Что толку в Ада если Ариан 5 все равно упал - Философия программирования

Здравствуйте, CrystaX, Вы писали:

CX>Если Вы посмотрите в той же ветке чуть выше, Вы найдете там более упрощенную реализацию. Там нет систем единиц, а есть только разные физические понятия — длина, масса, время. К системам единиц я пришел, будучи подталкиваемым Кодтом.

Интересно, что тема эта не новая.
Наткнулся на днях в старой уже книге (1980-х годов) "Языки программирования Ада, Си, Паскаль. Сравнение и оценка" на статью Джехани, где (в разделе о производных типах) он предлагает подход "единиц измерения", впоследствии реализованный в языке Физкал.
Надо отметить, что к тому времени в языке Ада уже существовала возможность объявления производных типов:

type LENGTH is new FLOAT;
type AREA is new FLOAT;
type VOLUME is new FLOAT;

Объявленные производные типы по умолчанию не могут смешиваться между собой.
Чтобы разрешить корректное смешение типов (например, когда переменная типа VOLUME получается из произведения переменных типов AREA и LENGTH) требуется определить соответствующие операторы.
Джехани не понравилось, что требуется определять так много вспомогательных операторов, и он предложил другой способ, который и был реализован в языке Физкал.
Оба эти способа отличаются от того, как это делается в Си++. (Что уже интересно.)
Такое впечатление, что объявление класса является в Си++ панацеей, хотя иногда можно было бы (ИМХО) поискать и более простые пути.
Что касается возможного решения этой проблемы для Оберона, то мне пришла в голову другая идея.
В языке Оберон немного не хватает возможности накладывать ограничения (constraint) на использования типов.
В частности нет средства, аналогичного "дженерикам", хотя еще в середине 1990-х Роу и Шиперски предложили простой способ реализовать lightweight parametric polymorphism для Оберона. (Я узнал об этом от Трурля.)
В принципе, ограничение использования типов, производных от базовых — тоже вид constraint-а.
Может быть, есть возможность найти общее решение для этих случаев?
(P.S. BTW: то, что в свое время была издана целая книга о сравнении языков Ада, Си и Паскаль (причем некоторые статьи были написаны еще в середине 70-х), указывает на то, что нащ "флейм" ведется уже около 30 лет!

)

AVC>>Проще говоря, назначение Оберона (поддержка компонентного программирования) отличается от назначения Си++ (поддержка ООП и обобщенного программирования в рамках отдельной программы, избегая ненужного "оверхеда" в run-time).
AVC>>Программист, пишущий на Обероне, иногда испытывает некоторые трудности, реализуя то, что на Си++ выразить сравнительно легко.
AVC>>Программист, пишущий на Си++, зачастую вообще не представляет, чего он лишен.

CX>Допускаю. Но как-то в голову ничего не приходит. Если Вас не затруднит, не могли бы Вы привести примерный список возможностей? Как известно, язык не только расширяет, но и ограничивает мышление.

Пытаться перечислить достоинства обероновского подхода не так легко, хотя они для меня очевидны.
Возможно, здесь нужен более систематический и уравновешенный ум, чем мой.

Кроме того, нужно больше времени, чем у меня обычно есть в распоряжении.

