Вы бы использовали (диалект) LISP для реального применения? Где и почему? [закрыто]

LISP (и такие диалекты, как Scheme, Common LISP и Clojure) не получили большой поддержки в отрасли, даже несмотря на то, что они являются довольно приличными языками программирования. (На данный момент кажется, что они набирают обороты).

Теперь, это не имеет прямого отношения к вопросу, который вы бы использовали диалект LISP для производственной программы? Что за программа и почему? Использование такого рода интеграции в некоторый другой код (например, C) также включены, но обратите внимание, что это то, что вы имеете в виду в своем ответе. Широкие концепции предпочтительны, но конкретные приложения также являются нормальными.

Вы бы использовали диалект LISP для производственной программы?

Абсолютно

Что за программа и почему?

Лисп - это динамический язык общего назначения. Сегодня он имеет те же основные трудности, что и другие динамические языки общего назначения, которые не публикуются Microsoft: собственные потоки, интеграция с графическим интерфейсом, детерминированная работа GC и небольшие объемы памяти.

Я полагаю, что нативные потоки создаются LispWorks и SBCL. Возможно, другие? Я не исследовал полностью.

LispWorks и Franz Common Lisp - коммерческие продукты - интегрируются в GUI до определенной степени успеха. Не имея $$, чтобы купить их, я не знаю, насколько хорошо это работает. Я подозреваю, что они работают довольно хорошо ...

Можно выполнить детерминированную операцию GC (это делается в Java с некоторым уровнем успеха), но я не знаю, есть ли в существующих системах Lisp (поддерживаемых) какой-либо код для этого.

Я полагаю, небольшой след памяти достигается некоторыми Лиспами.

Суть в том, что Common Lisp технически готов к созданию производственных систем. И это так .

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

Лично я хотел бы создать полноценную производственную систему в Common Lisp с нуля в командной среде.

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

В моем опыте с Лиспом - не значительным, но значительно большим, чем «Привет, мир» - я обнаружил, что этот язык чрезвычайно полезен после первых болей «Argh new language». Большая часть языка соединяется в очень регулярной и довольно очевидной манере, которую я не нахожу, чтобы другие языки работали как. Частично это слияние выражений и заявлений. Часть этого - основной тип данных списка. Частью этого является система типов. Часть этого - макросистема. Не поймите меня неправильно, хотя, есть болевые точки. Но они не бьют меня по лицу так сильно, как болевые точки других языков.

Одним из упрощенных примеров является процедура длины списка Python. Подход Python заключается в вызове len(mysequence). Но, если мы думаем об этом, длина является свойством последовательности. Итак, mysequence.len()это более подходящая идея. Лисп по существу устраняет это синтаксическое различие. (length thing)это и синтаксис вызова функции и синтаксис метода. Конечно, некоторые люди расстраиваются и хотят синтаксической разницы. Я предпочел бы иметь регулярность.

edit2: я преобразовал часть моей MS диссертации, которая работает на рабочем столе, в Common Lisp, и с ним было приятно работать до сих пор.

Я лично знаю людей, использующих Lisp в форме Clojure в паре инвестиционных банков и стартапов в Лондоне. Я также выбрал Clojure в качестве основного языка разработки для своего собственного стартапа, поэтому я готов положить свои деньги туда, где я говорю :-)

