Здравствуйте, Андрей Хропов, Вы писали:
CP>>Бизнес-модель "шапками нах закидаем!" пора отправить на помойку истории. АХ>Да, вместе с бизнес-моделью "предложим откат знакомому чиновнику" желательно бы.
Будете смеяться, но эти модели зачастую порождаются одна другой. По крайней мере я это лично наблюдал раза два.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Меня упорно обвиняют не в тех греха, которые я совершил
Я вовсе ничего не иvею против возможностей Nemerle, я "клевещу" исключительно на род человеческий, утверждая:
1) Непоследовательность в синтексисе будет мешать распространению Nemerel из-за особенносте человеческой психики. Но польских аспирантов видно просто перло от креатиффа.
2) "Мощь" либо не бутет востребована, либо будет использоваться не к месту и не по назначению, опять-таки из-за ограниченности человеческих способностей. О том, что она может быть применена с большой с пользой, я не спорю.
3) При разработке реальтных проектов (крупных, с большим кол-вом участников), нужна не столько "мощь" инструментальных средств, сколько дисциплина, контроль и ограничения — опять из-за слабости человеческого восприятия и слабых коммуникационных способностей.
Не Nemerle первы, не он последний, его заявка на mainstream (учитывая CLR, C-like синтаксис) не вполне состоятельная, а маргинальных языков создано и так достаточно.
Здравствуйте, lastochkin, Вы писали:
L>Меня упорно обвиняют не в тех греха, которые я совершил
Никто тебя ни в чём не обвиняет. Просто есть не согласные с твоим мнением, вот и всё.
L>Я вовсе ничего не иvею против возможностей Nemerle, я "клевещу" исключительно на род человеческий, утверждая:
В чём то я с тобой согласен. Как контрактнику мне доводилось работать в разных командах, в больших и маленьких, сильных и слабых. То о чём ты говоришь относится в большей степени к большим и слабым командам, когда попытки достичь результата направлены исключительно на увеличение количества землекопов. Но, как известно, принцип брать не уменьем, а числом в программировании плохо работает.
L>Не Nemerle первы, не он последний, его заявка на mainstream (учитывая CLR, C-like синтаксис) не вполне состоятельная, а маргинальных языков создано и так достаточно.
Кстати, есть ещё одна область, точнее даже не область, а зияющая дыра. Это — DSL. Майкрософт сейчас занимается какими-то исследованиями, но боюсь, что на Немерле это делать будет всё равно проше.
... << RSDN@Home 1.2.0 alpha rev. 0>>
Если нам не помогут, то мы тоже никого не пощадим.
Здравствуйте, FR, Вы писали:
FR>такая программа выводит мусор, так как локальный n не запоминается, в языках же подерживающих замыкания n запомнится и результат будет правильный.
С мусором бороться вполне можно, но тогда это приведёт к проблеме типа циклических ссылок, когда не понятно кто кого первый должен удалять.
... << RSDN@Home 1.2.0 alpha rev. 0>>
Если нам не помогут, то мы тоже никого не пощадим.
Здравствуйте, CopyPaste, Вы писали:
L>>Хочешь ты или нет, но если ты занимаешься реальной разработкой, то тебе придется читать чужой код, а кому-то придется — твой.
CP> Дебилам — не придётся. И мне код дебилов редко приходится читать — стараюсь с ними не связываться.
Здравствуйте, IT, Вы писали:
FR>>такая программа выводит мусор, так как локальный n не запоминается, в языках же подерживающих замыкания n запомнится и результат будет правильный.
IT>С мусором бороться вполне можно, но тогда это приведёт к проблеме типа циклических ссылок, когда не понятно кто кого первый должен удалять.
Здравствуйте, IT, Вы писали:
IT>Здравствуйте, FR, Вы писали:
FR>>такая программа выводит мусор, так как локальный n не запоминается, в языках же подерживающих замыкания n запомнится и результат будет правильный.
IT>С мусором бороться вполне можно, но тогда это приведёт к проблеме типа циклических ссылок, когда не понятно кто кого первый должен удалять.
Циклические ссылки тоже можно разрулить но в результате получится тот же GC
Здравствуйте, Lloyd, Вы писали:
IT>>С мусором бороться вполне можно, но тогда это приведёт к проблеме типа циклических ссылок, когда не понятно кто кого первый должен удалять.
L>В паскале? Как?
В Паскале скорее всего никак.
... << RSDN@Home 1.2.0 alpha rev. 0>>
Если нам не помогут, то мы тоже никого не пощадим.
Скажи, а кроме глословных заявлений ты в силах что-то сказать? Ну, там обосновать свои слова. Привести факты. А то ты очень громко вещаещь, но все твои слова пустой звук. Вот, к примеру, откуда ты взял "Непоследовательность в синтексисе"? Обоснуй, пожалуйста это утверждение. Приведи примеры. Глядишь если они окажутся обоснованными, то мы убедим авторов языка и исправим непоследовательност. Ну, а если это просто твои догадки, то ты так и скажи.
Еще интересно было бы послушать про "маргинальность". Ведь с тем же успехом можно утверждать, что это ты и твои слова маргинальны (и не безосновательно, надо сказать). И чем ты докажешь, что ты не верблюд?
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, lomeo, Вы писали:
L>С сайта Немерле: L>[quote] L>All the people who consider Nemerle syntax odd, compared to C#, are referred to the Haskell and/or Lisp manuals. L>[/quote]
Не надо приводить не относящихся к делу. Примеры не последовательности в студию. Если примеров нет, то не стоит повтоять этот домысел вновь.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, CopyPaste, Вы писали:
WH>>>Это факт. WH>>>Многие почемуто постоянно забывают про выделеное. L>>Иной раз лучше 1000 строк простого кода, чем 100 супер-навороченного.
CP> А если это 1000 строк навороченного кода? Пусть там даже одни только примитивнейшие конструкции a la Python, и каждая строчка читается как песня, но логика за всем этим та-акая сложная, что лучше сразу вешаться.
CP> В таких ситуациях и нужно метапрограммирование — сначала создаёшь язык, потом на нём как можно более просто и понятно описываешь сложную логику.
CP> Вот скажи, тебе что приятнее и понятнее читать — EBNF, или написанный на Си конечный автомат, из этого самого EBNF сделанный?
Проще читать описание, сделанное на известном генераторе парсеров YACC, а не написанное самоделкиным угребище на макросах.
CP> Тебе проще читать XML-описание виджетов на гуёвой формочке, или C++-ный код поверх кошмарного MFC?
Проще читать С++ный код поверх кошмарного MFC (кстати, это совсем не сложно), чем столкнуться с хреново документированным описанием гуя на собственном языке, который считай что не документирован вообще.
Кстати, если это сообщение читают сотрудники компании CQG — загляните в директорию client/flo, и вы сможете увидеть такой самопальный "язык" воочию. Я еще не видел ни одного спеца, который сталкиваясь по работе со вставкой на FLO, не начинал материться (на нем описываются GOC-и, а они сами по себе штуки прикольные ). К счастью, его написал и пользовал всего один самоделкин, так что вероятность встретить FLO в исходниках клиента CQG невысока.
Ну короче, я хорошо представляю себе, что было бы, попадись Брайану Беллу, который эту дурь FLO написал, язычок типа Немерле (выглядит этот Брайан, кстати, один в один как сумасшедший ученый из фильма "назад в будущее") . Его имя и так было вместо ругательства в московском офисе — он очень творчески управлялся с темплейтами и COM-классами, а уж с таким пулеметом как немерле точно пропал бы дом, зуб даю .
Так что у нас в конторе Немерле не будет. Мы жить хотим. Вдруг в ком-нибудь неожиданно проснется талант Брайана Белла?
Здравствуйте, VladD2, Вы писали:
VD>Не надо приводить не относящихся к делу. Примеры не последовательности в студию. Если примеров нет, то не стоит повтоять этот домысел вновь.
Я не отвечал на вопрос "где примеры последовательности". Мои слова всего лишь повод задуматься: во-первых, есть люди, которым не нравится синтаксис Немерле именно своей нечеткостью, во-вторых, это люди определенного круга, в-третьих, на официальном сайте не дается ни опровержения, ни согласия с этим замечанием, подчеркивая, мол "есть мнение".
Т.е. примеры ничего не скажут — кому то они покажут, что синтаксис нечеткий (непоследовательность — немного не то слово), кому то нет.
Здравствуйте, Gaperton, Вы писали:
CP>> Вот скажи, тебе что приятнее и понятнее читать — EBNF, или написанный на Си конечный автомат, из этого самого EBNF сделанный? G>Проще читать описание, сделанное на известном генераторе парсеров YACC, а не написанное самоделкиным угребище на макросах.
Что делать, если для желаемого dsl-я нет известного инструмента?
Здравствуйте, lomeo, Вы писали:
L>Здравствуйте, Gaperton, Вы писали:
CP>>> Вот скажи, тебе что приятнее и понятнее читать — EBNF, или написанный на Си конечный автомат, из этого самого EBNF сделанный? G>>Проще читать описание, сделанное на известном генераторе парсеров YACC, а не написанное самоделкиным угребище на макросах.
L>Что делать, если для желаемого dsl-я нет известного инструмента?
Отвечаю. Если нет известного инструмента для чего бы то ни было, не только DSL, то либо обходятся без инструмента — гражданскими средствами, либо пишут свой инструмент. Содержательно, да? Ну, так какой вопрос, такой и ответ.
Могу сказать про себя — я в таких случаях делал свой парсер и свою виртуальную машину. Благо что ФОРТ-машина, как и парсеры, делается элементарно, быстро и на автомате — не успеешь сказать "немерле". DSL-и были очень специфические, это были языки описания торговых систем и преобразований временных рядов, и для них не было ну совершенно никакого известного инструмента.
Это все было на С++. Менять язык только ради того, что прямо на нем можно сделать DSL, я не буду — это глупость. Должны быть более веские причины.
АХ>>Единственное что напрягает "mutable" для переменных (но это видимо специально, чтобы не хотелось использовать ), я бы предпочел более короткое "val" как в Scala.
АХ>Букву перепутал, var конечно же.
Я сомневаюсь в Вашей способности прогнозировать будущее Nemerle в основном потому, что Вы, по всей видимости, мало знакомы с его настоящим. Лично мне было гораздо интереснее почитать соображения о проблемах Nemerle здесь
ведь у меня сложилось впечатление, что Vermicious Knid разбирается в вопросе существенно лучше.
В то время как Ваше сочинение о будущем Nemerle изобилует преимущественно эмоциональными суждениями и мизантропией, которая как всегда единственная надежда и опора во дни сомнений, во дни тягостных раздумий о судьбах нашей родины.
L>Основные проблемы Nemerle, мешающие ему стать распространенным языком: L>1) "Предательство" синтаксиса L>2) Упор на повышение "мощности" языка L>3) Метапрограммирование (для п.2) L>4) Смешение парадигм (для п.2)
Мешают стать таковым почти всем существующим языкам. Кроме, естественно, тех, которые проектировались пуристами для пуристов.
Может Вы намекаете на то, что по сравнению с Java даже такие языки как C++ или C# являются маргинальными?
Весьма сомнительный тезис.
Рассмотрим подробнее тот же C#: Мало того что он содержит многочисленные "предательства С-like синтаксиса" вроде объявления массивов, так в нем есть вещи и покруче, которые Вы вполне могли бы назвать "предательством семантики" (например псевдодеструкторы ~foo, которые на самом деле никакие не деструкторы). Налицо существенные претензии на повышение выразительности (которую вы называете мощностью) в виде foreach или yield. Существует некоторая поддержка языком AOP в виде атрибутов.
И самое страшное — просто таки каинова печать — смешение парадигм. Думаю влияние ФП на C# трудно не заметить, нес па?
Так что из Вашей теории следует абсолютная невозможность какого бы то ни было настоящего у C#, и в этом теория противоречит фактам.
Тем более, похоже что пуристы сдают позиции. В Java решили досыпать фич и сахарку, а VB вообще стал более чем навороченным языком.
L>В основе проблем лежат: L>1) Преувеличение мыслительных способностей программистов, а и людей вообще. В реальности они довольно ограничены. L>2) Преувеличение роли логического, рационального мышления. Человек мысли иррационально, эмоционально (увы и ах).
Серьезная заявка на победу! Отталкиваясь от этих же аргументов Вы с таким же успехом докажете невозможность программирования, высшей математики и даже устного счета. Не останавливайтесь на достигнутом, порадуйте нас новыми шокирующимим откровениями.
L>3) Ошибочная посылка: язык программирования служит общения к компьютером. При современном развитии вычислительных сред, язык программирования служит прежде всего для накопления знаний и общения между разработчиками.
В словах "общения к компьютером" мне видится что-то мистическое. Извините, но мистика это не мой профиль.
L>Подробно о проблемах: L>1) Синтаксис Nemerle взяв за основу синтаксис C, тем не менее существенно от него отступает, причем без всякого разумного обоснования. Если бы синтаксис отличался радикально (как у Python, Ruby и др.) это было бы пол беды — проосто изучение языка стало бы путешествием в совершенно новый мир, пусть непривычный и даже чуток враждебный. Враг бывает достоин уважения и даже восхижения, но предатель — никогда.
Меня обескураживает такой романтический подход к языкам. Я склонен полагать, что называть своим врагом язык можно с таким же успехом как и десятичную систему счисления или электроперфоратор.
L>Все удачные (читай: получившие расространение) синтаксические приемники Си шли по пути расширения его синтаксиса, но, в отличии от Nemerle, не извращения, таковы C++, Java, Java-script, PHP, C#, даже Perl. Аргумент разработчиков Nemerle: синтаксис отличается, но люди легко его выучат. Ответ: да, выучат, если захотят учить язык с "предательским" (эмоциональная реакция!) синтаксисом, но удовольствия не получат (опять эмоции, но на них держится мир).
Это фактически не верно. Синтаксис претерпевал во многих примерах названных Вами положительными существенные изменения. Хотя, возможно, мне трудно уловить тонкость между "расширением" и "извращением". По моему же скромному разумению, те, кто стерпел Perl вынесут все что угодно с вот такими вот скобочками {}. Я даже подозреваю, что если бы в Lisp по умолчанию были правильные(тм) скобки, то его ждал бы ошеломительный успех.
Специально для тех, кто уже готовится отбивать мне почки, заявляю: про lisp я пошутил.
L>2) Программистам не хватает не "мощности", которую вполне можно упаковать в библиотеки и API, а надежности, защищенности и удобства. Такие ставшие "примитивными" возможности среды разработки, как подсветка синтаксиса, контекстная справка, переход по перекрестным сслыкам, InteliSence и т.п. экономят гораздо больше времени и нервных клеток, чем многие синтаксические навороты. Причина в том, что программы пишут живые люди, которые быстро утомляются, часто ошибаются, что-то забывают и т.д. Простота и лаконичность — вот чего ждут разработчики.
Этот довод работает в обе стороны. Просто взгляды на простоту очень сильно отличаются. Синтаксические сладкоешки уверяют, что оператор + все только упрощает, а синтаксические диабетики приходят в ужас от того, что за + может скрываться операция сложения матриц. В тех условиях, когда договориться о объеме стандартной порции сахара не представляется возможным, вполне может оказаться востребованным решение, позволяющее досыпать сахар по вкусу. Вы поняли, о чем я.
Мне кажется, что Nemerle (если не касаться макросов, да и макросы там к взрыву мозга не приводят) очень простой язык. Гораздо проще чем Scala или даже C# 3.0. Что же касается лаконичности, то про C# и тем более Java лучше вообще не вспоминать.
Про волшебный язык с двумя положительными свойствами я даже не заикнусь. А то придут мрачные люди вроде капитана Блэка из Catch 22 и сообщат, что к подписанию присяги о лояльности меня не допустят. Не очень то и хотелось.
L>3) Метапрограммирование очень существенно усложняет понимание кода человеком, в виду ограниченности мыслительных возможностей последнего (причем подвижек с этим в обозримом будущем не ожидается). И это очень серьезная причина ограничивать использование средств метапрограммирования, не смотря на их потенциальную силу,
Есть мнение, что метапрограммирование как раз упрощает понимание. Оно как раз и придумывалось для того, чтобы пощадить наши мозги, а за одно и не позволить умереть от бессмысленного труда. Люди, которые ставят перед собой противоположные цели, занимаются не метапрограммированием, а разработкой пятимерных кубиков Рубика.
L>не зря в современных успешных языках (C++, C# 2.0) оно сведено к минимуму (generic-и), а то и вовсе отсутствует (Java). А ведь мир видал препроцессоры куда круче Nemerle-вского, в PL/I язык препроцессора по мощи не многим уступал самому целевому языку. Похоже, использование generic-ов (причем без typedef!) и Reflection вполне достаточная доза метапрограммирования в современных языках.
Для начала, обобщенное программирование к метапрограммированию никакого отношения не имеет. Причем обобщенное программирование в java теперь есть. Про препроцессоры вообще кошмар. Макросы Nemerle никакого отношения к препроцессору не имеют. Это расширение компилятора, а не средство осуществляющее текстовые подстановки.
При этом совершенно не понятно, почему, оставляя право на существование эмиссии кода в рантайм Вы отказываете в этом праве макросам? Это вещи по сложности почти несопоставимые, а уж по количеству граблей и подавно.
Непонятно также, почему, если отсутствие поддержки метапрограммирования — это только плюс, множество людей извращаются с кодогенераторами и шаблонами?
К слову, раз уж язык претендует на мэйнстрим, в нем есть некоторые средства дать по рукам тем самым "самоделкиным" которые примуться строчить свои макросы и которых тут так боятся.
L>4) Язык реализующий несколько парадигм (процедурная, функциональная, декларативная)
Боже, храни Королеву! Вы бы хоть с терминологией разобрались, а? Это же элементарное уважение к собеседнику.
L>видимо предполагает их интенсивное совместное использование, что опять таки является непосильной (увы) нагрузкой для программиста.
Перегруженным мозгам остаются их естественные права использовать все что можно раздельно и экстенсивно.
Аргумент снова работает в обе стороны: мультипарадигменность позволяет плавно переходить от одной парадигмы к другой, допускает возможность комбинировать подходы в удобных пропорциях. С этой точки зрения, мультипарадигменность как раз претензия на мейнстрим.
L>В лучшем случае труднопонимаемые детали будут задвинуты, в худшем будут служить причиной тонких, неуловимых ошибок и огромных проблем с чтением чужого кода.
Все те же аргументы приводились и против ООП. Функциональные элементы все равно так или иначе приходят в мэйнстрим, пусть даже и под мозгодробительными названиями, придуманными microsoft-ом.
L>Вы пробовали изучать, к примеру, Пролог? Пока читаете описание и разбираешь простые примеры — все отлично. Как дело доходит до решения оригинальных задач и чтения реального кода, вот тут и понимаете как трудно переключиться в принципиально иную парадигму.
Тем не менее такое переключение уже происходило и не раз.
L>Приходится сделать неутешительный вывод: Nemerle — лишь новый красивый узорчатый листок на пышном дереве мертвых исследовательских языков где-то рядом с НУТ-ом (Новым Утопистом) и другими попытками объять необъятное.
Приходится сделать неутешительный вывод: тема будущего Nemerle в Вашем сообщении не раскрыта. У этого языка есть проблемы с Выходом в мэйнстрим. Я даже склоняюсь к мысли, что значительной популятности у Nemerle никогда не будет, и вовсе не потому, что он слишком хорош для этого мира. Качество языка с распространенностью вообще слабо коррелирует.
Вот только хорошая совместимость с .NET уже означает, что этот язык не является маргинальным.
Старина Аристотель, кажется говорил, что одна ласточка еще не делает весны, но вот только Nemerle такой ласточкой и не является. Тем более не является и попыткой объять необъятное.
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
'You may call it "nonsense" if you like, but I'VE heard nonsense, compared with which that would be as sensible as a dictionary!' (c) Lewis Carroll
Здравствуйте, Gaperton, Вы писали:
G>Отвечаю. :xz: Если нет известного инструмента для чего бы то ни было, не только DSL, то либо обходятся без инструмента — гражданскими средствами, либо пишут свой инструмент. :) Содержательно, да? Ну, так какой вопрос, такой и ответ.
;-)
G>Могу сказать про себя — я в таких случаях делал свой парсер и свою виртуальную машину. Благо что ФОРТ-машина, как и парсеры, делается элементарно, быстро и на автомате — не успеешь сказать "немерле". DSL-и были очень специфические, это были языки описания торговых систем и преобразований временных рядов, и для них не было ну совершенно никакого известного инструмента.
Ну! О чем и речь.
Если задаче нужен DSL, а известного нет, то его приходится писать. А макросы в этом деле неплохо помогают. Я, честно говоря, даже не представляю, зачем мне писать на лиспе, у которого нет макросов.
В общем то это моя вина. Из-за категоричности твоих постов я решил, что ты противник макросов.
G>Это все было на С++. Менять язык только ради того, что прямо на нем можно сделать DSL, я не буду — это глупость. Должны быть более веские причины.
Спасибо, это то, что я хотел услышать.
Разумеется, я не говорил ни о "менять", ни о "только для dsl"
Здравствуйте, Klapaucius, Вы писали:
K>В то время как Ваше сочинение о будущем Nemerle изобилует преимущественно эмоциональными суждениями и мизантропией, которая как всегда единственная надежда и опора во дни сомнений, во дни тягостных раздумий о судьбах нашей родины.
Вы так говорите, как будто с другой стороны посты у нас не изобилуют эмоциональными суждениями, и Немерлисты являют собой классический образ характера выдержанного, нордического .
L>>3) Ошибочная посылка: язык программирования служит общения к компьютером. При современном развитии вычислительных сред, язык программирования служит прежде всего для накопления знаний и общения между разработчиками.
K>В словах "общения к компьютером" мне видится что-то мистическое. Извините, но мистика это не мой профиль.
Э-э батенька, должно быть стыдно цепляться к словам и делать вид, что мы ничего не понимаем. Автор, очевидно, имеет в виду идеи, стоящие за literate programming, противопоставляя их пионерскому подходу "настоящих программистов", которые пишут "настоящий код не для всех". Знакомый типаж?
Да вот посмотрите, что тут один дядька пишет на эту тему...
I believe that the time is ripe for significantly better documentation of programs, and that we can best achieve this by considering programs to be works of literature. Hence, my title: "Literate Programming."
Let us change our traditional attitude to the construction of programs: Instead of imagining that our main task is to instruct a computer what to do, let us concentrate rather on explaining to human beings what we want a computer to do.
The practitioner of literate programming can be regarded as an essayist, whose main concern is with exposition and excellence of style. Such an author, with thesaurus in hand, chooses the names of variables carefully and explains what each variable means. He or she strives for a program that is comprehensible because its concepts have been introduced in an order that is best for human understanding, using a mixture of formal and informal methods that reinforce each other.
Donald Knuth. "Literate Programming (1984)" in Literate Programming. CSLI, 1992, pg. 99.
Так вот, автор выразил мнение, что массированое применение макросов и неконтроллируемые эксперименты над синтаксисом ухудшат свойства "литературности" программ, сделают их сложнее для понимания другим человеком, даже если он мега-гуру. Современные программные комплексы состоят из миллионов строк кода, такой объем один человек написать и осмыслить в одиночку не может принципиально. Так что чужой и незнакомый код — это реальность, с которой сталкивается каждый программист в компании, разрабатывающей промышленное ПО. Основной критерий, применяемый к коду таких систем — это maintainability (легкость сопровождения), потому как код такого объема выкинуть нельзя, это долговременная инвестиция компании. Плюс, надо отдавать себе отчет, что авторы системы из компании могут уйти, или будут заняты другой работой, и поддерживать код будут другие люди, не те, кто писали.
Первое правило, которое вводится для обеспечения maintainability — это внутренний стандарт кодирования, который, кроме оформления кода, часто накладывает ограничения на применение свойств испольуемых языков, даже таких "гражданских", как С++. Ну и разумеется, макросы, как средство, наиболее опасное для maintainability, должно находится под строгим контролем, и применяться очень ограничено.
Это правда жизни, дорогой коллега. Невыполнение этих правил загонит компанию в гроб. Не слыхали, что пришлось сделать yahoo, когда из него ушла банда Грэхема? Они вынуждены были переписать движок магазинов, сделанный на LISP, а в нем было 30% метакода... Вот так-то...
Если нам не помогут, то мы тоже никого не пощадим.
Если нет известного инструмента для чего бы то ни было, не только DSL, то либо обходятся без инструмента — гражданскими средствами, либо пишут свой инструмент. 
