В начале хотел отписаться в соседней темке, но потом понял, что не укладываюсь в её направление, так что сделаю отдельную. Да, и сразу хочу сказать, что вопросы платформ тут обсуждать не хочу — на этот предмет я уже полностью высказался в соседних темах. Т.е. понятно, что, если какой-то инструмент будет реализован скажем только под какой-нибудь там .net, то он будет отброшен из рассмотрения ещё до оценки его "dsl возможностей". Но здесь мы это обсуждать не будем — можно пока условно считать, что все инструменты реализованы под все платформы.

И так DSL. На мой взгляд вся эта область делится на две принципиально разных части: dsl исполняемые в процессе разработки ПО и dsl исполняемые в процессе работы ПО. Рассмотрим по отдельности.

1. DSL исполняемые в процессе работы ПО.

Речь о так называемых встроенных скриптах. Даже не буду приводить примеры — используется почти во всём сложном ПО. Гораздо интереснее рассмотреть способы реализации:

А. В большинстве случаев наиболее логичным и эффективным способом является встраивание какого-то из интерпретируемых языков общего назначения, с добавлением набора специфических для предметной области функций. Чаще всего это Lua, Python, JavaScript, но может быть и Lisp, Prolog и т.п. Конкретная реализация тривиальна: подключаем библиотеку языка, регистрируем свои предметные функции в движке; если требуется редактирование скриптов пользователем в самом приложение, то берём что-нибудь вроде QScintilla(там даже некое автодополнение работать будет). Данный подход позволяет не только получить "на халяву" готовый отлаженный интерпретатор, но и что самое главное, вылизанный годами эволюции синтаксис языка. Обычно разница с велосипедами очевидна (например достаточно взглянуть на убогий вид cmake скриптов в сравнение с scons/waf(использующие Python)). Но не всегда...

Б. В некоторых случаях всё же лучше разработать свой язык. Как успешный пример, используемый лично мною, могу назвать скажем OpenSCAD. Здесь, на мой взгляд, самым сложным является именно проектирование удобного непротиворечивого языка. И я не представляю какие инструменты (кроме ручки, бумаги и мозгов) могут помочь в этом. Так же очень важно хорошее знание предметной области. Однако после придумывания языка уже никаких особых проблем не возникает. Мы записываем формальную грамматику, берём какой-нибудь flex+bizon (или их аналоги для других платформ) и получаем готовый парсер. Интерпретатор же синтаксического дерева в таких случая обычно является просто исполнителем функций предметной области. В общем всё просто и уже давно разработано. Ну можно ещё добавить синтаксический модуль для нового языка в QScintilla, если требуется редактирование в самом приложение (как в том же OpenSCAD).

2. DSL исполняемые в процессе разработки ПО.

Обычно применяются для повышения эффективности работы программиста на каком-то языке общего назначения. Соответственно реализация очень сильно зависит от возможностей этого языка:

А. Реализация DSL через различные препроцессоры. В принципе не сложная вещь, применяемая обычно для мелких расширений базового языка. Соответственно это наиболее актуально для всяких там слабых языков (а зачем нам такие?). Хотя и в том же C++ есть свои известные вариации: moc (из Qt), ODB, AspectC++ и т.п. Однако для сильных развивающихся языков (а в особенности с наличием метапрограммирования) данный подход на мой взгляд является тупиковым. К примеру moc можно было давным давно выкинуть из Qt, а ODB после выхода нового стандарта. Ну и плюс надо отметить, что у этого подхода обычно большие проблемы с редакторами кода.

Б. Реализация DSL средствами самого языка (EDSL). Понятно, что в первую очередь тут идёт речь об использование метапрограммирования, причём только времени компиляции. Большинство динамических языков обладают базовой возможностью метапрограммирования, но т.к. оно отрабатывает только во время исполнения программы, то к повышению эффективности работы программиста это имеет слабое отношение (максимум синтаксический сахар). Т.е. в итоге сюда попадает один мейнстрим язык и несколько языков второго эшелона. В общем случае разработка EDSL вдвойне сложная задача, т.к. требуется одновременно и разработать удобный новый язык и как-то вместить его в синтаксис базового. Однако на моей практике я чаще всего встречался с EDSL, являющимися встроенными реализациями каких-то уже готовых известных языков, так что авторам оставалась только половина проблемы. Как примеры для C++: регулярные выражения — Boost.Xpressive, грамматики — Boost.Spirit, SQL — sqlpp11. Ещё бывает просто прямое отображение предметной области типа Boost.Unit — физические размерности. Или более сложный пример из D: html шаблонизатор в vibe.d, поддерживающий вставки нативного кода, является реализацией синтаксиса jade (а те утащили его у Haml). Кстати, с возможностями нового стандарта C++ можно попробовать замахнуться на подобные вещи и уж точно можно переписать указанные выше библиотеки вообще без синтаксического шума (задавать DSL конструкции обычными строками, но при этом разбираемыми во время компиляции). В целом с выходом нового стандарта и появлением в boost'е набора библиотек поддержки, метапрограммирование на том самом мейнстрим языке перестаёт быть таким уж диким кактусом, как было когда-то. Что довольно печально для языков второго эшелона, главным преимуществом которых является развитое метапрограммирование. Хотя до реального удобства конечно же ещё очень далеко. Ну и отдельно можно заметить, что данный подход не приносит никаких проблем с редакторами кода. Правда и автодополнения по EDSL языку тут получиться не удастся.

Подводя итоги.

Если мы говорим о каких-то инновационных инструментах для работы с DSL (Nemerle, Nitra и т.п.), то как я понял (поправьте, если что), они могут относиться только к пункту 2.Б. А что у нас тут может быть инновационного? Поддержка каких-то очень сложных EDSL? Сомнительно... Кстати, а хотя бы поддержка тех, что есть у мейнстрим языка имеется? Т.е. могу я скачать готовые к продакшену EDSL библиотеки работы с sql, регулярными выражениями, физическими размерностями, html-шаблонизатор с нативными вставками и т.п? Ну и даже если могу, то всё равно этого мало — новому языку надо быть заметно лучше мейнстрима, чтобы были какие-то шансы. Насколько я помню у Nemerle тут была одна потенциальная киллер-фича — автодополнение по EDSL. Но она же вроде только для одной сомнительной IDE, что опять же вычёркивает это преимущество для очень многих пользователей. И вряд ли есть путь, как расширить это на все редакторы. В итоге я пока так и не понял, что в принципе инновационного могут принести эти решения в работу с DSL. Даже если бы они были реализованы под все платформы, а не только под .net.

P.S. Оффтопик. Написал всё это и увидел, что в принципе в выборе .net'a есть определённый смысл: 1. там нет никаких конкурентов по МП, 2. там общепринята та самая IDE. В итоге при таком раскладе уже появляются определённые шансы... Конечно при условии, что многим .net программистам интересны подобные сложные темы (про это я уже высказывал большие сомнения).

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

_>И так DSL. На мой взгляд вся эта область делится на две принципиально разных части: dsl исполняемые в процессе разработки ПО и dsl исполняемые в процессе работы ПО. Рассмотрим по отдельности.
Не думаю, что есть смысл разделять.

_>А. В большинстве случаев наиболее логичным и эффективным способом является встраивание какого-то из интерпретируемых языков общего назначения, с добавлением набора специфических для предметной области функций.
И получаем тормоза и отсутствие статических проверок предметной области.

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

_>но и что самое главное, вылизанный годами эволюции синтаксис языка.
Синтаксис языка высасывается из пальца при его создании и никогда не меняется.
Так что не ясно, о какой эволюции ты говоришь.

В любом случае синтаксис дело десятое. Главное определить сущности предметной области.

_>Здесь, на мой взгляд, самым сложным является именно проектирование удобного непротиворечивого языка.
Он получается автоматически после того как определены сущности предметной области.

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

_>Однако после придумывания языка уже никаких особых проблем не возникает. Мы записываем формальную грамматику, берём какой-нибудь flex+bizon (или их аналоги для других платформ) и получаем готовый парсер.

1)Записать под них грамматику это те ещё пляски с бубном.
2)Восстановление после ошибок там считай что нет. Да и сами сообщения о ошибках такие, что волосы дыбом встают.
3)Что с типизацией делать будешь?

_>А. Реализация DSL через различные препроцессоры. В принципе не сложная вещь, применяемая обычно для мелких расширений базового языка. Соответственно это наиболее актуально для всяких там слабых языков (а зачем нам такие?).
С++ слабый. Я знаю про все его фишки. Просто я ещё и альтернативы знаю.

_>Ну и плюс надо отметить, что у этого подхода обычно большие проблемы с редакторами кода.
У С++ вообще проблемы с редакторами кода.

_>Большинство динамических языков обладают базовой возможностью метапрограммирования, но т.к. оно отрабатывает только во время исполнения программы, то к повышению эффективности работы программиста это имеет слабое отношение (максимум синтаксический сахар).
Это не правда. Наметапрограммировать на динамически типизированных языках можно очень много. Банальным сахаром они не ограничиваются.
Проблемы динамики: Тормоза и баги. Поэтому я и считаю все динамически типизированные языки ошибкой природы.

_>Т.е. в итоге сюда попадает один мейнстрим язык и несколько языков второго эшелона. В общем случае разработка EDSL вдвойне сложная задача, т.к. требуется одновременно и разработать удобный новый язык и как-то вместить его в синтаксис базового.
А ещё приходится бороться с убогой системой "метапрограммирования" С++ (ты же про него говоришь).

_>Кстати, с возможностями нового стандарта C++ можно попробовать замахнуться на подобные вещи и уж точно можно переписать указанные выше библиотеки вообще без синтаксического шума (задавать DSL конструкции обычными строками, но при этом разбираемыми во время компиляции).
Знал бы ты как немерле за такое с говном смешивают.

Линк в строке? ААААА!!! УУУУ!!!! КОООООШШШМАААР!!!

Ну и добавим сюда традиционные для С++ тормоза при компиляции и километровые сообщения об ошибках.

Нитре программирование в строках уже не нужно. Там парсер намного мощьнее, чем у немерле.

_>В целом с выходом нового стандарта и появлением в boost'е набора библиотек поддержки, метапрограммирование на том самом мейнстрим языке перестаёт быть таким уж диким кактусом, как было когда-то.
Не перестаёт.

_>Ну и отдельно можно заметить, что данный подход не приносит никаких проблем с редакторами кода.
Они как не работали, так и продолжат не работать.

_> Если мы говорим о каких-то инновационных инструментах для работы с DSL (Nemerle, Nitra и т.п.), то как я понял (поправьте, если что), они могут относиться только к пункту 2.Б.
Не только.
Компиляторы Nemerle и Nitra реализованы в виде ДЛЛ.
И нет никаких проблем запустить и во время исполнения.
Включая все сервисы ИДЕ внутри своего приложения. Те не "некое автодополнение", а полноценную ИДЕ с подсветкой типов, навигацией, полноценным автодополением, рефакторингом переименования, подсветкой ошибок в реальном времени итп.
[Nitra] Autocompletion

Автор: VladD2
Дата: 10.06.15

_>А что у нас тут может быть инновационного? Поддержка каких-то очень сложных EDSL?
Не только.
Ещё и куча мелких специфических для задачи улучшений, которые могут сократить код в разы.

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

_>Т.е. могу я скачать готовые к продакшену EDSL библиотеки работы с sql, регулярными выражениями, физическими размерностями, html-шаблонизатор с нативными вставками и т.п?
Можешь.

_>Ну и даже если могу, то всё равно этого мало — новому языку надо быть заметно лучше мейнстрима, чтобы были какие-то шансы. Насколько я помню у Nemerle тут была одна потенциальная киллер-фича — автодополнение по EDSL.
Да их тьма.

_>Но она же вроде только для одной сомнительной IDE, что опять же вычёркивает это преимущество для очень многих пользователей.
Оно к ИДЕ вообще не привязано.
Просто не нашлось желающих сделать это под другие ИДЕ. Вернее желающие были, но до рабочего состояния не довели.
Ибо засунуть поддержку языка в ИДЕ само по себе не простое занятие.
Ибо у каждой ИДЕ куча своих тараканов.

Интересно, что в языках и средах, где разделения на стадии компиляци и выполнения нету (т.е. динамических ЯП), DSL — это не «отдельная сложная идея», а простой и общепринятый паттерн проектирования. Т.е. в большой степени, любая domain specific library склонна определятя соответствующий своим целям domain specific language

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

_>>И так DSL. На мой взгляд вся эта область делится на две принципиально разных части: dsl исполняемые в процессе разработки ПО и dsl исполняемые в процессе работы ПО. Рассмотрим по отдельности.
WH>Не думаю, что есть смысл разделять.

Разница принципиальна. Одно — это инструмент создания приложения, а другое — это инструмент кастомизации готового приложения.

_>>А. В большинстве случаев наиболее логичным и эффективным способом является встраивание какого-то из интерпретируемых языков общего назначения, с добавлением набора специфических для предметной области функций.
WH>И получаем тормоза и отсутствие статических проверок предметной области.

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

Насчёт тормозов вопрос спорный. Если мы говорим о встроенных скриптах, то там же вся реальная работа происходит на базовом языке, а скриптовой играет роль системного клея. Для примера могу посоветовать попробовать посоревноваться на Nemerle в быстродействие численной математики скажем с Питоном, к которому подключён NumPy.

_>>но и что самое главное, вылизанный годами эволюции синтаксис языка.
WH>Синтаксис языка высасывается из пальца при его создании и никогда не меняется.
WH>Так что не ясно, о какой эволюции ты говоришь.

Ну да, т.е. C#6.0 вообще ничем не отличается от C#1.0... )))

_>>Однако после придумывания языка уже никаких особых проблем не возникает. Мы записываем формальную грамматику, берём какой-нибудь flex+bizon (или их аналоги для других платформ) и получаем готовый парсер.
WH>
WH>1)Записать под них грамматику это те ещё пляски с бубном.
WH>2)Восстановление после ошибок там считай что нет. Да и сами сообщения о ошибках такие, что волосы дыбом встают.
WH>3)Что с типизацией делать будешь?

А никто не собирается проектировать для встроенного скрипта язык уровня C++ или C#. ))) Посмотри на конкретные реальные примеры. Вот тот же OpenSCAD кстати очень полезный продукт, набирающий сейчас популярность.

_>>Ну и плюс надо отметить, что у этого подхода обычно большие проблемы с редакторами кода.
WH>У С++ вообще проблемы с редакторами кода.

В CLion тоже?

_>>Большинство динамических языков обладают базовой возможностью метапрограммирования, но т.к. оно отрабатывает только во время исполнения программы, то к повышению эффективности работы программиста это имеет слабое отношение (максимум синтаксический сахар).
WH>Это не правда. Наметапрограммировать на динамически типизированных языках можно очень много. Банальным сахаром они не ограничиваются.
WH>Проблемы динамики: Тормоза и баги. Поэтому я и считаю все динамически типизированные языки ошибкой природы.

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

_>>Кстати, с возможностями нового стандарта C++ можно попробовать замахнуться на подобные вещи и уж точно можно переписать указанные выше библиотеки вообще без синтаксического шума (задавать DSL конструкции обычными строками, но при этом разбираемыми во время компиляции).
WH>Знал бы ты как немерле за такое с говном смешивают.
WH>

WH>Линк в строке? ААААА!!! УУУУ!!!! КОООООШШШМАААР!!!

))) Не вижу в этом ничего плохого, если эта строка парсится и превращается в инструкции процессору на этапе компиляции.


_>> Если мы говорим о каких-то инновационных инструментах для работы с DSL (Nemerle, Nitra и т.п.), то как я понял (поправьте, если что), они могут относиться только к пункту 2.Б.
WH>Не только.
WH>Компиляторы Nemerle и Nitra реализованы в виде ДЛЛ.
WH>И нет никаких проблем запустить и во время исполнения.

Т.е. речь про вариант 1.Б? Но там не нужен такой сложный язык в роли встроенного скрипта. Вообще без вариантов. Или же может ты имел виду построить в нём простенький EDSL? Но зачем такие сложности (тащить к клиенту ещё и Nemerle), когда можно обойтись только этим DSL'ем?

WH>Включая все сервисы ИДЕ внутри своего приложения. Те не "некое автодополнение", а полноценную ИДЕ с подсветкой типов, навигацией, полноценным автодополением, рефакторингом переименования, подсветкой ошибок в реальном времени итп.
WH>[Nitra] Autocompletion

Автор: VladD2
Дата: 10.06.15

Для мелких скриптовых языков это всё вообще не актуально. Ну ты сам посмотри, где вообще применяются подобные DSL'и... Даже построенные на полноценных языках общего назначения такого не имеют — взгляни на консоль python'a/lisp'a во всяких CAD'ах или текстовых редакторах, а про консоль lua/python'a в играх я вообще молчу. ))) А в случае совсем маленького DSL (не на базе языка общего назначения), типа того же OpenSCAD или скажем CMake, про это вообще смешно упоминать.

_>>Кстати, а хотя бы поддержка тех, что есть у мейнстрим языка имеется?
WH>Имеется. Ну, или пишется за неделю по вечерам.

Я ни на секунду не сомневаюсь, что на Nemerle можно легко повторить большинство DSL библиотек, написанных на C++. Но как бы есть очень большая разница между возможностью написания и возможностью скачать готовый отлаженный продукт. И мне кажется, что если уж язык специализируется на таких вопросах, то самые базовые вещи (типа регулярных выражений, SQL, html шаблонизатора) точно должны быть под рукой.

_>>Т.е. могу я скачать готовые к продакшену EDSL библиотеки работы с sql, регулярными выражениями, физическими размерностями, html-шаблонизатор с нативными вставками и т.п?
WH>Можешь.

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

_>>Но она же вроде только для одной сомнительной IDE, что опять же вычёркивает это преимущество для очень многих пользователей.
WH>Оно к ИДЕ вообще не привязано.
WH>Просто не нашлось желающих сделать это под другие ИДЕ. Вернее желающие были, но до рабочего состояния не довели.
WH>Ибо засунуть поддержку языка в ИДЕ само по себе не простое занятие.
WH>Ибо у каждой ИДЕ куча своих тараканов.

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

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

Г>Интересно, что в языках и средах, где разделения на стадии компиляци и выполнения нету (т.е. динамических ЯП), DSL — это не «отдельная сложная идея», а простой и общепринятый паттерн проектирования. Т.е. в большой степени, любая domain specific library склонна определятя соответствующий своим целям domain specific language

И в этом определение нет особого смысла, т.к. всё равно не будет никакой проверки правил этого языка до выполнения приложения. А уж при выполнение такие вещи проверяются одинаково в языках с любой типизацией, только вот программисту от этого уже мало пользы.

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

_>))) Не вижу в этом ничего плохого, если эта строка парсится и превращается в инструкции процессору на этапе компиляции.

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

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

_>Разница принципиальна. Одно — это инструмент создания приложения, а другое — это инструмент кастомизации готового приложения.
Как по мне так это одно и то же.

_>Однако индустрия однозначно выбрала динамические языки на роль встроенных скриптов. Я даже не знаю есть ли смысл приводить примеры... Они же просто вокруг. Вот даже в браузере сейчас печатаю и то JS отрабатывает.
Их просто реализовать легко.
Статически типизированный язык с выводом типов гораздо более сложная штука.

_>Ну да, т.е. C#6.0 вообще ничем не отличается от C#1.0... )))
Насыпали маленько сахара.

_>А никто не собирается проектировать для встроенного скрипта язык уровня C++ или C#. ))) Посмотри на конкретные реальные примеры. Вот тот же OpenSCAD кстати очень полезный продукт, набирающий сейчас популярность.
Это всё для любого языка нужно.

_>Дело не в этом, а в том что это метапрограммирование отрабатывает на этапе исполнения приложения, так что программисту от него пользы не больше, чем от любых других обычных конструкций языка. Вот к примеру, как ты сделаешь на Питоне (ну или любом другом аналогичном языке) автоматическую проверку корректности зашитого в код sql запроса?
В рантайме. Как и всё остальное.
Это и есть их главная пролема.
Но говорить что там слабое метапрограммирование просто не корректно.

_>))) Не вижу в этом ничего плохого, если эта строка парсится и превращается в инструкции процессору на этапе компиляции.
Расскажи это всяким ганжустасам.

_>Т.е. речь про вариант 1.Б? Но там не нужен такой сложный язык в роли встроенного скрипта. Вообще без вариантов. Или же может ты имел виду построить в нём простенький EDSL?
Да что угодно.

_>Но зачем такие сложности (тащить к клиенту ещё и Nemerle), когда можно обойтись только этим DSL'ем?
Так проще. Ибо писать всё это самому дурь редкостная.

_>Для мелких скриптовых языков это всё вообще не актуально.
Это не правда.

_>Ну ты сам посмотри, где вообще применяются подобные DSL'и... Даже построенные на полноценных языках общего назначения такого не имеют — взгляни на консоль python'a/lisp'a во всяких CAD'ах или текстовых редакторах, а про консоль lua/python'a в играх я вообще молчу. )))
Просто по тому, что ИДЕ это сложно. ИДЕ для динамически типизированных языков за гранью фантастики. Надёжно работающих ни одной не видел.

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

_>А в случае совсем маленького DSL (не на базе языка общего назначения), типа того же OpenSCAD или скажем CMake, про это вообще смешно упоминать.
Почему? Чем тебе помешает автокомплит включая имена файлов? Подсветка ошибок, включая не существующие имена? итп

_>Я ни на секунду не сомневаюсь, что на Nemerle можно легко повторить большинство DSL библиотек, написанных на C++.
Все. И ещё кучу того что на С++ не сделать.

_>Ого, этого я не знал. Помню только про парсеры у вас. А кинешь прямые ссылки на остальное? ) Причём лучше даже не на сами библиотеки, а на какие-нибудь тестовые примеры их использования...
https://github.com/rsdn/nemerle/blob/master/snippets/Nemerle.Xml/Test/Main.n
https://github.com/rsdn/nemerle/blob/master/Linq/Tests/Tests.n

  make (s : string) : void
  {
    regexp match (s) {
      | "a+.*" => printf ("a\n");
      | @"(?<num : int>\d+)-\w+" => printf ("%d\n", num + 3);
      | "(?<name>(Ala|Kasia))? ma kota" =>
        match (name) {
          | Some (n) => printf ("%s\n", n)
          | None => printf ("noname?\n")
        }
      | _ => printf ("default\n");
    }
    
    regexp match (s) {
      | @"(?<_a>.*)\)" => printf ("parens %s\n", _a);
      | _ => ()
    }
  }

_>Так о том и речь, что для всех не сделаешь. Да собственно даже для ведущих не факт, что выйдет.
Ты не понял.
Все языковые сервисы универсальны.
Нужно просто реализовать тонну специфичных для ИДЕ интерфейсов.

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

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

_>И в этом определение нет особого смысла, т.к. всё равно не будет никакой проверки правил этого языка до выполнения приложения. А уж при выполнение такие вещи проверяются одинаково в языках с любой типизацией, только вот программисту от этого уже мало пользы.
Ты никогда в жизни не сможешь объяснить это всяким мамутам.
Но всё же нужно понимать, что рантайм проверки убирают не все преимущества.
Метапрограммирование на динамически типизированных языках таки заметно сокращает код. И делает его декларативным. А это само по себе очень большая помощь разработчику.

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

_>>Разница принципиальна. Одно — это инструмент создания приложения, а другое — это инструмент кастомизации готового приложения.
WH>Как по мне так это одно и то же.

Для начала, этим могут заниматься разные люди с очень разным уровнем подготовки.

_>>Однако индустрия однозначно выбрала динамические языки на роль встроенных скриптов. Я даже не знаю есть ли смысл приводить примеры... Они же просто вокруг. Вот даже в браузере сейчас печатаю и то JS отрабатывает.
WH>Их просто реализовать легко.
WH>Статически типизированный язык с выводом типов гораздо более сложная штука.

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

_>>Ну ты сам посмотри, где вообще применяются подобные DSL'и... Даже построенные на полноценных языках общего назначения такого не имеют — взгляни на консоль python'a/lisp'a во всяких CAD'ах или текстовых редакторах, а про консоль lua/python'a в играх я вообще молчу. )))
WH>Просто по тому, что ИДЕ это сложно. ИДЕ для динамически типизированных языков за гранью фантастики. Надёжно работающих ни одной не видел.
WH>А если ИДЕ для языка будет получаться автоматически и встраиваться в приложения за день, то будет совсем другой расклад.
_>>А в случае совсем маленького DSL (не на базе языка общего назначения), типа того же OpenSCAD или скажем CMake, про это вообще смешно упоминать.
WH>Почему? Чем тебе помешает автокомплит включая имена файлов? Подсветка ошибок, включая не существующие имена? итп

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

WH>https://github.com/rsdn/nemerle/blob/master/snippets/Nemerle.Xml/Test/Main.n

Ну это не совсем то, что я имел в виду (речь шла про какой-нибудь готовый известный синтаксис типа такого http://vibed.org/templates/diet#grammar, а не голый html), но уже из этого кода понятно, что нужное можно легко получить из этого. Так что плюс. )

WH>https://github.com/rsdn/nemerle/blob/master/Linq/Tests/Tests.n

Ммм, так эта реализация SQL основана на linq из .net или мне показалось из-за сходных названий?

WH>

WH>  make (s : string) : void
WH>  {
WH>    regexp match (s) {
WH>      | "a+.*" => printf ("a\n");
WH>      | @"(?<num : int>\d+)-\w+" => printf ("%d\n", num + 3);
WH>      | "(?<name>(Ala|Kasia))? ma kota" =>
WH>        match (name) {
WH>          | Some (n) => printf ("%s\n", n)
WH>          | None => printf ("noname?\n")
WH>        }
WH>      | _ => printf ("default\n");
WH>    }
    
WH>    regexp match (s) {
WH>      | @"(?<_a>.*)\)" => printf ("parens %s\n", _a);
WH>      | _ => ()
WH>    }
WH>  }
WH>

Здесь не очень ясно без исходников, текстовая строка, задающая шаблон, доживает до рантайма или живёт только на этапе компиляции?

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

_>>))) Не вижу в этом ничего плохого, если эта строка парсится и превращается в инструкции процессору на этапе компиляции.
_DA>Только вот в этом случае не получится получить от IDE хоть какую-то функциональность (примитивные подсветка и автодополнение работают в той же Intellij из коробки). Более того, написание плагинов к готовой IDE тоже превратится в довольно неприятное занятие.

Эмм, речь же про EDSL в виде строки или в виде каких-то конструкций языка. Что вменяемого может мне показать обычная IDE по этому поводу, если оно будет не строкой? ) Информацию о том, что за этим символом скрывается страшный шаблон (C++) или жирный макрос (Nemerle)? Нет, спасибо, такое мне совсем не интересно... )))

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

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

Г>>Интересно, что в языках и средах, где разделения на стадии компиляци и выполнения нету (т.е. динамических ЯП), DSL — это не «отдельная сложная идея», а простой и общепринятый паттерн проектирования. Т.е. в большой степени, любая domain specific library склонна определятя соответствующий своим целям domain specific language

_>И в этом определение нет особого смысла, т.к. всё равно не будет никакой проверки правил этого языка до выполнения приложения. А уж при выполнение такие вещи проверяются одинаково в языках с любой типизацией, только вот программисту от этого уже мало пользы.

Ну, типа, у нас, бедных нищасных недолюбленных разработчиков на динамических языках, СВЯ АТМСФЕРА.

Компиляцию (гарантированную проверку работоспособнсоти перед деплоем) нам заменяют тесты/спеки. Это, как ни странно, работает (*место для вашего флейма статика vs динамика*). Так уж вышло, что бОльшую часть прогрессивных фишек в мифический «мейнстрим» привносим мы. Выразительности проще проявляться в динамических языках, obviously.

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

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

Г>Компиляцию (гарантированную проверку работоспособнсоти перед деплоем) нам заменяют тесты/спеки. Это, как ни странно, работает (*место для вашего флейма статика vs динамика*).

Всё верно, в динамике тесты вместо компиляции. И соответственно совершенно непонятно зачем конструировать некие специальные объекты в коде (DSL'и), если для проверки их правил всё равно придётся писать тесты. Т.е. для динамических языков введение DSL'а абсолютно ничего не привносит (во всяком случае на этапе "компиляции"/тестирования).

Г>Так уж вышло, что бОльшую часть прогрессивных фишек в мифический «мейнстрим» привносим мы. Выразительности проще проявляться в динамических языках, obviously.

А почему мейнстрим стал мифическим? ))) Кстати, к нему и куча динамики вполне себе относится: JavaScript, PHP, Python...

P.S. Я вполне себе люблю писать на динамических языка (мой любимчик — Python). Но только короткие скрипты.

Г>Ну, типа, у нас, бедных нищасных недолюбленных разработчиков на динамических языках, СВЯ АТМСФЕРА.

А ты скажи, что не так Обмажемся свое динамикой и говнякаем

Г>Компиляцию (гарантированную проверку работоспособнсоти перед деплоем) нам заменяют тесты/спеки. Это, как ни странно, работает (*место для вашего флейма статика vs динамика*).

То, что оно работает, не значит, что оно работает правильно

ЗЫ. Это не спор, это просто уточнения

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

_>Для начала, этим могут заниматься разные люди с очень разным уровнем подготовки.
Ну, так и в разработке могут принимать участие разные люди.
Скажем, когда я работал в Парусе, там было две команды.
Одна писала движок. Вторая писала логику на этом движке.
Уровень подготовки был очень разный.
Первая команда могла творить все, что в голову взбредёт. Второй было запрещено всё кроме того что разрешено, а разрешено им было весьма не много.
Дать второй команде ДСЛ, в котором можно было делать только то, что разрешено было-бы оптимальным решением.
Но в те времена я нитру ещё даже не придумал.

_>Только не надо этого всего для скриптов. Ну вот сам смотри, как разница между выдачей ошибки при компиляции и при исполнение, если между ними пролегает 1 микросекунда? )
Это не правда.
1)В случае со статикой ошибка будет подсвечена прямо в редакторе.
2)Логики может быть больше десятка строк и тогда все проблемы динамики в полный рост.

_>Не, ну если оно будет совсем "на халяву" (хотя бы в стиле подключения QScintilla) и при этом сумеет простые динамические языки, то тогда конечно было бы не плохо. Но я что-то сомневаюсь в таком чуде... )
Для статически типизированных в случае с нитрой будет совсем на халяву.

_>Ну это не совсем то, что я имел в виду (речь шла про какой-нибудь готовый известный синтаксис типа такого http://vibed.org/templates/diet#grammar,
Можно и такой. Работы на день.

_>а не голый html), но уже из этого кода понятно, что нужное можно легко получить из этого. Так что плюс. )
Из этого сделали NemerleWeb который гораздо круче простых шаблонизаторов.

_>Ммм, так эта реализация SQL основана на linq из .net или мне показалось из-за сходных названий?
А какую тебе надо?
Линк лучше чем голый SQL.
Но есть и вот такое: https://github.com/rsdn/nemerle/wiki/SQL-macros

_>Здесь не очень ясно без исходников, текстовая строка, задающая шаблон, доживает до рантайма или живёт только на этапе компиляции?
Если посмотришь внимательно, то заметишь что переменные прямо в регексах объявляются.

?<num : int>

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

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

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

_>Эмм, речь же про EDSL в виде строки или в виде каких-то конструкций языка. Что вменяемого может мне показать обычная IDE по этому поводу, если оно будет не строкой? ) Информацию о том, что за этим символом скрывается страшный шаблон (C++) или жирный макрос (Nemerle)? Нет, спасибо, такое мне совсем не интересно... )))
В случае с найтрой тебе покажут символ языка.
Причём что это за символ зависит от языка.
Это может быть .НЕТный тип, может быть SQL'ная таблица, может быть любая другая сущность предметной области.

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

Г>>Компиляцию (гарантированную проверку работоспособнсоти перед деплоем) нам заменяют тесты/спеки. Это, как ни странно, работает (*место для вашего флейма статика vs динамика*).

_>Всё верно, в динамике тесты вместо компиляции. И соответственно совершенно непонятно зачем конструировать некие специальные объекты в коде (DSL'и), если для проверки их правил всё равно придётся писать тесты. Т.е. для динамических языков введение DSL'а абсолютно ничего не привносит (во всяком случае на этапе "компиляции"/тестирования).

Тут, чтобы о чём-нибудь разговаривать, нужно бы согласовать словари.

1. Что такое DSL?
2. Зачем нужне DSL?
3. Может ли DSL быть определён без выхода за рамки «базового» языка?

Мои ответы (на единственность и непогрешимость которых я не претендую) таковы:
1. Это сущности и операции с ними, отражающие некую предметную область (domain)
2. Чтобы иметь возможность программировать некую логику в рамках заданной предметной области эффективно и выразительно
3. Да, в достаточно гибком и выскоуровневом языке

Тупой пример:

class User < ActiveRecord::Base
  # вот это, добрые люди, DSL:
  has_many :posts
  scope(:for_fetching){where(fetch_date < Time.now)}

  validations do
    validate_presence :name
  end
end

Какое «значение» имеет такой DSL? Да тупо меньше писать, чтобы добиться того же эффекта. Меньше писать — больше можно написать (или будет написано то, чего иначе не возникло бы, скажем валидации).
Несмотря на отсутствие стадии «компиляции», бОльшая часть этого кода, выполняемая на этапе «определения класса», если его неверно написать, упадёт при первой же загрузке (в т.ч. если скажем таблицы БД posts не существует в природе, или ты ошибся и написал pots).
То есть не надо даже сложные тесты писать — достаточно загрузить код, и DSL либо заработает, либо обломается.

Г>>Так уж вышло, что бОльшую часть прогрессивных фишек в мифический «мейнстрим» привносим мы. Выразительности проще проявляться в динамических языках, obviously.

_>А почему мейнстрим стал мифическим? ))) Кстати, к нему и куча динамики вполне себе относится: JavaScript, PHP, Python...

«Мифический мейнстрим» — это послание в соседний тред, где оказалось, что мейнстрим состоит из 4-5 языков

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

