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

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

V>Но это нерационально с точки зрения эгоизма, поэтому лучше сразу назвать технологию говном, а тех кто ее продвигают — недоучками.
V>Не знаю ничего насчет именно языка ДРАКОН, слышал где-то, подумал что это что-то детское,
Это не детское. Это очень похожи на блок схемы которые я изучал в школе. Задания были домашние: нарисовать блок схему такого-то алгоритма. Такие схемы подходят для написания коротких и не очень сложных программ и алгоритмов. Полезны в самом начале изучения программирования. Ну, может и не в самом начале, не в третьем классе, когда ученикам дают задание нарисовать путь черепашки в тетради в клеточку диктуя сколько шагов в какую сторону света сделала черепашка, но где-то после этого...

Теперь смотрим, что пишут

Автор: Владимир Паронджанов
Дата: 24.05.12

счастливые пользователи:

И только когда весь алгоритм «отлизан» — переходим к собственно программированию. В чём оно теперь заключается? В том, что для каждой иконы нужно написать код, который выполнит то, что написано на этой иконе. Как правило это 1 строчка. На высоких уровнях иерархии проекта — это может быть вызов одной функции, или одного метода класса (заметим, что все функции и классы тоже нарисованы на ДРАКОНЕ). На нижнем уровне — это может быть изменение одного бита.

Вот я сейчас подсчитал, в одном небольшом проекте, над которым я работаю сейчас 254845 строчек кода. Ну а теперь представьте себе схему с таким количеством иконок. Как думаете их среда разработки выдержит размер поля в 50400х35280 пикселей? (примерно столько понадобится для отрисовки такого количества иконок)

Ну да, большие программы нужны не везде. Но может ли, к примеру, эта разработка выдавать код на JavaScript ? Сомневаюсь.

Вот что нужно современному программисту здесь

Автор: niXman
Дата: 16.05.12

:

существует ли софт, который умеет эмулировать выполнение некоторого кода в многопоточной среде так, чтоб была возможность задать кол-во потоков/точки_входа, и по финалу, создавать граф вызовов или еще какую-нить диаграмму ?

Нужен язык (визуальный, на иконках), который хорошо и ясно представляет программу, код которой исполняется параллельно. Вот если вы подойдете и попросите какого-нибудь программиста объяснить вам как работает его многопоточная (многониточная) программа, то я почти уверен, что он примется что-то рисовать на бумаге в процессе объяснения... но это будет не Дракон.

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

LVV>Передщергиваете. Я говорил о том, что мы проводили опрос. На предмет в каком виде легче доходит алгоритм.
LVV>И вывод был однозначный: девушки все поголовно воспринимают картинки, то есть схемы.
LVV>А пацаны — в основном псевдокод. Но есть отдельные личности, которым пофигу: одинаково информативным является и псевдокод, и схемы-картинки.
Как быстро Вы сдали назад. Я освежу вашу весьма короткую преподавательскую память вашей первой цитатой:
"Как препод могу сказать, что некоторым студентам и почти всем студенткам гораздо проще посмотреть на картинку алгоритма, чем на текст алгоритма. Для рисования сложных алгоритмов Дракон подходит как нельзя лучше."

LVV>Привет вашей логике... Она даже на женскую не похожа...
У вас не осталось аргументов и вы решили перейти к оскорблениям? Достойное поведение для преподавателя , продолжайте в том же духе . Так вы привлечете просто массы неистовых поклонников к Дракону .

Смотришь на все это, а потом безучастно читаешь на CNN ньюса о том, что очередной спутник Третьего Рима (а четвертому как известно не быть ) бороздит просторы океана, или устраивает фейерверк в атмосфере. Наверное также чьи студенты познали Новые Идеи В Программировании от мастеров-преподавателей

Уважаемые коллеги!

В этом сообщении речь пойдет о семействе ДРАКОН-языков.
То есть о гибридных языках.
А также о структурах данных.

ГИБРИДНЫЕ ЯЗЫКИ ДРАКОН-СЕМЕЙСТВА

ГРАФИЧЕСКИЙ И ТЕКСТОВЫЙ СИНТАКСИС ДРАКОНА

ДРАКОН – графический (визуальный) язык, в котором используются два типа элементов:

• графические фигуры (иконы),
• текстовые надписи, расположенные внутри или снаружи икон (текс-
тоэлементы).

Следовательно, синтаксис ДРАКОНа распадается на две части.

