SIGKILL - Programmering

Haskell og Debian

nospam@example.com (Troels Henriksen) — Fri, 27 Jun 2008 21:47:32 +0200

Tilbage i 2007 var mit nytårsforsæt at lære Haskell. Eftersom jeg skriver om det nu, må det vel antages at det ikke blev opfyldt, hvilket er korrekt. Dog er jeg nu begyndt at rette op på det ved at læse lærebogen Programming in Haskell og løse Euler-problemer. Lærebogen er ganske udemærket, dens eneste brist er at den ikke forudsætter nogen form for forgående programmeringserfaring og således bruger en del sider på at beskrive grundlæggende programmeringskoncepter (og bogen er ikke for tyk til at begynde med). Det lader til at være et generelt problem med mange af de funktionsorienterede sprog: Stort set alle tilgængelige bøger er lærebøger beregnet til helt nye programmører, en situation hvor Common Lisp, der har mesterværker som Art of the Metaobject Protocol, skiller sig noget ud.

For at opnå erfaring med brug af Haskell i rigtige projekter er jeg gået over til en ny window manager, xmonad, baseret på den tese at jeg vil blive så irriteret over diverse ubekvemmeligheder at jeg bliver motiveret til at ændre i koden. Der er allerede adskillige ting der irriterer mig (først og fremmest de elendige genvejstaster, et punkt som ratpoison har forvænt mig med).

Jeg er også begyndt at overveje at droppe Debian som styresystem til fordel for Ubuntu. Min oprindelige argumentation for at bruge Debian var at det ville være lettere at vedligeholde Debian end at tilpasse Ubuntu til mine til tider usædvanlige præferencer. Efterhånden er jeg begyndt at tvivle på dette, især efter mit system er begyndt at nægte at vise output på både laptop-skærmen og den tilsluttede VGA-skærm på samme tid.

Min testing-filosofi

nospam@example.com (Troels Henriksen) — Mon, 19 Feb 2007 22:56:58 +0100

Nu synes jeg efterhånden jeg har nok erfaring med skrivning og vedligeholdelse af test-suiter til middelstore programmer, til at jeg på den vanlige vis kan eksponere mine holdninger og meninger om emnet på denne blog. Unit testing er jeg ikke den store tilhænger af - unit testing er alt for baseret på infleksible retningslinjer, og skaber et alt for stort overhead i forhold til hvad jeg får ud af mine tests. Tag som eksempel - jeg har i den seneste uge skrevet nogen tests der tester diverse funktioner i forbindelse med Lisp-syntax parseren i Climacs. Disse funktioner er afhængige af at et større generelt framework fungerer korrekt, for slet ikke at snakke om at de også tester at selve parseren parser korrekt. Ifølge unit-testing-metodologien skulle jeg teste hver funktion isoleret (i virkeligheden hver enkelt klasse, men det giver ikke mening når objektsystemet, som CLOS, er metode-fikseret og ikke klasse-fikseret), og producere mock-objekter som overholder det offentlige interface, men derudover blot producerer dummy-resultater. Det skulle sikre at hver enkelt test kun tester ét eneste aspekt af den samlede kodebase - en enkelt funktion, i dette tilfælde. Jeg må indrømme at jeg ikke kan se den store idé i dette, og jeg bruger derfor rigtige objekter, klasser og funktioner i mine tests. For mig fungerer test-suiten primært som en regressionstest, og selv hvis vi ser bort fra det massive overhead som det ville kræve at lave mock-objekter for hele den stak af funktionalitet de testede funktioner afhænger af, ville jeg aldrig ende med at opnå mere dækkende tests, end med min nuværende ad-hoc testing. Det betyder måske at en fejl i en funktion kunne komme til udtryk i at en urelateret test fejler, men det er ikke et problem, som jeg ser det. Når man først er klar over at en fejl eksisterer, er det ofte ret nemt at spore, og test-suiten har opfyldt sit primære mål, nemlig at rejse et flag om at programmet som helhed ikke fungerer korrekt. Jeg går meget mindre op i om den enkelte funktion er korrekt, end jeg går op i om hele programmet kan arbejde sammen (og logisk følger førstnævnte af sidstnævnte). Derfor forsøger jeg så vidt muligt at skrive mine tests, så de kræver at så meget som muligt af programmet fungerer korrekt, for at testen er succesfuld. Interaktionen mellem delene i et program, er nok en af de ting som oftest kan forfalde med tiden, og derfor finder jeg det fjollet at bruge ekstra energi på at undgå at teste disse interaktioner i ens test-suite.

