LINUX.ORG.RU

Сказ о том, как Игнат-молодец Common Lisp в Ынтерпрайз пихал.


3

6

Наверняка многие читатели интересуются, какова подоплёка моих последних тем о возможности применения Common Lisp в промышленном программировании. Чувствую что обязан рассказать всю историю целиком, как минимум для тех, кто помогал мне ответами. Пользуясь случаем, хочу также всех поблагодарить.

***

Предистория. Некоторое время назад работодатель (крупный производственный концерн) обнаружил пробел в IT-инфраструктуре. Было принято решение в пользу in-house разработки, потому что на рынке подобного готового продукта просто нет, а штат разработчиков у нас довольно большой и квалифицированный. Но разработка исторически ведётся на традиционных, статичных, «слабых» языках, в основном Java и C++.

Но надо отдать должное, к новым перспективным технологиям относятся открыто и с энтузиазмом. Поэтому я предложил рассмотреть в качестве технологии Common Lisp, а мне предложили сделать доклад с обоснованием перед Техническим Комитетом.

***

Вот тут собственно и начинается история. Некоторое время я собирал информацию и готовил доклад, спасибо всем на ЛОРе кто отвечал на мои вопросы о лиспе. Итак, были рассмотрены следующие существенные для промышленного ПО аспекты.

1. Persistence. Общепринятый в современном ПО подход, позволяющий автоматически отображать программные сущности и отношения между ними на таблицы и связи в СУБД. Для Common Lisp индустриальным стандартом де-факто является AllegroCache, хотя это и не «стандарт» в общепринятом смысле, как JPA например. Прозвучал закономерный вопрос «почему надо тратить несколько тысяч $$$ на Allegro, если Hibernate даёт всё то же самое, к тому же оно бесплатно и открыто?» Нет, для холдинга несколько тысяч $$$ - это в общем копейки. Но финансово успешной организацию делает в том числе умение считать каждую копеечку, и тратить деньги обоснованно.

2. Интеграция. Предполагается, что продукт будет состоять из нескольких распределённых модулей, коммуницирующих друг с другом. А также надо будет обращаться к внешней системе через CORBA. Если с коммуникацией CL-CL всё более менее понятно (AMQP, веб-сервисы) то с CORBA оказалось не всё так гладко. Так, стабильного CORBA 3.0 ORB для Common Lisp просто нету. В некотором приближении может устроить ORB, входящий в состав LispWorks. Это ещё несколько тысяч $$$, см. выше насчёт обоснования. Опять-таки, для Java и C++ имеются открытые, бесплатные и стабильные CORBA 3.0 ORBs. Ну и сами лисперы однозначно соглашаются в том, что «Common Lisp и CORBA не предназначены друг для друга», так что тут однозначный неуд.

3. Моделирование. Индустриальный стандарт для моделирования, UML, оказался слабо применим по причине сильных расхождений в семантике между UML/ООП и CLOS. Своих методик моделирования для CL нет. При этом распространено абсурдное мнение, что лучшая модель и документация - это сам код. Боюсь, что происходит оно от незнания UML и непонимания, что подавляющее большинство аспектов, охватываемых UML, в принципе невыразимо ни в каком в тексте. Вообще, наверняка UML можно использовать в некотором приближении, задействуя стереотипы и т.п. Но такой практики просто нет, а в индустрии практика - это всё. Позволить себе наступать на неизвестные грабли можно только в исключительных случаях.

4. Методология. Чётко очерченной методологии разработки для CL как-то тоже не наблюдается. Стандартной IDE у нас считается Eclipse, а для CL стандартом де факто является Emacs+SLIME, что повлечёт переучивание большого числа сотрудников. CUSP для Eclipse оказался довольно сырым поделием, чтобы его реально использовать, придётся инвестировать в его допиливание. Что касается, паттернов проектирования, в принципе многие из них применимы и к Common Lisp. Но практики такой опять же нету. Следовательно, нету опыта и информации.

После этого был задан закономерный вопрос: а каковы, собственно, преимущества CL, ради которых можно было бы стерпеть всё вышеперечисленное?

