Чому Лісп не є більш поширеним? [зачинено]

Я починаю вивчати схему за допомогою відеороликів SICP, і я хотів би перейти до Common Lisp далі.

Мова здається дуже цікавою, і більшість людей, які пишуть на ній книги, вважають, що вона має неперевершену виражальну силу. Здається, CL має гідну стандартну бібліотеку.

Чому Лісп не є більш поширеним? Якщо він дійсно настільки потужний, люди повинні користуватися ним у всьому світі, але натомість знайти, скажімо, службу оголошень Lisp майже неможливо.

Я сподіваюся, що це не просто дужки, оскільки вони не є великою проблемою через деякий час.

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

Крім того, легко зловживати експресивними мовами. Досвідчений програміст Java може швидко переробити погано записаний код. Чим виразнішою стає мова, тим важче стає розуміння та перероблення жахливого коду. Макроси LISP - хороший приклад. Макроси - це потужний інструмент у правих руках. У чужих руках вони можуть призвести до заплутаного і важкого налагодження коду.

LISP - ризикований вибір для вищого керівництва. Якщо все піде не так, ніхто не буде звинувачувати управління у виборі популярної об'єктно-орієнтованої мови, що підтримується великою корпорацією, наприклад Oracle або Microsoft. Набагато простіше наймати програмістів, які мають досвід популярних, легких для вивчення мов.

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

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

Незважаючи на все це, я сподіваюся ...

Clojure має шанс стати популярним. Він працює на JVM, чудово взаємодіє з Java, і робить одночасне програмування набагато простішим. Це все важливі речі для багатьох компаній.

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

Чому Лісп не є більш поширеним? Якщо вона справді така потужна, люди повинні її використовувати всюди,

Якщо ви вважаєте, що мови обрані за своїми технічними достоїнствами, вас чекає розчарування душі.

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

але натомість знайти, скажімо, рекламу вакансій Lisp майже неможливо.

Як не дивно, компанії 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. Здавалося, це правильно зробити. Я почав читати Практичний звичайний Lisp як стрибок, оскільки я справді не знав вбудованих функцій і мені потрібен проект, над яким працюватимуть у Lisp. S-вирази були красивими і легкими. Усі ці дужки були неймовірно вразливими для мене, оскільки в день було зрозуміло, що саме відбувається в коді.

Тому я намагаюся написати свою першу програму в Ліспі поза книгою. Я хотів інструмент командного рядка, який би рахував рядки коду та видаляв тривіальні рядки з числа кодів. Не найкорисніший інструмент, але цікаво зробити. Він передбачає доступ до файлів, трохи розбору та підрахунку. Я застосував той самий інструмент у Python приблизно тижнем раніше.

Мені потрібно отримати доступ до аргументів командного рядка. Тоді я дізнаюся, що немає стандартного способу отримання аргументів командного рядка. Всі вони нестандартні функції. Це зовсім не крос-платформа. Це здебільшого просто погіршується звідси, оскільки мова не має вбудованої в нього багато бібліотек. Я перейшов на Haskell і не потрапив дуже далеко до Common Lisp (тому мої скарги можуть бути навіть неправдивими).

Така нестандартна річ завжди була для мене болем у минулому. У C ++ є така ж проблема, але з такими слабкими бібліотеками, як Boost, ви можете подолати.

Також не допомагає, що синтаксис Lisp для всього іншого, крім S-виразів, трохи некрасивий.

IMO, в основному це пов'язано з:

• Погана підтримка бібліотеки. Звичайно, зараз є Quicklisp, що дозволяє легко встановлювати бібліотеки, але це не компенсує їх, як і раніше, досить мало, і досить багато погано документовані або не дуже добре підтримуються. Порівняно з Python, є велика ймовірність, що написання нетривіальної програми Lisp (незалежно від конкретного діалекту), ймовірно, все ще потребуватиме винахід принаймні частини колеса чи двох.
• Відсутність ознайомлення з моделлю, прийнятою інструментами розробки. Більшість людей, яких я знаю, досить залякані тим, що користуються SLIME та Emacs, що зрозуміло для людей, які звикли до Eclipse та Visual Studio. Є два плагіни Eclipse, я думаю, я спробував лише один з них кілька років тому, і це було досить баггі. Вся екосистема Lisp виглядає так, що вона застрягла на півдорозі між тими днями, коли вона була частиною повноцінної системи Lisp, що працює і сучасним стандартом oh-it-other-language. Вивчення Lisp не обмежується вивченням нової мови - вам також потрібно вивчити зовсім інший спосіб роботи та мислення, і хоча це нормально, якщо ви робите це як хобі, сумнівно, чи варто це робити в бізнес.

