Scala vs. Java 8.

[noef]

Wow, dik za tip, to vypada dost dobre. Se moc v Java knihovnach neorientuju (uz vubec ne v tech, co maji stejnou funkcionalitu jako Scala), ale obe knihovny vypadaji solidne. Pokud nekdy budu donucen delat v Jave, tak alespon vim, po cem sahnout .

[Reklama]

[Kit]

Ale to pak budu ten samy problem s "x" resit v modulu OrbState (je tam "position" a "velocity", oboje maji fieldy "x" a "y").

Ještě jsem přišel na jedno možné řešení:

Kód: [Vybrat]

oldVelX = Vector.x $ Orb.velocity $ orb
Je to bez dalších getterů - stačí deriving (Show). Je možné s tím jít do libovolné úrovně zanoření - pouze se tím prodlouží zápis. Zároveň se sloučí Pos a Vel do jednoho modulu Vector. Oba mají stejné fieldy, tak proč je oddělovat?

Trochu je mi záhadou, k čemu jsou ve FP settery. Také je mi divné, že potřebuješ souřadnici X a neptáš se po Y. Funkcionalita by se pak dala schovat do modulu Vector. Nemusel by ses v tomto modulu pachtit s komponentami X a Y, prostě bys pracoval s vektory.

[andy]

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.

Jojo, IMO myslel přesně tohle - a tohle je teda v GHC bug - tohle by tam jít nemělo. On to taky typechecker nebo linker chytí, ale jak je vidět, tak ne vždycky. A bohužel v GHC8 se to zkompiluje, a to i jako knihovna Naštěstí je to hodně výjimečná situace (je potřeba se dost snažit, aby se to povedlo), a i trochu proti best practice, ale zkompilovat by se to teda nemělo. Otázka je, jestli s backpackem k tomu nemůže docházet častěji.

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

Tak jsem se na to podíval - je na to makro makeFields, viz http://stackoverflow.com/questions/34617973/make-lenses-th-with-the-same-field-name-using-makeclassy. Tohle problém vyřeší a není to "bad practice"

Trochu je mi záhadou, k čemu jsou ve FP settery. Také je mi divné, že potřebuješ souřadnici X a neptáš se po Y. Funkcionalita by se pak dala schovat do modulu Vector. Nemusel by ses v tomto modulu pachtit s komponentami X a Y, prostě bys pracoval s vektory.

Lens jsou něco jako XPath, ale nad interními strukturami - které jsou v FP všechny immutable. Takž lens teda částečně řeší problém, který mimo FP nemusí řešit - tzn. modifikaci vnořených struktur. Ale z druhé strany je to neuvěřitelně flexibilní záležitost, speciálně s různým Travsersable, index lens apod. Navíc nejde jen o setter, ale je to FP - tak tam máš i "over". Tohle je trochu vycucané z prstu, ale máš třeba:

Kód: [Vybrat]

data A { _cislo :: Int, _...}
cache :: Map T.Text (Maybe A)
-- Přičti ke všem A._cislo v cache (tzn. Just hodnotám) jedničku
let res = cache & traverse . _Just . cislo %~ (+1)
Nedávno jsem řešil třeba modifikaci nějakého XMLka. Potřeboval jsem nastavit nějakou option - přidat do toho stromu na určité místo nějakou XML podstrukturu. Tohle vypadá dost hrozně..ale zkus si představit, jak bys to dělal v non-FP jazyce - tohle vypadá dost mutable díky State monadu - a "zoom" je nádstavba mimo jiné nad settery:

Kód: [Vybrat]

-- | Najde Phase konkretniho jmena
phaseWithName pname = svcPhases . traverse . phaseXml . nodes . filtered (\phase -> phase ^? tel "name" . text == Just pname)
-- | Najde konkretni option ve fazi
phaseOption optname = tel "options" . nodes . doption optname
... atd.
addMountConfig (Just (CopyMountParameters {..})) = do
      zoom (phaseWithName "Recover-Copy") $ do
        enabled .= "true"
        phaseOption "recoveryInstance" .= Just _cpInstance
        phaseOption "recoveryType" .= Just "recovery"
        phaseOption "dbRenameSuffix" .= Just _cpSuffix
      zoom (phaseWithName "Mount-Copy") $ do
        enabled .= "true"
        phaseOption "mountpath" .= Just _cpMountPath
        phaseOption "copyMetadataPath" .= Just _cpMountPath
        phaseOption "mounthost" .= Just _cpHost
        phaseOption "accesstype" .= Just "read-write"


[javaman ()]

