Příspěvky

211

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

« kdy: 13. 11. 2019, 10:43:54 »

a nebo to dojede na to, ze on to neumel vysvetlit nebo ja pochopit a tak sme toho radsi nechali, aby sme si nekazili jinak celkem pratelsky vztah.

Ono asi těžko by ti někdo vysvětloval, proč se zamiloval do nějaké holky tak, aby ses do ní zamiloval taky

Mít vestavěný automatický "subsystém", který při setkání s +- použitelnou ženskou začne vyrábět drogy aby jeden moc nepřemýšlel a raději ji zbouchnul, je svým způsobem velmi racionální. Ale řekl bych, že listoper si představoval trochu jiný druh racionální úvahy.

212

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

« kdy: 07. 11. 2019, 11:55:24 »

P.S. "normálně" neříkáme "objekt" skoro ničemu. Možná tak ještě budově nebo souboru budov Ten náš "objekt" je celkem čistý kalk z angličtiny.

Pravda. Asi jak už občas přemýšlím napůl v angličtině, tak mi to automaticky splynulo s předmětem.

Jinak by si ale měl synchronizace řešit každý objekt sám vnitřně.

To funguje fajn do doby než chci poslat několik zpráv po sobě. Uvažovat stylem že o objektu nevím vůbec nic i když mi právě nějak odpověděl na zprávu není moc intuitivní a ani praktické.

213

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

« kdy: 07. 11. 2019, 10:57:52 »

OOP model zarovka s metodami rozsvit, zhasni je naprosto korektni model. Nechapu blaboleni, proc by jako zarovka mela sama něco delat, zarovka je pouze objektem, se kterym se manipuluje. Iniciatorem akce je objekt Osoba, která implementuje Runnable.run a zde je kod manipulujici se zarovkou.

To, že žárovka sama něco dělá, vyplývá právě z toho zasílání zprávy. Osoba té žárovce jen zašle zprávu a je na té žárovce, jak s tou zprávou naloží. A i OOP jazyky bez posílání zpráv mají virtuální metody, díky kterým volající neví, co tahle konkrétní žárovka udělá. Osoba to jen iniciuje, ale nerozhoduje o tom, co se má stát.

To je právě zásadní rozdíl mezi objekty z OOP a z reálného světa. Drtivá většina toho, čemu normálně říkáme "objekt" rozumí akorát zprávě "zůstaň".

214

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

« kdy: 06. 11. 2019, 10:51:47 »

V podstatě to není zas tak těžký úkol ...

Mě to teda zní zatraceně komplikovaně. A ten zárodek je už v tom, že se tam ta funkcionalita přidává postupně a specifikace se mění pod rukama. Tohle se dříve či později bude muset překopat bez ohledu na paradigma.

Jiným příkladem může být například rozsáhlý systém, který staví model pro Marketing, Sales, Ordering a Support. Všechny tyto oddělení pracují se zákazníkem, ale není žádané, aby tato třída byla v systému pouze jednou, protože bude obsahovat příliš odlišnou funkcionalitu, bude mít příliš závislostí, bude mít tendenci růst apod.

Tady by mi osobně seděla varianta Entity-Component systému. Zákazník by měl v základu jen minimum dat a každé oddělení by si na něj mohlo přidávat komponenty s dodatečnými daty podle potřeby. Každé oddělení musí rozumět jen pár komponentám a zbytek neřeší. A o funkcionalitu se starají právě ta oddělení. Zákazník a jeho komponenty jsou jenom balíky dat.
ECS je oblíbený hlavně v gamedev světě. Není to klasické OOP, spíš to připomíná relační databáze. Ale je to zatraceně mocný a flexibilní přístup.

215

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

« kdy: 06. 11. 2019, 10:08:34 »

Ale tak to zase není limitováno na OOP, a setkáte se s tím i při programování např. v čistém C.  Naopak v C++ to mnohdy může být jednodušší kvůli věcem jako shared_ptr, které dělá reference counting za vás.  (Ale nejsem C++ programátor, tak netuším, jestli v tom není nějaká zrada...)

