LINUX.ORG.RU

Релиз Allegro CL 9.0

 , , ,


2

3

Вышла новая версия реализации среды программирования Common Lisp — Allegro CL 9.0.

Allegro CL® является динамической объектно-ориентированной средой программирования, подходящей для разработки сложных энтерпрайз-ориентированных приложений. Разработка такого рода приложений с миллиардами объектов теперь стала еще проще с новым Allegro CL 9.0. Сложность сегодняшних программных комплексов и взрывной рост объемов данных получили широкое распространение во всех областях, начиная с наук о жизни (Life Sciences) и кончая финансовым анализом (Financial Analytics).

Из наиболее значимых изменений в этой версии — полная поддержка SMP (Symmetric Multiprocessing) на SMP-платформах:

  • 32-bit Linux (x86), 64-bit Linux (x64);
  • 64-bit Mac OS X 10.5;
  • 32-bit Windows, 64-bit Windows.

«Релиз ACL 9.0 от Franz является важным шагом вперед, который принес настоящий SMP в одну из самых лучших существующих сред программирования. Все наши существующие многопоточные приложения „просто работают“ и выполняются быстрее, чем раньше на том же оборудовании.» — Jason Cornez CTO, RavenPack International.

Из других изменений:

  • 820 улучшений с последнего релиза.
  • Важное обновление для AllegroServe. Автоматическая компрессия/декомпрессия файлов, поддержка «chunking», и новые опции для безопасности, включая TLS v1.0 протокол для защищенных соединений.
  • jLinker. Улучшен протокол, проще API.
  • Важные изменения в интерфейсе Allegro CL к Amazon Elastic Compute Cloud (EC2), поддержка регионов.
  • Упрощенная установка для 64 битных графических утилит на Mac.
  • Метод «dequeue» теперь включает таймаут.
  • Поддержка компрессии данных. См. класс util.zip:deflate-stream и аналогичные функции.
  • Новый макрос in-case-mode позволяет загрузку fasl-файлов, скомпилированных в других режимах из запущенной лисп-среды.
  • Структуры могут быть переданы или возвращены в/из foreign функций как по значению, так и по ссылке.
  • Поддержка различных систем кодирования: MD2, MD4, MD5, SHA1, SHA256, SHA512, и RMD160.
  • Множество улучшений в Common Graphics и в IDE для систем без SMP.
  • Другие изменения

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

★★

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

Ответ на: комментарий от Macil

Scala - это прежде всего ООП система. Так что неудивительно.

Но с другой стороны, коллекции Scala очень похожи и на коллекции F#. Просто вызываем не функции модулей, а методы объектов. А модули и их функции - это уже как бы не совсем ООП.

Мода? Не наблюдаю никакой «моды»! Наблюдаю восстановление баланса между научным и инженерным подходами в разработке мейнстрим-софта.

Это ООП - инженерный подход? Странно, у меня хорошее ООП всегда ассоциировалось с философией и математикой: классификация, атрибуты, минимальное реализующее подмножество и полнота, инварианты, непротиворечивость и прочее. Хотя на практике ООП превращается в черти знает что, и тут отчасти соглашусь про «инженерный подход», но справедливости ради, программы на хаскеле тоже не всегда напоминают о «научном подходе» :)

Я пытался противопоставить? Даже близко нет. Кроме того, противопоставлять их попросту глупо. И Одерский это доказал на практике.

Отчасти согласен. Только считаю, что Одерский не был пионером. Мультрипарадигменные языки появились довольно давно.

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

ЗЫ: А раз ООП такое хорошее, так что ж тебя мое высказывание задело?

Ты, наверное, шутишь?

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

Это ООП - инженерный подход? Странно, у меня хорошее ООП всегда ассоциировалось с философией и математикой: классификация, атрибуты, минимальное реализующее подмножество и полнота, инварианты, непротиворечивость и прочее.

ООП - это не математика, а эвристики. Так что это скорее инженерный подход. Математический - это ФП (и АТД ранее).

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

