Hvor mange triks kan man egentlig lære en gammel hund?

Det er ingen tvil om at iPhone har sørget for at horder av utviklere har lært seg teknologiene som ble utviklet i NeXT – Cocoa og Objective-C rundt 1990. For å kunne lage programmer som kjører på iPhone må man lære seg programmeringsspråket Objective-C, og rammeverkene som finnes på iPhone ligner såpass mye på Cocoa, som Mac-programmer er laget i, at antallet utviklere av rene Mac-applikasjoner nok har økt stort det siste året.

Det er ingen tvil om at Cocoa er imponerende. Det er sjelden man ser abstraksjoner som fungerer så godt, ved at de hjelper utvikleren å lage avanserte og brukervennlige applikasjoner. Det at man kan bruke dette også på iPhone gir iPhone et forsprang konkurrerende mobilplattformer vil bruke lang tid på å ta igjen. I tillegg til Ruby on Rails er det få rammeverk jeg har sett gi abstraksjoner på riktig nivå i like stor grad som Cocoa.

Mitt problem er språket.

For å utvikle programmer på iPhone bruker man altså Objective-C. Objective-C er sterkt inspirert av Smalltalk, og slik sett et rendyrket objektorientert språk. Og dette er kanskje interessant: Smalltalk var det Steve Jobs så da han besøkte Xeroc PARC på syttitallet; da han oppdaget grafiske brukergrensesnitt, mus og vinduer – det vi alle bruker idag. Smalltalk var også det Apples Lisa kjørte. Smalltalk hadde imidlertid et stort problem på den tida, nemlig at det var gudsjammerlig treigt på datidens maskinvare.

Objective-C, derimot, er basert på C; Objective-C er faktisk et supersett av C. Samtidig er Objective-C (i den det er mulig i C) tro mot objektorienteringen i Smalltalk. Men altså mye, mye raskere og på sett og vis mer pragmatisk ved at man kan bruke C og C++-kode i Objective C-prosjektet sitt. Objective-C har noen åpenbare språklige vorter; firkantklammer og peker-asterikser reduserer lesbarheten, men dette føles på sett og vis bare herlig pragmatisk og er noe man slutter å irritere seg over etterhvert. Så også muligens med disse .h-filene man er nødt til å lage.

Nå har åpenbart tiden kommet for å legge til støtte for blokker i Objective-C. Og her begynner man å se mer av fundamentene Objective-C er bygget på enn jeg liker. Apple foreslår å bruke caret (^) for å definere blokker i C, og her snakker vi om en språklig mutant av dimensjoner:

void EvalFuncOnGrid( float(^block)(float) ) {
    int i;
    for ( i = 0; i < 5 ; ++i ) {
        float x = i * 0.1;
        printf("%f %f", x, block(x));
    }
}

void Caller(void) {
    float forceConst = 3.445;
    EvalFuncOnGrid(^(float x){ return 0.5 * forceConst * x * x; });
}

void main(void) {
   Caller();
}

Blokker, eller block closures, er et kraftig verktøy som kan være vanskelig å forstå. Den beste beskrivelsen jeg har hørt er at det er som å gi metodene dine en ekstra lunge. Ruby bruker kodeblokker til en rekke ting, ofte for å gi en eller annen form for transaksjonsstøtte rundt en operasjon. I funksjonelle språk er konstrukter som tilsvarer kodeblokker de mest grunnleggende byggeklossene i et hvilket som helst program. Smalltalk bruker dem i mye større grad, blant annet fordi Smalltalk mangler nøkkelord som if, else og while:

(theEconomy isInRecession) 
   whileTrue: ['Strange' printString]
   whileFalse: ['Not so strange' printString]

I Smalltalk, som altså er den største inspirasjonen til Objective-C, er altså blokker helt grunnleggende; det er helt umulig å lage et Smalltalkprogram uten dem. Når Objective-C nå har klart seg i tjue år uten er det i en merkelig forkledning Apple ser ut til å introdusere dem i språket, og jeg tror det vil ta lang tid før utviklere føler seg bekvem med å bruke dem i programmene sine.

Kanskje denne hunden har lært de triksene den kan?


Gravatar-aktivert. Les mer om gravatar.
E-postadressen vil ikke vises på siden