Seven languages in seven weeks - Erlang

Det femte språket i boken Seven Languages in Seven weeks av Bruce Tate är Erlang. Ett språk som togs fram av Ericsson då inga andra var bra nog. Erlang har ett par designmål som skiljer det från andra språk. Det hanterar väldigt många saker parallellt. Språket är tar även ett annat grepp på felhantering som kort och gott går ut på att det är helt ok att en process dör ibland.

Erlang - dag 1
Erlang har fått en del inspiration från Prolog. Faktum är att man började med att modifiera Prolog för att få det resultat man önskade. Så mycket av syntaxen är relativt lik. Man har tuples, atoms. Men inga objekt.

Erlang är trots att det är ett högnivå-språk lämpligt att köra hårdvarunära då det finns stöd för att manipulera bits och bytes. Erlang dessutom ruskigt stora tal naturligt. Så många siffror du får plats med i minnet.

Precis som med Prolog använder man rekursiva strukturer för att lösa problem.

Erlang - dag 2
För en Java-utvecklare är annonyma funktioner inget nytt. Även om det skiljer en del mellan den objektorienterade approchen och den i Erlang. Dock blir det lite mer spännande i Erlang som som är dynamiskt typat. Funktionen du får kan ju vara vilken funktion som helst.

En styrka med annonyma funktioner är att du precis som i Ruby kan skriva en funktion som du kör på varje element i en lista och du kan enkelt återanvända dina funktioner på vilken lista som helst.

Erlang - dag 3
Dag tre går igenom de parallella verktyg som Erlang har. Principen är väldigt enkel och bygger på koncepten om Actors och Messages som vi sett tidigare. Det finns några inbyggda sätt att skapa processer och att skicka meddelanden till den kö som varje process är utrustad med. Sedan kommer processen att beta av kön ett meddelande i taget. Det är höggradigt asynkrona meddelanden som skickas så vill man åstadkomma synkrona meddelanden får man ta till lite trick, men i princip får man vänta på att man får ett asynkront meddelande tillbaka. I princip kanske man kan säga att alla applikationer man bygger i princip blir som en liten svärm med webservrar som löser var sin uppgift.

Felhantering i Erlang går i mångt och mycket ut på att låta saker dö. Tricket är att inte hantera något tillstånd. Alla funktionsanrop bär med sig all information den behöver och nästa anrop kommer, förutsatt att samma information skickas in, ge samma resultat. Poängen med detta är att det lättare att döda en process och starta den igen om något blivit sjukt än att försöka att hantera fel. Den nya processen kommer att ge samma resultat som den gamla så det är ingen som kommer att bry sig kort och gott.

Jag är lite besviken på kapitlet om Erlang. Jag känner att jag saknar kopplingen till verkligheten. Kapitlet kändes akademiskt. Jag förstår att tillstånd är något som är dåligt om man vill hantera många saker samtidigt men samtidigt så har de flesta applikationer jag träffat på små beroenden på vad klockan är, eller hur många som är inloggade. Var tar all denna information vägen i en Erlangapplikation?

Jag har en teori om den här boken. Den är inte till för att ge en översikt på ett antal språk så att man ska kunna jämföra dem och kanske välja ut ett för att lära sig "på riktigt". Bokens syfte är att lära ut funktionell programmering, men genom att sockra med Ruby som objektorienterat språk och Io som är likt javascript så märker man inte hur man sakta lär sig funktionsbaserat tänkande.

Seven languages in seven weeks - Scala

Dags för språk nummer fyra ur boken Seven languages in seven weeks. Nu blir det Scala. Ett språk som många ser som språket som kommer att Java som huvudspråk till JVM. En av fördelarna med Scala är att det är kompatibelt med Java. Har du 10 år av kod med dig från Java så behöver du inte börja med att skriva om den utan du kan återanvända dina favoritfunktioner från Scala.

Scala - dag 1
Första dagen med Scala var rätt trist, lite syntax varav det mesta känns igen från de flesta c-derivat. Så det var inte mycket som kändes nytt. Det som var lite intressant var att man valt att ha mixins eller moduler (ruby resp io) och för att förvirra lite kallar dem för traits. Jag hoppas på en roligare dag två :)

Scala - dag 2
Idag har vi gått igenom Scalas nyckelord var och val. Skillnaden mellan dessa är om variabeln som deklareras är mutable (kan förändras) eller inmutable (kan inte förändras). Genom att ha stora delar av sin kod inmutable kan man utradera mycket av de problem som objektorienterade språk har med parallell körning, tex över flera processorer.

En stor del av kapitlet ägnas åt Scalas collections. Dessa är i mångt och mycket också uppbygda runt inmutable objects. Tex om du lägger till ett objekt i en lista får du tillbaka en helt ny lista i stället för att behöva oroa dig för om din lista har förändrats på oväntat sätt. Jag uppfattar det som kanske något ineffektivt men förstår att vinsten kommer när man börjar arbeta med parallell bearbetning.

Scalas collections kan användas i vanliga for-loopar men tanken är att man ska använda dem funktionellt. Alltså finns det sätt att skicka in en funktion som ska köras på alla objekt tex på din lista.

Scala - dag 3
Under dag 3 visades den inbyggda xml-hanteringen där xml kan definieras som vilken variabel som helst.

Patternmatching är en funktion som lite kan jämföras med de logiska vilkoren i prolog.

Parallellism i Scala liknar till viss del den i Io då den använder actors och meddelanden.

Lite sammanfattning om Scala.
Jag uppfattar Scala som en utveckling av Java där man kunnat släppa kravet på bakåtkompabilitet som finns. Så att byta ut trådbaserad parallellsim mot actors. Införa inmutable objects och functionalism m.m. Trots allt detta nya så kan man ändå återanvända sina gamla javabibliotek. Det är ganska trevligt tycker jag.