Например, почему Clojure сосёт у CL: http://www.linux.org.ru/jump-message.jsp?msgid=3716932&cid=3717630 :)

наверное я не так гуглил, но гугль выдает мне перлы вроде таких:

http://www.linux.org.ru/view-message.jsp?msgid=3737944

(толпа лисперов учится выводить A1 B2 C3 D4 на экран )

прочитав этот топик я проникся простотой, понятностью и удобством lisp :)

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

спасибо :)

iterate таки пропатчили?

> iterate таки пропатчили?

Ты же не знаешь, что это такое, почему тебя волнует его судьба? :)

ps: still user of loop

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

В таком случае, надо бы иметь его в lisp-lor-faq.

> Ты же не знаешь, что это такое, почему тебя волнует его судьба? :)

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

> а на lisp любая сложная задача уровня вывода строки на экран требует применения патчей, выбора из десятка вариантов и консультации с десятком других лисперов?

Несомненно! Только вместе, толпой мы можем запинать вымирающих титанов плюсатой мысли.

> Несомненно! Только вместе, толпой мы можем запинать вымирающих титанов плюсатой мысли.

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

> Например, почему Clojure сосёт у CL: http://www.linux.org.ru/jump-message.jsp?msgid=3716932&cid=3717630 :)

Кстати да, я не представляю, как на яве сделать рестарты :-) интересно, как с этим у mono

> Несомненно! Только вместе, толпой мы можем запинать вымирающих титанов плюсатой мысли.

К нам намного сложнее придраться... ибо простые вопросы типа "как вывести строку на терминал" относятся к С, а не С++, и мы тут типа не причем...

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

>> Ты же не знаешь, что это такое, почему тебя волнует его судьба? :)

>на lisp любая сложная задача уровня вывода строки на экран требует применения патчей, выбора из десятка вариантов и консультации с десятком других лисперов?

Что-то ты заливаешь. Посмотри любой файл в емаксе, тот же tetris.el - ничего там сверхестественного нет.

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

я вас внимательно слушаю - что я такого не вижу со своим маленьким ростом?

что такое? нечего сказать? обосрались?

> я вас внимательно слушаю - что я такого не вижу со своим маленьким ростом?

Рост в студию!

178см

Кстати, да. Re: их удел

А есть ли аналог Hibernate (или чегонить довольно равноценного) и аналог Spring (или чегонить довольно равноценного) для С++ ?

maxima, axiom, acl2, autocad, ITA Software....

>А есть ли аналог Hibernate (или чегонить довольно равноценного) и аналог Spring (или чегонить довольно равноценного) для С++ ?

В Окамле тоже нет.

сразу видно неумного человека. до свидания....

мне не приходилось сталкиваться с ними( я так понял это все для Java ), гугль нашел:

http://code.google.com/p/pococapsule/
http://code.google.com/p/hiberlite/

но думаю они как минимум уступают в возможностях

> maxima, axiom, acl2, autocad, ITA Software....

autocad только для скриптования лисп использует, все остальное имеет лучшие аналоги, остается только многоточие - но оно меня не впечатлило

> до свидания....

вали, пердун

Нет, вывод типов это не совсем typeof...

> Нет, вывод типов это не совсем typeof...

да - мы уже посмеялись :)

Типовая параметризация в Ocaml еще то гавно
попробуй внутри параметризованного класса объявить параметризованный метод, да и синтаксис - убивать надо

и вообще, камл - эще та задница, особенно меня порадовало, в свое время, что он не мог сделать tail recursion на методах и, самое забавное - зависал, когда стэк заканчивался

У меня как бы противоположные ощущения :)

Сваять конкретный аналог
let compose f g = function x -> f(g(x));;
на C/С++/C#/Java/Pascal легко!

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

Нет, ещё не появилось ISO14882C++0x планируется к концу года.

> Нет, ещё не появилось ISO14882C++0x планируется к концу года.

стандарт - да, а реализация уже есть

> Типовая параметризация в Ocaml еще то гавно

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

До этого я еще не добрался.

> он не мог сделать tail recursion на методах и, самое забавное - зависал, когда стэк заканчивался

В Си++ (с которым сравнение) tail recursion вобще нет :)

> Сваять конкретный аналог

> let compose f g = function x -> f(g(x));;

> на C/С++/C#/Java/Pascal легко!

Можно увидеть аналог на Си?

А что вы против emacs имеете? Я именно в нём пишу на C++/Perl и т.д.

