Создатель Python разочарован в Scala

> Произведением квадратных матриц A и B (размером n) назовём 
> квадратную матрицу P размера n, такую что элемент Pij равен сумме 
> произведений Aik * Bkj, k пробегает диапазон от 1 до n, для любых 
> i, j от 1 до n. Вычислить матрицу P.

> Псевдокод (считаем, что матрицы аллокированы, и матрица p 
> предварительно обнулена):

> for (i = 0; i < n; i++)
> for (j = 0; j < n; j++)
> for (k = 0; k < n; k++)
> p[i][j] += a[i][k] * b[k][j];

Лисповый вариант не слишком будет отличаться от вашего "алгоритмического" языка:

(loop for i from 0 below n
   do (loop for k from 0 below n
	 for aik = (aref a i k)
	 do (loop for j from 0 below n
	       do (incf (aref p i j) (* aik (aref b k j))))))

Более того, "человеческих" слов здесь больше, чем у вас в си-подобном псевдокоде.

> Вы уверены, что готовы к этому? Я готов. Приоткрою завесу. В реальной задаче (прототипом которой является подсчёт отклонений) присутствуют декодирование/декомпрессия данных, распараллеливание расчётов на кластере, специализированный GUI, использующий OpenGL, работа с SQL СУБД, веб-интерфейс, интеграция CORBA.

Ну а чем напугать-то хотели? GUI? GL? SQL? WEB? CORBA?

> Читайте внимательнее, это был псевдокод.

Где взять псевдокомпилятор? В смысле - что должен проиллюстрировать этот псевдокод?

>Английский.

Почему не японский?

> Область применения программирования - это не только математика

А само программирование - это не арифметика.

>К сожалению, класс задач, хорошо формализуемый на функциональном языке, крайне узок.

Еще один необоснованный стереотип.

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

Покажите мне _хоть одну_ задачу формализованную в терминах ООП.

>(Заметьте, никто не отрицает математической и логической строгости этой парадигмы.)

Ага - особенно глядя как F# появился в MSVS, а в С# появились лямбды, в жабе изобретают их же, а в с++ пишут костыли в бусте. Чего уж тут отрицать.

>В однострочности и небольшой глубине дерева разбора.

И что?

>Для самого DSL тоже нужен профайлер, потому что, профилируя хост-язык, Вы не сможете понять, какой области DSL (scope вызова + параметры + переменные + ...) соответствует найденный bottleneck.

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

>...и всем надмножеством этого класса.

Каким подмножеством? Снятием статистики с большего и меньшего куска памяти? Кто-то тут говорил что-то о примитивности?

Добавлю. Прямо скажем, читаемость кода на Си оставляет желать лучшего. Но человек со стороны, особенно математик, разберётся в нём без проблем. Разве что синтаксис for(;;) может вызвать временные затруднения.

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

К слову, человечество не стоит на месте в плане придумывания языков, всё более и более удобных для решения математических задач. Я имею в виду, конечно же, Fortress - совершенно революционную инициативу от Sun, где стираются грани между математической нотацией и собственно кодом программы.

Но это ещё дальше от Лисп.

P. S. Кстати, за Fortress стоит Guy Steele, человек, вклад которого в Scheme сложно недооценить. Вряд ли бы он инициировал разработку Fortress, если бы Scheme всех и вся устраивала бы полностью.

> Понятное дело, что человек чаще объясняет, как надо сделать, а не что надо сделать. Но компьютеры - не человеки. Они умеют только сложить и в регистр покласть.

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

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

(require 'lisp-matrix)

...

(m* a b)

>Ну а чем напугать-то хотели? GUI? GL? SQL? WEB? CORBA?

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

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

- С и ассемблеры микроконтроллеров для обработки данных (DSP);
- C, C++, Fortran и специализированные пакеты (плюс MPI) для расчётов;
- Python для GUI;
- Java для реализации middle-tier (СУБД и CORBA).

У Вас есть шанс доказать, что Лисп готов в одиночку переплюнуть все вышеописанные языки и технологии. Не упускайте его. :)

using namespace boost::numeric::ublas;
...
p = a * b;

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

Засим откланиваюсь.

