“In ‘Foutvrij Programmeren’ (Martijn Linssen in Computable, 12 maart 2004) stoort me dat met veel bombarie en veel omhaal van wollige bewoordingen weer eens een ‘methode’ wordt gepresenteerd die definitief een eind moet maken aan alle programmeerproblemen”, reageert John Pool.
Het begint al in de kop van het artikel met de ongefundeerde bewering dat de kwaliteit van programma’s merkbaar achteruit is gegaan. Vervolgens worden acp (application control programming) en siblr (slim implementation of business logic requirements) opgevoerd als tovermiddelen waarmee deze onwenselijke situatie voorgoed valt uit te bannen.
De kerngedachte van acp wordt in onduidelijke bewoordingen uitgelegd, maar bestaat blijkbaar uit het combineren van het gebruik van referentievariabelen en objecten, die in dit verband de rol toebedeeld krijgen van ‘krimpende’ of ‘uitzettende’ verzamelingen van variabelen. Hierbij geldt dan dat: “alleen objecten worden doorgegeven van de ene (?) functie, en het liefst slechts één object”. Er worden semi-exacte termen gebruikt die verder niet toegelicht worden, zoals “werkelijke globale variabelen voor de hele transactie”, “compleetheid” van een “transactie”, en “operationele waardes van variabelen”.
Gekunsteld
Onder het kopje siblr (wie verzint een dergelijk acroniem?) wordt ons medegedeeld dat deze aanpak bedoeld is om complexe bedrijfslogicavereisten te vereenvoudigen. Dat lijkt mij niet de bedoeling: deze vereisten zijn er nu eenmaal en moeten als uitgangspunt beschouwd worden bij het verdere ontwerpproces. De schrijver bedoelt naar ik aanneem dat de notatie van deze vereisten eenvoudiger en begrijpelijker wordt door het gebruik van siblr. Hij stelt daarbij een transformatie voor – het “omgekeerde if-statement” – die soelaas zou moeten bieden. Deze aanpak is echter in het geheel niet overtuigend. Voor het simplistische voorbeeldje is de genoemde transformatie namelijk overbodig, en voor realistische voorbeelden uit de grotemensenwereld is zij niet eens mogelijk zonder de geclaimde begrijpelijkheid geweld aan te doen. De logica van het voorbeeldje is onnodig complex weergegeven, wellicht om het te contrasteren met het ‘leesbare’ resultaat van de transformatie. Zelfs een beginnend programmeur zou het statement opschrijven als:
if A and B and C then
— do D
— E = call F
— if E = G then do H
Deze notatie is korter en inzichtelijker dan de gekunstelde ‘do … while false’-constructie met ‘break-statements’, die volgens het artikel bedoeld is om “programma’s in lijn te laten lopen”. Wat dit betekent wordt niet verder toegelicht. De constructie is overigens niets anders dan een verkapt gebruik van ‘goto’s’ zoals dat in de jaren zestig noodzakelijk was met Fortran (dat in zijn eerste versies geen blokstructuur en geen ‘else’-takken kende). Daardoor heeft deze constructie ook alle beperkingen en nadelen zoals die al 36 jaar geleden door onze landgenoot Edsger Dijkstra op overtuigende wijze zijn geformuleerd. Ik zou graag zien hoe het gebruikte voorbeeld op een leesbare manier als “omgekeerd if-statement” wordt weergegeven wanneer een of meer van de condities A, B en C voorzien zijn van ‘else’-takken, om over iteraties nog maar te zwijgen.
Woordenbrij
In het onderdeel ‘Code wordt een open boek’ wordt ons nogmaals uit de doeken gedaan welk probleem siblr eigenlijk oplost. Het maakt namelijk een eind aan “het op en neer springen binnen een functie, het aan- en uitzetten van switches die op andere plaatsen weer gecontroleerd en aan- of uitgezet worden”. Ik weet niet van welke planeet de schrijver afkomstig is, maar ik ken geen enkel serieuze ontwerpmethode waarin een dergelijke aanpak gepropageerd wordt.
Verder houdt de schrijver, als ik zijn betoog goed begrijp, een pleidooi voor het gebruik van één systeembrede, globale goed/fout-variabele met de naam ‘output’ die het liefst (?) de waarde “succes!” moet hebben. De inzichten en ontwikkelingen in de aanpak van ‘exception handling’ zoals die de afgelopen tien jaar hebben plaatsgevonden schijnen geheel ongemerkt aan de schrijver voorbij te zijn gegaan. Het feit dat hij deze niet eens noemt is in dit opzicht veelzeggend.
Tegen het eind van ‘Code wordt een open boek’ treffen wij de volgende passage aan: “Wat er nu nog mist is een blauwdruk van de applicatie als er géén fouten optreden: dit kan worden afgedwongen door foutafhandeling te forceren (‘dumping’) op het eind van elke transactie. Deze ‘dumping’ kan gefaciliteerd worden door een – uiteraard systeembrede en globale – ‘debug’-switch te controleren in de foutafhandeling, waardoor een dump wordt geforceerd: hierdoor eindigt elke transactie met een complete dump van het transactieobject”. Ook na intensieve en herhaalde lezing wil het mij maar niet helder worden wat er met deze woordenbrij bedoeld wordt. Wat is in vredesnaam een “blauwdruk van de applicatie” en waarom moet er foutafhandeling geforceerd worden als er geen fout is opgetreden?
Slechte dienst
Ook in het deel van het artikel contrasteert de schrijver zijn voorgestelde aanpak met de volgens hem gebruikelijke methoden, getuige de zin: “Functies hoeven niet langer complexe en moeilijk te ontwarren ‘if’-statements, ‘goto’-labels of ‘gosubs’ te bevatten, evenmin als een veelvoud aan switches of plaatselijke foutafhandeling”. Ook hier rijst de vraag in welke eeuw de schrijver eigenlijk leeft.
Concluderend ben ik van mening dat Linssen het vakgebied met dit artikel een slechte dienst bewijst. De indruk wordt gewekt dat er maar wat aangeprutst wordt in automatiseringsland, en als uitweg presenteert hij vervolgens een warrig beschreven en slecht onderbouwd pseudo-alternatief. Eerlijk gezegd bekruipt mij het onbehaaglijke gevoel dat Linssen er meer op uit is om zichzelf en zijn bedrijf, Capgemini, met een twee pagina’s breed artikel in de schijnwerpers te zetten, en dat de inhoud daarbij van ondergeschikt belang is.< BR>
John Pool, Amersfoort