Графический (визуальный) синтаксис охватывает алфавит икон, правила их размещения в поле чертежа и правила связи икон с помощью соединительных линий. Графический синтаксис описан в главе 33.

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

Оператор языка ДРАКОН — это икона или комбинация икон, взятые вместе с текстовыми надписями.

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

§12. СЕМЕЙСТВО ДРАКОН-ЯЗЫКОВ

Дракон – не один язык, а целое семейство, которое может включать практически неограниченное число дракон-языков. Все гибридные языки дракон-семейства имеют одинаковый графический синтаксис. Это обеспечивает зрительное сходство дракон-схем различных гибридных языков.

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

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

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

§13. КАК ПОСТРОИТЬ ГИБРИДНЫЙ ЯЗЫК
ПРОГРАММИРОВАНИЯ В ОБЩЕМ СЛУЧАЕ?

Чтобы построить гибридный язык, нужно выполнить 5 шагов.

Шаг 1. Выбрать целевой язык (например, язык Си).

Шаг 2. Использовать графический синтаксис языка Дракон в качестве графического синтаксиса гибридного языка Дракон-Си.

Шаг 3. Использовать синтаксис целевого языка (синтаксис языка Си) в качестве текстового синтаксиса гибридного языка Дракон-Си.

Шаг 4. Удалить из текстового синтаксиса гибридного языка Дракон-Си все элементы, которые заменяются управляющей графикой ДРАКОНа.

Шаг 5. Создать транслятор из дракон-схемы в исходный код языка Си.

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

При использовании гибридных языков исходным текстом программы считается дракон-схема и только она.

Пример. Предположим, пользователь работает в связке Дракон-конструктор – Транслятор Дракон-Си – Keil. Понятно, что исходником служит дракон-схема. При отладке программы не следует вносить исправления в промежуточные текстовые Си-файлы. Все исправления нужно вносить в исходный код, то есть в дракон-схему.

Петр Приклонский сообщает:

«Я уже больше года работаю на связке Дракон-конструктор – DrakonToC – Keil. И ни в коем случае не позволяю себе править промежуточные текстовые Си-файлы. Исходник – это дракон-схема!» [1]

§14. ДВА ЭТАПА РАЗВИТИЯ ЯЗЫКОВ ПРОГРАММИРОВАНИЯ

С точки зрения человеческого фактора, в истории развития языков программирования можно выделить два этапа.

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

На втором этапе (который, по-видимому, только начинается) некоторые языки высокого уровня смогут работать в сочетании с языком Дракон, образуя гибридные языки. При этом функция исходного кода программы переходит к дракон-схемам.

Это позволит отказаться от текстовых управляющих структур, используемых в языках высокого уровня, и заменить их на управляющую графику Дракона.

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

§15. ПЛАН РАЗВИТИЯ И ЧАСТИЧНОЙ УНИФИКАЦИИ
ЯЗЫКОВ ПРОГРАММИРОВАНИЯ

Опыт использования языка Дракон и гибридных языков позволяет предложить план развития и частичной унификации языков высокого уровня из трех пунктов.

1. Использовать графический синтаксис языка Дракон в качестве
стандарта, позволяющего осуществить частичную унификацию
языков высокого уровня.

2. Текстовый синтаксис следует заимствовать из целевого языка. При
этом следует удалить все элементы текстового синтаксиса, которые
заменяются управляющей графикой Дракона.

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

§16. ВЫВОДЫ

1. Язык Дракон можно присоединить к некоторым языкам программирования и получить так называемые гибридные языки:

язык Дракон + язык Си = гибридный язык Дракон-Си

язык Дракон + язык Дельфи = гибридный язык Дракон-Дельфи

язык Дракон + язык Джава = гибридный язык Дракон-Джава

язык Дракон + язык Си# = гибридный язык Дракон-Си#

язык Дракон + язык Питон = гибридный язык Дракон-Питон

язык Дракон + язык Перл = гибридный язык Дракон-Перл

язык Дракон + язык Руби = гибридный язык Дракон-Руби

язык Дракон + язык Ада = гибридный язык Дракон-Ада

язык Дракон + язык Tcl = гибридный язык Дракон-Tcl

язык Дракон + язык Оберон = гибридный язык Дракон-Оберон

язык Дракон + язык Ассемблер = гибридный язык Дракон-Ассемблер

и т. д.

