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.’
@Jack:
“Ben natuurlijk wel benieuwd hoe citizen developers dit probleem oplossen met hun lowcode en nocode tools :-)”
Nog even voor de duidelijkheid: welk probleem zou er opgelost moeten worden?
Bij lowcode/nocode draait het om het versnellen van applicatiebouw – de onderliggende database-structuur en/of taal is daar niet of nauwelijks relevant = je vraag heeft veel weg van iets over appels en peren en zo?
🙂
=====
Voor de volledigheid mijn € 0,50 over de meerwaarde van nocode (bij lowcode heb ik wat bedenkingen).
De sweet spot van nocode zit hem vooral in het stroomlijnen van grotendeels sequentieel uitgevoerde administratieve processen – zeg maar het digitaliseren van vele opeenvolgende digitale en/of fysieke “papier-“stromen.
Of het in elkaar schuiven en optimaliseren van de gegevensverwerking rondom meerdere losse administratieve systemen.
Een voorbeeld over de as van “papier-“stromen: near-realtime registratie en verwerking van aankopen van producten en diensten; inclusief geautomatiseerde fiscale verrekening met de belastingdienst (versus achteraf verrekenen via het indienen van declaraties met bijbehorende bonnetjes) = iets wat vooral relevant is voor de medewerkers van (bijvoorbeeld) de Europese Commisie en buitenlandse ambassades.
Een voorbeeld over de as van het in elkaar schuiven van losse administratieve systemen: het administreren van opportuniteiten rondom adviesopdrachten, de daaropvolgende inzet van groepen interne en externe consultants, de financiele verrekening, bijbehorende facturatie en financiele analyses = alles near-realtime zodat er wekelijks en maandelijks helderheid is omtrent mogelijke opdrachten, beschikbaarheid van mensen en de cashflow.
Versus alle inzichten op het eind van de maand volgend op de maand waarin de uren/diensten feitelijk geleverd zijn = zoiets als een auto besturen met een nagenoeg permanente blik op de achteruitkijkspiegel.
Karakteristiek bij een dergelijke nocode aanpak is het bij elkaar klikken van stroomschema’s, gegevenselementen en de bijbehorende elkaar opvolgende bewerkingen. Hierdoor is er een enorme tijdwinst te boeken in vergelijking met een traditionele aanpak; waaronder de keuze van een data(base) model en query-taal. Dit is bij nocode allemaal niet of nauwelijks relevant.
Rob, nog even wat achtergrond info bij OpenRules.
Drijvende kracht achter dit platform is Jacob Feldman, zoals bovenaan de website staat vermeld.
Hij is schrijver van 2 boeken, die ik niet heb gelezen, maar de titels zijn veelzeggend:
– DMN in Action with Openrules (2017)
– Goal-Oriented Decision Modeling with Openrules (2019)
Hij volgt de DMN-standaard (DMN = ‘Decision Modeling and Notation’), maar is er ook kritisch over.
Hier bijvoorbeeld: https://openrules.wordpress.com/2018/06/18/keep-dmn-simple/
“However, today DMN is full of complex, programmer-oriented features which seem to get even more complex in new releases. There are plenty examples of unnecessary complexity being proudly promoted for their “elegance”. “
En verderop vetgedrukt:
“We need to keep the DMN standard oriented to business users.”
Naast DMN is hij ook voorstander van Goal Orientation, zoals blijkt uit zijn tweede boek.
En daarmee wedt hij, mijns inziens, op 2 verschillende paarden, die in tegengestelde richting lopen.
DMN is namelijk niet doelgedreven maar datagedreven. In mijn optiek gaat de Goal Orientation van OpenRules dus nog niet ver genoeg. Waarbij ik het verband tussen Goal Orientation en Service Orientation nu maar even laat voor wat het is.
Met deze informatie zijn we er nog niet, want dezelfde Jacob Feldman is ook de drijvende kracht achter de website: https://dmcommunity.org/challenge/
En dan vind ik dit berichtje van hem wel heel aardig:
https://dmcommunity.org/2021/04/14/which-rules-not-to-execute/
————————————————————-
Will, bedankt voor je inzichten!
Daar ga ik nog even op kauwen 🙂
@Jack, ik heb het verhaal gisteren doorgelezen en snap er nog niet veel van.
Is er sprake van een of andere engine waar vanuit wordt gegaan maar verder in het artikel (https://openrules.wordpress.com/2020/11/13/accessing-database-from-business-rules/) niet wordt genoemd? Is er ergens een relationele structuur waarin type (DataSQL) is uitgewerkt? Bijvoorbeeld Decision Table DefineTotals heeft vier kolommen – twee aan twee – (condition/conclusion) ieder met een onderverdeling van twee (Payment Amount etc. met daaronder 8 kolommen, twee aan twee (conditie/operator). Ik zie zo niet hoe ik hiervan een proof-of-concept kan uitwerken zonder eerst op een aantal onderdelen eerst het wiel opnieuw uit te moeten vinden.
mvg Rob
@Will, waar je m.i. over praat, is het automatiseren van de rol van de gebruiker. Dat is waar het bij ons ook voortdurend over gaat. Ik ben ook met je eens dat de keuze van de database model en query taal daarbij in principe niet belangrijk is, althans niet in meerdere mate dan dat die keuzen in het algemeen van belang zijn. Maar zeker ook niet in mindere mate.
Bijzonder hoe de discussie zich betreffende code ontwikkelt want de blackbox is niet de code van de front-end welke eenvoudig te vervangen is zoals Jack en zijn SOA vriendjes laten zien. Blackbox van de back-end gaat om achterliggende data architectuur wat steeds vaker een datalake is waar dynamisch de benodige informatie uit verkregen kan worden door het real-time combineren van data op een front-end device hoewel de QR-code voor toegang dus nog even statisch is als de beslissingstabellen van Jack. Ik heb de QR-code daarom maar gewoon uitgeprint want de belofte dat de locatiegegevens niet gebruikt worden is niet erg geloofwaardig uit de mond van een minister die alleen maar liegt.
@Rob
“waar je m.i. over praat, is het automatiseren van de rol van de gebruiker”
Is dat niet per definitie het geval? Als in: gaat het niet altijd om het (weg-?)automatiseren van gebruikersrollen? Tis te zeggen… mij lijkt dat dit de primaire driver zou moeten zijn achter de inzet van IT?!
Kan je het hooguit nog hebben over wie je dan als “gebruiker” ziet… 🙂
=====
“althans niet in meerdere mate dan dat die keuzen in het algemeen van belang zijn. Maar zeker ook niet in mindere mate”
Hangt er vanaf uit welke elementen je lever- en verdien-model bestaat.
Als daar een vorm van (technisch) applicatie- en systeem-beheer bij zit klopt je stelling. Immers, de keuze voor een DBMS gaat gepaard met keuzes voor een onderliggend OS en infra; al dan niet afgenomen in IaaS- of PaaS-vorm. De mate en manier waarop je die combi beheer(s)t is leidend voor het rendement op die elementen van het lever en verdien-model.
Is het een model op basis van applicatiebouw en functioneel beheer (wat als SaaS-dienst wordt afgenomen = nocode), dan maakt het DBMS niet meer uit = iemand anders zijn probleem/vraagstuk. En daarmee een element in het lever- en verdien-model van die “iemand anders”.
=====
En dit is dan enkel het aspect “applicatie-techniek” – de aard van de opslag, de te verwerken gegevens en bijbehorende governance komt daar nog eens bovenop = moet ook beheer(s)t worden.
Voordeel is dat dit een generiek element is in welk model dan ook. Maar inhoudelijk wel eentje met een grote variëteit aan smaakjes: on-prem, cloud-storage voor backup, IaaS, PaaS, SaaS, etc. Laat staan als er gewerkt wordt me een hybride model…
@Will, Inzake automatisering van de rol van de gebruiker is dat – zoals ik het bedoel – niet per definitie het geval. Je automatiseert een toepassing of proces en dat vergt gebruikers. De gebruikers hebben vaak met meerdere applicaties te maken. Wij proberen die gebruikers te ondersteunen of routinematige taken zelfs over te nemen met Workflow/Robotic Process Automation. Het Worfklow process kan daardoor worden gezien als een (virtuele) gebruiker van de aanwezige applicaties. In iets groter verband worden applicaties daarmee elkaars gebruiker.
@Rob: ok – even een voorbeeld – als tjek op wat je bedoeld.
Stel je hebt een taak in een proces wat op dit moment 1 FTE aan tijdbesteding vraagt. Die tijd gaat op aan het herhaald uitvoeren van een serie clicks verdeeld over – zeg – 12 verschillende applicaties.
Dat wordt vervangen door een stukje (RPA-)software wat dezelfde clicks voor diezelfde applicaties doet. Waardoor je de rol van de gebruiker niet direct hebt vervangen; enkele degene die de rol vervult: dat was eerst die ene FTE (verdeeld over bijvoorbeeld 4 medewerkers) en is nu dat stukje RPA-software.
De business case zit hem er dan in dat de kosten voor die ene FTE substantieel hoger zijn dan (1) – de kosten voor die RPA-software, (2) – het inregelen en (3) – het beheer/onderhoud. Waarbij beheer/onderhoud, naar verwachting, vooral betrekking heeft op veranderingen in de gebruikersinterface van die 12 applicaties. Dit omdat de tjeks en clicks in de workflow van de RPA-software dan wellicht aangepast moet worden.
Zoiets? Ongeveer?
Ja, klopt helemaal in mijn visie. Maar er is meer. 1. de RPA zit op ieder moment klaar, terwijl sommige wenselijke acties bij een menselijke gebruiker mosterd na de maaltijd kunnen zijn. 2. Dat heeft een gevolg: uit het feit dat een actie nog niet heeft plaatsgevonden, kan worden afgeleid dat de geassocieerde gebeurtenis nog niet heeft plaatsgevonden. 3. De RPA-kan 1500, 2000 verwerkingen in een minuut afhandelen en dan weer dagen geduldig wachten. 4. De RPA (gebruiker) kan worden gevoed met wat hij zelf eerder heeft aangemaakt (voor backups, versie-migraties, dingen met een terugkerend karakter zoals abonnementsfacturen, (memoriaal) journaalposten van periodieke afschrijvingen en dergelijke).
@Rob:
“2. Dat heeft een gevolg: uit het feit dat een actie nog niet heeft plaatsgevonden, kan worden afgeleid dat de geassocieerde gebeurtenis nog niet heeft plaatsgevonden”
“4. De RPA (gebruiker) kan worden gevoed met wat hij zelf eerder heeft aangemaakt (voor backups, versie-migraties, dingen met een terugkerend karakter zoals abonnementsfacturen, (memoriaal) journaalposten van periodieke afschrijvingen en dergelijke)”
Ja – dat zijn inderdaad mooie use cases.
En als ik vragen mag: wat is een voor dit doel fraaie RPA oplossing?
Andere vraag: heb je ooit eens overwogen om dit soort dingen met Python in te regelen?
Rationale achter Python (afgaande op het begin van het artikel): heb je Python eenmaal onder de knie, dan zijn er legio mogelijkheden. Zowel aan de kant van de werknemer (toekomstperspectief) als voor een IT-dienstverlener (hogere automatiseringsgraad van beheertaken).