reklama

Scala vs. Java 8.

JS

Re:Scala vs. Java 8.
« Odpověď #15 kdy: 01. 09. 2015, 10:03:46 »
async je jen makro. Není tam třeba LINQ.

Aha, nicmene nezavisle na tom, ze je to makro (nebo mozna proto), ma to urcita omezeni (ktera si uz nepamatuji). Mozna jsou to smysluplna omezeni, ale prijde mi, ze se v tom pak programuje hur, pokud ta omezeni nejsou na prvni pohled zjevna. Obavam se, ze tato, byt nutna omezeni, vyplyvaji z prilis vysokych ambici tvurce jazyka - coz je presne pripad toho "vareni dortu" (neocekavane  interakce ruznych, samostatne nepochybne uzitecnych, abstrakci).

S LINQem mas pravdu. Jak je na tom vlastne Scala a databaze? Existuje ve Scale nejaky oficialni zpusob, jak k nim pristupovat?

Citace
Opravdu? Myslel jsem, že tam je jen instance metoda parametr - tj. bez tečky a závorek.

Mas pravdu, unahlil jsem se. Ale ze svoji (spis male) zkusenosti se Scalu naucit je to dost matouci, a to znam oba zapisy. Moji kolegove na tom nebyli o moc lepe.

Asi je to o pohledu, z meho hlediska skutecne pri pouzivani programovaciho jazyka nehraje roli, z kolika primitiv byl postaven. Dulezitejsi je, jestli se abstrakce/operatory, ktere ma programator k dispozici, daji dobre skladat, chovaji se tak nejak predvidatelne (nemaji treba ruzna tezko vysvetlitelna omezeni) a zbytecne se svoji funkcionalitou neprekryvaji. V tomhle povazuji Python za neprekonanou jednicku, prestoze ma nejspis mizerny typovy system a je v podstate imperativni. (Coz je asi i odrazem toho, ze mi programovani ve staticky typovych systemech zvlast nevyhovuje.) Proste prumysl ma IMHO trochu jine potreby nez akademici (treba stabilitu) a pokud se Scala ve svem vyvoji trochu neuklidni, obavam se, ze moc uspesna nebude (coz by byla skoda, protoze IMHO, Java si zaslouzi nahradu, a Scala je v mnoha smerech pokrok).

Citace
Mj. GHC Haskell má oboje. Výhoda implicitních parametrů je, že můžete předávat normální hodnoty - například spojení do databáze. 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 rad bych aspon videl nejaky popis, jak pomoci implicitu ve Scale dosahnout aspon tehoz, co delaji typove tridy. Cetl jsem ten originalni Oderskeho clanek, ale byl mi nesrozumitelny. Stejne tak na tech vic instanci by to asi chtelo nejake lepsi priklady.

Jinak tu Oderskeho prednasku o Dotty jsem videl, ale moc jsem nerozumel, k cemu to vlastne dela. Ta tvoje poznamka o DOT to aspon trochu dovysvetluje, dik.

reklama


Radek Miček

Re:Scala vs. Java 8.
« Odpověď #16 kdy: 01. 09. 2015, 12:48:04 »
No rad bych aspon videl nejaky popis, jak pomoci implicitu ve Scale dosahnout aspon tehoz, co delaji typove tridy. Cetl jsem ten originalni Oderskeho clanek, ale byl mi nesrozumitelny. Stejne tak na tech vic instanci by to asi chtelo nejake lepsi priklady.

V Haskellu:

Kód: [Vybrat]

import Data.List (sort)

data Osoba = Osoba { jmeno :: String }
  deriving (Show, Eq)

-- Mohli bychom odvodit i pres deriving, nicmene pro blizsi korespondenci
-- se Scalou nechame zvlast.
instance Ord Osoba where
  compare x y = compare (jmeno x) (jmeno y)

setrid :: Ord t => [t] -> [t]
setrid = sort

main :: IO ()
main = do
  let lide = [Osoba "Dana", Osoba "Alena", Osoba "Cenek"]
  print $ setrid lide

Totéž ve Scale:

Kód: [Vybrat]
case class Osoba(jmeno: String)

