Dansk udvikler: Clojure er legende let

Lisp-dialekten Clojure kan noget med parallelisme, som andre sprog ikke kommer i nærheden af. Det mener dansk udvikler, som sagtens kan sælge løsninger i det meget unge sprog til kunderne.

Clojure er langt mere effektivt end andre nye sprog, såsom Scala og Ruby. Det mener den selvlærte freelance-programmør Lau Jensen, som underbygger sin påstand med et kodeeksempel, som i Clojure slår både Scala og Ruby af banen, både med hensyn til ydelse og antal kodelinjer. Eksemplerne kan findes på hans blog via fanebladet "eksterne links" under denne artikel.

Clojure, som udtales "closure," er et nyt sprog i Java-lejren, som lover at gøre det nemmere at danse med parallelisme-problemet, hvor programmer skal skæres i bidder, der kan udføres samtidigt, for at skalere over flere og flere CPU-kerner.

»Det, der virkelig giver Clojure en fordel i forhold til kodestørrelsen, er, at det er funktionelt. Det er Ruby ikke. Alle de variabler, du bruger i Ruby, skal du selv holde styr på at få "muturet rundt" - du skifter deres værdier løbende, som du går igennem koden. Sådan fungerer Clojure ikke. Når du først har givet variablen en værdi, så beholder den værdien, på nær nogle få undtagelser.«

Ifølge Lau Jensen er det ikke nogen nyhed, at koden kan reduceres drastisk, når variablerne ikke kan ændres. Det vidste IBM allerede for 60 år siden.

Uforanderlige variabler giver robuste programmer

På trods af at et moderne sprog som Scala har funktionelle træk, så er det stadigt muligt at benytte foranderlige variable i sproget, og derfor mener Lau Jensen ikke, at Scala fortjener at blive kaldt for et funktionelt sprog.

»Koden bliver ikke lige så robust, når du ikke ved, hvad du kan stole på,« siger han, og sigter til foranderligheden i Scala. Ifølge Lau Jensens mening skyldes en stor del af de fejl, der findes i software, at koden er skrevet i sprog, som tillader foranderlighed.

Clojure er specielt designet til den moderne computerarkitektur, hvor de enkelte processorkerners ydelse flader ud, men hvor vi til gengæld får mange flere at dem af rutte med.

Det kræver understøttelse af parallelisme og samtidighed på sprog-niveauet, og her mener Lau Jensen, at Clojure er langt bedre end alle andre sprog.

Actors kan fejle under pres

Erlang er et andet sprog, der har vundet mange fans på grund af sin evne til parallelisme. Men Lau Jensen er ikke vild med den såkaldte Actor-model, da den ikke er så effektiv eller sikker, som man skulle tro. I bogen "Programming in Scala" fra det ellers velrenommerede forlag O'Reilly gives et eksempel med Actors, som fejler under pres.

Til gengæld lykkedes det på kort tid Lau Jensen at skrive en Clojure-udgave af bogens Scala-kode, men med en reduktion i kodelinjer fra 105 til 35 kodelinjer. Og uden at fejle, vel at mærke. Eksemplet kan findes på Lau Jensens blog.

Lau Jensen har gået fra at være it-projektleder med interesse for Common Lisp til fuldtids Clojure-udvikler. Det var Clojures integration med Javas store mængde af biblioteker, der gjorde ham begejstret for sproget. Det fik en praktisk anvendelse, da han skulle løse et problem for DONG Energy.

Energiselskabet skulle skabe et stykke software, som kan bedømme, om en kundes energiforbrug er inden for rimelighedens grænser, ved at sammenligne med tilsvarende kunders forbrug.

Her kunne Clojure nedsætte projektets tidsforbrug fra en vurdering på halvanden måned, i en databaseløsning med PHP på brugersiden, til væsentligt mindre. Prototypen tog Lau Jensen tre timer at skrive, aftenen før projektets skæbne skulle afgøres.

Han synes i øvrigt ikke, det er rigtigt, at det funktionelle paradigme er sværere end andre programmeringsmodeller. Der kan være nogle hurdler, men efter tre måneders tid bliver det »legende let.« Det er heller ikke svært at afsætte Clojure som projekt-platform, fornemmer Lau Jensen, der satser på at skrive masser af Clojure-projekter i fremtiden.