_>>Для начала, этим могут заниматься разные люди с очень разным уровнем подготовки.
WH>Ну, так и в разработке могут принимать участие разные люди.
WH>Скажем, когда я работал в Парусе, там было две команды.
WH>Одна писала движок. Вторая писала логику на этом движке.
WH>Уровень подготовки был очень разный.
WH>Первая команда могла творить все, что в голову взбредёт. Второй было запрещено всё кроме того что разрешено, а разрешено им было весьма не много.
WH>Дать второй команде ДСЛ, в котором можно было делать только то, что разрешено было-бы оптимальным решением.

Так о том и речь. Причём этот DSL очевидно должен быть очень простой. А в тоже самое время первая команда могла параллельно использовать какой-нибудь мегасложный DSL на макросах, для статической проверки каких-то правил в своём коде.

_>>Только не надо этого всего для скриптов. Ну вот сам смотри, как разница между выдачей ошибки при компиляции и при исполнение, если между ними пролегает 1 микросекунда? )
WH>Это не правда.
WH>1)В случае со статикой ошибка будет подсвечена прямо в редакторе.

А кто мешается сделать так же с динамикой? ) У нас же это всё внутри одного приложения...

_>>Ммм, так эта реализация SQL основана на linq из .net или мне показалось из-за сходных названий?
WH>А какую тебе надо?
WH>Линк лучше чем голый SQL.

По поводу linq у меня особое мнение. Лучше не будем поднимать эту тему. )))

WH>Но есть и вот такое: https://github.com/rsdn/nemerle/wiki/SQL-macros

Да, вот так отлично) Хотя понятно, что любители C# такое не воспримут и захотят только Linq вариант. )))

_>>Здесь не очень ясно без исходников, текстовая строка, задающая шаблон, доживает до рантайма или живёт только на этапе компиляции?
WH>Если посмотришь внимательно, то заметишь что переменные прямо в регексах объявляются.
WH>

WH>?<num : int>
WH>

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

Если здесь всё во время компиляции, то мне нравится, классно! ) Особенно в сочетание с ПМ. )

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

_>>Эмм, речь же про EDSL в виде строки или в виде каких-то конструкций языка. Что вменяемого может мне показать обычная IDE по этому поводу, если оно будет не строкой? ) Информацию о том, что за этим символом скрывается страшный шаблон (C++) или жирный макрос (Nemerle)? Нет, спасибо, такое мне совсем не интересно... )))
WH>В случае с найтрой тебе покажут символ языка.
WH>Причём что это за символ зависит от языка.
WH>Это может быть .НЕТный тип, может быть SQL'ная таблица, может быть любая другая сущность предметной области.

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

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

Г>Тут, чтобы о чём-нибудь разговаривать, нужно бы согласовать словари.

Хорошо, сейчас поясню всё на простейшем примере, основываясь на описанной мною в первом сообщение классификации.

Вот смотри, если пока отвлечься от вопросов динамики/статики и просто рассмотреть такой классический очевидный DSL, как регулярные выражения, то к какому пункту моей классификации он относится? Правильный ответ: или 1.Б или 2.Б, в зависимости от реализации. Т.е. в первом случае мы имеем подключение классической библиотечки регулярных выражений, работающей с зашитой в код приложения текстовой строкой (исполняет здесь роль встроенного скрипта). Если программист ошибся в этой строке (ввёл выражение, нарушающее синтаксис регулярных выражений), то мы узнаем об этой ошибке только в процессе исполнения приложения (вне зависимости от типа базового языка программирования). Во втором случае (использования библиотеки типа Boost.Xpressive в C++ или тут приводился выше пример кода для Nemerle) в коде приложения не будет находиться никаких строк (т.е. итоговое приложение не содержит DSL скрипт), а будет только бинарный код, очевидно валидный (по построению).

Так вот возвращаясь к динамике/статике. Моя основная мысль была в том, что на языке со статическим метапрограммированнием возможна реализация DSL как типа 1.Б (имеет смысл применять только если исполняемый "скрипт" запрашивается снаружи, а не зашит в приложение), так и типа 2.Б. А в языках с динамическим метапрограммированием в принципе возможен только тип 1.Б.

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

_>Угу, я уже понял что у вас в этом смысле всё круто. Правда только для одной IDE (от использования которой я отказался ещё несколько лет назад). А то я писал про вариант с DSL в обычных IDE.
Ох. Ещё раз.
Найтра на ИДЕ не завязана вообще от слова совсем.
Прямо сейчас есть интеграция в студию и отдельная WPF'ная программа с редактором в котором есть и подсветка и автодополнение и много чего ещё.
Точно так же найтру можно засунуть в любую другую программу.

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

_>Так о том и речь. Причём этот DSL очевидно должен быть очень простой. А в тоже самое время первая команда могла параллельно использовать какой-нибудь мегасложный DSL на макросах, для статической проверки каких-то правил в своём коде.
Ох. В случае с найтрой это строго одно и то же.
Только набор макросов разный.

_>А кто мешается сделать так же с динамикой? ) У нас же это всё внутри одного приложения...
Удачи.

_>Да, вот так отлично) Хотя понятно, что любители C# такое не воспримут и захотят только Linq вариант. )))
Линк (особенно если это linq2db) объективно лучше.

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

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

Г>>Тут, чтобы о чём-нибудь разговаривать, нужно бы согласовать словари.

_>Хорошо, сейчас поясню всё на простейшем примере, основываясь на описанной мною в первом сообщение классификации.

[...]

_>Так вот возвращаясь к динамике/статике. Моя основная мысль была в том, что на языке со статическим метапрограммированнием возможна реализация DSL как типа 1.Б (имеет смысл применять только если исполняемый "скрипт" запрашивается снаружи, а не зашит в приложение), так и типа 2.Б. А в языках с динамическим метапрограммированием в принципе возможен только тип 1.Б.

Мне кажется, что помимо (естественного для статики, но не базового для разработки вообще) деления на «проверяемое в компайлтайме» и «проверяемое в рантайме» нужно говорить о делении на проверяемое во время разработки и проверяемое в продакшене.

И польза от идеи DSL в принципе — в том, что у нас получается лаконичный код, отражающий предметную область и надёжно проверяемый во время разработки (несмотря на то, что по классификации с точки зрения статики, всё это попадает в одну и ту же «самую неуважаемую» категорию). Пример (часть примера выше):

class User < ActiveRecord::Base
  has_many :posts # <- DSL!
end

Чем интересна отмеченная строка?
* она сгенерирует некоторое количество кода (методы типа User.add_post, User.remove_post, User.posts.count и т.д.), который скорее всего корректен и оптимален; без этого пришлось бы реализовывать их все вручную и тестировать каждый в отдельности
* она — часть основного языка, и если ты напишешь has many :posts или has_much :posts или has_many posts — тебя поправит конечно не компилятор, но интерпретатор на этапе разработки
* она даёт раннее обнаружение ошибок: например, если таблицы posts не существует в БД или в ней нет ключа для ассоциации — код упадёт сразу при запуске с понятной и читаемой ошибкой (а не в одном из методов в рантайме, в котором ты опечатался в названии таблицы, хотя во всех остальных методах всё верно)

И всё это исключительно для демонстрации мысли, которую я написал как примечание к исходному посту (в целом верному): что плавающая грань между «этапом разработки» и «этапом исполнения» в динамических языках способствует более естественному проникновению идеи DSL в эту среду.

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

Г>И всё это исключительно для демонстрации мысли, которую я написал как примечание к исходному посту (в целом верному): что плавающая грань между «этапом разработки» и «этапом исполнения» в динамических языках способствует более естественному проникновению идеи DSL в эту среду.

Даже при 100% покрытии строчек кода тестами, нет гарантии отсутствия ошибок которые могли бы быть отловлены в статически типизированных языках во время компиляции.
Чтобы такую гарантию получить в динамически типизированных языках — нужно делать тесты на все комбинации возможных ветвей исполнения, что во-первых практически нереально, а во-вторых даже доказательство того что покрыты все комбинации ветвей — сама по себе нетривиальная задача (и по-всей видимости неразрешимая).

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

_>>Угу, я уже понял что у вас в этом смысле всё круто. Правда только для одной IDE (от использования которой я отказался ещё несколько лет назад). А то я писал про вариант с DSL в обычных IDE.
WH>Ох. Ещё раз.
WH>Найтра на ИДЕ не завязана вообще от слова совсем.
WH>Прямо сейчас есть интеграция в студию и отдельная WPF'ная программа с редактором в котором есть и подсветка и автодополнение и много чего ещё.
WH>Точно так же найтру можно засунуть в любую другую программу.

В процессе нашего обсуждения Nemerle и т.п. я уже точно не первый раз повторяю фразу вида "можно сделать и можно скачать" — это очень разные вещи. Причём если говорить про всякие библиотеки и т.п., то там даже проще, т.к. хотя и надо впечатать код, но хотя бы только один раз. А в случае IDE это надо делать для каждой (а их сейчас десятки популярных, нет ни одного однозначного лидера) и в каждом случае по разному. Так что пока я всё же останусь при своём мнение, что реализация есть только под VS. Хотя понятно, что теоретически ситуация может измениться.

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

Г>>И всё это исключительно для демонстрации мысли, которую я написал как примечание к исходному посту (в целом верному): что плавающая грань между «этапом разработки» и «этапом исполнения» в динамических языках способствует более естественному проникновению идеи DSL в эту среду.

EP>Даже при 100% покрытии строчек кода тестами, нет гарантии отсутствия ошибок которые могли бы быть отловлены в статически типизированных языках во время компиляции.
EP>Чтобы такую гарантию получить в динамически типизированных языках — нужно делать тесты на все комбинации возможных ветвей исполнения, что во-первых практически нереально, а во-вторых даже доказательство того что покрыты все комбинации ветвей — сама по себе нетривиальная задача (и по-всей видимости неразрешимая).

Это неверно.
Скажем, тот код, который я привёл в прошлом сообщении, упадёт, будучи неверно написан, не «в одной из веток, до которой исполнение может быть и не доберётся, если не покрыть её тестами», а при любой загрузке всего кода. Иными словами, в языках без «стадии компиляции», всё равно есть несколько разных стадий существования кода; и DSL-и обычно определяются так, что контролируют правильность на ранних стадиях.

Впрочем, для нового витка вечного флейма «статика vs динамика» я что-то староват уже, кажется.

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

_>>Так о том и речь. Причём этот DSL очевидно должен быть очень простой. А в тоже самое время первая команда могла параллельно использовать какой-нибудь мегасложный DSL на макросах, для статической проверки каких-то правил в своём коде.
WH>Ох. В случае с найтрой это строго одно и то же.
WH>Только набор макросов разный.

Ну ОК, посмотри тогда задачку ниже. )

_>>А кто мешается сделать так же с динамикой? ) У нас же это всё внутри одного приложения...
WH>Удачи.
Что удачи? ) Вот я запускаю gcc на коде с ошибкой и он мне ругается "какая-то хрень в строке такой-то". Или я запускаю python с ошибочным скриптом и он точно так же ругается "какая-то хрень в строке такой-то". Где разница то для отображения ошибки в редакторе?

_>>Да, вот так отлично) Хотя понятно, что любители C# такое не воспримут и захотят только Linq вариант. )))
WH>Линк (особенно если это linq2db) объективно лучше.

На эту тему уже было большое обсуждения http://rsdn.ru/forum/flame.comp/6029504.flat.1

Автор: alex_public
Дата: 27.04.15

, в том числе и про linq2db. И там даже есть мои мысли по этому поводу http://rsdn.ru/forum/flame.comp/6012168

Автор: alex_public
Дата: 12.04.15

с дальнейшими спорами на эту тему. ))) Но повторять то обсуждение я не вижу смысла, тем более, что непонятно о чём вообще можно спорить после таких http://rsdn.ru/forum/flame.comp/6013262

Автор: gandjustas
Дата: 13.04.15

признаний от самих фанатов linq. )))

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

Значит мне требуется DSL, который будет работать у пользователей. К счастью изобретать новый язык не требуется — это должен быть Пролог. Причём в своей полноценной реализации, в смысле возможностей работы с предикатами. А вот стандартная библиотека языка (ну там всякие writeln, open(file) и т.) вообще не нужна. Вместо неё должен быть набор разных предметных функций. А так же должна быть реализована возможность обработки событий, инициируемых в базовом языке. Ну и всё это должно работать быстро (soft realtime), многопоточно и с доступом к железу (из базового языка). Целевая ОС — Linux.

Кроме этого требуется ещё редактор с подсветкой для этого DSL. Целевые ОС: минимально Windows и Android, а в идеале все возможные. )))

В данный момент задачка полностью решена в виде приложения на C++, которое использует готовый движок Пролога (написанный на C, совершенно адским кодом, который нереально изменять). Реализация не потребовала много времени и в принципе всё нормально работает, но итоговая архитектура мне не очень нравится (кривовато из-за особенностей реализации движка) и периодически вылезают разные острые углы. Если предположим в ближайшем будущем я захочу взять отдельного человека специально на решение задачи "избавиться от этого движка", то можешь ли ты предложить мне что-то интересное на базе ваших технологий? Или проще поставить задачу в виде "переписать как есть, только по-человечески"? )

Проблема редактора же полностью решена готовым компонентом QScintilla (100% кроссплатформенность, время интеграции в приложение — несколько часов). И я даже не знаю что ещё можно тут предложить для подобного DSL. Однако если у тебя есть какие-то идеи, то с удовольствием выслушаю.
==============================================

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

_>>Так вот возвращаясь к динамике/статике. Моя основная мысль была в том, что на языке со статическим метапрограммированнием возможна реализация DSL как типа 1.Б (имеет смысл применять только если исполняемый "скрипт" запрашивается снаружи, а не зашит в приложение), так и типа 2.Б. А в языках с динамическим метапрограммированием в принципе возможен только тип 1.Б.
Г>Мне кажется, что помимо (естественного для статики, но не базового для разработки вообще) деления на «проверяемое в компайлтайме» и «проверяемое в рантайме» нужно говорить о делении на проверяемое во время разработки и проверяемое в продакшене.

Я с этим абсолютно согласен. Только вот фокус в том, что разница заключается не только в проверке. Разница заключается в наличие/отсутствие в продакшене самого DSL, как сущности. Причём это не зависит от типа базового языка — скажем подредактировать строку с регулярным выражением можно и в скомпилированном C++ приложение.

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

Кстати, актуальные для разработки следствия могут быть и совсем другие. К примеру в вопросах защиты ПО или вообще нераскрытия алгоритмов.

Г>И польза от идеи DSL в принципе — в том, что у нас получается лаконичный код, отражающий предметную область и надёжно проверяемый во время разработки (несмотря на то, что по классификации с точки зрения статики, всё это попадает в одну и ту же «самую неуважаемую» категорию). Пример (часть примера выше):
Г>

Г>class User < ActiveRecord::Base
Г>  has_many :posts # <- DSL!
Г>end
Г>

Г>Чем интересна отмеченная строка?
Г>* она сгенерирует некоторое количество кода (методы типа User.add_post, User.remove_post, User.posts.count и т.д.), который скорее всего корректен и оптимален; без этого пришлось бы реализовывать их все вручную и тестировать каждый в отдельности
Г>* она — часть основного языка, и если ты напишешь has many :posts или has_much :posts или has_many posts — тебя поправит конечно не компилятор, но интерпретатор на этапе разработки
Г>* она даёт раннее обнаружение ошибок: например, если таблицы posts не существует в БД или в ней нет ключа для ассоциации — код упадёт сразу при запуске с понятной и читаемой ошибкой (а не в одном из методов в рантайме, в котором ты опечатался в названии таблицы, хотя во всех остальных методах всё верно)

Нуу на самом деле я не уверен, что конкретно этот пример стоит называть именно DSL'ем. Потому что от языка всё же ожидается наличие какой-то внутренней нетривиальной логики. А это скорее похоже на просто библиотечную функцию с метапрограммированием. Разве что это только малая часть целого комплекса функций с неким общим контекстом? Ну и да, я никогда не говорил, что от динамического метапрограммирования вообще нет пользы.

Г>И всё это исключительно для демонстрации мысли, которую я написал как примечание к исходному посту (в целом верному): что плавающая грань между «этапом разработки» и «этапом исполнения» в динамических языках способствует более естественному проникновению идеи DSL в эту среду.

В принципе согласен. Если в варианте 1.A. базовый язык приложения оказывается совпадающим с выбранным для основы DSL'а скриптовым языком, то мы автоматически получаем бесшовную интеграцию, а сам DSL по сути сводится к написанию некой библиотеки на базовом языке.

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

EP>>Даже при 100% покрытии строчек кода тестами, нет гарантии отсутствия ошибок которые могли бы быть отловлены в статически типизированных языках во время компиляции.
EP>>Чтобы такую гарантию получить в динамически типизированных языках — нужно делать тесты на все комбинации возможных ветвей исполнения, что во-первых практически нереально, а во-вторых даже доказательство того что покрыты все комбинации ветвей — сама по себе нетривиальная задача (и по-всей видимости неразрешимая).
Г>Это неверно.

Это верно для общего случая.

Г>Скажем, тот код, который я привёл в прошлом сообщении, упадёт, будучи неверно написан, не «в одной из веток, до которой исполнение может быть и не доберётся, если не покрыть её тестами», а при любой загрузке всего кода.

Примитивные случаи — да, может отловить первый попавшийся тест. А в общем случае даже 100% покрытие по строчкам кода не поможет.

