Ответ на »сообщение 3673« (Jack Of Shadows)
___________________________

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

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

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

Ответ на »сообщение 3651« (Jack Of Shadows)
___________________________

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

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


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

Тем временем вышла первая публичная альфа версия системы 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

Ответ на »сообщение 3670« (AVC)
___________________________
Я вот, например, считаю, что главное -- правильно поделить программу на модули и поставить на границе проверку предусловий и инвариантов.

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

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

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

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

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

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

Ответ на »сообщение 3669« (Jack Of Shadows)
___________________________

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

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

Ответ на »сообщение 3666« (Jack Of Shadows)
___________________________

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

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

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

Ответ на »сообщение 3668« (AVC)
___________________________
А запрещать называть костыль костылем -- это уже какой-то верх политкорректности.


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

Ответ на »сообщение 3666« (Jack Of Shadows)
___________________________

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

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

Ответ на »сообщение 3664« (Jack Of Shadows)
___________________________

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

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

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

Увы, нет.