Re[5]: Язык ДРАКОН — новая идея в программировании - Философия программирования

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

ВП>Не могу с Вами согласиться. По моему мнению, оптимальным является путь: сначала графика — потом преобразование в код.
ВП>Я опираюсь на свой производственный опыт.
Если это опыт в виде космических проектов — возможно именно для таких проектов это и оптимально. Но космическая отрасль весьма и весьма специфична. Например там требования не меняются, сначала идет составление документации, и очень подробное, затем реализация (не работал в этой отрасли, но по крайней мере про подобное слышал неоднократно, причем эта отрасль даже у буржуев весьма и весьма специфична). Соответственно такие вещи, как рефакторинг, не очень актуальны. Но в 99% случаев программирование предполагает совершенно другую методологию разработки, когда требования постоянно меняются прямо во время реализации, когда время выхода на рынок крайне критично, когда документация и техзадание весьма скудная, часто к моменту начала разработки вообще никто не знает что реально нужно сделать, и к требуемому результату приходят методом проб и ошибок. И постоянное изменение требований — это неизбежность, от этого невозможно отказаться! Если откажешься, то пока сделаешь — продукт будет уже не нужен со старыми требованиями. И вот для таких проектов подход, когда сначала графика, а потом преобразование в код, является полностью не применимым. Вернее даже так — многие пытаются такое применять. Но итог у всех один — многократное затягивание времени разработки и раздутие штатов в результате такого подхода.

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

ВП>Не могу с Вами согласиться. По моему мнению, оптимальным является путь: сначала графика — потом преобразование в код.
ВП>Я опираюсь на свой производственный опыт.
Позвольте охарактеризовать его как отставший минимум на 30 лет от современного состояния индустрии.

ВП>Язык ДРАКОН используется в НПЦАП в виде Технологии разработки алгоритмов и программ "Графит-Флокс". Технология используется во многих крупных ракетно-космических проектах с 1996 года:
ВП>http://drakon.su/_media/biblioteka/grafit_a4.pdf
ВП>Слева — работают инженеры. Справа — программисты.
"Передача дискеты в отдел программистов". Мда. Я бы постеснялся такие слайды показывать вообще (кроме как при обсуждении истории).

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

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

R>>В CryEngine допустим добавляем солдата на карту.
R>>У него есть события "вижуВрага", "слышуВрага" вешаем на них тригер "включить серену" и "бежать в координату X,Y,Z".
R>>На событие "сработала сирена" вешаем "spawn 10 десантников в координате X,Y,Z".
R>>Присваиваем десантникам group id и если один из членов групы "вижуВрага" -> оповестить("group id","атаковать врага id").

R>Вот тут вы небольшой кусочек AI записли в виде текста, а почему же вы не нарисовали его в виде графической диаграммы? Ведь если верить продвигателям визуального программирования это проще, быстрее и эргономичнее.

Я привел примерный порядок действий которые нужно выполнить.
Создавать такие скрипты в редакторе не райское удовольствие, но для пользователя который не знаком с lua/angelscipt и sdk, других вариантов нету.

CryEngine позорно падает когда редактирую AIPath, привожу пример на UE3

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

Помимо неоднократно уже озвученной критики графического представления алгоритмов по сравнению с текстовой, хочется вставить и свои 5 копеек.

1) Данный подход затрагивает только подход к алгоритмам. Т.е. самому "низкому" уровню в написании программы. Вопросы декомпозиции, управления сложностью и пр. оставлено за кадром.

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

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

3) Обучаемость и преемственность. Все хорошие специалисты учились писать и читать код и алгоритмы текстом. Все признанные "классики" (Кнут, Ахо-Ульман, и др) пишут свои примеры на псевдокоде, и не графическими средствами. Подрастающее поколение, которые через 5-10 лет вырастут в "ведущие", сейчас пишут и читают код традиционными средствами. И, значит, традиционный подход будет привычен как минимум 2 будущим поколениям разработчиков.

Ну и на-последок

