Увидел недавно эту фразу и призадумался. Жаль, что автор той фразы не сможет поучаствовать в обсуждении — тазиком зацепило. Но подобное мнение я слышу последнее время постоянно, так что уверен, что и на ЛОРе полно его сторонников.

ЛОР, объясни мне, почему принято считать, что «IT — это дыра», что IT не престижно, что карьера в IT бессмысленна? Может, это у меня какие-то розовые, идеалистические представления об IT? Работаю я архитектором в хорошей компании, работа интересная, проекты серьёзные и важные, зарплата отличная, график вполне свободный — никто над душой не стоит. Времени хватает и на работу, и на спорт, и на хобби (музыка), и на отдых. Жаловаться вообще не на что. Ну, разве на то, что мало девушек :) Но, с одной стороны, оно и к лучшему — ничего не отвлекает на работе :) Да и вне работы не могу пожаловаться на отсутствие женского внимания ;) На всё лето обычно беру творческий отпуск и еду путешествовать куда-нибудь. Не похоже на «дыру», правда?

Может, это у меня скромные потребности, и, работая в другой сфере (не IT), можно было зарабатывать в пять раз больше? А может, про «дыру под названием IT» пишут неквалифицированные лузеры? Но ведь для неквалифицированного специалиста везде будет «дыра». А может, это только в Москве всё нормально, а за пределами МКАДа в IT полная жопа? Короче, вопросов больше, чем ответов.

А какое представление о состоянии дел в IT у тебя, ЛОРовец?

Привет, ЛОР. На днях поступил сигнал, что нашу контору «заказали».

Не сказать, чтобы источник был настолько серьёзный, чтобы там сворачивать бизнес, срочно вывозить компы и так далее. Тем не менее, есть вероятность, что в ближайшем будущем у нас ожидается маски-шоу с изъятием оборудования.

Собственно, господа в масках могут ограничиться одним изъятием. К такому часто прибегают, чтобы просто нарушить бизнес. Но, в зависимости от серьёзности заказа, может быть установка на юридические последствия. Бизнес абсолютно белый и пушистый, на компах в основном линукс и Mac OS X, немногочисленная винда - лицензионная. Но надо ли говорить, что, попав в руки волшебников в погонах, на компах могут «нечаянно» появиться пиратский Компас 3D, гигабайты детского порно, пиратка последней ленты Михалкова и трактат Рихарда Вагнера «О еврействе в музыке».

ЛОР, предлагаю отбросить все эти «да это блеф, вас просто пугают», «если решили посадить, то посадят и без изъятия компов», «в российском суде вы ничего не докажете» и так далее. Давайте сосредоточимся на одном use case: как гарантированно обезопасить себя от подбрасывания вышеописанных подарочков после изъятия компов? Мне в голову пришла идея: что если в присутствии понятых и адвоката загрузиться с LiveCD и снять MD5 с дисков? Технически это даст возможность доказать в суде, что данные были изменены. Но насколько юридически значимыми будут такие доказательства, то есть примет ли их суд? И как вести себя при изъятии, чтобы позволили снять MD5, ведь это может занять значительное время.

Кастую в тред всех юридически подкованных товарищей.

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

Выходит, что для удаления сообщения нужны (хотя бы формальные) обоснования; иногда это просто невозможно, например, когда сообщение находится в данном разделе и содержит обсуждение действий модератора. А тупо забанить пользователя - значительно проще, чем Тазик и пользуется постоянно.

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

Вот знаете, есть такой эксперимент. Когда лабораторную обезъянку приучают: красный кружок - удар током, синий треугольник - банан. И с тех пор у неё навсегда красный кружок ассоциируется с болью.

Так и на ЛОРе. Если кое-кто видит «LISP» - у него сразу возникает ассоциация «флейм», «флуд», «срач», «ад и погибель». И рука на автомате тянется к кнопке «удалить», снося в тартарары интересную техническую дискуссию, в которой специалисты аргументированно и взвешенно обсуждают технологии с их плюсами и минусами.

Быть может, при таких условных рефлексах стоит всё-таки повышать квалификацию и расширять кругозор? Ну или как минимум воздержаться от модерирования технических разделов, где требуется мало-мальская компетентность.

Наверняка многие читатели интересуются, какова подоплёка моих последних тем о возможности применения 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++.

Надо признать, я солидарен с вот этим постингом в том, какая проблема у лиспа(и у Common Lisp в частности) на текущий момент является ключевой, и какая отталкивает от него разработчиков.

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

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

Взять вот такую простенькую, даже тупую, программку - GUI-морда к БД. На C# написать ее не составило совершенно никакого труда, и заняло это пару часов от силы. Но если попытаться сделать то же самое на лиспе, окажется что сделать это не так уж и просто - будет очень не хватать WPF, очень не хватать Entity Framework, да и даже банального интерфейса к ОС(для того чтобы сделать программу синглтоном). И это не говоря уже про Visual Studio и прочие инструменты типа Expression Blend, которые очень сильно упрощают разработку GUI и подобного.

