Dědičnost dnes

[balki]

Jinak existuji skutecne "design patterns" v FP. Jsou to veci jako treba funktor, nebo monada, nebo monoid, nebo traversable.. typicky (v Haskellu) definovany pres nejakou typovou tridu a zakony, ktere pro ne plati. Ale to uz je o necem trochu jinem, a v jistem smyslu je to mnohem zajimavejsi (protoze lepe definovane) nez design patterns z GoF book.

To nejsou vzory, ale normální matematické koncepty.

Rypes do toho pekne (zbytecne), ale jsou to vzory podle te puvodni Alexanderovy definice.

Kazdopadne, spis to byl povzdech nad tim, ze to co se nazyva "software design patterns" jsou triviality, ktere zpopularizovala GoF knizka, pritom lepe by bylo, kdyby doslo k tomu, ze si programatori uvedomi Howard-Curry korespondenci, a dojde jim, ze kazdy vzor v programovani ma svuj odraz v matematice a naopak. Neblamuji za to ani tak autory, ti proste sami moc nevedeli, co delaji (ja sam jsem o FP jeste pred par lety nic moc nevedel, na druhou stranu, ja aspon nepisu knihy, jak psat software a nestudoval jsem puvodne computer science), spis kolektivni nevedomi programatoru, ktere se vyse uvedenym prispevkem snazim napravit.

Jak uz jsem psal, vyvoj v IT probiha od slozitejsiho k jednodussimu, a chvili trva, nez si uvedomime, ze nejake pojmy popisuji totez a zjistime, ze vlastne cast z nich nepotrebujeme.

Funkcionalne programovanie tu existuje bezmala 70 rokov. Gang of four nie su ziadni hlupaci, je naivne predpokladat, ze o tom nic nevedeli. GoF vzory nie su raketova veda, ale vypozorovane overene riesenia z praxe. Da sa namietat, ze niektore vzory su hrackarske (napriklad interpreter), ale obvinovai ich z nevedomosti, to je trosku silna kava.  Proste spravili katalog overenych rieseni pre oblubenu paradigmu. Problem vzorov je ten, ze si ludia neprecitaju poriadne definicie, nevedia o com ten vzor je a bud ich nevhodne pouziju, alebo z nevedomosti na ne nadavaju. Slepo kopiruju implementacie, ktore niekde videli a nevedia si vzor usposobit pre svoje potreby, alebo usposobia zle.

Mate male bezvyznamne plus, ze ste zmienili Christophera Alexandra a jeho definicie navrhovych vzorov. Spomeniem este Jima Copliena, ktory tieto definicie priviedol do sveta pocitacov.
Ked si pozriete alexandrove architektonicke vzory, tiez su to "triviality".

[Reklama]

[JS]

Horší je to právě s tím stromem - v FP musím při zápisu někde dole zpětně "přeskládat" celý strom, nemůžu jenom najít list, zapsat do něj a mám hotovo.

To neni tak docela pravda, staci jen vtipne "pretacet" pointery (menit misto, kde ten strom ma koren), rika se tomu zipper.

Kazdopadne, je treba si uvedomit, ze FP je abstrakce, ktera ma slouzit programatorum, aby jejich kodu slo lepe porozumet (a byl lepe udrzovatelny), nikoli pocitacum, aby provadeli ten kod rychleji. To je casty mylny dojem. FP dnes fakticky znamena cenu navic, kterou se kompilatory postupne snazi dohnat. Je nadeje, ze to pomuze lepe psat treba vicevlaknove programy, ale zatim to tak docela neni.

Je to podobne jako treba s GOTO. Dnesni jazyky GOTO neumoznuji, prestoze by to v nekterych situacich bylo efektivnejsi (treba obecne stavove automaty, rizeni vyjimek, atd.). Spoleha se misto toho na kompilator, ze z relativne cisteho strukturovaneho kodu vytvori efektivni spagety.

Takze abych se vratil k tomu, ze FP neumoznuje datove struktury obsahujici cykly. Je to proste podobny trade-off. Kdyz definujes takovou strukturu, musis se vyporadat s tim, ze zmena pointeru potencialne znamena memory leak (nebo pro rypaly - GC cyklus, vyber si svuj jed). Proto je lepsi se jim vyhnout, a vetsinou to jde. Ale je celkem dobre mozne, ze jsou treba pouzite v nejake knihovne, jejiz API je navenek zcela funkcionalni.