A co andy, ty to děláš kde a proč? Vypadá to, že se o to také dost zajímáš. Děláš to v práci?

[Kit]

Nedávno jsem řešil třeba modifikaci nějakého XMLka. Potřeboval jsem nastavit nějakou option - přidat do toho stromu na určité místo nějakou XML podstrukturu. Tohle vypadá dost hrozně..ale zkus si představit, jak bys to dělal v non-FP jazyce

V PHP to dělám zcela běžně a vypadá to mnohem jednodušeji. Je fakt, že i ve FP se s tímto požadavkem musí nějak poprat.

[Reklama]

[Inkvizitor]

Nedávno jsem řešil třeba modifikaci nějakého XMLka. Potřeboval jsem nastavit nějakou option - přidat do toho stromu na určité místo nějakou XML podstrukturu. Tohle vypadá dost hrozně..ale zkus si představit, jak bys to dělal v non-FP jazyce

V PHP to dělám zcela běžně a vypadá to mnohem jednodušeji. Je fakt, že i ve FP se s tímto požadavkem musí nějak poprat.

Ukaž kód. ;-)

[ttt]

Pro duplicitní jména v rekordech haskellu jsem našel https://ghc.haskell.org/trac/ghc/wiki/Records/OverloadedRecordFields/DuplicateRecordFields. Přišlo mi, že to je přesně to, co chci příště použít, až s nimi budu mít problém. Má použití lens pro tento případ nějaké výhody?

[Kit]

Nedávno jsem řešil třeba modifikaci nějakého XMLka. Potřeboval jsem nastavit nějakou option - přidat do toho stromu na určité místo nějakou XML podstrukturu. Tohle vypadá dost hrozně..ale zkus si představit, jak bys to dělal v non-FP jazyce

V PHP to dělám zcela běžně a vypadá to mnohem jednodušeji. Je fakt, že i ve FP se s tímto požadavkem musí nějak poprat.

Ukaž kód. ;-)

Však se podívej na dokumentaci třídy DomDocument, tam najdeš vše potřebné.

[andy]

V PHP to dělám zcela běžně a vypadá to mnohem jednodušeji. Je fakt, že i ve FP se s tímto požadavkem musí nějak poprat.

