henrik knopper bloghoved

JAOO: Funktionelle sprog

Tirsdag morgens keynote blev holdt af Simon Peyton-Jones, en af udviklerne bag sproget Haskell.

Sproget har i snart 20 år levet en obskur akademisk tilværelse og ligger p.t. næstnederst på listen over praktisk anvendte sprog.

Derudover er det et sprog der er så svært at lære så bare det at sige at man koder i Haskell giver respekt. Men ikke nødvendigvis produktivitet...

Så hvorfor bruge tid på det?

Fordi det er et meget rent funktionelt sprog hvor hovedparten af funktionaliteten ikke ligger i sideeffekterne og i øvrigt ligger det nr 6. på listen over sprog folk taler om (står ret langt nede på siden).

Og så er Simon Peyton- Jones en erfaren underviser og han formåede virkelig at gøre det levende.

Men i en verden hvor alle problemstillinger i forretningslivet pr definition kan klares på engelsk er det meget svært at forstå hvorfor der forskes så meget i at udvikle nye sprog som giver lidt bedre mulighed for at beskrive en given proces.

Det ville jo svare til at men skulle lære japansk på handelshøjskolen for at kunne udtrykke Jinba Ittai, og det er jo absurd.

Det ville da være bedre at bruge ressourcerne på at tilrette problemet så det kunne kodes i C#.

Eller ville det?

Der er jo stadig mennesker der lærer dansk for at kunne læse Kierkegaard uden filter.

Er 'engelsk som koncernsprog' udtryk for en meningsforstyrrende forsimpling af de problemer en global virksomhed står overfor?

Jeg kommer nok aldrig selv til at mester Haskell, men det var en god reminder om at det nogen gange er sproget der sætter både synsvinklen på og grænserne for problemet og dets løsning.

Så selvom den løsning man kan formulere altid er den bedste er den ikke nødvendigvis den rigtige.

Kommentarer (22)
sortSortér kommentarer
  • Ældste først
  • Nyeste først
  • Bedste først
Torben Mogensen Blogger

Her synes jeg tværtimod, at den succes, som de objektorienterede sprog har haft, primært skyldes markedsføring: Man har sagt, at nar man skal arbejde med ting/objekter fra den virkelige verden, så skal man selvfølgelig bruge et objektorienteret sprog, for det er designet netop til at modellere virkelige objekter.

Det er selvfølgelig noget vås. Hele sprogbrugen om objekter, klasser, metoder, nedvarvning, osv. bruger dagligdags ord om programmeringsbegreber, der ikke har en fløjtende is med de dagligdags ord at gøre.

Funktionssprog misleder ikke på samme måde. En funktion er præcis det den udgiver sig for: Det man i skolens matematiktimer kalder en funktion. Og en værdi er det man i skolens matematiktimer kalder en værdi.

Peter Lundsby

Det er selvfølgelig noget vås. Hele sprogbrugen om objekter, klasser, metoder, nedvarvning, osv. bruger dagligdags ord om programmeringsbegreber, der ikke har en fløjtende is med de dagligdags ord at gøre.

Det er jeg komplet uenig med dig, alle de begreber, er jo til for at beskrive, den virkelige verden. Og hvis man beskæftiger sig lidt med objekt-orienteret analyse, så vil man opdage at det de er fortrinelige til formål. Langt mere medgørlige end hvis man skulle sætte verdenen på matematiske formler. Grunden til dette er at en given handling i den virkelige verden, ofte har sideeffekter og at tilstande af egenskaber på objekter ændre sig.

Når vi snakker analyse og design, så er objekt-orientering klart overlegen i forhold til den funktionelle tilgang. Men under selve implementeringsarbejdet, så har de funktionelle sprog en nogle væsentlige features, som man bare ikke finder i imperative sprog.

Det er derfor jeg tror på hybrid sprogene, som f.eks. Scala og F#. De bringer det bedste af begge verdener sammen!

Torben Mogensen Blogger

Det er jeg komplet uenig med dig, alle de begreber, er jo til for at beskrive, den virkelige verden.

