Dankzij ‘application control programming’ en ‘slim implementation of business logic requirements’ is het mogelijk om foutvrije code te schrijven, zo beweerde Martijn Linssen onlangs. Onzin, vindt John Pool. Zijns inziens worden deze termen warrig beschreven en is de voorgestelde methode een slecht onderbouwd pseudo-alternatief.
In het artikel ‘Foutvrij Programmeren’ van Martijn Linssen (Computable, 12 maart) wordt met veel omhaal weer eens een ‘methode’ gepresenteerd die definitief een eind moet maken aan alle programmeerproblemen.
Het begint al 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 kan worden uitgebannen.
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”.
Niet overtuigend
Onder het kopje ‘Siblr’ (wie verzint een dergelijk acroniem?) wordt ons medegedeeld dat deze aanpak bedoeld is om complexe eisen aan de bedrijfslogica (business logic requirements) te vereenvoudigen. Dat lijkt mij niet de bedoeling: deze eisen 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 eisen 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 W. 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.
Blauwdruk
Onder het kopje ‘Code wordt een open boek’ wordt ons nogmaals uit de doeken gedaan welk probleem siblr eigenlijk oplost. Het maakt namelijk een einde 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 enkele serieuze ontwerpmethode waarin een dergelijke aanpak gepropageerd wordt.
Verder houdt de schrijver, als ik zijn betoog goed begrijp, een pleidooi voor het gebruik van een enkele 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 hem voorbij te zijn gegaan. Het feit dat hij deze niet eens noemt, is in dit opzicht veelzeggend.
Tegen het einde van dit paragraafje treffen wij de volgende passage aan: “Wat 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?
Ook onder het laatste kopje 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.
Pseudo-alternatief
Concluderend ben ik van mening dat de heer 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 de heer Linssen er meer op uit is om zichzelf en zijn bedrijf 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