Это ООП - инженерный подход

От парадигмы слабо зависит. Дело скорее с чем ассоциируется та или иная «парадигма». Согласись, что в последнее время стали намного больше задумываться:

1. О спецификациях вообще.
2. О применении формальных методов в разработке спецификаций.
3. О создании неких формальных связей между спецификацией и разрабатываемым продуктом.

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

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

За последние лет десять очень развилось направление по разработке серверных приложений - интернет шагает по планете. Может быть, с этим связан интерес к «спецификациям» и ФП в частности?

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

Может быть, с этим связан интерес к «спецификациям» и ФП в частности?

Скорее с безопасностью.

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

Написал в franz ради интереса про лицензии и был приятно удивлен наличием русскоязычного персонала)

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

strobe
()
Ответ на: комментарий от dave

Но с другой стороны, коллекции Scala очень похожи и на коллекции F#.

неуидивительно, там же Дон Сайм ЕМНИП руки свои поприкладывал

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

ты свою бизнес-логику можешь описать в декларативном виде или в логике ограничений

во-первых далеко не всю бизнес-логику удобно писать в декларативном виде, во-вторых, надеюсь, достопочтимому известны некоторые особенности и нюансы пролога как платформы, которые, кхм, несколько ограничивают применение пролога IRL?

Выигрышь в производитнльности в порядки.

надеюсь, здесь имеется в виду скорость написания проекта

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

Хотя на практике ООП превращается в черти знает что

в корявых руках оно всегда так, абстрактная «практика» тут не причём

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

надеюсь, достопочтимому известны некоторые особенности и нюансы пролога как платформы, которые, кхм, несколько ограничивают применение пролога IRL?

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

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

надеюсь, здесь имеется в виду скорость написания проекта

Both. Зацени как чувак накатал решение Судоку в 33 строчки: https://gist.github.com/3217582 . И производительность очень даже (до 400 мс на самых сложных примерах).

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

надеюсь, достопочтимому известны некоторые особенности и нюансы пролога как платформы, которые, кхм, несколько ограничивают применение пролога IRL?

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

ну, как насичот, например:
1) хорошо подходит для описания взаимосвязей, но плохо для описания последовательностей действий
2) в некотрых случаях неспособность системы пролога выработать ответ на вопрос при формально корректной записи программы (да, это касается процедурных значений, но чисто декларативные подходы ограничены)
3) нюанс связанный с получением ответов на вопрос, ты получаешь первый ответ который удовлетворяет условиям, и никто тебе не говорит насколько он является оптимальным, а перебор часто может иметь бесконечное количество ответов... упс

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

итого, не стоит переоценивать и пихать пролог везде, у него есть вполне определённая область применения, где он себя вполне хорошо чувствует

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

надеюсь, здесь имеется в виду скорость написания проекта

Both

прости, но в общем случае так говорить - 4.2

Зацени как чувак накатал решение Судоку

1) это clojure же?
2) пусть он напишет аллокатор :)

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

Тогда недостатки известные, да. Но:

итого, не стоит переоценивать и пихать пролог везде

Анонимус не предлагал пихать его «везде» - предлагалось ограничиться бизнес-логикой. Более того, он довольно туманно выразился «в декларативном виде или в логике ограничений, как это принято в Прологе», под это даже JESS и Drools подойдут.

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

Анонимус не предлагал пихать его «везде» - предлагалось ограничиться бизнес-логикой

ок, поясню тогда более подробно

основная проблема с производством ПО - это сложность, основной источник сложности - это рассогласование моделей проблемной области у пользователей и исполнителей, для устранения данного рассогласования используются ЯП общего назначения или DSL

так вот с точки зрения описания бизнес-логики (БЛ) пролог с одной стороны не представляет инструмента, который позволял бы писать в терминах данной предметной области, то есть он не является DSL для описания БЛ, а сдругой стороны он недостаточно гибок для того чтобы быть использованным в качестве базового языка для создания таких DSL (здесь, как мне видится, куда больше подходит Lisp & Co.)

