DRAKON.SU

Это мировая статистика. Ее можно посмотреть в сети.

.. найти сейчас ссылку на эту статистику у меня не получается.
Но месяц назад по работе искал и находил именно эти данные.

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

Люди, ау! Впору фонарь зажигать... Где Ваши мысли, где предложения?

Мне кажется, что в изложении Паранджанова несколько завышена роль перцепции, то есть непосредственного восприятия. И это при том, что он совершенно правильно указывает на её огромную роль!
В изложении на примере "атомный реактор" и "красавица" делается вывод о том, что сложность в тексте.
Я бы сделал акцент на важности графических шаблонов решения.
Вырастание связей нейронов в мозгу в цепочку - это не то, на мой взгляд.
Посмотрите на пример с Пуанкаре, когда его озарило при посадке - он "проинтуичил" возможность применения шаблона.

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

Нагружение элементов шаблона под конкретную реализацию - это уже другая компонента мышления.

Второе - комбинирование этих стандартных шаблонов-модулей в большую схему "формата A1-A0".

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

А можно пример?
А то без примера тоже... гм... шаблон срабатывает... Сразу .Net вспоминается...

Данное письмо прошу воспринимать не как критику, а опять же как направление развития предложенной идеи, в т.ч. очерчивание проблем, требующих решения!

Хочу отметить следующее противоречие:
- язык должен иметь МАЛО базовых элементов (букв, граф.примитивов и т.п.), чтобы быть обозримым и легко запоминаемым (эта аксиома доказательства не требует);
- чем БОЛЬШЕ стандартных шаблонов использует человек в проектировании, тем лучше (этот постулат требует доказательства).

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

Классический вариант решения - упорядочивание библиотеки (в т.ч. иерархическое). Представьте упорядоченный поиск (Россия, Москва, Красная площадь, ГУМ). И представьте иероглиф (подробная географическая карта). Как она Вам?
Упорядочивание типа "ранжирование" (сортировка). Как найти, к примеру, ул.Керченскую в Москве (вручную найти, мы же про труд человека говорим)? Нашли Москву и листаем УПОРЯДОЧЕННЫЙ СПИСОК. А на карте что делать? Там есть упорядочивание, но оно НАМ ПОКА НЕ ИЗВЕСТНО. Отсюда проблема.

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

То есть, выходит, что далеко не всегда графическое представление выигрышно?

P.S. Хотел дать всем высказаться, но, извините, от комментария не удержался... Уж тема очень интересная!

Уважаемый Максим!

Меня очень заинтересовало Ваше сообщение. Хотелось бы задать несколько вопросов.

Вы пишете: "В нашем "бизнесе" (да и в любом связанном с разработкой) наибольший эффект от Дракона... - не в разработке ПО для ПЛК, а в составлении техзадания на алгоритмы их отработку и взаимное согласование".
Означают ли эти слова, что Вы используете дракон на практике? Если да, расскажите о своем опыте подробнее. Если нет, просьба изложить Вашу мысль в более развернутом виде.
И последнее. Каковы Ваши планы? Собираетесь ли вы использовать Дракон на практике. Расскажите о Ваших планах подробнее.

С глубоким уважением
Владимир Паронджанов

Тем, кто интересуется «Технологией разработки алгоритмов и программ Графит-Флокс», сообщаю, что структурная схема указанной технологии выложена по ссылке http://upload.caxapa.ru/grafit.doc
Благодарю Railway Kagen за помощь в организации ссылки.

Напомню, что Графит и Флокс - это не самостоятельные языки, а две "половинки" одного языка - языка Дракон.
Подробнее см. viewtopic.php?p=13427#p13427
после слов "Это неверно"

Владимир Даниелович, большое Вам спасибо за публикацию структурной схемы!
Поясните, пожалуйста, аббревиатуры УГРА и ТМИ.
2 вопроса по третьему этапу: 1) Сначала идёт отладка только программ, а потом уже программ в увязке с оборудованием, которым они управляют? 2) Программисты и комплексники работают вместе, каждый отлаживает свою часть работы?