4) Традиционный подход доказал свою состоятельность. Написаны миллионы программ и алгоритмов, подчас сложнейших. Может ли "ДРАКОН" похвастать сложными программами, разработанными с применением его парадигмы? Как буду выглядеть на нем классические алгоритмы, в тексте записываемые в 10-15 строчек? (Сортировки, LZ, балансировки деревьев)?

Уважаемый Евгений Пасынков!

X>1) Данный подход затрагивает только подход к алгоритмам. Т.е. самому "низкому" уровню в написании программы. Вопросы декомпозиции ... оставлены за кадром.

Это не так. Вопросы декомпозиции проработаны очень подробно и тщательно.

Даю выдержку из книги 2012 года. Книга доступна. В ней 520 страниц. Все изложено подробнейшим образом.

§8. ВЫВОДЫ

1. Головной алгоритм – это алгоритм самого верхнего уровня на лест-
нице декомпозиции.

2. Головной алгоритм может содержать вставки (вызываемые проце-
дуры). Но сам он не может быть вставкой для алгоритма более вы-
сокого уровня.

3. Головной алгоритм – это всегда силуэт. Он не может быть прими-
тивом или системой примитивов.

4. Для создания головного алгоритма используют:

• метод эргономичной декомпозиции;
• метод многостраничного силуэта.

5. Головной алгоритм может быть:

• одностраничным силуэтом;
• многостраничным силуэтом.

6. Одностраничный силуэт размещается на одном листе бумаги (на
одном экране).

7. Многостраничный силуэт размещают на нескольких листах бума-
ги. При работе с экраном силуэт прокручивают по горизонтали.

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

9. Силуэт – главное достоинство языка ДРАКОН. Он обладает мощ-
ными выразительными средствами.

10. Сложные алгоритмы следует изображать как силуэты, в которых
многократно используются иконы «вставка». Последние, в свою
очередь, раскрываются как силуэты и т. д. Таким образом, сложный
алгоритм надо изображать как последовательную декомпозицию
силуэтов.

11. На практике силуэт используют в подавляющем большинстве слу-
чаев.

12. Примитив применяют редко, скорее как исключение.

13. Тем не менее, отказываться от примитива не следует, так как он ну-
жен для описания малых алгоритмов.

14. Кроме того, примитив полезен из педагогических соображений.
Основные понятия и правила ДРАКОНа удобно объяснять на самой простой модели.
То есть на примитиве. И только после этого
переходить к рассказу о силуэте.

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

V>На разбор чужого кода в тексте запросто могут уйти часы, а в графике — всегда считанные минуты.

Да, да, конечно.

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

Давайте подумаем вместе. Что именно доказывает Ваша графика?

1. Графика бывает хорошая и плохая.

2. Вы привели привер ПЛОХОЙ графики.

3. Дракон-схема — это ХОРОШАЯ графика.

4. Так что Ваш пример "не стреляет".

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

ВП>Язык Дракон значительно облегчает алгоритмизацию и программирование
Больше подходит название: Язык Динозавр. Как раз для тех кто из старой советской школы, не смог переучиться вовремя и перейти от блок-схем и чертежей, на языки программирования.

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

ВП>>В заключение скажу твердо: если Вам надо составить СЛОЖНЫЙ алгоритм (100 000 строк или больше) и Ваше главное требование: АЛГОРИТМ ДОЛЖЕН БЫТЬ ПОНЯТНЫМ ДЛЯ ЧЕЛОВЕКА, то Дракон не имеет конкурентов. То, что на этом форуме сгоряча говорят молодые люди, не соответствует действительности.

E>Во первых, сложный алгоритм из 100 000 строк составлять не нужно никогда! Ибо это явно для гениев с IQ под 1000.

Так было вчера, когда еще не было Дракона. Дракон коренным образом меняет ситуацию. Дракон без труда превращает НЕПОНЯТНОЕ в ПОНЯТНОЕ.
Ваш тезис говорит о том, что до появления Дракона Человечество не имело средств для изображения ПОНЯТНЫХ сложных алгоритмов.