2. Гибридный язык почти полностью сохраняет концепцию, струк-
туру, типы данных и другие особенности целевого языка. В строго
определенном числе случаев текстовая нотация целевого языка за-
меняется на графическую нотацию Дракона. Такой прием позволя-
ет улучшить эргономический облик гибридного языка и повысить
производительность труда программистов.

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

Первым делом на языке ДАКОН нужно составить программу по удалению из "документации" всей демагогии, это позволит сделать язык еще проще, удобнее, понятнее пользователю, после этого (видимо) изучение не потребует неоправданных больших затрат, у специалистов появится резерв времени, они исправят все недостатки и облегчат жизнь алгоритмистов и специалистов, вследствие чего они быстро и легко овладеют и создадут алгоритмы и прикладные программы, создадут мощные инструменты и легко применят их на практике и прочая прочая прочая... фух, дело бредогенераторов живет и процветает, так и хочется взять канделябр и отдубасить этого кулибина легко и непринужденно... тьфу...

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

G>фух, дело бредогенераторов живет и процветает, так и хочется взять канделябр и отдубасить этого кулибина легко и непринужденно... тьфу...

Уважаемый grosborn!

У меня просьба. Если Вас не очень затруднит, изложите Ваши возражения более подробно и желательно с аргументацией.

Спасибо.

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

C>>Тогда схема превратится в жуткую неудобную вещь. Так как выворачивать наизнанку алгоритм — неудобно.
R>Можно пример, в каком месте вывернет?
Предлагается линейный императивный алгоритм переписать в событийно-управляемый. Читать про сопрограммы и прочее.

R>>>Диаграмма нагляднее отображает что происходит, даже в случае очень высокоуровневых шаблонов.
C>>Чем нагляднее? Я тут не увидел ни одной реальной диаграммы кроме кривых детских примеров.
R>Диаграммы тут обобщенные, но хорошо иллюстрируют подход к проблеме.
Да.

R>Например так создают AI и постановочные сцены в популярных игровых движках.
Не так. AI в играх пишется на старом добром С++ или других языках. Графически только расставляются всякие инициаторы и прочее (дык, а как это делать по-другому?).

R>Kismet редактор в Uneral Engine.

Ага.

R>Flow Graph Editor редактор в CryEngine 3.
И?

R>Вообще, прочитав статью у меня прошла ассоциация с комбинациями в Го и сохранением рисунка игры (захватом территории).
И?

R>Знаю что без фреймворка или dsl писать сложные поведения и fsm на c/c++/java/c# то еше удовольствие. А ревьюить без знания кода практически невозможно, только в случае если кто-то будет подсказывать что делает тот или другой кусок кода.
И?

R>Некоторое время баловался Debugger Canvas, достаточно удобно. Если в таком-же стиле сделать редактор дракона, да с отладкой схем.
R>И еше добавить уровни:
R>1 Большие логические модули
R>2 Подпрограммы
R>3 Низкоуровневые алгоритмы
Это всё умели делать Rational Rose и Together. Оба сдохли заслуженной смертью.