Jak by to vypadalo v PHP? Já si to totiž třeba v pythonu představit umím, a rozhodně by to jednodušejce nevypadalo (i.e. to raw XMLko začíná až na phaseXml a ten zápis "phaseOption "recoveryInstance" .= Just _cpInstance" přidá/nahradí celou podstrukturu typu '<option><name>recoveryInstance</name><value>...</value></option>).

A co andy, ty to děláš kde a proč? Vypadá to, že se o to také dost zajímáš. Děláš to v práci?

Taky - proč? Protože to umožňuje výrazně efektivnější práci. Ale zas jsou větší požadavky na hlavu programátora

Pro duplicitní jména v rekordech haskellu jsem našel https://ghc.haskell.org/trac/ghc/wiki/Records/OverloadedRecordFields/DuplicateRecordFields. Přišlo mi, že to je přesně to, co chci příště použít, až s nimi budu mít problém. Má použití lens pro tento případ nějaké výhody?

Jo, protože lens jsou composable, zatímco ty record fields ne. Ono v jakkoliv složitějším programu v podstatě rychle přejdeš na lens, protože jiný způsob updatu vnořených struktur je silně nepraktický.

[javaman ()]

A co andy, ty to děláš kde a proč? Vypadá to, že se o to také dost zajímáš. Děláš to v práci?

Taky - proč? Protože to umožňuje výrazně efektivnější práci. Ale zas jsou větší požadavky na hlavu programátora

Je radost vidět lidi, kteří se o vývoj zajímají víc. To víš, z práce znám lopaty, které toho moc neumí. Takže to máš jako hlavní práci a nebo pro vylepšení práce? Jak jsem tu psal, Scala se dá najít docela jednoduše, ale asi žádná pecka práce to nebude. Ale třeba Haskell má využití kde? Dovedu si to představit třeba pro administrátora, protože on má volnost v jazycích. U vývojáře je to složitější.

[David]

A co andy, ty to děláš kde a proč? Vypadá to, že se o to také dost zajímáš. Děláš to v práci?

Taky - proč? Protože to umožňuje výrazně efektivnější práci. Ale zas jsou větší požadavky na hlavu programátora

Je radost vidět lidi, kteří se o vývoj zajímají víc. To víš, z práce znám lopaty, které toho moc neumí. Takže to máš jako hlavní práci a nebo pro vylepšení práce? Jak jsem tu psal, Scala se dá najít docela jednoduše, ale asi žádná pecka práce to nebude. Ale třeba Haskell má využití kde? Dovedu si to představit třeba pro administrátora, protože on má volnost v jazycích. U vývojáře je to složitější.

Javamane kdybys nebyl lopata tak by ses podival na web Haskellu kde je to uvedeno. Nicmene pro lopaty to sem napisu. Jednak je to seznam uvedeny v https://wiki.haskell.org/Haskell_in_industry a taky https://www.quora.com/Which-companies-use-Haskell

[javaman ()]

A co andy, ty to děláš kde a proč? Vypadá to, že se o to také dost zajímáš. Děláš to v práci?

Taky - proč? Protože to umožňuje výrazně efektivnější práci. Ale zas jsou větší požadavky na hlavu programátora

Je radost vidět lidi, kteří se o vývoj zajímají víc. To víš, z práce znám lopaty, které toho moc neumí. Takže to máš jako hlavní práci a nebo pro vylepšení práce? Jak jsem tu psal, Scala se dá najít docela jednoduše, ale asi žádná pecka práce to nebude. Ale třeba Haskell má využití kde? Dovedu si to představit třeba pro administrátora, protože on má volnost v jazycích. U vývojáře je to složitější.

Javamane kdybys nebyl lopata tak by ses podival na web Haskellu kde je to uvedeno. Nicmene pro lopaty to sem napisu. Jednak je to seznam uvedeny v https://wiki.haskell.org/Haskell_in_industry a taky https://www.quora.com/Which-companies-use-Haskell

Kdybys nebyl lopata, tak bys chápal, na co jsem se ptal.

[noef]

Tak jsem se na to podíval - je na to makro makeFields, viz http://stackoverflow.com/questions/34617973/make-lenses-th-with-the-same-field-name-using-makeclassy. Tohle problém vyřeší a není to "bad practice"

Jj, po predchozich postech jsem to taky nasel a zacal na to prechazet. Je to lepsi, nez tuna qualified importu a neprehledny zapis kompozice lens, ale zase takova vyhra to taky neni. Je treba skarede pojmenovavat fieldy recordu (prefixovat jmenem recordu), takze kdyz se to vytvari pres record syntax, tak je to pekne ukecane (co teprv, kdyz se jmeno recordu sklada z nekolika slov, fuj). Dalsi nevyhoda je, ze si to samo nehlida, zda uz to v projektu danou type classu nevytvorilo, kontroluje se jen aktualni soubor, takze pak dochazi k takovym podivnostem, jakoze musim importovat do modulu s velocity modul s position, prestoze z nej nic "viditelne" nepouzivam, protoze oba pouzivaji stejny field a jinak se vytvori type class dvakrat a samozrejmne to umre. Stale mi to pripada spise jako hack, ale je to rozhodne pouzitelnejsi, protoze lens pouzivam casteji nez vytvareni noveho zaznamu.

[andy]

Takže to máš jako hlavní práci a nebo pro vylepšení práce? Jak jsem tu psal, Scala se dá najít docela jednoduše, ale asi žádná pecka práce to nebude. Ale třeba Haskell má využití kde? Dovedu si to představit třeba pro administrátora, protože on má volnost v jazycích. U vývojáře je to složitější.

Haskell má využití kdekoliv. Je to supr jazyk na psaní webových backendů, které dělají vcelku cokoliv - za posledních pár let se objevilo obrovské množství knihoven na tyhle věci. Teď nedávno jsem potřeboval zpracovat rychle nějaký data - normálně jsem to dělával pythonem, krátký skriptík - zkusil jsem použít haskell a překvapivě to bylo vlastně stejně rychlé. Člověk je výrazně efektivnější než lidi píšící v jiných jazycích (je to trošku výběrový efekt, ale ten vývoj je fakt výrazně lepší). Ale je pravda, že v Čechách to moc neletí...

[andy]

Je treba skarede pojmenovavat fieldy recordu (prefixovat jmenem recordu), takze kdyz se to vytvari pres record syntax, tak je to pekne ukecane (co teprv, kdyz se jmeno recordu sklada z nekolika slov, fuj).

Já jsem na to tak detailně nekoukal, ale prefixovat by to asi mohlo jít čímkoliv, ne? A nebo si to makro upravit.. Před dvěma týdny jsem napsal úplně stejný makro do jiného projektu.... no jo, byl jsem líný si přečíst dokumentaci Ale je to překvapivě docela jednoduché.