Почему Лисп не получил более широкого распространения? [закрыто]

50

Я начинаю изучать Scheme с видео SICP, и я хотел бы перейти к Common Lisp дальше.

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

Почему Лисп не получил более широкого распространения? Если он действительно настолько силен, люди должны использовать его повсюду, но вместо этого почти невозможно найти, скажем, объявления о работе на Лиспе.

Я надеюсь, что это не просто скобки, так как через некоторое время они не станут большой проблемой.

Andrea
источник
3
xkcd2.heroku.com/297
Мишель Тилли
5
Steel Bank (обычный) LISP на самом деле более популярен, чем вы можете себе представить. Подобные LISP макропроцессоры (например, M4) также широко используются. Вы можете не видеть его в выбранной вами области, но он все еще существует (к лучшему или к худшему).
Тим Пост
8
Недавнее землетрясение и цунами уничтожили заводские скобки в Японии. :-(
oosterwal
1
Какую версию Lisp нам следует использовать? Помните, диалекты Лисп более или менее несовместимы.
2
LISP (или диалектов) используются повсеместно , например , AutoLISP диалект LISP используется Autocad en.wikipedia.org/wiki/AutoLISP или EMACS en.wikipedia.org/wiki/Emacs_Lisp
Jaydee

Ответы:

69

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

Кроме того, легко злоупотреблять выразительными языками. Опытный Java-программист может быстро рефакторировать плохо написанный код. Чем выразительнее язык, тем сложнее становится понимание и рефакторинг ужасного кода. Макросы LISP являются хорошим примером. Макросы - это мощный инструмент в правильных руках. В чужие руки, они могут привести к путанице и трудно отладить код.

LISP - рискованный выбор для высшего руководства. Если что-то пойдет не так, никто не будет обвинять руководство в выборе популярного объектно-ориентированного языка, поддерживаемого крупной корпорацией, такой как Oracle или Microsoft. Гораздо проще нанимать программистов с опытом работы на популярных, легко изучаемых языках.

Даже прогрессивные компании, желающие использовать более мощный язык, обычно не выбирают LISP. Это связано с тем, что многие новые языки пытаются найти компромисс, заимствуя мощные функции LISP, оставаясь легкими в освоении для масс. Скала и Руби следуют этой модели. Плохие программисты могут быстро их найти и продолжать писать тот же посредственный код, что и в Java. Хорошие программисты могут воспользоваться более продвинутыми функциями для написания прекрасного кода.

Скобки не проблема. Haskell - невероятно мощный и выразительный язык с синтаксисом, похожим на Python или Ruby, и он не получил широкого распространения по многим из тех же причин, что и LISP.

Несмотря на все это, я надеюсь ...

Clojure имеет шанс стать популярным. Он работает на JVM, отлично взаимодействует с Java и значительно упрощает параллельное программирование. Это все важные вещи для многих компаний.

* Это мой взгляд как профессионального программиста JVM с опытом работы с Java, Clojure, JRuby и Scala.

Дбырне
источник
25
Возражение против сложности поиска квалифицированных программистов - это что-то вроде собаки, гонящейся за хвостом. Если бы Lisp был более распространенным, было бы легче найти хороших программистов.
Андреа
3
@ Андреа Это определенно правда. Тем не менее, его труднее выучить, что еще больше усугубляет проблему. Я понимаю, что это может быть противоречивым мнением, так как многие профессора преподают схему как родной язык.
dbyrne
9
Да, APL - отличный пример выразительного языка. Кроме того, хороший пример того, почему выразительность не самая важная вещь;)
dbyrne
9
Я не думаю, что это определение на самом деле передает то, что означает выразительное. Лично, прежде чем я буду называть язык выразительным, я должен убедиться, что я могу читать то, что я написал. Например, использование нетривиальной логики в инициализаторе цикла в C может сэкономить вам несколько строк кода, но это не совсем понятно. С другой стороны, понимание списка в Python может сохранить пару строк и быть более читабельным. Таким образом, вы действительно нашли способ выразить то, что вы имели в виду, более кратко. Если он не читается, вы вообще не можете ничего выразить.
Андреа
3
Я думаю, может быть, я выхожу как тот, кто не любит шутки. По правде говоря, я люблю это. Clojure - невероятный язык. Я думаю, что это очень жизнеспособный выбор для использования определенной компанией. Я просто отмечаю, что есть много компаний, в которых это не имеет смысла, и использование чего-то вроде Scala - гораздо более практичный выбор.
dbyrne
17

