Comments 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, когда/если баги пофиксят.
примитивный фэнбоизм без особо знания матчасти
UFO just landed and posted this here
кажется, вы неправильно поняли. автор использует идею как бы создания нового диалекта 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. Можно заново создавать.
UFO just landed and posted this here
Прямая ссылка на сайт автора: degutis.org. Его другие статьи по лиспу тоже интересно почитать.
> В конце концов, эти два языка стали довольно успешными, не так ли?
Заметил, что вот так вот игнорируют Perl, прообраз Ruby, и в некотором смысле Python. Ведь тоже вполне успешный язык, и еще используется, на нем полно рабочих проектов и прикладных библиотек.
Кстати недвано Maц сказал нечто следующее: «Если б я увидел современный Perl — я бы не стал создавать Ruby»
А так статья занятная, давно уже хочется clojure поковырять.
Заметил, что вот так вот игнорируют Perl, прообраз Ruby, и в некотором смысле Python. Ведь тоже вполне успешный язык, и еще используется, на нем полно рабочих проектов и прикладных библиотек.
Кстати недвано Maц сказал нечто следующее: «Если б я увидел современный Perl — я бы не стал создавать Ruby»
А так статья занятная, давно уже хочется clojure поковырять.
Sign up to leave a comment.
Будущее Лиспа