Miks Kotlin on vinge, aga sa jääd ikkagi Java juurde

Sõltumata sellest, millisesse gruppi te kuulute, on põhjus, miks te jääte koos Java. Ja ma ei süüdista teid. Sellel on vaieldamatult kõige arenenum, universaalsem ja täielikum ökosüsteem kogu maailma ettevõte maailma. Sellel keelel on kenasti kohandatud võimalused, mis on kuskil õiges vahemikus liiga palju ja liiga vähe. Ja uusi funktsioone lisatakse aeglaselt, kuid järjekindlalt, hoides seda enamasti kursis uuemate suundumustega programmeerimismaailmas.

Kas te teate Lombok aga? Kui te seda ei tee, siis soovitan väga proovida. Kui teile meeldib, siis on mul midagi just teie jaoks, mida proovida. Täiesti uus keel, mis oma omaduste poolest muudab Lomboki iganenuks. Selle nimi on Kotlin.

Kotlin? Sa mõtled Androidi keelt?

Google ise õnnistas Kotlini Androidi puhul nii palju, et sellest sai platvormi de facto keel. Selles artiklis ei keskendu ma sellele, kuid Android on tõepoolest koht, kus ma esimest korda Kotliniga kohtusin.

Minu töökaaslane arendas rakendust, mis oli tollase praeguse projekt, omal käel. Tähtajad lähenesid aga kiiresti, nii et mulle anti ülesanne aidata tal neid täita. Lubage mul end nüüd ajas tagasi viia sellesse hetke. Aaaa ja... YUCK! Miks ta kasutab mingit imelikku keelt, mis kõlab nagu ketšupi brändi!? See näeb kohutav välja!

Miks on iga funktsiooni ette kirjutatud "fun"? Nagu ma juba ei teaks, mis see on. Samuti on mul juba lõbus koos Java igatahes. Ja kus on tagastustüüp? Lõpus? Oled sa hullu? Mis see on, kas sa määrad midagi funktsioonile? Sellel pole mingit mõtet! See kõik näeb lihtsalt välja nagu Java koos täiendavate sammudega! Oodake, kuhu see meetod kuulub? Kuhu sa selle peitsid sa ketsupi-häälne, Java imiteeriv vabandus programmeerimiskeele kohta? Oh ei. Oh ei, sa ei teinud seda. ON SEE GLOBAALNE FUNKTSIOON? See on kõik, ma olen valmis, ma helistan politseisse.

Spoiler hoiatus: ma ei helistanud õiguskaitseorganitele. Kas see meeldis mulle või mitte, pidin oma Java-keskset mõtteviisi kohandama, et kohaneda teise keelega. See ei ole siiski nii halb, eks? See on ikkagi JVM keel, kindlasti on see lihtsalt teistsugune Java. Võib-olla isegi mõne laheda lisafunktsiooniga? Vastumeelselt hakkasin projekti kallal töötama.

Java koos täiendavate sammudega

Kui Java on nii suurepärane, miks ei ole siis Java 2? Nalja kõrvale jättes mõtlesin ma seda endale. Ma lihtsalt teesklen, et Kotlin on Java 2. Uus süntaks ja kõik, aga ma pean seda lihtsalt piisavalt ära õppima, et projekt lõpetada. Boy oh boy oli ma eksinud.

Pärast paari päeva pikkust proovimist sain kiiresti aru, et nii Kotlin kui ka Java ei ole nii elastsed. Kui püüda neid üksteise poole painutada, lõpeb see paratamatult sellega, et üks neist murdub pooleks. Selgus, et Kotlin on omaette asi ja see, et see töötab JVMil, ei tähenda programmeerija seisukohast peaaegu täpselt midagi. (Kõrvalmärkusena võib see ka transpileerida JavaScript, või kompileerida algupäraseks binaarseks versiooniks).

Plaan B siis. Tegelikult tuleb õppida keelt tundma. Dokumendi esmakordne lugemine ajab kogenud Java-programmeerijal külmavärinaid läbi selgroo. Näiteks:
- eelnevalt mainitud ülevalpoolne ehk globaalne kontekst
- parameetrite ja funktsioonide tagastamistüübid, mis on määratud lõpus

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

funktsiooni keha võib olla väljendus (kasutades võrdsuse märki)

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

if avaldis võib anda tulemuse

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

Okei, ma pean lihtsalt sellega harjuma. Lihtsalt teistsugune süntaks. Mida teil veel pakkuda on, mister Kotlin?

 value?.method() // execute if not null

Oh ok, vabanemine if (value == null), punkt teile. Mis sul veel on?

fun check(list: List, alternative: Boolean) = when {
 list on LinkedList -> print("lingitud")
 alternatiiv -> print("alternatiiv")
 list.size > 50 -> print("big")
 else -> print("muu")
 }