Кстати, из ветки "Знатокам лисп (2)" поступили хорошие новости. "Знатоки" после длительных мучений родили-таки пригодное решение. Рекомендую ознакомиться с их мытарствами: http://www.linux.org.ru/view-message.jsp?msgid=3277883

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

> Но компьютеры - не человеки. 

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

>ни умеют только сложить и в регистр покласть

Это на С.

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

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

>Очередная придирка будет рассмотрена как отказ привести 
соответствующую реализацию на Лисп.

Фига се придирка. Половины кода нету.

Вот на скале:

object Matrix {
  def matrix(a: Array[Array[Int]], b: Array[Array[Int]], n: Int)(i: Int, j: Int) =
    (0 to (n - 1)).foldLeft(0)((s: Int, k: Int) => s + a(i)(k) * b(k)(j))

  def main(args: Array[String]) = {
    val a = Array(Array(1, 2), Array(3, 4));
    val b = Array(Array(6, 7), Array(8, 9));
    val r = matrix(a, b, 2) _
    println(r(0, 0))
    println(r(1, 1))
  }
}

Если вы поймете чем это конкретно отлично от вашего вы поймете чего вы в С лишены.

> Кстати, из ветки "Знатокам лисп (2)" поступили хорошие новости. "Знатоки" после длительных мучений родили-таки пригодное решение

В этой ветке практически такое же решение, если вы лисповый код не понимаете :)

>Если бы программа на DSL состояла хотя бы из десятка строчек, Вам рано или поздно стало бы интересно, в какой из этих строчек произошёл ексепшен.

Ты не понимаешь сущности DSL'ов. Ты думаешь, что DSL что-то типа ява-скрипта в браузере или встроенного языка 1С. Но это все языки общего назначения.

DSL он либо кодогенератор, причем обычно исходного кода т.е. комбинирует различные примитивные конструкции языка общего назначения. Либо язык системной интеграции, т.е. связывает компоненты, написанные на языке общего назначения.

И в первом и во втором случае все уже отлажено и оттестировано. Где здесь нужен дебаггер/профайлер?

Хорошо, организовать дебаггер DSL'а достаточно сложно, я согласен. Хотя, например, в яве и для того и для другого есть целая инфраструктура, а для "графики" есть Eclipse.

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

>>Если бы программа на DSL состояла хотя бы из десятка строчек, Вам рано или поздно стало бы интересно, в какой из этих строчек произошёл ексепшен.

>Ты не понимаешь сущности DSL'ов.

Ты по человечески скажи - на DSL программы из 10 строчек не пишутся? Они все настольо мощны, что любая задача укладывается в 9 и менее строк? :D

> Ты думаешь, что DSL что-то типа ява-скрипта в браузере или встроенного языка 1С.

Пошла телепатия...

> Но это все языки общего назначения.

Язык 1С - общего назначения O_o Приведешь пример чего-нибудь, написанного на этом языке, кроме приблуд для 1С?

> DSL он либо кодогенератор, причем обычно исходного кода

Ну то есть профилировка/отладка предлагается на уровне сгенерированного кода, вроде как 30 лет назад программы на ЯВУ отлаживались на уровне ассемблера. И прежде чем ты скажешь, что DSL не нужна отладка - DSL бывают не только декларативные.

А в чём состоит изначальная задача-то, по которой нужно соревноваться?

Топик "Знатокам лиспа" (без "(2)").

>O_o Приведешь пример чего-нибудь

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

С DSL'ом такое невозможно принципиально: он заточен под конкретную предметную область.

>Ну то есть профилировка/отладка предлагается на уровне сгенерированного кода

А отладка она всегда на уровне сгенерированного кода. И тот факт, что дебаггер тебе показывает типа твой исходный текст этого факта не меняет. Другой вопрос как сделать, чтобы дебаггер тебе показвал типа исходный код на твоем DSL. Это несколько сложнее и в случае DSL -> Целевой язык -> Машинный код не осуществимо. А вот в случае DSL -> Целевой язык -> Байт-код очень даже можно. Было бы желание.

Но мне всегда процесс отладки представлялся в виде процесса получения информации о причинах, которые вызвали ту или иную ошибку. Чем тебя не устраивает дамп работы программы?