Optimering i højniveausprog

nospam@example.com (Troels Henriksen) — Sun, 11 Feb 2007 23:32:00 +0100

Dette blog-indlæg gør mig glad fordi det viser hvordan ydelse kan komme fra de former for inferens en compiler kan udføre omkring højniveausprog, i stedet for at delegere det ud til programmøren at lave mikrooptimeringer. Det viser hvordan vi har en reel chance for at gøre højniveausprog (nok især de statiske funktionsorienterede) bedre ydende i det almene tilfælde end traditionelle super-ydelses-sprog som C. Efterhånden som vores viden om automatisk optimering vokser, vil begrænsninger i hvad sprogene garanterer nok betyde mere og mere for hvor meget der kan optimeres, og det vil ramme især C hårdt, da compileren ikke rigtigt kan regne med noget som helst.

Reformatterings-cirkusset

nospam@example.com (Troels Henriksen) — Wed, 31 Jan 2007 00:01:58 +0100

Normalt ville jeg ikke tage mig af hvordan folk (mis)bruger deres computere, men det er lang tid siden jeg har blogget, og jeg kom næsten til omtrent at love at skrive et indlæg hvori jeg på diskret vis kritiserer en unavngivnet person, så here goes. En af de ting jeg erindrer fra da jeg brugte Windows, og en ting som jeg stadigvæk observerer på Internettet, er at mange teknisk vidende brugere ofte reformaterer deres maskine (i virkeligheden, reformatterer (system)filsystemet på deres harddisk(e), men herefter blot refereret til som "formattering af maskinen") og geninstallerer styresystemet. Dette er til tider nødvendigt - Windows er karakteristisk for at kunne ende i en tilstand af næsten total infunktionalitet, hvor det er markant nemmere at rydde systemets tilstand og starte forfra, end at forsøge at uddrive de onde ånder som har besat systemet. Da jeg brugte Windows var 4-5 måneder en rimelig levetid for en installation, og det var nærmest forventet at man benyttede sig af reformattering for at løse tekniske problemer (om folk der vælger denn løsning vitterligt er "teknisk vidende" skal jeg lade gå ubesvaret). Min nuværende styresystemsinstallation, Gentoo GNU/Linux, er fra 1. januar 2004, og har lært mig et og andet omkring glæderne, eller manglen på samme, ved hyppige formatteringer.

Et af de mest meningsløse argumenter jeg har hørt som forsvar for hyppig formattering er, at det skulle give en bedre backups. Hvis man konstant formatterer sin maskine ville jeg da ellers mene at man til sidst bliver træt af at tage fuldt dækkende backups, og begynder at sjuske ("det der har jeg ikke ændret på siden sidst!"), eller begynder at smide ting væk som man ikke umiddelbart kan se hvad man skal bruge til (disse ting får man ofte lyst til at se på adskillige år efter, noget jeg selv har oplevet for nyligt). Den idéelle løsning er naturligvis at gemme al ens data på en seperat partition, eller fysisk disk, hvis man er voldsom, og nøjes med at formatere det filsystem som selve styresystemet, og måske programmer, er installeret på. Men det er måske for kompliceret...

