Příspěvky

361

/dev/null / Re:Těžké OOP problémy

« kdy: 12. 11. 2019, 10:51:28 »

Myslel jsem si, že tu budeme propírat OOP. Místo toho se tu hádají stoupenci FP o slovíčka. Nechcete si to vyříkat ve vlastním vlákně?

Kite, abys nebyl naštvanej, že tady plevelíme vlákno o OOP... My tady totiž právě OOP probíráme!

Množina predikátů, to je totiž třída. Ty predikáty říkají, jestli daný objekt odpovídá na danou zprávu. Nebo jinak: průnik predikátům příslušných množin individuí je množina objektů dané třídy.

Dědění je přidávání predikátů do množiny. Vícenásobná dědičnost je sjednocení množin predikátů.

Ale jo, beru to a naštvaný nejsem. Jen z těch diskuzí mám OOP stále raději, že se nemusím dohadovat o formální kraviny. Místo toho mám návrhové vzory, u kterých je toho dohadování mnohem méně.

Naštěstí si vždy poradím i bez vícenásobné dědičnosti, protože ji používám jen tam, kde má skutečně smysl. Pokud bych měl mít někde protected atribut, je to pro mne jasným signálem, že tady dědičnost být nemá.

362

/dev/null / Re:Těžké OOP problémy

« kdy: 11. 11. 2019, 22:54:04 »

Mutabilita dělá Lisp Lispem. Nedělá rozdíl mezi programem a daty. Není mnoho jazyků, které se mohou pochlubit tím, že umí samy sebe modifikovat za plného provozu.

Nevim, ktery dialekt lispu pouzivas, ale tohle mi prijde minimalne zavadejici. Aspon v clojure je podle me expanze makra jen transformace jednoho immutable listu na novy immutable list.

Používám Common Lisp, který nejlépe vyhovuje mým potřebám. Clojure se u mne dlouho neohřál, některé vlastnosti mi v něm chyběly.

363

/dev/null / Re:Těžké OOP problémy

« kdy: 11. 11. 2019, 20:53:52 »

Ne, myslím to, že predikát je většinou brán jako funkce, která vrací True/False.

Jo, to tu občas psáváš, ale pak místo uvědomění si chyby začneš plodit nějaké relativistické argumenty stylu predikát == vlastnost a tudíž je ok říct vlastnost je množina vlastností == predikát je množina predikátů. Člověk pak neví, jak vážně to má brát...

Nemůžeme za to, že za predikáty považuješ pouze jejich podmnožinu.

364

/dev/null / Re:Těžké OOP problémy

« kdy: 11. 11. 2019, 20:39:33 »

Nebo co musim odebrat z clojure, aby se stal ciste funkcionalnim?

Side effecty. Mutabilní data, která se dají sdílet, má Clojure myslím taky, ne? (Nevím, celému lispovskému světu se záměrně dost vyhýbám, nesedí mi to)

Mutabilita dělá Lisp Lispem. Nedělá rozdíl mezi programem a daty. Není mnoho jazyků, které se mohou pochlubit tím, že umí samy sebe modifikovat za plného provozu.

365

/dev/null / Re:Těžké OOP problémy

« kdy: 11. 11. 2019, 16:34:11 »

Jen jsem chtěl upozornit na to, že pokud se stoupenci FP budou hádat o slovíčka, budeme z toho mít my ostatní tak akorát srandu.

366

/dev/null / Re:Těžké OOP problémy

« kdy: 11. 11. 2019, 16:20:45 »

Myslel jsem si, že tu budeme propírat OOP. Místo toho se tu hádají stoupenci FP o slovíčka. Nechcete si to vyříkat ve vlastním vlákně?

367

Vývoj / Re:Problem s prekladom PHP

« kdy: 11. 11. 2019, 13:29:51 »

Docela mi pomohlo, když jsem hned za řádek global dal tohle:

Kód: [Vybrat]

$flowId = $settings['readable_fields'][$approvalFlowId][$fieldName] ?? null;

a provedl substituci na ostatních místech.

Teď už vidím, že refaktoring bude hračka.

368

Vývoj / Re:Problem s prekladom PHP

« kdy: 11. 11. 2019, 12:18:41 »

Evidentně jsou v parametrech $approvalFlowId a $fieldName takové hodnoty, pro které nejsou definovány odpovídající hodnoty v $settings.

Je snad jasné, že tento kousek kódu je odporným hnusem. Dá se to však napravit.

369

/dev/null / Re:Těžké OOP problémy

