Что круче: Лисп или Хаскелль?

> Ты тоже не в состоянии осознать, что программа на Rake является программой на Ruby?

В состоянии (а в скобках замечу, что с Руби я познакомился раньше, чем ты).

Я так понял, ваша претензия в том, что видимый синтаксис остаётся без изменений?

За этой претензией идет гораздо более глубокая - кто и как проверяет программу на DSL.

Так там и нечему изменяться: и в лиспах, и в Ruby, и в Io

Не надо Лисп сюда приплетать. Его макры работают в compile-time, умеют проверять и трансформировать код. В Руби это есть? Нет, IIRC.

> Тривиальней пример нельзя было выбрать?

Пример ведь не совсем тривиальный, правда? Попробуй написать такое на pure-'твой любимый язык'. Тривиальным его делает использование готовых библиотек. Большинство задач требует комбинации нескольких готовых библиотек с некоторым количеством собственной логики. И лучше всего для этого подходит универсальный ЯП. А использование DSL может быть оправданно только для относительного небольшого круга задач.

> замечательно конечно, вот только это не набор DSL, ты оказывается просто неуч

Аргументы кончились, переходим к прямым оскорблениям?

DROP TABLE T2

SELECT * from T1

Внезапно, drop table t2 и select all from t1 могут быть вылидным кодом, например, на Tcl. Ну синтаксис конкретного языка накладывает определённые ограничения, и что? Что это доказывает?

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

Я так понимаю, ты уже определился с тем, является ли Rake DSL-ем?

> Аргументы кончились

да - на ваши веские доводы у меня нет аргументов, разрешите откланяться

> Не надо Лисп сюда приплетать. Его макры работают в compile-time, умеют проверять и трансформировать код. В Руби это есть?

Да успокойся ты уже со своей статической типизацией и проверками в compile-time. Если 100 раз повторить один и тот же вброс, он станет очень унылым.

> И лучше всего для этого подходит универсальный ЯП. А использование DSL может быть оправданно только для относительного небольшого круга задач.

И чем более универсальными становятся универсальные ЯП, тем меньше остаётся круг для «настоящих DSL». Конфиг к программе на Tcl удобнее всего хранить на самом Tcl. А еще можно хранить разметку гуя, запросы к БД, описания парсинга аргументов командной строки, тысячи их...

можешь тоже написать вариант отрисовки PDF через DSL

PDFShow "Hello World" file.pdf

> PDFShow «Hello World» file.pdf

охуеть - множество разных DSL умеют собираться в один и совсем не надо писать код? чудеса

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

Но все-таки такой круг задач есть, да? Например, yacc отцы юникса не смогли оформить в виде библиотеки.

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

А почему одно исключает другое? Правильный DSL - это DSEL.

охуеть - множество разных DSL умеют собираться в один и совсем не надо писать код?

Почему же? Надо, конечно.

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

> Но все-таки такой круг задач есть, да?

Да, такие задачи есть.

Например, yacc отцы юникса не смогли оформить в виде библиотеки.

Отцы юникса писали на С и придумали DSL, ибо писать всё на C большой напряг. Другие люди, вместо того, что бы изобретать разные DSL, просто придумали более высокоуровневые языки программирования.

> Ты сформулируй внятно, что тебе нужно

все вроде кроме тебя поняли, geekless заявил, что библиотека == DSL, только через жопу, я предложил ему воспользоваться вместо набора библиотек набором DSL для решения конкретной задачи

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

...и пишут на них DS(E)L.

> А почему одно исключает другое?

Бритва Оккама же.

Правильный DSL - это DSEL.

Почему?

все вроде кроме тебя поняли

Ну дык объясни тупому мне, что у тебя предметная область, а что - текущая задача. Я, в отсутствие подобной информации, предположил, что предметная область - «показывать PDF-ы в окнах», а текущая задача - «показать file.pdf в окне с заголовком Hello World». Тогда программа на DSL будет выглядеть примерно так, как я тебе показал, а код для DSL-я, конечно, надо писать.

