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

ГВ> Не согласен. В данном случае при проектировании функции диспетчеризации мы используем знание о наборе поступающих сообщений. Если источник сообщений добавит ещё одно-два, то придётся модифицировать клиентский код, который придётся разыскивать через search и т.п.

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

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

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

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

ГВ>>Не надо путать C и С++. Аналогичное решение на C++ выглядело бы как класс с чисто виртуальными методами. В общем-то, это надёжнее, поскольку была бы возможна группировка методов по целевому назначению и была бы гарантия того, что реализующий объект реализует _все_ методы некоторой группы. По крайней мере — он о них знает.

AVC>Предположим, Вам предложили переписать Windows заново на Си++.
AVC>Сколько чисто виртуальных методов Вы поместите в абстрактный класс "Окно"?
AVC>Примите во внимание, что, решив впоследствии добавить еще один виртуальный метод, Вы можете столкнуться с неразрешимой проблемой.

Алексей, Геннадий, здесь вы затронули такую интересную тему, как "расширяемость", "совместимость" и "прозрачность". Буквально совсем недавно она уже всплывала в Re[25]: Функциональные типы (параллельная ветка)

Автор: gbear
Дата: 30.06.05

и Re[10]: Формат конфигов

Автор: Геннадий Васильев
Дата: 29.06.05

(в последнем случае мы с тобой, Геннадий, достигли взаимопонимания).

Я это к тому, что в последнее время я пришел к мнению, что строгие интерфейсы и четко определенными сигнатурами гораздо менее гибки и расширяемы (к этому же можно отнести и виртуальные методы), чем message-based схемы. Например, был у меня метод:

ret_code_t
wait_event( event_t *& evt );

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

ret_code_t
wait_event( event_t *& evt, unsigned int timeout );

Вроде ничего сложного, такие модификации, к счастью, выявляются в процессе прототипирования. Но уже в процессе эксплуатации появляются новые требования:
— ожидать не указанное число миллисекунд, а до указанного абсолютного времени. Либо, что еще хуже, ждать либо указанного абсолютного времени, либо указанное количество миллисекунд (что быстрее произойдет);
— задавать фильтры событий, например, автоматом отбраковывать события, которые нас не интересуют или не разрешены к обработке в данном состоянии. Самое важное, что фильтрация должна осуществляться внутри wait_event, чтобы не пересчитывать тайм-ауты после возврата из wait_event.

Уже настройка под такие требования потребует появления нескольких методов wait_event с разными сигнатурами. Но развитие wait_event, его использование и сопровождение всего, что с wait_event связано, могло бы быть проще, если бы wait_event изначально имел вид:

ret_code_t
wait_event( event_t *& evt, wait_event_params_t & params );

поскольку структура wait_event_params_t могла бы расширятся гораздо проще, чем сигнатура wait_event. Но и возможности расширения wait_event_params_t так же могут оказаться ограниченными. Особенно, если wait_event_params_t будет представлена в виде интерфейса и использовать нужно будет его конкретные реализации. Поэтому еще более гибким подходом, имхо, является такой:

class    wait_event_traits_t
    {
    public :
        // Возвращает уникальный идентификатор свойства.
        virtual traits_id_t
        id() const = 0;
        
        // Возвращает true, если свойство нельзя проигнорировать.
        virtual bool
        must_understand() const = 0;
        ...
    };

ret_code_t
wait_event( event_t *& evt, const wait_event_traits_map_t & traits );

где wait_event_traits_map_t -- это некий объект, который позволяет получать указатели на wait_event_traits_t по traits_id (в простейшем случае обычный std::map).

Применяя метод wait_event(evt,traits) мы получаем единую точку входа в сервис с расширяемой функциональностью.

Имхо, еще более удобным такой подход становится при создании распределенных приложений (а может быть и компонентных). Ведь тогда заранее точно не известно, какой объем функциональности поддерживается удаленной стороной (компонентом). И запрос сервиса путем передачи объекта-сообщения (а не вызова удаленного метода с жесткой сигнатурой) становится более простым делом в плане расширяемости и поддержки совместимости с предыдущими версиями.

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

