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.
Node.js neni univerzalni, je orientovan na web.Webem to možná začalo, dneska už je to stejně univerzální platforma jako Python.
jestli je tím myšleno asyncio, tak tady je IMO python hodně pozadu, srovnejte s erlangem, haskellem a asi goCo Erlang a Haskell... Node.js už tady máme 9 (slovy: devět) let!
Az nastane cas na posilani zprav mezi objekty, python prijde s flexibilnim funkcnim resenim. Ted je na poradu dne spise asynchronni komunikace, kterou python pred casem adoptoval a ted se ladi.S tím se asi nedá nesouhlasit. Stejně jako s tím asyncio, kdy Python teď ladí něco, co jinde už deset let funguje
Zasílání zpráv je už teď (Pykka), akorát je to neúplná omezená implementace Akka, což je neúplná omezená implementace toho, co má Erlang víc než dvacet let )
Protoze kdyz scitam objekt 1 + objekt 1, tak to typicky nechci zatezovat pomalou komunikaci.To ani není nutně potřeba. Zase příklad z Elixiru: komunikace pomocí zpráv se dělá jenom mezi procesy. V rámci jednoho procesu se dělá (víceméně) standardní volání funkcí.
Bud chci vykon nebo flexibilitu, ale ani jednim nenarusim paradigma proceduralniho/oop/funkcionalniho programovani. Posilani zprav je flexibilni, ale ani volanim metod nenarusim oop. Jestli je objekt autonomni nebo ne zalezi na jeho implementaci a ne na zpusobu, jakym komunikuje.Ale jistě, pokud chceš, můžeš všechno. Ale pokud máš nějaké prostředky, tak jim design přizpůsobuješ. Pokud máš jako hlavní prostředek volání metod, tak se ti prostě nebude chtít jít třeba do té distribuovanosti (a je to racionální). Navíc tě to bude motivovat udělat rozhraní objektu určitým způsobem.
Rozdil je technicky, u posilani zprav muzu komunikovat skrze ruzna rozhrani, treba i socket a mit tak distribuovany system, za tuto flexibilitu se, jako vzdy, plati vykonemTo je pravda.
a navic je to komplikovanejsi na spravu.Ne vždycky, záleží na okolnostech.
Jaky je v tom rozdil ale pro navrh programu? Imho zadny, protoze z pohledu abstrakce je to to same. Tedy v pripade, ze se bude jednat o objekty v ramci jednoho programu. U distribuovaneho systemu me to bude nutit delat co nejvetsi objekty s co nejdelsi zivotnosti.I v rámci jednoho programu je rozdíl zásadní - buď píšu autonomní objekty, které se samy rozhodují, nebo píšu tupé recepty "když X, tak Y".
A ja nevidim zadnou vyhodu v tom, aby se mi do ServletDispatcheru sypal neidentifikovatelny bordel a dej se vule bozi.Já taky ne. A proč to říkáš?
Smysl one otazky spociva v tom, jaky ze je rozdil mezi synchronni zpravou a zavolanim metody.No já myslím, že jsem to už řekl dostatečně jasně:
pokud volám metodu, tak tím bezprostředně spouštím nějaký (víc nebo míň) statický, předem daný kód. Pokud posílám zprávu, tak jenom sděluju nějakou informaci. Jak s tím příjemce informace naloží, jestli v návaznosti na to vyvine nějakou činnost nebo ne, je už na něm.
A kdyz zavolam metodu, co se sama interne rozhodne co udela?Tak se na tom, co jsem napsal, nemění ani čárka.
K cemu je dobre posilat do objektu zpravu, se kterou objekt neumi pracovat? Aby mi vratil InvalidArgumentException?Jak kdy a jak k čemu. Je "k něčemu dobré", že můžeš http serveru poslat nevalidní request? Je "k něčemu dobré", že po něm můžeš chtít resource, který nemá, a on ti odpoví "404 not found"?
Neni nahodou lepsi mit metodu se staticky typovanymi parametry, aby vubec nebylo mozne nesmyslnou zpravu objeku zaslat?
Dneska je programovani zhruba na urovni pred Kopernikem, takze se od tech majoritnich cirkevnich nazoru distancuju.Jak myslíš, no. Já bych si spíš vsadil, že to ještě v průběhu života přehodnotíš, ale třeba bych prohrál
Bud mam asynchronni poslani zpravy. Fire and forget.To s tím, co píšu, přímo nesouvisí.
Nebo mam synchronni volani zpravy, totez co volani funkce nebo metody. A to jsou celkem dve zpravy. Jedna odesilajici pozadavek, druha prijimajici vysledek.
Haskell je prilis striktni, neodpovida lidske intuiciZ mýho pohledu hlavně většinové programátorské intuici neodpovídá líné vyhodnocování. Většina z nás začínala a nejvíc času strávila přemýšlením v intencích "algoritmus je posloupnost kroků [...]".
Ja se majoritnich nazoru stitim. Majoritni nazor je jako lemmings nebo ovce.Majoritní názor taky je, že je Země kulatá. Minoritní názor je, že je placka.
Kdyby záleželo na tom, co jde v čem implementovat, tak je instrukce mov ta úplně nejobecnější možná abstrakce (je výpočetně úplná, takže jde pomocí nich implementovat úplně všechno).Ještě lepší je logický NOR, s ním si dospělej chlap vystačí
Nedovedl jsem si predstavit, ze se zrovna Ty na tohle nechytnes. ;-)Tak jasně, pro mě je to prostě srdcovka. S multiagentními systémy jsem si pohrával ještě když jsem tahal kačera po škole
muzu rict, ze zavolani metody je taky poslani zpravy.Říct to samozřejmě můžeš, ale naděláš tím víc škody než užitku, protože jsou to dva zásadně odlišné koncepty. Už jsme o tom tady mluvili: pokud volám metodu, tak tím bezprostředně spouštím nějaký (víc nebo míň) statický, předem daný kód. Pokud posílám zprávu, tak jenom sděluju nějakou informaci. Jak s tím příjemce informace naloží, jestli v návaznosti na to vyvine nějakou činnost nebo ne, je už na něm.
Stejně goroutiny/channely v Go, REST, microservices, ...Jo, málem bych zapomněl na výpočetní clustery - tam to funguje už hodně dlouho - MPI, Hadoop, Spark, ... To je všechno o předávání zpráv mezi dost autonomními, "svéprávnými" jednotkami.
Zalozit celou aplikaci na "posilani zprav" mezi "objekty", to se moc neuchytilo a IMO jsou k tomu dobre duvody.Já bych to takhle příkře nestavěl. Skoro bych řekl, že naopak tenhle způsob dívání se na systémy se poslední dobou docela rozšiřuje, akorát ne na té "druhé nejnižší úrovní" (samotný programovací jazyk). Na vyšších urovních se mi ale zdá, že docela kvete.
Root.cz (www.root.cz), informace nejen ze světa Linuxu. ISSN 1212-8309
Copyright © 1998 – 2023 Internet Info, s.r.o. Všechna práva vyhrazena. Powered by Linux.