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

Z>Очень много чего дает? Ты же не говоришь новичкам, что .should возвращает объект, который имеет свойство .have. Ты им говоришь, что нужно писать точка should точка have, только так и никак иначе. Это ничем не отличается от того, что ты им скажешь, что писать надо пробел should пробел have. Конкретно эта точка — дает тебе лишь иллюзию понимания.

Так можно рассказать вчерашнему выпускнику инъяза который подался в ИТ — вот рецепт, пиши так, менять надо вот так, и то если он не будет заниматься разработкой а максимум будет фиксать готовый код автоматических тестов. И то в этом случае не ясно, что ему придет в голову, т.к. у него возможности английского языка будут гораздо выше shouldJS и ему нужно будет четко понимать, чего может этот shouldJS, а чего нет.
Разработчик, в отличие от гуманитария, решает задачи намного большего масштаба, все это в уме и лазить каждый раз в словарик вербов или доку слишком дорого. Ты может быть так и делаешь, а обычно дев имеет в голове четкое представление модели и сам может хорошо предсказывать, где какие методы-вызовы-возможности могут быть, а где какие не могут.
Соответственно разработчику нужно в обязательном порядке понимать всю вычислительную модель, знать что когда вычисляется, а что когда конфигуриуется, какая модель используется, какие у неё свойства, возможности и тд и тд и тд. То есть, сущности, связи, контракты, инварианты, побочные эффекты, ленивость, энергичность, издержки — это все надо надо держать в уме,т.к. от этого зависит качество решения.
Типичная реакция разработчика на конструкцию DSL .DoWhatever((x) => x + y) — посмотреть, когда вызовется лямбда, и чего будет происходить с данными вплоть до момента появляения на UI или в БД. И здесь ничего не меняется, если DSL вдруг станет другим — DoWhatever x + y. В любом случае нужно разобраться с вычислительной моделью на уровне, достаточном для решения задач с определенным качеством решения.
Теперь очень понятно удивление людей которые первый раз видят Linq — лямбды оказывается вызываются не сразу, а результат никуда не сохраняется. И меня абсолютно не удивляет тот факт, что хорошее знание хотя бы тех же Linq2Objects имеют только кандидаты с опытом от 5 лет в среднем. Остальные, проверено, пишут "по рецепту".

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

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

IT>Таких проектов тысячи. Шаблоны в плюсах, ASP.NET MVC, T4 templates, миллиарды доморещенных кодогенераторов, System.Reflection.Emit, System.Linq.Expressions и построенные на них библиотеки вроде BLToolkit — это всё метапрограммирование.

Это МП в очень урезаном виде, собтсвенно компоненты разработаны большой конторой или имеют широкое коммюнити. Такое МП очень востребовано программистами, т.к. позволяет накапливать опыт как девелоперу, так и команде, фирме так и коммюнити. И это значит, что решение с большой вероятностью поймет другой разработчик.
А вот на счет "миллиарды доморощенных кодогенераторов" я не уверен, что там все гладко с т.з. бизнеса. Например потому что техническая сложность задачи и сложность решения задачи вещи между собой никак не связаные. Добиться что бы сложность решения соответствовала сложности решения да с одного тыка в доморощенном проекте это вобщем сказки, басни, выдумки и тд.
С метапрограммированием вроде T4 все очень просто — посмотрел, как нужно использовать, посмотрел где можно использовать, и с большой вероятностью решение не будет ни провальным, ни заумным.
Зато с самопальными ДСЛ, самопальным метакодом вроде макросов, все ровно наоборот — как правило код пишется такой, что понятен ровно одному человеку, максимум одной тиме. Собтсвенно ровно тоже с обычным фремворком, если девелопер будет писать код от скуки или это будет просто одноразовый код на выброс. Как правило это редкость. А в случае самопального МП это норма, забороть это можно только массированым применением решения и накоплением опыта использования и наблюдения за стоимостью майнтенанса, суппорта и траблшутинга.
Собтсвенно по ДСЛ и макрам ничего такого нет в помине, при этом стоимость суппорта и майнтенанса превышают стоимость стартапа иногда даже на порядки. Теперь, если учесть, что майнтенас и суппорт типично считаются "простыми" задачами, совершенно неочевидно, как сделать их дешовыми если использовано самопальное МП, которое практически всегда требует квалификацию вроде той, которая была у разрабов на стартапе. То есть, — суппортать и майнтейнить ВиаВеб могли только Грехем со товарищи, мультимиллионеры, что им тупо не было интересно. И найти надо было не просто лисперов, а лисперов которые могли поднять тот метакод. Парадокс — если такой лиспр найдется, то с большой вероятностью ему такой проект будет неинтересен, он уже готов, он скорее убежит в другой стартап и может даже станет очередным Грэхемом().

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

