Уважаемый Тимур, Вы сделали важный вывод в развитии программирования.

К парадигме ООП - объектно ориентированного программирования Вами добавлена новая парадигма программирования - АОП - алгоритм-ориентированное программирование.





Реализация и развитие языка Дракон в интегрированной среде DRAKON позволяет реализовать и использовать обе парадигмы ООП и АОП. В предложенной технологии процесс программирования разделен на 4 автономных части.

Отсюда


И.с. DRAKON сформировалась в процессе обсуждения в этой теме в течении года.

Внимание !!!

К парадигме ООП - объектно ориентированного программирования, сегодня добавлена новая парадигма программирования.

ОГО! Теперь их уже две, что ли?!!

ООП позволяет организовать данные.

АОП позволяет реализовывать сложные алгоритмы исходя из выбранных данных.

Тут как в той поговорке про яйцо или курицу - что первое. Так и здесь - проблема выбора - с чего лучше решать задачу с алгоритмов или с данных. Как показывает опыт, в больших системах - с данных, а в локальных фрагментах этих систем - с алгоритмов. И процесс этот итеративный - ООП-АОП-ООП-АОП... с движением к некоторому оптимуму. ООП хорошо разработано, имеет средства автоматизации, проверок на баги, различные фичи (e.g. 50 (35) рекомендаций на С++ Скотта Мейерса).

Теперь же делаются попытки создать АОП.

Так вот и вопрос - в чём плох (или хорош) Дракон как средство именно для АОП (самоустраняясь от данных). В Драконе введён принцип пространственных семантических блок схем - когда расположение элементов играет роль в представляемом ей алгоритме. Разумеется, любую такую блок-схему можно всегда (?) свернуть в классическую блок-схему инвариантную к расположению её элементов.
Тут надо осознать, что Дракон, представляющий парадигма АОП придуман для лучшего понимания человеком.

На запрос "алгоритм-ориентированное программирование" поиска в Интернете ссылки не находятся, что свидетельствует о новом подходе (парадигме) в программировании.

Александр, не понял Вас, Вы пишите не по теме.

Для чего?

Вы правы, прошу прощения. Не удержался.

Сопоставление UML и Дракона очень важно по нескольким причинам:
1. UML является стандартом де-факто для подготовки спецификаций в промышленном программном производстве.
2. Дракон обладает богатым потенциалом для развития в направлении единого языка спецификаций.
3. Постепенно зреет понимание, что открытые исходные тексты без открытых спецификаций являются большей частью технологическим мусором. Следовательно, требуется хороший инструмент для представления спецификаций.
4. В России ощущается явная потребность в унификации решений и формировании новых технологических платформ с целью минимизации зависимости от конкретных ОС и конкретного инструментария. Прежде всего, в прикладной сфере. Для унификации требуется уровень спецификаций.
5. Не исключаю возможности, что Дракон может быть серьезным кандидатом на роль (единого) языка спецификаций (как минимум, в области ПО) на уровне национальных или отраслевых стандартов. По крайней мере, есть все основания инициировать подобный вектор развития.

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

На мой взгляд, имеет смысл направить усилия в сторону формирования общественного Центра компетенции Дракона (например, на базе OberonCore) и начать готовить базу аргументации на основании уже проделанной работы за минувший год обсуждения в этом форуме.

Класс языка:

мультипарадигмальный:
визуальный
императивный
процедурный
структурный (неклассическая двумерная структуризация)
автоматный
параллельный
реального времени
end-user development
кроссплатформенный
гибридный

Сопоставление UML и Дракона очень важно по нескольким причинам:

1. UML является стандартом де-факто для подготовки спецификаций в промышленном программном производстве.

2. Дракон обладает богатым потенциалом для развития в направлении единого языка спецификаций.

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

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

5. Не исключаю возможности, что Дракон может быть серьезным кандидатом на роль (единого) языка спецификаций (как минимум, в области ПО) на уровне национальных или отраслевых стандартов. По крайней мере, есть все основания инициировать подобный вектор развития.

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

Особый интерес может представлять разделение на декларативный и императивный уровни представления спецификаций с помощью Дракона и/или его модификаций.

На мой взгляд, имеет смысл направить усилия в сторону формирования общественного Центра компетенции Дракона (например, на базе OberonCore) и начать готовить базу аргументации на основании уже проделанной работы за минувший год обсуждения в этом форуме.

4. Напомню, что Дмитрий Владимирович Барановский (Дмитрий В Б) предложил термин "силуэтное програмирование", правда, без термина "парадигма".