Onlangs was er bij Finalist een discussieavond en presentatie over de filosofie van Ruby en hoe Rubyisten graag programmeren. Ruby code volgens deze filosofie noemen we ‘Rubyesque’. Hierbij was het mijn taak om een presentatie te geven over wat Rubyesque inhoudt, waarna we met z’n allen er over zouden discussiëren.

De aanleiding was het feit dat we op zoek zijn naar meer Rubyisten om ons team te versterken. Deze avond was om te kijken of er mensen binnen Finalist waren die nu nog geen Ruby doen, maar daar wel interesse in hebben en wilden weten of Ruby hun aansprak. Verder is een dergelijke discussie natuurlijk leerzaam voor alle betrokkenen.

Het was mijns inziens een succesvolle avond, dus bij deze een “korte” samenvatting.

Over programmeren en de ‘flow’

Het gaat hier allemaal over meningen en meningen verschillen. Door veel blogs en code te lezen meen ik te zien dat er toch enige concensus bestaat binnen de Ruby community over wat Rubyesque inhoudt, alhoewel dit niet zo vaak expliciet uitgesproken wordt. Om die reden pretendeer ik ook niet compleet te zijn, of de absolute waarheid te spreken.

Programmeren wordt vaak met allerlei andere vakken vergeleken om maar uit te leggen hoe men denkt over zijn/haar vak. Binnen de Ruby community wordt programmeren het meest vergeleken met een ambachtelijk vak. Ik zou graag zelfs een stapje verder gaan door het programmeren te vergelijken met kunst of het spelen van een muziekinstrument. Programmeren is een creatief proces en je probeert met hetgeen je maakt betekenis uit te drukken. Dat kan alleen als je het instrument wat je gebruikt goed onder controle hebt.

Elke programmeertaal heeft zijn eigen stijl, zijn eigen ‘flow’. Het is verstandig om deze flow te volgen. Het is makkelijker om te doen wat de makers van de programmeertaal in gedachten hadden dan er tegenin te gaan. Probeer bijvoorbeeld geen inheritance te doen in een taal die d.m.v. prototyping werkt. Als je de flow van een taal volgt dan is je code ook beter onderhoudbaar door je medeprogrammeurs.

Over Ruby

In Ruby is alles gericht op de blijheid van de programmeur. Immers, een blije programmeur is beter gemotiveerd zijn uiterste best te doen, levert betere code op, en zal zich verantwoordelijk voelen om geen slechte code over te dragen. En van betere code wordt iedereen blij.

Het is de computer die het zware werk moet doen en niet de programmeur. Dit betekent dat Ruby niet bijzonder snel is, maar omdat computerkracht goedkoper is dan mankracht, is dat niet heel erg.

Ruby heeft een aantal kenmerken om het leven van de programmeur leuker te maken:

• Dynamisch en open om makkelijk zaken naar je hand te kunnen zetten
• Weinig regels, dus makkelijker te onthouden
• Voor vaak voorkomende taken zijn ‘shortcuts’
• Veel mogelijkheden om code te herbruiken (zie bijv. mijn post over modules)
• Optionele interpunctie om leesbaarder te zijn
• Methoden zoals attr_accessor om jezelf minder te hoeven herhalen

Dynamisch

Bij een dynamische taal is het niet belangrijk welk type een object heeft, maar wat het kan. Dit heet duck typing. Zolang een object maar kan wat het moet doen, maakt het niet uit wat het precies is. Niet alleen maakt dit het maken van mock-objecten erg makkelijk, je bent ook een hoop kopzorgen kwijt en je hoeft inheritance niet te misbruiken om aan functie definities te voldoen.

Een mooi voorbeeld hiervan is de Rack specificatie. Het zegt over de headers alleen dat het een object moet zijn dat reageert op de methode each. Dit geeft programmeurs erg veel vrijheid, ze kunnen een hash gebruiken, maar ook een eigen object, zonder dat het hoeft over te erven van hash.

De flow in Ruby is dat er zelden gecontroleerd wordt welke objecten als parameters gebruikt worden. De controle op correct gebruik van objecten wordt als storend ervaren en leidt af van de bedoeling van de code. De verantwoordelijkheid van het juist gebruiken van een library ligt bij de gebruiker en niet de maker van de library.

