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


T>>Как быть с теми, чей домен не сильно определен ?
T>>Как быть с теми, которые плохо формализованы ?
T>>Как быть с теми которые затрагивают сразу несколько доменов ?

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

Предполагается что понятия и отношения привезет волшебник в голубом вертолете ?

T>>Импортирую данные которые кастомеры по отрасли хранят в CSV.

O> Куда?

В модель данных.

O> А что такое "полноценный парсер"? Такой, который escape всякие поймет, да кавычки корректно прочитает? Ну так он действительно необходим, тупое решение будет работать до первого же не-тупого CSV от "кастомеров по отрасли" (уж не знаю, кто это такие, но звучит страшно).

Вопрос был — "зачем" ? Не можешь ответить ?

T>> Я вот не смог объяснить, потому там и по сей день string.split.
O> Достаточно показать валидный CSV который этот split сломает. Чего там объяснять-то?

Недостаточно.

T>>Не совсем ясно, как быть с приложением, где встретится сразу пачка разных областей. Где набрать дсл на все случаи жизни ?
O> Те, кто не способен dsl написать, не справятся и с тупым решением задачи, требующей экспертизы в нескольких областях.

Неужели наличие экспертизы в нескольких областях автоматически гарантирует умение дсл и компиляторов ?

T>>А большинство про неё даже не знают.

O> У них огромное преимущество — они не испорчены и не напуганы.

Они просто ничего не хотят знать, при том что уже гарантировано получают очень неплохую ЗП.

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

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

T>>Это и показывает, что материал сложный. Когда материал простой, все студенты его на раз умеют.

O> Неверно. При паршивом преподавании любой материал сложным покажется. А в данном случае вообще нужный материал и не дают, а только грузят абсолютно несущественной ерундой, 100% из которой на практике не пригодится совершенно. То, что пригодится, как раз и не дают.

Не хочешь ли ты сказать, что преподаватели сами не понимают этот материал ?
Откуда тогда возьмется та самая простота ?
И как объяснить тот факт, что преподаватели одни и те же, а одни предметы усваиваются хорошо, а другие — плохо ?

T>>Я и не говорил про матан, но по моему компиляторы это всего лишь часть математики.

O> Так любую хоть немного формализуемую (пусть даже только в бредовых фантазиях формализуемую) отралсь можно обозвать "частью математики".

Так в том то и дело

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

T>>Как быть с теми, чей домен не сильно определен ?
WH>Определить. Твой КО.

А бизнесу сказать: "Ребята, заносите миллионы долларов через пять-десять лет, пока мы всё формализуем и напишем классный DSL"

T>>Как быть с теми, которые плохо формализованы ?
WH>Формализовать. Можно итерациями. Это работает не хуже чем с библиотеками.

T>>Как быть с теми которые затрагивают сразу несколько доменов ?
WH>Чего? У задачи один домен.

Это у тебя так.

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

Где взять DSL на все случаи жизни ? Кто будет семантику реализовывать ?

T>>Импортирую данные которые кастомеры по отрасли хранят в CSV.
WH>Ничего не сказал.
WH>Куда ты их ипортируешь?

Из CSV файлов.

WH>Зачем ты их импортируешь?

Кастомер так хочет. Там его данные. Он хочет с ними работать в нашем приложении.

WH>Не проще ли сказать базе данных, чтобы она их сама импортировала? Они умеют.

Спасибо, ты открыл Америку. Осталось самое малое — вписать эту фичу в конкретные сценарии. Тут окажется, что прежде чем совать файл базе данных, уже нужно залезть в этот файл что бы посмотреть, что там такое. По этой причине мы например отказались от БД в качестве основного парсера CSV


T>>Я видел проекты где решения вроде string.split работали десятками лет. Для чего там полноценный парсер ? Я вот не смог объяснить, потому там и по сей день string.split.
WH>То что ошибка не проявлялась или ее проявления не были замечены не значит что ошибки не было.
WH>И сам такой баг нашол. Код с ошибкой отрабатывал десятки миллионов раз в день в течение нескольких лет.
WH>Но ошибка не проявлялась.
WH>Когда я засунул туда немного не обычные данные, но полностью корректные данные все упало.

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

T>> Ни один бизнес не пойдет на такое решение.
WH>Глупый бизнес. Ибо эти люди очень дорого обходятся. И имеют как правило отрицательный выхлоп.

Ты наверное думаешь, что раз программист двое круче, то и профит у бизнеса будет вдвое больше ? Стоимость разработки <10% от стоимости всех затрат. И часто нужно не просто уметь программировать, но и понимать всю специфику бизнеса. Как правило, второе всегда важнее первого.

