Более лучший Лисп

А что не так с тиклем во внешности?

Я не про темы. «Не взлетел» - тормозил бы так, что ни кто в здравом уме не дождался бы загрузки. Тикль - тормоз (по сравнению с другими языками). Сервера - там это особого значения не имеет: трудно на современном железе не обогнать сеть и/или БД.

В чём вообще разница?

Не думаю, что эта дискуссия особо плодотворна.

Разница между try..finally и unwind-protect - чисто культуральная. Именно по культуральным причинам лисп непонятен. В нём почти всё названо непривычными для профессионального программиста именами. Это плохо, т.к. создаёт ненужный барьер при обучении. Кроме того, часто используемые сущности, такие, как destructuring-bind и multiple-value-bind названы слишком длинными словами, это как если бы вместо «и» всегда писать «а-также», а вместо или - «а-может-быть-и». Новый синтаксис позволяет начать с чистого листа и дать вещам нормальные имена.

Чего из этого нет?

Ничего нет. LOOP плохо поддерживается отладчиком Lispworks, например, нельзя поставить брекпойнт для пошагового исполнения в начале итерации, не меняя исходника. В этом смысле любой «быдлоязык» с IDE лучше, т.к. пошаговое исполнение бывает полезно на практике.

Синтаксис a.b не имеет смысла с точки зрения CLOS.

Не уверен, что это делает большую честь CLOS.

А ты можешь вогнать цикл while внутрь for или условный if или даже паттерн-матчинг? Нет. А вот в f# можно. For-comprehension в scala убог, и возможно, что он никогда лучше уже не станет.

А какое отличие от for в scala? Он же по типу do

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

В нём почти всё названо непривычными для профессионального программиста именами.

Не уверен, что try...finally появилось раньше чем unwind-protect. И хотя на практике это не играет никакой роли, всё-же странно переименовывать сущность потому что в каком-то другом ставшем популярным языке она названа по-другому.

Кстати, вы должны понимать часть баттхёрта коммонлисперов к clojure. Те же яйца, только:

• lambda => fn
• defun => defn
• progn => do (prog1 и prog2 нету)
• do => loop
• loop нет вообще
• let* => let (let нету)

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

</trollolo>

Ничего нет.

Самый близкий аналог for и т.д. по выразительности - do. С ним IDE дружат.

В общем, вычислительные выражения выглядят как вполне обычный код, только ты в начале самом говоришь, что все конструкции нужно пропустить через определенный функциональный преобразователь (буквально, «построитель»). Плюс есть особые конструкции для монадической стрелки (let!) и еще парочка похожих.

JVM все равно больший тормоз. Гораздо больший

shootout?

Хочу вот такое:

(defmessage (list dlist-container) 
            (:add (new-node dlist-container-node) :after node)
  ...)

в смысле с диспатчингом по ключевым параметрам

Использовать:

(@ my-list (:add item1) 
           (:add item2 :after item1) 
           (:add item3))

Кроме того, часто используемые сущности, такие, как destructuring-bind и multiple-value-bind названы слишком длинными словами

В современном коде используется

(bind (a b c) ...) или (bind (values a b) ...)

Вроде и коротко и ясно

Зачем лжешь, врунишка? JVM на порядки быстрее тикля.

А браузера для McCLIM случайно нет? :) Webkit или, хотя бы, Gecko.

http://common-lisp.net/project/closure/

http://mcclim.cliki.net/Application

Он серьёзно сравним по уровню поддержки стандартов, надёжности и быстродействию с webkit? И флеш уиеет? И на оффтопике работает? o.O

Лисперы не перестают меня удивлять.

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

Тот факт, что он требует TRIVIAL-SOCKETS как бы намекает на возраст проекта.

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

known to work in recent (July 2005) versions of SBCL

%)

Да ладно возраст, раздел News на глагне намекает на живость проекта.

Что-то он у меня не собирается. Столько окаменелостей использует. Больше ничего нет?

