Java vs Kotlin vs ... pro aplikace pro Android

[Phi]

Jak už někdo podotkl, taky se dá počkat, až ty ověřené vlastnosti dorazí do Javy.

nedorazí, protože by rozbily zpětnou kompatibilitu.

Ocividne nechapete zpetnou kompatibilitu u Javy

Třeba omezení jedna veřejná třída na soubor z Javy nejspíš nikdy nezmizí. To není moc slučitelné s data classes a funkcemi, které by nebyly součástí tříd. Navíc by takové změny asi narazily na odpor u části komunity.

Ekvivalent data classes i extension methods jsou v Project Lombok roky. V podstatě jde o totéž, akorát Kotlin je přímo podporován v IDE zatímco Lombok si člověk musí obstarat sám. Osobně mi Lombok jako PoC toho, jak vykrást Kotlin stačí. Ale nedělám v Oracle, tak se třeba pletu.
Kotlin asi bude mít hezčí syntax, ale to je tak vše.

[Reklama]

[Radek Miček]

Ekvivalent data classes i extension methods jsou v Project Lombok roky. V podstatě jde o totéž, akorát Kotlin je přímo podporován v IDE zatímco Lombok si člověk musí obstarat sám. Osobně mi Lombok jako PoC toho, jak vykrást Kotlin stačí. Ale nedělám v Oracle, tak se třeba pletu.
Kotlin asi bude mít hezčí syntax, ale to je tak vše.

Kotlin má navíc pojmenované argumenty (builder v Lomboku je dost slabá náhrada) a korutiny (pro psaní asynchroního kódu). Plus, jak říkáte, hezčí syntax, díky níž je kód mnohem přehlednější.

Možná pomůže, prezentace o Kotlinu, kterou jsem dělal v Skliku, když náš tým přecházel s jedním projektem na Kotlin (předtím jsem používali Javu s Lombokem).

[MarSik]

Pojmenované argumenty v konstruktoru a safe null operátor jsou moc pěkná vylepšení.

Hezčí syntax je subjektivní, protože Kotlin (stejně jako Go) vsadil na Pascalovské konvence, což je celkem velká změna oproti C/Java. Stejně tak pokusy o co nejméně závorek. Někdy se to pak hůře čte.

[gll]

Pojmenované argumenty v konstruktoru a safe null operátor jsou moc pěkná vylepšení.

Hezčí syntax je subjektivní, protože Kotlin (stejně jako Go) vsadil na Pascalovské konvence, což je celkem velká změna oproti C/Java. Stejně tak pokusy o co nejméně závorek. Někdy se to pak hůře čte.

Protože je taková syntax čitelnější. Původní C nepředpokládalo, že se někdy budou používat názvy generik s 50 a více znaky. Vynechání závorek umožňuje zápis podobný Ruby blokům, ale mocnější.

v tomto kódu

Kód: [Vybrat]

UI {
    editText {
        hint = "Name"
    }
}

byste asi nechtěl všude psát ({ a }) .

[MarSik]

Kód: [Vybrat]

UI {
    editText {
        hint = "Name"
    }
}


No a to tom právě mluvím. Čistě z tohoto úryvku neni naprosto jasné, co to vlastně je. Třída s metodou? Lambda předaná nějaké funkci (vnořeně)? Neříkám, že všechny závorky jsou nutné, ale ne všechny se také dají vypustit.

Třeba v prezentaci p. Míčka mi poslední změna už čitelnější nepřijde (složené závorky + return -> rovnítko).

[Reklama]

[gll]

Kód: [Vybrat]

UI {
    editText {
        hint = "Name"
    }
}


No a to tom právě mluvím. Čistě z tohoto úryvku neni naprosto jasné, co to vlastně je. Třída s metodou? Lambda předaná nějaké funkci (vnořeně)? Neříkám, že všechny závorky jsou nutné, ale ne všechny se také dají vypustit.

Třeba v prezentaci p. Míčka mi poslední změna už čitelnější nepřijde (složené závorky + return -> rovnítko).

Kdybyste Kotlin alespoň minimálně znal, bylo by vám to na první pohled jasné.

[MarSik]

Kdybyste Kotlin alespoň minimálně znal, bylo by vám to na první pohled jasné.