Ну, аналоги яка есть почти для всех языков, даже для высокоуровневых. http://javacc.java.net/ http://www.dabeaz.com/ply/

В принципе, дальше — больше. Объектом предметной области надо как-то еще управлять. Появляется набор функций, все это сводится в тайпклассы или обычные ООП-классы... Структура объекта предметной области может меняться, по идее, где-то нужно хранить метаданные объекта, а это уже TemplateHaskell и все-равно перекомпиляция...

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

CLOS в CL сделан как раз для решения этой проблемы. В Xerox'e совсем не дураки сидели...

Где можно почитать про CLOS не углубляясь в CL? Очень меня интересует этот момент.

Во-первых, можно невозбранно сложить 2 + 2.0 + «2» и получить 6.

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

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

Честно говоря не помню зачем это может быть нужно. Раньше точно помнил, а сейчас — забыл. Разве что плагины…

Бритва Оккама же.

Подробнее, пожалуйста.

Почему?

Ну, собственно, по той самой бритве. Язык с расширением в виде DSEL проще, чем отдельно язык и отдельно DSL.

Другое дело, что далеко не все языки дают удобные инструменты для создания хороших DSEL. Лисп в этой области покруче C, Хаскель ещё круче.

> а что - текущая задача.

есть DSL для рисования через cairo, есть DSL для работы со строками, есть DSL для работы с гуем, есть DSL для отрисовки PDF и т.д., geekless считает, что все это использовать вместе так же удобно, как и набор библиотек

>> Бритва Оккама же.

Подробнее, пожалуйста.

Зачем городить DSL, если с ним не получается лучше, чем без него?

Язык с расширением в виде DSEL проще, чем отдельно

язык и отдельно DSL.

Э, нет. Так нельзя говорить. Я как-то смотрел eDSL для генерации HTML на Haskell - выглядело впечатляюще, но только я бы таким всё равно не стал пользоваться, ибо это должно быть в отдельном DSL и в отдельных файлах.

Вообще, если предметная область стоит того, что бы городить для неё DSL, то велика вероятность, что для этой области есть предметные специалисты. И было бы хорошо, если бы они могли работать с этим DSL без надобности работать с «основным языком», ибо ведь DSL будет намного проще, чем универсальный язык + eDSL.

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

> Да успокойся ты уже

В отличие от тебя, я спокоен.

Если 100 раз повторить один и тот же вброс, он станет очень унылым.

Ну а как еще вас учить?

есть DSL для рисования через cairo, есть DSL для работы со строками, есть DSL для работы с гуем, есть DSL для отрисовки PDF и т.д., geekless считает, что все это использовать вместе так же удобно, как и набор библиотек

Ещё раз: что - предметная область, что - текущая задача?

И, кстати: DSEL - это такая навороченная библиотека.

ВНЕЗАПНО в Хаскелле исключительно форматирование структуру и формирует.

ВНЕЗАПНО читаем стандарт! Используй фигурные скобочки, Люк.

Зачем городить DSL, если с ним не получается лучше, чем без него?

Так не получается лучше.

«Делайте всё настолько проще, насколько возможно - но не проще».

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

Ну вот, сам говоришь, что нужен DSL.

Вообще, если предметная область стоит того, что бы городить для неё DSL, то велика вероятность, что для этой области есть предметные специалисты. И было бы хорошо, если бы они могли работать с этим DSL без надобности работать с «основным языком», ибо ведь DSL будет намного проще, чем универсальный язык + eDSL.

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

А потом предметному специалисту понадобится какая-нибудь мелочь, в этот DSL не входящая...

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

Нет. Только в том случае, когда DSL по тем или иным причинам нельзя удобным образом реализовать как внутренний.

> Ещё раз: что - предметная область, что - текущая задача?

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

И, кстати: DSEL - это такая навороченная библиотека.

а помидоры обычно бывают красного цвета, рад, что обменялись ценной информацией

