5-й номер журнала «Практика функционального программирования»

> Ты бы сказал, что у тебя просто идиосинкразия на CL.

Ну я и сказал. Извини, что не сразу.

Зачем же так извращаться-то попусту.

Я тролль же :(

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

>Нет, модуль на ECL нельзя вызывать из SBCL

а, значит модуль вызвать, ну тогда компилим ecl как c либу, и тут дальше всё написано:

http://www.sbcl.org/manual/Step_002dBy_002dStep-Example-of-the-Foreign-Functi...

Почему у меня ушло на это минуту поиска?

> Почему у меня ушло на это минуту поиска?

У меня не ушло на это ни минуты - я понимал, что без FFI модуль на ECL вызвать нельзя, и в этом отличие ECL от Cython. А ты так и не ответил на мой вопрос, что, впрочем, характерно для лисп-фанбоев - они не могут признать недостатки любимого инструмента.

> т.е. ты мне вбросы предлогаешь

Я - тебе? Ты фантазируешь.

даже без каких-либо пояснений (насколько большие проекты тестировались и пр)

Догадайся с трех раз, что могло тестироваться. Подсказка: какой самый известный проект использует Git?

а я должен мэил лист грепать?

*shrug* не грепай.

> Я - тебе? Ты фантазируешь.

А кто говорил, что mercurial быстрее git'a?

Догадайся с трех раз, что могло тестироваться.

что угодно

Подсказка: какой самый известный проект использует Git?

Вот и давай бенчмарки на кернел

> А кто говорил, что mercurial быстрее git'a?

Я. Но я это не тебе сказал.

давай бенчмарки

Наша песня хороша, начинай сначала.

> Я. Но я это не тебе сказал.

И что?

Ах, да, пистон - говно и медленее даже пхп во ВСЕМ. Только я это не tailgunner сказал, так что доказательств не будет.

> пистон - говно и медленее даже пхп во ВСЕМ.

Аминь, брат :D

> Ах, да, пистон - говно

здравствуйте, К.О.

так что доказательств не будет

это и так очевидно

>У меня не ушло на это ни минуты - я понимал, что без FFI модуль на ECL вызвать нельзя, и в этом отличие ECL от Cython.

Cython - это декларации из стандарта CL + FFI SBCL. ECL - другой лисп. Ты уже совсем бредишь.

А ты так и не ответил на мой вопрос,

ответил (смотри про рантайм).

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

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

>> А ты так и не ответил на мой вопрос,

ответил (смотри про рантайм).

Нужен был ответ «да» или «нет». Могу повторить вопрос: могу ли я написать на ECL модуль и _прозрачно_ (без FFI) использовать его в SBCL?

Начнем хотя бы с того, что недостатков лиспа ты не называл.

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

>Нужен был ответ «да» или «нет».

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

это унылый синтаксис

очень объективная и аргументированная точка зрения.

невменяемые фанбои.

и как они тебе мешают? ты сам-то пока ничего вменяемого по лиспу не сказал.

> А из питона ты можешь прозрачно вызвать модуль на jпитоне?

Нет. Но я и не говорю, что Jython - аналог Cython.

это унылый синтаксис

очень объективная и аргументированная точка зрения.

Личные быдловкусы. Правда, их разделяет большинство.

невменяемые фанбои.

и как они тебе мешают?

Мне? Обычно никак (хотя немного раздражает, когда в девелоперский лист Python или D приходит такой и начинает объяснять, что всё не нужно, кроме лиспа). Такие фанбои мешают самому CL.

ты сам-то пока ничего вменяемого по лиспу не сказал.

Я сказал, что ничего против него не имею, но заявления типа «лисп рвет» меня смешат.

>Правда, их разделяет большинство.

ну дык, миллионы не могут ошибаться.

что Jython - аналог Cython.

это другой аноним говорил.

Такие фанбои мешают самому CL.

Каким образом?

типа «лисп рвет» меня смешат

то есть сильного отставания чистого питона/руби от ведущих реализаций лиспа не наблюдается. я правильно понял?

>> Такие фанбои мешают самому CL.

Каким образом?

Имидж портят. Впрочем, мнение миллионов мух лисперов не заботит, понимаю %)

типа «лисп рвет» меня смешат

то есть сильного отставания чистого питона/руби от ведущих реализаций лиспа не наблюдается. я правильно понял?

Нет, ты понял неправильно.

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

Потому же, почему и лисперы к «Все г..но кроме моч.. лиспа» :-D

> Потому же, почему и лисперы к «Все г..но кроме моч.. лиспа» :-D

