Hvorfor Kotlin er fantastisk, men du vil likevel fortsette med Java

Uansett hvilken gruppe du tilhører, er det en grunn til at du holder deg til Java. Og jeg klandrer deg ikke. Det har uten tvil det mest utviklede, universelle og komplette økosystemet i hele verden. bedrift verden. Språket har et godt skreddersydd sett med muligheter, et sted i den rette sonen mellom for mye og for lite. Og nye funksjoner blir sakte, men sikkert lagt til, slik at det stort sett holder seg oppdatert med nyere trender i programmeringsverdenen.

Vet du Lombok Men? Hvis du ikke gjør det, anbefaler jeg på det sterkeste å prøve. Hvis du liker det, så har jeg noe bare for deg å prøve. Et helt nytt språk, som med sine funksjoner gjør Lombok overflødig. Det heter Kotlin.

Kotlin? Mener du Android-språket?

Kotlin på Android ble velsignet av Google selv til det punktet at det ble det de facto språket som ble valgt for plattformen. Det er ikke dette jeg skal fokusere på i denne artikkelen, men Android er faktisk stedet der jeg møtte Kotlin for første gang.

Min arbeidskollega utviklet en app for en på det tidspunktet aktuell prosjektpå egen hånd. Men tidsfristene nærmet seg med stormskritt, så jeg ble delegert til å hjelpe ham med å overholde dem. La meg nå forflytte meg tilbake i tid til det øyeblikket. Og... Æsj! Hvorfor bruker han et merkelig språk som høres ut som en ketchupmerke!? Det ser forferdelig ut!

Hvorfor står det "fun" foran hver funksjon? Som om jeg ikke allerede vet hva det er. Dessuten har jeg allerede gøy med Java Uansett. Og hvor er returtypen? På slutten? Er du gal? Hva er det, tilordner du noe til en funksjon? Det gir ingen mening! Det ser bare ut som Java med ekstra trinn! Vent, hvor er klassen denne metoden tilhører? Hvor har du gjemt den, din ketchup-klingende.., Java imiterende unnskyldning for et programmeringsspråk? Å nei, det gjorde du ikke. Å nei, det gjorde du ikke. ER DET EN GLOBAL FUNKSJON? Jeg er ferdig. Jeg ringer politiet.

Spoilervarsel: Jeg ringte ikke politiet. Enten jeg likte det eller ikke, måtte jeg justere min Java-sentriske tankegang for å tilpasse meg et annet språk. Men det er vel ikke så ille? Det er fortsatt et JVM-språk, det er sikkert bare et annet Java. Kanskje til og med med noen kule ekstrafunksjoner? Motvillig begynte jeg å jobbe med prosjektet.

Java med ekstra trinn

Hvis Java er så bra, hvorfor finnes det ingen Java 2? Spøk til side, det var det jeg tenkte for meg selv. Jeg skal bare late som om Kotlin er Java 2. Ny syntaks og alt, men jeg trenger bare å lære meg nok av det til å fullføre prosjektet. Jøss, der tok jeg feil.

Etter å ha prøvd det i bare en dag eller to, innså jeg raskt at både Kotlin og Java er ikke så elastiske. Forsøk på å bøye dem mot hverandre ender uunngåelig med at en av dem knekker i to. Det ble tydelig at Kotlin er en ting for seg selv, og det faktum at det fungerer på en JVM betyr nesten ingenting fra et programmeringsståsted. (I parentes bemerket kan det også transpile til JavaScripteller kompileres til en opprinnelig binærfil).

Plan B, da. Bli kjent med språket. Første gang man leser dokumentasjonen, går det kaldt nedover ryggen på en erfaren Java-programmerer. For eksempel:
- tidligere nevnte toppnivå, også kalt global kontekst
- parameter- og funksjonens returtyper spesifisert på slutten

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

funksjonens kropp kan være et uttrykk (med likhetstegn)

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

if-setningen kan gi et resultat

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

Ok, jeg må bare venne meg til det. Bare en annen syntaks. Hva mer har du å tilby, mister Kotlin?

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

Ok, å kvitte seg med if (value == null)...et poeng til deg. Hva mer har du?

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

Hmm fint, kan være nyttig å unngå hvis andre blokkerer, men virker fortsatt som en gimmick skjønt.

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

