Неосилятор ищет язык.

> DSL решает не задачи предметной области, он решает каким образом создавать решения задач предметной области.

Именно по этому в 0,99 случаях он не нужен. Нужен не инструмент для создания решений, а одно частное решение.

под любым нетривильным DSL и лежит библиотека

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

> Именно по этому в 0,99 случаях он не нужен. Нужен не инструмент для создания решений, а одно частное решение.

но это же круто, а еще DSL имеет непосредственное отношение к CL, а это круто вдвойне

DSL имеет непосредственное отношение к CL

какое, кстати?

>> КРуто! А структура какой будет иметь вид - списка, или как в С? А данные в массиве ка лежат - по указетлям, или непосредственно как в C?

нет, не списка, по указателям, в CL все-таки динамическая типизация и как следствие — гетерогенные вектора

Необязательно. В SBCL если при создании массива указать тип, приводящийся к одному из стандартных машинных, получится массив, в котором данные лежат подряд. (make-array length :element-type 'double-float) вернёт полный аналог double*, применив немного магии из него можно даже вытащить собственно указатель и отправить в сишную библиотеку через FFI.

С точки зрения числодробления основная проблема CL (точнее, SBCL ибо это наиболее продвинутая реализация из тех, с которыми мне приходилось работать), это то, что там нет способа избавиться от преобразования результатов toplevel функций в лисповый объект. Это особенно начинает сказываться когда идёт работа с голыми числами: каждый раз, когда надо вернуть double-float, приходится выделять место в памяти и возвращать указатель на него вместо обычной передачи через стек как в C (flet, labels и входные параметры, вроде, можно заоптимизировать). Выхода два: описывать все вычисления через макросы, разворачивающиеся в итоге в простыню кода без или почти без вызовов нелокальных функций (так делает swizard по ссылке от yoghurt) или писать ядро вычислений на C, а в CL выносить логику верхнего уровня. К примеру, если задача формулируется в терминах векторного счисления, сложение векторов и умножений матриц можно взять из GSL, а то, как надо складывать векторы и умножать матрицы, описывать уже на лиспе. Результат получается весьма неплохой и по скорости, и по выразительности.

> К примеру, если задача формулируется в терминах векторного счисления, сложение векторов и умножений матриц можно взять из GSL, а то, как надо складывать векторы и умножать матрицы, описывать уже на лиспе. Результат получается весьма неплохой и по скорости, и по выразительности.

Слава ЛММ, что FFI есть не только в CL. Таким сценарием пользуются в большинстве высокоуровневых ЯП. Так что адептам CL остается усиленно онанировать на макросы.

>возвращать указатель на него вместо обычной передачи через стек как в C
Говоришь компилятору DYNAMIC-EXTENT, и все передается через стек.
То есть, через указатели, конечно, но место на стеке выделяется.

Хотя вообще, это смешно, насчет стека рассуждать. Нормальные GC и так работают как стек - для выделения памяти надо только указатель инкрементировать.

Все эти «высокоуровневые языки» и близко не подходят по возможностям оптимизации к коммонлиспу.

Хватит писать хуйню, если не имеешь представления о предмете.

Вот посмотри: http://love5an.livejournal.com/357147.html

Вот это операция сложения векторов произвольной длины, состоящих из 32битных интов, на SBCL/x86:

; disassembly for ADD-INT-VECTORS
; 243F0CD8:       850500000021     TEST EAX, [#x21000000]     ; no-arg-parsing entry point
;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;; Размеры массивов хранятся в виде fixnum. 
;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;    "-3" это "стирание" метки типа массива, 
;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;      т.е. превращение тегированного указателя в обычный(метка типа массива - 0b111), 
;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;        и одновременно добавление к указателю 4. 
;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;    Т.е. реально данные лежат в (указатель_на_вектор + 8) 
;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;    А в (указатель_на_вектор + 4) лежит длина вектора.
;      CDE:       8B42FD           MOV EAX, [EDX-3] ;; EDX == v1
;      CE1:       8B4FFD           MOV ECX, [EDI-3] ;; EDI == v2
;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;; Вычисление минимальной длины:
;      CE4:       39C8             CMP EAX, ECX
;      CE6:       7F26             JNLE L3
;      CE8:       8BC8             MOV ECX, EAX ;;; ECX - минимальная из длин векторов
;      CEA: L0:   31C0             XOR EAX, EAX ;;; EAX - счетчик цикла
;      CEC:       EB11             JMP L2
;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;; Цикл:
;      CEE: L1:   8B740701         MOV ESI, [EDI+EAX+1] ;; вытаскиваем число из вектора v1
;      CF2:       8B5C0201         MOV EBX, [EDX+EAX+1] ;; вытаскиваем число из v2
;      CF6:       01F3             ADD EBX, ESI ;; суммируем
;      CF8:       895C0201         MOV [EDX+EAX+1], EBX ;; складываем результат в v1
;      CFC:       83C004           ADD EAX, 4 ;; инкремент. 4(0b100) - число 1 в виде fixnum
;      CFF: L2:   850500000021     TEST EAX, [#x21000000]
;      D05:       39C8             CMP EAX, ECX ;; проверяем, надо ли заканчивать цикл
;      D07:       7CE5             JL L1
;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;; Возврат из функции. Восстановление предыдущего фрейма, и т.д.
;      D09:       8BE5             MOV ESP, EBP
;      D0B:       F8               CLC
;      D0C:       5D               POP EBP
;      D0D:       C3               RET ;; возвращаемое значение - в EDX, он же - первый аргумент, v1
;      D0E: L3:   EBDA             JMP L0

На SBCL/x64 можно прикрутить(и более того - прикручено, правда в стандартном комплекте только для скаляров, но компилятор можно модифицировать в рантайме) SSE для векторных вычислений.

Вообще, вот пример inline-ассемблера SBCL, проверка наличия SSE по CPUID: http://love5an.livejournal.com/355007.html

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

Например: https://github.com/Lovesan/virgil

Вот например библиотеки, основанные на нем:

• https://github.com/Lovesan/doors
• https://github.com/Lovesan/LDX

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

• вот примеры непосредственно из кода библиотек, приведенных выше:
  • http://love5an.livejournal.com/363892.html
  • https://github.com/Lovesan/doors/blob/master/ui/window-classes.lisp

Ну и опять таки - все упирается в квалификацию разработчика.

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

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

ИМНО чем плох DSL:

1) под каждую задачу свой синтаксис, их надо помнить. Скажем я юзаю C++, питон, bash, gnuplot эпизодически maxima. Синтаксис bash ориентирован на мин. нажатие кнопок, к нему вопросов нет. Но ептить - если б синтаксис gnuplot и maxima (типа ориентированный на свои задачи) был питоновский, жить было бы куда проще! Да, были бы какие то излишества, но было бы единообразие и ошибок было бы много меньше.

2) Этот DSL надо сделать. Сейчас мне ничего не надо делать - есть класс С++, я им рулю из питона, все просто и естественно. Есть траблы с привязкой к bash (разбор опций командной строки) - ну тут да, фактичски я делаю на основе интроспекции bash-ориентированный DSL. Но можно и exec-ом обойтись, хотя тут синтаксис уже не тот будет...

Ведь чем хорош скриптовый ЯП - ты его можешь вообще не знать, ну будешь тока переменные присваивать, остальные конструкции не мешают. Понадобилось что то бол. экзотическое - выучил скажем for и if. Конечно, не получится такого синтаксического сахара - вот у меня строка, первым идет имя переменной, потом опционально через собаку ее имя для представления в LaTeX, потом опционально ее тип и через двоеточие значение, потом опционально через тире комментарий... а оно правда так надо, что бы это все писать-парится, а потом какой нить гений скажет - не, не через собаку а через процент а собаку мы заюзаем для обозначения логина?;-)

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

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

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

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