Но я попробую назвать хотя бы несколько преимуществ.
Благодаря защите типов, раздельной компиляции и динамической загрузке модулей, "оберонщики" пользуются компонентным подходом уже почти 20 лет, т.е. намного раньше остальных (до COM, до Java и т.д.). Причем программирование компонентов ничем не отличается от "просто программирования". (В Обероне это одно и то же.)
Многие свойства языка Оберон объясняются требованиями компонентного подхода.
Например: строгий контроль типов (type safety) и сборка мусора (garbage collection).
Оберон позволяет использовать переменную только в соответствии с ее типом (исключение составляет низкоуровневре программирование с явным использованием псевдомодуля SYSTEM, необходимого для написания самых низких "этажей" Оберон-системы). Статический контроль типов осуществляется при компиляции, динамический в run-time. Динамический контроль реализован весьма эффективно. Для проверки указателя (или процедурного типа) достаточно сравнить его с NIL (указатели инициализируются значением NIL, так что указатель всегда либо равен NIL, либо указывет на переменную, созданную с помощью NEW). Для проверки динамического типа достаточно одного сравнения, т.к. каждый тип в Оберона характеризуется (кроме прочего) уровнем расширения.
Если учесть, что Оберон в основном работает по "голому железу", то цена, которую он "платит" за надежность, минимальна — оверхед по отношению к Си/Си++ составляет всего несколько процентов (а не разы, как для Java или C#).
Если убрать из кода дополнительные проверки, то оверхеда нет совсем. (В конце 1990-х XDS "побил" все компиляторы Си++, включая Watcom, на тесте drystone).
Сборка мусора, вероятно, попала в Оберон не из Лиспа, а из паскалеподобного языка Cedar, который был создан в качестве эксперимента в Xerox PARC по следам Смоллтока. Т.к. на один и тот же объект можно ссылаться из разных компонентов, совершенно ничего не знающих друг о друге и написанных разными программистами в разное время, то самый простой способ обеспечить корректную работу с памятью — централизовать сборку мусора, поручить ее системе, а не доверять ее отдельным компонентам.
Чтобы обеспечить простоту сборки мусора, Вирт полностью отказался от вариантных записей (RECORD CASE или union), полностью вытеснив их расширяемыми (extensible) записями.
Все известные мне компиляторы Оберона предоставляют возможность финализации как объектов, так и модулей.
Можно сделать вывод, что в Обероне (в отличие от Паскаля или даже Модулы-2) Вирту полностью удалось решить проблему защиты памяти, причем минимальными средствами.
Кроме того, сборка мусора облегчает программисту реализацию нетривиальных алгоритмов, работающих с динамической памятью.
В Обероне "упор" делается не на классы, как в Си++, а на модули: модуль в Обероне — и единица трансляции, и единица загрузки, и пространство имен, и единица инкапсуляции. Благодаря последнему, модули позволяют естественно реализовывать целые паттерны проектирования (вроде тех, что описаны в книге "банды четырех"). Нет никакой потребности в явных извращениях, вроде friend-ов.
Модульная структура Оберона облегчает написание программ в команде. Если интерфейс модуля не меняется, то клиентные модули не нуждаются в перекомпиляции. Вместе с тем, Оберон обеспечивает межмодульный контроль типов.
Поддержка обероновской средой информации о типах в run-time создает возможности метапрограммирования. Например, в ETH Oberon обработка исключений решается методами метапрограммирования, причем, если исключения не возникло, накладные расходы равны нулю.
В Обероне нет программы или главной процедуры (main). Действия активируются командами вида M.P, где M — имя модуля, а P — имя процедуры. Это облегчает создание тестов, т.к. тест может вызывать непосредственно нужный фрагмент программы, не надо писать отдельную тестовую программу. Тест может храниться непосредственно в исходнике.
Т.к. типичная обероновская среда (вроде BlackBox) работают с документами (а не просто текстами), то документирование программ сильно облегчается. Можно использовать по своему усмотрению выделение цветом или шрифтом, или, например, гиперссылки. Можно использовать для документирования программы фрагменты других документов, непосредственно вставив их в соответствующие места программы.
Ну, это уже "рюшечки", хотя это и удобно, и красиво.
В обероновской среде нет никакой нужды в отдельном программистском IDE. Все дополнительные возможности достаются (благодаря свойствам среды) практически бесплатно. (Поэтому наивна критика вроде: "Вы говорите о свойствах языка или свойствах среды? Определитесь!" Просто уровень интеграции в Обероне гораздо выше, чем в обычных системах.)
Иногда мне даже не верится, что такие возможности создаются на основе языка, настолько простого, что его первый компилятор (написанный Виртом) "весил" всего 45K!

Конечно, и у других языков есть свои плюсы. Мне понравилась изобретательность, которую проявили eao197 и Вы, решая проблемы с помощью шаблонов. Но все же я отношусь к этим примерам не более как к хитроумным трюкам, вроде известной задачи о программе, печатающей саму себя. Например, на Обероне она решается так (пример прилагается к компилятору XDS):

<*+ MAIN *> MODULE self;
IMPORT InOut;
CONST C=27X; F=6; L=15;
VAR s: ARRAY F+L OF ARRAY 64 OF CHAR;
    i: INTEGER;
BEGIN
  s[ 0] := '<*+ MAIN *> MODULE self;';
  s[ 1] := 'IMPORT InOut;';
  s[ 2] := 'CONST C=27X; F=6; L=15;';
  s[ 3] := 'VAR s: ARRAY F+L OF ARRAY 64 OF CHAR;';
  s[ 4] := '    i: INTEGER;';
  s[ 5] := 'BEGIN';
  s[ 6] := '  FOR i := 0 TO (F+L)*2-1 DO';
  s[ 7] := '    IF i>=F*2+L THEN InOut.WriteString (s[i-F-L])';
  s[ 8] := '    ELSIF i<F   THEN InOut.WriteString (s[i])';
  s[ 9] := '    ELSE';
  s[10] := '      InOut.WriteString ("  s[");';
  s[11] := '      InOut.WriteInt (i-F, 2);';
  s[12] := '      InOut.WriteString ("] := ");';
  s[13] := '      InOut.Write (C);';
  s[14] := '      InOut.WriteString (s[i-F]);';
  s[15] := '      InOut.Write (C);';
  s[16] := '      InOut.Write (";")';
  s[17] := '    END;';
  s[18] := '    InOut.WriteLn;';
  s[19] := '  END';
  s[20] := 'END self.';
  FOR i := 0 TO (F+L)*2-1 DO
    IF i>=F*2+L THEN InOut.WriteString (s[i-F-L])
    ELSIF i<F   THEN InOut.WriteString (s[i])
    ELSE
      InOut.WriteString ("  s[");
      InOut.WriteInt (i-F, 2);
      InOut.WriteString ("] := ");
      InOut.Write (C);
      InOut.WriteString (s[i-F]);
      InOut.Write (C);
      InOut.Write (";")
    END;
    InOut.WriteLn;
  END
END self.

Здравствуйте, AVC, Вы писали:

AVC>Здравствуйте, CrystaX, Вы писали:

CX>>Если Вы посмотрите в той же ветке чуть выше, Вы найдете там более упрощенную реализацию. Там нет систем единиц, а есть только разные физические понятия — длина, масса, время. К системам единиц я пришел, будучи подталкиваемым Кодтом.

AVC>Интересно, что тема эта не новая.
AVC>Наткнулся на днях в старой уже книге (1980-х годов) "Языки программирования Ада, Си, Паскаль. Сравнение и оценка" на статью Джехани, где (в разделе о производных типах) он предлагает подход "единиц измерения", впоследствии реализованный в языке Физкал.
AVC>Надо отметить, что к тому времени в языке Ада уже существовала возможность объявления производных типов:
AVC>

AVC>type LENGTH is new FLOAT;
AVC>type AREA is new FLOAT;
AVC>type VOLUME is new FLOAT;
AVC>

AVC>Объявленные производные типы по умолчанию не могут смешиваться между собой.
AVC>Чтобы разрешить корректное смешение типов (например, когда переменная типа VOLUME получается из произведения переменных типов AREA и LENGTH) требуется определить соответствующие операторы.
AVC>Джехани не понравилось, что требуется определять так много вспомогательных операторов, и он предложил другой способ, который и был реализован в языке Физкал.
AVC>Оба эти способа отличаются от того, как это делается в Си++. (Что уже интересно.)
AVC>Такое впечатление, что объявление класса является в Си++ панацеей, хотя иногда можно было бы (ИМХО) поискать и более простые пути.

Вот тут немного не согласен. Ведь класс в C++ — это просто абстракция, ничем не лучше и не хуже других похожих абстракций. Поэтому то, что данную конкретную задачу (расширение типов) решают на C++ с помощью классов, на мой взгляд, не хуже и не лучше других подходов. Вообще, конечно, на эту тему можно долго спорить, но вряд ли из нее удастся извлечь хотя бы маленькое рациональное зерно. Посему спорить не буду.

AVC>Что касается возможного решения этой проблемы для Оберона, то мне пришла в голову другая идея.
AVC>В языке Оберон немного не хватает возможности накладывать ограничения (constraint) на использования типов.
AVC>В частности нет средства, аналогичного "дженерикам", хотя еще в середине 1990-х Роу и Шиперски предложили простой способ реализовать lightweight parametric polymorphism для Оберона. (Я узнал об этом от Трурля.)
AVC>В принципе, ограничение использования типов, производных от базовых — тоже вид constraint-а.
AVC>Может быть, есть возможность найти общее решение для этих случаев?
AVC>(P.S. BTW: то, что в свое время была издана целая книга о сравнении языков Ада, Си и Паскаль (причем некоторые статьи были написаны еще в середине 70-х), указывает на то, что нащ "флейм" ведется уже около 30 лет!

)

Как известно, все новое — это хорошо забытое старое.

AVC>Пытаться перечислить достоинства обероновского подхода не так легко, хотя они для меня очевидны.
AVC>Возможно, здесь нужен более систематический и уравновешенный ум, чем мой.

AVC>Кроме того, нужно больше времени, чем у меня обычно есть в распоряжении.

AVC>Но я попробую назвать хотя бы несколько преимуществ.
[skipped]

В этом месте Вы рассказали только ожидаемое, а именно — модули и garbage collector. На самом деле это не совсем то, что я хотел услышать. Попробую переформулировать вопрос по-другому: "Что есть в Обероне такого, принципиально не реализуемого на C++ с приемлемыми затратами или же без таковых?".
Объясню более подробно. Та же модульность и garbage collector вполне реализуемы на C++ (с помощью конвенций, принятых для проекта — не используем голые указатели, только смарт-пойнтеры, определяем жесткие интерфейсы модулей и т.д. и т.п.). Понятно, что неопытный программист, вторгшийся в такую систему и/или незнакомый с конвенцией, принятой в текущем проекте, запросто может посеять трудноуловимый (в той или иной степени) баг. Оберон же реализует эти конвенции на уровне языка, поэтому за их выполнением следит компилятор, а не программисты. Но, честно говоря, для меня это не довод. Я сейчас говорю не о каких-то теоретических коммандах программистов, в которых профессиональный уровень участников неоднороден, а о себе и людях, с которыми я работаю. В нашей ситуации вероятность нарушения конвенции крайне мала, а посему это преимущество Оберона для меня сводится практически к нулю. Повторю еще раз — я не пытаюсь доказать преимущество C++ над всеми остальными языками (в этом форуме и без меня найдутся те, кто это будет доказывать). Я пытаюсь понять одну простую вещь: "Что принципиально нового может принести для меня Оберон?" (ибо я есть C++-программист, а Вы утверждали, что C++-программист зачастую не представляет, чего он лишен).
Теперь о формулировке "приемлемые затраты". В конце концов, и на чистом C можно написать программу, построенную на ООП, с ручной реализацией наследования, ручным разруливанием "виртуальных" вызовов и т.д. Как легко заметить, здесь также все основывается на конвенции. Но в этом случае затраты времени и труда, на мой взгляд, слишком высоки. Так какие же затраты приемлемы а какие нет? А очень просто — если мы вводим "запретительную" конвенцию (вроде того же запрета на использование голых указателей), большую часть работы удается автоматизировать. Такие трудозатраты приемлемы. Если же конвенция носит "принудительный" характер (реализация наследования и динамического полиморфизма на C), возникает гораздо большая вероятность промахнуться и допустить ошибку. Такие трудозатраты неприемлемы. Данная формулировка приемлемости/неприемлемости затрат относится исключительно к фразе "Что есть в Обероне такого, принципиально не реализуемого на C++ с приемлемыми затратами или же без таковых?" и никоим образом не претендует на универсальность.

Так что скажете? Что есть в Обероне такого, что может сильно облегчить мне жизнь как программисту (или даже заставит по-новому взглянуть на суть программирования вообще)?

AVC>В Обероне нет программы или главной процедуры (main). Действия активируются командами вида M.P, где M — имя модуля, а P — имя процедуры. Это облегчает создание тестов, т.к. тест может вызывать непосредственно нужный фрагмент программы, не надо писать отдельную тестовую программу. Тест может храниться непосредственно в исходнике.
AVC>Т.к. типичная обероновская среда (вроде BlackBox) работают с документами (а не просто текстами), то документирование программ сильно облегчается. Можно использовать по своему усмотрению выделение цветом или шрифтом, или, например, гиперссылки. Можно использовать для документирования программы фрагменты других документов, непосредственно вставив их в соответствующие места программы.
AVC>Ну, это уже "рюшечки", хотя это и удобно, и красиво.
AVC>В обероновской среде нет никакой нужды в отдельном программистском IDE. Все дополнительные возможности достаются (благодаря свойствам среды) практически бесплатно. (Поэтому наивна критика вроде: "Вы говорите о свойствах языка или свойствах среды? Определитесь!" Просто уровень интеграции в Обероне гораздо выше, чем в обычных системах.)

Алексей, согласитесь все же, что все это не имеет ни малейшего отношения к языку. Быть может, для Вас заданный мною вопрос и прозвучал наивно, но для меня предыдущий текст звучит ничуть не менее наивно.

AVC>Иногда мне даже не верится, что такие возможности создаются на основе языка, настолько простого, что его первый компилятор (написанный Виртом) "весил" всего 45K!

Вообще говоря, это совсем не аргумент. Программы создают люди и, следовательно, программы получаются хорошими или плохими не из-за языка, на которых их пишут, а из-за людей, которые их создают.

AVC>Конечно, и у других языков есть свои плюсы. Мне понравилась изобретательность, которую проявили eao197 и Вы, решая проблемы с помощью шаблонов. Но все же я отношусь к этим примерам не более как к хитроумным трюкам, вроде известной задачи о программе, печатающей саму себя. Например, на Обероне она решается так (пример прилагается к компилятору XDS):
[skipped]

Когда будет немного больше времени, обязательно изучу Ваш код — интересно!

Но все же "изобретательность, проявленная мною и Евгением" при решении наших задач — это далеко не только хитроумные трюки! Это вполне рабочие решения, применяемые в промышленном коде и позволяющие сэкономить много сил и времени.

... << RSDN@Home 1.1.4 beta 7 rev. 447>>

Здравствуйте, A.Lokotkov, Вы писали:

AVC>>Кстати, интересно, кто-нибудь задумался, чтобы случилось, если бы вследствие этого выхода за границы диапазона исключения бы не было? Имеем: ракету рядом с земной поверхностью, "руководствующуюся" совершенно неверными данными.

AL>В случае с Арианом-5 ничего бы не было. Ничего. Исключение возникло в "мертвом" коде, который кочевал из проекта в проект и в 5-м Ариане был не нужен. Там в отчете всё есть.

Прошу прощения, не сразу понял, что Вы имеете в виду.
Сработал автоматизм писателя компиляторов: "мертвый" код — код, который никогда не исполняется.
А Вы имели в виду: "мертвый" код — бесполезный, уже не нужный.
Сейчас вот дошло.

Все же, дело не в том, что этот "мертвый" код был не нужен в Ариане-5. Он был нужен, но только до взлета ракеты.

ошибка произошла в компоненте ПО, предназначенном исключительно для выполнения "регулировки" Инерциальной Платформы. Причем – что звучит парадоксально, если не абсурдно – этот программный модуль выдает значимые результаты только до момента H0 + 7 сек. отрыва ракеты со стартовой площадки. После того, как ракета взлетела, никакого влияния на полет функционирование данного модуля оказать не могло;

однако, "функция регулировки" действительно должна была (в соответствии с установленными для нее требованиями) действовать еще 50 сек. после инициации "полетного режима" на шине Навигационной Системы (момент H0-3 сек.), что она с усердием дурака, которого заставили богу молиться, и делала;

Здравствуйте, CrystaX, Вы писали:

AVC>>Такое впечатление, что объявление класса является в Си++ панацеей, хотя иногда можно было бы (ИМХО) поискать и более простые пути.

CX>Вот тут немного не согласен. Ведь класс в C++ — это просто абстракция, ничем не лучше и не хуже других похожих абстракций. Поэтому то, что данную конкретную задачу (расширение типов) решают на C++ с помощью классов, на мой взгляд, не хуже и не лучше других подходов. Вообще, конечно, на эту тему можно долго спорить, но вряд ли из нее удастся извлечь хотя бы маленькое рациональное зерно. Посему спорить не буду.

Наверное, правильно. Зачастую мы слишком много и слишком горячо спорим о мелочах.

AVC>>Пытаться перечислить достоинства обероновского подхода не так легко, хотя они для меня очевидны.
AVC>>Возможно, здесь нужен более систематический и уравновешенный ум, чем мой.

AVC>>Кроме того, нужно больше времени, чем у меня обычно есть в распоряжении.

AVC>>Но я попробую назвать хотя бы несколько преимуществ.
CX>[skipped]

CX>В этом месте Вы рассказали только ожидаемое, а именно — модули и garbage collector. На самом деле это не совсем то, что я хотел услышать. Попробую переформулировать вопрос по-другому: "Что есть в Обероне такого, принципиально не реализуемого на C++ с приемлемыми затратами или же без таковых?".
CX>Объясню более подробно. Та же модульность и garbage collector вполне реализуемы на C++ (с помощью конвенций, принятых для проекта — не используем голые указатели, только смарт-пойнтеры, определяем жесткие интерфейсы модулей и т.д. и т.п.). Понятно, что неопытный программист, вторгшийся в такую систему и/или незнакомый с конвенцией, принятой в текущем проекте, запросто может посеять трудноуловимый (в той или иной степени) баг. Оберон же реализует эти конвенции на уровне языка, поэтому за их выполнением следит компилятор, а не программисты. Но, честно говоря, для меня это не довод. Я сейчас говорю не о каких-то теоретических коммандах программистов, в которых профессиональный уровень участников неоднороден, а о себе и людях, с которыми я работаю. В нашей ситуации вероятность нарушения конвенции крайне мала, а посему это преимущество Оберона для меня сводится практически к нулю. Повторю еще раз — я не пытаюсь доказать преимущество C++ над всеми остальными языками (в этом форуме и без меня найдутся те, кто это будет доказывать). Я пытаюсь понять одну простую вещь: "Что принципиально нового может принести для меня Оберон?" (ибо я есть C++-программист, а Вы утверждали, что C++-программист зачастую не представляет, чего он лишен).

Сходный аргумент выдвигает и Евгений (eao197).
Честно говоря, я здесь вас (обоих) не совсем понимаю.
Вы так верите в неконтролируемые компилятором конвенции, которые не будут нарушаться?
Так ведь все ошибки делаются "ненарочно", и ошибки в соблюдении конвенций — в том числе.
У меня же конвенции с детства ассоциируются с Паниковским и прочими детьми лейтенанта Шмидта.

А может быть, Си++программисты просто несколько самоуверены, и каждый из них думает: "Я-то уж не ошибусь!"?

В Обероне можно выделить две принципиальные вещи:
1) надежность (особо удалась Вирту защита памяти; надежность — это очень приятное чувство!);
2) простота.
По поводу последнего можно распространяться долго.
Здесь не только простота языка.
Что освоить COM, толковые люди (которые потом пишут об этом книги) тратят по полгода; при этом, по их словам, ощущают туман в своей голове.

