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

Изменения в новой версии:

• Монолитная система дополнений clojure-contrib.jar заменена на полностью модульную структуру, что позволяет, во-первых, не включать в готовые приложения код неиспользуемых библиотек, а во-вторых, иметь собственный цикл разработки для каждой отдельной библиотеки. При этом для обновления с Clojure 1.2 рекомендуется сначала обновить библиотеки, а затем уже обновиться до Clojure 1.3;
• Улучшенная поддержка примитивов для арифметических расчетов;
• Изменения в определении записей (defrecord) и типов (deftype);
• Улучшена система оповещения об исключениях и ошибках;
• Несколько новых функций в clojure.core, clojure.data, clojure.pprint, clojure.repl;
• clojure.java.shell/sh теперь поддерживает в качестве источника данных объекты типов InputStream, Reader, File, byte[];
• Поддержка Maven для компиляции и развертывания приложений;
• Улучшения в плане производительности скомпилированных приложений;
• Множество устраненных ошибок.

>>> Полный список изменений

Значится так. Есть уже лет шесть работающая морда к СУБД - программа для всякой там бухгалтерии и т.д. и т.п. Написана на связке Tcl/Tk/Python. Выглядит она примерно так. Кроме того, что она редактирует данные в базенке, она еще осужествляет разную печать посредством генерации xls-документов. Все это крутится на винде и на линухе, причем, у некоторых, в терминалках.
По ряду причин я хочу ее перевести под java. Описание интерфейса и логика у меня жестко разделены, потому надо будет переписать только движок, и 90% кода подхватится jython-ом.
Теперь перейдем к сабжу. На сегодня имеется 2 работающих подхода: традиционный гуи и web-морда. Между ними и выбирается, причем, накладывается ряд требований:

• Поведение программы не должно отличаться от уже существующего. Например, все кейбиндинги, должны подхватится. В случае с веб-мордой я не уверен, что они не законфликтуют с кейбиндингами браузера.
• Критичны диалоги с выпадающими табличками или деревьями, такие как список валют на сриншоте. Записей в такой табличке может быть много, до сотет тысяч, потому для такой таблички реализовано кеширование, и фильтр с сортировкой. Можно ли подобное реализовать на веб-морде? Просто ли это?
• Как быть с печатью? На данный момент пользователь просматривает и печатает из OO или MSOffice. Использование такого формата существенно облегчает жизнь и мне, и пользователю. В случае с ГУИ юзер сразу видит готовый документ и ему надо только нажать кнопку «Печать». В случае с веб-мордой надо еще и отвечать на вопрос браузера о сохранении или открытии документа. Это не упрощение, а усложнение для юзера и он воспримет такое в штыки. Выставить действием по умолчанию тоже не получится, т.к. у разных пользователей разные привычки на сей счет.
• Важно быстродействие. На данный момент прога бодро работает на доживающих свой век третьих пеньках. И даже на паре машин, привязанных 98-й виндой к станочкам, как-то крутится. Я не уверен, что решение на базе веб-морды будет бодро крутится на тех же третьих пеньках. Например, Zimbra на таких машинах ведет себя очень грустно.
• Развертывание ГУЯ уже отработано и много лет с этим не возникает проблем. В случае с веб-мордой могут быть накладки. Например, та же Zimbra не работает с популярной весьма Оперой и для ее функционирования нужна достаточно мощная железка.

На данный момент я решил выбрать в качестве ГУИ и реализовать его на SWING. Тем не менее я хочу рассмотреть альтернативы. Особенно web-морды.

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

С чего начать изучение Erlang? Книги, туториалы, документация.

Как вы изучали этот язык? Расскажите своё впечатление от использования, чем он лучше/хуже других известным вам языков?

Через пару месяцев начнётся работа по портированию проекта с С на Erlang для лучшей масштабируемости и хотелось бы подойти к этому моменту подготовленным.

Спасибо.

Привет. Недавно просил оценить пару десятков строк своего кода на лиспе и получил несколько ссылок «как правильно писать». Одним из пунктов было примерно следующее: старайтесь в каждом случае использовать частные решения вместо общих, когда это возможно eq вместо equal, setq вместо setf и т.д. И если со сравнением все понятно - у разных функций разная точность и разная скорость выполнения, - то ситуация с setq и setf не совсем ясна.

