Zobrazit příspěvky

Tato sekce Vám umožňuje zobrazit všechny příspěvky tohoto uživatele. Prosím uvědomte si, že můžete vidět příspěvky pouze z oblastí Vám přístupných.


Příspěvky - BoneFlute

Stran: 1 ... 123 124 [125] 126 127 ... 133
1861
Odkladiště / Re:Proč bitcoin?
« kdy: 27. 08. 2015, 01:14:26 »
No tak to stačí vyprat, ne? Prostředník, který na jedné straně přijímá bitcoiny, a na druhé straně je vydává, přičemž zahazuje vztah mezi tím.
Tak uvidíme že částka šla od A k B a za chvíli tatáž nebo lehce menší částka od B k C.
Aby to praní bylo zvenku nevysledovatelné, musel by ten prostředník být charakteru banky, kde jsou vklady a převody různé v čase i velikosti. Jenže to pak zas nemůže vztahy zahazovat, aby vůbec jako banka fungoval.
Proč by nemohla? Samozřejmě ty vztahy bude zahazovat až jak bude moct. Ale cíl je splněn.

1862
Odkladiště / Re:Proč bitcoin?
« kdy: 26. 08. 2015, 22:42:09 »
> Ano, ale vidíš, že HUIhkeuIzýÝuihf3 platil 0.541 BTC 1huiÁiuh26cIPQ. Může být dost obtížné ty identity přiřadit ke skutečným osobám.
Ano, z počátku nevíme, čí ty adresy jsou. Ale záznam o transakci je nesmazatelně zapsán v historii a čeká na profláknutí identity. Víme taky s kým dalším ty adresy vstupovaly do styku, a takhle se dřív nebo později skrze vztahy něco odhalí. Zatímco hotovostní platba žádný záznam nedělá, a i bankovní transakce se dohledávají obtížněji (vědět vůbec jaké banky se použilo, soudní příkaz, problém s přeshraniční jurisdikcí...)
No tak to stačí vyprat, ne? Prostředník, který na jedné straně přijímá bitcoiny, a na druhé straně je vydává, přičemž zahazuje vztah mezi tím.

1863
Vývoj / Re:Programovaci jazyk budoucnosti
« kdy: 26. 08. 2015, 20:39:47 »
Jako kreacionistu by mě zajímalo, existuje nějaký program, který simuluje evoluci tak, jak to popisují pánové od Evoluční biologie?
Pro upřesnění, zajímá mě stroj, který zvyšuje svou informační komplexitu aniž by tomu byl nadřazen systém, který ji má ještě vyšší.

Existuje a je to inspirováno... evoluční biologií ;)
https://cs.wikipedia.org/wiki/Genetick%C3%BD_algoritmus
Teorii znám. Pár evolučních programů jsem si taky spíchnul. Ale zajímaly by mě nějaké příklady implementací.
Já jsem si vzpoměl na jistý polymorfní vir, tuším, že se jmenoval hydra. Ten se vyvíjel až hrůza.

Ale hlavně aby pokud možno co nejvíc odpovídali zadání Evoluční biologie. To ten můj příklad s virem byl bohužel jen prostá variabilita.


1864
Vývoj / Re:Programovaci jazyk budoucnosti
« kdy: 26. 08. 2015, 18:55:07 »
vyviji se v case (evoluce) ... 

Jako kreacionistu by mě zajímalo, existuje nějaký program, který simuluje evoluci tak, jak to popisují pánové od Evoluční biologie?
Pro upřesnění, zajímá mě stroj, který zvyšuje svou informační komplexitu aniž by tomu byl nadřazen systém, který ji má ještě vyšší.

1865
Vývoj / Re:Programovaci jazyk budoucnosti
« kdy: 25. 08. 2015, 13:55:01 »
Podle mně se časem běžné programování posune do grafického programování. Dneska už existuje Matlab/Simulink, nebo do určité míry propracovanější LabView, kde můžeš napsat pěkně složité systémy bez toho aby jsi napsal jedinou čárku kódu a také neporovnatelně rychleji.
Třeba tady v tom videu udělá za necelých 5 minut pomalým tempem plně funkční aplikaci pro snímáni obrazu z kamery
https://www.youtube.com/watch?v=aJCxJLuAhTs

Mě se to líbí.
Ještě by mohli u těch elementů prezentovat tečoucí data, ať člověk může okem odhadnout, zda to dělá co má.
A taky by na to mohli poslat grafika. Ty ikony jsou děsný :-)

