Re: Несколько вопросов вразброс
Артём Н. -> debian-russian@lists.debian.org @ Sun, 01 Jul 2012 23:10:58 +0400:
>> АН> Думаю, что сравнивать рабочую ФС и её копию - не совсем корректно. В случае
>> АН> бэкапа, имеется возможность сделать новый.
>> Если оно побилось, пока бэкап хранился (битый блок на бэкапном винте,
>> например), то ты это обнаружишь только во время восстановления. Когда
>> по постановке задачи :) сделать новый бэкап возможности уже нет.
АН> Имелось ввиду, что был создан некорректный бэкап и есть возможность пересоздать.
А автор fsarchive имел в виду то, что написал я.
>> АН> Хм... Да, пожалуй, это верно.
>> АН> Но, если система выполняет ответственные действия..?
>> АН> Вопрос в том совместить требования надёжности и корректности с
>> АН> отказоустойчивостью и возможностью восстановления после сбоя?
>> Кодогенерация сишного или даже ассемблерного кода на какой-нибудь agda.
>> Которая из тебя душу вынет, пока ты ей корректность не докажешь.
>> Правда, порог вхождения весьма высокий.
АН> Про Agda не слышал. Что-то небогато по ней документации, но,
АН> насколько я понял, это система автоматического доказательства
АН> теорем. Не очень понимаю, как она может быть использована, в данном
АН> контексте: тесты же должны выполняться после компиляции..?
В данном случае компиляция выполняется вместо тестов. Тесты, в отличие
от доказательства корректности, не являются гарантией надежности.
>> Мне говорили о людях, которые на Haskell делают по этой схеме авионику.
>> Реально летающие приборы. В сам прибор хаскельную программу запихнуть
>> вряд ли можно - он, зараза, ленивый, и время реакции у него поэтому
>> негарантированное. А с кодогенерацией - и делают, и проходят
>> сертификацию процесса разработки, а она (сертификация эта) в авиации
>> довольно серьезная.
АН> Хм... Да, про Haskell знаю, что "чистый" функциональный язык. На практике я им
АН> не пользовался, поэтому для меня он не известен. Всё никак руки не доходят
АН> осилить. Только собираюсь. :-)
АН> Я думал, что на практике он серьёзно не применяется.
А он вот применяется.
АН> Но ведь, правда, Haskell должен быть надёжнее, потому что, функции не имеют
АН> "внутренних" побочных эффектов (внешние по отношению к среде, всё-равно должны
АН> быть, например, запись в файл).
В нем есть четкое разграничение - где у нас код с побочными эффектами, а
где чистый. Да, это надежнее.
>> Любой статически типизированный функциональный язык с нормальной
>> системой типов, начиная с того же Haskell или Ocaml.
АН> Ocaml? Любопытно. Пожалуй, посмотрю подробнее.
АН> Для него есть какая-то IDE? И как с библиотеками?
Я знаю одну IDE на все случаи жизни. Emacs. С библиотеками вот у этих
двоих должно быть все хорошо. Ну, то есть у Haskell и есть хорошо - я
на нем работаю и знаю. На Ocaml я не работал, но он тоже мейнстримный,
и тоже с библиотеками все должно быть.
>> При правильном
>> применении, правда, потому что они позволяют довольно легко прострелить
>> себе ногу.
АН> При правильном?
Угу. Оба языка Тьюринг-полны, и если программировать на них без мозгов,
то получится "как всегда".
>> Если брать что-то менее мейнстримное и более строгое, типа
>> той же агды, то прострелить себе ногу будет сложнее. Но и библиотек
>> меньше.
>> И да, насколько я вижу тенденции, такие вещи стараются делать, сообразив
>> на таком языке себе DSL, и пользуясь им. Не запрещая себе пользоваться
>> языком общего назначения, но все-таки выражаясь в терминах абстракций
>> предметной области.
АН> Хм... Про это мне ещё читать и читать. :-(
Это надо не просто читать. Это надо еще и писать. Иначе интуиция не
наработается.
>> >> Я скрипты, от которых хочу надежности, обычно на перле пишу, учитывая,
>> >> что в Debian
>> >> Package: perl-base
>> >> Priority: required
>> АН> o.O Perl, кажется, похож на автомат со снятым предохранителем, направленный в ноги?
>> Многое зависит от наличия головы ;-) Никто не мешает писать в каждом
>> перловом файле use strict; и даже запускать его с -T. Ну и эта... Все
>> его "короткие" варианты под девизом Do The Right Thing - они для
>> однострочников. В скриптах, от которых требуется надежность, никто не
>> запрещает использовать более многословные варианты, и даже иногда
>> что-нибудь проверять :-)
АН> Хм... Всё-равно, особого доверия я к нему не испытываю: слишком "обширный"
АН> синтаксис.
Знаешь, по сравнению с шеллом, к которому ты почему-то испытываешь
доверие, синтаксис перла - просто недостижимый идеал логичности и
лаконичности :-) И уж во всяком случае перл, в отличие от шелла, таки
позволяет писать большие надежные приложения. Есть опыт, ага.
А если ты хочешь действительно прекрасного синтаксиса, возьми tcl. У
него _полное_ описание синтаксиса и семантики укладывается, если я
правильно помню, в одну страницу A4, а if - всего лишь процедура из
стандартной библиотеки. И все необходимое из того, что я описывал, есть.
>> OPT_PARAM1=${OPT_PARAM1:-value1}
>> и позволить пользователю переопределять именно OPT_PARAM_1,
>> использование которой он потом увидит, а не неочевидно с нею связанную
>> ENV_USER_PARAM1
АН> Проверять наличие в окружении OPT_PARAM перед чтением конфига.
АН> И записывать во внутреннюю переменную. Затем делать подстановку переменной по
АН> умолчанию, взятой из конфига.
А чего ради так извращаться, если есть более прямой путь?
>> А почему в конфиге? Да потому что тогда это будет написано в одном
>> месте, а иначе придется писать в каждом скрипте, использующем этот
>> конфиг.
АН> Э... Так код-то один? А конфигов может быть много...
Если логика такая, то можно и в скрипте.
>> Зато, правда, тогда зачитывать этот конфиг можно будет не
>> только шеллом. Но поскольку по опыту ситуация, когда один и тот же
>> конфиг и сурсится шеллом, и читается чем-то еще, встречается крайне
>> редко...
АН> По-моему, тут дополнительные сложности и нарушение ортогональности...
А по-моему, нарушение ортогональности - это как раз модификация
результата чтения конфига в использующем его скрипте.
АН> Лучший вариант - сделать единообразный формат конфига.
АН> Или сервер, отдающий конфиг в каком-либо общем формате.
Все известные мне попытки последнего сводятся в итоге к переусложнению
конструкции и тому, что самым сложным и ненадежным местом в системе
оказывается получение какой-то несчастной директории для сохранения
файлов.
Reply to: