Это перевод статьи Стивена Дегутиса.
Будущее 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, и останется таковым в обозримом будущем.
Будущее 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, и останется таковым в обозримом будущем.