Comeback van oude programmeertalen

De opmars van Assembler, Fortran en SQL

Dit artikel delen:

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

"Assembler groeit onder meer door Arduino-achtige projecten"

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.’

De Tiobe-index vind je hier; de Computable-index hier.

x

Om te kunnen beoordelen moet u ingelogd zijn:

Dit artikel delen:

Lees verder


Reacties

Dan krijgt Forth wellicht straks ook nog een revival. De Next-interpreter van Forth springt naar het adres dat volgt op de assembly code van die interpreter (van Forth-word naar Forth-word totdat hij op een opcode Forth-word terecht komt, een Forth-word dat niet met het Builds-deel van de Builds/Does-constructor is gebouwd. Dan komt ie dus niet meer op een opcode assembly van de Next-Interpreter terecht maar in functionele op-code. Onder Andere Harvard SoftWorks had een compiler/optimizer gebouwd die alle Next opcode verwijderde uit een versie voor deployment en dan kreeg je ongelooflijk snelle op-code waar het resultaat van een C-compiler alleen maar tegenop kon als je wist wat je moest doen om daarmee optimaal snelle code te krijgen. Forth had ook reverse polish notation dat direct aansloot op het push/pull-karakter van CPU's. Had Intel de smeekbeden van de toenmalige community opgevolgd en een Next-instructie ingebouwd in de CPU, weet ik niet hoe het met Forth gegaan zou zijn.

Als ik met goed herinner kon de optimizer ook nog bepalen of hij sommige code maar repeterend achter elkaar moest zetten of toch opteerde voor een loop (maar dat kan ik er later ook romantisch bij gefantaseerd hebben :-))

Grappig dat Cobol als oude taal wordt gemarkeerd, en C niet, terwijl ze niet zoveel van elkaar in leeftijd verschillen... Maar met C++, Java en C# als direct afgeleiden, oogt C veel moderner (en minder oubollig) dan Cobol, dus ik snap het wel.

SQL is geen taal zoals bv C, het heeft toevoegingen nodig zoals PL/SQL of Transact-SQL om het een volwaardige taal te maken.

SQL is al tijden de voorkeursmethode om iets met data in een database te doen. Dankzij Spark SQL implementaties is het ook mogelijk om in (Databricks) notebooks met SQL op dataframes te werken, bijvoorbeeld tussen de Python statements door.

Ik zou SQL geen taal willen noemen, maar meer een onder woorden gebrachte wiskunde (verzamelingenleer). Het is een gestructureerde manier om te benoemen welke verzamelingen er moeten worden meegenomen in het verkrijgen van een uitkomst.

Met de komst van procedures zijn er meer directieve zaken in de taal gesloten. Maar strikt gesproken zijn procedures geen onderdeel van de 'taal' SQL. SQL is opgezet en bedoeld als een onafhankelijke manier van uitvragen, procedures zijn door leveranciers aan de taal toegevoegd om teveel dataverkeer tussen applicatie en database te voorkomen. Hier is in de praktijk echter vaak misbruik van gemaakt door het verplaatsen van zuivere applicatie verantwoordelijkheden naar de database. Dit heeft meer dan eens geleid tot het gevreesde 'vendor lock-in'.

Maar zuiver gesproken is SQL geen taal.

"Maar zuiver gesproken is SQL geen taal."

Jack, is er niet nog een dooie duitser die hier wat over geschreven heeft ?

SQL is zeker wel een taal, maar of het echt een programmeertaal is... :-)

Ik programmeer nauwelijks meer, maar als ik wat schrijf is het SQL, heerlijk want functionele taal. Je beschrijft welke uitkomst je wilt hebben in plaats van het imperatieve waarin je zegt wat de computer moet doen.

Iemand al een vertaling van de L in de afkorting SQL gedaan? Prachtig dat Dino rammelt op de deur van Jack en Henri toegeeft dat hij niet meer weet waar de Q en S voor staan in de afkorting want de gesloten vraagstellingen zijn voor een woordkunstaar als een vrije interpretatie van de uitkomst. Cryptisch als altijd gaat het niet om de dode Duitser die ooit eens wat geschreven heeft maar de context waarin hij het geschreven heeft, 5 mei vieren we nog altijd het aantal dooie Duitsers. Of om precies te zijn het aantal foute Duitsers want de tijd leerde dat niet iedereen een stramme rechterarm had. Foute denkbeelden kent in de taal van Jack geen grijs middenveld. Henri probeert een balletje op te gooien met zijn reactie over uitkkomsten maar hij krijgt het balletje recht tussen zijn ogen, wat is namelijk het doel waarop we richten?

@Dino

I stand corrected, SQL is een taal in de zin dat het iets is waarmee je de informatie opvraagt. Mijn fout om het geen taal te noemen.

