Co si myslíte o OOP?

[listoper]

Kdyz hotswapnu nejaky modul ktery ma funkci akceptujici tuple tak mi otp samo zmigruje vsechny existujici relevantni tuply ktere do ni muzou prijit?

Úplně neumím rozšifrovat, na co se vlastně ptáš. Každopádně se nic samo nemigruje. Ale v OTP existují postupy, jak stavy zmigrovat. I způsoby, jak udělat rollback. Je to dost komplexní věc, nedá se to vysvětlit pár větama. Ale můžeš si něco o tom vygooglit, po netu je toho spousta.

A brani mi neco udelat ty migrace podobne v pythonu? Pokud vim tak erlang ma nemenitelne datove struktury. Takze migrace stavu bude znamenat zahozeni stareho a vytvoreni noveho stavu.

[Reklama]

[Mirek Prýmek]

A brani mi neco udelat ty migrace podobne v pythonu?

Ano, několik věcí - a je to popsané v tom odkazu, co's říkal, že sis pročetl.

Pokud vim tak erlang ma nemenitelne datove struktury. Takze migrace stavu bude znamenat zahozeni stareho a vytvoreni noveho stavu.

Ne. V Erlangu se stav udržuje tak, že se předává z jedné funkce do druhé. V event-loopu pak typicky ta funkce volá sebe sama:

Kód: [Vybrat]

def loop(stav) do
  # do something
  loop(stav)
end
(Tohle je Elixir, ale to je úplně to samý jako Erlang)

V OTP je pak tohle ještě zabalený do wrapperu, kterej když zjistí, že jsi kód upgradnul, tak automaticky zavolá funkci, která se o upgrade toho "stav" postará. Viz "Changing Internal State" http://erlang.org/doc/design_principles/appup_cookbook.html

[listoper]

A brani mi neco udelat ty migrace podobne v pythonu?

Ano, několik věcí - a je to popsané v tom odkazu, co's říkal, že sis pročetl.

Hmm. Nepresvedcil si me, ale nehodlam to dal tlacit, protoze python tolik neznam.

Pokud vim tak erlang ma nemenitelne datove struktury. Takze migrace stavu bude znamenat zahozeni stareho a vytvoreni noveho stavu.

Ne. V Erlangu se stav udržuje tak, že se předává z jedné funkce do druhé. V event-loopu pak typicky ta funkce volá sebe sama:

Kód: [Vybrat]

def loop(stav) do
  # do something
  loop(stav)
end
(Tohle je Elixir, ale to je úplně to samý jako Erlang)

V OTP je pak tohle ještě zabalený do wrapperu, kterej když zjistí, že jsi kód upgradnul, tak automaticky zavolá funkci, která se o upgrade toho "stav" postará. Viz "Changing Internal State" http://erlang.org/doc/design_principles/appup_cookbook.html

Fajn, ale stav je porad immutable. Takze ta funkce co se postara o upgrade vytvori novy stav a preda ho zpet do smycky.

[Mirek Prýmek]

Hmm. Nepresvedcil si me, ale nehodlam to dal tlacit, protoze python tolik neznam.

Ale já tě přece nepřesvědčuju, jenom říkám, že to máš popsané na té odkazované SO stránce a na jiných z ní odkazovaných:

You can use reload(module) for this, but beware of nasty side effects. For example, existing code will be based on the original code, it will not magically get new attributes or baseclasses added.

https://stackoverflow.com/questions/3862871/hot-reloading-swapping-with-python

Python modules’ code is recompiled and the module-level code reexecuted, defining a new set of objects which are bound to names in the module’s dictionary. The init function of extension modules is not called a second time. As with all other objects in Python the old objects are only reclaimed after their reference counts drop to zero. The names in the module namespace are updated to point to any new or changed objects. Other references to the old objects (such as names external to the module) are not rebound to refer to the new objects and must be updated in each namespace where they occur if that is desired.

https://stackoverflow.com/questions/437589/how-do-i-unload-reload-a-python-module

Prostě, Python je příliš flexibilní, dynamický a data jsou příliš provázaná (navzájem a s kódem) na to, aby to tam šlo implementovat dobře. U Erlangu to jde, protože tam s daty není potřeba dělat nic, prohodí se jenom kód a nové funkce se prostě zavolají se stejnými argumenty, se kterými by se volaly staré funkce.

Fajn, ale stav je porad immutable. Takze ta funkce co se postara o upgrade vytvori novy stav a preda ho zpet do smycky.

Samozřejmě. V Erlangu žádná funkce nic jiného než vytvářet nová data nemůže. Erlang má naprosto striktně imutabilní data. A proč to říkáš?

[listoper]

Fajn, ale stav je porad immutable. Takze ta funkce co se postara o upgrade vytvori novy stav a preda ho zpet do smycky.

Samozřejmě. V Erlangu žádná funkce nic jiného než vytvářet nová data nemůže. Erlang má naprosto striktně imutabilní data. A proč to říkáš?

Koukni na co reaguju. Tam mi tvrdis ze to tak neni.

