Scala vs. Java 8.

[klw]

...
...java...
...

No to zase bude flejm...

[Reklama]

[noef]

Dost kritiky Scaly v tomto vlakne je nepravdiva a/nebo neaktualni. XML jazyk opousti (nebo uz opustilo?), komunita si naopak stezuje, ze novych veci je pomalu a vyvoj je prilis pomaly (takze pro to prave korporatni pouziti je uz asi zrala ). Pouzivat Akku z Javy je hruza - strasne moc boilerplatu. Je to podobne jako s Play, pokud nepouzijete Scalu, tak to neni o nicem, protoze nevyuzijete nejvetsi vyhody knihovny.

Syntaxe Scaly me prijde lepsi nez treba Javy, mene ukecana, vice k veci. Neprijde mi dobry ten pristup "on ten boiler plate muze vygenerovat IDE" - proc tam musi byt boilerplate, kdyz se stejne vzdy generuje? Akorat to IMO znecitelnuje kod.

Python nemam rad a stejne tak pristup "pouze jeden zpusob". Ja mam radeji na vyber a pouziju nejvhodnejsi pristup pro dany problem, ne ze jsem omezeny na jeden univerzalni pristup a ten je mi vnucen jako "vzdy nejlepsi pro kazdy problem". Kvuli tomu treba v Pythonu je FP dost tragicke, mel bych psat asi spis "FP".

A argument, ze s Java 8 jde krasne psat FP stejne/lepe nez ve Scale ci ze s Java 8 uz Scala neni potreba? Uz jsem na nazor podobneho ignoranta reagoval na quore, tak to jen znovu shrnu. V Jave stale hodne veci chybi, napr. lepsi typovy system (treba implicits, path-dependent typy), case classes, for comprehensions, pattern matching s extractory (nejen match statement, ale i pro val), neprekonane kolekce* (nesrovnatelne s Javou, kde se vse musi vselijak obalovat a vybalovat), moznost psat DSL, strucnejsi syntaxe (tzn. mene nevyznamoveho balastu). Mam pocit, ze i uplne zaklady typu Option (v Jave myslim Optional) mely v Jave dost kriticke problemy. Problem lamdb a vyjimek v Jave tu uz nekdo uvadel.

Scala rozhodne neni dokonala, ma problemy (jak nekdo zminil, obcas bugy v prekladaci, velikost std. knihovny [problem na starsich Androidech], problemy s obfuscatory, spatna podpora maker v IDEA, ne vzdy funguje typova inference, pomalejsi preklad), ale jeji vlastnosti ty drobne problemy v pohode prevazi (nemalo jich vyresi prave Dotty). Scala je stale, co se funkci tyce, mnoho kroku pred Javou.

*: Po pravde jsem zatim v zadnem jinem jazyce nenasel lespi std. knihovnu pro kolekce (obsahem, inuitivnosti, konzistenci [napr. flatMap pro Option i List]).

A jen tak mimochodem ani ten Haskell neni nejaky zlaty gral. Si hraju s prekladacem a intepretem jazyka v Haskellu a treba records jsou dost za trest - Haskell nepodporuje (primo) pretezovani funkci, takze v jednom namespacu zadny record (neco jako struct nebo case class) nesmi mit stejne pojmenovane fieldy, protoze pak koliduji jmena getteru (pripadne jmena lens). (Ano, vim, jde pouzit type classy, ale co jsem cetl, tak je to bad practice. Pouzivam kombinaci importu a qualified importu a kvuli tomu pribylo dost boiler platu a navic s kazdym novym record se musi upravovat build file ) Trochu pokukuji po OCamlu, ktery vypada, ze tyto problemy nema, ale zatim jsem nemel moc casu se na neho podivat blize.

[Radek Miček]

*: Po pravde jsem zatim v zadnem jinem jazyce nenasel lespi std. knihovnu pro kolekce (obsahem, inuitivnosti, konzistenci [napr. flatMap pro Option i List]).

Bohužel kolekce ve Scale mají i svou temnou stranu. Například co přesně dělá následující kód?

Kód: [Vybrat]

Map(8 -> "osm").map(_._1)

Jaký je statický typ? Jaká kolekce je vrácena skutečně? Pokud tomu kódu chceme porozumět, je třeba si uvědomit, že se jedná o zkratku za

Kód: [Vybrat]

Predef.Map.apply(Predef.ArrowAssoc(8).->("osm")).map(((x$1) => x$1._1))(Iterable.canBuildFrom)

tedy statický typ je Iterable[Int] a vrácená kolekce je List. Na první pohled to není vůbec zřejmé, ale když jde o výkon, je důležité to vědět.

[Radek Miček]