Man kan beskrive den virkelige verden i alt, bare man laver en passende modelleringsrelation. Men at den type objekter, som findes i OO-sprog, skulle gøre dette lettere end andre datastrukturer, kan jeg ikke se. Der skal alt for meget udenomssnak for at modellere så simple begreber som par og alternativer.

Langt mere medgørlige end hvis man skulle sætte verdenen på matematiske formler.

Hvis du med matematiske formler mener formler over tal, så har du ikke forstået, hvad funktionssprog går ud på: Det er netop til begreber, der ikke er tal, at funktionssprog rigtigt kommer til deres ret.

Når vi snakker analyse og design, så er objekt-orientering klart overlegen i forhold til den funktionelle tilgang.

Kun hvis det eneste man har lært om analyse og design er objektorienteret analyse og design. Og desværre er det i reglen kun det man lærer på it-uddannelserne. Analyse og design, der bygger på datastrukturer, funktioner og relationer er (efter min mening) meget nemmere at arbejde med.

Peter Lundsby

Der skal alt for meget udenomssnak for at modellere så simple begreber som par og alternativer.

Jeg ikke det svære i at modellere par som en klasse. Er ikke helt sikker på hvad du mener med alternativer, men mon ikke også man kunne modellere klasser.

Hvis du med matematiske formler mener formler over tal, så har du ikke forstået, hvad funktionssprog går ud på

Hvor kom det fra! Har jeg skrevet at det var formler over tal? Jeg er bestemt godt klar over at matematik er andet og mere en tal. Så dårlig er informatik-linjen på DTU heller ikke.

Men hvorfor forholder du dig ikke til essensen, nemlig at en given handling i den virkelige verden, ofte har sideeffekter og at tilstande af egenskaber på objekter ændre sig.

Det er meget basalt, jeg er idag 33 år gammel og næste gang jeg har fødselsdag, så bliver jeg 34.
I et objekt-orienteret sprog, vil jeg stadig være den samme person (instans) selvom jeg bliver ældre. Mens jeg ikke et funktionelt sprog, ville være en ny (hvilket selvfølgeligt godt kan være sandt på et filosofiskplan, men nok er imod de fleste menneskers intuition).

Kun hvis det eneste man har lært om analyse og design er objektorienteret analyse og design.

Ironisk nok er den første formelle undervisning jeg har modtaget, indenfor emnet, netop i den funktionelle tilgang, og jeg må sige at jeg ikke er imponeret. Og slet ikke efter at havde at havde sat mig ind i analyse og design udfra en OO-tilgang.

Jeg overhørte iøvrigt engang en forlæser på DTU, fortælle at han, ikke troede på OO-tilgangen, fordi han havde undervist i et hold i OOP og den kode, de havde lavet havde et ihvertfald været noget værre rod. Men efter at havde snakket med ham et par minutter, blev det klart at han ikke havde forstået noget som helst omkring OO-design og ikke ville kunne genkende et Design-pattern selvom det ramte ham lige imellem øjnene.

Selv har jeg lidt et ben i hver lejr, jeg glæder mig meget til at kunne skrive dele af min kode som funktionel. Men jeg ville være meget ked af at undvære OO-analyse og design som værktøjer.

Torben Mogensen Blogger

Jeg [ser] ikke det svære i at modellere par som en klasse.

I f.eks. SML og Haskell skriver man et par af en string og et tal som f.eks. ("hammer",6). I OO sprog skal du først definere en klasse med to felter og derefter kalde en konstruktor på denne klasse. Og du skal lave en ny klasse, hvis du vil have par af f.eks. tal og sandhedsværdier.

Er ikke helt sikker på hvad du mener med alternativer, men mon ikke også man kunne modellere [det med] klasser.

Selvfølgelig kan du det. Du kan også modellere det som en sekvens af bit.

Et alternativ er i denne kontekst, at noget kan være en ud af to eller flere forskellige ting, f.eks. at en figur enten er en cirkel defineret ved centrum og radius eller en rektangel defineret ved to punkter.

I Haskell definerer du blot en datastruktur, der siger

[code=haskell]
type Punkt = (Double,Double)
data Figur = Cirkel (Punkt, Double)
| Rektangel (Punkt,Punkt)
[/code]

