Anders Hejlsberg: Sådan styrer jeg C#-udviklingen

Anders Hejlsberg er i dag mest kendt for at have ansvaret for sproget C# hos Microsoft, men stod også tidligere bag kendte programmeringssprog. I 1980’erne skrev han Turbo Pascal, og i 1990’erne var han chefarkitekt bag Delphi hos Borland. Siden 2000 har han stået i spidsen for Microsofts C#, og i begyndelsen af oktober kunne han præsentere et helt nyt projekt, han også har været ansvarlig for: Typescript, der er et værktøj til Javascript-udvikling.

Version2 fik et interview med en af Danmarks mest kendte udviklere, da han var forbi Aarhus til Goto-konferencen tidligere i oktober.

Da du gik i gang med C#, havde du så forestillet dig, hvor udbredt det ville blive?

»Nej, det havde jeg ikke forestillet mig. Det ville også være alt for meget hybris at gøre det. Egentlig er jeg også selv blevet forbavset over, hvor stort det er blevet. Det kan jeg kun være glad for og stolt af, men det har aldrig været det, der var spørgsmålet. Det handlede om at lave et godt stykke teknisk arbejde. At forstå, hvad programmører har brug for, og lave det så rent som muligt i implementeringen af det. På mange måder er jeg en meget pragmatisk programmør. Og det er måske derfor, vi er kommet så langt, som vi er kommet.«

»Jeg var rimelig ny hos MS, da vi startede – havde været der et par år, da vi gik i gang med C# – og jeg tror ikke rigtig, jeg havde forstået, hvor meget power der er i MS, når de først begynder at fyre med alle cylindre. Det var helt utroligt at se forskellen i forhold til Borland, som jeg kom fra. Jeg var bare heldig på mange måder, at være det rigtige sted på det rigtige tidspunkt, men selvfølgelig også få gjort det rigtige stykke arbejde.«

For hver gang der skal en ny version på gaden, bliver det mere kompliceret, for det er ikke på tale at fjerne funktioner i C#, forklarer han.

»Når først du bliver så etableret, som vi er blevet, er det helt klart en udfordring at få lavet en helt ny compiler, som er 100 procent baglænskompatibel med alt, hvad der er lavet tidligere. Det er selvfølgelig altid meget nemmere at lave version 1, fordi der ikke er noget, den skal være kompatibel med, men når du har en million programmører, som bruger dit sprog hver dag, og som får lavet en farlig masse kode, så skal du være baglænskompatibel. «

»Du kan aldrig fjerne noget. Hvis du fjerner noget, så er der helt klart noget kode derude, der lige brugte den feature, og så falder det på gulvet. Så der er kun én vej frem, nemlig at lægge mere oven på.«

Må som regel sige nej

Det betyder, at Anders Hejlsberg må være ret striks med, hvad der kommer ind af nye funktioner.

»Udfordringen er at være meget sikker på, hvad du lægger ind af nye ting, og jeg bruger mere tid på at sige nej end på at sige ja. Du kan ikke gøre det til en køkkenvask, hvor du skovler alt op, som folk beder om, for så bliver det noget miskmask på ingen tid.«

»Du skal være meget bevidst om, hvad der er hvad. Hver eneste feature du propper ind, skal genvinde i øget produktivitet, den kompleksitet, den tilfører. Der er masser af features, som giver bedre produktivitet, men som ikke genvinder de minuspoint, du får i kompleksitet. Så udfordringen er at finde den rigtige balancegang.«

Hvordan tager I den beslutning?

»Det handler om at have fingeren i jorden nok steder. Og når du selv er programmør, kan du føle, om det er rigtig godt, eller lidt for specifikt til én bestemt problemstilling. Jeg kigger meget ofte efter løsninger, som er en klasse af problemløsning, i stedet for at være en instans af problemløsning. Hvor der er forskellige instanser, som bliver løst i den klasse af problemer.«

Sponseret indhold

Dansk IP-telefoni rider højt på den buldrende Teamsbølge

IT-projekter

»Vi vil helst lave sprogfeatures, som løser mange problemer på én gang i forskellige domæner. Det er en indikator af, at vi er på det rette metaniveau i sproget, hvorimod hvis vi er nede og proppe en masse lad os bare sige SQL-syntaks ind i sproget, fordi der er mange, som skriver databaseprogrammer i C#, så har vi fået skabt et rodet hjørne, som ikke føles rigtigt, når du skriver klient-applikationer. Man skal være forsigtig med at binde sig til ting, der er for domænespecifikke.«

Bruger I også empiriske data fra undersøgelser af, hvordan værktøjerne bliver brugt?

»Det gør vi. Vi har forskellige portals, hvor alle vores brugere kan stemme på, hvilke features der er mest vigtige for dem, og det kigger vi meget på. Og vi kigger på, hvad der sker i andre sprog i industrien, og hvad der sker i forskellige application patterns, som pludselig bliver vigtigere end andre.«

Nye funktioner må ikke bare løse et lille problem

»Noget af det er også ting, som ingen egentlig havde bedt om. For eksempel med asynkron programmering. Vi har faciliteter, som gør det muligt at gøre det, for eksempel lambda-functions. Men vi vidste også godt, at det hurtigt blev for komplekst. Så selvom ingen decideret bad om at få funktionen på denne måde, var der folk, som beklagede sig over, hvor komplekst det var.«

»Det sker også, at folk kommer og siger: ’Kan du ikke lave sådan og sådan?’. Så viser det sig, at de har fundet på en løsning på et problem, og måske kan du ikke lide løsningen, men kan godt se problemet. Så må du starte forfra og lave den rigtige løsning. Nogle gange beder folk om en bestemt ting, men vil egentlig bare have løst det problem, de har.«

Er det så i sidste ende din beslutning, hvad der skal med?

»I det sidste ende er det et team, der tager beslutningerne. Men hvis vi så ikke kan blive enige, er det mig, som skal sige: ’Nu går vi den vej i stedet for den vej’. Men det sker jo stort set aldrig. Når vi så har valgt at gå én vej, bliver det mit job at pløje et spor for den vej. Når folk siger: ’Det har vi ikke tid til, vi skal bruge flere ressourcer’, så er det mit job at være sikker på, at vi kan få dem.«