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

EOH>

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

EOH>Увы, практика показывает что код больше читается / поддерживается, нежели пишется.
С этим утверждением никто не спорит. Вот в чём вопрос: ты считаешь, что введение custom syntax затруднит чтение?

Мне вот кажется, что как минимум не всегда. К примеру, читать linq в форме query comprehensions всяко проще, чем те же запросы в форме вызовов функций.
И таких вариантов ещё много. DSL на C — в общем-то, хороший пример. То есть люди всё-таки мучительно рожают новые языки в рамках существующих, и оно окупается — судя по тому, что сетевой стек в FreeBSD таки работает.

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

VD>Да, КО! Для любой сложной задачи нужны подходящие инструменты. И если инструменты сложны, то для их изучения нужно больше усилий. Но без этого сложные задачи не решить.
VD>То же самое происходит и со знаниями. Чем более сложная задача, тем больше базовых знаний нужно для ее понимания и решения.
VD>Причем тут ДСЛ-и и МП? Это же общая проблема сложных задач.
Мы с тобой одинаково мыслим, так что относительно тебя я — КО.
А, вот, Eye of Hell так не думает

IT>Если речь идёт о библиотеке vs. DSL, то тут, конечно, вопрос спорный. Но товарищ утверждал, что он старается ничем таким не пользоваться вообще.

Это про меня? ^_^"

WH>>>А что архитектуре проекта новичков обучать не нужно? А специфичные для проекта библиотеки они тоже знают?
EOH>>Нужно. И этого я тоже стараюсь избегать использую стандартные дизайн, архитектуру и
WH>Стандартную архитектуру? Это какую?
WH>Только давай чтобы она подошла для компилятора, фотошапа, ядра ОС, прошивки микроконтроллера, гуглопоиска,...

А там под области есть. MVC для GUI, threadpool для распределения задач, marhsalling для передачи данных и прочее. А вот когда народ вместо того, чтобы взять QThreadPool пишет свой велосипед потому что "так будет на пять процентов быстрее и расширяемее" — то при условии, что мы не пишем кластер, у нас сразу проблемы.

EOH>>уменьшая количество специфичных библиотек.
WH>Я тоже против велосипедов но жизнь такова что иногда приходится их изобретать.

Ну так я про общий случай, а не про частности. Понятно что для каждого случая мы стараемся применять лучшие инструменты и подходы. Но, ИМХО, в общем случае стандартные подходы более благотворно влияют на поддерживаемость проектов. А добавлять свои DSL на пустом месте — это ой.

EOH>>В разумных пределах конечно. Чего я хочу, это избежать ситуацию когда программист открывает файл проекта и единственная реакция: "А-а-а-а-а-а-а-а! Что ЭТО?!?" .
WH>А я хочу избежать ситуации когда человек вместо файлика на десяток другой килобайт видит мегабайт исходников.
WH>Это вполене реальное отношение Грамматика C# и его препроцессора занимают 44 138 байт.
WH>Сгенерированный код распечатанный преттипринтом занимает 2 334 568 байт.
WH>Ты можешь говорить что хочешь но разобраться с грамматикой на ПЕГе минимум на два порядка проще чем с тем кодом который из нее получается.
WH>Просто по тому что кода на два порядка меньше.

Коллега, как я уже говорил, вы взяли крайне удобный ракурс для обсуждения DSL — написание компиляторов . То, что для написания компилятора DSL — это единственное разумное и естественное решение я не спорю. Но ведь топикстертер наверняка не про разработку компиляторов спрашивал? ^_^. Да и оцените объем задач по разработке компиляторов по отношению к остальным задачам разработки — это, ИМХО, достаточно узкая ниша.

IT>Недавний пример с переходом на FW 4.0. Единственная реакция при переходе на новый ASP была как раз: "А-а-а-а-а-а-а-а! Что ЭТО?!?". Поплыл рендеринг контролов, изменилась модель секьюрити и изменилась логика обработки HTTP реквеста.
IT>Зато наши доморощенные быблиотечки как жужжали, так и жужжат.
IT>В общем, очередной притянутый за уши аргумент.

Если бы ответ на вопрос был бы очевиден, вопрос бы не стоял? ^_^.

