SObjectizer: I Love This Game! - Средства разработки

Ребята не имею ничего личного к автору, при общении с ним убеждался в его проффесионализме, но увидев статью не смог сдержаться. Софт, написанный на этом движке, (работал с ним лично) это один единый гармонично работающий глюк. Не поддающийся логичному лечению и благодаря вашей работе с годами он только совершенствуется, становясь все более непредсказыемым. Хотя по мне — ничего личного к вам не имею. Но тем не менее могу сказать только одно — ваш софт, написанный на этой платформе это и есть одна единая проблема.
Мультизадачность требует более глубокого анализа и серьезного подхода. Очень много недочетов, всплывающих впоследствии, что серьезно отражается на работе написанных на этой платформе программ. Можно также отметить, что используются слишком громоздкие конструкции для генерации системы имен и классов, что больше характерезует такую работу как диссертационную, а не как коммерческий проект.
Вывод можно сделать только один — ваша работа при дальнейшей разработке может вылиться в докторскую диссертацию.

Здравствуйте, Аноним

Жаль, что общение происходит на анонимном уровне. У меня почта есть, я бы с удовольствием выслушал конкретную критику в адрес SObjectizer-а и разработанных на его основе продуктов.

А>Софт, написанный на этом движке, (работал с ним лично) это один единый гармонично работающий глюк.

Какой именно софт?

A>Но тем не менее могу сказать только одно — ваш софт, написанный на этой платформе это и есть одна единая проблема.

Имхо, такие слова можно отнести к очень большому количеству софта, написанного на "более патентованных" технологиях (CORBA, J2EE, COM).

А>Очень много недочетов, всплывающих впоследствии, что серьезно отражается на работе написанных на этой платформе программ.

Про наличие недочетов я и сам знаю. Но с какими именно довелось столкнуться именно вам?
Ваши слова могли бы существенно поднять приоритет работ над этими проблемами.

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

Например?

Здравствуйте, eao197, Вы писали:

E>Ваши слова могли бы существенно поднять приоритет работ над этими проблемами.

Сразу оговорюсь... аноним — это не я.

Я думаю, самая большая проблема этого продуката — С++.
Причем не то даже плохо, что сам продукт на плюсах написан. А то что прикладные решения прийдется писать на них. Все же не серьзно рассчитвать, что на серевере будет жить море кода с ручным управлением памяти написанного на небезопасном языки и при этом не будет моря глюков.

Учитесь у МС. У них тоже многие серверы на плюсах написаны, но вот прикладникам в основном предлагается развивать их уже в безопасном режиме. И это правильно.

... << RSDN@Home 1.2.0 alpha rev. 620>>

Здравствуйте, VladD2, Вы писали:

VD>Сразу оговорюсь... аноним — это не я.

Я и не сомневался.

VD>Я думаю, самая большая проблема этого продуката — С++.

...Э ... у... ну... так уж получилось. Исторически. И не факт, что если бы в 2001-2002 годах SObjectizer был бы реализован на чем-нибудь управляемом (ближе всего в это время была Java), то SObjectizer получился бы настолько быстрым, каким он является сейчас.

VD>Все же не серьзно рассчитвать, что на серевере будет жить море кода с ручным управлением памяти написанного на небезопасном языки и при этом не будет моря глюков.

Мне кажется, что существующее положение вещей данный довод опровергает. Существует масса кода на C/C++, которые работают в режиме 24x7, не глючат и не падают. Существует не мало кода на Java, который должен был бы работать в режиме 24x7, но падает.

Разговоры о том, что на C++ нельзя писать надежные программы -- это от лукавого. Очень похожи на разговоры о том, что на динамических языках нельзя писать надежные программы. И то и другое не верно. Скорее C++ не облегчает написание надежных программ. Поэтому первый же дятел-разработчик легко вызывает крах большой системы.

К особенностям C++ SObjectizer добавляет еще и свои прибабахи, к которым нужно привыкнуть. Но после этого использовать SObjectizer не сложно.