Поставил beirc. Теперь Tk ни по каким меркам не назовёшь страшным.

У uzbl на сайте лежало что-то для ecl.

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

Вы уже несколько раз эту мысль повторяете, но я так и не понял в чем проблема с сообществом?

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

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

Кроме того, лисперы ещё и наименее фанатичны, т.к. большая часть лисперов пишет не только на лиспе, а ещё на 2-3 языках.

С ними можно обсуждать по существу многие вопросы

Вы довольно точно диагностировали диагноз. Я понял, с лисперами отлично попить пива и порассуждать о разных, наверное интересных, вещах (компиляторы, метапрограммирование! и т.п.) Но вы не сказали ни слова про то, какой замечательный код пишут лисперы и какие замечательные программы они делают.

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

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

lisp-em? Это event-manager для uzbl.

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

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

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

Ну тут вам виднее, просто сам стандарт CL местами на те же лет 10 отстает от других языков, на мой взгляд.

сам стандарт CL местами на те же лет 10 отстает
от других языков

Например?

Опенсорсный свободный код мало чем отличается от такого
же кода на других языках

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

Работа с файловой системой, например, отсутствие в стандарте потоков, например.

отсутствие в стандарте потоков, например.

monk таким стандартом считает обёртку bordeaux-threads. Что-то мне подсказывает, что большинство тоже.

Работа с файловой системой

«If, say, versioning file systems come back into vogue, Common Lisp will be ready.» — Peter Seibel «Practical Common Lisp»

Здесь не разберёшь, толи стандарт в делёком прошлом, толи в ещё не наступившем будущем.

bind

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

Таким образом, нужно знать не CL, а множество его диалектов (по числу творческих/ленивых лисперов).

Я не вижу причины, почему в языке изначально нельзя иметь нормальные конструкции.

Самый близкий аналог for и т.д. по выразительности - do

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

профессиональных лисперов

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

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

это - не общепризнанный синтаксический сахар

То есть в C++ баним всё, кроме std::. Потому как boost::, Qt, Gtk--, ... - не общепризнанный синтаксический сахар. Тогда что останется? Потоков в C++ теперь тоже нет, файловой системы тоже :-)

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

SLIME подсвечивает, в каком аргументе находишься. Мне хватало.

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

У лиспа высокий порог входа. Соответственно, денег такой специалист хочет как 1С-ник с сертификатом 1С:Руководитель проекта. А 1С-специалист — это как VB-специалист. Каждый, кто разобрался с синтаксисом, себя таковым считает (но алгоритмы они пишут... про инварианты и область определения функции ничего не слышали).

Потоков в C++ теперь тоже нет

с разморозкой

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

Давай по конкретным примерам. Чем тебе не угодили по «уровню технологической мысли»?

https://github.com/fare/lisp-interface-library
https://github.com/edicl/hunchentoot
https://github.com/tomoyuki28jp/web4r

Можешь привести примеры из других языков, которые опережают эти «лет этак на 10».

Потоков в C++ теперь тоже нет

с разморозкой

В ISO/IEC 14882:2003 не нашёл. Скажи номер раздела. Или укажи на какой стандарт ты ссылаешься (мы же в случае CL на ANSI CL ссылаемся).

В ISO/IEC 14882:2003 не нашёл.

уже два года как новый стандарт принят

ISO/IEC 14882:2011

Можно ещё почитать историю создания стандарта и понять: второму стандарту не быть, по крайней мере в ближайшем будущем

почему это? объясни развёрнуто. рассказы автора HyperSpec / CLtL про то, как им тяжко пришлось это описывать — не в кассу.

потому что есть более адекватные примеры стандартизации более других лиспов — не стандартизация ad hoc сложившегося языка в свалку общелиспа, а разработка через тестирование стандартизацию — сначала идёт простая и непротиворечивая спецификация, потом она стандартизируется (по типу RFC), потом появляется референсная реализация по этой спецификации и стандарту.