ГВ>>>Однако, если сугубо формально, то анализ типа сообщения всё равно остаётся. Тем-то, кстати, и хорош LSP, что его нарушение можно определить по сугубо формальным признакам.
Т>>Как раз по сугубо формальным признакам нарушений не видно.
ГВ>Ну, здравствуйте! А цепочка IS — это что?

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

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

Т>А что Вы скажете насчет PL/1? Вполне себе традиционный язык.

А разве речь шла о нем в данном топике? Давайте не будем уводить беседу в другое русло. Я не утверждаю и никогда не утверждал, что C++ лучше и круче всех остальных языков (ну ладно, было мое высказывание о "других языках", но я уже поправился здесь

Автор: CrystaX
Дата: 08.07.05

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

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

CX>На самом деле основное отличие C++ от его главных оппонентов в этой ветке (Оберон, C#, Java) в плане безопасности заключается не в том, что на нем нельзя писать безопасные программы (множество примеров говорит о том, что можно), а в том, что он не мешает писать небезопасные программы.

Если цель — написать небезопасноу программу, ни один язык не может мне помешать в ее достижении.

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

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

CX>>На самом деле основное отличие C++ от его главных оппонентов в этой ветке (Оберон, C#, Java) в плане безопасности заключается не в том, что на нем нельзя писать безопасные программы (множество примеров говорит о том, что можно), а в том, что он не мешает писать небезопасные программы.

Т>Если цель — написать небезопасноу программу, ни один язык не может мне помешать в ее достижении.
+1

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

Кодт wrote:
> R>>Реально будет использовано меньше. Длинные произведения делаются
> R>>inline-функциями. Поэтому небольшая автоматизация изврата — и
> R>>генерируются только используемые размерности. Хотя, конечно, получится
> R>>многовато, но искусство требует жертв. Благо, не человеческих, и даже не
> R>>усилий.
>
> Искусство требует нечеловеческих жертв!
> ((с) Ленин после прослушивания Лунной Сонаты)
>
> ГВ>Ну-ксь, поверим гармонию алгеброй. Для 10^9 комбинаций, даже если на
> генерацию уходит 1 ms (оптимистично), то получим... 10^6 секунд на один
> проход генерации... Это... что-то около 11 дней на заход. Объём
> выходного файла при 50 символах на экземпляр ~50 ГБ.
>
> ГВ>Даже если срезать три порядка — всё равно невесело. А если ещё
> тестирование...
>
> Причём самое обидное, что из всего этого многообразия потребуются ну
> сто, ну двести разных сочетаний. Правда, забодаешься вручную их выявлять...

Так про то и речь. При объявлении переменной пишется ссылка на процедуру
— генератор (не знаю, как это принято говорить.. Вроде PHP-островков в
HTML, только Pascal в Pascal), которая и проверяет существование нужного
типа (вроде grep) и по необходимости дописывает в файл программы
объявление, а в модуль типов — полное описание типа. Я имел в виду
такую генерацию. И будет 200 типов * 1000 байт = 200 кБ, за несколько
секунд. у меня генерируется 10*4*2000 в некотором месте (используется
меньше, но оптимизировать лень) — это не так долго
генерируется/компилируется, кроме того пересоздание/перекомпиляция редка.

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

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

Все правильно: "Каждый выбирает для себя..." (из песни)
Мне показалось (может, и ошибочно), что ты немного разочарован результатом — каждый остался "при своем".
Но главное назначение дискуссии — расширить представления участников о предмете.
Я узнал для себя много нового, меня даже понравились некоторые примеры кода на Си++.
(Просто мне немного трудно их "принять". Наверное, это дело практики, времени, привычки. Буду понемногу разбираться в новых возможностях Си++.)
Поэтому я, в принципе, удовлетворен.
Дискуссии (если они касаются не совсем уж легких предметов) всегда развиваются по спирали и возвращаются на прежнее место, но уже на другом уровне.
Надеюсь, что мы обсудим и неязыковые причины ненадежности программ. Мне кажется, что в основном они связаны с трудностями моделирования реального мира. А это тоже очень интересная тема.

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

AVC>Все правильно: "Каждый выбирает для себя..." (из песни)
AVC>Мне показалось (может, и ошибочно), что ты немного разочарован результатом — каждый остался "при своем".

Нет, не разочарован. Честно говоря, вообще не припоминаю случаев, когда в споре вдруг кому-то "неожиданно открылась истина, ослепляя своим блеском".
Цель не в этом. Цель в другом — дать пищу для размышлений и, возможно, подтолкнуть к действию. Я вот, например, решил на Оберон посмотреть более внимательно, а также лиспом на досуге заняться (тем же emacs-ом для начала) — чем не результат?

AVC>Но главное назначение дискуссии — расширить представления участников о предмете.
AVC>Я узнал для себя много нового, меня даже понравились некоторые примеры кода на Си++.

+1

AVC>(Просто мне немного трудно их "принять". Наверное, это дело практики, времени, привычки. Буду понемногу разбираться в новых возможностях Си++.)
AVC>Поэтому я, в принципе, удовлетворен.

+1

AVC>Дискуссии (если они касаются не совсем уж легких предметов) всегда развиваются по спирали и возвращаются на прежнее место, но уже на другом уровне.
AVC>Надеюсь, что мы обсудим и неязыковые причины ненадежности программ. Мне кажется, что в основном они связаны с трудностями моделирования реального мира. А это тоже очень интересная тема.

Да, вот это хотелось бы обсудить.

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

CX>Я вот, например, решил на Оберон посмотреть более внимательно

Не сочтите за коммерческую рекламу, но в июльском номере журнала "Мир ПК" на компакт диске в разделе "Студия программирования" обещают поместить соответсвующие материалы (BlackBox). Это я на тот случай сообщаю, если Вы вдруг по модему чего из интернета скачивать надумаете, так лучше сначала там посмотреть.

Здравствуйте, Сергей Губанов, Вы писали:

СГ>Не сочтите за коммерческую рекламу, но в июльском номере журнала "Мир ПК" на компакт диске в разделе "Студия программирования" обещают поместить соответсвующие материалы (BlackBox). Это я на тот случай сообщаю, если Вы вдруг по модему чего из интернета скачивать надумаете, так лучше сначала там посмотреть.

Спасибо, но BlackBox и XDS я уже скачал и начал щупать. У меня, слава богу, ADSL.

Здравствуйте, Павел Кузнецов, Вы писали:

ПК>В отличие от C++ на ассемблере нет способа сделать так, чтоб компилятор ловил ошибки типизации. В C++ такие способы есть, так что аналогия некорректна.

Нет в С++ такого способа. Всегда можно взять и сделать все что душе угодно. А в том же МАСМ-е были макросы которые тоже позволяли делать безопасные конструкции. Так что аналогия более чем уместна.

VD>> Скорости это не дает. <...>

ПК>Дело-то не в скорости,

А, ну, значит я читаль не умею.

ПК> а в возможности добавлять к встроенным проверкам свои, которые контролируют далеко не только тривиальные ошибки выхода за границы массивов, но и (частично) семантическую корректность программы.

Ясно очерденая попытка подмены темы.

ПК>Ну-ка, сделай на C# такое

Автор: Павел Кузнецов
Дата: 07.07.05

...

Долго смотрел, много думал... Как бы это сказать по мягче... Не обижайся, но у тебя уже какой-то не совсем нормальный дизайн появляется. Я не понял чем обусловлены вот эти замечательные выводы:

Однако теперь видны другие недостатки: 1) в месте объявления функций-членов ICommunicator совершенно неочевидно, какие из вариантов ответов они могут возвращать; 2) в точке использования неясно, учтены ли все варианты ответов, или же по ошибке о каком-то из них забыли.

Я бы просто объявил два перечисления (C#):

enum FileExistsAnswer
{
    Cancel,
    Overwrite,
    Skip,
}

enum FolderDoesNotExistsAnswer
{
    Cancel,
    Continue,
}

Ну, и использовал бы в этом интерфейсе:

interface ICommunicator
{
  FileExistsAnswer FileExists(Path path);
  FolderDoesNotExistsAnswer FolderDoesNotExists(Path path);
  . . .
};

Код получается короче и читабельнее:

if (file_exists(path))
{
  switch (communicator.FileExists(path))
  {
        case FileExistsAnswer.Cancel:    . . .
        case FileExistsAnswer.Overwrite: . . .
        case FileExistsAnswer.Skip:      . . .
        default:                         throw UnexpectedCommunicatorAnswer();
  }
}
...

Ну, и никакого метапрограммирования тут не нужно.

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

ПК>Только не надо про R#: он совершенно не контролирует характер изменений AST

Автор: Павел Кузнецов
Дата: 16.06.05

, так что в случае его использования о какой-либо безопасности говорить (пока?) сложно...

Это твои тараканы. Меня они не интересуют. Я как то не видел подобных проблем используя R#. Бороться же с твоими домыслами у меня желания нет.

Что же до пенисометрии, то я тебе просто устану приводить примеры тог что можно сдедалать на R# и нельзя на С++ (без внешних средств).

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

ПК>>Ну-ка, сделай на C# такое

Автор: Павел Кузнецов
Дата: 07.07.05

...

VD>Долго смотрел, много думал... Как бы это сказать по мягче... Не обижайся, но у тебя уже какой-то не совсем нормальный дизайн появляется. Я не понял чем обусловлены вот эти замечательные выводы:
VD>

Однако теперь видны другие недостатки: 1) в месте объявления функций-членов ICommunicator совершенно неочевидно, какие из вариантов ответов они могут возвращать; 2) в точке использования неясно, учтены ли все варианты ответов, или же по ошибке о каком-то из них забыли.