Ok, den ser faktisk nyttig ut, jeg liker den! På den annen side kan jeg lage en singleton i Java også. Kanskje det ikke blir så elegant, men det er ikke noe nytt. Har du noen ess i ermet? Noen skikkelige heavy hitters?

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

Vent... Hva?

Milliardfeilen

Se for deg en kodebase der du ikke trenger å bekymre deg for nullsikkerhet. Tenk deg at du bare tar det for gitt at hver referanse faktisk inneholder noe meningsfylt. Tenk deg å være sikker på at alle null-relaterte problemer er håndtert på forhånd.
Forestill deg ikke mer. Alle referanser i Kotlin er ikke nullable som standard. Hvis du vil gjøre dem nullable, må du bevisst ta den avgjørelsen, og eksplisitt oppgi det i kode:

 var s: String? = null

Jeg forstår at du kanskje er skeptisk til hele ideen på dette tidspunktet. Du er vant til nullbare referanser. Du har det i bakhodet når du koder. Du har lært hvor du må være forsiktig. Det er akkurat det jeg tenker. Kommer fra Java...føltes det rart til å begynne med. Hva er poenget? Det kommer ikke til å få alle relaterte problemer til å forsvinne på magisk vis. Jeg må bare legge til "?" overalt. Det høres ut som en jobb.

Men jeg bestemte meg for å dykke dypt ned i språket, ikke sant? La oss få det på din måte, mister Kotlin. Jeg begynte å gjøre en innsats for å eliminere så mange nullbare variabler, felt og parametere som mulig. Steg for steg lærte jeg å bruke språkfunksjoner som gjorde det enklere å eliminere nullbare referanser, f.eks. safe call-operatoren "?.", elvis-operatoren "?:", delegerte egenskaper, "let"-metoden og mer.

Etter hvert klarte jeg å få noen klasser til å bare inneholde felt og metodeparametere som ikke var null. Jeg visste at hvis en klasse var vellykket instansiert, kunne jeg nesten glemme null i metodekroppene. Det var en lykke. Med tiden satte jeg mer og mer pris på dette. Men til syvende og sist tenkte jeg ikke på det som en "killer feature", Java fortsatt føltes som hjemme. Helt til...

Comebacket

Prosjektet nærmet seg slutten. Jeg lærte Kotlin mer og mer å kjenne, og med denne kunnskapen ble koden stadig mer ryddig, lesbar og konsis. Du kunne se forbedringene med det blotte øye i commit-historikken. Men nå er tiden endelig kommet. Med uventet gode minner fra det nye språket var det på tide å si farvel og gå tilbake til den søte komfortsonen i Java. Det var i hvert fall det jeg trodde.

Kjenner du den følelsen når du begynner å sette pris på noe i samme øyeblikk som det er borte? Når du ikke innser hvor avhengig du er av noe før du ikke kan bruke det lenger? Det var det beste eksemplet på den følelsen jeg noen gang har opplevd.

Da jeg gikk tilbake til å skrive koden i JavaJeg ble nesten livredd for mangelen på noen funksjoner. Det var som om hjernen min ubevisst, feilaktig, ettermonterte Kotlin-funksjoner i Java. Jeg opplevde situasjoner der jeg faktisk begynte å implementere noe, bare for å innse at det ikke ville fungere i dette språket. I beste fall kunne jeg skrive det Kotlin-aktig, men det ville bli klumpete, uleselig og/eller kreve for mye boilerplate.

Nullsikkerhet var selvfølgelig den funksjonen jeg savnet mest. Men jeg ble overrasket over hvor mange mindre ting som ble naturlige for meg: navngitte parametere, egenskaper i stedet for gettere og settere, "==" som equals og "===" som referensiell likhet, kvalifisert "this", utvidelsesfunksjoner, implisitt singulær lambda-parameter, "_" for ubrukte lambda-parametere, dataklasser, scope-funksjoner, andre Kotlin stdlib-funksjoner, operatorer og mer. Og måten alt passer fint sammen på. Til sammenligning føltes Java ... primitivt.

Det føltes faktisk så ille at jeg begynte å vurdere å bytte til Kotlin helt og holdent. Teoretisk sett er det fullt interoperabelt med Java, du kan bare legge til Kotlin-støtte i et eksisterende prosjekt og begynne å skrive nye klasser. Kotlin-siden vet hvordan man "snakker" med Java, og Java-siden vet ikke engang at den "snakker" med et annet språk. Og etter kompilering til bytekode gjør det egentlig ingen forskjell for JVM-en.

