LINUX.ORG.RU

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


0

1

http://13-49-ru.blogspot.com/2010/07/blog-post_21.html

Утритесь, неосиляторы и s-exp'офобы. Лисп - не только лучший язык, но и успешно доказывает это в промышленных разработках и даже среди C++- и java-кодеров, не читавших умных книжек.

★★★★★

Ответ на: комментарий от archimag

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

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

tailgunner ★★★★★
()
Ответ на: комментарий от tailgunner

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

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

archimag ★★★
()
Ответ на: комментарий от linuxfan

Знаешь какой вывод напрашивается? Что не надо свои наколенные поделки с -D_GNU_SOURCE называть Ъ C++.

Т.е. gcc/g++ - это не Ъ-C/C++? А gnu-софт - это тоже наколенные поделки? А что делать, если раньше фича foo присутствовала без _GNU_SOURCE (т.е., вроде как, Ъ), а в следующей версии компилятора стала её требовать?

Гипотеза подтверждается.

И эти люди мне говорят, как FFI может сломаться... Да код на коммон лиспе (ANSI) между различными имплементациями более переносим, чем крестовый между разными компиляторами.

И зря, что буста не было. Он-то написан людьми, которые знают и умеют писать на Ъ C++. Наверное, поэтому он совместим с весьма широким спектром компиляторов.

Отлично! Почему тогда он тоже сломался при переходе с gcc 3 на 4? А почему в его кишках столько quirk'ов и workaround'ов для разных версий разных компиляторов на разных осях? Ничего не напоминает из критикумого тобой?

Ты опять про наколенные поделки? Часто у тебя бывало, что после апгрейда libc или libstdc++ система ломалась? libjpeg, libpng и куча других библиотек сколько времени держат стабильное API?

С glibc только за последние пару лет помню несколько моментов, когда Дреппер сохами в землю упирался и говорил, что это весь софт глючный, а не его glibc.

С остальными библиотеками тоже есть проблемы с несовместимыми API, ABI, поэтому из суперсовместимого софта на C/C++ собирают дистрибутивы, призванные избавить пользователя от анальной кары несовместимости.

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

mv ★★★★★
()
Ответ на: комментарий от archimag

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

Итак, с 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 абсолютно согласен. Там без свига ручками неприкольно. А чем в лиспе лучше, чем из плюсовки-то? Можно поподробнне осветить эту сторону вопроса?

linuxfan
()
Ответ на: комментарий от archimag

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

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

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

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

linuxfan
()
Ответ на: комментарий от linuxfan

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

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

tailgunner ★★★★★
()
Ответ на: комментарий от mv

>Да код на коммон лиспе (ANSI) между различными имплементациями более переносим, чем крестовый между разными компиляторами.

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

А почему в его кишках столько quirk'ов и workaround'ов для разных версий разных компиляторов на разных осях? Ничего не напоминает из критикумого тобой?

В какой лисповой библиотеке ты хочешь, чтобы я нашел волшебные #+(...)? И, кстати, будь добр, уточни, что полезного можно написать на ANSI-compliant lisp? На нем даже http-клиента не напишешь, потому что FFI не стандартизован и свой у каждой реализации!

С glibc только за последние пару лет помню несколько моментов, когда Дреппер сохами в землю упирался и говорил, что это весь софт глючный, а не его glibc.

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

С остальными библиотеками тоже есть проблемы с несовместимыми API, ABI, поэтому из суперсовместимого софта на C/C++ собирают дистрибутивы, призванные избавить пользователя от анальной кары несовместимости.

Я вновь вынужден напомнить тебе о 90% десктопов под управлением ОС Windows, где люди живут себе и спокойно пользуют кучу плюсовых приложений, не имея никакой головной боли. В линаксе ситуация примерно столь же радужная.

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

linuxfan
()
Ответ на: комментарий от tailgunner

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

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

linuxfan
()
Ответ на: комментарий от linuxfan

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

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

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

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

tailgunner ★★★★★
()
Ответ на: комментарий от linuxfan

> Итак, с 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 и можно экспериментировать, фактически с С-кодом, прямо в нём.

archimag ★★★
()
Ответ на: комментарий от archimag

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

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

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

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

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

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

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

linuxfan
()
Ответ на: комментарий от linuxfan

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

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


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

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

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


Не так ли?



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

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


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

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


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

archimag ★★★
()
Ответ на: комментарий от archimag

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

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

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

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

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

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

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

linuxfan
()
Ответ на: комментарий от linuxfan

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

Ты упорно игнорируешь оппонентов и ведёшь разговор с воображаемым другом? Друг тебе не предлагал посмотреть исходники любой портабельной крестовой библиотеки, хоть тот же boost?

И, кстати, будь добр, уточни, что полезного можно написать на ANSI-compliant lisp? На нем даже http-клиента не напишешь, потому что FFI не стандартизован и свой у каждой реализации!

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

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

Т.е. ты даже не в теме про бодания Дреппера? Хреновенький такой сишник.

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

У меня проблем и несовместимостей в лиспе не больше, чем в си/крестах. Всего лишь.

mv ★★★★★
()
Ответ на: комментарий от linuxfan

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

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

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


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

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


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

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

им не под силу



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

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


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

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


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

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

archimag ★★★
()
Ответ на: комментарий от mv

>Друг тебе не предлагал посмотреть исходники любой портабельной крестовой библиотеки, хоть тот же boost?

Я предлагал другу погрепать коды лисповых библиотек на предмет #+(...)?

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

Реакторов? Ядерных?

Т.е. ты даже не в теме про бодания Дреппера? Хреновенький такой сишник.

Просвяти же меня!

linuxfan
()
Ответ на: комментарий от Love5an

> Треды(да даже и сокеты, но треды - особенно) в стандарт языка программирования пихать - бредятина.

Именно поэтому, например, в Scheme треды - это srfi. Опциональное расширение стандарта. ИМХО идеальное решение.

naryl ★★★★★
() автор топика
Ответ на: комментарий от linuxfan

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

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

naryl ★★★★★
() автор топика
Ответ на: комментарий от linuxfan

> Схема уже перестала быть оторванным от жизни академическим говном? Научилась сокеты и прочие радости жизни изображать?

Да, но к теме это не относится. Да и оторванным от жизни она никогда не была. Академическим говном, но не оторванным от жизни. ;)

naryl ★★★★★
() автор топика
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.