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

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

M>Какой ценой?

Ценой освобождения от предрассудков.

M>За счет чего?

За счет выбрасывания из кода болерплэйта и ограничения его решаемой задачей. Это позволяет отказаться от борьбы с языком реализации и не повторять себя.

M>С использованием каких инструментов?

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

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

M>Где и когда эти возможности будут и будут ли они вообще?

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

M>Какова стоимость поддержки этих DSLей, написанный безымянными гениями?

Она уже в немерле не высокая. Вот возможности ограниченные. Только внутренние ДСЛ и только при соблюдении немерловых ограничений на расширение синтаксиса.

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

Никто ничего не избегает. Говорить о деталях Н2 мы пока не можем. Про немерл можно говорить все что угодно. Собственно пока что мы его для работы и используем. Так большая часть практического опыта как раз из немерла.

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

M>Пока что реальность никакой мега не показывает (за исключением исчезающе малого количества DSLей, с каждым из которых есть свои дополнительные проблемы).

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

M>Нет, мы указываем на очевидные пробелы в ваших сказках.

Сказки это только для тебя. Для нас это уже давно быль.

Что до проблем, то я уже устал повторять. Они были всегда, есть и будут вечно. Но решать проблемы стало куда проще.

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

Умные люди применяют ДСЛ-и и сейчас. Вот только возможности поддержки этих ДСЛ-ей крайне ограничены, а затраты времени на их создание велико.

Мы же пытаемся изменить это. Снижение сложности создания и поддержки ДСЛ с уровня "хардкор" до уровня "средний пользователь, не дурак" вполне возможно.

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

M>Кто занимается поиском ошибок в реализации этих DSLей? Их развитием, поддержкой, выявлением проблем с производительностью? Банальным обучением?

По разному. Все в точности как с библиотеками. Когда авторы, когда комьюнити, когда фирма производитель.

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

I>Разговор ведь не о том, чтобы решать любую задачу написанием под неё DSL.

А разве не про это говорит WH ?

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

M>Да, взять бы. https://github.com/rsdn/nemerle/tree/master/snippets/peg-parser

M>1. Ты абсолютно на 100% уверен, что это правильная реализация PEG?

Уверен в большей степени нежели в любом классе из библиотеки дотнета.

M>Количество тестов для этой реализации равно примерно нулю

Обожаю телепатов.
Не говоря уже об отдельных тестах PegGrammar используется в самом Nemerle для прсинга C# (Nemerle умеет компилировать C#-файлы). Так что он тестируется непосредственно в тестах немерла. Зайди вот сюда и поищи файлы с расширением ".cs".

M>2. В случае возникновения ошибок в парсере/генерации кода, сколько времени тебе понадобится найти и изменить ошибку,

Пока что больше часа эта задача не занимала.

M>имея на руках два-три десятка исходников без комментариев и завязанных на неизвестно количество макросов, определенных неизвестно где, и неизвестно, во что разворачивающихся?

А это все твои выдумки. И комментарии можно добавить (и они есть). На что код завязан тоже легко ищется. Он же квази-цитатами генерируется. Так что соответствие между генерируемым кодом и шаблонами находится под подвыражениям на раз.

M>Автор этого добра написал это добро, которое, цитирую «может генерировать любой говнокод с нарушением всех правил хорошего тона результирующего языка, за нарушение которых при ручной работе нужно отрывать руки», и уволился из компании. Через два дня это добро начало вылезать боком изо всех щелей. Что будешь делать? Продолжать вещать сказки про «ах-ах-ах, все так прекрасно»?

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

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

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

M>Я и PEG пользуюсь и, скажем, SQL'ем или каким-нибудь гремлином с cypher'ом. Вот только не надо рассказывать ничем не подкрепленные сказки про мега...мега...мега... DSLей.

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

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

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

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

DSL позволяет выделить чистое знание в отдельний слой. Польза самоочевидна.

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

T>А "мулька сбоку" это обычно хак в пару строчек-пару страниц кода. Например так — есть парсер, который валится на одном из выражений. "Мулька сбоку" — пропатчить выражения "в лоб" без модификации парсера.
Чё за бред!?
Ты реально предлагаешь править текст, перед тем как давать его парсеру?
Ахринеть не встать.
Пожалуй, разговор на этом можно закончить.
Я понял, с кем разговариваю.