И попробуй привести пример DSL'а, которому нужна символьная отладка.

> Другой вопрос как сделать, чтобы дебаггер тебе показвал типа исходный код на твоем DSL. Это несколько сложнее и в случае DSL -> Целевой язык -> Машинный код не осуществимо.

Не надо ля-ля. Очень даже осуществимо. Если, например, целевой язык Цэ, то у него есть #line. Это в тупейшем случае. Можно сколь угодно сложную дебажную информацию протаскивать через цепочку промежуточных языков.

> А вот в случае DSL -> Целевой язык -> Байт-код очень даже можно

Ну это вообще тривиально, особенно в .NET.

> Но мне всегда процесс отладки представлялся в виде процесса получения информации о причинах, которые вызвали ту или иную ошибку.

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

> И попробуй привести пример DSL'а, которому нужна символьная отладка.

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

> DSL он либо кодогенератор, причем обычно исходного кода т.е. комбинирует различные примитивные конструкции языка общего назначения.

Часто анализировать этот самый исходный код просто нереально. Попробуй подебажить код на Си, сделанный таким DSL, как Bison. :)

> И в первом и во втором случае все уже отлажено и оттестировано.

Сам кодогенератор тоже отлаживать надо, однако. И пользователь должен иметь возможность дебажить свой код, не зная вообще ничего о том, как кодогенератор работает - иначе в DSL и смысла то никакого нет.

> Где здесь нужен дебаггер/профайлер?

Увы, везде. Особенно профайлер - очень легко в кодогенераторе ошибиться и сделать очень неэффективный код.

>> O_o Приведешь пример чего-нибудь

> С примерами затрудняюсь

Ну тогда и не швыряйся терминами.

> С DSL'ом такое невозможно принципиально: он заточен под конкретную предметную область.

У тебя какое-то узкое определение DSL. Что мешает ему быть Тьюринг-полным? Что мешает ему иметь достаточно широкий Domain?

<софистика> Вообще-то все (даже универсальные) языки являются DSL (их domain - программирование :)). Ну а уж ассемблеры - по определению DSL, ибо их domain - одна архитектура. </софистика>

> отладка она всегда на уровне сгенерированного кода. И тот факт, что дебаггер тебе показывает типа твой исходный текст этого факта не меняет.

Ой, правда? А почему именно сгенерированного кода, а не вентилей или электрических сигналов?

> Но мне всегда процесс отладки представлялся в виде процесса получения информации о причинах, которые вызвали ту или иную ошибку.

Яволь.

> Чем тебя не устраивает дамп работы программы?

Это противопоставление ножа и мясорубки. Я могу обойтись без отладчика, не вопрос. Но я могу его эффективно использовать, когда он есть.

> И попробуй привести пример DSL'а, которому нужна символьная отладка.

Ну я бы привел в пример XSLT, но придет Ява-джедай r и скажет, что ему отладчик не нужен, хотя он пишет такой сложный XSL, какой только 1 из 20 прогеров пишут :) Или SQL дебаггер, но тоже найдется кто-нибудь, кому он не нужен. Да возьми любой известный DSL и вбей в гугле "XXX debugger" - для половины из них что-нибудь найдется.

Но вообще-то я не хотел флеймить об отладчиках. Мне хотелось услышать что-нибудь вроде: "да, для DSL нет отладчика/профайлера, но высокоуровневость DSL всё равно дает выигрыш; если вам приходится писать на DSL большую программу, вы неправильно его спроектировали;". В общем, что-то конкретное от людей с большим опытом DSLстроения :)

Народ ждет Pivo взамест Java - виртуальную машину на Питоне!

> Народ ждет Pivo взамест Java - виртуальную машину на Питоне!

Нет уж лучше пусть остается жаба, чем эта убойная смесь уайтспейса и бейсика (ц)

Глупый пингвин (Тук) робко прячет тело жирное в утесах Только смелый Гвидо Россум реет молнии подобный Он кричит и птицы слышат Пусть скорее будет "Pivo"... et cetera

