Programmeertalen: een toekomstgerichte set

Een IT-afdeling met een historie van decennia draagt onvermijdelijk ballast met zich mee. Gedurende deze lange tijd zijn applicaties gebouwd en is infrastructuur ingericht in uiteenlopende programmeertalen. Het vraagt nogal wat om voor al die omgevingen voldoende expertise voorhanden te hebben.

Daarnaast zijn er veelbelovende nieuwe ontwikkelingen. Niet meedoen lijkt geen optie. Wat doe je daarmee in je rol als CIO of CTO?

De afweging die je als CIO/ CTO maakt is een andere afweging dan die van een ontwikkelteam, een programmeur of zelfs een architect. Naast de technische overwegingen zijn er overwegingen met een zakelijk of strategisch aspect.

Ontwikkelomgevingen en programmeertalen vormen voor ontwikkelaars de context waarin zij hun werkzame leven voor een aanzienlijk deel doorbrengen. Ze doen een grote investering in tijd en inspanning in die context. Die kennis is hun kapitaal. Niet zelden vormt het ook een deel van hun identiteit.
Het idee om de variëteit te beteugelen door met bepaalde talen en omgevingen te stoppen kan gemakkkelijk op weerstand kan stuiten. Het is al snel alsof je iemand zijn speeltje afpakt.

Speeltje...? Omgekeerd is ook juist veel enthousiasme voor nieuwe ontwikkelingen te verwachten. Veel ontwikkelaars worden geïnspireerd door nieuwe technologie, door te proberen, door te spelen. Wat overigens niet zonder risico is, de belofte dat ze 'het het wel even zullen doen' hangt in de lucht. In navolging van Frederick P. Brooks: alle ontwikkelaars zijn optimisten.

Talen of omgevingen?

In enge zin gaat het om de mogelijkheden van een programmeertaal. In brede zin is er om een taal heen een ecosysteem van libraries, ontwikkelomgevingen, beschikbare expertise, internetfora en ontsluiting van kennis via AI-systemen. De keuze behelst zowel de programmeertaal als het ecosysteem.

Old code never dies

Nieuw of oud an sich is geen argument. Stokoud werkt nog steeds, is bewezen en alle fouten zijn er inmiddels wel uitgehaald. In de meteorologie is Fortran nog steeds dominant. In de financiële wereld mogen organisaties - De Belastingdienst, banken - zich afvragen of ze COBOL wel echt willen afschaffen. Als het zo moeilijk blijkt om een alternatief te bouwen, dan is het oude wellicht erg degelijk.

Hoe kan dat? Ten eerste door 'de zeef'. Waarom zijn in de klassieke muziek al die composities uit vorige eeuwen zo geniaal? Survivor bias. De mindere composities zijn allang uit ons geheugen verdwenen. Alleen de topselectie is overgebleven.

Verder, uit eigen observatie, ontwikkelen in die oude omgevingen was moeilijk. Het type programmeur dat daarin paste was analytisch zeer intelligent, taai en consciëntieus. De IT-afdeling in die tijd was de spreekwoordelijke ivoren toren met een bijbehorende onaantastbare status. (En nogal eens ook een dosis bijbehorende arrogantie, waar we later overigens nog lang last van hebben gehad, maar dat terzijde.)

Het waarom van een taal

Nieuwe talen verschijnen bij de vleet, wat vaak vergezeld gaat met een aanzienlijke hype. Maar lang niet alles wordt succesvol. Voorbij de hype sukkelt een groot deel in slakkentempo voort. Terugkijkend, was het een must om over te stappen van Java naar Scala, van - iets anders - naar Ruby on Rails? Scala, de gedoodverfde opvolger van het zogenaamd achterhaalde Java. Ruby on rails, een taal om gemakkelijk en snel websites in te bouwen. Het is tamelijk stil geworden op dat spoor.

Wat gaat een nieuwe taal toevoegen, welk probleem wordt er opgelost? Slechts een net wat andere syntax, een paar handige features extra, is onvoldoende fundament voor duurzaam succes. Een nieuwe taal of omgeving begint op braakliggend terrein, er zijn nog geen libraries, geen boeken, geen experts en geen succesvolle implementaties. Er is langere tijd interesse nodig wil zo'n taal van de grond komen.

