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

EOH>С этим я не спорю. Я против того, чтобы Вася вместо использования Qt, PEG или Antlr сел и написал собственное расширение к C++ и потом радостно использовал его, к примеру, для чтения конфиг файлов. Потому что когда он уволится — этот его велоспиед кому-то поддерживать. И будет он, скорее всего, реализован намного хуже чем тот же Boost::Spirit .

А откуда возьмутся эти Qt, PEG, Antlr или Boost::Spirit, если никто не будет создавать нового?

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

Но для массы задач таких решений нет. Чем более специфична задача, тем меньше шансов найти готовое решение.

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

EOH>P.S. И вообще, вы как-то настоятельно клоните к задачам создания парсеров.

Потому что сами этим занимаемся, и потому что это хрестоматийный пример использования ДСЛ-я.

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

ДСЛ есть ДСЛ в любой задаче. Просто грамматики — это очень очевидный пример. А так примеров масса. Те же Рельсы, например.

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

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

О, да КО! Предлагаю больше не повторять эту банальность. Я даже больше скажу, ДСЛ не стоит использовать, если решение с ним и решение без него приблизительно равнозначны.

EOH>А вот свои DSL за исключением редких случаев лучше, ИМХО, не писать.

А вот это утверждение неверно. И убедительных обоснований к нему не приведено. Да и как их привести то к ошибочной позиции?

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

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

Вообще одно то, что вы пишите ГУЙ на С++ уже говорит о том, что средства разработки под задачи вы подбираете, мягко говоря, не очень хорошо. Плюс применимы только в одном случае — когда нужно выжимать из процессора последние биты. Для гуя есть масса куда более подходящих средств.

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

EOH>С этим никто не спорит. Автор интересовался, что в мейнстриме со встраиванием DSL в язык. Я рассказал про проблемы. Понятное дело, что кому надо — те используют. Но в мейнстрим, ИМХО, не пойдет — страшно. Вот посмотрим года через 3-4 что будет с руби в мейнстриме — он как бы под DSL заточен.

Руби и рельсы давно уже в мейнстриме. Подавляющее большинство веб решений выбирают между PHP, Rails, Django, ASP.NET и Java. 5 лет рельсы пережили и пережили неплохо. А самому руби скоро 20 лет будет.

Посмотри на все популярные ruby gems, там сплошное метапрограммирование и DSLи. Не стесняются люди применять метапрограммирование и DSL как в своих проектах, так и использовать чужие.

Кстати, в руби вообще нет защиты от конфликтов, один gem определит свой String.to_html, другой — свой, средств для борьбы с этим нет вообще. Победит будет подключен последним, и ничего, живут.

Там давно стерлась грань между синтаксисом руби и синтаксисом библиотеки:

class MyClass
  singleton :per => :request
end

Этот код сложно читать и поддерживать? Да я уверен, что его смогут понять люди не знакомые с руби вообще, не то, что с библиотекой которая это реализует. Для этого надо знать паттерн синглтон и немного о вебе. А ведь его семантика не говорит нам ровно ничего что могло бы помочь нам понять, что делает этот вызов.

Давай не будем про формоклепов, вот ты сам, придя на новый проект, что быстрее поймешь, код выше или:

public class MyClass
{
  public MyClass() {} // заметь, конструктор придется оставит публичным, для того, чтобы DI контейнер мог его юзать
  // тут нужно тайное знание, что этот класс нельзя создавать явно, только через DI
}
// плюс еще огромный макаронный конфиг черт знает где, который содержит строчку
container.RegisterType<MyClass>(new HttpContextLifetimeManager());

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

Знаком код?

private MyCoolClass _myCoolClass;
public MyCoolClass MyCoolClass
{
  get 
  { 
    if (_myCoolClass == null)
    {
       _myCoolClass = new MyCoolClass();
    }
    return _myCoolClass;
  }
}

Его писал наверное каждый C# программист хоть раз в жизни. В нем есть проблема, про которую не подозревают многие формоклепы, он не является thread safe.