Кто бодяжит под Виндой ТОт по жизни лох тупой И уже от страшных глюков Дохнут стаи жирных Туков Выйдет в поле Индиана Вынет что-то из кармана Будет резать будет бить Пора на ОпенСолярис - переходить. АС Пушкин

Кстати о бабочках: На базе жвм (JVM) появился новый язык Скала ( Scala ) и фреймворк под названием Лифт ( Lift ) на скалу. Прикольно!

А жвм это что-то типо ЖЗЛ (жизнь замечательных людей) или жзя ( ... языков программирования ) хотя скорее просто - шизя

Во, давайте я тоже пофлеймлю. 

Я считаю, что лисп - это великолепная платформа (правда, немало
изуродованная кривой стандартизацией). Дизайн, позволяющий 
компилировать каждую отдельную функцию не выходя из программы и 
притом в нативный код, defmacro, eval-when, подобие объекта, 
пропущенного через (read (print x)), объекту x для встроенных и 
пользовательских объектов - всё это - прекрасные и уникальные вещи. 

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

Простые задачи писать не лиспе неудобно. Да, где-то можно с помощью 
DSL сделать из 10 строк 1000. Но DSL не покрывают всех случаев. В 
итоге, всё равно DSL будет генерить только треть кода, остальные две 
трети придётся писать вручную. Именно поэтому лисп - среды, которые я 
видел, настолько убоги - просто на лиспе неудобно программировать. 

Итак, чего не хватает лиспу. Тупо нужно больше разных скобок. Ответ о 
том, что "можно определить любые скобки в своём DSL" - не катит. Есть 
такой общеупотребимый "DSL", состоящий из основных конструкций языка, 
таких как переменные, условные конструкции, операции со строками и 
т.п. Кому-то может казаться, что складывать строки с помощью 
concatenate 'string или format nil "~A~A - это нормально. Но я думаю, 
что это _не_ нормально. Наверное, во время создания лиспа никто не 
думал, что он будет использоваться для бухгалтерских программ или для 
генерации веба. Поэтому операции со строками просто не казались 
нужными. Но пришли другие времена. Да. Тупо не хватает тех 
преимуществ, которые даёт статическая типизация. Я говорю не о 
скорости. Я говорю именно о выразительности языка. 

(defstruct foo bar)
(foo-bar (make-foo) - foo повторяется здесь два раза. Это плохо и 
современные языки от этого давно избавились. Аналогичную проблему мы 
имеем в CLOS

(defclass foo () (bar)) 

мы будем вынуждены обращаться к слоту по долгому имени
(defclass foo () ((bar :accessor bar^)))

мы испортили глобальное пространство имён и породили generic function 
там, где в C и Java её нет. 

Синтаксис struct.field, который есть в С и во всех нормальных языках, 
отсутствует в лиспе и это плохо. 

a.b.c = (с^ (b^ a)) 

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

Да, читать a[b] - это много приятнее, чем (elt a b) или (gethash a 
b). Но такой синтаксис нельзя сделать в лиспе, не поменяв лисп до 
неузнаваемости. Нельзя даже сделать, чтобы [a b] означало разное в 
засимости от типа a - при этом мы вносим полиморфизм и теряем 
скорость. 

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

Ещё одна проблема - вложенность. 
(flet (...) (let (...) (macrolet (...) ...))) - вот эти три 
закрывающие скобки - это плохо, они не 
нужны ни для чего. Нечитаемо и непонятно. В реальности никто никогда 
не считает эти скобки, а пользуется редактором и смотрит на отступы. 
Но эти отступы на самом деле тоже вряд ли полезны, т.к. человек будет 
смотреть сначала на строки (что находится под чем), а потом уже на 
глубину отступа. Я вот недавно написал макрос proga, который 
позволяет писать так:
(proga
 (flet foo (arg) (list arg))
 (let bar (foo 1))
 (macrolet a-foo (foo bar))
 (cons a-foo bar) 
 )

И это - ИМХО более читаемо, чем

(flet ((foo (arg) (list arg))))
 (let ((bar (foo 1)))
  (macrolet ((a-foo (foo-bar)))
   (cons a-foo bar))))

Я экономлю по 4 скобки и по одному уровню вложенности для каждого 
одиночного let, flet минус две скобки и один уровень отступа для всей 
конструкции. Конкретно в этом примере, я сэкономил 
10 скобок и два уровня отступа. 

