Проект Оберон / Oberon Language and System, 1986-1990
Язык программирования и ОС Оберон.
Проект Оберон (Project Oberon) преследовал цель создания однопользовательской ОС для рабочей станции. Первоначально планировалось при создании ОС использовать язык программирования Модула-2, однако с целью повышения расширяемости и гибкости будущей ОС было принято решение добавить в язык возможность расширения типов. Так появился язык программирования Оберон.
Результатом проекта была ОС Oberon, реализованная полностью на языке Oberon и являющаяся средой выполнения (runtime) для языка Oberon. Замкнутая моноязыковая модульная среда с графическим интерфейсом, концепцией активных документов, динамической загрузкой / выгрузкой драйверов устройств и подсистемой сборки мусора.
Подробнее
Summary of projects by N. Wirth, 1962 - 1999:
« A sabbatical year at the Xerox Palo Alto Research Center (1984-85) brought Wirth into closer touch with the Cedar Operating System, developed in the preceding years at PARC. This was perhaps the first system truly tuned to the needs of personal workstations, and freed from the framework inherited from central computers with a batch processing mode. In daily use, however, Cedar showed all too clearly the symptoms of large software developed by large groups of people: it was bulky and unreliable. It had already become so complex, and its structure had become so intertwined that it was most difficult, if not impossible, to understand it. Wirth decided to undertake the development of a new system, based on concepts suggested by Cedar, but with the firm goal to keep its size such that it could be well understood as a whole, and could be explained in detail in the literature and in courses. Together with J. Gutknecht he worked on the conception and the detailed programming for the following 3-4 years, after which the basic, but easily extensible system was operational.
Although it was planned to use Modula-2 to implement the Oberon System, it soon became evident that a fundamental facility needed for extensibility was lacking: type extension. It was decided to also discard various facilities of lesser importance of Modula-2, and to construct a new, derived language and its compiler. Being an integral part of the project, the language also obtained the name Oberon.
Language and System soon became the standard tools in the Institute for software development, and in particular the development of system extensions. Wirth himself developed and programmed a graphics editor and software for the network connecting the Ceres workstations. A particular challenge was the design of a server station for printing, file distribution, and electronic mail, all together under the constraint of Oberon's single process property. Using a simple, clear concept proved to be a large benefit; the server operates without failure continuously for years. »
Из документации Инструментальный комплекс «BlackBox» (перевод Ткачёв Ф.В.):
« Модула-2
…
Simula, Smalltalk и Cedar
Однако Вирт продолжал интересоваться прежде всего настольными компьютерами, и опять важный импульс пришел из центра PARC компании Xerox. В этом центре были изобретены рабочая станция, лазерный принтер, локальная сеть, графический дисплей и многие другие технологии, расширяющие возможности использования компьютеров человеком. Кроме того, в центре PARC были популяризированы некоторые более старые и малоизвестные технологии, такие как мышь, интерактивная графика и, наконец, объектно ориентированное программирование. Эта последняя концепция (хотя и не сам термин) была впервые использована в языке высокого уровня Симула (1966) — еще одном из семейства алголоподобных языков. Как и предполагает имя, язык Simula использовал объектные технологии прежде всего для целей моделирования [simulation]. Однако язык Smalltalk (1983), разработанный в центре PARC компании Xerox, использовал их практически для всего, что угодно. Проект Smalltalk был также пионерским в плане дизайна пользовательского интерфейса: графический интерфейс пользователя (GUI), каким мы его теперь знаем, был разработан для системы Smalltalk.
В центре PARC эти идеи повлияли на другие проекты, например, паскалеподобный язык Cedar. Как и Smalltalk и позднее Оберон, Cedar представлял собой не только язык программирования, но и операционную систему. Операционная система Cedar была весьма впечатляющей и мощной, однако сложной и нестабильной.
Оберон [Oberon]
Проект Оберон был начат в 1985 в ETH Виртом и его коллегой Юргом Гуткнехтом [Jürg Gutknecht]. Это была попытка выделить все существенное из системы Cedar в виде универсальной, но все же обозримой операционной системы для рабочих станций. Получившаяся система оказалась очень маленькой и эффективной, прекрасно работала в оперативной памяти размером всего 2 MB и требовала при этом лишь 10 MB памяти на диске. Важной причиной малого размера системы Оберон был ее компонентный дизайн: вместо интеграции всех желаемых средств в один монолитный программный колосс, менее часто используемые программные компоненты (модули) могли быть реализованы как расширение ядра системы. Такие компоненты загружались, только когда они были действительно нужны, и они могли совместно использоваться всеми приложениями.
Вирт понял, что компонентно-ориентированное программирование требовало некоторых средств объектно-ориентированного программирования, таких как упрятывание информации [information hiding], позднее связывание [late binding] и полиморфизм.
Упрятывание информации было сильной чертой Модулы-2. Позднее связывание поддерживалось в Модуле-2 посредством процедурных переменных. Однако там не было полиморфизма. Поэтому Вирт добавил расширенное переопределение типов [type extension]: записевый тип мог быть объявлен как расширение <потомок> другого записевого типа <предка>. Тип-потомок можно было использовать всюду вместо одного из его предков.
Но компонентно-ориентированное программирование выходит за рамки объектно-ориентированного. В системе, построенной из компонентов, компонент может разделять свои структуры данных с произвольным числом других компонентов, о которых она ничего не знает. Эти компоненты обычно также не знают о существовании друг друга. Такое взаимное незнание делает управление динамическими структурами данных, и в частности правильное освобождение уже ненужной памяти, принципиально более трудной проблемой, чем в закрытых программных системах. Следовательно, необходимо оставить на долю реализации языка всю работу по определению момента, когда какая-то область памяти более не нужна, чтобы повторно использовать ее без ущерба для безопасности системы. Системный сервис, выполняющий такую автоматическую утилизацию памяти, называется сборщик мусора [garbage collector]. Сбор мусора предотвращает две из числа наиболее труднонаходимых и попросту опасных ошибок в программах: утечки памяти [memory leaks] (когда более не используемая память не освобождается) и висячие ссылки [dangling pointers] (преждевременное освобождение памяти). Висячие ссылки позволяют одному компоненту разрушить структуры данных, принадлежащие другим. Такое нарушение защиты типов [type safety] должно быть предотвращено, т.к. компонентные системы могут содержать многие независимо написанные компоненты неизвестного качества (например, полученные из Интернета).
Хотя алголоподобные языки всегда имели высокую репутацию в плане безопасности, введение полной защиты типов (и, следовательно, сбора мусора) явилось качественным скачком. Именно по этой причине полная совместимость с Модулой-2 оказалась невозможной. Получившаяся модификация Модулы-2 была названа как и вся система — Оберон.
Система модулей в Обероне, как и в Модуле-2, обеспечивала упрятывание информации для целых семейств типов, а не только для отдельных объектов. Это позволило определять и гарантировать инварианты для нескольких взаимодействующих объектов. Другими словами, разработчики получили возможность разрабатывать механизмы защиты более высокого уровня, отталкиваясь от базовых средств защиты на уровне модулей и защиты типов, обеспечиваемых хорошей реализацией Оберона.
Ортодоксальные объектно-ориентированные языка типа Smalltalk пренебрегали как типизацией переменных (вообще не поддерживая типы), так и упрятыванием информации (ограничивая ее объектами и классами), что явилось большим шагом назад в технологии разработки программного обеспечения. Оберон примирил миры объектно-ориентированного и модульного программирования.
Последнее требование компонентно-ориентированного программирования — возможность динамически загружать новые компоненты. В Обероне единица загрузки та же, что и единица компиляции — модуль. »