А теперь представьте на секунду, что вместо документированного, с книгами/блогами/евангелистами asp.net у вас написанный пять лет назад Васей Пупкиным фреймворк с собственным DSL. Без хорошей документации, с кучей написанного слабыми программистами кода (потому что бюджет нерезиновый, а высококлассных программистов мало и хотят они много) и, что самое обидное — без Васи Пупкина, потому что в Яндекс ушел . Представили? И вам в такой проект нужно нанять двоих человек, потому что бизнес и надо решать задачи.

EOH>>Нужно. И этого я тоже стараюсь избегать использую стандартные дизайн, архитектуру и уменьшая количество специфичных библиотек. В разумных пределах конечно.
VD>Так в чем разница то? Мы же не агитируем за пихание ДСЛ-ей во все дыры? Если ДСЛ упростит реализацию на 5% и будет сложным в изучении, то толку от него скорее всего не будет. Скорее всего будет даже вред.

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

EOH>>Чего я хочу, это избежать ситуацию когда программист открывает файл проекта и единственная реакция: "А-а-а-а-а-а-а-а! Что ЭТО?!?" .
VD>Это ни разу не проблема, если люди делаю свое дело грамотно.

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

VD>А если тебе показать огромное ГУИ-приложение без Qt (и других библиотек) и написанное еще не самым лучшим образом, то ты разберешься в нем быстрее?
VD>Может лучше изучить этот самый Qt и потом уже разобраться в приложении которое будет в разы проще из-за его применения?

Напоминаю свою точку зрения: вместо написания собственных DSL для решения задач, не связанных с разработкой компиляторов, предпочтительнее использовать либо уже существующие библиотеки, которые известны широким нанимаемым массам, либо уже существующие DSL, которые так же известны широким массам. А вот свои DSL за исключением редких случаев лучше, ИМХО, не писать.

VD>Лисп тоже не идеал. Но все же в нем макры работают на уровне АСТ. Это ближе всего к подходу немерла.

Оффтопик. Да, потому что в нем это АСТ — полторы ветки и четыре чахлых листика ;-E~. В tcl то же самое.

EOH>>Код библиотеки поддерживать не надо, если она стандартная. Я — за стандартные библиотеки и против велосипедов ^_^.
VD>Код макро-библиотеки поддерживать не надо, если она стандартная. Я — за стандартные библиотеки и против велосипедов ^_^.
VD>У вас что на работе "Здарова Мир!" пишут? Или весь код вы запихиваете в конечные проекты и доводите его уровень до гипер-говнокода?

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

EOH>>А я рассматриваю все в реальнй жизни. Реальные проекты — это не идеально документированные системы, на 100% покрытые юнит тестами и выглядящие как набор тасков и связанных с ними хорошо документированных коммитов.
VD>Какой-то хреновенький у вас мир. Тестов нет. Кругом говнокод. А чтобы его как-то разгребать рассчитываете на набор детей из индусских школ.

Именно так. Это реалии большинства софтовых проектов, увы. Не всем же делать что-то новое, с нуля и одному . А как только появляется команда из нескольких человек — то все начинает удручающе ухудшаться.

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

Примитивность задач — вопрос очень субъективных. Сетевые протоколы, высоконагруженные сервера, отказоустойчивые системные сервисы — это примитивно? ^_^.

VD>Но что делать тем у кого основная сложность в собственном коде? Что если стандартных библиотек для проекта нет (или они не покрывают значимого объема кода)?
VD>Надо или писать библиотеки самому, или пихать всю сложность в основной код. И тут получается парадокс. Гонясь за простотой и по этой причине боясь использовать ДСЛ вы получаете многократное усложнение решения. Да, в каждой отдельной строке вашего проекта сможет разобраться даже выпускник индусского ПТУ. Но в проекте в целом уже не сможет разобраться и его архитектор.

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

VD>Мы же ведь говорим о реальной жизни, а не о образцово-показательном проекте, так? А в реальной жизни проект в которой напихано много кода очень быстро превращается в ад с точки зрения поддержки.

Для борьбы с этим есть не только DSL. Есть декомпизиция на иерархию слабосвязанных модулей.

