Будущее Лиспа

Автор оригинала: Steven Degutis
  • Перевод
Это перевод статьи Стивена Дегутиса.

Будущее Lisp


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

Если вы еще не знакомы с ним, Lisp является замечательным семейством языков; его чрезвычайно минималистический синтаксис позволяет нам думать практически на уровне алгоритмов, не заморачиваясь по поводу неочевидного синтаксиса или каких-либо языковых рамок.

Положение на рынке


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

Clojure, несомненно, самый популярный диалект на сегодняшний день. Некоторые люди даже поспорили бы, что это единственный Lisp, который имеет практическую ценность в настоящее время. В нем появился синтаксический сахар для большого количества типов данных, удачная интеграция с JVM, исчезли все неуклюжие части, характерные для традиционных Lisp-языков.

Впрочем, есть и другие, такие как Nu, который является панацеей, если вы создаете что-то для IOS или Mac, но не любите указатели. (Эй, а ведь это чем-то смахивает на MacRuby!)

Но почему Nu не удалось взлететь? И почему CL и Scheme умерли? Почему лишь один Clojure набирает обороты? Может ли другой диалект Lisp ожидать такого же успеха?

Проклятие… и благословение


Несомненно, от синтаксиса никуда не денешься. S-выражения делают Lisp чрезвычайно простым и позволяют использовать крутую фичу, которую мы называем макросами, но все эти скобки просто отвратительны, и ни один человек не может с ними справиться, если только он не работает на Emacs+pardeit. Крупнейшее достоинство Лиспа является, вероятно, его самой большой слабостью.

Но мы также не должны забывать о переносимости. Никто не будет писать приложение полностью на Scheme, поскольку для него нет стандартных библиотек. Clojure переориентировался на JVM, которая является не только кросспатформенной, но и изобилует встроенными полезными классами и сторонними библиотеками. Благодаря Java, JVM является целостной и стабильной платформой.

Но какое нам дело до платформы?

Nu — очень интересный диалект. Он был создан, чтобы сделать процесс разработки под IOS / Mac легче и веселее. Он предоставляет набор макросов Lisp, а также целую кучу полезных инструментов, которые помогут вам начать разрабатывать.

Но Cocoa — SDK, а не платформа. Любой, кто говорит вам обратное, пытается вам что-то продать (вероятно, Xcode). В Mac/IOS приложениях вся фишка в графическом интерфейсе, и каждый компонент, который вам понадобится на любом этапе разработки, уже предусмотрен для вас (нужно добавить, они тесно связанны друг с другом) в рамках платформы. От вас нужно лишь немного воображения.

Так что же в этом плохого?

При написании приложений в Cocoa, вы получаете модели, контроллеры, представления, и должны «склеить» их вместе минимальным количеством кода на Objective-C. Таким образом, вы теряете возможность применить все фичи Lisp. Почти каждая строка кода на Nu (навскидку — около 95%) только и будет, что вызывать код Objective-C, что превращает использование Lisp просто в какую-то нелепость.

Кроме того, большинство библиотек Apple, просто не имеют никакого значения вне контекста данного вида разработки. Так что практически ничего нельзя сделать, чтобы эффективно использовать функциональную парадигму программирования, и к тому же приходится избегать низкоуровневого С функционала Apple, чтобы просто сохранить совместимость с Lisp.

Получается, что просто бессмысленно не использовать Apple-овский «суперклей»(речь о Objective-C) в пользу нашего «доморощенного» клея(Nu), это просто того не стоит. Это по своей сути проблема любой SDK — не только Cocoa, но и Android, и других.

JVM же предоставляет свободу. Архитектура полностью в ваших руках. Вы сами формируете модель. Уровень представления выбирается в зависимости от типа приложения(серверное, GUI, утилиты командной строки и т.д.). У вас полная свобода от самого начала и до конца.

Поиск правильной платформы

Но это не уникальная черта JVM. То же самое происходит и с С, и С++, Python и Ruby, не так ли? Посмотрим правде в глаза, Lisp, встроенный в Ruby или Python, является избыточным: эти языки позволяют реализовать 90% желаемого функционала, так зачем что-то придумывать только ради макросов, к тому же, такая система будет еще и медлительной.