IT>А если серьёзно, то есть вещи, в которых, конечно же, должен принимать участие менеджер, а разработчик должен предоставить ему выбор. Например, решение на макросах — условно, месяц, решение без макросов — три. Выбирай, родной.

И опять ни слова про стоимость майнтенанса и суппорта. В большинстве проектов стоимостью стартапа можно пренебречь по сравнению с майнтенансом и суппортом. Это означает примерно следующее — на стартапе можно давать любые ЗП лишь бы проект сделали как надо. А на майнтенасе и суппорте все должно быть максимально предсказуемо, просто и самое главное — дешево. Если есть перспектива 10 лет трахаться с поисхом лисперов, функционалистов то здесь нет ни предсказуемости, ни дешевизны, так как таких специалистов от силы 1-2% от общей массы и ЗП у них часто вдвое втрое выше чем у рядовых девелоперов. С учетом того, что нужно снизить риски связаные с уходом специалиста, брать надо 2-3 человека. Внезапно оказывается, что по рискам и деньгам майнтенас у лисперов, функционалистов выходит намного дороже простых пхп-джавистов-дотнетчиков.

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

T> Зато с самопальными ДСЛ, самопальным метакодом вроде макросов, все ровно наоборот — как правило код пишется такой, что понятен ровно одному человеку, максимум одной тиме...

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

T>И найти надо было не просто лисперов, а лисперов которые могли поднять тот метакод. Парадокс — если такой лиспр найдется, то с большой вероятностью ему такой проект будет неинтересен, он уже готов, он скорее убежит в другой стартап и может даже станет очередным Грэхемом().

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

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

T>И опять ни слова про стоимость майнтенанса и суппорта. В большинстве проектов стоимостью стартапа можно пренебречь по сравнению с майнтенансом и суппортом. Это означает примерно следующее — на стартапе можно давать любые ЗП лишь бы проект сделали как надо. А на майнтенасе и суппорте все должно быть максимально предсказуемо, просто и самое главное — дешево. Если есть перспектива 10 лет трахаться с поисхом лисперов, функционалистов то здесь нет ни предсказуемости, ни дешевизны, так как таких специалистов от силы 1-2% от общей массы и ЗП у них часто вдвое втрое выше чем у рядовых девелоперов. С учетом того, что нужно снизить риски связаные с уходом специалиста, брать надо 2-3 человека. Внезапно оказывается, что по рискам и деньгам майнтенас у лисперов, функционалистов выходит намного дороже простых пхп-джавистов-дотнетчиков.

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

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

То, что делает сейчас команда Немерле, как раз шаг в правильном направлении. Если они в своём порыве не оторвутся от реальной жизни и не улетят в далёкие дали (что порой проявляется), то мы вполне вероятно можем получить пример инструмента, кардинально упрощающего разработку DSL и использование МП.

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

T>Так можно рассказать вчерашнему выпускнику инъяза который подался в ИТ — вот рецепт, пиши так, менять надо вот так, и то если он не будет заниматься разработкой а максимум будет фиксать готовый код автоматических тестов. И то в этом случае не ясно, что ему придет в голову, т.к. у него возможности английского языка будут гораздо выше shouldJS и ему нужно будет четко понимать, чего может этот shouldJS, а чего нет.
T>Разработчик, в отличие от гуманитария, решает задачи намного большего масштаба, все это в уме и лазить каждый раз в словарик вербов или доку слишком дорого. Ты может быть так и делаешь, а обычно дев имеет в голове четкое представление модели и сам может хорошо предсказывать, где какие методы-вызовы-возможности могут быть, а где какие не могут.

Не понял мысль. Ты не показал, чем .should.have для разработчика лучше should have. Вдобавок, зачем то, перешел на личности.

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

Что мешает это делать с DSL?

T>Типичная реакция разработчика на конструкцию DSL .DoWhatever((x) => x + y) — посмотреть, когда вызовется лямбда, и чего будет происходить с данными вплоть до момента появляения на UI или в БД. И здесь ничего не меняется, если DSL вдруг станет другим — DoWhatever x + y. В любом случае нужно разобраться с вычислительной моделью на уровне, достаточном для решения задач с определенным качеством решения.

Именно. И там и там — либо понимать, либо делать заученные вещи по рецептам.

T>Теперь очень понятно удивление людей которые первый раз видят Linq — лямбды оказывается вызываются не сразу, а результат никуда не сохраняется. И меня абсолютно не удивляет тот факт, что хорошее знание хотя бы тех же Linq2Objects имеют только кандидаты с опытом от 5 лет в среднем. Остальные, проверено, пишут "по рецепту".