shared_ptr ve více vláknech není úplně intuitivní pro někoho, kdo neví do detailů jak to uvnitř funguje. Z nějakého důvodu dost lidí předpokládá, že je ten ukazatel atomický a pak se škaredě spálí. Vlákna jsou holt zlo.

216

O serveru Root.cz / Re:Pravidla diskuze #3

« kdy: 05. 11. 2019, 09:40:13 »

Nežereš maso, nepoznáš vtip!

217

Windows a jiné systémy / Re:Apache Tomcat: vyčerpání TCP spojení

« kdy: 18. 10. 2019, 13:07:32 »

Něco podobného jsem už viděl. Jestli nějakou z těch appek psali Izraelci, tak bych se koukal primárně tam.

218

Vývoj / Re:Uváznutí v Aktor systému

« kdy: 18. 10. 2019, 09:18:27 »

Jediné, co zatím víme, je že se to nebude testovat, páč to je kargokult.

Tímto přístupem se na to možná rovnou vykašli, ne?

To byla narážka na tvůj příspěvek :

Jen jsem se chtěl vyhnout uváznutí v cargo-cultu.

Jo a

Aktory jako služby, poskytující data i poskytující výpočty. Aktor jako klient se bude dotazovat jiných aktorů. Libovolný aktor může poslat dotaz libovolnému jinému. Zpráva vede přes prostředníka, který schraňuje zprávy, a pak je předává adresátům. Aktor dostane zprávu, podle ní vykoná svou úlohu - sám, nebo deleguje na jiného. Prostředník pošle zpět zprávu: zpráva uložena, zpráva vyzvednuta.

Zprávy coby komunikační protokol mám zatím bez pravidel. V dalším kroku bych rád nějaký formální jazyk typu KQML.

Tedy jak vidno, není to nic světoborného. Taky tam v tom zadání nejsou žádná zvláštní omezení. Jakékoliv postřehy vítám.

Pointa je, že jsem teda napsal první prototyp, a hned jsem si ho zacyklil. Tedy nejde mi o to, že by to muselo být vysloveně neprůstřelné jen by to snad nemuselo být tak snadné to rozbít.

není zadání. Tohle je teoretický popis úplně obecného actor systému. Pokud ty actory můžou dělat a posílat cokoliv, tak nemáš co hlídat. Jakékoliv chování může být správně.

219

Vývoj / Re:Uváznutí v Aktor systému

« kdy: 17. 10. 2019, 22:35:40 »

Naopak. Jsem v okamžiku návrhu. Všechnu je zelené a krásné. Ale ty aktory může (bude moct) napsat kdokoliv.

Hmm, a máš k tomu nějaké zadání? Třeba bychom se nad tím návrhem, vzory co omezí uváznutí atp. mohli zamyslet kolektivně..

Tak nějak. Zatím víme akorát to, že nějací nám neznámí programátoři budou psát nějaké blíže nespecifikované agenty. A ti agenti si budou mezi sebou posílat nějaká nám neznámá data. Jediné, co zatím víme, je že se to nebude testovat, páč to je kargokult.

Kdo ty agenty bude psát? Programátoři, poloprogramátoři, nebo cvičené opice? A v čem?
Co ti agenti budou dělat? Jaká konkrétní data si mezi sebou budou posílat?
Co ten komunikační protokol musí umět? Má být synchronní nebo asynchronní? Posílají si agenti zprávy přímo, nebo dávají obecné požadavky? Co latence a propustnost? Nestačí na to něco odladěného typu ZeroMQ?

220

Vývoj / Re:Uváznutí v Aktor systému

« kdy: 17. 10. 2019, 17:40:54 »

Ale taky se to začíná blížít unit testům, které tu už pár lidí doporučovalo.

Ty unittesty byla evidentně rada z nepochopení. Tu jsem vyškrtl.

Možná by stálo za to rozepsat důvody, proč tady unittesty nepomůžou. Mohlo by to tu diskuzi trochu posunout.

Osobně nevidím nějaký zásadní rozdíl mezi specializovaným hlídačem nějakého protokolu (musí být specializovaný, protože obecně tam může lítat opravdu cokoliv) a specializovaným testem nějakého rozhraní. Oboje kontroluje, jestli ta komunikace odpovídá nějaké předloze, jen to kontrolují jindy.

