Přechod z Javy na Rust. Ano či ne?

[echo_zulu]

Dobrá otázka je i "Co je to vůbec OOP?". Odpověď není až tak jednoduchá

Chápem ako to myslíte, ale tá odpoveď v podstate jednoduchá je. Pokiaľ poznáte históriu toho označenia. A myslím tým históriu od doby pred tým ako to označenie vzniklo.

A pokiaľ ju nepoznáte a nie ste si istý tým, čo OOP znamená, tak znamená to, čo si drvivá väčšina jeho používateľov myslí, že znamená.

To, že to označenie bolo vytvorené pre niečo iné, nie je vôbec podstatné. Nikdy sa to nepodarilo v širšej miere presadiť, ale hlavne, aj jeho samotný tvorca sa po čase vyjadril, že to, čo vytvoril, mal nazvať inak, podľa toho, čo je pre to, čo vytvoril zásadné a čo by mu dalo jednoznačný a nezameniteľný význam.

Keby to, čo vytvoril, nazval inak, tak je celkom veľká pravdepodobnosť, že OOP by sa začalo používať prirodzeným vývojom už len na základe toho aké generické slova sú v ňom použité.

[Reklama]

[echo_zulu]

Ona jakákoliv serializace bude v principu narušovat zapouzdření, jinak nemůže fungovat. Je jen otázka, jestli to není zapouzdřené až na úrovni toho xml, nebo už někdy dřív.

Väčšinou, keď vám nezáleží na opaku, ale nie nutne vždy.

Zapúzdrenie slúži na zabránenie nekontrolovanej zmeny členskej dátovej položky, aby jej nežiadanou zmenou nemohlo dôjsť k nastaveniu vnútorného stavu, ktorý je neplatný alebo iným spôsobom nežiadaný.

Pokiaľ si serializované dáta podpíšete, tak deserializácia prípadnú manipuláciu s dátami v uloženej forme odhalí, a vytvorenie objektu neumožní.

[echo_zulu]

V tomto smyslu porušují zapouzdření všechny gettery a settery. Přesto je kdekdo používá.

Gettery iba ak vracajú odkaz na nekonštantnú položku, settery iba ak argument zapíšu do členskej premennej bez akejkoľvek kontroly.

[echo_zulu]

No právě. Opravdu se ten dokument mění? Je furt stejný, jen jsme k němu přidali nějaké ověření. Že je to jiný inkoust na stejném papíře je nepodstatný detail. V programu to může být druhý objekt, který se odkazuje na ten původní nezměněný dokument.

Presne. Nepodpísaný dokument a podpísaný dokument majú byť dve rôzne veci. Potom sa dá jednoducho dosiahnuť, že ak funkcii, ktorá vyžaduje podpísaný dokument dáte ako argument nepodpísaný dokument, dostanete veľmi dôrazné upozornenie už pri zostavení programu. Teda, pri pokuse o zostavenie programu...

[Kit]

V tomto smyslu porušují zapouzdření všechny gettery a settery. Přesto je kdekdo používá.

Gettery iba ak vracajú odkaz na nekonštantnú položku, settery iba ak argument zapíšu do členskej premennej bez akejkoľvek kontroly.

To jsou velmi časté případy. Bohužel autoři stále tvrdí, že zapouzdření neporušují.

[Reklama]

[Jožka Niemand]

Btw asi velmi dobré porovnání OOP s funkcionálním přístupem (identity, stavy) napsal Hick Hickey https://clojure.org/about/state

Minimálně za přečtení a zamyšlení to stojí. Možná to automaticky vyřeší ten problém s "lejstrem" vs "lejstrem se štemplem" - imho je to jen otázka správného pojmenování jednotlivých abstrakcí.

Nevím, no. Mám už za ty desítky let něco odprogramováno a slovy doktora Vlacha, "zákony života nám ukládají vyzkoušet všechny možné varianty, abychom se nakonec vrátili k té první." V mém případě - procedurálně-imperativnímu strukturovanému paradigmatu. Opravdu mám pocit, že všelijaké ty snahy o čisté OOP, FP a já nevím, co ještě, jsou takové snahy najít svatý grál, nebo to království, kde létají pečení holubi rovnou do úst. Jenže nakonec člověk zjistí, že "co já se toho království nahledal... Nic nenajdou. Všude se musí... makat." A čím více jsem toho viděl a vyzkoušel, tím větší mám pocit, že ta "klasika" je nakonec to nejlepší. Takže když čtu podobné náboženské texty jako ten odkazovaný, už se musím jen usmívat.

[BoneFlute]

jsou takové snahy najít svatý grál, ...
Takže když čtu podobné náboženské texty jako ten odkazovaný, už se musím jen usmívat.

A já ho našel a musím se usmívat vám. Nevím, jak jsme si pomohli 

[BoneFlute]

Trochu se omlouvám za to rýpnutí do funkcionální víry ale nedalo mi to :-)

Nejde o víru, ale o paradigma. Skrz co interpretujete svět a jaké základní kameny používáte při stavbě toho modelu.

OOP velmi dobře modeluje svět jak ho známe. Když se odprostíme od nějaké metafyziky úrovně kvarků a spol, tak objekt si skutečně uchovává svůj vztah. Když lékař testuje pacienta a jeho organizmus, tak skutečně ta informace je uvnitř, a pěkně schovaná pod kůží, etc, etc.

