Fórum Root.cz

Hlavní témata => Vývoj => Téma založeno: okalousek 29. 10. 2020, 14:28:14

Název: Kotlin nebo Scala pro backend?
Přispěvatel: okalousek 29. 10. 2020, 14:28:14
Zdravím. Momentálně se dívám po jazycích Kotlin a Scala. Oba vypadají zajímavě, povrchově jsem si je zkusil. Android vývoj mě úplně nezajímá ale Kotlin má zajímavý Ktor, takže na backendu je také použitelný. Rád bych se zeptal: Čemu bych se měl věnovat?
Název: Re:Kotlin nebo Scala pro backend?
Přispěvatel: registrovany_ava 29. 10. 2020, 16:04:10
Já dělal několik let ve Scale, a možná bych víc doporučil Kotlin, ve kterém jsem nedělal nikdy :-) Scala je dost složitý jazyk s featurami (hlavně implicity), u kterých není bez zkušeností moc jasné, jak je správně používat. Řekl bych že mi trvalo alespoň rok než jsem v ní začal dělat jakžtakž idiomaticky. A i to je dost relativní, protože má více táborů - lidi, co jí považují za lepší Javu (a těm bych opravdu doporučil Kotlin), a lidi co jedou hardcore FP (používají knihovny jako cats nebo scalaz, nebo nedejbože shapeless), a to FP je zas mnohem líp vidět a snáz a čistěji se naučí v jazycích jako je Haskell. Navíc se těžko shání spolupracovníci.

Ale jestli máš chuť, určitě ti Scala hodně dá. A jako staticky typovaný, rel. rozšířený FP jazyk nad JVM asi nejsou moc lepší volby.
Název: Re:Kotlin nebo Scala pro backend?
Přispěvatel: okalousek 29. 10. 2020, 16:18:07
Já dělal několik let ve Scale, a možná bych víc doporučil Kotlin, ve kterém jsem nedělal nikdy :-) Scala je dost složitý jazyk s featurami (hlavně implicity), u kterých není bez zkušeností moc jasné, jak je správně používat. Řekl bych že mi trvalo alespoň rok než jsem v ní začal dělat jakžtakž idiomaticky. A i to je dost relativní, protože má více táborů - lidi, co jí považují za lepší Javu (a těm bych opravdu doporučil Kotlin), a lidi co jedou hardcore FP (používají knihovny jako cats nebo scalaz, nebo nedejbože shapeless), a to FP je zas mnohem líp vidět a snáz a čistěji se naučí v jazycích jako je Haskell. Navíc se těžko shání spolupracovníci.

Ale jestli máš chuť, určitě ti Scala hodně dá. A jako staticky typovaný, rel. rozšířený FP jazyk nad JVM asi nejsou moc lepší volby.

Tak, umím použitelně Rust, takže ty FP konstrukce mi nejsou cizí. Určitě se alespoň nějak naučím oba, jen se chci rozhodnout co víc prohlubovat. Ale i Kotlin má decentní FP konstrukce, ale nejsem nějaký "hardcore" FP fanoušek.
Název: Re:Kotlin nebo Scala pro backend?
Přispěvatel: registrovany_ava 29. 10. 2020, 16:59:12
Ok, přeju ať se daří. Osobní doporučení - až zjistíš, že příliš často hledáš odpovědi na takovéhle otázky: https://stackoverflow.com/questions/6246719/what-is-a-higher-kinded-type-in-scala , což se ti asi po nějaké době začne dít aniž by jsi sám chtěl, přečti si Learn yourself haskell for a greater good. Je to zábavná knížka, ve který jsou tyhle věci podaný daleko srozumitelněji než jsem kdy potkal ve Scale.
Název: Re:Kotlin nebo Scala pro backend?
Přispěvatel: okalousek 29. 10. 2020, 17:16:37
Ok, přeju ať se daří. Osobní doporučení - až zjistíš, že příliš často hledáš odpovědi na takovéhle otázky: https://stackoverflow.com/questions/6246719/what-is-a-higher-kinded-type-in-scala , což se ti asi po nějaké době začne dít aniž by jsi sám chtěl, přečti si Learn yourself haskell for a greater good. Je to zábavná knížka, ve který jsou tyhle věci podaný daleko srozumitelněji než jsem kdy potkal ve Scale.
Děkuji, ale ještě jsem se nerozhodl čemu se budu do hloubky věnovat.
Název: Re:Kotlin nebo Scala pro backend?
Přispěvatel: Ink 29. 10. 2020, 17:55:37
Já dělal několik let ve Scale, a možná bych víc doporučil Kotlin, ve kterém jsem nedělal nikdy :-) Scala je dost složitý jazyk s featurami (hlavně implicity), u kterých není bez zkušeností moc jasné, jak je správně používat. Řekl bych že mi trvalo alespoň rok než jsem v ní začal dělat jakžtakž idiomaticky. A i to je dost relativní, protože má více táborů - lidi, co jí považují za lepší Javu (a těm bych opravdu doporučil Kotlin), a lidi co jedou hardcore FP (používají knihovny jako cats nebo scalaz, nebo nedejbože shapeless), a to FP je zas mnohem líp vidět a snáz a čistěji se naučí v jazycích jako je Haskell. Navíc se těžko shání spolupracovníci.

Ale jestli máš chuť, určitě ti Scala hodně dá. A jako staticky typovaný, rel. rozšířený FP jazyk nad JVM asi nejsou moc lepší volby.

A jakou zkušenost jsi měl s rychlostí kompilace a ekosystémem/toolingem? Když jsem se o Scalu zajímal já, přišlo mi, že to jsou hlavní potenciálně problematické věci. Samozřejmě, ta vysoká heterogenita může být nepříjemná, ale to je designové rozhodnutí a podle mě se tam dá zvolit nějaká podmnožina idiomů, které člověk používá, ale když to celé funguje divně nebo pomalu, je to zásadní problém.
Název: Re:Kotlin nebo Scala pro backend?
Přispěvatel: okalousek 29. 10. 2020, 18:02:14
Já dělal několik let ve Scale, a možná bych víc doporučil Kotlin, ve kterém jsem nedělal nikdy :-) Scala je dost složitý jazyk s featurami (hlavně implicity), u kterých není bez zkušeností moc jasné, jak je správně používat. Řekl bych že mi trvalo alespoň rok než jsem v ní začal dělat jakžtakž idiomaticky. A i to je dost relativní, protože má více táborů - lidi, co jí považují za lepší Javu (a těm bych opravdu doporučil Kotlin), a lidi co jedou hardcore FP (používají knihovny jako cats nebo scalaz, nebo nedejbože shapeless), a to FP je zas mnohem líp vidět a snáz a čistěji se naučí v jazycích jako je Haskell. Navíc se těžko shání spolupracovníci.

Ale jestli máš chuť, určitě ti Scala hodně dá. A jako staticky typovaný, rel. rozšířený FP jazyk nad JVM asi nejsou moc lepší volby.

A jakou zkušenost jsi měl s rychlostí kompilace a ekosystémem/toolingem? Když jsem se o Scalu zajímal já, přišlo mi, že to jsou hlavní potenciálně problematické věci. Samozřejmě, ta vysoká heterogenita může být nepříjemná, ale to je designové rozhodnutí a podle mě se tam dá zvolit nějaká podmnožina idiomů, které člověk používá, ale když to celé funguje divně nebo pomalu, je to zásadní problém.
Tak já mám intellij idea-U, takže tooling není zase až takový problém.
Název: Re:Kotlin nebo Scala pro backend?
Přispěvatel: registrovany_ava 29. 10. 2020, 19:23:54
A jakou zkušenost jsi měl s rychlostí kompilace a ekosystémem/toolingem? Když jsem se o Scalu zajímal já, přišlo mi, že to jsou hlavní potenciálně problematické věci. Samozřejmě, ta vysoká heterogenita může být nepříjemná, ale to je designové rozhodnutí a podle mě se tam dá zvolit nějaká podmnožina idiomů, které člověk používá, ale když to celé funguje divně nebo pomalu, je to zásadní problém.

Rychlost překladu ujde, řekl bych že o něco rychlejší než Rust v debug režimu - desítky tisíc řádků trvají vteřiny až desítky vteřin studené kompilace, ale docela funguje inkrementální, která to v praxi hodně zrychluje.

Jako IDE používám Intellij community version, a Scala plugin je na dost vysoké úrovni.

Dokumentace ke standardní knihovně ujde, ale teď jsem rozmazlený Rust-em, tam je to přeci jen vyšší úroveň.

Chybí mi nějaký centrální repozitář scala knihoven ala crates.io pro Rust, ale je to asi trochu dané tím, že Scala má dobrou interop s Javou (hlavně ve směru Scala používá Javu, opačně už se vývojář musí trochu snažit), takže Scala vývojář má vlastně k dispozici taky všechny Javovské balíky z Mavenu atp.

Hodně jsem nadával, a nejen já, na build/package manager sbt - https://www.scala-sbt.org/ . Na jednoduché věci je to jednoduché, ale když si člověk chce něco customizovat, napsat vlastní plugin, nebo prostě jen dobře porozumnět tomu, jak to funguje, je to naprosté šílenství. Kdybych začínal nový větší projekt, dost bych uvažoval o tom vyzkoušet https://github.com/lihaoyi/mill , ale osobní zkušenost nemám.

Učil jsem se z "Programming in Scala" od Oderskyho a spol, to je super knížka, prostě jsem to projel od začátku do konce a zkoušel si kód, zábavný měsíc. Dneska bych asi začal s https://www.handsonscala.com/ . Celkově se mi líbí Scala věci od Li Haoyie (autora té knížky i Millu), jsou na používání jednoduché, ale promyšlené - a to znamená, že vymyslet je asi vůbec jednoduché nebylo. Ale je to jen moje osobní preference, někdo jiný bude mít rád shapeless.

Nevím jak hodně se ví, že Scala má nový překladač s novými featurami - https://dotty.epfl.ch/ . U nového projektu bych do toho asi klidně šel.

Abych to nějak shrnul, považuju Scalu a ekosystém za vyzrálý a naprosto production-ready, v tom jazyce se pracuje příjemně, i když nějaké nedostatky má, a nějaké nadávání určitě taky přijde (hlavně asi sbt). Určitě bych ve Scale dělal 100x radši než v Javě.
Název: Re:Kotlin nebo Scala pro backend?
Přispěvatel: okalousek 30. 10. 2020, 01:10:07
A jakou zkušenost jsi měl s rychlostí kompilace a ekosystémem/toolingem? Když jsem se o Scalu zajímal já, přišlo mi, že to jsou hlavní potenciálně problematické věci. Samozřejmě, ta vysoká heterogenita může být nepříjemná, ale to je designové rozhodnutí a podle mě se tam dá zvolit nějaká podmnožina idiomů, které člověk používá, ale když to celé funguje divně nebo pomalu, je to zásadní problém.

Rychlost překladu ujde, řekl bych že o něco rychlejší než Rust v debug režimu - desítky tisíc řádků trvají vteřiny až desítky vteřin studené kompilace, ale docela funguje inkrementální, která to v praxi hodně zrychluje.

Jako IDE používám Intellij community version, a Scala plugin je na dost vysoké úrovni.

Dokumentace ke standardní knihovně ujde, ale teď jsem rozmazlený Rust-em, tam je to přeci jen vyšší úroveň.

Chybí mi nějaký centrální repozitář scala knihoven ala crates.io pro Rust, ale je to asi trochu dané tím, že Scala má dobrou interop s Javou (hlavně ve směru Scala používá Javu, opačně už se vývojář musí trochu snažit), takže Scala vývojář má vlastně k dispozici taky všechny Javovské balíky z Mavenu atp.

Hodně jsem nadával, a nejen já, na build/package manager sbt - https://www.scala-sbt.org/ . Na jednoduché věci je to jednoduché, ale když si člověk chce něco customizovat, napsat vlastní plugin, nebo prostě jen dobře porozumnět tomu, jak to funguje, je to naprosté šílenství. Kdybych začínal nový větší projekt, dost bych uvažoval o tom vyzkoušet https://github.com/lihaoyi/mill , ale osobní zkušenost nemám.

Učil jsem se z "Programming in Scala" od Oderskyho a spol, to je super knížka, prostě jsem to projel od začátku do konce a zkoušel si kód, zábavný měsíc. Dneska bych asi začal s https://www.handsonscala.com/ . Celkově se mi líbí Scala věci od Li Haoyie (autora té knížky i Millu), jsou na používání jednoduché, ale promyšlené - a to znamená, že vymyslet je asi vůbec jednoduché nebylo. Ale je to jen moje osobní preference, někdo jiný bude mít rád shapeless.

Nevím jak hodně se ví, že Scala má nový překladač s novými featurami - https://dotty.epfl.ch/ . U nového projektu bych do toho asi klidně šel.

Abych to nějak shrnul, považuju Scalu a ekosystém za vyzrálý a naprosto production-ready, v tom jazyce se pracuje příjemně, i když nějaké nedostatky má, a nějaké nadávání určitě taky přijde (hlavně asi sbt). Určitě bych ve Scale dělal 100x radši než v Javě.
Jen jsem nepřišel jak je to s breakpointy (nebo to dělat postaru s println(...))
Název: Re:Kotlin nebo Scala pro backend?
Přispěvatel: registrovany_ava 30. 10. 2020, 06:53:47
Jen jsem nepřišel jak je to s breakpointy (nebo to dělat postaru s println(...))

Hmm, mě snad breakpointy nějak fungovaly, co si vybavuju.. Ale jo, debugování je určitě slabší místo. Tady jsem zas v nevýhodě, že jsem kdysi dělal ve Smalltalku, takže když se teď potkám s "moderním" debuggerem, mám chuť zlomit klávesnici, hodit jí do kamen a skočit za ní, a spíš se debugování vyhýbám. Aspoň mě to nutí víc psát unit testy.