Так к чему этот постинг вообще? Пишите библиотеки для лиспа, вот к чему! Я вот твердо уверен, будь у CL столько же библиотек, как у .NET, или, тем более, Java, то последними бы никто почти не пользовался.

http://love5an.livejournal.com/366931.html

Продолжаем тему интеграции систем на Common Lisp. С интеграцией со внешним миром вроде разобрались в прошлой теме: единственным жизнеспособным, стандартным и не костыльным вариантом являются веб-сервисы. Поддержка CORBA слабая.

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

• publish-subscribe и point-to-point семантика,
• безопасность как уровня транспорта так и на доступ к topic'ам,
• гарантия доставки,
• транзактность,
• durability.

Есть ли что-то такого же уровня для Common Lisp? Я тут наткнулся на библиотеку ZeroMQ для CL, её я так понимаю написал наш mv, за что ему конечно спасибо... но ZeroMQ - безброкерная система, так что она пролетает по части гарантии, транзактности и durability (сохранения сообщений при отвале клиента и доставка при переподключении).

UPD: По просьбам трудящихся, замечу, что мы ориентируемся на стабильные промышленные ОС (Linux, Solaris) на x86 и RISC железе. Настоятельно прошу не предлагать экспериментальные и маргинальные решения вроде миграции на Plan 9, спаять лисп-машину и т.п.

Есть ли у кого-нибудь практика моделирования при помощи UML систем на Common Lisp? Интересует опыт применения конкретных инструментов, для генерации скелетных классов например.

Несомненно инкрементальная разработка и возможность поправить что-то на работающем образе относятся к большим достоинствам Common Lisp. Но вот предположим я там чего-то наинкрементировал на живой системе через REPL, в нескольких разных местах. Подскажите Ъ-способ синхронизировать изменения обратно в дерево исходников, для дальнейшей синхронизации в VCS, например Subversion. Или, для любителей DVCS - Git/Mercurial/Monotone etc.

Подскажите ORB для Common Lisp. Надо чтобы поддерживал хотя бы CORBA 3.0 и умел SSLIOP и HTIOP. Обнаруженный мной CLORB ничего этого не поддерживает и уже пять лет как не обновлялся

Меня удивляет, сколько у местных лисперов враждебности в адрес GoF и паттернов проектирования, что «GoF это такой мемуар про то как перцы писали текстовый редактор, там больше пиара». Ну предположим в некоторых паттернах действительно нет нужды... например Visitor не нужен потому ччто есть multiple dispatch. Некоторые паттерны сильно завязаны на ООП, которое я так понимаю в Лиспе не приветствуется. Но подавляющее большинство паттернов не только успешно решает поставленные задачи, но ещё и реализуются красивее, чем в той же Java, за счёт развитой макросистемы и ФПП. То есть задача и способ решения есть, но западло назвать это «паттерном»? Откуда такая боязнь называть вещи своими именами. А то получается как в анекдоте: ж**а есть, а слова нету.

Также хочется услышать опытных лисперов, какой подход к проектированию своего ПО вы практикуете, желательно с пояснениями и обоснованиями. На всякий случай, проектирование - это то, что следует после постановки ТЗ, но предшествует непосредственно кодированию. Спасибо.

Подскажите, есть ли для Common Lisp аналог Future и Executor из Java? Или какой-нибудь похожий метод. Нужно запускать асинхронное выполнение функций, и получать их результат в другое время, из другой функции и из другого потока. Обязательно чтобы был таймаут, аналогично Future.get(timeout, unit). Желательно чтобы задачи распределялись на thread pool, то есть не создавать новый thread на каждый новый вызов, потому что это неэффективно. Мне кажется задача должна хорошо уложиться в функциональную парадигму Лиспа. Но ничего готового не нашёл...

Было проведено несколько десятков микробенчмарков .NET vs Java vs Mono. Вычисление тригонометрии, логарифмов, работа с коллекциями, парсинг... Для труЪ: Java везде сливает на порядки ;)

!Ъ идут сюда

Какова вероятность того, что, выбрав вариант ответа случайным образом, вы ответите на данный вопрос правильно?

а) 25% б) 50% в) 75% г) 25%

Можно округлять.

Всем привет!

Неоднократно приходилось слышать такое утверждение: в лиспе возможности рефакторинга, профилирования, отладки и многого другого достигаются средствами самого языка. Т.е. без использования вспомогательных средств, нередко усложнённых, как например в Eclipse или IDEA для Явы. В принципе, я готов в это поверить, т.к. язык очень могучий, и всё, что я до сих пор освоил в нём это лишь верхушка айсберга. Поэтому хочу попросить местных гуру-лисперов продемонстрировать вышесказанное на двух простеньких примерах,

1. Рефакторинг «Смена сигнатуры». Пусть есть функция, которая вызывается в сотне мест. Понадобилось а) переименовать функцию, б) добавить параметр. Хочеться, чтобы вызовы функции поменялись на новые во всех местах, где она используется. В место недостающего параметра подставлять NIL, ну или какие-то конкретные значения в зависимости от контекста.
2. Рефакторинг «Подъём метода». Пусть есть класс А, и наследующий от него класс В (классы понимаются в терминах CLOS, разумееться). Хочется переместить некий метод из класса В в класс-родитель А, или наоборот, это будет уже «спуск метода».

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