Речі починають виглядати трохи краще, особливо з Clojure, який знаходиться поруч.

Я дізнався LISP мільярд років тому в коледжі.

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

LISP стосується вкладеної функціональності, і люди просто так не думають. Вони думають з точки зору DO A, B, C, D, тоді E. Not do A, що передбачає виконання B і C, тоді D і E. Це пов'язане з певною сукупністю, яка заплутує. За винятком заздалегідь визначених завдань, таких як "подати декларацію з податку на прибуток", люди не думають одночасно, вони думають послідовно. Ось чому сьогодні домінуючи процедурні мови.

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

Так що це чудово для вирішення проблем, але вирішення проблем не дуже важливо в програмуванні. Введення даних, валідація, форматування вихідних даних, на які LISP був надзвичайно слабким.

Я думаю, що одна з проблем з Lisp ще не згадується в тому, що для посереднього або початківця програміста (як я, я вільно визнаю), може бути складно зрозуміти, як ти перетворюєш код Lisp у велику програму. Це легко писати, але важко архітектору. Я не думаю, що жодна з концепцій не є особливо складною, але менталітет "Зроби сам" настільки сильний, що я часто відчуваю себе з втрати, де навіть почати.

З мовою OOP, на зразок Java або C #, ви можете використовувати систему типів, щоб активізувати себе до робочої моделі та створити її. З Lisp (або Lua, або Javascript, з цього приводу) існує таке поняття, що ви можете вийти і робити це будь-яким способом. Якщо ви хочете OOP, просто зробіть власну систему OOP! Окрім створення власного ООП чи навчання чужого, це новий бар’єр на вершині мови перед тим, як отримати зручні програми. Плюс, я завжди відчуваю, що ООП у Ліспі чи Луї насправді немає, як я міг би просто проігнорувати це, якщо дуже хотів, тож у чому сенс?

Коротше кажучи, я думаю, що програмування в Ліспі вимагає великої дисципліни, і це дуже важко підійти. Мови з сильним типом та мови OOP пропонують певну дисципліну, тому програміст може зосередити свої обмежені запаси на доопрацюванні проектів, а не на мові.

EDIT: Як аналогія, яка мене просто вразила, це як якщо вам потрібно виконати деякі роботи по дереву, і двоє людей пропонують вам свої ящики для інструментів. Інструменти однієї людини є начебто крихтими, але в основному можна буде виконати роботу, доклавши трохи зусиль. Інша людина має велику частину деталей, але обіцяє, що ви можете комбінувати ці деталі, щоб зробити найкращі інструменти, які ви коли-небудь використовували, ідеально підходять для вашої зчеплення та найкращої якості. Ви просто повинні спочатку їх побудувати.

Я довго дивився на те саме, і навіть ходив на конференції в Ліспі, щоб спробувати зрозуміти, що це за «темна сторона» Ліспа, яка заважає всім його прийняти.

Я не знайшов повної гідної відповіді.

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

Єдине часткове пояснення, яке я придумав, - це те, що більшість чудових ідей Lisp зараз є звичайною справою, єдине дійсно важливе, що відсутнє (надзвичайно важливий IMO) - це простота метапрограмування.

На жаль, я не бачу простого способу адсорбувати цю концепцію для інших мов, тому що метапрограмування є гарним вимагає гомоніконічної та регулярної мови (я кажу про загальну метапрограмування, а не про скинуту версію лише для шаблонів). Іншими словами, він в основному вимагає підходу Ліспа до синтаксису: код - це дані, а дані - код. Введення коду на багатій синтаксисом мові, що маніпулює 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, хости або не дозволяють, або не роблять це легко, і тому що це не просто, мало людей використай це. Але насправді запуск Lisp на хості може бути простішим, ніж ви можете подумати, навіть якщо це вимагає трохи більше роботи, ніж їх позашляховий PHP-сервіс. Нещодавно я отримав лукавство додатків Scheme , що працюють тут тільки з невеликим зусиллям.

ІМО, це здебільшого питання поганих термінів: Лісп був старим (і майже за визначенням вже не захоплюючим) задовго до того, як він став практичним для більшості людей або використання. Clojure (для одного прикладу) має набагато кращі шанси. Його успіх буде набагато більше залежати від сприйняття як нового, модного та крутого, ніж будь-що таке практичне, як взаємодія з Java (і все інше, що працює на JVM).