Co si myslíte o OOP?

[Youda]

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

Jinak ale celkem souhlas se vším, co píšeš.

A priklad z Javy je napr. OSGi Container Apache Karaf v podani talend ESB, ktery taktez volani mezi jednotlivymi services v ramci jednoho node implemetuje jako proste volani metody, do externich nodes jako zpravy (z pohledu uzivatele transparentni volani metody). Routuje to tusim Apache Camel, nody jsou managovane via Apache Zookeeper.
Na kazdou mikroservicu kontrola RBAC a PEP (policy enforcement point)

Na papire velika krasa, v realite se to hrouti pod tihou byrokracie a je vyhodnejsi delat si distribuovane funkcni moduly sam. Takze hezky core + collectory + stream processing fronty + backend + GUI.
Cellou filosofii microservices poivazuju za mrtvy hype, vsechny tyhle pristupy stoji na premise, ze zaslani zpravy nestoji nic, resp je stejne levne jako zavolani lokalni metody v ramci JVM a ze je to stejne spolehlive.

[Reklama]

[operator]

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

Jinak ale celkem souhlas se vším, co píšeš.

Nutne neni potreba ani to posilani zprav. Resp. je potreba v minimu pripadu, kdy se vyplati ho implementovat rucne a proto je lepsi ho nemit by default. Ale rozlisoval bych mezi interni implementaci a abstrakci. V Pythonu treba cisla interne take ve skutecnosti nejsou objekty, to by byl o dost pomalejsi, ale vuci programatorovi se tak tvari a to je to, co se pocita, to je podle me podstatne, protoze to umoznuje programatorovi k programu pristupovat nejakym a jednotnym pristupem. Podle me je Python vyborne navrzen, vsechno je v nem objekt a definice tridy je zaroven definici datoveho typu. Pricemz k tomuto sjednoceni doslo az ve verzi 2.2, a po zbytek druhe generace v nem byly objekty dvojiho typu. Cesta k jeho dobremu navrhu je lemovana chybami a odvahou prinaset nekompatibilni zmeny. 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.

[v]

Ted je na poradu dne spise asynchronni komunikace, kterou python pred casem adoptoval a ted se ladi.

jestli je tím myšleno asyncio, tak tady je IMO python hodně pozadu, srovnejte s erlangem, haskellem a asi go

[Kadet]

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

Jakmile vidis, ze to na co lidi pouzivaji tisice az miliony radku kodu jde pouzit par set nebo mozna nizkych tisic, a udelat to zaroven jednodussi, rychlejsi, citelnejsi, tak prehodnotis.

Jestli v programovani existuje silver bullet, pak bych bych vsadil hodne na to, ze to bude jednoduchost (simplicity).

Presne na tohle je dobra vyssi abstrakce, kterou nazyvas nadbytecny syntakticky cukr. Porad to vnimam tak, ze si protirecis.

Az vyresis tuhle kontradikci, naleznes nirvanu.

Syntakticky cukr je derava abstrakce. Dostanes jednu abstrakci dnes, ale uz z ni zitra nevytvoris jeste vyssi abstrakci. Pro nederavy abstrakce potrebujes vysoce kompozitabilni stavebni bloky, napr. nekdo zminil nor nebo mov nebo funkce. Ty slozis do vyssich abstraktnich bloku, ty jeste do vyssich, atd.
Tridy a objekty jsou derava abstrakce. Je to videt kdyz zjistis ze najednou potrebujes metatridy a tvuj jazyk je nema. Smalltalk tridy mozna deravy nejsou, ale ve vetsine jazyku je to abstraktni dira.

[Inkvizitor]

Tridy a objekty jsou derava abstrakce. Je to videt kdyz zjistis ze najednou potrebujes metatridy a tvuj jazyk je nema. Smalltalk tridy mozna deravy nejsou, ale ve vetsine jazyku je to abstraktni dira.

Ve skutecnosti metatridy prakticky nikomu nechybi.

[Reklama]

[operator]

Ted je na poradu dne spise asynchronni komunikace, kterou python pred casem adoptoval a ted se ladi.

jestli je tím myšleno asyncio, tak tady je IMO python hodně pozadu, srovnejte s erlangem, haskellem a asi go

Pozadu je, ale dotahuje se, s kazdou verzi se to vylepšuje. Asyncio je modelova knihovna. Soucasti jazyka se staly prikazy async a await a pracuje se na jejich hlubsi integraci do systemu. Python jde evolucni cestou vyvoje, takze se nejprve vyzkousi koncept, pak se to implementuje jako modul, pak se to zavede do jazyka, a nakonec se to v nem usazuje a prorusta do systemu. Stejne tak to probihalo u dalsich abstrakci, u novych trid, iteratoru, generatoru, type hintingu. Je to jen otazka casu.

[Kadet]

Poslednich par stranek je rozprava o tom jestli je lepsi poslani zpravy nebo zavolani metody. Jednak u toho litaji ruzny interpretace, jednak jestli to bezi uvnitr pocitace nebo vne mezi pocitaci. Bylo by to fajn klasifikovat.

Podobna debata by mohla byt nad tvrdou konzistenci a eventualni konzistenci (eventual consistency). Poslani zpravy je fire and forget. Erlang system mi da dobrej zaklad postavit microservice system, to jo. Ale tezka cast je udelat v tom skutecne konzistentni system, protoze to je to, co uzivatele nebo programatora, co koordinuje jednotky takovyho systemu, zajima. Nezajima ho, ze nekdy ta zprava nekdy dorazi, nekdy mozna ne. Tvrde konzistentni system je RPC nebo taky jinak receno 'zavolani metody' neboli dve zpravy, jedna odesilajici request a druha prijimajici response, obe provazany nejakym reauest-id.

