Příspěvky

586

Vývoj / Re:Dědičnost dnes

« kdy: 31. 01. 2017, 21:48:43 »

Funkce v lambda kalkulu jsou relace. Celý lambda kalkulus je jen notace pro zapisování funkcí (vytváření funkcí z výrazů). Ale to už je skoro slovíčkaření, nechme to.

Nemusi byt, kdyz vezmu lambda kalkulus jako formalni system, nemusim o funkcich jako relacich nad mnozinami vubec nic vedet (podobne jako nemusim typy chapat jako mnoziny). Muzes definovat relaci jako vysledek beta-redukce, ale to uz tomu davas nejakou interpretaci.

Sorry, ale predikátová logika a lambda kalkulus nejsou alternativou jeden druhému. Navíc predikátová logika je formálně silnější.

Klasicka predikatova logika je o neco silnejsi, ale je otazka, jestli je to az takova vyhra. Jsou lide, treba Voevodsky, kteri by radsi videli alternativu v tom lambda kalkulu. Aspon ja v tom tedy vidim hlavne jazykovou barieru pro vetsi rozsireni automatickeho dokazovani. Ale matematici jsou konzervativni a chteji pouzivat predikatovou logiku, navic v ni maji napsano spousta kodu..

OK, filosofie matematiky není zrovna můj obor, tak se nebudu pouštět do polemiky, i když můj osobní pocit je, že na spoustě věci bychom se shodli.

587

Vývoj / Re:Dědičnost dnes

« kdy: 31. 01. 2017, 21:33:07 »

A nebo prostě trvá, než si na to lidi zvyknou.

Tak me napada, podobna situace je i v matematice. Vetsina matematiku pouziva normalni predikatovou logiku, ale lambda kalkulus (treba kalkulus konstrukci) by mozna byl praktictejsi. Jde zase jen o zvyk. :-) (Ne docela, je tady cela ta otazka konstruktivismu..)

Sorry, ale predikátová logika a lambda kalkulus nejsou alternativou jeden druhému. Navíc predikátová logika je formálně silnější.

Lambda calculus je turingovo kompletny. Ino by islo opisat predikatovu logiku lambda calculom, len by to bolo ako skrabanie sa lavou rukou za pravym uchom. Sklamem vas, ale lambda calculus je silnejsi, zvladne kazdy vypocitatelny problem.

Co to je za kecy? Zjisti si, co znamená turingovsky kompletní a kam ve výpočetní hierarchii spadá formální logika. Pak se můžeme bavit, proč je logika nerozhodnutelná a co je z ní třeba odebrat, aby byla.

588

Vývoj / Re:Dědičnost dnes

« kdy: 31. 01. 2017, 20:25:08 »

A nebo prostě trvá, než si na to lidi zvyknou.

Tak me napada, podobna situace je i v matematice. Vetsina matematiku pouziva normalni predikatovou logiku, ale lambda kalkulus (treba kalkulus konstrukci) by mozna byl praktictejsi. Jde zase jen o zvyk. :-) (Ne docela, je tady cela ta otazka konstruktivismu..)

Sorry, ale predikátová logika a lambda kalkulus nejsou alternativou jeden druhému. Navíc predikátová logika je formálně silnější.

589

Vývoj / Re:Dědičnost dnes

« kdy: 31. 01. 2017, 20:21:47 »

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.

Ne, to netvrdim, zaprve, neni potreba az takovy redukcionismus, a za druhe, mluvim spis o funkcich ve smyslu lambda kalkulu nez ve smyslu relaci.

Funkce v lambda kalkulu jsou relace. Celý lambda kalkulus je jen notace pro zapisování funkcí (vytváření funkcí z výrazů). Ale to už je skoro slovíčkaření, nechme to.

590

Vývoj / Re:Dědičnost dnes

« kdy: 31. 01. 2017, 15:56:05 »

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.

591

Vývoj / Re:Dědičnost dnes

« kdy: 31. 01. 2017, 15:12:05 »

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

I z pohledu abstrakce nebo nejake "pohodlnosti" by to bylo zajimave, pokud by ten rozdil byl fakt propastny.

Tak fajn, myslel jsem, že se hádáte jen o efektivitě, v tom případě se zdržím

592

