Re[25]: Веб и динамика? Веб и статика+метапрограммирование. - Философия программирования

Здравствуйте, Воронков Василий, Вы писали:

ВВ>Про меньшее количество движений — это совсем неочевидно. Как компилятор может контролировать то, что известно только в рантайме?

А не надо выдумывать. Все что нужно для веб-сервера известно в компайлтайме. Более того сам компайл-тайм может быть в рантайме, если что.

А контролировать он может очень многое. Главная разница в статическом МП (назовем это так) по сравнению с динамическим подходом заключается в том, что динамика как бы плывет по течению. Что есть то и используется. Скажем вызвали метод GetForumById(2)... Механизмы динамики перехватывают вызов несуществующего метода. На базе неких соглашений преобразуют его в некий SQL-запрос. Получают данные... Если данные есть, то заворачивают их, скажем, в JESON и отправляют клиенту. Все это происходит уже в рантайме. А значит от написания кода до отлова ошибки может пройти много времени.

Тоже самое основанное на статическом МП работает чуть иначе. Оно на этапе компиляции формирует модель данных, ненерирует по ней нужные методы и т.п. В итоге сама система типов контролирует корректность ссылок и зависимостей. При этом мы получаем интеллисенс и почти полностью застрахованы от опечаток. В рантайме сформированная еще при компиляции модель сравнивается с моделью БД и или выдается сообщение об ошибке, или БД реструктуризовавший так чтобы соответствовать модели данных.

Такое решение позволяет нам выявлять ошибки раньше и дает значительно больший контроль за происходящим. А это, на мой взгляд, несомненный плюс.

И вот еще что... Вернемся опять же к ПЕГ-у. Вот казалось бы Rats! и PegGrammar основаны на одном и том же формализме — PEG-е. Они оба используют статически-типизированные бэкэнды и генерацию кода. Но PegGrammar предоставляет значительно больше сервиса. Он обеспечивает раннее обнаружение ошибок и внятное сообщение о них. Так же он предоставляет навигацию по грамматике, подсветку ошибок прямо в грамматике, фолдинг и другие прелести которые мы имеем для обычного кода. Все это мы имеем потому, что мета-код встроен в процесс компиляции. Компилятор и макрос образуют замкнутую взаимодействующую систему. И это огромный плюс!

Здравствуйте, hardcase, Вы писали:

L>>Для кодогенерилки достаточно динамики, нафиг тут типы выводить?
H>foreach — макрос выводящий типы. Как его на кодогенераторах сделать?

Знаешь, я как-то об этом уже писал, но поиском не нашёл. Если вкратце, то такие вещи имхо нужно делать средствами языка. Например, в Haskell это будет функция. А типы выведет компилятор.

L>>По остальным пунктам, как я понимаю, замечаний нет?

H>Конечно есть, но уже сколько раз говорилось о них что лень повторять.

Ну так давай пофлеймим, скучно же.

H>Макросы нужны как средство автоматизации и абстрагирования: ядро Nemerle очень компактно, а макросы позволяют его расширить в нужную сторону нужным способом.

Грубо говоря: есть язык, недостаточно выразительный, скажем, C#. И вот мы добавляем к нему систему, позволяющую удобно писать к нему кучу компайлер-плагинов или там препроцессоров. Язык можно сделать жутко красивым и выразительным, расширяя его в нужную сторону таким способом. Это нормально?

Здравствуйте, lomeo, Вы писали:

L>Грубо говоря: есть язык, недостаточно выразительный, скажем, C#. И вот мы добавляем к нему систему, позволяющую удобно писать к нему кучу компайлер-плагинов или там препроцессоров. Язык можно сделать жутко красивым и выразительным, расширяя его в нужную сторону таким способом. Это нормально?

Да.

Здравствуйте, Ziaw, Вы писали:

Кэр>>Вы сами задали вопрос противопоставив type providers макросам. Я вам высказал свою точку зрения на тот момент, когда type providers появятся, и если они будут справлятся с этими задачами.

Z>Передергиваете, type providers макросам противопоставили вы.

Я сказал, что возможно есть более прямое решение проблемы типизации изначально нетипизированных данных. Протиповоставление "или-или" сделали вы в этом сообщении:

Кэр>Это решение потенциально покрывает такой пласт проблем, что возникает большой вопрос — а зачем тогда нужны будут макросы.

Я бы переформулировал вопрос. Зачем жалкое подобие макросов type providers тому у кого есть полноценные макросы. Эти провайдеры для конкретной задачи реализуются одним человеком максимум за пару недель без привлечения Don Syme и хайпа на PDC.