А на Обероне Вы просто пишете свой модуль.
Возьмем самое малое. Разве невидимо и безошибочно работающий garbage collector не лучше, чем AddRef() и Release()?
Разве это не аргумент?
Неужели простота ничего не стоит? А затраты на изучение слишком сложных программных продуктов, а потерянные годы жизни (все лучшие годы!

), а тот ужасный (и потенциально опасный!) код, который громоздят те несчастные, которые так и не разобрались до конца во всех тонкостях очередного модного и, как всегда, чрезмерно сложного средства?
А можете Вы гарантировать, что Ваш код не будет сопровождать менее грамотный программист, который не станет соблюдать все конвенции?
О комментариях, например, уже давно говорят, что они не должны содержать то, что можно сказать с помощью самого кода.
А ведь Ваши конвенции — во многом такие вот комментарии. Многие решения в коде будут без них непонятны.

CX>Теперь о формулировке "приемлемые затраты". В конце концов, и на чистом C можно написать программу, построенную на ООП, с ручной реализацией наследования, ручным разруливанием "виртуальных" вызовов и т.д. Как легко заметить, здесь также все основывается на конвенции. Но в этом случае затраты времени и труда, на мой взгляд, слишком высоки.

Не все согласятся с Вами так уж безоговорочно.
Пайк в своей старой статье "Notes on Programming in C" пишет:

The O-O languages give you you more of course — prettier syntax, derived types and so on — but conceptually they provide little extra.
Combining data-driven programs with function pointers leads to an astinishingly expressive way of working, a way that, in my experience, has often led to pleasant surprises. Even without a special O-O language, you can get 90% of the benefit for no extra work and be more in control of result.

Впрочем, я, разумеется, не спорю, что O-O языки лучше приспособлены для ООП.

CX>Так какие же затраты приемлемы а какие нет? А очень просто — если мы вводим "запретительную" конвенцию (вроде того же запрета на использование голых указателей), большую часть работы удается автоматизировать. Такие трудозатраты приемлемы. Если же конвенция носит "принудительный" характер (реализация наследования и динамического полиморфизма на C), возникает гораздо большая вероятность промахнуться и допустить ошибку. Такие трудозатраты неприемлемы. Данная формулировка приемлемости/неприемлемости затрат относится исключительно к фразе "Что есть в Обероне такого, принципиально не реализуемого на C++ с приемлемыми затратами или же без таковых?" и никоим образом не претендует на универсальность.