// Implicity pro třídu Osoba umístíme do companion objektu Osoba:
object Osoba {
  // Instance typové třídy Ordering. Ve skutečnosti obyčejná hodnota
  // typu Ordering[Osoba].
  // Hodnotu jsme zkonstruovali pomocí funkce Ordering.fromLessThan.
  implicit val usporadani: Ordering[Osoba] = Ordering.fromLessThan(_.jmeno < _.jmeno)
}

object Program {
  // Podmínka T : Ordering říká, že pro T musí
  // existovat instance typové třídy -
  // tj. implicitní hodnota typu Ordering[T].
  def setrid[T : Ordering](xs: List[T]) = xs.sorted

  def main(args: Array[String]): Unit = {
    val lide = List(Osoba("Dana"), Osoba("Alena"), Osoba("Cenek"))
    println(setrid(lide))
  }
}

Kdyby se nám standardní uspořádání na osobách nehodilo, můžeme definovat jinou implicitní hodnotu:

Kód: [Vybrat]
object Program {
  def setrid[T : Ordering](xs: List[T]) = xs.sorted

  implicit val jineUsporadani: Ordering[Osoba] = Ordering.fromLessThan(_.jmeno > _.jmeno)

  def main(args: Array[String]): Unit = {
    val lide = List(Osoba("Dana"), Osoba("Alena"), Osoba("Cenek"))
    println(setrid(lide))
  }
}

Jinak def setrid[T : Ordering](xs: List[T]) je zkratka za def setrid[T](xs: List[T])(implicit x: Ordering[T]) - hodí se, když implicitní parametr x nepoužíváme uvnitř funkce explicitně.

Re:Scala vs. Java 8.
« Odpověď #17 kdy: 01. 09. 2015, 14:36:44 »
Uznávám, že dnes není těch důvodů pro Scalu tolik, jako v době, kdy jsem přecházel já (2010). Tehdy byla Java 6 a pokusy programovat v Javě funkcionálně byly trochu krkolomné. Dnes je tu Java 8 a je to o poznání méně krkolomné, byť zdaleka ne ideální.

Kdyby tehdy tu byla Java 8, nevím, jestli bych na Scalu přecházel. Ale z dnešního pohledu by mi to přišlo škoda, Scala má stále co nabídnout.

Actor model – to je mnohem obecnější záležitost, jednotlivé actory mohou být i na úplně jiném stroji. A jinak toto bylo ve Scale deprecated a doporučuje se používat actory z Akka.

Funkcionální programování – zkoušel jsem Javu 8 a nedá se to srovnávat.
* Třeba udělat z kolekce Stringů kolekci java.net.URL jde ve Scale snadno, v Javě musím řešit checked exceptions. Ne, že bych vyloženě neměl checked exceptions rád, ale dokud tu nebude pro ně dobrá podpora v lambda funkcích, budou komplikovat funkcionální programování.
* Myslím, že pro Scalu je – aspoň dnes – lepší funkcionální ekosystém.

Immutable typy – ano, dá se to dělat i v Javě a já to tak dělal. Místo case classes se dá použít Lombok, který sice neumí úplně všechno, co case classes (např. pattern matching by v Javě neměl smysl), ale to základní ano. Na druhou stranu je tu trošku problém s ekosystémem – například když buu v Javě chtít (de)serializovat JSON do objektů, tuto konstrukci mi snad žádná knihovna podporovat nebude. Ve Scale použiju upickle nebo Play-JSON. V Javě ani jeden z nich tak snadno nepoužiju, protože to chce makra. Stručně: V Javě s tímto přístupem spíše narazím.

Klíčové slovo val, kdy pak není možné měnit proměnnou - Java má final – ano. Varianta s final je ukecanější, ale v zásadě ano.

Akademická syntaxe – nevím, jestli je akademická, ale vyhovuje mi celkem. Je svým způsobem jednodušší: například v syntaxi není níc jako typecast či instanceof – místo nich máme metody asInstanceOf a isInstanceOf. Nemáme operátor pro sčítání, třída Int má metodu „+“. (Kompilátor to pak zkompiluje vhodným způsobem, takže se to přeloží na checkcast, iadd apod. a žádné volání metody v takovémto bytecode nebude.)

XML syntaxe – pokud si dobře vzpomínám, tak ta se má z core jazyka oddělit do samostatného modulu. Snad má být implementována pomocí maker a string interpolation.