Где тут передергивание с моей стороны — не вижу в упор. Хотя судя по тому что что у вас и доказательства по аналогии таковыми перестали быть — от вас я готов ожидать уже чего угодно.

Z>А что, можно проектировать иерархию классов не задумываясь об SRP, LSP и прочих P? Это такая простая задача не наделать конфликтов с этими не вполне формальными принципами? Что, там нет ситуаций, когда все компилируется, а для исправления ошибки нужен редизайн иерархии либо костыли в виде навешиваний нескольких параллельных иерархий визиторов?

Эти проблемы имеют меньшую стоимость разрешения. Хотя бы потому что они гораздо лучше изучены. Но я так понимаю, я тут уперся в секту, поэтому я лучше отойду в сторону.

Z>Банальные экстеншен методы в умелых руках могут наделать жутких конфликтов, а если использовать их в виде DLL, понять, что не работает можно только взвалив на плечи рефлектор и тучу чужого кода.

Кэр>>В общем, есть много объективных причин (еще со времен Лиспа), почему кастомный синтаксис в прикладных задачах используется очень редко. Его удел — библиотеки, которые вещь в себе. И никакой другой задачи, кроме предоставления своего функционала не решают. Это вполне может быть веб-фреймворк. Но это очень вряд ли прикладная задача.

Z>Все библиотеки вещь в себе и никакой другой задачи кроме предоставления своего функционала не решают, это раз.

Нет. Большинство библиотек как раз-таки не изолированы должном образом от бизнес-задачи и проекта, в котором они написаны. Поэтому их как раз с трудом можно перенести в новый проект. Библиотеки из фреймворков — они как раз отличаются тем, что изначально затачиваются на многоразовое использование и допускают, что там будет бюджет на различные красивости, чтобы выделится на фоне других фреймворков.

Z>Кастомный синтаксис это всего лишь один из многочисленных способов применения метапрограммирования и он широко используется во всех языках с поддержкой метапрограммирования, это два.

Вот против этого широкого использования кастомного синтаксиса я как раз и выступаю. Он приносит дополнительные сложности, а инструментов, что бороться с этими сложностями что-то не видно.

Z>Тема как раз про вебфреймворки в динамике и статике, это три.

Я уже сказал, что веду речь об общем применении макросов. Хотя интерес к разговору у меня уже стремительно падает.

Z>>>Ваши аргументы напомнили мне фанатов процедурного программирования с жаром доказывающих ненужность С++ тем, что классы не нужны, когда есть структуры. Кричащими о сложности автокомплишена в современнных IDE и о том, что С++ никем нормально не поддерживается. О том, что наследование и виртуальные вызовы на С используются от силы в 1% проектов и требуют огромных усилий по поддержке. О том, что код с этими вызовами на С ни черта не понимают люди только что пришедшие в проект и потому такой код бяка.

Кэр>>Правильно. Доказательства по аналогии — это наш метод. Всегда создает такое приятное душевное равновесие. Окружающих убедить удается не всегда — но себя всегда пожалуйста.

Z>Это не доказательства по аналогии, это пример вполне здравых рассуждений доказывающих ненужность конкретной технологии. Хотел обратить внимание на то, что все эти утверждения были абсолютно верны, логичны и обоснованы. Тем не менее не так страшен черт, IDE сделали, грабли научились аккуратно обходить.

Вы здесь приводите исторический пример, затем заменяете одну технологию другой по аналогии и утверждаете, что пример остается валидным. Таким образом можно доказывать необходимость изучения любой новой технологии, которая сейчас не имеет поддержку IDE, но если хорошо вложится — то она появится. Если вы не понимаете, что это доказательство по аналогии — я лучше пойду.

Кэр>>Выдыхайте, то что я лапшу на ушах стараюсь не держать, не означает, что я считаю себя эталоном.
Z>Перенос своего неприятия инструмента на всех именно это и означает.

Я всего лишь изложил то, что я вижу вокруг. Кастомный синтаксис в прикладных задачах — можно встретить очень и очень редко. И на это есть объективные причины, которые я изложил from the top of my head. А у вас сразу пошли обиды — мол я "эталон", и свое "неприятие распространяю на всех". Вы меня лично еще обвините, что я не ценю работу немерлистов и лично торможу прогресс программирования в целом. И типичная картина разработчика компилятора Немерле будет завершена.

Здравствуйте, Воронков Василий, Вы писали:

ВВ>Ну во-первых, особого рефакторинга я в том же Немерле не вижу

Вот у C# есть, Решарпер называется.

