Fórum Root.cz

Hlavní témata => Vývoj => Téma založeno: petersonoop 22. 12. 2018, 23:20:25

Název: Co si myslíte o OOP?
Přispěvatel: petersonoop 22. 12. 2018, 23:20:25
Je potreba to vsade pretlacat? Je potreba zakazdym vidiet nejaky nejaku navrhovy vzor? Treba to hnat az do velkych abstrakcii aj ked netreba?
Název: Re:co si myslite o oop?
Přispěvatel: Kit 22. 12. 2018, 23:29:43
OOP je užitečnou metodikou pro udržení pořádku v kódu. Pokud OOP někdo chybně pochopí, tak se mu ten kód naopak zesložití.
Název: Re:co si myslite o oop?
Přispěvatel: Mirek Prýmek 22. 12. 2018, 23:33:54
Jenom to nejhorsi :)
Název: Re:co si myslite o oop?
Přispěvatel: Industry 4.0 22. 12. 2018, 23:57:07
Jako toto https://www.youtube.com/watch?v=qmuFlaFYdgE ?
Název: Re:co si myslite o oop?
Přispěvatel: Kadet 23. 12. 2018, 03:59:41
Lidi ze stary skoly by o dnesnim java nebo c++ oop rekli ze si nekdo spletl objekty a moduly. Hint. private a public apodobny modifikatory pro objekty, pritom to je zalezitost modulu a balicku.

Smalltalk nebo Self pouzivaly oop pro navrh vnitrnosti jazyka, a to je asi tak jediny kde se daji oop principy pouzit. Skutecne explicitni oop by repeezentoval Erlang a jeste explicitnejsi Event Sourcing.
Název: Re:co si myslite o oop?
Přispěvatel: dfasdfasdf 23. 12. 2018, 07:20:30
OOP je nastroj, bud ho pouzijes dobre, nebo blbe.
OOP neni svaty gral.
Název: Re:co si myslite o oop?
Přispěvatel: kamen 23. 12. 2018, 08:03:16
OOP je sprosta, skodliva a necitliva antropomorfizace pocitacu!

Pryc s ni. #MEETOOP!
Název: Re:co si myslite o oop?
Přispěvatel: dfasdfasdf 23. 12. 2018, 08:12:39
OOP je sprosta, skodliva a necitliva antropomorfizace pocitacu!

Pryc s ni. #MEETOOP!

to je celkem vtipny komentar, ale proc antropomorfizace???
objekt neni nijak zavisly na lidskych vlastnostech, objekt je proste jen nejaka struktura.
i mimozemstani muzou klasifikovat veci a objekty.
Název: Re:co si myslite o oop?
Přispěvatel: petersonoop 23. 12. 2018, 08:34:27
Jenom to nejhorsi :)
Preco to najhorsie?
Ma oop za nasledok zhorsenie performance aplikacie? Ak teda zoberiem c# a javu do uvahy, tak o oop nemozno hovorit, len o akomsi napodobneni.
Co dizajn patterny? Idu ruka v ruke s oop, pretlacate ich?
Název: Re:co si myslite o oop?
Přispěvatel: anonym 23. 12. 2018, 09:13:43
Je treba si uvedomit, ze OOP neni bud a nebo, tak jako spousta dalsich veci, ale je to spise skala, muzes to pouzivat v ruzne intenzite. Kdysi se to v Jave pouzivalo az presprilis, ale prislo se na to, ze to tak dobre neni a zmirnilo se to. V Jave i diky tomu, ze se zacal hodne pouzivat Inversion of Control, coz udelalo architekturu vice plochou - rikam tomu plocha architektura jako protiklad k super sofistikovane architekture nebo jak to nazvat. V ploche architekture se dobre orientuje.

Jen bych chtel zminit takovou drobnost ktera se tyka abuzu polymorfismu. A nebo obecneji, na abuzu zobecnovani - protoze polymorfizmus je zobecnovani. To by cloveka treba nenpadlo, ze neco takoveho existuje, nez dojde na velky zabordelovany projekt, kde se hojne vyuziva polymorfizmus - on totiz dokaze uplne znicit statickou analyzu kodu metodou generovani method call hierarchiii, coz je extremne dulezity nastroj pro orientaci v kodu. Tzn. ja se ridim tim, ze kdyz neni nutne abstrahovat, tak to nedelam, ikdyz to udelat jde. Drive jsem si myslel, ze musim abstrahovat automaticky, kdyz to jde. Ono neni zase tak spatne napsat toho kodu trochu vic, nez by se muselo, pokud to povede k citelnejsimu programu jako celku.
Název: Re:co si myslite o oop?
Přispěvatel: CoffeeMan 23. 12. 2018, 09:33:23
Já se teda domnívám, že OOP byl a je pěkný xindl. A to se dala Jásiru Arafatovi ještě Nobelova cena míru.  8)
Název: Re:co si myslite o oop?
Přispěvatel: dfasdfasdf 23. 12. 2018, 09:39:42
Já se teda domnívám, že OOP byl a je pěkný xindl. A to se dala Jásiru Arafatovi ještě Nobelova cena míru.  8)

dobry, ale tady se diskutuje Object Oriented Programing a ne rucnikari.
Název: Re:co si myslite o oop?
Přispěvatel: Kit 23. 12. 2018, 10:09:34
Jen bych chtel zminit takovou drobnost ktera se tyka abuzu polymorfismu. A nebo obecneji, na abuzu zobecnovani - protoze polymorfizmus je zobecnovani. To by cloveka treba nenpadlo, ze neco takoveho existuje, nez dojde na velky zabordelovany projekt, kde se hojne vyuziva polymorfizmus - on totiz dokaze uplne znicit statickou analyzu kodu metodou generovani method call hierarchiii, coz je extremne dulezity nastroj pro orientaci v kodu. Tzn. ja se ridim tim, ze kdyz neni nutne abstrahovat, tak to nedelam, ikdyz to udelat jde. Drive jsem si myslel, ze musim abstrahovat automaticky, kdyz to jde. Ono neni zase tak spatne napsat toho kodu trochu vic, nez by se muselo, pokud to povede k citelnejsimu programu jako celku.

Polymorfismus je naopak velmi užitečný. Nevidím důvod, proč by měl ničit statickou analýzu. Vždyť každý polymorfní objekt musí správně implementovat použité rozhraní. Kontrola je z obou stran.
Název: Re:co si myslite o oop?
Přispěvatel: Martin 23. 12. 2018, 10:22:30
Cargo kult. Tedy aspon v nasi firme.
Název: Re:co si myslite o oop?
Přispěvatel: dfasdfasdf 23. 12. 2018, 10:24:37
Cargo kult. Tedy aspon v nasi firme.

nejake vtipne detaily z nataceni mas?
Název: Re:co si myslite o oop?
Přispěvatel: Martin 23. 12. 2018, 10:40:01
Cargo kult. Tedy aspon v nasi firme.
nejake vtipne detaily z nataceni mas?
Implementace C interface (exportovane funkce z DLL/SO), kazda funkce vypada takto:
int "C" DELEJ_NECO(void *p,<...>)
{
   CONTEXT_CLASS *pc = (CONTEXT_CLASS *)p;
   return pc->delej_neco(<...>);
}
kde CONTEXT_CLASS je sice trida, ale pouziva se jen jako struct, nemame virtualni/override metody, nepouzivame vyjimky (kvuli problemum s C++ runtime na nekterych platformach). Nevyuziva se tedy zadna vyhoda C++, ale je to C++ s objekty.
Vlastni C++ metody jsou kratke, mnohem prehlednejsi by bylo dat implementaci primo do DELEJ_NECO().
Mam v ruce kladivo a tak je vsechno hrebik :-)
Název: Re:co si myslite o oop?
Přispěvatel: JSH 23. 12. 2018, 11:11:54
OOP je sprosta, skodliva a necitliva antropomorfizace pocitacu!

Pryc s ni. #MEETOOP!

to je celkem vtipny komentar, ale proc antropomorfizace???
objekt neni nijak zavisly na lidskych vlastnostech, objekt je proste jen nejaka struktura.
i mimozemstani muzou klasifikovat veci a objekty.
Myslím že tuším, co má na mysli. V původním OOP (třeba Smalltalk) jsou objekty něco, co přijímá požadavky a nějak je řeší. Těm objektům se nevolají přímo metody ale posílají jim zprávy, co je třeba udělat. Myslím, že daleko lepší název by byl "service" nebo možná i "actor" něco podobného. Na rozdíl od Javovských objektů jsou ty Smalltalkovské daleko autonomnější.
Je tam opravdu velký rozdíl mezi normálními a OOP objekty. Třeba "cihla" není moc dobrý OOP objekt a posílat jí nějakou zprávu dává smysl jen v jazyce který nic jiného neumožňuje.
Název: Re:co si myslite o oop?
Přispěvatel: petersonoop 23. 12. 2018, 11:26:15
Polymorfizmus je celkom performance hit
Název: Re:co si myslite o oop?
Přispěvatel: Kit 23. 12. 2018, 11:48:16
Polymorfizmus je celkom performance hit

Právě naopak. S masivním využitím polymorfismu se mé skripty nejen zpřehlednily, ale i zrychlily.
Název: Re:co si myslite o oop?
Přispěvatel: balki 23. 12. 2018, 11:57:20
OOP je nastroj, bud ho pouzijes dobre, nebo blbe.
OOP neni svaty gral.

lubim ta  :-*. tesat do kamena.
Název: Re:co si myslite o oop?
Přispěvatel: petersonoop 23. 12. 2018, 12:19:28
Polymorfizmus je celkom performance hit

Právě naopak. S masivním využitím polymorfismu se mé skripty nejen zpřehlednily, ale i zrychlily.
No ty teda dobre trepes :)
Název: Re:co si myslite o oop?
Přispěvatel: Bacsa 23. 12. 2018, 12:24:14
Jenom to nejhorsi :)
Preco to najhorsie?
Prýmek je místní übertroll.
Název: Re:co si myslite o oop?
Přispěvatel: CoffeeMan 23. 12. 2018, 12:31:33
Já se teda domnívám, že OOP byl a je pěkný xindl. A to se dala Jásiru Arafatovi ještě Nobelova cena míru.  8)

dobry, ale tady se diskutuje Object Oriented Programing a ne rucnikari.

A co když v OOP mají programátory, kteří dělají OOP? ???
Název: Re:co si myslite o oop?
Přispěvatel: Jan Forman 23. 12. 2018, 12:45:29
Dle mého dává smysl u velkých monolitických oblud. Pokud máte microservices, už to žádné velké benefity nemá.
Zase to tam není složité, takže lze použít i tam. Pokud tu monolitickou zrůdu rozmlátíte na kousky, taky nemusí být objektová.

Preferuju všechno rozsekané na malé kousky :) pak je mi naprosto jedno v čem to je napsané.
Název: Re:co si myslite o oop?
Přispěvatel: petersonoop 23. 12. 2018, 12:49:07
Ja pracujem na projekte kde oop je dost zastupene a tolko abstrakcie som este nikde nevidel a mam pocit, ze je to niekedy az prekomplikovane a uplne zbytocne.
Název: Re:co si myslite o oop?
Přispěvatel: Kadet 23. 12. 2018, 12:50:54
Dokazal byste nekdo nadefinovat oop? Lidi se tu ztraci v semantice.
Název: Re:co si myslite o oop?
Přispěvatel: ldj 23. 12. 2018, 12:51:13
Dle mého dává smysl u velkých monolitických oblud. Pokud máte microservices, už to žádné velké benefity nemá.
Zase to tam není složité, takže lze použít i tam. Pokud tu monolitickou zrůdu rozmlátíte na kousky, taky nemusí být objektová.

Preferuju všechno rozsekané na malé kousky :) pak je mi naprosto jedno v čem to je napsané.
Monolit neni antipattern :) A nejsou microservices vicemene OOP prevedene do distribuovaneho systemu service(object) a zasilani zprav? :)
Název: Re:co si myslite o oop?
Přispěvatel: Mirek Prýmek 23. 12. 2018, 13:07:22
Preco to najhorsie?
Ma oop za nasledok zhorsenie performance aplikacie? Ak teda zoberiem c# a javu do uvahy, tak o oop nemozno hovorit, len o akomsi napodobneni.
Myslel jsem to "mainstream OOP" (C++, Java apod.)

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.

Už samotný modelování světa jako množiny jakýchsi (ontologických) entit, které mají jakési vlastnosti, je problematické. Je založeno na tom, že existuje jakási "prázdná identita", která je potom "věšákem na vlastnosti". Ve skutečném světě je ale spousta jevů, kde žádné identity neexistují a vznikají všelijaké ad-hoc shluky jevů a vlastností (triviální příklad jsou třeba korály nebo shluky nějakých bakterií, kde výraz "jedinec" moc nedává smysl, tím spíš jedinec, který by měl být "věšákem na vlastnosti").

Ale ok, tohle ještě beru, že je 1. celkem užitečný model 2. ve většině případů to funguje uspokojivě 3. víceméně to opdovídá tomu, jak si běžně svět konceptualizujeme.

Zásadní problém je ale v tom, že "mainstream OOP" příšerně zfetišizovalo dědičnost. Vytvořila se představa, že pojmy (nedejmatkopřírodo dokonce ty ontologické entity) tvoří hierarchii danou množinami vlastností individuí. A protože lidi uvěřili, že to je tak "přirozeně", začali se snažit pojmy (nedejmatkopřírodo entity) do těch hierarchií rvát. Na sílu. A z toho pak plynou ty dementní nekonečné debaty, jestli má čteverec dědit z obdélníka nebo naopak. Totální ztráta času. Evidentní střelení se do nohy.

Naštěstí se tahle debilita časem trochu utlumila a modernější přístup je spíš skládání vlastností bez potřeby hierarchizace (mixiny, interfejsy apod.). To je daleko lepší přístup, který nevede k nesmyslným slepým uličkám, kde se jazyk zabývá víc sám sebou než tím, co by měl řešit. A btw, je to návrat ke kořenům, protože původní OOP dědičnost nefetišizovalo, AFAIK.
Název: Re:co si myslite o oop?
Přispěvatel: Kiwi 23. 12. 2018, 13:07:40
Dokazal byste nekdo nadefinovat oop? Lidi se tu ztraci v semantice.
Ne. Každý si pod tím představuje trochu něco jiného. Pro mě to je to, co tím mysleli otcové-zakladatelé, tj. Alan Kay a spol.
Název: Re:co si myslite o oop?
Přispěvatel: Mirek Prýmek 23. 12. 2018, 13:18:31
Ne. Každý si pod tím představuje trochu něco jiného. Pro mě to je to, co tím mysleli otcové-zakladatelé, tj. Alan Kay a spol.
Tomu se dneska (bohužel) říká spíš "agentní systém" nebo "actor model".
Název: Re:co si myslite o oop?
Přispěvatel: oss 23. 12. 2018, 13:29:00
Boze, toto tu je ciste trolenie bez argumentov.
fakt zboznujem ludi co sa vyjadruju o OOP a pri tom v nom nevedia kodit (vid priklad hore, to je antoipatern OOP).
Ale dnes je modrene nadavat na vsteko co ako tak funguje a dava zmysel.
Název: Re:co si myslite o oop?
Přispěvatel: Kiwi 23. 12. 2018, 13:46:46
Ne. Každý si pod tím představuje trochu něco jiného. Pro mě to je to, co tím mysleli otcové-zakladatelé, tj. Alan Kay a spol.
Tomu se dneska (bohužel) říká spíš "agentní systém" nebo "actor model".
Proto tvrdě prosazuji návrat k tomu původnímu smyslu. Pro to byl ten název vymyšlen. Že tím dnes většina lidí myslí C++ nebo Javu je jen důkazem, že to celé vůbec nepochopili (včetně tvůrců těch jazyků). Současné mainstreamové pojetí je cargo kult jak vyšitý.
Název: Re:co si myslite o oop?
Přispěvatel: JSH 23. 12. 2018, 13:53:20
Ne. Každý si pod tím představuje trochu něco jiného. Pro mě to je to, co tím mysleli otcové-zakladatelé, tj. Alan Kay a spol.
Tomu se dneska (bohužel) říká spíš "agentní systém" nebo "actor model".
Proto tvrdě prosazuji návrat k tomu původnímu smyslu. Pro to byl ten název vymyšlen. Že tím dnes většina lidí myslí C++ nebo Javu je jen důkazem, že to celé vůbec nepochopili (včetně tvůrců těch jazyků). Současné mainstreamové pojetí je cargo kult jak vyšitý.
Ono to taky vychází z toho, že si vybrali fakt blbý název. Všude kromě OOP se "objekt" říká něčemu, co rozumí akorát tak zprávě "zůstaň". Jestli by nebylo lepší se vrátit k původní myšlence s nějakým lepším jménem. :)
Název: Re:co si myslite o oop?
Přispěvatel: Kadet 23. 12. 2018, 13:59:41
Dokazal byste nekdo nadefinovat oop? Lidi se tu ztraci v semantice.
Ne. Každý si pod tím představuje trochu něco jiného. Pro mě to je to, co tím mysleli otcové-zakladatelé, tj. Alan Kay a spol.

Alan Kay ma svoji definici kterou neustale omila a nikdo ji nechape. Precet jsem o tom neapocer jeho komentaru i posledni clanky na quore a HN kam prispiva. Rad bych, aby tu jeho definici nekdo tady vysvetlil, nez se budem bavit dal.
Název: Re:co si myslite o oop?
Přispěvatel: Kit 23. 12. 2018, 14:03:18
Ja pracujem na projekte kde oop je dost zastupene a tolko abstrakcie som este nikde nevidel a mam pocit, ze je to niekedy az prekomplikovane a uplne zbytocne.

Také jsem dělal na projektu, ve kterém byla použita čtyřúrovňová dědičnost, ve které prarodičem byla třída Config. No prostě hnus. A když jsem se ozval, že je to kravina, tak se to vedení nelíbilo.
Název: Re:co si myslite o oop?
Přispěvatel: Mirek Prýmek 23. 12. 2018, 14:07:16
Jestli by nebylo lepší se vrátit k původní myšlence s nějakým lepším jménem. :)
No to je právě ten "agent" nebo "actor" :) Lepší je imho "actor". Sice to zní trochu exoticky, ale "agent" na sebe nabaluje speciální význam, který mu byl dán v podoboru "multiagentní systémy" (takže různé ty komunikační jazyky KQML, ACL, sémantiky/ontologie atd.)

Když místo "programuju objektově" řekneš "programuju pomocí actorů", bude jasný, že nemyslíš to zparchantělý rádobyOOP :)
Název: Re:co si myslite o oop?
Přispěvatel: Kiwi 23. 12. 2018, 14:08:26
Dokazal byste nekdo nadefinovat oop? Lidi se tu ztraci v semantice.
Ne. Každý si pod tím představuje trochu něco jiného. Pro mě to je to, co tím mysleli otcové-zakladatelé, tj. Alan Kay a spol.

Alan Kay ma svoji definici kterou neustale omila a nikdo ji nechape. Precet jsem o tom neapocer jeho komentaru i posledni clanky na quore a HN kam prispiva. Rad bych, aby tu jeho definici nekdo tady vysvetlil, nez se budem bavit dal.
Se mi líbí, jak když někdo něco nepochopí, tak tvrdí, že to "nikdo" nechápe. Čemu přesně nerozumíš?
Název: Re:co si myslite o oop?
Přispěvatel: Kadet 23. 12. 2018, 14:54:14
To je dobre ze tomu nekdo jako ty rozumi.
Vysvetli mi tedy

- svoji definici oop
- priklad systemu co hodne lidi zna co je oop
- na ktery pripady bys pouzil oop jestli vubec
- kterej programovaci jazyk je skutecne oop. Nebo kterej byl jestli vubec kdy byl
Název: Re:co si myslite o oop?
Přispěvatel: Kiwi 23. 12. 2018, 15:20:08
To je dobre ze tomu nekdo jako ty rozumi.
Vysvetli mi tedy

- svoji definici oop
- priklad systemu co hodne lidi zna co je oop
- na ktery pripady bys pouzil oop jestli vubec
- kterej programovaci jazyk je skutecne oop. Nebo kterej byl jestli vubec kdy byl
- objekt jako černá krabička, která může mít stav, přijímá a vysílá zprávy, pomocí nichž interaguje s okolím; množina zpráv na něž reaguje a způsob jak tak činí je čistě v gesci objektu (může se to v čase i měnit)
- použil bych ho u problémů, které se přirozeně rozpadají na autonomní podproblémy a je účelné je na tyto autonomní jednotky separovat z důvodů přehlednosti, substituovatelnosti, znovupoužitelnosti a testování
- Smalltalk
Název: Re:co si myslite o oop?
Přispěvatel: JSH 23. 12. 2018, 15:35:46
- použil bych ho u problémů, které se přirozeně rozpadají na autonomní podproblémy a je účelné je na tyto autonomní jednotky separovat z důvodů přehlednosti, substituovatelnosti, znovupoužitelnosti a testování
Popravdě, tohle toho moc neříká. Dělit problémy na menší a jednodušší kusy se snaží úplně všechna paradigmata. Je to akorát rozkecané "použil bych ho tam, kde se hodí". Někdo, komu OOP několikrát nebouchlo do obličeje, ví kulové, kdy je to účelné a kdy není.
Název: Re:co si myslite o oop?
Přispěvatel: rigormortiz 23. 12. 2018, 15:42:37
Prijde mi, ze do jiste miry je spise problem business logic nez OOP jako takove. Ono to totiz svadi prevadet "firemni procesy" do "trid" a reflektovat/popisovat realitu v programovacim jazyku.

Bez ohledu na to jaky mate oblibeny programovaci jazyk doporucuju bez predsudku precist a nechat se treba i inspirovat:

https://rubyonrails.org/doctrine/
http://trailblazer.to/ potazmo http://trailblazer.to/gems/cells/

Filozofie neni vylozene zavisla na jazyku, tak snad aspon nekomu to rozsiri obzory. Kdyz se spravne nacrtne business logika a rozume se to prevede do OOP tak polymorfizmus je rozhodne dobry pristup, jenom se to nesmi prehanet, protoze pak opravdu muze dojit ke snizeni citelnosti nebo testovatelnosti kodu. Proste vseho s mirou a "overthinking" je fakt problem hodne lidi.

Ja doufam, ze vetsina je aspon trochu rozumna a chape, ze krasnej a citelnej kod nemusi bejt zrovna ten nejefektivnejsi. Dalsi oblibena vec je "code reusability" coz neni uplne sranda udelat, aby se vam to po pridani par novejch ficurek nezacalo rozpadat nebo molochovatet. Dalsi kamen urazu, ze kteryho obvinuju vetsinou "byznysaky", ze PoC neni produkt. Sice zbastlite za par hodin neco co by chteli, ale muze trvat dny i tydny to naimplementovat spravne, jenze vime jak to je s "pridelovanim prostredku". Treba VW a jejich pr**er s "klicema" .... Aneb z PoC jsme udelali produkt. Gratuluju.

Jinak vidime to napr. i v Linuxu, prechod od init scriptu k systemd nebo treba v gnome, kdy gconf je do jiste miry lehka forma registru podobne jak ve windowsech. Proste kdyz vam aplikace roste tak v urcite fazi nechcete mit vsechno v tisici konfigurakach kde ma kazdej dva az tri radky, jelikoz mate vysoce modularni pristup. Nakonec to soupnete nekam do "databaze", aby se vam s tim lip pracovalo. Cili ten pristup je definovanej velikosti aplikace a jejim designem (monolith vs atomic) atd. ....
Název: Re:co si myslite o oop?
Přispěvatel: Kiwi 23. 12. 2018, 15:44:44
- použil bych ho u problémů, které se přirozeně rozpadají na autonomní podproblémy a je účelné je na tyto autonomní jednotky separovat z důvodů přehlednosti, substituovatelnosti, znovupoužitelnosti a testování
Popravdě, tohle toho moc neříká. Dělit problémy na menší a jednodušší kusy se snaží úplně všechna paradigmata. Je to akorát rozkecané "použil bych ho tam, kde se hodí". Někdo, komu OOP několikrát nebouchlo do obličeje, ví kulové, kdy je to účelné a kdy není.
To ano, ale tady jsem měl na mysli právě tu autonomii. Že sám o sobě je ten objekt "životaschopný". Pokud použiju klasickou strukturovanou dekompozici, tak toto nezbytně neplatí (dokonce to bude platit málokdy).
Název: Re:co si myslite o oop?
Přispěvatel: Kadet 23. 12. 2018, 15:48:54
To je dobre ze tomu nekdo jako ty rozumi.
Vysvetli mi tedy

- svoji definici oop
- priklad systemu co hodne lidi zna co je oop
- na ktery pripady bys pouzil oop jestli vubec
- kterej programovaci jazyk je skutecne oop. Nebo kterej byl jestli vubec kdy byl
- objekt jako černá krabička, která může mít stav, přijímá a vysílá zprávy, pomocí nichž interaguje s okolím; množina zpráv na něž reaguje a způsob jak tak činí je čistě v gesci objektu (může se to v čase i měnit)
- použil bych ho u problémů, které se přirozeně rozpadají na autonomní podproblémy a je účelné je na tyto autonomní jednotky separovat z důvodů přehlednosti, substituovatelnosti, znovupoužitelnosti a testování
- Smalltalk

Diky, od toho se da odpichnout.

Objekt jako cerna krabicka prijimajici a vysilajici zpravy.

Zastavi se zbytek sveta v case zatimco jeden objekt zpracovava zpravu?

Pokud jo, pak je to oop ve smyslu synchronni simulace. Smalltalk to splnuje. Java a CPP, pokud si odmyslim tu michaninu objektu a modulu, tak taky.

Pokud kazdej objekt funguje nezavisle, tj. ve vlastnim vlakne, s tim ze jeden objekt neblokuje ostatni, tak se tomu rika mimo jine asynchronni simulace, actor model, reaktivni programovani?, gen_server, erlang nebo mikrojadro operacniho systemu.

Alan Kay nekde zminil explicitni cas, proto rikam, ze to co tim svym oop myslel, nikdo nechape. Proto druha otazka. Jak je definovan cas v tomhle oop?

Nejaky systemovy hodiny? Pak je to obycejna real time simulace. Taky se tomu rika operacni system.

Nebo explicitne definovanej cas? Pak se daji vsechny zpravy ktery objekty prijimaji a odesilaji reprezentovat jako data s explicitnim timestampem. Jediny co ukladas jsou tyhle zpravy. To co pak provedou s vnitrnim stavem objektu muzes vzdycky prehrat od zacatku pokud si uchovas log tech zprav. Rika se tomu event sourcing, v databazich write ahead logging, journaling.

A ted moje definice oop. Oop jak ho lidi chapou je management stavu systemu v case. Stav je explicitne ulozen v pameti/disku/databazi a prichozi a odchozi zpravy jsou prchave, tj. fire and forget. Jinak receno staticky pohled na system a da se modelovat pomoci treba UML.

Dualem tohoto pohledu je explicitni uchovavani zprav/eventu v pameti/disku/databazi a stav objektu je prchavy, protoze muze byt vzdy prehran od zacatku historie diky tomu, ze je ulozen log vsech modifikaci jeho stavu. Jinak receno data flow pohled na system.
Název: Re:co si myslite o oop?
Přispěvatel: Bacsa 23. 12. 2018, 15:58:43
- kterej programovaci jazyk je skutecne oop. Nebo kterej byl jestli vubec kdy byl
Objective-C
Název: Re:co si myslite o oop?
Přispěvatel: Kiwi 23. 12. 2018, 16:06:20
IMHO to není třeba stavět takto kategoricky. To zase zavání nějakým dogmatismem. Nikde není řečeno, že musí jít o synchronní nebo o asynchronní model. Nejspíš ve většině případů půjde o synchronní přístup, v případech, kdy je to účelné/nezbytné, si konkrétní objekty budou žít ve vlastním čase. Nevidím moc smysl dělat z toho zbytečnou vědu.

Rozdíl oproti C++like jazykům vidím hlavně v eleganci, s jakou je to řešené. Předně dynamické typování vnímám jako nezbytnost pro objektový přístup. Bez toho podle mě není možné efektivně dosáhnout těch správných efektů, resp. statickým typováním se to všechno šíleně zamotá a znepřehlední. Tím se nabourává ta absolutní autonomie objektů.
Název: Re:co si myslite o oop?
Přispěvatel: rigormortiz 23. 12. 2018, 16:10:50
Kadet,

prijde mi, ze se snazis najit obecne reseni/popis/pristup na pomerne konkretni vec. Coz ti vetsinou nevyjde. Kdyz prirovname ten objekt k cihle, tak s tim pracujes jako s cihlou (nejdriv hezky vedle sebe a pak dalsi radek) otazka zni jestli stejnej objekt pouzijes i na stavbu mrakodrapu (tam bys asi pouzil objekt pilir a stavel ho nahoru a pak okolo nej).

Tahle prednaska by se ti mohla libit: https://www.youtube.com/watch?v=OSGv2VnC0go

Nerikam, ze vystihuje presne to na co se ptas. S tema objektama, vem si ze mas objekt "session" nebo "user" a potom mas nejaky objekt "message" a "log". Na kazdy mozna pouzijes jiny navrhovy vzor. Kdyz se budes snazit implementovat jeden a ten samy na vsechny, nebo najit nejaky super obecny, asi ti to nevyjde.
Název: Re:co si myslite o oop?
Přispěvatel: rigormortiz 23. 12. 2018, 16:17:34
Promin spatnej link: https://www.youtube.com/watch?v=HTLu2DFOdTg

obe ty prednasky jsou dobry.
Název: Re:co si myslite o oop?
Přispěvatel: Kadet 23. 12. 2018, 16:31:30
Kadet,

prijde mi, ze se snazis najit obecne reseni/popis/pristup na pomerne konkretni vec. Coz ti vetsinou nevyjde. Kdyz prirovname ten objekt k cihle, tak s tim pracujes jako s cihlou (nejdriv hezky vedle sebe a pak dalsi radek) otazka zni jestli stejnej objekt pouzijes i na stavbu mrakodrapu (tam bys asi pouzil objekt pilir a stavel ho nahoru a pak okolo nej).

Tahle prednaska by se ti mohla libit: https://www.youtube.com/watch?v=OSGv2VnC0go

Nerikam, ze vystihuje presne to na co se ptas. S tema objektama, vem si ze mas objekt "session" nebo "user" a potom mas nejaky objekt "message" a "log". Na kazdy mozna pouzijes jiny navrhovy vzor. Kdyz se budes snazit implementovat jeden a ten samy na vsechny, nebo najit nejaky super obecny, asi ti to nevyjde.

Pojem oop uz strasi tenhle svet dostatecne , dlouho tak si zaslouzi nejakou definici, at se chudaci juniori maji od ceho odpichnout. Pokud se definice nenajde, protoze si pod tim kazdej predstavuje neco jinyho, tak je to taky dobrej poznatek. Muze se pak celej pojem oop zahodit a vyresi se tim spousta semantickych nedorozumeni.

Jinak ja se bavim o modelovani realnyho sveta. Napr. business problemu. V takovym problemu figuruje cas. Kazdy z techto problemu muze byt namapovan na nejaky reaktivni system. Pokud v systemu nefiguruje cas, pak se da takovy problem reprezentovat pouhou statickou funkci, ktera mapuje vstupy na vystupy. Pak zadny oop neni treba, staci napsat obyc funkci a poskladat ji z mensich funkci atd.

Session je stav systemu v case. Message je explicitni instrukce na update toho stavu. Log je serializovana kolekce messagu v case.

Message i log muzu reprezentovat v nejakym jazyce s oop featurama. Ale otazka je jestli jsem dostatecnej masochista na to abych to udelal. Napr. Proc bych reprezentoval message jako nejakou python classu a pak ji definoval serialize a deserealize metody kdyz muzu pouzit klasickej dict, na kterej mi existuje milion funkci z python ekosystemu.

Kdyz jsme u pythonu, tohle video by reprezentovalo muj pohled.

"Stop writing classes"
https://youtu.be/o9pEzgHorH0

Název: Re:co si myslite o oop?
Přispěvatel: rigormortiz 23. 12. 2018, 16:45:07

Pojem oop uz strasi tenhle svet dostatecne , dlouho tak si zaslouzi nejakou definici, at se chudaci juniori maji od ceho odpichnout. Pokud se definice nenajde, protoze si pod tim kazdej predstavuje neco jinyho, tak je to taky dobrej poznatek. Muze se pak celej pojem oop zahodit a vyresi se tim spousta semantickych nedorozumeni.

Jinak ja se bavim o modelovani realnyho sveta. Napr. business problemu. V takovym problemu figuruje cas. Kazdy z techto problemu muze byt namapovan na nejaky reaktivni system. Pokud v systemu nefiguruje cas, pak se da takovy problem reprezentovat pouhou statickou funkci, ktera mapuje vstupy na vystupy. Pak zadny oop neni treba, staci napsat obyc funkci a poskladat ji z mensich funkci atd.

Podivej se na ten koncept co pouziva Trailblazer (http://trailblazer.to/) a predevsim (http://trailblazer.to/gems/cells/)

Netvrdim, ze to je to nejlepsi a jediny, ale ty koncepcni casti a to jak "uchopili" problem se mi zamlouva. Jenze taky rozumim tomu, ze ne vzdycky to sedi/je mozny podle "modeloveho prikladu". Neboli jestli chces zobecnit "realnej svet" na nejakou tridu/sablonu, neuspejes. Jdu se mrknout na tu prednasku cos poslal, jsem zvedavej. Dik za link.

Kdyz vezmeme v potaz treba onen "log" ve chvili kdy ti to plive nejakej vystup do "souboru" je to asi fuk, ale ve chvili, kdy chces treba pouzit ruzny "system" do kterejch to loguje, prave treba polymorfizmus je na to jak delanej. Cili podle toho jestli je instance of "loguj do sentry" nebo "loguj do souboru" nebo "loguj do graylogu", ohnes to strasne jednoduse a nezabordeli se ti to. Protoze nekde ve tride volas jenom Log.write(message).

Shodou okolnosti ten prvni link co jsem ti poslal na tu prednasku tak tam pan velmi dobre vysvetluje, ze chces vracet iteratable misto dict a nemusis pak delat zbytecny bastleni.
Název: Re:co si myslite o oop?
Přispěvatel: Kadet 23. 12. 2018, 17:03:45

Pojem oop uz strasi tenhle svet dostatecne , dlouho tak si zaslouzi nejakou definici, at se chudaci juniori maji od ceho odpichnout. Pokud se definice nenajde, protoze si pod tim kazdej predstavuje neco jinyho, tak je to taky dobrej poznatek. Muze se pak celej pojem oop zahodit a vyresi se tim spousta semantickych nedorozumeni.

Jinak ja se bavim o modelovani realnyho sveta. Napr. business problemu. V takovym problemu figuruje cas. Kazdy z techto problemu muze byt namapovan na nejaky reaktivni system. Pokud v systemu nefiguruje cas, pak se da takovy problem reprezentovat pouhou statickou funkci, ktera mapuje vstupy na vystupy. Pak zadny oop neni treba, staci napsat obyc funkci a poskladat ji z mensich funkci atd.

Podivej se na ten koncept co pouziva Trailblazer (http://trailblazer.to/) a predevsim (http://trailblazer.to/gems/cells/)

Netvrdim, ze to je to nejlepsi a jediny, ale ty koncepcni casti a to jak "uchopili" problem se mi zamlouva. Jenze taky rozumim tomu, ze ne vzdycky to sedi/je mozny podle "modeloveho prikladu". Neboli jestli chces zobecnit "realnej svet" na nejakou tridu/sablonu, neuspejes. Jdu se mrknout na tu prednasku cos poslal, jsem zvedavej. Dik za link.

Kdyz vezmeme v potaz treba onen "log" ve chvili kdy ti to plive nejakej vystup do "souboru" je to asi fuk, ale ve chvili, kdy chces treba pouzit ruzny "system" do kterejch to loguje, prave treba polymorfizmus je na to jak delanej. Cili podle toho jestli je instance of "loguj do sentry" nebo "loguj do souboru" nebo "loguj do graylogu", ohnes to strasne jednoduse a nezabordeli se ti to. Protoze nekde ve tride volas jenom Log.write(message).

Shodou okolnosti ten prvni link co jsem ti poslal na tu prednasku tak tam pan velmi dobre vysvetluje, ze chces vracet iteratable misto dict a nemusis pak delat zbytecny bastleni.

Nejvic polymorfickej mechanismus co znam jsou unix pipes a files. Misto toho abych v pythonu nebo jave bastlil svoji reimplementaci polymorfismu na logovani, radsi udelam

Sys.stderr.write(message)

A zabalim celrj program do nejakyho shell skriptu nebo systemd unit configu, kterej mi to redirectne do graylogu, sentry, do filu, systemd journalu.

Nac tahat zbytecny zavislosti na tyhle externi sluzby do jednoduchyho python skriptu. Kdyz to chce nekdo pustit na cli a podivat se na vystup, at ten log plivne do stderr. Kdyz to chce nekdo plivnout do graylogu, klidne muze.

Sam uz vis, ze je lepsi vracet iterator nez statickej list nebo dict. Pak zjstis ze celej takovej problem muzes namapovat na streamovaci system coz je jeste obecnejsi nez iterator. Ale to uz je lekce c.2.
Název: Re:co si myslite o oop?
Přispěvatel: Mirek Prýmek 23. 12. 2018, 17:20:19
Rozdíl oproti C++like jazykům vidím hlavně v eleganci
Rozdíl je hlavně v tom, že poslání zprávy a volání funkce je úplně něco jiného. C++ to pomíchalo a lidi to přestali rozlišovat. K jeho dobru je třeba říct, že k tomu byl docela pádnej důvod (výkon). Ale výsledek je bohužel smutnej.

Předně dynamické typování vnímám jako nezbytnost pro objektový přístup.
A to je podle mě přesně ta výš zmíněná chyba. Obvykle tohle totiž řekne člověk, kterej ví, že "opravdové OOP" potřebuje něco flexibilnějšího než volání compile-time metod (např. pro respondsToSelector) a v tomhle smyslu je to celkem i pravda.

Ve skutečnosti ale není. Protože posílání zpráv NENÍ volání funkcí. Čili to s tím vůbec nesouvisí. Zprávy můžou být klidně typované, vnitřek actoru může být klidně typovaný, není to žádný problém. Protože zprávy se prostě zpracovávají úplně jiným mechanismem než se volají funkce.

Viz Erlang, Elixir: to jsou prakticky dva jazyky v jednom: struktura jednoho je daná strukturou komunikace (kdo komu posílá co), druhé je "běžný" funkcionální jazyk (který sice není typovaný, ale klidně by mohl být).
Název: Re:co si myslite o oop?
Přispěvatel: rigormortiz 23. 12. 2018, 17:28:33

Pojem oop uz strasi tenhle svet dostatecne , dlouho tak si zaslouzi nejakou definici, at se chudaci juniori maji od ceho odpichnout. Pokud se definice nenajde, protoze si pod tim kazdej predstavuje neco jinyho, tak je to taky dobrej poznatek. Muze se pak celej pojem oop zahodit a vyresi se tim spousta semantickych nedorozumeni.

Jinak ja se bavim o modelovani realnyho sveta. Napr. business problemu. V takovym problemu figuruje cas. Kazdy z techto problemu muze byt namapovan na nejaky reaktivni system. Pokud v systemu nefiguruje cas, pak se da takovy problem reprezentovat pouhou statickou funkci, ktera mapuje vstupy na vystupy. Pak zadny oop neni treba, staci napsat obyc funkci a poskladat ji z mensich funkci atd.

Podivej se na ten koncept co pouziva Trailblazer (http://trailblazer.to/) a predevsim (http://trailblazer.to/gems/cells/)

Netvrdim, ze to je to nejlepsi a jediny, ale ty koncepcni casti a to jak "uchopili" problem se mi zamlouva. Jenze taky rozumim tomu, ze ne vzdycky to sedi/je mozny podle "modeloveho prikladu". Neboli jestli chces zobecnit "realnej svet" na nejakou tridu/sablonu, neuspejes. Jdu se mrknout na tu prednasku cos poslal, jsem zvedavej. Dik za link.

Kdyz vezmeme v potaz treba onen "log" ve chvili kdy ti to plive nejakej vystup do "souboru" je to asi fuk, ale ve chvili, kdy chces treba pouzit ruzny "system" do kterejch to loguje, prave treba polymorfizmus je na to jak delanej. Cili podle toho jestli je instance of "loguj do sentry" nebo "loguj do souboru" nebo "loguj do graylogu", ohnes to strasne jednoduse a nezabordeli se ti to. Protoze nekde ve tride volas jenom Log.write(message).

Shodou okolnosti ten prvni link co jsem ti poslal na tu prednasku tak tam pan velmi dobre vysvetluje, ze chces vracet iteratable misto dict a nemusis pak delat zbytecny bastleni.

Nejvic polymorfickej mechanismus co znam jsou unix pipes a files. Misto toho abych v pythonu nebo jave bastlil svoji reimplementaci polymorfismu na logovani, radsi udelam

Sys.stderr.write(message)

A zabalim celrj program do nejakyho shell skriptu nebo systemd unit configu, kterej mi to redirectne do graylogu, sentry, do filu, systemd journalu.

Nac tahat zbytecny zavislosti na tyhle externi sluzby do jednoduchyho python skriptu. Kdyz to chce nekdo pustit na cli a podivat se na vystup, at ten log plivne do stderr. Kdyz to chce nekdo plivnout do graylogu, klidne muze.

Sam uz vis, ze je lepsi vracet iterator nez statickej list nebo dict. Pak zjstis ze celej takovej problem muzes namapovat na streamovaci system coz je jeste obecnejsi nez iterator. Ale to uz je lekce c.2.

Skouknul jsem tu prednasku a od zacatku mi to prislo, ze misto tridy proste jenom nekdo chtel napsat "helper" bo jak tam rikal "my heap toolkit". Rozhodne jsou tam jsou hezky veci a dik za sharing.

Tvuj problem je, ze ty vidis "jednoduchej" python script, to cos napsal za jako modelovej priklad pak vypada, ze to vyjde. Jenze pokud se bavis o necem vetsim nez je par funkci ktery nekde neco berou a nekam to davaj uz ti to nevyjde. Mas predpoklad, ze mas k dispozici bash cili to co nevybordelis ve svym pythonu zacnes bordelit ve svym bashi, kterej treba na windowsech neni, stejne jako existence systemd je dalsi "hard dependency". To mas jako kdyz chces bejt nekdo database agnostic nebo platform agnostic, ale zaroven reknes, ze to bezi jenom na linuxu s postgresem :)

To co ti chci rict, zes sis "vytvoril konkretni problem" a nasel sis na nej "konkretni reseni", ale zaroven tu pises, ze chces "obecny principy" a "realny svet". Navzajem se to vylucuje.

Kdyz delas skript tak delas skript a pokrocily "techniky/pristupy" v tom resi nemusis, protoze je to konkretni skrtip na reseni konkretniho problemu. Pokud mas aplikaci, ktera resi treba logovani a analyzu hovoru pro call centrum, muzes to napsat jako 300 skriptu ktery budes nejak importovat jeden do druhyho, nebo to muzes napsat jako clovek, kdy sice budes mit ve finale 500 souboru a 200 trid, ale aspon se to bude dat cist, testovat a rozsirovat a ne z toho delat nejaky spagety a dalsich 20 berlickovejch bashu okolo toho.

Jestli tady jde o premerovani udu a dogmatickou demagogii kde minimalismus je doktrina a zadna promena nebude mit vic jak tri pismenka, prosim jak je libo. Klidne ti i reknu ze mas pravdu a ze to tak je nejlepsi, kdyz te to potesi ;)

Salut.
Název: Re:co si myslite o oop?
Přispěvatel: Kadet 23. 12. 2018, 17:45:54

Pojem oop uz strasi tenhle svet dostatecne , dlouho tak si zaslouzi nejakou definici, at se chudaci juniori maji od ceho odpichnout. Pokud se definice nenajde, protoze si pod tim kazdej predstavuje neco jinyho, tak je to taky dobrej poznatek. Muze se pak celej pojem oop zahodit a vyresi se tim spousta semantickych nedorozumeni.

Jinak ja se bavim o modelovani realnyho sveta. Napr. business problemu. V takovym problemu figuruje cas. Kazdy z techto problemu muze byt namapovan na nejaky reaktivni system. Pokud v systemu nefiguruje cas, pak se da takovy problem reprezentovat pouhou statickou funkci, ktera mapuje vstupy na vystupy. Pak zadny oop neni treba, staci napsat obyc funkci a poskladat ji z mensich funkci atd.

Podivej se na ten koncept co pouziva Trailblazer (http://trailblazer.to/) a predevsim (http://trailblazer.to/gems/cells/)

Netvrdim, ze to je to nejlepsi a jediny, ale ty koncepcni casti a to jak "uchopili" problem se mi zamlouva. Jenze taky rozumim tomu, ze ne vzdycky to sedi/je mozny podle "modeloveho prikladu". Neboli jestli chces zobecnit "realnej svet" na nejakou tridu/sablonu, neuspejes. Jdu se mrknout na tu prednasku cos poslal, jsem zvedavej. Dik za link.

Kdyz vezmeme v potaz treba onen "log" ve chvili kdy ti to plive nejakej vystup do "souboru" je to asi fuk, ale ve chvili, kdy chces treba pouzit ruzny "system" do kterejch to loguje, prave treba polymorfizmus je na to jak delanej. Cili podle toho jestli je instance of "loguj do sentry" nebo "loguj do souboru" nebo "loguj do graylogu", ohnes to strasne jednoduse a nezabordeli se ti to. Protoze nekde ve tride volas jenom Log.write(message).

Shodou okolnosti ten prvni link co jsem ti poslal na tu prednasku tak tam pan velmi dobre vysvetluje, ze chces vracet iteratable misto dict a nemusis pak delat zbytecny bastleni.

Nejvic polymorfickej mechanismus co znam jsou unix pipes a files. Misto toho abych v pythonu nebo jave bastlil svoji reimplementaci polymorfismu na logovani, radsi udelam

Sys.stderr.write(message)

A zabalim celrj program do nejakyho shell skriptu nebo systemd unit configu, kterej mi to redirectne do graylogu, sentry, do filu, systemd journalu.

Nac tahat zbytecny zavislosti na tyhle externi sluzby do jednoduchyho python skriptu. Kdyz to chce nekdo pustit na cli a podivat se na vystup, at ten log plivne do stderr. Kdyz to chce nekdo plivnout do graylogu, klidne muze.

Sam uz vis, ze je lepsi vracet iterator nez statickej list nebo dict. Pak zjstis ze celej takovej problem muzes namapovat na streamovaci system coz je jeste obecnejsi nez iterator. Ale to uz je lekce c.2.

Skouknul jsem tu prednasku a od zacatku mi to prislo, ze misto tridy proste jenom nekdo chtel napsat "helper" bo jak tam rikal "my heap toolkit". Rozhodne jsou tam jsou hezky veci a dik za sharing.

Tvuj problem je, ze ty vidis "jednoduchej" python script, to cos napsal za jako modelovej priklad pak vypada, ze to vyjde. Jenze pokud se bavis o necem vetsim nez je par funkci ktery nekde neco berou a nekam to davaj uz ti to nevyjde. Mas predpoklad, ze mas k dispozici bash cili to co nevybordelis ve svym pythonu zacnes bordelit ve svym bashi, kterej treba na windowsech neni, stejne jako existence systemd je dalsi "hard dependency". To mas jako kdyz chces bejt nekdo database agnostic nebo platform agnostic, ale zaroven reknes, ze to bezi jenom na linuxu s postgresem :)

To co ti chci rict, zes sis "vytvoril konkretni problem" a nasel sis na nej "konkretni reseni", ale zaroven tu pises, ze chces "obecny principy" a "realny svet". Navzajem se to vylucuje.

Kdyz delas skript tak delas skript a pokrocily "techniky/pristupy" v tom resi nemusis, protoze je to konkretni skrtip na reseni konkretniho problemu. Pokud mas aplikaci, ktera resi treba logovani a analyzu hovoru pro call centrum, muzes to napsat jako 300 skriptu ktery budes nejak importovat jeden do druhyho, nebo to muzes napsat jako clovek, kdy sice budes mit ve finale 500 souboru a 200 trid, ale aspon se to bude dat cist, testovat a rozsirovat a ne z toho delat nejaky spagety a dalsich 20 berlickovejch bashu okolo toho.

Jestli tady jde o premerovani udu a dogmatickou demagogii kde minimalismus je doktrina a zadna promena nebude mit vic jak tri pismenka, prosim jak je libo. Klidne ti i reknu ze mas pravdu a ze to tak je nejlepsi, kdyz te to potesi ;)

Salut.

Chlape neco mi naznacuje ze ti 1. dochazi para a za 2. delas porad na prvnim sw projektu, kterej je hromada sracek rozsekana do 500 souboru a milionu trid. Nedivim se ti, ze te to desi a hledas zpusob jak se v tom bordelu zorientovat pomoci organizace kodu, enkapsulace, statickyho typovani apod.

Ja ti jenom rikam ze kdyz trochu odzoomujes a podivas se na problem co resis, tj. analyza logu a hovoru pro call centrum, tak je to prachsprostej problem analyzy streamu dat. Neco mi rika, ze tam na to pouzivate scalu a ze je to prasecina.
Název: Re:co si myslite o oop?
Přispěvatel: Archie 23. 12. 2018, 17:56:58
Velky spatny. Jak na backendu, tak frontendu. A strasne nerad bych se k OOP kdykoliv vracel, pokud bych nemel programovat hry. Typescript + Node.js na serveru, React na frontendu, funkce. Programator se v OOP daleko vic vrta v rezii vlastniho programovani, nezli v reseni problemu.

Samozrejme, nelze brat takto dogmaticky. 100 projektu, 100 pristupu. Takove ty webove CMS protkane AbstractPageHyperAbstractPageProvidery, kde kurzorkem v debugu preskakuji uz dvacatou tridu, abych na spodku vodopadu nalezl "god komponentu" udrzujici si vlastni stav v 10 lokalnich promennych - tak tomu se rad vyhnu.

p.s. Videl jsem i jQuery + Vanila JS objektove pojaty frontend. Kombinace dedicnosti, css selektorů, prefixu, sufixu a externich pluginu byla skutecnym pozitkem pro milovniky dobreho kodu.
Název: Re:co si myslite o oop?
Přispěvatel: Kiwi 23. 12. 2018, 18:03:31
Rozdíl oproti C++like jazykům vidím hlavně v eleganci
Rozdíl je hlavně v tom, že poslání zprávy a volání funkce je úplně něco jiného. C++ to pomíchalo a lidi to přestali rozlišovat. K jeho dobru je třeba říct, že k tomu byl docela pádnej důvod (výkon). Ale výsledek je bohužel smutnej.

Předně dynamické typování vnímám jako nezbytnost pro objektový přístup.
A to je podle mě přesně ta výš zmíněná chyba. Obvykle tohle totiž řekne člověk, kterej ví, že "opravdové OOP" potřebuje něco flexibilnějšího než volání compile-time metod (např. pro respondsToSelector) a v tomhle smyslu je to celkem i pravda.

Ve skutečnosti ale není. Protože posílání zpráv NENÍ volání funkcí. Čili to s tím vůbec nesouvisí. Zprávy můžou být klidně typované, vnitřek actoru může být klidně typovaný, není to žádný problém. Protože zprávy se prostě zpracovávají úplně jiným mechanismem než se volají funkce.

Viz Erlang, Elixir: to jsou prakticky dva jazyky v jednom: struktura jednoho je daná strukturou komunikace (kdo komu posílá co), druhé je "běžný" funkcionální jazyk (který sice není typovaný, ale klidně by mohl být).
Podle mě se v tom strašně pipláte. Z praktického pohledu mě nikdy nenapadlo nad tím tak dumat. Jen vnímám rozdíly, resp. to, co mě irituje jinde. Mě vůbec připadá, že se tady strašně teoretizuje, místo aby si lidi prakticky zkusili A, pak B a pak řešili, v čem se jim dělá lépe.
Název: Re:co si myslite o oop?
Přispěvatel: Jose 23. 12. 2018, 18:26:23
OOP má své opodstatnění a je to silný nástroj, bohužel to často dopadá jako když dáte dítěti do ruky nabitou pistoli ;D
Název: Re:co si myslite o oop?
Přispěvatel: JSH 23. 12. 2018, 18:27:47
Rozdíl oproti C++like jazykům vidím hlavně v eleganci
Rozdíl je hlavně v tom, že poslání zprávy a volání funkce je úplně něco jiného. C++ to pomíchalo a lidi to přestali rozlišovat. K jeho dobru je třeba říct, že k tomu byl docela pádnej důvod (výkon). Ale výsledek je bohužel smutnej.
C++ to nepomíchalo. Objektový model C++ je +- převzatý ze Simuly.
Název: Re:co si myslite o oop?
Přispěvatel: Mirek Prýmek 23. 12. 2018, 18:29:56
Podle mě se v tom strašně pipláte. Z praktického pohledu mě nikdy nenapadlo nad tím tak dumat. Jen vnímám rozdíly, resp. to, co mě irituje jinde. Mě vůbec připadá, že se tady strašně teoretizuje, místo aby si lidi prakticky zkusili A, pak B a pak řešili, v čem se jim dělá lépe.
Ne, tohle není žádná teoretická onanie. Má to konkrétní (tragické) důsledky. Ten asi nejhorší ze všech je, že když máš posílání zpráv implementované (jednoduše) jako volání metod, tak při vícevláknovém zpracování ti vznikají race conditions. Což je přesně to, co to dnešní praseOOP dostává do kolen. A co by se nemohlo stát, kdyby se tyhle dvě věci nemíchaly.

Je to velice praktická věc, akorát ten "teoretický" problém jako příčinu ne každý vidí, protože prostě nic jinýho neviděl, nezažil. Proto bych každýmu fakt vřele doporučoval si zkusit ten Elixir, aby mu to mohlo docvaknout. Zprávy jsou zprávy, mají se posílat do inboxu, odtud vybírat a (dle libovůle) zpracovávat. Žádný nesmysly typu vlákno Pes teď vlezlo do třídy Kočka. Pes je pes a kočka je kočka. Stačí to jenom nemíchat, tak snadné to je :)
Název: Re:co si myslite o oop?
Přispěvatel: Mirek Prýmek 23. 12. 2018, 18:31:42
C++ to nepomíchalo. Objektový model C++ je +- převzatý ze Simuly.
V C++ se žádné zprávy do žádných inboxů neposílají. V C++ se posílání zpráv markýruje voláním (potenciálně virtuálních) metod.
Název: Re:co si myslite o oop?
Přispěvatel: Mirek Prýmek 23. 12. 2018, 18:36:59
C++ to nepomíchalo. Objektový model C++ je +- převzatý ze Simuly.
V C++ se žádné zprávy do žádných inboxů neposílají. V C++ se posílání zpráv markýruje voláním (potenciálně virtuálních) metod.
Jo, pardon, špatně jsem tu větu pochopil. Ok, díky za upřesnění. Nechtěl jsem říct, že to Stoustrup vymyslel, ale že to zpopularizoval. Což byl podle mě (multi)million dollar mistake.
Název: Re:co si myslite o oop?
Přispěvatel: Kiwi 23. 12. 2018, 18:46:16
Podle mě se v tom strašně pipláte. Z praktického pohledu mě nikdy nenapadlo nad tím tak dumat. Jen vnímám rozdíly, resp. to, co mě irituje jinde. Mě vůbec připadá, že se tady strašně teoretizuje, místo aby si lidi prakticky zkusili A, pak B a pak řešili, v čem se jim dělá lépe.
Ne, tohle není žádná teoretická onanie. Má to konkrétní (tragické) důsledky. Ten asi nejhorší ze všech je, že když máš posílání zpráv implementované (jednoduše) jako volání metod, tak při vícevláknovém zpracování ti vznikají race conditions. Což je přesně to, co to dnešní praseOOP dostává do kolen. A co by se nemohlo stát, kdyby se tyhle dvě věci nemíchaly.

Je to velice praktická věc, akorát ten "teoretický" problém jako příčinu ne každý vidí, protože prostě nic jinýho neviděl, nezažil. Proto bych každýmu fakt vřele doporučoval si zkusit ten Elixir, aby mu to mohlo docvaknout. Zprávy jsou zprávy, mají se posílat do inboxu, odtud vybírat a (dle libovůle) zpracovávat. Žádný nesmysly typu vlákno Pes teď vlezlo do třídy Kočka. Pes je pes a kočka je kočka. Stačí to jenom nemíchat, tak snadné to je :)
Tohle mi připadá jako opačný extrém.
Název: Re:co si myslite o oop?
Přispěvatel: Martin 23. 12. 2018, 19:07:57
Rozdíl je hlavně v tom, že poslání zprávy a volání funkce je úplně něco jiného. C++ to pomíchalo a lidi to přestali rozlišovat.
Poslani synchronni zpravy a volani funkce je to same. Nebo preferujete asynchronni posilani zprav, kazdy obekt s vlastnim vlaknem, handlerem a obrovskym balastem navic? Prijde Vam soucasny SW prilis optimalizovany, chcete ho jeste viz zpomalit?
Název: Re:co si myslite o oop?
Přispěvatel: Mirek Prýmek 23. 12. 2018, 19:21:55
Poslani synchronni zpravy a volani funkce je to same.
V jakém smyslu?

Nebo preferujete asynchronni posilani zprav, kazdy obekt s vlastnim vlaknem, handlerem a obrovskym balastem navic?
Není potřeba vlastní vlákno. Nevím, co si mám představit pod handlerem. Jaký "obrovský balast"?
Název: Re:co si myslite o oop?
Přispěvatel: Kadet 23. 12. 2018, 19:46:51
Poslani synchronni zpravy a volani funkce je to same.
V jakém smyslu?

Nebo preferujete asynchronni posilani zprav, kazdy obekt s vlastnim vlaknem, handlerem a obrovskym balastem navic?
Není potřeba vlastní vlákno. Nevím, co si mám představit pod handlerem. Jaký "obrovský balast"?

Volani funkce a synchronni poslani zpravy, tj. zaslani pozadavku a obdrzeni odpovedi, jsou skutecne totez, pokue je to v ramci programovaciho jazyka.

Vlakno je pouze abstrakce. Muze byt tezkopadne jako unix nebo nt vlakno s velkym stackem, nebo velmi lehka abstrakce v pripade green threadingu.

Ale z pohledu actor systemu bezi kazdy agent ve svem vlakne.
Název: Re:co si myslite o oop?
Přispěvatel: Martin 23. 12. 2018, 21:19:37
Vlakno je pouze abstrakce. Muze byt tezkopadne jako unix nebo nt vlakno s velkym stackem, nebo velmi lehka abstrakce v pripade green threadingu.
Ale z pohledu actor systemu bezi kazdy agent ve svem vlakne.
Green threading? A jsme zpet u kooperativniho multitaskingu jako ve win 3.11. A neni nejlepsi cely ten balast zahodit a rovnou zavolat metodu?
Název: Re:co si myslite o oop?
Přispěvatel: Bacsa 23. 12. 2018, 21:26:04
Vlakno je pouze abstrakce. Muze byt tezkopadne jako unix nebo nt vlakno s velkym stackem, nebo velmi lehka abstrakce v pripade green threadingu.
Ale z pohledu actor systemu bezi kazdy agent ve svem vlakne.
Green threading? A jsme zpet u kooperativniho multitaskingu
Go má kooperativní scheduler a jak skvěle šlape...
Název: Re:co si myslite o oop?
Přispěvatel: Martin 23. 12. 2018, 21:34:08
Go má kooperativní scheduler a jak skvěle šlape...
Jiste, na dnesnich CPU bezi rychle vsechno. Ale mohlo by i rychleji.
https://benchmarksgame-team.pages.debian.net/benchmarksgame/faster/go-gpp.html
Název: Re:co si myslite o oop?
Přispěvatel: Bacsa 23. 12. 2018, 21:52:23
Go má kooperativní scheduler a jak skvěle šlape...
Jiste, na dnesnich CPU bezi rychle vsechno. Ale mohlo by i rychleji.
https://benchmarksgame-team.pages.debian.net/benchmarksgame/faster/go-gpp.html
Debilně napsaný kód bude vždy pomalejší. Vypovídací hodnota nula.
Název: Re:co si myslite o oop?
Přispěvatel: Mirek Prýmek 23. 12. 2018, 22:09:40
Volani funkce a synchronni poslani zpravy, tj. zaslani pozadavku a obdrzeni odpovedi, jsou skutecne totez, pokue je to v ramci programovaciho jazyka.
Tak já zkusím jeden protipříklad: když se skutečně předává zpráva, tak se předávají data a 1. ten, kdo je předává nad nimi ztrácí jakoukoliv kontrolu, 2. příjemce jim nutně nemusí rozumět. Čili jde například udělat velmi snadno obecnou RPC proxy, která umí proxovat cokoli, i to, co v době jejího překladu ještě vůbec neexistuje. S voláním metod tohle udělat nejde.

Ale z pohledu actor systemu bezi kazdy agent ve svem vlakne.
Tak to asi bude dost záležet na definicích pojmů. Nemám potřebu se o ně přít ani je řešit. To, co je opravdu důležitý, je, že actors komunikují pouze pomocí předávání dat, tj. nesdílejí ani paměť, ani jiné zdroje, čili z principu nemůže nastat race condition jako u OOP, nemusí se používat žádné zběsilé zámky, kritické sekce a podobné srandy. Pořád existuje problém deadlocku kvůli možným kruhovým závislostem, ale to asi žádné extraelegantní řešení stejně nemá (aspoň já o něm nevím).

Jestli dvěma goroutinám, které si posílají zprávy pomocí kanálu někdo chce nebo nechce říkat "dvě vlákna", je mi celkem jedno. Skutečné OS vlákno to může být jenom jedno a žádná tragická performance penalty tam není (btw, stejný princip se používá i v embedded), ani žádné extrabuřthandlery ani jiný "obrovský balast".
Název: Re:co si myslite o oop?
Přispěvatel: Kit 23. 12. 2018, 22:30:52
Tak já zkusím jeden protipříklad: když se skutečně předává zpráva, tak se předávají data a 1. ten, kdo je předává nad nimi ztrácí jakoukoliv kontrolu, 2. příjemce jim nutně nemusí rozumět. Čili jde například udělat velmi snadno obecnou RPC proxy, která umí proxovat cokoli, i to, co v době jejího překladu ještě vůbec neexistuje. S voláním metod tohle udělat nejde.

Tak těmto definicím vyhovuje PHP docela dobře, tedy alespoň v mých aplikacích.
Název: Re:co si myslite o oop?
Přispěvatel: Kadet 23. 12. 2018, 22:42:40
Vlakno je pouze abstrakce. Muze byt tezkopadne jako unix nebo nt vlakno s velkym stackem, nebo velmi lehka abstrakce v pripade green threadingu.
Ale z pohledu actor systemu bezi kazdy agent ve svem vlakne.
Green threading? A jsme zpet u kooperativniho multitaskingu jako ve win 3.11. A neni nejlepsi cely ten balast zahodit a rovnou zavolat metodu?

Ja jsem nikde nezminil nic o konkretni implementaci frajere.

Pouze rikam, ze z pohledu jednoho agenta muzu na posloupnost jeho operaci nahlizet jako na vlakno. Kdyz usporadam jeho operace v kodu podle toho jak pujdou po sobe, dokonce.ten kod zacne vypadat jako synchronni. Ale presto muzu volat jeho jednotlivy 'metody'.
Název: Re:co si myslite o oop?
Přispěvatel: Bacsa 23. 12. 2018, 22:44:31
Poslani synchronni zpravy a volani funkce je to same.
V jakém smyslu?

Nebo preferujete asynchronni posilani zprav, kazdy obekt s vlastnim vlaknem, handlerem a obrovskym balastem navic?
Není potřeba vlastní vlákno. Nevím, co si mám představit pod handlerem. Jaký "obrovský balast"?
Volani funkce a synchronni poslani zpravy, tj. zaslani pozadavku a obdrzeni odpovedi, jsou skutecne totez
To je pravda, ale jen v rámci jednoho adresního prostoru.
Název: Re:co si myslite o oop?
Přispěvatel: Mirek Prýmek 23. 12. 2018, 22:45:58
Tak těmto definicím vyhovuje PHP docela dobře, tedy alespoň v mých aplikacích.
To není definice, jenom znínění dvou vlastností, které jsou podstatné pro ten protipříklad.

Jinak formální definice actor modelu existují (i velmi formální) a každý si může ověřit, jestli je ta která implementace OOP splňuje nebo ne.
Název: Re:co si myslite o oop?
Přispěvatel: Mirek Prýmek 23. 12. 2018, 22:47:21
To je pravda, ale jen v rámci jednoho adresního prostoru.
Znova opakuju: v jakém smyslu je to pravda (v rámci jednoho adresního prostoru)?
Název: Re:co si myslite o oop?
Přispěvatel: Mirek Prýmek 23. 12. 2018, 22:48:48
Kdyz usporadam jeho operace v kodu podle toho jak pujdou po sobe, dokonce.ten kod zacne vypadat jako synchronni. Ale presto muzu volat jeho jednotlivy 'metody'.
Přiznám se, že vůbec nejsem schopnej dešifrovat, co se snažíš sdělit :)
Název: Re:co si myslite o oop?
Přispěvatel: Kadet 23. 12. 2018, 22:56:27
Volani funkce a synchronni poslani zpravy, tj. zaslani pozadavku a obdrzeni odpovedi, jsou skutecne totez, pokue je to v ramci programovaciho jazyka.
Tak já zkusím jeden protipříklad: když se skutečně předává zpráva, tak se předávají data a 1. ten, kdo je předává nad nimi ztrácí jakoukoliv kontrolu, 2. příjemce jim nutně nemusí rozumět. Čili jde například udělat velmi snadno obecnou RPC proxy, která umí proxovat cokoli, i to, co v době jejího překladu ještě vůbec neexistuje. S voláním metod tohle udělat nejde.

Ale z pohledu actor systemu bezi kazdy agent ve svem vlakne.
Tak to asi bude dost záležet na definicích pojmů. Nemám potřebu se o ně přít ani je řešit. To, co je opravdu důležitý, je, že actors komunikují pouze pomocí předávání dat, tj. nesdílejí ani paměť, ani jiné zdroje, čili z principu nemůže nastat race condition jako u OOP, nemusí se používat žádné zběsilé zámky, kritické sekce a podobné srandy. Pořád existuje problém deadlocku kvůli možným kruhovým závislostem, ale to asi žádné extraelegantní řešení stejně nemá (aspoň já o něm nevím).

Jestli dvěma goroutinám, které si posílají zprávy pomocí kanálu někdo chce nebo nechce říkat "dvě vlákna", je mi celkem jedno. Skutečné OS vlákno to může být jenom jedno a žádná tragická performance penalty tam není (btw, stejný princip se používá i v embedded), ani žádné extrabuřthandlery ani jiný "obrovský balast".

Mirku, ten, kdo posila tu zpravu neztraci ihned kontrolu v pripade synchronniho (blokujiciho) volani, jak jsem zminoval. Tj. Tazatel po odeslani zamrzne vyjma toho, ze je schopen prijmout odpoved na svoji odeslanou zpravu. Tazatel a odpovidatel se muzou koordinovat pomoci unikatniho klice (correlation id), ktere svazuje request a response k sobe.

Ano, kazdy agent funguje jakoby plne ve svym pocitaci, s vlastnimi zdroji, ve vlastnim vlakne. Jak moc blizko se tehle abstrakce v softwaru implementujicim agenty/actory dosahne je irelevantni. Konceptualne jsou plne izolovani.
Název: Re:co si myslite o oop?
Přispěvatel: Kadet 23. 12. 2018, 23:03:15
Kdyz usporadam jeho operace v kodu podle toho jak pujdou po sobe, dokonce.ten kod zacne vypadat jako synchronni. Ale presto muzu volat jeho jednotlivy 'metody'.
Přiznám se, že vůbec nejsem schopnej dešifrovat, co se snažíš sdělit :)

Az budu u kompu hodim sem priklad.

Uzivejte Vanoce objektaci!
Název: Re:co si myslite o oop?
Přispěvatel: Martin 23. 12. 2018, 23:07:00
Volani funkce a synchronni poslani zpravy, tj. zaslani pozadavku a obdrzeni odpovedi, jsou skutecne totez, pokue je to v ramci programovaciho jazyka.
Tak já zkusím jeden protipříklad: když se skutečně předává zpráva, tak se předávají data a 1. ten, kdo je předává nad nimi ztrácí jakoukoliv kontrolu, 2. příjemce jim nutně nemusí rozumět. Čili jde například udělat velmi snadno obecnou RPC proxy, která umí proxovat cokoli, i to, co v době jejího překladu ještě vůbec neexistuje. S voláním metod tohle udělat nejde.
Nejsem toho nazoru. Prijimaci strana musi na urcite urovni zprave rozumet, jinak by neumela data zpracovat. Vysilac muze vysilat data najakou funkci napr. send(data) a prijimac obsahuje naky handler napr. ondatareceive(data).
Prostou zamenou volani send() za ondatareceive() se zmenilo vysilani zpravy na volani metody.

Název: Re:co si myslite o oop?
Přispěvatel: Martin 23. 12. 2018, 23:08:18
Ja jsem nikde nezminil nic o konkretni implementaci frajere.
Mohli bychom zustat v v rovine akademicke diskuse?
Název: Re:co si myslite o oop?
Přispěvatel: Mirek Prýmek 23. 12. 2018, 23:10:55
Mirku, ten, kdo posila tu zpravu neztraci ihned kontrolu v pripade synchronniho (blokujiciho) volani, jak jsem zminoval. Tj. Tazatel po odeslani zamrzne vyjma toho, ze je schopen prijmout odpoved na svoji odeslanou zpravu. Tazatel a odpovidatel se muzou koordinovat pomoci unikatniho klice (correlation id), ktere svazuje request a response k sobe.
Já teď nevím, o čem mluvíš. Jestli o "mainstream OOP", "původním OOP", actor modelu nebo nějaké své představě. Pokud o actor modelu, tak nemáš pravdu hned v několika bodech.

P.S. tím mým "ztrácí kontrolu" jsem myslel, že nemůže poslat něco ve stylu ukazatel, co by mohl po doručení měnit.

Ano, kazdy agent funguje jakoby plne ve svym pocitaci, s vlastnimi zdroji, ve vlastnim vlakne. Jak moc blizko se tehle abstrakce v softwaru implementujicim agenty/actory dosahne je irelevantni. Konceptualne jsou plne izolovani.
Souhlas - jak je to implementované je irelevantní, pokud jsou splněné jisté požadavky.

Nejsem toho nazoru. Prijimaci strana musi na urcite urovni zprave rozumet, jinak by neumela data zpracovat.
A v tom se právě mýlíš. V actor modelu i "původním OOP" můžeš mít objekt, který na jakoukoli zprávu odpoví "sorry, nerozumím". Opět: v pseudoOOP implementovaném pomocí volání metod to není realizovatelné.
Název: Re:co si myslite o oop?
Přispěvatel: Kiwi 23. 12. 2018, 23:15:22
Volani funkce a synchronni poslani zpravy, tj. zaslani pozadavku a obdrzeni odpovedi, jsou skutecne totez, pokue je to v ramci programovaciho jazyka.
Tak já zkusím jeden protipříklad: když se skutečně předává zpráva, tak se předávají data a 1. ten, kdo je předává nad nimi ztrácí jakoukoliv kontrolu, 2. příjemce jim nutně nemusí rozumět. Čili jde například udělat velmi snadno obecnou RPC proxy, která umí proxovat cokoli, i to, co v době jejího překladu ještě vůbec neexistuje. S voláním metod tohle udělat nejde.
Nejsem toho nazoru. Prijimaci strana musi na urcite urovni zprave rozumet, jinak by neumela data zpracovat. Vysilac muze vysilat data najakou funkci napr. send(data) a prijimac obsahuje naky handler napr. ondatareceive(data).
Prostou zamenou volani send() za ondatareceive() se zmenilo vysilani zpravy na volani metody.
Nemusí, přesně ten příklad s proxy je přiléhavý. Prostě vezmu zprávu, aniž bych jí sám rozuměl, a pošlu ji někam dál.
Název: Re:co si myslite o oop?
Přispěvatel: Bacsa 23. 12. 2018, 23:41:47
Volani funkce a synchronni poslani zpravy, tj. zaslani pozadavku a obdrzeni odpovedi, jsou skutecne totez, pokue je to v ramci programovaciho jazyka.
Tak já zkusím jeden protipříklad: když se skutečně předává zpráva, tak se předávají data a 1. ten, kdo je předává nad nimi ztrácí jakoukoliv kontrolu, 2. příjemce jim nutně nemusí rozumět. Čili jde například udělat velmi snadno obecnou RPC proxy, která umí proxovat cokoli, i to, co v době jejího překladu ještě vůbec neexistuje. S voláním metod tohle udělat nejde.
Nejsem toho nazoru. Prijimaci strana musi na urcite urovni zprave rozumet, jinak by neumela data zpracovat. Vysilac muze vysilat data najakou funkci napr. send(data) a prijimac obsahuje naky handler napr. ondatareceive(data).
Prostou zamenou volani send() za ondatareceive() se zmenilo vysilani zpravy na volani metody.
To je v zásadě pravda, ale otázka je, co pak dělá to ondatareceive.
Název: Re:co si myslite o oop?
Přispěvatel: Bacsa 23. 12. 2018, 23:43:16
To je pravda, ale jen v rámci jednoho adresního prostoru.
Znova opakuju: v jakém smyslu je to pravda (v rámci jednoho adresního prostoru)?
Volá se funkce podle nějakého ABI, konkrétní implementace závisí na jazyce, ale umí to třeba i Java.
Název: Re:co si myslite o oop?
Přispěvatel: Mirek Prýmek 24. 12. 2018, 00:03:44
Volá se funkce podle nějakého ABI, konkrétní implementace závisí na jazyce, ale umí to třeba i Java.
Jak v Javě napíšeš třídu, na které když zavoláš jakoukoli - tj. i v době překladu neznámou metodu, tak ti vrátí string "Sorry, I do not understand"?

Pokud to jde (nevím), tak nějak extrémně krkolomně. Přitom tohle by měl být základ skutečného OOP.
Název: Re:co si myslite o oop?
Přispěvatel: Mirek Prýmek 24. 12. 2018, 00:10:08
To je v zásadě pravda.
Ne, není to pravda. Bacsa mixuje úroveň jazyka (volání metody vs. předání dat) a jeho implementaci (konkrétní implementace předání dat vs. nějaké to vyhledávání ve virtuální tabulce, ASM CALL apod.)

To, že sémantiku předávání zpráv můžu za nějakých podmínek implementovat pomocí volání metody, neznamená, že je to totéž. Volat můžu jenom metody, které předem znám (jsou v tabulce metod), data můžu předávat jakákoliv a žádnou tabulku k tomu nepotřebuju.

Docela rozumný kompromis je použít oboje - mít tabulku metod, ale zároveň i nějaký fallback, který můžu využít ke zpracování neznámých zpráv (např. Python IIRC).
Název: Re:co si myslite o oop?
Přispěvatel: BaldSlattery 24. 12. 2018, 00:12:48
Volá se funkce podle nějakého ABI, konkrétní implementace závisí na jazyce, ale umí to třeba i Java.
Jak v Javě napíšeš třídu, na které když zavoláš jakoukoli - tj. i v době překladu neznámou metodu, tak ti vrátí string "Sorry, I do not understand"?

Pokud to jde (nevím), tak nějak extrémně krkolomně. Přitom tohle by měl být základ skutečného OOP.

Přes InvocationHandler. Je to stejně “krkolomné” jako ve Smalltalku.
Název: Re:co si myslite o oop?
Přispěvatel: Mirek Prýmek 24. 12. 2018, 00:40:33
Je to stejně “krkolomné” jako ve Smalltalku.
Ve Smalltalku je to, pokud se nepletu, na dva řádky. Můžeš ukázat tu implementaci v Javě? Je taky na dva řádky?
Název: Re:co si myslite o oop?
Přispěvatel: Kiwi 24. 12. 2018, 01:11:25
Je to stejně “krkolomné” jako ve Smalltalku.
Ve Smalltalku je to, pokud se nepletu, na dva řádky. Můžeš ukázat tu implementaci v Javě? Je taky na dva řádky?
Jen doplním - ve Smalltalku:
Kód: [Vybrat]
doesNotUnderstand: aMessage
    ^ 'Unknown message: ', aMessage asString
Název: Re:co si myslite o oop?
Přispěvatel: BaldSlattery 24. 12. 2018, 02:10:52
Je to stejně “krkolomné” jako ve Smalltalku.
Ve Smalltalku je to, pokud se nepletu, na dva řádky. Můžeš ukázat tu implementaci v Javě? Je taky na dva řádky?
Jen doplním - ve Smalltalku:
Kód: [Vybrat]
doesNotUnderstand: aMessage
    ^ 'Unknown message: ', aMessage asString
V Javě to bude standardně na tři řádky kvůli uzavírací závorce. Tohle do Javy dali lidi z Lighthousu, kteří psali v ObjC a v Sunu po akvizici je donutili psát v Javě.
Název: Re:Co si myslíte o OOP?
Přispěvatel: Martin 24. 12. 2018, 09:39:13
Nejsem toho nazoru. Prijimaci strana musi na urcite urovni zprave rozumet, jinak by neumela data zpracovat.
A v tom se právě mýlíš. V actor modelu i "původním OOP" můžeš mít objekt, který na jakoukoli zprávu odpoví "sorry, nerozumím". Opět: v pseudoOOP implementovaném pomocí volání metod to není realizovatelné.
int nakafunkce(...) { return ERR_NOT_SUPPORTED;}


To je v zásadě pravda, ale otázka je, co pak dělá to ondatareceive.
Asi se podiva do vstupnich dat, nejak je parsuje a nejak na ne reaguje.
Název: Re:co si myslite o oop?
Přispěvatel: Martin 24. 12. 2018, 09:41:46
Nejsem toho nazoru. Prijimaci strana musi na urcite urovni zprave rozumet, jinak by neumela data zpracovat. Vysilac muze vysilat data najakou funkci napr. send(data) a prijimac obsahuje naky handler napr. ondatareceive(data).
Prostou zamenou volani send() za ondatareceive() se zmenilo vysilani zpravy na volani metody.
Nemusí, přesně ten příklad s proxy je přiléhavý. Prostě vezmu zprávu, aniž bych jí sám rozuměl, a pošlu ji někam dál.
To same je, kdyz ondatareceive(...) zavola nejakyjinyondatareceive(...).
Název: Re:Co si myslíte o OOP?
Přispěvatel: Mirek Prýmek 24. 12. 2018, 10:08:04
int nakafunkce(...) { return ERR_NOT_SUPPORTED;}
Na jakoukoli zprávu, ne na zprávu "nakafunkce".
Název: Re:Co si myslíte o OOP?
Přispěvatel: Martin 24. 12. 2018, 10:32:46
int nakafunkce(...) { return ERR_NOT_SUPPORTED;}
Na jakoukoli zprávu, ne na zprávu "nakafunkce".
nakafunkce(...) je handler vsech zprav. Ocekaval jsem, ze si to domyslite.
Název: Re:Co si myslíte o OOP?
Přispěvatel: BaldSlattery 24. 12. 2018, 10:35:06
Nejsem toho nazoru. Prijimaci strana musi na urcite urovni zprave rozumet, jinak by neumela data zpracovat.
A v tom se právě mýlíš. V actor modelu i "původním OOP" můžeš mít objekt, který na jakoukoli zprávu odpoví "sorry, nerozumím". Opět: v pseudoOOP implementovaném pomocí volání metod to není realizovatelné.
int nakafunkce(...) { return ERR_NOT_SUPPORTED;}
On myslí dynamický dispatch, to by v Javě byla metoda invoke (obdoba forward), z jejíchž parametrů lze vyčíst jméno původně volané metody.
Název: Re:Co si myslíte o OOP?
Přispěvatel: BaldSlattery 24. 12. 2018, 10:35:55
int nakafunkce(...) { return ERR_NOT_SUPPORTED;}
Na jakoukoli zprávu, ne na zprávu "nakafunkce".
nakafunkce(...) je handler vsech zprav. Ocekaval jsem, ze si to domyslite.
Nepochopils.
Název: Re:co si myslite o oop?
Přispěvatel: Mirek Prýmek 24. 12. 2018, 10:43:46
V Javě to bude standardně na tři řádky kvůli uzavírací závorce.
Trochu jsem hledal příklady a zjevně to moc používaný není. Zaujalo mě tohle:

Citace
Under no circumstances should you call the method on the proxy itself since it will be intercepted again by the invocation handler and you will be faced with a StackOverflowError.
https://blog.frankel.ch/the-power-of-proxies-in-java/

Znamená to, že ten objekt nesmí mít jinou metodu než invoke? To by bylo docela hloupý.

Taky, jestli to chápu správně, nemůže vracet primitivní typy.

Tohle do Javy dali lidi z Lighthousu, kteří psali v ObjC a v Sunu po akvizici je donutili psát v Javě.
Je určitě fajn, že to tam přidali. Každopádně škoda už je způsobena: obraty tohodle typu působí exoticky, místo aby byly chápaný jako úplně normální OO zpracování zpráv.
Název: Re:Co si myslíte o OOP?
Přispěvatel: Mirek Prýmek 24. 12. 2018, 10:48:11
nakafunkce(...) je handler vsech zprav. Ocekaval jsem, ze si to domyslite.
No a to je prave to michani urovne implementace a urovne jazyka. O implementaci se nebavime. Semantika predavani zprav samozrejme pomoci funkci implementovat jde. Bylo by nesmyslne tvrdit, ze actor model nejde v mainstreamových jazycích implementovat. To samozřejmě jde, jsou to jazyky turingovsky kompletní :)
Název: Re:co si myslite o oop?
Přispěvatel: BaldSlattery 24. 12. 2018, 11:31:56
Tohle do Javy dali lidi z Lighthousu, kteří psali v ObjC a v Sunu po akvizici je donutili psát v Javě.
Je určitě fajn, že to tam přidali. Každopádně škoda už je způsobena: obraty tohodle typu působí exoticky, místo aby byly chápaný jako úplně normální OO zpracování zpráv.
Za to už Java nemůže. Nicméně tvoje uvažování “nevím o něčem, tak to neexistuje” se ukázalo být chybným, stejně jako “pokud to něco náhodou existuje, je to krkolomné”.
Název: Re:co si myslite o oop?
Přispěvatel: Kiwi 24. 12. 2018, 11:49:21
Tohle do Javy dali lidi z Lighthousu, kteří psali v ObjC a v Sunu po akvizici je donutili psát v Javě.
Je určitě fajn, že to tam přidali. Každopádně škoda už je způsobena: obraty tohodle typu působí exoticky, místo aby byly chápaný jako úplně normální OO zpracování zpráv.
Za to už Java nemůže. Nicméně tvoje uvažování “nevím o něčem, tak to neexistuje” se ukázalo být chybným, stejně jako “pokud to něco náhodou existuje, je to krkolomné”.
Nicméně ten konkrétní příklad, jak na to v Javě, tu zatím nikdo neuvedl. Pouze tu tvrdíte, že to jde.
Název: Re:co si myslite o oop?
Přispěvatel: Mirek Prýmek 24. 12. 2018, 11:57:13
Nicméně tvoje uvažování “nevím o něčem, tak to neexistuje” se ukázalo být chybným
Nepamatuju si, že bych tvrdil, že to v Javě neexistuje. Pamatuju se, že jsem explicitně řekl, že nevím. Nejsem na Javu žádný odborník a děkuju za doplnění, byla to pro mě zajímavá informace.

Každopádně to nic nemění na tom, co jsem tvrdil: neexistuje to v tom smyslu, že tyhle - v původním OOP naprosto běžné a základní - obraty v "mainstream OOP" neexistují v tom smyslu, že nejsou v učebnicích, běžně se (zřejmě) nepoužívají, všechno se drtí dědičností. Původně základní skládání a manipulace se selectory se používá málo nebo vůbec.

Stačí se prostě podívat na nějakou základní učebnici SmallTalku a Javy. Jestli tam někdo nevidí zásadní rozdíl ve způsobu řešení problémů, tak je asi zbytečný ho o tom přesvědčovat.

, stejně jako “pokud to něco náhodou existuje, je to krkolomné”.
Ano, v tomhle jsem se mýlil, to uznávám. Má to nějaká omezení a je to specialita, ne obecná vlastnost všech objektů, ale uživatelsky to není tak nepříjemný, jak jsem čekal.

Ještě je taky otázka, co se děje pod kapotou - jestli je tam nějaká performance penalty oproti normálním metodám.
Název: Re:co si myslite o oop?
Přispěvatel: BaldSlattery 24. 12. 2018, 12:30:36
Tohle do Javy dali lidi z Lighthousu, kteří psali v ObjC a v Sunu po akvizici je donutili psát v Javě.
Je určitě fajn, že to tam přidali. Každopádně škoda už je způsobena: obraty tohodle typu působí exoticky, místo aby byly chápaný jako úplně normální OO zpracování zpráv.
Za to už Java nemůže. Nicméně tvoje uvažování “nevím o něčem, tak to neexistuje” se ukázalo být chybným, stejně jako “pokud to něco náhodou existuje, je to krkolomné”.
Nicméně ten konkrétní příklad, jak na to v Javě, tu zatím nikdo neuvedl. Pouze tu tvrdíte, že to jde.
Trochu jsem se tu v té diskuzi ztratil, jaké bylo zadání?
Název: Re:co si myslite o oop?
Přispěvatel: BaldSlattery 24. 12. 2018, 12:36:30
Nicméně tvoje uvažování “nevím o něčem, tak to neexistuje” se ukázalo být chybným
Nepamatuju si, že bych tvrdil, že to v Javě neexistuje. Pamatuju se, že jsem explicitně řekl, že nevím. Nejsem na Javu žádný odborník a děkuju za doplnění, byla to pro mě zajímavá informace.

Každopádně to nic nemění na tom, co jsem tvrdil: neexistuje to v tom smyslu, že tyhle - v původním OOP naprosto běžné a základní - obraty v "mainstream OOP" neexistují v tom smyslu, že nejsou v učebnicích, běžně se (zřejmě) nepoužívají, všechno se drtí dědičností. Původně základní skládání a manipulace se selectory se používá málo nebo vůbec.

Stačí se prostě podívat na nějakou základní učebnici SmallTalku a Javy. Jestli tam někdo nevidí zásadní rozdíl ve způsobu řešení problémů, tak je asi zbytečný ho o tom přesvědčovat.

, stejně jako “pokud to něco náhodou existuje, je to krkolomné”.
Ano, v tomhle jsem se mýlil, to uznávám. Má to nějaká omezení a je to specialita, ne obecná vlastnost všech objektů, ale uživatelsky to není tak nepříjemný, jak jsem čekal.

Ještě je taky otázka, co se děje pod kapotou - jestli je tam nějaká performance penalty oproti normálním metodám.
Ono se to k tomu prapůvodnímu účelu - distribuovaným objektům - nepoužívá už ani ve Smalltalku nebo ObjC. Performance penalty tam určitě bude, i v ObjC je forwardInvocation řádově pomalejší (ten prapůvodní účel zahrnoval síťovou komunikaci s ještě mnohem větší latencí, tak to nevadilo). Moderní použití proxy je v ObjC například “animátor”, ale protože je ten mechanismus nesnesitelně pomalý, zrychlili to přidáním forwardingTarget. To už v Javě opravdu není, ale zrovna tohle tam asi nikomu nechybí.

Jinak v Javě se to používá pod kapotou, tj. v podstatě jen v knihovnách, kde to je skryté, takže se s tím BFL normálně nesetká (což je asi spíš dobře).
Název: Re:co si myslite o oop?
Přispěvatel: Mirek Prýmek 24. 12. 2018, 13:11:26
Ono se to k tomu prapůvodnímu účelu - distribuovaným objektům
Právěže to není (jediný) prapůvodní účel. Je to technika, která je prapůvodně úplně normální, žádná exotika: já tomu požadavku nerozumím, předám to někomu, kdo to zvládne zpracovat. Použitelné např. pro skládání obecných objektů, jejichž rozhraní pak nemusím znát.

Stejně tak to respondsToSelector. Chci neznámý objekt uložit do pdf? No tak se ho prostě zeptám, jestli to umí. Fakt to musím komplikovat rozhraním ICanSaveToPDFInAWayYouWouldLike nebo ExtremelyComfortSaveableToPDFObjectFactory?

A o tom to právě je, tyhle techniky nikoho dneska ani nenapadnou. Přitom právě tohle je "to OOP", ne nějaká přiblblá dědičnost.
Název: Re:co si myslite o oop?
Přispěvatel: BaldSlattery 24. 12. 2018, 13:23:46
Ono se to k tomu prapůvodnímu účelu - distribuovaným objektům
Právěže to není (jediný) prapůvodní účel. Je to technika, která je prapůvodně úplně normální, žádná exotika
To není pravda, i do původního OOP to přidali až v souvislosti s potřebou DO. RespondsToSelector je něco jiného, to tam původně bylo, ale to je jen introspekce. Nicméně hádat se nebudu, jen v podstatě “překládám” z AJ příslušnou pasáž z knihy Object oriented programming přímo od Coxe. Jinak historie “čistého” OOP včetně toho forwardingu za účelem DO je skvěle popsaná v knize Developing business applications with OpenStep, kterou jsem teď taky oprášil, abych si ověřil, co tu píšu. V té je i historický exkurs o probublání mnoha technik z OpenStepu do Javy. Čili závěr je, že buď prapůvodní účel forwardingu byly výhradně distribuované objekty, nebo Brad Cox lže.
Název: Re:co si myslite o oop?
Přispěvatel: BaldSlattery 24. 12. 2018, 14:01:11
Ono se to k tomu prapůvodnímu účelu - distribuovaným objektům
Právěže to není (jediný) prapůvodní účel. Je to technika, která je prapůvodně úplně normální, žádná exotika: já tomu požadavku nerozumím, předám to někomu, kdo to zvládne zpracovat. Použitelné např. pro skládání obecných objektů, jejichž rozhraní pak nemusím znát.

Stejně tak to respondsToSelector. Chci neznámý objekt uložit do pdf? No tak se ho prostě zeptám, jestli to umí. Fakt to musím komplikovat rozhraním ICanSaveToPDFInAWayYouWouldLike nebo ExtremelyComfortSaveableToPDFObjectFactory?

A o tom to právě je, tyhle techniky nikoho dneska ani nenapadnou. Přitom právě tohle je "to OOP", ne nějaká přiblblá dědičnost.
Jinak další sekundární použití bylo HOM, to se přestalo používat až s příchodem bloků. DO vyšly z módy jako důsledek rozšíření HTTP, takže jediné současné použití je fakt jen ten animátor (to je něco jako doesNotRecognize light, funkčně omezenější, ale zato řádově rychlejší). Ale i to je už skoro historie.
Název: Re:co si myslite o oop?
Přispěvatel: Mirek Prýmek 24. 12. 2018, 14:39:26
Nicméně hádat se nebudu, jen v podstatě “překládám” z AJ příslušnou pasáž z knihy Object oriented programming přímo od Coxe.
A nebylo by lepší tu pasáž prostě odcitovat? Já tu knížku po ruce nemám, takže těžko můžu vědět, co tam píše :)
Název: Re:Co si myslíte o OOP?
Přispěvatel: Michsl2 24. 12. 2018, 14:40:55
Ja jsem na to sel empiricky. Rozdelil jsem si softy na oop/neoop a problemove(bugy, pady, leaky)/bezproblemove. Sam jsem byl prekvapeny jak silna korelace oop->problemy mi z toho vysla.
Název: Re:co si myslite o oop?
Přispěvatel: Mirek Prýmek 24. 12. 2018, 14:55:46
A nebylo by lepší tu pasáž prostě odcitovat?
Každopádně:

Citace
OOP to me means only messaging, local retention and protection and
hiding of state-process, and extreme late-binding of all things. It
can be done in Smalltalk and in LISP. There are possibly other
systems in which this is possible, but I'm not aware of them.
http://userpage.fu-berlin.de/~ram/pub/pub_jf47ht81Ht/doc_kay_oop_en (zvýraznění moje)

"Mainstreamové OOP" nesplňuje ani jedno...
Název: Re:co si myslite o oop?
Přispěvatel: BaldSlattery 24. 12. 2018, 15:02:22
A nebylo by lepší tu pasáž prostě odcitovat? Já tu knížku po ruce nemám, takže těžko můžu vědět, co tam píše :)
To bych se upsal. Ale jak říkám, nemám potřebu někoho přesvědčovat, zvlášť o věcech, které jsou jen historickou kuriozitou.
Název: Re:co si myslite o oop?
Přispěvatel: BaldSlattery 24. 12. 2018, 15:05:03
A nebylo by lepší tu pasáž prostě odcitovat?
Každopádně:

Citace
OOP to me means only messaging, local retention and protection and
hiding of state-process, and extreme late-binding of all things. It
can be done in Smalltalk and in LISP. There are possibly other
systems in which this is possible, but I'm not aware of them.
http://userpage.fu-berlin.de/~ram/pub/pub_jf47ht81Ht/doc_kay_oop_en (zvýraznění moje)

"Mainstreamové OOP" nesplňuje ani jedno...
Begun the language wars have  ::)
Název: Re:co si myslite o oop?
Přispěvatel: Mirek Prýmek 24. 12. 2018, 15:24:23
To bych se upsal. Ale jak říkám, nemám potřebu někoho přesvědčovat, zvlášť o věcech, které jsou jen historickou kuriozitou.
Nejde o přesvědčování, mě to zajímá a třeba i někoho jinýho. Třeba se v něčem zásadně mýlím, v tom případě bych to chtěl vědět. Ten InvactionHandler pro mě taky byla zajímavá informace.
Název: Re:Co si myslíte o OOP?
Přispěvatel: Kit 24. 12. 2018, 15:25:17
Ja jsem na to sel empiricky. Rozdelil jsem si softy na oop/neoop a problemove(bugy, pady, leaky)/bezproblemove. Sam jsem byl prekvapeny jak silna korelace oop->problemy mi z toho vysla.

Pokud by to rozdělení nebylo binární, tak by z toho mohl vylézt zajímavý graf XY. Java ani C# nejsou tak objektové jako Smalltalk. Znamená to snad, že je se Smalltalkem víc problémů?
Název: Re:Co si myslíte o OOP?
Přispěvatel: Youda 24. 12. 2018, 15:26:03
Preju pekne svatky a najdete si nejake zenske.
Název: Re:co si myslite o oop?
Přispěvatel: BaldSlattery 24. 12. 2018, 15:30:04
Třeba se v něčem zásadně mýlím, v tom případě bych to chtěl vědět.
Myslím, že nejsme ve sporu.
Název: Re:co si myslite o oop?
Přispěvatel: Kit 24. 12. 2018, 15:33:14
To bych se upsal. Ale jak říkám, nemám potřebu někoho přesvědčovat, zvlášť o věcech, které jsou jen historickou kuriozitou.
Nejde o přesvědčování, mě to zajímá a třeba i někoho jinýho. Třeba se v něčem zásadně mýlím, v tom případě bych to chtěl vědět. Ten InvactionHandler pro mě taky byla zajímavá informace.

Mne to například také zajímá. V PHP běžně používám magické metody, které se však mnoha vývojářům nelíbí. Přitom podle této diskuze dělají z PHP objektovější jazyk, než je třeba C++, C# nebo Java.
Název: Re:co si myslite o oop?
Přispěvatel: BaldSlattery 24. 12. 2018, 15:50:24
To bych se upsal. Ale jak říkám, nemám potřebu někoho přesvědčovat, zvlášť o věcech, které jsou jen historickou kuriozitou.
Nejde o přesvědčování, mě to zajímá a třeba i někoho jinýho. Třeba se v něčem zásadně mýlím, v tom případě bych to chtěl vědět. Ten InvactionHandler pro mě taky byla zajímavá informace.
Mne to například také zajímá. V PHP běžně používám magické metody, které se však mnoha vývojářům nelíbí. Přitom podle této diskuze dělají z PHP objektovější jazyk, než je třeba C++, C# nebo Java.
Tohle je zase novinka pro mě, vypadá to, že __call v PHP je to samé, co forwardInvocation.
Název: Re:co si myslite o oop?
Přispěvatel: BaldSlattery 24. 12. 2018, 15:56:18
dělají z PHP objektovější jazyk, než je třeba C++, C# nebo Java.
Tak Java má ten forwarding taky a C# má dynamické objekty také už drahně let.  Jen to C++ v tomto zaostává.
Název: Re:Co si myslíte o OOP?
Přispěvatel: Kiwi 24. 12. 2018, 16:41:09
Problém těch mainstreamových "objektových" jazyků je v tom, že se vzal koňský povoz, koně byli nahrazeni traktorem a voila - máme auto. A za moderní výdobytky se považuje, že se to už neřídí opratěmi, ale vozka už má "drahně let" místo nich také volant (jehož pohyby se přenášejí do toho traktoru pomocí provazů). Nedokážu pochopit, že to stádo IT ovcí nevidí a nechce vidět, že toto opravdu není auto a žádnými vylepšními se z toho auto nikdy neudělá, protože je to prostě koncepčně od základů špatně. Vždycky to bude jen koňský povoz, třebaže bez koní. Což je ještě horší, než kdyby to byl normální koňský povoz s koňmi.
Název: Re:Co si myslíte o OOP?
Přispěvatel: BaldSlattery 24. 12. 2018, 16:49:33
Problém těch mainstreamových "objektových" jazyků je v tom, že se vzal koňský povoz, koně byli nahrazeni traktorem a voila - máme auto. A za moderní výdobytky se považuje, že se to už neřídí opratěmi, ale vozka už má "drahně let" místo nich také volant (jehož pohyby se přenášejí do toho traktoru pomocí provazů). Nedokážu pochopit, že to stádo IT ovcí nevidí a nechce vidět, že toto opravdu není auto a žádnými vylepšními se z toho auto nikdy neudělá, protože je to prostě koncepčně od základů špatně. Vždycky to bude jen koňský povoz, třebaže bez koní. Což je ještě horší, než kdyby to byl normální koňský povoz s koňmi.
Až jednou dostuduješ, tak možná různé přístupy k OOP pochopíš. Prozatím uber na agresivitě, za neznalost se stydět nemusíš.
Název: Re:Co si myslíte o OOP?
Přispěvatel: anonym 24. 12. 2018, 16:52:23
Me se libi, jak nemusim ty prkotiny s OOP resit. Delam v robustnim frameworku (Spring) ktery se pouziva uplne vsude, v tom plati nejake best practice toho, jak vlastne tam to OOP bude vypadat (zadne prehnane OOP konstrukce, jen jednoduche konstrukce v ramci IoC), malokdy se stane, ze musim vymyslet nejake kolo na to, jak neco udelat, vyjma business logiky. V Jave na backendu je tolik prace, ze me zadne objevovani kola neceka ani do budoucna na zadne jine platforme - coz nemuze rict kdokoliv z JS/Python/CokolivJineho, jo jeste vyjma C#, tam to maji taky zmaknute dobre. Vlastne veskerou nutnou implementaci mi pokryje framework a jeho best practice, ja si ani nepamatuju, kdy jsem musel pouzit nejake sofistikovanejsi navrhovy vzor, protoze vzdycky vsechno slo udelat jednoduse (Takove ty zakladni vzory jako je Factory nepocitam).

Název: Re:co si myslite o oop?
Přispěvatel: Kit 24. 12. 2018, 17:15:37
V PHP běžně používám magické metody, které se však mnoha vývojářům nelíbí. Přitom podle této diskuze dělají z PHP objektovější jazyk, než je třeba C++, C# nebo Java.
Tohle je zase novinka pro mě, vypadá to, že __call v PHP je to samé, co forwardInvocation.

Zrovna metoda __call() mě napadla, ale je jich tam víc. Ačkoli je nemám rád, tak i __get(), __set() a __isset() jsou skvěle použitelné, protože místo
Kód: [Vybrat]
$article->setTitle("Titulek");
// se dá mnohem pohodlněji a přehledněji zapsat
$article->title = "Titulek";
Zda to přímo ovlivní globální atribut nebo zda se to provede přes interní setter, je už čistě na implementaci objektu. Dají se takto snadno refaktorovat třídy s globálními atributy, včetně možnosti doplnění vhodných dekorátorů.

Na rozdíl od ostatních jazyků metoda __destruct() v PHP skutečně funguje, tedy že okamžitě zneplatní objekt. Zavře tedy i soubory, které jsou v objektu otevřeny - nečeká se, až je GC začne likvidovat. Ostatně se GC často ani nestačí spustit, celá paměť se s ukončením procesu uvolní naráz.
Název: Re:co si myslite o oop?
Přispěvatel: BaldSlattery 24. 12. 2018, 17:46:59
mě to zajímá
K tomu původnímu tvrzení o účelu - Smalltalk původně to doesNotUnderstand neměl, to přidali až do verze Smalltalk-80 (viz stejnojmenná kniha). Kayův důraz na zprávy plyne z toho, že v jeho pojetí měly jít posílat i mimo adresní prostor a třeba i mezi počítači v rámci jedné syntaxe. To doesNotUnderstand byl právě jen implementační detail (z toho pak postupně vzniklo doesNotRecognize, forward, forwardingTarget atd.) a čím dál víc se to zkrkolomnilo (vrcholem je požadavek ObjC implementovat za účelem odchytu zpráv methodSignatureForSelector), jak se postupně naráželo na další technické nedostatky a zádrhely. Ta prvotní verze Smalltalku tedy uměla jen něco jako virtuální metody, protože než začali implementovat Distributed Smalltalk (viz stejnojmenné články a kniha), tak nic dynamičtějšího nepotřebovali.

Jednoznačně se shodneme, že dědičnost se rozšířila jak mor, i když s OOP nemá moc společného. Tímto asi pro dnešek končím, [MerryChristman wishTo: Prymek]  ;)
Název: Re:co si myslite o oop?
Přispěvatel: Mirek Prýmek 24. 12. 2018, 20:06:38
K tomu původnímu tvrzení o účelu [...]
Díky moc za exkurs. Reálně jsem si trochu hrál s ObjectiveC, kolem Smalltalku jsem se jenom lehce šmrncl, takže vědět kdy co přidali, to je fakt daleko za mými obzory ohledně těhle jazyků. Každopádně si ale živě pamatuju, jaký překvapení pro mě bylo, když jsem si prvně o Obj-C něco četl (s nějakou znalostí C++). Ten aha moment: ajó, tak tohle je vlastně to OOP! Wow! ;)

Koukám na Wiki, že Smalltalk-80 byl první veřejně vydaná verze, takže to pořád docela slušně splňuje pojem "původní OOP" ;)

Tímto asi pro dnešek končím, [MerryChristman wishTo: Prymek]  ;)
Tobě a všem ostatním taky, dík.
Název: Re:co si myslite o oop?
Přispěvatel: anonym 24. 12. 2018, 21:29:46
Tímto asi pro dnešek končím, [MerryChristman wishTo: Prymek]  ;)
Tobě a všem ostatním taky, dík.

Hosi tak co to je, nedelejte tu z toho vatikanskou telenovu, tohle je technicke diskuzni forum. Priste jak to uvidim tak to hlasim Krcmimu.
Název: Re:co si myslite o oop?
Přispěvatel: Mirek Prýmek 24. 12. 2018, 23:09:35
Priste jak to uvidim tak to hlasim Krcmimu.
Dobře děláš, protože na vatikánskou telenovelu je u nás pěkně vostrej paragraf.
Název: Re:Co si myslíte o OOP?
Přispěvatel: Mlocik97 25. 12. 2018, 15:22:03
OOP? v zmysle takom, jak sa šmuchtlá vätšinou programátorov v "modernej Jave" je to grc. Ale OOP v pôvodnej myšlienke môže mať výhody pre určité situácie.
Název: Re:Co si myslíte o OOP?
Přispěvatel: anonym 26. 12. 2018, 09:59:55
OOP? v zmysle takom, jak sa šmuchtlá vätšinou programátorov v "modernej Jave" je to grc. Ale OOP v pôvodnej myšlienke môže mať výhody pre určité situácie.

Ty vis prdlacku.
Název: Re:Co si myslíte o OOP?
Přispěvatel: petersonoop 26. 12. 2018, 10:40:28
Chlapci tak vam to tu riadne sibe. 9 vlakien o nicom. Ukazovat a merat si peeero chodte niekam do sauny
Název: Re:Co si myslíte o OOP?
Přispěvatel: Petr 27. 12. 2018, 05:29:35
OOP je dobry sluha a spatny pan. Dobre jsou jazyky, ktere ho umoznuji, ale nevynucuji, takze je mozne ho aplikovat jen na mista a situace, kde je to vyhodne.
Název: Re:Co si myslíte o OOP?
Přispěvatel: MilosZ 27. 12. 2018, 23:31:25
Organizace pro Osvobozeni Palestiny je teroristickou organizaci a ptat se na yo, co si myslim, je velmi prostoduche, az retardovane.
Název: Re:Co si myslíte o OOP?
Přispěvatel: Kit 28. 12. 2018, 02:02:26
OOP je dobry sluha a spatny pan. Dobre jsou jazyky, ktere ho umoznuji, ale nevynucuji, takze je mozne ho aplikovat jen na mista a situace, kde je to vyhodne.

Kadet tady uvedl link na video, ve kterém je prezentováno, jak zbytečné některé třídy mohou být.
https://www.youtube.com/watch?v=o9pEzgHorH0 (https://www.youtube.com/watch?v=o9pEzgHorH0)

Na devel.cz se tazatel ptal na zbytečnost testu. Odpověděl jsem mu, že je zbytečná celá třída a napsal k tomu náhradu na dva řádky. Byl jsem zavalen mínusy, hlavně kvůli tomu, že jsem odpověděl jinak, než se očekávalo. Budiž. Zároveň je z toho vidět, že když osekám třídu tak, že z ní nic nezbyde, tak se to nehodí do mantry OOP.

Mnoho tříd je napsáno tak, že mají několik atributů, ke každému jeden getter a jeden setter. Co to je? Obyčejná struktura. Jen se místo "title = xxx" píše "setTitle(xxx)". Operace s takovou instancí se provádí v další třídě, nejlépe pomocí statických metod. To má být OOP? Ne, je to jen převlečené strukturované programování.

Ani se nedivím, že se vývojáři ozývají, že tohle je fuj. Místo toho, aby napravili chybně aplikované OOP, utíkají k funkcionálnímu programování. Tam už mají své struktury, které mohli mít v objektech. Tam mají i funkce, které používají stejně, jako používali statické metody. Místo tříd mají moduly. Prakticky to používají stejně, jen s úspornějším zápisem. I tu curryfikaci si mohli napsat v OOP, kdyby to zvládli.

V každém paradigmatu se dá napsat dobrý nebo špatný program. Nejlepší výsledky však vychází, pokud je možné paradigmata kombinovat, nejlépe ve vrstvách. Spodní vrstva strukturovaně, mezivrstva funkcionálně, horní vrstva objektově. Proč ne?
Název: Re:Co si myslíte o OOP?
Přispěvatel: harrison314 28. 12. 2018, 09:37:22
OOP je dobry sluha a spatny pan. Dobre jsou jazyky, ktere ho umoznuji, ale nevynucuji, takze je mozne ho aplikovat jen na mista a situace, kde je to vyhodne.

Kadet tady uvedl link na video, ve kterém je prezentováno, jak zbytečné některé třídy mohou být.
https://www.youtube.com/watch?v=o9pEzgHorH0 (https://www.youtube.com/watch?v=o9pEzgHorH0)

Na devel.cz se tazatel ptal na zbytečnost testu. Odpověděl jsem mu, že je zbytečná celá třída a napsal k tomu náhradu na dva řádky. Byl jsem zavalen mínusy, hlavně kvůli tomu, že jsem odpověděl jinak, než se očekávalo. Budiž. Zároveň je z toho vidět, že když osekám třídu tak, že z ní nic nezbyde, tak se to nehodí do mantry OOP.

Mnoho tříd je napsáno tak, že mají několik atributů, ke každému jeden getter a jeden setter. Co to je? Obyčejná struktura. Jen se místo "title = xxx" píše "setTitle(xxx)". Operace s takovou instancí se provádí v další třídě, nejlépe pomocí statických metod. To má být OOP? Ne, je to jen převlečené strukturované programování.

Ani se nedivím, že se vývojáři ozývají, že tohle je fuj. Místo toho, aby napravili chybně aplikované OOP, utíkají k funkcionálnímu programování. Tam už mají své struktury, které mohli mít v objektech. Tam mají i funkce, které používají stejně, jako používali statické metody. Místo tříd mají moduly. Prakticky to používají stejně, jen s úspornějším zápisem. I tu curryfikaci si mohli napsat v OOP, kdyby to zvládli.

V každém paradigmatu se dá napsat dobrý nebo špatný program. Nejlepší výsledky však vychází, pokud je možné paradigmata kombinovat, nejlépe ve vrstvách. Spodní vrstva strukturovaně, mezivrstva funkcionálně, horní vrstva objektově. Proč ne?

Tie minusy si tam dostal pre t, ze namiesto odpovede na otazku si zacal trollovat.
A hlavne nevies ci je ta treda zbytocna lebo nepoznas kontext a hlavne tvoje vedomosti z programovania su dost obmedzene na PHP a male one man show projektiky.
Název: Re:co si myslite o oop?
Přispěvatel: SB 28. 12. 2018, 10:22:26
...Ve skutečném světě je ale spousta jevů, kde žádné identity neexistují a vznikají všelijaké ad-hoc shluky jevů a vlastností (triviální příklad jsou třeba korály nebo shluky nějakých bakterií, kde výraz "jedinec" moc nedává smysl, tím spíš jedinec, který by měl být "věšákem na vlastnosti")...

Při všem respektu k vám je tohle jen vaším nedostatkem fantazie - cokoliv, co jde pojmenovat nebo popsat, jde i modelovat, a to i věci abstraktní.
Název: Re:co si myslite o oop?
Přispěvatel: SB 28. 12. 2018, 11:45:56
...A neni nejlepsi cely ten balast zahodit a rovnou zavolat metodu?

A kterou?
Název: Re:co si myslite o oop?
Přispěvatel: Ondra Satai Nekola 28. 12. 2018, 11:48:26
Vlakno je pouze abstrakce. Muze byt tezkopadne jako unix nebo nt vlakno s velkym stackem, nebo velmi lehka abstrakce v pripade green threadingu.
Ale z pohledu actor systemu bezi kazdy agent ve svem vlakne.
Green threading? A jsme zpet u kooperativniho multitaskingu jako ve win 3.11. A neni nejlepsi cely ten balast zahodit a rovnou zavolat metodu?

Rozdil je trebas v tom, ze u green threads si muzes rozbit aplikaci sam, u 3.11 ti ji mohl sejmout uplne kazdy...
Název: Re:co si myslite o oop?
Přispěvatel: SB 28. 12. 2018, 12:40:04
Ono se to k tomu prapůvodnímu účelu - distribuovaným objektům
Právěže to není (jediný) prapůvodní účel. Je to technika, která je prapůvodně úplně normální, žádná exotika: já tomu požadavku nerozumím, předám to někomu, kdo to zvládne zpracovat. Použitelné např. pro skládání obecných objektů, jejichž rozhraní pak nemusím znát.

Stejně tak to respondsToSelector. Chci neznámý objekt uložit do pdf? No tak se ho prostě zeptám, jestli to umí. Fakt to musím komplikovat rozhraním ICanSaveToPDFInAWayYouWouldLike nebo ExtremelyComfortSaveableToPDFObjectFactory?

A o tom to právě je, tyhle techniky nikoho dneska ani nenapadnou. Přitom právě tohle je "to OOP", ne nějaká přiblblá dědičnost.
Jinak další sekundární použití bylo HOM, to se přestalo používat až s příchodem bloků. DO vyšly z módy jako důsledek rozšíření HTTP, takže jediné současné použití je fakt jen ten animátor (to je něco jako doesNotRecognize light, funkčně omezenější, ale zato řádově rychlejší). Ale i to je už skoro historie.

Co je to HOM?

Osobně to vidím, že jste se buďto spletl, nebo Cox ani nelže, ale spíš nerozumí. Delegace je obecně využitelný mechanismus vyplývající z podstaty objektu jako samostatné jednotky.

Co je animátor, nevím (prosím odkaz), ale další využití je nemalé: Mimo zmiňovaných distrib. objektů (i přes váš názor při komunikaci samostatných objektových systémů (klient-obj. DB, objektoví peers, ...) stále potřebné) např. zmiňovaná proxy, stub, implementace universálního náv. vzoru Nil, vzorů Fasáda, Adaptér.
Název: Re:co si myslite o oop?
Přispěvatel: BaldSlattery 28. 12. 2018, 13:20:45
Co je to HOM?

Cox ani nelže, ale spíš nerozumí. Delegace je obecně využitelný mechanismus vyplývající z podstaty objektu jako samostatné jednotky.

Co je animátor, nevím (prosím odkaz)
HOM je posílání zpráv vyššího řádu (higher order messaging).

Cox je autorem ObjC, takže mu celkem rozumí. Nicméně řec vůbec nebyla o delegaci.

Animator je - přísně vzato - metoda některých tříd GUI vracející proxy animující změny některých vlastností: https://developer.apple.com/documentation/appkit/nsanimatablepropertycontainer/1530511-animator?language=objc
Název: Re:Co si myslíte o OOP?
Přispěvatel: Kit 28. 12. 2018, 13:21:30
Na devel.cz se tazatel ptal na zbytečnost testu. Odpověděl jsem mu, že je zbytečná celá třída a napsal k tomu náhradu na dva řádky. Byl jsem zavalen mínusy, hlavně kvůli tomu, že jsem odpověděl jinak, než se očekávalo. Budiž. Zároveň je z toho vidět, že když osekám třídu tak, že z ní nic nezbyde, tak se to nehodí do mantry OOP.
Tie minusy si tam dostal pre t, ze namiesto odpovede na otazku si zacal trollovat.
A hlavne nevies ci je ta treda zbytocna lebo nepoznas kontext a hlavne tvoje vedomosti z programovania su dost obmedzene na PHP a male one man show projektiky.

Takže velký projekt poznám podle toho, že používá uměle nafouklé třídy?
Název: Re:Co si myslíte o OOP?
Přispěvatel: Ondra Satai Nekola 28. 12. 2018, 13:33:40
Na devel.cz se tazatel ptal na zbytečnost testu. Odpověděl jsem mu, že je zbytečná celá třída a napsal k tomu náhradu na dva řádky. Byl jsem zavalen mínusy, hlavně kvůli tomu, že jsem odpověděl jinak, než se očekávalo. Budiž. Zároveň je z toho vidět, že když osekám třídu tak, že z ní nic nezbyde, tak se to nehodí do mantry OOP.
Tie minusy si tam dostal pre t, ze namiesto odpovede na otazku si zacal trollovat.
A hlavne nevies ci je ta treda zbytocna lebo nepoznas kontext a hlavne tvoje vedomosti z programovania su dost obmedzene na PHP a male one man show projektiky.

Takže velký projekt poznám podle toho, že používá uměle nafouklé třídy?

Ne. Ale vzhledem ke sve omezene zkusenosti nepoznas, kdy je neco umele nafoukle.
Název: Re:co si myslite o oop?
Přispěvatel: Mirek Prýmek 28. 12. 2018, 14:25:31
...Ve skutečném světě je ale spousta jevů, kde žádné identity neexistují a vznikají všelijaké ad-hoc shluky jevů a vlastností (triviální příklad jsou třeba korály nebo shluky nějakých bakterií, kde výraz "jedinec" moc nedává smysl, tím spíš jedinec, který by měl být "věšákem na vlastnosti")...

Při všem respektu k vám je tohle jen vaším nedostatkem fantazie - cokoliv, co jde pojmenovat nebo popsat, jde i modelovat, a to i věci abstraktní.
Tady jde asi o nedorozumění. Neřekl jsem, že to "nejde modelovat", ale že naše obvyklé "substanční" modely jsou pro spoustu jevů reálného života neadekvátní. Kdyby to ti, kdo je používají, věděli a skromně přiznávali, tak by to bylo ok. Ale když se začnou tvářit, že jejich model je tak dobrý, že to snad ani není model, ale ontologie (vystihuje samou podstatu toho, jaký svět je), je to průser.

Příklad:

AFAIK, v ranných fázích vývoje je lidský zárodek shluk buněk, přičemž se může stát, že část tohodle shluku se utrhne a vznikne z něj samostatný jedinec (jednovaječná dvojčata) nebo naopak se vyvíjí dva oddělené shluky, vypadá to na dvojčata, ale pak se z ničehožnic shluky spojí a je z toho ve finále jeden člověk.

Pokud tenhle děj budu chtít modelovat, nemůžu říct, že tam je jedna nebo dvě entity (na které věším vlastnosti), nemůžu určit přesný okamžik, kdy se z jedné staly dvě ani ze dvou jedna. Ani moc nevíme, jak bysme měli vlastnosti dvou splynuvších jedinců mergovat a naopak.

Laicky mám za to, že to je důsledek aristotelismu, který nám pomáhá a zároveň háže klacky pod nohy dodnes. Umíme dobře pracovat se "substancí" a "akcidenty" (i když tomu tak dneska neříkáme), ale moc neumíme konceptualizovat plynulé, těžko definovatelné změny, které mají kvalitativní/ontologickou povahu.
Název: Re:Co si myslíte o OOP?
Přispěvatel: Kit 28. 12. 2018, 14:26:28
Na devel.cz se tazatel ptal na zbytečnost testu. Odpověděl jsem mu, že je zbytečná celá třída a napsal k tomu náhradu na dva řádky. Byl jsem zavalen mínusy, hlavně kvůli tomu, že jsem odpověděl jinak, než se očekávalo. Budiž. Zároveň je z toho vidět, že když osekám třídu tak, že z ní nic nezbyde, tak se to nehodí do mantry OOP.
Tie minusy si tam dostal pre t, ze namiesto odpovede na otazku si zacal trollovat.
A hlavne nevies ci je ta treda zbytocna lebo nepoznas kontext a hlavne tvoje vedomosti z programovania su dost obmedzene na PHP a male one man show projektiky.
Takže velký projekt poznám podle toho, že používá uměle nafouklé třídy?
Ne. Ale vzhledem ke sve omezene zkusenosti nepoznas, kdy je neco umele nafoukle.

Předpokládám, že velké projekty by měly dodržovat zásady SOLID. Uvedený příklad je porušuje.
Název: Re:co si myslite o oop?
Přispěvatel: SB 28. 12. 2018, 16:18:47
Citace
Under no circumstances should you call the method on the proxy itself since it will be intercepted again by the invocation handler and you will be faced with a StackOverflowError.
https://blog.frankel.ch/the-power-of-proxies-in-java/

Znamená to, že ten objekt nesmí mít jinou metodu než invoke? To by bylo docela hloupý.

Co jsem na to koukal a testoval, tak to funguje tak, že každý zastupovaný objekt je zastoupen vždy vlastní instancí (té samé) třídy Proxy, což je jakýsi bastard, který díky neznámé magii (hacku?; souvisí s @CallerSensitive?) nespouští danou metodu, ale údaje o volání vždy předává na navěšený nadefinovaný handler. Tento handler VŽDY spouští metodu invoke, která následně může volat další metody uvedené v něm, ale samy vybrány a spuštěny nejsou.

Celý postup definice a vytvoření proxy má k jednoduchosti ze Smalltalku hodně daleko (koneckonců jako celá reflexivita v Javě), samotná třída Proxy neumožňuje specializaci s překrytím části pro handler či metodu řešící "zprávu", což situaci ještě zhoršuje.
Název: Re:co si myslite o oop?
Přispěvatel: SB 28. 12. 2018, 16:48:53
Cox je autorem ObjC, takže mu celkem rozumí. Nicméně řec vůbec nebyla o delegaci.

Animator je - přísně vzato - metoda některých tříd GUI vracející proxy animující změny některých vlastností: https://developer.apple.com/documentation/appkit/nsanimatablepropertycontainer/1530511-animator?language=objc

Je-li delegací jakékoliv předávání požadavku dalšímu objektu, pak je to i předávání zpráv, kterým objekt nerozumí.

Animátor znamená objekt, který zajišťuje provedení nějaké zvolené posloupnosti změn jiného objektu v času? Chápu to správně? Pak se jedná spíše o adaptér.
Název: Re:co si myslite o oop?
Přispěvatel: SB 28. 12. 2018, 17:05:09
Tady jde asi o nedorozumění. Neřekl jsem, že to "nejde modelovat", ale že naše obvyklé "substanční" modely jsou pro spoustu jevů reálného života neadekvátní. Kdyby to ti, kdo je používají, věděli a skromně přiznávali, tak by to bylo ok. Ale když se začnou tvářit, že jejich model je tak dobrý, že to snad ani není model, ale ontologie (vystihuje samou podstatu toho, jaký svět je), je to průser.

Příklad:

AFAIK, v ranných fázích vývoje je lidský zárodek shluk buněk, přičemž se může stát, že část tohodle shluku se utrhne a vznikne z něj samostatný jedinec (jednovaječná dvojčata) nebo naopak se vyvíjí dva oddělené shluky, vypadá to na dvojčata, ale pak se z ničehožnic shluky spojí a je z toho ve finále jeden člověk.

Pokud tenhle děj budu chtít modelovat, nemůžu říct, že tam je jedna nebo dvě entity (na které věším vlastnosti), nemůžu určit přesný okamžik, kdy se z jedné staly dvě ani ze dvou jedna. Ani moc nevíme, jak bysme měli vlastnosti dvou splynuvších jedinců mergovat a naopak.

Laicky mám za to, že to je důsledek aristotelismu, který nám pomáhá a zároveň háže klacky pod nohy dodnes. Umíme dobře pracovat se "substancí" a "akcidenty" (i když tomu tak dneska neříkáme), ale moc neumíme konceptualizovat plynulé, těžko definovatelné změny, které mají kvalitativní/ontologickou povahu.

Nejdříve je třeba říci, že model je zjednodušením, kdy modeluju jen to, co mi stačí (a i to můžu zprasit - běžný to jev). Vytvořím-li dokonalý model modelující vše, bude nutně zcela identický se vzorem, pak ale nemá smysl vytvářet model, použiju originál.

U vašeho modelu zárodku je třeba především rozmyslet, co chcete modelovat, máte na výběr různou granularitu od dělení genetické informace přes buňky až po celé chuchvalce, záleží, k čemu to bude.

Poslední myšlenka je hlubší než moje duševní schopnost.
Název: Re:co si myslite o oop?
Přispěvatel: BaldSlattery 28. 12. 2018, 18:23:26
Cox je autorem ObjC, takže mu celkem rozumí. Nicméně řec vůbec nebyla o delegaci.

Animator je - přísně vzato - metoda některých tříd GUI vracející proxy animující změny některých vlastností: https://developer.apple.com/documentation/appkit/nsanimatablepropertycontainer/1530511-animator?language=objc

Je-li delegací jakékoliv předávání požadavku dalšímu objektu
Ale to (v OOP) není.
Název: Re:co si myslite o oop?
Přispěvatel: BaldSlattery 28. 12. 2018, 18:24:30
Cox je autorem ObjC, takže mu celkem rozumí. Nicméně řec vůbec nebyla o delegaci.

Animator je - přísně vzato - metoda některých tříd GUI vracející proxy animující změny některých vlastností: https://developer.apple.com/documentation/appkit/nsanimatablepropertycontainer/1530511-animator?language=objc

Animátor znamená objekt, který zajišťuje provedení nějaké zvolené posloupnosti změn jiného objektu v času? Chápu to správně? Pak se jedná spíše o adaptér.
Je to jen proxy udělaná pomocí forward, viz dokumentace.
Název: Re:co si myslite o oop?
Přispěvatel: Youda 28. 12. 2018, 22:23:56
Tady jde asi o nedorozumění. Neřekl jsem, že to "nejde modelovat", ale že naše obvyklé "substanční" modely jsou pro spoustu jevů reálného života neadekvátní. Kdyby to ti, kdo je používají, věděli a skromně přiznávali, tak by to bylo ok. Ale když se začnou tvářit, že jejich model je tak dobrý, že to snad ani není model, ale ontologie (vystihuje samou podstatu toho, jaký svět je), je to průser.

Příklad:

AFAIK, v ranných fázích vývoje je lidský zárodek shluk buněk, přičemž se může stát, že část tohodle shluku se utrhne a vznikne z něj samostatný jedinec (jednovaječná dvojčata) nebo naopak se vyvíjí dva oddělené shluky, vypadá to na dvojčata, ale pak se z ničehožnic shluky spojí a je z toho ve finále jeden člověk.

Pokud tenhle děj budu chtít modelovat, nemůžu říct, že tam je jedna nebo dvě entity (na které věším vlastnosti), nemůžu určit přesný okamžik, kdy se z jedné staly dvě ani ze dvou jedna. Ani moc nevíme, jak bysme měli vlastnosti dvou splynuvších jedinců mergovat a naopak.

Laicky mám za to, že to je důsledek aristotelismu, který nám pomáhá a zároveň háže klacky pod nohy dodnes. Umíme dobře pracovat se "substancí" a "akcidenty" (i když tomu tak dneska neříkáme), ale moc neumíme konceptualizovat plynulé, těžko definovatelné změny, které mají kvalitativní/ontologickou povahu.

Nejdříve je třeba říci, že model je zjednodušením, kdy modeluju jen to, co mi stačí (a i to můžu zprasit - běžný to jev). Vytvořím-li dokonalý model modelující vše, bude nutně zcela identický se vzorem, pak ale nemá smysl vytvářet model, použiju originál.

U vašeho modelu zárodku je třeba především rozmyslet, co chcete modelovat, máte na výběr různou granularitu od dělení genetické informace přes buňky až po celé chuchvalce, záleží, k čemu to bude.

Poslední myšlenka je hlubší než moje duševní schopnost.

Jakozto absolvent Kybernetiky u Marika mam nejake matne tuseni o modelovani a o Teorii systemu.
Vasi debatu ctu s uzasem.
Jsou tyto vase texty mysleny jako variace na pividku Woodyho Allena: "Kdyby byli impresioniste dentisty", nebo jste ozrali?
Název: Re:co si myslite o oop?
Přispěvatel: Mirek Prýmek 29. 12. 2018, 06:09:34
Nejdříve je třeba říci, že model je zjednodušením, kdy modeluju jen to, co mi stačí (a i to můžu zprasit - běžný to jev). Vytvořím-li dokonalý model modelující vše, bude nutně zcela identický se vzorem, pak ale nemá smysl vytvářet model, použiju originál.

U vašeho modelu zárodku je třeba především rozmyslet, co chcete modelovat, máte na výběr různou granularitu od dělení genetické informace přes buňky až po celé chuchvalce, záleží, k čemu to bude.
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.
Název: Re:co si myslite o oop?
Přispěvatel: Mirek Prýmek 29. 12. 2018, 06:11:10
Jsou tyto vase texty mysleny jako variace na pividku Woodyho Allena: "Kdyby byli impresioniste dentisty", nebo jste ozrali?
Konstruktivnější reakce (co konkrétně se ti nezdá, nebo čemu nerozumíš) by pro debatu byla cennější.
Název: Re:co si myslite o oop?
Přispěvatel: I/O 29. 12. 2018, 11:22:26
Jsou tyto vase texty mysleny jako variace na pividku Woodyho Allena: "Kdyby byli impresioniste dentisty", nebo jste ozrali?
Konstruktivnější reakce (co konkrétně se ti nezdá, nebo čemu nerozumíš) by pro debatu byla cennější.
https://www.youtube.com/watch?v=8Z-YjkS2wzI
Název: Re:Co si myslíte o OOP?
Přispěvatel: oss 29. 12. 2018, 12:27:54
Ked je OOP zo Smalltalku tak super hyper uzasne pre co sa (smalltalk) nepouziva?
Název: Re:Co si myslíte o OOP?
Přispěvatel: anonym 29. 12. 2018, 12:44:58
Podle me zasadni pristup v OOP, ktery dodal do tohoto modelovani tu spravnou konzistenci, je Inversion of Control. Diky IoC je totiz vlastne mozne redukovat OOP na jednoduchou plochou architekturu bez slozitych konstrukci, ktera nasledne tvori zaklad cele aplikace. Rozdeli to design na Funkce a Data. Tim se proste nikdy neda nic zkazit, je to VZDY prehledne. Nasledne sofistikovanejsi OOP konstrukce se pouzivaji, az pokud jsou vylozene k necemu prospesne. IoC umoznuje psat jednoduse a dava prostor otazce "Je tato OOP konstrukce (navrhovy vzor) pro aplikaci prospesnejsi, nez jednoduche IoC?" Pokud je, tak PAK JI TEPRVE pouziju, pokud ne (ve vetsine pripadu), pokracuje se v ploche IoC architekture. Zaroven je IoC takovy navrat ke korenum programovani, a to jsou prave ty Funkce a Data, ktere tu byly odjakziva. Dala by se na tom nakreslit (vyzivova) pyramida, kde spodni patro by nalezelo prave tomuto Funkce+Data designu.

Hosi, podle me tu resite veci, ktere se uz resily, v praxi v Jave (a obslehl to posleze C#) uz pred mnoha lety ve Spring frameworku.

A taky neni pravda, ze sofistikovane OOP konstrukce se k nicemu nehodi. Vsak se podivejte na Javu a .NET standardni knihovny, jaka to je nadhera. To je OOP vazeni! Srovnejte to s tema srackama co jsou v Javascriptu a pak tady pindejte neco o tom jak je OOP spatne. To je totiz typicke degenerativni binarni mysleni programatoru, ze nedokazou pochopit, ze neco DOzadekE neni bud a nebo, ale ze je tam ku*va SKALA. Kdyz si nejste vedomi toho, ze OOP je takto skalovatelne, tak tomu dpc NEROZUMITE.
Název: Re:co si myslite o oop?
Přispěvatel: Unknown 29. 12. 2018, 13:10:17
Jsou tyto vase texty mysleny jako variace na pividku Woodyho Allena: "Kdyby byli impresioniste dentisty", nebo jste ozrali?
Konstruktivnější reakce (co konkrétně se ti nezdá, nebo čemu nerozumíš) by pro debatu byla cennější.
https://www.youtube.com/watch?v=8Z-YjkS2wzI

Vy jste to taky nepochopil?
Název: Re:Co si myslíte o OOP?
Přispěvatel: Kit 29. 12. 2018, 13:18:11
Podle me zasadni pristup v OOP, ktery dodal do tohoto modelovani tu spravnou konzistenci, je Inversion of Control. Diky IoC je totiz vlastne mozne redukovat OOP na jednoduchou plochou architekturu bez slozitych konstrukci, ktera nasledne tvori zaklad cele aplikace. Rozdeli to design na Funkce a Data. Tim se proste nikdy neda nic zkazit, je to VZDY prehledne. Nasledne sofistikovanejsi OOP konstrukce se pouzivaji, az pokud jsou vylozene k necemu prospesne. IoC umoznuje psat jednoduse a dava prostor otazce "Je tato OOP konstrukce (navrhovy vzor) pro aplikaci prospesnejsi, nez jednoduche IoC?" Pokud je, tak PAK JI TEPRVE pouziju, pokud ne (ve vetsine pripadu), pokracuje se v ploche IoC architekture. Zaroven je IoC takovy navrat ke korenum programovani, a to jsou prave ty Funkce a Data, ktere tu byly odjakziva. Dala by se na tom nakreslit (vyzivova) pyramida, kde spodni patro by nalezelo prave tomuto Funkce+Data designu.

Nepopisuješ IoC v OOP, ale strukturované programování. Klidně zůstaň u C, Pascalu nebo Fortranu.
Název: Re:co si myslite o oop?
Přispěvatel: hawran diskuse 29. 12. 2018, 13:51:19
...
https://www.youtube.com/watch?v=8Z-YjkS2wzI
Doufám, že ten idiot, o kterém se tam mluví, nebude mít i novorční projev.

Končit starý a začínat rok nový tou samou duševní žumpou a verbalním průjmem by už bylo moc...
Název: Re:co si myslite o oop?
Přispěvatel: I/O 29. 12. 2018, 13:52:14
Jsou tyto vase texty mysleny jako variace na pividku Woodyho Allena: "Kdyby byli impresioniste dentisty", nebo jste ozrali?
Konstruktivnější reakce (co konkrétně se ti nezdá, nebo čemu nerozumíš) by pro debatu byla cennější.
https://www.youtube.com/watch?v=8Z-YjkS2wzI

Vy jste to taky nepochopil?

Pochopil jsem, že se tady mezi sebou hádá banda rotných Maňasů.
Název: Re:co si myslite o oop?
Přispěvatel: Kit 29. 12. 2018, 13:59:00
...
https://www.youtube.com/watch?v=8Z-YjkS2wzI
Doufám, že ten idiot, o kterém se tam mluví, nebude mít i novorční projev.

Končit starý a začínat rok nový tou samou duševní žumpou a verbalním průjmem by už bylo moc...

Nebude. Kromě toho máš možnost se na to nekoukat a neposlouchat, prostě to ignorovat. Jak jednoduché.
Název: Re:co si myslite o oop?
Přispěvatel: anonym 29. 12. 2018, 14:19:48
...
https://www.youtube.com/watch?v=8Z-YjkS2wzI
Doufám, že ten idiot, o kterém se tam mluví, nebude mít i novorční projev.

Končit starý a začínat rok nový tou samou duševní žumpou a verbalním průjmem by už bylo moc...

Jednou budes taky takovy, rika se tomu senilita. Ja Zemana volil a vedel jsem, ze senilita uz na nej leze, ale Drahos proste nebyl lepsi, bohuzel. To co predvedl Drahos v duelech, a cela jeho kampan zalozena z vetsiny na kritice soucasneho prezidenta, byla dost zalostna. Kdyz nekdo nekoho takhle kritizuje, mel by to dokazat delat lepe, ale Drahos predvedl jen naprosty debakl.
Název: Re:co si myslite o oop?
Přispěvatel: hawran diskuse 29. 12. 2018, 15:09:26
...
Nebude. Kromě toho máš možnost se na to nekoukat a neposlouchat, prostě to ignorovat. Jak jednoduché.
Uff, ještě že tak.

(a neboj, dobrovolně se na takové hrůzy nedívám)
Název: Re:co si myslite o oop?
Přispěvatel: hawran diskuse 29. 12. 2018, 15:10:31
... debakl.
:) ;) :D ;D
Tak určitě.
Název: Re:Co si myslíte o OOP?
Přispěvatel: Kit 29. 12. 2018, 15:24:18
Ked je OOP zo Smalltalku tak super hyper uzasne pre co sa (smalltalk) nepouziva?

Zkus ho chvíli používat a možná na to přijdeš. Syntaxe používání objektů je v něm elegantně jednoduchá, ale způsob psaní vlastních tříd už tak triviální není. Zápis je dost odlišný od dnešních jazyků.

V každém případě má smysl se Smalltalk naučit (podobně jako Lisp) aby sis vytvořil určitý nadhled, který pak využiješ třeba v Javě. Ovšem musím varovat před tím, že se ti pak Java možná zhnusí.
Název: Re:Co si myslíte o OOP?
Přispěvatel: BaldSlattery 29. 12. 2018, 15:37:02
neco DOzadekE neni bud a nebo, ale ze je tam ku*va SKALA
Scala? Ta je funkcionální.
Název: Re:Co si myslíte o OOP?
Přispěvatel: BaldSlattery 29. 12. 2018, 15:37:49
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í.
  ;D
Název: Re:Co si myslíte o OOP?
Přispěvatel: Ondra Satai Nekola 29. 12. 2018, 15:42:02
neco DOzadekE neni bud a nebo, ale ze je tam ku*va SKALA
Scala? Ta je funkcionální.

Scala je multiparadigmatická.
Název: Re:Co si myslíte o OOP?
Přispěvatel: Kiwi 29. 12. 2018, 16:15:45
Ked je OOP zo Smalltalku tak super hyper uzasne pre co sa (smalltalk) nepouziva?
Zkus si něco nastudovat o marketingu, byl bys vyléčen z iluzí, že o úspěchu produktu rozhoduje jeho kvalita.
Název: Re:Co si myslíte o OOP?
Přispěvatel: anonym 29. 12. 2018, 20:38:47
Ked je OOP zo Smalltalku tak super hyper uzasne pre co sa (smalltalk) nepouziva?
Zkus si něco nastudovat o marketingu, byl bys vyléčen z iluzí, že o úspěchu produktu rozhoduje jeho kvalita.

Mohl by jsi uvezt priklad z oblasti sw inzenyrstvi, kde nejaky produkt mel hlavne dobry marketing, ale jinak nestal za moc?
Název: Re:Co si myslíte o OOP?
Přispěvatel: anonym 29. 12. 2018, 20:39:25
(a presto ze nestal za moc, tak se masove rozsiril)
Název: Re:Co si myslíte o OOP?
Přispěvatel: Mirek Prýmek 29. 12. 2018, 20:39:30
Mohl by jsi uvezt priklad z oblasti sw inzenyrstvi, kde nejaky produkt mel hlavne dobry marketing, ale jinak nestal za moc?
Windows.
Název: Re:Co si myslíte o OOP?
Přispěvatel: anonym 29. 12. 2018, 20:41:08
Mohl by jsi uvezt priklad z oblasti sw inzenyrstvi, kde nejaky produkt mel hlavne dobry marketing, ale jinak nestal za moc?
Windows.

Haaahahahaa. Ja nejsem pametnik jako Kiwi, ale pokud je mi znamo, v dobe rozmachu dosu a posleze windows Linuxy byly predrazene mrchy, ktere si nikdo nemohl dovolit. Pokud vim, tak na to same dojel i Sun se svym Solaris. Tohle urcite neni pripad marketingu a bulikovani neceho verejnosti, nemuzes oddelit kvalitu produktu od jeho ceny.
Název: Re:Co si myslíte o OOP?
Přispěvatel: anonym 29. 12. 2018, 20:41:35
pardon, rikam Linuxy a myslim Unixy...
Název: Re:Co si myslíte o OOP?
Přispěvatel: Mirek Prýmek 29. 12. 2018, 20:46:34
Těch možností bylo víc: OS/2, MacOS, BeOS, NeXT, ... Jinak ne všechny UNIXy byly drahé, bylo i BSD.
Víceméně všechny alternativy byly technicky lepší než "grafická nadstavba DOSu" jménem Windows.
Název: Re:Co si myslíte o OOP?
Přispěvatel: anonym 29. 12. 2018, 20:48:32
Těch možností bylo víc: OS/2, MacOS, BeOS, NeXT, ... Jinak ne všechny UNIXy byly drahé, bylo i BSD.
Víceméně všechny alternativy byly technicky lepší než "grafická nadstavba DOSu" jménem Windows.

Dobre, to neumim posoudit, ale je tady jeste jedna kvalita, a ta se skryva v tom "tech moznosti bylo nekolik" - standardizace a to, ze kazdy ma svem PC jediny OS, a to je Windows, namisto toho, aby tech OS bylo celkem 10 ruznych, se taky ceni.
Název: Re:Co si myslíte o OOP?
Přispěvatel: Mirek Prýmek 29. 12. 2018, 20:49:53
Dobre, to neumim posoudit, ale je tady jeste jedna kvalita, a ta se skryva v tom "tech moznosti bylo nekolik" - standardizace a to, ze kazdy ma svem PC jediny OS, a to je Windows, namisto toho, aby tech OS bylo celkem 10 ruznych, se taky ceni.
Jistě, ale to byl až důsledek toho marketingového vítězství technicky horšího produktu.
Název: Re:Co si myslíte o OOP?
Přispěvatel: anonym 29. 12. 2018, 20:54:25
Dobre, to neumim posoudit, ale je tady jeste jedna kvalita, a ta se skryva v tom "tech moznosti bylo nekolik" - standardizace a to, ze kazdy ma svem PC jediny OS, a to je Windows, namisto toho, aby tech OS bylo celkem 10 ruznych, se taky ceni.
Jistě, ale to byl až důsledek toho marketingového vítězství technicky horšího produktu.

Ale jak vis, kolik stal, a jaky treba v porovnani poskytoval servis? A dalsi vec je, proc si tedy ty dalsi OS taky neudelaly marketing? Nebylo to nahodou proto, ze byli neschopni?

Ja si pod tim pejorativnim slovem marketing predstavim, ze me nekdo vlastne uvadi v omyl a prodava mi za vetsi penize nejakou plecku. Pochybuju, ze tohle byl priklad Windows a Dosu. Bylo to proste pro lidi urcite z nejakych duvodu vyhodnejsi.
Název: Re:Co si myslíte o OOP?
Přispěvatel: anonym 29. 12. 2018, 21:07:38
Proste kdyz X tvych znamych maji DOS, tak ty si taky koupis pocitac, kde je DOS, protoze to lze taky povazovat za projev kvality produktu, ze budes mit to same co ma 9 z 10 tvych znamych. A pokud to neco je popularni obecne a ma to dobry marketing, muzes si to koupit a vlastne si tim "vsadit na sveho kone", s tim, ze predpokladas, ze casem se to mnohem vyklepsi a jeste vice rozsiri. A to lze taky povazovat za urcity typ kvality.
Název: Re:Co si myslíte o OOP?
Přispěvatel: Inkvizitor 29. 12. 2018, 21:18:14
Těch možností bylo víc: OS/2, MacOS, BeOS, NeXT, ... Jinak ne všechny UNIXy byly drahé, bylo i BSD.
Víceméně všechny alternativy byly technicky lepší než "grafická nadstavba DOSu" jménem Windows.

Ale Mirku... BeOS byla jednouživatelská hračka pro omezené spektrum využití, MacOS nestabilní OS se složitou správou RAM a kooperativním multitaskingem (jeho další přežití bylo neudržitelné, tak Apple udělal kompletní remake nad Unixem), OS/2 měl dost vysoké nároky na RAM a byl poměrně drahý. NeXT nemá smysl rozebírat vůbec. Je potřeba si přiznat, že Windows v něčem prostě byly a asi stále jsou nejlepší. Nic z Tebou nastíněných "alternativ" nemá tak vymakanou podporu korporátního prostředí a kromě Macu se nic z toho nechytá v oblasti počítačů na doma, jakmile má člověk větší nároky na portfolio použitelného HW nebo profi SW. To píšu jako člověk, který se používání Windows snaží vyhýbat jak může a Gatese s Ballmerem přímo nesnáší. Microsoft možná na začátku prodal klon trapného osmibitového OS, ale dost tvrdě makal na svých produktech a rozhodně nebyl zdaleka ve všem horší.
Název: Re:Co si myslíte o OOP?
Přispěvatel: BaldSlattery 29. 12. 2018, 22:04:12
Těch možností bylo víc: OS/2, MacOS, BeOS, NeXT, ... Jinak ne všechny UNIXy byly drahé, bylo i BSD.
Víceméně všechny alternativy byly technicky lepší než "grafická nadstavba DOSu" jménem Windows.
NeXT nemá smysl rozebírat vůbec.
Ten jediný za něco stál (akorát se jmenoval NeXTSTEP).
Název: Re:Co si myslíte o OOP?
Přispěvatel: Inkvizitor 29. 12. 2018, 22:07:12
NeXT nemá smysl rozebírat vůbec.
Ten jediný za něco stál (akorát se jmenoval NeXTSTEP).

Z technického hlediska určitě zajímavý, to nepopírám. Ale z obchodního hlediska podle mě odsouzený k neúspěchu - vývoj šel prostě jinudy.
Název: Re:Co si myslíte o OOP?
Přispěvatel: BaldSlattery 29. 12. 2018, 22:17:18
NeXT nemá smysl rozebírat vůbec.
Ten jediný za něco stál (akorát se jmenoval NeXTSTEP).
Z technického hlediska určitě zajímavý, to nepopírám. Ale z obchodního hlediska podle mě odsouzený k neúspěchu - vývoj šel prostě jinudy.
Jeho přejmenovaná verze dnes běží na 100 milionech počítačů, to není tak úplně neúspěch.
Název: Re:Co si myslíte o OOP?
Přispěvatel: Mirek Prýmek 29. 12. 2018, 23:04:33
Ale Mirku... BeOS byla jednouživatelská hračka pro omezené spektrum využití, MacOS nestabilní OS se složitou správou RAM a kooperativním multitaskingem
Tak jistě, ale musíš srovnávat produkty vydané ve stejné době. "Masová" (tj. ne-NT) verze Windows měla preemptivní multitasking až od Windows 95 a že by ty nějak oplývaly stabilitou, to ani nemám uplně pocit :)

a byl poměrně drahý
Nojo, jenže o tom právě jsou ty business decisions. Kdyby si tenkrát IBM nehrálo na exkluzivní OS, ale dalo by ho za babku a ke svému železu zdarma, kdoví, jakou cestou by vývoj šel.

---
Nicméně to je dost OT, radši už to rozvíjet nebudu :)
Název: Re:Co si myslíte o OOP?
Přispěvatel: Inkvizitor 29. 12. 2018, 23:09:28
Tak jistě, ale musíš srovnávat produkty vydané ve stejné době. "Masová" (tj. ne-NT) verze Windows měla preemptivní multitasking až od Windows 95 a že by ty nějak oplývaly stabilitou, to ani nemám uplně pocit :)

No OK, Windows 9x šly do háje a nikdo rozumný slzu neuroní. Jde o to, že Microsoft už v roce 93 vydal NT a včas přepřáhnul. To bylo v zásadě geniální. Nechci to už taky rozpitvávat (ani využití Nextstepu v MacOS X). Mějte se hezky, sejdeme se možná příště u jiného topicu.
Název: Re:Co si myslíte o OOP?
Přispěvatel: JS 30. 12. 2018, 17:27:01
Mohl by jsi uvezt priklad z oblasti sw inzenyrstvi, kde nejaky produkt mel hlavne dobry marketing, ale jinak nestal za moc?

Z ktere oblasti chces priklad? MS-DOS, Windows 95, MS Word, MS Excel, PHP, IE, VB, ASP, Javascript, Eclipse, Hadoop, MongoDB..

Ke kazde z tech veci v te dobe existovaly podstatne lepsi alternativy, jen byly (z toho ci onoho duvodu = marketing) mene zname.
Název: Re:Co si myslíte o OOP?
Přispěvatel: tulip 30. 12. 2018, 17:53:17
Z ktere oblasti chces priklad? MS-DOS, Windows 95, MS Word, MS Excel, PHP, IE, VB, ASP, Javascript, Eclipse, Hadoop, MongoDB..

Me by zajimal ten Hadoop (bez ironie). Rozvedl bys to?
Název: Re:Co si myslíte o OOP?
Přispěvatel: anonym 30. 12. 2018, 18:43:10
Mohl by jsi uvezt priklad z oblasti sw inzenyrstvi, kde nejaky produkt mel hlavne dobry marketing, ale jinak nestal za moc?

Z ktere oblasti chces priklad? MS-DOS, Windows 95, MS Word, MS Excel, PHP, IE, VB, ASP, Javascript, Eclipse, Hadoop, MongoDB..

Ke kazde z tech veci v te dobe existovaly podstatne lepsi alternativy, jen byly (z toho ci onoho duvodu = marketing) mene zname.

Me by zajimala ta lepsi alternativa sve doby ke vsemu z toho, co jsi uvedl.
Název: Re:Co si myslíte o OOP?
Přispěvatel: Mirek Prýmek 30. 12. 2018, 19:29:13
Me by zajimal ten Hadoop (bez ironie). Rozvedl bys to?
Mě taky. Dneska alternativy jsou (minimálně znám Spark a Flink), ale ty jsou IIRC pozdějšího data.
Název: Re:Co si myslíte o OOP?
Přispěvatel: Ondra Satai Nekola 30. 12. 2018, 20:01:01
Me by zajimal ten Hadoop (bez ironie). Rozvedl bys to?
Mě taky. Dneska alternativy jsou (minimálně znám Spark a Flink), ale ty jsou IIRC pozdějšího data.
Nejen pozdejsi, ale v produkci typicky navic nad Hadoopem (resp. nad HDFS a YARNem).
Název: Re:Co si myslíte o OOP?
Přispěvatel: operator 30. 12. 2018, 20:18:42
Mohl by jsi uvezt priklad z oblasti sw inzenyrstvi, kde nejaky produkt mel hlavne dobry marketing, ale jinak nestal za moc?

Z ktere oblasti chces priklad? MS-DOS, Windows 95, MS Word, MS Excel, PHP, IE, VB, ASP, Javascript, Eclipse, Hadoop, MongoDB..

Ke kazde z tech veci v te dobe existovaly podstatne lepsi alternativy, jen byly (z toho ci onoho duvodu = marketing) mene zname.
Co lepsiho bylo k php a js? Imho to neposuzujes komplexne.
Název: Re:Co si myslíte o OOP?
Přispěvatel: Honza 30. 12. 2018, 20:24:38
Co lepsiho bylo k php a js? Imho to neposuzujes komplexne.
No tak tohle je zrovna špatný příklad. JS se používá naopak právě proto, že nic jiného v prohlížečích pro skripty není. A také to není důkaz jeho "kvality".
Název: Re:Co si myslíte o OOP?
Přispěvatel: Mlocik97 30. 12. 2018, 20:30:37
Co lepsiho bylo k php a js? Imho to neposuzujes komplexne.
No tak tohle je zrovna špatný příklad. JS se používá naopak právě proto, že nic jiného v prohlížečích pro skripty není. A také to není důkaz jeho "kvality".

absolútny nesúhlas.
Citace
JS se používá naopak právě proto, že nic jiného v prohlížečích pro skripty není
,... v prohlížečích se používa JS, protože práve není nič lepšího čo by v prohlížečích mohlo bežať.
Název: Re:Co si myslíte o OOP?
Přispěvatel: Kit 30. 12. 2018, 20:43:06
Citace
JS se používá naopak právě proto, že nic jiného v prohlížečích pro skripty není
,... v prohlížečích se používa JS, protože práve není nič lepšího čo by v prohlížečích mohlo bežať.

Dovedu si představit, že by v prohlížečích běhal Lisp. Byla by to paráda.
Název: Re:Co si myslíte o OOP?
Přispěvatel: Kiwi 30. 12. 2018, 21:01:36
Citace
JS se používá naopak právě proto, že nic jiného v prohlížečích pro skripty není
,... v prohlížečích se používa JS, protože práve není nič lepšího čo by v prohlížečích mohlo bežať.

Dovedu si představit, že by v prohlížečích běhal Lisp. Byla by to paráda.
V prohlížečích by mohl být nějakou VM zpracováván nějaký bytekód, do kterého by mohlo být překládáno z čehokoli. Bylo by to jednodušší, univerzálnější a nenáročnější jak na objem dat přepravovaných po síti, tak na výkon počítačů. Ale často mám u některých řešení pocit, že jsou to vítězové soutěže o nejhloupěji navržený kus SW.
Název: Re:Co si myslíte o OOP?
Přispěvatel: anonym 30. 12. 2018, 21:17:30
Citace
JS se používá naopak právě proto, že nic jiného v prohlížečích pro skripty není
,... v prohlížečích se používa JS, protože práve není nič lepšího čo by v prohlížečích mohlo bežať.

Dovedu si představit, že by v prohlížečích běhal Lisp. Byla by to paráda.
V prohlížečích by mohl být nějakou VM zpracováván nějaký bytekód, do kterého by mohlo být překládáno z čehokoli. Bylo by to jednodušší, univerzálnější a nenáročnější jak na objem dat přepravovaných po síti, tak na výkon počítačů. Ale často mám u některých řešení pocit, že jsou to vítězové soutěže o nejhloupěji navržený kus SW.

Tak to snad je webassembly, ne? To je i snad ten duvod, proc je takovy rozmach jazyku co se umi kompilovat do "webu". (jsem Javista, takze me napada Kotlin)
Název: Re:Co si myslíte o OOP?
Přispěvatel: Kit 30. 12. 2018, 21:38:02
Tak to snad je webassembly, ne? To je i snad ten duvod, proc je takovy rozmach jazyku co se umi kompilovat do "webu". (jsem Javista, takze me napada Kotlin)

Pro vývoj webu bych se vyhnul všemu, co je typováno staticky.
Název: Re:Co si myslíte o OOP?
Přispěvatel: Mlocik97 30. 12. 2018, 21:40:45
Tak to snad je webassembly, ne? To je i snad ten duvod, proc je takovy rozmach jazyku co se umi kompilovat do "webu". (jsem Javista, takze me napada Kotlin)

Pro vývoj webu bych se vyhnul všemu, co je typováno staticky.

Tys napsal v tomto vlákne rozumný komentár. WOW  :) //
Název: Re:Co si myslíte o OOP?
Přispěvatel: anonym 30. 12. 2018, 21:43:16
Tak to snad je webassembly, ne? To je i snad ten duvod, proc je takovy rozmach jazyku co se umi kompilovat do "webu". (jsem Javista, takze me napada Kotlin)

Pro vývoj webu bych se vyhnul všemu, co je typováno staticky.

Tak, musime si ujasnit, co je to vyvoj webu. J si pod vyvojem webu predstavuju tvorbu webovych stranek, coz je dostatecne obecny pojem na to, abych si pod tim predstavil i webove stranky slouzici jako frontend pro informacni systemy, jako jsou napr. v bankach a telco. A pri vyvoji IS bych se ja osnobne vyhnul vsemu, co naopak neni staticky typovane.
Název: Re:Co si myslíte o OOP?
Přispěvatel: Kit 30. 12. 2018, 21:43:55
Dovedu si představit, že by v prohlížečích běhal Lisp. Byla by to paráda.
V prohlížečích by mohl být nějakou VM zpracováván nějaký bytekód, do kterého by mohlo být překládáno z čehokoli. Bylo by to jednodušší, univerzálnější a nenáročnější jak na objem dat přepravovaných po síti, tak na výkon počítačů. Ale často mám u některých řešení pocit, že jsou to vítězové soutěže o nejhloupěji navržený kus SW.

Takže by se po linkách přenášel binární bajtkód? To se mi nejeví jako dobré řešení a ani nevidím úsporu při transportu.
Název: Re:Co si myslíte o OOP?
Přispěvatel: Kit 30. 12. 2018, 21:49:22
Tak, musime si ujasnit, co je to vyvoj webu. J si pod vyvojem webu predstavuju tvorbu webovych stranek, coz je dostatecne obecny pojem na to, abych si pod tim predstavil i webove stranky slouzici jako frontend pro informacni systemy, jako jsou napr. v bankach a telco. A pri vyvoji IS bych se ja osnobne vyhnul vsemu, co naopak neni staticky typovane.

Statické typování se hodí pro strukturované programování, ale já raději používám OOP, ve kterém je lepší typovat dynamicky.
Název: Re:Co si myslíte o OOP?
Přispěvatel: Kiwi 30. 12. 2018, 21:52:18
Dovedu si představit, že by v prohlížečích běhal Lisp. Byla by to paráda.
V prohlížečích by mohl být nějakou VM zpracováván nějaký bytekód, do kterého by mohlo být překládáno z čehokoli. Bylo by to jednodušší, univerzálnější a nenáročnější jak na objem dat přepravovaných po síti, tak na výkon počítačů. Ale často mám u některých řešení pocit, že jsou to vítězové soutěže o nejhloupěji navržený kus SW.

Takže by se po linkách přenášel binární bajtkód? To se mi nejeví jako dobré řešení a ani nevidím úsporu při transportu.
Proč?
Název: Re:Co si myslíte o OOP?
Přispěvatel: BaldSlattery 30. 12. 2018, 21:54:36
Tak to snad je webassembly, ne? To je i snad ten duvod, proc je takovy rozmach jazyku co se umi kompilovat do "webu". (jsem Javista, takze me napada Kotlin)

Pro vývoj webu bych se vyhnul všemu, co je typováno staticky.
A důvod?
Název: Re:Co si myslíte o OOP?
Přispěvatel: Kadet 30. 12. 2018, 22:00:41
Doporucuju si precist tohle od Alana Kaye. Jeho nazor na web prohlizece. Prohlizec je operacni system, nebo alespon jeho vrstva. Je to prostredi, ve kterym bezi aplikace, izolovane od sebe. Presna definice OS. Tak proc znovu vynalezat kolo.

http://www.drdobbs.com/architecture-and-design/interview-with-alan-kay/240003442?pgno=2
Název: Re:Co si myslíte o OOP?
Přispěvatel: Kit 30. 12. 2018, 22:05:11
Dovedu si představit, že by v prohlížečích běhal Lisp. Byla by to paráda.
V prohlížečích by mohl být nějakou VM zpracováván nějaký bytekód, do kterého by mohlo být překládáno z čehokoli. Bylo by to jednodušší, univerzálnější a nenáročnější jak na objem dat přepravovaných po síti, tak na výkon počítačů. Ale často mám u některých řešení pocit, že jsou to vítězové soutěže o nejhloupěji navržený kus SW.
Takže by se po linkách přenášel binární bajtkód? To se mi nejeví jako dobré řešení a ani nevidím úsporu při transportu.
Proč?

Textový formát je pro přenos přece jen trochu úspornější. Kde by tedy docházelo ke kompilaci? Na serveru nebo až na klientovi?
Název: Re:Co si myslíte o OOP?
Přispěvatel: Kit 30. 12. 2018, 22:08:43
Pro vývoj webu bych se vyhnul všemu, co je typováno staticky.
A důvod?

Důvod je ten, že nemám důvod pro statické typování. Ničemu to neprospěje a jen to hází klacky pod nohy.
Název: Re:Co si myslíte o OOP?
Přispěvatel: Kiwi 30. 12. 2018, 22:33:21
Doporucuju si precist tohle od Alana Kaye. Jeho nazor na web prohlizece. Prohlizec je operacni system, nebo alespon jeho vrstva. Je to prostredi, ve kterym bezi aplikace, izolovane od sebe. Presna definice OS. Tak proc znovu vynalezat kolo.

http://www.drdobbs.com/architecture-and-design/interview-with-alan-kay/240003442?pgno=2
Asi před rokem jsem tady na rootu v jiné diskusi, kde se řešilo něco podobného, odcitoval tento Kayův názor, aniž bych schválně uvedl autora.  Naprostá většina čitatelů hodnotila červeným palcem. "Chtěl by pohánět loď parou! Blázen."

Dovedu si představit, že by v prohlížečích běhal Lisp. Byla by to paráda.
V prohlížečích by mohl být nějakou VM zpracováván nějaký bytekód, do kterého by mohlo být překládáno z čehokoli. Bylo by to jednodušší, univerzálnější a nenáročnější jak na objem dat přepravovaných po síti, tak na výkon počítačů. Ale často mám u některých řešení pocit, že jsou to vítězové soutěže o nejhloupěji navržený kus SW.
Takže by se po linkách přenášel binární bajtkód? To se mi nejeví jako dobré řešení a ani nevidím úsporu při transportu.
Proč?

Textový formát je pro přenos přece jen trochu úspornější. Kde by tedy docházelo ke kompilaci? Na serveru nebo až na klientovi?
Úspornější? Co je pro boha úspornějšího na tom, když se po netu valí sem a tam pořád dokola ty samé tagy v podobě mnohabajtových stringů, jmen funkcí, proměnných, klíčových slov, syntaktického cukru, komentářů a jiného balastu, jehož sémantika se dá zachytit doslova pár bajty, nebo by se dal eliminovat zcela?

Ke kompilaci kódu by docházelo pokud možno přímo u autora kódu. Prohlížeč by obsahoval pouze VM.

Koncept webu, tak jak to vymysleli v CERNu, je IMHO jeden z největších omylů IT za posledních 30 let. A další ukázka toho, jak se může i naprosto nemožná technologie masově rozšířit.
Název: Re:Co si myslíte o OOP?
Přispěvatel: Kit 30. 12. 2018, 22:54:37
Textový formát je pro přenos přece jen trochu úspornější. Kde by tedy docházelo ke kompilaci? Na serveru nebo až na klientovi?
Úspornější? Co je pro boha úspornějšího na tom, když se po netu valí sem a tam pořád dokola ty samé tagy v podobě mnohabajtových stringů, jmen funkcí, proměnných, klíčových slov, syntaktického cukru, komentářů a jiného balastu, jehož sémantika se dá zachytit doslova pár bajty, nebo by se dal eliminovat zcela?

Ke kompilaci kódu by docházelo pokud možno přímo u autora kódu. Prohlížeč by obsahoval pouze VM.

Ty mnohabajtové stringy se docela dobře komprimují během přenosu. Kromě toho je velké množství skriptů a stylů minifikováno, když se dělá deploy. Jedno- či dvouznakový identifikátor zabere méně místa než celý node či odkaz na něj. Když porovnáš velikost souboru .java a .class, tak to moc velký rozdíl není, podobně jako .py vs. .pyc. Zdrojáky se však lépe komprimují.
Název: Re:Co si myslíte o OOP?
Přispěvatel: BaldSlattery 30. 12. 2018, 22:59:47
Doporucuju si precist tohle od Alana Kaye. Jeho nazor na web prohlizece. Prohlizec je operacni system, nebo alespon jeho vrstva. Je to prostredi, ve kterym bezi aplikace, izolovane od sebe. Presna definice OS. Tak proc znovu vynalezat kolo.

http://www.drdobbs.com/architecture-and-design/interview-with-alan-kay/240003442?pgno=2
Asi před rokem jsem tady na rootu v jiné diskusi, kde se řešilo něco podobného, odcitoval tento Kayův názor, aniž bych schválně uvedl autora.  Naprostá většina čitatelů hodnotila červeným palcem. "Chtěl by pohánět loď parou! Blázen."

Dovedu si představit, že by v prohlížečích běhal Lisp. Byla by to paráda.
V prohlížečích by mohl být nějakou VM zpracováván nějaký bytekód, do kterého by mohlo být překládáno z čehokoli. Bylo by to jednodušší, univerzálnější a nenáročnější jak na objem dat přepravovaných po síti, tak na výkon počítačů. Ale často mám u některých řešení pocit, že jsou to vítězové soutěže o nejhloupěji navržený kus SW.
Takže by se po linkách přenášel binární bajtkód? To se mi nejeví jako dobré řešení a ani nevidím úsporu při transportu.
Proč?

Textový formát je pro přenos přece jen trochu úspornější. Kde by tedy docházelo ke kompilaci? Na serveru nebo až na klientovi?
Úspornější? Co je pro boha úspornějšího na tom, když se po netu valí sem a tam pořád dokola ty samé tagy v podobě mnohabajtových stringů, jmen funkcí, proměnných, klíčových slov, syntaktického cukru, komentářů a jiného balastu, jehož sémantika se dá zachytit doslova pár bajty, nebo by se dal eliminovat zcela?

Ke kompilaci kódu by docházelo pokud možno přímo u autora kódu. Prohlížeč by obsahoval pouze VM.

Koncept webu, tak jak to vymysleli v CERNu, je IMHO jeden z největších omylů IT za posledních 30 let. A další ukázka toho, jak se může i naprosto nemožná technologie masově rozšířit.
  Bez uvedení autora to není citace. Navíc Kay nic takového neřekl, nanejvýš apud.
Název: Re:Co si myslíte o OOP?
Přispěvatel: Kiwi 30. 12. 2018, 23:30:00
Textový formát je pro přenos přece jen trochu úspornější. Kde by tedy docházelo ke kompilaci? Na serveru nebo až na klientovi?
Úspornější? Co je pro boha úspornějšího na tom, když se po netu valí sem a tam pořád dokola ty samé tagy v podobě mnohabajtových stringů, jmen funkcí, proměnných, klíčových slov, syntaktického cukru, komentářů a jiného balastu, jehož sémantika se dá zachytit doslova pár bajty, nebo by se dal eliminovat zcela?

Ke kompilaci kódu by docházelo pokud možno přímo u autora kódu. Prohlížeč by obsahoval pouze VM.

Ty mnohabajtové stringy se docela dobře komprimují během přenosu. Kromě toho je velké množství skriptů a stylů minifikováno, když se dělá deploy. Jedno- či dvouznakový identifikátor zabere méně místa než celý node či odkaz na něj. Když porovnáš velikost souboru .java a .class, tak to moc velký rozdíl není, podobně jako .py vs. .pyc. Zdrojáky se však lépe komprimují.
Tak jednak je potom otázkou, zda javovský či pythoní bytekód je vhodný etalon (osobně ho nepovažuji za nic ideálního a strukturu .class jsem nestudoval, abych dokázal posoudit, kolik balastu obsahuje) - avšak sám, jakožto embeďák, můžu často porovnávat binární kód pro mikrořadiče s korespondujícím zdrojákem v C či C++. A tam je to celkem jasné. Pokud poměr u relativně hutného (oproti strojovému kódu) bytekódu nevychází dobře oproti zdrojáku, asi je něco špatně. Abych jen nekritizoval, tak za zdařilý považuji bytekód jazyka Lua.

A jednak je nevhodná celková koncepce, kdy statický web složitými kličkami dynamizuji. Komprimace je sice hezká, ale neřeší podstatu problému.

Bez uvedení autora to není citace. Navíc Kay nic takového neřekl, nanejvýš apud.
Takže většina toho, čemu říkáme citáty, zvláště ty latinské, vlastně podle tebe vůbec citáty nejsou. Prosím, držme se obecně přijímaného významu slov a nevymýšlej si pro ně své vlastní definice. Ale nešť - tak jsem přeparafrázoval Kayovy názory na to, jak by podle něj mohl vypadat web. Proč jsem schválně autora neuvedl, je snad zřejmé - většina lidí ani nemá svůj názor, jen kýve či kroutí podle toho, kdo daný názor vysloví. A to dnes bohužel platí i v politice a umění.
Název: Re:Co si myslíte o OOP?
Přispěvatel: BoneFlute 30. 12. 2018, 23:33:22
Statické typování se hodí pro strukturované programování, ale já raději používám OOP, ve kterém je lepší typovat dynamicky.

Tak já bych se s dovolením od této blbosti odpíchl, a zeptal se vás na názor.

V čem je dynamické typování, či případně netypování, užitečné? Za mě jsem dospěl k závěru, že jsou to dvě situace:
1. Erlang dokáže za chodu opravovat/upravovat kód. A autoři prohlásili, že tam typy nedali, protože se jim nepovedlo vymyslet jak na to.
2. Někdy se hodí, zejména na prototypování, když jsou typy volitelné, a následně to při refactoringu upřesňovat. Protože ze začátku člověk třeba nemá jasno, jak to má vypadat, a tak samozřejmě dost dobře nemůže ty typy určit.

Kromě těchto dvou scénářů nevím o ničem, kdy by netypování (př. dynamické typování) bylo užitečné.

Co myslíte vy?
Název: Re:Co si myslíte o OOP?
Přispěvatel: anonym 30. 12. 2018, 23:36:57
Tak, musime si ujasnit, co je to vyvoj webu. J si pod vyvojem webu predstavuju tvorbu webovych stranek, coz je dostatecne obecny pojem na to, abych si pod tim predstavil i webove stranky slouzici jako frontend pro informacni systemy, jako jsou napr. v bankach a telco. A pri vyvoji IS bych se ja osnobne vyhnul vsemu, co naopak neni staticky typovane.

Statické typování se hodí pro strukturované programování, ale já raději používám OOP, ve kterém je lepší typovat dynamicky.

U slozitych IS je rozhodny faktor poradek v cem to jen jde, muze to byt klidne tezkopadne a casoe narocnejsi na implementaci, ale jak by v tom byl bordel jako u webdevelopmentu, tak by se ti to vratilo nasobne na tezsi udrzbe. Narocnost SW vyvoje roste exponencialni se slozitosti domeny, kterou ma resit, ne linearne.
Název: Re:Co si myslíte o OOP?
Přispěvatel: Kiwi 30. 12. 2018, 23:51:56
Statické typování se hodí pro strukturované programování, ale já raději používám OOP, ve kterém je lepší typovat dynamicky.

Tak já bych se s dovolením od této blbosti odpíchl, a zeptal se vás na názor.

V čem je dynamické typování, či případně netypování, užitečné? Za mě jsem dospěl k závěru, že jsou to dvě situace:
1. Erlang dokáže za chodu opravovat/upravovat kód. A autoři prohlásili, že tam typy nedali, protože se jim nepovedlo vymyslet jak na to.
2. Někdy se hodí, zejména na prototypování, když jsou typy volitelné, a následně to při refactoringu upřesňovat. Protože ze začátku člověk třeba nemá jasno, jak to má vypadat, a tak samozřejmě dost dobře nemůže ty typy určit.

Kromě těchto dvou scénářů nevím o ničem, kdy by netypování (př. dynamické typování) bylo užitečné.

Co myslíte vy?
V OOP je dynamické typování opravdu výhodnější - kvůli polymorfismu a velmi pozdní vazbě. Zatímco ve strukturovaných jazycích typu Pascal obvykle předpokládám určitý typ dat na určitém místě a situace, kdy tomu tak není, jsou spíše výjimečné, v objektovém přístupu je tomu přesně naopak. Pokud toto není aspoň v nějaké omezené formě umožněno (jako v C++ či v Javě), tak se vůbec nedá mluvit o objektovém programování.

Jinými slovy, zatímco v klasickém přístupu chci pole integerů a případ, kdy bych chtěl pole nějakých obecných prvků, je více či méně krkolomný, u objektového přístupu chci primárně pole nějakých obecných prvků a když budu chtít, aby tam byly jen integery, budu si to muset nějak (více či méně krkolomně) pohlídat.
Název: Re:Co si myslíte o OOP?
Přispěvatel: Kit 30. 12. 2018, 23:53:15
Ty mnohabajtové stringy se docela dobře komprimují během přenosu. Kromě toho je velké množství skriptů a stylů minifikováno, když se dělá deploy. Jedno- či dvouznakový identifikátor zabere méně místa než celý node či odkaz na něj. Když porovnáš velikost souboru .java a .class, tak to moc velký rozdíl není, podobně jako .py vs. .pyc. Zdrojáky se však lépe komprimují.
Tak jednak je potom otázkou, zda javovský či pythoní bytekód je vhodný etalon (osobně ho nepovažuji za nic ideálního a strukturu .class jsem nestudoval, abych dokázal posoudit, kolik balastu obsahuje) - avšak sám, jakožto embeďák, můžu často porovnávat binární kód pro mikrořadiče s korespondujícím zdrojákem v C či C++. A tam je to celkem jasné. Pokud poměr u relativně hutného (oproti strojovému kódu) bytekódu nevychází dobře oproti zdrojáku, asi je něco špatně. Abych jen nekritizoval, tak za zdařilý považuji bytekód jazyka Lua.

A jednak je nevhodná celková koncepce, kdy statický web složitými kličkami dynamizuji. Komprimace je sice hezká, ale neřeší podstatu problému.

Vzal jsem používané bajtkódy. Samozřejmě je možné vymyslet jednodušší a kratší bajtkód, viz tvůj binární kód pro mikrořadiče. Jenže když do něj doplníš vlastnosti, které jsou dnes po něm požadovány, tak z něj zase vznikne moloch. Přenášený zdroják spíš vnímám jako serializovaný derivační strom. Když ho má číst člověk, tak je dobré ho mít upravený i graficky, ale pokud ho má číst jen stroj, tak je to vcelku jedno.

Co bys považoval za dobrou alternativu k dynamizovanému statickému webu?
Název: Re:Co si myslíte o OOP?
Přispěvatel: BoneFlute 31. 12. 2018, 00:04:23
V OOP je dynamické typování opravdu výhodnější - kvůli polymorfismu a velmi pozdní vazbě.
Nenašel jsem situaci, kdy by pozdní vazba bránila typům. Můžeš uvést příklad?

Jinými slovy, zatímco v klasickém přístupu chci pole integerů a případ, kdy bych chtěl pole nějakých obecných prvků, je více či méně krkolomný, u objektového přístupu chci primárně pole nějakých obecných prvků a když budu chtít, aby tam byly jen integery, budu si to muset nějak (více či méně krkolomně) pohlídat.
Nevidím důvod, proč by ty obecné prvky neměli mít patřičný typ. Mám komponentu, do které chci vkládat různé widgety. Tak bude dozajisté užitečné, když mi to tam pustí jen widgety (input, textarea, datepicker, timepicker, calendar, grid, form, ...), a integer nikoliv.
Název: Re:Co si myslíte o OOP?
Přispěvatel: Kit 31. 12. 2018, 00:07:02
Statické typování se hodí pro strukturované programování, ale já raději používám OOP, ve kterém je lepší typovat dynamicky.
V čem je dynamické typování, či případně netypování, užitečné?

Zeptám se opačně: V čem je užitečné statické typování? Že je typ ověřen už při překladu? To přece testy dovedou také a to mnohem lépe. Kromě toho jazyků s kvalitním staticky typováním je poměrně málo, například Java mezi ně nepatří. Vždyť u ní si ani nemohu odvodit vlastní typ!

Nepleť si dynamické typování s netypováním. Je v tom docela zásadní rozdíl. U dynamického typování si ten typ každá proměnná nese s sebou a normálně se s ním pracuje. Reflexe je u dynamického typování naprosto běžným nástrojem. Odpadají také problémy s používáním přetěžování.
Název: Re:Co si myslíte o OOP?
Přispěvatel: Kit 31. 12. 2018, 00:11:32
V OOP je dynamické typování opravdu výhodnější - kvůli polymorfismu a velmi pozdní vazbě.
Nenašel jsem situaci, kdy by pozdní vazba bránila typům. Můžeš uvést příklad?

Řeč je o velmi pozdní vazbě, kterou staticky typované jazyky prakticky neznají.
Název: Re:Co si myslíte o OOP?
Přispěvatel: Kit 31. 12. 2018, 00:17:06
Nevidím důvod, proč by ty obecné prvky neměli mít patřičný typ. Mám komponentu, do které chci vkládat různé widgety. Tak bude dozajisté užitečné, když mi to tam pustí jen widgety (input, textarea, datepicker, timepicker, calendar, grid, form, ...), a integer nikoliv.

Však ty obecné prvky mají patřičný dynamický typ. Proč bych měl mezi widgety strkat integer?
Název: Re:Co si myslíte o OOP?
Přispěvatel: anonym 31. 12. 2018, 00:25:16
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 :D

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 8) 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  8)
Název: Re:Co si myslíte o OOP?
Přispěvatel: Kit 31. 12. 2018, 00:32:34
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  8)

Za kvalitní objektový jazyk považuji Python a kousek za ním PHP. Java ani C# nevede programátory k OOP, ale ke strukturovanému programování. 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í.
Název: Re:Co si myslíte o OOP?
Přispěvatel: BoneFlute 31. 12. 2018, 00:37:16
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 co popisuješ není dobrá definice. Vejdou se do toho snad všechny funkcionální jazyky. A možná i mnoho dalších neOOP.
Název: Re:Co si myslíte o OOP?
Přispěvatel: BoneFlute 31. 12. 2018, 00:40:35
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 :D

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 8) 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  8)

Tak snad nemusí být hned tak zle. Mě to jen připomělo, že občas narážím na hlasy, které obhajují dynamické typování. A já bych si někdy opravdu docela rád vyslechl v čem je to užitečné. (Čímž díky @Kiwi-mu za pokus o vysvětlení, ačkoliv to zatím nestačilo :-) )
Název: Re:Co si myslíte o OOP?
Přispěvatel: BaldSlattery 31. 12. 2018, 00:45:52
Takže většina toho, čemu říkáme citáty, zvláště ty latinské, vlastně podle tebe vůbec citáty nejsou. Prosím, držme se obecně přijímaného významu slov a nevymýšlej si pro ně své vlastní definice. Ale nešť - tak jsem přeparafrázoval Kayovy názory
Souhlas, tak si nevymýšlej nesmysly. Definice: “Citát je doslovné znění z díla spisovatele, anebo doslovně zopakovaný výrok. [...] Při citování se uvádí jak autor, tak i dílo v kterém se výrok objevil.” Tohle jsi měl mít na ZŠ (předpokládám, žes ji úspěšně ukončil), asi to fakt jde s naším školstvím od 5 k 0.
Název: Re:Co si myslíte o OOP?
Přispěvatel: BaldSlattery 31. 12. 2018, 00:50:29
Ajeje, uz tu zacina akademicka debata.
  Begun the language wars have  ;D
Název: Re:Co si myslíte o OOP?
Přispěvatel: Kadet 31. 12. 2018, 00:50:55
k statickymu typovani.

Jediny, kdy jsem ho pouzil, bylo na vytvoreni nejaky vysoce optimalizovany funkce, nejakyho tight loopu, kterej jsem pak stejne volal z Pythonu.

Dobrej priklad kde staticky typovani naprosto selhava jsou silne variabilni datovy struktury. Proste prace s json daty. To co mi posilaji nektery backend apj jsou jsony o deseti urovnich a skutecne nemam silu na to mapovat tohlr monstrum na nejakej muj class nebo haskell type.

Pokud by mi nekdo doporucil pouzit dynamickej typ Node (string -> string|int|list|Node), tak je to akorat pouziti dynamickyho typovani, akorat v jazyce, kterej na to bude daleko hur stavenej, nez jazyk vytvorenej pro praci s dicts.
Název: Re:Co si myslíte o OOP?
Přispěvatel: anonym 31. 12. 2018, 00:53:21
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  8)

Za kvalitní objektový jazyk považuji Python a kousek za ním PHP. Java ani C# nevede programátory k OOP, ale ke strukturovanému programování. 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í.

Dochazi ti vubec ta vec, ze dpc co ma jako byt, ze to vede ke strukturovanemu programovani a ne k OOP? Protoze ja dam ruku do ohne, ze tohle je PRAVZE UMYSL a ze je to SAKRA LEPSI. Chapes ty vubec, ze mas nejakou svou zarytou premisu, ze kdyz to neni ciste OOP, tak je to spatne? A kde jsu tu premisu jako vzal? Protoze me prijde, ze je tady jasny trend, ze od OOP, a myslim tim ted to puritanske paradigma, se ustupuje uz nekolik let jak v Jave, tak v C#. Tomu se rika stredni cesta, jestlis o tom nekdy neslysel. A dam vsadil bych se ze proto, ze se lidi sw inzenyri napric celou industry vic a vic shodli, ze to proste je takhle LEPSI. A kdyz je to takhle LEPSI, tak je to proste LEPSI.
Název: Re:Co si myslíte o OOP?
Přispěvatel: BoneFlute 31. 12. 2018, 01:24:32
Dobrej priklad kde staticky typovani naprosto selhava jsou silne variabilni datovy struktury. Proste prace s json daty. To co mi posilaji nektery backend apj jsou jsony o deseti urovnich a skutecne nemam silu na to mapovat tohlr monstrum na nejakej muj class nebo haskell type.
No a co pak s tím děláš? Máš strukturu struktury struktur. A to by mělo mít nějaký význam, ne? Třeba a.b.c je klíč pro nějakou konkrétní konkfiguraci (třeba). Takže to potom čekuješ ručně?

Můžeš prosím rozvést to "naprosto selhává"? Tak trochu v tom čuchám "nechce se mi to definovat, tak to nechám vágní, a řešit to budu potom...".
Název: Re:Co si myslíte o OOP?
Přispěvatel: Kadet 31. 12. 2018, 01:31:56
Dobrej priklad kde staticky typovani naprosto selhava jsou silne variabilni datovy struktury. Proste prace s json daty. To co mi posilaji nektery backend apj jsou jsony o deseti urovnich a skutecne nemam silu na to mapovat tohlr monstrum na nejakej muj class nebo haskell type.
No a co pak s tím děláš? Máš strukturu struktury struktur. A to by mělo mít nějaký význam, ne? Třeba a.b.c je klíč pro nějakou konkrétní konkfiguraci (třeba). Takže to potom čekuješ ručně?

Můžeš prosím rozvést to "naprosto selhává"? Tak trochu v tom čuchám "nechce se mi to definovat, tak to nechám vágní, a řešit to budu potom...".

Chci z jsonu ziskat a.b.c

1. nechapu proc bych mel definovat typ nekolika urovnovyho jsonu
2. pokud to nebudu typovat ale budu s tim pracovat jako s dynamickym typem, pak mi statickej jazyk nijak nepomoh. naopak mi to zneprijemnil hloupyma hlaska a pri kompilaci
Název: Re:Co si myslíte o OOP?
Přispěvatel: BoneFlute 31. 12. 2018, 01:51:55
Dobrej priklad kde staticky typovani naprosto selhava jsou silne variabilni datovy struktury. Proste prace s json daty. To co mi posilaji nektery backend apj jsou jsony o deseti urovnich a skutecne nemam silu na to mapovat tohlr monstrum na nejakej muj class nebo haskell type.
No a co pak s tím děláš? Máš strukturu struktury struktur. A to by mělo mít nějaký význam, ne? Třeba a.b.c je klíč pro nějakou konkrétní konkfiguraci (třeba). Takže to potom čekuješ ručně?

Můžeš prosím rozvést to "naprosto selhává"? Tak trochu v tom čuchám "nechce se mi to definovat, tak to nechám vágní, a řešit to budu potom...".

Chci z jsonu ziskat a.b.c

1. nechapu proc bych mel definovat typ nekolika urovnovyho jsonu
2. pokud to nebudu typovat ale budu s tim pracovat jako s dynamickym typem, pak mi statickej jazyk nijak nepomoh. naopak mi to zneprijemnil hloupyma hlaska a pri kompilaci

1. protože aby si dostal a.b.c a ne třeba a.b.x
2. to je tautologie. Já znám jen dvě možnosti: statickej typ= vím, že je tam a.b.c, dynamický typ: nevím nic. Tudíž, aby si to mohl zpracovat musíš tu informaci dodat dodatečně ručně. V čem ti dynamický typ pomohl?

Připomenu, já samozřejmě můžu ve statickém jazyce veškeré informace ignorovat, a pracovat jen s tuplem. (Sám si to zmiňoval "Node (string -> string|int|list|Node)"). Ale to pak znamená, jestli to chápu dobře, že jen a pouze chcetš si tu kontrolu dělat sám. To je veškerá výhoda dynamického typování? Možnost dělat si všechno ručně?

--
edit: jak si to po sobě čtu, možná by byl lepší výraz "záruka" na místo "vím". Protože já samozřejmě o té hodnotě můžu evidovat co je to za typ. Ale stroj s tím víc nepracuje.
Název: Re:Co si myslíte o OOP?
Přispěvatel: Kadet 31. 12. 2018, 02:16:36
Dobrej priklad kde staticky typovani naprosto selhava jsou silne variabilni datovy struktury. Proste prace s json daty. To co mi posilaji nektery backend apj jsou jsony o deseti urovnich a skutecne nemam silu na to mapovat tohlr monstrum na nejakej muj class nebo haskell type.
No a co pak s tím děláš? Máš strukturu struktury struktur. A to by mělo mít nějaký význam, ne? Třeba a.b.c je klíč pro nějakou konkrétní konkfiguraci (třeba). Takže to potom čekuješ ručně?

Můžeš prosím rozvést to "naprosto selhává"? Tak trochu v tom čuchám "nechce se mi to definovat, tak to nechám vágní, a řešit to budu potom...".

Chci z jsonu ziskat a.b.c

1. nechapu proc bych mel definovat typ nekolika urovnovyho jsonu
2. pokud to nebudu typovat ale budu s tim pracovat jako s dynamickym typem, pak mi statickej jazyk nijak nepomoh. naopak mi to zneprijemnil hloupyma hlaska a pri kompilaci

1. protože aby si dostal a.b.c a ne třeba a.b.x
2. to je tautologie. Já znám jen dvě možnosti: statickej typ= vím, že je tam a.b.c, dynamický typ: nevím nic. Tudíž, aby si to mohl zpracovat musíš tu informaci dodat dodatečně ručně. V čem ti dynamický typ pomohl?

Připomenu, já samozřejmě můžu ve statickém jazyce veškeré informace ignorovat, a pracovat jen s tuplem. (Sám si to zmiňoval "Node (string -> string|int|list|Node)"). Ale to pak znamená, jestli to chápu dobře, že jen a pouze chcetš si tu kontrolu dělat sám. To je veškerá výhoda dynamického typování? Možnost dělat si všechno ručně?

--
edit: jak si to po sobě čtu, možná by byl lepší výraz "záruka" na místo "vím". Protože já samozřejmě o té hodnotě můžu evidovat co je to za typ. Ale stroj s tím víc nepracuje.

1. kdyz tam chybi a.b.c, tak mi to muze vratit treba null a vubec se nebudu zlobit
2. popravde tvoji vetu nechapu. Nepotrebuju zadnou informaci dodavat. To, co se skryva pod a.b.c ma svuj dynamicky typ a to mi staci, abych a tim pracoval. Pokud a.b.c neexistuje, vrati mi to null, keyerror nebo jinou takovou hodnotu.

Nechapu kde jsi vytah, ze jsem tvrdil neco o 'veskerych vyhodach dynamickych jazyku'. Tvrdil jsem pouze, ze staticky jazyky v tomhle selhavaji a kazdej normalni clovek by pouzil 'tuple' misto definovanu tyou cely struktury. Tj. sahnul by po dynamickym typovani.
Název: Re:Co si myslíte o OOP?
Přispěvatel: Kiwi 31. 12. 2018, 02:50:08
Co bys považoval za dobrou alternativu k dynamizovanému statickému webu?
Zahodit koncept webového prohlížeče a nahradit ho pouhou VM, zahodit koncept webových stránek a nahradit je kompletně jednotným standardizovaným bytekódem appletů, které ať si každý píše, v čem mu to vyhovuje/co je pro daný účel nejvýhodnější, doplnit o podepsané knihovny (dostupné transparentně z dotazovaného serveru či odjinud), vše spravované na straně klienta systémem cache. Webová stránka, jež je ze své podstaty pouhým označkovaným textem, by tak byla nahrazena plnohodnotným programem.

Applet, který jen zobrazí analogii statického webu, by nebyl o nic složitější ani delší než současný web. Odpadly by všelijaké CSS, cookies, flashe a podobné nesmysly. Při přístupu k portálu (třeba jako root.cz) by došlo jen ke stažení dat, protože veškerý kód by byl nacachovaný u klienta včetně potřebných knihoven. Zjednodušila by se komunikace klient-server i klientA-server-klientB, klient-klient apod. Zjednodušilo by se sdílení dat. Ne, že by řada z toho dnes nešla zařídit, praxe si to vynutila, ale děje se tak často neuvěřitelně krkolomnými způsoby. Což je i důvod, proč si myslím, že se jednodušší řešení při masovém rozšíření toho současného nemá šanci rozšířit - prostě protože nějak to jde i tak.

protoze nic lepsiho vymysleneho nebylo 8)
Právě že bylo.  :) Jestliže tytéž problémy vyřeším na třetině LOC a za pětinu času, tak ať mě nikdo nepřesvědčuje, že nepracuji s lepším nástrojem. Dlouhé roky jsem dělal v C++, backendy i frontendy, embedded i PC, pamatuji Turbo Vision i OWL, jásal jsem nad Qt... Něco málo (ve srovnání s objemem práce v C++) jsem dělal v Javě a v C#. Ale když to srovnám s věcmi jako Cocoa v Objective C nebo smalltalkovými frameworky, tak je to prostě parní stroj versus parní turbína - základní myšlenka je sice stejná, ale jsou tam jisté velmi podstatné rozdíly.

V OOP je dynamické typování opravdu výhodnější - kvůli polymorfismu a velmi pozdní vazbě.
Nenašel jsem situaci, kdy by pozdní vazba bránila typům. Můžeš uvést příklad?
Už to tu zmiňoval Kit. Spíš jde o ty přívlastky statický/dynamický. Rozdíl bych viděl asi v tom, že ve statickém případě se v daném místě další (řádný) běh programu může odvíjet jedině od dat. V dynamickém od dat a/nebo jejich typu, nebo dokonce nezávisle na jejich typu. To dává větší spektrum možností, jak na ně program v daném místě může (řádně) reagovat. Ve statickém případě se musím omezit (často zbytečně defenzivně) jen na určitý typ dat, přičemž diskrepance mezi povinně deklarovaným očekávaným a reálně přijatým typem dat vede k chybovému stavu. Jsou to opačné imperativy - za všech okolností znát typ dat, s nimiž pracuji, vs. nestarat se o typ dat, dokud to nezbytně nepotřebuji k práci s nimi.

Jinými slovy, zatímco v klasickém přístupu chci pole integerů a případ, kdy bych chtěl pole nějakých obecných prvků, je více či méně krkolomný, u objektového přístupu chci primárně pole nějakých obecných prvků a když budu chtít, aby tam byly jen integery, budu si to muset nějak (více či méně krkolomně) pohlídat.
Nevidím důvod, proč by ty obecné prvky neměli mít patřičný typ. Mám komponentu, do které chci vkládat různé widgety. Tak bude dozajisté užitečné, když mi to tam pustí jen widgety (input, textarea, datepicker, timepicker, calendar, grid, form, ...), a integer nikoliv.
A co se zeptat opačně - proč by nutně musely mít nějaký dopředu známý patřičný typ? Když jdu nakupovat rohlíky, tak k tomu také nepotřebuji speciální tašku na rohlíky. O to, že v ní budou jen rohlíky, se postarám tak, že do ní prostě nic jiného nedám. Ale konat nákup za situace, že mám k dispozici jen tašky na rohlíky, přepravky na lahve, tašky na šunkové salámy, tašky na párky, tašky na chleby apod. by mohl být docela nesnadný úkol. Přitom v tom obchodě je jistě vhodné, aby zboží bylo roztříděno dle druhů, stejně tak ten, kdo z něj bude vařit, bude potřebovat odlišit máslo od chleba. Ale pro účely přenosu z obchodu domů to bude jedno, nebo spíš bude třeba odlišit, co je křehké a co ne. Křehká jsou vejce, ale taky třeba sklenice nebo žárovky či pivo ve skle. Nikoli však pivo v PETce. Pro účely uskladnění se bude rozlišovat podle toho, co půjde do ledničky (pivo bez ohledu na to, je-li ve skle či v PETce), co do mrazáku, co do špajzu. A to je právě ta mnohotvárnost - možnost klasifikovat tytéž objekty za různých situacích - pro různé potřeby různě. Ale k tomu je nezbytné, aby se s nimi technicky dalo zacházet úplně stejně - abych je pokud možno mohl všechny uchopit do ruky a tím s nimi manipulovat a pouhým pohledem, přičichnutím apod., prostě dle vlastnosti, jež mě zajímá, je klasifikovat (včetně situace "tohle mi dali místo sušenek Vanda, ty se už nevyrábějí, ale prý je to něco podobného" a "tohle vůbec netuším, co je, dali mi to pro Frantu, tak mu to prosím předej").

Jiná analogie - dříve PC mělo DIN konektor na klávesnici, DB9 na myš, DB25 na tiskárnu, ale taky byly PS/2 konektory na myš a klávesnici, externí disky měly SCSI, které obvykle představovalo taky další kartu do základní desky... Dnes to řeší jednotné USB a dynamicky se rozhodne, jakým způsobem se připojené zařízení bude obsluhovat.

Takže většina toho, čemu říkáme citáty, zvláště ty latinské, vlastně podle tebe vůbec citáty nejsou. Prosím, držme se obecně přijímaného významu slov a nevymýšlej si pro ně své vlastní definice. Ale nešť - tak jsem přeparafrázoval Kayovy názory
Souhlas, tak si nevymýšlej nesmysly. Definice: “Citát je doslovné znění z díla spisovatele, anebo doslovně zopakovaný výrok. [...] Při citování se uvádí jak autor, tak i dílo v kterém se výrok objevil.” Tohle jsi měl mít na ZŠ (předpokládám, žes ji úspěšně ukončil), asi to fakt jde s naším školstvím od 5 k 0.
Název: Re:Co si myslíte o OOP?
Přispěvatel: Kit 31. 12. 2018, 02:50:59
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 co popisuješ není dobrá definice. Vejdou se do toho snad všechny funkcionální jazyky. A možná i mnoho dalších neOOP.

Pokud jsi to nepochopil, tak jsem tuto definici označil za naprosto chybnou.

OOP je hlavně o umístění metod do objektu - tedy tam, kde je stav.
Název: Re:Co si myslíte o OOP?
Přispěvatel: BoneFlute 31. 12. 2018, 02:57:12
1. protože aby si dostal a.b.c a ne třeba a.b.x
2. to je tautologie. Já znám jen dvě možnosti: statickej typ= vím, že je tam a.b.c, dynamický typ: nevím nic. Tudíž, aby si to mohl zpracovat musíš tu informaci dodat dodatečně ručně. V čem ti dynamický typ pomohl?

Připomenu, já samozřejmě můžu ve statickém jazyce veškeré informace ignorovat, a pracovat jen s tuplem. (Sám si to zmiňoval "Node (string -> string|int|list|Node)"). Ale to pak znamená, jestli to chápu dobře, že jen a pouze chcetš si tu kontrolu dělat sám. To je veškerá výhoda dynamického typování? Možnost dělat si všechno ručně?

--
edit: jak si to po sobě čtu, možná by byl lepší výraz "záruka" na místo "vím". Protože já samozřejmě o té hodnotě můžu evidovat co je to za typ. Ale stroj s tím víc nepracuje.

1. kdyz tam chybi a.b.c, tak mi to muze vratit treba null a vubec se nebudu zlobit
2. popravde tvoji vetu nechapu. Nepotrebuju zadnou informaci dodavat. To, co se skryva pod a.b.c ma svuj dynamicky typ a to mi staci, abych a tim pracoval. Pokud a.b.c neexistuje, vrati mi to null, keyerror nebo jinou takovou hodnotu.

Nechapu kde jsi vytah, ze jsem tvrdil neco o 'veskerych vyhodach dynamickych jazyku'. Tvrdil jsem pouze, ze staticky jazyky v tomhle selhavaji a kazdej normalni clovek by pouzil 'tuple' misto definovanu tyou cely struktury. Tj. sahnul by po dynamickym typovani.
1. "třeba"?!
2. Pokud pracuju s nějakou strukturou (mluvím o JSON), tak pokud s ní nějak pracuji, tak musím vědět co je zač. Tedy, potřebuji informaci. Že mám řadu klíčů a.b.c je informace. Protože třeba taky mohu dostat x.y.z. A to přeci není to samé. Otázka je, kdy tu informaci dodám. Buď předem, nebo dodatečně. Což má své důsledky.

Mé stanovisko (můžeš mě opravit) je, že dynamické jazyky se používají v situaci kdy:
1. za běhu měnitelný systém (znám jen Erlang)
2. prototypování
3. neumím, nebo jazyk neumí typy

Příklad, který si uvedl, bych opravdu raději dělal v staticky typovaném jazyce. Právě proto, že by mi IMHO spoustu práce usnadnil.
Název: Re:Co si myslíte o OOP?
Přispěvatel: Kit 31. 12. 2018, 03:01:02
Já znám jen dvě možnosti: statickej typ= vím, že je tam a.b.c, dynamický typ: nevím nic. Tudíž, aby si to mohl zpracovat musíš tu informaci dodat dodatečně ručně. V čem ti dynamický typ pomohl?

Co udělá statický typ, když mu místo a.b.c přijde a.b.x? V čem mi pomůže, když se takový program sesype, místo aby tu chybu zpracoval?
Název: Re:Co si myslíte o OOP?
Přispěvatel: Kit 31. 12. 2018, 03:04:13
Co bys považoval za dobrou alternativu k dynamizovanému statickému webu?
Zahodit koncept webového prohlížeče a nahradit ho pouhou VM, zahodit koncept webových stránek a nahradit je kompletně jednotným standardizovaným bytekódem appletů, které ať si každý píše, v čem mu to vyhovuje/co je pro daný účel nejvýhodnější, doplnit o podepsané knihovny (dostupné transparentně z dotazovaného serveru či odjinud), vše spravované na straně klienta systémem cache. Webová stránka, jež je ze své podstaty pouhým označkovaným textem, by tak byla nahrazena plnohodnotným programem.

Když by to bylo tak skvělé, tak proč se to nedělá?
Název: Re:Co si myslíte o OOP?
Přispěvatel: Kadet 31. 12. 2018, 03:10:46
1. protože aby si dostal a.b.c a ne třeba a.b.x
2. to je tautologie. Já znám jen dvě možnosti: statickej typ= vím, že je tam a.b.c, dynamický typ: nevím nic. Tudíž, aby si to mohl zpracovat musíš tu informaci dodat dodatečně ručně. V čem ti dynamický typ pomohl?

Připomenu, já samozřejmě můžu ve statickém jazyce veškeré informace ignorovat, a pracovat jen s tuplem. (Sám si to zmiňoval "Node (string -> string|int|list|Node)"). Ale to pak znamená, jestli to chápu dobře, že jen a pouze chcetš si tu kontrolu dělat sám. To je veškerá výhoda dynamického typování? Možnost dělat si všechno ručně?

--
edit: jak si to po sobě čtu, možná by byl lepší výraz "záruka" na místo "vím". Protože já samozřejmě o té hodnotě můžu evidovat co je to za typ. Ale stroj s tím víc nepracuje.

1. kdyz tam chybi a.b.c, tak mi to muze vratit treba null a vubec se nebudu zlobit
2. popravde tvoji vetu nechapu. Nepotrebuju zadnou informaci dodavat. To, co se skryva pod a.b.c ma svuj dynamicky typ a to mi staci, abych a tim pracoval. Pokud a.b.c neexistuje, vrati mi to null, keyerror nebo jinou takovou hodnotu.

Nechapu kde jsi vytah, ze jsem tvrdil neco o 'veskerych vyhodach dynamickych jazyku'. Tvrdil jsem pouze, ze staticky jazyky v tomhle selhavaji a kazdej normalni clovek by pouzil 'tuple' misto definovanu tyou cely struktury. Tj. sahnul by po dynamickym typovani.
1. "třeba"?!
2. Pokud pracuju s nějakou strukturou (mluvím o JSON), tak pokud s ní nějak pracuji, tak musím vědět co je zač. Tedy, potřebuji informaci. Že mám řadu klíčů a.b.c je informace. Protože třeba taky mohu dostat x.y.z. A to přeci není to samé. Otázka je, kdy tu informaci dodám. Buď předem, nebo dodatečně. Což má své důsledky.

Mé stanovisko (můžeš mě opravit) je, že dynamické jazyky se používají v situaci kdy:
1. za běhu měnitelný systém (znám jen Erlang)
2. prototypování
3. neumím, nebo jazyk neumí typy

Příklad, který si uvedl, bych opravdu raději dělal v staticky typovaném jazyce. Právě proto, že by mi IMHO spoustu práce usnadnil.

Nic ve zlym, ale je videt, ze vy lidi ze statickyho typovani jste matematici a zajima vas spis nejaka axiomaticka pravda vesmiru nez dodat vysledek zakaznikovi.

1. ano, treba null nebo KeyError. cokoliv s cim bude tazatel spokojen
2. Muzes si o ty strukture precist treba encyklopedii a vykouzlit nad tim nejakej katamorfismus. Ja mezitim zavolam query("a.b.c", json_objekt, else=null) a jdu domu s penezma od zakaznika.

Staticky typovani je ti uplne k nicemu jakmile ti prijdou data po prekladu programu. Tj. prave nejakej json objekt co ti posle API v responsu, nebo user input. Stejne na to pouzijes dynamicky typovani. Muzes si ho znovuvynalezt v haskellu pomoci pouziti tvyho 'tuplu' ale porad je to dynamicky typovani. Union objekty maji za behu programu nejakej 'tag' kterej urcuje, ktera varianta z unionu je prave pouzita. = dynamicky typovani. Treba je tu nejaky velky nedorozumeni ohledne semantiky, co znamena typ.
Název: Re:Co si myslíte o OOP?
Přispěvatel: BoneFlute 31. 12. 2018, 03:13:50
V OOP je dynamické typování opravdu výhodnější - kvůli polymorfismu a velmi pozdní vazbě.
Nenašel jsem situaci, kdy by pozdní vazba bránila typům. Můžeš uvést příklad?
Už to tu zmiňoval Kit. Spíš jde o ty přívlastky statický/dynamický. Rozdíl bych viděl asi v tom, že ve statickém případě se v daném místě další (řádný) běh programu může odvíjet jedině od dat. V dynamickém od dat a/nebo jejich typu, nebo dokonce nezávisle na jejich typu. To dává větší spektrum možností, jak na ně program v daném místě může (řádně) reagovat. Ve statickém případě se musím omezit (často zbytečně defenzivně) jen na určitý typ dat, přičemž diskrepance mezi povinně deklarovaným očekávaným a reálně přijatým typem dat vede k chybovému stavu. Jsou to opačné imperativy - za všech okolností znát typ dat, s nimiž pracuji, vs. nestarat se o typ dat, dokud to nezbytně nepotřebuji k práci s nimi.
Obávám se, že takto statické typování nefunguje. Všechny příklady tebou naznačného spektra možností mohu řešit. A statické typování mi bude hodně pomáhat. (A nemusím to dělat ručně.)

Zkusme být konkrétní. Bylo tu uvedeno parsování JSONu. Řešil bych to určitě staticky. Rozhodování zpracování podle typu dat? Staticky. Rozhodnování podle dat - to si nejsem jist, co myslíš. Jak se mohu rozhodovat podle dat? Čeho se mohu chytnout? Můžeš uvést příklad?


Jinými slovy, zatímco v klasickém přístupu chci pole integerů a případ, kdy bych chtěl pole nějakých obecných prvků, je více či méně krkolomný, u objektového přístupu chci primárně pole nějakých obecných prvků a když budu chtít, aby tam byly jen integery, budu si to muset nějak (více či méně krkolomně) pohlídat.
Nevidím důvod, proč by ty obecné prvky neměli mít patřičný typ. Mám komponentu, do které chci vkládat různé widgety. Tak bude dozajisté užitečné, když mi to tam pustí jen widgety (input, textarea, datepicker, timepicker, calendar, grid, form, ...), a integer nikoliv.
A co se zeptat opačně - proč by nutně musely mít nějaký dopředu známý patřičný typ?
To samozřejmě (u statického typování) nemusíš. Ale občas je fajn točit pivo do skleněné flašky, a bylinky sypat do papírové krabice. A zajistit, aby to nešlo naopak. Já tam neuváděl komponentu na inputy, ale komponentu na widgety.

Taška na rohlíky je provokace. Jestli nechceš vést vážou diskusi, tak to řekni rovnou :-)
Název: Re:Co si myslíte o OOP?
Přispěvatel: BoneFlute 31. 12. 2018, 03:19:41
Nic ve zlym, ale je videt, ze vy lidi ze statickyho typovani jste matematici a zajima vas spis nejaka axiomaticka pravda vesmiru nez dodat vysledek zakaznikovi.
Opak je pravdou.


2. Muzes si o ty strukture precist treba encyklopedii a vykouzlit nad tim nejakej katamorfismus. Ja mezitim zavolam query("a.b.c", json_objekt, else=null) a jdu domu s penezma od zakaznika.
Kdepak, nejdeš. Já už jsem hotov, zatímco ty stále ještě honíš KeyError :-)

No nic, mír s tebou.
Název: Re:Co si myslíte o OOP?
Přispěvatel: BoneFlute 31. 12. 2018, 03:26:26
Co udělá statický typ, když mu místo a.b.c přijde a.b.x? V čem mi pomůže, když se takový program sesype, místo aby tu chybu zpracoval?
Kde jsi sebral, že se ten program sesype? Staticky typované jazyky narozdíl od svých dynamických kolegů obvykle nepadaj (ne, že by vůbec, ale násobně méně).

Ale k tvé otázce: statický typ zajistí, že v případě a.b.x pojede program jinou cestou. Zajistí, že ta cesta bude existovat. Zajistí, že dojde ke korektnímu zpracování. A zajistí, že se program nesesype.
Název: Re:Co si myslíte o OOP?
Přispěvatel: Kit 31. 12. 2018, 03:31:27
2. Pokud pracuju s nějakou strukturou (mluvím o JSON), tak pokud s ní nějak pracuji, tak musím vědět co je zač. Tedy, potřebuji informaci. Že mám řadu klíčů a.b.c je informace. Protože třeba taky mohu dostat x.y.z. A to přeci není to samé. Otázka je, kdy tu informaci dodám. Buď předem, nebo dodatečně. Což má své důsledky.

Statické typování znamená, že když chceš zpracovat JSON, tak bezpečně víš, že na první položce pole je číslo, na druhé je string a na třetí je datum: [42, "Adam", "1995-05-25"]. Běda, pokud zdroj dat přehodí pořadí - to pak vyběhne fatal error.

Při dynamickém typování bude v JSONu místo pole mapa: {id:42, name:"Adam", birthdate:"1995-05-25"}. Na rozdíl od statického přístupu jsou zde uvedeny skutečné typy, tedy id, name a birthdate. Nemusí nás trápit, pokud ten JSON má položky v jiném pořadí - podstatné je, že je zachována relace typ:hodnota.
Název: Re:Co si myslíte o OOP?
Přispěvatel: BoneFlute 31. 12. 2018, 03:45:09
2. Pokud pracuju s nějakou strukturou (mluvím o JSON), tak pokud s ní nějak pracuji, tak musím vědět co je zač. Tedy, potřebuji informaci. Že mám řadu klíčů a.b.c je informace. Protože třeba taky mohu dostat x.y.z. A to přeci není to samé. Otázka je, kdy tu informaci dodám. Buď předem, nebo dodatečně. Což má své důsledky.

Statické typování znamená, že když chceš zpracovat JSON, tak bezpečně víš, že na první položce pole je číslo, na druhé je string a na třetí je datum: [42, "Adam", "1995-05-25"]. Běda, pokud zdroj dat přehodí pořadí - to pak vyběhne fatal error.
Ne, to to skutečně neznamená.

Při dynamickém typování bude v JSONu místo pole mapa: {id:42, name:"Adam", birthdate:"1995-05-25"}. Na rozdíl od statického přístupu jsou zde uvedeny skutečné typy, tedy id, name a birthdate. Nemusí nás trápit, pokud ten JSON má položky v jiném pořadí - podstatné je, že je zachována relace typ:hodnota.

`id` z `{id:42, name:"Adam", birthdate:"1995-05-25"}` rozhodně není typ. Při dynamickém typování nic z toho co jsi popsal nezískáváme navíc. Je mi to líto, opravdu píšeš nesmysly.
Název: Re:Co si myslíte o OOP?
Přispěvatel: Kadet 31. 12. 2018, 03:53:11
Nic ve zlym, ale je videt, ze vy lidi ze statickyho typovani jste matematici a zajima vas spis nejaka axiomaticka pravda vesmiru nez dodat vysledek zakaznikovi.
Opak je pravdou.


2. Muzes si o ty strukture precist treba encyklopedii a vykouzlit nad tim nejakej katamorfismus. Ja mezitim zavolam query("a.b.c", json_objekt, else=null) a jdu domu s penezma od zakaznika.
Kdepak, nejdeš. Já už jsem hotov, zatímco ty stále ještě honíš KeyError :-)

No nic, mír s tebou.

Omyl. Ja mam hotovo a resim co s null nebo keyerror. V tehle chvili by mi teoreticky statickej typ pomoh, to je pravda.

Jenomze ty jsi jeste nepreskocil a uz rikas HOP. Zatim jsi neukazal jak by ses s tim vyporadal.

Kit dal dobry priklady v jsonu. Dalsi dobrej priklad kde selhava staticky typovani je tohle. Mam dva objekty. Chci ziskat 'name'.

V dynamickym jazyce zavolam 'query("name")' a jdu domu, splneno. Jak bude vypadat ve statickym jazyce typ kterej mi zvladne oba priklady? Nebo musim vytvorit powerset vsech kombinaci pritomnych/chybejicich poli?
Opakuju, pouziti datovyho typu 'JsonNode' je reimplementace dynamickyho typovani.

{id:42, name:"Adam", birthdate:"1995-05-25"}
{id:42, name:"Adam"}
Název: Re:Co si myslíte o OOP?
Přispěvatel: ivoszz 31. 12. 2018, 04:26:45
2. Pokud pracuju s nějakou strukturou (mluvím o JSON), tak pokud s ní nějak pracuji, tak musím vědět co je zač. Tedy, potřebuji informaci. Že mám řadu klíčů a.b.c je informace. Protože třeba taky mohu dostat x.y.z. A to přeci není to samé. Otázka je, kdy tu informaci dodám. Buď předem, nebo dodatečně. Což má své důsledky.

Statické typování znamená, že když chceš zpracovat JSON, tak bezpečně víš, že na první položce pole je číslo, na druhé je string a na třetí je datum: [42, "Adam", "1995-05-25"]. Běda, pokud zdroj dat přehodí pořadí - to pak vyběhne fatal error.

Při dynamickém typování bude v JSONu místo pole mapa: {id:42, name:"Adam", birthdate:"1995-05-25"}. Na rozdíl od statického přístupu jsou zde uvedeny skutečné typy, tedy id, name a birthdate. Nemusí nás trápit, pokud ten JSON má položky v jiném pořadí - podstatné je, že je zachována relace typ:hodnota.
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?

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.

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.

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.
Název: Re:Co si myslíte o OOP?
Přispěvatel: Kit 31. 12. 2018, 04:40:03
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?

Pascal používá record, v C je to struct.
Název: Re:Co si myslíte o OOP?
Přispěvatel: Kit 31. 12. 2018, 04:54:19
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.

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.

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.

Nakonec jsme se dopracovali k tomu, že ve staticky typovaných jazycích používáš dynamické typování, protože bez něj bys tu úlohu neudělal. Zpracování reflexe je také z dynamického typování. Otázkou je, k čemu by mi bylo statické typování v dynamicky typovaném jazyce. A že nejdou dodělat? V PHP jdou...

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.
Název: Re:Co si myslíte o OOP?
Přispěvatel: BoneFlute 31. 12. 2018, 05:11:34
... 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á.
Název: Re:Co si myslíte o OOP?
Přispěvatel: Kadet 31. 12. 2018, 05:40:51
... 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á.

Problem je 'presvedcit kompilator'. Napr. existuji programy, ktere dokaze clovek interpretovat, ale nelze je staticky overit. Soundness vs Completeness.

Prakticky kazdej praktickej clovek, kdo kdy delal v necem staticky typovanym a pak zkusil neco napsat v pythonu, jq nebo one line pipelinu ve shellu, chtel staticky jazyky hodit do kose. Staticky jazyky jsou dobry akorat na definovani jednoduchy funkce, kterou je treba silne zoptimalizovat. Do dynamickych jazyku se pak lehce importuje skrz FFI. Z pohledu dynamickyho jazyka je takova importovana staticka funkce ekvivalentni hardwaru. Funkce je rychlejsi a je nemenici se = nova instrukce = hardware.

Napr. si napisu v C funkci add_vector(xs: ints, ys: ints) ktera mi vrati soucet obou vstuonuch vektoru. V pythonu si to importnu a muzu to brat jako optimalizovanou vektorizovanou CPU instrukci.
Název: Re:Co si myslíte o OOP?
Přispěvatel: BoneFlute 31. 12. 2018, 05:51:05
Mam dva objekty. Chci ziskat 'name'.

V dynamickym jazyce zavolam 'query("name")' a jdu domu, splneno. Jak bude vypadat ve statickym jazyce typ kterej mi zvladne oba priklady? Nebo musim vytvorit powerset vsech kombinaci pritomnych/chybejicich poli?
Opakuju, pouziti datovyho typu 'JsonNode' je reimplementace dynamickyho typovani.

{id:42, name:"Adam", birthdate:"1995-05-25"}
{id:42, name:"Adam"}

Pseudokód, rozepsáno (pro laiky):

Kód: [Vybrat]
s = "{id:42, name:"Adam", birthdate:"1995-05-25"}"
type Person = {id: Int, name: String, birthdate: Maybe Date}
print (Person id, name, birthdate) = id .. name .. (case birtdate
   Just x -> x
   Nothing -> '')
print (Json.parse Person s)

Tak samozřejmě, že by to šlo napsat i pomocí toho query("name"), ale myslím si, že by to nikdo soudnej nedělal. Bylo by to přesně to dynamické, aniž by to přineslo nějaký užitek, a jen jeho nedostatky:

Kód: [Vybrat]
s = "{id:42, name:"Adam"}"
print [id, name, birthdate] = id .. name .. birtdate
print (Json.query ['id', 'name', 'birthdate'] s)
->> KeyError
Název: Re:Co si myslíte o OOP?
Přispěvatel: BoneFlute 31. 12. 2018, 05:57:38
Problem je 'presvedcit kompilator'. Napr. existuji programy, ktere dokaze clovek interpretovat, ale nelze je staticky overit. Soundness vs Completeness.

Prakticky kazdej praktickej clovek, kdo kdy delal v necem staticky typovanym a pak zkusil neco napsat v pythonu, jq nebo one line pipelinu ve shellu, chtel staticky jazyky hodit do kose. Staticky jazyky jsou dobry akorat na definovani jednoduchy funkce, kterou je treba silne zoptimalizovat.

Ano, to jsem psal. Důvody pro dynamicky typovaný jazyk:
1. za běhu měnitelný systém (znám jen Erlang)
2. prototypování
3. neumím, nebo jazyk neumí typy

Samozřejmě sám sebe označit za praktického člověka a pak všechny ty, kteří to mají jinak označit za nepraktické je hodně odvážně, ale budiž ti přáno.

Takže ještě jednou. Pokud by si byl schopen uvést nějakou výhodu dynamicky typovaných jazyků, krom těch mnou zmíněných tří bodů - sem s tím. V opačném případě to tedy můžem uzavřít.
Název: Re:Co si myslíte o OOP?
Přispěvatel: Kadet 31. 12. 2018, 06:06:14
Mam dva objekty. Chci ziskat 'name'.

V dynamickym jazyce zavolam 'query("name")' a jdu domu, splneno. Jak bude vypadat ve statickym jazyce typ kterej mi zvladne oba priklady? Nebo musim vytvorit powerset vsech kombinaci pritomnych/chybejicich poli?
Opakuju, pouziti datovyho typu 'JsonNode' je reimplementace dynamickyho typovani.

{id:42, name:"Adam", birthdate:"1995-05-25"}
{id:42, name:"Adam"}

Pseudokód, rozepsáno (pro laiky):

Kód: [Vybrat]
s = "{id:42, name:"Adam", birthdate:"1995-05-25"}"
type Person = {id: Int, name: String, birthdate: Maybe Date}
print (Person id, name, birthdate) = id .. name .. (case birtdate
   Just x -> x
   Nothing -> '')
print (Json.parse Person s)

Tak samozřejmě, že by to šlo napsat i pomocí toho query("name"), ale myslím si, že by to nikdo soudnej nedělal. Bylo by to přesně to dynamické, aniž by to přineslo nějaký užitek, a jen jeho nedostatky:

Kód: [Vybrat]
s = "{id:42, name:"Adam"}"
print [id, name, birthdate] = id .. name .. birtdate
print (Json.query ['id', 'name', 'birthdate'] s)
->> KeyError

Diky, to byl zacatek. Druhej den mi api posle json s velikosti bot. Treti den se tam objevi pole s vysi jeho platu, atd atd.

{id:42, name:"Adam"}
{id:42, name:"Adam", birthdate:"1995-05-25"}
{id:42, name:"Adam", birthdate:"1995-05-25", shoesize:43}
{id:42, name:"Adam", birthdate:"1995-05-25", salary:200000}

K moji smule musim kazdej den prepisovat typ Person i kdyz me zajima jenom jeho jmeno.

Druha vec. Je rozdil mezi chybejicim polem birthdate a kdyz je birthdate v jsonu null. Takze ten typ by vypadal spis (Maybe (Date|null)).

Dynamicky by to udelal kazdej soudnej clovek co chce domu prinest penize a nakrmit zenu a deti. Tyhle haskell hratky jsou pro lidi produkujici akademicky hracky. Mam tu cest s takovyma pracovat a jejich napln dne je debatovat nad morfismama a kategoriema misto dodavani vysledku.
Název: Re:Co si myslíte o OOP?
Přispěvatel: Kadet 31. 12. 2018, 06:11:24
Problem je 'presvedcit kompilator'. Napr. existuji programy, ktere dokaze clovek interpretovat, ale nelze je staticky overit. Soundness vs Completeness.

Prakticky kazdej praktickej clovek, kdo kdy delal v necem staticky typovanym a pak zkusil neco napsat v pythonu, jq nebo one line pipelinu ve shellu, chtel staticky jazyky hodit do kose. Staticky jazyky jsou dobry akorat na definovani jednoduchy funkce, kterou je treba silne zoptimalizovat.

Ano, to jsem psal. Důvody pro dynamicky typovaný jazyk:
1. za běhu měnitelný systém (znám jen Erlang)
2. prototypování
3. neumím, nebo jazyk neumí typy

Samozřejmě sám sebe označit za praktického člověka a pak všechny ty, kteří to mají jinak označit za nepraktické je hodně odvážně, ale budiž ti přáno.

Takže ještě jednou. Pokud by si byl schopen uvést nějakou výhodu dynamicky typovaných jazyků, krom těch mnou zmíněných tří bodů - sem s tím. V opačném případě to tedy můžem uzavřít.

Uzavrem to klidne. Myslim ze se shodnem na tom, ze schopnost dodat vysledek v staticky typovanym jazyce se v nekterych konkretnich prikladech realneho sveta blizi k nule. Muj verdikt o dynamickych jazycich v kontrastu tedy, muzes si to pridat jako dalsi bod, je ze jsou POUZITELNY. Jinymi slovy jsem schopen dodat vysledek. Se statickym jazykem ostatni lidi mezitim dodavaji akorat hromadu slibu.
Název: Re:Co si myslíte o OOP?
Přispěvatel: BoneFlute 31. 12. 2018, 06:30:13
Mam dva objekty. Chci ziskat 'name'.

V dynamickym jazyce zavolam 'query("name")' a jdu domu, splneno. Jak bude vypadat ve statickym jazyce typ kterej mi zvladne oba priklady? Nebo musim vytvorit powerset vsech kombinaci pritomnych/chybejicich poli?
Opakuju, pouziti datovyho typu 'JsonNode' je reimplementace dynamickyho typovani.

{id:42, name:"Adam", birthdate:"1995-05-25"}
{id:42, name:"Adam"}

Pseudokód, rozepsáno (pro laiky):

Kód: [Vybrat]
s = "{id:42, name:"Adam", birthdate:"1995-05-25"}"
type Person = {id: Int, name: String, birthdate: Maybe Date}
print (Person id, name, birthdate) = id .. name .. (case birtdate
   Just x -> x
   Nothing -> '')
print (Json.parse Person s)

Tak samozřejmě, že by to šlo napsat i pomocí toho query("name"), ale myslím si, že by to nikdo soudnej nedělal. Bylo by to přesně to dynamické, aniž by to přineslo nějaký užitek, a jen jeho nedostatky:

Kód: [Vybrat]
s = "{id:42, name:"Adam"}"
print [id, name, birthdate] = id .. name .. birtdate
print (Json.query ['id', 'name', 'birthdate'] s)
->> KeyError

Diky, to byl zacatek. Druhej den mi api posle json s velikosti bot. Treti den se tam objevi pole s vysi jeho platu, atd atd.

{id:42, name:"Adam"}
{id:42, name:"Adam", birthdate:"1995-05-25"}
{id:42, name:"Adam", birthdate:"1995-05-25", shoesize:43}
{id:42, name:"Adam", birthdate:"1995-05-25", salary:200000}

K moji smule musim kazdej den prepisovat typ Person i kdyz me zajima jenom jeho jmeno.
Nemusíš. Naparsují se hodnoty, které tam jsou, které vyžaduješ. Ostatní je smetí, které se bude ignorovat.


Druha vec. Je rozdil mezi chybejicim polem birthdate a kdyz je birthdate v jsonu null. Takze ten typ by vypadal spis (Maybe (Date|null)).
Nevypadal.


Uzavrem to klidne. Myslim ze se shodnem na tom, ze schopnost dodat vysledek v staticky typovanym jazyce se v nekterych konkretnich prikladech realneho sveta blizi k nule. Muj verdikt o dynamickych jazycich v kontrastu tedy, muzes si to pridat jako dalsi bod, je ze jsou POUZITELNY. Jinymi slovy jsem schopen dodat vysledek. Se statickym jazykem ostatni lidi mezitim dodavaji akorat hromadu slibu.
Neschodnem. Mě by zajímal konkrétní scénář, kdy je dynamický jazyk tak výrazně použitelnější, že to slovo píšeš kapitálkama. (Parsování JSON to evidentně není.) To, že to prohlašuješ mi pochopitelně nestačí.

Možná si budu muset počkat na někoho, kdo rozumí obému.
Název: Re:Co si myslíte o OOP?
Přispěvatel: Kadet 31. 12. 2018, 07:06:39
Mam dva objekty. Chci ziskat 'name'.

V dynamickym jazyce zavolam 'query("name")' a jdu domu, splneno. Jak bude vypadat ve statickym jazyce typ kterej mi zvladne oba priklady? Nebo musim vytvorit powerset vsech kombinaci pritomnych/chybejicich poli?
Opakuju, pouziti datovyho typu 'JsonNode' je reimplementace dynamickyho typovani.

{id:42, name:"Adam", birthdate:"1995-05-25"}
{id:42, name:"Adam"}

Pseudokód, rozepsáno (pro laiky):

Kód: [Vybrat]
s = "{id:42, name:"Adam", birthdate:"1995-05-25"}"
type Person = {id: Int, name: String, birthdate: Maybe Date}
print (Person id, name, birthdate) = id .. name .. (case birtdate
   Just x -> x
   Nothing -> '')
print (Json.parse Person s)

Tak samozřejmě, že by to šlo napsat i pomocí toho query("name"), ale myslím si, že by to nikdo soudnej nedělal. Bylo by to přesně to dynamické, aniž by to přineslo nějaký užitek, a jen jeho nedostatky:

Kód: [Vybrat]
s = "{id:42, name:"Adam"}"
print [id, name, birthdate] = id .. name .. birtdate
print (Json.query ['id', 'name', 'birthdate'] s)
->> KeyError

Diky, to byl zacatek. Druhej den mi api posle json s velikosti bot. Treti den se tam objevi pole s vysi jeho platu, atd atd.

{id:42, name:"Adam"}
{id:42, name:"Adam", birthdate:"1995-05-25"}
{id:42, name:"Adam", birthdate:"1995-05-25", shoesize:43}
{id:42, name:"Adam", birthdate:"1995-05-25", salary:200000}

K moji smule musim kazdej den prepisovat typ Person i kdyz me zajima jenom jeho jmeno.
Nemusíš. Naparsují se hodnoty, které tam jsou, které vyžaduješ. Ostatní je smetí, které se bude ignorovat.


Druha vec. Je rozdil mezi chybejicim polem birthdate a kdyz je birthdate v jsonu null. Takze ten typ by vypadal spis (Maybe (Date|null)).
Nevypadal.


Uzavrem to klidne. Myslim ze se shodnem na tom, ze schopnost dodat vysledek v staticky typovanym jazyce se v nekterych konkretnich prikladech realneho sveta blizi k nule. Muj verdikt o dynamickych jazycich v kontrastu tedy, muzes si to pridat jako dalsi bod, je ze jsou POUZITELNY. Jinymi slovy jsem schopen dodat vysledek. Se statickym jazykem ostatni lidi mezitim dodavaji akorat hromadu slibu.
Neschodnem. Mě by zajímal konkrétní scénář, kdy je dynamický jazyk tak výrazně použitelnější, že to slovo píšeš kapitálkama. (Parsování JSON to evidentně není.) To, že to prohlašuješ mi pochopitelně nestačí.

Možná si budu muset počkat na někoho, kdo rozumí obému.

Aha, takze nechces typovat celej ten json objekt, ale pouze tu podmnozinu se kterou chces pracovat.

Prakticky si svym Person typem nadefinoval json schema, podle kteryho prichozi json objekt zvalidujes. Dela to za tebe zrejme json.parse funkce a statickej typ je jaon schema.

Takze prijmes objekt, zvalidujes ho podle schematu, vyberes si jen ty hodnoty, ktery tvuj typ definuje a pretransformujes json reprezentaci do ekvivalentni interni stromovy reprezentace v haskellu treba.

Kdyz mas dobrej ekosystem, ve kterym mas tak dobrej parser a serializer, ze dokaze pouzit reflexi nad typem, tak ti to bude fungovat.
Pak musis mit v ekosystemu spoustu sikovnych funkci, ktery ti umozni s takovym typem obecne pracovat. Prece nebudes pro kazdy pridany pole pridavat funkcionalitu do funkci ktery nad tim typem pracujou. Tzn. asi nejaka silna reflexe.

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.
Chci mit nejakou garanci o tom objektu?  Dam si praci a nadefinuju schema podle kteryho objekt overim, podobne jako ve tvym statickym prikladu.
Název: Re:Co si myslíte o OOP?
Přispěvatel: n 31. 12. 2018, 07:59:47
Mohl by jsi uvezt priklad z oblasti sw inzenyrstvi, kde nejaky produkt mel hlavne dobry marketing, ale jinak nestal za moc?

Z ktere oblasti chces priklad? MS-DOS, Windows 95, MS Word, MS Excel, PHP, IE, VB, ASP, Javascript, Eclipse, Hadoop, MongoDB..

Ke kazde z tech veci v te dobe existovaly podstatne lepsi alternativy, jen byly (z toho ci onoho duvodu = marketing) mene zname.

Mohl bys prosimte napsat alternativy k win95, word, excel, hadoop?
Název: Re:Co si myslíte o OOP?
Přispěvatel: Octopuss 31. 12. 2018, 09:37:23
Jsou to teroristi!?!
Název: Re:Co si myslíte o OOP?
Přispěvatel: Mirek Prýmek 31. 12. 2018, 10:35:33
1. Erlang dokáže za chodu opravovat/upravovat kód. A autoři prohlásili, že tam typy nedali, protože se jim nepovedlo vymyslet jak na to.
Měl bys k tomuhle nějakej odkaz? Přijde mi divný, že by to zaznělo přesně takhle (že by tím důvodem byl právě hot code loading).

---

Jinak k té debatě statický vs. dynamický: ani trochu se nechci účastnit flamewaru, přijde mi to dětinský. Oba přístupy mají svoje pro a proti a každej si může vybrat, co mu víc vyhovuje. IMHO jsi ale udělal v úvahách několik faktických/argumentačních chyb.

1. Několikrát opakuješ obrat "nemá typy". To je minimálně zavádějící. Dynamické jazyky mají typy. Od staticky typovaných se liší jenom tím, jestli informaci o typu znáš (pozitivně, s jistotou) při překladu, nebo až v době běhu. V principu provádíš tu stejnou kontrolu, jenom jindy. Výhoda statických jazyků je v tom, že kontrolu provedeš (ve většině případů - viz 2) jenom jednou, zatímco u dynamického ji musíš provádět pořád dokola, za běhu.

2. Z bodu 1 přímo vyplývá, že statický jazyk má problém v situacích, kdy typ v době překladu z principu nemůžeš znát - to je ten příklad s načítáním JSONu, ale můžeš jich vymyslet bambilion jiných. Můžeš to řešit dvěma způsoby (možná i jinak, ale teď mě jiná možnost nenapadá):

A) buď máš k dispozici algebraické typy a (v době překladu neznámý) typ prohlásíš za nějakou nadmnožinu různých typů, v extrémním případě všech myslitelných a dál pracuješ s tímhle nadtypem

B) nebo typ zjistíš za běhu (dynamické typování!) a program podle typu větvíš, takže i v době překladu víš, že do určité větve ti jde už jenom určitý typ

3. Někde jsi řekl, že do dynamických jazyků nejdou typy (při překladu) dodat. To není pravda. Stejně jako se u statického jazyka občas musíš uchýlit k dynamickému typování, můžeš u dynamického jazyka otypovat ty části programu, kde v době překladu víš, co tam bude za typ. A můžeš to i kontrolovat, úplně stejně jako u statického (viz např. u Erlangu Dializer). Dokonce by asi i šlo (ale nevím o žádném dynamickém jazyce, který by to uměl) třeba některé části programu otypovat staticky a u nich vyhodit kontroly typů za běhu.

Prostě, ty dva přístupy se vzájemně nevylučují. Je třeba si jenom uvědomit, že u některých částí programu víš předem, s jakými daty může pracovat, u jiných částí to nevíš (ani u jednoho typu jazyka). Ty části můžou být různě velké.

Na druhou stranu s tebou docela souhlasím v tom, že udržovat tu část, kde typy znáš, co největší (a tím se vyvarovat runtime chybám) je docela dobrý přístup. Ale i kdyby ses na hlavu postavil, nemůžeš mít takových 100% programu. Někde prostě z principu věci dostaneš data, jejichž typ v době překladu neznáš.
Název: Re:Co si myslíte o OOP?
Přispěvatel: Mirek Prýmek 31. 12. 2018, 10:41:30
Upřesnění:

máš k dispozici algebraické typy
Tohle jsem moc zúžil. Nemusí to být jenom vyloženě algebraické typy, ale jakýkoliv mechanismus "nadtypů". Třeba i to klasické OOP "načtu přes síť objekt, neznám jeho kompletní typ, ale vím, že umí zpracovat zprávu saveToPdf" - to je taky "nadtyp".
Název: Re:Co si myslíte o OOP?
Přispěvatel: Mirek Prýmek 31. 12. 2018, 11:01:07
P.S. Taky není od věci si uvědomit, že "znát typ" není nic jiného, než "vědět něco o datech, která se v tomhle místě programu můžou vyskytnout". Přičemž u drtivé většiny jazyků (všech?) to "něco" pořád ještě nestačí k tomu, abys mohl mít jistotu, že program bude ve všech případech běžet korektně.

Např. pokud víš, že ve výrazu x / y je y s jistotou "integer", je ti to víceméně na nic, protože situace, kdy je y nula má stejné důsledky jako kdyby to byl string. Dělení nulou je stejně nedefinované jako dělení stringem. Takže kdykoli se ti v programu objeví dělení (nebo jakákoli jiná parciální funkce), stane se ti ze statického jazyka efektivně dynamický - protože prostě v době překladu nejsi schopný ověřit korektnost.
Název: Re:Co si myslíte o OOP?
Přispěvatel: Mirek Prýmek 31. 12. 2018, 11:16:21
A co se zeptat opačně - proč by nutně musely mít nějaký dopředu známý patřičný typ? Když jdu nakupovat rohlíky, tak k tomu také nepotřebuji speciální tašku na rohlíky.
Tady podsouváš něco, co není pravda (strawman). Že máš staticky typovaný jazyk ještě neimplikuje, že musíš nutně pracovat jenom s nějakými základními typy a všechny je zvlášť ošetřovat. Stačí ti mít nějaký mechanismus nadtypů (viz výš).

Že některé statické jazyky nadtypy nemají, to považuju za zločin (jo, mluvím o tobě, Go!).

Čili v tom tvém příkladu: máš nadtyp "cokoli do čeho se dá vložit cokoli, co je menší než Boeing" ;)
Název: Re:Co si myslíte o OOP?
Přispěvatel: listoper 31. 12. 2018, 11:30:55
Statické typování se hodí pro strukturované programování, ale já raději používám OOP, ve kterém je lepší typovat dynamicky.
1. Erlang dokáže za chodu opravovat/upravovat kód. A autoři prohlásili, že tam typy nedali, protože se jim nepovedlo vymyslet jak na to.
Mel bys na to nejaky odkaz? Nefunguje to u kazdeho jazyka s REPL?

2. Někdy se hodí, zejména na prototypování, když jsou typy volitelné, a následně to při refactoringu upřesňovat. Protože ze začátku člověk třeba nemá jasno, jak to má vypadat, a tak samozřejmě dost dobře nemůže ty typy určit.

Tohle mi prijde zvlastni. refactoring chapu jako "cisteni" kodu v pripade, ze uz funguje spravne tzn. beze zmeny funkcionality... Abych mohl delat refactoring "bezpecne" potrebuju mit uz v ruce nejaky kontrolni mechanizmus (testy nebo typovou kontrolu), abych mohl po vycisteni prokazat, zachovani funcionality.

Takze, kdyz budu delat nejaky proof of concept tak muzu bez testu a bez typu, ale rozhodne to pak nebudu refactorovat do nejake produkcni verze, protoze bych se osypal.

Název: Re:Co si myslíte o OOP?
Přispěvatel: Mirek Prýmek 31. 12. 2018, 11:35:23
Mel bys na to nejaky odkaz? Nefunguje to u kazdeho jazyka s REPL?
S REPL to nemá nic společnýho. V Erlangu můžeš za běhu vyměnit jeden modul za jiný. Můžeš si to představit tak, jako bys v Javě vyměnil implementaci třídy String za jinou a všechen kód, včetně knihoven atd. začal pracovat s novou třídou (ta stará prostě vůbec neexistuje, vyhodíš ji). Nejsem si vůbec jistej, jestli tohle umí všechny jazyky, spíš bych řekl, že ne.
Název: Re:Co si myslíte o OOP?
Přispěvatel: Inkvizitor 31. 12. 2018, 11:47:30
A co se zeptat opačně - proč by nutně musely mít nějaký dopředu známý patřičný typ? Když jdu nakupovat rohlíky, tak k tomu také nepotřebuji speciální tašku na rohlíky.
Tady podsouváš něco, co není pravda (strawman). Že máš staticky typovaný jazyk ještě neimplikuje, že musíš nutně pracovat jenom s nějakými základními typy a všechny je zvlášť ošetřovat. Stačí ti mít nějaký mechanismus nadtypů (viz výš).

Že některé statické jazyky nadtypy nemají, to považuju za zločin (jo, mluvím o tobě, Go!).

Čili v tom tvém příkladu: máš nadtyp "cokoli do čeho se dá vložit cokoli, co je menší než Boeing" ;)

Co máš na mysli těmi nadtypy, prosímtě?
Název: Re:Co si myslíte o OOP?
Přispěvatel: Mirek Prýmek 31. 12. 2018, 11:56:49
Co máš na mysli těmi nadtypy, prosímtě?
Typ je množina hodnot. Nadtyp je nadmnožina.
Název: Re:Co si myslíte o OOP?
Přispěvatel: Inkvizitor 31. 12. 2018, 12:02:20
Co máš na mysli těmi nadtypy, prosímtě?
Typ je množina hodnot. Nadtyp je nadmnožina.

Tomu rozumím, ale asi tušíš, že na to jsem se neptal. Jde mi o tu implementaci; chápu, že třeba v Javě máš Object, narážíš konkrétně na Go, ale pokud tomu dobře rozumím, tak nízkoúrovňové jazyky obecně nic takového nemají.
Název: Re:Co si myslíte o OOP?
Přispěvatel: listoper 31. 12. 2018, 12:08:07
Mel bys na to nejaky odkaz? Nefunguje to u kazdeho jazyka s REPL?
S REPL to nemá nic společnýho. V Erlangu můžeš za běhu vyměnit jeden modul za jiný. Můžeš si to představit tak, jako bys v Javě vyměnil implementaci třídy String za jinou a všechen kód, včetně knihoven atd. začal pracovat s novou třídou (ta stará prostě vůbec neexistuje, vyhodíš ji). Nejsem si vůbec jistej, jestli tohle umí všechny jazyky, spíš bych řekl, že ne.

To E v REPL znamena "evaluate".  Nevim jak jinde, ale v mem oblibenem clojure proste predhodim REPLu kod a on se evaluuje. To znamena, ze pokud v tom kodu prepisu funkci, nebo cely namespace tak stara verze kodu efektivne zmizi a je nahrazena tou predhozenou.
A uz sem to videl v akci i na produkci... (byl to trochu opruz kvuli sitarum a bezpecakum, ale nakonec to probehlo)
Název: Re:Co si myslíte o OOP?
Přispěvatel: Mirek Prýmek 31. 12. 2018, 12:10:22
Tomu rozumím, ale asi tušíš, že na to jsem se neptal.
Netušil jsem, jinak bych ti tak neodpovídal :)

Jde mi o tu implementaci; chápu, že třeba v Javě máš Object, narážíš konkrétně na Go, ale pokud tomu dobře rozumím, tak nízkoúrovňové jazyky obecně nic takového nemají.
Nevím, co jsou "nízkoúrovňové jazyky". Bavíme se obecně o různých jazycích, takže těžko mluvit o konkrétní implementaci. Prakticky těch mechanismů může být víc, ale všechny mají stejný "filosofický" princip:

1. typ je "sjednocením" dvou typů -> algebraické typy (tj. prakticky: chci mít možnost napsat funkci, která vrací string nebo int)

2. nadtyp je definovaný tím, že má jenom některé vlastnosti podtypu -> dědičnost, interfejsy

V jazyce OOP klíčová slova "předek" a "Liskovové substituce".
Název: Re:Co si myslíte o OOP?
Přispěvatel: Mirek Prýmek 31. 12. 2018, 12:12:04
To E v REPL znamena "evaluate".  Nevim jak jinde, ale v mem oblibenem clojure proste predhodim REPLu kod a on se evaluuje. To znamena, ze pokud v tom kodu prepisu funkci, nebo cely namespace tak stara verze kodu efektivne zmizi a je nahrazena tou predhozenou.
A uz sem to videl v akci i na produkci... (byl to trochu opruz kvuli sitarum a bezpecakum, ale nakonec to probehlo)
No jistě, ale to je něco jinýho.

Hot reloading v Erlangu je o tom, že ti běží na serveru nějaká aplikace a ty v ní za běhu změníš část kódu. Klíčový je to, že měníš existující aplikaci, zatímco v REPLu vlastně vytváříš novou.
Název: Re:Co si myslíte o OOP?
Přispěvatel: Inkvizitor 31. 12. 2018, 12:20:25
1. typ je "sjednocením" dvou typů -> algebraické typy (tj. prakticky: chci mít možnost napsat funkci, která vrací string nebo int)

Tedy "sum type"? Tak tam má Go asi fakt handicap.

2. nadtyp je definovaný tím, že má jenom některé vlastnosti podtypu -> dědičnost, interfejsy

No ale interface naopak podporuje...

Ne že bych chtěl zrovna já obhajovat Go, jenom mě zajímalo, proč jsi po něm tak tvrdě vyjel.
Název: Re:Co si myslíte o OOP?
Přispěvatel: Mirek Prýmek 31. 12. 2018, 12:24:15
Tedy "sum type"? Tak tam má Go asi fakt handicap.
Jo. Nebo se používá i termín "composite type".

No ale interface naopak podporuje...
Ne že bych chtěl zrovna já obhajovat Go, jenom mě zajímalo, proč jsi po něm tak tvrdě vyjel.
Interfejsy sice podporuje, ale celkově je ten type systém dost omezený. Prakticky se to projevuje tak, že ve spoustě kódu uvidíš "prázdný interfejs" - tj. ekvivalent Object. Go je na tom prostě teď stejně jako Java před deseti lety. A i ty argumenty jsou stejné... (nejen) v tomhletom je Go trochu smutný příběh.
Název: Re:Co si myslíte o OOP?
Přispěvatel: JS 31. 12. 2018, 12:31:35
Mohl by jsi uvezt priklad z oblasti sw inzenyrstvi, kde nejaky produkt mel hlavne dobry marketing, ale jinak nestal za moc?

Z ktere oblasti chces priklad? MS-DOS, Windows 95, MS Word, MS Excel, PHP, IE, VB, ASP, Javascript, Eclipse, Hadoop, MongoDB..

Ke kazde z tech veci v te dobe existovaly podstatne lepsi alternativy, jen byly (z toho ci onoho duvodu = marketing) mene zname.

Me by zajimala ta lepsi alternativa sve doby ke vsemu z toho, co jsi uvedl.

Unix, OS/2, WordPerfect, Quattro Pro, Perl, Netscape, Delphi, jakykoli jiny sablonovaci system, Guile, Visual Studio, horizontalni skalovani aplikace na miru (Google pozdeji od MapReduce uplne ustoupil), temer jakakoli SQL databaze.

Nekdy tech alternativ bylo i vic, pisu ty hlavni. Ale nebyly tolik v mode.
Název: Re:Co si myslíte o OOP?
Přispěvatel: BaldSlattery 31. 12. 2018, 12:34:57
Upřesnění:

máš k dispozici algebraické typy
Tohle jsem moc zúžil. Nemusí to být jenom vyloženě algebraické typy, ale jakýkoliv mechanismus "nadtypů". Třeba i to klasické OOP "načtu přes síť objekt, neznám jeho kompletní typ, ale vím, že umí zpracovat zprávu saveToPdf" - to je taky "nadtyp".
Upřesnění upřesnění: to je pak spíše protokol/rozhraní, případně trait.
Název: Re:Co si myslíte o OOP?
Přispěvatel: Mirek Prýmek 31. 12. 2018, 12:37:01
Upřesnění upřesnění: to je pak spíše protokol/rozhraní, případně trait.
No je to oboje. Chceš dosáhnout stejného cíle (vytvoření "obecnějšího typu") a jdeš na to buď přes algebraické typy nebo přes dědičnost nebo přes interfejsy.
Název: Re:Co si myslíte o OOP?
Přispěvatel: Kiwi 31. 12. 2018, 12:38:21
Když by to bylo tak skvělé, tak proč se to nedělá?
Svět by byl dnes jistě úplně jiný, pokud by se v něm prosazovaly zásadně jen věci, které jsou skvělé.

Obávám se, že takto statické typování nefunguje. Všechny příklady tebou naznačného spektra možností mohu řešit. A statické typování mi bude hodně pomáhat. (A nemusím to dělat ručně.)

Zkusme být konkrétní. Bylo tu uvedeno parsování JSONu. Řešil bych to určitě staticky. Rozhodování zpracování podle typu dat? Staticky. Rozhodnování podle dat - to si nejsem jist, co myslíš. Jak se mohu rozhodovat podle dat? Čeho se mohu chytnout? Můžeš uvést příklad?
Netvrdím, že to nejde. Kdyby to nešlo, tak by většina praktických problémů byla neřešitelná staticky typovanými jazyky. Jenže to, co vnímáš jako cosi, co ti bude hodně pomáhat, já často vnímám jako klacky motající se pod nohama.
Rozhodování podle dat, tím myslím IF size > 5 cm THEN ...
Rozhodování podle typu, tím myslím IF (x hasMagnitude) THEN ...
Rozhodování bez ohledu na typ, tím myslím IF x > 5 THEN ..., bez ohledu na to, co to "x" je, protože mě zajímá jen odpověď na otázku, zda "to" je větší než 5.
Konkrétní příklad bych vzal mnohem prostší - chceš realizovat jakýsi print(x), který zajistí vypsání argumentu na terminál. Jaký datový typ x-u by ta funkce měla podle tebe optimálně očekávat a proč? V čem mi jakožto vývojáři pomůže, že ta funkce očekává ten konkrétní datový typ? Uvažuješ-li o stringu, tak pokračuj v úvaze dál - jak se teda pak vypořádat s ne-stringy. Nebo třeba seznam v Pascalu...

Jinými slovy, zatímco v klasickém přístupu chci pole integerů a případ, kdy bych chtěl pole nějakých obecných prvků, je více či méně krkolomný, u objektového přístupu chci primárně pole nějakých obecných prvků a když budu chtít, aby tam byly jen integery, budu si to muset nějak (více či méně krkolomně) pohlídat.
Nevidím důvod, proč by ty obecné prvky neměli mít patřičný typ. Mám komponentu, do které chci vkládat různé widgety. Tak bude dozajisté užitečné, když mi to tam pustí jen widgety (input, textarea, datepicker, timepicker, calendar, grid, form, ...), a integer nikoliv.
A co se zeptat opačně - proč by nutně musely mít nějaký dopředu známý patřičný typ?
To samozřejmě (u statického typování) nemusíš. Ale občas je fajn točit pivo do skleněné flašky, a bylinky sypat do papírové krabice. A zajistit, aby to nešlo naopak. Já tam neuváděl komponentu na inputy, ale komponentu na widgety.

Taška na rohlíky je provokace. Jestli nechceš vést vážou diskusi, tak to řekni rovnou :-)

Viděl jsi často, že by hostinský točil pivo do papírové krabice, přestože mu v tom nic nebrání? Jistě by šlo zařídit, aby se pípa odjistila jen v případě, že pod sebou detekuje konkrétně určený značkový půllitr. Mě by popadl rapl a ta pípa by letěla na smetiště hned v okamžiku, kdy by mi odmítala pustit pivo do džbánku.

Co je na tašce na rohlíky tak provokativního? Do datového typu rohlík dám jen rohlík a seznam rohlíků není nic jiného než taška na rohlíky. V době překladu vím, že mám datový typ, do kterého můžu naskládat jedině rohlíky. Jistě, mohu vytvořit i datový typ, do něhož jdou sázet rohlíky a housky. Ale i tuto situaci musím předvídat v době překladu.

A co se zeptat opačně - proč by nutně musely mít nějaký dopředu známý patřičný typ? Když jdu nakupovat rohlíky, tak k tomu také nepotřebuji speciální tašku na rohlíky.
Tady podsouváš něco, co není pravda (strawman). Že máš staticky typovaný jazyk ještě neimplikuje, že musíš nutně pracovat jenom s nějakými základními typy a všechny je zvlášť ošetřovat. Stačí ti mít nějaký mechanismus nadtypů (viz výš).

Že některé statické jazyky nadtypy nemají, to považuju za zločin (jo, mluvím o tobě, Go!).

Čili v tom tvém příkladu: máš nadtyp "cokoli do čeho se dá vložit cokoli, co je menší než Boeing" ;)
Neznám moc jazyků, které by obsahovaly "rohlík" jako jeden ze základních typů. Budu-li chtít modelovat nákupní tašku, tak jako nejjednodušší případ mě napadá nějaká kolekce, třeba seznam. Ale pořád mi tu BoneFlute nevysvětlil, seznam čeho by to optimálně měl být a jakou by to mělo výhodu oproti obecné dynamicky typované kolekci. Protože staticky typovaný jazyk mi říká "hele, tu informaci, co konkrétně se chystáš nakupovat, bezpodmínečně potřebuju znát dopředu", zatímco dynamicky typovaný jazyk nikoli. Vidím to tak, že ve statickém případě bych si musel definovat nějaký typ "zboží", který pojme veškerý sortiment plánovaného nákupu. Jenže proč bych se musel omezovat na cokoli, co třeba je menší než ten Boeing, když ze zadání problému neplyne, že bych nikdy neměl chtít koupit Boeing?

Statické typování mě nutí, abych dopředu znal nějaké omezení, nebo abych si ho uměle vytvořil, ačkoli z řešeného problému vůbec neplyne. To první je často nemožné a tedy vede k tomu druhému, což je smrtící. Nejčastějším problémem, se kterým se vývojář ve své pracovní době potýká, není obvykle přímo problém, který má za úkol vyřešit, ale jak se vypořádat s problémy, které si nadělal sám sobě dříve nebo které mu vymysleli jeho předchůdci. Takže jakmile se zákazník zeptá, proč nejde koupit Boeing, co mu na to odpovíš? A jak se budeš tvářit, až po X mandays práce, spočívající v překopávání půlky programu kvůli Boeingu, ti zákazník nezaplatí ani halíř, protože v té původní smlouvě o dílo není nikde napsáno, že by ten program neměl umět nakupovat Boeingy?
Název: Re:Co si myslíte o OOP?
Přispěvatel: BaldSlattery 31. 12. 2018, 12:39:05
A co se zeptat opačně - proč by nutně musely mít nějaký dopředu známý patřičný typ? Když jdu nakupovat rohlíky, tak k tomu také nepotřebuji speciální tašku na rohlíky.
Že některé statické jazyky nadtypy nemají, to považuju za zločin (jo, mluvím o tobě, Go!).
Go má rozhraní (kterému výše říkáš “nadtyp”), což je právě ten hledaný duck typing. Viz též vnitřní implementace rozhraní v Go, dost to připomíná dynamické “typování” à la Smalltalk (navenek to je bohužel omezené syntaxí, ale jde to obejít).
Název: Re:Co si myslíte o OOP?
Přispěvatel: BaldSlattery 31. 12. 2018, 12:43:23
Tedy "sum type"? Tak tam má Go asi fakt handicap.
Jo. Nebo se používá i termín "composite type".
Určitě? Composite type je prachobyčejný record/struct/class: https://en.wikipedia.org/wiki/Composite_data_type
Název: Re:Co si myslíte o OOP?
Přispěvatel: listoper 31. 12. 2018, 12:45:38
To E v REPL znamena "evaluate".  Nevim jak jinde, ale v mem oblibenem clojure proste predhodim REPLu kod a on se evaluuje. To znamena, ze pokud v tom kodu prepisu funkci, nebo cely namespace tak stara verze kodu efektivne zmizi a je nahrazena tou predhozenou.
A uz sem to videl v akci i na produkci... (byl to trochu opruz kvuli sitarum a bezpecakum, ale nakonec to probehlo)
No jistě, ale to je něco jinýho.

Hot reloading v Erlangu je o tom, že ti běží na serveru nějaká aplikace a ty v ní za běhu změníš část kódu. Klíčový je to, že měníš existující aplikaci, zatímco v REPLu vlastně vytváříš novou.

Ano na vzdalenem produkcnim serveru mi bezi existujici aplikace. Pripojim se pomoci nREPL a hot reloadnu si co chci...
V navrhu erlangu to zrejme bylo klicove, zatimco v clojure to funguje spis nahodou, nez ze by to byl cil... ale funguje.
Samozrejme se na nejtere veci musi davat pozor.... Pokud sejdes z cesty a zacnes intenzivne pouzivat java interop, nebo atomy tak si muzes tu bezici aplikaci nakopnout. Ale pokud budes psat pure funkce tak je to bez problemu.

Jednou sem dokonce celou aplkaci vyvyjel na vzdalenem serveru. Nebylo to nic velkeho a bylo to potreba jen na par tydnu. Nastartoval jsem si na cilovem serveru REPL u sebe CIDER a pripojil se na nej. Kdyz jsem byl hotov jen sem odpojil CIDER a nechal to bezet. Druhy den sem se zase pripojil abych pridal novy endpoint a zase odpojil. Bylo to jen v testovacim prostredi (na produkci bych na to nemel koule), ale intenzivne se pouzivalo behem toho co sem vyvyjel....
Název: Re:Co si myslíte o OOP?
Přispěvatel: Mirek Prýmek 31. 12. 2018, 12:45:52
Protože staticky typovaný jazyk mi říká "hele, tu informaci, co konkrétně se chystáš nakupovat, bezpodmínečně potřebuju znát dopředu",
A to právě není pravda. I ve statickém jazyce můžeš mít kolekci "neznámého" typu. Ten typ musí minimálně splňovat vlastnosti, které jsou pro tu danou kolekci potřeba (např. musí být hashovatelný) a maximálně to může být i konkrétní typ. K praktické implementaci pak potřebuješ parametrizovatelné typy - něco jako Array<String>.

Statické typování mě nutí, abych dopředu znal nějaké omezení
Ne. Dobře udělané statické typování tě jenom nutí, aby ty vkládané objekty měly vlastnosti, které pro vložení do té které kolekce jsou nutně potřeba (např. ta hashovatelnost). A to je správně.

, nebo abych si ho uměle vytvořil
Nic takového se neděje.
Název: Re:Co si myslíte o OOP?
Přispěvatel: Mirek Prýmek 31. 12. 2018, 12:49:10
Určitě? Composite type je prachobyčejný record/struct/class: https://en.wikipedia.org/wiki/Composite_data_type
No dyť jo :) Struct můžeš taky zneužít jako nadtyp: pokud chceš funkci, která vrací string nebo int, tak vrátíš struct se dvěma položkami, jedna string a druhá int.
Název: Re:Co si myslíte o OOP?
Přispěvatel: Mirek Prýmek 31. 12. 2018, 12:50:15
Ano na vzdalenem produkcnim serveru mi bezi existujici aplikace. Pripojim se pomoci nREPL a hot reloadnu si co chci...
V navrhu erlangu to zrejme bylo klicove, zatimco v clojure to funguje spis nahodou, nez ze by to byl cil... ale funguje.
Samozrejme se na nejtere veci musi davat pozor.... Pokud sejdes z cesty a zacnes intenzivne pouzivat java interop, nebo atomy tak si muzes tu bezici aplikaci nakopnout. Ale pokud budes psat pure funkce tak je to bez problemu.
No vždyť já netvrdím, že to v Clojure nejde. Jenom říkám, že to neplyne z toho, že má REPL.
Název: Re:Co si myslíte o OOP?
Přispěvatel: Inkvizitor 31. 12. 2018, 12:50:33
Tedy "sum type"? Tak tam má Go asi fakt handicap.
Jo. Nebo se používá i termín "composite type".

No ale interface naopak podporuje...
Ne že bych chtěl zrovna já obhajovat Go, jenom mě zajímalo, proč jsi po něm tak tvrdě vyjel.
Interfejsy sice podporuje, ale celkově je ten type systém dost omezený. Prakticky se to projevuje tak, že ve spoustě kódu uvidíš "prázdný interfejs" - tj. ekvivalent Object. Go je na tom prostě teď stejně jako Java před deseti lety. A i ty argumenty jsou stejné... (nejen) v tomhletom je Go trochu smutný příběh.

Jasně, i mně přijde návrh Go na hlavu (pragmatické výhody jsou, nepopírám). Teď řeší, jak udělat líp ošetření chyb, přičemž ale už v době původního návrhu jazyka muselo být jasné, že řešením je haskellovský Either. Jenže oni se rozhodli ten jazyk napsat takhle "blbě", protože takhle blbě se přece píše kód už desítky let a taky to jde.

Na druhou stranu třeba Rust má prakticky všechno správně - má algebraické typy, má pattern matching, má monadické řetězení operací, všechno krásně zapadá. Na druhou stranu je ten jazyk statický až na půdu, všechny ty abstrakce se v době překladu zapečou až pomalu do železa. Může to omezovat, ale sedí mi to dohromady.
Název: Re:Co si myslíte o OOP?
Přispěvatel: BaldSlattery 31. 12. 2018, 12:53:50
Určitě? Composite type je prachobyčejný record/struct/class: https://en.wikipedia.org/wiki/Composite_data_type
No dyť jo :) Struct můžeš taky zneužít jako nadtyp: pokud chceš funkci, která vrací string nebo int, tak vrátíš struct se dvěma položkami, jedna string a druhá int.
Můžu, všechno se dá ochcat, ale už to není sum type.
Název: Re:Co si myslíte o OOP?
Přispěvatel: JS 31. 12. 2018, 12:54:08
Tak snad nemusí být hned tak zle. Mě to jen připomělo, že občas narážím na hlasy, které obhajují dynamické typování. A já bych si někdy opravdu docela rád vyslechl v čem je to užitečné. (Čímž díky @Kiwi-mu za pokus o vysvětlení, ačkoliv to zatím nestačilo :-) )

Podle me to ma smysl u interpretovanych/skriptovacich jazyku, jejichz premisou je tvorba "lepiciho" kodu s pomerne malou mnozinou zakladnich typu. Pripadne v domenove-specifickych oblastech.

Typy se v programovani pouzivaji pro 3 ruzne ucely, a jen jeden z nich je typova kontrola. Pokud typovou kontrolu nutne nevyzadujes, pak typicky ani nevyzadujes druhy ucel, kterym je kontrola nad zpusobem ulozeni dat v pameti (coz je casto dusledek toho, ze mnozina zakladnich/vestavenych typu je mala). Zbyva tedy treti smysl typu - polymorfni dispatch - a u dynamickych jazyku se to zjednodusuje o to, ze se usetri jmenny prostor a nemusime type checkeru vysvetlovat nektere situace. Tedy vyhodou je, temer vyhradne, kratsi a prehlednejsi zapis.

Nicmene s rozvojem typove inference to prestava postupne davat smysl i v techto oblastech.
Název: Re:Co si myslíte o OOP?
Přispěvatel: Mirek Prýmek 31. 12. 2018, 12:54:14
Jasně, i mně přijde návrh Go na hlavu (pragmatické výhody jsou, nepopírám). Teď řeší, jak udělat líp ošetření chyb, přičemž ale už v době původního návrhu jazyka muselo být jasné, že řešením je haskellovský Either. Jenže oni se rozhodli ten jazyk napsat takhle "blbě", protože takhle blbě se přece píše kód už desítky let a taky to jde.

Na druhou stranu třeba Rust má prakticky všechno správně - má algebraické typy, má pattern matching, má monadické řetězení operací, všechno krásně zapadá. Na druhou stranu je ten jazyk statický až na půdu, všechny ty abstrakce se v době překladu zapečou až pomalu do železa. Může to omezovat, ale sedí mi to dohromady.
Jo, mám z toho úplně stejný pocit. V Go udělali několik rozhodnutí, který vůbec nechápu. V Rustu jsem na nic takovýho nenarazil (ale znám ho málo, daleko míň než Go, ve kterým jsem psal i nějaký netriviální produkční kód).

Co jsem se koukal na návrhy ohledně Go 2.0, vypadá to, že celkem napravují většinu věcí, který v jedniččce vůbec neměly být. Možná ta dvojka bude i docela pěknej jazyk konečně ;)
Název: Re:Co si myslíte o OOP?
Přispěvatel: Mirek Prýmek 31. 12. 2018, 12:54:55
Můžu, všechno se dá ochcat, ale už to není sum type.
Ne, je to product type ;)
Název: Re:Co si myslíte o OOP?
Přispěvatel: BaldSlattery 31. 12. 2018, 13:08:13
Mě to jen připomělo, že občas narážím na hlasy, které obhajují dynamické typování. A já bych si někdy opravdu docela rád vyslechl v čem je to užitečné.
Užitečná je pozdní vazba. A užitečná je i kontrola typů při překladu. Úplně nejlépe to má asi vyřešené ObjC, které má stejný dispatch zpráv jako Smalltalk, ale překladač kontroluje typy, jsou-li uvedeny (původní ObjC mělo jen “id”). Při překladu se tedy kontrolují typy vzhledem k hierarchii (dědičnost) a konformanci. Když chci, můžu použít “id” a pak se kontrola při překladu neprovádí. Většina běžného kódu tedy může být staticky otypovaná a jen v případě nouze můžu nechat kontrolu typů až na běh. Navíc v kombinaci s instancetype a auto se typy ani nemusí explicitně uvádět, překladač si je totiž odvodí (a zkontroluje) sám. V Go je pozdní vazba také (jako v ObjC) implementovaná pomocí isa, což se používá při volání metod na proměnných deklarovaných jako interface.
Název: Re:Co si myslíte o OOP?
Přispěvatel: listoper 31. 12. 2018, 13:22:47
Ano na vzdalenem produkcnim serveru mi bezi existujici aplikace. Pripojim se pomoci nREPL a hot reloadnu si co chci...
V navrhu erlangu to zrejme bylo klicove, zatimco v clojure to funguje spis nahodou, nez ze by to byl cil... ale funguje.
Samozrejme se na nejtere veci musi davat pozor.... Pokud sejdes z cesty a zacnes intenzivne pouzivat java interop, nebo atomy tak si muzes tu bezici aplikaci nakopnout. Ale pokud budes psat pure funkce tak je to bez problemu.
No vždyť já netvrdím, že to v Clojure nejde. Jenom říkám, že to neplyne z toho, že má REPL.

A ja si prave myslim, ze plyne. A koukal jsem na par prikladu jak se to dela v tom erlangu a prijde mi to velmi podobne. Neni eshell vlastne takovy REPL?
Treba java ma jshell, ale to neni (podle me) plnohodnotny REPL. A taky nevim jak udelat  v jave rozumne hot swapping. Slysel jsem o jRebel, ale nikdy jsem to nevidel v praxi.
Název: Re:Co si myslíte o OOP?
Přispěvatel: Mirek Prýmek 31. 12. 2018, 13:52:24
A ja si prave myslim, ze plyne. A koukal jsem na par prikladu jak se to dela v tom erlangu a prijde mi to velmi podobne. Neni eshell vlastne takovy REPL?
Ne "vlastne takovy", eshell je REPL.

Akorat porad nezorumim tomu, proc tyhle dve vlastnosti spojujes, jsou uplne ortogonalni. REPL muzes udelat v jakemkoliv jazyce, k hot code (re)loadingu potrebujes nekolik predpokladu, ktere ne kazdy jazyk splnuje.

V JVM, co jsem se dočetl, hot reloading jde, ale nemůžeš měnit signatury ani odstraňovat nebo přidávat metody. Takže vlastně můžeš jenom měnit implementaci existujících věcí.
Název: Re:Co si myslíte o OOP?
Přispěvatel: listoper 31. 12. 2018, 14:49:39
A ja si prave myslim, ze plyne. A koukal jsem na par prikladu jak se to dela v tom erlangu a prijde mi to velmi podobne. Neni eshell vlastne takovy REPL?
Ne "vlastne takovy", eshell je REPL.

Akorat porad nezorumim tomu, proc tyhle dve vlastnosti spojujes, jsou uplne ortogonalni. REPL muzes udelat v jakemkoliv jazyce, k hot code (re)loadingu potrebujes nekolik predpokladu, ktere ne kazdy jazyk splnuje.

V JVM, co jsem se dočetl, hot reloading jde, ale nemůžeš měnit signatury ani odstraňovat nebo přidávat metody. Takže vlastně můžeš jenom měnit implementaci existujících věcí.

Spojuju, protoze se domnivam, ze kdyz ma jazyk REPL tak uz ma vse co je potreba k hot swapu. Treba jde hot swap i bez nej, ale nevim jak.

Jake jsou ty predpoklady ktere myslis, ze jsou k hot swapu potreba?


A btw. taky se domnivam, ze nejde udelat (plnotucny) REPL v kazdem jazyce... Treba ta java ho pokud vim nema. Co treba C?
Název: Re:Co si myslíte o OOP?
Přispěvatel: Mirek Prýmek 31. 12. 2018, 15:08:00
Jake jsou ty predpoklady ktere myslis, ze jsou k hot swapu potreba?
No napriklad musis mit moznost nejak zabezpecit, ze kod nepoleze do kodu, ktery prave reloadujes. Nebo musis mit moznost mit zaraz v pameti dve verze tehoz. Pak musis mit vubec moznost kod za behu menit. Nesmi existovat zpusob, jak se na kod odkazovat (pointerem nebo necim podobnym), nebo musis mit moznost ty odkazy automaticky updatovat. Atd. atd. těch věcí je moře.

A btw. taky se domnivam, ze nejde udelat (plnotucny) REPL v kazdem jazyce... Treba ta java ho pokud vim nema. Co treba C?
REPL není nic jiného než iteraktivní vyhodnocovač výrazů. Pokud pro nějaký jazyk není, tak spíš proto, že to u něj nedává moc smysl, např. proto, že výrazy jsou v tom jazyce podružná věc. Mám pocit, že máš nějaké mylné představy o magické podstatě REPLu :)

Pro Javu existuje: https://www.infoq.com/articles/jshell-java-repl
Název: Re:Co si myslíte o OOP?
Přispěvatel: lopata 31. 12. 2018, 15:11:25
A btw. taky se domnivam, ze nejde udelat (plnotucny) REPL v kazdem jazyce... Treba ta java ho pokud vim nema. Co treba C?

REPL jde udělat s trochou snahy v každém jazyce: https://github.com/root-project/cling

S hot swapem to není tak jednoduché, vem si třeba inlinované funkce,  jak bys je chtěl hot swapovat? Jediné rozumné řešení je všechno překompilovat, což už se dá dost těžko považovat za hot swap.
Název: Re:Co si myslíte o OOP?
Přispěvatel: anonym 31. 12. 2018, 15:11:29
A ja si prave myslim, ze plyne. A koukal jsem na par prikladu jak se to dela v tom erlangu a prijde mi to velmi podobne. Neni eshell vlastne takovy REPL?
Ne "vlastne takovy", eshell je REPL.

Akorat porad nezorumim tomu, proc tyhle dve vlastnosti spojujes, jsou uplne ortogonalni. REPL muzes udelat v jakemkoliv jazyce, k hot code (re)loadingu potrebujes nekolik predpokladu, ktere ne kazdy jazyk splnuje.

V JVM, co jsem se dočetl, hot reloading jde, ale nemůžeš měnit signatury ani odstraňovat nebo přidávat metody. Takže vlastně můžeš jenom měnit implementaci existujících věcí.

Synku, Java to neni jen tak nejaka technologie s fajnovym marketingem, muzes metody pridavat, i tridy, potrebujes jen JVM opatchovat s DCEVM.

S Hot swapem se vsak (jak jinak) nedaji menit jakekoliv inicializace cehosi. Proto me stve, kdyz nekdo udela nejaky framework co ma byt jakoze jednoduchy, ale pitome a zbytecne tam dela nejaky inicializace, cimz znemozni hot swap. (treba hotswap kdyz menis rest api)

Nicmene v praxi se v Jave stejne da pouzit JRebel, ktery vylepsuje nejen hotswap, ale taky zna implementacni detaily ruznych frameworku a tak dokaze udelat i reinicializaci. Jenze stoji 10000,- rocne, coz sockam, ktere by nejradeji nezaplatily ani za IntelliJ Ideu a pouzili misto toho Eclipse, pripada jako hodne.

Nicmene v praxi v korporatech neni vetsinou potreba neco hotswapovat, kdyz se dodrzuje TDD. Takze to pak tolik nechybi
Název: Re:Co si myslíte o OOP?
Přispěvatel: Kit 31. 12. 2018, 15:30:47
Jake jsou ty predpoklady ktere myslis, ze jsou k hot swapu potreba?
No napriklad musis mit moznost nejak zabezpecit, ze kod nepoleze do kodu, ktery prave reloadujes. Nebo musis mit moznost mit zaraz v pameti dve verze tehoz. Pak musis mit vubec moznost kod za behu menit. Nesmi existovat zpusob, jak se na kod odkazovat (pointerem nebo necim podobnym), nebo musis mit moznost ty odkazy automaticky updatovat. Atd. atd. těch věcí je moře.

To není tak složité. Vytvoříš nový derivační strom a přehodíš na něj pointer z předchozího stromu. Proces, který běží v předchozím stromu, v něm normálně doběhne a další procesy už běží v novém stromu. Starý strom je zrušen teprve tehdy, až na něj žádný pointer neukazuje.
Název: Re:Co si myslíte o OOP?
Přispěvatel: BoneFlute 31. 12. 2018, 15:51:50
2. Někdy se hodí, zejména na prototypování, když jsou typy volitelné, a následně to při refactoringu upřesňovat. Protože ze začátku člověk třeba nemá jasno, jak to má vypadat, a tak samozřejmě dost dobře nemůže ty typy určit.

Tohle mi prijde zvlastni. refactoring chapu jako "cisteni" kodu v pripade, ze uz funguje spravne tzn. beze zmeny funkcionality... Abych mohl delat refactoring "bezpecne" potrebuju mit uz v ruce nejaky kontrolni mechanizmus (testy nebo typovou kontrolu), abych mohl po vycisteni prokazat, zachovani funcionality.

Takze, kdyz budu delat nejaky proof of concept tak muzu bez testu a bez typu, ale rozhodne to pak nebudu refactorovat do nejake produkcni verze, protoze bych se osypal.
Je možné, že výraz refactoring jsem nepoužil podle příručky.

Představ si funkci, která má argumenty a plní formulář:
Kód: [Vybrat]
function assetContactForm(form, name, age, email, content)
{
    form['name'].value = name
    form['age'].value = age
    form['email'].value = email
    form['content'].value = content
    return form
}
Ze začátku to plníš takhle. Pak si ale řekneš, že by si chtěl omezit vstupy  na číslo, text, etc. A nebo zjistíš, že vlastně ta funkce je celá blbě.
Využiješ situace, že na začátku pracuješ s ideálními podmínkami. Ale na závěr už chceš spolehlivý kód.
Název: Re:Co si myslíte o OOP?
Přispěvatel: listoper 31. 12. 2018, 15:53:09
Jake jsou ty predpoklady ktere myslis, ze jsou k hot swapu potreba?
No napriklad musis mit moznost nejak zabezpecit, ze kod nepoleze do kodu, ktery prave reloadujes. Nebo musis mit moznost mit zaraz v pameti dve verze tehoz. Pak musis mit vubec moznost kod za behu menit. Nesmi existovat zpusob, jak se na kod odkazovat (pointerem nebo necim podobnym), nebo musis mit moznost ty odkazy automaticky updatovat. Atd. atd. těch věcí je moře.
No a ja tvrdim, ze pokud mas plnotucny REPL tak musis mit vsechny tyhle veci taky, protoze jinak bys nemohl mit ani ten.  A z toho vyvozuju, ze pokud mas REPL mas i hot swap.

A btw. taky se domnivam, ze nejde udelat (plnotucny) REPL v kazdem jazyce... Treba ta java ho pokud vim nema. Co treba C?
REPL není nic jiného než iteraktivní vyhodnocovač výrazů. Pokud pro nějaký jazyk není, tak spíš proto, že to u něj nedává moc smysl, např. proto, že výrazy jsou v tom jazyce podružná věc. Mám pocit, že máš nějaké mylné představy o magické podstatě REPLu :)

Pro Javu existuje: https://www.infoq.com/articles/jshell-java-repl

No a podle me to R v REPL znamena read a jeho reader by mel umet precist jakykoliv kod ktery jde zkompilovat/interpretovat i mimo repl. Pokud tomu tak neni tak to neni plnohodnotny REPL.
Napriklad jshell neumi package http://openjdk.java.net/jeps/222 (http://openjdk.java.net/jeps/222):
"A snippet may not declare a package or a module. All JShell code is placed in a single package in an unnamed module. The name of the package is controlled by JShell."

Název: Re:Co si myslíte o OOP?
Přispěvatel: Mirek Prýmek 31. 12. 2018, 15:53:33
Synku, Java to neni jen tak nejaka technologie s fajnovym marketingem, muzes metody pridavat, i tridy, potrebujes jen JVM opatchovat s DCEVM.
Takže, tatínku, pro normální JVM od Sunu platí to, co jsem napsal :)
Název: Re:Co si myslíte o OOP?
Přispěvatel: BoneFlute 31. 12. 2018, 15:54:08
Např. pokud víš, že ve výrazu x / y je y s jistotou "integer", je ti to víceméně na nic, protože situace, kdy je y nula má stejné důsledky jako kdyby to byl string. Dělení nulou je stejně nedefinované jako dělení stringem. Takže kdykoli se ti v programu objeví dělení (nebo jakákoli jiná parciální funkce), stane se ti ze statického jazyka efektivně dynamický - protože prostě v době překladu nejsi schopný ověřit korektnost.
S tím nemám problém. Já neobhajuji statické typování. Já hejtuju dynamické.
Název: Re:Co si myslíte o OOP?
Přispěvatel: Mirek Prýmek 31. 12. 2018, 15:56:51
No a ja tvrdim, ze pokud mas plnotucny REPL tak musis mit vsechny tyhle veci taky, protoze jinak bys nemohl mit ani ten.  A z toho vyvozuju, ze pokud mas REPL mas i hot swap.
No tak to z chybného předpokladu vyvozuješ chybný závěr, no, co na to říct jiného? REPL máš třeba v pythonu a code reloading tam dělat nejde (AFAIK). Existující kód prostě běží dál, změny se projeví jenom v nově nataženém.

Pokud tomu tak neni tak to neni plnohodnotny REPL.
Beru na vědomí tvou definici "plnohodnotného REPLu".

Ani ten ti ale na hot code reload nestačí.
Název: Re:Co si myslíte o OOP?
Přispěvatel: listoper 31. 12. 2018, 15:57:38
A btw. taky se domnivam, ze nejde udelat (plnotucny) REPL v kazdem jazyce... Treba ta java ho pokud vim nema. Co treba C?

REPL jde udělat s trochou snahy v každém jazyce: https://github.com/root-project/cling

S hot swapem to není tak jednoduché, vem si třeba inlinované funkce,  jak bys je chtěl hot swapovat? Jediné rozumné řešení je všechno překompilovat, což už se dá dost těžko považovat za hot swap.

Viz. odpoved Mirkovi. cling neznam, ale myslim, ze to nebude plnohodnotny REPL.
Název: Re:Co si myslíte o OOP?
Přispěvatel: Mirek Prýmek 31. 12. 2018, 15:57:47
S tím nemám problém. Já neobhajuji statické typování. Já hejtuju dynamické.
Však jo. Já jenom, že ty tvoje hejty platí i pro statické, jenom v menší míře.
Název: Re:Co si myslíte o OOP?
Přispěvatel: lopata 31. 12. 2018, 16:06:26
Viz. odpoved Mirkovi. cling neznam, ale myslim, ze to nebude plnohodnotny REPL.

Cling je plnohodnotný REPL. On totiž REPL nemusí vůbec inlinovat funkce, k ničemu to v REPLu není prakticky dobré.

Ale v produkčním kódu inlinované funkce jsou a to je jeden z důvodů, proč nejde udělat hot swap, i když existuje plnohodnotný REPL.
Název: Re:Co si myslíte o OOP?
Přispěvatel: BoneFlute 31. 12. 2018, 16:07:07
1. Erlang dokáže za chodu opravovat/upravovat kód. A autoři prohlásili, že tam typy nedali, protože se jim nepovedlo vymyslet jak na to.
Měl bys k tomuhle nějakej odkaz? Přijde mi divný, že by to zaznělo přesně takhle (že by tím důvodem byl právě hot code loading).
Bohužel. Někde jsem to četl. A klidně to může být kec, nestojí mi na tom můj světonázor :-)

1. Několikrát opakuješ obrat "nemá typy". To je minimálně zavádějící. Dynamické jazyky mají typy. Od staticky typovaných se liší jenom tím, jestli informaci o typu znáš (pozitivně, s jistotou) při překladu, nebo až v době běhu. V principu provádíš tu stejnou kontrolu, jenom jindy. Výhoda statických jazyků je v tom, že kontrolu provedeš (ve většině případů - viz 2) jenom jednou, zatímco u dynamického ji musíš provádět pořád dokola, za běhu.
Snažil jsem se bavit o statickém typování, nikoliv o staticky typovaných jazycích. A pro mě podstatný rozdíl je právě a hlavně v tom, že jsem schopen ten kód zkontrolovat při překladu. Jak píšeš. To, že při dynamickém typování ty výrazy si nesou typy, to jsem (doufám) nikde nerozporoval. Každopádně to nepovažuji za výhodu, ale za znouzecnost. Ale někteří tvrdí, že by to měla být výhoda.

2. Z bodu 1 přímo vyplývá, že statický jazyk má problém v situacích, kdy typ v době překladu z principu nemůžeš znát - to je ten příklad s načítáním JSONu, ale můžeš jich vymyslet bambilion jiných. Můžeš to řešit dvěma způsoby (možná i jinak, ale teď mě jiná možnost nenapadá):

A) buď máš k dispozici algebraické typy a (v době překladu neznámý) typ prohlásíš za nějakou nadmnožinu různých typů, v extrémním případě všech myslitelných a dál pracuješ s tímhle nadtypem

B) nebo typ zjistíš za běhu (dynamické typování!) a program podle typu větvíš, takže i v době překladu víš, že do určité větve ti jde už jenom určitý typ
Uváděl jsem příklad jakéhosi kódu s JSONem. IMHO pro staticky typovaný jazyk to není problém. Dokonce bych se troufal tvrdit, že je na to šikovnější.

Zajímalo  by mě pár kousků  těch bambilionu jiných, kde dynamické typování je vhodnější (nikoliv jediné technicky možné).

3. Někde jsi řekl, že do dynamických jazyků nejdou typy (při překladu) dodat. To není pravda. Stejně jako se u statického jazyka občas musíš uchýlit k dynamickému typování, můžeš u dynamického jazyka otypovat ty části programu, kde v době překladu víš, co tam bude za typ. A můžeš to i kontrolovat, úplně stejně jako u statického (viz např. u Erlangu Dializer). Dokonce by asi i šlo (ale nevím o žádném dynamickém jazyce, který by to uměl) třeba některé části programu otypovat staticky a u nich vyhodit kontroly typů za běhu.
Myslím, že to jsem nebyl já.

Prostě, ty dva přístupy se vzájemně nevylučují. Je třeba si jenom uvědomit, že u některých částí programu víš předem, s jakými daty může pracovat, u jiných částí to nevíš (ani u jednoho typu jazyka). Ty části můžou být různě velké.
Já vím.

Na druhou stranu s tebou docela souhlasím v tom, že udržovat tu část, kde typy znáš, co největší (a tím se vyvarovat runtime chybám) je docela dobrý přístup. Ale i kdyby ses na hlavu postavil, nemůžeš mít takových 100% programu. Někde prostě z principu věci dostaneš data, jejichž typ v době překladu neznáš.
Otázka narážela na tvrzení, že dynamické typování má nějaké nesporné výhody. To, že mám blbej jazyk, který to neumí, nepovažuji za výhodu. To, že typy neumím, také nepovažuji za výhodu (i když...).

Troufám si neskromě tvrdit, že celkem vím, jaký je rozdíl mezi staticky a dynamicky typováním. Ale ať nad tím dumám jak dumám, tak mi vychází, že dynamické typování je znouzecnost. Nemá žádné benefity. Pletu se?
Název: Re:Co si myslíte o OOP?
Přispěvatel: BoneFlute 31. 12. 2018, 16:12:49
S tím nemám problém. Já neobhajuji statické typování. Já hejtuju dynamické.
Však jo. Já jenom, že ty tvoje hejty platí i pro statické, jenom v menší míře.

Jsem si toho vědom. Ale to už je úplně jiná otázka. (Můj velký sen je typový systém (nebo cokoliv jiného), kterým budu schopen zajistit absolutní korektnost. Ale to už jsme tu tuším probírali, a narážel jsem na nepochopení :-))
Název: Re:Co si myslíte o OOP?
Přispěvatel: Kit 31. 12. 2018, 16:13:36
Představ si funkci, která má argumenty a plní formulář:
Kód: [Vybrat]
function assetContactForm(form, name, age, email, content)
{
    form['name'].value = name
    form['age'].value = age
    form['email'].value = email
    form['content'].value = content
    return form
}
Ze začátku to plníš takhle. Pak si ale řekneš, že by si chtěl omezit vstupy  na číslo, text, etc. A nebo zjistíš, že vlastně ta funkce je celá blbě.
Využiješ situace, že na začátku pracuješ s ideálními podmínkami. Ale na závěr už chceš spolehlivý kód.

V PHP to jde docela snadno. Prostě ty typy nacpeš do formálních parametrů a máš hotovo.
Kód: [Vybrat]
function assetContactForm(array $form, string $name, int $age, string $email, string $content) {
    $form['name'] = $name;
    $form['age'] = $age;
    $form['email'] = $email;
    $form['content'] = $content;
    return $form;
}
Název: Re:Co si myslíte o OOP?
Přispěvatel: BoneFlute 31. 12. 2018, 16:17:52
Dokonce by asi i šlo (ale nevím o žádném dynamickém jazyce, který by to uměl) třeba některé části programu otypovat staticky a u nich vyhodit kontroly typů za běhu.
PHP, google-closure-compiler, Flow, TypeScript.

Nevím jak je na tom to vyhození kontroly typů za běhu (minimálně snad google-closure-compiler by to měl splňovat). Ale zatím pozoruju, že 1) to vyhození kontroly není potřeba, 2) jen z dynamicky typovaného jazyka děláš staticky typovaný jazyk. Takže jsme IMHO u slovíčkaření.
Název: Re:Co si myslíte o OOP?
Přispěvatel: BoneFlute 31. 12. 2018, 16:22:43
V PHP to jde docela snadno. Prostě ty typy nacpeš do formálních parametrů a máš hotovo.
Kód: [Vybrat]
function assetContactForm(array $form, string $name, int $age, string $email, string $content) {
    $form['name'] = $name;
    $form['age'] = $age;
    $form['email'] = $email;
    $form['content'] = $content;
    return $form;
}

Aby to bylo typově korektní, tak ten $form musí být typu (Form String, Int, String, String, ...) :-P (Ale to samozřejmě nebylo pointou mého příspěvku.)
Název: Re:Co si myslíte o OOP?
Přispěvatel: Kit 31. 12. 2018, 16:23:42
Troufám si neskromě tvrdit, že celkem vím, jaký je rozdíl mezi staticky a dynamicky typováním. Ale ať nad tím dumám jak dumám, tak mi vychází, že dynamické typování je znouzecnost. Nemá žádné benefity. Pletu se?

Statické typování nemá žádné benefity, pouze vývojáři hází klacky pod nohy a znemožňuje velmi pozdní vazbu. Vývojáři to obchází tak, že část kódu udělají přes dynamický REPL. U dynamicky typovaného jazyka je to naopak: Staticky natypuji jen to, co skutečně chci mít staticky typováno.
Název: Re:Co si myslíte o OOP?
Přispěvatel: Mirek Prýmek 31. 12. 2018, 16:27:07
Zajímalo  by mě pár kousků  těch bambilionu jiných, kde dynamické typování je vhodnější (nikoliv jediné technicky možné).
Neříkal jsem, že je vhodnější, ale že je bambilion případů, kdy musíš statické typování opustit a přejít na dynamické, protože prostě typ v době překladu neznáš. Je to jakákoliv situace, kdy data načítáš z externího zdroje. Z principu věci ti typový systém může zaručit, že je někde nějaký typ, jenom za předpokladu, že ten zdroj těch dat má pod kontrolou. Kdykoli načítáš ze sítě nebo z disku, typy nemáš.

Ale ať nad tím dumám jak dumám, tak mi vychází, že dynamické typování je znouzecnost. Nemá žádné benefity. Pletu se?
Se zkvalitněním inference výhody trochu ubývají. Ale pár bys jich našel. Například když potřebuješ někde na zkoušku nějaký typ změnit, může ti probublat do spousty kódu, takže to musíš změnit i na spoustě mít, který vůbec spouštět nechceš. Je to podobný jako s IO v Haskellu - nemůžeš si někam jenom tak narychlo dát nějaký debug výpis...

Tohle jasná výhoda je. A našel bys jich víc. Jestli převažují nevýhody, to ať si každý soudruh posoudí sám :)
Název: Re:Co si myslíte o OOP?
Přispěvatel: Kit 31. 12. 2018, 16:28:03
V PHP to jde docela snadno. Prostě ty typy nacpeš do formálních parametrů a máš hotovo.
Kód: [Vybrat]
function assetContactForm(array $form, string $name, int $age, string $email, string $content) {
    $form['name'] = $name;
    $form['age'] = $age;
    $form['email'] = $email;
    $form['content'] = $content;
    return $form;
}

Aby to bylo typově korektní, tak ten $form musí být typu (Form String, Int, String, String, ...) :-P (Ale to samozřejmě nebylo pointou mého příspěvku.)

To by nefungovalo. Napsal jsem svůj kód dle tvého příkladu, který je v PHP korektní a funkční.
Název: Re:Co si myslíte o OOP?
Přispěvatel: listoper 31. 12. 2018, 16:30:18
No a ja tvrdim, ze pokud mas plnotucny REPL tak musis mit vsechny tyhle veci taky, protoze jinak bys nemohl mit ani ten.  A z toho vyvozuju, ze pokud mas REPL mas i hot swap.
No tak to z chybného předpokladu vyvozuješ chybný závěr, no, co na to říct jiného? REPL máš třeba v pythonu a code reloading tam dělat nejde (AFAIK). Existující kód prostě běží dál, změny se projeví jenom v nově nataženém.
Uz je to davno co sem delal s pythonem. Ale melo by to jit.

Pokud tomu tak neni tak to neni plnohodnotny REPL.
Beru na vědomí tvou definici "plnohodnotného REPLu".

Ani ten ti ale na hot code reload nestačí.

Nerikam, ze k hot swapu je potreba REPL. Ale ze k REPLu je potreba hot swap.
Tudis vsude kde REPL je... Musi byt i hot swap

Název: Re:Co si myslíte o OOP?
Přispěvatel: Mirek Prýmek 31. 12. 2018, 16:32:34
Ale melo by to jit.
Ne, nejde to, smiř se s tím, mýlíš se.

(sorry, tohle téma už mě nebaví, omlouvám se z něj)
Název: Re:Co si myslíte o OOP?
Přispěvatel: BoneFlute 31. 12. 2018, 16:45:00
V PHP to jde docela snadno. Prostě ty typy nacpeš do formálních parametrů a máš hotovo.
Kód: [Vybrat]
function assetContactForm(array $form, string $name, int $age, string $email, string $content) {
    $form['name'] = $name;
    $form['age'] = $age;
    $form['email'] = $email;
    $form['content'] = $content;
    return $form;
}

Aby to bylo typově korektní, tak ten $form musí být typu (Form String, Int, String, String, ...) :-P (Ale to samozřejmě nebylo pointou mého příspěvku.)

To by nefungovalo. Napsal jsem svůj kód dle tvého příkladu, který je v PHP korektní a funkční.

Nechápu, co se pokoušíš říct?
Název: Re:Co si myslíte o OOP?
Přispěvatel: listoper 31. 12. 2018, 16:45:45
Ale melo by to jit.
Ne, nejde to, smiř se s tím, mýlíš se.

(sorry, tohle téma už mě nebaví, omlouvám se z něj)
OK Miro. si omluven.
Pro ostatni: https://docs.python.org/3/library/importlib.html#importlib.reload (https://docs.python.org/3/library/importlib.html#importlib.reload)
Je tu nejakej pythonak, kterej by rekl, jestli je to pouzitelne?
Název: Re:Co si myslíte o OOP?
Přispěvatel: BoneFlute 31. 12. 2018, 16:51:05
Zajímalo  by mě pár kousků  těch bambilionu jiných, kde dynamické typování je vhodnější (nikoliv jediné technicky možné).
Neříkal jsem, že je vhodnější, ale že je bambilion případů, kdy musíš statické typování opustit a přejít na dynamické, protože prostě typ v době překladu neznáš. Je to jakákoliv situace, kdy data načítáš z externího zdroje. Z principu věci ti typový systém může zaručit, že je někde nějaký typ, jenom za předpokladu, že ten zdroj těch dat má pod kontrolou. Kdykoli načítáš ze sítě nebo z disku, typy nemáš.
Já nevím, tohle se mi nezdá. Když mám data z externího zdroje, stále to můžu otypovat. Typy dělají jakoby "cestičky". Prostě mám vstup od uživatele (co může být více nespolehlivé). A vím, 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.


Ale ať nad tím dumám jak dumám, tak mi vychází, že dynamické typování je znouzecnost. Nemá žádné benefity. Pletu se?
Se zkvalitněním inference výhody trochu ubývají. Ale pár bys jich našel. Například když potřebuješ někde na zkoušku nějaký typ změnit, může ti probublat do spousty kódu, takže to musíš změnit i na spoustě mít, který vůbec spouštět nechceš. Je to podobný jako s IO v Haskellu - nemůžeš si někam jenom tak narychlo dát nějaký debug výpis...

Tohle jasná výhoda je. A našel bys jich víc. Jestli převažují nevýhody, to ať si každý soudruh posoudí sám :)

Ano, tu mám v tom seznamu :-)
Jde vlastně o featuru, moct ty typy vypnout. Protože třeba ten Haskell to vždycky kompiluje jako na produkci.
Název: Re:Co si myslíte o OOP?
Přispěvatel: Kit 31. 12. 2018, 17:06:20
V PHP to jde docela snadno. Prostě ty typy nacpeš do formálních parametrů a máš hotovo.
Kód: [Vybrat]
function assetContactForm(array $form, string $name, int $age, string $email, string $content) {
    $form['name'] = $name;
    $form['age'] = $age;
    $form['email'] = $email;
    $form['content'] = $content;
    return $form;
}
Aby to bylo typově korektní, tak ten $form musí být typu (Form String, Int, String, String, ...) :-P (Ale to samozřejmě nebylo pointou mého příspěvku.)
To by nefungovalo. Napsal jsem svůj kód dle tvého příkladu, který je v PHP korektní a funkční.
Nechápu, co se pokoušíš říct?

To je otázka nebo konstatování?

V původní ukázce jsi nic takového neuvedl, proto jsem to udělal tak jak jsem to udělal. Pokud Form bude třída, tak to bude v PHP vypadat asi takto:
Kód: [Vybrat]
function assetContactForm(Form $form, string $name, int $age, string $email, string $content) {
    $form->name = $name;
    $form->age = $age;
    $form->email = $email;
    $form->content = $content;
    return $form;
}
Vše řádně otypováno, včetně $form->name atd. Spokojen?
Název: Re:Co si myslíte o OOP?
Přispěvatel: v 31. 12. 2018, 17:31:27
Je to podobný jako s IO v Haskellu - nemůžeš si někam jenom tak narychlo dát nějaký debug výpis...
ale může http://hackage.haskell.org/package/base-4.12.0.0/docs/Debug-Trace.html#v:trace
Název: Re:Co si myslíte o OOP?
Přispěvatel: v 31. 12. 2018, 17:36:16
Ale ať nad tím dumám jak dumám, tak mi vychází, že dynamické typování je znouzecnost. Nemá žádné benefity. Pletu se?
dynamický jazyk umožňuje napsat většinu konstrukcí jako ve statickém jazyce bez nutnosti přesvědčovat typechecker, že víte co děláte, taky se snadněji implementuje (protože nepotřebuje typechecker)
Název: Re:Co si myslíte o OOP?
Přispěvatel: Mirek Prýmek 31. 12. 2018, 17:45:52
Je tu nejakej pythonak, kterej by rekl, jestli je to pouzitelne?
Existující kód prostě běží dál, změny se projeví jenom v nově nataženém.
Název: Re:Co si myslíte o OOP?
Přispěvatel: Mirek Prýmek 31. 12. 2018, 17:46:16
ale může http://hackage.haskell.org/package/base-4.12.0.0/docs/Debug-Trace.html#v:trace
Jistě, ale to je hack.
Název: Re:Co si myslíte o OOP?
Přispěvatel: Kadet 31. 12. 2018, 17:49:22
Zajímalo  by mě pár kousků  těch bambilionu jiných, kde dynamické typování je vhodnější (nikoliv jediné technicky možné).
Neříkal jsem, že je vhodnější, ale že je bambilion případů, kdy musíš statické typování opustit a přejít na dynamické, protože prostě typ v době překladu neznáš. Je to jakákoliv situace, kdy data načítáš z externího zdroje. Z principu věci ti typový systém může zaručit, že je někde nějaký typ, jenom za předpokladu, že ten zdroj těch dat má pod kontrolou. Kdykoli načítáš ze sítě nebo z disku, typy nemáš.
Já nevím, tohle se mi nezdá. Když mám data z externího zdroje, stále to můžu otypovat. Typy dělají jakoby "cestičky". Prostě mám vstup od uživatele (co může být více nespolehlivé). A vím, 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.

Uvazujes tak, ze uz vis presne, co s temi prichozimi daty chces udelat. Tj. ziskat jmeno, cislo, pripadne hodit error, kdyz se to nepovede.

Ale aby sis moh s temi prichozimi daty hrat a prozkoumavat je, musis je bud plne otypovat nebo pouzit dynamicky typovani. Zjistili jsme ze plne typovat ty jsony nechces, dynamicky typovat je taky nechces, tak mi z toho vyplyva opet, ze potrebujes presny zadani, jinak odmitas pracovat.

To reprezentuje tu sortu programatoru, ktery se nehnou z mista, dokud nemaji precizne zpracovany zadani. S preciznim zadanim je pak suna fuk jestli pouzijes python nebo haskell, protoze jsi dostal definici vstupu a vystupu, tak z toho akorat napises funkci.

Programivani je ale casto o prozkoumavani moznych reseni. A proto v nejistych podminkach dynamicky jazyky vzdy zvitezily.
Název: Re:Co si myslíte o OOP?
Přispěvatel: Mirek Prýmek 31. 12. 2018, 18:06:02
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í :) Vstup od uživatele není moc dobrej příklad, protože to je vždycky string. Zajímavější je třeba deserializace z disku nebo sítě.

Jde vlastně o featuru, moct ty typy vypnout. Protože třeba ten Haskell to vždycky kompiluje jako na produkci.
Přesně tak. Chceš jenom něco narychlo prubnout a přitom jsi nucenej psát stejně kvalitní kód jako pro produkci. A to je opruz.
Název: Re:Co si myslíte o OOP?
Přispěvatel: v 31. 12. 2018, 18:07:46
Přesně tak. Chceš jenom něco narychlo prubnout a přitom jsi nucenej psát stejně kvalitní kód jako pro produkci. A to je opruz.
https://ghc.haskell.org/trac/ghc/wiki/DeferErrorsToRuntime
Název: Re:Co si myslíte o OOP?
Přispěvatel: listoper 31. 12. 2018, 18:08:19
Je tu nejakej pythonak, kterej by rekl, jestli je to pouzitelne?
Existující kód prostě běží dál, změny se projeví jenom v nově nataženém.
Ty ne. Ty mas omluvenku ;-).

Ale tak dobre... jestli moc chces muzes mi to vysvetlit. Ja budu poslouchat.
Název: Re:Co si myslíte o OOP?
Přispěvatel: Mirek Prýmek 31. 12. 2018, 18:09:25
Ale tak dobre... jestli moc chces muzes mi to vysvetlit. Ja budu poslouchat.
https://stackoverflow.com/questions/3862871/hot-reloading-swapping-with-python
Název: Re:Co si myslíte o OOP?
Přispěvatel: listoper 31. 12. 2018, 19:09:36
Ale tak dobre... jestli moc chces muzes mi to vysvetlit. Ja budu poslouchat.
https://stackoverflow.com/questions/3862871/hot-reloading-swapping-with-python
Ok. Procetl jsem. I nektere ty odkazovane veci. A nejsem si jisty, co mas na mysli.
Vsude se pise jak se to da udelat... A na co si dat pozor.

To, ze stare objekty (vytvorene podle predchozi verze kodu) zustanou nezmenene je snad v poradku ne?
Název: Re:Co si myslíte o OOP?
Přispěvatel: BoneFlute 31. 12. 2018, 19:11:26
Zajímavější je třeba deserializace z disku nebo sítě.
V čem je to jiné? Taky dostanu proud dat, defakto string, defakto zase musím použít Maybe.
Název: Re:Co si myslíte o OOP?
Přispěvatel: Mirek Prýmek 31. 12. 2018, 19:11:49
To, ze stare objekty (vytvorene podle predchozi verze kodu) zustanou nezmenene je snad v poradku ne?
Ne. To je to, co ti porad nedochazi. Podstata je ve vymene stareho za nove ne ve vytvoreni noveho. To druhé Python umí (a umí to jakýkoliv jazyk s REPL), to první ne.
Název: Re:Co si myslíte o OOP?
Přispěvatel: Mirek Prýmek 31. 12. 2018, 19:13:20
V čem je to jiné? Taky dostanu proud dat, defakto string, defakto zase musím použít Maybe.
Jiné je to v tom, že serializovaná data můžou obsahovat serializované typy. Tj. dostaneš se přesně do situace dynamicky typovaného jazyka - typy znáš (pozitivně, jistě) v době běhu, ale ne v době překladu.
Název: Re:Co si myslíte o OOP?
Přispěvatel: BoneFlute 31. 12. 2018, 19:14:14
Uvazujes tak, ze uz vis presne, co s temi prichozimi daty chces udelat. Tj. ziskat jmeno, cislo, pripadne hodit error, kdyz se to nepovede.

Ale aby sis moh s temi prichozimi daty hrat a prozkoumavat je, musis je bud plne otypovat nebo pouzit dynamicky typovani. Zjistili jsme ze plne typovat ty jsony nechces, dynamicky typovat je taky nechces, tak mi z toho vyplyva opet, ze potrebujes presny zadani, jinak odmitas pracovat.

To reprezentuje tu sortu programatoru, ktery se nehnou z mista, dokud nemaji precizne zpracovany zadani. S preciznim zadanim je pak suna fuk jestli pouzijes python nebo haskell, protoze jsi dostal definici vstupu a vystupu, tak z toho akorat napises funkci.

Programivani je ale casto o prozkoumavani moznych reseni. A proto v nejistych podminkach dynamicky jazyky vzdy zvitezily.
Supr. Tak jsme se s velkou parádou dostaly k bodu dva, o tom, že bez typů se lépe prototypuje. To je všechno?
Název: Re:Co si myslíte o OOP?
Přispěvatel: listoper 31. 12. 2018, 19:21:08
To, ze stare objekty (vytvorene podle predchozi verze kodu) zustanou nezmenene je snad v poradku ne?
Ne. To je to, co ti porad nedochazi. Podstata je ve vymene stareho za nove ne ve vytvoreni noveho. To druhé Python umí (a umí to jakýkoliv jazyk s REPL), to první ne.

Tak to ale erlang taky neumi.
Název: Re:Co si myslíte o OOP?
Přispěvatel: Mirek Prýmek 31. 12. 2018, 19:21:50
Tak to ale erlang taky neumi.
Jak jsi na to prisel?
Název: Re:Co si myslíte o OOP?
Přispěvatel: hawran diskuse 31. 12. 2018, 19:47:30
Chlopé, běžte ven (mezi lidi)!
 :)  ;)  :D  ;D
Název: Re:Co si myslíte o OOP?
Přispěvatel: Mirek Prýmek 31. 12. 2018, 19:48:35
Chlopé, běžte ven (mezi lidi)!
 :)  ;)  :D  ;D
Já náhodou běhám celej den.




[ve Factoriu ;) ]
Název: Re:Co si myslíte o OOP?
Přispěvatel: listoper 31. 12. 2018, 19:50:15
Tak to ale erlang taky neumi.
Jak jsi na to prisel?
Kdyz hotswapnu nejaky modul ktery ma funkci akceptujici tuple tak mi otp samo zmigruje vsechny existujici relevantni tuply ktere do ni muzou prijit?
Název: Re:Co si myslíte o OOP?
Přispěvatel: Mirek Prýmek 31. 12. 2018, 19:54:41
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.
Název: Re:Co si myslíte o OOP?
Přispěvatel: listoper 31. 12. 2018, 20:03:40
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.
Název: Re:Co si myslíte o OOP?
Přispěvatel: Mirek Prýmek 31. 12. 2018, 21:03:45
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
Název: Re:Co si myslíte o OOP?
Přispěvatel: listoper 31. 12. 2018, 21:52:31
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.
Název: Re:Co si myslíte o OOP?
Přispěvatel: Mirek Prýmek 31. 12. 2018, 23:16:09
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:

Citace
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

Citace
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áš?
Název: Re:Co si myslíte o OOP?
Přispěvatel: listoper 31. 12. 2018, 23:28:39
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.
Název: Re:Co si myslíte o OOP?
Přispěvatel: Mirek Prýmek 31. 12. 2018, 23:55:50
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 :)
Název: Re:Co si myslíte o OOP?
Přispěvatel: listoper 01. 01. 2019, 00:18:59
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.
Název: Re:Co si myslíte o OOP?
Přispěvatel: pd 01. 01. 2019, 17:09:17
Je to zlocinecka organizace a Arafat je terorista. :-)
Název: Re:Co si myslíte o OOP?
Přispěvatel: dfasdfasdf 01. 01. 2019, 17:15:49
Je to zlocinecka organizace a Arafat je terorista. :-)

to nikdo nerozporuje, spis je otazka jestli delal arafat v c++ nebo v jave???
Název: Re:co si myslite o oop?
Přispěvatel: SB 03. 01. 2019, 11:37:28
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.
Název: Re:Co si myslíte o OOP?
Přispěvatel: SB 03. 01. 2019, 11:42:41
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í.
  ;D

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ší.
Název: Re:Co si myslíte o OOP?
Přispěvatel: SB 03. 01. 2019, 13:16:03
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.
Název: Re:Co si myslíte o OOP?
Přispěvatel: SB 03. 01. 2019, 13:25:08
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 :D

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 8) 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  8)

Že něčemu nerozumíte, ještě neznamená, že je to blbost.
Název: Re:Co si myslíte o OOP?
Přispěvatel: SB 03. 01. 2019, 13:40:27
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.
Název: Re:Co si myslíte o OOP?
Přispěvatel: SB 03. 01. 2019, 13:50:11
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ě.
Název: Re:Co si myslíte o OOP?
Přispěvatel: Kit 03. 01. 2019, 13:55:45
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.

Zapouzdření nemusí být fyzické. Stačí, když programátor nepřistupuje z vnějšku k atributům instance, a to ani prostřednictvím getterů či setterů.

Python je multiparadigmatickým jazykem, neobjektové konstrukce sice působí divoce, ale jsou tam. Žádný jazyk není dokonalý. Třídní (statické?) metody nepoužívám, takže příslušné anotace ani nemusím řešit.
Název: Re:Co si myslíte o OOP?
Přispěvatel: SB 03. 01. 2019, 14:26:50
...Protoze me prijde, ze je tady jasny trend, ze od OOP, a myslim tim ted to puritanske paradigma, se ustupuje uz nekolik let jak v Jave, tak v C#. Tomu se rika stredni cesta, jestlis o tom nekdy neslysel. A dam vsadil bych se ze proto, ze se lidi sw inzenyri napric celou industry vic a vic shodli, ze to proste je takhle LEPSI. A kdyz je to takhle LEPSI, tak je to proste LEPSI.

Těžko ustupovat od (Kayova) OOP, když se vlastně nikdy ani pořádně nepoužívalo.
Tu shodu bych prosil doložit.
Co je to "industry"?
Název: Re:Co si myslíte o OOP?
Přispěvatel: Kit 03. 01. 2019, 14:46:03
...Protoze me prijde, ze je tady jasny trend, ze od OOP, a myslim tim ted to puritanske paradigma, se ustupuje uz nekolik let jak v Jave, tak v C#. Tomu se rika stredni cesta, jestlis o tom nekdy neslysel. A dam vsadil bych se ze proto, ze se lidi sw inzenyri napric celou industry vic a vic shodli, ze to proste je takhle LEPSI. A kdyz je to takhle LEPSI, tak je to proste LEPSI.
Těžko ustupovat od (Kayova) OOP, když se vlastně nikdy ani pořádně nepoužívalo.
Tu shodu bych prosil doložit.
Co je to "industry"?

To budou asi tím, že ti inženýři chtějí programovat strukturovaně v jakémkoli jazyce. To není střední cesta, ale nešikovný návrat k assembleru.

Návrhové vzory jsou v pořádku, jen si mnozí pletou jejich případy užití. Nedivím se, že pak nadávají na OOP.
Název: Re:Co si myslíte o OOP?
Přispěvatel: BoneFlute 03. 01. 2019, 17:03:11
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ě.

Kód: [Vybrat]
type Person = Person String String Int
getName (Person x _ _) = x
getSurname (Person _ x _) = x
getAge (Person _ _ x) = x
getFullname p = getName p .. " " .. getSurname p .. " (" .. getAge p .. ")"
parsePerson :: String -> Person
parsePerson s = ......

- funkce popisují změny stavu
- bez stavu nemají smysl
- jsou neoddělitelné

Jediný rozdíl je, že ten stav je vně.
Název: Re:Co si myslíte o OOP?
Přispěvatel: Kiwi 03. 01. 2019, 18:01:59
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.
Tak jinak - jak by podle tebe vypadala implementace polymorfismu tak, jak je chápán v objektovém paradigmatu, prostředky (nikoli jejich obcházením) staticky typovaného prostředí?
Název: Re:Co si myslíte o OOP?
Přispěvatel: operator 03. 01. 2019, 18:42:12
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.
Neobjektové konstrukce nejsou zbytečné, python není oop jazyk, ale hybridní. Jestli mu neco vycist, tak to, ze by default krome len(list) neumi i list.len(). Zapouzdreni ma. Proc povazujete dekoratory za nekoncepcni? Python nepouziva modifikujici klicova slova, ale obecneji fungujici a uzivatelsky nastavitelne dekorarory, coz je koncept.
Název: Re:Co si myslíte o OOP?
Přispěvatel: Kit 03. 01. 2019, 19:22:30
Funkcionální jazyky neznám, ale z toho, co jsem zatím viděl, řeší výpočet přesně opačně.
- funkce popisují změny stavu
- bez stavu nemají smysl
- jsou neoddělitelné

Jediný rozdíl je, že ten stav je vně.

- Funkce přece nepopisují změny stavu, ale transformují vstupní data na výstupní. Objekty nemusí měnit svůj stav a mnohé jsou zcela immutable.
- Funkce mají smysl i bez stavu. Co třeba sinus nebo logaritmus? Kde mají ten stav? Výstup se neukládá tam, kde dříve byl vstup, ale posílá se dál.
- V OOP jsou instance navázány na metody. U funkcí se data volně přiřazují přes parametry dle potřeby

Netvrdím, že tu není podobnost, dokonce se v OOP dá mírně inspirovat z FP, ale těch rozdílů je docela dost. Ve FP je docela kladen důraz na typování, zatímco v OOP není podstatné.
Název: Re:Co si myslíte o OOP?
Přispěvatel: Inkvizitor 03. 01. 2019, 19:38:02
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.
Tak jinak - jak by podle tebe vypadala implementace polymorfismu tak, jak je chápán v objektovém paradigmatu, prostředky (nikoli jejich obcházením) staticky typovaného prostředí?

V praxi bohatě stačí implementovat interface/trait ve všech typech, se kterými se daná operace má provádět. Bál bych se, že pozdní vazba může vést k "pozdnímu myšlení", namísto aby člověk promýšlel koncepčně, kam to celé směřuje.
Název: Re:Co si myslíte o OOP?
Přispěvatel: BoneFlute 03. 01. 2019, 21:57:21
...
Blbec jsem čekal odpověď od SB, hrozně se divil, když ta odpověď nějak přestávala dávat smysl...
Název: Re:Co si myslíte o OOP?
Přispěvatel: Kit 03. 01. 2019, 22:20:33
...
Blbec jsem čekal odpověď od SB, hrozně se divil, když ta odpověď nějak přestávala dávat smysl...

Potřebuješ, abych ti to vysvětlil nějako podrobněji? Neboj se zeptat.
Název: Re:Co si myslíte o OOP?
Přispěvatel: BoneFlute 04. 01. 2019, 03:00:14
...
Blbec jsem čekal odpověď od SB, hrozně se divil, když ta odpověď nějak přestávala dávat smysl...

Potřebuješ, abych ti to vysvětlil nějako podrobněji? Neboj se zeptat.
Jsi hodný, ale já nepotřebuju vědět všechno.
Tak možná jestli mi na to něco napíše SB, tak to si ještě přečtu.
Název: Re:Co si myslíte o OOP?
Přispěvatel: BoneFlute 04. 01. 2019, 05:16:22
Obávám se, že takto statické typování nefunguje. Všechny příklady tebou naznačného spektra možností mohu řešit. A statické typování mi bude hodně pomáhat. (A nemusím to dělat ručně.)

Zkusme být konkrétní. Bylo tu uvedeno parsování JSONu. Řešil bych to určitě staticky. Rozhodování zpracování podle typu dat? Staticky. Rozhodnování podle dat - to si nejsem jist, co myslíš. Jak se mohu rozhodovat podle dat? Čeho se mohu chytnout? Můžeš uvést příklad?
Netvrdím, že to nejde. Kdyby to nešlo, tak by většina praktických problémů byla neřešitelná staticky typovanými jazyky. Jenže to, co vnímáš jako cosi, co ti bude hodně pomáhat, já často vnímám jako klacky motající se pod nohama.
Takže něco takového jako když já po milióntý prvý pouštím celou aplikaci, a píšu druhou miliardu testů, aby to pokrylo alespoň 5procent všech možnejch chyb? :-)
Toto asi už bude o pocitech, takže to nerozebírejme. Zajímají mě tedy asi spíše nějaké racionálnější argumenty.


Rozhodování podle dat, tím myslím IF size > 5 cm THEN ...
Rozhodování podle typu, tím myslím IF (x hasMagnitude) THEN ...
Rozhodování bez ohledu na typ, tím myslím IF x > 5 THEN ..., bez ohledu na to, co to "x" je, protože mě zajímá jen odpověď na otázku, zda "to" je větší než 5.
Rozumím. Tak první bude nějaká funkce. Druhé bude pattern matching na typ. A třetí se řeší třídou/interfacem. Viz odpověď dále.

Konkrétní příklad bych vzal mnohem prostší - chceš realizovat jakýsi print(x), který zajistí vypsání argumentu na terminál. Jaký datový typ x-u by ta funkce měla podle tebe optimálně očekávat a proč? V čem mi jakožto vývojáři pomůže, že ta funkce očekává ten konkrétní datový typ? Uvažuješ-li o stringu, tak pokračuj v úvaze dál - jak se teda pak vypořádat s ne-stringy. Nebo třeba seznam v Pascalu...
typ show (v případně Javy by to bylo něco jako Printable)
Takový typ zajistí, že každá hodnota je schopná se převést na string. Včetně toho seznamu. Včetně uživatelského typu.

V Haskellu je to otázka přidání deriving show k definici typu, a všechno si odvodí sám.


Viděl jsi často, že by hostinský točil pivo do papírové krabice, přestože mu v tom nic nebrání? Jistě by šlo zařídit, aby se pípa odjistila jen v případě, že pod sebou detekuje konkrétně určený značkový půllitr. Mě by popadl rapl a ta pípa by letěla na smetiště hned v okamžiku, kdy by mi odmítala pustit pivo do džbánku.
Smysl statických typů je zajistit, aby se něco takového nestalo. Když zůstaneme u přirovnání, tak ty budeš muset hostinského zaškolit, a ještě nainstalovat kameru, aby si ho sledoval, zda nečepuje pivo přímo do pusy. A stejně ho neuhlídáš. Zatímco já tam budu moct dát cedulku "samoobslužná pípa".

Každopádně ve statickém jazyce zajistím, že ta pípa se odjistí jen v případě, kdy je do čeho načepovat. Džbánek ano, papírová krabice ne.

V případě dynamických typů ten problém máš samozřejmě taky. Ale buď ho neřešíš, a doufáš, že všechno dobře dopadne. Nebo testuješ jak blbej, a pak doufáš, že všechno dobře dopadne.


Co je na tašce na rohlíky tak provokativního? Do datového typu rohlík dám jen rohlík a seznam rohlíků není nic jiného než taška na rohlíky. V době překladu vím, že mám datový typ, do kterého můžu naskládat jedině rohlíky. Jistě, mohu vytvořit i datový typ, do něhož jdou sázet rohlíky a housky. Ale i tuto situaci musím předvídat v době překladu.
Ano, musím to předvídat v době překladu. To je jediné, v čem máš pravdu. Jinak fakt neuvažuju, tak jak popisuješ.
Kontainer na rohlíky bych dělal v případě, kdy chci jen rohlíky. Takže to bude třeba recept na jednohubky. Protože ten dělám zásadně z rohlíků.
Ale když budu brát do krámu nějakou tašku, tak bych byl idiot se omezovat takhle, ne. Budu definovat jiná omezení. Ta, která budou užitečná.


Neznám moc jazyků, které by obsahovaly "rohlík" jako jeden ze základních typů.
Taky nás nic takového nezajímá. Doba typování ala jazyk C je naštěstí už dávno pryč.

Budu-li chtít modelovat nákupní tašku, tak jako nejjednodušší případ mě napadá nějaká kolekce, třeba seznam. Ale pořád mi tu BoneFlute nevysvětlil, seznam čeho by to optimálně měl být a jakou by to mělo výhodu oproti obecné dynamicky typované kolekci.
Toho, čeho potřebuješ. To přirovnání je debilní, ale tak můžeš mít nákupní tašku na pečivo. Takže obecný typ pro pečivo. Nebo typ TuháHmota, aby si tam nečepoval to pivo. Atd.

Pak samozřejmě můžeš dojít k závěru, že nevíš, a že tam chceš dát cokoliv. Tak dáš typ *, a budeš tam moct uložit opravdu cokoliv.


Protože staticky typovaný jazyk mi říká "hele, tu informaci, co konkrétně se chystáš nakupovat, bezpodmínečně potřebuju znát dopředu", zatímco dynamicky typovaný jazyk nikoli.
Není nutné, uvádět úplně konkréntí informaci, tam kde ji nepotřebuješ vědět. S tím si typy poraděj.

Trošku bych to přeformuloval:
Statickej jazyk: "hele, čím víc mi řekneš podrobností předem, tím líp ti pomůžu".
Dynamickej jazyk: "hele, mě to nezajímá, cpi si tam co chceš, stejně si to budeš hlídat ty, já ti nepomůžu, ani mě nenapadne".


Statické typování mě nutí, abych dopředu znal nějaké omezení, nebo abych si ho uměle vytvořil, ačkoli z řešeného problému vůbec neplyne.
Nenutí, nemusíš vytvářet, pokud skutečně neplyne. Ale častokrát plyne. Statické typování dělá úplně jinou věc.


Nejčastějším problémem, se kterým se vývojář ve své pracovní době potýká, není obvykle přímo problém, který má za úkol vyřešit, ale jak se vypořádat s problémy, které si nadělal sám sobě dříve nebo které mu vymysleli jeho předchůdci. Takže jakmile se zákazník zeptá, proč nejde koupit Boeing, co mu na to odpovíš? A jak se budeš tvářit, až po X mandays práce, spočívající v překopávání půlky programu kvůli Boeingu, ti zákazník nezaplatí ani halíř, protože v té původní smlouvě o dílo není nikde napsáno, že by ten program neměl umět nakupovat Boeingy?
To zdaleka není specifické pro Statické typování. Ve skutečnosti je to tak, že:
- Ve statickém typování řešíš, jak problém popsat, a překladač ti fluše do tváře tvoje chyby.
- V dynamickém typování ti aplikace furt padá (ideálně na produkci), protože jsi nevychytal všechny chyby (nic ti nepomáhá).
V obou případech klient čeká.
Název: Re:Co si myslíte o OOP?
Přispěvatel: BoneFlute 04. 01. 2019, 05:22:02
... a nemusime type checkeru vysvetlovat nektere situace.
Tak, že nepoužití typů je jednodužší pro autora jazyka, to je tak nějak jasné. Ale tady mi tvrdí, že to má výhody pro někoho, kdo ten jazyk bude používat.
Název: Re:Co si myslíte o OOP?
Přispěvatel: BoneFlute 04. 01. 2019, 05:26:30
Většina běžného kódu tedy může být staticky otypovaná a jen v případě nouze můžu nechat kontrolu typů až na běh.
O jakém případě nouze mluvíš? Můžeš to rozvést? Nějaký příklad?
Název: Re:Co si myslíte o OOP?
Přispěvatel: BoneFlute 04. 01. 2019, 05:35:45
Aby to bylo typově korektní, tak ten $form musí být typu (Form String, Int, String, String, ...) :-P (Ale to samozřejmě nebylo pointou mého příspěvku.)

V původní ukázce jsi nic takového neuvedl, proto jsem to udělal tak jak jsem to udělal. Pokud Form bude třída, tak to bude v PHP vypadat asi takto:
Kód: [Vybrat]
function assetContactForm(Form $form, string $name, int $age, string $email, string $content) {
    $form->name = $name;
    $form->age = $age;
    $form->email = $email;
    $form->content = $content;
    return $form;
}
Vše řádně otypováno, včetně $form->name atd. Spokojen?
Tak pod pojmem řádně otypováno si představuju něco dost jiného. Dej si ještě práci, když už odvádíš téma.
Název: Re:Co si myslíte o OOP?
Přispěvatel: BoneFlute 04. 01. 2019, 05:45:09
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á.
Název: Re:Co si myslíte o OOP?
Přispěvatel: operator 04. 01. 2019, 09:11:03
Smysl statických typů je zajistit, aby se něco takového nestalo.
Smyslem statickych typu je vykonostni optimalizace.
Název: Re:Co si myslíte o OOP?
Přispěvatel: SB 04. 01. 2019, 09:16:30
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ší.
Název: Re:Co si myslíte o OOP?
Přispěvatel: SB 04. 01. 2019, 09:26:53
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.
Název: Re:Co si myslíte o OOP?
Přispěvatel: SB 04. 01. 2019, 09:38:53
...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á.
Název: Re:Co si myslíte o OOP?
Přispěvatel: Ondra Satai Nekola 04. 01. 2019, 09:48:56
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...
Název: Re:Co si myslíte o OOP?
Přispěvatel: operator 04. 01. 2019, 10:16:49
...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.
Název: Re:Co si myslíte o OOP?
Přispěvatel: BoneFlute 04. 01. 2019, 10:21:21
...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.
Název: Re:Co si myslíte o OOP?
Přispěvatel: BoneFlute 04. 01. 2019, 10:31:50
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.
Název: Re:Co si myslíte o OOP?
Přispěvatel: SB 04. 01. 2019, 10:35:06
...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.
Název: Re:Co si myslíte o OOP?
Přispěvatel: operator 04. 01. 2019, 10:36:40
...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.
Název: Re:Co si myslíte o OOP?
Přispěvatel: BoneFlute 04. 01. 2019, 10:36:59
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.)
Název: Re:Co si myslíte o OOP?
Přispěvatel: BoneFlute 04. 01. 2019, 10:44:03
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!
Název: Re:Co si myslíte o OOP?
Přispěvatel: Inkvizitor 04. 01. 2019, 10:52:19
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.
Název: Re:Co si myslíte o OOP?
Přispěvatel: operator 04. 01. 2019, 11:21:42
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.
Název: Re:Co si myslíte o OOP?
Přispěvatel: mirek 04. 01. 2019, 11:28:57
Fakt nechápu, co tu řešíte. Když vemu ten úžasný Python, tak pokud mám methodu:
Kód: [Vybrat]
def get_record(self, data):
Tak co ta metoda vrací? A co jí mám poslat? Fakt někdo chce takový jazyk používat na víc než na hraní a skriptíky?
Název: Re:Co si myslíte o OOP?
Přispěvatel: JS 04. 01. 2019, 11:30:39
Funkcionální jazyky neznám, ale z toho, co jsem zatím viděl, řeší výpočet přesně opačně.
- funkce popisují změny stavu
- bez stavu nemají smysl
- jsou neoddělitelné

Jediný rozdíl je, že ten stav je vně.

- Funkce přece nepopisují změny stavu, ale transformují vstupní data na výstupní. Objekty nemusí měnit svůj stav a mnohé jsou zcela immutable.
- Funkce mají smysl i bez stavu. Co třeba sinus nebo logaritmus? Kde mají ten stav? Výstup se neukládá tam, kde dříve byl vstup, ale posílá se dál.
- V OOP jsou instance navázány na metody. U funkcí se data volně přiřazují přes parametry dle potřeby

Netvrdím, že tu není podobnost, dokonce se v OOP dá mírně inspirovat z FP, ale těch rozdílů je docela dost. Ve FP je docela kladen důraz na typování, zatímco v OOP není podstatné.

Moc nechapu, co tu resite. OOP a FP jsou dualni - je mozne z jednoho udelat druhe pomoci IoC. (Ale fakt je, ze me ten FP pristup prijde prehlednejsi. Je to vec vkusu.) S typovanim FP az tak moc nesouvisi - prvni FP jazyk - lambda kalkul - byl beztypovy (ale take v dusledku toho nebyl silne normalizujici, coz je.. neprijemne).
Název: Re:Co si myslíte o OOP?
Přispěvatel: rumcajz 04. 01. 2019, 11:31:35
Python je srackoidny jazyk. Na C# sa nechyta
Název: Re:Co si myslíte o OOP?
Přispěvatel: JS 04. 01. 2019, 11:34:03
... a nemusime type checkeru vysvetlovat nektere situace.
Tak, že nepoužití typů je jednodužší pro autora jazyka, to je tak nějak jasné. Ale tady mi tvrdí, že to má výhody pro někoho, kdo ten jazyk bude používat.

V tom co jsem psal jsem mel na mysli programatora. Napriklad nemusim type checkeru v Haskellu vysvetlovat, ze zadany retezcovy literal ma byt typu Text a nikoli typu String. (A o existenci OverloadedStrings vim, jde o obecny problem.)
Název: Re:Co si myslíte o OOP?
Přispěvatel: JS 04. 01. 2019, 11:35:41
Smysl statických typů je zajistit, aby se něco takového nestalo.
Smyslem statickych typu je vykonostni optimalizace.

Smyslem je oboji a jeste jedna vec navic - staticky dispatch na zaklade typu. Typy maji v programovani tri funkce - kontrolu parametru, volbu datove struktury, a dispatch.
Název: Re:Co si myslíte o OOP?
Přispěvatel: anonym 04. 01. 2019, 11:38:50
Hosi to je hrozne tohleto, to je zumpa toto...
Název: Re:Co si myslíte o OOP?
Přispěvatel: SB 04. 01. 2019, 12:28:34
V JVM, co jsem se dočetl, hot reloading jde, ale nemůžeš měnit signatury ani odstraňovat nebo přidávat metody. Takže vlastně můžeš jenom měnit implementaci existujících věcí.

A to je právě jedním z důsledků toho, že Java nemá zasílání zpráv, ale volání funkcí.
Název: Re:Co si myslíte o OOP?
Přispěvatel: rumcajz 04. 01. 2019, 12:41:08
Hosi, co tak ist dokoncit si strednu skolu?
Název: Re:Co si myslíte o OOP?
Přispěvatel: uetoyo 04. 01. 2019, 12:45:52
Fakt nechápu, co tu řešíte. Když vemu ten úžasný Python, tak pokud mám methodu:
Kód: [Vybrat]
def get_record(self, data):
Tak co ta metoda vrací? A co jí mám poslat? Fakt někdo chce takový jazyk používat na víc než na hraní a skriptíky?

Tak za prvé by měla mít metoda dokumentační komentář a za druhé se dají přidat typy do signatury. https://docs.python.org/3/library/typing.html

Název: Re:Co si myslíte o OOP?
Přispěvatel: mirek 04. 01. 2019, 12:55:43
Fakt nechápu, co tu řešíte. Když vemu ten úžasný Python, tak pokud mám methodu:
Kód: [Vybrat]
def get_record(self, data):
Tak co ta metoda vrací? A co jí mám poslat? Fakt někdo chce takový jazyk používat na víc než na hraní a skriptíky?

Tak za prvé by měla mít metoda dokumentační komentář a za druhé se dají přidat typy do signatury. https://docs.python.org/3/library/typing.html

Proč by ho měla mít? Když se dobře jmenuje, tak přesně víš, co dělá. Může ho mít, ale nevím, proč bych do něj měl dávat typ?

A proč bych je tam přidával, když tu všichni píšou, že nejsou potřeba?

Jen mě to zajímá, fakt do toho nechci rýt. Dynamické typování zřejmě žádné výhody nemá a celé tohle vlákno to akorát potvrzuje. Takže bych rád věděl, jak to funguje a jak právě dynamičtí programátoři přemýšlí a jak fungují. Třeba bych tomu přišel na chuť taky. Pokud ale nevím, co posílat za typy, tak bohužel v tom dělat neumím.
Název: Re:Co si myslíte o OOP?
Přispěvatel: SB 04. 01. 2019, 13:19:15
Ale ať nad tím dumám jak dumám, tak mi vychází, že dynamické typování je znouzecnost. Nemá žádné benefity. Pletu se?
Se zkvalitněním inference výhody trochu ubývají. Ale pár bys jich našel. Například když potřebuješ někde na zkoušku nějaký typ změnit, může ti probublat do spousty kódu, takže to musíš změnit i na spoustě mít, který vůbec spouštět nechceš. Je to podobný jako s IO v Haskellu - nemůžeš si někam jenom tak narychlo dát nějaký debug výpis...

Nebo jinak: Kotím javový kód. Mám 5 věcí rozdělaných (např. v TDD standard), ale dokud to nebudu mít alespoň formálně (tedy i typově, což samo o sobě nestačí) správně, tak to nepřeložím. Takže to nějak ojebu (doplním kraviny, pozakomentuju - krásný příklad na situaci, kdy kód funguje špatně, ale překladem prošel, takže jej někteří považují za správný!), abych mohl vyzkoušet TU JEDNU VĚC, co jsem potřeboval.
Název: Re:Co si myslíte o OOP?
Přispěvatel: v 04. 01. 2019, 13:22:06
jako obvykle si každý představuje pod pojmem "typ" něco trochu (nebo i hodně) jiného
tenhle to hezky shrnul: http://tomasp.net/blog/2015/against-types/
Název: Re:Co si myslíte o OOP?
Přispěvatel: SB 04. 01. 2019, 13:26:43
No tak to z chybného předpokladu vyvozuješ chybný závěr, no, co na to říct jiného? REPL máš třeba v pythonu a code reloading tam dělat nejde (AFAIK). Existující kód prostě běží dál, změny se projeví jenom v nově nataženém.
Uz je to davno co sem delal s pythonem. Ale melo by to jit.

V PyCharmu před necelým rokem mi to nešlo (přestože bych to fakt docenil). Proč nevím.
Název: Re:Co si myslíte o OOP?
Přispěvatel: Kit 04. 01. 2019, 13:30:29
Fakt nechápu, co tu řešíte. Když vemu ten úžasný Python, tak pokud mám methodu:
Kód: [Vybrat]
def get_record(self, data):Tak co ta metoda vrací? A co jí mám poslat? Fakt někdo chce takový jazyk používat na víc než na hraní a skriptíky?
Tak za prvé by měla mít metoda dokumentační komentář a za druhé se dají přidat typy do signatury. https://docs.python.org/3/library/typing.html
Proč by ho měla mít? Když se dobře jmenuje, tak přesně víš, co dělá. Může ho mít, ale nevím, proč bych do něj měl dávat typ?

A proč bych je tam přidával, když tu všichni píšou, že nejsou potřeba?

Jen mě to zajímá, fakt do toho nechci rýt. Dynamické typování zřejmě žádné výhody nemá a celé tohle vlákno to akorát potvrzuje. Takže bych rád věděl, jak to funguje a jak právě dynamičtí programátoři přemýšlí a jak fungují. Třeba bych tomu přišel na chuť taky. Pokud ale nevím, co posílat za typy, tak bohužel v tom dělat neumím.

Té metodě pošleš data a vrátí record. Jak prosté, typy ani signatury k tomu nejsou potřebné.

Celé toto vlákno je o tom, že statické typování nemá žádné výhody proti dynamickému - snad jen výkonnostní. Pokud opravdu potřebuji výkon, použiji Fortan, kde ty statické typy mám.
Název: Re:Co si myslíte o OOP?
Přispěvatel: Ondra Satai Nekola 04. 01. 2019, 13:45:14
Fakt nechápu, co tu řešíte. Když vemu ten úžasný Python, tak pokud mám methodu:
Kód: [Vybrat]
def get_record(self, data):Tak co ta metoda vrací? A co jí mám poslat? Fakt někdo chce takový jazyk používat na víc než na hraní a skriptíky?
Tak za prvé by měla mít metoda dokumentační komentář a za druhé se dají přidat typy do signatury. https://docs.python.org/3/library/typing.html
Proč by ho měla mít? Když se dobře jmenuje, tak přesně víš, co dělá. Může ho mít, ale nevím, proč bych do něj měl dávat typ?

A proč bych je tam přidával, když tu všichni píšou, že nejsou potřeba?

Jen mě to zajímá, fakt do toho nechci rýt. Dynamické typování zřejmě žádné výhody nemá a celé tohle vlákno to akorát potvrzuje. Takže bych rád věděl, jak to funguje a jak právě dynamičtí programátoři přemýšlí a jak fungují. Třeba bych tomu přišel na chuť taky. Pokud ale nevím, co posílat za typy, tak bohužel v tom dělat neumím.

Té metodě pošleš data a vrátí record. Jak prosté, typy ani signatury k tomu nejsou potřebné.

Celé toto vlákno je o tom, že statické typování nemá žádné výhody proti dynamickému - snad jen výkonnostní. Pokud opravdu potřebuji výkon, použiji Fortan, kde ty statické typy mám.

Jenom vykonost. A bezpecnost. A moznost refaktorovat s podporou nastroju. A lepsi code completion. A snazsi TDD.

Co vlastne nam ti Rimane prinesli?
Název: Re:Co si myslíte o OOP?
Přispěvatel: SB 04. 01. 2019, 14:05:31
To, ze stare objekty (vytvorene podle predchozi verze kodu) zustanou nezmenene je snad v poradku ne?
Ne. To je to, co ti porad nedochazi. Podstata je ve vymene stareho za nove ne ve vytvoreni noveho. To druhé Python umí (a umí to jakýkoliv jazyk s REPL), to první ne.

Nevím, zda si rozumíte:
Jestliže ve Smalltalku přepíšu za běhu (Smalltalk má běh pořád) metodu, všechny instance dané třídy, přestože se nijak nezměnily, budou používat novou metodu, protože nositelem metod objektu je zde třída (způsob implementace metod). Když v Javascriptu změním kód, který generuje objekty včetně metod (bez "prototypování", ad-hoc), pak samozřejmě nové chování budou mít až ty nové objekty.
Název: Re:Co si myslíte o OOP?
Přispěvatel: BaldSlattery 04. 01. 2019, 14:14:07
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.
Staticke typy zvysuji miru slozitosti programu, tedy jeho nachylnost k chybam.
Kandidát na nejdebilnější hlášku desetiletí.
Název: Re:Co si myslíte o OOP?
Přispěvatel: Kit 04. 01. 2019, 14:23:36
Celé toto vlákno je o tom, že statické typování nemá žádné výhody proti dynamickému - snad jen výkonnostní. Pokud opravdu potřebuji výkon, použiji Fortan, kde ty statické typy mám.
Jenom vykonost. A bezpecnost. A moznost refaktorovat s podporou nastroju. A lepsi code completion. A snazsi TDD.

- Bezpečnost? To je jen iluze, která není ničím podložena.
- Možnost refaktorovat je stejná. Nevidím výhodu statického typování.
- Lepší code completion je jen dáno konkrétním použitým IDE. Ve Vimu je to jedno, tam vítězí dynamické typování.

Dynamicky typovaný jazyk se lépe čte, vlastně ke čtení ty typy ani nepotřebuji. Hodí se do hlavičky metod a funkcí - tam je dávám, protože programuji proti rozhraní, které je vyžaduje.
Název: Re:Co si myslíte o OOP?
Přispěvatel: SB 04. 01. 2019, 14:25:43
Zapouzdření nemusí být fyzické. Stačí, když programátor nepřistupuje z vnějšku k atributům instance, a to ani prostřednictvím getterů či setterů.

Zapouzdření je nezávislé na programátorovi. Nemíním tu rozjíždět flamevár, už se to tu řešilo. Já uznávám pouze Kayovo OOP, a ten v tom má jasno.

Python je multiparadigmatickým jazykem, neobjektové konstrukce sice působí divoce, ale jsou tam. Žádný jazyk není dokonalý. Třídní (statické?) metody nepoužívám, takže příslušné anotace ani nemusím řešit.

Multiparadigmatismus by nevadil, kdyby byl přínosem. Jestliže zde lze plnohodnotně operaci nahradit zasláním zprávy objektu, je zde imperativní paradigma navíc, což samo o sobě vůbec není zadarmo - vyžaduje mimo implementace paradigmatu i implementaci spolupráce paradigmat, což samo o sobě komplikuje jazyk => porušení KISS.

Asi není, ale proč vyrábět další poprasený jazyk a spálit se znovu?

Třídní metody mají svoje rozsáhlé užití, proto by jejich implementace měla nějak vypadat. (Pozor, třídní a statický jsou 2 různé věci bastardizací OOP považované za jedno.)
Název: Re:Co si myslíte o OOP?
Přispěvatel: operator 04. 01. 2019, 14:29:56
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.
Jako stary pythonista bys mel vedet, ze python konstanty nema.  Kdyz mas dve sady cisel a nechces aby doslo k jejich zamene, staci si je otypovat. To slo delat vzdy a enum v pythonu nedela nic jineho, je to jen preddefinovana trida za timto ucelem. Staticke typy k tomu nepotrebujes a testy ti to odhali, kdyz budou dobre, take muzes pouzit typing.

Delas tu chybu, ze si pletes obecne typy a staticke typy. Typy aby plnily svou kontrolni funkci nemusi byt staticke a ani to neni zadouci, je to omezujici a dela to program slozitejsi, rozumej nachylnejsi k chybam. Jedine plus pro staticke typy je vyssi vykon, zaplaceny vyssi slozitosti. Jazyky typu C maji slabe typovani, tvrditvze to je spatne je velmi odvazne, ale je to hezky doklad toho, ze _staticke_ typovani ma jiny ucel. Doslo by ti to rychleji, kdyby ses nasnazil mavnout rukou nad tim, proc vubec staticke typy vznikly, tento duvod nepominul. Pak bys jim neprisuzoval ucel, ktery nemaji.

Název: Re:Co si myslíte o OOP?
Přispěvatel: Ondra Satai Nekola 04. 01. 2019, 14:36:38
- Bezpečnost? To je jen iluze, která není ničím podložena.
- Možnost refaktorovat je stejná. Nevidím výhodu statického typování.
- Lepší code completion je jen dáno konkrétním použitým IDE. Ve Vimu je to jedno, tam vítězí dynamické typování.

Dynamicky typovaný jazyk se lépe čte, vlastně ke čtení ty typy ani nepotřebuji. Hodí se do hlavičky metod a funkcí - tam je dávám, protože programuji proti rozhraní, které je vyžaduje.

Ze nepouzivas IDE je ciste tvuj problem. Rozdil je v tom, ze IDE se statickym typovanim moznost ma, bez ne.

Bezpecnost samozrejme neni zadna iluze. Neni stoprocentni, ale pomerne dost chyb se proste udelat neda (nebo jen za cenu urciteho na prvni pohled patrneho nasili)

Refaktoring meles porad dokola a porad spatne. Mas-li dve metody stejneho jmena v ruznych hierarchiich, tak bez statickeho typovani neudelas rename jen jedne z nich. Trivialni priklad. Ze jsi v refaktorovani skoncil u regexpu je opet jen tva omezenost.
Název: Re:Co si myslíte o OOP?
Přispěvatel: operator 04. 01. 2019, 14:44:02
Fakt nechápu, co tu řešíte. Když vemu ten úžasný Python, tak pokud mám methodu:
Kód: [Vybrat]
def get_record(self, data):
Tak co ta metoda vrací? A co jí mám poslat? Fakt někdo chce takový jazyk používat na víc než na hraní a skriptíky?

To je prece popsane v dokumentaci k te funkci. Samotna znalost typu te k pochopeni funkce a jak ji pouzivat nepriblizuje nijak vic. I kdybys vedel, ze int je cislo, porad bez dokumentace nevis jake cislo a co znamena.  Ano, dynamicke jazyky se pouzivaji na vic veci, nez hrani se skriptiky.
Název: Re:Co si myslíte o OOP?
Přispěvatel: Ondra Satai Nekola 04. 01. 2019, 14:46:55
Fakt nechápu, co tu řešíte. Když vemu ten úžasný Python, tak pokud mám methodu:
Kód: [Vybrat]
def get_record(self, data):
Tak co ta metoda vrací? A co jí mám poslat? Fakt někdo chce takový jazyk používat na víc než na hraní a skriptíky?

To je prece popsane v dokumentaci k te funkci. Samotna znalost typu te k pochopeni funkce a jak ji pouzivat nepriblizuje nijak vic. I kdybys vedel, ze int je cislo, porad bez dokumentace nevis jake cislo a co znamena.  Ano, dynamicke jazyky se pouzivaji na vic veci, nez hrani se skriptiky.

Teoreticky. Prakticky treba kdyz mas getXs(), tak podle typu vis, zda mohou byt xka duplicitni (list vs. set).
Název: Re:Co si myslíte o OOP?
Přispěvatel: Inkvizitor 04. 01. 2019, 14:52:33
Jako stary pythonista bys mel vedet, ze python konstanty nema.  Kdyz mas dve sady cisel a nechces aby doslo k jejich zamene, staci si je otypovat. To slo delat vzdy a enum v pythonu nedela nic jineho, je to jen preddefinovana trida za timto ucelem. Staticke typy k tomu nepotrebujes a testy ti to odhali, kdyz budou dobre, take muzes pouzit typing.

Delas tu chybu, ze si pletes obecne typy a staticke typy. Typy aby plnily svou kontrolni funkci nemusi byt staticke a ani to neni zadouci, je to omezujici a dela to program slozitejsi, rozumej nachylnejsi k chybam. Jedine plus pro staticke typy je vyssi vykon, zaplaceny vyssi slozitosti. Jazyky typu C maji slabe typovani, tvrditvze to je spatne je velmi odvazne, ale je to hezky doklad toho, ze _staticke_ typovani ma jiny ucel. Doslo by ti to rychleji, kdyby ses nasnazil mavnout rukou nad tim, proc vubec staticke typy vznikly, tento duvod nepominul. Pak bys jim neprisuzoval ucel, ktery nemaji.

Je to marný, s Tebou se nedomluvím. Od zítřka kamarádím s Kitem.
Název: Re:Co si myslíte o OOP?
Přispěvatel: BoneFlute 04. 01. 2019, 15:03:58
... a nemusime type checkeru vysvetlovat nektere situace.
Tak, že nepoužití typů je jednodužší pro autora jazyka, to je tak nějak jasné. Ale tady mi tvrdí, že to má výhody pro někoho, kdo ten jazyk bude používat.

V tom co jsem psal jsem mel na mysli programatora. Napriklad nemusim type checkeru v Haskellu vysvetlovat, ze zadany retezcovy literal ma byt typu Text a nikoli typu String. (A o existenci OverloadedStrings vim, jde o obecny problem.)
To beru.
Název: Re:Co si myslíte o OOP?
Přispěvatel: BoneFlute 04. 01. 2019, 15:06:03
Ale ať nad tím dumám jak dumám, tak mi vychází, že dynamické typování je znouzecnost. Nemá žádné benefity. Pletu se?
Se zkvalitněním inference výhody trochu ubývají. Ale pár bys jich našel. Například když potřebuješ někde na zkoušku nějaký typ změnit, může ti probublat do spousty kódu, takže to musíš změnit i na spoustě mít, který vůbec spouštět nechceš. Je to podobný jako s IO v Haskellu - nemůžeš si někam jenom tak narychlo dát nějaký debug výpis...

Nebo jinak: Kotím javový kód. Mám 5 věcí rozdělaných (např. v TDD standard), ale dokud to nebudu mít alespoň formálně (tedy i typově, což samo o sobě nestačí) správně, tak to nepřeložím. Takže to nějak ojebu (doplním kraviny, pozakomentuju - krásný příklad na situaci, kdy kód funguje špatně, ale překladem prošel, takže jej někteří považují za správný!), abych mohl vyzkoušet TU JEDNU VĚC, co jsem potřeboval.
Ale jo, to už tu bylo. Dokonce jsem to uváděl jako jeden ze scénářů, kdy je dynamické typování lepší HNED V OTÁZCE.
Název: Re:Co si myslíte o OOP?
Přispěvatel: operator 04. 01. 2019, 15:08:18
Fakt nechápu, co tu řešíte. Když vemu ten úžasný Python, tak pokud mám methodu:
Kód: [Vybrat]
def get_record(self, data):
Tak co ta metoda vrací? A co jí mám poslat? Fakt někdo chce takový jazyk používat na víc než na hraní a skriptíky?

Tak za prvé by měla mít metoda dokumentační komentář a za druhé se dají přidat typy do signatury. https://docs.python.org/3/library/typing.html

Proč by ho měla mít? Když se dobře jmenuje, tak přesně víš, co dělá. Může ho mít, ale nevím, proč bych do něj měl dávat typ?

A proč bych je tam přidával, když tu všichni píšou, že nejsou potřeba?

Jen mě to zajímá, fakt do toho nechci rýt. Dynamické typování zřejmě žádné výhody nemá a celé tohle vlákno to akorát potvrzuje. Takže bych rád věděl, jak to funguje a jak právě dynamičtí programátoři přemýšlí a jak fungují. Třeba bych tomu přišel na chuť taky. Pokud ale nevím, co posílat za typy, tak bohužel v tom dělat neumím.
V pythonu se z dokumentacnich retezcu mj. generuje dokumentace. Tva otazka tedy je, proc by mel byt program zdokumentovany. Tato dokumentace je primou soucasti programu/knihovny.

Ten typ tam muzes dat, kdyz ti to prijde vyhodne a nemusis, kdyz to je nepotreba nebo to naopak program komplikuje. Je to moznost, nikoliv povinnost. Ja je nepouzivam, ale pokud ma nekdo pocit, ze diky tomu bude mit lepsi program, tak tu moznost ma.

Dynamicke typovani vyhodu ma, je jednodussi, flexíbilnejsi a srozumitelnejsi. Staticke typovani je vlastne docela hloupe a neprirozene, je umele. Principialni rozdil mezi statickym a dynamickym typovanim je v tom, kdo nese informaci o typu, zda promenna nebo hodnota.
Název: Re:Co si myslíte o OOP?
Přispěvatel: BoneFlute 04. 01. 2019, 15:08:40
Je to marný, s Tebou se nedomluvím. Od zítřka kamarádím s Kitem.
Si pomůžeš? :-P
Název: Re:Co si myslíte o OOP?
Přispěvatel: JS 04. 01. 2019, 15:19:11
jako obvykle si každý představuje pod pojmem "typ" něco trochu (nebo i hodně) jiného
tenhle to hezky shrnul: http://tomasp.net/blog/2015/against-types/

To ovsem neni nic tak neobvykleho, ze pojem "typ" ma v programovani jiny vyznam nez v matematice. Treba pojem "funkce" ma v programovani take jiny vyznam.

Funkcionalni programovani se prave obecne snazi obe discipliny priblizit a tedy tam se snazi oba pojmy pouzivat primarne v matematickem vyznamu (coz je uzsi a formalnejsi). Ale obecne v programovani to ten vyznam, bohuzel historicky, nema.
Název: Re:Co si myslíte o OOP?
Přispěvatel: Inkvizitor 04. 01. 2019, 15:41:04
Je to marný, s Tebou se nedomluvím. Od zítřka kamarádím s Kitem.
Si pomůžeš? :-P

Jak řekl klasik, všechno je relativní.
Název: Re:Co si myslíte o OOP?
Přispěvatel: v 04. 01. 2019, 15:41:22
jako obvykle si každý představuje pod pojmem "typ" něco trochu (nebo i hodně) jiného
tenhle to hezky shrnul: http://tomasp.net/blog/2015/against-types/

To ovsem neni nic tak neobvykleho, ze pojem "typ" ma v programovani jiny vyznam nez v matematice. Treba pojem "funkce" ma v programovani take jiny vyznam.

Funkcionalni programovani se prave obecne snazi obe discipliny priblizit a tedy tam se snazi oba pojmy pouzivat primarne v matematickem vyznamu (coz je uzsi a formalnejsi). Ale obecne v programovani to ten vyznam, bohuzel historicky, nema.
neobvyklé to třeba není, ale tady půlka lidí debatuje o pascalu a druhá o teorii typů a to mi přijde takové nahovno
Název: Re:Co si myslíte o OOP?
Přispěvatel: JS 04. 01. 2019, 15:43:41
Dynamicke typovani vyhodu ma, je jednodussi, flexíbilnejsi a srozumitelnejsi. Staticke typovani je vlastne docela hloupe a neprirozene, je umele. Principialni rozdil mezi statickym a dynamickym typovanim je v tom, kdo nese informaci o typu, zda promenna nebo hodnota.

To neni tak docela pravda. Napriklad Haskell nema promenne, jen hodnoty; pritom je staticky typovany. Na druhou stranu, treba Java ma promenne, ale nektere hodnoty (objekty) si drzi informaci o svem typu.

Rozdil je skutecne v tom, zda se typy kontroluji pri prekladu nebo az pri behu programu. A to druhe obvykle znamena nejakou ztratu vykonu a vyssi spotrebu pameti.
Název: Re:Co si myslíte o OOP?
Přispěvatel: uetoyo 04. 01. 2019, 15:48:04
Fakt nechápu, co tu řešíte. Když vemu ten úžasný Python, tak pokud mám methodu:
Kód: [Vybrat]
def get_record(self, data):
Tak co ta metoda vrací? A co jí mám poslat? Fakt někdo chce takový jazyk používat na víc než na hraní a skriptíky?

Tak za prvé by měla mít metoda dokumentační komentář a za druhé se dají přidat typy do signatury. https://docs.python.org/3/library/typing.html

Proč by ho měla mít? Když se dobře jmenuje, tak přesně víš, co dělá. Může ho mít, ale nevím, proč bych do něj měl dávat typ?

A proč bych je tam přidával, když tu všichni píšou, že nejsou potřeba?

Jen mě to zajímá, fakt do toho nechci rýt. Dynamické typování zřejmě žádné výhody nemá a celé tohle vlákno to akorát potvrzuje. Takže bych rád věděl, jak to funguje a jak právě dynamičtí programátoři přemýšlí a jak fungují. Třeba bych tomu přišel na chuť taky. Pokud ale nevím, co posílat za typy, tak bohužel v tom dělat neumím.

a) Dokumentaci by měla mít, aby se zní  dala generovat dokumentace, to se snad dělá i v jiných jazycích ne? Jinak v Pythonu se tam slušně strká i "typ". To už před tím než se zavedli type-hints.

b) Vytváříš falešnou představu že když někdo dělá v třeba v Pythonu je to milovník dynamického typování :), to ani ne, ale  kolem toho co mě baví je Python komunita, takže asi tak.

c) Ideální jazyk pro mne by byl něco jako OCaml, ale bohužel už jsou zavedený knihovny Pandas, Numpy, Scipy -- tohle se těžko nahrazuje.

Samozřejmě na Pythonu je blbý, že jako začátěčník ti dovolí všechno, blbě se refaktoruje atd.
Název: Re:Co si myslíte o OOP?
Přispěvatel: operator 04. 01. 2019, 15:48:18
Fakt nechápu, co tu řešíte. Když vemu ten úžasný Python, tak pokud mám methodu:
Kód: [Vybrat]
def get_record(self, data):
Tak co ta metoda vrací? A co jí mám poslat? Fakt někdo chce takový jazyk používat na víc než na hraní a skriptíky?

To je prece popsane v dokumentaci k te funkci. Samotna znalost typu te k pochopeni funkce a jak ji pouzivat nepriblizuje nijak vic. I kdybys vedel, ze int je cislo, porad bez dokumentace nevis jake cislo a co znamena.  Ano, dynamicke jazyky se pouzivaji na vic veci, nez hrani se skriptiky.

Teoreticky. Prakticky treba kdyz mas getXs(), tak podle typu vis, zda mohou byt xka duplicitni (list vs. set).
V prvni rade to vim z dokumentace, v druhe rade k tomu opravdu nepotrebuji staticke typy.
Název: Re:Co si myslíte o OOP?
Přispěvatel: BoneFlute 04. 01. 2019, 15:52:25
neobvyklé to třeba není, ale tady půlka lidí debatuje o pascalu a druhá o teorii typů a to mi přijde takové nahovno
Pravdu máš soudruhu. A přitom ta moje otázka vypadala celkem jednoduše.
Název: Re:Co si myslíte o OOP?
Přispěvatel: Ondra Satai Nekola 04. 01. 2019, 15:52:51
Fakt nechápu, co tu řešíte. Když vemu ten úžasný Python, tak pokud mám methodu:
Kód: [Vybrat]
def get_record(self, data):
Tak co ta metoda vrací? A co jí mám poslat? Fakt někdo chce takový jazyk používat na víc než na hraní a skriptíky?

To je prece popsane v dokumentaci k te funkci. Samotna znalost typu te k pochopeni funkce a jak ji pouzivat nepriblizuje nijak vic. I kdybys vedel, ze int je cislo, porad bez dokumentace nevis jake cislo a co znamena.  Ano, dynamicke jazyky se pouzivaji na vic veci, nez hrani se skriptiky.

Teoreticky. Prakticky treba kdyz mas getXs(), tak podle typu vis, zda mohou byt xka duplicitni (list vs. set).
V prvni rade to vim z dokumentace, v druhe rade k tomu opravdu nepotrebuji staticke typy.

Nepotrebujes, pomahaji. A to i pokud se bavime o ridke situaci, kdy dokumentace je 100%.
Název: Re:Co si myslíte o OOP?
Přispěvatel: SB 04. 01. 2019, 15:54:04
Kód: [Vybrat]
type Person = Person String String Int
getName (Person x _ _) = x
getSurname (Person _ x _) = x
getAge (Person _ _ x) = x
getFullname p = getName p .. " " .. getSurname p .. " (" .. getAge p .. ")"
parsePerson :: String -> Person
parsePerson s = ......

Na uvedeném kódu nejen že nevidím nic objektového, ale dokonce ani výhradně funkcionálního, to je v podstatě imperativní programování.

Jediný rozdíl je, že ten stav je vně.

Nebo ty funkce jsou vně? Jak potom dosáhnete konzistenci (u složitějších modelů, ne tohoto triviálního případu), když si každý kdekoliv může vyrobit funkci, která přepíše v "stavu" cokoliv zvenku?

P. S.: Opravdu se jednotlivé položky struktury odkazují tak neobratně a nepřehledně pozicí?!
Název: Re:Co si myslíte o OOP?
Přispěvatel: operator 04. 01. 2019, 15:56:49
Fakt nechápu, co tu řešíte. Když vemu ten úžasný Python, tak pokud mám methodu:
Kód: [Vybrat]
def get_record(self, data):
Tak co ta metoda vrací? A co jí mám poslat? Fakt někdo chce takový jazyk používat na víc než na hraní a skriptíky?

Tak za prvé by měla mít metoda dokumentační komentář a za druhé se dají přidat typy do signatury. https://docs.python.org/3/library/typing.html

Proč by ho měla mít? Když se dobře jmenuje, tak přesně víš, co dělá. Může ho mít, ale nevím, proč bych do něj měl dávat typ?

A proč bych je tam přidával, když tu všichni píšou, že nejsou potřeba?

Jen mě to zajímá, fakt do toho nechci rýt. Dynamické typování zřejmě žádné výhody nemá a celé tohle vlákno to akorát potvrzuje. Takže bych rád věděl, jak to funguje a jak právě dynamičtí programátoři přemýšlí a jak fungují. Třeba bych tomu přišel na chuť taky. Pokud ale nevím, co posílat za typy, tak bohužel v tom dělat neumím.

a) Dokumentaci by měla mít, aby se zní  dala generovat dokumentace, to se snad dělá i v jiných jazycích ne? Jinak v Pythonu se tam slušně strká i "typ". To už před tím než se zavedli type-hints.

b) Vytváříš falešnou představu že když někdo dělá v třeba v Pythonu je to milovník dynamického typování :), to ani ne, ale  kolem toho co mě baví je Python komunita, takže asi tak.

c) Ideální jazyk pro mne by byl něco jako OCaml, ale bohužel už jsou zavedený knihovny Pandas, Numpy, Scipy -- tohle se těžko nahrazuje.

Samozřejmě na Pythonu je blbý, že jako začátěčník ti dovolí všechno, blbě se refaktoruje atd.
Jo, dokumentaci by mel mit kazdy jazyk, byt ne u kazdeho je soucasti jazyka. Kazdopadne by se dokumentace nemela nahrazovat statickymi typy.
Zadnou takovou predstavu nevytvarim, python pouziva kde kdo, dobri i spatni programatori, dokonce i laici. Ale neni to o pythonu, dominantne rozsirenych dynamickych jazyku je tady vic a jejich vyznam narusta.
Název: Re:Co si myslíte o OOP?
Přispěvatel: BoneFlute 04. 01. 2019, 16:06:24
Nebo ty funkce jsou vně? Jak potom dosáhnete konzistenci (u složitějších modelů, ne tohoto triviálního případu), když si každý kdekoliv může vyrobit funkci, která přepíše v "stavu" cokoliv zvenku?
Ve FP nemůžeš přepsat stav. A v Haskellu nemůže kdokoliv vyrobit funkci - hlídaj to typy a moduly. Ale to už je jinej příběh.


P. S.: Opravdu se jednotlivé položky struktury odkazují tak neobratně a nepřehledně pozicí?!
Tak, na struktury jsou spíše zkratky, já to z demostrativních důvodů rozepsal. Ale jinak ano, a je to velice šikovné a dobře se na to zvyká.
Název: Re:Co si myslíte o OOP?
Přispěvatel: operator 04. 01. 2019, 16:21:01
Fakt nechápu, co tu řešíte. Když vemu ten úžasný Python, tak pokud mám methodu:
Kód: [Vybrat]
def get_record(self, data):Tak co ta metoda vrací? A co jí mám poslat? Fakt někdo chce takový jazyk používat na víc než na hraní a skriptíky?
To je prece popsane v dokumentaci k te funkci. Samotna znalost typu te k pochopeni funkce a jak ji pouzivat nepriblizuje nijak vic. I kdybys vedel, ze int je cislo, porad bez dokumentace nevis jake cislo a co znamena.  Ano, dynamicke jazyky se pouzivaji na vic veci, nez hrani se skriptiky.
Teoreticky. Prakticky treba kdyz mas getXs(), tak podle typu vis, zda mohou byt xka duplicitni (list vs. set).
V prvni rade to vim z dokumentace, v druhe rade k tomu opravdu nepotrebuji staticke typy.
Nepotrebujes, pomahaji. A to i pokud se bavime o ridke situaci, kdy dokumentace je 100%.
To je cira z nouze ctnost.
Název: Re:Co si myslíte o OOP?
Přispěvatel: operator 04. 01. 2019, 16:37:06
Dynamicke typovani vyhodu ma, je jednodussi, flexíbilnejsi a srozumitelnejsi. Staticke typovani je vlastne docela hloupe a neprirozene, je umele. Principialni rozdil mezi statickym a dynamickym typovanim je v tom, kdo nese informaci o typu, zda promenna nebo hodnota.

To neni tak docela pravda. Napriklad Haskell nema promenne, jen hodnoty; pritom je staticky typovany. Na druhou stranu, treba Java ma promenne, ale nektere hodnoty (objekty) si drzi informaci o svem typu.

Rozdil je skutecne v tom, zda se typy kontroluji pri prekladu nebo az pri behu programu. A to druhe obvykle znamena nejakou ztratu vykonu a vyssi spotrebu pameti.

takze kdyz v haskellu napisu
Kód: [Vybrat]
dabl x = x + x
Co je to to 'x' a je datoveho typu double nebo int?

Je otazka, zda objekt je opravdu hodnota, ale dobre, opravuji formulaci na 'kde i informace o jednoduchem datovem typu je soucasti hodnoty.

Takze kdyz v pythonu, php a pod vyuziji type hinting, a datove typy zkontroluji pri prekladu, udelal jsem z nej staticky typovany jazyk? Myslim ze ne a to prave proto, ze informace o typu je soucasti hodnoty, nikoliv promenne. To je podle me zakladni rozdil, nikoliv cas kontroly.
Název: Re:Co si myslíte o OOP?
Přispěvatel: Ondra Satai Nekola 04. 01. 2019, 16:47:50
Dynamicke typovani vyhodu ma, je jednodussi, flexíbilnejsi a srozumitelnejsi. Staticke typovani je vlastne docela hloupe a neprirozene, je umele. Principialni rozdil mezi statickym a dynamickym typovanim je v tom, kdo nese informaci o typu, zda promenna nebo hodnota.

To neni tak docela pravda. Napriklad Haskell nema promenne, jen hodnoty; pritom je staticky typovany. Na druhou stranu, treba Java ma promenne, ale nektere hodnoty (objekty) si drzi informaci o svem typu.

Rozdil je skutecne v tom, zda se typy kontroluji pri prekladu nebo az pri behu programu. A to druhe obvykle znamena nejakou ztratu vykonu a vyssi spotrebu pameti.

takze kdyz v haskellu napisu
Kód: [Vybrat]
dabl x = x + x
Co je to to 'x' a je datoveho typu double nebo int?

Je otazka, zda objekt je opravdu hodnota, ale dobre, opravuji formulaci na 'kde i informace o jednoduchem datovem typu je soucasti hodnoty.

Takze kdyz v pythonu, php a pod vyuziji type hinting, a datove typy zkontroluji pri prekladu, udelal jsem z nej staticky typovany jazyk? Myslim ze ne a to prave proto, ze informace o typu je soucasti hodnoty, nikoliv promenne. To je podle me zakladni rozdil, nikoliv cas kontroly.

dabl :: Num a => a -> a

(jinymi slovy x je cislo)

(a jeste update: dabl je polymorfni, ale nezamenovat to uplne s polymorfismem pozdni vazby v beznem OOP)
Název: Re:Co si myslíte o OOP?
Přispěvatel: operator 04. 01. 2019, 17:03:27
Dynamicke typovani vyhodu ma, je jednodussi, flexíbilnejsi a srozumitelnejsi. Staticke typovani je vlastne docela hloupe a neprirozene, je umele. Principialni rozdil mezi statickym a dynamickym typovanim je v tom, kdo nese informaci o typu, zda promenna nebo hodnota.

To neni tak docela pravda. Napriklad Haskell nema promenne, jen hodnoty; pritom je staticky typovany. Na druhou stranu, treba Java ma promenne, ale nektere hodnoty (objekty) si drzi informaci o svem typu.

Rozdil je skutecne v tom, zda se typy kontroluji pri prekladu nebo az pri behu programu. A to druhe obvykle znamena nejakou ztratu vykonu a vyssi spotrebu pameti.

takze kdyz v haskellu napisu
Kód: [Vybrat]
dabl x = x + x
Co je to to 'x' a je datoveho typu double nebo int?

Je otazka, zda objekt je opravdu hodnota, ale dobre, opravuji formulaci na 'kde i informace o jednoduchem datovem typu je soucasti hodnoty.

Takze kdyz v pythonu, php a pod vyuziji type hinting, a datove typy zkontroluji pri prekladu, udelal jsem z nej staticky typovany jazyk? Myslim ze ne a to prave proto, ze informace o typu je soucasti hodnoty, nikoliv promenne. To je podle me zakladni rozdil, nikoliv cas kontroly.

dabl :: Num a => a -> a

(jinymi slovy x je cislo)

(a jeste update: dabl je polymorfni, ale nezamenovat to uplne s polymorfismem pozdni vazby v beznem OOP)
Muj priklad vypadal jinak. Je to priklad ze statickeho jazyka a krasne to ukazuje, ze vase tzv. vyhody statickych jazyku jsou iluzorni. Vy statickym typum prisuzujete vlastnosti, ktere neplynou ze statickeho typovani. Staticke typovani ma jedinou vyhodu a smysl, umoznuje vyrazne lepsi vykonovou optimalizaci. To vsechno ostatni jsou vedlejsi efekty, ktere nejsou platne pro vsechny staticke jazyky a nejsou podmineny existenci statickeho typovani.
Název: Re:Co si myslíte o OOP?
Přispěvatel: Ondra Satai Nekola 04. 01. 2019, 17:06:43
Dynamicke typovani vyhodu ma, je jednodussi, flexíbilnejsi a srozumitelnejsi. Staticke typovani je vlastne docela hloupe a neprirozene, je umele. Principialni rozdil mezi statickym a dynamickym typovanim je v tom, kdo nese informaci o typu, zda promenna nebo hodnota.

To neni tak docela pravda. Napriklad Haskell nema promenne, jen hodnoty; pritom je staticky typovany. Na druhou stranu, treba Java ma promenne, ale nektere hodnoty (objekty) si drzi informaci o svem typu.

Rozdil je skutecne v tom, zda se typy kontroluji pri prekladu nebo az pri behu programu. A to druhe obvykle znamena nejakou ztratu vykonu a vyssi spotrebu pameti.

takze kdyz v haskellu napisu
Kód: [Vybrat]
dabl x = x + x
Co je to to 'x' a je datoveho typu double nebo int?

Je otazka, zda objekt je opravdu hodnota, ale dobre, opravuji formulaci na 'kde i informace o jednoduchem datovem typu je soucasti hodnoty.

Takze kdyz v pythonu, php a pod vyuziji type hinting, a datove typy zkontroluji pri prekladu, udelal jsem z nej staticky typovany jazyk? Myslim ze ne a to prave proto, ze informace o typu je soucasti hodnoty, nikoliv promenne. To je podle me zakladni rozdil, nikoliv cas kontroly.

dabl :: Num a => a -> a

(jinymi slovy x je cislo)

(a jeste update: dabl je polymorfni, ale nezamenovat to uplne s polymorfismem pozdni vazby v beznem OOP)
Muj priklad vypadal jinak. Je to priklad ze statickeho jazyka a krasne to ukazuje, ze vase tzv. vyhody statickych jazyku jsou iluzorni. Vy statickym typum prisuzujete vlastnosti, ktere neplynou ze statickeho typovani. Staticke typovani ma jedinou vyhodu a smysl, umoznuje vyrazne lepsi vykonovou optimalizaci. To vsechno ostatni jsou vedlejsi efekty, ktere nejsou platne pro vsechny staticke jazyky a nejsou podmineny existenci statickeho typovani.

Tvuj priklad byl
Kód: [Vybrat]
dabl x = x + xne?

A ja ti odpovidam, jak je to typovane. Nato ses ptal, ne?

Nechapu, co je na tom "iluzorni" a ktera vlastnost ti tam chybi.
Název: Re:Co si myslíte o OOP?
Přispěvatel: BoneFlute 04. 01. 2019, 17:11:03
Je otazka, zda objekt je opravdu hodnota, ale dobre, opravuji formulaci na 'kde i informace o jednoduchem datovem typu je soucasti hodnoty.
Rozdělení na hodnotové nehodnotové typy je IMHO taková bolest mutabilních jazyků. V haskellu je všechno hodnota: číslo, text, pole, funkce, ... Většina věcí tam je first-class. Takže když prohlásíme, že sturktura je objekt, tak ano, i v takovém případě by to byla hodnota.


Takze kdyz v pythonu, php a pod vyuziji type hinting, a datove typy zkontroluji pri prekladu, udelal jsem z nej staticky typovany jazyk?
Skoro. Určitě to pomůže odchytit velkou fůru potenciálních chyb. Ale type-hinting bude furt slabej proti plnohodnotnému statickému systému.
Například takovouto chybu ti to neodhalí (omlouvám se za případné hrubky, v pythony type-hinting ještě neumím používat).

Kód: [Vybrat]
class ContactForm:
    def __init__(self):
        self.name = none
        self.age = none

def assetContactForm(ContactForm form, string name, int age):
    form.name = name
    form.birth = age
    return form



Takze kdyz v pythonu, php a pod vyuziji type hinting, a datove typy zkontroluji pri prekladu, udelal jsem z nej staticky typovany jazyk? Myslim ze ne a to prave proto, ze informace o typu je soucasti hodnoty, nikoliv promenne. To je podle me zakladni rozdil, nikoliv cas kontroly.
V Haskellu (a myslím, že to tak platí u většiny modernějších jazyků) je typ součást hodnoty:

Kód: [Vybrat]
sum :: Int -> Int -> Int
sum a b = a + b

inc a = a + 1

dump (sum (inc 4) (inc 5.5))
Název: Re:Co si myslíte o OOP?
Přispěvatel: Kit 04. 01. 2019, 17:32:52
Teoreticky. Prakticky treba kdyz mas getXs(), tak podle typu vis, zda mohou byt xka duplicitni (list vs. set).

K čemu potřebuješ rozlišovat list vs. text? Dostaneš kolekci a budeš s ní tak i pracovat.
Název: Re:Co si myslíte o OOP?
Přispěvatel: Inkvizitor 04. 01. 2019, 17:44:11
Teoreticky. Prakticky treba kdyz mas getXs(), tak podle typu vis, zda mohou byt xka duplicitni (list vs. set).

K čemu potřebuješ rozlišovat list vs. text? Dostaneš kolekci a budeš s ní tak i pracovat.

List nemá stejné metody jako set, natož jako text.
Název: Re:Co si myslíte o OOP?
Přispěvatel: Ondra Satai Nekola 04. 01. 2019, 17:47:35
Teoreticky. Prakticky treba kdyz mas getXs(), tak podle typu vis, zda mohou byt xka duplicitni (list vs. set).

K čemu potřebuješ rozlišovat list vs. text? Dostaneš kolekci a budeš s ní tak i pracovat.

On je tam trochu sémantický rozdíl, víme? A z toho typu vysloveně svítí.
Název: Re:Co si myslíte o OOP?
Přispěvatel: Kit 04. 01. 2019, 17:53:01
Teoreticky. Prakticky treba kdyz mas getXs(), tak podle typu vis, zda mohou byt xka duplicitni (list vs. set).
K čemu potřebuješ rozlišovat list vs. text? Dostaneš kolekci a budeš s ní tak i pracovat.
List nemá stejné metody jako set, natož jako text.

Dobrá, zde tedy polymorfismus selhává. K čemu tedy potřebuji takovou kolekci vytahovat z objektu? Nebylo by lepší ji iterovat uvnitř nebo místo kolekce předat iterovatelný objekt?
Název: Re:Co si myslíte o OOP?
Přispěvatel: Kit 04. 01. 2019, 18:01:34
Teoreticky. Prakticky treba kdyz mas getXs(), tak podle typu vis, zda mohou byt xka duplicitni (list vs. set).
K čemu potřebuješ rozlišovat list vs. text? Dostaneš kolekci a budeš s ní tak i pracovat.
On je tam trochu sémantický rozdíl, víme? A z toho typu vysloveně svítí.

Sémantický rozdíl nevidím. Seznam autorů nebo množina autorů? Pro mne je to kolekce autorů a budu s ní pracovat tak, aby když někdo vymění list za set, mi to mohlo být jedno.
Název: Re:Co si myslíte o OOP?
Přispěvatel: Ondra Satai Nekola 04. 01. 2019, 18:02:49
Teoreticky. Prakticky treba kdyz mas getXs(), tak podle typu vis, zda mohou byt xka duplicitni (list vs. set).
K čemu potřebuješ rozlišovat list vs. text? Dostaneš kolekci a budeš s ní tak i pracovat.
List nemá stejné metody jako set, natož jako text.

Dobrá, zde tedy polymorfismus selhává. K čemu tedy potřebuji takovou kolekci vytahovat z objektu? Nebylo by lepší ji iterovat uvnitř nebo místo kolekce předat iterovatelný objekt?

Ne.

Protože s iteratorem nebo iterací uvnitř neuděláš rozumně  třebas základní množinové operace.
Název: Re:Co si myslíte o OOP?
Přispěvatel: Ondra Satai Nekola 04. 01. 2019, 18:03:07
Teoreticky. Prakticky treba kdyz mas getXs(), tak podle typu vis, zda mohou byt xka duplicitni (list vs. set).
K čemu potřebuješ rozlišovat list vs. text? Dostaneš kolekci a budeš s ní tak i pracovat.
On je tam trochu sémantický rozdíl, víme? A z toho typu vysloveně svítí.

Sémantický rozdíl nevidím. Seznam autorů nebo množina autorů? Pro mne je to kolekce autorů a budu s ní pracovat tak, aby když někdo vymění list za set, mi to mohlo být jedno.

Pokud ti není jasný rozdíl mezi sémantikou listu a setu, tak je asi problém na tvém přijímači.

(Btw zrovna tady máš ještě o problém navíc, protože se rozlišuje první autor, korespondující autor...)
Název: Re:Co si myslíte o OOP?
Přispěvatel: operator 04. 01. 2019, 18:03:31
Kód: [Vybrat]
~ $ cat hint_test.py
class ContactForm:
    def __init__(self):
        self.name = none
        self.age = none

def assetContactForm(ContactForm form, string name, int age):
    form.name = name
    form.birth = age
    return form
~ $
~ $ python hint_test.py
  File "hint_test.py", line 6
    def assetContactForm(ContactForm form, string name, int age):
                                        ^
SyntaxError: invalid syntax
~ $
~ $ pylint hint_test.py
Using config file /data/data/com.termux/files/home/.pylintrc
************* Module hint_test
E:  6, 0: invalid syntax (<string>, line 6) (syntax-error)
~ $

Jak vidis, tak tuhle blbost ti python odchytne. Tvrzeni ze typing z pythonu udela staticky typovany jazyk je dalsi nesmysl. Az se prokouses moznostmi a schopnostmi typingu, probereme si moznosti cythonu.
Název: Re:Co si myslíte o OOP?
Přispěvatel: UF 04. 01. 2019, 18:10:08
Teoreticky. Prakticky treba kdyz mas getXs(), tak podle typu vis, zda mohou byt xka duplicitni (list vs. set).
K čemu potřebuješ rozlišovat list vs. text? Dostaneš kolekci a budeš s ní tak i pracovat.
On je tam trochu sémantický rozdíl, víme? A z toho typu vysloveně svítí.

Sémantický rozdíl nevidím. Seznam autorů nebo množina autorů? Pro mne je to kolekce autorů a budu s ní pracovat tak, aby když někdo vymění list za set, mi to mohlo být jedno.

hele kite - zeptam se te jenom jednou ... jestli pak vis co je to anglicky "pasy"?
Název: Re:Co si myslíte o OOP?
Přispěvatel: Kit 04. 01. 2019, 18:16:53
hele kite - zeptam se te jenom jednou ... jestli pak vis co je to anglicky "pasy"?

Ano, vím. Jak to souvisí s OOP?
Název: Re:Co si myslíte o OOP?
Přispěvatel: BoneFlute 04. 01. 2019, 18:26:52
Kód: [Vybrat]
~ $ cat hint_test.py
class ContactForm:
    def __init__(self):
        self.name = none
        self.age = none

def assetContactForm(ContactForm form, string name, int age):
    form.name = name
    form.birth = age
    return form
~ $
~ $ python hint_test.py
  File "hint_test.py", line 6
    def assetContactForm(ContactForm form, string name, int age):
                                        ^
SyntaxError: invalid syntax
~ $
~ $ pylint hint_test.py
Using config file /data/data/com.termux/files/home/.pylintrc
************* Module hint_test
E:  6, 0: invalid syntax (<string>, line 6) (syntax-error)
~ $

Jak vidis, tak tuhle blbost ti python odchytne. Tvrzeni ze typing z pythonu udela staticky typovany jazyk je dalsi nesmysl. Az se prokouses moznostmi a schopnostmi typingu, probereme si moznosti cythonu.

Chtěl jsem vyjít vstříc, a napsat to v jazyku, kterému oslovený rozumí, a takto on spolupracuje. OK, beru na vědomí.
Název: Re:Co si myslíte o OOP?
Přispěvatel: BoneFlute 04. 01. 2019, 18:38:22
Jako starý Pythonista...
Mohu tě požádat o odpověď na mou otázku?

Důvody pro použití dynamických typů:
1. za běhu měnitelný systém (znám jen Erlang)
2. prototypování (takové to, když potřebuješ jen něco zkusit, a upřesňovat to budeš pozdějc)
3. neumím, nebo jazyk neumí typy

Doplníš další? (Kromě těchto scénářů nevím o ničem, kdy by netypování (př. dynamické typování) bylo užitečné.)
Název: Re:Co si myslíte o OOP?
Přispěvatel: Kadet 04. 01. 2019, 18:58:08
Jako starý Pythonista...
Mohu tě požádat o odpověď na mou otázku?

Důvody pro použití dynamických typů:
1. za běhu měnitelný systém (znám jen Erlang)
2. prototypování (takové to, když potřebuješ jen něco zkusit, a upřesňovat to budeš pozdějc)
3. neumím, nebo jazyk neumí typy

Doplníš další? (Kromě těchto scénářů nevím o ničem, kdy by netypování (př. dynamické typování) bylo užitečné.)

4. pripady, kdy staticky typovy system je prilis prisny a nepovoli preklad programu, ktery by dynamicky jazyk v pohode zvladnul a navic je takovy program lidsky intuitivni
Název: Re:Co si myslíte o OOP?
Přispěvatel: operator 04. 01. 2019, 19:01:57
Jako starý Pythonista...
Mohu tě požádat o odpověď na mou otázku?

Důvody pro použití dynamických typů:
1. za běhu měnitelný systém (znám jen Erlang)
2. prototypování (takové to, když potřebuješ jen něco zkusit, a upřesňovat to budeš pozdějc)
3. neumím, nebo jazyk neumí typy

Doplníš další? (Kromě těchto scénářů nevím o ničem, kdy by netypování (př. dynamické typování) bylo užitečné.)
4. genericke programovani
5. flexibilita
6. jednodussi (prehlednejsi) kod
7. introspekce
8. interaktivita
Název: Re:Co si myslíte o OOP?
Přispěvatel: v 04. 01. 2019, 19:09:31
8. interaktivita
to není výsada dynamických jazyků, viz např https://www.youtube.com/watch?v=mOtKD7ml0NU
Název: Re:Co si myslíte o OOP?
Přispěvatel: BoneFlute 04. 01. 2019, 19:16:27
Jako starý Pythonista...
Mohu tě požádat o odpověď na mou otázku?

Důvody pro použití dynamických typů:
1. za běhu měnitelný systém (znám jen Erlang)
2. prototypování (takové to, když potřebuješ jen něco zkusit, a upřesňovat to budeš pozdějc)
3. neumím, nebo jazyk neumí typy

Doplníš další? (Kromě těchto scénářů nevím o ničem, kdy by netypování (př. dynamické typování) bylo užitečné.)

4. pripady, kdy staticky typovy system je prilis prisny a nepovoli preklad programu, ktery by dynamicky jazyk v pohode zvladnul a navic je takovy program lidsky intuitivni
Jediné co se mi vybavilo jsou IO monády v Haskellu. Jinak mě nenapadá, kdy by měl být typový systém příliš přísný. A i u těch IO monádách je to vlastně lepší, než bez toho.

Přijde mi to jako kombinace 2ky a neznalosti.
Název: Re:Co si myslíte o OOP?
Přispěvatel: Ondra Satai Nekola 04. 01. 2019, 19:17:10
Jako starý Pythonista...
Mohu tě požádat o odpověď na mou otázku?

Důvody pro použití dynamických typů:
1. za běhu měnitelný systém (znám jen Erlang)
2. prototypování (takové to, když potřebuješ jen něco zkusit, a upřesňovat to budeš pozdějc)
3. neumím, nebo jazyk neumí typy

Doplníš další? (Kromě těchto scénářů nevím o ničem, kdy by netypování (př. dynamické typování) bylo užitečné.)
4. genericke programovani
5. flexibilita
6. jednodussi (prehlednejsi) kod
7. introspekce
8. interaktivita

Hele viděl jsi někdy nějaký moderní statický typovaný jazyk?
Název: Re:Co si myslíte o OOP?
Přispěvatel: operator 04. 01. 2019, 19:20:08
8. interaktivita
to není výsada dynamických jazyků, viz např https://www.youtube.com/watch?v=mOtKD7ml0NU
To je tvrzeni do pranice. Je jazyk staticky, pokud struktury oznacovane za staticke vytvari dynamicky? Muzu v takovem interpretu definovat funkci, ktera bude pracovat s datovym typem, ktery zatim jeste neni definovan?
Název: Re:Co si myslíte o OOP?
Přispěvatel: Inkvizitor 04. 01. 2019, 19:23:43
Jako starý Pythonista...
Mohu tě požádat o odpověď na mou otázku?

Důvody pro použití dynamických typů:
1. za běhu měnitelný systém (znám jen Erlang)
2. prototypování (takové to, když potřebuješ jen něco zkusit, a upřesňovat to budeš pozdějc)
3. neumím, nebo jazyk neumí typy

Doplníš další? (Kromě těchto scénářů nevím o ničem, kdy by netypování (př. dynamické typování) bylo užitečné.)

No já Ti raději povím svoji historii; když nepočítám Basic a Pascal a úkroky stranou typu FoxPro, vyšel jsem programátorsky z C a C++. V C byla perfektní široká škála funkcí, které oproti Pascalu umělo (práce s řetězci atd.) Jenže celou dobu mě trápilo dřevácké strukturování programů, explicitní alokace atd. C++ bylo podstatně hezčí, v té době ještě takové to staré s klasickými pointery atd., ale už to umělo aspoň reference a spousta věcí tam byla příčetnější než v C. Pak jsem koketoval s Javou - v době šílených nestabilních IDE typu Xelfi a microsoftí snahy ukrást celou platformu pomocí J++. Šílené obstrukce okolo načtení kousku souboru, to API bylo neskutečně hnusné.

V Linuxu byly dva jazyky, které mě zaujaly - Perl, který mi vždycky přišel trhlý a Python, který měl jenom "trhlou" syntaxi. Měl ale vizi, programy v něm psané byly celkem elegantní a čitelné a člověk se nemusel mazat s nějakým hloupým mallocem a callocem atd. Nějaká ideologie kolem mě trochu oslovila, ale to bylo spíš mladické poblouznění.

Takže zpátky k výhodám Pythonu - čitelnost, dobrá komunita, batteries included, v jazyku se cítím docela přirozeně. Pro prototypy je celkem super a i větší věci se v něm dají dělat, ne že ne. Dobré je, že můžeš mít kolekce s různorodými prvky, prostě se s tím hezky pracuje a zároveň se vždycky můžeš vyptat, co je ten prvek zač a podle toho s ním naložit. Prostě hezká hračka, lego, které se dá použít i na praktické věci. Mám ty výhody zobecňovat? Perl nesnáším, Ruby nemusím, Smalltalk je úplně jiný svět, PHP beru jako praktický nástroj, ale jinak mi taky nejde moc od ruky.

Co se mi líbí:

1. Neukecaná syntaxe - to ale řeší i typová inference apod.
2. Vysokoúrovňové idiomy a datové struktury - to je ale obecný trend a není to statická ani dynamická věc
3. Automatická správa paměti (ať už jde o RC, GC nebo paměťový model a la Rust)
4. Kvalitní knihovny
5. Dobré nástroje pro organizaci kódu - moduly, balíčky apod.

Python mnohé z toho splňuje, jiné jazyky taky. Dynamické typování nepovažuju za takovou výhodu. Python to dělá takhle a docela mu to jde. Jiné jazyky to umí jinak. Kdybych si mohl svobodně zvolit jazyk, šel bych spíš cestou Rustu/Scaly/Haskellu/F#. Python mě živí, umím ho nejlíp a často je to pragmaticky správná volba. Ale z dynamických vlastností nedělám fetiš, na těch to nestojí. Spousta věcí se díky nim dá spíchnout skoro "zadarmo", jenže má to samozřejmě dlouhodobé náklady. Důležitý je proces a produkt. A svět programovacích jazyků se vyvíjí k lepšímu - i Python.
Název: Re:Co si myslíte o OOP?
Přispěvatel: operator 04. 01. 2019, 19:27:55
Jako starý Pythonista...
Mohu tě požádat o odpověď na mou otázku?

Důvody pro použití dynamických typů:
1. za běhu měnitelný systém (znám jen Erlang)
2. prototypování (takové to, když potřebuješ jen něco zkusit, a upřesňovat to budeš pozdějc)
3. neumím, nebo jazyk neumí typy

Doplníš další? (Kromě těchto scénářů nevím o ničem, kdy by netypování (př. dynamické typování) bylo užitečné.)
4. genericke programovani
5. flexibilita
6. jednodussi (prehlednejsi) kod
7. introspekce
8. interaktivita

Hele viděl jsi někdy nějaký moderní statický typovaný jazyk?
Nevim co povazujes za moderni. Znam ty, ktere se se pouzivaji a je potreba je znat. C, C#, Java. Na akademicke jako je Haskell neplytvam casem.
Název: Re:Co si myslíte o OOP?
Přispěvatel: Ondra Satai Nekola 04. 01. 2019, 19:28:42
Jako starý Pythonista...
Mohu tě požádat o odpověď na mou otázku?

Důvody pro použití dynamických typů:
1. za běhu měnitelný systém (znám jen Erlang)
2. prototypování (takové to, když potřebuješ jen něco zkusit, a upřesňovat to budeš pozdějc)
3. neumím, nebo jazyk neumí typy

Doplníš další? (Kromě těchto scénářů nevím o ničem, kdy by netypování (př. dynamické typování) bylo užitečné.)
4. genericke programovani
5. flexibilita
6. jednodussi (prehlednejsi) kod
7. introspekce
8. interaktivita

Hele viděl jsi někdy nějaký moderní statický typovaný jazyk?
Nevim co povazujes za moderni. Znam ty, ktere se se pouzivaji a je potreba je znat. C, C#, Java. Na akademicke jako je Haskell neplytvam casem.

Aha. Takže houby víš, ale názor se ti už udělal.
Název: Re:Co si myslíte o OOP?
Přispěvatel: BoneFlute 04. 01. 2019, 19:32:06
Takže zpátky k výhodám Pythonu - čitelnost, dobrá komunita, batteries included, v jazyku se cítím docela přirozeně. Pro prototypy je celkem super a i větší věci se v něm dají dělat, ne že ne. Dobré je, že můžeš mít kolekce s různorodými prvky, prostě se s tím hezky pracuje a zároveň se vždycky můžeš vyptat, co je ten prvek zač a podle toho s ním naložit. Prostě hezká hračka, lego, které se dá použít i na praktické věci. Mám ty výhody zobecňovat? Perl nesnáším, Ruby nemusím, Smalltalk je úplně jiný svět, PHP beru jako praktický nástroj, ale jinak mi taky nejde moc od ruky.

Co se mi líbí:

1. Neukecaná syntaxe - to ale řeší i typová inference apod.
2. Vysokoúrovňové idiomy a datové struktury - to je ale obecný trend a není to statická ani dynamická věc
3. Automatická správa paměti (ať už jde o RC, GC nebo paměťový model a la Rust)
4. Kvalitní knihovny
5. Dobré nástroje pro organizaci kódu - moduly, balíčky apod.

Python mnohé z toho splňuje, jiné jazyky taky. Dynamické typování nepovažuju za takovou výhodu. Python to dělá takhle a docela mu to jde. Jiné jazyky to umí jinak. Kdybych si mohl svobodně zvolit jazyk, šel bych spíš cestou Rustu/Scaly/Haskellu/F#. Python mě živí, umím ho nejlíp a často je to pragmaticky správná volba. Ale z dynamických vlastností nedělám fetiš, na těch to nestojí. Spousta věcí se díky nim dá spíchnout skoro "zadarmo", jenže má to samozřejmě dlouhodobé náklady. Důležitý je proces a produkt. A svět programovacích jazyků se vyvíjí k lepšímu - i Python.
Podepisuju se.

A díky!

Já tedy postupem času u dynamických jazycích přešel na Luu, protože mi přijde taková subtilnější a rychlejší. A stejně jsem vždycky narazil na to, že tam spousta věcí musím zase dělat ručně. V porovnání s Haskellem je to jako dláto verzus CNC soustruh. Dláto mohu použít hned, jednoduše, a nemusím nic řešit. Ale taky se udřu.
Název: Re:Co si myslíte o OOP?
Přispěvatel: BoneFlute 04. 01. 2019, 19:34:49
Hele viděl jsi někdy nějaký moderní statický typovaný jazyk?
Nevim co povazujes za moderni. Znam ty, ktere se se pouzivaji a je potreba je znat. C, C#, Java. Na akademicke jako je Haskell neplytvam casem.
S tou Javou a C# jsi si jist? ;-)
Název: Re:Co si myslíte o OOP?
Přispěvatel: operator 04. 01. 2019, 19:49:13
Jako starý Pythonista...
Mohu tě požádat o odpověď na mou otázku?

Důvody pro použití dynamických typů:
1. za běhu měnitelný systém (znám jen Erlang)
2. prototypování (takové to, když potřebuješ jen něco zkusit, a upřesňovat to budeš pozdějc)
3. neumím, nebo jazyk neumí typy

Doplníš další? (Kromě těchto scénářů nevím o ničem, kdy by netypování (př. dynamické typování) bylo užitečné.)

No já Ti raději povím svoji historii; když nepočítám Basic a Pascal a úkroky stranou typu FoxPro, vyšel jsem programátorsky z C a C++. V C byla perfektní široká škála funkcí, které oproti Pascalu umělo (práce s řetězci atd.) Jenže celou dobu mě trápilo dřevácké strukturování programů, explicitní alokace atd. C++ bylo podstatně hezčí, v té době ještě takové to staré s klasickými pointery atd., ale už to umělo aspoň reference a spousta věcí tam byla příčetnější než v C. Pak jsem koketoval s Javou - v době šílených nestabilních IDE typu Xelfi a microsoftí snahy ukrást celou platformu pomocí J++. Šílené obstrukce okolo načtení kousku souboru, to API bylo neskutečně hnusné.

V Linuxu byly dva jazyky, které mě zaujaly - Perl, který mi vždycky přišel trhlý a Python, který měl jenom "trhlou" syntaxi. Měl ale vizi, programy v něm psané byly celkem elegantní a čitelné a člověk se nemusel mazat s nějakým hloupým mallocem a callocem atd. Nějaká ideologie kolem mě trochu oslovila, ale to bylo spíš mladické poblouznění.

Takže zpátky k výhodám Pythonu - čitelnost, dobrá komunita, batteries included, v jazyku se cítím docela přirozeně. Pro prototypy je celkem super a i větší věci se v něm dají dělat, ne že ne. Dobré je, že můžeš mít kolekce s různorodými prvky, prostě se s tím hezky pracuje a zároveň se vždycky můžeš vyptat, co je ten prvek zač a podle toho s ním naložit. Prostě hezká hračka, lego, které se dá použít i na praktické věci. Mám ty výhody zobecňovat? Perl nesnáším, Ruby nemusím, Smalltalk je úplně jiný svět, PHP beru jako praktický nástroj, ale jinak mi taky nejde moc od ruky.

Co se mi líbí:

1. Neukecaná syntaxe - to ale řeší i typová inference apod.
2. Vysokoúrovňové idiomy a datové struktury - to je ale obecný trend a není to statická ani dynamická věc
3. Automatická správa paměti (ať už jde o RC, GC nebo paměťový model a la Rust)
4. Kvalitní knihovny
5. Dobré nástroje pro organizaci kódu - moduly, balíčky apod.

Python mnohé z toho splňuje, jiné jazyky taky. Dynamické typování nepovažuju za takovou výhodu. Python to dělá takhle a docela mu to jde. Jiné jazyky to umí jinak. Kdybych si mohl svobodně zvolit jazyk, šel bych spíš cestou Rustu/Scaly/Haskellu/F#. Python mě živí, umím ho nejlíp a často je to pragmaticky správná volba. Ale z dynamických vlastností nedělám fetiš, na těch to nestojí. Spousta věcí se díky nim dá spíchnout skoro "zadarmo", jenže má to samozřejmě dlouhodobé náklady. Důležitý je proces a produkt. A svět programovacích jazyků se vyvíjí k lepšímu - i Python.
U me je to podobne, Python+C(ython) je prvni vychozi volba. Otazka nezni proc Python jo, ale proc Python ne. Takze Python ne, kdyz potrebuji skriptovat webove stranky, tam je nutny JS, Python ne, kdyz jde o produkt na verejny hosting, tam je to PHP, Python ne, kdyz jde o produkt, ktery ma byt integrovan do stavajici podnikove infrastruktury nebo se jedna o jeji modifikaci, tam je to casto Java nebo C#. Ale ve vetsine pripadu Python vyhovi. Je paradni treba na automation, kde se driv pouzivalo vba, je paradni na webove aplikace, ktere jedou na vlastnim serveru a dneska uz je skoro vsechno webova aplikace, o tradicni desktopove prestal byt zajem. Drive byl duvod k odmitnuti Pythonu pozadavek na vysoky vykon, Cython to ale zmenil a dnes se pozadavky na vykon neni potreba zabyvat.
Název: Re:Co si myslíte o OOP?
Přispěvatel: operator 04. 01. 2019, 19:56:57
Jako starý Pythonista...
Mohu tě požádat o odpověď na mou otázku?

Důvody pro použití dynamických typů:
1. za běhu měnitelný systém (znám jen Erlang)
2. prototypování (takové to, když potřebuješ jen něco zkusit, a upřesňovat to budeš pozdějc)
3. neumím, nebo jazyk neumí typy

Doplníš další? (Kromě těchto scénářů nevím o ničem, kdy by netypování (př. dynamické typování) bylo užitečné.)
4. genericke programovani
5. flexibilita
6. jednodussi (prehlednejsi) kod
7. introspekce
8. interaktivita
Hele viděl jsi někdy nějaký moderní statický typovaný jazyk?
Nevim co povazujes za moderni. Znam ty, ktere se se pouzivaji a je potreba je znat. C, C#, Java. Na akademicke jako je Haskell neplytvam casem.
Aha. Takže houby víš, ale názor se ti už udělal.
To bych nerekl. Zabyvam se tim pragmaticky. I kdyby haskell nebyl tak tezkopadny, jako v praxi pouzivane staticke jazyky, tak je to bezvyznamna zajimavost, protoze v praxi je to nepouzitelny jazyk. Zajimaji me a posuzuji vlastnosti praktickych jazyku.
Název: Re:Co si myslíte o OOP?
Přispěvatel: Ondra Satai Nekola 04. 01. 2019, 20:09:35
Jako starý Pythonista...
Mohu tě požádat o odpověď na mou otázku?

Důvody pro použití dynamických typů:
1. za běhu měnitelný systém (znám jen Erlang)
2. prototypování (takové to, když potřebuješ jen něco zkusit, a upřesňovat to budeš pozdějc)
3. neumím, nebo jazyk neumí typy

Doplníš další? (Kromě těchto scénářů nevím o ničem, kdy by netypování (př. dynamické typování) bylo užitečné.)
4. genericke programovani
5. flexibilita
6. jednodussi (prehlednejsi) kod
7. introspekce
8. interaktivita
Hele viděl jsi někdy nějaký moderní statický typovaný jazyk?
Nevim co povazujes za moderni. Znam ty, ktere se se pouzivaji a je potreba je znat. C, C#, Java. Na akademicke jako je Haskell neplytvam casem.
Aha. Takže houby víš, ale názor se ti už udělal.
To bych nerekl. Zabyvam se tim pragmaticky. I kdyby haskell nebyl tak tezkopadny, jako v praxi pouzivane staticke jazyky, tak je to bezvyznamna zajimavost, protoze v praxi je to nepouzitelny jazyk. Zajimaji me a posuzuji vlastnosti praktickych jazyku.

A že půlka těch věcí neplatí ani u Javy třebas o F# nebo Scale nemluvě...
Název: Re:Co si myslíte o OOP?
Přispěvatel: BoneFlute 04. 01. 2019, 20:20:58
Jako starý Pythonista...
Mohu tě požádat o odpověď na mou otázku?

Důvody pro použití dynamických typů:
1. za běhu měnitelný systém (znám jen Erlang)
2. prototypování (takové to, když potřebuješ jen něco zkusit, a upřesňovat to budeš pozdějc)
3. neumím, nebo jazyk neumí typy

Doplníš další? (Kromě těchto scénářů nevím o ničem, kdy by netypování (př. dynamické typování) bylo užitečné.)
4. genericke programovani
5. flexibilita
6. jednodussi (prehlednejsi) kod
7. introspekce
8. interaktivita
Hele viděl jsi někdy nějaký moderní statický typovaný jazyk?
Nevim co povazujes za moderni. Znam ty, ktere se se pouzivaji a je potreba je znat. C, C#, Java. Na akademicke jako je Haskell neplytvam casem.
Aha. Takže houby víš, ale názor se ti už udělal.
To bych nerekl. Zabyvam se tim pragmaticky. I kdyby haskell nebyl tak tezkopadny, jako v praxi pouzivane staticke jazyky, tak je to bezvyznamna zajimavost, protoze v praxi je to nepouzitelny jazyk. Zajimaji me a posuzuji vlastnosti praktickych jazyku.

A že půlka těch věcí neplatí ani u Javy třebas o F# nebo Scale nemluvě...
Že i na takovou obludu jako je javascript se roubujou typy (Flow, google-closure, TypeScript), protože bez nich žádnou větší aplikaci prostě neudržíš.
Název: Re:Co si myslíte o OOP?
Přispěvatel: v 04. 01. 2019, 20:22:20
8. interaktivita
to není výsada dynamických jazyků, viz např https://www.youtube.com/watch?v=mOtKD7ml0NU
To je tvrzeni do pranice. Je jazyk staticky, pokud struktury oznacovane za staticke vytvari dynamicky? Muzu v takovem interpretu definovat funkci, ktera bude pracovat s datovym typem, ktery zatim jeste neni definovan?
první otázce nerozumím, na druhou je odpověď kladná (typeclasses, parametricity a tak)
Název: Re:Co si myslíte o OOP?
Přispěvatel: JS 04. 01. 2019, 20:37:17
Python mnohé z toho splňuje, jiné jazyky taky. Dynamické typování nepovažuju za takovou výhodu. Python to dělá takhle a docela mu to jde. Jiné jazyky to umí jinak. Kdybych si mohl svobodně zvolit jazyk, šel bych spíš cestou Rustu/Scaly/Haskellu/F#. Python mě živí, umím ho nejlíp a často je to pragmaticky správná volba. Ale z dynamických vlastností nedělám fetiš, na těch to nestojí. Spousta věcí se díky nim dá spíchnout skoro "zadarmo", jenže má to samozřejmě dlouhodobé náklady. Důležitý je proces a produkt. A svět programovacích jazyků se vyvíjí k lepšímu - i Python.
Podepisuju se.

Ja to vidim podobne jako Inkvizitor - taky jsem Python zacal pouzival okolo roku 2001, a v te dobe to bylo prijemne jednodussi nez vsechno ostatni okolo. Pozdeji jsem si oblibil Common Lisp a Haskell, ale Python mi porad jde nejlepe.

Ale zacinat znovu, tak rovnou u Haskellu... jak uz jsem ti psal, s dobrou typovou inferenci se vyhoda dynamickeho typovani znacne snizuje. Takze pocitam, ze soucasny trend je (velmi pomaly) postupny navrat ke statickemu typovani diky rozsireni typove inference.
Název: Re:Co si myslíte o OOP?
Přispěvatel: BoneFlute 04. 01. 2019, 20:49:57
Ja to vidim podobne jako Inkvizitor - taky jsem Python zacal pouzival okolo roku 2001, a v te dobe to bylo prijemne jednodussi nez vsechno ostatni okolo. Pozdeji jsem si oblibil Common Lisp a Haskell, ale Python mi porad jde nejlepe.

Ale zacinat znovu, tak rovnou u Haskellu... jak uz jsem ti psal, s dobrou typovou inferenci se vyhoda dynamickeho typovani znacne snizuje. Takze pocitam, ze soucasny trend je (velmi pomaly) postupny navrat ke statickemu typovani diky rozsireni typove inference.
Takže když si to shrnu, dynamické typování nemá žádné principielní výhody. Jen je to zkrátka a dobře jednodužší na implementaci a naučení. Můžeme se bavit o tom, že je tu jakýsi historický balast, který si vývojáři nesou (například představa ukecanosti, představa pouze základních typů, nepochopení důsledků typové kontroly, etc) vytvářející mýtus výhod, ale jinak asi nic výraznějšího tam nebude. Souhlas?
Název: Re:Co si myslíte o OOP?
Přispěvatel: agent 04. 01. 2019, 20:52:10
...Takze pocitam, ze soucasny trend je (velmi pomaly) postupny navrat ke statickemu typovani diky rozsireni typove inference.
A když to už někdo opravdu potřebuje dynamicky, tak třeba c# mu vychází vstříc datový typem dynamic (třeba jako parametry metod).
Název: Re:Co si myslíte o OOP?
Přispěvatel: agent 04. 01. 2019, 20:54:17
Tedy datový typ není moc vhodné slovo v téhle souvislosti, takže dejme tomu "datový typ"  ;D
Název: Re:Co si myslíte o OOP?
Přispěvatel: tipař 04. 01. 2019, 21:11:05
Ja to vidim podobne jako Inkvizitor - taky jsem Python zacal pouzival okolo roku 2001, a v te dobe to bylo prijemne jednodussi nez vsechno ostatni okolo. Pozdeji jsem si oblibil Common Lisp a Haskell, ale Python mi porad jde nejlepe.

Ale zacinat znovu, tak rovnou u Haskellu... jak uz jsem ti psal, s dobrou typovou inferenci se vyhoda dynamickeho typovani znacne snizuje. Takze pocitam, ze soucasny trend je (velmi pomaly) postupny navrat ke statickemu typovani diky rozsireni typove inference.
Takže když si to shrnu, dynamické typování nemá žádné principielní výhody. Jen je to zkrátka a dobře jednodužší na implementaci a naučení. Můžeme se bavit o tom, že je tu jakýsi historický balast, který si vývojáři nesou (například představa ukecanosti, představa pouze základních typů, nepochopení důsledků typové kontroly, etc) vytvářející mýtus výhod, ale jinak asi nic výraznějšího tam nebude. Souhlas?
+1
Název: Re:Co si myslíte o OOP?
Přispěvatel: listoper 04. 01. 2019, 21:50:15
Ja to vidim podobne jako Inkvizitor - taky jsem Python zacal pouzival okolo roku 2001, a v te dobe to bylo prijemne jednodussi nez vsechno ostatni okolo. Pozdeji jsem si oblibil Common Lisp a Haskell, ale Python mi porad jde nejlepe.

Ale zacinat znovu, tak rovnou u Haskellu... jak uz jsem ti psal, s dobrou typovou inferenci se vyhoda dynamickeho typovani znacne snizuje. Takze pocitam, ze soucasny trend je (velmi pomaly) postupny navrat ke statickemu typovani diky rozsireni typove inference.
Takže když si to shrnu, dynamické typování nemá žádné principielní výhody. Jen je to zkrátka a dobře jednodužší na implementaci a naučení. Můžeme se bavit o tom, že je tu jakýsi historický balast, který si vývojáři nesou (například představa ukecanosti, představa pouze základních typů, nepochopení důsledků typové kontroly, etc) vytvářející mýtus výhod, ale jinak asi nic výraznějšího tam nebude. Souhlas?
+1

Kdyz se nam tu tedy formuje nejaky konsenzus... Tak se zeptam.
Z toho co tu ctu to vypada, ze staticke typovani (a la haskell) ma jistou evolucni vyhodu pred dynamickym.
Z dlouhodobeho hlediska muzeme tedy predokladat vymizeni dynamicky typovanych jazyku?
(at uz tim, ze se prestanou pouzivat, nebo tim, ze do nich typy proniknou)
Nejake odhady kdy to bude?


Název: Re:Co si myslíte o OOP?
Přispěvatel: tipař 04. 01. 2019, 21:55:43
Ja to vidim podobne jako Inkvizitor - taky jsem Python zacal pouzival okolo roku 2001, a v te dobe to bylo prijemne jednodussi nez vsechno ostatni okolo. Pozdeji jsem si oblibil Common Lisp a Haskell, ale Python mi porad jde nejlepe.

Ale zacinat znovu, tak rovnou u Haskellu... jak uz jsem ti psal, s dobrou typovou inferenci se vyhoda dynamickeho typovani znacne snizuje. Takze pocitam, ze soucasny trend je (velmi pomaly) postupny navrat ke statickemu typovani diky rozsireni typove inference.
Takže když si to shrnu, dynamické typování nemá žádné principielní výhody. Jen je to zkrátka a dobře jednodužší na implementaci a naučení. Můžeme se bavit o tom, že je tu jakýsi historický balast, který si vývojáři nesou (například představa ukecanosti, představa pouze základních typů, nepochopení důsledků typové kontroly, etc) vytvářející mýtus výhod, ale jinak asi nic výraznějšího tam nebude. Souhlas?
+1

Kdyz se nam tu tedy formuje nejaky konsenzus... Tak se zeptam.
Z toho co tu ctu to vypada, ze staticke typovani (a la haskell) ma jistou evolucni vyhodu pred dynamickym.
Z dlouhodobeho hlediska muzeme tedy predokladat vymizeni dynamicky typovanych jazyku?
(at uz tim, ze se prestanou pouzivat, nebo tim, ze do nich typy proniknou)
Nejake odhady kdy to bude?

A v čem by dělaly lopaty? Dynamicky typované jazyky jsou pro lidi, kteří ještě neumí programovat a chtějí nějak jednoduše začít.
Název: Re:Co si myslíte o OOP?
Přispěvatel: abc 04. 01. 2019, 23:16:21
Takže když si to shrnu, dynamické typování nemá žádné principielní výhody. Jen je to zkrátka a dobře jednodužší na implementaci a naučení. Můžeme se bavit o tom, že je tu jakýsi historický balast, který si vývojáři nesou (například představa ukecanosti, představa pouze základních typů, nepochopení důsledků typové kontroly, etc) vytvářející mýtus výhod, ale jinak asi nic výraznějšího tam nebude. Souhlas?

Dynamicky typovaný jazyky si serou do huby, viz PHP. Snažíme se v něm dělat jakoby byl staticky typovanej, přitom ale nemáme featury jako přetížení, generiku a navíc dynamický typy proměnnejch a type hinty ještě k tomu snižujou výkon.
Název: Re:Co si myslíte o OOP?
Přispěvatel: JS 04. 01. 2019, 23:20:59
Z dlouhodobeho hlediska muzeme tedy predokladat vymizeni dynamicky typovanych jazyku?
(at uz tim, ze se prestanou pouzivat, nebo tim, ze do nich typy proniknou)
Nejake odhady kdy to bude?

Muj nazor je, ze se toho nedozijes (tzn. nestane se to do 40 let  :)).  Podle me dojde k tomu, ze vznikne nova forma typove inference, ktera bude pouzivat jen typove tridy. Takze kompilator bude typy urcovat uplne sam (pripadne s nejakymi lehkymi hinty). Pak to bude v podstate jen zalezitost kompilatoru, jestli je urci behem kompilace nebo to zkompiluje s typovou kontrolou za behu - v jazyce to tak jako tak pujde zapsat i bez typu.
Název: Re:Co si myslíte o OOP?
Přispěvatel: BaldSlattery 04. 01. 2019, 23:49:09
Z dlouhodobeho hlediska muzeme tedy predokladat vymizeni dynamicky typovanych jazyku?
(at uz tim, ze se prestanou pouzivat, nebo tim, ze do nich typy proniknou)
Nejake odhady kdy to bude?
kompilator bude typy urcovat uplne sam (pripadne s nejakymi lehkymi hinty).
Tohle už některé jazyky mají.
Název: Re:Co si myslíte o OOP?
Přispěvatel: Kit 04. 01. 2019, 23:56:05
Dynamicky typovaný jazyky si serou do huby, viz PHP. Snažíme se v něm dělat jakoby byl staticky typovanej, přitom ale nemáme featury jako přetížení, generiku a navíc dynamický typy proměnnejch a type hinty ještě k tomu snižujou výkon.

V PHP přetěžování nechybí, to sis asi s něčím spletl. K čemu generika, když si mohu strom poskládat z čehokoli? Typehinty vůbec používat nemusíš. Kde je problém?
Název: Re:Co si myslíte o OOP?
Přispěvatel: Blbec 05. 01. 2019, 00:47:26
Jako starý Pythonista...
Mohu tě požádat o odpověď na mou otázku?

Důvody pro použití dynamických typů:
1. za běhu měnitelný systém (znám jen Erlang)
2. prototypování (takové to, když potřebuješ jen něco zkusit, a upřesňovat to budeš pozdějc)
3. neumím, nebo jazyk neumí typy

Doplníš další? (Kromě těchto scénářů nevím o ničem, kdy by netypování (př. dynamické typování) bylo užitečné.)

4. pripady, kdy staticky typovy system je prilis prisny a nepovoli preklad programu, ktery by dynamicky jazyk v pohode zvladnul a navic je takovy program lidsky intuitivni
Jediné co se mi vybavilo jsou IO monády v Haskellu. Jinak mě nenapadá, kdy by měl být typový systém příliš přísný. A i u těch IO monádách je to vlastně lepší, než bez toho.

Přijde mi to jako kombinace 2ky a neznalosti.

Chlape, ty si nejdřív něco nastuduj o typových systémech, než budeš rozdávat pravdy.
Existujou validní programy, který statickej jazyk neuzná. Žádnej statickej typovej systém nebude nikdy dostatečně silnej na to, aby uznal všechny validní programy - viz Godelovy věty o nekompletnosti.

http://logan.tw/posts/2014/11/12/soundness-and-completeness-of-the-type-system/
Název: Re:Co si myslíte o OOP?
Přispěvatel: BoneFlute 05. 01. 2019, 02:18:52
Chlape, ty si nejdřív něco nastuduj o typových systémech, než budeš rozdávat pravdy.
Existujou validní programy, který statickej jazyk neuzná. Žádnej statickej typovej systém nebude nikdy dostatečně silnej na to, aby uznal všechny validní programy - viz Godelovy věty o nekompletnosti.

http://logan.tw/posts/2014/11/12/soundness-and-completeness-of-the-type-system/

Opět, Přijde mi to jako kombinace 2ky a neznalosti. Samozřejmě, že tento problém existuje, a statické jazyky si s ním umějí poradit.
Název: Re:Co si myslíte o OOP?
Přispěvatel: JS 05. 01. 2019, 07:50:20
Existujou validní programy, který statickej jazyk neuzná. Žádnej statickej typovej systém nebude nikdy dostatečně silnej na to, aby uznal všechny validní programy - viz Godelovy věty o nekompletnosti.

http://logan.tw/posts/2014/11/12/soundness-and-completeness-of-the-type-system/

IMHO to je spis teoreticky problem, v praxi se to resi pridanim dodatecneho axiomu (s tim, ze se stale preferuje neuplnost pred nekorektnosti). Nevim o tom, ze by zatim nekdo potreboval vic nez "jeden" axiom, kterym je otypovani rekurzivnich typu. (Mozna se to deje kdyz prejdeme k zavislostnim typum nebo jinym typovym rozsirenim, nevim.)

Snad me nekdo doplni. Mam pocit, ze je to jako v matematice - po axiomu nekonecna a vyberu uz jsou v podstate dalsi pridavane axiomy dost exoticke a clovek je na bezne problemy nepotrebuje.
Název: Re:Co si myslíte o OOP?
Přispěvatel: JS 05. 01. 2019, 07:53:39
Z dlouhodobeho hlediska muzeme tedy predokladat vymizeni dynamicky typovanych jazyku?
(at uz tim, ze se prestanou pouzivat, nebo tim, ze do nich typy proniknou)
Nejake odhady kdy to bude?
kompilator bude typy urcovat uplne sam (pripadne s nejakymi lehkymi hinty).
Tohle už některé jazyky mají.

Nejsem si jisty, zda myslime totez - asi by bylo lepsi uvest priklad. V Haskellu existuji pro to rozsireni, ale zatim to jeste neni uplne ono - selzou pokud vysledny typ neni implikovan jednoznacne.
Název: Re:Co si myslíte o OOP?
Přispěvatel: UF 05. 01. 2019, 11:20:18

Kdyz se nam tu tedy formuje nejaky konsenzus... Tak se zeptam.


tady se formuje leda tak velky h0vn0
Název: Re:Co si myslíte o OOP?
Přispěvatel: Kiwi 05. 01. 2019, 16:34:39
Obávám se, že takto statické typování nefunguje. Všechny příklady tebou naznačného spektra možností mohu řešit. A statické typování mi bude hodně pomáhat. (A nemusím to dělat ručně.)

Zkusme být konkrétní. Bylo tu uvedeno parsování JSONu. Řešil bych to určitě staticky. Rozhodování zpracování podle typu dat? Staticky. Rozhodnování podle dat - to si nejsem jist, co myslíš. Jak se mohu rozhodovat podle dat? Čeho se mohu chytnout? Můžeš uvést příklad?
Netvrdím, že to nejde. Kdyby to nešlo, tak by většina praktických problémů byla neřešitelná staticky typovanými jazyky. Jenže to, co vnímáš jako cosi, co ti bude hodně pomáhat, já často vnímám jako klacky motající se pod nohama.
Takže něco takového jako když já po milióntý prvý pouštím celou aplikaci, a píšu druhou miliardu testů, aby to pokrylo alespoň 5procent všech možnejch chyb? :-)
Toto asi už bude o pocitech, takže to nerozebírejme. Zajímají mě tedy asi spíše nějaké racionálnější argumenty.
Jaká miliarda testů? Používám jak jazyky staticky typované, tak dynamicky a nepozoruji, že by programy v těch druhých padaly nějak častěji.

Rozhodování podle dat, tím myslím IF size > 5 cm THEN ...
Rozhodování podle typu, tím myslím IF (x hasMagnitude) THEN ...
Rozhodování bez ohledu na typ, tím myslím IF x > 5 THEN ..., bez ohledu na to, co to "x" je, protože mě zajímá jen odpověď na otázku, zda "to" je větší než 5.
Rozumím. Tak první bude nějaká funkce. Druhé bude pattern matching na typ. A třetí se řeší třídou/interfacem. Viz odpověď dále.
A v dynamicky typovaném Smalltalku se to vše vyřeší jedním a tím samým mechanismem.

Viděl jsi často, že by hostinský točil pivo do papírové krabice, přestože mu v tom nic nebrání? Jistě by šlo zařídit, aby se pípa odjistila jen v případě, že pod sebou detekuje konkrétně určený značkový půllitr. Mě by popadl rapl a ta pípa by letěla na smetiště hned v okamžiku, kdy by mi odmítala pustit pivo do džbánku.
Smysl statických typů je zajistit, aby se něco takového nestalo. Když zůstaneme u přirovnání, tak ty budeš muset hostinského zaškolit, a ještě nainstalovat kameru, aby si ho sledoval, zda nečepuje pivo přímo do pusy. A stejně ho neuhlídáš. Zatímco já tam budu moct dát cedulku "samoobslužná pípa".

Každopádně ve statickém jazyce zajistím, že ta pípa se odjistí jen v případě, kdy je do čeho načepovat. Džbánek ano, papírová krabice ne.

V případě dynamických typů ten problém máš samozřejmě taky. Ale buď ho neřešíš, a doufáš, že všechno dobře dopadne. Nebo testuješ jak blbej, a pak doufáš, že všechno dobře dopadne.
Ale to je často zbytečně defenzivní přístup. Velké komplikace kvůli něčemu, čemu se dá předejít i jinak - prakticky tak, že pípu obsluhuje jedině personál k tomu kompetentní. Podobně je jednodušší namalovat na silnici plnou čáru než všude stavět svodidla.


Co je na tašce na rohlíky tak provokativního? Do datového typu rohlík dám jen rohlík a seznam rohlíků není nic jiného než taška na rohlíky. V době překladu vím, že mám datový typ, do kterého můžu naskládat jedině rohlíky. Jistě, mohu vytvořit i datový typ, do něhož jdou sázet rohlíky a housky. Ale i tuto situaci musím předvídat v době překladu.
Ano, musím to předvídat v době překladu. To je jediné, v čem máš pravdu. Jinak fakt neuvažuju, tak jak popisuješ.
Kontainer na rohlíky bych dělal v případě, kdy chci jen rohlíky. Takže to bude třeba recept na jednohubky. Protože ten dělám zásadně z rohlíků.
Ale když budu brát do krámu nějakou tašku, tak bych byl idiot se omezovat takhle, ne. Budu definovat jiná omezení. Ta, která budou užitečná.
Akorát jsi přidal nicneříkající přívlastek ke slovu "omezení", abys ho nějak ospravedlnil. Která to jsou a proč? Opět - pro mě často zbytečně restriktivní způsob myšlení.

Neznám moc jazyků, které by obsahovaly "rohlík" jako jeden ze základních typů.
Taky nás nic takového nezajímá. Doba typování ala jazyk C je naštěstí už dávno pryč.
A jaká je tedy dnes doba?

Budu-li chtít modelovat nákupní tašku, tak jako nejjednodušší případ mě napadá nějaká kolekce, třeba seznam. Ale pořád mi tu BoneFlute nevysvětlil, seznam čeho by to optimálně měl být a jakou by to mělo výhodu oproti obecné dynamicky typované kolekci.
Toho, čeho potřebuješ. To přirovnání je debilní, ale tak můžeš mít nákupní tašku na pečivo. Takže obecný typ pro pečivo. Nebo typ TuháHmota, aby si tam nečepoval to pivo. Atd.

Pak samozřejmě můžeš dojít k závěru, že nevíš, a že tam chceš dát cokoliv. Tak dáš typ *, a budeš tam moct uložit opravdu cokoliv.
A proč? Když tu kolekci využívá nějaký modul, který už má na jiném místě zajištěno, že tam přijde jen patřičný typ objektů, tak není důvod to opět někde specifikovat a kontrolovat. Dokonce to bude komplikace, když se změní protokol na vyšší úrovni. Zatímco u nespecifikovaného typu by nebylo nutné zasahovat do daného modulu vůbec, v tomto případě se tím vše úplně zbytečně rozbije.

Trošku bych to přeformuloval:
Statickej jazyk: "hele, čím víc mi řekneš podrobností předem, tím líp ti pomůžu".
Dynamickej jazyk: "hele, mě to nezajímá, cpi si tam co chceš, stejně si to budeš hlídat ty, já ti nepomůžu, ani mě nenapadne".
Naprosto v pořádku. Úplně stejně argumentují známí, kteří sympatizují s levicovými stranami. A nedokážou pochopit, když jim říkám, že nechci, aby mě stát vodil za ručičku, protože se umím vodit sám. Ale chtěl bych zdůraznit, že jsem prvotně reagoval na odpověď na Kitův komentář, v němž výslovně zmiňoval objektové jazyky. Nikdo tam po překladači nechce, aby něco takového hlídal, protože to je plně v kompetenci objektu.


- V dynamickém typování ti aplikace furt padá (ideálně na produkci), protože jsi nevychytal všechny chyby (nic ti nepomáhá).
Podobné předsudky jsem taky míval, dokud jsem v tom nezačal dělat. A, světe div se, žádné neustálé padání se nekoná. Přiznám se, že mě to samotného překvapilo, ale v dynamicky typovaných jazycích se vyvíjí trošku jinak - musíš u toho trochu změnit způsob uvažování. Ze začátku má člověk nutkání dopisovat typovou kontrolu ručně, ale to je ve skutečnosti antipattern. To platí třeba i v Pythonu (viz Idiomatic Python), ale třeba v takovém objektovém Smalltalku je to přímo do očí bijící. Prostě typová kontrola je také kompetence objektů. A ono to funguje, a velmi dobře!
Název: Re:Co si myslíte o OOP?
Přispěvatel: baranomrd 05. 01. 2019, 17:09:03
Citace
V dynamickém typování ti aplikace furt padá (ideálně na produkci), protože jsi nevychytal všechny chyby (nic ti nepomáhá).

Tak toto je hneď z úvodu dezinformácia roka 2019, lebo toto, ani na tomto informačne bezcennom fóre, už do ďalšieho Silvestra nikto neprekoná. To čo za lopatku toto vyslovilo? Strel si facku a viac sa nevyjadruj k programovaniu :D
Název: Re:Co si myslíte o OOP?
Přispěvatel: Kit 05. 01. 2019, 17:38:07
Rozhodování podle dat, tím myslím IF size > 5 cm THEN ...
Rozhodování podle typu, tím myslím IF (x hasMagnitude) THEN ...
Rozhodování bez ohledu na typ, tím myslím IF x > 5 THEN ..., bez ohledu na to, co to "x" je, protože mě zajímá jen odpověď na otázku, zda "to" je větší než 5.
Rozumím. Tak první bude nějaká funkce. Druhé bude pattern matching na typ. A třetí se řeší třídou/interfacem. Viz odpověď dále.
A v dynamicky typovaném Smalltalku se to vše vyřeší jedním a tím samým mechanismem.

... a ještě se v něm tím samým mechanismem napíší testy.

Trošku bych to přeformuloval:
Statickej jazyk: "hele, čím víc mi řekneš podrobností předem, tím líp ti pomůžu".
Dynamickej jazyk: "hele, mě to nezajímá, cpi si tam co chceš, stejně si to budeš hlídat ty, já ti nepomůžu, ani mě nenapadne".
Naprosto v pořádku. Úplně stejně argumentují známí, kteří sympatizují s levicovými stranami. A nedokážou pochopit, když jim říkám, že nechci, aby mě stát vodil za ručičku, protože se umím vodit sám. Ale chtěl bych zdůraznit, že jsem prvotně reagoval na odpověď na Kitův komentář, v němž výslovně zmiňoval objektové jazyky. Nikdo tam po překladači nechce, aby něco takového hlídal, protože to je plně v kompetenci objektu.

Ano, je v kompetenci objektu, aby si pohlídal komunikaci s okolím. Když do té tašky na rohlíky přidám 10, tak to pochopí jako přidání 10 rohlíků. Když do ní přidám objekt (4 housky), tak přibudou 4 housky. Když budu chtít přidat litr točeného piva, tak vyhodí výjimku, protože do tašky na rohlíky se pivo točit nedá. Stačí mi k tomu jedna metoda, která si typy na vstupu ohlídá sama a obvykle lépe než typový systém.

- V dynamickém typování ti aplikace furt padá (ideálně na produkci), protože jsi nevychytal všechny chyby (nic ti nepomáhá).
Podobné předsudky jsem taky míval, dokud jsem v tom nezačal dělat. A, světe div se, žádné neustálé padání se nekoná. Přiznám se, že mě to samotného překvapilo, ale v dynamicky typovaných jazycích se vyvíjí trošku jinak - musíš u toho trochu změnit způsob uvažování. Ze začátku má člověk nutkání dopisovat typovou kontrolu ručně, ale to je ve skutečnosti antipattern. To platí třeba i v Pythonu (viz Idiomatic Python), ale třeba v takovém objektovém Smalltalku je to přímo do očí bijící. Prostě typová kontrola je také kompetence objektů. A ono to funguje, a velmi dobře!

Vidím jako významný rozdíl v tom, že ve staticky typovaných jazycích se vstupní data kontrolují před vstupem do objektu, ale v dynamicky typovaných jazycích až po vstupu do objektu. Pokud je takový objekt volán na 10 místech, který přístup je výhodnější?
Název: Re:Co si myslíte o OOP?
Přispěvatel: Kadet 05. 01. 2019, 18:22:42
Ve staticky typovanym jazyku se provede kontrola vstupnich dat nejen pred vstupem do funkce/objektu ale kdyz se dostatecne chytre oseka prostor typu vstupnich dat, da se matematicky dokazat validnost dat retezove. Tj. kdyz mi sedi vstupni data do moji funkce a vystup z my funkce sedi do nasledujici funkce v poradi, tak se transzitivne dokaze ze sedi celej program.

Problem je ze se musi provest mozkova lobotomie a intuitivni programy pro obycejnyho cloveka se musi nejak nacpat do toho osekanyho typovyho systemu. Obzvlast to boli u generik. Dynamickej jazyk mapuje lidskou intuici skoro presne do reseni problemu, u statickyho musi clovek provadet mentalni gymnastiku, nez svoji intuici nejak vmestna do ty omezeny svedsky bedny jmenem statickej typovej system.

Cim lepsi typovej system, tim min to boli samozrejme. Obzvlast kdyz novy typovy systemy jako Idris umoznujou typovy diry. Tj. dokud nevis co tam bude za typ, tak to preskocis a program prelozis i bez toho.

Problem je v tom ze skutecne pouzitelnej typovej system je zatim dost daleko v budoucnosti, proto vsichni radsi pouzivaji dynamicky jazyky. Nebo soucasny staticky jazyky pro skutecne jednoduchy programy, ktery jenom tahaji nejaky jasne specifikovany data sem a tam, zejmena pokud potrebujou vykon.

Vykon je lepsi u soucasnych mainstream statickych jazyku, protoze se daji prelozit do C ekvivalentu, tj. zhruba representace jak funguje CPU. Existujou i dynamicky jazyky ktery fungujou na vykonnostni urovni C. Dokonce ho i prekonavaji v dnesni dobe, kde se silne uvazuje s paralelnim vypoctem. Viz vektorovy jasyky APL family, obzvlast kdb, numpy, apod.
Název: Re:Co si myslíte o OOP?
Přispěvatel: uetoyo 05. 01. 2019, 18:35:21
Ve staticky typovanym jazyku se provede kontrola vstupnich dat nejen pred vstupem do funkce/objektu ale kdyz se dostatecne chytre oseka prostor typu vstupnich dat, da se matematicky dokazat validnost dat retezove. Tj. kdyz mi sedi vstupni data do moji funkce a vystup z my funkce sedi do nasledujici funkce v poradi, tak se transzitivne dokaze ze sedi celej program.

Problem je ze se musi provest mozkova lobotomie a intuitivni programy pro obycejnyho cloveka se musi nejak nacpat do toho osekanyho typovyho systemu. Obzvlast to boli u generik. Dynamickej jazyk mapuje lidskou intuici skoro presne do reseni problemu, u statickyho musi clovek provadet mentalni gymnastiku, nez svoji intuici nejak vmestna do ty omezeny svedsky bedny jmenem statickej typovej system.

Cim lepsi typovej system, tim min to boli samozrejme. Obzvlast kdyz novy typovy systemy jako Idris umoznujou typovy diry. Tj. dokud nevis co tam bude za typ, tak to preskocis a program prelozis i bez toho.

Problem je v tom ze skutecne pouzitelnej typovej system je zatim dost daleko v budoucnosti, proto vsichni radsi pouzivaji dynamicky jazyky. Nebo soucasny staticky jazyky pro skutecne jednoduchy programy, ktery jenom tahaji nejaky jasne specifikovany data sem a tam, zejmena pokud potrebujou vykon.

Vykon je lepsi u soucasnych mainstream statickych jazyku, protoze se daji prelozit do C ekvivalentu, tj. zhruba representace jak funguje CPU. Existujou i dynamicky jazyky ktery fungujou na vykonnostni urovni C. Dokonce ho i prekonavaji v dnesni dobe, kde se silne uvazuje s paralelnim vypoctem. Viz vektorovy jasyky APL family, obzvlast kdb, numpy, apod.
Numpy? To myslíš tu Python knihovnu napsanou v C? ???
Název: Re:Co si myslíte o OOP?
Přispěvatel: Kadet 05. 01. 2019, 19:11:52
Ve staticky typovanym jazyku se provede kontrola vstupnich dat nejen pred vstupem do funkce/objektu ale kdyz se dostatecne chytre oseka prostor typu vstupnich dat, da se matematicky dokazat validnost dat retezove. Tj. kdyz mi sedi vstupni data do moji funkce a vystup z my funkce sedi do nasledujici funkce v poradi, tak se transzitivne dokaze ze sedi celej program.

Problem je ze se musi provest mozkova lobotomie a intuitivni programy pro obycejnyho cloveka se musi nejak nacpat do toho osekanyho typovyho systemu. Obzvlast to boli u generik. Dynamickej jazyk mapuje lidskou intuici skoro presne do reseni problemu, u statickyho musi clovek provadet mentalni gymnastiku, nez svoji intuici nejak vmestna do ty omezeny svedsky bedny jmenem statickej typovej system.

Cim lepsi typovej system, tim min to boli samozrejme. Obzvlast kdyz novy typovy systemy jako Idris umoznujou typovy diry. Tj. dokud nevis co tam bude za typ, tak to preskocis a program prelozis i bez toho.

Problem je v tom ze skutecne pouzitelnej typovej system je zatim dost daleko v budoucnosti, proto vsichni radsi pouzivaji dynamicky jazyky. Nebo soucasny staticky jazyky pro skutecne jednoduchy programy, ktery jenom tahaji nejaky jasne specifikovany data sem a tam, zejmena pokud potrebujou vykon.

Vykon je lepsi u soucasnych mainstream statickych jazyku, protoze se daji prelozit do C ekvivalentu, tj. zhruba representace jak funguje CPU. Existujou i dynamicky jazyky ktery fungujou na vykonnostni urovni C. Dokonce ho i prekonavaji v dnesni dobe, kde se silne uvazuje s paralelnim vypoctem. Viz vektorovy jasyky APL family, obzvlast kdb, numpy, apod.
Numpy? To myslíš tu Python knihovnu napsanou v C? ???

Chapu tvoji pomatenost, ale rad vysvetlim.
Vzdycky operujes s vrstvami hardware a software. Hardware = stavebni bloky, software = staveni, neboli aplikace

Kdyz delas v C, tak volas hardwarovy funkce, napr. scitani nebo deleni cisel jako instrukci na CPU. Samozrejme bys to moh napsat primo v C pomoci treba Church numerals nebo deleni jako long division, ale radsi zavolas optimalizovanou hardware instrukci.

Podobne kdyz delas v jazyku vyssi abstraktni urovne, jako napr. volani funkci numpy v pythonu, je to stejny. Numoy je pro tebe hardware, tj. stavebni bloky, a ty je jen skladas dohromady. Je pak jedno jestli jsou stavebni bloky napsany v C nebo implementovany jako hardware. Viz neuronovy procesory v posledni dobr
Název: Re:Co si myslíte o OOP?
Přispěvatel: Kit 05. 01. 2019, 19:15:28
Teoreticky. Prakticky treba kdyz mas getXs(), tak podle typu vis, zda mohou byt xka duplicitni (list vs. set).
K čemu potřebuješ rozlišovat list vs. text? Dostaneš kolekci a budeš s ní tak i pracovat.
On je tam trochu sémantický rozdíl, víme? A z toho typu vysloveně svítí.
Sémantický rozdíl nevidím. Seznam autorů nebo množina autorů? Pro mne je to kolekce autorů a budu s ní pracovat tak, aby když někdo vymění list za set, mi to mohlo být jedno.
Pokud ti není jasný rozdíl mezi sémantikou listu a setu, tak je asi problém na tvém přijímači.

(Btw zrovna tady máš ještě o problém navíc, protože se rozlišuje první autor, korespondující autor...)

Kód: [Vybrat]
#!/usr/bin/env python
# -*- coding: utf-8 -*-

def vypis(kolekce):
    print(type(kolekce))
    for i in kolekce:
        print(i)
    print()

seznam = ["Alfa", 42, 42, ("Beta", "Gamma")]
mnozina = {"Alfa", 42, 42, ("Beta", "Gamma")}
vypis(seznam)
vypis(mnozina)

Jak vidíš, tak proceduře vypis() je v daném případě jedno, zda jí předhodíš seznam nebo množinu. Vypíše obojí. Pokud je budu potřebovat rozlišit, stále ještě mohu použít reflexi.
Název: Re:Co si myslíte o OOP?
Přispěvatel: Ondra Satai Nekola 05. 01. 2019, 20:54:04
Teoreticky. Prakticky treba kdyz mas getXs(), tak podle typu vis, zda mohou byt xka duplicitni (list vs. set).
K čemu potřebuješ rozlišovat list vs. text? Dostaneš kolekci a budeš s ní tak i pracovat.
On je tam trochu sémantický rozdíl, víme? A z toho typu vysloveně svítí.
Sémantický rozdíl nevidím. Seznam autorů nebo množina autorů? Pro mne je to kolekce autorů a budu s ní pracovat tak, aby když někdo vymění list za set, mi to mohlo být jedno.
Pokud ti není jasný rozdíl mezi sémantikou listu a setu, tak je asi problém na tvém přijímači.

(Btw zrovna tady máš ještě o problém navíc, protože se rozlišuje první autor, korespondující autor...)

Kód: [Vybrat]
#!/usr/bin/env python
# -*- coding: utf-8 -*-

def vypis(kolekce):
    print(type(kolekce))
    for i in kolekce:
        print(i)
    print()

seznam = ["Alfa", 42, 42, ("Beta", "Gamma")]
mnozina = {"Alfa", 42, 42, ("Beta", "Gamma")}
vypis(seznam)
vypis(mnozina)

Jak vidíš, tak proceduře vypis() je v daném případě jedno, zda jí předhodíš seznam nebo množinu. Vypíše obojí. Pokud je budu potřebovat rozlišit, stále ještě mohu použít reflexi.

Jasne. Existuji situace, kdy je to jedno (a v nich ti nic nebrani pouzit neco jak Iterable). A (drz se!) jsou situace, kdy to jedno neni. Pokud je chces resit jako prase... tak je res jako prase.
Název: Re:Co si myslíte o OOP?
Přispěvatel: Kit 05. 01. 2019, 21:40:20
Jak vidíš, tak proceduře vypis() je v daném případě jedno, zda jí předhodíš seznam nebo množinu. Vypíše obojí. Pokud je budu potřebovat rozlišit, stále ještě mohu použít reflexi.
Jasne. Existuji situace, kdy je to jedno (a v nich ti nic nebrani pouzit neco jak Iterable). A (drz se!) jsou situace, kdy to jedno neni. Pokud je chces resit jako prase... tak je res jako prase.

Správně jsi poznal, že seznam i množina jsou Iterable, což je přesně to, o co mi šlo. Ukázal jsem příklad, kde je výhodné použití polymorfismu. Velmi dobře vím, že jsou situace, kdy to jedno není, ale o tom ten příklad není. Místo striktně defenzivního přístupu použiji takový, který je v daném případě výhodnější. Uvedeným postupem docílím mnohem volnějších závislostí mezi objekty, což je silně žádoucí. Mohu je tak poměrně jednoduše zaměňovat. Jestli je to styl na prase, tak programuji jako prase - ale objektově.

V Javě bych v deklaraci formálního parametru použil Iterable<Object>. Takže vlastně stejně, jen o pár zbytečných znaků navíc.

Pokud by byl problém s množinou, mohu ji klidně přetypovat na seznam při volání procedury nebo až uvnitř.
Kód: [Vybrat]
vypis(list(seznam))
vypis(list(mnozina))

# nebo uvnitř vypis()
    seznam = list(kolekce)
Název: Re:Co si myslíte o OOP?
Přispěvatel: MartinBeran 05. 01. 2019, 21:47:08
Kód: [Vybrat]
#!/usr/bin/env python
# -*- coding: utf-8 -*-

def vypis(kolekce):
    print(type(kolekce))
    for i in kolekce:
        print(i)
    print()

seznam = ["Alfa", 42, 42, ("Beta", "Gamma")]
mnozina = {"Alfa", 42, 42, ("Beta", "Gamma")}
vypis(seznam)
vypis(mnozina)

Jak vidíš, tak proceduře vypis() je v daném případě jedno, zda jí předhodíš seznam nebo množinu. Vypíše obojí. Pokud je budu potřebovat rozlišit, stále ještě mohu použít reflexi.

Tento příklad krásně ilustruje problém dynamicky typovaných jazyků. Procedura vypis() implicitně předpokládá, že parametr kolekce se dá iterovat a že iterací dostanu objekty, pro které má smysl volat print(). Když nebudou splněny obě tyto podmínky, funkce havaruje. Pravděpodobně vyhodí nějakou výjimku, kterou buď očekávám a musím na ni nějak zareagovat, nebo výjimka shodí celý program. Kdybych se chtěl výjimce vyhnout, musel bych v kódu nějak ošetřit chování funkce pro všechny typy, které nejsou "iterable<printable>". Ovšem ze zadání může plynout, že nemá smysl volat vypis() na takové typy. Ve staticky typovaném jazyce bych jednoduše přidal parametru kolekce typ iterable<printable> a mohl bych se spolehnout, že případné chyby odhalí kompilátor při překladu. V dynamicky typovaném jazyce můžu tento požadavek tak akorát napsat do dokumentace a případně doufat, že na každé použití této funkce někdo napíše test, že se v tom kokrétním místě vždy volá se správným typem.
Název: Re:Co si myslíte o OOP?
Přispěvatel: MartinBeran 05. 01. 2019, 21:57:16
V Javě bych v deklaraci formálního parametru použil Iterable<Object>. Takže vlastně stejně, jen o pár zbytečných znaků navíc.

Těch "pár zbytečných znaků navíc" definuje kontrakt mezi autorem a uživatelem funkce, který zajistí, že funkce nepůjde zavolat s parametrem, pro který nemá smysl. Jako bonus je tento kontrakt automaticky dokumentován. Navíc, kdyby se každý Object neuměl vypsat, kompilátor na to autora funkce upozorní a donutí opravit typ na něco jako Iterable<Printable>.
Název: Re:Co si myslíte o OOP?
Přispěvatel: Honza 05. 01. 2019, 22:06:46
Tento příklad krásně ilustruje problém dynamicky typovaných jazyků. Procedura vypis() implicitně předpokládá, že parametr kolekce se dá iterovat a že iterací dostanu objekty, pro které má smysl volat print().
Toto není problém dynamicky typovaných jazyků, ale pouze tohoto příkladu. Navíc je to napsané spíš strukturovaně, než s OOP.
V OOP by pro výpis sloužila samostatná třída (nějaký Printer), s pomocí návrhového vzoru Visitor by si implementovala sama tu metodu print(), nebo by ji delegovala na ty prvky, u kterých to potřebuji. Navíc ve skutečnosti vůbec nemusí záležet na tom, zda chci vypsat kolekci, prvek, a nebo třeba rekurzivně nějaký Composite
Název: Re:Co si myslíte o OOP?
Přispěvatel: Kit 05. 01. 2019, 22:15:27
Tento příklad krásně ilustruje problém dynamicky typovaných jazyků. Procedura vypis() implicitně předpokládá, že parametr kolekce se dá iterovat a že iterací dostanu objekty, pro které má smysl volat print(). Když nebudou splněny obě tyto podmínky, funkce havaruje. Pravděpodobně vyhodí nějakou výjimku, kterou buď očekávám a musím na ni nějak zareagovat, nebo výjimka shodí celý program. Kdybych se chtěl výjimce vyhnout, musel bych v kódu nějak ošetřit chování funkce pro všechny typy, které nejsou "iterable<printable>". Ovšem ze zadání může plynout, že nemá smysl volat vypis() na takové typy. Ve staticky typovaném jazyce bych jednoduše přidal parametru kolekce typ iterable<printable> a mohl bych se spolehnout, že případné chyby odhalí kompilátor při překladu. V dynamicky typovaném jazyce můžu tento požadavek tak akorát napsat do dokumentace a případně doufat, že na každé použití této funkce někdo napíše test, že se v tom kokrétním místě vždy volá se správným typem.

Jistě, uvedený příklad nemá ošetřen vstup, protože pro demonstrační účely je nepotřebuje. V reálu jsou před výkonnou částí procedury nejen typové kontroly, ale i další validace s případným vyhozením výjimky. Záleží na specifikaci požadavku, zda a v jaké míře je taková validace účelná. Pokud se připouští, že na vstupu bude třeba int nebo string, procedura s tím musí počítat. U staticky typovaných jazyků by přibyly další dvě přetížené metody. Pak do té metody někdo bude chtít strčit float...

Statické typy nepřipouští, že bych tu proceduru mohl chtít volat s hodnotou jiného typu, než jaký je uveden ve formálním parametru. Považuji to za chybu. V dynamicky typovaném jazyce mohu předat i hodnotu, která není iterable a procedura si s tím poradí. Je to její starost.
Název: Re:Co si myslíte o OOP?
Přispěvatel: Ondra Satai Nekola 05. 01. 2019, 22:16:35
Tento příklad krásně ilustruje problém dynamicky typovaných jazyků. Procedura vypis() implicitně předpokládá, že parametr kolekce se dá iterovat a že iterací dostanu objekty, pro které má smysl volat print(). Když nebudou splněny obě tyto podmínky, funkce havaruje. Pravděpodobně vyhodí nějakou výjimku, kterou buď očekávám a musím na ni nějak zareagovat, nebo výjimka shodí celý program. Kdybych se chtěl výjimce vyhnout, musel bych v kódu nějak ošetřit chování funkce pro všechny typy, které nejsou "iterable<printable>". Ovšem ze zadání může plynout, že nemá smysl volat vypis() na takové typy. Ve staticky typovaném jazyce bych jednoduše přidal parametru kolekce typ iterable<printable> a mohl bych se spolehnout, že případné chyby odhalí kompilátor při překladu. V dynamicky typovaném jazyce můžu tento požadavek tak akorát napsat do dokumentace a případně doufat, že na každé použití této funkce někdo napíše test, že se v tom kokrétním místě vždy volá se správným typem.

Jistě, uvedený příklad nemá ošetřen vstup, protože pro demonstrační účely je nepotřebuje. V reálu jsou před výkonnou částí procedury nejen typové kontroly, ale i další validace s případným vyhozením výjimky. Záleží na specifikaci požadavku, zda a v jaké míře je taková validace účelná. Pokud se připouští, že na vstupu bude třeba int nebo string, procedura s tím musí počítat. U staticky typovaných jazyků by přibyly další dvě přetížené metody. Pak do té metody někdo bude chtít strčit float...

Statické typy nepřipouští, že bych tu proceduru mohl chtít volat s hodnotou jiného typu, než jaký je uveden ve formálním parametru. Považuji to za chybu. V dynamicky typovaném jazyce mohu předat i hodnotu, která není iterable a procedura si s tím poradí. Je to její starost.

Jinymi slovy udelas vic prace, ale vysledek je mene bezpecny.
Název: Re:Co si myslíte o OOP?
Přispěvatel: Ondra Satai Nekola 05. 01. 2019, 22:17:38
Jak vidíš, tak proceduře vypis() je v daném případě jedno, zda jí předhodíš seznam nebo množinu. Vypíše obojí. Pokud je budu potřebovat rozlišit, stále ještě mohu použít reflexi.
Jasne. Existuji situace, kdy je to jedno (a v nich ti nic nebrani pouzit neco jak Iterable). A (drz se!) jsou situace, kdy to jedno neni. Pokud je chces resit jako prase... tak je res jako prase.

Správně jsi poznal, že seznam i množina jsou Iterable, což je přesně to, o co mi šlo. Ukázal jsem příklad, kde je výhodné použití polymorfismu. Velmi dobře vím, že jsou situace, kdy to jedno není, ale o tom ten příklad není. Místo striktně defenzivního přístupu použiji takový, který je v daném případě výhodnější. Uvedeným postupem docílím mnohem volnějších závislostí mezi objekty, což je silně žádoucí. Mohu je tak poměrně jednoduše zaměňovat. Jestli je to styl na prase, tak programuji jako prase - ale objektově.

V Javě bych v deklaraci formálního parametru použil Iterable<Object>. Takže vlastně stejně, jen o pár zbytečných znaků navíc.

Pokud by byl problém s množinou, mohu ji klidně přetypovat na seznam při volání procedury nebo až uvnitř.
Kód: [Vybrat]
vypis(list(seznam))
vypis(list(mnozina))

# nebo uvnitř vypis()
    seznam = list(kolekce)

Jenomze o ten polymorfismus bys neprisel ani se statickym typovanim.
Název: Re:Co si myslíte o OOP?
Přispěvatel: Ondra Satai Nekola 05. 01. 2019, 22:18:36
Kód: [Vybrat]
#!/usr/bin/env python
# -*- coding: utf-8 -*-

def vypis(kolekce):
    print(type(kolekce))
    for i in kolekce:
        print(i)
    print()

seznam = ["Alfa", 42, 42, ("Beta", "Gamma")]
mnozina = {"Alfa", 42, 42, ("Beta", "Gamma")}
vypis(seznam)
vypis(mnozina)

Jak vidíš, tak proceduře vypis() je v daném případě jedno, zda jí předhodíš seznam nebo množinu. Vypíše obojí. Pokud je budu potřebovat rozlišit, stále ještě mohu použít reflexi.

Tento příklad krásně ilustruje problém dynamicky typovaných jazyků. Procedura vypis() implicitně předpokládá, že parametr kolekce se dá iterovat a že iterací dostanu objekty, pro které má smysl volat print(). Když nebudou splněny obě tyto podmínky, funkce havaruje. Pravděpodobně vyhodí nějakou výjimku, kterou buď očekávám a musím na ni nějak zareagovat, nebo výjimka shodí celý program. Kdybych se chtěl výjimce vyhnout, musel bych v kódu nějak ošetřit chování funkce pro všechny typy, které nejsou "iterable<printable>". Ovšem ze zadání může plynout, že nemá smysl volat vypis() na takové typy. Ve staticky typovaném jazyce bych jednoduše přidal parametru kolekce typ iterable<printable> a mohl bych se spolehnout, že případné chyby odhalí kompilátor při překladu. V dynamicky typovaném jazyce můžu tento požadavek tak akorát napsat do dokumentace a případně doufat, že na každé použití této funkce někdo napíše test, že se v tom kokrétním místě vždy volá se správným typem.

To dava na Kida moc velky smysl. To neprojde :-/
Název: Re:Co si myslíte o OOP?
Přispěvatel: paranoik 05. 01. 2019, 22:23:09
Toto není problém dynamicky typovaných jazyků, ale pouze tohoto příkladu.

Toto je problém dynamicky typovaných jazyků. Ve staticky typovaném jazyce můžeš napsat vypis jako generickou funkci a dostaneš naprosto stejnou funkcionalitu jaku v pythonu. Když tu funkci píšeš, nemusíš znát konkrétní typ. Jako bonus navíc máš typovou kontrolu během překladu, funce vypis nepujde zavolat s nečím, co není iterable a printable a v runtime to bude rychlejší než dynamicky typovaný jazyk, protože v runtime se už žádné typové kontroly dělat nemusí.
Název: Re:Co si myslíte o OOP?
Přispěvatel: Kit 05. 01. 2019, 22:24:58
Tento příklad krásně ilustruje problém dynamicky typovaných jazyků. Procedura vypis() implicitně předpokládá, že parametr kolekce se dá iterovat a že iterací dostanu objekty, pro které má smysl volat print().
Toto není problém dynamicky typovaných jazyků, ale pouze tohoto příkladu. Navíc je to napsané spíš strukturovaně, než s OOP.
V OOP by pro výpis sloužila samostatná třída (nějaký Printer), s pomocí návrhového vzoru Visitor by si implementovala sama tu metodu print(), nebo by ji delegovala na ty prvky, u kterých to potřebuji. Navíc ve skutečnosti vůbec nemusí záležet na tom, zda chci vypsat kolekci, prvek, a nebo třeba rekurzivně nějaký Composite

Na příkladu jsem použil Occamovu břitvu, abych ukázal principy, které pochopí i propagátoři statického typování. Bylo by zbytečné ji obalovat nějakými plechy na bojlery.

V OOP vůbec není potřebné, aby se o výpis staraly nějaké další třídy. Stačí, když se budeme držet SOLID.
Název: Re:Co si myslíte o OOP?
Přispěvatel: Kit 05. 01. 2019, 22:29:46
Toto není problém dynamicky typovaných jazyků, ale pouze tohoto příkladu.

Toto je problém dynamicky typovaných jazyků. Ve staticky typovaném jazyce můžeš napsat vypis jako generickou funkci a dostaneš naprosto stejnou funkcionalitu jaku v pythonu. Když tu funkci píšeš, nemusíš znát konkrétní typ. Jako bonus navíc máš typovou kontrolu během překladu, funce vypis nepujde zavolat s nečím, co není iterable a printable a v runtime to bude rychlejší než dynamicky typovaný jazyk, protože v runtime se už žádné typové kontroly dělat nemusí.

Generika jsou pouze berličkou, aby se ve staticky typovaných jazycích dalo dělat totéž co v dynamicky typovaných. Stále však budu chtít zavolat tu proceduru třeba se stringem.

Rychlost je dobrý důvod, proč používat staticky typované jazyky. Ovšem které? Java ani C# mezi ně nepatří.
Název: Re:Co si myslíte o OOP?
Přispěvatel: paranoik 05. 01. 2019, 22:39:08
Generika jsou pouze berličkou, aby se ve staticky typovaných jazycích dalo dělat totéž co v dynamicky typovaných. Stále však budu chtít zavolat tu proceduru třeba se stringem.

Znovu opakuji, když to napíšeš jako generickou funkci ve staticky typovaném jazyce, získáš navíc typovou kontrolu během překladu a vyšší výkon. Se stringem to půjde zavolat taky.

Dynamické typování v tomto případě nemá žádnou výhodu. Bude to pomalejší a na chyby v programu se přijde až v runtime, kdy to celé spadne. Tvoje zásadní neznalosti vedou k tomu, že nedokážeš rozlišit, kdy a na co je kterou technologii vhodné použít.
Název: Re:Co si myslíte o OOP?
Přispěvatel: MartinBeran 05. 01. 2019, 22:42:55
Tento příklad krásně ilustruje problém dynamicky typovaných jazyků. Procedura vypis() implicitně předpokládá, že parametr kolekce se dá iterovat a že iterací dostanu objekty, pro které má smysl volat print().
Toto není problém dynamicky typovaných jazyků, ale pouze tohoto příkladu. Navíc je to napsané spíš strukturovaně, než s OOP.
V OOP by pro výpis sloužila samostatná třída (nějaký Printer), s pomocí návrhového vzoru Visitor by si implementovala sama tu metodu print(), nebo by ji delegovala na ty prvky, u kterých to potřebuji. Navíc ve skutečnosti vůbec nemusí záležet na tom, zda chci vypsat kolekci, prvek, a nebo třeba rekurzivně nějaký Composite

Zrovna print() není úplně dobrý příklad, protože "nějak smysluplně vypsat" se dají vypsat hodnoty libovolného typu. Ale třeba get_peer_address() má jistě smysl pro třídu network_socket. Hůř se ale bude hledat význam takové funkce pro string nebo int a s tím mi nepomůže, když tu funkci přesunu do samostatné třídy address_extractor. Jde mi o to, že některé operace nemají pro nějaké typy smysl, buď obecně nebo v kontextu konkrétního řešeného problému. Jakákoliv runtime reakce na volání takové operace s nevhodným typem argumentu je špatně, protože v prvé řadě nemělo dojít k tomu zavolání. Tedy jedná se o chybu v programu, kterou je nutno řešit úpravou kódu. Statické typování mi takovou chybu odhalí včas a bez toho, abych musel kvůli diagnostice psát víc, než jméno typu.
Název: Re:Co si myslíte o OOP?
Přispěvatel: Kit 05. 01. 2019, 22:46:17
Dynamické typování v tomto případě nemá žádnou výhodu. Bude to pomalejší a na chyby v programu se přijde až v runtime, kdy to celé spadne.

Při chybě v programu to spadne už v testech - stejně jako při statickém typování.
Název: Re:Co si myslíte o OOP?
Přispěvatel: paranoik 05. 01. 2019, 22:50:41
Při chybě v programu to spadne už v testech - stejně jako při statickém typování.

Při statickém typování to nepůjde vůbec přeložit, chybu zjistíš ještě dřív, než napíšeš jedinou řádku testů.
Název: Re:Co si myslíte o OOP?
Přispěvatel: Ondra Satai Nekola 05. 01. 2019, 22:53:46
Dynamické typování v tomto případě nemá žádnou výhodu. Bude to pomalejší a na chyby v programu se přijde až v runtime, kdy to celé spadne.

Při chybě v programu to spadne už v testech - stejně jako při statickém typování.

Pokud máš plné pokrytí. Za předpokladu jedné unity.

Pokud píšeš libku nebo nedejte bozi framework, tak se ti tohle ještě dál komplikuje...
Název: Re:Co si myslíte o OOP?
Přispěvatel: BaldSlattery 05. 01. 2019, 22:55:58
Teoreticky. Prakticky treba kdyz mas getXs(), tak podle typu vis, zda mohou byt xka duplicitni (list vs. set).
K čemu potřebuješ rozlišovat list vs. text? Dostaneš kolekci a budeš s ní tak i pracovat.
On je tam trochu sémantický rozdíl, víme? A z toho typu vysloveně svítí.
Sémantický rozdíl nevidím. Seznam autorů nebo množina autorů? Pro mne je to kolekce autorů a budu s ní pracovat tak, aby když někdo vymění list za set, mi to mohlo být jedno.
Pokud ti není jasný rozdíl mezi sémantikou listu a setu, tak je asi problém na tvém přijímači.

(Btw zrovna tady máš ještě o problém navíc, protože se rozlišuje první autor, korespondující autor...)

Kód: [Vybrat]
#!/usr/bin/env python
# -*- coding: utf-8 -*-

def vypis(kolekce):
    print(type(kolekce))
    for i in kolekce:
        print(i)
    print()

seznam = ["Alfa", 42, 42, ("Beta", "Gamma")]
mnozina = {"Alfa", 42, 42, ("Beta", "Gamma")}
vypis(seznam)
vypis(mnozina)
Jak vidíš, tak proceduře vypis() je v daném případě jedno, zda jí předhodíš seznam nebo množinu. Vypíše obojí. Pokud je budu potřebovat rozlišit, stále ještě mohu použít reflexi.
Jde-li jen o (úsporný) zápis, tak v C++ to jde stejně jednoduše (bez explicitních typů):
Kód: [Vybrat]
auto printElements(auto coll) {
  for (auto el : coll) {
    std::cout << el << std::endl;
  }
}

int main() {
  std::vector<int> v{1, 2, 3};
  printElements(v);
  std::set<int> s{4, 5, 6};
  printElements(s);
  printElements("abc"s);
}
Ještě nějaký jiný problém s typy?
Název: Re:Co si myslíte o OOP?
Přispěvatel: Honza 05. 01. 2019, 22:56:56
Při chybě v programu to spadne už v testech - stejně jako při statickém typování.

Při statickém typování to nepůjde vůbec přeložit, chybu zjistíš ještě dřív, než napíšeš jedinou řádku testů.

Tohle je tady mylně považováno za výhodu statických jazyků, ale ten program nepůjde přeložit vůbec úplně celý.
Přitom v dynamickém jazyce mi ta hotová část programu může už dávno běžet...
Název: Re:Co si myslíte o OOP?
Přispěvatel: MartinBeran 05. 01. 2019, 23:01:10
Generika jsou pouze berličkou, aby se ve staticky typovaných jazycích dalo dělat totéž co v dynamicky typovaných.

Tahle věta platí pro třídu Object v Javě, nebo void* a makra v C. Naopak generika v Javě nebo šablony v C++ přidávají něco navíc - možnost definovat chování nějaké třídy, jejíž objekty se nějakým způsobem starají o objekty jiných tříd (typický příklad jsou kolekce nebo chytré ukazatele), bez znalosti typu vnitřních objektů, ale zároveň při použití takové generické třídy mít možnost omezit, co může obsahovat. Je to přesně jako v tom příkladu s Iterable<Printable> versus Iterable<Object>, mám kolekci objektů, jejíž implementace procházení obsažených objektů nezávisí na typu obsažených objektů, ale chci vynutit (staticky v době překladu), že při konkrétním použití budou ty obsažené objekty něco umět.
Název: Re:Co si myslíte o OOP?
Přispěvatel: Ondra Satai Nekola 05. 01. 2019, 23:03:14
Při chybě v programu to spadne už v testech - stejně jako při statickém typování.

Při statickém typování to nepůjde vůbec přeložit, chybu zjistíš ještě dřív, než napíšeš jedinou řádku testů.

Tohle je tady mylně považováno za výhodu statických jazyků, ale ten program nepůjde přeložit vůbec úplně celý.
Přitom v dynamickém jazyce mi ta hotová část programu může už dávno běžet...

A na to jsi přišel jak?
Název: Re:Co si myslíte o OOP?
Přispěvatel: DotNetGuy 05. 01. 2019, 23:03:42
Kite, už nikdy nezmiňuj Javu, ale místo ní C#. Vytlučem jí Linuxákum z hlavy a všichni budou používat C#.

Jinak, nechápu proč se tu furt dokola omílá statický vs dynamický typování.

Dynamické typování v tomto případě nemá žádnou výhodu. Bude to pomalejší a na chyby v programu se přijde až v runtime, kdy to celé spadne.

Přesně to jsem chtěl napsat. Statickym typovánim nic nezkazíš a nechápu, proč se mu někteří tak brání. Dynamický tě může (ale nemusí) rychle přivést do problémů a navíc žere výkon.
Název: Re:Co si myslíte o OOP?
Přispěvatel: Honza 05. 01. 2019, 23:05:09
Tento příklad krásně ilustruje problém dynamicky typovaných jazyků. Procedura vypis() implicitně předpokládá, že parametr kolekce se dá iterovat a že iterací dostanu objekty, pro které má smysl volat print().
Toto není problém dynamicky typovaných jazyků, ale pouze tohoto příkladu. Navíc je to napsané spíš strukturovaně, než s OOP.
V OOP by pro výpis sloužila samostatná třída (nějaký Printer), s pomocí návrhového vzoru Visitor by si implementovala sama tu metodu print(), nebo by ji delegovala na ty prvky, u kterých to potřebuji. Navíc ve skutečnosti vůbec nemusí záležet na tom, zda chci vypsat kolekci, prvek, a nebo třeba rekurzivně nějaký Composite

Zrovna print() není úplně dobrý příklad, protože "nějak smysluplně vypsat" se dají vypsat hodnoty libovolného typu. Ale třeba get_peer_address() má jistě smysl pro třídu network_socket. Hůř se ale bude hledat význam takové funkce pro string nebo int a s tím mi nepomůže, když tu funkci přesunu do samostatné třídy address_extractor.

Tak částečně souhlas, ale ta samostatná třída pomůže v jiné věci. Můžu chtít vypsat totéž několika způsoby. K tomu ale nebudu mít metody print1, print2, print3...

Ale šlo mi o trochu něco jiného. Dávají se sem nějaké příklady, a na jejich základě se pak hodnotí obecně celá rodina programovacích jazyků... V takovém případě by ty příklady musely vypadat hodně jinak!
Název: Re:Co si myslíte o OOP?
Přispěvatel: Kit 05. 01. 2019, 23:11:04
... Ale třeba get_peer_address() má jistě smysl pro třídu network_socket. Hůř se ale bude hledat význam takové funkce pro string nebo int a s tím mi nepomůže, když tu funkci přesunu do samostatné třídy address_extractor. Jde mi o to, že některé operace nemají pro nějaké typy smysl, buď obecně nebo v kontextu konkrétního řešeného problému. Jakákoliv runtime reakce na volání takové operace s nevhodným typem argumentu je špatně, protože v prvé řadě nemělo dojít k tomu zavolání. Tedy jedná se o chybu v programu, kterou je nutno řešit úpravou kódu. Statické typování mi takovou chybu odhalí včas a bez toho, abych musel kvůli diagnostice psát víc, než jméno typu.

get_peer_address() má jako parametr int32, string nebo je to jedno? Návratová hodnota je big endian nebo little endian? Pro diagnostiku musíš psát i testy. Co když dostaneš 0.0.0.0 nebo 255.255.255.255? Bude to v pořádku?
Název: Re:Co si myslíte o OOP?
Přispěvatel: Honza 05. 01. 2019, 23:12:40
Při chybě v programu to spadne už v testech - stejně jako při statickém typování.

Při statickém typování to nepůjde vůbec přeložit, chybu zjistíš ještě dřív, než napíšeš jedinou řádku testů.

Tohle je tady mylně považováno za výhodu statických jazyků, ale ten program nepůjde přeložit vůbec úplně celý.
Přitom v dynamickém jazyce mi ta hotová část programu může už dávno běžet...

A na to jsi přišel jak?
Je tu stále stejná skupina diskutujících. A tak jsem si dovolil představit si ten dokonalý statický typový systém, který nepotřebuje unit testy, a který se píše od začátku do konce na čisto, kdy až na konci se povede celý zkompilovat, což znamená, že je správně, a rovnou se posílá na produkci...  ;D  ;D (jen trocha ironie)
Název: Re:Co si myslíte o OOP?
Přispěvatel: MartinBeran 05. 01. 2019, 23:15:24
Při chybě v programu to spadne už v testech - stejně jako při statickém typování.

Při statickém typování to nepůjde vůbec přeložit, chybu zjistíš ještě dřív, než napíšeš jedinou řádku testů.

Tohle je tady mylně považováno za výhodu statických jazyků, ale ten program nepůjde přeložit vůbec úplně celý.
Přitom v dynamickém jazyce mi ta hotová část programu může už dávno běžet...

To je zcela zásadní výhoda statických jazyků. O tom, že  to není omyl, svědčí i všechny ty snahy naroubovat statickou typovou kontrolu na původně dynamicky typované jazyky. A zatímco opravuji kód, aby prošla typová kontrola, hotová část programu, tedy předchozí zkompilovatelná, odladěná, otestovaná a v mém oblíbeném VCS uložená verze, už dávno běží v produkčním nasazení. A já se přitom nemusím bát, že se z nějakého podivného důvodu do nějaké pomocné funkce, která normálně dostává řetězce a volá na ně clear(), dostane jako parametr handle k databázi :)
Název: Re:Co si myslíte o OOP?
Přispěvatel: Kit 05. 01. 2019, 23:16:56
Při chybě v programu to spadne už v testech - stejně jako při statickém typování.
Při statickém typování to nepůjde vůbec přeložit, chybu zjistíš ještě dřív, než napíšeš jedinou řádku testů.

Nejprve se píší testy a teprve když neprojdou, píše se program.
Název: Re:Co si myslíte o OOP?
Přispěvatel: MartinBeran 05. 01. 2019, 23:25:00
... Ale třeba get_peer_address() má jistě smysl pro třídu network_socket. Hůř se ale bude hledat význam takové funkce pro string nebo int a s tím mi nepomůže, když tu funkci přesunu do samostatné třídy address_extractor. Jde mi o to, že některé operace nemají pro nějaké typy smysl, buď obecně nebo v kontextu konkrétního řešeného problému. Jakákoliv runtime reakce na volání takové operace s nevhodným typem argumentu je špatně, protože v prvé řadě nemělo dojít k tomu zavolání. Tedy jedná se o chybu v programu, kterou je nutno řešit úpravou kódu. Statické typování mi takovou chybu odhalí včas a bez toho, abych musel kvůli diagnostice psát víc, než jméno typu.

get_peer_address() má jako parametr int32, string nebo je to jedno? Návratová hodnota je big endian nebo little endian? Pro diagnostiku musíš psát i testy. Co když dostaneš 0.0.0.0 nebo 255.255.255.255? Bude to v pořádku?

Funkce get_peer_address() je buď metoda třídy network_socket bez parametrů, nebo je to samostatná funkce (nebo klidně metoda třídy address_extractor) s jedním parametrem typu network_socket. Návratová hodnota je typu socket_address, což je polymorfní typ zahrnující IPv4, IPv6 i řetězce (používané jako jména UNIX domain socketů). Všechny tyhle informace jsou explicitně napsané ve zdrojáku, z něj se automaticky přenesou do dokumentace (např. v C++ pomocí Doxygenu), a to všechno bez nutnosti napsat jediné slovo komentáře a jediný test zjišťující, zda se předávají nebo vrací hodnoty správných typů. Testy už píšu jen na ověření chování této funkce se smysluplnými typy parametrů.
Název: Re:Co si myslíte o OOP?
Přispěvatel: Kit 05. 01. 2019, 23:27:03
Při chybě v programu to spadne už v testech - stejně jako při statickém typování.
Při statickém typování to nepůjde vůbec přeložit, chybu zjistíš ještě dřív, než napíšeš jedinou řádku testů.
Tohle je tady mylně považováno za výhodu statických jazyků, ale ten program nepůjde přeložit vůbec úplně celý.
Přitom v dynamickém jazyce mi ta hotová část programu může už dávno běžet...
To je zcela zásadní výhoda statických jazyků. O tom, že  to není omyl, svědčí i všechny ty snahy naroubovat statickou typovou kontrolu na původně dynamicky typované jazyky. A zatímco opravuji kód, aby prošla typová kontrola, hotová část programu, tedy předchozí zkompilovatelná, odladěná, otestovaná a v mém oblíbeném VCS uložená verze, už dávno běží v produkčním nasazení. A já se přitom nemusím bát, že se z nějakého podivného důvodu do nějaké pomocné funkce, která normálně dostává řetězce a volá na ně clear(), dostane jako parametr handle k databázi :)

Co jsou to "pomocné funkce"? Když mají vedlejší efekt, tak to jsou procedury, ne?

Je fakt, že statická typová kontrola se dostala i do PHP, ovšem používá se tam pouze v rozhraní, protože jinde by nedávala smysl.
Název: Re:Co si myslíte o OOP?
Přispěvatel: O 05. 01. 2019, 23:32:40
Tohle je tady mylně považováno za výhodu statických jazyků, ale ten program nepůjde přeložit vůbec úplně celý.
Přitom v dynamickém jazyce mi ta hotová část programu může už dávno běžet...

To je zcela zásadní výhoda statických jazyků. O tom, že  to není omyl, svědčí i všechny ty snahy naroubovat statickou typovou kontrolu na původně dynamicky typované jazyky. A zatímco opravuji kód, aby prošla typová kontrola, hotová část programu, tedy předchozí zkompilovatelná, odladěná, otestovaná a v mém oblíbeném VCS uložená verze, už dávno běží v produkčním nasazení. A já se přitom nemusím bát, že se z nějakého podivného důvodu do nějaké pomocné funkce, která normálně dostává řetězce a volá na ně clear(), dostane jako parametr handle k databázi :)

Jestli potřebuješ staticky typovaný jazyk, aby sis byl jistý, že tvůj kód omylem nepromázne databázi, tak bys měl změnit obor. Nebo si alespoň pořídit hodně kvalitní pojistku na blbost.
Název: Re:Co si myslíte o OOP?
Přispěvatel: MartinBeran 05. 01. 2019, 23:35:38
Dynamické typování v tomto případě nemá žádnou výhodu. Bude to pomalejší a na chyby v programu se přijde až v runtime, kdy to celé spadne.

Při chybě v programu to spadne už v testech - stejně jako při statickém typování.

Pokud máš plné pokrytí. Za předpokladu jedné unity.

Pokud píšeš libku nebo nedejte bozi framework, tak se ti tohle ještě dál komplikuje...

K tomu mě napadá akademická otázka: Dá se pro libovolný program napsat testovací sada, která nalezne všechny chyby, jež by nalezla statická typová kontrola, a přitom nebude zahrnovat (jakkoliv zakamuflovanou) statickou typovou kontrolu?
Název: Re:Co si myslíte o OOP?
Přispěvatel: MartinBeran 05. 01. 2019, 23:36:19
Co jsou to "pomocné funkce"? Když mají vedlejší efekt, tak to jsou procedury, ne?

Používám terminologii mého oblíbeného C++.
Název: Re:Co si myslíte o OOP?
Přispěvatel: Kit 05. 01. 2019, 23:37:04
... Ale třeba get_peer_address() má jistě smysl pro třídu network_socket. Hůř se ale bude hledat význam takové funkce pro string nebo int a s tím mi nepomůže, když tu funkci přesunu do samostatné třídy address_extractor. Jde mi o to, že některé operace nemají pro nějaké typy smysl, buď obecně nebo v kontextu konkrétního řešeného problému. Jakákoliv runtime reakce na volání takové operace s nevhodným typem argumentu je špatně, protože v prvé řadě nemělo dojít k tomu zavolání. Tedy jedná se o chybu v programu, kterou je nutno řešit úpravou kódu. Statické typování mi takovou chybu odhalí včas a bez toho, abych musel kvůli diagnostice psát víc, než jméno typu.

get_peer_address() má jako parametr int32, string nebo je to jedno? Návratová hodnota je big endian nebo little endian? Pro diagnostiku musíš psát i testy. Co když dostaneš 0.0.0.0 nebo 255.255.255.255? Bude to v pořádku?

Funkce get_peer_address() je buď metoda třídy network_socket bez parametrů, nebo je to samostatná funkce (nebo klidně metoda třídy address_extractor) s jedním parametrem typu network_socket. Návratová hodnota je typu socket_address, což je polymorfní typ zahrnující IPv4, IPv6 i řetězce (používané jako jména UNIX domain socketů). Všechny tyhle informace jsou explicitně napsané ve zdrojáku, z něj se automaticky přenesou do dokumentace (např. v C++ pomocí Doxygenu), a to všechno bez nutnosti napsat jediné slovo komentáře a jediný test zjišťující, zda se předávají nebo vrací hodnoty správných typů. Testy už píšu jen na ověření chování této funkce se smysluplnými typy parametrů.

A jak je to s těmi IP 0.0.0.0 nebo 255.255.255.255? Jsou validní nebo ne?

Z toho, co jsi napsal, nemusím v PHP řešit vůbec nic, proto mi ten příklad připadal trochu odtržený od reality. Vlastně ani nepotřebuji metodu get_peer_address(), neboť tu hodnotu mám nachystanou v $_SERVER["REMOTE_ADDR"].
Název: Re:Co si myslíte o OOP?
Přispěvatel: BaldSlattery 05. 01. 2019, 23:37:38
Dynamické typování v tomto případě nemá žádnou výhodu. Bude to pomalejší a na chyby v programu se přijde až v runtime, kdy to celé spadne.

Při chybě v programu to spadne už v testech - stejně jako při statickém typování.

Pokud máš plné pokrytí. Za předpokladu jedné unity.

Pokud píšeš libku nebo nedejte bozi framework, tak se ti tohle ještě dál komplikuje...
Dá se pro libovolný program napsat testovací sada, která nalezne všechny chyby, jež by nalezla statická typová kontrola, a přitom nebude zahrnovat (jakkoliv zakamuflovanou) statickou typovou kontrolu?
Ne
Název: Re:Co si myslíte o OOP?
Přispěvatel: BoneFlute 05. 01. 2019, 23:42:16
Kód: [Vybrat]
#!/usr/bin/env python
# -*- coding: utf-8 -*-

def vypis(kolekce):
    print(type(kolekce))
    for i in kolekce:
        print(i)
    print()

seznam = ["Alfa", 42, 42, ("Beta", "Gamma")]
mnozina = {"Alfa", 42, 42, ("Beta", "Gamma")}
vypis(seznam)
vypis(mnozina)

Jak vidíš, tak proceduře vypis() je v daném případě jedno, zda jí předhodíš seznam nebo množinu. Vypíše obojí. Pokud je budu potřebovat rozlišit, stále ještě mohu použít reflexi.

Tento příklad krásně ilustruje problém dynamicky typovaných jazyků. Procedura vypis() implicitně předpokládá, že parametr kolekce se dá iterovat a že iterací dostanu objekty, pro které má smysl volat print(). Když nebudou splněny obě tyto podmínky, funkce havaruje. Pravděpodobně vyhodí nějakou výjimku, kterou buď očekávám a musím na ni nějak zareagovat, nebo výjimka shodí celý program. Kdybych se chtěl výjimce vyhnout, musel bych v kódu nějak ošetřit chování funkce pro všechny typy, které nejsou "iterable<printable>". Ovšem ze zadání může plynout, že nemá smysl volat vypis() na takové typy. Ve staticky typovaném jazyce bych jednoduše přidal parametru kolekce typ iterable<printable> a mohl bych se spolehnout, že případné chyby odhalí kompilátor při překladu. V dynamicky typovaném jazyce můžu tento požadavek tak akorát napsat do dokumentace a případně doufat, že na každé použití této funkce někdo napíše test, že se v tom kokrétním místě vždy volá se správným typem.

Na tomto příkladu můžeme vidět ještě jednu vlastnost dynamických typů.

Jsem pečlivý programátor, a do tý funkce print() dám aserci, abych varoval, že vkládám špatné vstupy. Tím dosáhnu toho, že ta funkce bude házet výjimky, což je ale další rozměr, který té funkci přidám. Ty výjimky musím ne/odchytit. Nesmí se mi poplést. Neměl bych je přehlédnout. A hlavně, hmm, kdy vlastně nastane? Díky Murphymu, tak na produkci, a budu rád, když budu logovat.

Statické typování má tu výhodu, že taková situace jednoduše neexistuje. Pokud popletu vstupy, tak to na mě zařve kompilátor. Hned! Nemusím testovat, jestli ta funkce vyhodila nějakou chybu, protože jsem se překlpl. Spustu věcí nemusím dělat. Kód je kratší a přímočařejší.
Název: Re:Co si myslíte o OOP?
Přispěvatel: Kit 05. 01. 2019, 23:43:55
Co jsou to "pomocné funkce"? Když mají vedlejší efekt, tak to jsou procedury, ne?
Používám terminologii mého oblíbeného C++.

Samozřejmě, chápu to. Syntakticky je to funkce, sémanticky procedura. Dají se tedy používat oba pojmy. Už když jsem se učil Pascal, tak k nám začínal pronikat jazyk C, ve kterém byl rozdíl mezi procedurou a funkcí jaksi setřen. Už tenkrát mi C nebylo sympatické.
Název: Re:Co si myslíte o OOP?
Přispěvatel: MartinBeran 05. 01. 2019, 23:49:18

A já se přitom nemusím bát, že se z nějakého podivného důvodu do nějaké pomocné funkce, která normálně dostává řetězce a volá na ně clear(), dostane jako parametr handle k databázi :)

Jestli potřebuješ staticky typovaný jazyk, aby sis byl jistý, že tvůj kód omylem nepromázne databázi, tak bys měl změnit obor. Nebo si alespoň pořídit hodně kvalitní pojistku na blbost.

Já už jsem ve svém programátorském životě viděl příliš mnoho chyb, které jsem buď sám udělal, nebo jsem je musel opravit, o nichž jsem byl přesvědčený, že nemohou nastat... :)

S trochou nadsázky - programátoři se dělí do několika podmnožin:

Programátoři z první podmnožiny potřebují nabrat zkušenosti nebo, když toho nejsou schopni, najít si jiný obor. Programátoři z druhé podmnožiny dávají přednost staticky typovaným jazykům, protože jim pomáhají diagnostikovat chyby. Pro programátory ze třetí podmnožiny jsou lepší dynamicky typované jazyky, protože je nebrzdí v tvůrčím rozletu. Drobný problém je, že třetí podmnožina je prázdná.
Název: Re:Co si myslíte o OOP?
Přispěvatel: v 05. 01. 2019, 23:50:22
K tomu mě napadá akademická otázka: Dá se pro libovolný program napsat testovací sada, která nalezne všechny chyby, jež by nalezla statická typová kontrola, a přitom nebude zahrnovat (jakkoliv zakamuflovanou) statickou typovou kontrolu?
+1
Název: Re:Co si myslíte o OOP?
Přispěvatel: MartinBeran 05. 01. 2019, 23:55:08
Dá se pro libovolný program napsat testovací sada, která nalezne všechny chyby, jež by nalezla statická typová kontrola, a přitom nebude zahrnovat (jakkoliv zakamuflovanou) statickou typovou kontrolu?
Ne

Já si to myslím taky, ale na akademickou otázku by mě zajímala akademická odpověď, tedy přeformulování otázky do formální podoby a matematický důkaz...
Název: Re:Co si myslíte o OOP?
Přispěvatel: Kit 05. 01. 2019, 23:58:23
Statické typování má tu výhodu, že taková situace jednoduše neexistuje. Pokud popletu vstupy, tak to na mě zařve kompilátor. Hned! Nemusím testovat, jestli ta funkce vyhodila nějakou chybu, protože jsem se překlpl. Spustu věcí nemusím dělat. Kód je kratší a přímočařejší.

Statické typování neodhalí logické chyby. Pokud napíši takovou funkci či metodu
Kód: [Vybrat]
float sin(float phi) {
    return 0.0;
}

tak kompilátorem v pohodě projde, ale je špatně. Navíc z ní vůbec není patrné, zda je parametr ve stupních, radiánech nebo v jiných jednotkách. Takže i ten typ "float" je de facto špatně, protože neobsahuje sémantiku. Když tam hodíš údaj v metrech, tak to typová kontrola nepozná. Takže bez testů se prostě neobejdeš, jinak ti podobná hloupá chyba proběhne až na produkci. Tam ti to neslítne, ale bude produkovat chybná data, což je ještě horší.
Název: Re:Co si myslíte o OOP?
Přispěvatel: BoneFlute 05. 01. 2019, 23:58:42

A já se přitom nemusím bát, že se z nějakého podivného důvodu do nějaké pomocné funkce, která normálně dostává řetězce a volá na ně clear(), dostane jako parametr handle k databázi :)

Jestli potřebuješ staticky typovaný jazyk, aby sis byl jistý, že tvůj kód omylem nepromázne databázi, tak bys měl změnit obor. Nebo si alespoň pořídit hodně kvalitní pojistku na blbost.

Já už jsem ve svém programátorském životě viděl příliš mnoho chyb, které jsem buď sám udělal, nebo jsem je musel opravit, o nichž jsem byl přesvědčený, že nemohou nastat... :)

S trochou nadsázky - programátoři se dělí do několika podmnožin:
  • Ti, kteří dělají chyby, a nevědí, co s tím.
  • Ti, kteří dělají chyby, ale snaží se z nich poučit a snaží se používat nástroje, které jim pomohou chyby lépe odhalovat a odstraňovat.
  • Ti, kteří nedělají chyby.

Programátoři z první podmnožiny potřebují nabrat zkušenosti nebo, když toho nejsou schopni, najít si jiný obor. Programátoři z druhé podmnožiny dávají přednost staticky typovaným jazykům, protože jim pomáhají diagnostikovat chyby. Pro programátory ze třetí podmnožiny jsou lepší dynamicky typované jazyky, protože je nebrzdí v tvůrčím rozletu. Drobný problém je, že třetí podmnožina je prázdná.
+1
Název: Re:Co si myslíte o OOP?
Přispěvatel: v 06. 01. 2019, 00:03:42
Navíc z ní vůbec není patrné, zda je parametr ve stupních, radiánech nebo v jiných jednotkách. Takže i ten typ "float" je de facto špatně, protože neobsahuje sémantiku. Když tam hodíš údaj v metrech, tak to typová kontrola nepozná.

Kód: [Vybrat]
sin :: Deg Float -> Float
Název: Re:Co si myslíte o OOP?
Přispěvatel: Kit 06. 01. 2019, 00:07:42
S trochou nadsázky - programátoři se dělí do několika podmnožin:
  • Ti, kteří dělají chyby, a nevědí, co s tím.
  • Ti, kteří dělají chyby, ale snaží se z nich poučit a snaží se používat nástroje, které jim pomohou chyby lépe odhalovat a odstraňovat.
  • Ti, kteří nedělají chyby.

Programátoři z první podmnožiny potřebují nabrat zkušenosti nebo, když toho nejsou schopni, najít si jiný obor. Programátoři z druhé podmnožiny dávají přednost staticky typovaným jazykům, protože jim pomáhají diagnostikovat chyby. Pro programátory ze třetí podmnožiny jsou lepší dynamicky typované jazyky, protože je nebrzdí v tvůrčím rozletu. Drobný problém je, že třetí podmnožina je prázdná.

Popis druhé podmnožiny je neúplný. Patří do ní i programátoři, kteří píší testy.
Název: Re:Co si myslíte o OOP?
Přispěvatel: Kit 06. 01. 2019, 00:11:38
Navíc z ní vůbec není patrné, zda je parametr ve stupních, radiánech nebo v jiných jednotkách. Takže i ten typ "float" je de facto špatně, protože neobsahuje sémantiku. Když tam hodíš údaj v metrech, tak to typová kontrola nepozná.
Kód: [Vybrat]
sin :: Deg Float -> Float

To je zápis signatury v Haskellu. Pokud sis nevšiml, tak nejenže to bylo napsáno v jiném jazyce, ale ani jsi nevyřešil problém s návratovou hodnotou.
Název: Re:Co si myslíte o OOP?
Přispěvatel: anonym 06. 01. 2019, 00:31:43
Hosi, divejte se, resite tu uplne blbosti. K rozreseni vsech svych zivotnich otazek potrebujete jenom jednu vec, a to Javu. To je lek na vsechny vase psychicke neduhy. Musite jen poznat tu silu.

Timto uzaviram tuto diskuzi. Krcmi, muzes!

(https://ih0.redbubble.net/image.524810061.1148/flat,550x550,075,f.u1.jpg)
Název: Re:Co si myslíte o OOP?
Přispěvatel: BoneFlute 06. 01. 2019, 00:33:50
S trochou nadsázky - programátoři se dělí do několika podmnožin:
  • Ti, kteří dělají chyby, a nevědí, co s tím.
  • Ti, kteří dělají chyby, ale snaží se z nich poučit a snaží se používat nástroje, které jim pomohou chyby lépe odhalovat a odstraňovat.
  • Ti, kteří nedělají chyby.

Programátoři z první podmnožiny potřebují nabrat zkušenosti nebo, když toho nejsou schopni, najít si jiný obor. Programátoři z druhé podmnožiny dávají přednost staticky typovaným jazykům, protože jim pomáhají diagnostikovat chyby. Pro programátory ze třetí podmnožiny jsou lepší dynamicky typované jazyky, protože je nebrzdí v tvůrčím rozletu. Drobný problém je, že třetí podmnožina je prázdná.

Popis druhé podmnožiny je neúplný. Patří do ní i programátoři, kteří píší testy.
Jako doplňek k statickým typů jsou samozřejmě testy výborným nástrojem.
Název: Re:Co si myslíte o OOP?
Přispěvatel: Mirek Prýmek 06. 01. 2019, 00:34:48
Nevím, zda si rozumíte:
Jestliže ve Smalltalku přepíšu za běhu (Smalltalk má běh pořád) metodu, všechny instance dané třídy, přestože se nijak nezměnily, budou používat novou metodu, protože nositelem metod objektu je zde třída (způsob implementace metod). Když v Javascriptu změním kód, který generuje objekty včetně metod (bez "prototypování", ad-hoc), pak samozřejmě nové chování budou mít až ty nové objekty.
Taky nevím, jestli si rozumíme, ale to, co já chápu pod "hot code (re)loading" je každopádně to první, ne to druhé. Myslím, že jsem to několikrát celkem jasně napsal.
Název: Re:Co si myslíte o OOP?
Přispěvatel: Mirek Prýmek 06. 01. 2019, 00:40:13
Je to ošetřený a rozhodnutý v době překladu. To je to co mě zajímá.
Nevím, jestli jsme si tady rozuměli. V době překladu víš jenom to, že
1. z externího zdroje dostaneš posloupnost bajtů (vstup uživatele nebo síťový packet)
2. víš, že bys chtěl, aby ta posloupnost bajtů byl nějaký typ (např. integer zakódovaný jako string)

Jestli se tvoje "compile time přání" v run time splní nebo ne - to není nic jiného než dynamické typování.
Název: Re:Co si myslíte o OOP?
Přispěvatel: Mirek Prýmek 06. 01. 2019, 00:41:25
V JVM, co jsem se dočetl, hot reloading jde, ale nemůžeš měnit signatury ani odstraňovat nebo přidávat metody. Takže vlastně můžeš jenom měnit implementaci existujících věcí.
A to je právě jedním z důsledků toho, že Java nemá zasílání zpráv, ale volání funkcí.
Intuitivně bych to taky tak tipoval. Ale nemám dostatek erudice, abych to mohl tvrdit s jistotou :)
Název: Re:Co si myslíte o OOP?
Přispěvatel: BoneFlute 06. 01. 2019, 00:45:16
Je to ošetřený a rozhodnutý v době překladu. To je to co mě zajímá.
Nevím, jestli jsme si tady rozuměli. V době překladu víš jenom to, že
1. z externího zdroje dostaneš posloupnost bajtů (vstup uživatele nebo síťový packet)
2. víš, že bys chtěl, aby ta posloupnost bajtů byl nějaký typ (např. integer zakódovaný jako string)

Jestli se tvoje "compile time přání" v run time splní nebo ne - to není nic jiného než dynamické typování.
Podstatné je, že já sice chci integer, ale stroj ví, že to nemusí být jen integer. A tak mě přinutí, compile-time, ošetřit obě možnosti.

(Jsem si vědom, že to není univerzální pravda, a že ne každý staticky typovaný jazyk se bude takto chovat. Ale je to má motivace, proč ano, a proč ne dynamické.)
Název: Re:Co si myslíte o OOP?
Přispěvatel: Kadet 06. 01. 2019, 00:45:37
Je tu nejak mnohi zastancu statickejo typovani. Prijde mi, ze maji spoustu casu na psani na internetu a zapasenim s kompilatorem.

Mezitim lidi v Pythonu dodavaji vysledky a nemusi o tom zvanit.

Ono tech praci v haskellu stejne ani moc neni, mad nekde na akademii. Chapu ze to mrzi ze se s haskellem uzivi jen hrstka lidi.

https://www.reddit.com/r/haskell/comments/635d05/haskell_or_other_fp_programmer_positions_in_europe/
Název: Re:Co si myslíte o OOP?
Přispěvatel: Mirek Prýmek 06. 01. 2019, 00:46:46
Pro případ, že by to Blbcovi uniklo, tenhle příspěvek si myslím stojí za samostatné téma, tak jsem si ho dovolil založit :)

Existujou validní programy, který statickej jazyk neuzná. Žádnej statickej typovej systém nebude nikdy dostatečně silnej na to, aby uznal všechny validní programy - viz Godelovy věty o nekompletnosti.

https://forum.root.cz/index.php?topic=20479
Název: Re:Co si myslíte o OOP?
Přispěvatel: Mirek Prýmek 06. 01. 2019, 00:52:17
Podstatné je, že já sice chci integer, ale stroj ví, že to nemusí být jen integer. A tak mě přinutí, compile-time, ošetřit obě možnosti.

(Jsem si vědom, že to není univerzální pravda, a že ne každý staticky typovaný jazyk se bude takto chovat. Ale je to má motivace, proč ano, a proč ne dynamické.)
No, skoro bych řekl, že to je univerzální pravda. Protože ten jazyk prostě musí nějak ošetřit tu druhou možnost.

Čili, jinak řečeno: myslím, že tady propadáš falešnému dilematu: není tady žádný rozdíl mezi statickým a dynamickým jazykem. "Statický" tě typicky donutí tu eventualitu explicitně ošetřit, dynamický typicky vyhodí výjimku (přičemž to, že máš povinnost nějak ošetřit výjimky je implicitní).

Nehádám se s tebou, přijde mi taky lepší mít explicitně dvě větve, když tam věcně nutně jsou, ale nevidím mězi těmi dvěma možnostmi, jak k tomu přistupovat, tak světodějný rozdíl jako ty ;)
Název: Re:Co si myslíte o OOP?
Přispěvatel: Mirek Prýmek 06. 01. 2019, 00:54:31
Dá se pro libovolný program napsat testovací sada, která nalezne všechny chyby, jež by nalezla statická typová kontrola, a přitom nebude zahrnovat (jakkoliv zakamuflovanou) statickou typovou kontrolu?
Ne

Já si to myslím taky, ale na akademickou otázku by mě zajímala akademická odpověď, tedy přeformulování otázky do formální podoby a matematický důkaz...
Mě by zas enormně zajímalo, jak bys chtěl vágní pojmy typu "jakkoliv zakamuflovaná statická typová kontrola" přeformulovat do formální podoby :)
Název: Re:Co si myslíte o OOP?
Přispěvatel: anonym 06. 01. 2019, 01:05:18
Vtipne jak se tu polemizuje nad statickou typovou kontrolou, zatimco v Jave se momentalne nadava nad novym populistickym slunickarskym klicovym slovem "var", protoze to zpusobi, ze nejde videt navratovy typ primo v kodu, coz zhorsuje prehlednost. Fakt inteligentni. Podle me by ten "var" meli synci vyhodit.

Co se vas tyce hosi, tak vy proste delate webdevelopment. Se s tim proste smirte, webolepici. Opravdovi softwarovi inzenyri pouzivaji staticky typovany jazyk, protoze vyvijeji poradne komplexni backendove veci.

To je jak kdyby jeden frajer peclive frezoval ocelove obrobky do komplexniho pristroje, zatimco opodal by se mu smal nejaky plantala z kvetinarstvi, ze naco to frezuje do oceli a dela to tak presne a namahave, kdyz na to prece muze pouzit stejne dobre nuzky a lepenku, jako to dela on.
Název: Re:Co si myslíte o OOP?
Přispěvatel: Kit 06. 01. 2019, 01:09:57
To je jak kdyby jeden frajer peclive frezoval ocelove obrobky do komplexniho pristroje, zatimco opodal by se mu smal nejaky plantala z kvetinarstvi, ze naco to frezuje do oceli a dela to tak presne a namahave, kdyz na to prece muze pouzit stejne dobre nuzky a lepenku, jako to dela on.

Proč bych měl lisovat podložky pod matičky z plechu, když je mohu soustružit z kulatiny a prověřovat kalibrem, že?
Název: Re:Co si myslíte o OOP?
Přispěvatel: Mirek Prýmek 06. 01. 2019, 01:12:23
To je jak kdyby jeden frajer peclive frezoval ocelove obrobky do komplexniho pristroje, zatimco opodal by se mu smal nejaky plantala z kvetinarstvi, ze naco to frezuje do oceli a dela to tak presne a namahave, kdyz na to prece muze pouzit stejne dobre nuzky a lepenku, jako to dela on.

Proč bych měl lisovat podložky pod matičky z plechu, když je mohu soustružit z kulatiny a prověřovat kalibrem, že?
Panové, fakt vám přijde, že tahle pseudotrefná, emotivní, na všech deset noh kulhající přirovnání, jsou k něčemu dobrá?
Název: Re:Co si myslíte o OOP?
Přispěvatel: BoneFlute 06. 01. 2019, 01:48:24
Nehádám se s tebou, přijde mi taky lepší mít explicitně dvě větve, když tam věcně nutně jsou, ale nevidím mězi těmi dvěma možnostmi, jak k tomu přistupovat, tak světodějný rozdíl jako ty ;)

:-)

Pro mě je to úplně-extrémně-maximálně-úplně-ultimátně-základně-úplně nutný.

Primus: Dynamický jazyk mě obvykle nepřinutí ošéfovat tu druhou větev (čest výjimkám). Zapomenu na to. Vždycky. Každej. I Kit. Zatímco v Staticky typovaném jazyce, když tu větev zamatlám, a neošetřím to (ne, že by to nešlo), tak je to moje vědomé, opakovaně varované, rozhodnutí.
Secundus: Dynamický jazyk tu větev projde na produkci, což je naprosto pozdě.
Název: Re:Co si myslíte o OOP?
Přispěvatel: BaldSlattery 06. 01. 2019, 01:49:22
Dá se pro libovolný program napsat testovací sada, která nalezne všechny chyby, jež by nalezla statická typová kontrola, a přitom nebude zahrnovat (jakkoliv zakamuflovanou) statickou typovou kontrolu?
Ne
Já si to myslím taky, ale na akademickou otázku by mě zajímala akademická odpověď
Tak třeba typová kontrola umí zajistit, že funkce vrací sudé číslo. Testem to nejde, nejsou-li ty výsledky shora omezené.
Název: Re:Co si myslíte o OOP?
Přispěvatel: BoneFlute 06. 01. 2019, 01:54:15
Dá se pro libovolný program napsat testovací sada, která nalezne všechny chyby, jež by nalezla statická typová kontrola, a přitom nebude zahrnovat (jakkoliv zakamuflovanou) statickou typovou kontrolu?
Ne
Já si to myslím taky, ale na akademickou otázku by mě zajímala akademická odpověď
Tak třeba typová kontrola umí zajistit, že funkce vrací sudé číslo. Testem to nejde, nejsou-li ty výsledky shora omezené.
Pouštíš se na tenkej led :-) Bohatě stačí, že typová kontrola umí zajistit, že funkce vrátí celé číslo. Už v takovém případě test nebude stačit.
Název: Re:Co si myslíte o OOP?
Přispěvatel: BaldSlattery 06. 01. 2019, 02:07:41
Statické typování má tu výhodu, že taková situace jednoduše neexistuje. Pokud popletu vstupy, tak to na mě zařve kompilátor. Hned! Nemusím testovat, jestli ta funkce vyhodila nějakou chybu, protože jsem se překlpl. Spustu věcí nemusím dělat. Kód je kratší a přímočařejší.
Kód: [Vybrat]
float sin(float phi) {
    return 0.0;
}

Navíc z ní vůbec není patrné, zda je parametr ve stupních, radiánech nebo v jiných jednotkách. Takže i ten typ "float" je de facto špatně, protože neobsahuje sémantiku. Když tam hodíš údaj v metrech, tak to typová kontrola nepozná.
To je tím, že to je hloupě napsané. V takovém systému jde mít typ obsahující (a kontrolující) fyzikální rozměr i jednotku a činitele, takže prostě řeknu, že rozměr vstupu je 1 a výpočet upravím podle vlastností vstupu. Pak tam nepůjdou hodit metry, protože clashne rozměr. Fyzici tohle mají ve výpočtech ošetřené běžně, jen ty typy bývají divočejší, například vektorové pole.
Název: Re:Co si myslíte o OOP?
Přispěvatel: Kit 06. 01. 2019, 02:26:25
Statické typování má tu výhodu, že taková situace jednoduše neexistuje. Pokud popletu vstupy, tak to na mě zařve kompilátor. Hned! Nemusím testovat, jestli ta funkce vyhodila nějakou chybu, protože jsem se překlpl. Spustu věcí nemusím dělat. Kód je kratší a přímočařejší.
Kód: [Vybrat]
float sin(float phi) {
    return 0.0;
}

Navíc z ní vůbec není patrné, zda je parametr ve stupních, radiánech nebo v jiných jednotkách. Takže i ten typ "float" je de facto špatně, protože neobsahuje sémantiku. Když tam hodíš údaj v metrech, tak to typová kontrola nepozná.
To je tím, že to je hloupě napsané. V takovém systému jde mít typ obsahující (a kontrolující) fyzikální rozměr i jednotku a činitele, takže prostě řeknu, že rozměr vstupu je 1 a výpočet upravím podle vlastností vstupu. Pak tam nepůjdou hodit metry, protože clashne rozměr. Fyzici tohle mají ve výpočtech ošetřené běžně, jen ty typy bývají divočejší, například vektorové pole.

Na vektorovém či tenzorovém poli nevidím nic divokého.

Tu funkci jsem tak napsal záměrně. Jak bys ji tedy napsal, aby nebyla hloupě, např. v Javě?
Název: Re:Co si myslíte o OOP?
Přispěvatel: Honza 06. 01. 2019, 02:39:03
Na tom příkladu se sinusem bych chtěl vidět jednu věc: chci, aby parametrem mohl být i zlomek, nejen float...
A výsledek chci mít možnost obojí, podle toho, jak to vyjde, abych neztratil přesnost výpočtu. Ha?
Název: Re:Co si myslíte o OOP?
Přispěvatel: BaldSlattery 06. 01. 2019, 02:53:06
Na tom příkladu se sinusem bych chtěl vidět jednu věc: chci, aby parametrem mohl být i zlomek, nejen float...
A výsledek chci mít možnost obojí, podle toho, jak to vyjde, abych neztratil přesnost výpočtu. Ha?
To je triviální, prostě rozhraním.
Název: Re:Co si myslíte o OOP?
Přispěvatel: Honza 06. 01. 2019, 03:21:05
Na tom příkladu se sinusem bych chtěl vidět jednu věc: chci, aby parametrem mohl být i zlomek, nejen float...
A výsledek chci mít možnost obojí, podle toho, jak to vyjde, abych neztratil přesnost výpočtu. Ha?
To je triviální, prostě rozhraním.
Díky, člověk rychle zapomene, že je něco takového ve statických jazycích potřeba...
Název: Re:Co si myslíte o OOP?
Přispěvatel: Kit 06. 01. 2019, 03:36:11
Na tom příkladu se sinusem bych chtěl vidět jednu věc: chci, aby parametrem mohl být i zlomek, nejen float...
A výsledek chci mít možnost obojí, podle toho, jak to vyjde, abych neztratil přesnost výpočtu. Ha?
To je triviální, prostě rozhraním.
Díky, člověk rychle zapomene, že je něco takového ve statických jazycích potřeba...

Ve statických jazycích je nutné ho i implementovat nějakou přetíženou metodou.
Název: Re:Co si myslíte o OOP?
Přispěvatel: Honza 06. 01. 2019, 03:41:55
Na tom příkladu se sinusem bych chtěl vidět jednu věc: chci, aby parametrem mohl být i zlomek, nejen float...
A výsledek chci mít možnost obojí, podle toho, jak to vyjde, abych neztratil přesnost výpočtu. Ha?
To je triviální, prostě rozhraním.
Díky, člověk rychle zapomene, že je něco takového ve statických jazycích potřeba...

Ve statických jazycích je nutné ho i implementovat nějakou přetíženou metodou.

Ano, to se blížíme tomu, co jsem chtěl naznačit. Přetíženou metodou to totiž nepůjde, protože typ výsledku známe až za běhu...
Např. v Javě rozhodně nemůžu mít dvě stejné metody, pokud mají různé typy výsledku...
Název: Re:Co si myslíte o OOP?
Přispěvatel: Kit 06. 01. 2019, 03:51:51
Na tom příkladu se sinusem bych chtěl vidět jednu věc: chci, aby parametrem mohl být i zlomek, nejen float...
A výsledek chci mít možnost obojí, podle toho, jak to vyjde, abych neztratil přesnost výpočtu. Ha?
To je triviální, prostě rozhraním.
Díky, člověk rychle zapomene, že je něco takového ve statických jazycích potřeba...
Ve statických jazycích je nutné ho i implementovat nějakou přetíženou metodou.
Ano, to se blížíme tomu, co jsem chtěl naznačit. Přetíženou metodou to totiž nepůjde, protože typ výsledku známe až za běhu...
Např. v Javě rozhodně nemůžu mít dvě stejné metody, pokud mají různé typy výsledku...

Pokud se liší typem parametru, tak ano. Ovšem sin(π/6) má reálný parametr, ale racionální výsledek. Také jsem zvědav, jak to staticky natypují.
Název: Re:Co si myslíte o OOP?
Přispěvatel: BaldSlattery 06. 01. 2019, 03:55:40
Na tom příkladu se sinusem bych chtěl vidět jednu věc: chci, aby parametrem mohl být i zlomek, nejen float...
A výsledek chci mít možnost obojí, podle toho, jak to vyjde, abych neztratil přesnost výpočtu. Ha?
To je triviální, prostě rozhraním.
Díky, člověk rychle zapomene, že je něco takového ve statických jazycích potřeba...
Ve statických jazycích je nutné ho i implementovat nějakou přetíženou metodou.
Ano, to se blížíme tomu, co jsem chtěl naznačit. Přetíženou metodou to totiž nepůjde, protože typ výsledku známe až za běhu...
Např. v Javě rozhodně nemůžu mít dvě stejné metody, pokud mají různé typy výsledku...

Pokud se liší typem parametru, tak ano. Ovšem sin(π/6) má reálný parametr, ale racionální výsledek. Také jsem zvědav, jak to staticky natypují.
racionální implikuje reálný, sám sis odpověděl, co je rozhraním
Název: Re:Co si myslíte o OOP?
Přispěvatel: Kit 06. 01. 2019, 04:04:35
Pokud se liší typem parametru, tak ano. Ovšem sin(π/6) má reálný parametr, ale racionální výsledek. Také jsem zvědav, jak to staticky natypují.
racionální implikuje reálný, sám sis odpověděl, co je rozhraním

V uvedeném případě je to naopak - z reálného čísla se stává racionální.
Název: Re:Co si myslíte o OOP?
Přispěvatel: BaldSlattery 06. 01. 2019, 04:44:25
Pokud se liší typem parametru, tak ano. Ovšem sin(π/6) má reálný parametr, ale racionální výsledek. Také jsem zvědav, jak to staticky natypují.
racionální implikuje reálný, sám sis odpověděl, co je rozhraním

V uvedeném případě je to naopak - z reálného čísla se stává racionální.
On nechtěl racionální čísla, ale zlomky, to sis tam přimyslel. pi/6 je zlomek.
Název: Re:Co si myslíte o OOP?
Přispěvatel: BoneFlute 06. 01. 2019, 05:01:39
Na tom příkladu se sinusem bych chtěl vidět jednu věc: chci, aby parametrem mohl být i zlomek, nejen float...
A výsledek chci mít možnost obojí, podle toho, jak to vyjde, abych neztratil přesnost výpočtu. Ha?
To je triviální, prostě rozhraním.
Díky, člověk rychle zapomene, že je něco takového ve statických jazycích potřeba...

Ve statických jazycích je nutné ho i implementovat nějakou přetíženou metodou.
Kite, Kite. Ty kdyby si tomu aspoň rozuměl, co?

Kód: [Vybrat]
type RatioNum = RatioNum Num
          |  RatioNumFract Num Num
          deriving show

sin :: RatioNum -> RatioNum
sin RatioNum num = ...
sin RatioNumFract num denom = ...

print $ sin (RatioNum 5)
print $ sin (RatioNumFract 5 2)
Název: Re:Co si myslíte o OOP?
Přispěvatel: Ondra Satai Nekola 06. 01. 2019, 09:33:17
Na tom příkladu se sinusem bych chtěl vidět jednu věc: chci, aby parametrem mohl být i zlomek, nejen float...
A výsledek chci mít možnost obojí, podle toho, jak to vyjde, abych neztratil přesnost výpočtu. Ha?

Spolecne rozhrani. Nebo implicitni konerze. Nebo typova trida...
Název: Re:Co si myslíte o OOP?
Přispěvatel: Kit 06. 01. 2019, 09:57:35
Na tom příkladu se sinusem bych chtěl vidět jednu věc: chci, aby parametrem mohl být i zlomek, nejen float...
A výsledek chci mít možnost obojí, podle toho, jak to vyjde, abych neztratil přesnost výpočtu. Ha?
To je triviální, prostě rozhraním.
Díky, člověk rychle zapomene, že je něco takového ve statických jazycích potřeba...

Ve statických jazycích je nutné ho i implementovat nějakou přetíženou metodou.
Kite, Kite. Ty kdyby si tomu aspoň rozuměl, co?

Kód: [Vybrat]
type RatioNum = RatioNum Num
          |  RatioNumFract Num Num
          deriving show

sin :: RatioNum -> RatioNum
sin RatioNum num = ...
sin RatioNumFract num denom = ...

print $ sin (RatioNum 5)
print $ sin (RatioNumFract 5 2)

Bavíme se o objektových jazycích. Patří mezi ně i Haskell?
Název: Re:Co si myslíte o OOP?
Přispěvatel: Ondra Satai Nekola 06. 01. 2019, 10:22:21
Na tom příkladu se sinusem bych chtěl vidět jednu věc: chci, aby parametrem mohl být i zlomek, nejen float...
A výsledek chci mít možnost obojí, podle toho, jak to vyjde, abych neztratil přesnost výpočtu. Ha?
To je triviální, prostě rozhraním.
Díky, člověk rychle zapomene, že je něco takového ve statických jazycích potřeba...

Ve statických jazycích je nutné ho i implementovat nějakou přetíženou metodou.
Kite, Kite. Ty kdyby si tomu aspoň rozuměl, co?

Kód: [Vybrat]
type RatioNum = RatioNum Num
          |  RatioNumFract Num Num
          deriving show

sin :: RatioNum -> RatioNum
sin RatioNum num = ...
sin RatioNumFract num denom = ...

print $ sin (RatioNum 5)
print $ sin (RatioNumFract 5 2)

Bavíme se o objektových jazycích. Patří mezi ně i Haskell?

Tak si to prepis do Scaly.
Název: Re:Co si myslíte o OOP?
Přispěvatel: O 06. 01. 2019, 13:55:35

A já se přitom nemusím bát, že se z nějakého podivného důvodu do nějaké pomocné funkce, která normálně dostává řetězce a volá na ně clear(), dostane jako parametr handle k databázi :)

Jestli potřebuješ staticky typovaný jazyk, aby sis byl jistý, že tvůj kód omylem nepromázne databázi, tak bys měl změnit obor. Nebo si alespoň pořídit hodně kvalitní pojistku na blbost.

Já už jsem ve svém programátorském životě viděl příliš mnoho chyb, které jsem buď sám udělal, nebo jsem je musel opravit, o nichž jsem byl přesvědčený, že nemohou nastat... :)

S trochou nadsázky - programátoři se dělí do několika podmnožin:
  • Ti, kteří dělají chyby, a nevědí, co s tím.
  • Ti, kteří dělají chyby, ale snaží se z nich poučit a snaží se používat nástroje, které jim pomohou chyby lépe odhalovat a odstraňovat.
  • Ti, kteří nedělají chyby.

Programátoři z první podmnožiny potřebují nabrat zkušenosti nebo, když toho nejsou schopni, najít si jiný obor. Programátoři z druhé podmnožiny dávají přednost staticky typovaným jazykům, protože jim pomáhají diagnostikovat chyby. Pro programátory ze třetí podmnožiny jsou lepší dynamicky typované jazyky, protože je nebrzdí v tvůrčím rozletu. Drobný problém je, že třetí podmnožina je prázdná.

Kecy. Sebedokonalejší typový systém za tebe kvalitní kód nevyrobí, prasit se dá v čemkoli. Mnohem více záleží na znalostech, zkušenosti a disciplíně(!) programátora. Sám jsem sice ve své víc než dvacetileté profesní praxi vždy pracoval převážně se staticky typovanými jazyky, ale nevidím ve statickém typování nijak velký přínos, co se týká bezpečnosti a vůbec kvality kódu. Způsob typování představuje jen jeden střípek ve škále vlastností jazyka a v praxi je to nakonec stejně hlavně o člověku, jeho schopnostech a přístupu, ne o nástroji. Nástroj je jen tak dobrý, jak dobrý je jeho uživatel. Kromě toho je zjevné, že dynamické a dynamicky typované jazyky si našly svou niku, ve které se prosadily, a je známkou arogance (nebo hlouposti či nezkušenosti) je jen tak spatra shazovat jako jazyky pro fušery. Ale když černobílé uvažování je tak pohodlné, že?
Název: Re:Co si myslíte o OOP?
Přispěvatel: Inkvizitor 06. 01. 2019, 14:23:44
Je to ošetřený a rozhodnutý v době překladu. To je to co mě zajímá.
Nevím, jestli jsme si tady rozuměli. V době překladu víš jenom to, že
1. z externího zdroje dostaneš posloupnost bajtů (vstup uživatele nebo síťový packet)
2. víš, že bys chtěl, aby ta posloupnost bajtů byl nějaký typ (např. integer zakódovaný jako string)

Jestli se tvoje "compile time přání" v run time splní nebo ne - to není nic jiného než dynamické typování.

To zase prrr. Máme 3 funkce, read_int(), print_int() a main(). Napíšu to v pseudokódu volně inspirovaném Rustem:


func read_int(s: stream) -> Result<int, str> {
  buf = stream.read();
  if len(buf) == 8
    Ok(buf.to_integer())
  else
    Err("Invalid size, cannot convert to integer")
}

func print_int(i: int) {
  print("Valid integer {}", i)
}

func main() {
  s = open_stream();
  match read_int(s) {
    case Ok(i) print_int(i)
    case Err(s) print("Error on input: {}", s)
  }
}


Tam nikde žádný dynamický typ není - validace vstupu je ošetřena algebraickým datovým typem. S tímhle se dá pracovat donekonečna. Možnost invalidního/variabilního vstupu zesložiťuje logiku, ale pokud tam nemáme dynamickou deserializaci, která umožňuje načíst zcela libovolné typy ze streamu, statické typování není ohroženo.
Název: Re:Co si myslíte o OOP?
Přispěvatel: Mirek Prýmek 06. 01. 2019, 14:52:03
Tam nikde žádný dynamický typ není
A proč to žere jenom osmibajtové vstupy?!
Název: Re:Co si myslíte o OOP?
Přispěvatel: Inkvizitor 06. 01. 2019, 14:55:50
Tam nikde žádný dynamický typ není
A proč to žere jenom osmibajtové vstupy?!

Ale nežere. Zná dva druhy vstupu, int a noise. Co nemá 8 bajtů, je noise. Způsob ošetření lze samozřejmě zvolit libovolně.
Název: Re:Co si myslíte o OOP?
Přispěvatel: Kit 06. 01. 2019, 15:04:08
Tam nikde žádný dynamický typ není
A proč to žere jenom osmibajtové vstupy?!
Ale nežere. Zná dva druhy vstupu, int a noise. Co nemá 8 bajtů, je noise. Způsob ošetření lze samozřejmě zvolit libovolně.

Jak to vyhodnotí vstup "12nazdar"? Jako int nebo noise?
Název: Re:Co si myslíte o OOP?
Přispěvatel: Mirek Prýmek 06. 01. 2019, 15:20:20
Zná dva druhy vstupu, int a noise. Co nemá 8 bajtů, je noise.
No a dynamicky (až za běhu) rozhoduje o typu => je to dynamické typování.
Název: Re:Co si myslíte o OOP?
Přispěvatel: v 06. 01. 2019, 15:30:33
Zná dva druhy vstupu, int a noise. Co nemá 8 bajtů, je noise.
No a dynamicky (až za běhu) rozhoduje o typu => je to dynamické typování.
součtové typy => dynamické typování?
Název: Re:Co si myslíte o OOP?
Přispěvatel: Mirek Prýmek 06. 01. 2019, 15:33:56
součtové typy => dynamické typování?
rozhodování o typu za běhu => dynamické typování
Název: Re:Co si myslíte o OOP?
Přispěvatel: Kit 06. 01. 2019, 15:40:54
Pokud by mnou uvedený string "12nazdar" znamenal číslo 3545017221638283634 nebo prostě osmibajtový string "12nazdar" a tento typ by byl součástí aplikace, jednalo by se o statické typování. Typ noise se nepřipouští.
Název: Re:Co si myslíte o OOP?
Přispěvatel: v 06. 01. 2019, 15:42:15
součtové typy => dynamické typování?
rozhodování o typu za běhu => dynamické typování
co je "rozhodování o typu"?
Název: Re:Co si myslíte o OOP?
Přispěvatel: Mirek Prýmek 06. 01. 2019, 15:59:26
co je "rozhodování o typu"?
Nemam potrebu se tady tahat za nohu ani hadat o pitomosti :)
Název: Re:Co si myslíte o OOP?
Přispěvatel: v 06. 01. 2019, 16:05:37
co je "rozhodování o typu"?
Nemam potrebu se tady tahat za nohu ani hadat o pitomosti :)
tak tak, tyhle mlhavé vágní úvahy...
Název: Re:Co si myslíte o OOP?
Přispěvatel: Kit 06. 01. 2019, 16:05:57
součtové typy => dynamické typování?
rozhodování o typu za běhu => dynamické typování
co je "rozhodování o typu"?

To znamená, není předem jasně dáno, že na vstupu je osmibajtový int a nic jiného. Jakmile připustím nějaký "noise", už dynamicky rozhoduji, jaký typ dat na tom vstupu je. Když chci přečíst 512 bajtů (sektor) z disku jako zařízení (ne přes FS), tak staticky říkám, že chci načíst přesně 512 bajtů a v bufferu očekávám 512 platných bajtů. Z FS může přijít i kratší záznam s uvedenou délkou, ale to už je dynamický typ.
Název: Re:Co si myslíte o OOP?
Přispěvatel: Mirek Prýmek 06. 01. 2019, 16:07:38
tak tak, tyhle mlhavé vágní úvahy...
Nevím, co je na tom vágního. Jestliže máš nějaký vstup a podle toho, co tam přijde, se rozhoduje, jestli je to typ X nebo typ Y, tak tomu já říkám "dynamické typování". Pokud někdo ten pojem používá jinak, rád si to poslechnu. Ale nehodlám si tady hrát na kočku s myší.
Název: Re:Co si myslíte o OOP?
Přispěvatel: Inkvizitor 06. 01. 2019, 16:08:40
co je "rozhodování o typu"?
Nemam potrebu se tady tahat za nohu ani hadat o pitomosti :)

Tak dobře, třeba jsem konkrétně já nepochopil, co jsi chtěl říci původním příspěvkem. Pokud jsi chtěl ukázat, že i statický jazyk dokáže zpracovat dynamický vstup, nemám problém.
Název: Re:Co si myslíte o OOP?
Přispěvatel: Inkvizitor 06. 01. 2019, 16:12:51
tak tak, tyhle mlhavé vágní úvahy...
Nevím, co je na tom vágního. Jestliže máš nějaký vstup a podle toho, co tam přijde, se rozhoduje, jestli je to typ X nebo typ Y, tak tomu já říkám "dynamické typování". Pokud někdo ten pojem používá jinak, rád si to poslechnu. Ale nehodlám si tady hrát na kočku s myší.

Součtový typ dokáže z různých typů udělat různé hodnoty téhož typu. Pokud si množinu možných vstupních hodnot namodeluješ součtovým typem, je Tvoje tvrzení poměrně sporné. Úplně jiná situace by byla, kdybys použil pro vstup třeba pythonní pickle, tam už se o typech opravdu rozhoduje ad hoc.
Název: Re:Co si myslíte o OOP?
Přispěvatel: v 06. 01. 2019, 16:14:04
tak tak, tyhle mlhavé vágní úvahy...
Nevím, co je na tom vágního. Jestliže máš nějaký vstup a podle toho, co tam přijde, se rozhoduje, jestli je to typ X nebo typ Y, tak tomu já říkám "dynamické typování". Pokud někdo ten pojem používá jinak, rád si to poslechnu. Ale nehodlám si tady hrát na kočku s myší.
v Inkvizitorově příkladu se transformuje hodnota staticky daného typu na jinou (opět staticky známého typu), žádné "rozhodování o typu" se tam neděje, stejně jako když třeba porovnáváte celá, v době překladu neznámá, čísla
Název: Re:Co si myslíte o OOP?
Přispěvatel: Mirek Prýmek 06. 01. 2019, 16:20:23
Tak dobře, třeba jsem konkrétně já nepochopil, co jsi chtěl říci původním příspěvkem. Pokud jsi chtěl ukázat, že i statický jazyk dokáže zpracovat dynamický vstup, nemám problém.
Myslel jsem, že jsem to napsal celkem jasně. Možná ne. Chtěl jsem říct, že otypovat program v době překladu jde jenom tam, kde mám pod kontrolou vstupní typy (lapidárně: "vím, co mi leze dovnitř"). Pokud nevím, co mi leze dovnitř, a ukáže se to až v době běhu, pak jsem v situaci dynamického typování (aka "rozhování o typech až za běhu").

Součtový typ dokáže z různých typů udělat různé hodnoty téhož typu. Pokud si množinu možných vstupních hodnot namodeluješ součtovým typem, je Tvoje tvrzení poměrně sporné.
Mno... Součtový typ je způsob, jak dva (nebo více) typů "schovat pod jeden" - je to čistě proto, že potřebuješ, aby ti z funkce lezl jenom jeden typ. Je to technikálie, nic jiného. Nic to nemění na sémantice toho programu: dovnitř ti leze něco, o čem v době překladu nic nevíš a dozvíš se to až v době běhu - a podle toho, jestli tam bude X nebo Y, půjde program větví A nebo B.

Dalo by se argumentovat i jinak: mohl by sis vytvořit součtový typ, který by obsáhl všechny typy. Nazvěme takový typ Super. Všechny funkce nechť potom mají typ Super -> Super. Byl by takový jazyk/program podle tebe "statický" nebo "dynamický"?
Název: Re:Co si myslíte o OOP?
Přispěvatel: Mirek Prýmek 06. 01. 2019, 16:41:15
v Inkvizitorově příkladu se transformuje hodnota staticky daného typu na jinou (opět staticky známého typu), žádné "rozhodování o typu" se tam neděje, stejně jako když třeba porovnáváte celá, v době překladu neznámá, čísla
Jak jsem psal někde výš: "Znát typ" není nc jiného než "mít nějakou znalost o datech v tomhle místě programu". "Statické jazyky" se snaží v době překladu ze struktury programu vydedukovat co nejvíc znalostí. "Dynamické jazyky" na to rezignují a znalosti získávají až v době běhu. V tom je ten zásaní rozdíl.

Když použiju součtový typ "StringVal String | IntVal Int", tak tím jenom dávám překladači najevo, že vím, že v tomhle místě programu se za běhu objeví buď integer nebo string. Dynamický jazyk vlastně říká totéž: v tomhle (každém) místě programu nevím, co za běhu bude: int, string, list, ...
Název: Re:Co si myslíte o OOP?
Přispěvatel: Ondra Satai Nekola 06. 01. 2019, 16:48:34
součtové typy => dynamické typování?
rozhodování o typu za běhu => dynamické typování
co je "rozhodování o typu"?

To znamená, není předem jasně dáno, že na vstupu je osmibajtový int a nic jiného. Jakmile připustím nějaký "noise", už dynamicky rozhoduji, jaký typ dat na tom vstupu je. Když chci přečíst 512 bajtů (sektor) z disku jako zařízení (ne přes FS), tak staticky říkám, že chci načíst přesně 512 bajtů a v bufferu očekávám 512 platných bajtů. Z FS může přijít i kratší záznam s uvedenou délkou, ale to už je dynamický typ.

Hele, co se naučit nejdřív programovat v nějakém staticky typovaném jazyce? Haskell i Scala mají literatury pro začátečníky dost.
Název: Re:Co si myslíte o OOP?
Přispěvatel: BoneFlute 06. 01. 2019, 16:52:22
v Inkvizitorově příkladu se transformuje hodnota staticky daného typu na jinou (opět staticky známého typu), žádné "rozhodování o typu" se tam neděje, stejně jako když třeba porovnáváte celá, v době překladu neznámá, čísla
Jak jsem psal někde výš: "Znát typ" není nc jiného než "mít nějakou znalost o datech v tomhle místě programu". "Statické jazyky" se snaží v době překladu ze struktury programu vydedukovat co nejvíc znalostí. "Dynamické jazyky" na to rezignují a znalosti získávají až v době běhu. V tom je ten zásaní rozdíl.

Když použiju součtový typ "StringVal String | IntVal Int", tak tím jenom dávám překladači najevo, že vím, že v tomhle místě programu se za běhu objeví buď integer nebo string. Dynamický jazyk vlastně říká totéž: v tomhle (každém) místě programu nevím, co za běhu bude: int, string, list, ...

Statické typování: předem vím, co se může stát, a tomu přizpůsobím program.
Dynamické typování: teprve za běhu řeším, co se stalo, a podle toho mám napsaný program.

Zásadní rozdíl je (dle mého chápání) compile-time, versus run-time.

Ve statickém jazyce nepřeložím.
V dynamickém jazyce mi vypadne výjimka za běhu.
Název: Re:Co si myslíte o OOP?
Přispěvatel: v 06. 01. 2019, 16:54:15
v Inkvizitorově příkladu se transformuje hodnota staticky daného typu na jinou (opět staticky známého typu), žádné "rozhodování o typu" se tam neděje, stejně jako když třeba porovnáváte celá, v době překladu neznámá, čísla
Jak jsem psal někde výš: "Znát typ" není nc jiného než "mít nějakou znalost o datech v tomhle místě programu".
to je dost zúžený výklad, typ můžou mít i "věci", které nemají žádnou hodnotu/nepředstavují data
Název: Re:Co si myslíte o OOP?
Přispěvatel: v 06. 01. 2019, 16:55:45
Když použiju součtový typ "StringVal String | IntVal Int", tak tím jenom dávám překladači najevo, že vím, že v tomhle místě programu se za běhu objeví buď integer nebo string. Dynamický jazyk vlastně říká totéž: v tomhle (každém) místě programu nevím, co za běhu bude: int, string, list, ...
no ano, stacký jazyk - jeden algebraický typ, dynamický - cokoliv
Název: Re:Co si myslíte o OOP?
Přispěvatel: Mirek Prýmek 06. 01. 2019, 16:58:11
no ano, stacký jazyk - jeden algebraický typ, dynamický - cokoliv
mohl by sis vytvořit součtový typ, který by obsáhl všechny typy. Nazvěme takový typ Super. Všechny funkce nechť potom mají typ Super -> Super. Byl by takový jazyk/program podle tebe "statický" nebo "dynamický"?
čili, pokud bysme chtěli slovíčkařit: statický jazyk: jeden algebraický typ. Dynamický jazyk: jeden algebraický typ (pod kterým jsou "schované" všechny možné).
Název: Re:Co si myslíte o OOP?
Přispěvatel: Mirek Prýmek 06. 01. 2019, 16:59:03
to je dost zúžený výklad, typ můžou mít i "věci", které nemají žádnou hodnotu/nepředstavují data
Neplodné slovíčkaření.
Název: Re:Co si myslíte o OOP?
Přispěvatel: v 06. 01. 2019, 17:04:08
no ano, stacký jazyk - jeden algebraický typ, dynamický - cokoliv
mohl by sis vytvořit součtový typ, který by obsáhl všechny typy. Nazvěme takový typ Super. Všechny funkce nechť potom mají typ Super -> Super. Byl by takový jazyk/program podle tebe "statický" nebo "dynamický"?
čili, pokud bysme chtěli slovíčkařit: statický jazyk: jeden algebraický typ. Dynamický jazyk: jeden algebraický typ (pod kterým jsou "schované" všechny možné).
překrucujete to
dá se říct, že dynamický jazyk má jeden součtový typ pro všechny hodnoty (Robert Harper, "unityped"), statický umí rozlišit více typů u různých částí programu (třeba funkcí)
Název: Re:Co si myslíte o OOP?
Přispěvatel: v 06. 01. 2019, 17:05:25
to je dost zúžený výklad, typ můžou mít i "věci", které nemají žádnou hodnotu/nepředstavují data
Neplodné slovíčkaření.
viz např. "phantom types"
jenom se snažím vyhnout mlhavým vágním pojmům
Název: Re:Co si myslíte o OOP?
Přispěvatel: Mirek Prýmek 06. 01. 2019, 17:13:35
překrucujete to
dá se říct, že dynamický jazyk má jeden součtový typ pro všechny hodnoty (Robert Harper, "unityped"), statický umí rozlišit více typů u různých částí programu (třeba funkcí)
Nic nepřekrucuju. Celou dobu říkám jenom to, že nějaké "světodějné" rozlišování mezi statickými a dynamickými jazyky je iluze (falešné dilema). Jedná se totiž jenom o množství informací, které o datech mám - a to je na kontinuu, není to binární "statický ví vždycky všechno v compile time" vs. "dynamický neví v compile time nikdy nic". Statické jazyky občas něco neví (a tím se v té části programu přiblíží k dynamickému) a dynamické občas mají možnost použít třeba anotaci (a tím se v té části programu přiblíží ke statickému).

A jelikož už jsem řekl všechno, co jsem chtěl říct, a asi třikrát zopakoval, líp už svoji myšlenku asi vyjádřit neumím, takže už se asi nemá smysl, abych se dál téhle diskuse účastnil, pokud se nějak zásadně neposune.
Název: Re:Co si myslíte o OOP?
Přispěvatel: Mirek Prýmek 06. 01. 2019, 17:14:55
viz např. "phantom types"
jenom se snažím vyhnout mlhavým vágním pojmům
Neplodné slovíčkaření.
Název: Re:Co si myslíte o OOP?
Přispěvatel: BoneFlute 06. 01. 2019, 17:19:37
Statické jazyky občas něco neví
No jo, ale uvádíš blbej příklad.

Dobrej příklad je dělení nulou. Což ve většině statických jazyků nejde, a dokonce to zbuchne.
Zatímco příklad parsováním vstupu je naopak situace, kdy ten jazyk ví všechno. Takže blbej příklad.
Název: Re:Co si myslíte o OOP?
Přispěvatel: Mirek Prýmek 06. 01. 2019, 17:21:02
Zatímco příklad parsováním vstupu je naopak situace, kdy ten jazyk ví všechno.
Neví, jestli výpočet půjde cestou A nebo B, to se rozhodne až za běhu.
Název: Re:Co si myslíte o OOP?
Přispěvatel: Inkvizitor 06. 01. 2019, 17:24:08
Tak dobře, třeba jsem konkrétně já nepochopil, co jsi chtěl říci původním příspěvkem. Pokud jsi chtěl ukázat, že i statický jazyk dokáže zpracovat dynamický vstup, nemám problém.
Myslel jsem, že jsem to napsal celkem jasně. Možná ne. Chtěl jsem říct, že otypovat program v době překladu jde jenom tam, kde mám pod kontrolou vstupní typy (lapidárně: "vím, co mi leze dovnitř"). Pokud nevím, co mi leze dovnitř, a ukáže se to až v době běhu, pak jsem v situaci dynamického typování (aka "rozhování o typech až za běhu").

Součtový typ dokáže z různých typů udělat různé hodnoty téhož typu. Pokud si množinu možných vstupních hodnot namodeluješ součtovým typem, je Tvoje tvrzení poměrně sporné.
Mno... Součtový typ je způsob, jak dva (nebo více) typů "schovat pod jeden" - je to čistě proto, že potřebuješ, aby ti z funkce lezl jenom jeden typ. Je to technikálie, nic jiného. Nic to nemění na sémantice toho programu: dovnitř ti leze něco, o čem v době překladu nic nevíš a dozvíš se to až v době běhu - a podle toho, jestli tam bude X nebo Y, půjde program větví A nebo B.

Dalo by se argumentovat i jinak: mohl by sis vytvořit součtový typ, který by obsáhl všechny typy. Nazvěme takový typ Super. Všechny funkce nechť potom mají typ Super -> Super. Byl by takový jazyk/program podle tebe "statický" nebo "dynamický"?

No tak to zkusím rozebrat. Každý jazyk, který podporuje větvení a umí reagovat na podněty zvenčí (vstup z klávesnice, čtení ze socketu, generátor (pseudo)náhodných čísel), může prakticky ve kterémkoli místě výpočtu vytvářet hodnoty různých typů (náš příklad s explicitním čtením dat odněkud je jenom jedna z možností a to, že se ty hodnoty vytvářejí v rámci sum type v jedné funkci, to je zase jenom speciální případ).

Pokud by byl jazyk založený na pozdní vazbě, samozřejmě by šlo o dynamický jazyk/program. Jenže třeba Rust tohle nemá, nemá ani dědičnost (tedy žádné Super), implementuje pouze jednotlivé traity a překladač v každém místě ví, co se kde nachází a co se s tím smí dělat. Pokud i na něj chceš přidat nálepku "dynamický", určitě se to dá vyargumentovat, ale pak je taková nálepka neužitečná a tím i celý spor nedává smysl.
Název: Re:Co si myslíte o OOP?
Přispěvatel: BoneFlute 06. 01. 2019, 17:28:34
Zatímco příklad parsováním vstupu je naopak situace, kdy ten jazyk ví všechno.
Neví, jestli výpočet půjde cestou A nebo B, to se rozhodne až za běhu.
Ano. Což ale pro naše potřeby není vůbec důležitá informace. Ví všechno potřebné (, když tedy slovíčkaříš).

Pokud porovnáváš tuto nerozhodnost, s tupostí dynamických jazyků, tak ti udělám radost, a nebudu už v diskusi pokračovat :-P
Název: Re:Co si myslíte o OOP?
Přispěvatel: v 06. 01. 2019, 17:29:43
pro zajímavost blog Granpa Boba: https://existentialtype.wordpress.com/2011/03/19/dynamic-languages-are-static-languages/
nevím jestli souhlasím, ale zajímavé to je
Název: Re:Co si myslíte o OOP?
Přispěvatel: MartinBeran 06. 01. 2019, 17:33:10
dávám překladači najevo, že vím, že v tomhle místě programu se za běhu objeví buď integer nebo string. Dynamický jazyk vlastně říká totéž: v tomhle (každém) místě programu nevím, co za běhu bude: int, string, list, ...

Je docela rozdíl mezi "vím, že tady je string nebo int" a "vím, že tady je nějaká hodnota libovolného typu".
Název: Re:Co si myslíte o OOP?
Přispěvatel: Mirek Prýmek 06. 01. 2019, 17:37:15
Pokud porovnáváš tuto nerozhodnost, s tupostí dynamických jazyků, tak ti udělám radost, a nebudu už v diskusi pokračovat :-P
Ne. Jenom říkám, že je to "kontinuum tuposti", přičemž není pravda, že "statické jazyky" jsou vždycky a ve všech situacích úplně vlevo a dynamické vždycky úplně v pravo. Různé jazyky se v různých situacích na tom kontinuu objevují na různých místech.
Název: Re:Co si myslíte o OOP?
Přispěvatel: Mirek Prýmek 06. 01. 2019, 17:39:10
nemá ani dědičnost (tedy žádné Super)
Jestli tímhle reaguješ na to mnou zmíněné Super, tak jsi vůbec nepochopil, co jsem se snažil říct (netvrdím, že je to tvoje chyba).
Název: Re:Co si myslíte o OOP?
Přispěvatel: Mirek Prýmek 06. 01. 2019, 17:40:32
Je docela rozdíl mezi "vím, že tady je string nebo int" a "vím, že tady je nějaká hodnota libovolného typu".
Ano. Ale rozdíl mezi tím, kdy nevím, jestli je to jeden ze dvou typů nebo jeden za čtyř nebo jeden z dvaceti sedmi (kolik jich je v Pythonu?), je kvantitaivní, ne kvalitativní.
Název: Re:Co si myslíte o OOP?
Přispěvatel: v 06. 01. 2019, 17:48:02
mě snad jebne!!!
Název: Re:Co si myslíte o OOP?
Přispěvatel: baranomrd 06. 01. 2019, 17:48:31
Kecy. Sebedokonalejší typový systém za tebe kvalitní kód nevyrobí, prasit se dá v čemkoli. Mnohem více záleží na znalostech, zkušenosti a disciplíně(!) programátora. Sám jsem sice ve své víc než dvacetileté profesní praxi vždy pracoval převážně se staticky typovanými jazyky, ale nevidím ve statickém typování nijak velký přínos, co se týká bezpečnosti a vůbec kvality kódu. Způsob typování představuje jen jeden střípek ve škále vlastností jazyka a v praxi je to nakonec stejně hlavně o člověku, jeho schopnostech a přístupu, ne o nástroji. Nástroj je jen tak dobrý, jak dobrý je jeho uživatel. Kromě toho je zjevné, že dynamické a dynamicky typované jazyky si našly svou niku, ve které se prosadily, a je známkou arogance (nebo hlouposti či nezkušenosti) je jen tak spatra shazovat jako jazyky pro fušery. Ale když černobílé uvažování je tak pohodlné, že?

Počuli ste slovo Božie... Všetci čo tu vediete tie jalové debaty o typoch si toto vytlačte a zarámujte. V deň v ktorý tento text pochopíte, sa aj vy stanete programátormi. Dovtedy ste lopaty s plnou hubou rádoby odborných kecov.
Název: Re:Co si myslíte o OOP?
Přispěvatel: Mirek Prýmek 06. 01. 2019, 17:49:02
mě snad jebne!!!
Ultimátní argument ke zkvalitnění diskuse.
Název: Re:Co si myslíte o OOP?
Přispěvatel: MartinBeran 06. 01. 2019, 18:22:52
Ano. Ale rozdíl mezi tím, kdy nevím, jestli je to jeden ze dvou typů nebo jeden za čtyř nebo jeden z dvaceti sedmi (kolik jich je v Pythonu?), je kvantitaivní, ne kvalitativní.

Konečný je možná počet primitivních typů. Ale už když se přidají struktury (v C), třídy (v C++ nebo Javě), nebo se jako struktura použije hash (v Perlu) nebo dictionary (v Pythonu), tak těch typů je nekonečně (spočetně). Jestli to je kvantitativní nebo kvalitativní rozdíl je námět na dlouhou neplodnou filozofickou diskusi. Z pragmatického pohledu je to rozdíl docela důležitý. Ale souhlasím, že mezi dynamickým a statickým přístupem k typům existuje plynulý přechod.
Název: Re:Co si myslíte o OOP?
Přispěvatel: MartinBeran 06. 01. 2019, 18:40:11
Kecy. Sebedokonalejší typový systém za tebe kvalitní kód nevyrobí, prasit se dá v čemkoli. Mnohem více záleží na znalostech, zkušenosti a disciplíně(!) programátora. Sám jsem sice ve své víc než dvacetileté profesní praxi vždy pracoval převážně se staticky typovanými jazyky, ale nevidím ve statickém typování nijak velký přínos, co se týká bezpečnosti a vůbec kvality kódu. Způsob typování představuje jen jeden střípek ve škále vlastností jazyka a v praxi je to nakonec stejně hlavně o člověku, jeho schopnostech a přístupu, ne o nástroji. Nástroj je jen tak dobrý, jak dobrý je jeho uživatel. Kromě toho je zjevné, že dynamické a dynamicky typované jazyky si našly svou niku, ve které se prosadily, a je známkou arogance (nebo hlouposti či nezkušenosti) je jen tak spatra shazovat jako jazyky pro fušery. Ale když černobílé uvažování je tak pohodlné, že?

Počuli ste slovo Božie... Všetci čo tu vediete tie jalové debaty o typoch si toto vytlačte a zarámujte. V deň v ktorý tento text pochopíte, sa aj vy stanete programátormi. Dovtedy ste lopaty s plnou hubou rádoby odborných kecov.

Výše uvedený text je směs subjektivních názorů autora (já naopak po třicetiletých zkušenostech s vývojem softwaru vidím ve staticky typovaných jazycích velký přínos ke kvalitě kódu), částečně tvrzení s nízkou informační hodnotou (jak kvaltifikovat "mnohem vice", používání dynamických jazyků neimplikuje, jestli jsou lepší nebo horší než statické) a částečně obecné pravdy, které my hloupé lopaty máme už desítky let pochopené a zpracované a nemusíme je pořád omílat. Místo toho se můžeme soustředit na odbornou debatu (i když tahle je trochu moc dojmologická a dost ztrácí smysl). Ale když vidím tu slušnost schovanou v těchto dvou příspěvcích, chtě nechtě se mi na jazyk dere sousloví "pseudomanažerské kecy"  :)
Název: Re:Co si myslíte o OOP?
Přispěvatel: Mirek Prýmek 06. 01. 2019, 18:59:38
Ale už když se přidají struktury (v C), třídy (v C++ nebo Javě), nebo se jako struktura použije hash (v Perlu) nebo dictionary (v Pythonu), tak těch typů je nekonečně (spočetně).
C, C++ ani Java nejsou dynamické jazyky. A zcela záměrně jsem řekl Python. Python nemá parametrizovaný typ dictionary<K,V>, má jeden typ dictionary. Perl (zcela vědomě a záměrně) vůbec neznám.

Skoro bych tipoval, že většina dynamických jazyků bude mít spíš konečný počet typů, protože tam pro parametrizaci není tak silný důvod jako u statických jazyků.
Název: Re:Co si myslíte o OOP?
Přispěvatel: Mirek Prýmek 06. 01. 2019, 19:02:40
Jestli to je kvantitativní nebo kvalitativní rozdíl je námět na dlouhou neplodnou filozofickou diskusi.
Souhlas.
Název: Re:Co si myslíte o OOP?
Přispěvatel: MartinBeran 06. 01. 2019, 19:36:26
Ale už když se přidají struktury (v C), třídy (v C++ nebo Javě), nebo se jako struktura použije hash (v Perlu) nebo dictionary (v Pythonu), tak těch typů je nekonečně (spočetně).
C, C++ ani Java nejsou dynamické jazyky. A zcela záměrně jsem řekl Python. Python nemá parametrizovaný typ dictionary<K,V>, má jeden typ dictionary. Perl (zcela vědomě a záměrně) vůbec neznám.

Skoro bych tipoval, že většina dynamických jazyků bude mít spíš konečný počet typů, protože tam pro parametrizaci není tak silný důvod jako u statických jazyků.

Myslel jsem to tak, že často používaný typ je "record", tedy množina pojmenovaných položek, kde počet, jména a typy položek jsou součástí definice typu. V C to je struct, v C++ nebo v Javě to je class. V jazycích, které mají asociativní pole (dictionary v Pythonu, hash v Perlu) se typ record implementuje pomocí asociativního pole, které má konstatní množinu klíčů (ať už lze prostředky jazyka tuto konstantnost vynutit, nebo ne). Takových typů je nekonečno. Statická typová kontrola mi umožňuje definovat, že v konkrétním místě programu se smí vyskytovat pouze konkrétní (konečná nebo nekonečná) podmnožina všech možných typů. Při dynamickém typování se musím být schopen v každém místě umět vypořádat s kterýmkoliv z celé nekonečné množiny všech možných typů.
Název: Re:Co si myslíte o OOP?
Přispěvatel: Mirek Prýmek 06. 01. 2019, 19:46:54
Takových typů je nekonečno.
Ano, takových typů je nekonečně mnoho, ale dynamické jazyky takové typy nemají, protože je nepotřebují. Statické jazyky je mají, protože potřebují nějak označit, co "z pole vyleze". Proto pokud potřebuju v dynamickém jazyce nějak reagovat na "všechny typy", není jich zas tak moc.
Název: Re:Co si myslíte o OOP?
Přispěvatel: Inkvizitor 06. 01. 2019, 20:03:15
Myslel jsem to tak, že často používaný typ je "record", tedy množina pojmenovaných položek, kde počet, jména a typy položek jsou součástí definice typu. V C to je struct, v C++ nebo v Javě to je class. V jazycích, které mají asociativní pole (dictionary v Pythonu, hash v Perlu) se typ record implementuje pomocí asociativního pole, které má konstatní množinu klíčů (ať už lze prostředky jazyka tuto konstantnost vynutit, nebo ne). Takových typů je nekonečno. Statická typová kontrola mi umožňuje definovat, že v konkrétním místě programu se smí vyskytovat pouze konkrétní (konečná nebo nekonečná) podmnožina všech možných typů. Při dynamickém typování se musím být schopen v každém místě umět vypořádat s kterýmkoliv z celé nekonečné množiny všech možných typů.

Python má historicky dva různé způsoby vytváření "recordu" - dictionary (pohodlnější) a class (těžkopádnější, ale systémovější). V poslední době přišly dvě novinky - named tuple a dataclass, protože prostě ani dictionary (nejdynamičtější řešení z dynamických) ani "normální" třída nejsou zase tak moc super. To je, spolu s dalšími změnami včetně anotací typů odpověď vývojářů jazyka na otázku, zda by se příklon ke statickým programovacím jazykům přece jenom občas nehodil.
Název: Re:Co si myslíte o OOP?
Přispěvatel: MartinBeran 06. 01. 2019, 20:08:47
Takových typů je nekonečno.
Ano, takových typů je nekonečně mnoho, ale dynamické jazyky takové typy nemají, protože je nepotřebují. Statické jazyky je mají, protože potřebují nějak označit, co "z pole vyleze". Proto pokud potřebuju v dynamickém jazyce nějak reagovat na "všechny typy", není jich zas tak moc.

Statické jazyky mají typy "record", protože v mnoha situacích je to přirozený způsob reprezentace dat (osoba = {jméno, příjmení, datum_narození}). Taková reprezentace dat je v dynamických jazycích potřeba úplně stejně. A i v dynamickém jazyce potřebuju zareagovat na to, když místo hodnoty typu osoba dostanu hodnotu typu osoba = {jméno, příjmení, přezdívka, adresa}). Např. v Perlu pro tohle existuje částečná podpora, protože můžu fixovat množinu přípustných klíčů pro konkrétní hodnotu typu hash, což se ale pořád kontroluje za běhu programu.
Název: Re:Co si myslíte o OOP?
Přispěvatel: Mirek Prýmek 06. 01. 2019, 20:16:34
Taková reprezentace dat je v dynamických jazycích potřeba úplně stejně.
Není.
Název: Re:Co si myslíte o OOP?
Přispěvatel: Mirek Prýmek 06. 01. 2019, 20:23:49
Python má historicky dva různé způsoby vytváření "recordu" - dictionary (pohodlnější) a class (těžkopádnější, ale systémovější). V poslední době přišly dvě novinky - named tuple a dataclass, protože prostě ani dictionary (nejdynamičtější řešení z dynamických) ani "normální" třída nejsou zase tak moc super.
To všechno je ale pod kapotou netypovaný dict. viz x.__dict__

To je, spolu s dalšími změnami včetně anotací typů odpověď vývojářů jazyka na otázku, zda by se příklon ke statickým programovacím jazykům přece jenom občas nehodil.
Příklon ke statičnosti se hodí vždycky, to může popírat jenom někdo s hodně velkýma klapkama na očích.
Název: Re:Co si myslíte o OOP?
Přispěvatel: Mirek Prýmek 06. 01. 2019, 20:24:47
To všechno je ale pod kapotou netypovaný dict. viz x.__dict__
On možná lepší příklad než Python by byl JS nebo Lua...
Název: Re:Co si myslíte o OOP?
Přispěvatel: BoneFlute 06. 01. 2019, 20:30:23
Proto pokud potřebuju v dynamickém jazyce nějak reagovat na "všechny typy", není jich zas tak moc.
To je sice možné, ale když si mám vybrat mezi: kontrolovat, zda přišel správný typ, a pokud ne, tak chcípnout; a mezi tím, že vždy přijde správný typ...
Název: Re:Co si myslíte o OOP?
Přispěvatel: Mirek Prýmek 06. 01. 2019, 20:31:51
To je sice možné, ale když si mám vybrat mezi: kontrolovat, zda přišel správný typ, a pokud ne, tak chcípnout; a mezi tím, že vždy přijde správný typ...
Souhlasím, ale to jsi skočil do jiného tématu. My jsme pořád ještě u toho, že dynamické typování je vlastně jenom takový "trochu širší" součtový typ :)
Název: Re:Co si myslíte o OOP?
Přispěvatel: Kit 06. 01. 2019, 20:36:25
To je, spolu s dalšími změnami včetně anotací typů odpověď vývojářů jazyka na otázku, zda by se příklon ke statickým programovacím jazykům přece jenom občas nehodil.
Příklon ke statičnosti se hodí vždycky, to může popírat jenom někdo s hodně velkýma klapkama na očích.

Statické typy používám v PHP také, ale jen tam, kde to dává smysl - zejména v rozhraní. V kolekcích už význam nemají.

Dynamické typování přináší jednu užitečnou vlastnost: Program je možné snadno řídit tokem dat.
Název: Re:Co si myslíte o OOP?
Přispěvatel: Kit 06. 01. 2019, 20:39:11
Proto pokud potřebuju v dynamickém jazyce nějak reagovat na "všechny typy", není jich zas tak moc.
To je sice možné, ale když si mám vybrat mezi: kontrolovat, zda přišel správný typ, a pokud ne, tak chcípnout; a mezi tím, že vždy přijde správný typ...

Proč by měl program v dynamicky typovaném jazyce chcípat, když nepřijde ten správný typ? Tenhle FUD opakuješ pořád dokola. Zbytečně.
Název: Re:Co si myslíte o OOP?
Přispěvatel: BoneFlute 06. 01. 2019, 20:46:09
To je sice možné, ale když si mám vybrat mezi: kontrolovat, zda přišel správný typ, a pokud ne, tak chcípnout; a mezi tím, že vždy přijde správný typ...
Souhlasím, ale to jsi skočil do jiného tématu. My jsme pořád ještě u toho, že dynamické typování je vlastně jenom takový "trochu širší" součtový typ :)
Pardon :-)

Já si myslím, že není. Protože dynamické typování je úplně jiná (samozřejmě špatná) filozofie programování. Ale nerad bych se opakoval. :-)
Název: Re:Co si myslíte o OOP?
Přispěvatel: Mirek Prýmek 07. 01. 2019, 00:47:42
Já si myslím, že není. Protože dynamické typování je úplně jiná (samozřejmě špatná) filozofie programování. Ale nerad bych se opakoval. :-)
To se nevylučuje. Používat v celém programu takhle široký součtový typ je úplně jiná (podle někoho samozřejmě špatná) filosofie programování ;)
Název: Re:Co si myslíte o OOP?
Přispěvatel: BoneFlute 07. 01. 2019, 01:31:54
Já si myslím, že není. Protože dynamické typování je úplně jiná (samozřejmě špatná) filozofie programování. Ale nerad bych se opakoval. :-)
To se nevylučuje. Používat v celém programu takhle široký součtový typ je úplně jiná (podle někoho samozřejmě špatná) filosofie programování ;)

Nejde o to, že je špatná.

Když napíšu staticky typovanej program, tak je to jako když si vypálím cestičky, kterým potom tečou data. Ty jednotlivé typy kontrolujou, zda jsou jednotlivé cesty na sebe správně napojený. Druhý význam typů je, že určuje odbočky. Například parsování čísla.
V dynamickém jazyce typy slouží jako aserty při vstupech. A jako informace, podle kterého může (ale nemusí) můj if udělat odbočku (ve statickém jazyce si tu odbočku musím připravit).

Kód: [Vybrat]
type Person = {name: String, surname: String, age: Int}

parsePerson(s: String) : Maybe Person = ...

str.concat (a: String, b: String) = ...

readIO(io) =
    case (parsePerson(io.read())):
        Just x -> console.log str.concat("person: ", x)
        Nothing -> console.error "Je třeba definice Person."
Dá se to zapsat v statickém i dynamickém jazyce. V obou použiju stejný druh typu. Dokonce stejnou konstrukci (ač u dynamických jazyků jsou obvyklejší výjimky). Jenže dynamický jazyk tu chybu pustí.

Přijde mi, že se používá stejný nástroj (typ), ale každý úplně jiným způsobem.
Název: Re:Co si myslíte o OOP?
Přispěvatel: Mirek Prýmek 07. 01. 2019, 01:40:27
Asi se už dost opakujeme, ale tak co už :) Ve všem souhlas, jenom tomuhle nerozumím:

Jenže dynamický jazyk tu chybu pustí.

V dynamickém jazyce bude výsledkem parsePerson buď hodnota typu Person nebo výjimka, ve statickém buď Just Person nebo Nothing. Nevidím tam žádný zásadní "světodějný" rozdíl. Jediný rozdíl, který tam vidím (a souhlasím, že je docela podstatný), je, že statický jazyk tě donutí obě varianty explicitně ošetřit, zatímco dynamický tě klidně nechá výjimku nechat probublat až do main a nechat program spadnout v produkci :)
Název: Re:Co si myslíte o OOP?
Přispěvatel: BoneFlute 07. 01. 2019, 02:06:26
Asi se už dost opakujeme, ale tak co už :) Ve všem souhlas, jenom tomuhle nerozumím:

Jenže dynamický jazyk tu chybu pustí.

V dynamickém jazyce bude výsledkem parsePerson buď hodnota typu Person nebo výjimka, ve statickém buď Just Person nebo Nothing. Nevidím tam žádný zásadní "světodějný" rozdíl. Jediný rozdíl, který tam vidím (a souhlasím, že je docela podstatný), je, že statický jazyk tě donutí obě varianty explicitně ošetřit, zatímco dynamický tě klidně nechá výjimku nechat probublat až do main a nechat program spadnout v produkci :)

V tom řádku s Just je právě schválně chyba. Kde statický jazyk si "všimne" při překladu, že x není string. To považuju za dost "světodějný".
Název: Re:Co si myslíte o OOP?
Přispěvatel: Mirek Prýmek 07. 01. 2019, 02:11:31
V tom řádku s Just je právě schválně chyba. Kde statický jazyk si "všimne" při překladu, že x není string. To považuju za dost "světodějný".
Ajo, promiň, toho jsem si nevšiml. Ale co tím demonstruješ? Jenom to, že statické jazyky umí některé chyby odhalit už v době překladu. To ale přece všichni víme, ne?!

A proč to demonstrovat tak krkolomně? Stačilo úplně:

Kód: [Vybrat]
def some_func_anywhere():
  return 1 + "x"
- Python ti tohle ochotně pustí do produkce i když by to krásně mohl odhalit. No, je to tak, dělá míň práce, než by mohl :)
Název: Re:Co si myslíte o OOP?
Přispěvatel: Kit 07. 01. 2019, 02:12:03
Asi se už dost opakujeme, ale tak co už :) Ve všem souhlas, jenom tomuhle nerozumím:
Jenže dynamický jazyk tu chybu pustí.
V dynamickém jazyce bude výsledkem parsePerson buď hodnota typu Person nebo výjimka, ve statickém buď Just Person nebo Nothing. Nevidím tam žádný zásadní "světodějný" rozdíl. Jediný rozdíl, který tam vidím (a souhlasím, že je docela podstatný), je, že statický jazyk tě donutí obě varianty explicitně ošetřit, zatímco dynamický tě klidně nechá výjimku nechat probublat až do main a nechat program spadnout v produkci :)

Nevidím důvod, proč by v dynamicky typovaném jazyce měla aplikace padat v produkci. Ovšem pokud někdo píše testy jen podle metrik...

Statické typy neodhalí logickou chybu v kódu. V tom případě bude vývojář spokojen, že se mu aplikace hezky zkompilovala, ale bude mu produkovat vadná data - což je ještě horší, než kdyby na té produkci spadla.
Název: Re:Co si myslíte o OOP?
Přispěvatel: Mirek Prýmek 07. 01. 2019, 02:19:38
Nevidím důvod, proč by v dynamicky typovaném jazyce měla aplikace padat v produkci. Ovšem pokud někdo píše testy jen podle metrik...
Mohl úplně jednoduše na otestování nějakého edge casu zapomenout. Probublal mu None někam, kde správně neměl být povolený, uložilo se to na disk, nikdo na ty data deset let nešáhl a nikdo už dneska neví, že tam kdysi None být mohl.

Jistě, můžeš si vymýšlet pohádky o tom, že to byla změna kontraktu, která měla být zaznamenána do dokumentace a bla bla bla. Ať si ten důvod pojmenuješ jak chceš, tak výsledek je stejný: spadlo to v produkci.
Název: Re:Co si myslíte o OOP?
Přispěvatel: Kit 07. 01. 2019, 02:20:49
A proč to demonstrovat tak krkolomně? Stačilo úplně:
Kód: [Vybrat]
def some_func_anywhere():
  return 1 + "x"
- Python ti tohle ochotně pustí do produkce i když by to krásně mohl odhalit. No, je to tak, dělá míň práce, než by mohl :)

Nepustí:
Kód: [Vybrat]
File "list.py", line 11, in some_func_anywhere
    return 1 + "x"
TypeError: unsupported operand type(s) for +: 'int' and 'str'
Název: Re:Co si myslíte o OOP?
Přispěvatel: Mirek Prýmek 07. 01. 2019, 02:22:09
Nepustí:
No dobře, tak ten string bude trochu víc zakuklenej no. Třeba do atributu.
Název: Re:Co si myslíte o OOP?
Přispěvatel: BoneFlute 07. 01. 2019, 03:23:17
Ajo, promiň, toho jsem si nevšiml. Ale co tím demonstruješ? Jenom to, že statické jazyky umí některé chyby odhalit už v době překladu. To ale přece všichni víme, ne?!

Pokoušel jsem se na ladit ne ten váš problém, co řešíte. Evidentně se mi to nepovedlo :-)
Název: Re:Co si myslíte o OOP?
Přispěvatel: Mirek Prýmek 07. 01. 2019, 03:27:37
Pokoušel jsem se na ladit ne ten váš problém, co řešíte. Evidentně se mi to nepovedlo :-)
Ne, nepovedlo :) Pointa je v tom, že v obou systémech se program větví na základě typu a v obou k tomu dojde až za běhu.

To, co's udělal, je, že jsi do té jedné větve dal chybu, kterou dynamický jazyk neodhalí. Ale tím jsi nic nového neřekl - je totiž úplně jedno, jestli takovou chybu dáš hned na začátek té větve (hned ze matchnutí Just x) nebo až někam za deset jiných volání jiných funkcí :) Prostě pořád je to ta samá chyba.
Název: Re:Co si myslíte o OOP?
Přispěvatel: BoneFlute 07. 01. 2019, 03:46:54
Ne, nepovedlo :) Pointa je v tom, že v obou systémech se program větví na základě typu a v obou k tomu dojde až za běhu.
Ale jen u toho dynamického dojde za běhu k tomu "vymejšlení". (Což je ale také věc, kde záleží na tom, jak se to vezme.)

Čo chceš dokázat?
Název: Re:Co si myslíte o OOP?
Přispěvatel: v 07. 01. 2019, 08:54:05
Nepustí:
No dobře, tak ten string bude trochu víc zakuklenej no. Třeba do atributu.
pustí i bez kukly
Kód: [Vybrat]
>>> def some_func_anywhere():
...   return 1 + "x"
...
>>> some_func_anywhere()
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "<stdin>", line 2, in some_func_anywhere
TypeError: unsupported operand type(s) for +: 'int' and 'str'
>>>
Název: Re:Co si myslíte o OOP?
Přispěvatel: SB 07. 01. 2019, 09:30:32
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.
Tak jinak - jak by podle tebe vypadala implementace polymorfismu tak, jak je chápán v objektovém paradigmatu, prostředky (nikoli jejich obcházením) staticky typovaného prostředí?

- Pro komunikaci objektů by se používalo zasílání zpráv (jinak by to nebylo OOP a nefungoval bezpodmínečný polymorfismus), takže jakémukoliv objektu by šlo zaslat jakoukoliv zprávu bez ohledu na typ cíle.
- Zpráva by obsahovala mimo názvu metody a parametrů i (třeba i jen volitelně) jejich typ a požadovaný typ návratové hodnoty, čímž by dohledávání metody objektem nepodléhalo pouze názvu a počtu parametrů, ale i typům parametrů a návratové hodnoty (dle pravidla Liskovové).
Název: Re:Co si myslíte o OOP?
Přispěvatel: Mirek Prýmek 07. 01. 2019, 09:36:36
(dle pravidla Liskovové).
A ještě lepší by bylo tam podtypový polymorfismus vůbec nemít, ušetřili bysme si spoustu bolehlavů ;)
Název: Re:Co si myslíte o OOP?
Přispěvatel: SB 07. 01. 2019, 09:43:51
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.
Neobjektové konstrukce nejsou zbytečné, python není oop jazyk, ale hybridní. Jestli mu neco vycist, tak to, ze by default krome len(list) neumi i list.len(). Zapouzdreni ma. Proc povazujete dekoratory za nekoncepcni? Python nepouziva modifikujici klicova slova, ale obecneji fungujici a uzivatelsky nastavitelne dekorarory, coz je koncept.

A jaký má smysl zavádět imperativní konstrukce s objekty, jestliže je to bez přínosu a komplikuje to jazyk i jeho implementaci?
Opravdu se tu nehodlám dohadovat s někým, co je to zapouzdření a zda jej má Python, OPRAVDU NE!
Proč tedy není i u instanční metody anotace "@instancemethod"?
Název: Re:Co si myslíte o OOP?
Přispěvatel: nzn 07. 01. 2019, 09:45:17
To všechno je ale pod kapotou netypovaný dict. viz x.__dict__
Ne že by to v diskusi bylo podstatné, ale ne vše je zakuklený dict, viz __slots__ (ono pro malé třídy je dict dost overkill).
Název: Re:Co si myslíte o OOP?
Přispěvatel: Mirek Prýmek 07. 01. 2019, 09:49:08
Ne že by to v diskusi bylo podstatné, ale ne vše je zakuklený dict, viz __slots__ (ono pro malé třídy je dict dost overkill).
To je ale jenom optimalizace, která pro to, o čem se bavíme, nejenom že není podstatná, ale nemá to vůbec žádný vliv.
Název: Re:Co si myslíte o OOP?
Přispěvatel: SB 07. 01. 2019, 10:07:47
Viděl jsi často, že by hostinský točil pivo do papírové krabice, přestože mu v tom nic nebrání? Jistě by šlo zařídit, aby se pípa odjistila jen v případě, že pod sebou detekuje konkrétně určený značkový půllitr. Mě by popadl rapl a ta pípa by letěla na smetiště hned v okamžiku, kdy by mi odmítala pustit pivo do džbánku.
Smysl statických typů je zajistit, aby se něco takového nestalo. Když zůstaneme u přirovnání, tak ty budeš muset hostinského zaškolit, a ještě nainstalovat kameru, aby si ho sledoval, zda nečepuje pivo přímo do pusy. A stejně ho neuhlídáš. Zatímco já tam budu moct dát cedulku "samoobslužná pípa".


Nemá smysl řešit, že použijete např. typový seznam, když to potřebujete. Problémem u statických jazyků je použití seznamu v případě, kdy v něm potřebujete různé prvky.

Příklad: Mám batoh s danou nosností a objemem a (netypový) seznam blíže neurčených předmětů (= nezajímá mě, co to je), jejichž jediným společným prvkem (a to ještě ne nutně) je, že odpovídají na zprávu "hmotnost" a "velikost", a chci zjistit, zda se mi do toho batohu vlezou. Jak se to řeší typovaným seznamem???
Název: Re:Co si myslíte o OOP?
Přispěvatel: SB 07. 01. 2019, 10:13:35
Pak samozřejmě můžeš dojít k závěru, že nevíš, a že tam chceš dát cokoliv. Tak dáš typ *, a budeš tam moct uložit opravdu cokoliv.

Vizte můj příspěvek dříve: Není problémem vytvořit seznam s prvky typu objekt a najebat do něj cokoliv, problémem je potom nad tímto seznamem spustit sumu na vlastnost "cena" nebo "objem". Jak se to udělá v statickém jazyku?
Název: Re:Co si myslíte o OOP?
Přispěvatel: Mirek Prýmek 07. 01. 2019, 10:16:55
Příklad: Mám batoh s danou nosností a objemem a (netypový) seznam blíže neurčených předmětů (= nezajímá mě, co to je), jejichž jediným společným prvkem (a to ještě ne nutně) je, že odpovídají na zprávu "hmotnost" a "velikost", a chci zjistit, zda se mi do toho batohu vlezou. Jak se to řeší typovaným seznamem???
Proč je tam to "ne nutně"? Pokud chci zjistit, jestli se mi tam vlezou, pak musí na ty zprávu odpovídat nutně, jinak nemůžu rozhodnout, jestli se mi tam vlezou.

Pak taky není pravda to "netypový" a "nezajímá mě, co to je". "Netypový" by znamenalo, že o těch objektech nemám vůbec žádnou informaci. Já ale nějakou mám: odpovídají na zprávu "hmotnost" a "velikost". To je typ.  (Odbočka: ) Přesvědčení, že to typ není, vychází imho z internalizace zparchantělého OOP založeného jenom na dědičnosti.

Jak by se to vyřešilo? Snadno. Už víme, že ty objekty mají nějaký typ. Stačí ho pojmenovat (např. HasWeightAndDimension) a pak už snadno můžu říct, že pracuju s polem HasWeightAndDimension[].

Jak to přesně technicky udělat, na to asi bude víc způsobů. Jeden konkrétní je třeba ten, který ma Go: struktury implementují rozhraní implicitně - tj. jakmile jsou pro strukturu definované všechny potřebné metody, je interface implementovaný, není potřeba to explicitně prohlašovat.
Název: Re:Co si myslíte o OOP?
Přispěvatel: SB 07. 01. 2019, 10:19:15

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

Není problémem zapracovat další zvláštní, pojmenovaná uspořádání.
Název: Re:Co si myslíte o OOP?
Přispěvatel: v 07. 01. 2019, 10:23:41
Viděl jsi často, že by hostinský točil pivo do papírové krabice, přestože mu v tom nic nebrání? Jistě by šlo zařídit, aby se pípa odjistila jen v případě, že pod sebou detekuje konkrétně určený značkový půllitr. Mě by popadl rapl a ta pípa by letěla na smetiště hned v okamžiku, kdy by mi odmítala pustit pivo do džbánku.
Smysl statických typů je zajistit, aby se něco takového nestalo. Když zůstaneme u přirovnání, tak ty budeš muset hostinského zaškolit, a ještě nainstalovat kameru, aby si ho sledoval, zda nečepuje pivo přímo do pusy. A stejně ho neuhlídáš. Zatímco já tam budu moct dát cedulku "samoobslužná pípa".


Nemá smysl řešit, že použijete např. typový seznam, když to potřebujete. Problémem u statických jazyků je použití seznamu v případě, kdy v něm potřebujete různé prvky.

Příklad: Mám batoh s danou nosností a objemem a (netypový) seznam blíže neurčených předmětů (= nezajímá mě, co to je), jejichž jediným společným prvkem (a to ještě ne nutně) je, že odpovídají na zprávu "hmotnost" a "velikost", a chci zjistit, zda se mi do toho batohu vlezou. Jak se to řeší typovaným seznamem???

jedna z obecnějších možností:
Kód: [Vybrat]
{-# LANGUAGE ExistentialQuantification, ConstraintKinds, GADTs #-}

data Ex c = forall x. c x => Ex x

instance x ~ Show => Show (Ex x) where
    show (Ex x) = show x

xxx :: [Ex Show]
xxx = [Ex (), Ex 2, Ex "3"]

main = print xxx
Název: Re:Co si myslíte o OOP?
Přispěvatel: JS 07. 01. 2019, 10:24:32
Pak samozřejmě můžeš dojít k závěru, že nevíš, a že tam chceš dát cokoliv. Tak dáš typ *, a budeš tam moct uložit opravdu cokoliv.

Vizte můj příspěvek dříve: Není problémem vytvořit seznam s prvky typu objekt a najebat do něj cokoliv, problémem je potom nad tímto seznamem spustit sumu na vlastnost "cena" nebo "objem". Jak se to udělá v statickém jazyku?

V Haskellu existuje vic moznosti, jak na to. Muzeme si definovat typovou tridu (neco jako interface) a definovat jeji instance pro kazdy z tech typu. Druha moznost je pouzit plnohodnotne dynamicke typy - typ Data.Dynamic v Haskellu.

Cela ta otazka je tak trochu strawman. Ve staticky typovanych jazycich se samozrejme muzeme typove kontroly zbavit, v pripadech, kdy to proste staticky typove zkontrolovat nelze. To je ten trivialni smer. Potiz je v tom opacnem smeru - pridat do dynamicky typovaneho jazyka statickou typovou kontrolu, aniz bychom do nich pridali typechecker.
Název: Re:Co si myslíte o OOP?
Přispěvatel: SB 07. 01. 2019, 10:37:33
Fakt nechápu, co tu řešíte. Když vemu ten úžasný Python, tak pokud mám methodu:
Kód: [Vybrat]
def get_record(self, data):
Tak co ta metoda vrací? A co jí mám poslat? Fakt někdo chce takový jazyk používat na víc než na hraní a skriptíky?

Tak především jste v uvedeném případě udělal jednu z nejzákladnějších a nejhorších chyb v psaní kódu (standard většiny "vývojářů"), to je, že jste špatně pojmenoval jak metodu, tak její druhý parametr nicneříkajícím označením. A jestli si myslíte, že typovaně

Propocet get_record(Object self, Integer data)

to bude lepší, tak se mýlíte.

Název: Re:Co si myslíte o OOP?
Přispěvatel: krasty 07. 01. 2019, 10:47:19
hovna tecou proudem
Název: Re:Co si myslíte o OOP?
Přispěvatel: SB 07. 01. 2019, 11:15:10
...Ale type-hinting bude furt slabej proti plnohodnotnému statickému systému.

Samozřejmě. Na druhou stranu existuje nějaký ten "plnohodnotný" statický systém? Ať se tu nebavíme o něčem nedosažitelném.
Název: Re:Co si myslíte o OOP?
Přispěvatel: M 07. 01. 2019, 11:44:38
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.
Neobjektové konstrukce nejsou zbytečné, python není oop jazyk, ale hybridní. Jestli mu neco vycist, tak to, ze by default krome len(list) neumi i list.len(). Zapouzdreni ma. Proc povazujete dekoratory za nekoncepcni? Python nepouziva modifikujici klicova slova, ale obecneji fungujici a uzivatelsky nastavitelne dekorarory, coz je koncept.

A jaký má smysl zavádět imperativní konstrukce s objekty, jestliže je to bez přínosu a komplikuje to jazyk i jeho implementaci?
Opravdu se tu nehodlám dohadovat s někým, co je to zapouzdření a zda jej má Python, OPRAVDU NE!
Proč tedy není i u instanční metody anotace "@instancemethod"?

@ není anotace, ale dekorátor. Takovou classmethod si můžete zjednodušeně představit jako wrapper který implementuje interface deskriptoru (__get__). Když python na třídě nebo objektu narazí na deskriptor, tak přenechá implementaci chování toho, co se má vrátit, tomu deskriptoru. A classmethod udělá to, že tu funkci nabinduje ne na objekt, ale na jeho třídu. Jakákoliv funkce sama o sobě má taky metodu __get__, takže pokud je ta funkce položená na třídě, tak při přístupu z instance objektu se vrátí nabindovaná na instanci toho objektu a při volání dostane jako první argument objekt. S deskriptory a __getattribute__/__setattribute__ protokolem se dá hodně vyhrát, myslím si, že i řízení přístupu by se s určitým performance hitem dalo vyrobit, ale proč bych to dělal ...

Ty "neobjektové" funkce si představte jako implementaci určitého protokolu. Díky duck typingu nemusí mít objekt miliardy metod pro všechny možné situace. Proto také můžou existovat věci jako len(), iter(), next(), ... které ho využívají. Pokud vím, že něco je kolekce, len() na to bude fungovat a určitým postupem zjistí, kolik je v ní prvků. Taky můžu udělat např. max(map(len, iterable)). max(map(lambda i: i.len(), iterable)) by bylo krkolomnější. Rubysta by namítl, že iterable.collect(&:len) je lepší, ale každý jazyk má své vlastnosti :)

Dokonce se v pythonu dá udělat isinstance({}, Mapping), kde mapping není rodič třídy dict a přesto to vrátí True. Mapping je totiž ABC třída, která definuje jaké metody má mít něco, co se dá považovat za Mapping. A pokud je objekt má, není nejmenší pochyb o tom, jestli se chová jako Mapping nebo ne.
Název: Re:Co si myslíte o OOP?
Přispěvatel: SB 07. 01. 2019, 12:38:27
Funkce get_peer_address() je buď metoda třídy network_socket bez parametrů, nebo je to samostatná funkce (nebo klidně metoda třídy address_extractor) s jedním parametrem typu network_socket.

Jak dostane ta "samostatná funkce", nebo třída address_extractor z toho socketu tu adresu???

Návratová hodnota je typu socket_address, což je polymorfní typ zahrnující IPv4, IPv6 i řetězce (používané jako jména UNIX domain socketů).

Co je to "polymorfní typ"?

Testy už píšu jen na ověření chování této funkce se smysluplnými typy parametrů.

Jasně, když je to jen pro smysluplné typy parametrů, tak to vlastně testy ani nejsou.
Název: Re:Co si myslíte o OOP?
Přispěvatel: SB 07. 01. 2019, 12:49:21
K tomu mě napadá akademická otázka: Dá se pro libovolný program napsat testovací sada, která nalezne všechny chyby, jež by nalezla statická typová kontrola, a přitom nebude zahrnovat (jakkoliv zakamuflovanou) statickou typovou kontrolu?

Přeloženo: Dá se mechanismus statické kontroly nahradit jiným mechanismem statické kontroly, aniž by byl tomu prvnímu podobný? (Jestli jsem to správně pochopil, předpokládá se formální kontrola zdrojáku, ne běhová.)

Jaký má daná snaha smysl?
Název: Re:Co si myslíte o OOP?
Přispěvatel: Kit 07. 01. 2019, 13:16:39
Fakt nechápu, co tu řešíte. Když vemu ten úžasný Python, tak pokud mám methodu:
Kód: [Vybrat]
def get_record(self, data):
Tak co ta metoda vrací? A co jí mám poslat? Fakt někdo chce takový jazyk používat na víc než na hraní a skriptíky?

Tak především jste v uvedeném případě udělal jednu z nejzákladnějších a nejhorších chyb v psaní kódu (standard většiny "vývojářů"), to je, že jste špatně pojmenoval jak metodu, tak její druhý parametr nicneříkajícím označením. A jestli si myslíte, že typovaně

Propocet get_record(Object self, Integer data)

to bude lepší, tak se mýlíte.

Velmi výstižné. Hlavně však nepoužívat v těch názvech maďarskou notaci. Když pak někdo změní typ dat, vypadá to fakt blbě a metoda se musí zbytečně přejmenovávat.
Název: Re:Co si myslíte o OOP?
Přispěvatel: Kit 07. 01. 2019, 13:24:18
K tomu mě napadá akademická otázka: Dá se pro libovolný program napsat testovací sada, která nalezne všechny chyby, jež by nalezla statická typová kontrola, a přitom nebude zahrnovat (jakkoliv zakamuflovanou) statickou typovou kontrolu?

Přeloženo: Dá se mechanismus statické kontroly nahradit jiným mechanismem statické kontroly, aniž by byl tomu prvnímu podobný? (Jestli jsem to správně pochopil, předpokládá se formální kontrola zdrojáku, ne běhová.)

Jaký má daná snaha smysl?

O něco podobného se snaží například PHPStan. Smyslem je udělat zdrojáky čitelnější, s menším množstvím záludností. Ovšem pojmenování věcí, které je pro OOP zásadní, neřeší. Nemá ani jak.
Název: Re:Co si myslíte o OOP?
Přispěvatel: SB 07. 01. 2019, 15:06:35
(dle pravidla Liskovové).
A ještě lepší by bylo tam podtypový polymorfismus vůbec nemít, ušetřili bysme si spoustu bolehlavů ;)

Do důsledku vzato pak ale rovnou můžu říct, že typované zprávy jsou na hovno, a pořeším si ověření parametrů na začátku metody jak chci, do jaké hloubky chci a podle čeho chci, čímž se opět vracíme k tomu, že samotná typová kontrola nemusí stačit.
Název: Re:Co si myslíte o OOP?
Přispěvatel: SB 07. 01. 2019, 15:29:31
Příklad: Mám batoh s danou nosností a objemem a (netypový) seznam blíže neurčených předmětů (= nezajímá mě, co to je), jejichž jediným společným prvkem (a to ještě ne nutně) je, že odpovídají na zprávu "hmotnost" a "velikost", a chci zjistit, zda se mi do toho batohu vlezou. Jak se to řeší typovaným seznamem???
Proč je tam to "ne nutně"? Pokud chci zjistit, jestli se mi tam vlezou, pak musí na ty zprávu odpovídat nutně, jinak nemůžu rozhodnout, jestli se mi tam vlezou.

Je to tam schválně, protože se dokonce v krajním případě můžu rozhodnout, že co neodpoví na zprávu (ověřením odpovídatelnosti objektu, nebo zachycením chyby), buďto do batohu nepůjde, nebo celá metoda vrátí chybu, nebo odpověď False, nebo já nevím co. Prostě se můžu rozhodnout, aniž bych věděl, co za bordel v tom seznamu je.

Pak taky není pravda to "netypový" a "nezajímá mě, co to je". "Netypový" by znamenalo, že o těch objektech nemám vůbec žádnou informaci. Já ale nějakou mám: odpovídají na zprávu "hmotnost" a "velikost". To je typ.  (Odbočka: ) Přesvědčení, že to typ není, vychází imho z internalizace zparchantělého OOP založeného jenom na dědičnosti.

Jak by se to vyřešilo? Snadno. Už víme, že ty objekty mají nějaký typ. Stačí ho pojmenovat (např. HasWeightAndDimension) a pak už snadno můžu říct, že pracuju s polem HasWeightAndDimension[].

Přesně!
Nezajímá mě ve smyslu statických typů. Píšete to správně, za typ "weight" můžeme považovat i schopnost odpovídat na zprávu "weight", pak tyto "vícetypové" objekty se vzájemně různě prolínají v některých typech. Lepší by bylo ale označovat je za "vzájemně polymorfní v metodách", či "vzájemně polymorfní v nějaké jejich společné části protokolu". Neboli v Kayově (zprávovém) OOP nejde o polymorfismus typový/třídní (nekteré objekty typ ani mít nemusejí, třeba ad-hoc), ale polymorfismus zprávový/protokolový (třeba i jen částečný).
Je to tak?

Jak to přesně technicky udělat, na to asi bude víc způsobů. Jeden konkrétní je třeba ten, který ma Go: struktury implementují rozhraní implicitně - tj. jakmile jsou pro strukturu definované všechny potřebné metody, je interface implementovaný, není potřeba to explicitně prohlašovat.

To je ale opět onen protokol objektu.
Název: Re:Co si myslíte o OOP?
Přispěvatel: MartinBeran 07. 01. 2019, 15:32:54
Funkce get_peer_address() je buď metoda třídy network_socket bez parametrů, nebo je to samostatná funkce (nebo klidně metoda třídy address_extractor) s jedním parametrem typu network_socket.

Jak dostane ta "samostatná funkce", nebo třída address_extractor z toho socketu tu adresu???

Původně jsem reagoval na návrh, že výpis informací o objektu nemá dělat metoda print(), ale samostatná třída Printer. Ta se taky musí nějak dostat k informacím, které má vypsat. Třída address_extractor funguje v principu stejně.

Návratová hodnota je typu socket_address, což je polymorfní typ zahrnující IPv4, IPv6 i řetězce (používané jako jména UNIX domain socketů).

Co je to "polymorfní typ"?

https://en.cppreference.com/w/cpp/language/object#Polymorphic_objects (https://en.cppreference.com/w/cpp/language/object#Polymorphic_objects)