Спасибо заранее!

Всем привет, хочу продолжить тему работы с файлами в ФП. Тут недавно были примеры, но очень тривиальные, прочитать-записать. Вопрос такой, как в ФП-языке считать в память огромный файл как двумерный массив, и чтобы он а) занимал в памяти столько же места сколько на диске б) доступ к элементам был быстрый (О(1))?

Предистория такова, мы обрабатываем изображения с телескопов, там счёт идёт на сотни мегапикселей, и глубина пикселя 32 бита. Так что типичное изображение ~ два с половиной гигабайта, для этих целей специально собраны счётные узлы с 4 Гб RAM. Это чтобы изображение поместилось целиком в память, и оставалось на промежуточные буферы для накопления результатов. Естественно, все рассчёты написаны на Си и С++, работает быстро, памети хватает. Но код некрасивый, много повторяющихся конструкций и т.п. Народ в основном закостенелый из старшего поколения, ничего кроме Си и фортрана не знают, а я хочу попробывать более современные языки.

Так что буду благодарен за примеры чтения массивов для Haskell и особенно Scheme. И чтобы можно было посмотреть, сколько памяти реально израсходовано. Спасибо!

Всем привет...

Хочу поблагодарить всех, кто мне помогал с задачкой (http://www.linux.org.ru/view-message.jsp?msgid=3746388), хотя результат получился, мягко говоря, плачевный :( а если честно говорить - жидко обкакались :)

Короче, я поговорил со знакомым лисп-гуру, он мне предложил код по разбору DSL и манипуляции XML... Всё с самого начала пошло наперекосяк :( Кода, кстати, реально много, десятки файлов... Сперва оно просто не запускалось: у них там Аллегро LISP, у нас SBCL, там разные конструкции... После того как подпилил, стало запускаться. Но тормозит просто по-чёрному, не знаю, может у SBCL под нашу платфору JIT какой-то недоделанный. Потом оказалось, что отрабатываются только INSERT и DELETE, апдейты не отрабатываются, гуру не дописал... шаблоны файлов не обрабатываются, zip-формат не поддерживается... тимлид посмотрел на эту гору кода со скобками, покрутил пальцем у виска, теперь они все на меня странно смотрят в коридоре :)

Что самое обидное, жабщики это сделали ещё в пятницу, безо всяких шеллов, файндов и XSLT... Распарсили DSL при помощи JavaCC, надыбали какой-то Schema Aware процессор, прикрутили Ant для паттернов файлов, зип-формат там "искаропки"... Реально за пару часов сделали, я сам смотрел в VCS, кода всего несколько килобайт, всего три класса - парсер, лексер и что-то для Ant. И, главное, работает офигенно быстро всё.

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

В общем, обздались мы по полной с лиспом :) А у меня розовый туман начал спадать понемногу... на своей шкуре понял, что LISP - в общем, не панацея, язык интересный, но как только появляется практическая задача из реального мира - грабли. Хотя конечно в области ИИ ему нет равных.

Такая вот "история неуспеха" :) Жалко, что из-за неудачного дебюта путь для LISP будет закрыт в нашу организацию... ни для каких серъёзных задач его не станут теперь пробовать, раз с такой мелочовкой не справился.

PS. Кстати на bash+find+xsltproc я тоже попробовал ради интереса - всё равно медленнее, чем на Java!!! наверно потому, что xsltproc не schema aware... я вот думаю, может на Haskell надо было попробоывать? что скажете?

Всем привет!

Возникла на работе задачка. Есть огромное количество зазипованного XML (документы OpenOffice), тысячи их. Надо пробежаться по всей куче и подправить XML в соответствии с правилами. Правила выглядят так:

для_файлов <путь>/docs/**/naklad/*.odt:
удалить_ноду /abc/def/gh[@zxc=$var1]
вставить_ноду ... перед_нодой ...
установить_значение /qwe/rty/iop/@asd = $var2

и так далее, переменные $var1 и $var2 задаются извне.

Я просто интуитивно чую, что это задача для LISP'а. Да и не столько интуитивно, сколько объективно, смотрите: обработка нестандартных wildcard'ов (**), специализированный язык правил - типичный же DSL! Плюс обработка текстов (XML).

У нас, правда, всё пишут на Java, жабокодеры получают кучу бабок ни за что и понтуются, достали уже... есть мысль утереть им нос :) Начальство вменяемое, если им продемонстрировать эффективное решение, то пойдут навстречу.

Времени дали до понедельника, половину выходных потратил на девушку, время поджимает, надеюсь на помощь коллективного ЛОРовского разума :) Я в лиспе сравнительно новичок, подскажите, куда копать вообще? Есть один знакомый лисп-гуру из Англии, попробую его попросить. Но - одна голова хорошо, а десять лучше! Спасибо :)