Databáze – je tu například knihovna Slick, za kterou dnes stojí Typesafe.

K „neklidnému vývoji“ – nemám pocit, že by tato výtka byla dnes na místě. Před pěti rokama ano. Dnes, když vyjde mová minor (setinková) verze, ověřuje se, že je 100% kompatibilní. Když vyšla nějaká desetiknová verze, slibovali kompatibilitu zdrojáků, s výjimkou zavržených a experiemntálních fíčur. A Dotty? To je dnes samostatný jazyk. Co je dnes v Dotty, to se může – pokud se to osvědčí – dostat časem do Scaly. Ale tím pískovištěm dnes není Scala, ale právě Dotty. Není to naopak dobře?

Mám pocit, že ke klidnějšímu vývoji přispělo i založení Typesafe.

JS

Re:Scala vs. Java 8.
« Odpověď #18 kdy: 02. 09. 2015, 23:02:46 »
V Haskellu:
...

Totéž ve Scale:
...

Diky za odpoved! Uz tomu trochu zacinam rozumet.

javaman ()

Re:Scala vs. Java 8.
« Odpověď #19 kdy: 23. 12. 2016, 16:35:00 »
Když jsou ty svátky, tak to chce i něco kvalitního tady. Jak je na tom Scala dnes? Sem tam narazím firmu, kde ji ještě používají, ale nějaký velký boom asi už nepřijde. Nebo myslíte, že Scala pořád má co nabídnout? Nebo je lepší se poohlédnout po něčem jiném? Myslím proti Javě. Co třeba Go, to zdejší koumáci už někde určitě mají nasazené.

reklama


Radek Miček

Re:Scala vs. Java 8.
« Odpověď #20 kdy: 23. 12. 2016, 20:59:24 »
Nebo myslíte, že Scala pořád má co nabídnout?

Scala má určitě co nabídnout - a to nejen oproti Javě nebo C# (C# 7 je velmi složitý a moc toho nenabízí, Scala je složitá, ale alespoň nabízí řadu věcí, co jiné jazyky nemají), ale i třeba oproti Haskellu.

Citace
Co třeba Go, to zdejší koumáci už někde určitě mají nasazené.

Z pohledu vývoje programovacích jazyků je Go krokem cca 30 let nazpět.

javaman ()

Re:Scala vs. Java 8.
« Odpověď #21 kdy: 23. 12. 2016, 21:09:45 »
Proti Haskellu má třeba co? Pokud jste to rozebírali, tak to stačí vypíchnout. Mně se líbí, že Scala jede na JVM. C# je pro mě mimo kvůli MS.

Právě Go si sem tam někdo pochvaluje, že odebralo takové ty novinky, které jen věci znepřehledňují. Podle mě to není pravda, ale neměl jsem na něj skoro žádný čas, takže těžko říct. Takže myslíš, že Go ani nemá cenu někam nasazovat? Nebo třeba jen kvůli výkonu?

.

Re:Scala vs. Java 8.
« Odpověď #22 kdy: 23. 12. 2016, 21:39:20 »
Go má určitě taky co nabídnout. :)
Dokonce jsem přesvědčen, že si s Javou ani moc nekonkurují a spíš doplňují. Go určitě nemá takovou podporu knihoven jako Java, ale za poslední roky se situace hodně zlepšila a v oblasti, kde se Go používá, nic zásadního už nechybí.

Go je více určeno na systémové věci, systémové utility a pak pro web. Rozhodně bych v něm nedělal ekonomický systém, i když se najdou lidé, kteří to zkoušejí. S Javou pak Go sdílí jednoduchou křížovou kompilaci a snadné nasazení. V oblasti, kde je JVM zbytečnou zátěží, těžko hledat něco vhodnějšího.

Překážkou může být, že pochopení idiomatického Go může být pro Javistu problém.

Tuxik

  • *****
  • 1 473
    • Zobrazit profil
    • E-mail
Re:Scala vs. Java 8.
« Odpověď #23 kdy: 23. 12. 2016, 21:46:40 »
Proti Haskellu má třeba co? Pokud jste to rozebírali, tak to stačí vypíchnout. Mně se líbí, že Scala jede na JVM. C# je pro mě mimo kvůli MS.

