На базарной площади довольно часто можно слышать высказывания об
Обероне. Мне кажется, что на базарной площади пора появиться ветке об
этой системе и языке, что-то вроде "Мысли об Обероне". Что это такое, перспективы
этой системы, что
полезного можно извлечь из него для программирования на Дельфи
(например) и др.
Заранее извините за много букв и излишне лирическое отступление. Возможно, оно кому-нибудь и сгодится.
Несколько слов о том, что является изюминкой Оберона (на мой взгляд).
Если брать сам язык -- то он прост, как самокат. Можно разобрать, собрать, понять, что и почему именно так сделано, что к чему крепится. Компонентный Паскаль -- это уже мопед. Ездить можно быстрее, с ветерком, но устройство будет посложнее. Горючее требуется и тех.обслуживание. Да и до мотоциклов пока не дотягивает. До Ямахи -- точно, ну а до Harley-Davidson, тем более.
Вопрос: а всем ли нужна Ямаха? Наверное, нет. Мне, например, вполне сойдет и самокат. Я могу его обустроить так, как я хочу. А главное, он помогает мне решить задачу -- перемещаться в пространстве быстрее, чем на своих двоих. Большие расстояния я могу преодолевать с помощью других транспортных средств. А для коротких дистанций, да еще в условиях "городских пробок", -- самое оно. Могу даже приделать моторчик, если очень уж хочется, чтобы было "как у людей". Но не буду. Ценность самоката как раз в том, что он самокат.
Оберон создавался как язык реализации конкретной системы, воплощавшей идеи расширяющего программирования. Он был вспомогательным средством. Систему делали сначала на Modula-2, затем от языка реализации стали отрезать ненужные вещи (преимущественно системного плана), благо перед Виртом не было цели создать новый уникальный язык, который взаимодействовал бы с другими языками. Сначала Оберон имел, как и Modula-2, DEFINITION и IMPLEMENTATION. Потом Вирт решил их слить. Вирт вообще практически всю свою жизнь работал в замкнутом, самодостаточном мире и создавал эту "самость" такого мира. Его системы носили характеры моноязыковых систем, т.е. они не терпели других (точнее, не заботились об их существовании).
Такое абстрагирование от реальности позволило добиться очень интересных результатов.
Была ли до Оберона идея расширения типа? Конечно, была. Но ее воплощение было куда более размыто, да и не несло оно ту нагрузку, которую придал ей Оберон.
Является ли Оберон языком ООП? На мой взгляд, нет. Вот Компонентный Паскаль я могу назвать языком ООП, с поправкой на то, что он, прежде всего, язык модульного программирования и модули там первичны, а классы вторичны. А что же Оберон? Он конструктор ООП. Ассемблер ООП, но не язык ООП. И глупо от него требовать больше, чем он может дать. Лучше это осознавать. В этом его слабость, но в этом его и огромная сила. Он не является заложником ООП-модели. Он может ее воплощать, пусть с определенными допущениями проблемами, но может.
Гораздо важнее в Обероне то, что расширение типа вкупе с процедурными переменными и модулями, а также со встроенными в язык средствами контроля динамического типа (пресловутый охранник-привратник типа) позволяют получать крайне интересные вещи. Не без побочных эффектов, но вещи интересные.
Чем замечательна система Oberon, которую проектировал и делал Гуткнехт (в основном)? Тем, что в системе документ поставлен во главу угла? Это здорово, но, на мой взгляд, не самое ценное.
Самое ценное в том, что компилируемый язык со строгим контролем типов обрел в одном лице систему программирования (IDE), исполняющую систему (run-time) и операционную систему, которая "плавает" поверх стандартных ОС – самодостаточную систему макетирования ПО. Постойте, скажете вы, а Smalltalk, а Cedar System из Xerox PARC? Да, они были ДО системы Oberon, Вирт и Гуткнехт их смотрели, с ними работали, брали самое для себя полезное. Но система Oberon -- это не Smalltalk и не Cedar. Модули сыграли огромную роль в том, чем стала эта система. Да, такая простая и элементарная, казалось бы, вещь, которую мы все никак не можем определить.
В чем была заслуга Пфистера и Шиперски? Они изобрели что-то принципиально новое? Да ничего подобного. Они взяли наработки системы Oberon и стали думать, как это можно приспособить к агрессивному внешнему миру, с которым неизбежно приходится сталкиваться в разработке промышленных систем.
Шел 1993-1994 гг. В то время и закладывались основы реинкарнации системы Oberon под именем Oberon/F. Некоторые следы этого вы можете найти в статье моего коллеги -- Сергея Орлова, с которым вместе работали в ComputerWeek-Moscow, а теперь -- в изд-ве "Открытые системы" --
http://www.oberon2005.ru/paper/obe_95.pdf . (Правда, когда он ее писал, мы еще не были знакомы.)
Что сделали молодые, энергичные воспитанники школы Вирта в своей компании Oberon microsystems? (О ее истории и истоках кое-что я неделю назад в этом форуме опубликовал.)
К тому моменту в ETH уже вовсю преподавали ООП. Специально для этой цели (преподавания ООП) Ханспетер Мессенбек и его коллеги создали новый язык Object Oberon, где CLASS был закреплен в диалекте Оберона синтаксически. Был сделан компилятор, который, кстати, несильно усложнил эталонный компилятор Оберона. Но модули в Обероне доминировали, классу придавать "самость" не решились, и вот уже появился на свет компромисс -- Оберон-2. Язык, под которым Вирт согласился поставить свою подпись, хотя к его созданию отношения по сути не имел. И при случае всегда подчеркивает -- что это язык Мессенбека. Кстати, в 1993 г. вышла книга Мессенбека "Object-Oriented Programming in Oberon-2", которую я держу сейчас в руках. Убежден, что Пфистер и Шиперски очень немало почерпнули из нее.
В самый разгар работ над Oberon/F -- прообразом BlackBox -- появляется Java. Наше вам здрасьте… Тут, понимаешь, строили-строили, а эти раз-два и в дамках. Куда скромным швейцарцам супротив великой Sun, да еще стремившейся с помощью этой Java утереть нос всем своим конкурентам (а конкурентов было не счесть -- почти все вокруг).
Пришлось слегка подправить Оберон-2, выровнять базовые типы с прицелом на Java, а также взять у наглого самозванца кое-что для ООП. Так получился в 1997 г. Компонентный Паскаль (Component Pascal). Вспоминаю, что в середине 1997 г. дал соответствующую новость в "Мире ПК" (я тогда там не работал), опираясь на только что вышедший Language Report.
Среда BlackBox потому и интересна, что сохранила от системы Oberon важную суть -- это одновременно среда программирования и исполняющая система, которую можно динамически расширять.
В рамках технологического цикла разработки сложных систем очень редко выделяют фазу макетирования (прототипирования). Зададимся вопросом: что есть действующий макет системы и чем он отличается от реальной системы? Макет должен создаваться быстрее, на нем желательно пробовать и проверять проектные решения. В идеале разница между ним и реальной системой должна быть незримой (извне). То, где кончается макет и начинается система, можно определить только по соответствию зафиксированным техническим требованиям (знаменитое -- "не ошибка, а фича"). Программиста-хозяин такими требования практически никогда не связан, в отличие от программиста-слуги. И для него очень важно, чтобы перетекание из макета в систему происходило просто и органично (наращиванием, расширением, уточнением, конкретизацией).
Что мне нравится в BlackBox? Это среда
быстрого макетирования. Причем макетирования с прицелом на промышленное применение. Макет можно не выбрасывать, а доделывать! В этом отношении система Oberon ей уступает. Да, BlackBox, положа руку на сердце, не блещет тщательной проработкой и на фоне системы Oberon не является революционным новшеством. Но вполне практичный инструмент для решения достаточно широкого спектра задач.
Теперь о языках.
Глупо спорить, что лучше: Оберон или Компонентный Паскаль. Это РАЗНЫЕ языки. Один старается не привязываться к ООП (даже терминологически). Другой ищет свое место в мире как обновленный Оберон с примесью классов а-ля Java.
Компонентный Паскаль. Да, это компромисс. Неплохой компромисс. По крайней мере, его объектная модель много проще Java, C++, Delphi, C#. Более того, для многих задач его можно применять и как язык проектирования (с допущениями, конечно). Он не перегружен техническими деталями, как другие ООП-языки, при этом позволяет воплощать практически все основные вещи.
Таким образом, забегая немного вперед, выскажу крамольную мысль (точнее, повторюсь). Оберон, на мой взгляд, не является языком ООП, а остается языком модульного программирования (с расширением типа). Компонентный Паскаль также является языком модульного программирования, при этом его вполне можно назвать ООП-языком. В этом большая разница между "близнецами-братьями".
Ну а в том, что за подводные камни есть в Обероне и КП, думаю, мы еще успеем не раз убедиться.