Еще большее удивление у людей появляется, когда они понимают, что то, что выглядит точно как лямбда, на самом деле ни разу не лямбда и вообще никогда не вызывается. Казалось бы, разработчики должны изгнать эту бесовскую технологию, которая все запутывает и не дает "понимать всю вычислительную модель, знать что когда вычисляется, а что когда конфигуриуется, какая модель используется, какие у неё свойства, возможности". Вот ты лично знаешь все эти вещи про провайдеры linq2x?

Может быть ты легко держишь в голове модель строящегося по экспрешенам запроса? Черта с два, максимум, ты четко понимаешь, какой запрос будет построен в итоге, а чаще всего, вместо знания у тебя наиболее вероятная догадка. Как экспрешены превращаются в SQL в кишках провайдера знают только разработчики этого провайдера. Для всех остальных — it just works.

Вобщем linq отличный контрпример твоей теории, спасибо за подсказку.

IT>На самом деле это всё не проблема. Те кто хотя бы пробовал использовать макросы и DSL это знают. Проблема в другом. На сегодняшний день не существует вменяемых средств для разработки DSL и решений, базирующихся на МП. Их просто нет. Ни одного. Те что есть вменяемыми назвать никак нельзя, т.к. они требуют очень неочевидного шаманства и знаний потрохов компилятора, которые изрядно попахивают сами по себе.

Почему ты выносишь эти проблемы за рамки поддержки и развития? Борьба с этим поднимет цену на поддержку и развитие весьма неиллюзорно.

Тут рядом

Автор: VladD2
Дата: 24.02.13

один из DSL-апологетов в двух подряд сообщениях говорит

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

В Яху тупо решили избавиться от лиспа и переписать все на Труъ языке — С++... Там еще сам язык играет большую роль. Лисп есть лисп. Его не каждый читать может. Но это отдельная история.

Чем этот самый гипотетический Лисп отличается от активно рекламируемых гипотетических DSLей?

Z>Я регулярно сталкиваюсь с подобными, вполне приличными DSL от самоделкиных. Достаточно документированными и понятными, в существование которых истово не верит Мамут.

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

Z>Не понял мысль. Ты не показал, чем .should.have для разработчика лучше should have. Вдобавок, зачем то, перешел на личности.

should.have полностью соответсвует правилам синтаксиса js. Заморочки и возможности этого синтаксиса известны и понятны любому внятному разработчику на JS. Для JS есть множество средств вплоть до браузерных, которые позволяют дебажить это дело, прототипировать «на коленке» (прямо в консоли, с автодополнением) и т.п.

Что у нас есть для "should have"? А нихрена нет
— Каковы правила синтаксиса? Что будет, если я вставлю перенос строки между should и have? Что с кавычками, можно ли использовать "? Есть или нет semicolon insertion? Где описан синтаксис анонимных функций? Да и вообще функций.
— Что с типами данных? Как они соотносятся с типами данных JS?
— Какие средства есть для этого DSL? Дебаггер? Консоль? Интроспекция хоть какая-нибудь?
— Кто автор компилятора, во что это компилируется? Каково качество генерируемого кода? Где в генерируемом коде возможные узкие места по производительности?

Это так, навскидку, в 12 ночи после пива.

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

M>Почему ты выносишь эти проблемы за рамки поддержки и развития? Борьба с этим поднимет цену на поддержку и развитие весьма неиллюзорно.

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

M>Чем этот самый гипотетический Лисп отличается от активно рекламируемых гипотетических DSLей?

В макросах List нет доступа к информации о типах. В результате применение таких макросов сильно ограничено и ценность их примерно на уровне текстуальных подстановок макросов C.

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

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

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

Практически все описанные тут людьми проблемы сводятся к двум вещам: чтобы придумать хороший DSL надо быть гением и это какой-то чертов текст, который непонятно как работает, а не код, с которым легко работать. Правда легкость работы с кодом сильно преувеличивается.

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


Z>>Не понял мысль. Ты не показал, чем .should.have для разработчика лучше should have. Вдобавок, зачем то, перешел на личности.

M>should.have полностью соответсвует правилам синтаксиса js. Заморочки и возможности этого синтаксиса известны и понятны любому внятному разработчику на JS. Для JS есть множество средств вплоть до браузерных, которые позволяют дебажить это дело, прототипировать «на коленке» (прямо в консоли, с автодополнением) и т.п.

