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

Stran: 1 2 [3] 4
31
Vývoj / Re:Dědičnost dnes
« kdy: 02. 02. 2017, 23:00:45 »
A pokud jde o ten odkazovaný článek, tak je to opravdu tak napůl esoterická záležitost, protože se snaží nás přesvědčit, že chceme-li posuzovat časovou složitost co nejobecněji, tak musíme předpokládat sice konečná, ale libovolně rozsáhlá data, na nichž ukazuje, že je obecně nelze obsloužit v konstantním čase z ryze fyzikálních důvodů (jen jsem čekal, kdy tam začne vytahovat holografický princip z teorie strun).
To je sice roztomilé, ale jen jako taková kratochvilná teoretická onanie. Protože v praxi při porovnávání algoritmů předpokládám nikoliv "sice konečné, avšak libovolně rozsáhlé" paměti, ale jeden a ten samý konkrétní stroj.

Ono se ukazuje, že navrhovat algoritmy, počítat jejich složitost a vzájemně porovnávat jejich efektivitu je paradoxně jednodušší, když předpokládáme sice konečná, ale libovolně velká data. Dělá se to tak desítky let a i když o tom možná nevíte, výsledky takových teoretických úvah denně používáte. A ten odkazovaný článek vlastně není nic překvapivého ani esoterického, je to spíš téměř triviální pozorování.

Takže pokud by mi podobný rozumbrada začal opravovat mé odhady řka, že přístup k paměti má přece složitost O(√n), pousmál bych se, poplácal bych ho po tvářičce a popřáv mu mnoho radosti při onaniích nad řešením otázek, kolik andělů se vejde na povrch horizontu událostí černé díry, bych ho kopnul do...

Hodně vtipné. Zvlášť když si uvědomíte, že při taktovacích frekvencích v řádu GHz a omezení rychlostí světla se omezení rychlosti přístupu k paměti (nebo obecně latence libovolné komunikace) začnou projevovat na vzdálenostech několika centimetrů.

32
Vývoj / Re:Dědičnost dnes
« kdy: 02. 02. 2017, 22:45:34 »
Proto nema smysl nad takovou mnozinou algoritmu a vstupu uvazovat o stroji, ktery pristupuje k pameti v O(1) pro libovolne N - takovy stroj je jen teoreticky konstrukt.

Navíc i v teorii má takový stroj některé velmi nepěkné vlastnosti, např. na něm některé algoritmy vychází exponenciálně rychlejší, než bychom chtěli. Proto se v teorii složitosti různě omezuje, např. maximální velikostí slova nebo právě logaritmickou cenou přístupu do paměti.

33
Vývoj / Re:Dědičnost dnes
« kdy: 02. 02. 2017, 22:40:02 »
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ů.

Jestli to nebude "krásně jasné", protože to je "správný" příklad. OOP opravdu krásně funguje na diskrétní simulace a grafické objekty (nebo ještě lépe na GUI). Protože tam objekty existují samy za sebe a nesnaží se reprezentovat nějaké entity "reálného světa". Připadá mi to mnohem rozumnější, než použití OOP spojená s nekonečnými filozofickými debatami, jestli je reprezentace zvolená "dobře". Zvlášť když se často takto reprezentují pasivní data a OOP je uměle svazuje s operacemi (metodami). Pak se ještě prohlásí za špatnou vícenásobná dědičnost a je možné se začít hádat, jestli třída C má dědit z A nebo z B, když přirozené by bylo, aby dědila z obou. Celá nesmyslná debata se vyostří hádkou, jestli je lepší statické nebo dynamické typování, Java nebo Smalltalk, a co z toho je "původní", nebo "pravověrné" OOP. Uvědomme si, že programování zahrnuje řešení různorodých problémů, pro které se hodí různé nástroje a také různá hodnotící kritéria. Jeden malý příklad - nedávno jsem narazil na dva texty. Jeden vychvaloval efektivitu alternativního GC pro Javu, kterému stačí i cca 50 % výkonu CPU. Druhý byl návrh na předělání iterátorů a algoritmů ve standardní knihovně C++, čímž by se ve specifických situacích ušetřila v přeloženém kódu jedna instrukce podmíněného skoku.

34
Vývoj / Re:Dědičnost dnes
« kdy: 19. 01. 2017, 09:56:12 »
Řeč byla o tom, co to je "původní OOP". Pojem OOP použil poprvé Alan Kay, a to v souvislosti se Smalltalkem. Byl jsi to ty, kdo tu začal slovíčkařit o tom, co to je "původní OOP". Řekl bych, že my ostatní tak nějak chápeme, že OOP zahrnuje více konceptů (sám jsem to tu už zmínil). A proto odkazuje-li někdo na ten smalltalkovský, tak obrat "původní OOP" je tedy zcela na místě a srozumitelný.

