Re: Несколько вопросов вразброс
01.07.2012 20:36, Artem Chuprina пишет:
> АН> Думаю, что сравнивать рабочую ФС и её копию - не совсем корректно. В случае
> АН> бэкапа, имеется возможность сделать новый.
> Если оно побилось, пока бэкап хранился (битый блок на бэкапном винте,
> например), то ты это обнаружишь только во время восстановления. Когда
> по постановке задачи :) сделать новый бэкап возможности уже нет.
Имелось ввиду, что был создан некорректный бэкап и есть возможность пересоздать.
> АН> Хм... Да, пожалуй, это верно.
> АН> Но, если система выполняет ответственные действия..?
> АН> Вопрос в том совместить требования надёжности и корректности с
> АН> отказоустойчивостью и возможностью восстановления после сбоя?
> Кодогенерация сишного или даже ассемблерного кода на какой-нибудь agda.
> Которая из тебя душу вынет, пока ты ей корректность не докажешь.
> Правда, порог вхождения весьма высокий.
Про Agda не слышал. Что-то небогато по ней документации, но, насколько я понял,
это система автоматического доказательства теорем. Не очень понимаю, как она
может быть использована, в данном контексте: тесты же должны выполняться после
компиляции..?
> Мне говорили о людях, которые на Haskell делают по этой схеме авионику.
> Реально летающие приборы. В сам прибор хаскельную программу запихнуть
> вряд ли можно - он, зараза, ленивый, и время реакции у него поэтому
> негарантированное. А с кодогенерацией - и делают, и проходят
> сертификацию процесса разработки, а она (сертификация эта) в авиации
> довольно серьезная.
Хм... Да, про Haskell знаю, что "чистый" функциональный язык. На практике я им
не пользовался, поэтому для меня он не известен. Всё никак руки не доходят
осилить. Только собираюсь. :-)
Я думал, что на практике он серьёзно не применяется.
Но ведь, правда, Haskell должен быть надёжнее, потому что, функции не имеют
"внутренних" побочных эффектов (внешние по отношению к среде, всё-равно должны
быть, например, запись в файл).
> Любой статически типизированный функциональный язык с нормальной
> системой типов, начиная с того же Haskell или Ocaml.
Ocaml? Любопытно. Пожалуй, посмотрю подробнее.
Для него есть какая-то IDE? И как с библиотеками?
> При правильном
> применении, правда, потому что они позволяют довольно легко прострелить
> себе ногу.
При правильном?
> Если брать что-то менее мейнстримное и более строгое, типа
> той же агды, то прострелить себе ногу будет сложнее. Но и библиотек
> меньше.
> И да, насколько я вижу тенденции, такие вещи стараются делать, сообразив
> на таком языке себе DSL, и пользуясь им. Не запрещая себе пользоваться
> языком общего назначения, но все-таки выражаясь в терминах абстракций
> предметной области.
Хм... Про это мне ещё читать и читать. :-(
> >> Я скрипты, от которых хочу надежности, обычно на перле пишу, учитывая,
> >> что в Debian
> >> Package: perl-base
> >> Priority: required
> АН> o.O Perl, кажется, похож на автомат со снятым предохранителем, направленный в ноги?
> Многое зависит от наличия головы ;-) Никто не мешает писать в каждом
> перловом файле use strict; и даже запускать его с -T. Ну и эта... Все
> его "короткие" варианты под девизом Do The Right Thing - они для
> однострочников. В скриптах, от которых требуется надежность, никто не
> запрещает использовать более многословные варианты, и даже иногда
> что-нибудь проверять :-)
Хм... Всё-равно, особого доверия я к нему не испытываю: слишком "обширный"
синтаксис.
> OPT_PARAM1=${OPT_PARAM1:-value1}
> и позволить пользователю переопределять именно OPT_PARAM_1,
> использование которой он потом увидит, а не неочевидно с нею связанную
> ENV_USER_PARAM1
Проверять наличие в окружении OPT_PARAM перед чтением конфига.
И записывать во внутреннюю переменную. Затем делать подстановку переменной по
умолчанию, взятой из конфига.
> А почему в конфиге? Да потому что тогда это будет написано в одном
> месте, а иначе придется писать в каждом скрипте, использующем этот
> конфиг.
Э... Так код-то один? А конфигов может быть много...
> Зато, правда, тогда зачитывать этот конфиг можно будет не
> только шеллом. Но поскольку по опыту ситуация, когда один и тот же
> конфиг и сурсится шеллом, и читается чем-то еще, встречается крайне
> редко...
По-моему, тут дополнительные сложности и нарушение ортогональности...
Лучший вариант - сделать единообразный формат конфига.
Или сервер, отдающий конфиг в каком-либо общем формате.
Reply to: