Co si myslíte o OOP?

[BoneFlute]

Já nevím, tohle se mi nezdá. Když mám data z externího zdroje, stále to můžu otypovat. [...] typem určím, že buď zadá číslo, a pak ho zpracuju, nebo zadá nečíslo, a pak mu hodím chybovku. Tohle jde udělat compile-time.

To rozlišení mezi číslem a (čímkoli jiným) není nic jinýho, než dynamický typování

Je to ošetřený a rozhodnutý v době překladu. To je to co mě zajímá.

[Reklama]

[operator]

Smysl statických typů je zajistit, aby se něco takového nestalo.

Smyslem statickych typu je vykonostni optimalizace.

[SB]

Jen tak pro informaci by mne zajímalo, který staticky typovaný jazyk standardně doporučuje mít v poli různé typy? Tím neříkám, že to v některých nejde, ale je to prostě prasárna, kdy poté musím používat reflexi. Pro tyto případy se používá mapa, což je tvůj druhý příklad. Jaký je rozdíl?

Přestože netypové jazyky reflexi umějí, obvykle ji nepoužívají, protože ji nepotřebují. Používají polymorfní zprávy, např. name, asString, isNil, ... Tu mapu jsem nepochopil.

Celý ten případ s JSONem je na hlavu postavený. Pokud chci pracovat s hlubokou strukturou, prostě použiji JSONPath, stejně jako dříve uvedený příklad a mám to stejně rychle. Podle jazyka pak zpracuji chybu, pokud položka neexistuje. Žádný rozdíl.

Procházení JSONu jako dynamické struktrury není z podstaty problémem, to tu nikdo nepotřebuje řešit. Problémem je až okamžik, kdy pro tuto dynamickou strukturu potřebujete namodelovat objekt tak, aby ji rovněž dynamicky dokázal vcucnout, neboli aby obsahoval to, co popisuje JSON. To u statického jazyku nemusí být vůbec pr-del.

Nejsem žádný mistr přes jazyky, ale pokud vím, všechny běžně používané staticky typované jazyky umožňují nějakým způsobem reflexi, takže není problém do nich dynamické typování "dodělat". Statické typování do dynamicky typovaných jazyků ale dodělat nelze.

Jasně, vždycky to nějak jde, problémem je to slovo "nějak", často to není snadné => práce navíc.
Statické typování v době překladu pochopitelně ne, ale běhově pochopitelně ano.

Mám zkušenosti s oběma skupinami a největší rozdíl vidím v dokumentaci. Na co ve staticky typovaných jazycích stačí 3 řádky a odkaz na strukturu, je potřeba v dynamicky typovaných jazycích zpravidla 3x tolik informací. A ani potom nemám moc velkou jitotu, co tam skutečně může být.

Těžko říct. Obecně platí, že každý jazyk je dobrý v něčem jiném, není jeden, co má všechno nejlepší.

[SB]

Na co v dynamicky typovaných jazycích stačí jedna metoda, ve staticky typovaných potřebuješ třeba tři přetížené. Například pokud potřebuješ sort pro integer, float nebo string.

Ale ne. Dle principu sebeodpovědnosti objektu každý objekt definuje uspořádání (např. isLessThan:), metodě sort už pak stačí je obecně a polymorfně ověřovat pro jednotlivé páry, aniž by o nich musela cokoliv vědět.

[SB]

...Když konečně přesvědčím kompilátor, aby to přeložil, tak mám obecně hotovo. Zbejvaj sémantické chyby. Zatímco u dynamického jazyka furt něco padá.

Jo, o tom tu bylo hovadsky dlouhé vlákno ve fóru se závěrem, že kompletnost významové kontroly programu a jednoduchost takové kontroly jdou (logicky) proti sobě, takže jsou-li vaše typy jednoduché, většina kontrol vás teprve čeká.

[Reklama]

[Ondra Satai Nekola]

Na co v dynamicky typovaných jazycích stačí jedna metoda, ve staticky typovaných potřebuješ třeba tři přetížené. Například pokud potřebuješ sort pro integer, float nebo string.

Ale ne. Dle principu sebeodpovědnosti objektu každý objekt definuje uspořádání (např. isLessThan:), metodě sort už pak stačí je obecně a polymorfně ověřovat pro jednotlivé páry, aniž by o nich musela cokoliv vědět.