Je to asi podobne jako kdyby sis stezoval, ve strukturovanem programovani, hm, kdyz mam vsechno definovane jako procedury a jejich volani, tak se nemuzu "jen tak" vratit do uz existujiciho stack framu (aniz bych zrusil ty volane). Jelikoz to neni obecne dobry napad, delat takove veci, tak se s tim proste naucis pracovat. Analogicky, zase muze existovat knihovna (nebo spis kompilator), ktera treba efektivne implementuje stavove automaty, a tohle pravidlo interne celkem bezne porusuje.

[JS]

Určitě je to rychlé (na to ale obvykle sere pes), ale hlavně jednoduché a objektové - využívá to identitu (základní vlastnost OOP), data se neindexují - to je antivzor oblíbený u relačníků.

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.

[JS]

Funkcionalne programovanie tu existuje bezmala 70 rokov. Gang of four nie su ziadni hlupaci, je naivne predpokladat, ze o tom nic nevedeli.

To neni, co rikam. Mozna o tom slyseli nekdy na prednasce. Ale stejne to udelali spatne, protoze jsou jen lide. Tehdy bylo OOP celkem popularni, dnes jsme zjistili, ze FP ma asi vic vyhod, a situace se zmenila.

To se deje vsude. Prvni bezne hard disky byly CKD, chvili trvalo, nez navrharum doslo, ze jim staci LBA. Prvni soubory mely zaznamovou strukturu, zase trvalo, nez se prislo na to, ze je lepsi proste posloupnost bajtu. Atd. Neni to o tom, ze by byli blbi, ale meli bud konkretni duvod (ktery prestal postupne platit), nebo si proste jen mysleli, ze to nejak necemu pomuze. Mylili se.

No a stejne bude beznym programatorum chvili trvat, ze je nejlepsi (vicemene) vsechno brat jako (matematicke) funkce.. John Backus tohle rikal uz v 70. letech.

[balki]

Takze vezmime si konfiguraciu aplikacie, ktora sa kazdych x minut obnovuje. A budem mat 50 nekonzistentnych konfiguracnych objektov, lebo pan riesi Http request a filesystem. Alebo spravi sa singleton a budem mat konfiguraciu na jednom mieste, pre vsetkych rovnaku.

Dalsi priklad mam rozhranie rs232, tam nie je httprequest alebo databaza, problem je vsak, ze je len jedno. Bud vymyslim neviem ake zamykanie cez 50 instancii, alebo si proste spravim singleton.

Potrebujem nieco serializovat von do nejakeho mrdkoveho suboru, co nema http request ani databazu, a je potrebne aby sa do neho nezapisovalo z 50 miest. Takze bud spravim sialene zamykanie cez 50 instancii, alebo spravim singleton. Pripadne sa zahram na to, ze som jouda a singleton nepoznam a ten isty objekt odovzdavam vo vsetkych metodach. To je potom "super", zbytocne to tam zavadzia.

Dalsi relevantny pripad. Chcem sa vyhnut "statickej" triede, lebo je to vlastne zkripleny objekt a ja chcem normalny, pouzijem singleton.

Ked robim webku pre jouda sro v php, mozno singletony nie su treba. Ale pri roznych IRL aplikaciach potreba nastava. U vas toho polku zariadi webserver a ani o tom neviete.  Ja osobne, kde mozem, pouzijem framework, co sa o instancie stara za mna. Ale su pripady, ked nemozem, lebo kodim zrovna lib-ku, co ma mat zavislost iba na java api. Tam singleton vyuzijem.

Tak to jsou zrovna hodně špatné příklady - to, že potřebujete číst jedinou konfiguraci, používat jedno spojení a komunikovat přes jeden sériák, neznamená, že je musíte vyrobit jako jedináčka. Objekt, který s nimi pracuje, je má dostat při inicializaci nebo spuštění akce (nebo od někoho, koho zná). Co se stane, když budete mít více konfiguráků? Když přidáte další sériák? Když budete komunikovat s 3 servery?
Toto řešení mi spíš zavání globálními odkazy přes třídu. Antivzor znemožňující testování, zvyšující coupling a zabordelující aplikaci!