BTW nedávno jsem sepsal poznámky popisující pár základních vlastností Scaly, třeba se to někomu bude hodit:

• Základy Scaly
• Základy Scaly – 2. část

[noef]

Jiste, kolekce ve Scale nejsou dokonale (ostatne typovy system zaplatil cenu za snahu byt nejak kompatibilni s Javou a nutnosti behu na JVM), ale co do pouzitelnost jsem opravdu nenasel lepsi. Rozsirovat nejakou Scala kolekci neni take uplne primocare a bez znalosti implementacnich detailu celkem obtizne (ano, i to jsem si zkusil ). K tomu vykonu - nepouzivaji se v pripade opravdove starosti o vykon spise specializovane knihovny?

Jeste jsem zapomnel na to, ze v Jave jsou lambdy, kdezto ve Scale closure (doufam, ze jsem to neprohodil). V Jave se v lambde nemuzete odkazovat na vnejsi promennou (myslim funguje pouze pro final, nebo takove podobne omezeni), ve Scale to neni problem (podobne jako v JavaScriptu).

Moc jsem Go ani Kotlin nestudoval, ale neprisly mi nicim moc vyjimecne. Prinasi neco navic oproti treba te Scale? Jedinne o cem v Kotlinu vim, co vypada dobre, je podpora proxy primo v jazyce (potreboval jsem to nekolikrat pri praci s Javovskymi tridami, ktere jsem nemohl upravovat). Go vypada jako tuctovy jazyk, podle slov jejich vyvojaru zamereny na rychle nauceni se, coz moc jako kvalitu nevnivam. Proc mit dalsi Python (nebo cokoliv jineho), kdyz nauceni se jazyka mi potrva zlomek casu (treba tyden/mesic), nez samotna prace v jazyce (roky)?

The key point here is our programmers are Googlers, they’re not researchers. They’re typically, fairly young, fresh out of school, probably learned Java, maybe learned C or C++, probably learned Python. They’re not capable of understanding a brilliant language but we want to use them to build good software. So, the language that we give them has to be easy for them to understand and easy to adopt.
– Rob Pike

Jazyk pro lopaty?

PS: Psani sem me donutilo si neco o Go precist a teda ten jazyk je tak neuveritelne zpatecnicky, ze se az divim, ze s tim prisel Google.
Why Go’s design is a disservice to intelligent programmers

[Reklama]

[Z]

Na skalu jsem se vyzadekijoval jen jsem viděl co všechno se v ní dá dělat. V tomhle jazyce se da neuveritelne prasit a v praxi ma misto jen ve velmi uzkem spektru aplikaci a situaci. Pocinaje Javou 8 a lambdama je uz uplnemimo misu. Navic vsechny testy srovnavajici performance ktere jsem videl ukazuji scalu jako pomalejsi nez javu.

[noef]

Prasata mate vsude, to neni nejaka nevyhoda jazyka. I v tom hloupouckem a omezenm Go se prasi pomoci reflexe, aby se prekonaly omezeni jazyka. Ja budu mit radeji jazyk, kde mam vetsi volnost a nemusim prasit z duvodu, ze to jinak nejde.

Jste si asi neprecetl vyse, co vsechno Java 8 pro rozumne praktikovani FP postrada. Jiste, pokud nechcete FP, vice ficur, expresivnejsi jazyk, lepsi typovy system, tak Scala moc neprinese, ale to jste v prve rade Scalu ani nemusel zvazovat, kdyz vam vyhovuje uzvanena Java se svymi omezenimi (o tom snad tento topic neni).

Ano, ve vetsine benchmarku je Scala o neco malo pomalejsi (nic dramatickeho), ale to se da cekat. Musim (spise pro pobaveni) ale rict, ze existuji i benchmarky, kdy je Scala rychlejsi nez Java (tusim, kdyz se benchmark lepe strefi do datovych struktur a optimalizaci prekladace Scaly).

[Z]

Jo to je sice hezke ze mas rad jazyk ve kterem mas volnost, nez budes muset pracovat po programátotech, kteří tu volnost měli taky a obzvláště když jsou z Indie nebo jsou to prOstě jen úplní začátečníci.
To si taky rikam, ze javascript je vlastne strasne fajn, dokud nemusim delat neco v appce kde se prehnalo stado prasat.

Protoze porad se jeste da vyznat v aplikaci, kterou psali indie-like programatori, kdyz ta aplikace pouziva jednoduche konstrukce a je napsana "flat" - a k tomu te primeje Java - nez v aplikaci psane radobyinteligentim koumakem, ktery do ni zasmudrchava jednu radobychytrou konstrukci za druhou, az je z toho gorDonsky uzel - a to nechci videt co by sesmolil ve scale.

