Assembler, Fortran en Cobol. Enkele oudjes onder de programmeertalen winnen aan populariteit. Ook SQL beleeft een revival. Wat is er aan de hand?
We halen de bevindingen uit de recente editie van de Tiobe Index, een van de lijsten die Computable gebruikt voor zijn eigen index.
Al heeft Tiobe de neiging om te mikken op de eerder klassieke benadering van it (en programmeertalen). C staat daar bijvoorbeeld op de eerste plaats, gevolgd door Python (terwijl die bij veel andere de lijst aanvoert) en Java op plek drie.
Assembler
Opvallend zijn de oudjes in hun index. Zo stijgt Assembler in een jaar tijd van veertien naar negen, en rolt dus de top tien binnen. Dat is opvallend voor een taal die echt teruggaat naar de basics van programmeren. Assembler is nauwelijks meer dan een symbolische weergave van machinetaal. Ze ontstond in 1947, en is dus bijna 75 jaar oud.
Seppe Vanden Broucke, professor aan de UGent en KU Leuven, ziet een aantal redenen voor de comeback van Assembler. ‘Assembler wordt gebruikt voor embedded en internet of things-toestellen met vaak weinig stroomverbruik en geheugen’, stelt hij. ‘En dergelijke toepassingen zitten in de lift.’
Een andere reden is dat het een belangrijke hobby-taal is. ‘Bijvoorbeeld voor Arduino-achtige projecten, vaak gerelateerd aan iot. Ook zogenaamde retro-computing platforms, die de laatste tijd in opmars zijn, maken er gebruik van. Projecten als Mega65‘, stelt Vanden Broucke, ook in security een rol voor Assembler ziet. ‘Zo zijn er toch nog veel exploits die Assembler gebruiken voor de kritieke delen.’
Fortran & Cobol
De grootste stijger in de recente Tiobe-lijst van programmeertalen is Fortran. Die gaat op een jaar tijd maar liefst van 37 naar 17 in hun Index. Ook Fortran is een oude krijger. Het was een programmeertaal die in de jaren vijftig ontstond en door IBM werd aangeboden.
Bij Tiobe zelf wijten ze de opmars van Fortran aan ‘de massale behoefte aan getallen kraken’, vaak voor wetenschappelijke projecten. ‘Fortran heeft één duidelijke gebruikstoepassing in machine learning. Onderliggend is er heel veel Fortran-code die daarbij wordt gebruikt’, beaamt Vanden Broucke, die zelf voor it-gebruikersvereniging SAI onlangs een webinar over trends in programmeertalen en dit aanhaalde.
Verder in de lijst houdt ook Cobol behoorlijk stand op plaats nummer 25. Al is dat niet echt een comeback. Traditionele programmeertalen blijven vaak vrij lang aan, door hun legacy. En ook een taal als Cobol, een taal uit de jaren zestig, gaat maar moeilijk weg. Het is zo dat er het voorbije jaar bij een legacy-vernieuwing wel wat Cobol is gebruikt (of opgefrist). ‘Maar dat zijn geen nieuwe projecten’, nuanceert Vanden Broucke.
SQL
Wie ook mooi standhoudt in de lijst is SQL, een querytaal. ‘We hadden de laatste jaren een beetje het gevoel van dat SQL aan het verdwijnen was’, aldus de professor. ‘Maar SQL is het database lingua franca.’
Voor SQL spreekt de professor wél van een opmars. ‘Met de komst van NewSQL, zoals een MongoDB en dergelijke, zien we vandaag zelfs een revival in SQL’, vindt hij. ‘Het idee leeft toch wel dat die oude databanken nog niet zo slecht waren. Ook met de beweging naar cloud gerichte databanken en dataplatformen zoals Dremio en Snowflake, is men SQL terug volledig gaan omarmen als querytaal’, stelt hij.
Is die revival van SQL niet opmerkelijk? ‘Velen beseffen dat ze die taal niet willen missen, want het alternatief wordt niet altijd als beter aanzien. Het zal waarschijnlijk nog vele jaren duren alvorens SQL dood valt te noemen.’
Je moet sneller dan je schaduw klikken om 1500 maal per minuut te klikken, probeer het maar eens met een stopwatch. Rob is dan ook niet echt realistisch als we kijken naar round-trip van de gebruikelijke online transactiesystemen welke niet van batchverwerkingen houden. Dat wil natuurlijk niet zeggen dat je via de achterdeur de truc niet kunt doen want scripts en job schedulers zijn niet echt nieuw en ik was altijd goed in mezelf weg automatiseren. Dat leverde weer de kennis voor loadtesten op want het juist dimensioneren van een systeem scheelt een heleboel geld, misschien wel meer dan de FTE die ook wat anders kan doen. Zo knijpen we Rob met zijn RPA via QoS want geen mens kan een factuur of journaalpost in een fractie van een seconde controleren. Je kunt die proces stap er natuurlijk ook tussenuit halen maar volgens mij pas je dan het business proces aan welke opeens tot een integriteitsprobleem leidt als er geen controle meer is.
@Oudlid, de controle e.d. zijn allemaal aansluitende workflow processen die òf in het asynchrone (vervolg)deel van de api call zitten òf via een message queue gaan. Die processen kunnen op een email-reactie zitten wachten, een voorraadcheck bij een leverancier moeten doen, een externe credit-check, een doorverwerking naar een erp-programma, enz. Daar hoeft de API-client allemaal niet op te wachten. Als we een API-client laten wachten en we zoeken een crediteur op (of we maken hem rudimentair aan, we een invoice header aanmaken, gemiddeld 2 à 3 factuurregels met lookup/rudimentaire aanmaak van voorraadartikel met lookup/aanmaak verpakkingseenheid/prijs van betreffende artikel, halen we toch echt wel circa 1800 facturen per minuut in een gecompileerde t-sql stored procedure (in een met NVMe SSD en 512GB RAM opgepimpt servertje van 6 jaar oud waarbij de betreffende virtual server dan circa 80GB krijgt). Moet je wel in 1 roundtrip de betreffende JSON List aanleveren in de SQL-server natuurlijk.
@Will, Python zou zeker een optie zijn. Kan ook in SQL-Server, dus geen van/naar van data. We zijn echter helemaal ingevoerd op T-SQL en ik denk dat Python ten opzichte daarvan toch nog wel wat beperkingen zou hebben en vermoedelijk geen extra mogelijkheden.
Rob,
Natuurlijk kun je fantastische prestaties halen als je alles in-memory op één server kan doen maar de realiteit na meer dan 30 jaar SOA is dat verschillende servers onderling communiceren via API-interfaces en message queue’s waardoor de round-trip van één transactie steeds langer wordt omdat er steeds meer schakels aan de ketens toegevoegd zijn. En natuurlijk kun je eerst alle bestellingen consolideren zodat je één bestand hebt wat je middels een batchverwerking kunt laten doen maar daarmee pas je eigenlijk het proces zelf aan, je gaat van een online parallel proces waarin de transacties binnen druppelen naar een sequentieel proces waarin je in één keer een emmer leeg gooit. Die keus kan trouwens heel valide zijn als we kijken naar de aanpassing van tabellen maar ik vrees dat we het dan niet meer over de RPA van het automatiseren van klikken in de fornt-end hebben.
Klopt, het ging inmiddels over het automatiseren van de rol van gebruiker.
Ter aanvulling, jouw realiteit na 30 jaar SOA is inmiddels volkomen verouderd. Het kan echt allemaal slimmer.
Als ik kijk naar mijn dagelijkse realiteit waar welbekende ‘bill of materials’ al snel enkele honderden factuurregels heeft als ik het project tot in detail moet specificeren dan heeft concept van de online transactionele verwerking van één-voor-één duidelijk een voordeel in het maatwerk waarin de onderdelen van verschillende leveranciers op elkaar afgestemd moeten zijn. De beslissingstabellen van Jack gaan om de keuzevrijheid die je hebt want de massaproductie van een lopende band lijkt me verouderd als we kijken naar de marktveranderingen. Het kan dus inderdaad een stuk slimmer nu dingen sneller wijzigen en paradigma van SOA heeft naar mijn mening daarin een voordeel omdat de workflow sneller aan te passen is door het principe van ‘disconnected processes’ waardoor er minder afhankelijkheden in de keten zijn. Ik kan bijvoorbeeld winkelen bij de AH maar ook bij de Jumbo als beiden hetzelfde leveren en alleen nog op de prijs met elkaar concurreren. Slimmer wordt dan het welbekende kwaliteitsaspect van goedkoper hoewel het vaak lastig is om appels met appels te vergelijken doordat het vraagstuk van standarisatie uiteindelijk haaks op de commerciële belangen van de leverancier staat. Wij van WC-eend kennen dan ook de truc van business logica in proprietary code stoppen want Transact-SQL is volgens mij niet een open standaard.
@Oudlid, dat soort bill-of-materials-achtige processen is vaak al sinds edifact in voorzien. In onze gevallen gaat het om tot dan toe handmatig werk. Op de koppelvlakken volgen we zoveel mogelijk Odata. Mvg rob.
Will, als je het zo stelt is nocode niets anders dan orkestratie!
Je (zeer verhelderende!) reactie maakt duidelijk dat lowcode- en nocode-tools geen oplossing bieden voor het vormgeven van bedrijfsfunctionaliteit, zoals bij de vermelde passenger rebooking-challenge, maar voornamelijk een rol spelen bij het modelleren van opeenvolgende processen. Ik was dus inderdaad appels met peren aan het vergelijken.. 🙂
Maar….
Is orkestratie niet een ander woord voor (proces)spaghetti?
Dan is het de hoogste tijd om procesmodellen te vereenvoudigen met beslissingstabellen:
https://blog.sapiensdecision.com/how-the-decision-model-drastically-simplifies-process-models/
die hier nog minder gelukkig decision models worden genoemd.
Het vervangen van procesmodellen (dus low/nocode) door beslissingstabellen (dus 5GL) is dus beslist een stap in de goede richting:
https://openrules.wordpress.com/2020/10/17/rules-based-service-orchestration/
al mag het van mij nog wel wat doelgerichter, zoals blijkt uit de hier vermelde Loan Origination example/challenge.
Op een website kwam ik de volgende evolutie van programmeertalen tegen:
3GL – 4GL – Lowcode – Nocode
Maar als Low/Nocode vooral een rol speelt op het vlak van de opeenvolgende processen, blijf je op het vlak van de bedrijfsfunctionaliteit dus afhankelijk van de duistere algoritmen van een 3GL en/of machine learning-code (ofwel de blackbox van Oudlid). Waarmee je dus blijft knoeien met de beruchte Business-IT-alignment.
Hierbij is Lowcode en Nocode dus een aanvulling op 3GL en 4GL; je opmerking
“Bij lowcode/nocode draait het om het versnellen van applicatiebouw – de onderliggende database-structuur en/of taal is daar niet of nauwelijks relevant” klopt dus precies.
In mijn optiek is de evolutie van programmeertalen echter – verrassing – :
3GL – 4GL – 5GL
waarbij 5GL wordt toegepast voor het beschrijven van functionaliteit (als vervanging van 3GL en aanvulling op – eventueel al bestaande – 4GL-databases) èn de end-to-end applicatieflow.
Zoals 3GL ooit ter vervanging diende van 1GL/2GL Machinetaal/Assembler.
Waar stroomschema’s tekort schieten is het rekening houden met de persoonlijke situatie van de klant/burger; precies het punt waarop de belastingdienst steeds onder vuur ligt (toeslagenaffaire, schuldenbeleid, etc).
https://www.nu.nl/economie/6120737/belastingdienst-weer-onder-vuur-mensen-met-schulden-niet-goed-beschermd.html
Wil je wel rekening houden met de persoonlijke situatie van de burger met stroomschema’s, dan leidt dat tot een onontwarbare processpaghetti/flowchartspaghetti. Wat je dus precies vermijd met het toepassen van beslissingstabellen/taal (en dan doelgedreven ipv. datagedreven)!
Waar het mis gaat met een nocode-aanpak is af te leiden uit de volgende formuleringen in je reactie:
“..stroomlijnen van grotendeels *sequentieel* uitgevoerde administratieve processen”
“..digitaliseren van vele * opeenvolgende* digitale en/of fysieke “papier-“stromen”
“.. elkaar opvolgende bewerkingen”
En dan wordt het tijd om één van de bekendste voorvechters van de beslissingstabellentechniek te citeren (in “De vaste waarden van de systeemontwikkeling” uit 2003, blz. 7):
https://www.frankrobben.be/publications-press/commemorations/prof-dr-maurice-verhelst/
“In dit verband moet worden opgemerkt dat het gebruik van flowcharts bij het programmeren een verderfelijke praktijk is; flowcharts behoren tot de slechtste technieken die men bij het programmeren ooit heeft gebruikt. Ze dwingen de programmeur sequentieel te denken en verhinderen juist daarom dat hij ruimtelijk denkt.”
Hoi Jack,
Zie inzake OpenRules s.v.p. de vragen in mijn reactie van 15 aug 14:37.
Evolutie is niet zo makkelijk, vooral als het de toekomst betreft. Evolutie is aanpassing aan real world veranderingen. Want Life is what happens to you, while you’re busy making other plans. Dus braaf meebewegen met de agile naar de cloud movement. You’ll never walk alone.
Wat hebben 4GL/5GL talen nu daadwerkelijk opgelost ? Het niet gebruiken ervan is geen complot of kennisgebrek. Het heeft momenteel (de laatste 30 jaar) alleen een beperkt toepassingsgebied. Als ik mijn programeeruitdagingen met alleen specificatie van input/output en paar tabellen kon oplossen, dan deed ik het meteen. Dat we als zowel niet- als wel-iters zoveel moeite hebben met specificeren, dat verklaart overigens ook de noodzaak van agile. Continuous gepruts, maar wel steeds stukkie beter result, hopen we dan maar. En als het design slecht bleek, wordt het uiteindelijk legacy. Dan beginnen we opnieuw.