Et andet argument er at man holder sit system rent ved hyppige formatteringer. Det åbenlyse svar er nej, man holder det ikke rent, man udsletter og genskaber det rent. Det er ikke en løsning, det er en genstart. Computersystemhygiejne er ikke en handling, det er en process, en måde at arbejde med sit system på. Det handler om ikke at køre tilfældige programmer i non-sandboxes, og lade være med at bruge for mange unødvendige programmer (de daemons som Windows-programmer er så begejstrede for at starte tæller som "unødvendige"). En reformattering af hygiejneårsager er en falliterklæring, det er som at brænde Rom af, af renoveringshensyn.

Hvad er så de forbudne frugter som venter, hvis man undlader at lade ens system fungere som metafor for fugl Føniks? Det vigtigste er at det pludselig giver mening at bruge meget tid og energi på at tune og customize systemet så det passer til ens egen smag og arbejdsrytme. Jeg har brugt mange timer på at skrive scripts og arrangere opsætning af mit nuværende styresystem (og arbejdsmiljø), noget jeg aldrig ville have gjort hvis det skulle gøres om flere gange om året. De fleste Windows-brugere bruger ikke ret meget tid på at customize deres arbejdsmiljø, måske fordi Windowskulturen bare ikke lægger op til den slags, måske fordi de programmer de bruger ikke er synderligt velegnede til det, eller måske fordi det med så hyppige formatteringer er spild af tid. Det er lidt en skam, for et miljø opsat til ens personlige præferencer og vaner er nu en ret rar ting - det forvandler computeren til en udvidelse af ens bevidsthed, i stedet for blot at være et komplekst værktøj med et begrænset interface.

Så, for jeres egen skyld, drop det der reformatteringscirkus, lad jeres system vokse med jer, lad være med at starte forfra hele tiden. Der er heller ingen der køber nye sko, lige når de gamle er ved at være trådt til. Udøv lidt basal computerhygiejne, så bliver det pludseligt meget mere effektivt at undlade at foretage regelmæssige reformatteringer.

Blogindlæg og OOPD-eksamen

nospam@example.com (Troels Henriksen) — Tue, 23 Jan 2007 23:36:29 +0100

På fredag skal jeg til eksamen i Maskinarkitektur, og jeg terper således hårdt i denne uge for at være klar. Indtil videre har mine studier lært mig at slagskibe er alt for svage i Civilization IV, og at Oblivion stadigvæk er et rigtigt sprødt spil. Derudover har jeg læst nogle over-middel interessante blogindlæg, som jeg i mangel af kreativitet vil linke til her:

Artikel om Smalltalk's objektsystem. Smalltalk er sejt, især pga. Squeak, og idéen med at repræsentere alt som beskeder sent rundt mellem objekter er en interessant idé, som især kommer til sin ret i de store, integrerede miljøer som Smalltalk er så kendt for.
En artikel om glæden ved at programmer. Det har jeg selv tidligere skrevet om.
En artikel om images, den facilitet hvormed programmeringssprog kan forsøge at afhjælpe på defekter i moderne styresystemers konceptuelle defekter (eller forskelle).

Siden sidst er min gruppe og jeg også blevet færdige med vores eksamensopgave i Objektorienteret Programmering og Design - opgaven gik ud på at implementere en simulation af en biotop hvori finker interagerer med hinanden. Det var et overraskende interessant projekt, der var velegnet til Java-style OOP (surprise?), selvom jeg i nogle dele af programmet savnede multiple inheritance og mixins. Og i de fleste dele af programmet savnede jeg anonyme funktioner (det der fis med anonyme indre klasser giver mig skrivekrampe).

Emacs-paradokset

nospam@example.com (Troels Henriksen) — Sun, 07 Jan 2007 16:06:48 +0100

