Scala vs. Java 8.

[scalac]

Něco jsem si o Scale přečetl a trochu ji vyzkoušel, ale nejsem si jistý, jestli má smysl se o tento jazyk nějak víc zajímat.

Nějaké vlastnosti:

• 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.
  
• 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ě.
  
• Immutable typy - taky věc, co se dá udělat i v Javě, prostě budu mít jen konstruktory a žádné metody na modifikaci.
  
• Klíčové slovo val, kdy pak není možné měnit proměnnou - Java má final
  
• Akademická syntaxe - ta syntaxe je prostě taková, aby to nevypadalo jako Java
  

Nechci, aby to vypadalo jako nějaký hejt 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. Samozřejmě můžu dát pročítat články na netu, ale nějaká diskuze nemusí být od věci .

[Reklama]

[scalac]

u toho Funckcionálního programování jde také o to, že v Javě 8 už jsou anonymní funkce, ne tedy jen o tu třídu java.util.Stream.

Lze tedy psát např:

Collection<Integer> numbers = Arrays.toList(10,20,30,40);

int countBiggerThan50 = numbers.stream().filter(number -> number > 50).count();

[zboj]

Javě chybí to val (aka var/let), jinak výhody moc nejsou.

[Radek Miček]

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

Pokročilejší FP se v Javě stále dělá dost těžko - to je dáno typovým systémem (například argumentem generik ve Scale nemusí být typ, ale může to být typová funkce - tj. generická třída bez argumentů; nebo tzv. path-dependent typy).

Kromě silnějšího typového systému má Scala navíc implicitní argumenty (aplikací jsou například typové třídy) a makra.

[Radek Miček]

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

Pokročilejší FP se v Javě stále dělá dost těžko - to je dáno typovým systémem (například argumentem generik ve Scale nemusí být typ, ale může to být typová funkce - tj. generická třída bez argumentů; nebo tzv. path-dependent typy).

Kromě silnějšího typového systému má Scala navíc implicitní argumenty (aplikací jsou například typové třídy) a makra.

Samozřejmě Scale nechybí ani pattern matching a case classy.

[Reklama]

[Ziktofel]

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

Pokročilejší FP se v Javě stále dělá dost těžko - to je dáno typovým systémem (například argumentem generik ve Scale nemusí být typ, ale může to být typová funkce - tj. generická třída bez argumentů; nebo tzv. path-dependent typy).

Kromě silnějšího typového systému má Scala navíc implicitní argumenty (aplikací jsou například typové třídy) a makra.

Myslim, ze neco takovyho pujde i v Jave:
public class MyClass<X extends Function<Y, Z>> ...

[Radek Miček]

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

Pokročilejší FP se v Javě stále dělá dost těžko - to je dáno typovým systémem (například argumentem generik ve Scale nemusí být typ, ale může to být typová funkce - tj. generická třída bez argumentů; nebo tzv. path-dependent typy).

Kromě silnějšího typového systému má Scala navíc implicitní argumenty (aplikací jsou například typové třídy) a makra.

Myslim, ze neco takovyho pujde i v Jave:
public class MyClass<X extends Function<Y, Z>> ...

To není ono. Měl jsem na mysli higher-kinded generics.

Příkladem je MyClass<X>, kde X označuje generickou třídu se dvěma parametry, tj. uvnitř MyClass mohu použít třeba X<String, String>, X<Integer, String> a X<T, U>, kde T i U jsou typové parametry.

[podlesh]

Myslim, ze neco takovyho pujde i v Jave:

I když teoreticky jde ledacos, cokoliv trochu komplikovanějšího zabije:

• reifikace
• knihovny nenavržené pro generiky
• reflection (a té se jen tak nezbavíme, hlavně kvůli absenci metatříd)

[perceptron]

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.

actor model v akka funguje pre scalu aj pre javu

maju dve sady api

ale niektore veci v java api nezapisete resp. to vyzera ako perl

[JS]

Muj nazor je, ze na Scalu ma smysl se podivat. Zda se, ze to je budoucnost Javy/JVM - hodne modernich projektu ma API pro Scalu nebo je v ni primo napsano, takze myslim existuje kriticka masa "early adopters". I kdyz jako jazyk je to.. asi jako kdyz kocicka s pejskem varili dort. Na muj vkus trochu prekomplikovane, ale zvyknete si, tak jako si generace pred vami zvykla na C++.

Co se tyce syntaxe, Scala bere pulku syntaxe od staticky typovanych funkcionalnich jazyku, kdy se argumentu oddeluji mezerami. Obecne, spojeni OOP a FP mi nepripada uplne stastne. Je to asi jako nekomu, kdo nezna SQL a relacni databaze, vnutit ORM, s tim, ze to bude mit snazsi. No zpocatku asi trochu ano, nez narazi na zakladni problemy vyplyvajici z nepochopeni podstatnych odlisnosti obou modelu, a pak tvrde narazi a zivot si zkomplikuje. Ze stejneho duvodu bych doporucoval Javistum, kteri se zajimaji o FP, naucit se (pred Scalou) aspon trochu nejaky ciste funkcionalni jazyk, treba Haskell, pak bude snazsi pochopit, z ceho ze to FP do te Scaly vlastne prislo a jakou to ma roli (treba vyznam veci jako ciste funkce, line vyhodnocovani, pattern matching, algebraicke datove typy, currying apod.).

[Radek Miček]

I kdyz jako jazyk je to.. asi jako kdyz kocicka s pejskem varili dort. Na muj vkus trochu prekomplikovane

Ano, Scala je komplikovaná, ale nepřijde mi to jako nějaká splácanina - naopak mi přijde, že je tam jen pár konstrukcí, na nichž je vše postaveno (v tomto ohledu mi Scala přijde mnohem čistší než OCaml nebo GHC Haskell).

Jako hlavní problém ovšem vidím zabugovanost kompilátoru a určité problémy typového systému - oboje by mohl vyřešit DOT a jeho implementace dotty.

Obecne, spojeni OOP a FP mi nepripada uplne stastne.

Jelikož objekty ve Scale mohou obsahovat typy, lze je chápat jako přirozené zobecnění modulů z ML (např. z OCamlu).

[Ondrej Nemecek]

Vlastnosti Scaly ocení člověk, který vidí trochu do hloubky. Pro průměrného javistu je obtížně srozumitelná - mluvím z vlastní zkušenosti :-)

Ale na druhou stranu je to šance, jak se toho dost přiučit, takže bych to nevzdával hned na začátku. Taky proto, že jazyky nad jvm mají podle mě budoucnost, protože spojují to, co je známé a už funguje (jvm a knihovny) a přidávají k tomu pokrokové prvky (nový jazyk).

[JS]

I kdyz jako jazyk je to.. asi jako kdyz kocicka s pejskem varili dort. Na muj vkus trochu prekomplikovane

Ano, Scala je komplikovaná, ale nepřijde mi to jako nějaká splácanina - naopak mi přijde, že je tam jen pár konstrukcí, na nichž je vše postaveno (v tomto ohledu mi Scala přijde mnohem čistší než OCaml nebo GHC Haskell).

Tohle je takovy akademicky pohled. V praxi je myslim jedno, z kolika soucastek lze poskladat vlastnosti jazyka, daleko uzitecnejsi mi prijde jista "konzistence" vysledku (tedy ze to, co napisu, dela co bych asi tak cekal). Ale abych byl trochu konkretni - znas nejakou vlastnost programovacich jazyku, ktera je zrovna v mode a kterou se Oderski rozhodl do Scaly nepridat? Mluvim treba o XML syntaxi, makrech, async atd. Neni to jen problem z hlediska programovani, ale proste uz je IMHO cas na to, aby se Scala prestala prekotne vyvijet, pokud chce vyrust v pouzivany programovaci jazyk.