Но если я сейчас пойду на comp.lang.lisp и начну рекламировать этот 
макрос, меня смешают с говном Ъ лисперы. "Parens aren't there"

Фактически, из-за плохого синтаксиса и лёгкости создания макросов, с 
языком и случился распад на диалекты. Похоже, что он всё же рано или 
поздно загнётся. Ситуация тут совершенно фатальная - лисперы считают 
что всё нормально. Кроме того, по моим наблюдениям, лисперы, которые 
вынуждены противостоять тяжелым жизненным обстоятельствам (трудность 
применнеия лиспа, обусловленная социальными факторами и потрясающее 
убожество всех остальных языков) весьма индивидуалистичны (а большие 
проекты не пишутся в одиночку), не особо коммуникабельны и 
преисполнены снобизма. Например, на comp.lang.lisp они не радуются 
новичкам, а утюжат их, не понимая, что в сообществе - сила. Всё это 
не способствует расширению области применения лиспа.

Какова мораль - те, кто уже знает лисп, будут продолжать его 
использовать для прототипов и в каком-то узком диапазоне проектов, но 
в итоге, другие языки всё равно съедят лисп. Сто тысяч 
Ява-программистов всё равно напишут больше полезного людям кода, чем 
4000 лисперов, даже если каждый лиспер будет в 10 раз более 
продуктивен. Ну и понятно, что для любого работодателя лучше 
использовать Яву, чем Лисп. Даже если сам этот работодатель - лиспер. 

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

+0.9

Сам написал или скопипастил?

Lisp это просто Zope в руках неудачников прошу прощения за мой Пондос вичер уж если окончательно подвести черту и под жвм и под обсуждением клуба любителей Монти Пайтона вышла Кложа ( Clojure ) язык типа лисп на JVm

> Мне хотелось услышать что-нибудь вроде: "да, для DSL нет отладчика/профайлера, но высокоуровневость DSL всё равно дает выигрыш; если вам приходится писать на DSL большую программу, вы неправильно его спроектировали;". В общем, что-то конкретное от людей с большим опытом DSLстроения :)

На DSLах, бывает, пишутся ну очень большие програмы. Например, если это DSL описания баз знаний, и на нём пара гигабайт этих самых знаний понаписана.

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

Ну раз уж все молчат, добавлю есть очень миленький флейм Protege, он изначально был предназначен для Лиспа, но сейчас пишется на Яве. Его задача - создание онтологий, классификаторов и т.д. 4 версия работает с OWL ну чем не основа для дружбы народов (тем более как я слышал она идет из Стенфорда, где до последних лет работал создатель Лиспа, а пользуются ей почему-то наши госорганы в своих секретных фичах) (я вам ничего не говорил! тссс)

>У тебя какое-то узкое определение DSL.

Это у тебя оно какое-то широкое. Все очень просто: если ты думаешь как тебе адаптировать уже существующий язык к предметной области - это не DSL.

Взять тот же SQL (который не PL/SQL). Да, SQL - DSL. Но к твоей-ли предметной области? Нет. Проблемы своей предметной области ты решаешь с помощью различных обвязок, или OR-мапперов, промежуточных моделей и т.п.

А возьми, например HQL (Hibernate Query Language), хоть на выходе у него и SQL, решает он совсем другие проблемы. Правда тоже не ТВОИ. Да в какой-то мере он позволяет манипулировать объектной моделью... Но главным образом он управляет тем, что и как брать из базы.

А теперь возьмем DSL, который определяет каким образом будет создавататься объекты бизнес-логики, например "ВЫБРАТЬ ПЛАТЕЖКИ СОКРАЩЕННОГО ФОРМАТА ЗА XX.XX.XXXX ОТ ФИРМЫ "РОГА И КОПЫТА"". Вот это уже "твой" DSL, он решает ТВОИ проблемы, потому что только ты знаешь что такое "платежки" и "сокращенного формата".

И если нужен тебе отладчик или профайлер - делай. Благо что на JVM, что на CLI это делается легко. Но наличие отладчика/профайлера это уже ТВОИ проблемы.

