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