например:

1. разработка языка схема. сначала возникли RFC, потом всякие RnRS, потом — реализации.

2. европейская и японская ветви лиспов: XLisp, LeLisp, EuLisp, T, ISO ISLISP.

стандартизация ISO ISLISP иницировалась японскими программами «компьютеров пятого поколения» и проекта TRON. (кстати, подход TRON к спецификациям и стандартизациям — тут решает).

сначала, тот же EuLisp можно считать попыткой стандартизации нестандартных лиспов, вроде T, LeLisp, прочих.

но вот ISO ISLISP демонстрирует правильный подход к стандартизации.

стандартизация ISO ISLISP организацией ISO произошла ГОРАЗДО быстрее и проще, чем ANSI CL организацией ANSI.

отсюда вывод — все эти ужосы, описанные в истории создания стандарта — это проблемы ANSI и её организации работы/патентной системы/копирастии на текст стандарта, например.

3. разработка Qi, Qi II, Shen.

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

так что, объясни развёрнуто свою позицию. хотя про фрагментацию и малость сообщества — в целом, согласен.

ISO/IEC 14882:2011

А для него существует хотя бы один компилятор? В Gcc, например, почти на всём, что стандартизовали по потокам, в статусе стоит No

А для него существует хотя бы один компилятор? В Gcc, например, почти на всём, что стандартизовали по потокам, в статусе стоит No

future, thread, mutex etc. давно (относительно) есть и работают, в том числе и для visual c++ и clang, т.е. boost уже не нужен, а то что еще не (везде) реализовали - там boost не помошник

стандартизация ISO ISLISP организацией ISO произошла ГОРАЗДО быстрее и проще, чем ANSI CL организацией ANSI.

И именно поэтому для него не найти ни одной open-source библиотеки...

разработка языка схема. сначала возникли RFC, потом всякие RnRS, потом — реализации.

И, опять же, почему не так распространена как CL? Стандарт есть, много реализаций есть, что ещё нужно?

И именно поэтому для него не найти ни одной open-source библиотеки...

оно не так уж сильно от CL отличается:

http://www.islisp.org/whatisISLisp.html

http://en.wikipedia.org/wiki/ISLISP

в основном, в реализацию уже много чего встроено (примерно так же, как в схеме).

в OpenLisp реализации весьма годная библиотека. реализация вполне годная — кроссплатформные сборки бинарей под 20 ос. единственно что смущает, что это голимая проприетарщина за какие-то огромные тыщи евро.

хотя некоторое подмножество есть в emact емаксе.

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

из примерно аналогичных islisp-у вещей, но более популярных реализаций, можно попробовать например, EuLisp

Для clang раздел concurrency тоже наполовину заполнена.

Я в том смысле, что сейчас писать по стандарту 2011 года на C++ нельзя. А то не скомпилируется. Приходится писать на том подмножестве, что реализован в конкретном компиляторе.

И опять же, это не мешает наличию и широкому использованию QThread, CreateThread, TThread, ... Можно вспомнить TString, QString, CString, ... несмотря на то, что std::string стандартизован уже очень давно.

Для clang раздел concurrency тоже наполовину заполнена.

там аналогично - thread, mutex etc. уже есть

И опять же, это не мешает наличию и широкому использованию QThread, CreateThread, TThread, ...

повторюсь - уже можно брать std::thread вместо них, то, что не реализовано из нового стандарта не решается через «QThread, CreateThread, TThread»

уже можно брать std::thread

Так и в CL можно в любой реализации брать bordeaux-threads. Фактически, такие библиотеки как metabang, iterate, closer-mop ,alexandria можно считать неким «стандартом снизу». Также, как для C никто не стандартизует readline, gettext, но используют повсеместно.

Так и в CL можно в любой реализации брать bordeaux-threads.

std::thread - это таки оф. стандарт (про bordeaux-threads не знаю)