Комментарии 54
И CL и Scheme иеют реализации на JVM (ABCL и KAWA). Есть реализации на Parrot (фигня, конечно). SBCL и CCL предлагают оптимизирующие компиляторы способные потягаться с статически типизированными языками. ECL легко встраивается куда угодно. CFFI позволяет легко склеивать CL и C и использовать в CL любые библиотеки на C. У Scheme реализаций тьма тьмущая. Racket предлагает развитую среду разработки. Bigloo — компиляцию в нативный код. и т. д.
Но автору это пофигу, для него CL и Scheme «умерли». Он откопал какую-то неведомую фигNu и торжественно её поверг.
Clojure, несомненно, крут, но автор уж слишком однобок.
Ну и паразитирование на JVM почему-то преподносится как ценность, перекрывающая вообще всё. Что тоже сомнительно.
Но автору это пофигу, для него CL и Scheme «умерли». Он откопал какую-то неведомую фигNu и торжественно её поверг.
Clojure, несомненно, крут, но автор уж слишком однобок.
Ну и паразитирование на JVM почему-то преподносится как ценность, перекрывающая вообще всё. Что тоже сомнительно.
паразитирование? как это понимать? разве jvm для этого и не была создана?
jvm дает: 1. кроссплатформеность; 2. возможность интеграции с огромным количеством кода и инструментов, реализованных для jvm (самая массовая платформа, кто бы как бы не плевался). Где ж тут недостатки? Отсутствие велосипедного интерпретатора/компилятора?
1. java.com/en/download/manual.jsp Что-то FreeBSD тут не видно. -1
2. Согласен. +1
Недостатки:
1. Java (и .net) слабо пригодны для desktop, где очень важен code sharing. Java cannot into shared libraries. :) Две одновременно запущенные программы на java — уже накладно. Результаты JIT-компиляции не шарятся между процессами, поэтому java-программы и жрут так много памяти.
2. Android/Dalvik пример того, что JVM не так уж и пригодна для мобильных устройств. Типичный процессор — регистровый, а JVM оперирует стеком. То, что может быть удобным для JIT не обязательно удобно для машин с ограниченными вычислительными ресурсами.
3. JVM cannot into оптимизация хвостовой рекурсии. Байт-код каждого метода изолирован и jump между методами не возможен. Это отменяет целую кучу оптимизаций и ФП затруднено. Не зря для рекурсии в Clojure отдельная конструкция.
2. Согласен. +1
Недостатки:
1. Java (и .net) слабо пригодны для desktop, где очень важен code sharing. Java cannot into shared libraries. :) Две одновременно запущенные программы на java — уже накладно. Результаты JIT-компиляции не шарятся между процессами, поэтому java-программы и жрут так много памяти.
2. Android/Dalvik пример того, что JVM не так уж и пригодна для мобильных устройств. Типичный процессор — регистровый, а JVM оперирует стеком. То, что может быть удобным для JIT не обязательно удобно для машин с ограниченными вычислительными ресурсами.
3. JVM cannot into оптимизация хвостовой рекурсии. Байт-код каждого метода изолирован и jump между методами не возможен. Это отменяет целую кучу оптимизаций и ФП затруднено. Не зря для рекурсии в Clojure отдельная конструкция.
1. FreeBSD скорее мертв, чем жив. Оценочное мнение, но статистика говорит примерно то же самое, показывая уровень около 0.01% для FreeBSD.
По недостаткам:
1. поправьте меня, если не прав, но память уже давно не является ограничивающим фактором. В основном, она критична для игрушек, монтажа и ряда применений, наподобие рендеринга, которые на десктоп вообще вытаскивают непонятно зачем.
2. Dalvik попутно доказывает, что нечто пригодное можно родить из байт-кода jvm если не прямым путем, то автоматическим образом точно. Кроме того, java как платформа предполагает на стороне клиента скорее только рисование интерфейса, а основная процессородробильная логика на стороне сервера.
3. Опять же могу быть не прав, ибо слежу за этими новостями крайне непоследовательно, но в project lambda хвостовая рекурсия предусматривается. Ее появление в jvm — скорее вопрос времени.
По недостаткам:
1. поправьте меня, если не прав, но память уже давно не является ограничивающим фактором. В основном, она критична для игрушек, монтажа и ряда применений, наподобие рендеринга, которые на десктоп вообще вытаскивают непонятно зачем.
2. Dalvik попутно доказывает, что нечто пригодное можно родить из байт-кода jvm если не прямым путем, то автоматическим образом точно. Кроме того, java как платформа предполагает на стороне клиента скорее только рисование интерфейса, а основная процессородробильная логика на стороне сервера.
3. Опять же могу быть не прав, ибо слежу за этими новостями крайне непоследовательно, но в project lambda хвостовая рекурсия предусматривается. Ее появление в jvm — скорее вопрос времени.
Тем не менее SBCL может предложить больше www.sbcl.org/platform-table.html
1. На десктопе работают десятки программ. Если они перестанут шарить ресурсы (код), то никакой памяти не хватит. Представьте, что переключатель раскладок и апплет погоды займут не 300KB, а 30MB. Для пользовательских данных памяти не останется вообще.
2. Я в Dalvik не специалист, но там не очень хорошо с reflection. Жертва не малая.
3. По-сути: сейчас ничего подобного нет.
1. На десктопе работают десятки программ. Если они перестанут шарить ресурсы (код), то никакой памяти не хватит. Представьте, что переключатель раскладок и апплет погоды займут не 300KB, а 30MB. Для пользовательских данных памяти не останется вообще.
2. Я в Dalvik не специалист, но там не очень хорошо с reflection. Жертва не малая.
3. По-сути: сейчас ничего подобного нет.
jvm — это не серебряная пуля. Пока не столкнусь с этим, мне пофиг на платформы, которые jvm не поддерживают.
Я не призываю исполнять серверный софт на дальвике и запускать jvm в серверном режиме для запуска стопицоттысяч мелких диалоговых окошек. И даже не рассматриваю варианты перевода всего и вся на jvm.
Всему свое время, место и применение. Clojure более жизнеспособен благодаря инфраструктуре jvm.
Я не призываю исполнять серверный софт на дальвике и запускать jvm в серверном режиме для запуска стопицоттысяч мелких диалоговых окошек. И даже не рассматриваю варианты перевода всего и вся на jvm.
Всему свое время, место и применение. Clojure более жизнеспособен благодаря инфраструктуре jvm.
«Java cannot into shared libraries» — я конечно извиняюсь, это Вы сейчас на каком языке написали?
Это такой мем. lurkmore.ru/Int
> Что-то FreeBSD тут не видно.
Кому надо, у того видно.
www.freebsdfoundation.org/downloads/java.shtml
А раз уж gnome-games не собрались, то, выходит, надо :) и пофиг на статистику
Кому надо, у того видно.
www.freebsdfoundation.org/downloads/java.shtml
А раз уж gnome-games не собрались, то, выходит, надо :) и пофиг на статистику
> ECL легко встраивается куда угодно.
В SBCL из quicklisp работает около 95% библиотек (пытался скачать-поставить все), в ECL на глазок — чуть меньше половины. И не из-за несовместимых расширений, а из-за багов в системе.
ИМХО войдёт в тройку самых используемых свободных реализаций рядом с SBCL и CCL, когда/если баги пофиксят.
В SBCL из quicklisp работает около 95% библиотек (пытался скачать-поставить все), в ECL на глазок — чуть меньше половины. И не из-за несовместимых расширений, а из-за багов в системе.
ИМХО войдёт в тройку самых используемых свободных реализаций рядом с SBCL и CCL, когда/если баги пофиксят.
примитивный фэнбоизм без особо знания матчасти
НЛО прилетело и опубликовало эту надпись здесь
кажется, вы неправильно поняли. автор использует идею как бы создания нового диалекта Lisp, чтобы провести анализ нынешнего положения всех остальных диалектов и их возможно развития. это всего лишь прием автора.
На Joblist не будет и вакансий на haskell'е, ocaml'е, erlang'е и smalltalk'е. Но при этом за специаллистов на этих языках платят неиллюзорные деньги.
При написании приложений в Cocoa, вы получаете модели, контроллеры, представления, и должны «склеить» их вместе минимальным количеством кода на Objective-C. Таким образом, вы теряете возможность применить все фичи Lisp. Почти каждая строка кода на Nu (навскидку — около 95%) только и будет, что вызывать код Objective-C, что превращает использование Lisp просто в какую-то нелепость.
А что, в приложении вообще нет никакой логики и оно просто показывает окошки? И в Cocoa (или как оно там называется в Макоси) нет декларативных методов создания интерфейсов?
JVM же предоставляет свободу. Архитектура полностью в ваших руках. Вы сами формируете модель. Уровень представления выбирается в зависимости от типа приложения(серверное, GUI, утилиты командной строки и т.д.). У вас полная свобода от самого начала и до конца.
Пожалуйста, расшифруйте. Почему у меня нет полной свободы(?) с руби, питоном или с++ я не могу понять.
Но мы быстро спускаемся на землю, с осознанием того, что эти языки, каждый из которых имеет свою среду программирования(никакого Emacs), которую любой может быстро освоить, чтобы стать экспертом в языке в течение считанных недель.
Боже…
Впечатление такое, что ребенку дали игрушку, и она в этот миг стала для него самой лучшей, самой прекрасной в мире и он об этом хочет сказать все миру.
А мне мои знания Clojure помогли найти классный проект. Переписал все на Python :) Ибо все было жутко медленно. И разработка. И исполнение. Хотя код был чертовски красив.
Lisp является замечательным семейством языков; его чрезвычайно минималистический синтаксис позволяет нам думать практически на уровне алгоритмов, не заморачиваясь по поводу неочевидного синтаксиса или каких-либо языковых рамок.
Конечно тут от задач зависит. Сталкивался плотно с диалектом автокадовским лиспа — аutolisp/visual lisp
Страх и ужас. Тот же код на C++ (objectArx) или тем более c# (.Net Api) на порядок очевиднее и легче и понятнее.
После „Положения на рынке” стало ясно что автор ничего полезного по теме сказать не сможет. CL сейчас более популярен чем Clojure. О последнем просто много говорят. Clojre популярен в том же смысле, что и Scala или Haskell.
Здесь автор сначала противоречит сам себе, а потом просто ошибается:
> И почему CL и Scheme умерли?
Scheme не умирал. Для чего он был разработан, там и используется до сих пор. CL тоже сейчас не более мёртв чем обычно, скорее даже менее.
Дальше не читал.
Интересно, кстати, что люди, которые действительно вкладывают время в написание опенсорцных библиотек, реализаций, утилит и т.д. *никогда* не берутся „смотреть в будущее” и судить о существующем положении. От всевозможных же Стивенов Дегутисов и Йегге (тоже Стив, кстати), я никакого вклада кроме болтовни не видел.
Меритократия.
Здесь автор сначала противоречит сам себе, а потом просто ошибается:
> И почему CL и Scheme умерли?
Scheme не умирал. Для чего он был разработан, там и используется до сих пор. CL тоже сейчас не более мёртв чем обычно, скорее даже менее.
Дальше не читал.
Интересно, кстати, что люди, которые действительно вкладывают время в написание опенсорцных библиотек, реализаций, утилит и т.д. *никогда* не берутся „смотреть в будущее” и судить о существующем положении. От всевозможных же Стивенов Дегутисов и Йегге (тоже Стив, кстати), я никакого вклада кроме болтовни не видел.
Меритократия.
нет, Йегге таки много чего делает: js2-mode, например, (правда, для меня он не подошел, но говорят, можно допилить), сейчас работает над дебаггером для Clojure и троллит Рича Хики, чтобы они наконец написали двухпроходный компилятор (http://news.ycombinator.com/item?id=2466731) — а то ж, действительно, стыдно…
Непонятно, почему закопали схему, она же используется как встраиваемый язык.
Совершенно непонятно то, зачем статья была написана. О чём она?
Минус статье, так как не вижу смысла переводить подобный трэш. Лучше помогите мне перевести по Clojure ресурсы.
Кстати, совершенно необоснованные выпады в сторону CL. В чем он плох? Дилетантское заявление «много скобочек», и всё. Так мне лично скобочки нравится, это даже прикольно. Если отлаживаться в нотепаде, то да, неудобно.
Минус статье, так как не вижу смысла переводить подобный трэш. Лучше помогите мне перевести по Clojure ресурсы.
Кстати, совершенно необоснованные выпады в сторону CL. В чем он плох? Дилетантское заявление «много скобочек», и всё. Так мне лично скобочки нравится, это даже прикольно. Если отлаживаться в нотепаде, то да, неудобно.
«Кстати, совершенно необоснованные выпады в сторону CL.»
это уже не беда скобочек. Вы стандарт гляньте — это уже монстер если и не почище С++, то сравнимо. Решили всерьез садиться на CL? Начинайте отращивать бороду.
это уже не беда скобочек. Вы стандарт гляньте — это уже монстер если и не почище С++, то сравнимо. Решили всерьез садиться на CL? Начинайте отращивать бороду.
Поставил вам плюсег. :)
Стандарт глядел. И это уже более-менее обоснованная претензия, во всяком случае, с намеком на обоснованность — перегруженный стандарт (и вправду перегруженный). Скобочки же это ну совсем не повод рыгать на Лисп.
Стандарт глядел. И это уже более-менее обоснованная претензия, во всяком случае, с намеком на обоснованность — перегруженный стандарт (и вправду перегруженный). Скобочки же это ну совсем не повод рыгать на Лисп.
(и вам тот же зелёный значок)
Поглядывая на Python, J/APL становится ясно, что тема Лиспа по-прежнему толком не расскрыта. Пока лисп — это грозное напоминание как великолепные концепты можно минорно «сливать» на обочину мировой ИТ-движухи.
Жду когда вылезет какой-нибудь гений и скажет я взял PyPy платформу заимплементировал на ней параллельно вычисляемый nano-лисп со спецификацией в три странички и все охренеют от того, что в его лисп-спеке вообще не окажется места ни строкам, ни числам, ни даже идентификаторам, а только скобкам и нескольким знакам припинания. а все остальные символы войдут в приложение «Character bindings recommendations».
В общем, галактико ждёт своих лисп-героев.
Поглядывая на Python, J/APL становится ясно, что тема Лиспа по-прежнему толком не расскрыта. Пока лисп — это грозное напоминание как великолепные концепты можно минорно «сливать» на обочину мировой ИТ-движухи.
Жду когда вылезет какой-нибудь гений и скажет я взял PyPy платформу заимплементировал на ней параллельно вычисляемый nano-лисп со спецификацией в три странички и все охренеют от того, что в его лисп-спеке вообще не окажется места ни строкам, ни числам, ни даже идентификаторам, а только скобкам и нескольким знакам припинания. а все остальные символы войдут в приложение «Character bindings recommendations».
В общем, галактико ждёт своих лисп-героев.
Стандарт CL отнюдь не монстр, если учесть, что он описывает и стандартную библиотеку: стандартная библиотека Python что-то в 10 раз больше, кажется…
А так, начинать нужно не с чтения стандарта. ANSI Common Lisp — отличный вводный курс. Или же Practical Common Lisp.
А так, начинать нужно не с чтения стандарта. ANSI Common Lisp — отличный вводный курс. Или же Practical Common Lisp.
«Стандарт CL отнюдь не монстр, если учесть, что он описывает и стандартную библиотеку: стандартная библиотека Python что-то в 10 раз больше, кажется…»
И, казалось бы, странно, что несмотря на кучу недостатков Питона, от него людей за уши не оттащишь. А с CL — зашли, посмотрели, побробовали, повздыхали и… свалили. Или всё же не странно? вместо того, чтобы меня минусовать, лучше бы объективно взглянуть на реаль, выводы сделать. Чего со мной воевать-то?
«А так, начинать нужно не с чтения стандарта. ANSI Common Lisp — отличный вводный курс. Или же Practical Common Lisp.»
а это уж извините, кому как. По моему опыту, мало кто до стандарта вообще добирается. А потом язык от реализации языка не отличает и после 10 программирования…
И, казалось бы, странно, что несмотря на кучу недостатков Питона, от него людей за уши не оттащишь. А с CL — зашли, посмотрели, побробовали, повздыхали и… свалили. Или всё же не странно? вместо того, чтобы меня минусовать, лучше бы объективно взглянуть на реаль, выводы сделать. Чего со мной воевать-то?
«А так, начинать нужно не с чтения стандарта. ANSI Common Lisp — отличный вводный курс. Или же Practical Common Lisp.»
а это уж извините, кому как. По моему опыту, мало кто до стандарта вообще добирается. А потом язык от реализации языка не отличает и после 10 программирования…
«И, казалось бы, странно, что несмотря на кучу недостатков Питона ...»
Я разве говорил, что это недостаток? Я о том, что «монструозность» стандарта CL — миф: никто ж не жалуется на «монтруозность» стандарта Питона, так ведь? Собственно, я про «объективный взгляд на реаль».
«И, казалось бы, странно, что несмотря на кучу недостатков Питона, от него людей за уши не оттащишь. А с CL — зашли, посмотрели, побробовали, повздыхали и… свалили.»
К Питону никаких претензий — сам пользуюсь. Но меня, например, как раз от CL за уши не оттащищь. Возможно, дело в разном устройстве мозгов (я серьезно).
Вообще говоря, претензия только к одному всегда: про Lisp любят распространять кучу разного FUD'а. Например, «стандарт — монстр» (надеюсь, доказал уже, что это не так), «библиотек — нет», «скобки съедят ваш мозг» и т.д. Не распространяте FUD! ;)
Я разве говорил, что это недостаток? Я о том, что «монструозность» стандарта CL — миф: никто ж не жалуется на «монтруозность» стандарта Питона, так ведь? Собственно, я про «объективный взгляд на реаль».
«И, казалось бы, странно, что несмотря на кучу недостатков Питона, от него людей за уши не оттащишь. А с CL — зашли, посмотрели, побробовали, повздыхали и… свалили.»
К Питону никаких претензий — сам пользуюсь. Но меня, например, как раз от CL за уши не оттащищь. Возможно, дело в разном устройстве мозгов (я серьезно).
Вообще говоря, претензия только к одному всегда: про Lisp любят распространять кучу разного FUD'а. Например, «стандарт — монстр» (надеюсь, доказал уже, что это не так), «библиотек — нет», «скобки съедят ваш мозг» и т.д. Не распространяте FUD! ;)
1. Друзья, для тех, кто не в теме. Хотите узнать на какой странице Common Lisp стандарта (CLTL2) находятся массивы (Arrays) или скажем строковые литералы (Strings)? Не-е-е-т, я вам не скажу. Ваши ставки в студию! Vseloved вы ведь наверное быстрее других ответите? ;)
2. удобное место посмотреть на лаконичность разных языков, например, тут:
rosettacode.org/wiki/Sorting_algorithms/Quicksort#Common_Lisp
и после этого уже можно тушить ненужные споры по очевидным вопросам.
3. а касательно длин стандартов базового языка (без библиотек) моё мнение таково:
3 стр — мечта.
~10 стр — коротко, здорово!
~20 стр — нормально, потянет.
~40 стр — много!
более 50? — монстр!
2. удобное место посмотреть на лаконичность разных языков, например, тут:
rosettacode.org/wiki/Sorting_algorithms/Quicksort#Common_Lisp
и после этого уже можно тушить ненужные споры по очевидным вопросам.
3. а касательно длин стандартов базового языка (без библиотек) моё мнение таково:
3 стр — мечта.
~10 стр — коротко, здорово!
~20 стр — нормально, потянет.
~40 стр — много!
более 50? — монстр!
Ну, вот видите, не зря я вас заминусовал ;)
1. Стандарт Common Lisp — это не CLTL2, а ANSI Common Lisp. Его HTML-версия находится тут: www.lispworks.com/documentation/HyperSpec/Front/Contents.htm. Вам рассказать, как там найти Arrays? ;)
Кстати, очень удобно пользоваться, особенно, когда в emacs'е одним нажатием кнопки перекидывает к определению нужного символа.
2. давайте про лаконичность не будет. Это еще одна длинная дискуссия, для которой нужно иметь достаточно опыта написания production-кода на разных языках, в наличие которого у вас я пока сомневаюсь (или покажите мне ваш github эккаунт).
3. У Scheme очень маленький стандарт и очень большое количество диалектов.
Ваши цифры совершенно отфонарны.
Если уже считать что-то, то не количество страниц, а количество сущностей. И принцип тут должен быть, наверно, такой:
— если хотите получить язык, который очень легко реализовать (например, чтобы его портировать для встраиваемых систем т.д.), то желательно стандарт по-меньше
— если хотите упростить жизнь пользователям, чтобы у них была портабельность приложений и им не пришлось постоянно изобретать велосипеды — то по-больше
Кстати, ядро стандарта Lisp'а — описание синтаксиса (проще не придумаешь) + 25 специальных операторов (у Scheme — 7, и это пока известный мне мимнимум) + описание базовых типов. Всё остальное (функции, макросы) можно считать стандартной библиотекой.
1. Стандарт Common Lisp — это не CLTL2, а ANSI Common Lisp. Его HTML-версия находится тут: www.lispworks.com/documentation/HyperSpec/Front/Contents.htm. Вам рассказать, как там найти Arrays? ;)
Кстати, очень удобно пользоваться, особенно, когда в emacs'е одним нажатием кнопки перекидывает к определению нужного символа.
2. давайте про лаконичность не будет. Это еще одна длинная дискуссия, для которой нужно иметь достаточно опыта написания production-кода на разных языках, в наличие которого у вас я пока сомневаюсь (или покажите мне ваш github эккаунт).
3. У Scheme очень маленький стандарт и очень большое количество диалектов.
Ваши цифры совершенно отфонарны.
Если уже считать что-то, то не количество страниц, а количество сущностей. И принцип тут должен быть, наверно, такой:
— если хотите получить язык, который очень легко реализовать (например, чтобы его портировать для встраиваемых систем т.д.), то желательно стандарт по-меньше
— если хотите упростить жизнь пользователям, чтобы у них была портабельность приложений и им не пришлось постоянно изобретать велосипеды — то по-больше
Кстати, ядро стандарта Lisp'а — описание синтаксиса (проще не придумаешь) + 25 специальных операторов (у Scheme — 7, и это пока известный мне мимнимум) + описание базовых типов. Всё остальное (функции, макросы) можно считать стандартной библиотекой.
Помните в детстве как вы ломали мозг над ООП в C++/Java и указателями в C? Вот теперь взрослым дядям не хочется ломать мозг ещё раз над рестартами, замыканиями (кто с ФП не встречался) и синтаксическими макросами. По крайней мере виденные мной вздохи с сваливания были обусловлены именно этим: „Там всё то же что и в Java, плюс ещё пара непонятных ненужных фич”. Всё как в Blub Paradox Грема.
раздули Scheme. Можно заново создавать.
НЛО прилетело и опубликовало эту надпись здесь
Прямая ссылка на сайт автора: degutis.org. Его другие статьи по лиспу тоже интересно почитать.
> В конце концов, эти два языка стали довольно успешными, не так ли?
Заметил, что вот так вот игнорируют Perl, прообраз Ruby, и в некотором смысле Python. Ведь тоже вполне успешный язык, и еще используется, на нем полно рабочих проектов и прикладных библиотек.
Кстати недвано Maц сказал нечто следующее: «Если б я увидел современный Perl — я бы не стал создавать Ruby»
А так статья занятная, давно уже хочется clojure поковырять.
Заметил, что вот так вот игнорируют Perl, прообраз Ruby, и в некотором смысле Python. Ведь тоже вполне успешный язык, и еще используется, на нем полно рабочих проектов и прикладных библиотек.
Кстати недвано Maц сказал нечто следующее: «Если б я увидел современный Perl — я бы не стал создавать Ruby»
А так статья занятная, давно уже хочется clojure поковырять.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Будущее Лиспа