Co si myslíte o OOP?

[Kadet]

Staticka kontrola je dobra k tomu, ze overi, ze zadna funkce nedostane argument spatnyho typu. Tj. overi, ze struktura programu je spravne, ale neoveri semantiku, tj. takovy ry pripady kdy muzu ve funkci f(vaha: int, vyska: int) v klidu zamenit oba argumenty a typova kontrola mi to neodhali. To je uz pak o discipline programatora jestli na to pouzije typy nebo si na to napise testy. Kazdopadne staticka typova kontrola neni vselek proti vsem chybam.

Problem, kdy funkce dostane spatny argument, je dle me zpusobeny prasecim kodem s prilisnym vetvenim. Tj. pokud napisu v pythonu program co bere jeden typ argumentu, dela jednu vec ale zato spravne, pak mi staci jeden integracni test, co mi to dostatecne overi. Bud aplikace na testu slitne nebo ne.

Samozrejme kdyz nekdo prilis vetvi program (aka praseci kod), bude mit hodne prace s psanim testu nebo muze rovnou pouzit statickou kontrolu. Opet, vyresi to jenom strukturalni chyby, ne semanticke, takze za me je lepsi nepsat praseci kod.

[Reklama]

[operator]

Ja vedel ze to najdu, zajimalo me, kdo s touto vtipnou tezi prisel. A citoval jsem spatne, nebylo to v podstate, ale obecne.

... největší rozdíl vidím v dokumentaci.

Mě teda oslovilo compile time. 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á.

Tam patřilo spíš "Zatímco u dynamického jazyka mi furt něco padá." Už jsem psal, že dynamické typování není pro každého. Je nutné si nejen držet určitou kázeň, ale i pokrýt jednotku testy.

řekl byste tedy, že programování v dynamických jazycích (python, js) je náročnější než ve statických (haskell, pascal)?

Jak se říká, Easy to Learn, Hard to Master. Začátky s pythonem a js jsou snazší, ale plné porozumění, zvláště u poměrně komplexního pythonu, je rozhodně náročné.

[Kit]

Tam patřilo spíš "Zatímco u dynamického jazyka mi furt něco padá." Už jsem psal, že dynamické typování není pro každého. Je nutné si nejen držet určitou kázeň, ale i pokrýt jednotku testy.

řekl byste tedy, že programování v dynamických jazycích (python, js) je náročnější než ve statických (haskell, pascal)?

Naopak. Programování v dynamicky typovaných jazycích je jednodušší a bezpečnější, protože se neopíjíš iluzí, že tě typový systém ochrání před chybami.

[BoneFlute]

řekl byste tedy, že programování v dynamických jazycích (python, js) je náročnější než ve statických (haskell, pascal)?

Záleží náročnější na co.

Dynamické jazyky mají snadnej rozjezd. Nic tě nebrzdí. Nemusíš nic umět. Píšeš rychle, a aplikace utěšeně narůstá. IMHO s velikostí aplikace se to má tendenci bortit. Protože ti taky nic moc nepomáhá.

Co se týče statických jazyků, tak Pascal bych sem netahal. U Haskellu je to tak, že tě furt ten kompilátor komanduje. Což může být flustrující. Je těžší rozjezd, protože člověk se musí naučit pár těch záležitostí kolem typů. Ale když už ten kompilátor ukecáš, tak to většinou dost drží. Někdo porovnával na nějaké aplikaci Clojure a Haskell. A říkal, že je to cca stejný. Akorád v tom Haskellu je to pak tak nějak jakože do betonu zalité.

Dobré ohlasy má Rust, který by měl být poněkud netradičnější, ale se silnými typy. Žel zatím jsem neměl tak velkou možnost se mu věnovat.

Je zajímavé, že u většiny dynamických jazyků se dříve či později objeví tendence přidat tomu statickou typovou kontrolu (Javascript, Python). Proč asi.

[operator]

typová kontrola před spuštěním je statická typová kontrola

To nerozporuji, ale nepotrebuji k ni staticke typy.

to mi vůbec nedává smysl, asi radší půjdu programovat

Statickou typovou kontrolu lze provest i nad dynamickymi typy. Python umoznuje provest takovou kontrolu a presto je to porad dynamicky jazyk. A priklad jsem zde uvedl.

[Reklama]

[Dor]

Paráda. Tákže:

Napr. zapouzdreni je vlastnost modulovyho systemu. Ktery si lidi casto pletou s objektovym. Nebo je to treba taky totez.