Nebo jsou ty aktory nějaké zprasené produkty třetí strany bez podpory, zdrojáků a naděje?

221

Vývoj / Re:Uváznutí v Aktor systému

« kdy: 17. 10. 2019, 09:49:40 »

Tak možná by šlo, v případě deterministické funkce tu chybu odvodit podle toho vzoru víše. U nedeterministické funkce jsem samozřejmě v háji.

Determinismus toho moc neřeší. Ty actory můžou mít celkem složitý vnitřní stav. I pseudonáhodné generátory jsou deterministické a vzory se tam hledají dost blbě.

Periodicky se opakující vzor může být naprosto korektní chování. Představ si třeba komunikaci s nějakým senzorem.

Také jsem uvažoval, že bych to prostě jen výce vyhranil, aby to nebylo snadné, udělat cyklus. Třeba potvrzenka k tomu svádí. Takže udělat speciální typ zprávy, na kterou se neodpovídá.

Jo, pokud bude hlídač vědět, co tam má lítat, tak už se dá hlídat víc. Ale taky se to začíná blížít unit testům, které tu už pár lidí doporučovalo.

222

Vývoj / Re:Naučení se asynchronnímu programování

« kdy: 10. 10. 2019, 09:57:30 »

No a ja rikam, abyste neprogramovali asynchronne, protoze je to na 3.14cu, protoze to nema dobrou ergonomii

Coz mi pripomina, jak asi vypada stacktrace v pripade Coroutin s await async. Zda-li je zmrsena, nebo zda-li vypada stejne jako kdybych asynchronni cast kodu provedl v samostatnem vlakne, tedy ze ta odvetvena cast kodu ma svou vlastni peknou stacktrace.

Takže ty víš, že je to na pendrek a neergonomické a přitom ani nevíš jak vypadá stacktrace?

223

Vývoj / Re:Naučení se asynchronnímu programování

« kdy: 08. 10. 2019, 16:02:43 »

A to je v kontextu Javy a asynchronního programování důležité proč? Je to pojem z matematické teorie kategorií, který pro běžného programátora není naprosto důležitý. Kdejaká operace splňuje definici grupy nebo monoidu, ale použivá se to tak akorát při formálních důkazech a analýzách algoritmů.
...

Vy jste se ptal "Co mají Streamy s monádami?"

Běžný programátor to možná _nazývá_ jinak, ale _používá_ to naprosto běžně. Jestli je nějaká operace asociativní je důležité, pokud chci dělat třeba paralelní redukci. Jednotkový prvek mi zjednoduší api a počáteční podmínky. A ejhle, používám monoidy a to jsem k žádnému důkazu ani nečichl.

Máte nějaký problém s tím, že tyhle všudypřítomné struktury budeme nazývat stejně jako v matice?

224

Vývoj / Re:Naučení se asynchronnímu programování

« kdy: 08. 10. 2019, 12:16:07 »

Ja se treba priznam, ze casto i dost vaham nad uzitecnosti Streamu (monady). Mnohokrat mi prijde pouziti Foreahe mnohem praktictejsi a prehlednejsi. Dodnes z pameti nevim, jak ve Streamu napr. udelat Group By nad Mapou a musim cumet do Googlu.

Co mají Streamy s monádami? Prostě normální funkce vyššího řádu.

Nic moc, krom toho že streamy jsou monády. Akorát "bind" je přejmenovaný na "flatMap".

225

Studium a uplatnění / Re:Studium na VŠ po 40

« kdy: 03. 10. 2019, 16:39:20 »

V 40tke riesit VS? Zivot sa da pokazit aj krajsim sposobom, napriklad chlast, prostitutky .. 

V 40tke by si uz mal byt zabezpeceny z kazdej strany, venovat sa konickom, rodine, dovolenkam a uzival si kludnu jesen zivota..

Tos trosku prestrelil s tim podzimem, ted zrovna Katerina Nash ve 42 vyhrala svetak v cyklokrosu. Zkus ji rict, ze si uziva jesen zivota :-))

To že je někdo silnej neznamená, že mu to myslí.

Nemyslím, že to mělo být o chytrosti. Spíš že ve čtyřiceti ještě zdaleka není podzim života.