Меня же больше напрягает в C++ отсутствие настолько продвинутых фреймворков, как JDK или .NET. Поэтому даже выбор библиотеки для работы с HTTP-транспортом или с РСУБД выливается в совершенно не нужную головную боль. И затем оказывается, что в реальной системе от SObjectizer-а всего 20% кода, а все остальное -- это работа с какими-нибудь libcurl, libiconv, otl, libxml2 и пр.

Здравствуйте, eao197, Вы писали:

E>...Э ... у... ну... так уж получилось. Исторически. И не факт, что если бы в 2001-2002 годах SObjectizer был бы реализован на чем-нибудь управляемом (ближе всего в это время была Java), то SObjectizer получился бы настолько быстрым, каким он является сейчас.

1. Уверен, что скорость продукта в большей степени зависит от качества кода и алгоритмов. Ява даст оверхэд в среднем процентов в 20-70. Это не те цифры.
2. Кто сказал, что скорости не достаточно, а надежности избыточно? Вот аноним намекает на то, что как раз недостаточно надежности.
3. Перефразирую себя. Написать один сервер окуратно на С++ задача решаемая. Если потратить много денег/времени на тестирование, то он без сомнения будет работать. Но вот писать прикладной код на С++ — это маразм. На это способны еденицы. И если ты хочешь чтобы твой сервер был востребован, то его АПИ должен быть ориентирован на безопасный язык!

VD>>Все же не серьзно рассчитвать, что на серевере будет жить море кода с ручным управлением памяти написанного на небезопасном языки и при этом не будет моря глюков.

E>Мне кажется, что существующее положение вещей данный довод опровергает.

Это как? У вас море пользователей пишущих прикладные системы с использванием вашего сервера? Или аноним тут не про баги говорил (может это конкрент-провокатор?)?

E> Существует масса кода на C/C++, которые работают в режиме 24x7, не глючат и не падают. Существует не мало кода на Java, который должен был бы работать в режиме 24x7, но падает.

Ой, позволь не поверить. Думаю что работающего прикладного серверного кода написанного на Яве куда больеше чем написанного на С++.

E>Разговоры о том, что на C++ нельзя писать надежные программы -- это от лукавого.

Гарантированно надежные — это факт. Ну, да я не о том. Я о общей надежности решений. Если бы твои слова были бы правдой, то веб-приложения писались бы на С++, а Ява никогда не заняла бы такой огромный рынок.

E> Очень похожи на разговоры о том, что на динамических языках нельзя писать надежные программы.

Что считать динамическими? На динамически типизированных? Все завист от сложности системы. Монолитные огромные наврено сложно писать. А нечто вроде веб-приложений можно. Вот только при этом языка должен быть безопасным. Большинство динамически типизированных языко этому требованию удовлетворяют. А С++ — нет. Потому он и не пригоден для разработки прикладного серверного софта. То жест потенциально конечно и на ассемблере можно написать код без ошибок. Но чем больше объем системы, чем больше и разношерстнее команда разрботчиков, чем меньше сроки, тем меньше вероятность получения надежного продукта. Причем в отличии от типобезопасных языков не факт, что удастся за счет одного-двух талатнливых программистов быстро исправлять глуюки.

E> И то и другое не верно. Скорее C++ не облегчает написание надежных программ. Поэтому первый же дятел-разработчик легко вызывает крах большой системы.

Знашь, я вот сомтрю вокур и удивляюсь. С кем не заговоришь так он не дятел. А вокруг одни дятлы, дятлы, дятлы...

... << RSDN@Home 1.2.0 alpha rev. 620>>

Здравствуйте, VladD2, Вы писали:

VD>1. Уверен, что скорость продукта в большей степени зависит от качества кода и алгоритмов. Ява даст оверхэд в среднем процентов в 20-70. Это не те цифры.

70% это очень приличная величина. Даже 50% это уже слишком много.

