Smalltalk

что Smalltalk лучше всего подходит для проектирования ERP/СЭД/CRM/КИ-систем для предприятия.

Некоректное утверждения, smalltalk прежде всего среда разработки, а не проектирования.

1. Встроеностью gui, средств разработки и во многих случаях интегрированой БД c нативной smalltalk-овской семантикой.

2. Скоростью. OS-реализации часто не умеют оптимизировать цепочку вызовов и вобще не имеют средств для фиксации точек для такой оптимизации. В CL на такой случай всегда можно взять заточеные под оптимизацию лямбды, лексические *let.

3. Опять же интегрированостью. CL в ходе своей opensource-изации практически потерял свои CLIM-овские (и иже с ним) UI-шные наработки. Вот если интересно агитка genera ftp://publications.ai.mit.edu/ai-publications/2004/AIM-2004-005.pdf про то что было. От интересных штук кроме инкрементного компилятора и repl-а практически ничего не осталась.

5-6. yoghurt каждые 2-3 месяца отвечает такие вопросы. Поиск тебе поможет.

P.S А саме банальное присутсвие мультиметодов делает возможным делать first-class связи между объектами и соотвенно внятную объектную модель КИС, но это лирика.

в кложе своя объектная система, в clisp есть clos
З.Ы. что такое Ъ-ооп?

З.Ы. что такое Ъ-ооп?

Там где класыы, методы и.т.д first-class объекты.

ООП на классах далеко не Ъ, но, к сожалению, стандарт де-факто в отрасли.

потерял свои CLIM-овские (и иже с ним) UI-шные наработки.

Там что-то было, чего нет в ffi со свободными GUI-библиотеками?

Ъ-ООП - все в языке есть объект, объекты взаимодействуют между собой по средствам сообщений и т.п.

А какое тогда Ъ-ООП?

в кложе своя объектная система

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

агитка genera про то что было

Эх, такую машину про...ли :(

CLISP

Не CLIPS, а CL.

Smalltalk лучше всего подходит для проектирования ERP/СЭД/CRM/КИ-систем для предприятия.

Java.

значит я сам был дезинформирован, сорри, исправимся

Не CLIPS, а CL.

Учту

Java

Не любитель жабки. Особенно с того момента, когда она стала «синонимина» Oracle.

To All:

Вопрос актуален ^_^

Не любитель жабки.

Люблю-не люблю - это детство. Главный вопрос - целесообразность.

Систему пишу for fan. Поэтому считаю нецелесообранзным писать ее на том, чем лично мне не удобно пользоваться

Систему пишу for fan.

Для вентилятора?

Для вентилятора?

Для фаната. Есть международный клуб любителей ERP-систем. И там всего один участник.

3. Опять же интегрированостью. CL в ходе своей opensource-изации практически потерял свои CLIM-овские (и иже с ним) UI-шные наработки. Вот если интересно агитка genera ftp://publications.ai.mit.edu/ai-publications/2004/AIM-2004-005.pdf про то что было. От интересных штук кроме инкрементного компилятора и repl-а практически ничего не осталась.

CLIM есть в коммерческих CL, но CLIM вообще-то ортогонален CL.

И потерялась только среда (Genera с софтом), а не фичи языка.

Не связывайся с Common Lisp, если не готов к тому, что практически все надо будет делать самостоятельно. Никто не будет тебе помогать, и даже найдя решение какой-то своей проблемы (библиотеку, скажем), ты вскоре увидишь, что оно сильно отстает от коммерческих. Ты придешь жаловаться сюда, что все так плохо, тебе прочитают лекцию про «сядь и напиши», а ты скажешь, что «ваш CL гагно».

Там что-то было, чего нет в ffi со свободными GUI-библиотеками?

В той части в которой presentation-based - протокол отображения програмных объектов на UI и увязки их с действиями юзера, заточеный под CLOS + доп. расширения на type specifier. Такой подход позволял выделять максимально абстрактные операции и затем управляемо транслировать их целевой GUI api, расширяя по необходимости, то есть все заточено под то что бы жестких привязок не было.

Сейчас такое или разводят вручную (в нашем приложении 2000 уникальных форм!) или обходтся подмножеством CLIM-а, в cилу нехватки времени вобще и на осмысление в частности, достаточно урезанным. Я по крайней мере не видел аналоглв покрывающих такую же UI-шную область.

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