Scala vs. Java 8.

[javaman ()]

Nevím, jak to může být triviální, když je to jiný přístup k programování Právě takové to učení z Idei mi přijde nejhorší. Sice nevím proč, ale udělal jsem to, co mi řekla.

Takže pokud někde mají zaplacený aplikáč, který jede na komerční Javě, tak já jim řeknu, že jsou lopaty a smažu jim ho, ne? Samozřejmě tyhle projekty skoro nedělám, ale když prostě někam přijdeš, je to tam a třeba děláš jen nějakou maličkost na pár měsíců, tak proč ne. Ne všude můžeš rozjet projekt na nejnovějším Bootu a 5.

Já znám vývojáře, kteří chtějí dělat na kvalitních věcech a technologie není moc podstatná. Asi každý preferujeme jiné lidi. Starý dobře napsaný kód bude pořád hezký.

[Reklama]

[dustin]

Nevím, jak to může být triviální, když je to jiný přístup k programování

FP v javě využiješ jen v některých situacích, párkrát si to vyzkoušíš a pak už ti samo přijde, kdy by se to ti to hodilo. Typicky krátké kusy kódu, které se dřív řešily pomocnými třídami, často třeba enumy s metodami. Ve streamech je použití taky jednoduché a složitější kód si z lambdy stejně vytáhneš do metody, aby v tom nebyl bordel.

Právě takové to učení z Idei mi přijde nejhorší. Sice nevím proč, ale uděal jsem to, co mi řekla.

Kdyby sis to místo žvanění raději vyzkoušel. Idea ti pomůže hlavně se syntaxí a s maximálním zjednodušením kódu, sama za tebe smyčku do paralelizovatelného streamu neupraví. Ale rovnou ti třeba nabídne referenci na metodu místo ukecanějšího volání.

Takže pokud někde mají zaplacený aplikáč, který jede na komerční Javě, tak já jim řeknu, že jsou lopaty a smažu jim ho, ne? Samozřejmě tyhle projekty skoro nedělám, ale když prostě někam přijdeš, je to tam a třeba děláš jen nějakou maličkost na pár měsíců, tak proč ne. Ne všude můžeš rozjet projekt na nejnovějším Bootu a 5.

To je tvůj problém, jakou děláš práci. Já mám projekt své firmy pod plnou kontrolou a mohu si to udělat tak, jak potřebuju. Ale samozřejmě nečekám, že mi někdo bude platit za žvanění na rootu v pracovní době 300 litrů. Také svoje lidi nenazývám lopatami, ani začátečníky. A věř mi, že si hodně vybírám, protože mě s nimi musí bavit dělat. A  baví, hodně.

Starý dobře napsaný kód bude pořád hezký.

To rozhodně. Nicméně když do něj doplníš generika, bude i bezpečnější a příjemnější na používání. A když při jeho úpravách a rozšířeních (nedávno ses tu kasal, že děláš "nové featury") použiješ moderní prostředky, bude rychlejší a možná některé jeho části půjde provozovat i paralelně a využívat tak naplno ty desítky jader v dnešních serverech.

Jenže je otázka, zda tebe úspěch projektů tvých klientů vůbec zajímá. Vykešovat a táhnout dál, za jiným manažerským hejlem, co ti dá za žvanění a vytahování balík, protože sám má za žvanění balík ještě větší.

[javaman ()]

Ahaaa, tak to jo. Myslím, že takhle to nefunguje.

Vím, co umí Idea, ale nemám rád lopaty, které říkají, že něco umí a pak z nich vypadne max to napovídání v Idea. Jde o to chápat principy.

Jsem ti jen vysvětlil, že ne všude mají cool Java 8. Demo pro zákazníka také můžu udělat na beta knihovnách a všichni budou koukat. Samozřejmě to nemůžu dát do produkce.

Pokud platíš lopatám málo, tak je jasné, že si musíš dobře vybírat.

Tzv. žvanění je důležité. Alespoň víš, co se dělá. Lopata si 12 hodin něco píše do počítače a nikdo neví.

[Radek Miček]

Navic vsechny testy srovnavajici performance ktere jsem videl ukazuji scalu jako pomalejsi nez javu.

V řadě případů však může být situace opačná - např., když vhodně použijete specializaci generik (nebo miniboxing nebo dotty linker). Jiným příkladem je fúze ve streamovacích knihovnách - viz třeba knihovna strymonas, která je na mikrobenchmarcích až 10x rychlejší než streamy z Javy 8.

[andy]

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