VD>Сложность, вот реальная проблема при разработке ПО! И сложность в обучении ДСЛ-ю компенсируется простотой изучения решения сделанного на этом ДСЛ-е. А сложность поддержки ДСЛ-я компенсируется простотой поддержки решения сделанного на этом ДСЛ-е. И наоборот. Экономия на обучении выливается в сложность возникающую из-за роста объемов кода.

Я в курсе. Но вот так получилось, что мой опыт показывает, что с DSL в поддержке сложнее. Видимо, сильно от прикладной области зависит?

EOH>>

EOH>>Есть некая разница между широко распространенным DSL типа rake и тем, что мы сделали сами, нэ?
VD>>>Не. Никакой, если их приходится поддерживать самостоятельно.

EOH>>В том-то и дело, что нам не надо поддерживать самостоятельно популярную библиотеку — за нас это делают другие.
VD>Ну, так в чем разница с библиотеками то? Будут стандартные ДСЛ-и будете их точно так же использовать.
VD>А не будет, будете решать что делать. Писать свою библиотеку или ДСЛ. Тут опять же разницы никакой. А вот разница в результате может быть огромной.

В таком ракурсе может быть. Я больше сравниваю использование стандартных библиотек против собственного DSL ^_^.

VD>Более того, я согласен с тем, что если есть готовая реализация ДСЛ-я, или тем более, фрэймворк вроде рельсов, то глупо писать свой аналог. Но что делать если для задачи такого решения нет? Или есть те же рельсы на Руби, но код надо писать на дотнете или яве? Писать проект полностью в рукопашную? Написать библиотеку и мучиться с ее ограничениями? Или, может быть, все же написать свой фрэймворк?

Вы продолжаете подкидывать очень специфические примеры, где сбственный DSL — это единственное решение. Портирование с рельсов на .net — это не очень частая задача

EOH>>Немерле пока не смотрел. Но мы же говорим про DSL вообще, а не про особо удачную реализацию концепции метапрограммирования? В реальной жизни DSL чаще делают на t4, чем на немерле, увы
VD>Дык проблем в том, что собравшиеся тут люди делятся на два лагеря. Одни уже попробовали (посмотреть мало) Немерл и его МП, а другие судят об МП на основании Т4 и других поделок. Вот и получаются совсем разные выводы.

Убедили, я прочитаю мануал по Немерле .

EOH>>Увы, практика показывает что код больше читается / поддерживается, нежели пишется.
S>С этим утверждением никто не спорит. Вот в чём вопрос: ты считаешь, что введение custom syntax затруднит чтение?

Да нет, читается он замечательно. Только вот если в самом DSL баги, нужно его поддерживать и расширять — то при отсутствии автора это превращается в небольшой филиал ада. Не всегда, конечно, но часто

S>Мне вот кажется, что как минимум не всегда. К примеру, читать linq в форме query comprehensions всяко проще, чем те же запросы в форме вызовов функций.

А теперь попробуйте модифицировать сам LINQ

S>И таких вариантов ещё много. DSL на C — в общем-то, хороший пример. То есть люди всё-таки мучительно рожают новые языки в рамках существующих, и оно окупается — судя по тому, что сетевой стек в FreeBSD таки работает.

Ну, работает много чего. Но многие коммерческие продукты за время жизни переписываются с нуля много раз

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

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

VD>>Да, КО! Для любой сложной задачи нужны подходящие инструменты. И если инструменты сложны, то для их изучения нужно больше усилий. Но без этого сложные задачи не решить.
VD>>То же самое происходит и со знаниями. Чем более сложная задача, тем больше базовых знаний нужно для ее понимания и решения.
VD>>Причем тут ДСЛ-и и МП? Это же общая проблема сложных задач.
0>Мы с тобой одинаково мыслим, так что относительно тебя я — КО.
0>А, вот, Eye of Hell так не думает