Maar ik hoop dat je het ermee eens bent dat het in het lijstje van programmeertalen als C, C++, Java, Cobol, etc. niet thuishoort.

"Bijvoorbeeld voor Arduino-achtige projecten, vaak gerelateerd aan iot"

Dit is een voorbeeld van niet weten waar je over praat.
De Arduino is in 2004 bedacht als een kleine single-board computer met een bijbehorende IDE.
Het bordje had een USB-aansluiting en een ingebouwde bootloader voor het programmeren.
De taal waarin je hem moest programmeren heet C++, assembler kent de IDE niet en dat zou ook zijn doel voorbij schieten, want de Arduino was bedoeld voor mensen met weinig programmeerervaring.
Internet of things was nog toekomstmuziek en voor de Arduino onbereikbaar, want daarvoor heb je een TCP/IP stack nodig en die paste niet op het 8-bit computertje met 32k programmageheugen.

@CPT
Je had ook één reactie boven de eerste van jou kunnen kijken, daar leg ik uit wat het verschil is tussen de databasetaal SQL en de volwaardige talen PL/SQL en Transact-SQL.

Oudlid, je opmerkingen zijn niet eens off topic als we in de evolutie van programmeertalen een beweging zien van formele – logische, wiskundige en imperatieve – kunsttalen naar natuurlijke taal.

In tegenstelling tot derde generatietalen (3GL) en vierde generatietalen (4GL) zijn vijfde generatie talen veel sneller te leren omdat deze niet meer gericht zijn op wiskunde en logica, maar op natuurlijke taal.

Een eenvoudig overzicht:
3GL: HOW. Procedureel en datagedreven. Python, Java, etc.
4GL: WHAT. Declaratief. Database vraagtalen (SQL)
5GL: WHY. Declaratief en doelgedreven. DT (Decision Tables)

Tot op zekere hoogte sluit ik aan bij de visie van prof. Jan Vanthienen (KU Leuven):
https://dmcommunity.org/challenge/challenge-june-2021/

SQL kan gezien worden als een wiskundige specificatie van het gewenste resultaat en kan daarmee een zuivere 4GL worden genoemd (gericht op het wat, niet op het hoe). Mijns inziens is het vooral interessant om SQL steeds minder op te nemen binnen 3GL-talen (ofwel het embedden van SQL in procedurele talen) of aan te vullen met andere 3GL-constructies (bijv. PL/SQL) en steeds meer op te nemen binnen 5GL-talen.

Een fraaie challenge om dit aan te tonen is:
https://dmcommunity.org/challenge/challenge-oct-2016/
waar een oplossing met SQL nog steeds ontbreekt
(ofwel: wie gaat deze uitdaging aan)!

---------------------------------------------------------------------------------------------------------------------------------
Je opmerkingen over de grootste denker ooit zijn bepaald ongemakkelijk;
hier laat ik liever de meest relevante hedendaagse filosoof aan het woord:
https://www.trouw.nl/nieuws/heidegger-de-antisemiet-met-het-grote-licht~b70636d8/

Als we de toeslagenaffaire bij de belastingdienst echter plaatsen in de categorie “misdaden tegen de menselijkheid” gaat het niet om de vraag hoe fout Heidegger was in oorlogstijd, maar hoe fout het technocratische neoliberalisme is in “vredestijd”.

@Jack, volledig met je eens. SQL moet je aan Transact-SQL overlaten voor wat betreft SQL-Server. Niet vanaf een API-host e.d. en al helemaal nooit vanaf een user interface.

Forth was trouwens de eerste natural language programming language, zij het dat ere weinig functies te bedenken waren voor woorden als 'de', 'het' en 'een'. Maar ook zinsconstructies daarmee had je prima kunnen bedienen.

Door een of andere annonce (waarschijnlijk in Computable) was ik aanwezig bij de oprichtingsbijeenkomst van UX-NL op het Mathematisch Centrum in Amsterdam. Voor de aanmelding had ik om de een of andere reden Andrew Tanenbaum aan de lijn. Ik begon natuurlijk onmiddellijk over Forth en hij zei: "Ik heb mijn halve leven al in Assembly geprogrammeerd en ik ga dat de komende helft zeker niet nog eens doen".

Achteraf in mijn ogen onzin. In Forth programmeren is volkomen transparant met de taal uitbreiden en is aan geen enkel abstractieniveau gebonden. Integendeel, je ontkwam er niet aan om abstractieniveau op abstractieniveau te stapelen zoals je dat in een natuurlijke taal ook doet.

Voorlopig gaan we lekker door in Transact-SQL. Wat een heerlijke taal is dat. Voordat je met Forth in je eentje weer op dat niveau bent, is iedereen al dood en begraven. Tenzij je bij Adobe gaat werken wellicht. Volgens mij hebben die praktisch alles op basis van een eigen doorontwikkeling van Forth, in ieder geval PostScript als je dat van binnen beziet.