Вообще-то тот же рефакторинг переименования есть. И повторить Решарпер вполне можно. Это вопрос наличия сил и времени, а не принципиальный вопрос.

ВВ>Нормальная поддержка ИДЕ — на самом деле для языка с навороченным выводом типов это *сложнейшая* задача.

Глубочайшее заблуждение. Простота реализации IDE больше зависит от качества компилятора и самой IDE. Я не раз ловил себя на мысли, что сделать IDE с нуля проще чем сделать интеграцию к VS.

ВВ>В вашем случае она несколько упрощается, т.к. вы имеете прямой доступ к самому компилятору

А что мешает иметь доступ к компилятору в других языках? Я тебе больше скажу. В шарпе чем дальше тем сложнее будет жить без доступа к компилятору. Так что рано или поздно все прйдет к тому, что компиляторы будут сразу проектироваться не только как утилиты командной строки, но в первую очередь, как компонент рассчитанный на использование в разных задачах. Одной из дача несомненно будет движок интеграции с IDE.

ВВ>Если брать с чистого листа, то создание ИДЕ для динамически-типизированного языка и "языка вроде Немерле" — по сложности где-то близкие задачи.

Несешь несусветную чушь. Полноценная IDE для немерла возможно не потому, что у него нет или есть вывод типов, а потому, что в итоге — это статически-типизированный язык — язык для которого в итоге можно узнать все типы. Это позволяет нам точно утверждать, что имя А в конкретном месте — это метод такого-то класса, или имя такого-то типа. В динамике же, в общем случае, это невозможно. Там где вывод типов возможен, там — да, можно что-то сделать. Но если вывод типов возможен, то мы уже имеем дело не совсем сдинамикой. Точнее совсем не с динамикой.

Как раз все прелести динамики вроде "другой" интерпретации кода (например, обработка вызова не существующего метода), при этом не будут доступны. А если они будут использоваться, то ни о каком интеллисенсе уже говорить не придется.

Так что твои слова не более чем заблуждение (или намеренная лож).

ВВ>И там, и там будет хардкорный вывод типов

Насколько сложна будет ИДЕ с рефакторингом зависит опять же от того, что за динамический язык у нас. Вот для языка вроде Pure задача вполне посильная и сравнивая по сложности с Немерлевской ИДЕ.

Ну, реализуй. У тебя вот есть Ела. Сделй для нее IDE. Погляди что выйдет. А то пока что это все не очень ответственный треп.

ВВ>Ну это даже и неважно. Важно то, что как только разговор переключается на веб, то мы начинаем оперировать чисто количественными критериями — больше телодвижений, меньше. Кардинальных преимуществ-то нет.

Не. Веб мало чем отличается от остального софта. Чем больше проект тем важнее контроль над ним и скорость его выполнения. Тут вот часто приводят в качестве примера разные Фэйсбуки. А я тут давича узнал, что они ПХП в С преобразуют и и уже компилированный код гоняют. Вот тебе и динамика.

ВВ>Вот какой стимул у РОР-иста переходить на nrails? Разве что ради скорости. Ну так РОР медленный потому что он тупо медленный, а не потому что динамика. V8 вон быстрее раз в сорок.

Не он тупо медленный потому что тупо на медленном Руби написан и с применением тупо медленных подходов которые на Руби проще реализовать нежели быстрые.

Многие пишут веб на Яве или Шарпе. Вот для них либа вроде nrails является отличным решением.
Кроме того переход с РоР на nrails даст людям и другие бенефиты: больший контроль над кодом, упрощение рефактринга, возможность исользования линка, интеллисенс (комплит, навигация по коду, ...), и конечно же возможность обеспечить максимальную производительность. Ведь макросы не только предоставляют компилированные решения, но и помогают скрывать некрасивый, но продуктивный код за фасадом простых абстракций.

ВВ>А для ASP.NET MVC программиста преимущества очевидны. Ну так им и не надо доказывать, что динамика лучше статики.

Гы-гы. Как раз надо! Именно им и надо! Те кто использовали РоР знают, что получат. По этому для них вопрос очень прост. Они теряют динамику, но получают другие бенефиты. А вот для шарпокодеров и явщиков все совсем не очевидно. Они ведь в массе своей динамические подходы то и не нюхивали. Даже работая с ЯваСкрипом они умудряются обходиться без мета-программирования. Именно что дизейбля кнопочки на вебе.

ВВ>По-моему все просто.
ВВ>А священная война в стиле "статика + вывод типов + макросы" во всем круче динамики ни к чему не приведет.