1. DSL. Довод о простоте создания DSL был сразу воспринят скептически. Оказывается, у нас в организации уже давно используется Scala, на которой написание DSL (причём не ограниченных синтаксисом S-выражений, как в Лисп) гораздо проще и гибче.

2. Code-as-data, кодогенерация и метапрограммирование. При всех преимуществах такого подхода, сильно страдает понимаемость кода и, как следствие, общая поддерживаемость системы. Одно дело, когда код пишет энтузиаст-одиночка. Но ситуацию, когда шестиуровневые навороты кода понятны только автору, индустрия допустить не может. К тому же, современная Java обладает довольно развитыми средствами метапрограммирования, такими как StringTemplate или просто генерация кода на поддерживаемом JVM динамическом языке и тут же исполнение его. А принцип «code as data» вообще рассматривается как нарушение основополагающего в проектировании принципа separation of concerns.

3. Динамический язык и инкрементальная разработка. Динамика языка, при понимании преимуществ, тоже рассматривается скорее как негативное свойство. В промышленном программировании от системы в первую очередь требуется устойчивое поведение. Ситуация, когда поведение может измениться непредсказуемым образом в рантайме - недопустима. Грубо говоря из Common Lisp можно, как из пластилина, слепить что угодно. Но если слепить кувалду, то это будет пластилиновая кувалда, с закономерным выводом о её применимости. Кувалда должна быть всё-таки из металла. Теперь что касается инкрементальной разработки. Она безусловно является сильной стороной, но имеет кое-какие негативные последствия для эффективной командной работы с системами VCS. К тому же, современные Java IDE тоже это умеют: например, в отладчике на живой системе изменить код, тут же перекомпилировать и подгрузить обновлённый класс и продолжить отладку с предыдущего фрейма.

4. Производительность труда разработчика. Это то, что всегда относят к главным достоинствам Common Lisp, но я не нашёл возможностей объективно это доказать. Такие вещи может показать только практика. Если опираться чисто на объём кода, то он будет примерно эквивалентным для примерно эквивалентных проектов на CL и той же Java. На Java ещё и возможен выйгрыш за счёт богатой runtime library и отсутствия необходимости изобретать велосипеды. Так, например, QPX (ядро продукта ITA Software) занимает 500 тысяч строк на Common Lisp.

***

Думаю сами догадаетесь какие выводы сделал Технический комитет относительно будующего языка разработки. А лично я для себя сделал такой вывод. Common Lisp в промышленной разработке можно использовать только для программирования сложных алгоритмов, когда может «выстрелить» динамизм и макросистема. Использовать можно двумя способами: внедрять при помощи ECL в программы на С/С++, или запускать standalone SBCL образ и вызывать его через AMQP или веб-сервисы. На самостоятельное плаванье CL неспособен. Лисп - это юркий и быстрый катер, но в неспокойных водах «энтерпрайза» его плаванье будет недолгим. Там нужны тяжеловесные, хоть и неповоротливые, атомные ледоколы типа Java и C++.



Последнее исправление: Ignatik (всего исправлений: 1)

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

vertexua ★★★★★
()

Кстати ещё очень важное наблюдение... если абстрагироваться именно от Common Lisp, то следует обратить внимание на Scala и особенно Clojure. Очень перспективные и современные языки, сочетающие в себе плюсы функционального, динамического, метапрограммирования и «батарейки» JVM, и не имеющие родовых травм присущих Common Lisp.

Ignatik
() автор топика

> Думаю сами догадаетесь какие выводы сделал Технический комитет относительно будующего языка разработки

Нет, расскажи.

tailgunner ★★★★★
()

Спасибо за рассказ - интересно было читать!

Napitok ★★
()
Ответ на: комментарий от vertexua

Боюсь тоже самое можно сказать и про Хаскель и про остальные маргинальные ЯП типа Nemerle. Знал бы ты сколько сил нужно потратить чтобы убедить людей их не использовать в серьезных проектах. Да и в несерьезных тоже.

LongLiveUbuntu ★★★★★
()
Ответ на: комментарий от vertexua

