Лисп в промышленной разработке

Фи, какой вы тут срач из ничего развели. Вот я пишу мелкие велосипедики на Common LISP и запускаю в CLISP. Писать прикладные велосипедики на тех же плюсах - самоубийство. На отладку плюсокода уходит слишком много времени. Плюсы хорошо пользовать, если в проекте есть гуй на кутях. Для остальных задач существуют остальные языки. ^_^

> Для остальных задач существуют остальные языки. ^_^

а можно узнать из какого браузера ты это написал?

>На отладку плюсокода уходит слишком много времени

Пишу на плюсах, какой кнопкой в иде врубается отладчик давно забыл. ЧЯДНТ?

>LISP
Рука тянется к топору.

Я отвечу на этот вопрос, как только это будет иметь хоть какое-то отношение к дискуссии.

Наверное, ты забыл, что код надо компилить и потом ещё и запускать. :D

> Я отвечу на этот вопрос, как только это будет иметь хоть какое-то отношение к дискуссии.

а это имеет прямое отношение - если вы пишете из под браузера, написанного на С++( все нормальные ), то лицемерно заявлять, что вам С++ не нужен

НИНАДА!!1 Не отрубай себе руку! Я всё прощу! :D

> а это имеет прямое отношение - если вы пишете из под браузера, написанного на С++( все нормальные ), то лицемерно заявлять, что вам С++ не нужен

Ну кто ж заявлял что C++ не нужен? У меня несчастная Opera. Но это не значит, что я сейчас же брошусь кодить на плюсах. Плюсы хороши. И ЦЛ хорошо. Просто для каждой задачи своё. Если я пишу консольный быдлокод, то лучше буду писать его в каком-нибудь CLISP или SBCL ибо REPL.

> Плюсы хороши. И ЦЛ хорошо. Просто для каждой задачи своё

согласен

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

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

>C++ не нужен, а браузеры на нем потому, что у них огромная кодовая база, которой лет 15

Детачка, я немного испоганю твой розовый уютненький мирок: все пишется на C, C++ или .NET, потому что только эти платформы предоставляют полный доступ ко всем необходимым возможностям окружения. Если ты возьмешься писать браузер на лисп, ты потратишь первые пару лет только на написание биндингов ко всяким libpng/libjpeg/libxslt/xcb/gtk или qt и прочему. А к тому времени, как ты родишь все эти биндинги, библиотечки обновятся, совместимость сломается и все пойдет кувырком.

Есть языки (или правильнее сказать платформы?) первого класса и есть остальная шваль. В первому классу относятся C (и C++ в силу обратной совместимости), Java и .NET. Все остальное навешивает биндинги на эту великолепную тройку.

> Если ты возьмешься писать браузер на лисп, ты потратишь первые пару

лет только на написание биндингов ко всяким

libpng/libjpeg/libxslt/xcb/gtk

или qt и прочему. А к тому времени, как ты родишь все эти биндинги,

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

Ваша способность игнорировать реальность просто поражает.

> Ваша способность игнорировать реальность просто поражает.

покажите мне правильную обертку для cairo, пожалуйста ( и ФФ и хром ее используют ), потому-что я нашел только две «дохлых» + одну живую, но которая еще не готова( и не факт, что будет )

Деточка у тебя в штанах.

.NET, кстати, да и жаба, к «возможностям окружения» предоставляют доступ совершенно аналогично лиспу(FFI). В дотнете, кстати, вообще стдлиба убогая совершенно.

Есть языки (или правильнее сказать платформы?) первого класса и есть остальная шваль. В первому классу относятся C (и C++ в силу обратной совместимости), Java и .NET. Все остальное навешивает биндинги на эту великолепную тройку.

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

> покажите мне правильную обертку для cairo

про 1.9.14 я уже даже не мечтаю, давайте хоть для 1.8.10

> покажите мне правильную обертку для cairo

Мне cairo не нужна, поэтому просто не в курсе. Но чем ситуация с CL в данном случае отличается ситуации с тем же Python и другими динамическими языками? GTK+ специально делают так, что бы максимально упростить биндинг ко множеству языков. А вот использование C++ с GTK+ выглядит как историческое недоразумение.