Г>Впрочем, для нового витка вечного флейма «статика vs динамика» я что-то староват уже, кажется.

Не надо флейма, главное не опускать существенные детали — мол "тесты всё отловят".

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

_>Что удачи? ) Вот я запускаю gcc на коде с ошибкой и он мне ругается "какая-то хрень в строке такой-то". Или я запускаю python с ошибочным скриптом и он точно так же ругается "какая-то хрень в строке такой-то". Где разница то для отображения ошибки в редакторе?
Нормальные ИДЕ показывают, где ошибка без запуска. И даже без компиляции. Прямо во время набора кода.

_>Значит мне требуется DSL, который будет работать у пользователей. К счастью изобретать новый язык не требуется — это должен быть Пролог.
Кому должен?

_>Кроме этого требуется ещё редактор с подсветкой для этого DSL. Целевые ОС: минимально Windows и Android, а в идеале все возможные. )))
Прямо сейчас найтра такое не может.
Но после того как мы полностью перепишем найтру на найтре и сделаем нативный бэкенд то не вопрос.

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

_>Если предположим в ближайшем будущем
Это зависит от того насколько оно ближайшее.

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

_>Проблема редактора же полностью решена готовым компонентом QScintilla (100% кроссплатформенность, время интеграции в приложение — несколько часов). И я даже не знаю что ещё можно тут предложить для подобного DSL. Однако если у тебя есть какие-то идеи, то с удовольствием выслушаю.
QScintilla и близко не ИДЕ. Просто блокнот с подсветкой синтаксиса.

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

WH>Нормальные ИДЕ показывают, где ошибка без запуска. И даже без компиляции. Прямо во время набора кода.

Ааа, всё, понял о чём ты. Ну кстати говоря такое и с динамикой будет частично работать (в том что касается синтаксиса языка). Хотя конечно более ограниченно, чем со статикой.

_>>Значит мне требуется DSL, который будет работать у пользователей. К счастью изобретать новый язык не требуется — это должен быть Пролог.
WH>Кому должен?

Предметной области. ) А с чего вообще такие вопросы? )

_>>Кроме этого требуется ещё редактор с подсветкой для этого DSL. Целевые ОС: минимально Windows и Android, а в идеале все возможные. )))
WH>Прямо сейчас найтра такое не может.
WH>Но после того как мы полностью перепишем найтру на найтре и сделаем нативный бэкенд то не вопрос.

Вообще то главная проблема как раз в самом dsl, а не в гуи редакторе к нему. ) Редактор — это так, мелочи.

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

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

_>>Если предположим в ближайшем будущем
WH>Это зависит от того насколько оно ближайшее.

Скажем через полгодика. Ну плюс минус пара месяцев. )

_>>я захочу взять отдельного человека специально на решение задачи "избавиться от этого движка", то можешь ли ты предложить мне что-то интересное на базе ваших технологий? Или проще поставить задачу в виде "переписать как есть, только по-человечески"? )
WH>На данный момент найтра для продакшена не пригодна.

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

WH>QScintilla и близко не ИДЕ. Просто блокнот с подсветкой синтаксиса.

Конечно. Но мне именно блокнот (точнее там на самом деле речь о неком большом и сложном приложение, а это всего лишь его модуль) и нужен. Другое дело, что можно обсуждать уровень качества подсветки и автодополнения...

Г>>Впрочем, для нового витка вечного флейма «статика vs динамика» я что-то староват уже, кажется.
EP>Не надо флейма, главное не опускать существенные детали — мол "тесты всё отловят".

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

В этом топике лучше сосредоточится не на статика vs. динамика, имхо, а на обсуждении DSLей

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

Г>>>Впрочем, для нового витка вечного флейма «статика vs динамика» я что-то староват уже, кажется.
EP>>Не надо флейма, главное не опускать существенные детали — мол "тесты всё отловят".
M>Тесты все не отловят и на статике тоже.

Естественно, тесты и там всё не отловят.
А вот те ограничения которые задаются системой типов — проверяются гарантированно во время компиляции (если специально не обходить эту систему типов). Например так может проверятся правильность выражений на EDSL.

M>Тебе напомнить тривиальнейший пример, который «статисты» так и не смогли решить за два месяца? То-то же. Не надо преувеличивать и превозносить возможности и умения стат. типизации.

Не надо демагогии Я говорю про вполне конкретный аспект проверки правильности построения выражений DSL'ей во время компиляции.

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

_>Ааа, всё, понял о чём ты. Ну кстати говоря такое и с динамикой будет частично работать (в том что касается синтаксиса языка). Хотя конечно более ограниченно, чем со статикой.
Не думаю что ограничено тут правильное слово.
Там всё гораздо хуже.
Автокомплит комплитит, что не должен. Рефакоторинг переименования переименовывает, что попало итп.

_>Предметной области. ) А с чего вообще такие вопросы? )
Просто обычно такого счастья не бывает, что предметная область сводиться к готовому языку.

_>Вообще то главная проблема как раз в самом dsl, а не в гуи редакторе к нему. ) Редактор — это так, мелочи.
Найтра на данном этапе развития намертво прибита к .НЕТ
При помощи найтры, можно сгенерировать какой угодно код без привязки к платформе.
Но сам компилятор найтры ещё долго будет прибит гвоздями к .НЕТ.
А ведь тебе же компилятор в приложение встроить надо.

_>Я как раз и намекал, что в случае понимания реальной пользы для своих дел мог бы сам (лично или нет — не важно) вложиться в общую работу. )
Мы конечно рады любой помощи.
Но оторвать найтру от .НЕТ без полного бутстрапа не реально.
Ты, конечно, можешь попробовать, но потратишь уйму сил и скорее всего не осилишь.
Но даже если у тебя что-то получиться после бутстрапа оно всё равно пойдет в помойку.
Короче нужно соблюдать правильную последовательность развития. Иначе будет мучительно больно.

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

_>Конечно. Но мне именно блокнот (точнее там на самом деле речь о неком большом и сложном приложение, а это всего лишь его модуль) и нужен. Другое дело, что можно обсуждать уровень качества подсветки и автодополнения...
Подсветка там заканчивается на лексере.
А откуда оно возьмёт автодополнение вообще не ясно.

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

WH>Просто обычно такого счастья не бывает, что предметная область сводиться к готовому языку.

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

WH>Найтра на данном этапе развития намертво прибита к .НЕТ
WH>При помощи найтры, можно сгенерировать какой угодно код без привязки к платформе.
WH>Но сам компилятор найтры ещё долго будет прибит гвоздями к .НЕТ.
WH>А ведь тебе же компилятор в приложение встроить надо.

Да, но у меня больше сомнения даже не из-за .net'a. Всё же его некое подобие есть под linux (ну а т.к. нам тут не нужен ни gui, ни другой системный api, то наверное даже всё работало бы). А вопросы быстродействия и доступа к железу вполне решаемы через взаимодействующий C++ код. Дело в другом — чего будет стоить разработка подобного движка с помощью ваших технологий? Мне вот совершенно не очевидно, как будет создаваться код, реализующий базовые возможности языка (а там всё не просто, одна унификация с откатами и отсечениями чего стоит, не говоря уже о динамической модификации базы предикатов). Т.е. в случае Пролога парсер языка — это как раз простейшая вещь, в отличие от реализации его рантайма... Ну и соответственно, если тут нет какой-то существенной помощи (обещали же "лёгкое создания DSL'ей"? ), то тогда проще написать реализацию в лоб на C++ — будет быстрее и эффективнее.

Кстати, а у вас вообще есть хоть один законченный пример готового DSL'я (вообще любого), отрабатывающего во время исполнения приложения, а не во время компиляции?

_>>Конечно. Но мне именно блокнот (точнее там на самом деле речь о неком большом и сложном приложение, а это всего лишь его модуль) и нужен. Другое дело, что можно обсуждать уровень качества подсветки и автодополнения...
WH>Подсветка там заканчивается на лексере.
WH>А откуда оно возьмёт автодополнение вообще не ясно.

Как-то так: http://habrahabr.ru/post/144855/. Ну и с подсветкой аналогично, можно сделать умную. Но для нашего случая хватит и обычной.

M>>Тебе напомнить тривиальнейший пример, который «статисты» так и не смогли решить за два месяца? То-то же. Не надо преувеличивать и превозносить возможности и умения стат. типизации.

EP>Не надо демагогии Я говорю про вполне конкретный аспект проверки правильности построения выражений DSL'ей во время компиляции.


Из твоих слов

Автор: Evgeny.Panasyuk
Дата: 18.07.15

не следует, что ты говоришь только про какой-то аспект правильности построения выражений DSL'ей. Имхо.

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

_>И так DSL. На мой взгляд вся эта область делится на две принципиально разных части: dsl исполняемые в процессе разработки ПО и dsl исполняемые в процессе работы ПО. Рассмотрим по отдельности.

Касательно DSL в процессе разработки: в крупной индустрии ниша DSL-я забита UML-ем в разных вариациях с кодом внутри моделей на Java/C/C++/etc.
Ну и динамические языки само собой. Никто не будет городить новый DSL для какой-то задачи. Возьмут существующие решения. Да и .NET-у тут не место.

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

S>Касательно DSL в процессе разработки: в крупной индустрии ниша DSL-я забита UML-ем в разных вариациях с кодом внутри моделей на Java/C/C++/etc.
S>Ну и динамические языки само собой. Никто не будет городить новый DSL для какой-то задачи. Возьмут существующие решения. Да и .NET-у тут не место.

А для этого используются какие-то готовые известные инструменты или речь про свои внутренние? ) Я вот с UML вполне себе работаю, но кодогенерацию никогда не использовал в реальных проектах.

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

_>А для этого используются какие-то готовые известные инструменты или речь про свои внутренние? ) Я вот с UML вполне себе работаю, но кодогенерацию никогда не использовал в реальных проектах.

Речь о крупном бизнесе: Ericsson, Raytheon, Aetna, Lockhead Martin Corp, British Telecom и т.п. Они используют. Продукты разные, есть большая пачка наших, IBM-их продуктов, есть сторонние производители. В большинстве случаев готовые тулы расширяются customer-specific плагинами для конкретной ситуации.
Тот же Эриксон генерит код (гигабайты) который непосредственно идет в девайсы. Не технические компании обычно генерят web-service-ы (WSDL/XSD/Java) , BPEL и т.п

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

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

_>>>Разница принципиальна. Одно — это инструмент создания приложения, а другое — это инструмент кастомизации готового приложения.
WH>>Как по мне так это одно и то же.

_>Для начала, этим могут заниматься разные люди с очень разным уровнем подготовки.

Не могу пройти мимо этого аргумента. По сути он неявно предполагает:
1) необходимость предоставления пользователю ПО максимально удобного инструментария
2) достаточность предоставления квалифицированному программисту минимально необходимого инструментария

Так быть не должно. При решении нетривиальной задачи интересно задуматься — каким инструментарием я хотел бы обладать, чтобы решить эту задачу очевидно корректным и максимально удобным способом? Если ответ на этот вопрос найден (что часто совсем непросто), то задача сводится к "всего лишь"
Step1) созданию инструментария
Step2) тривиальному созданию решения на основе этого инструментария

Что делает решение (работу пользователя) тривиальной?

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

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

Именно поэтому мне очень нравится идеи, стоящие за Nitra — это четкое понимание того, что никому не нужен просто очередной парсер, что dsl — это не грамматика, а продукт, предназначенный для конечного пользователя. Это программирование будущего.

В настоящем же мы по многим причинам часто встречаем перекос — мы жертвуем простотой Step2 (см. выше) в угоду упрощения Step1:

> В большинстве случаев наиболее логичным и эффективным способом является встраивание какого-то из интерпретируемых языков общего назначения, с добавлением набора специфических для предметной области функций. Чаще всего это Lua, Python, JavaScript...

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

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

_>>Для начала, этим могут заниматься разные люди с очень разным уровнем подготовки.
_>Не могу пройти мимо этого аргумента. По сути он неявно предполагает:
_>1) необходимость предоставления пользователю ПО максимально удобного инструментария
_>2) достаточность предоставления квалифицированному программисту минимально необходимого инструментария

И да и нет. Главный нюанс в том, что различается не только удобство использования, но и возможности этих инструментов. Очевидно, что программистские инструменты не сопоставимо мощнее. Однако за всё приходится платить, в том числе и за эту мощь. Конечно же хотелось бы и её иметь обёрнутой в суперудобную упаковку... Но в большинстве случаев реализация такой упаковки слишком дорогая и не окупается с точки зрения бизнеса.

>> В большинстве случаев наиболее логичным и эффективным способом является встраивание какого-то из интерпретируемых языков общего назначения, с добавлением набора специфических для предметной области функций. Чаще всего это Lua, Python, JavaScript...
_>Ведь главное чтобы пользователь/программист мог решить задачу, не так ли? Не так. DSL должен быть таким, чтобы задачу нельзя было не решить.

Только пока что решение реальной задачи (см. выше мой пример) данным способом вполне осуществимо, а вот технологии на базе Nitra не смогли ничего мне тут предложить.

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

_>И да и нет. Главный нюанс в том, что различается не только удобство использования, но и возможности этих инструментов. Очевидно, что программистские инструменты не сопоставимо мощнее. Однако за всё приходится платить, в том числе и за эту мощь. Конечно же хотелось бы и её иметь обёрнутой в суперудобную упаковку... Но в большинстве случаев реализация такой упаковки слишком дорогая и не окупается с точки зрения бизнеса.
Ты написал полную ерунду.
Попробуй дать определение мощности языка, и ты поймёшь почему.

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

_>Только пока что решение реальной задачи (см. выше мой пример) данным способом вполне осуществимо, а вот технологии на базе Nitra не смогли ничего мне тут предложить.
Сейчас найтра написана только на треть. Ессно от неё в данный момент толку мало.

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

WH>Возможность написать, что угодно к мощности отношения не имеет. Ибо тогда самым мощным языком будет ассемблер.

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

_>>Только пока что решение реальной задачи (см. выше мой пример) данным способом вполне осуществимо, а вот технологии на базе Nitra не смогли ничего мне тут предложить.
WH>Сейчас найтра написана только на треть. Ессно от неё в данный момент толку мало.

Ммм она закодирована только на треть или придумана только на треть (что по сути означает, что вы ещё вообще не представляете что делать)? Если второе, то тогда и обсуждать сейчас нечего. А вот если первое... Предложим что продукт уже был бы на 100% готов — чтобы тогда ты мог предложить по моему небольшому примеру выше?

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

_>В каком-то смысле так и есть. Просто неудобство использования данного мощнейшего инструмента уж слишком велико...
У тебя очень странные представления о мощности.
Обычно люди считают, что чем меньше слов приходится написать для решения задачи, тем мощнее язык.
То есть, то, что ты называешь удобством.

_>Ммм она закодирована только на треть или придумана только на треть (что по сути означает, что вы ещё вообще не представляете что делать)? Если второе, то тогда и обсуждать сейчас нечего.
Закодирована.

_>А вот если первое... Предложим что продукт уже был бы на 100% готов — чтобы тогда ты мог предложить по моему небольшому примеру выше?
Найтра это: напиши компилятор — получи IDE в подарок.
Все возможности найтры направлены на максимальное упрощение этого процесса.
И если кто-то добавит в стандартную библиотеку прологовский движок, то твоя задача будет решаться за несколько дней, включая встраивание полноценной ИДЕ для твоего языка в твоё приложение.

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

WH>Найтра это: напиши компилятор — получи IDE в подарок.
WH>Все возможности найтры направлены на максимальное упрощение этого процесса.

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

Напомню, что при обсуждение nemerle, nitra и т.п. постоянно звучал тезис вида "с помощью наших инструментов будет легко создавать свои DSL". А на практике оказывается, что в собственно создание DSL у вас помощи ровно ноль. А это самая сложная часть... Помогают же ваши инструменты исключительно с организацией мощного редактора для этого DSL. Тоже полезная вещь, но вообще другого порядка и из другой области.

WH>И если кто-то добавит в стандартную библиотеку прологовский движок, то твоя задача будет решаться за несколько дней, включая встраивание полноценной ИДЕ для твоего языка в твоё приложение.

