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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

У меня нет опыта работы в реальной компании, но я знаю, почему мне было трудно использовать 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-выражений, немного уродлив.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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