Ještě jsem si uvědomil, že poměrně velký rozdíl mezi Kotlinem a Scalou je právě v tom, že Kotlin nemá skoro žádnou vlastní standardní knihovnu - jen tenký obal nad Javou, zatímco Scala jí má docela tlustou - obzvlášť kolekce. Scalovské kolekce hodně tlačí immutable přístup, to u Kotlinu neočekávám, tím se zásadně mění přístup k programování. Myslím, že člověk, co už umí Javu, se naučí produktivně Kotlin za pár dní, zatímco Scalu za týdny, měsíce, roky..
Název: Re:Kotlin nebo Scala pro backend?
Přispěvatel: tomas88 30. 10. 2020, 08:09:20
Dosti zalezi pro jake ucely to ma byt. Ciste ze studijni hlediska (pokud dobre znas javu) bych sel do Scaly. Rozsiri to obzory uplne jinym smerem. Pokud to ma byt seriozni vec s dlouhou podporou tak Kotlin (ikdyz ja bych zustal asi radeji u obycejne javy).
Název: Re:Kotlin nebo Scala pro backend?
Přispěvatel: wajtr 30. 10. 2020, 08:34:33
tomas88 mi odpoved vzal primo z ust, naprosto s nim souhlasim  :)
Jinak ja jsem v Kotlinu napsal i netrivialni veci (okolo 40000 LOC) a mohu potvrdit ze i v teto velikosti je to stale pouzitelne a dobre se mi v tom dela... u Scaly bych si nebyl tak jisty...
Název: Re:Kotlin nebo Scala pro backend?
Přispěvatel: registrovany_ava 30. 10. 2020, 08:42:08
tomas88 mi odpoved vzal primo z ust, naprosto s nim souhlasim  :)
Jinak ja jsem v Kotlinu napsal i netrivialni veci (okolo 40000 LOC) a mohu potvrdit ze i v teto velikosti je to stale pouzitelne a dobre se mi v tom dela... u Scaly bych si nebyl tak jisty...

Projekt co jsem dělal ve Scale má shodou okolností taky okolo 40000 LOC, a spolupracoval jsem i na větším. Pracuje se v tom taky dobře i na takovýchto projektech, ostatně Scala má jako jeden z hlavních cílů být a Scalable language. Potíž je spíš ta učicí křivka.
Název: Re:Kotlin nebo Scala pro backend?
Přispěvatel: A.P.Hacker 30. 10. 2020, 10:04:01
Scalovské kolekce hodně tlačí immutable přístup, to u Kotlinu neočekávám, tím se zásadně mění přístup k programování.

Kotlin prisel minimalne s dataclasses
Název: Re:Kotlin nebo Scala pro backend?
Přispěvatel: A.P.Hacker 30. 10. 2020, 10:05:39
Hmm, mě snad breakpointy nějak fungovaly, co si vybavuju.. Ale jo, debugování je určitě slabší místo. Tady jsem zas v nevýhodě, že jsem kdysi dělal ve Smalltalku, takže když se teď potkám s "moderním" debuggerem, mám chuť zlomit klávesnici, hodit jí do kamen a skočit za ní, a spíš se debugování vyhýbám. Aspoň mě to nutí víc psát unit testy.

co modernim debuggerum chybi?
Název: Re:Kotlin nebo Scala pro backend?
Přispěvatel: tomas88 30. 10. 2020, 10:22:46
tomas88 mi odpoved vzal primo z ust, naprosto s nim souhlasim  :)
Jinak ja jsem v Kotlinu napsal i netrivialni veci (okolo 40000 LOC) a mohu potvrdit ze i v teto velikosti je to stale pouzitelne a dobre se mi v tom dela... u Scaly bych si nebyl tak jisty...

Projekt co jsem dělal ve Scale má shodou okolností taky okolo 40000 LOC, a spolupracoval jsem i na větším. Pracuje se v tom taky dobře i na takovýchto projektech, ostatně Scala má jako jeden z hlavních cílů být a Scalable language. Potíž je spíš ta učicí křivka.

Jo, ta učící křivka to je právě problém. Nepochybuju o tom, že se v tom nechají psát velké projekty. Ale každý větší projekt potřebuje tým lidí a pochybuju, že se dobře skládá Scala tým co by se o to dlouhodobě staral.
Název: Re:Kotlin nebo Scala pro backend?
Přispěvatel: okalousek 30. 10. 2020, 22:16:10
Máte někdo zkušenosti s obojím? Mám zkušenosti z rustu, takže traity a FP mi není cizí. Tady záleží co nejlépe zúročím a samozřejmě v jakém jazyce se nejlépe píše.
Název: Re:Kotlin nebo Scala pro backend?
Přispěvatel: novotnyr 31. 10. 2020, 02:13:38
Kotlin je pragmatická Scala.

Kotlin využijete na backende, lebo napr. Spring má už dnes pomerne dobrú podporu pre finty z Kotlinu. Gradle viete písať v Kotline miesto Groovy. Kotlin viete rovno využiť na Androide miesto Javy. Do Kotlinu sa pragmaticky pridávajú vlastnosti, ktoré vývojári využívajú.

Kotlin má super tooling - veď ho robia tí istí ľudia, čo IntelliJ IDEA (IntelliJ je už spolovice napísaná v Kotline). Dokonca sa vôbec nehanbia vykrádať zľava-sprava, veď data classes.

Scala je dobrá ak máte konkrétny use-case a konkrétny framework. V Scale viete písať aktorov v Akke, resp. celý aktorový stack okolo toho (Play, Akka HTTP, Lagom).

Scala má tiež rozumný FP prístup, a viete to ťahať ešte ďalej do scalaz/cats a to ste už skoro v kráse Haskellu. Otázka je, či zoženiete na reálny projekt podobne zmýšľajúcich ľudi. Ak ste FP a neviete sa rozhodnúť, pozrite si Vavr.io ako biedny protipól FP pre Java svet. V Scale samozrejme užitočné premakané veci: traity, sealed traity, data classes, silný pattern matching.

Inak strašiakom v Scale je sbt: ten je fakt aj po rokoch dosť biedny a pomalý. IntelliJ však má super plugin, v ňom sa Scala klepe krásne.

Reálny projekt v Scale stále záleží na tom kto ho založil a ako ho maintainuje. Tam je totiž veľká šírka toho, ako sa filozoficky projekt pojme, teda koľko FP a koľko OOP sa tam naprasí. Náš produkčný projekt bol pekný s rozumnou dávkou FP, ale tam to držal pohromade Lagom. Na iných projektoch sa stalo, že senior sa odpútal z reťaze a nabúchal FP, čo syntax zvládla, len sa to veľmi ťažko maintainovalo, nebodaj čítalo.
Název: Re:Kotlin nebo Scala pro backend?
Přispěvatel: okalousek 01. 11. 2020, 00:28:36
Je vidět že Kotlin dělali lidé kteří znají problémy vývoje aplikací a snaží se je moderním způsobem řešit. Díky tomu "vypůjčování" z jiných jazyků má Kotlin spoustu zajímavých věcí jako například konkurenci, datové třídy apod. Přibývají nové funkce. Řekl bych že je to i docela slušně funkcionální jazyk (tzn. nepřehání to), jen mi chybí pattern-matching na vyšší úrovni (ale dá se bez něj žít).

---

Scala na druhou stranu je jazyk o kterém si při studiu "Průvodce Scalou" pomyslím: "Nikdy mě nenapadlo že by něco takového mohlo existovat". Samozřejmě že je více funkcionální než Kotlin a někdo by ve scale mohl psát Haskell stylem. Je to hodně zajímavý jazyk, ale když vidím že verze 3.0 nikde (zatím) a vypadá to že zájem o jazyk jede na setrvačnosti.
Název: Re:Kotlin nebo Scala pro backend?
Přispěvatel: waldir 01. 11. 2020, 12:57:05
S prominutím, ale jazyk bez pattern matchingu, bez algebraickych datovych typu, a optimalizovany na to aby se operace provadely skrz efekty neni funkcionalni jazyk. Kotlin ma o nekolik radu slabsi typovy system a vpodstate nepouzitelnou generiku. Zkratka je to funkcionalne **vypadajici** hromadka syntaktickeho cukru nad javou.