Да что же это такое? Где уже нужно написать что «статически типизированный язык /= C или Pascal» чтобы все поняли?

Где можно почитать про CLOS не углубляясь в CL?

http://www2.parc.com/csl/groups/sda/publications/papers/Kiczales-TUT95/for-we...

Там не CLOS, но важнейшая часть CLOS-а наличествует.

Во-первых это скорее фича слабой типизации, а не демонической.

демонической.

Ну, ты понял.

есть набор разных DSL( строки, гуй, отрисовка PDF для cairo, cairo, файлы и пр. ) - воспользуйся ими, чтоб показать PDF из файла на экране,

Не понял, так это ты сам и показал, нет?

Я думал, ты хочешь узнать, как оно будет выглядеть в НАШЕМ СОБСТВЕННОМ DSL.

>> Зачем городить DSL, если с ним не получается лучше, чем без него?

Так не получается лучше.

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

Ну вот, сам говоришь, что нужен DSL.

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

А что, предметный специалист будет сильно страдать от осознания,

что DSEL, с которым он работает - на самом деле часть основного

языка?

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

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

Только в том случае, когда DSL по тем или иным причинам нельзя

удобным образом реализовать как внутренний.

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

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

Ну так это зависит от используемого основного языка.

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

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

Вообще да, иногда специалист УЖЕ привык к некоему языку, и ему будет неудобно с DSEL. В качестве примера - тот же HTML; верстальщику будет ПРОЩЕ работать с более-менее обычным HTML, чем, скажем, с Haskell-комбинаторами. И тут уже надо смотреть, что выгодней - переучить верстальщика, или делать внешний DSL, напоминающий HTML. Но таких ситуаций не так уж много.

Внутренний DSL это удар по модульности

Это ещё с чего вдруг???

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

Полноценная же работа с ЯП подразумевает не только существование компилятора/интерпретатора, но и:

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

Я не совсем понимаю, о чём говорят люди, когда говорят, что задача создания ЯП - тривиальна?

Покажите мне средство, на котором я могу тривиальным образом создавать совершенно новые языки. В лиспе я не могу решить все эти задачи тривиальным образом. Они решаются, но с существенными трудозатратами. Я думаю, что в лиспе меня спасает то, что на самом деле, такая задача почти никогда не возникает - я пишу набор макросов и вот тебе «DSL». Один раз такая задача возникла, я её решил, но назвать эту работу тривиальной у меня что-то язык не повернётся.

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

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

Намекаете на JavaScript? Да, хороший язык.

Я не совсем понимаю, о чём говорят люди, когда говорят, что задача создания ЯП - тривиальна?

Например, о DSEL-ах, где практически всё перечисленное тобой можно взять из основного языка.

я пишу набор макросов и вот тебе «DSL».

Без кавычек. Да, это лисповский способ делать DSEL. Способ довольно корявый, макросы - это тебе не first-class objects, но более-менее неплохой.

Вообще, у меня такое впечатление, что ты неправильно понимаешь, что такое DSL. Это не язык, на котором мы будем писать ВСЁ, и тем более не язык, который мы будем продавать. Это язык, на котором мы будем писать некоторую часть, помогающий основному языку, а не заменяющий его. А потому «библиотеки», «треды» и т.п. присутствуют только тогда, когда это нужно.

Намекаете на JavaScript? Да, хороший язык.

Намекаю на хаскель. В жабоскрипте как раз много всякой грязи.

> Покажите мне средство, на котором я могу тривиальным образом создавать совершенно новые языки

одни из моих знакомых в совершенно секретных условиях сейчас активно пишут такое :) кстати будет и под линукс, но правда закрытое

А пока можно посмотреть на такое:

http://www.jetbrains.com/mps/

но о тривиальности конечно речь не идет

> Интерактивность SQL хорошо стыкуется с интерактивностью среды лиспа

Имеем налицо победу динамического подхода над статическим.