В какую ещё стандартную библиотеку? Если ты про .net, то реализаций Пролога там полно (ну правда большинство являются биндингами к движкам на C, но это не суть). Но мне то нужен модифицированный Пролог, а не классический (иначе это был бы не DSL) — всё равно основная часть работы остаётся. Т.е. никаких различий с моим текущим раскладом (не считай проблем от .net'a).

А идея была в том, что если бы существовал некий модный инструмент, реально помогающий создавать свои DSL, то можно было бы не брать какой-то готовый движок Пролога и допиливать его, а написать самому с нуля простенькое (но обязательно эффективное https://en.wikipedia.org/wiki/Warren_Abstract_Machine) решение в приемлемые сроки. Но такого инструмента нет. Ну а продвинутый редактор... Это конечно любопытно, но только после того, как сам DSL уже реализован.

Кстати, а вот для EDSL у вас действительно есть инструмент для реализации самого языка. Я говорю про макросы — для них у вас уже реализован универсальный интерпретратор. Но это инструмент ограниченный областью метапрограммирования. Т.е. по сути у вас есть инструмент для лёгкого создания DSL, но из очень узкой области — генерирующего (ну грубо говоря) исходные коды на Nemerle.

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

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

_>Напомню, что при обсуждение nemerle, nitra и т.п. постоянно звучал тезис вида "с помощью наших инструментов будет легко создавать свои DSL". А на практике оказывается, что в собственно создание DSL у вас помощи ровно ноль.
ДСЛи для парсинга, типизации и кодогенерации это ноль?
Куча реализованных расширяемых языков, которые можно транслировать в кучу разных бекендов это ноль?
А что тогда не ноль?

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

_>В какую ещё стандартную библиотеку?
Найтры.

_>Если ты про .net,
Нет, не про .НЕТ.

_>то реализаций Пролога там полно (ну правда большинство являются биндингами к движкам на C, но это не суть). Но мне то нужен модифицированный Пролог, а не классический (иначе это был бы не DSL) — всё равно основная часть работы остаётся. Т.е. никаких различий с моим текущим раскладом (не считай проблем от .net'a).
Ты говорил, что вся твоя модификация сводится к замене нескольких функций.
Или ты что-то утаил?

_>А идея была в том, что если бы существовал некий модный инструмент, реально помогающий создавать свои DSL, то можно было бы не брать какой-то готовый движок Пролога и допиливать его, а написать самому с нуля простенькое (но обязательно эффективное https://en.wikipedia.org/wiki/Warren_Abstract_Machine) решение в приемлемые сроки. Но такого инструмента нет. Ну а продвинутый редактор... Это конечно любопытно, но только после того, как сам DSL уже реализован.
Вот найтра как раз и есть такой инструмент.
У тебя будет расширяемая реализация:
1)Прологовского синтаксиса с типизацией + компиляция в WAM.
2)WAM
3)Куча компиляторов WAM в разные архитектуры.

_>Кстати, а вот для EDSL у вас действительно есть инструмент для реализации самого языка. Я говорю про макросы — для них у вас уже реализован универсальный интерпретратор.
Что? Нет у нас интерпретаторов.

_>Но это инструмент ограниченный областью метапрограммирования. Т.е. по сути у вас есть инструмент для лёгкого создания DSL, но из очень узкой области — генерирующего (ну грубо говоря) исходные коды на Nemerle.
Ох. Он ограничен только тараканами в твоей голове.
Запомни: Между "пользовательскими" и "программистскими" языками разницы нет.
Совсем нет.
Никакой.
Ты её придумал.

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

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

_>>Вот если честно, то именно это совершенно не интересно. Ну точнее конечно же если бы давали "на халяву", то не отказался бы, но не более того.
WH>99% программистов с тобой не согласны.

Нормального программиста в первую очередь интересует работа компилятора/интерпретатора. Вот если он есть и работает идеально, то тогда уже можно начать говорить про красивые редакторы...

_>>Напомню, что при обсуждение nemerle, nitra и т.п. постоянно звучал тезис вида "с помощью наших инструментов будет легко создавать свои DSL". А на практике оказывается, что в собственно создание DSL у вас помощи ровно ноль.
WH>ДСЛи для парсинга, типизации и кодогенерации это ноль?
WH>Куча реализованных расширяемых языков, которые можно транслировать в кучу разных бекендов это ноль?
WH>А что тогда не ноль?

Эмм, а какая мне разница сколько разных DSL вы реализовали (кстати, список тоже не особо внушает, т.к. в нём исключительно "преобразователи текста", хотя это вполне естественно для EDSL), если меня волнуют исключительно инструменты способные помочь в реализации своего DSL?

_>>то реализаций Пролога там полно (ну правда большинство являются биндингами к движкам на C, но это не суть). Но мне то нужен модифицированный Пролог, а не классический (иначе это был бы не DSL) — всё равно основная часть работы остаётся. Т.е. никаких различий с моим текущим раскладом (не считай проблем от .net'a).
WH>Ты говорил, что вся твоя модификация сводится к замене нескольких функций.
WH>Или ты что-то утаил?

Здесь http://rsdn.ru/forum/philosophy/6117537

Автор: alex_public
Дата: 18.07.15

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

_>>А идея была в том, что если бы существовал некий модный инструмент, реально помогающий создавать свои DSL, то можно было бы не брать какой-то готовый движок Пролога и допиливать его, а написать самому с нуля простенькое (но обязательно эффективное https://en.wikipedia.org/wiki/Warren_Abstract_Machine) решение в приемлемые сроки. Но такого инструмента нет. Ну а продвинутый редактор... Это конечно любопытно, но только после того, как сам DSL уже реализован.
WH>Вот найтра как раз и есть такой инструмент.
WH>У тебя будет расширяемая реализация:
WH>1)Прологовского синтаксиса с типизацией + компиляция в WAM.
WH>2)WAM
WH>3)Куча компиляторов WAM в разные архитектуры.

Вот! Это ты описал прямо "мечту"! ))) Только вот есть один нюанс... Для реализации подобного с нуля у нас нет ни опыта, ни ресурсов (ну это на данный момент). Поэтому берём готовых движок и подпиливаем его немного. С прицелом решить в будущем проблему в лоб, "залив её баблом" (нанять отдельных специальных людей на написание своего движка, скорее всего на чистом C++).

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

WH>Ты можешь прямо сейчас взять немерле. Засунуть его в свою программу. И компилировать им пользовательский код, который пользователи пишут на своём ДСЛ.

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

В любом случае покажи хотя бы один пример реализации подобного, а то может я чего-то не знаю... )

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

_>Нормального программиста в первую очередь интересует работа компилятора/интерпретатора. Вот если он есть и работает идеально, то тогда уже можно начать говорить про красивые редакторы...
Большинство программистов без нормальной ИДЕ на язык не взглянут. И будут правы.

_>Эмм, а какая мне разница сколько разных DSL вы реализовали (кстати, список тоже не особо внушает, т.к. в нём исключительно "преобразователи текста", хотя это вполне естественно для EDSL), если меня волнуют исключительно инструменты способные помочь в реализации своего DSL?
Ещё раз. Когда натра будет доведена до релиза, там будет куча разных языков, на основе которых ты можешь сделать свой.
Переписывать язык в ассемблер весьма кошмарное занятие.
А вот переписывание в высокоуровневый язык, который лишь немного ниже твоего ДСЛ несравнимо приятнее.

_>Здесь http://rsdn.ru/forum/philosophy/6117537

Автор: alex_public
Дата: 18.07.15

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

_>Вот! Это ты описал прямо "мечту"! ))) Только вот есть один нюанс... Для реализации подобного с нуля у нас нет ни опыта, ни ресурсов (ну это на данный момент). Поэтому берём готовых движок и подпиливаем его немного. С прицелом решить в будущем проблему в лоб, "залив её баблом" (нанять отдельных специальных людей на написание своего движка, скорее всего на чистом C++).
Вот для того чтобы эта мечта стала реальностью мы и пишем найтру.

_>Если бы существовал какой магический инструмент, позволяющий по простому задать основные принципы языка и быстро получить готовый компилятор/интерпретатор... Однако ничего подобного не существует. И я не пойму почему ты пишешь "Вот найтра как раз и есть такой инструмент", если чуть выше сам же говорил, что там речь исключительно о создание IDE для нового языка, а не о создание самого языка.
Я написал:

Найтра это: напиши компилятор — получи IDE в подарок.

Те программист создаёт компилятор, а ИДЕ найтра делает сама.

_>Так а на чём будет написана сама реализация DSL? На макросах немерле? Как-то сомнительно, что на них можно эффективно работать с рантайм конструкциями.
Ещё как может. Макрос немере это просто код на немерле. И может делать что угодно.
Соответственно получаем всю нужную информацию, компилируем сборку и запускаем.
Гоняться по производительности с этой сборкой ты устанешь.

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

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

_>>Нормального программиста в первую очередь интересует работа компилятора/интерпретатора. Вот если он есть и работает идеально, то тогда уже можно начать говорить про красивые редакторы...
WH>Большинство программистов без нормальной ИДЕ на язык не взглянут. И будут правы.

Сомнительное утверждение. Я со многими языками работаю просто в Notepad++. Понятно, что для сложных статически типизированных компилируемых языков типа C++ IDE весьма желательна. Но мы же частенько работает и с совсем другими языками. Всякие там скрипты на Питоне, JS и т.п. А уж специализированные DSL обычно ещё проще.

_>>Эмм, а какая мне разница сколько разных DSL вы реализовали (кстати, список тоже не особо внушает, т.к. в нём исключительно "преобразователи текста", хотя это вполне естественно для EDSL), если меня волнуют исключительно инструменты способные помочь в реализации своего DSL?
WH>Ещё раз. Когда натра будет доведена до релиза, там будет куча разных языков, на основе которых ты можешь сделать свой.
WH>Переписывать язык в ассемблер весьма кошмарное занятие.
WH>А вот переписывание в высокоуровневый язык, который лишь немного ниже твоего ДСЛ несравнимо приятнее.

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

_>>Здесь http://rsdn.ru/forum/philosophy/6117537

Автор: alex_public
Дата: 18.07.15

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

Как бы классический пролог не предусматривает никаких обрабочиков внешних событий. Тем более асинхронных и с многопоточностью. Т.е. имеем N потоков внутри движка и M потоков в системном коде, который может делать вызовы (на которые подписались в скрипте) в движок. И всё это корректно взаимодействует между собой.

_>>Если бы существовал какой магический инструмент, позволяющий по простому задать основные принципы языка и быстро получить готовый компилятор/интерпретатор... Однако ничего подобного не существует. И я не пойму почему ты пишешь "Вот найтра как раз и есть такой инструмент", если чуть выше сам же говорил, что там речь исключительно о создание IDE для нового языка, а не о создание самого языка.
WH>Я написал:
WH>

WH>Найтра это: напиши компилятор — получи IDE в подарок.

WH>Те программист создаёт компилятор, а ИДЕ найтра делает сама.

Хорошо, похоже я не совсем правильно понял ситуацию. Однако в этом виноваты в основном твои формулировки. Вот опять же ты даже в этой фразе делаешь упор на IDE, а про компилятор пишешь "создаёт программист". Из этого кажется, что помощи в создание языка ровно ноль, а речь только про IDE. И вот только сейчас, после долгой дискуссии я смог вытащить из тебя клещами информацию про некую библиотеку языков в Найтре — уже реальная помощь, особенно если попадётся близкий синтаксис. Может и ещё что-то есть)))

_>>Так а на чём будет написана сама реализация DSL? На макросах немерле? Как-то сомнительно, что на них можно эффективно работать с рантайм конструкциями.
WH>Ещё как может. Макрос немере это просто код на немерле. И может делать что угодно.
WH>Соответственно получаем всю нужную информацию, компилируем сборку и запускаем.
WH>Гоняться по производительности с этой сборкой ты устанешь.

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

_>>В любом случае покажи хотя бы один пример реализации подобного, а то может я чего-то не знаю... )
WH>Вся найтра в данный момент огромный макрос для немерле.
WH>Наверное, самый большой из существующих.

Не, хочется наоборот что-то очень простое, но чтобы исполняло пользовательские скрипты. )

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

_>Сомнительное утверждение. Я со многими языками работаю просто в Notepad++.
Ты не репрезентативен.

_> Понятно, что для сложных статически типизированных компилируемых языков типа C++ IDE весьма желательна.
Для С++ нормальной ИДЕ нет. Он слишком запутанный.

_>Но мы же частенько работает и с совсем другими языками. Всякие там скрипты на Питоне, JS и т.п.
Для этих нормальная ИДЕ просто не реализуема.
ИДЕ и динамическая типизация вещи не совместимые.

_>А уж специализированные DSL обычно ещё проще.
Если у тебя больше 10 строк кода, то блокнот уже плохой вариант.

_>Как бы классический пролог не предусматривает никаких обрабочиков внешних событий.
И что для этого нужно сделать?

_>Хорошо, похоже я не совсем правильно понял ситуацию. Однако в этом виноваты в основном твои формулировки. Вот опять же ты даже в этой фразе делаешь упор на IDE, а про компилятор пишешь "создаёт программист". Из этого кажется, что помощи в создание языка ровно ноль, а речь только про IDE. И вот только сейчас, после долгой дискуссии я смог вытащить из тебя клещами информацию про некую библиотеку языков в Найтре — уже реальная помощь,
Ох. Создание оно бывает разным.
Даже без библиотеки разница между найтрой и обычными языками при создании компиляторов будет как между SQL и ассемблером при написании запросов к реляционной базе данных.

_>особенно если попадётся близкий синтаксис. Может и ещё что-то есть)))
Синтаксис фигня. Главное чтобы семантика нужная была. А перегнать один синтаксис в другой не проблема.

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

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

_>Нормального программиста в первую очередь интересует работа компилятора/интерпретатора. Вот если он есть и работает идеально, то тогда уже можно начать говорить про красивые редакторы...
Если для языка/ДСЛ компилятор/интерпретатор только на бумаге существует или не работает нормально, то нафиг такой язык вообще нужен?

Так-то я разделяю мысль, что наличие готовых IDE далеко не так важно (хотя и очень хорошо, если есть), но аргументы странные.

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

WH>Ты не репрезентативен.
Мне почему-то кажется, что ты оцениваешь, в первую очередь, "виндовс-мир" или даже сообщество дот-нет программистов. Понятное дело, когда есть родная для платформы IDE, а фреймворк изначально только на этой платформе и работал, то люди привыкли использовать (единственную!) IDE. На том же линуксе целый зоопарк IDE и языков, а программистов не так уж мало.

Тем более, что если язык хоть немного людей заинтересовал, то его поддержку добавляют в имеющиеся IDE, причём в те, с которыми привыкли работать. Привыкшие работать с той же IntelliJ IDEA не особо захотят переходить на вижуал студию только из-за того, что там поддержка языка будет лучше. Особенно, если они работают не под виндой вообще.

WH>Для С++ нормальной ИДЕ нет. Он слишком запутанный.
WH>Для этих нормальная ИДЕ просто не реализуема.
WH>ИДЕ и динамическая типизация вещи не совместимые.
Тебе не кажется, что противоречишь сам себе? С одной стороны "без IDE на язык никто даже не посмотрит", с другой — перечислил немало вполне себе мейнстримовых вещей, для которых "нет нормальных IDE". И ведь живут как-то.

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

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

WH>>Ты не репрезентативен.
DE>Мне почему-то кажется, что ты оцениваешь, в первую очередь, "виндовс-мир" или даже сообщество дот-нет программистов. Понятное дело, когда есть родная для платформы IDE, а фреймворк изначально только на этой платформе и работал, то люди привыкли использовать (единственную!) IDE. На том же линуксе целый зоопарк IDE и языков, а программистов не так уж мало.

DE>Тем более, что если язык хоть немного людей заинтересовал, то его поддержку добавляют в имеющиеся IDE, причём в те, с которыми привыкли работать. Привыкшие работать с той же IntelliJ IDEA не особо захотят переходить на вижуал студию только из-за того, что там поддержка языка будет лучше. Особенно, если они работают не под виндой вообще.

Тред о dsl, о какой заинтересованности языком и поддержке IDE третьими лицами может идти речь?
(Конечно, можно взять python, добавить пару функций предметной области и назвать это dsl, но это зачастую поиск ключей под фонарем, когда основанием для выбора языка является удобство интеграции, а не заточенность под доменную область)

И вот представьте команду пусть даже средних размеров, один отдел запилил dsl, в другом кто-то жмет Ctrl+пробел, а в ответ тишина. Документация если есть то устарела или врет, что дальше делать не ясно.

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

Я сейчас, слегка утрируя, описал разницу между провальным и успешным внедрением dsl.

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

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

_>Тред о dsl, о какой заинтересованности языком и поддержке IDE третьими лицами может идти речь?
Ну я отвечал больше на "написание кода в notepad++". Но даже если говорить в контексте ДСЛ, то как думаешь — если человек "всю жизнь" пишет в idea на джаве/скале, то он побежит ставить вижуал студию из-за того, что нитровые ДСЛ туда удобно интегрируются?

Нет, я не буду спорить с пользой и удобностью ИДЕ. Вот только интеграция с одной из целой кучи не выглядит как киллер-фича.

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

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

_>>Тред о dsl, о какой заинтересованности языком и поддержке IDE третьими лицами может идти речь?
DE>Ну я отвечал больше на "написание кода в notepad++". Но даже если говорить в контексте ДСЛ, то как думаешь — если человек "всю жизнь" пишет в idea на джаве/скале, то он побежит ставить вижуал студию из-за того, что нитровые ДСЛ туда удобно интегрируются?

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

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

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

_>>Сомнительное утверждение. Я со многими языками работаю просто в Notepad++.
WH>Ты не репрезентативен.

Ой, да ладно, я то ещё как раз могу считаться сторонником IDE (хотя бы для C++ и ему подобных). А есть же орды разработчиков, которые спокойно себе работают с C/C++ в том же vim или Еmacs или их современными аналогами (типа Sublime), и не хотят ничего слышать ни про какие IDE.

_>> Понятно, что для сложных статически типизированных компилируемых языков типа C++ IDE весьма желательна.
WH>Для С++ нормальной ИДЕ нет. Он слишком запутанный.

И CLion тоже? )))

_>>Но мы же частенько работает и с совсем другими языками. Всякие там скрипты на Питоне, JS и т.п.
WH>Для этих нормальная ИДЕ просто не реализуема.
WH>ИДЕ и динамическая типизация вещи не совместимые.

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

