Intervju med en guru
Om fremtiden og sikkerhet
Litt bakgrunnsinformasjon om Anders Heljsberg
Anders Heljsberg er virkelig et stort navn innenfor utvikling. Han begynte som student i Danmark, men landet ble snart for lite for Anders. Han står blant annet bak utviklingen av Turbo Pascal på 70-tallet. Anders stoppet midlertid ikke der - han jobbet fram til 1996 hos Borland, der han var ansvarlig for utviklingen av Delphi. Da ble han hyret inn av Microsoft, hvor han i dag leder selskapets C#-satsning. Han er også en sentral medarbeider på Microsofts .NET-plattform, og er en av kun 16 ansatte som har fått tittelen "Distinguished engineer".
HWB.no: Jeg tenkte vi kunne starte med et lite blikk inn i fremtiden. Hvilket språk tror du blir ”fremtidens språk”, og hvilke grunner er det til det?
Anders: Jeg vet ikke hvilket det fremtidige språket blir, men jeg vet at det blir fremtidige språk. Det har vært mange språk, og det kommer til å komme mange språk fremover. Noe vi ser i C#-prosjektet er at vi bygger på en rik tradisjon av C og C++. Jeg tror at vi lærer noe nytt for hver runde. Og jeg tror noen av de tingene som det er verdt å lære seg i dag, vil vi se i bruk i fremtiden. For eksempel det å gjøre språkene mer deklarative, og mindre imperative. I dag, når vi skriver programmer, er de veldig imperative. Det er mye snakk om å si ”hvordan du vil ha det gjort”. For å ta et eksempel: ”Ta ”i”, legg til 2, flytt det hit bort”, og så videre. I stedet burde vi snakke om ”hva du vil ha gjort”: Jeg vil ha dette prosessert slik eller slik. I større og større grad vil vi se deklarativ programmering, fordi det er begrenset hvor langt du kan gå med imperativ programmering. Jeg tror vi allerede har de fleste brikkene på plass, og jeg ser ingen videre fruktbar utvikling i den retningen. Når det gjelder deklarativ programmering er det derimot mye man kan gjøre. Og dette ser vi mye av i dag, innenfor såkalt utvikling av domene-spesifikke språk (DSL-er). Dette kan være bedriftssystemer, SQL og andre spørringsspråk.
En interessant utfordring er derfor å sørge for at programmeringsspråkene ”modnes”, og dermed blir rike nok til at man kan lage DSL-ene innenfor språk som for eksempel C#. Og dette er et eksempel på ting jeg er veldig interessert i å jobbe videre med. Og hvilke grep vi trenger å gjøre for at C# blir rikt nok til at vi innenfor dette kan utvikle et spørringsspråk, ”business processing” språk eller en ”rules engine”.
Mange av brikkene er som sagt allerede på plass, men det mangler også noen. Og i denne sammenheng er det interressante steder vi kan hente ideer fra. Funksjonelle programmeringsspråk som ML og Haskell har mange spennende egenskaper som kunne bidra på dette området. Dette er derfor det jeg tror vil karakterisere programmeringsspråk om, la oss si, fem til ti år. Språkene vil semantisk sett være rikere og være mer ekspressive, slik at du kan gjøre de domene-spesifikke tingene uten å måtte bruke anførselstegn slik man må i SQL-spørringer. En større integrasjon mellom disse to verdenene kan føre til spennende muligheter.
HWB.no: Tror du man når et punkt der det er ”farlig” å blande imperative og deklarative programmeringsstiler?
Anders: Jeg tror ikke det blir ”farlig”, men at det tvertimot kan være fruktbart å gjøre dette. Jeg tror dette er måten vi kan gjøre programmerere mer produktive på.
HBW.no: Vil vi se grunnleggende endringer i syntaksen i språkene?
Anders: Syntaks er i utgangspunktet bare syntaks. Eller det kommer forresten helt an på hvem du spør. Spør du en akademiker, er syntaksen bare den nedskrevne semantikken. Og semantikken er det interessante. Jeg har en tendens til å følge begge.
Noen vil fortelle deg at syntaks ikke har noe å si. Jeg mener det tvertimot har mye å si, fordi det hjelper deg til å tenke og resonnere rundt koden. Dersom det er for mange parenteser eller lignende slik mange klager på med LISP, er det vanskelig å se for seg koden klart. Dersom syntaksen er uforståelig, blir det vanskelig å se noe for all støyen. Når det er sagt er det viktig å få syntaksen riktig, men du starter med det semantiske. Det er her man, semantisk sett, må legge til nye egenskaper.
HWB.no: Sikkerhet og programmeringsspråk, hvordan er disse relatert til hverandre? Som et tilleggspørsmål til dette, hvordan vil .NET versjon 2.0 være ”sikrere” enn versjonene 1.0 og 1.1?
Anders: Måten sikkerhet og programmeringsspråk er relatert på er som følger: Noen ganger gjør vi feil eller glemmer å tenke på visse ting som kan medføre en sikkerhetsrisiko. Visse programmeringsspråk lager sterke garantier for hva man kan gjøre og for hva som sjekkes i når programmet kjøres, mens andre har løsere garantier for dette. Eldre språk som C eller C++ lager for eksempel ingen garantier for sjekking når man indekserer inn i et array, f.eks. om man indekserer utenfor grensene til det arrayet. Om man ikke setter opp koden riktig og hvis man ikke eksplisitt gjør alle grensesjekkene alle steder, åpner man opp for sikkerhetshull. Dette er helt klart ikke ønskelig.
Kontrollerte kjørbarhetsmiljøer, som .NET, har noen iboende fordeler i forhold til de eldre programmeringsspråkene. .NET er i sin natur mer sikker fordi vi for eksempel har gjort alle grensesjekker for arrayer standard. Disse kan du ikke skru av, og du vil derfor ikke opplever såkalte buffer overrun-problemer i .NET.
Et annet problem man ofte ser er løse pekere (”stray pointers”) eller ”pointer overruns”. I .NET har vi forsøkt å tette disse hullene. Dette ble ikke bare gjort av sikkerhetshensyn, men også for å gjøre applikasjoner mer robuste. Klarer man å fjerne problemene, klarer man også å fjerne sikkerhetshullene. Derfor er kontrollert kode mer sikkert, simpelthen fordi det ”lever” i et mer robust designet miljø.
HWB.no: Du frykter ikke at dette kan virke som en hindring for programmerere?
Anders: Nei, det tror jeg ikke. Det er klart det medfører visse restriksjoner – alt har en pris. I dette tilfellet vil det være en liten pris å betale i kjørehastighet. All grensesjekkingen tar tid, men det positive ved dette er at «Just in time»-kompilatorer kan ”se” mønstre i dette, og forutse hva som kommer til å skje. Slike smarte ting kan man gjøre for å få opp prosesseringshastigheten, samtidig som man har en sikker og robust infrastruktur.
Tilbake til spørsmålet om hva .NET versjon 2.0 gjør bedre enn versjonene 1.0 og 1.1.
For det første fokuserer vi mye på sikkerhet i våre utviklingsprosesser, noe som har endret seg mye siden jeg kom til Microsoft for åtte år siden. På den tiden var det ikke mye snakk om sikkerhet, og dette er derfor et ganske nytt fenomen. Vi har måttet endre måten vi tenker på omkring utvikling av programvare. Et eksempel er at vi i vår utviklingsprosess nå alltid legger inn en sikkerhets-milepæl, hvor bokstavelig talt hele avdelingen fokuserer på sikkerhet. Dette innebærer at vi forsøker å knekke koden, kjøre verktøy for å bryte sikkerheten, og så videre. Dette er i grunnen en spesiell prosess. Det finnes ingen matematisk formel man kan benytte i dette arbeidet. Så til syvende og sist dreier dette med seg sikkherhet mye om mennesker med et skrudd syn. Gjerne intelligente og smarte folk, men ført på villspor, som bruker sin tid på å finne ut hvordan de kan ødelegge livet for andre. Derfor blir søkingen etter sikkerhetshull en fantasirik og spennende prosess, som det som sagt ikke finnes noe verktøy for.
En annen ting man oppdager når man jobber med dette er at sikkerhet ikke er en bryter som man kan skru av eller på. Det er her snakk om en balanse mellom fleksibilitet og egenskaper på den ene siden og uleilighet og mangel på egenskaper på den andre. Det ultimate sikre system er jo et system som er skrudd av! Det gjør til gjengjeld ingenting for deg. I den andre enden har man det helt åpne, men sårbare systemet. Et eller annet sted i mellom disse ytterpunktene finnes det systemet som vi må kjøre på. Vi blir nødt til å endre mange av våre standarder til for eksempel ”slå av makroer”, men dette blir tungvint for brukerne. Plutselig er et regneark som var lettvint å bruke, blitt vanskelig å bruke. Vi må alle dessverre betale for økt sikkerhet i form av mindre brukervennlighet.
XAML og Visual Studio
HWB.no: Når det gjelder XAML-prosjektet: Hvilke egenskaper er de mest fremtredende med dette språket?
Anders: Spesifikt sett blir XAML brukt som det XML-språket vi benytter for å beskrive visuelle brukergrensesnitt for Avalon-prosjektet. Sistnevnte er en del av Longhorn, neste versjon av Windows, og blir den neste generasjon GUI-system.
Dette skal gjøre oss i stand til å bygge en helt ny klasse visuelle applikasjoner som er mye mer flytende og dynamiske i sin oppførsel enn det vi har i dag. XAML er et persistens-format for det visuelle brukergrensesnittet i Avalon. Det interessante med XAML er at du kan tenke på det som et XML-basert persistens-format for objekter. Det som definerer alle tag-navn i XAML, for eksempel <button, size=1>, <textpanel>, og så videre. Det er faktisk en direkte avbildning mellom XML og klassenavnene du har for de underliggende XAML-klassene. Så ”button” blir bokstavelig talt navnet for det tilsvarende klassenavnet. Dette gjør at XAML blir et utstrakt persistens-format – når du oppretter nye klasser så har du i det samme opprettet nye element-navn. Og attributtene er egenskapsnavn, der attributtene avbildes mot egenskaper (properties). Eksempelvis blir ”size” en egenskap ved ”button”-klassen.
Så XAML i bunn og grunn et XML-basert persistens-format. I dette tilfellet benyttes dette i det visuelle domenet, og det er derfor slik at navnene på elementene er UI-elementer. De kan i grunnen være hva som helst. Språket er derfor mer generelt enn det vi benytter det til per dags dato, og det blir derfor i sin natur utvidbart.
HWB.no: Så du tror XAML og Avalon vil påvirke utviklingsprosessen? Og på hvilken måte vil dette i så fall skje?
Anders: Det tror jeg helt sikkert de vil komme til å gjøre! De vil gjøre deg i stand til å bygge en helt ny klasse med klient-applikasjoner som vil kunne gjøre nytte av den grafiske arkitekturen og GPU-enes enorme kraft. Denne er jo tilgjengelig for de fleste av oss, men blir per i dag ikke brukt fullt ut annet enn i spill og lignende. Du vil derfor få mye rikere effekter og alpha-blending, rotasjon og andre 3D-effekter som ubegrenset skalering. Dette fikk man ikke i de tidligere generasjoners pikselbaserte miljøer. Det som er interessant med XAML er at du kan tenke på det som et deklarativt språk. Det er jo et domene-spesifikt språk som brukes for å deklarere grafiske brukergrensesnitt.
HWB.no: Vil brukere av Visual Studio se noe av XAML, eller vil den nødvendige koden bli generert av Visual Studio?
Anders: Det vil på et tidspunkt komme en ”Avalon”-designer, som lar deg programmere Avalon-baserte visuelle brukergrensesnitt i Visual Studio. Så du MÅ ikke se XAML-koden, men du vil definitivt kunne se den dersom du ønsker det.
HWB.no: Vil det være egenskaper i XAML som du ikke vil kunne generere i Visual Studio, og som man dermed må legge inn manuelt?
Anders: Både ja og nei. Designverktøyet vi lager vil være en fullspekket designer, men visse ting involverer koding. Du kan for eksempel ikke visuelt designe en effekt som du vil skape, fordi den også involverer kode. Vi vil imidlertid legge opp til at du kan legge inn denne koden på enklest mulig vis.
I tillegg, på grunn av at XAML er utvidbart, kan man deklarere sine egne elementer. Disse kan man, dersom man ønsker det, deretter videreutvikle visuelt. Så det vi snakker om her er mer enn et satt antall kontroller. På en måte er alt i Avalon bygget ut av seg selv. Hvis du ikke liker vår knapp, kan du ”kaste” denne og definere din egen uten problemer.
Driftere og programmering
HWB.no: Utviklingen av C# er på vei over i produkter som SQL-server. Hvordan ser du for deg fremtiden for driftere?
Anders: La meg først snakke litt om hva jeg håper å kunne gjøre over tid med C#. Noe av det som har interessert meg de siste årene er den avstanden som finnes mellom generelle programmeringsspråk og databaser. Når man skriver en forretningsapplikasjon i dag, så snakker man alltid mot en database. Denne databasen har en tendens til å være en relasjonsdatabase basert på SQL. Samtidig skrives programmer i språk som C# og Java, som er objektorienterte, imperative og basert på en helt annen gren innen IT. Det er rett og slett veldig mange motsetninger mellom disse to verdenene, der den ene er relasjonsbasert og hierarkisk og den andre er objektorientert. For å kunne skrive en bra forretningsapplikasjon må man skrive i begge verdener. Man må også kunne håndtere brobygging mellom de to verdenene. Slik jeg ser det vil det være store produktivitetsgevinster å hente fra en tettere integrasjon mellom disse to. Hvorfor skal jeg for eksempel ikke være i stand til å skrive mine spørringer inne i C#? Eller hvorfor må jeg skrive ting i anførselstegn, som ikke blir sjekket når jeg bruker slike?
På den positive siden kan vi allerede i dag se begynnelsen til en integrasjon, blant annet i SQL-server 2005, Yukon. Der har man integrasjon mellom CLR og SQL-server, og muligheten for å skrive C#-, .NET- eller Visual Basic-kode inne i databasen. Vi kan imidlertid gå mye lenger enn dette! Dette er kun begynnelsen, og vi har så mye mer å komme med. Dette er ting jeg har jobbet mye med det siste halvannet år.
HWB.no: Tror det vil være nødvendig for en drifter å lære seg programmering?
Anders: Driftere kan jo allerede en del programmering, for eksempel fra T-SQL. Likevel er integrasjonen mellom programmeringsspråk og eksempelvis SQL ikke noe som skjer over natten. Vi holder på å berede grunnen for en nyere og tettere integrert programmeringsmodell. Dette vil gjøre at du kan jobbe i samme program og programmeringsmiljø for alle de ulike nivåene i utviklingsprosessen. Dette vil til syvende og sist gjøre programmerere mer produktive. Dette skjer som sagt ikke over natten. Så det er ingen grunn til at driftere skal slutte å skrive SQL og hive seg over noe annet.
HWB.no: Hvordan ser du på utviklingen av Microsoft-produkter relatert til SUNs Java i tiden fremover?
Anders: Jeg tror det skjer en del interessante ting i Java-miljøet for tiden. Når jeg sammenligner det med hvordan det så ut for fem år siden, synes jeg det virker veldig fraksjonert. Og det ser ut til å bli mer fraksjonert dag for dag. Og dette overrasker meg ikke. Grunnen til dette, tror jeg, er behovet de ulike leverandørene har for å differensiere seg fra hverandre på en eller annen måte. Dette innebærer at de må bygge sin egen verktøykasse, sin egen applikasjonsserver, og så videre. Samtidig bidrar de med et utrolig mangfold av API-er. Dette igjen fører til at det er en utfordring å velge blant disse – for ikke å snakke om å få dette til å jobbe sammen.
Dette gjør at det blir mindre grad av overførbarhet av kunnskap. Når man begynner på et nytt prosjekt må man forholde seg til et annet sett med verktøy, og så videre. På den måten synes jeg .NET er veldig interessant. Der er måten vi gjør ting på helt annerledes. Vi forsøker å få til en veldig dyptgående vertikal integrasjon, helt fra databasen opp til det grafiske brukergrensesnittet. Vi bruker en del tid på å sørge for at dette faktisk fungerer bra sammen, noe som mangler i Java-verdenen. De to verdenene er derfor nokså ulike, og de blir mer og mer ulike for hver dag. Her vil jeg si at vi er meget fornøyde med fremgangen på .NET-plattformen, og at vi er kommet et godt stykke på vei i løpet av de seks årene vi har jobbet med den. Jeg tror vi er i ferd med å sette ordentlig i gang med dette, og jeg er veldig spent på hva som skjer fremover i de neste tre årene.
Utdannelse og fremtidens programmerere
HWB.no: Hvilke er de viktigste programmeringsspråkene, plattformene og prosessene fremtidige programmerer burde lære seg?
Anders: Jeg tror det er masse man kan se på. Jeg synes også programmeringsverktøy har blitt fantastiske i forhold til de jeg brukte når jeg startet. På MS-plattformen synes jeg selvfølgelig at .Net-plattformen og C# er et fint sted å starte, for å komme inn i et moderne utviklingsmiljø. Og ikke bare de nevnte, men også Visual Studio. Denne kommer også i studentutgaver og Express-versjoner som er fritt tilgjengelig for nedlasting.
HWB.no: Når det gjelder utdannelser og utdannelsesløp – vil det gi størst tyngde med en bredere forståelse og erfaring med ulike miljøer og utviklingsplattformer, eller med en mer spesialisert utdannelse innenfor et fåtall språk?
Anders: Jeg tror det er slik at det første språket du lærer introduserer deg for 90% av konseptene du vil se i alle de andre språkene. Det er litt som med en baby: Det er en ting å lære seg å snakke i første omgang, og så er det en helt annen ting å lære seg andre språk. Så først må man lære seg å snakke. Man kan diskutere hvilket som er det første språket man burde lære, og alle universiteter vil ha sin oppfatning av hvilket språk dette er. Uansett er det slik at når du først lærer deg ett, så er det mye lettere å lære seg andre. Etterhvert ser man nok fordeler og ulemper med hvert språk, men det er mye som er felles.
Det som har endret seg mye med tiden er at man tidligere måtte bruke mesteparten av tiden på å lære seg selve programmeringsspråket. Med språket ble det levert et lite kjøretidsbibliotek som man kunne lære seg. I dag er språket i seg selv nesten ingenting, kanskje 5% av læringskurven. Resten er den omkringliggende plattformens API. Det er her det har skjedd en stor utvikling. Plattformene i dag har så mange egenskaper, og som en konsekvens av dette har API-ene blitt store. Derfor er det på dette feltet utfordringen ligger når man skal lære seg å programmere.
Det som er interessant med .NET er at vi har flere ulike programmeringsspråk, som alle jobber på samme plattform. Og det er jo der den store læringen ligger – resten er jo kun syntaks, om det er snakk om Visual Basic, C# eller en av de andre. Alt finnes i den samme verdenen.
Programmeringsspråk i dag er ikke så mye større nå enn de var når jeg studerte. For eksempel er C# ikke særlig mye større enn Pascal, som ble laget for mer enn tredve år siden, i 1974. Det er API-ene som har vokst enormt siden den gang. Det går rett og slett ikke å sammenligne et kjøretidsbibliotek i Pascal med ett på .NET-plattformen. Dette er egentlig en direkte effekt av Moores lov – man kan rett og slett gjøre mye mer.
Anders Heljsberg stilte villig opp for fotografen sammen med HWB.nos redaktør.
HWB.no: Har du noen gode råd til fremtidige programmerere? Hvis du tenker tilbake på den gang du studerte – hadde du noen visjoner som gjorde at du er kommet dit du er i dag?
Anders: Nei, for all del, det hadde jeg ikke. Jeg hadde ingen anelse om at jeg skulle ende opp med å jobbe og bo i USA. Det hele har rett og slett vært en kjempeopplevelse for meg, og jeg har hatt det mye moro! Jeg tror at det som alltid motiverte meg, og som har fungert for meg, er å følge det gamle ordtaket ”Gjør det du liker, og pengene vil følge ”. Jeg ble ikke først og fremst motivert av pengene jeg kunne tjene. Jeg ble fascinert av det datamaskiner kunne gjøre. Tanken på at ”her finnes det en maskin som gjør deg i stand til å skape den verdenen du måtte ønske” – og i tillegg ha fullstendig kontroll over den. Ned til den minste detalj. Dette er i seg selv utrolig, og blir på en måte som det ultimate hjernetrim. Dette har vært drivkraften for min del, hele tiden. Jeg tror man kan gjøre store ting når man er entusiastisk og virkelig interessert i det man driver på med. Det at man gjør noe fordi man vil gjøre det, i motsetning til noe man er nødt til å gjøre. Når jeg ser gode programmerere er det også dette jeg ser.
En annen ting er at det er viktig å forsøke å være pragmatisk, forsøke å gjøre ting enkelt. Det er en ting jeg alltid prøver å få til. Som Einstein sa: ”Gjør alt så enkelt som mulig, men ikke enklere”. Enkelhet er en god ting. Mange mennesker tror at de kan gjøre det stort dersom de pønsker ut noe som er veldig komplisert – og at større kompleksitet er bedre. Dersom man ser på alle de virkelig gode ideene i verden, så er de enkle. Så tenk enkelhet!
HWB.no: Et siste spørsmål, helt på tampen: Hvilke egenskaper skulle du gjerne sett i .NET, men som det for øyeblikket ikke er mulig å få implementert?
Anders: Det ville være mer av det samme som jeg har snakket om tidligere. Dette med tettere integrasjon mellom databasesiden og programmeringssiden. Det er på disse områdene vi virkelig kan få lagt til enda større verdi. Dette er min lille, personlige ting som jeg bruker mye tid til å tenke på.
