Rambler's Top100
"Knowledge itself is power"
F.Bacon
Поиск | Карта сайта | Помощь | О проекте | ТТХ  
 Базарная площадь
  
О разделе

Основная страница

Группы обсуждений


Тематический каталог обсуждений

Архив

 
 К н и г и
 
Книжная полка
 
 
Библиотека
 
  
  
 


Поиск
 
Поиск по КС
Поиск в статьях
Яndex© + Google©
Поиск книг

 
  
Тематический каталог
Все манускрипты

 
  
Карта VCL
ОШИБКИ
Сообщения системы

 
Форумы
 
Круглый стол
Новые вопросы

 
  
Базарная площадь
Городская площадь

 
   
С Л С

 
Летопись
 
Королевские Хроники
Рыцарский Зал
Глас народа!

 
  
ТТХ
Конкурсы
Королевская клюква

 
Разделы
 
Hello, World!
Лицей

Квинтана

 
  
Сокровищница
Подземелье Магов
Подводные камни
Свитки

 
  
Школа ОБЕРОНА

 
  
Арсенальная башня
Фолианты
Полигон

 
  
Книга Песка
Дальние земли

 
  
АРХИВЫ

 
 

Сейчас на сайте присутствуют:
 
  
 
Во Флориде и в Королевстве сейчас  03:38[Войти] | [Зарегистрироваться]
Обсуждение темы:
Оберон-технология: особенности и перспективы


Тематика обсуждения: Оберон-технология. Особенности, перспективы, практическое применение. 

Количество сообщений на странице

Порядок сортировки сообщений
Новое сообщение вверху списка (сетевая хронология)
Первое сообщение вверху списка (обычная хронология)

Перейти на конкретную страницу по номеру


Всего в теме 6256 сообщений

Добавить свое сообщение

Отслеживать это обсуждение

Обсуждение из раздела
Школа ОБЕРОНА

<<<... | 3746—3737 | 3736—3727 | 3726—3717 | ...>>>
Всего сообщений в теме: 6256; страниц: 626; текущая страница: 253


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


№ 3735   07-04-2007 15:52 Ответить на это сообщение Ответить на это сообщение с цитированием
Ответ на »сообщение 3731« (Сергей Перовский)
___________________________

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


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


№ 3734   07-04-2007 15:46 Ответить на это сообщение Ответить на это сообщение с цитированием
Ответ на »сообщение 3732« (Сергей Перовский)
___________________________

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

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

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

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


№ 3733   07-04-2007 15:41 Ответить на это сообщение Ответить на это сообщение с цитированием
Ответ на »сообщение 3731« (Сергей Перовский)
___________________________

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

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

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

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


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


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


№ 3730   07-04-2007 14:33 Ответить на это сообщение Ответить на это сообщение с цитированием
Ответ на »сообщение 3728« (Руслан Богатырев)
___________________________

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


№ 3729   07-04-2007 14:28 Ответить на это сообщение Ответить на это сообщение с цитированием
Ответ на »сообщение 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
 AVC


№ 3728   07-04-2007 14:17 Ответить на это сообщение Ответить на это сообщение с цитированием
Ответ на »сообщение 3715« (Руслан Богатырев)
___________________________

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

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


№ 3727   07-04-2007 13:56 Ответить на это сообщение Ответить на это сообщение с цитированием
Ответ на »сообщение 3726« (Руслан Богатырев)
___________________________

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

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

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

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


<<<... | 3746—3737 | 3736—3727 | 3726—3717 | ...>>>
Всего сообщений в теме: 6256; страниц: 626; текущая страница: 253


Добавить свое сообщение

Отслеживать это обсуждение

Дополнительная навигация:
Количество сообщений на странице

Порядок сортировки сообщений
Новое сообщение вверху списка (сетевая хронология)
Первое сообщение вверху списка (обычная хронология)

Перейти на конкретную страницу по номеру
  
Время на сайте: GMT минус 5 часов

Если вы заметили орфографическую ошибку на этой странице, просто выделите ошибку мышью и нажмите Ctrl+Enter.
Функция может не работать в некоторых версиях броузеров.

Web hosting for this web site provided by DotNetPark (ASP.NET, SharePoint, MS SQL hosting)  
Software for IIS, Hyper-V, MS SQL. Tools for Windows server administrators. Server migration utilities  

 
© При использовании любых материалов «Королевства Delphi» необходимо указывать источник информации. Перепечатка авторских статей возможна только при согласии всех авторов и администрации сайта.
Все используемые на сайте торговые марки являются собственностью их производителей.

Яндекс цитирования