А это утверждение ты только что сам придумал. Ziaw всего лишь сказал, что по его наблюдениям того чего можно добиться динамикой можно добиться и статикой + МП. Ну, ты конечно прав в том, что в эту формулу вывод типов не плохо было бы добавить. Но никто не утверждал, что "статика + вывод типов + макросы" круче динамики. Утверждение было более частным. "статика + вывод типов + макросы" ~ "динамике + много тестов". А раз так, то не трудно сделать вывод, что ришения на "статика + вывод типов + макросы" сдерживаются исключительно тем, что сегодня средства разработки для "статика + вывод типов + макросы" банально не развиты. Немерл явные пионер в этой области. Подходы с внешними ДСЛ-ями настолько тяжелы в реализации и поддержке, что даже МС не может предложить ничего путного.

ВВ>Потому что на самом деле не круче. Они разные и для разного. Как бы ни были круты макросы так или иначе вы упретесь в ограничения системы типов, которые в динамике отсутствуют как класс.

Очередную чушь морозишь. Системы типов есть везде. Даже в ассемлере. А уж в динамически-типизированных языках и подавно.

Если ты утверждаешь, что система типов скажем дотнета или немерла утупает Рубийной, то потрудись это обосновать.

ВВ> А в статике изобретаются сложнейшие системы типов, чтобы добиться хоть части этой гибкости.

Системы типов изобретаются для улучшения контроля над кодом. Хаскелисты (не без основания, надо заметить) утверждают, что описание типа во многом определяет реализацию. В этом отношении динамические системы типов — это попытка отсрочить контроль на как можно поздний срок. Это упрощает освоение таких языков, но не несет ничего хорошего проектам, так как снижает контроль над кодом и усложняет обнаружение ошибок (ведь чем позже ошибка выявлена, тем сложнее ее устранить). Именно по этому в динамике ДСЛ-естроение так развито. Ведь ДСЛ-и образуют собственные системы типов которые снижают вероятность ошибки.

ВВ>А для конкретной случае веба — ну реально по фиг динамика там или статика.

Это и есть положительный ответ на вопрос автора темы. По-фиг уже достаточно чтобы признать, что "статика + вывод типов + макросы" позволяет добиться того, чего позволяет добиваться "динамика + тесты".

ВВ>Слишком много переменных, известных только в рантайме, чтобы это что-то решало.

Что же тебя так тянет на откровенно высосанные из пальца утверждения?
Ну, что может быть известно только в рантайме при разработке того же веб-сервера? Ведь ответ очевиден — только данные! А это то как раз не являются проблемой.

Всегда можно сделать так, чтобы все что нужно для проекта было бы известно до рантайма. Задач которые действительно требуют анализа мета-данных в рантайме очень мало. И даже их можно решать путем динамической компиляции.
Так что не надо выдумывать.

ВВ>Я для себя буду выбирать более удобное и последовательное решение, более близкое к моим задачам, а какая там типизация — буду смотреть в последнюю очередь.

Вот с этим можно согласиться. Лично если я буду иметь на руках два решения одинаковых по возможностям, то я предпочту статически-типизированное просто потому, что оно будет более быстрым, комфортным и надежным. А раз мы сошлись на том, что можно достичь возможностей динамике используя связку "статика + вывод типов + макросы", то остается только создать действительно хорошую реализацию.

ЗЫ

Хотя на самом деле убедить окружающих в том, что хорошая реализация действительно хороша будет куда сложнее

Здравствуйте, VladD2, Вы писали:

VD>Вот только они в своих рассуждениях забывают упоминать детали. А детали все портят...
VD>1. Даже выразителности Хаскеля зачастую недостаточно чтобы записывать ДСЛ-и именно в том виде в котором его видя программисты. В итоге в ход идут ужимки. Вместо символов "/" в грамматике начинают использоваться супер-пупер конструкции вида "<@>" и т.п.

Полностью неверно. В нём можно использовать символ /

VD>2. Красивый и легко расширяемый код в большинстве случаев — это медленный код. А быстрый код — это не очень красивый код. Например, красивые выкрутася на хаскеле зачастую связаны с применением ленивости (отложенного вычисления). Но те же ленивые списки частенько очень сильно замедляют код. Скажем для представление строк в хаскеле по умолчанию применяются ленивые списки, но это очень медленно. По этому там же придумали бинарные строки, которые, как я понимаю, являются массивами символов. Но вот уже с ними работать не так здорово.

"Ленивый код — медленный код" — неправда.