WH>Ты реально предлагаешь править текст, перед тем как давать его парсеру?

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

например, то же ядро линукса под специфическое реальное примение патчится именно таким способом.

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

DG>например, то же ядро линукса под специфическое реальное примение патчится именно таким способом.
Ты хочешь сказать, что правки ядра лежат не в git'е и мержаться с обновлением, а вот прямо так на лету, перед тем как скормить их gcc патчаться каким то кодом?
Ты серьёзно?

WH>Ты хочешь сказать, что правки ядра лежат не в git'е и мержаться с обновлением, а вот прямо так на лету, перед тем как скормить их gcc патчаться каким то кодом?

на vcs лежат отдельно исходные исходники, и отдельно патчи. С vcs-а выдергивает и то, и другое, а дальше make накладывает одно на другое.
Обновлении версии ядра линукса сводится к закидыванию новой версии, и проверке, что patch-и продолжают накладываться в нужные места.

Если делать по твоему, то при каждом обновлении — попадаешь на кучу ручной работы.

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

T>>А "мулька сбоку" это обычно хак в пару строчек-пару страниц кода. Например так — есть парсер, который валится на одном из выражений. "Мулька сбоку" — пропатчить выражения "в лоб" без модификации парсера.
WH>Чё за бред!?
WH>Ты реально предлагаешь править текст, перед тем как давать его парсеру?

Это пример "мульки сбоку", что бы тебе было понятно про что речь, которая по времени меньше чем копание в парсере.

WH>Ахринеть не встать.
WH>Пожалуй, разговор на этом можно закончить.
WH>Я понял, с кем разговариваю.

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

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

DG>>например, то же ядро линукса под специфическое реальное примение патчится именно таким способом.
WH>Ты хочешь сказать, что правки ядра лежат не в git'е и мержаться с обновлением, а вот прямо так на лету, перед тем как скормить их gcc патчаться каким то кодом?
WH>Ты серьёзно?

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

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

Собтсвенно вопрос — что делать девелоперу, если у него есть один рабочий день, ошибка где то унутре ДСЛ, а он проект видит второй день, ни архитектуры, ни предметной области, ни дсл, не знает.
Хочу увидеть внятный ответ типа: "Надо посылать всех нахрен и идти разбираться с ДСЛ, потому что это важнее чем десяток блокеров в баклоге"

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

IO>т.е. имеем подход, который сам по себе сопротивляется загниванию кода...

Как говорится, сами только кошки родятся. И то у меня есть большие сомнения по этому поводу.

МП и ДСЛ сами по себе от загнивания не страхуют. Они просто делают перетрахивание ((с) Лукашенко) проекта подъемной задачей.

IO>Еще аргумент. В любой программе на языке общего назначения в единую кашу замешано "что надо сделать" и "как сделать".
IO>Чистое знание о предметной области размазано, растворено в реализации. Его очень тяжело выделить, изучить, найти в нем ошибку, изменить. Крупицы кода, которые несут знание, теряются в полотнах реализации.

Именно так. Причем проблема размазывания обратно пропорционально объему кода умноженному на количество аспектов в коде.

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

IO>DSL позволяет выделить чистое знание в отдельний слой. Польза самоочевидна.

+1

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

Здравствуйте, C.A.B, Вы писали:

CAB>Сначала давай определимся что же такое метапрограммирование?

Давай

CAB>В моём понимании это процесс собственно создания метасредств, например макросов, DSL'ей и других программ создающих программы.

ДСЛ-и тут не причем. Точнее ДСЛ-и вполне могут использоваться для МП, но ДСЛ != МП. Вот МП может быть применено при разработке ДСЛ. Это — да.

CAB>А так как метасредства не являются voodoo, нужна некоторая вычислительная модель(модель вычислений), чтобы заставить это всё работать.

Тут лучше остановиться и определиться с термином вычислительная модель. Машина Тюринга или лябмбда-исчисления Черча вполне пригодная модель для МП.

