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

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

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


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

Архив

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


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

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

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

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

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

 
   
С Л С

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

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

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

Квинтана

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

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

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

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

 
  
АРХИВЫ

 
 

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


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

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

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

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


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

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

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

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

<<<... | 3686—3677 | 3676—3667 | 3666—3657 | ...>>>
Всего сообщений в теме: 6256; страниц: 626; текущая страница: 259


№ 3676   07-04-2007 03:11 Ответить на это сообщение Ответить на это сообщение с цитированием
Ответ на »сообщение 3673« (Jack Of Shadows)
___________________________

Ответ на »сообщение 3670« (AVC)
___________________________
Ну и наконец есть ошибки в изменении состояния (самый распространенный случай.) Они к сожалению ничем кроме тестов не отлавливаются.

Хорошо, исключили ручное управление. Не меняем состояние явно. Однако продолжаем решать все те же задачи, где смысл не в преобразовании входа в выход, а в переходах между состояниями. Тогда эти же переходы мы будем описывать, так скажем, "аллегорически", декларативно, чтобы нам "автоматическая коробка" потом их прокрутила. Где гарантии, что в этом "аллегорическом" описании мы не наворотим ошибок? Я смотрел документы по Haskell in Embedded Systems - никакой особой краткости/выразительности кода в задачах на управление по сравнению с кодом уровня Паскаля я не увидел - что и естественно, это не те задачи, на которых ФП "парит как птица"...
Все тезисы автора публикации превосходны, он прекрасно описал проблемы, вызванные низкоуровневыми средствами, используемыми при программировании встроенных систем... если программировать на С или ассмеблере :-) Проблема высокоуровневого системного программирования давно уже прекрасно разрешена в Модуле/Обероне/Аде.

Изменения состояния вполне контролируемы и без отказа от ручного управления. Стоит от "размазывания" состояния перейти к его концентрации в строго специфицированных модулях и микромодулях (объектах), описать контракты - и изменения вполне контролируемы и формально доказуемы. Кроме того, при установке на всех "узких интерфейсах" контроля предусловий, мы получим динамический контроль правильности работы программы с локализацией сбоя. Предусловия небольшие, описываются раздельно, ошибиться в них сложно. Если же совершена ошибка где-то в функциональном описании в большой программе (пусть в 10 раз реже, но такие ошибки появляться будут) - насколько труднее ее будет локализовать?
Никогда не забуду ощущений от перехода на Компонентный Паскаль - когда твои модули начинают работать сразу или всего после нескольких пробных запусков (при этом обычно не нужно что-то трассировать и искать ошибку, дамп по предусловию уже принес нам ее место "на блюдечке с голубой каемочкой").


№ 3675   07-04-2007 02:45 Ответить на это сообщение Ответить на это сообщение с цитированием
Ответ на »сообщение 3651« (Jack Of Shadows)
___________________________

Ответ на »сообщение 3649« (Geniepro)
___________________________
Вот любопытно, эти шесть мест с квалифицированными именами дают что-нибудь реальное в плане повышения понятности? :о))

Учитывая специфику модулей в хаскеле (отсутствие хранимого в них состояния) это ничего вообще не дает.


Я делаю кое-какие вещи на FreePascal (Object Pascal), там квалифицирование имени модуля необязательное. Но как-то само собой сложилось так, что я указываю имя модуля всегда, и это реально помогает! Сразу видно, откуда берётся какая-нибудь функция типа SUPPORT.GetDistanceToSegment. Разгрузка мозгов гораздо выгоднее экономии клацанья клавишами при набивке имени модуля.
Вот сейчас подумал, что квалифицирование импорта - это на самом деле, построение гипертекста, как на HTML-странице указание URL :)


№ 3674   07-04-2007 02:23 Ответить на это сообщение Ответить на это сообщение с цитированием
Тем временем вышла первая публичная альфа версия системы UnixAos!
Пока под Darwin/Intel, но в скором времени обещают и под Solaris и Linux...
https://lists.inf.ethz.ch/pipermail/oberon/2007/005290.html
ftp://ftp.informatik.uni-bremen.de/home/fld/oberon/UnixAos
 SAGE


№ 3673   06-04-2007 23:33 Ответить на это сообщение Ответить на это сообщение с цитированием
Ответ на »сообщение 3670« (AVC)
___________________________
Я вот, например, считаю, что главное -- правильно поделить программу на модули и поставить на границе проверку предусловий и инвариантов.

Отвечу на это вашими же словами:
"Интересно, с чего Вы это взяли?
Нужна ведь какая-то статистика, подтверждающая, ..." :))

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

