Fórum Root.cz
Hlavní témata => Vývoj => Téma založeno: Aldik 21. 11. 2017, 14:08:11
-
Ahoj, přemýšlíme ve firmě o přepsání jedné aplikace, která je naprogramována pomocí JQM, Phonegap, Typescript (jako hybridní). Aplikace se nakonec používá výhradně jen na Androidu, takže uvažujeme nad výše napsanými jazyky (i když poslední info ohledně přispívání Google do Swiftu vypadá také velmi zajímavě) Jaký jazyk - platformu - by jste dnes použili pro novou aplikaci pro Android? Jedná se o komerční aplikaci (byď není na Google Play), takže QT odpadá (což mě osobně mrzí).
Díky za názory
-
Proč odpadá Qt? Je LGPL (s omezeními lze používat i komerčně) i Qt Commercial (za peníze).
Předně bych doporučoval jazyk, který umí vaši programátoři.
-
No to je zase firma k pohledání, když ani neumí zaplatit nástroje pro vývoj. Proč si furt všichni myslí, že sw má být zadarmo? QT je kvalití knihovna, lepší než nějaká Java nebo Kotlin. To je jak ty žumpy co používají Eclipse protože nejsou schopni dát ani 4000,-/ročně za Ideu.
Qt je placené jen v určitých případech, tuším že pokud ti stačí použít již zkompilované knihovny z Qt, je to zadara. Nevýhoda je, že o to větší ta appka bude, protože musíš tahat celé knihvny, ikdyž z nich použiješ jen Fň.
-
Určitě raději Kotlin, osobně bych zkusil Flutter od Google. Produktivita by mohla být ještě lepší než s Kotlinem. Poslední dobou jsou na něj jen kladné ohlasy - https://hackernoon.com/what-are-we-doing-with-googles-flutter-74ff29dd256a a pojede vám to bez větších problémů i na jabku.
-
Pouzil by som Javu, nie je to ezotericky jazyk, lahsie sa na to zhanaju developeri.
-
Já bych zvolil Javu. Kotlin obsahuje spoustu „cukrátek“, každý si bude chtít něco vyzkoušet a skončíte s kódem, který bude plný míst, o kterých většina programátorů nebude vědět, co vlastně znamenají. Pro využívání takovéhoto jazyka je podle mne potřeba velká disciplína a někdo s velkými zkušenostmi, kdo rozhodne, co se bude používat a co ne. A obávám se, že takovýchhle lidí s dostatečnou zkušeností s Kotlinem bude dnes jen velmi málo, prakticky jen vývojáři JetBrains a pár dalších.
-
To je jak ty žumpy co používají Eclipse protože nejsou schopni dát ani 4000,-/ročně za Ideu.
To je blbost, neni to tak, ze by sa jednalo iba o platenie. Eclipse je de facto standard - ked riesis nejaky problem s IDE, najdes na to ovela viac tipov pre Eclipse, ako pre Ideu... a pre mna je Idea aj moc komplikovana ... je to vec preferencii ... ja osobne uprednostnujem Eclipse.
-
Nezavadel bych do firmy novou technologii jen kvůli jedné aplikaci. Takže bych se zeptal sám sebe, jestli tedy budete v tom zvoleném jazyku vyvíjet i něco dalšího.
A souhlasím s názorem, že Javistu seženete snadněji než Kotlinistu. Takže má Kotlin nějakou killer feature, kvůli které půjdete proti proudu? Já o žádné takové nevím.
-
Eclipse je de facto standard
Bejvavalo. V roce 2016 to bylo cca 48% vs 43% ve prospěch Eclipse, letos už v některých průzkumech Intellij vede. Zřejmě máme tedy standardy dva a něco napoví i fakt, že Android Studio přešlo z Eclipse na Intellij, asi tak před 3 nebo 4 lety.
-
Nezavadel bych do firmy novou technologii jen kvůli jedné aplikaci. Takže bych se zeptal sám sebe, jestli tedy budete v tom zvoleném jazyku vyvíjet i něco dalšího.
A souhlasím s názorem, že Javistu seženete snadněji než Kotlinistu. Takže má Kotlin nějakou killer feature, kvůli které půjdete proti proudu? Já o žádné takové nevím.
Proti proudu je dnes spíš používání Javy 7 než Kotlinu.
-
Ale Android už dnes má podporu Java 8 - https://developer.android.com/studio/write/java8-support.html
-
Proti proudu je dnes spíš používání Javy 7 než Kotlinu.
A přestat používat statickou analýzu a mockito je co? Tyhle věci před půl rokem s Kotlinem moc nejeli (jestli teď, to nevím)
Java 8 už na Androidu je.
Možná bych se víc zaměřil na ekosystém kolem jazyka než na ty syntaktické bonbonky které Kotlin oproti Javě nabízí. Za 2 roky to možná bude jasná volba, v tuhle chvíli ne.
-
To je jak ty žumpy co používají Eclipse protože nejsou schopni dát ani 4000,-/ročně za Ideu.
To je blbost, neni to tak, ze by sa jednalo iba o platenie. Eclipse je de facto standard - ked riesis nejaky problem s IDE, najdes na to ovela viac tipov pre Eclipse, ako pre Ideu... a pre mna je Idea aj moc komplikovana ... je to vec preferencii ... ja osobne uprednostnujem Eclipse.
Nerikej co preferujes, kdyz vis prd. Problem s IDE resis na Eclipsu furt, ne na Idei, ta totiž fachá. Co se týče funkcionality, tak Idea nemá víc nástrojů než Eclipse, je to úplně to samé. To co jsi napsal je totální hovadina.
-
Konzervativně použít standardní “vanilla” nástroje pro platformu doporučené jejim výrobcem bez dalšich udělátorů a pomocníčků. Nejste asi výzkumný ustav nebo testovací laboratoř programovacích nástrojů dle posledních trendů na trendy blozích a cílem je předpokládám primárně spolehlivá a dlouhodobě udržovatelná aplikace.
-
To je jak ty žumpy co používají Eclipse protože nejsou schopni dát ani 4000,-/ročně za Ideu.
To je blbost, neni to tak, ze by sa jednalo iba o platenie. Eclipse je de facto standard - ked riesis nejaky problem s IDE, najdes na to ovela viac tipov pre Eclipse, ako pre Ideu... a pre mna je Idea aj moc komplikovana ... je to vec preferencii ... ja osobne uprednostnujem Eclipse.
Nerikej co preferujes, kdyz vis prd. Problem s IDE resis na Eclipsu furt, ne na Idei, ta totiž fachá. Co se týče funkcionality, tak Idea nemá víc nástrojů než Eclipse, je to úplně to samé. To co jsi napsal je totální hovadina.
He?
Osobne Eclipse hatery nechapu.
V soucasnosti se eclipse/idea/netbeans nepouzivaji na nic jineho, nez jako editor a frontend pro maven/gradle a git.
Pravda, v eclipse je obcas potreba zmackout ALT+F5 na obcerstveni maven projektu, jinak je to uplne u zadeke.
-
Ahoj, díky všem za názory, pravděpodobně to bude Java. Co se týče QT, není to o tom, že bychom si mysleli, že - Proč si furt všichni myslí, že sw má být zadarmo - by sw měl být zadarmo, ale spíše o menších zkušenostech kolegů s tímto frameworkem. Přiznám se, že jsem ani nevěděl o možnosti ho použít pro komerční aplikaci ve free verzi.
-
A přestat používat statickou analýzu a mockito je co?
statická analýza je podle vás co? Třeba null safety?
-
Ahoj, díky všem za názory, pravděpodobně to bude Java. Co se týče QT, není to o tom, že bychom si mysleli, že - Proč si furt všichni myslí, že sw má být zadarmo - by sw měl být zadarmo, ale spíše o menších zkušenostech kolegů s tímto frameworkem. Přiznám se, že jsem ani nevěděl o možnosti ho použít pro komerční aplikaci ve free verzi.
Já bych se na takovýhle dotaz možná zeptal někde jinde, kde mají s vývojem pro Android a Kotlinem praktické zkušenosti, ne na linux fóru, kde vám namísto toho doporučí věci jako je Qt anebo aspoň zůstat u 10 let starých technologií a nástrojů. Odmítat Kotlin jakožto nový, ezoterický a neozkoušený jazyk může leda tak někdo, kdo ho v praxi vůbec nepoužil. První vývojáři v něm začali vyvíjet už tak 2 roky zpátky a před půl rokem dostal plnou podporu od Googlu (a ve stejné době mimochodem i od Spring frameworku).
Myslím si, že velká většina lidí, která ho měla šanci použít, se už k Javě vrátit vůbec nechce. Kotlin oproti Javě přináší sice jen "drobné bonbónky", ale je jich tolik, že ve výsledku vývoj mnohonásobně usnadní. Kód je mnohem stručnější, čitelnější, typově bezpečnější, a navíc nejde jenom o vylepšení jazyka, ale díky extension metodám jde snadno vylepšit práci s řadu hrozivých androidích API, se kterými se při použití Javy prostě nic udělat nedá. Například přímo Jetbrains vyvíjejí knihovnu, která dokáže nahradit všechna ta příšerná layout xmlka staticky typovaným DSL:
https://github.com/Kotlin/anko
Někdo tu zmiňoval Javu 8, ale ta jednak nesnese s Kotlinem srovnání, a jednak je plně podporovaná až někdy od Andoidu 6 nebo kolik, takže pokud chce člověk cílit na celý současný trh, tak má stejně smůlu. Je možná pravda, že u Kotlinu zatím neexistuje tolik best practices a lidí, kteří jej znají, taky není moc, ale průměrný Javista je schopný v něm efektivně kódit už po několika dnech. Navíc není třeba používat všechny parádičky, i když v Kotlinu budete "psát Javu", tak daný kód bude stejně vypadat mnohem lépe. A pokud by něco byl opravdu problém, můžu napsat danou funkcionalitu přímo v Javě, kombinování obou jazyků v jednom projektu je triviální. A naopak, není problém novou funkcionalitu do existujícího projektu začít psát v Kotlinu.
-
Odmítat Kotlin jakožto nový, ezoterický a neozkoušený jazyk může leda tak někdo, kdo ho v praxi vůbec nepoužil.
"Někdo" považuje kotlin za ďaľší módny výstrelok. Ešte donedávna bol takto tlačený frikulínmi groovy, potom scala, potom zasa tento kotlin. Mozgová kapacita sa dá využiť lepšie, než sa učiť každú chvíľu nový jazyk. Osobne si počkám až sa featury z kotlinu dostanú do javy. Pre kotlin by ma presvedčilo, ak by sa ho podarilo presadiť v korporáte, pričom by bola garantovaná kontinuita. Takto kto vie. Dnes napíšete v kotline, o dva roky zasa môžete prepisovať do niečoho viacej cool.
-
Dnes napíšete v kotline, o dva roky zasa môžete prepisovať do niečoho viacej cool.
No a co, pohrál jsem si, přepis přece zaplatí někdo jiný.... klasika.
-
Dnes napíšete v kotline, o dva roky zasa môžete prepisovať do niečoho viacej cool.
No a co, pohrál jsem si, přepis přece zaplatí někdo jiný.... klasika.
Zase zde plivete špínu na něco, o čem nic nevíte.
-
Možná nemám zkušenosti s Kotlinem, ale na druhou stranu vím, jaké je to udržovat a rozvíjet dlouhodobý projekt (> 15 let) financovaný čistě ze svých výnosů, na kterém se průběžně střídají vývojáři.
-
Původní tazatel se ale ptal, v čem vyvíjet aplikace pro Android. Myslíte, že ji bude udržovat ještě za 15 let? To je mimochodem zhruba tak doba, kdy se fíčury z Kotlinu dostanou do Javy.
-
15 let nevím, ale 5 let klidně - přidávat funkce, updatovat na nové verze androidu atd. Samozřejmě pokud nejde o jednorázové zadání a nazdar. Třeba takové ovládací appky k drahým hifi přístrojům - tam bych čekal dostupnost aktualizovaných verzí i víc, než 5 let.
Na druhou stranu je pěkné, že kotlin vyžaduje jen javu 6 a je tudíž kompatibilní i se starými androidy. Pro ty bych v javě 6 už psát nechtěl.
-
15 let nevím, ale 5 let klidně - přidávat funkce, updatovat na nové verze androidu atd. Samozřejmě pokud nejde o jednorázové zadání a nazdar. Třeba takové ovládací appky k drahým hifi přístrojům - tam bych čekal dostupnost aktualizovaných verzí i víc, než 5 let.
Co tím chcete říct? Vy věříte, že na budoucích verzích Androidu Kotlin nebude podporován?
-
Co tím chcete říct? Vy věříte, že na budoucích verzích Androidu Kotlin nebude podporován?
To asi bude, když kompiluje pro JVM. Ale bude ještě někoho zajímat? V klasickém cyklu Představení - Hype - Vystřízlivění - Běžný provoz je Kotlin momentálně ve fázi Hype.
Jak už někdo podotkl, taky se dá počkat, až ty ověřené vlastnosti dorazí do Javy.
-
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.
-
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
-
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.
-
Více veřejných tříd na soubor je feature, který mě až tak nezajímá. Při vývoji v IDE nepracuji primárně se soubory, ale s třídami. Navíc si snázeji v editoru otevřu dvě třídy vedle sebe, když jsou každá ve svém souboru, než mít jeden soubor otevřený dvakrát (jde, ale mate to). Navíc čím kratší soubor, tím je to pro mě příjemnější a navíc to mírně snižuje riziko kolize v GITu s ostatními vývojáři. Vyhýbám se tomu i v Pythonu.
Ale Kotlin má jiné featury, které vypadají příjemně (omezení na null v typech, funkční typy vs. SAM, dotaženější generika). To vše se do javy může postupně dostat.
-
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.
-
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 (https://github.com/radekm/notes-cs/blob/master/2017/Kotlin.pdf), 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).
-
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.
-
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
UI {
editText {
hint = "Name"
}
}
byste asi nechtěl všude psát ({ a }) .
-
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).
-
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é.
-
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):
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 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):
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í :))
-
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):
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:
-
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):
UI(() -> editText(hint = "Name"))
jsou tam dvě lambdy
UI(() -> editText(() -> hint = "Name"))
ale nefungovalo by to, protože v kontextu té vnitřní lambdy neexistuje členská proměnná hint.
-
v Javě nede volat lambdu s receiverem.
https://kotlinlang.org/docs/reference/lambdas.html#function-literals-with-receiver
-
v Javě nede volat lambdu s receiverem.
https://kotlinlang.org/docs/reference/lambdas.html#function-literals-with-receiver
*nejde
-
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
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.
-
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ě.
-
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ě.
Znovu. Tohle je diskuze o Kotlinu. Když o tématu nic nevíte, tak se nevyjadřujte. Pouze zaplevelujete diskuzi.
-
Znovu. Tohle je diskuze o Kotlinu. Když o tématu nic nevíte, tak se nevyjadřujte. Pouze zaplevelujete diskuzi.
Úvodní dotaz mi nepřijde jako diskuse pouze o Kotlinu...
-
Znovu. Tohle je diskuze o Kotlinu. Když o tématu nic nevíte, tak se nevyjadřujte. Pouze zaplevelujete diskuzi.
Úvodní dotaz mi nepřijde jako diskuse pouze o Kotlinu...
já jsem reagoval na příspěvky hloupě kritizující Kotlin bez znalosti problematiky. Včetně toho vašeho.
No a co, pohrál jsem si, přepis přece zaplatí někdo jiný.... klasika.
-
já jsem reagoval na příspěvky hloupě kritizující Kotlin bez znalosti problematiky. Včetně toho vašeho.
Přísvěvek hloupě kritizující Kotlin by zněl asi takto: "Kotlin je jen nesmyslný fork Javy vytvořen jedním subjektem na truc druhému subjektu". A takový a podobné zde v diskuzi, pokud vím, nepadly.
-
já jsem reagoval na příspěvky hloupě kritizující Kotlin bez znalosti problematiky. Včetně toho vašeho.
Přečti si ještě jednou, na co se tazatel ptá - co zvolit pro vývoj aplikace. A o tom ty příspěvky jsou, ne o detailech kotlinu.
-
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.
Opravdu? První věta je: "Přemýšlíme ve firmě..". A z mého pohledu jsou pro použití nějaké technologie důležité i jiné věci než jak přijemný je daný syntaktický cukr a kolik řádku jste v tom jazyce už napsal. Například:
- kolik je volných programátorů na trhu
- jaké je množství dokumentace a zkušeností ze kterých můžu čerpat
- jak rychle přeškolím svoje lidi
- jak bude probíhat code-review a spolupráce s ostatními týmy, které ten jazyk pořádně (nebo vůbec) neznají
- jak moc budou moji programátoři dělat chyby
- obzvláště když budou psát v novém jazyce a zároveň udržovat dalších N projektů v jazyce Y
- bude team-lead rozumět tomu co jeho lidi dělají?
To všechno jsou body, u kterých narazíte na to, že lidé v tom jazyce aktivně nepíší, ten tutorial nečetli, a nebo četli už před nějakou dobou. A stejně s nimi musíte spolupracovat.
Takže správná odpověď je opravdu: Připravte se na pomalý a drahý vývoj nebo pište v jazyce, který znáte.
-
Takže správná odpověď je opravdu: Připravte se na pomalý a drahý vývoj nebo pište v jazyce, který znáte.
Takhle genericky to nejde říct. Musíte si ohodnotit každý bod a porovnat plusy/mínusy obou řešení. Investice do učení nového jazyka se mohou vrátit v lepší efektivitě.
Mimochodem Kotlin je jednoduchý na naučení (pár týdnů max) a je dneska jednodušší sehnat Java programátora co chce dělat v Kotlinu a zaučit ho, než shánět samotného Java programátora na "čistou" Javu.
-
Mimochodem Kotlin je jednoduchý na naučení (pár týdnů max) a je dneska jednodušší sehnat Java programátora co chce dělat v Kotlinu a zaučit ho, než shánět samotného Java programátora na "čistou" Javu.
Teď si děláte legraci nebo to myslíte s nadsázkou? To by vlastně znamenalo, že Java programátoři nechtějí programovat v Javě a čekali celý svůj život na to, aby jako Java programátoři mohli programovat v Kotlinu?
"Všechno je postavené na Javě, všichni Java programátoři umí Javu, tak pro jistotu překopeme náš projekt do Kotlinu a všechny naše Java programátory pošleme na školení. Sice nám v konečném efektu Kotlin nepřinese nic nového, ale ať v práci nemáme nudu, protože práce a projekty přeci počkají" ???
-
Mimochodem Kotlin je jednoduchý na naučení (pár týdnů max) a je dneska jednodušší sehnat Java programátora co chce dělat v Kotlinu a zaučit ho, než shánět samotného Java programátora na "čistou" Javu.
Teď si děláte legraci nebo to myslíte s nadsázkou? To by vlastně znamenalo, že Java programátoři nechtějí programovat v Javě a čekali celý svůj život na to, aby jako Java programátoři mohli programovat v Kotlinu?
"Všechno je postavené na Javě, všichni Java programátoři umí Javu, tak pro jistotu překopeme náš projekt do Kotlinu a všechny naše Java programátory pošleme na školení. Sice nám v konečném efektu Kotlin nepřinese nic nového, ale ať v práci nemáme nudu, protože práce a projekty přeci počkají" ???
Na Androidu donedávna nebylo moc na výběr.
-
Me prijde kotlin jako slepa ulicka.
Bezi to nad JVM, takze to logicky nemuze nabidnout nic moc vic, nez syntakticky cukr nad Jawou.
Ktery ostatne casto odstinuje IDE.
Osobne nemam rad ani Lombok, IDE funkce "Generate getters/setters" a "create constructor from fields" udelaji to same, boilerplate je odsunuty na spodek tridy, kde neprekazi.
A kdyz potrebuju strcit debug interceptor do getteru, proste ho tam strcim.
IMHO jedina pekna vec jsou non-null objekty, a korutiny jinak nevidim nic, za co by stalo menit jazyk.
-
Bezi to nad JVM, takze to logicky nemuze nabidnout nic moc vic, nez syntakticky cukr nad Jawou.
Někdo vztah Kotlinu a Javy přirovnává ke vztahu Javascriptu a JQuery
-
Mimochodem Kotlin je jednoduchý na naučení (pár týdnů max) a je dneska jednodušší sehnat Java programátora co chce dělat v Kotlinu a zaučit ho, než shánět samotného Java programátora na "čistou" Javu.
Teď si děláte legraci nebo to myslíte s nadsázkou? To by vlastně znamenalo, že Java programátoři nechtějí programovat v Javě a čekali celý svůj život na to, aby jako Java programátoři mohli programovat v Kotlinu?
"Všechno je postavené na Javě, všichni Java programátoři umí Javu, tak pro jistotu překopeme náš projekt do Kotlinu a všechny naše Java programátory pošleme na školení. Sice nám v konečném efektu Kotlin nepřinese nic nového, ale ať v práci nemáme nudu, protože práce a projekty přeci počkají" ???
Dělám pohovory, vidím že na naší pozici Java+Kotlin se hlásí víc kandidátů a lepších než na pouze Java pozice. Já už jsme za 20 let dělal v mnoha jazycích a pochybuji že Java nebo Kotlin budou ty poslední ve kterých něco napíšu. A zjevně nejsem sám.
Kotlin vs Java 9 tolik lepších věcí nenabízí, nicméně Kotlin vs Java 6 (Android) nebo Kotlin vs Javascript/Typescript ano. Pak se přeškolení rychle zaplatí. Běžný Java programátor se Kotlin naučí sám po večerech. Je to triviální.
O přepsání existujícího projektu z Javy do Kotlinu tu snad nikdo nemluví. Na nové projekty bych si vybral Kotlin před Javou.
-
Kotlin vs Java 9 tolik lepších věcí nenabízí, nicméně Kotlin vs Java 6 (Android) nebo Kotlin vs Javascript/Typescript ano. Pak se přeškolení rychle zaplatí. Běžný Java programátor se Kotlin naučí sám po večerech. Je to triviální.
Android podporuje většinu vlastností Java 8 (všechny, kvůli kterým by šlo zvažovat přechod na Kotlin). Oficiálně od Android Studia 3 (tedy stejně dlouho jako Kotlin), neoficiálně šla použít s Retrolambda už od dob, kdy se Android ještě vyvíjel na Eclipsu.