Miksi Kotlin on mahtava, mutta pysyt silti Javassa?
Marcin Perlikowski
Vanhempi Java-kehittäjä
Jos olet Java-kehittäjä, sinulla on todennäköisesti ainakin jonkin verran kokemusta muista ohjelmointikielistä. Jotkut meistä aloittivat ohjelmointiseikkailunsa jollakin muulla kielellä, kuten C/C++, JavaScript, C#, Python tai ehkä jopa Pascalilla tai Basicilla. Jotkut kuitenkin aloittivat Javalla eivätkä vain koskaan kiinnittäneet kovinkaan paljon huomiota muihin kieliin, muistellen ikävästi sitä yhtä kertaa, kun heidän piti nopeasti koodata jotain frontend-puolella.
Riippumatta siitä, mihin ryhmään kuulut, on olemassa syy, miksi pysyt mukana Java. Enkä syytä sinua. Se on luultavasti kehittynein, yleisin ja täydellisin ekosysteemi koko maailmassa. yritys maailmaan. Kielessä on mukavasti räätälöityjä valmiuksia, jotka ovat jossain oikealla alueella liiallisen ja liian vähäisen välillä. Uusia ominaisuuksia lisätään hitaasti mutta tasaisesti, jolloin kieli pysyy pääosin ohjelmointimaailman uusien suuntausten tasalla.
Tiedätkö Lombok kuitenkin? Jos et tunne, suosittelen kokeilemaan. Jos pidät siitä, minulla on jotain juuri sinulle kokeiltavaa. Kokonaan uusi kieli, joka ominaisuuksiltaan tekee Lombokista tarpeettoman. Sen nimi on Kotlin.
Kotlin? Tarkoitatko Androidin kieltä?
Google itse siunasi Kotlinin Androidissa niin, että siitä tuli alustan de facto-kieli. En keskity tässä artikkelissa tähän, mutta Android on todellakin paikka, jossa tapasin Kotlinin ensimmäistä kertaa.
Työkaverini oli kehittämässä sovellusta silloiselle nykyiselle projektiyksin. Määräajat lähestyivät kuitenkin nopeasti, joten minut valtuutettiin auttamaan häntä niiden täyttämisessä. Siirryn nyt ajassa taaksepäin tuohon hetkeen. Ja... YUCK! Miksi hän käyttää jotain outoa kieltä, joka kuulostaa kuin ketsuppimerkki!? Se näyttää kamalalta!
Miksi ennen jokaista funktiota kirjoitetaan "fun"? Ihan kuin en jo tietäisi, mikä se on. Lisäksi minulla on jo hauskaa kanssa Java joka tapauksessa. Ja missä on paluutyyppi? Lopussa? Oletko hullu? Mitä tuo on, osoitatko jotain funktiolle? Siinä ei ole mitään järkeä! Kaikki näyttää vain siltä, että Java lisävaiheilla! Odota, mihin luokkaan tämä metodi kuuluu? Minne piilotit sen, senkin ketsuppi-ääninen, Java jäljittelevä tekosyy ohjelmointikielelle? Voi ei. Voi ei, et tehnyt. ONKO TUO GLOBAALI FUNKTIO? Nyt riittää, olen valmis, soitan poliisille.
Spoilerivaroitus: en soittanut lainvalvontaviranomaisille. Halusinpa tai en, minun oli mukautettava Java-keskeistä ajattelutapaani toisen kielen huomioon ottamiseksi. Eihän se kuitenkaan ole niin paha, eikö niin? Se on edelleen JVM-kieli, varmasti se on vain eri Java. Ehkä jopa hienoilla lisäominaisuuksilla? Vastahakoisesti aloin työstää projektia.
Java lisävaiheiden kanssa
Jos Java on niin loistava, miksi Java 2:ta ei ole olemassa? Vitsit sikseen, Niin ajattelin itsekseni. Teeskentelen, että Kotlin on Java 2. Uusi syntaksi ja kaikki, mutta minun on vain opittava tarpeeksi, jotta saan projektin valmiiksi. Voi pojat, olin väärässä.
Kokeiltuani sitä vain päivän tai kaksi, tajusin nopeasti, että sekä Kotlin että Java eivät ole niin joustavia. Jos niitä yrittää taivuttaa toisiaan kohti, toinen niistä katkeaa väistämättä kahtia. Tuli selväksi, että Kotlin on asia erikseen, ja se, että se toimii JVM:llä, ei merkitse ohjelmoijan näkökulmasta juuri mitään. (Sivuhuomautuksena mainittakoon, että se voi myös transpileerata JavaScript, tai kääntää natiiviksi binääriksi).
Suunnitelma B sitten. Itse asiassa tutustu kieleen. Jos lukee dokumentteja ensimmäistä kertaa, kokeneen Java-ohjelmoijan selkärangan läpi tulee väristyksiä. Esimerkiksi: - aiemmin mainittu ylätason eli globaali konteksti - lopussa määritetyt parametri- ja palautustyypit
fun sum(a: Int, b: Int): Int {
return a + b
}
funktiorunko voi olla lauseke (tasa-arvomerkin avulla).
fun sum(a: Int, b: Int) = a + b
if-lause voi antaa tuloksen
val y = if (x == 1) {
"one"
} else if (x == 2) {
"two"
} else {
"other"
}
Okei, minun täytyy vain tottua siihen. Vain erilainen syntaksi. Mitä muuta sinulla on tarjota, herra Kotlin?
value?.method() // execute if not null
Okei, eroon pääseminen if (arvo == null), piste sinulle. Mitä muuta sinulla on?
fun check(list: List, alternative: Boolean) = when {
list on LinkedList -> print("linked")
vaihtoehto -> print("vaihtoehto")
list.size > 50 -> print("iso")
else -> print("muu")
}
Hmm kiva, voisi olla kätevää välttää, jos muut blokkaavat, mutta vaikuttaa silti kikkailulta.
object SingularObject: Counter() {
var a = 14
fun test() = if (a > 10) "enemmän" else "vähemmän"
}
Okei, tuo näyttää todella hyödylliseltä, pidän siitä! Toisaalta voin luoda singletonin myös Javassa. Ehkä se ei ole näin tyylikäs, mutta se ei ole mitään uutta. Onko sinulla ässiä hihassa? Todellisia kovia kamaa?
var s: String = null // ei käänny, ei-null-tyyppi.
Kuvittele koodipohja, jossa sinun ei tarvitse huolehtia nollaturvallisuudesta. Kuvittele, että pidät itsestäänselvyytenä sitä, että jokainen viittaus todella sisältää jotain merkityksellistä. Kuvittele olevasi varma, että kaikki nollaan liittyvät ongelmat on hoidettu etukäteen. Kuvittele enää. Kotlinissa kaikki viittaukset eivät ole oletusarvoisesti nollattavissa. Jos haluat tehdä siitä nollattavissa olevan, sinun täytyy tehdä tietoisesti tehdä tämä päätös, ja nimenomaisesti ilmoittaa sen koodi:
var s: String? = null
Ymmärrän, että suhtaudutte ehkä epäilevästi koko ajatukseen tässä vaiheessa. Olet tottunut mitätöitäviin viittauksiin. Pidät sen takaraivossasi koodatessasi. Olet oppinut, missä sinun on oltava varovainen. Ajatukseni ovat täsmälleen samat. Tulossa Java, se tuntui aluksi todella oudolta. Kuten, mitä järkeä siinä on? Se ei taikomalla saa kaikkia asiaan liittyviä ongelmia katoamaan. Minun täytyy vain lisätä "?" joka paikkaan, kuulostaa työläältä.
Mutta päätin sukeltaa syvälle kieleen. Tehdään se sinun tavallasi, herra. Kotlin. Aloin pyrkiä poistamaan niin monta nollattavaa muuttujaa, kenttää ja parametria kuin mahdollista. Askel askeleelta opin käyttämään kielen ominaisuuksia, jotka helpottivat nollattavien viittausten poistamista, esimerkiksi safe call "?." -operaattoria, elvis "?:" -operaattoria, delegoituja ominaisuuksia, let-metodia ja paljon muuta.
Ajan myötä sain aikaan sen, että jotkut luokat sisälsivät vain kenttiä ja metodiparametreja, jotka eivät olleet nollia. Periaatteessa tiesin, että jos luokka oli onnistuneesti instantioitu, metodien nollattavuus voitiin melkein unohtaa. Se oli autuaaksi tekevää. Ajan myötä arvostin tätä yhä enemmän. Lopulta en kuitenkaan pitänyt sitä tappavana ominaisuutena, Java tuntui yhä kodilta. Kunnes...
Paluu
Hanke lähestyi loppuaan. Tutustuin Kotliniin yhä paremmin, ja tämän tiedon myötä koodista tuli yhä siistimpää, luettavampaa ja tiiviimpää. Parannukset saattoi nähdä paljain silmin commit-historiassa. Aika on kuitenkin vihdoin koittanut. Kun uudesta kielestä jäi yllättävänkin mukavia muistoja, oli aika sanoa hyvästit ja palata takaisin suloiseen mukavuusalueeseen Java. Tai niin minä luulin.
Tiedätkö sen tunteen, kun alat arvostaa jotain juuri sillä hetkellä, kun se on poissa? Kun et tajua, miten paljon luotat johonkin, ennen kuin et voi enää käyttää sitä? Se oli paras esimerkki tuosta tunteesta, jonka olen luultavasti koskaan elämässäni kokenut.
Kun palasin kirjoittamaan koodia Java, olin melkein kauhuissani joidenkin ominaisuuksien puuttumisesta. Aivoni ikään kuin olisivat alitajuisesti ja virheellisesti jälkiasentaneet Kotlinin ominaisuuksia Javaan. Koin tilanteita, joissa aloin itse asiassa toteuttaa jotain, mutta tajusin, ettei se toimi tällä kielellä. Parhaassa tapauksessa voisin kirjoittaa sen Kotlinin tapaan, mutta siitä tulisi tilaa vievä, lukukelvoton ja/tai se vaatisi liikaa boilerplatea.
Nollaturvallisuus oli tietenkin ominaisuus, jota kaipasin eniten. Yllätyin kuitenkin siitä, kuinka monista pienemmistä asioista tuli minulle luonnollisia: nimetyt parametrit, ominaisuudet getterien ja setterien sijaan, "==" yhtäläisyyksinä ja "===" viittauksellisena yhtäläisyytenä, kvalifioitu "this", laajennusfunktiot, implisiittinen singulaarinen lambda-parametri, "_" käyttämättömille lambda-parametreille, dataluokat, scope-funktiot, Kotlinin stdlibin funktiot, operaattorit ja paljon muuta. Ja se, miten kaikki sopii hienosti yhteen. Vertailun vuoksi Java tuntui... primitiiviseltä.
Se tuntui itse asiassa niin pahalta, että aloin harkita Kotliniin siirtymistä kokonaan. Teoriassa se on täysin yhteensopiva Javan kanssa, voit vain lisätä Kotlin-tuen olemassa olevaan projektiin ja alkaa kirjoittaa uusia luokkia. Kotlinin puoli osaa "puhua" Javalle, eikä Javan puoli edes tiedä, että se "puhuu" toisen kielen kanssa. Ja bytecode-kääntämisen jälkeen JVM:llä ei ole oikeastaan mitään merkitystä.
Todellisuuden tarkistus
Joten mitä sinä odotat? Jos kieli on niin hyvä kuin sanot, käytä sitä! Ehkä ei kuitenkaan nykyisissä projekteissa, sillä tiedän, että sen pitäisi olla yhteentoimiva, mutta kahden eri kielen sekoittaminen tällä tavalla kuulostaa rumalta.
Okei, uusia moduuleja varten - Kotlin se on. Vai onko? Työskentelet joukkue. Sinun on kuultava heitä ja vakuutettava heidät tämän uuden kielen suuruudesta. Mitä? Eivätkö he pidä siitä? Kuulostaa siltä, etteivät he vain halua nähdä vaivaa sen oppimiseksi. Et voi syyttää heitä, sinäkin olit aluksi epäileväinen.
Projektipäällikkö! Kyllä! Hän ymmärtää varmasti, miten paljon hyötyä Kotlin tuo tiimillemme. Voi sitä mahtavuutta, joka tulee! -No -Odota, miksi? -Joukkue ei tiedä sitä. -He oppivat! -He eivät halua oppia. -Voit tehdä niitä! -Heidän ei tarvitse oppia. -Se on totta, mutta ajattele mahdollisuuksia! -Joo, entä jos ajattelisit ensin ongelmia.
Legendan mukaan on olemassa hanke. Projekti, joka on suuri ja monimutkainen, mutta joka on kirjoitettu hienosti joka osaan. Projekti, jossa kaikki kehittäjät ovat yksimielisiä käytetyistä ratkaisuista. Jossa uudet toiminnallisuudet vain virtaavat sujuvasti ohjelmoijien näppäimistöltä. Jossa virheet ovat harvinaisia ja helppo korjata.
Oletko nähnyt tällaista hanketta? En ole. Jotkin olivat lähellä, mutta useimmat niistä ovat suurta perintökoodin sekasotkua. Ja jos ne eivät ole, niistä tulee todennäköisesti sellainen jossain vaiheessa tulevaisuudessa. Kuvittele nyt, että sekaan lisätään toinen kieli. Se tuo uusia tapoja tehdä virheitä. Se edellyttää, että kehittäjät tietävät, mitä he tekevät. Se on vähintäänkin riski.
Ota nyt huomioon myös kehittäjien rotaatio. Ihmisiä tulee ja menee. Pakotatko jokaisen uuden kehittäjän opettelemaan kokonaan uuden kielen? Ei, se on haitallista. Palkkaatko Kotlin-kehittäjiä ylipäätään? Onnea sen kanssa, hyvän Java-kehittäjän palkkaaminen on tarpeeksi vaikeaa.
Ihmiset ovat yrittäneet. Minun on sanottava, että en ole samaa mieltä useimmista artikkelin väitteistä. Siinä on jonkin verran perusteltua kritiikkiä, mutta mielestäni he eivät käyttäneet Kotlinia tarpeeksi ymmärtääkseen "Kotlinin tapaa". Monet kommentoijat artikkelin alla näyttävät ajattelevan samalla tavalla.
Sillä ei kuitenkaan ole väliä. Veikkaan, että näin tapahtuisi myös sinun projektissasi. "Kokeilin sitä, en pitänyt siitä". Et saa heitä käyttämään siihen enemmän aikaa. Et saa heitä yrittämään uudelleen. Et saa heitä antamaan sille uutta mahdollisuutta. Ja käytännön näkökulmasta katsottuna he saattavat olla oikeassa. Java on vain niin suosittu, että minkään muun käyttäminen JVM:ssä tuntuu tarpeettomalta.
Miksi sitten tämä artikkeli?
Käytit juuri huomattavan paljon aikaa kirjoittaessasi artikkelia, jolla ei näytä olevan mitään pointtia. Miksi yrittäisin opetella kieltä, jos se on mielestäsi joka tapauksessa turhaa?
Minusta se ei ole turhaa. Olen edelleen sitä mieltä, että Kotlin on loistava. Haluan edelleen käyttää sitä (ja käytänkin sitä yksityisissä projekteissani). Jos voisin, siirtyisin siihen ja unohtaisin Javan rajoitukset. Mutta nykyinen todellisuus sanoo, etten voi. Ja haluan yrittää muuttaa sitä.
Tarkoitukseni on, että sinä, rakas lukija, ainakin harkitset mahdollisuutta tulla ulos mukavalta Java-mukavuusalueelta. Koska ehkä, vain ehkä, sinä rakastat Kotlinia yhtä paljon kuin minä. Ja jos rakastat, yksi Kotlinia tunteva kehittäjä lisää. markkinat.