Der er visse ting, som de fleste programmører er enige om resulterer i bedre software - kommentarer, klare funktioner, minimal tilstandsmutation, unit-tests, indkapsling, osv. Emacs er interessant i den forbindelse at de fleste af disse ting ignoreres, men at det resulterende program alligevel er yderst anvendeligt, og endda let at ændre for folk der ikke er bekendte med kodebasen. Hvilke af disse facetter af traditionel softwareudvikling-best-practice er det helt præcist Emacs ser stort på?

Kommentarerne i Emacs er ikke udpræget gode, men til gengæld er hver eneste funktion og global variabel tilknyttet en docstring der beskriver dens funktion (en slags proto-Javadoc) og som kan læses fra Emacs' eget interne hjælpesystem. Men at finde ud af hvordan en typisk Emacs-funktion gør sit arbejde, i modsætning til hvad den gør, er ofte lidt mere kompliceret.
Klare funktioner er ikke noget Emacs gør noget synderligt ud af - funktionerne er ofte ganske store, og det store antal af små hjælpefunktioner der normalt karakteriserer funktionssprog er ikke at finde i meget Emacs Lisp - men det bør vel ikke undre, da Emacs Lisp ikke er synderligt funktionsorienteret i det hele taget.
Tilstandsmutation er derimod noget af det Emacs går højt op i - stort set alle Emacs-programmer er baseret på at kalde brugerkommando-lignende funktioner der flytter rundt på markøren og indsætter og sletter tekst - som en superpowered makro. Man bruger typisk noget ophæng der sørger for at skærmen ikke bliver opdateret mens dette sker, og at markørens oprindelige position bliver gendannet, for at det ikke skal virke for forvirrende for brugeren. Men at mutere skjult global data, som bufferen eller markøren, er en typisk teknik indenfor programmering af Emacs-funktioner, og det kan gøre koden noget tricky at læse. Fordelen er, at hvis man kunne udføre processen manuelt, er det ret nemt at overføre det til Emacs Lisp-kode, da man stort set bare ville kunne kalde redigeringskommandoerne selv.
Emacs har ingen unit-tests eller anden form for automatiseret testing overhovedet. Moving on...
Indkapsling a la Java og C++ er anathema i Emacs (og delvist, indenfor Lisp i almindelighed). Der er ingen sort-hvid grænse mellem interne funktioner og det eksterne interface, men derimod en kontinuerlig linje hvor funktioner går fra at være langhårede og skrøbelige, til at være mere brugerorienterede og simple. Alle funktioner og globale variable (næsten) er dokumenteret og kan bruges i Emacs Lisp-programmer, og når man skal finde en funktion til at løse en given opgave, slår man ikke op i en reference som i de fleste andre sprog, men søger i stedet i alle definerede funktioner og deres dokumentation efter de(t) nøgleord der relaterer til det problem man vil have løst. Emacs' datastrukturer er typisk simple og åbne.

Til trods for disse brud på almindelige konventioner er Emacs et utroligt stabilt og velfungerende program, og at skrive kode, der benytter sig af Emacs' store funktionsbibliotek er ganske behageligt, til trods for manglen på indkapsling og abstraktion. Det er ikke ligetil at foreklare årsagen til dette fænomen, men jeg har en vag mistanke om at det er fordi det skaber en tæt forbindelse imellem manuel tekstredigering af programmering af tekstmanipulationsfunktioner. At alle funktioner, selv de "intern", er direkte tilgængelige for alle Emacs Lisp-programmer, kan kun fungere fordi Emacs fra bunden af blev designet til at understøtte dette - alle funktioner er veldokumenterede, og hvis man vil være helt sikker på at man har forstået dem, er kildekoden kun et enkelt tastetryk væk. Emacs' arkitektur er, set fra et softwareudviklingsynspunkt, ikke synderligt elegant, korrekt eller ren, men man føler sig så herligt hjemme i den - den er super-pragmatisk og behagelig, ligesom man føler sig mere komfortabel i ens mindre-til-voldsomt rodede og beskidte værelse, end man gør i en steriliseret hospitalsgang der skinner af marmor. Tekstredigering er ofte et beskidt og hacky arbejde, og måske skaber Emacs' knapt-så-teoretisk-perfekte arkitektur et passende værktøj til en sådan opgave (det samme fænomen kan observeres i programmeringssproget Perl).