1. Явный strictness расставляют при профилировании там, где надо. Обрати внимание — там, где не надо, его не расставляют. Иначе он может, например, снизить производительность.
2. Списки и преобразования над ними как раз частенько транслируются в простые циклы.
3. Почему работать с бинарными строками не так здорово? Паттерн матчингом разбираются, есть функции аналогичные функциям над списками.

Ну, и конечно, главный аргумент — легко расширяемый код (независимо от языка) обычно достаточно быстрый. Надо быстрее — профилируют и правят узкие места. В Haskell, благодаря лёгкости equational reasoning в большинстве случаев не доходит до уродования кода — код остаётся столь же чистым, понятным, легко модифицирумым.

VD>3. Хаскель хорош когда речь идет о написании вычислительного кода. Но для проектирования больших симстем в нем нет ничего акромя возможности вручную эммулировать паттерн "Абстрактный Тип Данных". Соответственно и все выкрутасы с кодом и ДСЛ-ями обычно ограничиваются тем что мы называем уровнем метода.

Это даже не ложь, а глупость. Отсутствие у тебя знаний о функциональном дизайне ты представляешь как отсутсвие функционального дизайна вообще.
Чего не хватает не сказано. Что такое ручное эмулирование — не понимаю.

VD>Не смотря на все эти проблемы отледьные товарищи с огромным удовольствием вешают ярлыки "убогих недоязыков" на те языки которые попросту используют другие типы абстракции. К великому сожалению "недоязыки" делают их любимый хаскель в хвост и гриву.

Во-первых. Описанных тобой проблем нет — они только у тебя в голове.
Во-вторых. Я называл твой любимый Nemerle "убогим недоязыком"?? Вообще-то, он мне скорее нравится.
В-третьих. Про хвост и гриву — перестань уже выдавать свои фантазии за объективную реальность.

VD>Интересно, что авторы Хаскеля намного более трезвы в своих оценках. Их мнение значительно более взвешено. Вот тут есть интервью с одним из авторов Хаскеля где он весьма трезво и разумно говорит об этом языке. С ним трудно не согласиться (в отличии от фанатов). Хаскель, в первую очередь — это полигон (лаборатория) идей. Его главная идея изоляция и явная декларация кода содержащего побочные эффекты. А вот система типов у него переусложненная, но все равно не являющаяся идеальным средством для реализации DSL-ей.

Это же надо так передёргивать!

1. Haskell как лаборатория — это отношение SPJ и это естественно. Никакого "в первую очередь" тут даже нет.
2. "Его главная идея" — полный бред. Почитай уже об истории создания Haskell от того же SPJ. Побочными эффектами, а вернее даже зависимым от этого параллелизмом занимается SPJ. И он там и говорит про себя, а не про Haskell.
3. С переусложнением (по сравнению с лямбдой, а не, например, типизацией .NET!) соглашусь
4. Про идеальное средство никто и не говорил, зачем ты это приплёл?

VD>Если ты утверждаешь, что система типов скажем дотнета или немерла утупает Рубийной, то потрудись это обосновать.

как минимум отсутствует duck-typing

Здравствуйте, VladD2, Вы писали:

L>>>По остальным пунктам, как я понимаю, замечаний нет?

H>>Конечно есть, но уже сколько раз говорилось о них что лень повторять.
VD>Да бесполезно повторять. Хаскель — это религия. Она даже на совершенно очевидные вещи будут смотреть и говорить что не видят разницы.

А какова конечная цель? В чём польза может заключаться?

VD>Вообще, все эти соры совершенно бесполезны именно по той причине, что это реализованные споры.
VD>Освоить обсуждаемые технологии не так просто. На это нужно много времени и сил. А без их освоения получается не боле чем абстрактная философия. Сравнение теплого с мягким.

Есть люди, разбирающиеся и в Haskell и в Nemerle. Думаю, они могут сравнивать эти языки. Я же говорю про то, что знаю — Haskell и макросы (я знаю лисповые и TH, работал с обоими). Этого достаточно, чтобы я мог судить о Haskell и макросах?

Здравствуйте, Воронков Василий, Вы писали:

ВВ>>>Хотя бы потому что с точки зрения любого фреймворка важно не то, как это фреймворк *пишется*, а то, как он используется.
VD>>А тебе действительно не важно то насколько легко фрэймворк пишется и насколько он гладко скрывает все сложности разработки прикладной задачи?

ВВ>Здесь обсуждается не это. Хочешь в очередной раз свести все к своему любимому флейму "макросы вс. мир"?

Ты в очередной раз бросил голословное утверждение (это мягко говоря, на самом деле ложное), так потрудись обосновать его. Иначе твои рассуждения не стоят ничего, так как базируются ложных предпосылках.