Когда у тебя реалтайм-рендеринг в 3D, а параметры в сишные функции надо постоянно маршалить, понимаешь, что это нихрена не глупо, и питоновский стиль «накатали абы как, всюду строки» не прокатывает.

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

И потом, Вы таки лукавите (ну или не Вы а Ваши предшественники по треду) - сказали бы CL+C - я бы поверил без вопросов. А то я тож могу сказать что питон самый быстрый для числодробления, потому что у меня пускач и кодогенратор на питоне, а то что я плюсовый код дальше собираю как бы и не важно...

> 1) под каждую задачу свой синтаксис, их надо помнить.

Ведь чем хорош скриптовый ЯП - ты его можешь вообще не знать,

Взаимоисключающие параграфы с бредовым тезисом о возможности незнания «скриптовых ЯП»

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

Естественно много. Например, в реалтайм 3D-рендеринге - каждый фрейм огромная куча вызовов графического api через сишный интерфейс.
Да зачем даже про рейлтайм 3D говорить - вот если мы пишем свой гуи-фреймворк с нуля, используя только системные библиотеки - тут тоже важна скорость маршилинга.

Не важна его скорость только во всяких мелких гуевых/веб мордах к бд.

CL+C

Для того, чтобы писать эффективный код на CL, никакие си не нужны. Они только питону и прочим скриптовым недоязыкам нужны. Я выше привел пример - какой машинный код генерирует SBCL. Упомянул, что к нему можно прикрутить SSE, опять же. Зачем SBCL'ю Си «для ускорения»?