Zajem o scalu by byl, bohuzel s nabidkou pozic je to bida :-(.

Název: Re:Kotlin nebo Scala pro backend?
Přispěvatel: A.P.Hacker 01. 11. 2020, 13:13:45
Zkratka je to funkcionalne **vypadajici** hromadka syntaktickeho cukru nad javou.

myslim, ze se ani nesnazi vypadat funkcionalne. Nejdulezitejsi neni ten pridany syntakticky cukr, ale odstraneni nesmyslnych limitaci Javy. Dost toho prevzali z Groovy a Ruby, adaptovali na staticky typovany jazyk. Treba tohle se jim podle me hodne povedlo https://kotlinlang.org/docs/reference/type-safe-builders.html

Název: Re:Kotlin nebo Scala pro backend?
Přispěvatel: okalousek 01. 11. 2020, 13:19:06
S prominutím, ale jazyk bez pattern matchingu, bez algebraickych datovych typu, a optimalizovany na to aby se operace provadely skrz efekty neni funkcionalni jazyk. Kotlin ma o nekolik radu slabsi typovy system a vpodstate nepouzitelnou generiku. Zkratka je to funkcionalne **vypadajici** hromadka syntaktickeho cukru nad javou.

Zajem o scalu by byl, bohuzel s nabidkou pozic je to bida :-(.
V dnešní době bych ani nemluvil o tom jestli je jazyk funkcionální či imperativní, pokud to není čistě to a to (C je čistě procedurální, SmallTalk objektový, Haskell funkcionální, ...) ale co si z každého paradigmatu "vyzobal". Spousta jazyků si bere co chce (například z funkcionálních mapy, filtry což mi šetří cykly).
Název: Re:Kotlin nebo Scala pro backend?
Přispěvatel: jano6 01. 11. 2020, 18:56:58
Kotlin ale nesúťaží priamo s jazykmi Scala, Clojure, Haskell či OCalm. Kotlin je pragmatický jazyk
pre Java programátorov, pre ktorých je tento jazyk zjavením. Opravuje množstvo chýb, opomenutí
a nezmyslov napr: infantilný názov ArrayList pre zoznamy, neexistencia bežných funkcií, neexistencia literálovej
syntaxe pre kolekcie, vynucované výnimky, dodrbané Futures, práca s kolekciami z praveku, bienda podpora základného FP
programovania a mnoho ďalšieho.  V Kotline je všetko logickejšie, premyslenejšie a omnoho viac expresívne.
Rovnaká úloha v  Kotline si vyžaduje je zlomok kódu, oproti Jave. Okrem toho je zaujímavá možnosť kompilácie
do JS alebo natívneho kódu. Spolu s DSL abstrakciami sú to naozaj brutal zaujímavé veci.

Jednou z priorít jazyka Kotlin bola spätná kompatibilita s Javou a jej knižnicami a čo najjednoduchší
prechod. IntelliJ má zabudovaný pomerne mocný refaktoring Java kódu na Kotlin. Java postupne morálne
starne a prechod na tento jazyk je najviac priamočiarí.

Java programátor, ktorý prejde na Kotlin, získa strašne veľa. Skúseného FP programátora nemusí Kotlin vôbec ohúriť;
ale to jeho dizajnéri ani memali za cieľ.


S prominutím, ale jazyk bez pattern matchingu, bez algebraickych datovych typu, a optimalizovany na to aby se operace provadely skrz efekty neni funkcionalni jazyk. Kotlin ma o nekolik radu slabsi typovy system a vpodstate nepouzitelnou generiku. Zkratka je to funkcionalne **vypadajici** hromadka syntaktickeho cukru nad javou.

Zajem o scalu by byl, bohuzel s nabidkou pozic je to bida :-(.
Název: Re:Kotlin nebo Scala pro backend?
Přispěvatel: okalousek 01. 11. 2020, 21:13:42
Kotlin ale nesúťaží priamo s jazykmi Scala, Clojure, Haskell či OCalm. Kotlin je pragmatický jazyk ...

Právě na Kotlinu se mi líbí ten pragmatismus. Také mám rád FP (zkušenosti z Rustu), ale na Haskell (alespoň zatím) nemám a dále mi vyhovuje OOP, takže se Scala ukazovala za dobrou volbu, ale Kotlin a jeho pragmatismus (HTML dsl například) je také velice pěkná volba. A to mě dostalo sem. Kotlin má také funkcionální prvky.
Název: Re:Kotlin nebo Scala pro backend?
Přispěvatel: listoper 01. 11. 2020, 21:35:11
Kotlin ale nesúťaží priamo s jazykmi Scala, Clojure, Haskell či OCalm. Kotlin je pragmatický jazyk ...

Právě na Kotlinu se mi líbí ten pragmatismus. Také mám rád FP (zkušenosti z Rustu), ale na Haskell (alespoň zatím) nemám a dále mi vyhovuje OOP, takže se Scala ukazovala za dobrou volbu, ale Kotlin a jeho pragmatismus (HTML dsl například) je také velice pěkná volba. A to mě dostalo sem. Kotlin má také funkcionální prvky.

No tak pak se nabizi Clojure. Z toho pragmatismus strika do vsech smeru.
Název: Re:Kotlin nebo Scala pro backend?
Přispěvatel: okalousek 01. 11. 2020, 21:38:17
Kotlin ale nesúťaží priamo s jazykmi Scala, Clojure, Haskell či OCalm. Kotlin je pragmatický jazyk ...

Právě na Kotlinu se mi líbí ten pragmatismus. Také mám rád FP (zkušenosti z Rustu), ale na Haskell (alespoň zatím) nemám a dále mi vyhovuje OOP, takže se Scala ukazovala za dobrou volbu, ale Kotlin a jeho pragmatismus (HTML dsl například) je také velice pěkná volba. A to mě dostalo sem. Kotlin má také funkcionální prvky.

No tak pak se nabizi Clojure. Z toho pragmatismus strika do vsech smeru.
. Někde v oblasti práce s velkými daty či AI(?) je to asi užitečný jazyk, ale pro mě je to spíše taková kuriozita.
Název: Re:Kotlin nebo Scala pro backend?
Přispěvatel: okalousek 02. 11. 2020, 10:28:07
Bylo tu zmíněno že něco je na něco. Ale co je na co?
Název: Re:Kotlin nebo Scala pro backend?
Přispěvatel: listoper 02. 11. 2020, 14:11:15
Kotlin ale nesúťaží priamo s jazykmi Scala, Clojure, Haskell či OCalm. Kotlin je pragmatický jazyk ...

Právě na Kotlinu se mi líbí ten pragmatismus. Také mám rád FP (zkušenosti z Rustu), ale na Haskell (alespoň zatím) nemám a dále mi vyhovuje OOP, takže se Scala ukazovala za dobrou volbu, ale Kotlin a jeho pragmatismus (HTML dsl například) je také velice pěkná volba. A to mě dostalo sem. Kotlin má také funkcionální prvky.

No tak pak se nabizi Clojure. Z toho pragmatismus strika do vsech smeru.
. Někde v oblasti práce s velkými daty či AI(?) je to asi užitečný jazyk, ale pro mě je to spíše taková kuriozita.

Ani velky data ani AI nedelam.
Pouzivam vsude kde muzu a nemuzu si to vynachvalit.
Ale nechci ti to nutit.
Jen sem zachytil slovo pragmatismus tak jsem reagoval, protoze clojure je podle me "no nonsense" jazyk.
Vzdycky kdyz pisu v clojure tak proste vidim a pisu business logiku a vubec nemusim resit zadny technikalie okolo.
Název: Re:Kotlin nebo Scala pro backend?
Přispěvatel: okalousek 02. 11. 2020, 16:00:45
Věřím že Clojure je moc pěkný jazyk ale (to (je (pro ( mě (extrém)))) a myslím že i pro mnoho lidí.
Název: Re:Kotlin nebo Scala pro backend?
Přispěvatel: listoper 02. 11. 2020, 16:14:45
Věřím že Clojure je moc pěkný jazyk ale (to (je (pro ( mě (extrém)))) a myslím že i pro mnoho lidí.

:-) jako ze hodne zavorek?
To mi rikali kluci v tymu pred rokem taky. Tak sme si dali nejaky spolecny zadani a ja to psal v clojure a oni v jave.
A mel sem zavorek polovicku :-).

V clojure neni vic zavorek nez jinde (mozna s vyjimkou pythonu?) jen je tam min vseho ostatniho.
A kdyz pouzijes slusny editor kterej podporuje structured coding (a to jde prave nejlip u lispu protoze je homoiconic) tak ty zavorky vubec nevnimas.

Kód: [Vybrat]
System.out.println("ahoj");

vs.

(println "ahoj")

Navic kdyz vezmu ten tvuj pripad tak spravneji by to asi bylo (extrem (me (pro (je (to))))) protoze prvni se vyhodnoti to uvnitr ale diky threading makru to v clojure muzu napsat takhle:

Kód: [Vybrat]

(->> (to)
     (je)
     (pro)
     (me)
     (extrem))
Název: Re:Kotlin nebo Scala pro backend?
Přispěvatel: BoneFlute 02. 11. 2020, 16:19:56
... ale (to (je (pro ( mě (extrém)))) a myslím že i pro mnoho lidí.
To je mýtus.
Název: Re:Kotlin nebo Scala pro backend?
Přispěvatel: okalousek 02. 11. 2020, 18:08:53
Samozřejmě. Určitě je to zajímavý jazyk ale to už je asi moc (ale třeba jednoho dne mu přijdu na chuť).
Název: Re:Kotlin nebo Scala pro backend?
Přispěvatel: jano6 02. 11. 2020, 20:21:00
F# je tiež veľmi pragmatický jazyk. Všetky kolekcie sú immutable okrem polí; pretože
polia sa často využívajú vo výpočtoch, ktoré sú mutable. V jazyku neexistuje null hodnota,
ale keby to bolo treba, dá sa to spojazdniť pomocou AllowNullLiteral atribútu.
Rekurzia je first-class, ale v jazyku sú aj tradičné for cykly; niekedy sa to proste hodí.

Clojure veľmi nepoznám, ale rozhodne je to veľmi zaujímavý jazyk. Keď som si porovnával
príklady na rosetta code, tak čo sa týka čitateľnosti, zrozumiteľnoti, a elegancie, tak väčšinou
mi vyšiel F#.  V niektorých prípadoch to bol však Clojure. Zároveň fakt, že syntax LISPU sa
výrazne nezmenila od roku 1958, je veľmi pozoruhodný. (Porovnajme si to s tým, ako sa
drasticky menia jazyky napr. PHP, JS, C# či C++.)


Kotlin ale nesúťaží priamo s jazykmi Scala, Clojure, Haskell či OCalm. Kotlin je pragmatický jazyk ...

Právě na Kotlinu se mi líbí ten pragmatismus. Také mám rád FP (zkušenosti z Rustu), ale na Haskell (alespoň zatím) nemám a dále mi vyhovuje OOP, takže se Scala ukazovala za dobrou volbu, ale Kotlin a jeho pragmatismus (HTML dsl například) je také velice pěkná volba. A to mě dostalo sem. Kotlin má také funkcionální prvky.

No tak pak se nabizi Clojure. Z toho pragmatismus strika do vsech smeru.
Název: Re:Kotlin nebo Scala pro backend?
Přispěvatel: listoper 02. 11. 2020, 21:17:23
Zároveň fakt, že syntax LISPU sa výrazne nezmenila od roku 1958, je veľmi pozoruhodný. (Porovnajme si to s tým, ako sa
drasticky menia jazyky napr. PHP, JS, C# či C++.)


To bude tim, ze LISP syntax v podstate nema zadnou ;-). (cti minimalni)
Název: Re:Kotlin nebo Scala pro backend?
Přispěvatel: okalousek 02. 11. 2020, 21:21:25
Svým způsobem je Lisp velice elegantní jazyk, ne?
Název: Re:Kotlin nebo Scala pro backend?
Přispěvatel: listoper 02. 11. 2020, 22:40:39
Svým způsobem je Lisp velice elegantní jazyk, ne?

Jo, ale ma tu nevyhodu, ze jak si na to zvyknes tak ti vsechno ostatni prijde hnusny  ;D
Název: Re:Kotlin nebo Scala pro backend?
Přispěvatel: registrovany_ava 03. 11. 2020, 09:07:17
Kotlin ale nesúťaží priamo s jazykmi Scala, Clojure, Haskell či OCalm. Kotlin je pragmatický jazyk ...

Právě na Kotlinu se mi líbí ten pragmatismus. Také mám rád FP (zkušenosti z Rustu), ale na Haskell (alespoň zatím) nemám a dále mi vyhovuje OOP, takže se Scala ukazovala za dobrou volbu, ale Kotlin a jeho pragmatismus (HTML dsl například) je také velice pěkná volba. A to mě dostalo sem. Kotlin má také funkcionální prvky.

No tak pak se nabizi Clojure. Z toho pragmatismus strika do vsech smeru.

Mě se na Clojure zásadně nelíbí (osobní preference) absence statických typů. Máš nějaké zkušenosti s https://github.com/typedclojure/typedclojure ? V jakém je to stavu, je tam poslední dobou nějak málo commitů..?
Název: Re:Kotlin nebo Scala pro backend?
Přispěvatel: A.P.Hacker 03. 11. 2020, 10:44:03
Mě se na Clojure zásadně nelíbí (osobní preference) absence statických typů.

https://www.youtube.com/watch?v=YR5WdGrpoug
Název: Re:Kotlin nebo Scala pro backend?
Přispěvatel: listoper 03. 11. 2020, 13:16:13
Kotlin ale nesúťaží priamo s jazykmi Scala, Clojure, Haskell či OCalm. Kotlin je pragmatický jazyk ...

Právě na Kotlinu se mi líbí ten pragmatismus. Také mám rád FP (zkušenosti z Rustu), ale na Haskell (alespoň zatím) nemám a dále mi vyhovuje OOP, takže se Scala ukazovala za dobrou volbu, ale Kotlin a jeho pragmatismus (HTML dsl například) je také velice pěkná volba. A to mě dostalo sem. Kotlin má také funkcionální prvky.

No tak pak se nabizi Clojure. Z toho pragmatismus strika do vsech smeru.

Mě se na Clojure zásadně nelíbí (osobní preference) absence statických typů. Máš nějaké zkušenosti s https://github.com/typedclojure/typedclojure ? V jakém je to stavu, je tam poslední dobou nějak málo commitů..?

S tim sem si nikdy nehral...
Pouzivam https://clojure.org/guides/spec (https://clojure.org/guides/spec) obcas... a kdysi sem si hral s https://github.com/arohner/spectrum (https://github.com/arohner/spectrum).

Ale hlavne RDD (repl driven development) prece jenom kontrolovat typy pri kompilaci je trochu pozde ze? (:-D)
Název: Re:Kotlin nebo Scala pro backend?
Přispěvatel: Ink 03. 11. 2020, 13:47:58
S tim sem si nikdy nehral...
Pouzivam https://clojure.org/guides/spec (https://clojure.org/guides/spec) obcas... a kdysi sem si hral s https://github.com/arohner/spectrum (https://github.com/arohner/spectrum).

Ale hlavne RDD (repl driven development) prece jenom kontrolovat typy pri kompilaci je trochu pozde ze? (:-D)

Podle mych zkusenosti ty typy u dynamickych jazycich nejvic chybeji az pri upravach produkcniho systemu.
Název: Re:Kotlin nebo Scala pro backend?
Přispěvatel: listoper 03. 11. 2020, 13:52:34
S tim sem si nikdy nehral...
Pouzivam https://clojure.org/guides/spec (https://clojure.org/guides/spec) obcas... a kdysi sem si hral s https://github.com/arohner/spectrum (https://github.com/arohner/spectrum).

Ale hlavne RDD (repl driven development) prece jenom kontrolovat typy pri kompilaci je trochu pozde ze? (:-D)

Podle mych zkusenosti ty typy u dynamickych jazycich nejvic chybeji az pri upravach produkcniho systemu.

Chapu co rikas, ale nejak nechapu souvislost s tim co citujes.
Název: Re:Kotlin nebo Scala pro backend?
Přispěvatel: Ink 03. 11. 2020, 14:35:58
Chapu co rikas, ale nejak nechapu souvislost s tim co citujes.

Co jsi tedy myslel timhle:

kontrolovat typy pri kompilaci je trochu pozde ze?
Název: Re:Kotlin nebo Scala pro backend?
Přispěvatel: listoper 03. 11. 2020, 15:03:00
Chapu co rikas, ale nejak nechapu souvislost s tim co citujes.

Co jsi tedy myslel timhle:

kontrolovat typy pri kompilaci je trochu pozde ze?

Castecne trochu provokace :-).
Castecne to ze s clojure a spec muzu overovat konfrmitu kdykoli se mi zachce.
Treba pro jeden konkretni vyraz uprostred funkce.

Samozrejme to stejne tak muzu delat i pri upravach produkcniho systemu.
A kdyz mam koule a pristup tak i primo na te produkci.
Název: Re:Kotlin nebo Scala pro backend?
Přispěvatel: Ink 03. 11. 2020, 17:19:27
Chapu co rikas, ale nejak nechapu souvislost s tim co citujes.

Co jsi tedy myslel timhle:

kontrolovat typy pri kompilaci je trochu pozde ze?

Castecne trochu provokace :-).
Castecne to ze s clojure a spec muzu overovat konfrmitu kdykoli se mi zachce.
Treba pro jeden konkretni vyraz uprostred funkce.

Samozrejme to stejne tak muzu delat i pri upravach produkcniho systemu.
A kdyz mam koule a pristup tak i primo na te produkci.

No dobře, předpokládám, že jde o ověření dynamické (mýlím se?), což ale není zrovna to, co je "později než kompilace". Pokud není v každé chvíli dostateřně jasné, s jakým datovým typem se pracuje, hrozí chyba ve všech možných okrajových případech no a po úpravách nebo dokonce refaktorizaci to bude nejspíš jenom horší.
Název: Re:Kotlin nebo Scala pro backend?
Přispěvatel: listoper 03. 11. 2020, 17:38:17
Chapu co rikas, ale nejak nechapu souvislost s tim co citujes.

Co jsi tedy myslel timhle:

kontrolovat typy pri kompilaci je trochu pozde ze?

Castecne trochu provokace :-).
Castecne to ze s clojure a spec muzu overovat konfrmitu kdykoli se mi zachce.
Treba pro jeden konkretni vyraz uprostred funkce.

Samozrejme to stejne tak muzu delat i pri upravach produkcniho systemu.
A kdyz mam koule a pristup tak i primo na te produkci.

No dobře, předpokládám, že jde o ověření dynamické (mýlím se?), což ale není zrovna to, co je "později než kompilace". Pokud není v každé chvíli dostateřně jasné, s jakým datovým typem se pracuje, hrozí chyba ve všech možných okrajových případech no a po úpravách nebo dokonce refaktorizaci to bude nejspíš jenom horší.

Ja vidim hlavni vyhodu statickeho overeni v tom, ze se to nedeje az v runtimu na produkci. Tzn. to overeni spravnosti se deje driv.
U statickyho checkovani to proste overi kompiler a vysledek zarucuje, ze ty chyby nenastanou. To je fajn.
Ale pri RDD mam runtime uz behem developmentu... takze je trochu jedno jestli je to staticky nebo dynamicky... proste je to driv nez ten runtime na produkci(a driv nez ten compile time... proto sem si dovolil tu provokaci).
Ma staticke typovani nejakou dalsi vyhodu pred dynamickym krome toho, ze ta kontrola typu probehne pred nasazenim?

A jinak to spektrum:
Citace
A library for doing static analysis of Clojure code, catching clojure.spec conform errors at compile time.

Ale to uz je dost dlouho co sem si s tim hral a nevim v jakem je to dneska stavu.
Název: Re:Kotlin nebo Scala pro backend?
Přispěvatel: tralala5 03. 11. 2020, 18:16:59
Zatial co Scalu povazujem za lepsi jazyk tak by som isiel v tomto pripade do Kotlinu. V Scale som napisal jeden netrivialny Spark job a nebol to projekt len o par triedach ... enterprise vec proste a venoval som sa tomu asi pol roka a udrzoval to, je to skvely jazyk a vsetko, ale mne sa zdalo, ze to je take C++ v Jave. Mas tam milion sposobov ako tam nieco napisat a musis si davat viac pozor co pises a ako to pises a drzat sa nejakeho standardu inak to zacne byt gulas. Druha vec co mi na Scale vadila bolo to, no, nie ze vadilo, ale proste mal som dojem ze Scala je trocha tazkopadna - zatial co ta vyjadrovacia schopnost je brutalna, tak do toho musis dat strasne vela vedomosti aby to robilo to ci co atd, Kotlin mi pride ako Java na steroidoch, nemas tam zakernosti ako implicity (ktore same o sebe nie su zle) atd, v Scale som mal dojem ze nebojujem len s tym co napisat ale este aj s tym ze ako, vracal som sa k tomu kodu a ako som sa v scale zlepsoval tak som aj ten kod stale prepisoval a piloval aby to bolo idiomaticky atd a stravil som nad tym kopec casu ktory bol vlastne vyhodeny von oknom. Aby som to zhrnul, do Scaly ked mas na to nervy a nie je to projekt na jedno popoludnie. Pre vacsiu flexibilitu a rychlejsi vyvoj by som zvolil Kotlin.
Název: Re:Kotlin nebo Scala pro backend?
Přispěvatel: Ink 03. 11. 2020, 18:44:34
Ma staticke typovani nejakou dalsi vyhodu pred dynamickym krome toho, ze ta kontrola typu probehne pred nasazenim?

Že kontrola probíhá před nasazením je vlastnost, ne konkrétní výhoda. Výhody jsou třeba takové, že:

1. Kompilátor nedovolí překlad, pokud má protichůdné či nedostatečné informace o typu. To jsi měl asi na mysli.
2. Vývojový nástroj (který s kompilátorem může sdílet některé komponenty) člověku ještě před samotnou kompilací v reálném čase ty nedostatky může hlásit (nevím, co v tomto může navíc nabídnout Tvůj REPL driven development).
3. Vývojový nástroj ukazuje typ proměnné/hodnoty/parametru apod. díky inferenci. Při vývoji neustále vím, co za data tam leze, jakou mají vnitřní strukturu (zde už může docházet i k našeptávání atributů ve strukturovaných datech apod.).
Název: Re:Kotlin nebo Scala pro backend?
Přispěvatel: listoper 03. 11. 2020, 20:55:48
Ma staticke typovani nejakou dalsi vyhodu pred dynamickym krome toho, ze ta kontrola typu probehne pred nasazenim?

Že kontrola probíhá před nasazením je vlastnost, ne konkrétní výhoda. Výhody jsou třeba takové, že:

1. Kompilátor nedovolí překlad, pokud má protichůdné či nedostatečné informace o typu. To jsi měl asi na mysli.
2. Vývojový nástroj (který s kompilátorem může sdílet některé komponenty) člověku ještě před samotnou kompilací v reálném čase ty nedostatky může hlásit (nevím, co v tomto může navíc nabídnout Tvůj REPL driven development).
3. Vývojový nástroj ukazuje typ proměnné/hodnoty/parametru apod. díky inferenci. Při vývoji neustále vím, co za data tam leze, jakou mají vnitřní strukturu (zde už může docházet i k našeptávání atributů ve strukturovaných datech apod.).

Tak mam dojem ze uz se tu kdysi resilo, ze 2 a 3 umi jetbrains resit i u pythonu.
Co umi RDD navic?
Proste si muzu pri vyvoji uprostred psani funkce provolat nejakej vyraz a videt co se mi vrati.
Cela funkce muze bejt i nezkompilovatelna ... ja si poustim jen ten jeden vyraz.
Vim ze jinde mi dokaze treba ide rict, jestli se to zkompiluje.. ale REPL mi rovnou rekne vysledky.

Mam bezici runtime a do nej si evaluaci propaguju definice funkci. A muzu si je volat.
V priloze sem cervenym obdelnickem vyznacil jak se mi ukaze navratova hodnota po "C+x e"

Kdyz si zkusim spustit (hello "Paul") tak na me vybehne to co je v druhe priloze.

Ano nepouzil sem ten spectum takze je to dynamicky vyhodnocovane tim, ze si to spoustim. A tady v tom pripade dokonce s konkretni hodnoutou takze to neni uplne vypovidajici pripad.
Nicmene to melo ukazat to ze zkouset konformitu vuci specifikovanemu typu muzu jeste "pred kompilaci" takze mam driv feedback. Samozrejme, ze tam ta kompilace je, ale vyvojar se o ni nezajima... neni to takovy ten meznik tak a ted si to zbuilduju a nasadim.... je to proste jen tuknuti do klavesnice a vysledek je hned.

Tezko se to vysvetluje... lip se to ukazuje.

Název: Re:Kotlin nebo Scala pro backend?
Přispěvatel: redustin 03. 11. 2020, 22:04:40
Tak mam dojem ze uz se tu kdysi resilo, ze 2 a 3 umi jetbrains resit i u pythonu.

Bez důsledných type hintů, příp. jedinečně pojmenovaných metod (jak často tu zaznívá propagace stručných jednoslovných názvů...) si ani pycharm moc neškrtne. A nelze se mu divit, že neumí věštit...
Název: Re:Kotlin nebo Scala pro backend?
Přispěvatel: Ink 03. 11. 2020, 22:58:02
Tak mam dojem ze uz se tu kdysi resilo, ze 2 a 3 umi jetbrains resit i u pythonu.

Bez důsledných type hintů, příp. jedinečně pojmenovaných metod (jak často tu zaznívá propagace stručných jednoslovných názvů...) si ani pycharm moc neškrtne. A nelze se mu divit, že neumí věštit...

No a když se přidají hovadiny typu **kwargs, ani křišťálová koule nepomůže.
Název: Re:Kotlin nebo Scala pro backend?
Přispěvatel: Sam Samovic 03. 11. 2020, 23:42:45
Uff, moje odpoved asi nenadchne ale presto si ji neodpustim. Proc se chce nekdo poustet do vyvoje v nejakem "pseudo" jazyce ? Chci tim rict ze jedna vec je smysluplny pokrok ale ta "turbulence" vzniku novych jazyku mi pripada az usmevna. Nekdo vytvori novy jazyk, protoze je super-cuper a ma features xy ktery tech 30 jazyku predtim nemelo.  Nez se ten jazyk dostane alespon do prvni stable verze uz je vlastne zastaraly protoze nejaci frikulini vymysleli novy jazyk xy'. Pochopim to na urvoni skolni ci osobniho rozovje ale z hlediska komercniho vyuziti mi to prijde ulitle. Nerikam ze nikdo v kotlinu/scale nepise ale  ... Mainstream je dneska asi Java,C#,Python ? Ja byt majitel nejake firmy a prijit ke mne clovek ze mi chce neco bastlit v Kotlinu protoze mu to prijde cool & sexy tak ho zenu svinskym krokem. Uz vidim jak mi za 2 roky rekne ze ho to neba, ze jde jinam protoze jazyk XY'' a ja zacinam schanet na trhu nekoho kdo zna Kotlin, Scala. Priznavam jsem starej pes co pise 20let v Ccku, ale to nenavidene Ccko, ma proad zivy ekosystem, spoustu podpurnejch toolu pres profilovani, debug, valgrind atd. Existuji vubec takove tooly pro Kotlin, Scalu budou existovat za 2 roky ? A pokud jsem v nem (C/C++) napsali projekt puvodne pro HP-UX na PARISCU, postupem casu se portoval na HP-UX itanium az skoncil na Linuxu/x86_64 porad to bude udrzitelne. Me proste prijde ze lidi kvuli svemu egu, hrozne tristi sily a pokroku to spis skodi nez prospiva. Je sice fajn ze si muzu vybrat ze 100 programovacich jazyku ale dava to smysl ?  Jeste bych dodal ze to neni o moji lenosti, naucit se neco noveho, kdyz si clovek prosel Cobol,Pascal,C/C++,Java,Pro*C,PL/SQL neni az zas tak slozite se naucit novy jazyk alespon syntakticky, toze ze za vikend pochopite Javu z vas nedela samozrejme programatora v Jave, protoze ta dzungle classu a interface je proste usmevna.
Název: Re:Kotlin nebo Scala pro backend?
Přispěvatel: BoneFlute 04. 11. 2020, 00:58:34
hrozne tristi sily a pokroku to spis skodi nez prospiva

A v čem by sis teda představoval ten pokrok? Aby to dle tvého nebylo plejtvání?

Scala, Kotlin, Rust jsou následovníci Java, Python.
Java, Python jsou následovníci C, C++, Basic, Pascal
C je následovník Assembleru.

Můj děda programoval u IBM v kolíčcích, a nad Assemblerem ohrnoval nos.
Název: Re:Kotlin nebo Scala pro backend?
Přispěvatel: premekv 04. 11. 2020, 08:59:33
Ja byt majitel nejake firmy a prijit ke mne clovek ze mi chce neco bastlit v Kotlinu protoze mu to prijde cool & sexy tak ho zenu svinskym krokem. Uz vidim jak mi za 2 roky rekne ze ho to neba, ze jde jinam protoze jazyk XY'' a ja zacinam schanet na trhu nekoho kdo zna Kotlin, Scala.

Asi chápu myšlenku, ale s Kotlinem bych zrovna nikoho ze dveří nevyhazoval, nebál bych se toho.

Píše Roman Pichlík (Dagi) na svém blogu o jednom projektu:

"Jedno z důležitých a správných rozhodnutí bylo vsadit na Kotlin. Dost nám to pomohlo s hiringem, protože komunita Java vývojářů na to dost slyšela."

Kotlin není úplně cool hype, má za sebou ca 10 let aktivního vývoje. Je to jazyk nad JVM (tj máte celý java ekosystém nástrojů, knihoven...) Pro dobrého javistu nebude sebemenší problém se ho naučit.  Pro začátečníky je to také ok, jazyk je díky některým věcem v návrhu bezpečnější než java. Jinak na té javě je znát, že některé věci z kotlinu/scaly přebírá...


Název: Re:Kotlin nebo Scala pro backend?
Přispěvatel: Ink 04. 11. 2020, 09:25:11
Uff, moje odpoved asi nenadchne ale presto si ji neodpustim. Proc se chce nekdo poustet do vyvoje v nejakem "pseudo" jazyce ? Chci tim rict ze jedna vec je smysluplny pokrok ale ta "turbulence" vzniku novych jazyku mi pripada az usmevna. Nekdo vytvori novy jazyk, protoze je super-cuper a ma features xy ktery tech 30 jazyku predtim nemelo.  Nez se ten jazyk dostane alespon do prvni stable verze uz je vlastne zastaraly protoze nejaci frikulini vymysleli novy jazyk xy'. Pochopim to na urvoni skolni ci osobniho rozovje ale z hlediska komercniho vyuziti mi to prijde ulitle. Nerikam ze nikdo v kotlinu/scale nepise ale  ... Mainstream je dneska asi Java,C#,Python ? Ja byt majitel nejake firmy a prijit ke mne clovek ze mi chce neco bastlit v Kotlinu protoze mu to prijde cool & sexy tak ho zenu svinskym krokem. Uz vidim jak mi za 2 roky rekne ze ho to neba, ze jde jinam protoze jazyk XY'' a ja zacinam schanet na trhu nekoho kdo zna Kotlin, Scala. Priznavam jsem starej pes co pise 20let v Ccku, ale to nenavidene Ccko, ma proad zivy ekosystem, spoustu podpurnejch toolu pres profilovani, debug, valgrind atd. Existuji vubec takove tooly pro Kotlin, Scalu budou existovat za 2 roky ? A pokud jsem v nem (C/C++) napsali projekt puvodne pro HP-UX na PARISCU, postupem casu se portoval na HP-UX itanium az skoncil na Linuxu/x86_64 porad to bude udrzitelne. Me proste prijde ze lidi kvuli svemu egu, hrozne tristi sily a pokroku to spis skodi nez prospiva. Je sice fajn ze si muzu vybrat ze 100 programovacich jazyku ale dava to smysl ?  Jeste bych dodal ze to neni o moji lenosti, naucit se neco noveho, kdyz si clovek prosel Cobol,Pascal,C/C++,Java,Pro*C,PL/SQL neni az zas tak slozite se naucit novy jazyk alespon syntakticky, toze ze za vikend pochopite Javu z vas nedela samozrejme programatora v Jave, protoze ta dzungle classu a interface je proste usmevna.

Smysl to dává, pokud ten jazyk má přidanou hodnotu. Vem si, že optimalizuješ na rychlost vývoje, udržovatelnost kódu, rychlost běhu, bezpečnost apod. Kdyby za Tebou přišel někdo, že psát v Kotlinu je cool a zatrhnul bys to, asi bys udělal dobře.  Co ale když má dobré důvody? A co když, díky tomu že se mu v něčem vyvíjí lépe, udělá aplikaci, jakou by v "mainstreamu" prostě neudělal z nedostatku motivace?

Proč si myslíš, že Google, Microsoft, Apple, Amazon a další laborují s různými novými jazyky? No protože doufají, že se jim povede něco zlepšit. A často tomu tak je. Go je v něčem lepší než Python nebo C, Rust v něčem přerostl C++. A ekosystém? Kolikrát v mnohém lepší!
Název: Re:Kotlin nebo Scala pro backend?
Přispěvatel: redustin 04. 11. 2020, 09:31:56
A pak Oracle koupí IntelliJ a Kotlin samozřejmě pro nepotřebnost zařízne...

Jedna věc je malý jednorázový projekt, druhá věc je firemní systém s výhledem na desítky let. Opravdu si nemyslím, že je best practice projekty po pěti letech přepisovat od nuly. Naopak u takových projektů byly počáteční rozhodnutí a průběžné řízení projektu špatně, když projekt nebylo možno dlouhodobě rozvíjet a přetvářet na nové požadavky.
Název: Re:Kotlin nebo Scala pro backend?
Přispěvatel: okalousek 04. 11. 2020, 09:51:56
A pak Oracle koupí IntelliJ a Kotlin samozřejmě pro nepotřebnost zařízne...

No jasně. Zařízne primární (Googlem podporovaný) programovací jazyk pro nejrozšířenější spotřební platformu (Android). Ten by si na Kotlinu raději namastil kapsu.

A IntelliJ dělá spoustu IDE která nejsou pro Javu, nevím jestli by to bylo pro Oracle zase tak užitečné.
Název: Re:Kotlin nebo Scala pro backend?
Přispěvatel: Filip Jirsák 04. 11. 2020, 10:27:10
Kotlin není úplně cool hype, má za sebou ca 10 let aktivního vývoje.
Ono nemusí záležet na době vývoje. Řekl bych, že to „cool hype“ má Kotlin v genech. Je na něm hrozně vidět, že to není jazyk navržený architektem, ale je poskládaný zespoda programátory – jako když pejsek a kočička vařili dort. Když tam přilepíme všechno, co je dobré, musí být přece výsledek úžasný. Jenže tam chybí nějaký cíl, něco, co by to zastřešilo, dalo to jazyku nějaký smysl. U Javy, Scaly, Go, C++, Rustu, C, JavaScriptu, TypeScriptu, Pythonu, Perlu nebo PHP dokážu ten jazyk charakterizovat jednou větou. V případě Kotlinu to nedokážu – resp. jedna věta by byla o tom, jak Kotlin vznikl, ne k čemu je určen.

Jinak na té javě je znát, že některé věci z kotlinu/scaly přebírá...
Je fajn, že úlohu pokusných králíků na sebe vzaly jiné jazyky a Java může přebírat až to, co se osvědčí :-)
Název: Re:Kotlin nebo Scala pro backend?
Přispěvatel: redustin 04. 11. 2020, 10:35:27
Zrovna u Oraclu si dovedu představit, že by chtěli uškodit googlu, se kterým jsou v permanentním sporu.

U mobilní aplikace neočekávám mnoholetou životnost, tam je naopak důležitý co nejkratší čas vývoje. A příští verze může být napsaná klidně v něčem, co aktuálně nejvíc frčí, nikdo ji nebude udržovat spoustu let. Mluvil jsem o firemních systémech. Píšou banky nebo operátoři své systémy v Kotlinu? Možná nějaké pluginy a doplňky jo.
Název: Re:Kotlin nebo Scala pro backend?
Přispěvatel: okalousek 04. 11. 2020, 10:39:55
Mě spíše přijde že C++ je dort pejska a kočičky. Začalo to jako dort a poté tam začali dávat to nejlepší odevšad. Ale on je to takový efekt C++, to se stává i Javě, C# a nakonec všem jazykům.

Kotlin je jazyk navržený Javisty, tak, jak by se jim Java líbila.
Název: Re:Kotlin nebo Scala pro backend?
Přispěvatel: listoper 04. 11. 2020, 10:50:55
Zrovna u Oraclu si dovedu představit, že by chtěli uškodit googlu, se kterým jsou v permanentním sporu.

U mobilní aplikace neočekávám mnoholetou životnost, tam je naopak důležitý co nejkratší čas vývoje. A příští verze může být napsaná klidně v něčem, co aktuálně nejvíc frčí, nikdo ji nebude udržovat spoustu let. Mluvil jsem o firemních systémech. Píšou banky nebo operátoři své systémy v Kotlinu? Možná nějaké pluginy a doplňky jo.

Nektere to pisou v clojure a mysli to dost vazne :-) https://www.finextra.com/newsarticle/36297/nubank-buys-firm-behind-clojure-programming-language (https://www.finextra.com/newsarticle/36297/nubank-buys-firm-behind-clojure-programming-language)
Název: Re:Kotlin nebo Scala pro backend?
Přispěvatel: premekv 04. 11. 2020, 11:07:31
Jenže tam chybí nějaký cíl, něco, co by to zastřešilo, dalo to jazyku nějaký smysl. U Javy, Scaly, Go, C++, Rustu, C, JavaScriptu, TypeScriptu, Pythonu, Perlu nebo PHP dokážu ten jazyk charakterizovat jednou větou. V případě Kotlinu to nedokážu – resp. jedna věta by byla o tom, jak Kotlin vznikl, ne k čemu je určen.

