ALMAD: souhlas, az na to, ze py3 neni mrtvej, ale pomerne uspesne na nej prechazi vetsina komunity. Stalo to ovsem spoustu potu, hadek a "compatibility" featur a trvalo to (a jeste potrva) spoustu let. Ale uz je aspon jasno...

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)