Recordy v haskellu jsou takové, jaké jsou, protože nikdo neví, jak to udělat líp V GHC8 jsou DuplicateRecordFields, ale moc nevím, na co to je, když stejně v jakémkoliv větším projektu začne člověk používat lensy. TypeClass na lensy použít nějak jde, IMO bad practice to ani není, ale když je pak víc recordů přes různé moduly, tak asi ten boilerplate nebude úplně jednoduchý - nějaký TemplateHaskell makro by to asi vyřešlo, ale myslím, že nic takového zatím není. Koukal, jsem, jak to je řešeno v purescriptu a vlastní používání mi připadá ještě horší.

Navíc typové třídy v Haskellu dovolují (víceméně) pouze jednu instanci typové třídy pro jeden typ (program s více instancemi GHC AFAIK neslinkuje) - implicity ve Scale toto omezení nemají. Někdo sice říká, že toto omezení je výhodné, ale na druhou stranu někdy je užitečné (a přirozené) mít více instancí - například aditivní i multiplikativní monoid.

No já Scalu neumím, takže mi není moc jasné, jak tohle funguje....  E.Kmett to popsal tak, že třeba Set nebo Map díky různým instancím nedokáže garantovat, že se to setřídění nezmění - je to tak, nebo se to v poslední době nějak zlepšilo?

[Reklama]

[Radek Miček]

E.Kmett to popsal tak, že třeba Set nebo Map díky různým instancím nedokáže garantovat, že se to setřídění nezmění - je to tak, nebo se to v poslední době nějak zlepšilo?

Nevím, co přesně myslel - samo od sebe se uspořádání nezmění. Problémy mohou nastat, když máte funkci, která pracuje se dvěma množinami a obě mají jiné uspořádání, ale funkce předpokládá, že obě mají stejné (vím, že některé funkce ve standardní knihovně jsou na to ošetřeny, nevím, zda všechny).

Navíc podobná věc se mohla (nevím, zda stále může??) stát i v GHC Haskellu - viz příklad na konci http://blog.ezyang.com/2014/07/type-classes-confluence-coherence-global-uniqueness/ - a tam na to funkce nejsou připraveny.

[Kit]

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

Recordy v haskellu jsou takové, jaké jsou, protože nikdo neví, jak to udělat líp

Co takhle je umístit do různých namespace?

[javaman ()]

Radku, ty ten výzkum používáš k čemu? Je to třeba normálně v práci a ostatní to ocení? A nebo to máš rád sám, takže třeba v práci bys dělal v jednom FP jazyce a ostatním se věnoval jako hobby?

[noef]

Co se tyce knihoven, tak celkem dost jich lze ve Scale pouzivat normalne jak z Javy. Na ty bezne veci jsou casto knihovny primo pro Scalu, se kterymi se ze Scaly pracuje prijemneji (napr. zadne null, Scali kolekce, DSL atp.). Co jsem se dival a zkousel (a cetl, osobne nevyvijim ve Scale pro penize), tak treba webove veci s Play si lidi pochvalovali, podobne treba DB pristup se Slick, vetsina i Akku. Kdo chce vice hardcore FP tam ten muze sahnout po ScalaZ, Cats, Shapeless atp. Ale nejak do hloubky to zhodnotit nedokazu, pouze muzu rict, ze jsem zatim na to domaci vyvijeni* nenarazil na pripad, ze by Java knihovnu mela a Scala ne (at uz nativni, nebo stejnou Javi, ikdyz ty byvaji celkem otravne na pouzivani, kdyz jste zvykli na lepsi).

*: Normalni veci typu web crawler, multiplatformni GUI klikatko, pristup k souborum, JSON, Android (predevsim libGDX), jednoducha server-client aplikace.

Jak jsem psal vyse, pokud najimate hloupe nebo line vyvojare, nebo je nechcete zaucovat do lepsiho jazyka, ktery v zaveru poskytne nepreberne vyhod (vyssi abstrakce = mene kodu, lepsi citelnost, znovupouzitelnost), tak IMO najimate jen "lopaty" a casem se vam to vymsti. Podobne tragicky to vidim, kdyz se nesmi psat testy (o to horsi, pokud jde o dynamicke jazyky). Ano, muzete prejit na Go a najmout prvni skupinu mladych uchazecu, kteri v tom umi napsat Hello world, ale podle toho pak budou vypadat vase aplikace. Prasit se da ve vsem. Treba nedavno jsem videl kod na zjisteni kolize bodu vuci trojuhelniku v 2D v celych cislech, bylo to tusim v Jave a bylo to resene cykly pres vsechny body trojuhelniku...

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