De propositie voor een taal, de raison d'être biedt een beeld van de potentie. Vaak is die heel inzichtgevend. Java: write once, run everywhere. Fortran: wiskunde, academisch rekenen. Julia: hoge performance, consistentie, voor data science. COBOL: voor business vraagstukken.

Het zijn andere overwegingen dan de argumenten van de programmeur die Java niet blieft omdat het geen 'printf' kent, een JIT compiler heeft en liever bij C++ blijft.

De keuze voor een programmeertaal heeft consequenties die zich uitstrekken tot op strategisch niveau. Het stelt eisen aan medewerkers, bij werving en opleiding. Het bepaalt de mogelijk te leveren prestatie, op aspecten als kosten, flexibiliteit en schaalbaarheid. Bovendien wordt de keuze gefixeerd in de gerealiseerde applicaties, die een levenscyclus hebben van minimaal tien jaar. Het onderhoud dat in die periode, noodzakelijk in die taal en omgeving plaatsvindt overstijgt in kosten doorgaans de initiële investering.
Omgekeerd, oude applicaties en de beslissingen uit het verleden kunnen een IT-afdeling in het heden volkomen klem zetten.

Voor menig organisatie die gewoon is haar gebouwen te huren (leasen), is de horizon voor het digitaal onroerend goed minstens zo lang als die van 'de bakstenen'. Toch halen deze keuzes in weinig directiekamers de agenda. Het is bij uitstek het domein van de CIO/CTO. Qua benodigde technische expertise is dat begrijpelijk. De consequenties voor de organisatie echter, in algemene business en strategische termen, zouden wel aandacht mogen hebben.

Een nieuwe taal en omgeving

In welke omgeving ga je investeren met een nieuw project? Voor een enterprise applicatie gaat het over een budget van vaak een aantal miljoenen en een lange tijdshorizon. Je wilt niet geforceerd worden tot een overstap en volledige herbouw. Het platform waar je voor kiest moet continuïteit bieden en zich blijven ontwikkelen.
Maar hoe kom je daar, zonder glazen bol, achter? Er is wel een aantal aspecten te beschouwen om tot een onderbouwde keuze te komen.

Het eigenaarschap?

• proprietary. De taal is onderdeel van een applicatie of platform van een leverancier.
• proprietary. De taal is een zelfstandig product van een leverancier.
• beslissingen over de taal worden genomen door een onafhankelijke entiteit
• er zijn meerdere aanbieders

Kortom: met wie ga je in zee?

Proprietary

Is een leverancier eigenaar dan is een vendor lock in onvermijdelijk. Dat geldt in sterke mate voor scripttalen die deel uitmaken van een applicatie. Code die je schrijft voor SAP of Salesforce gaat niet langer mee dan het gebruik van de applicatie in de organisatie.
Onderhandelen bij de aankoop wordt wel gezien als remedie voor die afhankelijkheid, maar biedt slechts beperkt soelaas. Het is bijvoorbeeld erg moeilijk te specificeren wat toekomstige ontwikkeling en support moet inhouden.
De staat van dienst van de leverancier geeft wel een indicatie. Hoe is het gesteld met loyaliteit naar klanten, prijsvorming, doorontwikkeling, marktpositie, etc?
Wat blijft is het risico op een overname. De volgende eigenaar kan een investeringsmaatschappij zijn of een concurrent die het product van de markt wil nemen.

De uitzondering waar menig organisatie zich wel 'aan uitlevert' is Microsoft. Kies je voor Microsoft dan verbind je je lot aan de ondernemingsstrategie van dat bedrijf. Een 'Microsoft tenzij'-beleid is geen beleid maar capitulatie.

Foundation

Voor veel talen is een stichting in het leven geroepen. Soms komt het initiatief vanuit een commerciële leverancier, die gebruikers meer zekerheid wil bieden of zelf meer baat heeft bij een industriestandaard dan een beperkte gesloten oplossing. Het kan ook een gemeenschap zijn van organisaties en individuen die belang hebben bij de technologie, zonder dat er sprake is van een duidelijk leidende partij. De figuur van een stichting an sich betekent nog weinig. Bepalend is hoe deze bestuurd wordt, de belanghebbenden betrokken zijn en het beleid en besluitvoming (de governance) zijn geregeld. Dat vergt een klein onderzoek.

Bij Rust wordt de governance expliciet op de website geadresseerd.

In kringen van filmmakers bestaat een gevleugelde uitspraak: 'If you don't have the rights, you don't have the film'. Ook voor de IT-sector is deze bijzonder relevant. Immers, wat is je code waard als je niet weet of je het op een platform mag of kunt draaien?

Open source software

Open source is een business model, idealisme, hobbyisme, een freemium model en abandonware. Vaak is het een van deze, soms enkele, of het is alles tegelijk. Soms ook is het alleen marketing zonder inhoud. Veel programmeertalen vallen onder een open source licentie. Overigens worden de open source licenties - er zijn veel varianten - kwalitatief beoordeeld door de Open Source Initiative.

Open source heeft waarde als er aan twee condities is voldaan. Er is een actieve, betrokken gemeenschap en de activiteiten van die gemeenschap zijn georganiseerd. Daartoe is een structuur nodig, bijvoorbeeld in de vorm van een stichting, met goed beleid en bestuur. Is dat er niet, dan is het open source 'in name only'.

Soms is er een geestelijk vader (of moeder, maar ik ken zogauw geen voorbeelden) die aan het roer staat. Voorbeelden zijn Linus Thorvalds voor Linux en Guido van Rossum voor Python. De cultuur in zo'n gemeenschap varieert van 'corporate' tot die van een bevlogen piratenclub die de wereld wil veroveren. Een stichting met een grote staat van dienst is de Apache Software Foundation, waar een aantal goede producten in is ondergebracht.

Abandonware, tot slot, is een praktijk met kwalijke trekjes. Door een pakket open source te maken komt een leverancier, schijnbaar idealistisch, van verplichtingen en verwachtingen af.
(Wikipedia abandonware).

Open source floreert als het gevoed wordt vanuit de gemeenschap van gebruikers. Daar hoort wederkerigheid bij. Je wordt toch geen free rider? Hoe gaat je organisatie een bijdrage leveren? Dat kan in vele vormen: ontwikkeling, het melden en oplossen van bugs, een donatie, sprekers op een congres, promotie etc.

Een interessante studie is: Javier Cánovas (2019): Livable Software - Governance strategies in Programming Languages – Who decides what gets in the language?
Naast eigenaarschap en governance zijn er natuurlijk nog andere overwegingen hoe een taal in een organisatie past.

Overdraagbaarheid

Sommige talen lenen zich prima om snel wat in elkaar te 'hacken'. De ontwikkelaar van het initiële product kan scoren met zijn prestatie. Maar dat is 'leuk voor even'. De ellende begint in productie en het onderhoud aan de code.
Code moet overdraagbaar zijn. De taal speelt daarin een rol. Zo kenmerkt Python zich bijvoorbeeld door een goede object oriëntatie, consistentie en daardoor leesbaarheid.

Overwegingen

Robuustheid

Een taal wordt robuust wanneer aan zaken die mis kunnen gaan aandacht is besteed en daar maatregelen voor zijn genomen. Bijvoorbeeld door een juist gebruik af te dwingen en een goede foutafhandeling te verplichten.

Betrouwbaarheid

De taal maakt onderdeel uit van een breder ecosysteem. Ook voor die grotere omgeving is het van belang hoe de kwaliteit is geborgd. Een library bijvoorbeeld, die in een applicatie wordt opgenomen moet functioneel correct zijn en moet vrij zijn van malware. Dat geldt voor de huidge versie en voor toekomstige versies, die wellicht zelfs automatisch worden geïnstalleerd.

• De herkomnst: waar komen de componenten vandaan?
• De functionele juistheid: is die zelf te controleren en/ of hoe is die geborgd?
• Is de component vrij van malware?

Hoe met dit thema wordt omgegaan loopt sterk per domein en omgeving uiteen.

Green computing