Tips og korrekturforslag til denne historie sendes til tip@version2.dk
Kommentarer (25)
sortSortér kommentarer
  • Ældste først
  • Nyeste først
  • Bedste først
Hans-Kristian Bjerregaard

Idéen er den samme som når du koder i C istedet for assembler; for at du som menneske får mere overblik med et højere niveau i sproget og kan gøre ting lettere for dig selv og andre.

Hvis dette højere niveau medfører en langsommere eksekvering kan en optimering jo være at beregne delvist uafhængie dele af programmet paralelt. Så nu mere oversætteren kan finde disse dele uden at det skal defineres alt for eksplicit jo bedre.

Grundidéen her er jo ikke meget anderledes end de analyser der laves når der genereres maskinkode fra C kode. Der analyseres koden jo også for om man kan undlade variable og maskininstruktioner, så at undersøge om noget kan eksekveres paralelt er jo bare yderlige en dimension til optimal maskinkodegenerering.

  • 0
  • 0
NA NA

Hvor er det dejligt at fokus for mange nye programmeringssprog er på at få antal kodelinier ned - jeg mener det er jo et stort problem at få plads til al den kilde kode man laver og hoved problemet med ineffektive programmører er den tid det tager dem at indtaste koden.

  • 0
  • 0
Rene Nejsum

For 20 år siden skrev jeg meget parallel kode i C på en 8 Mhz 80186 med 64 Kb RAM, det gav rigtig meget mening, selvom det performede mindre end 1/1000 af Python på en 3 Ghz CPU i dag.

Parallelisme som en måde at håndtere mange komplicerede State's med askynkrone event's har ikke noget med performance at gøre.

I dag har performance ikke kun noget med afviklingshastighed at gøre, performance er tiden fra en forretningsidé til første transaktion, jeg ville nødigt skulle skrive et mellemstor website i ren C.

Jeg er enig i at antal kode linier skal ned, vi som programmører skal skrive mindre og lade CPU'en gøre arbejdet. Selvom vinduet til koden er blevet lidt større end ASCII terminalens 80x25, så er det stadig et meget lille vindue man har til at kigge ind i sit system med, man skal derfor kunne udtrykke mest muligt på de linier man har til rådighed.

I Python (og Clojure, Ruby, etc.) kan man udtrykke mere på samme plads. Desuden er der som regel fejl i X% af alle kode linier (1<X<10), så færre linier = færre fejl :-)

  • 0
  • 0
NA NA

Desuden er der som regel fejl i X% af alle kode linier (1<X<10), så færre linier = færre fejl :-)

Ja det skulle man tro - men desværre er det totalt naivt og det forholder sig typisk lige omvendt!

Her er et eksempel på en enkelt linie kode fra den blog der er nævnt i eksterne links:

[code=java]
counts.sort { |a, b| a[0] <=> b[0] }.each { |pair| out << "#{pair[0]}\t#{pair[1]}\n" }
[/code]

Det eneste man gør er at man "komprimere" en masse ting ind i en linie kode - dermed gør man koden meget sværere at læse, meget sværere at vedligeholde, meget sværere at udvide og øger sandsynligheden for at der er fejl.

Det er efter min mening et meget godt eksempel på hvordan man IKKE skal skrive kode og hvorfor disse bastard funktionelle konstruktioner som har set dagens lys i Scala og som man har forurenet C# er en katastrofe

  • 0
  • 0
Christian Nobel

Det er vel ikke nødvendigvis et mål at antallet af kodelinier skal ned, det vigtigste er da at programmer laves så logisk og overskueligt som overhovedet muligt.

Mange bommerter opstår jo lige præcis fordi at man har mast ting sammen i noget fnidret og uoverskeligt som f.eks sådan en Javascript sag som dette:
[code=Javascript]var objRegExp =
/(^a-z@([a-z_.])([.][a-z]{3})$)|(^a-z@
([a-z_.]
)(.[a-z]{3})(.[a-z]{2})*$)/i;[/code]

Der skal altså ikke ret megen rysten på hånden før det kan gå galt.

Herudover så er fordelen jo ved at bruge kompilerede programmer at alt det deskriptive kan skrælles væk, så det kun er den rå kode der afvikles.

/Christian

  • 0
  • 0