Syntaksklasser for programmeringssprog

nospam@example.com (Troels Henriksen) — Thu, 14 Dec 2006 23:20:28 +0100

For mig at se, når jeg vurderer syntaksen for et programmeringssprog, findes der tre primære klasser af syntakse (som er en total uformel klassifikation og ikke har noget med sprogteori at gøre, så lad være med at tro det har):

De strukturerede syntakse, alá Lisp og Scheme, hvor syntaksen direkte svarer til en eller anden simpel repræsentation - f.eks. et træ, og hvor den derudover er meget regulær og det er helt klart hvordan den vil være repræsenteret i hukommelsen når den er blevet indlæst.
De token-baserede sprog, der består af enkelte udelelige symboler, der kan kombineret på arbitrær eller semi-arbitrær vis, uden mange syntaktiske regler. Brainfuck er et fint eksempel, hvor alle tokens består af ét tegn, og den eneste regel for et gyldigt program er at der skal være et balanceret antal af firkantede parenteser. Et lidt mere seriøst sprog i denne kategori kunne være APL.
De grammatiske syntakse, som vi kender dem fra C, C++, Java, Haskell, mfl. Disse har alle nogle (relativt) komplekse grammatiske regler, ting som operatorpræcedens og er generelt svære at forudsige hvordan vil se ud som et syntakstræ. Til gengæld har de ofte mange syntaktiske "genveje" der kan få kode til at fremstå kort og elegant.

Når jeg vurderer et sprog opfatter jeg, stort set, alle syntakse inden for hver af de tre klasser for ækvivalent - hvis det er en grammatisk syntaks vil der være operatorpræcedens, der vil være regler for hvordan visse ting bare skal se ud, og jeg vil sandsynligvis ikke være i stand til at lave meningsfyld preprocessing på kodens parse-træ (jeg ved der er undtagelser, jf. Smalltalk der ikke har operatorpræcedensregler). Til gengæld forventer jeg også syntaktiske genveje, såsom C's array-indekserings-syntaks eller Haskell's syntaks for uendelige lister.

Hver af disse former for syntakser har fordele og ulemper - personligt hælder jeg mest til de strukturerede syntakse når det kommer til større programmer, simpelthen fordi det er langt simplere at lave intelligente editorer der kan bearbejde udtryk, når det er helt klart hvad et udtryk dækker over. Desuden gør den regulære syntaks det muligt at lave effektiv preprocessing uden alt for meget smerte (C++ tilbyder template metaprocessing, der er en svagere og mere smertefuld implementation i en grammatisk syntaks). Dog ville jeg til et on-and-off scriptsprog til små opgaver nok foretrække et sprog med en grammatisk syntaks propfyldt med genveje - for der er det ikke sandsynligt at jeg vil gå ud over hvad sproget direkte er designet til, og derfor ikke have behov for mange af de faciliteter som en struktureret syntaks tilbyder.

Bootstrapping og design af højniveau-sprog

nospam@example.com (Troels Henriksen) — Sat, 09 Dec 2006 22:35:01 +0100

