Kāpēc Kotlin ir lieliska, bet jūs tik un tā paliksiet ar Java

Neatkarīgi no tā, pie kuras grupas piederat, ir iemesls, kāpēc jūs palikāt ar. Java. Un es jūs nevainoju. Tai ir, iespējams, visattīstītākā, universālākā un pilnīgākā ekosistēma visā pasaulē. uzņēmums pasaule. Valodai ir labi pielāgots iespēju kopums, kas atrodas kaut kur pareizajā zonā starp pārāk daudz un pārāk maz. Un jaunas iespējas tiek lēnām, bet nemitīgi pievienotas, saglabājot to lielākoties atjauninātu, ņemot vērā jaunākās tendences programmēšanas pasaulē.

Vai jūs zināt Lombokas tomēr? Ja jums nav, es ļoti iesaku pamēģināt. Ja jums tas patīk, tad man ir kaut kas tieši jums, ko izmēģināt. Pilnīgi jauna valoda, kas ar savām īpašībām padara Lombok novecojušu. Tās nosaukums ir Kotlin.

Kotlin? Jūs domājat Android valodu?

Kotlin operētājsistēmā Android ir saņēmusi pašas Google svētību, un tā ir kļuvusi par de facto platformas valodas izvēli. Šajā rakstā es nepievērsīšu uzmanību šim jautājumam, taču Android patiešām ir vieta, kur es pirmo reizi sastapos ar Kotlin.

Mans darba kolēģis izstrādāja lietotni tobrīd aktuālajam projekts, pats par sevi. Taču termiņi strauji tuvojās, tāpēc man tika uzticēts palīdzēt viņam tos ievērot. Ļaujiet man tagad pārcelties atpakaļ laikā uz to brīdi. Aaaand... YUCK! Kāpēc viņš lieto kaut kādu dīvainu valodu, kas izklausās kā kečupa zīmols!? Tas izskatās briesmīgi!

Kāpēc pirms katras funkcijas ir rakstīts “fun”? It kā es jau nezinātu, kas tas ir. Turklāt man jau ir jautri ar Java jebkurā gadījumā. Un kur ir atgriešanas tips? Beigās? Vai tu esi traks? Kas tas ir, vai jūs kaut ko piešķirat funkcijai? Tam nav nekādas jēgas! Tas viss izskatās kā Java ar papildu soļiem! Pagaidiet, kur ir klase, kurai pieder šī metode? Kur tu to paslēpis, kečups, Java atdarinot attaisnojums programmēšanas valodas? Ak, nē. Ak nē, jūs to nedarījāt. VAI TĀ IR GLOBĀLĀ FUNKCIJA? Un viss, es esmu beidzis, es izsaucu policiju.

Spoileris: es neizsaucu tiesībsargājošās iestādes. Neatkarīgi no tā, vai man tas patika vai nē, man nācās pielāgot savu Java orientēto domāšanu, lai pielāgotos citai valodai. Tomēr tas nebūs tik slikti, vai ne? Tā joprojām ir JVM valoda, protams, tā vienkārši ir cita. Java. Varbūt pat ar dažām lieliskām papildu funkcijām? Nesteidzīgi es sāku strādāt pie projekta.

Java ar papildu soļiem

Ja Java ir tik lieliska, kāpēc nav Java 2? Joki malā, Tas ir tas, ko es domāju, ka sev. Es vienkārši izlikšos, ka Kotlin ir Java 2. Jauna sintakse un viss pārējais, bet man tikai jāapgūst pietiekami daudz, lai pabeigtu projektu. Ak, ak, ak, es kļūdījos.

Izmēģinājis to tikai vienu vai divas dienas, es ātri sapratu, ka gan Kotlin, gan Java nav tik elastīgi. Mēģinājums saliekt tās vienu pret otru neizbēgami beidzas ar to, ka viena no tām saplīst uz pusēm. Kļuva skaidrs, ka Kotlin ir lieta pati par sevi, un tas, ka tā darbojas uz JVM, no programmētāja viedokļa gandrīz neko nenozīmē. (Piebildīšu, ka tā var arī transpilēt uz JavaScript, vai kompilēt kā vietējo bināro versiju).