T>>Не совсем ясно, как быть с приложением, где встретится сразу пачка разных областей. Где набрать дсл на все случаи жизни ?
WH>Написать. Это просто.

А волшебник в голубом вертолете формализует каждую из областей и реализует семантику ?

T>>А большинство про неё даже не знают.
WH>Нужно учиться. Или ты думаешь, куда ты попал?

Кому ? Для чего ? Вот приходит вчерашний студент на работу, получает сходу ЗП которые выше раз в пять чем средняя по стране.
Откуда у него будет мотив учиться ?

WH>Программист это инженер, а не дворник. Он просто обязан быть хорошо подготовлен.

Люди обычно учатся, что бы чего то добиться, а не просто так, от любви к процессу.
Чего нужно добиваться инженеру ? Квартиру, машину, детей ?
На это хватит той ЗП которую получает молодой специалит, т.е. вчерашний студент, а если он еще пару леваков прихватит, то еще и самолет прикупит.

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

T>>В кратце, люди создают инструментарий для себя
T>>1 орудийный == синтаксис
T>>2 понятийный == семантика

T>>Людие которые в разумные сроки могут п.2 + п.1 настолько мало, что их можно пересчитать по пальцам.

O> Вот как раз это утверждение совершенно не соответствует действительности. Это может любой школьник. Не напрягаясь.

И что же толпы школьников никак не могут выдать внятный DSL для описания вечной проблемы — UI ?

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

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

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

T> И часто нужно не просто уметь программировать, но и понимать всю специфику бизнеса. Как правило, второе всегда важнее первого.

Специфика бизнеса — это и есть domain-specific
Вывод: DSL рулят!

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

T>>>Это и показывает, что материал сложный. Когда материал простой, все студенты его на раз умеют.
WH>>Нет. Это показывает, что студентов учат не правильному материалу.

T>Если так, то это значит, что тема компиляторов сложна даже для преподавателей.

Ну вот зачем говорить глупости с таким упрямством?

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

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

O>> Прелесть подхода с употреблением DSL в том, что плевать на общие случаи, и решать надо всегда лишь примитивные частные задачи. Общее решение, при необходимости, само получится. Потом.

T>А для чего дсл для примитивных частных задач ? их тыщи. ДСЛ нужен там где можно закрыть общий случай.

Неверно. DSL нужны там, где решение с DSL будет проще, понятее не поддерживаемее. Никаких таких "общих случаев" не надо, это совершенно нерелевантная тема.

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

O>> А вот когда html таки появился, я сразу говорил что это чушь, и что все делают заведомо неправильно. Недоумевал, почему вылезло это SGML-отродье и почему забыли про DPS и другие умные технологии. Да что там — latex тот же уже на всю катушку был популярен (и Тим Барнс-Ли его прекрасно знал, как и про DPS). Но все равно родилась фигня, а до хотя бы отдаленно приличного состояния вся эта шелуха не дошла и по сей день.

T>Вот-вот. А сейчас для UI считай ничего лучше html+css вобщем то и нет. А говоришь одного раза достаточно.

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

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

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

T>Предполагается что понятия и отношения привезет волшебник в голубом вертолете ?

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

T>>>Импортирую данные которые кастомеры по отрасли хранят в CSV.

O>> Куда?

T>В модель данных.

Какую модель? В каком виде представленную?

O>> А что такое "полноценный парсер"? Такой, который escape всякие поймет, да кавычки корректно прочитает? Ну так он действительно необходим, тупое решение будет работать до первого же не-тупого CSV от "кастомеров по отрасли" (уж не знаю, кто это такие, но звучит страшно).

T>Вопрос был — "зачем" ? Не можешь ответить ?

Затем, что иначе это не будет поддежкой CSV. Потому как валидный CSV поломает этот "парсер" запросто.

T>>> Я вот не смог объяснить, потому там и по сей день string.split.
O>> Достаточно показать валидный CSV который этот split сломает. Чего там объяснять-то?

T>Недостаточно.

Ну, в таком случае надо всех уволить. С волчьим билетом. Потому что дебилы опасны для общества.

T>>>Не совсем ясно, как быть с приложением, где встретится сразу пачка разных областей. Где набрать дсл на все случаи жизни ?
O>> Те, кто не способен dsl написать, не справятся и с тупым решением задачи, требующей экспертизы в нескольких областях.

T>Неужели наличие экспертизы в нескольких областях автоматически гарантирует умение дсл и компиляторов ?

Да.

O>> У них огромное преимущество — они не испорчены и не напуганы.

T>Они просто ничего не хотят знать, при том что уже гарантировано получают очень неплохую ЗП.

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

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