I f.eks. Java er det ikke voldsomt svært at definere et punkt (med det kræver noget mere kodetekst). For at definere figurer skal du først lave en abstrakt superklasse og derefter en nedarvet klasse for cirkel og en anden for trekant.

Nar du så i Haskell vil definere en funktion, der finder arealet af en figur skriver du

[code=haskell]
areal(Cirkel (_,r)) = r^2
areal(Rektangel ((x1,y1),(x2,y2)))
= abs((x2-x1)*(y2-y1))
[/code]

I Java skal du tilbage og modificere både en abstrakte klasse og dens underklasser ved at tilføje en areal() metode.

Du vil sikkert argumentere for, at arealet er en egenskab ved figuren, og derfor bør være en del af figurens type. Men med den tankegang skal man ved definitionen af figurtypen forudsige alle de operationer, man vil lave på figurer. Hvis jeg f.eks. senere vil finde den mindste bounding box til en figur, kan jeg i Haskell blot definere en ny funktion, mens jeg i Java skal tilbage og rette i klassedefinitionerne.

Men hvorfor forholder du dig ikke til essensen, nemlig at en given handling i den virkelige verden, ofte har sideeffekter og at tilstande af egenskaber på objekter ændre sig.

Det er meget basalt, jeg er idag 33 år gammel og næste gang jeg har fødselsdag, så bliver jeg 34.
I et objekt-orienteret sprog, vil jeg stadig være den samme person (instans) selvom jeg bliver ældre. Mens jeg ikke et funktionelt sprog, ville være en ny (hvilket selvfølgeligt godt kan være sandt på et filosofiskplan, men nok er imod de fleste menneskers intuition).

Det er ikke særligt smart at have alderen liggende som en opdaterbar værdi. Det er langt nemmere at havde fødselsdatoen liggende som immutabel værdi. Så skal du ikke opdatere alderen hvert år, men blot sammenligne med dags dato.

Og hvornår er din alder blevet opdateret ved, at der var en eller anden, der anvendte en metode på dig?

Lad os tage en bankkonto som et andet eksempel. En OO tilgang vil sige, at en konto er en værdi, der bliver opdateret med "hæv" og "sæt ind" metoder. En funktionel tilgang vil være, at en konto er en liste af hæv/indsæt transaktioner, hvor man kan tilføje nye transaktioner uden at destruere de tidligere (det vil faktisk være ulovligt at gøre dette). Saldo er da en funktion af listen af transaktioner.

Saldo kan beregnes inkrementelt, så man ikke, hver gang man skal se saldoen, skal helt tilbage til Adam og Eva, men som modelleringsbegreb er det fint blot at betragte kontoen som en liste af immutable transaktioner. Resten er blot en optimering. Jeg kan ikke se en ligeså elegant modellering som objekter.

Claus Jørgensen

Nar du så i Haskell vil definere en funktion, der finder arealet af en figur skriver du

I C# kan du gøre det samme med en extension metode, men haskell versionen er jo i princippet mere funktioner med overloads, end at hvert objekt har dets egen areal metode.

Så det handler om hvordan du ser på det.

OO:

> Cirkel.UdregnAreal(parametere);
> instanceAfCirkel.UdregnAreal();

Funktionelt:

> UdregnAreal<Cirkel>(parametere);

Jeg synes personligt ikke at en monadistisk tilgangsvinkel er bedre eller tilbyder bedre concurrency end ellers.

Derudover synes jeg at det er mere logisk at arealet af en cirkel er gruppet med en Cirkel, end at funktionen er grupperet med andre areal funktioner.

Min formelsamling har også alt cirkel matematik samlet, ikke alle areal formler samlet samme sted.

Og samtidig giver Haskell's tilgang mindre strukturet kode, og kræver meget mere disciplin i navngivning af sin filstruktur.

Peter Lundsby

I f.eks. Java er det ikke voldsomt svært at definere et punkt (med det kræver noget mere kodetekst).