VD>2. Кто сказал, что скорости не достаточно, а надежности избыточно? Вот аноним намекает на то, что как раз недостаточно надежности.

С анонимными утверждениями всегда трудно спорить.

VD>3. Перефразирую себя. Написать один сервер окуратно на С++ задача решаемая. Если потратить много денег/времени на тестирование, то он без сомнения будет работать. Но вот писать прикладной код на С++ — это маразм. На это способны еденицы. И если ты хочешь чтобы твой сервер был востребован, то его АПИ должен быть ориентирован на безопасный язык!

Если бы это был сервер... Это же не сервер, а встраиваемая в процесс библиотека. Для C++ она на C++. Для управляемых языков, вполне возможно, нужно будет делать полностью управляемый вариант.

VD>>3. Перефразирую себя. Написать один сервер окуратно на С++ задача решаемая. Если потратить много денег/времени на тестирование, то он без сомнения будет работать. Но вот писать прикладной код на С++ — это маразм. На это способны еденицы. И если ты хочешь чтобы твой сервер был востребован, то его АПИ должен быть ориентирован на безопасный язык!

E>Если бы это был сервер... Это же не сервер, а встраиваемая в процесс библиотека. Для C++ она на C++. Для управляемых языков, вполне возможно, нужно будет делать полностью управляемый вариант.

Добавлю ложку дегтя. Встраиваемая библиотека, которая подтяоивает с собой еще пару десятков библиотек, что в общем-то не добавляет красоты решения.

Сказал бы просто народ не портите мне получение степени и все бы тебе на ура сказали, давай поможем. Но парить всем мозги и отнекиваться от очевидного факта не вижу смысла (все тот же аноним)

Здравствуйте, Аноним, Вы писали:

А>Добавлю ложку дегтя. Встраиваемая библиотека, которая подтяоивает с собой еще пару десятков библиотек, что в общем-то не добавляет красоты решения.

Последняя стабильная версия SObjectizer тянет за собой 6 дополнительных библиотек. Общий объем SObjectizer-а вместе с библиотеками составляет ~110 тысяч строк (включая примеры и тесты). Текущая не стабильная версия, которая создается на основе ACE, использует 7 дополнительных библиотек (с учетом ACE). Все это идет в одном наборе и не требует автономной инсталляции или настройки (посмотреть, как это выглядит, можно на примере ObjESSty, кстати, практически все эти библиотеки используются и самой ObjESSty).

А>Сказал бы просто народ не портите мне получение степени и все бы тебе на ура сказали, давай поможем.

Степень я хотел получить с объектной СУБД (предтечей ObjESSty). SObjectizer никогда не имел отношения ни к науке, ни к моим амбициям в области научных или околонаучных степеней. Более того, мой личный вклад в разработку SObjectizer по сравнению с вкладом, например, Аркадия Косарева, Андрея Лабыча и Василия Гайдукова, настолько мал, что при всем желании я не смог бы выдавать SObjectizer за свое достижение.

A>Но парить всем мозги и отнекиваться от очевидного факта не вижу смысла (все тот же аноним)

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

E>Здравствуйте, VladD2, Вы писали:

Не ну не наглость, а?
Если вы не видели ни разу стабильных проектов на С++ то кто вам доктор???
Если там и есть баги — так де их нет?
Это нормальный процесс написания софта.

Да у нас при ошибке с памятью крешится апликуха.
Минус? С одной стороны да — с другой плюс — сразу видно багу.
У вас же программеры вымаливают у начальства ещё и ещё мощнее тачки.
Плохие программеры?
Ну дык сами выше говорили — сплошь и рядом ........

И кто вам сказал, что 2 хороших программиста не стабилизируют аппликуху на с++? Не избавят её от мемори ликов и тд и тп детских болезней?
Зачем такое говорить?

на плюсы уже 20 лет гонят — а они живут — и БУДУТ ЖИТЬ И РАЗВИВАТЬСЯ!