И кстати если когда-нибудь и появится мода на DSL, то она скорее всего будет происходить как раз как продолжение этой моды... Уже сейчас наблюдается много решений, позволяющих существенно упрощать работу (относительно и так простого базового скриптового языка) в конкретной узкой области с помощью специальных библиотек. По факту они уже реализуют DSL'и, хотя и не акцентируют на этом внимание. Я могу привести не один такой пример.

_>>Как бы классический пролог не предусматривает никаких обрабочиков внешних событий.
WH>И что для этого нужно сделать?

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

WH>Ох. Создание оно бывает разным.
WH>Даже без библиотеки разница между найтрой и обычными языками при создании компиляторов будет как между SQL и ассемблером при написании запросов к реляционной базе данных.

Ну так а где я про это должен был узнать? ) Ты вот сейчас первый раз произносишь подобные слова (раньше всё про IDE, да про IDE)... Правда чтобы я окончательно поверил в это чудо, требуется ещё какое-то разъяснение механизмов. Т.е. откуда собственно берётся эта разница. Лучше всего на каком-нибудь простейшем примере...

_>>Т.е. ты хочешь сказать, что наш скрипт по сути будет отрабатывать на этапе компиляции? ) А полученный exe можно будет выкидывать в помойку? )))
WH>Нет я хочу сказать что скрипт будет превращается в ДЛЛ после чего очень быстро исполняться.

Ну я понял, что получается такой забавный трюк. ))) Но если оно работает, то это в принципе не важно. Правда остаётся ещё вопрос реализуемости самого языка на этих макросах... Да, я в курсе что там весь .net доступен. Но скажем для задачи реализации движка пролога то от этого ни холодно ни жарко...

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

_>>Нормального программиста в первую очередь интересует работа компилятора/интерпретатора. Вот если он есть и работает идеально, то тогда уже можно начать говорить про красивые редакторы...
DE>Если для языка/ДСЛ компилятор/интерпретатор только на бумаге существует или не работает нормально, то нафиг такой язык вообще нужен?

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

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

_> (да и гвоздями к студии она не прибита, насколько я понимаю)
Ну да, вроде. Но поддержка ИДЕ часто упоминается как преимущество. А из коробки поддерживается только вижуал студия. По крайней мере, на данный момент.

_>Во-вторых, постановка вопроса странная. "Всю жизнь" он может заниматься чем угодно, а на конкретном проекте есть определенные требования к рабочему месту. For fun хоть в тетрадке пишите.
Тут можно с двух точек зрения посмотреть:
1. Разработка может вестись вообще не на виндовс или без вижуал студии, это совсем не редкость, кстати. В этом случае, нитра в такой проект не попадёт, как раз по причинам, которые ты сам называл — инфраструктура и всё такое.
2. Вот заинтересовался, например, хочу пощупать инструмент. А тут мне говорят — ставь винду, ставь студию... А так бы поигрался "for fun", а потом и глядишь — пытался бы в продакшен перетащить. Или хотя бы везде рассказывал какой это крутой инструмент.

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

_>Ой, да ладно, я то ещё как раз могу считаться сторонником IDE (хотя бы для C++ и ему подобных). А есть же орды разработчиков, которые спокойно себе работают с C/C++ в том же vim или Еmacs или их современными аналогами (типа Sublime), и не хотят ничего слышать ни про какие IDE.
Вопрос в том, какой процент.

WH>>Для С++ нормальной ИДЕ нет. Он слишком запутанный.
_>И CLion тоже? )))
Чудес не бывает.

_>Так я про это и говорю. Только вот этот факт совершенно не означает, что сами такие языки не нужны. Более того, они всё последнее десятилетие только набирают популярность.
Они не нужны.
Кто считает иначе, пусть покажет задачу, для которой они нужны.
Я задавал этот вопрос много раз. Но так и не получил ни одного внятного ответа.

_>Ну так а где я про это должен был узнать? ) Ты вот сейчас первый раз произносишь подобные слова (раньше всё про IDE, да про IDE)...
А какой ещё смысл может быть у ДСЛ, чей домен компиляторы?

_>Правда чтобы я окончательно поверил в это чудо, требуется ещё какое-то разъяснение механизмов. Т.е. откуда собственно берётся эта разница. Лучше всего на каком-нибудь простейшем примере...
Сейчас нам не до примеров.

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

DE>Мне почему-то кажется, что ты оцениваешь, в первую очередь, "виндовс-мир" или даже сообщество дот-нет программистов. Понятное дело, когда есть родная для платформы IDE, а фреймворк изначально только на этой платформе и работал, то люди привыкли использовать (единственную!) IDE. На том же линуксе целый зоопарк IDE и языков, а программистов не так уж мало.
Когда я говорю про ИДЕ, я говорю, про любую ИДЕ.
Но чтобы была ИДЕ, а не блокнот.

DE>Тем более, что если язык хоть немного людей заинтересовал, то его поддержку добавляют в имеющиеся IDE, причём в те, с которыми привыкли работать. Привыкшие работать с той же IntelliJ IDEA не особо захотят переходить на вижуал студию только из-за того, что там поддержка языка будет лучше. Особенно, если они работают не под виндой вообще.
Да что вы все к студии прицепились? Найтра вообще ни разу не про студию.

DE>Тебе не кажется, что противоречишь сам себе? С одной стороны "без IDE на язык никто даже не посмотрит", с другой — перечислил немало вполне себе мейнстримовых вещей, для которых "нет нормальных IDE". И ведь живут как-то.
С++ для некоторых задач не имеет альтернативы из-за производительности кода.
Жабаскрип не имеет альтернативы в браузерах.
Этих людей я могу понять и пожалеть.
Но тех, кто пишет на этом при наличии альтернативы, я понять не могу.

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

DE>1. Разработка может вестись вообще не на виндовс или без вижуал студии, это совсем не редкость, кстати. В этом случае, нитра в такой проект не попадёт, как раз по причинам, которые ты сам называл — инфраструктура и всё такое.
Современная преальфа действительно не попадает.
А вот 1.0 уже попадёт.
Ибо будет оторвана от платформы.

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

WH>Они не нужны.
WH>Кто считает иначе, пусть покажет задачу, для которой они нужны.
WH>Я задавал этот вопрос много раз. Но так и не получил ни одного внятного ответа.
Ты просто не получил такого ответа, который тебе понравился бы. Так-то я тоже сторонник статической типизации, но отрицать наличие множества любителей динамики весьма странно.

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

_>Т.е. в случае Пролога парсер языка — это как раз простейшая вещь, в отличие от реализации его рантайма... Ну и соответственно, если тут нет какой-то существенной помощи (обещали же "лёгкое создания DSL'ей"? ), то тогда проще написать реализацию в лоб на C++ — будет быстрее и эффективнее.

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

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

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

Покажи задачу, на которой динамика лучше.
Одну задачу.
Я что так много прошу?

DE>но отрицать наличие множества любителей динамики весьма странно.
Миллион мух не аргумент.

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

LP>Так тебе нужен компилятор/райнтайм или ide? Насколько я понял идею обсуждаемого продукта, он предоставляет собой генератор среды разработки для языка с описанной семантикой и... все.
Нет, не всё.

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

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

WH>Я что так много прошу?
Ты просишь не того человека, учитывая, что я прямо сказал, что тоже предпочитаю статическую типизацию.

WH>Миллион мух не аргумент.
Ещё раз: я точно так же считаю аргументы в духе "динамика — это свобода", "тесты всё равно надо писать" и прочее, мягко говоря, не убедительными. Ну аргументы у них есть, просто ты с ними не согласен.

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

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

DE>>Если для языка/ДСЛ компилятор/интерпретатор только на бумаге существует или не работает нормально, то нафиг такой язык вообще нужен?

_>О том и речь. ) Так что разработчика языка (а здесь мы все пишем от его лица, т.к. речь про DSL'и) должно волновать в первую очередь именно это. А уж с редактором как-нибудь потом можно будет разобраться.

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

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

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

DE>Ещё раз: я точно так же считаю аргументы в духе "динамика — это свобода", "тесты всё равно надо писать" и прочее, мягко говоря, не убедительными. Ну аргументы у них есть, просто ты с ними не согласен.
Как можно соглашаться с аргументами, которые не выдерживают критики?
Единственный объективный аргумент в пользу динамической типизации: Нужно писать меньше кода.
Но если в случае с жабой выигрыш существенный. То в случае с языками, где есть вывод типов и метапрограммирование выигрыш сводится примерно к нулю.
При этом не появляется ни одной из проблем динамической типизации.
1)Медленное исполнение.
2)Большое потребление памяти.
3)Серьёзные проблемы с поддержкой кода, если его больше 100 строк.
4)Плохая поддержка ИДЕ.

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

_>>Ой, да ладно, я то ещё как раз могу считаться сторонником IDE (хотя бы для C++ и ему подобных). А есть же орды разработчиков, которые спокойно себе работают с C/C++ в том же vim или Еmacs или их современными аналогами (типа Sublime), и не хотят ничего слышать ни про какие IDE.
WH>Вопрос в том, какой процент.

Очень даже приличный. )

_>>Так я про это и говорю. Только вот этот факт совершенно не означает, что сами такие языки не нужны. Более того, они всё последнее десятилетие только набирают популярность.
WH>Они не нужны.
WH>Кто считает иначе, пусть покажет задачу, для которой они нужны.
WH>Я задавал этот вопрос много раз. Но так и не получил ни одного внятного ответа.

Да легко. Вот к примеру периодически возникает потребность в написание различных скриптов (к примеру не тривиального построения проектов и т.п.). Сейчас это пишется на Питоне (кстати тоже в своеобразном DSL). На каком из статически типизированных языков ты предлагаешь мне сделать эту работу? И чем это будет удобнее?

_>>Правда чтобы я окончательно поверил в это чудо, требуется ещё какое-то разъяснение механизмов. Т.е. откуда собственно берётся эта разница. Лучше всего на каком-нибудь простейшем примере...
WH>Сейчас нам не до примеров.

Ну ладно, тогда значит посмотрим, когда у вас появится уже что-то готовое)

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

LP>Так тебе нужен компилятор/райнтайм или ide? Насколько я понял идею обсуждаемого продукта, он предоставляет собой генератор среды разработки для языка с описанной семантикой и... все. Или же они замахиваются и на компилятор/интерпретатор? Если так, то даже не смешно, легче программу на китайском заставить говорить, чем реализовать такое для любого языка/платформы.

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

Что же касается обсуждаемого продукта, то по словам WolfHound'а он помогает в написание компилятра/рантайма и при этом даёт IDE вообще на халяву. В последнее я даже готов поверить. ))) А вот в первое пока нет, т.к. не было продемонстрировано ни одного примера подобной помощи. С другой стороны разработка у них ещё далека от завершения, так что возможно всё и будет. ))) Но я пока не особо представляю как.

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

_>Значит мне требуется DSL, который будет работать у пользователей. К счастью изобретать новый язык не требуется — это должен быть Пролог. Причём в своей полноценной реализации, в смысле возможностей работы с предикатами. А вот стандартная библиотека языка (ну там всякие writeln, open(file) и т.) вообще не нужна. Вместо неё должен быть набор разных предметных функций. А так же должна быть реализована возможность обработки событий, инициируемых в базовом языке. Ну и всё это должно работать быстро (soft realtime), многопоточно и с доступом к железу (из базового языка). Целевая ОС — Linux.

Если это не является секретной информацией, не могли бы вы описать чуть подробнее? Или какой-нибудь документ выложить.
Просто интересно, ничего кроме этого.

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

WH>Покажи задачу, на которой динамика лучше.
WH>Одну задачу.
WH>Я что так много прошу?

Я тоже не отношусь к сторонникам динамики, но преимущества в определенных случаях, по-моему, очевидны: можно писать код БЫСТРО. Можно абстрагироваться от типа переменной вообще. Можно вызывать функции, которые еще не написаны. Ну и так далее. Для больших и даже средних систем это вряд ли можно назвать преимуществом, а вот для прототипов или утилит — самое то.

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

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

А можно пример такой ситуации?

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

WH>Как можно соглашаться с аргументами, которые не выдерживают критики?
Знаешь что забавно? Что люди выступающие против макросов/ДСЛ тоже считают твои аргументы не убедительными.

WH>Но если в случае с жабой выигрыш существенный. То в случае с языками, где есть вывод типов и метапрограммирование выигрыш сводится примерно к нулю.
Вот только мейнстримовых (статически типизированных) языков с "выводом типов и метапрограммированием" (практически?) нет. А динамика вполне доступна и "пропихнуть в продакшен", наверное, легче чем немерле.

Ну и опять же про "миллионы мух": любители динамики ведь и решения принимают. Да и найти готовых специалистов проще.

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

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

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

_DA>А можно пример такой ситуации?

— C++
— любой динамический язык: невозможно надежно делать анализ типов => нет хорошего автодополнения, навигации, рефакторингов. Работа IDE сводится к "Чувак, я тут что-то нашла — это оно? Нажми кнопочку, а то я боюсь сама менять." Не говоря о случаях, когда не находит.

Это мы говорим про базовые вещи, а есть штуки типа data-flow анализа, которые потребуют еще больше прыжков, если язык делать абы как.

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

_DA>>А можно пример такой ситуации?

N>- C++
N>- любой динамический язык: невозможно надежно делать анализ типов => нет хорошего автодополнения, навигации, рефакторингов. Работа IDE сводится к "Чувак, я тут что-то нашла — это оно? Нажми кнопочку, а то я боюсь сама менять." Не говоря о случаях, когда не находит.

Это ведь не примеры языков, для которых нельзя сделать ничего "умнее подсветки ключевых слов и скобочек". Да и вопрос был не в том. Если бы условный питон разрабатывался одновременно с IDE для него, то он бы вдруг сменил динамическую типизацию на статическую что ли? Я спрашивал про ситуацию, когда при разработке DSL без одновременной реализации IDE в результате получается язык, для которого нельзя ничего сделать "умнее подсветки ключевых слов и скобочек". С учетом того, что это, вообще говоря, наш DSL, и мы его можем менять. Понятно, что если вообще не думать об IDE в перспективе, то получится менее подготовленный к IDE-функционалу язык, но это не вынуждает одновременно с языком еще и IDE-функционал реализовывать. Тем более, что любой язык впоследствии может развиваться в довольно неожиданных направлениях.

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

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

LP>>Так тебе нужен компилятор/райнтайм или ide? Насколько я понял идею обсуждаемого продукта, он предоставляет собой генератор среды разработки для языка с описанной семантикой и... все.
WH>Нет, не всё.

Пытаетесь объять необъятное?

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

Да ну? Это сомнительно хотя бы потому, что универсальные генераторы IDE есть уже давно (https://eclipse.org/Xtext/), а вот действительно универсальные генераторы компиляторов — такого история не знает. Каков должен быть алгоритм, который лишь из одного метаописания языка С++ может комплировать С++ код, а из метаописания языка Prolog-a — Prolog-код?

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

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

_>Что же касается обсуждаемого продукта, то по словам WolfHound'а он помогает в написание компилятра/рантайма и при этом даёт IDE вообще на халяву. В последнее я даже готов поверить. )))

Получение IDE для языка с описанной семантикой уже давно не проблема
https://eclipse.org/Xtext/
Но вот сказки про универсальный генератор компиляторов оставим для любителей фантастики.

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

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

_DA>>>А можно пример такой ситуации?

N>>- C++
N>>- любой динамический язык: невозможно надежно делать анализ типов => нет хорошего автодополнения, навигации, рефакторингов. Работа IDE сводится к "Чувак, я тут что-то нашла — это оно? Нажми кнопочку, а то я боюсь сама менять." Не говоря о случаях, когда не находит.

_DA>Это ведь не примеры языков, для которых нельзя сделать ничего "умнее подсветки ключевых слов и скобочек".

Конечно я слегка преувеличил — какую-то IDE для С++ теоретически можно сделать, но практически это выльется не только в страдания разработчиков IDE, но и страдания пользователей (больше потребляемой памяти и CPU, меньше возможностей)

_DA>Если бы условный питон разрабатывался одновременно с IDE для него, то он бы вдруг сменил динамическую типизацию на статическую что ли?

Конечно. Если бы питон писали для разработки больших программ с использованием автоматизирующих инструментов, то никакой динамической типизации там не было бы. Это странно и с точки зрения IDE, и эффективной интерпретации, и чтения/поддержки.

_DA>Я спрашивал про ситуацию, когда при разработке DSL без одновременной реализации IDE в результате получается язык, для которого нельзя ничего сделать "умнее подсветки ключевых слов и скобочек".

Ну вот в С++ даже треугольные скобочки подсветить не получится без полного синтаксического разбора. Что мешает получить такой DSL? Человеку будет "все понятно", а IDE — не совсем. А ведь синтаксис это не самое сложное.

_DA>С учетом того, что это, вообще говоря, наш DSL, и мы его можем менять.

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

_DA> Понятно, что если вообще не думать об IDE в перспективе, то получится менее подготовленный к IDE-функционалу язык, но это не вынуждает одновременно с языком еще и IDE-функционал реализовывать. Тем более, что любой язык впоследствии может развиваться в довольно неожиданных направлениях.

"Менее" бывает разное. C менее предназначен, чем Java, С++ — менее, чем C, Python — менее, чем C++. Рано или поздно различать "менее" и "совсем не" становится бессмысленно.

Я, кстати, не проповедую "каждому языку — свою IDE". Имхо есть места, где это просто не нужно/не оправданно. Но там где нужно, стоит думать про нее с первого дня.

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

N>Я, кстати, не проповедую "каждому языку — свою IDE". Имхо есть места, где это просто не нужно/не оправданно. Но там где нужно, стоит думать про нее с первого дня.
Тут главное не забывать, что нет таких задач, для которых нужно было бы калечить язык, так чтобы для него было трудно сделать ИДЕ.

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

_>Да легко. Вот к примеру периодически возникает потребность в написание различных скриптов (к примеру не тривиального построения проектов и т.п.). Сейчас это пишется на Питоне
И сколько там строк?

_>(кстати тоже в своеобразном DSL).
И чего в питоне ДСЛного?

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

_> И чем это будет удобнее?
Будешь получать по рукам не через час работы скрипта, а до запуска.

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

ARK>Я тоже не отношусь к сторонникам динамики, но преимущества в определенных случаях, по-моему, очевидны: можно писать код БЫСТРО.
Статическая типизация этому не мешает.

ARK>Можно абстрагироваться от типа переменной вообще.
Вывод типов.

ARK>Можно вызывать функции, которые еще не написаны.
1)Любая нормальная ИДЕ одним нажатием кнопки может сделать заглушку бросающую исключение.
2)Ничто не мешает компилятору генерировать такие заглушки.
Те выставил флаг компилятору, а он вместо ошибки начал давать предупреждение и выкидывать исключение при вызове метода.