это если мы говорим целиком за БЛ, но какие-то части, естественно, хорошо и качественно ложатся на модель пролога

shty ★★★★★
()
Последнее исправление: shty (всего исправлений: 1)
Ответ на: комментарий от shty

с точки зрения описания бизнес-логики (БЛ) пролог с одной стороны не представляет инструмента, который позволял бы писать в терминах данной предметной области

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

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

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

как нет, есть же - упоротый язык 1С (и не только он, но он здесь упоминался), сурпрыз-сурпрыз

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

а если без шуток

Такого универсального инструмента вообще нет

1) разговор не шёл об универсальных инструментах
2) универсальность - это из области широкой специализации, мы здесь говорим за узкую
3) пролог никак не помогает писать БЛ, и годится для этого чуть больше чем не очень <--- это основная мысль

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

пролог никак не помогает писать БЛ, и годится для этого чуть больше чем не очень

Если сводить БЛ к бухгалтерии - да, наверное.

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

Когда это бухгалтерия стала синонимом «бизнес-процесса»?

1) note: БП vs БЛ
2) выбросим бухгалтерские дела из описания БП? :)
3) 1С склад или 1С логистика - это тоже бухгалтерия?

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

пролог никак не помогает писать БЛ, и годится для этого чуть больше чем не очень

Если сводить БЛ к бухгалтерии - да, наверное.

1) данное привИдение живёт только в твоей голове, но пусть будет, имеешь право
2) но пример хороший, очевидно, что если пролог не очень хорош в описании некоторых аспектов БЛ, то он не может быть рекомендован как средство описания БЛ в целом
3) приведи хороший, правильный пример (не бухгалтерию), чоужтам

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

Если сводить БЛ к бухгалтерии - да, наверное.

1) данное привИдение живёт только в твоей голове

В твоей. Ты почему-то постоянно говоришь о 1С.

приведи хороший, правильный пример (не бухгалтерию), чоужтам

Чем тебе XCON плохой пример? Но можем зайти на Википедию, пройти по ссылке, и...

http://www.javaworld.com/javaworld/jw-09-2003/jw-0919-iw-jrules.html

«One such „smart tool“ is a business rule management system (BRMS) that takes business logic out of procedural code and puts it where it belongs: in the hands of business analysts. A BRMS can extract and isolate business rules from all of the other control code in an application, allowing business analysts to configure the rules (for discount pricing, loan interest rates, insurance premiums, and so on) using simple if-then-else statements and ordinary business language».

Внезапно, обнаруживаем rule engine (несколько, на самом деле). И Пролог тоже rule engine.

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

1С склад или 1С логистика

XCON - вполне логистика

во-первых это не «логистика», а система заказа, это несколько разные вещи, во-вторых ты соскочил с темы, суть была в том что 1С - это не только бухгалтерия

да, я знаю, что это OPS5

1) в данном случае пофиг, можно считать что с т.з. нашего разговора - это одно и то же
2) именно задачи типа экспертных систем, организации планирования, представления знаний и т.д. пишутся на всяческих прологах влёт, и именно для этого они и хороши

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

1) это clojure же?

Да, с библиотекой для логического программированния. Собственно вся программа написана с помощью ЛП.

2) пусть он напишет аллокатор :)

Почему именно аллокатор? Там вообще ничего сложного нету (писал несложный страничный аллокатор на Форте). Или ты про другое?

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

Ты почему-то постоянно говоришь о 1С.

один раз упомянул, да и то не само 1С, да и то в шутливом контексте, перечитай тред :)

Внезапно, обнаруживаем rule engine (несколько, на самом деле). И Пролог тоже rule engine.

1) Prolog - это тебе не rule engine, это декларативный ЯП :)
2) внезапно, Java работает совсем не так как Prolog, надеюсь ты это не станешь отрицать, как и то что речь шла изначально о Prolog?

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

Почему именно аллокатор?