Dokud ti staci jedno usporadani...

[operator]

...Když konečně přesvědčím kompilátor, aby to přeložil, tak mám obecně hotovo. Zbejvaj sémantické chyby. Zatímco u dynamického jazyka furt něco padá.

No LOL. Staticke typy vznikly za ucelem vykonostni optimalizace, pro jednoduchou a rychlou praci s pameti..  Navzdory tomu spousta jejich priznivcu je presvedcena, ze jejich smysl je zajistit bezchybnost aplikace a z nich potom padaji obdobne nesmyslne hlasky, ze kdyz program proleze kompilatorem, tak je hotovo.

Dovolim si tvrzeni, ze staticke typy adoruji lini programatori, kteri nechteji delat testy a ziji v naivnim presvedceni, ze kompilator testuje aplikaci za ne.

Programy v dynamickych jazycich obecne nepadaji, to je domenou jazyku, ktere nemaji vyjimky. Nevzpominam si ze bych videl nekdy padnout python. A jestli jo, tajḱ jedine kvuli nejake knihovne napsane v C, tedy staticky typovanem jazyku.

[BoneFlute]

...Když konečně přesvědčím kompilátor, aby to přeložil, tak mám obecně hotovo. Zbejvaj sémantické chyby. Zatímco u dynamického jazyka furt něco padá.

Jo, o tom tu bylo hovadsky dlouhé vlákno ve fóru se závěrem, že kompletnost významové kontroly programu a jednoduchost takové kontroly jdou (logicky) proti sobě, takže jsou-li vaše typy jednoduché, většina kontrol vás teprve čeká.

Šlo o pochopitelné zjednodušení. V statickém typování mám spousta kontrol (netvrdím, že všechno). V dynamickém žádné. Nehledě na to, že v mé otázce jsem to zohlednil. Ptal jsem se, co je výhoda dynamického typování. Když to technicky nejde, tak to technicky nejde, to dá rozum. Ale to není ta výhoda.

[BoneFlute]

No LOL. Staticke typy vznikly za ucelem vykonostni optimalizace, pro jednoduchou a rychlou praci s pameti.. 

Taky si LOLnu. Samozřejmě, tak vznikli. Ale to je historie. Existuje taky věc, jako teorie typů.

Navzdory tomu spousta jejich priznivcu je presvedcena, ze jejich smysl je zajistit bezchybnost aplikace a z nich potom padaji obdobne nesmyslne hlasky, ze kdyz program proleze kompilatorem, tak je hotovo.

Ano, a taky to tak je. Sice to asi nejde dotáhnout tak, aby to bylo doslova jak píšu, ale odvedou ohromné množství práce. V porovnání s dynamickými, které nedělají žádnou práci, ...

Dovolim si tvrzeni, ze staticke typy adoruji lini programatori, kteri nechteji delat testy a ziji v naivnim presvedceni, ze kompilator testuje aplikaci za ne.

Měl jsem jednou přednášku na námět teorie typů. Vzhledem k tomu, jak na mě zmateně koukali mě už nepřekvapuje, že tu tolika lidem zcela ujel vlak.

Programy v dynamickych jazycich obecne nepadaji, to je domenou jazyku, ktere nemaji vyjimky. Nevzpominam si ze bych videl nekdy padnout python.

Tak když to říkáš. Na takovou blbost se nebudu optěžovat argumentovat.

[SB]

...V dynamickym prostredi to deserializuju do obyc nestovanyho dict objektu, nad kterym mam dostupnych tisic generickych funkci. Konverzi do vsech moznych formatu. Vse dostupne out of the box...

To je ale špatně, to jste jen jednu dynamickou strukturu (JSON) převedl na jinou (dictionary) a mohl ji převést ještě na jinou (XML) a do toho bouchat těmi "obecnými" funkcemi, nebo do toho bouchat zvenku (anemický doménový model). To umí i ten statický jazyk. To je mi ale k hovnu, já potřebuju, aby z toho vypadnul specifický objekt se specifickou funkcionalitou řešící můj specifický problém (bavíme se tu o OOP, ne?)!!!

