Det finnes tusenvis av programmeringsspråk. Likevel bruker de fleste av oss 4-5 stykker som ser nogenlunde like ut, støtter mye av den samme funksjonaliteten, og generelt kan brukes om hverandre. Kjenner du som meg på at vi kunne hatt godt av litt variasjon? Hvorfor skal vi absolutt skrive kode med if
-er og for
-er i tekstfiler som kompileres til kode, og hvorfor har vi latt Ken Thompson få diktere at det er {
som skal bety starten på et scope? Heldigvis finnes det veldig mange andre alternativer der ute: Terskelen for å være Turing-komplett er tross alt ikke spesielt høy. Mulige mer eller mindre verdige kandidater er for eksempel PowerPoint, eller Magic-kort (gitt at de første programmererne jobbet med hullkort er det nesten rart at vi har endt opp med Java istedenfor Magic). Dagens kalenderluke vil ta en kikk på 4 slike programmeringsspråk, som definitivt ikke er JavaScript, C#, eller Python, og som på hver sin måte har nyttig og/eller spennende funksjonalitet som ikke er vanlig i de programmeringsspråkene de fleste av oss bruker daglig for å få mat på bordet.
APL
APL ble i 1962 satt ut i verden av utvikler og forsker Ken Iverson i boken A Programming Languge, med målsetningen om å lage et bedre alternativ til den konvensjonelle tegnsetningen i matematikk. Notasjonen viste seg å være nyttig for å beskrive de på den tiden nymotens greiene som ble kalt datamaskiner, og innen 1966 var notasjonen implementert som et faktisk programmeringspråk.
Den grunnleggende byggestenen i språket er ikke et objekt eller en byte, men en potensielt flerdimensjonal matrise. Disse modifiseres med et sett på rundt 50 operatorer. Noen ligner på dem vi er vant til fra matematikken, f.eks. +
og *
, mens noen er mer unike, som ⌹
(matrise-inversjon) eller ⍴
(returnerer lengden på hver dimensjon i matrisen). Felles for alle er at de fungerer på matriser av forskjellige dimensjoner: 1 + 2
blir som kjent 3
, mens 1 + 1 2 3
blir til vektoren 2 3 4
, og 1 2 3 + 1 2 3
blir til 2 4 6
.
APL ser for uinvidde ut som en blanding av havregrøt og kalkulus, men dersom man lærer seg syntaxen, kan man gjøre ekstremt mye på veldig få linjer kode. Det finnes mange implementasjoner av APL i dag, men den klart mest populære og optimerte heter Dyalog APL. APL kan prøves i nettleseren på denne siden. Prøv f.eks. å lime inn (⌽,0 1↓⊢)↑'*'\¨⍨1,⍨⍳ 10
i prompten for litt julestemning.
Hva kan man få til dersom man mestrer språket? I denne (lange) videoen vises det frem en kompilator implementert i APL som kan kjøre på både CPU og GPU (!), som er mye raskere og bruker mye mindre minne enn en del andre kompilatorer som regnes som state of the art, og som er implementert på under 17 A4-sider med kode. Det er ekstremt kompakt skrevet, men med så få linjer kode skal det mye til å gå seg vill i kodebasen.
Smalltalk
Hva om det ikke var noe skille mellom IDE, programmeringsspråk og operativsystem? Det er tesen Smalltalk jobber ut ifra. Språket ble utviklet på 1970-tallet av Alan Kay på forskningssenteret Xerox PARC, som på få år utviklet datamusen, laserprinteren, og en hel haug med andre ting vi bruker mer eller mindre daglig i dag.
Smalltalk var blant de første rent objektorienterte språkene. Absolutt alt i språket er et objekt. Smalltalk er også ekstremt dynamisk. Det er ikke bare typene i språket som er dynamisk, alle objekter kan inspiseres og endres når som helst, også når programmet kjører, uten at man må restarte noe. Siden det ikke er noe skille mellom IDEen og programmeringspråket, er det vanlig å f.eks. stoppe midt i en debugging-session, skrive litt kode direkte i debuggeren, og fortsette å kjøre programmet med den nye kodeendringen. Det blir som om man kunne sette et breakpoint, endre kode direkte i DevTools-debuggeren i nettleseren uten å noensinne trenge å restarte systemet. Fungerer ikke debuggeren som du ønsker midt i en debugging session? Bare gjør endringene du vil rett på debugger-objektet og fortsett debugging-sessionen.
I dag er det nok mest legacy-systemer som bruker Smalltalk (databasen Gemstone er fortsatt en del brukt). Det finnes likevel gode moderne implementasjoner, og blant dem er nok Pharo fra det franske forskningsinstituttet INRIA det mest fremtredende.
Idris
Statiske typer har kommet for å bli, og ikke minst er dette tydelig i frontend-verden, hvor TypeScript har hatt en enorm vekst de siste årene og har etter hvert tatt over mer og mer for JavaScript. Men hvor langt kan man tøye strikken med typesystemer? En interessant gren av typeteori er typesystemer som bruker avhengige typer. I slike typesystemer kan typene være avhengige av bestemte verdier.
Et eksempel på hvordan dette kan være nyttig: Vi ønsker en funksjon for matrisemultiplikasjon. Med avhengige typer kan man gi funksjonen typen (m1: Matrix(x,y), m2: Matrix(y,z)) -> Matrix(x,z)
, hvor Matrix(N,M)
er typen til en matrise med N rader og M kolonner. Her er det allerede klart fra typen at den første matrisen har like mange kolonner som den andre matrisen har rader, så funksjonen vil kun kunne kalles med matriser som faktisk kan multipliseres.
Frem til nylig har avhengige typer hovedsaklig vært brukt i forskning, men i nyere tid har enkelte begynt å se på mulighetene for å ta det i bruk i mer praktisk rettet kode. Den britiske forskeren Edwin Brady (tidligere kjent for det særs uintuitive programmeringsspråket Whitespace, hvor man skriver kode med forskjellige typer mellomrom), har utviklet Idris for å eksperimentere i denne sfæren. Idris er et funksjonelt språk, og kombinasjonen med avhengige typer gjør at Idris er ekstremt velegnet til det Brady selv kaller type-drevet utvikling
, hvor programmeringsspråket kan automatisk generere store deler av mange funksjonsimplementasjoner bare fra typene, demonstrert f.eks. her.
Avhengige typer kan tilogmed brukes til å matematisk bevise at logikken i koden din holder, og Idris har funksjonalitet for å støtte dette om du måtte ønske. Vil du gå mer i dybden på Idris og avhengige typer, er denne boken både god og lettlest, tematikken tatt i betraktning.
Lisp
Siste språk ut er et av de mest toneangivende og historierike av alle programmeringsspråk, og har dannet grunnlaget for utrolig mange av de tingene vi tar for gitt i programmeringsspråk i dag, slik som scoping på blokker, anonyme- / lambdafunksjoner, garbage collection, rekursjon, og et hav av andre ting. Det er selvfølgelig snakk om Lisp. Språket (som i dag er en familie med nært beslektede språk), var det andre programmeringsspråket som ble laget (etter FORTRAN), og kom til på MIT allerede på slutten av 1950-tallet, og ble skikkelig definert i en artikkel fra John McCarthy i 1960.
Selvom moderne språk har tatt i bruk mange av Lisp sine nyvinninger, er det fortsatt spesielt én ting veldig få andre språk kan nå opp til, og det er macro-systemet.
En macro er en bit med kode som genererer annen kode. Dette er i seg selv ikke noe banebrytende, men kombinert med syntaxen i Lisp blir det ikke bare mulig, men utrolig enkelt å endre på språket slik du vil. Lisp sin grunnleggende byggesten er en liste, og lister brukes både til å definere og skrive kode og til å beskrive data. Siden Lisp sin syntax er bruker samme representasjon for kode og data, kan man generere kode som om det var en hvilken som helst annen datastruktur. Denne artikkelen gir et veldig godt innblikk i hvorfor det er en ønsket egenskap.
Med macroer kan man gjøre språket til akkurat det man ønsker, og macroer i Lisp blir dermed et slags ultimat våpen i jakten på spennende nyvinninger i programmeringsspråk. Har du for eksempel lyst på asynkrone funksjonskall? Dette kan implementeres som et bibliotek istedenfor å måtte bygges inn i språket, gjennom å bruke macroer. Trenger du typer? Prøv f.eks. Coalton som legger til et typesystem likt det som finnes i Haskell. Likte du APL? Null problem. Mulighetene er endeløse.
Til slutt
Jeg håper dagens luke har gitt deg et lite avbrekk i fra klementinspising og Mariah Carey nå i førjulsstria, og at du har fått en liten smakebit på noen interessante programmeringsspråk som du omtrent garantert ikke får lov av sjefen din å innføre på jobb.