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

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

> треды есть в C++0x

А сокеты? Я правильно понял, что ещё год назад программисты на C++ были фанатиками, ибо тогда в стандарте не было ни сокетов, ни тредов, а что за стандарт без сокетов и тредов? Но теперь они на пути к исправлению, ибо треды добавили в новый стандарт, а лет через 10 добавят ещё и сокеты?

Дебил тут ты.

google://bordeaux-threads

> Я правильно понял, что ещё год назад программисты на C++ были фанатиками

нет конечно - программисты на С++ не вопят, что треды не нужны в стандарте

> я имел ввиду стандарт на thread

Хм, и сколько приложений на C++ пользуются описанными там возможностями?

> Дебил тут ты.

молодец - умеешь повторять слова

> нет конечно - программисты на С++ не вопят, что треды не нужны

в стандарте

Ещё год назад вопили, а теперь не вопят, потому что добавили. Логично. К.О.

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

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

> Хм, и сколько приложений на C++ пользуются описанными там возможностями?

потоки в С++ используются очень часто

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

согласен

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

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

>Это каким образом компилятор может навязывать свой open, если он определён в стандарте??

RTFM. open не прописан в сишном стандарте. Там прописан только fopen. Ровно как и pthread_* не найти в стандартах языка. Однако есть стандарт POSIX, благодаря которому можно спокойно писать под зоопарк линаксов, фряху, солярку, чпуксы, qnx и еще черте какой экзотики.

Но если ты берешь один и тот же язык лисп, но две его реализации, то на одной и той же машине для многопоточности (кстати, многопоточность в лиспе ведь посасывает на некоммерческих реализациях?) в sbcl и clisp тебе нужно ставить костыль (borderaux-threads), который не всегда успевает обновляться и приспосабливаться к новым версиям лисповых имплементаций.

Захочешь работать с сокетами? Когда-то был trivial-socket, аффтар его забросил, появился usocket, реализующий в том числе и устаревшее API trivial-socket. А потом, бац, выходит новая версия clisp, в которой незначительно меняется FFI, у тебя просасывает CFFI и вместе с ним все, что завязано на внешние функции. Так смешно, что даже смешно говорить о промышленном лиспе.

И ни одна из этих двух с половиной реализаций не содержит своих расширений??

Еще как содержит. И ими даже можно пользоваться. И если бы потрудился осведомиться, в g++-ной STL есть ext/stdio_streambuf.h, котором ты мог бы воспользоваться на *nix'ах для оборачивания stdin/stdout/stderr дочерних процессов в плюсовые потоки.

Прекратите бредить.

Я до тебя доношу мысль о том, что в языке C есть доступ к POSIX compatibility layer операционных систем. В лиспе такого нет. Он остановился в развитии на уровне 80-х годов и с тех пор не сдвинулся ни на шаг. Достаточно посмотреть на его архаичные pathname'ы.

Потоки(streams) это такая структура данных.
А треды это треды. На крайний случай - нити.

> Ещё год назад вопили

а по-моему вы п%здите :)

> Потоки(streams) это такая структура данных.

А треды это треды. На крайний случай - нити.

http://ru.wikipedia.org/wiki/%D0%9C%D0%BD%D0%BE%D0%B3%D0%BE%D0%BF%D0%BE%D1%82...

и да - если у тебя есть официально утвержденный перевод, то давай ссылку

>google://bordeaux-threads

Это убожество с pthread несравнимо. Я даже не пытаюсь спросить, зачем нужен враппер, поддерживающий два коммерческих лиспа и один свободный? Поясню суть моего недоумения: если кто-то купил Allegro CL, зачем ему покупать LispWorks? И откуда у SBCL-ного нищеброда появятся деньги на коммерческий лисп?

Ну и, конечно, мне забавляет сам факт существования абстракции второго порядка: враппер для враппера системной библиотеки потоков, встроенной в реализацию языка. Брррр!

> Достаточно посмотреть на его архаичные pathname'ы.