Vývoj / Re:Dědičnost dnes

« kdy: 31. 01. 2017, 15:04:20 »

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.

593

Vývoj / Re:Dědičnost dnes

« kdy: 31. 01. 2017, 14:45:02 »

Jednoduchost implementace grafu v OOP?

A z toho má plynout co?

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.

594

Vývoj / Re:Prepojenie Raspberry Pi / Arduino a PHP

« kdy: 31. 01. 2017, 11:56:00 »

Pak asi fakt nechápu, proč do toho taháš nějaký externí webhosting?!

K čemu je čtečka připojená a jak?

No pretože potrebujem, aby s tým systémom vedeli pracovať aj administrátori v kancelárií a podobne.

Čítačka je normálne pripojená cez USB rozhranie do počítaču.

Myslím, že to je celkem jasné. Pokud musí existovat nějaký server (veřejný nebo lokální), tak se prostě udělá long polling. Provozovateli to bude jedno a navenek se to bude tvářit jako push. Nic víc k tomu vymyslet nejde.

595

Vývoj / Re:BSD licence vlastního kódu a zaměstnavatelé

« kdy: 31. 01. 2017, 09:56:19 »

Tady se člověk dočte perly. Doufám že se radami typu "v práci přemýšlej, piš a commituj doma a pak to zaměstnavateli licencuj..." nebude nikdo řídit...

+1. Predpokladam, ze v pracovnej zmluve nema, ze v praci bude premyslat, doma nasledne nieco napise a licencia patri jemu. V takom pripade by som to predbezne hodnotil ako hrube porusenie pracovnej disciplíny. Okrem ineho poberal mzdu za dobu,  ked mal vykonavat cinnost pre zamestnavatela definovanu svojou pracovnou zmluvou, ale nekonal tak (zavazne porusil povinnosti vyplyvajuce s pracovnopravneho vztahu).

Všechno plyne ze smlouvy a zákoníku. Smlouvu sem těžko dá, takže se předpokládá default (zákoník). Ten definuje celkem jasně, co je zaměstnanecké dílo, a autorský zákon dodefinuje, jak do toho zapadnou licence. Situace je celkem jasná.

596

Vývoj / Re:Dědičnost dnes

« kdy: 31. 01. 2017, 09:53:44 »

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.

597

Vývoj / Re:Dědičnost dnes

« kdy: 31. 01. 2017, 09:51:10 »

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.

598

Vývoj / Re:Dědičnost dnes

« kdy: 31. 01. 2017, 01:17:31 »

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.

599

Vývoj / Re:Vytvoření minimalistického pseudo kódu

« kdy: 30. 01. 2017, 20:04:46 »

co to ma delat, co a jakym zpusobem tomu budu cpat na vstupu a co  je pozadovany vysledek zpracovani dat ze vstupu, proste popsat formalizovane pozadovanou funkcnost

Takto funguje Prolog.

600

Vývoj / Re:Dědičnost dnes

« kdy: 30. 01. 2017, 19:32:50 »

Proč se teda ten tvůj Smalltalk a dynamické typování skoro na nic nepoužívá? Pochybuju, že tvůrci C++ a Javy byli úplně mimo a nic nechápali.

Sranda je, ze on by se mozna pouzival, kdyby Java nevznikla.. Zacatkem 90.let to byla pomerne silna konkurence C++ a psaly se v tom i business aplikace (IBM do toho treba hodne investovala).

Ale Java prisla a byla zdarma.. a jak uz to tak v IT byva, otevrene veci zvitezi, i kdyz jsou horsi. S kvalitou to nema moc co delat.

Smalltalk byl zrovna hodně uzavřený (a drahý), proto se významně nerozšířil. Paradoxem osudu je, že Sun před spácháním Javy používal ObjC, dokonce si s NeXTem navrhli vlastní standardní API, kterému se Java velmi nápadně podobá, protože Sun koupil Lighthouse a donutil jeho programátory psát pro Javu. The rest is history.

A kdyby nezatkli Patricka Naughtona, protože si dopisoval s agentem FBI vydávájícím se za malou holčičku o sexu s nezletilými, mohla Java vypadat úplně jinak, protože na rozdíl od Goslinga Naughton chtěl mít Javu podstatně "objektovější". Shit (and Java) happens.