Takže já potřebuju, aby když mi přijde JSON pro rekonstrukci objednávky, tak jej předstrčím prázdné Objednávce, aby se z něj deserializovala s tím, že na místě objednatele může být fyzická, nebo právnická osoba. Tohle ale dokáže i ta prašivá Java, problémem je, že aby to šlo, musím fyz. a práv. osobě najít společného předka, protože Java mechanismus pro znovupoužití kódu (dědičnost) zneužívá pro předstírání pozdní vazby vedoucí na polymorfismus. U dynamického jazyku je mi to u pr-dele, tam prostě do objednatele strčím objekt, který umím deserializovat (bez ohledu na jeho funkcionalitu; dle dat nebo označení v podjsonu), nebo který v případě objektu s identitou dostanu od úložiště objektů. Práce s ním je pak již jinou, oddělenou záležitostí, tzn. že Objednávka sama o sobě nemusí s objektem objednatele umět pracovat (nebo používat vše), ale někdo jiný, kdo bude potřebovat, to umět bude.

[operator]

...Když konečně přesvědčím kompilátor, aby to přeložil, tak mám obecně hotovo. Zbejvaj sémantické chyby. Zatímco u dynamického jazyka furt něco padá.

Jo, o tom tu bylo hovadsky dlouhé vlákno ve fóru se závěrem, že kompletnost významové kontroly programu a jednoduchost takové kontroly jdou (logicky) proti sobě, takže jsou-li vaše typy jednoduché, většina kontrol vás teprve čeká.

Šlo o pochopitelné zjednodušení. V statickém typování mám spousta kontrol (netvrdím, že všechno). V dynamickém žádné. Nehledě na to, že v mé otázce jsem to zohlednil. Ptal jsem se, co je výhoda dynamického typování. Když to technicky nejde, tak to technicky nejde, to dá rozum. Ale to není ta výhoda.

U statickych typu mas kontrolu prace s pameti, kterou u dynamickych jazyku nepotrebujes. Kompilator  dynamickeho jazyka ti take odhali spoustu chyb a linter spoustu dalsich. Nic z toho neznamena, ze kdyz to tim proleze, ze uz mas prakticky hotovo. A mimochodem, me linter na chyby upozornuje uz behem psani.

[BoneFlute]

Dokud ti staci jedno usporadani...

Je v tom rozdíl, zda je ten stav uvnitř objektu (OOP), či vně (FP) ? Imho ten problém je stejný. Ani jeden to nedělá výrazně líp. (Pro mě je FP hlavně Haskell.)

[BoneFlute]

Nic z toho neznamena, ze kdyz to tim proleze, ze uz mas prakticky hotovo.

Šlo o pochopitelné zjednodušení.

U statickych typu mas kontrolu prace s pameti,

Ano. No a? Ptal jsem se na to, v čem je dynamické typování tak výrazně výhodnější jak statické. V tom, že statické umí i optimalizovat výkon?

Kompilator  dynamickeho jazyka ti take odhali spoustu chyb a linter spoustu dalsich. Nic z toho neznamena, ze kdyz to tim proleze, ze uz mas prakticky hotovo. A mimochodem, me linter na chyby upozornuje uz behem psani.

Proto jsem tak přeháněl. Protože vám kompilátor dynamického jazyka objeví syntax error, a linter nevhodnou konstrukci, a už jste z toho unešeni jak OHROMNĚ vám to pomáhá. Panejo!

[Inkvizitor]

No LOL. Staticke typy vznikly za ucelem vykonostni optimalizace, pro jednoduchou a rychlou praci s pameti..  Navzdory tomu spousta jejich priznivcu je presvedcena, ze jejich smysl je zajistit bezchybnost aplikace a z nich potom padaji obdobne nesmyslne hlasky, ze kdyz program proleze kompilatorem, tak je hotovo.

Jako starý Pythonista musím nesouhlasit. Stačí blbá číselná konstanta (v Pythonu už je naštěstí enum), máš dvě sady číselných konstant, někdo se sekne, napíše něco podobného (našeptávání ve Vimu nebo v IDE) a chyba je na světě. To jsem bohužel viděl v praxi. A jelikož těch konstant můžeš mít desítky a jelikož to špatné číslo může nasekat paseku, která na první pohled není hned vidět, testy to pravděpodobně nevyřeší. Nehledě k tomu, že testy zcela obecně nezaručují korektnost aplikace ve všech situacích. Tady by explicitní typ a la Haskell vyřešil úplně všechno.

