Hvorfor Kotlin er fantastisk, men du bliver alligevel ved med at bruge Java

Uanset hvilken gruppe du tilhører, er der en grund til, at du bliver hos Java. Og jeg bebrejder dig ikke. Det har uden tvivl det mest udviklede, universelle og komplette økosystem i hele verden. virksomhed verden. Sproget har et pænt skræddersyet sæt af muligheder, et sted i den rigtige zone mellem for meget og for lidt. Og der bliver langsomt, men sikkert tilføjet nye funktioner, så det stort set er opdateret med nyere tendenser i programmeringsverdenen.

Kender du til Lombok Men? Hvis du ikke gør, kan jeg varmt anbefale at prøve. Hvis du kan lide det, så har jeg noget, du bare skal prøve. Et helt nyt sprog, som i kraft af sine funktioner gør Lombok overflødigt. Det hedder Kotlin.

Kotlin? Mener du Android-sproget?

Kotlin på Android blev velsignet af Google selv i en sådan grad, at det de facto blev det foretrukne sprog til platformen. Det er ikke det, jeg vil fokusere på i denne artikel, men Android er faktisk det sted, hvor jeg mødte Kotlin for første gang.

Min arbejdskollega var ved at udvikle en app til en dengang aktuel projektpå egen hånd. Deadlines nærmede sig dog hurtigt, så jeg blev uddelegeret til at hjælpe ham med at nå dem. Lad mig nu sætte mig selv tilbage i tiden til det øjeblik. Aaaand ... FUCK! Hvorfor bruger han et underligt sprog, der lyder som en ketchup-mærke!? Det ser forfærdeligt ud!

Hvorfor står der "fun" før hver funktion? Som om jeg ikke allerede ved, hvad det er. Desuden har jeg allerede sjov med Java Nå, men... Og hvor er returtypen? I slutningen? Er du ikke rigtig klog? Hvad er det, tildeler du noget til en funktion? Det giver ingen mening! Det hele ser bare ud som Java med ekstra trin! Vent, hvor er den klasse, som denne metode tilhører? Hvor har du gemt den, din ketchup-lydende, Java imiterende undskyldning for et programmeringssprog? Åh nej, det gjorde du ikke. Åh nej, det gjorde du ikke. ER DET EN GLOBAL FUNKTION? Det var det, jeg er færdig, jeg ringer til politiet.

Spoiler alert: Jeg ringede ikke til politiet. Uanset om jeg kunne lide det eller ej, var jeg nødt til at tilpasse min Java-centrerede tankegang til et andet sprog. Men det er vel ikke så slemt, vel? Det er stadig et JVM-sprog, det er sikkert bare et andet Java. Måske endda med nogle fede ekstrafunktioner? Modstræbende begyndte jeg at arbejde på projektet.

Java med ekstra trin

Hvis Java er så fantastisk, hvorfor findes der så ikke en Java 2? Spøg til side, det var det, jeg tænkte ved mig selv. Jeg vil bare lade, som om Kotlin er Java 2. Ny syntaks og det hele, men jeg skal bare lære nok af det til at afslutte projektet. Hold da op, hvor tog jeg fejl.

Efter at have prøvet det i bare en dag eller to, indså jeg hurtigt, at både Kotlin og Java er ikke så elastiske. Hvis man forsøger at bøje dem mod hinanden, ender det uundgåeligt med, at en af dem knækker midt over. Det blev tydeligt, at Kotlin er en ting for sig selv, og det faktum, at det fungerer på en JVM, betyder næsten ingenting set fra en programmørs synspunkt. (Som en sidebemærkning kan det også transpile til JavaScripteller kompileres til en native binær fil).

Så er det plan B. Lær faktisk sproget at kende. Når man læser dokumenterne for første gang, går der kuldegysninger gennem rygraden på en erfaren Java-programmør. For eksempel:
- tidligere nævnte topniveau aka global kontekst
- parameter- og funktionsreturtyper specificeret i slutningen

fun sum(a: Int, b: Int): Int {
   returnerer a + b
}

Funktionens krop kan være et udtryk (med lighedstegn)

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

if-sætningen kan give et resultat

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

Okay, jeg skal bare vænne mig til det. Bare en anden syntaks. Hvad har du ellers at byde på, hr. Kotlin?

 value?.method() // udfør, hvis ikke null

Åh ok, at slippe af med hvis (værdi == null)Et point til dig. Hvad har du ellers?

fun check(list: List, alternative: Boolean) = when {
 listen er LinkedList -> print("linked")
 alternativ -> print("alternativ")
 list.size > 50 -> print("big")
 else -> print("andet")
 }