brainfuck же.

> 2) Этот DSL надо сделать. Сейчас мне ничего не надо делать - есть класс С++,

У вас классы на С++ сами по себе рожаются?

Выводы на уровне детского засада «сейчас мне ничего не надо делать, поэтому остальное - говно» можете оставить при себе, они не имеют какой-либо ценности (очевидно, что привычные/уже сделанные вещи требует меньше затрат на реализацию/вообще ничего не требуют на реализацию)

> Наск я помню, анус со ртом в процессе эволюции менялся несколько раз

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

> У вас классы на С++ сами по себе рожаются?

Я их пишу, и у меня это не вызывает никаких затруднений.

Выводы на уровне детского засада «сейчас мне ничего не надо делать, поэтому остальное - говно»

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

> Для того, чтобы писать эффективный код на CL, никакие си не нужны. Они только питону и прочим скриптовым недоязыкам нужны. Я выше привел пример - какой машинный код генерирует SBCL. Упомянул, что к нему можно прикрутить SSE, опять же. Зачем SBCL'ю Си «для ускорения»?

http://www.linux.org.ru/forum/development/6008391/page3#comment-6011828 Ваш пост? «В них, для маршалинга данных в Си» - Си первым сказали Вы а не я, я Вас за язык не тянул.

http://yandex.by/yandsearch?text=анус рот эволюция&rdrnd=823179&lr=29633

напр вот

http://www.studumka.com/kl/blastuly/evolyutsiya-ontogeneza.html

> Я их пишу

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

Я таких выводов не делал, это Вы че та маханули...

Вот ваши слова:

> 2) Этот DSL надо сделать. Сейчас мне ничего не надо делать - есть класс С++, я им рулю из питона, все просто и естественно.

К чему это всё? Да, если что-то есть - то это есть и не нужно это реализовать. Согласен. Если что-то привычное - то оно привычное, и требует меньше затрат на использование/примение.

Я сказал что мне для моих задач оно не нужно, я сказал почему не нужно

Потому что 1) «непривычно» 2) уже всё реализованно? Мм, это прописные истины. На стадии #2 менять реализацию - высшая степень идиотизма. Я не понял, что же вы пытались донести.

И мне не нравится Ваш тон.

Перегнул, прощу прощения.

>«В них, для маршалинга данных в Си» - Си первым сказали Вы а не я, я Вас за язык не тянул.

Системные API предоставляют сишный интерфейс. Поэтому нам и нужен маршалинг в Си и обратно. Рантайм лиспа не в вакууме работает. При чем тут скорость работы вообще?

Рот — это «вход» системы пищеварения и им останется. Это определение. С#ать через рот просто невозможно — это противоречит определению.

> Системные API предоставляют сишный интерфейс.Поэтому нам и нужен маршалинг в Си и обратно. Рантайм лиспа не в вакууме работает. При чем тут скорость работы вообще?

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

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

Перегнул, прощу прощения.

Принято ;-)

