Härom dagen upplevde jag något som kan betecknas som Flashback. Jag rycktes tillbaka till osäkerhetens land. En utvecklares mardröm. Åter tvingades jag använda ett ramverk där inte bara ett utan flera kompileringssteg ingår. Ett arbetsflöde bestående av väntan och tidsödande intervaller. Vilket skapar osäkerhet om senaste versionen av källkoden verkligen exekveras. Flera kompileringssteg fick mig att tänka på scriptspråk. Det rakt motsatta. Källkod som exekveras direkt utan kompileringssteg.
Det finns många scriptspråk. Några av de populära är PHP, Ruby och Javascript. Det som väcker mitt intresse är Groovy. Frågan jag ställer mig är om det finns tillräckliga fördelar för att lägga det under lupp och komplettera verktygslådan. Med nätets hjälp försöker jag samla argumenten.
Varför valet föll på Groovy är dess likhet med Java. Precis som javan körs det i Java Virtual Mashine, JVM:n. Syntaxmässigt är den nästan identiskt. Därför borde tröskeln som måste passeras inte vara så stor innan språket blir ett tillförlitligt verktyg i arsenalen. Då jag kommer från Java-land innebär det stora tidsvinster. Efter många år som konsult är tidsvinster en ständig följeslagare. Undvika all tid som inte är debiterbar. Konsultens ständiga spöke. Jakten på debiterbara timmar gör sig påmind.
Även om likheterna är stora så finns det syntaxiska förenklingar. Det talas om “noise reduction”. Reduceras antalet rader går det naturligtvis snabbare i utvecklingsfasen men också i underhållsfasen är det bättre med mindre kod. Översikten underlättas och underhållet förenklas! Exempel finns där Groovy jämförs med Java. Motsvarande funktionalitet kan skrivas med hälften eller till och med en tredjedel av antalet kodrader som behövs i java.
En funktionalitet som framhålls i Groovy är möjligheten till något som kallas closure. Ett kodblock som kan skickas runt som parameter. Det ger möjlighet att i befintlig kod få in hooks eller exit points. Med closure kan också beroendet minskas vilket utgör en viktig strävan. Inbyggda builders är andra exempel. XML hanteras på ett enkelt sätt. För att undvika det i javan så vanliga NullPointerException finns “safe navigation operator”. Ett ? direkt efter objektet. Visst finns en hel del godis. Utvecklingen underlättas.
Ett annat argument för Groovy är möjligheten till Meta-programmering. Varje objekt i Groovy har en MetaClass som håller information om objektets class. Alla call går via denna MetaClass. Därmed går det att skapa funktionalitet dynamiskt. En möjlighet som kommer till användning när Groovy används som Domain Specific Language, DSL. Skapa ett metaspråk som är användbart inom sitt speciella område. Vilket är ett sätt att underlätta kommunikation mellan den som ska använda programvaran och den som står för funktionaliteten då terminologin byggs in i programvaran.
Ytterligare en möjlighet är consolfunktionen som med fördel används i enkla tester.
Det största motargumentet jag stött på är prestandan. Jämförelser med Java förloras alltid. Men möjligheten finns att kompilera groovy-koden och skapa class-filer på motsvarande sätt som i Java.
Om jag ska försöka mig på en summering så väger argumenten för Groovy över. Speciellt med tanke på de fördelar som finns när man kommer från Java-miljön. Nu blir det att söka vidare. Gräva fram någon lämplig bok om Groovy och hitta projekt där språket kan tillämpas.
Hade jag kommit från något annat håll än Javamiljön så hade följande citat från skaparen av Groovy James Strachan gjort mig mera tveksam. I sin blogg några år efter Groovy introducerats skev han följande:
“I can honestly say if someone had shown me the Programming in Scala book by Martin Odersky, Lex Spoon & Bill Venners back in 2003 I’d probably have never created Groovy.”