C>>И чем это противоречит моим словам? Как я напишу реализацию TCP-стека с помощью state-машины?
R>Тут наверно недопонимание, имел ввиду что простая установка соединения уже требует отслеживания состояния сокета. тоесть работать с сокетом можно только в connected состоянии, при состоянии error нужно переподключится итд..., я в этом вижу стейт машину
И дальше что? Возьми реальный код TCP-стека (я даже помогу — вот он: http://lxr.free-electrons.com/source/net/ipv4/tcp.c ) и посмотри на объём кода в нём. State-машина там теряется в объёме реальной работы, которую надо делать при установке соединения.

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

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

Что ж, 124 страницы это фигня, можно сказать начало, старт проекта. Видимо это кропотливая ручная работа, поэтому ждем трехтомника всяческих новых фундаментальных понятий. А если наскучит, можете заказать у меня в этом стиле стотомник, я когда студентом был баловался генераторами.

> У меня просьба. Если Вас не очень затруднит, изложите Ваши возражения более подробно и желательно с аргументацией.

Вызов на демагогическую дуэль? Как ожидаемо.

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

G>Что ж, 124 страницы это фигня, можно сказать начало, старт проекта. Видимо это кропотливая ручная работа, поэтому ждем трехтомника всяческих новых фундаментальных понятий. А если наскучит, можете заказать у меня в этом стиле стотомник, я когда студентом был баловался генераторами.

Корчеватель — тоже ты?

Здравствуйте, Владимир Паронджанов, Вы писали:

ВП>Здравствуйте, Курилка, Вы писали:

К>>проектирование в первую очередь затрагивает вопросы декомпозиции задачи на слои/функции/объекты и т.п.? Или в драконе есть аналоги структурных диаграмм UML, например?

ВП>Да, есть. В драконе есть аналоги структурных диаграмм UML (диаграмм поведения). Если говорить более точно:

ВП>

ВП>Аналогом дракон-схем служат диаграммы поведения (behaviour diagrams) языка UML, в частности, диаграмма деятельности (activity diagram), диаграмма состояний (UML state machine diagram) и некоторые диаграммы взаимодействия (interaction diagrams), например, диаграмма синхронизации (timing diagram).

ВП>Другим аналогом дракон-схем являются блок-схемы алгоритмов, диаграммы Насси-Шнейдермана, псевдокод (язык описания алгоритмов) и др.

Всё это выглядит очень странно, если учесть, что диаграммы поведения НЕ являются структурными диаграммами, а являются одним из вариантов диаграмм взаимодействия (причём в цитате об этом есть упоминание). Да даже и смешивать в одну кучу диаграммы поведения и взаимодействия (как это сделано в вашей цитате) некорректно, ибо это разные диаграммы и акцент в них делается на разные аспекты программы.
Если есть проблемы с тем, что есть структурные диаграммы, можно посмотреть хотяб вики.
Интересно всёж услышать ответ на мой вопрос

> G>Что ж, 124 страницы это фигня, можно сказать начало, старт проекта. Видимо это кропотливая ручная работа, поэтому ждем трехтомника всяческих новых фундаментальных понятий. А если наскучит, можете заказать у меня в этом стиле стотомник, я когда студентом был баловался генераторами.
>
> Корчеватель — тоже ты?

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

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

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

LVV>>Передергиваете. Я говорил о том, что мы проводили опрос. На предмет в каком виде легче доходит алгоритм.
LVV>>И вывод был однозначный: девушки все поголовно воспринимают картинки, то есть схемы.
LVV>>А пацаны — в основном псевдокод. Но есть отдельные личности, которым пофигу: одинаково информативным является и псевдокод, и схемы-картинки.
__>Как быстро Вы сдали назад. Я освежу вашу весьма короткую преподавательскую память вашей первой цитатой:
__>"Как препод могу сказать, что некоторым студентам и почти всем студенткам гораздо проще посмотреть на картинку алгоритма, чем на текст алгоритма. Для рисования сложных алгоритмов Дракон подходит как нельзя лучше."
И где здесь сдача назад?
Мы провели опрос — результаты я озвучил. Разве что в первом сообщении не написал, что мы спрашивали.

LVV>>Привет вашей логике... Она даже на женскую не похожа...
__>У вас не осталось аргументов и вы решили перейти к оскорблениям? Достойное поведение для преподавателя , продолжайте в том же духе . Так вы привлечете просто массы неистовых поклонников к Дракону .
Прошу извинить, если чем обидел.
Но на женскую логику ваша абсолютно не похожа...

Здравствуйте, Владимир Паронджанов, Вы писали:

ВП>Даю ссылку на Краткое описание языка ДРАКОН. Всего 124 страницы. Много рисунков.
ВП>О космических кораблях нет ни слова. Все примеры очень простые, бытового характера.
ВП>http://drakon-practic.ru/drakon.pdf
Предположим, Драконом пользуются для написания реальных программ
Несколько вопросов:
1) Системы контроля версий. Насколько удобно сделать diff между произвольными ревизиями кода?;
2) Насколько удобно закомментировать какую ветку или часть кода, насколько легко это все вынести в отдельную процедуру?;
3) Книгу я просмотрел очень мельком, все примеры там бытового характера. А вот в реальности насколько удобно рисовать эти диаграмки? Отображают ли эти диаграмки полностью структуру программы с полной детализацией, или же за детализацией нужно нажимать кучу клавиш, переменные скрыты и размазаны, и чтоб реально понять что как работает, придется очень сильно потрудиться?

