В таких системах обычно развиваются скриптовые языки. Обычные языки программирования с выкрутасами и прибамбасами. Эти языки могли запросто быть комбинациями Оберон+АПИ.

А о языках самих этих систем. Языке чертежа, электрической схемы и т.п.

...
Да только я говорю отнюдь не о встроенных скриптовых языках.
А о языках самих этих систем. Языке чертежа, электрической схемы и т.п.

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

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

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

А что имеется в виду? Информатизация обозначений по ЕСКД (и неимперативных по ЕСТД)?

...
Если за программирование системы моделирования на языке электрических схем ещё можно пободаться, то программирование какой-нибудь SCADA на языке FBD и контроллера в её составе на языке LD ( ) уж однозначно относится к программированию. Укажете место данной задачи и подходы к её решению в свете озвученного предложения Оберон+АПИ?

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

Укажете место данной задачи и подходы к её решению в свете озвученного предложения Оберон+АПИ?

В будущем программирование без структурного редактора будет похоже на изучение в школе информатики без доступа к компьютеру.

Комбинаторная классика форумной риторики: связь по форме слова ("программа"), а не по смыслу.

Т.е. именно то, что в этом сообщении и теме в целом обсуждалось, и просматривается. Так?

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

Столько лет Вы говорите о структурном редакторе на форуме... Честное слово, освоить программирование и написать структурный редактор намного быстрее и проще

Ниже поясню и это, насколько смогу...
...

Сергей! Вашему оптимизму, преданности своему делу и вере в успех можно только позавидовать. Серьёзно! Столько лет Вы говорите о структурном редакторе на форуме. Для меня всегда только одно было загадкой: почему Вы сами не напишете этот свой Poor..., простите, Pure Builder? Честное слово, освоить программирование и написать структурный редактор намного быстрее и проще, чем обратить всех в свою веру. Я искренне Вас не понимаю. Ничего личного.

Зато я очень хорошо понимаю, что выделить пару часов на трёп в форуме и пару лет (а хоть бы и месяцев!) на разработку - совершенно разные вещи...

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

...Полагаю, что внимание должно быть сосредоточено не на программировании, а на МОДЕЛИРОВАНИИ.
Пожалуй, как и в любой науке, могла бы быть полезной хотя бы первоначальная классификация, систематизация способов и языков моделирования.

...И здесь, в одной из веток, будет алгоритмизация. И для неё можно предложить уже что-то конкретное - тот же Оберон (или Дракон ). Причём опять-таки, не следует забывать, что, по большому счёту семантика-то у них того... одинаковая! Хотя и равно непригодная для конструирования электрических схем...

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

И комбинация функций представления этих сущностей и функций получения императива работы с ними и будет реализацией DSL (для "предметки", где эти сущности употребляются)?..

Да, совершенно верно. Первое - не приводит к созданию программы, а второе - приводит.

Какая задача-то решается?
Обратите внимание, что я говорю о моделировании, а Info21 о программировании.

Но мы вообще-то давно вышли за пределы темы - в заголовке ещё открытое ПО зачем-то фигурировало!

...

Можете для начала сами себя профинансировать, если задача заинтересовала...

...
Реализация - да. Но акцент не на реализации, а на самом DSL...
...

Всё равно, IMHO, проходим единый процесс моделирования/формализации задачи/предметки... в конце которого выходим на программно-строгое представление...

в разном масштабе...

И обязательно возникает задача перехода от "внешней схемы" (на ДСЛ) к "нейтральной" на инфор-языке (тот же "Оберон+АПИ"). Примерно как писал в этом сообщении. Или не так? тогда как Вы видите процесс "от постановки до кода/педантических инструкций"?..

А конкретному ЯПЗ, специфичному для некоей "предметки", и будет соответствовать набор средств реализации (допустим, тех же функций АПИ - облечённых в форму ББ-библиотек - так я понимаю?). Часть средств "межпредметные", часть - специфичны для реализации этого ЯПЗ. Ну и технология применения этих средств (в формальном смысле - перевода с ЯПЗ на язык реализации).