To je ovšem naprosto zcestný argument. Ten samý totiž mohou použít (a používali) například i vývojáři v Perlu nebo Haskellu a neudělá to z Perlu čitelný a příjemný jazyk. Lidská řeč je také redundantní [1] a to z dobrého důvodu [2]. Nevidím důvod, proč jít do extrému v minimalizaci zbytečných znaků. Většinu času jako programátor totiž trávím čtením (i např mírně neznámých jazyků). Takže alespoň minimální kontext mi umožnuje se lépe soustředit. A proto ne všechno nové je automaticky lepší. Kompresi ať si dělá překladač.

PS: Jelikož tam nebylo žádné fun ani class, tak to nejspíš byly opravdu vnořené lambdy, ale to nebylo podstatné pro moji poznámku. Otázkou totiž je, proč v tomto případě nevypustit naopak ty složené závorky. "Skoro standardní Java" by vypadala například takto (a všimněte si, že to pořád na první pohled je volání funkce):

Kód: [Vybrat]

UI(() -> editText(hint = "Name"))
[1] https://en.wikipedia.org/wiki/Pleonasm

[2]

"Further, pleonasm can serve as a redundancy check: If a word is unknown, misunderstood, or misheard, or the medium of communication is poor—a wireless telephone connection or sloppy handwriting—pleonastic phrases can help ensure that the entire meaning gets across even if some of the words get lost."

[v]

Kdybyste Kotlin alespoň minimálně znal, bylo by vám to na první pohled jasné.

To je ovšem naprosto zcestný argument. Ten samý totiž mohou použít (a používali) například i vývojáři v Perlu nebo Haskellu a neudělá to z Perlu čitelný a příjemný jazyk. Lidská řeč je také redundantní [1] a to z dobrého důvodu [2]. Nevidím důvod, proč jít do extrému v minimalizaci zbytečných znaků. Většinu času jako programátor totiž trávím čtením (i např mírně neznámých jazyků). Takže alespoň minimální kontext mi umožnuje se lépe soustředit. A proto ne všechno nové je automaticky lepší. Kompresi ať si dělá překladač.

PS: Jelikož tam nebylo žádné fun ani class, tak to nejspíš byly opravdu vnořené lambdy, ale to nebylo podstatné pro moji poznámku. Otázkou totiž je, proč v tomto případě nevypustit naopak ty složené závorky. "Skoro standardní Java" by vypadala například takto (a všimněte si, že to pořád na první pohled je volání funkce):

Kód: [Vybrat]

UI(() -> editText(hint = "Name"))
[1] https://en.wikipedia.org/wiki/Pleonasm

[2]

"Further, pleonasm can serve as a redundancy check: If a word is unknown, misunderstood, or misheard, or the medium of communication is poor—a wireless telephone connection or sloppy handwriting—pleonastic phrases can help ensure that the entire meaning gets across even if some of the words get lost."

to je jak z havlova Vyrozumění

[gll]

Kdybyste Kotlin alespoň minimálně znal, bylo by vám to na první pohled jasné.

To je ovšem naprosto zcestný argument. Ten samý totiž mohou použít (a používali) například i vývojáři v Perlu nebo Haskellu a neudělá to z Perlu čitelný a příjemný jazyk. Lidská řeč je také redundantní [1] a to z dobrého důvodu [2]. Nevidím důvod, proč jít do extrému v minimalizaci zbytečných znaků. Většinu času jako programátor totiž trávím čtením (i např mírně neznámých jazyků). Takže alespoň minimální kontext mi umožnuje se lépe soustředit. A proto ne všechno nové je automaticky lepší. Kompresi ať si dělá překladač.

PS: Jelikož tam nebylo žádné fun ani class, tak to nejspíš byly opravdu vnořené lambdy, ale to nebylo podstatné pro moji poznámku. Otázkou totiž je, proč v tomto případě nevypustit naopak ty složené závorky. "Skoro standardní Java" by vypadala například takto (a všimněte si, že to pořád na první pohled je volání funkce):

Kód: [Vybrat]

UI(() -> editText(hint = "Name"))
[1] https://en.wikipedia.org/wiki/Pleonasm

[2]

"Further, pleonasm can serve as a redundancy check: If a word is unknown, misunderstood, or misheard, or the medium of communication is poor—a wireless telephone connection or sloppy handwriting—pleonastic phrases can help ensure that the entire meaning gets across even if some of the words get lost."