Du glemmer lidt, at vi snakker analyse og design-fasen, så jeg skal slet ikke skrive noget Java, jeg er ved at tegne et diagram over domænemodellen og de klasser jeg føler er intuitivt forstået har jeg ikke tænkt mig at definere nærmere på dette tidspunkt.
Mit diagram kan jeg vise til repræsentater for forretningen, som efter min erfaring så kan hjælpe mig med at forstå problemet bedre.
Hvis der er nogle specielt kritiske forløb, tegner jeg sekvens diagrammer, som viser hvordan interaktionen forgår det kan jeg igen, bruge som materiale overfor forretningen som kan hjælpe mig med at forstå hvad der skal bygges!

Det er ikke særligt smart at have alderen liggende som en opdaterbar værdi. Det er langt nemmere at havde fødselsdatoen liggende som immutabel værdi.

Nu snakker du igen implementation (hvor iøvrigt er enig med dig både i tilfældet med alderen og bankkonto), men som sagt er vi i enten analyse eller design-fasen, og specielt i analyse-fasen kan det give rigtigt god mening at modellere alderen som en egenskab, jeg har ihvertfald selv svært ved at se det nyttige i at forklare en bruger at vi har taget fødselsdatoen med, fordi vi så kan udregne alderen, hvis det kun er alderen der er relevant i den pågældende sammenhæng. Det samme med Bankkontoen hvis det kun er saldoen, der er relevant for den opgave der skal løses, så vil jeg helt klart gerne kunne modellere det som bare en saldo, og ikke som en transaktionsliste og en funktion der kan udregne saldoen.

OO analyse og design, tilbyder en række værktøjer såsom klassediagrammer, sekvensdiagrammer, usecases etc. til at forstå hvad der skal bygges. Og jeg synes bare ikke jeg har set ligende værktøjer med den funktionelle tilgang! (Men det kan selvfølgeligt bare være at der er noget jeg har misset!)

Jeg tror at for langt den overvejende-del af dem der arbejder i erhvervslivet med udvikling idag, er netop problemstillingen, med at finde ud af hvad der skal bygges, helt central. Og jeg mener helt klart at OO's succes i høj grad kan tilskrives, at den hjælper netop med dette problem.

Nu er det noget tid siden jeg har læst den, men jeg mener at Frederik Brooks i Mythical Man Month, kalder netop problemet med at vide hvad der skal bygges, for essensen af programmering.

Nikolaj Brinch Jørgensen

@Torben
At sige at objektorienterede sprog er dårligere end de funktionelle er vel lige at gå lidt langt.

At funktionelle sprog generelt er bedst fordi de beskriver matematikkens verden bedst er kun sandt, hvis det var fordi al programmering handler om matematik - men sjovt nok er det kun en lille del af programmering der handler om matematik. Til den del kan vi med fordel anvende de funktionelle sprog.

Det er måske også derfor at funktionelle sprog finder størst udbredelse på universiteter og lignende, hvor de har nogle store kværne og laver matematiske simuleringer.

I forretningsverdnen (der hvor der bliver udviklet allermest software), har matematikken i dens rene form kun lidet betydning. Der er det menneskelige processer der betyder noget, og man skaber modeller af den virkelig verden. Altså ville det være rart om man brugte et programmeringssprog der lader udvikler nemmest oversætte kravene til faktuel kode. Her har de objektorienterede eller de forretningsorientede (læs: COBOL) programmeringssprog størst udbredelse - måske af den grund at de bare udtrykker dette bedre, og mere produktivt.

Til operativsystemer har vi igen brug for noget andet, og derfor er de alle (jeg ved der er nogle obskure operativsystemer der afviger) implementeret i C og assembler/maskinkode.

At man så nu fremstiller hybridsprog der låner fra hindanden (Scala, Groovy, Ruby ...) er da kun dejligt for udviklerne, så kan de løse vores problemer mere effektivt.

SÅ glem nu det der fanboyisme om at mit programmeringssprog/-paradigme er bedre end dit, for det er og bliver noget vrøvl. Se på opgaven der skal løses og vælg det rigtige værktøj.

/NEKO

Baldur Norddahl

I f.eks. SML og Haskell skriver man et par af en string og et tal som f.eks. ("hammer",6). I OO sprog skal du først definere en klasse med to felter og derefter kalde en konstruktor på denne klasse. Og du skal lave en ny klasse, hvis du vil have par af f.eks. tal og sandhedsværdier