Peter Juhl Christiansen

Det er vel klart for enhver, at den tid det tager at udvikle software er meget vigtig!! og der er undersøgelser der viser at det antal linjer (færdig og virkende kode) en udvikler kan lave i snit per dag er storset det samme lige meget hvilket sprog man bruger.

Dvs det tager længerer tid at udvikle software i C end i Python. (selv er jeg mere til Ruby), ja eller Clojure.

Dermed ikke sagt at det nu er slut med at kode C, som vi alle ved er der ting C bare er bedst til, men der er faktisk folk der påstår at så snart man har mere end en tråd så er java i mange tilfælde hurtigere end C (Så har jeg lige snittet den store religions debat :-).

Og ifølge Rich Hickey (Mr Clojure) er clojure meget tæt på at være lige så hurtigt som Java. Så for mig at se er der mange grunde til at sprog som Clojure er særdeles interesant.

Så til jer der siger "jeg er bare så sej til C og det er jo det der er bedst"...hallo det var noget man sagde i 80'erne og 90'erne. Følg lige med tiden!

Eller blive ved med at skrive alt det C i vil men tro ikke det i laver er bedre af den grund.

Ups så kom jeg lige til at "bitche" lidt, det er ikke personligt :-)

/PJC

  • 0
  • 0
Christian Nobel

der er undersøgelser der viser at det antal linjer (færdig og virkende kode) en udvikler kan lave i snit per dag er storset det samme lige meget hvilket sprog man bruger.

Den tror jeg simpelthen ikke på.

Programmering er ikke stileskrivning frit fra hjertet, så hovedparten af tiden går med problemløsning/knusning, og efterfølgende kode skrivning - og der kan det nogen gange være meget, meget hurtigere at skrive 10 liniers let skreven, let forstående og selvdokumenterende kode, i stedet for at sidde og gruble over hvordan man får krympet det hele ned til en linie fuldstændig uoverskueligt klyt.

/Christian

  • 0
  • 0
Peter Juhl Christiansen

Det handler jo ikke om at tilstræbe så få linjer kode som muligt.

Det handler om at skrive overskueligt og let læselig kode, og det viser sig bare at det samme problem fylder mere at beskrive i et sprog frem for et andet.

Så når man skal lave noget om eller finde en bug betyder det naturligvis noget om man har 20.000 linjer kode eller kun 10.000.

Så når folk siger at de kan beskrive et problem i Clojure ved færre linjer kode, så er det, efter min mening interessant fordi programmering handler om at beskrive løsninger og formidle dem både til CPU'en og til mennesker.

  • 0
  • 0
Slet Mig nu

At lave en sammenligning af sprog på baggrund af antal linjer kode svarer lidt til den famøse diskussion af ODF vs. OOXML i forhold til antal sider i en standard.

Hvordan skal linjerne tælles i forhold til at finde fejl? Hvis der er 5000 linjer i et velkendt open source library der bruges af mange over hele verden tæller linjerne på samme måde som hvis man skriver selv 5000 linjer? Hvis ens Java kode på 50 linjer kalder et library på 5000 linjer er det bedre eller værre end 100 linjer Ruby kode? Er 10 dage udvikling i SPROG-X værre eller bedre end 20 dage SPROG-Y kode hvis det tager en halv dag mere at fejlrette i SPROG-X? Hvad hvis firmaet har svære ved at finde folk som kan SPROG-X?

Alle sprog har deres fordele og ulemper når de vurderes i den sammenhæng som de skal anvendes, i udviklingsperioden, i en produktionsrettelse situation m.m.

  • 0
  • 0
Christian Nobel

At lave en sammenligning af sprog på baggrund af antal linjer kode svarer lidt til den famøse diskussion af ODF vs. OOXML i forhold til antal sider i en standard.

Helt enig.

Vi kunne jo lave en tilsvarende sammenligning mellem to ikke eksisterende programmer, begge med formål at låse en dør op og gå indenfor:

Klartsprogsprogram:

Tag nøgle fra lomme;
Skub nøglen ind i låsen;
Drej nøglen ½ omgang mod uret;
Drej nøglen tilbage;
Træk nøglen ud;
Læg nøglen i lommen;
Tryk dørhåndtag ned;
Skub døren væk fra dig selv;
Gå ind;