VD>Я бы просто объявил два перечисления (C#): <...>
VD>Ну, и использовал бы в этом интерфейсе:
VD>

VD>interface ICommunicator
VD>{
VD>  FileExistsAnswer FileExists(Path path);
VD>  FolderDoesNotExistsAnswer FolderDoesNotExists(Path path);
VD>  . . .
VD>};
VD>

VD>Код получается короче и читабельнее:
VD>

VD>if (file_exists(path))
VD>{
VD>  switch (communicator.FileExists(path))
VD>  {
VD>        case FileExistsAnswer.Cancel:    . . .
VD>        case FileExistsAnswer.Overwrite: . . .
VD>        case FileExistsAnswer.Skip:      . . .
VD>        default:                         throw UnexpectedCommunicatorAnswer();
VD>  }
VD>}
VD>...
VD>

Когда будет добавлен новый вариант в FileExistsAnswer, данный код будет-по прежнему компилироваться, хотя и не учитывает этот новый вариант. Данная ошибка легко может пройти незамеченной, что и происходит на практике. Подход, продемонстрированный в примере по ссылке -- следствие двух вещей: 1) реакция на ощутимое количество исправляемых ошибок в коде, использующем communicators; 2) необходимость значительно изменить иерархию communicators, и желание сделать так, чтобы была гарантия, что в ходе изменений нигде не будут внесены ошибки с забытыми возвращаемыми значениями и т.п. Возможность ввести enum для каждой из функций рассматривалось, но было отвергнуто из-за того, что такой подход не ловит большинство реально наблюдаемых ошибок, связанных с изменениями communicators.