Et lille sidespor - der er ikke nogen god grund til at java ikke har en indbygget java.util.Pair klasse i stil med:
[code=java]public class Pair<T1,T2> {
public T1 v1;
public T2 v2;
public Pair(T1 v1, T2 v2) {
this.v1 = v1;
this.v2 = v2;
}
}[/code]
Så kan man klare opgaven med new Pair<String,Integer>("hammer",6).

Torben Mogensen Blogger

Baldur skrev:

Et lille sidespor - der er ikke nogen god grund til at java ikke har en indbygget java.util.Pair klasse i stil med: ....

Så kan man klare opgaven med new Pair<String,Integer>("hammer",6).

Ja, efter at der er kommet generics i Java, kan man gøre den slags. Men det kræver stadig omkring tre gange så meget tekst at bygget parret, end det gør I Haskell eller SML. Og inden generics (som iøvrigt har sin oprindelse i funktionelle sprog), skulle man definere en ny klasse, hver gang man skulle bygge en ny slags par. Eller bruge et par af to Objects og downcaste, når man ville have fat i komponenterne.

Nicolai skrev:

I forretningsverdnen (der hvor der bliver udviklet allermest software), har matematikken i dens rene form kun lidet betydning. Der er det menneskelige processer der betyder noget, og man skaber modeller af den virkelig verden. Altså ville det være rart om man brugte et programmeringssprog der lader udvikler nemmest oversætte kravene til faktuel kode. Her har de objektorienterede eller de forretningsorientede (læs: COBOL) programmeringssprog størst udbredelse - måske af den grund at de bare udtrykker dette bedre, og mere produktivt.

Sjovt nok er forretningsverdenen netop der, hvor funktionssprog har mest udbredelse i erhvervslivet. :-)

SÅ glem nu det der fanboyisme om at mit programmeringssprog/-paradigme er bedre end dit, for det er og bliver noget vrøvl. Se på opgaven der skal løses og vælg det rigtige værktøj.

Det var sådan set også min pointe. Mine indlæg er primært en reaktion mod de indlæg, der udtrykker den holdning, at funktionssprog er irrelevante, da OO sprog er bedre til både modellering og implementering.

Jeg programmerer heller ikke alt i funktionssprog. Lige nu er jeg ved at rode med noget GUI, og der bruger jeg JavaFX, og f.eks. landkortsgenereringsprogrammet på min hjemmeside er skrevet i C. Sidstnævnte er mestendels masser af formler og meget lidt datastrukturer, så der er ikke nogen voldsom fordel ved at bruge et funktionssprog.

Torben Mogensen Blogger

At funktionelle sprog generelt er bedst fordi de beskriver matematikkens verden bedst

Den non sequitur må være for din egen regning. Min pointe var, at navngivningen af sprogelementer i funktionelle sprog ikke foregiver at tingene er andet, end de er, mens sprogbrugen i OO sprog er misledende fordi den bruger dagligdags ord om noget, der ikke ligner de ting, ordene normalt bruges om. Det siger ikke i sig selv noget om sprogenes kvaliteter, men en del om hvordan de markedsfører sig selv.

Nikolaj Brinch Jørgensen

Sjovt nok er forretningsverdenen netop der, hvor funktionssprog har mest udbredelse i erhvervslivet. :-)

du kommer bare med en stak beviser på at vi bruger funtionssprog til implementering i erhvervslivet mest. Nævn projekterne, hvor det ikke er C/C++, Java, C#, COBOL osv. af de imperative sprog der er dominerende.

Det var sådan set også min pointe. Mine indlæg er primært en reaktion mod de indlæg, der udtrykker den holdning, at funktionssprog er irrelevante, da OO sprog er bedre til både modellering og implementering.

Du startede altså med at fortælle os at funtionelle sprog var bedre end OO sprog - det var ikke omvendt.
Nu trækker du måske i land?

Og inden generics (som iøvrigt har sin oprindelse i funktionelle sprog)...