ВВ>Не об этом речь. Тема другая. Удобство конечного решения.

Тема то та самая. Динамика выбирается не потому, что на ней есть хоть одно единственное преимущество для конечной системы (сайта, например), а потому, что она удобнее чем, скажем, C# для реализации того самого фрэймворка. И динамика выбирается не какая попало. Скажем я не знаю ни об одном фрэймворке подобном РоР-у созданном на Васике, хотя он с некоторыми опциями тоже очень даже динамичен. Динамика выбирается та что предоставляет мощьные механизмы МП.

Так что это ты от темы пытаешься уйти. Здесь не обсуждаются конченые сайты. Здесь обсуждаются фрэйворки для их разработки. А значит вопросы их реализации.

ВВ>И да, мне *как пользователю* неважно, насколько сильно страдал разработчик при разработке фреймворка.

Но важно, что фрэймворк имеет меньше возможностей. А средства разработки влияют на возможности фрэймворка. Ведь фрэймворк делают люди. А у людей силы ограничены. Значит речь идет не о стараниях, а о производительности труда разработчика и том результате которые при этом получается.

VD>>Тебе не кажется, что если фрэймвор делается на базе более подходящего решения, то и результат получается лучше?

ВВ>Здесь я связи не вижу.

Приплыли. При столь очевидной лжи дальше разговаривать не о чем.

ВВ>Если я использую внешний ДСЛ, почему результат — итоговая библиотека — должна получиться хуже?

По определению. Более подходящее решение позволяет решить задачу проще. А значит:
1. Решить ее быстрее.
2. Решить ее качественнее.
3. Решить более объемную задачу.

ВВ>Ежу понятно, что макросы удобнее рукописного генератора, не об этом речь, но как это влияет на результат

Так же как работа снегоуборочной техники по сравнению с использованием лопаты для снега. Производительность труда выше, халтуры меньше. Это же ведь очевидно! Все что можно чистить снегоуборочной техников (при ее наличии) лучше чистить ею. Это понимают все. Но почему-то большая часть программистов не осознает такой простой истины, что применение более мощных средств разработки точно так же выгоднее.

Так что на твоем месте я бы упирал на то, что хотя динамика и обеспечивает примерно те же возможности, но делает это проще. Это будет конструктивно. Возможно это так и есть на самом дел... пока.

Здравствуйте, hardcase, Вы писали:

L>>Грубо говоря: есть язык, недостаточно выразительный, скажем, C#. И вот мы добавляем к нему систему, позволяющую удобно писать к нему кучу компайлер-плагинов или там препроцессоров. Язык можно сделать жутко красивым и выразительным, расширяя его в нужную сторону таким способом. Это нормально?
H>Да.

А ты видишь недостатки такого подхода? Если да — какие?

Здравствуйте, Воронков Василий, Вы писали:

VD>>Очень советую поработать над логическим выводом, так как такие ошибки не допустимы, на мой взгляд.
VD>>Из сказанного никак не вытекает последнего утверждения.

ВВ>Тебе неудобно пользоваться кодом, которые сгенерирован через студийные билд-провайдеры? С т.з. юзабилити это чем от макросов отличается?

Я не понял как логическая ошибка вообще может быть связана с какими-то утверждениями. Отсюда никакой ответ на твой вопрос не будет иметь смысл.

Еще раз повторюсь. Нельзя делать выводы из несвязанных утверждений. Нельзя по законам логики. Или мы очень далеко уйдем!

ВВ>>>А визуальные DSL-и для многих даже удобнее макросов. А если мне *как пользователю* не видно разницы...

VD>>Визуальные DSL может и хороши но у них есть два недостатка.
VD>>1. Они далеко не для всего применимы. Точнее будет сказать применимы они весьма редко.
VD>>2. Их очень не просто создавать. Фактически DSLTools предоставляет средство только для рисования диаграм. А весь код по анализу кода и генерации оного придется написать самому. Отсюда и такое малое количество тех самых DSL-ей произведенных с его помощью.

ВВ>И одно важное достоинство — они широко используются и, так сказать, насаждаются вендором платформы.

Достоинство до весьма надуманное. Я знаком с двумя DSLTools-DSL-ями. Оба разработаны МС. Оно — это дизайнер классов. Согласен, штука очень удобная и полезная для ОО-проектов. Второй — это дизайнер для WWF (который теперь вроде как просто WF). Вот он на мой взгляд используется не так часто и не так нужен. Но это скорее следствие применимости (странности) самого WF.

