Ответ на
»сообщение 1798« (Сергей Перовский)
___________________________
Дело в том, что попыток сформулировать, что же такое Оберон-технология (прошу заметить не язык и не система, а именно вынесенная в заголовок технология) было тут не мало. Но я уловил единственное реальное отличие от других систем: базовое понятие модуля, как единицы языка, единицы компиляции и единицы загрузки в одном лице. Да еще и с автоматическим динамическим контролем корректности вызовов.
В чем суть Оберона я уже сформулировала: модуль + расширение RECORD-типа. А динамика загрузки-выгрузки - побочная вещь.
Синтаксис языка отличается замечательной цельностью.
Именно тот случай, когда знание принципов освобождает от знания фактов.
Тони Хоар, один из ближайших друзей и соратников Вирта, называл это концептуальной экономией (conceptual economy). И наряду с надежностью и эффективностью считал очень важным свойством языка программирования.
Готов выслушать Вашу формулировку Оберон-технологии.
Боюсь, к этому не готова. Есть несколько разных Оберон-языков. Они исповедуют несколько отличные вещи. Поэтому корректнее было бы говорить об Оберон-технологиях, во множественном числе. И не удивляться, что в каких-то моментах они могут противоречить или вступать в конфликт друг с другом. По крайней мере, для пользы дела удобнее считать именно так, пока убедительно не доказано обратное.
ООП возникло дважды из двух разных классов задач.
Первый раз это было как раз имитационное моделирование - в Симуле67 было введено понятие класса и объекта, имеющего не только поля, но и схему поведения.
Если позволите, я бы это прокомментировала. В основе ООП лежит концепция класса. Откуда возникло это слово и сама идея? Разумеется, Smalltalk не был тут первопроходцем. Первым языком, в котором слово class, обозначающее ту концепцию, которая близка нашему нынешнему понимаю ООП, была Simula 67. Здесь Снегурочка с Вами готова согласиться. Но дело в том, что идея класса была сформулирована и реализована несколько раньше - в языке Simula I. Там уже были activity (классы) и process (объекты). Кристен Нигаард и Оле-Йохан Дал еще тогда заложили идею порождения объектов, каждый из которых суть
данные плюс связанные с ними
операции, правда, тогда еще без наследования.
В 1965 г. в ALGOL Bulletin вышла важнейшная работа Тони Хоара, которая называлась просто "Record Handling". В ней Хоар обобщил опыт других языков и предложил идею record class, объединив запись - record (известной по PL/I и COBOL) со ссылкой - reference (она была предложена Виртом в 1965 г. в его первом языке Euler и двумя годами ранее в языке CPL из английского Кембриджа).
Как признавались Нигаард и Дал в своих воспоминаниях о создании Симулы, именно осенью 1966 г. они тщательно изучали работы Хоара (вслед за первой вышла в марте 1966 г. и Further Thoughts on Record Handling). Они искали способ "прикрутить" понравившуюся идею record class к своей Симуле. И пришли к выводу, что ее можно сформулировать как process class, убрав слово process. Т.е. оставить просто class. Правда, reference там были в неявном виде.
В 1972 г. в Советском Союзе в изд-ве "Мир" вышел сборник "Языки программирования", где были опубликованы переводы докладов на Летней школе NATO по языкам программирования, которая прошла в 1966 г. в Виллар-де-Ланс (Франция). Если сможете его раздобыть, рекомендую внимательно изучить работу Хоара "Обработка записей" (Record Handling). Несмотря на не очень хороший перевод почитать очень даже стоит. Работа занимает примерно 60 страниц. Из нее понятно, откуда росли ноги ООП и что закладывалось в основу той самой Симулы-67, от которой обычно и принято вести отсчет эре ООП. В том же сборнике есть и столь же объемная статья Оле-Йохана Дала о Симуле. Сам Дал вместе с Нигаардом в качестве источника идей Симулы-67 упоминали именно эту тройку работ Хоара (включая и его доклад на школе NATO).
Второе открытие ООП связано с задачей построения оконного пользовательского интерфейса и языком Смолтолк. На этой задаче большинству студентов объясняют принципы ООП.
Собственно, это детище Алана Кея и дало реальный импульс моде на ООП, которая переросла потом во всеобщую "ООПсовизацию" программирования. Алан Кей, в отличие от большинства из нас, хорошо был знаком с ранними работами Никлауса Вирта, и с большим интересом относился, в частности, к тому же языку Euler, где была заложена динамическая типизация в рамках алголоподобного языка.
Поскольку сей факт известен очень немногим, приведу точные цитаты (дело было в апреле 1993 г. в американском Кембридже на конференции HOPL-II, сразу после доклада Вирта об истории разработки Паскаля):
Allen Kay: Your thesis and Euler were going in a pretty interesting direction. Why did you go back to more static languages?
Niklaus Wirth: For a thesis topic you have to do something that is new and original, you are expected to explore new ways. Afterwards, as an engineer, I felt the need for creating something that is pragmatic and useful.
В основу Паскаля были положены идеи Хоара о record handling. Но даже без намека на ООП. В Modula и Modula-2 вошли идеи Симулы по моделированию на основе процессов, хотя облечено это было в концепцию модуля из языка Mesa. В Обероне Вирт по сути вернулся к первоистокам: record + reference (но уже и ссылки на procedure) и дали фундамент для ООП без использования самого ООП. Круг замкнулся.
Таким образом, Оберон помимо того, что был квинтэссенцией Паскаля и Модулы, вобрал в себя идеи Хоара, Euler и Simula.
Ответ на
»сообщение 1809« (Илья Ермаков)
___________________________
Вот тут бы, кстати, говоря С++ с шаблонами и инлайном ой как пригодился. Один из немногих случаев, когда у ЦеПлюса есть весомое преимущество.
Инлайны это ладно (вообще-то везде должны быть), а вот шаблоны тут как помогут? Ускорить не ускорят. Если при оптимизации использованы особенности типа (весьма вероятно), наоборот замедлят, т.к. эти оптимизации уже не применить.
А если речь о быстром получении того же кода, но работающего с другим типом, то тут обычного переименования типа (в Дельфи есть) хватит. В крайнем случае find/replace.:)
Не, шаблоны только при создании библиотек контейнеров полезны...