Generics har sin baggrund i Templates fra C++ (de kan så vel være trukket fra funktionelle sprog).
Du kan da ikke begynde at sige noget om "inden generics". Vi kan også finde gamle udgaver af funktionelle sprog som hverken kan dit eller dat, det er ikke relevant. Det er relevatn hvorvidt et sprog kan noget i sin nuværende udbredte form.
Tynd is vil nogen måske sige? :-)

Baldur Norddahl

Generics har sin baggrund i Templates fra C++ (de kan så vel være trukket fra funktionelle sprog).

Generics og templates er to vidt forskellige koncepter.

Generics i Java er udviklet af Martin Odersky i sproget Pizza. Pizza blev senere viderudviklet til Scala og er netop et projekt der går på at integrere funktionsorienterede og objektorienterede sprog.

Baldur Norddahl

Ja, efter at der er kommet generics i Java, kan man gøre den slags. Men det kræver stadig omkring tre gange så meget tekst at bygget parret, end det gør I Haskell eller SML

I betragtning af at java er et sprog der udvikler sig med en hastighed sammenlignelig med en gletscher, så skal vi vist være glade for at det kun er tre gange så meget tekst. Det ville hjælpe hvis java havde typeinferens.

Scala klarer samme opgave med præcis samme syntaks som SML.

Men selvom programmer i Scala er meget kortere end tilsvarende programmer skrevet i Java, så er det velkendt at programmer skrevet i f.eks. SML er endnu kortere.

Torben Mogensen Blogger

Men selvom programmer i Scala er meget kortere end tilsvarende programmer skrevet i Java, så er det velkendt at programmer skrevet i f.eks. SML er endnu kortere.

Ja, og SML er endda forholdsvis ordrig i forhold til f.eks. Haskell: I Haskell skal du f.eks. ikke skrive "val" og "end" ved let-udtryk, og [i]list comprehensions[/i] gør nogle ting meget kompakt i Haskell.

Fredrik Skeel Løkke

Som måske desværre gik tabt i nogle sprog detaljer..

Mht. funktionelle sprog og design/analyse fasen, så er det min opfattelse at en af hovedværktøjerne her er

type signaturer

(typisk "arrow types") i modsætning til UML. Jeg bygger den antagelse på interviews, om hvordan de arbejder med modellering, med bl.a. simon peyton jones og eric meijer!

Nikolaj Brinch Jørgensen

Når nu der hele tiden refereres til Haskell og SML, skulle man så ikke også sammenligne med Erlang, XQuery, XSLT og andre mere udbredte anvendelser af det funktionelle programeringsparadigme?

Der er ikke rigtig nogen der bruger Haskell og/eller SML i store virksomhedsløsninger, hvor godt nogen så synes det ellers ville være.
Realiteten er også at de store udbydere ikke supportere disse sprog.
At Jaskell og Scala er supporteret i form af at de kører på en JVM, gør ikke at virksomhederne kaster sig over dem, heller ej udbyderne af software.

Så når nogen mener at Haskell er bedre end Java er det jo en personlig subjektivt og følelsesladet holdning - og den har man ret til at have.

Man kan dog ikke forvente at andre er enige i ens subjektive holdinger.

Sidste gang vi skulle kaste os over de funktionelle programmeringssprog var det på grund af SML var enormt typestærkt, og Java er både typestærkt men også typesvagt og derfor var det dårligt.

Den købte vi heller ikke, for som egentlig betyder noget er brugbarheden, kvaliteten og prisen på det der frembringes med det valgte værktøj (være det funktionelt, proceduralt, objektorieteret eller ingen af delene).
Af ovenstående er både brugbarhed og kvalitet subjektive bedømmelseskriterier afhængig af situationen, men pris oftest ikke er det.
Og ingen har været i stand til endnu at godtgøre om det er billigere at implementere en løsning i SML eller dynamisk typede sprog som PHP/Perl/Python/Ruby...

Altså dem vi laver software til er temmlig ligeglade med om det er lavet i det ene eller andet. De tænker ikke "nej jeg må hellere købe en Garmin GPS for den er implementeret i Haskell", de køber den de subjektivt synes er bedst til prisen - og sådan skal det også være.