DSL не нужен, когда у тебя сидит сотня индусов. Он даже вреден. Может получится так, на надцатом витке "спирали" DSL станет тормозом развития продукта, потому что 5 лет назад была допущена незначительная ошибка проектирования...

Короче запарился я :) VSL этого обьяснить не смог, и ушел. А я уж мне и подавно.

Кстати к Бизонщикам это тоже относится. см Протеже (Protege )

protégé - это клево! это как Pivo только с_раками

> А скрипач, который тут на лисп гонит, просто свистит

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

Возможно, в ближайшее время я к тебе обращусь. Лисперы нужны (только не Common Lisp, увы).

А свистит скрипач тут о другом - о том, что якобы есть трудности с дебагом написанных на Лиспе DSLей. Это откровенная ложь, никаких трудностей нет. Дебаг рулил, рулит и будет рулить.

>Ты не понимаешь сущности DSL'ов. Ты думаешь, что DSL что-то типа ява-скрипта в браузере или встроенного языка 1С. Но это все языки общего назначения.

неа. Для "общего назначения" они недостаточно универсальны.

>DSL он либо кодогенератор, причем обычно исходного кода т.е. комбинирует различные примитивные конструкции языка общего назначения. Либо язык системной интеграции, т.е. связывает компоненты, написанные на языке общего назначения.

и js в Mozilla/XUL, и 1Cscript в bkend.dll это как раз языки "системной интеграции". Где система -- это платформа на XPCOM или C++, предоставляющая интерфейсы к объектам внутри платформы в "скрипты".

> И в первом и во втором случае все уже отлажено и оттестировано. Где здесь нужен дебаггер/профайлер?

ну например в XUL нужен дебаггер если chrome:// где-то глючит. С другим примером то же самое: оно транслирует внутренний "язык запросов" или ОО систему в SQL, и если этот SQL получается неэффективный (из-за недорасставленных индексов, например), сторонним логированием SQL и всякими припарками вокруг ч0рного ящика "платформы" можно понять, как план этих запросов улучшить

> Мне хотелось услышать что-нибудь вроде: "да, для DSL нет отладчика/профайлера, но высокоуровневость DSL всё равно дает выигрыш; если вам приходится писать на DSL большую программу, вы неправильно его спроектировали;"

это тогда недоDSL, embedded DSL. Фактически просто навороченный кодогенератор. А если сделать в смысле Language Workbench (у Фаулера), то будет там и отладчик, и интеграция, и профилировщик.

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

любые? драйвера можно? :)

вот в том же 1цент своего даже sqrt встроенного нет. Хотя можно подключить сторонний COM-объект.

> С DSL'ом такое невозможно принципиально: он заточен под конкретную предметную область

в том же 1С: есть язык запросов, калька SQL на русском языке, который в отличие от стд. SQL (ну не считая оракловского разве) понимает итоги по иерархиям, аггрегатные операции (правда, не все), вхождение в подмножество. Это как раз DSL. Cам скрипт тоже DSL: проецируются объекты предметной области на объекты "платформы", правда ООП в духе Visual Basic'а, и проблемы с многопоточностью/реентерабельностью (попробуй запустить два отладчика одновременно, например). Тоже DSL, правда, убогий и не расширяемый. В общем, я бы назвал интеграционные языки тоже DSL, правда совсем убогими и ограниченными. Но, например, смоллток как расширяемая система или лисп -- более удобные DSL, саморасширяемые, эволюционные системы.

> Язык 1С - общего назначения O_o Приведешь пример чего-нибудь, написанного на этом языке, кроме приблуд для 1С?

есть шахматы, в 2003 году кто-то писал. На простых блицах обыгрывает недоКМС-а.

> А теперь не могли бы Вы в ответ привести пример такого же уровня, но написанный на Лисп? Позволю себе ответить за Вас: "нет, не могли бы", потому что на Лисп почему-то до сих пор не написано СУБД, по своим качествам приближающихся к PostgreSQL.

1. сам постгресс
2. дофига ООБД, например, AllegroCache и тп.

> Возможно, в ближайшее время я к тебе обращусь. Лисперы нужны (только не Common Lisp, увы).

