Здравствуйте, AlexRK, Вы писали:
WH>>1)Просто по тому, что для решения той же задачи на библиотеке будут написаны тысячи, а то и миллионы кода. ARK>Ну, это другой уже вопрос.
Да нет. Тот же.
Ибо если ты сломаешь библиотеку, то тебе придется чинить на порядок другой больше кода.
А это само по себе делает изменение интерфейса библиотеки более намного более болезненным, чем изменение ДСЛ.
ARK>Вот в это я поверить не могу. Каким это магическим образом можно легко изменить весь код? Рефакторинг и в обычном коде иногда сложен, а с DSL...
Не нужно верить. Нужно просто понять, что можно написать компилятор из старого в новый.
Более того на основе этого компилятора можно получить автоматическое превращение старого в новый.
ARK>А если этот DSL-код еще где-нибудь в строковых литералах лежит, как SQL?
Так я же не про строковые литералы говорю. А про нормальные языки.
WH>>3)Многие вещи, которые требуют изменения интерфейса библиотеки можно делать без изменения ДСЛ. ARK>И наоборот.
Лож.
WH>>Например, я полностью изменил реализацию парсера при этом синтаксис и семантика не изменились. ARK>Ну, частный случай.
Только что-то он у меня регулярно повторяется.
Причем не только с парсером. Но и с другими ДСЛ.
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Re[22]: А при чем тут DSL? (в продолжении темы о языках общего назначения)
Здравствуйте, WolfHound, Вы писали:
ARK>>Вот в это я поверить не могу. Каким это магическим образом можно легко изменить весь код? Рефакторинг и в обычном коде иногда сложен, а с DSL... WH>Не нужно верить. Нужно просто понять, что можно написать компилятор из старого в новый.
Угу, просто компилятор написать. Элементарно, Ватсон.
WH>>>3)Многие вещи, которые требуют изменения интерфейса библиотеки можно делать без изменения ДСЛ. ARK>>И наоборот. WH>Лож.
Почему?
WH>>>Например, я полностью изменил реализацию парсера при этом синтаксис и семантика не изменились. ARK>>Ну, частный случай. WH>Только что-то он у меня регулярно повторяется. WH>Причем не только с парсером. Но и с другими ДСЛ.
Реализацию и для библиотеки можно менять без изменения интерфейса.
Re[23]: А при чем тут DSL? (в продолжении темы о языках общего назначения)
Здравствуйте, Ikemefula, Вы писали:
I>Да все просто, в linq том же мне незачем приседать, что бы выяснить, что же там происходит. В принципе, с макросами почти так же, только дольше. А вот с дсл где взять внутренности вычислительной модели ?
Открываешь, исходники ДСЛ и читаешь.
I>Да как бы понятно — чего требуется от ДСЛ. Относительно автокомплитов и интелисенсов ты немного погорячился.
Почему? Есть весьма чёткий план как это сделать.
I>Нужен не просто рефакторинг, нужна возможность заглянуть внутрь модели, возможность изменить не название кейворда, а его семантику. Это уже получаются миграции, а не рефакторинг. На примере SQL или регэксов хорошо видно.
И часто тебе нужно сделать так чтобы метод Insert всю базу грохал?
I>На счет кривизны и тормознутости сумлеваюсь.
Это факты.
I>И рукописная модель тоже дсл. Светлое бущущее про которые ты говоришь уже давно настало, опаньки !
I>Кстати, ты рослин уже обогнал по перформансу или нет ?
Парсер я скорей всего не обгоню. Ибо они разбирают фиксированный язык, а я работаю с расширяемым. Это требует дополнительной работы.
Но не сильно отстать смогу. Хотя есть уйти в натив... может и получится.
А вот их типизатор скорей всего обгоним.
При этом когда Н2 взлетит создание новых языков будет на порядки дешевле чем добавление нового языка в рослин.
Мы даже сможем без проблем сделать макросы для C#, VB.NET, Java итп.
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Re[23]: А при чем тут DSL? (в продолжении темы о языках общего назначения)
Здравствуйте, AlexRK, Вы писали:
ARK>Угу, просто компилятор написать. Элементарно, Ватсон.
С нормальными инструментами действительно элементарно.
WH>>>>3)Многие вещи, которые требуют изменения интерфейса библиотеки можно делать без изменения ДСЛ. ARK>>>И наоборот. WH>>Лож. ARK>Почему?
Ну, покажи пример, когда наоборот.
ARK>Реализацию и для библиотеки можно менять без изменения интерфейса.
Если повезёт. А на практике ДСЛ скрывает реализацию неизмеримо лучше, чем библиотека.
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Re[24]: А при чем тут DSL? (в продолжении темы о языках общего назначения)
Здравствуйте, WolfHound, Вы писали:
WH>Здравствуйте, AlexRK, Вы писали:
ARK>>Угу, просто компилятор написать. Элементарно, Ватсон. WH>С нормальными инструментами действительно элементарно.
"С нормальными инструментами что угодно сделать элементарно". Высказывание примерно того же типа.
WH>>>>>3)Многие вещи, которые требуют изменения интерфейса библиотеки можно делать без изменения ДСЛ. ARK>>>>И наоборот. WH>>>Лож. ARK>>Почему? WH>Ну, покажи пример, когда наоборот.
Сперва покажите пример, когда библиотеку надо менять, а DSL нет.
ARK>>Реализацию и для библиотеки можно менять без изменения интерфейса. WH>Если повезёт. А на практике ДСЛ скрывает реализацию неизмеримо лучше, чем библиотека.
На вашей практике может и так. А когда (и если) будет такая практика у крутого архитектора из новозадрищенска — вот тогда и посмотрим, что лучше скрывает. Правда, это при нашей жизни вряд ли будет.
Re[23]: А при чем тут DSL? (в продолжении темы о языках общего назначения)
Здравствуйте, hardcase, Вы писали:
H>Здравствуйте, AlexRK, Вы писали:
ARK>>Угу, просто компилятор написать. Элементарно, Ватсон.
H>Тут кто-то еще боится слова "компилятор"? Это так в универе напугали, что сей страх все еще преследует по жизни?
Ваше шапкозакидательство весьма забавно.
Re[25]: А при чем тут DSL? (в продолжении темы о языках общего назначения)
Здравствуйте, AlexRK, Вы писали:
ARK>Ваше шапкозакидательство весьма забавно.
Ваша боязнь компиляторостроения весьма забавна. Уже сегодняшних инструментах совершенно обычному программисту по силам наколбасить компилятор простого паскалеобразного языка с автоматическим управлением памятью под пачку платформ и архитектур за крайне разумное время (для первого прототипа недельки будет достаточно). А тут речь шла про транслятор с одного языка в другой не слишком отличающийся, гипотетический пример уровня сложности задачи: транслятор из C# 2.0 в C# 3.0 делающиий подстановки var где возможно и заменяющий delegate на лямбды, и все это при наличии типизатора для обоих ревизий C#. Да такие задачи можно решать, что называется, не отрываясь от RSDN-а!
/* иЗвиНите зА неРовнЫй поЧерК */
Re[20]: А при чем тут DSL? (в продолжении темы о языках общего назначения)
Здравствуйте, WolfHound, Вы писали:
I>>иначе будет как с SQL, большинство использует "по рецептам", малая часть думает что знает, и только ничтожная действительно знает SQL. I>>С регэксами тож самое, перестал пользоваться на время — все забыто и надо снова документацию перечитывать. WH>Я бы посмотрел на то как ты руками будешь выписывать работу с файлом с ACID в полный рост. Или хотя бы ДКА для разбора текста.
А какое отношение ACID имеет к ds*L*?
Re[21]: А при чем тут DSL? (в продолжении темы о языках общего назначения)
Здравствуйте, AndrewVK, Вы писали:
AVK>У большой тройки, если не брать экзотики, SQL'99 поддержан на 100%. У второго эшелона ситуация почти такая же, даже FB с его чудесами подтянулся. Так что расширения синтаксиса есть, изменений относительно базового нет.
На вскидку:
1. совершенно разный синтаксис для identity (mssql — identity, mysql — auto_increment, postgresql — serial кажется);
2. у версионников и блокировочников по сути совершенно различные реализации параллелизма — далеко не последнего аспекта работы серверов.
Re[13]: А при чем тут DSL? (в продолжении темы о языках общего назначения)
Здравствуйте, Ikemefula, Вы писали:
I>Не знаю, как ты считал это доминирование, я через день нахожу в разных проектах самопальные парсеры Если посчитать количество этих самопальных парсеров, сильно сомневаютьс, что регэксы будут доминировать.
Гыгы, кстати +100. А я эти самопальные парсеры пишу.
Re[22]: А при чем тут DSL? (в продолжении темы о языках общего назначения)
Здравствуйте, dimgel, Вы писали:
D>1. совершенно разный синтаксис для identity (mssql — identity, mysql — auto_increment, postgresql — serial кажется);
На так потому что не покрывается стандартом (хотя я 2008 стандарт не смотрел внимательно). Вот и изобретает каждый во что горазд. Та же ситуация с ограничением выборки — стандартизовано только в 2008, да и то как то по уродски.
D>2. у версионников и блокировочников по сути совершенно различные реализации параллелизма — далеко не последнего аспекта работы серверов.
Это не имеет отношения ни к семантике самого языка, ни тем более к синтаксису. От того, что писанная на С# программа на рантайме дотнета и моно в некоторых моментах ведет себя по разному, шарп не становится двумя разными языками.
... << RSDN@Home 1.2.0 alpha 5 rev. 66 on Windows 8 6.2.9200.0>>
Как минимум, пока не сделали квазицитаты. Но с хорошей вероятностью и потом буду бояться, потому что сколько-нибудь нетривиальные вещи квазицитатами не обойдутся, и будет там адъ. Собственно, новый scala-reflect.jar уже сам по себе — адъ, а разработчики скалы им вполне довольны. И в этом адъу придётся разбираться, чтобы понять, что происходит. Староват я уже в таких наворотах разбираться, тем более, что требоваться это знание будет настолько редко, что каждый раз придётся заново изучать.
Re[26]: А при чем тут DSL? (в продолжении темы о языках общего назначения)
Здравствуйте, hardcase, Вы писали:
H>Уже сегодняшних инструментах совершенно обычному программисту по силам наколбасить компилятор простого паскалеобразного языка
Жаль только оно нафик никому кроме студентов не нужно.
... << RSDN@Home 1.2.0 alpha 5 rev. 66 on Windows 8 6.2.9200.0>>
Здравствуйте, Ikemefula, Вы писали:
K>>А примеры не из мира компиляторостроения должны выдавать разрабы, не создающие сам N, а пользующиеся им.
I>Ага, должны. А что еще должны эти разрабы ? I>Обычно разработчики инструментария обычно хорошо в курсе потребностей своей целевой аудитории. I>А вот немерлисты почему то хорошо в курсе только компиляторов. Так шта...
А ты задайся вопросом, сколько написали библиотек те разрабы, которые создают компилятор C#. Насколько мне известно, некоторые из них присутствуют здесь, на RSDN. Так сколько они написали кода, не относящегося к компилятору? Естественно, имеется в виду, пока она работают (работали) над самим компилятором.
Как-то странно требовать прикладной код от системных программистов, не находишь?
Между тем, я для себя нашёл немало примеров макросов, написанных именно для прикладных целей. Это не полноценные DSL, а упомянутые мной однострочные NotNull и т. п. Так шта, было бы желание...
Здравствуйте, Ziaw, Вы писали:
Z>Хотелось бы увидеть альтернативы этим DSL, ну и документацию к ним. Чтобы все, наконец, смогли понять чего следует бояться в DSL.
Я полагаю, именно пример printf из Nemerle можно приводить в качестве того, почему не следует бояться макросов. Как известно, в языках C, C++, C# и многих других строковые литералы (строки форматирования в printf, Console.Write, String.Format, регулярки в виде строк, выражения XPath и пр.) не проверяются на этапе компиляции; в случае банальной опечатки ошибка выпадет в рантайме. Макрос printf в Nemerle проверяет формат в компайл-тайме. Мелочь, а приятно. Не нужен ни решарпер, ни утилиты статического анализа кода, ни лишние тесты.
Re[8]: А при чем тут DSL? (в продолжении темы о языках общего назначения)
Здравствуйте, Ziaw, Вы писали:
Z> a.Insert(b) и insert b into a
Я именно такие примеры имел в виду, когда писал ранее о плохой подаче информации о макросах и дслях. Большинство обучающих примеров сделаны именно так: сперва пишется некая простая функция (Insert()), потом она заменяется на макрос (insert into). В итоге читатель не видит никакой разницы, уменьшения кода не происходит, понимание не улучшается.
Информацию следует подавать по другому: брать приличный кусок кода, который невозможно сократить с помощью стандартных средств (языки без МП), и показывать пример, как этот код может быть заменён однострочным макросом. Для затравки, привития интереса — самое то.
Re[6]: А при чем тут DSL? (в продолжении темы о языках общего назначения)
Здравствуйте, koodeer, Вы писали:
I>>Ага, должны. А что еще должны эти разрабы ? I>>Обычно разработчики инструментария обычно хорошо в курсе потребностей своей целевой аудитории. I>>А вот немерлисты почему то хорошо в курсе только компиляторов. Так шта...
K>А ты задайся вопросом, сколько написали библиотек те разрабы, которые создают компилятор C#. Насколько мне известно, некоторые из них присутствуют здесь, на RSDN. Так сколько они написали кода, не относящегося к компилятору? Естественно, имеется в виду, пока она работают (работали) над самим компилятором.
Когда вышел C#, от микрософта сразу вышел целый вагон примеров и разных приложений чуть не на все случаи жизни. Я например по ним и учился. Собтсвенно у них всегда так, из последнего это например TypeScript. Вышел язык, еще альфа, но уже есть целая куча примеров, которые полезны для потребителя.
K>Как-то странно требовать прикладной код от системных программистов, не находишь?
Абсолютно нормально, когда разработчик языка пишет на нём типовые сценарии потребителей еще задолго до выпуска версии. А вот у немерлистов типовой сценарий это компилятор немерле.
Собтсвенно в нормальных языках и хороших либах ровно так же — примеров и готовых решений на порядок больше, чем кода относящегося к проекту.
Re[22]: А при чем тут DSL? (в продолжении темы о языках общего назначения)
M>>Как ты там рядом говорил? Легкая трансформация? Вот мы трансформировали наш SQL на использование window functions вместо linit x,y. ВНЕЗАПНО оказалось, что все у всех перестало работать. А как же сказки о безболезненном изменении DSL
? WH>Ты можешь взять другой ДСЛ который это всё прячет. Например linq.
Всех клиентов все равно придется менять
WH>Или сделать транслятор стандартного SQL в конкретный диалект. WH>Но научить БД не изменяя саму БД ессно нельзя. WH>Я же всегда говорил в контексте того что мы можем править компилятор.
Если у тебя есть возможность менять компилятор DSL, значит у тебя есть возможность менять библиотеку Почему внезапно ты пишешь, что библиотеку менять сложнее или нельзя ее поменять без изменения интерфейса?
Здравствуйте, koodeer, Вы писали:
K>Я полагаю, именно пример printf из Nemerle можно приводить в качестве того, почему не следует бояться макросов. Как известно, в языках C, C++, C# и многих других строковые литералы (строки форматирования в printf, Console.Write, String.Format, регулярки в виде строк, выражения XPath и пр.) не проверяются на этапе компиляции; в случае банальной опечатки ошибка выпадет в рантайме. Макрос printf в Nemerle проверяет формат в компайл-тайме. Мелочь, а приятно. Не нужен ни решарпер, ни утилиты статического анализа кода, ни лишние тесты.
Ты путаешь результа и его достижение. Что бы выяснить, почему люди боятся макросов, надо выкатить код самого макроса printf а уже потом делать выводы.