Hmm kena, võiks olla mugav vältida, kui teised blokeerivad, tundub siiski nagu trikk.

 objekt SingularObject: Counter() {
 var a = 14
 fun test() = if (a > 10) "rohkem" else "vähem"
 }

Ok, see tundub tegelikult kasulik, mulle meeldib! Teisest küljest, ma võin luua singletoni ka Java's. Võib-olla ei ole see nii elegantne, aga see ei ole midagi väga uut. On sul mingeid ässasid varrukas? Nagu tõelised heavy hitterid?

 var s: String = null // ei kompileeru, mitte-null tüüp

Oota... mida?

Miljardi dollari viga

Kujutage ette koodibaasi, kus te ei pea muretsema nullturvalisuse pärast. Kujutage ette, et iga viide sisaldab tegelikult midagi mõttekat. Kujutage ette, et olete kindel, et iga nulliga seotud probleem on eelnevalt lahendatud.
Kujutage ette, et enam ei ole. Kõik viited Kotlinis ei ole vaikimisi nullitavad. Kui te soovite neid nullitavaks muuta, peate te teadlikult teha see otsus ja selgesõnaliselt märkida see kood:

 var s: String? = null

Ma saan aru, et te võite praegu olla skeptiline kogu selle idee suhtes. Te olete harjunud nulliga viidetega. Sa hoiad seda kodeerimise ajal tagantjärele meeles. Sa oled õppinud, kus sa pead olema ettevaatlik. Täpselt minu mõtted. Tulevad Java, alguses tundus see tõepoolest imelik. Nagu, mis mõte on? See ei kaota maagiliselt kõiki sellega seotud probleeme. Ma pean lihtsalt igal pool lisama "?", kõlab nagu töö.

Aga ma otsustasin ju sügavale keelde sukelduda? Olgu see siis sinu moodi, mister Kotlin. Hakkasin tegema jõupingutusi, et kõrvaldada nii palju nullitav muutujaid, välju ja parameetreid kui võimalik. Samm-sammult õppisin kasutama keele omadusi, mis lihtsustasid nullitavate viidete kõrvaldamist, nt safe call "?." operaator, elvis "?:" operaator, delegeeritud omadused, "let" meetod ja palju muud.

Aja möödudes õnnestus mul saada mõned klassid sisaldama ainult mitte-null välju ja meetodi parameetreid. Põhimõtteliselt teadsin, et kui klass on edukalt instantseeritud, võin peaaegu unustada nullitavuse meetodite kehades. See oli õndsus. Aja jooksul hindasin seda üha enam ja enam. Lõppkokkuvõttes ei pidanud ma seda siiski tapjafunktsiooniks, Java tundus ikka veel nagu kodus. Kuni...

Tagasitulek

Projekt lähenes lõpule. Ma õppisin Kotlini üha paremini tundma ja nende teadmistega muutus kood üha korrastatumaks, loetavamaks ja ülevaatlikumaks. Parandusi võis palja silmaga näha commit history's. Lõpuks jõudis aga kätte see aeg. Ootamatult armsate mälestustega uuest keelest oli aeg hüvasti jätta ja minna tagasi magusasse mugavustsooni Java. Või nii ma arvasin.

Kas tunnete seda tunnet, kui hakkate midagi hindama just sel hetkel, kui see on kadunud? Kui sa ei saa aru, kui palju sa millestki sõltud, kuni sa ei saa seda enam kasutada? See oli kõige parem näide sellest tundest, mida ma ilmselt kunagi elus kogenud olen.

Kui ma sain tagasi koodi kirjutamise juurde Java, ma olin peaaegu hirmunud mõnede funktsioonide puudumise pärast. See oli nagu mu aju oleks alateadlikult, valesti tagantjärele Kotlini funktsioone Java'sse paigaldanud. Ma kogesin olukordi, kus ma tegelikult hakkasin midagi rakendama, ainult selleks, et aru saada, et see ei tööta selles keeles. Parimal juhul saaksin selle Kotlini moodi kirjutada, kuid see oleks mahukas, loetamatu ja/või nõuaks liiga palju boilerplate'i.

Nullturvalisus oli muidugi see funktsioon, mida ma kõige rohkem igatsesin. Aga ma olin üllatunud, kui palju väiksemaid asju muutus minu jaoks loomulikuks: nimeparameetrid, omadused getterite ja setterite asemel, "==" kui võrdsus ja "===" kui referentsiaalne võrdsus, kvalifitseeritud "this", laiendamisfunktsioonid, implicit singular lambda parameeter, "_" kasutamata lambda parameetrite jaoks, andmeklassid, scope funktsioonid, muud Kotlini stdlib funktsioonid, operaatorid ja palju muud. Ja kuidas see kõik kenasti kokku sobib. Võrreldes sellega tundus Java... primitiivne.

