Waarom Kotlin geweldig is, maar je toch bij Java blijft

Ongeacht tot welke groep je behoort, er is een reden waarom je bij Java. En ik verwijt je niets. Het heeft misschien wel het meest ontwikkelde, universele en complete ecosysteem in de hele wereld. onderneming wereld. De taal heeft een mooi afgestemde set mogelijkheden, ergens in de juiste zone tussen te veel en te weinig. En nieuwe mogelijkheden worden langzaam maar gestaag toegevoegd, waardoor de taal grotendeels up-to-date blijft met nieuwere trends in de programmeerwereld.

Weet je Lombok hoewel? Als je dat niet doet, raad ik je aan het te proberen. Als je het leuk vindt, dan heb ik iets voor je om te proberen. Een geheel nieuwe taal, die door zijn eigenschappen Lombok overbodig maakt. Hij heet Kotlin.

Kotlin? Bedoel je de Android taal?

Kotlin op Android werd gezegend door Google zelf tot het punt dat het de de facto voorkeurstaal voor het platform is geworden. Dit is niet waar ik me in dit artikel op zal richten, maar Android is inderdaad de plek waar ik Kotlin voor het eerst ontmoette.

Mijn collega op het werk was een app aan het ontwikkelen voor een toen actuele projectin zijn eentje. Deadlines naderden echter snel, dus werd ik gedelegeerd om hem te helpen ze te halen. Ik ga nu even terug in de tijd naar dat moment. Aaen... YUCK! Waarom gebruikt hij een rare taal die klinkt als een ketchup merk!? Het ziet er verschrikkelijk uit!

Waarom staat er "fun" voor elke functie? Alsof ik nog niet weet wat het is. Ik heb ook al leuk met Java hoe dan ook. En waar is het terugkeertype? Aan het einde? Ben je gek? Wat is dat, wijs je iets toe aan een functie? Het slaat nergens op! Het ziet er allemaal uit als Java met extra stappen! Wacht, waar is de klasse waartoe deze methode behoort? Waar heb je het verstopt jij ketchup-klinkende, Java imitatie-excuus van een programmeertaal? Oh nee. Oh nee, dat deed je niet. IS DAT EEN GLOBALE FUNCTIE? Dat is het, ik ben klaar, ik bel de politie.

Spoiler alert: ik heb de politie niet gebeld. Of ik het nu leuk vond of niet, ik moest mijn Java-gerichte denkwijze aanpassen aan een andere taal. Maar zo erg zal het toch niet zijn? Het is nog steeds een JVM-taal, het is gewoon een andere Java. Misschien zelfs met wat coole extra functies? Met tegenzin begon ik aan het project te werken.

Java met extra stappen

Als Java zo geweldig is, waarom is er dan geen Java 2? Grapjes terzijde, dat is wat ik bij mezelf dacht. Ik doe net alsof Kotlin Java 2 is. Nieuwe syntaxis en zo, maar ik hoef er alleen maar genoeg van te leren om het project af te maken. Tjongejonge, wat had ik het mis.

Nadat ik het een dag of twee had geprobeerd, realiseerde ik me al snel dat zowel Kotlin als Java zijn niet zo elastisch. Proberen ze naar elkaar toe te buigen eindigt onvermijdelijk met het doormidden breken van een van de twee. Het werd duidelijk dat Kotlin een ding op zich is, en het feit dat het werkt op een JVM betekent bijna niets vanuit het oogpunt van een programmeur. (Terzijde, het kan ook transporteren naar JavaScriptof worden gecompileerd naar een native binair bestand).

Plan B dan. Leer de taal eigenlijk kennen. Als je de documenten voor het eerst leest, lopen de rillingen over de rug van een doorgewinterde Java-programmeur. Bijvoorbeeld:
- eerder genoemde top-level aka globale context
- parameter- en functieretourtypes gespecificeerd aan het einde

fun som(a: Int, b: Int): Int {
   return a + b
}

het functiegedeelte kan een uitdrukking zijn (met behulp van gelijkheidsteken)

 fun som(a: Int, b: Int) = a + b

if-instructie kan een resultaat geven

 val y = if (x == 1) {
 "one"
 } else if (x == 2) {
 "twee"
 } else {
 "other"
 }

Ok, ik moet er gewoon aan wennen. Gewoon een andere syntax. Wat heb je nog meer te bieden, meneer Kotlin?

waarde?.methode() // uitvoeren indien niet null

Oh ok, het wegwerken van als (waarde == nul)een punt voor jou. Wat heb je nog meer?

fun check(list: List, alternative: Boolean) = wanneer {
 list is LinkedList -> print("linked")
 alternatief -> print("alternatief")
 list.size > 50 -> print("big")
 anders -> print("ander")
 }

