Interaktiv programmering er farlig

I mange tilfeller så er programmering en treg prosess. Du endrer litt kode, bygger, kjører tester, venter. Hvis alt går bra så endrer du litt kode til. Etter hver så blir man vant til at ting tar tid og tenker at sånn er programmering. Men det trenger ikke være slik!

For noen år siden så jeg Bret Victors inspirerende presentasjon Inventing on Principle og tenkte at interaktiv programmering må være fremtiden. Nå nylig kom jeg over Figwheel, som automatiserer prosessen til interaktiv programmering i nettleseren via ClojureScript og tenkte at dette måtte jeg prøve ut i praksis.

Først, her er resultatet av det første forsøket mitt; se på sirklene hoppe!

Seriøst, sprettballer? Det har jeg sett før...

Ok, greit, det er ikke spesielt imponerende. Men dette handler om måten det ble laget; via interaktiv programmering.

Med interaktiv så mener jeg det at man endrer et program mens det kjører i nettleseren og deretter får umiddelbar, visuell tilbakemelding på endringene. Konkret så blir programmet oppdatert så snart du lagrer en fil i kodebasen din.

Dette kan også kombineres med tradisjonelt REPL-basert interaktivitet, hvor du typisk selektivt oppdaterer deler av programmet ditt i motsetning til å ta alle endringer ved hver lagring.

Tilstand, en festbrems

LOL tenker du kanskje, interaktiv programmering kan jo ikke fungere for annet enn trivielle lekeprogram; objektorienterte systemer har jo tilstand og sideeffekter smurt ut over alt! Det er jo i beste fall slitsomt å kunne oppdatere kjørende kode og samtidig holde styr på tilstanden.

Men det er mulig. Løsningen er todelt; isoler tilstanden i programmet ditt og bruk tilstandsløse, sideeffektfrie funksjoner. Dette er essensen i filosofien bak Clojure, og årsaken til at ClojureScript passer så bra til interaktiv programmering.

Eksempelvis så er all tilstanden til sprettball-animasjonen isolert til et atom

(defonce model (atom {:balls (for [n (range 1 10)]
                           {:pos [(* n 40) (* n 10)]
                            :velocity [0 0.3]
                            :acceleration [0 0.065]})}))

For hver frame som tegnes så skjer følgende:

• Man beregner neste tilstand ved å ta den nåværende tilstanden og sende den gjennomn et sett med funksjoner uten sideeffekter som tar inn en tilstand og gir tilbake en endret tilstand.
• Atomet oppdateres til slutt med den nye tilstanden
• Skjermen oppdateres basert på den nye tilstanden til atomet

For å se den interaktive utviklingsprosessen i aksjon, så se denne screencasten fra personen bak Figwheel.

Jeg kan virkelig anbefale å prøve ut interaktiv programmering; det gir deg den korteste feedbackloopen jeg noen gang har opplevd.

Ressurser

• Les canvas-fn kildekoden
• Mozilla's Canvas API site forklarer essensen i canvas APIet.