O>>> Прелесть подхода с употреблением DSL в том, что плевать на общие случаи, и решать надо всегда лишь примитивные частные задачи. Общее решение, при необходимости, само получится. Потом.
T>>А для чего дсл для примитивных частных задач ? их тыщи. ДСЛ нужен там где можно закрыть общий случай.
O> Неверно. DSL нужны там, где решение с DSL будет проще, понятее не поддерживаемее. Никаких таких "общих случаев" не надо, это совершенно нерелевантная тема.

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

O> Еще бы сказали, что языки высокого уровня нужны там, где можно закрыть общий случай, а "примитивные частные задачи" можно и на ассемблере нафигачить.

Если они действительно примитивные — да, это имеет смысл.

T>>Вот-вот. А сейчас для UI считай ничего лучше html+css вобщем то и нет. А говоришь одного раза достаточно.

O> А не надо сравнивать столь сложную тему (UI) с такой примитивной и убогой как разработка и реализация языков.

Наоборот, это разработка и реализация языков — сложная тема на всех уровнях.
А UI в своей базе примитивен до ужаса. Сложность там в основном в оптимизации юзкейсов.

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

O>> Неверно. При паршивом преподавании любой материал сложным покажется. А в данном случае вообще нужный материал и не дают, а только грузят абсолютно несущественной ерундой, 100% из которой на практике не пригодится совершенно. То, что пригодится, как раз и не дают.

T>Не хочешь ли ты сказать, что преподаватели сами не понимают этот материал ?

Да, именно так.

T>Откуда тогда возьмется та самая простота ?

Из жизни, из практики. А преподаватели — это недоумки-теоретики, в основном. Много вы видели в ВУЗах преподавателей с реальным опытом в индустрии? Они не только компиляторов не понимают, они вообще-то ничего не понимают.

T>И как объяснить тот факт, что преподаватели одни и те же, а одни предметы усваиваются хорошо, а другие — плохо ?

Что-то я сомневаюсь в том, что что-то там "хорошо" усваивается с помощью преподавателей. Просто по одним предметам студенты догадываются заниматься самостоятельно, решать практические задачи, а по другим боятся (благодаря недоумкам-преподавателям, конечно же). Посмотрите на выпускников ВУЗов — они ни черта вообще не умеют, если у них не было реальной практики.

T>>>Я и не говорил про матан, но по моему компиляторы это всего лишь часть математики.

O>> Так любую хоть немного формализуемую (пусть даже только в бредовых фантазиях формализуемую) отралсь можно обозвать "частью математики".

T>Так в том то и дело

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

T>>>Как быть с теми, чей домен не сильно определен ?
WH>>Определить. Твой КО.
T>А бизнесу сказать: "Ребята, заносите миллионы долларов через пять-десять лет, пока мы всё формализуем и напишем классный DSL"
А ты что совсем программу не проектируешь?
Бедный бизнес.

T>>>Как быть с теми которые затрагивают сразу несколько доменов ?
WH>>Чего? У задачи один домен.
T>Это у тебя так.
Это всегда так.

T>Где взять DSL на все случаи жизни ? Кто будет семантику реализовывать ?
Часто это проще чем писать библиотеки.

T>>>Импортирую данные которые кастомеры по отрасли хранят в CSV.
WH>>Ничего не сказал.
WH>>Куда ты их ипортируешь?
T>Из CSV файлов.
Ты вообще читаешь?

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

T>Ты наверное думаешь, что раз программист двое круче, то и профит у бизнеса будет вдвое больше ? Стоимость разработки <10% от стоимости всех затрат. И часто нужно не просто уметь программировать, но и понимать всю специфику бизнеса. Как правило, второе всегда важнее первого.
И чем же таким занимается разработчик, что пишет код только 10% своего времени?
Я сколько работаю программистом, у меня на всякие совещания уходит процентов 10 времени.
А остальное исследования (это неучи вообще не могут), проектирование (и это тоже) и кодирование (да и это обычно себе дороже).
У тебя в конторе явно что-то не так.

T>А волшебник в голубом вертолете формализует каждую из областей и реализует семантику ?
А что ты сам не в состоянии?

T>Кому ? Для чего ? Вот приходит вчерашний студент на работу, получает сходу ЗП которые выше раз в пять чем средняя по стране.
T>Откуда у него будет мотив учиться ?
Тех, кто не учиться нужно, отправлять в дворники, а не программистом брать.
Ибо писать они всё равно не смогут.
Проверено.

T>Люди обычно учатся, что бы чего то добиться, а не просто так, от любви к процессу.
Хорошие инженеры учатся всегда. Они просто не могут, не учится. Иначе моментом тупеют и теряют квалификацию.