1. УГРА - это постоянно обновляемый "самый древний" элемент инструментальной системы создания программ для бортового компьютера Бисер".
УГРА умеет транслировать, редактировать, имеет средства отладки и позволяет формировать "модель памяти". Модель памяти - это начинка, которая загружается в "изначально пустую" оперативную память бортового компьютера "Бисер".
Раньше программы для компьютера Бисер писали на Бисер-ассемблере. УГРА выполняла все функции (трансляцию, редактирование, отладку, создание модели памяти) для ассемблерных программ.
С появлением технологии Графит-Флокс ситуация несколько изменилась. Все инструментальные программы технологии Графит-Флокс создаются как надстройки над "древней" УГРОЙ.

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

3.Вы спрашиваете: "Сначала идёт отладка только программ, а потом уже программ в увязке с оборудованием, которым они управляют?"
Логичный вопрос. На самом деле часто (хотя и не всегда) происходит наоборот. Сначала проводятся проверки функциональных трактов системы управления ракетой на КОМПЛЕКСНОМ СТЕНДЕ СИСТЕМЫ УПРАВЛЕНИЯ . Заодно проверяются программы. При автономной провверке функциональных трактов это сильно упрощает проверку и отработку программ.
И только если встречется очень трудная и хитрая ошибка, производится более тщательная проверка на отладчике.

4. Вы спрашиваете: "Программисты и комплексники работают вместе, каждый отлаживает свою часть работы?"
Ответ таков (для автономной проверке функциональных трактов СУ и входящих в них программ). Начинают работу комплексники. Обычно они могут выявить и исправить свою ошибку без участия программистов.(При этом они, разумеется, выдают программистам на дискетах материалы для перетрансляции).
Но если это ошибка не комплексников, а программистов (или просто сложная ситуация) програмисты, конечно, принимают участие в отладке.

5. Если кто интересуется, сплетни о нашем бортовом компьютере Бисер (и его модификациях) можно посмотреть здесь
http://www.novosti-kosmonavtiki.ru/phpB ... php?t=6220

Ссылка для wiki: http://store.oberoncore.ru/lib/paper/grafit_A4.pdf
Технология разработки алгоритмов и программ "Графит-Флокс"

Добавлено: Присоединенный файл лучше не использовать.

Большое спасибо за подробнейшие разъяснения!

У меня не получилось найти на Вики такой статьи...

wiki.oberoncore.ru

статья Дракон

раздел "Применение"

Вроде ссылка на документ оттуда живая..

Хм.. Не совсем..
pdf, вложенный на форум скачивается как текст.
Вопрос к админам - поскольку отдельного хранилища для файлов по дракону нет, куда переместить grafit_A4.pdf? Вроде прямо в вику грузить не принято.
Дело в том, что на сахАре ссылка временная - умрет в течение месяца, как выйдет из кеша.

Спасибо!

Даже вику подправили. Спасибо.

здесь


Есть. Это inc(PC). Увеличение на единицу ProgramCounter. Выполняется каждый раз автоматически по окончании выполнения очередной команды целевой платформы. Поскольку на сегодня для широких масс не реализованы более экзотические методы исполнения команд, кроме как последовательные, данный оператор пока является умолчательным. Его явное указание для массово применяемых архитектур просто привет к неоправданному загромождению текста программ. Вторая причина - априорная неопределенность в количестве шагов целевой платформы для действий, записанных на языке высокого уровня.

Почти офтоп. Немного о визуальных методах в теоретической физике.
http://sadovski.iep.uran.ru/RUSSIAN/LTF/Diagramm.pdf

p.s. ..эпиграф сильный..

Всё просто здорово, за исключением:
1. всё что видно это какие то рассуждения о чём то.
2. как с наконец познакомиться с самим языком или системой? книг по фэнтэзи полно, а тут вроде про реальность, где она?
3. где сайт разработчика?
Давайте к реалям, если есть давайте, если нет, то извинитесь и закройте тему.

1. Многое уже есть. Просто просмотрите заголовки тем в разделе: viewforum.php?f=62
2. Вы книгу Владимира Паронджанова "Как улучшить работу ума" читали?

А что, собственно, нереального?
Предложен язык спецификации процессов (если Вы про то, где познакомиться, то, например, в книге Как улучшить работу ума).

Разные организации используют этот язык, как им удобно. Ракеты-носители у Роскосмоса летают. Спецификации протоколов рисуются (viewtopic.php?f=62&t=1148). Бизнес-процессы люди описывают. В Active Oberon тоже транслируют. Если у Вас есть задачи, в которых удобно что-то специфицировать ДРАКОНом - специфицируйте.