да первое что в голову пришло, не обращай внимания, давай с другой стороны зайдём - «зачем в хаскелле монады?»

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

ты соскочил с темы

Начались дешевые отмазки. И 1С, который ты приплел, вдруг у меня в голове, и отвечая на твои вопросы я соскакиваю с темы. Читай ссылку, просвещайся.

tailgunner ★★★★★
()
Последнее исправление: tailgunner (всего исправлений: 1)
Ответ на: комментарий от unlog1c

Да, с библиотекой для логического программированния. Собственно вся программа написана с помощью ЛП.

знаешь что от твоего ЛП после конпелятора остаётся - ничего, байт-код для JVM :)

напомню: речь шла именно о Prolog (!)

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

> надеюсь, достопочтимому известны некоторые особенности и нюансы пролога как платформы, которые, кхм, несколько ограничивают применение пролога IRL?

Замени «пролог» на «логику предикатов» и посмейся вместе со мной: ... надеюсь, достопочтимому известны некоторые особенности и нюансы логики предикатов как платформы, которые, кхм, несколько ограничивают применение логики предикатов IRL? (fixed)

> 1) хорошо подходит для описания взаимосвязей, но плохо для описания последовательностей действий

Формальная логика подходит для описания взаимосвязей (в том числе причинно-следственных) и построения выводов на их основе, но плохо для подмены понятий и отстаивания «женских» абсолютов... (fixed) — поэтому логика хреново применима IRL.

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

На проблемы использования доменов .com намекает хотя бы то как первоначальный энтузиазм (бум доткомов) по поводу этой доменной зоны сменился чередой банкротств немалого количества венчурных фондов и прямых инвесторов на западе, что привело к схлопыванию пузыря. (fixed) — поэтому доткому хреново применимы IRL.

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

> с точки зрения описания бизнес-логики (БЛ) пролог с одной стороны не представляет инструмента

Зависит от бизнес-логики.

> не представляет инструмента, который позволял бы писать в терминах данной предметной области

Prolog - это, вообще-то, тупо набор правил для исчисления высказываний, если тебе нужно писать DSL возьми для этого какой-то язык *программирования* с возможность создания DSL, а не язык логики предикатов. Simula / gpss тоже не подходят для «бизнес-логики IRL»? А если «бизнес» это моделирование производственных (т.е. ынтерпрайз) процессов и прочая имитационная хренота? :-)

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

> Кхм. Когда это бухгалтерия стала синонимом «бизнес-процесса»?

В отделе бухгалтерии - ведение бухгалтерии это и есть бизнес-процесс.

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

> Prolog - это тебе не rule engine, это декларативный ЯП :)

Он декларативен лишь для достаточно узкого спектра «логик», основанных на различных выжимках из логики дизъюнктов хорна в перемешку с ограничительными эвристиками. Для описания чего бы то ни было другого Prolog будет обычными такими бессмысленными наскальными рисунками.

> ЯП :)

Скорее, ЯЛ - язык одной конкретной логики.

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

В отделе бухгалтерии - ведение бухгалтерии это и есть бизнес-процесс.

Спасибо, Капитан.

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

напомню: речь шла именно о Prolog (!)

Я согласен, что Пролог неприменим в промышленности, это proof of concept язык, полный своих идиосинкразий. В качестве обучению ЛП вполне пригоден, но не больше.

Другое дело - подмножество логическое программирования, встраимое в язык общего назначения. Тут уж тебя никто не заставляет логически описывать сугубо императивные действия, но при этом ты можешь применить ЛП для нужных тебе участков.

знаешь что от твоего ЛП после конпелятора остаётся - ничего, байт-код для JVM :)

Естественно, так же как и от ФП, и от ООП в переводе в мышиный код ничего не останется, но при чем здесь это? Фишка ЛП в том, что чем декларативнее код, тем больше его сможет соптимизировать компилятор.