ARK>Ну и так далее.
Что-то пока у тебя не задалось.

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

DE>Знаешь что забавно? Что люди выступающие против макросов/ДСЛ тоже считают твои аргументы не убедительными.
Разница существенна.
Я знаю про динамическую типизацию больше чем они.
Они про макросы не знают ничего.

DE>Вот только мейнстримовых (статически типизированных) языков с "выводом типов и метапрограммированием" (практически?) нет. А динамика вполне доступна и "пропихнуть в продакшен", наверное, легче чем немерле.
Пихать динамику в продакшен глупо. Всегда.

DE>Ну и опять же про "миллионы мух": любители динамики ведь и решения принимают. Да и найти готовых специалистов проще.
К сожалению нельзя запретить принимать решения мухам.
Вот они и тащат в продакшен всякое говно. То динамически типизированный язык притащат. То NoSQL в качестве основного хранилища.

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

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

N>>Я, кстати, не проповедую "каждому языку — свою IDE". Имхо есть места, где это просто не нужно/не оправданно. Но там где нужно, стоит думать про нее с первого дня.
WH>Тут главное не забывать, что нет таких задач, для которых нужно было бы калечить язык, так чтобы для него было трудно сделать ИДЕ.

Это само собой.

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

ARK>Если это не является секретной информацией, не могли бы вы описать чуть подробнее? Или какой-нибудь документ выложить.
ARK>Просто интересно, ничего кроме этого.

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

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

LP>Пытаетесь объять необъятное?
Нет.

LP>Да ну?
Компилятор может написать любой профильный студент. И даже некоторые школьники.
Нормальных ИДЕ раз, два и обчёлся.

LP>Это сомнительно хотя бы потому, что универсальные генераторы IDE есть уже давно (https://eclipse.org/Xtext/),
Крайне ограниченная штука с кучей закатов солнца вручную.

LP>а вот действительно универсальные генераторы компиляторов — такого история не знает. Каков должен быть алгоритм, который лишь из одного метаописания языка С++ может комплировать С++ код, а из метаописания языка Prolog-a — Prolog-код?
https://en.wikipedia.org/wiki/Graph_rewriting закрывает процентов 90.

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

_>>Да легко. Вот к примеру периодически возникает потребность в написание различных скриптов (к примеру не тривиального построения проектов и т.п.). Сейчас это пишется на Питоне
WH>И сколько там строк?

Обычно 1-2 экрана. ) Ну точнее я то уже привык использовать данный инструмент вообще во всех случаях, так что частенько встречаются скрипты и в несколько строк. Однако их теоретически можно было бы заменить всякими там make/bat и т.п. файлами. В отличие от сложных случаев, которые писать без помощи специализированных инструментов очень неприятно.

_>>(кстати тоже в своеобразном DSL).
WH>И чего в питоне ДСЛного?

DSL там реализует не сам Питон, а соответствующие библиотечки для него. Например типа таких: http://docs.fabfile.org/en/1.10/tutorial.html

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

Ну так назови хотя бы один. В чём проблема? )))

Причём обрати внимание... Это я ещё не потребовал наличия в языке готовых инструментов типа http://www.scons.org или https://waf.io, без которых написание подобных скриптов является сомнительным развлечением. А ты уже и без этого не смог назвать ни одного языка...

_>> И чем это будет удобнее?
WH>Будешь получать по рукам не через час работы скрипта, а до запуска.

Это конечно же очень хорошо, но только при выполнение трёх условий:

1. Чтобы писалось не сложнее чем сейчас. Т.е. чтобы синтаксис языка был не тяжелее Питона и были в наличие нужные предметные библиотеки.
2. Чтобы запускалось не сложнее чем сейчас. Т.е. никаких там отдельных компиляторов, а просто некий универсальный исполнитель скриптов, который прописываем в path.
3. Чтобы можно было увидеть ссылку на скачивание описанного чуда, а не утверждение, что это всё теоретически возможно (против этого никто и не возражал). ))))

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

ARK>>Я тоже не отношусь к сторонникам динамики, но преимущества в определенных случаях, по-моему, очевидны: можно писать код БЫСТРО.
WH>Статическая типизация этому не мешает.

Иногда мешает.

ARK>>Можно абстрагироваться от типа переменной вообще.
WH>Вывод типов.

Вывод типов имеет дело с каким-то конкретным типом, а я имею дело с типом, который, возможно, вообще еще не объявлен.

ARK>>Можно вызывать функции, которые еще не написаны.
WH>1)Любая нормальная ИДЕ одним нажатием кнопки может сделать заглушку бросающую исключение.
WH>2)Ничто не мешает компилятору генерировать такие заглушки.
WH>Те выставил флаг компилятору, а он вместо ошибки начал давать предупреждение и выкидывать исключение при вызове метода.

1) Не все используют IDE.
2) Не все используют IDE, генерящие такие заглушки.
3) Это лишние телодвижения и, возможно, неиспользуемый мусор в коде.

ARK>>Ну и так далее.
WH>Что-то пока у тебя не задалось.

Вполне объективные наблюдения.

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

ARK>>Если это не является секретной информацией, не могли бы вы описать чуть подробнее? Или какой-нибудь документ выложить.
ARK>>Просто интересно, ничего кроме этого.

_>Через пару месяцев наверное могу вообще подробно рассказать. ) А пока могу только уточнить, что описанный DSL не является самоцелью или чем-то подобным, а выступает всего лишь в роли одного из инструментов реализации (в данном случае кастомизации) некого интересного прикладного решения.

Спасибо, будем ждать.

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

N>Если мы можем его менять, то никаких вопросов, конечно, нет. А если уже написаны горы кода?

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

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

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

N>>Если мы можем его менять, то никаких вопросов, конечно, нет. А если уже написаны горы кода?

_DA>Пока не нужно поддерживать обратную совместимость, то в общем-то тоже больших проблем у нас, например, на практике не возникает с внесением изменений в DSL, когда есть способы трансформирования AST.

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

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

_DA>>Пока не нужно поддерживать обратную совместимость, то в общем-то тоже больших проблем у нас, например, на практике не возникает с внесением изменений в DSL, когда есть способы трансформирования AST.

N>И у клиентов? Впрочем, с синтаксисом при таких возможностях проблем действительно немного.
Я как раз и имел ввиду, что пока клиенты сами код не пишут на DSL, то можно его безболезненно изменять, так как он весь хранится у нас. (На самом деле один клиент есть такой, но там совсем по мелочи, ему можно и персонально исходники поправить).

N>А если вы решили что-то автоматизировать и обнаружили, что не можете до исполнения программы понять нужные свойства, т.к. это просто не предусмотрено? Хотя тяжело, конечно, без общего конкретного примера рассуждать.
Эмм, это вопрос уже конкретно по нашему проекту? Могу в приватных сообщениях рассказать, если интересно )

WH>Единственный объективный аргумент в пользу динамической типизации: Нужно писать меньше кода.

Но это очень сильный аргумент.

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

1) Динамика удобнее при интеграции с другими динамическими системами или сервисами, о типизации которых на этапе компиляции ничего не известно.
Примеры — работа с удаленным rpc-сервером без схемы, чтение данных из базы если схема заранее неизвестна, стык с другими динамическими системами, в общем все юзкейсы для которых ms ввел dynamic.
Статическая типизация здесь никаких гарантий не даст, а под ногами мешаться будет.

2) Динамика удобнее, когда статическая типизация в имеющихся альтернативах недостаточно гибка. Например когда нужно объединение типов — вот в Nemerle есть variant, но что делать если одна переменная имеет тип A | B | C | D, а другая — A | C | E | F? Один variant-тип неудобно по многим причинам (ну например он должен быть объявлен в одной сборке) да и нужные нам статические проверки он не обеспечит, а если два — то проблема в том, что значения A1 и A2 будут разными, и вот мы уже пишем кучу ненужного затрудняющего понимание кода. Ну а если в языке даже неуклюжего variant/pm нет, то вообще туши свет — мысль, которая могла быть выражена лаконично, растекается. Да что там, в большинстве языков даже тип со значениями ( T | null (значение отсутствует) | undefined (значение не определено) ) уже страшная проблема.

3) Системы с горячей заменой кода. Наверное, удачно совместить ее со статической типизацией в принципе возможно, но пока на этом поле играет динамика.

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

Когда в руках молоток, все вокруг кажется гвоздями. Если проблемы типизации должно решать метапрограммирование, то у типизации проблема.

WH>1)Медленное исполнение.
WH>2)Большое потребление памяти.
WH>3)Серьёзные проблемы с поддержкой кода, если его больше 100 строк.
WH>4)Плохая поддержка ИДЕ.

Как и все трюизмы, эти, верные в целом (если, конечно, опустить "100 строк"), могут не соответствовать действительности в конкретных условиях.

Например, почему-то поддержка того же Эрланга со стороны ИДЕ намного лучше, чем существующая на данный момент поддержка Nemerle.

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

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

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

N>>А если вы решили что-то автоматизировать и обнаружили, что не можете до исполнения программы понять нужные свойства, т.к. это просто не предусмотрено? Хотя тяжело, конечно, без общего конкретного примера рассуждать.
_DA>Эмм, это вопрос уже конкретно по нашему проекту? Могу в приватных сообщениях рассказать, если интересно )

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

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

и сильно ли это повлияло на существующий код.

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

_>1) Динамика удобнее при интеграции с другими динамическими системами или сервисами, о типизации которых на этапе компиляции ничего не известно.
Ничего не сможешь с этим сервисом сделать. Даже обратится к нему не сможешь.
Либо тебе известен контракт. А если есть контракт, то уже есть типы.

_>Примеры — работа с удаленным rpc-сервером без схемы, чтение данных из базы если схема заранее неизвестна, стык с другими динамическими системами, в общем все юзкейсы для которых ms ввел dynamic.
И что ты будешь дальше делать?
Максимум что ты можешь сделать, это распечатать то, что ты получил.
Это при условии, что ты вообще смог к нему обратиться.

А вот если ты хочешь сделать что-то осмысленное, то тебе нужно знать что там лежит
Вот тут уже и появляются статическая типизация.

_>2) Динамика удобнее, когда статическая типизация в имеющихся альтернативах недостаточно гибка. Например когда нужно объединение типов — вот в Nemerle есть variant, но что делать если одна переменная имеет тип A | B | C | D, а другая — A | C | E | F?
Это легко делается.
Просто это нужно настолько редко что никто это не делает.
Но если тебе так хочется, к немерле 2 я это прикручу.

_>Ну а если в языке даже неуклюжего variant/pm нет, то вообще туши свет — мысль, которая могла быть выражена лаконично, растекается.
Так в большинстве динамически типизированных языков этого тоже нет.

_>Да что там, в большинстве языков даже тип со значениями ( T | null (значение отсутствует) | undefined (значение не определено) ) уже страшная проблема.
Мы всё ещё говорим про динамическую типизацию, где в переменной может быть любое говно?

_>3) Системы с горячей заменой кода. Наверное, удачно совместить ее со статической типизацией в принципе возможно, но пока на этом поле играет динамика.
Ну, она много где играет только по тому, что никто статику засунуть не пробовал.

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

_>Как и все трюизмы, эти, верные в целом (если, конечно, опустить "100 строк"), могут не соответствовать действительности в конкретных условиях.
Когда конкретно они не соответствуют действительности?

_>Например, почему-то поддержка того же Эрланга со стороны ИДЕ намного лучше, чем существующая на данный момент поддержка Nemerle.
Я ещё не видел ни одной ИДЕ для динамически типизированных языков, которую не мог бы запутать десятком строк кода.

_>Резюмируя — чтобы тащить динамику в продакшн действительно нужны веские причины, но при их наличии динамика не табу.
Пока что таких причин так и не назвали.

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

WH>>Статическая типизация этому не мешает.
ARK>Иногда мешает.
Ни разу не замечал. Единственное что мешает быстро писать код это непонимание того что нужно писать.

ARK>Вывод типов имеет дело с каким-то конкретным типом, а я имею дело с типом, который, возможно, вообще еще не объявлен.
Ну, где то ты заполняешь этот тип.

ARK>1) Не все используют IDE.
ARK>2) Не все используют IDE, генерящие такие заглушки.
Это их проблемы.

ARK>3) Это лишние телодвижения и, возможно, неиспользуемый мусор в коде.
Вот это ты проигнорировал.

WH>>2)Ничто не мешает компилятору генерировать такие заглушки.
WH>>Те выставил флаг компилятору, а он вместо ошибки начал давать предупреждение и выкидывать исключение при вызове метода.

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

_>Обычно 1-2 экрана. )
Те до 100 строк.
На таких объёмах динамика ещё не успевает превратиться в ад.

_>DSL там реализует не сам Питон, а соответствующие библиотечки для него. Например типа таких: http://docs.fabfile.org/en/1.10/tutorial.html
Для любого статически типизированного языка такое пишется примерно за день.

_>Ну так назови хотя бы один. В чём проблема? )))
10 секунд гугления.
http://www.haskellforall.com/2015/01/use-haskell-for-shell-scripting.html

_>1. Чтобы писалось не сложнее чем сейчас. Т.е. чтобы синтаксис языка был не тяжелее Питона и были в наличие нужные предметные библиотеки.

main = do
    cd "/tmp"
    mkdir "test"
    output "test/foo" "Hello, world!"  -- Write "Hello, world!" to "test/foo"
    stdout (input "test/foo")          -- Stream "test/foo" to stdout
    rm "test/foo"
    rmdir "test"
    sleep 1
    die "Urk!"

_>2. Чтобы запускалось не сложнее чем сейчас. Т.е. никаких там отдельных компиляторов, а просто некий универсальный исполнитель скриптов, который прописываем в path.
Либо есть либо пишется за пару часов.

_>3. Чтобы можно было увидеть ссылку на скачивание описанного чуда, а не утверждение, что это всё теоретически возможно (против этого никто и не возражал). ))))
Ещё 30 секунд гугления и ты найдёшь ещё много чего интересного.

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

ARK>>Вывод типов имеет дело с каким-то конкретным типом, а я имею дело с типом, который, возможно, вообще еще не объявлен.
WH>Ну, где то ты заполняешь этот тип.

Я могу просто вызвать метод "Process" у параметра метода. А потом позвать дополнительно еще IsValid. При этом никакого типа с этими Process/IsValid у меня пока нет (и, возможно, и не будет никогда), я просто набрасываю общую структуру. Может я, быстро найдя лучший вариант алгоритма, вообще удалю этот метод, не успев даже объявить нужный тип.

ARK>>3) Это лишние телодвижения и, возможно, неиспользуемый мусор в коде.
WH>Вот это ты проигнорировал.
WH>

WH>>>2)Ничто не мешает компилятору генерировать такие заглушки.
WH>>>Те выставил флаг компилятору, а он вместо ошибки начал давать предупреждение и выкидывать исключение при вызове метода.

Пардон, это я как-то пропустил. Ну да, с таким флагом будет то же самое. Но это и есть уже динамика по сути.

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

ARK>Я могу просто вызвать метод "Process" у параметра метода. А потом позвать дополнительно еще IsValid. При этом никакого типа с этими Process/IsValid у меня пока нет (и, возможно, и не будет никогда), я просто набрасываю общую структуру. Может я, быстро найдя лучший вариант алгоритма, вообще удалю этот метод, не успев даже объявить нужный тип.
Так в чём проблема то?
Или ты хочешь обязательно запустить недописанный код?

ARK>Пардон, это я как-то пропустил. Ну да, с таким флагом будет то же самое. Но это и есть уже динамика по сути.
Нет. Это только для прототипа. Для релиза это нужно отключать.
И тогда компилятор всё отловит.

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

