Ответ на »сообщение 3734« (Руслан Богатырев)
___________________________
>>>Я не очень понял, откуда следует, что динамически должны загружаться обязательно непроверенные (неоттестированные) модули?
Я про системные ошибки. Не в смысле операционных систем, а в смысле теории систем.
Система обладает свойствами, которыми не обладают ее элементы.
Сами по себе модули могут не содержать ошибок с точки зрения их разработчиков.
И с точки зрения тестеров модуля.
А с точки зрения пользователя, система собранная из оттестированных модулей может работать непредсказуемым образом.
Если модуль делали смежники, можно гарантировать, что требования они поняли по своему и тесты подбирали соответственно.

Ответ на »сообщение 3731« (Сергей Перовский)
___________________________

В Обероне АБСОЛЮТНО НЕОБХОДИМ квалифицированный импорт, поскольку он создавался для МОДУЛЬНОГО ПРОГРАММИРОВАНИЯ. Если мы работаем в другой парадигме, неважно ООП или ФП, квалифицированный импорт становится необязательным, а то и бесполезным.
Поэтому почувствовав удобство этого механизма в Обероне, не надо утверждать, что это единственно правильный способ, он просто правильный для Оберона, соответствующий его концепциям и назначению.

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

Ответ на »сообщение 3732« (Сергей Перовский)
___________________________

Любой обновленный модуль, при всей правильности интерфейсов и продвинутости языка может содержать новые АЛГОРИТМИЧЕСКИЕ ошибки, которые никаким способом кроме тестирования не ловятся.

Данное утверждение справедливо по отношению к любому модулю (что статически, что динамически линкуемому/подгружаемому).

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

Согласование изменений требуется в том случае, когда авторы изменений затрагивают интересы смежников (клиентов). Если же авторы гарантируют (берут на себя ответственность) отсутствие этих изменений при расширении/модификации, нет никакого анархического программирования. Каждый отвечает за свой участок. Я не очень понял, откуда следует, что динамически должны загружаться обязательно непроверенные (неоттестированные) модули? Откуда такая дискриминация?

Ответ на »сообщение 3731« (Сергей Перовский)
___________________________

В Обероне АБСОЛЮТНО НЕОБХОДИМ квалифицированный импорт, поскольку он создавался для МОДУЛЬНОГО ПРОГРАММИРОВАНИЯ. Если мы работаем в другой парадигме, неважно ООП или ФП, квалифицированный импорт становится необязательным, а то и бесполезным.

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

Боюсь, в данном случае имеет место серьезное заблуждение. С этой точки зрения (наличия и использования модулей) разницы между Delphi и Обероном нет практически никакой (загрузка-выгрузка модулей не регламентируется языком -- это выверты реализации). Подробнее см. здесь http://www.europrog.ru/qa261005.html

Незнание, как известно, не освобождает от ответственности. Аналогия "государство" против "соседнего отдела" -- это принцип, не диктуемый языком (Delphi), а лишь следствие сложившейся практики работы в Delphi, где вопросам модульной декомпозиции видимо уделяют крайне мало внимания.

Ответ на »сообщение 3700« (AVC)
___________________________
>>>Но случилось так, что разработчики одного из импортируемых Вами модулей решили расширить его функциональность и тоже завели себе процедуру FindClose.
Мне вообще очень трудно представить такой анархический стиль программирования, когда в систему вносятся несогласованные изменения. Может на каких-то задачах это единственно возможный вариант, но меня этот подход просто пугает. Мне достаточно тех изменений, которые вносятся в Windows, временами делая программы неработоспособными, чтобы мечтать о более масштабном распостранении такой практики. Любой обновленный модуль, при всей правильности интерфейсов и продвинутости языка может содержать новые АЛГОРИТМИЧЕСКИЕ ошибки, которые никаким способом кроме тестирования не ловятся. А поскольку плоходиагностируемые алгоритмические ошибки, как правило, сводятся к упущению из рассмотрения редких случаев, то срабатывают они в момент, когда все уже убедились, что все прекрасно работает. Мы даже не сможем понять, замена какого модуля привела к катастрофе.