Na tom, že OOP zahrnuje více konceptů, se shodneme. Jeden z těch konceptů je implementován v jazyce Smalltalk, jiný v C++ a Javě. Ten druhý pochází ze Simuly, která vznikla před Smalltalkem. Já jsem výraz "původní OOP" pochopil jako "první v čase", nikoliv "co bylo jako OOP poprvé nazvané". Přijde mi, že možné jsou v češtině oba významy. Stačí vyjasnit si nedorozumění a věcně odpovědět na otázku...

35
Vývoj / Re:Dědičnost dnes
« kdy: 18. 01. 2017, 18:31:50 »
Jenže pojem OOP v době Simuly neexistoval. Ten zavedl až Alan Kay v souvislosti se Smalltalkem.

To, že se zavede nějaký pojem, ještě neznamená, že pod něj nelze zahrnout něco, co existovalo už předtím. Už proto, že Alan Kay nestavěl na zelené louce. Ano, můžeme OOP chápat omezeně tak, jak funguje ve Smalltalku. Alternativně můžeme pod OOP zahrnout i využití stejných nebo podobných principů v jiných jazycích trochu jiným způsobem. Myslím, že programování není o dogmatickém dodržování nějakých oblíbených naučených teoretických principů, ale o pragmatickém hledání fungujícího řešení (kde pod pojem "fungující" zahrnuji podle okolností i srozumitelnost, rozšiřitelnost, dodržení smysluplných konvencí, aj.).

36
Vývoj / Re:Dědičnost dnes
« kdy: 18. 01. 2017, 18:19:31 »
Odkdy je čtverec (či obdélník)  prostorový útvar??!!! Zpátky na základku! (Proč mluvíte o obsahu?? Proč o dvou nezávislých proměnných?? Mimochodem to, že velikost strany a je stejná jako velikost strany b neznamená, že jsou to nějaké závislé proměnné. Tohle jsou základy matematiky, to by měl každý programátor znát!)

Vhodná definice pojmu (resp. třídy) čtverec se může v závislosti na kontextu dost lišit. Dovedu si představit problémy, pro které se hodí snad všechny varianty třídy Čtverec a jejích vztahů k třídě Obdélník, které zde byly zmíněny. A pokud bude Čtverec součástí množiny tříd pro reprezentaci 3D scény, může být chápán jako prostorový útvar odvozený z Kružnice (která je odvozená z třídy Bod). Zároveň může být Čtverec bázovou třídou pro obdélník i krychli.

Čtverec je speciální případ obdélníku, který má shodou okolností všechny strany stejně dlouhé. Tečka. Tohle se učí na ZŠ...

...a teprve v matematických předmětech na vysoké škole se člověk dozví, že ty "pravdy" ze ZŠ jsou většinou zjednodušení platná jen za specifických podmínek.

37
Vývoj / Re:Dědičnost dnes
« kdy: 18. 01. 2017, 18:01:09 »
To původní bylo vlastně velmi jednoduché, jen zprávy mezi objekty, bez ohledu na dědičnost. Celá ta současná diskuse o Javě apod. je pak dost zcestná a není ani tak o OOP, jako o omezeních imperetivních jazyků, na které byly naroubovány objekty a virtuální volání.

Ano, virtuální volání, to je z mého pohledu největší rozpor mezi původním OOP (pozdní vazba s přenesením odpovědnosti na cílový objekt) a dnešní implementací (časná vazba s rozhodováním zdrojového objektu řešená typovou kontrolou).

Co to je "původní OOP"? Něco ještě před Simulou? Protože pojetí tříd, objektů, dědičnosti a virtuálních funkcí v jazyce Simula 67 je blíž dnešním jazykům jako C++ nebo Java, než Smalltalku, který vznikl až po Simule.

38
Vývoj / Re:Dědičnost dnes
« kdy: 16. 01. 2017, 20:55:39 »
Připadá mi, že v této diskusi se míchá dědičnost jako koncept používaný při modelování reality v softwaru a dědičnost jako nástroj programovacího jazyka. A většina argumentace se implicitně točí kolem informačních systémů. Jenže OOP se používá i jinde. Např. GUI toolkity používají OOP již desítky let - namátkou Turbo Vision, Object Windows, GTK+, Qt. Dokonce k tomu nepotřebují ani OO jazyk (GTK+). V těchto aplikacích má použití dědičnosti s hlubokou polymorfní hierarchií hodně dobrý smysl. Naopak mi není moc jasné, proč se data v informačním systému snažit modelovat pomocí objektů a následně se hádat o různé aspekty OOP, když by lépe posloužil relační databázový model. Zvlášť, když data jsou už často v relační databázi uložena.

39
Vývoj / Re:Komerčné projekty v golang?
« kdy: 04. 06. 2016, 23:29:43 »
Trochu odbočím - zajímalo by mě, jestli je někde jednoduše vysvětlené, jak jsou všechny tyhle objektové a funkcionální vychytávky Swiftu implementované?
Je to v oficiální dokumentaci a kód je open source.