See tundus tegelikult nii halb, et hakkasin kaaluma Kotlinile üleminekut üldse. Teoreetiliselt on see Java'ga täielikult koostalitlusvõimeline, saab lihtsalt Kotlini toe olemasolevasse projekti lisada ja hakata uusi klasse kirjutama. Kotlini pool oskab Java'ga "rääkida" ja Java pool ei tea isegi, et ta "räägib" teise keelega. Ja pärast bytecode'iks kompileerimist ei tee see JVMile tegelikult mingit vahet.

Reaalsuse kontroll

Mida te siis ootate? Kui keel on nii hea, kui te ütlete, siis kasutage seda! Võib-olla mitte olemasolevates projektides küll, ma tean, et see peaks olema koostalitlusvõimeline, aga kahe erineva keele segamine niimoodi kõlab koledal kombel.

Ok, nii et uute moodulite jaoks - Kotlin see on. Või on see? Te töötate meeskond. Te peate nendega konsulteerima ja neid veenma selle uue keele suursugususes. Mida? See ei meeldi neile? Kõlab nii, et nad lihtsalt ei taha selle õppimiseks vaeva näha. Sa ei saa neid küll süüdistada, ka sina olid alguses skeptiline.

Projektijuht! Jah! Ta mõistab kindlasti, kui suurt väärtust Kotlin meie meeskonnale annab. Oh, milline suursugusus tuleb!
-No
-Oota, miks?
-Meeskond ei tea seda.
-Nad õpivad!
-Nad ei taha õppida.
-Te saate neid teha!
-Nad ei pea õppima.
-See on küll tõsi, aga mõtle võimaluste peale!
-Ja, mis siis, kui sa mõtled kõigepealt probleemidele.

Legend ütleb, et on olemas projekt. Projekt, mis on suur ja keeruline, kuid igas osas kenasti kirjutatud. Projekt, kus kõik arendajad on kasutatud lahenduste osas ühel meelel. Kus uued funktsionaalsused lihtsalt voolavad sujuvalt programmeerijate klaviatuurilt. Kus vigu on harva ja neid on lihtne parandada.

Kas olete näinud sellist projekti? Ma ei ole. Mõni oli küll lähedal, kuid enamik neist on suur pärandkoodi segadus. Ja kui nad seda ei ole, siis tõenäoliselt muutuvad nad selleks mingil hetkel tulevikus. Nüüd kujutage ette, et visake sinna juurde veel üks keel. See toob kaasa uusi võimalusi vigade tegemiseks. See nõuab, et arendajad teaksid, mida nad teevad. See on pehmelt öeldes risk.

Nüüd kaaluge ka arendajate rotatsiooni. Inimesed tulevad ja lähevad. Kas te panete iga uue arendaja õppima täiesti uut keelt? Ei, see on ebaproduktiivne. Kas te võtate Kotlini arendajaid üldse tööle? Palju õnne sellega, hea Java arendaja palkamine on piisavalt raske.

Inimesed on proovinud. Pean ütlema, et ma ei nõustu enamiku selles artiklis esitatud väidetega. Seal on mõningast põhjendatud kriitikat, kuid ma arvan, et nad ei kasutanud Kotlini piisavalt, et tegelikult mõista "Kotlini viisi". Paljud kommenteerijad selle artikli all näivad arvavat sarnaselt.

See ei ole siiski oluline. Vean kihla, et see juhtuks ka teie projektis. "Proovitud, ei meeldinud". Sa ei pane neid rohkem aega kulutama. Sa ei pane neid uuesti proovima. Te ei pane neid andma sellele veel üht võimalust. Ja praktilisest vaatenurgast vaadatuna võib neil olla õigus. Java on lihtsalt nii populaarne, et millegi muu kasutamine JVMis tundub üleliigne.

Miks siis see artikkel?

Sa kulutasid just märkimisväärse aja artikli kirjutamisele, millel ei tundu olevat mõtet. Miks ma peaksin proovima keelt õppida, kui te ütlete, et see on niikuinii mõttetu?

Noh, ma ei arva, et see on mõttetu. Ma arvan endiselt, et Kotlin on suurepärane. Ma tahan seda ikka veel tegelikult kasutada (ja ma tegelikult kasutan seda oma eraprojektide jaoks). Kui ma saaksin, siis ma lihtsalt läheksin sellele üle ja unustaksin Java piirangud. Aga praegune reaalsus ütleb, et ma ei saa. Ja ma tahan proovida seda muuta.

Minu kavatsus teile, lugupeetud lugeja, on vähemalt kaaluda võimalust tulla välja mugavast Java mugavustsoonist. Sest võib-olla, ainult võib-olla, armastad Kotlini sama palju kui mina. Ja kui te armastate, siis on veel üks Kotlini tundev arendaja rohkem. turg.

Loe edasi:

Parim projektitüüp Java jaoks

3 ühist väljakutset tarkvara tootearenduse alustavatele ettevõtetele

Õige viis tipp Java arendajate leidmiseks