CX>Так что скажете? Что есть в Обероне такого, что может сильно облегчить мне жизнь как программисту (или даже заставит по-новому взглянуть на суть программирования вообще)?

Подумаю, "поскриплю" мозгами.

AVC>>В Обероне нет программы или главной процедуры (main). Действия активируются командами вида M.P, где M — имя модуля, а P — имя процедуры. Это облегчает создание тестов, т.к. тест может вызывать непосредственно нужный фрагмент программы, не надо писать отдельную тестовую программу. Тест может храниться непосредственно в исходнике.
AVC>>Т.к. типичная обероновская среда (вроде BlackBox) работают с документами (а не просто текстами), то документирование программ сильно облегчается. Можно использовать по своему усмотрению выделение цветом или шрифтом, или, например, гиперссылки. Можно использовать для документирования программы фрагменты других документов, непосредственно вставив их в соответствующие места программы.
AVC>>Ну, это уже "рюшечки", хотя это и удобно, и красиво.
AVC>>В обероновской среде нет никакой нужды в отдельном программистском IDE. Все дополнительные возможности достаются (благодаря свойствам среды) практически бесплатно. (Поэтому наивна критика вроде: "Вы говорите о свойствах языка или свойствах среды? Определитесь!" Просто уровень интеграции в Обероне гораздо выше, чем в обычных системах.)

CX>Алексей, согласитесь все же, что все это не имеет ни малейшего отношения к языку. Быть может, для Вас заданный мною вопрос и прозвучал наивно, но для меня предыдущий текст звучит ничуть не менее наивно.

Может быть.

А, может быть, и нет.
Между Обероном-языком и Обероном-средой (и Обероном-системой) есть связь.
Ничего подобного я не видел в системах, написанных на Си.

AVC>>Иногда мне даже не верится, что такие возможности создаются на основе языка, настолько простого, что его первый компилятор (написанный Виртом) "весил" всего 45K!

CX>Вообще говоря, это совсем не аргумент. Программы создают люди и, следовательно, программы получаются хорошими или плохими не из-за языка, на которых их пишут, а из-за людей, которые их создают.

Правильно. В частности, потому что именно люди выбирают хорошие или плохие языки.

Я привел размер оригинального компилятора Вирта только для того, чтобы проиллюстрировать простоту Оберона.
Другие сторонники Оберона зачастую приводят в качестве аргумента размер определения языка (всего несколько страниц).
Но описание может быть просто неполным, "урезанным".
Размер компилятора убеждает больше.

AVC>>Конечно, и у других языков есть свои плюсы. Мне понравилась изобретательность, которую проявили eao197 и Вы, решая проблемы с помощью шаблонов. Но все же я отношусь к этим примерам не более как к хитроумным трюкам, вроде известной задачи о программе, печатающей саму себя. Например, на Обероне она решается так (пример прилагается к компилятору XDS):
CX>[skipped]

CX>Когда будет немного больше времени, обязательно изучу Ваш код — интересно!

Это не мой код.

Это один из примеров, поставляемых вместе с компилятором XDS.
Я привел его как пример остроумного (да еще и написанного на любимом Обероне!

), но не имеющего большого практического значения кода.
Впрочем, это не критика кода, т.к. охотно допускаю и просто "искусство для искусства".

Но, однако, не в "производственной" программе.

CX>Но все же "изобретательность, проявленная мною и Евгением" при решении наших задач — это далеко не только хитроумные трюки! Это вполне рабочие решения, применяемые в промышленном коде и позволяющие сэкономить много сил и времени.

Возможно. Хотя, честно говоря, это вызывает у меня сомнения. Иногда мне кажется, что здесь больше "любви к искусству", чем реальной потребности.
Я не оспариваю пользы трюков, когда они действительно необходимы.
Вероятно, что в Вашем случае и в случае Евгения это действительно так.
Но представьте себе, что весь код (а не отдельный небольшой фрагмент) такой!
Читателю программы, ИМХО, будет легче сразу повеситься!

Здравствуйте, AVC, Вы писали:

CX>>В этом месте Вы рассказали только ожидаемое, а именно — модули и garbage collector. На самом деле это не совсем то, что я хотел услышать. Попробую переформулировать вопрос по-другому: "Что есть в Обероне такого, принципиально не реализуемого на C++ с приемлемыми затратами или же без таковых?".
CX>>Объясню более подробно. Та же модульность и garbage collector вполне реализуемы на C++ (с помощью конвенций, принятых для проекта — не используем голые указатели, только смарт-пойнтеры, определяем жесткие интерфейсы модулей и т.д. и т.п.). Понятно, что неопытный программист, вторгшийся в такую систему и/или незнакомый с конвенцией, принятой в текущем проекте, запросто может посеять трудноуловимый (в той или иной степени) баг. Оберон же реализует эти конвенции на уровне языка, поэтому за их выполнением следит компилятор, а не программисты. Но, честно говоря, для меня это не довод. Я сейчас говорю не о каких-то теоретических коммандах программистов, в которых профессиональный уровень участников неоднороден, а о себе и людях, с которыми я работаю. В нашей ситуации вероятность нарушения конвенции крайне мала, а посему это преимущество Оберона для меня сводится практически к нулю. Повторю еще раз — я не пытаюсь доказать преимущество C++ над всеми остальными языками (в этом форуме и без меня найдутся те, кто это будет доказывать). Я пытаюсь понять одну простую вещь: "Что принципиально нового может принести для меня Оберон?" (ибо я есть C++-программист, а Вы утверждали, что C++-программист зачастую не представляет, чего он лишен).

AVC>Сходный аргумент выдвигает и Евгений (eao197).
AVC>Честно говоря, я здесь вас (обоих) не совсем понимаю.
AVC>Вы так верите в неконтролируемые компилятором конвенции, которые не будут нарушаться?
AVC>Так ведь все ошибки делаются "ненарочно", и ошибки в соблюдении конвенций — в том числе.
AVC>У меня же конвенции с детства ассоциируются с Паниковским и прочими детьми лейтенанта Шмидта.

AVC>А может быть, Си++программисты просто несколько самоуверены, и каждый из них думает: "Я-то уж не ошибусь!"?

Вы знаете, определенная доля самоуверенности во мне, конечно же, есть. И конечно же, соблюдение конвенций не спасает на 100% от ошибок. Но на 95% спасает, а это уже приемлемый уровень. Ведь у меня две альтернативы:
1. Полностью положиться на безопасный язык программирования и не задумываться об этом вообще.
2. Создать безопасность самому, следую конвенциям, и имея возможность, в случае необходимости, в каком-то конкретном куске коде переделать его, не нарушая безопасность "снаружи" (для пользователей этого кода), но убрав лишние проверки и прочие прелести безопасного кода внутри, достигнув тем самым значительного улучшения производительности.

Я выбираю второй вариант. Более того, слова о достижении более высокой производительности — это не просто слова, а случаи (не такие и редкие) из моей практики. Мне очень нравиться принцип "сделать из правильной программы быструю гораздо легче, чем из быстрой — правильную", но защищенные языки программирования во многом ограничивают мою свободу в создании действительно быстрой программы. Да, они предлагают взамен безопасность (и это дорогого стоит!), но уж такова специфика моей работы, что мне зачастую очень важна производительность (я говорю о программировании под микродевайсы, у которых очень ограниченные ресурсы).

AVC>В Обероне можно выделить две принципиальные вещи:
AVC>1) надежность (особо удалась Вирту защита памяти; надежность — это очень приятное чувство!);
AVC>2) простота.
AVC>По поводу последнего можно распространяться долго.
AVC>Здесь не только простота языка.
AVC>Что освоить COM, толковые люди (которые потом пишут об этом книги) тратят по полгода; при этом, по их словам, ощущают туман в своей голове.

AVC>А на Обероне Вы просто пишете свой модуль.
AVC>Возьмем самое малое. Разве невидимо и безошибочно работающий garbage collector не лучше, чем AddRef() и Release()?
AVC>Разве это не аргумент?

Нет. Для меня — не аргумент. Потому что те же AddRef и Release пишутся всего пару раз и потом вызывающий код ими только пользуется. При должной организации разбиения на модули (не в Обероновском понимании этого слова) нет никакой нужды знать, что происходит в потрохах.

AVC>Неужели простота ничего не стоит? А затраты на изучение слишком сложных программных продуктов, а потерянные годы жизни (все лучшие годы!

), а тот ужасный (и потенциально опасный!) код, который громоздят те несчастные, которые так и не разобрались до конца во всех тонкостях очередного модного и, как всегда, чрезмерно сложного средства?
AVC>А можете Вы гарантировать, что Ваш код не будет сопровождать менее грамотный программист, который не станет соблюдать все конвенции?
AVC>О комментариях, например, уже давно говорят, что они не должны содержать то, что можно сказать с помощью самого кода.
AVC>А ведь Ваши конвенции — во многом такие вот комментарии. Многие решения в коде будут без них непонятны.

Мне — понятны. А также людям, с которыми я работаю. Ибо мы сообща вырабатываем эти конвенции и потом сообща их придерживаемся. Аргумент же о сопровождающем программисте, который не будет знать об этих конвенциях — я Вам об этом уже говорил. Не знаю, быть может это только мне так повезло, но наше руководство не будет бросать на поддержку кода неподготовленных людей. Кроме того, все соглашения и замечания по проекту хранятся в документе "Project design", который надо прочитать, прежде чем браться за поддержку.

CX>>Так что скажете? Что есть в Обероне такого, что может сильно облегчить мне жизнь как программисту (или даже заставит по-новому взглянуть на суть программирования вообще)?

AVC>Подумаю, "поскриплю" мозгами.

Ок, буду ждать.

CX>>Алексей, согласитесь все же, что все это не имеет ни малейшего отношения к языку. Быть может, для Вас заданный мною вопрос и прозвучал наивно, но для меня предыдущий текст звучит ничуть не менее наивно.

AVC>Может быть.

AVC>А, может быть, и нет.
AVC>Между Обероном-языком и Обероном-средой (и Обероном-системой) есть связь.

Но мы ведь говорим об Обероне-языке, а не об Обероне-системе?

AVC>Ничего подобного я не видел в системах, написанных на Си.

Хмм... А как же Unix? Типичнейшая C-среда. Да, конечно, если говорить о GUI и прочих рюшечках, то этого нет. Но мне, честно говоря, GUI абсолютно не важен. Мне очень нравиться высказывание Денниса Ритчи по этому поводу: "UNIX — это очень простая и гибкая операционная система. Правда, для того, чтобы понять и принять эту простоту, требуется гений или, как минимум, программист"

Вообще же, на сравнение сред предлагаю не скатываться, т.к. в данном случае гораздо больший вес имеют личные предпочтения.

AVC>Правильно. В частности, потому что именно люди выбирают хорошие или плохие языки.

AVC>Я привел размер оригинального компилятора Вирта только для того, чтобы проиллюстрировать простоту Оберона.
AVC>Другие сторонники Оберона зачастую приводят в качестве аргумента размер определения языка (всего несколько страниц).
AVC>Но описание может быть просто неполным, "урезанным".
AVC>Размер компилятора убеждает больше.

Честно говоря, меня не убеждает. Я, например, и на ассемблерах, бывало, писал — так там размер транслятора и того меньше. И что? О чем это говорит? Да ровным счетом ни о чем.

AVC>Это не мой код.

AVC>Это один из примеров, поставляемых вместе с компилятором XDS.
AVC>Я привел его как пример остроумного (да еще и написанного на любимом Обероне!

), но не имеющего большого практического значения кода.
AVC>Впрочем, это не критика кода, т.к. охотно допускаю и просто "искусство для искусства".

AVC>Но, однако, не в "производственной" программе.

Вот в этом, похоже, мы с Вами и не сходимся — я допускаю в производственной программе использование интересного кода.

AVC>Возможно. Хотя, честно говоря, это вызывает у меня сомнения. Иногда мне кажется, что здесь больше "любви к искусству", чем реальной потребности.
AVC>Я не оспариваю пользы трюков, когда они действительно необходимы.
AVC>Вероятно, что в Вашем случае и в случае Евгения это действительно так.
AVC>Но представьте себе, что весь код (а не отдельный небольшой фрагмент) такой!
AVC>Читателю программы, ИМХО, будет легче сразу повеситься!

Здесь мы опять переходим на обсуждение некого гипотетического "читателя программы", который к тому же (гипотетически!) недостаточно грамотен, чтобы разобраться в коде, даже предварительно почитав документ "Project design"! Однако, мне как-то неинтересно обсуждать этого самого читателя. Прямо как у Стругацких: "Ах, дурак, какой ты умный! Какой ты хороший, дурак! Не беспокойся ни о чем, дурак!"

... << RSDN@Home 1.1.4 beta 7 rev. 447>>

Здравствуйте, AVC

Почитал тут вашу переписку с CrystaX, получил большое удовольствие. Не часто в сравнениях каких-либо языков здесь на RSDN я видел такое спокойное и конструктивное изложение своих взглядов и позиций. Мой респект вам, Алексей и Дмитрий.

AVC>Сходный аргумент выдвигает и Евгений (eao197).
AVC>Честно говоря, я здесь вас (обоих) не совсем понимаю.
AVC>Вы так верите в неконтролируемые компилятором конвенции, которые не будут нарушаться?
AVC>Так ведь все ошибки делаются "ненарочно", и ошибки в соблюдении конвенций — в том числе.
AVC>У меня же конвенции с детства ассоциируются с Паниковским и прочими детьми лейтенанта Шмидта.

AVC>А может быть, Си++программисты просто несколько самоуверены, и каждый из них думает: "Я-то уж не ошибусь!"?

AVC>В Обероне можно выделить две принципиальные вещи:
AVC>1) надежность (особо удалась Вирту защита памяти; надежность — это очень приятное чувство!);
AVC>2) простота.
AVC>По поводу последнего можно распространяться долго.
AVC>Здесь не только простота языка.
AVC>Что освоить COM, толковые люди (которые потом пишут об этом книги) тратят по полгода; при этом, по их словам, ощущают туман в своей голове.

AVC>А на Обероне Вы просто пишете свой модуль.
AVC>Возьмем самое малое. Разве невидимо и безошибочно работающий garbage collector не лучше, чем AddRef() и Release()?
AVC>Разве это не аргумент?
AVC>Неужели простота ничего не стоит? А затраты на изучение слишком сложных программных продуктов, а потерянные годы жизни (все лучшие годы!

), а тот ужасный (и потенциально опасный!) код, который громоздят те несчастные, которые так и не разобрались до конца во всех тонкостях очередного модного и, как всегда, чрезмерно сложного средства?

Все, что здесь написано, Алексей, увы, горькая правда. Я бы добавил только, что, имхо, COM -- это как раз пример неудачной технологии, раскрученной благодоря монополизму и упертости Microsoft. В то же время Oberon производит впечатление стройной и красивой (может потому и компактной) системы. Но, нераскрученной и уж точно не мейнстримовой. Се ля ви. "Все мы жертвы цепи нелепых случайностей" ((С) К.Вонегут).

Тем не менее меня интересует другая сторона медали. И ты, и я уже сошлись на мнении, что C++ сложный, тяжелый и небезопасный язык. Но что дальше? Есть ведь куча C/C++ кода от которого нельзя просто так отказаться, бросить все и уйти в Java/C#/Oberon. Более того, есть области, про которые говорил Дмитрий, в которых мейнстримовые сейчас Java и C# по своей ресурсоемкости и производительности просто C++ не конкуренты. Да и мне, в свое время, довелось поработать на платформе, где кроме убогого C++ компилятора вообще никаких других языков не было. Вот здесь и начинаешь задаваться вопросом, так как же программировать на C++, чтобы было и просто, и безопасно? Сложный вопрос, однако.

Честно говоря, я не знаю, возможен ли на него однозначный ответ. Более того, я склоняюсь к мысли, что вряд ли. Слишком уж много разных направлений C++ накрыл. Но, может быть, можно делать какие-то удобные framework-и для отдельных прикладных направлений и достигать с помощью таких framework-ов надежности и простоты, которой так не хватает? Путь хотя бы в рамках одной компании и одного семейства продуктов.

У меня есть опыт создания и работы с таким framework-ом, SObjectizer-ом, о котором я тебе говорил. Благодоря некоторым идеологическим и техническим решениям простота и надежность там достигаются. Вряд ли ее уровень можно сравнить с уровнем Oberon, но все же. Например, в SObjectizer все сообщения являются динамически-созданными объектами, но об их уничтожении программисту совершенно не нужно заботиться -- это делает run-time. Так же благодоря взаимодействию на основе сообщений достигается модульность (можно даже сказать компонентность). А возможность собирать конкретные программые комплексы из отдельных dll-кирпичиков для меня уже так необходима, что я даже не знаю, как без нее обходиться.

Довольно комфортные условия для программирования на C++ предлагает Qt от www.trolltech.com. Там настолько продуманная и удобная схема владения объектами, что очень редко приходится писать delete, в основном, только new

