В связи с обсуждениями роли и места Оберон-языков и развития сред их поддержки возникли некоторые мысли. И вопросы, конструктивные ответы на которые могли бы быть интересны. Они, как показалось, более всего затрагивает именно системное программирование - прежде всего самого ББ.
1. По содержанию процесса.
Тот же Фридланд выделяет три рода назначений - исследовательское, учебное, практическое. Как характерные черты первых двух здесь указывались (Kemet) - непрерывность процесса, неизменность платформы и динамичность надстройки. А вроде как практическое решение проблемы должно допускать смену базиса, где все проблемные места известны и рассмотрены под микроскопом и решены теоретически. В то же время следовало бы уточнить:
А что, непрерывность в практических проектах - это плохо? Или хорошо, но недостижимо? Или достижимо, но при определённых условиях? И почему коммерческая разработка ПО имеет мало общего с чертами, которые Вы указали? М.б. не всякая коммерческая - а с недостаточной ответственностью разработчика ("гарантоспособностью") - грубо говоря,
"гоблинская"?.. И каковы критерии отделения промышленной? М.б. "короткие/длинные деньги" (расчётный срок окупаемости)? или ещё что-то?..
2. По свойствам среды.
Иногда поднимается вопрос, что текст как интерфейс имеет границы применения, причём для эффективного использования его возможностей нужна удобная среда разработки.
Если в общем о пользовании средой - сказанное надо понимать как согласие с выводом отсюда (курсив мой):
Ильченко Эдуард писал(а):
Как будто кто-то пытается скрыть целостную картину, разбиванием её на мелкие, слабо связанные друг с другом, части.
Да, такой эффект тоже есть.
Эти эффекты взаимно противоположны. А золотая середина между ними представляет собой унылый компромисс выбора из двух зол.
Всё почему? Имхо, потому что очень мало кто занимается проектированием. Не системы, языка или IDE, а именно
эргономически обоснованного процесса моделирования (куда включается не только представления данных и алгоритмика, но сам процесс разработки программы, оптимизация изучения предметной области, оптимизация принятия решений). И даже хотя бы первым этапом, который обозначен Паронджановым как когнитивная эргономика.
...
А если конкретнее - возникают вопросы по существу:
Нужен ли иной тип представления проекта в среде? какой? Он должен работать "в связке" с ТКИ (скажем, через переключение видов)? Или может заменить ТКИ? за счёт каких преимуществ? и каковы его основные свойства?
Также порой ББ критикуется за то, что в нём нет средств для эффективной разработки приложений, а специфичность ТКИ-подхода к интерфейсу и бинарный формат файлов исходного кода и недостаточность редактора среды не дают возможности эффективно использовать сторонние средства.
А конкретно нужно определиться - какие эффективные средства нужны, каких нет в ББ? и в целом как участники видят систему таких средств?
3. По формату - при обсуждении некоторых сред графической/"вижуальной" разработки было сказано следующее:
Другое дело, что LAbView берёт другим - она во многом заточена на обработку сигналов, а там "графическое" представление довольно-таки естественно. Но вот адекватного перевода в текст (желательно человекочитаемый) явно не хватает и там.
И тут вопрос - удобство представления может достигаться новым форматом? Или существующий бинарник в среде надо как-то человекочитаемо представлять (возможно, схематически)?
4. Возникают и споры относительно организации программ в COM-стандарте и возможностей КП.
Тут первый вопрос - снижает ли это гарантоспособность того, что разрабатывается в ББ? А если да - то что делать - заново писать среду? или дорабатывать существующую? Какую технологию она должна поддерживать, если не COM? И можно ли писать новую в ББ?