Open

In Ruby is niks definitief. Dit zorgt ervoor dat je dingen kan toevoegen en veranderen in elk object, inclusief core classes. Dit wordt monkey patching of duck punching genoemd. Dit zorgt ervoor dat je nog mooiere een leesbaardere code kan schrijven, zoals:

15.minutes.ago

Niemand hoeft uit te leggen wat deze code doet. Niemand hoeft documentatie te lezen om te begrijpen wat de intentie is van deze code. Monkey patching helpt enorm bij het verduidelijken van je code.

Ik begrijp dat dit voor sommige mensen wild en extreem kan overkomen. Het past niet binnen de strakke regels die gelden in andere talen. Toch zijn dit soort technieken fijn en lichtelijk verslavend. Het is makkelijk in gebruik en maakt je code zo kort en duidelijk, dat wanneer ik in een andere taal werk ik me erger aan het feit dat ik soms iets meer moeite moet doen om hetzelfde te bereiken.

Monkey patching is wel gevaarlijk. Je bent zelf verantwoordelijk voor het verantwoord omgaan met deze techniek. Gebruik tests om ervoor te zorgen dat je geen dingen overhoop haalt die je niet bedoeld had.

Interpunctie

Ruby staat toe dat je, zolang het niet ambigu wordt, haakjes weg te laten. En dat doen Rubyisten graag. Het is voor een groot deel een kwestie van smaak, maar in de ogen van de meeste Rubyisten is het belangrijk dat code goed en makkelijk te lezen moet zijn.

Daarom schrijven we liever dit:

class Post
  belongs_to :author, :dependent => :destroy
end

Dan de variant met alle interpunctie in beeld:

class Post
  belongs_to(:author, {:dependent => :destroy})
end

Het is niet belangrijk dat {:dependent => :destroy} een hash is. Het is belangrijk dat de relatie afhankelijk is van de auteur en dat de post vernietigd wordt als de auteur vernietigd wordt. Dat is namelijk de betekenis van de code. Hetzelfde geldt voor belongs_to. Het is niet interessant dat dit een methode is en dat de rest de parameters zijn.

Door interpunctie te schrappen kunnen onze hersenen zich beter focussen op wat er staat, in plaats van welke objecten er gebruikt worden om dit te bereiken.

Weinig regels, veel shortcuts

Ruby kent maar een handje vol taal constructies. Er zijn drie taal-elementen, namelijk Objecten, Methoden en Closures. Er is dus niks bijzonders aan classes en modules. Het zijn gewoon objecten. Voor de rest zijn er een paar taal constructies zoals if, while, en logica operators zoals && en ||.

Verder zijn de meeste keywords shortcuts naar taal-constructies of methoden die vaak voorkomende taken makkelijker moeten maken. Zoals het definiëren van een klasse:

class Car < Vehicle
  # ...
end

Dit wordt door de Ruby interpreter gelezen als:

Car = Class.new(Vehicle) do
  # ...
end

Dit is dus gewoon een methode die aangeroepen wordt op een object. De eerste parameter is een ander object en een closure. Je kan het zelf ook zo schrijven en er mee spelen als je dat wilt (zoals dynamisch een enorme lijst van klassen maken).

Een paar andere voorbeelden:

counter += 1                   # met shortcut
counter = counter + 1          # zonder shortcut, maar ook zonder interpunctie
counter = counter.+(1)         # zonder shortcut, met alle interpunctie (ja, + is gewoon een methode)
 
@user ||= User.new             # dit wordt de 'teapot'-operator of de 'or-or-equals' genoemd
@user = @user || User.new      # als @user bestaat gebruik die dan, anders maak een nieuwe user en stop die in de @user variabele
 
exit unless busy or cancelled  # 'unless' is een shortcut voor 'if !()'
exit if !(busy or cancelled)   # 'if' achter een zin is ook een shortcut
if !(busy or cancelled)        # voor 'if' er omheen
  exit
end

