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

_>Я больше чем убежден, что прежде чем писать ТАКИЕ проекты

Под "ТАКИМИ" понимается SObjectizer? Или вообще разработка библиотек и фреймворков?

_> надо знать как минимум логику работы
_>1) Процессора (выборка-исполенние)
_>2) Памяти
_>3) Контроллеров прерываний и их взаимодействие с процем
_>...ну и, короче, знать основы работы на НИЗАХ как и почему и хотеть(!) интересоваться этим дальше.

Это очень спорное утверждение, выходящее за рамки обсуждения SObjectizer, но все-таки можно ли его обосновать?

_>А именно для того, чтобы не изобретать велосипеды. Зная железо вы будете постоянно проводить аналогии с программированием наверху! Я никогда не возьму на работу программера на .NET если он не знает ассемблера, так как его грамотность в архитектуре приложений скорее всего оставляет желать лучшего. (А это самое главное, синтаксис языка — на самом последнем месте).

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

_>Заметьте все части компа работают в ассинхронном режиме, и ничего не валится. Причем некоторые моменты поистине гениальны в железе. Взять для примера хоть алгоритм работы 2-х кешей в двух ядерном процессоре — подика придумай как его на SObjectizer написать (теоретически). Я уверен все накроется или, по крайней мене, доставка сообщений будет не оптимальна. Есть замечательные слова — разделя и властвуй. У вас есть иерархический протокол сообщений с возможностью надстройки или смены протокола? Тут зашел разговор про маршрутизацию, Сразу же надо знать почему в компе ее нет, а в локальных/глобальных сетях есть. В чем плюсы и недостатки. От куда столько сетевых протоколов и как они работают. Тогда и не было бы демогогии что лучше. Это все к вопросу о велосипедах.

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

Если же вы думаете, что при разработке программного обеспечения (software) нужно искать аналогии в аппаратуре (hardware), то может быть скажете, где в аппаратуре можно найти аналогию сборки мусора (GC)?
Это я к тому, что на мой взгляд, в мире не так уж много принципиально разных идей. И какая-нибудь идея может иметь разные воплощения в разных областях, будь то software или hardware (как то асинхронное взаимодействие). Вот только совсем не факт, что какая-то реализация идеи в hardware должна становиться догмой в software.

_>Не надо тут говорить, что у SObjectizer уникальная идея. я больше чем убежден (более-менее серьезный разговор это развеет) что это не так.

А где было сказано, что SObjectizer -- это уникальная идея?
Наоборот, подчеркивалось, что многие вещи были взяты из других источников (см., например, сообщение AVC

Автор: AVC
Дата: 10.01.06

).
А люди, знакомые с Erlang-ом сразу говорят, что SObjectizer выглядит, как попытка реализовать Erlang в C++.
Повторюсь, в мире не так уж много оригинальных идей.

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

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

_>Несмотря на такую критику я не против такой идеи, только меня насторожило следующее: автор сказал, что у них нет идей, что делать дальше.

Не говорил я такого.
Я сказал:

Его возможностей (как внутреннего инструмента) вполне достаточно. Поэтому можно сказать, что нет свежих идей, которые бы дали новый толчок развитию SObjectizer.

Идеи как раз есть. Только это все наши собственные идеи. А хотелось бы услышать новые, неожиданные, из тех областей, про которые мы, возможно, даже не слышали. Чтобы в идеале кто-то взял и сказал: "Я считаю, что SObjectizer мог бы пригодиться вот здесь, но для этого нужно, чтобы он поддерживал то-то и то-то."
А мы бы в ответ: "Ух ты! А ведь действительно... Погнали!"
Но еще важнее, чтобы реализованная в SObjectizer идея была бы опробованна на практике. Чтобы не оказалось, что мы сделали фишку, предоставляющую только академический интерес.

Ну, например, время от времени возникает желание сделать сообщение-сигнал. Т.е., если сообщение A было отосланно, но еще не обработано, то повторые отсылки A не приводят к появлению новых экземпляров A. Или иногда высказываются предположение, что очереди заявок к агентам можно было бы ограничить по глубине. Скажем, стоит в очереди 2000 событий, новое не ставится, т.к. агент перегружен. Или идея перехвата сообщений с возможностью возобновления его обработки в дальнейшем. Или идея о сохранении сообщений в очередях на диске для обеспечения их гарантированной доставки...

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

_>У людей в белых халатах из Research-центров всегда есть куча идей и куча денег — нет времени это все реализовать.

Мы не люди в белых халатах из Research центров.
Интервэйл (пока) не Microsoft, не Sun, не HP, не Siemens и, тем более, не IBM. Так что у нас элементарно нет кучи денег на то, чтобы нанять 5-10 человек на полный рабочий день для клепания новых версий SObjectizer-а.
И при этом, не смотря на отсутствие белых халатов и кучи денег, времени все равно не хватает.

Если же у кого есть куча денег, которые он хочет вложить в Research, то мы с удовольствием поможем эту кучу освоить

_>Собственно интересна ранняя история такой идеи, с чего бы вдруг ей зародиться?

Ранняя история описывалась в ранней же моей статье История одного проекта. Но если этого не достаточно, то я могу сделать небольшой экскурс от истоков до сегодняшнего дня.

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

А нынешний вид SObjectizer и так оОочень сильно отличается от того, что было в самом начале.