И конечно же просто не может быть нормальной совместимости такого алгоритмического языка, как Lisp с таким низкоуровневым языком, как C, или таким спагетти-порождающим языком, как C++. Кто-то освобождает память, зачем, когда, и вообще, где моя курица? Все это слишком запутанно.

Другие потенциальные ниши

На секундочку может промелькнуть такая идея: пойти по пути Ruby и Python, написав интерпретируемый диалект Lisp с собственным набором стандартных библиотек. В конце концов, эти два языка стали довольно успешными, не так ли?

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

Или новый диалект Lisp мог бы пойти по пути Go и стать статическим языком с невероятно-быстрым временем компиляции и выполнения. Но я не думаю, что это самое важное. Время компиляции не может стать меньше, чем 0 — а это примерно там, где находятся Ruby и Python. А время выполнения теоретически не может быть намного меньше, чем время выполнения jvm, разве только при определенных обстоятельствах (планеты выстроятся в ряд, и вы пропрыгаете на одной ноге 3 раза).

Впереди, в обозримом будущем!


Правда в том, ни одна другая платформа прямо сейчас не может предоставить стандартные библиотеки, стороннюю поддержку, расширяемость, широкий функционал, сообщество, и переносимость на том уровне, на котом это делает JVM. Clojure в настоящее время является лучшим воплощением Lisp, и останется таковым в обозримом будущем.
Поделиться публикацией

