Functioneel programmeren in Scala

Afgelopen weekend weer even in Scala gedoken. Ik liep namelijk wat tegen beperkingen van het OO paradigma aan. Of eigenlijk tegen het imperatief programmeren.

In een project ging het om berekenen van het rendement van een portefeuille. Mijn code vond ik uiteindeljk complex, met name als ik formules moest aanpassen. In een spreadsheet gaat het proces honderd maal sneller en is het ook begrijpelijker.
Het spreadsheet model heeft functies als input voor andere functies en dit zit duidelijker tegen het functionele programmeer model aan.

In het ander project ging het om manipuleren van grote xml structuren. Het werken met de DOM api gaf geheugen en performance problemen, terwijl Sax en Stax weer moeilijker te programmeren zijn. Xml is echter ook maar een lijst van lijsten en dit is weer makkelijker in een functionele taal te doen.

Voldoende redenen dus om functioneel programmeren ook een beetje te beheersen. Scala lijkt een lage instap omdat je gebruik kunt maken van het Java platform en je niet meteen volledig functioneel hoeft te programmeren. In C# zou je weer LINQ kunnen gebruiken.

He duurde wel even voordat het functioneel denken weer aansloeg. Ik was ook heel veel tijd kwijt aan de details van de taal. Was een beetje verwend door het leren van Smalltalk dat maar zes keywords kent en waar je de taal in een half uur hebt geleerd. Wat het niet meteen makkelijker maakt, maar je zit niet zo met het niet goed kennen van de syntax als bij Scala.

Een Scala script heb ik nu wel af en het resultaat ervan is naar de klant toe. Het was geen petproject, er moest echt iets af. Dat werkt toch het beste merk ik. Je moet dan wel door bijten als het even lastig wordt.

Ik ben redelijk tevreden over de code. Het algoritme is simpeler geworden dan als ik het in Java met Dom of Stax zou hebben opgelost. Ik weet nu ook wat tail-recursion in houdt. De code is goed aan te passen en te hergebruiken, omdat het niet erg gebonden is aan een specifieke xml structuur. Je bent alleen bezig met het deel dat je wil aanpassen en de rest van boom interessert je niet.

Ben wel niet zo tevreden over de leesbaarheid van de code, maar dat is misschien een kwestie van wennen. Het is leesbaarder dan Java, maar dat is de lat erg laag leggen.

Ik zal nog wat schrijven over het opzetten van het project, het gebruik van de IDE, maven, specs, e.d. Daarna kijken of de rendement rekenmodule ook beter te implementeren is in Scala of misschien wel in C# en LINQ.

Verbeteren van versiebeheer in Smalltalk

Het is me nog niet gelukt om mijn manier van werken met versie beheer in Smalltalk toe te passen. Ik ben gewend aan meerdere keren per dag atomaire commits te doen met een goede beschrijving.

Hierdoor kan ik van elke wijziging aan mijn code opzoeken waarom ik het gedaan heb. Ik registreer in wezen mijn denkproces. "What was I thinking" kan ik jaren nadat ik de code heb geschreven nog opzoeken. Dat wetende kan ik ook meteen alles vergeten wat ik heb gedaan na mijn commit en met een verse blik kijken naar het volgend probleem.

Het is ook een manier om van anderen te leren. Ik kan het denkproces van programmeurs op andere projecten volgen en er van leren.

Het registreren van commentaar is natuurlijk nutteloos als het nooit gelezen wordt. Daarom vind ik het belangrijk dat je de repository via een webinterface kunt benaderen. Een webbrowser is altijd aanwezig op een computer en de web views zijn ook te Google'en.

Een commit met goed commentaar doen in Envy, de code repository van Visual Age, vind ik nog omslachtig. Het kost me teveel tijd en haalt mij uit mijn flow, dus val ik terug op de einde van de dag commit. Er is daarnaast ook geen timeline view om makkelijk te zien wat er de afgelopen dagen aan de code gewijzigd is.

We hadden het er vandaag wel over om een Seaside frontend voor Envy te gaan maken. Vind ik een goed plan, en een timeline view zoals van Github en Trac, staat dan boven aan mijn lijst.

Macbook accu’s

De accu van mijn macbook pro deed al een tijdje raar. Coconut gaf aan dat ik maar 23% capaciteit overhad. Na het een avondje gecalibreerd te hebben, heeft na een dag werken besloten het volledig op te geven. Had daar eerder naar moeten kijken, toen ik vorige maand nog garantie had bijvoorbeeld. Maar ik heb nog goede hoop dat dit valt onder een bekend probleem bij Apple en dat ik een nieuwe accu kan krijgen. Gelukkig heb ik nog een spare thuis liggen waarmee ik vooruit kan.

Op dezelfde dag en misschien zelfde moment dat mijn accu dood valt, kondigt Apple de niet verwisselbare accu aan in de nieuwe macbook pro. Weet niet wat ik ervan moet vinden. Acht uur achter elkaar werken lijkt me wel cool en normaal heb ik een spare ook niet echt nodig.

Vind het echter wel fijn dat ik nu geen downtime heb en dat ik mijn machine niet hoef weg te brengen voor een nieuwe accu. Maar voor die ene keer in de twee jaar dat het kan gebeuren? Het zou me niet tegenhouden de nieuwe macbook pro te kopen.