Истоки любви к DSL-ям и метапрограммингу :) - Философия программирования

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

Д>И что, кто-то заставлял использовать эти средства насильно?

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

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

Ну и получи свои же слова:

И что, кто-то заставлял использовать эти средства насильно? Ходил по офисам и палкой бил по головам ослушников? Плохой выбор — это проблема выбирающего. Если выбора нет и библиотека откровенно плоха — напиши свою и обогатись. Если нет времени на это — пиши прогу с учетом замены в будущем. Пишите с использованием языка, а не думайте на нем. И так далее.

Чего на C++ продолжать писать, если такие проблемы с сексом?

Уже утомили подобные стенания. Кого действительно C++ достал уже давно на нем не пишут, у VladD2, IT или AndrewVK спроси. А то, блин, как в анекдоте: "ежики плакали, кололись, но все равно..."

E>>Какой из распространенных ныне языков пережил существенное изменение с потерей совместимости (будучи уже раскрученным и имеющим солидную кодовую базу) и при этом выжил?

Д>бейсик? Не буду приводить его в качестве примера хорошего языка, конечно. Но его живучесть просто потрясает, он прошел очень большой путь от того чуда с номерами строк 10,20,30 до VB.NET, который стал практически нормальным языком

Д>Что еще важнее, язык развивается и занимает новые ниши. В отличие от С++, который ожидает прямо противоположная участь.

Про какой именно бейсик идет речь? Имхо, под этим названием в реализациях QuickBasic, TurboBasic, VisualBasic скрывались совершенно разные языки.

E>>Почему у тебя неявно сковозит, что DSL -- это просто? DSL может быть сложен как по синтаксису, так и по семантике.

Д>Потому что это будет уже не DSL

Т.е., DSL -- это только самые простые вещи. Если что-то чуть сложнее, то это уже не DSL, так? Тогда что?

Д>Давай ты приведешь конкретный пример проблемы, которую нельзя решить относительно несложным автоматическим конвертором, а я попробую ее решить?

Давай: Makefile -> SCons или Makefile -> Boost.Build-2, или SCons -> Ant.

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

C>В новом Стандарте будет

Страуструп писал, что рабочей группе просто
C>не хватило времени на стандартизацию хэш-карты. А потом уже править
C>Стандарт нельзя по правилам ISO.

Вообще, да. 25 лет это конечно не срок чтобы такую могучую вещь стандартизовать.

... << RSDN@Home 1.2.0 alpha rev. 637>>

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

E>Чего на C++ продолжать писать, если такие проблемы с сексом?

А я на нем и не пишу. Давно уже. Как раз потому, что комитетчики давно и прочно положили болт на реальные проблемы языка.

E>Про какой именно бейсик идет речь? Имхо, под этим названием в реализациях QuickBasic, TurboBasic, VisualBasic скрывались совершенно разные языки.

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

E>Т.е., DSL -- это только самые простые вещи. Если что-то чуть сложнее, то это уже не DSL, так? Тогда что?

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

E>Давай: Makefile -> SCons или Makefile -> Boost.Build-2, или SCons -> Ant.

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

... << RSDN@Home 1.1.4 stable SR1 rev. 568>>

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

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

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

Д>А как ты определишь, что входной набор — тот самый, на котором твой алгоритм сработает?
В смысле? У нас каждый раз появляется некий фиксированный набор входных данных. Мы гарантированно определяем, остановится ли скрипт на этих входных данных.
Д>А то как-то неудобно будет, если алгоритм решения задачи останова не сможет остановиться сам

Он всегда останавливается.
Д>Алгоритм же, который гарантированно работает только на заранее установленном наборе из нескольких примеров входных данных — не особо то и нужен...
Еще раз: входные данные могут быть любыми. Просто алгоритм не отвечает на вопрос "а может ли данная программа вообще зациклиться при каких-нибудь данных".
Полное пространство возможных входов заведомо не будет использовано за все время эксплуатации скрипта.

1.1.4 stable rev. 510

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