> А вот использование C++ с GTK+ выглядит как историческое недоразумение.

если вы про cairo - то это независимая библиотека, у которой есть возможность работать как с Qt, так и с GTK

> если вы про cairo - то это независимая библиотека

Спасибо, я знаю.

у которой есть возможность работать как с Qt, так и с GTK

И?

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

> Использовать C-библиотеки из CL обычно (за небольшими исключениями) проще, чем из C++. Сейчас в пользу C++ относительно cairo говорит только то, что для него уже имеется качественная обёртка. Но это всего лишь вопрос времени и потребности.

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

> у меня сложилось впечатление что в CL все так - есть масса мертвых

оберток, за которыми никто не следит

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

Глянь на sourceforge, там тот же cliki, даже хуже.

>.NET, кстати, да и жаба, к «возможностям окружения» предоставляют доступ совершенно аналогично лиспу(FFI).

Действительно, закроем глаза на то, что их стандартные библиотеки покрывают 95% возможностей операционной системы и почти 100% потребностей прикладного программирования. Зато в лисп у нас есть FFI, над которым можно навесить макросов и сделать свой убогенький заводик по производству велосипедов.

>А это вообще везде так, не только в CL. А впечатление, скорей всего, связано с отвратным состоянием cliki.net, в которой каждый «студент» может оставить запись о своём проекте.

Ок, давай по существу: хочу работающую лисповую библиотеку для xmpp. Требуется: поддержка TLS или SSL, умение работать с srv-записями. cl-xmpp не умеет SRV, а также глючит, бажит и не работает с TLS. Под C (соответственно, и под плюсы), есть не одна _работающая_ библиотека. Для CL — ни одной.

> Ок, давай по существу: хочу работающую лисповую библиотеку

для xmpp.

Давай по другому, хочу нормальную библиотеку для работы с XML (уж это поважней будет, чем xmpp) в С++, так, что бы была поддержка XPath и XSLT и простой способ писать свои расширения для этих вещей. Но такой просто нет (Xerces/Xalan не предлагать). И нормального биндинга к libxml2 тоже в природе нет, есть несколько неполноценных уродцев.

В CL же есть полноценное решение на базе CXML, а также мой биндниг cl-libxml2. Я кстати писал его после того, как патчил для своих нужд xmlwrapp (которая одна имеет нормальный дизайн, но сильно недопилена) и на фоне этого был сильно впечатлён насколько из CL проще работать с C-либами, чем из C++. Реально, написать биндинг к libxml2 для CL гораздо проще, чем для C++.

А вот все твои рассуждения выше - это просто домыслы, не соответствующие реальной практике.

> А вот все твои рассуждения выше - это просто домыслы, не соответствующие реальной практике.

То есть для XMPP предлагается юзать Си-библиотеку?

> То есть для XMPP предлагается юзать Си-библиотеку?