Computers verbruiken energie. De ene programmeertaal is veel sneller dan de andere. Er kunnen bijvoorbeeld veel meer gebruikers op één server. De keuze voor de taal en omgevingen maakt een verschil. Een high performance taal is efficienter en uiteindelijk zuiniger. Dit zijn talen die code compileren en alle cores van een processor weten te gebruiken: Java, C#, Julia, RUST, Erlang, Fortran, Swift, C++.

De arbeidsmarkt

Erlang heeft een aantal interessante eigenschappen. Maar Erlang-ontwikkelaars vinden??? Ik vrees dat het niet te doen is. De taal is ook nog eens lastig om aan te leren, opleiden wordt ook een kostbare aangelegenheid. De arbeidsmarkt is hier een beperkende, zoniet blokkerende factor.
De markt voor ontwikkelaars is krap, het is een kandidatenmarkt. Een ontwikkelaar wil niet blijven hangen in een oude omgeving met weinig toekomst. Dat is niet handig voor het CV, de volgende opdracht of job.

In het aanbod en niveau van ontwikkelaars zijn clusters te onderkennen. Een taal en een ontwikkelomgeving met een taaie steile leercurve aan het begin en abstracte concepten trekt mensen met een sterk analytisch vermogen, die in staat zijn de omgeving te doorgronden en er hun voordeel mee te doen. Een scripttaal, waar je snel mee op weg bent, maar die ook grenzen heeft, spreekt typisch een ander type ontwikkelaar aan.

Twee voorbeelden.
- Een Java omgeving heeft concepten en frameworks die je pas gaat waarderen bij grote projecten, waar schaalbaarheid en cyber security van belang zijn.
- PHP is meer een beginnerstaal. Minder gedoe, oneerbiedig gezegd: 'lekker knutselen'.

Door de keuze voor een taal worden ook andere aspecten van de ontwikkelorganisatie ingekleurd.

Wat opvalt bij de research voor dit artikel is dat ook de oude talen zich blijven moderniseren. Zelfs Perl en Fortran bieden ondersteuning voor object oriented programmeren. De vraag is of ze achteraan de kar hangen of zich opnieuw weten uit te vinden. Daarin zijn verschillende voorbeelden. Al dan niet onder druk van het opkomende Scala heeft Java stevige slagen gemaakt is en is nu up to date. Maar er zijn ook omgevingen die nieuwe features deels implementeren zonder dat er sprake lijkt te zijn van een bewuste richting. Daar zou je een verwijt kunnen leggen naar Perl en PHP.

Een samenhangend IT-landschap

Wat te doen met de oude talen en omgevingen? Er is geen keus dan naar een samenhangend beknopt gamma toe te werken. Een gefragmenteerd landschap is niet te managen en de kosten zijn niet te dragen. Soms moet dat geleidelijk omdat oude applicaties voorlopig nog een realiteit zullen blijven. Daarnaast zijn er nieuwe keuzes te maken. Naast de criteria die al genoemd zijn is het van belang om algemene trends in de overwegingen te betrekken.
Een aantal trends als voorbeeld:

• Cyber security is een grote zorg. Talen moeten faciliteiten bieden om uiterst robuust te ontwikkelen.
• Talen zonder geheugenmanagement - zoals C++) worden als achterhaald beschouwd. (Behalve voor zeer specifieke toepassingen.)
• Plezier, het kunnen werken in een aangename omgeving zal verder toenemen in belang. Dat geldt zowel op individueel als op teamniveau.
• De eerste generatie talen uit het internettijdperk begint oud te worden. Sommige zullen verdwijnen, andere zal het lukken om een generationele sprong te maken.

Waar kom je dan op uit? Dat is onmogelijk in algemene zin te formuleren. Iedere situatie is anders. Is er een twintigtal goede Perl-ontwikkelaars in huis, dan zul je die omgeving eerder koesteren dan afbouwen.

• Overal en altijd, client side web: HTML, CSS, Javascript.
• Voor enterprise applicaties, web sites etc: Java, C#
• Voor data science: Julia, R
• Voor kleine programma's, websites, scripts: Python
  
  
• Voor low level programming: RUST
• Voor liefhebbers: Erlang, Fortran, Swift
• Te exploreren nieuwkomers: Kotlin, Go.
  
  
• Niet meer voor nieuwbouw: Visual Basic, Perl, COBOL, C++, Ruby on Rails, PHP.