Tātad plāns B. Patiesībā, apgūstiet valodu. Pirmo reizi lasot dokumentāciju, pieredzējušam Java programmētājam pār mugurkaulu pārlaižas drebuļi. Piemēram:
- iepriekš minētais augstākā līmeņa jeb globālais konteksts
- parametru un funkcijas atgriešanas tipi, kas norādīti beigās.

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

funkcijas ķermenis var būt izteiksme (izmantojot vienlīdzības zīmi)

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

if paziņojums var sniegt rezultātu

 val y = if (x == 1) {
 "viens"
 } else if (x == 2) {
 "divi"
 } else {
 "cits"
 }

Labi, man pie tā vienkārši jāpierod. Vienkārši cita sintakse. Ko vēl jūs varat piedāvāt, Kotlin kungs?

 value?.method() // izpildīt, ja nav null

Labi, atbrīvojoties no ja (value == null), punkts jums. Kas vēl jums ir?

fun check(list: List, alternative: Boolean) = kad {
 saraksts ir LinkedList -> print("linked")
 alternative -> print("alternative")
 list.size > 50 -> print("big")
 else -> print("cits")
 }

Hmm jauki, varētu būt ērts, lai izvairītos, ja vēl bloķē, tomēr šķiet, ka triks, lai gan.

 objekts SingularObject: Counter() {
 var a = 14
 fun test() = if (a > 10) "more" else "less"
 }

Ok, šis izskatās patiešām noderīgs, man tas patīk! No otras puses, es varu izveidot singleton arī Java. Varbūt tas nebūs tik elegants, bet tas nav nekas jauns. Vai ir kādi tusi tavā piedurknē? Piemēram, īsti smagi trāpījumi?

 var s: string = null // nesaliekas, non-null tips

Pagaidiet... kas?

Kļūda par miljardu dolāru

Iedomājieties kodu bāzi, kurā nav jāuztraucas par nulles drošību. Iedomājieties, ka vienkārši uzskatāt par pašsaprotamu, ka katra atsauce patiešām satur kaut ko nozīmīgu. Iedomājieties, ka esat pārliecināts, ka visas ar nulli saistītās problēmas ir atrisinātas jau iepriekš.
Iztēlojieties, ka vairs ne. Visas Kotlin atsauces pēc noklusējuma nav nulles. Ja vēlaties, lai tās būtu nullei pieejamas, jums ir nepieciešams apzināti pieņemt šo lēmumu un nepārprotami norādīt to kods:

 var s: string? = null

Es saprotu, ka šobrīd jūs, iespējams, esat skeptiski noskaņoti pret šo ideju. Jūs esat pieraduši pie nulles atsaucēm. Kodēšanas laikā jūs to paturat prātā. Jūs uzzinājāt, kur jums jābūt uzmanīgiem. Tieši tādas ir manas domas. Nākot no Java, sākumā tā patiešām šķita dīvaina. Piemēram, kāda ir jēga? Tas neļaus maģiski pazust visām saistītajām problēmām. Man vienkārši visur būs jāpievieno “?”, izklausās pēc pienākuma.

Bet es nolēmu ienirt dziļāk valodā, vai ne? Ļaujiet, lai ir jūsu ceļš, mister Kotlin. Es sāku censties likvidēt pēc iespējas vairāk nulles mainīgo, lauku un parametru. Soli pa solim es iemācījos izmantot valodas iespējas, kas atviegloja nullei pielietojamo atsauču novēršanu, piemēram, drošā izsaukuma “?.” operatoru, elvis “?:” operatoru, deleģētās īpašības, “let” metodi un citas.

