LUDWIG_: WILD_A: Flame dokoncen v poste, nevim nakolik tim zasirat kluby ;)

takze zaver diskuze o pouceni z py2-3 je, ze postupny kompatibilni, i kdyz spinavy vyvoj je lepsi nez radikalni skok na novou cistou verzi a soubezny vyvoj?

ALMAD: drtiva vetsina knihoven ktery pouzivam uz je bud py3-compatible nebo se na kompatibilite s vervou pracuje. Novejsi verze py3 + six umoznujou psat knihovny kompatibilni s py2 i py3 single-codebase, a to je ta "jedina spravna" cesta jak to dneska delat, a prave existence "jedine spravne" cesty je strasne dulezita -- jeste pred par lety v tom byl bordel, tak se skoro nikdo do kompatibility radsi nepoustel.

Takze dneska uz nepochybuju, ze prijde cas, kdy py3 nebude problem.

ALMAD: ja jsem opravdovej uzivatel a z vlastni zkusenosti na vyber mam.

Ze to byl (a jeste je a chvili bude) porod, je nabiledni. A ze celej puvodni koncept py3 byla chyba a ze scala se podobny ceste musi vyhnout jak cert krizi je taky jasny, to se se mnou nemusis hadat. Vzdyt i guido toho lituje. Jen rikam, ze uz je vsechno, zda se, na dobry ceste, coz bych si jeste pred par lety prohlasit netroufnul.

ALMAD: A jo, se 3.3 je to lepsi, ale taky jak dlouho se core vyvojari museli presvedcovat, ze ten jazyk nema bejt cistej, ale pouzitelnej.

A AFAIK, o 2.8 je porad zajem a uvazuje se o ni, protoze kdyz si opravdovej uzivatel, tak tak nejak nemas na vyber.

Ale vis jak je to s tou historii...

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.