LINUX.ORG.RU

Smalltalk

 , overdose, , ,


0

4

Доброго времени суток. Занимался я раскопками некрофилического характера и натолкнулся на такое утверждение, что Smalltalk лучше всего подходит для проектирования ERP/СЭД/CRM/КИ-систем для предприятия. Отсюда возникли вопросы: 1. Чем smalltalk так хорош для этих задач? 2. В чем недостатки Ъ-ООП? Чем он так плох? 3. Чем система написанная на smalltalk будет лучше аналога написанного скажем на CLISP или Clojure? Ну и: 5. Реализация системы будет под офтопик. Поэтому нужен smalltalk либо под него либо кросс. Что посоветуете? 6. Туториалы/мануалы/литература под него(в первую очередь интуресуют материалы для быстрого старта). Всем спасибо!

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

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

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

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

antares0 ★★★★
()

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

antares0 ★★★★
()

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

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

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

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

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

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

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

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

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

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

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

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

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

power
()

CLISP

Не CLIPS, а CL.

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

Java.

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

Не CLIPS, а CL.

Учту

Java

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

To All:

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

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

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

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

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

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

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

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

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

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

mv ★★★★★
()

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

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

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

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

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

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

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