Почему Лисп не получил более широкого распространения? Если это действительно так сильно, люди должны использовать его повсюду,

Если вы считаете, что языки выбраны из-за их технических достоинств, вас ждет душераздирающее разочарование.

Такие решения принимаются на основе стрипперов и стейков . Microsoft может себе это позволить. Оракул может. Sun потратила столько денег, раскручивая Java, что обанкротилась. Дважды. Децентрализованное, гетерогенное, добровольное сообщество не может конкурировать с этим.

но вместо этого почти невозможно найти, скажем, объявления о работе на Лиспе.

Как ни странно, компании Lisp говорят прямо противоположное: у них постоянно есть вакансии, но они не могут найти достаточно людей, чтобы заполнить их. (То же самое относится к Haskell, ML, O'Caml, Forth, Smalltalk, ...)

Йорг Миттаг
источник
3
Где я живу (Италия) Я сомневаюсь, что существует хотя бы одна компания на Лиспе ...
Andrea
1
Какие крупные компании продвигают Ruby, Python и JavaScript? JS - это, по общему признанию, особый случай, но другие два кажутся достаточно популярными без массивной поддержки со стороны корпораций и вендоров
Бен Хьюз
Да, это верно и для других языков. У большинства хороших кодеров COBOL уже есть работа, и они все равно не читают рекламу. Зачем беспокоиться о рекламе?
Бо Перссон
Что на самом деле? Я буду писать код на любом языке, который не является мейнстримом, хотя Хаскелл звучит у меня над головой. Небольшой объем кода, который я кодировал в нем, чрезвычайно красив, но без хорошего наставника я понятия не имею, когда использовать каждую монаду и аппликативные функторы.
aoeu256
9

У меня нет опыта работы в реальной компании, но я знаю, почему мне было трудно использовать LISP.

Прежде всего, это напоминает мне об этом сообщении в блоге: http://steve-yegge.blogspot.com/2006/04/lisp-is-not-acceptable-lisp.html

Основная проблема, с которой я сталкиваюсь с Лиспом, это вопрос "какой Лисп". Я обычно работаю на Linux в качестве основной платформы, но вещи, которые я делаю, должны быть совместимы с Windows. Это означает, что когда я оцениваю используемую технологию, она должна облегчить мою жизнь при работе с двумя радикально разными операционными системами. Мне не нравится это требование, но использовать его в реальном проекте - это требование. Теперь я буду использовать языки, которые не имеют очень хорошей поддержки в Windows, для моих собственных личных побочных проектов, но, поскольку у меня никогда не было возможности написать в них большой программный проект, у меня нет необходимого опыта.

Теперь, когда я пытался выучить функциональный язык, я действительно хотел выучить Common Lisp. Казалось, что это правильно. Я начал читать Practical Common Lisp как отправную точку, поскольку я действительно не знал встроенных функций и мне нужен был проект для работы в Lisp. S-выражения были красивыми и легкими. Все эти круглые скобки были невероятно красивы для меня, поскольку было ясно, как точно, что происходило в коде.

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

Мне нужно получить доступ к аргументам командной строки. Затем я узнаю, что нет стандартного способа получить аргументы командной строки. Все они нестандартные функции. Это не кроссплатформенность вообще. В основном это только ухудшается, поскольку в язык не встроено много библиотек. В итоге я переключился на Haskell и не очень углубился в Common Lisp (так что мои жалобы могут даже не быть действительными).

Такая нестандартная вещь всегда была для меня болью в прошлом. C ++ имеет ту же проблему, но с такими библиотеками, как Boost, вы можете обойти эти недостатки.

Также не помогает то, что синтаксис Lisp для всего, кроме S-выражений, немного уродлив.

jsternberg
источник
1
PLT Racket (ранее PLT Scheme) хорошо работает как в Linux, так и в Windows.
Ларри Коулман
Интересно, что я ожидаю, что Common Lisp будет гораздо более стандартным и удобным для реальных приложений, чем Scheme. (Я сейчас читаю Практический Общий Лисп.)
Джорджио
Я рекомендую вам выбрать Haskell (который, на мой взгляд, является лучшим языком), но как насчет Clojure? Он работает на JVM, поэтому он должен быть переносимым и иметь доступ ко всем необходимым библиотекам.
Андрес Ф.
Аргументы командной строки сложно использовать в C ++? В самом деле?
Ник Кейли,
Разве не тривиально построить кросс-компилятор, который меняет Lisp на Scheme на Clojure? Почему люди не используют их?
aoeu256
8

ИМО, в основном это связано с:

  • Плохая поддержка библиотеки. Конечно, теперь есть Quicklisp, который облегчает установку библиотек, но он не компенсирует, что их все еще довольно мало, и многие из них плохо документированы или не очень хорошо поддерживаются. По сравнению с Python, есть хороший шанс, что написание нетривиального приложения на Лиспе (независимо от конкретного диалекта), вероятно, все же будет связано с переизобретением хотя бы части колеса или двух.
  • Недостаток знакомства с моделью, принятой инструментами разработки. Большинство моих знакомых довольно напуганы необходимостью использовать SLIME и Emacs, что понятно для людей, привыкших к Eclipse и Visual Studio. Думаю, есть два плагина Eclipse, я попробовал один из них несколько лет назад, и он был довольно глючным. Вся экосистема Лиспа выглядит так, как будто она застряла на полпути между днями, когда она была частью полноценной системы, работающей на Лиспе, и современным стандартом «ой-это-другой-язык». Изучение Lisp не ограничивается изучением нового языка - вам также нужно выучить совершенно другой способ работы и мышления, и хотя это нормально, если вы занимаетесь этим как хобби, сомнительно, стоит ли это делать в бизнес.

Вещи начинают выглядеть немного лучше, особенно с Clojure.

donkey_lz
источник
1
«Большинство людей, которых я знаю, довольно напуганы необходимостью использовать SLIME и Emacs, что понятно для людей, привыкших к Eclipse и Visual Studio.»: Снова и снова я чувствую, что Лисп предназначен для элиты.
Джорджио
2
«Вам также необходимо научиться совершенно другому способу работы и мышления, и хотя это нормально, если вы занимаетесь этим как хобби, сомнительно, стоит ли это делать в бизнесе». достаточно веская причина?
Джорджио
Была ли продемонстрирована эта «повышенная производительность»? Это, конечно, не ясно для меня (да, я запрограммирован на диалекте Lisp). Там нет серебряных пуль.
Ник Кейли,
5

Я изучал LISP миллиард лет назад в колледже.

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

LISP - это вложенная функциональность, и люди просто так не думают. Они думают с точки зрения DO A, B, C, D, а затем E. Не делайте A, что включает в себя выполнение B и C, затем D и E. Это предполагает своего рода параллелизм, который сбивает с толку. За исключением предопределенных задач, таких как «заполнение декларации о доходах», люди не думают одновременно, они думают последовательно. Вот почему процедурные языки доминируют сегодня.

В результате производственный код, такой как Java и C, может быть легко переведен на английский. Код LISP не может; ни один человеческий язык не структурирован таким образом.

Так что это здорово для решения проблем, но решение проблем не очень важно в программировании. Ввод данных, валидация, форматирование выходных данных - все это было очень слабо.

Энди Кэнфилд
источник
7
Решение проблем - это все, что мы делаем. Манипулировать данными нелегко в Java или C. Манипулирование данными в cons-ячейках намного проще в Лиспе и других функциональных языках. Большинство операций с данными одинаковы, и не важно, в каком порядке вы их обрабатываете. Это легко сделать с помощью вызова map и указателя на функцию. Я также сказал бы, что легче думать о вложенной функциональности, чем о процедурной функциональности (так как одна детализирует вашу цель, а другая - как выполнить указанную цель), но у меня нет никаких доказательств этого. В любом случае, я бы не сказал, что по этой причине LISP не используется.
Йтернберг
4
Программирование не о решении проблем? Я так не думаю. И, кстати, я не думаю, что ты можешь изучать язык и в колледже.
Адам Арольд
+1, звучит очень правдоподобно для меня, кто не знает Лисп. Я бы сказал, что C / Java лучше, чем Python, для решений корпоративного масштаба.
Йонас Быстрем
Пока это единственный ответ, который поднял огромную тему функциональности против процедурных, но давайте не будем забывать, что процедурное мышление имеет тенденцию любить возиться с глобусами данных в переменных везде, где вы можете прикоснуться из многих мест и потоков, создавая проблемы синхронизации. Функционал не страдает так быстро, хорошо написанный функционал не страдает вообще.
maxpolk
1
Однажды программист спросил меня, как лучше выразить цикл for с помощью диаграммы потока данных. Для таких людей нет никакого смысла в непроцедурных языках. Думаю , в FORTRAN.
Ник Кейли,
5

Я думаю, что одна проблема с Lisp, которая еще не упоминалась, состоит в том, что для посредственного или начинающего программиста (как я, я свободно признаю), может быть трудно понять, как вы превращаете код на Lisp в большую программу. Это легко написать, но трудно для архитектора. Я не думаю, что какие-либо концепции особенно сложны, но менталитет «сделай сам» настолько силен, что я часто теряюсь, с чего начать.

С помощью языка ООП, такого как Java или C #, вы можете использовать систему типов, чтобы подняться до рабочей модели и построить ее. С Лиспом (или Lua, или Javascript, если на то пошло) есть такое понятие, что вы можете выходить и делать это любым удобным для вас способом. Если вы хотите ООП, просто создайте свою собственную систему ООП! За исключением того, что вы создаете свой собственный ООП или изучаете чужой, это новый барьер на вершине языка, прежде чем вы получите полезные программы. Кроме того, я всегда чувствую, что ООП в Лиспе или Lua на самом деле не существует, как будто я мог просто проигнорировать это, если бы я действительно хотел, так какой смысл?

Короче говоря, я думаю, что программирование на Лиспе требует большой дисциплины, и это очень трудно найти. Языки со строгой типизацией и языки ООП предлагают своего рода встроенную дисциплину, поэтому программист может сосредоточить свои ограниченные резервы на завершении проектов, а не на настройке языка.

РЕДАКТИРОВАТЬ: Как аналогия, которая просто поразила меня, это как если бы вам нужно было сделать некоторые деревянные работы, и два человека предлагают вам свои ящики для инструментов. Инструменты одного человека в некотором роде отвратительны, но в основном они выполняются с небольшими усилиями. У другого человека есть большая корзина с деталями, но он обещает, что вы можете комбинировать эти части, чтобы сделать лучшие инструменты, которые вы когда-либо использовали, идеально подходящие для вашей руки и наилучшего качества. Вы просто должны построить их в первую очередь.

CodexArcanum
источник
2
Common Lisp, по крайней мере, явно является языком OO: Common Lisp Object System является частью стандарта.
Фрэнк Ширар
Да, и, насколько я понимаю, он очень мощный, но мне кажется, что это особенность языка. Это не то же самое, что Java, где нужно понимать объекты с первого дня. Практический Common Lisp не затрагивает CLOS до главы 16. Возможно, я просто склонен к статической типизации, хотя мне не нравятся языки с динамической типизацией. ,
CodexArcanum
Lisp позволяет вам использовать замыкания (let-over-lambda) вместо объектов для облегченного ООП, но я считаю, что его легко обновить, чтобы использовать ООП через CLOS.
aoeu256
2

Я долго размышлял над этим и даже ходил на конференции по Лиспу, чтобы попытаться понять, что это за «темная сторона» Лиспа, которая мешает всем принять его.

Я не нашел полного приличного ответа.

Невежество может быть причиной недостающей популярности, но меня больше удивляет то, что даже тот, кто наверняка знает о Лиспе (например, Google - у них работает Питер Норвиг), не использует его.

Единственное частичное объяснение, которое я придумываю, состоит в том, что большинство великих идей на Лиспе стали обычным явлением, единственная действительно важная пропущенная идея (чрезвычайно важная IMO) - это простота метапрограммирования.

К сожалению, я не вижу простого способа адсорбировать эту концепцию для других языков, потому что для хорошего метапрограммирования требуется гомоиконичный и регулярный язык (я говорю об общем метапрограммировании, а не о простой версии только для шаблонов). Другими словами, это в основном требует подхода Lisp к синтаксису: код - это данные, а данные - это код. Написание кода на языке с богатым синтаксисом, который манипулирует AST, сложнее, потому что вам нужно знать два языка: как писать код и как писать AST. Это особенно сложно, если ваш AST является фиксированным, а также сложным и нерегулярным с большим количеством различных типов узлов. Вместо этого Lisp имеет достаточно регулярный (и расширяемый!) AST, и вы уже обычно пишете код, напрямую записывая AST.

Метапрограммирование также по своей природе более сложное (и метапрограммирование даже больше и так далее), и большинство программистов и менеджеров, очевидно, просто предпочитают ответ «никому не понадобится».

Мне особенно грустно, что такие «новые» языки, как, например, goзаканчивали тем, что использовали текстовое метапрограммирование, когда это необходимо (генераторы внешнего кода, пишущие текстовые файлы) и «магию» (то есть компилятор может делать то, что не могут делать программисты).

Я думаю, что решением проблемы сложности являются мощные инструменты и образование. Тенденция, видимо, вместо тупых инструментов и притворяется, что проблемы нет.

6502
источник
+1 за «Я думаю, что решением проблемы сложности являются мощные инструменты и образование».
Джорджио
после 50 лет оправдание «невежества» носит довольно худой характер
Ник Кейли
1
@NickKeighley: зависит. Даже сегодня большинство программистов ничего не знают о Лиспе (например, в большинстве случаев Лисп описывают как функциональный язык). Даже среди тех, кто «знает» Лисп, почти никто никогда не видел идею макроса с достаточной детализацией (я не говорю о неконтролируемой версии схемы, но о полной алгоритмической мощи и удобстве квази-цитирования, когда это подходит лучше).
6502
@ 6502: IMO Lisp, хотя он и не является чисто функциональным, поддерживает функциональное программирование гораздо лучше, чем многие основные языки, такие как C #, Java, C ++ и т. Д. Для многих программистов FP означает время от времени просто использовать лямбда-выражения: эти программисты не пропустят Lisp, Clojure или Haskell. Поэтому я хотел бы добавить: (1) Lisp поддерживает FP довольно хорошо, и функциональные программисты извлекут из этого пользу, но (2) незнание FP и его преимуществ является одной из причин, по которой Lisp не используется чаще.
Джорджио
1
@ 6502: Наличие списков в качестве базовой структуры данных и обычных функций высокого порядка в списках также является функцией, отсутствующей в Javascript. И, насколько я помню, у Javascript также есть выражение / выражение двойственности. Я бы определенно поместил Lisp (Common Lisp) на несколько шагов дальше в направлении FP, чем Javascript или Python. Под этим я не подразумеваю, что Common Lisp является чисто функциональным языком, я согласен с тем, что он мультипарадигмальный, но он поддерживает FP намного лучше, чем другие мультипарадигмальные языки.
Джорджио
1

Кажется, что даже CL не имеет очень хорошей поддержки библиотеки. По крайней мере, по словам людей, которые перешли с Lisp на Python:

http://www.redmountainsw.com/wordpress/archives/reddit-switches-from-lisp-to-python

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

Неманья Трифунович
источник
2
Это больше не правда. Quicklisp решил эту проблему.
2
Стоит также упомянуть, что с CFFI любая библиотека C может использоваться из Common Lisp. CFFI хорошо документирован и работает хорошо. С другой стороны, если потратить несколько часов на написание оболочек для функций на языке C сильно повлияет на ваш проект, Lisp, вероятно, в любом случае не будет правильным выбором.
Ларри Коулман
Я сделал нетривиальный проект в Scheme и знаю компанию, которая использует Scheme (Chicken Scheme) для нескольких продуктов.
Джорджио
1

Быть могущественным не обязательно подразумевает широкое использование. Вы слышали о термине «Оптимизировать для общего случая»? К сожалению, как многие говорили раньше посредственности, если быть уверенным, что это намного лучше для людей, чем большие хиты со многими неудачами между ними.

Это касается не только LISP, но и множества технологий. Хорошее знакомство с инструментами обработки текста Unix, awk, sed, perl может сэкономить вам дни программирования. К сожалению, я видел, как люди занимали дни, выполняя подобные задачи в других инструментах плохо, что могло бы сделать эти инструменты более эффективно в считанные минуты. Но если человек проведет всю свою жизнь в затмении, он никогда не сможет оценить ценность этих вещей. Вы можете написать огромную программу с удобочитаемостью и удобством сопровождения, и все такое, но в чем смысл написания такой программы, хотя она не написана, и это легко могло бы сделать эту работу.

Еще один аспект при проектировании инструментов в наши дни, насколько они полезны из коробки, чтобы использовать их напрямую для решения проблемы. Вы не можете создать что-то слишком общее, а затем сказать, что вы будете хеджировать все это через библиотеки и фреймворки. Это немного сложно сделать таким образом. Хороший инструмент хорошо сочетается с окружающей средой и проблемами вокруг нее. Вот почему такие инструменты, как php, perl и awk, продолжают оставаться актуальными, несмотря на бесконечные троллинг и бэширование, потому что они слишком полезны, чтобы их выбрасывать, и часто они выполняют большую работу, чем обычный язык со многими библиотеками и фреймворками.

Точно так же вы увидите, что такие языки, как Java / Python, очень хороши, и я бы сказал, что лучше всего подходит для определенных задач. Python особенно хорош и прост в изучении и написании. Также эти языки действительно хороши, если ваши конечные точки данных стандартны. Какая-то база данных, XML или данные такого рода. В основном структурированные данные.

Лисп будет там вокруг долгое время, но не обязательно широко распространенный. Как вы увидите, у каждого инструмента есть своя ниша. И они решают определенный набор проблем очень хорошо из коробки. Я думаю и уверен, что LISP хорошо справляется с задачами и задачами, для решения которых он предназначен.

Kamaal
источник
+1 за цитирование принципа «Оптимизировать для общего случая».
Джорджио
Да, но замыкания LISP - это оптимизация для общего случая объектов. Также мне было интересно, вносит ли кто-нибудь изменения в свою базу кода LISP, рассматривая ее как дерево и выполняя запросы к нему, как JQuery для HTML.
aoeu256
1

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

gcbenison
источник
0

ИМО, в основном это проблема плохого времени: Лисп был стар (и почти по определению больше не интересен) задолго до того, как он стал практичным для большинства людей или пользователей. Clojure (для одного примера) имеет гораздо больше шансов. Его успех будет во многом зависеть от того, будет ли он восприниматься как новый, модный и крутой, чем что-либо более практичное, чем взаимодействие с Java (и всем остальным, что работает на JVM).

Джерри Гроб
источник