Virkelighetssjekk

Så hva venter du på? Hvis språket er så bra som du sier, er det bare å bruke det! Kanskje ikke i eksisterende prosjekter, men jeg vet at det bør være interoperabelt, men å blande to forskjellige språk på denne måten høres stygt ut.

Ok, så for nye moduler - Kotlin er det. Eller er det det? Du jobber i en team. Du må rådføre deg med dem og overbevise dem om hvor flott dette nye språket er. Hva? Liker de det ikke? Liker de det ikke? Det høres ut som om de ikke vil anstrenge seg for å lære det. Men du kan ikke klandre dem, du var også skeptisk til å begynne med.

Prosjektlederen! Ja! Han vil helt sikkert forstå den store verdien Kotlin vil tilføre teamet vårt. Å, den storheten som vil komme!
-Nei
-Vent, hvorfor? -Hvorfor?
-Hva er det? -Laget vet det ikke.
-De vil lære!
-De vil ikke lære. -De vil ikke lære.
-Du kan lage dem!
-De trenger ikke å lære. -De trenger ikke å lære.
-Jeg mener, det er sant, men tenk på mulighetene!
-Ja, hva om du tenker på problemene først? -Ja.

Legenden sier at det finnes et prosjekt. Et prosjekt som er stort og komplekst, men som er pent skrevet i alle ledd. Et prosjekt der alle utviklerne er enige om hvilke løsninger som skal brukes. Der ny funksjonalitet bare flyter jevnt og trutt fra programmerernes tastaturer. Der feil er sjeldne og enkle å fikse.

Har du sett et sånt prosjekt? Jeg har ikke det. Noen var i nærheten, men de fleste av dem er et stort rot av gammel kode. Og hvis de ikke er det, vil de sannsynligvis bli det en gang i fremtiden. Forestill deg nå at du kaster inn et annet språk i miksen. Det introduserer nye måter å gjøre feil på. Det krever at utviklerne vet hva de gjør. Det er mildt sagt en risiko.

Tenk også på rotasjon av utviklere. Folk kommer og går. Vil du tvinge alle nye utviklere til å lære seg et helt nytt språk? Nei, det er kontraproduktivt. Vil du ansette Kotlin-utviklere i utgangspunktet? Lykke til med det, det er vanskelig nok å ansette en god Java-utvikler.

Folk har prøvd. Jeg må si at jeg ikke er enig i de fleste av påstandene i den artikkelen. Det er noe gyldig kritikk der, men jeg tror de ikke har brukt Kotlin nok til å faktisk forstå "Kotlin-måten". Mange kommentatorer under den artikkelen ser ut til å tenke på samme måte.

Men det spiller ingen rolle. Jeg vedder på at dette ville skjedd i ditt prosjekt også. "Prøvde det, likte det ikke". Du får dem ikke til å bruke mer tid på det. Du får dem ikke til å prøve igjen. Du får dem ikke til å gi det en ny sjanse. Og fra et praktisk synspunkt kan de ha rett. Java er så populært at det virker overflødig å bruke noe annet på JVM-en.

Hvorfor denne artikkelen da?

Du har nettopp brukt mye tid på å skrive en artikkel som ikke ser ut til å ha noe poeng. Hvorfor skulle jeg prøve å lære meg et språk, hvis du sier at det er meningsløst uansett?

Jeg synes ikke det er meningsløst. Jeg synes fortsatt at Kotlin er flott. Jeg har fortsatt lyst til å bruke det (og det gjør jeg faktisk i mine private prosjekter). Hvis jeg kunne, ville jeg bare byttet til det og glemt begrensningene i Java. Men slik virkeligheten ser ut nå, kan jeg ikke det. Og det vil jeg prøve å endre på.

Min intensjon er at du, kjære leser, i det minste skal tenke på muligheten for å komme ut av den koselige Java-komfortsonen. For kanskje, bare kanskje, vil du elske Kotlin like mye som jeg gjør. Og hvis du gjør det, er det enda en Kotlin-kyndig utvikler på marked.

Les mer om dette:

Den beste typen prosjekter for Java

3 vanlige utfordringer ved utvikling av programvareprodukter for oppstartsbedrifter

Den riktige måten å finne de beste Java-utviklerne på