> Рот — это «вход» системы пищеварения и им останется. Это определение. С#ать через рот просто невозможно — это противоречит определению.

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

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

> Есть ли такой язык в котором нету низкоуровневой мороки а только функции и переменные?

QBasic :)

А так — http://balancer.ru/tech/forum/2010/11/t73381--programirovanie-graficheskikh-p...

Блять. Я вообще с идиотами не люблю разговаривать, но, ладно.

Давай, покажи, где в питоне «модуль», предоставляющий интерфейс к виндовому DXGI? D3D11(_нормальный_, эквивалентный нативному, а не как DirectPython11, который говно)?
Или, я не знаю, вообще, двусторонний интерфейс к COM(причем не через IDispatch, как в говне типа PyWin32, или как его там, а чтобы нормальные интерфейсы с табличками виртуальных методов, и чтобы оно к GC было прикручено)?

Это распространенная ошибка любителей скриптовых языков - накатали им в стандартной библиотеке полтора модуля на полтора системных вызова линуксов, и они думаю, у них все интерфейсы всех систем так скрыты.

SQL-запросы писал?
И что, не обосрался?

А ведь SQL это самый яркий пример DSL вообще.

Ок, наверное убедили.

Только поменьше экспрессии - столь эмоциональный стиль изложения мешает воспринимать Ваши аргументы, серьезно.

> столь эмоциональный стиль изложения мешает воспринимать

Ваши аргументы

это же love5an, он по другому не умеет.

;      CFF: L2:   850500000021     TEST EAX, [#x21000000]
;      D05:       39C8             CMP EAX, ECX ;; проверяем, надо ли заканчивать цикл

Знатный говнокодец генерируют эти ваши лиспы, TEST EAX, [#x21000000] - пустая интсрукция, результат ее не используется, причем она со следующей cmp спариться не может потому что один и тот же регистр используют.

Лавсанчик, хватит уже форсить свое кривое никому не нужное говно.

у меня там 8 фоловеров уже на doors, и 4 на LDX, и это учитывая что разработка еще только-только началась.

А вот где твой код? Или это ты как раз у нас клепаешь никому, строго говоря, не нужное говно, в стиле «бд->html», и поэтому проецируешь?

знатное говнецо у тебя голове, чудила

>Вот мне посоветовал знакомый javascript, это так?

Он не подумал.

> К примеру, если задача формулируется в терминах векторного счисления, сложение векторов и умножений матриц можно взять из GSL, а то, как надо складывать векторы и умножать матрицы, описывать уже на лиспе. Результат получается весьма неплохой и по скорости, и по выразительности.

Как в NumPy

> Все эти «высокоуровневые языки» и близко не подходят по возможностям оптимизации к коммонлиспу.

Да-да, на шутаут-то давно заглядывал? :)

http://shootout.alioth.debian.org/u32/which-programming-languages-are-fastest...

Чёрт возьми! Какие-то хацкели, клины, скалы, сишарпы и луы делают божественный коммон лисп. Это заговор против CL, никак иначе.

> Это заговор против CL, никак иначе.

Вообще, там CL демонстрирует просто отличные результаты, если адекватно оценивать, конечно.

> Похоже, vslдрочеры не знают, что DSL - это одна из базовых идей Unix

Статья-то не про DSL'и как таковые, а про конкретный подход к их реализации.

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

Я же проверяю на практике, и результатами доволен.

Неужели тебе так трудно признать, что любимый sbcl вовсе не вершина эволюции?

>Пробовал в С++ , но не осилил наследование, классы... буэ неужели просто функций и переменных мало?

да ты и прямь неосилятор!

P.S По теме - Qt

P.P.S. Если совсем туго, то - VB... но я этого не говорил...

Не вершина уж точно, есть куда расти.
Но уж на порядок лучше чем все то дерьмо, которое остальное.

И. Для CL возможности оптимизации продолжаются там, где для говноязыков типа C# и C++ они заканчиваются.

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

Wolfram Mathematica однозначно. То, что ты хочешь, делается там в одну строку.

Какой такой в дупу unix? DSL это одна из базовых идей науки вообще. Вся математика это одна большая куча из dsl-ов, построенных под задачи физики, экономики, сопромата и прочего.