Если серьезно, то тут главное понимать, что модель вычислений мета-средства никак не связан с моделью вычисления получаемой программы. Это, пожалуй, главное достоинство МП. Пы просто генерируем то решение (алгоритм), которое нам нужно. А то как мы это делает рояли не играет.

CAB>Например в препроцессоре С этой моделью есть банальная подстановка текста.

Ты удивишься, когда узнаешь, что это называется мудреным термином переписывание термов. Ограниченная она и небезопасная.

CAB>Программирование с использованием метасредств(т.е. кода уже используется только модель задачи), ИМХО, называть МП не корректно, т.к. в это случае совершенно не обязательно знать о том как работает МП, и даже о том что оно существует.

Это какой-то поток сознания. Видимо ты имел в виду ДСЛ (или язык программирования вообще). Ну, да программирование на языке программирования не обязано быть метапрограммированием. А вот написание компилятора или интерпретатора является разновидностью МП. Только это бесполезные знания.

CAB>Это ведь уже не программирование, это кодогенерация.

Как сказал мой брат — "Помилуйте! Какой хлопок?! Это стопроцентный coon!". Если серьезно, то кодогенерация — это разновидность метапрограммирования. МП > кодогенерации, так как МП может осуществляться за счет других средств. Например, за счет модификации кода/объектов на лету.

CAB>Зачем все? Думаю достаточно МП + то во что оно будет разворачиваться.

Затем, что ты, как автор метапрограммы, определяешь, что будет генерировать тво метапрограмма. И если ты не знаком с ООП, то не сможешь сгенерировать полноценныое ОО-решение.

Кстати, вычислительные модели ДСЛ-ей не обязаны быть парадигмамами. Это может быть куда более простая модель. Например, моделью вычислений может быть конечный автомат (как в регулярных выражениях) или сеть зависимостей (как в make/Ant/MSBuild).

Кстати, ты наверно даже не думал о том, что файл проекта в VS написан на ДСЛ. Верно?

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

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

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

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

VD>По сути ДСЛ/модель + МП позволяет представить код в виде матрицы, где по вертикали располагается код на ДСЛ, а по горизонтали МП-код. Их перемножение и дает конечный код решающий задачу. Аналогичный рукописный код имеет сходный генерируемому объем кода. Именно это определяет синергизм данного подхода. Правим относительно мало кода, получаем решение содержащее много кода.

собственно, это и есть факторизация кода, которая меняется при рефакторинге

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

VD>В твоем мышлении есть одна ошибка. Ты почему-то не верно оцениваешь сложность поддержки рукописного кода. Если решения задачи можно сгенерировать по существенно более простой/короткой/ясной модели, то сравнимое по характеристикам рукописаное решение будет несоизмеримо сложно. И поддерживать его будет сложно просто из-за огромного объема кода и неизбежных для такого объема ошибок в проектировании и реализации.

VD>Чем более концептуальная ошибка/изменение, тем сложнее ее устранить/сделать в рукописном коде. В решение же на базе ДСЛ и кодогенерации это не критично, так как изменив код генератора можно устранить ошибку без полного переписывания кода.

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

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

То о чем говорит танкер совсем другой случай. Он предлагает вместо того чтобы фиксить баг написать код который будет патчить код который поступает на вход парсеру.

DG>Если делать по твоему, то при каждом обновлении — попадаешь на кучу ручной работы.
Что касается твоего случая, то git это делает одной командой. Где ты нашел кучу ручной работы, я не понимаю.
Я уже больше года так мержу изменение интеграции немерла, которое сделал лично для себя.

Короче всё выглядит, так что кто-то накосячил и развел под это дело кучу идеологии.

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

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

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

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

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

WH>Ну да. Порог вхождения в МП на питоне действительно большой.

И в С++ огромный, и в D большой, и даже в схеме с фортом не маленький.
Почему-то люди боятся/(не понимают как) писать код который пишет код.

WH>Да и порог вхождения в сам питон просто огромен. Хотя и выглядит маленьким ибо простые вещи можно начать писать сразу но то что больше "привет мир"

Ты не прав, но флеймить нет желания