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.>
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);
}
}
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
.
116 Odpovědí
30505 Zhlédnutí