Хм, это интересно, а что за лисп?

Меня, если что, можно найти через comp.lang.lisp, я называюсь budden или что-то в этом роде.

>> Где компиляторы распространённых языков, написанные на Лисп?
>Транслятор самого распростанённого в мире языка (VB6), переводящий его в VB.NET, написан на Лиспе.

а верификатор подписываемых драйверов на корректность написан на Окамле, ну и что? но компиляторы действительно есть.

> То есть такое выражение на псевдоязыке: "let P(i,j) = sum (by k=1..n) of A(i,k)*B(k,j), where i,j=1..n" будет по всем параметрам более читаемым, чем аналог на Лиспе. (Кстати, приведите его.)

(mydsl-eval (let P ( i j) = sum (by k = 1 .. n) of A ( i j) * B (k j) where (i j) = 1 .. n))

сильно непонятней стало? ну запятые можно добавить по вкусу
или сверху парсер написать, который то выражение переведет в s-выражения (примеры таких языков см. в MBase)

> Вы уверены, что готовы к этому? Я готов. Приоткрою завесу. В реальной задаче (прототипом которой является подсчёт отклонений) присутствуют декодирование/декомпрессия данных, распараллеливание расчётов на кластере, специализированный GUI, использующий OpenGL, работа с SQL СУБД, веб-интерфейс, интеграция CORBA.

в примерах к MBase есть dotNET-язык, шейдеры и OpenGL в DSL на лиспе. Посмотри там, на что это может быть похоже.

>Ты по человечески скажи - на DSL программы из 10 строчек не пишутся?

Ты давно отлаживал программы из 10 строк? DSL обучно пишут для того чтобы дебаггером не пользоваться. Человеку который пишет на DSL не нужен дебаггер - если дошло до этого - это очень фиговый DSL.

То есть может и существуют в природе DSL где без дебаггера никуда - но из этого не проистекает что написание DSL связано с написанием дебаггера - и раз нет дебаггера - значит DSL гавно.

> А теперь не могли бы Вы в ответ привести пример такого же уровня, но написанный на Лисп?
> Позволю себе ответить за Вас: "нет, не могли бы", потому что на Лисп почему-то до сих пор не написано СУБД, по своим качествам приближающихся к PostgreSQL.

см. http://www.software-lab.de/radical.pdf http://www.software-lab.de/dbui.html http://www.prodevtips.com/tag/lisp/

http://www.software-lab.de/app.html#minAppRef

"An introduction to writing browser-based applications in Pico Lisp, using the XHTML/CSS
GUI-Framework, can be found in the "Pico Lisp Application Development" tutorial. In the last section, it describes a minimal but quite complete Application. ERP in 700 lines! :-)"

>А теперь попробуйте догадаться почему.

потому что полноценные РСУБД нафиг не нужны для мини-задачи, где хватает мини-ООБД.
Вот r говорит, не нужен полноценный 4GL, и всё тут. Можно сразу из базы брать и в XSLT заворачивать. А я говорю -- нужен для формализации метаданных и представления онтологии предметной области, хоть какой-то огрызок в виде ORM. Тот самый "интеграционный язык предметной области". А если он расширяемый, а не ограниченный, то тут и по полноценного DSL недалеко.

> То есть может и существуют в природе DSL где без дебаггера никуда - но из этого не проистекает что написание DSL связано с написанием дебаггера - и раз нет дебаггера - значит DSL гавно.

из этого проистекает, что если вдруг в твоём DSL будут ошибки (а они будут, если это не 10 строк) -- ты не будешь знать, где они, и как их исправить

Ну, это как бы не совсем лисп. Это встраиваемый в Лисп C#, но с синтаксисом S-выражений (и соответственно его может генерить более высокоуровневый код на Лиспе).

OpenGL непосредственно из Лиспа тоже дёргать можно, например в Bigloo (только биндинги старые, без напильника не собираются). И это даже вполне эффективно, не хуже Си.

>из этого проистекает, что если вдруг в твоём DSL будут ошибки (а они будут, если это не 10 строк) -- ты не будешь знать, где они, и как их исправить

Ну да - если пошагового дебаггера нет - ошибки исправить нельзя. Новое слово в программировании.