Подробнее:
http://rsdn.ru/Forum/Message.aspx?mid=1261795&amp;only=1

Автор: Павел Кузнецов
Дата: 07.07.05

http://rsdn.ru/Forum/Message.aspx?mid=1261535&amp;only=1

Автор: Павел Кузнецов
Дата: 07.07.05

http://rsdn.ru/Forum/Message.aspx?mid=1261749&amp;only=1

Автор: Павел Кузнецов
Дата: 07.07.05

raskin,

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

> Так про то и речь. При объявлении переменной пишется ссылка на процедуру — генератор (не знаю, как это принято говорить.. Вроде PHP-островков в HTML, только Pascal в Pascal), которая и проверяет существование нужного типа (вроде grep) и по необходимости дописывает в файл программы объявление, а в модуль типов — полное описание типа. <...>

Ну, там намного сложнее получится, т.к. это уже, фактически, неявное инстанцирование со всеми вытекающими: ODR и т.п. Собственно, если идти по этому пути, то, по крайней мере для Ады, не нужно выдумывать свои велосипеды: "Адские" расширения для автоматического инстанцирования существуют, можно взять одно из них.

Здравствуйте, Павел Кузнецов, Вы писали:

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

Это параноя уже.

ПК> Подход, продемонстрированный в примере по ссылке -- следствие двух вещей: 1) реакция на ощутимое количество исправляемых ошибок в коде, использующем communicators; 2) необходимость значительно изменить иерархию communicators, и желание сделать так, чтобы была гарантия, что в ходе изменений нигде не будут внесены ошибки с забытыми возвращаемыми значениями и т.п. Возможность ввести enum для каждой из функций рассматривалось, но было отвергнуто из-за того, что такой подход не ловит большинство реально наблюдаемых ошибок, связанных с изменениями communicators.