Kotlin je určen ke všemu, k čemu je určena java. Má mít kompaktnější syntax (properties, data classes, switch expressions, lambdy, type inference, template strings....  něco z toho se později dostává do javy..). Má být bezpečnější pro "průmyslové použití" tj návrhem preventivně bránit částým chybám (null safe calls, == vs ref. equality..). "Průmyslové použití" pro mne znamená  velký projekt, kde kód píše hodně lidí s různými úrovněmi znalosti.  Zároveň, do třetice, ten jazyk má být jednoduchý na naučení (ne o moc složitější než java) a kód v něm má být dobře udržovatelný (jako v javě). Takže se právě naopak chce vyhnout zbrklému přidávání features stylem "kočička pejsek".

Název: Re:Kotlin nebo Scala pro backend?
Přispěvatel: BoneFlute 04. 11. 2020, 11:28:28
Jenže tam chybí nějaký cíl, něco, co by to zastřešilo, dalo to jazyku nějaký smysl. U Javy, Scaly, Go, C++, Rustu, C, JavaScriptu, TypeScriptu, Pythonu, Perlu nebo PHP dokážu ten jazyk charakterizovat jednou větou. V případě Kotlinu to nedokážu – resp. jedna věta by byla o tom, jak Kotlin vznikl, ne k čemu je určen.