Komprimeret mister mox program:
noe^lo-->laa<\½|½/>laa<--lo<--no|^^doe>>enter;

Gad lide at vide hvad der er hurtigst at skrive inklusive tænkearbejdet?

Og hvor lang tid tager det så at opdage en bøf i klartsprogsprogrammet sammenlignet med mister mox programmet?

/Christian

  • 0
  • 0
Peter Juhl Christiansen

Til Kent (og andre)

Jeg er enig diskutionen er forsimplet, som den slags ofte er.

Men mit indlæg var et svar til dem der ikke forstod at det overhovedet ku være vigtigt om et sprog var i stand til at beskrive et givent problem på en kortere (og ofte) mere præcis måde.

Det synes jeg bestemt det er, og synes derfor vi skal forsætte bestræbelserne på at udvikle bedre måder at lave software på. (og defor er Clojure interessant)

Så jeg forsøgte at nuancerer debatten, at der er mange andre faktorer i spil når man vælger sprog er jeg enig i, så for min skyld kan godt nuancerer debatten mere i den retning :-)

Skal man nuancerer debatten om Clojure er hele ideen at der i sproget er en klar concurency model bygget ind i sproget som hvis man ellers kan lide den model gør det nemmere at lave "fler trådet" programmer, samtidig med at man har alle Java's mange og vel testede biblioteker.

Efter som programmer med mere end en tråd nok er kommet for at blive, er sprog el. der førsøger at takle dette problem bedre end det vi har idag bestemt værd at studerer.

  • 0
  • 0
Lars Tørnes Hansen

Parallelitet er eksplicit udtrykt i koden for LISP sprog:

Eksempel:
(f1 (f2) (f3))

gør det klart at funktionerne f2 og f3 kan udføres parallelt.

SBCL CLISP compileren oversætter til maskinkode. Der er en gut der arbejder med benchmarking af forskellige sprog. For SBCL går det ret godt, især efter en optimering hvor habns fibonacci CLISP kode kan koges ned til 44 maskinkode instruktioner.
Se mere på:http://lists.canonical.org/pipermail/kragen-tol/2007-March/000852.html

  • 0
  • 0
Torben Mogensen Blogger

Man hører tit C-programmører argumentere, at man ikke kan opnå samme afviklingshastighed med et højereniveausprog, da man i C er meget tæt på maskinen.

Det er i stor udstrækning rigtigt nok, men der er nogle forbehold:

  1. Man kan ved at kode tæt på maskinen I C lave et program, der er næsten optimalt for denne bestemt maskine, men så snart du flytter koden til en anden maskine, kan den sagtens være særdeles suboptimal. Det gælder specielt, hvis du koder til en parallel maskine.

    1. For ikke-trivielle problemer tager det ofte [i]meget[/i] længere tid at udvikle koden i C end i et højereniveau sprog.

    2. I reglen bruges 90% af køretiden i 10% af koden (og dette gælder rekursivt), så der er ikke vundet noget ved at bruge C som hovedsprog. Det er i reglen bedre at bruge et højniveausprog, og efter behov adskille de tidskritiske dele i biblioteksfunktioner, der kan skrives i et mere maskinnært sprog. Det har endvidere den fordel, at det er (forholdsvist) nemt at erstatte disse funktioner med andre, når man skifter til en anden maskine, hvor de oprindelige "optimeringer" ikke er så relevante længere.

Hvad angår antallet af kodelinjer, så kan det være svært at sammenligne æbler og appelsiner, men jeg har gennem tiden set flere undersøgelser, der viser i retning af, at tiden pr. linje (forudsat det samme gennemsnitlige antal tegn pr. linje) er stort set uafhængig af sproget. En undersøgelse fra 70'erne sagde, at en gennemsnitlig programmør uanset sprog (APL, assembler eller COBOL) kunne lave 5 linjer kode om dagen, hvis man inkluderede hele processen fra kodeskitser/diagrammer, koden, afprøvning, osv. inklusive fejlretning efter koden tages i brug.

Det lyder ikke af meget, men her er tale om kodelinjer, der skrives helt fra bunden, ikke copy-paste-modify kodning, som er reglen i dag.

Men der er selvfølgelig forskel på kode. Kode, der sætter et skærmbillede op kan fylde en masse, men det er i reglen hurtigt skrevet, mens f.eks. en quicksort funktion kan tage en del tid at få lavet korrekt, selv om det er ganske få linjer. Og, om Christian skriver, kan man ofte gøre kode kortere (og mindre læselig) ved at bruge mere tid.

  • 0
  • 0
Jesper Louis Andersen

Parallelitet er eksplicit udtrykt i koden for LISP sprog:

Eksempel:
(f1 (f2) (f3))

Lige et godt råd: Common Lisp skal du passe på med at kalde CLISP. CLISP er en CL-implementation, ligesom SBCL og CMUCL er det.

Hvis f2 og f3 har sideeffekter er det ikke oplagt at de kan udføres i parallel. Som regel er der givet en evalueringsrækkefølge for den slags udtryk (Hvis jeg husker rigtigt er det givet for CL men ikke for Scheme).

  • 0
  • 0
Jesper Louis Andersen

Det er efter min mening et meget godt eksempel på hvordan man IKKE skal skrive kode og hvorfor disse bastard funktionelle konstruktioner som har set dagens lys i Scala og som man har forurenet C# er en katastrofe

Det afhænger til dels af hvor vant man er til at læse den type kode. For en erfaren ruby-programmør vil jeg tro at linien nærmest "giver sig selv". Det er korrekt at det kan overgøres som så meget andet - men man må til dels acceptere en del tilvending.

Jeg har ikke læst Ruby siden 2003 men det tog mig ca. 20 sekunder at forstå den linie. Til gengæld ville jeg nok skulle have brugt mere tid i C# eller Java - man skal være "i træning" for at kunne læse kode.

  • 0
  • 0
Jesper Louis Andersen

Lige som med Python kan jeg ikke se ideen med parallelisme, hvis koden eksekveres en faktor 500 - 1000 langsommere end C.

Det er det, jeg kalder for "Parallel Performance Gap". Det er muligt at du bedre kan beskrive problemet i Erlang, men hvis problemet er en faktor 30 langsommere end et single-CPU C-program så skal dit (pinligt parallelliserbare) problem altså køres på en maskine med mindst 30 gange så mange kerner før det giver mening. Det bliver klimaet ikke glad for...

  • 0
  • 0
Peter Juhl Christiansen

Nu er der altså forskel på parallelisering og på "concurrency". Og et sprog som Erlang er særligt fikst til problemer der er "concurrent" af natur, som fx en server.

Så skal man lave en server i C er den ikke til ret meget hvis den er kun har en tråd, dvs man skal løse problemet med at få sin server multitrådet om man vælger C eller erlang, men det sidste tager dig meget kortere at få rigtigt fordi sproget hjælper dig.

Selvom jeg ikke selv har skrevet en server i erlang kan jeg garanterer at den IKKE er 30 gange langsommer, den kan formodentlig sagten være hurtigere.

  • 0
  • 0
Slet Mig nu

Jeg ser jævnligt folk som inderligt gerne vil have at netop deres ynglings sprog er bedre, hurtigere eller lignende i forhold til gængse sprog som Java, C# eller hvad man nu kan finde på. Som killer-app finder de ofte frem eksempler som quicksort eller at finde det største tal i en liste af heltal. Uden tvivl ser det valgte eksempel godt ud, alt ser jo godt ud i en demo. Desværre glemmer de fleste at projekter typisk er anderledes end at implementere quicksort og at der er mange måder at vurdere et sprog på, f.eks.:

  1. Hvor hurtig tager det at udvikle en løsning på et givet problem.
  2. Hvor hurtig er time-to-resolution in en incident/change-situation
  3. Hvor lang tid skal en mand bruge på at blive ferm til at bruge sproget i en professionel situation
  4. Hvor stor markedspenetrering har sproget; vil det være nemt at finde en mand som kan udvikle/supportere/... en løsning og kan man stjæle en masse fra andre (f.eks. Apache) eller skal man lære en mand op hver gang.

og mange flere. Ovennævnte briller er med et firmas, det er lidt anderledes hvis man laver et hyggeprojekt til klubben.

