Преди да се върнем към общите въпроси на софтуерното инженерство, трябва да премислим няколко по-конкретни поуки от опита с fetchmail.
Синтаксисът на rc файла включва допълнителни "шумови" ключови думи, които напълно се пренебрегват от граматичния анализатор. Англо-подобният синтаксис, който те позволяват, е значително по-четим от традиционните сбити двойки "ключ-стойност", които получавате, ако напълно премахнете шумовите думи.
Те започнаха като среднощен експеримент, когато забелязах как декларациите от rc файла много замязват на императивен миниезик. (Точно заради това и промених оригиналната ключова дума на popclinet от "server" на "poll").
Струваше ми се, че този императивен миниезик може да стане по-лесен за използване, ако се доближи до английския. Сега, макар да съм убеден привърженик на школата за дизайн "направи го език", илюстрирана от Emacs, HTML и много езици за бази от данни, обикновено не съм голям почитател на "англо-подобните" синтаксиси.
По традиция програмистите са склонни да предпочитат контролните синтаксиси, които са много точни и компактни, и нямат никакъв излишък на информация. Това е културно наследство от времето, когато компютърните ресурси бяха скъпи, така че степените на граматичен анализ трябваше да бъдат колкото се може по-евтини и по-прости. Тогава английският език, с около 50% излишък на информация, е изглеждал като много неподходящ модел.
Но това не е моето основание обикновено да избягвам англо-подобните синтаксиси; споменах го тук само за да го срина. С евтини цикли и ядро, сбитостта не бива да бъде самоцел. За един език в днешно време е по-важно да бъде удобен за хората, отколкото да бъде евтин за компютъра.
Все още има добри основания да бъдем предпазливи. Едно от тях е цената на сложността във фазата на граматичен анализ -- вие не искате да я повишите до нивото, където сама по себе си ще бъде значителен източник на грешки и объркване за потребителя. Друго основание е, че при опит да се направи англо-подобен синтаксис на език често се оказва, че "английският", който той ще говори, е толкова объркващ, колкото би бил традиционният синтаксис. (Това може да се види при много от т.нар. "езици от четвърто поколение" и комерсиалните езици за заявки към бази от данни.)
Контролният синтаксис на fetchmail изглежда заобикаля тези проблеми, понеже приложението на езика е силно ограничено. Той съвсем не е език с общо предназначение. Нещата които той казва, просто не са толкова сложни, така че съществува малка вероятност от объркване при мисленото движение между дребно подмножество на английския език и действителен контролен език. Мисля, че тук има една по-обща поука:
16. Когато езикът ти съвсем не е Тюринг-издържан, синтактичният подсладител може да бъде твой приятел.
Друга поука се отнася за сигурността чрез мъглявост. Някои потребители на fetchmail ме помолиха да променя софтуера, за да съхранява паролите в шифриран вид в rc файла, така че любопитковците да не могат случайно да ги видят.
Не го сторих, пронеже това всъщност не увеличава защитата. И без туй ако някой е придобил права за да прочете вашия rc файл, тогава ще е в състояние да изпълнява fetchmail -- и ако те искат да се докопат до паролата ви, ще са в състояние да измъкнат необходимия декодер от самия код на fetchmail, за да я получат.
Всичко, което ще постигне шифрирането на паролите във .fetchmailrc, е да даде фалшиво чувство за сигурност на хората, които не мислят много усилено. Общото правило тук е:
17. Една система за сигурност е толкова сигурна, колкото сигурна е нейната тайна. Пазете се от псевдо-тайни.