Что имеем в настоящий момент, при создании информационных систем?

* М + ЯП + SQL + RDB
* М + ЯП + ΝοSQL + ΝοSQL DB
* М + ЯП + XQuery + XSLT + XML + XML-DB
* М + ЯП + SparQL + OWL/RDF + Tripplet Store
* и различные вариации ...

Где М — модель, ЯП — язык программирования логики (Java/Python/C++/C#....)

Каждый элемент списка можно рассматривать как отдельное, независимое информационное пространство, так SQL запрос, код бизнес-логики на ЯП и таблицы в RDB не имеют прямой связи между собой и могут дублировать функционал друг друга. Отсюда проблемы синхронизации кода и данных на разных уровнях и синхронизации уровней между собой. Стоит еще добавить создание документации разного типа для каждого уровня как еще одно информационное пространство.

Чего хотелось бы?

* Запустить проект и последовательно уточнять, детализировать, имея рабочую систему с первого шага.
* Не думать о БД (RDBS, XMLDB и прочих), транзакциях, кластерах, отслеживании зависимостей при внесении изменений в дизайн системы, кэшировании.
* Иметь легко расширяемую, документированную систему на нескольких естественных языках.
* Иметь всю историю изменений кода и данных в ИС.
* Находить явные и скрытые логические зависимости в ИС как в данных так и в коде и решать уровнения.
* Не задумываться об оптимизации и многопоточности, компилятор/интерпретатор найдет оптимальные пути вычисления.
* Гибкости в построении отчетов, возможности формирования отчета как результат диалога с ИС.
* Просматривать отчеты любой сложности видя на экране всегда актуальные данные.
... и еще кучу вещей.

Мы занимаемся созданием языка Animo и среды Animotron для достижения перечисленных "хотелок".
Здесь краткий экскурс https://docs.google.com/document/d/1DrlUT30L1qeRcyjTxGi3Zu5IPUpI4ia3Uu7YHoDYMGE/edit#
Кого заинтересует, просьба оставлять вопросы и комментарии на полях документа или в этом форуме

а нет "человеческого" описания? Если можно не в гугдоксе...
пока нету.

Хотел немного поспрашивать, но из вашего документе нельзя копировать - получается, это просто картинка. Как то несовременно, DOS-ом отдаёт :-)
Можно копировать, можете, даже, экспортировать в любой формат. Более того, можете выделить текст и оставить комментарий к нему на полях. Или спросить в чате прямо в документе, только чат не сохраняется при закрытии документа.

авторкакой видите область применения вашего продукта? Какими видите граничные условия (объем данных, сложность модели и пр.)
Сложность особой роли не играет. Ограничения по объему: милиарды узлов и связей в графе

автореще в 80-х пройденный этап

Ребят, если не секрет, какой этап пройденный еще в 80?
А то мужики-то и не в курсе! Велосипеды изобретают.

авторстранно, что мужики не знают о сетевых моделях, графах и еще куче вещей, которые уже опробованы и проверены на прочность и применимость в различных областях. Все эти ссылки, представления логики в виде графов и т.п. наверняка же должны были изучить ДО а не во время или после.
Хотя я бы с удовольствием посмотрел на очередную реинкарнацию, если бы она была. Почитав материалы понял что пока идет обмен идеями, не более. Или ссылки неправильные?
Да это все было и есть мы только подошли с другого боку. ссылки на гитхаб в статье, если действительно интересно.

Petro123Dmitriy ShabanovА так же языки программирования известные мне работают отдельно от хранилища данных, в анимо хранилище (память) едины для данных и кода, более того находятся в одних топологиях (это свойство роднит с лиспом и вводит в заблуждение).
здесь распишите подробнее.
В анимо нет отдельно модулей, фалов с текстами программ или данными. Вся информация - преобразуется в граф. Некий анимо-объект - это одновременно и объект и функция, тип или свойство для других объектов. И таких объектов может быть сколько угодно, при чем каждый со своим набором характеристик и поведением.
Для изменения поведения объекта не надо делать класс или функцию для данного типа объектов, компилировать или интерпретировать текст программы. Все что нужно, лишь перестроить связи в графе.

Petro123я в курсе, что для того чтобы из мухи сделать человека, надо перестроить ДНК\связи в графе.
Извините за сарказм.
- как проектируется бизнес-логика (от use-case)?

Просто, как и все остальное - выражениями.

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

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

Семантика связей задается неким базовым набором операторов (связь и есть оператор).

ViPRosдаже не как задается (это в принципе техническое решение) - кем задается и в какой форме все ж

Если речь идет о пограничном слое (связь с внешней средой, ввод вывод), то мостами (bridge) преобразующими внешний сигнал в анимо выражение и обратно. Это может быть что угодно: анимо-синтаксис, XML, Json, непосредственно данные протоколов HTTP/XMPP, стандартный ввод вывод - все что позволяет вам ваша фантазия, для этого есть АПИ.

egorychgazdovskyВсе что нужно, лишь перестроить связи в графе.управление версиями какое-то предусмотрено?
как я понимаю, традиционные CVS в вашу систему не заинтегрируешь

Все хранится в графе, можно отследить путь изменений, более того можно добавить такой параметр как время, непосредственно в сам язык. Зачем нужны в таком случае традиционные CVS? Проблема непонимания, наверное, в том что вы рассматриваете ИС как набор сопряженных не зависящих частей БД, сервер приложений, сервер кеширования, сревер CVS и пр. с потоками между ними и как следствие сериализаций/десериализацией на каждом канале. А мы как замкнутую экосистему.

_модDmitriy Shabanov в анимо хранилище (память) едины для данных и кода, более того находятся в одних топологиях (это свойство роднит с лиспом и вводит в заблуждение).
Есть реализации лиспа, где списки (программы и данные) хранятся в БД постоянно.

Это лишь один из аспектов, но было бы интересно взглянуть, не поделитесь ссылкой?

ViPRosgazdovskyпропущено...


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

"входит", "трахает", "иногда", "кого", "седня" это не операторы - это объекты.

ViPRos,

автортолько что вроде говорили что это связи (я понмаю, что это и процессы и одновременно объекты :))

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