ALMAD: no, neni to idealni, ale je nejaky lepsi zpusob jak z toho ven? nebo je lepsi se placat v soucasny situaci?

LUDWIG_: ...no a jestli scala 3 bude jako python 3, tak potes koste.

Jako Haskell a jeho inference taky nebyla bez problemu, a to Haskell je "jednodussi" jazyk ve smyslu, ze je ciste funkcionalni a nesnazi se kombinanovat OO a interoperabilitu s Javou jako Scala.

Haskell byl ale pragmatictejsi v tom, ze ma jasne definovany relativne jednoduchy mezi-jazyk Core, do ktery se Haskell preklada... Plus, strategie "avoid success at all cost" se vyplatila, ze ta evoluce jazyka mohla byt pomerne radikalni.
Scala je ted v tezky situaci, ze se stala fukncionalnim programovanim pro masy, a uz takhle si lidi (pravem) stezuji, jak jsou jednotlivy verze nekompatibilni.

Moje predpoved je, ze az se finalizuje DOT (https://github.com/namin/dot ), prekope se Scala do nejake nove "ciste" verze, ktera bude soubezne existovat s tou starou polo-rozbitou. Tedy neco jako Python 2.6/7/... a 3.xx.

LUDWIG_: teda nic proti, jen jsem víc pragmaticky orientovaný a víc ocením jak jazyk s reasoningem pomáhá mě než já kompilátoru zbavit ho jeho utrpení

LUDWIG_: upřímně, nemám sílu tohle číst... asi chci opravdu dělat něco užitečnýho.

LUDWIG_:
True Scala complexity | @yaaang's blog
http://yz.mit.edu/wp/true-scala-complexity/

LITTLELI LITTLELI: do jiste miry odstrasujici... v nejake prednasce o GHC rikal S-P Jones, ze kombinace parametrickeho a podtypoveho (subtype) polymorfismu je prilis komplikovana, tudiz vetsinou cesta do bazin a ze jedinou vyjimkou je Scala... podle tech Phillipsovo prednasek to ale vypada, ze se v bazine vnitrne brodi, jen to skryvaji.

Kdybych mel nejak shrnout ty zavery, tak za soucasneho stavu: 1) scalac nebude nikdy rychly, protoze je to neuveritelny moloch, 2) clovek se muze setkat s radou podivnosti, ktere vydedukuji jeho vnitrni pochody, 3) scalac nemuze delat prilis mnoho optimalizaci kvuli bohatosti jazyka.

Pres tyhle neduhy je Scala porad ale prakticky jazyk a mnohem elegantnejsi nez Java... a treba se ve Scale 3 (ci nake budouci verzi) vybodnou na zpetnou kompatibilitu a prekopou to od zacatku s ohledem na tyhle neduhy.

Tady je trochu "praktictejsi" pohled (prece jen vetsina programovani ve Scale neni takovy boj jako scalac):

Skills Matter
https://skillsmatter.com/...lscasts/4921-some-musings-on-scala-and-clojure-by-a-long-time-scala-dude

UETOYO: je nepovinna, takze je to spis extra dokumentace pro ostatni (a sanity check pro refactoring)... inference to odhadne vetsinou spravne - kdyz clovek potrebuje nejaky extra vykon, tak jak pise ANT_39... jsou typy pro unsafe string, unboxed numeriku apod.

(Ja sam jsem Cckar resp. C++kar, tak s pouzivanim ruznych lispu a haskellu "in anger" nemam moc zkusenosti.)

UETOYO: Signatura je nepovinna, ale urcite se tam dela staticka inference typu, takze prekladac muze optimalizovat. Takovy ghc to AFAIK i dela, ale nemam moc tuseni, jak dobre. Na shootoutu snad byly nejaky vysledky, co naznacovaly, ze kdyz clovek strategicky pouzive nejaky ty unsafe stringy atp., tak to beha temer C rychlosti, ale to zas tak moc neznamena.

UETOYO: Teoreticky muze, Common Lisp na to tusim ma nejaky anotace, pomoci kterych jde nak pozicovat funkce na skale mezi rychlosti a bezpecnosti, ruzne scheme kompilatory umely na zaklade staticke analyzy nejake veci vydedukovat a tak. Jak je to v praxi, nevim, tady na tohle tema mluvival ID Sad0ur, ale uz jsem ho tu nakou dobu nevidel.

UETOYO: jj, "The Lisp family of languages are all "strongly typed" in the sense that typing errors are prevented at runtime."

LITTLELI: ja bych pozitivni prinos videl jen ve dvou pripadech LUDWIG_ (ve smyslu ze snizenou produktivitu pri kodeni vyvazi potencialne min debugovani a udrzitelnejsi system); jinak to imho smysl postrada

pokud někdo (volitelně) anotuje typy, tak to pro něj (nebo skupinu) předpokládám má nějaký pozitivní význam z hlediska produktivity. jinak to jaksi postrádá smyslu, že?

LITTLELI: Pouzil jsem sice ostry vyrazy, hlavne ve snaze vyvolat nejakou diskuzi, ale osobne to fakt vnimam jako nahrazku v nouzi, kdyz to teda nejde jinak. A jinak viz LUDWIG_.

LITTLELI: je to volitelne (=> min uzitecne: nedokaze to z principu odchytit radu veci, co staticke jazyky zvladnou) a musi to byt explicitne vypsane (=> min produktivni oproti untyped Clojure nebo statickym jazykum s inferenci)

WILD_A: tak mně zas přijde, že to takhle nestojí. Mít takovou možnost volitelně mi přijde dost užitečné a rozhodně ne "lámání" nebo nějaké "znásilňování". Docela to odpovídá filosofii Clojure.

LUDWIG_: Z toho teda flejm nekouka, nejak neumim zaujmout jiny stanovisko nez je to tvoje. Clojure je Lisp a Lisp je jakej je a ma svoje vyhody a ja jsem velkej fanousek. Pokud mi z nejakyho duvodu Lisp nevyhovuje tak proc ho znasilnovat a lamat vzdyt tu jsou i jiny jazyky, za mne treba OCaml, Haskell jsem se zatim moc nenaucil.

Odbocka ve forme nadavani na pomery, mne osobne prijde snaha nacpat do kazdyho jazyka vsechno co umej ostatni fakt hloupa, pokud danej jazyk v jadru nevyhovuje tak ho prece nepouzivam a zvolim si lepsi nastroj, prirovnavam to k remeslnikovi, ten taky nema na vsechno kladivo, teda pokud je dobrej.

WILD_A: tak hura do toho - mne osobne ten Typed Clojure prijde jako z nouze cnost, pokud je tym a hafec kodu v Clojure nebo clenove tymu, co nic jineho nez Clojure neumi/neuznavaji... na solo projekty mi to prijde zbytecny a staci untyped Clojure a na vsechno ostatni jsou tu staticke jazyky s chytrou inferenci :)