Dev Summit 2026 met Adele Carpenter: 'Java sucks, maar hoeft niet weg'

Java vraagt vaak veel code, kan behoorlijk stroef aanvoelen en null ligt altijd op de loer. Toch draaien banken, verzekeraars en talloze andere organisaties nog altijd op de programmeertaal. Tijdens de Tweakers Developers Summit laat software-engineer Adele Carpenter zien waar de bekende ergernissen vandaan komen. En waarom C#-developers zich daar best een beetje zelfvoldaan over mogen voelen.

Via een omweg naar softwareontwikkeling

Adele Carpenter kwam niet via de gebruikelijke route in de softwareontwikkeling terecht. Toen ze tien jaar geleden naar Nederland verhuisde, bezat ze diploma's in civiele techniek en handelswetenschappen, maar wist ze nog weinig van software. Ze solliciteerde bij Trifork Amsterdam op een functie in sales en marketing rond de GOTO-conferenties en bijbehorende trainingen.
"Tijdens mijn sollicitatie moesten ze me uitleggen wat opensourcesoftware was. En toch namen ze me aan."Dat sollicitatiegesprek verliep anders dan dat van de gemiddelde toekomstige developer. "Tijdens mijn sollicitatie moesten ze me uitleggen wat opensourcesoftware was. En toch namen ze me aan."

Via de conferenties ontmoette Carpenter dagelijks ontwikkelaars die enthousiast vertelden over programmeertalen en de systemen waaraan ze werkten. Die wereld trok haar steeds meer. Ze wilde begrijpen waarover zij spraken en uiteindelijk zelf op zo'n podium staan.
"Ik dacht: dit is de plek waar ik wil zijn. Ik ga leren programmeren en op een dag sta ik zelf op dat podium."

Carpenter overtuigde de directeur van Trifork ervan dat ze tijdens haar werk mocht leren programmeren. Ze verdeelde haar tijd tussen marketing en code en vroeg na ongeveer een jaar om een plek in een klantproject. Sinds 2019 werkt ze als software-engineer; eind 2021 stond ze voor het eerst als spreker op een conferentie.
Tegenwoordig combineert ze ontwikkeling met advieswerk bij klanten en gebruikt ze onder meer Java, Kotlin, Spring, React, JavaScript en TypeScript. Trifork bouwt complexe maatwerksoftware, waaronder digitale toets- en examenomgevingen voor het onderwijs. Daarbij gaat het om systemen die op drukke momenten probleemloos beschikbaar moeten zijn en lang worden onderhouden. Dan telt niet alleen hoe prettig een taal programmeert, maar vooral of de software betrouwbaar en voorspelbaar blijft draaien.

Java afkraken uit liefde