Že nejdou třídní věci dát do třídy, protože je Java zprasená, je věcí druhou.

To je toho prskania, musel som si ocistit macbook. Ked budem potrebovat 3 seriaky, odstranim singleton z objektu a spravim si pool. A zrovna ten pool bude tiez singleton. To da kurevsku praci zmazat tri riadky. A ze je globalny objekt pre aplikaciu, ano je, o tom je, to je feature.

Musim ocenit, ze viete googlit ale:

• Nevola sa to triedne, ale objektovo-orientovane programovanie. Je to objektoch, triedy nestastne vymyslel Kay.
• Testovanie singleton neztazuje, staci si nastavit pri testovani singleton. Skobinujem ho so vzorom strategy a voila, da sa to menit za hocico! Brutalne tazka robota. Rozne mock objekty a  netrivialne zavislosti testovanie komplikuju viac. Btw unit testy ako su dnes vymyslene nie su objektove.
• Viac konfigurakov v jednej aplikacii? To je naco dobre?

[Reklama]

[Mirek Prýmek]

To neni tak docela pravda, staci jen vtipne "pretacet" pointery (menit misto, kde ten strom ma koren), rika se tomu zipper.

Jo, já jsem myslel strom, kde ta struktura nese význam. Např. strom internetových domén - v kořeni mám '.', pod ním dítě 'cz', pod ním 'root'...

Je to podobne jako treba s GOTO. Dnesni jazyky GOTO neumoznuji, prestoze by to v nekterych situacich bylo efektivnejsi (treba obecne stavove automaty, rizeni vyjimek, atd.). Spoleha se misto toho na kompilator, ze z relativne cisteho strukturovaneho kodu vytvori efektivni spagety.

To je moc pěkný přirovnání. A kruhem ( ) se tak zpátky dostáváme k tomu, co už tady zaznělo - že zajímavé je, když v jazyce něco zakážu (protože mi to poskytuje nějakou garanci), ne když něco povolím. To je ta chyba v uvažování lidí, kteří si myslí, že když někam přidám map a fold, tak mi vznikne funkcionální jazyk...

Napadá mě role rodič, potomek - jejich vzájemné spojení. Zaměstnanec-pracovní místo, ...

Viz to, co už tady zaznělo - existují na to reprezentace bez cyklů. V něčem jsou možná míň efektivní, v něčem zase víc. Záleží na úplně konkrétním způsobu použití. Já neznám žádný use case, kde by absence cyklů vedla k nějakému úplně zásadnímu problému. Jednak existence cyklů v datech dost často sama o sobě ukazuje na problematický návrh (jakmile vidím cyklus, měl bych zpozornět), jednak ten cyklus prostě můžu reprezentovat všelijak jinak než přímými referencemi.

[balki]

Funkcionalne programovanie tu existuje bezmala 70 rokov. Gang of four nie su ziadni hlupaci, je naivne predpokladat, ze o tom nic nevedeli.

To neni, co rikam. Mozna o tom slyseli nekdy na prednasce. Ale stejne to udelali spatne, protoze jsou jen lide. Tehdy bylo OOP celkem popularni, dnes jsme zjistili, ze FP ma asi vic vyhod, a situace se zmenila.

To se deje vsude. Prvni bezne hard disky byly CKD, chvili trvalo, nez navrharum doslo, ze jim staci LBA. Prvni soubory mely zaznamovou strukturu, zase trvalo, nez se prislo na to, ze je lepsi proste posloupnost bajtu. Atd. Neni to o tom, ze by byli blbi, ale meli bud konkretni duvod (ktery prestal postupne platit), nebo si proste jen mysleli, ze to nejak necemu pomuze. Mylili se.

No a stejne bude beznym programatorum chvili trvat, ze je nejlepsi (vicemene) vsechno brat jako (matematicke) funkce.. John Backus tohle rikal uz v 70. letech.

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.
Alebo to potom dopadne ako emacs lisp, kde si pridali vsetko mozne a nakoniec funkcionalne nerobia.

[zboj]

Horší je to právě s tím stromem - v FP musím při zápisu někde dole zpětně "přeskládat" celý strom, nemůžu jenom najít list, zapsat do něj a mám hotovo.

To neni tak docela pravda, staci jen vtipne "pretacet" pointery (menit misto, kde ten strom ma koren), rika se tomu zipper.