Hmm leuk, kan handig zijn om te vermijden als iemand anders blokkeert, maar het lijkt nog steeds een gimmick.

 object SingularObject: Teller() {
 var a = 14
 fun test() = als (a > 10) "meer" anders "minder"
 }

Ok, die ziet er echt nuttig uit, ik vind het leuk! Aan de andere kant kan ik in Java ook een singleton maken. Misschien zal het niet zo elegant zijn, maar het is niet echt nieuw. Heb je nog azen in je mouw? Zoals echte zwaargewichten?

 var s: String = null // compileert niet, niet-null type

Wacht... wat?

De miljardenfout

Stel je een codebase voor waar je je geen zorgen hoeft te maken over null safety. Stel je voor dat je het gewoon voor lief neemt dat elke referentie daadwerkelijk iets zinvols bevat. Stel je voor dat je er zeker van bent dat elk null-gerelateerd probleem van tevoren is opgelost.
Stel je niets meer voor. Alle referenties in Kotlin zijn standaard niet nullable. Als je ze nullable wilt maken, moet je bewust die beslissing nemen, en expliciet vermeld het in de code:

 var s: String? = null

Ik begrijp dat je op dit moment misschien sceptisch bent over het hele idee. Je bent gewend aan nullable referenties. Je houdt het in je achterhoofd tijdens het coderen. Je hebt geleerd waar je voorzichtig moet zijn. Precies mijn gedachten. Komende van JavaHet voelde eerst inderdaad raar. Zo van, wat is het nut? Het zal niet op magische wijze alle gerelateerde problemen laten verdwijnen. Ik moet gewoon overal "?" toevoegen, klinkt als een klus.

Maar ik besloot toch om diep in de taal te duiken? Laten we het op jouw manier doen meneer Kotlin. Ik begon me in te spannen om zoveel mogelijk nulvariabelen, velden en parameters te elimineren. Stap voor stap leerde ik om taalfuncties te gebruiken die het makkelijker maakten om nullable referenties te elimineren, zoals de safe call "?." operator, de elvis "?:" operator, gedelegeerde eigenschappen, de "let" methode en meer.

Naarmate de tijd verstreek, kreeg ik het voor elkaar om sommige klassen alleen niet-null velden en methode parameters te laten bevatten. In principe wist ik dat als een klasse succesvol geïnstantieerd was, ik de nullabiliteit in methode bodies bijna kon vergeten. Het was een zaligheid. Na verloop van tijd ging ik dit steeds meer waarderen. Maar uiteindelijk zag ik het niet als een killer feature, Java voelde nog steeds als thuis. Totdat...

De terugkomst

Het project naderde het einde. Ik leerde Kotlin steeds beter kennen en met deze kennis werd de code steeds netter, leesbaarder en beknopter. Je kon de verbeteringen met het blote oog zien in de commit geschiedenis. Maar nu is het eindelijk zover. Met onverwacht dierbare herinneringen aan de nieuwe taal, was het tijd om afscheid te nemen en terug te gaan naar de zoete comfortzone van Java. Of dat dacht ik toch.

Ken je dat gevoel dat je iets begint te waarderen op het moment dat het weg is? Wanneer je je niet realiseert hoezeer je op iets vertrouwt totdat je het niet meer kunt gebruiken? Het was het allerbeste voorbeeld van dat gevoel dat ik waarschijnlijk ooit in mijn leven heb ervaren.

Toen ik terugging naar het schrijven van de code in JavaIk schrok bijna van het gebrek aan sommige functies. Het was alsof mijn hersenen onbewust, ten onrechte Kotlin functies achteraf in Java inbouwden. Ik heb situaties meegemaakt waarin ik iets begon te implementeren, om me vervolgens te realiseren dat het niet zou werken in deze taal. In het beste geval zou ik het Kotlin-achtig kunnen schrijven, maar het zou omvangrijk, onleesbaar en/of te veel boilerplate vereisen.

Null safety was natuurlijk de functie die ik het meest miste. Maar ik was verrast door hoeveel kleinere dingen voor mij vanzelfsprekend werden: parameters met naam, eigenschappen in plaats van getters en setters, "==" als gelijken en "===" als referentiële gelijkheid, gekwalificeerd "this", uitbreidingsfuncties, impliciete enkelvoudige lambda parameter, "_" voor ongebruikte lambda parameters, data klassen, scope functies, andere Kotlin stdlib functies, operatoren en nog veel meer. En de manier waarop het allemaal mooi in elkaar past. Ter vergelijking, Java voelde... primitief.