Imho znepřístupňovat vlastnosti a funkcionalitu má smysl na úrovni modulů i na úrovni tříd. Jsem zvyklý při zapouzdřování myslet hlavně na to znepřístupňování na úrovni tříd, ale musí se s tím velmi opatrně. Špatně se to pak jednotkově testuje (což se dá většinou obejít), ale hlavně to často není potřeba, pokud se dodržuje SRP.

Polymorfismus je zalezitost typovyho systemu. V dynamickym jazyku me tohle netrapi, ve statickym musim mit po ruce interfacy nebo abstraktni tridy.

V dynamickém jazyku mě právě trápí, že ten interface kolegové často použít nemusí a tím se zhoršuje orientace v kódu.

OO navrh je staticky pohled na relace mezi objekty. Taky znamo jako ER diagram.

Dostal jsi mě. Ale víš co jsem myslel.

Design patterny tohohle typu jsou take znamy jako 'chybejici vlastnost jazyka'. Tj. napr. namisto factory patternu muzu pouzit proste obycejnou funkci.

Viz http://wiki.c2.com/?AreDesignPatternsMissingLanguageFeatures

Asi úplně nerozumím argumentu. Místo factory patternu můžu použít i obyčejnou funkci. Můžu i nalinkovat funkčnost zkompilovanou z assembleru. Jsem programátor. Můžu cokoliv.

Dependency injection znamena 'posli mi objekt jako parametr, at si ho nemusim vytvaret sam'.

Tak hlavně by mělo platit, že ho nemůžu vytvářet sám. Protože v různých situacích chci různé implementace toho samého rozhraní. Tam kde ten objekt potřebuji, tak tam se nechci starat o to, jaká ta implementace to bude. Např. mock při jednotkovém testování. Nebo implementace pro konkrétní databázi, jako je to např v PDO v PHP.

Popravde benefit pouzivani principu SOLID jsem nikdy moc nepochopi, treba mi to nekdo vysvetli na prikladu. Stejne tak jsem nikdy neprisel na to, proc navrhovat aplikace timto komplexnim zpusobem co pouziva milion hierarchii a rozhrani. Podle me je takovych systemu poskrovnu, napr. operacni system nebo GUI.

SOLID je celá sada doporučení a težko se udělá příklad do jednoho komentáře. Ale benefity jsou např: Snadná znovupoužitelnost již naprogramovaného. Dobře testovatelné jednotkovými testy. Minimalizace stavů, kdy opravou jedné funkcionality rozbiji jinou.

Ale samozřejmě OOP může být dobrý sluha ale velmi zlý pán.

[v]

typová kontrola před spuštěním je statická typová kontrola

To nerozporuji, ale nepotrebuji k ni staticke typy.

to mi vůbec nedává smysl, asi radší půjdu programovat

Statickou typovou kontrolu lze provest i nad dynamickymi typy. Python umoznuje provest takovou kontrolu a presto je to porad dynamicky jazyk. A priklad jsem zde uvedl.

vybavuju si jenom příklad s typovýma anotacema

[operator]

typová kontrola před spuštěním je statická typová kontrola

To nerozporuji, ale nepotrebuji k ni staticke typy.

to mi vůbec nedává smysl, asi radší půjdu programovat

Statickou typovou kontrolu lze provest i nad dynamickymi typy. Python umoznuje provest takovou kontrolu a presto je to porad dynamicky jazyk. A priklad jsem zde uvedl.

vybavuju si jenom příklad s typovýma anotacema

Však to je ono.

[Kadet]

řekl byste tedy, že programování v dynamických jazycích (python, js) je náročnější než ve statických (haskell, pascal)?

Záleží náročnější na co.

Dynamické jazyky mají snadnej rozjezd. Nic tě nebrzdí. Nemusíš nic umět. Píšeš rychle, a aplikace utěšeně narůstá. IMHO s velikostí aplikace se to má tendenci bortit. Protože ti taky nic moc nepomáhá.

Co se týče statických jazyků, tak Pascal bych sem netahal. U Haskellu je to tak, že tě furt ten kompilátor komanduje. Což může být flustrující. Je těžší rozjezd, protože člověk se musí naučit pár těch záležitostí kolem typů. Ale když už ten kompilátor ukecáš, tak to většinou dost drží. Někdo porovnával na nějaké aplikaci Clojure a Haskell. A říkal, že je to cca stejný. Akorád v tom Haskellu je to pak tak nějak jakože do betonu zalité.