В nemerle это делается так:

public MyCoolClass: MyCoolClass
{
  [Memoize]
  get 
  { 
    MyCoolClass()
  }
}

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

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

VD>>Что-то я не понял. "точко-запятуюшная" пунктуация вроде бы есть и в С++ и в шарпе. Так о чем ты?

R3>Например:
R3>

R3>~
R3>*
R3>&
->>
R3>::
>>>
R3><<
R3>

R3>.NET показал, что это не нужно.

Ничего не понятно. Ты бы лучше показал пример на C# и аналогичный на nemerle, чтобы понять, что конкретно не нравится.

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

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

Ты уверен, что проблема именно в том, что этот фреймворк был с собственным DSL?

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

EOH>Давайте попробую так сформулировать: "написать правильный DSL который был бы правильным как в использовании так и в поддержке сложнее, нежели написать правильную библиотеку. Поэтому мейнстрим за библиотеками".
Это не правда.
Там где ДСЛ уместен ДСЛ сделать проще.

EOH>Я же не против DSL вообще. Понятное дело, что для частного случая можно и нужно использовать то, что для этого частного случая будет лучше. Но если у меня команда 20+ человек и старший программист Вася приползает ко мне со словами "а вот давай я тут DSL вверну, оно понятнее будет" — я не разрешу. Потому что сейчас Вася тут, а завтра в Яндексе. И что он там напишет — непонятно. Пусть лучше кода будет немного больше, зато у проекта через год головной боли будет меньше.
1)Ты в одном абзаце противоречишь сам себе.
2)Вся жизнь состоит из частных случаев.
3)Немного больше кода это во сколько раз? В два? В три? В десять? В сто?

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

EOH>ИМХО не очень удачный пример потому что эксплоитит ту область, в которой DSL must have — создание парсеров. Но ведь парсеры не так часто создаются?
Так у меня еще есть...
http://code.google.com/p/nemerle/source/browse/nemerle/trunk/snippets/Nemerle.Xml/Test/Main.n
http://code.google.com/p/nemerle/source/browse/nemerle/trunk/snippets/ComputationExpressions/Test/AsyncTest.n
http://nemerle.org/wiki/index.php?title=Late_Binding_Macro
И список можно продолжать долго.

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

EOH>А там под области есть. MVC для GUI,
Реактивный MVVM гораздо лучше. Но для него ДСЛ нужен.

EOH>threadpool для распределения задач, marhsalling для передачи данных и прочее. А вот когда народ вместо того, чтобы взять QThreadPool пишет свой велосипед потому что "так будет на пять процентов быстрее и расширяемее" — то при условии, что мы не пишем кластер, у нас сразу проблемы.
К сожелению стандартные вещи не всегда подходят.
Все идет к тому что мне придется написать пул потоков для немерле 2.
Ибо поведение стандартного заточено на IO а у нас много CPU.

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

EOH>А добавлять свои DSL на пустом месте — это ой.
А кто говорит про пустое место?

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

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

EOH>Программирование — оно большое. Я рассматриваю со своей колокольни — создание коммерческих, коробочных продуктов. Тоесть ПО для продажи. А вы для чего DSL использовали? Вольфхаунд, Хардкейс — выскажитесь пожалуйста, дабы сравнить.
ДСЛ создается для удаления из кода паттернов которые по другому не удалить.

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

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

EOH>Да нет, читается он замечательно. Только вот если в самом DSL баги, нужно его поддерживать и расширять — то при отсутствии автора это превращается в небольшой филиал ада. Не всегда, конечно, но часто
Скажем тот же Nemerle.Peg люди правят и без меня.
Может дело в авторе и/или инструментах?

EOH>А теперь попробуйте модифицировать сам LINQ
В немерле 2 такие модификации будут делаться на раз.

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

EOH>>>Чем проще код — чем лучше он переживает ротацию кадров.
IT>>Что в данном случае подразумевается под "проще"?

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

