VladD2,
NL>>К счастью, сигналов к спаду не видно, есть примеры компаний, решивших на полный переход с Java на Scala за кратчайшие сроки.
VD>Дай та Бог. Но верится с трудом.
Здравствуйте, Evgeny.Panasyuk, Вы писали:
EP>Почему не нужен? Если можно описать это в виде PM, а не через убогие запятые.
Потому что это грамматика, а не ее использование (т.е. новый синтаксис). В виде ПМ ее просто не описать. Нечего ПМ-мить. А, запятые — это кривой синтаксис сделанный поляками когда-то. Убрать их было бы не сложно. Там проблема в другом. Возможности расширения синтаксиса сильно ограничены. Вот в Nitra все тоже самое достигается за счет использования полноценных расширяемых грамматик.
EP>Помимо строковых макросов есть мощные шаблоны которых нет в Nemerle, и поэтому макросы нужны намного реже чем в Nemerle.
Из итересного там только переменное количество параметров. В остальном шаблоны и дженики довольно близки. А, МП на шаблонах я категорически не поддерживаю. Это всегда выливается в оверхэд и геморрой.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
VD>К тому же Немерле не столь радикально отличается от C#. Целевая аудитория у Немерла скорее всего C#-разработчики переросшие C#. У них бы не возникло проблем ни с освоением Немерла, ни с использованием двух языков. По сути они очень близки.
Если вы именно так определяете целевую аудиторию Nemerle, то тогда хочу сообщить вам, что она очень и очень маленькая.
Скажем большинство отписывающихся в этой теме (включая и меня) к ней не относятся.
VD>В прочем, я понимаю, что это аргумент. И у меня есть идея сделать чистый суперсет C# или с минимальными изменениями по делу. Возможно это упростит "взлет". Сейчас мы себе уже такое можем позволить за счет Nitra.
Возможно. Хотя лично мне от этого будет ни холодно ни жарко. ))) Но желаю успеха. )
Здравствуйте, VladD2, Вы писали:
_>>C# — "ничего", мейнстрим. _>>Java — "ничего", мейнстрим. _>>C++ — "хотя бы что-то", мейнстрим. _>>Nemerle, D — "хорошо развито", маргинальный язык. VD>Дык, и с какого перепугу то, они маргинальные? Ну, ди ладно. Он совсем не похож на плюсы. Но Nemerle — это по сути правильно спроектированный C#. C# в котором устранены некоторые проблемы, добавлена отличная поддержка ФП и реализовано МП/DSL-естроение.
А какие они, мейнстрим что ли? )
VD>Кроме того твои слова имеют смысл для С++ у которого аудитория отнюдь не расширяется в последнее время. А, для C#/дотнета? А, для Явы?
В последнее время заметно расширялись вообще только Objective-C (понятно из-за чего и уже перестал — началось падение) и JS. )
Что касается метапрограммирования на платформах jvm и .net, то на мой взгляд это не имеет большого смысла из-за самой ориентации этих платформ. Хотя конечно некий совсем небольшой процент желающих усложнить платформу безусловно будет. Его можно оценить по уровню распространённости той же Scala. Однако в большинстве случаев оно не нужно потребителям данных платформ. И тут я имею в виду не программистов, а бизнес, который нанимает этих программистов.
NL>>>К счастью, сигналов к спаду не видно, есть примеры компаний, решивших на полный переход с Java на Scala за кратчайшие сроки. VD>>Дай та Бог. Но верится с трудом.
NL>Guardian.co.uk NL>zalando.de (модный сайт, 15 млн юзеров, 200 технарей) NL>Bank of America
Здравствуйте, Геннадий Васильев, Вы писали:
ГВ>А с DSL как-то совсем не понятно: это что, каждый на своём языке будет писать?
Когда говоришь о DSL, вспоминай в первую очередь регэкспы. Идеальный пример DSL.
Другой хороший пример DSL — описания грамматик для парсера.
Еще один хороший пример DSL — UML (например, для описания конечного автомата).
И напоследок еще один — математика (например, матрично-тензорно-векторные операции, или интегрирование/дифференцирование). Чтоб инженерам-математикам-физикам, которые смотрят на код, что-то считающий, было сразу видно, какая в нем формула записана (с поправкой на линейный, а не двумерный, синтаксис) и правильна ли она.
Это даже не говоря о более нишевых, создающихся под конкретную задачу, которую решает данный софт.
В данном случае "каждый" — это каждая команда.
Да, внутри команды будет свой собственный DSL — в чем проблема? По большому счету, любая хорошая (в смысле API) библиотека — это уже DSL, просто с "обычным" синтаксисом.
На самом деле даже не важно имеют их аргументы смысл или нет. Важнее другое. Тут мы имеем примеры двух однозначных представителей целевой аудитории Rust, причём явно следящих за ним всё последнее время. Однако после его релиза они говорят о том, что всё же не будут его применять на практике. Т.е. значит что почему-то не зацепил в достаточной степени...
Здравствуйте, VladD2, Вы писали:
EP>>Не пользоваться же тем, что работает на совершенно не подходящей платформе. EP>>...Ещё раз, мне в первую очередь не нужен .NET, а Nemerle уже как следствие из этого. VD>Ну, ты же пользующийся Шарпом? Пусть для мелочевки, но ведь пользуешся?
Там где я им пользуюсь, у меня задание именно сделать пример на C# к биндингам-C++, то есть Nemerle тут вообще никак не подходит. Некоторые клиенты используют C#, и примеры для них нужны именно на C#.
VD>>>Если отбросить метапрограммирование, то не очень то там много преимуществ по сравнению с дженериками дотнета. EP>>Много + higher-rank polymorphism. VD>А, для чего ты его на практике (без метапрограммирования) использовать можешь?
Например:
* non-type template paramter для точек/симплексов произвольной размерности. Размерность N задаётся как параметр шаблона структуры, а внутри структуры массив фиксированного размера N. Массив таких структур выделяется за одну аллокацию.
* ситуации подобные этой
делаются на раз. В обобщённом коде такое не редко вылезает — комбинатор имеет минимум информации о том что он комбинирует.
VD>>>Разве что иногда можно получить более оптимальный код и операторы использовать. EP>>"иногда" — это ты сильно лукавишь, VD>Ничего я не лукавлю. Проблемы с дженериками реально появляются только, если хранятся вэлью-типы (особенно предопредеделные) и над ними нужно выполнять некие операции которые невозможно описать через констрэйны дженериков (не выражаются в виде интерфейсов). Там, да, приходится таскать с собой лямбды обобщающие вычисления.
Тут я говорю не про синтаксические ограничения, а про оптимальность. Любая ФВП приводит к тормозам, в то время как в C++ они бесплатны, либо практически бесплатны.
EP>>либо совершенно не представляешь масштаб. Например C++ скомпилированный в JavaScript (!!!) оказывается в два раза быстрее
аналогичного кода на C#. VD>А, это не более чем вопрос кодогенерации.
Оптимальную кодогенрацию для C++ делать проще, за счёт семантики языка. В этом примере на C++ нет ни одного косвенного вызова по построению.
EP>>Опять лукавишь. Лямбды/замыкания в C++ лучше зоопарка из C#, могут больше (полиморфные лямбды), и работают быстрее. VD>Ни фига они больше не могут. Полноценных замыканий нет.
Аргументы?
VD>Так что или все в рэйдонли, или следи за временем жизни сам.
Они read-only по умолчанию, но это ортогонально времени жизни
При этом эти замыкания спокойно могут захватывать ресурсы
.
VD>Плюс убогий синтаксис убивающий всю выразительность.
return и пара скобочек не принципиальная проблема. В том же Lisp/Scheme/Clojure этих скобочек на порядок больше.
VD>Что до полиморфности, то в Немерле тоже можно сделать полиморфную лямбду. Только по жизни это совершенно не нужно.
1. Здесь речь про C#, а не Nemerle
2. Полиморфные лямбды для меня это главная фича C++14. Например очень удобно при обработки гетерогенных структур данных.
VD>>>Не натягивай сову на глобус. "type erasure" — это термин из Явы. EP>>type erasure это общий термин, не ограниченный Java'ой. VD>Приведи мне ссылку на стандарт C# где бы использовался этот термин или его аналог.
А при чём тут стандарт C#? Это общее-программерский термин.
VD>Ты что-то себе выдумал или не понимаешь значения этого термина. В дотнете все типы жденериков хранятся в метаданных. Никакой потери информации не случается.
Потеря происходит при AOT компиляции.
VD>>>В дотнете его нет. EP>>Есть — сохранение лямбды в Func<...> — это и есть стирание конкретного типа лямбды. VD>Что за чушь?
Хочешь сказать generic функция принимающая Func<...> компилируется для каждого варианта лямбды отдельно?
EP>>И методы компилируются под этот стёртый тип. В то время как в C++, принимая лямбду через шаблон — мы получаем всю информацию необходимую для инлайнинга. VD>Это никакого отношения к стиранию типов не имеет. Иначе наследование и полиморфизм — это тоже стирание типов.
Вообще-то так и есть.
VD>А, для инлайниннга нужно просто иметь исходник (вернее его AST). В дотнете это вполне возможно, так как код тоже является метаданными и может быть довольно качественно восстановлен из байткода. Плюс инлайнинг возможен на уровне байткода.
Всё действительно возможно. И C++ компиляторы могут инлайнить при стирании типов, но даже у них это получается с трудом. Намного проще инлайнить простые вызовы (которые в C++ по построению), чем косвенные.
VD>Делаем анализ, что ссылка на predicate локальна для метода и принимаем решение инлайнить. Получаем: VD>
VD> int result = 0;
VD> foreach (x in source)
VD> if (x % 2 == 0)
VD> result += current;
VD>
Вот в примере выше с transform — там всё в одном .cs файле, одна простая ФВП (даже без yield), и одна простая лямбда — в результате никакого инлайна и тормоза.
VD>Другое дело когда ссылка на лямбду пришла из другой библиотеки скомпилированной бинарно и недоступной на момент компиляции. Но, тут и С++ ничего сделать не может.
Необязательно при компиляции, есть ещё link-time optimization. Но я о другом говорю — код C++ проще оптимизировать по его построению, а не потому что оптимизаторы умеют инлайнить косвенные вызовы (в простых случаях они действительно умеют).
EP>>Передавая две разные лямбды в один и тот же шаблон функции — мы получаим разные воплощения этого шаблона, с разными адресами. VD>Ну, и тут тоже самое можно делать.
Где? В C#? Как?
EP>>Если же стирать тип в C++ (например через std::funciton) — то инлайнить такой код точно также намного сложнее. VD>Это не стирание типа. Ты неверно термин понимаешь.
std::function это самое что ни на есть type erasure.
VD>>>Места затрудняющие оптимизации есть, но их не много. EP>>Да они практически пронизывают весь язык. VD>Это домыслы.
Это факты: двухкратное сливание C++ коду скомпилированному в JS, и это ещё пример простенький — всего одна ФВП и лямбда.
VD>>>Те же лябды не инлайнят не потому что нельзя, а потому что руки до оптимизаций подобного рода не доходят. EP>>Их можно инлайнить, но это намного сложнее. VD>Я выше показал. Ничего сложного в этом нет.
Инлайнинг косвенного вызова сложнее инлайнинга обычного, согласен?
VD>>>Дотнет все же далет одна команда в Рэдмонде, а С++-ом занимаются вот уже 30 лет десятки команд по всему свету. EP>>Вообще не аргумент — Clang появился позже .NET, и он уделывает C# код даже при компиляции в JavaScript VD>Это уже демагогия.
Это реальный тест.
VD>По жизни грамотно написанный код на дотнете работает не сильно медленее чем тот же на любом супер-оптимизирующем компиляторе.
Я в той теме многократно говорил о том что и на C# и на Java действительно можно создавать быстрый код, но для этого приходится отказываться от абстракций, и вручную выпиливать низкоуровневый код. Потому что эти абстракции дорогие, в отличии от бесплатных, или практически бесплатных в C++.
Здравствуйте, VladD2, Вы писали:
VD>Не надо их брать, так как это полная чушь, а не цифры. Нельзя по запросам строк судить по частоте использования языка. Как-кой нибудь идиот нагенерит 100500 директорий с именем языка и внезапно получается, что Скала популярнее Шарпа.
Ты не согласен с самими цифрами или с их источником?
_>>Смотри, Nemerle нацелен на определённую нишу, а именно на использование возможностей МП. VD>А, С++ нацелен на использование МП?
Скажем так, C++ вполне конкурентен и без МП (хотя лично мне он такой уже не подходит) хотя бы за своё быстродействие. А вот у Nemerle без МП нет киллер-фич в сравнение с C#.
VD>Ну, какого хрена загонять язык общего назначения в нишу "использование МП"? Язык по всем критериям лучше C#. Если исключить тулинг, то трудно найти код который бы оказался бы кратче или красивее будучи написанным на Шарпе. VD>Но, почему-то ниша Шарпа, по твоему, шире чем ниша Немерла.
Не совсем так. Речь идёт о той нише, где есть смысл в переходе с C# на Nemerle. А так то понятно, что теоретически любой C# код можно заменить на Nemerle, только вот непонятно зачем тратиться на такой переход, не получая никаких ощутимых бонусов.
VD>И? МП на шаблонах еще более сложная и невнятная штука. Как это тебе мешает использовать Буст и другие библиотеки?
А у Nemerle есть свой аналог Boost'а? )
_>>В то время как платформы Java и .Net ориентированны в первую очередь на внутрикорпоративную разработку VD>Плюс это не совсем так. На дотнете и яве пишут различнийший софт. Тот же ReSharper и IDEA тому отличный пример. Вы бы назвали эти задачи "системными".
Не стоит выдавать явные исключения за правило. )
_>>Кстати говоря, это совсем не минус этих платформ, а как раз их главное преимущество. Только вот с точки зрения распространение МП на них это весьма печально... Сомневаюсь, что даже каждый десятый тут хорошо знаком с концепцией МП. VD>Да, во всю там МП используется. Мало кто хочет выписывать классы для того же ORM руками.
Нуу если называть интроспекцию времени исполнения метапрограммированием, то конечно же... Представляю ступор этих товарищей, когда им предложат быстренько накидать свой DSL на макросах... )))
_>>В итоге получаем что если бы Немерле был нативным, то теоретически мог бы заинтересовать каждого десятого разработчика. А при текущем выборе .net'a он хорошо если каждого сотого заинтересует. Надо ли пояснять, что означают такие цифры с точки зрения маркетинга? ) _>>P.S. Понятно, что все эти цифры условные. Но я думаю ты прекрасно понимаешь, что реальные цифры всё равно уложатся в описанные тенденции. VD>Цифры эти не верные. Верно только, что если бы язык охватывал бы больше платформ, то и вероятность заинтересовать больше программистов была бы больше.
Главное не конкретные цифры, а тенденции. Не думаю, что в них я ошибся. )
VD>Я бы с удовольствием перевел бы немерл на все существующие платформы, но как ты понимаешь, это не простое и не бесплатное удовольствие.
А если попробовать реализовать скажем фронтенд к gcc? )
Здравствуйте, VladD2, Вы писали:
VD>Снобизм у вас, у сиплюсплсников серьезный. Отсюда и выводы неверные. В серьезных задачах скорость достигается не за счет битовыжимательных способностей языка, а за счет грамотно организации кэшей и их инкрементальный обновлению. VD>Важно, только чтобы отставания от битовыжимателей не было в разы. Вот именно это и происходит.
А по факту, там где нужна скорость, биты таки выжимают везде (это можно дать ускорение на порядок, а то и несколько), в том числе и на Java. Вот конкретный пример, ручная нарезка массивов на структуры через байт-буфера, отказ от GC, и прочие кактусы радости: http://www.youtube.com/watch?v=Q-7y1u9kZV0
Здравствуйте, kochetkov.vladimir, Вы писали:
KV>Здравствуйте, gandjustas, Вы писали:
KV>>>О каком событии идет речь и какие кейсы не покрывает в данном случае Nemerle по сравнению с C#? G>>Ты не понял. KV>Возможно, но на всякий случай обновил пример с событиями на сайте: http://www.nemerle.org/About#ID0EIH
Увы, это нужно было 5 лет назад, сейчас уже смысла немного.
G>>Мс предлагает фичу для решения конкретных проблем. Nemerle предлагает фичу просто потому что её можно сделать. KV>Это не так. Могу заверить, что фичи, добавляемые в Nemerle, всегда решают конкретную проблему. В противном случае, они просто не добавляются или улетают в Snippets.
Может и не так, но об этом никто не знает. На взгляд обывателя в Nemerle 100500 фич, которые неизвестно как использовать.
Чтобы разобраться — нужно напрягать мозг, а люди в принципе этого очень не любят. Им лучше меньше фич и понятное использование каждой, чем наоборот.
В этой ситуации лидер — C#, там каждая фича имеет под собой очень жизненную ситуацию и очень легко найти руководство к использованию фич в подобных ситуациях.
Здравствуйте, VladD2, Вы писали:
VD>Короче, все те же споры пошли по кругу. Причем один в качестве аргумента приводит довод, что неудобно в одном проекте использовать два очень близких языка (Шарпа и Немерле), а другой ратует за внесение в проект совершенно разных языков и за перенос контроля типов на рантайм.
Ты не следишь за тем, кто и что пишет. Это один человек... Re[17]: За счет чего выстреливают языки?
Здравствуйте, jazzer, Вы писали:
ГВ>>А с DSL как-то совсем не понятно: это что, каждый на своём языке будет писать?
J>Когда говоришь о DSL, вспоминай в первую очередь регэкспы. Идеальный пример DSL. J>Другой хороший пример DSL — описания грамматик для парсера. J>Еще один хороший пример DSL — UML (например, для описания конечного автомата). J>И напоследок еще один — математика (например, матрично-тензорно-векторные операции, или интегрирование/дифференцирование). Чтоб инженерам-математикам-физикам, которые смотрят на код, что-то считающий, было сразу видно, какая в нем формула записана (с поправкой на линейный, а не двумерный, синтаксис) и правильна ли она.
J>Это даже не говоря о более нишевых, создающихся под конкретную задачу, которую решает данный софт. J>В данном случае "каждый" — это каждая команда. J>Да, внутри команды будет свой собственный DSL — в чем проблема? По большому счету, любая хорошая (в смысле API) библиотека — это уже DSL, просто с "обычным" синтаксисом.
В принципе, не бесспорно, но в основном согласен. Однако, обрати внимание — почти во всех перечисленных тобой случаях хорошо очерчена задача, которую решает та или иная система, и эта задача выходит за пределы собственно построения DSL:
— Регэкспы — анализ текста по регулярным выражениям (принципы анализа, скорость разбора, а потом уже способ записи);
— Грамматики — построение анализатора для другого языка (как строить, из каких примитивов и т.п.);
— UML — опять таки, сначала ставится задача переноса конструктивных элементов UML на код, а потом уже — форма записи в текстовом виде;
— Математика — ну, здесь ещё более или менее, хотя сама по себе задача не сказать, чтобы очень распространённая;
— API — здесь понятно, сначала строится сама библиотека для каких-то отвлечённых (от DSL) целей.
То есть в "типовых" случаях, приводиимых для иллюстрации использования DSL, сам DSL — сугубо вторичная задача по отношению к какой-то ещё, к тому, что зашифровано под буквой D — domain. И если первичная задача поставлена и так или иначе решается, то создать DSL под неё обычно не представляет большой проблемы. Отсюда попытка сместить акценты в сторону самого построения DSL приводит слушателей, скажем так, в замешательство, т.к. контекст расширяется, и получается то, о чём я написал выше:
это что, каждый на своём языке будет писать?
Update: Собственно, в качестве примера DSL ещё неплохо приводить лисповский LOOP и лисповский же FORMAT. Вот уж, где собрано всё, что могло присниться и привидеться, но опять таки, оба этих "языка" заточены под конкретную задачу и сам по себе язык не сказать, чтобы представлял какую-то особую проблему.
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Здравствуйте, VladD2, Вы писали:
VD>Да, ни фига это не повышает производительность того кто пишет на нормальном языке. Уровень кода на Немерле не ниже сктиптового. Это по сравнению с С++ там какой-то выигрышь. Разве что изменять код интерактивнее получится.
Дело не в интерактивности, а в том кто и где будет менять этот код.
VD>Короче, все те же споры пошли по кругу. Причем один в качестве аргумента приводит довод, что неудобно в одном проекте использовать два очень близких языка (Шарпа и Немерле), а другой ратует за внесение в проект совершенно разных языков и за перенос контроля типов на рантайм.
Не надо убегать от неудобной дискуссии. И кстати это всё был я один. Я одновременно не хочу писать в одном проекте на двух близких языках и вполне готов внести встроенный скриптовой язык в проект (естественно не в любой, а там где это имеет смысл). Объясняется это очень просто. Встроенный скрипт — это не просто какой-то высокий уровень, это на самом деле мелочи (хотя я в таких случаях использую как раз самые высокоуровневые языки). Главное тут — это возможность существенного изменения поведения приложения без его перекомпиляции. Т.е. это вообще возможности из другой области.
VD>Снобизм у вас, у сиплюсплсников серьезный. Отсюда и выводы неверные. В серьезных задачах скорость достигается не за счет битовыжимательных способностей языка, а за счет грамотно организации кэшей и их инкрементальный обновлению. Важно, только чтобы отставания от битовыжимателей не было в разы. Вот именно это и происходит.
совсем не давно был конкретный простейший пример (отставание C# в 7 раз!), который никто из любителей .net'а не смог опровергнуть. Может Nemerle тут покажет класс по быстродействию? ) Если что, исходники для разных языков, а так же точные результаты измерений есть там дальше по ветке обсуждения.
Здравствуйте, alex_public, Вы писали:
_>На самом деле даже не важно имеют их аргументы смысл или нет. Важнее другое. Тут мы имеем примеры двух однозначных представителей целевой аудитории Rust, причём явно следящих за ним всё последнее время. Однако после его релиза они говорят о том, что всё же не будут его применять на практике. Т.е. значит что почему-то не зацепил в достаточной степени...
Нет, это не так. Второй просто тролль и язык его не интересовал. Первый, насколько я могу судить, человек вполне прагматичный и логично рассматривает инфраструктуру как преимущество.
Ты вообще можешь представить, что должен предлагать язык, чтобы программисты на каком-нибудь другом языке повально перебежали? Имхо, это просто нереально.
Ну и то, что язык в процессе развития несколько сменил приоритеты закономерно влечёт и то, что некоторые старые "адепты" разочаруются (и придут новые).
Здравствуйте, Геннадий Васильев, Вы писали:
ГВ>То есть в "типовых" случаях, приводиимых для иллюстрации использования DSL, сам DSL — сугубо вторичная задача по отношению к какой-то ещё, к тому, что зашифровано под буквой D — domain. И если первичная задача поставлена и так или иначе решается, то создать DSL под неё обычно не представляет большой проблемы.
Для этого требуется самая малость — возможность встраивать DSL в хост-язык, то есть поддержка Embedded DSL — EDSL.
Здравствуйте, Evgeny.Panasyuk, Вы писали:
ГВ>>То есть в "типовых" случаях, приводиимых для иллюстрации использования DSL, сам DSL — сугубо вторичная задача по отношению к какой-то ещё, к тому, что зашифровано под буквой D — domain. И если первичная задача поставлена и так или иначе решается, то создать DSL под неё обычно не представляет большой проблемы.
EP>Для этого требуется самая малость — возможность встраивать DSL в хост-язык, то есть поддержка Embedded DSL — EDSL.
Внезапно: это нужно для того, чтобы встроить DSL в хостовый язык, но никак не для того, чтобы сформулировать сам DSL. Разницу понимаешь? Утрированно, C++ вполне можно трактовать, как вариацию DSL для Java (через JNI).
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Здравствуйте, Геннадий Васильев, Вы писали:
ГВ>>>То есть в "типовых" случаях, приводиимых для иллюстрации использования DSL, сам DSL — сугубо вторичная задача по отношению к какой-то ещё, к тому, что зашифровано под буквой D — domain. И если первичная задача поставлена и так или иначе решается, то создать DSL под неё обычно не представляет большой проблемы. EP>>Для этого требуется самая малость — возможность встраивать DSL в хост-язык, то есть поддержка Embedded DSL — EDSL. ГВ>Внезапно: это нужно для того, чтобы встроить DSL в хостовый язык, но никак не для того, чтобы сформулировать сам DSL. Разницу понимаешь?
Я разницу понимаю, и очень удобно когда есть EDSL в хост-языке, за счёт тесной интеграции с остальным кодом.
Сформулировать же DSL можно хоть на бумаге — только что дальше делать-то?
Здравствуйте, DarkEld3r, Вы писали:
DE>Ты вообще можешь представить, что должен предлагать язык, чтобы программисты на каком-нибудь другом языке повально перебежали? Имхо, это просто нереально.
Нуу скажем Swift (на мой вкус вполне приятная современная штука) в сравнение с убогим Objective-C как раз предлагает такой живой пример. Хотя опять же мы и тут не наблюдаем полного мгновенного перехода, но это скорее вследствие инерции. Но в целом думаю это можно рассматривать как пример успеха.
Здравствуйте, Evgeny.Panasyuk, Вы писали:
ГВ>>>>То есть в "типовых" случаях, приводиимых для иллюстрации использования DSL, сам DSL — сугубо вторичная задача по отношению к какой-то ещё, к тому, что зашифровано под буквой D — domain. И если первичная задача поставлена и так или иначе решается, то создать DSL под неё обычно не представляет большой проблемы. EP>>>Для этого требуется самая малость — возможность встраивать DSL в хост-язык, то есть поддержка Embedded DSL — EDSL. ГВ>>Внезапно: это нужно для того, чтобы встроить DSL в хостовый язык, но никак не для того, чтобы сформулировать сам DSL. Разницу понимаешь? EP>Я разницу понимаю, и очень удобно когда есть EDSL в хост-языке, за счёт тесной интеграции с остальным кодом. EP>Сформулировать же DSL можно хоть на бумаге — только что дальше делать-то?
А это уже не проблема, а мелкие технические трудности: плюс-минус парсер и генератор. Проблема — обнаружить задачи, ради которых именно нужен DSL, как отдельная сущность. Поэтому тезис о том, что Nemerle позволяет писать встроенные DSL, звучит как попытка выпятить относительно редко используемый подход.
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
quicksort =: (($:@(<#[),(=#[),$:@(>#[)) ({~ ?@#)) ^: (1<#)
Представляю ступор этих товарищей, когда им предложат быстренько накидать свой DSL на макросах... )))