[Reklama]

[Mirek Prýmek]

Koukni na co reaguju. Tam mi tvrdis ze to tak neni.

Máš pravdu, že jsem to napsal blbě. Chtěl jsem říct, že to není nic zvláštního, že v tom není podstata hot code loadingu. To "vytvoření nového stavu" se dělá po každém eventu (který mění stav).

A pořád mi není jasný, proč se o tom vlastně bavíme

[listoper]

Koukni na co reaguju. Tam mi tvrdis ze to tak neni.

Máš pravdu, že jsem to napsal blbě. Chtěl jsem říct, že to není nic zvláštního, že v tom není podstata hot code loadingu. To "vytvoření nového stavu" se dělá po každém eventu (který mění stav).

A pořád mi není jasný, proč se o tom vlastně bavíme

Me uz taky ne.  Tak toho nechame.

[pd]

Je to zlocinecka organizace a Arafat je terorista. :-)

[dfasdfasdf]

Je to zlocinecka organizace a Arafat je terorista. :-)

to nikdo nerozporuje, spis je otazka jestli delal arafat v c++ nebo v jave???

[SB]

Míjíte se s tím, co se snažím říct. Podstata sdělení je v tom příspěvku, který jste citoval, líp ji asi nevyjádřím:

Ne, o výkon nejde, spíš mě štve, jakým způsobem OOP strukturuje uvažování. V době největšího OOP-hypu se OOP vydávalo ne za model reality, ale tvářilo se, že má téměř ontologickou povahu. Tj. v knížkách se podvědomě sugerovala představa, že svět JE takový (má takovou strukturu), jak ho OOP modeluje. Tedy že OOP je vlastně "přirozený". A to je strašně destruktivní iluze.

Nerozporuju váš příspěvek, naopak jsem doplnil, že model už z podstaty (zjednodušení) nemůže být ekvivalentem skutečného objektu.

[SB]

Ked je OOP zo Smalltalku tak super hyper uzasne pre co sa (smalltalk) nepouziva?

Ovšem musím varovat před tím, že se ti pak Java možná zhnusí.

 

To není vůbec vtipné, psychické následky můžou být dost nepříjemné. Asi nikomu se nechce pracovat s horším, když pozná lepší.

[SB]

V OOP je dynamické typování opravdu výhodnější - kvůli polymorfismu a velmi pozdní vazbě.

Už to tu psal tuším p. Prýmek: Typ typování souvisí jen okrajově s polymorfismem - typovaný systém vede pouze na užší vyhledávání metody na straně obeslaného objektu dle typů ve zprávě, nic víc. Nepleťte si to s prasojazyky Java a C#, kdy jejich problémem není samotné typování, ale tzv. podtypový polymorfismus jako prostředek realizace časné vazby znemožňující kamarádění objektů (instancí) typově (třídně) nepříbuzných.

[SB]

Ajeje, uz tu zacina akademicka debata. Jeste ze to nemusim resit, asi se budu drzet Javy a jestli mi nekdo bude tvrdit, ze to neni tak vhodne na OOP, tak se budu smat, protoze kdo rikal, ze na tom zalezi, hlavne, ze se prace odvede dobre.

Ja jsem vlastne docela rad, ze jak Java, tak C# nejsou Kit-compliant OOP programovaci jazyky

Hosi, reknu vam to takhle a usetrim vam praci a dohadovani. Nevymyslejte bejkarny s OOP a podivejte se, jak to vypada v Jave a C# a jak se to pouziva v praxi, a toho se drzte, protoze nic lepsiho vymysleneho nebylo A jestli to je Kit-compliant OOP je vec uplne druhorada, protoze bavime se o tom, co je lepsi a co horsi, o to jde predevsim 

Že něčemu nerozumíte, ještě neznamená, že je to blbost.

[SB]

Za kvalitní objektový jazyk považuji Python...

Tak to máte docela nízké požadavky na kvalitu. Python je sice syntakticky přehledný a má dost knihoven, takže se v něm rychle dělá, ale ZCELA ZBYTEČNĚ obsahuje neobjektové konstrukce (len(řetězec), ...), na zapouzdření dlabe (přestože implementace by pravděpodobně ani nebyla složitá), definice třídních metod je řešena nekoncepčně přes jakési anotace... To mě napadá jen tak z hlavy, na co jsem stihnul zběžně narazit.

[SB]

O pár stránek zpět bylo propagováno oddělení funkcí od datových struktur, což je přesně proti myšlence OOP, tedy že metody jsou co nejblíž k datům, se kterými pracují.

OOP je o umístění stavu do objektu a o polymorfismu.

To nestačí. Kit to píše dobře. Myšlenkou OOP je, že stavy bez popisu svých změn a změny bez stavů nemají smysl, neboli jsou neoddělitelné.

To co popisuješ není dobrá definice. Vejdou se do toho snad všechny funkcionální jazyky. A možná i mnoho dalších neOOP.

Funkcionální jazyky neznám, ale z toho, co jsem zatím viděl, řeší výpočet přesně opačně.