Laika gaitā man izdevās panākt, ka dažas klases satur tikai tādus laukus un metožu parametrus, kas nav nulles. Būtībā es zināju, ka tad, ja klase ir veiksmīgi instancēta, es gandrīz varu aizmirst par nulles iespēju metodes ķermenī. Tā bija svētlaime. Ar laiku es to novērtēju arvien vairāk un vairāk. Tomēr galu galā es par to nedomāju kā par slepkavniecisku funkciju, Java joprojām jutās kā mājās. Līdz...

Atgriešanās

Projekts tuvojās noslēgumam. Es arvien vairāk iepazinu Kotlin, un, pateicoties šīm zināšanām, kods kļuva arvien sakoptāks, lasāmāks un kodolīgāks. Uzlabojumus varēja pamanīt ar neapbruņotu aci izmaiņu vēsturē. Taču beidzot pienāca laiks. Ar negaidīti mīļām atmiņām par jauno valodu bija pienācis laiks atvadīties un atgriezties saldajā komforta zonā Java. Vismaz es tā domāju.

Vai jūs pazīstat to sajūtu, kad sākat kaut ko novērtēt tieši tajā brīdī, kad tas pazudis? Kad jūs nesaprotat, cik ļoti uz kaut ko paļaujaties, līdz brīdim, kad vairs nevarat to izmantot? Tas bija vislabākais šīs sajūtas piemērs, kādu es, iespējams, jebkad dzīvē esmu piedzīvojis.

Kad es atgriezos pie koda rakstīšanas Java, mani gandrīz biedēja dažu funkciju trūkums. Bija tā, it kā manas smadzenes zemapziņā būtu nepareizi ieviesušas Kotlin funkcijas Java. Es piedzīvoju situācijas, kad es patiešām sāku kaut ko īstenot, lai saprastu, ka šajā valodā tas nedarbosies. Labākajā gadījumā es to varētu uzrakstīt Kotlin līdzīgi, bet tas būtu apjomīgs, nelasāms un/vai prasītu pārāk daudz boilerplate.

Nulles drošība, protams, bija funkcija, kuras man pietrūka visvairāk. Taču mani pārsteidza, cik daudz mazāku lietu man kļuva pašsaprotamas: nosaukti parametri, īpašības getteru un setteru vietā, “==” kā equals un “===” kā atsauces vienlīdzība, kvalificēts “this”, paplašinājuma funkcijas, netiešais vienskaitļa lambda parametrs, “_” neizmantotiem lambda parametriem, dati klases, darbības jomas funkcijas, citas Kotlin stdlib funkcijas, operatori un citas. Un tas, kā tas viss labi sader kopā. Salīdzinājumā Java šķita... primitīva.

Patiesībā es jutos tik slikti, ka sāku apsvērt iespēju vispār pāriet uz Kotlin. Teorētiski tā ir pilnībā savietojama ar Java, jūs varat vienkārši pievienot Kotlin atbalstu esošajam projektam un sākt rakstīt jaunas klases. Kotlin puse zina, kā “sarunāties” ar Java, un Java puse pat nezina, ka tā “sarunājas” ar citu valodu. Un pēc kompilēšanas uz baitikodi JVM tas īsti neko nemaina.

Realitātes pārbaude

Tātad, ko jūs vēl gaidāt? Ja valoda ir tik laba, kā jūs sakāt, vienkārši izmantojiet to! Varbūt tomēr ne jau esošajos projektos, es zinu, ka tai vajadzētu būt savietojamai, bet divu dažādu valodu sajaukšana šādā veidā izklausās neglīti.

Labi, tātad jaunajiem moduļiem - Kotlin. Vai arī tā ir? Jūs strādājat komanda. Jums ir jākonsultējas ar viņiem un jāpārliecina viņus par šīs jaunās valodas lielumu. Ko? Viņiem tā nepatīk? Izklausās, ka viņi vienkārši nevēlas pielikt pūles, lai to apgūtu. Taču jūs nevarat viņus vainot, arī jūs sākumā bijāt skeptiski noskaņots.

