Zo’n 80 jaar geleden werden de eerste stappen gezet op het gebied van programmeren. In die tijd werd er geprogrammeerd op het niveau van de machine in binaire waarden; de bekende nulletjes en eentjes. Omdat dit een erg ingewikkelde manier van programmeren was, werden er talen ontwikkeld op een hoger niveau die in staat waren om de ingevoerde code om te zetten naar de taal die de machine kon begrijpen: een assembler. Voorbeelden van dergelijke talen zijn bijvoorbeeld Fortran en Cobol. In die tijd was er ook nog geen muis aan de computer gekoppeld, simpelweg omdat die op dat moment nog niet uitgevonden was. Dat hield in dat alle besturing van de applicatie en invoer van gegevens middels het toetsenbord moesten plaatsvinden. Een leuk feitje: om die reden is het toetsenbord uitgebreid met de functietoetsen die je nu nog steeds bovenaan je toetsenbord kunt terugvinden. Namelijk de toetsen F1 tot en met F12, waarbij het de afspraak was dat je met F1 een helpfunctie kon oproepen. Mits deze natuurlijk geprogrammeerd was 😉.

Grafische omgeving

De eerste grafische omgeving waarin een programmeur kon werken was ontwikkeld door Xerox, de Xerox Alto computer. Dit is tevens de eerste computer die gebruik maakte van een muis. Vanaf dat moment deden ook de grafische widgets zoals radiobuttons, checkboxen en pictogrammen hun intrede. Dit idee werd later overgenomen door Steve Jobs van Apple en Bill Gates van Microsoft. Het eerste grafische besturingssysteem dat door Microsoft is ontwikkeld heet Windows 1.0 en kwam midden jaren 80 op de markt. Vanaf die tijd werd het ook mogelijk om in een grafische omgeving te programmeren. De gangbare programmeertalen kregen een IDE (Integrated Development Environment) waarin met gebruikmaking van widgets GUI’s (Graphical User Interface) applicaties ontwikkeld konden worden. Voor Microsoft kon daarbij gebruik gemaakt worden van Visual Basis 1.0 wat kon draaien op het grafische besturingssysteem Windows 3.x. De lancering van Visual Basic 1.0 vond plaats in mei 1992.

De 'sleur-en-pleur' methode

Met deze nieuwe versie van ontwikkeltools was het voor de programmeur een stuk eenvoudiger geworden om applicaties te ontwikkelen. In plaats van alle objecten die op het scherm geplaatst moesten worden in code uit te werken, konden nu de Controls (denk aan een radiobutton) naar het scherm gesleept worden en werd in feite alle code die te maken had met de opmaak van het scherm al op de achtergrond voor de programmeur gecreëerd. Ook wel de “sleur-en-pleur” methode genoemd. De programmeur hoefde dan alleen nog maar de functionaliteit achter de schermen, denk aan bijvoorbeeld de opslag van gegevens of het uitvoeren van berekeningen, te programmeren. Een bijkomend voordeel van deze grafische ontwikkelmethode was het zogenaamde WYSIWYG (What You See Is What You Get), oftewel zoals de programmeur het scherm voor zich zag, was ook het beeld zoals de uiteindelijke gebruiker dat scherm onder ogen zou krijgen.

'The future of coding is no coding at all'

Maar zoals altijd gaan de ontwikkelingen verder. Zoals CEO van GitHub, Chris Wanstrath, ooit zei: “The future of coding is no coding at all”. Het idee hierachter is dat heel veel zaken die bij het programmeren komen kijken te maken hebben met het invoeren, wijzigen, verwijderen of presenteren van data. Die data is veelal object georiënteerd. Denk bijvoorbeeld aan het object ‘Klant’. Een klant heeft een aantal gegevens die wij van hem of haar willen vastleggen, bijvoorbeeld naam en adresgegevens. Door alle entiteiten die we in onze applicatie nodig hebben, te vormen tot een samenhangend datamodel, wordt in feite de basis gelegd voor de applicatie. Naar alle waarschijnlijkheid zullen alle entiteiten onderhouden moeten worden. Oftewel toegevoegd, gewijzigd of verwijderd kunnen worden. Het enige wat verschilt zijn de onderliggende attributen/kenmerken van een dergelijke entiteit. In een LowCode/NoCode omgeving is het mogelijk om voor deze functionaliteiten een standaard template te ontwikkelen. Op basis van zo’n dergelijke template wordt, gebruikmakend van de attributen die onderdeel uitmaken van de entiteit, het scherm opgebouwd om de gegevens te tonen en functionaliteit voor het opslaan, wijzigen of verwijderen van gegevens uit het onderliggende datasysteem. Dit alles wordt gegenereerd zonder dat de programmeur ook maar één regel programmacode geschreven heeft.

Waarom dan niet alleen NoCode in plaats van LowCode/NoCode

Dat komt omdat natuurlijk niet alles door templates die vooraf gedefinieerd zijn te ondervangen is. Soms moet er toch nog wat “maatwerk” geleverd worden. Op dat moment komt de LowCode om de hoek kijken. Ook het “programmeren” in een dergelijke omgeving is aangepast aan de nieuwe manier van werken. Het “programmeren” vindt niet meer plaats in het schrijven van coderegels maar door het configureren van een data-stroom/proces-schema. Hierin kunnen wederom met behulp van een soort controls-acties op de onderliggende gegevens worden uitgevoerd. Denk aan bijvoorbeeld het inplannen van een meerdaagse cursus die rekening houdt met weekenden en feestdagen, zodat cursusdagen alleen op werkdagen ingepland zullen worden.

Het grote voordeel van deze methode van werken is dat applicaties veel sneller gerealiseerd kunnen worden. Daarnaast zijn de applicaties veelal direct te gebruiken op meerdere apparaten (mobiel, tablet en desktop) zonder ook maar één “regel” te coderen.