[D-lang] Итоги и небольшой обзор о состоянии языка

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

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

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

(def-stored-proc my_proc
   :args '((id int))
   :returns '((result (varchar 1000)))
   :body (fbody
  select name from ~:(client-table-name) where id=:id into result;
  ~:($assert (fbody name is not null^)); 
^))

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

что тебе не нравится? MULTIPLE-VALUE-BIND? MAKE-STRING-OUTPUT-STREAM?

секрет раскрою, только никому не говори:

(defmacro mvb (variables values-form &body body)
 `(multiple-value-bind
    ,variables ,values-form
    ,@body))

(setf (symbol-function 'strstrm) #'make-string-output-stream)

И вообще, CL очень concise, он имеет право быть sesquipedalian

...и губозакаточную машинку

Какое нахер минимальное ядро? И велосипедить потом битовые операции на списках, или массивы, или структуры?

CL это опыт нескольких поколений инженеров. Идея «Modern Clean Lisp» ублюдско тупа в своей сути.

http://c2.com/cgi/wiki?ModernCleanLisp

Unfortunately they add other mistakes which don't make them clean or even modern. Creating a real ModernCleanLisp has been tried a few times. All failed. See: EuLisp?, ISLisp, prefix-Dylan, and some more ... If you want a modern clean Lisp you can just take EuLisp?. The definition and some implementations are there. Almost nobody uses them. So, don't hold your breath - it will not happen anytime soon. And, no, ArcLanguage isn't it. The thing is, Common Lisp and Scheme are good enough for Lisp programmers. The newer Lisps aren't getting wide acceptance and aren't getting any acceptance from non-Lisp-programmers. See ModernCleanLisp as experimental languages that will die away after some time. CommonLisp and Scheme will stay.

хахаха. доставило ;-)

Just fire up your CL and go: CL-USER 3 > (make-package «ELITE-COMMON-LISP») #<The ELITE-COMMON-LISP package, 0/16 internal, 0/16 external>

CL-USER 4 > (in-package «ELITE-COMMON-LISP») #<The ELITE-COMMON-LISP package, 0/16 internal, 0/16 external>

ELITE-COMMON-LISP 5 > (shadow 'cons) T

ELITE-COMMON-LISP 6 > (cons 'a '())

Error: Undefined operator CONS in form (CONS (QUOTE A) (QUOTE NIL)). 1 (continue) Try invoking CONS again. 2 Return some values from the form (CONS (QUOTE A) (QUOTE NIL)). 3 Try invoking something other than CONS with the same arguments. 4 Set the symbol-function of CONS to another function. 5 Set the macro-function of CONS to another function. 6 (abort) Return to level 0. 7 Return to top loop level 0.

Type :b for backtrace, :c <option number> to proceed, or :? for other options Ahhhhhhhh. That's much better. Now I can code without that d*mmed CONS operator gettin' in my way!

> concise
Мы на Русском форуме, ты не забыл?

что тебе не нравится?

Мне не нравится то, что вот это http://www.franz.com/support/documentation/current/doc/environments.htm не является стандартом. Т.е., лисповые макры на самом деле не так круты, как они должны были бы быть. Я буду рад на указание конструктивного и переносимого решения этой проблемы.

Идея «Modern Clean Lisp» ублюдско тупа в своей сути

Ты настолько часто повторяешь подобные слова, что у меня возникает три версии:
1. Ты - последователь Ла Вея.
2. Твои родители тебя воспитывали в национальном стиле, объясняя, что все «инакодругие» люди вокруг - идиоты.
3. Ты сам не очень умный и пытаешься проконвейерить слова, которые чешут твой мозг.

В общем, может быть так, что все три варианта имеют место одновременно.

defmacro mvb
ну, если уж на то пошло, то вроде как metabang-bind:bind. Но есть ещё multiple-value-list, multiple-value-setq, symbol-macrolet и т.п.

http://c2.com/cgi/wiki?ModernCleanLisp

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

> 3. Ты сам не очень умный и пытаешься проконвейерить слова, которые чешут твой мозг.
Не, это я зря сказал. Тебя долго убеждали (например, те же родители) в том, что ты сам не очень умный. Как раз с помощью таких слов. И, хотя ты сам знаешь, что ты умный, всё же хочется проконвейерить эти слова.

>Ты - последователь Ла Вея.
В некотором роде.

> ...и губозакаточную машинку
Если бы я не программировал каждый день на нереально прекрасном лиспе, я мог бы откомментировать свои пожелания точно так же. А так я вполне ясно вижу, что то, чего я хочу - вполне реализуемо. Кстати, наиболее легко этого добиться, видимо, в рамках какого-нибудь ECL, поскольку он сам генерит сишный код и умеет его компоновать к образу. Видимо, там есть необходимая инфраструктура. Хотя вроде GCL - это не шибко качественная реализация лиспа.

>В некотором роде.
Зло неизбежно, но горе тому, через кого оно приходит в этот мир.

> Если бы я не программировал каждый день на нереально прекрасном лиспе,

«Нереально прекрасный» - и при этом не «язык мечты»? Ничего себе у тебя запросы.

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

Я не высказывал своих пожеланий :)

А так я вполне ясно вижу, что то, чего я хочу - вполне реализуемо.

Как говорит мой начальник, «Запрограммировать можно всё». Но вот это:

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

и это:

- возможность работы с памятью на уровне С.

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

А в остальном, ты описал нечто близкое к Ocaml.

> а в случае питона и сам язык плохой.

Чем, кроме дурацких отступов?

Повторяю:
я мог бы откомментировать СВОИ пожелания точно так же.

ты описал нечто близкое к Ocaml.
Известные мне реализации Ocaml не являются динамическими.

> - возможность работы с памятью на уровне С.

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

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

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

Ну я прикинул - вроде вполне можно. В дополнение к обычному функционалу нужно всего лишь:
- сделать каждый указатель двунаправленным.Чтобы можно было знать не только куда он смотрит, но и откуда. Информацию «откуда» можно хранить где-то в отдельном месте в хеш-таблицах,ключём в которых является значение указателя
- иметь возможность повесить свой обработчик на создание, изменение и удаление указателя.
Это на самом деле не сложно, если это изначально заложить в дизайн языка. Сложно это сделать потом, если изначально оно не было заложено.

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

Ладно, извините, я хотел бы закрыть офтопик.

Лямбды да, отступы да, тормозной - есть немного. А с кириллицей где проблемы?

Не динамический

Ыыыы! «Зло»?

> Известные мне реализации Ocaml не являются динамическими.

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

- возможность работы с памятью на уровне С.

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

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

Причем тут FFI? Он везде есть.

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

Что значит «откуда»?

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

Хотя для таких целей может хватить и Boehm GC, Страуструп смотрит на тебя с пониманием.

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

Что значит «откуда»?

К каждому объекту приделать массив указателей на указатели на него?

>Если бы это сделали, это был бы точно «хит сезона».

если только для вас, для большинства это просто не нужно. принципиальных преимуществ(помимо компиляции в натив, да и это решается) перед C#/Java+(groovy/scala/clojure) для большинства не будет.

>Да, и справедливости ради я бы отметил, что «динамический и высокоуровневый язык» показывает хорошую скорость только при _максимальной_ типизации всего и вся.
Не всего, в основном только ключевых моментов. В SBCL/CMUCL у Python(компилятор внутри них так называется, еще раз, и появился он раньше одноименного языка) очень хороший механизм type propagation.

>>Ты - последователь Ла Вея.

В некотором роде.

Это клиника.

«В некотором роде», для тупых, значит - пентаграммы не ношу, блэкмитол не слушаю, сотоной, магией и прочей хуйней не интересуюсь, и т.п., переболел лет в 14-15.
Однако, в общем разделяю взгляды на жизнь.
какие - вот тут можно почитать, к примеру
http://ru.wikipedia.org/wiki/%D0%A1%D0%B0%D1%82%D0%B0%D0%BD%D0%B8%D0%B7%D0%BC...

Та... разница медлу Ла Веевским сатанизмом и Ницшей только в том, что у первых куча дурных пафосных заморочек с Сатаной и прочей АТМТОЙ.

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

Javascript

BASIC

+inf. Почему-то практически все ЛаВеисты отличаются непробиваемой ограниченностью.

> К каждому объекту приделать массив указателей на указатели на него?
Ну, не к каждому. Например, ограничить указатель размером в N-2 бита, где N-разрядность машины. В одном из двух оставшихся бит разместить факт наличия таблицы «обратных указателей». Сами указатели хранятся во внешней хеш-таблице. Однако, нужны они будут только если на этапе компиляции не удалось доказать благонадёжность этого указателя.

магией и ... не интересуюсь

Странно, не получилось ничего, что ли? Или лукавишь?

Я пока не очень хорошо знаю Ocaml, но загружаемые модули там точно есть, и доступные для модификации глобальные таблицы функций тоже

Было бы интересно получить опровержение моего утверждения. Мы проверяли в своё время, может быть, просто что-то не то делали. Повторюсь, есть функция a, и b, которая вызывает a. При перекомпиляции b в лиспе, как правило, a начинает вызывать новое тело b. То же, например, в MS SQL. Как в Firebird - я до сих пор не понимаю, похоже, что ответ - «иногда». Но в Firebird IBExpert позволяет автоматически пересобрать всё, что зависит. В Питоне и Окамле - нет. Кроме того, в лиспе и в MS SQL можно поменять также сигнатуру функции. Например, убрать обязательный параметр. При этом, попытка вызова со старым набором параметров вызовет вменяемую ошибку выполнения. Вот это я называю динамической средой исполнения, и на меньшее я согласился бы с большим трудом.

Javascript в известных мне реализациях по скорости принципиально не отличается от Python и иже с ним. Кроме того, он ограничен по библиотечным средствам.

Тьфу! Ошибся! Есть A. Есть B. A вызывает B. При перекомпиляции B, A начинает вызывать новое тело B.

community.livejournal.com/ru_lisp

Как я вижу, люди, знакомые с D дали нужные ответы. Хотелось бы только добавить что я не хотел обидеть кого-либо, кто уберждён что использует лучший на свете язык.
Статус D действительно не так радует как хочется, но меня удивляет как люди могут говорить что у языка, который находится в таком состоянии, не будущего. Видимо, не каждый может понять как рождаются языки и как родили их любимые языки. Ну да ладно.
На счёт GC: судя по референсам, можно управлять всем чем угодно.
Функционал «искаропки» можно исследовать по данной ссылке: http://digitalmars.com/d/2.0/phobos/phobos.html
Пока, в D2.0 есть только Phobos, т.е. нет необходимости путаться.
DMD работает стабильно и выводит нормальные комментарии на ошибки.
Сейчас я занимаюсь изучением синтаксиса и семантики D2.0. Некоторые интересные моменты(в первую очередь - то чего нет в Си) выписываю тезисами в твиттер http://twitter.com/iorlasd
Думаю, некоторым будет интересно иногда почитывать.

- простой язык. Что-нибудь типа оберона, хотя настолько просто не получится, придётся несколько сложнее

http://fantom.org Ы?

Может, Dylan?

>Видимо, не каждый может понять как рождаются языки и как родили их любимые языки.

дело не в этом, если честно. Vala моложе D, даже еще 1.0 версии нет, но будущее Vala вырисовывается гораздо ярче.

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

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

хм, ну вот посмотрел «альтернативу» - mbase 3-й беты. Вроде тот-же лисп, но из-за краткости синтаксиса это начинает смахивать на старый write-only перл :(

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

Черт. А ведь через какое-то время так будут говорить про Си!

Увы, я знаю только одного человека(лично), который бы хоть немного выделял Vala. Однако и тот не шибко её выделяет как язык, который сможет найти свою нишу.
У Ди есть задача, для которой он создавался - заменить Си и С++. Чем не задача? Да, сложно. Да, не верится что linux могут переписать на D.
Но я то к чему, люди говорят так, как-будто C и CPP будут вечны и ничто не придёт им на замену. Они об этом плачутся, но и сами же пытаются похоронить попытки сделать такую замену.
Замена - большее чем было. Это так, уточняю для любителей придираться к словам.
Судя по вашему посту, вы не в курсе что такое D и зачем он. Вот это просто обижает меня и других «проповедников» D. Нет, правда. Просто обидно что люди не читают то что пишешь ты и другие.
Не в обиду сказано.

давай без «вы».. тем более мы с тобой, вроде-как, примерно одного возраста.

Увы, я знаю только одного человека(лично), который бы хоть немного выделял Vala. Однако и тот не шибко её выделяет как язык, который сможет найти свою нишу.

Человек неправильный :) Vala создавался не просто так, а как специализированный язык для Gnome, он очень хорошо вписывается в инфраструктуру GObject и очень удобен для разработки под Gnome. Vala уже нашел свою нишу, большего от него никто не ждал. Часть гнома, написанная на Vala будет расти в геометрической прогрессии.

Но я то к чему, люди говорят так, как-будто C и CPP будут вечны и ничто не придёт им на замену.

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

На С++ тоже написано уже огромное количество кода, так что в какое-либо обозримое время от него отказаться не получится.. хотя кто-знает.

Вот на замену C# он вполне может встать.. но и тут большой вопрос.

Судя по вашему посту, вы не в курсе что такое D и зачем он. Вот это просто обижает меня и других «проповедников» D. Нет, правда.

Не отрицаю.. Но пока попытки разобраться ни к чему не приводят.. Кроме как к осознанию того, что D - это эдакая интересная игрушка.

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

Ну, скажем, Vault - шаг в правильном направлении.

> Ну, скажем, Vault - шаг в правильном направлении.

К нему доки где-то есть?

> ...и губозакаточную машинку

вроде как единственное, с чем я там не согласен — макросы не нужны, а нужна partial evaluation

ну и всякие динамические фенечки нужны (не всем, а гурманам) не для релиза, а для отладочного билда

и наконец нынешнее состояние CS похоже вполне позволяет сделать такое

«динамическими фенечками» я назвал например возможность замены функции в рантайме на функцию с несовместимой сигнатурой

а вообще подозреваю, что это игрушка и потеря времени программиста

но не вижу проблем *заранее* в языке предусмотреть возможность сделать такое — фактически 1 лишнюю индирекцию, искорее наборот, где-нить *по делу* может потребоваться такое, а оно уже есть.

Если я правильно понимаю, только на архиве осталось: http://web.archive.org/web/20080219014100/http://research.microsoft.com/vault/

>давай без «вы».. тем более мы с тобой, вроде-как, примерно одного возраста.
Я не против. Привычка - с незнакомыми людьми, к которым нет отвращения, обращаться на «вы».

Vala уже нашел свою нишу

Это не ниша, а так, ячейка. Если вала не уйдёт сильно дальше внутреннего использования в гноме - фейл.

не придет

Ну что ты так то? =/ Разве тебя устраивают C и CPP? Меня нет. Увы, альтернатив не было, пришлось писать на этих языках. Сейчас я вижу что есть альтернатива, которая стоит того чтобы перейти на неё. Плюсов уйма. Только ленивый или лиспер не увидит их.

Вот на замену C# он вполне может встать.. но и тут большой вопрос.

C#? Ты точно что-то перепутал. Почитай о Ди.

хотя кто-знает.

Напомню что код на C легко можно использовать в Ди. По сему если и делать переход, то он будет без особых проблем.

> http://web.archive.org/web/20080219014100/http://research.microsoft.com/vault/

Какая-то странная муть.

>вроде как единственное, с чем я там не согласен — макросы не нужны, а нужна partial evaluation
Ты наркоман?

«самолеты не нужны, а нужны стиральные машины»

«самолеты не нужны, а нужны стиральные машины»

Луговский в своё время обронил фразу - «частичное применение функций эквивалентно метапрограммированию».

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

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