2011-10-23

Att lära sig Scala

Läs följande artikel och gråt en skvätt om du gillar Scala:
http://tataryn.net/2011/10/learning-scala-learn-the-fundamentals-first/
Allt kretsar kring ett "really simple example"
m.map { t => val (s,i) = t; (s, i+1) }
Det är en intressant artikel, men samtidigt är det lite trist att någon tycker att man måste krångla till det så förbannat. Författaren valde exemplat för att det "shows off almost everything you need to know in order to get started ". Om jag hade behövt kunna det här för att komma igång med Scala hade jag aldrig kommit igång. Det är sånt här som kan skrämma bort vem som helst.

2011-10-14

Bara ett ramverk till

Det är lätt att lösa problem genom att lägga in nya ramverk eller ny teknik.
Vad vi ofta inte tänker på är att komplexiteten ökar för varje nytt ramverk.
Om vi hela tiden löser problem genom att införa ny teknik, så kommer projektet
förr eller senare att falla ihop spontant.

När vi ställs inför lockelsen att ta in ny teknik för att lösa något som just
nu är akut bör vi ta ett steg tillbaka och fundera. Vad är det vi vill uppnå?
Beror problemet på ett tidigare felval? Kanske man kan byta ut en komponent mot
en komponent som bättre svarar mot behoven?

Oviljan att byta ut gamla komponenter är ofta grundat på sunt förnuft: Ändra inte
på det som fungerar. Vi har byggt upp kompetens runt det gamla ramverket. Det
blir mycket kod som måste skrivas om. Osv. Men i den andra vågskålen finns den
smygande komplexitetsökningen. Och den är svår att mäta.

Min erfarenhet är att jag sällan ångrat att byta teknik rakt över, men ofta ångrat
när jag inte gjort det. Att dutta med plåster är sällan en hållbar strategi i längden.

Sammanfattningsvis är det så enkelt att man måste ha ett helhetsperspektiv när
man bestämmer sig för vilken teknik och vilka ramverk som ska användas.
Att lägga till ett nytt ramverk är nästan aldrig ett isolerat beslut utan något som
ger konsekvenser för resten av koden också.