Интересный документ. Зацепил очень многие из собственных соображений.
Попробовал изложить "зацепленное", но времени причёсывать нет, поэтому изложение сильно черновое.
=======
1. О концепции единой графической среды.
Концепция представляется глубоко правильной (она, в общем, не нова, но её постановка ещё раз, с современных позиций и в контексте Дракона и Оберона, представляется очень полезной).
Один из самых удручающих моментов в современном программостроении - это разобщённость решений. Такая разобщённость, которая для понимающих людей (например, "оберонщиков") выглядит просто "сизифовым трудом". Например, у разработчиков на массовых технологиях нет даже привычной для программистов на Компонентном Паскале/Блэкбоксе унифицированной базы для составных текстовых документов, которая позволяла бы разработчикам приложений унифицированно предоставлять такой сервис и его расширения пользователям. Каждый вынужден решать эту задачу повторно, многократно, одинаково некачественно (потому что невозможно решать такую сложную задачу в индивидуальном порядке). Нечего и говорить про следующий уровень - графического редактирования, на нём всё ещё хуже.
Естественные потребности алгоритмизировать и интегрировать программные решения сегодня обеспечиваются зоопарком скриптовых языков, внешних форматов и протоколов и т.п. В общем, всё очень "запущено". Хотя те, кто работает в операционных средах вроде Блэкбокса, Смоллтока и т.п. знают, как это может быть решено.
Тот же Блэкбокс можно рассматривать применительно к обсуждаемым идеям как верный прототип, серьёзный шаг в нужном направлении. Правда, пока что покрывающий программирующую целевую аудиторию и обеспечивающий текстоцентричные задачи. Двигаться дальше можно, перепроектировав, развив систему на новом уровне.
2. О парном к Оберону языке
С одной стороны, вполне понятно, от каких соображений отталкивается автор. С другой стороны, первое желание такой язык иметь может оказаться... скоропалительным. Это не значит, конечно, что в итоге не будет смысла его иметь. Но, может быть, для другого профиля, других проблем, чем кажется изначально.
Здесь я выскажу несколько отдельных соображений, без какого-то обобщающего мнения.
Во-первых, эмпирический факт: в Оберон-системах Оберон успешно выполняет функции макроязыка/скрипта, как раз это мы считаем традиционным преимуществом. В частности, говорим о том, что то, что пытаются получить, скрещивая тот же С и Питон (динамичность-гибкость и компилируемость-быстродействие), уже имеется в виде одного языка. Т.е. задача традиционных макроязыков на Обероне успешно решается без отдельного языка. Но это не значит, что нет каких-то новых задач (исходящих из специфики той же единой пользовательской среды), которые пока ещё не решаются.
В принципе, в качестве языка верхнего уровня можно рассмотреть правила записи и комбинации команд и "органов управления" в пользовательской среде. Какие-то конвейеры передачи результатов между операциями и проч. В ББ это обеспечивается в том числе спец. графическими объектами в активном тексте. Т.е. часть таких задач решается на уровне объектов интерфейса, активного документа.
Во-вторых, существует специфика задач интеграции компонентов (обеспечения вот этого "конвейера" между компонентами), требующая особых структур данных, удобных для этого. Как раз тот момент, который Вы отмечаете, говоря о том, что язык этого верхнего уровня должен быть ориентирован на текст. Ещё в СССР у тех же новосибирцев были языки вот такого тексто-ориентированного, интегрирующего характера. Сегодня эта специфика присуща распространённым скриптовым языкам типа PHP, ECMAScript(JavaScript). (Я не упоминаю более серьёзные языки, ориентированные на разнообразные структуры данных, функциональные языки, в частности). В принципе, структуры данных для удобного решения задач интеграции устоялись, например, в том же JavaScript - какими бы проблемами он не обладал, но "склеивать" на нём можно быстро и легко. Моё мнение - что стоит попробовать это сложившееся из скриптовых языков понимание отобразить в библиотеки на Обероне, и, возможно, необходимость для решения этих проблем в отдельном языке вообще отпадёт.
Однако, если говорить об отдельном языке, то я бы посмотрел в качестве одного из примеров марковские языки, например, тот же Рефал. И тут мы подходим, как раз глядя на Рефал, к ещё одному моменту, который Вы тоже затронули, говоря о необходимости "удобно обрабатывать графические схемы как данные". Язык должен быть, оказывается, не на плоские строки ориентирован, а на обработку иерархических данных. Они характерны для некоторых прикладных задач, бизнес-задач. На мой взгляд, набор базовых средств обработки таких данных сегодня есть в XPath/XQuery, по крайней мере, таков мой опыт их использования.
И в-третьих, возможно, языком вот этого верхнего уровня (склеивающим, интегрирующим) мог бы стать Дракон с древовидными структрами данных, соответствующими XML-языкам, правда, упрощённым до уровня непрофессиональных программистов. Но с сохранением преобразований в XML, который реально сегодня стал форматом для интеграции программных систем.
Такие вот соображения.
|
Dva_Pernatyh.pdf [1.3 МБ]