Потом я еще раз повторяюсь DSLTools — это библиотеке облегчающая создание визуальных рисовалок. Создание самого DSL она не упрощает! Разработку с использованием DSLTools можно было бы намного упростить, если в качестве бэкэнда использовать макрос-систему аналогичную немерловой (или собственно ее).

ВВ>Люди к ним привыкли. И таки-да, многим удобнее модель набросать в дизайнере, чем делать это макросом.

Покажи мне хотя бы одного человека коорый создал бы свой DSL на базе DSLTools? Так к чему привыкли люди?

VD>>Короче, ты опять теоретизируешь есть только один путь понять почему макросы лучше — попробовать.

ВВ>Еще раз — речь не идет о том, лучше или хуже макросы. Речь об удобстве итогового продукта. Енд-юзеру по фиг — макросы там или внешний ДСЛ. Важен результат.

Еще раз — это демагогия и уход от темы. Лучше средства — лучше и фрэймворк. Лучше фрэймворк — лучше и конечный продукт. Не уже ли это не очевидно?

Здравствуйте, Курилка, Вы писали:

К>Из других вариантов — pyjamas и Lift (правда в последнем скорее обёртки к JS+AJAX+Comet)

Даже для OCaml'а уже пара штук есть http://ocsigen.org/js_of_ocaml/ и http://code.google.com/p/ocamljs/
плюс интерпретатор OCaml байткода на js http://www.pps.jussieu.fr/~canou/obrowser/tutorial/

Здравствуйте, Воронков Василий, Вы писали:

ВВ>Я о другом. Скажем, linq2Sql, использующий "внешний" генератор кода, не менее удобен в использовании, чем аналогичное решение с макросами.

В том-то и дело, что менее! Степень интеграции генератора очень важна!
А еще более авжно, что такой генератор намного проще сделать макросами, а не внешним генератором.
Но по любому, внешних генератор — это тоже мета-программынй подход к решению задачи.

ВВ>Здесь же, мне показалось, не о крутости макросов идет речь, а об удобстве веб-фреймворка.

Не. Здесь речь идет о том, что для создания веб-фрэймворков можно с одинаковым успехом использовать как статику (с МП и выводом типов), так и динамику. И ты это вроде как даже признал.

А удобство конечно же — это многофакторный "продукт". Плюс ко всему прочему еще и субъективный. Кому-то вон копипэст и визарды в АСП.НЭТ.МВЦ нравится.

Здравствуйте, VladD2, Вы писали:

R>>Ну хорошие шаблоны очень близки по возможностям к макросам. Например D'шные вполне позволяют "анализировать компилируемый код" http://www.digitalmars.com/d/2.0/traits.html http://www.digitalmars.com/d/2.0/phobos/std_traits.html

VD>Я только что влез в тему где дишники обсуждали возможности расширения своих "хороших" шаблонов. Точнее шаблоны их вообще мало пригодны для многих вещей. Так что речь шла о их "стринг миксинах".

Cтринг миксины это не шаблоны, это практически текстовые макросы

Как не упирался Вальтер, но макросы давно уже в D пролезли

VD>Вот погляди. Только у дишников все странно. В том числе и интерфейс их конфы. Так что всех сообщений почему-то не видно. Может есть какие-то другие интерфейсы?

Да конфа у них ужас, я раньше через news reader читал, сейчас постоянно не слежу.

Здравствуйте, lomeo, Вы писали:

L>Наоборот! С помощью метапрограммирования такое писать очень сложно. Проще заранее разработать ограниченную систему типов. Писать же на макросах анализ такой сложной и низкоуровневой системы типов, как в .NET, на поиск таких высокоуровненых вещей как чистая функция — гораздо сложнее, чем внести это в язык.

Да, Кэп Очвидность! Реализовывать чистые функции на макрах — не самое разумное проведение времени (хотя я видел таких орлов).

А вот синтаксис для лямбд уже можно и весьма удобно.

L>А! Речь про eDSL? Если взять другие языки, то окажется, что с этим там всё в порядке — ruby, например.

О, да — Кэп! Руби — это отличный динамический язык известный своими возможностями мета-программирования и подмены семантики кода.

L>Или, чтобы было схоже с Nemerle — Scala.

Увы, но нет. Скале в области eDSL с немерлом не тягаться. Даже Хаскель (тот что не теплэйт) в пролете остается.

Руби был отличный пример. И основная разница между Руби и Немерлом как раз в том какими средствами достигаются нужные нам eDSL-ные возможности, и то сколь надежный и быстрый код мы получаем в итоге. И тут если средства Руби весьма хороши, то результат получается мягко говоря не таким хорошим. Все же Руби — это интерпретатор и при том оОчень медленный.

