Zobrazit příspěvky

Tato sekce Vám umožňuje zobrazit všechny příspěvky tohoto uživatele. Prosím uvědomte si, že můžete vidět příspěvky pouze z oblastí Vám přístupných.


Příspěvky - registrovany_ava

Stran: 1 2 [3] 4 5 ... 8
31
Vývoj / Re:Je Rust jazyk budoucnosti?
« kdy: 14. 11. 2020, 14:42:44 »
Mě RUST naprosto odrazuje syntaxí. Líbí se mi co to umí a jak to dělá, ale psát se mi v tom nechce. Podle mého názoru si hodně syntaxí ublížil v migraci lidí z C/C++, obzvlášť, když to je vlastně jeho cílovka.
Alespoň tak se mi to jeví.

Kód v rustu má tendence se zašmodrchat, ale pokud se člověk snaží to psát hezky, tak je to v pohodě.

Já mám opačnou zkušenost. Asi žádný jazyk mě zatím tolik nenutil kód rozšmodrchávat. Tím, že je naprosto striktní co se týče vlastnictví, sdílených a exkluzivních referencí, lifetimů, bezpečnosti přístupu z více vláken atp., člověka nutí kód předělávat, dokud tyhle věci nejsou jasné překladači, a jako vedlejší efekt většinou i programátorovi a čtenářům. Takže srovnatelnou funkcionalitu mi většinou v Rustu trvá déle implementovat, ale mám pak čistší, čitelnější a korektnější kód.

32
Vývoj / Re:Je Rust jazyk budoucnosti?
« kdy: 10. 11. 2020, 20:53:16 »
To nevím, ale má ošklivou syntaxi

