Dědičnost dnes

[BoneFlute]

OOP je mix deklarativního a imperativního programování. FP je více deklarativní. Pro některé lidi je problém vyjádřit myšlenku, ale dát příkaz umí každý.

Ono to je tak, ze programovanie byva multiparadigmove. Aj to funkcionalne sklzne k multiparadigmovitosti, a vznikaju objekty, alebo procedury, pripadne owrapuju proceduralny kod v C. V c-cku to niekedy sklzne k vytvaraniu kvazi-objektov, alebo k funkcionalnemu. Nic nie je uplne ciste.

A co z toho plyne?

Ze pokial prejdeme od skolskych prikladov do realneho sveta, multiparadigmovitost je vsadepritomna.

Jak to souvisí s tvrzením, že FP je neintuitivní.

Ze FP si poziciava veci z inych paradigiem aby bolo intuitivnejsie? T.j. opovrhovanie inymi paradigmami je sranie si do vlastneho hniezda.

Udělejme si v tom pořádek:
1. FP si nepůjčuje věci z jiných paradigmat. FP je paradigma samo o sobě.
2. Co si půjčuje z jiných paradigmat jsou tak maximálně jazyky.
3. Haskell je pure funkcionální, a z imperativního světa si tam fakt půjčuje pouze zápis některých monád a to kdo ví zda vůbec.
4. Opovrhování jinýmy paradigmaty je jen tvá fantazie. Nikde jsem nic takového nenaznačil.

Zopakuji co jsem chtěl říct: To, že vývojáři nepoužívají FP je jen otázka zvyku. FP rozhodně není neintuitivní.

[Reklama]

[gll]

Sorry, ale tahle vaše diskuse je přece bezpředmětná, nedá se přímo porovnávat OOP a FP, protože zápis v FP nic nevypovídá o časové složitosti výpočtu.

To ne, ale mohl by teoreticky existovat nejaky problem, jehoz popis pomoci imutabilnich struktur by byl zjevne vyrazne nevyhodny.

Nic takového mě nenapadá. Může být samozřejmě nevýhodný z pohledu abstrakce nebo "popsatelnosti", ale ne efektivity výpočtu.

V FP musíte používat jiné datové struktury, které jsou z principu pomalejší.

[balki]

Udělejme si v tom pořádek:
1. FP si nepůjčuje věci z jiných paradigmat. FP je paradigma samo o sobě.
2. Co si půjčuje z jiných paradigmat jsou tak maximálně jazyky.
3. Haskell je pure funkcionální, a z imperativního světa si tam fakt půjčuje pouze zápis některých monád a to kdo ví zda vůbec.
4. Opovrhování jinýmy paradigmaty je jen tvá fantazie. Nikde jsem nic takového nenaznačil.

Zopakuji co jsem chtěl říct: To, že vývojáři nepoužívají FP je jen otázka zvyku. FP rozhodně není neintuitivní.

Len ten zvyk trva uz nejako dlho, pricom su nonstop pokusy o pretlacenie FP do mainstreamu. A FP je taka dokonala paradigma, ze potrebuje aj objektove a proceduralne konstrukcie  inak je to hracka pre matematikov.

[gll]

Ježkovanoho, obecné vyhledávání bez předběžné znalosti neexistuje, nejde to udělat. Musím vědět spoustu věcí, abych to mohl reálně realizovat. Potřebuju komparační funkci, znalost o tom kolik bude zhruba dat... Vejde mi to do paměti, nebo to musím dát na disk? Vejde mi to na jeden disk, nebo to musím nějak distribuovat na více disků/strojů? Obecné vyhledávání je hezký teoretický koncept, asi tak na úrovni obecného programovacího jazyka elegantně řešícího všechny problémy .

Dobre, tak mam predbeznou znalost "chci vyhledavat mezi stringy s neohranicenou delkou, jejichz celkova velikost bude maximalne takova, aby se mi vsechny vesly do pameti, ktera ma 16G". Jak udelam s takovym zadanim vyhledavani se slozitosti O(1)?

můžete hashovat nějaká ID těch řetězců. Případně jejich adresy v paměti.

[zboj]

Sorry, ale tahle vaše diskuse je přece bezpředmětná, nedá se přímo porovnávat OOP a FP, protože zápis v FP nic nevypovídá o časové složitosti výpočtu.

To ne, ale mohl by teoreticky existovat nejaky problem, jehoz popis pomoci imutabilnich struktur by byl zjevne vyrazne nevyhodny.

Nic takového mě nenapadá. Může být samozřejmě nevýhodný z pohledu abstrakce nebo "popsatelnosti", ale ne efektivity výpočtu.

V FP musíte používat jiné datové struktury, které jsou z principu pomalejší.