S>В смысле? У нас каждый раз появляется некий фиксированный набор входных данных. Мы гарантированно определяем, остановится ли скрипт на этих входных данных.

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

S>Еще раз: входные данные могут быть любыми. Просто алгоритм не отвечает на вопрос "а может ли данная программа вообще зациклиться при каких-нибудь данных".

S>Полное пространство возможных входов заведомо не будет использовано за все время эксплуатации скрипта.

Ок. Случайно получилось так, что первый же входной набор подвесил скрипт. Что будет делать твой алгоритм?

... << RSDN@Home 1.1.4 stable SR1 rev. 568>>

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

E>>Про какой именно бейсик идет речь? Имхо, под этим названием в реализациях QuickBasic, TurboBasic, VisualBasic скрывались совершенно разные языки.

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

Я хотел сказать, что под именем "Бейсик" скрывались несколько разных языков. А не изменения одного языка.
Но даже если ты считаешь, что это все же был один и тот же язык, то я не уверен, что к моменту появления различных VisualBasic-ов он был серьезно популярен и имел солидную кодовую базу (сравнимую с таковой в Pascal, C, C++, Lisp, Smalltalk и пр.).

E>>Т.е., DSL -- это только самые простые вещи. Если что-то чуть сложнее, то это уже не DSL, так? Тогда что?

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

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

E>>Давай: Makefile -> SCons или Makefile -> Boost.Build-2, или SCons -> Ant.

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

Бла-бла-бла. На словах.

Д>Ты видишь здесь какие-то приципиальные проблемы, я понять не могу?

Я вижу. И вижу, что ты решил эту задачу.

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

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

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

S>>Полное пространство возможных входов заведомо не будет использовано за все время эксплуатации скрипта.

Д>Ок. Случайно получилось так, что первый же входной набор подвесил скрипт. Что будет делать твой алгоритм?
Как что? Пристрелит скрипт. Его задача собственно в том, чтобы зацикливание приводило к вылету исключения, а не к отжиранию 100% процессора навсегда.

1.1.4 stable rev. 510

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

Q>Сравнение исключительно тупое. Классическая Машина Тьюринга имеет бесконечную память, поэтому современная ЭВМ по определению не может решать бесконечное множество задач, которые подвластны МТ

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

... << RSDN@Home 1.1.4 stable SR1 rev. 568>>

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

E>Я хотел сказать, что под именем "Бейсик" скрывались несколько разных языков. А не изменения одного языка.

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

E>Но даже если ты считаешь, что это все же был один и тот же язык, то я не уверен, что к моменту появления различных VisualBasic-ов он был серьезно популярен и имел солидную кодовую базу (сравнимую с таковой в Pascal, C, C++, Lisp, Smalltalk и пр.).

Вай, как интересно. Бейсик у нас оказывается мало популярен и нераспространен? До VB были десятки диалектов, и на всех что-то писали.
Мне всего с полгода назад предлагали спортировать прогу с какого-то древнего диалекта на VB. Отказался, потому что неинтересно. А ты говоришь — кодовой базы нет.

E>DSL может быть сложен сам по себе из-за сложности предметной области.

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

E>Бла-бла-бла. На словах.

У меня нет ни времени, ни желания заниматься пенисометрией. Тратить неделю-две времени на задачу, результаты которой мне не нужны? Как-нибудь в другой жизни.

E>Я вижу. И вижу, что ты решил эту задачу.

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

... << RSDN@Home 1.1.4 stable SR1 rev. 568>>

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

D>>Спасибо, обязательно прочту, как только найду.

CS>Найди. Рекомендую.

Оно? http://www.krotov.info/lib_sec/25_sh/sha/sharden_02.htm

D>>Жизнь представляет собой процесс, и как любой физический процесс, он не может происходить без увеличения энтропии...

CS>Я бы не был столь категоричен.

Мне следовало бы уточнить, что речь идет об изолированной системе и необратимых процессах.