Jack,
Doe je een filosofische drogredenering van tu quoque? Tijd en (fout) Zijn kent uiteraard een context omdat we niet met hedendaagse moraal kunnen oordelen over denkbeelden in het verleden maar wat als deze rijmen met het heden?

Kom, kom Jack het 'zijnshistorisch antisemitisme' blijft HOE mooi je het filosofisch ook verpakt een moreel verwerpelijk denken. Mark Twain stelde daarom ooit dat de geschiedenis zich niet herhaalt maar dat deze wel rijmt omdat de HOE achter de uitkomst vaak niet goed onderzocht is.

Een 'gekunstelde' taal van beeldspraak heeft geen duizend woorden nodig voor het binaire gevoel van goed en fout. Volgens mij maak je namelijk een foutje in de vertaling als het gaat om misdaden tegen de mensheid en menselijkheid door een historisch-culturele referentie naar een suggestief gevoel.

Goed dat je refereert naar toeslagen-affaire want vergeet niet dat opdracht hiertoe vanuit het volk kwam toen bleek dat er op grote schaal gefraudeerd werd, niet iedereen is slachtoffer. Willen we meer of minder (Bulgaren)fraude want het nieuwe leiderschap lijkt erg veel op het oude.

Zo te horen zijn die 4e en 5e gen talen makkelijk te leren, alleen moet je gekunstelde prijsvragen uitschrijven om iets te vinden dat je ermee kunt oplossen :-)

@Dino
Zo te lezen heb jij geen flauw idee wat 4e en 5e generatie programmeertalen zijn.

Rob, wat een gave reactie; wat je stelt is computer nostalgie van de bovenste plank!

Zelf programmeerde ik in Z80-assembler, Basic en Forth op een TRS80 model 1 en dat was één van de redenen om in 1983 na mijn militaire diensttijd Informatica te gaan studeren in Groningen (HIO).

Gestructureerd programmeren werd vooral onderwezen met Pascal en pseudocode maar mijn interesse voor de taal Forth bleef op de achtergrond steeds aanwezig. Nog steeds heb ik “Flitsend Forth” van Alan Winfield (met een oranje FORTH-79 Overzichtkaart) in mijn boekenkast.

En hoofdstuk 7 van mijn afstudeerscriptie in 1988 had de titel “Een kennisbeschrijvende taal in FORTH”. Maar in het voorwoord van deze scriptie had ik al afscheid genomen van deze taal.

Terwijl ik in het vierde jaar van de opleiding een expertsysteem maakte in Forth, toen nog met losse als-dan regels in plaats van beslissingstabellen, volgde ik ook het vak Vertalerbouw, onder andere aan de hand van het gelijknamige boek van Alblas (en anderen). Vanwege mijn eigen interesse schafte ik daarnaast het mooi compacte “Compilerbouw” aan van Nicklaus Wirth, de bedenker van talen als Pascal en Modula. Dit handzame boekje lijkt mij overigens een bewerking en vertaling te zijn van hoofdstuk 5 van zijn eerder verschenen bekende boek “Algorithms + Data Structures = Programs”.

Hoewel Forth beslist compilerende (codegenererende) eigenschappen heeft, vond ik de toepassingsmogelijkheden van deze taal voor Vertalerbouw uiteindelijk toch te beperkt. Ik overwoog hiervoor destijds de overstap naar de programmeertaal C, maar heb dat verder nooit doorgezet.

Inmiddels ben ik enkele jaren geleden wel overgestapt naar Python en heb daar geen seconde spijt van gehad. Maar Forth is in de jaren 80 beslist een bron van inspiratie geweest!

De link die je legt tussen Forth en natural language onderschrijf ik volkomen.

“Forth is zeer geschikt voor het maken van een taal, toegespitst op een bepaald onderwerp.
Op zijn best lijkt een Forthprogramma uiteindelijk op een normale zin.”
“Het is ongetwijfeld de meest flexibele en kneedbare programmeertaal die er bestaat.”
https://www.hcc.nl/algemeen/2981-flexibel-programmeren-in-forth

“… omdat bij een goede programmeerstijl zonder variabelen de data verborgen blijft, beschouwen sommige programmeurs Forth als een object-georiënteerde programmeertaal avant la lettre. “
https://nl.wikipedia.org/wiki/Forth_(programmeertaal)

Je moet mij natuurlijk niet vertellen dat je Transact-SQL een heerlijke taal vind, want dan ga ik je een oplossing vragen voor die eerder genoemde challenge :-)

Weet zo niet welke challenge je bedoelt, Jack. Wellicht mijn fout. Harvard Softworks heeft indertijd ook nog FOO (Fort Object Orientation Tools) uitgebracht. Daar heb ik toen niets mee gedaan. Ik gebruikte Forth voor een Eprom-progammer (later nog uitgebreid van 2K (2702 naar 8K (2708)) voor de Brother Centronics typemachine interface die we ontwikkeld hadden en verder voor native export van data uit vroege versies van Exact (met een random access file structuur) voornamelijk naar Dbase 3/4 en Clipper.

Hoor graag meer over die challenge. Transact-SQL kan alles :-)
mvgRob

Rob, even naar boven scrollen:
https://dmcommunity.org/challenge/challenge-oct-2016/
waar een oplossing met SQL nog steeds ontbreekt
(ofwel: wie gaat deze uitdaging aan)!


@Jack:
Enkele jaren later was Compilerbouw van Wirth het standaardwerk op de opleiding...

Het probleem van jouw link:
https://dmcommunity.org/challenge/challenge-oct-2016/

is goed oplosbaar in Transact-SQL middels loops en cursoren en "SELECT (TOP x) * FROM table WHERE whatever ORDER BY status / miles" (eventueel via een hulptabel of decode). En ook in Transact-SQL is er geen plek voor Tom, daar verandert een taal niks aan.

Transact-SQL kan alles, nl 3GL constructies :-) https://en.wikipedia.org/wiki/Transact-SQL

@Frank, vergeet de Window Functions niet (https://www.sqlservercentral.com/articles/understanding-the-over-clause). En eventueel een WITH voor de UPDATE. (WITH common_table_expression). Je moet dan met ROW_Number minderen in de PARTITION_BY uitsluiten en erbinnen Capacity met 1 verlagen en uitsluiten als ie 0 gelopen is. Status Flight en SortOrder Passenger is beide statisch. Met de Window Functions kun je nog van alles binnen ieder element van een SET-based ResultSet.

@Rob
Met WITH (een query als pseudotabel) en window functions kom je al een heel eind. Ik gebruik van de window functions vooral de ranking, maar er kan veel meer mee. Je kunt er min of meer de GROUP BY mee vervangen (niet helemaal, je groepeert niet dus verliest geen regels), maar het kan ook in combinatie met (OVER komt na GROUP BY). Het lukt dan ongetwijfeld zonder programmeertaalstructuren zoals loops, maar vanwege de leesbaarheid zou ik daar waarschijnlijk toch voor kiezen.

@Frank, eens met betrekking tot dit geval (als praktijkgeval, niet als challenge). Het probleem is dat je steeds uit moet sluiten wat je al behandeld hebt bij iedere iteratie en dat alles wat je al behandeld hebt ook nog op andere manieren leidt tot een nieuwe situatie. Dat is typisch wat voor Window Functions omdat die allerlei Clause onderdelen steeds per item in de resultset opnieuw uitvoeren.

Wat denken jullie, komt basic onder dos van microsoft ook weer terug?

@Jan
Nee, die rotte basis-Basic met regelnummers komt niet meer terug, maar wie weet komt GFA Basic ooit wel terug:
https://en.wikipedia.org/wiki/GFA_BASIC

@Frank, bedankt voor de link, leuk. Was bedoeld als grapje . . .
Wellicht krijgen we nog een virtuele S36 met RPG II.

Ik denk dat ze daar in de virtualisatie-omgevingen van IBM nog honderden in Nederland van hebben draaien, Jan. Of inmiddels in allerlei Docker instances, wellicht?

@Jan, Rob:
https://www.rs-online.com/designspark/my-raspberry-pi-thinks-it-s-a-mainframe

Voor een paar euro kun je "mainframpje" spelen!

Uw reactie

LET OP: U bent niet ingelogd. U kunt als gast reageren maar dan wordt uw reactie pas zichtbaar na goedkeuring door de redactie. Om uw reactie direct geplaatst te krijgen moet u eerst rechtsboven inloggen of u registreren

Vul uw naam in
Vult u een geldig e-mailadres in
Vult u een reactie in
Jaarbeurs b.v. gaat zorgvuldig en veilig om met uw persoonsgegevens. Meer informatie over hoe we omgaan met je data lees je in het privacybeleid
Als u een reactie wilt plaatsen moet u akkoord gaan met de voorwaarden
Nieuwsbrief

Wil je dagelijks op de hoogte gehouden worden van het laatste ict-nieuws, trends en ontwikkelingen? Abonneer je dan op onze gratis nieuwsbrief.

Vul een geldig e-mailadres in

Stuur dit artikel door

Uw naam ontbreekt
Uw e-mailadres ontbreekt
De naam van de ontvanger ontbreekt
Het e-mailadres van de ontvanger ontbreekt

×
×
article 2021-06-18T11:56:00.000Z William Visterin