Ответ на
»сообщение 2« (Q. Werty)
___________________________
Для себя я определяю ключевой признак ОТ следующим образом:
"Безопасность программирования превыше всего".
Другими словами, язык и среда должны в максимальной степени закрывать все возможности программиста сделать ошибку при написании кода или, по крайней мере, свести к минимуму возможные последствия этой ошибки.
Все остальные "родовые" признаки ОТ я считаю следствием этой главной концепции:
1) Концепция модуля, как "закрытой" от внешних воздействий единицы компиляции;
2) Строгая статическая типизация данных и жесткий контроль согласования типов;
3) Автоматическая сборка мусора и никакой арифметики указателей;
4) Простая грамматика языка и возможность ее полного описания в нотации Бэкуса-Наура;
Собственно благодаря этому я и пришел к ОТ.
Большое спасибо, Ваш ответ -- хорошее начало для анализа ОТ.
Согласен с Вами, что
главная цель ОТ -- надежность.
Но, ИМХО, нам еще только предстоит детальный анализ
механизмов ОТ, для чего и создана ветка.
Сам я главными (целевыми) характеристиками ОТ считаю следующие.
1. Надежность. (В чем полностью согласен с Вами.)
2. Гибкость. (В т.ч. -- расширяемость. Но не только; другой пример -- многомерные гибкие массивы.)
3. Эффективность. (ОТ не требует JVM, может эффективно работать по "голому железу", что -- в моем случае -- представляет значительный интерес.)
4. Простота. (Добиться выполнения всех трех предыдущих требований самым простым путем. Эта цель четко обозначена эпиграфом к описанию О-1: "Make it as simple as possible, but not simpler". Первые три пункта показывают, что значит "not simpler", и почему Оберон -- не brainfuck (есть такой дурацкий язык :) ).)
Опять же, повторюсь, это только основные характеристики, цели ОТ.
Нам же, смею надеяться, здесь предстоит именно анализ механизмов.
Языки программирования имеют разные цели.
Целью Си было совмещение низкоуровневого и высокоуроневого программирования (т.е. решение этого противоречия) в одном языке. Отсюда -- адресная арифметика, спецификатор register, инкрементные операторы.
Целью Си++ было сочетание противоречивых требований абстракции и эффективности. Это вполне согласуется с целями Си. Отсюда -- inline, template и т.д.
На мой взгляд, целью виртовских языков было сочетание противоречивых требований надежности, гибкости и эффективности, но приоритет всегда отдавался надежности.
Давайте рассмотрим с этой точки зрения язык Паскаль.
Small и inflexible, по словам Страуструпа. (Впрочем, какой еще оценки можно было ожидать от человека, чья фамилия является олицетворением множественного наследования? :) )
Но нас будет интересовать ответ на вопрос: а почему Паскаль inflexible?
Что, Вирт не мог создать аналога Си?
Да запросто!
При этом надо было пожертвовать только одним -- надежностью.
Вот интересная черта (классического) Паскаля: он не модульный.
Текст паскалевской программы начинается словом program, заканчивается словом end и точкой.
Все остальное -- между этим.
Как будто весь текст программы должен быть написан одним человеком.
Вопрос: почему так?
Предполагаемый ответ: не была еще в то время разработана технология
раздельной компиляции, нельзя было обеспечить надежности при использовании нескольких модулей (да и понятия модуля -- в современном смысле -- тогда еще не было).
Как решил эту проблему Си? Да никак! #include, а там -- Бог поможет.
Во многом прогресс вдоль линейки Паскаль -- Модула-2 -- Оберон есть история технологии
раздельной компиляции.
Именно она, в конце концов, позволяет оберонщикам аж с 80-х годов наслажаться надежным компонентным программированием (как с динамической загрузкой, так и с проверкой типов!), в то время как весь мир барахтался (да и сейчас еще барахтается) в прежних нерешенных проблемах Си, что получило название "DLL hell".
Другой интересная особенность Паскаля -- включение размерности массива в его тип.
Это еще как критиковали, не стану сейчас пересказывать Кернигана.
Как с эти справлялся Си? Да никак! В нем, можно сказать, нет массивов, тем паче -- контроля выхода за границы массива.
В Модуле-2 появились гибкие массивы, в Обероне -- многомерные гибкие массивы, а в Обероне-2 -- динамические многомерные гибкие массивы.
И все это -- без потери надежности, по мере возможности добавляя гибкость!
В этом разница между Виртом, с одной стороны, и Ритчи и Страуструпом -- с другой.
Один
решал проблемы, другие ей просто
пренебрегли.
Ну, на то они и молодцы, а Вирт -- старый чудак. :)
Но я немного увлекся.
Повторюсь, главная цель этой ветки --
детальный анализ ОТ.
Надеюсь, что нам здесь удастся, наконец, разобраться в этом вопросе.
Для себя я определяю ключевой признак ОТ следующим образом:
"Безопасность программирования превыше всего".
Другими словами, язык и среда должны в максимальной степени закрывать все возможности программиста сделать ошибку при написании кода или, по крайней мере, свести к минимуму возможные последствия этой ошибки.
Все остальные "родовые" признаки ОТ я считаю следствием этой главной концепции:
1) Концепция модуля, как "закрытой" от внешних воздействий единицы компиляции;
2) Строгая статическая типизация данных и жесткий контроль согласования типов;
3) Автоматическая сборка мусора и никакой арифметики указателей;
4) Простая грамматика языка и возможность ее полного описания в нотации Бэкуса-Наура;
Собственно благодаря этому я и пришел к ОТ.
Мы часто говорим, что существует оригинальная Оберон-технология (дальше -- ОТ или ТО, как кому нравится :) ), имеющая свои особенности.
На этом форуме хотелось бы четко сформулировать эти особенности и, сопоставив с особенностями других известных технологий, оценить перспективы ОТ.
Кроме оценки перспектив, такой анализ мог бы принести и непосредственную пользу.
1) Привести к более сознательному программированию на Обероне, опираясь на понимание базовых принципов ОТ, а не в рамках упоминавшегося где-то в наших ветках "синтаксического мышления".
2) Научить нас применять ОТ, даже будучи вынужденными пользоваться другими языками программирования.
3) Возможно, мы дозреем и до того, что сами сумеем в отдельных пунктах дорабатывать ОТ. Кто знает? :)