У вас одни детские болезни — у нас другие — так что не равняйте божий дар с яичницой.

Пишите на своих управляемых платформах "мега сервера" и не морочте людям голову.

Человек выложил свой труд — им с++ не понравился. Может в той работе главный аспект не надёжность и совсем не коммерческое использование.
Это что сказать англичанину — "Вы проиграли в футбол потому, что у вас правостороннее движение."

Здравствуйте, Dj.ValDen, Вы писали:

<...со скипанным согласен...>

DV>Человек выложил свой труд — им с++ не понравился.

Влад прав вот в чем: то, что проект на C++, в данной конкретной ситуации сильно усложняет:
— интеграцию его с приложениями на других языках. Просто потому, что для элементарных вещей, вроде, XML, HTTP, SOAP, XML-RPC приходится искать библиотеки, качество которых может оставлять много лучшего;
— разработку современных приложений с логированием, доступом к БД, работой с XML, поддержкой SOAP, unit-тестингом и пр. Опять же по причине того, что все эти инструменты не объеденены в один согласованный SDK.

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

DV>Может в той работе главный аспект не надёжность и совсем не коммерческое использование.

По поводу надежности: нашелся один аноним, который бросил пару бездоказательных фраз. Не называя ни названий конкретных продуктов, ни увиденных им багов/проблем. И его мнение априори начинает считаться объективным и адекватным. Между тем, компания, которая занимается разработкой и использованием SObjectizer-а, продает свои решения и использует их каждый день. Созданные на SObjectizer системы работают прямо сейчас. Баги есть, как же без них, но крайне редко именно SObjectizer тому причина. Меня бы давно выгнали с работы, если бы мы на SObjectizer-е делали ненадежное ПО.

По поводу коммерции: я не маркетолог и не продавец. Моя цель -- привлечь внимание к SObjectizer. Имхо, нельзя применить только то, чего нет. И если новые применения для SObjectizer-а найдуться, то с коммерцией мы там как-нибудь разберемся.

E>- разработку современных приложений с логированием, доступом к БД, работой с XML, поддержкой SOAP, unit-тестингом и пр. Опять же по причине того, что все эти инструменты не объеденены в один согласованный SDK.

это у вас не объединены

E>Тем не менее, я не согласен, что сейчас все нужно делать на управляемых языках. Были, есть и будут области, где C++ еще долго будет вне конкуренции (просто по эффективности, предсказуемости и низкой ресурсоемкости).

SObjectizer.

А где об этом можно больше узнать кроме как в номере журнала?

Здравствуйте, Dj.ValDen, Вы писали:

E>>- разработку современных приложений с логированием, доступом к БД, работой с XML, поддержкой SOAP, unit-тестингом и пр. Опять же по причине того, что все эти инструменты не объеденены в один согласованный SDK.

DV>это у вас не объединены

А у вас объеденены?

Как, если не секрет?

Я знаю, что, например, Qt все это в одном флаконе предоставляет.

DV> SObjectizer.

DV>А где об этом можно больше узнать кроме как в номере журнала?

Самая полная информация о SObjectizer в виде небольшого учебника по программированию в SObjectizer собрана здесь (~1.2Mb).

Здравствуйте, eao197, Вы писали:

E>Здравствуйте, Dj.ValDen, Вы писали:

E>>>- разработку современных приложений с логированием, доступом к БД, работой с XML, поддержкой SOAP, unit-тестингом и пр. Опять же по причине того, что все эти инструменты не объеденены в один согласованный SDK.

DV>>это у вас не объединены

E>А у вас объеденены?

E>Как, если не секрет?

E>Я знаю, что, например, Qt все это в одном флаконе предоставляет.

ну дык и у нас можно сказать так

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

Простота украшает мир

Здравствуйте, VladD2, Вы писали:
VD>Я думаю, самая большая проблема этого продуката — С++.
Влад, Вы опять о своем, наболевшем?

