Ну, Влад, основная цель Оберон-клуба — это помочь заинтересованным в Оберон-технологиях людям найти друг друга, вместе поспособствовать их распространению и развитию. Что конечно гораздо шире, чем проект ZXDev и мои посты выше. Опыт показывает, что средние программисты не в состоянии осознать преимуществ, предоставляемых Оберон-технологиями. Человек, которого могут заинтересовать Обероны — как минимум неординарная личность. И я часто наблюдаю подтверждение этому тезису. Средний программист — обычно потребитель средств разработки, они для него не самоцель, а средство, как правило, заработать себе на жизнь. И он терпит их недостатки, привыкая к ним, но обожает носиться со списком их достоинств (часто мифических).
Неординарная личность — её интересует в первую очередь качество средств разработки, доступность и возможность доработать-развить самостоятельно в нужном направлении (C#/.NET, Java при всём декларировании их прогрессивности и проч. и проч. наглухо запечатаны; я не имею ввиду открытые исходники, а внутрифирменную стратегию развития, зависимость от сомнительных коммерческих целей и развитие не обязательно в нужном русле), потенциал, а также кто и с какой целью их продвигает.
Много лет занимаясь программированием и получая новый опыт, осваивая новые средства, постепенно ко мне пришло понимание, что мир IT-разработки развивается слегка не в ту сторону. Чего-то не хватает. Мы, программисты, безнадежно застряли в текстовом представлении программ, в императиве, в избыточной сложности. Постоянно вынуждены реализовывать на разных платформах/технологиях схожие вещи, но разными способами. Сделанным наработкам не хватает тотальности, они больше похожи на какие-то временные заплатки. Наблюдается сильная привязка процесса разработки к определённым средствам и к конкретным языковым особенностям (часто мешающим перенести программы, например, даже с одной реализации Си на другую, даже в пределах одной платформы) или конкретно устаревшему или откровенно неудачному API, от которой порою трудно избавиться. Очень низкая производительность труда программиста. Высокая концентрация ошибок в продуктах. Постепенно эти проблемы осознаются и мэйнстримом, но осталось много “старой закалки” программистов, которые изо всех сил цепляются за обжитые ими программные средства, не очень чётко понимая их недостатки. Будь то Си-подобный синтаксис (C++, C#, Java, PHP), или реальная необходимость использования беззнаковых типов и препроцессора, или целесообразность подмены простого и логичного понятия модульности с чётко выписанным полным/ограниченным экспортом/импортом сущностей и автоматическим конструированием интерфейсов модулей планомерным внедрением очень изощрённых средств для эмуляции модульности, таких как сборки, классы и пространства имён. Я бы назвал это концептуальной перегруженностью. Или неудачной постановкой акцентов, допущенной при проектировании языковых средств.
В деятельности по разработке программного обеспечения нас интересует обычно не список конструкций программы, а структурированный набор проектных решений, который можно визуализировать различными способами. Если продолжить аналогию, то получить базу проектных решений из машинной программы теоретически можно, но автоматический анализ здесь практически безсилен. А массив ручной работы напротив — огромен. Ибо в машинной программе не присутствуют в явном виде метаданные (почему принято именно такое решение, почему то или иное было сделано именно данным способом, какие есть ещё варианты). В то же время машинную программу можно будет сгенерировать на основе такой базы автоматически, дополняя проектные пробелы и углубляя детализированное представление проекта методом диалога с пользователем или программистом.
В каком виде хранить и как структурировать базу проектных решений — вопрос непростой. Удовлетворительно он ещё не решён. Мне попадались интересные работы в этом направлении как визуализации кода, так и как некоторая надъязыковая надстройка, позволяющая оперировать понятиями более высокого уровня, чем текст программы. С большим интересом я познакомился с идеями, реализованными в языке Пролог, с компонетно-ориентированной парадигмой Клеменса Шиперского, частично реализованной в системе
BlackBox Component Builder, с идеями Андрея Петровича Ершова о Лексиконе программирования (см. статью
«Предварительные соображения о Лексиконе программирования»), с такими инструментами как
HiAsm (это не ассемблер; данный проект реализует идею графического представления программ в виде, похожем на печатные схемы — компоненты-радиодетали и набор связей-проводников между ними). Упомяну конечно и Дракон, но с ним я не очень знаком.
Пришло понимание: нужно делать визуальные конструкторы, в которых упор будет сделан на визуальное удобное представление проектных решений и манипуляции с ними. Нужна визуализация, позволяющая бросить взгляд на проект с разных сторон. Пусть уже остаётся текстовое представление, куда ж без него. Но не более чем в роли промежуточного звена. Пусть программисты оперируют не языковыми конструкциями, а набором идей и проектных решений, только тогда их производительность может вырасти в десятки раз, а результаты, ими полученные, будут более высокого качества. Все эти мечты в конце концов привели меня к Оберон-технологиям, как самому простому, но очень мощному средству, потенциал которого огромен. Вот то самое представление, текстовое конечно, но конструировать визуализаторы и списки проектных решений надо поверх какого-то базиса. Нужен язык, удовлетворяющий определённым требованиям. И Оберон в этом контексте имеет много преимуществ перед другими языками.
Этот язык не замер (хотя стандарт Оберона-1 зафиксирован около 25 лет назад), а продолжает развиваться. Для него разрабатывают компактные специализированные расширения (например,
OberonX — математическое расширение для Оберона, реализованное в ETH Oberon и Active Oberon). Но базой для всех Оберон-компиляторов остаётся набор средств Оберона-1. Такая совместимость позволяет надеяться на неизменную языковую платформу, на которую можно опереться ввиду того, что она будет реализована во всех более расширенных диалектах. Кстати, благодаря этому, как правило, переносить программы между различными диалектами Оберона гораздо проще, чем перенести с Borland C Builder на Microsoft Visual C.
Подчеркну — нужна возможность с самого начала делать одинаковые вещи одинаковым способом (Кнопка это кнопка. А в окне браузера она, в окошке EXE-программы для Win32 или на рабочем столе Gnome/Ubuntu — это уже дело десятое). И второе — иметь возможность развернуть результаты сделанного на различные программные и аппаратные системы, платформы, даже с ретро включительно. Чтобы, однажды разработав, везде иметь универсальную кнопку, подстраивая к задаче только её свойства, и не терять при переходе с системы на систему, с платформы на платформу.
Да, хорошо бы поставить во главу угла идеи и требования пользователя, а не
железяку -> аппаратную конфигурацию -> процессор -> ОС -> Среда разработки -> Язык программирования -> Визуальные конструкторы GUI, запросов к БД и т.п. -> API и библиотеки -> ...Время показало, что первым делом пользователя интересуют его задачи, а эта цепочка из высоких технологий весьма шатка, неустойчива и подвергается изменениям буквально на каждом шагу. Обероны здесь отнюдь не панацея, а компромисс, языковая программная платформа, снимающая некоторую часть проблем, впрочем, это ещё предстоит проверить в различных областях деятельности IT-инженеров.
Вход
FAQ
Поиск