Dobré ohlasy má Rust, který by měl být poněkud netradičnější, ale se silnými typy. Žel zatím jsem neměl tak velkou možnost se mu věnovat.

Je zajímavé, že u většiny dynamických jazyků se dříve či později objeví tendence přidat tomu statickou typovou kontrolu (Javascript, Python). Proč asi.

S tim betonem je to dobry prirovnani.

U dynamickych jazyku se objevi tendence pridat typovou kontrolu (optional types) a u statickych pridat na dynamicnosti (type holes). Otazka je jestli je nejaka zlata cesta uprostred.

V rustu jsem delal a pokud se to podari napsat, ma v to clovek duveru ze to neslitne na nejakym okrajovym pripade. Ze to vyplazne semanticky spatnej vysledek mam asi podobnlu duveru jako kdyz to napisu v pythonu.

V rustu je peklo napsat jakoukoliv cyklickou datovou strukturu. Graf, strom s pointrem na rodice, apod. V haskellu se mi to ani nildy nepovedlo, protoze je z principu imutabilni. Urcite existuje nejaly magicky trik jak tyhle problemy v haskellu resit, ale nemam na ne cas, protoze chci resit problemy a ne hadanky jak to udelat.

[BoneFlute]

A hlavne, i kdyz pada, tak jen na semanticke chyby

Nikoliv. Padá to na syntaktické či logické chyby. Jako třeba na to, že do metody očekávající dict {street: "", city:""} pošlu: {name: "", surname:"", address: {street: "", city:""}}.

[BoneFlute]

Ze to vyplazne semanticky spatnej vysledek mam asi podobnlu duveru jako kdyz to napisu v pythonu.

Nikdy jsem netvrdil opak.

V rustu je peklo napsat jakoukoliv cyklickou datovou strukturu. Graf, strom s pointrem na rodice, apod. V haskellu se mi to ani nildy nepovedlo, protoze je z principu imutabilni. Urcite existuje nejaly magicky trik jak tyhle problemy v haskellu resit

Většinou jsem se bez cyklické struktury obešel.
V Haskellu by to nemusel být problém, pokud nechceš pointer. Něco jako:

Kód: [Vybrat]

data Node = Node {pk: Int, val: String, links: [Node]}
Vycházíš z toho, že:

Kód: [Vybrat]

(Node 42 "text") == (Node 42 "text")protože na pointery se nehraje.

[v]

typová kontrola před spuštěním je statická typová kontrola

To nerozporuji, ale nepotrebuji k ni staticke typy.

to mi vůbec nedává smysl, asi radší půjdu programovat

Statickou typovou kontrolu lze provest i nad dynamickymi typy. Python umoznuje provest takovou kontrolu a presto je to porad dynamicky jazyk. A priklad jsem zde uvedl.

vybavuju si jenom příklad s typovýma anotacema

Však to je ono.

tak to je rozpor - anotace / "nepotrebuji k ni staticke typy"

[operator]

A hlavne, i kdyz pada, tak jen na semanticke chyby

Nikoliv. Padá to na syntaktické či logické chyby. Jako třeba na to, že do metody očekávající dict {street: "", city:""} pošlu: {name: "", surname:"", address: {street: "", city:""}}.

Logicke chyby povazuji za podmnozinu semantickych, a jak to pada po prelozeni se syntaktickymi, to bych chtel videt.

[BoneFlute]

A hlavne, i kdyz pada, tak jen na semanticke chyby

Nikoliv. Padá to na syntaktické či logické chyby. Jako třeba na to, že do metody očekávající dict {street: "", city:""} pošlu: {name: "", surname:"", address: {street: "", city:""}}.

Logicke chyby povazuji za podmnozinu semantickych

Tak to považuješ chybně.

[v]

V rustu je peklo napsat jakoukoliv cyklickou datovou strukturu. Graf, strom s pointrem na rodice, apod. V haskellu se mi to ani nildy nepovedlo, protoze je z principu imutabilni. Urcite existuje nejaly magicky trik jak tyhle problemy v haskellu resit, ale nemam na ne cas, protoze chci resit problemy a ne hadanky jak to udelat.

tohle je zajímavé téma! znám asi tři přístupy, reference v IO/ST atd, knot tying (velká sranda!) a u grafů to zajímavě řeší algebraické grafy (http://hackage.haskell.org/package/algebraic-graphs)