С одной стороны я и сам давно привык присваивать значения символам через setq, но борюсь с этой привычкой для однообразного отражения в коде однотипных операций; для присваивания символам setf раскрывается в setq - о производительности речи не идет. С другой стороны, увидел этот совет и задумался: setq и setf и так визуально достаточно похожи, в коде однозначно читаются как «присваивание», зато по setq можно сразу определить, что присваивание происходит просто переменной, а по setf - что это модификация части какого-то объекта.

Кто какого мнение придерживается в данном вопросе и почему?

Помогите собрать список «must have» книг для системных администраторов (Linux). Это надо для одного связанного с linux.org.ru проекта, подробности которого я пока не могу рассказать.

В первую очередь интерисуют книги на русском языке и которые сейчас есть в продаже.

Накидайте plz

Здравствуйте, коллеги.

Есть программа (досталась по-наследству) которая работает с большими графами, строками и много чего с ними делает. Написана на C. Это неудобно т.к. вся работа с памятью, указателями, границами массивов итп ложится на программиста. А ещё нет ООП, перегрузки, именованных аргументов и прочих вкусностей. В результате погрязли в коде. Нужен альтернативный ЯП.

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

Какие есть альтернативы C? Кресты не предлагать, не хотим :). Высказываются предложения использовать яву, но душа к ней не лежит. Моно и всё что с ней связано тоже не предлагать. Посмотрел на go, не впечатлило. Одним глазом смотрю на D, вторым на julia, куда бы третьим посмотреть? ObjC?

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

Как возможно лучше всего сохранить объект типа
HashMap<String, Map<String, MyObject>> ?
С возможностью загрузить его. При этом в каком либо читабельном формате(xml, например).

Creator: TeX
Producer: pdfTeX-1.40.11
http://ompldr.org/vY3h1bQ/latex.png

Creator: Word
Producer: Mac OS X 10.7.3 Quartz PDFContext
http://ompldr.org/vY3h1dA/msword.png

А накидайте, пожалуйста, примеров достижений Российской науки, промышленности и т.д. за последние годы. Именно Российских достижений. Не СССР. Хочу гордиться своей страной! Достали нытик-треды!

То, о чем так долго говорили параноики - свершилось. В Интернете появился червь Koobface, который заражает основные ОС благодаря своей кросс-платформенности (он написан на Java). Это значит, что под ударом очутились пользователи как Windows так и Linux - систем.

Как это работает?

Червь распространяется по социальным сетям, таким как Twitter, Facebook и MySpace от лица существующего пользователя со взломанным аккаунтом от одних друзей к другим, по цепочке, с предложением перейти на фейк-страничку с Youtube и посмотреть «прикольный ролик». Для просмотра требуется Java-апплет (jnana.tsa). Если пользователь соглашается, то его ПК превращается в зомби-машину и работает на благо владельцев бот-сетей.

Апплет использует уязвимость в Java, в Linux-системах он копирует себя в домашнюю директорию пользователя, но не прописывается в файлы автозапуска. Поэтому зараженный ПК остается ботом только до первой перезагрузки. Однако, огромное количество пользователей могут неделями не перезагружать свои ПК или ноутбуки (скачивая торренты, например)...

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

По ссылке в «Подробнее» оригинал сообщения с блога специалиста по безопасности компании ParetoLogic, который нашел червя первым.

Хабраюзер gjf повторил опыт и в своём сообщении на хабре подтвердил работоспособность зловреда:

http://habrahabr.ru/blogs/virus/107211/ (подробные скриншоты)

«Лаборатория Касперского» уже занялась этим червем описав его работоспособность в своем корпоративном блоге:

http://www.securelist.com/ru/blog/40157/Novaya_krossplatformennaya_ugroza_dlya_polzovateley_sotsialnykh_setey (подробные скриншоты)

Лаборатория Касперского сообщает, что из Северной Америки червь за сутки добрался уже до России.

>>> Подробности

Latex, DocBook, что-то еще?

P.S. Про Doxygen я знаю, но мне не удалось заставить его выдать данные в нужном мне виде (тупо список прототипов функций с документацией), и в любом случае программная документация не исчерпывается doc-комментариями.

В своей новой статье Леннарт Поттеринг (Lennart Poettering), известный разработкой звукового сервера PulseAudio и системы загрузки systemd, объяснил, чем его не устраивает syslog, и предложил свою универсальную реализацию системного журнала в Linux.

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

Поскольку данная разработка Леннарта войдёт в Fedora 17 и далее, скорее всего, разойдётся по всем дистрибутивам, я взял на себя труд перевести и предложить вашему вниманию эту статью.

>>> Перевод статьи