E>Люди же со скромным IQ 200 делают декомпозицию и составляют набор простых слабо связанных алгоритмов.

Дракон помогает Вам в этом. И заодно снижает требования к IQ с 200 до 120 или даже до 100.

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

Тут приводили пример составления программы для контроллера замка. Была показана схема контроллера замка. Схема элементарная в графическом виде, вопринимается в среднем за 1-5 мин. Не покажешь пример записи этой схемы в текстовом виде? В общем, это будет нечитаемый нет-лист на полторы сотни строк, который просто описывает компоненты и связи. Прямо как в типичной бизнес-логике программы. Т.е. обычный, плоховоспринимаемый текстовый мусор. Разбираться в таком — от часа. Искать ошибки — от дня.

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

C>>>Бурановский программист в теме уже отметился и сказал, что они ничерта про ДРАКОН не знают.
V>>Он сказал что он бурановский программист, он на обслуживающей инфраструктуре был — пульты делал.
C>Я не верю, что на ДРАКОНе было что-то вообще работающее написано (в документации мог использоваться). Скорее всего, его автор просто врёт.

С чего ты взял?

C>Никаких независимых подтверждений его слов нет.

Пол-но и уже относительно давно.

C>Так же как и вообще известного софта или работающих реализаций самого языка.

Что такое "работающая реализация"?

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

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

Будет ошибкой сравнивать неполноценный UML, с полноценным языком. Тут высказался.

К>Если есть проблемы с тем, что есть структурные диаграммы, можно посмотреть хотяб вики.

Детсад как он есть.

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

X>1) Данный подход затрагивает только подход к алгоритмам. Т.е. самому "низкому" уровню в написании программы. Вопросы декомпозиции, управления сложностью и пр. оставлено за кадром.

Ровно наоборот. Любой набор схем — это в первую очередь декомпозиция, иерархия и описание связей м/у уровнями.

X>2) Предложенный подход, по сути, является еще одной записью императивного подхода. Оно с той или иной степенью "хорошести" ложится на алгоритмические проблемы, однако никак не подходит к функциональному-, компонентному-,

Замечательно подходит. Курить dataflow.

X>мета-программированию,

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

X>и пр., т.е. всему тому что составляет разработку современного ПО "в большом".

Современый мейнстрим — это императив и ничего кроме имератива. Остальное существует постольку-постольку.

X>Но все это можно было бы пережить. и применять для разработки конкретных алгоритмов, если бы не

X>3) Обучаемость и преемственность. Все хорошие специалисты учились писать и читать код и алгоритмы текстом.

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

Схемы подразделяют на семь типов: структурные, функциональные, принципиальные, соединений (монтажные), подключений (схемы внешних соединений), общие и расположения

и ты это как-то сдавал... Экзамен же не покупал, надеюсь?

X>Все признанные "классики" (Кнут, Ахо-Ульман, и др) пишут свои примеры на псевдокоде, и не графическими средствами.

У Кнута и Фаулера непрофильное образование.

У Кнута понятно почему, непонятно почему у Фаулера...

X>Подрастающее поколение, которые через 5-10 лет вырастут в "ведущие", сейчас пишут и читают код традиционными средствами.

Подрастающее поколение выходит из ВУЗов все менее и менее образованным, т.е. разговор ни о чем.

X>И, значит, традиционный подход будет привычен как минимум 2 будущим поколениям разработчиков.

Ерунда. Современный программист не видит своей работы без элементов графического представления, таких как:
— иерархия проекта (пакетов/неймспейсов)
— иерархия классов
— статистика вызовов и использований
— диаграммы вызовов (графы) профайлеров
— графы веток систем контроля версий
— и т.д. до бесконечности.

Никакое текстовое представление графа не заменит графическое. А деревья — это лишь разновидность графов.

X>4) Традиционный подход доказал свою состоятельность.

Традиционный подход — это графика и текст совместно в любой документации:

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

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