Спрашиваю это все потому, что визуальными средствами написания программ я пользовался на практике и в реальных проектах. И могу сказать, что обплевался. Простейшие рефакторинги делать крайне затруднительно. На диаграмме не все, чтобы увидеть детали, надо нажимать на прямоугольник и смотреть проперти. А если детализация ого-го, то схема крайне перегружена и ее хрен разберешь. Дополнительно, пока какой управляющий блок набьешь, проклянешь все на свете. diff ни хрена ни сделать — если что работало, кто то что то поменял, и работать перестало, хрен докопаешься до причины. Перед использованием всего этого требуется проходить черти какой инструктаж, ибо куча неочевидных моментов.
Я видел кучу рекламных роликов о том, что вот, наконец то, появился новый язык, программисты не нужны, специалисты в предметной области сами все напишут. И в 100 процентах случаев заканчивалось тем, что приходится привлекать программистов, несмотря на наглядность читаемого представления, эти программисты страшно матерятся, тратят в 10 раз больше времени, а также программистов требуется в 10 раз больше. Ибо кроме того, что это все крайне неудобно использовать на практике, еще и среда разработки страшно глючит, а также при малейшем отклонении от идеального эталонного сценария приходится делать такие извраты и макароны, что появляется желание уйти в запой с горя. А если в самом начале в какой либо переменной допустил орфографическую ошибку — все, это уже практически не исправить. Средств рефакторинга нет, чтобы выделить процедуру, нужно ее рисовать с нуля. Даже переменную переименовать проблема, приходится реплейсить внутреннее представление этой схемки, никому не говоря, ибо это запрещено. В результате, учитывая то, что рефакторить крайне затруднительно, на практике код очень быстро превращается в черти какие макароны, когда на одной схеме тысячи стрелочек и блоков, налезающих друг на друга.

PS Относительно новых идей в программировании — мне понравилось вот это. Это действительно то, чтобы мне хотелось видеть. Но рисование программы визуально в виде аналогов блок схем (неважно — UML это, DFD или дракон схемы) — это очень старая идея, которая себя не оправдала, а пытались это реализовать наверно тысячи фирм.

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

Т>Мммм. Будет вкусно!

Это реальный язык, на котором программируют люди, далекие от профессионального программирования. На нем Буран сделали и он полетел. А современные "профессиональные программисты" наверняка бы уронили, к бабке не ходи.

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

Т>>Мммм. Будет вкусно!
V>Это реальный язык, на котором программируют люди, далекие от профессионального программирования. На нем Буран сделали и он полетел. А современные "профессиональные программисты" наверняка бы уронили, к бабке не ходи.
Бурановский программист в теме уже отметился и сказал, что они ничерта про ДРАКОН не знают.

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


__>А вот в штатах бедолаги не знают и все на UML рисуют. И инструментов там — тьма тьмущая. И все довольны.

У них до UML вообще единых стандартов графических обозначений для ПО не было. Наш ГОСТ их обгонял на десятилетия.


__>И как это так получилось что какой-то там дракон вдруг стал лучше uml-кубиков?

Потому что UML — это НЕ язык программирования. Это язык абстракций. На нем не напишешь полноценную программу. А на Драконе — напишешь.
В этом плане UML полный отстой. Он был изначально разработан как некая упрощенная иконографика для обмена информацией м/у коллегами, поэтому в нем отсутствует целостность. С помощью каждого типа диаграммы можно передать лишь какой-то один аспект происходящего, но никогда всю программу целиком.

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

C>До ДРАКОНа были Together, Rational Rose и прочие гадости. Кто-то их помнит?
Розу я до конца жизни не забуду. Помню как поставил, мне в результате перетерлись все MSXML библиотеки, в результате полсистемы перестало работать. Когда то (больше 10 лет назад) верил, что типа такие мегафирмы не могут сделать лажу, а за визуальным программированием действительно будущее. Ладно б одна фирма и единичный случай, а я таких мегавизуальных средств с генерацией кода из сверхпонятнейших диаграмм видел минимум 5. А то и все 10 и более, если считать случаи, когда предоставляют сверхпонятный язык, позволяющий программировать просто аналитикам, а всех программистов поувольнять. По мне, так лучше уж на брейнфаке все писать, для него хоть кодогенератор можно написать с нормального языка и забыть про все ужасы этой визуальщины.

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

WH>Дракон-схема задает конечный автомат.
WH>Если задача не сводится к конечному автомату, то дракон работать перестает.

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

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

WH>Если задача не сводится к конечному автомату, то дракон работать перестает.

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

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

ВП>>На Драконе задачи прекрасно решаются в терминах предметной области. На работе я организую работу именно таким образом.
WH>Только если предметная область сводится к КА.
WH>А если нет, то все становится печально.

По твоей ссылке предметной областью являлся компилятор с DSL. Разработка такого компилятора — вполне себе автоматная задача.