Kód: [Vybrat]
fn vypis_obsah<T: MaObsah>(tvar: T) {
to mě odrazuje se o něj víc zajímat.

Možná se ti víc bude líbit novější

Kód: [Vybrat]
fn vypis_obsah(tvar: impl MaObsah) {
popř jaký zápis by se ti líbil víc?


33
Vývoj / Re:Je Rust jazyk budoucnosti?
« kdy: 10. 11. 2020, 20:50:42 »
S dovolením bych se vrátil k rustu. Docela by mě zajímalo, jestli se ten jazyk vůbec ještě vyvýjí. Mě totiž příjde takový napůl mrtvý.

Proč? Před lety, když jsem ho zkoušel, tak jsem skončil na TcpListeneru, kterému nebylo možné nastavit timeout (a taková služba se prostě musí sestřelovat a tudíž je téměř nepoužitelná). Tenkrát jsem rust odložil jako jazyk ještě ve vývoji. Nic méně dívám se, že i po letech tahle základní funkcionalita pořád chybí. Exsituje sice crate net2, který vypadá, že by to mohl doplnit, ale tohle už mělo být dávno doplněné ve std. knihovně.

Neví někdo, jak je to s vývojem rustu? Tohle totiž moc živě nevypadá.

Ano, Rust se "vyvýjí". https://blog.rust-lang.org/2020/05/15/five-years-of-rust.html

34
Vývoj / Re:Je Rust jazyk budoucnosti?
« kdy: 06. 11. 2020, 20:18:07 »
Nedávno jsem četl docela zajímavý článek: https://ferrous-systems.com/blog/rust-as-productive-as-kotlin/

35
Vývoj / Re:Je Rust jazyk budoucnosti?
« kdy: 06. 11. 2020, 09:17:33 »
- jeden subor je jeden modul (maju to aj ine jazyky, ale je to taka strasna blbost)
- premature optimalization na UTF-8 stringy, to sposobiilo, ze sa zo stringami pracuje naozaj zle, a kcoli tomu ma Rsut sam o sebe prilis vela typov stringov (str, String,  CStr,...)
- async/await len v preview

S těmi moduly je to pravda jen částečně, systém modulů v Rustu umožňuje snadno přes exporty zveřejnit jinou strukturu, než jaká je v souborech. Jeden modul jeden soubor je sane default. Mě se s tím pracuje dobře.

Ta "premature optimization" je zase sane default, ze kterého se dá utéct pomocí jiných stringových typů. Většinou ale pracuješ s UTF-8, a ta obtížná práce s ním je spíš principiální - UTF-8 je prostě složité na manipulaci, než špatný návrh jazyka/knihovny.

- async/await len v preview - není pravda.

36
Vývoj / Re:Je Rust jazyk budoucnosti?
« kdy: 06. 11. 2020, 09:13:28 »
Ten split() je rozhodnutí tvúrcú API, ne?
Ano, ale u jazyka se neohodnotí jen jazyk, ale hlavně také standardní knihovna, ekosystém okolo a spousta věcí

1. Nevzniká Vec<&str>, ale impl Iterator<Item=&str>
2. Podle mě je to API naprosto v pořádku, co se ti nelíbí? Když splitnu String, dostanu iterátor přes pohledy do toho splitnutého stringu (tedy iterátor přes typ &str), jak lépe by to mělo být?

37
Vývoj / Re:Kotlin nebo Scala pro backend?
« kdy: 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ů..?

38
Vývoj / Re:Kotlin nebo Scala pro backend?
« kdy: 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.

39
Vývoj / Re:Kotlin nebo Scala pro backend?
« kdy: 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..

40
Vývoj / Re:Kotlin nebo Scala pro backend?
« kdy: 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ě.

41
Vývoj / Re:Kotlin nebo Scala pro backend?
« kdy: 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.

42
Vývoj / Re:Kotlin nebo Scala pro backend?
« kdy: 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.

43
Vývoj / Re:Discriminated unions v C++
« kdy: 26. 10. 2020, 18:32:23 »
Pro pořádek dodám i variantu s typy None a AnotherCurrency

Super, díky moc. Pro mě je zajímavé zajímavé srovnat si tohle řešení s řešením od Fortrana, který použil čistý std::variant bez wrapování double do tagovaných typů (tedy jeho řešení bylo nejblíž původnímu zadání, tvoje je zas asi idiomatičtější v C++, a o něco bezpečnější).

44
Vývoj / Re:Discriminated unions v C++
« kdy: 25. 10. 2020, 08:44:41 »
...To si láskavo nechaj pre niekoho iného, ja na to naozaj nie som vôbec zvedavý. Nemyslím si totiž, že niekto, kto odpoveď s riešením zásadného problému s vynechaním marginálnych a triviálnych záležitostí, považuje za odpoveď na úplne inú otázku, má nárok rozdeľovať nejaké pochvaly...

Rozdělovat pochvaly jsi začal ty, proto ta jízlivost ode mě (skutečně asi trochu přehnaná). Já bych se taky mohl urazit, že jsi nepochválil mojí odpověď, která uváděla na pravou míru tazatelovu domněnku, že std::variant neumožňuje víc variant stejného typu. Umožňuje (https://stackoverflow.com/a/43116041/3220468), a je to zásadní vlastnost součtového typu, která se v jazycích s first-class podporou součtového typu zcela běžně používá. Bohužel, v C++ praxi se zdá, že takový std::variant je natolik nepraktický na používání, že je lepší ty typy nějak odlišit (tagování, wrapnutí).

45
Vývoj / Re:Discriminated unions v C++
« kdy: 24. 10. 2020, 10:17:42 »
C++ baví z viacerých dôvodov (je univerzálne, je rozšírené, dá sa tam hrať z detailami a optimalizovať, je to hlavný jazyk pre Unreal Engine, je to jazyk orientovaný na rýchlosť, nič pred programátorom neskrýva atď).

Řekl bych, že o Rustu to všechno platí taky až na "rozšířené" (to se doufám změní :-) a "hlavní jazyk pro Unreal Engine" (to chápu, že může být blocker). Ale nechci ho nikomu vnucovat.

Stran: 1 2 [3] 4 5 ... 8