Čekal jsem, kdy někdo vytáhne zippery a příslušné derivace.

[Mirek Prýmek]

Funkcionalne programovanie je hlavne neintuitivne, preto sa netesi popularite. [...]  Riesit veci cez definicie,  listy a rekurzie, bez vedlajsich efektov to je dobre mentalne cvicenie, no na problemy z praxe je fp nesikovny nastroj.

<pokus o humor>a to ještě nemluvíme o Prologu!</pokus o humor>

Pozor, "čisté FP" (bez vedlejších efektů) je jenom podskupina celého FP. Kromě něj taky existuje rodina vycházející ze Standard ML, která side effecty má -> programuje se normálně imperativně, úplně stejně jako kdekoli jinde a nejsou potřeba monády apod.

[zboj]

No a stejne bude beznym programatorum chvili trvat, ze je nejlepsi (vicemene) vsechno brat jako (matematicke) funkce.

Hodně silné (a nepravdivé) tvrzení. V podstatě tvrdíš, že je nejlepší vše brát jako relace nebo přímo množiny (protože co jiného jsou funkce). Chtěl bych vidět ten tvůj množinový kód řešící všechno nejlépe.

[v]

Funkcionalne programovanie tu existuje bezmala 70 rokov. Gang of four nie su ziadni hlupaci, je naivne predpokladat, ze o tom nic nevedeli.

To neni, co rikam. Mozna o tom slyseli nekdy na prednasce. Ale stejne to udelali spatne, protoze jsou jen lide. Tehdy bylo OOP celkem popularni, dnes jsme zjistili, ze FP ma asi vic vyhod, a situace se zmenila.

To se deje vsude. Prvni bezne hard disky byly CKD, chvili trvalo, nez navrharum doslo, ze jim staci LBA. Prvni soubory mely zaznamovou strukturu, zase trvalo, nez se prislo na to, ze je lepsi proste posloupnost bajtu. Atd. Neni to o tom, ze by byli blbi, ale meli bud konkretni duvod (ktery prestal postupne platit), nebo si proste jen mysleli, ze to nejak necemu pomuze. Mylili se.

No a stejne bude beznym programatorum chvili trvat, ze je nejlepsi (vicemene) vsechno brat jako (matematicke) funkce.. John Backus tohle rikal uz v 70. letech.

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.
Alebo to potom dopadne ako emacs lisp, kde si pridali vsetko mozne a nakoniec funkcionalne nerobia.

za sebe můžu říct, že na překladače a komunikační protokoly je haskell docela šikovný

[gll]

Ta reprezentace s kruhoými odkazy je zase neefektivní, pokud budu chtít seznam všech vrcholů - já to mám s časovou složitostí 0, vy s n

v mé reprezentaci mám seznam všech vrcholů přístupný na jeden průchod.

vrchol je trojice (id, odkaz_na_predchozi_vrchol,  seznam_hran)

hrana je trojice (odkaz_na_vrchol, delka, odkaz_na_predchozi_hranu)

pokud je n počet vrcholů, tak seznam vrcholů projdu v čase n, vy také. Pro ryclé hledání podle id si mohu vytvořit další strukturu s odkazy na ten seznam.

Pokud by můj primární use case bylo hledat sousedící hrany, tak bych zvolil jinou reprezentaci, nejspíš tuhle:

Kód: [Vybrat]

%{vrchol1: [vrchol2, vrchol3], vrchol3: [vrchol4]}
- tj. asociativní pole vrchol=>seznam sousedů.

to je v praxi asi nejlepší reprezentace, ale některé algoritmy budou mít horší asymptotickou složitost.
návštěva sousedních vrcholů je pomalejší. viz níže.

Asi ne seznam hran, ale seznam vrcholů. Ano, to skutečně v FP pro obecný graf udělat nejde. Ale nevadí to, protože máme jiné možné reprezentace. A je otázka, jestli to, že to v ostatních jazycích jde, za to skutečně stojí. Plynou z toho totiž pak např. takové věci, jako že když chce Ruby udělat GC, musí zastavit celý svět. Velice nepříjemná vlastnost pro produkci...

imperativní jazyky mají mutable hashmapy s časem přístupu n(1), odkazy bych v nich nepoužíval

