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