Personliga verktyg
Du är här: Hem Dokumentation Tutorials Katedralen och basaren Några fler lektioner från Fetchmail
Donera
Inloggning


Glömt ditt lösenord?
Ny användare?
« November 2019 »
November
TiOnToFr
123
45678910
11121314151617
18192021222324
252627282930
 
Dokumentåtgärder

Några fler lektioner från Fetchmail

Några fler lektioner från Fetchmail
Jag analyserar ett framgångsrikt open-source projekt, fetchmail, som medvetet kördes som en test av några överraskande teorier om utveckling av programvara, som kommer från Linux historia. Jag diskuterar dessa teorier utifrån två fundamentalt olika utveklingsmodeller, 'katedral-modellen', som flertalet i den kommersiella världen använder, kontra 'basar-modellen' från Linuxvärlden. Jag visar, att dessa modeller emanerar från motstridiga ansatser om felsökningens natur gällande programvara. Jag ger sedan en underbyggd argumentation för att Linuxerfarenheten "med ett tillräckligt antal ögon blir alla fel ytliga" visar analogi med andra självkorrigerande system av själviska agenter, och avslutar med en utredning om vad denna insikt betyder för programmeringskonstens framtid.
Page 9 of 16.

Innan vi går tillbaka till allmänna frågor om programvaruutformning, så finns ett par specifika läxor från erfarenheten med fetchmail att fundera över. Icke tekniskt intresserade läsare kan hoppa över detta stycke.

Initieringsfilens (rc-filens) syntax inkluderar "optional noise" nyckelord som ignoreras av parsern. Den engelsk-liknande syntaxen som dessa tillåter gör texten avsevärt mer läsbar än den traditionella och korta 'nyckelord-värde par' text som man får om man stryker dem.

Detta började med sena kvällsexperiment när jag märkte hur rc-filens deklarationer började likna ett imperativt minispråk. (Det är också orsaken till att jag ändrade popclients ursprungliga nyckelord 'server' till 'poll').

Jag föreställde mig att om jag kunde göra detta imperativa minispråk mer likt engelska skulle det kanske bli lättare att använda. Men, även om jag är anhängare till gör-det-till-ett-språk skolan inom programkonstruktion som till exempel Emacs och HRML och många databas motorer, så är jag vanligtvis ingen anhängare till 'English-like' syntax.

Traditionella programmerare har tenderat att föredra syntaxer som är precisa och kompakta och helt saknar redundans. Detta är ett arv från den tiden då datorns resurser var dyra, så att 'parsing'-steget skulle vara så enkelt och billigt som möjligt. Engelskan, som har 50% redundans, tycktes då inte alls vara någon lämplig förlaga.

Detta är inte mitt skäl för att undvika engelskliknande syntaxer: Jag nämner det bara här för att krossa den idéen. Med billiga klockcykler och minne, bör inte litenhet vara ett mål i sig. Numera är det viktigare att ett språk är bekvämt för människan än billigt med avseende på datorns resurser.

Det återstår emellertid goda skäl att tänka sig för. Ett är komplexitetskostnaden för parsersteget - man vill inte dra det till en nivå där det i sig själv är en källa till fel och förvirring bland användarna. Ett annat skäl är att om man försöker göra syntaxen för språket engelskliknande blir det i praktiken så att den "engelska" datorn talar blir så allvarligt deformerad att den ytliga likheten med det naturliga språket blir lika förvirrande som en traditionell syntax skulle ha blivit. (Man kan se denna effekt i många så kallade "fjärde generationens-" kommersiella språk för sökning i databaser.)

Styrspråkets syntax i fetchmail tycks undgå dessa problem eftersom språkets domän är extremt begränsad. Det är långt ifrån ett språk med allmän tillämpning; de saker det uttrycker är inte särskilt komplicerade, så det finns inte så mycket utrymme för förvirring i att gå mentalt mellan en liten delmängd av naturlig engelska till ett styrspråk. Jag tror det kan finnas en sensmoral här:

16 När ens språk är långt ifrån fullständigt (Turing-komplett) kan syntaktiskt socker (syntactic sugar) vara till hjälp.

En annan läxa är den om 'säkerhet genom oklarhet' (security by obscurity). En del användare bad mig ändra programmet så att lösenordet skulle sparas i krypterad form i rc-filen, så att snokare inte skulle komma att se dem. Jag gjorde inte det, därför att det inte ger något extra skydd. Vem som helst som har läsrättigheterna till din rc-fil kan köra fetchmail lika väl som du - och om de är ute efter ditt lösenord så kan de rycka loss dekodern ur fetchmailkoden och få fram det. Det enda en .fetchmailrc lösenordskryptering skulle ha gjort är att ge en falsk känsla av säkerhet till människor som inte tänker så långt. Den generella regeln är:

17. Ett säkerhetssystem är inte säkrare än dess hemliga nycklar. Tag dig i akt för pseudohemligheter.