Omezená dědičnost (je něco lepšího než OOP?)

[Radek Miček]

vůbec GHC Haskell je asi nejlepší současný "programovací systém" (krom výpočetně náročných věcí, ale s GPU to prý taky nějak umí)

Dovolil bych si nesouhlasit: 1) GHC Haskell je poměrně komplikovaný (možná kvůli tomu, aby měl dobrou typovou inferenci) - existuje řada podobných jazyků, které mají silnější typový systém a jsou jednodušší než Haskell - např. Idris (má však horší typovou inferenci). 2) O časové a prostorové složitosti určité části kódu je nutné uvažovat v kontextu celého programu, nestačí uvažovat o dané části izolovaně.

[Reklama]

[v]

vůbec GHC Haskell je asi nejlepší současný "programovací systém" (krom výpočetně náročných věcí, ale s GPU to prý taky nějak umí)

Dovolil bych si nesouhlasit: 1) GHC Haskell je poměrně komplikovaný (možná kvůli tomu, aby měl dobrou typovou inferenci) - existuje řada podobných jazyků, které mají silnější typový systém a jsou jednodušší než Haskell - např. Idris (má však horší typovou inferenci). 2) O časové a prostorové složitosti určité části kódu je nutné uvažovat v kontextu celého programu, nestačí uvažovat o dané části izolovaně.

já jsem se samozřejmě nevyjádřil moc precizně, měl jsem na mysli praktické použití, knihovny, komunitu

[v]

asi naprostý offtopic, ale velicr zajímavé čtení http://aosabook.org/en/ghc.html
ty počty řádků...

[Ivan Novy]

...

A víte co je zajímavé, že rálný svět vykazuje oba tyto přístupy, makrosvět je to první řešení a kvantový mikrosvět to druhé :-)

Zvolte rozsahy možných kolizí a náhodně vyberte výsledek z toho rozsahu. Logické kolize do makrosvěta hry nezasáhnou, když kolem elementárních prvků definujete okolí, kde interakce probíhají, přenos interakce pak bude možný jen tehdy, když bude existovat řetěz elementárních prvků, či událostí, které se vzájemně budou dotýkat v rámci takto definovaného okolí :-)))

A o všemocném, všezachraňujícím a všeřešícím trhu nic?
Nic??
NIC???

To je přece fyzikální implementace trhu :-) V toto prostředí se šíří jen dostatečně silné signály, které mají takovou energii, která je schopná ovlivnit více elementárních částic. A to je přesně funkce trhu. Selektovat vznikající signály a tak optimalizovat rozdělování zdrojů.

Vyjdete-li z tohoto principu zjistíte, že stav modelového světa hry nemusíte udržovat fyzicky v nějakých datových strukturách, ale můžete pouze pracovat s jeho ideou a vybírat náhodně z možných lokálních interakcí, jejich propagace do makrosvěta hry, vytvoří iluzi příčiny a následku, stejně jak se to děje v našem "reálném" světě :-)))

[JS]

asi naprostý offtopic, ale velicr zajímavé čtení http://aosabook.org/en/ghc.html
ty počty řádků...

Zajimave. A je to hodne nebo malo? Napadlo me srovnani - ZIL - interpretr a optimalizujici kompilator varianty Lispu (vzhledem k dobe vzniku to nemohl byt Common Lisp) pro IBM Mainframe (OS/370), vcetne "standardni" knihovny - zhruba 40k radek assembleru a 40k radek Lispu. Jestli sem nekdo hodi cisla pro jine kompilatory/systemy, rad si je poslechnu.

[Reklama]

[noef]

Nad JVM nebo CLR můžete postavit jazyky se silnějšími typovými systémy než má Haskell.

Ostatně Scala nemá ostře slabší typový systém než Haskell. Na rozdíl od Haskellu má Scala navíc podtypový polymorfismus. Důsledkem toho je slabší typová inference.

Mel jsem na mysli predevsim generiku a inferenci. A to, ze to "jde" postavit, neznamena, ze by se melo - vykon muze byt dost zalostny, pokud se bude muset uzivat ve velkem reflexe protoze omezeni JVM (ikdyz myslim celkem dost toho padlo, nekde jsem cetl neco s dynamic instrukcemi).

Generika JVM je dost chaba. Ve Scale se musi pouzivat berlicky v podobe tagu a v podstate simulovat runtime podporu generiky pomoci reflexe. CLR je o uroven vys.

No, je mozne ze je to dusledek toho podtypoveho polymorfismu (netusim), ale faktem je, ze oproti Haskellu se musi Scale opravdu casto pomahat (jiste, porad lepsi nez Java).

