Здравствуйте, Воронков Василий, Вы писали:
ВВ>Здравствуйте, dotneter, Вы писали:
ВВ>>>но нет нужных высокоуровневых средств, включая даже самые банальные. D>>Можно список?
ВВ>Да начните хотя бы с модулей или пространств имен.
Неплохо эмулируется. ВВ>Если это функциональный язык, то где первоклассные средства для частичного применения функций? Язык не в последнюю очередь расчитан на работу с ДОМ-ом, но где хоть какие-то встроенные средства для этого вроде ПМ-а? За исключением самых последних версий, которые все равно на широком уровне использовать нельзя, нет встроенных средств для представления non strict вычислений.
Ничего что этого нет в большенстве популярных языков? ВВ>Обращения к родительскому скопу (base, super) нет. Отсутствует понятие иммутабельности, констант или чего-то подобного. Из-за этого, кстати, уже в сам язык заложены чудесатые грабли — например, можно спокойно переопределить undefined.
Не сказал бы что это все тянет на вашу третью стадию, скорее должно быть
3) Да, чего-то не хватает, но пользоваться вполне можно.
... << RSDN@Home 1.2.0 alpha 4 rev. 1111>>
Talk is cheap. Show me the code.
Re[16]: [JavaScript] Формирование DOM-а в броузере
Здравствуйте, Gaperton, Вы писали:
ВВ>>Наконец те, кому нравится ДжаваСкрипт, могут просто не пользоваться таким фреймворком. Всегда есть альтернативы. Для больших любителей ДжаваСкрипта есть и вовсе node.js. G>"Такого фреймворка" — сейчас нет, им, в конце концов, невозможно воспользоваться, и об альтернативах ему и свободе выбора говорить рановато. А вот dojo с extjs — уже есть, как и GWT.
Ну и монструозным его называть тоже ведь рановато, правда?
ВВ>>К тому же мысль о том, что фреймворк, отвечающий за компиляцию основного языка в ДжаваСкрипт, должен быть монструозным, а клиентские фреймворки — всегда белые и пушистые, мне кажется несколько сомнительной. Как раз наоборот — последнее время библиотеки для ДжаваСкрипта становятся все более и более монструозными. И прежде всего потому что они пытаются восполнить недостатки самого языка. Очевидно же, что куда лучше, когда у нас есть, так сказать, "первоклассные" средства, а не их эмуляция на уровне библиотек.
G>Когда эта мысль кажется сомнительной — всегда можно посмотреть на Google Web Toolkit, транслирующий Java в HTML/JS, и сравнить монструозность. Заодно станет понятно, что при подходе с компиляцией возникает интереснейшая проблема с отладкой. В GWT, например, она решается своим контейнером и специальным рантаймом для запуска и отладки приложений на JAVA без компиляции.
В отличие от Джава, Немерле довольно хорошо подходит для решения такого класса задач. Задача с отладкой может быть решена по-разному — в том числе и имитацией хост-среды браузера. Опять же — могу сказать, что я очень редко отлаживаю ДжаваСкрипт. Вполне можно прожить без пошаговой отладки вообще, просто с расширенным отладочным дампом, позволяющий "снимать" стек на определенный момент времени, глобальный скоп и пр. На худой конец можно отлаживать ДжаваСкрипт
ВВ>>Вообще в ДжаваСкрипте следующая проблема. Есть довольно мощная база — в случае с JS это замыкания и P-OOP, — но нет нужных высокоуровневых средств, включая даже самые банальные. В итоге, используя эту самую базу, мы и пытаемся через ректальное отверстие имитировать то, что легко и просто достигается на других языках, потому что уже есть "из коробки".
G>Так не надо имитировать — не будет и проблем. На JS надо писать так, как положено писать на JS, не пытаясь изображать из него всякие явы, сишарпы, и прочие. Там свои идиомы. Я, например, разного рода "объектными" обертками вроде Prototype не пользуюсь.
А как на нем положено писать? В функциональном стиле на нем писать нельзя — он просто никакой в этом плане. P-OOP через делегацию — кто-то реально использует его на полную катушку в более или менее габаритных проектах? Это ж тихий ужас — вся программа превращается в один гигантский спец-эффект и никаких средств контроля над этим. Как это вообще с функциональной парадигмой сочетается? Говорят, что Схемой при дизайне JS вдохнялись? Ага.
Я концепцию этого языка не понимаю. И по ходу ее никто вообще не понимает. Все "продвинутые" библиотеки на ДжаваСкрипте написаны в таком стиле, который сложно назвать красивым и понятным. Слабо верится, что есть какой-то "другой" ДжаваСкрипт, где все и правда решается легко и просто, а не через заднее отверстие.
Вообще проблема JS в том, что на нем очень сложно писать надежный код. Неспроста возникают паттерны вроде:
function foo(bar, undefined) {
if (bar == undefined) {
...
}
}
foo(bar);
И не надо говорить, что ДжаваСкрипт — это просто обычный динамический язык. Есть и другие динамические языки, не все атрибуты ДжаваСкрипта являются необходимыми для динамического языка.
ВВ>>На мой взгляд и Питон, и Руби — если уж говорить о других популярных динамических языках — гораздо лучше ДжаваСкрипта. Они продуманней и повернуты к пользователю нужным местом, а не этим самым ректальным отверстием. Это уж не говоря о том, что вообще есть такие языки как Эрланг. G>Это вопрос исключительно привычек и умения готовить конкретный язык. На JS, Питоне, и Руби одна и та же задача может быть решена по разному. И выглядеть при этом хорошо.
Я так не считаю. Я считаю, что ДжаваСкрипт куда более низкоуровневый язык по сравнению с Питоном и Руби. И решения на нем выглядят, соответственно. Там, где на Руби получится изящный ДСЛ, на ДжаваСкрипте будет тонна говнокода, играющего с замыканиями. Покажи мне код на ДжаваСкрипте, отличный от тривиального, который выглядит хорошо?
Сравни фичи ДжаваСкрипта и Руби. В последнем куча *высокоуровневых* абстракций. В ДжаваСкрипте — замыкания и спец-эффекты.
ВВ>>В итоге идея компиляции основного языка в ДжаваСкрипт мне кажется очень даже многообещающей. Ее основная задача — даже не избавиться от "плохого" JS, а писать весь код приложения на одном языке, а следовательно, иметь возможность использовать общие подходы и паттерны, даже реюзать одни и те же функции и пр. G>Такое средство уже есть, и оно достаточно зрелое. Это Google Web Toolkit.
А на дотнете мне толку от него?
Еще и ur/web есть, но вопрос — аналогичный.
Re[18]: [JavaScript] Формирование DOM-а в броузере
Здравствуйте, dotneter, Вы писали:
ВВ>>Да начните хотя бы с модулей или пространств имен. D>Неплохо эмулируется.
На ДжаваСкрипте все в той или иной степени эмулируется. Плохо именно то, что эмулируется. И зачастую по-разному.
ВВ>>Если это функциональный язык, то где первоклассные средства для частичного применения функций? Язык не в последнюю очередь расчитан на работу с ДОМ-ом, но где хоть какие-то встроенные средства для этого вроде ПМ-а? За исключением самых последних версий, которые все равно на широком уровне использовать нельзя, нет встроенных средств для представления non strict вычислений. D>Ничего что этого нет в большенстве популярных языков?
В популярных языках есть нормальное следование главной концепции. Если таковой не является ФП, то мы имеем стандартный набор из перегрузки, именованных параметров и пр. Но в ДжаваСкрипте нет и этого. Собственно, в нем нет полноценной реализации ни одной из поддерживаемых парадигм.
ВВ>>Обращения к родительскому скопу (base, super) нет. Отсутствует понятие иммутабельности, констант или чего-то подобного. Из-за этого, кстати, уже в сам язык заложены чудесатые грабли — например, можно спокойно переопределить undefined. D>Не сказал бы что это все тянет на вашу третью стадию, скорее должно быть D>3) Да, чего-то не хватает, но пользоваться вполне можно.
Чего конкретно в нем не хватает, зависит от того, с каких позиций к нему подходить.
Как у функционального языка у него не хватает много чего, вплоть до сомнений в том, что он является функциональным. Реализована лишь самая базовая инфраструктура. Где частичное применение? Операторы для работы с функциями? Где иммутабельные переменные и структуры данных? Хвостовую рекурсию из имеющихся реализаций хоть кто-нибудь раскручивает?
Если рассматривать его как P-OOP язык и сравнивать, скажем, с Self, то опять же окажется, что реализована лишь самая базовая инфраструктура. Где трейты, уникальные объекты, миксины? Глядя на Self, возникает впечатление, что действительно у этого языка есть проработанная концепция, которая создавалась в расчете на то, что P-OOP действительно будет использоваться как главенствующая парадигма при программировании на Self. Глядя на ДжаваСкрипт...
Re[19]: [JavaScript] Формирование DOM-а в броузере
Здравствуйте, Воронков Василий, Вы писали:
ВВ>Глядя на Self, возникает впечатление, что действительно у этого языка есть проработанная концепция.
Опять же вы берете какие то сферические языки, возьмите тот же топ http://www.tiobe.com/index.php/content/paperinfo/tpci/index.html и скажите каким их них js сильно проигрывает в проработке концепции. Да, есть хорошо продуманые языки, но им уступает не только js, но и большенство остальных популярных языков.
... << RSDN@Home 1.2.0 alpha 4 rev. 1111>>
Talk is cheap. Show me the code.
Re[20]: [JavaScript] Формирование DOM-а в броузере
Здравствуйте, dotneter, Вы писали:
D>Здравствуйте, Воронков Василий, Вы писали:
ВВ>>Глядя на Self, возникает впечатление, что действительно у этого языка есть проработанная концепция. D>Опять же вы берете какие то сферические языки,
Это не сферические языки. Это прямые прародители JS. Если Self — это сферический язык программирования, то P-OOP — это сферическая парадигма программирования. А Схема так и вовсе в вашем топе есть.
D>возьмите тот же топ http://www.tiobe.com/index.php/content/paperinfo/tpci/index.html и скажите каким их них js сильно проигрывает в проработке концепции. Да, есть хорошо продуманые языки, но им уступает не только js, но и большенство остальных популярных языков.
Практически всем, за исключением разве что PHP. Все эти языки из списка имеют четко выраженную главенствующую парадигму, последовательно, а не обрывочно реализованную.
Re[17]: [JavaScript] Формирование DOM-а в броузере
В вебе WYSIWIG'ами для верстки чего-либо пользуются только люди, для которых и Word — это WYSIWIG редактор для веб'а. По вполне очевидной причине — вызивиги просто не умеют генерировать правильный код для визуального представления того, что на экране. И это задача на данный момент нереализуема вообще, кстати.
Здравствуйте, Gaperton, Вы писали:
G>Реализация шаблонов на стороне браузера — это в простейшем случае примерно пара десятков строк кода. Говорить не о чем. Пример здесь.
В простейшем случае все просто.
G>Именно так устроены шаблоны jQuery внутри.
G>Да с моей точки зрения вся твоя затея — есть бесполезная трата времени, сил, и процессора. Но время, естественно, твое, тебе и решать, как его тратить.
Было бы странно от тебя услышать что-то другое.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[17]: [JavaScript] Формирование DOM-а в броузере
Здравствуйте, VladD2, Вы писали:
G>>Реализация шаблонов на стороне браузера — это в простейшем случае примерно пара десятков строк кода. Говорить не о чем. Пример здесь.
VD>В простейшем случае все просто.
Ой, извини. У тебя же сложнейший случай, я не учел.
Re[18]: [JavaScript] Формирование DOM-а в броузере
Здравствуйте, Gaperton, Вы писали:
VD>>В простейшем случае все просто.
G>Ой, извини. У тебя же сложнейший случай, я не учел.
Достаточно того, что он не простерший. Самое важное тут автоматическое обновление при изменении зависимых свойств. Ну, и сами шаблоны должны быть рекурсивными, поддерживать управляющие конструкции и возможность формирования частей шаблонов с помощью ФВП.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[17]: [JavaScript] Формирование DOM-а в броузере
Здравствуйте, Воронков Василий, Вы писали:
G>>Когда эта мысль кажется сомнительной — всегда можно посмотреть на Google Web Toolkit, транслирующий Java в HTML/JS, и сравнить монструозность. Заодно станет понятно, что при подходе с компиляцией возникает интереснейшая проблема с отладкой. В GWT, например, она решается своим контейнером и специальным рантаймом для запуска и отладки приложений на JAVA без компиляции.
ВВ>В отличие от Джава, Немерле довольно хорошо подходит для решения такого класса задач.
Тот факт, что Java внезапно стала для него подходить плохо — еще надо обосновать. Про неуловимого Джо по кличке Немерле — я вообще молчу.
ВВ>Задача с отладкой может быть решена по-разному — в том числе и имитацией хост-среды браузера.
Человеческий способ ровным счетом один — сделать так же, как в GWT. Все остальное приведет к "ухудшению качества сервиса" для разработчика.
ВВ>Опять же — могу сказать, что я очень редко отлаживаю ДжаваСкрипт. Вполне можно прожить без пошаговой отладки вообще, просто с расширенным отладочным дампом, позволяющий "снимать" стек на определенный момент времени, глобальный скоп и пр.
Если джаваскрипта всего три строки "для придания сайтам динамики" — то отлаживать почти нечего. И говорить тоже не о чем.
А вот в каком-нибудь GMail — его как минимум тысячи строк. Про Google Docs я вообще молчу.
ВВ>На худой конец можно отлаживать ДжаваСкрипт
Автогенеренный? Ради счастья работать с фреймворком, избавляющим программиста от говноязыка JS? Спасибо, без меня. Я предпочитаю отлаживать код, написанный человеком для человека.
ВВ>>>Вообще в ДжаваСкрипте следующая проблема. Есть довольно мощная база — в случае с JS это замыкания и P-OOP, — но нет нужных высокоуровневых средств, включая даже самые банальные. В итоге, используя эту самую базу, мы и пытаемся через ректальное отверстие имитировать то, что легко и просто достигается на других языках, потому что уже есть "из коробки".
G>>Так не надо имитировать — не будет и проблем. На JS надо писать так, как положено писать на JS, не пытаясь изображать из него всякие явы, сишарпы, и прочие. Там свои идиомы. Я, например, разного рода "объектными" обертками вроде Prototype не пользуюсь.
ВВ>А как на нем положено писать? В функциональном стиле на нем писать нельзя — он просто никакой в этом плане.
В целом — получается очень похоже на generic programming Степанова — объекты + ФВП. А этот стиль, в свою очередь взят из лиспа.
На JS прекрасно можно писать в функциональном стиле. И делать "монадные" протяжки в духе LINQ — это вообще элементарно.
ВВ>P-OOP через делегацию — кто-то реально использует его на полную катушку в более или менее габаритных проектах? Это ж тихий ужас — вся программа превращается в один гигантский спец-эффект и никаких средств контроля над этим.
Это не тихий ужас, а очень интересная особенность, которую надо уметь правильно готовить. Реальная потребность в этом возникает редко.
ВВ> Как это вообще с функциональной парадигмой сочетается? Говорят, что Схемой при дизайне JS вдохнялись? Ага.
Вполне нормально сочетается. У меня, по крайней мере. Схема и Лисп не являются чистыми ФЯ — там применяется ровно тот же стиль, что в JS, плюс еще макросы.
ВВ>Я концепцию этого языка не понимаю. И по ходу ее никто вообще не понимает.
Никто? Да неужели? Ты опрос проводил?
ВВ>Все "продвинутые" библиотеки на ДжаваСкрипте написаны в таком стиле, который сложно назвать красивым и понятным. Слабо верится, что есть какой-то "другой" ДжаваСкрипт, где все и правда решается легко и просто, а не через заднее отверстие.
А на Немерле — все продвинутые библиотеки непременно написаны красиво и кому угодно понятно?
ВВ>Вообще проблема JS в том, что на нем очень сложно писать надежный код. Неспроста возникают паттерны вроде:
ВВ>
Эвона как. Век живи — век учись говнокод писать. Можно подробнее — и откуда же возникают подобные "паттерны"?
ВВ>И не надо говорить, что ДжаваСкрипт — это просто обычный динамический язык. Есть и другие динамические языки, не все атрибуты ДжаваСкрипта являются необходимыми для динамического языка.
Почему не надо-то? Оно так и есть.
G>>Это вопрос исключительно привычек и умения готовить конкретный язык. На JS, Питоне, и Руби одна и та же задача может быть решена по разному. И выглядеть при этом хорошо.
ВВ>Я так не считаю. Я считаю, что ДжаваСкрипт куда более низкоуровневый язык по сравнению с Питоном и Руби. И решения на нем выглядят, соответственно. Там, где на Руби получится изящный ДСЛ, на ДжаваСкрипте будет тонна говнокода, играющего с замыканиями. Покажи мне код на ДжаваСкрипте, отличный от тривиального, который выглядит хорошо?
Дай мне пример, где по твоему непременно на JS говнокод должен получиться — и поговорим. Давай, show me your code.
ВВ>>>В итоге идея компиляции основного языка в ДжаваСкрипт мне кажется очень даже многообещающей. Ее основная задача — даже не избавиться от "плохого" JS, а писать весь код приложения на одном языке, а следовательно, иметь возможность использовать общие подходы и паттерны, даже реюзать одни и те же функции и пр. G>>Такое средство уже есть, и оно достаточно зрелое. Это Google Web Toolkit.
ВВ>А на дотнете мне толку от него?
На дотнете аналогичная штука делалась в рамках F#.
Re[19]: [JavaScript] Формирование DOM-а в броузере
Здравствуйте, VladD2, Вы писали:
G>>Ой, извини. У тебя же сложнейший случай, я не учел.
VD>Достаточно того, что он не простерший. Самое важное тут автоматическое обновление при изменении зависимых свойств. Ну, и сами шаблоны должны быть рекурсивными, поддерживать управляющие конструкции и возможность формирования частей шаблонов с помощью ФВП.
Интересно. Примеры использования этого языка шаблонов у тебя есть? Наброски какие-нибудь?
Re[20]: [JavaScript] Формирование DOM-а в броузере
Здравствуйте, Gaperton, Вы писали:
G>>>Ой, извини. У тебя же сложнейший случай, я не учел.
VD>>Достаточно того, что он не простерший. Самое важное тут автоматическое обновление при изменении зависимых свойств. Ну, и сами шаблоны должны быть рекурсивными, поддерживать управляющие конструкции и возможность формирования частей шаблонов с помощью ФВП.
G>Интересно. Примеры использования этого языка шаблонов у тебя есть? Наброски какие-нибудь?
Желательно — иллюстрирующие идею формирования фрагментов шаблонов с помощью ФВП.
Re[17]: [JavaScript] Формирование DOM-а в броузере
Здравствуйте, Воронков Василий, Вы писали:
ВВ>Да начните хотя бы с модулей, или пространств имен
Модули закрыты спецификацией CommonJS.
Пространства имен делаются тривиально. Например, так.
var module = function(){
var _privateVar;
return {
publicVar: ...
}
}();
ВВ>Если это функциональный язык, то где первоклассные средства для частичного применения функций?
Ни разу не обязаны присутствовать в функциональном языке. Эрланг, например, как-то обходится.
ВВ>Язык не в последнюю очередь расчитан на работу с ДОМ-ом, но где хоть какие-то встроенные средства для этого вроде ПМ-а?
Средства для работы с DOM-ом берутся в абсолютно любом современном веб фреймворке (например — jQuery). Выглядят везде одинаково, и основаны на CSS-селекторах. Паттерн-матчинг в этой задаче в сравнении с селекторами нервно курит в сторонке.
ВВ>За исключением самых последних версий, которые все равно на широком уровне использовать нельзя, нет встроенных средств для представления non strict вычислений.
Что характерно — JS в этом не одинок, и никакой трагедии в этом нет.
ВВ> Обращения к родительскому скопу (base, super) нет.
Есть. Прототипы.
ВВ> Отсутствует понятие иммутабельности, констант или чего-то подобного. Из-за этого, кстати, уже в сам язык заложены чудесатые грабли — например, можно спокойно переопределить undefined.
Так же, как в Схеме и Лиспе. И что?
ВВ>Вообще такое ощущение, что ДжаваСкрипт никто под его предметную область не затачивал.
Достаточно один раз взглянуть на jQuery, чтобы понять, что заточка под "предметную область" JS-у не требуется. Она излишня.
ВВ>Просто некий динамический язык, с неким рандомным набором парадигм. К тому же, чтобы писать на нем более или менее безопасный код, придется писать столько кода, что даже C# на этом фоне покажется лаконичным.
Пример.
Re[18]: [JavaScript] Формирование DOM-а в броузере
Здравствуйте, Gaperton, Вы писали:
ВВ>>В отличие от Джава, Немерле довольно хорошо подходит для решения такого класса задач. G>Тот факт, что Java внезапно стала для него подходить плохо — еще надо обосновать. Про неуловимого Джо по кличке Немерле — я вообще молчу.
Одних квази-цитат по-моему достаточно, что определить, что подходит хорошо, а что плохо.
ВВ>>Задача с отладкой может быть решена по-разному — в том числе и имитацией хост-среды браузера. G>Человеческий способ ровным счетом один — сделать так же, как в GWT. Все остальное приведет к "ухудшению качества сервиса" для разработчика. ВВ>>Опять же — могу сказать, что я очень редко отлаживаю ДжаваСкрипт. Вполне можно прожить без пошаговой отладки вообще, просто с расширенным отладочным дампом, позволяющий "снимать" стек на определенный момент времени, глобальный скоп и пр. G>Если джаваскрипта всего три строки "для придания сайтам динамики" — то отлаживать почти нечего. И говорить тоже не о чем. G>А вот в каком-нибудь GMail — его как минимум тысячи строк. Про Google Docs я вообще молчу.
Ты разрабатывал GMail и отлаживал там ДжаваСкрипт? Я писал достаточно большие приложения на JS и отладчиком практически не пользовался. Вообще полезность пошагового отладчика сильно преувеличена. Есть куча языков, где его вообще нет — и ничего. Пишите тесты и будет вам счастье.
ВВ>>На худой конец можно отлаживать ДжаваСкрипт G>Автогенеренный? Ради счастья работать с фреймворком, избавляющим программиста от говноязыка JS? Спасибо, без меня. Я предпочитаю отлаживать код, написанный человеком для человека.
Ну и что? Народ не смущает отлаживать автогенеренный JS в который компилируется CoffeeScript. Тебя смущает — проходите дальше. В чем проблема-то?
G>В целом — получается очень похоже на generic programming Степанова — объекты + ФВП. А этот стиль, в свою очередь взят из лиспа. G>На JS прекрасно можно писать в функциональном стиле. И делать "монадные" протяжки в духе LINQ — это вообще элементарно.
Примерчик приведи такой "протяжки". Пока что Linq из императивного языка C# у меня слабо ассоциируется с функциональщиной.
ВВ>>P-OOP через делегацию — кто-то реально использует его на полную катушку в более или менее габаритных проектах? Это ж тихий ужас — вся программа превращается в один гигантский спец-эффект и никаких средств контроля над этим. G>Это не тихий ужас, а очень интересная особенность, которую надо уметь правильно готовить. Реальная потребность в этом возникает редко.
Нет там ничего интересного. Реализован самый базис из того же Self-а. А обо всем остальном забыли. Рекурсивный люкап по хэш-таблицами — вот и весь ваш П-ООП в JS.
ВВ>> Как это вообще с функциональной парадигмой сочетается? Говорят, что Схемой при дизайне JS вдохнялись? Ага. G>Вполне нормально сочетается. У меня, по крайней мере. Схема и Лисп не являются чистыми ФЯ — там применяется ровно тот же стиль, что в JS, плюс еще макросы.
Какой такой "тот же стиль"? P-OOP что ли?
Лисп вообще ни разу не похож не JS, там принципиально другая идеология.
ВВ>>Я концепцию этого языка не понимаю. И по ходу ее никто вообще не понимает. G>Никто? Да неужели? Ты опрос проводил?
Я видел довольно много кода, а ты?
ВВ>>Вообще проблема JS в том, что на нем очень сложно писать надежный код. Неспроста возникают паттерны вроде: ВВ>>
G>Эвона как. Век живи — век учись говнокод писать. Можно подробнее — и откуда же возникают подобные "паттерны"?
Ну если ты не знаешь, то undefined можно переопределить и это единственный способ гарантированно получить "правильный" undefined. В противном случае в коде будет уязвимость. Иначе говоря, он является говно-кодом.
ВВ>>И не надо говорить, что ДжаваСкрипт — это просто обычный динамический язык. Есть и другие динамические языки, не все атрибуты ДжаваСкрипта являются необходимыми для динамического языка. G>Почему не надо-то? Оно так и есть.
Потому что это не так. Все языки разные. Динамика вовсе не обязывает всех превращаться в ДжаваСкрипт.
G>>>Это вопрос исключительно привычек и умения готовить конкретный язык. На JS, Питоне, и Руби одна и та же задача может быть решена по разному. И выглядеть при этом хорошо. ВВ>>Я так не считаю. Я считаю, что ДжаваСкрипт куда более низкоуровневый язык по сравнению с Питоном и Руби. И решения на нем выглядят, соответственно. Там, где на Руби получится изящный ДСЛ, на ДжаваСкрипте будет тонна говнокода, играющего с замыканиями. Покажи мне код на ДжаваСкрипте, отличный от тривиального, который выглядит хорошо? G>Дай мне пример, где по твоему непременно на JS говнокод должен получиться — и поговорим. Давай, show me your code.
В любой. Любое значение можно переопределить. Почти любая операция над любыми типами корректна. Все высокоуровневые возможности имитируются на замыканиях. Получается куча кода, которую легко поломать простой опечаткой.
Re[19]: [JavaScript] Формирование DOM-а в броузере
Здравствуйте, Воронков Василий, Вы писали:
G>>Эвона как. Век живи — век учись говнокод писать. Можно подробнее — и откуда же возникают подобные "паттерны"? ВВ>Ну если ты не знаешь, то undefined можно переопределить и это единственный способ гарантированно получить "правильный" undefined. В противном случае в коде будет уязвимость. Иначе говоря, он является говно-кодом.
Есть как минимум ещё 2 способа проверки на неопределённое значение:
typeof bar == "undefined"
и
bar == void 0
А выше приведённый код и вправду так себе.
G>>Дай мне пример, где по твоему непременно на JS говнокод должен получиться — и поговорим. Давай, show me your code. ВВ>В любой. Любое значение можно переопределить. Почти любая операция над любыми типами корректна. Все высокоуровневые возможности имитируются на замыканиях. Получается куча кода, которую легко поломать простой опечаткой.
Всё перечисленное не имеет непосредственного отношения к говнокоду, но облегчает его написание при желании и определённой форме рук. В любом случае, без примеров тут говорить не о чем, что показывает предыдущий пример.
Re[20]: [JavaScript] Формирование DOM-а в броузере
Здравствуйте, Gaperton, Вы писали:
VD>>Достаточно того, что он не простерший. Самое важное тут автоматическое обновление при изменении зависимых свойств. Ну, и сами шаблоны должны быть рекурсивными, поддерживать управляющие конструкции и возможность формирования частей шаблонов с помощью ФВП.
G>Интересно. Примеры использования этого языка шаблонов у тебя есть? Наброски какие-нибудь?
Шаблонов пока не реализовано. Так что могу только показать как примерно тоже самое выглядит на базе встроенных элементов: ClickCounter.n
В комментарии преведен жабаскрипт в который раскрывается модель.
Ниже приведена вьюха. Собственно вот такие вьюхи и должны становиться за одно и клиентскими шаблонами, к которым можно осуществлять декларативный биндинг (как это делается со встроенными элементами).
Внутри биндинга пока жабаскрипт, но планируется там тоже использовать статически-типизированный язык.
Здравствуйте, VladD2, Вы писали:
VD>Шаблонов пока не реализовано. Так что могу только показать как примерно тоже самое выглядит на базе встроенных элементов: VD>[url=http://code.google.com/p/nemerle/source/browse/nemerle/trunk/snippets/Nemerle.WUI.Reactive/Test/MVVMs/ClickCounter.n VD>]ClickCounter.n[/url] VD>В комментарии преведен жабаскрипт в который раскрывается модель. VD>Ниже приведена вьюха. Собственно вот такие вьюхи и должны становиться за одно и клиентскими шаблонами, к которым можно осуществлять декларативный биндинг (как это делается со встроенными элементами). VD>Внутри биндинга пока жабаскрипт, но планируется там тоже использовать статически-типизированный язык.
Понятно.
1) Как собираемся решать проблему отсутствия отладчика?
2) Как будет устроено взаимодействие клиента на JS и сервера?
VD>В качестве прототипа можно рассматривать knockout:
Кнокаут знаю.
Re[19]: [JavaScript] Формирование DOM-а в броузере
Здравствуйте, Воронков Василий, Вы писали:
ВВ>Ты разрабатывал GMail и отлаживал там ДжаваСкрипт? Я писал достаточно большие приложения на JS и отладчиком практически не пользовался. Вообще полезность пошагового отладчика сильно преувеличена. Есть куча языков, где его вообще нет — и ничего. Пишите тесты и будет вам счастье.
О, переход на личности. Какая разница, разрабатывал ли лично я GMail? Это что-то меняет?
Если тебе интересно — я делал не уступающее ему по сложности офллайновое веб-проложение для POS-терминалов, работающее в FF 3.6 на google gears, в котором _вся_ логика реализована на JS.
И позволь мне тебе не поверить, что ты смог сделать что-то мало-мальски сложное, работающее в браузере, не пользуясь отладчиком.
G>>Автогенеренный? Ради счастья работать с фреймворком, избавляющим программиста от говноязыка JS? Спасибо, без меня. Я предпочитаю отлаживать код, написанный человеком для человека.
ВВ>Ну и что? Народ не смущает отлаживать автогенеренный JS в который компилируется CoffeeScript. Тебя смущает — проходите дальше. В чем проблема-то?
Ты видишь какую-то проблему в том, что я предпочитаю отлаживать код, написанный человеком для человека, и предлагаю вам отлаживать автогенеренный код без меня? Я — не вижу.
ВВ>Примерчик приведи такой "протяжки". Пока что Linq из императивного языка C# у меня слабо ассоциируется с функциональщиной.
var map = _db.select("*").from("mytable").where("key = ?", value ).as_map( "Id", RowConstructor );
G>>Это не тихий ужас, а очень интересная особенность, которую надо уметь правильно готовить. Реальная потребность в этом возникает редко.
ВВ>Нет там ничего интересного. Реализован самый базис из того же Self-а. А обо всем остальном забыли. Рекурсивный люкап по хэш-таблицами — вот и весь ваш П-ООП в JS.
А весь ООП в С++ — это косвенный вызов по VMT. И что?
ВВ>>> Как это вообще с функциональной парадигмой сочетается? Говорят, что Схемой при дизайне JS вдохнялись? Ага. G>>Вполне нормально сочетается. У меня, по крайней мере. Схема и Лисп не являются чистыми ФЯ — там применяется ровно тот же стиль, что в JS, плюс еще макросы.
ВВ>Какой такой "тот же стиль"? P-OOP что ли?
Нет, не что ли. Я ответил в письме — ты ответ проскипал.
ВВ>Лисп вообще ни разу не похож не JS, там принципиально другая идеология.
Внешняя похожесть к вопросу никакого отношения не имеет.
ВВ>>>Я концепцию этого языка не понимаю. И по ходу ее никто вообще не понимает. G>>Никто? Да неужели? Ты опрос проводил? ВВ>Я видел довольно много кода, а ты?
А я довольно много писал.
G>>Эвона как. Век живи — век учись говнокод писать. Можно подробнее — и откуда же возникают подобные "паттерны"?
ВВ>Ну если ты не знаешь, то undefined можно переопределить и это единственный способ гарантированно получить "правильный" undefined. В противном случае в коде будет уязвимость. Иначе говоря, он является говно-кодом.
Ну, если ты не знаешь, то для надежной проверки на undefined достаточно написать:
if(typeof myVar == 'undefined')
Теперь давай вернемся к вопросу — и откуда же у нас возникают подобные "паттерны"?
ВВ>>>И не надо говорить, что ДжаваСкрипт — это просто обычный динамический язык. Есть и другие динамические языки, не все атрибуты ДжаваСкрипта являются необходимыми для динамического языка. G>>Почему не надо-то? Оно так и есть.
ВВ>Потому что это не так. Все языки разные. Динамика вовсе не обязывает всех превращаться в ДжаваСкрипт.
Конечно не обязывает. КО сообщает — если бы в JavaScript не было никаких отличий от Ruby, он назывался бы не JavaScript, а Ruby. Языки разные — но по своим возможностям равноценны.
G>>Дай мне пример, где по твоему непременно на JS говнокод должен получиться — и поговорим. Давай, show me your code.
ВВ>В любой. Любое значение можно переопределить.
Как в Лиспе и Схеме. И что?
ВВ>Почти любая операция над любыми типами корректна. Все высокоуровневые возможности имитируются на замыканиях.
Как в лиспе и схеме.
ВВ>Получается куча кода, которую легко поломать простой опечаткой.
Как в любом динамическом языке.
Re[20]: [JavaScript] Формирование DOM-а в броузере
Здравствуйте, Gaperton, Вы писали:
ВВ>>Ты разрабатывал GMail и отлаживал там ДжаваСкрипт? Я писал достаточно большие приложения на JS и отладчиком практически не пользовался. Вообще полезность пошагового отладчика сильно преувеличена. Есть куча языков, где его вообще нет — и ничего. Пишите тесты и будет вам счастье. G>О, переход на личности. Какая разница, разрабатывал ли лично я GMail? Это что-то меняет?
Разница есть, когда ты начинаешь делать такие утверждения. Я как-то не вижу того, чтобы ты говорил исключительно за себя. Напротив, ты же делаешь глобальные утверждения о том, какой именно дебаг нужен и как он вообще необходим. Вполне логично спросить, на основе чего эти утверждения делаются.
G>Если тебе интересно — я делал не уступающее ему по сложности офллайновое веб-проложение для POS-терминалов, работающее в FF 3.6 на google gears, в котором _вся_ логика реализована на JS. G>И позволь мне тебе не поверить, что ты смог сделать что-то мало-мальски сложное, работающее в браузере, не пользуясь отладчиком.
Я вообще практически не пользуюсь отладчиком. И можешь мне не верить. Мне, честно говоря, как-то по фиг
G>>>Автогенеренный? Ради счастья работать с фреймворком, избавляющим программиста от говноязыка JS? Спасибо, без меня. Я предпочитаю отлаживать код, написанный человеком для человека. ВВ>>Ну и что? Народ не смущает отлаживать автогенеренный JS в который компилируется CoffeeScript. Тебя смущает — проходите дальше. В чем проблема-то? G>Ты видишь какую-то проблему в том, что я предпочитаю отлаживать код, написанный человеком для человека, и предлагаю вам отлаживать автогенеренный код без меня? Я — не вижу.
Я не понимаю, зачем это вообще обсуждается тут. Речь была не о твоих личных предпочтениях.
ВВ>>Примерчик приведи такой "протяжки". Пока что Linq из императивного языка C# у меня слабо ассоциируется с функциональщиной. G>
Не вижу здесь никаких монад. В лучшем случае это банальная цепочка вызовов, по аналогии с pipe-operator-ами. Которая здесь имитируется на чем-то вроде fluent API.
Объясни мне пожалуйста, что в этом коде функционального и какое он имеет отношение к Linq.
G>>>Это не тихий ужас, а очень интересная особенность, которую надо уметь правильно готовить. Реальная потребность в этом возникает редко. ВВ>>Нет там ничего интересного. Реализован самый базис из того же Self-а. А обо всем остальном забыли. Рекурсивный люкап по хэш-таблицами — вот и весь ваш П-ООП в JS. G>А весь ООП в С++ — это косвенный вызов по VMT. И что?
Тогда бы С++ мало чем отличался от С, где косвенный вызов тоже не проблема.
Речь, видимо, о том, что П-ООП предполагает еще что-то, кроме, собственно, механизма делегации и самих прототипов, но вот в JS ничего этого нет.
А class based OOP в С++ достаточно полон.
ВВ>>>> Как это вообще с функциональной парадигмой сочетается? Говорят, что Схемой при дизайне JS вдохнялись? Ага. G>>>Вполне нормально сочетается. У меня, по крайней мере. Схема и Лисп не являются чистыми ФЯ — там применяется ровно тот же стиль, что в JS, плюс еще макросы. ВВ>>Какой такой "тот же стиль"? P-OOP что ли? G>Нет, не что ли. Я ответил в письме — ты ответ проскипал.
Ах, ты про монадические протяжки. Опять же мимо. Вся программа на Лиспе может рассматриваться как один большой список, текст программы — манипуляция с самим текстом программы как со списком. ДжаваСкриптом тут не пахнет.
ВВ>>Лисп вообще ни разу не похож не JS, там принципиально другая идеология. G>Внешняя похожесть к вопросу никакого отношения не имеет.
Я не про внешнюю похожесть.
ВВ>>>>Я концепцию этого языка не понимаю. И по ходу ее никто вообще не понимает. G>>>Никто? Да неужели? Ты опрос проводил? ВВ>>Я видел довольно много кода, а ты? G>А я довольно много писал.
И пришел к выводу, что ДжаваСкрипт похож на Лисп?
G>>>Эвона как. Век живи — век учись говнокод писать. Можно подробнее — и откуда же возникают подобные "паттерны"?
ВВ>>Ну если ты не знаешь, то undefined можно переопределить и это единственный способ гарантированно получить "правильный" undefined. В противном случае в коде будет уязвимость. Иначе говоря, он является говно-кодом.
G>Ну, если ты не знаешь, то для надежной проверки на undefined достаточно написать: G>
G>if(typeof myVar == 'undefined')
G>
Этот код не одинаков. null == undefined вычисляется в true. Тип null при этом object. То, что я привел — это просто пример. Его можно записать и проще, просто объявив переменную без инициализации. И в отличие от твоего варианта он работает.
G>Теперь давай вернемся к вопросу — и откуда же у нас возникают подобные "паттерны"?
Видимо, от понимания семантики языка.
ВВ>>>>И не надо говорить, что ДжаваСкрипт — это просто обычный динамический язык. Есть и другие динамические языки, не все атрибуты ДжаваСкрипта являются необходимыми для динамического языка. G>>>Почему не надо-то? Оно так и есть. ВВ>>Потому что это не так. Все языки разные. Динамика вовсе не обязывает всех превращаться в ДжаваСкрипт. G>Конечно не обязывает. КО сообщает — если бы в JavaScript не было никаких отличий от Ruby, он назывался бы не JavaScript, а Ruby. Языки разные — но по своим возможностям равноценны.
Если сейчас мы начнем скатываться в тему "все языки тюринг полны", то это просто демагогия. В большинстве популярных языков достаточно полно реализованы их основные парадигмы. В ДжаваСкрипте этого нет. Если он нахватался исключительно худших черт от своих прародителей, это его вовсе не оправдывает.
Re[22]: [JavaScript] Формирование DOM-а в броузере
Здравствуйте, Gaperton, Вы писали:
G>Понятно. G>1) Как собираемся решать проблему отсутствия отладчика?
Модель представления компилируется в исполняемый код и отладка для нее есть (при наличии тестов).
Представление тоже можно в тестах дергать в скомппилированом виде.
С биндингом дела обстоят хуже. Но он ведь декларативный, а значит и отлаживать в нем особо нечего.
Для сложных случаев можно отлаживать сгенерированные скрипты (в броузере).
G>2) Как будет устроено взаимодействие клиента на JS и сервера?
Для модели представления у нас есть все матаданные (во время компиляции). По ней можно генерировать код для сериализации в JSON и обратно (с контролем типов и т.п.).
VD>>В качестве прототипа можно рассматривать knockout:
G>Кнокаут знаю.
Ну, вот собственно идея сделать к нему (или аналогичный ему) фрэймворк, только не на JS, а на базе усеченного (до возможностей JS) немерла. Модель представления и представление описывается на немерле. Далее по этому описанию генерируется скрипт и ХТМЛ которые отправляются клиенту.
При этом имеем следующие фичи:
1. Статическая типизация для кода модели представления и представлений, что позволяет отслеживать несоответствия между ними.
2. Интеллисенс.
3. Наличие метаданных модели во время компиляции позволяет генерировать много разных разностей вроде сериализации в JSON или кода валидации.
4. Все преимущества реактивного подхода в UI. Ну, как в кнокауте.
5. Сокрытие деталей реализации. В том же кнокауте приходится заниматься преситаниями, так как вместо простых типов нужно использовать разные обзервабл-обертки. Тут же код чистый, а обзерверность припаивается при генерации кода.
6. Кнокаут вычисляет зависимости в рантайме. Мы же можем вычислить их статически и не дать, например, создать циклическую зависимость.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
А вот dojo с extjs — уже есть, как и GWT.
Ты опрос проводил?