Er zijn nog veel meer shortcuts. Waarom doet Ruby dit? Waarom staat Ruby toe dat je soms dingen iets anders formuleert? Het gaat niet alleen om leesbaarheid, maar vooral om de wens dat je makkelijk de vertaalslag kan maken tussen wat er in je hoofd zit en de code.

Hoe kleiner de stap is van gedachten naar code, hoe makkelijker het is om te programmeren. In Ruby heb je alle vrijheid om jezelf uit te drukken zoals je zelf wilt. Dat hoeft niet noodzakelijk goed uit te pakken. Als je een onduidelijk beeld hebt van het probleem, schrijf je onduidelijke code. Er is niks wat je tegenhoudt om slechte code te schrijven. Het mes snijdt aan twee kanten.

Intentie

Code hoort zijn intentie duidelijk te maken. Ruby code is Rubyesque als het de methoden gebruikt die ik net beschreven heb om de intentie duidelijk te maken. Omdat Ruby zo'n heldere en schone syntax heeft, worden de meeste DSL's (Domain Specific Languages) geschreven in Ruby zelf.

De naamgeving van variabelen en methoden is erg belangrijk. Als je de code leest moet het in 1x duidelijk zijn wat de bedoeling is van de code.

Een fantastisch voorbeeld is Rspec, een van de meest gebruikte test frameworks van Ruby:

describe Post do
 
  context "when it's not approved" do
    subject { Post.new(:approved => false) }
    it { should_not be_publishable }
  end
 
  context "when it's approved" do
    subject { Post.new(:approved => true) }
    it { should be_publishable }
  end
 
end

De gehele Ruby trukendoos wordt gebruikt om ervoor te zorgen dat ik makkelijk mijn specificaties en tests kan schrijven. Dit lijkt misschien niet meer op "normale" Ruby code, maar dat is het nog steeds. Niks meer dan objecten, methoden en closures.

Het Rubyesque hier aan is wat Rspec je toe in staat stelt. Er is zo min mogelijk afleiding van de betekenis. Ik kan in een oogopslag zien of mijn code nog wel voldoet aan de wensen van de klant en door de test te draaien zien of de code werkt zoals gespecificeerd. En nog fijner: ik hoef er amper moeite voor te doen! Rspec maakt Test Driven Development erg eenvoudig.

Geïnteresseerd naar de code bij dit voorbeeld? Kijk hier.

Kort en bondig

Het is Rubyesque om dingen zo kort mogelijk op te schrijven. Dat betekent niet alleen korte regels (ik vind een regel tussen 80 en 100 karakters een acceptabele lengte), maar ook korte methoden. De code smell detector Reek zal bijvoorbeeld al een waarschuwing geven als je methode langer is dan 6 regels. Mag je dan geen langere methoden schrijven? Natuurlijk wel. Is het verstandig? Nee.

Korte zinnen zijn namelijk veel beter leesbaar voor mensen. En het zijn mensen die de code moeten onderhouden en begrijpen. En zo zijn we weer terug bij de filosofie achter Ruby. Het is gemaakt om begrijpbaar te zijn voor mensen. Dat de computer er meer moeite voor moet doen om het te begrijpen is minder belangrijk.

Conclusie

Ruby is een vrije taal, waarin heel veel mag en kan. Het doel is om blij te worden van je werk. Dit is gedaan door een taal te maken die dicht bij menselijke taal staat. Dit zorgt ervoor dat je begrijpelijke code kan schrijven. Als je programmeert in Ruby probeer dan dezelfde doelstelling aan te houden.

De meeste mensen komen vanuit Java of PHP en dan lijkt Ruby een vage en magische taal. Dat valt alles mee. Ruby is makkelijk te leren en te begrijpen. De basis is erg klein. Rubyisten programmeren niet volgens strakke regels en dogma's, maar experimenteren met verschillende interpretaties van hetzelfde probleem.

Hopelijk heb je nu een idee gekregen van de filosofie achter Ruby. Ik zou iedereen adviseren rond te kijken naar de verschillende filosofiën van andere talen en te kijken bij welke filosofie je jezelf het beste thuis voelt. Voel jij je thuis bij de Ruby filosofie en heb je de discipline die nodig is om Ruby te kunnen schrijven, dan kan ik je Ruby van harte aanbevelen.