[dustin]

Myslím, že se tu střetávají světy teoretické, které jazyky studují, a praktické, které v nich dodávají složité systémy s dlouhou historií i neustále se měnícími požadavky. Obojí je důležité, např. FP v javě ušetří spoustu času ryzímu praktikovi i ve velikém legacy systému, kdy rychle naráží na omezení a těší se na další verze, kde už snad budou omezení volnější (jo, checked exceptions). Stejně tak by ocenil hodnotové typy, to by zabránilo mrakům hloupých chyb. A reifikovaná generika mohou podstatně zpřehlednit kód, někdy se prostě to instanceof potřebuje. Všeho toho se java dočká http://literatejava.com/java-language/value-types-list-int-coming-java-10/ a hlavně díky světu teoretickému.

Nedávno jsem potřeboval zásadně zrychlit legacy kód se spoustou jednoduchých výpočtů nad velikými kolekcemi (stovky tisíc položek). Smyčky jsem jednoduše přehodil do streamů s lambda filtry a foreach, do nejrozsáhlejších jsem použil paralelní streamy a kolekce zaměnil za concurrent verze. Za necelé dvě hodiny celkem nenáročných úprav se doba výpočtu původně jednovláknového zpracování zkrátila na 8jádře ani ne na desetinu. A produkční server má těch jader 32. Jsem přesvědčený, že bez teoretických pokroků ve FP a jejich následného transferu do praxe v javě by tohle vůbec nebylo možné.

[Radek Miček]

Jo to je sice hezke ze mas rad jazyk ve kterem mas volnost, nez budes muset pracovat po programátotech, kteří tu volnost měli taky a obzvláště když jsou z Indie nebo jsou to prOstě jen úplní začátečníci.

To je možné, ale ne každý musí po takových programátorech pracovat.

Pokud si zvolíte jednoduchý jazyk, kde chybí řada abstrakcí, tak i když jste skvělý programátor, snadno skončíte s kódem, který není extra přehledný (protože nemáte k dispozici potřebné abstrakce).

[dustin]

To je možné, ale ne každý musí po takových programátorech pracovat.

Bohužel na déle běžících rozsáhlých projektech je to spíše pravidlo, než výjimka.

[javaman ()]

Můžu se zeptat, kde jste přišli k tolika informacím o FP? Protože není problém se to naučit, spíše kde to využít? Scala docela frčí i u nás a dají se najít pozice, ale takový záběr, jako máte, není úplně běžný. Když to srovnám s Javou, tak běžný Java vývojář o Javě moc neví, takže úroveň vašich znalostí je dost nad průměrem.

[dustin]

Rozhodně to nebyla otázka na mě, ale běžné FP v javě se slušnější vývojář naučí s podporou IDE (idea to rovnou nabízí) za pár použití, není to vůbec nic složitého. A postupně přidává Optional atd. Časem začne prskat, že má legacy kód checked exceptions a nemůže si FP usnadňovat práci. Kód se zkrátí a zrychlí.

Nechápu, jak architekt s tvým záběrem může toto nepoužívat a nevyžadovat. Ono to zřejmě bude všechno trochu jinak....

[javaman ()]

Na všechny tady

FP je až v 8, takže souhlasím, že naučit se to může i nováček. Problém je s tím, že dřív to tam nebylo a zároveň pokud nemáš základy FP, tak ty konstrukce nejsou moc příjemné. Další věc je, že jsou projekty, kde se jede na 6 a možná se brzy přejde na 7.

Jakože Java architekt bude dávat do projektů Scalu jen tak, aby byl cool? Jazyk je na Javě to méně podstatné. Nástroje a knihovny z toho dělají špičku.

[dustin]

FP jsme v životě nepoužívali a naučit se to v javě bylo triviální. Už jsem ti to psal několikrát. Obávám se, že je to tím, že to sám neumíš, protože sám nic neprogramuješ.

Náš systém má první commit v r. 2002, 32 tis. commitů, nějakých 10 tis. tříd a udržovat jej upgradovatelný na novou javu je jednou z důležitých priorit. Samozřejmě to obnáší i upgrade používaných knihoven. S každou novou verzí JVM se rychlost původního neupraveného kódu zvedla. Levný zisk. Priority přece ze své pozice určuješ ty, tak proč se oháníš omezeními v tvé pravomoci...

Vývojáři chtějí dělat na moderních technologiích, ne na dinosaurech (stejně jako chtějí dělat na pořádných mašinách a pořádných monitorech). Když už se musí vrtat ve starém kódu (to už tak prostě je), tak jej chtějí posouvat dopředu, aby do něj mohli svůj kód psát moderně a mohlo je to bavit.