Так не бывает. Примитивными инструментами (включая примитивные мозги) сложные задачи просто решать нельзя. Так что ты где-то лукавишь. Либо у вас несложные задачи, либо всё же требуются усилия и немалые, чтобы поддерживать то, что у вас есть, либо квалификация твоих сотрудников на вполне приличном уровне.

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

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

Найми трёх, а лучше четырёх индусов на зарплату двоих. Заменяемость Вась Пупкиных повысится неимоверно. Любой винтик в команде можно будет без труда заменить таким же тупым. Вот только что они тебе нарешают? К сожалению, к IQ не применима функция сложения, работает только функция Max и 10 индусов с IQ равным 10 никогда не решат качественно задачу, требующую IQ 100.

Z>Руби и рельсы давно уже в мейнстриме. Подавляющее большинство веб решений выбирают между PHP, Rails, Django, ASP.NET и Java. 5 лет рельсы пережили и пережили неплохо. А самому руби скоро 20 лет будет.

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

Z>Посмотри на все популярные ruby gems, там сплошное метапрограммирование и DSLи. Не стесняются люди применять метапрограммирование и DSL как в своих проектах, так и использовать чужие.Кстати, в руби вообще нет защиты от конфликтов, один gem определит свой String.to_html, другой — свой, средств для борьбы с этим нет вообще. Победит будет подключен последним, и ничего, живут.
Там давно стерлась грань между синтаксисом руби и синтаксисом библиотеки:

Вот года через три-четыре и узнаем, хорошо это или плохо

Z>

Z>class MyClass
Z>  singleton :per => :request
Z>end
Z>

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

Это, на мой взгляд, не очень хороший пример — он маленький. Да, ЭТО легко прочесть и, я думаю, нетрудно будет поддерживать. Но в сложном коммерческом проекте хотя бы от миллиона строк исходников DSL будет несколько слоажнее — и тут то проблемы и начнутся.

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

При этом они полностью зависят от тех, кто поддерживает сам DSL. Стоит такому человеку / людям уволиться или заболеть — у нас двадцать формоклеперов с проблемами ^_^.

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

WH>Все идет к тому что мне придется написать пул потоков для немерле 2.
WH>Ибо поведение стандартного заточено на IO а у нас много CPU.

На это смотрел?

EOH>>Давайте попробую так сформулировать: "написать правильный DSL который был бы правильным как в использовании так и в поддержке сложнее, нежели написать правильную библиотеку. Поэтому мейнстрим за библиотеками".
WH>Это не правда.
WH>Там где ДСЛ уместен ДСЛ сделать проще.

Тут, я думаю, никто из нас не сможет аргументировать свою позицию — не думаю, что есть репрезентативная статистика по данному вопросу

EOH>>Я же не против DSL вообще. Понятное дело, что для частного случая можно и нужно использовать то, что для этого частного случая будет лучше. Но если у меня команда 20+ человек и старший программист Вася приползает ко мне со словами "а вот давай я тут DSL вверну, оно понятнее будет" — я не разрешу. Потому что сейчас Вася тут, а завтра в Яндексе. И что он там напишет — непонятно. Пусть лучше кода будет немного больше, зато у проекта через год головной боли будет меньше.
WH>1)Ты в одном абзаце противоречишь сам себе.
WH>2)Вся жизнь состоит из частных случаев.
WH>3)Немного больше кода это во сколько раз? В два? В три? В десять? В сто?

1) Где? O_O
2) Мой опыт показывает, что в разработке можно для большей части случаев выделить много общего.
3) Это зависит от контекста задачи, сами понимаете. В каждом конкретном случае нужно принимать решение. Я — за то, чтобы учитывать проблемы с DSL при поддержке.