Kotlin je určen ke všemu, k čemu je určena java. Má mít kompaktnější syntax (properties, data classes, switch expressions, lambdy, type inference, template strings....  něco z toho se později dostává do javy..). Má být bezpečnější pro "průmyslové použití" tj návrhem preventivně bránit částým chybám (null safe calls, == vs ref. equality..). "Průmyslové použití" pro mne znamená  velký projekt, kde kód píše hodně lidí s různými úrovněmi znalosti.  Zároveň, do třetice, ten jazyk má být jednoduchý na naučení (ne o moc složitější než java) a kód v něm má být dobře udržovatelný (jako v javě). Takže se právě naopak chce vyhnout zbrklému přidávání features stylem "kočička pejsek".
A řekl bych, že úspěšně.
Název: Re:Kotlin nebo Scala pro backend?
Přispěvatel: okalousek 04. 11. 2020, 11:59:49
Kotlin je určen ke všemu, k čemu je určena java. Má mít kompaktnější syntax (properties, data classes, switch expressions, lambdy, type inference, template strings....  něco z toho se později dostává do javy..). Má být bezpečnější pro "průmyslové použití" tj návrhem preventivně bránit částým chybám (null safe calls, == vs ref. equality..). "Průmyslové použití" pro mne znamená  velký projekt, kde kód píše hodně lidí s různými úrovněmi znalosti.  Zároveň, do třetice, ten jazyk má být jednoduchý na naučení (ne o moc složitější než java) a kód v něm má být dobře udržovatelný (jako v javě). Takže se právě naopak chce vyhnout zbrklému přidávání features stylem "kočička pejsek".
A je tam i slušná CSP-oidních korutin, hodně rozšíření pro jazyk.
Název: Re:Kotlin nebo Scala pro backend?
Přispěvatel: Filip Jirsák 04. 11. 2020, 12:40:18
Kotlin je určen ke všemu, k čemu je určena java. Má mít kompaktnější syntax (properties, data classes, switch expressions, lambdy, type inference, template strings....  něco z toho se později dostává do javy..). Má být bezpečnější pro "průmyslové použití" tj návrhem preventivně bránit částým chybám (null safe calls, == vs ref. equality..). "Průmyslové použití" pro mne znamená  velký projekt, kde kód píše hodně lidí s různými úrovněmi znalosti.  Zároveň, do třetice, ten jazyk má být jednoduchý na naučení (ne o moc složitější než java) a kód v něm má být dobře udržovatelný (jako v javě). Takže se právě naopak chce vyhnout zbrklému přidávání features stylem "kočička pejsek".
Ať počítám, jak počítám, jmenujete čtyři různé cíle. A vyjmenováváte jednotlivé fíčury, které samy o sobě jsou nepochybně dobré. Akorát že dobrý dort nevzniká tím, že se dá na hromadu hodně dobrých ingrediencí.
Název: Re:Kotlin nebo Scala pro backend?
Přispěvatel: Idris 04. 11. 2020, 13:04:20
Jenže tam chybí nějaký cíl, něco, co by to zastřešilo, dalo to jazyku nějaký smysl. U Javy, Scaly, Go, C++, Rustu, C, JavaScriptu, TypeScriptu, Pythonu, Perlu nebo PHP dokážu ten jazyk charakterizovat jednou větou. V případě Kotlinu to nedokážu – resp. jedna věta by byla o tom, jak Kotlin vznikl, ne k čemu je určen.

Kotlin je určen ke všemu, k čemu je určena java. Má mít kompaktnější syntax (properties, data classes, switch expressions, lambdy, type inference, template strings....  něco z toho se později dostává do javy..). Má být bezpečnější pro "průmyslové použití" tj návrhem preventivně bránit částým chybám (null safe calls, == vs ref. equality..). "Průmyslové použití" pro mne znamená  velký projekt, kde kód píše hodně lidí s různými úrovněmi znalosti.  Zároveň, do třetice, ten jazyk má být jednoduchý na naučení (ne o moc složitější než java) a kód v něm má být dobře udržovatelný (jako v javě). Takže se právě naopak chce vyhnout zbrklému přidávání features stylem "kočička pejsek".
A řekl bych, že úspěšně.
Tak určitě je lepší než Java. To je ale hodně nízká laťka.
Název: Re:Kotlin nebo Scala pro backend?
Přispěvatel: Idris 04. 11. 2020, 13:09:34
hrozne tristi sily a pokroku to spis skodi nez prospiva
A v čem by sis teda představoval ten pokrok? Aby to dle tvého nebylo plejtvání?
To jsou strašné žvásty. Touto logikou je plýtvání každý základní výzkum. Naopak toto “plýtvání” je z dlouhodobého hlediska největším přínosem pro celý obor obecně, o jednotlivé jazyky prakticky nejde. Dělící čára běží mezi zvídavými, bystrými jedinci a konzervativní, tupou masou.

Když už jsme u té zvídavosti, jak ses popral s tou intuicionistickou logikou? Dalo ti to něco?
Název: Re:Kotlin nebo Scala pro backend?
Přispěvatel: premekv 04. 11. 2020, 14:11:40
Kotlin je určen ke všemu, k čemu je určena java. Má mít kompaktnější syntax (properties, data classes, switch expressions, lambdy, type inference, template strings....  něco z toho se později dostává do javy..). Má být bezpečnější pro "průmyslové použití" tj návrhem preventivně bránit částým chybám (null safe calls, == vs ref. equality..). "Průmyslové použití" pro mne znamená  velký projekt, kde kód píše hodně lidí s různými úrovněmi znalosti.  Zároveň, do třetice, ten jazyk má být jednoduchý na naučení (ne o moc složitější než java) a kód v něm má být dobře udržovatelný (jako v javě). Takže se právě naopak chce vyhnout zbrklému přidávání features stylem "kočička pejsek".
Ať počítám, jak počítám, jmenujete čtyři různé cíle. A vyjmenováváte jednotlivé fíčury, které samy o sobě jsou nepochybně dobré. Akorát že dobrý dort nevzniká tím, že se dá na hromadu hodně dobrých ingrediencí.

No, proč vlastně trváme na tom, že nový jazyk má mít jeden "zastřešující" cíl a mít jeden nosný důvod pro svoji existenci? Co když vezmu něco stávajícího a to jenom vylepším resp. něco v tom fixnu? Vím, že ten výchozí jazyk je "ultra konzervativní" a proto není šance, že bych (alespoň v dohledném čase) mohl ovlivnit ten. On si časem nějaké ty fíčury přebere. A nebo nepřebere/nemůže, i když by to pro něj bylo dobré, ale důležitější je třeba zpětná kompatibiltita. Když ten můj nový jazyk navíc zapadne do ekosystému, má veškerou podporu toolů atd. tak ok ne? "Dobrota" dortu se měří tím, kolika lidem "chutná". V čem konkrétně je podle vás ten jazyk nekonzistentní (kočkopes)?

