Norwegian Developer Conference 2009 (NDC) arrangeres denne uken av ProgramUtvikling i Telenor Arena på Fornebu. Til stede er omtrent tusen betalende deltakere som får høre mening og råd og fra en rekke kjente foredragsholdere innen primært Microsoft-teknologier og smidig programvareutvikling. Blant disse er Ted Neward, som digi.no fikk en prat med.
Neward har programmert profesjonelt siden 1995 og har erfaring fra en rekke ulike språk, inkludert C++, Java og .NET-relaterte språk. Han er hovedkonsulent hos ThoughtWorks.
Under NDC snakket Neward blant annet om programmeringsspråk, som han mener vil komme langt mer i fokus de nærmeste årene.
- Språk er verktøy. For å velge riktig verktøy må man kjenne problemet, men også mulighetene til verktøyet, for å kunne velge hvilket verktøy man bør bruke for dette ene problemet. Problemet definerer derfor verktøyet som skal brukes. Dette er vanskeligere i vår bransjen, en for eksempel i byggebransjen, fordi verktøyene vi bruker er mer komplekse, fortalte Neward.
Han mener at utviklere stadig mangler tilgang på gode nok verktøy.
- Problemet i dag når en kunde kommer med et problem, er at problemet må oversettes til en løsning, som igjen skal gjengis som kode. Det er ikke alltid man som utvikler forstår problemet klart, og at man baserer prosjektet på antakelser. Man har i 50 år forsøkt å lukke dette gapet, sa Neward.
Han mener at domenespesikke språk vil kunne bidra til å redusere avstanden mellom kunde og utvikler.
Domenespesifikke programmeringsspråk er laget for å bli brukt innen et spesielt problemområde, for eksempel i finanssystemer, forsvarssystemer eller grafikkløsninger. Det er altså den rake motsetningen av generelle programmeringsspråk som C++ og Java.
Neward fortalte at han blant ønsker seg et eget språk for utvikling av brukergrensesnitt.
- Et som ikke er basert på XML, som ikke er noe bra utviklingsspråk. Microsofts XAML er et eksempel på dette. XML er brukt fordi det var det som var mest sexy en stund, og fordi det er enkelt å syntaksanalysere, sa Neward.
- Jeg ville heller bygge et språk spesielt rundt WPF, med støtte for event-håndtering. Man vil ikke ha slikt i XML. XAML er kanskje bedre enn C# til lage brukergrensesnitt, men jeg er ikke overbevist om at det er den beste løsningen.
Neward forteller at det forskes mye på programmeringsspråk ved akademiske institusjoner, men at forholdet mellom de akademiske miljøene og praktikerne, altså de utøvende programmererne, må anses som ganske fiendtlig.
- I alle andre bransjer er akademikerne respektert. Men på en IT-konferanse er det ingen som vil høre på akademikere, fordi temaene gjerne er komplett irrelevante i forhold til programmererne daglig arbeid, fortalte Neward.
Han mener begge parter må bruke mer tid på å komme nærmere hverandre og se mer på hverandres arbeid.
- Man må lytte til hverandre og relatere forskningen til det virkelige liv. Forskerne er generelt for isolerte fra utviklerfellesskapet, sa Neward.
Han nevner som et eksempel at forsker lager programmeringsspråk som beviser et eller annet konsept, men som viser seg å være helt ubrukelige i praksis fordi forskeren som har laget det for eksempel mener at flate filer er tilstrekkelig for lagring av data, og derfor har droppet å gi språket støtte for integrasjon med databaser.
På amerikansk engelsk omtales akademikernes isolasjon fra omverdenen som at de bor i et elfenbenstårn.
- Fra tårnet kan man se mønstre som de på bakken ikke kan se. Man får bedre oversikt. Det er ikke nødvendigvis galt å bo der, men det er galt å bo bare der, sa Neward.
- Forskerne kan fra tårnet kanskje kunne observere lignende problemer på ulike steder som kan løses med en felles modell. Men de må teste ut modellene i det virkelige liv. Et eksempel er modelldrevet arkitektur, som bare fungerer i de enkleste tilfellene. Lag en modell, trykk på en knapp og få laget koden...
Neward mener at forskerne innen programvare bør bruke tre til seks måneder i året på problemer i det virkelige liv. Programvare skiller seg her fra andre typer forskning i laboratorier. I kjemi reagerer to stoffer med hverandre på samme måte om man er i laboratoriet eller ikke, men det er ikke slik ting fungerer innen programvare, mener Neward.
Blant de utfordringene mange utviklere står overfor i dag, er parallellprogrammering og samtidighet. For å utnytte den økte regnekraften i moderne datamaskiner må programvaren tilpasses kjøring på flere prosessorer eller prosessorkjerner på en gang.
- Utfordringene er blant annet knyttet til samtidighet, for eksempel at man kan ha to identiske programmer som kjøres uten å forstyrre hverandre, med unntak om man faktisk ønsker at de skal samarbeide. Deling av data mellom tråder er et annet eksempel. Man må ha et velstrukturert format, men programmeringsspråkene tilbyr ikke dette i dag, sa Neward.
- Parallellprogrammering er vanskelig og medfører en stor sannsynlig for feil med språk som Visual Basic og C#. Det er mulig å gjøre det, men utviklere vil ikke. De velger i stedet minste motstands vei, mener Neward.
Under NDC holdt Neward også et foredrag om JavaScript. digi.nos prat med Neward foregikk før dette foredraget, hvor Neward skulle fortelle publikum at JavaScript faktisk er et virkelig språk.
- Det handler ikke bare om nettlesere. JavaScript er mer interessant enn Ruby og Python fordi det har en modell som er enklere å forstå og fordi det er mer dynamisk.
Neward sa at JavaScript er bredt tilgjengelig og at det også blant annet kan kjøres i virtuelle maskiner som CLR og JVM.
- JavaScript kan kanskje være et godt språk for å lage brukergrensesnitt, sa Neward, som mener at mange av feilene med JavaScript skyldes nettleserintegrasjonen.
- Mange kjenner språket allerede, men mange er negative til språket fordi de ikke forstår det.
Neward medgir at mange av utviklingsverktøyene for JavaScript er temmelig grunnleggende og uferdige. Når det gjelder kritikken mot ytelsen, mener han at dette er en misforståelse og til dels irrelevant.
- Det er vanskelig å så at JavaScript har god eller dårlig ytelse, fordi det er vanskelig å måle ytelsen til selve språket, siden det knapt brukes utenfor nettleseren, forklarer Neward.
- Vi har dessuten for lengst krysset grensen for at utviklertiden er dyrere enn CPU-tiden. Man må se på hva som er viktigst og hvor man kan spare penger, avslutter Neward.
