Dědičnost dnes

[spasitel]

http://bredy.novacisko.cz/?/46
co reknete na tenhle clanek?

[Reklama]

[Mirek Prýmek]

řešení, která jsem vygooglil nejsou čistě FP.

Tak já nevím, já když do Googlu zadám "haskell dijkstra algorithm", tak to mám hned na prvních třech pozicích. Ale možná mám jinej Google.

Obecně nelze libovolný algoritmus pro stroj s náhodným přístupem do paměti zapsat pomocí skládání funkcí, jak tvrdí zboj.

Důkaz?

[Ondra Satai Nekola]

Obecně nelze libovolný algoritmus pro stroj s náhodným přístupem do paměti zapsat pomocí skládání funkcí, jak tvrdí zboj.

A na to jsi prisel jak?

https://en.wikipedia.org/wiki/Turing_machine_equivalents

[gll]

Obecně nelze libovolný algoritmus pro stroj s náhodným přístupem do paměti zapsat pomocí skládání funkcí, jak tvrdí zboj.

A na to jsi prisel jak?

https://en.wikipedia.org/wiki/Turing_machine_equivalents

Co má společného Turingův stroj s tím co jsem psal? Já psal o stroji s náhodným přístupem do paměti. Pomocí turingova stroje i lambda kalkulu můžete vyřešit stejné problémy, ale ne ve stejném čase a se stejnou paměťovou náročností. Běžné algoritmy jsou postupy výpočtu pro stroj RAM.

[SB]

Proc by to nemohlo fungovat? Treba ve Facebooku to funguje...

Nebavím se o FP, ale o "vývojářích".

[Reklama]

[Ondra Satai Nekola]

Obecně nelze libovolný algoritmus pro stroj s náhodným přístupem do paměti zapsat pomocí skládání funkcí, jak tvrdí zboj.

A na to jsi prisel jak?

https://en.wikipedia.org/wiki/Turing_machine_equivalents

Co má společného Turingův stroj s tím co jsem psal? Já psal o stroji s náhodným přístupem do paměti. Pomocí turingova stroje i lambda kalkulu můžete vyřešit stejné problémy, ale ne ve stejném čase a se stejnou paměťovou náročností. Běžné algoritmy jsou postupy výpočtu pro stroj RAM.

Turinguv stroj s tim ma spolecneho to, ze je to z tradicnich duvodu "zaklad", se kterym je jak lambda kalkulus tak RAM ekvivalentni.

Ano, pokud reknes, ze mas stejnou vyspocetni silu, ale mohou se lisit detaily behu, tak se s tim da souhlasit. Ale je to neco dost jineho, nez jsi psal na zacatku.

[SB]

To neresi vsechny problemy, ktere mam na mysli, nektere problemy to prinasi (treba vykonnostni kvuli obecnosti), a konecne, mnoho modernich GC beztak pracuje s neprimymi ukazateli, takze to neni takovy rozdil oproti treba indexovanemu poli.

GC je pro mě PNJ (problém někoho jiného), nejsem vývojářem VM.

[SB]

A ještě pokud tomu dobře rozumím, tak "pravé" OOP je dynamické. Takže aplikaci zapnu a vyvíjím za chodu? Protože při každém volání metody jsem ji mohl předefinovat, ne? A fakt takhle někdo vyvíjí?

A čo si, Kefalín, predstavujete pod takým slovom "dynamický"?

[SB]

To není žádný pravěk, je to jiný přístup. Já dávám přednost klasickému vývoji editací zdrojového kód po důkladném rozvážení a distribuci změn pomocí VCS. Smalltalk mi přijde jako vaření guláše. Je to málo slaný? Přisol. Zároveň mi do hrnce někdo strká lžíci, neb má hlad, kráva se na přední straně ještě pase, zadní noha se jí už vaří. Spadlo z ní zezadu něco do hrnce? Nevadí, vem naběračku, vylov to ven, zamíchej, přidej majoránku a vaříme dál.

Může to fungovat, ale možná je i nějaký dobrý důvod, proč se to ve větším měřítku neujalo.

Neujalo se to ze zcela jednoduchého dobrého důvodu - způsob překladu a spouštění aplikací většiny jazyků to neumožňuje. Mimoto váš příměr je docela hloupý, osobně neshledávám žádný přínos v potřebě překladu celé aplikace při drobné změně v jedné metodě, ale HLAVNĚ v časově náročné opětovné simulaci situace kdesi hluboko v aplikaci, to je tím hlavním problémem.

[Kiwi]

http://bredy.novacisko.cz/?/46
co reknete na tenhle clanek?

