Kotlin nebo Scala pro backend?

[BoneFlute]

... ale (to (je (pro ( mě (extrém)))) a myslím že i pro mnoho lidí.

To je mýtus.

[Reklama]

[okalousek]

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ť).

[jano6]

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.

[listoper]

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)

[okalousek]

Svým způsobem je Lisp velice elegantní jazyk, ne?

[Reklama]

[listoper]

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 

[registrovany_ava]

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ů..?

[Google CTCCTCGGCGGGCACGTAG]

Mě se na Clojure zásadně nelíbí (osobní preference) absence statických typů.

https://www.youtube.com/watch?v=YR5WdGrpoug

[listoper]

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 obcas... a kdysi sem si hral s https://github.com/arohner/spectrum.

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

[Ink]

S tim sem si nikdy nehral...
Pouzivam https://clojure.org/guides/spec obcas... a kdysi sem si hral s 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.

[listoper]

S tim sem si nikdy nehral...
Pouzivam https://clojure.org/guides/spec obcas... a kdysi sem si hral s 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.

[Ink]

Chapu co rikas, ale nejak nechapu souvislost s tim co citujes.

Co jsi tedy myslel timhle:

kontrolovat typy pri kompilaci je trochu pozde ze?

[listoper]

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.

[Ink]

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ší.

[listoper]

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:

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.