Jinak normální slovník (hashmap) je třeba v Elixiru first class citizen, takže je implementovaný v runtimu nejefektivnějším možným způsobem - maximální složitost pro čtení i zápis je log(n).

proto, aby šlo rychle bez kopírování dostat změněnou kopii, to ve skutečnosti není hashmapa, ale nějaká forma stromu.

http://stackoverflow.com/questions/35677865/is-map-lookup-in-elixir-o1

přístup k prvku má složitost O(log n), nikoli O(1) jako u hashmapy

Horší je to právě s tím stromem - v FP musím při zápisu někde dole zpětně "přeskládat" celý strom, nemůžu jenom najít list, zapsat do něj a mám hotovo. To je pravda. Ale opakuju: No a? Co z toho plyne? Že FP není ve všem lepší? No jasně, to přece nikdo netvrdí.

opravdovou hashmapu byste musel kopírovat při každé změně, pokud má být immutable. Právě proto se v FP jazycích používají stromy.

[Kamil Podlešák]

Jinak existuji skutecne "design patterns" v FP. Jsou to veci jako treba funktor, nebo monada, nebo monoid, nebo traversable.. typicky (v Haskellu) definovany pres nejakou typovou tridu a zakony, ktere pro ne plati. Ale to uz je o necem trochu jinem, a v jistem smyslu je to mnohem zajimavejsi (protoze lepe definovane) nez design patterns z GoF book.

To nejsou vzory, ale normální matematické koncepty.

Rypes do toho pekne (zbytecne), ale jsou to vzory podle te puvodni Alexanderovy definice.

Kazdopadne, spis to byl povzdech nad tim, ze to co se nazyva "software design patterns" jsou triviality, ktere zpopularizovala GoF knizka, pritom lepe by bylo, kdyby doslo k tomu, ze si programatori uvedomi Howard-Curry korespondenci, a dojde jim, ze kazdy vzor v programovani ma svuj odraz v matematice a naopak. Neblamuji za to ani tak autory, ti proste sami moc nevedeli, co delaji (ja sam jsem o FP jeste pred par lety nic moc nevedel, na druhou stranu, ja aspon nepisu knihy, jak psat software a nestudoval jsem puvodne computer science), spis kolektivni nevedomi programatoru, ktere se vyse uvedenym prispevkem snazim napravit.

Máš nějaký reálný důvod myslet si že nevěděli co dělají, nebo to jenom tak dedukuješ?

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. 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.

[gll]

dnes lze strávit úspěšnou kariéru jenom kombinací knihoven.

Právě design patterny dělají z psaní a používání knihoven zbytečnou vědu.

[Mirek Prýmek]

pokud je n počet vrcholů, tak seznam vrcholů projdu v čase n, vy také.

teď si asi v něčem nerozumíme, nebo nevím. Mluvili jsme o reprezentaci způsobem (Python):

Kód: [Vybrat]

a = {}
b = {'peers': [a]}
a['peers'] = [b]
versus (Elixir)

Kód: [Vybrat]

a = ...
b = ...
nodes = [a,b]
edges = [(a,b),(b,a)]
Pokud chci u té první reprezentace získat seznam všech vrcholů, musím je nejenom všechny postupně projít (složitost n), ale navíc musím ještě kontrolovat, které už jsem navštívil (protože cykly).

to je v praxi asi nejlepší reprezentace, ale některé algoritmy budou mít horší asymptotickou složitost.
návštěva sousedních vrcholů je pomalejší. viz níže.

Ale vždyť jsem to psal: návštěva sousedů je pomalejší, ale vyvoření seznam všech vrcholů je rychlejší (nulová náročnost - už to mám rovnou). Záleží, co chci, a podle toho volím reprezentaci. Nerozumím, o čem se vlastně bavíme.

imperativní jazyky mají mutable hashmapy s časem přístupu n(1), odkazy bych v nich nepoužíval

Neplést prosím střední a maximální časovou složitost. Vyhledávání s maximální složitostí (o té jsem psal) O(1) neexistuje. Optimální složitost pro nejhorší případ je O(log n).

viz http://stackoverflow.com/a/9214594/3150343

opravdovou hashmapu byste musel kopírovat při každé změně, pokud má být immutable. Právě proto se v FP jazycích používají stromy.

Nemusí. Runtime ví, jestli se do mapy zapisuje, a může klidně použít jakoukoli implementaci.