Declaratief programmeren: oude wijn in nieuwe zakken?
Declaratief programmeren is zowat de heilige graal van ICT op het vlak van programmeren. Onder meer Bill Gates heeft zich al bijzonder optimistisch uitgelaten over de techniek, en Microsoft zou aan een nieuwe taal werken die zich helemaal richt op intuïtieve softwareontwikkeling. Maar wat moeten we verstaan onder ‘declaratief programmeren’?
Declaratief programmeren is geen nieuw concept. De voorbije decennia is het al in verschillende verschijningsvormen opgedoken en getoetst. Zelfs SQL werd gepositioneerd als declaratieve data access: je zegt gewoon wat je wil en niet hoe het moet gebeuren.
Daarbij moet gezegd dat declaratief programmeren niet hetzelfde is als end-user-programming. De vele pogingen om de gebruiker zelf zijn specificaties, laat staan de nodige formele input, te laten produceren wekt steeds een initieel enthousiasme op, maar eindigt steevast in hetzelfde scenario: de tool terug naar de IT-mensen en de gebruikers back to the business. De enige uitzondering hierop is Excel.
Declaratief programmeren is bovendien verre van een precies gedefinieerd concept. De idee is dat de ‘code’ zeer dicht staat bij de specificatie of dat de specificatie, onder welke vorm dan ook, de code ís. Tot nu toe zijn er al een viertal technologieën die in de buurt komen maar toch altijd tekortschieten als het er op aan komt de basis te zijn voor generieke applicatieontwikkeling.
Laat ons beginnen met NLP: Natural Language Processing. Daarbij geef je instructies in de taal van de gebruiker, grammaticaal en ook qua vocabularium. Naast een aantal verdienstelijke pogingen in het bevragen van databases is deze technologie er nooit in geslaagd om als basis te dienen voor het automatiseren van de soms complexe businesslogica. Ook NLP moet zich houden aan de semantiek van de concepten en de relatie tussen concepten. En natuurlijke taal is niet echt een manier om deze dingen formeel te beschrijven. Exit NLP dus voor declaratief programmeren.
Een tweede technologie die zich kandidaat stelt om het label declaratief programmeren te krijgen is Rule Based Programming (RBP). Ofschoon RBP heel erg in de buurt komt van declaratief programmeren blijft het wel programmeren. Met andere woorden: applicatiestructuur en architectuur, informatiemodellen of objectmodellen die de concepten formeel vastleggen, zijn bij RBP even belangrijk als bij procedureel programmeren. En vergeet niet dat procedureel programmeren ook zeer natuurlijk kan zijn, met name op het ogenblik dat we willen dat een aantal instructies of taken in een welbepaalde volgorde moeten worden uitgevoerd. Het is een grote uitdaging om een procedure op een niet-procedurele manier te gaan beschrijven.
RBP bewijst wel zijn grote toegevoegde waarde, ondermeer bij event-driven programming, workflow implementatie, maar ook bij het beheersbaar en onderhoudbaar automatiseren van complexe businesslogica. Het verwondert mij nu al enkele jaren dat noch in de Java virtual machines, noch in de .NET CLR, de mogelijkheden van RBP ingebakken zitten. Maar ook hier schuilt het gevaar: “Als je alleen een hamer hebt, ziet alles er uit als een spijker.” Gebruik de declaratieve mogelijkheden van RBP op die plaatsen binnen de architectuur van de toepassing waar het een onmiddellijk nut heeft. En onthoudt: het is en blijft Rule Based Programming, werk dus voor mensen die hierin zijn opgeleid.
Een derde technologie zijn de declaratieve programmeertalen. Hoewel ze nooit zijn doorgedrongen, zijn er wel een aantal zeer verdienstelijke pogingen geweest. Eind jaren tachtig heb ik het geluk gehad met een declaratieve programmeertaal te mogen werken. Het was een code generator die op basis van de niet procedurele instructies COBOL genereerde. En het werkte. Men concentreerde zich op wat het programma moest doen en niet op hoe je het moest implementeren. Het enige nadeel: het integreerde niet zo goed bij de bestaande applicatie-infrastructuur. Het was alles of niks. En toegegeven: op een bepaald moment was het toch ook nodig om wat meer procedureel te ‘programmeren’ en dat was dan soms wat moeilijk. Wat men wel ziet is dat de idee groeit om zich meer te concentreren op het ‘wat’ van de instructie in plaats van het ‘hoe’. Ook het ‘set-oriented’ aspect van een instructie blijkt meer en meer ingang te vinden. Een goed voorbeeld hiervan is LINQ van MS. Een mooie evolutie.
En tenslotte MDA (Model Driven Architecture). MDA is al enkele jaren onder ons, sinds 2001 meer specifiek. Platform Independent Models (PIM) worden via een Platform Definition Model (PDM) omgezet naar een Platform Specific Model (PSM). Code wordt gegenereerd vanuit de modellen. Voor de academici is dit wel een zeer zuivere manier van applicatieontwikkeling. Er zijn wel niet veel bedrijven die in deze richting aan het evolueren zijn. Sommigen wagen zich aan codegeneratie vanuit UML-diagramma’s. Het probleem is dat eens de code genereert is, men verder werkt op deze code en niet op het model zelf. En wat met algoritmes, berekeningen of beslissingsbomen? Het vraagt heel wat discipline en formalisme om dit in een model te kunnen gieten.
Al deze technologieën en ideeën hebben één ding gemeenschappelijk: ze verplichten de gebruiker, lees ‘de ontwikkelaar’, om op een hoger niveau van abstractie te gaan denken en werken, en daardoor ook behoorlijk wat controle uit handen te geven. Het citaat van Frank Minderman: “Controle is goed, maar vertrouwen is beter”, is nog niet echt doorgedrongen in ICT.