Z pohledu vyčíslitelnosti to není (obecně) pravda. Problém (resp. nedorozumění) je v tom, že v FP se používá čistě matematický zápis, kdežto v OOP algoritmický. Čili kód v OOP se přímo vykoná (překlad sekvenčního zápisu do kódu procesoru je přímočarý), kdežto v případě FP se kód nejprve "proceduralizuje", a to jde udělat různými způsoby. Ty naivní jsou méně efektivní, ale to neznamená, že to nejde udělat efektivně. Například Dijkstrův grafový algoritmus (abych byl konkrétní) je v FP stejně efektivní jako v OOP.

[Reklama]

[Mirek Prýmek]

můžete hashovat nějaká ID těch řetězců. Případně jejich adresy v paměti.

To uz pak prave neni O(1), jak jsme si jiz byli vyjasnili.

[gll]

můžete hashovat nějaká ID těch řetězců. Případně jejich adresy v paměti.

To uz pak prave neni O(1), jak jsme si jiz byli vyjasnili.

http://stackoverflow.com/questions/11677201/near-perfect-or-perfect-hash-of-memory-addresses-in-c

[gll]

Například Dijkstrův grafový algoritmus (abych byl konkrétní) je v FP stejně efektivní jako v OOP.

Chtěl bych to řešení vidět. Bez použití STMonády.

[Mirek Prýmek]

http://stackoverflow.com/questions/11677201/near-perfect-or-perfect-hash-of-memory-addresses-in-c

A jak to s tim souvisi?

[lopata]

Dobre, tak mam predbeznou znalost "chci vyhledavat mezi stringy s neohranicenou delkou, jejichz celkova velikost bude maximalne takova, aby se mi vsechny vesly do pameti, ktera ma 16G". Jak udelam s takovym zadanim vyhledavani se slozitosti O(1)?

Udělám to jednoduše, nebudu znovuvynalézat kolo a použiju něco hotového: http://cmph.sourceforge.net/.
Doporučuju ke čtení ještě http://cmph.sourceforge.net/papers/wads07.pdf, rozšíříš si tím obzory.

Pokud se budeš snažit argumentovat tím, že spočítat hash na stringu proměnné délky nejde v konstatním čase, tak by se o tom zaprvé dalo diskutovat (ale to se mi nechce) a zadruhé je to úplně jedno, protože tohle se ve složitosti normálně zanedbává. Ono by ti to udělalo binec i ve složitosti hledání ve stromu, protože porovnat dva velmi dlouhé stringy může trvat velmi dlouho. Máš to započítané ve složitosti hledání ve stromu? Nemáš, počítá se to jako konstatní operace.

[JS]

Funkcionalne programovanie je hlavne neintuitivne, preto sa netesi popularite. Ked programujem funkcionalne pripadam si ako matfyzak, ktory zo seba suka definicie. Nie ako bezny clovek, co si povie, ze teraz spravim toto a potom hento ...  Riesit veci cez definicie,  listy a rekurzie, bez vedlajsich efektov to je dobre mentalne cvicenie, no na problemy z praxe je fp nesikovny nastroj.

Ja mam opacnou zkusenost. Dlouho jsem se FP vyhybal, ale kdyz jsem si to zkusil, zjistil jsem, ze muj kod je prehlednejsi (protoze me to opravdu nuti ho lepe abstrahovat). A i kdyz to nemohu zatim moc pouzit, pral bych si, abych mohl.

A jinak nekteri lide tvrdi, ze lidem, kteri se s programovanim nikdy nesetkali, jde funkcionalni programovani lepe. Ono to "intuitivni" je o zvyku, lide se proste moc nechteji ucit neco zcela jineho, kdyz uz se to nejak naucili ve skole.

[BoneFlute]

Udělejme si v tom pořádek:
1. FP si nepůjčuje věci z jiných paradigmat. FP je paradigma samo o sobě.
2. Co si půjčuje z jiných paradigmat jsou tak maximálně jazyky.
3. Haskell je pure funkcionální, a z imperativního světa si tam fakt půjčuje pouze zápis některých monád a to kdo ví zda vůbec.
4. Opovrhování jinýmy paradigmaty je jen tvá fantazie. Nikde jsem nic takového nenaznačil.

Zopakuji co jsem chtěl říct: To, že vývojáři nepoužívají FP je jen otázka zvyku. FP rozhodně není neintuitivní.

Len ten zvyk trva uz nejako dlho, pricom su nonstop pokusy o pretlacenie FP do mainstreamu. A FP je taka dokonala paradigma, ze potrebuje aj objektove a proceduralne konstrukcie  inak je to hracka pre matematikov.

