Vervuilde grabbeltonnen

Wat hebben COBOL, SQL en UML gemeen? Het zijn op een bepaalde manier alle drie talen en alle drie zijn het afkortingen eindigend op een L. Dat klopt, maar het onderwerp van deze column is een derde gemeenschappelijke eigenschap: de vervuiling aan concepten en operatoren waar deze talen last van hebben. Ze bevatten een overdaad aan concepten en taalconstructies, met onderling overlappende en soms zelfs twijfelachtige functionaliteit. Het zijn als het ware grabbeltonnen geworden. Indien de ontwikkelaar een bepaald probleem moet oplossen, kijkt hij in de ton, steekt zijn vinger in de lucht om de windrichting te bepalen, en vraagt zich af welke constructie hij dit keer weer eens zal gebruiken. 

Laten we met de oudste van de drie beginnen: COBOL. Aan deze taal zijn door de jaren heen vele nieuwe instructies en concepten toegevoegd. Hierdoor kan een programmeur uit vele verschillende oplossingen kiezen. Voor sommigen klinkt dit als een voordeel. Net als toen ze jong waren, geldt voor hen nog steeds het motto: hoe groter de keuze bij de speelgoedwinkel hoe beter. 
Maar een groot aantal overlappende concepten moet als een nadeel beschouwd worden. Veel overlappende functies impliceert dat de software onnodig complex is, veel training vereist, dat onderhoud duur wordt, en uiteraard ontstaat hierdoor een grotere kans op fouten.

SQL kent hetzelfde probleem. Alle documenten die samen de nieuwe SQL3-standaard vormen, zijn meer dan 2000 pagina's dik. Als er zoveel pagina's nodig zijn om een taal te beschrijven is er serieus iets fout met die taal. Zeker als u zich bedenkt dat Kathleen Jensen en Niklaus Wirth slechts 167 pagina's nodig hadden om Pascal te definiëren (en dit is inclusief voorbeelden en toelichtingen). 
Chris Date, een van de grondleggers van relationele databases, schreef in 1990 een artikel waarin hij een bepaalde vraag op zeven verschillende manieren in SQL wist te formuleren. Toen maakte hij echter gebruik van de SQL1-standaard. Jaren later deed hij nog eens over, maar nu met behulp van de uitgebreidere SQL2-standaard. Hij is uiteindelijk bij vijftig alternatieve versies maar gestopt. Kunt u zich voorstellen hoeveel oplossingen er mogelijk zullen zijn met SQL3?

UML lijkt eenzelfde lot bestempeld. Het is prima dat we een verzameling technieken als standaard kiezen. Het zal de communicatie tussen analisten, ontwerpers en programmeurs verhelderen en verbeteren. De vraag is alleen of we inderdaad zoveel diagrammentechnieken nodig hebben en of binnen elke techniek zoveel concepten noodzakelijk zijn. Als we niet oppassen, zal de toekomst van UML erg veel overeenkomsten vertonen met de historie van COBOL en SQL.

Einstein heeft het zelf ooit gezegd: houd het zo simpel mogelijk! In de wiskunde en logica wordt altijd getracht het aantal concepten tot een minimum te beperken. Binnen ons vakgebied hebben we te snel het idee dat wanneer een probleem niet snel of eenvoudig met een taal opgelost kan worden, de taal dan maar uitgebreid moet worden. Op zich zou dat geen ramp zijn, maar om nu voor elk probleem een andere oplossing te introduceren, is overdreven. Op de lange termijn gaat dit problemen geven. Er zal harder nagedacht moeten worden vooraleer een nieuw concept toegevoegd wordt. Kan het bijvoorbeeld niet met een algemener concept opgelost worden, waardoor gelijk ook twintig andere problemen opgelost worden?

Laten we proberen onze talen, inclusief specificatietalen als UML, zo orthogonaal mogelijk te houden.