| Оберон-технология: особенности и перспективы |
Тематика обсуждения: Оберон-технология. Особенности, перспективы, практическое применение.
Всего в теме 6256 сообщений
Добавить свое сообщение
Отслеживать это обсуждение  Обсуждение из раздела
Школа ОБЕРОНА
| № 1176 04-12-2006 03:08 |   |
>>> Мне нравится эта идея:
>>> структура входных/выходных данных порождает структуру программы
А мне нравится немного другая:
структура реального объекта порождает структуру модели и структуру программы.
Только вот беда - структуру программы принято составлять по другим принципам,
диктуемым мифами, парадигмами, принципами, филисофией и религией программирования.
А вот это несоответствие и порождает большинство ошибок.
То, что в состоянии отловить правильный компилятор - мизер.
И его значение - электрошооквая профилактика ошибок у новичка.
А это идея! Подвести вольт ... ну, 36 (зависит от требуемых сроков обучения)
к креслу и на exception ... Буквально feedback ! :)
| № 1175 03-12-2006 01:08 | |
Ответ на »сообщение 1171« (Geniepro)
___________________________
... Имхо, это идеальный подход для Функционального программирования. Но он, как я понимаю, плохо совместим с принципами ООП.
Оберон и КП - языки компонентно-ориентированные, то есть близки к ООП. Можно ли совместить методику Джексона с Оберон-технологией?
Как-то очень непонятно. Где, что, с чем не совместимо? Априорно несовместимо? Это, боюсь, слишком сильный тезис. И неправильный.
Что такое тут "принципы ООП"?
Как раз, скажем, КП заточен под "ограниченное ООП" (абстрактный родитель --> несколько конкретных, нерасширяемых потомков). Остальное -- для совместимости со старыми Оберонами (EXTENSIBLE вообще надо спрятать в SYSTEM и т.п.).
Не нужно мифологизировать ФП и так уж принципиально его противопоставлять Оберону/КП -- нет такого противуположения в объективной объективности -- только в объективной субъективности (в том смысле, что головы, в которых такое субъективное мнение существует, объективно существуют :))))).
| № 1174 02-12-2006 13:04 | |
Ответ на »сообщение 1137« (AVC)
___________________________
Ответ на »сообщение 1113« (гость)
___________________________
Полезно также знать о данных, приведенных Брегой (на которого ссылается info21).
Единственное, в последнем случае мне лично не вполне ясна методика оценки.
У меня была где-то в конторе бумажная копия. Увижу -- сообщу, договоримся.
| № 1173 02-12-2006 13:03 | |
Ответ на »сообщение 1152« (Денис Зайцев)
___________________________
Дык, там же результаты расследования тоже были опубликованы, в которых было написано, что не нужно было нарушать принципы design by contract. Унаследованный код не был быть нужным образом документирован, значит, его нельзя было использовать.
Что "не нужно" зависит от того, что продает пишущий :))
Я вот "продаю", что там должно было быть как минимум int16 := SHORT( int32 ), а не int16 := int32 (если я правильно помню, и тогда (Geniepro) в »сообщение 1147« прав).
SHORT -- сам себе комментарий.
| № 1172 02-12-2006 10:39 | |
Ответ на »сообщение 1171« (Geniepro)
___________________________
>>>Можно ли совместить методику Джексона с Оберон-технологией?
Действительно, все идеи доказательства алгоритмов и программ родом из того периода развития программирования, когда программа имела четко разделенные вход и выход.
Т.е. это как раз область функционального программирования:
ВВОД->ОБРАБОТКА->ВЫВОД.
Когда программы стали обрабатывать потоки событий, функциональный подход стал недостаточным. А с ним и методы доказательства или синтеза алгоритмов.
Но для отдельных функций это хорошо работает. И грех не воспользоваться.
| № 1171 02-12-2006 07:57 | |
Ответ на »сообщение 1169« (Снегурочка)
___________________________
Я давно уже уважаю методику Джексона (JSP), о которой вычитал в старинной книге Дэвида Кинга "Создание эффективного программного обеспечения".
Мне нравится эта идея: структура входных/выходных данных порождает структуру программы (алгоритма обработки данных). Имхо, это идеальный подход для Функционального программирования. Но он, как я понимаю, плохо совместим с принципами ООП.
Оберон и КП - языки компонентно-ориентированные, то есть близки к ООП. Можно ли совместить методику Джексона с Оберон-технологией?
| № 1170 01-12-2006 18:21 | |
| № 1169 01-12-2006 17:52 | |
Ответ на »сообщение 1165« (Geniepro)
___________________________
Понятное дело, что верифицированный софт - самый лучший софт, но насколько такой достаточно сложный софт реален?
И поможет ли тут Оберон-технология? :о))
Поможет. Чем проще и четче правила, по которым строится программа, чем проще понимание программистом того, что он делает с помощью языка, тем легче верифицировать программу. Верификация не может быть до конца формальна. Это важный момент. Человек все равно остается ключевым звеном, которым нельзя пренебрегать.
Но верификация даже с учетом такого понимания должна все же проводиться. Ей должны повергаться как штатные, так и нештатные действия программы. Нужно предусматривать программные исключения и верифицировать их наряду с нормальным порядком выполнения.
Ответ на »сообщение 1167« (Сергей Перовский)
___________________________
И Дейкстра и Грис никогда не призывали верифицировать программы полностью.
Дейкстра особо выделял формальную спецификацию программы и проводил разграничение между correctness concern (аспект корректности - ли программа своей формальной спецификации) и pleasantness concern (аспект удовлетворительности - является ли программа, удовлетворяющая спецификации, именно тем, что задумывалось).
По этой теме есть интересная публикация - обзор недавней статьи М.Джексона из октябрьского номера IEEE Computer - "Что мы можем ожидать от верификации программ?" (What Can We Expect from Program Verification?) http://www.osp.ru/text/302/3584623/_p3.html
и там же - статьи Дэвида Гриса «Чему мы не научились в отношении обучения программированию?» (What Have We Not Learned about Teaching Programming?).
Ответ на »сообщение 1168« (AVC)
___________________________
ИМХО, хорошая структура является обязательным требованием равно при стремлении к постижимости и доказуемости (верификации).
Верно. Сейчас верификация и средства обеспечения надежности ПО - одна из самых горячих тем в research-сфере. И там появление Оберона было бы совсем нелишним.
| № 1168 01-12-2006 16:39 | |
Ответ на »сообщение 1164« (Снегурочка)
___________________________
Простота структуры и ясность документации - это не главное на пути к надежному софту. Тестирование - иллюзия гарантии надежности. На самом деле необходима верификация - как модели, так и ее реализации.
Если вспомнить историю, верификация и структурное программирование взаимосвязаны. Злоупотребление goto затрудняло доказательство программ.
ИМХО, хорошая структура является обязательным требованием равно при стремлении к постижимости и доказуемости (верификации).
Взять хотя бы количественный аспект: плохая структура приводит к взрывному росту количества связей между разными компонентами (т.н. декартовому произведению).
Неужели кто-то всерьез полагает, что требование ясности структуры, свойственное всем интеллектуальным областям (ИМХО, без исключения), необязательно почему-то именно для программирования?
| № 1167 01-12-2006 13:29 | |
Ответ на »сообщение 1165« (Geniepro)
___________________________
>>>доказательство корректности программы на порядок сложнее самой программы
Доказательство правильности программы тоже не серебрянная пуля.
И Дейкстра и Грис никогда не призывали верифицировать программы полностью.
Речь шла о процедурах, модулях и библиотеках, предназначенных для широкого тиражирования.
Если предлагаешь для всеобщего пользования набор процедур ( тем более ежели за деньги), будь добр ДОКАЗАТЬ, что процедуры будут делать ровно то, что написано в спецификации. Причем во всех случаях.
Представьте, что ядро Windiws было бы верифицировано! Что API функции всегда работали бы в соответствии со спецификациями. Даже если бы это увеличило себестоимость на опрядок (во что верится с трудом) дело все равно было бы сверхприбыльное.
Добавить свое сообщение
Отслеживать это обсуждение
| Дополнительная навигация: |
| 