при этом SQL надо отнести к статически типизированным языкам; вот как бы протекал диалог, если бы он был ДТ:

прогер: update table1 set field1=2*field1+5;

SQL: ок, хорошо... 100000 records updated... 200000... 300000...

через 5 минут:

SQL: хозяин, внезапно field1 оказалось блобом; че делать будем?

> Намекаю на хаскель

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

В жабоскрипте как раз много всякой грязи.

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

Намекаю на хаскель.

Не, Дэвид Блейн. Синтаксис Хаскеля трудно отнести к его достоинтсвам. Он несколько перегружен.

> Лисп в этой области покруче C, Хаскель ещё круче.

Толсто же. Хаскель по части написания ДСЛ от сишки-то не далеко ушел, с лиспом же это убожество даже сравнивать смешно.

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

Невозможно, потому что если мы написали ф-ю f:A->B, потом ф-ю, которая применя к этой f, то теперь мы не можем изменить тип f например на A->C - должна быть ошибка типов в этом случае. Если же можем - то у нас нарушаются инварианты и это ничем не отличается от динамический типизации.

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

но возможны варианты, когда такое прокатит, например, если С является подтипом В, или если в рамках одной транзакции по изменению кода мы меняем и функцию, которая применяется к этой f

>Где можно почитать про CLOS не углубляясь в CL? Очень меня интересует этот момент.

Я где-то натыкался на PARC'овскую книжку по OOP. Она в принципе известная. Но вот где именно - не помню.

Храни метаданные в строке, списке, словаре или ещё хрен знает в чём

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

Честно говоря не помню зачем это может быть нужно.

Например, цепочка Документ -> Платежное поручение -> конкретное платежное поручение. Документ у тебя - метакласс, который определяет логику некого абстрактного документа, Платежное поручение - класс, определяющий логику документа «платежное поручение», и соответственно, объекты этого класса.

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

в случае не встроенных типов всё будет уже не так здорово

Ну, в ООП понятие «тип» от понятия «класс» неотделимо. А с классами дело обстоит просто: мы посылаем объекту некую мессагу. Объект ответил - отлично. Объект не смог ответить - это мы можем учесть в нашей логике, например быстро и бесславно сдохнуть до тех пор, пока управление не перейдет вышестоящей сущности, которая приведет все в порядок, или не приведет. В некоторых случаях мы можем спросить у объекта, сможет ли он ответить на мессагу или нет.

В CLOS ООП сделан по-другому, но принцип остается тем же.

Нужно быть проще и люди к тебе потянуться. Всё перечисленное нужно только для широко используемого языка общего назначения. Интерпретатор C-подобного языка пишется максимум за неделю. На C++. Это исключительно личный опыт.

Он прост и естественен для большинства людей, имеющих какое-либо отношение к программированию.

Depends. Два наиболее известных DSL-я - это HTML и SQL. Каждый из них в жабоскриптовом синтаксисе будет выглядеть очень нелепо. В Хаскельном SQL можно сделать почти таким же, как есть сейчас, а HTML... ну, более-менее похожим.

Хаскель по части написания ДСЛ от сишки-то не далеко ушел, с лиспом же это убожество даже сравнивать смешно.

Не узнаю вас в гриме? Love5an?

Синтаксис Хаскеля трудно отнести к его достоинтсвам. Он несколько перегружен.

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

Хаскель по части написания ДСЛ от сишки-то не далеко ушел, с лиспом же это убожество даже сравнивать смешно.

Воистину аноним хуже...

> Два наиболее известных DSL-я - это HTML и SQL.

Э, закончили разговор, HTML это язык разметки, к DLS никаком боком отнести его нельзя.

Э, закончили разговор, HTML это язык разметки, к DLS никаком боком отнести его нельзя.

Почему это - нельзя??? Ну, не тьюринг-полный (я не учитываю веяния CSS3), ну и что? Чем он хуже вполне тьюринг-полного PostScript, который применяется примерно для того же, но при этом является диалектом Forth-а?