Projekta vadītājs! Jā! Viņš noteikti sapratīs, cik lielu vērtību Kotlin varētu dot mūsu team. Ak, tas lielums, kas nāks!
-No
-Pagaidiet, kāpēc?
-team to nezina.
-Viņi mācīsies!
-Viņi nevēlas mācīties.
-Tu var pagatavot!
-Viņiem nav jāmācās.
-Tas ir taisnība, bet padomājiet par iespējām!
-Ja, bet vispirms padomājiet par problēmām.

Leģenda vēsta, ka pastāv projekts. Projekts, kas ir liels un sarežģīts, bet skaisti uzrakstīts visās tā daļās. Projekts, kurā visi izstrādātāji ir vienisprātis par izmantotajiem risinājumiem. Kur jaunas funkcionalitātes vienmērīgi plūst no programmētāju klaviatūrām. Kur kļūdas ir reti sastopamas un viegli novēršamas.

Vai esat redzējuši šādu projektu? Neesmu redzējis. Daži bija tuvu tam, bet lielākā daļa no tiem ir liels mantots koda haoss. Un, ja nav, tad, visticamāk, kādreiz nākotnē par tādu kļūs. Tagad iedomājieties, ka šajā maisījumā tiek izmantota vēl viena valoda. Tā ievieš jaunus veidus, kā pieļaut kļūdas. Tā prasa, lai izstrādātāji zinātu, ko viņi dara. Tas ir, maigi izsakoties, risks.

Tagad ņemiet vērā arī izstrādātājs rotācija. Cilvēki nāk un aiziet. Vai jūs liksiet katram jaunajam izstrādātājam apgūt pilnīgi jaunu valodu? Nē, tas ir neproduktīvi. Vai jūs vispirms pieņemsiet Kotlin izstrādātājus? Veiksmi ar to, jo nolīgt labu Java izstrādātāju ir pietiekami grūti.

Cilvēki ir mēģinājuši. Man jāsaka, ka es nepiekrītu lielākajai daļai apgalvojumu šajā rakstā. Tur ir pamatota kritika, bet es domāju, ka viņi nav pietiekami daudz izmantojuši Kotlin, lai patiešām saprastu “Kotlin veidu”. Daudzi komentētāji zem šī raksta, šķiet, domā līdzīgi.

Tomēr tam nav nozīmes. Varu derēt, ka tas notiktu arī jūsu projektā. “Izmēģināju, nepatika”. Jūs neliksiet viņiem tam veltīt vairāk laika. Jūs neliksiet viņiem mēģināt vēlreiz. Jūs nepiespiedīsiet viņus dot tam vēl vienu iespēju. Un no praktiskā viedokļa viņiem var būt taisnība. Java ir tik populārs, ka jebkāda cita JVM lietojuma izmantošana šķiet lieka.

Kāpēc tad šis raksts?

Jūs tikko pavadījāt ievērojamu laiku, rakstot rakstu, kuram, šķiet, nav jēgas. Kāpēc man būtu jāmēģina mācīties valodu, ja jūs sakāt, ka tas tik un tā ir bezjēdzīgi?

Es nedomāju, ka tas ir bezjēdzīgi. Es joprojām domāju, ka Kotlin ir lieliska. Es joprojām vēlos to izmantot (un es to izmantoju savos privātajos projektos). Ja es varētu, es vienkārši pārietu uz to un aizmirstu par Java ierobežojumiem. Bet pašreizējā realitāte saka, ka es nevaru. Un es vēlos mēģināt to mainīt.

Mans nodoms jums, dārgais lasītāj, ir vismaz apsvērt iespēju iziet no mājīgās Java komforta zonas. Jo varbūt, tikai varbūt, jums Kotlin patiks tikpat ļoti kā man. Un, ja tā, tad tas ir vēl viens Kotlin pārzinošs izstrādātājs uz tirgus.

Lasīt vairāk:

Labākais Java projektu veids

3 biežāk sastopamie programmatūras produktu izstrādes izaicinājumi jaunuzņēmumiem

Pareizais veids, kā atrast labākos Java izstrādātājus