VD>Все же не серьзно рассчитвать, что на серевере будет жить море кода с ручным управлением памяти написанного на небезопасном языки и при этом не будет моря глюков.
Влад, ну пожалуйста, ткните пальцем где Вы видели море работающего серверного кода с морем глюков. Ну не продаются такие глючные программы! А между прочем рынок серверного софта не вчера появился

VD>Учитесь у МС. У них тоже многие серверы на плюсах написаны, но вот прикладникам в основном предлагается развивать их уже в безопасном режиме. И это правильно.

ЗЫ. Евгений, в чем Влад действительно прав, так это во вопросе интеграции серверного и прикладного софта — должна быть ифраструктура. Без этого никуда, поэтому сложно представить быструю разработку качественного софта построенного на основе SObjectizer (вот тут .NET впереди планеты всей. каким стал в свое время Visual Basic с ActiveX-ом).

Здравствуйте, GU Glez, Вы писали:

GG>ЗЫ. Евгений, в чем Влад действительно прав, так это во вопросе интеграции серверного и прикладного софта — должна быть ифраструктура.

С этим я как раз согласен. См. здесь.

GG>Без этого никуда, поэтому сложно представить быструю разработку качественного софта построенного на основе SObjectizer (вот тут .NET впереди планеты всей. каким стал в свое время Visual Basic с ActiveX-ом).

А можно узнать твой способ деления софта на серверный и прикладной?

Я это к тому, что если пытаться на SObjectizer делать формы доступа к БД, то это совершенно бесполезное занятие. В SObjectizer вообще нет никаких вспомогательных средств для этого. Но вот если представить себе приложение, которое содержит графический GUI и должно управлять какой-нибудь железякой или снимать измерения с этой железяки. GUI часть можно писать на Qt, wxWidgets или MFC. GUI будет работать на основной нити приложения. Часть для общения с железом будет работать на другой нити (нитях). Как-то нужно организовать взаимодействия между этими нитями и объектами, которые в них живут. Тут как раз может помочь SObjectizer. Для этого в виде агентов оформляются объекты для взаимодействия с железом. Так же в виде агентов могут быть оформлены некоторые части GUI (окна). Когда от пользователя через GUI поступает команда на железяку всего лишь нужно переслать сообщение соответствующему железячному агенту. Точно так же, если железячный агент обнаруживает изменения в состоянии оборудования, он отсылает сообщение агенту в GUI и агент получатель отображает это изменение в виде какого-то индикатора.

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

Но в многопоточных приложениях, имхо, такая помощь разработчику со стороны SObjectizer-а означает довольно многое. Предположим, что создается фильтр какого-нибудь телекомуникационного протокола. Выделяется транспортый объект точки входа в фильтр. Он разбирает входящий трафик и преобразует его в прикладные сообщения. Эти сообщения рассылаются в глубь приложения с тем, чтобы кто-то их дальше обработал. При этом транспортый агент так же рассылает сообщения о происходящих событиях в систему логирования. Так же транспортый агент обновляет у себя статистическую/мониторинговую информацию (и эти изменения так же в виде сообщений уходят в подсистему мониторинга). Далее прикладные сообщения поступают агенту-фильтру, преобразуются и отсылаются другому транспортому агенту. Параллельно с этим подсистема логирования и подсистема мониторинга может отсылать сообщения о происходящих событиях на удаленную машину к службе техобслуживания. При этом всем программисту не нужно заботится об очередях сообщений, о блокировках (mutex-ах) и уведомлениях (event-ах или condition variable), о пулах потоков и пр.

Вот это роль SObjectizer как до сих пор видел ее я. То, что SObjectizer написан на C++ -- это следствие истории его развития ("Все мы жертвы цепи нелепых случайностей" (C) К.Вонегут). Если в SObjectizer-е будет заинтересованность, то он может быть реализован и на других языках (не сразу, конечно). Мне хотелось бы понять, будет ли в этом потребность (т.е. заинтересованность читателей журнала и форума) и, если будет, то к какому языку прежде всего нужно будет присмотреться.