Problém OOP je v tom, že se to strašně špatně používá v praxi. FP je paradigma, které je trochu atypické, trochu na hlavu (pro někoho), jenže jeho výhoda je v tom, že se mnohem lépe používá. Programátor kód, který je napsaný FP způsobem má kód mnohem více pod kontrolou etc, etc. Za svou kariéru, když jsem řešil problém OOP způsobem, tak jsem se někdy dostal do situace, že to bylo dost nepřirozený, nebo komplikovaný. A velmi často strašně nečitený.

V případě FP se mi to nestává.

Čistá prax, nic víc.

[Pavel Tišnovský]

Btw asi velmi dobré porovnání OOP s funkcionálním přístupem (identity, stavy) napsal Hick Hickey https://clojure.org/about/state

Minimálně za přečtení a zamyšlení to stojí. Možná to automaticky vyřeší ten problém s "lejstrem" vs "lejstrem se štemplem" - imho je to jen otázka správného pojmenování jednotlivých abstrakcí.

Takže když čtu podobné náboženské texty jako ten odkazovaný, už se musím jen usmívat.

Naprosto v pořádku, ať si každý programuje, jak uzná za vhodné, ostatně kdo já jsem, abych to rozhodoval (tedy kromě toho, jak to budeme dělat v mém týmu). Ale ta linkovaná stránka v žádném případě není náboženský text, ale dobré vysvětlení, jak se s identitami a stavy pracuje v Clojure, což je poměrně prakticky navržený jazyk, ovšem postavený na praktickém FP.

[Jožka Niemand]

Btw asi velmi dobré porovnání OOP s funkcionálním přístupem (identity, stavy) napsal Hick Hickey https://clojure.org/about/state

Minimálně za přečtení a zamyšlení to stojí. Možná to automaticky vyřeší ten problém s "lejstrem" vs "lejstrem se štemplem" - imho je to jen otázka správného pojmenování jednotlivých abstrakcí.

Takže když čtu podobné náboženské texty jako ten odkazovaný, už se musím jen usmívat.

Naprosto v pořádku, ať si každý programuje, jak uzná za vhodné, ostatně kdo já jsem, abych to rozhodoval (tedy kromě toho, jak to budeme dělat v mém týmu). Ale ta linkovaná stránka v žádném případě není náboženský text, ale dobré vysvětlení, jak se s identitami a stavy pracuje v Clojure, což je poměrně prakticky navržený jazyk, ovšem postavený na praktickém FP.

Až na ta hodnotící prohlášení. Praktický jazyk postavený na FP (i když ne tak fundamentálně) je pro mě Common Lisp. Scheme taky ještě zkousnu, ale např. Erlang nebo Haskell už není můj cup of tea. S čistým OOP mám mnohem menší problém (Smalltalk), ale pořád se nemohu zbavit dojmu, že OOP mě nutí věci dělat mnohem kostrbatěji, než je nutné. A jazyk typu Rust - to je čistý BDSM.

[Jiří Havel]

Dobrá otázka je i "Co je to vůbec OOP?". Odpověď není až tak jednoduchá

Chápem ako to myslíte, ale tá odpoveď v podstate jednoduchá je. Pokiaľ poznáte históriu toho označenia. A myslím tým históriu od doby pred tým ako to označenie vzniklo.

A pokiaľ ju nepoznáte a nie ste si istý tým, čo OOP znamená, tak znamená to, čo si drvivá väčšina jeho používateľov myslí, že znamená.

To, že to označenie bolo vytvorené pre niečo iné, nie je vôbec podstatné. Nikdy sa to nepodarilo v širšej miere presadiť, ale hlavne, aj jeho samotný tvorca sa po čase vyjadril, že to, čo vytvoril, mal nazvať inak, podľa toho, čo je pre to, čo vytvoril zásadné a čo by mu dalo jednoznačný a nezameniteľný význam.

Keby to, čo vytvoril, nazval inak, tak je celkom veľká pravdepodobnosť, že OOP by sa začalo používať prirodzeným vývojom už len na základe toho aké generické slova sú v ňom použité.

Ano, jazyk S. od pana K. je důležitá součást toho zmatku. Četl jsem i jeho vyjádření o tom, že to nazval fakt blbě. Akorát že OOP jazyky typu svatá čtveřice se inspirovaly ještě předtím od Simuly (jen nevím, jak se tomu paradigmatu říkalo v té době). Pak tu máme skupinku "nasyp všechno do jedné hashmapy". A možná i další.
Dorazila to etapa stříbrné kulky. Aspoň že ta už je snad pryč.

[Jiří Havel]

Nevím, no. Mám už za ty desítky let něco odprogramováno a slovy doktora Vlacha, "zákony života nám ukládají vyzkoušet všechny možné varianty, abychom se nakonec vrátili k té první." V mém případě - procedurálně-imperativnímu strukturovanému paradigmatu. Opravdu mám pocit, že všelijaké ty snahy o čisté OOP, FP a já nevím, co ještě, jsou takové snahy najít svatý grál, nebo to království, kde létají pečení holubi rovnou do úst. Jenže nakonec člověk zjistí, že "co já se toho království nahledal... Nic nenajdou. Všude se musí... makat." A čím více jsem toho viděl a vyzkoušel, tím větší mám pocit, že ta "klasika" je nakonec to nejlepší. Takže když čtu podobné náboženské texty jako ten odkazovaný, už se musím jen usmívat.

No já dělám primárně v C++ a C#, ale Haskell hodně ovlivnil moje uvažování. Jo, když hledáte stříbrnou kulku, dostanete akorát žaludeční vředy. Ale jako inspirace, že se dá problém pojmout jinak a líp je to supr.

Řekl bych že zrovna nové C++ je funkcionálním programováním hodně ovlivněné. I sprosté slovo na M by se našlo