Чтобы поймать такую ошибку достаточно написать запрос на R#-е. А можно вообще превратить подобную фигню в диекларативную с ватоматической проверкой при инициализации.

Ну, и что самое главное в твоем случае я вообще не заметил никакого контроля. Или рассчитывается, что кто-то особо зоркий будет сидеть и сравнивать if-ы с объявлениями переменных?

ЗЫ

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

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

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

AVC>>Дмитрий, конечно, я согласен с тобой в том, что "надо делать хорошо и не надо плохо".
AVC>>Но мне вот подумалось, что твой совет мало отличается от совета Трурля не использовать Си++ вообще.

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

ЛОЛ . Навскидку — из тех, что на слуху. Dylan. Lisp. OCaml. Clean. Haskell. Возможности шаблонов С++ по сравнению с системами типов каждого из этих языков — децкий лепет. Стоит также заметить, что при большей гибкости они на порядок проще в понимании и использовании чем великий и могучий "modern C++" ((С) Александреску).

Из них, OCaml и Clean сравнимы по скорости с С++. Dylan и Lisp — с Java/C# (примерно вдвое медленнее С++). Haskell у нас в аутсайдерах — в лучшем случае втрое медленнее С++.

Кстати, стоит упомянуть еще и Smalltalk — по гибкости он тоже значительно превосходит систему типов С++ (по скорости выполнения сравним с Java).

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

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

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

VladD2,

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

> Это параноя уже.