I dag læste jeg en interessant historie om hvordan Squeak-miljøet blev til, og hvordan det er designet. Udvikling og vedligeholdelse af disse højniveau-systemer interesserer mig meget, fordi det for mig at se næsten er magi at de overhovedet kan fungere. Smalltalk, der er et meget højniveau-sprog, bruges til at skrive sin egen virtual machine - det er respekt. Generelt synes jeg at sprog, der afhænger af komplekse runtime-miljøer, har nogle fascinerende detaljer omkring porting til nye systemer, og grundlæggende bootstrapping - hvor C på triviel vis omdannes til totalt flad og statisk maskinkode, så kræver det lidt mere at få et Smalltalk-image op og køre. Ydermere kan der opstå interessante komplikationer og detaljer når man laver selv-kompilering med den slags runtime-systemer - CMUCL, den klassiske frie implementation af Common Lisp, er berygtet for at være ekstremt kompliceret at kompilere, og er kendetegnet ved at nye kompileringer af CMUCL arver karakteristika fra den CMUCL det bliver kompileret med - OOP go home, det her er ægte inheritance! En af de mest underholdende konsekvenser af dette, som jeg har læst om, er at man, når man porter CMUCL til en ny platform - det være sig en ny maskine, styresystem eller bare nyt sæt libraries - anbefales at rekompilere CMUCL med sig selv et par gange, bare lige for at få ryddet ordentligt op og få reduceret antallet af compiler-advarsler.

Hvorfor er der...

nospam@example.com (Troels Henriksen) — Thu, 28 Sep 2006 14:38:36 +0200

... ikke flere sprog der har valgt at navngive deres standardfunktioner efter IBM 704-instruktionssættet? Når man ser på de sprog der følger denne designfilosofi må man da formode at det er en god idé? Det kan da ikke være værre end at bruge glorificeret PDP-11 makroassembly?

Sprogfleksibilitet versus værktøjer

nospam@example.com (Troels Henriksen) — Sun, 03 Sep 2006 20:56:21 +0200

I dag så jeg denne halvgamle posting på en af Squeak's mailing-lister (Squeak er et Smalltalk-miljø, prøv det, hvis du ikke allerede har - det kan være noget af en øjenåbner og er sjovt at lege med). Beskedens kerne er at Smalltalk's stringente holdning til hvordan et computerprogram skal designes og struktureres, betyder at man kan bruge utroligt avancerede værktøjer til at skrive, og analysere, Smalltalk-kode. Idet programmer altid er organiserede i objekthierarkier, kan værktøjerne gå ud fra nogle grundlæggende formodninger, der gør at de har let ved at gennemskue koden. Det hjælper naturligvis også at Smalltalk-miljøer typisk ikke bruger filer, og at man bare siger at man vil redigere i en given metode for en given klasse, og så får et editor-vindue med kildekoden. Så behøver værktøjerne ikke beskæftige sig med inddeling af koden i filer og den slags pjat.

