Към текста

Метаданни

Данни

Оригинално заглавие
The Cathedral and the Bazaar, (Пълни авторски права)
Превод от
, (Пълни авторски права)
Форма
Есе
Жанр
  • Няма
Характеристика
  • Няма
Оценка
5,5 (× 2 гласа)

Информация

Корекция и форматиране
Юлиян Йорданов (2014)
Източник
catb-bg.sourceforge.net

Сътрудници на превода: Антон Зиновиев, Христо Божинов

История

  1. — Добавяне

Още няколко поуки от fetchmail

Преди да се върнем към общите въпроси на софтуерното инженерство, трябва да премислим няколко по-конкретни поуки от опита с fetchmail.

Синтаксисът на rc файла включва допълнителни „шумови“ ключови думи, които напълно се пренебрегват от граматичния анализатор. Англо-подобният синтаксис, който те позволяват, е значително по-четим от традиционните сбити двойки „ключ-стойност“, които получавате, ако напълно премахнете шумовите думи.

Те започнаха като среднощен експеримент, когато забелязах как декларациите от rc файла много замязват на императивен миниезик. (Точно заради това и промених оригиналната ключова дума на popclinet от „server“ на „poll“).

Струваше ми се, че този императивен миниезик може да стане по-лесен за използване, ако се доближи до английския. Сега, макар да съм убеден привърженик на школата за дизайн „направи го език“, илюстрирана от Emacs, HTML и много езици за бази от данни, обикновено не съм голям почитател на „англо-подобните“ синтаксиси.

По традиция програмистите са склонни да предпочитат контролните синтаксиси, които са много точни и компактни, и нямат никакъв излишък на информация. Това е културно наследство от времето, когато компютърните ресурси бяха скъпи, така че степените на граматичен анализ трябваше да бъдат колкото се може по-евтини и по-прости. Тогава английският език, с около 50% излишък на информация, е изглеждал като много неподходящ модел.

Но това не е моето основание обикновено да избягвам англо-подобните синтаксиси; споменах го тук само за да го срина. С евтини цикли и ядро, сбитостта не бива да бъде самоцел. За един език в днешно време е по-важно да бъде удобен за хората, отколкото да бъде евтин за компютъра.

Все още има добри основания да бъдем предпазливи. Едно от тях е цената на сложността във фазата на граматичен анализ — вие не искате да я повишите до нивото, където сама по себе си ще бъде значителен източник на грешки и объркване за потребителя. Друго основание е, че при опит да се направи англо-подобен синтаксис на език често се оказва, че „английският“, който той ще говори, е толкова объркващ, колкото би бил традиционният синтаксис. (Това може да се види при много от т.нар. „езици от четвърто поколение“ и комерсиалните езици за заявки към бази от данни.)

Контролният синтаксис на fetchmail изглежда заобикаля тези проблеми, понеже приложението на езика е силно ограничено. Той съвсем не е език с общо предназначение. Нещата които той казва, просто не са толкова сложни, така че съществува малка вероятност от объркване при мисленото движение между дребно подмножество на английския език и действителен контролен език. Мисля, че тук има една по-обща поука:

16. Когато езикът ти съвсем не е Тюринг-издържан, синтактичният подсладител може да бъде твой приятел.

Друга поука се отнася за сигурността чрез мъглявост. Някои потребители на fetchmail ме помолиха да променя софтуера, за да съхранява паролите в шифриран вид в rc файла, така че любопитковците да не могат случайно да ги видят.

Не го сторих, понеже това всъщност не увеличава защитата. И без туй ако някой е придобил права за да прочете вашия rc файл, тогава ще е в състояние да изпълнява fetchmail — и ако те искат да се докопат до паролата ви, ще са в състояние да измъкнат необходимия декодер от самия код на fetchmail, за да я получат.

Всичко, което ще постигне шифроването на паролите във .fetchmailrc, е да даде фалшиво чувство за сигурност на хората, които не мислят много усилено. Общото правило тук е:

17. Една система за сигурност е толкова сигурна, колкото сигурна е нейната тайна. Пазете се от псевдо-тайни.