Příspěvky

3886

Vývoj / Re:Funkcionální jazyky.

« kdy: 19. 08. 2015, 21:50:31 »

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

Jé, no to bylo svého času úplný programátorský porno Ale obsah už si dneska nepamatuju, natož tuhle konkrétní zápletku. Budu si to asi muset někdy ve vaně pro pobavení znovu přečíst Akorát nevím, jak moc to ještě odpovídá dnešní situaci, minimálně Java asi od té doby nějaký vývoj prodělala...

(a nepřímo vyplynula poučka, že dědičnost mnohdy přináší víc škody než užitku )

Jj, to je jeden ze závěrů, které jsem si sám pro sebe taky udělal, jedna z těch ne-přirozeností je ta hierarchie. Přirozeně asi spíš přemýšlíme tak, že obecné pojmy sdružují jednotlivosti s nějakými společnými znaky, ale ne nutně ve formě hierarchie. Mj. proto mi začaly být daleko sympatičtejší jazyky založený na volně kombinovatelných rozhraních, založených jenom na společných vlastnostech a ničem jiném. Odpadá tím spousta z těch klasických neplodných nekonečných OOP sporů o ničem...

3887

Vývoj / Re:Funkcionální jazyky.

« kdy: 19. 08. 2015, 21:07:04 »

může, není, do teologie se (dneska večer) nepouštím

No právěže v Erlangu je definované naprosto přesně. Včetně toho, jak se to chová v konkurentním prostředí, jak se zprávy řadí, jak je možné je vybírat atd.atd. Proto na posílání zpráv není nic špatného, akorát musí být prostě implementované dobře.

Nešlo by to řešit tak, že by se formatter do funkce předal společně s objektem X (to může udělat i kompilátor automaticky - v Haskellu se k tomu používají typové třídy, ve Scale implicity, v Rustu traity)?

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. Haskell bych do toho netahal, já se vymezuju proti konkrétnímu řešení v konkrétním "mainstreamovém OOP".

3888

Vývoj / Re:Funkcionální jazyky.

« kdy: 19. 08. 2015, 21:01:36 »

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

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.

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

3889

Vývoj / Re:Funkcionální jazyky.

« kdy: 19. 08. 2015, 20:49:37 »

naproti tomu oop - "posílání zpráv objektů" - co to vlastně je? jistě víme jenom že konsensus neexistuje, patterrny... stav rozházený všude možně.. a tak

A tak to zas neee! Posílání zpráv je (může být) naprosto jasně definované a pokud skutečně funguje tak, jak se tváří, že funguje, je to ok (Erlang, Elixir). Problém dnešního OOP je mj. v tom, že vychází z logiky posílání zpráv a přitom žádné neposílá, jenom to neuměle kašíruje.

3890

Vývoj / Re:Funkcionální jazyky.

« kdy: 19. 08. 2015, 20:40:48 »

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í?!

Ve finále mi přijde daleko přirozenější a přímočařejší uvažování funkcionální, kde je analogie výrobní linka: X jde dovnitř, Y jde ven. Toť vše

3891

Vývoj / Re:Funkcionální jazyky.

« kdy: 19. 08. 2015, 20:36:28 »

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

3892

Vývoj / Re:Funkcionální jazyky.

« kdy: 19. 08. 2015, 20:26:50 »

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

3893

Vývoj / Re:Funkcionální jazyky.

« kdy: 19. 08. 2015, 20:17:20 »

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

3894

Vývoj / Re:Funkcionální jazyky.

« kdy: 19. 08. 2015, 19:18:20 »

Říkám, nejsem žádný odborník na OOP, ber to tak pls.

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.

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.

3895

Vývoj / Re:programovaci jazyk budoucnosti

« kdy: 19. 08. 2015, 17:50:02 »

Berme to jako výzvu k úvaze, zda dnešní vysokoúrovňovost jazyků by se nedala ještě posunout. A samozřejmě jak.

Otázka je, co je "dnešní úroveň". AFAIK jsou nějaké pokusy o automatické generování kódu z UML apod. To už je dost vysoká úroveň

3896

Vývoj / Re:programovaci jazyk budoucnosti