Увы. Меня, как программиста с большим стажем конечно очень волнует технологическая сторона вопроса. Трогает судьба Qt и будующее Java. Но как менеджеру мне жизненно необхоимо думать о жизни проектов через полгода, через год, через пять лет. Об изменении хотелок "заказчиков". О том, что будет если вот этот и вон тут программисты завтра уйдут в Яндекс или лягут в больницу. Поэтому в условиях не нишевых задач (напомню, что я занимаюсь коробочными продуктами, в данный момент это radmin) я вынужден выбирать не подходящий инструмент, а инструмент который будет наиболее предсказуемым и который легко смогут использовать другие люди в будующем. Тут, понятное дело, как и везде приходится проводить некую черту, чтобы н скатиться к использованию чистого C и WinAPI . Но проблема выбора технологий — это отдельная песня. Сейчас ведь любую задачу можно решить сотней разных технологий и решений. И невозможно угадать какая более подходящая. Так и работаем -_-.

S>К примеру, читать linq в форме query comprehensions всяко проще, чем те же запросы в форме вызовов функций.

конечно, затрудняет, т.к. добавляет сущности сверх необходимости.
query comprehensions ради решения частной задачи: примитивная обработка коллекции — полностью поменяли синтаксис.
при этом если сравнивать плюсы и минусы, то будет следущее:
вместо точек и запятых пишутся пробелы — вкусовщина
параметры функции пишутся без скобок — есть в этом и хорошее, и плохое,
"стандартные" слова(where,select) пишутся с маленькой буквы, а не с большой — вкусовщина
а добавился только один существенный плюс:
присваивание имени одиночному элементу списка происходит один раз, а не в каждой функции


и соответственно, вместо того чтобы научить стандартный синтаксис такой штуке — в язык тащится чужеродный синтаксис для частной маленькой задаче

зы
если взять код

from cust in customers
    where cust.City == "London"
    orderby cust.Name ascending
    select cust;

то этот код и в нормальном синтаксисе хорошо смотрится, если придумать как переменную cust объявлять только один раз,
и как использовать контекстно-зависимые идентификаторы без необходимости указания полного имени
например, так:

