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

E>Под "ТАКИМИ" понимается SObjectizer? Или вообще разработка библиотек и фреймворков?
Имеется ввиду проекты с предполагаемым числом строк в 100000.

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

E>Это очень спорное утверждение, выходящее за рамки обсуждения SObjectizer, но все-таки можно ли его обосновать?
Просто: Мне кажется, что многие менеджеры обработки данных: агент, роутер, свич, светофор наконец. имеет одну и ту же природу — обработывают данные. Знание плюсов и минусов одинаковых по природе объектов, но различающийхся по способу обработки развивает кругозор, позволяет быстрее входить "в тему", понимать логику работы, предлагать лучшие варианты сходу (так как у работника большой кругозор!). Мне трудно судить по вашему знанию аппаратных средств, но компьютер устроен так же — посылка сообщений некоторым своим частям через прерывания, которых есть приоритет, на прерывания можно "подписаться" можно посылать прерывания по таймеру, замаскировать их ну и тд. Наверно, идея понятна, кто владеет информацией — владеет всем миром.

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

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

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

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

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

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

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

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

E>Хочется сохранить разумный баланс между функциональностью SObjectizer и сложностью его реализации. Чтобы не превратить SObjectizer в барахолку неиспользуемых возможностей, которую очень трудно сопровождать.
А это уже вопрос архитектуры, разделения проекта на функциональные части, огранизации производства. 2-3 человека это сопросождать не смогут 100%.

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

E>Ранняя история описывалась в ранней же моей статье История одного проекта. Но если этого не достаточно, то я могу сделать небольшой экскурс от истоков до сегодняшнего дня.
E>А нынешний вид SObjectizer и так оОочень сильно отличается от того, что было в самом начале.
Отлично, осталось только добавить, то что нужно вам. А что добавлять должны решать как минимум 3 человека
Надо написать список плюсов и минусов (а для этого как я говорил надо иметь знания в других областях) прийти к общему мнению.

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