Common Lisp er lidt anderledes - der har man ubegrænset fleksibilitet, selv den grundlæggende syntaks kan ændres, hvis man skulle nære trang til dette. Jeg har selv oplevet konsekvensen af dette i forbindelse med mit arbejde på Climacs - Lisp er (retteligt) berømt for sine muligheder for introspection - at se ind i, og ændre, programmets tilstand, mens det kører, men lige så nemt som det er at analysere kørende kode, ligeså besværligt er det at analysere koden, mens den endnu blot er tekst i et editorvindue. Når syntaksen kan redefineres efter forgodtbefindende, er det ofte umuligt at vide hvordan et givent symbol og bruges, og derfor lave rigtig intelligent symbolfuldføring (alá Microsoft's IntelliSense). Man kan naturligvis lære editoren om hvordan den skal opfatte specifikke makroer/readermakroer, men det er umuligt at gøre det generelt for alle makroer programmøren kunne finde på at definere, med mindre man rent faktisk implementerer en halv compiler i kode-analyse-modulet.

Er det så værd at ofre sprogfleksibilitet, for til gengæld at få bedre værktøjer? Det afhænger af situationen - det er nok nødvendigt at have visse begrænsninger i sproget, for at gøre det muligt at have intelligent værktøjer i det hele taget. Men generelt er jeg af den oplevelse at værktøjer altid kan skabes, ændres og forbedres ("hvis en compiler kan gøre det, så kan et eksternt redskab også"), mens man som oftest er låst fast på hvad sproget kan, så derfor er det vigtigst at sørge for at sproget er fleksibelt og kraftfuldt til at begynde med.

Denne side bør I allerede kende

nospam@example.com (Troels Henriksen) — Fri, 11 Aug 2006 00:06:55 +0200

For en god ordens skyld - hvis I ikke allerede kender til thedailywtf.com, så gør I det nu. Det er en side hvor der bliver postet eksempler på hvorfor det ikke kræver ret meget kompetence at få et job i computerindustrien, og hvor grimt man rent faktisk kan skrive Visual Basic-kode.

Og så har jeg desuden også fundet nogle projekter der kan holde mig beskæftiget resten af ferien. Det er jo godt nok.

Edit: Indlæg version 2.0, link fikset.

Eksempel på CLIM

nospam@example.com (Troels Henriksen) — Fri, 16 Jun 2006 11:58:00 +0200

For et stykke tid siden skrev jeg om CLIM og var især begejstret for presentation types. Det er jeg stadigvæk, og for at konkretisere hvorfor jeg synes de er så geniale, vil jeg nu komme med et eksempel på hvorledes jeg har brugt dem i løbet af de sidste uger.

Jeg arbejder i min fritid på Climacs - en næstegenerations Emacs skrevet i Common Lisp. Derudover arbejder jeg også på CLIM-desktop - integration mellem en række forskellige CLIM-programmer. I CLIM-desktop har jeg skrevet kode der udnytter presentation types på en ret interessant måde - en standard presentation type er symbol, som bliver brugt når et program ønsker at vise brugeren et almindeligt Lisp-symbol. Ved at definere en presentation command translator har jeg kædet alle presentations af denne typer sammen med en kommando, der får Climacs til at redigere definitionen af symbolet. Resultatet af dette er at når et program producerer output, kan det blot sige at et givent stykke output repræsenterer et givent symbol, hvorefter brugeren til hver en tid kan holde ALT inde, klikke på symbolet, og blive taget til den fil, og position i filen, hvor symbolets funktion, klasse, type, osv., bliver defineret. Dette sker fuldstændigt uden at applikationsprogrammøren skal tænke nærmere over det, han kan blot gå ud fra at miljøet giver brugeren nogle relevante interaktionsmuligheder for en given presentation type (selvom programmet selvfølgelig også kan definere sine egne).

På samme måde er andre presentation types også kædet til kommandoer - filnavne giver mulighed for at åbne filen, klassenavne mulighed for at redigere i filen, og kommandoer og kommandonavne mulighed for at redigere kommandoens definition. Det er ret komfortabelt at bruge et miljø hvor man, hvis man pludselig opdager en bug i en kommando, som regel bare kan holde ALT inde og trykke på kommandoen, og fikse den. Og denne funktionalitet kommer fuldstændigt gratis for applikationsprogrammøren, hvor det i de fleste toolkits ville være ganske besværligt at implementere.

Go with the control-flow!

nospam@example.com (Troels Henriksen) — Mon, 15 May 2006 20:14:06 +0200

I dag er fælleshadet rettet imod en ellers typisk blogpost med titlen Signs You're a Crappy Programmer (and don't know it). Jeg forstår inderligt ikke hvorfor den har fået så meget opmærksomhed, så mange kommentarer og en så prominent placering på had-vejviserne Digg og Reddit. Nuvel, hvem er jeg at skulle gå imod blogosfærens strømninger (wow, det ord får mig til at føle mig helt metroseksuel og Web 2.0-sej - betyder det at jeg kan få en bog udgivet hos O'Reilly?): Jeg må omgående ytre min mening om indlægget fra min egen piedestal.

De fleste af indlæggets punkter er ded sædvanlige, korrekte, men efterhånden noget almindelige, kritik af begrebet enterprise ready og den sædvanlige parodi af enterprise programmøren. Der er dog to punkter som jeg synes er interessante, og som jeg tilfældigvis går meget op i, og det er de to punkter der omhandler længden af funktioner og antallet af exit points i en funktion.

Jeg er tilhænger af funktionsorienteret programmering, og opfatter derfor funktioner som små, isolerede bidder, der udfører beregninger eller handlinger. Det betyder også at jeg opfatter funktioner fra et matematisk standpunkt, og forsøger at minimere, eller eliminere, side-effekter og funktioners afhængighed af miljøet. Jo større funktioner er, desto sværre er det at undgå side-effekter, derfor foretrækker jeg store mængder små funktioner, der hver løser en enkelt opgave, og som idéelt set ikke har sideeffekter, samt en større interface-funktion, der organiserer kaldene til beregningsfunktionerne og udfører nødvendige side-effekter. De små side-effekt-frie funktioner tillader mig også at bruge matematisk logik til at ræsonnere omkring dem - f.eks. verificere deres korrekthed eller ændre på hvordan de bliver kaldt. Kernen i denne organisering af funktioner er at det som oftest er lettere at fejlrette, eller verificere, 3 funktioner á 10 linjer, end én funktion på 25 linjer.

Derfor er jeg som udgangspunkt også imod funktioner med mange exit points - eller helt præcist, jeg er imod funktioner med mange eksplicitte exit points. I funktionsorienterede sprog har en funktion, eller et udtryk, blot den returværdi, som sidste udtryk i funktionen har - returværdien, og exit pointet, bliver altså automatisk udledt af hvornår funktionen simpelthen ikke har mere kode at køre. Det er for mig den optimale løsning, og samtidigt en gylden regel man kan følge stort set hvor som helst: Lad control-flowet fremgå af logikken. Hvis man har behov for tidlig exit, så bør logikken formes så denne tidlige exit er en del af den, ikke ved at lave vilkårlige exits hid og did.

Climacs pr0n og jubilæum

nospam@example.com (Troels Henriksen) — Sun, 30 Apr 2006 22:34:59 +0200

For præcist et år siden gik jeg i gang med at lære Common Lisp, det sprog, der sidenhed er blevet mit absolutte favoritsprog (og som tilmed var med til at introducere mig til rigtig datalogi).

Jeg har i løbet af året arbejdet på en række mindre ting - mindre, fordi jeg ikke har været tilstrækkeligt familiær med sproget og dets redskaber til at overkomme større opgaver, men i løbet af de seneste måneder har jeg alligevel været involveret i et større projekt: Climacs - en moderne implementation af en Emacs-editor i Common Lisp. Kombineret med CLIM-Desktop er Climacs allerede et udemærket udviklingsmiljø til Common Lisp - og det er allerede begyndt at se ganske fancy ud (Climacs pr0n!).

Webprogrammering

nospam@example.com (Troels Henriksen) — Mon, 17 Apr 2006 23:20:34 +0200

Jeg har før skrevet om min datalogiundervisning på gymnasiet, hvor jeg har beskæftiget mig med så fantastiske teknologier som VBA og VB.NET. Nu er vi startet på webprogrammering, og min lærer har i et svagt øjeblik ladet os bruge et hvilket som helst serverside-sprog som vi måtte ønske. Jeg har aldrig brudt mig synderligt om webprogrammering - behovet for at kæmpe med diverse browseres fejlfortolkninger og det generelt meget primitive interface har genereret mig en del. Jeg håber at dette bliver et mindre problem hvis jeg finder et tilstrækkeligt interessant webframework - jeg har kigget på Ruby on Rails, men var ikke synderligt imponeret. Det lignede mest af alt en autogenerator til databaseinterfaces... ret uinteressant. Og så er det i Ruby.

I stedet kigger jeg på UnCommon Web, der også har den fordel at der er utroligt lidt dokumentation, så det kan blive et helt eventyr at lave noget i det. Måske kan det give noget så dødssygt som webprogrammering en smule spænding.

Edit: Holy shit, UnCommon Web er fantastisk fedt.