V>Потому что UML — это НЕ язык программирования. Это язык абстракций. На нем не напишешь полноценную программу. А на Драконе — напишешь.
Как это не напишешь? Ты Rational Rose видел? Тоже самое, рисуем диаграмки, внутри квадратиков набираем код (тоже скрытый), нажимаем generate — и вуаля, если все правильно то, что нагенерил, даже скомпилится. У меня в студенческие годы получалось. Дракон — крайне похожая концепция, только диаграмки другие. А если брать LabView — там даже генерить ничего не надо, там с помощью квадратиков можно написать полноценную программу. И там тоже есть средства декомпозиции, если что. Еще есть Scratch и BYOB.
Вот на нишу Scratch в принципе замахнуться можно попробовать, то есть применять язык в обучении студентов. Возможно даже выйдет что толковое из этого, ибо Дракон, насколько я видел, поощряет так называемое wishful thinking — если этому наконец будут учить студентов с первых курсов, наконец студенты будут учиться программированию в институте, а не на работе (а многие и на работе так и не осиливают все это). Только надо так среду дорабатывать, чтобы его можно было использовать в качестве первого языка, чтоб что то осмысленное вроде hello world или пляски каких либо спрайтов под музыку можно было написать интуитивно, не читая документацию и не просматривая видео.
Да, кстати — очень бы хотелось увидеть пример реализации быстрой сортировки на Драконе. Крайне хочется оценить понятность.

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

X>>1) Данный подход затрагивает только подход к алгоритмам. Т.е. самому "низкому" уровню в написании программы. Вопросы декомпозиции ... оставлены за кадром.

ВП>Это не так. Вопросы декомпозиции проработаны очень подробно и тщательно.

Структурная декомпозиция — вещь, известная примерно 50 лет. Это был прорыв в разработке ПО тех лет.

Однако индустрия не стоит на месте. И экспериментально давно доказано, что структурная декомпозиция работает хорошо ТОЛЬКО на микро-уровне, т.е. в пределах одного алгоритма или связки 2-3 алгоритмов.

А дальше — ООП, аспекты, компоненты, мета-... и прочее.

ВП>Даю выдержку из книги 2012 года. Книга доступна. В ней 520 страниц. Все изложено подробнейшим образом.

Ничего нового

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

X>>2) Предложенный подход, по сути, является еще одной записью императивного подхода. Оно с той или иной степенью "хорошести" ложится на алгоритмические проблемы, однако никак не подходит к функциональному-, компонентному-,
V>Замечательно подходит. Курить dataflow.

И что — кто-то в графическом виде оперирует с dataflow больше чем 20-30 узлов? Не верю.

V>Дракон — это мета-программирование само по себе. Другое мета-программирование будет другим, иногда принципиально другим. В том-то и дело, что метапрограммирование — это всегда некий трюк по выходу на новую степень абстракций. Графика — это лишь один из таких трюков, работающий из-за "врожденной" иерархичности элементов.

Слова знакомые, а мысль от меня ускользает....

Я, по свей наивности, всегда считал мета-программированием то, что выполняется на этапе компиляции.

X>>и пр., т.е. всему тому что составляет разработку современного ПО "в большом".
V>Современый мейнстрим — это императив и ничего кроме имератива. Остальное существует постольку-постольку.

Да ну. JavaBeans — классический компонентный подход.
Stateless servlets — классическая функциональщина, хоть и записываемая в императивном стиле

V>Схемы подразделяют на семь типов: структурные, функциональные, принципиальные, соединений (монтажные), подключений (схемы внешних соединений), общие и расположения
V>и ты это как-то сдавал... Экзамен же не покупал, надеюсь?

Я этого не учил

Непрофильное образование

0101 — Мат.Анализ.

X>>Подрастающее поколение, которые через 5-10 лет вырастут в "ведущие", сейчас пишут и читают код традиционными средствами.
V>Подрастающее поколение выходит из ВУЗов все менее и менее образованным, т.е. разговор ни о чем.

Я говорил не про ВУЗы. Я говорил про обучение в сильных командах.