V ničem se neliší od jiných, stejně nešťastně napsaných úvodů do OOP. Další z textů, jejichž autor podlehl dojmu, že OOP stojí a leží na dědění. I s "povinným" prvoplánovým příkladem grafických objektů, na němž je "všechno krásně jasné", aspoň do doby, než by se v tom zvídavý čtenář začal šťourat a začal si klást otázky, jestli je opravdu dobrý nápad odvozovat děděním křivku od úsečky, jestli je to opravdu šikovné doplňovat takto vzniklou hierarchii o vlastnost barvy dalším děděním od již specializovaných tříd a k čemu je to celé dobré, když stejně na vykreslení každého z těch útvarů je objekt plátno, který to všechno umí tak nějak bokem i bez objektů. Bohužel, asi i vinou takovýchto textů v praxi spousta programů vypadá tak, jak vypadá.
V češtině existují rozhodně mnohem lepší texty o OOP, např. od V. Merunky nebo O. Čady.

P.S.: Poznámka "Chtěl jsem vybrat nějaký programovací jazyk pro popis OOP, ale neuspěl jsem. Buď se jedná o jazyk příliš složitý (smalltalk)..." hned v úvodu mě opravdu rozesmála.

[zboj]

http://bredy.novacisko.cz/?/46
co reknete na tenhle clanek?

V ničem se neliší od jiných, stejně nešťastně napsaných úvodů do OOP. Další z textů, jejichž autor podlehl dojmu, že OOP stojí a leží na dědění. I s "povinným" prvoplánovým příkladem grafických objektů, na němž je "všechno krásně jasné", aspoň do doby, než by se v tom zvídavý čtenář začal šťourat a začal si klást otázky, jestli je opravdu dobrý nápad odvozovat děděním křivku od úsečky, jestli je to opravdu šikovné doplňovat takto vzniklou hierarchii o vlastnost barvy dalším děděním od již specializovaných tříd a k čemu je to celé dobré, když stejně na vykreslení každého z těch útvarů je objekt plátno, který to všechno umí tak nějak bokem i bez objektů. Bohužel, asi i vinou takovýchto textů v praxi spousta programů vypadá tak, jak vypadá.
V češtině existují rozhodně mnohem lepší texty o OOP, např. od V. Merunky nebo O. Čady.

P.S.: Poznámka "Chtěl jsem vybrat nějaký programovací jazyk pro popis OOP, ale neuspěl jsem. Buď se jedná o jazyk příliš složitý (smalltalk)..." hned v úvodu mě opravdu rozesmála.

Zrovna Čadova knížka o OOP je dost otřesná.

[gll]

řešení, která jsem vygooglil nejsou čistě FP.

Tak já nevím, já když do Googlu zadám "haskell dijkstra algorithm", tak to mám hned na prvních třech pozicích. Ale možná mám jinej Google.

Implementace, které jsem našel, používají knihovny, které uvnitř nejsou FP.

Obecně nelze libovolný algoritmus pro stroj s náhodným přístupem do paměti zapsat pomocí skládání funkcí, jak tvrdí zboj.

Důkaz?

Zboj psal něco o lambda kalkulu. V lambda kalkulu se pro tvorbu datových struktur používají dvojice. Pomocí nich nemůžete vytvořit například pole s přístupem O(1) k libovolnému indexu. Můžete si stavební bloky naprogramovat imperativně a používat je jako black box. Taková řešení bych nenazýval čistě FP.

Nejsem informatik, možná se vyjadřuji nepřesně. Formální důkaz vám zde napsat nedokážu, ale vy důkaz opaku také nemáte.

[JS]

Co má společného Turingův stroj s tím co jsem psal? Já psal o stroji s náhodným přístupem do paměti. Pomocí turingova stroje i lambda kalkulu můžete vyřešit stejné problémy, ale ne ve stejném čase a se stejnou paměťovou náročností. Běžné algoritmy jsou postupy výpočtu pro stroj RAM.

Myslim, ze to je problem v teorii, nikoli v praxi. Pominme ted to, ze FP je jen abstrakce, ktera se pak beztak preklada do von Neumannovy architektury.

Potiz je v tom, ze RAM, ktera ma pristup O(1), nelze fyzikalne zkonstruovat. I dnes se to projevuje tim, ze existuje neco jako hierarchie pameti (a ze treba nelze zvetsovat L1 cache, protoze se typicky ocekava, ze do ni pujde pristupovat v jednom cyklu). Proto se proste fakt, ze realna RAM neni O(1) zanedbava a pocita se s tim, jako by to bylo O(1), protoze to je dostatecne dobra aproximace pro velikosti RAM, ktere se typicky pouzivaji.

Tedy realna RAM neni O(1), ale spis O(log n), a takovou RAM lze realizovat i funkcionalne (pomoci stromu).

[gll]

Turinguv stroj s tim ma spolecneho to, ze je to z tradicnich duvodu "zaklad", se kterym je jak lambda kalkulus tak RAM ekvivalentni.

Z hlediska složitosti algoritmů určitě ekvivalentní není.

[Kiwi]

Zrovna Čadova knížka o OOP je dost otřesná.

Která a v čem?