DRAKON.SU

Отделено: viewtopic.php?p=62596#p62596
Может, всё-таки довести язык до ума... хотя бы с учётом всех высказанных на форуме пожеланий...
И только потом уже "организовывать обучение"?

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

Пока получается, что кое-какие проблемы выявляются, но изменять некому, т.к. те, кто выявляет проблемы, всё равно применяют узко и не могут поменять сбалансировано "с общей колокольни". Вы ведь, Алексей, не возьмётесь?

Логика обоснованная.
Но потом обязательно получится, что доводить до ума никто не будет, потому что "много книг написано" и продолжают писаться новые.

А ведь возможен и другой подход. Если довести, то будет интересно и востребовано даже без сопроводительных книг!

С первой пенсии... возобновлю занятия живописью
А там уже, насколько ресурсов хватит

Т.е. до точной гибридизации, скажем, с импер-частью Оберона/КП? Или ещё что-то имеется в виду?

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

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

Как-то так.

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

А кто делать-то минимальную часть хотя бы будет? И как Вы, скажем, представляете описание языка - видимо, тоже не чисто текстовым?
Визуальная часть - это, наверное, через библиотеки реализуется?

Поясните, пожалуйста.

Считаю прогрессивным подход "форма = обычный (составной) документ" (http://oberoncore.ru/library/pfister_co ... software12, см. рис 2-6). Т.е. в самой форме программировать/кодировать нечего.

У Вас другое видение для форм, или ... для "дракон"-схем ?

В Дельфи форма тоже = обычный документ
Всё дело в программной поддержке работы с ним.

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

Возможные варианты интеграции (так, навскидку):
- используется полноценная RAD-среда, а в отдельные участки кода копипастится код, сгенерированный из Дракон-среды (собственно, как сейчас и делается);
- используются сторонние конструкторы форм, а всё остальное делается в Дракон-среде;
- всё делается в Дракон-среде.

Конечно, максимальный вариант был бы идеален с точки зрения пиара Дракона. Но вряд ли это целесообразно на практике.
Возможно, целесообразным будет даже первый вариант, только тогда Дракон нужно превратить в плагин (или надстройку) для какой-нибудь среды. С Дельфи это сделать можно, с Блэкбоксом, вероятно, тоже...

Но тут появляется сильная зависимость от реализации. Как максимально ослабить эту зависимость? Пока не знаю. Думать надо.

Тоже тут не верно. Но что Вы имели ввиду, я теперь понял, спасибо.

Да ну? А если подумать?
(Хотя, конечно, оффтопик).

В ББ (ББ --- пример, где указанный подход применяется) нет специального конструктора форм, как части среды разработки. Всё что Вы упомянули, для ББ смысла не имеет. Про это я говорил в начале. В этом разница.

Зависит от точки зрения.
Мой взгляд - это мелкие технические детали.
По большому счёту пользователь, разрабатывая программный продукт и работая с ним, всё равно имеет дело с разными частями, слоями, представлениями (view):
- алгоритмическая часть;
- визуальная часть (не обязательно единственная, кстати!);
- декларативная часть;
- вспомогательная (в т.ч. help);
- содержательная (данные, справочники, тексты и т.п.);
- и т.д.

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

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

А как средство обучения - да, хорошо. Но мало. Потому что одна алгоритмика - это далеко не всё, что требуется.

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

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

Кратко говоря, нужно учить методологии формализации знаний - своих и чьих-то - составной частью которой является система языков. Чтобы учни могли действовать примерно по такой, как здесь, технологии.

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

Кстати, для своих целей уже определил, как деклар-часть программ визуализировать.. вот только замечаний или предложений по АТ-языку что-то не наблюдается... типа, можно считать всё правильным?

Б) Как внедрить его (т.е. для чего собственно прозвучал призыв)? Тут тоже два направления: официальное и реальное Имеется ли в виду предлагать включение техноязыка в ГОСы? Тогда ведь нужно дать какие-то материалы для включения; предполагается, что кто-то из Оберон-сообщества разработает их (в связке с КП/ББ)? Или всемерно расширять "внестандартное" использование его в различных дисциплинах? Так это личное дело учителей (в пределах возможности действовать "поверх программ") - кто может/хочет, тот и делает (ясно, что в информатике/ИТ-инженерии больше возможностей у того, кто имеет больший фрагмент учплана).

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

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

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

P.S. Сказанное не является критикой шампур-метода. Напротив, его базовые принципы - шампура, главности/побочности вертикалей, силуэтного деления маршрутов - как раз допускают развитие (в т.ч. и в направлении отражения смысла, не сводимого к порядку следования чего-либо). Что можно сделать на их базе - показывают ПК- и ДМ-языки.

Т.е. Вы говорите о доработке Дракона с графической формы представления алгоритма до (в идеале) универсального средства разработки?

Да. Потому что иначе ему в образовании место найти очень трудно.
А, может, и не особо надо - учитывая все издержки...

На практике мне, например, для программирования контроллеров МЭК-овских языков хватает. Хотя Дракон бы там смотрелся органично, как расширение этого набора.
Для системного программирования я его тоже использую. Но в том ущербном виде, который есть сегодня, польза небольшая. 90% ресурсов уходит на борьбу с ограничениями а) языка, б) "Ты-среды".
Для десктопных приложений... ещё веселее...

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

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

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

Хм?.. А можно посмотреть на пример, когда структурирование (чего: кода или данных?) снижает производительность?..

Алексей, почему вас напрягают рокировки и выравнивания размеров, что бы вы хотели и что предлагаете?

ИС Дракон доработана для пересадки или заземления лианы с возможным пересечением. Возможно это будет соответствовать вашему направлению мыслей при думании о задаче. Будет в очередном выпуске ИС Дракон.