Recordy v haskellu jsou takové, jaké jsou, protože nikdo neví, jak to udělat líp

Co takhle je umístit do různých namespace?

No, to ted pouzivam, ale neni to zadna slava:

Pouzivam kombinaci importu a qualified importu a kvuli tomu pribylo dost boiler platu a navic s kazdym novym record se musi upravovat build file

Jsem tak trochu rozmazleny z Java sveta (ve Scale je to stejne), ze pridam soubor a on se sam prida do buildu. Kdyz se pak pracuje s lens (nebo i jen temi "getter" funkcemi), tak se musi pouzivat qualified import na ne a je otravne a IMO celkem neprehledne.

Priklad jak to mam nyni (Orb a Vel jsou qualified imports, IMO to celkem kazi retezeni lens, ktere mohlo byt krasne intuitivni - nyni je tecka oddelovac importu i kompozice funkci):

Kód: [Vybrat]

oldVelX = orb^.Orb.velocity.Vel.x
A jak by to mohlo vypadat, kdyby Haskell umel pretezovani funkci (to by pak ty recordy byly i normalne pouzitelne):

Kód: [Vybrat]

oldVelX = orb^.velocity.x
Pouzivat type classy k tomuto ucelu mi prijde dost neprakticke (navic ani nevim, zda to vyresi problemy s kolizemi jmen auto-generovanych lens, tipl bych, ze spis nevyresi) a jak jsem psal, na vice mistech jsem cetl, ze pouzivat je vylozene k pretezovani funkci je bad practice, tak nevim...

Jako mozna neco delam a/nebo chapu spatne, jsem vecny Haskell zacatecnik, ktery se v tom pro zabavu placa .

[Kit]

Priklad jak to mam nyni (Orb a Vel jsou qualified imports, IMO to celkem kazi retezeni lens, ktere mohlo byt krasne intuitivni - nyni je tecka oddelovac importu i kompozice funkci):

Kód: [Vybrat]

oldVelX = orb^.Orb.velocity.Vel.x
A jak by to mohlo vypadat, kdyby Haskell umel pretezovani funkci (to by pak ty recordy byly i normalne pouzitelne):

Kód: [Vybrat]

oldVelX = orb^.velocity.x

Haskell se teprve učím, ale měl jsem spíš takovou představu:

Kód: [Vybrat]

oldVelX = orb^.Vel.x
Pleonasmy při programování totiž moc rád nemám a vyhýbám se jim, jak jen to jde.

Otázkou samozřejmě je, zda by to v této podobě fungovalo. Proč oldVelX není součástí modulu Vel? Pak by to bylo jen

Kód: [Vybrat]

oldX = x

[noef]

Kód: [Vybrat]

oldVelX = orb^.Orb.velocity.Vel.x

Haskell se teprve učím, ale měl jsem spíš takovou představu:

Kód: [Vybrat]

oldVelX = orb^.Vel.x
Pleonasmy při programování totiž moc rád nemám a vyhýbám se jim, jak jen to jde.

Otázkou samozřejmě je, zda by to v této podobě fungovalo. Proč oldVelX není součástí modulu Vel? Pak by to bylo jen

Kód: [Vybrat]

oldX = x

Ehm, asi nechapu. Ten zapis nelze zjednodusit (ne bez upravy importu, pripadne modulu s recordy), "Orb.velocity" je lens pro field "velocity" v "OrbState" record a "Vel.x" je lens pro field "x" ve "Velocity" record. Vzhledem k tomu, ze mam vice zaznamu, kde se vyskytuje field "x" (v mem pripade to "x" je lens, ale to je celkem jedno, ikdybych nepouzil lens tak chci "getter" a ten se bude jmenovat stejne), tak nemohu importovat vse z "Velocity" modulu, protoze bych dostal i "x :: Velocity -> Int" a to by kolidovalo s jinou fkci pro ziskani "x" z jineho zaznamu, napr. "x :: FilePos -> Int".

Mozna bych to mohl vysperkovat pouzitim mezer, ale porad je to IMO tezkopadne a hure prehledne.
Verze se zduraznenim, co je get operace a kompozice a co je namespace (ty jsou bez mezer).

Kód: [Vybrat]

oldVelX = orb ^. Orb.velocity . Vel.x
"oldVelX" se pouziva pri vypoctu zmeny stavu interpretu (neni to top level funkce) a tak mi prislo vhodnejsi umistit fci vedle ostatnich funkci interpretu, ktere se take zabyvaji zmenou stavu. A stejne to neresi problem, pokud se v "OrbState" pouziva dalsi zaznam, ktery ma field "x" (nebo jiny kolidujici), akorat jsem problem presunul jinam - z vyssi vrsty do nizsi vrstvy - do modulu s "OrbState" funkcemi.