Hmm fint, kunne være praktisk at undgå, hvis andre blokerer, virker dog stadig som en gimmick.

 objekt SingularObject: Counter() {
 var a = 14
 fun test() = if (a > 10) "mere" else "mindre"
 }

Ok, den ser faktisk nyttig ud, den kan jeg godt lide! På den anden side kan jeg også lave en singleton i Java. Måske bliver det ikke så elegant, men det er ikke noget nyt. Har du nogen esser i ærmet? Rigtige heavy hitters?

 var s: String = null // kompilerer ikke, ikke-null-type

Vent ... hvad?

Fejlen til en milliard dollars

Forestil dig en kodebase, hvor du ikke behøver at bekymre dig om null-sikkerhed. Forestil dig, at du bare tager det for givet, at hver reference faktisk indeholder noget meningsfuldt. Forestil dig at være sikker på, at alle null-relaterede problemer er håndteret på forhånd.
Forestil dig ikke mere. Alle referencer i Kotlin er ikke nullable som standard. Hvis du vil gøre dem nullable, skal du bevidst træffe den beslutning, og udtrykkeligt angive det i Kode:

 var s: String? = null

Jeg forstår, at du måske er skeptisk over for hele ideen på dette tidspunkt. Du er vant til nullable referencer. Du har det i baghovedet, når du koder. Du har lært, hvor du skal være forsigtig. Det er præcis mine tanker. Jeg kommer fra JavaDet føltes faktisk underligt i starten. Hvad er meningen med det? Det vil ikke på magisk vis få alle relaterede problemer til at forsvinde. Jeg bliver bare nødt til at tilføje "?" overalt, det lyder som en opgave.

Men jeg besluttede mig for at dykke dybt ned i sproget, gjorde jeg ikke? Lad os gøre det på din måde, hr. Kotlin. Jeg begyndte at gøre en indsats for at eliminere så mange nullable variabler, felter og parametre, som jeg kunne. Trin for trin lærte jeg at bruge sprogfunktioner, der gjorde det lettere at fjerne nullable referencer, f.eks. safe call "?."-operatoren, elvis "?:"-operatoren, delegerede egenskaber, "let"-metoden og meget mere.

Som tiden gik, lykkedes det mig at få nogle klasser til kun at indeholde ikke-null-felter og metodeparametre. Dybest set vidste jeg, at hvis en klasse blev instantieret med succes, kunne jeg næsten glemme alt om nullability i metodekroppe. Det var en lyksalighed. Med tiden satte jeg mere og mere pris på det. I sidste ende tænkte jeg dog ikke på det som en killer-funktion, Java Det føltes stadig som et hjem. Indtil...

Comebacket

Projektet nærmede sig sin afslutning. Jeg lærte Kotlin mere og mere at kende, og med denne viden blev koden mere og mere ryddelig, læsbar og kortfattet. Man kunne se forbedringerne med det blotte øje i commit-historikken. Men nu er tiden endelig kommet. Med uventet gode minder om det nye sprog var det tid til at sige farvel og vende tilbage til den søde komfortzone med Java. Det troede jeg i hvert fald.

Kender du den følelse, når du begynder at sætte pris på noget i det øjeblik, det er væk? Når du ikke indser, hvor meget du er afhængig af noget, før du ikke kan bruge det længere? Det var det allerbedste eksempel på den følelse, jeg nok nogensinde har oplevet i mit liv.

Da jeg kom tilbage til at skrive koden i JavaJeg blev næsten skræmt over manglen på nogle funktioner. Det var, som om min hjerne ubevidst og fejlagtigt havde overført Kotlin-funktioner til Java. Jeg oplevede situationer, hvor jeg faktisk gik i gang med at implementere noget for så at indse, at det ikke ville fungere i dette sprog. I bedste fald kunne jeg skrive det Kotlin-agtigt, men det ville være omfangsrigt, ulæseligt og/eller kræve for meget boilerplate.

Null safety var selvfølgelig den funktion, jeg savnede mest. Men jeg blev overrasket over, hvor mange mindre ting, der blev naturlige for mig: navngivne parametre, egenskaber i stedet for getters og setters, "==" som equals og "===" som referentiel lighed, kvalificeret "this", udvidelsesfunktioner, implicit singulær lambda-parameter, "_" for ubrugte lambda-parametre, dataklasser, scope-funktioner, andre Kotlin stdlib-funktioner, operatorer og meget mere. Og den måde, det hele passer sammen på. Til sammenligning føltes Java ... primitivt.