Jako hlavní problém ovšem vidím zabugovanost kompilátoru a určité problémy typového systému - oboje by mohl vyřešit DOT a jeho implementace dotty.

Vubec se tomu nedivim, kdyz se podivam, co vsechno za vlastnosti Oderski ve Scale chce mit. Ale IMHO ten paper jde presne smerem, kterym by uz Scala mela prestat jit - pokud bude Oderski povazovat Scalu za svoji experimentalni platformu pro vyzkum programovacich jazyku, nikdy se poradne neprosadi. Zase tam chteji pridat nejake silene zobecneni, ktere ovsem bude mit v praxi spoustu vyjimek (protoze nikdo jaksi poradne nepromyslel, jak to zkombinovat s temi ostatnimi vlastnostmi, je-li to vubec mozne), takze to realne programovani spis zamlzi nez zjednodusi.

Obecne, spojeni OOP a FP mi nepripada uplne stastne.

Jelikož objekty ve Scale mohou obsahovat typy, lze je chápat jako přirozené zobecnění modulů z ML (např. z OCamlu).

No ja mluvim spis (ale ne vylucne) o syntaxi. Scala se rozhodla k volani metody jak se zapisuje v OOP (instance.metoda(parametr)) jeste pridat system pouzivany ve funkcionalnich jazycich (metoda instance parametr). Vysledek je, ze kod je potencialne spatne citelny pro vsechny. Jeste je tam par jinych takovych pripadu.

Dalsi priklad jsou implicity, to jsem vubec nepochopil. Kdyby proste pridal typove tridy, mohlo to byt krasne ciste.

[Radek Miček]

I kdyz jako jazyk je to.. asi jako kdyz kocicka s pejskem varili dort. Na muj vkus trochu prekomplikovane

Ano, Scala je komplikovaná, ale nepřijde mi to jako nějaká splácanina - naopak mi přijde, že je tam jen pár konstrukcí, na nichž je vše postaveno (v tomto ohledu mi Scala přijde mnohem čistší než OCaml nebo GHC Haskell).

znas nejakou vlastnost programovacich jazyku, ktera je zrovna v mode a kterou se Oderski rozhodl do Scaly nepridat? Mluvim treba o XML syntaxi, makrech, async atd.

async je jen makro. Není tam třeba LINQ.

Jako hlavní problém ovšem vidím zabugovanost kompilátoru a určité problémy typového systému - oboje by mohl vyřešit DOT a jeho implementace dotty.

Vubec se tomu nedivim, kdyz se podivam, co vsechno za vlastnosti Oderski ve Scale chce mit. Ale IMHO ten paper jde presne smerem, kterym by uz Scala mela prestat jit - pokud bude Oderski povazovat Scalu za svoji experimentalni platformu pro vyzkum programovacich jazyku, nikdy se poradne neprosadi. Zase tam chteji pridat nejake silene zobecneni, ktere ovsem bude mit v praxi spoustu vyjimek (protoze nikdo jaksi poradne nepromyslel, jak to zkombinovat s temi ostatnimi vlastnostmi, je-li to vubec mozne), takze to realne programovani spis zamlzi nez zjednodusi.

Osobně mi to přijde jako zjednodušení - průnik typů tam je nově komutativní. Navíc při typové kontrole nevznikají nekonečné typy.

No ja mluvim spis (ale ne vylucne) o syntaxi. Scala se rozhodla k volani metody jak se zapisuje v OOP (instance.metoda(parametr)) jeste pridat system pouzivany ve funkcionalnich jazycich (metoda instance parametr).

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

Dalsi priklad jsou implicity, to jsem vubec nepochopil. Kdyby proste pridal typove tridy, mohlo to byt krasne ciste.

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.

[Radek Miček]

Mj. Odersky měl nedávno prezentaci o novém kompilátoru Dotty: Compilers are Databases.