> Красава. Даже я бы так Лисп не обосрал. Обоснованно, с подготовкой, со сбором информации.

Ну у меня не стояло задачи специально «обосрать»... Просто хотелось расставить точки, в первую очередь для себя. А результат да, получился не самый радужный, но зато теперь всё по полочкам разложено.

Ignatik
() автор топика

столько пафоса, но так уныло =(

korvin_ ★★★★★
()
Ответ на: комментарий от Ignatik

дикое отжирание памяти и тормозной gc, я на жабе не программист, так что всех минусов не знаю

anonymous
()
Ответ на: комментарий от tailgunner

> Нет, расскажи.

Я конечно понимаю что вы стебётесь, как обычно :)
Но в общем да, почему бы не озвучить решение...

1. Основным языком будет Java
2. Части, существенно требующие динамики - на Groovy
3. Там, где потребуются DSL (если вообще потребуются) - Scala
4. Для реализации сложной логики рассматривается Clojure, но вряд ли что-то такое будет, система несложная
5. Там, где нужен performance и realtime - C/C++

По-моему, вполне оправданный современный подход, для каждой задачи - свой инструмент

Ignatik
() автор топика
Ответ на: комментарий от Ignatik

Кстати было заявлено, что со стратегической точки зрения можно было бы и в п.1 поставить Scala, но её пока мало кто знает. Но в будущем ориентироваться будем однозначно на Scala.

Ignatik
() автор топика
Ответ на: комментарий от korvin_

> JVM.

А какие претензии к JVM? Не к языку Java, а конкретно к виртуальной машине?

Ignatik
() автор топика
Ответ на: комментарий от anonymous

> дикое отжирание памяти и тормозной gc, я на жабе не программист, так что всех минусов не знаю

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

GC гибко настраивается, а при глубоком понимании принципов его работы (поколения и т.п.) на его работу можно очень тонко влиять

Ignatik
() автор топика
Ответ на: комментарий от Ignatik

> 1. Основным языком будет Java

2. Части, существенно требующие динамики - на Groovy

3. Там, где потребуются DSL (если вообще потребуются) - Scala

4. Для реализации сложной логики рассматривается Clojure, но вряд ли что-то такое будет, система несложная

5. Там, где нужен performance и realtime - C/C++

5-6 языков для несложной системы. Реально ынтерпрайз.

По-моему, вполне оправданный современный подход, для каждой задачи - свой инструмент

Продаю новую идею: универсальные языки программирования. Если не боитесь Скалы и Груви - ими и ограничтесь.

tailgunner ★★★★★
()
Ответ на: комментарий от o

> Извини, но http://tsya.ru. Читать тяжело :(

Поправил как смог... это у меня давнишняя беда, с детства :)

Ignatik
() автор топика
Ответ на: комментарий от tailgunner

> 5-6 языков для несложной системы. Реально ынтерпрайз.

Несложной по логике, но требовательной в плане NFR (поддерживаемость, производительность, масштабируемость).

Продаю новую идею: универсальные языки программирования. Если не боитесь Скалы и Груви - ими и ограничтесь.


Рано или поздно к тому всё и придёт. Java в перспективе будет заменена на Scala, а Clojure вряд ли понадобится вообще. В данный момент да, Скалы побаиваются - мало кадров.

Но вот от C/C++ никуда не деться, кое-где нужен реалтайм, работа с hardware и высокая производительность, которая даже с современным HotSpot JIT не достигается в принципе.

Ignatik
() автор топика
Ответ на: комментарий от anonymous

> 1. http://www.cliki.net/ORM

Кучка нестандартизованных, развиваемых энтузиастами библиотек. Для нас крайне важна industry acceptance и гарантированная поддержка.

2. http://www.cliki.net/CORBA


Я их недавно даже цитировал: «CORBA is a poor match with CLOS». CLORB заброшен и не развивается уже 5 лет как

Не лучше ли опиратья на функциональность (scope)?


На функциональность чего? Языка? Извините, но никакая функциональность не перевесит кучу вышеописанных проблем нефункционального характера.

