Theo de Ridder
Prometa Ratum
<ridder@xirion.nl>
Het is opvallend dat tot de eerste programmeertalen meteen talen behoorden die zich weinig aantrokken van onderliggende hardware. Voorbeelden zijn APL, LISP, SNOBOL en SIMULA. Deze oertalen probeerden vooral een paradigma zo puur mogelijk vorm te geven. De betreffende paradigma's waren zo goed gekozen dat er in al die tijd weinig nieuws aan is toegevoegd. Helaas kunnen de talen die het uiteindelijk echt gemaakt hebben nauwelijks van enige puurheid, abstractie of elegantie beschuldigd worden. Te denken valt dan natuurlijk aan Fortran, Cobol, Basic en C/C++.
Pogingen om de complexiteit van software te reduceren met 4GL-achtige scripttalen hebben betrekkelijk weinig geholpen. Voor een deel komt dat door de talloze ontwerpfouten van scripttalen die zich vooral bij grotere applicaties wreken. Daarnaast wordt de inspanning om software te maken slechts voor een klein deel bepaald door de kwaliteit van de te gebruiken programmeertaal zelf. Het gaat ook om zaken zoals de beschikbare ontwikkelomgeving en het gekozen ontwikkelproces.
Een oude droom die steeds opnieuw leven wordt ingeblazen is hergebruik van bestaande componenten. Opvallend is dat de grootste pleitbezorgers van hergebruik vaak eerst al het bestaande over boord willen zetten. Men denke daarbij bijvoorbeeld aan dat wat zich nu rondom Java afspeelt. Effectief hergebruik heeft veel te maken met een onderliggende architectuur. De bouwstenen van zo'n architectuur blijken te berusten op vrij abstracte patronen, die lang niet altijd rechtstreeks op taalconstructies zijn af te beelden. Een goede architectuur dient met name de impact van te verwachten veranderingen in te perken.
Er bestaat een schattingsmodel dat bij een bepaald veranderingspercentage van de requirements aangeeft wat de maximale omvang van de te ontwikkelen software is alvorens er absolute chaos onstaat. Die omvang is voor C/C++ 4000000 regels bij 1% maandelijkse verandering, 80000 regels bij 5%, en 2800 regels bij 20%. Dit verband is extra verontrustend omdat nu niet alleen de doelen maar ook de middelen van het softwareproductieproces zeer snel veranderen. Het is dus niet toevallig dat Cobol en Fortran het zo lang volhielden.