Mozna se vyjadruju blbe. Jak pisu, taky se to ucim .

PS: Tady jsou ty importy:

Kód: [Vybrat]

import           Runtime.Data.OrbState              -- pouze typ, aby se nemuselo psat OrbState.OrbState
import qualified Runtime.OrbState            as Orb -- pomocne veci. qualified proto, aby napr. fce "position" nekolidovala s jinou fci pojmenovanou "position"

[noef]

Omlouvam se za predchozi off-topic, ted se pokusim o neco vice on-topic.

Funkcionální programování - nevím jestli s příchodem Javy 8 a třídy java.util.Stream to je ještě nějaká výhoda oproti Javě.

Ok, tak napr.: Ma Java nejakou lens knihovnu pro immutable typy? Scala ma treba Monocle (mnoho funkcionality, nejen lenses, ale take narocnejsi na nauceni se) nebo QuickLens (jednoduche, primocare, funkcni).

Immutable typy - taky věc, co se dá udělat i v Javě, prostě budu mít jen konstruktory a žádné metody na modifikaci.

Jiste, "da" se udelat, asi jako OOP v C, nebo garbage collector pro ASM...

A jak budete resit treba takovou prkotinu jako vytvareni noveho objektu se zmenenym jednim fieldem? Rucne si psat potrebne metody vracejici kopii objektu se zmenou? Ve Scale to za vas udela prekladac copy metodou, kterou navic muzete "zmenit" v kopii vice fieldu. Nebo pouzivat Lombok? Ktery ma nevyhody, jako napr. ze IDE s nim muze mit problemy, nebo ze i pres znacne usnadneni tam stale je boiler-plate (co jsem se dival, tak pro to kopirovani dve volani metody navic).

Actor model - po vzoru Erlangu lze mít objekty, které čekají na zprávy a ty potom zpracovávají. Tipuju, že to bude implementované teda nějak tak,
že po spuštění aplikace napsané ve Scale tam bude několik vláken, které budou sloužit pro zpracovávání zpráv z front jednotlivých Actorů.
Tohle by mělo být normálně možné udělat i v Javě, není to jakoby  vlastnost, které v Javě nelze docílit.

<Copy&paste prvni odstavec odpovedi k predchozimu bodu.>

Kód: [Vybrat]

    public static class Greeter extends UntypedActor {
        String greeting = "";

        public void onReceive(Object message) {
            if (message instanceof WhoToGreet)
                greeting = "hello, " + ((WhoToGreet) message).who;

            else if (message instanceof Greet)
                // Send the current greeting back to the sender
                getSender().tell(new Greeting(greeting), getSelf());

            else unhandled(message);
        }
    }

Kód: [Vybrat]

class Greeter extends Actor {
  var greeting = ""

  def receive = {
    case WhoToGreet(who) => greeting = s"hello, $who"
    case Greet           => sender ! Greeting(greeting) // Send the current greeting back to the sender
  }
}To vam fakt ta Javi verze prijde hezci a lepe citelna? Me rozhodne ne.

Klíčové slovo val, kdy pak není možné měnit proměnnou - Java má final

val ve Scale je vychozi a kratke, naopak pokud mame neco jako "Int final a = 4;" tak to final je navic a tudiz vychozi stav je mutable, coz znaci, ze FP je v jazyku neco navic => neni pro FP prizpusoben.

Akademická syntaxe - ta syntaxe je prostě taková, aby to nevypadalo jako Java

Ciste subjektivni. Cilem naopak bylo, aby to bylo hodne podobne Jave, coz pri nepouzivani FP a jen OOP celkem funguje (syntaxe je v tom pripade pomalu 1:1). Jako jestli mate problem s tim, ze genercike typy maji parametry v [] misto <>, nevim, pripada mi to jako prkotina. Nepovinne stredniky mi prijde velmi sympaticke v kazdem jazyce. Rozdily na teto nejnizsi urovni jsou opravdu velmi male.

Nechci, aby to vypadalo jako nějaký hejt Scaly

Tak to presne pusobi - vetsina bodu akorat znaci uplnou problematiky a/nebo Scaly.

, ale opravdu by mě zajímalo, proč bych to měl chtít na něco použít místo Javy, když bych si musel zvykat na tu syntaxi.

