M>>Ага-ага. Потом такой вот гений уволится, а нагенерированый его поделкой говнокод будет вылезать боком в самых неожиданных местах, ага.
VD>А действительно будешь править нагенерированный говнокод, а не код на ДСЛ и кодогенератор? Тогда конечно вылезет боком. Но это как раз об этом в той пословице говорилось — "Заставь дурака богу молиться он лоб расшибет.".
Нет, придется править DSL или кодогенератор. Кто сказал, что это будет просто? Ах, да, Вульфхаунд это сказал, и мы ему все моментально поверили, ага-ага.
VD>В твоем мышлении есть одна ошибка. Ты почему-то не верно оцениваешь сложность поддержки рукописного кода.
VD>Если решения задачи можно сгенерировать по существенно более простой/короткой/ясной модели, то сравнимое по характеристикам рукописаное решение будет несоизмеримо сложно. И поддерживать его будет сложно просто из-за огромного объема кода и неизбежных для такого объема ошибок в проектировании и реализации.
О да, а в DSL не будет ни ошибок проектирования, ни ошибок реализации, ага-ага.
VD>Чем более концептуальная ошибка/изменение, тем сложнее ее устранить/сделать в рукописном коде. В решение же на базе ДСЛ и кодогенерации это не критично, так как изменив код генератора можно устранить ошибку без полного переписывания кода.
Да-да-да. Ведь кодогенераторы написаные гениями без единого коммнетария так легко править!
M>>Почини свой телепатор. Я не верю в то, что все подряд DSLи максимально понятны, абсолютно легки в поддержке, самодокументируемы, мегаэффективны и т.п., как тут заливаете вы с вульфхаундом. WH>Ох. WH>ДСЛ можно сделать более понятным, более простым в поддержке, намного лучше самодокументируемым, и порой на порядки более эффективным, чем код на обычных языках.
Какой ценой? За счет чего? С использованием каких инструментов? Где и когда эти возможности будут и будут ли они вообще? Какова стоимость поддержки этих DSLей, написанный безымянными гениями? Вы же упорно избегаете этих вопросов, продолжая заливать уже опостылевшие сказки про то, что DSL — это мегакруто, мегапросто, мегадоступно, мега... мега... мега...
Пока что реальность никакой мега не показывает (за исключением исчезающе малого количества DSLей, с каждым из которых есть свои дополнительные проблемы).
WH>Мы говорим про существование, а не про всеобщесть. WH>А вы ломитесь в открытую дверь пытаясь доказать что ДСЛ может быть плохим. Но с этим никто не спорит.
Нет, мы указываем на очевидные пробелы в ваших сказках.
Здравствуйте, Mamut, Вы писали:
M>Какой ценой? За счет чего? С использованием каких инструментов? Где и когда эти возможности будут и будут ли они вообще? Какова стоимость поддержки этих DSLей, написанный безымянными гениями? Вы же упорно избегаете этих вопросов, продолжая заливать уже опостылевшие сказки про то, что DSL — это мегакруто, мегапросто, мегадоступно, мега... мега... мега...
M>Пока что реальность никакой мега не показывает (за исключением исчезающе малого количества DSLей, с каждым из которых есть свои дополнительные проблемы).
Да взять хотя бы Nemerle.PEG, попробуй попользоваться им, а потом попробуй напиши аналогичный парсер вручную.
Разговор ведь не о том, чтобы решать любую задачу написанием под неё DSL.
DSL помогает тогда, когда есть некоторое множество переиспользуемых алгоритмов, которые можно выразить в отдельном кратком языке, что значительно упрощает написание и поддержку кода, связанного с этими алгоритмами.
M>>Какой ценой? За счет чего? С использованием каких инструментов? Где и когда эти возможности будут и будут ли они вообще? Какова стоимость поддержки этих DSLей, написанный безымянными гениями? Вы же упорно избегаете этих вопросов, продолжая заливать уже опостылевшие сказки про то, что DSL — это мегакруто, мегапросто, мегадоступно, мега... мега... мега...
M>>Пока что реальность никакой мега не показывает (за исключением исчезающе малого количества DSLей, с каждым из которых есть свои дополнительные проблемы).
I>Да взять хотя бы Nemerle.PEG, попробуй попользоваться им, а потом попробуй напиши аналогичный парсер вручную.
Специально выделил выше.
I>Разговор ведь не о том, чтобы решать любую задачу написанием под неё DSL. I>DSL помогает тогда, когда есть некоторое множество переиспользуемых алгоритмов, которые можно выразить в отдельном кратком языке, что значительно упрощает написание и поддержку кода, связанного с этими алгоритмами.
Кто занимается поиском ошибок в реализации этих DSLей? Их развитием, поддержкой, выявлением проблем с производительностью? Банальным обучением?
1. Ты абсолютно на 100% уверен, что это правильная реализация PEG? Количество тестов для этой реализации равно примерно нулю
2. В случае возникновения ошибок в парсере/генерации кода, сколько времени тебе понадобится найти и изменить ошибку, имея на руках два-три десятка исходников без комментариев и завязанных на неизвестно количество макросов, определенных неизвестно где, и неизвестно, во что разворачивающихся?
Автор этого добра написал это добро, которое, цитирую «может генерировать любой говнокод с нарушением всех правил хорошего тона результирующего языка, за нарушение которых при ручной работе нужно отрывать руки», и уволился из компании. Через два дня это добро начало вылезать боком изо всех щелей. Что будешь делать? Продолжать вещать сказки про «ах-ах-ах, все так прекрасно»?
ЗЫ. Не надо считать, что я против DSL, как класса. Я и PEG пользуюсь и, скажем, SQL'ем или каким-нибудь гремлином с cypher'ом. Вот только не надо рассказывать ничем не подкрепленные сказки про мега...мега...мега... DSLей.
Здравствуйте, Mamut, Вы писали:
I>>Да взять хотя бы Nemerle.PEG
M>Да, взять бы. https://github.com/rsdn/nemerle/tree/master/snippets/peg-parser
M>1. Ты абсолютно на 100% уверен, что это правильная реализация PEG? Количество тестов для этой реализации равно примерно нулю M>2. В случае возникновения ошибок в парсере/генерации кода, сколько времени тебе понадобится найти и изменить ошибку, имея на руках два-три десятка исходников без комментариев и завязанных на неизвестно количество макросов, определенных неизвестно где, и неизвестно, во что разворачивающихся?
M>Автор этого добра написал это добро, которое, цитирую «может генерировать любой говнокод с нарушением всех правил хорошего тона результирующего языка, за нарушение которых при ручной работе нужно отрывать руки», и уволился из компании. Через два дня это добро начало вылезать боком изо всех щелей. Что будешь делать? Продолжать вещать сказки про «ах-ах-ах, все так прекрасно»?
M>ЗЫ. Не надо считать, что я против DSL, как класса. Я и PEG пользуюсь и, скажем, SQL'ем или каким-нибудь гремлином с cypher'ом. Вот только не надо рассказывать ничем не подкрепленные сказки про мега...мега...мега... DSLей.
Если бы не было этого самого ПЕГ'а, я бы просто не решился написать некоторые вещи, которые я написал. Никаких серъёзных проблем я за ним не заметил, но это темы и не касается, так как такой же аргумент можно предъявить и разработчику обычной библиотеки.
Главное, что есть инструмент, которым удобно пользоваться именно в виде отдельного синтаксиса. Без этого инструмента разработка усложняется, с ним упрощается, причём значительно. Что ещё надо?
Опять же, тут часто проскакивает фраза "что делать, если чувак уволился". Попробуй посмотреть на это со стороны разработчика библиотек. На каждый ли проект нужно писать отдельную библиотеку? Что делать, если разработчик библиотеки уволился?
DSL удобен тогда, когда его можно переиспользовать во многих местах и когда он значительно сокращает количество boilerplate кода.
Здравствуйте, Mamut, Вы писали:
M>Кто занимается поиском ошибок в реализации этих DSLей? Их развитием, поддержкой, выявлением проблем с производительностью? Банальным обучением?
Кто занимается поиском ошибок в реализации библиотек? Их развитием, поддержкой, выявлением проблем с производительностью? Банальным обучением?
Неужели использоние библиотеки настолько проще, чем использование DSL? Там и там придётся читать вводную статью и полистать примеры. Количество знаний в обоих случаях практически одинаково. Только DSL помимо функционала, предлагает сокращённый синтаксис, для того, чтобы повысить выразительность кода.
Здравствуйте, Tanker, Вы писали:
WH>>Тот код, который получается в результате переписывания, вообще никого не волнует. T>Он что, сам пишется и сам выполняется и сам же отлаживается ?
Ну да. Один раз написал ДСЛ, а дальше всё само.
Или хочешь сказать, тебя волнует тот машинный код, который получается в результате работы компилятора твоего любимого языка программирования? Я думаю, 99.999% программистов туда по делу ни разу не заглядывали.
WH>>А всё по тому, что генерируемый код не требует поддержки. T>Это слишком сильное утверждение.
Это факт.
... << RSDN@Home 1.2.0 alpha 5 rev. 62>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Re[37]: А при чем тут DSL? (в продолжении темы о языках общего назначения)
Здравствуйте, Tanker, Вы писали:
T>Это смотря какие требования. Как только доходит дело до взаимодействия, как во всех функциональных языках появляется эмуляция ООП. Если тебе придет в голову написать на хаскеле хотя бы полноценный richedit, сразу станет ясно, что к чему.
Вот сам и попробуй. Если делать нормальный для хаскеля дизайн, то он не будет иметь ничего общего с ООП. Совсем.
Хотя конечно есть мастера, которые на любом языке пишут как на фортране.
... << RSDN@Home 1.2.0 alpha 5 rev. 62>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Re[39]: А при чем тут DSL? (в продолжении темы о языках общего назначения)
Здравствуйте, Tanker, Вы писали:
T>Реши ту же самую задачу в терминах хоть ФЯ, хоть макров, хоть мега-дсл и перед тобой встанут те же самые проблемы.
Не встанут. Уж точно не те же.
T>При этом задача проектирования взаимодействия на порядок сложнее.
Взаимодействия чего?
T>Это не важно. Нормальный дизайн в какой нибудь большой области хорошо если получится родить за пару-тройку лет. За такое время можно выразить в С# чуть не любое решение.
Нормальный дизайн для C#.
T>>>А что с чем сравнивать ? Вот если представить твой пример в виде ДСЛ, то получится например так, минимальный набор WH>>Отставить изобретать другие языки. T>А можно я буду лучше знать, о чем же я говорил ?
Ты уходил от ответа.
T>Инверсия предполагает два варианта, один до, другой — после. Я показал тебе второй вариант, как сделать инверсию управления с помощью дсл и это именно то о чем я говорил изначально.
ДСЛ это прежде всего язык.
Если ты считаешь, что один язык инвертирует управление, то почему ты считаешь, что другой не инвертирует?
T>Не фатально. Когда они не видят код решения основной задачи, они вообще ничего не могут сделать. А это уже фатально.
Хватит эту глупость повторять. Re[6]: Способно ли метапрограммирование заменить отдельные я
Там пример код на ДСЛ и то во что он разворачивается.
Возьми двух студентов и попроси одного поправить первый вариант, а другого второй.
Например, набор ключевых слов изменить.
T>Это общий случай МП, я так понимаю ?
Что значит общий? Вполне конкретный.
T>Ну и предполагается, что студент, который пишет на С#, внезапно каким то чудом поймет такие вещи ?
То во что этот код разворачивается, он совершенно точно не поймёт. Никогда. См пример выше. Там про немного другой он очень похожий ДСЛ.
T>>>Даже с шаблонами, квазицитированием не все гладко — вместо того, что бы "посмотреть" нужно дополнять код из некоторого контекста. Соотственно продуктивность с МП у студентов много хуже чем без МП. WH>>Проверял? T>А как же.
Расскажи.
... << RSDN@Home 1.2.0 alpha 5 rev. 62>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Re[40]: А при чем тут DSL? (в продолжении темы о языках общего назначения)
Здравствуйте, Tanker, Вы писали:
T>Сложность построения дизайна настолько высока, что сложностью используемой парадигмы можно пренебречь,
Нельзя. Пока ты не поймешь, что парадигма определяет дизайн, ты не поймешь то о чём разговор.
T>Это заблуждение. Максимум продуктивности только на одном единственном языке, ну может двух.
Это не правда.
T>Как ты понимаешь, выбирается тот вариант, который заапрувит бизнес.
Бизнес ничего не утверждает. Ибо бизнес ничего в этом не понимает. Бизнес нанимает инженеров, которые решают.
И когда бизнес нанимает плохих инженеров, которым лень понять, как работает ДСЛ, проект загибается.
Привет Яха... Они наняли плохих инженеров, которые не хотели учить лисп.
В результате вместо N усилий на поддержку они затратили 1000N усилий на переписывание и потом начали тратить 10N усилий на поддержку.
В результате проект из лидера скатился в УГ. И сейчас Яха его даже продать не может.
T>Мулька сбоку как правило оказывается проще, чем хотя бы разобраться в ДСЛ. Потому до того, как ДСЛ полностью выдохнется, он обрастет вагоном хаков, костылей и подпорок к этим костылям.
Мулька с боку проще только когда у тебя мегатонны рукописного кода.
Те если у тебя 10 метров кода. И тебе через все методы нужно протащить новый параметр.
То в случае с рукописным кодом ты будешь делать подпорки.
А если этот код получается в результате работы генератора, то тебе для этого придется поправить несколько строк в генераторе.
Место в генераторе, как правило, очень легко ищется при помощи полнотекстового поиска.
... << RSDN@Home 1.2.0 alpha 5 rev. 62>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Re[41]: А при чем тут DSL? (в продолжении темы о языках общего назначения)
Здравствуйте, WolfHound, Вы писали:
T>>Сложность построения дизайна настолько высока, что сложностью используемой парадигмы можно пренебречь, WH>Нельзя. Пока ты не поймешь, что парадигма определяет дизайн, ты не поймешь то о чём разговор.
А еще сильнее дизайн определяет задача которую надо решить, требования и ограничения.
T>>Это заблуждение. Максимум продуктивности только на одном единственном языке, ну может двух. WH>Это не правда.
T>>Как ты понимаешь, выбирается тот вариант, который заапрувит бизнес. WH>Бизнес ничего не утверждает. Ибо бизнес ничего в этом не понимает. Бизнес нанимает инженеров, которые решают.
Бизнес утверждает == утверждает специалист на стороне бизнеса. Я думал это очевидно.
WH>И когда бизнес нанимает плохих инженеров, которым лень понять, как работает ДСЛ, проект загибается.
В первую очередь специалист на таких позициях должен понимать доменную область на отлично. И как правило скилы таких инженеров в программировании будут послабее в силу того, что они все время тратят на вполне определенные задачи.
WH>Привет Яха... Они наняли плохих инженеров, которые не хотели учить лисп. WH>В результате вместо N усилий на поддержку они затратили 1000N усилий на переписывание и потом начали тратить 10N усилий на поддержку. WH>В результате проект из лидера скатился в УГ. И сейчас Яха его даже продать не может.
Поделись, откуда у тебя такие цифры и данные ? Надо полагать у тебя инсайдерская информация ?
T>>Мулька сбоку как правило оказывается проще, чем хотя бы разобраться в ДСЛ. Потому до того, как ДСЛ полностью выдохнется, он обрастет вагоном хаков, костылей и подпорок к этим костылям. WH>Мулька с боку проще только когда у тебя мегатонны рукописного кода.
Надо полагать освоение ДСЛ занимает секунды, правильно я тебя понимаю ?
WH>А если этот код получается в результате работы генератора, то тебе для этого придется поправить несколько строк в генераторе. WH>Место в генераторе, как правило, очень легко ищется при помощи полнотекстового поиска.
Ну да, секунды на освоение ДСЛ, используемой архитектуры, секунды на изучение всех ограничений и требований. В какой сказке такое ?
The animals went in two by two, hurrah, hurrah...
Re[42]: А при чем тут DSL? (в продолжении темы о языках общего назначения)
Здравствуйте, Tanker, Вы писали:
T>А еще сильнее дизайн определяет задача которую надо решить, требования и ограничения.
Ты просто катастрофически недооцениваешь влияние парадигмы.
T>Бизнес утверждает == утверждает специалист на стороне бизнеса. Я думал это очевидно.
Что за специалист на стороне бизнеса?
Расшифруй пожалуйста.
WH>>И когда бизнес нанимает плохих инженеров, которым лень понять, как работает ДСЛ, проект загибается. T>В первую очередь специалист на таких позициях должен понимать доменную область на отлично. И как правило скилы таких инженеров в программировании будут послабее в силу того, что они все время тратят на вполне определенные задачи.
Что за позиция такая волшебная. Проясни.
T>Поделись, откуда у тебя такие цифры и данные ? Надо полагать у тебя инсайдерская информация ?
Цифры я наблюдаю на реальных проектах.
А про то, что яха этот проект попыталась продать, и никто не позарился в интернете написано.
WH>>Мулька с боку проще только когда у тебя мегатонны рукописного кода. T>Надо полагать освоение ДСЛ занимает секунды, правильно я тебя понимаю ?
Ну, зачем же так передергивать.
Не секунды. Но минимум на порядок меньше чем мегатонны рукопашного кода.
T>Ну да, секунды на освоение ДСЛ, используемой архитектуры, секунды на изучение всех ограничений и требований. В какой сказке такое ?
Ну, про секунды это ты придумал и теперь споришь.
Но то, что ДСЛ изучить на порядки проще это факт.
... << RSDN@Home 1.2.0 alpha 5 rev. 62>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Re[40]: А при чем тут DSL? (в продолжении темы о языках общего назначения)
Здравствуйте, WolfHound, Вы писали:
T>>Реши ту же самую задачу в терминах хоть ФЯ, хоть макров, хоть мега-дсл и перед тобой встанут те же самые проблемы. WH>Не встанут. Уж точно не те же.
Именно те же и встанут. Возьми любую задачу, которую мусолят в ООП форумах и реши на чем угодно , немерле, макры, хаскель, лисп. Хочешь сравнивать дизайны одной и той же задачи в разных языках — реши задачу типичную для ООП в C# на хаскеле том же. Ну вот ричэдит полноценный напиши или хотя бы почтовый клиент.
T>>Это не важно. Нормальный дизайн в какой нибудь большой области хорошо если получится родить за пару-тройку лет. За такое время можно выразить в С# чуть не любое решение. WH>Нормальный дизайн для C#.
Это не важно.
T>>>>А что с чем сравнивать ? Вот если представить твой пример в виде ДСЛ, то получится например так, минимальный набор WH>>>Отставить изобретать другие языки. T>>А можно я буду лучше знать, о чем же я говорил ? WH>Ты уходил от ответа.
Я показал тебе именно то, о чем говорил изначально.
T>>Инверсия предполагает два варианта, один до, другой — после. Я показал тебе второй вариант, как сделать инверсию управления с помощью дсл и это именно то о чем я говорил изначально. WH>ДСЛ это прежде всего язык. WH>Если ты считаешь, что один язык инвертирует управление, то почему ты считаешь, что другой не инвертирует?
Давно опохмелялся ? Я тебе сказал, что пример твой невалидный, неполный, некорректный. Не надо фантазировать без повода.
T>>Не фатально. Когда они не видят код решения основной задачи, они вообще ничего не могут сделать. А это уже фатально. WH>Хватит эту глупость повторять. WH>Re[6]: Способно ли метапрограммирование заменить отдельные я
WH>Там пример код на ДСЛ и то во что он разворачивается. WH>Возьми двух студентов и попроси одного поправить первый вариант, а другого второй. WH>Например, набор ключевых слов изменить.
Это некорректный пример. В этой области уже давно используется метапрограммирование, наверное лет 50. А ты попробуй таки показать перформанс в инвентаризации, страховании, кредитовании и тд и тд и тд. Сразу скажу — ты быстро сдуешься. Потому что здесь за тебя уже давно формализовали все что только можно, только оптимизации и модификации перебирай. А вот в инвентаризации все очень непросто и она никогда не будет формализована.
Кроме того, типичные задачи это не набор ключевых слов изменить, а изыскать например баг в связывании. N сценариев работает хорошо, N+1 выдает погрешность. Все, приехали, это задачка уже не для студента, потому что надо знать как работает конкретный ДСЛ изнутри.
T>>Это общий случай МП, я так понимаю ? WH>Что значит общий? Вполне конкретный.
Значит не интересно.
T>>Ну и предполагается, что студент, который пишет на С#, внезапно каким то чудом поймет такие вещи ? WH>То во что этот код разворачивается, он совершенно точно не поймёт. Никогда. См пример выше. Там про немного другой он очень похожий ДСЛ.
Опаньки. А как ты собираешься специалистов готовить ? Это все равно что сказать, что разработчики gcc не понимают, во что же код разворачивается.
T>>А как же. WH>Расскажи.
Уже рассказал, читай внимательнее.
The animals went in two by two, hurrah, hurrah...
Re[38]: А при чем тут DSL? (в продолжении темы о языках общего назначения)
Здравствуйте, WolfHound, Вы писали:
WH>Вот сам и попробуй. Если делать нормальный для хаскеля дизайн, то он не будет иметь ничего общего с ООП. Совсем.
На хаскеле никто в своем уме не пробует решать такие задачи, за которые берутся плюсовики, джависты или дотнетчики. Покажи полноценный ричэдит на хаскеле, сразу будет ясно, что к чему.
The animals went in two by two, hurrah, hurrah...
Re[41]: А при чем тут DSL? (в продолжении темы о языках общего назначения)
Здравствуйте, WolfHound, Вы писали:
T>>Он что, сам пишется и сам выполняется и сам же отлаживается ? WH>Ну да. Один раз написал ДСЛ, а дальше всё само. WH>Или хочешь сказать, тебя волнует тот машинный код, который получается в результате работы компилятора твоего любимого языка программирования? Я думаю, 99.999% программистов туда по делу ни разу не заглядывали.
Меня волнуют все особенности, свойства, сайдэффекты, расход памяти, перформанс и тд и тд и тд. Ты лучше выпусти какой нибудь Uber-продукт кроме фремворка-компилятора, а то одни обещания, что все буедт красиво.
WH>>>А всё по тому, что генерируемый код не требует поддержки. T>>Это слишком сильное утверждение. WH>Это факт.
Это просто глупость, потому что никто не предлагает фиксить руками генереный код. Тем не менее баги там бывают и фиксить их нужно. Сложность фиксов на порядок выше сложности фиксов простого рукописного кода.
The animals went in two by two, hurrah, hurrah...
Re[43]: А при чем тут DSL? (в продолжении темы о языках общего назначения)
Здравствуйте, WolfHound, Вы писали:
T>>А еще сильнее дизайн определяет задача которую надо решить, требования и ограничения. WH>Ты просто катастрофически недооцениваешь влияние парадигмы.
Ты просто давным давно вариешься в той теме, которая уже формализована по самое "не могу". Выйди в бизнес-приложения, да покажи нормальный дсл, что нибудь внятное, не пермишны и не конечные автоматы.
T>>Бизнес утверждает == утверждает специалист на стороне бизнеса. Я думал это очевидно. WH>Что за специалист на стороне бизнеса? WH>Расшифруй пожалуйста.
Очень просто. Бизнес нанимает специалиста который 1 будет понимать и достигать цели бизнеса 2 понимает специфику бизнеса 3 понимает разработку и может ею управлять
Этот специалист и будет аппрувать предложения девелоперов. С точки зрения бизнеса мелкий хак который уже завтра можно отрелизить, то есть, тупо фактически технический долг на ровном месте, очень выгоден, потому что выплатить этот долг можно будет самыми разными вариантами. А если ты захочешь пофиксать ДСЛ, то это уже не получится просто так, надо 1 разобраться 2 убедиться что нет влияний на другие модули ,т.к. дсл применяется тотально 3 провести через все фазы релиза. И вот с точки зрения бизнеса это уже очень не гибко, т.к. компенсировать это время скорее всего просто так не получится.
WH>>>И когда бизнес нанимает плохих инженеров, которым лень понять, как работает ДСЛ, проект загибается. T>>В первую очередь специалист на таких позициях должен понимать доменную область на отлично. И как правило скилы таких инженеров в программировании будут послабее в силу того, что они все время тратят на вполне определенные задачи. WH>Что за позиция такая волшебная. Проясни.
См выше. Для бизнеса в первую очередь важно что бы разработка была предсказуемой. Зависимость от высококвалифицированых специалистов это большой риск и никакой предсказуемости не дает, потому что эти спецы имеют обыкновение менять работу, когда им стало скучно.
T>>Поделись, откуда у тебя такие цифры и данные ? Надо полагать у тебя инсайдерская информация ? WH>Цифры я наблюдаю на реальных проектах.
Ты выдал некоторые соотношения касательно стоимости поддержки конкретного проекта в конкретной конторе. Мне интересно знать, откуда эти соотношения взялись.
WH>А про то, что яха этот проект попыталась продать, и никто не позарился в интернете написано.
Это ничего не значит.
WH>>>Мулька с боку проще только когда у тебя мегатонны рукописного кода. T>>Надо полагать освоение ДСЛ занимает секунды, правильно я тебя понимаю ? WH>Ну, зачем же так передергивать. WH>Не секунды. Но минимум на порядок меньше чем мегатонны рукопашного кода.
А "мулька сбоку" это обычно хак в пару строчек-пару страниц кода. Например так — есть парсер, который валится на одном из выражений. "Мулька сбоку" — пропатчить выражения "в лоб" без модификации парсера.
T>>Ну да, секунды на освоение ДСЛ, используемой архитектуры, секунды на изучение всех ограничений и требований. В какой сказке такое ? WH>Ну, про секунды это ты придумал и теперь споришь. WH>Но то, что ДСЛ изучить на порядки проще это факт.
На порядке проче чего ? Когда на проекте меняется команда, то как правило баклог уже такой длины, что некогда заниматься дсл, надо блокеры месяцами фиксить. К тому моменту, как блокеры пофиксятся, твой ДСЛ уже гарантировано будет покрыт костялями и подпорками.
The animals went in two by two, hurrah, hurrah...
Re[22]: А при чем тут DSL? (в продолжении темы о языках общего назначения)
M>>Кто занимается поиском ошибок в реализации этих DSLей? Их развитием, поддержкой, выявлением проблем с производительностью? Банальным обучением?
I>Кто занимается поиском ошибок в реализации библиотек? Их развитием, поддержкой, выявлением проблем с производительностью? Банальным обучением?
I>Неужели использоние библиотеки настолько проще, чем использование DSL? Там и там придётся читать вводную статью и полистать примеры. Количество знаний в обоих случаях практически одинаково.
Да неужели. Тут уже несколько лет апологеты DSL наперебой рассказывают сказки, что нет, вы что, все гораздо легче, быстрее, документируемее. А уж инструменты для разработки!!! (отсутсвующие, естественно).
Любая IDE для худшего из языков С++ даст многокилометровую фору любому инструменту для самого успешного из DSL-ей — SQL'ю, например. Не хочешь пофиксить баги в оптимизаторе SQLя для MySQL, например?
I>Только DSL помимо функционала, предлагает сокращённый синтаксис, для того, чтобы повысить выразительность кода.
Да-да-да. Свежо предание. Справедливо лишь для некоторого количества DSLей, но эти DSLи имеют свои проблемы.
Здравствуйте, Mamut, Вы писали:
M>Нет, придется править DSL или кодогенератор. Кто сказал, что это будет просто? Ах, да, Вульфхаунд это сказал, и мы ему все моментально поверили, ага-ага.
Никто этого и не говорил. Но это будет проще чем править аналогичный генерированному код написанный руками.
Ага. Вот и остальные странно оценивающие сложность люди и постоянно кивающие на дураков работают в этом самом энтерпрайзе. В нем явно что-то не так .
VD>>Если решения задачи можно сгенерировать по существенно более простой/короткой/ясной модели, то сравнимое по характеристикам рукописаное решение будет несоизмеримо сложно. И поддерживать его будет сложно просто из-за огромного объема кода и неизбежных для такого объема ошибок в проектировании и реализации.
M>О да, а в DSL не будет ни ошибок проектирования, ни ошибок реализации, ага-ага.
Это ты опять выдумал. Такого никто не утверждал. Не будет непреодолимой сложности в поддержке. А ошибки, конечно же, неизбежны. Вот только чтобы изменить рукопашное решение обычно нужно его переписать чуть меньше чем полностью, а при наличии МП только изменить МП-код. Объем изменений будет не сопоставим. Мы за последние пол года делали это уже раз 10. А вот для кода немерлового компилятора не можем проделать куда меньших изменений из-за того, что код написан вручную.
VD>>Чем более концептуальная ошибка/изменение, тем сложнее ее устранить/сделать в рукописном коде. В решение же на базе ДСЛ и кодогенерации это не критично, так как изменив код генератора можно устранить ошибку без полного переписывания кода.
M>Да-да-да. Ведь кодогенераторы написаные гениями без единого коммнетария так легко править!
Опять выдумываешь. Дело не в том кто написал кодогенерацию, а в том, что объем кода несопоставим. Код годогенертора в десятки или сотни раз меньше генерируемого кода. И что намного важнее между кодом генерирующим код и генерируемым кодом нет зависимостей. Мы просто имеем некоторую модель (выраженную в виде ДСЛ или еще как-то) и генерирующий код. Последний читает модель и генерирует конечный код. В любой момент можно начать генерировать координатор иной код.
В рукописном же решении неменуемо появляется сильная связанность. Одни части системы зависят от других. Код который мог бы быть сформирован автоматически по модели написан вручную и имеет множество частных решений, которые требуют ручного управления при рефакторинге. В сумме это приводит к сильному усложнению глобальных изменений в коде, в плоть до полной их невозможности за приемлемое время.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[42]: А при чем тут DSL? (в продолжении темы о языках общего назначения)
Здравствуйте, IO, Вы писали:
IO>+ при рукописном решении намного больше соблазн пофиксить подпоркой "вот тута, где оно глючит", а не разбираться в глубинных причинах, зачастую в кривости архитектуры, симптом которой проявился в ошибке
IO>а вот в ДСЛ выбора нету — нужно переосмыслить и фиксить на корню
Подпорки можно и генерировать. Но, абсолютно согласен, желания делать подпорки возникает куда реже просто потому, что сделать полноценное решение намного проще.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Вот если представить твой пример в виде ДСЛ, то получится например так, минимальный набор