Ну на этот счет есть огромное количество материала, которое как раз таки показывает основного виновника ошибок в программах - микроменеджмент состояния.
Ну а из примеров это подтверждающих - большие проекты написанные на ФЯ (я об Эрланге говорю) в которых надежность - то есть отсутствие тех самых ошибок, недостижима для ИЯ.

Рассмотрим пример.
Присваивание не является корнем ВСЕХ ошибок. Всего лишь БОЛЬШИНСТВА из них.
Так что ваш пример ничего не доказывает.
Есть ошибки типизации. Они отлавливаются компилятором со статической строгой типизацией.
Есть ошибки неправильных параметров. Они отлавливаются пред и постусловиями.
Ну и наконец есть ошибки в изменении состояния (самый распространенный случай.) Они к сожалению ничем кроме тестов не отлавливаются.



№ 3672   06-04-2007 23:27 Ответить на это сообщение Ответить на это сообщение с цитированием
Ответ на »сообщение 3671« (AVC)
___________________________
Я просто подчеркиваю огромную разницу между именованием костыля костылем
Ну а я подчеркиваю разницу именования костыля костлыем и чего то другого костылем.
Да вы и сами эту разницу можете ощутить.
Достаточно мне начать называть оператор присваивания костылем, а вас умственным инвалидом. :))
И ведь правда, хаскель показывает что не нужен этот костыль. Что можно и без него.
Что именно из за него спотыкаешься, делаешь ошибки.

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


№ 3671   06-04-2007 23:12 Ответить на это сообщение Ответить на это сообщение с цитированием
Ответ на »сообщение 3669« (Jack Of Shadows)
___________________________

Во дает :)) Ему говорят - это не костыль. А он отвечает "Мне запрещают костыль называть костылем".
Вы неисправимы :))


Я просто подчеркиваю огромную разницу между именованием костыля костылем и квалификацией собеседника как инвалида или... как неисправимого. ;)
 AVC


№ 3670   06-04-2007 23:08 Ответить на это сообщение Ответить на это сообщение с цитированием
Ответ на »сообщение 3666« (Jack Of Shadows)
___________________________

>>>Я считаю что лучший способ борьбы с ошибками это повсеместное ограничение жонглирования состоянием.

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

Рассмотрим пример.
Допустим, процедура должна вычислить квадратный корень из вещественного числа, а в качестве аргумента ей передали отрицательное число.
Ну и что толку, что здесь нет присвоения?
Все равно требуется проверка принадлежности аргумента области определения функции.
 AVC


№ 3669   06-04-2007 23:03 Ответить на это сообщение Ответить на это сообщение с цитированием
Ответ на »сообщение 3668« (AVC)
___________________________
А запрещать называть костыль костылем -- это уже какой-то верх политкорректности.


Во дает :)) Ему говорят - это не костыль. А он отвечает "Мне запрещают костыль называть костылем".
Вы неисправимы :))


№ 3668   06-04-2007 22:50 Ответить на это сообщение Ответить на это сообщение с цитированием
Ответ на »сообщение 3666« (Jack Of Shadows)
___________________________

>>>Вам показать пальцем на костыли, инвалидные коляски и прочие "наркотики" или сами найдете ?

Ой, Jack, а как Вы порой обвиняете "императивщиков" в разных грехах? :)
А запрещать называть костыль костылем -- это уже какой-то верх политкорректности.
Ладно, пусть это будет... ветка сирени. :)
 AVC


№ 3667   06-04-2007 22:44 Ответить на это сообщение Ответить на это сообщение с цитированием
Ответ на »сообщение 3664« (Jack Of Shadows)
___________________________

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

В данном случае Ваша критика не по адресу. :)
Эту путаницу привнес Geniepro, уравняв в статусе библиотечные функции Хаскеля и встроенные функции и процедуры Оберона, код которых встраивается компилятором (вместо ссылки на библиотеку или какой-либо модуль).

>>>Я уверен что в стандартном наборе библиотек оберона тоже наберется не одна сотня классов.

Увы, нет.
 AVC


<<<... | 3686—3677 | 3676—3667 | 3666—3657 | ...>>>
Всего сообщений в теме: 6256; страниц: 626; текущая страница: 259


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

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

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

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

Перейти на конкретную страницу по номеру
  
Время на сайте: 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» необходимо указывать источник информации. Перепечатка авторских статей возможна только при согласии всех авторов и администрации сайта.
Все используемые на сайте торговые марки являются собственностью их производителей.

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