Моя фраза была не про это. Касательно же XMPP, предлагается юазть cl-xmpp (http://common-lisp.net/project/cl-xmpp/) и если вдруг она по каким-то причинам не работает - патчить.

>Давай по другому

Итак, с xmpp в лиспе работать нельзя. Я так понимаю, у лисперов фамильная черта не отвечать на неугодные вопросы?

хочу нормальную библиотеку для работы с XML

http://www.xmlsoft.org Не поверишь, даже биндинги не нужны, ибо плюсы обратно совместимы с сями. Хотя если хочется, то http://ftp.gnome.org/pub/GNOME/sources/libxml++/

В CL же есть полноценное решение на базе CXML

Recent changes: rel-2008-11-30

Поциент скорее мертв, чем жив.

также мой биндниг cl-libxml2

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

на фоне этого был сильно впечатлён насколько из CL проще работать с C-либами, чем из C++.

С тем, что из лиспового FFI реально удобно обращаться к нативному коду по сравнению с перлом, питоном и даже Lua абсолютно согласен. Там без свига ручками неприкольно. А чем в лиспе лучше, чем из плюсовки-то? Можно поподробнне осветить эту сторону вопроса?

>Касательно же XMPP, предлагается юазть cl-xmpp

Оно не собирается при включенном TLS на clisp'е. В общем, как я помню, к gmail'овскому аккаунту из нее мне подключиться так и не удалось.

Кстати, давай продолжим специальную олимпиаду: как у нас с HTTP в CL? Меня смущает, что drakma последний раз обновлялась в 2008, а cl-curl аж в 2007.

Об асинхронном http клиенте, поддерживающем несколько параллельных запросов (вроде того, что встроен в libevent) я и мечтать не смею.

> С тем, что из лиспового FFI реально удобно обращаться к нативному коду по сравнению с перлом, питоном и даже Lua абсолютно согласен. Там без свига ручками неприкольно.

Что за «сдвиг ручками» в Питоне?

>Что за «сдвиг ручками» в Питоне?

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

> Чтобы общаться с питоном (и остальными упомянутыми языками), нужно либо ручками писать враппер в сишном коде, либо заюзать swig, который сделает это за тебя.

А... это было давно и неправда.

В CL же ты в лисповом коде просто пишешь прототип фнукции, описываешь структуры данных и получаешь профит на выходе.

В Питоне уже несколько лет, с появления ctypes, примерно так же («примерно» - потому что я не знаю точно, как оно в CL).

> Итак, с xmpp в лиспе работать нельзя. Я так понимаю, у лисперов

фамильная черта не отвечать на неугодные вопросы?

Я не работаю с xmpp, поэтому не могу ответить на данный вопрос. Это так сложно понять?

http://www.xmlsoft.org Не поверишь, даже биндинги не нужны,

ибо плюсы обратно совместимы с сями

Не поверю, ибо очень хорошо знаю что это такое и написал много кода с этой с использованием этой либы (на С++). По дизайну libxml2 такое уродство, что пихать его прямиком в плюсовый код я бы ни в коем случае не стал - баги потом замучаешься выгребать. Хотя если вы готовы непосредственно юзать таким образом, то это сразу объясняет вашу позицию. Что бы понять, что такое хороший биндинг к libxml2 посмотрите, например, на lxml (http://codespeak.net/lxml/).

Хотя если хочется, то http://ftp.gnome.org/pub/GNOME/sources/libxml++/

Гы, это одна из тех либ, про которые я говорил выше как неполноценных уродцев. Вы что, посты не читаете? Ещё раз - ни одного вменяемого биндинга к libxml2 для C++ нет.

Recent changes: rel-2008-11-30

Поциент скорее мертв, чем жив.

Издеваетесь? Посмотрите когда было последнее стоящее изменение в libxml2.

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

не было, пришлось клепать велосипед.

Угу, только этот велосипед имеет непосредственную поддержку не только DOM, но и XPath, XSLT, HTML, а также простую возможность писать расширения для XPath (функций) и XSLT (элементов) непосредственно на CL, чего нет ни в одном из «невелосипедных» биндингов к libxml2 для C++.

А чем в лиспе лучше, чем из плюсовки-то?

cl-libxml2 это плод работы одного человека в течении 2 недель, плюс потом мелкая подчиска багов. Над биндингами к libxml2 для С++ работало гораздо больше народа и гораздо больше, но что-то ничего вменяемого родить они не смогли. Всё дело в том, что есть REPL и можно экспериментировать, фактически с С-кодом, прямо в нём.

>Гы, это одна из тех либ, про которые я говорил выше как неполноценных уродцев.

Какие-то более конкретные указания на неполноценность _официального_ биндинга будут? Или опять общие фразы?

Напоминаю, что неполноценность — это отсутствие какой-либо функциональности в биндинге. Субъективную неэстетичность называть неполноценностью неправильно.

cl-libxml2 это плод работы одного человека в течении 2 недель, плюс потом мелкая подчиска багов.

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

Всё дело в том, что есть REPL и можно экспериментировать, фактически с С-кодом, прямо в нём.

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

> Напоминаю, что неполноценность — это отсутствие какой-либо

функциональности в биндинге.

Я же уже сказал несколько раз: поддержка XPath, XSLT, невалидирующего HTML-парсера, расширений к XPath и XSLT. Этого нет ни в одном плюсовом биндинге. Вы что не читаете? Или термины не знакомы?

вот и пришлось самому вместо непосредственной разработки продукта

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

Не так ли?

Можете считать это такой чертой характера, склонность писать open source. Мне просто нравится писать код и я его пишу. Это плохо? Кто-то ведь пишет код и на С++, а вы на нём просто паразитируете?

а в C++ можно использовать сишный код безо всяких REPL

Гы. Вы пробовали сколько-нибудь серьёзно работать с той же libxml2? У этой либы нет нормальной документации, а то что есть местами просто не верна - обнаружил это когда писал cl-libxml2. Эту либу просто нельзя нормально понять без чтения исходного кода. И поэтому очень нужен REPL, что бы понять как ведёт себя библиотека и убедиться в правильном понимании. Только не надо говорить, что все либы на С/С++ имеют замечательную доку и разобраться в них не составляет никакого труда - это совсем не так.

и промежуточных FFI, которые могут привносить свои багоглюки.

Не сталкивался. О чём речь? Если бы с FFI были проблемы, то ничего бы в CL вообще не работало бы, ибо с ОС ведь надо взаимодействовать в любом случае.

>Я же уже сказал несколько раз: поддержка XPath, XSLT, невалидирующего HTML-парсера, расширений к XPath и XSLT. Этого нет ни в одном плюсовом биндинге. Вы что не читаете? Или термины не знакомы?

А ты вообще знаешь, что XPath — часть libxml2 и в официальном полном биндинге поддержка XPath имеет место быть. Если ты не можешь понять, что значит каталог examples/dom_xpath, то я тут бессилен.

Вы пробовали сколько-нибудь серьёзно работать с той же libxml2?

Работал. Документация могла бы быть и лучше (применимо практически к любому опенсорсу). Однако даже документация к libxml2 полнее, чем к cl-libxml2. А поскольку авторы осознавали, что написать полноценный мануал им не под силу, они родили директорию examples, где все освещено.

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

Я обычно предпочитаю examples.

Так что там с HTTP в CL?

> А ты вообще знаешь, что XPath — часть libxml2

Прекрасно знаю. Я же писал к ней биндинг. К.О. в недоумении.

в официальном полном биндинге поддержка XPath имеет место быть

Хм, когда она была мне нужна её там ещё не было. Допилили, молодцы. Но что делать с остальными возможностями?

Однако даже документация к libxml2 полнее, чем к cl-libxml2.

Естественно, документатор из меня тот ещё. Другое дело, что с cl-libxml2 можно работать и без документации вовсе (слава SLIME!), а для работы с libxml2 документации явно не достаточно.

А поскольку авторы осознавали, что написать полноценный мануал

им не под силу

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

они родили директорию examples, где все освещено.

Да прям, всё. Я, конечно, всё это хорошо изучал. Однако этого мало.

Так что там с HTTP в CL?

Хм, есть несколько веб-серверов, есть клиент Drakma, есть биндинг к curl. Впрочем, Drakma меня не устраивает и при необходимости (которая прогнозируется) я постараюсь написать решение на базе iolib, с асинхронным вводом/выводом и развратными женщинами.

Давай остановимся? Утверждать, что над С++ нимб светится от того, как с ним всё хорошо, несколько наивно. Все хорошо знают имеющиеся проблемы и что они обусловлены самой историей развития этого языка (ибо изначально и в последующем это было компромиссное решение). Со своей стороны, я никогда не говорил, что в CL всё хорошо (кстати, я достаточно часто пишу об это в блоге). Идеального языка сейчас просто нет и вряд ли он когда будет. CL предоставляет определённые возможности, которые являются привлекательными для многих. Но при этом имеет ряд инфраструктурных проблем. Вопрос лишь в том, готов ли принять имеющиеся проблемы ради имеющихся достоинств или нет. Этот выбор надо делать для любого языка и лучше, если с трезвой головой, без предрасудков.

> Есть языки (или правильнее сказать платформы?) первого класса и есть остальная шваль. В первому классу относятся C (и C++ в силу обратной совместимости), Java и .NET. Все остальное навешивает биндинги на эту великолепную тройку.

По этой логике Java, .NET и C++ тоже отлично подходят под определение швали. Язык первого класса только один.