0.
Предисловие
Много раз меня спрашивали о том, как "изобретают"
языки программирования. Трудно сказать конкретно, но совершенно точно,
что это - дело опыта и тщательных раздумий над предметом. Иногда я
отвечал: "Также, как создать самолёт. Нужно выяснить количество
необходимых деталей и материалов, затем правильно собрать их в единое
целое." Этот ответ может не быть до конца удовлетворительным, но в обоих
случаях результатом может быть и взлёт и падение.
Языки программирования были одной из первых тем,
определивших компьютерную науку, как дисциплину "с собственным лицом".
Они не принадлежали к математике, также как и к электронной инженерии.
Началом был Алгол 60, своим определением синтаксиса диктовавший
жёсткость и точность. То и дело в академии вспыхивали очаги активности,
изучались свойства языка, выискивались сбои и противоречия, изобретались
мощные алгоритмы синтаксического анализа, преодолевались сложности
"общения" с компиляторами. Позже появилось ощущение, что Алгол "узковат"
для решения насущных задач. Требовался новый, лучший язык, возможно
потомок Алгола. Были созданы специальные комиссии, и разгорелись жаркие
споры, кое-кто бредил Грандиозными Формальными Системами, другие думали
о вещах, более приближённых к практической среде. К среде, на которой и
"взрос" Паскаль.
1. Структурированное программирование и Паскаль
Паскаль родился в 1969 г. как знак "освобождения" [0]. Более того.
Обязанный обучать людей программированию, я столкнулся со скудными
возможностями Фортрана и Алгола. Первый не отвечал моему "вкусу"
исследователя, второй был противен мне как инженеру. Я вырвал себя из
этой тюрьмы, создав Паскаль, показавший, что элегантный стиль и
эффективное "нутро" не есть два взаимоисключающих понятия. Я был, да и
сейчас остаюсь уверенным в том, что язык, используемый в обучении,
должен диктовать некий стиль, элегантность, непротиворечивость и в то же
время отражать нужды (но не плохие привычки) практики. Я хотел создать
язык, который подходил бы и моим ученикам для обучения и мне, для
практической работы.
Вторым из упомянутых "освобождений" было исключение
ограничений навязанных работой комиссии. В 1966, Алгол W [1] являлся
компромисом, "гнувшимся" под давлением многочисленных мнений и пожеланий
обеих сторон: комиссии по Алголу (Algol committee) и сообщества
программистов на Алголе (Algol community). Конечно, многие из них были
значимыми и полезными, но другие были изрядной помехой, либо могли
нанести вред основной концепции в силу своей несовместимости с общими
принципами. Некоторые члены были заинтересованы в создании языка с
новаторскими функциями, следствие которых могло бы стать объектом
последующих исследований, тогда как мне в роли инженера было очень
нелегко с предложениями, вопрос реализации которых так и оставался
предметом многочисленных обсуждений. Мне хотелось иметь как минимум
конкретную идею, как это должно быть представлено на существующих
компьютерах и, к тому же, будет нормально реализовывать качества,
отсутствующие в Фортране.
Основой, доминировавшей при создании Паскаля, была идея
"заставить" язык мыслить методично, использовать общепринятые методы
представления математических выражений, удовлетворять нужды
практического программирования и содействовать структурированному
подходу. Фундаментальные правила языка должны быть простыми,
воспринимаемыми интуитивно и полностью комбинируемыми. Например, если
x+y является выражением, оно может использоваться как часть выражения
при присвоениях, как параметр процедуры или как индекс. Скажем, если
общераспространённое соглашение приводит x-y-z к (x-y)-z, мы не должны
получить x-(y-z). Или, если столетиями x=y обозначает равенство x и y,
нам необходимо воздержаться от самонадеянной замены этого представления
на x==y. Фактически, Паскаль был построен на фундаменте систем
математического обозначения и Алгола. Паскаль и его вариации были
названы "Алголоподобными" (Algol-like).
Сегодня трудно представить себе все обстоятельства,
превалировавшие в 1960-х. Мы должны вспомнить, что "компьютерствующее"
сообщество было жёстко поделено на два профессиональных лагеря. Учёные и
инженеры использовали Фортран для программирования своих расширяемых,
"словоориентированных" (word-oriented) двоичных компьютеров. Системные
программисты, трудившиеся в недрах компьютерных компаний, использовали
"родные" машинные коды. Были попытки объединить два эти мира, такие как
новейший компьютер Burroughs B-5000 или язык программирования PL/I от
IBM. Они пожирали солидные бюджеты и были заведомо обречены. Паскаль был
другой попыткой такого рода, менее претенциозной и без бюджета или
поддержки индустриального масштаба. Он обращался к идее рекурсивно
задаваемых структур, не только исполняемых операторов, но также и типов
данных. В качестве элементов были взяты массивы (вектора, матрицы) из
Фортрана и Алгола, также как записи (records) и файлы из Кобола.
Концепция позволяла свободно комбинировать их между собой.
Другое труднопредставимое ныне - крайняя ограниченность
компьютерных ресурсов. Компьютеры с более чем восемью тысячами слов
памяти (16 кб), исполнявшие одну инструкцию менее чем за 10мс,
назывались "супер-компьютерами". Ничего удивительного в том, что даже
просто генерация хотя бы настолько же компактного и эффективного кода,
как у Фортрана, для компилятора нового языка была сложной задачей.
Каждая инструкция считалась и, для примера, генерация изощрённых вызовов
процедур, беря во внимание активное использование рекурсии, означала
длительную прогулку в ожидании окончания. Проверка индексов на этапе
работы программы считалась чрезмерной роскошью.
Ну, компьютерная мощь растёт с каждым годом, а с ней и
возможности программ и программистов. Повторяющиеся неудачи и грубые
ошибки в промышленных продуктах выявили сложности, присущие
интеллектуальному созданию при повышающейся сложности новых задач.
Единственное решение находится в структурировании программ, в
предоставлении программисту возможности отсечь мелкие частности при
сборке чего-то большего. Эта школа мышления была названа
"Структурированным программированием" [2] и Паскаль был создан
исключительно в согласовании с условиями данной дисциплины. Его основы
идут намного глубже простого "программирования без выражений go to",
нежели думают некоторые. Это, скорее, окончательный метод решения
проблемы.
Кроме структурированных выражений, язык характеризует
концепция типов данных. Она говорит, что каждый объект имеет свой тип;
будь это константа, переменная, функция или параметр. Типизация данных
вводит избыточность, а она, в свою очередь, может быть использована для
обнаружения несоответствий, являющихся ошибками. Если тип всех объектов
может быть определен посредством простого чтения исходного текста (то
есть, без исполнения программы), тогда тип называется "статичным" и уже
компилятор может проверить его. Разумеется, ошибки, обнаруженные
компилятором, безобидны и малосопоставимы с теми, которые будут найдены
во время исполнения программы в "полевых" условиях, конечным
пользователем. Потому, статичная типизация явилась важным аспектом в
создании программ, появившимся в 1970-х с началом создания крупных
программных комплексов.
Особо удачной идеей была интеграция указателей в
статичную типизацию, предложенная Hoare [3] и использованная в Паскале.
Простое присвоение фиксированного типа не только каждому объекту данных,
но также и каждому указателю, как если переменная-указатель в любое
время может только указывать на объект того типа, к которому относится
(или никуда не указывать). Пресловутое программирование с указателями,
позже названное обработкой списков (list processing), нашумевшее своими
ловушками, теперь вызывало опасений не больше, чем программирование без
указателей.
Но Паскаль всё еще страдал некоторыми огрехами, более
или менее значимыми, в зависимости от частного восприятия или
применения. Одна из проблем заключалась в том, что язык весьма
категорично истолковывал статичную типизацию, требовавшую наличия
информации о каждом параметре процедуры во время компиляции. Пока
декларация массива имела жёсткие рамки начала и конца, весьма удобные
динамические массивы исключались напрочь. Глядя в прошлое, можно
увидеть, что это ограничение было глупым и удержало многих пользователей
Алгола от перехода на Паскаль. Обычно, массивы передавались указателем,
а для динамических массивов необходимо было всего лишь добавить
информацию о границах. Небольшое усложнение компилятора с лихвой
окупилось бы повышенной гибкостью языка.
Существовали и некоторые другие недостатки, пришедшие
из Алгола, из за недостатка мужества у автора отбросить некоторые
правила и боязни противодействия "зубров" старой школы. Первым в списке
стоял оператор "go to", оставленный в концепции несмотря на то, что его
можно было полностью заменить связками "if", "while" или "repeat".
Другая допущенная ошибка заключалась в отсутствии полного
специфицирования параметров формальных процедур, что, в принципе, было
"подкопом" под всю систему типизации. Это проиллюстрировано сжатым
примером ниже. Между прочим, это также может послужить примером
программистских загадок, популярных некогда.
PROCEDURE P(b: BOOLEAN; q: PROCEDURE);
VAR i: INTEGER;
PROCEDURE Q; BEGIN i := i+1 END Q;
BEGIN i := 0;
IF b THEN P(FALSE, Q) ELSE q;
Print(i)
END P
Загадка: Какая последовательность номеров будет
выведена посредством вызова P(TRUE, P)? Возьмите во внимание тот факт,
что для q не нужно указывать тип параметра! Здесь мы столкнулись со
случаем, когда определенное комбинирование принципов ведет к трудностям
в интерпретации, несмотря на то, что каждый принцип в отдельности
безвреден и полностью определен. Здесь присутствует комбинация вложенных
процедур, локальных контекстов и рекурсии, вызывающая проблему. Одна из
труднорешимых задач языкового дизайна - исключить непредвиденные
нежелательные эффекты.
Последним, но важным обстоятельством является то, что
Паскаль перенял у Алгола несколько семантических неоднозначностей, что
весьма пагубно. Я имею ввиду недостаточно явный закрывающий символ для
вложенных конструкций. Первейший пример: условный оператор. Как
следствие, вложение в выражении:
IF b0 THEN IF b1 THEN S0 ELSE S1
либо как:
IF b0 THEN [IF b1 THEN S0] ELSE S1
Более подробное описание содержится в [4].
2. Модульное программирование и Модула-2
С
некоторыми полностью выявленными дефектами и появившимися требованиями к
программированию, наступило самое время для создания нового
языка-преемника. Двумя откровенно новаторскими фишками были
мультипрограммирование и "утаивание информации" (information hiding).
Лично у меня был еще один критерий: создать язык, годный для описания
систем полностью, от хранилища данных до редактора документов, от
менеджера процессов до компилятора и, от драйвера экрана до графического
редактора. Я понял, что множество проблем в разработке программ
происходит от смешения частей, созданных в разных языках. Это стало
очевидным, когда мы создавали рабочую станцию Lilith в 1978 г. [6].
Основой ей была рабочая станция Alto (Xerox PARC) [5]. Программное
обеспечение Alto в основном создавалось в Mesa; ПО для Lilith -
полностью в Модуле-2. Создание более чем одного языка для одной РС
являлось чрезмерно накладным. Несомненно то, что Модула родилась в силу
неизбежности.
Краеугольным камнем Модулы-2 была (как ни странно)
модульная конструкция. Если Паскаль служил для построения монолитных
программ, Модула-2 годилась для систем, состоящих из иерархии частей,
определяемых соответствующими интерфейсами. Каждая часть называлась
модулем, а в последствии, в Аде - упаковкой (package). Короче, модуль
был похож на программу на Паскале с добавлением явных интерфейсных
спецификаций для других модулей. Это делалось так: модули описывались
как два разных текстовых файла: один содержал определения, другой - их
реализацию, "начинку". В первом были описаны объекты модуля, видимые из
других модулей; обычно это типы и наименования процедур. Как говорится,
"экспортная" информация. Во втором - все локальные, скрытые объекты и
тела (т.е. реализации) процедур. Отсюда и термин - "сокрытие информации"
(information hiding). Заголовок содержит списки идентификаторов,
импортируемых из других модулей. Маленький пример:
DEFINITION MODULE Files;
TYPE File;
Rider = RECORD eof: BOOLEAN END ;
PROCEDURE Set(VAR r: Rider; f: File; pos: INTEGER);
PROCEDURE Read(VAR r: Rider; VAR ch: CHAR);
PROCEDURE Write(VAR r: Rider; ch: CHAR);
PROCEDURE Length(f: File): INTEGER;
END Files.
Эта ключевая особенность удовлетворяла важнейшие нужды
командного программирования. Теперь стало возможным модульное разбиение
задания и возможность общего согласования интерфейсов планируемой
системы, после этого члены команды могли независимо друг от друга
создавать части, закрепленные за каждым. Этот способ был назван
модульным программированием. Концепция "модуля" поднималась раньше при
создании Parnas и, в сочетании с мульти-программированием в работах
Hoare и Brinch Hansen, где модульная конструкция была названа
"монитором" (monitor) [8, 9]. Также модуль был представлен в конкретной
форме в Mesa, а в Модуле-2 упрощён и обобщён.
Модульная конструкция могла, наверное, иметь в основном
только академический интерес, если бы не техника раздельной компиляции,
с самого её начала связанная с модулем. Под термином "раздельной
компиляции" мы понимаем, что (1) полная проверка типов производится
компилятором не только внутри модуля, но и по его интерфейсам и (2)
проверка совместимости (и версий) между соединяемыми модулями
достигается посредством простого ключевого сравнения, когда модули
скомпонованы и загружены. Воздержимся от изложения технических деталей,
но подчеркнём то, что это - критическое требование в создании
комплексных систем, до сих пор довольно плохо поддерживаемое
большинством систем коммерческого происхождения.
Несмотря на замечательные качества модулей с раздельной
коспиляцией, язык также имел некоторые недостатки. Конечно,
происходившие от Паскаля огрехи были исправлены. Синтаксис теперь был
недвусмысленным, спецификации типов - завершёнными, набор базовых типов
данных - исчерпывающим. Но как результат, язык, а с ним и компилятор
становились весьма большими и грузными, несмотря на то, что оставались
меньшими, чем сопоставимые коммерческие изделия. Цель, превращение языка
в мощное средство описания целых систем, была достигнута посредством
добавления некоторых низкоуровневых возможностей, в основном для доступа
к отдельным машинным ресурсам (таким, как ввод/вывод устройств). Такие
построения, как приведение типов, существенно контрастировали с понятием
абстракций высокоуровневого языка и потому - избегались. Их называли
"лазейками" (loopholes), потому что они ломали правила, диктуемые
абстракцией. Но иногда эти правила оказывались слишком жёсткими и
использование лазеек нельзя было исключить. Дилемма была решена через
модульное структурирование, которое позволило свести использование таких
"грязных" трюков в специфичные низкоуровневые обслуживающие модули. Если
подумать, это - примитивный взгляд на сущность программистов. Урок: если
ты предлагаешь возможность, которую могут окритиковать - её обязательно
окритикуют скорее всего!
3. Объектно-ориентированное программирование и
Оберон
Пришествие персонального компьютера в 80-х изменило пути
и задачи, для решения которых использовались компьютеры. Прямое,
немедленное взаимодействие заменило удалённый доступ и отработку
пакетных заданий (batch processing). Пользовательские интерфейсы
становились важным фактором. Они получили оформление в виде
высокоразрешающего дисплея, заменившего экраны из 24 строк по 80
символов в каждой, многие действия стали выполняться с помощью мыши.
Появились такие понятия, как окна и многозадачность (впервые были
применены на Xerox Alto и частично в проекте Smalltalk [10]). Вместе с
этим пришёл объектно-ориентированный стиль программирования. Истоки
методики объектно-ориентированного дизайна происходят от
специализированного предмета симуляции событий (явлений) и языка Simula,
созданного для его поддержки. Авторы Simula, Dahl и Nygaard,
реализовавшие её, в своё время доказывали, что объектно-ориентированное
программирование - тема, полезная не только в симуляции событий.
Некоторые сторонники ООП даже предлагали обратить всё программирование к
новому "видению мира".
Мы чувствовали, что революция - не время для излечения
застарелых болезней "софтварной" профессии и решили, что
эволюционировать будет мудрым шагом. Соблазнённые создать версию
Модулы-2, "очищенной" от ненужных тонкостей, мы также хотели выявить все
детали, необходимые для описания "объектной ориентированности". Наши
поиски показали, что необходимо было добавить только одну "фишку", а все
остальные ингредиенты уже были в Модуле. Единственная добавленная
возможность позволяла конструировать иерархии типов данных и в проекте
Smalltalk называлась "субклассированием". Наши собственным термином было
"расширение типа": новый тип задавал дополнительные аттрибуты к
имеющимся в старом. Расширение типа имело отличный обратный эффект в
деле борьбы с "лазейками", описанными выше.
Отсутствие "лазеек" - жестокий тест качества языка.
После всего, язык предоставляет "абстракцию", формальную систему,
определенную набором непротиворечивых правил и аксиом. "Лазейки" служат
для обхода этих правил и могут быть достижимы только в элементах другой,
лежащей ниже, системы, в части реализации. Принципиальное назначение
языка - в некотором роде защитить программиста от деталей реализации и
дать ему возможность мыслить исключительно в рамках абстракции высшего
уровня. Следовательно, язык должен быть полностью описан без каких-либо
зависимостей от конкретной модели компьютера или реализации
компилятора/интерпретатора.
Оберон явился попыткой упростить язык до самой его
сути. Результатом стал язык, более мощный и элегантный, нежели его
предшественники. Спецификация программирования в Паскале занимала 30
страниц, для Модулы - 45 страниц, для Оберона - всего 16 [12]. Что,
впрочем, неудивительно как результат более чем 25 лет активной работы
над созданием языков программирования.
Одним из упрощений было соединение задающей и
реализующей частей модулей. Один модуль Оберона описывается одним
файлом. Его заголовок содержит один список используемых модулей (или
импортируемых объектов). Определения объектов, доступных из других
модулей, помечаются специальным образом. Немаркированные, локальные
объекты остаются невидимыми. С дидактической точки зрения, это
объединение могло вызвать сожаления, потому что в идеальном виде
определяющие части могут создаваться совместно всеми членами команды, а
реализующие - каждым отдельным членом, вне зависимости от других до тех
пор, пока определения в заголовках остаются неизменными. Как бы то ни
было, рост количества файлов в связи со старой схемой отдельных
заголовков с необходимостью поддержки соответствующих частей в порядке
был признан недостатком. Более того, объединение исключило необходимость
проверки согласованности между определяющей и реализующей частями
модуля. Также, определяющая часть могла быть легко вычленена из текста
модуля посредством простой программы.
4. Выводы и будущее
В статье про Оберон M.
Franz написал [13]: "Мир запомнит Никласа Вирта в первую очередь, как
'парня, создавшего этот язык' и его имя будет связано с Паскалем." Его
наблюдение весьма точно; также приглашение на эту конференцию намекает
на то, что мне необходимо сконцентрироваться на Паскале. Моё
беспардонное отступление от темы проистекает из уверенности в том, что
потомки Паскаля, Модула и Оберон - намного более зрелые языки. Всё это -
семья, где каждый новый язык взял силу и опыт предыдущих. В конце
концов, временной промежуток - 25 лет.
Почему тогда Паскаль получил столько внимания, а Модула
и Оберон - лишь малую часть? Снова я цитирую Франца: "Это было, от
части, личной виной Вирта". Он продолжает: "Он удерживался от ...
названий, таких как Паскаль-2, Паскаль+, Паскаль 2000, но в противовес,
тяготел к таким как Модула и Оберон". Снова Франц прав. В своё
оправдание могу сказать, что Паскаль-2 и Паскаль+ были заняты другими
для своих собственных модификаций Паскаля, а я чувствовал, что такого
рода названия будут вводить в заблуждение относительно своего предмета,
хотя синтаксически похожи на "родителя" и происходят от него. Я
подчёркиваю тот факт, что для меня прогресс более важен, нежели
преемственность, несмотря на слабую маркетинговую политику.
Но, конечно, именование - это еще далеко не всё. В
одном мы не были достаточно активны (как сегодня говорят: "агрессивны"):
в широкой публикации наших разработок. Вместо того, чтобы говорить, что
было "не так" с Модулой и Обероном, лучше поговорить о том, что хорошо в
Паскале. По моим ощущениям, следующие факторы были определяющими:
- Паскаль, вобравший в себя концепции структурированного
программирования, был существенно другим и более прогрессивным чем,
скажем, Фортран. Особенно в Америке, где Алгол по сути был
неизвествен.
- В начале 70-х была создана организация пользователей (Pascal User
Group PUG), популяризовавшая язык и выпускавшая новостные сообщения.
- Паскаль вовремя был портирован для первых микрокомпьютеров (UCSD)
[14], и потому получил наибольшее количество новых пользователей,
которым больше не мешали прочно укоренившиеся навыки и наработки в
других языках.
- Паскаль был "подобран" начинающими компаниями. Реализация языка
фирмы Borland была первым продуктом, доступным по цене менее 50
долларов, что превратило его в "домашний" язык.
- UCSD также, как и Borland, качественно превратило компилятор в
завершённое средство разработчика, включавшее редактор программ,
файловый менеджер и средства отладки. Это сделало Паскаль крайне
привлекательным для учебных заведений и для начинающих программистов.
Это изменило способ написания программ. Быстрый цикл
"написал-скомпилировал-проверил-работает" и интерактивность также
явились привлекающими факторами.
- Почти сразу после начального "выброса" языка "в массы" начался
стабильный рост количества книг по программированию на Паскале. Это
было настолько значимо, насколько была велика популярность языка в
школах и университетах. Бумажные книги и программы заключили
"симбиотическую" дружбу.
Возможно, ценным наблюдением является то, что эта
"цепная реакция" началась около 1977 г., через семь лет после того, как
Паскаль был реализован на главном коспьютере CDC и были опубликованы его
спецификации. Тогда же, он был портирован на некоторое количество других
больших компьютеров, но оставался в основном в пределах университетов.
Эта работа по переложению языка в значительной степени базировалась на
нашем проекте P-компилятора, генерировавшего P-код и позже, его
преемника M-код (для Модулы) и Java byte-code.
В контрасте с Паскалем, Модула и Оберон появились не во
времена, когда компьютер завоёвывал новые сегменты общества. В тогдашней
педагогической практике концепцию модульного построения не посчитали
достаточно значительной, чтобы переходить на использование новых, хоть и
похожих языков. Учебники были выбраны, средства - вложены, время было
неподходящим для перемен. Промышленность также не пожелала заключить
Модулу в свои объятья, за некоторыми исключениями, в основном в Англии.
Более "вкусным" решением было расширение Паскаля с сохранением обратной
совместимости и старых ошибок. Здесь появилась конкуренция в виде C++ и
Ады, с мощной промышленной поддержкой.
Оберон "задвинули" намного глубже. Индустрия фактически
проигнорировала язык. Это просто поразительно: как в 1988 г. был
представлен не только элегантный и мощный язык, в 1990-м к нему
добавился компактный и быстрый компилятор, наряду с современной средой
разработки для рабочих станций, завершенной оконной системой, сетевыми
возможностями, редактором документов и графики; всё это было умещалось в
200 кб. памяти, сам компилятор занимал менее 50-ти. Вся система, включая
исходные тексты [15], была исчерпывающе описана в одной книге. Это
доказывало, что если применять соотвествующие методы и инструменты,
определенная система может быть построена затратами лишь с малой части
человеческих сил, выделяемых в обычной ситуации.
Понять это можно, только если взглянуть на ситуацию со
стороны последних глубоких изменений в компьютерной сфере. Ныне ресурсы
не являются "богатством", память исчисляется мегабайтами (а не
килобайтами, как 15 лет назад), инструкции - наносекундами вместо
микросекунд, а частоты - гигагерцами вместо мегагерц. Побуждения
экономии отринуты начисто. Единственный значимый ресурс -
профессиональный человеческий труд. Промышленность имеет трудности даже
с поиском хороших программистов C, а найти программиста на Обероне -
вообще, нереально. Теперь, попробуйте найти хоть один довод за
использование Оберона компаниями?
Здесь присутствует тупиковая ситуация: Освоение новых
средств и методов непрактично, пока использование старых не станет
откровенно убыточным. Так что же, получается, мы обречены на вечное
создание растущих гор усложняющегося программного обеспечения, которое
никто не понимает полностью, несмотря на то, что все стараются держаться
подальше от его "ошибок" и недочётов? В попытке изменить столь
неприглядное видение будущего, необходимо предпринять некоторые "чистые"
старты сейчас и далее. Требуется смелость для того, чтобы "отбрасывать"
и "отказываться", для выбора простоты и "прозрачности" в качестве целей
создания в противовес сложности и невразумительным изощрениям.
В деле программирования языков два таких начинания были
предприняты не так давно. Я имею ввиду Java и C#. Оба способствуют
ограничению избыточного количества возможностей, пытаясь предложить
определенную дисциплину программирования. Посему, движутся в правильном
направлении. Это воодушевляет. Но им предстоит еще проделать очень
долгий путь до Паскаля и еще больший - до Оберона.
Литература
- N. Wirth. The Programming Language Pascal. Acta Informatica, 1, 35
- 63 (1971)
- N. Wirth and C.A.R. Hoare. A Contribution to the development of
ALGOL. Comm. ACM 9, 6, 413 - 432 (June 1966)
- E. W. Dijkstra. Notes on Structured Programming. In Structured
Programming. O.-J. Dahl, E. W. Dijkstra and C.A.R. Hoare, Acad. Press,
1972.
- C.A.R. Hoare. Notes on Data Structuring. In Structured
Programming. O.-J. Dahl, E. W. Dijkstra and C.A.R. Hoare, Acad. Press,
1972, and C.A.R. Hoare. Record Handling. In F. Genuys, Ed.,
Programming Languages. Acad. Press, 1968.
- N. Wirth. Recollections about the Development of Pascal. In T.J.
Bergin, R.G. Gibson. History of Programming Languages II,
Addison-Wesley 1996, ISBN 0-201-89502-1.
- C.P. Thacker et al. Alto: A personal computer. Xerox PARC, Tech.
Report CSL-79-11.
- N. Wirth. The personal computer Lilith. Proc. 5th International
Conf. on Software Engineering, IEEE Computer Society Press, 1981.
- N. Wirth. Programming in Modula-2. Springer, 1974. ISBN
0-387-50150-9.
- C.A.R. Hoare. An Operating System Struturing Concept. Comm. ACM,
17, 10 (Oct. 1974), 548-557.
- P. Brinch Hansen. Operating System Principles. Prentice-Hall 1973,
ISBN 0-13-637843-9.
- A. Goldberg and A. Kay, Eds. Smalltalk-72 Instruction Manual.
Tech. Report, Xerox PARC, March 1976.
- Ole-Johan Dahl and C.A.R.Hoare. Hierarchical Program Structures.
In Structured Programming. O.-J. Dahl, E. W. Dijkstra and C.A.R.
Hoare, Acad. Press, 1972.
- N. Wirth. The Programming Language Oberon. Software, Practice and
Experience, 1988.
- M. Franz. Oberon: The overlooked Jewel. In L. Boszormenyi, J.
Gutknecht, G. Pomberger. The School of Niklaus Wirth. ISBN
1-55860-723-4 and 3-932588-85-1.
- UCSD Pascal Useres Manual. SofTech, 1981.
- N. Wirth and J. Gutknecht. Project Oberon. Addison-Wesley, 1992.
ISBN 0-201-54428-8.
Документ был представлен на конференции пионеров компьютеризации в
Бонне, 28-29.06.2001 г.