Dále ta Tvoje naprosto nekonstruktivní poznámka o účelu statických jazyků - jasně, u trošku inteligentnějších asemblerů (C a spol.) to není nic jiného, než přiblížení železu, jenže u moderních, dobře psaných jazyků typy pomáhají přesnému vyjadřování a kontrole korektnosti. To vidí každý, kdo zažil v akci *ML, Haskell, Rust atd. a nemá klapky na očích. Jazyky typu C mají navíc to typování úplně špatně (přetypování ukazatelů, hloupá sémantika boolovských operací). A Python, bohužel, z Céčka pár těch nesmyslů přebral (sémantika boolovských operací, před verzí 3 bylo dokonce možno porovnávat číslo a None, to byl teda nápad!)

Takže otázka nezní, co bylo původním záměrem statických jazyků, ale co přinášejí navíc a v čem samozřejmě mohou mít nevýhody. Zbytek Tvého příspěvku necituju, ale vzhledem k tomu, že explicitně zmiňuješ C, doporučuju trochu pokory a samostudia.

[operator]

No LOL. Staticke typy vznikly za ucelem vykonostni optimalizace, pro jednoduchou a rychlou praci s pameti.. 

Taky si LOLnu. Samozřejmě, tak vznikli. Ale to je historie. Existuje taky věc, jako teorie typů.

Navzdory tomu spousta jejich priznivcu je presvedcena, ze jejich smysl je zajistit bezchybnost aplikace a z nich potom padaji obdobne nesmyslne hlasky, ze kdyz program proleze kompilatorem, tak je hotovo.

Ano, a taky to tak je. Sice to asi nejde dotáhnout tak, aby to bylo doslova jak píšu, ale odvedou ohromné množství práce. V porovnání s dynamickými, které nedělají žádnou práci, ...

Dovolim si tvrzeni, ze staticke typy adoruji lini programatori, kteri nechteji delat testy a ziji v naivnim presvedceni, ze kompilator testuje aplikaci za ne.

Měl jsem jednou přednášku na námět teorie typů. Vzhledem k tomu, jak na mě zmateně koukali mě už nepřekvapuje, že tu tolika lidem zcela ujel vlak.

Programy v dynamickych jazycich obecne nepadaji, to je domenou jazyku, ktere nemaji vyjimky. Nevzpominam si ze bych videl nekdy padnout python.

Tak když to říkáš. Na takovou blbost se nebudu optěžovat argumentovat.

Teorie typu existuje a ne jen jedna, treba i v psychologii a je to asi stejne relevantni.
Realita je jednoducha, programovani se neobejde bez testovani, bez statickych typu ano. Staticke typy zvysuji miru slozitosti programu, tedy jeho nachylnost k chybam. Stojí to jen za ten výkon a jen tam, kde je ten výkon významný.

Diky za potvrzeni, ze se jedna o nesmyslnou hlasku.

Obavam se, ze vlak ujel lidem, kteri nepronikli do podstaty programovani v dynamickych jazycich, protoze timto smerem jde prirozeny vyvoj. Jestli teorii typu nikdo krom zneuznanych geniu nechape, neni to nic jineho nez zdroj chyb a slepy (protichudny) smer vyvoje, ktery vede ke zjednodusovani programovani.

Neni to blbost, jen na to nemas argument. Typicky padaji programy napsane v C, prestoze maji staticke typy a prolezly kompilatorem, protoze to navzdory tvemu presvedceni nic nyznamena. Vyssi programovaci jazyky zpravidla nepadaji, maji automatickou spravu pameti a byvaji rizene ukoncovany vyjimkami, ktere je snadne zachytit a osetrit. Pro vytvareni stabilnich programu je to evidentne lepsi pristup, nez staticky kompilovane C. Kdyby se webove stranky skriptovaly v C misto v JS, byly by rychlejsi, ale prohlizec by neustale padal, nebylo by to pouzitelne. Kompilovany jazyk se statickymi typy neni sam o sobe zarukou bezchybnosti, spolehlivosti ani pouzitelnosti.