Det føltes faktisk så slemt, at jeg begyndte at overveje helt at skifte til Kotlin. Teoretisk set er det fuldt interoperabelt med Java, man kan bare tilføje Kotlin-understøttelse til et eksisterende projekt og begynde at skrive nye klasser. Kotlin-siden ved, hvordan man "taler" med Java, og Java-siden ved ikke engang, at den "taler" med et andet sprog. Og efter kompilering til bytecode gør det ikke rigtig nogen forskel for JVM'en.

Virkelighedstjek

Så hvad venter du på? Hvis sproget er så godt, som du siger, så brug det! Måske ikke i eksisterende projekter, for jeg ved godt, at det skal være interoperabelt, men at blande to forskellige sprog på denne måde lyder grimt.

Ok, så for nye moduler - Kotlin er det. Eller er det? Du arbejder i et hold. Du er nødt til at rådføre dig med dem og overbevise dem om det nye sprogs storhed. Og hvad så? Kan de ikke lide det? Det lyder, som om de bare ikke vil gøre en indsats for at lære det. Det kan du ikke bebrejde dem, for du var også skeptisk i starten.

Projektlederen! Ja, ja! Han vil helt sikkert forstå den store værdi, som Kotlin vil tilføre vores team. Åh, den storhed, der vil komme!
-Nej
-Vent, hvorfor?
-Holdet ved det ikke.
-De skal nok lære det!
-De ønsker ikke at lære.
-Du kan lave dem!
-De har ikke brug for at lære.
-Jeg mener, det er sandt, men tænk på mulighederne!
-Ja, hvad med at tænke på problemerne først.

Legenden siger, at der findes et projekt. Et projekt, der er stort og komplekst, men pænt skrevet i alle dele. Et projekt, hvor alle udviklere er enige om de anvendte løsninger. Hvor nye funktioner bare flyder ud af programmørernes tastaturer. Hvor fejl er sjældne og nemme at rette.

Har du set sådan et projekt? Det har jeg ikke. Nogle kom tæt på, men de fleste af dem er et stort rod af gammel kode. Og hvis de ikke er det, bliver de det nok på et eller andet tidspunkt i fremtiden. Forestil dig nu, at du smider et andet sprog ind i blandingen. Det introducerer nye måder at begå fejl på. Det kræver, at udviklerne ved, hvad de laver. Det er mildest talt en risiko.

Overvej nu også udviklerrotation. Folk kommer og går. Vil du tvinge alle nye udviklere til at lære et helt nyt sprog? Nej, det er kontraproduktivt. Vil du overhovedet ansætte Kotlin-udviklere? Held og lykke med det, det er svært nok at ansætte en god Java-udvikler.

Folk har prøvet. Jeg må sige, at jeg ikke er enig i de fleste af påstandene i den artikel. Der er en del gyldig kritik, men jeg tror ikke, de har brugt Kotlin nok til rent faktisk at forstå "Kotlin-måden". Mange kommentatorer under artiklen synes at tænke på samme måde.

Men det betyder ikke noget. Jeg vil vædde med, at det også ville ske i dit projekt. "Prøvede det, kunne ikke lide det". Du får dem ikke til at bruge mere tid på det. Du får dem ikke til at prøve igen. Du får dem ikke til at give det en chance til. Og ud fra et praktisk synspunkt har de måske ret. Java er bare så populær, at det virker overflødigt at bruge noget andet på JVM'en.

Hvorfor så denne artikel?

Du har lige brugt en del tid på at skrive en artikel, som tilsyneladende ikke har nogen pointe. Hvorfor skulle jeg prøve at lære et sprog, hvis du alligevel siger, at det er meningsløst?

Jeg synes ikke, det er meningsløst. Jeg synes stadig, at Kotlin er fantastisk. Jeg vil stadig gerne bruge det (og det gør jeg faktisk til mine private projekter). Hvis jeg kunne, ville jeg bare skifte til det og glemme alt om Javas begrænsninger. Men den nuværende virkelighed siger, at jeg ikke kan. Og det vil jeg gerne prøve at ændre på.

Min hensigt med dig, kære læser, er i det mindste at overveje muligheden for at komme ud af den hyggelige Java-komfortzone. For måske, bare måske, vil du elske Kotlin lige så meget, som jeg gør. Og hvis du gør, er det endnu en Kotlin-kyndig udvikler på marked.

Læs mere om det:

Den bedste type projekter til Java

3 almindelige udfordringer ved softwareproduktudvikling for nystartede virksomheder

Den rigtige måde at finde de bedste Java-udviklere på