CS>Феномен Жизни состоит в том что во всей наблюдаемой нами Вселенной только
CS>в экосфере планеты Земля идет активный и управляемый синтез — из простых компонентов образуются сложные системы.

Это должно как-то уменьшать энтропию?

CS>Принцип неубывания энтропии (второе начало термодинамики) справедлив только для целостной изолированной системы.
CS>Постулируя что Вселенная бесконечна, а Жизнь имеет свойство экспансии (экосфера постоянно расширяется) имеем динамическую
CS>систему которая в принципе не может быть замкнута.

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

В общем-то, когда я говорил энтропия, я имел ввиду энтропию Вселенной (а не экосферы или какой-либо другой системы). Энтропия Вселенной должна увеличиваться, просто потому, что наряду с обратимыми процессами (которые не изменяют энтропию), существуют необратимые процессы (которые ее увеличивают). Человек по идее может только способствовать или препятствовать росту энтропии, но не может повернуть ее вспять. Он конечно же может уменьшить энтропию в каком-то одном месте, но при этом она обязательно увеличится в другом.

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

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

S>Совершенно верно. Другого способа не остановиться нет. Т.к. пространство состояний конечно, скрипт либо достигнет стоп-состояния, либо будет бесконечно ходить "вокруг" него.

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

S>Как что? Пристрелит скрипт. Его задача собственно в том, чтобы зацикливание приводило к вылету исключения, а не к отжиранию 100% процессора навсегда.

Допустим, что цикл у него оооочень большой. Алгоритм завершается, но через неделю. Добавив две копии скрипта и время, которое отжирает планировщик, получаем время завершения в n месяцев. Что делать будем?

... << RSDN@Home 1.1.4 stable SR1 rev. 568>>

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

VD>Вообще, да. 25 лет это конечно не срок чтобы такую могучую вещь стандартизовать.

Они просто были заняты раскладыванием и маскировкой граблей. Не до того было

... << RSDN@Home 1.1.4 stable SR1 rev. 568>>

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

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

Я хотел сказать, что за диалектами скрывались совершенно разные языки. Ну не могу я считать Basic с БК-1001 времен 1989 года диалектом того же языка, что и TurboBasic 1993 года и уж тем более современного VisualBasic.

Д>Вай, как интересно. Бейсик у нас оказывается мало популярен и нераспространен? До VB были десятки диалектов, и на всех что-то писали.

До появления VisualBasic он был, имхо, мало популярен и распространен в серьезной разработке.

Д>Мне всего с полгода назад предлагали спортировать прогу с какого-то древнего диалекта на VB. Отказался, потому что неинтересно.

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

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

Д> А ты говоришь — кодовой базы нет.

Я говорил об отсутствии серьезной кодовой базы на момент появления QuickBasic, TurboBasic и VisualBasic. А не о сегодняшнем дне.

E>>DSL может быть сложен сам по себе из-за сложности предметной области.

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

А логика откуда вылезла? В том же make не такая уж и сложная логика за DSL-ем спрятана, да еще на чистом C реализована, а сам DSL не шибко прост.

Может ты дашь описание своего видения DSL и приведешь примеры того, что ты называешь DSL-ями? А то мне кажется, что мы говорим о разных вещах.

Д>У меня нет ни времени, ни желания заниматься пенисометрией. Тратить неделю-две времени на задачу, результаты которой мне не нужны? Как-нибудь в другой жизни.

Тогда нафига было говорить:

Давай ты приведешь конкретный пример проблемы, которую нельзя решить относительно несложным автоматическим конвертором, а я попробую ее решить?

можешь решить -- реши и покажи работоспособный код. Я думаю, что за конвертер из Makefile (GNU make, к примеру) в SCons разработчики SCons-а тебе огромный THANKS выразят. А не можешь сделать, не трынди. В программирование "возможность" означает наличие работающей программы, а не умные слова о том, что кто-то проблем не видит.

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

E> Ну не могу я считать Basic с БК-1001 времен 1989 года диалектом того же языка, что и TurboBasic 1993 года и уж тем более современного VisualBasic.

А чего ты тогда ожидал от меня? Какого ответа? Пример я тебе привел, это уже твоя проблема, нравится он тебе или нет.

E>Она как. Вот тебе и цена потери совместимости.

А язык при этом цветет и пахнет. Может не совсем розами, но и не трупным запахом

E>И представь себе, что если DSL-и будут цвести и пахнуть, и при развитии DSL-ей будут плевать на сохранение совместимости, то такие многократные платежи за программу в процессе жизни программы станут обыденностью.

Значит, покупатели будут плевать на таких производителей DSLей. Если сейчас кое-кто выпустит новую версию офиса, которая категорически не открывает старые файлы, как ты думашеь — насколько далеко его пошлют?

E>Я говорил об отсутствии серьезной кодовой базы на момент появления QuickBasic, TurboBasic и VisualBasic. А не о сегодняшнем дне.

надо понимать, прогу со строками 10-20-30 и goto написали вчера? Как раз в те времена ее и написали, и надо думать, с тех самых пор использовали.

E>А логика откуда вылезла? В том же make не такая уж и сложная логика за DSL-ем спрятана, да еще на чистом C реализована, а сам DSL не шибко прост.

но не шибко и сложен.

E>Может ты дашь описание своего видения DSL и приведешь примеры того, что ты называешь DSL-ями? А то мне кажется, что мы говорим о разных вещах.

тысячу раз уже про это писал, в том числе и тебе лично. Ну не тысячу, но раза два-три точно.
Regex. XPath. XSD.
достаточно?
Что характерно, никто так и не рвется выпускать пачками версии, которые несовместимы со старыми и требуют переписывать код каждый год.

E>можешь решить -- реши и покажи работоспособный код.

Решить проблему — не то же самое, что написать код для ее решения. Алгоритм я предложил, а для написания кода у меня нет ни времени, ни желания. antlr/cocor/yacc тебе в руки, смотря что больше по вкусу. Пишешь грамматику, получаешь DOM, генеришь из него новый код.
Если хочешь рабочий код — готовь деньги, я не мать Тереза.

E>Я думаю, что за конвертер из Makefile (GNU make, к примеру) в SCons разработчики SCons-а тебе огромный THANKS выразят.

Этот THANKS будет выражаться в денежных единицах за то время, которое я на это убью?

E>А не можешь сделать, не трынди.

Есть разница между "не могу" и "не хочу". Или ты искренне думал, что я вот так сяду, заброшу всё и буду на халяву решать для тебя объемистую задачу?

... << RSDN@Home 1.1.4 stable SR1 rev. 568>>

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

E>>И представь себе, что если DSL-и будут цвести и пахнуть, и при развитии DSL-ей будут плевать на сохранение совместимости, то такие многократные платежи за программу в процессе жизни программы станут обыденностью.

Д>Значит, покупатели будут плевать на таких производителей DSLей. Если сейчас кое-кто выпустит новую версию офиса, которая категорически не открывает старые файлы, как ты думашеь — насколько далеко его пошлют?

Насколько я понимаю, VB.NET не очень совместим с VB 6. Тем не менее MS не послали. Просто потому, что это MS. Так же, как не послали MS с MFC и не послали Sun с AWT.

Речь идет не о монстрах вроде MS, Sun или IBM, или W3C с их XPath или XSD. Речь идет о DSL, которые будут разрабатывать за соседним столом. А ты будешь вынужден его использовать. Просто потому, что тебе так сказали.

E>>А логика откуда вылезла? В том же make не такая уж и сложная логика за DSL-ем спрятана, да еще на чистом C реализована, а сам DSL не шибко прост.

Д>но не шибко и сложен.

Тем не менее, корректного преобразования Makefile в SCons или Ant тебе сделать не получится.

Д>Regex. XPath. XSD.
Д>достаточно?

Это все декларативные DSL, без алгоритмических возможностей. Язык Make или язык LaTeX являются примерами не чисто декларативных DSL.

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

Что характерно, Regex описывает хорошо проработанную в теории предметную область. И при этом есть несколько несовместимых между собой синтаксисов Regex: в Perl, в Posix, в Emacs, в Vim.

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

E>>можешь решить -- реши и покажи работоспособный код.

Д>Решить проблему — не то же самое, что написать код для ее решения.

Я тебе сказал: в программировании. А не в computer science. Это в науке ты можешь что-то теоритически доказать и быть довольным как слон. А в программировании -- нет программы, нет решения. И сказки про то, что ты можешь и понимаешь, рассказывай своим работодателям.

Д>Алгоритм я предложил, а для написания кода у меня нет ни времени, ни желания.

Не было алгоритма.

Д>Пишешь грамматику, получаешь DOM, генеришь из него новый код.

Свидетельство незнания вопроса. Makefile и SCons предлагают семантически разные способы описания задачи. Так что кроме получения DOM тебе придется еще и логику преобразования одного типа описания в другое реализовывать. С учетом разных ньюансов. А если еще и потребовать, чтобы полученное SCons-описание был хотя бы понятен человеку, то все еще больше усложняется.

Д>Если хочешь рабочий код — готовь деньги, я не мать Тереза.

Это называется отмазка. Сначала -- давай задачу, решу. Затем -- алгоритм придумал, решать лень. Потом -- деньги давай.

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

E>>А не можешь сделать, не трынди.

Д>Есть разница между "не могу" и "не хочу". Или ты искренне думал, что я вот так сяду, заброшу всё и буду на халяву решать для тебя объемистую задачу?

Не вижу разницы. Задача конвертации из Makefile в SCons мне самому нафиг не упала. Ты просил пример, я тебе предложил. Ты сделать его за обозримое время и с приемлимыми накладными расходами не можешь. Что и требовалось доказать. А трындеть нужно меньше.

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

E>Насколько я понимаю, VB.NET не очень совместим с VB 6. Тем не менее MS не послали. Просто потому, что это MS.

Или просто полученные ими результаты стоили затрат?

E>Речь идет о DSL, которые будут разрабатывать за соседним столом. А ты будешь вынужден его использовать. Просто потому, что тебе так сказали.

Если мне скажут делать явную глупость, то я пойду и скажу автору данной мысли, что я о нем думаю. Благо, идти недалеко.

E>Это все декларативные DSL, без алгоритмических возможностей. Язык Make или язык LaTeX являются примерами не чисто декларативных DSL.

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

E>А в программировании -- нет программы, нет решения.

А еще там есть такое правило, нет денег — нет программы.

E>Свидетельство незнания вопроса. Makefile и SCons предлагают семантически разные способы описания задачи. Так что кроме получения DOM тебе придется еще и логику преобразования одного типа описания в другое реализовывать. С учетом разных ньюансов. А если еще и потребовать, чтобы полученное SCons-описание был хотя бы понятен человеку, то все еще больше усложняется.

Пусть так. Ну а что ты хочешь доказать то? Что если не было бы make, то вообще и проблемы бы не было?

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

А с чего ты взял, что это будет дороже, чем делать всё врукопашную?

E>Не вижу разницы. Задача конвертации из Makefile в SCons мне самому нафиг не упала. Ты просил пример, я тебе предложил. Ты сделать его за обозримое время и с приемлимыми накладными расходами не можешь.

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

... << RSDN@Home 1.1.4 stable SR1 rev. 568>>

От:	VladD2	www.nemerle.org
Дата:	02.05.06 16:09
Оценка:

	От:	Cyberax
	Дата:	02.05.06 16:47
	Оценка:

От:	eao197	http://eao197.blogspot.com
Дата:	02.05.06 17:12
Оценка:

От:	VladD2	www.nemerle.org
Дата:	02.05.06 19:02
Оценка:

	От:	Дарней
	Дата:	03.05.06 03:53
	Оценка:

От:	Sinclair	https://github.com/evilguest/
Дата:	03.05.06 04:33
Оценка: