De pros en cons van back-end programmeertalen bij de Nederlandse Overheid - comments

Discussie naar aanleiding van het artikel De pros en cons van back-end programmeertalen bij de Nederlandse Overheid - Developer Overheid

En wat is de discussie? D’r is geen one-size-fits-all, zoals het artikel ook zegt. Daar ben ik het mee eens. Ik denk zelfs dat er per project / dienst / oplossing meerdere talen van toepassing kunnen zijn, omdat elke taal z’n (haar?) eigen nukken en dynamiek en features kent. Niet elke taal is even goed voor elk doel. Ik heb niet het idee dat we hier nu echt een discussie over kunnen voeren?

Of mis ik iets? (wat heel goed mogelijk is, want ik weet maar 0.001 % van alles wat er te weten valt … of waarschijnlijk nog minder :grin: )

Hey Marc, met discussie bedoelde ik niet een flame war over welke programmeertaal het beste is (zoals je die wel eens vaker voorbij ziet komen), maar juist zoals jij zegt: wat zijn de sterktes en zwaktes van talen, wanneer gebruik je nou wat, en wat is een daarin een beetje de consensus van de community. Dit met het oog op dat bovenstaand artikel is bedoeld als een soort overzichtspagina voor developers die in een project moeten kiezen waarmee ze aan de slag gaan - en als voorbeeld voor hoe we dit soort artikelen op developer.overheid.nl door middel van of in combinatie met discussie hier zo bruikbaar mogelijk kunnen maken.

Nice. Mee eens dat het zinnig om daar over te posten … hoewel het ook echt wel moeilijk is om tot enkele antwoorden te komen. Dit soort keuzes zijn zo afhankelijk van de context waarin je je bevindt!

Easy means something that’s achieved without effort. Simple means something that’s uncomplicated and easily understood. But it cannot be achieved without effort.

Het kan gemakkelijk (easy) zijn om een taal te kiezen die je kent. Of die het team kent. En dat kan ook echt waarde hebben in het kader van continuïteit en brede ondersteuning door het hele team. Tegelijk kan gemakkelijk (easy) niet per se de meest eenvoudige (simple) keuze zijn. Bovenstaande quote heb ik ergens van Medium gevist … maar werd mij vooral duidelijk door de founder van Clojure … wat misschien wel een eenvoudige oplossing / taal is … maar voor mij zeker niet gemakkelijk :grin: Tja …

Ik denk dat de keuze voor een programmeertaal als eerste bepaald wordt door de technische context en vervolgens door de organisatorische context.

Wat is je doel platform? Browser? Hm… JavaScript … of JavaScript transpiler talen, zoals TypeScript, ClojureScript, CoffeeScript, 'whatever’Script …
Kubernetes en containers? Hm… Dan maakt het veel minder uit …

Organisatorische context gaat veel meer over welke kennis is beschikbaar in het team? Welke kennis is beschikbaar in de community waarin het speelt? Wat is een veelgebruikte taal (of framework)? Hoe lang gaat het project mee moeten kunnen? Is dan een (te) nieuwe taal wel zo verstandig? Of juist heel plausibel?

“Organisatorische context gaat veel meer over welke kennis is beschikbaar in het team? Welke kennis is beschikbaar in de community waarin het speelt? Wat is een veelgebruikte taal (of framework)? Hoe lang gaat het project mee moeten kunnen? Is dan een (te) nieuwe taal wel zo verstandig? Of juist heel plausibel?”

Voor mijn gevoel zou er tussen de (developers binnen de) verschillende publieke organisaties veel meer het gevoel moeten bestaan dat dit één community is - dat is natuurlijk het hele idee achter Code for NL, al sinds het begin. Daarmee samen hangt een streven naar convergentie in ways of working en stacks, met natuurlijk wel altijd de door jou genoemde “tool for the job” in het achterhoofd. Maar (meer) eenheid zorgt voor herbruikbaarheid, maar misschien nog wel belangrijker: het beter kunnen bestuderen van andermans oplossingen, daar feedback op geven, aan meewerken, etc. Oftewel: lagere drempels voor samenwerking tussen “de overheid”.

@jgroenen om in te gaan op je hoofdvraag. Wanneer gebruik je nou welke taal? Ik zie dat er tegenwoordig veel moderne strictly typed talen zijn die enorm veel developersgemak bieden (Go etc.). Daarom denk ik dat het op termijn ook vaak voor de developer zelf fijn is om te merken wat zo’n taal voor je kan doen.

Een bezwaar die ik zelf zie bij Node is de slechte onderhoudbaarheid. Ik heb als developer die is begonnen als front-ender veel met JavaScript/Node gewerkt. Echter zie je dat het aantal packages heel snel oploopt en je al heel snel in een “Dependency hell” terecht komt. Je pakt iets na een jaar of twee van de plank en de boel updaten is op dat moment erg moeilijk door breaking changes etc.

Conclusie: als back-end taal zou ik daarom altijd een taal kiezen die specifiek als back-end taal bedoelt is. En het liefst dan een taal met een eco-systeem dat jouw aansluit op jouw wensen.

Een front-end project zou ik qua dependencies zo “simpel” (precies zoals @marcvanandel het omschrijft) mogelijk houden. Dit vanwege eerder genoemde “Dependency hell”. Het is heel makkelijk om het React moeras in te lopen en allerlei dependencies te installeren. Echter kom je wanneer het project ouder wordt al snel op een punt waarop twee geïnstalleerde dependencies allebei een andere versie van weer een derde dependency nodig hebben. Op dat moment is er veel inspanning vereist om de situatie te fixen. Begon dit vooral in te zien door gesprekken met @hugo.