Právě Go si sem tam někdo pochvaluje, že odebralo takové ty novinky, které jen věci znepřehledňují. Podle mě to není pravda, ale neměl jsem na něj skoro žádný čas, takže těžko říct. Takže myslíš, že Go ani nemá cenu někam nasazovat? Nebo třeba jen kvůli výkonu?
Jak kvůli výkonu? JVM je přece rychlejší, než fyzický procesor nad kterým běží. Nebo se zase něco změnilo?

Radek Miček

Re:Scala vs. Java 8.
« Odpověď #24 kdy: 23. 12. 2016, 21:48:12 »
Proti Haskellu má třeba co? Pokud jste to rozebírali, tak to stačí vypíchnout.

Věci z OOP - např. podtypový polymorfismus (lze využít pro typové třídy nebo pro tagování - př. Int @@ Customer je podtyp Intu, který jde použít všude, kde je třeba Int, ale naopak nejde použít Int, když je vyžadován Int @@ Customer) nebo dědičnost. Nebo třeba to, že v jednom programu může být více instancí jedné typové třídy pro jeden typ.

Nebo to, že Scala je menší jazyk než GHC Haskell, kde se řada featur všelijak překrývá (např. implicitní parametry se překrývají s typovými třídami nebo víceparametrické typové třídy se překrývají s typovými třídami s asociovanými typy) - což dává prostor k nekompatibilitám - např. je třeba dělat dvě verze některých knihoven.

Citace
Mně se líbí, že Scala jede na JVM. C# je pro mě mimo kvůli MS.

Oracle je možná ještě horší než MS (viz třeba Oracle finally targets Java non-payers – six years after plucking Sun
Thought Java was 'free'? Think again
) a CLR  je pod MIT licencí, zatímco OpenJDK je pod GPL.

Citace
Právě Go si sem tam někdo pochvaluje, že odebralo takové ty novinky, které jen věci znepřehledňují. Podle mě to není pravda, ale neměl jsem na něj skoro žádný čas, takže těžko říct. Takže myslíš, že Go ani nemá cenu někam nasazovat? Nebo třeba jen kvůli výkonu?

Zásadní potíží Go je, že uživatel nemůže vytvářet nové generické typy. Velmi dobrou alternativou ke Go může být v brzké době OCaml (až se do hlavní distribuce zamerguje podpora pro paralelní běh) - i z hlediska výkonu viz Golang’s Real-time GC in Theory and Practice.

Citace
Takže myslíš, že Go ani nemá cenu někam nasazovat?

Já osobně bych to nedělal (hodně cením vyjadřovací sílu jazyka), ale je řada lidí, kteří jsou s Go spokojeni.

Radek Miček

Re:Scala vs. Java 8.
« Odpověď #25 kdy: 23. 12. 2016, 22:08:02 »
CLR  je pod MIT licencí

Oprava: Má být .NET Core místo CLR.

Natix

Re:Scala vs. Java 8.
« Odpověď #26 kdy: 23. 12. 2016, 22:30:38 »
Ještě tu nikdo nezmínil Kotlin. Ten v podstatě kombinuje to nejlepší/nejdůležitější ze Scaly a Groovy a zároveň zachovává bezproblémovou obousměrnou kompatibilitu s Javou. Co se týče Androidu, tak tam se s trochou nadsázky pomalu stává mainstreamem.

javaman ()

Re:Scala vs. Java 8.
« Odpověď #27 kdy: 23. 12. 2016, 22:58:38 »
Super, díky za info. Přečtu a prozkoumám.

noname

Re:Scala vs. Java 8.
« Odpověď #28 kdy: 23. 12. 2016, 23:42:03 »
Ak ta zaujima funkcionalne programovanie, tak si pozri aj jazyk Clojure, ktory tiez bezi na JVM. Podla mna je hodne dobry a celkom dobre sa v nom programuje.

zboj

  • *****
  • 1 507
    • Zobrazit profil
    • E-mail
Re:Scala vs. Java 8.
« Odpověď #29 kdy: 24. 12. 2016, 00:20:30 »
Citace
Co třeba Go, to zdejší koumáci už někde určitě mají nasazené.

Z pohledu vývoje programovacích jazyků je Go krokem cca 30 let nazpět.
Nicméně stále je překvapivě dobře použitelné.

 

reklama