To zni jako nejake narky studentika, vzdyt ta zakladni syntaxe je, jak jsem psal, pomalu 1:1 mapovani na Javu. Vetsina (vse?) je akorat kratsi, je mene zavorek, slozenych zavorek, stredniku a dalsi nevyznamove omacky. Jiste, pokud mluvite o implicits, path-depedent typech a dalsi magie s typy, tak tam se to bude lisit, protoze Java nic takoveho nema .

Samozřejmě můžu dát pročítat články na netu, ale nějaká diskuze nemusí být od věci .

Doporucil bych si nejdrive precist o zakladech FP, protoze z vaseho prispevku je patrne, ze vam zalostne chybi (ne, pouzivani funkcni/metod nutne neznamena FP pristup). Take bych rad poznamenal, ze FP ve Scale bez dalsich knihoven je myslim spise zakladni (tvurce to zamyslel pro bezne vyvojare, nechtel z toho mit dalsi Haskell). Pokud chcete videt poradne FP, tak se podivejte na ScalaZ .

[Kit]

Ehm, asi nechapu. Ten zapis nelze zjednodusit (ne bez upravy importu, pripadne modulu s recordy), "Orb.velocity" je lens pro field "velocity" v "OrbState" record a "Vel.x" je lens pro field "x" ve "Velocity" record. Vzhledem k tomu, ze mam vice zaznamu, kde se vyskytuje field "x" (v mem pripade to "x" je lens, ale to je celkem jedno, ikdybych nepouzil lens tak chci "getter" a ten se bude jmenovat stejne), tak nemohu importovat vse z "Velocity" modulu, protoze bych dostal i "x :: Velocity -> Int" a to by kolidovalo s jinou fkci pro ziskani "x" z jineho zaznamu, napr. "x :: FilePos -> Int".

Mozna bych to mohl vysperkovat pouzitim mezer, ale porad je to IMO tezkopadne a hure prehledne.
Verze se zduraznenim, co je get operace a kompozice a co je namespace (ty jsou bez mezer).

Kód: [Vybrat]

oldVelX = orb ^. Orb.velocity . Vel.x
"oldVelX" se pouziva pri vypoctu zmeny stavu interpretu (neni to top level funkce) a tak mi prislo vhodnejsi umistit fci vedle ostatnich funkci interpretu, ktere se take zabyvaji zmenou stavu. A stejne to neresi problem, pokud se v "OrbState" pouziva dalsi zaznam, ktery ma field "x" (nebo jiny kolidujici), akorat jsem problem presunul jinam - z vyssi vrsty do nizsi vrstvy - do modulu s "OrbState" funkcemi.

Proč se ptáš přes jeden modul místo toho, aby ses zeptal přímo modulu Orb?

Kód: [Vybrat]

oldVelX = velocityX orb^
a do modulu Orb dopíšeš funkci velocityX.

[noef]

Ale to pak budu ten samy problem s "x" resit v modulu OrbState (je tam "position" a "velocity", oboje maji fieldy "x" a "y"). Navic si takhle budu muset rucne vyrabet getter funkce pro kazdy vnoreny field kazdeho record co OrbState obsahuje? A co pak setter funkce? To uz jsme jak v Jave... K tomu jsou ty lenses, aby se to nemuselo psat rucne. I kdybych pouzil "velocityX" reseni a smiril se s rucnim psanim vsech kombinaci getteru a setteru, tak ani to neni moc slavne reseni, protoze to predpoklada, ze vsude, kde budu pouzivat ten OrbState, tak nebude nic mit jedinny field stejny jako v OrbState (napr. Velocity), protoze pak by jmeno rucne vytvoreneho getteru (napr. "velocityX") samozrejmne kolidovalo s getterem toho druheho zaznamu pro jeho x ve velocity...

Ta ^. je jeden operator (getter), jmeno promenne je orb. To "Orb.velocity . Vel.x" znaci skladani lens, tj. z "OrbState" se zamer na "velocity" field a v nem na "x" field.

Jeste to zkusim pogooglit, jestli neco nenajdu. Posledne kdyz jsem to resil, tak jsem akorat nasel reseni prefixovat si vsechny fieldy jmenem recordu, coz me prijde hnusne a v podstate stejne, jako druhe reseni, tj. qualified importy. Bych prisahal, ze jsem nekde videl nejake reseni, ktere me ale dost desilo, protoze zapinalo dost lang. features a ja se v nich zatim nevyznam a nektere mohou vest k celkem velkym problemum (zmeni se semantika a/nebo syntaxe jazyka).

[bsmk]

samozrejme sa to stale nevyrovna scale, ale pomocou http://www.javaslang.io/ a https://immutables.github.io/ sa da aj v jave vela biolerplate kodu vyhnut.