KRONIKK: Programmering i dag er som å lage en steinskulptur. Det vi trenger er mer smidige kommunikasjonsmodeller. Programmeringsspråk som oppfører seg mer som formbar leire – og mindre som granitt.
For å lage slike verktøy må vi ta et fundamentalt oppgjør med selve basisen for programmering, og lage totalt nye tenkesett, som erstatter de eksisterende paradigmene med nye tenkemåter. Blant annet må vi fullstendig revurdere selve konseptet «programmeringsspråk» og hellige kuer som objektorientering, kompilering og interpretasjon.
Når du i dag lager et program kommuniserer du konsekvent på et språk som datamaskinen ikke forstår, hvor du tvinger maskinene som skal kjøre programmet ditt til enten å kompilere ned til et helt annet språk, subsidiært å dynamisk tolke det under kjøring.
Dette er sammenlignbart med å kommunisere med en som kun forstår arabisk, på norsk, og være avhengig tolk som oversetter korrekt for deg som mellommann.
Vi må finne en felles plattform å kommunisere våre intensjoner på. Et språk vi både forstår og datamaskinen kan kjøre, uten å gå via disse mellomleddene.
Selvmodifiserende kode
Det skaper koherens i programmeringen, slik at intensjonene våre kan bli direkte forstått av datamaskinen, uten kompliserende mellomledd med rom for misforståelser. I tillegg muliggjør dette at datamaskinen kan programmere seg selv, og modifisere sine egne programmer, og kommunisere sine forandringer til oss på et språk som vi kan forstå.
Dette fordrer at eksekveringsspråket og programmeringsspråket er det samme. I dag forstår faktisk ikke en datamaskin selv hva den kjører, fordi det er skrevet på et språk som den selv ikke forstår, uten at vi bringer inn kompliserende statiske mellomledd, som for eksempel dekompilering, kompilering eller interpretasjon.
På toppen av dette problemet, kommer problemet med enkapsulering og polymorfisme, som i dag stort sett utelukkende er definert statisk i opprinnelsesspråket, og ikke kan modifiseres av selve programmet eller datamaskinen selv under kjøring. Dette er sant både for «dynamiske» språk og statiske språk.
Ved å ta et fundamentalt oppgjør med programmeringsmodellene våre og bryte ned barrieren mellom data og logikk, vil logikk og funksjonalitet kunne være «data» til et tredjepartsprogram, som dette programmet kan forstå, analysere og modifisere. Slik lærer vi datamaskinen å snakke med seg selv og andre datamaskiner, samtidig som det språket den snakker er forståelig også for oss.
Ny måte å tenke på
Disse nye språkmekanismene er basert på eksisterende og konvensjonell teknologi. Det er bare en ny måte å tenke på.
Et godt eksempel er konseptet «kode» og «data». To verdener som i dag er fullstendig adskilt. Ved å ikke lengre skille mellom de blir plutselig koden formbar. Koden kan da forvandles til noe fullstendig annet enn det det var.
Da viskes forskjellene mellom data, kode og programmering vekk. Programmet kan modifisere seg selv. Kode kan være inputdata til andre funksjoner, data kan eksekveres og så videre.
Data kan i dag sendes inn i en «funksjon» (metode, logikk, kode), men en kan ikke i særlig grad forandre hvilke parametre en funksjon tar. Ei heller kan man forandre selve funksjonen i seg selv. Dette skaper en rigid modell hvor koden er støpt i sement etter at programmet er ferdig. Ved å se på «kode» som bare en annen form for «data» kan selve koden modifiseres. Parametrene vi sender inn i funksjonen kan forandres under kjøring.
Noen av disse programmeringsmodellene har «quantum computing qualities» fordi et program (funksjon, metode, logikk) for eksempel kan løse forskjellige oppgaver, avhengig av data man sender inn.
Det er ingenting «magisk» med disse konseptene. De kan fortsatt utmerket godt eksekveres innenfor rammene av våre eksisterende binære algebraiske modeller, med dagens datamaskiner.
Still deg selv følgende spørsmål:
- Hvorfor kan ikke programmet mitt programmere seg selv?
- Hvorfor kan ikke programmet mitt snakke tilbake til meg på et språk som jeg kan forstå?
- Hvorfor kan ikke jeg fortelle programmet mitt dynamisk under kjøring hvilke algoritmer jeg vil det skal bruke?
- Hvorfor kan ikke programmet mitt selv velge hvilke oppgaver det skal parallellisere?
- Hvorfor kan ikke programmet mitt bytte ut eksisterende funksjonalitet mens det kjører?
Når jeg snakker om parallellisering, mener jeg at man kan ta en hvilken som helst funksjon, og under kjøringen bestemme om denne skal kjøre i samme prosess sekvensielt, eller om den skal fases over til an annen prosessor/maskin for eksekvering.
Dette er enkelt i det paradigmet jeg beskriver fordi «kode» bare er en annen form for data, og enkelt kan sendes fra en prosessor eller datamaskin til en annen, ved bruk av for eksempel konvensjonelle web services over for eksempel HTTP. Med andre ord kan en sende kode som data til en annen server og eksekvere koden på den andre serveren, for så å returnere resultatet av eksekveringen tilbake til den opprinnelige kilden. Dette skaper skaleringsmodeller som er umulige med dagens paradigmer.
Det er ikke sci-fi
For å finne svaret på spørsmålene jeg stilte må du først erkjenne at du lever i steinalderen, og at alt du trodde du visste er basert på steinalderteknologi! Du må erkjenne at for å løse disse problemene må du først lære deg selv og datamaskinen å snakke det samme språket. Du må bryte ned barrieren som er kunstig konstruert for å skille mellom «data» og «logikk».
Det vi trenger i programmering, er en relativitetsteori, som bryter ned barrieren mellom data og logikk, på samme måte som Einsteins teori eliminerte barrieren mellom energi og masse. Slike modeller finnes faktisk.
For en referanseimplementasjon som gjør akkurat det som er beskrevet ovenfor, kan leseren ta en titt på mitt prosjekt. Se gjerne også en demonstrasjon jeg har lagt ut på Youtube.
Dette er ikke science fiction. Det er faktisk funksjonelle ideer med eksisterende implementasjoner.
Delta i debatten
Informasjon om debattinnlegg og kronikker i digi.no
Alle innlegg må sendes til redaksjon@digi.no. Husk å legge ved et portrettbilde. Vi forbeholder oss retten til å redigere innsendt materiale.