Вот pathnames определённо зря ругаешь. Может, работа с ними и несколько громоздка, но они обеспечивают полную независимость от извратов ОС (при прямых руках, да).

> Однако есть стандарт POSIX

Приехали. И как отношение стандарт POSIX имеет к стандарту языка C? И почему я не могу из CL использовать функции из стандарта POSIX?

в sbcl и clisp тебе нужно ставить костыль (borderaux-threads),

В чём заключается его костыльность?

Хорошо, давай по другому, назови мне пожалуйста язык, в котором в стандарте прописана сборка мусора и потоки? Это важный момент, ибо сборка мусора зависит от реализации потоков. Стандартизировать потоки это значит ограничивать возможности по реализации сборки мусора. Где такое есть?

Захочешь работать с сокетами? Когда-то был trivial-socket, аффтар его

забросил, появился usocket, реализующий в том числе и устаревшее API

trivial-socket

Когда? Когда компьютеры были большими? Что мешает использовать iolib и современный API?

Я до тебя доношу мысль о том, что в языке C есть доступ к POSIX

compatibility layer операционных систем.

И я до тебя тоже доношу мысль о том, что в CL есть доступ к POSIX compatibility layer операционных систем. Стандарт POSIX это стандарт на операционные системы, а не на язык.

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

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

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

А потом, бац, выходит новая версия clisp, в которой незначительно меняется FFI, у тебя просасывает CFFI и вместе с ним все, что завязано на внешние функции. Так смешно, что даже смешно говорить о промышленном лиспе.

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

>Может, работа с ними и несколько громоздка, но они обеспечивают полную независимость от извратов архаичных, несуществующих или просто гипотетических ОС

fixed

Или ещё обобщённей: а потом, бац, выходит новая версия RHEL или вендов, и твой старый зоопарк программ отказывается на них работать. Так смешно, что даже смешно говорить об использовании программ в промышленности.

>А потом, бац, выходит новая версия gcc, в которой незначительно меняются подключаемые хидеры, у тебя просасывает либц и вместе с ней полдистрибутива.

Так толсто, что тебе стоит заняться пауэрмонадингом, чтобы сбросить жирок. Наличие и содержимое unistd.h мне гарантировано POSIX'ом. Или ты про сейчас про ext?

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

POSIX

Которого под винду, фактически, нету(не будем вспоминать cygwin(кстати, вот уж костыль так костыль)). А винда, это, напомню, 90, с чем-то там, процентов рынка.

в sbcl и clisp тебе нужно ставить костыль (borderaux-threads)

Я вот не пойму, в каком месте он более костыльный, чем pthreads? Все в нем нормально.

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

Ну-ка пример. Только не надо про clisp, там треды вообще в альфе, и в стабильные билды еще не вошли.

trivial-socket

Нашел чо вспомнить.

usocket

Вот именно. Хорошая библиотека, стабильная и вполне поддерживаемая.

А потом, бац, выходит новая версия clisp, в которой незначительно меняется FFI, у тебя просасывает CFFI и вместе с ним все, что завязано на внешние функции.

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

Еще как содержит. И ими даже можно пользоваться. И если бы потрудился осведомиться, в g++-ной STL есть ext/stdio_streambuf.h, котором ты мог бы воспользоваться на *nix'ах для оборачивания stdin/stdout/stderr дочерних процессов в плюсовые потоки.

Демагогия.

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

Смешно.

в языке C есть доступ к POSIX compatibility layer операционных систем. В лиспе такого нет.

Да им и в лиспе, при желании, ничто не мешает пользоваться. Но, опять же, смотри выше про этот самый posix. И, кстати, вот он уж то как раз и является древним говном мамонта, которое в развитии не сдвинулось ни на шаг c 80х-начала-90х годов.

Он остановился в развитии на уровне 80-х годов и с тех пор не сдвинулся ни на шаг.

Ох да конечно, конечно, слышали. И, кстати, какой лисп то? CL вон вообще в середине 90х только стандартизировался. И продолжает в современных реализациях развиваться. А про схему я уж и не говорю - вон R6RS тот же.