Hvorom alt er, hvordan tæller man op? Det kan være uhyggelig nemt at kode en multi-threaded og distribueret server i et bestemt sprog, men hvis den underliggende virtual maskine er langsom eller hvis den kompilerede native kode er ikke optimeret godt så bliver slutresultatet skidt. Ruby/Clojure/Scala/... kan være nok så hurtig at udvikle i forhold til C,C++, ... men hvis slutresultatet ikke har den nødvendige performance set fra brugerens synspunkt så hjælper det ikke. Så har du fejlet. Det mødes ofte med kommentaren om at jeg kan skrive dynamisk kompileret kode som bliver optimeret bedre end C, C++ og så valgte du i det tilfælde et bedre sprog end C sprogene set i forhold til runtime-afvikling-performance aspektet.

Vurdering af et sprog er ekstremt kontekst afhængigt, så Version2 drop nu de her 'Java er død', 'Se min quicksort i Ruby' m.m. artikler og begynd at skrive om større projekter i Danmark hvor der er erfaringer med sprog som Ruby, Clojure, ... i fasen hvor der skal findes folk med kompetencer, udviklingsfasen, produktionssupportfasen m.m. Og få nu mange forskellige aspekter med.

  • 0
  • 0
Torben Mogensen Blogger

Yderligere vigtige kriterier for valg af sprog:

  1. Findes der flere uafhængige implementeringer af sproget?
  2. Er sproget beskrevet entydigt og præcist?
  3. Findes der godt lærebogsmateriale til sproget?
  4. Er sproget nogenlunde stabilt eller er det stadig under forandring?

Ikke alle kriterier er lige vigtige for alle. Til små hobbyprojekter er de ovenstående kriterier ikke vigtige, men til større projekter med lang levetid, er de efter min mening ret vigtige.

Det skal dog ikke forhindre firmaer i at bruge nye, endnu ikke færdigudviklede sprog til langsigtede projekter, men så bør firmaerne selv deltage aktivt i udvikling og specifikation af sproget.

  • 0
  • 0
Kresten Krab Thorup

Erlang er et andet sprog, der har vundet mange fans på grund af sin evne til parallelisme. Men Lau Jensen er ikke vild med den såkaldte Actor-model, da den ikke er så effektiv eller sikker, som man skulle tro. I bogen "Programming in Scala" fra det ellers velrenommerede forlag O'Reilly gives et eksempel med Actors, som fejler under pres.

Dette må være en grov forsimpling af hvad Lau har sagt om dette emne, den slags ting der sker når en journalist skal formidle så kompliceret stof.

Man kan jo ikke klandre Erlang for problemer i et Scala library. Netop stabilitet, og evnen til at reagere på pres er ting som Erlang excellerer i; eller rettere sagt det er problemstillinger som Erlangs bibliotek OTP har politikker for, og måder man kan konfigurere på.

Netop dette er jo et godt eksempel på, hvorfor det er mere interessant at lære Erlang end Scala. Det er en 20 år gammel, solid, gennemtestet platform, som har set alle de her problemer før.

Et uddsagn som "Actor modellen er ikke så effektiv eller sikker, som man skulle tro" siger jo ikke meget. Hvad tror du? Det er bare mudderkastning, eller misforståelse. Man kunne jo fristes til at sammenligne det med udsagn som, at "Clojure er ikke så gennemprøvet som man skulle tro", eller "Det går bedre med Laus mavefornemmelse, end ventet". Hvad havde du ventet?

Jeg skrev i øvrigt en lille bløb om actor modellen på min blog i går, som fik en del medvind rundt omkring: http://bit.ly/6f0pj7

  • 0
  • 0
Tania Andersen

Dette må være en grov forsimpling af hvad Lau har sagt om dette emne, den slags ting der sker når en journalist skal formidle så kompliceret stof.

Der tager du fejl, Kresten. Det er nøjagtigt hvad Lau Jensen sagde i det båndede interview. Og han fik citatet til eftersyn før publiceringen.

Mvh Tania
Version2

  • 0
  • 0
Kresten Krab Thorup

Der tager du fejl, Kresten. Det er nøjagtigt hvad Lau Jensen sagde i det båndede interview. Og han fik citatet til eftersyn før publiceringen.

OK, det var så et fejlslagent forsøg på at prøve at nuancere diskussionen uden at latterliggøre Lau. Det må du undskylde Tania, det var ikke henvendt til dig.

  • 0
  • 0
Log ind eller Opret konto for at kommentere