Forth

На ЛОРе хотя бы встречаются реальные программисты «на этих языках». В отличие от.

На ЛОРе хотя бы встречаются реальные программисты «на этих языках»

На Template Haskell?

Осторожно, вещества!

http://webreading.ru/sci_/sci_psychology/dghon-lilli-programmirovanie-i-metap...

Ну ладно, D - такая же маргинальщина, как и лиспы. Но все равно, непонятно, куда его можно употребить, авторы же говорят, что он mukti-purpose

О, слона-то я и не заметил. Не, такие не попадались вроде. :-D

Я-то по заголовку думал, что человеков метапрограммируют, а тут лиспосрач :(

+1

Без батареек нахрен не нужен.

Но все равно, непонятно, куда его можно употребить, авторы же говорят, что он mukti-purpose

Для всего, чего используется Си++. И для большей части приложений Си, относящихся к userspace (а может, и для всех таких приложений).

Ruby же.

Как сказал тов. geekless, батареек нет - значит, ни для чего. Тут на лоре один человек хотел написать на д свой революционный де, который вовсе и не де. Я до конца даже не понял. Но суть в том, что нужен был порт berkley db для чего-то. Существующий был малофункциональным и устаревшим, а новый написать он вроде так и не осилил. И т.д. Оно-то и правильно, было бы удобно писать прикладное по на Д вместо С при сравнимой скорости работы и значительно более легкой разработке, но если самому велосипедить библиотеки, добром не кончится.

Еще большая маргинальщина чем обрезки от ногтей.

Как сказал тов. geekless, батареек нет - значит, ни для чего.

Как скажешь. Мне вот интересно, зачем, например, компилятору батарейки.

Впрочем, одной из целей D является прозрачный вызов Си-кода, так что я не понял про «порт berkeley db».

если самому велосипедить библиотеки, добром не кончится

А кто должен писать библиотеки (кроме стандартной)? Заказ от ынтырпрайза, как я понимаю, не поступал.

Что не так?

Уже прочитал «что не так»... Ты упоролся. Может кому-то и не видно метасистемы в Tcl, но это только потому, что Tcl и есть сплошная метасистема. Там вообще нет ничерта кроме неё.

плюсую за D

Метапрограммирование на тикле - это изврат, тикль не проектировался для этого и не предназначен. Не спорю, что то можно соорудить по-мелочи, видел примеры в wiki.tck.tk, но никакой «развитой метасистемы» у Tcl нет.

Ричард Метьювич, перелогинтесь

Впрочем, одной из целей D является прозрачный вызов Си-кода, так что я не понял про «порт berkeley db».

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

да, некоторые едят одну перловку и обкусывают ногти — они точно на лишпе написаны^Wнаметанопрограммированы

это смайл? D

Nemerle

Уже прочитал «что не так»... Ты упоролся. Может кому-то и не видно метасистемы в Tcl, но это только потому, что Tcl и есть сплошная метасистема. Там вообще нет ничерта кроме неё.

В общем, частично беру свои слова обратно. Подход «все есть строка», subst, eval, возможность на ходу собирать из кусочков текст и на ходу его же и исполнять - это все относится к метапрограммированию и эти фичи действительно были заложены были при проектировании (cast jtootf). Благодяря этим фишкам можно слабать на скорую руку какую нить хрень, в wiki поместить (там этого добра навалом) и даже в повседневном использовании, когда нужно быстро и грязно, тоже бывает уместно. Но развитой системы метапрограммирования (как в Racket например) тут нет.

Ричард Метьювич, перелогинтесь

Ричард Метьювич яростно брызгает слюной при упоминании тикля. Я же нормально к нему отношусь и пользуюсь частенько.

«прозрачный вызов» заключается в использовании тулзы, которая на основе хедеров С генерирует код на D,

«Прозрачный вызов» заключается в том, что объектные файлы D линкуются с объектными файлами GCC.

почти под все библиотеки привязки пишутся вручную

Боюсь, ты не представляешь, что такое «писать привязки вручную»...

Прозрачный вызов" заключается в том, что объектные файлы D линкуются с объектными файлами GCC.

а... как я сразу не догадался - собираем berkeley db в кучу объектников, пишем к каждому файлу по обертке, линкуем это все - и вот она простота и прозрачность

Боюсь, ты не представляешь, что такое «писать привязки вручную»...

не бойся, все хорошо

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

ЯП с развитой метасистемой

Racket. Альтернатив, вобщем-то, пока нет.

Нормальному ЯП метасистема не нужна.

Равно как нормальному ЯП не нужна система типов, ФВП, да и вообще все конструкции кроме goto.

Интересно, а расширения GHC DataKinds, PolyKinds и TypeFamilies за метапрограммирование прокатят или еще нет?

Коненчо, нет. Они в совокупности даже с TH не дадут и 1% от выразительности метапрограммирования.

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

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

а кто назовет это «ад и погибель»

Тот просто пробовал нечто лучшее. А так - на безрыбье и рак рыба, да.

Homoiconicity? Не нужно, честно.

Практика показывает, что без Homoiconicity сложность разработки макросов возрастает на порядок. Иными словами - _практичная_ (то есть такая, которую приятно, удобно и выгодно использовать на практике, а не просто чтобы поиграться и помериться длиной члена в рамках СО) система метапрограммирования без homoiconicity невозможна.

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

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

1. Чем проще синтаксис, тем более часто применимо квазицитирование. То есть там где в лиспе я просто напишу декларативный паттерн с квазицитированием, какая-нибудь хаскиблядь будет вовсю пидорасить АСТ руками. 2. Когда квазицитирование неприменимо, то чем проще АСТ, тем проще его пидорасить руками.

М, кстати. Io Language.

Java/Groovy ?

Квазицитирование применимо к сколь угодно сложному синтаксису. AST никогда не надо пидорасить руками. Смотри на Немерле.

Препроцессоры и кодогенераторы нельзя срастить со средой исполнения.

И не надо.

Так что они заведомо проигрывают - ни дебагера нормального не сделаешь, ни средств отладки.

Чем дебагер от средств отладки отличается, и почему это «не сделаешь»? Визуальный отладчик в Antlr видел?

Тот просто пробовал нечто лучшее. А так - на безрыбье и рак рыба, да.

Назови. Только не надо про scons или cmake бухтеть, хуже этого убожества вообще ничего нет.

Ты опять выходишь на связь? Иди в своё немерле, откуда вылез.

И не надо.

То есть отладка не нужна? Ну хорошо, чо.

Чем дебагер от средств отладки отличается

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

и почему это «не сделаешь»?

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

Визуальный отладчик в Antlr видел?

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

Назови.

Любая полноценная (не препроцессор типа ANTLR или TH) система метапрограммирования. Как в лиспах, например.

Квазицитирование применимо к сколь угодно сложному синтаксису.

Это ложь.

Смотри на Немерле.

А что немерле? Смотрим на первый же пример макроса (printf какой-нибудь) и видим, как АСТ пидорасят руками. Да, как на немерле написать macro-generated macro?

Это не ты ли про макросы немерле на нульче кукарекал и вертел жопкой в ответ на любую просьбу привести хотя бы кусочек кода с использованием ПРОСТЫХ МОЩНЫХ УДОБНЫХ немерле-макросов?

[continued]

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

Любая полноценная (не препроцессор типа ANTLR или TH) система метапрограммирования. Как в лиспах, например.

Этому норкоману больше не наливать! У него уже лисп системой сборки стал.

Это ложь.

Это правда. Любой lexerless parser это умеет. Полечись.

Смотрим на первый же пример макроса (printf какой-нибудь) и видим, как АСТ пидорасят руками. Да, как на немерле написать macro-generated macro?

Не на тот немерле смотришь. Смотри на PEG.

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

Этому норкоману больше не наливать! У него уже лисп системой сборки стал.

Какая система сборки? Там же черным по белому - система метапрограммирования.

Это правда. Любой lexerless parser это умеет.

Лол, ты дебил. При чем тут парсер, если мы говорим о генерации, а не о разборе?

Не на тот немерле смотришь. Смотри на PEG.

При чем тут PEG? Давай линки на printf без дрочева АСТ и с генерацией макросов.

Как ты будешь реализовывать эффективные, компилируемые eDSL без метапрограммирования?

А много есть задач для которых могут понадобиться компилируемые eDSL? Я могу себе представить, например, встраиваемый JSON в виде ADT, интерпретируемые eDSL в виде тех же ADT (eval(your_adt_object) -> results/effects), встраиваемый компилируемый HTML в виде комбинаторов задающих способ «рендеринга» этого HTML в необходимое текстовое представление или встраиваемый компилируемый eDSL в виде тех же комбинаторов задающих способ разбора некого AST из текстового представления. Для чего может понадобиться eDSL компилируемый в сам основной язык? Регулярные выражения? Ещё что-то?

Эффективные — это когда лишние три процента времени выполнения с помощью лома и такой-то матери уменьшают до двух процентов?

Равно как нормальному ЯП не нужна система типов, ФВП, да и вообще все конструкции кроме goto.

Очень толсто.