Podle wikipedie kotlin začal někdy 2010, 2011 ho oficiálně uvolnili, java 8 byla 2014. V době kdy Kotlin začínal, v té javě něco evidentně bolestně chybělo. To není objektivní argument, ale subjektivní výsledek pozorování (dělal jsem tehdy šéfa menšího týmu vývojářů v jedné bance). Pamatuju si, jaké urputné boje u nás u developerů nastaly za nasazení javy 8 do produkce. Hlavně šlo tedy o ty lambdy, že...  To bylo slávy, když se na tu osmičku konečně i v tom zabetonovaném korporátu přešlo. Skoro to bylo na nějakou bouřlivou oslavu. Ajťáci, no. Nikdy potom už něco takového nepamatuju. Třeba jsme nijak nebojovali o to, aby se java 12 rozšířila na javu 14 :) To je každému jedno. Tak tam opsové nasadí novou javu no. Ta 8čka byl nějaký zlom. Dokonce takový, že valná část lidí zbranže mi připadá, že dělí javu na "před osmičkou a tu s těma lambdama". Pro mladou generaci je java < 8 už asi něco jako pevná linka/fax. Vidí to v retrofilmech, používali to tátové, ale.... brr No to jsem se nechal trochu unést populismem. Vemte si, ale, za 3 roky java začala dokulhávat tam, kde už byli ostatní..

Nejde to jenom shodit na hezčí syntax. Jde i o ty filozofické změny (třeba nullable typy), které přinesly větší bezpečnost. (Dobře, aby mohl mít člověk objekt. srovnání, musel by asi naprogramovat a běžet totéž v K a javě a porovnávat počet NPE za časovou jednotku.). Nejde jen ale o nullable reference.

Jeden příklad z praxe za všechny. V projektu jsem kdysi refaktoroval field z int na Integer. V kódu na jednom místě zůstalo porovnávání přes ==. Unit testy prošly (pracovaly s dostatečně malými čísly :)) Bum problém "na produkci". Jasně, chyba obsluhy. Ale já alibisticky doteď trvám na tom, že kdo to takhle celé navrhnul, udělal bug v návrhu. Dokonce to bude kombinace více bugů v návrhu. Typový systém v Kotlinu je bugfix.  (Jasně, kdybych býval tehdy ten kód prohnal přes nějaké PMD nebo jinou statickou analýzu kódu, býval bych to asi chytil.  IDEčka tehdy nebyla na takové úrovni, těm to bylo jedno. Dneska už by IDEA svítila na tom "dvojpodtržítku" žlutou barvou jak pampeliška -- statická analýza/IDE je ale berlička).
Název: Re:Kotlin nebo Scala pro backend?
Přispěvatel: premekv 04. 11. 2020, 14:39:00
Jenom ještě doplním, dneska už má java takovou množinu fíčur a zejména! IDE (IntelliJ) je na tak vysoké úrovni, že sám necítím potřebu třeba na ten Kotlin na projektu přecházet. Ale nevadilo by mi ho používat (něco jsem v tom zkoušel). Ten jazyk se mi líbí, ale to, že budu dělat v kotlinu pro mne není "selling point". Řekl bych "jo, jasně" ale na zadnici si nesednu. Notabene už znám temná zákoutí javy (naše partnerství - někdy bolestivé - trvá velmi dlouho). Osvojil jsem si nějaké zvyky. Tak třeba v kódu, za který zodpovídám, striktně trvám na používání nonnull, nullable anotací (jedno z toho, jsou výlučné, já konzistentně používám @Nullable) u parametrů metod (pomůže to statické analýze a pro dokumentační účely při review atd. Co je @Nullable musí projít nullcheckem než se to dereferencuje.).  Strojová analýza kódu je samozřejmostí (stačí opět to, co je v IDEA, je to podle mne na velmi vysoké úrovni). Přesto, zrovna dneska zase řeším nějaký pitomý NPE v logu... chjo

Vemte si,. kde byl ekosystém a IDEčka javy před 10 lety (už na slušné úrovni ale zdaleka ne jako teď). Motivaci lidí pro jiný jazyk plně chápu.

Třeba to == vs. equals() u Integerů bylo těch 10 let zpátky skvělé téma u přijímacích pohovorů. Oddělit zelenáče (s falečným pocitem, že java je bezpečná a rozumí ji) od profíka, co zná internals. Jeden z "top 10 java interview questions" co jsem si prošel před pohovorem (a často to stačilo :D) Co pamatuju, tak druhý bod bylo sčítání Stringů.  Jiný význam tyhle věci ale nemají. Jsou to prostě quirks. Budu chtít častěji používat equals test nebo checkovat, že jde o stejnou referenci? Tipuju to první. Co je intuitivnější použít - "rovnítko operátor" nebo metodu equals? Rovnítko Tak proč se pro ten častější účel nepoužívá to rovnítko? Modernější jazyky to tak mají, java už to změnit nemohla.
Zní to jako blbost, my jsme tehdy s kolegou zažili poměrně pernou situaci.

Jazyk diktovaný architekty může vést k tomu, že mám pak třídu pro kalendář, která indexuje měsíce od nuly. Čistě akademicky logické. Teď už si jenom mnu jizvu po vícenásobné šlápnutí na tyhle vidle a importuju lepší pokus o datetime třídu (jo, práce s časovými zónami bývala také pohádka o zlém vlkovi). Komunita to fixla a připravila knihovnu, kterou pak všichni používali (protože ty vestavěné byly diplomaticky řečeno obtížněji použitelné). Java ji pak přebrala jako tu interní. Nevznikl trochu "pes-kočička dort"? Nekupí se náhodou v té javě "bad parts", které je dnes lepší nepoužívat ale jsou tam, protože java vrstvila věci co jsou "demodé" ale nemohla/nechtěla se jich zbavit.

Znovu říkám, javu mám rád.
Název: Re:Kotlin nebo Scala pro backend?
Přispěvatel: Ondrej Nemecek 04. 11. 2020, 15:59:38
Java má pitomá a neintuitivní generika a na cokoli trochu zavánějící pozdní vazbou se musí použít reflexe, i když by de fakto stačila interface. To jsou podle mě největší bolesti javy.
Název: Re:Kotlin nebo Scala pro backend?
Přispěvatel: Filip Jirsák 04. 11. 2020, 16:16:39
No, proč vlastně trváme na tom, že nový jazyk má mít jeden "zastřešující" cíl a mít jeden nosný důvod pro svoji existenci?
Protože zkušenost říká, že to jinak nefunguje. Když honíte moc zajíců, nechytíte nakonec ani jednoho.

Co když vezmu něco stávajícího a to jenom vylepším resp. něco v tom fixnu?
Pokud v tom vylepšíte jedu věc, je to jeden cíl. Pokud si tu věc k fixnutí nevyberete úplně špatně, bude výsledek fungovat.

V čem konkrétně je podle vás ten jazyk nekonzistentní (kočkopes)?
Vy jste ale psal o tom, že se něco (tj. jedna věc) fixne. To ale není případ Kotlinu.

Podle wikipedie kotlin začal někdy 2010, 2011 ho oficiálně uvolnili, java 8 byla 2014. V době kdy Kotlin začínal, v té javě něco evidentně bolestně chybělo. To není objektivní argument, ale subjektivní výsledek pozorování (dělal jsem tehdy šéfa menšího týmu vývojářů v jedné bance). Pamatuju si, jaké urputné boje u nás u developerů nastaly za nasazení javy 8 do produkce. Hlavně šlo tedy o ty lambdy, že...  To bylo slávy, když se na tu osmičku konečně i v tom zabetonovaném korporátu přešlo. Skoro to bylo na nějakou bouřlivou oslavu. Ajťáci, no. Nikdy potom už něco takového nepamatuju. Třeba jsme nijak nebojovali o to, aby se java 12 rozšířila na javu 14 :) To je každému jedno. Tak tam opsové nasadí novou javu no. Ta 8čka byl nějaký zlom. Dokonce takový, že valná část lidí zbranže mi připadá, že dělí javu na "před osmičkou a tu s těma lambdama". Pro mladou generaci je java < 8 už asi něco jako pevná linka/fax. Vidí to v retrofilmech, používali to tátové, ale.... brr No to jsem se nechal trochu unést populismem. Vemte si, ale, za 3 roky java začala dokulhávat tam, kde už byli ostatní..
To všechno je pravda. Ale nic z toho neříká, že když vezmu jazyk a naskládám do něj bez ladu a skladu půlku zajímavých věcí, které jsem potkal v jiných jazycích, že to jako celek bude dobře fungovat. Ostatně, kdyby to fungovalo, Kotlin by musel být úplná hvězda vzhledem k tomu, kolik sladkostí se tam přidalo.

Nejde to jenom shodit na hezčí syntax. Jde i o ty filozofické změny (třeba nullable typy), které přinesly větší bezpečnost. (Dobře, aby mohl mít člověk objekt. srovnání, musel by asi naprogramovat a běžet totéž v K a javě a porovnávat počet NPE za časovou jednotku.). Nejde jen ale o nullable reference.
Vlamujete se do otevřených dveří. Celou dobu říkám, že ty jednotlivosti jsou super. Každé to jednotlivé cukrátko z Kotlinu bych chtěl mít v jazyce, ve kterém budu psát. Akorát že, jak už jsem psal, jenom poskládat na hromadu ty hezké vlastnosti nestačí. Neumím to pořádně pospat, je to jenom můj dojem, ale podle mne programovací jazyk (stejně jako spousta dalších věcí) musí mít nějakou vnitřní logiku, systém, jednotlivé věci do sebe musí hezky zapadat. Je to jako s matematickými nebo fyzikálními teoriemi – ty opravdu zajímavé jsou pozoruhodně krásné, elegantní, věci do sebe hezky zapadají. I jejich matematické vyjádření bývá překvapivě stručné. Kotlin je pro mne ošklivý, ježatý, ty fíčury z něj trčí na všechny strany. Jsou jiné moderní jazyky, které se nechlubí tím, jak mají spoustu fíčur, ale vidím v nich nějakou vnitřní logiku – třeba Go, pravděpodobně i Rust. Vedle toho jsou staré jazyky, které se dokážou modernizovat a přijmout do sebe i dost odlišnou novinku – ale pěkně se to spojí s původním jazykem a nová verze je opět kompaktní a na první pohled nepoznáte, co tam bylo přidáno. Java takhle třeba přijala lambdy – počáteční návrhy byly dost hrozné, v diskusích jsem se o nich nevyjadřoval hezky, ale postupně se to otesalo a našel se tvar, který do Javy nakonec docela dobře zapadl. JavaScript dokázal přidat spoustu drobných vylepšení a pořád to drží pohromadě, v podobě TypeScriptu se dokonce přidal typový systém a pořád to jako celek dává dobrý smysl.

Jeden příklad z praxe za všechny. V projektu jsem kdysi refaktoroval field z int na Integer. V kódu na jednom místě zůstalo porovnávání přes ==. Unit testy prošly (pracovaly s dostatečně malými čísly :)) Bum problém "na produkci". Jasně, chyba obsluhy. Ale já alibisticky doteď trvám na tom, že kdo to takhle celé navrhnul, udělal bug v návrhu. Dokonce to bude kombinace více bugů v návrhu. Typový systém v Kotlinu je bugfix.  (Jasně, kdybych býval tehdy ten kód prohnal přes nějaké PMD nebo jinou statickou analýzu kódu, býval bych to asi chytil.  IDEčka tehdy nebyla na takové úrovni, těm to bylo jedno. Dneska už by IDEA svítila na tom "dvojpodtržítku" žlutou barvou jak pampeliška -- statická analýza/IDE je ale berlička).
Ano, primitivní typy v Javě jsou chyba návrhu, i když pochopitelná a omluvitelná dobou vzniku. Ale je to přesně ta věc, která tam nepatří, trčí z toho. Přidáte do jazyka novou vlastnost, na vše ostatní se to pěkně naváže – jenom primitivní typy to rozbijou. Přitom v době vzniku Javy byly podle mne primitivní typy přesně to cukrátko, které tam chce každý mít.
Název: Re:Kotlin nebo Scala pro backend?
Přispěvatel: Ink 04. 11. 2020, 18:12:25
Ano, primitivní typy v Javě jsou chyba návrhu, i když pochopitelná a omluvitelná dobou vzniku. Ale je to přesně ta věc, která tam nepatří, trčí z toho. Přidáte do jazyka novou vlastnost, na vše ostatní se to pěkně naváže – jenom primitivní typy to rozbijou. Přitom v době vzniku Javy byly podle mne primitivní typy přesně to cukrátko, které tam chce každý mít.

Podle mě to je přesně naopak. Primitivní typy jsou OK, chyba je, že Java nemá nic jako přetížení operátorů a že šla příliš radikálně cestou OOP. Porovnávání přes .equals() je rovnák na vohejbák, v každém normálním jazyce == porovnává hodnoty a ne reference.
Název: Re:Kotlin nebo Scala pro backend?
Přispěvatel: okalousek 04. 11. 2020, 18:15:44
Neumím to pořádně pospat, je to jenom můj dojem, ale podle mne programovací jazyk (stejně jako spousta dalších věcí) musí mít nějakou vnitřní logiku, systém, jednotlivé věci do sebe musí hezky zapadat. Je to jako s matematickými nebo fyzikálními teoriemi – ty opravdu zajímavé jsou pozoruhodně krásné, elegantní, věci do sebe hezky zapadají. I jejich matematické vyjádření bývá překvapivě stručné.
Zkuste Haskell.
Název: Re:Kotlin nebo Scala pro backend?
Přispěvatel: BoneFlute 04. 11. 2020, 18:37:11
Jenže tam chybí nějaký cíl, něco, co by to zastřešilo, dalo to jazyku nějaký smysl. U Javy, Scaly, Go, C++, Rustu, C, JavaScriptu, TypeScriptu, Pythonu, Perlu nebo PHP dokážu ten jazyk charakterizovat jednou větou. V případě Kotlinu to nedokážu – resp. jedna věta by byla o tom, jak Kotlin vznikl, ne k čemu je určen.