Здравствуйте, eao197, Вы писали:
E>А можно узнать твой способ деления софта на серверный и прикладной?
Все это конечно, не более чем вопрос терминологии. Понятно, что для GUI SObjectizer — есть "не то". Вышла ситуация "кто в лес, кто по дрова". Просто я (за всех других учасников форума сказать не могу), но не Вы, как один из разработчиков) хуже представляю как и где нужно использовать SObjectizer. Видимо читал не внимательно

. Одно дело "шампунь и кондиционер в одном флаконе", и другое сложное серверное приложение с GUI-интерфейсом. ИМХО, последнее надо бы разделять, чтобы в последствии слить воедино, но ввиде уже двух независимых программ (насколько это возможно) — одно на C++ (SObjectizer), другая на GC-языке. Вот такое мое видение. Т.к. сервер. программы все время делал один, то намучившись понял, что такой подход является более правильным (читай устойчивым), чем тот, который предлагает "держать все яйца в одной корзине".

Это все касаемо серверно()-клиентских приложений. Если рассматривать программу (любую), построенную как [измерительная часть] + [GUI], тогда да. О чем собственно Вы и пишите:
1.

SObjectizer не является жестким каркасом потому, что он не требует, чтобы все приложение было «написано на агентах». Напротив, SObjectizer позволяет реализовать лишь часть объектов приложения в виде агентов. Так, с помощью SObjectizer создавались CGI-модули, в которых SObjectizer запускался только для выполнения одного действия — запроса данных от другого приложения. После выполнения этого запроса SObjectizer останавливался, а CGI-модуль продолжал свою работу. При этом объем кода CGI, который работал с SObjectizer, составлял всего несколько процентов от общего объема кода модуля.

Также SObjectizer не накладывает органичений на способы интерактивного взаимодействия с пользователем. С помощью SObjectizer можно создавать «черные ящики», работающие вообще без какого-либо диалога с пользователем. Но можно создавать и полноценные GUI-приложения с применением готовых оконных библиотек, таких как MFC, ATL, WTL, Qt, wxWindows и др.

ЗЫ. Статью, к сожалению, я не читал (еще журнал не дошел), но pdf-ник просмотрел. Возможно отсюда и мое недопонимание сути SObjectizer.

Здравствуйте, Dj.ValDen, Вы писали:

DV> SObjectizer.

DV>А где об этом можно больше узнать кроме как в номере журнала?

Ваш вопрос касается только непосредственно SObjectizer.
Но мне кажется, что было бы также полезно познакомиться с литературой, связанной с SObjectizer косвенно. Это могло бы помочь оценить возможности SObjectizer.
Я имею в виду книгу Shlaer, Mellor "Object lifecycles: modeling the world in states". В начале 90-х она была издана на русском языке киевским издательством "Диалектика" под названием "Объектно-ориентированный анализ: моделирование мира в состояниях".
В этой книге детально описан метод ООА, концептуально родственный агентно-ориентированному подходу, примененному в SObjectizer. Евгений (eao197) указывал на него, как на один из "теоретических" источников SObjectizer.
В свое время одно только знакомство с этой книгой помогло мне создать ПО для одного из важнейших компонентов системы безопасности, хотя до того у меня был опыт написания только прикладных программ.
В результате со мной произошло нечто подобное тому, о чем сказал Евгений:

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

Впоследствии я применил этот подход еще в нескольких проектах, связанных с безопасностью. И всегда успешно.
Если подобный способ представления систем (программных и не только) покажется Вам простым и естественным, то тогда, IMHO, и применение SObjectizer не должно вызвать проблем. (Хотя я сужу об этом пока только по описанию SObjectizer. Но практически все кажется понятным и даже естественным).
В дополнение к хорошей концептуальной основе SObjectizer предоставляет готовую архитектуру (чего у меня, увы, не было).

Вывод