Og så lige dem der slås med hvem der kom først. Det gjorde funktionel programmering (50'erne), Dvs. der var nogen der fandt ud af at man ikke kunne alt det man gerne vill med de funktionelle programmeringssprog, så man opfandt... Objektorienteret programming (60'erne).
Ikke at nogen af dem er bedre end andre, men at vi har behov for begge.

Jesper Louis Andersen

Siden Erlang nu bliver nævnt...

Erlangs ideer er ikke dårlige til at løse de parallelle problemer vi står over for. I grunden kan visse af disse ideer også overføres til det objektorienterede paradigme, hvilket blandt Niklaus Wirth har nævnt.

Erlang som sprog lader dog noget tilbage at ønske. Det er en rodebunke i samme stil som PHP eller Ruby er det - med hvad det så giver af styrker og svagheder. Sproget er endvidere dynamisk typet hvilket giver nogle irritationsmomenter ved implementering af programmer. I det Erlangkode jeg har skrevet ville 19/20 fejl være fanget af et statisk typesystem. Trivielt endda.

Erlang som implementation er rimeligt god. Der er nogle designvalg rundt omkring som gør at parallellismen i praksis ikke helt er indfriet endnu. Men der arbejdes på det og deres model gør at det er langt nemmere at få til at virke end eksempeltvist Java. Blandt andet er måden Garbage Collection foregår på i Erlang meget nemmere at arbejde med en Javas.

Peter Mechlenborg

@Jesper
"Sproget er endvidere dynamisk typet hvilket giver nogle irritationsmomenter ved implementering af programmer."

Nej, men det er en diskussion om fordele om ulemper ved typede og utypede sprog, og ikke Erlang. Med min Erfarring med Erlang er at dette ikke irriterende, tværdigmod.

@Jesper
"Der er nogle designvalg rundt omkring som gør at parallellismen i praksis ikke helt er indfriet endnu. Men der arbejdes på det og deres model gør at det er langt nemmere at få til at virke end eksempeltvist Java."

Kan du uddybe dette lidt mere? Jeg ser Erlang som en af de allerbedste platforme til parallellismen der findes i dag, specielt hvis man har brug for at få flere maskiner til at arbejde sammen. Erlang har bestemt svagheder, men parallellisme, mener jeg ikke er en af dem.

Jesper Louis Andersen

Erlang og typer: Erlang blev faktisk udstyret med et typesystem i sin tid af en Hr Peyton Jones (Haskell), men af flere grunde blev det ikke implementeret. At Erlang blev dynamisk typed skyldes at det var en Prolog i starten. Og prolog er utypet.

At Erlang kunne vinde noget med typer ses tydeligvis af det arbejde som "the dialyzer" laver: Grundliggende rekonstruerer den typerne og advarer hvor din kode muligvis er forkert. Desuden kan dialyzeren forstå nogle simple typespecifikationer, som du kan finde i stdlib'et. Med andre ord er det gået op for Erlang-folkene at typer er en rar ting. Men de implementerer det som en opt-in feature i stedet for at tvinge dig til at bruge det. Til gengæld er der så visse ting de ikke kan garantere med typesystemet.

Erlang som implementation: Indtil for nyligt (R13) var implementationen ikke parallel på en række væsentlige punkter. F.eks. var ETS-tables beskyttet af en lock så hvis dit program aggressivt benyttede sig af disse røg parallelt speedup sig en tur. Ligeledes var run-queuen låsebeskyttet. Begge dele er lavet om nu, men bemærk venligst at selv om Erlang har mulighederne for at være rigtigt godt til parallellisme, så er det først for nyligt at implementationen begynder at udnytte det.

Et andet problem i erlang er at din type-zoo ikke er særlig stor og varieret. F.eks. ses det ved at den kanoniske string er en liste af tal. Ie, hvert tegn fylder 16 byte på en 64-bit arkitektur og 8 byte på en 32-bit arkitektur. Du kan bruge binaries, men de er immutable, ref-counted og har en helt anden grundsemantik. At standardbiblioteket ikke har et alternativ skyldes nok at det ikke har været formålet med Erlang: At drive telefonswitche og servere.

Log ind eller Opret konto for at kommentere