Ignatik
() автор топика
Ответ на: комментарий от Ignatik

> Что не так?

«Vala как замена Си/Си++» многое говорит о квалификации тех, кто так думает.

Лучше скажи, где ты нашел открытый и стабильный Си++ ORB для CORBA 3.0?

tailgunner ★★★★★
()
Ответ на: комментарий от tailgunner

> «Vala как замена Си/Си++» многое говорит о квалификации тех, кто так думает.

Ну, а что говорит-то? Не стесняйтесь... я им всё перескажу :) К тому же, где я говорил о полной замене? У нас без фанбойства...

> Лучше скажи, где ты нашел открытый и стабильный Си++ ORB для CORBA 3.0?

The ACE ORB же. CORBA 3.0 для C++, открытый, свободный, стабильный, с коммерческой поддержкой. А почему вы спрашиваете? Из праздного интереса, или есть конкретные задачи? Интересно было бы услышать, чужой опыт тоже важен

Ignatik
() автор топика
Ответ на: комментарий от Ignatik

>> Лучше скажи, где ты нашел открытый и стабильный Си++ ORB для CORBA 3.0?

The ACE ORB же.

Вечно забываю этого монстра.

А почему вы спрашиваете? Из праздного интереса, или есть конкретные задачи?

Из праздного интереса. Когда мы использовали CORBA, это был omniORB. Когда ты спросил именно про CORBA 3, я проверил omniORB - там этого нет.

tailgunner ★★★★★
()
Ответ на: комментарий от Ignatik

в будущем ориентироваться будем однозначно на Scala

общественность одобряет

jtootf ★★★★★
()

Без описания задачи (что надо было разработать) это просто унылый вброс. Надо было предложить писать на bash'e еще.

Ignatik> Предистория. Некоторое время назад работодатель (крупный производственный концерн) обнаружил пробел в IT-инфраструктуре. Было принято решение в пользу in-house разработки, потому что на рынке подобного готового продукта просто нет, а штат разработчиков у нас довольно большой и квалифицированный. Но разработка исторически ведётся на традиционных, статичных, «слабых» языках, в основном Java и C++.

Так что надо было разработать?

sdio ★★★★★
()

Ignatik> штат разработчиков у нас довольно большой и квалифицированный

Сколько всего? И сколько из них знают CL?

sdio ★★★★★
()
Ответ на: комментарий от anonymous

>> DSL
>> Scala
> /0

Что не так-то? Цитирую Википедию:

The design of Scala acknowledges the fact that, in practice, the development of domain-specific applications often requires domain-specific language extensions. Scala provides a novel combination of language mechanisms that make it easy to smoothly add new language constructs in the form of libraries:

  • any method may be used as an infix or postfix operator, and
  • closures are constructed automatically depending on the expected type (target typing).

A joint use of both features facilitates the definition of new statements without extending the syntax and without using macro-like meta-programming facilities.

Перевожу: в Scala любой метод может быть использован как инфиксный или префиксный оператор, поэтому Scala поощряет расширение языка (и, как следствие, простое создание DSL) без прибегания к макросам и метапрограммированию.

Ignatik
() автор топика
Ответ на: комментарий от sdio

> Так что надо было разработать?

Ну я подумал, что читатели всё же представляют себе примерный масштаб задач «ынтерпрайза». В нашем конкретном случае нужно приблизительно следующее:

1. Компоненты, работающие на производстве, снимают показания с оборудования
2. Там же, на производстве, происходит простая агрегация данных и асинхронная, но с гарантией доставки, отправка на сервер в ДЦ
3. На сервере происходит обработка и сохранение информации в базу
4. После этого по данным формируется куча разной отчётности и аналитики
5. Попутно надо скармливать данные в расчётный пакет, который доступен по CORBA.

Вот примерно как-то так. Всё это, разумеется, с corporate-grade security, шифрованием, защитой, разграничением доступа и так далее. Какие технологии были в результате выбраны, я уже озвучил выше

Сколько всего? И сколько из них знают CL?