. Может быть как раз эта продуманность и удобство Qt определила успешность проекта KDE? А так же компонентную модель, которая есть в KDE.

Собственно резюмировать хочется тем, что в рамках конкретных технологий и фреймворков в C++ можно обеспечить себе вополне безопасную, надежную и комфортную работу в C++. Причем, удачные фреймворки (типа Qt) имеют достаточно серьезный запас прочности для того, чтобы "случайно залетевший дятел не вызвал гибель цивилизации" (т.е. чтобы новичек неумелыми действиями не навредил остальному коду). Так что будущее C++ определяется, имхо, не столько развитием самого языка, сколько технологиями вокруг C++ (короля играет свита, если проще

... << RSDN@Home 1.1.4 beta 7 rev. 447>>

Здравствуйте, eao197, Вы писали:

E>Почитал тут вашу переписку с CrystaX, получил большое удовольствие. Не часто в сравнениях каких-либо языков здесь на RSDN я видел такое спокойное и конструктивное изложение своих взглядов и позиций. Мой респект вам, Алексей и Дмитрий.

Взаимно!

E>Все, что здесь написано, Алексей, увы, горькая правда. Я бы добавил только, что, имхо, COM -- это как раз пример неудачной технологии, раскрученной благодоря монополизму и упертости Microsoft. В то же время Oberon производит впечатление стройной и красивой (может потому и компактной) системы. Но, нераскрученной и уж точно не мейнстримовой. Се ля ви. "Все мы жертвы цепи нелепых случайностей" ((С) К.Вонегут).

E>Тем не менее меня интересует другая сторона медали. И ты, и я уже сошлись на мнении, что C++ сложный, тяжелый и небезопасный язык. Но что дальше? Есть ведь куча C/C++ кода от которого нельзя просто так отказаться, бросить все и уйти в Java/C#/Oberon. Более того, есть области, про которые говорил Дмитрий, в которых мейнстримовые сейчас Java и C# по своей ресурсоемкости и производительности просто C++ не конкуренты. Да и мне, в свое время, довелось поработать на платформе, где кроме убогого C++ компилятора вообще никаких других языков не было. Вот здесь и начинаешь задаваться вопросом, так как же программировать на C++, чтобы было и просто, и безопасно? Сложный вопрос, однако.

E>Честно говоря, я не знаю, возможен ли на него однозначный ответ. Более того, я склоняюсь к мысли, что вряд ли. Слишком уж много разных направлений C++ накрыл. Но, может быть, можно делать какие-то удобные framework-и для отдельных прикладных направлений и достигать с помощью таких framework-ов надежности и простоты, которой так не хватает? Путь хотя бы в рамках одной компании и одного семейства продуктов.

E>У меня есть опыт создания и работы с таким framework-ом, SObjectizer-ом, о котором я тебе говорил. Благодоря некоторым идеологическим и техническим решениям простота и надежность там достигаются. Вряд ли ее уровень можно сравнить с уровнем Oberon, но все же. Например, в SObjectizer все сообщения являются динамически-созданными объектами, но об их уничтожении программисту совершенно не нужно заботиться -- это делает run-time. Так же благодоря взаимодействию на основе сообщений достигается модульность (можно даже сказать компонентность). А возможность собирать конкретные программые комплексы из отдельных dll-кирпичиков для меня уже так необходима, что я даже не знаю, как без нее обходиться.

E>Довольно комфортные условия для программирования на C++ предлагает Qt от www.trolltech.com. Там настолько продуманная и удобная схема владения объектами, что очень редко приходится писать delete, в основном, только new

. Может быть как раз эта продуманность и удобство Qt определила успешность проекта KDE? А так же компонентную модель, которая есть в KDE.

E>Собственно резюмировать хочется тем, что в рамках конкретных технологий и фреймворков в C++ можно обеспечить себе вополне безопасную, надежную и комфортную работу в C++. Причем, удачные фреймворки (типа Qt) имеют достаточно серьезный запас прочности для того, чтобы "случайно залетевший дятел не вызвал гибель цивилизации" (т.е. чтобы новичек неумелыми действиями не навредил остальному коду). Так что будущее C++ определяется, имхо, не столько развитием самого языка, сколько технологиями вокруг C++ (короля играет свита, если проще

).

Достаточно неожиданно — языковой флейм оказался для меня весьма полезным.

Я вижу, пусть скромный, но все же результат: мы понимаем друг друга (хотя бы отчасти).
ИМХО, это даже важнее, чем соглашаться друг с другом. (Соглашаться можно и не понимая.)
Наверное, мне стоит взять небольшую паузу, и хорошо обдумать аргументы — как твои, так и Дмитрия.
У меня есть опасение, что в некоторых "пунктах разногласия" я достиг предела своей сегодняшней компетентности.
Несмотря на то, что я писал самые разные программы (большие и маленькие), работал в одиночку и в команде, у меня есть один значительный пробел в "жизненных университетах".
Я никогда не писал больших библиотек.

Вместе с тем, глядя на то, как устроены многие современные языки и библиотеки, сколько ошибок делается как при их проектировании, так и при использовании, и какие усилия требуются для освоения ряда современных программных (особенно — компонентных) технологий, я пришел к радикальным выводам (может быть — слишком радикальным

).
В это время я "наткнулся" на Оберон и был именно поражен (твое слово!

) его простотой, надежностью и красотой замысла.
Во основном этим и объясняется моя позиция.
Мне казалось, что на форумах RSDN мои оппоненты просто не видят идеи, которую Вирт вложил в Оберон.
Но, как оказалось, есть оппоненты (и ты, и Дмитрий, и еще ряд уважаемых мною "противников"), которые видят эту идею, но какие-то (возможно, недостаточно оцененные мной) факторы приводят их к другим выводам, не совпадающим с моими.
Короче, мне есть над чем подумать. Поэтому я возьму небольшую паузу.
Тем более, что есть еще ряд вопросов, уже не связанных с языком, которые мне бы хотелось обсудить на данном форуме.
(Это я снова о понятии ошибки и анализе всех стадий, на которых можно внести ошибку: анализе проблемной области, выборе модели, выборе типов данных и т.д. и т.п. Хочу в ближайшее время собрать мысли "в кучку" "родить" небольшой пост на эту тему.

)

Здравствуйте, AVC, Вы писали:

AVC>Достаточно неожиданно — языковой флейм оказался для меня весьма полезным.

AVC>Я вижу, пусть скромный, но все же результат: мы понимаем друг друга (хотя бы отчасти).
AVC>ИМХО, это даже важнее, чем соглашаться друг с другом. (Соглашаться можно и не понимая.)

Возможно, именно это и есть самый главный результат.

AVC>Наверное, мне стоит взять небольшую паузу, и хорошо обдумать аргументы — как твои, так и Дмитрия.
AVC>У меня есть опасение, что в некоторых "пунктах разногласия" я достиг предела своей сегодняшней компетентности.
AVC>Несмотря на то, что я писал самые разные программы (большие и маленькие), работал в одиночку и в команде, у меня есть один значительный пробел в "жизненных университетах".
AVC>Я никогда не писал больших библиотек.

AVC>Вместе с тем, глядя на то, как устроены многие современные языки и библиотеки, сколько ошибок делается как при их проектировании, так и при использовании, и какие усилия требуются для освоения ряда современных программных (особенно — компонентных) технологий, я пришел к радикальным выводам (может быть — слишком радикальным

).
AVC>В это время я "наткнулся" на Оберон и был именно поражен (твое слово!

) его простотой, надежностью и красотой замысла.
AVC>Во основном этим и объясняется моя позиция.
AVC>Мне казалось, что на форумах RSDN мои оппоненты просто не видят идеи, которую Вирт вложил в Оберон.
AVC>Но, как оказалось, есть оппоненты (и ты, и Дмитрий, и еще ряд уважаемых мною "противников"), которые видят эту идею, но какие-то (возможно, недостаточно оцененные мной) факторы приводят их к другим выводам, не совпадающим с моими.
AVC>Короче, мне есть над чем подумать. Поэтому я возьму небольшую паузу.

Будем ждать. Со своей стороны хочу сказать, что спокойных и уравновешенных оппонентов на форумах RSDN на самом деле не так уж и много. Но они все же есть (пусть и в небольших количествах), что не может не радовать. Вспоминается фраза, уже не помню откуда: "Вы мой лучший враг!"

AVC>Тем более, что есть еще ряд вопросов, уже не связанных с языком, которые мне бы хотелось обсудить на данном форуме.
AVC>(Это я снова о понятии ошибки и анализе всех стадий, на которых можно внести ошибку: анализе проблемной области, выборе модели, выборе типов данных и т.д. и т.п. Хочу в ближайшее время собрать мысли "в кучку" "родить" небольшой пост на эту тему.

)

... << RSDN@Home 1.1.4 beta 7 rev. 447>>

Здравствуйте, CrystaX, Вы писали:

CX>Вы знаете, определенная доля самоуверенности во мне, конечно же, есть. И конечно же, соблюдение конвенций не спасает на 100% от ошибок. Но на 95% спасает, а это уже приемлемый уровень. Ведь у меня две альтернативы:
CX>1. Полностью положиться на безопасный язык программирования и не задумываться об этом вообще.
CX>2. Создать безопасность самому, следую конвенциям, и имея возможность, в случае необходимости, в каком-то конкретном куске коде переделать его, не нарушая безопасность "снаружи" (для пользователей этого кода), но убрав лишние проверки и прочие прелести безопасного кода внутри, достигнув тем самым значительного улучшения производительности.

CX>Я выбираю второй вариант.

А я оба.

CX> Более того, слова о достижении более высокой производительности — это не просто слова,

Ага. Это пустые слова.

Думаю что большинство программистов даже не подазревает сколько пустых циклов выполняют их программы. И вина в этом лежит отнюдь не на языках и компиляторах.

... << RSDN@Home 1.1.4 beta 7 rev. 466>>

Здравствуйте, VladD2, Вы писали:

VD>Здравствуйте, CrystaX, Вы писали:

CX>>Вы знаете, определенная доля самоуверенности во мне, конечно же, есть. И конечно же, соблюдение конвенций не спасает на 100% от ошибок. Но на 95% спасает, а это уже приемлемый уровень. Ведь у меня две альтернативы:
CX>>1. Полностью положиться на безопасный язык программирования и не задумываться об этом вообще.
CX>>2. Создать безопасность самому, следую конвенциям, и имея возможность, в случае необходимости, в каком-то конкретном куске коде переделать его, не нарушая безопасность "снаружи" (для пользователей этого кода), но убрав лишние проверки и прочие прелести безопасного кода внутри, достигнув тем самым значительного улучшения производительности.

CX>>Я выбираю второй вариант.

VD>А я оба.

С чем тебя и поздравляю. Твой выбор.

CX>> Более того, слова о достижении более высокой производительности — это не просто слова,

VD>Ага. Это пустые слова.

Без комментариев.

VD>Думаю что большинство программистов даже не подазревает сколько пустых циклов выполняют их программы. И вина в этом лежит отнюдь не на языках и компиляторах.

Да что там, наверняка даже эти самые программисты не подозревают, отчего программы вообще работают. Наверняка среди программистов бытует мнение, что внутри этих железяк (компьютеров) злой дух сидит — называется странным демоническим именем Процессор! И что этот Процессор вытворяет с бедными программами — описанию не поддается! Он их выполняет!

Пришел Влад. С этого момента спокойная дискуссия превратится в яростный флейм с блеском фанатизма в глазах. Но я устраняюсь — не люблю фанатиков, пусть даже и неглупых.

... << RSDN@Home 1.1.4 beta 7 rev. 447>>

Здравствуйте, CrystaX, Вы писали:

CX>Пришел Влад. С этого момента спокойная дискуссия превратится в яростный флейм с блеском фанатизма в глазах. Но я устраняюсь — не люблю фанатиков, пусть даже и неглупых.

Не... спокойный безосновательный треп заканчивается.

Тут уже была куча тестов и как-то не вдино, чтобы они показали какое-то серьезное приемущество в скорости неуправляемого кода. Сдается мне, что все таки тормоза в приложениях в основном являются следствием плохой прокладки... между креслом и монитором. И если эта прокладка начнет тратить время не только на вылов глюков, а еще на поиск более производительных алгоритмов и оптимизацию производительности, то толку будет больше. И управляемый код ту ей очень поможет.

... << RSDN@Home 1.1.4 beta 7 rev. 466>>

Здравствуйте, CrystaX, Вы писали:

CX>>>Так что скажете? Что есть в Обероне такого, что может сильно облегчить мне жизнь как программисту (или даже заставит по-новому взглянуть на суть программирования вообще)?

AVC>>Подумаю, "поскриплю" мозгами.

CX>Ок, буду ждать.

А я буду думать.

Но пока я думаю, все же отреагирую на некоторые Ваши реплики.

CX>>>Алексей, согласитесь все же, что все это не имеет ни малейшего отношения к языку. Быть может, для Вас заданный мною вопрос и прозвучал наивно, но для меня предыдущий текст звучит ничуть не менее наивно.

AVC>>Может быть.

AVC>>А, может быть, и нет.
AVC>>Между Обероном-языком и Обероном-средой (и Обероном-системой) есть связь.

CX>Но мы ведь говорим об Обероне-языке, а не об Обероне-системе?

AVC>>Ничего подобного я не видел в системах, написанных на Си.

CX>Хмм... А как же Unix? Типичнейшая C-среда. Да, конечно, если говорить о GUI и прочих рюшечках, то этого нет. Но мне, честно говоря, GUI абсолютно не важен. Мне очень нравиться высказывание Денниса Ритчи по этому поводу: "UNIX — это очень простая и гибкая операционная система. Правда, для того, чтобы понять и принять эту простоту, требуется гений или, как минимум, программист"

К UNIX, как среде программирования, я отношусь очень хорошо.
Скажу, хотя бы, что каждый день пользуюсь инструментами, разработанными в этой программистской среде: редактирую программы в vi, использую в работе yacc, lex и т.д. И совсем не по причине фанатизма или эксцентричности. Просто для моих задач (создание систем программирования) эта среда подходит идеально.
Поэтому, когда я говорю о достоинствах обероновской среды, мне есть с чем сравнивать.
Некоторые (лучшие) особенности UNIX свойственны также и обероновской среде.
Например, Оберон-система так же строится из маленьких кусочков, хорошо выполняющих свою задачу и способных интегрироваться для решения больших задач. Только для интеграции используется единое адресное пространство (Вы можете обмениваться данными с нужным модулем напрямую), а не pipelines, как в UNIX. (ИМХО, многие особенности UNIX являются следствием того, что оперативная память в используемых Томпсоном и Ритчи компьютерах была слишком мала.)
И высказывание Ритчи вполне подходит не только к UNIX, но и к Оберону.
Возможно (трудно детально разобраться в самом себе

), что причины моего хорошего отношения к UNIX и Оберону одни и те же (или, по крайней мере, сходные).
Но в обероновской среде действительно есть некоторые "фичи", которых я не видел в системах, написанных на Си.

CX>Вообще же, на сравнение сред предлагаю не скатываться, т.к. в данном случае гораздо больший вес имеют личные предпочтения.

В Ваших словах есть резон.
Но когда я говорю о среде программирования, я имею в виду не "навороты" какого-то отдельно взятого IDE.
Вы сами дали мне хороший пример среды програмирования: UNIX.
Одна из книг Кернигана и Пайка так и называется: "UNIX — универсальная среда программирования" (the UNIX programming enviroment).
Свойства UNIX не сводятся к свойсвам отдельных программ. Здесь важен именно системный эффект.
Поэтому я и не могу согласиться с тем, что не надо апеллировать к свойствам среды.
Язык Оберон был создан для и в процессе создания операционной системы Оберон.
И поэтому был спроектирован так, чтобы обеспечивать требуемые системные качества и тот системный эффект, что роднит его с UNIX.
Почему же я должен об этом молчать?

Вот Си++ был создан для того, чтобы сохранить высокую эффективность кода при использовании объектно-ориентированного программирования.
Вы же не "стесняетесь" приводить высокую эффективность кода Си++ в качестве довода.

Но у всего есть своя цена, свои издержки.
Си++ был изначально рассчитан именно на создание отдельных (stand-alone) программ, поэтому и не имеет того системного эффекта, который есть у Оберона.

AVC>>Размер компилятора убеждает больше.

CX>Честно говоря, меня не убеждает. Я, например, и на ассемблерах, бывало, писал — так там размер транслятора и того меньше. И что? О чем это говорит? Да ровным счетом ни о чем.

Не могу здесь с Вами согласиться.
Язык высокого уровня — это не просто ассемблер.
Он предоставляет дополнительные возможности, которых ассемблер не дает.
Поэтому имеет смысл сравнивать только компиляторы языков сходного уровня функциональности.
В Обероне значение дроби функциональность/сложность превосходит аналогичное значение для большинства языков программирования (может, даже для всех; но этого я утверждать не стану, т.к., разумеется, не знаю всех языков).
Чтобы показать, почему я не принимаю Ваш аргумент, доведу его до абсурда и замечу, что если бы Вы писали прямо в машинных кодах (моя мама когда-то писала

), то Вам бы и ассемблер не понадобился.

AVC>>Но представьте себе, что весь код (а не отдельный небольшой фрагмент) такой!
AVC>>Читателю программы, ИМХО, будет легче сразу повеситься!

CX>Здесь мы опять переходим на обсуждение некого гипотетического "читателя программы", который к тому же (гипотетически!) недостаточно грамотен, чтобы разобраться в коде, даже предварительно почитав документ "Project design"! Однако, мне как-то неинтересно обсуждать этого самого читателя. Прямо как у Стругацких: "Ах, дурак, какой ты умный! Какой ты хороший, дурак! Не беспокойся ни о чем, дурак!"

Я исхожу из того, что чтение программ зачастую является более трудной задачей, чем их написание.

При чтении иных программ мозгам прямо-таки приходится становиться раком.

Поэтому "узкое место" я вижу именно в читабельности программ.
Я частенько сталкиваюсь с ситуациями, когда программы не модифицируются, а заново переписываются, настолько трудным кажется программисту труд чтения чужих программ.

Здравствуйте, CrystaX, Вы писали:

AVC>>Между Обероном-языком и Обероном-средой (и Обероном-системой) есть связь.
CX>Но мы ведь говорим об Обероне-языке, а не об Обероне-системе?

Без знакомства с Оберон-системой Оберон как язык не производит должного впечатления. Так же, как и Smalltalk, Java или C#. Представьте любой из этих языков как средство разработки на голом Win(Unix)Api.

Здравствуйте, AVC, Вы писали:

CX>>Хмм... А как же Unix? Типичнейшая C-среда. Да, конечно, если говорить о GUI и прочих рюшечках, то этого нет. Но мне, честно говоря, GUI абсолютно не важен. Мне очень нравиться высказывание Денниса Ритчи по этому поводу: "UNIX — это очень простая и гибкая операционная система. Правда, для того, чтобы понять и принять эту простоту, требуется гений или, как минимум, программист"

AVC>К UNIX, как среде программирования, я отношусь очень хорошо.
AVC>Скажу, хотя бы, что каждый день пользуюсь инструментами, разработанными в этой программистской среде: редактирую программы в vi, использую в работе yacc, lex и т.д. И совсем не по причине фанатизма или эксцентричности. Просто для моих задач (создание систем программирования) эта среда подходит идеально.
AVC>Поэтому, когда я говорю о достоинствах обероновской среды, мне есть с чем сравнивать.
AVC>Некоторые (лучшие) особенности UNIX свойственны также и обероновской среде.
AVC>Например, Оберон-система так же строится из маленьких кусочков, хорошо выполняющих свою задачу и способных интегрироваться для решения больших задач. Только для интеграции используется единое адресное пространство (Вы можете обмениваться данными с нужным модулем напрямую), а не pipelines, как в UNIX. (ИМХО, многие особенности UNIX являются следствием того, что оперативная память в используемых Томпсоном и Ритчи компьютерах была слишком мала.)
AVC>И высказывание Ритчи вполне подходит не только к UNIX, но и к Оберону.
AVC>Возможно (трудно детально разобраться в самом себе

), что причины моего хорошего отношения к UNIX и Оберону одни и те же (или, по крайней мере, сходные).
AVC>Но в обероновской среде действительно есть некоторые "фичи", которых я не видел в системах, написанных на Си.

Видимо, я просто не замечаю этих фич. "Все есть документ"? Не могу сказать, что эта фича мне нравится. Что еще?

CX>>Вообще же, на сравнение сред предлагаю не скатываться, т.к. в данном случае гораздо больший вес имеют личные предпочтения.

AVC>В Ваших словах есть резон.
AVC>Но когда я говорю о среде программирования, я имею в виду не "навороты" какого-то отдельно взятого IDE.
AVC>Вы сами дали мне хороший пример среды програмирования: UNIX.
AVC>Одна из книг Кернигана и Пайка так и называется: "UNIX — универсальная среда программирования" (the UNIX programming enviroment).

Именно с этой книги началось мое знакомство с UNIX.

AVC>Свойства UNIX не сводятся к свойсвам отдельных программ. Здесь важен именно системный эффект.
AVC>Поэтому я и не могу согласиться с тем, что не надо апеллировать к свойствам среды.
AVC>Язык Оберон был создан для и в процессе создания операционной системы Оберон.
AVC>И поэтому был спроектирован так, чтобы обеспечивать требуемые системные качества и тот системный эффект, что роднит его с UNIX.
AVC>Почему же я должен об этом молчать?

Видимо, мы говорим о разных вещах. Насколько я понял, мы говорим о языках. Если бы я приводил преимущества UNIX как среды, но при этом не хотел бы ничего слышать об Оберон-среде (тот же Blackbox, например), очевидно, я был бы необъективен. Подробнее см. ниже.

AVC>Вот Си++ был создан для того, чтобы сохранить высокую эффективность кода при использовании объектно-ориентированного программирования.
AVC>Вы же не "стесняетесь" приводить высокую эффективность кода Си++ в качестве довода.

AVC>Но у всего есть своя цена, свои издержки.
AVC>Си++ был изначально рассчитан именно на создание отдельных (stand-alone) программ, поэтому и не имеет того системного эффекта, который есть у Оберона.

Именно так. C++ (как, впрочем, и C) как язык системного эффекта не имеет. Он начинает проявляться только при использовании определенных технологий и в определенных средах (что, впрочем, все равно отношения к языку не имеет).
В случае Оберона же (как языка) единственное, что в нем относится к среде, это модульность. Ок, я согласен рассматривать эту его возможность как преимущество (о котором, впрочем, тоже можно спорить). Но говорить об IDE и о том, что в ней можно линки вставлять — не могу воспринять это как преимущество языка.

AVC>Не могу здесь с Вами согласиться.
AVC>Язык высокого уровня — это не просто ассемблер.
AVC>Он предоставляет дополнительные возможности, которых ассемблер не дает.
AVC>Поэтому имеет смысл сравнивать только компиляторы языков сходного уровня функциональности.
AVC>В Обероне значение дроби функциональность/сложность превосходит аналогичное значение для большинства языков программирования (может, даже для всех; но этого я утверждать не стану, т.к., разумеется, не знаю всех языков).
AVC>Чтобы показать, почему я не принимаю Ваш аргумент, доведу его до абсурда и замечу, что если бы Вы писали прямо в машинных кодах (моя мама когда-то писала

), то Вам бы и ассемблер не понадобился.

Совершенно верно! И тогда размер транслятора был бы 0! Но было бы от этого удобнее? Очевидно, что нет. Это я к тому, что размер компилятора не является доводом вообще.

CX>>Здесь мы опять переходим на обсуждение некого гипотетического "читателя программы", который к тому же (гипотетически!) недостаточно грамотен, чтобы разобраться в коде, даже предварительно почитав документ "Project design"! Однако, мне как-то неинтересно обсуждать этого самого читателя. Прямо как у Стругацких: "Ах, дурак, какой ты умный! Какой ты хороший, дурак! Не беспокойся ни о чем, дурак!"

AVC>Я исхожу из того, что чтение программ зачастую является более трудной задачей, чем их написание.

AVC>При чтении иных программ мозгам прямо-таки приходится становиться раком.

AVC>Поэтому "узкое место" я вижу именно в читабельности программ.
AVC>Я частенько сталкиваюсь с ситуациями, когда программы не модифицируются, а заново переписываются, настолько трудным кажется программисту труд чтения чужих программ.

Это только для неподготовленного (и, что греха таить, недисциплинированного) программиста. У меня был опыт практически полного переписывания кода, но каждый раз это случалось не из-за трудностей в понимании, а из-за необходимости изменения архитектуры.

... << RSDN@Home 1.1.4 beta 7 rev. 447>>

	От:	Павел Кузнецов
	Дата:	29.06.05 03:13
	Оценка:

От:	eao197	http://eao197.blogspot.com
Дата:	29.06.05 05:35
Оценка:

От:	eao197	http://eao197.blogspot.com
Дата:	29.06.05 05:35
Оценка:

От:	Сергей Губанов	http://sergey-gubanov.livejournal.com/
Дата:	29.06.05 07:45
Оценка:

От:	Сергей Губанов	http://sergey-gubanov.livejournal.com/
Дата:	29.06.05 07:46
Оценка:

От:	CrystaX	https://crystax.me/
Дата:	01.07.05 22:49
Оценка:	52 (3) +2

От:	VladD2	www.nemerle.org
Дата:	03.07.05 13:38
Оценка:

	От:	Трурль
	Дата:	04.07.05 08:07
	Оценка:	+1