Хм, можно ссылку на подобное высказывание? Буду хоть знать, кто такое говорит.

> Хм, можно ссылку на подобное высказывание? Буду хоть знать, кто такое говорит.

Да архимаг и говорил :))) Другими словами, но с тем же смыслом.

> Да архимаг и говорил :))) Другими словами, но с тем же смыслом.

Знаете, за вашу фантазию и способность коверкать смысл сказанных слов я отвечать не могу.

> Знаете, за вашу фантазию и способность коверкать смысл сказанных слов я отвечать не могу.

Далеко ходить не надо:

haskell для тех, кто любит созерцать «идеальные» конструкции. Это не инструмент созидания, а скорей способ размышлений о вечном ;) archimag * (22.05.2010 23:58:11)

Если б это было хотя бы 1% от правды, то было бы нормально, а так это и есть «все г..но кроме лиспа»

Логика «стандартна» в плане того, что все БД-ориентированные системы используют схожие алгоритмы. Это на сервере. А клиент - там я уже сделал Perl-конвертер из C# классов в формы списков/редактирования (XAML). Получилось неплохо, нужные классы добавляются на раз-два.

Касательно «1000 боилерплейта», тут меня терзают смутные сомнения. :)
Чтобы за 1 строкой спрятать 1000, эти строки всё равно надо написать!
Работу, как правило, ускоряют библиотеки, а не выразительные скобочки языка :)

> по скорости cl порвет питон

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

Работу, как правило, ускоряют библиотеки, а не выразительные скобочки языка :)

Не обязательно. Заезженный пример с быстрой сортировкой на Haskell и C. Что именно здесь делает код короче?

http://www.haskell.org/haskellwiki/Introduction

И это, пожалуй, самый простой пример. А ускорение работы при помощи библиотек это брутфорс чистейшей воды. Так и ассемблер можно «продуктивно» использовать.

> Если б это было хотя бы 1% от правды, то было бы нормально, а так это и есть «все г..но кроме лиспа»

С логикой у тебя очень плохо.

у тебя импотенция головного мозга. А питон тормознутое УГ

>>это унылый синтаксис

очень объективная и аргументированная точка зрения.

А ты хотел математическое обоснование пригодности синтаксиса? Как раз с математической точки зрения, синтаксис лиспа идеален, а вот с точки зрения его использования — не очень. Отсюда вывод: объективного взгляда на синтаксис не бывает, есть только субъективный. И он нам говорит, что синтаксис лиспа — говно.

> Отсюда вывод: объективного взгляда на синтаксис не бывает, есть только субъективный. И он нам говорит, что синтаксис лиспа — говно.

Отсюда вывод: объективного взгляда на синтаксис не бывает, есть только субъективный. И он нам говорит, что синтаксис хаскеля — говно.

Отсюда вывод: объективного взгляда на синтаксис не бывает, есть только субъективный. И он нам говорит, что синтаксис питона — говно.

Отсюда вывод: объективного взгляда на синтаксис не бывает, есть только субъективный. И он нам говорит, что синтаксис си — говно.

Отсюда вывод: объективного взгляда на синтаксис не бывает, есть только субъективный. И он нам говорит, что синтаксис си++ — говно.

Ну ты понял.

> ассемблер с nop порвет все
мне почему-то кажется что твой ассемблерный говнокод будет работать медленее сгенереного gcc

> Ну ты понял.

Ты всё правильно сказал, но забыл об одной простой вещи: количестве людей, разделяющих каждый из приведенных субъективных взглядов. Ну, «миллионы мух», ты понял...

> количестве людей, разделяющих каждый из приведенных

субъективных взглядов.

Что колличество людей? Что за манера говорить многозначительными фразами, из которых ничего не следует? Неужели так трудно ясно сформулировать свою мысль?

> Что за манера говорить многозначительными фразами, из которых ничего не следует?

Ты просто не можешь или не хочешь понять. Впрочем, изволь: количество людей, которые считают синтаксис Лиспа говном, гораздо больше, чем тех, которые считают говном синтаксис Си или Питона.

> количество людей, которые считают синтаксис Лиспа говном, гораздо

больше, чем тех, которые считают говном синтаксис Си или Питона.

Это что и вся мысль? Какой смысл в глубокомысленном утверждении общеизвестных фактов?

Мне никогда не нравился синтаксис Python, ибо я предпочитаю синтаксис в стиле C, но когда писал на Python мне даже в голову не приходило жаловаться на это: это данность, её надо просто принять, ведь Python я использовал вовсе не из-за его синтаксиса. Также из CL, я нахожу во многих случаях C-синтаксис более удобным, но s-выражения обеспечивают некоторые важные возможности, которые нельзя эффективно выразить с помощью синтаксиса в стиле C, так что скобочки это просто данность, которую надо принять ради получения многих важных преимуществ.