Ответ на »сообщение 3698« (AVC)
___________________________
>>>Вы действительно полагаете, что программная система (особенно, конечно, динамическая) в условиях такой неопределенности может быть надежной?
Я полагаю, что это важно именно для динамических систем. Все опять упирается в пресловутую отчуждаемость.
Тут уже приводился пример с визами: для поездок "за рубеж" вещь необходимая, а для вызова в соседнюю комнату бессмысленная.
В Обероне АБСОЛЮТНО НЕОБХОДИМ квалифицированный импорт, поскольку он создавался для МОДУЛЬНОГО ПРОГРАММИРОВАНИЯ. Если мы работаем в другой парадигме, неважно ООП или ФП, квалифицированный импорт становится необязательным, а то и бесполезным.
Поэтому почувствовав удобство этого механизма в Обероне, не надо утверждать, что это единственно правильный способ, он просто правильный для Оберона, соответствующий его концепциям и назначению.

Ответ на »сообщение 3728« (Руслан Богатырев)
___________________________

В отношении Дейкстры: с оригинального, нидерландского языка Edgar Wybe Dijkstra будет "Эдгар Вейбе Дейкстра" (а Edsger -- это, похоже, творчество американцев). Очень близко к тому, как писал А.П.Ершов.

Ответ на »сообщение 3728« (Руслан Богатырев)
___________________________

Ответ на »сообщение 3715« (Руслан Богатырев)
___________________________

Не знаю, нужно ли рассказывать, кто такой бывший главный архитектор Microsoft Чарльз Саймони (Charles Simonyi) и что есть венгерская нотация (Hungarian notation).

Возможно мелочь, но для кого-то окажется важной. Сверился по словарю Р.А.Лидина "Иностранные фамилии и личные имена. Написание и произношение" (1998). На венгерском фамилия и имя записываются наоборот, при этом у англоязычного Charles был иной оригинал -- Simonyi Karoly. На русском это (с учетом наших правил перевода имен с венгерского) будет звучать "Карой Шимоньи".


Раз уж так много говорят об авторе венгерской нотации, то он сейчас летит к МКС на нашем "Союзе":
http://news.bbc.co.uk/hi/russian/life/newsid_6532000/6532505.stm
http://news.bbc.co.uk/hi/russian/sci/tech/newsid_6536000/6536149.stm

Ответ на »сообщение 3715« (Руслан Богатырев)
___________________________

Не знаю, нужно ли рассказывать, кто такой бывший главный архитектор Microsoft Чарльз Саймони (Charles Simonyi) и что есть венгерская нотация (Hungarian notation).

Возможно мелочь, но для кого-то окажется важной. Сверился по словарю Р.А.Лидина "Иностранные фамилии и личные имена. Написание и произношение" (1998). На венгерском фамилия и имя записываются наоборот, при этом у англоязычного Charles был иной оригинал -- Simonyi Karoly. На русском это (с учетом наших правил перевода имен с венгерского) будет звучать "Карой Шимоньи".

Ответ на »сообщение 3726« (Руслан Богатырев)
___________________________

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

Хотелось бы донести важную мысль, которая как-то растворяется в эмоциях обсуждения. Технологическая дисциплина может быть обеспечена при жестком соблюдении стандарта. Для языка таковым стандартом (в случае отсутствия ISO/ECMA/ANSI и т.п.) является официальное (авторское) описание. Для среды стандарт всегда размыт. Его просто нет в природе.

Если разрешение неясностей (неоднозначностей) выходит за рамки описания языка, это нарушение технологической дисциплины (снижение надежности). Для Оберонов (несмотря на всю их компактность) официальные описания все же оставляют некоторые неоднозначности (прежде всего, в отношении особенностей реализации). Эти особенности должны явно специфицироваться разработчиками компиляторов и run-time (об IDE речь не идет). Пример: описание КП.

Что касается стандартных библиотек: они делятся на два вида -- встроенные (в компилятор, run-time) и внешние. Фиксация стандартных библиотек на основе контрактов-интерфейсов (предусловия, постусловия, инварианты...) является обязательным для соблюдения технологической дисциплины.