Kotlin je určen ke všemu, k čemu je určena java. Má mít kompaktnější syntax (properties, data classes, switch expressions, lambdy, type inference, template strings....  něco z toho se později dostává do javy..). Má být bezpečnější pro "průmyslové použití" tj návrhem preventivně bránit částým chybám (null safe calls, == vs ref. equality..). "Průmyslové použití" pro mne znamená  velký projekt, kde kód píše hodně lidí s různými úrovněmi znalosti.  Zároveň, do třetice, ten jazyk má být jednoduchý na naučení (ne o moc složitější než java) a kód v něm má být dobře udržovatelný (jako v javě). Takže se právě naopak chce vyhnout zbrklému přidávání features stylem "kočička pejsek".
A řekl bych, že úspěšně.
Tak určitě je lepší než Java. To je ale hodně nízká laťka.
Chtěl jsem tu jen oponovat pocitu, že Kotlin je dort pejska a kočičky mým pocitem, že naopak Kotlin je docela pěkně konzistentní.

Osobně mi přijde taky málo, ale to je už jinej příběh.
Název: Re:Kotlin nebo Scala pro backend?
Přispěvatel: BoneFlute 04. 11. 2020, 18:43:57
hrozne tristi sily a pokroku to spis skodi nez prospiva
A v čem by sis teda představoval ten pokrok? Aby to dle tvého nebylo plejtvání?
To jsou strašné žvásty. Touto logikou je plýtvání každý základní výzkum. Naopak toto “plýtvání” je z dlouhodobého hlediska největším přínosem pro celý obor obecně, o jednotlivé jazyky prakticky nejde. Dělící čára běží mezi zvídavými, bystrými jedinci a konzervativní, tupou masou.
Mě to nevykládej.
Mám pocit, že stále čekám na ten přelomovej jazyk, který bude opravdu špička, a bude opět revoluce - stejně jako bylo ve své době Java, a později Python. Přijde mi, že to stálo přešlapuje na místě - občas se objeví něco nadějného (Scala, Rust, Elm), ale pak mám pocit, že se do toho bojí pořádně fláknout, protože vývojáři konzervy by to odmítly... (Go, Kotlin)


Když už jsme u té zvídavosti, jak ses popral s tou intuicionistickou logikou? Dalo ti to něco?

Něco málo. Nebyl čas  ;D
Název: Re:Kotlin nebo Scala pro backend?
Přispěvatel: okalousek 04. 11. 2020, 19:27:35
A jaký je váš názor na Scalu?
Název: Re:Kotlin nebo Scala pro backend?
Přispěvatel: Idris 04. 11. 2020, 22:08:40
Mám pocit, že stále čekám na ten přelomovej jazyk, který bude opravdu špička, a bude opět revoluce - stejně jako bylo ve své době Java, a později Python. Přijde mi, že to stálo přešlapuje na místě - občas se objeví něco nadějného (Scala, Rust, Elm), ale pak mám pocit, že se do toho bojí pořádně fláknout, protože vývojáři konzervy by to odmítly... (Go, Kotlin)
To je otázka, co přelomového se dá ještě přinést. Zatím to na žádnou revoluci nevypadá.
Název: Re:Kotlin nebo Scala pro backend?
Přispěvatel: Filip Jirsák 04. 11. 2020, 22:29:26
Mám pocit, že stále čekám na ten přelomovej jazyk, který bude opravdu špička, a bude opět revoluce - stejně jako bylo ve své době Java, a později Python. Přijde mi, že to stálo přešlapuje na místě - občas se objeví něco nadějného (Scala, Rust, Elm), ale pak mám pocit, že se do toho bojí pořádně fláknout, protože vývojáři konzervy by to odmítly... (Go, Kotlin)
Nemyslím si, že by Java nebo Python byly nějaká revoluce. Právě naopak, dostaly se na špičku právě proto, že neexperimentovaly s ničím zásadně novým, jenom hezky zabalily to,co už se osvědčilo jinde. A dělají to dodnes. Ono se málokdy podaří něco udělat hned na první pokus dobře, takže ty revoluční jazyky, které přijdou s něčím opravdu novým, jenom krátce zazáří a pak zmizí, protože je převálcují nástupci, kteří byli sice pomalejší, ale mohli se tím pádem poučit z chyb.
Název: Re:Kotlin nebo Scala pro backend?
Přispěvatel: okalousek 05. 11. 2020, 09:19:54
Ano. Jako s Go. To není ani revoluce, ani evoluce, je to vlastně jen Céčko, kde je nějaká základní "objektová" podpora, mnohem větší standardní kníhovna, GC a CSP. Ale spousta věcí z 15-ti let vývoje programování byla prostě zahozena.
Název: Re:Kotlin nebo Scala pro backend?
Přispěvatel: BoneFlute 05. 11. 2020, 18:48:43
Ano. Jako s Go. To není ani revoluce, ani evoluce, je to vlastně jen Céčko, kde je nějaká základní "objektová" podpora, mnohem větší standardní kníhovna, GC a CSP. Ale spousta věcí z 15-ti let vývoje programování byla prostě zahozena.

Python byl revoluce. Go pak přenesl tu prošlapanou cestičku do kompilovaného světa (plus pár skvělejch nápadů, abych mu nekřivdil).
Název: Re:Kotlin nebo Scala pro backend?
Přispěvatel: Idris 05. 11. 2020, 19:36:51
Ano. Jako s Go. To není ani revoluce, ani evoluce, je to vlastně jen Céčko, kde je nějaká základní "objektová" podpora, mnohem větší standardní kníhovna, GC a CSP. Ale spousta věcí z 15-ti let vývoje programování byla prostě zahozena.
Python byl revoluce. Go pak přenesl tu prošlapanou cestičku do kompilovaného světa (plus pár skvělejch nápadů, abych mu nekřivdil).
V čem byl Python revoluce? Beru třeba Lisp nebo Smalltalk, ale proč Python?
Název: Re:Kotlin nebo Scala pro backend?
Přispěvatel: okalousek 05. 11. 2020, 19:53:17
Python byl revoluce. Go pak přenesl tu prošlapanou cestičku do kompilovaného světa (plus pár skvělejch nápadů, abych mu nekřivdil).

Go se hodně liší od Pythonu. Jazyk Go je hodně "upovídaný" narozdíl od Pythonu který by měl být "stručný ale přehledný". Když nemá Go generika tak buď dělám pro všechno vlastní funkci nebo přes reflexi, což je hodně neelegantní záležitost. Dokonce i Python má výjimky, Go má chybu jako druhou návratovou hodnotu. Go má hodně "boilerplate". Tak nevím, Go a Python mi přijdou jako diametrálně odlišné jazyky.
Název: Re:Kotlin nebo Scala pro backend?
Přispěvatel: BoneFlute 06. 11. 2020, 01:36:13
Ano. Jako s Go. To není ani revoluce, ani evoluce, je to vlastně jen Céčko, kde je nějaká základní "objektová" podpora, mnohem větší standardní kníhovna, GC a CSP. Ale spousta věcí z 15-ti let vývoje programování byla prostě zahozena.
Python byl revoluce. Go pak přenesl tu prošlapanou cestičku do kompilovaného světa (plus pár skvělejch nápadů, abych mu nekřivdil).
V čem byl Python revoluce? Beru třeba Lisp nebo Smalltalk, ale proč Python?

Python přinesl úplně jiný způsob myšlení - Python Zen. Možnost napsat jasně myšlenku, neřešit implementační detaily (práce s pamětí, práce s chybami), možnost nebát se, že ta aplikace spadne. Osvobození se od starého chápání typů jak bylo v C. Osvobození od nutnosti psát romány jak je v Javě. A hlavně to přinesl pro obyčejný lid, a prosadil to.

Smalltalk? Lisp? Jo, jasně, všichni jsme to znali. Ale tyto revoluce zůstali jen v hlavách autorů. Python se prosadil.

Z dnešního pohledu je Python nudný, nezajímavý a nic neumějící. Ale tehdá neměl konkurenci. Bylo to zjevení.
Název: Re:Kotlin nebo Scala pro backend?
Přispěvatel: Idris 06. 11. 2020, 03:23:52
Ano. Jako s Go. To není ani revoluce, ani evoluce, je to vlastně jen Céčko, kde je nějaká základní "objektová" podpora, mnohem větší standardní kníhovna, GC a CSP. Ale spousta věcí z 15-ti let vývoje programování byla prostě zahozena.
Python byl revoluce. Go pak přenesl tu prošlapanou cestičku do kompilovaného světa (plus pár skvělejch nápadů, abych mu nekřivdil).
V čem byl Python revoluce? Beru třeba Lisp nebo Smalltalk, ale proč Python?

Python přinesl úplně jiný způsob myšlení - Python Zen. Možnost napsat jasně myšlenku, neřešit implementační detaily (práce s pamětí, práce s chybami), možnost nebát se, že ta aplikace spadne. Osvobození se od starého chápání typů jak bylo v C. Osvobození od nutnosti psát romány jak je v Javě. A hlavně to přinesl pro obyčejný lid, a prosadil to.

Smalltalk? Lisp? Jo, jasně, všichni jsme to znali. Ale tyto revoluce zůstali jen v hlavách autorů. Python se prosadil.

Z dnešního pohledu je Python nudný, nezajímavý a nic neumějící. Ale tehdá neměl konkurenci. Bylo to zjevení.
Hmm, asi jsem jiná generace, za mého mládí byl pro “obyčejný lid” Basic.
Název: Re:Kotlin nebo Scala pro backend?
Přispěvatel: okalousek 06. 11. 2020, 10:04:29
Hmm, asi jsem jiná generace, za mého mládí byl pro “obyčejný lid” Basic.
Navíc se v něm [Pythonu] programují i velké byznysové aplikace.
Název: Re:Kotlin nebo Scala pro backend?
Přispěvatel: SB 06. 11. 2020, 11:31:42
Smalltalk? Lisp? Jo, jasně, všichni jsme to znali. Ale tyto revoluce zůstali jen v hlavách autorů. Python se prosadil.

Aha, takže revoluci lidu možno, ale nesmí jí být moc, jen tak trochu, aby to lid zvládl pobrat. Rozumím.
Název: Re:Kotlin nebo Scala pro backend?
Přispěvatel: Ink 06. 11. 2020, 11:50:54
Smalltalk? Lisp? Jo, jasně, všichni jsme to znali. Ale tyto revoluce zůstali jen v hlavách autorů. Python se prosadil.

Aha, takže revoluci lidu možno, ale nesmí jí být moc, jen tak trochu, aby to lid zvládl pobrat. Rozumím.

Lisp má neoblíbenou syntaxi, Smalltalk má neoblíbenou sémantiku. Vyhrál pragmatismus, ale to, co z nich je osvědčené, se v různých podobách prosadilo. To je dobrý výsledek, ne?
Název: Re:Kotlin nebo Scala pro backend?
Přispěvatel: jano6 06. 11. 2020, 13:19:37
Java má pitomá a neintuitivní generika a na cokoli trochu zavánějící pozdní vazbou se musí použít reflexe, i když by de fakto stačila interface. To jsou podle mě největší bolesti javy.

Pre mňa je to neexistencia obyčajných funkcií. Túto nepochopiteľnú chybu okopírovali aj v C#; potom
sa to snažili nejako napraviť cez built-int delegáty, ale nie je to ono.
Podľa mňa to vyplýva z toho, že Java je ako sa dnes hovorí opinionated jazyk; všetko musí byť objektovo.
Pre veľkú časť úloh objektové programovanie nie je potrebné a dokonca je zbytočné. Nemožnosť tvoriť
obyčajné funkcie zabrzdil rozvoj Javy ako jazyka a oproti moderným jazykom pôsobí zastaralo. Nuž, keď
sa raz základy zle postavia, tak už stavbu neprerobíme.