T>Чего нужно добиваться инженеру ? Квартиру, машину, детей ?
T>На это хватит той ЗП которую получает молодой специалит, т.е. вчерашний студент, а если он еще пару леваков прихватит, то еще и самолет прикупит.
Это я так понимаю, ты про себя говоришь?

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

O>> Вот как раз это утверждение совершенно не соответствует действительности. Это может любой школьник. Не напрягаясь.

T>И что же толпы школьников никак не могут выдать внятный DSL для описания вечной проблемы — UI ?

Программирование UI никогда проблемой не было. Проблема в его дизайне. А тут DSL не помогут.

Кроме того, UI это просто неинтересно. Вот никто и не берется за эту чушь.

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

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

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

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

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

T>>Откуда тогда возьмется та самая простота ?
O> Из жизни, из практики. А преподаватели — это недоумки-теоретики, в основном. Много вы видели в ВУЗах преподавателей с реальным опытом в индустрии? Они не только компиляторов не понимают, они вообще-то ничего не понимают.

Даже если это так для exUSSR и Европы, то уже в США ситуация заметно другая — там традиция использовать для преподавания практиков никогда не прерывалась.
Но и там знают, что разработка языков — дело сложное и неблагодарное: выживает 1 из 1000, в лучшем случае.
Значит, местные традиции ни при чём и незачем гнать на них.

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

_>Там был какой-то практический смысл тащить в рантайм лишнюю сущность или это просто "так реализовали"?
"Так реализовали". Реально, компилировать процесс инициализации объектов не имеет практического смысла. Зачем? Интерпретатор проще.

_>Как раз есть. Изнутри dsl мы чётко видим два вида вызовов: родные вызовы контролов и некий внешний вызов куда-то там.
Как вы их отличаете?

_>Но это уже вне языка (dsl) и только одна реализация, простейшая, которую я бы мог сам с ходу закодировать. А можно же представить себе много других вариантов. Например dsl компилируется непосредственно в последовательности вызовов win api (или же gtk api или же android api, в зависимости от целевой платформы), а наша функция calculate вообще написана на ассемблере и подключается через библиотеку. И это всё будет работать и в одной реализации и в другой, для одного и того же dsl кода.
Не понимаю, зачем вы лезете в такие подробности. Определитесь сначала с тем, какие возможности вы хотите в вашем DSL. Потом можно решать, во что его компилировать, и компилировать ли вообще.

_>Преимущество естественно в простоте и удобстве.
Ничего естественного в этом нет. Предположения о простоте и удобстве надо будет обосновывать, а не просто декларировать.

_>А вообще изначально задача ставилась не про язык для обработчиков, а про отделение "языка интерфейса" (который вбирал бы в себя всё, включая дизайн, логику интерфейса и т.д.) и "языка движка" с удобной связью между ними. Сейчас же в основном присутствуют (не в вебе) варианты разделяющие "язык размётки интерфейса" и "всё остальное".
Я вам намекаю на то, что вы изобретаете ровно то же самое.

_>И как я уже писал, в таком случае, мне даже сам язык размётки как таковой не нужен — полностью хватает визуального генератора, генерирующего системный код.
Я вам уже писал — язык разметки вы всё равно используете. Делать вид, что он вам "не нужен" — это жеманство.

_>Вариант выше с языком размётки, расширенным возможностью написания примитивных (но достаточных для логики интерфейса) обработчиков, — это просто моя первая мысль на эту тему.
Это плохая идея. Объясняю почему: вы, фактически, предлагаете пользователю выбор между написанием одного и того же обработчика на вашем DSL, и написанием того же самого на полноценном host-языке. Велики шансы, что он начнёт с первого, но рано или поздно будет вынужден перейти ко второму. Вообще, это не тот выбор, перед которым стоит ставить разработчика. Желательно, чтобы работал один способ, и он же по совместительству бы был самым очевидным.

_>Пока писал это, пришёл в голову альтернативный вариант. Я вроде уже писал что не исключаю вариант такого dsl реализованый как встроенный в системный язык. Т.е. условно говоря вот у нас сейчас есть визуальный редактор умеющий генерировать C++ (допустим для примера) код.
Чисто для справки: именно такой визуальный редактор вы делать задолбаетесь. По очевидным причинам.
А то, что вы имеете в виду — это 3 (три) разных штуки:
1. DSL описания разметки (который вам "не нужен")
2. Визуальный редактор для этого DSL (кстати, большинству разработчиков не нужен как раз он)
3. Компилятор/конвертер, который по описанию разметки генерирует код инициализации на хост-языке.

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