Můžete být trochu konkrétnější? Kde konkrétně najdu popis, jak jsou objekty uložené v paměti, co se děje při vytvoření/rušení objektu, jak se řeší volání metod, generické typy, protokoly, atd.? Studovat kód se mi fakt, nechce, to se radši bez těchto znalostí obejdu.

40
Vývoj / Re:Komerčné projekty v golang?
« kdy: 04. 06. 2016, 22:47:12 »
Šablonové metaprogramování je na dvě věci. Mnohem užitečnější by byla variance typů nebo extenzivní protokoly.

Možná byste měl tento názor prezentovat autorům standardní knihovny C++ nebo takových chuťovek, jako je boost::msm  :) Trochu odbočím - zajímalo by mě, jestli je někde jednoduše vysvětlené, jak jsou všechny tyhle objektové a funkcionální vychytávky Swiftu implementované?

41
Vývoj / Re:Komerčné projekty v golang?
« kdy: 04. 06. 2016, 22:37:37 »
Například nemá varianci typů nebo pattern matching. Taky nemá možnost omezovat generické parametry podle protokolů. O správě paměti se ani nezmiňuju - bez chytrých ukazatelů ani ránu. Reflexe je taky z těchto jazyků nejomezenější (to ovšem neberu jako nevýhodu, ale když už byla zmíněna...).

Variance typů v C++ je docela zamotaný problém kvůli obecnosti mechanismu šablon, kdy se mohou specializace tmplt<B> a tmplt<D> zásadně lišit, i když D je třída odvozená z B. Uznávám, že pattern matching je šikovný syntaktický cukr, ale asi bych ho nepovažoval za zásadní argument pro volbu jazyka. Ohledně správy paměti: v C++ si můžu vybrat z různých mechanismů nebo si implementovat vlastní. Swift mi pro třídy nutí alokaci na haldě a reference counting.

42
Vývoj / Re:Komerčné projekty v golang?
« kdy: 04. 06. 2016, 21:35:01 »
V Go můžete třídě implentovat rozhraní bez toho, abyste měnil její definici nebo vytvářel odvozenou třídu. https://medium.com/@matryer/golang-advent-calendar-day-one-duck-typing-a513aaed544d#.18cse2sme

V C++ obdobně fungují šablony, koncepty a popř. specializace šablon.

43
Vývoj / Re:Komerčné projekty v golang?
« kdy: 04. 06. 2016, 21:29:44 »
Nie ze by to malo nejake prakticke uplatnenie (zatial), ale https://www.reddit.com/r/programming/comments/4l5is8/java_generics_are_turing_complete/

Dík za odkaz, to je zajímavé a nevěděl jsem to. Ale já jsem zmínku o turingovské úplnosti myslel spíš z praktického hlediska. Tedy že v C++ lze při překladu pomocí šablon (a taky constexpr funkcí) něco netriviálního a užitečného rozhodnout nebo spočítat.

44
Vývoj / Re:Komerčné projekty v golang?
« kdy: 04. 06. 2016, 20:24:00 »
Jistě. C++ má poněkud omezený polymorfismus. Go sice také, ale úplně jinak (nemá dědičnost, jen rozhraní). Swift má rozhraní, dědičnost (trvá-li na ní někdo) i hodnotové typy, z pohledu OOP je nejflexibilnější. K tomu má ještě mnoho funkcionálních rysů. Prostě v ničem podstatném neomezuje, kdežto v C++ i Go člověk dříve či později narazí a musí začít různá omezení obcházet, což je opruz.

Asi OOP moc nerozumím... V čem je v C++ omezený polymorfismus nebo méně funkcionálních rysů, ať už obecně, nebo v porovnání se Swift? C++ má rozhraní (vícenásobnou dědičnost), dědičnost, i hodnotové typy, k tomu i trochu reflexe. Taky má lambdy, std::function, std::bind a template metaprogramming. Myslím, že turingovsky úplnému (možná jenom skoro) čistě funkcionálnímu compile-time templatovému jazyku v C++ se generické typy ve stylu Swiftu nebo Javy funkčností ani nepřibližují.

45
Vývoj / Re:Komerčné projekty v golang?
« kdy: 04. 06. 2016, 19:35:10 »
Tak C++ má taky určité problémy. Go je na něco příliš jednoduchý (zmíněná generika) a používám ho jen pro jednodušší servery, ale své výhody má. Nicméně nejlepší je z nativně překládaných jazyků Swift.

Máte na mysli nějaké konkrétní problémy C++, které by řešily Go nebo Swift? Snad každý jazyk má své výhody (a nevýhody). Ale je otázka, jestli ty výhody stojí za tu námahu se dotyčným jazykem zabývat. Tvrzení, že Swift je nejlepší, nemá bez uvedení hodnotících kritérií vůbec žádný smysl.

Stran: 1 2 [3] 4