Engang i min ungdom cyklede jeg sammen men en af mine venner. Hans kæde sad løs, og et par gang under turen hoppede den af, og han skulle hver gang bruge et minuts tid på at sætte den på igen. Jeg spurgte min ven, om ikke han skulle se at få strammet kæden. "Nej", sagde han, "for det er så dejligt nemt at sætte kæden på igen, når den er så løs".
Jeg ser lidt på samme med manges tilgang til programmering: Det kan være fristende at bruge et programmeringssprog med svage eller dynamiske typer, for det er så nemt at lave et lokalt fix til de problemer, man hele tiden støder på. Med et stærkt og informationsrigt typesystem skal man i reglen lave mere arbejde up front for at få noget, der kører, men til gengæld undgår man senere at skulle bruge tid på at rette mange små fejl. Så jeg foretrækker selv det sidste -- undtagen til små programmer (op til 50 linjer), hvor 100% korrekthed ikke er vigtig (f.eks. små one-time scripts).
Samme holdning ser man hos Tim Chevalier, en af folkene bag sproget Rust, som Mozilla og Samsung vil bruge til en ny browsermotor. Han erkender, at man ved at bruge Rusts ownership types (en variant af lineære typer) skal tænke sig mere om, når man programmerer, og at man ofte skal bruge tid på at få sit program gennem typecheckeren. Men man gør det mere eksplicit, hvordan ens pointere opfører sig (og det på en måde, så oversætteren kan verificere, at du ikke deallokerer for tidligt), og dermed forhindrer man, at små tanketorsk slipper igennem til testfasen, og samtidigt sikrer man bedre performance end i et sprog med managed pointers (GC).
Man kan gå stort set arbitrært langt med krav om statisk verifikation i sprog, helt op til at en komplet specifikation af in/out relationen skal verificeres statisk. Det er nok at overdrive lidt, så kunsten er at finde en passende balance mellem nyttigheden af de verificerede egenskaber og den ekstra byrde, man pålægger programmøren for, at oversætteren skal kunne verificere disse egenskaber. Traditionel statisk typesikkerhed har (efter min mening) for længst vist sin værdi, men den egenskab, der sikres ved dette, er langt fra tilstrækkelig til at fange alle potentielle køretidsfejl. De resterende fejl kan et sprog så enten ignorere ved at gøre opførslen udefineret (som i C og C++) eller ved at lave køretidscheck, som enten standser programmet med en fejlmeddelelse eller laver en exception, der kan fanges af det kørende program. Nogle potentielle køretidsfejl (såsom overflow af tal) kan være så svære at verificere sig ud af, at køretidscheck er uundgåelige, men for eksempel dereference af nulpegere, pegere til deallokeret lager eller visse former for space leaks er det ikke urimeligt at verificere sig ud af. Det kan (ligesom statisk typesikkerhed) kræve lidt ekstra disciplin, når man programmerer og lidt ekstra tid under oversættelsen, men det betaler sig i reglen alligevel i form af færre fejl og bedre performance (og vedligeholdbarhed).
...men det er dyrt at lave god journalistik. Derfor beder vi dig overveje at tegne abonnement på Version2.
Digitaliseringen buldrer derudaf, og it-folkene tegner fremtidens Danmark. Derfor er det vigtigere end nogensinde med et kvalificeret bud på, hvordan it bedst kan være med til at udvikle det danske samfund og erhvervsliv.
Og der har aldrig været mere akut brug for en kritisk vagthund, der råber op, når der tages forkerte it-beslutninger.
Den rolle har Version2 indtaget siden 2006 - og det bliver vi ved med.