T>> И часто нужно не просто уметь программировать, но и понимать всю специфику бизнеса. Как правило, второе всегда важнее первого.

K>Специфика бизнеса — это и есть domain-specific
K>Вывод: DSL рулят!

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

Т.е. не бвает универсальных специалистов которые одинаково хорошо строят ДСЛ, решают задачи бизнеса и реализуют программы на своём ДСЛ. Как то так складывается, что архитектор SQL сам не пишет запросы. А те, кто пишут запросы, и те, кто строит дсл, задачи бизнеса понимают плохо, потому им нужен человек из бизнеса, который ставит и учавствует в формализации области.

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

T>>Если так, то это значит, что тема компиляторов сложна даже для преподавателей.

O> Ну вот зачем говорить глупости с таким упрямством?

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

Практика всегда идет впереди теории. Если у теоретиков представление устаревшее, то это потому, что практики еще не накопили нужное количество опыта и не формализовали этот опыт.

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

WH>Есть такое.
WH>http://javascript.crockford.com/tdop/tdop.html
WH>Бред про то, что оно заточено под динамически типизированные языки пропускай мимо ушей.

Спасибо, попробую поиграть с разными реализациями.

O>> Совсем нет? Так не бывает. Но вы меня заинтересовали, попробую узнать про Pratt-а побольше. Есть какие-то ссылки по теме, которые гугл и википедия не дадут?
WH>У меня нельзя делать непрямую левую рекурсию.

У... Это плохо.

WH>Но на практике я даже представить не могу, кому может понадобиться непрямая левая рекурсия в данном алгоритме.

Встречается иногда.

WH>>>Да я не спорю. Но существующие языки тоже нужно разбирать.
O>> К задаче реализации DSL это особого отношения не имеет, к счастью.
WH>Но у меня это требование есть.
WH>Ибо одна из задачь парсить C# и Java.
WH>Чтобы дать людям возможность взять готовый проект и начать добавлять туда макры.

Логично. О расширении того же шарпа я как-то не подумал. Встраивать DSL в привычный шарп, а не в страшный Nemerle — это должно быть весьма удобно и эффективно.

WH>>>Мне хватает скорости, чтобы все распарсить.
O>> Даже если там сто тысяч строк кода?
WH>Nemerle.Peg пару метров в секунду на грамматике C# дает.

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

WH>>>Я это понимаю. И собираюсь сделать язык описания ошибочных ситуаций.
O>> А это не ошибочная ситуация. Это предупреждение.
WH>Тогда видимо я что-то не понял.
WH>Я думал ты про восстановление после ошибок говоришь.

Восстановление это еще более интересная тема. Но я привел в пример warning, таких в Clang очень много. Он тем и хорош, что на всякие синтаксические неоднозначности указывать умеет. И возможно это только благодаря страшному, кривому, рукописному парсеру. Очень быстрому, кстати.

O>> Мне Packrat интересен как раз тем, что его можно и руками делать, без DSLей, без генераторов.
WH>Так там как раз генератор.

Вот и интересно посмотреть, что он генерит.

O>> Семантика то как раз прозрачна, поскольку не далеко ушла от привычной семантики низлежащего языка.
WH>Вот ту не могу согласиться.
WH>Ибо ДСЛ для того и создают чтобы уйти от семантики языка более низкого уровня.

Как правило — да. Но в случае с парсерами это не всегда возможно (см. выше про clang). Тонкости поведения при ошибках декларативно определять пока никто не научился, так что наилучшим решением представляется как раз тоненькая прослойка над низким уровнем — определяем декларативно все, что можно, а где нельзя, там прозрачно скатываемся на низкий уровень. Это не leaky abstraction, это честно, потому как абстракция парсера от низкого уровня сама не далеко ушла.

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

T>>А для чего дсл для примитивных частных задач ? их тыщи. ДСЛ нужен там где можно закрыть общий случай.

O> Неверно. DSL нужны там, где решение с DSL будет проще, понятее не поддерживаемее. Никаких таких "общих случаев" не надо, это совершенно нерелевантная тема.

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

O> Еще бы сказали, что языки высокого уровня нужны там, где можно закрыть общий случай, а "примитивные частные задачи" можно и на ассемблере нафигачить.

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

T>>Вот-вот. А сейчас для UI считай ничего лучше html+css вобщем то и нет. А говоришь одного раза достаточно.

O> А не надо сравнивать столь сложную тему (UI) с такой примитивной и убогой как разработка и реализация языков.

Как ты померил сложность разработки и реализации языков ? Наверняка "у меня получилось и следовательно это просто" ?