Достаточно посмотреть на его архаичные pathname'ы.

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

в языке C есть доступ к POSIX compatibility layer операционных систем. В лиспе такого нет.

Врёшь! POSIX языкам программирования ортогонален.

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

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

libpng/libjpeg/libxslt/xcb/gtk

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

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

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

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

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

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

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

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

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

Так толсто, что тебе стоит заняться пауэрмонадингом, чтобы сбросить жирок. Наличие и содержимое unistd.h мне гарантировано POSIX'ом. Или ты про сейчас про ext?

НИ РАЗУ не было такого, чтобы при переходе gcc 2->3->4 без ошибок собирался проект, написанный на Ъ-C++. Более того, при апгрейде «y» в 3.x.y и 4.x.y тоже проблемы были. А там даже буста не было, и шаблоны не использовались. Так, си с классами.

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

Хуле, такая же паделка, как и всё остальное в вашем IT.

> Более того, при апгрейде «y» в 3.x.y и 4.x.y тоже проблемы были. А там даже буста не было, и шаблоны не использовались. Так, си с классами.

и вы конечно не помните с чем была связана ошибка?

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

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

и вы конечно не помните с чем была связана ошибка?

Сессно, нет, пять лет прошло. Впрочем, если вы в то время уже программировали на C++, то сами должны помнить ;) Или в багтрекере дебиана посмотрите.

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

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

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

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

Это же ещё круче. В то время как погромисты на Java, .NET и подобном мечтают о Ъ переносимости кода лисперы просто кодят и запускают свои поделия.

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

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

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

И?

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

> В то время как погромисты на Java, .NET и подобном мечтают о Ъ переносимости кода лисперы просто кодят и запускают свои поделия.

а можно пример переносимой программы, написанной полностью на лиспе? ну чтоб можно было с той же Java сравнить

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

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

SBCL? Anyway такие вопросы лучше задавать не мне ибо я говнокодер.

> SBCL?

там код на C есть

> там код на C есть

Тогда сдаюсь. ^_^"

> а можно пример переносимой программы, написанной полностью на лиспе? ну чтоб можно было с той же Java сравнить

хеллоуворлд.

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

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

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

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

>А винда, это, напомню, 90, с чем-то там, процентов рынка.

Смотря какого. Anyway s/POSIX/Win API/ и получишь те же проблемы: нет нормальных биндингов к API операционной системы.

Только не надо про clisp

clisp в версии толи 2.34-2.35, толи 2.35-2.36 слегка поменял синтаксис для своего FFI. Как думаешь, cl-gtk при этом отвалился?

Только не надо про clisp, там треды вообще в альфе, и в стабильные билды еще не вошли.

2.48: Multiple threads of execution are now experimentally supported (not ready for prime time yet).

Учитывая, что в SBCL треды только под линаксом (и экспериментально под макосью и фряхой), а 90% рынка по твоим же словам у винды, можно считать, что треды во всех свободных реализациях находятся в одинаковом месте: в жопе.

- есть расширения, вот такие, такие, и еще такие, вобщем у нас клевые расширения, не то, что в лиспах.

Ну так сравни, на скольких платформах доступны эти расширения. Покрытие получится покруче, чем у лисповсих специфических расширений. Хотя, нет, лиспов свободных же всего полтора: SBCL и куча кривоты.

Да им и в лиспе, при желании, ничто не мешает пользоваться.

Мешает. Для этого как минимум нужно транслировать разнообразные константы и декларации функций.

А про схему я уж и не говорю - вон R6RS тот же.

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

А вот ручками парсить пути файлов из строковых представлений - вот это действительно архаично.

smb shares-то в идеологию pathnames укладываются? Или сказывается архаичность?

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

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

>НИ РАЗУ не было такого, чтобы при переходе gcc 2->3->4 без ошибок собирался проект, написанный на Ъ-C++.

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

Более того, при апгрейде «y» в 3.x.y и 4.x.y тоже проблемы были.

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

А там даже буста не было, и шаблоны не использовались.

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

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

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

>А это вообще везде так, не только в 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++.

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