« kdy: 19. 08. 2015, 17:48:38 »

nejde mi to tak mne jen napadlo jestli by slo vymyslet nejaky metaprogramovaci jazyk treba nad pythonem ktery by byl jednodussi pro hlupaky jako jsem ktery by opravoval nejen tu jednodussi syntaxi v tomto jazyce predstavuju si ze by se pouzivalo neco jako orezana simple english

Není to úplně od věci, jak psali kolegové výš - AppleScript je výborný příklad, chtěl jsem ho taky napsat. Ale obecně bych to nepřeceňoval - když uděláš jazyk superpoužitelný pro jednu doménu, bude otravné ho použít jinde (pokud to vůbec půjde). Pokud chceš jazyk omezený na nějaké konkrétní použití, tak to jde. Třeba teď jsem vymyslel jazyk OnOff, který slouží k ovládání žárovky - když ji chceš zapnout, napíšeš On, když vypnout, napíšeš Off Přímočaré, efektivní, pochopitelné. Dokud někoho nenapadne jazyk OnOff rozšířit tak, aby v něm mohl napsat browser, to pak dopadne špatně Takže máš pravdu v tom, že pokud ti programování v "normálním" jazyce nejde, mohlo by ti jít nějaké jednodušší programování přesně jenom pro tu doménu, kterou chceš řešit. Ovšem to by ti někdo musel takový jazyk vymyslet, pokud možno přímo pro tebe

Obecnější poznámka, kterou si prosím neber osobně: čtu "nešlo mi to...tak jsem vymyslel, že je problém v jazyce". Myslím, že ne. Problém je v tobě - nevěnoval jsi dostatek úsilí tomu, aby ti to šlo. Třeba ten zmíněný Python je tak přístupný, že podle mě člověk s průměrným nebo i lehce podprůměrným IQ musí být schopný v něm něco napsat. Možná bude muset věnovat delší čas studiu a tréningu, ale nakonec to (na nějaké úrovni) dá. Zkus popřemýšlet spíš tímhle směrem - jestli jsi ochotný do toho dát trochu víc úsilí, jestli ti to za to stojí a jestli nemáš po ruce někoho, kdo by ti s tím pomohl. Myslím, že to je plodnější směr úvahy než o tom "metajazyce"

3897

Vývoj / Re:Funkcionální jazyky.

« kdy: 19. 08. 2015, 17:36:30 »

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)

3898

Vývoj / Re:Funkcionální jazyky.

« kdy: 19. 08. 2015, 17:28:58 »

gettery a settery nějak zabraňují těmto třídám sdílet rozhraní Presentable a mít metodu presentate() ?

Přesně tohle právě nechápu. Stejně jako mám společný toString, tak můžu mít společný toHTML a gettery s tím nemají vůbec nic společného (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).

3899

Vývoj / Re:Funkcionální jazyky.

« kdy: 19. 08. 2015, 15:22:59 »

Problémem getterů a setterů je, že nejsou polymorfní. Pokud budu mít ve třídě Article metodu setTitle(), tak taková metoda se mi vůbec nehodí ve třídě Person či Store. Nemohu tedy použít stejné rozhraní.

Možná je to tím, že se OOP už delší dobu vyhýbám, ale tohle jsem teda vůbec nepochopil. Atricle, Person a Store by měli mít nějaké společné rozhraní? Jaké? Co mají společného? A jak ve vytvoření takového rozhraní vadí gettery/settery? Ne že bych to téma chtěl přiživovat, ale tohle konkrétně by mě zajímalo.

3900

Vývoj / Re:Funkcionální jazyky.

« kdy: 19. 08. 2015, 09:12:59 »

C# light je příznačné myšlení Hurvínků neprogramátorů co se ještě v životě nesetkali s reálným větším projektem a proto mají zdání že je toho v C# zbytečně mnoho. Připadá mi to jako když plavčík co byl nejdál v Tróji v ZOO vymýšlí plavidlo na cestu do Yokohamy.

Sám seš Hurvínek. Podívej se na autora těch slajdů a pak třeba na autora http://fsharpforfunandprofit.com/ ty Hurvínku...