> Это что и вся мысль?

Ага. Я же не претендую на вселенские откровения.

Какой смысл в глубокомысленном утверждении общеизвестных фактов?

А чтобы их не забывали.

скобочки это просто данность

Обычно есть выбор - Лисп или не Лисп.

> Обычно есть выбор - Лисп или не Лисп.

Такой выбор есть всегда для всех языков. И что? Ты будешь делать выбор инструментального средства на основе синтаксических предпочтений? Мне это кажется странным, если задачу можно решить как на C так и на Python, то я никогда не будут делать выбор на основе того, что синтаксис Python мне нравится меньше, чем синтаксис С.

tailgunner

Впрочем, изволь: количество людей, которые считают синтаксис Лиспа говном, гораздо больше, чем тех, которые считают говном синтаксис Си или Питона.

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

о про скорость зашла речь. Кто сможет объяснить почему мега супер оптимизированное решение на cl для обрезки карт, для которого утверждалось, что быстрее невозможно сделать - http://swizard.livejournal.com/140846.html проиграло как по скорости так и по памяти решению на python - http://community.livejournal.com/fprog/11783.html?thread=300807#t300807

а ведь одной из целью решения на cl было «Продемонстрировать, что решения на CL практичны: при сравнимом LOC оказываются производительнее и потребляют меньше памяти, нежели решения на других языках» (http://swizard.livejournal.com/142027.html)

как же такое может быть?

> Кто сможет объяснить почему мега супер оптимизированное

решение на cl для обрезки карт

Ну, дык, ты что, читать не умеешь? Там же ясно написно: clisp.

> Ну, дык, ты что, читать не умеешь? Там же ясно написно: clisp

всмысле? решение было на sbcl с супер нитями и паралельным чтением, оно *действительно* очень быстрое

> всмысле?

В смысле clisp - это интерпертатор, весьма тормозной.

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

оно *действительно* очень быстрое

В посте lionet ясно написано CLISP, скорей всего автор делал и оптимизировал для SBCL, а запускали на CLISP. CLISP это просто интерпретатор (и без нитей) и причин, почему бы он должен быть быстрее, чем Python, в природе нет.

Подробное обсуждение скорости CL vs Python было здесь: http://www.linux.org.ru/forum/development/4535326

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

Вы что, не видите, что там CLISP? Это весьма медленная реализация CL. Правда она мне нравится - памяти ест мало. SBCL намного быстрее.

Инетерсно, когда проводили конкурс в жюри хоть один лиспер был?

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

под CLISP имелось ввиду Common LISP, а не гнутая реализация

> Слюшай, Дарагой. За всех людей говорить-то не надо.

Послушай, «дарагой». Я не говорил за всех людей - я знаю, что некоторым синтаксис Лиспа нравится. Я так же знаю, почему он именно такой и в чем его сильные стороны.

Так от куда они могут знать какой у него синтаксис?

Я говорю о тех, кто знает.

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

то есть хочешь сказать, что «просто алгоритм, реализованный на CLISP был медленнее» - это не так. Человек реально рубит в теме и пишет быстрые программы на CLISP (sbcl), оптимизирует их на самом низком уровне в этом ему нет равных среди участников в конкурсе

своим постом я лишь хотел подчеркнуть, что не нужно скорость и память ставить как гигантский плюс - у лиспа предостаточно других преимуществ

tailgunner Не надо тень на плетень.. Тебе самому-то не смешно. Ты же там о миллионах упоминаешь..

Ты всё правильно сказал, но забыл об одной простой вещи: количестве людей, разделяющих каждый из приведенных субъективных взглядов.
Ну, «миллионы мух», ты понял...

Ай, ай, ай... Как не хорошо обманывать.

> под CLISP имелось ввиду Common LISP, а не гнутая реализация

Посмотрел код, действительно, видимо нужен SBCL. Но это уже не важно. Я помню ещё swizard писал, что там мол много на IO уходит, какие-то фокусы начал по этому поводу изобретать. Глянул код - и сразу, у него там используются flexi-streams. Стоило столько заниматься оптимизацией и при этом заюзать такую тормозящую либу.

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

оно не медленное. проблемма не в sbcl и не в реализации, проблема в быстром питоне :)

> оно не медленное

Ну как же, если для IO используется flexi-streams, то на больших объёмах данных (а там вроде были большие) этого достаточно что бы убить производительность.

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

Что такое быстрый питон?