M>Что у нас есть для "should have"? А нихрена нет
M>- Каковы правила синтаксиса? Что будет, если я вставлю перенос строки между should и have? Что с кавычками, можно ли использовать "? Есть или нет semicolon insertion? Где описан синтаксис анонимных функций? Да и вообще функций.
M>- Что с типами данных? Как они соотносятся с типами данных JS?

Если язык встраивается в js он будет иметь те же правила и типы, что и js. За исключением языков, которые специально делаются для изменения правил или системы типов.

M>- Какие средства есть для этого DSL? Дебаггер? Консоль? Интроспекция хоть какая-нибудь?

Source maps и любой дебагер который его понимает.

M>- Кто автор компилятора, во что это компилируется? Каково качество генерируемого кода? Где в генерируемом коде возможные узкие места по производительности?

Это вопросы перпендикулярны срезу DSL/код.

M>Это так, навскидку, в 12 ночи после пива.

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

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

IT>Ты так говоришь как-будто у тебя богатейший опыт использования МП и DSL. И весь он при этом сугубо отрицательный. Ты сам когда-нибудь участвовал в таких проектах? Или это всё твои домыслы? Думаю, что второе. Поэтому советую тебе говорить обо всём об этом либо в будущем времени, либо в условном наклонении. Тогда можно будет это обсуждать. А так это всё выглядит как беспочвенные домыслы.

Ты можешь как то внятно обосновать, каким образом единичные самопальные практики станут гарантировано понятными девелоперам попроще ? Ну без намеков на мою квалификацию, но если хочешь, можешь и с намеками, если ничего другого нет.

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

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

Z>Не понял мысль. Ты не показал, чем .should.have для разработчика лучше should have. Вдобавок, зачем то, перешел на личности.

Не понял, где тут переход на личности. should.have это просто JS, вот и все.

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

Z>Что мешает это делать с DSL?

ДСЛ пока что редка практика, потому вопрос надо ставить так — за счет чего это легко делается в случае с ДСЛ.


T>>Теперь очень понятно удивление людей которые первый раз видят Linq — лямбды оказывается вызываются не сразу, а результат никуда не сохраняется. И меня абсолютно не удивляет тот факт, что хорошее знание хотя бы тех же Linq2Objects имеют только кандидаты с опытом от 5 лет в среднем. Остальные, проверено, пишут "по рецепту".

Z>Еще большее удивление у людей появляется, когда они понимают, что то, что выглядит точно как лямбда, на самом деле ни разу не лямбда и вообще никогда не вызывается. Казалось бы, разработчики должны изгнать эту бесовскую технологию, которая все запутывает и не дает "понимать всю вычислительную модель, знать что когда вычисляется, а что когда конфигуриуется, какая модель используется, какие у неё свойства, возможности". Вот ты лично знаешь все эти вещи про провайдеры linq2x?

Чем шире используешь, тем глубже приходится понимать. Что касается деревьев выражений, то это еще один пример ДСЛ, который демонстрирует собственно прелести ДСЛ во всей красе. Получается так, что даже инженеры от Микрософта, которым вроде как положено хорошо понимать что такое ЯП, накосячили с ДСЛ.

Z>Может быть ты легко держишь в голове модель строящегося по экспрешенам запроса? Черта с два, максимум, ты четко понимаешь, какой запрос будет построен в итоге, а чаще всего, вместо знания у тебя наиболее вероятная догадка. Как экспрешены превращаются в SQL в кишках провайдера знают только разработчики этого провайдера. Для всех остальных — it just works.

Как минимум с деревьями выражений нужно работать достаточно свободно. В кишки провайдера может и сложновато лазить, но очень классный код на LInq2EF может запросто оказаться непригодным к использованию. Что бы найти приемлемое решение, надо знать и понимать ограничения EF. С BLT вобщем ровно то же. И качественный DSL поверх всего этого ровно ничего не меняет — просто добавляет новый синтаксис, который нужно задолбить до автоматизма.

Z>Вобщем linq отличный контрпример твоей теории, спасибо за подсказку.

Наоборот. Linq и Деревья выражений показывают, что даже команде разработчиков C# хорошие ДСЛ оказались не под силу.

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

IT>Стоимость сапотра уменьшается в разы. Это я тебе не на основании домыслов говорю, а как человек, проводивший соответсвующие эксперименты на реальных проектах. Элементарная автоматизация кодирования с помощью макросов сокращает в несколько раз код, делает его понятней за счёт декларативности, выявляются и устраняются мелкие баги, которые раньше были незаметны и т.п. Поддержка такого кода тоже элементарна, т.к. не требует детального изучения макросов, а их использование тривиально.

