Oefening baart kunst

De meeste tekstverwerkers van vandaag zoals MS Word, WordPerfect of OpenOffice hebben een of andere spellingcontrole aan boord. Soms hebben ze de mogelijkheid om je fouten tijdens het typen te verbeteren.

Bijvoorbeeld, je typt ' incorect' en je tekstverwerker begrijpt wat je eigenlijk bedoelt en wijzigt je fout automatisch in 'incorrect'. Hopelijk 'kent' je computer jou goed en wijzigt hij het woord op de juiste manier. Een computer kan niet onder je hersenpan kijken en 100% zeker zijn van je intensies. Maar 95% is best een goede score voor een computer in dit soort situaties.

Op het eerste gezicht lijkt deze functie geweldig. Niks mis met een beetje hulp van je desktop vriend. Het zal je ervaring als computergebruiker alleen maar beter maken. Maar is dit wel zo?

Het probleem is... je typte het woord nog steeds incorrect. En dat maakt inderdaad niet uit als je af en toe een stukje schrijft. Maar het probleem wordt groter wanneer je deze functie dagelijks gebruikt. In dat geval programmeer je je hersens zo, dat wanneer je denkt aan het woord 'incorrect', je vingers 'incorect' typen. Je wordt niet verplicht om terug naar je fout te gaan en deze te verbeteren. En het enige dat je tekstverwerker doet is deze onnauwkeurigheid in stand houden en wellicht zelfs sterker maken.

Wat je tekstverwerker zou moeten doen is je een 'Ik zal niet inco(r)rect' typen schermpje laten zien en vervolgens je het woord 'incorrect' 100 keer juist laten typen voordat je door kunt met de document. Ik denk niet dat deze functie zijn weg zal vinden in de tekstverwerkers van vandaag – en de suggestie is grappig bedoeld – maar het zou je uiteindelijk wel een betere en snellere typist maken.

Op een hoger niveau komt het er eigenlijk op neer hoeveel we van onszelf willen automatiseren ten koste van onze vaardigheden. Dat zal erg ver gaan aangezien de mens van nature aardig lui is.

Snel terug naar de wereld van het programmeren (voordat we te filosofisch worden). Op feature lists van veel ontwikkelingsoftware of programmeertalen zie je vaak de term 'automatic garbage collector'. Dit betekent dat de programmeeromgeving (compiler) elke ongebruikt stukje geheugen zal teruggeven aan het besturingssysteem. Met andere woorden, als je een variabele in het geheugen hebt geinitialiseerd en vergeten bent om deze weer vrij te geven nadat je er klaar mee was, dan zal de AGC aan het werk gaan en het stukje geheugen netjes teruggeven. Een beetje zoals een automatische schoonmaker.

Handige functie, toch? Nee! Net zoals de automatische spellchecker in tekstverwerkers is deze functie een korte-termijn truc, niet een lange-termijn oplossing. Stel jezelf deze vraag eens: "Waarom ben ik deze variabelen vergeten op te ruimen?" Was het een bewuste keuze of ben je ze toevallig vergeten...?

Van mijn moeder moest ik vroeger altijd mijn eigen speelgoed opruimen, wanneer ik er klaar mee was. Het was een goede regel (hoewel ik toen een andere mening had) en ik doe er nog steeds mijn voordeel mee. Dus waarom is deze regel opeens niet meer gewenst in de wereld van software ontwikkeling? Door het gebruik van safety nets zoals de Automatic Garbage Collector worden je hersens lui. En luie hersens hebben de neiging om dingen te vergeten. Dingen die wellicht niet door de 'automatische schoonmakers' worden opgemerkt en verwerkt.

We zijn in de loop der tijd een hoop vaardigheden kwijt geraakt. De meeste mensen kunnen zonder lucifer of aansteker geen vuur meer maken en zonder hogere programmeertaal kan ik geen software meer schrijven.

Neem Spinrite6, een programma om je data van een kapotte harde schijf mee te redden. Steven Gibson heeft het helemaal in assembly code geschreven en het neemt niet meer dan 200kB(!) in beslag. Ik zeg het nog eens: 200kB. Wanneer ik een lege(!) applicatie in Delphi 7 (= hogere taal) compileer dan heb ik een executable van 360kB. 360kB voor een applicatie met een scherm dat verder niets doet. Goed, in die 360kB zitten mooie libraries die we vast en zeker een keertje nodig hebben, maar ergens klopt hier iets niet.

Steve Gibson schrijft goede en solide software. Ik denk dat dit komt omdat hij in assembly code programmeert. Dicht bij de machine, zonder veiligheidglas, airbags en automatic garbage collectors. En iedere dag worden zijn hersens scherper en wordt hij geforceerd om niets aan het toeval over te laten, het geheel te overzien en alle variabelen netjes op te ruimen.

Een meer theoretisch maar nog steeds interessant probleem met automatische schoonmakers zoals de AGC is dat je steeds meer en meer afschuift op het systeem (wat het systeem dan ook is). Hierdoor wordt het steeds moeilijker om er achter te komen waarom het systeem zich gedraagt zoals het zich gedraagt. Hoewel de automatic garbage collector vrij eenvoudig is en recht-door-zee, hoop ik dat je inziet dat een stapel van deze opruimers een computer systeem complexer maakt dan we misschien willen.

Als programmeur heb je vast wel eens gedacht dat je programma gek is geworden omdat hij dingen deed die totaal niet logisch en consistent waren. In je achterhoofd weet je dat software zich altijd logisch gedraagt, dus het probleem ligt altijd bij jezelf. Na lang debuggen wordt dit helaas altijd weer bevestigd.

Bart Bons houdt zich voornamelijk bezig met het ontwikkelen van business software, webservices en open standaarden.