Het voelde zelfs zo slecht dat ik begon te overwegen om helemaal over te stappen op Kotlin. Theoretisch is het volledig interoperabel met Java, je kunt gewoon Kotlin-ondersteuning toevoegen aan een bestaand project en beginnen met het schrijven van nieuwe klassen. Kotlin weet hoe het met Java moet "praten" en Java weet niet eens dat het met een andere taal "praat". En na de compilatie naar bytecode maakt het voor de JVM niet echt veel uit.

Realiteitscheck

Dus waar wacht je nog op? Als de taal zo goed is als je zegt, gebruik hem dan gewoon! Maar misschien niet in bestaande projecten, ik weet dat het interoperabel moet zijn, maar twee verschillende talen op deze manier mengen klinkt lelijk.

Oké, dus voor nieuwe modules: Kotlin. Of toch niet? Je werkt in een team. Je moet ze raadplegen en overtuigen van de grootsheid van deze nieuwe taal. Wat? Vinden ze het niet leuk? Het klinkt alsof ze gewoon geen moeite willen doen om het te leren. Je kunt het ze niet kwalijk nemen, jij was in het begin ook sceptisch.

De projectmanager! Ja! Hij zal zeker begrijpen welke grote waarde Kotlin voor ons team heeft. Oh, de grootsheid die zal komen!
-Geen
-Wacht, waarom?
-Het team weet het niet.
-Ze zullen het leren!
-Ze willen niet leren.
-Je kunt ze maken!
-Ze hoeven niet te leren.
-Ik bedoel, dat is waar, maar denk eens aan de mogelijkheden!
-Ja, denk eerst eens na over de problemen.

De legende zegt dat er een project bestaat. Een project dat groot en complex is, maar in elk onderdeel mooi geschreven. Een project waar alle ontwikkelaars het eens zijn over gebruikte oplossingen. Waar nieuwe functionaliteiten gewoon vloeiend van de toetsenborden van de programmeurs komen. Waar bugs zeldzaam en eenvoudig te verhelpen zijn.

Heb je ooit zo'n project gezien? Ik niet. Sommige kwamen in de buurt, maar de meeste zijn een grote puinhoop van legacy code. En als ze dat niet zijn, worden ze dat waarschijnlijk op een gegeven moment in de toekomst. Stel je nu eens voor dat je een andere taal in de mix gooit. Het introduceert nieuwe manieren om fouten te maken. Het vereist dat ontwikkelaars weten wat ze doen. Het is op zijn zachtst gezegd een risico.

Denk ook aan de rotatie van ontwikkelaars. Mensen komen en gaan. Wil je elke nieuwe ontwikkelaar een hele nieuwe taal laten leren? Nee, dat is contraproductief. Wil je überhaupt Kotlin-ontwikkelaars aannemen? Veel succes daarmee, een goede Java-ontwikkelaar aannemen is al moeilijk genoeg.

Mensen hebben het geprobeerd. Ik moet zeggen dat ik het niet eens ben met de meeste aantijgingen in dat artikel. Er staat wat steekhoudende kritiek in, maar ik denk dat ze Kotlin niet genoeg hebben gebruikt om "de Kotlin manier" echt te begrijpen. Veel commentaren onder dat artikel lijken er net zo over te denken.

Dat maakt echter niet uit. Ik wed dat dit in jouw project ook zou gebeuren. "Probeerde het, vond het niet leuk". Je zorgt er niet voor dat ze er meer tijd aan besteden. Je zorgt er niet voor dat ze het opnieuw proberen. Je zorgt er niet voor dat ze het nog een kans geven. En vanuit praktisch oogpunt hebben ze misschien wel gelijk. Java is gewoon zo populair, dat het overbodig lijkt om iets anders op de JVM te gebruiken.

Waarom dan dit artikel?

Je hebt zojuist een aanzienlijke hoeveelheid tijd besteed aan het schrijven van een artikel dat geen punt lijkt te hebben. Waarom zou ik proberen een taal te leren, als jij zegt dat het toch zinloos is?

Nou, ik denk niet dat het zinloos is. Ik denk nog steeds dat Kotlin geweldig is. Ik wil het nog steeds gebruiken (en dat doe ik ook voor mijn privéprojecten). Als het kon, zou ik er gewoon op overstappen en de beperkingen van Java vergeten. Maar de huidige realiteit zegt dat ik dat niet kan. En ik wil proberen dat te veranderen.

Mijn bedoeling voor jou, beste lezer, is om op zijn minst de mogelijkheid te overwegen om uit de gezellige Java-comfortzone te komen. Want misschien, heel misschien, ga je net zoveel van Kotlin houden als ik. En als dat zo is, dan is dat weer een ontwikkelaar met Kotlin-kennis op de markt.

Lees meer:

Het beste type projecten voor Java

3 veelvoorkomende uitdagingen bij de ontwikkeling van softwareproducten voor starters

De juiste manier om de beste Java-ontwikkelaars te vinden