L> Язык не имеет макросов, но писать на нём DSL-и приятно.

Да, ладно. А что же они тогда ХМЛ-литералы в язык встроили?

L>Если всё таки важен синтаксис, то во-первых — почему? Наверное, захочу примеров — мы как-то с VladD2 обсуждали разницу описания грамматики в Parsec и EBNF. Вместо p* пишем many p, вместо a | b, пишем a <|> b.

Ага. И вывод был "а нам (вам) там больше нравится... для нас не принципиально...", хотя любому не предвзятому наблюдателю было очевидно, что грамматика превращается в кашу.

L>Конечно, можно переопределить *, | для того, чтобы синтаксис был схож,

Да? Ну, так зачем дело стало? Используй! За одно сгенерируй хороший алгоритм, а не обходись только комбинаторами.

L>но даже если нет — отличия только в синтаксисе — насколько это важно?

Для ДСЛ-ей то? Очень важно! Для них читаемость и лаконичность — это очень, очень, ОЧЕНЬ важно!

К тому же разница не только в синтаксисе. Разница и в средствах реализации. Хаскель очень крут в области оптимизации функциональных вычислений. Я снимаю шляпу перед тем кто писал его оптимизатор. Де-деревизация — это супер-фича для любого ФЯ! Но черт, побери оптимизаторы не могут превратить плохие алгоритмы в хорошие, и неподходящие для задачи структуры данных в подходящие! А вот макросы могут! Вся муть макроса заключается в том, что от разрываем связь между декларцией задачи и ее реализацией. Скажем мы, если нам понадобится, то мы реализуем в PegGrammar генерацию GLR или LALR(1). И при этом исходная грамматика не изменится.

Так что заявление — макросы сложнее писать может от части и верно, но при этом не стоит забывать, что макросы дают совершенно иной уровень контроля за получаемым кодом.

L>Гораздо важнее в eDSL ведь семантика, как мне кажется.

Важно все. Синтаксис, семантика и реализация. Причем порой последнее выходит на первый план. Скажем сделать на Руби парсер с хорошим синтаксисом и нужной семантикой не так уж и сложно. А вот добиться того, чтобы он демонстрировал приемлемую производительность просто нельзя. Ну, разве что ли сгенерировать на Руби С-код и компильнуть его внешним компилятором, что как ты понимаешь не очень просто.

Для Скалы или Хаскеля все еще сложнее, так как средств МП в них нет вовсе. И все eDSL-естроение сводится к мимикрии обычного кода под DSL. А тут уже полно ограничений и с синтаксисом, и с реализацией. Когда приходится изворачиваться говорить о хороших результатах не приходится. Любой результат становится подвигом.

L>Во-вторых — препроцессоры тоже разные бывают. С удобными разборщиками типа haskell-src-exts или с помощью camlp4 можно очень удобно работать.

Дык, препроцессоры — это уже первый шаг к макросам. Если задача сводится к преобразованию одного синтаксиса в другой, то их в общем-то достаточно.

Но с препроцессорами есть множество проблем. Во-первых, они не могут обращаться к компилятору за информацией. А вынуть информацию из синтаксиса не всегда удается. Во-вторых, они создат проблемы с IDE.

Z>>Любой универсальный язык недостаточно выразителен в каждой специфической области.

L>Не так. "Любой универсальный язык недостаточно выразителен в какой-то специфической области"

Не так. "Любой универсальный язык без макросов недостаточно выразителен в какой-то специфической области"

L>и применение макросов показывает в какой именно.

И применение макросов позволяет устранить недостатки. А показать оно ничего не может, так как если макросы есть, то недостатки устранимы, а если их нет, то применять макры просто не выйдет, а значит и показать ничего нельзя. А то из твоего утверждения следует, что язык без макросов автоматом не имеет недостатков

От:	VladD2	www.nemerle.org
Дата:	20.12.10 17:45
Оценка:

От:	lomeo	http://lomeo.livejournal.com/
Дата:	20.12.10 17:50
Оценка:

От:	hardcase	http://nemerle.org
Дата:	20.12.10 17:58
Оценка:

	От:	Кэр
	Дата:	20.12.10 18:24
	Оценка:

От:	VladD2	www.nemerle.org
Дата:	20.12.10 18:26
Оценка:

От:	DarkGray	http://blog.metatech.ru/post/ogni-razrabotki.aspx
Дата:	20.12.10 18:40
Оценка: