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

VD>Именно. Кто-то тоже самое сказал о Руби. И заметь их не нразвали фанатами.

Это Зверёк был.

O>>Да, Nemerle гибок, но недостаточно для создания любого внешнего (в терминах Фаулера) DSL. Да и возможностей рефакторинга у него ноль на данный момент... Но это не означает, что в этой теме Nemerle лишний на 100%.

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

Я имел в виду, создать внешний так, чтобы он был внутренним

VD>Дисскуссия развернулась в основном с Адонцом. При этом она идет в общем-то не вокруг того плох Немерле или нет, а вокур того оправдан ли подход основанный на ДСЛ-ях. Естественно что в качесте примера приводится опыт из того языка который лучше всего подходит для ДСЛ-естроителства с нашей точки зрения. Зверек, как я понимаю, соглашаясь со мной в качестве языка для создания подразумевал использование Руби.

+1

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

E>Мужики, ну чесслово, забабахало. Может хватит поминать Nemerle на каждом шагу?
Спокойней, спокойней. Я все жду пока количество ссылок обгонит Украину. здесь

Автор: volk
Дата: 24.03.06

. Пока их всего то 2 тыщи с гаком.

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

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

VD>Это не верная логика. На ошибочном язые вообщен невозможно корректно описать задачу. Так что менять будет нечего.
Влад, проблема не в том, что можно легко написать. Проблема в том, можно ли будет этот код сопровождать. В случае библиотек(а лучше говорить императивном OOП) я знаю кучу умных книжек и методов каким образом сделать такое решение, которое будет гибким. Это значит, что в любом месте мы для какой-то функциональности можем сделать особый случай не ломая общей архитектуры. Это достаточно сложная и большая по объему наука. В случае DSL я такого не видел. Никто не применял его именно для данной задачи, и не искал подводные камни. Чем обернется внесение изменений DSL и во что это обойдется для текущей функциональности, для меня остается загадкой. Я вполне понимаю что мы практически в каждой задаче делаем свой DSL. Но я и понимаю что ожидать от текущих инструментов.

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

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

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

O>Почему вычёркиваем? Сваргать описание юнитов, подобное моему

Автор: Oyster
Дата: 10.04.06

, на C++, а потом вычеркнем. Или заявишь, что моё описание менее удобно?

Удобство это субъективный критерий, а о других я не услышал — так что равнозначно по функциональности. Вот и всё. Я не собираюсь в серьёз сравнивать решения на Nemerle и C++ потому что это очень разные языки. Это всё равно что сравнивать автобус и самосвал и доказывать, что автобус вообще для всех задач лучше, потому что там, мягкие сиденья.

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


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

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

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

O>То ж другое дело Доступно объяснить другим тяжелее, чем написать, естественно.

Это не правильный подход. Правильный — хочешь что-то хорошо понять, обясни другому.

VD>>С написанием статьи я помогу. Это не проблема. Ты хоть как-то напиши, а я подправлю/допишу.

O>Ну я попробую

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

VD>Главное приемущество внешних ДСЛ-ей заключается в том, что они не содержат (могут не содержать) в себе возможностей универсальных языков, а заначит пригодны для исользования неподготовленными пользователями.

Ты с чего это взял?
Возьми в качестве примера не собственный конфиг (кстати, там все настолько тривиально, что его и рассматривать не интересно), а тот же SQL.
А еще лучше язык TeX. Много ли найдется специалистов, способных писать макропакеты для LaTeX или CONTeX непосредственно в TeX?
Или PostScript.

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

Влад, ты неисправим. Попробуй забыть о том что у тебя в руках чудо-молоток и все проблемы вокруг выглядят как гвозди. Каким образом Nemerle сможет решать проблемы, для которых предназначены TeX и PostScript?

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

E>Ведь до сих пор на некоторых платформах C++ реализован через cfront и из C++кода генерируется C-код.
E>А из трех существующих трансляторов Eiffel два (EiffelStudio и SmartEiffel) не генерируют нативного кода, а транслируют Eiffel в C-код (так же возможна трансляция либо в MSIL (EiffelStudio), либо в Java byte code (SmartEiffel)).

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

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

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

E>Влад, ты неисправим. Попробуй забыть о том что у тебя в руках чудо-молоток и все проблемы вокруг выглядят как гвозди. Каким образом Nemerle сможет решать проблемы, для которых предназначены TeX и PostScript?

На нём легко писать сканеры и парсеры для external DSL как и на Ocaml, например.

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

O>На нём легко писать сканеры и парсеры для external DSL как и на Ocaml, например.

Если вести речь о качествах external DSL (удобство использования или степень соответствия решаемой задачи), то язык, на котором реализован сканер и парсер external DSL не имеет совершенно никакого значения

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

E>>Ведь до сих пор на некоторых платформах C++ реализован через cfront и из C++кода генерируется C-код.
E>>А из трех существующих трансляторов Eiffel два (EiffelStudio и SmartEiffel) не генерируют нативного кода, а транслируют Eiffel в C-код (так же возможна трансляция либо в MSIL (EiffelStudio), либо в Java byte code (SmartEiffel)).

Д>к разграничению DSL/не DSL это не имеет никакого отношения.

А смайлик в выброшенном тобой предложении из моего поста был намеряно проигнорирован?

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

O>>На нём легко писать сканеры и парсеры для external DSL как и на Ocaml, например.

E>Если вести речь о качествах external DSL (удобство использования или степень соответствия решаемой задачи), то язык, на котором реализован сканер и парсер external DSL не имеет совершенно никакого значения

Конечно. Это я отвечал на вопрос о том, почему Влад приплёл Nemerle к внешним DSL.

А вообще на Nemerle действительно легко делать такие штуки. Например, мне безумно понравился пример чего-то вроде ANTLR на макросах, который Влад уже приводил. К сожалению, nemerle.org с какой-то радости недоступен так что ссылку кинуть не могу...

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

E>А смайлик в выброшенном тобой предложении из моего поста был намеряно проигнорирован?

не хватает слова "лопата", так что до меня не дошло, где смеяться

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

Д>>к разграничению DSL/не DSL это не имеет никакого отношения.

E>А смайлик в выброшенном тобой предложении из моего поста был намеряно проигнорирован?

Даже со смайликом тяжело рассматривать C++ или Eiffel как Domain-Specific Language

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

O>Даже со смайликом тяжело рассматривать C++ или Eiffel как Domain-Specific Language

А если в качестве Domain взять Object-Oriented & Generic Programming, а жирным выделить Language?

И если сравнение C++ и Eiffel с DSL кажутся дикими, то как на счет Objective-C?

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

E>А если в качестве Domain взять Object-Oriented & Generic Programming, а жирным выделить Language?

Всё равно не смешно.

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

A>Чтобы добавить номер версии. вообще я просто привёл пример смены приоритетов. придумывать для такой замены смысл я не буду — это всего лишь пример.

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

A>Потому что в когда Си++ придумывали никто грабли не проектировал, однако он есть Пока не начнёшь использовать что-то каждый день — недостатков не увидишь.

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

A>Вааа наконецто!

Что на конец-то? Этот примерчик прото детская игрушка по сравнению с другими примерами.

A> Уже лучше!

Лучше чем, простите, что?

A>Да, признаю, некоторая ощютимая польза от макросов Nemеrle есть при сохранении условия простоты использования.

О! И я о том же. И это только мелкий примерчик...

Добрый день.
Почитал я тут споры на счет трудности освоения DSL, за и против и тд.
И набросал небольшой примерчик как я понимаю эту тематику. Очень хотелось бы чтобы кто-нибудь попинал.

Для демонстрации нового подхода попробуем разработать систему “Расписание движения поездов метро”.
1. Анализ предметной области.
Предметная область, в которой будет работать наша система, будет метрополитен. Система должна рассчитать расписание движения поездов для метрополитена по различным входным параметрам, таким как загруженность линии, времени суток, количество персонала. Мы хотим, чтобы наша система была универсальной и подходила для описания схемы любого метрополитена. Для этого нужно разработать всю модель системы на предметном языке, а затем сгенерировать по ней некоторое ядро, а настраивать его будут пользователи системы.
2. Проектирование предметной области.
Основные элементы, которые будут входить в нашу систему это:
1) Станция метро и её набор характеристик.
2) Поезд метро и его набор характеристик.
3) Переход между станциями и его набор характеристик.
4) Переезд между станциями и его набор характеристик.
5) Пассажир метро и его набор характеристик.
6) Персонал метро и его набор характеристик.
3. Реализация предметной области.
Разрабатываем алгоритм составления расписания, который работает с объектами предметной области.
Создаем команды нашего языка для манипулирования объектами предметной области:
1) Создать станцию метро (Характеристика1,…).
2) Создать переезд между станция_1 и станция_2(Характеристика 1,…).
3) Создать переход между станция_1 и станция_2(Характеристика 1,…).
4) Задать количество пассажиров на станции между время_1 и время_2(Характеристика 1,…).
5) Создать поезд (Характеристика 1,…).
6) Создать машиниста (Характеристика 1,…).
7) Создать расписание.
На данном этапе мы сделали модель предметной области и разработали язык для её описания и изменения. Язык описан в виде текста, но в общем случае это может быть что угодно: текст, таблицы, диаграммы или схемы. Функции этого языка сильно ограничены, но их достаточно для решения поставленной задачи. Теперь это концептуальное решение необходимо перевести в исходный код системы по следующим пунктам:

1 Необходимо разработать генераторы, которые смогут преобразовать понятия “Станция метро”, “Поезд метро” в классы универсального языка программирования.
Например:
Понятие “Станция метро” будет преобразовано следующим образом:

Class MetroStation
{
    String Name;
    ...
}

Все остальные объекты предметной области преобразуются аналогично.

2 При получении команды наша система должна сделать разбор команды, по возможности оптимизировать её и проверить на наличие ошибок(например попытку создания станции с пустым именем). После проверок наша система должна преобразовать команду из понятий предметной области в код. Например, команда “Создать станцию метро” может быть преобразована в следующий код

metroStations.add(new MetrosStation(“Невский проспект”,…));

Разработка системы завершена. Всю остальную настройку и доработку можно выполнить силами специалистов предметной области(Заказчиков).Этот пример очень простой для понимания принципов программирования в новом стиле, но его можно было бы расширить, добавив в команды функции создания новых элементов языка наравне с остальными, например, добавить понятие наземного перехода между станциями.
Узким местом в этом примере является создание генераторов из концептуальной модели в код и проверка на корректность тех команд, которые вводит пользователь. Только невозможность автоматизировать этот процесс сводит на нет все достоинства новой методологии.
Для того чтобы этот метод программирования заработал,необходимо, чтобы после разработки предметно ориентированного языка, позволяющего строить схему метро, программист смог использовать в своей программе некоторый редактор, что бы пользователи смогли спроектировать в нём метро своего города.

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


Спасибо

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

A>А какая есть визуальная поддержка рефакторинга? Переименовать класс/метод? И сё? Не густо.

Это NetBean



Я, лично , часто пользуюсь "Rename" и "Encapsulate Fields..."

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

E>Может в данной теме это и оффтопик, но вот статья о другом подходе к разработке DSL, на основе существующего языка (Ruby, как можно было догадаться ):
E>Взято из Ruby Code & Style.

Кстати, там идет интересное обсуждение: http://www.artima.com/forums/flat.jsp?forum=106&thread=155752
Цитата из первого поста:

Building DSLs is the bread and butter of Smalltalk (and Lisp) programming, but is a bit of a struggle in the Java (and similar) worlds. The big vendors are attempting to fix this through the use of mighty tools in the interests of supporting a new-but-old-but-new model of development, a rather fishy proposition at best.

This is symptomatic of one way in which the industry has decayed. The message of Smalltalk (and Lisp) is that the route to productivity is to use simple tools with few features and allow everyone interested to build upon them. The favoured route at the moment is to encode every good idea into an all-singing all-dancing "solution", take it or leave it.