Я нашел, что это был очень поучительный опыт изучения Clojure за последний год (после большого опыта работы с Java и C #). Основными причинами этого являются:

• Он имеет достаточно сильный акцент на функциональное программирование (больше, чем в большинстве других Лиспов). Автор и BDFL Rich Hickey часто цитируют Haskell как один из источников вдохновения для языкового дизайна, который означает, что вы получаете такие вещи, как полностью неизменные структуры данных, ленивые бесконечные последовательности и т. Д.
• Макропрограммирование макросов - философию Lisp «код - данные» трудно понять, если вы на самом деле не испытали ее, но это одна из причин, по которой Lisps настолько выразителен и продуктивен. У вас есть возможность расширить язык, чтобы он соответствовал вашей проблемной области.
• Фантастическая поддержка многоядерного параллелизма - я думаю, что Clojure - лучший язык для параллельного программирования прямо сейчас. См. Http://www.infoq.com/presentations/Value-Identity-State-Rich-Hickey для ознакомительной презентации об этом
• Интерактивная разработка в REPL - это отличный продуктивный способ создания приложений. Это дает вам реальное ощущение силы для динамического изменения кода запущенного приложения и программной проверки структур данных в реальном времени .....

Это также представляется практическим выбором для реального использования по следующим причинам:

• Работа на JVM с очень простым взаимодействием Java дает вам доступ ко всем библиотекам и инструментам в экосистеме Java
• Вы работаете на JVM, которая является проверенной и протестированной платформой для корпоративных приложений. Clojure извлекает выгоду из всех приятных функций JVM, таких как отличная компиляция GC и JIT бесплатно.
• По умолчанию это динамический язык , что делает его очень удобным для разработки и быстрого создания прототипов практически без всяких шаблонов. Однако вы можете добавить статические подсказки типа, чтобы получить довольно хорошую производительность там, где вам это нужно.
• Это прагматичное и полезное сообщество - такая культура, в которой люди добиваются успеха и делают упор на хорошо разработанные решения, которые решают реальные проблемы
• Существует поддержка инструментов в нескольких IDE . Я лично использую Eclipse с плагином против часовой стрелки (потому что мне нужна интеграция с Java), но есть много других вариантов.

Я бы использовал LISP, если бы это был лучший выбор для работы. Просто некоторые вещи, которые влияют на «лучший выбор»:

• поддержка поставщиков. Реализация LISP, которую мы используем - если что-то пойдет не так и будет мешать нашему развитию и, следовательно, нашим срокам, будет ли поставщик работать над решением с нами?
• поддержка библиотеки. Какие библиотеки доступны? Манипулирование строками, математика, доступ к данным, веб-сервлеты (или LISP-эквиваленты), оконный инструментарий и т. Д. Я не хочу писать этот материал с нуля.
• поддержка инструментов - Насколько хороша IDE? Твердый / стабильный или облупленный? Хорошая поддержка редактора? Интегрированный отладчик? Если мне нужно сделать GUI dev в LISP, есть ли визуальная IDE или мне нужно кодировать макет GUI вручную (я ненавижу это делать).
• Вклад разработчика (я действительно не хочу тратить слишком много времени, обучая моих товарищей по команде совершенно новому языку)

Все эти факторы должны учитываться при принятии решения о том, подходит ли LISP для проекта. В корпоративном мире я никогда не испытывал это.

Абсолютно. Пол Грэм хорошо это объясняет .

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

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

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

Таким образом, вы можете сказать, что использование Lisp было экспериментом. Наша гипотеза заключалась в том, что если бы мы писали наше программное обеспечение на Лиспе, мы могли бы выполнять функции быстрее, чем наши конкуренты, а также делать то, что они не могли делать в нашем программном обеспечении. И поскольку Lisp был настолько высокого уровня, нам не понадобилась бы большая команда разработчиков, поэтому наши затраты были бы ниже. Если бы это было так, мы могли бы предложить лучший продукт за меньшие деньги и при этом получать прибыль. В конечном итоге мы получим всех пользователей, а наши конкуренты - ни одного, и в конечном итоге обанкротятся. Это было то, на что мы надеялись, так или иначе.

Каковы были результаты этого эксперимента? Несколько удивительно, это сработало. В итоге у нас было много конкурентов, порядка двадцати-тридцати из них, но ни одно из их программного обеспечения не могло конкурировать с нашим. У нас был конструктор интернет-магазина wysiwyg, который работал на сервере и все же чувствовал себя настольным приложением. У наших конкурентов были скрипты cgi. И мы всегда были далеко впереди их по характеристикам. Иногда в отчаянии конкуренты пытались представить функции, которых у нас не было. Но с Лиспом наш цикл разработки был настолько быстрым, что иногда мы могли продублировать новую функцию в течение дня или двух после того, как конкурент объявил об этом в пресс-релизе. К тому времени, когда журналисты, освещающие пресс-релиз, успели позвонить нам, у нас появилась бы и новая функция.

Должно быть, нашим конкурентам казалось, что у нас есть какое-то секретное оружие - что мы расшифровываем их трафик Enigma или что-то в этом роде. На самом деле у нас было секретное оружие, но оно оказалось проще, чем они предполагали. Никто не передавал нам новости об их особенностях. Мы просто могли разрабатывать программное обеспечение быстрее, чем кто-либо мог подумать ...

Где: Emacs - это реальное приложение, использующее LISP.

Почему: это был отличный способ выразить соответствие между нажатием клавиши и действием. Это интерпретируется, и это быстро, и оно четко определено, и это просто.

И Macsyma, и Autocad основаны на диалекте Лисп. Я бы классифицировал их как «реальный мир», а также Emacs.

Абсолютно я бы это учел. Специально для новых разработок, которые имели некоторый параллельный вычислительный потенциал. Это, кажется, сладкое место для этих типов функциональных языков.

Lisp - один из лучших вариантов реализации компиляторов. И поскольку использование DSL и eDSL в настоящее время увеличивается, Lisp становится все более ценным. Я использую диалект Lisp для всех моих задач, связанных с DSL.

Прямо сейчас я пытаюсь использовать newLisp в качестве замены для Php на моем личном веб-сайте через платформу Dragonfly . Если я смогу понять, как заставить Apache играть хорошо, я воспользуюсь им (встроенный веб-сервер работает очень хорошо, но я бы предпочел работать через Apache). И как только это произойдет, я буду использовать newLisp везде, где я буду использовать Php, потому что мне не нравится Php, а мне нравится newLisp.

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

Но, честно говоря, я предпочитаю Ruby Lisp ... но это в основном вопрос сообщества и документации.

Я реализовал проприетарное коммерческое приложение в Common Lisp под названием Tankan, которое работает в Microsoft Windows как собственный исполняемый файл.

Это программа для тренировки запоминания японских иероглифов.

Программа работает как фоновый HTTP-сервер. Выполнение этого сервера и переход к его страницам координируется крошечным приложением-иконкой в ​​области системных уведомлений («Tray»), которое я разработал с использованием Visual C ++.

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

Программа Lisp поддерживает в своей памяти довольно сложное состояние сеанса, которое содержит историю ввода пользователя и различные отношения между различными объектами. Круговая нотация объекта Lisp (включаемая *print-circle*переменной) и то, как она работает в пользовательских print-objectметодах CLOS, очень помогает в реализации персистентности: пользователи могут сохранить состояние на диск и продолжить с того места, где они остановились. Все сохраняется, включая состояние пользовательского интерфейса. В графе объектов много общих подструктур, а также циклов. Кроме того, много статических ошибок, которые не нужно сохранять, например, содержимое объектов словарных статей. С помощью пользовательских методов печати объектов ANSI Common Lisp вы можете создавать сжатые печатные представления для объектов, которые, тем не менее, являются машиночитаемыми,

JavaScript почти не используется в веб-интерфейсе. Даже элементы управления для скрытия и отображения частей пользовательского интерфейса выполняются путем отправки формы и повторного рендеринга HTML. Следовательно, каждая деталь состояния пользовательского интерфейса находится на сервере и сохраняется при сохранении пользователем. Повторное создание HTML очень быстро. Это делается с помощью гигантского выражения обратной цитаты Lisp, которое передает HTML-генерирующий макрос. Код, скомпилированный Clozure Common Lisp (CCL), делает это настолько быстрым, что вы даже не подозреваете, что когда вы нажимаете кнопку [+] в пользовательском интерфейсе, чтобы открыть что-то, вы отправляете запрос на сервер, который восстанавливает вся проклятая страница, а не просто запуск некоторого локального JavaScript для изменения видимости локального элемента документа.

Программа изначально была разработана с CLISP. Благодаря тому, что ANSI CL является стандартным языком, с реализациями, которые хорошо соответствуют, и не слишком много хитрых ошибок в языке («неопределенное» или «определяемое реализацией» поведение), он довольно легко переносится на CCL.

CLISP не был оставлен; он по-прежнему используется для поддержки лицензирования, используя большую часть общей базы кода.

Я разработал оригинальную систему лицензирования для программы, используя криптографическую систему с эллиптическими кривыми, предоставляемую библиотекой IronClad, которая используется сервером лицензирования для подписи лицензий для их сертификации. (Кажется, я помню, что мог использовать программу командной строки OpenSSL для генерации параметров EC для ключа сервера.)

Лицензии представлены в виде объектов Lisp. Это дань переносимости Lisp, что программа Windows, скомпилированная Clozure Common Lisp, может генерировать лицензию на основе S-выражений, программа CLISP, запущенная на сервере Debian, может заполнить отсутствующее поле цифровой подписи в этом объекте и отправить его обратно в программа Windows, которая может проверить подпись.

На сервере, помимо службы лицензирования на основе CGI, используется простой API командной строки для управления лицензиями. Вы можете перечислить лицензии, найти конкретные и отредактировать их атрибуты: например, изменить дату истечения срока действия временной лицензии, чтобы предоставить пользователю исключение. Сервер лицензирования также генерирует электронные письма. Я не использовал никакой библиотеки для обработки CGI на стороне сервера: просто свернутый вручную код Lisp для работы с переменными среды Apache и аргументами командной строки. (Хотя код библиотеки используется для работы с кодировкой URL и генерацией HTML.) База данных не используется для хранения; лицензии объединяются в файл с именем licenses.lispи все.

Если кто-то заплатил мне, конечно.

Они, вероятно, были бы более заинтересованы в оплате кого-то, кто знает язык, хотя. Я только играл с elisp и схемой несколько раз.