Název: Re:Kotlin nebo Scala pro backend?
Přispěvatel: Tomas-T 06. 11. 2020, 13:37:05
Pre mňa je to neexistencia obyčajných funkcií. Túto nepochopiteľnú chybu okopírovali aj v C#; potom
sa to snažili nejako napraviť cez built-int delegáty, ale nie je to ono.
Podľa mňa to vyplýva z toho, že Java je ako sa dnes hovorí opinionated jazyk; všetko musí byť objektovo.
Pre veľkú časť úloh objektové programovanie nie je potrebné a dokonca je zbytočné. Nemožnosť tvoriť
obyčajné funkcie zabrzdil rozvoj Javy ako jazyka a oproti moderným jazykom pôsobí zastaralo. Nuž, keď
sa raz základy zle postavia, tak už stavbu neprerobíme.
Když si v aplikaci uděláš jednu statickou Common třídu (nebo klidně víc podle zaměření, když by jich bylo moc), tak její metody můžeš používat úplně stejně jako obyčejné funkce - nebo ne? 
Název: Re:Kotlin nebo Scala pro backend?
Přispěvatel: okalousek 07. 11. 2020, 18:29:58
No ano, ale proč to tak dělat? Kotlin i Scala umí vnořit funkci do funkcí (pro interní použití), nemusíte si na vše dělat třídu, jsou tam tzn. singletony
Název: Re:Kotlin nebo Scala pro backend?
Přispěvatel: Filip Jirsák 07. 11. 2020, 18:53:57
Podľa mňa to vyplýva z toho, že Java je ako sa dnes hovorí opinionated jazyk; všetko musí byť objektovo.
Pre veľkú časť úloh objektové programovanie nie je potrebné a dokonca je zbytočné. Nemožnosť tvoriť
obyčajné funkcie zabrzdil rozvoj Javy ako jazyka a oproti moderným jazykom pôsobí zastaralo. Nuž, keď
sa raz základy zle postavia, tak už stavbu neprerobíme.
Podívejte se na funkce v JavaScriptu. Jsou to obyčejné funkce a zároveň objekty.
Název: Re:Kotlin nebo Scala pro backend?
Přispěvatel: okalousek 07. 11. 2020, 20:28:28
Podľa mňa to vyplýva z toho, že Java je ako sa dnes hovorí opinionated jazyk; všetko musí byť objektovo.
Pre veľkú časť úloh objektové programovanie nie je potrebné a dokonca je zbytočné. Nemožnosť tvoriť
obyčajné funkcie zabrzdil rozvoj Javy ako jazyka a oproti moderným jazykom pôsobí zastaralo. Nuž, keď
sa raz základy zle postavia, tak už stavbu neprerobíme.
Podívejte se na funkce v JavaScriptu. Jsou to obyčejné funkce a zároveň objekty.
mi
JS je z hlediska designu extrémně primitivní.
Název: Re:Kotlin nebo Scala pro backend?
Přispěvatel: jano6 07. 11. 2020, 23:15:10
Citace
V čem byl Python revoluce? Beru třeba Lisp nebo Smalltalk, ale proč Python?

No zrejme nie vo features, ktoré má, ale možno je Python revolúciou preto, že sa doslova
masovo rozšíril. Je to jazyk aj pre nie programátorov. Pre veľa ľudí, pre ktorých sú
excelové funkcie už nedostatočné. To sa v histórii nepodarilo žiadnemu jazyku.

Citace
Když si v aplikaci uděláš jednu statickou Common třídu (nebo klidně víc podle zaměření, když by jich bylo moc),
tak její metody můžeš používat úplně stejně jako obyčejné funkce - nebo ne?

Stále tam musíme napísať tú Common triedu, ďalej je tam statický kontext, ktorý všetko len zamotáva.
A takéto statické  metódy nemožno použiť všade, kde by sa dala použiť bežná funkcia; viď tzv higher-order funkcie.

Citace
Podívejte se na funkce v JavaScriptu. Jsou to obyčejné funkce a zároveň objekty.

No to áno, to je v pohode, takto to majú aj Python či Ruby. Problém je, že v Jave či C#  metódy
nie sú ani jedno.
Název: Re:Kotlin nebo Scala pro backend?
Přispěvatel: listoper 08. 11. 2020, 14:46:31

A takéto statické  metódy nemožno použiť všade, kde by sa dala použiť bežná funkcia; viď tzv higher-order funkcie.


Co presne tam je za problem?
Název: Re:Kotlin nebo Scala pro backend?
Přispěvatel: okalousek 09. 11. 2020, 00:00:23
Pokud by se Java naučila brát za arugmenty funkce/metody (lambdy se nepočítají)
Název: Re:Kotlin nebo Scala pro backend?
Přispěvatel: listoper 09. 11. 2020, 06:24:54
Pokud by se Java naučila brát za arugmenty funkce/metody (lambdy se nepočítají)

A to neumi?
Název: Re:Kotlin nebo Scala pro backend?
Přispěvatel: okalousek 09. 11. 2020, 08:02:17
Pokud by se Java naučila brát za arugmenty funkce/metody (lambdy se nepočítají)

A to neumi?

Pravda, co se dívám tak Java 8 to umí.
someMethod (this::anotherOne);
Název: Re:Kotlin nebo Scala pro backend?
Přispěvatel: Filip Jirsák 09. 11. 2020, 10:44:23
Pokud by se Java naučila brát za arugmenty funkce/metody (lambdy se nepočítají)
Co znamená „lambdy se nepočítají“? Lambda je přece anonymní funkce. Jediné, co byste mohl chtít navíc, je možnost reflexí zkoumat předanou funkci, to opravdu Java neumí.
Název: Re:Kotlin nebo Scala pro backend?
Přispěvatel: jano6 09. 11. 2020, 12:22:26
Citace
Co presne tam je za problem?

Reagoval som na použitie statických metód; tie neexistenciu obyčajných funkcií nevyriešia, ale
pridávajú vlastné problémy (statická metóda môže volať len statickú metódu a pracovať so statickými
atribútmi.)

Citace
Co znamená „lambdy se nepočítají“? Lambda je přece anonymní funkce.
Jediné, co byste mohl chtít navíc, je možnost reflexí zkoumat předanou funkci, to opravdu Java neumí.

Opravte ma ak sa mýlim, ale lambda sa len tvári ako anonymná funkcia. Je to len syntaktický
konštrukt, z ktorého kompiler spraví objekt. Java bohužiaľ nemá bežné funkcie, len metódy.
A tie nie sú first-class.

Čo bolo pridané v Java 8 je vohejbák. Java stále nemá obyčajné funkcie, len cez funkcionálne rozhrania
sa okľukou vytvárajú objekty a volajú potom metódy.

Kód: [Vybrat]
public class Example {
 
    public static void main(String args[]) {
 
        Function <Integer, Integer> inc = e -> e + 1;
        doSum(5, inc);
 
    }
 
    public static void doSum(int value, Function <Integer, Integer> func) {
        System.out.println(func.apply(value));
    }
}

Ono to vyzerá ako funkcia, ale nie je.
Je to celé komplikované. Java pridala do jazyka celý rad preddefinovaných rozhraní
kvôli uľahčeniu práce, ale faktom je, že nemáme funkcie, len objekty a ich metódy.
Každú "funkcia" potrebuje mať vlastné rozhranie napr:

Kód: [Vybrat]
@FunctionalInterface
public interface Consumer<T> {
    void accept(T t);
}

Porovnajme si to s JavaScript kódom:

Kód: [Vybrat]
function inc(val) {
    return val + 1;
}

function dec(val) {

    return val - 1;
}

function double(val) {

    return val * 2;
}

function halve(val) {

    return val / 2;
}

let pipeline = [inc, halve, dec, double];

let res = pipeline.reduce((total, fn) => {
   
  return fn(total);
}, 9);

console.log(res);

Je to elegantný, jednoduchý, ale veľmi expresívny kód. Žiadne statické metódy, žiadne
funkcia musí byť v classe, žiadne vohejbáky ako @FunctionalInterface alebo delegáty (C#).
Jednoduchý priamočiary kód.

Váčšina moderných programovacích jazykov má obyčajné funkcie, vrátane jazykov Python, PHP, JavaScript, Rust,
Go, Ruby, C++, F#, ...

Preto som napísal, že podľa mňa to je neexistencia obyčajných funkcií najväčšia chyba v dizajne Javy.
Název: Re:Kotlin nebo Scala pro backend?
Přispěvatel: listoper 09. 11. 2020, 13:13:46
Citace
Co presne tam je za problem?

Reagoval som na použitie statických metód; tie neexistenciu obyčajných funkcií nevyriešia, ale
pridávajú vlastné problémy (statická metóda môže volať len statickú metódu a pracovať so statickými
atribútmi.)


A ja reagoval na tohle:
Citace
A takéto statické  metódy nemožno použiť všade, kde by sa dala použiť bežná funkcia; viď tzv higher-order funkcie.

A zajima me jakej problem s pouzitim statickych metod v souvislosti s higher-order funkcemi.


a ted me teda jeste zajima tohle:
Citace
statická metóda môže volať len statickú metódu a pracovať so statickými atribútmi.

Prijde mi to jako trochu absurdni si na tohle stezovat kdyz si zacal diskuzi tim, ze jave chybi obycejne funkce.
Funkce prece nemuze sama od sebe sahat na instancni promenne nejakeho objektu pokud na nej nema referenci.
A pokud staticke metode predam jako parametr referenci na nejaky objekt tak muze bez problemu volat instanci metody a pracovat s jeho promennyma.
Název: Re:Kotlin nebo Scala pro backend?
Přispěvatel: Filip Jirsák 09. 11. 2020, 13:14:25
Opravte ma ak sa mýlim, ale lambda sa len tvári ako anonymná funkcia. Je to len syntaktický
konštrukt, z ktorého kompiler spraví objekt.
Na tom přece nezáleží, co s tím udělá kompilátor. To bychom tu jinak neměli žádné objektové ani funkcionální jazyky – kompilátor to nakonec stejně vždy přeloží do imperativního kódu, protože dnešní procesory nic jiného neumí.

Java bohužiaľ nemá bežné funkcie, len metódy.
A tie nie sú first-class.
JVM nemá běžné funkce, jen metody, které nejsou first-class. Java jako jazyk má lambdy, které jsou first-class a metody jsou na ně převoditelné.

Čo bolo pridané v Java 8 je vohejbák. Java stále nemá obyčajné funkcie, len cez funkcionálne rozhrania
sa okľukou vytvárajú objekty a volajú potom metódy.
Nenazýval bych to vohejbákem, lambdy se nakonec podařilo do Javy integrovat hezky. Java byla navržena jako plně objektový jazyk (až na ty nešťastné primitivní typy), takže to, že jsou lambdy objekty, je v Javě správně.

Preto som napísal, že podľa mňa to je neexistencia obyčajných funkcií najväčšia chyba v dizajne Javy.
Java je záměrně navržená tak, že má malou základní sadu vlastností. Jsem silně přesvědčený o tom, že díky tomu se Java tak rozšířila. Takže to, co vy označujete za největší chybu dizajnu Javy, je podle mne naopak velká výhoda a příčina takového rozšíření. Že se Java nehodí na vše? Ano, to je samozřejmě pravda, jsou věci, pro které je JavaScript vhodnější než Java. Ale tak už tu máme GraalVM, kde můžete spouštět Javu i JavaScript.
Název: Re:Kotlin nebo Scala pro backend?
Přispěvatel: Ondrej Nemecek 09. 11. 2020, 16:47:21
Citace
Preto som napísal, že podľa mňa to je neexistencia obyčajných funkcií najväčšia chyba v dizajne Javy.

No to je argument stylu „největší chyba javy je, že to není javascript“.

Na skriptování v java ekosystému použijte třeba Groovy, Beanshell, jshell.
Název: Re:Kotlin nebo Scala pro backend?
Přispěvatel: okalousek 10. 11. 2020, 10:32:24
Asi se budu muset naučit oba a využívat dle situace ;)
Název: Re:Kotlin nebo Scala pro backend?
Přispěvatel: A.P.Hacker 10. 11. 2020, 10:39:23
Citace
Preto som napísal, že podľa mňa to je neexistencia obyčajných funkcií najväčšia chyba v dizajne Javy.

No to je argument stylu „největší chyba javy je, že to není javascript“.

Na skriptování v java ekosystému použijte třeba Groovy, Beanshell, jshell.

jak souvisi obycejne funkce se skriptovanim?
Název: Re:Kotlin nebo Scala pro backend?
Přispěvatel: listoper 10. 11. 2020, 10:53:10
Citace
Preto som napísal, že podľa mňa to je neexistencia obyčajných funkcií najväčšia chyba v dizajne Javy.

No to je argument stylu „největší chyba javy je, že to není javascript“.

Na skriptování v java ekosystému použijte třeba Groovy, Beanshell, jshell.

jak souvisi obycejne funkce se skriptovanim?

To zalezi na tom co je to "obycejna funkce". Na to bysme potrebovali definici od autora terminu - Jano6.
Ja si to z toho ,co zatim rekl vykladam tak, ze mu vadi ze v jave tam musi napsat navic slovo static a ze to musi byt definovane uvnitr nejake tridy a pak uz to teda neni dost obycejne.

A pak souvislost se skriptovanim vidim v tom, ze script (typicky mensi velikost) je zahlcen nadbytecnym balastem.
U vetsiho programu to "tolik" nevadi, protoze procento balastu vuci uzitecnemu kodu byde vyznamne mensi.
Název: Re:Kotlin nebo Scala pro backend?
Přispěvatel: Ondrej Nemecek 10. 11. 2020, 16:49:03
Citace
Preto som napísal, že podľa mňa to je neexistencia obyčajných funkcií najväčšia chyba v dizajne Javy.

No to je argument stylu „největší chyba javy je, že to není javascript“.

Na skriptování v java ekosystému použijte třeba Groovy, Beanshell, jshell.

jak souvisi obycejne funkce se skriptovanim?

To zalezi na tom co je to "obycejna funkce". Na to bysme potrebovali definici od autora terminu - Jano6.
Ja si to z toho ,co zatim rekl vykladam tak, ze mu vadi ze v jave tam musi napsat navic slovo static a ze to musi byt definovane uvnitr nejake tridy a pak uz to teda neni dost obycejne.

A pak souvislost se skriptovanim vidim v tom, ze script (typicky mensi velikost) je zahlcen nadbytecnym balastem.
U vetsiho programu to "tolik" nevadi, protoze procento balastu vuci uzitecnemu kodu byde vyznamne mensi.

Vidím to podobně. V reálném programu je potřeba balast na organizaci kódu, takže se ta režie ve výsledku vyplatí.

Rozvolnění kódu, duck-typing a podobně by se mi v javě taky občas hodilo, nicméně na to můžu použít celkem bezbolestně třeba to Groovy a to i v existujícím java projektu. Nebo použít jiný jvm jazyk.
Název: Re:Kotlin nebo Scala pro backend?
Přispěvatel: okalousek 10. 11. 2020, 20:40:34
S dovolením bych se vrátil k původní otázce.

Scala vs Kotlin -> Co se na co "hodí"?