De titel van Carpenters talk laat weinig ruimte voor subtiliteit: Java Sucks (So C# Didn't Have To). Toch is de sessie geen afrekening met de taal waarmee ze haar geld verdient. De provocatie komt juist voort uit haar waardering voor Java én haar ontmoetingen met developers uit de Microsoft-wereld.

Op conferenties met veel C#-developers hoorde Carpenter regelmatig dat Java hopeloos verouderd was. Sommigen hadden de taal voor het laatst tijdens hun studie gebruikt, vaak in de jaren negentig. Hun oordeel stond nog altijd vast: Java 1.2 was vervelend, dus Java moest wel een slechte taal zijn.

In de praktijk worden Java en C# allebei gebruikt voor bedrijfskritische systemen. Het zijn volwassen talen met omvangrijke ecosystemen en gemeenschappen vol kennis en ervaring. Voor organisaties is de keuze tussen beide daarom meestal minder dramatisch dan developers doen voorkomen.

Toch plagen de kampen elkaar graag. "Er bestaat nog steeds behoorlijk wat hokjesdenken. Dan denk ik: zien jullie niet dat we in wezen allemaal hetzelfde doen?"

Carpenter gebruikt die rivaliteit om te laten zien hoe programmeertalen van elkaar leren. De makers van C# konden voortbouwen op keuzes die bij Java goed of juist minder goed uitpakten. Java nam later weer ideeën over uit nieuwere talen. Zo veranderen talen stap voor stap, terwijl ze eerdere beslissingen soms tientallen jaren meedragen.

Waarom Java niet vervangen hoeft te worden

Java bestaat inmiddels ruim dertig jaar en bevat keuzes die met de kennis van nu waarschijnlijk anders zouden worden gemaakt. Carpenter ziet dat niet als reden om de taal af te schrijven. "Ik denk niet dat Java vervangen hoeft te worden. Je moet de taal nemen zoals hij is, met alle wratten erbij."
Sommige eigenschappen die Java ouderwets laten aanvoelen, maken de taal juist"Ik denk niet dat Java vervangen hoeft te worden. Je moet de taal nemen zoals hij is, met alle wratten erbij." aantrekkelijk voor grote organisaties. Java is stabiel, beschikt over veel frameworks, bibliotheken en hulpmiddelen en draait via de Java Virtual Machine op verschillende besturingssystemen.

Daar komt de sterke achterwaartse compatibiliteit bij. Nieuwe versies moeten bestaande software zo min mogelijk beschadigen. Daardoor blijft soms oude ballast behouden, maar hebben organisaties doorgaans een duidelijk upgradepad en hoeven ze hun systemen niet bij iedere update te herbouwen. Carpenters team werkt inmiddels met Java 25 en ondervindt bij upgrades weinig problemen: veel bestaande code blijft gewoon werken. Voor toepassingen die twintig jaar of langer meegaan, weegt die zekerheid vaak zwaarder dan een compactere of elegantere schrijfwijze.

Generics, lambdas en verdwenen type-informatie

De tekortkomingen van Java krijgen in Carpenters talk volop aandacht. Checked exceptions zijn bijvoorbeeld lastig te combineren met lambdas: "Je kunt ze combineren, maar daarvoor heb je extra code nodig, bijvoorbeeld om een functionele interface te implementeren." Ook de manier waarop Java generics heeft ingevoerd, werkt nog dagelijks door in moderne code.

C# bood al vroeg de mogelijkheid om functies via delegates door te geven. Daardoor voelt functioneel programmeren in C# vaak natuurlijker. Java kreeg later eveneens lambdas en andere functionele mogelijkheden, maar die sluiten niet overal soepel aan op oudere onderdelen van de taal.

Kotlin voelt op dat vlak volgens Carpenter natuurlijker. Doordat Kotlin en Java binnen dezelfde JVM-omgeving samenwerken, kunnen teams per probleem kiezen voor een meer objectgerichte of juist functionele oplossing zonder hun bestaande Java-ecosysteem achter te laten. Bovendien ondersteunt Java functioneel programmeren met elke nieuwe versie steeds beter.

Een veelbesproken verschil is de manier waarop beide talen met generics omgaan. C# bewaart tijdens het uitvoeren informatie over het concrete type. De software kan daardoor onderzoeken met welk type zij werkt. Java past daarentegen type erasure toe: na het compileren is een groot deel van die informatie niet meer rechtstreeks beschikbaar. Dat beperkt bepaalde vormen van inspectie tijdens runtime en dwingt developers soms tot omwegen.

C#-ontwikkelaars kijken daar graag hoofdschuddend naar. Carpenter: "Dan vragen ze hoe we in vredesnaam kunnen overleven in die donkere middeleeuwen zonder reified generics. Maar weet je? Java-developers redden zich prima." Als je bijvoorbeeld met een bibliotheek als Jackson data deserialiseert naar Java-objecten, moet je het verwachte type expliciet als parameter meegeven. Dat lukt mede dankzij vaste programmeerpatronen, bibliotheken en de kennis die in dertig jaar rond Java is opgebouwd. Niet iedere oplossing is elegant, maar een taal staat nooit los van het gereedschap en de gemeenschap eromheen.

Ook een programmeertaal is een softwareproject

De makers van Java beschikten in de jaren negentig over andere hardware, eisen en inzichten dan taalontwerpers nu. Een keuze die toen verstandig was, kan tientallen jaren later onhandig uitpakken. Door de nadruk op achterwaartse compatibiliteit zijn zulke beslissingen bovendien moeilijk terug te draaien.
Carpenter vergelijkt kritiek op een vreemde taalconstructie met een klant die vraagt waarom een ogenschijnlijk eenvoudige functie niet morgen kan worden opgeleverd. Een developer weet dat achter zo'n verzoek afhankelijkheden, beveiligingseisen, tests en architectuurkeuzes schuilgaan.

"De mensen die aan Java werken, verschillen daarin niet van jou en mij. Zij werken alleen aan een ander soort systeem. Ze hebben net zo diep over hun problemen nagedacht en kennen technische beperkingen waarvan wij niet allemaal op de hoogte zijn."

Een ongelukkige eigenschap is dus niet automatisch het resultaat van slecht denkwerk. Een wijziging kan gevolgen hebben voor de compiler, de JVM, frameworks en enorme hoeveelheden bestaande code. Soms beschermt een compromis miljoenen toepassingen. Soms blijkt pas jaren later dat een keuze minder goed heeft uitgepakt. Een programmeertaal is uiteindelijk zelf een langlopend softwareproject.

Engels als nieuwe programmeertaal

Terwijl haar talk terugkijkt op dertig jaar taalontwikkeling, verandert Carpenters eigen manier van programmeren snel door AI. Tijdens een workshop bouwde ze met Claude Code een kleine chatdienst in Go, een taal die niet tot haar gebruikelijke gereedschap behoort. "Mijn agent heeft hem voor me in Go gebouwd. Zelf houd ik me meestal bij de talen waarmee ik mijn geld verdien."

"Mijn belangrijkste programmeertaal is op dit moment Engels. Dat is behoorlijk wennen."Dat roept een ongemakkelijke vraag op: voelt ze zich prettig bij productiecode waarvan ze niet iedere regel zelf heeft geschreven of uit haar hoofd kent? Ze begrijpt wat de software doet, maar kent niet automatisch elk detail van de gegenereerde code. Daar is ze naar eigen zeggen nog niet helemaal uit.

Tegelijkertijd krijgt ze meer gedaan. De nadruk verschuift van iedere regel zelf typen naar vooraf nadenken over ontwerp, architectuur en grenzen. Een programmeeragent heeft duidelijke instructies en structuur nodig. Zonder die sturing kan hij snel veel code produceren die het verkeerde probleem oplost. De snelheid van de agent neemt de verantwoordelijkheid voor review, tests en de uiteindelijke productiecode niet weg.

"Mijn belangrijkste programmeertaal is op dit moment Engels. Dat is behoorlijk wennen." Carpenter schrijft nog altijd graag code, maar haalt de meeste voldoening uit toepassingen die nuttig zijn en problemen voor gebruikers oplossen.

Een verhaal in plaats van een feitenlijst

Ervaring met Java of C# is niet nodig om Carpenters talk te volgen. De geschiedenis van Java vormt een herkenbaar voorbeeld van de afwegingen achter langlopende softwareprojecten. Dezelfde vragen spelen bij frameworks en platformen die jarenlang worden onderhouden: wat verander je, wat laat je staan en hoeveel bestaande gebruikers mag een verbetering raken? Java-developers krijgen mogelijk hernieuwde waardering voor hun taal. C#-developers mogen zich van Carpenter nog iets zelfvoldaner voelen.

Haar uitnodiging voor de Tweakers Developers Summit is eenvoudig: "Wil je iets leren over de geschiedenis van software, begrijpen hoe projecten zich door de jaren heen ontwikkelen of gewoon lachen ten koste van Java? Kom dan vooral langs."

Dev Summit 2026: Koop nu je kaartje voor de Tweakers Dev Summit 2026 en verdiep je in het complete programma!

Hou je ook zoveel van – of haat je vurig op Java? Dan mag je deze talk van Adele natuurlijk niet missen. Koop dan hier een kaartje. De stapel overgebleven kaartjes slinkt met de dag (geen grap!), dus wacht niet heel lang meer als je erbij wilt zijn. Meer informatie over het programma, workshops en de andere sprekers vind je op de aparte Dev Summit-website. We zien je heel graag in Utrecht!

Reacties (27)

[Wolfos]

De vergelijking met C# is incompleet zonder het .NET Core project te noemen. Microsoft heeft flink in C# geïnvesteerd met eigenlijk een volledige herimplementatie van C# en het hele ecosysteem eromheen.
Daar plukken we nu de vruchten van. C# is snel, cross-platform en modern terwijl Java nog altijd voortborduurt op dezelfde 30 jaar oude basis en een beetje achterblijft.

[Gropah]

Ik vind het persoonlijk wel meevallen hoe erg java achterblijft? Het heeft een tijdje stil gestaan (vooral tussen 7 en 11), maar de laatste tijd zijn er veel goede toevoegingen en verbeteringen geweest. Oracle kijkt goed naar andere talen, wat daar goed werkt en waar developers blij van worden. Dingen als records en pattern matching en (wat minder recent) de switch als expression kunnen gebruiken. En ook de JDK word nog steeds beter, met dingen als compact object headers (waardoor RAM verbruik verkleint, met alle gevolgen van dien) en de garbage collector is ook flink verbeterd.

Ik word persoonlijk iets blijer van kotlin (ja, ik ben een programmeur die JVM talen gebruikt ), maar het is niet alsof java echt een kriem is om mee te werken. En uit deze survey van Jetbrains lijkt hetzelfde te komen.

[Reactie gewijzigd door Gropah op 23 oktober 2026 09:00]

[Mars Warrior]

Het punt is alleen dat heel veel Java-code 5 tot 10 jaar geleden is gebouwd. Die hebben dus nog steeds de mega overhead van Java, en dat verander je niet eventjes.

In het verleden zijn wij overgestapt van Java naar Javascript en dat scheelde bij sommige projecten een factor 4 in kosten. De Java-ontwikkelaars hadden ook een veel lager uurtarief omdat ze tov Javascript ontzettend veel code moesten bouwen om dezelfde functionaliteit te bouwen.

Met de huidige Java-taal is dat verschil een heel stuk kleiner geworden. Maar dat doet niks met de bestaande grote systemen: die kosten nog steeds heel veel qua onderhoud.

Daarbij hebben we ook nog eens veel plezier gehad van full-stack developers: het maakt niet meer uit waar de code draait, server- of clientside. Met sommige stacks is dat ook niet relevant meer.

Dus ja. In veel gevallen blijft Java bestaan als backend, maar zijn er in andere talen (vaak Javascript/Typescript) interfaces omheen gebouwd die fijn communiceren met de frontends.

[Gropah]

Aan de andere kant kun je nu wellicht stellen dat door AI, java wellicht een voordeel is omdat het erg gestructureerd is, en er enorm veel code beschikbaar is waardoor AI er goed op getraind is.

Het punt is; elk taal heeft zijn plek en zijn voor- (en na)delen en heel veel hangt af van context. Als je iets maakt wat veel met netwerken en filesystems doet of in een klein team aan iets werkt dan is het waarschijnlijk handiger om een taal te pakken die goed async kan doen zoals javascript. Als je met een klein team zit, is het misschien beter om iets te pakken zodat iedereen aan alles kan zitten zoals javascript of kotlin. Als je een veel dingen van te voren wil afvangen, dan is een gecompileerde taal waarschijnlijk handiger terwijl dat waarschijnlijk weer onhandig is als je veel dynamische JSONs binnen krijgt. Als je shit super snel en low latency moet zijn, dan kun je waarschijnlijk beter in rust of c++ bezig gaan. Als je nu wat opzet pak je wellicht kotlin, waar je ongeveer 10 jaar geleden ruby (on rails) pakte, en 20 jaar geleden java of c#.

[Reactie gewijzigd door Gropah op 23 oktober 2026 17:24]

[Kerfuffle]

Ik heb met C# en Java gewerkt en vond C# niet sneller dan Java. De reden dat ik met C# ben gestopt is dat iedere nieuwe .NET versie een 180 leek te doen op wat best practices (met name in ASP.NET) waren, terwijl Java in een iets lager tempo consequent beter werd.

Ook de Microsoft community hielp niet mee overigens; supportforums stonden typisch vol met posts met vragen over obscure foutmeldingen waar niemand op reageerde.

Ik greep wel terug op .NET core voor serverless omdat dat betere coldstarts had dan Java (en Spring). De JVM garbage collector en JIT-compiler waren daar debet aan. Maar dat is tegenwoordig door JIT- en AOT-optimalisatie wel verbeterd.

Tbh voel je in modern Java vooral het voordeel van z'n legacy.

[The Zep Man]

Daar komt de sterke achterwaartse compatibiliteit bij. Nieuwe versies moeten bestaande software zo min mogelijk beschadigen. Daardoor blijft soms oude ballast behouden, maar hebben organisaties doorgaans een duidelijk upgradepad en hoeven ze hun systemen niet bij iedere update te herbouwen. Carpenters team werkt inmiddels met Java 25 en ondervindt bij upgrades weinig problemen:

Ondertussen lees ik over horrorverhalen waarbij met veel moeite een organisatie een upgrade van Java 6 naar 8 uitvoert en daar zo'n beetje blijft hangen omdat de upgrade naar 11 pijn kan doen. Zie ook de staat van Java-installaties aan het begin van 2025. Het moet fijn zijn om tijdig voldoende middelen te krijgen om upgrades goed te testen en door te voeren.

[Reactie gewijzigd door The Zep Man op 23 oktober 2026 08:33]

[Gropah]

Volgens mij is voor 8 naar 11 voor veel enterprises een groot probleem (geweest) omdat er nogal wat breaking changes in zaten rondom java EE/jakarta. Ik heb zelf een aantal van die migraties gedaan. In het begin was het zeker even ploeteren, maar als je openrewrite gebruikt ben je er al snel. Sindsdien zijn er ook nog een paar dingen waar je rekening mee moet houden met upgraden, maar is het over het algemeen relatief makkelijk geweest.

[Hardfreak]

6 naar 8 en 8 naar 11 waren inderdaad wel vrij heftig, maar de upgrades naar de volgende LTS versies waren steeds minder en minder pijnlijk. Het grootste pijnpunt zit hem tegenwoordig vooral in speciale libraries zoals Lombok of andere libraries die heel diepgaande introspectie doen en zelf bytecode gaan beginnen injecteren at compile time.

Ook frameworks zoals Spring Boot en Quarkus moet je vaak mee upgraden naar de volgende major voor ondersteuning van de nieuwe Java versie. Daar zit je dan vaker met breaking changes, maar die komen soms ook gewoon voort uit veranderingen en deprecation van standaarden en libraries. Op die manier blijf je ook wel een beetje mee met de tijd.

Het is en blijft nog altijd een hoop werk, maar vaak is de JDK niet meer het grootste pijnpunt. Als je tijdens de lifecycle van je applicatie ervoor zorgt dat je je dependencies geregeld update, dan zou de migratie niet zo pijnlijk meer mogen zijn.

En just for fun and giggles, ik heb onlangs nog een java 8 desktop applicatie weten starten met java 25. Het enige probleem waar ik tegenaan liep was dat die een interne SSL class niet meer vond, maar die applicatie is dan ook blijven steken op TLS1.

[pclin]

Weer zo’n presentatie over hoe achterhaald Java zou zijn, terwijl Java 25 flink is verbeterd sinds Java 8, dat inmiddels twaalf jaar oud is.

Dan wordt het feit dat sommige organisaties al die jaren niet zijn meegegaan met nieuwe Java-versies ineens gebruikt als bewijs dat Java moeilijk te onderhouden is. En in de introductie komt ook nog voorbij dat Java 1.2 vervelend was, dus dat Java wel een slechte taal moet zijn.

Jammer dat het weer zo’n talk is. Er staan er al zoveel op internet: “Java is dead” roepen om aandacht te trekken. De argumenten zeggen vooral iets over organisaties die zelf zijn blijven stilstaan.

Ik ben ook al 27 jaar Java ontwikkelaar en de code die ik nu schrijf lijkt niet op de code van in het begin. Ja, zoals bij alles in software ontwikkeling. 'It depends!'

[RichieB]

Lees eens het hele artikel. Dit is dus juist niet een "Java is dead" talk, maar ze legt uit waarom Java gewoon blijft bestaan naast alle andere talen.

[Reactie gewijzigd door RichieB op 23 oktober 2026 11:44]

[Tubby]

true, maar punt blijft wel dat mensen graag bashen tegen Java. Zelf ben ik op mijn opleiding begonnen met Java en toen (2000) dacht ik niet dat je hiermee daadwerkelijk applicaties wilde bouwen, het was best pijnlijk allemaal.

Maar tig Java versies verder is de taal en het ecosysteem enorm volwassen geworden, Maven, Spring en Hibernate hebben hier veel in gedaan. Maar mooier is om te zien dat meerdere ideeen / concepten kunnen groeien in het ecosysteem en dat de betere varianten overleven

ondertiteling, ik ben na mijn studie als Java ontwikkelaar aan de slag gegaan in web-applicaties. Dus ondertussen ook wel een jaartje of 23 under my belt

[Reactie gewijzigd door Tubby op 23 oktober 2026 09:45]

[bzzzt]

Ik zat rond 2000 op een opleiding waar C++ de standaard was. Toen kwam Java net op en moet zeggen dat ik het eigenlijk best een verademing vond: code draaide misschien iets minder optimaal maar vergeleken met C++ kreeg je een behoorlijk uitvoerige standaardlibrary en een taal die minder focus legde op technische noodzakelijkheden als geheugenbeheer. Juist voor 'business' applicaties is het fijn dat de logica in code eenvoudig te doorzien is.

[pclin]

Dat is ook waar veel ‘Java is dead’-talks op internet over gaan: provoceren om views te trekken. De boodschap is vervolgens vaak juist waarom Java nog steeds bestaat.

Mijn reactie ging niet over de inhoud van de talk, maar over de woordkeuze en de manier waarop het artikel is geschreven. De titel en formulering zijn duidelijk bedoeld om aandacht te trekken en mensen naar de conferentie te krijgen. Dat is begrijpelijk, maar het blijft wel een nogal bekende aanpak.

[Vexxon]

"Mijn belangrijkste programmeertaal is op dit moment Engels. Dat is behoorlijk wennen."

Dit besef ik mij ook steeds meer en meer en daar baal ik best wel van soms.
De issue is vooral jongere collega's die alleen maar Engels spreken maar niet meer de programmeertaal die gebruikt wordt. "Het moet af" betekent tegenwoordig, laat AI maar genereren, als het werkt is het goed we hoeven niet te begrijpen wat we zelf opleveren. We bouwen dus niet alleen technical debt op maar ook cognitive debt.
Een bug in productie wordt weer opgelost door AI, ik denk dat veel bedrijven de deksel op de neus gaan krijgen over een aantal jaar wanneer de code niet meer te onderhouden is door mensen en ze totaal afhankelijk zijn van AI.

[Reactie gewijzigd door Vexxon op 23 oktober 2026 08:31]

[Piemol]

Nu is AI nog betaalbaar en snappen we een beetje hoe het werkt, dus is dat nu nog geen probleem.

Kan over 5 jaar totaal anders zijn

[Vexxon]

Nu is AI nog betaalbaar en snappen we een beetje hoe het werkt, dus is dat nu nog geen probleem.

Exact, eerst bedrijven afhankelijk maken en dan de kosten omhoogschroeven. In die zin denk ik dat de meer ervaren ontwikkelaars toch een stuk waardevoller gaan zijn in plaats van dat ze uitgefaseerd kunnen gaan worden door AI

[locke960]

Het grootste probleem wat Java heeft is Oracle.
Waarom zou je software van een advocatenkantoor met een IT afdeling gebruiken?

[Tubby]

Gelukkig heb je niets met Oracle van doen als je Java gebruikt. De Java taal en specs zijn open en er zijn open implementaties die ook productiewaardig zijn (ik run zelf bij voorkeur op Eclipse Temurin)

en ja, ik ben ook geen fan van Oracle dus als het niet nodig is loop ik daar graag met een grote boog omheen.

in het hele Java Community Proces spelen ze uiteraard wel een rol, en dat doen ze ook goed imho.

[rneeft]

Voor wie ’m nog niet gezien heeft: YouTube: The Java Story | The Official Documentary is een leuke docu over het ontstaan van Java, de bijna-ondergang en de cadans waar ze tegenwoordig in zitten.

[xorpd]

Het kleine aantal keywords in Java (ten opzichte van C++) is een duidelijk voordeel (less is more). Vooral het afschaffen van unsigned voorkomt veel nare bugs. Ook het feit dat methods standaard virtual zijn maakt het gebruik van OO technieken stukken laagdrempeliger. Reflection maakt het eenvoudig Java modules als plugins te gebruiken.

Er zijn natuurlijk ook nadelen. De garbage collector bijvoorbeeld vreet geheugen en maakt Java ongeschikt voor embedded toepassingen. En het String object heeft teveel overhead.

[divvid]

Diverse keren gestart met java, ongeveer tegelijk met PHP en Perl, maar elke keer kreeg ik niet voor elkaar wat ik wilde. Dingen die simpel waren in en paar regels Perl (nee, niet te vergelijken en eveneens een kl... taal) kostten enorm veel werk (in ons domein) in java. Druk van managers die dingen gedaan wilde krijgen speelde ook mee.

Uiteindelijk gesettled op Python, simpelweg omdat ik nog steeds veel in uitprobeersels en snelle ad hoc code rondhang. (en ook Python is niet heilig). Ook gekeken naar Julia en gebruik dat soms in combinatie met Python

Ik denk dat er uiteindelijk geen enkele taal is die aan alle behoeftes kan voldoen.

Een groot probleem bij Java is dat als je op zoek gaat naar voorbeeld code, je soms in oude structuren beland. AI doet dat iets beter, als is dat ook niet alles. Heeft iemand al het geheugen gebruik genoemd?

[Salvatron]

Wat een onzin dat je de taal moet nemen zoals die is. Als een taal problemen heeft die niet weggenomen kunnen worden is het beter om die taal te vervangen door wat beters. Het zal niet voor niets zijn dat Kotlin is uitgevonden.

[Tubby]

Kotlin bouwt dan gelukkig ook door op de basis van het java ecosysteem. In de loop van de tijd zijn er ook wel een aantal jvm talen geweest (groovy, scala) die uiteindelijk ook hun sporen heb nagelaten in de nieuwere versies van de Java taal

het is juist mooi dat dergelijke initiatieven kunnen ontstaan in groeien in het Java eco systeem. Ik verwacht dat een aantal goede ideeën uit kotlin ook in de standaard Java taal worden geabsorbeerd.

[vrije_vogel]

Java heeft altijd een hoge instap-leercurve gehad. Weerstand tegen Java is sinds het begin van de taal een constante geweest.

Vraagt het veel code? Al sinds mensenheugenis vult de tab-toets aan na de eerste paar letters. Worden methods en properties aangevuld.
Voor die code krijg je veel terug. Veiligheid. Duidelijkheid. Performance.
Een Java omgeving dwingt veel af. Je moet je exceptions netjes afhandelen. Niet alleen de happy flow coderen. Variabelen die niet zijn geïnitialiseerd? Null pointer exception. Of de code compileert niet. Beter je best doen, Sjefke.

Aan het fundament van Java lag een nieuw paradigma ten grondslag. 'The network is the computer'. Dat vroeg iets anders dan voortmodderen met een scripttaal in het internet tijdperk. Write once, run everywhere was een belofte die in het begin leidde tot een magere performance omdat de JVM een nieuw concept was. Maar die is ijzersterk geworden.

Nog zoiets. Voor het deployment van Java kun je kiezen tussen meerdere engines. Er zijn meerdere JVM's van verschillende leveranciers. Als je een enterprise platform gaat opzetten is dat een criterium. Na juist deze week is duidelijk waarom.

[xorpd]

De leercurve van Java is in ieder geval stukken lager dan die van C++. Ik kwam van C (met een paar uitstapjes naar C++) en ik was binnen een dag productief.

Java exceptions ben ik geen fan van, SEH is praktisch waardeloos en om een exception te genereren als een bestand niet bestaat i.p.v. een error terug te geven is een ontwerpfout.

Write once, run everywhere is in de praktijk (server-side Java) niet van belang.

Ik vergeet bijna het belangrijkste: Java staat het embedden van objects niet toe, alleen references zijn toegestaan. Nooit meer die C/C++ twijfel: moet ik een punt of een pijltje gebruiken? C++ bewijst hoe meer keuzes hoe moeilijker de taal.

[Reactie gewijzigd door xorpd op 23 oktober 2026 19:13]