Наверняка если макросы пишутся по некоторым соглашениям, подходам которе вырабатывались десятками раз на других проектах(и потому уже фактически не самопальные, максимум — условно самопальные) и разработкой занимается человек(команда) у которого лет 10 опыта минимум(имеется ввиду фултайм на продакшне и связаная с этим ответсвенность). Я угадал ?
Вот в таком варианте все очень правдоподобно. Теперь, если посмотреть на возраст типичного разработчика, то оказывается что ему ~27 лет, то есть, 5 лет после университета в виде фуллтайма на продакшне, а разрабы от 10 лет и выше составляют всего единицы процентов, от силы десяток, если случится чудо. При этом только они способны писать простой код и вырабатывать подходы-соглашения. То есть, если предположить, что такие разрабы равномерно распределены по всем проектам, окажется что >90% проектов вообще не имеют никаких шансов. Реально же все гораздо хуже — этим десятилетним как правило нужна значительная техническая сложность, что бы был хоть какой то интерес работать. А это значит, что такие опытные разрабы просто кучкуются вокруг интересных им проектов.
А вот в других проектах все немного иначе. Когда молодые девелоперы начинают писать самопальный ДСЛ или изобретать подход к генерации, то кроме дикого ужаса это ничего не вызывает и такие проекты дохнут быстрее чем ты успеваешь о них узнавать.

M>>Почему ты выносишь эти проблемы за рамки поддержки и развития? Борьба с этим поднимет цену на поддержку и развитие весьма неиллюзорно.

IT>Я никуда их не выношу. Я как раз и говорю, что это проблема. Сами по себе DSL и МП вовсе не проблема. Проблема в том, что инструменты для использования, которые мы имеем сейчас в сравнении с тем же ООП находятся примерно на уровне каменного века.

Интересно, что про это тут говорят абсолютно все, кроме, скажем, вульфхаунда, который постоянно верещит про «нада пользавацца правильными инструментами!!одинодин»


M>>Чем этот самый гипотетический Лисп отличается от активно рекламируемых гипотетических DSLей?

IT>В макросах List нет доступа к информации о типах. В результате применение таких макросов сильно ограничено и ценность их примерно на уровне текстуальных подстановок макросов C.

Это не ответ. Откуда возьмется информация о типах в DSL тоже никому неизвестно. Инструменты-то для разработки отсутсвуют

M>>Что у нас есть для "should have"? А нихрена нет
M>>- Каковы правила синтаксиса? Что будет, если я вставлю перенос строки между should и have? Что с кавычками, можно ли использовать "? Есть или нет semicolon insertion? Где описан синтаксис анонимных функций? Да и вообще функций.
M>>- Что с типами данных? Как они соотносятся с типами данных JS?

Z>Если язык встраивается в js он будет иметь те же правила и типы, что и js. За исключением языков, которые специально делаются для изменения правил или системы типов.

Как ты хитро сам себе противоречишь в двух предложениях. Итак, в твоем варианте — что там с типами данных? Они такие же как в js или это все таки исключение?

M>>- Какие средства есть для этого DSL? Дебаггер? Консоль? Интроспекция хоть какая-нибудь?

Z>Source maps и любой дебагер который его понимает.

Которые в природе отсутсвуют.

M>>- Кто автор компилятора, во что это компилируется? Каково качество генерируемого кода? Где в генерируемом коде возможные узкие места по производительности?

Z>Это вопросы перпендикулярны срезу DSL/код.

Ни разу не перпендикулярны. Ярые апологеты DSLя активно пытаются игнорировать эти вопросы.

M>>Это так, навскидку, в 12 ночи после пива.
Z>Навскидку, cucumber довольно неплохо живет, несмотря на наличие всех описанных тобой проблем.

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

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

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

Z>Не только инструменты. Еще не наработаны различные практики, мало литературы и рекомендаций. Но основное, да, инструменты.

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

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

IT>Я никуда их не выношу. Я как раз и говорю, что это проблема. Сами по себе DSL и МП вовсе не проблема. Проблема в том, что инструменты для использования, которые мы имеем сейчас в сравнении с тем же ООП находятся примерно на уровне каменного века.

Сами по себе они обеспечивают довольно высокий уровень вхождения. Инструментами это не забороть. Инструментами можно сделать так, что в некоторых случаях МП можно использовать "по рецепту", типа T4. В общем случае высокий порог вхождения так и остаётся. Радикально снизить этот порог можно только посредством введения МП и ДСЛ в университетскую программу во взрослом виде, а не в виде курсе на 18 часов и три с половиной лабораторных.

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

T>Наоборот. Linq и Деревья выражений показывают, что даже команде разработчиков C# хорошие ДСЛ оказались не под силу.

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