Problem s microservices je matematicka nemoznost provest exactly-once-delivery s omezenou pameti.

Takze posilani zprav je jen potencialni prvni krok k tomu dostat se k nejakymu funkcnimu systemu. Chapu, kdyz se s Erlangem/Elixirem nekdo uci, tak je to ze zacatku wow.

Pokusy v posledni dobe vytvorit NoSQL eventual consistency databaze spadly na hubu, nikdo je nechce pouzivat a ted Google prisel se Spannerem, kterej dela tvrdou konzistenci napric kontinenty diky tomu ze na to ma dedikovanej hardware.

[Mirek Prýmek]

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

Takže jo, možná za deset let Python nějakou aspoň jakžtakž použitelnou implementaci mít možná bude. (Teda za předpokladu, že benevolentní diktátor nesdělí poddaným Pravdu, že to je od základů špatný přístup a proto to v Pythonu nikdy nebude )

[Mirek Prýmek]

jestli je tím myšleno asyncio, tak tady je IMO python hodně pozadu, srovnejte s erlangem, haskellem a asi go

Co Erlang a Haskell... Node.js už tady máme 9 (slovy: devět) let!

[v]

jestli je tím myšleno asyncio, tak tady je IMO python hodně pozadu, srovnejte s erlangem, haskellem a asi go

Co Erlang a Haskell... Node.js už tady máme 9 (slovy: devět) let!

já jsem hlavně narážel na nutnost psát explicitně všelijaké ty async/await, když erlang má lightweight vlákna přes 30 let

[operator]

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

Jakmile vidis, ze to na co lidi pouzivaji tisice az miliony radku kodu jde pouzit par set nebo mozna nizkych tisic, a udelat to zaroven jednodussi, rychlejsi, citelnejsi, tak prehodnotis.

Jestli v programovani existuje silver bullet, pak bych bych vsadil hodne na to, ze to bude jednoduchost (simplicity).

Presne na tohle je dobra vyssi abstrakce, kterou nazyvas nadbytecny syntakticky cukr. Porad to vnimam tak, ze si protirecis.

Az vyresis tuhle kontradikci, naleznes nirvanu.

Syntakticky cukr je derava abstrakce. Dostanes jednu abstrakci dnes, ale uz z ni zitra nevytvoris jeste vyssi abstrakci. Pro nederavy abstrakce potrebujes vysoce kompozitabilni stavebni bloky, napr. nekdo zminil nor nebo mov nebo funkce. Ty slozis do vyssich abstraktnich bloku, ty jeste do vyssich, atd.
Tridy a objekty jsou derava abstrakce. Je to videt kdyz zjistis ze najednou potrebujes metatridy a tvuj jazyk je nema. Smalltalk tridy mozna deravy nejsou, ale ve vetsine jazyku je to abstraktni dira.

Nerozumim pojmu derava abstrakce?
Jak vis co bude zitra?
Nad objekty jako abstrakce imho stoji komponenty. Ale neni nutne aby nad kazdou abstrakci byla jeste vyssi, resp. aby kazda abstrakce byla soucasti ci stavebnim kamenem vyssi abstrakce.
Metatrida je spise implementacni detail, druh tridy za nejakym ucelem, podobne jako je treba abstraktni trida, nez nova vyssi abstrakce. Python manipulaci s metatridami umoznuje, ale myslim ze jsem toho nikdy nevyuzil, takze se nedivim, ze v jinych jazycich nejsou k dispozici. Pokud by to byl problem, je dusledkem nedostatecne implementace, nikoliv chybne abstrakce.
V cem je objekt derava abstrakce?
Trida je derava abstrakce ale smalltalk trida derava neni? Zase si protirecis.

[operator]

jestli je tím myšleno asyncio, tak tady je IMO python hodně pozadu, srovnejte s erlangem, haskellem a asi go

Co Erlang a Haskell... Node.js už tady máme 9 (slovy: devět) let!

já jsem hlavně narážel na nutnost psát explicitně všelijaké ty async/await, když erlang má lightweight vlákna přes 30 let

Mozna ma a nic mu to nebylo platny. :-) Python ma greenlety uz taky nejaky rok, o tom to preci neni.

[v]

jestli je tím myšleno asyncio, tak tady je IMO python hodně pozadu, srovnejte s erlangem, haskellem a asi go

Co Erlang a Haskell... Node.js už tady máme 9 (slovy: devět) let!

já jsem hlavně narážel na nutnost psát explicitně všelijaké ty async/await, když erlang má lightweight vlákna přes 30 let

Mozna ma a nic mu to nebylo platny. :-) Python ma greenlety uz taky nejaky rok, o tom to preci neni.

greenlet jsem neznal, nicméně to nevypadá jako skutečné lightweight vlákno, chybí mi ta abstrakce vlákna

[operator]

jestli je tím myšleno asyncio, tak tady je IMO python hodně pozadu, srovnejte s erlangem, haskellem a asi go

Co Erlang a Haskell... Node.js už tady máme 9 (slovy: devět) let!

Node.js neni univerzalni, je orientovan na web. V tomto smeru nabizi Python treba Tornado a Twisted. Ale to je take jednoucelove reseni. Reseni na urovni jazyka je samozrejme lepsi.

[gll]

chybí mi ta abstrakce vlákna

to by mělo vypadat jak?