Vzhledem k tomu, že za 40let co existuje OOP (ať se vrátíme k tématu topicu) se programátoři nenaučili OOP používat a dál to patlají procedurálně, jsem optimistou.
To by ostatně mohlo odpovědět na tvou otázku, proč že prej FP není v mainstreamu. Těch důvodů je pochopitelně více, a hlavně bych je hledal v technické oblasti, ale jedním z nich je skutečnost, že třeba v Haskellu funkcionálně programovat musíš. Zatímco v Javě objektově nikoliv.

[JS]

Protože já stále vidím, že mícháte dva problémy: jak se dají řešit programátorské problémy a jak se dají řešit lidské problémy programátorů (tedy především domluva, respektive neschopnost se domluvit).
GOF naopak velmi správně naznali, že toto klasické řešení "jsme všichni fundovaní matematici, takže se domluvíme matematickými abstrakcemi" je naprosto nefunkční v době masové produkce SW.

Jestli tohle byl zamer GoF, tak o nich mam jeste horsi mineni. Vytvorenim dalsi zbytecne terminologie se komunikacni problem nevyresi.

Mozna je problem v te predstave, ze produkce SW musi byt masova.. Mozna kdyby se od toho ustoupilo, redukovalo by se to prave na dobre pasujici dilky (skrze typovy system) a nebylo by potreba tolik lidi.

A to podle tehdejších měřítek, dnes je to mnohem horší; v té době ještě vývojáři sem tam potřebovali řešit algoritmy - dnes lze strávit úspěšnou kariéru jenom kombinací knihoven.

Moje zkusenost je takova, ze znovupouzitelnost FP kodu je mnohem vyssi nez u OOP kodu. Prave proto, ze to nuti cloveka rozbit ten problem na male dilky, a prave proto, ze se data neskryvaji.

Takze, pokud chces, aby software byl jako LEGO, a nerozpadl se, az tech dilku bude moc, FP (aka treba Haskell) je ta prava cesta.

[JS]

Je to podobne elegantni jako to GOTO. Problem nastane, jakmile si uvedomis, ze pokud mas takovou sit vzajemnych odkazu, musis nejak resit updatovani vsech vadnych pointeru, a jak je najdes, aniz by neco melo prehled o tom, co kam ukazuje? Proste pokud datova struktura neni strom, existuji tam extra naklady na praci s ni, ktere opomijis.

Teď ještě, co jsou to ty "vadné pointery".

Napr. kdyz se rozhodnu nejaky pointer zmenit nebo odebrat. Pokud mam cyklickou strukturu, musim mit neco, co vi o vsech ostatnich pointerech na ten dany objekt, aby bylo mozne rozhodnout, zda ho uvolnit. Nebo kdyz si nekde jinde drzim nejakou informaci, ktera zavisi na strukture tech pointeru, musim tu informaci upravit. Takze nestaci jenom potencialne cyklicka sit objektu, musi byt nejake dalsi ridici objekty, ktere resi tyhle situace. Ja si aspon nedovedu predstavit, ze bych graf mel reprezentovany jen pomoci uzlu, aniz bych treba vedel, kolik jich je.

(Proto je v databazich schema centralizovane, aby se mohl vytvorit provadeci plan.)

[JS]

Takové nešťastně řečené. Haskell má třídy (říká jim typy) a interface (říká jim třídy). A je to dost důležitý a užívaný koncept. Snad ten nejdůležitější v Haskellu, který jej odlišuje od ostatních FP jazyků. Ne nadarmo se používá úslový: "následuj typy".

Mas celkem pravdu. Ale i Java ma typy.. nepotrebujes navic pojem trida. Typova kontrola v Haskellu je fajn, ale vsechno by slo napsat uplne stejne i bez ni (proste bychom presli od typoveho lambda kalkulu k netypovemu).

Dale, typove tridy v Haskellu jsou mocnejsi nez interface, a v podstate by se bez nich dalo obejit - misto funkce vyzadujici typovou tridu by se proste do dane funkce predal dalsi parametr, n-tice funkci, jak jsou definovane pro danou instanci typove tridy. Tedy bychom mohli typovou tridu reprezentovat jako typ - n-tici nejakych funkci, parametrizovanou typem, nad kterym je definovana ta typova trida. V tomto smyslu jsou typove tridy jen usnadneni zapisu.

Jeste se mi v souvislosti s interfacy vybavuje Eric Meijer, ktery spravne rika, ze interface je velmi slaby kontrakt. Skutecny kontrakt jsou nejake zakony, ktere plati pro funkce definovane v ramci interfacu (nebo typove tridy, chces-li). Tahle falesna predstava je IMHO jeden z duvodu, proc jsou GoF navrhove vzory tak omezene - jelikoz jejich predstava kontraktu stoji a pada s interfacem, nemohou ve finale rikat nic extra zajimaveho o tom, co se snazi popsat.