ARK>>Я могу просто вызвать метод "Process" у параметра метода. А потом позвать дополнительно еще IsValid. При этом никакого типа с этими Process/IsValid у меня пока нет (и, возможно, и не будет никогда), я просто набрасываю общую структуру. Может я, быстро найдя лучший вариант алгоритма, вообще удалю этот метод, не успев даже объявить нужный тип.
WH>Так в чём проблема то?
WH>Или ты хочешь обязательно запустить недописанный код?

Ну да, что-то быстренько набросать и запустить недописанное, посмотреть на работу какого-то куска.

ARK>>Пардон, это я как-то пропустил. Ну да, с таким флагом будет то же самое. Но это и есть уже динамика по сути.
WH>Нет. Это только для прототипа. Для релиза это нужно отключать.
WH>И тогда компилятор всё отловит.

Окей, пусть для прототипа — все равно, это же и есть динамика, просто реализованная таким вот странным образом.

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

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

_>>Обычно 1-2 экрана. )
WH>Те до 100 строк.
WH>На таких объёмах динамика ещё не успевает превратиться в ад.

Ну так таких задач то множество. Кстати, если посмотреть на многие веб-решения, то хотя в целом система выглядит большой, но на практике всё сводится ко множеству не связанных между собой скриптов как раз такого размера (обычно просто прокладка между браузером и БД).

_>>DSL там реализует не сам Питон, а соответствующие библиотечки для него. Например типа таких: http://docs.fabfile.org/en/1.10/tutorial.html
WH>Для любого статически типизированного языка такое пишется примерно за день.

Нуу не за день, а скажем за недельку (общее решение, а не частный скрипт), но да, ничего сложного. Только вот дело в том, что у меня есть множество других дел, гораздо более сложных, и тратить время на написание подобной ерунды нет никакого желание. Хочется просто скачать и чтобы всё работало из коробки. )

_>>Ну так назови хотя бы один. В чём проблема? )))
WH>10 секунд гугления.
WH>http://www.haskellforall.com/2015/01/use-haskell-for-shell-scripting.html
_>>1. Чтобы писалось не сложнее чем сейчас. Т.е. чтобы синтаксис языка был не тяжелее Питона и были в наличие нужные предметные библиотеки.
WH>

WH>main = do
WH>    cd "/tmp"
WH>    mkdir "test"
WH>    output "test/foo" "Hello, world!"  -- Write "Hello, world!" to "test/foo"
WH>    stdout (input "test/foo")          -- Stream "test/foo" to stdout
WH>    rm "test/foo"
WH>    rmdir "test"
WH>    sleep 1
WH>    die "Urk!"
WH>

Это Хаскель то не тяжеловесный? ))) Ну да, если держаться строго в рамках этого DSL, то конечно всё выглядит просто. Только вот в таких случаях скрипты и не нужны особо (хватит обычных bat файлов). А стоит сделать малейших шаг в сторону (собственно ради чего и нужен Питон), как в данном случае всплывут кривые монады и прочие радости Хаскеля. При таком подходе я буду думать скорее не о требуемом алгоритме скрипта, а о том как же его записать на этом "модном" языке...)))

_>>3. Чтобы можно было увидеть ссылку на скачивание описанного чуда, а не утверждение, что это всё теоретически возможно (против этого никто и не возражал). ))))
WH>Ещё 30 секунд гугления и ты найдёшь ещё много чего интересного.

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

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

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

_>Нуу не за день, а скажем за недельку (общее решение, а не частный скрипт), но да, ничего сложного.
Я говорю по запускалку.
Что там неделю писать?

_>Только вот дело в том, что у меня есть множество других дел, гораздо более сложных, и тратить время на написание подобной ерунды нет никакого желание. Хочется просто скачать и чтобы всё работало из коробки. )
Мы говорим не про то есть готовые инструменты или нет, а про то есть ли толк от динамической типизации.
Это сильно разные темы.

_>Это Хаскель то не тяжеловесный? ))) Ну да, если держаться строго в рамках этого DSL, то конечно всё выглядит просто. Только вот в таких случаях скрипты и не нужны особо (хватит обычных bat файлов). А стоит сделать малейших шаг в сторону (собственно ради чего и нужен Питон), как в данном случае всплывут кривые монады и прочие радости Хаскеля. При таком подходе я буду думать скорее не о требуемом алгоритме скрипта, а о том как же его записать на этом "модном" языке...)))
Ты только что читал насквозь монадический код.
Слово do видишь? Это начало монадического кода.

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

ARK>Если компилятор позволяет обойти проверки типов (и даже проверки наличия методов), вместо этого выбрасывая в рантайме исключения — то мы получаем по факту динамику.
Разница в том, что в случаи динамически типизированным языком ты не сможешь отключить этот ключик и получить все проверки.

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

ARK>>Если компилятор позволяет обойти проверки типов (и даже проверки наличия методов), вместо этого выбрасывая в рантайме исключения — то мы получаем по факту динамику.
WH>Разница в том, что в случаи динамически типизированным языком ты не сможешь отключить этот ключик и получить все проверки.

Да, это я понял. Но, ИМХО, это и не требуется — набросал небольшой прототип или скрипт, задачу выполнил и забыл.

Зато некий ненужный мусорок в коде появляется — надо же написать названия хотя бы фейковых типов для параметров методов и возвращаемых значений.

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

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

LP>>Пытаетесь объять необъятное?
WH>Нет.

Но ощущение складывается именно такое.

LP>>Да ну?
WH>Компилятор может написать любой профильный студент. И даже некоторые школьники.
WH>Нормальных ИДЕ раз, два и обчёлся.

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

LP>>Это сомнительно хотя бы потому, что универсальные генераторы IDE есть уже давно (https://eclipse.org/Xtext/),
WH>Крайне ограниченная штука с кучей закатов солнца вручную.

Закаты вручную там начинаются как раз при компиляции. Иде делается достаточно прямо и тупо.

LP>>а вот действительно универсальные генераторы компиляторов — такого история не знает. Каков должен быть алгоритм, который лишь из одного метаописания языка С++ может комплировать С++ код, а из метаописания языка Prolog-a — Prolog-код?
WH>https://en.wikipedia.org/wiki/Graph_rewriting закрывает процентов 90.

Универсальный алгоритм абсолютно бесполезен. Иначе все в этом мире писалось бы на Прологе, который работает на одном-единственном алгоритме перебора с откатами, ну и костылями, позволяющими ограничить перебор. Ну еще я не знаю ни одной реализации пролога, которая использовала бы graph rewriting. Это говорит о том, что использование этого алгоритма менее обравданов данном случае, ну или что все идиоты.

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

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

DE>>Вот только мейнстримовых (статически типизированных) языков с "выводом типов и метапрограммированием" (практически?) нет. А динамика вполне доступна и "пропихнуть в продакшен", наверное, легче чем немерле.
WH>Пихать динамику в продакшен глупо. Всегда.

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

ObjectFromSystem1 objSys1 = system1.obtainSomeObject();
ObjectFromSystem2 objSys2 = new ObjectFromSystem2();
objSys1.field1 = objSys2._field1;
objSys1.field2 = objSys2._field2;
...
system2.send(objSys2);

Здесь обращение к полям объектов равносильно их декларации в классе.

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

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

При выполнении становится известен. На стадии компиляции нет.

WH>И что ты будешь дальше делать?
WH>Максимум что ты можешь сделать, это распечатать то, что ты получил.

Да все что угодно. Например, что пользователь скажет (приложения или библиотеки).

WH>А вот если ты хочешь сделать что-то осмысленное, то тебе нужно знать что там лежит
WH>Вот тут уже и появляются статическая типизация.

Ну вот json там лежит, к примеру, одному из тысячи. Осмысленность привнесет пользователь скриптом на JavaScript. Зачем мне тут статическая типизация?

_>>2) Динамика удобнее, когда статическая типизация в имеющихся альтернативах недостаточно гибка. Например когда нужно объединение типов — вот в Nemerle есть variant, но что делать если одна переменная имеет тип A | B | C | D, а другая — A | C | E | F?
WH>Это легко делается.
WH>Просто это нужно настолько редко что никто это не делает.
WH>Но если тебе так хочется, к немерле 2 я это прикручу.

Поверю на слово, если приведешь типы этих двух переменных.

_>>Ну а если в языке даже неуклюжего variant/pm нет, то вообще туши свет — мысль, которая могла быть выражена лаконично, растекается.
WH>Так в большинстве динамически типизированных языков этого тоже нет.

Чего нет, вариантов? (все-таки в примере упор на варианты, а не pm — что до pm, то где-то есть, а где-то его заменяют другие языковые средства).

_>>Да что там, в большинстве языков даже тип со значениями ( T | null (значение отсутствует) | undefined (значение не определено) ) уже страшная проблема.
WH>Мы всё ещё говорим про динамическую типизацию, где в переменной может быть любое говно?

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

А в переменной будет то, что в нее положили.

_>>3) Системы с горячей заменой кода. Наверное, удачно совместить ее со статической типизацией в принципе возможно, но пока на этом поле играет динамика.
WH>Ну, она много где играет только по тому, что никто статику засунуть не пробовал.

Когда засунут, тогда сравним. Пока засчитаем победу за неявкой соперника.

(На всякий случай, горячая замена кода — это киллер-фича для определенного класса задач).

_>>Когда в руках молоток, все вокруг кажется гвоздями. Если проблемы типизации должно решать метапрограммирование, то у типизации проблема.
WH>Дело в том, что динамическая типизация позволяет некоторое метапрограммирование.
WH>Так что если в языке нет метапрограммирования, то сравнение будет просто не корректным.

Ясно.

WH>Ну и вывод типов ты изящно проигнорировал.

А я просто не понял этот аргумент. Он позволяет писать меньше кода, экономя на явном указании типов? В контексте дискуссии это мелочи. Или что-то еще?

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

_>>Как и все трюизмы, эти, верные в целом (если, конечно, опустить "100 строк"), могут не соответствовать действительности в конкретных условиях.
WH>Когда конкретно они не соответствуют действительности?

Касательно ресурсов:
Как программисты мы решаем инженерные задачи. Наша программа должна работать в заданных ограничениях. Нет смысла говорить о "в общем низкой производительности" или "в общем высоком потреблении памяти". Память не имеет значения для cpu или io bound приложений на выделенном сервере. Допустимая производительность некоторых консольных приложений может варьироваться в пределах нескольких порядков. Игровой клиент должен выдать 60fps на заданной спецификации. Сервер должен обеспечить заданные ccu или количество запросов в секунду.

Как только мы выходим за рамки требований, разговор теряет всякий смысл. GC медленный, IL медленный, динамика медленная, трамваи медленные. Один C++ быстрый, и веб-сайты нужно писать на нем.

Касательно стоимости поддержки:
Технически у динамики есть свои плюсы, которые в ветке упоминались. Рефакторинг часто делать быстрее, хотя гарантий компилятора много меньше. Ввообще польза от статической компиляции при поддержке в первую очередь носит информационный характер. Баги типизации в динамике — относительная редкость, легко ловятся и очень легко чинятся. (Сужу по опыту, статистикой не владею).
Опять же, стоимость поддержки — задача в том числе экономическая, и если в моей деревне программиста поддержки, перешедшего, к примеру, с java на средних размеров проект с Питоном, Эрлангом, JS или пусть тогда и C# можно обучить максимум за месяц, после чего он начнет приносить пользу, то Nemerle и С++ сложнее и дороже.

_>>Например, почему-то поддержка того же Эрланга со стороны ИДЕ намного лучше, чем существующая на данный момент поддержка Nemerle.
WH> Я ещё не видел ни одной ИДЕ для динамически типизированных языков, которую не мог бы запутать десятком строк кода.

Честно говоря, не вижу прямой связи между моим утверждением и твоим возражением.

_>>Резюмируя — чтобы тащить динамику в продакшн действительно нужны веские причины, но при их наличии динамика не табу.
WH>Пока что таких причин так и не назвали.

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

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

LP>Ну и? Ты ведь говоришь не про компилятор под определенный язык, а универсальный компилятор. Я все жду, когда же ты скажешь наконец, что ваш продукт предоставляет (или собирается предоставлять) способ для более быстрого построения компилятора под конкретный язык (это именно то, что люди ждут от подобных инструментов), но ты все твердишь про полностью автоматический способ построения такого компилятора исходя лишь из формального описания языка, что можно реализовать лишь для определенного семейства похожих языков, но не для всего множества существующих языков.
Тут главная идея в иерархии языков.
Те если у нас в стандартной поставке будет
MSIL++ -> MSIL ибо MSIL ужасен. Делать переписывание напрямую в него весьма утомительное занятие.
MSIL -> LLVM
MSIL -> JavaScript

То реализовав C# -> MSIL++ мы автоматом получим компиляцию C# в MSIL, LLVM и JavaScript.

LP>Закаты вручную там начинаются как раз при компиляции. Иде делается достаточно прямо и тупо.
Когда я на него смотрел, они там были везде.

LP>Универсальный алгоритм абсолютно бесполезен. Иначе все в этом мире писалось бы на Прологе, который работает на одном-единственном алгоритме перебора с откатами, ну и костылями, позволяющими ограничить перебор. Ну еще я не знаю ни одной реализации пролога, которая использовала бы graph rewriting. Это говорит о том, что использование этого алгоритма менее обравданов данном случае, ну или что все идиоты.
Какое отношение пролог имеет к переписыванию одного языка в другой?
Да ни какого.
Он для этой задачи вообще плохо подходит.

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

LP>Кроме одного случая. Когда динамика используется для интеграции систем друг с другом (на уровне получить из одной системы и передать в другую) при отсутствии всякого метаописания, то есть без возможности автоматически сгенерировать классы.
И когда такое происходит?

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

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

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

_>Ну вот json там лежит, к примеру, одному из тысячи. Осмысленность привнесет пользователь скриптом на JavaScript. Зачем мне тут статическая типизация?
Я вообще не понимаю, что за сценарий ты описываешь.

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

case A { ... }
case B { ... }
case C { ... }
case D { ... }
case E { ... }
case F { ... }
set Set1 = A | B | C | D;
set Set2 = A | C | E | F;
set Set3 = A | C;

Переменные типа Set3 можно без проверки во время исполнения присвоить переменным типа Set1 и Set2.

_>Чего нет, вариантов? (все-таки в примере упор на варианты, а не pm — что до pm, то где-то есть, а где-то его заменяют другие языковые средства).
Жуткий закат солнца вручную его заменят.

_>Нет же, про статическую (в языках, в которых проблемы с выражением простой дизъюнкции типов).
1)Это проблемы конкретных языков.
И я сразу написал, что есть плохие статически типизированные языки.

Единственный объективный аргумент в пользу динамической типизации: Нужно писать меньше кода.
Но если в случае с жабой выигрыш существенный. То в случае с языками, где есть вывод типов и метапрограммирование выигрыш сводится примерно к нулю.

(С)

Автор: WolfHound
Дата: 03.08.15

Ну и в динамике вообще никакого контроля нет.

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

_>Ну и опять же, в динамическом Эрланге и типы можно указывать, и вывод типов есть. Просто проверка типизации происходит не при компиляции, а при статическом анализе.
Те отдельным инструментом превращаем эрланг в статически типизированный язык.
И почему появился этот инструмент?
Просто тут меня пытаются убедить, что это всё не нужно.

_>Как программисты мы решаем инженерные задачи. Наша программа должна работать в заданных ограничениях. Нет смысла говорить о "в общем низкой производительности" или "в общем высоком потреблении памяти". Память не имеет значения для cpu или io bound приложений на выделенном сервере. Допустимая производительность некоторых консольных приложений может варьироваться в пределах нескольких порядков. Игровой клиент должен выдать 60fps на заданной спецификации. Сервер должен обеспечить заданные ccu или количество запросов в секунду.
А потом происходит рост нагрузки и большие разборки в EVE online превращаются в пошаговые.
А всё по тому, что питон не тянет.

А если ещё вспомнить про то, что вычисления требуют энергию... а потом вспомнить про мобильные устройства...
Короче если приложение будет работать в 10 раз медленнее, то оно съест батарею в 10 раз быстрее.
Даже не смотря на то, что отклик у него будет удовлетворительным.

_>Как только мы выходим за рамки требований, разговор теряет всякий смысл. GC медленный, IL медленный, динамика медленная, трамваи медленные. Один C++ быстрый, и веб-сайты нужно писать на нем.
IL тормозит только по тому, что мелкософт не вложился в оптимизатор от слова совсем.

_>Технически у динамики есть свои плюсы, которые в ветке упоминались.
Не выдержали критики.

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

Что мне даст динамика? Да ничего.

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

_>и если в моей деревне программиста поддержки, перешедшего, к примеру, с java на средних размеров проект с Питоном, Эрлангом, JS или пусть тогда и C# можно обучить максимум за месяц, после чего он начнет приносить пользу, то Nemerle и С++ сложнее и дороже.
Про С++ согласен. Он очень запутанный.
А вот про немерле нет. Чтобы после жабы не выучить его за несколько дней нужно быть полный гоблином.

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

_>Ну как же, называли, с одной ты даже согласился
С какой?

_>- есть ниши, где на данный момент статическая типизация не представлена.
Это ты про то, что какой-то диверсант засунул жабаскрипт в браузеры?