: кроме чтения непосредственно литературы об SObjectizer, можно рекомендовать книгу Шлаер и Меллора. Это может помочь в понимании основных принципов SObjectizer.

Здравствуйте, GU Glez, Вы писали:

GG>Одно дело "шампунь и кондиционер в одном флаконе", и другое сложное серверное приложение с GUI-интерфейсом. ИМХО, последнее надо бы разделять, чтобы в последствии слить воедино, но ввиде уже двух независимых программ (насколько это возможно) — одно на C++ (SObjectizer), другая на GC-языке. Вот такое мое видение.

Я тоже думаю, что подобные вещи нужно разделять.
Вопрос в том, как их затем объединять. Один способ -- использовать коммуникационные возможности SObjectizer-а (т.н. SOP). Но тогда в GC-приложении должен быть свой SObjectizer. Поэтому я и говорю, что если потребуется и будет заинтересованность, то сделаем

Мне просто интересно, захочет ли кто-то программировать в агентах, например, в C#, Python, Ruby или OCaml-е, или Lisp-е.

Второй вариант -- использовать для взаимодействия другие механизмы (SOAP, XML-RPC или CORBA). Тогда GC приложению вообще без разницы, написан ли сервер на C++ и SObjectizer-е или на чем-то еще. Такой вариант можно применять прямо сейчас. И в некоторых проектах у нас так и было.

GG>ЗЫ. Статью, к сожалению, я не читал (еще журнал не дошел), но pdf-ник просмотрел. Возможно отсюда и мое недопонимание сути SObjectizer.

А там короткая выжимка из SObjectizer Book, только отдельное внимание уделено перспективам SObjectizer в сложившихся условиях. В частности, этому посвящен раздел "Ложка дегтя" и особенно "Социально-политические проблемы":

Главная политическая проблема SObjectizer в том, что SObjectizer существует только на C++ и только для C++. В частности, возможности SObjectizer для создания распределенных приложений можно использовать исключительно в С++. Конечно, SObjectizer не мешает использовать в этом же приложении иные способы взаимодействия (CORBA, COM, SOAP, XML-RPC). Но и не помогает. А если в приложение встраивается ручная поддержка CORBA или SOAP, то встает вопрос: “К чему тогда вообще использовать SObjectizer?” И ответ на этот вопрос, особенно когда требуется интероперабельность с написанными на других языках приложениями, часто бывает не в пользу SObjectizer.

Еще одна проблема наследуется SObjectizer от C++. В последнее время у C++ появились очень серьезные конкуренты. С одной стороны, это Java и .Net/C# с огромным количеством готовых библиотек и IDE нового поколения. Очень многих программистов от C++ отталкивает отсутствие настолько же удобных IDE (с автодополнением, автоподсказкой, поддержкой рефакторинга) как IDEA и Eclipse для Java, или VisualStudio+ReSharper для C#. В С++ с этим дела обстоят неважно. A у SObjectizer еще хуже — ведь сейчас нет ни одной IDE, способной поддерживать специфические особенности SObjectizer (хотя бы так, как VisualStudio помогла использовать MFC)...

От:	Евгений Охотников	http://eao197.blogspot.com
Дата:	30.12.05 17:19
Оценка:	480 (12) -1

	От:	Аноним
	Дата:	02.01.06 23:29
	Оценка:

От:	eao197	http://eao197.blogspot.com
Дата:	03.01.06 07:23
Оценка:

От:	VladD2	www.nemerle.org
Дата:	05.01.06 18:39
Оценка:	1 (1) +1 -3

От:	eao197	http://eao197.blogspot.com
Дата:	06.01.06 07:51
Оценка:	1 (1) +1

От:	Dj.ValDen	http://ua.linkedin.com/in/dvalchuk
Дата:	08.01.06 20:01
Оценка:	13 (3) +4 -3

	От:	GU Glez
	Дата:	10.01.06 10:53
	Оценка:

	От:	AVC
	Дата:	10.01.06 11:00
	Оценка:	33 (4)