customers
.As(cust*)
.Where(cust.City == "London)
.OrderBy(cust.Name, ascending)
.Select(cust)

ззы
ортогональность — наше всё.
а DSL — это нарушает.

Здравствуйте, DarkGray, Вы писали:
DG>если взять код
DG>

DG>from cust in customers
DG>    where cust.City == "London"
DG>    orderby cust.Name ascending
DG>    select cust;
DG>

DG>то этот код и в нормальном синтаксисе хорошо смотрится, если придумать как переменную cust объявлять только один раз,
DG>и как использовать контекстно-зависимые идентификаторы без необходимости указания полного имени
DG>например, так:
DG>

DG>customers
DG>.As(cust*)
DG>.Where(cust.City == "London)
DG>.OrderBy(cust.Name, ascending)
DG>.Select(cust)
DG>

Это не C#. Это какой-то другой DSL, который явно не лучше, чем query comprehension. Для эксперимента перепиши на честный C#, и тогда станет понятно преимущество нового синтаксиса.

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

EOH>Да нет, читается он замечательно. Только вот если в самом DSL баги, нужно его поддерживать и расширять — то при отсутствии автора это превращается в небольшой филиал ада. Не всегда, конечно, но часто
Как раз в этом-то всё и дело. Код пишется один раз, а читается — много. Поэтому мучительные инвестиции в DSL должны окупиться за счёт того, что потом программы на DSL будет проще читать.

S>>Мне вот кажется, что как минимум не всегда. К примеру, читать linq в форме query comprehensions всяко проще, чем те же запросы в форме вызовов функций.

EOH>А теперь попробуйте модифицировать сам LINQ
Это, имхо, неудачный пример. Linq вшит в компилятор намертво — кстати, и даже с ним народ ухитряется так корёжить семантику, что только ух! У Барта де Смета есть linq to Z3.

EOH>Ну, работает много чего. Но многие коммерческие продукты за время жизни переписываются с нуля много раз

S>Это не C#.

конечно, не c#, там в сообщении об этом написано, если ты конечно его читал.
но это в C# можно было добавить, и было бы намного полезнее, чем херотень с query comprehensions

и соответственно, моя основная мысль:
что менять синтаксис под частные задачи особого смысла не имеет,
и что синтаксис имеет смысл менять глобально, повышая его ортогональность и выразительность.

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

S>Здравствуйте, Eye of Hell, Вы писали:

EOH>>

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

EOH>>Увы, практика показывает что код больше читается / поддерживается, нежели пишется.
S>С этим утверждением никто не спорит. Вот в чём вопрос: ты считаешь, что введение custom syntax затруднит чтение?
Введение произвольной кастомизации синтаксиса — затруднит.

S>Мне вот кажется, что как минимум не всегда. К примеру, читать linq в форме query comprehensions всяко проще, чем те же запросы в форме вызовов функций.
query comprehensions — скорее антипример. Во-первых он основан на дофига проработанной теоретически и практически конепции монад. Во-вторых довольное сильное влияние на query comprehensions произвел не менее проработанный SQL. Несмотря на то что linq дает очень много возможностей это далеко не custom syntax, а хорошо продуманное и теоретически обоснованное расширение языка. Сомневаюсь что средний разработчик сможет такое расширение сделать.

S>И таких вариантов ещё много.
На самом деле очень мало.

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

DG>query comprehensions ради решения частной задачи: примитивная обработка коллекции — полностью поменяли синтаксис.

А ты Rx видел? А Reacive Parsers? А Linq to Z3?

Покажешь где там "примитивная обработка коллекции"?

DG>>query comprehensions ради решения частной задачи: примитивная обработка коллекции — полностью поменяли синтаксис.

G>А ты Rx видел? А Reacive Parsers? А Linq to Z3?

почему там недостаточно обычных extension?

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


DG>>>query comprehensions ради решения частной задачи: примитивная обработка коллекции — полностью поменяли синтаксис.

G>>А ты Rx видел? А Reacive Parsers? А Linq to Z3?

DG>почему там недостаточно обычных extension?
Обычные extension оказываются более многословные и требуют гораздо больше скобочек в записи.
Именно поэтому и придумывают синтаксис для монад, а не используют вызовы методов.

DG>>почему там недостаточно обычных extension?
G>Обычные extension оказываются более многословные и требуют гораздо больше скобочек в записи.
G>Именно поэтому и придумывают синтаксис для монад, а не используют вызовы методов.

что не хватает в C# синтаксисе для того, чтобы работать с монадами так же, как из linq comp?

зы
ответ. не хватает только:
аналогов слов from и let, которые умеют навешивать алиасы с областью видимости до конца statement-а,
автоматической конвертации выражения в лямбду(делегат), если функция объявлена как принимающая лямбду

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

EOH>Увы. Меня, как программиста с большим стажем конечно очень волнует технологическая сторона вопроса. Трогает судьба Qt и будующее Java. Но как менеджеру мне жизненно необхоимо думать о жизни проектов через полгода, через год, через пять лет. Об изменении хотелок "заказчиков". О том, что будет если вот этот и вон тут программисты завтра уйдут в Яндекс или лягут в больницу. Поэтому в условиях не нишевых задач (напомню, что я занимаюсь коробочными продуктами, в данный момент это radmin) я вынужден выбирать не подходящий инструмент, а инструмент который будет наиболее предсказуемым и который легко смогут использовать другие люди в будующем. Тут, понятное дело, как и везде приходится проводить некую черту, чтобы н скатиться к использованию чистого C и WinAPI . Но проблема выбора технологий — это отдельная песня. Сейчас ведь любую задачу можно решить сотней разных технологий и решений. И невозможно угадать какая более подходящая. Так и работаем -_-.
Я думаю, что это не вопрос предсказуемости, а вопрос баланса между стоимостью вхождения и стоимостью разработки и сопровождения. И DSL и фреймворки увеличивают стоимость вхождения, поскольку требуют освоения. Они же дают выгоду — ускоряют разработку и упрощают сопровождение. В какую сторону смещать этот баланс, это вопрос другой. На него нельзя ответить, оставаясь исключительно в технической плоскости, тут я с тобой соглашусь. Например, плохо иметь высокую стоимость вхождения, если компания может позволить себе только студентов, с вытекающими из этого последствиями: низкой квалификацией и высокой текучкой. Но, хочу повториться: мой поинт в том, что принципиальной разницы между DSL и фреймворками в этом смысле нет. Я даже так скажу — DSL это всего лишь более удобный способ представления фреймворка