А это важно? Всего несколько сотен, среди них есть со знанием лиспа (не обязательно CL, может Scheme или Clojure). Во-первых, если действительно нужно, то можно нанять; во-вторых, как показывает практика, нормальный разработчик (с хорошим образованием) довольно быстро осваивает лисп с нуля. А так называемый «Blub paradox» на практике оказывается выдумкой фанатика

Ignatik
() автор топика
Ответ на: комментарий от Ignatik
1. Компоненты, работающие на производстве, снимают показания с оборудования
2. Там же, на производстве, происходит простая агрегация данных и асинхронная, но с гарантией доставки, отправка на сервер в ДЦ
3. На сервере происходит обработка и сохранение информации в базу
4. После этого по данным формируется куча разной отчётности и аналитики
5. Попутно надо скармливать данные в расчётный пакет, который доступен по CORBA.

Спасибо, посмеялся.

sdio ★★★★★
()
Ответ на: комментарий от sdio

> Спасибо, посмеялся.

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

Ignatik
() автор топика
Ответ на: комментарий от Ignatik

1. Компоненты, работающие на производстве, снимают показания с оборудования

здесь java? C достаточно

2. Там же, на производстве, происходит простая агрегация данных и асинхронная, но с гарантией доставки, отправка на сервер в ДЦ

Язык любой + MQ (message queue) «с corporate-grade security, шифрованием, защитой, разграничением доступа и так далее.»

3. На сервере происходит обработка и сохранение информации в базу

SQL -> UPDATE

4. После этого по данным формируется куча разной отчётности и аналитики

Вот тут как раз подoйдет LISP, лучше чем JAVA

5. Попутно надо скармливать данные в расчётный пакет, который доступен по CORBA.

Тупая буферная (прокси) программа на любом языке умеющим работать с CORBA 3

sdio ★★★★★
()
Ответ на: комментарий от Ignatik

Ignatik> я за вас начинаю волноваться.

И да, волнуйся за себя. Надо быть упоротым красноглазиком, чтобы в своем Ынтерпрайзе с штатом программистов >100, из которых несколько что-то слышали о CL, предлагать заменить их любимую java и c++, на что-то кардинально отличающееся.

sdio ★★★★★
()

Мне всегда казалось, что CORBA нужна прежде всего для интеграции унаследованного кода, в котором невозможно разобраться или переписать. А для новых разрабатываемых программных систем CORBA неуместна ни в каком виде.

iZEN ★★★★★
()
Ответ на: комментарий от sdio

А чего смешного? Типичные задачи получения, обработки и сохранения телеинформации на объектах энергетики и промышленности.

iZEN ★★★★★
()
Ответ на: комментарий от Ignatik

> Что не так-то? Цитирую Википедию

Мало ли что написано в википедии?

Перевожу: в Scala любой метод может быть использован как инфиксный или префиксный оператор

То есть от того что мы вместо f(x,y) пишем x f y эта херь становтися ДСЛ? ололо.

anonymous
()

Если интересно в нашей конторе произошла (не полная пока еще), но все же миграция с Java на Python. В нашу не сильно интерпрайзнутую инфраструктуру (судя по описанию у нас она сложнее чем у вас) питон вписался, причем даже улучшил ее. Например стал во всю применяться неблокирующий ввод-вывод. А Java NIO только в новых проектах используется. Тот же JDBC как был тормознутым блокирующим говном, так им и останется.

dizza ★★★★★
()
Ответ на: комментарий от sdio

Ты либо придурок, либо на серьезном предприятии никогда не работал. С таким подходом, как у тебя, софт будет валиться от любого чиха :)

bik ★★
()
Ответ на: комментарий от sdio

это тебе не школьный сайт разрабатывать :))

bik ★★
()
Ответ на: комментарий от bik

Спасибо, ваше мнение очень важно для нас, оставайтесь на линии.

sdio ★★★★★
()
Ответ на: комментарий от bik

bik> С таким подходом, как у тебя, софт будет валиться от любого чиха :)

Ты либо придурок, либо на серьезном предприятии никогда не работал.

С чего бы ему валиться? Все модули распределенной системы глобальны и надежны.

sdio ★★★★★
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.