Проведу аналогию. Раньше, когда процессоры были попроще и трава зеленее, самым быстрым решением было написание программы на assembly language, ведь у пользователя голова ясная, и он четко знает что хочет сделать (для некоторых embedded-архитектур до сих пор так). Но по ходу, как х86 стала обрастать всё большим количеством возможностей и усложняться, компилируемый код ставал всё быстрее рукописного. Потому что компилятору значительно проще разрулить операции по регистрам (которых на х86 критически мало), чем программисту. Плюс учитывать еще всяческие оптимизации для процессоров - держать это всё в голове очень сложно.

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

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

В 1С уже используют декларативное программирование. Например для генерации форм документов, отчетов, запросов к базе.

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

[..] надеюсь, достопочтимому известны некоторые особенности и нюансы логики предикатов как платформы

логика предикатов - это не платформа

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

Формальная логика подходит для описания взаимосвязей (в том числе причинно-следственных) и построения выводов на их основе, но плохо для подмены понятий и отстаивания «женских» абсолютов...

это ты просто неопытный :)

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

с точки зрения описания бизнес-логики (БЛ) пролог с одной стороны не представляет инструмента

Зависит от бизнес-логики.

в общем случае не подходит

Prolog - это, вообще-то, тупо набор правил для исчисления высказываний

конечно нет

shty ★★★★★
()
Последнее исправление: shty (всего исправлений: 1)
Ответ на: комментарий от alienclaster

если тебе нужно писать DSL возьми для этого какой-то язык *программирования* с возможность создания DSL, а не язык логики предикатов

поэтому мне и непонятно зачем пристёгивать к интерпретатору Lisp ещё и Prolog

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

Для описания чего бы то ни было другого Prolog будет обычными такими бессмысленными наскальными рисунками.

в общем всё так, о чём я и говорил

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

Я согласен, что Пролог неприменим в промышленности

не-не-не, применим, ещё как, но только область применения у него вполне себе ограничена

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

знаешь что от твоего ЛП после конпелятора остаётся - ничего, байт-код для JVM :)

Естественно, так же как и от ФП, и от ООП в переводе в мышиный код ничего не останется, но при чем здесь это? Фишка ЛП в том, что чем декларативнее код, тем больше его сможет соптимизировать компилятор.

не, оптимизация тут не при чём, совсем

если говорить за ВМ, тут различия в том как происходит выполнение программы, будет ли JIT это, будет ли «хождение» по AST или же, как в случае пролога, граф со связями + эвристики, и вот тут разница существенная

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

Не троллинга ради: ты что, и впрямь не понимаешь разницы между CL и Clojure, или притворяешься?

Также интересует этот вопрос. Когда смотрел фишки CL, из интересного, по сравнению с Clojure видел только замену исключений(не помню как оно точно называлось). И еще Reader Macros.

Я не говорю о фишках рантайма, может CL и быстрее, но интересует как раз языковое сравнение. Чем CL лучше Clojure?

Могу сказать, что Clojure понравилось более развитой поддержкой базовых структур, код поприятнее читать. На отсутствие поддержки хвостовой рекурсии пофиг, потому что замена приемлемая, а рекурсия такая же частая операция, как цикл while в Ruby.

Очень неплохо взята идея ленивых последовательностей из Haskell.

JVM дал шанс взлететь. Без него никто бы Clojure не юзал, ибо нахер оно нужно без библиотек.

Напишите, тот кто в тем, какие еще есть фишку у CL и плюсы по сравнению с Clojure?

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

Погугли CL vs. Clojure. При этом почитай соответствующие доводы с обеих сторон, чтобы получить более менее объективную картинку. Кстати, существует реализация CL для jvm - ABCL, которая постоянно развивается. Не стоит про это забывать.

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

поэтому мне и непонятно зачем пристёгивать к интерпретатору Lisp ещё и Prolog

Видимо, есть причина, если существует Common Prolog в LispWorks.

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

Видимо, есть причина, если существует Common Prolog в LispWorks.

кастомеры диктуют фичи. Вот и вся причина. :)

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