« kdy: 10. 11. 2019, 22:00:53 »

A teď hejt FP

FP nemám potřebu hejtit. Možná proto, že ho moc neznám a používám z něj víceméně jen konstrukce map filter a reduce, které považuji za velmi užitečné.

Jestli si vzpominam dobre z jinych vlaken tak si fanouskem LISPu ne?

Ano, stále jsem fanouškem Lispu. Ten je však multiparadigmatický a na většinu prací ho nemohu použít, protože nemám nikoho, kdo by mi dělal code review. Používám ho i jako lepší kalkulačku, protože je vždy poruce a je svižnější, než třeba Excel. V čem jiném bych měl psát AI, než v Lispu?

Ze zdejších konverzací však mám pocit, jako kdyby Haskell byl jediným správným funkcionálním jazykem. Zkusil jsem ho, nesedl mi. To ale neznamená, že bych FP neuznával. V PHP kombinuji funkcionální komponenty s objektovými a funguje to skvěle. Pokud něco potřebuji deklarativně, napíši k tomu kus XSLT. Pokud potřebuji transakci v DB, napíši uloženou proceduru.

Kdykoli chtěl někdo něco dělat čistě v jednom paradigmatu, vznikla z toho jen hromada rovnáků na ohejbáky.

370

/dev/null / Re:Těžké OOP problémy

« kdy: 10. 11. 2019, 20:30:12 »

A teď hejt FP

FP nemám potřebu hejtit. Možná proto, že ho moc neznám a používám z něj víceméně jen konstrukce map filter a reduce, které považuji za velmi užitečné.

371

/dev/null / Re:Těžké OOP problémy

« kdy: 10. 11. 2019, 15:05:07 »

a můžeme se vrátit třeba k hejtování OOP.

Challenge accepted!

To není hejtování, ale běžný standard.

372

/dev/null / Re:Těžké OOP problémy

« kdy: 08. 11. 2019, 12:00:34 »

Abstrakce je užitečná, jen pokud zobecňuje několik konkrétních případadů a zkrátí kód. Overengineering je psaní abstrakcí, které použijete jen jednou. Mluvím o psaní vlastních abstrakcí, ne o používání knihoven.

Občas napíši abstrakci i tam, kde ji použiji jen jednou. Vlastně to dělám stále. Jen je třeba vědět, kterou abstrakci v daném místě použít.

373

/dev/null / Re:Těžké OOP problémy

« kdy: 08. 11. 2019, 10:25:46 »

Monoid v kategorii endofunktorů je ultraužitečná abstrakce, ale kolik wannabe vývojářů ví, která bije? Přesně o tomto je myslím Go, které kašle na fancy abstrakce, Pike ho navrhnul - dle vlastních slov - pro absolventy bez zkušeností.

Jenže kolik vývojářů ví, co je monoid a co endofunktor? To znají jen ti, kteří studovali teorii kategorií a těch není mnoho.

374

/dev/null / Re:Těžké OOP problémy

« kdy: 07. 11. 2019, 13:33:26 »

Tak jsem si to zkusil predstavit a vysledek je furt stejny.
Zarovka je furt tupa sklenena banka, ktera sviti, kdyz v tece proud.
A je uplne jedno jestli je spoustena vypinacem na stene, elektronikou projektoru.

Ano, sitovym vypinacem, muzu ovladat PC, klidne treba i vetrak, s faktem, co je to objekt Zarovka, to nema spojecneho lautr nic.

S takhle omezenou představivostí se OOP dělá docela blbě. Možná ti lépe vyhovuje FP.

375

/dev/null / Re:Těžké OOP problémy

« kdy: 07. 11. 2019, 13:30:00 »

... napriklad, ze atribut User v session na webu neni modelem cloveka, ale ze je to model listku do pichacky daneho  cloveka na vratnici. Pak ho nenapadaj peachoviny jako User.zabookijSiObedVKantyne(), protoze kartotecni listky tohle obvykle nedelaji. A ze tam parti User.prichod(cas), user.odchod(cas) apod.
Nebo ze je logicke mit Lopata.naberUhli() a ne Uhli.naskakejNaLopatu().

Je zajimave, co jsou schopni lidi vymyslet za selmostroje a zakonity fail svedou na paradigma.

Kdo má tedy kompetenci zabookování obědu v kantýně? User si vybere jídlo z Menu a pošle požadavek do Canteen.

Také bych raději použil User.add(new Prichod) a User.add(new Odchod). Případně Lopata.naber(new Uhli).