X>>И, значит, традиционный подход будет привычен как минимум 2 будущим поколениям разработчиков.
V>Ерунда. Современный программист не видит своей работы без элементов графического представления, таких как:
V>- иерархия проекта (пакетов/неймспейсов)
V>- иерархия классов
V>- статистика вызовов и использований
V>- диаграммы вызовов (графы) профайлеров
V>- графы веток систем контроля версий
V>- и т.д. до бесконечности.

МОЛОДЕЦ!
Все твои примеры — это СЛЕДСТВИЕ кода (т.е. взгляд на код под разными углами), но ни как не его ПРИЧИНА.

Я очень даже поддерживаю различные диаграммы и графики. Но, посмотрев на них и сделав выводы, возвращаюсь к ТЕКСТУ для изменения.

X>>4) Традиционный подход доказал свою состоятельность.
V>Традиционный подход — это графика и текст совместно в любой документации:
V>Не понимаю, почему у некоторых чешется обязательно противопоставлять одно другому. Графические среды — это лишь попытка заполнить пропасть м/у документацией и целевым продуктом. Нормальное, ИМХО, желание.

До тех пор пока графы и диаграммы помогают понять код — "you'r welcome"!
Как только пытаются в эти графы запихать ВСЮ программу,и обязать ее модифицировать тоже через графическое представление — fail.

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

E> ... применять язык в обучении студентов. Возможно даже выйдет что толковое из этого, ибо Дракон, насколько я видел, поощряет так называемое wishful thinking — если этому наконец будут учить студентов с первых курсов ...

Применение языка ДРАКОН в системе высшего образования

В 1996 году Государственный комитет по высшему образованию Российской Федерации включил изучение языка ДРАКОН в программу курса «Информатика» для направлений:

510000 — Естественные науки и математика
540000 — Образование
550000 — Технические науки
560000 — Сельскохозяйственные науки

Даю ссылку на официальный документ
http://drakon.su/_media/biblioteka/progr_drakon.pdf

В официальном документе Госкомвуза «Примерная программа дисциплины „Информатика“» имеется раздел, посвященный языку ДРАКОН и использующий его понятийный аппарат:

Раздел 3. АЛГОРИТМЫ И АЛГОРИТМИЗАЦИЯ. ВИЗУАЛИЗАЦИЯ АЛГОРИТМОВ

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

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

Понимаемость алгоритмов и методы её улучшения. Понятие эргономичного алгоритма. Равносильные преобразования визуальных алгоритмов, позволяющие улучшить их понимаемость: рокировка, подстановка, вертикальное и горизонтальное объединение, визуализация логических формул в условных операторах.

Две формы представления алгоритмов: визуальная и текстовая. Визуальные и текстовые языки и псевдоязыки. Преобразование алгоритмов из визуальной формы в текстовую и обратно. Преимущества визуальной формы. Анализ визуальных алгоритмов методом застывших условий. Язык абстрактных ДРАКОН-схем как инвариант класса процедурных языков.

В документе Госкомвуза «Примерная программа дисциплины „Информатика“» содержится обоснование концепции и структуры учебного курса информатики и, в частности, дается обоснование использования языка ДРАКОН:

1. Среди требований, предъявляемых к современным алгоритмическим языкам, на первое место все чаще выходит понимаемость (comprehensibility) алгоритмов и программ, которая определяется как «свойство программы минимизировать интеллектуальные усилия, необходимые для её понимания»[16] Это объясняется тем, что «в современных условиях качественная программа должна обладать, помимо надежности и эффективности, ещё и такими важнейшими качествами как понимаемость и сопровождаемость»[70]

Наиболее мощным средством для улучшения понимаемости является визуализация алгоритмов и программ: «общепризнанно, что человеческий мозг в основном ориентирован на визуальное восприятие, и люди получают информацию при рассмотрении графических образов быстрее, чем при чтении текста»[71]…

2. … В связи с этим тема «алгоритмы и алгоритмизация» (см. раздел 3 программы) излагается в рамках визуальной парадигмы, что позволяет получить ряд преимуществ: облегчить изучение темы, улучшить эргономические характеристики алгоритмов и т. д.