1866
Vývoj / Re:Funkcionální jazyky.
« kdy: 20. 08. 2015, 02:17:06 »
U tohodle vycházím ze dvou věcí:

1. snad každá učebnice OOP uvádí příklady z reálného světa jako právě třeba to Člověk-Savec-Strunatec     - a dost často se tam najde dovětek typu "vidíte, přesně takhle o tom přece normálně uvažujete!" - ano, u Člověk-Savec-Strunatec to funguje. U Žárovka-Světlo taky. Ale jakmile začne člověk řešit skutečný program v reálném nasazení, nebo si aspoň přečte pár debat o takových problémech, zjistí, že OOP se až podezřele často zabývá samo sebou místo problému, který je k řešení...

2. velice často se v debatách o tom, jestli nějaký návrh je nebo není vhodný, argumentuje analogiemi z reálného světa. Jako například že máslo nelétá nebo psa se na nic neptáme. Čili tam lidi zjevně analogii minimálně nevědomě očekávají, jinak by je nenapadlo takhle argumentovat. Nikdo nezdůvodňuje statiku domu tím, že mu tohle řešení víc připomíná zmrzlinu, takže je lepší.

(lehce si z toho dělám srandu, to je doufám poznat)

No já nevím. Já jsem o Člověku jako o Savci, natož Strunatci uvažoval naposled na základce. Čímž si tak nějak nenápadně přihřívám polívčičku, že dědění u OOP nemám rád.

Myslím si, že OOP je o analogiích z reálného světa. Hlavně o modelování.

A příklad s učebnicemi je poněkud nešťastný. Papír snese všechno.

1867
Vývoj / Re:Funkcionální jazyky.
« kdy: 19. 08. 2015, 21:49:18 »
Co konkrétně? Já se z Haskellu hodně inspiruju, a jeho praktiky používám i v OOP.
Já jsem konkrétně dost vystřízlivěl z propagandy, že OOP odpovídá tomu, jak skutečně myslíme. Z toho tvrzení, že OOP-uvažování odpovídá přirozenému způsobu práce s pojmy (Sysel je Savec, Savec je Strunatec...). Když se koukneš na to, o čem jsme se bavili teď, co to má propánakrále společného s (nám) přirozeným způsobem uvažování?! :)

Nedá mi to a připomenu dnes již starou polemiku mezi p. Viriusem a p.Čadou o tom, jak jsou na tom z hlediska třídního OOP třídy reálných a komplexních čísel. Vyplynulo z toho, že návrh OOP hierarchie není tak jednoduchý, jak by se mohlo zdát (a nepřímo vyplynula poučka, že dědičnost mnohdy přináší víc škody než užitku :D)

Já jsem nejdříve nadšeně opustil OOP ve prospěch FP. Konkrétně Haskellu. Pak jsem zjistil, že Haskell je víc OOP než Java s C# dohromady, ale že používat čistě jen blbé přepravky mě nebaví.

Takže:
- nepoužívám dědičnost na reusable kódu
- nedělám velké objekty
- dělám anemické objekty a objekty chovající se jako konfigurovatelné funkce
- fakt modeluju realitu přesně jak v to ty nevěříš

Zatím mi to vychází.

1868
Vývoj / Re:Funkcionální jazyky.
« kdy: 19. 08. 2015, 21:42:40 »
To asi nějak šlo, ale já právě mluvím o situaci, kdy ten formatter nemám. Např. deserializuju objekty ze souboru a chci do html vypsat jejich seznam. Čili pro každý objekt pak budu horko těžko hledat vhodný formatter.
A když by jsi ten formater měl součástí objektu, tak jsi na tom v čem líp?

1869
Vývoj / Re:Funkcionální jazyky.
« kdy: 19. 08. 2015, 21:39:23 »
Ano budu. To co popisuješ ty, je jako ukazovat na Máslo a říct: "padej do ledničky". Jako některá inteligentnější Másla to umí. Ale když koukám na našeho Psa, tak si říkám, že je někdy jednodužší ho tam dostat ručně (do boudy, do ledničky mu to de).
Jak jsem říkal, (už) nevěřím tomu, že OOP přímo souvisí s reálným světem a nevěřím argumentaci analogií z reálného světa. Kdybych si z toho chtěl dělat srandu (což vlastně chci! :)) ), tak lednička taky nefunguje tak, že když z ní chceš něco vzít, tak se staneš ledničkou, něco si tam vezmeš, pak se staneš zpátky BoneFlutem a juchů, máš to v ruce! A přitom přesně tohle vlákna v OOP dělají...
Hmm, nezaměňuješ teď tak trochu teorii s realitou?

Neodvažuji se tvrdit, jak moc je OOP inspirovaný reálným světem, ale většina těch nekoncepčností IMHO vychází z toho, že si to ti programátoři (případně i jazyky jako takové) dělají tak trochu po svém.

Lednička funguje tak, jak bych to OOP čekal. Mám ledničku. Má zprávu put. Má zprávu takeOut. Přijímá libovolné objekty, které mají zprávy getSize, getWeight. Když chci něco dát do ledničky, musím na to použít nějaký manipulátor Hands.

Pokud nepřijde Kit, který zakazuje gettery, tak mě to celkem sedí.

To s tím stát se ledničkou je sice pravda, to ti neberu, ale dá se s tím žít. A bavíme se o OOP, ne o konkrétní implementaci nějakého jazyka.

Ne. Pokud formátovací kód neexistuje, tak neexistuje, v tom se ta dvě řešení neliší a lišit nemůžou. Maximálně můžeš mít obecný formatter, ale to já taky (objekt metodu nepodporuje? Ok, tady je workaround...) Jediný skutečný rozdíl je přesně v tom, kde ten kód leží - já bych ho připlácl k datům, ty bys ho dal někam kdovíkam a pak ho při každé operaci horko těžko zase zpátky hledal. To mi prostě přijde zbytečný, nekoncepční a typicky OOP-přeplácaný. :) Ale už bych fakt tuhle věc opustil, není to důležitý ani jako offtopic :)
No, já bych zase řekl, že právě tento způsob vůbec není klasicky OOP. To jsem si přinesl z Haskellu. Nechci aby ten formater používal kdekdo.

1870
Vývoj / Re:Funkcionální jazyky.
« kdy: 19. 08. 2015, 20:52:30 »
3. Čistě filozoficky objekt Máslo by neměl umět létat letadlem. (A přesto létá.)
Čistě prakticky by bylo fajn umět jakoukoli operaci udělat s libovolným neznámým objektem, to je polymorfismus. Když ti dám objekt X, tak budeš zjišťovat reflexí, jaké je třídy, budeš se dívat do nějakého seznamu, jestli pro tu třídu máš formatter? No nevím :)
Ano budu. To co popisuješ ty, je jako ukazovat na Máslo a říct: "padej do ledničky". Jako některá inteligentnější Másla to umí. Ale když koukám na našeho Psa, tak si říkám, že je někdy jednodužší ho tam dostat ručně (do boudy, do ledničky mu to de).

Mimochodem to s tou reflexí, to nemáš pravdu. Rozdíl mezi tím tvým a mým je pouze umístění. Stejně jako mě může scházet formater, tak tobě může ten objekt to které formátování neumět.

1871
Vývoj / Re:Funkcionální jazyky.
« kdy: 19. 08. 2015, 20:34:25 »
děkuji kolegové, že jste mi připoměli proč oop nesnáším a proč mám rád haskell
Ano, ano, taky jsem se na to upomněl :)
Co konkrétně? Já se z Haskellu hodně inspiruju, a jeho praktiky používám i v OOP.

1872
Vývoj / Re:Funkcionální jazyky.
« kdy: 19. 08. 2015, 20:32:36 »
Já bych to udělal pomocí tří rozhraní:
1. Entry -  obsahuje vlastní objekt.
2. Formater - objekt získávající Entry a výsledek bude stream/string
3. Dump - objekt zastřešující vytisknutí libovolného objektu.

Takže třeba: objekt DumpJSON nakrmím formatery, a pak když budu chtít vytisknout Psa, tak se použije PesFormaterJSON.
Může být, o (ne)vhodnost nějakého OOP návrhu se rozhodně přít nebudu ;) Chápu, že v tomhle případě opravdu gettery potřebuješ (nebo použít frienda, což je ještě horší a navíc to jde jenom (?) pro C++).

Pocitově se mi to nelíbí proto, že ti tam vzniká jednoúčelová třída, která musí být napsaný přesně na míru třídě toho daného tisknutého objektu - např. když si vymyslíš novou třídu Mirek, musíš k ní vytvořit MirekFormatterJSON, která bude mít jedinou metodu formatToJSON, kterou bych daleko raději viděl v Mirkovi než kdekoli jinde, protože když bude jinde, zase musím vědět, že vůbec pro Mirka existuje, jak se jmenuje, horko těžko ho budu pro Mirka hledat automaticky... Nevím no, mně se to prostě pocitově (ne-odborně) nezdá :)

...a mám podezření, že se k tomuhle návrhu uchyluješ v podstatě jenom proto, že přemýšlíš v intencích jazyka, který neumožňuje bezbolestně rozšiřovat existující třídy[1], což by imho pořádný OOP jazyk umět měl ;)

[1] https://developer.apple.com/library/ios/documentation/Cocoa/Conceptual/ProgrammingWithObjectiveC/CustomizingExistingClasses/CustomizingExistingClasses.html

Mno, ve skutečnosti se k tomu uchyluji proto, že:
1. Nesnáším velké třídy. Třída Mirek obsahující metody toJSON, toXML, toAnything mě děsí, a mám s tím zlé zkušenosti.
2. Jestli ten kód napíšu do jednoúčelové třídy, nebo to vlepím do existujícího objektu... tak to radši tu jednoúčelovku.
3. Čistě filozoficky objekt Máslo by neměl umět létat letadlem. (A přesto létá.)
4. Poslední dobou si hodně hraju na kontext. V jednom místě aplikace potřebuju specielní transformaci objektu. Když tuto transformaci zadrátuju do dotyčného objektu, tak to tím zveřejním, a budou to chtít používat všude. To je moc odvážné.

1873
Vývoj / Re:Funkcionální jazyky.
« kdy: 19. 08. 2015, 19:50:06 »
Říkám, nejsem žádný odborník na OOP, ber to tak pls.
Beru neboj.

A když budu chtít, aby se mi ten objekt prezentoval v json, xml, pdf, ...?
No tak budeš muset mít další protokoly (interfaces) s metodami  toJSON, toXML, toPDF.
Upravování existujícího kódu. To není dobře.

Imho mi to s těmi gettery souvisí dost těsně, protože na to presentování budu používat nějaký jiný nástroj, kterému ten objekt předhodím. A ten bude reflexi toho objektu dělat pomocí getterů.
To nejde napsat obecně. Nevím, jak bys mohl zobrazovat libovolný neznámý objekt. Leda přes nějaké rozhraní typu Person, kde budeš mít jistotu, že daný objekt umí odevzdat jméno, příjmení, adresu apod. a ty nějak zobrazíš. Ale to už není klasický getter, to je datové rozhraní.

Ale nehledej v tom žádnou vědu, prostě jsem chtěl říct, že otázka, jestli mám nebo nemá gettery nijak neovlivňuje otázku, jestli objekt splňuje nebo nesplňuje nějaký interface typu IsHTMLPresentable.
Já bych to udělal pomocí tří rozhraní:
1. Entry -  obsahuje vlastní objekt.
2. Formater - objekt získávající Entry a výsledek bude stream/string
3. Dump - objekt zastřešující vytisknutí libovolného objektu.

Takže třeba: objekt DumpJSON nakrmím formatery, a pak když budu chtít vytisknout Psa, tak se použije PesFormaterJSON.

1874
Vývoj / Re:Funkcionální jazyky.
« kdy: 19. 08. 2015, 18:22:36 »
Jak zlo?
V tom smyslu, že když chci objekt odprezentovat v html, tak bych se ho neměl ptát na jeho properties a sám skládat prezentaci, ale měl bych ho nechat sama sebe odprezentovat. (Samozřejmě to neber doslovně, když mám třeba MVC, tak to tam bude třeba probíhat jinak, to je jasný. Každopádně nerozumím tomu, jak s tím gettery můžou souviset)

A když budu chtít, aby se mi ten objekt prezentoval v json, xml, pdf, ...?
Imho mi to s těmi gettery souvisí dost těsně, protože na to presentování budu používat nějaký jiný nástroj, kterému ten objekt předhodím. A ten bude reflexi toho objektu dělat pomocí getterů.


1875
Vývoj / Re:Funkcionální jazyky.
« kdy: 19. 08. 2015, 17:32:12 »
(ledaže by Kit chtěl říct, že používat getter je zlo a že se musí vždycky pokud to jde použít toString,toHTML,presentate - s čím snad ale nikdo nepolemizuje).
Jak zlo?

Stran: 1 ... 123 124 [125] 126 127 ... 133