[hawran diskuse]

...

A víte co je zajímavé, že rálný svět vykazuje oba tyto přístupy, makrosvět je to první řešení a kvantový mikrosvět to druhé :-)

Zvolte rozsahy možných kolizí a náhodně vyberte výsledek z toho rozsahu. Logické kolize do makrosvěta hry nezasáhnou, když kolem elementárních prvků definujete okolí, kde interakce probíhají, přenos interakce pak bude možný jen tehdy, když bude existovat řetěz elementárních prvků, či událostí, které se vzájemně budou dotýkat v rámci takto definovaného okolí :-)))

A o všemocném, všezachraňujícím a všeřešícím trhu nic?
Nic??
NIC???

To je přece fyzikální implementace trhu :-) V toto prostředí se šíří jen dostatečně silné signály, které mají takovou energii, která je schopná ovlivnit více elementárních částic. A to je přesně funkce trhu. Selektovat vznikající signály a tak optimalizovat rozdělování zdrojů.

Vyjdete-li z tohoto principu zjistíte, že stav modelového světa hry nemusíte udržovat fyzicky v nějakých datových strukturách, ale můžete pouze pracovat s jeho ideou a vybírat náhodně z možných lokálních interakcí, jejich propagace do makrosvěta hry, vytvoří iluzi příčiny a následku, stejně jak se to děje v našem "reálném" světě :-)))

Evidentně dost dobrej matroš, prozradíš, čím přihnojuješ?

[Radek Miček]

asi naprostý offtopic, ale velicr zajímavé čtení http://aosabook.org/en/ghc.html
ty počty řádků...

Pro srovnání - OCaml, současný stav:

lexer (lex) - 3277
parser (parsing) - 10029
typechecker (typing) - 33468
překlad do nativního kódu (asmcomp) - 24787
běhové prostředí pro nativní kód (asmrun) - 7448
překlad do bajtkódu (bytecomp) - 13707
běhové prostředí pro bajtkód (byterun) - 22537
REPL (toplevel) - 3230
standardní knihovna (stdlib) - 24110
sdílený kód (utils) - 2477

celkem: 145070

Nezapočítal jsem například: debugger pro bajtkód (pro nativní kód se používá GDB), ocamlbuild (build systém), ocamldoc (systém pro generování dokumentace), další knihovny (otherlibs), yacc a pár dalších věcí

[Ivan Nový]

Pusobi to na me tak, ze zrovna na hry by se FP poustet nemelo. Resp. ne do te doby, nez budou optimalizace na urovni stavajicich prekladacu/virtualnich stroju (tzn. ze prekladac bude opravdu spolehlive transformovat funkcionalni veci na imperativni). IMO zacit by se melo tam, kde trochu horsi vykon je vyvazen rychlejsim vyvojem. Velmi podobna pozice jakou mela Java - ma (melo) to maly vykon, ale vyvoj je velmi svizny, takze to vyvazi ty nevyhody: $ za vyvoj >> $ za hw => radeji koupime lepsi/vic hw.

Problém není v převodu funkcionálního na imperativní kód. To už překladače zvládají poměrně dobře. Problém je převod imperativních programátorů na funkcionální, stačí si přečíst místní diskuzi. Většina programátorů je bez měnitelného stavu totálně ztracená a z toho se odvíjí zbytek. Funkcionální řešení nevymyslí a pokud ho někdo vymyslí za ně, tak ho stejně nepoberou. Naučit se myslet jinak je nadlouho.
A pak je tady taky drobnější problém s tím, že většína existujících nástrojů staví na imperativním přístupu. Setrvačnost udělá hodně.

To je podstata problému. Na vině je funkcionální notace a na ní naroubovaná imperativní notace jako if, while a podobně. Pokud někdo objeví notaci, která bude vypadat přirozeně, FP se rozšíří.

Naděje vkládané do FP, ale mohou být liché, protože se v této technologii nerealizují a hlavně neudržují rozsáhlé reálné projekty běžící desítky let. Každý program do 100 řádků vypadá elegantně a je krásný. Horší je to, když už má těch řádků více. Vyjadřovací schopnosti programovacích jazyků nejsou na úrovni textu prózy, ale na úropvni čtení básní, proto i struktura textu je důležitá. A FP jazyky ji mají přímo katastrofální.

[v]

... A FP jazyky ji mají přímo katastrofální.

citation needed

[v]

asi naprostý offtopic, ale velicr zajímavé čtení http://aosabook.org/en/ghc.html
ty počty řádků...

Pro srovnání - OCaml, současný stav:

lexer (lex) - 3277
parser (parsing) - 10029
typechecker (typing) - 33468
překlad do nativního kódu (asmcomp) - 24787
běhové prostředí pro nativní kód (asmrun) - 7448
překlad do bajtkódu (bytecomp) - 13707
běhové prostředí pro bajtkód (byterun) - 22537
REPL (toplevel) - 3230
standardní knihovna (stdlib) - 24110
sdílený kód (utils) - 2477

celkem: 145070

Nezapočítal jsem například: debugger pro bajtkód (pro nativní kód se používá GDB), ocamlbuild (build systém), ocamldoc (systém pro generování dokumentace), další knihovny (otherlibs), yacc a pár dalších věcí

docela by mě zajímaly jiné "jednojazykové" překladače, třeba javac nebo cpython, našel jsem údaj pro gcc, ale to je hodně nefér srovnání

[Ivan Nový]

...

A víte co je zajímavé, že rálný svět vykazuje oba tyto přístupy, makrosvět je to první řešení a kvantový mikrosvět to druhé :-)

Zvolte rozsahy možných kolizí a náhodně vyberte výsledek z toho rozsahu. Logické kolize do makrosvěta hry nezasáhnou, když kolem elementárních prvků definujete okolí, kde interakce probíhají, přenos interakce pak bude možný jen tehdy, když bude existovat řetěz elementárních prvků, či událostí, které se vzájemně budou dotýkat v rámci takto definovaného okolí :-)))

A o všemocném, všezachraňujícím a všeřešícím trhu nic?
Nic??
NIC???

To je přece fyzikální implementace trhu :-) V toto prostředí se šíří jen dostatečně silné signály, které mají takovou energii, která je schopná ovlivnit více elementárních částic. A to je přesně funkce trhu. Selektovat vznikající signály a tak optimalizovat rozdělování zdrojů.

Vyjdete-li z tohoto principu zjistíte, že stav modelového světa hry nemusíte udržovat fyzicky v nějakých datových strukturách, ale můžete pouze pracovat s jeho ideou a vybírat náhodně z možných lokálních interakcí, jejich propagace do makrosvěta hry, vytvoří iluzi příčiny a následku, stejně jak se to děje v našem "reálném" světě :-)))

Evidentně dost dobrej matroš, prozradíš, čím přihnojuješ?

No je to jen obrácení Lemova principu, že počítač s nekonečně velkou pamětí může mít program nulové délky :-))) No a dle některých fyziků takovým počítačem je vlastně reálný svět, když v časoprostoru všechny možné události existují "současně", mimo čas. Abyste zjistil, zda se dvě kružnice protínají, nemusíte porovnávat dva seznamy se souřadnicemi bodů vytvářejících kružnice.

[noef]

Vyjadřovací schopnosti programovacích jazyků nejsou na úrovni textu prózy, ale na úropvni čtení básní, proto i struktura textu je důležitá. A FP jazyky ji mají přímo katastrofální.

Zrovna napr. takovy Haskell dost lidi povazuje za prekrasny jazyk - lze strucne a vystizne zapsat slozite myslenky. Samozrejme pokud si nekdo pod hezkym kodem programu predstavuje co nejvice nevyznamoveho balastu (Java/Python), pak je IMO neco spatne.

[Ivan Nový]

... A FP jazyky ji mají přímo katastrofální.

citation needed

Stačí se podívat na pár desítek řádků FP kódu. K čemu citace, k tomu stačí vlastní úsudek.

[Radek Miček]

Nad JVM nebo CLR můžete postavit jazyky se silnějšími typovými systémy než má Haskell.

Ostatně Scala nemá ostře slabší typový systém než Haskell. Na rozdíl od Haskellu má Scala navíc podtypový polymorfismus. Důsledkem toho je slabší typová inference.

Mel jsem na mysli predevsim generiku a inferenci. A to, ze to "jde" postavit, neznamena, ze by se melo - vykon muze byt dost zalostny, pokud se bude muset uzivat ve velkem reflexe protoze omezeni JVM (ikdyz myslim celkem dost toho padlo, nekde jsem cetl neco s dynamic instrukcemi).

Pokud nepožadujete, aby vygenerovaný kód šel jednoduše použít z Javy, tak můžete v některých případech provést monomorfizaci - tj. generika specializovat (jako v C++; viz Whole-Program Compilation in MLton, slajd 12). Drobný háček je v tom, že to nemusí vždy jít - například, pokud program používá polymorfní rekurzi. Další háček je v tom, že vzniknou problémy s variancí, pokud používáte podtypový polymorfismus - (např. Iterable<int> nebude podtyp Iterable<Object>, zatímco Iterable<Int> je).