Комментарии 54

    +11
    И CL и Scheme иеют реализации на JVM (ABCL и KAWA). Есть реализации на Parrot (фигня, конечно). SBCL и CCL предлагают оптимизирующие компиляторы способные потягаться с статически типизированными языками. ECL легко встраивается куда угодно. CFFI позволяет легко склеивать CL и C и использовать в CL любые библиотеки на C. У Scheme реализаций тьма тьмущая. Racket предлагает развитую среду разработки. Bigloo — компиляцию в нативный код. и т. д.

    Но автору это пофигу, для него CL и Scheme «умерли». Он откопал какую-то неведомую фигNu и торжественно её поверг.

    Clojure, несомненно, крут, но автор уж слишком однобок.

    Ну и паразитирование на JVM почему-то преподносится как ценность, перекрывающая вообще всё. Что тоже сомнительно.
      +2
      паразитирование? как это понимать? разве jvm для этого и не была создана?
        +2
        Судя по тому, что invoke dynamic появился совсем недавно, это скорее новое веянье чем изначальный план.
          +2
          А появился он затем, чтобы как-то поднять производительность языков с динамической типизацией до уровня Java. Меньше года назад я смотрел на производительность Clojure, которая сливала даже Jython'у, не говоря о Java, и совсем не говоря о CL.
        +3
        jvm дает: 1. кроссплатформеность; 2. возможность интеграции с огромным количеством кода и инструментов, реализованных для jvm (самая массовая платформа, кто бы как бы не плевался). Где ж тут недостатки? Отсутствие велосипедного интерпретатора/компилятора?
          +1
          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 отдельная конструкция.
            0
            1. FreeBSD скорее мертв, чем жив. Оценочное мнение, но статистика говорит примерно то же самое, показывая уровень около 0.01% для FreeBSD.
            По недостаткам:
            1. поправьте меня, если не прав, но память уже давно не является ограничивающим фактором. В основном, она критична для игрушек, монтажа и ряда применений, наподобие рендеринга, которые на десктоп вообще вытаскивают непонятно зачем.
            2. Dalvik попутно доказывает, что нечто пригодное можно родить из байт-кода jvm если не прямым путем, то автоматическим образом точно. Кроме того, java как платформа предполагает на стороне клиента скорее только рисование интерфейса, а основная процессородробильная логика на стороне сервера.
            3. Опять же могу быть не прав, ибо слежу за этими новостями крайне непоследовательно, но в project lambda хвостовая рекурсия предусматривается. Ее появление в jvm — скорее вопрос времени.
              +1
              Тем не менее SBCL может предложить больше www.sbcl.org/platform-table.html

              1. На десктопе работают десятки программ. Если они перестанут шарить ресурсы (код), то никакой памяти не хватит. Представьте, что переключатель раскладок и апплет погоды займут не 300KB, а 30MB. Для пользовательских данных памяти не останется вообще.
              2. Я в Dalvik не специалист, но там не очень хорошо с reflection. Жертва не малая.
              3. По-сути: сейчас ничего подобного нет.
                0
                jvm — это не серебряная пуля. Пока не столкнусь с этим, мне пофиг на платформы, которые jvm не поддерживают.
                Я не призываю исполнять серверный софт на дальвике и запускать jvm в серверном режиме для запуска стопицоттысяч мелких диалоговых окошек. И даже не рассматриваю варианты перевода всего и вся на jvm.
                Всему свое время, место и применение. Clojure более жизнеспособен благодаря инфраструктуре jvm.
                  0
                  > jvm — это не серебряная пуля.

                  Перечитайте мой первый комментарий. Именно это я и пытался донести.
              +2
              «Java cannot into shared libraries» — я конечно извиняюсь, это Вы сейчас на каком языке написали?

              0
              > Что-то FreeBSD тут не видно.

              Кому надо, у того видно.
              www.freebsdfoundation.org/downloads/java.shtml
              А раз уж gnome-games не собрались, то, выходит, надо :) и пофиг на статистику
            +1
            > ECL легко встраивается куда угодно.

            В SBCL из quicklisp работает около 95% библиотек (пытался скачать-поставить все), в ECL на глазок — чуть меньше половины. И не из-за несовместимых расширений, а из-за багов в системе.

            ИМХО войдёт в тройку самых используемых свободных реализаций рядом с SBCL и CCL, когда/если баги пофиксят.
              0
              Ага. Сам не использую, но слежу за новыми версиями. Для меня лакмусовая бумажка — flexi-streams, пока не работает в ECL.
                +1
                Кому писал программки, запускаемый образ SBCL даже пожатый gzexe у всех вызывал одну и ту же реакцию: „Почему так много весит?!?”. ECL может сильно расширить потенциальную клиентскую базу. ;)
            +7
            примитивный фэнбоизм без особо знания матчасти
            • НЛО прилетело и опубликовало эту надпись здесь
                0
                кажется, вы неправильно поняли. автор использует идею как бы создания нового диалекта Lisp, чтобы провести анализ нынешнего положения всех остальных диалектов и их возможно развития. это всего лишь прием автора.
                • НЛО прилетело и опубликовало эту надпись здесь
                    0
                    Статья-перевод вообще-то.
                      0
                      Статья переводная
                      • НЛО прилетело и опубликовало эту надпись здесь
                        0
                        На оригинальном сайте нет возможности комментировать — придётся вам здесь отдуваться за автора. :)
                        +1
                        На Joblist не будет и вакансий на haskell'е, ocaml'е, erlang'е и smalltalk'е. Но при этом за специаллистов на этих языках платят неиллюзорные деньги.
                        0
                        При написании приложений в Cocoa, вы получаете модели, контроллеры, представления, и должны «склеить» их вместе минимальным количеством кода на Objective-C. Таким образом, вы теряете возможность применить все фичи Lisp. Почти каждая строка кода на Nu (навскидку — около 95%) только и будет, что вызывать код Objective-C, что превращает использование Lisp просто в какую-то нелепость.

                        А что, в приложении вообще нет никакой логики и оно просто показывает окошки? И в Cocoa (или как оно там называется в Макоси) нет декларативных методов создания интерфейсов?

                        JVM же предоставляет свободу. Архитектура полностью в ваших руках. Вы сами формируете модель. Уровень представления выбирается в зависимости от типа приложения(серверное, GUI, утилиты командной строки и т.д.). У вас полная свобода от самого начала и до конца.

                        Пожалуйста, расшифруйте. Почему у меня нет полной свободы(?) с руби, питоном или с++ я не могу понять.

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

                        Боже…

                        Впечатление такое, что ребенку дали игрушку, и она в этот миг стала для него самой лучшей, самой прекрасной в мире и он об этом хочет сказать все миру.
                        0
                        А мне мои знания Clojure помогли найти классный проект. Переписал все на Python :) Ибо все было жутко медленно. И разработка. И исполнение. Хотя код был чертовски красив.
                          0
                          Lisp является замечательным семейством языков; его чрезвычайно минималистический синтаксис позволяет нам думать практически на уровне алгоритмов, не заморачиваясь по поводу неочевидного синтаксиса или каких-либо языковых рамок.

                          Конечно тут от задач зависит. Сталкивался плотно с диалектом автокадовским лиспа — аutolisp/visual lisp

                          Страх и ужас. Тот же код на C++ (objectArx) или тем более c# (.Net Api) на порядок очевиднее и легче и понятнее.
                            +5
                            После „Положения на рынке” стало ясно что автор ничего полезного по теме сказать не сможет. CL сейчас более популярен чем Clojure. О последнем просто много говорят. Clojre популярен в том же смысле, что и Scala или Haskell.

                            Здесь автор сначала противоречит сам себе, а потом просто ошибается:
                            > И почему CL и Scheme умерли?

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

                            Дальше не читал.

                            Интересно, кстати, что люди, которые действительно вкладывают время в написание опенсорцных библиотек, реализаций, утилит и т.д. *никогда* не берутся „смотреть в будущее” и судить о существующем положении. От всевозможных же Стивенов Дегутисов и Йегге (тоже Стив, кстати), я никакого вклада кроме болтовни не видел.

                            Меритократия.
                              0
                              нет, Йегге таки много чего делает: js2-mode, например, (правда, для меня он не подошел, но говорят, можно допилить), сейчас работает над дебаггером для Clojure и троллит Рича Хики, чтобы они наконец написали двухпроходный компилятор (http://news.ycombinator.com/item?id=2466731) — а то ж, действительно, стыдно…
                              0
                              Непонятно, почему закопали схему, она же используется как встраиваемый язык.
                                0
                                Потому что схема — не на JVM. Автор оригинала, похоже, просто фанат Java и решил воспеть ей дифирамбы таким вот странным образом. Он вообще всё закопал, кроме Clojure.
                                +2
                                Совершенно непонятно то, зачем статья была написана. О чём она?
                                Минус статье, так как не вижу смысла переводить подобный трэш. Лучше помогите мне перевести по Clojure ресурсы.

                                Кстати, совершенно необоснованные выпады в сторону CL. В чем он плох? Дилетантское заявление «много скобочек», и всё. Так мне лично скобочки нравится, это даже прикольно. Если отлаживаться в нотепаде, то да, неудобно.

                                  +1
                                  «Кстати, совершенно необоснованные выпады в сторону CL.»

                                  это уже не беда скобочек. Вы стандарт гляньте — это уже монстер если и не почище С++, то сравнимо. Решили всерьез садиться на CL? Начинайте отращивать бороду.
                                    +2
                                    Поставил вам плюсег. :)
                                    Стандарт глядел. И это уже более-менее обоснованная претензия, во всяком случае, с намеком на обоснованность — перегруженный стандарт (и вправду перегруженный). Скобочки же это ну совсем не повод рыгать на Лисп.
                                      +1
                                      (и вам тот же зелёный значок)
                                      Поглядывая на Python, J/APL становится ясно, что тема Лиспа по-прежнему толком не расскрыта. Пока лисп — это грозное напоминание как великолепные концепты можно минорно «сливать» на обочину мировой ИТ-движухи.

                                      Жду когда вылезет какой-нибудь гений и скажет я взял PyPy платформу заимплементировал на ней параллельно вычисляемый nano-лисп со спецификацией в три странички и все охренеют от того, что в его лисп-спеке вообще не окажется места ни строкам, ни числам, ни даже идентификаторам, а только скобкам и нескольким знакам припинания. а все остальные символы войдут в приложение «Character bindings recommendations».

                                      В общем, галактико ждёт своих лисп-героев.
                                        0
                                        А каким местом J/APL к Python?
                                          0
                                          лаконичным.
                                      0
                                      Стандарт CL отнюдь не монстр, если учесть, что он описывает и стандартную библиотеку: стандартная библиотека Python что-то в 10 раз больше, кажется…
                                      А так, начинать нужно не с чтения стандарта. ANSI Common Lisp — отличный вводный курс. Или же Practical Common Lisp.
                                        0
                                        «Стандарт CL отнюдь не монстр, если учесть, что он описывает и стандартную библиотеку: стандартная библиотека Python что-то в 10 раз больше, кажется…»

                                        И, казалось бы, странно, что несмотря на кучу недостатков Питона, от него людей за уши не оттащишь. А с CL — зашли, посмотрели, побробовали, повздыхали и… свалили. Или всё же не странно? вместо того, чтобы меня минусовать, лучше бы объективно взглянуть на реаль, выводы сделать. Чего со мной воевать-то?

                                        «А так, начинать нужно не с чтения стандарта. ANSI Common Lisp — отличный вводный курс. Или же Practical Common Lisp.»

                                        а это уж извините, кому как. По моему опыту, мало кто до стандарта вообще добирается. А потом язык от реализации языка не отличает и после 10 программирования…
                                          0
                                          «И, казалось бы, странно, что несмотря на кучу недостатков Питона ...»
                                          Я разве говорил, что это недостаток? Я о том, что «монструозность» стандарта CL — миф: никто ж не жалуется на «монтруозность» стандарта Питона, так ведь? Собственно, я про «объективный взгляд на реаль».

                                          «И, казалось бы, странно, что несмотря на кучу недостатков Питона, от него людей за уши не оттащишь. А с CL — зашли, посмотрели, побробовали, повздыхали и… свалили.»
                                          К Питону никаких претензий — сам пользуюсь. Но меня, например, как раз от CL за уши не оттащищь. Возможно, дело в разном устройстве мозгов (я серьезно).

                                          Вообще говоря, претензия только к одному всегда: про Lisp любят распространять кучу разного FUD'а. Например, «стандарт — монстр» (надеюсь, доказал уже, что это не так), «библиотек — нет», «скобки съедят ваш мозг» и т.д. Не распространяте FUD! ;)
                                            0
                                            1. Друзья, для тех, кто не в теме. Хотите узнать на какой странице Common Lisp стандарта (CLTL2) находятся массивы (Arrays) или скажем строковые литералы (Strings)? Не-е-е-т, я вам не скажу. Ваши ставки в студию! Vseloved вы ведь наверное быстрее других ответите? ;)

                                            2. удобное место посмотреть на лаконичность разных языков, например, тут:
                                            rosettacode.org/wiki/Sorting_algorithms/Quicksort#Common_Lisp

                                            и после этого уже можно тушить ненужные споры по очевидным вопросам.

                                            3. а касательно длин стандартов базового языка (без библиотек) моё мнение таково:

                                            3 стр — мечта.
                                            ~10 стр — коротко, здорово!
                                            ~20 стр — нормально, потянет.
                                            ~40 стр — много!
                                            более 50? — монстр!

                                              0
                                              Ну, вот видите, не зря я вас заминусовал ;)

                                              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, и это пока известный мне мимнимум) + описание базовых типов. Всё остальное (функции, макросы) можно считать стандартной библиотекой.
                                                0
                                                ANSI Common Lisp — de facto standard or de jure? такие вот дела.

                                                NRN.
                                          0
                                          Помните в детстве как вы ломали мозг над ООП в C++/Java и указателями в C? Вот теперь взрослым дядям не хочется ломать мозг ещё раз над рестартами, замыканиями (кто с ФП не встречался) и синтаксическими макросами. По крайней мере виденные мной вздохи с сваливания были обусловлены именно этим: „Там всё то же что и в Java, плюс ещё пара непонятных ненужных фич”. Всё как в Blub Paradox Грема.
                                            0
                                            lazy evaluation, continuations, closures — всё наше. не надо гнать на стариков, они надежда наша и support.
                                              0
                                              Моя выборка — вчерашние студенты, усиленно работающие за еду.
                                    0
                                    раздули Scheme. Можно заново создавать.
                                    • НЛО прилетело и опубликовало эту надпись здесь
                                        0
                                        Прямая ссылка на сайт автора: degutis.org. Его другие статьи по лиспу тоже интересно почитать.
                                          0
                                          > В конце концов, эти два языка стали довольно успешными, не так ли?
                                          Заметил, что вот так вот игнорируют Perl, прообраз Ruby, и в некотором смысле Python. Ведь тоже вполне успешный язык, и еще используется, на нем полно рабочих проектов и прикладных библиотек.
                                          Кстати недвано Maц сказал нечто следующее: «Если б я увидел современный Perl — я бы не стал создавать Ruby»

                                          А так статья занятная, давно уже хочется clojure поковырять.

                                          Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.

                                          Самое читаемое