Kdybyste věnoval 30 minut pročtení tutorialu, tak by vám to bylo jasné. Je to volání funkcí, jejichž jediný parametr je lambda. Pokud je lambda poslední parametr, lze ji zapsat za závorky. Pokud je lambda jediný parametr, lze závorky vynechat.

https://kotlinlang.org/docs/reference/lambdas.html

In Kotlin, there is a convention that if the last parameter to a function is a function, and you're passing a lambda expression as the corresponding argument, you can specify it outside of parentheses:

[gll]

PS: Jelikož tam nebylo žádné fun ani class, tak to nejspíš byly opravdu vnořené lambdy, ale to nebylo podstatné pro moji poznámku. Otázkou totiž je, proč v tomto případě nevypustit naopak ty složené závorky. "Skoro standardní Java" by vypadala například takto (a všimněte si, že to pořád na první pohled je volání funkce):

Kód: [Vybrat]

UI(() -> editText(hint = "Name"))

jsou tam dvě lambdy

Kód: [Vybrat]

UI(() -> editText(() -> hint = "Name"))

ale nefungovalo by to, protože v kontextu té vnitřní lambdy neexistuje členská proměnná hint.

[gll]

v Javě nede volat lambdu s receiverem.

https://kotlinlang.org/docs/reference/lambdas.html#function-literals-with-receiver

[gll]

v Javě nede volat lambdu s receiverem.

https://kotlinlang.org/docs/reference/lambdas.html#function-literals-with-receiver

*nejde

[PetrN]

gll

Kdybyste Kotlin alespoň minimálně znal

Kdybyste věnoval 30 minut pročtení tutorialu

Člověče, to je samé "kdybyste" - takto to prostě nefunguje, když k Vám do obchodu příjde zákazník a řekne Vám, že už k Vám nepříjde, protože u Vás nenašel čerstvé pečivo a Vy byste odvětil: "Kdybyste věnoval 10 minut k vyšplhání nahoru na regál, tak byste to čerstvé pečivo našel ...", tak to asi nevyřešíte. Jak psal někdo přede mnou, kolikrát musíte číst kód i z jazyků, které neznáte, často čtete kód někoho, koho jste nikdy neviděl a prostě oceníte přehlednost a jednoznačnost kódu.

anonym

To je jak ty žumpy co používají Eclipse protože nejsou schopni dát ani 4000,-/ročně za Ideu.

Krásná startovací věta pro flame war, kde ovšem, pokud se podívate na různé flame wary rozhodně vyhrává eclipse (ať už přehledností, náročností na paměť nebo rychlostí). A kdoví jak by to bylo, kdyby dal Google přednost eclipse pro vytvoření Android studia (a je nám asi všem jasné, že zde nehrála roli kvalita nástroje, ale jiné důvody).

[gll]

gll

Kdybyste Kotlin alespoň minimálně znal

Kdybyste věnoval 30 minut pročtení tutorialu

Člověče, to je samé "kdybyste" - takto to prostě nefunguje, když k Vám do obchodu příjde zákazník a řekne Vám, že už k Vám nepříjde, protože u Vás nenašel čerstvé pečivo a Vy byste odvětil: "Kdybyste věnoval 10 minut k vyšplhání nahoru na regál, tak byste to čerstvé pečivo našel ...", tak to asi nevyřešíte. Jak psal někdo přede mnou, kolikrát musíte číst kód i z jazyků, které neznáte, často čtete kód někoho, koho jste nikdy neviděl a prostě oceníte přehlednost a jednoznačnost kódu.

tak to ve slušných diskuzích funguje. Když o tématu vím hovno, tak držím hubu. Tazatel asi nechce znát názory lidí, kteří si ani nepřečetli tutorial. Natož aby v tom něco programovali.

[PetrN]

tak to ve slušných diskuzích funguje. Když o tématu vím hovno, tak držím hubu. Tazatel asi nechce znát názory lidí, kteří si ani nepřečetli tutorial. Natož aby v tom něco programovali.

No, myslím, že první odpověď na otázku v tomto vlákně byla ta správná:

Předně bych doporučoval jazyk, který umí vaši programátoři.

pak už je to jen zabředávání do konstrukcí jazyka, které jsou zcela bezvýznamné.

Pokud na základě nějaké flame war diskuze budu nutit svého Java programátora, aby to udělal v Kotlinu a naopak (aby člověk, kterému vyhovuje Kotlin to psal v Javě), pak je asi něco špatně.