EOH>>ИМХО не очень удачный пример потому что эксплоитит ту область, в которой DSL must have — создание парсеров. Но ведь парсеры не так часто создаются?
WH>Так у меня еще есть...
WH>http://code.google.com/p/nemerle/source/browse/nemerle/trunk/snippets/Nemerle.Xml/Test/Main.n
WH>http://code.google.com/p/nemerle/source/browse/nemerle/trunk/snippets/ComputationExpressions/Test/AsyncTest.n
WH>http://nemerle.org/wiki/index.php?title=Late_Binding_Macro
WH>И список можно продолжать долго.

Парсер XML, парсер языка юнит-тестов, и расширение языка. Про первые два я писал. Про расширение языка... Ну пока оно одно — оно безвредно. Когда из будет полторы сотни как в ядре FreeBSD — у нас будут проблемы.

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

IT>На это смотрел?
Влад мне этой байдой все уши прожужал пока я ему с рефлектором на перевес не показал что там происходит на самом деле...

EOH>>Проще — это значет, что после того как автор кода покидает компанию, нанятый на его место сотрудник сравнимой квалификации может без усилий поддерживать и модифицировать этот код.
IT>Так не бывает. Примитивными инструментами (включая примитивные мозги) сложные задачи просто решать нельзя. Так что ты где-то лукавишь. Либо у вас несложные задачи, либо всё же требуются усилия и немалые, чтобы поддерживать то, что у вас есть, либо квалификация твоих сотрудников на вполне приличном уровне.

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

VD>А откуда возьмутся эти Qt, PEG, Antlr или Boost::Spirit, если никто не будет создавать нового?

Новое пусть высококлассные архитекторы создают, которые в этом разбираются.

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

Вы утрируете мою позицию — она не настолько бинарна. Я за то, чтобы в случаях если есть опции, склоняться к не использованию собственного DSL если можно его не использовать. Понятное дело, что если опций нет то и DSL будем использовать, и на бейсике писать, и ядро патчить. Я просто стараюсь избегать таких практик. Почему — уже четвертый день рассказываю. Возможно, я не прав — время покажет

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

Z>Ты уверен, что проблема именно в том, что этот фреймворк был с собственным DSL?

Был бы я уверен — я бы достаточно быстро доказал свою позицию и никто бы тут четыре дня не обсуждал . Не уверен, но практика показывает что без DSL в общем случае попроще поддерживать будет.

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

Соглашусь. Но мне как менеджеру комфортнее работать со средним по рынку. Среднее по рынку Москвы сейчас, увы, довольно низкое. Они и слова то такого "DSL" не знают .

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

Может быть. На личном опыте могу сказать что Qt читается проще чем Rails человеком, который знает C++ и Ruby но не знает соответствующего фреймворка и DSL ^_^.

EOH>>А вот свои DSL за исключением редких случаев лучше, ИМХО, не писать.
VD>А вот это утверждение неверно. И убедительных обоснований к нему не приведено. Да и как их привести то к ошибочной позиции?

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

VD>Свои ДСЛ-и писать можно и нужно. Но как и любой другой код это должно быть: а) действительно необходимо (т.е. давать ощутимые преимущества), б) ДСЛ должен быть тщательно спроектирован и продуман, в) ДСЛ должен быть качественно реализован на подходящих для этого средствах.

а) Программист среднего уровня не сможет понять, когда это действительно необходмо. А на рынке, увы, проще нанять среднего уровня, нежели высокого. Поэтому я стараюсь просто так в руки DSL никому не давать ^_^.
б) Увы, мало кто может тщательно продумать и спроектировать DSL. На мой взгляд, плохо спроектированный DSL страшнее плохо спроектированного кода .
в) Ну и про качественную реализацию я молчу.

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

Конечно. Я же не могу позволить себе нанимать только высококлассных программистов .

VD>Вообще одно то, что вы пишите ГУЙ на С++ уже говорит о том, что средства разработки под задачи вы подбираете, мягко говоря, не очень хорошо. Плюс применимы только в одном случае — когда нужно выжимать из процессора последние биты. Для гуя есть масса куда более подходящих средств.

Увы, у меня нет своей компании чтобы единолично выбирать технологии и решения с нуля. Я работаю за деньги с тем, что дадут