Намана пока.

Лисп - отец всего. И к нему всё сходится в любом оптимизирующем компиляторе, только вам не докладывают.

> В Си++ (с которым сравнение) tail recursion вобще нет :)

Может я чего-то путаю, но для нефункциональных языков, коим является, к слову сказать, и C++, разве имеет отношение рекомая хвостовая рекурсия?

;-)

> но для нефункциональных языков, коим является, к слову сказать, и C++, разве имеет отношение рекомая хвостовая рекурсия?

Да, конечно.

>> он не мог сделать tail recursion на методах и, самое забавное - зависал, когда стэк заканчивался

> В Си++ (с которым сравнение) tail recursion вобще нет :)

a) хвостовая рекурсия - просто еще один вид оптимизации, который многие плюсовые компиляторы умеют уже 100 лет в обед
б) негров в америке конечно же линчуют, но _зависать_ на stack overflow это очень поганое поведение

> a) хвостовая рекурсия - просто еще один вид оптимизации,

А с этим кто-то спорит?

> который многие плюсовые компиляторы умеют уже 100 лет в обед

Ссылку. И версию Окамля, на которой была проблема.

> a) хвостовая рекурсия - просто еще один вид оптимизации, который многие плюсовые компиляторы умеют уже 100 лет в обед

Речь как я понял идёт как раз о выполнении этой операции на уровне языка. Или явное на это указание программистом. Чего в C++ я не наблюдаю окромя ~unroll_loop, но это не язык.

Не понимаю необходимости такого средства и вопрошаю умудрённых.

> А что вы против emacs имеете? Я именно в нём пишу на C++/Perl и т.д.

против него - ничего, я против фанатиков, которые везде про него талдычат, только заходит разговор про любой редактор или IDE - сразу прибегают и кричат, что emacs всех краше

Этого дэ-юре быть не может, сами понимаете.

Если вы про #ifndef __GXX_EXPERIMENTAL_CXX0X_, то это ещё не реализация, а проект. Сам жду.

>> который многие плюсовые компиляторы умеют уже 100 лет в обед

> Ссылку.

RTFM

> И версию Окамля, на которой была проблема.

3.08.x или 3.09.x, не помню, в общем года полтора-два назад точно
сам проверь, рекурсивно в методе объекта, позови себя
там скорее всего из-за того что smalltalk like объектная модель

+ кэмловские параметризованные типы не умеют частичную специализацию
+ нет перегрузки по типу аргументов - иногда это дает увлекательные результаты
+ дебильный скопинг - когда к полю типа надо обращатся Var.Module.name_of_field
+ попробуй сделать float + int в кэмле (достало в свое время все время писать функции на каждую операцию с разными типами и использовать их )

> ротив него - ничего, я против фанатиков, которые везде про него талдычат, только заходит разговор про любой редактор или IDE - сразу прибегают и кричат, что emacs всех краше

Ну так вы ещё не попробовали? Таки краше ж! :-D

vim-еров не обижать! Тоже хорош, но не для меня. emacs логичнее и однороднее.

>> a) хвостовая рекурсия - просто еще один вид оптимизации, который многие плюсовые компиляторы умеют уже 100 лет в обед

> Речь как я понял идёт как раз о выполнении этой операции на уровне языка. Или явное на это указание программистом. Чего в C++ я не наблюдаю окромя ~unroll_loop, но это не язык.

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

+ выведение типов в окружении где наличествуют параметризованные типы и сложно сочиненные типы из смешной и забавной игрушки превращается в злую шутку

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

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

> Если вы про #ifndef __GXX_EXPERIMENTAL_CXX0X_, то это ещё не реализация, а проект. Сам жду.

в 4.4 это реализовано:

http://gcc.gnu.org/gcc-4.4/changes.html
http://gcc.gnu.org/gcc-4.4/cxx0x_status.html

>>> который многие плюсовые компиляторы умеют уже 100 лет в обед

>> Ссылку.

> RTFM

FM, которые я R, говорят, что gcc умеет оптимизировать хвостовые вызовы с существенными ограничения.

> + попробуй сделать float + int в кэмле

Ну это да, общеизвестный косяк :)

> Ссылку

http://www.ddj.com/architect/184401756

З.Ы. пропускал уроки в лор.девелопмент ?

> выведение типов зло, и везде где только можно его стоит пресекать

нужен только local type inference и его вариации