Это повседневная реальность: эти ошибки появляются, и тестированием адекватно не отлавливаются. И о чем, собственно, периодически и заходит речь: C++ позволяет программисту сделать так, что такие ошибки будут отлавливаться компилятором. Тут Трурль интересный пример на OCaml показал (раньше не знал, что pattern matching в OCaml требует проверки всех возможных результатов — в общем-то, это логично, но я как-то об этом не задумывался); так что противопоставление на примере данного случая с другими языками, там, где оно делалось, следует сузить до языков, которые чаще всего противопоставляются в данном форуме C++ (C#, Java, Оберон, Ада, Delphi).

> Чтобы поймать такую ошибку достаточно написать запрос на R#-е.

R# здесь отдыхает: 1) тянуть только из-за этого его никто в проект не будет; 2) запросы, как я понимаю, писать нелегко, так что для каждой функции их просто-напросто никто писать не будет, что и происходит со всякими другими анализаторами кода и средствами, подобными Lint — обычно там ограничиваются достаточно общими правилами, аналогичными соглашениям по кодированию и т.п.

> А можно вообще превратить подобную фигню в диекларативную с ватоматической проверкой при инициализации.

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

> Ну, и что самое главное в твоем случае я вообще не заметил никакого контроля. Или рассчитывается, что кто-то особо зоркий будет сидеть и сравнивать if-ы с объявлениями переменных?

Контроль происходит в момент, когда возникла ошибка компиляции по поводу недостающего значения. Этого (для наших целей) достаточно; главное не пропустить само место, где не ожидают нового возвращаемого значения.

> Вообще странно слышать от человека который постоянно твердит, что "дело в классе разработчика..." о таких примитивных ошибках.

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

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

VD>Вообще странно слышать от человека который постоянно твердит, что "дело в классе разработчика..." о таких примитивных ошибках.

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

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

AVC>>Все правильно: "Каждый выбирает для себя..." (из песни)
AVC>>Мне показалось (может, и ошибочно), что ты немного разочарован результатом — каждый остался "при своем".

CX>Нет, не разочарован. Честно говоря, вообще не припоминаю случаев, когда в споре вдруг кому-то "неожиданно открылась истина, ослепляя своим блеском".
CX>Цель не в этом. Цель в другом — дать пищу для размышлений и, возможно, подтолкнуть к действию. Я вот, например, решил на Оберон посмотреть более внимательно, а также лиспом на досуге заняться (тем же emacs-ом для начала) — чем не результат?

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

Из книги "Ле-цзы"

Циньский князь Мугун сказал конюшему Бо Лэ:
— Ты уже стар годами. Нет ли кого-нибудь в твоем роду, кто умел бы отбирать лошадей?
— Доброго коня можно узнать по стати, мускулам и костяку. Однако у Первого Коня в Поднебесной все это — словно бы стерто и смыто, скрыто и спрятано. Такой конь мчится, не поднимая пыли, не оставляя следов. Сыновья же мои малоспособны: они сумеют найти хорошего коня, но не смогут найти Первого Коня в Поднебесной. Когда-то я таскал вязанки дров и связки овощей совместно с неким Цзюфан Гао. Он разбирался в лошадях не хуже вашего слуги. Пригласите его.
Князь принял Цзюфан Гао и немедля отправил его за конем. Через три месяца Цзюфан Гао вернулся и доложил:
— Отыскал. В Песчаных Холмах.
— А что за конь? — спросил Мугун.
— Гнедая кобыла.
Послали за кобылой, а это оказался вороной жеребец.
Князь, опечалившись, позвал Бо Лэ и сказал ему:
— Ничего не получилось! Тот, кого ты прислал отбирать коней, не способен разобраться даже в масти, не умеет отличить кобылу от жеребца — какой уж из него лошадник!
— Неужели он этого достиг! — сказал Бо Лэ, вздохнув в глубоком восхищении. — Да после этого тысячи и тьмы таких, как я, — ничто в сравнении с ним! Ведь Гао видит природную суть. Отбирает зерно, отметая мякину, проникает внутрь, забывая о внешнем. Видит то, что нужно видеть, а ненужного не — замечает. Смотрит на то, на что следует смотреть, пренебрегая тем, на что смотреть не стоит. Да такое умение — дороже всяких коней!
Когда жеребца привели, это и впрямь оказался первый конь в Поднебесной!

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

AVC>>Надеюсь, что мы обсудим и неязыковые причины ненадежности программ. Мне кажется, что в основном они связаны с трудностями моделирования реального мира. А это тоже очень интересная тема.

CX>Да, вот это хотелось бы обсудить.

Надеюсь, в ближайшее время нам это удастся.