3. Синтез идей информатики и эргономики полезен тем, что процесс алгоритмизации (который во многих случаях требует значительных трудозатрат) становится менее трудоемким и более ясным. Для этого вводится понятие «эргономичный алгоритм». Излагаются равносильные преобразования алгоритмов, способные улучшить их эргономические характеристики. При этом алгоритмизация и программирование рассматриваются как частный случай более общей проблемы — систематизации, структуризации, представления и формализации человеческих знаний[72]

4. Сближение понятий «алгоритм» и «процедурное знание» дает возможность расширить понятие алгоритма и распространить его на любые технологии (промышленные, сельскохозяйственные, медицинские, образовательные и т. д.[73] Это позволяет в эргономически разумных пределах формализовать описание технологий с помощью визуального алгоритмического языка. В результате описание техпроцессов становится более наглядным и четким, освобождается от пробелов и двусмысленностей. Такой подход обещает заметный выигрыш. Во-первых, благодаря наглядности сокращаются сроки и трудоемкость изучения современных технологий, что особенно важно в рамках концепции непрерывного образования. Во-вторых, формализация и полнота описания техпроцесса может содействовать укреплению технологической дисциплины на производстве и в других областях.

5. Для решения столь масштабных задач нужен универсальный язык представления процедурных знаний в любой предметной области. Это должен быть язык нового типа: общедоступный, человечный, предельно легкий в изучении и удобный в работе, создающий наиболее комфортные условия для человеческого мозга, позволяющий решать проблемы ценою минимальных интеллектуальных усилий, удовлетворяющий самым строгим эргономическим и дидактическим требованиям. Анализ показывает, что в наибольшей степени этим требованиям соответствует процедурный язык визуального представления знаний и визуального программирования ДРАКОН (Дружелюбный Русский Алгоритмический язык, Который Обеспечивает Наглядность), являющийся обобщением опыта, накопленного при создании космического корабля «Буран»[74][75] ДРАКОН задуман как «один из самых легких языков представления знаний и самый первый язык, с которого нужно начинать обучение алгоритмическому мышлению и программированию»[76]

6. При коллективной интеллектуальной работе важную роль играет интеллектуальное взаимопонимание и интеллектуальное взаимодействие между специалистами. Для улучшения взаимопонимания необходимо иметь общую языковую основу. Благодаря своей человечности (эргономичности) язык ДРАКОН относительно легко устраняет барьеры взаимного непонимания (в части процедурных знаний) между работниками различных специальностей: врачами и физиками, математиками и конструкторами, биологами и экономистами, программистами и технологами и т. д. Тем самым ДРАКОН создает универсальную языковую основу для процедурного интеллектуального взаимодействия между людьми, в частности, между участниками многопрофильных проектов. В результате этот «язык взаимопонимания» заметно упрощает междисциплинарное и иное общение между представителями разных организаций, ведомств, отделов, лабораторий, научных школ и профессий, отчасти играя роль «производственного эсперанто».

7. Бакалавр любой специальности должен уметь формализовать свои процедурные профессиональные знания самостоятельно, то есть без помощи профессиональных программистов или когнитологов (инженеров по знаниям). Программа предусматривает приобретение навыков автоформализации знаний на языке ДРАКОН.[77]

О дальнейшем развитии событий расскажу в отдельном сообщении.

	От:	Wolverrum
	Дата:	26.05.12 11:40
	Оценка:

От:	Владимир Паронджанов	http://drakon.su/ Форумы сайта http://forum.drakon.su
Дата:	26.05.12 12:38
Оценка:	23 (2)

	От:	elmal
	Дата:	26.05.12 13:39
	Оценка:

	От:	Cyberax
	Дата:	26.05.12 14:31
	Оценка:	+1

	От:	roro
	Дата:	26.05.12 19:11
	Оценка:

От:	xvost	http://www.jetbrains.com/company/people/Pasynkov_Eugene.html
Дата:	27.05.12 06:23
Оценка:	+6

От:	Vain	google.ru
Дата:	27.05.12 13:32
Оценка:	1 (1) +1 -1