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: Wavelet 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: Wavelet 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: Wavelet 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)

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.

I když vím, že get_peer_address dostane socket, musím otestovat, že ze socketu extrahuje a vrátí správnou adresu a ne nějaká náhodná data. Jenom se nemusím zabývat testováním reakce na situaci, kdy dostane něco jiného než socket, protože statická typová kontrola zajistí, že to nemůže nastat.
Název: Re:Co si myslíte o OOP?
Přispěvatel: MartinBeran 07. 01. 2019, 15:41:42
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?

Reagoval jsem na tvrzení, že místo statické typové kontroly mohu použít dynamickou typovou kontrolu a testy. Statická typová kontrola zabrání určité třídě chyb v programu, protože nepovolí použití neočekávaných typů. Pokud mají být testy plnohodnotnou náhradou, měly by všechny tyto chyby odchytit taky (nepřu se o to, že testy mohou zachytit i spoustu jiných chyb, na které naopak nestačí typová kontrola). Je mi celkem jedno, jak budou testy vypadat, ale aby odpověď nebyla triviální, neměly by zahrnovat nic, co je jen převlečená statická typová kontrola přesunutá z kompilátoru do testovacího prostředí (tedy žádná statická analýza zdrojáků s použitím typových anotací).
Název: Re:Co si myslíte o OOP?
Přispěvatel: SB 07. 01. 2019, 15:58:07
@ není anotace, ale dekorátor. Takovou classmethod si můžete zjednodušeně představit...

Je mi buřt, jak se to jmenuje (dekorátor je pro mě návrhový vzor), vnitřní implementace je nepodstatná. Představoval bych si, že vedle klíčového slova def tu bude např. classdef, aby bylo jasné, co je definováno na třídní a co na instanční straně. Tyto anotace/dekorátory na mě dělají dojem dobastlovaného jazyku.

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

Nechápu. Proč budu "určitým postupem" zjišťovat, kolik je v kolekci prvků, když se jí můžu rovnou zeptat? Oč jsou uvedené funkce jednodušší, koncepčnější a přehlednější než seznam.len(), seznam.forEach(), seznam.max(), ... Tohle se mi jeví jako zbytečný bastl za účelem lezení do zadku uživatelům zvyklým na imperativní jazyky.
Název: Re:Co si myslíte o OOP?
Přispěvatel: Kit 07. 01. 2019, 16:07:49
Statická typová kontrola zabrání určité třídě chyb v programu, protože nepovolí použití neočekávaných typů. Pokud mají být testy plnohodnotnou náhradou, měly by všechny tyto chyby odchytit taky (nepřu se o to, že testy mohou zachytit i spoustu jiných chyb, na které naopak nestačí typová kontrola). Je mi celkem jedno, jak budou testy vypadat, ale aby odpověď nebyla triviální, neměly by zahrnovat nic, co je jen převlečená statická typová kontrola přesunutá z kompilátoru do testovacího prostředí (tedy žádná statická analýza zdrojáků s použitím typových anotací).

Při statickém typování se neobejdeš bez testů, používáš tedy dva kontrolní mechanismy. Cílem tvůrců Smalltalku bylo tyto dva mechanismy sloučit do jednoho, tedy do testů. U dynamicky typovaných jazyků jsou tedy v testech i kontroly typů.

Naproti tomu se mi typové anotace nelíbí, to už raději v hlavičce metody ten typ použiji. Problém však nastane, pokud jsou přípustné paranetry různých typů. U statického typování se to řeší přetěžováním, což může pro různé kombinace typů parametrů znamenat značné množství metod. U dynamického se to může vyřešit v jedné metodě.
Název: Re:Co si myslíte o OOP?
Přispěvatel: BaldSlattery 07. 01. 2019, 16:12:35
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???
Rozhraním, ne? V ObjC se to jmenuje protokol, řekne se, jakou metodu má implementovat, a zbytek už je triviální.
Název: Re:Co si myslíte o OOP?
Přispěvatel: operator 07. 01. 2019, 16:12:45
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"?
Smysl je ve flexibilite. Zadne paradigma neni objektivne lepsi nez jine a pro ruzne situace muze byt jednou vhodnejsi to a podruhe ono, v Pythonu si je lze podle potřeby vybrat a kombinovat je, zlepsuje to vyjadrovaci prostredky jazyka. To je bez pochyby prinosne a obliba Pythonu prokazuje, ze to za pripadne komplikace stoji.

Nedohadujte se, Python zapouzdreni ma, at se vam to libi nebo ne. Zapouzdreni je abstrakce, ktera progranatorum umoznuje urcity pristup k programovani a Python tento pristup umoznuje.

@instancemethod neni anotace, ale dekorator a tento tam neni, protoze je to vychozi chovani. Stejne byste se mohl ptat, proc se v matematice nepise + pred kladnymi cisly, kdyz u zapornych se pise -.
Název: Re:Co si myslíte o OOP?
Přispěvatel: operator 07. 01. 2019, 16:16:04
Statická typová kontrola zabrání určité třídě chyb v programu, protože nepovolí použití neočekávaných typů. Pokud mají být testy plnohodnotnou náhradou, měly by všechny tyto chyby odchytit taky (nepřu se o to, že testy mohou zachytit i spoustu jiných chyb, na které naopak nestačí typová kontrola). Je mi celkem jedno, jak budou testy vypadat, ale aby odpověď nebyla triviální, neměly by zahrnovat nic, co je jen převlečená statická typová kontrola přesunutá z kompilátoru do testovacího prostředí (tedy žádná statická analýza zdrojáků s použitím typových anotací).

Při statickém typování se neobejdeš bez testů, používáš tedy dva kontrolní mechanismy. Cílem tvůrců Smalltalku bylo tyto dva mechanismy sloučit do jednoho, tedy do testů. U dynamicky typovaných jazyků jsou tedy v testech i kontroly typů.

Naproti tomu se mi typové anotace nelíbí, to už raději v hlavičce metody ten typ použiji. Problém však nastane, pokud jsou přípustné paranetry různých typů. U statického typování se to řeší přetěžováním, což může pro různé kombinace typů parametrů znamenat značné množství metod. U dynamického se to může vyřešit v jedné metodě.

Typove anotace jsou dobra pomucka, svuj smysl maji treba u verejneho rozhrani. Vyhodou u nich je, ze nejsou povinne, takze je programator je nemusi otrocky pouzivat tam, kde nemaji smysl nebo dokonce program zbytecne komplikuji.
Název: Re:Co si myslíte o OOP?
Přispěvatel: Kit 07. 01. 2019, 16:17:15
Proč budu "určitým postupem" zjišťovat, kolik je v kolekci prvků, když se jí můžu rovnou zeptat? Oč jsou uvedené funkce jednodušší, koncepčnější a přehlednější než seznam.len(), seznam.forEach(), seznam.max(), ... Tohle se mi jeví jako zbytečný bastl za účelem lezení do zadku uživatelům zvyklým na imperativní jazyky.

Vývojář by se především měl zeptat sám sebe, zda ten počet prvků potřebuje k dosažení cíle. Například zmíněné metody seznam.forEach(), seznam.max() tuto potřebu zpravidla eliminují.
Název: Re:Co si myslíte o OOP?
Přispěvatel: Kit 07. 01. 2019, 16:20:03
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???
Rozhraním, ne? V ObjC se to jmenuje protokol, řekne se, jakou metodu má implementovat, a zbytek už je triviální.

Jenže co když některé položky seznamu toto rozhraní nesplňují a tuto metodu implementovánu nemají?
Název: Re:Co si myslíte o OOP?
Přispěvatel: BaldSlattery 07. 01. 2019, 16:23:07
Statická typová kontrola zabrání určité třídě chyb v programu, protože nepovolí použití neočekávaných typů. Pokud mají být testy plnohodnotnou náhradou, měly by všechny tyto chyby odchytit taky (nepřu se o to, že testy mohou zachytit i spoustu jiných chyb, na které naopak nestačí typová kontrola). Je mi celkem jedno, jak budou testy vypadat, ale aby odpověď nebyla triviální, neměly by zahrnovat nic, co je jen převlečená statická typová kontrola přesunutá z kompilátoru do testovacího prostředí (tedy žádná statická analýza zdrojáků s použitím typových anotací).

Při statickém typování se neobejdeš bez testů, používáš tedy dva kontrolní mechanismy. Cílem tvůrců Smalltalku bylo tyto dva mechanismy sloučit do jednoho, tedy do testů. U dynamicky typovaných jazyků jsou tedy v testech i kontroly typů.

Naproti tomu se mi typové anotace nelíbí, to už raději v hlavičce metody ten typ použiji. Problém však nastane, pokud jsou přípustné paranetry různých typů. U statického typování se to řeší přetěžováním, což může pro různé kombinace typů parametrů znamenat značné množství metod. U dynamického se to může vyřešit v jedné metodě.
To není pravda, takové metody používají buď generika, nebo rozhraní. V C++ můžu říct, že parametr je “auto”, a překladač si s tím poradí. Chyby se řeší koncepčně (Concepts TS).
Název: Re:Co si myslíte o OOP?
Přispěvatel: BaldSlattery 07. 01. 2019, 16:24:16
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???
Rozhraním, ne? V ObjC se to jmenuje protokol, řekne se, jakou metodu má implementovat, a zbytek už je triviální.

Jenže co když některé položky seznamu toto rozhraní nesplňují a tuto metodu implementovánu nemají?
Tak nemá smysl cpát je do batohu, to by si stěžoval i Smalltalk.
Název: Re:Co si myslíte o OOP?
Přispěvatel: Kit 07. 01. 2019, 16:30:01
Typove anotace jsou dobra pomucka, svuj smysl maji treba u verejneho rozhrani. Vyhodou u nich je, ze nejsou povinne, takze je programator je nemusi otrocky pouzivat tam, kde nemaji smysl nebo dokonce program zbytecne komplikuji.

Záleží na jazyku. V Pythonu jsou typové anotace v pořádku, ale v PHP uváděné anotace do dokumentace jsou hnusné. Když se v PHP metoda otypuje, tak to vypadá podobně jako typová anotace v Pythonu.
Název: Re:Co si myslíte o OOP?
Přispěvatel: Kit 07. 01. 2019, 16:36:48
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???
Rozhraním, ne? V ObjC se to jmenuje protokol, řekne se, jakou metodu má implementovat, a zbytek už je triviální.
Jenže co když některé položky seznamu toto rozhraní nesplňují a tuto metodu implementovánu nemají?
Tak nemá smysl cpát je do batohu, to by si stěžoval i Smalltalk.

Mám je na seznamu věcí, které chci do toho batohu dát. Předměty, které to rozhraní nesplní, však do toho batohu dávat nebudu. Pokud ten seznam obsahuje takové nesmysly, tak to ještě nemusí znamenat, že ten seznam zahodím a prohlásím, že nikam nejedu.
Název: Re:Co si myslíte o OOP?
Přispěvatel: BaldSlattery 07. 01. 2019, 16:39:53
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???
Rozhraním, ne? V ObjC se to jmenuje protokol, řekne se, jakou metodu má implementovat, a zbytek už je triviální.
Jenže co když některé položky seznamu toto rozhraní nesplňují a tuto metodu implementovánu nemají?
Tak nemá smysl cpát je do batohu, to by si stěžoval i Smalltalk.

Mám je na seznamu věcí, které chci do toho batohu dát. Předměty, které to rozhraní nesplní, však do toho batohu dávat nebudu. Pokud ten seznam obsahuje takové nesmysly, tak to ještě nemusí znamenat, že ten seznam zahodím a prohlásím, že nikam nejedu.
Tak v tom případě nemáš vůbec žádný problém, napiš si to třeba v Go, je to poučné.
Název: Re:Co si myslíte o OOP?
Přispěvatel: Kit 07. 01. 2019, 16:44:02
Mám je na seznamu věcí, které chci do toho batohu dát. Předměty, které to rozhraní nesplní, však do toho batohu dávat nebudu. Pokud ten seznam obsahuje takové nesmysly, tak to ještě nemusí znamenat, že ten seznam zahodím a prohlásím, že nikam nejedu.
Tak v tom případě nemáš vůbec žádný problém, napiš si to třeba v Go, je to poučné.

Totéž si mohu napsat i v PHP, Pythonu nebo některém z mnoha dalších dynamicky typovaných jazyků.
Název: Re:Co si myslíte o OOP?
Přispěvatel: M 07. 01. 2019, 16:45:03
@ není anotace, ale dekorátor. Takovou classmethod si můžete zjednodušeně představit...

Je mi buřt, jak se to jmenuje (dekorátor je pro mě návrhový vzor), vnitřní implementace je nepodstatná. Představoval bych si, že vedle klíčového slova def tu bude např. classdef, aby bylo jasné, co je definováno na třídní a co na instanční straně. Tyto anotace/dekorátory na mě dělají dojem dobastlovaného jazyku.

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

Nechápu. Proč budu "určitým postupem" zjišťovat, kolik je v kolekci prvků, když se jí můžu rovnou zeptat? Oč jsou uvedené funkce jednodušší, koncepčnější a přehlednější než seznam.len(), seznam.forEach(), seznam.max(), ... Tohle se mi jeví jako zbytečný bastl za účelem lezení do zadku uživatelům zvyklým na imperativní jazyky.

Pepa vyrobí .size(), Franta vyrobí .length(), Honza vyrobí .len() ... a pak se v tom vyznej (to už se mi stalo).

Generické věci využívající generické protokoly nemusí bordelit třídní namespace a zbytečně komplikovat dědičnost. Například len() se podívá, jestli si třída implementuje __len__ a pokud ne, tak si ji projde a spočítá počet prvků, takže funguje s čímkoliv, co je iterable. Ditto ostatní takové věci. Ale Control-Space Enter, já vím.

Navíc python do jisté míry podporuje funkcionální styl programování, kde se přesně takové věci dělají. A když už mám jazyk, co takové programování podporuje, tak proč bych to nevyužil? Šetří to psaní, lépe se píšou výrazy ve funkcionálním stylu.

A ano, třídy a objekty jsou v pythonu víceméně pouze "glorifikované dicty", které se dají měnit jak se zamane. Je ale na odpovědnosti programátora, aby psal slušně a ne jak prase. Když si někde vytvořím _my_private, tak by v code review mělo být nad slunce jasné, že když někdo napíše neco._my_private, že je něco asi špatně.

Když se člověk začte do dokumentace, tak zjistí, že vnitřnosti jsou poměrně jednoduché a jsou okolo mechanismy, které se dají ovlivnit aby si člověk ušetřil psaní, zkontroloval data, která se předávají, vytvořil něco na způsob DSL... Takový přístup umožňuje větší kontrolu nad tím, co se děje a nabízí více možností, jak splnit úkol. A třeba to i pěkně napsat.
Název: Re:Co si myslíte o OOP?
Přispěvatel: BoneFlute 07. 01. 2019, 16:45:48
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?

Není to problém. Prostě nad tím pustím tu funkci sum() která vynucuje vlastnost "cena" či "objem". A ono se to transitivně propíše i do toho seznamu. Takže někdy v tom okamžiku mi kompilátor začne řvát, že tam má něco nedomyšleného, ať to laskavě domyslím.
Název: Re:Co si myslíte o OOP?
Přispěvatel: BaldSlattery 07. 01. 2019, 16:46:43
Mám je na seznamu věcí, které chci do toho batohu dát. Předměty, které to rozhraní nesplní, však do toho batohu dávat nebudu. Pokud ten seznam obsahuje takové nesmysly, tak to ještě nemusí znamenat, že ten seznam zahodím a prohlásím, že nikam nejedu.
Tak v tom případě nemáš vůbec žádný problém, napiš si to třeba v Go, je to poučné.

Totéž si mohu napsat i v PHP, Pythonu nebo některém z mnoha dalších dynamicky typovaných jazyků.
Bez typové kontroly. V C++, Go, ObjC nebo Swiftu to máš stejně flexibilní a s kontrolou.
Název: Re:Co si myslíte o OOP?
Přispěvatel: operator 07. 01. 2019, 16:48:52
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 :)

To do produkce nepusti Python, ale programator. Spravne to ma vypadat takto:
Kód: [Vybrat]
~ $ cat tt.py
def some_func_anywhere():
    """
    Function raise TypeError exception.
    >>> some_func_anywhere()
    Traceback (most recent call last):
        ...
    TypeError: unsupported operand type(s) for +: 'int' and 'str'
    """
    return 1 + "x"

if  __name__ == '__main__':
    import doctest
    print(doctest.testmod())
~ $ python tt.py
TestResults(failed=0, attempted=1)

A pak je v poradku, ze se to pusti do produkce, protoze funkce dela to co ma delat.
Název: Re:Co si myslíte o OOP?
Přispěvatel: MartinBeran 07. 01. 2019, 16:53:10
Při statickém typování se neobejdeš bez testů, používáš tedy dva kontrolní mechanismy. Cílem tvůrců Smalltalku bylo tyto dva mechanismy sloučit do jednoho, tedy do testů. U dynamicky typovaných jazyků jsou tedy v testech i kontroly typů.

Jenže ideální by bylo se obejít zcela bez testů a správnost programu dokázat. To z mnoha důvodů většinou nejde. Proto se snažíme dokázat (rozhodnout na základě statické analýzy zdrojových textů, pro všechny možné vstupy a bez nutnosti program spouštět) aspoň něco. Statická typová analýza je jedním z nástrojů, jak dokázat aspoň některé vlastnosti programu. Jestliže nějaké tvrzení o programu dokážeme (v matematickém slova smyslu), tak si můžeme být jistí, že platí.

Na druhou stranu testy většinou žádné obecné tvrzení o programu nedokazují, protože je není možné napsat tak, aby pokryly úplně celý stavový prostor programu. Takže se spoléháme na to, že otestujeme některé speciální situace, v lepším případě zvolené "chytře", např. na základě znalosti kódu, v horším případě vybrané náhodně, v nejhorším případě vybrané systematicky špatně. Když testy neohlásí chybu, tak věříme, že je program dobře. Ale ve skutečnosti jsme jen ověřili, že nenastane chyba pro určitou (většinou malou) podmnožinu vstupů. A to ještě za předpokladu, že nějaká chyba v testu nezamaskuje přítomnost chyby v kódu.

 Když mám k dispozici dva kontrolní mechanismy, které jsou do značné míry komplementární, tak se mi nezdá vhodné jeden z nich zahodit (a ještě ten s principiálně silnější vypovídací schopností) a tvářit se, že jsem zachoval stejnou úroveň kontroly.
Název: Re:Co si myslíte o OOP?
Přispěvatel: Lojza 07. 01. 2019, 17:16:55
mne by treba zajimalo proc se dynamicke jazyky zatim neprosadily u life saving real time mission criticial systems, ktere se nejspis vyvijeji jen v silne typovych jazycich, napr. v Ade resp. v jazycich ktere jsou jeji podmnozinou


https://en.wikipedia.org/wiki/Ada_(programming_language (https://en.wikipedia.org/wiki/Ada_(programming_language))


https://en.wikipedia.org/wiki/SPARK_(programming_language (https://en.wikipedia.org/wiki/SPARK_(programming_language))


https://en.wikipedia.org/wiki/Ravenscar_profile (https://en.wikipedia.org/wiki/Ravenscar_profile)


nebo je to jinak ?



Název: Re:Co si myslíte o OOP?
Přispěvatel: operator 07. 01. 2019, 17:30:56
Při statickém typování se neobejdeš bez testů, používáš tedy dva kontrolní mechanismy. Cílem tvůrců Smalltalku bylo tyto dva mechanismy sloučit do jednoho, tedy do testů. U dynamicky typovaných jazyků jsou tedy v testech i kontroly typů.

Jenže ideální by bylo se obejít zcela bez testů a správnost programu dokázat.
To je samozřejmě hloupost a realita je přesně opačná, bez testů se neobejdeme, bez _statických_ typů ano. Statické typy mají jediné opodstatnění, výkon. Ve všem ostatním jsou nahraditelné.
Název: Re:Co si myslíte o OOP?
Přispěvatel: operator 07. 01. 2019, 17:34:28
mne by treba zajimalo proc se dynamicke jazyky zatim neprosadily u life saving real time mission criticial systems, ktere se nejspis vyvijeji jen v silne typovych jazycich, napr. v Ade resp. v jazycich ktere jsou jeji podmnozinou


https://en.wikipedia.org/wiki/Ada_(programming_language (https://en.wikipedia.org/wiki/Ada_(programming_language))


https://en.wikipedia.org/wiki/SPARK_(programming_language (https://en.wikipedia.org/wiki/SPARK_(programming_language))


https://en.wikipedia.org/wiki/Ravenscar_profile (https://en.wikipedia.org/wiki/Ravenscar_profile)


nebo je to jinak ?
Doporucuji neplest si silne a staticke typovani.
Název: Re:Co si myslíte o OOP?
Přispěvatel: Inkvizitor 07. 01. 2019, 17:37:00
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__

A vo tom to je. Vytvořila se abstrakce, která má v některých ohledech výhodnější vlastnosti než vrstva pod ní. Dictionary je skvělá obecná struktura, protože do ní můžu vložit prakticky cokoli, ale mizerná struktura pro popis dat, která mají pevný formát. Normální třída v Pythonu je skvělý obecný nástroj, protože je velice flexibilní, ale z pohledu člověka, který chtěl record a nic víc, je to kanon na vrabce se vším všudy.

Dynamické jazyky jsou super, protože dovolují naprogramovat všechno a všelijak. Pokud po nich chceme přesnost, rychlost a spolehlivost, je ta flexibilita spíš na obtíž. Můj odhad je, že dynamické jazyky budou ustupovat, protože jejich základem je snadnost implementace a vyhýbání se složitostem návrhu, což jim historicky přinášelo nemalé výhody. Statické jazyky se ale vyvíjejí, jak z hlediska ergonomie, tak z pohledu podpory nástrojů a možností.
Název: Re:Co si myslíte o OOP?
Přispěvatel: Honza 07. 01. 2019, 17:41:59
mne by treba zajimalo proc se dynamicke jazyky zatim neprosadily u life saving real time mission criticial systems, ktere se nejspis vyvijeji jen v silne typovych jazycich, napr. v Ade resp. v jazycich ktere jsou jeji podmnozinou


https://en.wikipedia.org/wiki/Ada_(programming_language (https://en.wikipedia.org/wiki/Ada_(programming_language))


https://en.wikipedia.org/wiki/SPARK_(programming_language (https://en.wikipedia.org/wiki/SPARK_(programming_language))


https://en.wikipedia.org/wiki/Ravenscar_profile (https://en.wikipedia.org/wiki/Ravenscar_profile)


nebo je to jinak ?
Já tuším, že to bude tím, že implementace těch jazyků, které se pro to nepoužívají, mají nedeterministický GC. Pokud navíc běží VM pouze v jednom vlákně, tak to je problém. Ale není to proto, že jde o dynamické jazyky...
Název: Re:Co si myslíte o OOP?
Přispěvatel: operator 07. 01. 2019, 17:46:53
Já mám takovou krásnou ukázku flexibility dynamického jazyka. Implementace funkce undo pro libovolné proměnné libovolného typu. Jak složité bude tohle implementovat ve statickém jazyce, který se používá v produkční sféře, tedy C, C++, Java, C#?
Kód: [Vybrat]
~ $ python2 history.py
var1: 4
var1 after undo: 2 <type 'int'>
var2: 4
var2 after undo: 2 <type 'str'>
~ $ cat history.py
import sys

def undo(name):
    undo.data[name].pop(-1)
    return undo.data[name][-1]
undo.data = {}

def history(frame, event, arg):
    for name,val in frame.f_locals.items():
        if name not in undo.data:
            undo.data[name] = []
        else:
            if undo.data[name][-1] is val:
                continue
        undo.data[name].append(val)
    return history

def main():
    for i in range(5):
        var1 = i
        var2 = str(i)


    print "var1:", var1
    var1 = undo('var1')
    var1 = undo('var1')
    print "var1 after undo:", var1, type(var1)

    print "var2:", var2
    var2 = undo('var2')
    var2 = undo('var2')
    print "var2 after undo:", var2, type(var2)

if  __name__ == '__main__':
    sys.settrace(history)
    main()
    sys.settrace(None)
Název: Re:Co si myslíte o OOP?
Přispěvatel: anonym 07. 01. 2019, 17:58:40
Já mám takovou krásnou ukázku flexibility dynamického jazyka. Implementace funkce undo pro libovolné proměnné libovolného typu. Jak složité bude tohle implementovat ve statickém jazyce, který se používá v produkční sféře, tedy C, C++, Java, C#?
Kód: [Vybrat]
~ $ python2 history.py
var1: 4
var1 after undo: 2 <type 'int'>
var2: 4
var2 after undo: 2 <type 'str'>
~ $ cat history.py
import sys

def undo(name):
    undo.data[name].pop(-1)
    return undo.data[name][-1]
undo.data = {}

def history(frame, event, arg):
    for name,val in frame.f_locals.items():
        if name not in undo.data:
            undo.data[name] = []
        else:
            if undo.data[name][-1] is val:
                continue
        undo.data[name].append(val)
    return history

def main():
    for i in range(5):
        var1 = i
        var2 = str(i)


    print "var1:", var1
    var1 = undo('var1')
    var1 = undo('var1')
    print "var1 after undo:", var1, type(var1)

    print "var2:", var2
    var2 = undo('var2')
    var2 = undo('var2')
    print "var2 after undo:", var2, type(var2)

if  __name__ == '__main__':
    sys.settrace(history)
    main()
    sys.settrace(None)

Ty vole co to je za hack, to doufam ze Java ani takovouto cestou neumi, fuj :D

Ano, mas pravdu, uvedl jsi kraaasnyy pripad flexibilnosti dynamicky typovaneho jazyka.
Název: Re:Co si myslíte o OOP?
Přispěvatel: Kit 07. 01. 2019, 18:01:13
Jenže ideální by bylo se obejít zcela bez testů a správnost programu dokázat. To z mnoha důvodů většinou nejde. Proto se snažíme dokázat (rozhodnout na základě statické analýzy zdrojových textů, pro všechny možné vstupy a bez nutnosti program spouštět) aspoň něco. Statická typová analýza je jedním z nástrojů, jak dokázat aspoň některé vlastnosti programu. Jestliže nějaké tvrzení o programu dokážeme (v matematickém slova smyslu), tak si můžeme být jistí, že platí.

Také by mohlo být ideální obejít se bez statických typů. Bude to znamenat pouze určitou ztrátu výkonu, což v dnešní době není považováno za podstatné. Statická analýza může být (a také bývá) součástí testů.

Na druhou stranu testy většinou žádné obecné tvrzení o programu nedokazují, protože je není možné napsat tak, aby pokryly úplně celý stavový prostor programu. Takže se spoléháme na to, že otestujeme některé speciální situace, v lepším případě zvolené "chytře", např. na základě znalosti kódu, v horším případě vybrané náhodně, v nejhorším případě vybrané systematicky špatně. Když testy neohlásí chybu, tak věříme, že je program dobře. Ale ve skutečnosti jsme jen ověřili, že nenastane chyba pro určitou (většinou malou) podmnožinu vstupů. A to ještě za předpokladu, že nějaká chyba v testu nezamaskuje přítomnost chyby v kódu.

Zpravidla testujeme pouze okrajové podmínky, kdy program má fungovat a kdy naopak musí vyhodit výjimku. Na znalost kódu se spoléhat nemůžeme, protože ho v době psaní testů ještě nemáme. Když testy neohlásí chybu, tak zpřesníme testy, to je základ. Nevěř testům, které projdou.

Když mám k dispozici dva kontrolní mechanismy, které jsou do značné míry komplementární, tak se mi nezdá vhodné jeden z nich zahodit (a ještě ten s principiálně silnější vypovídací schopností) a tvářit se, že jsem zachoval stejnou úroveň kontroly.

Proto se tyto kontrolní mechanismy kombinují. Smalltalk šel cestou testování a možná proto se tolik nerozšířil. Haskell se vydal cestou statického typování, ale bez testů se také neobejde. Nejlépe jsou dnes na tom jazyky, které oba přístupy volně kombinují. Proto byly do PHP či Pythonu přidány volitelné statické typy a proto se staticky typované programy nejen dokazují, ale i testují.
Název: Re:Co si myslíte o OOP?
Přispěvatel: operator 07. 01. 2019, 18:39:55
Já mám takovou krásnou ukázku flexibility dynamického jazyka. Implementace funkce undo pro libovolné proměnné libovolného typu. Jak složité bude tohle implementovat ve statickém jazyce, který se používá v produkční sféře, tedy C, C++, Java, C#?
Kód: [Vybrat]
~ $ python2 history.py
var1: 4
var1 after undo: 2 <type 'int'>
var2: 4
var2 after undo: 2 <type 'str'>
~ $ cat history.py
import sys

def undo(name):
    undo.data[name].pop(-1)
    return undo.data[name][-1]
undo.data = {}

def history(frame, event, arg):
    for name,val in frame.f_locals.items():
        if name not in undo.data:
            undo.data[name] = []
        else:
            if undo.data[name][-1] is val:
                continue
        undo.data[name].append(val)
    return history

def main():
    for i in range(5):
        var1 = i
        var2 = str(i)


    print "var1:", var1
    var1 = undo('var1')
    var1 = undo('var1')
    print "var1 after undo:", var1, type(var1)

    print "var2:", var2
    var2 = undo('var2')
    var2 = undo('var2')
    print "var2 after undo:", var2, type(var2)

if  __name__ == '__main__':
    sys.settrace(history)
    main()
    sys.settrace(None)

Ty vole co to je za hack, to doufam ze Java ani takovouto cestou neumi, fuj :D

Ano, mas pravdu, uvedl jsi kraaasnyy pripad flexibilnosti dynamicky typovaneho jazyka.

To neni zadny hack, ale priklad vyuziti velmi uzitecna veci, introspekce. Mohu skrz ni kontrolovat chod programu, aniz bych zasahoval do jeho kodu a reagovat libovolne na ruzne specificke podminky. Introspekce neni nutne vlastnost jen dynamickeho jazyka, ale v dynamickem jazyku se lehce vyrovnam s tim, ze prichazum do styku s hodnotami libovolnych datovych typu.
Název: Re:Co si myslíte o OOP?
Přispěvatel: anonym 07. 01. 2019, 19:22:42
Já mám takovou krásnou ukázku flexibility dynamického jazyka. Implementace funkce undo pro libovolné proměnné libovolného typu. Jak složité bude tohle implementovat ve statickém jazyce, který se používá v produkční sféře, tedy C, C++, Java, C#?
Kód: [Vybrat]
~ $ python2 history.py
var1: 4
var1 after undo: 2 <type 'int'>
var2: 4
var2 after undo: 2 <type 'str'>
~ $ cat history.py
import sys

def undo(name):
    undo.data[name].pop(-1)
    return undo.data[name][-1]
undo.data = {}

def history(frame, event, arg):
    for name,val in frame.f_locals.items():
        if name not in undo.data:
            undo.data[name] = []
        else:
            if undo.data[name][-1] is val:
                continue
        undo.data[name].append(val)
    return history

def main():
    for i in range(5):
        var1 = i
        var2 = str(i)


    print "var1:", var1
    var1 = undo('var1')
    var1 = undo('var1')
    print "var1 after undo:", var1, type(var1)

    print "var2:", var2
    var2 = undo('var2')
    var2 = undo('var2')
    print "var2 after undo:", var2, type(var2)

if  __name__ == '__main__':
    sys.settrace(history)
    main()
    sys.settrace(None)

Ty vole co to je za hack, to doufam ze Java ani takovouto cestou neumi, fuj :D

Ano, mas pravdu, uvedl jsi kraaasnyy pripad flexibilnosti dynamicky typovaneho jazyka.

To neni zadny hack, ale priklad vyuziti velmi uzitecna veci, introspekce. Mohu skrz ni kontrolovat chod programu, aniz bych zasahoval do jeho kodu a reagovat libovolne na ruzne specificke podminky. Introspekce neni nutne vlastnost jen dynamickeho jazyka, ale v dynamickem jazyku se lehce vyrovnam s tim, ze prichazum do styku s hodnotami libovolnych datovych typu.

A jaky je zrovna usecase pro to historii setovani tech parametru? To se da prece logovat - pokud pises spravne objektove a ne jako prase, mas tam getry a setry. Nenapada me k cemu by to bylo dobre.
Název: Re:Co si myslíte o OOP?
Přispěvatel: operator 07. 01. 2019, 19:45:52
Já mám takovou krásnou ukázku flexibility dynamického jazyka. Implementace funkce undo pro libovolné proměnné libovolného typu. Jak složité bude tohle implementovat ve statickém jazyce, který se používá v produkční sféře, tedy C, C++, Java, C#?
Kód: [Vybrat]
~ $ python2 history.py
var1: 4
var1 after undo: 2 <type 'int'>
var2: 4
var2 after undo: 2 <type 'str'>
~ $ cat history.py
import sys

def undo(name):
    undo.data[name].pop(-1)
    return undo.data[name][-1]
undo.data = {}

def history(frame, event, arg):
    for name,val in frame.f_locals.items():
        if name not in undo.data:
            undo.data[name] = []
        else:
            if undo.data[name][-1] is val:
                continue
        undo.data[name].append(val)
    return history

def main():
    for i in range(5):
        var1 = i
        var2 = str(i)


    print "var1:", var1
    var1 = undo('var1')
    var1 = undo('var1')
    print "var1 after undo:", var1, type(var1)

    print "var2:", var2
    var2 = undo('var2')
    var2 = undo('var2')
    print "var2 after undo:", var2, type(var2)

if  __name__ == '__main__':
    sys.settrace(history)
    main()
    sys.settrace(None)

Ty vole co to je za hack, to doufam ze Java ani takovouto cestou neumi, fuj :D

Ano, mas pravdu, uvedl jsi kraaasnyy pripad flexibilnosti dynamicky typovaneho jazyka.

To neni zadny hack, ale priklad vyuziti velmi uzitecna veci, introspekce. Mohu skrz ni kontrolovat chod programu, aniz bych zasahoval do jeho kodu a reagovat libovolne na ruzne specificke podminky. Introspekce neni nutne vlastnost jen dynamickeho jazyka, ale v dynamickem jazyku se lehce vyrovnam s tim, ze prichazum do styku s hodnotami libovolnych datovych typu.

A jaky je zrovna usecase pro to historii setovani tech parametru? To se da prece logovat - pokud pises spravne objektove a ne jako prase, mas tam getry a setry. Nenapada me k cemu by to bylo dobre.
Pamatovat si historii muze byt dobre treba k implementaci transakci a bud rollbacku nebo provest navrat do nejakeho casu. Nebo potrebujes mit triger ne na hodnotu, ale rychlost zmeny. Fantazii se meze nekladou. Logovat muzes svuj kod ale to znamenak ze ho musis upravit a bude ho to zpomalovat. Predstav si, ze chces docasne logovat nejaky kus kodu, treba nejakou funkci nebo metodu nejake tridy z nejake knihovny, do ktere ale nechces nebo nemuzes zasahovat.
Název: Re:Co si myslíte o OOP?
Přispěvatel: Inkvizitor 07. 01. 2019, 19:55:40
Já mám takovou krásnou ukázku flexibility dynamického jazyka. Implementace funkce undo pro libovolné proměnné libovolného typu. Jak složité bude tohle implementovat ve statickém jazyce, který se používá v produkční sféře, tedy C, C++, Java, C#?
Kód: [Vybrat]
~ $ python2 history.py
var1: 4
var1 after undo: 2 <type 'int'>
var2: 4
var2 after undo: 2 <type 'str'>
~ $ cat history.py
import sys

def undo(name):
    undo.data[name].pop(-1)
    return undo.data[name][-1]
undo.data = {}

def history(frame, event, arg):
    for name,val in frame.f_locals.items():
        if name not in undo.data:
            undo.data[name] = []
        else:
            if undo.data[name][-1] is val:
                continue
        undo.data[name].append(val)
    return history

def main():
    for i in range(5):
        var1 = i
        var2 = str(i)


    print "var1:", var1
    var1 = undo('var1')
    var1 = undo('var1')
    print "var1 after undo:", var1, type(var1)

    print "var2:", var2
    var2 = undo('var2')
    var2 = undo('var2')
    print "var2 after undo:", var2, type(var2)

if  __name__ == '__main__':
    sys.settrace(history)
    main()
    sys.settrace(None)

Až na to, že jelikož objekty v Pythonu obecně nejsou immutabilní, je Ti zcela obecně ta Tvoje LIFO kolekce hodnot úplně nanic.
Název: Re:Co si myslíte o OOP?
Přispěvatel: operator 07. 01. 2019, 20:02:52
Já mám takovou krásnou ukázku flexibility dynamického jazyka. Implementace funkce undo pro libovolné proměnné libovolného typu. Jak složité bude tohle implementovat ve statickém jazyce, který se používá v produkční sféře, tedy C, C++, Java, C#?
Kód: [Vybrat]
~ $ python2 history.py
var1: 4
var1 after undo: 2 <type 'int'>
var2: 4
var2 after undo: 2 <type 'str'>
~ $ cat history.py
import sys

def undo(name):
    undo.data[name].pop(-1)
    return undo.data[name][-1]
undo.data = {}

def history(frame, event, arg):
    for name,val in frame.f_locals.items():
        if name not in undo.data:
            undo.data[name] = []
        else:
            if undo.data[name][-1] is val:
                continue
        undo.data[name].append(val)
    return history

def main():
    for i in range(5):
        var1 = i
        var2 = str(i)


    print "var1:", var1
    var1 = undo('var1')
    var1 = undo('var1')
    print "var1 after undo:", var1, type(var1)

    print "var2:", var2
    var2 = undo('var2')
    var2 = undo('var2')
    print "var2 after undo:", var2, type(var2)

if  __name__ == '__main__':
    sys.settrace(history)
    main()
    sys.settrace(None)

Až na to, že jelikož objekty v Pythonu obecně nejsou immutabilní, je Ti zcela obecně ta Tvoje LIFO kolekce hodnot úplně nanic.
O tom co se mi hodi a co ne vis uplne prdlajs a jinak jsi na urovni trumbery, ktery na demonstracni hello world reaguje poznamkou, ze vypisovani slov hello world je uplne na nic. :-)
Název: Re:Co si myslíte o OOP?
Přispěvatel: Inkvizitor 07. 01. 2019, 20:05:38
O tom co se mi hodi a co ne vis uplne prdlajs a jinak jsi na urovni trumbery, ktery na demonstracni hello world reaguje poznamkou, ze vypisovani slov hello world je uplne na nic. :-)

Aha, takže Ty se prsíš kódem, který je ubohý a nepoužitelný a je to moje chyba? Sám jsi psal, že to funguje s hodnotami libovolného typu, tak se nevykrucuj, když jsem Tě nachytal.
Název: Re:Co si myslíte o OOP?
Přispěvatel: operator 07. 01. 2019, 20:21:06
O tom co se mi hodi a co ne vis uplne prdlajs a jinak jsi na urovni trumbery, ktery na demonstracni hello world reaguje poznamkou, ze vypisovani slov hello world je uplne na nic. :-)

Aha, takže Ty se prsíš kódem, který je ubohý a nepoužitelný a je to moje chyba? Sám jsi psal, že to funguje s hodnotami libovolného typu, tak se nevykrucuj, když jsem Tě nachytal.
Neprsim se kodem, prsim se moznostmi, ktere demonstruuji na jednoduche ukazce. Tvoje chyba je, ze na to reagujes s nepochopenim jako osel. Psal jsem, ze to funguje pro vsechny promenne libovolneho typu, coz plati.
Název: Re:Co si myslíte o OOP?
Přispěvatel: Kit 07. 01. 2019, 20:26:02
To neni zadny hack, ale priklad vyuziti velmi uzitecna veci, introspekce. Mohu skrz ni kontrolovat chod programu, aniz bych zasahoval do jeho kodu a reagovat libovolne na ruzne specificke podminky. Introspekce neni nutne vlastnost jen dynamickeho jazyka, ale v dynamickem jazyku se lehce vyrovnam s tim, ze prichazum do styku s hodnotami libovolnych datovych typu.

Vidím tam jednu vadu na kráse: Funkce history() a undo() jsou zbytečně součástí aplikace. Uvítal bych, kdyby byly spíš součástí toho testu dole. Nebo je to celé samostatným testem?
Název: Re:Co si myslíte o OOP?
Přispěvatel: Inkvizitor 07. 01. 2019, 20:26:59
Neprsim se kodem, prsim se moznostmi, ktere demonstruuji na jednoduche ukazce. Tvoje chyba je, ze na to reagujes s nepochopenim jako osel. Psal jsem, ze to funguje pro vsechny promenne libovolneho typu, coz plati.

Hele, chybu udělá každý, ale takhle zatloukat, to je trapné. Vymyslel sis featuru, která je nanic, udělal implementaci, která nefunguje, abys demonstroval, co tu nikdo nepopírá. Tím s Tebou fakt končím, už se budu akorát tiše uchechtávat.
Název: Re:Co si myslíte o OOP?
Přispěvatel: MartinBeran 07. 01. 2019, 21:27:10
Při statickém typování se neobejdeš bez testů, používáš tedy dva kontrolní mechanismy. Cílem tvůrců Smalltalku bylo tyto dva mechanismy sloučit do jednoho, tedy do testů. U dynamicky typovaných jazyků jsou tedy v testech i kontroly typů.

Jenže ideální by bylo se obejít zcela bez testů a správnost programu dokázat.
To je samozřejmě hloupost a realita je přesně opačná, bez testů se neobejdeme, bez _statických_ typů ano. Statické typy mají jediné opodstatnění, výkon. Ve všem ostatním jsou nahraditelné.

Když v takovéto diskusi věta začíná: "To je samozřejmě", je to silná indikace, že následuje nepravda. Aspoň jeden věcný argument by nebyl?

Ano, bez testů se neobejdeme, protože neumíme správnost programu dokázat. Ano, bez statických typů se obejdeme, když se smířime se ztrátou výhod, které poskytují. Ne, jejich význam nespočívá jen ve zlepšení výkonu. Také nás zbavují nutnosti psát některé druhy testů a zároveň poskytují lepší záruku správnosti programu.
Název: Re:Co si myslíte o OOP?
Přispěvatel: Mirek Prýmek 07. 01. 2019, 21:44:29
Já mám takovou krásnou ukázku flexibility dynamického jazyka.
Spíš je to krásná ukázka toho, že "krása" je veskrze subjektivní pojem.
Název: Re:Co si myslíte o OOP?
Přispěvatel: MartinBeran 07. 01. 2019, 21:45:07
Jenže ideální by bylo se obejít zcela bez testů a správnost programu dokázat. To z mnoha důvodů většinou nejde. Proto se snažíme dokázat (rozhodnout na základě statické analýzy zdrojových textů, pro všechny možné vstupy a bez nutnosti program spouštět) aspoň něco. Statická typová analýza je jedním z nástrojů, jak dokázat aspoň některé vlastnosti programu. Jestliže nějaké tvrzení o programu dokážeme (v matematickém slova smyslu), tak si můžeme být jistí, že platí.

Také by mohlo být ideální obejít se bez statických typů. Bude to znamenat pouze určitou ztrátu výkonu, což v dnešní době není považováno za podstatné. Statická analýza může být (a také bývá) součástí testů.

Kupodivu i v dnešní době na výkonu často záleží. Jaký je rozdíl, když je statická analýza (nejspíš včetně typové analýzy, pokud k ní kód poskytuje dostatek informací) součástí testů a ne kompilátoru? Kromě toho, že je pak potřeba statickou analýzu v testech vůbec řešit a kompilátor tyto informace nemůže použít pro optimalizaci?

Na druhou stranu testy většinou žádné obecné tvrzení o programu nedokazují, protože je není možné napsat tak, aby pokryly úplně celý stavový prostor programu. Takže se spoléháme na to, že otestujeme některé speciální situace, v lepším případě zvolené "chytře", např. na základě znalosti kódu, v horším případě vybrané náhodně, v nejhorším případě vybrané systematicky špatně. Když testy neohlásí chybu, tak věříme, že je program dobře. Ale ve skutečnosti jsme jen ověřili, že nenastane chyba pro určitou (většinou malou) podmnožinu vstupů. A to ještě za předpokladu, že nějaká chyba v testu nezamaskuje přítomnost chyby v kódu.

Zpravidla testujeme pouze okrajové podmínky, kdy program má fungovat a kdy naopak musí vyhodit výjimku. Na znalost kódu se spoléhat nemůžeme, protože ho v době psaní testů ještě nemáme. Když testy neohlásí chybu, tak zpřesníme testy, to je základ. Nevěř testům, které projdou.

Testy není nutné psát dřív než kód. U některých je to dost nevhodné. Kdybych bral poslední dvě věty doslova, tak nevím, jak poznám, že je program připraven pro produkční nasazení.

Když mám k dispozici dva kontrolní mechanismy, které jsou do značné míry komplementární, tak se mi nezdá vhodné jeden z nich zahodit (a ještě ten s principiálně silnější vypovídací schopností) a tvářit se, že jsem zachoval stejnou úroveň kontroly.

Proto se tyto kontrolní mechanismy kombinují. Smalltalk šel cestou testování a možná proto se tolik nerozšířil. Haskell se vydal cestou statického typování, ale bez testů se také neobejde. Nejlépe jsou dnes na tom jazyky, které oba přístupy volně kombinují. Proto byly do PHP či Pythonu přidány volitelné statické typy a proto se staticky typované programy nejen dokazují, ale i testují.

Právě že se programy nedokazují, a proto se musí testovat. I staticky typované jazyky kombinují oba přístupy. Já jsem nebyl ten, kdo prosazoval, že nejsou potřeba statické typy, protože testy. A netvrdím ani to, že statická typová analýza je náhradou testů.
Název: Re:Co si myslíte o OOP?
Přispěvatel: MartinBeran 07. 01. 2019, 21:46:49
Já mám takovou krásnou ukázku flexibility dynamického jazyka.
Spíš je to krásná ukázka toho, že "krása" je veskrze subjektivní pojem.

Ono by nejen této diskusi prospělo, kdyby každý diskutující rozlišoval věcné argumenty a subjektivní názory...
Název: Re:Co si myslíte o OOP?
Přispěvatel: Mirek Prýmek 07. 01. 2019, 21:53:18
Ono by nejen této diskusi prospělo, kdyby každý diskutující rozlišoval věcné argumenty a subjektivní názory...
Ano, velmi. Ale je to obtížné. Pro někoho přílíš obtížné.
Název: Re:Co si myslíte o OOP?
Přispěvatel: operator 08. 01. 2019, 05:28:40
To neni zadny hack, ale priklad vyuziti velmi uzitecna veci, introspekce. Mohu skrz ni kontrolovat chod programu, aniz bych zasahoval do jeho kodu a reagovat libovolne na ruzne specificke podminky. Introspekce neni nutne vlastnost jen dynamickeho jazyka, ale v dynamickem jazyku se lehce vyrovnam s tim, ze prichazum do styku s hodnotami libovolnych datovych typu.

Vidím tam jednu vadu na kráse: Funkce history() a undo() jsou zbytečně součástí aplikace. Uvítal bych, kdyby byly spíš součástí toho testu dole. Nebo je to celé samostatným testem?
Muze to byt tak i tak, je neco podobneho ale v komplexnejsi forme mam ve vlastni knihovne, kterou pouzivam jak pri testech tak nekdy i v samotnem kodu.
Název: Re:Co si myslíte o OOP?
Přispěvatel: operator 08. 01. 2019, 05:33:28
Neprsim se kodem, prsim se moznostmi, ktere demonstruuji na jednoduche ukazce. Tvoje chyba je, ze na to reagujes s nepochopenim jako osel. Psal jsem, ze to funguje pro vsechny promenne libovolneho typu, coz plati.

Hele, chybu udělá každý, ale takhle zatloukat, to je trapné. Vymyslel sis featuru, která je nanic, udělal implementaci, která nefunguje, abys demonstroval, co tu nikdo nepopírá. Tím s Tebou fakt končím, už se budu akorát tiše uchechtávat.
Nemas pravdu ani v jednom pripade. Nevymyslel jsem to ja, implementace funguje a demonstruuji tu vyhody dynamickych jazyku, ktere tu mnozi popiraji. Analogii ve statickem jazyku tu nikdo nepredvedl, asi to vubec nejde a rekl bych, ze odtud prameni tvoje nasranost :-).
Název: Re:Co si myslíte o OOP?
Přispěvatel: lopata 08. 01. 2019, 06:35:23
Nemas pravdu ani v jednom pripade. Nevymyslel jsem to ja, implementace funguje a demonstruuji tu vyhody dynamickych jazyku, ktere tu mnozi popiraji. Analogii ve statickem jazyku tu nikdo nepredvedl, asi to vubec nejde a rekl bych, ze odtud prameni tvoje nasranost :-).

My nejsme nasraní, my se podivujeme nad tvojí nezkušeností a zaslepeností. Použít implementation dependent debugger k implementaci historie, to je opravdu majstrštyk hodný uveřejnění na hovnokódu. Mimochodem kdyby sis přečetl dokumentaci k settrace, tak by ses tam dozvěděl mimo mnoho dalších zajímavých věcí i tohle:

CPython implementation detail: The settrace() function is intended only for implementing debuggers, profilers, coverage tools and the like. Its behavior is part of the implementation platform, rather than part of the language definition, and thus may not be available in all Python implementations.
Název: Re:Co si myslíte o OOP?
Přispěvatel: operator 08. 01. 2019, 07:48:49
Jenže ideální by bylo se obejít zcela bez testů a správnost programu dokázat. To z mnoha důvodů většinou nejde. Proto se snažíme dokázat (rozhodnout na základě statické analýzy zdrojových textů, pro všechny možné vstupy a bez nutnosti program spouštět) aspoň něco. Statická typová analýza je jedním z nástrojů, jak dokázat aspoň některé vlastnosti programu. Jestliže nějaké tvrzení o programu dokážeme (v matematickém slova smyslu), tak si můžeme být jistí, že platí.

Také by mohlo být ideální obejít se bez statických typů. Bude to znamenat pouze určitou ztrátu výkonu, což v dnešní době není považováno za podstatné. Statická analýza může být (a také bývá) součástí testů.

Kupodivu i v dnešní době na výkonu často záleží. Jaký je rozdíl, když je statická analýza (nejspíš včetně typové analýzy, pokud k ní kód poskytuje dostatek informací) součástí testů a ne kompilátoru? Kromě toho, že je pak potřeba statickou analýzu v testech vůbec řešit a kompilátor tyto informace nemůže použít pro optimalizaci?
Potreba vykonu je jen v nekterych prápadech. Proto se arduino bude programt v C asi vzdy a webove stranky asi nikdy. Dnes je vykonu tolik, ze mnohem vyznamnejsi je produktivita, ktera je vyssi u flexibilnejsich dynamickych jazyku. Staticke analyza u testu ma vyhodu v tom, ze ji lze pouzit jen tam kde je vhodna a potrebna. Idealni univerzalni jazyk budoucnosti by tedy mel mit moznost statickych typu, ale nepovinne. K necemu takovemu ma nakroceno cython, ktery kombinuje vyhody dynamickych a statickych jazyku.
Citace
Na druhou stranu testy většinou žádné obecné tvrzení o programu nedokazují, protože je není možné napsat tak, aby pokryly úplně celý stavový prostor programu. Takže se spoléháme na to, že otestujeme některé speciální situace, v lepším případě zvolené "chytře", např. na základě znalosti kódu, v horším případě vybrané náhodně, v nejhorším případě vybrané systematicky špatně. Když testy neohlásí chybu, tak věříme, že je program dobře. Ale ve skutečnosti jsme jen ověřili, že nenastane chyba pro určitou (většinou malou) podmnožinu vstupů. A to ještě za předpokladu, že nějaká chyba v testu nezamaskuje přítomnost chyby v kódu.

Zpravidla testujeme pouze okrajové podmínky, kdy program má fungovat a kdy naopak musí vyhodit výjimku. Na znalost kódu se spoléhat nemůžeme, protože ho v době psaní testů ještě nemáme. Když testy neohlásí chybu, tak zpřesníme testy, to je základ. Nevěř testům, které projdou.
Testy není nutné psát dřív než kód. U některých je to dost nevhodné. Kdybych bral poslední dvě věty doslova, tak nevím, jak poznám, že je program připraven pro produkční nasazení.
Mne prijde, ze je tu malo programatoru z praxe, programatoru, kteri vytvari skutecny produkcni kod, ktery neco poradneho dela, vydelava penize a za to jsou ti programatori placeni. Vypada to, ze je to tu samy teoreticky programator, ktery ma nastudovanu teorii typu, ale nikdy zadny realny produkt nevytvoril. Testovat se musi nejen ze program funguje a dela to co ma, ale i to, ze selze a nedela to co nema. Vetsinou se od programu nechce aby fungoval za kazdou cenu, ale hlavne aby nenadelal skody. Pokud zakaznik predem doda testy, je to to nejlepsi co muze programatora potkat, protoze programator zpravidla nerozumi byznysu a procesum zakaznika a aplikaci z funkcniho hlediska otestovat neumi. Programator vi, ze nemuze scitat int se stringem, ale to ani zdaleka nestaci. Ono se treba take musi otestovat, ze zkratovaci souprava muze byt osazena jen na jedno miste a na jednom miste muze byt jen jedna zkratovaci souorava s vyjimkou nekolika mist, ze musi byt osazena na prikaz b a nejde ji sundat, dokud plati, ale muze zustat osazena i po jeho ukonceni, ze muze byt osazena na vice prikazu b, ze jeden prikaz muze byt prilohou jineho prikazu b, kdy se pozadavky prenasi, ze jsou prikazy b ciste na odjisteni, kdy se nezajistuje, ze existuje moznost docasneho odjisteni na prikaz b a rada dalsich pravidel, ktere zakaznik upresnuje zpravidla az kdyz je aplikace hotova a poukazuje na chyby v aplikaci a divi se, ze to programatori nevi a udelali spatne, protoze je to prece vsechno jasne a logicke. Teda s tim, ze na ruznych lokalitach bezi procesy trochu odlisne, coz je potreba take zohlednit, coz ani zakaznik sam netusil, protoze pozadavek zadava nejaky manager, kterynti sam do detailý nezna. Ale rozhodne to nesmi byt spatne, protoze kdyz to bude fungovat spatne, pujde elektrikarum o zivot. No a to se bavime o velmi jednoduche evidencni knize, ktera se da naprogramovat za par dnu, ale otestovat ji dukladne a pustit do provozu je zalezitost na nekolik mesicu. Kazda uprava a zasah do kodu vyzaduje provest testy na vsechny vazby a podminky znovu, aby se overilo, ze se nic nenarusilo. Kod testu je rozsahlejsi nez sama aplikace. A staticke typy v tom hraji zcela marginalni ulohu. Aplikace musi byt v C#, protoze takove je zakaznikovo prostredi a rozumne nic jineho nepripusti, aby to byl schopen rozumne udrzovat. Takova je realna praxe, panove. A pak tady jsou s prominutim imbecilove, kteri zcela vazne tvrdi, ze kdyz aplikace projde kompilatorem, tak je v podstate hotovo.
Citace
Když mám k dispozici dva kontrolní mechanismy, které jsou do značné míry komplementární, tak se mi nezdá vhodné jeden z nich zahodit (a ještě ten s principiálně silnější vypovídací schopností) a tvářit se, že jsem zachoval stejnou úroveň kontroly.

Proto se tyto kontrolní mechanismy kombinují. Smalltalk šel cestou testování a možná proto se tolik nerozšířil. Haskell se vydal cestou statického typování, ale bez testů se také neobejde. Nejlépe jsou dnes na tom jazyky, které oba přístupy volně kombinují. Proto byly do PHP či Pythonu přidány volitelné statické typy a proto se staticky typované programy nejen dokazují, ale i testují.

Právě že se programy nedokazují, a proto se musí testovat. I staticky typované jazyky kombinují oba přístupy. Já jsem nebyl ten, kdo prosazoval, že nejsou potřeba statické typy, protože testy. A netvrdím ani to, že statická typová analýza je náhradou testů.
Staticke typy mohou pomoci pri overovani spravnosti kodu, ale jsou zbytne, nezbytne jsou testy. Staticke typy v tomto smeru hraji druhe housle.
Název: Re:Co si myslíte o OOP?
Přispěvatel: operator 08. 01. 2019, 08:00:37
Nemas pravdu ani v jednom pripade. Nevymyslel jsem to ja, implementace funguje a demonstruuji tu vyhody dynamickych jazyku, ktere tu mnozi popiraji. Analogii ve statickem jazyku tu nikdo nepredvedl, asi to vubec nejde a rekl bych, ze odtud prameni tvoje nasranost :-).

My nejsme nasraní, my se podivujeme nad tvojí nezkušeností a zaslepeností. Použít implementation dependent debugger k implementaci historie, to je opravdu majstrštyk hodný uveřejnění na hovnokódu. Mimochodem kdyby sis přečetl dokumentaci k settrace, tak by ses tam dozvěděl mimo mnoho dalších zajímavých věcí i tohle:

CPython implementation detail: The settrace() function is intended only for implementing debuggers, profilers, coverage tools and the like. Its behavior is part of the implementation platform, rather than part of the language definition, and thus may not be available in all Python implementations.
A presne za timto ucelem to pouzivam, k testovani aplikaci. Je to vyborna vec pro realtime aplikace, ktere bezi nonstop a potrebujes jejich chod monitorovat. Program se pozaduje a dodava vzdy na definovane platforme a v definovanem prostredi. Operacnim systemem pocinaje, verzi knihoven konce. Takze to co vnimas jako problem je v praxi nepodstatne a bez problemu toho vyuzivam dele, nez vubec existovaly nektere technologie microsoftu jako treba Silverlight nebo zustali kompatibilni, jako treba access a jeho runtime.
Název: Re:Co si myslíte o OOP?
Přispěvatel: operator 08. 01. 2019, 08:08:06
Při statickém typování se neobejdeš bez testů, používáš tedy dva kontrolní mechanismy. Cílem tvůrců Smalltalku bylo tyto dva mechanismy sloučit do jednoho, tedy do testů. U dynamicky typovaných jazyků jsou tedy v testech i kontroly typů.
Jenže ideální by bylo se obejít zcela bez testů a správnost programu dokázat.
To je samozřejmě hloupost a realita je přesně opačná, bez testů se neobejdeme, bez _statických_ typů ano. Statické typy mají jediné opodstatnění, výkon. Ve všem ostatním jsou nahraditelné.
Když v takovéto diskusi věta začíná: "To je samozřejmě", je to silná indikace, že následuje nepravda. Aspoň jeden věcný argument by nebyl?

Ano, bez testů se neobejdeme, protože neumíme správnost programu dokázat. Ano, bez statických typů se obejdeme, když se smířime se ztrátou výhod, které poskytují. Ne, jejich význam nespočívá jen ve zlepšení výkonu. Také nás zbavují nutnosti psát některé druhy testů a zároveň poskytují lepší záruku správnosti programu.
Pouzil jsem presne tolik argumentu, jako jich bylo pouzito u tvrzeni, na ktere jsem reagoval. Vecne argumenty jsou zrejme, alespon jsem predpokladal, ze je to vsem zrejme. Na tom ze se bez testu neda obejit se shodneme, a nenajde se jediny programator, ktery by kdy poskytl funkcni produkcni kod, aniz by ho otestoval. Ze se lze obejit bez statickych typu pro testovani programu dokazuje rada siroce pouzivanych jazyku, v kterych je napsano nespocet programu, ktere staticke typy nepouzivaji.
Název: Re:Co si myslíte o OOP?
Přispěvatel: anonym 08. 01. 2019, 08:13:13
Nemas pravdu ani v jednom pripade. Nevymyslel jsem to ja, implementace funguje a demonstruuji tu vyhody dynamickych jazyku, ktere tu mnozi popiraji. Analogii ve statickem jazyku tu nikdo nepredvedl, asi to vubec nejde a rekl bych, ze odtud prameni tvoje nasranost :-).

My nejsme nasraní, my se podivujeme nad tvojí nezkušeností a zaslepeností. Použít implementation dependent debugger k implementaci historie, to je opravdu majstrštyk hodný uveřejnění na hovnokódu. Mimochodem kdyby sis přečetl dokumentaci k settrace, tak by ses tam dozvěděl mimo mnoho dalších zajímavých věcí i tohle:

CPython implementation detail: The settrace() function is intended only for implementing debuggers, profilers, coverage tools and the like. Its behavior is part of the implementation platform, rather than part of the language definition, and thus may not be available in all Python implementations.
A presne za timto ucelem to pouzivam, k testovani aplikaci. Je to vyborna vec pro realtime aplikace, ktere bezi nonstop a potrebujes jejich chod monitorovat. Program se pozaduje a dodava vzdy na definovane platforme a v definovanem prostredi. Operacnim systemem pocinaje, verzi knihoven konce. Takze to co vnimas jako problem je v praxi nepodstatne a bez problemu toho vyuzivam dele, nez vubec existovaly nektere technologie microsoftu jako treba Silverlight nebo zustali kompatibilni, jako treba access a jeho runtime.

Aneb zastanci dynamicky typovanych jazyku byli nachytani v nedbalkach  :D

Nedokazu si predstavit, k cemu by tahle funkce byla. Co potrebujes logovat, to si zalogujes, volani metod muzes obcas  logovat pomoci AOP.

Mozna to je uzitecne pro nejake super jednoduche aplikace. V podstate ale neverim, ze pokud to pouzivas, ma tvoje aplikace dobry design. Mam podezreni, ze to delas na koleni. To je uplne typicke pro skriptovaci bastlire. Tahle diskuze je jeden o voze, druhy o koze.
Název: Re:Co si myslíte o OOP?
Přispěvatel: operator 08. 01. 2019, 08:46:29
Nemas pravdu ani v jednom pripade. Nevymyslel jsem to ja, implementace funguje a demonstruuji tu vyhody dynamickych jazyku, ktere tu mnozi popiraji. Analogii ve statickem jazyku tu nikdo nepredvedl, asi to vubec nejde a rekl bych, ze odtud prameni tvoje nasranost :-).

My nejsme nasraní, my se podivujeme nad tvojí nezkušeností a zaslepeností. Použít implementation dependent debugger k implementaci historie, to je opravdu majstrštyk hodný uveřejnění na hovnokódu. Mimochodem kdyby sis přečetl dokumentaci k settrace, tak by ses tam dozvěděl mimo mnoho dalších zajímavých věcí i tohle:

CPython implementation detail: The settrace() function is intended only for implementing debuggers, profilers, coverage tools and the like. Its behavior is part of the implementation platform, rather than part of the language definition, and thus may not be available in all Python implementations.
A presne za timto ucelem to pouzivam, k testovani aplikaci. Je to vyborna vec pro realtime aplikace, ktere bezi nonstop a potrebujes jejich chod monitorovat. Program se pozaduje a dodava vzdy na definovane platforme a v definovanem prostredi. Operacnim systemem pocinaje, verzi knihoven konce. Takze to co vnimas jako problem je v praxi nepodstatne a bez problemu toho vyuzivam dele, nez vubec existovaly nektere technologie microsoftu jako treba Silverlight nebo zustali kompatibilni, jako treba access a jeho runtime.

Aneb zastanci dynamicky typovanych jazyku byli nachytani v nedbalkach  :D

Nedokazu si predstavit, k cemu by tahle funkce byla. Co potrebujes logovat, to si zalogujes, volani metod muzes obcas  logovat pomoci AOP.

Mozna to je uzitecne pro nejake super jednoduche aplikace. V podstate ale neverim, ze pokud to pouzivas, ma tvoje aplikace dobry design. Mam podezreni, ze to delas na koleni. To je uplne typicke pro skriptovaci bastlire. Tahle diskuze je jeden o voze, druhy o koze.
Ne me to pusobi opacnym dojmem. Naslo se neco, na co jsou bezne jazyky se statickym typovanim kratke a nez to priznat, tak radsi sami sebe presvedcime, ze je to na nic. Obavam se, ze kdyby debugger byl domenou jen dynamickych jazyku jako introspekce, tak byste tu houfne tvrdili, ze debugger je na nic, vsak zjistit obsah promenne lze take pomoci logu. Introspekce je velmi uzitecna vlastnost jazyka, ale proc by se mel nekdo zamyslet nad jejimim moznostmi a vyuzitim, kdyzi ji nema k dispozici, ze. Je to neco neznameho, ciziho, fuj, prasacky hack a kdesi cosi - nazval bych to programatorskou xenofobii :-).
Název: Re:Co si myslíte o OOP?
Přispěvatel: Mirek Prýmek 08. 01. 2019, 09:18:03
Ne me to pusobi opacnym dojmem. Naslo se neco, na co jsou bezne jazyky se statickym typovanim kratke a nez to priznat, tak radsi sami sebe presvedcime, ze je to na nic.
Hele, předvedl jsi způsob, jak implementovat nějakou featuru (undo). A implementoval jsi ji prasáckým způsobem, který ve statických jazycích nemá moc ekvivalent. To ale neznamená, že stejná funkcionalita ve statických jazycích nejde implementovat jinak - a daleko čistěji.

Pokud bys chtěl undo implementovat čistě, použiješ explicitní stav a nějaký state store. Podívej se, jak to má udělané třeba Vue.js. JS sice není statický jazyk, ale ani tak tam nepoužili žádnou takovou prasárnu jako ty :)

Obavam se, ze kdyby debugger byl domenou jen dynamickych jazyku jako introspekce, tak byste tu houfne tvrdili, ze debugger je na nic, vsak zjistit obsah promenne lze take pomoci logu. Introspekce je velmi uzitecna vlastnost jazyka, ale proc by se mel nekdo zamyslet nad jejimim moznostmi a vyuzitim, kdyzi ji nema k dispozici, ze. Je to neco neznameho, ciziho, fuj, prasacky hack a kdesi cosi - nazval bych to programatorskou xenofobii :-).
Tvoje obava je zcela lichá.
Název: Re:Co si myslíte o OOP?
Přispěvatel: SB 08. 01. 2019, 09:49:54
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???
Rozhraním, ne? V ObjC se to jmenuje protokol, řekne se, jakou metodu má implementovat, a zbytek už je triviální.

Znamená to, že mám-li různé seznamy různých prvků, nad kterými potřebuju spouštět pokaždé jiné metody, musejí mít ony prvky rozhraní vždy s danou kombinací spouštěných metod, nebo rovnou pro každou metodu jedno rozhraní?
Název: Re:Co si myslíte o OOP?
Přispěvatel: operator 08. 01. 2019, 09:50:05
Ne me to pusobi opacnym dojmem. Naslo se neco, na co jsou bezne jazyky se statickym typovanim kratke a nez to priznat, tak radsi sami sebe presvedcime, ze je to na nic.
Hele, předvedl jsi způsob, jak implementovat nějakou featuru (undo). A implementoval jsi ji prasáckým způsobem, který ve statických jazycích nemá moc ekvivalent. To ale neznamená, že stejná funkcionalita ve statických jazycích nejde implementovat jinak - a daleko čistěji.

Pokud bys chtěl undo implementovat čistě, použiješ explicitní stav a nějaký state store. Podívej se, jak to má udělané třeba Vue.js. JS sice není statický jazyk, ale ani tak tam nepoužili žádnou takovou prasárnu jako ty :)

Obavam se, ze kdyby debugger byl domenou jen dynamickych jazyku jako introspekce, tak byste tu houfne tvrdili, ze debugger je na nic, vsak zjistit obsah promenne lze take pomoci logu. Introspekce je velmi uzitecna vlastnost jazyka, ale proc by se mel nekdo zamyslet nad jejimim moznostmi a vyuzitim, kdyzi ji nema k dispozici, ze. Je to neco neznameho, ciziho, fuj, prasacky hack a kdesi cosi - nazval bych to programatorskou xenofobii :-).
Tvoje obava je zcela lichá.

Predvedl jsem, jak interne bez zasahu kodu zachytavat zmeny promennych bez ohledu na jejich typ. Undo je jednoduchy demonstracni priklad, ktery ukazuje,  ze s nimi lze i nejak pracovat. Mohl jsem misto undo udelat double, ktery by je v pripade numericlych typu hodnoty zdvojnasobil. Asi bych to zase schytal, ze zdvojnasobit hodnoty je k nicemu a jde to udelat i jinak. Vue.js neni nekolikaradkova principialni demonstracni ukazka do disluse, prakticky kod je v pythonu take komplexnejsi, ma nekolik set radek, vyuziva sluzeb modulu inspect, ktery tohobspoustu skryva a ten princip z nej proto neni zrejmy. Poslali byste me do haje, kdybych tu neco takoveho ukazal a po vas pozadoval, abyste naprogramovali ekvivalent. Mate problem uvest ekvivalent primitivni demonstracni ukazky, jejiz podstata vam unika a chytate se marginalii. Po vas se chce, abysye odpovedeli stejne jednoduchou principialni (princip introspekce) ukazkou jak tehoz dosahnout v bezne pouzivanem jazyce se statickymi typy. Popripade pripustili, ze to jednoduse udelat nejde a pochopili s tim, kde jsou vyhody dynamickych jazyku.
Název: Re:Co si myslíte o OOP?
Přispěvatel: SB 08. 01. 2019, 09:55:29
Smysl je ve flexibilite. Zadne paradigma neni objektivne lepsi nez jine a pro ruzne situace muze byt jednou vhodnejsi to a podruhe ono, v Pythonu si je lze podle potřeby vybrat a kombinovat je, zlepsuje to vyjadrovaci prostredky jazyka. To je bez pochyby prinosne a obliba Pythonu prokazuje, ze to za pripadne komplikace stoji.

Nedohadujte se, Python zapouzdreni ma, at se vam to libi nebo ne. Zapouzdreni je abstrakce, ktera progranatorum umoznuje urcity pristup k programovani a Python tento pristup umoznuje.

@instancemethod neni anotace, ale dekorator a tento tam neni, protoze je to vychozi chovani. Stejne byste se mohl ptat, proc se v matematice nepise + pred kladnymi cisly, kdyz u zapornych se pise -.

Tady se neshodneme.
Pythonové "zapouzdření" už neřešte, to už je vyřešené.
Myslím, že jednoduchost, přehlednost, přímočarost, pochopitelnost a systematičnost mnou navrhovaného "classdef" je jasná.
Název: Re:Co si myslíte o OOP?
Přispěvatel: Mirek Prýmek 08. 01. 2019, 09:55:57
Mate problem uvest ekvivalent primitivni demonstracni ukazky, jejiz podstata vam unika a chytate se marginalii. Po vas se chce, abysye odpovedeli stejne jednoduchou principialni (princip introspekce) ukazkou jak tehoz dosahnout v bezne pouzivanem jazyce se statickymi typy. Popripade pripustili, ze to jednoduse udelat nejde a pochopili s tim, kde jsou vyhody dynamickych jazyku.
Dobyvas se do otevrenych dveri. Nikdo tady netvrdi, ze ve statickych jazycich existuji ekvivalenty ke vsem konstrukcim dynamickych jazyku.

Mohl bys pouzit daleko jednodussi argument:

Naimplementujte tohle, volové!
Kód: [Vybrat]
x = pickle.load(...)

To ve statickém jazyce nejde. Minimálně ne tak snadno. A nikdo to nerozporuje.

--
Jinak, celá tahle žabomyší válka je fakt tragikomicky dětinská.
Název: Re:Co si myslíte o OOP?
Přispěvatel: SB 08. 01. 2019, 09:58:29
Vývojář by se především měl zeptat sám sebe, zda ten počet prvků potřebuje k dosažení cíle. Například zmíněné metody seznam.forEach(), seznam.max() tuto potřebu zpravidla eliminují.

Proto o tom mluvím. Kvalitní (jakýkoliv) systém má být především minimalistický, barokních molochů máme všude kolem sebe 3 pr-dele.
Název: Re:Co si myslíte o OOP?
Přispěvatel: v 08. 01. 2019, 10:00:57
Naimplementujte tohle, volové!
Kód: [Vybrat]
x = pickle.load(...)

To ve statickém jazyce nejde. Minimálně ne tak snadno. A nikdo to nerozporuje.
http://hackage.haskell.org/package/python-pickle-0.2.3/docs/Language-Python-Pickle.html ?
Název: Re:Co si myslíte o OOP?
Přispěvatel: BaldSlattery 08. 01. 2019, 10:01:55
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???
Rozhraním, ne? V ObjC se to jmenuje protokol, řekne se, jakou metodu má implementovat, a zbytek už je triviální.

Znamená to, že mám-li různé seznamy různých prvků, nad kterými potřebuju spouštět pokaždé jiné metody, musejí mít ony prvky rozhraní vždy s danou kombinací spouštěných metod, nebo rovnou pro každou metodu jedno rozhraní?
Jasně, že ne. Dělá se to jako protokoly třeba v ObjC. Když už někdo potřebuje takto heterogenní seznam, musí pak použít ve Smalltalk-like jazycích conformsTo: a jinde třeba typové aserce, implementace bývá zcela stejná.
Název: Re:Co si myslíte o OOP?
Přispěvatel: SB 08. 01. 2019, 10:02:12
Rozhraním, ne? V ObjC se to jmenuje protokol, řekne se, jakou metodu má implementovat, a zbytek už je triviální.

Jenže co když některé položky seznamu toto rozhraní nesplňují a tuto metodu implementovánu nemají?
Tak nemá smysl cpát je do batohu, to by si stěžoval i Smalltalk.

Kit to možná chtěl napsat opačně: Co když položky metodu implementovanou mají, ale není v rozhraní.
Název: Re:Co si myslíte o OOP?
Přispěvatel: Mirek Prýmek 08. 01. 2019, 10:03:06
http://hackage.haskell.org/package/python-pickle-0.2.3/docs/Language-Python-Pickle.html ?
Tak jistě, můžeš si klidně implementovat celý Python v Haskellu, že :)
Název: Re:Co si myslíte o OOP?
Přispěvatel: BaldSlattery 08. 01. 2019, 10:10:40
Rozhraním, ne? V ObjC se to jmenuje protokol, řekne se, jakou metodu má implementovat, a zbytek už je triviální.

Jenže co když některé položky seznamu toto rozhraní nesplňují a tuto metodu implementovánu nemají?
Tak nemá smysl cpát je do batohu, to by si stěžoval i Smalltalk.

Kit to možná chtěl napsat opačně: Co když položky metodu implementovanou mají, ale není v rozhraní.
To je pak chyba v návrhu. Ve smalltalkoidním jazyce by nešlo použít conformsTo:, muselo by se sáhnout po respondsTo:, což je méně efektivní nejspíš ve všech jazycích, protože introspekce. Tohle je zřejmě důvod, proč je v Go konformance automatická. Nicméně pokud někdo udělá takovou botu třeba v Javě, tak musí sáhnout po reflexi jako ve Smalltalku, to není nic objevného.
Název: Re:Co si myslíte o OOP?
Přispěvatel: Mirek Prýmek 08. 01. 2019, 10:31:49
Tohle je zřejmě důvod, proč je v Go konformance automatická.
Co tím myslíš? Můžeš to rozvést nebo ilustrovat kódem?
Název: Re:Co si myslíte o OOP?
Přispěvatel: BaldSlattery 08. 01. 2019, 10:55:07
Tohle je zřejmě důvod, proč je v Go konformance automatická.
Co tím myslíš? Můžeš to rozvést nebo ilustrovat kódem?
To přece sám znáš, v Go se neuvádí u struktur implementovaná rozhraní, překladač si je odvodí sám podle implementovaných metod. Příklad: Když nedefinuju pro nějakou svou struct metodu String(), automaticky ji překladač považuje za Stringer, což je rozhraní ze standardní knihovny. To řeší tu zmiňovanou chybu kodéra, co zapomene uvést rozhraní jako podporované.
Název: Re:Co si myslíte o OOP?
Přispěvatel: operator 08. 01. 2019, 11:01:28
Mate problem uvest ekvivalent primitivni demonstracni ukazky, jejiz podstata vam unika a chytate se marginalii. Po vas se chce, abysye odpovedeli stejne jednoduchou principialni (princip introspekce) ukazkou jak tehoz dosahnout v bezne pouzivanem jazyce se statickymi typy. Popripade pripustili, ze to jednoduse udelat nejde a pochopili s tim, kde jsou vyhody dynamickych jazyku.
Dobyvas se do otevrenych dveri. Nikdo tady netvrdi, ze ve statickych jazycich existuji ekvivalenty ke vsem konstrukcim dynamickych jazyku.

Mohl bys pouzit daleko jednodussi argument:

Naimplementujte tohle, volové!
Kód: [Vybrat]
x = pickle.load(...)
To ve statickém jazyce nejde. Minimálně ne tak snadno. A nikdo to nerozporuje.
Jinak, celá tahle žabomyší válka je fakt tragikomicky dětinská.
Pickle pro me neni stezejni. Kdyz slysim dynamicky jazyk, je to pro me v prvni rade flexibilita a jednoduchost psani prehledneho kodu ktery jde primeji k podstate veci a v druhe rade moznost 'magickeho' zasahovani do chodu programu. Moznost menit hriste, na kterem se hraje. To nezajimavejsi na pythonu pro me se popisuje v runtime services: https://docs.python.org/3/library/python.html Obavam se, ze  kritici dynamickych jazyku nevi co to vlastne obnasi, nikdy se nepodivali za zrcadlo. Neumi vyuzit dynamickeho prostredi, boji se ho, jeho moznostina svobody a preferuji totalitu statickeho prostredi, prijde jim bezpecnejsil
Název: Re:Co si myslíte o OOP?
Přispěvatel: Mirek Prýmek 08. 01. 2019, 11:03:10
To přece sám znáš, v Go se neuvádí u struktur implementovaná rozhraní, překladač si je odvodí sám podle implementovaných metod. Příklad: Když nedefinuju pro nějakou svou struct metodu String(), automaticky ji překladač považuje za Stringer, což je rozhraní ze standardní knihovny. To řeší tu zmiňovanou chybu kodéra, co zapomene uvést rozhraní jako podporované.
Jasny, ja jsem jenom blbe pochopil kontext. Ok, dik.
Název: Re:Co si myslíte o OOP?
Přispěvatel: BaldSlattery 08. 01. 2019, 11:10:46
To přece sám znáš, v Go se neuvádí u struktur implementovaná rozhraní, překladač si je odvodí sám podle implementovaných metod. Příklad: Když nedefinuju pro nějakou svou struct metodu String(), automaticky ji překladač považuje za Stringer, což je rozhraní ze standardní knihovny. To řeší tu zmiňovanou chybu kodéra, co zapomene uvést rozhraní jako podporované.
Jasny, ja jsem jenom blbe pochopil kontext. Ok, dik.
BTW tohle by měly mít všechny jazyky, je to praktické.
Název: Re:Co si myslíte o OOP?
Přispěvatel: SB 08. 01. 2019, 11:17:43
Pepa vyrobí .size(), Franta vyrobí .length(), Honza vyrobí .len() ... a pak se v tom vyznej (to už se mi stalo).

Generické věci využívající generické protokoly nemusí bordelit třídní namespace a zbytečně komplikovat dědičnost. Například len() se podívá, jestli si třída implementuje __len__ a pokud ne, tak si ji projde a spočítá počet prvků, takže funguje s čímkoliv, co je iterable. Ditto ostatní takové věci. Ale Control-Space Enter, já vím.

Vidíte, a já měl vždy za to, že to, co vy označujete za bordelení, je cílenou strukturou z důvodu polymorfismu, kdy metoda "len" je implementována ve všech iterable a se stejným názvem, využiju-li k tomu ještě sdílení kódu dědičností, může to stačit napsat jednou. Místo toho funkce "len" přesouvá odpovědnost z objektů do sebe, kdy ve vlastní režii řeší (se snaží řešit), co že je iterable a jakou metodou sděluje délku. Co třídy neodvozené z iterable? Co třídy, které mají zároveň size i len s různým významem? Tohle je bordelení!

Navíc python do jisté míry podporuje funkcionální styl programování, kde se přesně takové věci dělají. A když už mám jazyk, co takové programování podporuje, tak proč bych to nevyužil? Šetří to psaní, lépe se píšou výrazy ve funkcionálním stylu.

Funkcionální programování, nebo jen funkcionální zápis?
To lepší psaní asi nebude objektivně doložitelné, že?

...Když si někde vytvořím _my_private, tak by v code review mělo být nad slunce jasné, že když někdo napíše neco._my_private, že je něco asi špatně.

Bude to v code review stačit? Co interpret, ví o tom?
Název: Re:Co si myslíte o OOP?
Přispěvatel: SB 08. 01. 2019, 11:22:23
Není to problém. Prostě nad tím pustím tu funkci sum() která vynucuje vlastnost "cena" či "objem". A ono se to transitivně propíše i do toho seznamu. Takže někdy v tom okamžiku mi kompilátor začne řvát, že tam má něco nedomyšleného, ať to laskavě domyslím.

Prosím?!
Název: Re:Co si myslíte o OOP?
Přispěvatel: SB 08. 01. 2019, 11:44:17
Testy není nutné psát dřív než kód. U některých je to dost nevhodné. Kdybych bral poslední dvě věty doslova, tak nevím, jak poznám, že je program připraven pro produkční nasazení.

No hlavně se vám to ani nepovede, protože ve statickém jazyku bez existence testovaného ani nepřeložíte test.
Název: Re:Co si myslíte o OOP?
Přispěvatel: SB 08. 01. 2019, 11:56:02
Staticke typy mohou pomoci pri overovani spravnosti kodu, ale jsou zbytne, nezbytne jsou testy. Staticke typy v tomto smeru hraji druhe housle.

Taky si to myslím. Typový systém nahradit testy jde. Testy typovým systémem taky, ale zatím jen teoreticky, prakticky to ještě nikdo nepředvedl. Otázkou tedy (stále) zůstává, zda mi to sraní s typy víc přinese než vezme. To si musí každý soudruh pořešit sám.
Název: Re:Co si myslíte o OOP?
Přispěvatel: SB 08. 01. 2019, 12:09:33
Znamená to, že mám-li různé seznamy různých prvků, nad kterými potřebuju spouštět pokaždé jiné metody, musejí mít ony prvky rozhraní vždy s danou kombinací spouštěných metod, nebo rovnou pro každou metodu jedno rozhraní?
Jasně, že ne. Dělá se to jako protokoly třeba v ObjC. Když už někdo potřebuje takto heterogenní seznam, musí pak použít ve Smalltalk-like jazycích conformsTo: a jinde třeba typové aserce, implementace bývá zcela stejná.

Explicitně definovanými protokoly??? To je ale to samé co rozhraní.
Co to je "Smalltalk-like jazycích"??? V čistě obj. jazycích není žádná podmínka, abych mohl objektu poslat zprávu, o tom se tu bavíme!
Název: Re:Co si myslíte o OOP?
Přispěvatel: BaldSlattery 08. 01. 2019, 12:14:35
Znamená to, že mám-li různé seznamy různých prvků, nad kterými potřebuju spouštět pokaždé jiné metody, musejí mít ony prvky rozhraní vždy s danou kombinací spouštěných metod, nebo rovnou pro každou metodu jedno rozhraní?
Jasně, že ne. Dělá se to jako protokoly třeba v ObjC. Když už někdo potřebuje takto heterogenní seznam, musí pak použít ve Smalltalk-like jazycích conformsTo: a jinde třeba typové aserce, implementace bývá zcela stejná.
Co to je "Smalltalk-like jazycích"???
ObjC třeba. Nebo Smalltalk :)
Název: Re:Co si myslíte o OOP?
Přispěvatel: SB 08. 01. 2019, 12:22:08
Kit to možná chtěl napsat opačně: Co když položky metodu implementovanou mají, ale není v rozhraní.
To je pak chyba v návrhu. Ve smalltalkoidním jazyce by nešlo použít conformsTo:, muselo by se sáhnout po respondsTo:, což je méně efektivní nejspíš ve všech jazycích, protože introspekce. Tohle je zřejmě důvod, proč je v Go konformance automatická. Nicméně pokud někdo udělá takovou botu třeba v Javě, tak musí sáhnout po reflexi jako ve Smalltalku, to není nic objevného.

A v kterém rozhraní má tedy být uvedena metoda např. pro hmotnost?
Smalltalk SERE na rozhraní či třídy, Smalltalk posílá zprávy, objekt vrací hodnotu, nebo chybu. To je celé!
Název: Re:Co si myslíte o OOP?
Přispěvatel: BaldSlattery 08. 01. 2019, 12:26:20
Kit to možná chtěl napsat opačně: Co když položky metodu implementovanou mají, ale není v rozhraní.
To je pak chyba v návrhu. Ve smalltalkoidním jazyce by nešlo použít conformsTo:, muselo by se sáhnout po respondsTo:, což je méně efektivní nejspíš ve všech jazycích, protože introspekce. Tohle je zřejmě důvod, proč je v Go konformance automatická. Nicméně pokud někdo udělá takovou botu třeba v Javě, tak musí sáhnout po reflexi jako ve Smalltalku, to není nic objevného.
A v kterém rozhraní má tedy být uvedena metoda např. pro hmotnost?
Smalltalk SERE na rozhraní či třídy, Smalltalk posílá zprávy, objekt vrací hodnotu, nebo chybu. To je celé!
Tak sem dej kód pro ten batoh, my ti tu pak vysvětlíme, kde děláš ve svém uvažování chybu.
Název: Re:Co si myslíte o OOP?
Přispěvatel: operator 08. 01. 2019, 12:55:22
Staticke typy mohou pomoci pri overovani spravnosti kodu, ale jsou zbytne, nezbytne jsou testy. Staticke typy v tomto smeru hraji druhe housle.

Taky si to myslím. Typový systém nahradit testy jde. Testy typovým systémem taky, ale zatím jen teoreticky, prakticky to ještě nikdo nepředvedl. Otázkou tedy (stále) zůstává, zda mi to sraní s typy víc přinese než vezme. To si musí každý soudruh pořešit sám.

Testy typovym systemem nahradit nelze, protoze neexistuje zadne obecne spravne chovani platne pro vsechny pripady. Jeden a ten samy kod muze byt jednou spatne a po druhe dobre. Funkce, ktera ma na vstupu 1 a na vystupu 0 muze fungovat pro jeden pripad dobre a pro druhy spatne. Jestli funguje podle ocekavani se da zkontrolovat jedine testem, v kterem nase ocekavani bude zahrnuto.
Název: Re:Co si myslíte o OOP?
Přispěvatel: Kit 08. 01. 2019, 13:20:48
Testy není nutné psát dřív než kód. U některých je to dost nevhodné. Kdybych bral poslední dvě věty doslova, tak nevím, jak poznám, že je program připraven pro produkční nasazení.
No hlavně se vám to ani nepovede, protože ve statickém jazyku bez existence testovaného ani nepřeložíte test.

To je právě účelem prvotního spuštění testu. Nesmí projít. Pokud by náhodou prošel, může to být chybou nebo také příznakem, že jsme hotovi.
Název: Re:Co si myslíte o OOP?
Přispěvatel: operator 08. 01. 2019, 13:21:09
...Když si někde vytvořím _my_private, tak by v code review mělo být nad slunce jasné, že když někdo napíše neco._my_private, že je něco asi špatně.
Bude to v code review stačit? Co interpret, ví o tom?
Ano, tohle by mohl interpret zachytit a poskytnout varovani. V praxi to zachyti lint.

Kód: [Vybrat]
~ $ cat xx.py
class Cls(object):
    def __init__(self):
        self.__var = 1

if  __name__ == '__main__':
    INS = Cls()
    print INS._Cls__var
~ $ pylint xx.py
Using config file /data/data/com.termux/files/home/.pylintrc
************* Module xx
R:  1, 0: Too few public methods (0/2) (too-few-public-methods)
E:  7,10: Instance of 'Cls' has no '_Cls__var' member (no-member)
W:  7,10: Access to a protected member _Cls__var of a client class (protected-access)

--------------------------------------------------------------------
Your code has been rated at -1.67/10 (previous run: -1.67/10, +0.00)

~ $ python2 xx.py
1
Název: Re:Co si myslíte o OOP?
Přispěvatel: Mirek Prýmek 08. 01. 2019, 14:01:19
BTW tohle by měly mít všechny jazyky, je to praktické.
Souhlas, tohle je rozhodne jedna z tech svetlejsich stranek Gocka :)
Název: Re:Co si myslíte o OOP?
Přispěvatel: BoneFlute 08. 01. 2019, 14:18:30
Testy typovym systemem nahradit nelze, protoze neexistuje zadne obecne spravne chovani platne pro vsechny pripady. Jeden a ten samy kod muze byt jednou spatne a po druhe dobre. Funkce, ktera ma na vstupu 1 a na vystupu 0 muze fungovat pro jeden pripad dobre a pro druhy spatne. Jestli funguje podle ocekavani se da zkontrolovat jedine testem, v kterem nase ocekavani bude zahrnuto.

To je samozřejmě pravda. Problém je v tom, že naopak je to ještě horší. Pár scénářů, které typy nezvládnou, zatímco většina scénářů, které pro změnu nezvládnou testy.

Takže druhé housle hrají testy.
Název: Re:Co si myslíte o OOP?
Přispěvatel: BoneFlute 08. 01. 2019, 14:21:44
Taky si to myslím. Typový systém nahradit testy jde.
Nahraď mi prosím typy za testy u tohoto příkladu:

Kód: [Vybrat]
inc (x: Int) = x + 1
Každopádně problém místních je v tom, že si nečtou argumenty. Takže za mě končím.
Název: Re:Co si myslíte o OOP?
Přispěvatel: operator 08. 01. 2019, 14:42:26
Testy typovym systemem nahradit nelze, protoze neexistuje zadne obecne spravne chovani platne pro vsechny pripady. Jeden a ten samy kod muze byt jednou spatne a po druhe dobre. Funkce, ktera ma na vstupu 1 a na vystupu 0 muze fungovat pro jeden pripad dobre a pro druhy spatne. Jestli funguje podle ocekavani se da zkontrolovat jedine testem, v kterem nase ocekavani bude zahrnuto.

To je samozřejmě pravda. Problém je v tom, že naopak je to ještě horší. Pár scénářů, které typy nezvládnou, zatímco většina scénářů, které pro změnu nezvládnou testy.

Takže druhé housle hrají testy.
A proto tu mame rozsirene jazyky bez statickych typu a vsechy programy psane v programech se statickymi typy je nutno dukladne testovat. To jsou mi pekne druhe housle. :-)
Název: Re:Co si myslíte o OOP?
Přispěvatel: Ondrej Nemecek 08. 01. 2019, 14:45:08
IMHO by bylo užitečnější místo této diskuze vést polemiku ve formě série článků s různými autory. Autoři by museli lépe argumentovat a uvést konkrétní příklady, na které by se pak lépe reagovalo. Portál by měl přísun zajímavých článků a paradoxně by si možná všichni ušetřili čas promrhaný v diskuzi... :-D
Název: Re:Co si myslíte o OOP?
Přispěvatel: Mirek Prýmek 08. 01. 2019, 14:52:16
Autoři by museli lépe argumentovat
Anebo by placali uplne stejne neplodne, neposlouchali se, vedli svuj monolog, akorat na desetkrat vetsi plose :)
Název: Re:Co si myslíte o OOP?
Přispěvatel: Inkvizitor 08. 01. 2019, 15:08:07
BTW tohle by měly mít všechny jazyky, je to praktické.
Souhlas, tohle je rozhodne jedna z tech svetlejsich stranek Gocka :)

Bohuzel to je dvojsecne. Napr. Rust dovoluje implementovat stejnou metodu pro typ pro ruzne traity (aka interfacy). K te duplicite muze dojit, protoze traity lze definovat uzivatelsky v kteremkoli modulu a duplicite se obecne nelze vyhnout, protoze stejny napad na nazev muze dostat vice lidi. Chapu, ze pristup Go ma svoje vyhody a muze byt prijemny, na druhou stranu zase nevidim zadnou zvlastni komplikaci v tom, ze implementaci interface/traitu musi autor explicitne deklarovat. Typovy system to pozna, prekladac to validuje, prace s tim prakticky zadna neni, IMO soudruzi v Google opet soustredili svoje usili ponekud pochybnym smerem.
Název: Re:Co si myslíte o OOP?
Přispěvatel: I/O 08. 01. 2019, 15:27:01
IMHO by bylo užitečnější místo této diskuze vést polemiku ve formě série článků s různými autory. Autoři by museli lépe argumentovat a uvést konkrétní příklady, na které by se pak lépe reagovalo. Portál by měl přísun zajímavých článků a paradoxně by si možná všichni ušetřili čas promrhaný v diskuzi... :-D
A s kterými? :D Kdyby tu polemiku vedli lidé jako A. Kay, D. Knuth nebo N. Wirth, tak bych si ji i rád přečetl. Ale na myšlenkové průjmy jakýchsi bezvýznamných českých Brouků Pytlíků bych fakt zvědavý nebyl. Takže když se tu nějaký anonymní niemand vysmívá dynamicky typovaným jazykům a lidem, kteří je používají, tak má pro mě mnohem větší váhu názor nositele Turingovy ceny:

I'm not against types, but I don't know of any type systems that aren't a complete pain, so I still like dynamic typing.
Název: Re:Co si myslíte o OOP?
Přispěvatel: pepa 08. 01. 2019, 15:38:30
I'm not against types, but I don't know of any type systems that aren't a complete pain, so I still like dynamic typing.

Asi nějaká lopata, která si myslí, že statické typy jsou jen na zlepšení výkonu ;D
Název: Re:Co si myslíte o OOP?
Přispěvatel: Inkvizitor 08. 01. 2019, 15:40:53
I'm not against types, but I don't know of any type systems that aren't a complete pain, so I still like dynamic typing.

Asi nějaká lopata, která si myslí, že statické typy jsou jen na zlepšení výkonu ;D

Ne, je to jinak. Protoze Alan Kay v roce 2003 prohlasil, ze vsechny typove systemy ktere zna, jsou moc velky opruz, je to vecna a nezpochybnitelna pravda platna i pro vsechny jazyky budoucnosti a diskuse je zbytecna.
Název: Re:Co si myslíte o OOP?
Přispěvatel: v 08. 01. 2019, 15:52:41
IMHO by bylo užitečnější místo této diskuze vést polemiku ve formě série článků s různými autory. Autoři by museli lépe argumentovat a uvést konkrétní příklady, na které by se pak lépe reagovalo. Portál by měl přísun zajímavých článků a paradoxně by si možná všichni ušetřili čas promrhaný v diskuzi... :-D
A s kterými? :D Kdyby tu polemiku vedli lidé jako A. Kay, D. Knuth nebo N. Wirth, tak bych si ji i rád přečetl. Ale na myšlenkové průjmy jakýchsi bezvýznamných českých Brouků Pytlíků bych fakt zvědavý nebyl. Takže když se tu nějaký anonymní niemand vysmívá dynamicky typovaným jazykům a lidem, kteří je používají, tak má pro mě mnohem větší váhu názor nositele Turingovy ceny:

I'm not against types, but I don't know of any type systems that aren't a complete pain, so I still like dynamic typing.
"I thought of objects being like biological cells and/or individual computers on a network, only able to communicate with messages"
- nositel turingovy ceny

"When people who can’t think logically design large systems, those systems become incomprehensible. And we start thinking of them as biological systems.  And since biological systems are too complex to understand, it seems perfectly natural that computer programs should be too complex to understand.
We should not accept this."
-jiný nositel turingovy ceny
Název: Re:Co si myslíte o OOP?
Přispěvatel: operator 08. 01. 2019, 16:28:50
I'm not against types, but I don't know of any type systems that aren't a complete pain, so I still like dynamic typing.
Asi nějaká lopata, která si myslí, že statické typy jsou jen na zlepšení výkonu ;D
Nevyuzivaji se jen na zlepseni vykonu, ale kvuli tomu vznikly a v tom jedinem jsou nenahraditelne.
Název: Re:Co si myslíte o OOP?
Přispěvatel: I/O 08. 01. 2019, 16:43:35
I'm not against types, but I don't know of any type systems that aren't a complete pain, so I still like dynamic typing.

Asi nějaká lopata, která si myslí, že statické typy jsou jen na zlepšení výkonu ;D

Ne, je to jinak. Protoze Alan Kay v roce 2003 prohlasil, ze vsechny typove systemy ktere zna, jsou moc velky opruz, je to vecna a nezpochybnitelna pravda platna i pro vsechny jazyky budoucnosti a diskuse je zbytecna.

Haskell v té době už existoval a ničím typově sofistikovanějším tu neargumentujete. Ostatně můžete shrnout své dojmy a zeptat se ho, co si o tom myslí dnes. Je to člověk, který by vám i odpověděl, když by viděl, že to má hlavu a patu, narozdíl od většiny českých profesůrků a inžynýrků z všelijakých sorbonn v Horní Dolní, kteří mají dojem, že je pod jejich úroveň na takové dotazy od prostého lidu reagovat.

Podle mě to jsou ale debaty na úrovni andělů na špičce jehly. Navíc působíte dojmem "dílcovou metodou odhadneme rychlost nepřátelského tanku". Sorry jako.

"I thought of objects being like biological cells and/or individual computers on a network, only able to communicate with messages"
- nositel turingovy ceny

"When people who can’t think logically design large systems, those systems become incomprehensible. And we start thinking of them as biological systems.  And since biological systems are too complex to understand, it seems perfectly natural that computer programs should be too complex to understand.
We should not accept this."
-jiný nositel turingovy ceny
A?
Název: Re:Co si myslíte o OOP?
Přispěvatel: Inkvizitor 08. 01. 2019, 17:03:06
Ne, je to jinak. Protoze Alan Kay v roce 2003 prohlasil, ze vsechny typove systemy ktere zna, jsou moc velky opruz, je to vecna a nezpochybnitelna pravda platna i pro vsechny jazyky budoucnosti a diskuse je zbytecna.

Haskell v té době už existoval a ničím typově sofistikovanějším tu neargumentujete. Ostatně můžete shrnout své dojmy a zeptat se ho, co si o tom myslí dnes. Je to člověk, který by vám i odpověděl, když by viděl, že to má hlavu a patu, narozdíl od většiny českých profesůrků a inžynýrků z všelijakých sorbonn v Horní Dolní, kteří mají dojem, že je pod jejich úroveň na takové dotazy od prostého lidu reagovat.

Podle mě to jsou ale debaty na úrovni andělů na špičce jehly. Navíc působíte dojmem "dílcovou metodou odhadneme rychlost nepřátelského tanku". Sorry jako.

No tak v prve rade tohle je opravdu normalni pokec a ne vedecka rozprava. Nikdy nikde krome ceskych for jsem ale nevidel, ze by nekdo prisel a en bloc napsal "nemate k tomu co rict, tudiz je debata bezcenna". Na Hacker News napriklad.

No a ta narazka na Haskell je nesmyslna. Kay netvrdi, ze typovy system Haskellu je malo sofistikovany, on se k Haskellu nevyjadruje vubec a je otazka, ktere jazyky skutecne zkousel prakticky pouzivat a co mu vadilo. IMO je proste zvykly fungovat jinak, vypiplal si Smalltalk apod. a v zasade vubec nema motivaci se do neceho "z opacne strany" seriozne poustet. To je pro me cely smysl toho citatu - v dynamickych jazycich se mu dela dobre a uz stejne osobne nebude presedlavat jinam. Pro nikoho dalsiho z toho nic neplyne, je to pratelske poplacani starsiho kamarada, ktery vidi svet jako nekteri dalsi kluci.

Cely ten citat ma psychologicky vyznam, ale argumentacne to nepomaha (je to spis argumentacni faul cesky zvany "dovolavani se autority"). Uplne rozumim tomu, ze zdejsi ucastniky nepovazujes za dostatecne erudovane, ale v takovem pripade je snad lepsi to nechat byt a jit jinam.
Název: Re:Co si myslíte o OOP?
Přispěvatel: SB 08. 01. 2019, 17:05:41
A v kterém rozhraní má tedy být uvedena metoda např. pro hmotnost?
Smalltalk SERE na rozhraní či třídy, Smalltalk posílá zprávy, objekt vrací hodnotu, nebo chybu. To je celé!
Tak sem dej kód pro ten batoh, my ti tu pak vysvětlíme, kde děláš ve svém uvažování chybu.

Kód: [Vybrat]
batoh := Bag new.
batoh add: (Kámen ofSize: 10 andWeight: 20).
batoh add: (Sekyrka ofMaterial: #ocel andWeight: 20).
batoh add: (Hovno ofColour: #tmavěHnědá andWeight: 120).

batoh sum: [ :x | x weight ].

"se zohledněním nevhodného prvku"
batoh sum: [ :x | [ x weight ] ifError: [ 0 ] ].
Název: Re:Co si myslíte o OOP?
Přispěvatel: Mirek Prýmek 08. 01. 2019, 17:15:05
Chapu, ze pristup Go ma svoje vyhody a muze byt prijemny, na druhou stranu zase nevidim zadnou zvlastni komplikaci v tom, ze implementaci interface/traitu musi autor explicitne deklarovat. Typovy system to pozna, prekladac to validuje, prace s tim prakticky zadna neni
No kdyz muze prekladac najit definici traitu kdekoli ve zdrojacich, tak uplne stejne muze najit i ten konflikt, takze to mi uplne jako argument neprijde.

Ale pripomnel jsi mi, ze jednu fakt blbou vlastnost to ma: kdyz interfejs implementuju explicitne, muze mi prekladac ohlasit, ze mi neco chybi, primo na tom miste, kde to chybi. Kdyz je to implicitni, tak mi (v lepsim pripade) oznami na uplne jinem miste, ze pro tuhle strukturu interfejs definovany neni (clovek se drbe na hlave jakto, kdyz pred chvili byl - a pricinu musi hledat uplne jinde nez kde je chyba, prekladac mu s tim nepomuze). Anebo (v horsim pripade) mu to prestane fungovat az v testech (nedej matko prirodo na produkci), protoze se mu ve switchi nenamatchoval interface, pac ho kvuli nejake trivialni chybe najednou neimplementuje :)

Jednou se mi tohle stalo a pekne jsem si trhal vlasy, takze nakonec mas vlastne asi pravdu, zas tak dobra featura to neni. Ten spatnej zazitek muj mozek asi sebezachovne vytesnil ;)
Název: Re:Co si myslíte o OOP?
Přispěvatel: v 08. 01. 2019, 17:21:52
Chapu, ze pristup Go ma svoje vyhody a muze byt prijemny, na druhou stranu zase nevidim zadnou zvlastni komplikaci v tom, ze implementaci interface/traitu musi autor explicitne deklarovat. Typovy system to pozna, prekladac to validuje, prace s tim prakticky zadna neni
No kdyz muze prekladac najit definici traitu kdekoli ve zdrojacich, tak uplne stejne muze najit i ten konflikt, takze to mi uplne jako argument neprijde.

Ale pripomnel jsi mi, ze jednu fakt blbou vlastnost to ma: kdyz interfejs implementuju explicitne, muze mi prekladac ohlasit, ze mi neco chybi, primo na tom miste, kde to chybi. Kdyz je to implicitni, tak mi (v lepsim pripade) oznami na uplne jinem miste, ze pro tuhle strukturu interfejs definovany neni (clovek se drbe na hlave jakto, kdyz pred chvili byl - a pricinu musi hledat uplne jinde nez kde je chyba, prekladac mu s tim nepomuze). Anebo (v horsim pripade) mu to prestane fungovat az v testech (nedej matko prirodo na produkci), protoze se mu ve switchi nenamatchoval interface, pac ho kvuli nejake trivialni chybe najednou neimplementuje :)

Jednou se mi tohle stalo a pekne jsem si trhal vlasy, takze nakonec mas vlastne asi pravdu, zas tak dobra featura to neni. Ten spatnej zazitek muj mozek asi sebezachovne vytesnil ;)
mi nějak nedochází jak to funguje, např. mám strukturu x = (y, z), tak pro (f x) se provede (f y) a (f z) a hodnota (f x) se určí jak?
Název: Re:Co si myslíte o OOP?
Přispěvatel: Mirek Prýmek 08. 01. 2019, 17:23:37
Podle mě to jsou ale debaty na úrovni andělů na špičce jehly.
Tak to ani náhodou. Debata o andělech byla daleko smysluplnější. To jenom dneska si ve své samolibé pýše myslime, že když je někde slovo "anděl", musí to být už z principu zhovadilost, i když o tom vůbec nic nevíme :)
Název: Re:Co si myslíte o OOP?
Přispěvatel: v 08. 01. 2019, 17:26:17
"I thought of objects being like biological cells and/or individual computers on a network, only able to communicate with messages"
- nositel turingovy ceny

"When people who can’t think logically design large systems, those systems become incomprehensible. And we start thinking of them as biological systems.  And since biological systems are too complex to understand, it seems perfectly natural that computer programs should be too complex to understand.
We should not accept this."
-jiný nositel turingovy ceny
A?
a ještě Robin Milner dostal turingovu cenu
Název: Re:Co si myslíte o OOP?
Přispěvatel: Mirek Prýmek 08. 01. 2019, 17:27:49
mi nějak nedochází jak to funguje, např. mám strukturu x = (y, z), tak pro (f x) se provede (f y) a (f z) a hodnota (f x) se určí jak?
https://tour.golang.org/methods/10
Název: Re:Co si myslíte o OOP?
Přispěvatel: SB 08. 01. 2019, 17:36:48
No hlavně se vám to ani nepovede, protože ve statickém jazyku bez existence testovaného ani nepřeložíte test.

To je právě účelem prvotního spuštění testu. Nesmí projít. Pokud by náhodou prošel, může to být chybou nebo také příznakem, že jsme hotovi.

Četl jste to pozorně?
Název: Re:Co si myslíte o OOP?
Přispěvatel: v 08. 01. 2019, 17:41:08
mi nějak nedochází jak to funguje, např. mám strukturu x = (y, z), tak pro (f x) se provede (f y) a (f z) a hodnota (f x) se určí jak?
https://tour.golang.org/methods/10
děkuji, ale asi jsem se zeptal blbě
Název: Re:Co si myslíte o OOP?
Přispěvatel: Mirek Prýmek 08. 01. 2019, 17:58:29
děkuji, ale asi jsem se zeptal blbě
Nebo jsem blbec já, to je v poho, zkus to třeba jinak :)
Název: Re:Co si myslíte o OOP?
Přispěvatel: BaldSlattery 08. 01. 2019, 18:35:46
A v kterém rozhraní má tedy být uvedena metoda např. pro hmotnost?
Smalltalk SERE na rozhraní či třídy, Smalltalk posílá zprávy, objekt vrací hodnotu, nebo chybu. To je celé!
Tak sem dej kód pro ten batoh

Kód: [Vybrat]
batoh := Bag new.
batoh add: (Kámen ofSize: 10 andWeight: 20).
batoh add: (Sekyrka ofMaterial: #ocel andWeight: 20).
batoh add: (Hovno ofColour: #tmavěHnědá andWeight: 120).

batoh sum: [ :x | x weight ].

"se zohledněním nevhodného prvku"
batoh sum: [ :x | [ x weight ] ifError: [ 0 ] ].
No super, takže v Go se to řeší za běhu úplně stejně pomocí typové aserce, kde je teda problém? Mimochodem moderní Smalltalk má protokoly taky, protože bez nich vzniká prasokód.
Název: Re:Co si myslíte o OOP?
Přispěvatel: v 08. 01. 2019, 19:26:09
děkuji, ale asi jsem se zeptal blbě
Nebo jsem blbec já, to je v poho, zkus to třeba jinak :)
zkusil jsem to obvyklým způsobem - nainstaloval go, vyzkoušel si to a zřejmě jsem to chápal blbě, představoval jsem si něco jako conditional conformance ze swiftu
Název: Re:Co si myslíte o OOP?
Přispěvatel: BaldSlattery 08. 01. 2019, 20:10:49
představoval jsem si něco jako conditional conformance ze swiftu
Ta ale k životu potřebuje generika, ne?
Název: Re:Co si myslíte o OOP?
Přispěvatel: Mirek Prýmek 08. 01. 2019, 20:34:21
zkusil jsem to obvyklým způsobem - nainstaloval go, vyzkoušel si to a zřejmě jsem to chápal blbě, představoval jsem si něco jako conditional conformance ze swiftu
Rule of thumb: neočekávat od Go nic, co by mohlo budit dojem pokročilosti ;)

P.S. conditional conformance jsem neznal, je to zajímavý, dík za zmínku
Název: Re:Co si myslíte o OOP?
Přispěvatel: Inkvizitor 08. 01. 2019, 20:52:02
Chapu, ze pristup Go ma svoje vyhody a muze byt prijemny, na druhou stranu zase nevidim zadnou zvlastni komplikaci v tom, ze implementaci interface/traitu musi autor explicitne deklarovat. Typovy system to pozna, prekladac to validuje, prace s tim prakticky zadna neni
No kdyz muze prekladac najit definici traitu kdekoli ve zdrojacich, tak uplne stejne muze najit i ten konflikt, takze to mi uplne jako argument neprijde.

Možná jsme se nepochopili, já jsem to moc nerozvedl. Může nastat situace, kdy chci naimplementovat v jednom typu dva traity se stejnou metodou (signarurou metody a bez explicitního přiřazení do daných traitů to nejde udělat. Pak samozřejmě musím mít způsob, jak danou metodu vybrat, když ji potřebuju volat:

https://stackoverflow.com/questions/44953197/how-do-i-disambiguate-traits-in-rust

Konflikt překladač najít může, ale vyřešit ho neumí. Další věc je, že pokud se sejdou dva traity se stejnou signaturou metody, je dost možné, že ta metoda nemá tu samou sémantiku, byť se jmenuje stejně. Takže já mám interface, Pepa zvolil jméno metody stejné jako je v interface, takže formálně ten interface naimplementoval, přijde Karel a bezelstně začne ten interface s tím typem používat, jenže ono to dělá trochu něco jiného, než Karel a autor toho interface předpokládali. V tomhle je nevýhoda duck typingu - předpokládat, že to samé slovo znamená vždy totéž, je obecně naivní. V uzavřeném ekosystému, kde si všichni rozumějí skoro i beze slov, problém nenastává, ale v "promiskutním" prostředí, kde se do produktu míchá X programátorů a skládá výsledek z Y externích knihoven, problém může být velký.
Název: Re:Co si myslíte o OOP?
Přispěvatel: Mirek Prýmek 08. 01. 2019, 21:15:49
přijde Karel a bezelstně začne ten interface s tím typem používat, jenže ono to dělá trochu něco jiného
K tomu ale může dojít i bez interfejsů. Pokud si jenom podle názvu metody myslím, že něco dělá, tak se můžu splést :)
Celkem ale souhlasím, asi to docela nebezpečné je.

(Takže ve finále jsem došel k tomu, že vlastně ty implicitní interfejsy vůbec nejsou dobrej nápad :)) )
Název: Re:Co si myslíte o OOP?
Přispěvatel: Sunar 08. 01. 2019, 21:24:19
přijde Karel a bezelstně začne ten interface s tím typem používat, jenže ono to dělá trochu něco jiného
K tomu ale může dojít i bez interfejsů. Pokud si jenom podle názvu metody myslím, že něco dělá, tak se můžu splést :)
Celkem ale souhlasím, asi to docela nebezpečné je.

(Takže ve finále jsem došel k tomu, že vlastně ty implicitní interfejsy vůbec nejsou dobrej nápad :)) )
Čekal jsem, kdy na to přijdete. Zen of Python: Explicit is better than implicit.
Název: Re:Co si myslíte o OOP?
Přispěvatel: tralala 08. 01. 2019, 21:24:44
lenze kompilator a jazyk je len tak blbovzdorny jak si ho spravis.

uz samotna premisa "dva traity rovnaka metoda" je blbost. mas to na prd navrhnute ked to niekto takto pouzije.

v scale ked ti toto nastane, tak je tam tzv linearizacia tych traitov. riesi to dobre znamy diamond problem

https://www.trivento.io/trait-linearization/
Název: Re:Co si myslíte o OOP?
Přispěvatel: Mirek Prýmek 08. 01. 2019, 21:29:57
Zen of Python: Explicit is better than implicit.
Třeba explicit types?

Zen of the World: všechna všeobecná tvrzení jsou nepravdivá.
Název: Re:Co si myslíte o OOP?
Přispěvatel: Sunar 08. 01. 2019, 21:31:53
Taky si to myslím. Typový systém nahradit testy jde.
Nahraď mi prosím typy za testy u tohoto příkladu:
Kód: [Vybrat]
inc (x: Int) = x + 1Každopádně problém místních je v tom, že si nečtou argumenty. Takže za mě končím.
Testy se nedělají na jeden řádek kódu, ale na funkční celek, třeba funkci. Jak typem zkontroluješ, že jsi omylem nenapsal 2 místo 1?
Název: Re:Co si myslíte o OOP?
Přispěvatel: v 08. 01. 2019, 21:35:22
Taky si to myslím. Typový systém nahradit testy jde.
Nahraď mi prosím typy za testy u tohoto příkladu:
Kód: [Vybrat]
inc (x: Int) = x + 1Každopádně problém místních je v tom, že si nečtou argumenty. Takže za mě končím.
Testy se nedělají na jeden řádek kódu, ale na funkční celek, třeba funkci. Jak typem zkontroluješ, že jsi omylem nenapsal 2 místo 1?
třeba
Kód: [Vybrat]
inc :: Nat n -> Nat (S n)
Název: Re:Co si myslíte o OOP?
Přispěvatel: Sunar 08. 01. 2019, 21:36:00
Zen of Python: Explicit is better than implicit.
Třeba explicit types?

Zen of the World: všechna všeobecná tvrzení jsou nepravdivá.
Většina tvých tvrzení je všeobecná.

Na typy se to dá vztáhnout také, ale spíše na implicitní versus explicitní přetypování, tedy slabé vs. silné typy.
Název: Re:Co si myslíte o OOP?
Přispěvatel: v 08. 01. 2019, 21:39:18
představoval jsem si něco jako conditional conformance ze swiftu
Ta ale k životu potřebuje generika, ne?
to ano, ten můj chybný dojem byl, že když všechny prvky struktury (nebo pole) jsou typu který implementuje rozhraní, tak struktura implementuje rozhraní
Název: Re:Co si myslíte o OOP?
Přispěvatel: Kit 08. 01. 2019, 21:41:43
Taky si to myslím. Typový systém nahradit testy jde.
Nahraď mi prosím typy za testy u tohoto příkladu:
Kód: [Vybrat]
inc (x: Int) = x + 1Každopádně problém místních je v tom, že si nečtou argumenty. Takže za mě končím.
Testy se nedělají na jeden řádek kódu, ale na funkční celek, třeba funkci. Jak typem zkontroluješ, že jsi omylem nenapsal 2 místo 1?
třeba
Kód: [Vybrat]
inc :: Nat n -> Nat (S n)

To vypadá jako kruhová definice. Skutečně to odhalí chybu, když místo čísla 5 tam dám omylem číslo 7?
Název: Re:Co si myslíte o OOP?
Přispěvatel: Sunar 08. 01. 2019, 21:44:36
Taky si to myslím. Typový systém nahradit testy jde.
Nahraď mi prosím typy za testy u tohoto příkladu:
Kód: [Vybrat]
inc (x: Int) = x + 1Každopádně problém místních je v tom, že si nečtou argumenty. Takže za mě končím.
Testy se nedělají na jeden řádek kódu, ale na funkční celek, třeba funkci. Jak typem zkontroluješ, že jsi omylem nenapsal 2 místo 1?
třeba
Kód: [Vybrat]
inc :: Nat n -> Nat (S n)
Co je to za jazyk, není to srozumitelné? Dokáže to zajistit to, že hodnota tohoto typu v jedné funkci může být zvýšena právě o jedna, v jiné právě o dva a v třetí může být změněna v závislosti na jiné hodnotě jiného typu a tim zkontrolovat funkčnost funkce? Co v případě, že funkce vrací jiný typ, než je parametr. Je kontrola správnosti funkce součástí vstupního nebo výstupního typu?
Název: Re:Co si myslíte o OOP?
Přispěvatel: BoneFlute 08. 01. 2019, 21:45:18
Taky si to myslím. Typový systém nahradit testy jde.
Nahraď mi prosím typy za testy u tohoto příkladu:
Kód: [Vybrat]
inc (x: Int) = x + 1Každopádně problém místních je v tom, že si nečtou argumenty. Takže za mě končím.
Testy se nedělají na jeden řádek kódu, ale na funkční celek, třeba funkci. Jak typem zkontroluješ, že jsi omylem nenapsal 2 místo 1?
inc je funkce.
Otázka nezní zda lze typem zcela nahradit testy, ale vaše opačné tvrzení, že typy lze nahradit testy.
Název: Re:Co si myslíte o OOP?
Přispěvatel: Kit 08. 01. 2019, 21:47:01
inc je funkce.
Otázka nezní zda lze typem zcela nahradit testy, ale vaše opačné tvrzení, že typy lze nahradit testy.

V OOP se nebavíme o funkcích, ale o metodách.
Název: Re:Co si myslíte o OOP?
Přispěvatel: v 08. 01. 2019, 21:51:23
Taky si to myslím. Typový systém nahradit testy jde.
Nahraď mi prosím typy za testy u tohoto příkladu:
Kód: [Vybrat]
inc (x: Int) = x + 1Každopádně problém místních je v tom, že si nečtou argumenty. Takže za mě končím.
Testy se nedělají na jeden řádek kódu, ale na funkční celek, třeba funkci. Jak typem zkontroluješ, že jsi omylem nenapsal 2 místo 1?
třeba
Kód: [Vybrat]
inc :: Nat n -> Nat (S n)

To vypadá jako kruhová definice. Skutečně to odhalí chybu, když místo čísla 5 tam dám omylem číslo 7?
jasně, tady je kód, přeju příjemnou zábavu
Kód: [Vybrat]
{-# LANGUAGE GADTs, TypeInType #-}

import Data.Kind

data Nat :: Type where
Z :: Nat
S :: !Nat -> Nat

data Nat' :: Nat -> Type where
Z' :: Nat' Z
S' :: !(Nat' n) -> Nat' (S n)

inc :: Nat' n -> Nat' (S n)
inc = S'
Název: Re:Co si myslíte o OOP?
Přispěvatel: v 08. 01. 2019, 21:54:46
Taky si to myslím. Typový systém nahradit testy jde.
Nahraď mi prosím typy za testy u tohoto příkladu:
Kód: [Vybrat]
inc (x: Int) = x + 1Každopádně problém místních je v tom, že si nečtou argumenty. Takže za mě končím.
Testy se nedělají na jeden řádek kódu, ale na funkční celek, třeba funkci. Jak typem zkontroluješ, že jsi omylem nenapsal 2 místo 1?
třeba
Kód: [Vybrat]
inc :: Nat n -> Nat (S n)
Co je to za jazyk, není to srozumitelné? Dokáže to zajistit to, že hodnota tohoto typu v jedné funkci může být zvýšena právě o jedna, v jiné právě o dva a v třetí může být změněna v závislosti na jiné hodnotě jiného typu a tim zkontrolovat funkčnost funkce? Co v případě, že funkce vrací jiný typ, než je parametr. Je kontrola správnosti funkce součástí vstupního nebo výstupního typu?
haskell, viz výše, je to typ funkce, která inkrementuje přirozené číslo, pokud by měla dělat něco jiného, měla by jiný typ
Název: Re:Co si myslíte o OOP?
Přispěvatel: Sunar 08. 01. 2019, 22:01:14
Taky si to myslím. Typový systém nahradit testy jde.
Nahraď mi prosím typy za testy u tohoto příkladu:
Kód: [Vybrat]
inc (x: Int) = x + 1Každopádně problém místních je v tom, že si nečtou argumenty. Takže za mě končím.
Testy se nedělají na jeden řádek kódu, ale na funkční celek, třeba funkci. Jak typem zkontroluješ, že jsi omylem nenapsal 2 místo 1?
inc je funkce.
Otázka nezní zda lze typem zcela nahradit testy, ale vaše opačné tvrzení, že typy lze nahradit testy.
Nečetl jsem poctivě celou diskusi, ale předpokládám, že takové tvrzení tu nezaznělo. Diskuse běží na téma potřebnosti statických typů k ověření bezchybnosti programu, nikoliv nahrazení typů.
Název: Re:Co si myslíte o OOP?
Přispěvatel: BoneFlute 08. 01. 2019, 22:09:17
Taky si to myslím. Typový systém nahradit testy jde.
Nahraď mi prosím typy za testy u tohoto příkladu:
Kód: [Vybrat]
inc (x: Int) = x + 1Každopádně problém místních je v tom, že si nečtou argumenty. Takže za mě končím.
Testy se nedělají na jeden řádek kódu, ale na funkční celek, třeba funkci. Jak typem zkontroluješ, že jsi omylem nenapsal 2 místo 1?
inc je funkce.
Otázka nezní zda lze typem zcela nahradit testy, ale vaše opačné tvrzení, že typy lze nahradit testy.
Nečetl jsem poctivě celou diskusi, ale předpokládám, že takové tvrzení tu nezaznělo. Diskuse běží na téma potřebnosti statických typů k ověření bezchybnosti programu, nikoliv nahrazení typů.
Název: Re:Co si myslíte o OOP?
Přispěvatel: Sunar 08. 01. 2019, 22:17:48
Taky si to myslím. Typový systém nahradit testy jde.
Nahraď mi prosím typy za testy u tohoto příkladu:
Kód: [Vybrat]
inc (x: Int) = x + 1Každopádně problém místních je v tom, že si nečtou argumenty. Takže za mě končím.
Testy se nedělají na jeden řádek kódu, ale na funkční celek, třeba funkci. Jak typem zkontroluješ, že jsi omylem nenapsal 2 místo 1?
třeba
Kód: [Vybrat]
inc :: Nat n -> Nat (S n)
Co je to za jazyk, není to srozumitelné? Dokáže to zajistit to, že hodnota tohoto typu v jedné funkci může být zvýšena právě o jedna, v jiné právě o dva a v třetí může být změněna v závislosti na jiné hodnotě jiného typu a tim zkontrolovat funkčnost funkce? Co v případě, že funkce vrací jiný typ, než je parametr. Je kontrola správnosti funkce součástí vstupního nebo výstupního typu?
haskell, viz výše, je to typ funkce, která inkrementuje přirozené číslo, pokud by měla dělat něco jiného, měla by jiný typ
Takze to je tohle? Tedy neco jako preddefinovany test?
Název: Re:Co si myslíte o OOP?
Přispěvatel: Sunar 08. 01. 2019, 22:20:12
Vypadl mi odkaz: http://hackage.haskell.org/package/vector-static-0.3.0.1/docs/src/Data-Nat.html
Název: Re:Co si myslíte o OOP?
Přispěvatel: Sunar 08. 01. 2019, 22:22:14
Taky si to myslím. Typový systém nahradit testy jde.
Nahraď mi prosím typy za testy u tohoto příkladu:
Kód: [Vybrat]
inc (x: Int) = x + 1Každopádně problém místních je v tom, že si nečtou argumenty. Takže za mě končím.
Testy se nedělají na jeden řádek kódu, ale na funkční celek, třeba funkci. Jak typem zkontroluješ, že jsi omylem nenapsal 2 místo 1?
inc je funkce.
Otázka nezní zda lze typem zcela nahradit testy, ale vaše opačné tvrzení, že typy lze nahradit testy.
Nečetl jsem poctivě celou diskusi, ale předpokládám, že takové tvrzení tu nezaznělo. Diskuse běží na téma potřebnosti statických typů k ověření bezchybnosti programu, nikoliv nahrazení typů.
Aha, tak to je nesmysl, i testy se opiraji o typovy system.
Název: Re:Co si myslíte o OOP?
Přispěvatel: Kit 08. 01. 2019, 22:29:17
Co je to za jazyk, není to srozumitelné? Dokáže to zajistit to, že hodnota tohoto typu v jedné funkci může být zvýšena právě o jedna, v jiné právě o dva a v třetí může být změněna v závislosti na jiné hodnotě jiného typu a tim zkontrolovat funkčnost funkce? Co v případě, že funkce vrací jiný typ, než je parametr. Je kontrola správnosti funkce součástí vstupního nebo výstupního typu?
haskell, viz výše, je to typ funkce, která inkrementuje přirozené číslo, pokud by měla dělat něco jiného, měla by jiný typ

Co takhle použít nějaký objektovější jazyk, třeba Scalu?
Název: Re:Co si myslíte o OOP?
Přispěvatel: BoneFlute 08. 01. 2019, 22:34:32
Aha, tak to je nesmysl, i testy se opiraji o typovy system.

Pokud bych tě mohl požádat; začal jsem tento svůj offtopic narážkou na tvrzení, že dynamické typování má nějakou zásadní výhodu proti statickému typování. Zajímalo by mě o jakou jde. Zatím zde žádný z příznivců to nebyl schopen srozumitelně vypíchnout.

Já, jako fanatik do statického typování uznávám dvě(tři) situace:
1. Erlang dokáže za chodu opravovat/upravovat kód. Někde jsem četl (ale možná je to kec), ž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. V Haskellu například všechno je přísně otypováno, jako kdyby to šlo na produkci. Což může být nepohodlné.
3. Jazyk, nebo člověk neumí typy a nechce se je učit.

Napadá tě něco?

Děkuji.
Název: Re:Co si myslíte o OOP?
Přispěvatel: v 08. 01. 2019, 22:51:03
Taky si to myslím. Typový systém nahradit testy jde.
Nahraď mi prosím typy za testy u tohoto příkladu:
Kód: [Vybrat]
inc (x: Int) = x + 1Každopádně problém místních je v tom, že si nečtou argumenty. Takže za mě končím.
Testy se nedělají na jeden řádek kódu, ale na funkční celek, třeba funkci. Jak typem zkontroluješ, že jsi omylem nenapsal 2 místo 1?
třeba
Kód: [Vybrat]
inc :: Nat n -> Nat (S n)
Co je to za jazyk, není to srozumitelné? Dokáže to zajistit to, že hodnota tohoto typu v jedné funkci může být zvýšena právě o jedna, v jiné právě o dva a v třetí může být změněna v závislosti na jiné hodnotě jiného typu a tim zkontrolovat funkčnost funkce? Co v případě, že funkce vrací jiný typ, než je parametr. Je kontrola správnosti funkce součástí vstupního nebo výstupního typu?
haskell, viz výše, je to typ funkce, která inkrementuje přirozené číslo, pokud by měla dělat něco jiného, měla by jiný typ
Takze to je tohle? Tedy neco jako preddefinovany test?
využití expresivního typového systému (GADT, zobecněné algebraické typy)
Název: Re:Co si myslíte o OOP?
Přispěvatel: v 08. 01. 2019, 23:03:53
Co je to za jazyk, není to srozumitelné? Dokáže to zajistit to, že hodnota tohoto typu v jedné funkci může být zvýšena právě o jedna, v jiné právě o dva a v třetí může být změněna v závislosti na jiné hodnotě jiného typu a tim zkontrolovat funkčnost funkce? Co v případě, že funkce vrací jiný typ, než je parametr. Je kontrola správnosti funkce součástí vstupního nebo výstupního typu?
haskell, viz výše, je to typ funkce, která inkrementuje přirozené číslo, pokud by měla dělat něco jiného, měla by jiný typ

Co takhle použít nějaký objektovější jazyk, třeba Scalu?
nijak mě to neláká
Název: Re:Co si myslíte o OOP?
Přispěvatel: Kit 08. 01. 2019, 23:47:06
Co je to za jazyk, není to srozumitelné? Dokáže to zajistit to, že hodnota tohoto typu v jedné funkci může být zvýšena právě o jedna, v jiné právě o dva a v třetí může být změněna v závislosti na jiné hodnotě jiného typu a tim zkontrolovat funkčnost funkce? Co v případě, že funkce vrací jiný typ, než je parametr. Je kontrola správnosti funkce součástí vstupního nebo výstupního typu?
haskell, viz výše, je to typ funkce, která inkrementuje přirozené číslo, pokud by měla dělat něco jiného, měla by jiný typ
Co takhle použít nějaký objektovější jazyk, třeba Scalu?
nijak mě to neláká

Tak nám aspoň přestaň vnucovat Haskell, který s OOP nesouvisí.
Název: Re:Co si myslíte o OOP?
Přispěvatel: A. F. 09. 01. 2019, 00:16:35
Tak nám aspoň přestaň vnucovat Haskell, který s OOP nesouvisí.

Proč? Mě to zajímá.
Název: Re:Co si myslíte o OOP?
Přispěvatel: BaldSlattery 09. 01. 2019, 00:22:32
Co je to za jazyk, není to srozumitelné? Dokáže to zajistit to, že hodnota tohoto typu v jedné funkci může být zvýšena právě o jedna, v jiné právě o dva a v třetí může být změněna v závislosti na jiné hodnotě jiného typu a tim zkontrolovat funkčnost funkce? Co v případě, že funkce vrací jiný typ, než je parametr. Je kontrola správnosti funkce součástí vstupního nebo výstupního typu?
haskell, viz výše, je to typ funkce, která inkrementuje přirozené číslo, pokud by měla dělat něco jiného, měla by jiný typ
Co takhle použít nějaký objektovější jazyk, třeba Scalu?
nijak mě to neláká

Tak nám aspoň přestaň vnucovat Haskell, který s OOP nesouvisí.
Furt lepší než PHP.
Název: Re:Co si myslíte o OOP?
Přispěvatel: operator 09. 01. 2019, 08:07:56
Tak jsem chtel overit tu haskell ukazku a zjistil, ze haskell je tak okrajovy jazyk, ze neni k dispozici v termuxu. Hledal jsem balicek s nazvem haskell nebo ghc. Seznam balicku: https://pastebin.com/kdfgUFRt To jen upevnuje me presvedceni, ze nema smysl ztracet cas okrajovymi nepodporovanymi jazyky.  Je schopen to nekdo predvest v jinem jazyku ktery je mezi balicky? (je tam kde co, rust, vala, erlang, java, ocaml, golang, clang, racket, ...)  Nebo se jedna ciste o schopnost haskellu, ktera je tu mylne prisuzovana jazykum se statickymi typy?
Název: Re:Co si myslíte o OOP?
Přispěvatel: Ondra Satai Nekola 09. 01. 2019, 08:45:44
Tak jsem chtel overit tu haskell ukazku a zjistil, ze haskell je tak okrajovy jazyk, ze neni k dispozici v termuxu. Hledal jsem balicek s nazvem haskell nebo ghc. Seznam balicku: https://pastebin.com/kdfgUFRt To jen upevnuje me presvedceni, ze nema smysl ztracet cas okrajovymi nepodporovanymi jazyky.  Je schopen to nekdo predvest v jinem jazyku ktery je mezi balicky? (je tam kde co, rust, vala, erlang, java, ocaml, golang, clang, racket, ...)  Nebo se jedna ciste o schopnost haskellu, ktera je tu mylne prisuzovana jazykum se statickymi typy?

To je tak pitomá metrika (přítomnost v termuxu) a tak pitomý argument (když je to v Haskellu a opírá se to o statické typy, tak to nutně je demonstrace výhod statických typů)...
Název: Re:Co si myslíte o OOP?
Přispěvatel: BaldSlattery 09. 01. 2019, 10:14:06
Taky si to myslím. Typový systém nahradit testy jde.
Nahraď mi prosím typy za testy u tohoto příkladu:
Kód: [Vybrat]
inc (x: Int) = x + 1Každopádně problém místních je v tom, že si nečtou argumenty. Takže za mě končím.
Testy se nedělají na jeden řádek kódu, ale na funkční celek, třeba funkci. Jak typem zkontroluješ, že jsi omylem nenapsal 2 místo 1?
třeba
Kód: [Vybrat]
inc :: Nat n -> Nat (S n)
To vypadá jako kruhová definice. Skutečně to odhalí chybu, když místo čísla 5 tam dám omylem číslo 7?
Máš něco proti kruhovým definicím?
Název: Re:Co si myslíte o OOP?
Přispěvatel: v 09. 01. 2019, 10:36:24
Tak nám aspoň přestaň vnucovat Haskell, který s OOP nesouvisí.
jestli je dynamické typování tak zásadní pro OOP jak tu mnozí tvrdí, pak je ukázka možností statického typování zcela relevantní
Název: Re:Co si myslíte o OOP?
Přispěvatel: Kit 09. 01. 2019, 10:51:56
Tak nám aspoň přestaň vnucovat Haskell, který s OOP nesouvisí.
jestli je dynamické typování tak zásadní pro OOP jak tu mnozí tvrdí, pak je ukázka možností statického typování zcela relevantní

Statické typování je pro OOP irelevantní.
Název: Re:Co si myslíte o OOP?
Přispěvatel: SB 09. 01. 2019, 11:06:58
Taky si to myslím. Typový systém nahradit testy jde.
Nahraď mi prosím typy za testy u tohoto příkladu:

Kód: [Vybrat]
inc (x: Int) = x + 1...

Pozor na to tykání!!!

V Pytónu:

Kód: [Vybrat]
def inc(x):
    if not isinstance(x, Int):
        raise Exception()
    ...

Když nad tím přemýšlím, tak musím uznat, že TYPOVÉ testy prováděné PŘI PŘEKLADU nahradit nejdou (běhové pochopitelně ano, vizte výše). Jestliže i naopak prakticky nejdou nahradit výpočetní testy typovými, pak už zůstává jen otázka, zda a kdy se vyplatí použít typový systém a kdy netypový. Osobně upřednostňuju ten volnější, netypový, ale to je na každém.
Název: Re:Co si myslíte o OOP?
Přispěvatel: JS 09. 01. 2019, 11:22:05
třeba
Kód: [Vybrat]
inc :: Nat n -> Nat (S n)

To vypadá jako kruhová definice. Skutečně to odhalí chybu, když místo čísla 5 tam dám omylem číslo 7?

To skutecne neodhali, ale to neodhali ani zadny test na inc.. Testem na funkce tezko otestujes, ze jsi pri volani te funkce zadal spravne parametry.
Název: Re:Co si myslíte o OOP?
Přispěvatel: Ondra Satai Nekola 09. 01. 2019, 11:25:59
Tak nám aspoň přestaň vnucovat Haskell, který s OOP nesouvisí.
jestli je dynamické typování tak zásadní pro OOP jak tu mnozí tvrdí, pak je ukázka možností statického typování zcela relevantní

Statické typování je pro OOP irelevantní.

Co se dovzdelat a zkusit se doucit trebas tu Scalu/F# nebo alespon Javu/C#?
Název: Re:Co si myslíte o OOP?
Přispěvatel: Kiwi 09. 01. 2019, 11:32:48
Tak nám aspoň přestaň vnucovat Haskell, který s OOP nesouvisí.
jestli je dynamické typování tak zásadní pro OOP jak tu mnozí tvrdí, pak je ukázka možností statického typování zcela relevantní

Statické typování je pro OOP irelevantní.

Co se dovzdelat a zkusit se doucit trebas tu Scalu/F# nebo alespon Javu/C#?
A jak souvisí Java/C# s OOP?
Název: Re:Co si myslíte o OOP?
Přispěvatel: Kit 09. 01. 2019, 11:37:36
třeba
Kód: [Vybrat]
inc :: Nat n -> Nat (S n)
To vypadá jako kruhová definice. Skutečně to odhalí chybu, když místo čísla 5 tam dám omylem číslo 7?
To skutecne neodhali, ale to neodhali ani zadny test na inc.. Testem na funkce tezko otestujes, ze jsi pri volani te funkce zadal spravne parametry.

Měl jsem na mysli tohle:
Kód: [Vybrat]
inc5 :: Nat n -> Nat (S n)
inc5 (x: Int) = x + 7

Jak to odhalí chybu? Chtěl jsem zvýšit o 5, ale místo toho se mi hodnota zvýší o 7.
Název: Re:Co si myslíte o OOP?
Přispěvatel: JS 09. 01. 2019, 11:46:55
Pozor na to tykání!!!

Hodne stesti!  :)

Citace
Když nad tím přemýšlím, tak musím uznat, že TYPOVÉ testy prováděné PŘI PŘEKLADU nahradit nejdou (běhové pochopitelně ano, vizte výše).

To samozrejme nejdou.

Citace
Jestliže i naopak prakticky nejdou nahradit výpočetní testy typovými

To samozrejme taky nejdou, kdybychom to umeli dokazat, nemuseli bychom to pocitat.

Citace
pak už zůstává jen otázka, zda a kdy se vyplatí použít typový systém a kdy netypový. Osobně upřednostňuju ten volnější, netypový, ale to je na každém.

Samozrejme odpoved je ten typovy, ten umoznuje oboji. Netypovy jen to druhe.
Název: Re:Co si myslíte o OOP?
Přispěvatel: SB 09. 01. 2019, 11:49:42
Nečetl jsem poctivě celou diskusi, ale předpokládám, že takové tvrzení tu nezaznělo. Diskuse běží na téma potřebnosti statických typů k ověření bezchybnosti programu, nikoliv nahrazení typů.
Aha, tak to je nesmysl, i testy se opiraji o typovy system.

Používají, ale neopírají (ve smyslu vyžadovat):

OOP (= bez primitiv):

Kód: [Vybrat]
GenČtverce = func(x) {
    return {
        _strana: x,
        strana: func() {return _strana},
        plocha: func() {return _strana^2}
    }

testČtverce = func() {
    assert (GenČtverce(5).plocha == 25)    # test identity
}


Ten svůj názor o nahraditelnosti typování jsem v předchozím příspěvku upravil.
Název: Re:Co si myslíte o OOP?
Přispěvatel: BaldSlattery 09. 01. 2019, 11:51:02
třeba
Kód: [Vybrat]
inc :: Nat n -> Nat (S n)
To vypadá jako kruhová definice. Skutečně to odhalí chybu, když místo čísla 5 tam dám omylem číslo 7?
To skutecne neodhali, ale to neodhali ani zadny test na inc.. Testem na funkce tezko otestujes, ze jsi pri volani te funkce zadal spravne parametry.

Měl jsem na mysli tohle:
Kód: [Vybrat]
inc5 :: Nat n -> Nat (S n)
inc5 (x: Int) = x + 7

Jak to odhalí chybu? Chtěl jsem zvýšit o 5, ale místo toho se mi hodnota zvýší o 7.
(S n) není o 5
Název: Re:Co si myslíte o OOP?
Přispěvatel: JS 09. 01. 2019, 11:53:21
Měl jsem na mysli tohle:
Kód: [Vybrat]
inc5 :: Nat n -> Nat (S n)
inc5 (x: Int) = x + 7

Jak to odhalí chybu? Chtěl jsem zvýšit o 5, ale místo toho se mi hodnota zvýší o 7.

Tohle odhali chybu hned - nezkompiluje se to. Protoze v typu stale rikas, ze chces zvysovat o 1. Neco jineho by bylo neco jako:

Kód: [Vybrat]
inc5 :: Nat n -> Nat (S (S (S (S (S n)))))
inc5 (x: Int) = x + 7

Uz jsme to tady pred casem rozebirali. Jisty si muzes byt jen tak, ze to napises dvakrat a porovnas. Testy a dostatecne silny typovy system jsou jen dve ruzne moznosti, jak se priblizit tomu "napsat to dvakrat". Oba na to jdou z jine strany, takze v tom priblizeni maji vyhody a nevyhody. Ale ciste teoreticky (v tom limitnim pripade) lze jedno zcela nahradit druhym, je to vec vkusu.
Název: Re:Co si myslíte o OOP?
Přispěvatel: SB 09. 01. 2019, 11:54:39

Nechtěl jste už končit?
Název: Re:Co si myslíte o OOP?
Přispěvatel: Ondra Satai Nekola 09. 01. 2019, 11:55:40
Tak nám aspoň přestaň vnucovat Haskell, který s OOP nesouvisí.
jestli je dynamické typování tak zásadní pro OOP jak tu mnozí tvrdí, pak je ukázka možností statického typování zcela relevantní

Statické typování je pro OOP irelevantní.

Co se dovzdelat a zkusit se doucit trebas tu Scalu/F# nebo alespon Javu/C#?
A jak souvisí Java/C# s OOP?

Aaaa, pan je fundamentalista ;)
Název: Re:Co si myslíte o OOP?
Přispěvatel: SB 09. 01. 2019, 11:55:53
Tak nám aspoň přestaň vnucovat Haskell, který s OOP nesouvisí.

Proč? Mě to zajímá.

Přečtěte si téma vlákna.
Název: Re:Co si myslíte o OOP?
Přispěvatel: SB 09. 01. 2019, 12:03:03
Citace
pak už zůstává jen otázka, zda a kdy se vyplatí použít typový systém a kdy netypový. Osobně upřednostňuju ten volnější, netypový, ale to je na každém.

Samozrejme odpoved je ten typovy, ten umoznuje oboji. Netypovy jen to druhe.

Supr. Teď ještě napište, co je "oboji" a "druhe", aby to začalo dávat smysl.
Název: Re:Co si myslíte o OOP?
Přispěvatel: Kit 09. 01. 2019, 12:13:43
třeba
Kód: [Vybrat]
inc :: Nat n -> Nat (S n)
To vypadá jako kruhová definice. Skutečně to odhalí chybu, když místo čísla 5 tam dám omylem číslo 7?
To skutecne neodhali, ale to neodhali ani zadny test na inc.. Testem na funkce tezko otestujes, ze jsi pri volani te funkce zadal spravne parametry.

Měl jsem na mysli tohle:
Kód: [Vybrat]
inc5 :: Nat n -> Nat (S n)
inc5 (x: Int) = x + 7

Jak to odhalí chybu? Chtěl jsem zvýšit o 5, ale místo toho se mi hodnota zvýší o 7.
(S n) není o 5

Funkce inc5 má zvýšit hodnotu o 5. Tak tam dej něco jiného než (S n), aby to fungovalo.
Název: Re:Co si myslíte o OOP?
Přispěvatel: operator 09. 01. 2019, 12:23:10
Tak jsem chtel overit tu haskell ukazku a zjistil, ze haskell je tak okrajovy jazyk, ze neni k dispozici v termuxu. Hledal jsem balicek s nazvem haskell nebo ghc. Seznam balicku: https://pastebin.com/kdfgUFRt To jen upevnuje me presvedceni, ze nema smysl ztracet cas okrajovymi nepodporovanymi jazyky.  Je schopen to nekdo predvest v jinem jazyku ktery je mezi balicky? (je tam kde co, rust, vala, erlang, java, ocaml, golang, clang, racket, ...)  Nebo se jedna ciste o schopnost haskellu, ktera je tu mylne prisuzovana jazykum se statickymi typy?
To je tak pitomá metrika (přítomnost v termuxu) a tak pitomý argument (když je to v Haskellu a opírá se to o statické typy, tak to nutně je demonstrace výhod statických typů)...
To neni metrika, proste si to nemam kde zkusit a z toho plyne muj osobni nezajem.

Neni to demonstrace vyhod statickych typu, pokud je haskell jediny jazyk, ktery to umi. V takovem pripade je to demonstrace vyhoda haskellu. Na tom zalozene tvrzeni o statickych typech je argumentacni klam, predcasna generalizace.

Srovnej. Implicitni pretypovani v jazyce C se take opira o staticke typy a prameni z toho nestabilita a chybovost programu napsanych v C. Je tedy nestabilitu a chybovost programu mozno oznacit za nevyhodu statickych typu? Nebo je to vlastnost jazyka, nikoliv statickych typu? 

Pokud se chceme bavit o vyhodach statickych typu, musite najit vlastnosti, ktere jsou spolecne jazykum se statickymi vlastnostmi a chybi jazykum s dynamickymi typy. Obavam se, ze krom vykonove optimalizace zadnou vyhodu statickych typu nikdo nenalezne. Ony i dynamicke jazyky mohou mit silny typovy system, viz treba Julia. Rada vlastnosti tady pripisovana statickym typum pak neni cizi ani nekterym dynamickym jazykum. Viz například zde oblíbené tvrzení o refaktoringu, přičemž jehož původ je v dynamickém smalltalku.
Název: Re:Co si myslíte o OOP?
Přispěvatel: operator 09. 01. 2019, 12:25:18
Taky si to myslím. Typový systém nahradit testy jde.
Nahraď mi prosím typy za testy u tohoto příkladu:

Kód: [Vybrat]
inc (x: Int) = x + 1...

Pozor na to tykání!!!

V Pytónu:

Kód: [Vybrat]
def inc(x):
    if not isinstance(x, Int):
        raise Exception()
    ...

Když nad tím přemýšlím, tak musím uznat, že TYPOVÉ testy prováděné PŘI PŘEKLADU nahradit nejdou (běhové pochopitelně ano, vizte výše). Jestliže i naopak prakticky nejdou nahradit výpočetní testy typovými, pak už zůstává jen otázka, zda a kdy se vyplatí použít typový systém a kdy netypový. Osobně upřednostňuju ten volnější, netypový, ale to je na každém.
Nahradit jdou a to typingem.
Název: Re:Co si myslíte o OOP?
Přispěvatel: Ondra Satai Nekola 09. 01. 2019, 12:30:27
Tak jsem chtel overit tu haskell ukazku a zjistil, ze haskell je tak okrajovy jazyk, ze neni k dispozici v termuxu. Hledal jsem balicek s nazvem haskell nebo ghc. Seznam balicku: https://pastebin.com/kdfgUFRt To jen upevnuje me presvedceni, ze nema smysl ztracet cas okrajovymi nepodporovanymi jazyky.  Je schopen to nekdo predvest v jinem jazyku ktery je mezi balicky? (je tam kde co, rust, vala, erlang, java, ocaml, golang, clang, racket, ...)  Nebo se jedna ciste o schopnost haskellu, ktera je tu mylne prisuzovana jazykum se statickymi typy?
To je tak pitomá metrika (přítomnost v termuxu) a tak pitomý argument (když je to v Haskellu a opírá se to o statické typy, tak to nutně je demonstrace výhod statických typů)...
To neni metrika, proste si to nemam kde zkusit a z toho plyne muj osobni nezajem.

Ty nemas pocitac? :-O
Kazdopadne jsou i REPLy online. A cele IDE online byvalo taky.
Název: Re:Co si myslíte o OOP?
Přispěvatel: Ondra Satai Nekola 09. 01. 2019, 12:32:01
Tak jsem chtel overit tu haskell ukazku a zjistil, ze haskell je tak okrajovy jazyk, ze neni k dispozici v termuxu. Hledal jsem balicek s nazvem haskell nebo ghc. Seznam balicku: https://pastebin.com/kdfgUFRt To jen upevnuje me presvedceni, ze nema smysl ztracet cas okrajovymi nepodporovanymi jazyky.  Je schopen to nekdo predvest v jinem jazyku ktery je mezi balicky? (je tam kde co, rust, vala, erlang, java, ocaml, golang, clang, racket, ...)  Nebo se jedna ciste o schopnost haskellu, ktera je tu mylne prisuzovana jazykum se statickymi typy?
To je tak pitomá metrika (přítomnost v termuxu) a tak pitomý argument (když je to v Haskellu a opírá se to o statické typy, tak to nutně je demonstrace výhod statických typů)...
Neni to demonstrace vyhod statickych typu, pokud je haskell jediny jazyk, ktery to umi. V takovem pripade je to demonstrace vyhoda haskellu. Na tom zalozene tvrzeni o statickych typech je argumentacni klam, predcasna generalizace.

Ale houby, umi to s drobnymi rozdily kopec jazyku (o Scale a F# tu uz rec sla), ten Haskell se proste bere jako "zlaty standard", co ho navic pomalu kazdy zna.
Název: Re:Co si myslíte o OOP?
Přispěvatel: Ondra Satai Nekola 09. 01. 2019, 12:33:30
Tak jsem chtel overit tu haskell ukazku a zjistil, ze haskell je tak okrajovy jazyk, ze neni k dispozici v termuxu. Hledal jsem balicek s nazvem haskell nebo ghc. Seznam balicku: https://pastebin.com/kdfgUFRt To jen upevnuje me presvedceni, ze nema smysl ztracet cas okrajovymi nepodporovanymi jazyky.  Je schopen to nekdo predvest v jinem jazyku ktery je mezi balicky? (je tam kde co, rust, vala, erlang, java, ocaml, golang, clang, racket, ...)  Nebo se jedna ciste o schopnost haskellu, ktera je tu mylne prisuzovana jazykum se statickymi typy?
To je tak pitomá metrika (přítomnost v termuxu) a tak pitomý argument (když je to v Haskellu a opírá se to o statické typy, tak to nutně je demonstrace výhod statických typů)...

Srovnej. Implicitni pretypovani v jazyce C se take opira o staticke typy a prameni z toho nestabilita a chybovost programu napsanych v C. Je tedy nestabilitu a chybovost programu mozno oznacit za nevyhodu statickych typu? Nebo je to vlastnost jazyka, nikoliv statickych typu? 


Timhle muzes ukazat na Hindenburg a odstrelit tim myslenku na letani...

Dulezite je, ze reseni existuje a neco prinasi. A bez statickeho typovani ti fungovat nebude.
Název: Re:Co si myslíte o OOP?
Přispěvatel: operator 09. 01. 2019, 13:32:12
Tak jsem chtel overit tu haskell ukazku a zjistil, ze haskell je tak okrajovy jazyk, ze neni k dispozici v termuxu. Hledal jsem balicek s nazvem haskell nebo ghc. Seznam balicku: https://pastebin.com/kdfgUFRt To jen upevnuje me presvedceni, ze nema smysl ztracet cas okrajovymi nepodporovanymi jazyky.  Je schopen to nekdo predvest v jinem jazyku ktery je mezi balicky? (je tam kde co, rust, vala, erlang, java, ocaml, golang, clang, racket, ...)  Nebo se jedna ciste o schopnost haskellu, ktera je tu mylne prisuzovana jazykum se statickymi typy?
To je tak pitomá metrika (přítomnost v termuxu) a tak pitomý argument (když je to v Haskellu a opírá se to o statické typy, tak to nutně je demonstrace výhod statických typů)...
To neni metrika, proste si to nemam kde zkusit a z toho plyne muj osobni nezajem.
Ty nemas pocitac? :-O
Kazdopadne jsou i REPLy online. A cele IDE online byvalo taky.
Zadny kam bych mohl instalovat cizi software. Online mohu zkusit.
Název: Re:Co si myslíte o OOP?
Přispěvatel: operator 09. 01. 2019, 13:33:53
Tak jsem chtel overit tu haskell ukazku a zjistil, ze haskell je tak okrajovy jazyk, ze neni k dispozici v termuxu. Hledal jsem balicek s nazvem haskell nebo ghc. Seznam balicku: https://pastebin.com/kdfgUFRt To jen upevnuje me presvedceni, ze nema smysl ztracet cas okrajovymi nepodporovanymi jazyky.  Je schopen to nekdo predvest v jinem jazyku ktery je mezi balicky? (je tam kde co, rust, vala, erlang, java, ocaml, golang, clang, racket, ...)  Nebo se jedna ciste o schopnost haskellu, ktera je tu mylne prisuzovana jazykum se statickymi typy?
To je tak pitomá metrika (přítomnost v termuxu) a tak pitomý argument (když je to v Haskellu a opírá se to o statické typy, tak to nutně je demonstrace výhod statických typů)...
Neni to demonstrace vyhod statickych typu, pokud je haskell jediny jazyk, ktery to umi. V takovem pripade je to demonstrace vyhoda haskellu. Na tom zalozene tvrzeni o statickych typech je argumentacni klam, predcasna generalizace.
Ale houby, umi to s drobnymi rozdily kopec jazyku (o Scale a F# tu uz rec sla), ten Haskell se proste bere jako "zlaty standard", co ho navic pomalu kazdy zna.
Zatim to spis vypada na vlastnost funkcionalnich jazyku, porad cekam na nejaky normalni. :-)
Název: Re:Co si myslíte o OOP?
Přispěvatel: Kit 09. 01. 2019, 13:35:48
Srovnej. Implicitni pretypovani v jazyce C se take opira o staticke typy a prameni z toho nestabilita a chybovost programu napsanych v C. Je tedy nestabilitu a chybovost programu mozno oznacit za nevyhodu statickych typu? Nebo je to vlastnost jazyka, nikoliv statickych typu? 
Timhle muzes ukazat na Hindenburg a odstrelit tim myslenku na letani...

Dulezite je, ze reseni existuje a neco prinasi. A bez statickeho typovani ti fungovat nebude.

Funguje to i bez statického typování, které může nahradit některé typy testů a přinést i něco navíc. Proto se dnes používají oba přístupy, které jsou vzájemně do jisté míry zastupitelné.

Kritika byla mířena proti jazyku C, kterému ani statické typování nepomáhá ke stabilitě aplikaci.
Název: Re:Co si myslíte o OOP?
Přispěvatel: operator 09. 01. 2019, 13:38:39
Tak jsem chtel overit tu haskell ukazku a zjistil, ze haskell je tak okrajovy jazyk, ze neni k dispozici v termuxu. Hledal jsem balicek s nazvem haskell nebo ghc. Seznam balicku: https://pastebin.com/kdfgUFRt To jen upevnuje me presvedceni, ze nema smysl ztracet cas okrajovymi nepodporovanymi jazyky.  Je schopen to nekdo predvest v jinem jazyku ktery je mezi balicky? (je tam kde co, rust, vala, erlang, java, ocaml, golang, clang, racket, ...)  Nebo se jedna ciste o schopnost haskellu, ktera je tu mylne prisuzovana jazykum se statickymi typy?
To je tak pitomá metrika (přítomnost v termuxu) a tak pitomý argument (když je to v Haskellu a opírá se to o statické typy, tak to nutně je demonstrace výhod statických typů)...

Srovnej. Implicitni pretypovani v jazyce C se take opira o staticke typy a prameni z toho nestabilita a chybovost programu napsanych v C. Je tedy nestabilitu a chybovost programu mozno oznacit za nevyhodu statickych typu? Nebo je to vlastnost jazyka, nikoliv statickych typu? 
Timhle muzes ukazat na Hindenburg a odstrelit tim myslenku na letani...
Dulezite je, ze reseni existuje a neco prinasi. A bez statickeho typovani ti fungovat nebude.
Dukaz pro toto tvrzeni?
Co se tyce Hindenburgu, nemas pravdu, ze to odstreli myslenku na letani. Stejne jako staticke typy neodstrali myslenku na programovani. Naopak to byl impulz pro vynalezani lepsiho letani, stroju tezsi nez vzduch.
Název: Re:Co si myslíte o OOP?
Přispěvatel: Ondra Satai Nekola 09. 01. 2019, 13:43:24
Tak jsem chtel overit tu haskell ukazku a zjistil, ze haskell je tak okrajovy jazyk, ze neni k dispozici v termuxu. Hledal jsem balicek s nazvem haskell nebo ghc. Seznam balicku: https://pastebin.com/kdfgUFRt To jen upevnuje me presvedceni, ze nema smysl ztracet cas okrajovymi nepodporovanymi jazyky.  Je schopen to nekdo predvest v jinem jazyku ktery je mezi balicky? (je tam kde co, rust, vala, erlang, java, ocaml, golang, clang, racket, ...)  Nebo se jedna ciste o schopnost haskellu, ktera je tu mylne prisuzovana jazykum se statickymi typy?
To je tak pitomá metrika (přítomnost v termuxu) a tak pitomý argument (když je to v Haskellu a opírá se to o statické typy, tak to nutně je demonstrace výhod statických typů)...
Neni to demonstrace vyhod statickych typu, pokud je haskell jediny jazyk, ktery to umi. V takovem pripade je to demonstrace vyhoda haskellu. Na tom zalozene tvrzeni o statickych typech je argumentacni klam, predcasna generalizace.
Ale houby, umi to s drobnymi rozdily kopec jazyku (o Scale a F# tu uz rec sla), ten Haskell se proste bere jako "zlaty standard", co ho navic pomalu kazdy zna.
Zatim to spis vypada na vlastnost funkcionalnich jazyku, porad cekam na nejaky normalni. :-)

Normální? Oba jsou to multiparadigmatické jazyky.
Název: Re:Co si myslíte o OOP?
Přispěvatel: operator 09. 01. 2019, 13:45:12
Ja si mezitim dovolim predvest moznost typove kontroly u dynamickeho jazyka.
Kód: [Vybrat]
~ $ mypy typehint.py
typehint.py:6: error: Argument 1 to "inc" has incompatible type "str"; expected "int"
~ $ cat typehint.py
def inc(x:int)->int:
    return x+1

if  __name__ == '__main__':
    print(inc(3))
    print(inc('4'))
~ $ mypy typehint.py
typehint.py:6: error: Argument 1 to "inc" has incompatible type "str"; expected "int"
Název: Re:Co si myslíte o OOP?
Přispěvatel: operator 09. 01. 2019, 13:48:48
Tak jsem chtel overit tu haskell ukazku a zjistil, ze haskell je tak okrajovy jazyk, ze neni k dispozici v termuxu. Hledal jsem balicek s nazvem haskell nebo ghc. Seznam balicku: https://pastebin.com/kdfgUFRt To jen upevnuje me presvedceni, ze nema smysl ztracet cas okrajovymi nepodporovanymi jazyky.  Je schopen to nekdo predvest v jinem jazyku ktery je mezi balicky? (je tam kde co, rust, vala, erlang, java, ocaml, golang, clang, racket, ...)  Nebo se jedna ciste o schopnost haskellu, ktera je tu mylne prisuzovana jazykum se statickymi typy?
To je tak pitomá metrika (přítomnost v termuxu) a tak pitomý argument (když je to v Haskellu a opírá se to o statické typy, tak to nutně je demonstrace výhod statických typů)...
Neni to demonstrace vyhod statickych typu, pokud je haskell jediny jazyk, ktery to umi. V takovem pripade je to demonstrace vyhoda haskellu. Na tom zalozene tvrzeni o statickych typech je argumentacni klam, predcasna generalizace.
Ale houby, umi to s drobnymi rozdily kopec jazyku (o Scale a F# tu uz rec sla), ten Haskell se proste bere jako "zlaty standard", co ho navic pomalu kazdy zna.
Zatim to spis vypada na vlastnost funkcionalnich jazyku, porad cekam na nejaky normalni. :-)
Normální? Oba jsou to multiparadigmatické jazyky.
Normalni, to jest ty, ktere se bezne pouzivaji v komercni praxi.
Název: Re:Co si myslíte o OOP?
Přispěvatel: Ondra Satai Nekola 09. 01. 2019, 13:49:23
Tak jsem chtel overit tu haskell ukazku a zjistil, ze haskell je tak okrajovy jazyk, ze neni k dispozici v termuxu. Hledal jsem balicek s nazvem haskell nebo ghc. Seznam balicku: https://pastebin.com/kdfgUFRt To jen upevnuje me presvedceni, ze nema smysl ztracet cas okrajovymi nepodporovanymi jazyky.  Je schopen to nekdo predvest v jinem jazyku ktery je mezi balicky? (je tam kde co, rust, vala, erlang, java, ocaml, golang, clang, racket, ...)  Nebo se jedna ciste o schopnost haskellu, ktera je tu mylne prisuzovana jazykum se statickymi typy?
To je tak pitomá metrika (přítomnost v termuxu) a tak pitomý argument (když je to v Haskellu a opírá se to o statické typy, tak to nutně je demonstrace výhod statických typů)...
To neni metrika, proste si to nemam kde zkusit a z toho plyne muj osobni nezajem.
Ty nemas pocitac? :-O
Kazdopadne jsou i REPLy online. A cele IDE online byvalo taky.
Zadny kam bych mohl instalovat cizi software. Online mohu zkusit.

...nebo si třeba koupit počítač? Pro programátora je to celkem užitečné vybavení.
Název: Re:Co si myslíte o OOP?
Přispěvatel: Ondra Satai Nekola 09. 01. 2019, 13:49:48
Tak jsem chtel overit tu haskell ukazku a zjistil, ze haskell je tak okrajovy jazyk, ze neni k dispozici v termuxu. Hledal jsem balicek s nazvem haskell nebo ghc. Seznam balicku: https://pastebin.com/kdfgUFRt To jen upevnuje me presvedceni, ze nema smysl ztracet cas okrajovymi nepodporovanymi jazyky.  Je schopen to nekdo predvest v jinem jazyku ktery je mezi balicky? (je tam kde co, rust, vala, erlang, java, ocaml, golang, clang, racket, ...)  Nebo se jedna ciste o schopnost haskellu, ktera je tu mylne prisuzovana jazykum se statickymi typy?
To je tak pitomá metrika (přítomnost v termuxu) a tak pitomý argument (když je to v Haskellu a opírá se to o statické typy, tak to nutně je demonstrace výhod statických typů)...
Neni to demonstrace vyhod statickych typu, pokud je haskell jediny jazyk, ktery to umi. V takovem pripade je to demonstrace vyhoda haskellu. Na tom zalozene tvrzeni o statickych typech je argumentacni klam, predcasna generalizace.
Ale houby, umi to s drobnymi rozdily kopec jazyku (o Scale a F# tu uz rec sla), ten Haskell se proste bere jako "zlaty standard", co ho navic pomalu kazdy zna.
Zatim to spis vypada na vlastnost funkcionalnich jazyku, porad cekam na nejaky normalni. :-)
Normální? Oba jsou to multiparadigmatické jazyky.
Normalni, to jest ty, ktere se bezne pouzivaji v komercni praxi.

Tak to jsou normální.
Název: Re:Co si myslíte o OOP?
Přispěvatel: BaldSlattery 09. 01. 2019, 13:58:53
Ja si mezitim dovolim predvest moznost typove kontroly u dynamickeho jazyka.
Kód: [Vybrat]
~ $ mypy typehint.py
typehint.py:6: error: Argument 1 to "inc" has incompatible type "str"; expected "int"
~ $ cat typehint.py
def inc(x:int)->int:
    return x+1

if  __name__ == '__main__':
    print(inc(3))
    print(inc('4'))
~ $ mypy typehint.py
typehint.py:6: error: Argument 1 to "inc" has incompatible type "str"; expected "int"
No vida, už jsi prozřel.
Název: Re:Co si myslíte o OOP?
Přispěvatel: lopatka 09. 01. 2019, 14:28:54
Počas behu programu neviete, resp. nemáte istotu, čo dostanete na vstupe. Jediný rozdiel je, že pri hodnote nesprávneho typu staticky typovaný spadne, dynamicky typovaný zas môže pokračovať, ale najskôr nekorektne.

Ani jedno, ani druhé však nie je riešenie, ani pád, ani nesprávne fungovanie. A tak si v oboch prípadoch musíte sami, "manuálne" overovať typ.

Preto kde je tá ohromná výhoda statických typov? Že sa neuklepnem v development time? Veď to sa nemusím ani s dynamickým. A unit testy musím písať tak či onak.

Takže so staticky typovaným jazykom asi budem vyvíjať o niečo pohodlnejšie, ale ak viem čo robím, ani s dynamickým typovaným to nebude žiadna tragédia. Hlavne nevidím nič pravdy na tom, že sú staticky typované jazyky principiálne lepšie od dynamických.

A krátkozraké vyjadrenia od zjavných amatérov bez praxe, typu: "so staticky typovaným jazykom ani unit testy nie sú potrebné", to je úplný nonsens - ktokoľvek s praxou na čomkoľvek väčšom vie, že bez testov sa v tíme zaobísť nedá, že to by bolo veľmi tragické rozhodnutie.

Takže o čom to tu vlastne točíte? O tomto, že staticky typované jazyky sú lepšie? Iste, väčšinou sa s nimi bude robiť o niečo lepšie. Ale že dynamicky typované sú zlé, resp. úplne nefunkčné? Ani náhodou.

To je celé. Oboje nakrásne funguje. A že nejde s dynamicky typovaným jazykom dosiahnuť presne to isté, ako so staticky? Jasne. Len sa tu strápňujete, keď sa to silou mocou snažíte zrovnávať. Veď ani staticky typovaným nedosiahnete presne to isté, ako s dynamickým. No a? Veď to je pointa. Ale vy tu napriek tomu miešate hrušky s jablkami - dynamické so statickými, funkcionálny s oop prístupom a hádate sa o naprostých zbytočnostiach.

A prax - je fajn, že vieš Smalltalk, ale nemáš zamestnanie, lebo na minoritné jazyky v praxi sere pes. Ani s Go, ani s Rust dieru do sveta neurobíš a v ponukách si nemáš šancu vyberať. Nadávať na Java/PHP/JS je možno v móde, ale nezamestnanými, keďže pracovné ponuky sú hlavne o nich, o tých škaredých, nefunkčných, lopatám a bastličom určených jazykoch. A radšej zazobaná lopata, ako nezamestnaný "akademik na roote".
Název: Re:Co si myslíte o OOP?
Přispěvatel: Kit 09. 01. 2019, 15:02:20
Měl jsem na mysli tohle:
Kód: [Vybrat]
inc5 :: Nat n -> Nat (S n)
inc5 (x: Int) = x + 7

Jak to odhalí chybu? Chtěl jsem zvýšit o 5, ale místo toho se mi hodnota zvýší o 7.

Tohle odhali chybu hned - nezkompiluje se to. Protoze v typu stale rikas, ze chces zvysovat o 1. Neco jineho by bylo neco jako:

Kód: [Vybrat]
inc5 :: Nat n -> Nat (S (S (S (S (S n)))))
inc5 (x: Int) = x + 7

Uz jsme to tady pred casem rozebirali. Jisty si muzes byt jen tak, ze to napises dvakrat a porovnas. Testy a dostatecne silny typovy system jsou jen dve ruzne moznosti, jak se priblizit tomu "napsat to dvakrat". Oba na to jdou z jine strany, takze v tom priblizeni maji vyhody a nevyhody. Ale ciste teoreticky (v tom limitnim pripade) lze jedno zcela nahradit druhym, je to vec vkusu.

Aha, takže úplně stejně to udělám, když budu chtít napsat funkci inc4096, která zvýší hodnotu o 4096?
Název: Re:Co si myslíte o OOP?
Přispěvatel: Kit 09. 01. 2019, 15:20:48
Ja si mezitim dovolim predvest moznost typove kontroly u dynamickeho jazyka.
Kód: [Vybrat]
~ $ mypy typehint.py
typehint.py:6: error: Argument 1 to "inc" has incompatible type "str"; expected "int"
~ $ cat typehint.py
def inc(x:int)->int:
    return x+1

if  __name__ == '__main__':
    print(inc(3))
    print(inc('4'))
~ $ mypy typehint.py
typehint.py:6: error: Argument 1 to "inc" has incompatible type "str"; expected "int"

Ono to funguje i bez explicitní deklarace typů:
Kód: [Vybrat]
def inc(x):
    return 1 + x

if __name__ == "__main__":
    print(inc(3))
    print(inc('4'))
Kód: [Vybrat]
4
Traceback (most recent call last):
  File "inc.py", line 9, in <module>
    print(inc('4'))
  File "inc.py", line 5, in inc
    return 1 + x
TypeError: unsupported operand type(s) for +: 'int' and 'str'
Název: Re:Co si myslíte o OOP?
Přispěvatel: ivoszz 09. 01. 2019, 15:41:22
Timhle muzes ukazat na Hindenburg a odstrelit tim myslenku na letani...
Dulezite je, ze reseni existuje a neco prinasi. A bez statickeho typovani ti fungovat nebude.
Dukaz pro toto tvrzeni?
Co se tyce Hindenburgu, nemas pravdu, ze to odstreli myslenku na letani. Stejne jako staticke typy neodstrali myslenku na programovani. Naopak to byl impulz pro vynalezani lepsiho letani, stroju tezsi nez vzduch.
To nemyslíš vážně s tím impulzem pro vynalézáním lepšího létání, že ne? Ta tragédie se stala v roce 1937. V té době už takové impulsy nebyly potřeba. Vzducholodě byly a kupodivu stále jsou (nyní zažívají určitou renesanci) poměrně okrajovou a velice speciální záležitostí, určenou pro specifické účely.
Název: Re:Co si myslíte o OOP?
Přispěvatel: JS 09. 01. 2019, 15:55:43
Aha, takže úplně stejně to udělám, když budu chtít napsat funkci inc4096, která zvýší hodnotu o 4096?

V podstate jo, akorat pouzijes silnejsi typovy system, kde se to "funkce zvysuje o 4096" zapise v typech rovnou s konstantou 4096.

Neni to pak (co do psani) odlisne od toho, mit test, ktery overi, jestli je vystup skutecne o 4096 vyssi nez vstup.

Nicmene zatimco to prvni to donuti typechecker overit pro vsechny pripady, to druhe overi jen nektere situace. Nevyhodou prvniho pristupu ovsem je, ze nekdy to ten typechecker taky dokazat nemusi umet.
Název: Re:Co si myslíte o OOP?
Přispěvatel: JS 09. 01. 2019, 16:00:27
Takže o čom to tu vlastne točíte? O tomto, že staticky typované jazyky sú lepšie? Iste, väčšinou sa s nimi bude robiť o niečo lepšie. Ale že dynamicky typované sú zlé, resp. úplne nefunkčné? Ani náhodou.

Myslim, ze slo o tu prvni otazku, a nikoli o tu druhou. Skoro nikdo tu netvrdil to druhe.
Název: Re:Co si myslíte o OOP?
Přispěvatel: v 09. 01. 2019, 16:04:36
Aha, takže úplně stejně to udělám, když budu chtít napsat funkci inc4096, která zvýší hodnotu o 4096?

V podstate jo, akorat pouzijes silnejsi typovy system, kde se to "funkce zvysuje o 4096" zapise v typech rovnou s konstantou 4096.

Neni to pak (co do psani) odlisne od toho, mit test, ktery overi, jestli je vystup skutecne o 4096 vyssi nez vstup.
nebo se přidá pár type families a napíše se třeba
Kód: [Vybrat]
Nat' n -> Nat' (Plus (Exp (S (S Z)) (S (S (S (S (S (S (S (S (S (S (S (S Z))))))))))))) n)hnus, ale taky úplně umělý příklad
Název: Re:Co si myslíte o OOP?
Přispěvatel: Kit 09. 01. 2019, 16:16:23
Aha, takže úplně stejně to udělám, když budu chtít napsat funkci inc4096, která zvýší hodnotu o 4096?
V podstate jo, akorat pouzijes silnejsi typovy system, kde se to "funkce zvysuje o 4096" zapise v typech rovnou s konstantou 4096.

Neni to pak (co do psani) odlisne od toho, mit test, ktery overi, jestli je vystup skutecne o 4096 vyssi nez vstup.
nebo se přidá pár type families a napíše se třeba
Kód: [Vybrat]
Nat' n -> Nat' (Plus (Exp (S (S Z)) (S (S (S (S (S (S (S (S (S (S (S (S Z))))))))))))) n)hnus, ale taky úplně umělý příklad

A co třeba kdybych chtěl funkci inc1234567, která bude přidávat 1234567? To budu zase vymýšlet podobnou bejkárnu?
Název: Re:Co si myslíte o OOP?
Přispěvatel: v 09. 01. 2019, 16:17:55
Aha, takže úplně stejně to udělám, když budu chtít napsat funkci inc4096, která zvýší hodnotu o 4096?
V podstate jo, akorat pouzijes silnejsi typovy system, kde se to "funkce zvysuje o 4096" zapise v typech rovnou s konstantou 4096.

Neni to pak (co do psani) odlisne od toho, mit test, ktery overi, jestli je vystup skutecne o 4096 vyssi nez vstup.
nebo se přidá pár type families a napíše se třeba
Kód: [Vybrat]
Nat' n -> Nat' (Plus (Exp (S (S Z)) (S (S (S (S (S (S (S (S (S (S (S (S Z))))))))))))) n)hnus, ale taky úplně umělý příklad

A co třeba kdybych chtěl funkci inc1234567, která bude přidávat 1234567? To budu zase vymýšlet podobnou bejkárnu?
jestli potřebujete funkci inc1234567 tak dobře vám tak
Název: Re:Co si myslíte o OOP?
Přispěvatel: lopatka 09. 01. 2019, 17:03:30
Takže o čom to tu vlastne točíte? O tomto, že staticky typované jazyky sú lepšie? Iste, väčšinou sa s nimi bude robiť o niečo lepšie. Ale že dynamicky typované sú zlé, resp. úplne nefunkčné? Ani náhodou.

Myslim, ze slo o tu prvni otazku, a nikoli o tu druhou. Skoro nikdo tu netvrdil to druhe.

Skoro nikto, ale niekto predsa. Navyše, otázka znie "čo si myslíte o oop". Až to tu skôr "skoro nikto" nerieši, miesto toho je tu ďalší flame ako ide s dynamicky typovaným jazykom dosiahnuť to isté, ako so staticky typovaným. Čo je v samom princípe nezmysel a zbytočnosť, nejde proste s dynamicky typovaným dosiahnuť navlas to isté, čo so staticky typovaným. A ani naopak, to isté so staticky, ako s dynamickým. A že tu našli nejaké podobnosti? No iste, a naprosto očakávane, to však ani len nemá zmysel riešiť.

Proste debata s niekoľko sto príspevkami a drvivá väčšina odveci, s nulovou praktickou hodnotou. Proste super...
Název: Re:Co si myslíte o OOP?
Přispěvatel: operator 09. 01. 2019, 18:54:31
Timhle muzes ukazat na Hindenburg a odstrelit tim myslenku na letani...
Dulezite je, ze reseni existuje a neco prinasi. A bez statickeho typovani ti fungovat nebude.
Dukaz pro toto tvrzeni?
Co se tyce Hindenburgu, nemas pravdu, ze to odstreli myslenku na letani. Stejne jako staticke typy neodstrali myslenku na programovani. Naopak to byl impulz pro vynalezani lepsiho letani, stroju tezsi nez vzduch.
To nemyslíš vážně s tím impulzem pro vynalézáním lepšího létání, že ne? Ta tragédie se stala v roce 1937. V té době už takové impulsy nebyly potřeba. Vzducholodě byly a kupodivu stále jsou (nyní zažívají určitou renesanci) poměrně okrajovou a velice speciální záležitostí, určenou pro specifické účely.
Už před nehodou Hindenburgu došlo k řadě nehod vzducholodí, většinou způsobených špatným počasím. Žádná vážnější nehoda se však netýkala Zeppelinů, ty držely pozoruhodný rekord v bezpečnosti letecké dopravy; např. Graf Zeppelin bezpečně nalétal více než 1,6 miliónu kilometrů, mj. i první úplný oblet zeměkoule a dopravila 12000 pasažérů. Firma Zeppelin hrdě zdůrazňovala, že na jejích vzducholodích se nikdy nezranil jediný pasažér.

Katastrofa Hindenburgu to zcela změnila. Efektní filmové záběry a vzrušený rozhlasový komentář přímo z místa neštěstí zcela zničily důvěru veřejnosti ve vzducholodě. Taková negativní publicita znamenala konec Zeppelinů a dopravy prostřednictvím ohromných vzducholodí vůbec. Sesterský stroj Hindenburgu Graf Zeppelin II létal ještě dva roky na výzvědné a propagační lety, ale to už byla jen labutí píseň, ukončená začátkem 2. světové války.

Zdroj wikipedia.

Nehoda teto nejvetsi vzducholode a spousta obeti natrvalo zmenila letecky prumysl. Do vzducholodi se prestalo investovat.
Název: Re:Co si myslíte o OOP?
Přispěvatel: operator 09. 01. 2019, 18:59:46
Tak jsem chtel overit tu haskell ukazku a zjistil, ze haskell je tak okrajovy jazyk, ze neni k dispozici v termuxu. Hledal jsem balicek s nazvem haskell nebo ghc. Seznam balicku: https://pastebin.com/kdfgUFRt To jen upevnuje me presvedceni, ze nema smysl ztracet cas okrajovymi nepodporovanymi jazyky.  Je schopen to nekdo predvest v jinem jazyku ktery je mezi balicky? (je tam kde co, rust, vala, erlang, java, ocaml, golang, clang, racket, ...)  Nebo se jedna ciste o schopnost haskellu, ktera je tu mylne prisuzovana jazykum se statickymi typy?
To je tak pitomá metrika (přítomnost v termuxu) a tak pitomý argument (když je to v Haskellu a opírá se to o statické typy, tak to nutně je demonstrace výhod statických typů)...
To neni metrika, proste si to nemam kde zkusit a z toho plyne muj osobni nezajem.
Ty nemas pocitac? :-O
Kazdopadne jsou i REPLy online. A cele IDE online byvalo taky.
Zadny kam bych mohl instalovat cizi software. Online mohu zkusit.
...nebo si třeba koupit počítač? Pro programátora je to celkem užitečné vybavení.
Na vyvoj mam pocitac, ale vzhledem k citlivosti nekterych zakazek s ohledem na kybernetickou bezpecnost si tam nemohu stahovat a instalovat kdejaky brak z netu. Na hrani si mi plne staci tablet.
Název: Re:Co si myslíte o OOP?
Přispěvatel: operator 09. 01. 2019, 19:02:25
Tak jsem chtel overit tu haskell ukazku a zjistil, ze haskell je tak okrajovy jazyk, ze neni k dispozici v termuxu. Hledal jsem balicek s nazvem haskell nebo ghc. Seznam balicku: https://pastebin.com/kdfgUFRt To jen upevnuje me presvedceni, ze nema smysl ztracet cas okrajovymi nepodporovanymi jazyky.  Je schopen to nekdo predvest v jinem jazyku ktery je mezi balicky? (je tam kde co, rust, vala, erlang, java, ocaml, golang, clang, racket, ...)  Nebo se jedna ciste o schopnost haskellu, ktera je tu mylne prisuzovana jazykum se statickymi typy?
To je tak pitomá metrika (přítomnost v termuxu) a tak pitomý argument (když je to v Haskellu a opírá se to o statické typy, tak to nutně je demonstrace výhod statických typů)...
Neni to demonstrace vyhod statickych typu, pokud je haskell jediny jazyk, ktery to umi. V takovem pripade je to demonstrace vyhoda haskellu. Na tom zalozene tvrzeni o statickych typech je argumentacni klam, predcasna generalizace.
Ale houby, umi to s drobnymi rozdily kopec jazyku (o Scale a F# tu uz rec sla), ten Haskell se proste bere jako "zlaty standard", co ho navic pomalu kazdy zna.
Zatim to spis vypada na vlastnost funkcionalnich jazyku, porad cekam na nejaky normalni. :-)
Normální? Oba jsou to multiparadigmatické jazyky.
Normalni, to jest ty, ktere se bezne pouzivaji v komercni praxi.
Tak to jsou normální.
:-)) Ohledne moznosti zneuznaneho a neuspesneho haskellu mi muzes veset buliky na nos, ohledne bezne pouzivanych jazyku v komercni sfere nikoliv.
Název: Re:Co si myslíte o OOP?
Přispěvatel: operator 09. 01. 2019, 19:05:22
Ja si mezitim dovolim predvest moznost typove kontroly u dynamickeho jazyka.
Kód: [Vybrat]
~ $ mypy typehint.py
typehint.py:6: error: Argument 1 to "inc" has incompatible type "str"; expected "int"
~ $ cat typehint.py
def inc(x:int)->int:
    return x+1

if  __name__ == '__main__':
    print(inc(3))
    print(inc('4'))
~ $ mypy typehint.py
typehint.py:6: error: Argument 1 to "inc" has incompatible type "str"; expected "int"
No vida, už jsi prozřel.
Tim ze jsem vyvratil vase tvrzeni, ze typova kontrola pred spustenim programu je domenou statickych typu? :-)
Název: Re:Co si myslíte o OOP?
Přispěvatel: operator 09. 01. 2019, 19:14:57
Ja si mezitim dovolim predvest moznost typove kontroly u dynamickeho jazyka.
Kód: [Vybrat]
~ $ mypy typehint.py
typehint.py:6: error: Argument 1 to "inc" has incompatible type "str"; expected "int"
~ $ cat typehint.py
def inc(x:int)->int:
    return x+1

if  __name__ == '__main__':
    print(inc(3))
    print(inc('4'))
~ $ mypy typehint.py
typehint.py:6: error: Argument 1 to "inc" has incompatible type "str"; expected "int"

Ono to funguje i bez explicitní deklarace typů:
Kód: [Vybrat]
def inc(x):
    return 1 + x

if __name__ == "__main__":
    print(inc(3))
    print(inc('4'))
Kód: [Vybrat]
4
Traceback (most recent call last):
  File "inc.py", line 9, in <module>
    print(inc('4'))
  File "inc.py", line 5, in inc
    return 1 + x
TypeError: unsupported operand type(s) for +: 'int' and 'str'
To co ukazujes ty je dynamicka kontrola za chodu programu, to co ukazuji ja je kontrola pred spustenim. Program mypy je type checker. Nainstaluj si ho prikazem 'python -m pip install -U mypy'

Rozdil poznas, kdyz kod upravis na

Kód: [Vybrat]
def inc(x:int)->int:
    return x+1

if  __name__ == '__main__':
    print(inc(3))
    if  False:
        print(inc('4'))
Název: Re:Co si myslíte o OOP?
Přispěvatel: Kit 09. 01. 2019, 19:32:10
To co ukazujes ty je dynamicka kontrola za chodu programu, to co ukazuji ja je kontrola pred spustenim. Program mypy je type checker. Nainstaluj si ho prikazem 'python -m pip install -U mypy'

Rozdil poznas, kdyz kod upravis na

Kód: [Vybrat]
def inc(x:int)->int:
    return x+1

if  __name__ == '__main__':
    print(inc(3))
    if  False:
        print(inc('4'))

V tom případě by mělo fungovat i tohle:
Kód: [Vybrat]
def inc(x:int)->int:
    return x+1

if False:
    print(inc(3))
    print(inc('4'))
Název: Re:Co si myslíte o OOP?
Přispěvatel: listoper 09. 01. 2019, 19:57:10
Ja si mezitim dovolim predvest moznost typove kontroly u dynamickeho jazyka.
Kód: [Vybrat]
~ $ mypy typehint.py
typehint.py:6: error: Argument 1 to "inc" has incompatible type "str"; expected "int"
~ $ cat typehint.py
def inc(x:int)->int:
    return x+1

if  __name__ == '__main__':
    print(inc(3))
    print(inc('4'))
~ $ mypy typehint.py
typehint.py:6: error: Argument 1 to "inc" has incompatible type "str"; expected "int"
No vida, už jsi prozřel.
Tim ze jsem vyvratil vase tvrzeni, ze typova kontrola pred spustenim programu je domenou statickych typu? :-)

Myslis, ze muzes porad mluvit to dynamickem jazyku kdyz pouzijes staticky type checker?
Název: Re:Co si myslíte o OOP?
Přispěvatel: operator 09. 01. 2019, 20:04:02
Aha, takže úplně stejně to udělám, když budu chtít napsat funkci inc4096, která zvýší hodnotu o 4096?

V podstate jo, akorat pouzijes silnejsi typovy system, kde se to "funkce zvysuje o 4096" zapise v typech rovnou s konstantou 4096.

Neni to pak (co do psani) odlisne od toho, mit test, ktery overi, jestli je vystup skutecne o 4096 vyssi nez vstup.

Nicmene zatimco to prvni to donuti typechecker overit pro vsechny pripady, to druhe overi jen nektere situace. Nevyhodou prvniho pristupu ovsem je, ze nekdy to ten typechecker taky dokazat nemusi umet.
Jedna se o naprosto primitivni funkci. Predstav si implementaci neceho slozitejsiho, treba md5(). Jak si typem overis vsechny pripady? Nebo jak si overis vsechny pripady u formatmonth() z calendar?
Kód: [Vybrat]
>>> import calendar
>>> print(calendar.LocaleTextCalendar().formatmonth(2019, 2))
   February 2019
Mo Tu We Th Fr Sa Su
             1  2  3
 4  5  6  7  8  9 10
11 12 13 14 15 16 17
18 19 20 21 22 23 24
25 26 27 28
A to jsme jeste porad u jednoduchych veci. Ted si predstav, ze mas overovat spravnost sloziteho vystupu typu webova stranka, video nebo hudebni skladba.
Název: Re:Co si myslíte o OOP?
Přispěvatel: operator 09. 01. 2019, 20:06:22
Aha, takže úplně stejně to udělám, když budu chtít napsat funkci inc4096, která zvýší hodnotu o 4096?
V podstate jo, akorat pouzijes silnejsi typovy system, kde se to "funkce zvysuje o 4096" zapise v typech rovnou s konstantou 4096.

Neni to pak (co do psani) odlisne od toho, mit test, ktery overi, jestli je vystup skutecne o 4096 vyssi nez vstup.
nebo se přidá pár type families a napíše se třeba
Kód: [Vybrat]
Nat' n -> Nat' (Plus (Exp (S (S Z)) (S (S (S (S (S (S (S (S (S (S (S (S Z))))))))))))) n)hnus, ale taky úplně umělý příklad

A co třeba kdybych chtěl funkci inc1234567, která bude přidávat 1234567? To budu zase vymýšlet podobnou bejkárnu?
jestli potřebujete funkci inc1234567 tak dobře vám tak
Tohle uz ma jiny principialni problem. Ten typ je radove slozitejsi nez sama funkce, takze je tu otazka, kdo bude kontrolovat spravnost zapisu typu :-).
Název: Re:Co si myslíte o OOP?
Přispěvatel: operator 09. 01. 2019, 20:12:55
Ja si mezitim dovolim predvest moznost typove kontroly u dynamickeho jazyka.
Kód: [Vybrat]
~ $ mypy typehint.py
typehint.py:6: error: Argument 1 to "inc" has incompatible type "str"; expected "int"
~ $ cat typehint.py
def inc(x:int)->int:
    return x+1

if  __name__ == '__main__':
    print(inc(3))
    print(inc('4'))
~ $ mypy typehint.py
typehint.py:6: error: Argument 1 to "inc" has incompatible type "str"; expected "int"
No vida, už jsi prozřel.
Tim ze jsem vyvratil vase tvrzeni, ze typova kontrola pred spustenim programu je domenou statickych typu? :-)

Myslis, ze muzes porad mluvit to dynamickem jazyku kdyz pouzijes staticky type checker?
Jiste, protoze vyrazy se porad vyhodnocuji az za chodu programu a typy jsou svazane s hodnotami. Nebo si myslis, ze python je staticky jazyk? Interpret pythonu zustava naprosto stejny a type hinty ignoruje, jsou vyhrazeny pro externi nastroje.  Uz se blizite k pochopeni toho, co jsou ve skutecnosti staticke typy a ze jim prisuzujete vlastnosti, ktere jim nejsou vlastni a lze jich dosahnout alternativne.
Název: Re:Co si myslíte o OOP?
Přispěvatel: Kit 09. 01. 2019, 20:25:10
Aha, takže úplně stejně to udělám, když budu chtít napsat funkci inc4096, která zvýší hodnotu o 4096?
V podstate jo, akorat pouzijes silnejsi typovy system, kde se to "funkce zvysuje o 4096" zapise v typech rovnou s konstantou 4096.

Neni to pak (co do psani) odlisne od toho, mit test, ktery overi, jestli je vystup skutecne o 4096 vyssi nez vstup.
nebo se přidá pár type families a napíše se třeba
Kód: [Vybrat]
Nat' n -> Nat' (Plus (Exp (S (S Z)) (S (S (S (S (S (S (S (S (S (S (S (S Z))))))))))))) n)hnus, ale taky úplně umělý příklad

A co třeba kdybych chtěl funkci inc1234567, která bude přidávat 1234567? To budu zase vymýšlet podobnou bejkárnu?
jestli potřebujete funkci inc1234567 tak dobře vám tak
Tohle uz ma jiny principialni problem. Ten typ je radove slozitejsi nez sama funkce, takze je tu otazka, kdo bude kontrolovat spravnost zapisu typu :-).

Mělo to jiný principiální problém už pro funkci inc5. Nenapadlo mě, že na to někdo 5× použije (S n) nebo ještě hroznější zápis.
Název: Re:Co si myslíte o OOP?
Přispěvatel: v 09. 01. 2019, 20:30:22
Aha, takže úplně stejně to udělám, když budu chtít napsat funkci inc4096, která zvýší hodnotu o 4096?
V podstate jo, akorat pouzijes silnejsi typovy system, kde se to "funkce zvysuje o 4096" zapise v typech rovnou s konstantou 4096.

Neni to pak (co do psani) odlisne od toho, mit test, ktery overi, jestli je vystup skutecne o 4096 vyssi nez vstup.
nebo se přidá pár type families a napíše se třeba
Kód: [Vybrat]
Nat' n -> Nat' (Plus (Exp (S (S Z)) (S (S (S (S (S (S (S (S (S (S (S (S Z))))))))))))) n)hnus, ale taky úplně umělý příklad

A co třeba kdybych chtěl funkci inc1234567, která bude přidávat 1234567? To budu zase vymýšlet podobnou bejkárnu?
jestli potřebujete funkci inc1234567 tak dobře vám tak
Tohle uz ma jiny principialni problem. Ten typ je radove slozitejsi nez sama funkce, takze je tu otazka, kdo bude kontrolovat spravnost zapisu typu :-).
haskell není jazyk s nejpokročilejším typovým systémem, ale je hodně rozšířený a ma jiné výhody
pro srovnání idris:
Kód: [Vybrat]
inc : (n : Nat) -> (m : Nat ** m = n + 1)
inc n = (n + 1 ** Refl)
přírůstek můžete přepsat podle potřeby, pokud se liší v typu a těle, neprojde typecheckerem
Název: Re:Co si myslíte o OOP?
Přispěvatel: Mirek Prýmek 09. 01. 2019, 20:41:22
pro srovnání idris:
Kód: [Vybrat]
inc : (n : Nat) -> (m : Nat ** m = n + 1)
inc n = (n + 1 ** Refl)
přírůstek můžete přepsat podle potřeby, pokud se liší v typu a těle, neprojde typecheckerem
Pripomnel jsi mi, ze jsem se chtel - az budu mit nekdy trochu vic casu na ptakoviny* - na nejaky jazyk s dependent types podivat. Idris je horky kandidat. Pouzival jsi ho nekdy trochu vic? Doporucil bys ho na hrani nebo radsi neco jinyho?

* takze nejspis nejdriv tak v duchodu
Název: Re:Co si myslíte o OOP?
Přispěvatel: v 09. 01. 2019, 20:47:52
pro srovnání idris:
Kód: [Vybrat]
inc : (n : Nat) -> (m : Nat ** m = n + 1)
inc n = (n + 1 ** Refl)
přírůstek můžete přepsat podle potřeby, pokud se liší v typu a těle, neprojde typecheckerem
Pripomnel jsi mi, ze jsem se chtel - az budu mit nekdy trochu vic casu na ptakoviny* - na nejaky jazyk s dependent types podivat. Idris je horky kandidat. Pouzival jsi ho nekdy trochu vic? Doporucil bys ho na hrani nebo radsi neco jinyho?

* takze nejspis nejdriv tak v duchodu
znám jenom letmo idris a agdu jsem viděl z vlaku... ale doporučil, příbuznost s haskellem je IMHO velká výhoda, jinak ten-jehož-jméno-je-nestálé o tom asi ví víc
pro zajímavost, blodwen/idris 2 https://www.youtube.com/watch?v=mOtKD7ml0NU
Název: Re:Co si myslíte o OOP?
Přispěvatel: BaldSlattery 09. 01. 2019, 21:36:31
Aha, takže úplně stejně to udělám, když budu chtít napsat funkci inc4096, která zvýší hodnotu o 4096?
V podstate jo, akorat pouzijes silnejsi typovy system, kde se to "funkce zvysuje o 4096" zapise v typech rovnou s konstantou 4096.

Neni to pak (co do psani) odlisne od toho, mit test, ktery overi, jestli je vystup skutecne o 4096 vyssi nez vstup.
nebo se přidá pár type families a napíše se třeba
Kód: [Vybrat]
Nat' n -> Nat' (Plus (Exp (S (S Z)) (S (S (S (S (S (S (S (S (S (S (S (S Z))))))))))))) n)hnus, ale taky úplně umělý příklad

A co třeba kdybych chtěl funkci inc1234567, která bude přidávat 1234567? To budu zase vymýšlet podobnou bejkárnu?
jestli potřebujete funkci inc1234567 tak dobře vám tak
Tohle uz ma jiny principialni problem. Ten typ je radove slozitejsi nez sama funkce, takze je tu otazka, kdo bude kontrolovat spravnost zapisu typu :-).
pro srovnání idris:
Kód: [Vybrat]
inc : (n : Nat) -> (m : Nat ** m = n + 1)
inc n = (n + 1 ** Refl)
Hic svnt dracones  ???
Název: Re:Co si myslíte o OOP?
Přispěvatel: BaldSlattery 09. 01. 2019, 21:38:26
pro srovnání idris:
Kód: [Vybrat]
inc : (n : Nat) -> (m : Nat ** m = n + 1)
inc n = (n + 1 ** Refl)
přírůstek můžete přepsat podle potřeby, pokud se liší v typu a těle, neprojde typecheckerem
Pripomnel jsi mi, ze jsem se chtel - az budu mit nekdy trochu vic casu na ptakoviny* - na nejaky jazyk s dependent types podivat. Idris je horky kandidat. Pouzival jsi ho nekdy trochu vic? Doporucil bys ho na hrani nebo radsi neco jinyho?

* takze nejspis nejdriv tak v duchodu
Jako první bych ho nedoporučil, má implicitní argumenty, při učení člověk jen zírá, kde se ztrácí proměnné.
Název: Re:Co si myslíte o OOP?
Přispěvatel: Mirek Prýmek 09. 01. 2019, 23:48:11
Jako první bych ho nedoporučil, má implicitní argumenty, při učení člověk jen zírá, kde se ztrácí proměnné.
Takze radsi Agdu? Nebo jeste neco jinyho?
Název: Re:Co si myslíte o OOP?
Přispěvatel: Tom@as 10. 01. 2019, 00:02:32
Aha, takže úplně stejně to udělám, když budu chtít napsat funkci inc4096, která zvýší hodnotu o 4096?
V podstate jo, akorat pouzijes silnejsi typovy system, kde se to "funkce zvysuje o 4096" zapise v typech rovnou s konstantou 4096.

Neni to pak (co do psani) odlisne od toho, mit test, ktery overi, jestli je vystup skutecne o 4096 vyssi nez vstup.
nebo se přidá pár type families a napíše se třeba
Kód: [Vybrat]
Nat' n -> Nat' (Plus (Exp (S (S Z)) (S (S (S (S (S (S (S (S (S (S (S (S Z))))))))))))) n)hnus, ale taky úplně umělý příklad

A co třeba kdybych chtěl funkci inc1234567, která bude přidávat 1234567? To budu zase vymýšlet podobnou bejkárnu?
jestli potřebujete funkci inc1234567 tak dobře vám tak
Tohle uz ma jiny principialni problem. Ten typ je radove slozitejsi nez sama funkce, takze je tu otazka, kdo bude kontrolovat spravnost zapisu typu :-).
pro srovnání idris:
Kód: [Vybrat]
inc : (n : Nat) -> (m : Nat ** m = n + 1)
inc n = (n + 1 ** Refl)
Hic svnt dracones  ???
Tak to už je šílené :D :D :D tolik vnořených komentářů
Název: Re:Co si myslíte o OOP?
Přispěvatel: BaldSlattery 10. 01. 2019, 00:11:30
Aha, takže úplně stejně to udělám, když budu chtít napsat funkci inc4096, která zvýší hodnotu o 4096?
V podstate jo, akorat pouzijes silnejsi typovy system, kde se to "funkce zvysuje o 4096" zapise v typech rovnou s konstantou 4096.

Neni to pak (co do psani) odlisne od toho, mit test, ktery overi, jestli je vystup skutecne o 4096 vyssi nez vstup.
nebo se přidá pár type families a napíše se třeba
Kód: [Vybrat]
Nat' n -> Nat' (Plus (Exp (S (S Z)) (S (S (S (S (S (S (S (S (S (S (S (S Z))))))))))))) n)hnus, ale taky úplně umělý příklad

A co třeba kdybych chtěl funkci inc1234567, která bude přidávat 1234567? To budu zase vymýšlet podobnou bejkárnu?
jestli potřebujete funkci inc1234567 tak dobře vám tak
Tohle uz ma jiny principialni problem. Ten typ je radove slozitejsi nez sama funkce, takze je tu otazka, kdo bude kontrolovat spravnost zapisu typu :-).
pro srovnání idris:
Kód: [Vybrat]
inc : (n : Nat) -> (m : Nat ** m = n + 1)
inc n = (n + 1 ** Refl)
Hic svnt dracones  ???
Tak to už je šílené :D :D :D tolik vnořených komentářů
Tak to už nezhoršujte  ;)
Název: Re:Co si myslíte o OOP?
Přispěvatel: Mirek Prýmek 10. 01. 2019, 00:12:05
Aha, takže úplně stejně to udělám, když budu chtít napsat funkci inc4096, která zvýší hodnotu o 4096?
V podstate jo, akorat pouzijes silnejsi typovy system, kde se to "funkce zvysuje o 4096" zapise v typech rovnou s konstantou 4096.

Neni to pak (co do psani) odlisne od toho, mit test, ktery overi, jestli je vystup skutecne o 4096 vyssi nez vstup.
nebo se přidá pár type families a napíše se třeba
Kód: [Vybrat]
Nat' n -> Nat' (Plus (Exp (S (S Z)) (S (S (S (S (S (S (S (S (S (S (S (S Z))))))))))))) n)hnus, ale taky úplně umělý příklad

A co třeba kdybych chtěl funkci inc1234567, která bude přidávat 1234567? To budu zase vymýšlet podobnou bejkárnu?
jestli potřebujete funkci inc1234567 tak dobře vám tak
Tohle uz ma jiny principialni problem. Ten typ je radove slozitejsi nez sama funkce, takze je tu otazka, kdo bude kontrolovat spravnost zapisu typu :-).
pro srovnání idris:
Kód: [Vybrat]
inc : (n : Nat) -> (m : Nat ** m = n + 1)
inc n = (n + 1 ** Refl)
Hic svnt dracones  ???
Tak to už je šílené :D :D :D tolik vnořených komentářů
Tak to už nezhoršujte  ;)
Coze?
Název: Re:Co si myslíte o OOP?
Přispěvatel: BaldSlattery 10. 01. 2019, 00:13:41
Jako první bych ho nedoporučil, má implicitní argumenty, při učení člověk jen zírá, kde se ztrácí proměnné.
Takze radsi Agdu? Nebo jeste neco jinyho?
Na naučení asi (nebo spíše rozhodně) ne. Na první lekce Pie (z knihy The little typer), nemá implicitní parametry, takže jsou všechna odvození (důkazy) názorně vidět.
Název: Re:Co si myslíte o OOP?
Přispěvatel: BaldSlattery 10. 01. 2019, 00:14:18
Aha, takže úplně stejně to udělám, když budu chtít napsat funkci inc4096, která zvýší hodnotu o 4096?
V podstate jo, akorat pouzijes silnejsi typovy system, kde se to "funkce zvysuje o 4096" zapise v typech rovnou s konstantou 4096.

Neni to pak (co do psani) odlisne od toho, mit test, ktery overi, jestli je vystup skutecne o 4096 vyssi nez vstup.
nebo se přidá pár type families a napíše se třeba
Kód: [Vybrat]
Nat' n -> Nat' (Plus (Exp (S (S Z)) (S (S (S (S (S (S (S (S (S (S (S (S Z))))))))))))) n)hnus, ale taky úplně umělý příklad

A co třeba kdybych chtěl funkci inc1234567, která bude přidávat 1234567? To budu zase vymýšlet podobnou bejkárnu?
jestli potřebujete funkci inc1234567 tak dobře vám tak
Tohle uz ma jiny principialni problem. Ten typ je radove slozitejsi nez sama funkce, takze je tu otazka, kdo bude kontrolovat spravnost zapisu typu :-).
pro srovnání idris:
Kód: [Vybrat]
inc : (n : Nat) -> (m : Nat ** m = n + 1)
inc n = (n + 1 ** Refl)
Hic svnt dracones  ???
Tak to už je šílené :D :D :D tolik vnořených komentářů
Tak to už nezhoršujte  ;)
Coze?
::)
Název: Re:Co si myslíte o OOP?
Přispěvatel: Mirek Prýmek 10. 01. 2019, 00:17:59
Na naučení asi (nebo spíše rozhodně) ne. Na první lekce Pie (z knihy The little typer), nemá implicitní parametry, takže jsou všechna odvození (důkazy) názorně vidět.
Dik!
Název: Re:Co si myslíte o OOP?
Přispěvatel: BaldSlattery 10. 01. 2019, 00:26:31
Na naučení asi (nebo spíše rozhodně) ne. Na první lekce Pie (z knihy The little typer), nemá implicitní parametry, takže jsou všechna odvození (důkazy) názorně vidět.
Dik!
Je to na githubu.
Název: Re:Co si myslíte o OOP?
Přispěvatel: Mirek Prýmek 10. 01. 2019, 03:22:39
Je to na githubu.
Jo, videl jsem.
Název: Re:Co si myslíte o OOP?
Přispěvatel: Ondra Satai Nekola 10. 01. 2019, 15:02:33
Tak jsem chtel overit tu haskell ukazku a zjistil, ze haskell je tak okrajovy jazyk, ze neni k dispozici v termuxu. Hledal jsem balicek s nazvem haskell nebo ghc. Seznam balicku: https://pastebin.com/kdfgUFRt To jen upevnuje me presvedceni, ze nema smysl ztracet cas okrajovymi nepodporovanymi jazyky.  Je schopen to nekdo predvest v jinem jazyku ktery je mezi balicky? (je tam kde co, rust, vala, erlang, java, ocaml, golang, clang, racket, ...)  Nebo se jedna ciste o schopnost haskellu, ktera je tu mylne prisuzovana jazykum se statickymi typy?
To je tak pitomá metrika (přítomnost v termuxu) a tak pitomý argument (když je to v Haskellu a opírá se to o statické typy, tak to nutně je demonstrace výhod statických typů)...
Neni to demonstrace vyhod statickych typu, pokud je haskell jediny jazyk, ktery to umi. V takovem pripade je to demonstrace vyhoda haskellu. Na tom zalozene tvrzeni o statickych typech je argumentacni klam, predcasna generalizace.
Ale houby, umi to s drobnymi rozdily kopec jazyku (o Scale a F# tu uz rec sla), ten Haskell se proste bere jako "zlaty standard", co ho navic pomalu kazdy zna.
Zatim to spis vypada na vlastnost funkcionalnich jazyku, porad cekam na nejaky normalni. :-)
Normální? Oba jsou to multiparadigmatické jazyky.
Normalni, to jest ty, ktere se bezne pouzivaji v komercni praxi.
Tak to jsou normální.
:-)) Ohledne moznosti zneuznaneho a neuspesneho haskellu mi muzes veset buliky na nos, ohledne bezne pouzivanych jazyku v komercni sfere nikoliv.

To je takovy problem se podivat do inzeratu? Scala neni zdaleka takova masovka jako trebas Java, ale misto se najde bez problemu. Pokud zuzis sve pozadavky na "zajimava prace", tak se ten pomer navic dost zlepsi...
Název: Re:Co si myslíte o OOP?
Přispěvatel: operator 10. 01. 2019, 16:18:15
Tak jsem chtel overit tu haskell ukazku a zjistil, ze haskell je tak okrajovy jazyk, ze neni k dispozici v termuxu. Hledal jsem balicek s nazvem haskell nebo ghc. Seznam balicku: https://pastebin.com/kdfgUFRt To jen upevnuje me presvedceni, ze nema smysl ztracet cas okrajovymi nepodporovanymi jazyky.  Je schopen to nekdo predvest v jinem jazyku ktery je mezi balicky? (je tam kde co, rust, vala, erlang, java, ocaml, golang, clang, racket, ...)  Nebo se jedna ciste o schopnost haskellu, ktera je tu mylne prisuzovana jazykum se statickymi typy?
To je tak pitomá metrika (přítomnost v termuxu) a tak pitomý argument (když je to v Haskellu a opírá se to o statické typy, tak to nutně je demonstrace výhod statických typů)...
Neni to demonstrace vyhod statickych typu, pokud je haskell jediny jazyk, ktery to umi. V takovem pripade je to demonstrace vyhoda haskellu. Na tom zalozene tvrzeni o statickych typech je argumentacni klam, predcasna generalizace.
Ale houby, umi to s drobnymi rozdily kopec jazyku (o Scale a F# tu uz rec sla), ten Haskell se proste bere jako "zlaty standard", co ho navic pomalu kazdy zna.
Zatim to spis vypada na vlastnost funkcionalnich jazyku, porad cekam na nejaky normalni. :-)
Normální? Oba jsou to multiparadigmatické jazyky.
Normalni, to jest ty, ktere se bezne pouzivaji v komercni praxi.
Tak to jsou normální.
:-)) Ohledne moznosti zneuznaneho a neuspesneho haskellu mi muzes veset buliky na nos, ohledne bezne pouzivanych jazyku v komercni sfere nikoliv.

To je takovy problem se podivat do inzeratu? Scala neni zdaleka takova masovka jako trebas Java, ale misto se najde bez problemu. Pokud zuzis sve pozadavky na "zajimava prace", tak se ten pomer navic dost zlepsi...
Pro mě jsou zajímavé zakázky. Nikdo z našich klientů (podniková sféra) takové obskurnosti nepoptává.
Název: Re:Co si myslíte o OOP?
Přispěvatel: Ondra Satai Nekola 10. 01. 2019, 16:30:01
Tak jsem chtel overit tu haskell ukazku a zjistil, ze haskell je tak okrajovy jazyk, ze neni k dispozici v termuxu. Hledal jsem balicek s nazvem haskell nebo ghc. Seznam balicku: https://pastebin.com/kdfgUFRt To jen upevnuje me presvedceni, ze nema smysl ztracet cas okrajovymi nepodporovanymi jazyky.  Je schopen to nekdo predvest v jinem jazyku ktery je mezi balicky? (je tam kde co, rust, vala, erlang, java, ocaml, golang, clang, racket, ...)  Nebo se jedna ciste o schopnost haskellu, ktera je tu mylne prisuzovana jazykum se statickymi typy?
To je tak pitomá metrika (přítomnost v termuxu) a tak pitomý argument (když je to v Haskellu a opírá se to o statické typy, tak to nutně je demonstrace výhod statických typů)...
Neni to demonstrace vyhod statickych typu, pokud je haskell jediny jazyk, ktery to umi. V takovem pripade je to demonstrace vyhoda haskellu. Na tom zalozene tvrzeni o statickych typech je argumentacni klam, predcasna generalizace.
Ale houby, umi to s drobnymi rozdily kopec jazyku (o Scale a F# tu uz rec sla), ten Haskell se proste bere jako "zlaty standard", co ho navic pomalu kazdy zna.
Zatim to spis vypada na vlastnost funkcionalnich jazyku, porad cekam na nejaky normalni. :-)
Normální? Oba jsou to multiparadigmatické jazyky.
Normalni, to jest ty, ktere se bezne pouzivaji v komercni praxi.
Tak to jsou normální.
:-)) Ohledne moznosti zneuznaneho a neuspesneho haskellu mi muzes veset buliky na nos, ohledne bezne pouzivanych jazyku v komercni sfere nikoliv.

To je takovy problem se podivat do inzeratu? Scala neni zdaleka takova masovka jako trebas Java, ale misto se najde bez problemu. Pokud zuzis sve pozadavky na "zajimava prace", tak se ten pomer navic dost zlepsi...
Pro mě jsou zajímavé zakázky. Nikdo z našich klientů (podniková sféra) takové obskurnosti nepoptává.

Jinymi slovy - generalizujes sve zkusenosti s patlanim v jedne oblasti na cely obor.
Název: Re:Co si myslíte o OOP?
Přispěvatel: operator 10. 01. 2019, 16:49:09
Tak jsem chtel overit tu haskell ukazku a zjistil, ze haskell je tak okrajovy jazyk, ze neni k dispozici v termuxu. Hledal jsem balicek s nazvem haskell nebo ghc. Seznam balicku: https://pastebin.com/kdfgUFRt To jen upevnuje me presvedceni, ze nema smysl ztracet cas okrajovymi nepodporovanymi jazyky.  Je schopen to nekdo predvest v jinem jazyku ktery je mezi balicky? (je tam kde co, rust, vala, erlang, java, ocaml, golang, clang, racket, ...)  Nebo se jedna ciste o schopnost haskellu, ktera je tu mylne prisuzovana jazykum se statickymi typy?
To je tak pitomá metrika (přítomnost v termuxu) a tak pitomý argument (když je to v Haskellu a opírá se to o statické typy, tak to nutně je demonstrace výhod statických typů)...
Neni to demonstrace vyhod statickych typu, pokud je haskell jediny jazyk, ktery to umi. V takovem pripade je to demonstrace vyhoda haskellu. Na tom zalozene tvrzeni o statickych typech je argumentacni klam, predcasna generalizace.
Ale houby, umi to s drobnymi rozdily kopec jazyku (o Scale a F# tu uz rec sla), ten Haskell se proste bere jako "zlaty standard", co ho navic pomalu kazdy zna.
Zatim to spis vypada na vlastnost funkcionalnich jazyku, porad cekam na nejaky normalni. :-)
Normální? Oba jsou to multiparadigmatické jazyky.
Normalni, to jest ty, ktere se bezne pouzivaji v komercni praxi.
Tak to jsou normální.
:-)) Ohledne moznosti zneuznaneho a neuspesneho haskellu mi muzes veset buliky na nos, ohledne bezne pouzivanych jazyku v komercni sfere nikoliv.

To je takovy problem se podivat do inzeratu? Scala neni zdaleka takova masovka jako trebas Java, ale misto se najde bez problemu. Pokud zuzis sve pozadavky na "zajimava prace", tak se ten pomer navic dost zlepsi...
Pro mě jsou zajímavé zakázky. Nikdo z našich klientů (podniková sféra) takové obskurnosti nepoptává.
Jinymi slovy - generalizujes sve zkusenosti s patlanim v jedne oblasti na cely obor.
Nejen sve. Jak uz jsem tu uvedl, pragmaticky me zajima jen to, co ma pro me prinos, ted a nebo v budoucnu.
Název: Re:Co si myslíte o OOP?
Přispěvatel: Ondra Satai Nekola 10. 01. 2019, 17:04:43
Tak jsem chtel overit tu haskell ukazku a zjistil, ze haskell je tak okrajovy jazyk, ze neni k dispozici v termuxu. Hledal jsem balicek s nazvem haskell nebo ghc. Seznam balicku: https://pastebin.com/kdfgUFRt To jen upevnuje me presvedceni, ze nema smysl ztracet cas okrajovymi nepodporovanymi jazyky.  Je schopen to nekdo predvest v jinem jazyku ktery je mezi balicky? (je tam kde co, rust, vala, erlang, java, ocaml, golang, clang, racket, ...)  Nebo se jedna ciste o schopnost haskellu, ktera je tu mylne prisuzovana jazykum se statickymi typy?
To je tak pitomá metrika (přítomnost v termuxu) a tak pitomý argument (když je to v Haskellu a opírá se to o statické typy, tak to nutně je demonstrace výhod statických typů)...
Neni to demonstrace vyhod statickych typu, pokud je haskell jediny jazyk, ktery to umi. V takovem pripade je to demonstrace vyhoda haskellu. Na tom zalozene tvrzeni o statickych typech je argumentacni klam, predcasna generalizace.
Ale houby, umi to s drobnymi rozdily kopec jazyku (o Scale a F# tu uz rec sla), ten Haskell se proste bere jako "zlaty standard", co ho navic pomalu kazdy zna.
Zatim to spis vypada na vlastnost funkcionalnich jazyku, porad cekam na nejaky normalni. :-)
Normální? Oba jsou to multiparadigmatické jazyky.
Normalni, to jest ty, ktere se bezne pouzivaji v komercni praxi.
Tak to jsou normální.
:-)) Ohledne moznosti zneuznaneho a neuspesneho haskellu mi muzes veset buliky na nos, ohledne bezne pouzivanych jazyku v komercni sfere nikoliv.

To je takovy problem se podivat do inzeratu? Scala neni zdaleka takova masovka jako trebas Java, ale misto se najde bez problemu. Pokud zuzis sve pozadavky na "zajimava prace", tak se ten pomer navic dost zlepsi...
Pro mě jsou zajímavé zakázky. Nikdo z našich klientů (podniková sféra) takové obskurnosti nepoptává.
Jinymi slovy - generalizujes sve zkusenosti s patlanim v jedne oblasti na cely obor.
Nejen sve. Jak uz jsem tu uvedl, pragmaticky me zajima jen to, co ma pro me prinos, ted a nebo v budoucnu.

To asi zůstaneš hodně omezenej.
Název: Re:Co si myslíte o OOP?
Přispěvatel: operator 10. 01. 2019, 17:41:39
Tak jsem chtel overit tu haskell ukazku a zjistil, ze haskell je tak okrajovy jazyk, ze neni k dispozici v termuxu. Hledal jsem balicek s nazvem haskell nebo ghc. Seznam balicku: https://pastebin.com/kdfgUFRt To jen upevnuje me presvedceni, ze nema smysl ztracet cas okrajovymi nepodporovanymi jazyky.  Je schopen to nekdo predvest v jinem jazyku ktery je mezi balicky? (je tam kde co, rust, vala, erlang, java, ocaml, golang, clang, racket, ...)  Nebo se jedna ciste o schopnost haskellu, ktera je tu mylne prisuzovana jazykum se statickymi typy?
To je tak pitomá metrika (přítomnost v termuxu) a tak pitomý argument (když je to v Haskellu a opírá se to o statické typy, tak to nutně je demonstrace výhod statických typů)...
Neni to demonstrace vyhod statickych typu, pokud je haskell jediny jazyk, ktery to umi. V takovem pripade je to demonstrace vyhoda haskellu. Na tom zalozene tvrzeni o statickych typech je argumentacni klam, predcasna generalizace.
Ale houby, umi to s drobnymi rozdily kopec jazyku (o Scale a F# tu uz rec sla), ten Haskell se proste bere jako "zlaty standard", co ho navic pomalu kazdy zna.
Zatim to spis vypada na vlastnost funkcionalnich jazyku, porad cekam na nejaky normalni. :-)
Normální? Oba jsou to multiparadigmatické jazyky.
Normalni, to jest ty, ktere se bezne pouzivaji v komercni praxi.
Tak to jsou normální.
:-)) Ohledne moznosti zneuznaneho a neuspesneho haskellu mi muzes veset buliky na nos, ohledne bezne pouzivanych jazyku v komercni sfere nikoliv.

To je takovy problem se podivat do inzeratu? Scala neni zdaleka takova masovka jako trebas Java, ale misto se najde bez problemu. Pokud zuzis sve pozadavky na "zajimava prace", tak se ten pomer navic dost zlepsi...
Pro mě jsou zajímavé zakázky. Nikdo z našich klientů (podniková sféra) takové obskurnosti nepoptává.
Jinymi slovy - generalizujes sve zkusenosti s patlanim v jedne oblasti na cely obor.
Nejen sve. Jak uz jsem tu uvedl, pragmaticky me zajima jen to, co ma pro me prinos, ted a nebo v budoucnu.
To asi zůstaneš hodně omezenej.
Prave naopak.
Název: Re:Co si myslíte o OOP?
Přispěvatel: Ondra Satai Nekola 10. 01. 2019, 17:55:18
Tak jsem chtel overit tu haskell ukazku a zjistil, ze haskell je tak okrajovy jazyk, ze neni k dispozici v termuxu. Hledal jsem balicek s nazvem haskell nebo ghc. Seznam balicku: https://pastebin.com/kdfgUFRt To jen upevnuje me presvedceni, ze nema smysl ztracet cas okrajovymi nepodporovanymi jazyky.  Je schopen to nekdo predvest v jinem jazyku ktery je mezi balicky? (je tam kde co, rust, vala, erlang, java, ocaml, golang, clang, racket, ...)  Nebo se jedna ciste o schopnost haskellu, ktera je tu mylne prisuzovana jazykum se statickymi typy?
To je tak pitomá metrika (přítomnost v termuxu) a tak pitomý argument (když je to v Haskellu a opírá se to o statické typy, tak to nutně je demonstrace výhod statických typů)...
Neni to demonstrace vyhod statickych typu, pokud je haskell jediny jazyk, ktery to umi. V takovem pripade je to demonstrace vyhoda haskellu. Na tom zalozene tvrzeni o statickych typech je argumentacni klam, predcasna generalizace.
Ale houby, umi to s drobnymi rozdily kopec jazyku (o Scale a F# tu uz rec sla), ten Haskell se proste bere jako "zlaty standard", co ho navic pomalu kazdy zna.
Zatim to spis vypada na vlastnost funkcionalnich jazyku, porad cekam na nejaky normalni. :-)
Normální? Oba jsou to multiparadigmatické jazyky.
Normalni, to jest ty, ktere se bezne pouzivaji v komercni praxi.
Tak to jsou normální.
:-)) Ohledne moznosti zneuznaneho a neuspesneho haskellu mi muzes veset buliky na nos, ohledne bezne pouzivanych jazyku v komercni sfere nikoliv.

To je takovy problem se podivat do inzeratu? Scala neni zdaleka takova masovka jako trebas Java, ale misto se najde bez problemu. Pokud zuzis sve pozadavky na "zajimava prace", tak se ten pomer navic dost zlepsi...
Pro mě jsou zajímavé zakázky. Nikdo z našich klientů (podniková sféra) takové obskurnosti nepoptává.
Jinymi slovy - generalizujes sve zkusenosti s patlanim v jedne oblasti na cely obor.
Nejen sve. Jak uz jsem tu uvedl, pragmaticky me zajima jen to, co ma pro me prinos, ted a nebo v budoucnu.
To asi zůstaneš hodně omezenej.
Prave naopak.
Tak jak jinak chceš fachidiocii říkat?
Název: Re:Co si myslíte o OOP?
Přispěvatel: operator 11. 01. 2019, 09:29:59
Tak jsem chtel overit tu haskell ukazku a zjistil, ze haskell je tak okrajovy jazyk, ze neni k dispozici v termuxu. Hledal jsem balicek s nazvem haskell nebo ghc. Seznam balicku: https://pastebin.com/kdfgUFRt To jen upevnuje me presvedceni, ze nema smysl ztracet cas okrajovymi nepodporovanymi jazyky.  Je schopen to nekdo predvest v jinem jazyku ktery je mezi balicky? (je tam kde co, rust, vala, erlang, java, ocaml, golang, clang, racket, ...)  Nebo se jedna ciste o schopnost haskellu, ktera je tu mylne prisuzovana jazykum se statickymi typy?
To je tak pitomá metrika (přítomnost v termuxu) a tak pitomý argument (když je to v Haskellu a opírá se to o statické typy, tak to nutně je demonstrace výhod statických typů)...
Neni to demonstrace vyhod statickych typu, pokud je haskell jediny jazyk, ktery to umi. V takovem pripade je to demonstrace vyhoda haskellu. Na tom zalozene tvrzeni o statickych typech je argumentacni klam, predcasna generalizace.
Ale houby, umi to s drobnymi rozdily kopec jazyku (o Scale a F# tu uz rec sla), ten Haskell se proste bere jako "zlaty standard", co ho navic pomalu kazdy zna.
Zatim to spis vypada na vlastnost funkcionalnich jazyku, porad cekam na nejaky normalni. :-)
Normální? Oba jsou to multiparadigmatické jazyky.
Normalni, to jest ty, ktere se bezne pouzivaji v komercni praxi.
Tak to jsou normální.
:-)) Ohledne moznosti zneuznaneho a neuspesneho haskellu mi muzes veset buliky na nos, ohledne bezne pouzivanych jazyku v komercni sfere nikoliv.

To je takovy problem se podivat do inzeratu? Scala neni zdaleka takova masovka jako trebas Java, ale misto se najde bez problemu. Pokud zuzis sve pozadavky na "zajimava prace", tak se ten pomer navic dost zlepsi...
Pro mě jsou zajímavé zakázky. Nikdo z našich klientů (podniková sféra) takové obskurnosti nepoptává.
Jinymi slovy - generalizujes sve zkusenosti s patlanim v jedne oblasti na cely obor.
Nejen sve. Jak uz jsem tu uvedl, pragmaticky me zajima jen to, co ma pro me prinos, ted a nebo v budoucnu.
To asi zůstaneš hodně omezenej.
Prave naopak.
Tak jak jinak chceš fachidiocii říkat?
Urážkami na tom nic nezměníš.

Pokud chceš něco dobrého a hodnotného tvořit, je lepší umět dva, tři praktické jazyky do hloubky (a i to je dnes moc, aby sis u všech udržoval expertní znalosti, včetně souvisejícího ekosystému), než se povrchně zabývat kdejakou obskurností, která má v praxi minimální využití. Rozdíl mezi mnou a tebou je jako rozdíl mezi praktickým hudebníkem a hudebním kritikem. Mě zajímá praktická stránka věci, to co mi pomůže reálně a dobře tvořit. A chceš-li to nazývat idiocií, prosím. Co ale říct o vás, co žijete v přesvědčení, že když se program podaří zkompilovat, tak je v podstatě hotovo. Vůbec netušíte, co obnáší praktická tvorba software, který není jen na hraní. To pochopíte, až se ze školy dostanete do praxe.
Název: Re:Co si myslíte o OOP?
Přispěvatel: Inkvizitor 11. 01. 2019, 10:07:18
Urážkami na tom nic nezměníš.

Pokud chceš něco dobrého a hodnotného tvořit, je lepší umět dva, tři praktické jazyky do hloubky (a i to je dnes moc, aby sis u všech udržoval expertní znalosti, včetně souvisejícího ekosystému), než se povrchně zabývat kdejakou obskurností, která má v praxi minimální využití. Rozdíl mezi mnou a tebou je jako rozdíl mezi praktickým hudebníkem a hudebním kritikem. Mě zajímá praktická stránka věci, to co mi pomůže reálně a dobře tvořit. A chceš-li to nazývat idiocií, prosím. Co ale říct o vás, co žijete v přesvědčení, že když se program podaří zkompilovat, tak je v podstatě hotovo. Vůbec netušíte, co obnáší praktická tvorba software, který není jen na hraní. To pochopíte, až se ze školy dostanete do praxe.

Treba se naucite psat undo jako ja, operator. Sice to dela memory leaky a moc to nefunguje, ale zato mi to trvalo jenom pul dne.
Název: Re:Co si myslíte o OOP?
Přispěvatel: Ondra Satai Nekola 11. 01. 2019, 10:24:14
Tak jsem chtel overit tu haskell ukazku a zjistil, ze haskell je tak okrajovy jazyk, ze neni k dispozici v termuxu. Hledal jsem balicek s nazvem haskell nebo ghc. Seznam balicku: https://pastebin.com/kdfgUFRt To jen upevnuje me presvedceni, ze nema smysl ztracet cas okrajovymi nepodporovanymi jazyky.  Je schopen to nekdo predvest v jinem jazyku ktery je mezi balicky? (je tam kde co, rust, vala, erlang, java, ocaml, golang, clang, racket, ...)  Nebo se jedna ciste o schopnost haskellu, ktera je tu mylne prisuzovana jazykum se statickymi typy?
To je tak pitomá metrika (přítomnost v termuxu) a tak pitomý argument (když je to v Haskellu a opírá se to o statické typy, tak to nutně je demonstrace výhod statických typů)...
Neni to demonstrace vyhod statickych typu, pokud je haskell jediny jazyk, ktery to umi. V takovem pripade je to demonstrace vyhoda haskellu. Na tom zalozene tvrzeni o statickych typech je argumentacni klam, predcasna generalizace.
Ale houby, umi to s drobnymi rozdily kopec jazyku (o Scale a F# tu uz rec sla), ten Haskell se proste bere jako "zlaty standard", co ho navic pomalu kazdy zna.
Zatim to spis vypada na vlastnost funkcionalnich jazyku, porad cekam na nejaky normalni. :-)
Normální? Oba jsou to multiparadigmatické jazyky.
Normalni, to jest ty, ktere se bezne pouzivaji v komercni praxi.
Tak to jsou normální.
:-)) Ohledne moznosti zneuznaneho a neuspesneho haskellu mi muzes veset buliky na nos, ohledne bezne pouzivanych jazyku v komercni sfere nikoliv.

To je takovy problem se podivat do inzeratu? Scala neni zdaleka takova masovka jako trebas Java, ale misto se najde bez problemu. Pokud zuzis sve pozadavky na "zajimava prace", tak se ten pomer navic dost zlepsi...
Pro mě jsou zajímavé zakázky. Nikdo z našich klientů (podniková sféra) takové obskurnosti nepoptává.
Jinymi slovy - generalizujes sve zkusenosti s patlanim v jedne oblasti na cely obor.
Nejen sve. Jak uz jsem tu uvedl, pragmaticky me zajima jen to, co ma pro me prinos, ted a nebo v budoucnu.
To asi zůstaneš hodně omezenej.
Prave naopak.
Tak jak jinak chceš fachidiocii říkat?
Urážkami na tom nic nezměníš.

Pokud chceš něco dobrého a hodnotného tvořit, je lepší umět dva, tři praktické jazyky do hloubky (a i to je dnes moc, aby sis u všech udržoval expertní znalosti, včetně souvisejícího ekosystému), než se povrchně zabývat kdejakou obskurností, která má v praxi minimální využití. Rozdíl mezi mnou a tebou je jako rozdíl mezi praktickým hudebníkem a hudebním kritikem. Mě zajímá praktická stránka věci, to co mi pomůže reálně a dobře tvořit. A chceš-li to nazývat idiocií, prosím. Co ale říct o vás, co žijete v přesvědčení, že když se program podaří zkompilovat, tak je v podstatě hotovo. Vůbec netušíte, co obnáší praktická tvorba software, který není jen na hraní. To pochopíte, až se ze školy dostanete do praxe.

A jeste si zjistit rozdil mezi idiocii a fachidiocii....
Název: Re:Co si myslíte o OOP?
Přispěvatel: Ondra Satai Nekola 11. 01. 2019, 10:30:53
Co ale říct o vás, co žijete v přesvědčení, že když se program podaří zkompilovat, tak je v podstatě hotovo.

Dobrej hastros.

Vůbec netušíte, co obnáší praktická tvorba software, který není jen na hraní. To pochopíte, až se ze školy dostanete do praxe.

A na to jsi prisel jak?
Název: Re:Co si myslíte o OOP?
Přispěvatel: Mirek Prýmek 11. 01. 2019, 10:52:22
Pokud chceš něco dobrého a hodnotného tvořit, je lepší umět dva, tři praktické jazyky do hloubky [...] než se povrchně zabývat kdejakou obskurností, která má v praxi minimální využití. [...] Mě zajímá praktická stránka věci, to co mi pomůže reálně a dobře tvořit.
Mě taky zajímá praktická stránka věci. A v praxi jsem zjistil, že je dobré znát ne dva až tři jazyky, ale především dvě až tři paradigmata. Protože znalost nového paradigmatu ti úplně změní perspektivu, pohled na věc. Zkušenost s jinými paradigmaty tě může výrazně inspirovat k lepším řešením nebo se vyvarovat chyb, které jsou způsobené tím, že máš klapky na očích (známé "když mám v ruce kladivo, všechno je hřebík").

Např. alespoň letmá znalost funkcionálního programování je afaik výborná proto, že se naučíš explicitně přemýšlet nad stavem - co s ním děláš, kam ho posíláš, kde se mění, kde se nemění atd. I v nefunkcionálním jazyce to může výrazně pomoct vyhnout se race conditions, zbytečným zámkům apod.

A právě proto je dobré třeba ten Haskell (nebo Elixir, Prolog, ...) alespoň párkrát zkusit, něco málo si v tom napsat. Pohrdat jím stylem "já jsem ten fachman, vy blbečcí akademičtí, mě vaše hračky nezajímají, protože vás musím živit" je hodně stupidní a omezený. Podobně stupidní jako "vy lopaty PHPkový si vykládejte co chcete, my jsme zasvěcenci páté úrovně haskellové gnóze!" Ne nadarmo byla po tisíciletí pýcha chápaná jako největší hřích...
Název: Re:co si myslite o oop?
Přispěvatel: PetrM 11. 01. 2019, 11:01:57
Vrátil bych se trochu na začátek.

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.

Abstrakci můžeš mít i bez OOP, nebo snad v tomhle vidíš objekty?
Kód: [Vybrat]
typedef int delkaStrany_t;
typedef int obvod_t;

obvod_t obvodObdelniku( delkaStrany_t stranaA, delkaStrany_t stranaB) {
   return 2 * (obvod_t) soucetDelek( stranaA, stranaB );
}

...

delkaStrany_t SoucetDelek( delkaStrany_t stranaA, delkaStrany_t stranaB) {
  return (delkaStrany_t) soucetIntu( (int) stranaA, (int) stranaB );
}

...

int soucetIntu( int a, int b ) {
  return a + b;
}

Na druhou stranu, OOP ti dává plno možností. V komunikaci (zapouzdříš si socket + vlákno a jenom sekáš instance), v GUI (widgety a obrazovky), moduly (modul = třída implementující nějaký API), ...

A zmíněný čas? To je přece stavová proměnná a reaguje na podněty okolního systému. Takže každý objekt má svoje vlastní chápání času, který se může od ostatních objektů lišit (např. kontejner neví nic o tom, že zrovna jím vlastněný objekt něco dělá, v jeho kontextu čas "tikne" třeba vytvořením/zrušením objektu uvnitř) a čas objektu je z principu nespojitý (minimálně změna jednoho bitu, což je nelineární). Tož asi tak...

Navíc OOP princip se dá využít kdekoliv. Pamatuješ originál Transport Tycoon? Tam jsem tipoval, že je tam nějaká třída "vozidlo", od ní odvozný třídy jako "autobus", "vlak", "letadlo",... No a pak jsem se dočetl, že to je psaný v ASM. A já něco z toho používám i v C ( popis např. v https://www.root.cz/knihy/object-oriented-programming-in-ansi-c/ ) a i C++ původně vzniklo jako prekompiler pro C.

Holt je to jenom nástroj a záleží na nás, jak, k čemu a v čem ho použijem. Zbytek diskuse jsou debaty o víte čem...

Mě taky zajímá praktická stránka věci. A v praxi jsem zjistil, že je dobré znát ne dva až tři jazyky, ale především dvě až tři paradigmata. Protože znalost nového paradigmatu ti úplně změní perspektivu, pohled na věc. Zkušenost s jinými paradigmaty tě může výrazně inspirovat k lepším řešením nebo se vyvarovat chyb, které jsou způsobené tím, že máš klapky na očích (známé "když mám v ruce kladivo, všechno je hřebík").


Souhlas ;)

P.S. Kadete, k těm typům. Je lepší hodinu bojovat se statickými typy, než týden hledat, proč se to číslo chová divně. Schválně, mám SessionID 231479973001 a používám to jako číslo ve formátu UINT64. Co dostanu, pokud ho první knihovna interně konvertuje do UINT32 (protože na ni od dob 32b nikdo nesáhl), druhá do INT64 (protože signed považuje za nativní formát) a pak zpátky do UINT64? Jaký budeš mít SessionID na konci toho procesu? A uspokojí tě to? Ale co, hlavní je, že ani ty tři warningy při buildu nedostaneš... A to se počítá.
Takže na začátku parsování/verifikace dat na jednom místě, následná logika pak ví, že data jsou validní a jak jsou zabalený. A pokud jsou zabalený jinak, kompilátor to zatepla nabonzuje...
Název: Re:Co si myslíte o OOP?
Přispěvatel: Ondra Satai Nekola 11. 01. 2019, 11:14:21
Pokud chceš něco dobrého a hodnotného tvořit, je lepší umět dva, tři praktické jazyky do hloubky [...] než se povrchně zabývat kdejakou obskurností, která má v praxi minimální využití. [...] Mě zajímá praktická stránka věci, to co mi pomůže reálně a dobře tvořit.
Mě taky zajímá praktická stránka věci. A v praxi jsem zjistil, že je dobré znát ne dva až tři jazyky, ale především dvě až tři paradigmata. Protože znalost nového paradigmatu ti úplně změní perspektivu, pohled na věc. Zkušenost s jinými paradigmaty tě může výrazně inspirovat k lepším řešením nebo se vyvarovat chyb, které jsou způsobené tím, že máš klapky na očích (známé "když mám v ruce kladivo, všechno je hřebík").

Např. alespoň letmá znalost funkcionálního programování je afaik výborná proto, že se naučíš explicitně přemýšlet nad stavem - co s ním děláš, kam ho posíláš, kde se mění, kde se nemění atd. I v nefunkcionálním jazyce to může výrazně pomoct vyhnout se race conditions, zbytečným zámkům apod.

A právě proto je dobré třeba ten Haskell (nebo Elixir, Prolog, ...) alespoň párkrát zkusit, něco málo si v tom napsat. Pohrdat jím stylem "já jsem ten fachman, vy blbečcí akademičtí, mě vaše hračky nezajímají, protože vás musím živit" je hodně stupidní a omezený. Podobně stupidní jako "vy lopaty PHPkový si vykládejte co chcete, my jsme zasvěcenci páté úrovně haskellové gnóze!" Ne nadarmo byla po tisíciletí pýcha chápaná jako největší hřích...

Ono jak se rika... neni nic praktictejsiho nez dobra teorie.
Název: Re:co si myslite o oop?
Přispěvatel: v 11. 01. 2019, 11:17:22
Takže na začátku parsování/verifikace dat na jednom místě, následná logika pak ví, že data jsou validní a jak jsou zabalený. A pokud jsou zabalený jinak, kompilátor to zatepla nabonzuje...
tohle je asi ústřední filosofie silně typového funkcionálního programování "make invalid state unrepresentable"
Název: Re:co si myslite o oop?
Přispěvatel: PetrM 11. 01. 2019, 12:09:37
tohle je asi ústřední filosofie silně typového funkcionálního programování "make invalid state unrepresentable"

Tak ono furt platí, že
1) Jak dostanu z vnějšku nějakou hodnot, musím ji validovat -> validátor / parser tam stejně bude
2) Chybu mám zachytit a ošetřit co nejdřív.
3) Věci by měly být řešeny na jednom místě (SRP)
4) Když vím, že tam bude UserID jako int16, nepotřebuju v hloubi aplikace řešit, co se stane, když tam náhodou bude string nebo float
5) Nemusím ukládat a zpracovávat, co nepotřebuju
6) Defenzivní programování - lepší nezkompilovat / dostat warning, než doufat, že je to OK a nic se nerozbije, pokud tam přijde nějaká "podivná" hodnota
7) Stejně dřív nebo pozděj finální typ potřebuju - při prvním výpočtu s daty (Error: Multiply is not defined with strings), při první operaci se stringem nad polem intů,...
8) Za sebe, pokud si mám vybrat mezi
Kód: [Vybrat]

int fn( int a, str b) {
  assert(a > 0);
}
nebo
Kód: [Vybrat]
fn(a, b) {
  assert(isInt(a));
  assert(isString(b));
  assert(a > 0);
}
,
volím první možnost - nejenom že je s tím míň práce, ale 2/3 testů tam zůstanou a po vypnutí asserce v release.
9) Implicitní typy můžou člověku pěkně zavařit.
10) Pokud jde o specifický data, je tady typedef. Pokud ho (zase to SRP) na jednom místě změním, kompilátor vybleje dobrý checklist, co je nekompatibilní a mám to změnit.
11) Pokud člověk potřebuje, netypovaný data protáhne vždycky. Jako string, jako variant, jako obecný pointer, zabalený do třídy, jako union,...
12) Nějak furt nevidím smysl v preferenci stavu, když mám data a nevím, v jakým formátu
Název: Re:Co si myslíte o OOP?
Přispěvatel: Kit 11. 01. 2019, 12:15:58
Mě taky zajímá praktická stránka věci. A v praxi jsem zjistil, že je dobré znát ne dva až tři jazyky, ale především dvě až tři paradigmata. Protože znalost nového paradigmatu ti úplně změní perspektivu, pohled na věc. Zkušenost s jinými paradigmaty tě může výrazně inspirovat k lepším řešením nebo se vyvarovat chyb, které jsou způsobené tím, že máš klapky na očích (známé "když mám v ruce kladivo, všechno je hřebík").

Je dobré ta paradigmata nejen znát, ale umět je i rozlišovat a vědět, pro které vrstvy a případy užití se hodí které. Píši nejen objektově v PHP, ale i strukturovaně v PL/SQL a funkcionálně v XSLT. Definování, co kam patří a kam ne, je poměrně strategickou úlohou. Sort se dá použít ve všech třech, ale pro každou vrstvu aplikace a každý typ dat je třeba rozhodnout, který z nich použít, protože univerzálně to vyřešit nelze. Pokud má být každý pátý řádek tabulky v prohlížeči zvýrazněný, tak se to dá udělat nejen zmíněnými nástroji, ale i v CSS. Pokud použijeme vhodný nástroj, usnadní nám do budoucí údržbu aplikace a sníží v ní počet WTF.
Název: Re:co si myslite o oop?
Přispěvatel: Kit 11. 01. 2019, 12:49:05
Tak ono furt platí, že
1) Jak dostanu z vnějšku nějakou hodnot, musím ji validovat -> validátor / parser tam stejně bude
2) Chybu mám zachytit a ošetřit co nejdřív.
3) Věci by měly být řešeny na jednom místě (SRP)

Ty první dva body jsou poněkud v rozporu s bodem třetím. Data z vnějšku klidně nechám probublat až do objektu, který je v zvaliduje až ve chvíli, kdy s těmi daty potřebuje pracovat. Tedy naopak je validuji co nejpozději. Pokud ta data proudí z více zdrojů, tak jsou validována právě v tom jednom objektu, který se stará právě jen o tento typ dat. O data jiného typu se stará jiný objekt, i když jsou součástí toho jednoho požadavku.

Tento přístup mi umožňují dělat poměrně jednoduché kontrolery, které se o validaci nestarají, ale pouze se rozhodují, které komponenty modelu použijí a jak je zkombinují.
Název: Re:co si myslite o oop?
Přispěvatel: Kit 11. 01. 2019, 12:59:13
8) Za sebe, pokud si mám vybrat mezi
Kód: [Vybrat]

int fn( int a, str b) {
  assert(a > 0);
}
nebo
Kód: [Vybrat]
fn(a, b) {
  assert(isInt(a));
  assert(isString(b));
  assert(a > 0);
}
,
volím první možnost - nejenom že je s tím míň práce, ale 2/3 testů tam zůstanou a po vypnutí asserce v release.

Ve skutečnosti však ta tvá první možnost vypadá takhle:
Kód: [Vybrat]
int fn( int a, str b) {
  assert(a > 0);
}

assert(isInt(a));
assert(isString(b));
fn(a, b);

takže jsi nic neušetřil, ale úlohu sis zesložitil. Odebral jsi funkci odpovědnost za validaci vstupu, ale zaměstnal jsi vstupní parser. Pokud budeš chtít změnit int na float, budeš muset měnit funkci i parser. Když změníš parser, budeš muset upravit i ostatní funkce, které jsou na datech z toho parseru závislé a v tuto chvíli akceptují stále jen ten int.
Název: Re:Co si myslíte o OOP?
Přispěvatel: operator 11. 01. 2019, 13:40:55
Urážkami na tom nic nezměníš.

Pokud chceš něco dobrého a hodnotného tvořit, je lepší umět dva, tři praktické jazyky do hloubky (a i to je dnes moc, aby sis u všech udržoval expertní znalosti, včetně souvisejícího ekosystému), než se povrchně zabývat kdejakou obskurností, která má v praxi minimální využití. Rozdíl mezi mnou a tebou je jako rozdíl mezi praktickým hudebníkem a hudebním kritikem. Mě zajímá praktická stránka věci, to co mi pomůže reálně a dobře tvořit. A chceš-li to nazývat idiocií, prosím. Co ale říct o vás, co žijete v přesvědčení, že když se program podaří zkompilovat, tak je v podstatě hotovo. Vůbec netušíte, co obnáší praktická tvorba software, který není jen na hraní. To pochopíte, až se ze školy dostanete do praxe.

Treba se naucite psat undo jako ja, operator. Sice to dela memory leaky a moc to nefunguje, ale zato mi to trvalo jenom pul dne.
Treba se naucite rozumet internim procesum jazyka, vyuzivat je a nebudete z toho vydeseny jako inkvizitor :-).
Název: Re:co si myslite o oop?
Přispěvatel: Peva 11. 01. 2019, 13:45:34
8) Za sebe, pokud si mám vybrat mezi
Kód: [Vybrat]

int fn( int a, str b) {
  assert(a > 0);
}
nebo
Kód: [Vybrat]
fn(a, b) {
  assert(isInt(a));
  assert(isString(b));
  assert(a > 0);
}
,
volím první možnost - nejenom že je s tím míň práce, ale 2/3 testů tam zůstanou a po vypnutí asserce v release.

Ve skutečnosti však ta tvá první možnost vypadá takhle:
Kód: [Vybrat]
int fn( int a, str b) {
  assert(a > 0);
}

assert(isInt(a));
assert(isString(b));
fn(a, b);

takže jsi nic neušetřil, ale úlohu sis zesložitil. Odebral jsi funkci odpovědnost za validaci vstupu, ale zaměstnal jsi vstupní parser. Pokud budeš chtít změnit int na float, budeš muset měnit funkci i parser. Když změníš parser, budeš muset upravit i ostatní funkce, které jsou na datech z toho parseru závislé a v tuto chvíli akceptují stále jen ten int.

Celkem pěkný příklad, který by navozoval dojem, že je vhodnější používat variantu 2. No, je to ale dáno tím, že se předpokládá, že s údaji bude po business stránce pracovat pouze ta JEDNA funkce. Jenže tak to ve skutečnosti nebude. Business logika je často komplexní a je rozprostřena do více method/objektů/funkcí....potom při variantě 2 je nutné  nějakým způsobem harmonizovat tu validaci...V tomto případě už přináší řešení 1 nesporné výhody.
Název: Re:co si myslite o oop?
Přispěvatel: PetrM 11. 01. 2019, 13:56:21
Ty první dva body jsou poněkud v rozporu s bodem třetím...

a) Záleží na situaci. Můžu mít M zdrojů a N zpracovatelů. Model 1:N je výhodnější se zpracováním na vstupu, N:1 u zpracovatele, zbytek někde mezi.
b) Pokud data předávám jako strukturu dat daných typů, provedu její naplnění při validaci (kdy stejně do dat sahám). Za předpokladu, že interně mám jako "flags" pole 32 bitů, nedává přece smysl interně jednou posílat string "acd" pro bity {0, 2, 3} a podruhý pro stejnou situaci číslo 13. Takže definováno je to na jednom místě - definice struktury. Pak je to definováno pro parsování vstupu ( to je pro OOP ideální - podle typu vstupu a typu dat si vyberu parser). Rozdíl je v tom, že v kontroléru pak taky neřeším typ dat - je prostě vždycky pro stejnou položku stejný, tak s s tím nezalamuju.

Prostě furt nevidím výhodu toho, že mám data a nevím, jak jsou zabalený.

Ve skutečnosti však ta tvá první možnost vypadá takhle..
Houbeles, nechápeš princip. U dynamickýho typování víš maximálně ty, co ti přijde za data. Většinou ani ty ne. A kompilátor/interpret se musí rozhodovat za běhu - mít připravený všechny varianty a kontrolní mechanismus na všechno. Takže mám menší a rychlejší kód.
Po zkompilování už se typ neřeší, je natvrdo zadrátovaný. A není ani důvod. Takže assert před vůbec není. Je řev kompilátoru, pokud se pokusím při parsování nacpat string do intu. Pak už to hlídat nemusím a za běhu nepadá "nevím co se stringem v proměnné", maximálně se ozve parser na vstupu, že se mu něco nelíbí.
A díky přetěžování funkcí vlastně ani nemusím řešit, čím to parsuju - podle toho, jaký typ chci, vybere kompilátor sám příslušnou parsovací funkci na vstupu.

Jenom si prostě při deklaraci interních řad řeknu, do čeho mají být zabalený a jak zabalený mají být vstupy/výstupy funkcí. Pokud to změním, dostanu při buildu echo, co jsem zapomněl nebo mám zkontrolovat. Ten boj proti nechápu - pokud teda dotyčný zná základy (jak se ukládá int, jak strimg, jak float, co  je to pointer,...) a tuší, jaký typy jsou k dispozici a co se pro jeho data hodí.
Název: Re:Co si myslíte o OOP?
Přispěvatel: UF 11. 01. 2019, 13:57:08
neuveritelny - vy se musite skarade nudit
Název: Re:Co si myslíte o OOP?
Přispěvatel: operator 11. 01. 2019, 13:59:26
Pokud chceš něco dobrého a hodnotného tvořit, je lepší umět dva, tři praktické jazyky do hloubky [...] než se povrchně zabývat kdejakou obskurností, která má v praxi minimální využití. [...] Mě zajímá praktická stránka věci, to co mi pomůže reálně a dobře tvořit.
Mě taky zajímá praktická stránka věci. A v praxi jsem zjistil, že je dobré znát ne dva až tři jazyky, ale především dvě až tři paradigmata. Protože znalost nového paradigmatu ti úplně změní perspektivu, pohled na věc. Zkušenost s jinými paradigmaty tě může výrazně inspirovat k lepším řešením nebo se vyvarovat chyb, které jsou způsobené tím, že máš klapky na očích (známé "když mám v ruce kladivo, všechno je hřebík").

Např. alespoň letmá znalost funkcionálního programování je afaik výborná proto, že se naučíš explicitně přemýšlet nad stavem - co s ním děláš, kam ho posíláš, kde se mění, kde se nemění atd. I v nefunkcionálním jazyce to může výrazně pomoct vyhnout se race conditions, zbytečným zámkům apod.

A právě proto je dobré třeba ten Haskell (nebo Elixir, Prolog, ...) alespoň párkrát zkusit, něco málo si v tom napsat. Pohrdat jím stylem "já jsem ten fachman, vy blbečcí akademičtí, mě vaše hračky nezajímají, protože vás musím živit" je hodně stupidní a omezený. Podobně stupidní jako "vy lopaty PHPkový si vykládejte co chcete, my jsme zasvěcenci páté úrovně haskellové gnóze!" Ne nadarmo byla po tisíciletí pýcha chápaná jako největší hřích...
To je pravda, ale jen castecne. Za prve v praxi potrebujes znat vice jazyku, protoze zadny univerzalni neexistuje. Ale cim mene jich je, tim lepe jim muzes rozumet. Za druhe ruzne paradigmata jsou uzitecna, ale nepotrebujes si kvuli tomu povrchne hrat s hromadou prakticky nevyuzitelnych jazyku. V tom je prave dobry python, protoze ti umoznuje jednotliva paradigmata podle potreby prirozene kombinovat. Viz pocatek diskuse a narky nad tim, ze je to spatne a jazyk to komplikuje. Za treti netyka se to jen paradigmat, ale i metodik vyvoje, a plati to i na tady odsuzovane dynamicke rysy jazyku, kterych se tu nekteri desi. I programovani v dynamickem jazyce potrebuje jiny pohled na vec. Mozna vic jiny, nez funkcionalni programovani. Odpor vuci dynamickym jazykum zazniva od tech, kteri se v nich pokousi programovat staticky, protoze to jinak neumi.
Název: Re:Co si myslíte o OOP?
Přispěvatel: PetrM 11. 01. 2019, 14:17:44
To je pravda, ale jen castecne. Za prve v praxi potrebujes znat vice jazyku, protoze zadny univerzalni neexistuje. Ale cim mene jich je, tim lepe jim muzes rozumet. Za druhe ruzne paradigmata jsou uzitecna, ale nepotrebujes si kvuli tomu povrchne hrat s hromadou prakticky nevyuzitelnych jazyku. V tom je prave dobry python, protoze ti umoznuje jednotliva paradigmata podle potreby prirozene kombinovat. Viz pocatek diskuse a narky nad tim, ze je to spatne a jazyk to komplikuje. Za treti netyka se to jen paradigmat, ale i metodik vyvoje, a plati to i na tady odsuzovane dynamicke rysy jazyku, kterych se tu nekteri desi. I programovani v dynamickem jazyce potrebuje jiny pohled na vec. Mozna vic jiny, nez funkcionalni programovani. Odpor vuci dynamickym jazykum zazniva od tech, kteri se v nich pokousi programovat staticky, protoze to jinak neumi.

Jenomže jsou jazyky, kde je něco neuvěřitelně složitý nebo komplikovaný a pokud nemáš jistotu, že i přes ty komplikace je to to nejlepší, tak to paradigma prostě nepoužiješ. Ono objektově se dá jet i v ASM, když na věc přijde, ale ASM je neskutečný opruz sám o sobě a když tam dáš něco navíc, tak je to ještě větší peklo.

A někdy i jiný jazyk má interní funkcionalitu, která se ti vybaví při práci v jiným jazyku - místo hledání jednorázovýho řešení si uděláš reusable modul, který simuluje chování jinýho jazyka (mám třeba v Cčku obdobu množin z Pascalu, ale přeloženou s BitBandem pro Cortexy, systém výjimek z C++, cykly jako foreach pro seznam,...). Takže víc jazyků i víc paradigmat se ti vrátí.
Název: Re:Co si myslíte o OOP?
Přispěvatel: Peva 11. 01. 2019, 14:36:27
Odpor vuci dynamickym jazykum zazniva od tech, kteri se v nich pokousi programovat staticky, protoze to jinak neumi.
Jenže svět, který se snažíme v IT modelovat/automatizovat má spíše charakter statických typů....Nikdo se nejmenuje 123456 nebo 10.60 a na výplatu dostanu vždy nějakou částku a ne stokorunčeských...takže oprávněný požadavek dynamických typů zpravidla zaznívá jen tehdy, když někdo něco generalizoval-sloučil. Navíc zákazník zpravidla požaduje ukládat data to staticky typovaných databází...v tomto případě nedává moc smysl zavádět do systému nějakou dynamickou složku.
Název: Re:co si myslite o oop?
Přispěvatel: Kadet 11. 01. 2019, 15:05:18

P.S. Kadete, k těm typům. Je lepší hodinu bojovat se statickými typy, než týden hledat, proč se to číslo chová divně. Schválně, mám SessionID 231479973001 a používám to jako číslo ve formátu UINT64. Co dostanu, pokud ho první knihovna interně konvertuje do UINT32 (protože na ni od dob 32b nikdo nesáhl), druhá do INT64 (protože signed považuje za nativní formát) a pak zpátky do UINT64? Jaký budeš mít SessionID na konci toho procesu? A uspokojí tě to? Ale co, hlavní je, že ani ty tři warningy při buildu nedostaneš... A to se počítá.
Takže na začátku parsování/verifikace dat na jednom místě, následná logika pak ví, že data jsou validní a jak jsou zabalený. A pokud jsou zabalený jinak, kompilátor to zatepla nabonzuje...

Bez urazky, ale kdyz jsi prase a pouzivas praseci knihovny ktery ti hloupy session id prezvejka do tolika formatu, tak se nedivim, ze potrebujes statickou kontrolu. Ja bych taky odmitnul pracovat na prasecim Python projektu, kdybych tam videl praseciny podobnyho typu. Taky bych byl radsi kdyby to bylo staticky otypovany.

Jenze ja bych vzal ten prasecak, pokusil se najit co se to snazi delat, tj. najit vstupy a vystupy a jak to komunikuje s okolnim svetem, a vyhazet 90% toho chliva ven.

Presne to taky delam ve svy praxi. V tvym pripade bych vyhazel vsechny th black box knihovnh co mi znasilnujou session id, session id bych nahradil pouhym stringem, protoze nepotrebuju delat aritmetiku ani pocitatncialni rovnice se session id.

Kod bych zredukoval na desetinu mozna min ve zlomku casu. To co ostatnim trva mesice, ja dodavam do tydne. Protoze dokazu rychle najit co je v programu potreba a co je balast.

Kdyz to dotahnu do konce a klient je spokojenej muzu zacit konecne optimalizovat. Takze vezmu kritickou sekci a prepisu ji v Cythonu, v C nebo necim podobnym. Nebo napisu kritickou sekci jako cistej C, java program a pospojuju to unix pipelinou. Je mi to prakticky jedno. A vis co. Dneska jsou komoy tak rychly, ze klient radsi zaplati za dve dalsi masiny misto prepisu do rychlejsiho jazyka.
Název: Re:co si myslite o oop?
Přispěvatel: PetrM 11. 01. 2019, 15:34:48
Bez urazky, ale kdyz jsi prase a pouzivas praseci knihovny ktery ti hloupy session id prezvejka do tolika formatu, tak se nedivim, ze potrebujes statickou kontrolu...

Já preferuju vlastní kód, ale nikdo ti nezaplatí vývoj vlastních knihoven. Vždycky používáš kód třetí strany a inspekce od kompilátoru se vždycky hodí (resp. je zadarmo).  "Model světa" totiž musíš přechrchlat na byty, aby jim stroj rozuměl a to jsou najednou chyby jak víno. Zaokrouhlování u floatů, přetečení nebo podtečení hodnot,... Prostě je fajn si říct, že to bude tak a ještě lepší si to restriktivně vynutit.

Btw, nemusí to být jenom staticky linkovaný knihovny, může to být kombinace několika jazyků, jedna z těch věcí může běžet na jiným fyzickým stroji,... A o to je to zákařnější - není nad to, když server má 64b hodnoty, klient 32b hodnoty a vývojář se diví. A pokud nezná typy (a s tím i tyhle pasti), tak si pěkně namlátí hubu.

Můj příklad je jenom malinká ukázka, jak to dopadá, když prasata ignorujou typy:
Krok | Typ | Dekadicky | Hexadecimálně | Podrobnosti
0 | uint64 | 231479973001 | 0x0000000035E5481489 | hodnota má 40b
1 | uint32 | 3846706313 | 0xE5481489 | přišli jsme o horních 8b hodnoty
2 | int64 | -448260983 | 0xFFFFFFFFE5481489 | bit 31 = 1 -> záporné číslo
3 | uint64 | 18446744072813029651 | 0xFFFFFFFFE5481489 | Interpretováno jako UINT64

Další past je třeba float - currency. Jak to má sakra kompilátor/interpreter poznat jenom podle toho, že jsou v parsovaným stringu číslice a mezi nima čárka? To jako podle toho, že je před tím "price="? A každej typ se přitom chová jinak...

Zkrátka, volnost typu = volnost kompilátoru = volnost chování výsledné aplikace. Typ je totiž nedílná součást popisu dat. Když kompilátor neví, co použít a jenom tak tam něco práskne, tak je něco blbě v principu.
Název: Re:Co si myslíte o OOP?
Přispěvatel: Ondrej Nemecek 11. 01. 2019, 15:54:15
Nejlepší jsou silně typované jazyky s pozdní vazbou  ;D

Akademici mají na slunci taky své místo, není vše jen o praxi.

A už se nehádejte, stejně to jde odnikud nikam :)
Název: Re:co si myslite o oop?
Přispěvatel: Kadet 11. 01. 2019, 17:54:20
Bez urazky, ale kdyz jsi prase a pouzivas praseci knihovny ktery ti hloupy session id prezvejka do tolika formatu, tak se nedivim, ze potrebujes statickou kontrolu...

Já preferuju vlastní kód, ale nikdo ti nezaplatí vývoj vlastních knihoven. Vždycky používáš kód třetí strany a inspekce od kompilátoru se vždycky hodí (resp. je zadarmo).  "Model světa" totiž musíš přechrchlat na byty, aby jim stroj rozuměl a to jsou najednou chyby jak víno. Zaokrouhlování u floatů, přetečení nebo podtečení hodnot,... Prostě je fajn si říct, že to bude tak a ještě lepší si to restriktivně vynutit.

Btw, nemusí to být jenom staticky linkovaný knihovny, může to být kombinace několika jazyků, jedna z těch věcí může běžet na jiným fyzickým stroji,... A o to je to zákařnější - není nad to, když server má 64b hodnoty, klient 32b hodnoty a vývojář se diví. A pokud nezná typy (a s tím i tyhle pasti), tak si pěkně namlátí hubu.

Můj příklad je jenom malinká ukázka, jak to dopadá, když prasata ignorujou typy:
Krok | Typ | Dekadicky | Hexadecimálně | Podrobnosti
0 | uint64 | 231479973001 | 0x0000000035E5481489 | hodnota má 40b
1 | uint32 | 3846706313 | 0xE5481489 | přišli jsme o horních 8b hodnoty
2 | int64 | -448260983 | 0xFFFFFFFFE5481489 | bit 31 = 1 -> záporné číslo
3 | uint64 | 18446744072813029651 | 0xFFFFFFFFE5481489 | Interpretováno jako UINT64

Další past je třeba float - currency. Jak to má sakra kompilátor/interpreter poznat jenom podle toho, že jsou v parsovaným stringu číslice a mezi nima čárka? To jako podle toho, že je před tím "price="? A každej typ se přitom chová jinak...

Zkrátka, volnost typu = volnost kompilátoru = volnost chování výsledné aplikace. Typ je totiž nedílná součást popisu dat. Když kompilátor neví, co použít a jenom tak tam něco práskne, tak je něco blbě v principu.

Opet, pocitas snad integraly a derivace se session id? Ja ne, proto to necham jako string a nic vic neresim.

Floaty maji velmi omezeny pouziti v byznys aplikacich. Penize nikdy nereprezentujes jako float pokud nejsi prase.

Kdyz teda operujes na urovni systemu a ne jen pouhyho izolovanyho programu, jako v tvym priklade klientu a serveru, tak ti kompilator v nicem nepomuze. Ten zkontroluje jen ty casti, ale ne celek. Opet, pokud si prase a nedokazes zajistit ze komunikacni protokol mezi podsystemy je spravne, nepomuze ti kompilator ani panenka maria.

Dale, Typ v beznych prog. jazycich je dost omezena pomucka. Pomuze ti oddelit string od cisla, ale nepomuze ti oddelit zaporny cislo od kladnyho cisla. Taky se ti jednoho krasnyho dne muze stat ze ti nekdo zacne posilat negativni hmotnosti tvych zakazniku a typovej system bude drzet hubu.

Název: Re:co si myslite o oop?
Přispěvatel: agent 11. 01. 2019, 18:16:36
...Kdyz to dotahnu do konce a klient je spokojenej muzu zacit konecne optimalizovat....
Tohle mě zaujalo.
Kdo ti tu optimalizaci zaplatí, pokud je klient už spokojený s právě hotovou verzí aplikace?
Realita te taková, že jakmile má projekťák od zákazníka akceptaci (za co nejméň nákladů = první verze se kterou je zákazník spokojený), předá to k fakturaci a ty dostaneš jinou práci.
Název: Re:co si myslite o oop?
Přispěvatel: BoneFlute 11. 01. 2019, 18:19:12
Tak ono furt platí, že
1) Jak dostanu z vnějšku nějakou hodnot, musím ji validovat -> validátor / parser tam stejně bude
2) Chybu mám zachytit a ošetřit co nejdřív.
3) Věci by měly být řešeny na jednom místě (SRP)

Ty první dva body jsou poněkud v rozporu s bodem třetím. Data z vnějšku klidně nechám probublat až do objektu, který je v zvaliduje až ve chvíli, kdy s těmi daty potřebuje pracovat. Tedy naopak je validuji co nejpozději. Pokud ta data proudí z více zdrojů, tak jsou validována právě v tom jednom objektu, který se stará právě jen o tento typ dat. O data jiného typu se stará jiný objekt, i když jsou součástí toho jednoho požadavku.

Tento přístup mi umožňují dělat poměrně jednoduché kontrolery, které se o validaci nestarají, ale pouze se rozhodují, které komponenty modelu použijí a jak je zkombinují.
Ano. A je to velmi špatně.
Název: Re:Co si myslíte o OOP?
Přispěvatel: BoneFlute 11. 01. 2019, 18:33:31
Ja si mezitim dovolim predvest moznost typove kontroly u dynamickeho jazyka.
Kód: [Vybrat]
~ $ mypy typehint.py
typehint.py:6: error: Argument 1 to "inc" has incompatible type "str"; expected "int"
~ $ cat typehint.py
def inc(x:int)->int:
    return x+1

if  __name__ == '__main__':
    print(inc(3))
    print(inc('4'))
~ $ mypy typehint.py
typehint.py:6: error: Argument 1 to "inc" has incompatible type "str"; expected "int"

Tohle mi přijde jako fajn řešení, kdy mohu "odložit" statickou kontrolu. Užitečná informace. Jsem o pythonu nevěděl. Dík.
Název: Re:co si myslite o oop?
Přispěvatel: Kadet 11. 01. 2019, 19:00:49
...Kdyz to dotahnu do konce a klient je spokojenej muzu zacit konecne optimalizovat....
Tohle mě zaujalo.
Kdo ti tu optimalizaci zaplatí, pokud je klient už spokojený s právě hotovou verzí aplikace?
Realita te taková, že jakmile má projekťák od zákazníka akceptaci (za co nejméň nákladů = první verze se kterou je zákazník spokojený), předá to k fakturaci a ty dostaneš jinou práci.

Proc by mi ji mel nekdo platit? Chces snad podojit toho zakaznika o vic penez?

Kdyz je spokojenej a prebira zodpovednost za beh a ja uz s tim nemam nic spolecnyho tak se jde na dalsi projekt. Klient je spokojenej, ja jsem spokojenej protoze jsem dostal dobrou referenci protoze jsem dodal funkcionalitu 10x rychleji nez nekdo kdo se snazil to naprcat v haskellu od zacatku.

Kdyz chce abych to drzel v chodu, tak mu reknu, ze chci nektery casti prepsat, treba do statickyho jazyka, abych se v tom za rok vyznal. Takze pokud po me chce drzet to v chodu tak at kouka zaplatit za zestabilizovani programu. Jinak to muzu odmitnout.
Název: Re:Co si myslíte o OOP?
Přispěvatel: v 11. 01. 2019, 19:06:12
Nejlepší jsou silně typované jazyky s pozdní vazbou  ;D
to by mělo v ghc jít
Název: Re:Co si myslíte o OOP?
Přispěvatel: Mirek Prýmek 11. 01. 2019, 19:10:24
je dobré znát ne dva až tři jazyky, ale především dvě až tři paradigmata
V tom je prave dobry python, protoze ti umoznuje jednotliva paradigmata podle potreby prirozene kombinovat.
Tak to se podle mě velice tragicky mýlíš. Pokud chceš nějakému paradigmatu porozumět, musíš si ho vyzkoušet pokud možno v čisté podobě. Protože jenom ta tě donutí opravdu použít daný přístup a neuhýbat jinam. Tj. pokud funkcionální, tak Haskell, ne Scalu. Na Haskellu pochopíš, o co jde, a pak v praxi už můžeš vzít tu Scalu, protože to může být ze spousty důvodů praktičtější.

Ne, Python opravdu není "multiparadigmatický", to je marketingový blábol. Ono v principu vůbec nic takového jako "multiparadigmatický" neexistuje, protože ta paradigmata jsou právě o tom, co ti jazyk nedovolí udělat, ne o tom, co ti dovolí. Když něco z principu nejde -> máš jistotu, že k tomu nedošlo -> máš zaručenou informaci.

Za druhe ruzne paradigmata jsou uzitecna, ale nepotrebujes si kvuli tomu povrchne hrat s hromadou prakticky nevyuzitelnych jazyku.
Potřebuješ, protože žádný jiný způsob, jak jim porozumět, neexistuje.
Název: Re:Co si myslíte o OOP?
Přispěvatel: BoneFlute 11. 01. 2019, 19:41:50
je dobré znát ne dva až tři jazyky, ale především dvě až tři paradigmata
V tom je prave dobry python, protoze ti umoznuje jednotliva paradigmata podle potreby prirozene kombinovat.
Tak to se podle mě velice tragicky mýlíš. Pokud chceš nějakému paradigmatu porozumět, musíš si ho vyzkoušet pokud možno v čisté podobě. Protože jenom ta tě donutí opravdu použít daný přístup a neuhýbat jinam. Tj. pokud funkcionální, tak Haskell, ne Scalu. Na Haskellu pochopíš, o co jde, a pak v praxi už můžeš vzít tu Scalu, protože to může být ze spousty důvodů praktičtější.

Ne, Python opravdu není "multiparadigmatický", to je marketingový blábol. Ono v principu vůbec nic takového jako "multiparadigmatický" neexistuje, protože ta paradigmata jsou právě o tom, co ti jazyk nedovolí udělat, ne o tom, co ti dovolí. Když něco z principu nejde -> máš jistotu, že k tomu nedošlo -> máš zaručenou informaci.

Za druhe ruzne paradigmata jsou uzitecna, ale nepotrebujes si kvuli tomu povrchne hrat s hromadou prakticky nevyuzitelnych jazyku.
Potřebuješ, protože žádný jiný způsob, jak jim porozumět, neexistuje.

Moje zkušenost:

Když jsem se dostal k Haskellu a začal jsem ho zkoumat, zažil jsem tolik aha momentů jak nikdy.
- že se dá psát úsporně
- že se dá psát smysluplně
- že typy dokáží extrémně pomáhat (a to jsem ještě nevěděl nic o závislostních typech)
- pochopil jsem typy (a že to co má Java a spol je výsměch)
- co to znamená zapouzdření
- co to znamená funkcionální

Pak jsem se vrátil k těm normálním business jazykům, které mě živí, a dost drsně to změnilo můj spůsob programování.

Čas od času zkouším něco v Pythonu. Většinou je to takové jakože dobré. Ale nikdy jsem se od něj nic užitečného neodnesl. Snad jen odsazování jsem si díky němu zamiloval. A čím více ten projekt rostl, tím víc mě Python rozčiloval - že sice má mnohé možnosti, ale vůbec, ale vůbec nepomáhá.

Pak se objeví vždycky nějaký chytrolín, který mě setře, že jsem jen nepochopil tu úžasnou filozofii. A když ho požádám o vysvětlení, tak jen, že to bych nepochopil.
Název: Re:Co si myslíte o OOP?
Přispěvatel: Mirek Prýmek 11. 01. 2019, 19:47:49
Ale nikdy jsem se od něj nic užitečného neodnesl.
Myslím, že největší zkušenost, jakou může Python dát, je potvrzení lidové moudrosti, že i s malým kašpárkem se dá hrát velké divadlo ;)
Název: Re:Co si myslíte o OOP?
Přispěvatel: BaldSlattery 11. 01. 2019, 20:50:28
Nejlepší jsou silně typované jazyky s pozdní vazbou  ;D
Třeba ObjC kombinující dvě výhody, extrémní rychlost Smalltalku a úžasnou paměťovou bezpečnost céčka :)
Název: Re:co si myslite o oop?
Přispěvatel: Kit 11. 01. 2019, 21:51:52
2.
Kód: [Vybrat]
fn(a, b) {
  assert(isInt(a));
  assert(isString(b));
  assert(a > 0);
}

Celkem pěkný příklad, který by navozoval dojem, že je vhodnější používat variantu 2. No, je to ale dáno tím, že se předpokládá, že s údaji bude po business stránce pracovat pouze ta JEDNA funkce. Jenže tak to ve skutečnosti nebude. Business logika je často komplexní a je rozprostřena do více method/objektů/funkcí....potom při variantě 2 je nutné  nějakým způsobem harmonizovat tu validaci...V tomto případě už přináší řešení 1 nesporné výhody.

Horizontální rozprostření business logiky je obvykle cestou do pekel. Je žádoucí, aby s údaji po business stránce pracovala pouze ta jedna funkce, resp. objekt, který obsahuje množinu takových metod, včetně validace. Takový objekt jednoduše injektuješ do modelu.
Název: Re:Co si myslíte o OOP?
Přispěvatel: Kit 11. 01. 2019, 21:59:44
Odpor vuci dynamickym jazykum zazniva od tech, kteri se v nich pokousi programovat staticky, protoze to jinak neumi.
Jenže svět, který se snažíme v IT modelovat/automatizovat má spíše charakter statických typů....Nikdo se nejmenuje 123456 nebo 10.60 a na výplatu dostanu vždy nějakou částku a ne stokorunčeských...takže oprávněný požadavek dynamických typů zpravidla zaznívá jen tehdy, když někdo něco generalizoval-sloučil. Navíc zákazník zpravidla požaduje ukládat data to staticky typovaných databází...v tomto případě nedává moc smysl zavádět do systému nějakou dynamickou složku.

Zrovna částku 10.60 je nejlepší předat do databáze jako string. Jakákoli konverze na nějaký int či float mimo databázi je zcela zbytečná a ve svém důsledku může aplikaci dost ublížit. Není žádný důvod pro hlídání takových typů v aplikaci.
Název: Re:co si myslite o oop?
Přispěvatel: Kit 11. 01. 2019, 22:24:11
Btw, nemusí to být jenom staticky linkovaný knihovny, může to být kombinace několika jazyků, jedna z těch věcí může běžet na jiným fyzickým stroji,... A o to je to zákařnější - není nad to, když server má 64b hodnoty, klient 32b hodnoty a vývojář se diví. A pokud nezná typy (a s tím i tyhle pasti), tak si pěkně namlátí hubu.

Můj příklad je jenom malinká ukázka, jak to dopadá, když prasata ignorujou typy:
Kód: [Vybrat]
Krok | Typ | Dekadicky          | Hexadecimálně         | Podrobnosti
   0 | uint64 | 231479973001           | 0x0000000035E5481489  | hodnota má 40b
   1 | uint32 | 3846706313             | 0xE5481489            | přišli jsme o horních 8b hodnoty
   2 | int64 | -448260983             | 0xFFFFFFFFE5481489    | bit 31 = 1 -> záporné číslo
   3 | uint64 | 18446744072813029651   | 0xFFFFFFFFE5481489    | Interpretováno jako UINT64

S tím mají problémy jen staticky typované jazyky. V dynamicky typovaných to vypadá asi takhle:
Kód: [Vybrat]
Krok | Typ    | Dekadicky    | Hexadecimálně        | Podrobnosti
   0 | string | 231479973001 | 0x0000000035E5481489 | hodnota má 12 B
   1 | string | 231479973001 | 0x0000000035E5481489 | hodnota má 12 B
   2 | string | 231479973001 | 0x0000000035E5481489 | hodnota má 12 B
   3 | string | 231479973001 | 0x0000000035E5481489 | hodnota má 12 B
Jinými slovy se nedělají konverze tam, kde to nikdo nepotřebuje.
Název: Re:co si myslite o oop?
Přispěvatel: Kit 11. 01. 2019, 22:42:13
Další past je třeba float - currency. Jak to má sakra kompilátor/interpreter poznat jenom podle toho, že jsou v parsovaným stringu číslice a mezi nima čárka? To jako podle toho, že je před tím "price="? A každej typ se přitom chová jinak...

Zkrátka, volnost typu = volnost kompilátoru = volnost chování výsledné aplikace. Typ je totiž nedílná součást popisu dat. Když kompilátor neví, co použít a jenom tak tam něco práskne, tak je něco blbě v principu.

Jaká past? String si rozparsuje databáze přesně tak jak potřebuje, třeba na ten finanční decimal. Jak mám tušit, jestli databáze ukládá částky na 2 desetinná místa (CZK) nebo třeba na 6 desetinných míst (BTC)? Proč by do toho měla aplikace zasahovat? Kompilátor/interpreter dynamicky typovaného jazyka prostě typ odvodí ze vstupních dat - stejně jako to dělá třeba i staticky typovaný Haskell.

Pokud si myslíš, že parser dynamicky typovaného jazyka odvozuje typ podle vstupních hodnot, tak jsi na omylu. Standardně to vůbec nedělá, prostě vše je string. Odvozující parser, například v Lispu, to však pozná už z prvního nebílého znaku.
Název: Re:co si myslite o oop?
Přispěvatel: Kit 11. 01. 2019, 22:57:52
Dale, Typ v beznych prog. jazycich je dost omezena pomucka. Pomuze ti oddelit string od cisla, ale nepomuze ti oddelit zaporny cislo od kladnyho cisla. Taky se ti jednoho krasnyho dne muze stat ze ti nekdo zacne posilat negativni hmotnosti tvych zakazniku a typovej system bude drzet hubu.

Tohle je docela důležitá poznámka. Pokud typy umožní zadat -100 kg, -200 cm nebo -300 °C, tak je takový typ zcela k ničemu. To už je lepší takové hodnoty (neotypované) předat do objektu, který s nimi pracuje a který zajistí nejen otypování, ale i validaci hodnot. Objekt může být za taková data zcela odpovědný a vadným vstupům se ubrání výjimkami. Je zcela v jeho kompetenci, zda nevalidní vstupy odmítne nebo sanuje. Běžný parser tohle nezvládne.

Datové vstupy se běžně zpracovávají kontextovou gramatikou, kterou obecné parsery nezvládají.
Název: Re:co si myslite o oop?
Přispěvatel: v 11. 01. 2019, 23:03:17
Dale, Typ v beznych prog. jazycich je dost omezena pomucka. Pomuze ti oddelit string od cisla, ale nepomuze ti oddelit zaporny cislo od kladnyho cisla. Taky se ti jednoho krasnyho dne muze stat ze ti nekdo zacne posilat negativni hmotnosti tvych zakazniku a typovej system bude drzet hubu.

Tohle je docela důležitá poznámka. Pokud typy umožní zadat -100 kg, -200 cm nebo -300 °C, tak je takový typ zcela k ničemu. To už je lepší takové hodnoty (neotypované) předat do objektu, který s nimi pracuje a který zajistí nejen otypování, ale i validaci hodnot. Objekt může být za taková data zcela odpovědný a vadným vstupům se ubrání výjimkami. Je zcela v jeho kompetenci, zda nevalidní vstupy odmítne nebo sanuje. Běžný parser tohle nezvládne.

Datové vstupy se běžně zpracovávají kontextovou gramatikou, kterou obecné parsery nezvládají.
jednotky má moc hezky udělaný F# https://docs.microsoft.com/en-us/dotnet/fsharp/language-reference/units-of-measure
a parsování jednotek problém není
Název: Re:co si myslite o oop?
Přispěvatel: Kit 11. 01. 2019, 23:14:24
jednotky má moc hezky udělaný F# https://docs.microsoft.com/en-us/dotnet/fsharp/language-reference/units-of-measure
a parsování jednotek problém není

To je sice hezké, ale nijak mi to nezabrání uživatelsky zadat záporné kilogramy nebo teplotu roztaveného železa 5000 °C. Pokud by objekt nedělal následnou validaci, zpracoval by i nesmysly. V tomhle mi bezkontextový parser skutečně nepomůže.
Název: Re:co si myslite o oop?
Přispěvatel: BaldSlattery 11. 01. 2019, 23:45:52
Dale, Typ v beznych prog. jazycich je dost omezena pomucka. Pomuze ti oddelit string od cisla, ale nepomuze ti oddelit zaporny cislo od kladnyho cisla. Taky se ti jednoho krasnyho dne muze stat ze ti nekdo zacne posilat negativni hmotnosti tvych zakazniku a typovej system bude drzet hubu.
Datové vstupy se běžně zpracovávají kontextovou gramatikou, kterou obecné parsery nezvládají.
Context-sensitive grammar? To asi dost těžko, v čem by se takový parser psal?
Název: Re:co si myslite o oop?
Přispěvatel: Kit 12. 01. 2019, 00:19:05
Dale, Typ v beznych prog. jazycich je dost omezena pomucka. Pomuze ti oddelit string od cisla, ale nepomuze ti oddelit zaporny cislo od kladnyho cisla. Taky se ti jednoho krasnyho dne muze stat ze ti nekdo zacne posilat negativni hmotnosti tvych zakazniku a typovej system bude drzet hubu.
Datové vstupy se běžně zpracovávají kontextovou gramatikou, kterou obecné parsery nezvládají.
Context-sensitive grammar? To asi dost těžko, v čem by se takový parser psal?

To je prosté. Podle prvního slova vybereš konstruktor a druhé slovo použiješ jako parametr. Vytvořená instance si ho už zpracuje podle svých potřeb. Pokud vyžaduje text, ale dostane číslo, zpracuje ho jako text. Pokud vyžaduje int, ale dostane text, vyhodí výjimku. Například REST funguje na tomto principu, ale variant je spousta.
Název: Re:co si myslite o oop?
Přispěvatel: BaldSlattery 12. 01. 2019, 01:19:55
Dale, Typ v beznych prog. jazycich je dost omezena pomucka. Pomuze ti oddelit string od cisla, ale nepomuze ti oddelit zaporny cislo od kladnyho cisla. Taky se ti jednoho krasnyho dne muze stat ze ti nekdo zacne posilat negativni hmotnosti tvych zakazniku a typovej system bude drzet hubu.
Datové vstupy se běžně zpracovávají kontextovou gramatikou, kterou obecné parsery nezvládají.
Context-sensitive grammar? To asi dost těžko, v čem by se takový parser psal?

To je prosté. Podle prvního slova vybereš konstruktor a druhé slovo použiješ jako parametr. Vytvořená instance si ho už zpracuje podle svých potřeb. Pokud vyžaduje text, ale dostane číslo, zpracuje ho jako text. Pokud vyžaduje int, ale dostane text, vyhodí výjimku. Například REST funguje na tomto principu, ale variant je spousta.
Taková gramatika je ale formálně bezkontextová.
Název: Re:co si myslite o oop?
Přispěvatel: Kit 12. 01. 2019, 01:36:49
Dale, Typ v beznych prog. jazycich je dost omezena pomucka. Pomuze ti oddelit string od cisla, ale nepomuze ti oddelit zaporny cislo od kladnyho cisla. Taky se ti jednoho krasnyho dne muze stat ze ti nekdo zacne posilat negativni hmotnosti tvych zakazniku a typovej system bude drzet hubu.
Datové vstupy se běžně zpracovávají kontextovou gramatikou, kterou obecné parsery nezvládají.
Context-sensitive grammar? To asi dost těžko, v čem by se takový parser psal?
To je prosté. Podle prvního slova vybereš konstruktor a druhé slovo použiješ jako parametr. Vytvořená instance si ho už zpracuje podle svých potřeb. Pokud vyžaduje text, ale dostane číslo, zpracuje ho jako text. Pokud vyžaduje int, ale dostane text, vyhodí výjimku. Například REST funguje na tomto principu, ale variant je spousta.
Taková gramatika je ale formálně bezkontextová.

Jak tedy pozná, že třeba 138 není číslo, ale tříznakový string?
Název: Re:co si myslite o oop?
Přispěvatel: BaldSlattery 12. 01. 2019, 01:57:27
Dale, Typ v beznych prog. jazycich je dost omezena pomucka. Pomuze ti oddelit string od cisla, ale nepomuze ti oddelit zaporny cislo od kladnyho cisla. Taky se ti jednoho krasnyho dne muze stat ze ti nekdo zacne posilat negativni hmotnosti tvych zakazniku a typovej system bude drzet hubu.
Datové vstupy se běžně zpracovávají kontextovou gramatikou, kterou obecné parsery nezvládají.
Context-sensitive grammar? To asi dost těžko, v čem by se takový parser psal?
To je prosté. Podle prvního slova vybereš konstruktor a druhé slovo použiješ jako parametr. Vytvořená instance si ho už zpracuje podle svých potřeb. Pokud vyžaduje text, ale dostane číslo, zpracuje ho jako text. Pokud vyžaduje int, ale dostane text, vyhodí výjimku. Například REST funguje na tomto principu, ale variant je spousta.
Taková gramatika je ale formálně bezkontextová.

Jak tedy pozná, že třeba 138 není číslo, ale tříznakový string?
Ten “konstruktor” a parametr jsou součástí jednoho pravidla.
Název: Re:co si myslite o oop?
Přispěvatel: agent 12. 01. 2019, 08:53:55
To je sice hezké, ale nijak mi to nezabrání uživatelsky zadat záporné kilogramy nebo teplotu roztaveného železa 5000 °C. Pokud by objekt nedělal následnou validaci, zpracoval by i nesmysly. V tomhle mi bezkontextový parser skutečně nepomůže.
Jedna šťouravá :) - co je nesmyslného na teplotě roztaveného železa 5000°C?
V zemském jádru má při téhle teplotě dokonce pevné skupenství.
https://cs.wikipedia.org/wiki/Zemsk%C3%A9_j%C3%A1dro
I záporné kilogramy můžou mít v určitém kontextu smysl - např relativní váha člověka ve vodě (i když Newtony by tady asi dávaly větší smysl)
Neodmítej na první pohled nesmyslný údaj bez znalosti kontextu.
Název: Re:co si myslite o oop?
Přispěvatel: BaldSlattery 12. 01. 2019, 09:20:46
To je sice hezké, ale nijak mi to nezabrání uživatelsky zadat záporné kilogramy nebo teplotu roztaveného železa 5000 °C. Pokud by objekt nedělal následnou validaci, zpracoval by i nesmysly. V tomhle mi bezkontextový parser skutečně nepomůže.
I záporné kilogramy můžou mít v určitém kontextu smysl - např relativní váha člověka ve vodě
Váha a hmotnost jsou dvě různé veličiny s různými jednotkami. Na Marsu se ti například změní váha, ale ne hmotnost. Za nás se tohle bralo na ZŠ, ale svět se asi změnil, dnes by si maturanti stěžovali na obtížnost, kdyby měli vysvětlit rozdíl  ???
Název: Re:co si myslite o oop?
Přispěvatel: mmm 12. 01. 2019, 11:15:29
Jedna šťouravá :) - co je nesmyslného na teplotě roztaveného železa 5000°C?

za atmosferického tlaku je bod varu železa o hodně níž.
Název: Re:Co si myslíte o OOP?
Přispěvatel: Ondra Satai Nekola 12. 01. 2019, 11:51:25
Odpor vuci dynamickym jazykum zazniva od tech, kteri se v nich pokousi programovat staticky, protoze to jinak neumi.
Jenže svět, který se snažíme v IT modelovat/automatizovat má spíše charakter statických typů....Nikdo se nejmenuje 123456 nebo 10.60 a na výplatu dostanu vždy nějakou částku a ne stokorunčeských...takže oprávněný požadavek dynamických typů zpravidla zaznívá jen tehdy, když někdo něco generalizoval-sloučil. Navíc zákazník zpravidla požaduje ukládat data to staticky typovaných databází...v tomto případě nedává moc smysl zavádět do systému nějakou dynamickou složku.

Zrovna částku 10.60 je nejlepší předat do databáze jako string. Jakákoli konverze na nějaký int či float mimo databázi je zcela zbytečná a ve svém důsledku může aplikaci dost ublížit. Není žádný důvod pro hlídání takových typů v aplikaci.

A já myslel, že Kit tu žraloka přeskočil už dávno. A on se to pořád snaží trumfnout...
Název: Re:Co si myslíte o OOP?
Přispěvatel: Kiwi 12. 01. 2019, 13:14:04
Odpor vuci dynamickym jazykum zazniva od tech, kteri se v nich pokousi programovat staticky, protoze to jinak neumi.
Jenže svět, který se snažíme v IT modelovat/automatizovat má spíše charakter statických typů....Nikdo se nejmenuje 123456 nebo 10.60 a na výplatu dostanu vždy nějakou částku a ne stokorunčeských...takže oprávněný požadavek dynamických typů zpravidla zaznívá jen tehdy, když někdo něco generalizoval-sloučil. Navíc zákazník zpravidla požaduje ukládat data to staticky typovaných databází...v tomto případě nedává moc smysl zavádět do systému nějakou dynamickou složku.

Zrovna částku 10.60 je nejlepší předat do databáze jako string. Jakákoli konverze na nějaký int či float mimo databázi je zcela zbytečná a ve svém důsledku může aplikaci dost ublížit. Není žádný důvod pro hlídání takových typů v aplikaci.

A já myslel, že Kit tu žraloka přeskočil už dávno. A on se to pořád snaží trumfnout...
V životě se člověku přihodí ledacos. Kdysi v databázi jeden takový samouk zavedl IP adresu jako string. On byl opravdu trochu omezenější, protože pořád nedokázal pochopit, že to je ve skutečnosti jen jedno číslo, nedokázal pochopit, jak může číslo obsahovat tři tečky. Jenže pak přišlo IPv6 a díky jeho stringu databáze bez problémů nové adresy zchroustala. Nakonec udělat si konverzi string->číslo (nebo whatever...) jde vždycky, ale kdyby byl databázi udělal nad uint32, celá věc by se bývala dost zkomplikovala.

Je to sice jako v těch pohádkách, kde hloupému Honzovi nakonec pomohlo štěstí, ale určité ponaučení si z toho pro praxi odnést lze.
Název: Re:Co si myslíte o OOP?
Přispěvatel: Mirek Prýmek 12. 01. 2019, 13:19:07
ale určité ponaučení si z toho pro praxi odnést lze.
Jaké?
Název: Re:Co si myslíte o OOP?
Přispěvatel: Kit 12. 01. 2019, 14:22:30
V životě se člověku přihodí ledacos. Kdysi v databázi jeden takový samouk zavedl IP adresu jako string. On byl opravdu trochu omezenější, protože pořád nedokázal pochopit, že to je ve skutečnosti jen jedno číslo, nedokázal pochopit, jak může číslo obsahovat tři tečky. Jenže pak přišlo IPv6 a díky jeho stringu databáze bez problémů nové adresy zchroustala. Nakonec udělat si konverzi string->číslo (nebo whatever...) jde vždycky, ale kdyby byl databázi udělal nad uint32, celá věc by se bývala dost zkomplikovala.

Je to sice jako v těch pohádkách, kde hloupému Honzovi nakonec pomohlo štěstí, ale určité ponaučení si z toho pro praxi odnést lze.

Něco podobného se mi skutečně stalo, když mi někdo vnucoval, že telefonní číslo mám ukládat jako uint32, ale já ho přesto udělal jako string, protože telefonní číslo není číslo.
Název: Re:Co si myslíte o OOP?
Přispěvatel: Inkvizitor 12. 01. 2019, 17:58:49
V životě se člověku přihodí ledacos. Kdysi v databázi jeden takový samouk zavedl IP adresu jako string. On byl opravdu trochu omezenější, protože pořád nedokázal pochopit, že to je ve skutečnosti jen jedno číslo, nedokázal pochopit, jak může číslo obsahovat tři tečky. Jenže pak přišlo IPv6 a díky jeho stringu databáze bez problémů nové adresy zchroustala. Nakonec udělat si konverzi string->číslo (nebo whatever...) jde vždycky, ale kdyby byl databázi udělal nad uint32, celá věc by se bývala dost zkomplikovala.

Je to sice jako v těch pohádkách, kde hloupému Honzovi nakonec pomohlo štěstí, ale určité ponaučení si z toho pro praxi odnést lze.

Něco podobného se mi skutečně stalo, když mi někdo vnucoval, že telefonní číslo mám ukládat jako uint32, ale já ho přesto udělal jako string, protože telefonní číslo není číslo.

Ty jsi, Kite, predbehl dobu. Dnes je v mode genderova flexibilita a jak by se hodilo mit moznost volnou formou zadat v kolonce pohlavi "kyberpes" namisto trapneho vyberu mezi M a F.
Název: Re:Co si myslíte o OOP?
Přispěvatel: Kit 12. 01. 2019, 21:52:42
Ty jsi, Kite, predbehl dobu. Dnes je v mode genderova flexibilita a jak by se hodilo mit moznost volnou formou zadat v kolonce pohlavi "kyberpes" namisto trapneho vyberu mezi M a F.

Zažil jsem i dobu, kdy se pohlaví zadávalo true/false.
Název: Re:Co si myslíte o OOP?
Přispěvatel: BoneFlute 12. 01. 2019, 22:01:50
Ty jsi, Kite, predbehl dobu. Dnes je v mode genderova flexibilita a jak by se hodilo mit moznost volnou formou zadat v kolonce pohlavi "kyberpes" namisto trapneho vyberu mezi M a F.

Zažil jsem i dobu, kdy se pohlaví zadávalo true/false.

Má pindíka? Ano/Ne :-D
Název: Re:Co si myslíte o OOP?
Přispěvatel: Cikáda 12. 01. 2019, 22:13:04
V životě se člověku přihodí ledacos. Kdysi v databázi jeden takový samouk zavedl IP adresu jako string. On byl opravdu trochu omezenější, protože pořád nedokázal pochopit, že to je ve skutečnosti jen jedno číslo, nedokázal pochopit, jak může číslo obsahovat tři tečky. Jenže pak přišlo IPv6 a díky jeho stringu databáze bez problémů nové adresy zchroustala. Nakonec udělat si konverzi string->číslo (nebo whatever...) jde vždycky, ale kdyby byl databázi udělal nad uint32, celá věc by se bývala dost zkomplikovala.

Je to sice jako v těch pohádkách, kde hloupému Honzovi nakonec pomohlo štěstí, ale určité ponaučení si z toho pro praxi odnést lze.

Něco podobného se mi skutečně stalo, když mi někdo vnucoval, že telefonní číslo mám ukládat jako uint32, ale já ho přesto udělal jako string, protože telefonní číslo není číslo.

Ty jsi, Kite, predbehl dobu. Dnes je v mode genderova flexibilita a jak by se hodilo mit moznost volnou formou zadat v kolonce pohlavi "kyberpes" namisto trapneho vyberu mezi M a F.

Akorát pohlaví (u lidí) jsou dvě. Tzv. "gender" je něco jiného. To jen taková technická :)
Název: Re:Co si myslíte o OOP?
Přispěvatel: Mirek Prýmek 13. 01. 2019, 01:05:21
Akorát pohlaví (u lidí) jsou dvě. Tzv. "gender" je něco jiného. To jen taková technická :)
Ještě přesněji, pojem "pohlaví" postupně ztrácí svůj někdejší čistě vnějškový biologický význam (má pindíka/nemá pindíka).

Pokud bych si měl vzít poučení z té anekdoty s IP adresou ve stringu, tak vlastně správný způsob, jak modelovat pojem "pohlaví" je neomezený string, do kterého dotazovaný může vepsat esej o tom, jestli to, co má mezi nohama, je ochoten nazývat slovem "pindík" a jakým způsobem to, co má mezi nohama, ovlivňuje jeho sebechápání v pojmech "žena" či "muž".

Nebo možná to poučení z té anekdoty s IP ve stringu je v tom, že bysme do labelu takové položky neměli psát "pohlaví", ale "co máte v občance v položce >pohlaví<?", nevím.
Název: Re:Co si myslíte o OOP?
Přispěvatel: Cikáda 13. 01. 2019, 02:09:14
Akorát pohlaví (u lidí) jsou dvě. Tzv. "gender" je něco jiného. To jen taková technická :)
Ještě přesněji, pojem "pohlaví" postupně ztrácí svůj někdejší čistě vnějškový biologický význam (má pindíka/nemá pindíka).

Ne, ideologicky není přesněji. Ten význam je stále stejný, i když chápu, že jsou proudy, které se snaží.  Mimo to, pohlaví není jen o "čistě vnějškovém biologickém významu", protože z hlediska biologie nejde jen o "má/nemá pindíka".
Název: Re:Co si myslíte o OOP?
Přispěvatel: Mirek Prýmek 13. 01. 2019, 02:23:35
Ne, ideologicky není přesněji.
O žádnou ideologii nejde. Jde o to, jak je to slovo reálně používáno reálnými lidmi. To moje tvrzení je deskriptivní, ne preskriptivní.

Teprve v poslední době se prostě ve veřejném prostoru běžně objevují otevřené informace o tom, že existují lidi, kteří mají pindíka a přesto mají potřebu se označovat za ženy (a naopak). To způsobilo zvýšené povědomí o tom, že ten pojem není tak bezproblémový, za jaký byl dříve pokládán.

Žádná ideologie v tom nehraje žádnou roli, to je typický red herring, hodný Václava Klause ml.
Název: Re:Co si myslíte o OOP?
Přispěvatel: Cikáda 13. 01. 2019, 03:42:51
O žádnou ideologii nejde. Jde o to, jak je to slovo reálně používáno reálnými lidmi. To moje tvrzení je deskriptivní, ne preskriptivní.

Teprve v poslední době se prostě ve veřejném prostoru běžně objevují otevřené informace o tom, že existují lidi, kteří mají pindíka a přesto mají potřebu se označovat za ženy (a naopak). To způsobilo zvýšené povědomí o tom, že ten pojem není tak bezproblémový, za jaký byl dříve pokládán.

1) Ne, pohlaví je terminus technicus. Tvoje tvrzení není deskriptivní, ale zavádějící. Ale rád si nechám vysvětlit, v čem je ten pojem problémový (resp. není bezproblémový).

2) To, že existují lidé, co mají pindíka a mají potřebu se označovat za ženy (a naopak), ale nemá žádný vliv na jejich pohlaví.

( 3) Paradoxně i kdyby se označovali za ženu s pindíkem, tak pořád patří do škatulky "žena", pokud bychom to brali jako relevantní. )

Žádná ideologie v tom nehraje žádnou roli, to je typický red herring, hodný Václava Klause ml.

Opravdu? Že zpochybňování vědeckých faktů je ideologické, je typický red herring?

Typický red herring je ohánění se v jistých ohledech extrémisty jako je Klaus ml.
Název: Re:Co si myslíte o OOP?
Přispěvatel: Kamil Podlešák 13. 01. 2019, 09:46:09
Akorát pohlaví (u lidí) jsou dvě. Tzv. "gender" je něco jiného. To jen taková technická :)
Ještě přesněji, pojem "pohlaví" postupně ztrácí svůj někdejší čistě vnějškový biologický význam (má pindíka/nemá pindíka).
...
Nebo možná to poučení z té anekdoty s IP ve stringu je v tom, že bysme do labelu takové položky neměli psát "pohlaví", ale "co máte v občance v položce >pohlaví<?", nevím.
Vy chcete překonat stávající rekord počtu příspěvků?

Nicméně k tématu: "gender" se lépe než "pohlaví" přeloží jako "rod". I když ani to není úplně ono... ale už to naznačuje na co se zaměřit u datového modelování.

K čemu vlastně potřebuji "pohlaví" nebo "rod" ve formuláři? Opravdu danou aplikaci zajímá jaký má dotyčný primární pohlavní orgán? Nebo jaké má chromozómy? Někdy ano. Ale troufám si říci že ve většině případů je zajímavý mluvnický rod pro skloňování (zvlášť v češtině, kde existuje vokativ). V takovém případě je lepší místo "pohlaví" mít kolonku "oslovení" s výběrem (pan, paní, slečna, doktor, etc) který mluvnický rod i správně implikuje. Dokážu si ale představit i aplikaci kde se používají "přezdívky" a pak je zcela na místě mít všechny tři rody které v českém jazyce existují.

Ještě bych se ale vrátil k tomu telefonu, který zde byl zmíněn. Doufám že nikoho snad opravdu nenapadne telefon ukládat jako integer nebo float!! A i když je k dispozici datový typ s neomezenou přesností (v dekadické soustavě), tak typicky nepodporuje významné nuly na začátku! A počet číslic také není úplně jasný, u mezinárodních čísel... A to všechno má stejně smysl zase podle aplikace: někdy je telefon použitý pro vytáčení, pak se samozřejmě číslo musí validovat. Ale pokud jsou to jenom kontaktní údaje někde zobrazené pro lidi, pak je lepší nechat telefon jako volný řetězec. Umožní to lidem zapsat speciality jako "klapka", rozsah čísel, nebo třeba "jen 9-12h". Samozřejmě, je to kompromis hodně směrem k uživatelům a nevhodný pro stroje :-)

Název: Re:Co si myslíte o OOP?
Přispěvatel: Inkvizitor 13. 01. 2019, 12:29:15
Vy chcete překonat stávající rekord počtu příspěvků?

Nicméně k tématu: "gender" se lépe než "pohlaví" přeloží jako "rod". I když ani to není úplně ono... ale už to naznačuje na co se zaměřit u datového modelování.

K čemu vlastně potřebuji "pohlaví" nebo "rod" ve formuláři? Opravdu danou aplikaci zajímá jaký má dotyčný primární pohlavní orgán? Nebo jaké má chromozómy? Někdy ano. Ale troufám si říci že ve většině případů je zajímavý mluvnický rod pro skloňování (zvlášť v češtině, kde existuje vokativ). V takovém případě je lepší místo "pohlaví" mít kolonku "oslovení" s výběrem (pan, paní, slečna, doktor, etc) který mluvnický rod i správně implikuje. Dokážu si ale představit i aplikaci kde se používají "přezdívky" a pak je zcela na místě mít všechny tři rody které v českém jazyce existují.

Ještě bych se ale vrátil k tomu telefonu, který zde byl zmíněn. Doufám že nikoho snad opravdu nenapadne telefon ukládat jako integer nebo float!! A i když je k dispozici datový typ s neomezenou přesností (v dekadické soustavě), tak typicky nepodporuje významné nuly na začátku! A počet číslic také není úplně jasný, u mezinárodních čísel... A to všechno má stejně smysl zase podle aplikace: někdy je telefon použitý pro vytáčení, pak se samozřejmě číslo musí validovat. Ale pokud jsou to jenom kontaktní údaje někde zobrazené pro lidi, pak je lepší nechat telefon jako volný řetězec. Umožní to lidem zapsat speciality jako "klapka", rozsah čísel, nebo třeba "jen 9-12h". Samozřejmě, je to kompromis hodně směrem k uživatelům a nevhodný pro stroje :-)

Já bych to zjednodušil: Optimální reprezentace dat je závislá na kontextu - záleží na tom, jaké hodnoty chceme ukládat, zda má být reprezentace lidsky čitelná nebo třeba zda chceme podle té hodnoty vyhledávat (ať už podle velikosti čísla nebo naopak třeba podle podřetězce).

Moje připomínka ke genderu byla zamýšlena jako popíchnutí Kita. Co tam má smysl nebo nemá, je závislé opět na kontextu. Bývaly doby, kdy pohlaví mělo jasnou souvislost s rozmnožováním a "rod" to respektoval (kupodivu slovo opět ukazuje k rození, což je jasně biologická, v našem druhu binární záležitost). V současném západním kontextu, kde jsou lidé věčnými dětmi a celý svět se točí kolem jejich ega, samozřejmě návrh software toto musí rovněž respektovat-
Název: Re:Co si myslíte o OOP?
Přispěvatel: Mirek Prýmek 13. 01. 2019, 12:42:18
1) Ne, pohlaví je terminus technicus.
Dobře. Takže mám před sebou nějakého člověka. Jakým testem s naprostou jistotou zjistím jeho pohlaví?
Název: Re:Co si myslíte o OOP?
Přispěvatel: Cikáda 13. 01. 2019, 13:04:59
1) Ne, pohlaví je terminus technicus.
Dobře. Takže mám před sebou nějakého člověka. Jakým testem s naprostou jistotou zjistím jeho pohlaví?

V drtivé většině pouhým zrakem, jinak podle chromozomů. Každopádně to lze určit.

Jak to souvisí?
Název: Re:Co si myslíte o OOP?
Přispěvatel: Kit 13. 01. 2019, 13:11:26
Moje připomínka ke genderu byla zamýšlena jako popíchnutí Kita. Co tam má smysl nebo nemá, je závislé opět na kontextu. Bývaly doby, kdy pohlaví mělo jasnou souvislost s rozmnožováním a "rod" to respektoval (kupodivu slovo opět ukazuje k rození, což je jasně biologická, v našem druhu binární záležitost). V současném západním kontextu, kde jsou lidé věčnými dětmi a celý svět se točí kolem jejich ega, samozřejmě návrh software toto musí rovněž respektovat-

Chtěl jsem toto popíchnutí přenechat ostatním, kteří jsou v rozlišování pohlaví zdatnější. Jen mi chybí definice genderu jedince, který vypadá jako žena se vším všudy, ale v břiše má místo vaječníků varlata a genetické testy také říkají, že je mužem.
Název: Re:Co si myslíte o OOP?
Přispěvatel: Mirek Prýmek 13. 01. 2019, 13:12:00
V drtivé většině pouhým zrakem, jinak podle chromozomů. Každopádně to lze určit.
To je velice vágní, je to potřeba upřesnit:

1. "pouhým zrakem" znamená co? Podívám se, jestli má pindíka?
2. "podle chromozomů" znamená co?
3. co když metody 1 a 2 dávají odlišné výsledky?
Název: Re:Co si myslíte o OOP?
Přispěvatel: Cikáda 13. 01. 2019, 13:31:36
V drtivé většině pouhým zrakem, jinak podle chromozomů. Každopádně to lze určit.
To je velice vágní, je to potřeba upřesnit:

1. "pouhým zrakem" znamená co? Podívám se, jestli má pindíka?
2. "podle chromozomů" znamená co?
3. co když metody 1 a 2 dávají odlišné výsledky?

Ne, není to vágní a asi jsi nedával ve škole pozor.

1) Ne, podíváš se a vidíš. Možná jsi na to ještě nepřišel, ale žena a muž mají vcelku rozeznatelně odlišnou stavbu těla.

2) To znamená, že máš mezery i v biologii.

3) Tak platí metoda 2.
Název: Re:Co si myslíte o OOP?
Přispěvatel: Mirek Prýmek 13. 01. 2019, 13:40:27
Ne, není to vágní a asi jsi nedával ve škole pozor.
No nebudu ti oplácet stejnou mincí (tj. nebudu se uchylovat k ad hominem) a omezím se na konstatování, že:

1. existují všelijaké varianty stavby těla, včetně "zmixovaných", kde např. člověk má obojí pohlavní orgány
2. existují všelijaké genetické poruchy, kde platí totéž

Čili tvůj dojem, že "pohlaví" je neproblematický pojem, je mylné. U drtivé většiny lidí je možné říct, že se jedná o muže nebo ženu, ale existují lidé, u kterých to jasné není, jsou prostě biologicky "někde mezi".
Název: Re:Co si myslíte o OOP?
Přispěvatel: v 13. 01. 2019, 13:43:43
V drtivé většině pouhým zrakem, jinak podle chromozomů. Každopádně to lze určit.
To je velice vágní, je to potřeba upřesnit:

1. "pouhým zrakem" znamená co? Podívám se, jestli má pindíka?
2. "podle chromozomů" znamená co?
3. co když metody 1 a 2 dávají odlišné výsledky?

Ne, není to vágní a asi jsi nedával ve škole pozor.
mi třeba ve škole na otázku kde se bere to 3.14.. odpověděli, že to 22/7 :) a s chromozomama je to podobně
Název: Re:Co si myslíte o OOP?
Přispěvatel: Karol Kos 13. 01. 2019, 13:44:33
Ach jo, kdy si lidi přestanou vymýšlet kraviny a vrátí se k podstatě. Člověk jako úzkonosá opice má od přírody dvě pohlaví, mužské a ženské. Všechno ostatní jsou genetické mutace. Není na tom nic špatného, prostě to je fakt. Namísto snahy o demagogické vytváření alternativních pohlaví by se lidé měli věnovat opravdovému zrovnoprávnění všech lidí obecně. A třeba ať se manželství redefinuje jako svazek dvou jedinců, bez dalšího upřesnění...  Pak by mohlo existovat pouze pohlaví mužské, ženské a nedefinované, plus by se jako další znak uzákonila orientace. Pohlaví by bylo dané, orientaci by si lide mohli zvolit...
Název: Re:Co si myslíte o OOP?
Přispěvatel: Mirek Prýmek 13. 01. 2019, 13:52:12
Všechno ostatní jsou genetické mutace.
Ano, jsou to genetické mutace, které způsobují, že u daného jedince nelze bezproblémově říct, jestli se jedná o samce nebo samici. Nic jiného tu nikdo netvrdí. Žádného "demagogického vytváření alternativních pohlaví" jsem si tady nevšiml, ty jo?
Název: Re:Co si myslíte o OOP?
Přispěvatel: Cikáda 13. 01. 2019, 13:55:01
Ne, není to vágní a asi jsi nedával ve škole pozor.
No nebudu ti oplácet stejnou mincí (tj. nebudu se uchylovat k ad hominem) a omezím se na konstatování, že:


Jistě, to ty nikdy.

1. existují všelijaké varianty stavby těla, včetně "zmixovaných", kde např. člověk má obojí pohlavní orgány
2. existují všelijaké genetické poruchy, kde platí totéž

Čili tvůj dojem, že "pohlaví" je neproblematický pojem, je mylné. U drtivé většiny lidí je možné říct, že se jedná o muže nebo ženu, ale existují lidé, u kterých to jasné není, jsou prostě biologicky "někde mezi".

Ne, není mylné.  Jistě, existují lidé, co se narodí s jednou ledvinou, ale člověk má dvě. Člověk má nos, jistě jsou lidé, kteří se narodí bez něj. Relativizuješ a argumentuješ absolutně zmatečně. Mutace, odchylky a poruchy jsou absolutně normální napříč světem, ale to nevypovídá nic o problematičnosti pojmu. Mimochodem, celosvětově se intersexuálové pohybují kolem setin procent přinejlepším (mluvíme-li o případech, které nelze rozhodnout). Chápu, že to zkoušíš, ale už to fakt zavání nihilismem.
Název: Re:Co si myslíte o OOP?
Přispěvatel: Mirek Prýmek 13. 01. 2019, 13:57:22
Ne, není mylné.  Jistě, existují lidé, co se narodí s jednou ledvinou, ale člověk má dvě. Člověk má nos, jistě jsou lidé, kteří se narodí bez něj.
U některých jedinců prostě je problém určit pohlaví. Proto není pojem "pohlaví" bezproblémový (tím ti odpovídám na položenou otázku).
Název: Re:Co si myslíte o OOP?
Přispěvatel: Wavelet 13. 01. 2019, 14:08:11
Ne, není mylné.  Jistě, existují lidé, co se narodí s jednou ledvinou, ale člověk má dvě. Člověk má nos, jistě jsou lidé, kteří se narodí bez něj.
U některých jedinců prostě je problém určit pohlaví. Proto není pojem "pohlaví" bezproblémový (tím ti odpovídám na položenou otázku).

Vy to ale asi opravdu děláte problematické. Doporučím vám některou přednášku u nás na přírodovědě. Pohlavní dimorfismus vám něco říká? A s OOP ty vaše komentáře souvisí jak?
Název: Re:Co si myslíte o OOP?
Přispěvatel: Cikáda 13. 01. 2019, 14:14:14
Ne, není mylné.  Jistě, existují lidé, co se narodí s jednou ledvinou, ale člověk má dvě. Člověk má nos, jistě jsou lidé, kteří se narodí bez něj.
U některých jedinců prostě je problém určit pohlaví. Proto není pojem "pohlaví" bezproblémový (tím ti odpovídám na položenou otázku).

Ano, takže může být problém určit pohlaví jedince. Termín pohlaví je jasný.

(proto jsem se ptal, jak to souvisí, což kdybys vysvětlil, tak jsme si mohli pár příspěvků odpustit)
Název: Re:Co si myslíte o OOP?
Přispěvatel: Mirek Prýmek 13. 01. 2019, 14:19:40
Termín pohlaví je jasný.
Pokud bude v modelu položka "pohlaví" s enumem "muž" a "žena", tak u některých jedinců nebude problém, co by tam mělo být.

Jestli ti to přijde jako že "Termín pohlaví je jasný.", tak přijde no. Mně ne.
Název: Re:Co si myslíte o OOP?
Přispěvatel: Cikáda 13. 01. 2019, 14:32:14
Termín pohlaví je jasný.
Pokud bude v modelu položka "pohlaví" s enumem "muž" a "žena", tak u některých jedinců nebude problém, co by tam mělo být.

Opět, to je něco jiného.

Jestli ti to přijde jako že "Termín pohlaví je jasný.", tak přijde no. Mně ne.

Ne, nepřijde, je. Zatím jsi nebyl schopen doložit, že tomu tak není.
Název: Re:Co si myslíte o OOP?
Přispěvatel: Kit 13. 01. 2019, 14:34:19
Mimochodem, celosvětově se intersexuálové pohybují kolem setin procent přinejlepším (mluvíme-li o případech, které nelze rozhodnout). Chápu, že to zkoušíš, ale už to fakt zavání nihilismem.

I při tak nízkém zastoupení je docela pravděpodobné, že v databázi s několika tisíci lidmi na někoho takového narazíme a musíme se s tím vypořádat. Dokonce mohou být rozdílné vstupy pro registraci v obchodě s oblečením a pro registraci ke sportovnímu utkání.
Název: Re:Co si myslíte o OOP?
Přispěvatel: Mirek Prýmek 13. 01. 2019, 14:37:36
Doporučím vám některou přednášku u nás na přírodovědě.
Kterou a proč?

Pohlavní dimorfismus vám něco říká?
Něco jo.

A s OOP ty vaše komentáře souvisí jak?
Souvisí to s modelováním. Dobrý příklad má o příspěvek výš Kit.
Název: Re:Co si myslíte o OOP?
Přispěvatel: Cikáda 13. 01. 2019, 14:43:11
Mimochodem, celosvětově se intersexuálové pohybují kolem setin procent přinejlepším (mluvíme-li o případech, které nelze rozhodnout). Chápu, že to zkoušíš, ale už to fakt zavání nihilismem.

I při tak nízkém zastoupení je docela pravděpodobné, že v databázi s několika tisíci lidmi na někoho takového narazíme a musíme se s tím vypořádat. Dokonce mohou být rozdílné vstupy pro registraci v obchodě s oblečením a pro registraci ke sportovnímu utkání.

Ano, ale pohlaví != určení pohlaví.
Název: Re:Co si myslíte o OOP?
Přispěvatel: Wavelet 13. 01. 2019, 14:52:10
Doporučím vám některou přednášku u nás na přírodovědě.
Kterou a proč?

Pohlavní dimorfismus vám něco říká?
Něco jo.

A s OOP ty vaše komentáře souvisí jak?
Souvisí to s modelováním. Dobrý příklad má o příspěvek výš Kit.

Který dobrý příklad měl Kit?
Přednáška: https://www.youtube.com/watch?v=mDl2Xrdpeow&t=5035s
Problém určení pohlaví neznamená, že pojem pohlaví je nějak problematický respektive kdybych takhle přemýšlel tak se nikam nepohnu.
Název: Re:Co si myslíte o OOP?
Přispěvatel: Mirek Prýmek 13. 01. 2019, 14:55:13
Který dobrý příklad měl Kit?
Příklad na to, že pokud máme v modelu položku "pohlaví", může dávat smysl mít pro jednoho člověka v různých kontextech v téhle položce různé hodnoty.

Přednáška: https://www.youtube.com/watch?v=mDl2Xrdpeow&t=5035s
A co bych tam měl hledat?
Název: Re:Co si myslíte o OOP?
Přispěvatel: Kit 13. 01. 2019, 14:58:35
Mimochodem, celosvětově se intersexuálové pohybují kolem setin procent přinejlepším (mluvíme-li o případech, které nelze rozhodnout). Chápu, že to zkoušíš, ale už to fakt zavání nihilismem.
I při tak nízkém zastoupení je docela pravděpodobné, že v databázi s několika tisíci lidmi na někoho takového narazíme a musíme se s tím vypořádat. Dokonce mohou být rozdílné vstupy pro registraci v obchodě s oblečením a pro registraci ke sportovnímu utkání.
Ano, ale pohlaví != určení pohlaví.

Jistě, ve sportu se určuje geneticky, tam je to jasné. Při nákupu oblečení nejen podle morfologie postavy, ale hlavně podle toho, co zákazník chce koupit. Například transvestita může být v civilu zcela jasným mužem, ale v daném obchodě chce vybírat dámské oblečení pro svá vystoupení. Co má zadat do formuláře?
Název: Re:Co si myslíte o OOP?
Přispěvatel: Cikáda 13. 01. 2019, 15:09:43
Mimochodem, celosvětově se intersexuálové pohybují kolem setin procent přinejlepším (mluvíme-li o případech, které nelze rozhodnout). Chápu, že to zkoušíš, ale už to fakt zavání nihilismem.
I při tak nízkém zastoupení je docela pravděpodobné, že v databázi s několika tisíci lidmi na někoho takového narazíme a musíme se s tím vypořádat. Dokonce mohou být rozdílné vstupy pro registraci v obchodě s oblečením a pro registraci ke sportovnímu utkání.
Ano, ale pohlaví != určení pohlaví.

Jistě, ve sportu se určuje geneticky, tam je to jasné. Při nákupu oblečení nejen podle morfologie postavy, ale hlavně podle toho, co zákazník chce koupit. Například transvestita může být v civilu zcela jasným mužem, ale v daném obchodě chce vybírat dámské oblečení pro svá vystoupení. Co má zadat do formuláře?

Ne, pohlaví je vědecký termín. To, že se muž oblékne jako žena, neznamená, že je žena. Ani když se nechá přeoperovat, tak to nezmění jeho pohlaví. To, s čím se identifikuje, je věc jiná.

Jistě, ve sportu se určuje geneticky, tam je to jasné.

Jinak toto není pravda. Např. Fallon Fox.
Název: Re:Co si myslíte o OOP?
Přispěvatel: Mirek Prýmek 13. 01. 2019, 15:44:08
pohlaví je vědecký termín
Pokud máš ve webovém formuláři položku "pohlaví", tak tě typicky nezajímá "vědecký" význam, ale jiné významy: právní, administrativní, sebeidentifikační apod.

Slovo "pohlaví" prostě není jednoznačné a jeho vědecký význam je jenom jeden z mnoha.
Název: Re:Co si myslíte o OOP?
Přispěvatel: Wavelet 13. 01. 2019, 15:44:56
Citace: Kit
Jistě, ve sportu se určuje geneticky, tam je to jasné. Při nákupu oblečení nejen podle morfologie postavy, ale hlavně podle toho, co zákazník chce koupit. Například transvestita může být v civilu zcela jasným mužem, ale v daném obchodě chce vybírat dámské oblečení pro svá vystoupení. Co má zadat do formuláře?
V databázi jako zákazník je muž (pokud to tak zadal), ale preference na doporučení oblečení chce mít ženské. Ten systém bych namodeloval s touto možností. Dře to protože se to snažíž ohnout na jiný scénář než to je namodelované.
Název: Re:Co si myslíte o OOP?
Přispěvatel: Wavelet 13. 01. 2019, 15:54:01
pohlaví je vědecký termín
Pokud máš ve webovém formuláři položku "pohlaví", tak tě typicky nezajímá "vědecký" význam, ale jiné významy: právní, administrativní, sebeidentifikační apod.

Slovo "pohlaví" prostě není jednoznačné a jeho vědecký význam je jenom jeden z mnoha.
Ano, jak to namodeluji tak to mám. Ale spíš se mi zdá že jste to pomotal s pojmem gender a teď se z toho snažíte nějak vymotat a to způsoběm, že to celé označíte za jakýsi "problém". Cikáda to píše dobře. Jinak ta přednáška by vám kromě jiného mohla ukázat že zjistit pohledem pohlaví je naprosto normální metoda. U lidí dost spolehlivá narozdíl třeba od papoušků.
Název: Re:Co si myslíte o OOP?
Přispěvatel: v 13. 01. 2019, 15:58:33
pohlaví je vědecký termín
Pokud máš ve webovém formuláři položku "pohlaví", tak tě typicky nezajímá "vědecký" význam, ale jiné významy: právní, administrativní, sebeidentifikační apod.

Slovo "pohlaví" prostě není jednoznačné a jeho vědecký význam je jenom jeden z mnoha.
Ano, jak to namodeluji tak to mám. Ale spíš se mi zdá že jste to pomotal s pojmem gender a teď se z toho snažíte nějak vymotat a to způsoběm, že to celé označíte za jakýsi "problém". Cikáda to píše dobře. Jinak ta přednáška by vám kromě jiného mohla ukázat že zjistit pohledem pohlaví je naprosto normální metoda. U lidí dost spolehlivá narozdíl třeba od papoušků.
tak jaký je teda typ kolonky "biologické pohlaví"? mi vyšlo tohle:
Kód: [Vybrat]
data Sex = Male | Female | Intersexasi v informačním systému pro doktory, ve filtru eshopu
Kód: [Vybrat]
data Sex = Male | Female | Unisex
Název: Re:Co si myslíte o OOP?
Přispěvatel: Cikáda 13. 01. 2019, 16:00:34
pohlaví je vědecký termín
Pokud máš ve webovém formuláři položku "pohlaví", tak tě typicky nezajímá "vědecký" význam, ale jiné významy: právní, administrativní, sebeidentifikační apod.

Slovo "pohlaví" prostě není jednoznačné a jeho vědecký význam je jenom jeden z mnoha.

Ne, není. A toto je přesně ta ideologie, o které jsem mluvil. Místo vědecký si tam strč "terminus technicus", aby ti to bylo jasné.

@uetoyo - díky
Název: Re:Co si myslíte o OOP?
Přispěvatel: Cikáda 13. 01. 2019, 16:01:41
pohlaví je vědecký termín
Pokud máš ve webovém formuláři položku "pohlaví", tak tě typicky nezajímá "vědecký" význam, ale jiné významy: právní, administrativní, sebeidentifikační apod.

Slovo "pohlaví" prostě není jednoznačné a jeho vědecký význam je jenom jeden z mnoha.
Ano, jak to namodeluji tak to mám. Ale spíš se mi zdá že jste to pomotal s pojmem gender a teď se z toho snažíte nějak vymotat a to způsoběm, že to celé označíte za jakýsi "problém". Cikáda to píše dobře. Jinak ta přednáška by vám kromě jiného mohla ukázat že zjistit pohledem pohlaví je naprosto normální metoda. U lidí dost spolehlivá narozdíl třeba od papoušků.
tak jaký je teda typ kolonky "biologické pohlaví"? mi vyšlo tohle:
Kód: [Vybrat]
data Sex = Male | Female | Intersexasi v informačním systému pro doktory, ve filtru eshopu
Kód: [Vybrat]
data Sex = Male | Female | Unisex

Není "biologické pohlaví", je pohlaví. Intersexuálové netvoří další pohlaví.
Název: Re:Co si myslíte o OOP?
Přispěvatel: Inkvizitor 13. 01. 2019, 16:14:14
Citace: Kit
Jistě, ve sportu se určuje geneticky, tam je to jasné. Při nákupu oblečení nejen podle morfologie postavy, ale hlavně podle toho, co zákazník chce koupit. Například transvestita může být v civilu zcela jasným mužem, ale v daném obchodě chce vybírat dámské oblečení pro svá vystoupení. Co má zadat do formuláře?
V databázi jako zákazník je muž (pokud to tak zadal), ale preference na doporučení oblečení chce mít ženské. Ten systém bych namodeloval s touto možností. Dře to protože se to snažíž ohnout na jiný scénář než to je namodelované.

Co na tomhle chcete modelovat? V obchodu s oblečením jsou běžně různá oddělení a když půjdu koupit podprsenku, nikoho nezajímá, jestli to je pro manželku nebo pro matku nebo pro ujetého souseda Pepu, zrovna tak v dětském oddělení Vás nechají koupit bryndák bez ohledu na to, jestli máte potvrzení o tom, že máte děti.
Název: Re:Co si myslíte o OOP?
Přispěvatel: Kit 13. 01. 2019, 16:18:14
Jinak ta přednáška by vám kromě jiného mohla ukázat že zjistit pohledem pohlaví je naprosto normální metoda. U lidí dost spolehlivá narozdíl třeba od papoušků.

Ve vlaku občas potkávám průvodčí(ho), u které(ho) jsem dosud pohlaví neidentifikoval.
Název: Re:Co si myslíte o OOP?
Přispěvatel: v 13. 01. 2019, 16:21:55
pohlaví je vědecký termín
Pokud máš ve webovém formuláři položku "pohlaví", tak tě typicky nezajímá "vědecký" význam, ale jiné významy: právní, administrativní, sebeidentifikační apod.

Slovo "pohlaví" prostě není jednoznačné a jeho vědecký význam je jenom jeden z mnoha.
Ano, jak to namodeluji tak to mám. Ale spíš se mi zdá že jste to pomotal s pojmem gender a teď se z toho snažíte nějak vymotat a to způsoběm, že to celé označíte za jakýsi "problém". Cikáda to píše dobře. Jinak ta přednáška by vám kromě jiného mohla ukázat že zjistit pohledem pohlaví je naprosto normální metoda. U lidí dost spolehlivá narozdíl třeba od papoušků.
tak jaký je teda typ kolonky "biologické pohlaví"? mi vyšlo tohle:
Kód: [Vybrat]
data Sex = Male | Female | Intersexasi v informačním systému pro doktory, ve filtru eshopu
Kód: [Vybrat]
data Sex = Male | Female | Unisex

Není "biologické pohlaví", je pohlaví. Intersexuálové netvoří další pohlaví.
tak řekněme, že typ Sex je výsledek funkce stanovující pohlaví, argumentem můžou být všelijaké biologické ukazatele respektive tvar osoby pro kterou nakupujeme :)
Název: Re:Co si myslíte o OOP?
Přispěvatel: Mirek Prýmek 13. 01. 2019, 16:36:19
Ale spíš se mi zdá že jste to pomotal s pojmem gender a teď se z toho snažíte nějak vymotat a to způsoběm, že to celé označíte za jakýsi "problém".
Vy jste si vybrali jednu definici, tu považujete za "správnou" a neberete v úvahu, že to slovo se může používat i v jiných významech, které třeba tak jednoznačné nejsou. To je samozřejmě v jistém smyslu řešení některých problémů, které nejednoznačnost toho slova přináší. Každý ale s vámi nemusí sdílet názor, že je to řešení nejlepší. A už vůbec s vámi nemusí souhlasit, že jenom toto a nic jiného je přesně význam toho slova.

Jinak ta přednáška by vám kromě jiného mohla ukázat že zjistit pohledem pohlaví je naprosto normální metoda.
Tak to se na ni asi dívat nemusím, protože to je samozřejmé. Obzvlášť pokud člověk mluví česky a nutně musí použít nějaký rod při komunikaci s lidma, jimž nemá možnost udělat genetický test.
Název: Re:Co si myslíte o OOP?
Přispěvatel: Wavelet 13. 01. 2019, 16:39:25
Citace: Kit
Jistě, ve sportu se určuje geneticky, tam je to jasné. Při nákupu oblečení nejen podle morfologie postavy, ale hlavně podle toho, co zákazník chce koupit. Například transvestita může být v civilu zcela jasným mužem, ale v daném obchodě chce vybírat dámské oblečení pro svá vystoupení. Co má zadat do formuláře?
V databázi jako zákazník je muž (pokud to tak zadal), ale preference na doporučení oblečení chce mít ženské. Ten systém bych namodeloval s touto možností. Dře to protože se to snažíž ohnout na jiný scénář než to je namodelované.

Co na tomhle chcete modelovat? V obchodu s oblečením jsou běžně různá oddělení a když půjdu koupit podprsenku, nikoho nezajímá, jestli to je pro manželku nebo pro matku nebo pro ujetého souseda Pepu, zrovna tak v dětském oddělení Vás nechají koupit bryndák bez ohledu na to, jestli máte potvrzení o tom, že máte děti.

Nepochopil jste zadání. Jako zákazník, který vyplní správně pohlaví -- muž, chci aby mi např. systém upřednostnil nabídky ženských šatů, protože jsem tranzvestita nebo prostě nakupuji pro ženu. Pokud by to bral automaticky z pole pohlaví, nastane problém, to žádná. Proto se to musí nějak odlišit, ale to neznamená že problém je v pohlaví, ale v tom, že ten systém musím modelovat jiným způsobem a dodat kontext "zajímám se především o...".

Název: Re:Co si myslíte o OOP?
Přispěvatel: Mirek Prýmek 13. 01. 2019, 16:42:52
Proto se to musí nějak odlišit, ale to neznamená že problém je v pohlaví, ale v tom, že ten systém musím modelovat jiným způsobem a dodat kontext "zajímám se především o...".
Problém je ve slovu "pohlaví", protože ne vždy a ne každý ho musí chápat úzce biologicky a to ještě v nějakém konkrétním technickém významu ("gen X na místě Y", "chromozomy XY", atd).

Existují lidi, kteří jsou biologicky (podle některých kritérií) muži, ale v občance mají napsáno "žena". Pokud se ptám na "pohlaví", musím to nutně upřesnit: biologické pohlaví, administrativně uznané pohlaví, máš pindíka? apod.
Název: Re:Co si myslíte o OOP?
Přispěvatel: Wavelet 13. 01. 2019, 16:48:17
Citace
Vy jste si vybrali jednu definici, tu považujete za "správnou" a neberete v úvahu, že to slovo se může používat i v jiných významech, které třeba tak jednoznačné nejsou. To je samozřejmě v jistém smyslu řešení některých problémů, které nejednoznačnost toho slova přináší. Každý ale s vámi nemusí sdílet názor, že je to řešení nejlepší. A už vůbec s vámi nemusí souhlasit, že jenom toto a nic jiného je přesně význam toho slova.
Ano, vybral jsem definic (vlastně jste ji vybral vy)i, která zapadá do kontextu o které tady mluvíte a tu jste vysvětloval zcestně.
Jinak z různými pojmy, co v jednom žargonu znamenaj tohle a v druhým onodle a ty musím nějak namodelovat se setkávám denně. Přesný opak toho co se mi snažíte říct.

Citace
Tak to se na ni asi dívat nemusím, protože to je samozřejmé. Obzvlášť pokud člověk mluví česky a nutně musí použít nějaký rod při komunikaci s lidma, jimž nemá možnost udělat genetický test.

Když je to tak samozřejmé, proč jste to popíral? Jinak škoda, zajímavá přednáška. Každej má holt svůj obor, nemůžeme rozumět všemu.
Název: Re:Co si myslíte o OOP?
Přispěvatel: Mirek Prýmek 13. 01. 2019, 16:52:10
Když je to tak samozřejmé, proč jste to popíral?
Můžete ocitovat příspěvek, ve kterém jsem to udělal?
Název: Re:Co si myslíte o OOP?
Přispěvatel: Wavelet 13. 01. 2019, 16:54:07
Proto se to musí nějak odlišit, ale to neznamená že problém je v pohlaví, ale v tom, že ten systém musím modelovat jiným způsobem a dodat kontext "zajímám se především o...".
Problém je ve slovu "pohlaví", protože ne vždy a ne každý ho musí chápat úzce biologicky a to ještě v nějakém konkrétním technickém významu ("gen X na místě Y", "chromozomy XY", atd).
Jasně! `Moje filozofie je vymyslet novou filozofii, když jí potřebuju.`
Název: Re:Co si myslíte o OOP?
Přispěvatel: Mirek Prýmek 13. 01. 2019, 16:54:50
Jasně! `Moje filozofie je vymyslet novou filozofii, když jí potřebuju.`
Ne.
Název: Re:Co si myslíte o OOP?
Přispěvatel: Wavelet 13. 01. 2019, 17:02:12
Když je to tak samozřejmé, proč jste to popíral?
Můžete ocitovat příspěvek, ve kterém jsem to udělal?
str. 61
A: Dobře. Takže mám před sebou nějakého člověka. Jakým testem s naprostou jistotou zjistím jeho pohlaví?
B: V drtivé většině pouhým zrakem, jinak podle chromozomů. Každopádně to lze určit.
A: To je velice vágní, je to potřeba upřesnit:
   1. "pouhým zrakem" znamená co? Podívám se, jestli má pindíka?
   ...

Proto sem ti psal o pohlavním dimorfismu, ani se nemusíš koukat na pindíka.
Snažit se někoho přesvědčit, že tahle metoda není 100% je na hranici paranoi -- pokud nejsi papoušek.
Název: Re:Co si myslíte o OOP?
Přispěvatel: Mirek Prýmek 13. 01. 2019, 17:03:51
Když je to tak samozřejmé, proč jste to popíral?
Můžete ocitovat příspěvek, ve kterém jsem to udělal?
str. 61
A: Dobře. Takže mám před sebou nějakého člověka. Jakým testem s naprostou jistotou zjistím jeho pohlaví?
B: V drtivé většině pouhým zrakem, jinak podle chromozomů. Každopádně to lze určit.
A: To je velice vágní, je to potřeba upřesnit:
   1. "pouhým zrakem" znamená co? Podívám se, jestli má pindíka?
   ...
Aha, takže jsem to nepopíral.
Název: Re:Co si myslíte o OOP?
Přispěvatel: v 13. 01. 2019, 17:43:38
Snažit se někoho přesvědčit, že tahle metoda není 100% je na hranici paranoi -- pokud nejsi papoušek.
nebo transgendered
Název: Re:Co si myslíte o OOP?
Přispěvatel: SB 15. 01. 2019, 11:26:25
Ne, Python opravdu není "multiparadigmatický", to je marketingový blábol. Ono v principu vůbec nic takového jako "multiparadigmatický" neexistuje, protože ta paradigmata jsou právě o tom, co ti jazyk nedovolí udělat, ne o tom, co ti dovolí. Když něco z principu nejde -> máš jistotu, že k tomu nedošlo -> máš zaručenou informaci.

Z tohoto pohledu Python není OOP, protože u něj neplatí, že "z principu nejde" měnit vnitřní stav objektu zvenku. Troufnete si to vysvětlovat místním mistrům?
Název: Re:Co si myslíte o OOP?
Přispěvatel: Mirek Prýmek 15. 01. 2019, 11:39:01
Z tohoto pohledu Python není OOP, protože u něj neplatí, že "z principu nejde" měnit vnitřní stav objektu zvenku. Troufnete si to vysvětlovat místním mistrům?
Určitě nemá "ukázkové", "vzorové", "čisté" OOP. Má OOP (a všechno ostatní) "pragmatické" nebo "good enough". Což je v praxi často přesně to, co lidi chtějí (viz https://en.wikipedia.org/wiki/Worse_is_better)
Název: Re:Co si myslíte o OOP?
Přispěvatel: gll 15. 01. 2019, 11:41:16
Ne, Python opravdu není "multiparadigmatický", to je marketingový blábol. Ono v principu vůbec nic takového jako "multiparadigmatický" neexistuje, protože ta paradigmata jsou právě o tom, co ti jazyk nedovolí udělat, ne o tom, co ti dovolí. Když něco z principu nejde -> máš jistotu, že k tomu nedošlo -> máš zaručenou informaci.

Z tohoto pohledu Python není OOP, protože u něj neplatí, že "z principu nejde" měnit vnitřní stav objektu zvenku. Troufnete si to vysvětlovat místním mistrům?

co znamená měnit stav z venku? Přiřazení v Pythonu zavolá metodu __setattr__. Tyhle diskuze vždy skončí dohadováním o slovíčkách.
Název: Re:Co si myslíte o OOP?
Přispěvatel: Kit 15. 01. 2019, 11:45:17
Ne, Python opravdu není "multiparadigmatický", to je marketingový blábol. Ono v principu vůbec nic takového jako "multiparadigmatický" neexistuje, protože ta paradigmata jsou právě o tom, co ti jazyk nedovolí udělat, ne o tom, co ti dovolí. Když něco z principu nejde -> máš jistotu, že k tomu nedošlo -> máš zaručenou informaci.
Z tohoto pohledu Python není OOP, protože u něj neplatí, že "z principu nejde" měnit vnitřní stav objektu zvenku. Troufnete si to vysvětlovat místním mistrům?

Když někdo zvenku zavolá setter, tak také mění stav objektu zvenku. Používání setterů je tedy v rozporu s principy OOP.
Název: Re:Co si myslíte o OOP?
Přispěvatel: SB 15. 01. 2019, 13:42:48
Když někdo zvenku zavolá setter, tak také mění stav objektu zvenku. Používání setterů je tedy v rozporu s principy OOP.

Setter je jako každá metoda uvnitř objektu, takže se nejedná o změnu zvenku. Stav je bez existujícího prostředníka zvenku nedostupný.
Název: Re:Co si myslíte o OOP?
Přispěvatel: SB 15. 01. 2019, 13:44:08
co znamená měnit stav z venku? Přiřazení v Pythonu zavolá metodu __setattr__. Tyhle diskuze vždy skončí dohadováním o slovíčkách.

O způsobech implementace řeč nebyla.
Název: Re:Co si myslíte o OOP?
Přispěvatel: Mirek Prýmek 15. 01. 2019, 14:36:42
Setter je jako každá metoda uvnitř objektu, takže se nejedná o změnu zvenku. Stav je bez existujícího prostředníka zvenku nedostupný.
Mně teda přijde, že to je spíš otázka designová/koncepční. Buď k objektu přistupuju jako ke structu/dementovi, kterého polopaticky řídím, nebo k němu přistupuju jako k dospělému, kterého o něco žádám a sděluju mu, jaké parametry odpovědi by se mi líbily. Nepřijde mi, že by tam byla ostrá hranice.
Název: Re:Co si myslíte o OOP?
Přispěvatel: Setter 15. 01. 2019, 15:07:32
Používání setterů je tedy v rozporu s principy OOP.
https://en.wikipedia.org/wiki/Setter ?
Název: Re:Co si myslíte o OOP?
Přispěvatel: operator 15. 01. 2019, 15:48:26
Odpor vuci dynamickym jazykum zazniva od tech, kteri se v nich pokousi programovat staticky, protoze to jinak neumi.
Jenže svět, který se snažíme v IT modelovat/automatizovat má spíše charakter statických typů....Nikdo se nejmenuje 123456 nebo 10.60 a na výplatu dostanu vždy nějakou částku a ne stokorunčeských...takže oprávněný požadavek dynamických typů zpravidla zaznívá jen tehdy, když někdo něco generalizoval-sloučil. Navíc zákazník zpravidla požaduje ukládat data to staticky typovaných databází...v tomto případě nedává moc smysl zavádět do systému nějakou dynamickou složku.
Ve statickem jazyku jsi nucen svet modelovat staticky, ale on ve skutecnosti staticky neni, kdyz nic jineho, vyviji se v case a je to prave zakaznik, kdo potrebuje aplikaci prizpusobovat.
Název: Re:co si myslite o oop?
Přispěvatel: operator 15. 01. 2019, 15:49:22

P.S. Kadete, k těm typům. Je lepší hodinu bojovat se statickými typy, než týden hledat, proč se to číslo chová divně. Schválně, mám SessionID 231479973001 a používám to jako číslo ve formátu UINT64. Co dostanu, pokud ho první knihovna interně konvertuje do UINT32 (protože na ni od dob 32b nikdo nesáhl), druhá do INT64 (protože signed považuje za nativní formát) a pak zpátky do UINT64? Jaký budeš mít SessionID na konci toho procesu? A uspokojí tě to? Ale co, hlavní je, že ani ty tři warningy při buildu nedostaneš... A to se počítá.
Takže na začátku parsování/verifikace dat na jednom místě, následná logika pak ví, že data jsou validní a jak jsou zabalený. A pokud jsou zabalený jinak, kompilátor to zatepla nabonzuje...

Bez urazky, ale kdyz jsi prase a pouzivas praseci knihovny ktery ti hloupy session id prezvejka do tolika formatu, tak se nedivim, ze potrebujes statickou kontrolu. Ja bych taky odmitnul pracovat na prasecim Python projektu, kdybych tam videl praseciny podobnyho typu. Taky bych byl radsi kdyby to bylo staticky otypovany.

Jenze ja bych vzal ten prasecak, pokusil se najit co se to snazi delat, tj. najit vstupy a vystupy a jak to komunikuje s okolnim svetem, a vyhazet 90% toho chliva ven.

Presne to taky delam ve svy praxi. V tvym pripade bych vyhazel vsechny th black box knihovnh co mi znasilnujou session id, session id bych nahradil pouhym stringem, protoze nepotrebuju delat aritmetiku ani pocitatncialni rovnice se session id.

Kod bych zredukoval na desetinu mozna min ve zlomku casu. To co ostatnim trva mesice, ja dodavam do tydne. Protoze dokazu rychle najit co je v programu potreba a co je balast.

Kdyz to dotahnu do konce a klient je spokojenej muzu zacit konecne optimalizovat. Takze vezmu kritickou sekci a prepisu ji v Cythonu, v C nebo necim podobnym. Nebo napisu kritickou sekci jako cistej C, java program a pospojuju to unix pipelinou. Je mi to prakticky jedno. A vis co. Dneska jsou komoy tak rychly, ze klient radsi zaplati za dve dalsi masiny misto prepisu do rychlejsiho jazyka.

Presne tak.
Název: Re:co si myslite o oop?
Přispěvatel: operator 15. 01. 2019, 15:54:56
Bez urazky, ale kdyz jsi prase a pouzivas praseci knihovny ktery ti hloupy session id prezvejka do tolika formatu, tak se nedivim, ze potrebujes statickou kontrolu...

Já preferuju vlastní kód, ale nikdo ti nezaplatí vývoj vlastních knihoven. Vždycky používáš kód třetí strany a inspekce od kompilátoru se vždycky hodí (resp. je zadarmo).  "Model světa" totiž musíš přechrchlat na byty, aby jim stroj rozuměl a to jsou najednou chyby jak víno. Zaokrouhlování u floatů, přetečení nebo podtečení hodnot,... Prostě je fajn si říct, že to bude tak a ještě lepší si to restriktivně vynutit.

Btw, nemusí to být jenom staticky linkovaný knihovny, může to být kombinace několika jazyků, jedna z těch věcí může běžet na jiným fyzickým stroji,... A o to je to zákařnější - není nad to, když server má 64b hodnoty, klient 32b hodnoty a vývojář se diví. A pokud nezná typy (a s tím i tyhle pasti), tak si pěkně namlátí hubu.

Můj příklad je jenom malinká ukázka, jak to dopadá, když prasata ignorujou typy:
Krok | Typ | Dekadicky | Hexadecimálně | Podrobnosti
0 | uint64 | 231479973001 | 0x0000000035E5481489 | hodnota má 40b
1 | uint32 | 3846706313 | 0xE5481489 | přišli jsme o horních 8b hodnoty
2 | int64 | -448260983 | 0xFFFFFFFFE5481489 | bit 31 = 1 -> záporné číslo
3 | uint64 | 18446744072813029651 | 0xFFFFFFFFE5481489 | Interpretováno jako UINT64

Další past je třeba float - currency. Jak to má sakra kompilátor/interpreter poznat jenom podle toho, že jsou v parsovaným stringu číslice a mezi nima čárka? To jako podle toho, že je před tím "price="? A každej typ se přitom chová jinak...

Zkrátka, volnost typu = volnost kompilátoru = volnost chování výsledné aplikace. Typ je totiž nedílná součást popisu dat. Když kompilátor neví, co použít a jenom tak tam něco práskne, tak je něco blbě v principu.
Svet musis digitalizovat, ale nemusis mit staticka data. V dalsi casti popiras sam sebe. V pythonu bys na to mel jeden univerzalni int a tvuj problem by vubec nenastal. Takze staticke typi te pred timto problemem nechřani,míny ho zpusobuji. Korunujes to v zaveru tvrzenim, ze typ je soucasti dat. Vitej ve svete dynamickych jazyku, tam to opravdu plati.
Název: Re:Co si myslíte o OOP?
Přispěvatel: Kit 15. 01. 2019, 16:47:59
Když někdo zvenku zavolá setter, tak také mění stav objektu zvenku. Používání setterů je tedy v rozporu s principy OOP.

Setter je jako každá metoda uvnitř objektu, takže se nejedná o změnu zvenku. Stav je bez existujícího prostředníka zvenku nedostupný.

Proto by settery měly být privátní.
Název: Re:Co si myslíte o OOP?
Přispěvatel: operator 15. 01. 2019, 16:56:22
je dobré znát ne dva až tři jazyky, ale především dvě až tři paradigmata
V tom je prave dobry python, protoze ti umoznuje jednotliva paradigmata podle potreby prirozene kombinovat.
Tak to se podle mě velice tragicky mýlíš. Pokud chceš nějakému paradigmatu porozumět, musíš si ho vyzkoušet pokud možno v čisté podobě. Protože jenom ta tě donutí opravdu použít daný přístup a neuhýbat jinam. Tj. pokud funkcionální, tak Haskell, ne Scalu. Na Haskellu pochopíš, o co jde, a pak v praxi už můžeš vzít tu Scalu, protože to může být ze spousty důvodů praktičtější.

Ne, Python opravdu není "multiparadigmatický", to je marketingový blábol. Ono v principu vůbec nic takového jako "multiparadigmatický" neexistuje, protože ta paradigmata jsou právě o tom, co ti jazyk nedovolí udělat, ne o tom, co ti dovolí. Když něco z principu nejde -> máš jistotu, že k tomu nedošlo -> máš zaručenou informaci.

Za druhe ruzne paradigmata jsou uzitecna, ale nepotrebujes si kvuli tomu povrchne hrat s hromadou prakticky nevyuzitelnych jazyku.
Potřebuješ, protože žádný jiný způsob, jak jim porozumět, neexistuje.
Porozumění záleží na inteligenci. Kdyby si to každý musel zkoušet, nikdo to nevymyslí. Zrovna tak je to věc sebeovládání.  Ovládat se můžeš sám a nebo potřebuješ, aby někdo ovlédal tebe, ať člověk nebo jazyk nebo statické typy. Někdo radši svobodu a zodpovědnost, někdo radši totalitu a přenesení zodpovědnosti na systém. Python je multiparadigmatický. Paradigma spočívá v přístupu k věci, ne v omezení. Python ti umožňuje různé přístupy. Čisté paradigma je extremismus. Ideální je možnost výběru a flexibilního přizpůsobení se aktuálním potřebám.
Název: Re:Co si myslíte o OOP?
Přispěvatel: Mirek Prýmek 15. 01. 2019, 17:15:33
Python ti umožňuje různé přístupy. Čisté paradigma je extremismus. Ideální je možnost výběru a flexibilního přizpůsobení se aktuálním potřebám.
Jasný. A i JavaScript je multiparadigmatický. A vlastně každý v současnosti existující jazyk. Protože tenhle blábol lidi naučil si myslet, že když má jazyk funkce jako first class citizens, tak je funkcionální. Až na to, že ono je to ve skutečnosti o dost  zajímavější. Jenže to nezjistíš, protože sis "funkcionálně" zaprogramoval v pythonu a nic jinýho nikdy nezkusíš. (tím nemyslím tebe osobně, ale lidi, kteří na tenhle blábol naskočili)
Název: Re:Co si myslíte o OOP?
Přispěvatel: operator 15. 01. 2019, 17:34:40
Python ti umožňuje různé přístupy. Čisté paradigma je extremismus. Ideální je možnost výběru a flexibilního přizpůsobení se aktuálním potřebám.
Jasný. A i JavaScript je multiparadigmatický. A vlastně každý v současnosti existující jazyk. Protože tenhle blábol lidi naučil si myslet, že když má jazyk funkce jako first class citizens, tak je funkcionální. Až na to, že ono je to ve skutečnosti o dost  zajímavější. Jenže to nezjistíš, protože sis "funkcionálně" zaprogramoval v pythonu a nic jinýho nikdy nezkusíš. (tím nemyslím tebe osobně, ale lidi, kteří na tenhle blábol naskočili)
Javascript mám docela rád, na menší věci, dobře se mi v něm píše. Také pragmatický jazyk, byť s pochybným původem. Co je to funkcionální si každý zkusil ve škole na lispu. Funkcionální programování není žádná novinka. A třeba C za multiparadigmatický jazyk nepovažuji, tomu objektové paradigma občas citelně chybí, nebo alespoň jmenné prostory. Viz třeba gtk napsané v C. V pythonu se s ním pracuje mnohem příjeměji a klidně tu může někdo operovat s myšlenkou, že python, kde je všechno objekt, včetně objektů frame a code, není objektový.
Název: Re:Co si myslíte o OOP?
Přispěvatel: Mirek Prýmek 15. 01. 2019, 17:39:02
Co je to funkcionální si každý zkusil ve škole na lispu.
Takže tě přece jenom někdo donutil si ty "nesmyslné" jazyky vyzkoušet. To je dobře :)
Název: Re:Co si myslíte o OOP?
Přispěvatel: operator 15. 01. 2019, 17:42:43
Co je to funkcionální si každý zkusil ve škole na lispu.
Takže tě přece jenom někdo donutil si ty "nesmyslné" jazyky vyzkoušet. To je dobře :)
Netvrdil jsem, že jsou nesmyslné, ale v praxi nepraktické a že se pragmaticky radši zabývám věcmi praktickými.
Název: Re:Co si myslíte o OOP?
Přispěvatel: gll 15. 01. 2019, 17:55:24
Co je to funkcionální si každý zkusil ve škole na lispu.
Takže tě přece jenom někdo donutil si ty "nesmyslné" jazyky vyzkoušet. To je dobře :)
Netvrdil jsem, že jsou nesmyslné, ale v praxi nepraktické a že se pragmaticky radši zabývám věcmi praktickými.

V praxi je nepraktická i přílišná volnost.
Název: Re:Co si myslíte o OOP?
Přispěvatel: operator 15. 01. 2019, 18:07:10
Co je to funkcionální si každý zkusil ve škole na lispu.
Takže tě přece jenom někdo donutil si ty "nesmyslné" jazyky vyzkoušet. To je dobře :)
Netvrdil jsem, že jsou nesmyslné, ale v praxi nepraktické a že se pragmaticky radši zabývám věcmi praktickými.
V praxi je nepraktická i přílišná volnost.
Proto davam prednost pythonu se silnymi typy, dnes i moznosti typehintingu.
Název: Re:Co si myslíte o OOP?
Přispěvatel: Mirek Prýmek 15. 01. 2019, 18:24:52
V praxi je nepraktická i přílišná volnost.
Mně vůbec celá praxe přijde taková nepraktická.
Název: Re:Co si myslíte o OOP?
Přispěvatel: operator 15. 01. 2019, 22:27:41
V praxi je nepraktická i přílišná volnost.
Mně vůbec celá praxe přijde taková nepraktická.
(https://cdn-images-1.medium.com/max/1600/0*ZglaEb3qQK6xCBC6.png)
Název: Re:Co si myslíte o OOP?
Přispěvatel: gll 16. 01. 2019, 10:30:11
Proto davam prednost pythonu se silnymi typy, dnes i moznosti typehintingu.

to právě funguje jen s podmnožinou pythonu. Když nějaká knihovna používá metaclassy, nebo jinak dynamicky generuje typy, tak se to musí řešit mypy pluginem. Většina pluginů pouze potlačí chybové hlášky.
Název: Re:Co si myslíte o OOP?
Přispěvatel: SB 16. 01. 2019, 11:35:48
Setter je jako každá metoda uvnitř objektu, takže se nejedná o změnu zvenku. Stav je bez existujícího prostředníka zvenku nedostupný.
Mně teda přijde, že to je spíš otázka designová/koncepční. Buď k objektu přistupuju jako ke structu/dementovi, kterého polopaticky řídím, nebo k němu přistupuju jako k dospělému, kterého o něco žádám a sděluju mu, jaké parametry odpovědi by se mi líbily. Nepřijde mi, že by tam byla ostrá hranice.

Funkčně může znamenat vyventilování stavů degeneraci objektu na struct, ale technicky pořád platí, že stav je sám o sobě zvenku nedostupný (nepočítám jazyky, co můžou stav rovnou udělat public).
Název: Re:Co si myslíte o OOP?
Přispěvatel: SB 16. 01. 2019, 11:40:44
Setter je jako každá metoda uvnitř objektu, takže se nejedná o změnu zvenku. Stav je bez existujícího prostředníka zvenku nedostupný.

Proto by settery měly být privátní.

Sice nevím, co tím myslíte, ale existuje jednodušší řešení - zapomeňte na settery, je to nadbytečný "koncept".
Název: Re:Co si myslíte o OOP?
Přispěvatel: SB 16. 01. 2019, 11:45:58
...A třeba C za multiparadigmatický jazyk nepovažuji, tomu objektové paradigma občas citelně chybí...

Jak může C chybět OOP, když není konstruované pro daný typ úloh, pro danou úroveň abstrakce? To byste mohl pak říci o každém jazyku, že mu chybí OOP.
Název: Re:Co si myslíte o OOP?
Přispěvatel: Kit 16. 01. 2019, 13:24:43
Setter je jako každá metoda uvnitř objektu, takže se nejedná o změnu zvenku. Stav je bez existujícího prostředníka zvenku nedostupný.
Proto by settery měly být privátní.
Sice nevím, co tím myslíte, ale existuje jednodušší řešení - zapomeňte na settery, je to nadbytečný "koncept".

Zcela souhlasím. Jsou zbytečné.
Název: Re:co si myslite o oop?
Přispěvatel: PetrM 16. 01. 2019, 13:39:14
Svet musis digitalizovat, ale nemusis mit staticka data.

Pokud svět musím digitalizovat, jsou tam dvě kvantizace - hodnota (např. ADC s rozlišením 12 bitů) a čas (vzorkování po např. 120ns). Příchod dalšího vzorku = změna stavu objektu.

V dalsi casti popiras sam sebe. V pythonu bys na to mel jeden univerzalni int a tvuj problem by vubec nenastal. Takze staticke typi te pred timto problemem nechřani,míny ho zpusobuji.

Kontrolní otázky:
- Jak Python interně ukládá ten INT?
- Pokud uložím INT do binárního souboru a načtu ho do programu v C++, budu kompatibilní?
- Budu kompatibilní, pokud ten Python spustím na 32-bit RPi a soubor otevřu v nativní aplikaci na AMD64 psané dejme tomu v C#?
- Jakou velikost bude mít ten soubor, když v něm bude pole 100 000 000 intů?
Název: Re:Co si myslíte o OOP?
Přispěvatel: PetrM 16. 01. 2019, 13:41:39
...A třeba C za multiparadigmatický jazyk nepovažuji, tomu objektové paradigma občas citelně chybí...

Cčku chybí plno věcí, ale zrovna objekty se dají celkem dobře vytvořit. Bjarne Stroustrupovi k tomu stačil preprocesor...
Název: Re:co si myslite o oop?
Přispěvatel: Kadet 16. 01. 2019, 14:20:43
Svet musis digitalizovat, ale nemusis mit staticka data.

Pokud svět musím digitalizovat, jsou tam dvě kvantizace - hodnota (např. ADC s rozlišením 12 bitů) a čas (vzorkování po např. 120ns). Příchod dalšího vzorku = změna stavu objektu.
Pokud '=' znamena ekvivalence, pak velky omyl. Prichod dalsiho vzorku muzu modelovat tak, ze ho prilepim na konec seznamu vsech vzorku a nic pri to menit nemusim.

V dalsi casti popiras sam sebe. V pythonu bys na to mel jeden univerzalni int a tvuj problem by vubec nenastal. Takze staticke typi te pred timto problemem nechřani,míny ho zpusobuji.

Kontrolní otázky:
- Jak Python interně ukládá ten INT?
- Pokud uložím INT do binárního souboru a načtu ho do programu v C++, budu kompatibilní?
- Budu kompatibilní, pokud ten Python spustím na 32-bit RPi a soubor otevřu v nativní aplikaci na AMD64 psané dejme tomu v C#?
- Jakou velikost bude mít ten soubor, když v něm bude pole 100 000 000 intů?

Je jedno jak Python uklada inty. Treba je ma ulozeny v cloudu a taha je pres sit. Je to abstrakce za kterou muze byt cokoliv. Ale pravdepodobne to bude ulozeny jako bytearray s variabilni velikosti.

Do binarniho souboru budes ukladat serializovanou reprezentaci. Zadnej dump internich struktur a srani se s endianem jako to delaji prasata v c++.

List bude mit umernou hodnotu velikosti ulozenych dat. 100m intu, log n bitu na kazdy integer. Ty jsi ho asi chtel nachytat na tom, ze int je fixed size datatype.

Polozil bych tu otazku jinak. Jakou velikost bude mit soubor kdyz v nem bude pole 100 000 000 stringu?
Název: Re:Co si myslíte o OOP?
Přispěvatel: operator 16. 01. 2019, 14:34:08
...A třeba C za multiparadigmatický jazyk nepovažuji, tomu objektové paradigma občas citelně chybí...

Jak může C chybět OOP, když není konstruované pro daný typ úloh, pro danou úroveň abstrakce? To byste mohl pak říci o každém jazyku, že mu chybí OOP.
a) Nemohl, protoze ne vsem jazykum chybi.
b) Jazyku C chybi proto, ze pro nej vznikaji veci jako gtk, kde by se - byt treba primitivni a jednoduche - OOP zatracene hodilo.
Název: Re:co si myslite o oop?
Přispěvatel: operator 16. 01. 2019, 14:49:02
Svet musis digitalizovat, ale nemusis mit staticka data.

Pokud svět musím digitalizovat, jsou tam dvě kvantizace - hodnota (např. ADC s rozlišením 12 bitů) a čas (vzorkování po např. 120ns). Příchod dalšího vzorku = změna stavu objektu.

V dalsi casti popiras sam sebe. V pythonu bys na to mel jeden univerzalni int a tvuj problem by vubec nenastal. Takze staticke typi te pred timto problemem nechřani,míny ho zpusobuji.

Kontrolní otázky:
- Jak Python interně ukládá ten INT?
- Pokud uložím INT do binárního souboru a načtu ho do programu v C++, budu kompatibilní?
- Budu kompatibilní, pokud ten Python spustím na 32-bit RPi a soubor otevřu v nativní aplikaci na AMD64 psané dejme tomu v C#?
- Jakou velikost bude mít ten soubor, když v něm bude pole 100 000 000 intů?
Ano, data musim zjednodusit,  ale z toho nevyplyva, ze datovy model musi byt staticky a nemuze se prubezne menit.

Int je v Pythonu objekt, jeho interni reprezentace je interni, o tu se nestaras a ani nemas starat, nema zadnou nativni binarni reprezentaci, jeho  nativni  repr()  reprezentace je textova, ktera funguje napric vsemi platformami. Jak si ho ulozis do binarního souboru pomoci struct je na tobe a stejnym zpusobem ho pak musis nacist, coz funguje spolehlive napric platformami. Za vyjimku by slo povazovat pickle, ktere ma i binarni format, opet kompatibilni napric platformami, pokud obe strany podporuji stejnou verzi protokolu.
Název: Re:co si myslite o oop?
Přispěvatel: PetrM 16. 01. 2019, 15:01:55
Pokud '=' znamena ekvivalence, pak velky omyl. Prichod dalsiho vzorku muzu modelovat tak, ze ho prilepim na konec seznamu vsech vzorku a nic pri to menit nemusim.

V tom případě je tam objekt "fronta dat", který změní svůj stav (už neí prázdný, přetekl, nebo došel do stavu, kdy vynutí zpracování s vyšší prioritou,...).

Pointa je taková, že hodnoty i čas jsou v digitálním modelu světa nespojitý. A je potřeba s tím počítat.

Je jedno jak Python uklada inty. Treba je ma ulozeny v cloudu a taha je pres sit. Je to abstrakce za kterou muze byt cokoliv. Ale pravdepodobne to bude ulozeny jako bytearray s variabilni velikosti.

Do binarniho souboru budes ukladat serializovanou reprezentaci. Zadnej dump internich struktur a srani se s endianem jako to delaji prasata v c++.

List bude mit umernou hodnotu velikosti ulozenych dat. 100m intu, log n bitu na kazdy integer. Ty jsi ho asi chtel nachytat na tom, ze int je fixed size datatype.

Polozil bych tu otazku jinak. Jakou velikost bude mit soubor kdyz v nem bude pole 100 000 000 stringu?

Aha. Takže dynamický pole bytů, hmm. Tak to je super. Takže 100 se uloží do 1B, 200 do dvou (počítám signed) a když někde budu mít 100k, bude to ve třech... A k tomu ještě nějaký info, jak sou ty data velký. A rozbitej alignment... No jedno lepší jak druhý:

- pokud chce nějak ty čísla násobit/dělit, musíš to přechroupat do jinýho standardu. Takže za běhu vybrat, že INT16 * INT64 chce konverzi INT16 na INT64 s taháním po bytech (protože alignment), pak že požiješ INT64*INT64 a podle výsledku alokuješ pole (klidně 10B), do kterýho to nasypeš. Takže tam, kde by stačila jedna verze natvrdo, máš cyklus na čtení, rozhodování o operaci za běhu, několik aletrnativ matematické funkce, ukládání v cyklu.
- Pokud chceš I/O operaci, musíš to přechroustat na to tvoje pěkný bytový pole. zase pěkně v cyklu, místo jedné instrukce pro data šířky sběrnice. Ve finále stejně musíš deklarovat, jak to do toho bitovýho streamu budeš sypat. No není to super?
- A pokud to hážeš na interní stringy, tak máš navíc pro čtení INT64 z RAMky 18*(RD + MUL10 + ADD). Zapsat číslo je ještě o trochu horší, 18*(MOD10 + DIV10 + WR). MUL, MOD a DIV jsou nejdražší operace a bez násobičky, která současně vyplivne dělení i zbytek, jsi v pr...

Python znamená Krajta. Největší škrtiči na světě. Už mám jasno, proč zvolili tohle slovo - takovýho škrtiče výkonu aby člověk pohledal. Nedivím se, že je program v Pythonu obvykle pomalejší než Ťokovo budování dálnic...  ;D
Název: Re:co si myslite o oop?
Přispěvatel: Kadet 16. 01. 2019, 15:18:08
Pokud '=' znamena ekvivalence, pak velky omyl. Prichod dalsiho vzorku muzu modelovat tak, ze ho prilepim na konec seznamu vsech vzorku a nic pri to menit nemusim.

V tom případě je tam objekt "fronta dat", který změní svůj stav (už neí prázdný, přetekl, nebo došel do stavu, kdy vynutí zpracování s vyšší prioritou,...).

Pointa je taková, že hodnoty i čas jsou v digitálním modelu světa nespojitý. A je potřeba s tím počítat.

Je jedno jak Python uklada inty. Treba je ma ulozeny v cloudu a taha je pres sit. Je to abstrakce za kterou muze byt cokoliv. Ale pravdepodobne to bude ulozeny jako bytearray s variabilni velikosti.

Do binarniho souboru budes ukladat serializovanou reprezentaci. Zadnej dump internich struktur a srani se s endianem jako to delaji prasata v c++.

List bude mit umernou hodnotu velikosti ulozenych dat. 100m intu, log n bitu na kazdy integer. Ty jsi ho asi chtel nachytat na tom, ze int je fixed size datatype.

Polozil bych tu otazku jinak. Jakou velikost bude mit soubor kdyz v nem bude pole 100 000 000 stringu?

Aha. Takže dynamický pole bytů, hmm. Tak to je super. Takže 100 se uloží do 1B, 200 do dvou (počítám signed) a když někde budu mít 100k, bude to ve třech... A k tomu ještě nějaký info, jak sou ty data velký. A rozbitej alignment... No jedno lepší jak druhý:

- pokud chce nějak ty čísla násobit/dělit, musíš to přechroupat do jinýho standardu. Takže za běhu vybrat, že INT16 * INT64 chce konverzi INT16 na INT64 s taháním po bytech (protože alignment), pak že požiješ INT64*INT64 a podle výsledku alokuješ pole (klidně 10B), do kterýho to nasypeš. Takže tam, kde by stačila jedna verze natvrdo, máš cyklus na čtení, rozhodování o operaci za běhu, několik aletrnativ matematické funkce, ukládání v cyklu.
- Pokud chceš I/O operaci, musíš to přechroustat na to tvoje pěkný bytový pole. zase pěkně v cyklu, místo jedné instrukce pro data šířky sběrnice. Ve finále stejně musíš deklarovat, jak to do toho bitovýho streamu budeš sypat. No není to super?
- A pokud to hážeš na interní stringy, tak máš navíc pro čtení INT64 z RAMky 18*(RD + MUL10 + ADD). Zapsat číslo je ještě o trochu horší, 18*(MOD10 + DIV10 + WR). MUL, MOD a DIV jsou nejdražší operace a bez násobičky, která současně vyplivne dělení i zbytek, jsi v pr...

Python znamená Krajta. Největší škrtiči na světě. Už mám jasno, proč zvolili tohle slovo - takovýho škrtiče výkonu aby člověk pohledal. Nedivím se, že je program v Pythonu obvykle pomalejší než Ťokovo budování dálnic...  ;D

Vzorky:
1. Muzu tu zpravu o novym vzorku poslat dal a ve svym systemu nic neukladat.
2. muzu s tim rovnou pracovat aniz bych to ukladal

python a inty:
pripada mi, ze jsi zamrznul cca tri desetileti nazpet a porad se snazis optimalizovat driv nez vyresis problem. Ztracis se tak v ruznych loopech, bitech, bajtech a podobnych low level srackach. Mezitim se svet posunul a zacal pouzivat abstrakce aby tenhle prasecak nemusel resit.

Pokud porad programujes na ENIACu, tak te chapu.
Název: Re:co si myslite o oop?
Přispěvatel: gll 16. 01. 2019, 15:22:20
Pokud '=' znamena ekvivalence, pak velky omyl. Prichod dalsiho vzorku muzu modelovat tak, ze ho prilepim na konec seznamu vsech vzorku a nic pri to menit nemusim.

V tom případě je tam objekt "fronta dat", který změní svůj stav (už neí prázdný, přetekl, nebo došel do stavu, kdy vynutí zpracování s vyšší prioritou,...).

Pointa je taková, že hodnoty i čas jsou v digitálním modelu světa nespojitý. A je potřeba s tím počítat.

Je jedno jak Python uklada inty. Treba je ma ulozeny v cloudu a taha je pres sit. Je to abstrakce za kterou muze byt cokoliv. Ale pravdepodobne to bude ulozeny jako bytearray s variabilni velikosti.

Do binarniho souboru budes ukladat serializovanou reprezentaci. Zadnej dump internich struktur a srani se s endianem jako to delaji prasata v c++.

List bude mit umernou hodnotu velikosti ulozenych dat. 100m intu, log n bitu na kazdy integer. Ty jsi ho asi chtel nachytat na tom, ze int je fixed size datatype.

Polozil bych tu otazku jinak. Jakou velikost bude mit soubor kdyz v nem bude pole 100 000 000 stringu?

Aha. Takže dynamický pole bytů, hmm. Tak to je super. Takže 100 se uloží do 1B, 200 do dvou (počítám signed) a když někde budu mít 100k, bude to ve třech... A k tomu ještě nějaký info, jak sou ty data velký. A rozbitej alignment... No jedno lepší jak druhý:

- pokud chce nějak ty čísla násobit/dělit, musíš to přechroupat do jinýho standardu. Takže za běhu vybrat, že INT16 * INT64 chce konverzi INT16 na INT64 s taháním po bytech (protože alignment), pak že požiješ INT64*INT64 a podle výsledku alokuješ pole (klidně 10B), do kterýho to nasypeš. Takže tam, kde by stačila jedna verze natvrdo, máš cyklus na čtení, rozhodování o operaci za běhu, několik aletrnativ matematické funkce, ukládání v cyklu.
- Pokud chceš I/O operaci, musíš to přechroustat na to tvoje pěkný bytový pole. zase pěkně v cyklu, místo jedné instrukce pro data šířky sběrnice. Ve finále stejně musíš deklarovat, jak to do toho bitovýho streamu budeš sypat. No není to super?
- A pokud to hážeš na interní stringy, tak máš navíc pro čtení INT64 z RAMky 18*(RD + MUL10 + ADD). Zapsat číslo je ještě o trochu horší, 18*(MOD10 + DIV10 + WR). MUL, MOD a DIV jsou nejdražší operace a bez násobičky, která současně vyplivne dělení i zbytek, jsi v pr...

Python znamená Krajta. Největší škrtiči na světě. Už mám jasno, proč zvolili tohle slovo - takovýho škrtiče výkonu aby člověk pohledal. Nedivím se, že je program v Pythonu obvykle pomalejší než Ťokovo budování dálnic...  ;D

Něco si k tomu vygooglete. Začněte tutoriálem. Tady vám to nikdo do podrobna nevysvětlí, zbytečně o bychom přepisovali dokumentaci.

pro úspornou reprezentaci pole čísel můžete použít třeba array.array nebo numpy.array

https://docs.python.org/3/library/array.html
Název: Re:co si myslite o oop?
Přispěvatel: operator 16. 01. 2019, 15:25:54
Svet musis digitalizovat, ale nemusis mit staticka data.

Pokud svět musím digitalizovat, jsou tam dvě kvantizace - hodnota (např. ADC s rozlišením 12 bitů) a čas (vzorkování po např. 120ns). Příchod dalšího vzorku = změna stavu objektu.
Pokud '=' znamena ekvivalence, pak velky omyl. Prichod dalsiho vzorku muzu modelovat tak, ze ho prilepim na konec seznamu vsech vzorku a nic pri to menit nemusim.

V dalsi casti popiras sam sebe. V pythonu bys na to mel jeden univerzalni int a tvuj problem by vubec nenastal. Takze staticke typi te pred timto problemem nechřani,míny ho zpusobuji.

Kontrolní otázky:
- Jak Python interně ukládá ten INT?
- Pokud uložím INT do binárního souboru a načtu ho do programu v C++, budu kompatibilní?
- Budu kompatibilní, pokud ten Python spustím na 32-bit RPi a soubor otevřu v nativní aplikaci na AMD64 psané dejme tomu v C#?
- Jakou velikost bude mít ten soubor, když v něm bude pole 100 000 000 intů?

Je jedno jak Python uklada inty. Treba je ma ulozeny v cloudu a taha je pres sit. Je to abstrakce za kterou muze byt cokoliv. Ale pravdepodobne to bude ulozeny jako bytearray s variabilni velikosti.

Do binarniho souboru budes ukladat serializovanou reprezentaci. Zadnej dump internich struktur a srani se s endianem jako to delaji prasata v c++.

List bude mit umernou hodnotu velikosti ulozenych dat. 100m intu, log n bitu na kazdy integer. Ty jsi ho asi chtel nachytat na tom, ze int je fixed size datatype.

Polozil bych tu otazku jinak. Jakou velikost bude mit soubor kdyz v nem bude pole 100 000 000 stringu?
Koukam zes to odpovedel za me.
Název: Re:co si myslite o oop?
Přispěvatel: operator 16. 01. 2019, 15:36:05
Pokud '=' znamena ekvivalence, pak velky omyl. Prichod dalsiho vzorku muzu modelovat tak, ze ho prilepim na konec seznamu vsech vzorku a nic pri to menit nemusim.

V tom případě je tam objekt "fronta dat", který změní svůj stav (už neí prázdný, přetekl, nebo došel do stavu, kdy vynutí zpracování s vyšší prioritou,...).

Pointa je taková, že hodnoty i čas jsou v digitálním modelu světa nespojitý. A je potřeba s tím počítat.
Ale to nikdo nerozporuje, jen jde o to, ze struktura ulozeni dat muze byt samopopisna a dynamicka, nemusi byt staticka a nemenna.
Citace

Je jedno jak Python uklada inty. Treba je ma ulozeny v cloudu a taha je pres sit. Je to abstrakce za kterou muze byt cokoliv. Ale pravdepodobne to bude ulozeny jako bytearray s variabilni velikosti.

Do binarniho souboru budes ukladat serializovanou reprezentaci. Zadnej dump internich struktur a srani se s endianem jako to delaji prasata v c++.

List bude mit umernou hodnotu velikosti ulozenych dat. 100m intu, log n bitu na kazdy integer. Ty jsi ho asi chtel nachytat na tom, ze int je fixed size datatype.

Polozil bych tu otazku jinak. Jakou velikost bude mit soubor kdyz v nem bude pole 100 000 000 stringu?

Aha. Takže dynamický pole bytů, hmm. Tak to je super. Takže 100 se uloží do 1B, 200 do dvou (počítám signed) a když někde budu mít 100k, bude to ve třech... A k tomu ještě nějaký info, jak sou ty data velký. A rozbitej alignment... No jedno lepší jak druhý:

- pokud chce nějak ty čísla násobit/dělit, musíš to přechroupat do jinýho standardu. Takže za běhu vybrat, že INT16 * INT64 chce konverzi INT16 na INT64 s taháním po bytech (protože alignment), pak že požiješ INT64*INT64 a podle výsledku alokuješ pole (klidně 10B), do kterýho to nasypeš. Takže tam, kde by stačila jedna verze natvrdo, máš cyklus na čtení, rozhodování o operaci za běhu, několik aletrnativ matematické funkce, ukládání v cyklu.
- Pokud chceš I/O operaci, musíš to přechroustat na to tvoje pěkný bytový pole. zase pěkně v cyklu, místo jedné instrukce pro data šířky sběrnice. Ve finále stejně musíš deklarovat, jak to do toho bitovýho streamu budeš sypat. No není to super?
- A pokud to hážeš na interní stringy, tak máš navíc pro čtení INT64 z RAMky 18*(RD + MUL10 + ADD). Zapsat číslo je ještě o trochu horší, 18*(MOD10 + DIV10 + WR). MUL, MOD a DIV jsou nejdražší operace a bez násobičky, která současně vyplivne dělení i zbytek, jsi v pr...

Python znamená Krajta. Největší škrtiči na světě. Už mám jasno, proč zvolili tohle slovo - takovýho škrtiče výkonu aby člověk pohledal. Nedivím se, že je program v Pythonu obvykle pomalejší než Ťokovo budování dálnic...  ;D

Ano, je to super, pohodlne se s tim pracuje, je vyloucena rada chyb s kterymi senty potykas, takze vyvoj je rychly, bezproblemovy a levny. Stoji to jen trochu pameti a vykonu navic, coz v dnesni dobe na vetsinu uloh neni zadny problem a optimalizuje se to nanvykon teprve tehdy, kdyz to ma smysl. Neni problem v pythonu programovat na raspberry pi, takze bezne uzivatelske stroje, o nekolik rwdu vykonnejsi jsou hodne za vodou. A optimalizovat kriticka mista v Python kodu a prepsat je do C je dnes hracka, protoze Cython.
Název: Re:Co si myslíte o OOP?
Přispěvatel: operator 16. 01. 2019, 16:18:13
Jsem rad, ze tu PetrM ma sarkasticke pripominky. Ono to krasne dokazuje omezenost mysleni 'statickych' programatoru, jejich mimoradne hlubokou brazdu statickeho mysleni, ze ktere nejen ze neumi vyjet, oni z ni uz ani nevidi ven. Ukazuje to, ze dokazi veci nazirat jen jednim zazitym zpusobem a tim jsou svazani. A vysvetluje to, proc nemaji radi dynamicke jazyky. Se svym statickm stylem mysleni nedokazi  vyuzivat jejich vyhodnych vlastnosti, snazi se je pouzivat staticky, coz samozrejme nefunguje dobre a oni jsou tim frustrovani.
Název: Re:co si myslite o oop?
Přispěvatel: Kit 16. 01. 2019, 16:47:58
- pokud chce nějak ty čísla násobit/dělit, musíš to přechroupat do jinýho standardu. Takže za běhu vybrat, že INT16 * INT64 chce konverzi INT16 na INT64 s taháním po bytech (protože alignment), pak že požiješ INT64*INT64 a podle výsledku alokuješ pole (klidně 10B), do kterýho to nasypeš. Takže tam, kde by stačila jedna verze natvrdo, máš cyklus na čtení, rozhodování o operaci za běhu, několik aletrnativ matematické funkce, ukládání v cyklu.

Zase ho nezaskočí výpočet 500**8 jako třeba v C. Podobně nebudeš mít problémy s poli, které jsou v C běžné. Nativní výpočty s komplexními čísly jsou určitě výhodnější než přes nějaké knihovny.

Jazyk C je prostě zastaralý a drží se jen díky tomu, že pro vývoj nízkoúrovňových komponent operačního systému není nic lepšího. Na aplikace se však nehodí.
Název: Re:Co si myslíte o OOP?
Přispěvatel: Mirek Prýmek 16. 01. 2019, 17:03:59
Ono to krasne dokazuje omezenost mysleni 'statickych' programatoru
Mno... Zaznelo tady "muzes pouzit numpy.array". Neni to nahodou implementovano staticky v cythonu nebo rovnou v C? :)
Název: Re:Co si myslíte o OOP?
Přispěvatel: gll 16. 01. 2019, 17:17:31
Ono to krasne dokazuje omezenost mysleni 'statickych' programatoru
Mno... Zaznelo tady "muzes pouzit numpy.array". Neni to nahodou implementovano staticky v cythonu nebo rovnou v C? :)

Ani ne. Typová informace je součástí toho objektu. Typová kontrola probíhá za běhu.
Název: Re:Co si myslíte o OOP?
Přispěvatel: Mirek Prýmek 16. 01. 2019, 17:19:22
Ani ne. Typová informace je součástí toho objektu. Typová kontrola probíhá za běhu.
Nemluvil jsem o tom, kde je typová kontrola, ale o tom, v čem je to implementováno.
Název: Re:Co si myslíte o OOP?
Přispěvatel: gll 16. 01. 2019, 17:22:44
Ani ne. Typová informace je součástí toho objektu. Typová kontrola probíhá za běhu.
Nemluvil jsem o tom, kde je typová kontrola, ale o tom, v čem je to implementováno.

je to implementováno stejně jako všechny vestavěné typy cpythonu.
Název: Re:Co si myslíte o OOP?
Přispěvatel: Mirek Prýmek 16. 01. 2019, 17:24:39
je to implementováno stejně jako všechny vestavěné typy cpythonu.
Ani mi to moc nepřijde: https://github.com/numpy/numpy/blob/master/numpy/core/src/common/array_assign.c
Název: Re:Co si myslíte o OOP?
Přispěvatel: gll 16. 01. 2019, 17:52:36
je to implementováno stejně jako všechny vestavěné typy cpythonu.
Ani mi to moc nepřijde: https://github.com/numpy/numpy/blob/master/numpy/core/src/common/array_assign.c

to jsou jen pomocné funkce, které přímo z pythonu volat nelze.

ndarray je implementováno tady

https://github.com/numpy/numpy/blob/master/numpy/core/src/multiarray/arrayobject.c

všechny vestavěné typy jsou implementovány v C, není rozdíl mezi rozšiřujícím typem a vestavěným typem.

https://docs.python.org/3/extending/newtypes_tutorial.html

Název: Re:Co si myslíte o OOP?
Přispěvatel: operator 16. 01. 2019, 17:54:57
Ono to krasne dokazuje omezenost mysleni 'statickych' programatoru
Mno... Zaznelo tady "muzes pouzit numpy.array". Neni to nahodou implementovano staticky v cythonu nebo rovnou v C? :)
Celý Python je implementován v C a ten zase generuje strojový kód. A co má být? Ze sportovních důvodů existuje C compiler implementovaný v Pythonu, viz https://github.com/ShivamSarodia/ShivyC
Název: Re:Co si myslíte o OOP?
Přispěvatel: Mirek Prýmek 16. 01. 2019, 18:25:48
ndarray je implementováno tady

https://github.com/numpy/numpy/blob/master/numpy/core/src/multiarray/arrayobject.c

všechny vestavěné typy jsou implementovány v C, není rozdíl mezi rozšiřujícím typem a vestavěným typem.

https://docs.python.org/3/extending/newtypes_tutorial.html
Vůbec nerozumím, co se snažíš říct.
Název: Re:Co si myslíte o OOP?
Přispěvatel: gll 16. 01. 2019, 18:36:48
ndarray je implementováno tady

https://github.com/numpy/numpy/blob/master/numpy/core/src/multiarray/arrayobject.c

všechny vestavěné typy jsou implementovány v C, není rozdíl mezi rozšiřujícím typem a vestavěným typem.

https://docs.python.org/3/extending/newtypes_tutorial.html
Vůbec nerozumím, co se snažíš říct.

co jsi chtěl říct ty tím odkazem?
Název: Re:Co si myslíte o OOP?
Přispěvatel: Mirek Prýmek 16. 01. 2019, 18:38:29
co jsi chtěl říct ty tím odkazem?
No já jsem reagoval na to, na co jsem reagoval: https://forum.root.cz/index.php?topic=20380.msg304009#msg304009
Název: Re:Co si myslíte o OOP?
Přispěvatel: Dor 16. 01. 2019, 18:47:43
Ohledně OPP si myslím, že je vhodné pro něco, co si drží nějaké stavy. Např. desktopová aplikace. A hlavně si myslím, že z těch, kteří tvrdí, že umějí OOP, pak 80% porgramátorů přinejmenším zneužívá dědičnost pro sdílení kódu a hrubě pourušují SRP. Tolik k OOP.

Jinak mi přijde, že když už to tu není úplné OT o pohlavích, tak stejně si tu namísto debaty o OPP hodně lidí obhajuje nějaký svůj jazyk a debata se stáčí na dynamické typování, enumy a věci, které imho s OOP tolik nesouvisí.
Název: Re:Co si myslíte o OOP?
Přispěvatel: Kadet 16. 01. 2019, 19:48:28
Ohledně OPP si myslím, že je vhodné pro něco, co si drží nějaké stavy. Např. desktopová aplikace. A hlavně si myslím, že z těch, kteří tvrdí, že umějí OOP, pak 80% porgramátorů přinejmenším zneužívá dědičnost pro sdílení kódu a hrubě pourušují SRP. Tolik k OOP.

Jinak mi přijde, že když už to tu není úplné OT o pohlavích, tak stejně si tu namísto debaty o OPP hodně lidí obhajuje nějaký svůj jazyk a debata se stáčí na dynamické typování, enumy a věci, které imho s OOP tolik nesouvisí.

Jinymi slovy, OOP = simulace. Napr. GUI, OS, cokoliv co pracuje se stavem.

Jednou jsem delal na projektu grafickyho editoru, co fungoval na tomhle principu manipulace se stavem. Pak jsem mel pridat funkcionalitu undo/redo. Ukazalo se, ze musim kazdou operaci (tj. zmenu stavu) reprezentovat explicitne a ulozit jit do nejakyho zasobniku, do kteryho pushuju a popuju podle toho jestli delam undo nebo redo.

Pak mi doslo proc to neudelat od zacatku tak, ze misto reprezentovani stavu (tj. v pameti jsou uchovany objekty a dat. struktury reprezentujici stav) muzu reprezentovat v pameti prechody mezi temi stavy. Neco jako dualni problem k reprezentaci stavu. Je to pak vyhodnejsi protoze, muzu celou simulaci prehrat od zacatku, kdyz neco testuju napr. Nemusim mit testera co vyklikava rucne vsechny stavy nez se dostane k bugu. Proste prehraju log operaci a sleduju jak se to promita do zmeny stavu systemu.

Nekdo tomu rika event sourcing, nekdo funkcionalni programovani, nekdo programovani s explicitnim casem.

Pro me je otazka OOP vs funkcionalni, apod
 nepodstatna. Ve funkcionalnim i OOP jazyce muzu napsat stavovou nebo prechodovou simulaci. Co je pro me dulezity je prave to jak na system pohlizim a jak ho reprezentuju.

Za me jasne vitezi reprezentovat zmeny systemu explicitne a stav systemu jako side produkt. Kdezto vetsina programatoru reprezentuje stav systemu explicitne a reprezentace prechodu mezi stavy je volatilni a tak nejak se vypari po zavolani metody.
Název: Re:Co si myslíte o OOP?
Přispěvatel: operator 16. 01. 2019, 20:07:10
Ohledně OPP si myslím, že je vhodné pro něco, co si drží nějaké stavy. Např. desktopová aplikace. A hlavně si myslím, že z těch, kteří tvrdí, že umějí OOP, pak 80% porgramátorů přinejmenším zneužívá dědičnost pro sdílení kódu a hrubě pourušují SRP. Tolik k OOP.

Jinak mi přijde, že když už to tu není úplné OT o pohlavích, tak stejně si tu namísto debaty o OPP hodně lidí obhajuje nějaký svůj jazyk a debata se stáčí na dynamické typování, enumy a věci, které imho s OOP tolik nesouvisí.
OOP je dobre treba na datove objekty, na vytvareni novych datovych typu. Zvlaste kdyz je jich hodne a maji hierarchickou strukturu. Typicky a vsude uvadeny pripad je GUI. A nebo ja jsem ted hodne ponoren do midi a midi eventů, u nich objektovy pristup take sedi jak zadek na hrnec. A s temito objekty pak muze byt dal klidne nakladano strukturovane nebo funkcionalne, jak je v dane situaci nejlepsi. Takze oop by mel byt dobry sluha aplikovany kam patri, ale ne spatny pan vnucovany nam z duvodu cistoty/uniformity jednoho paradigma i na miste, kde se nehodi.
Název: Re:Co si myslíte o OOP?
Přispěvatel: Kadet 16. 01. 2019, 20:36:24
Ohledně OPP si myslím, že je vhodné pro něco, co si drží nějaké stavy. Např. desktopová aplikace. A hlavně si myslím, že z těch, kteří tvrdí, že umějí OOP, pak 80% porgramátorů přinejmenším zneužívá dědičnost pro sdílení kódu a hrubě pourušují SRP. Tolik k OOP.

Jinak mi přijde, že když už to tu není úplné OT o pohlavích, tak stejně si tu namísto debaty o OPP hodně lidí obhajuje nějaký svůj jazyk a debata se stáčí na dynamické typování, enumy a věci, které imho s OOP tolik nesouvisí.
OOP je dobre treba na datove objekty, na vytvareni novych datovych typu. Zvlaste kdyz je jich hodne a maji hierarchickou strukturu. Typicky a vsude uvadeny pripad je GUI. A nebo ja jsem ted hodne ponoren do midi a midi eventů, u nich objektovy pristup take sedi jak zadek na hrnec. A s temito objekty pak muze byt dal klidne nakladano strukturovane nebo funkcionalne, jak je v dane situaci nejlepsi. Takze oop by mel byt dobry sluha aplikovany kam patri, ale ne spatny pan vnucovany nam z duvodu cistoty/uniformity jednoho paradigma i na miste, kde se nehodi.

Presne GUI a implementace vnitrnosti programovaciho prostredi (hierarchie cisel), nektery datovy struktury, jsou presne pripady, kde je fajn mit nastroje, co dokazou dispatchovat funkci hierarchicky.

Nemyslim si ale ze je k tomu potreba OOP jazyk, mela by stacit featura, ktera mi diapatchne spravnou funkci.

Napr. u hierarchie cisel. Mam pripady kdy scitam int a float:

1 + 1 (int_int_plus)
1.0 + 1 (float_int_plus)
1 + 1.0 (int_float_plus, nebo flip + float_int_plus)
1.0 + 1.0 (float_float_plus)

na zaklade typu potrebuju dispatchnout spravnou funkci nebo instrukci.

OOP s posilanim zprav nebo volanim metod je na to kratky, protoze dispatchuju pres dva argumenty. Muzu to ohackovat pres double dispatch. Nejakej haskell fanda mi muze tvrdit, ze bez dispatche na zaklade statickych typu to nepujde, ale kazdy vidi, ze je v tomhle pripade jedno jestli dispatchuju pri prekladu nebo az tesne pred volanim funkce.

Kazdopadne jakmile mam spravnou funkci, tak nepotrebuju dalsi featury OOP jazyka. Staci mi skladat funkce jednu za druhou. Algebra funkci je jednodussi nez algebra objektu, pokud beru objekt pouze jako mnozinu 1+ funkci.
Název: Re:Co si myslíte o OOP?
Přispěvatel: BaldSlattery 16. 01. 2019, 20:43:12
Ohledně OPP si myslím, že je vhodné pro něco, co si drží nějaké stavy. Např. desktopová aplikace. A hlavně si myslím, že z těch, kteří tvrdí, že umějí OOP, pak 80% porgramátorů přinejmenším zneužívá dědičnost pro sdílení kódu a hrubě pourušují SRP. Tolik k OOP.

Jinak mi přijde, že když už to tu není úplné OT o pohlavích, tak stejně si tu namísto debaty o OPP hodně lidí obhajuje nějaký svůj jazyk a debata se stáčí na dynamické typování, enumy a věci, které imho s OOP tolik nesouvisí.
OOP je dobre treba na datove objekty, na vytvareni novych datovych typu. Zvlaste kdyz je jich hodne a maji hierarchickou strukturu. Typicky a vsude uvadeny pripad je GUI. A nebo ja jsem ted hodne ponoren do midi a midi eventů, u nich objektovy pristup take sedi jak zadek na hrnec. A s temito objekty pak muze byt dal klidne nakladano strukturovane nebo funkcionalne, jak je v dane situaci nejlepsi. Takze oop by mel byt dobry sluha aplikovany kam patri, ale ne spatny pan vnucovany nam z duvodu cistoty/uniformity jednoho paradigma i na miste, kde se nehodi.

Presne GUI a implementace vnitrnosti programovaciho prostredi (hierarchie cisel), nektery datovy struktury, jsou presne pripady, kde je fajn mit nastroje, co dokazou dispatchovat funkci hierarchicky.

Nemyslim si ale ze je k tomu potreba OOP jazyk, mela by stacit featura, ktera mi diapatchne spravnou funkci.

Napr. u hierarchie cisel. Mam pripady kdy scitam int a float:

1 + 1 (int_int_plus)
1.0 + 1 (float_int_plus)
1 + 1.0 (int_float_plus, nebo flip + float_int_plus)
1.0 + 1.0 (float_float_plus)

na zaklade typu potrebuju dispatchnout spravnou funkci nebo instrukci.

OOP s posilanim zprav nebo volanim metod je na to kratky, protoze dispatchuju pres dva argumenty. Muzu to ohackovat pres double dispatch. Nejakej haskell fanda mi muze tvrdit, ze bez dispatche na zaklade statickych typu to nepujde, ale kazdy vidi, ze je v tomhle pripade jedno jestli dispatchuju pri prekladu nebo az tesne pred volanim funkce.

Kazdopadne jakmile mam spravnou funkci, tak nepotrebuju dalsi featury OOP jazyka. Staci mi skladat funkce jednu za druhou. Algebra funkci je jednodussi nez algebra objektu, pokud beru objekt pouze jako mnozinu 1+ funkci.
Blahopřeju k (zatím) nejdebilnějšímu příspěvku tohoto vlákna.
Název: Re:Co si myslíte o OOP?
Přispěvatel: Kadet 16. 01. 2019, 20:54:18
Ohledně OPP si myslím, že je vhodné pro něco, co si drží nějaké stavy. Např. desktopová aplikace. A hlavně si myslím, že z těch, kteří tvrdí, že umějí OOP, pak 80% porgramátorů přinejmenším zneužívá dědičnost pro sdílení kódu a hrubě pourušují SRP. Tolik k OOP.

Jinak mi přijde, že když už to tu není úplné OT o pohlavích, tak stejně si tu namísto debaty o OPP hodně lidí obhajuje nějaký svůj jazyk a debata se stáčí na dynamické typování, enumy a věci, které imho s OOP tolik nesouvisí.
OOP je dobre treba na datove objekty, na vytvareni novych datovych typu. Zvlaste kdyz je jich hodne a maji hierarchickou strukturu. Typicky a vsude uvadeny pripad je GUI. A nebo ja jsem ted hodne ponoren do midi a midi eventů, u nich objektovy pristup take sedi jak zadek na hrnec. A s temito objekty pak muze byt dal klidne nakladano strukturovane nebo funkcionalne, jak je v dane situaci nejlepsi. Takze oop by mel byt dobry sluha aplikovany kam patri, ale ne spatny pan vnucovany nam z duvodu cistoty/uniformity jednoho paradigma i na miste, kde se nehodi.

Presne GUI a implementace vnitrnosti programovaciho prostredi (hierarchie cisel), nektery datovy struktury, jsou presne pripady, kde je fajn mit nastroje, co dokazou dispatchovat funkci hierarchicky.

Nemyslim si ale ze je k tomu potreba OOP jazyk, mela by stacit featura, ktera mi diapatchne spravnou funkci.

Napr. u hierarchie cisel. Mam pripady kdy scitam int a float:

1 + 1 (int_int_plus)
1.0 + 1 (float_int_plus)
1 + 1.0 (int_float_plus, nebo flip + float_int_plus)
1.0 + 1.0 (float_float_plus)

na zaklade typu potrebuju dispatchnout spravnou funkci nebo instrukci.

OOP s posilanim zprav nebo volanim metod je na to kratky, protoze dispatchuju pres dva argumenty. Muzu to ohackovat pres double dispatch. Nejakej haskell fanda mi muze tvrdit, ze bez dispatche na zaklade statickych typu to nepujde, ale kazdy vidi, ze je v tomhle pripade jedno jestli dispatchuju pri prekladu nebo az tesne pred volanim funkce.

Kazdopadne jakmile mam spravnou funkci, tak nepotrebuju dalsi featury OOP jazyka. Staci mi skladat funkce jednu za druhou. Algebra funkci je jednodussi nez algebra objektu, pokud beru objekt pouze jako mnozinu 1+ funkci.
Blahopřeju k (zatím) nejdebilnějšímu příspěvku tohoto vlákna.

(zatim) v zavorce, protoze jsi me prave prekonal?
Název: Re:Co si myslíte o OOP?
Přispěvatel: operator 16. 01. 2019, 21:15:29
Ohledně OPP si myslím, že je vhodné pro něco, co si drží nějaké stavy. Např. desktopová aplikace. A hlavně si myslím, že z těch, kteří tvrdí, že umějí OOP, pak 80% porgramátorů přinejmenším zneužívá dědičnost pro sdílení kódu a hrubě pourušují SRP. Tolik k OOP.

Jinak mi přijde, že když už to tu není úplné OT o pohlavích, tak stejně si tu namísto debaty o OPP hodně lidí obhajuje nějaký svůj jazyk a debata se stáčí na dynamické typování, enumy a věci, které imho s OOP tolik nesouvisí.
OOP je dobre treba na datove objekty, na vytvareni novych datovych typu. Zvlaste kdyz je jich hodne a maji hierarchickou strukturu. Typicky a vsude uvadeny pripad je GUI. A nebo ja jsem ted hodne ponoren do midi a midi eventů, u nich objektovy pristup take sedi jak zadek na hrnec. A s temito objekty pak muze byt dal klidne nakladano strukturovane nebo funkcionalne, jak je v dane situaci nejlepsi. Takze oop by mel byt dobry sluha aplikovany kam patri, ale ne spatny pan vnucovany nam z duvodu cistoty/uniformity jednoho paradigma i na miste, kde se nehodi.

Presne GUI a implementace vnitrnosti programovaciho prostredi (hierarchie cisel), nektery datovy struktury, jsou presne pripady, kde je fajn mit nastroje, co dokazou dispatchovat funkci hierarchicky.

Nemyslim si ale ze je k tomu potreba OOP jazyk, mela by stacit featura, ktera mi diapatchne spravnou funkci.

Napr. u hierarchie cisel. Mam pripady kdy scitam int a float:

1 + 1 (int_int_plus)
1.0 + 1 (float_int_plus)
1 + 1.0 (int_float_plus, nebo flip + float_int_plus)
1.0 + 1.0 (float_float_plus)

na zaklade typu potrebuju dispatchnout spravnou funkci nebo instrukci.

OOP s posilanim zprav nebo volanim metod je na to kratky, protoze dispatchuju pres dva argumenty. Muzu to ohackovat pres double dispatch. Nejakej haskell fanda mi muze tvrdit, ze bez dispatche na zaklade statickych typu to nepujde, ale kazdy vidi, ze je v tomhle pripade jedno jestli dispatchuju pri prekladu nebo az tesne pred volanim funkce.

Kazdopadne jakmile mam spravnou funkci, tak nepotrebuju dalsi featury OOP jazyka. Staci mi skladat funkce jednu za druhou. Algebra funkci je jednodussi nez algebra objektu, pokud beru objekt pouze jako mnozinu 1+ funkci.
De facto oop nepotrebujes vubec, viz gtk v c, jde se bez toho obejit a nasimulovat to, ale je to krajne nepohodlne. Takze pokud mi vlastnosti oop zjednodusi nebo alespon zprehledni praci, jsem za to rad,  a soucasne jsem rad za to, ze je to jen moznost a nikoliv nutnost. Pro me je nejdulezitejsi moci s lehkosti, strucne a prehledne vyjadrit. A proto mam rad komplexni python s jeho multiparadigmatickym pristupem, dekoratory, generatory, comprehension a dalsimi featurami, protoze programovat v nem je poteseni a radost. Zvlast kdyz jsem nucen z profesnich duvodu programovat v necem tezkopadnem, a klopotnem jako je Java, tak ho potom o to vic umim ocenit. A ano, za to pohodli se plati vykonem.
Název: Re:Co si myslíte o OOP?
Přispěvatel: Mirek Prýmek 16. 01. 2019, 21:43:11
A proto mam rad komplexni python s jeho multiparadigmatickym pristupem, dekoratory, generatory, comprehension a dalsimi featurami, protoze programovat v nem je poteseni a radost.
A to jsi ještě nezmínil konkurentnost. Programovat něco konkurentního v Pythonu, to není potěšení a radost, to už je přímo orgastická extáze. Obzvlášť ve dvojce.
Název: Re:Co si myslíte o OOP?
Přispěvatel: BoneFlute 16. 01. 2019, 21:53:01
Se svym statickm stylem mysleni nedokazi  vyuzivat jejich vyhodnych vlastnosti

Měl jsi možnost tyto výhodné vlastnosti rozvést. Proč jsi to neudělal?
Název: Re:Co si myslíte o OOP?
Přispěvatel: BoneFlute 16. 01. 2019, 22:00:58
OOP je dobre treba na datove objekty, na vytvareni novych datovych typu. Zvlaste kdyz je jich hodne a maji hierarchickou strukturu.
Kdy potřebuješ hiearchickou strukturu? Čuchá čuchám zneužití dědičnosti na reusable kódu.
Název: Re:Co si myslíte o OOP?
Přispěvatel: gll 16. 01. 2019, 22:04:24
A proto mam rad komplexni python s jeho multiparadigmatickym pristupem, dekoratory, generatory, comprehension a dalsimi featurami, protoze programovat v nem je poteseni a radost.
A to jsi ještě nezmínil konkurentnost. Programovat něco konkurentního v Pythonu, to není potěšení a radost, to už je přímo orgastická extáze. Obzvlášť ve dvojce.

ve dvojce jsem používal gevent a radost to byla.
Název: Re:Co si myslíte o OOP?
Přispěvatel: Mirek Prýmek 16. 01. 2019, 22:07:17
ve dvojce jsem používal gevent a radost to byla.
Radost je slabý slovo. Když si člověk vzpomene na ten debugging! Saturnálie!
Název: Re:Co si myslíte o OOP?
Přispěvatel: operator 17. 01. 2019, 05:46:41
Se svym statickm stylem mysleni nedokazi  vyuzivat jejich vyhodnych vlastnosti
Měl jsi možnost tyto výhodné vlastnosti rozvést. Proč jsi to neudělal?
A proc bych to mel jeste vic rozvadet? Rozvedeno je to vic nez dost. Pro ty, kterym je shury dano programovat v dynamickem prostredi to rozvadet nepotrebuji a pro ty ostatni je to zbytecne. Staticky jazyk, to je neco jako vezeni. Tvrda omezeni, pevny rad, vse mas nalajnovano, zadna svoboda/flexibilita. Je to efektivni a prinasi to pocit bezpeci, protoze je o tebe postarano a neses minimalni zodpovednost. Kdyz jsi v tom moc dlouho, tak se pak na svobode citis ztraceny a chtel bys zpet do toho vytyceneho radu, kde se o tebe postaraji. Vysvetluj nekomu takovemu hodnotu svobody. Ja ti pochopeni neprinesu a uz vubec nevnutim, to je tvuj boj, me to nevycitej a na me to neprenasej.
Název: Re:Co si myslíte o OOP?
Přispěvatel: operator 17. 01. 2019, 05:51:23
ve dvojce jsem používal gevent a radost to byla.
Radost je slabý slovo. Když si člověk vzpomene na ten debugging! Saturnálie!
Zadny tvuj sarkasmus nic nezmeni na faktu, ze programovat v Pythonu mi z uvedenych duvodu prinasi nejvetsi poteseni. A vzhledem k jeho oblibe a rozsireni, navzdory tomu, ze za nim nestoji zadny ekonomicky gigant, nebudu evidentne jediny. A zvazuji, co za tim asi je, ze tebe to tak zere :-).
Název: Re:Co si myslíte o OOP?
Přispěvatel: Mirek Prýmek 17. 01. 2019, 07:33:34
A zvazuji, co za tim asi je, ze tebe to tak zere :-).
Mě to vůbec nežere, já v Pythonu dělám taky. Je to fajn jazyk, některé momenty má slabší a nesmí se to s ním moc přehánět, ale dělá se mi v něm dobře.
Název: Re:Co si myslíte o OOP?
Přispěvatel: Kit 17. 01. 2019, 07:39:54
Se svym statickm stylem mysleni nedokazi  vyuzivat jejich vyhodnych vlastnosti
Měl jsi možnost tyto výhodné vlastnosti rozvést. Proč jsi to neudělal?
A proc bych to mel jeste vic rozvadet? Rozvedeno je to vic nez dost. Pro ty, kterym je shury dano programovat v dynamickem prostredi to rozvadet nepotrebuji a pro ty ostatni je to zbytecne. Staticky jazyk, to je neco jako vezeni. Tvrda omezeni, pevny rad, vse mas nalajnovano, zadna svoboda/flexibilita. Je to efektivni a prinasi to pocit bezpeci, protoze je o tebe postarano a neses minimalni zodpovednost. Kdyz jsi v tom moc dlouho, tak se pak na svobode citis ztraceny a chtel bys zpet do toho vytyceneho radu, kde se o tebe postaraji. Vysvetluj nekomu takovemu hodnotu svobody. Ja ti pochopeni neprinesu a uz vubec nevnutim, to je tvuj boj, me to nevycitej a na me to neprenasej.

Připomněl jsi mi peklo fixní délky stringů v Pascalu. S tím se fakt nedalo rozumně pracovat. Staticky typovaného jazyka jsem si užil až až.
Název: Re:Co si myslíte o OOP?
Přispěvatel: PetrM 17. 01. 2019, 08:37:04
Pro ty, kterym je shury dano programovat v dynamickem prostredi to rozvadet nepotrebuji a pro ty ostatni je to zbytecne.

Co mi to jenom připomíná? Aha, https://www.joelonsoftware.com/2005/12/29/the-perils-of-javaschools-2/ Kterou část mozku nemáš, že nepojme i informaci o typu?

Staticky jazyk, to je neco jako vezeni. Tvrda omezeni, pevny rad, vse mas nalajnovano, zadna svoboda/flexibilita. Je to efektivni a prinasi to pocit bezpeci, protoze je o tebe postarano a neses minimalni zodpovednost. Kdyz jsi v tom moc dlouho, tak se pak na svobode citis ztraceny a chtel bys zpet do toho vytyceneho radu, kde se o tebe postaraji. Vysvetluj nekomu takovemu hodnotu svobody. Ja ti pochopeni neprinesu a uz vubec nevnutim, to je tvuj boj, me to nevycitej a na me to neprenasej.

Někdy je to dobře. Říká se tomu "defenzivní programování". Víš, že 123+456 = 579 a nemusíš počítat s tím, že to bude 123456, pokud to interpreter vyhodnotí jako string.

Ostatně i v Basicu byly typy "číslo" (např "a") a "string" (např. "a$") právě z tohoto důvodu. Když jsem přecházel z Basicu na Pascal, tak jsem se typům taky divil, ale zjistil jsem, že to má logiku a řada dřívějších chyb záhadně vymizela.

A rozhodování o typu? Sám říkáš "no tak inkluduju knihnovnu, která to řeší".  Není rozhodnutí "inkluduju knihovnu, která tohle pole vezme jako float" právě volba typu? Zatímco jinde napíšu prostě float x[500], tam musím něco inkludvat, něco vytvořit, nějak tam ty data přechroupat dovnitř, musím vědět něco o rozhraní toho něčeho,...

Se svym statickm stylem mysleni nedokazi  vyuzivat jejich vyhodnych vlastnosti

Například?

Zatím jsi jenom dokázal, že se problém odsouvá z deklarace proměnné na deklaraci knihovny, která to zpracuje, ale řešíš to stejně. A navíc tam máš režie s rozhodováním o aktuálním typu za běhu a kontrolou validity kdekoliv, což u typovanýho systému můžeš udělat na vstupu a víš, že pak se ti typ dat bez tvýho vědomí nezmění. A že máš víc pohodlí při psaní, míň pohodlí při ladění.
Název: Re:Co si myslíte o OOP?
Přispěvatel: gll 17. 01. 2019, 09:11:32
.....

ten článek The Perils of JavaSchools mimo jiné pojednává i o neschopnosti uvažovat na vyšší úrovni abstrakce.
Název: Re:Co si myslíte o OOP?
Přispěvatel: SB 17. 01. 2019, 09:47:59
Nekdo tomu rika event sourcing, nekdo funkcionalni programovani, nekdo programovani s explicitnim casem.

Nejmenuje se to continuation? https://en.wikipedia.org/wiki/Continuation (https://en.wikipedia.org/wiki/Continuation)
Název: Re:Co si myslíte o OOP?
Přispěvatel: SB 17. 01. 2019, 09:55:08
Blahopřeju k (zatím) nejdebilnějšímu příspěvku tohoto vlákna.

Nejdebilnějšímu ne, ale nemá smysl si stěžovat, že výpočetní model OOP je jiný než funkcionální, a tvrdit, že jeden je lepší než druhý.
Název: Re:Co si myslíte o OOP?
Přispěvatel: JS 17. 01. 2019, 11:08:17
A zvazuji, co za tim asi je, ze tebe to tak zere :-).
Mě to vůbec nežere, já v Pythonu dělám taky. Je to fajn jazyk, některé momenty má slabší a nesmí se to s ním moc přehánět, ale dělá se mi v něm dobře.

Tohle je presne duvod, proc se v teto diskusi s uzivatelem operator vubec nema smysl bavit. Jak uz bylo zrejme z prvnich jeho prispevku, vubec nebere na vedomi, co sem ostatni lide napsali (konkretne Inkvizitor, BoneFlute a ja).
Název: Re:Co si myslíte o OOP?
Přispěvatel: Mirek Prýmek 17. 01. 2019, 11:19:40
Nekdo tomu rika event sourcing, nekdo funkcionalni programovani, nekdo programovani s explicitnim casem.

Nejmenuje se to continuation? https://en.wikipedia.org/wiki/Continuation (https://en.wikipedia.org/wiki/Continuation)
Ne,  kontinuace je neco hodne jinyho.
Název: Re:Co si myslíte o OOP?
Přispěvatel: operator 17. 01. 2019, 13:47:55
Pro ty, kterym je shury dano programovat v dynamickem prostredi to rozvadet nepotrebuji a pro ty ostatni je to zbytecne.
Co mi to jenom připomíná? Aha, https://www.joelonsoftware.com/2005/12/29/the-perils-of-javaschools-2/ Kterou část mozku nemáš, že nepojme i informaci o typu?
Ja s typy nemam sebemensi problem. Ktera cast mozku chybi tobe, ze se nesrovna s dynamickymi typy?
Citace

Staticky jazyk, to je neco jako vezeni. Tvrda omezeni, pevny rad, vse mas nalajnovano, zadna svoboda/flexibilita. Je to efektivni a prinasi to pocit bezpeci, protoze je o tebe postarano a neses minimalni zodpovednost. Kdyz jsi v tom moc dlouho, tak se pak na svobode citis ztraceny a chtel bys zpet do toho vytyceneho radu, kde se o tebe postaraji. Vysvetluj nekomu takovemu hodnotu svobody. Ja ti pochopeni neprinesu a uz vubec nevnutim, to je tvuj boj, me to nevycitej a na me to neprenasej.

Někdy je to dobře. Říká se tomu "defenzivní programování". Víš, že 123+456 = 579 a nemusíš počítat s tím, že to bude 123456, pokud to interpreter vyhodnotí jako string.
Tvuj mozek mozna pojme informaci o typech, ale uz ne to, ze se deli na staticke/dynamicke a vedle toho na slabe/silne. Python ma silne typy, takze ti nikdy cislo implicitne nevyhodnoti jako string a naopak.
Citace

Ostatně i v Basicu byly typy "číslo" (např "a") a "string" (např. "a$") právě z tohoto důvodu. Když jsem přecházel z Basicu na Pascal, tak jsem se typům taky divil, ale zjistil jsem, že to má logiku a řada dřívějších chyb záhadně vymizela.
Tady se ale prece nevede debata jestli typy ano nebo ne, ale v jake podobe. Na to jake mas silne reci o mozku ti unika i zakladni podstata diskuse. Dynamicky jazyk neznamena beztypovy jazyk.
Citace

A rozhodování o typu? Sám říkáš "no tak inkluduju knihnovnu, která to řeší".  Není rozhodnutí "inkluduju knihovnu, která tohle pole vezme jako float" právě volba typu? Zatímco jinde napíšu prostě float x[500], tam musím něco inkludvat, něco vytvořit, nějak tam ty data přechroupat dovnitř, musím vědět něco o rozhraní toho něčeho,...

Se svym statickm stylem mysleni nedokazi  vyuzivat jejich vyhodnych vlastnosti

Například?

Zatím jsi jenom dokázal, že se problém odsouvá z deklarace proměnné na deklaraci knihovny, která to zpracuje, ale řešíš to stejně. A navíc tam máš režie s rozhodováním o aktuálním typu za běhu a kontrolou validity kdekoliv, což u typovanýho systému můžeš udělat na vstupu a víš, že pak se ti typ dat bez tvýho vědomí nezmění. A že máš víc pohodlí při psaní, míň pohodlí při ladění.
Ne, nic takoveho jsem a) nedokazal protoze rozdil mezi statickymi a dynamickymi typy lezi jinde a b) neresim to stejne. Zakladni rozdil č v tom, ze vykonovou optimalizaci resim jen tam, kde je nutna a jinde se tim nemusim a naopak mam vyhodu flexibility dynamickych typu a to v naproste vetsine kodu, vetsinou celem. Python mi treba umoznuje zpracovavat vzajemnou realtime midi komunikaci nekolika nastroju pres na raspbery pi zero s velkou vykonovou rezervou, cpu je zatizeno asi na cca 10 %, nepozorovatelnou latenci a to bez jakychkoliv optimalizaci. Me ten vykon proste nezajima. Pohodli pri ladeni je hodne relativni. A) nemusim ladit spoustu problemu, ktere u me jednoduse vubec nevznikaji, b) mam jednodussi a prehlednejsi kod a tedy mensi mnozstvi chyb c) mam introspekci a snazsi odhalovani chyb, d) mam radu vybornych nastroju na testovani. 

Nevim jak to maji ostatni, ale ja pri vytvareni programu mam minimum chyb, casto mi bezi na prvni dobrou. To je vyhoda jednoducheho prehledneho kodu, ktery primocare popisuje problem a asi i jistych zkusenosti, ktere uz mam, a samozrejme pylintu beziciho na pozadi, ktery me na chyby z nepozornosti upozornuje uz behem psani, nemusim cekat na kompilaci. A kdyz nad tim tak premyslim, tak i toho, ze ten kod spoustim mnohem casteji, nez kdyz programuji v kompilovanem jazyce.

Ja si chyby do programu zanasim vetsinou az pri vetsich zpetnych upravach programu, kdy treba nepodchytim vsechny souvislosti a na neco zapomenu. A tady ohromne pomahaji unit testy, ktere prave testuji ruzne okrajove podminky. Takze cim lepsi testy, tim snazsi ladeni. Pokud to porovnam s Javou nebo C#, neni to celkově o nic náročnější. Spíše naopak díky mému propracovanému systému zachycování výjimek, které jsou velmi informativní a produkují výpis na několik stránek, díky kterému vím přesně kdy kde co a jak probíhalo, znám stavy lokálních proměnných, historii stavů proměnných předávaných z funkcí do funkcí, zobrazuje se mi v tom i zdrojový kód z míst volání funkcí a výskytu chyby. V drtivé většině případů mi to samo o sobě stačí k odhalení příčiny chyby aniž bych musel koukat do zdrojáků nebo dokonce používal debuger. A tohle zapisuji i do logu, takže ani u zákazníka se nijak nemusím zabývat simulací a jdu na jisto i u problémů, které se objevují ojediněle a nejde je vyvolat na požádání. Takhle si zase pohodlí představuji já. Že si k tomu musím víc pohlídat i typy se v tom ztratí. Nepředstavuje to žádný problém, který by mě přiměl třeba používat type hinty, natož statický jazyk.
Název: Re:Co si myslíte o OOP?
Přispěvatel: operator 17. 01. 2019, 13:55:53
A zvazuji, co za tim asi je, ze tebe to tak zere :-).
Mě to vůbec nežere, já v Pythonu dělám taky. Je to fajn jazyk, některé momenty má slabší a nesmí se to s ním moc přehánět, ale dělá se mi v něm dobře.
Tohle je presne duvod, proc se v teto diskusi s uzivatelem operator vubec nema smysl bavit. Jak uz bylo zrejme z prvnich jeho prispevku, vubec nebere na vedomi, co sem ostatni lide napsali (konkretne Inkvizitor, BoneFlute a ja).
Na vedomi to beru, ale velmi casto to jsou falesne predstavy a myty o statickych/dynamickych typech, o tom, co jde nebo nejde, co je nutne nebo nezbytne.
Název: Re:Co si myslíte o OOP?
Přispěvatel: operator 17. 01. 2019, 14:01:11
A zvazuji, co za tim asi je, ze tebe to tak zere :-).
Mě to vůbec nežere, já v Pythonu dělám taky. Je to fajn jazyk, některé momenty má slabší a nesmí se to s ním moc přehánět, ale dělá se mi v něm dobře.
Tve vyjadrovani pusobi jinym dojmem.
Název: Re:Co si myslíte o OOP?
Přispěvatel: BaldSlattery 17. 01. 2019, 14:08:17
Nekdo tomu rika event sourcing, nekdo funkcionalni programovani, nekdo programovani s explicitnim casem.

Nejmenuje se to continuation? https://en.wikipedia.org/wiki/Continuation (https://en.wikipedia.org/wiki/Continuation)
Ne,  kontinuace je neco hodne jinyho.
Jo, kontinuace je monáda  :D
Název: Re:Co si myslíte o OOP?
Přispěvatel: BaldSlattery 17. 01. 2019, 14:10:30
Se svym statickm stylem mysleni nedokazi  vyuzivat jejich vyhodnych vlastnosti
Měl jsi možnost tyto výhodné vlastnosti rozvést. Proč jsi to neudělal?
A proc bych to mel jeste vic rozvadet? Rozvedeno je to vic nez dost. Pro ty, kterym je shury dano programovat v dynamickem prostredi to rozvadet nepotrebuji a pro ty ostatni je to zbytecne. Staticky jazyk, to je neco jako vezeni. Tvrda omezeni, pevny rad, vse mas nalajnovano, zadna svoboda/flexibilita. Je to efektivni a prinasi to pocit bezpeci, protoze je o tebe postarano a neses minimalni zodpovednost. Kdyz jsi v tom moc dlouho, tak se pak na svobode citis ztraceny a chtel bys zpet do toho vytyceneho radu, kde se o tebe postaraji. Vysvetluj nekomu takovemu hodnotu svobody. Ja ti pochopeni neprinesu a uz vubec nevnutim, to je tvuj boj, me to nevycitej a na me to neprenasej.

Připomněl jsi mi peklo fixní délky stringů v Pascalu. S tím se fakt nedalo rozumně pracovat. Staticky typovaného jazyka jsem si užil až až.
Fixní délka v typu může být užitečná. I když asi spíše u seznamu než řetězce.
Název: Re:Co si myslíte o OOP?
Přispěvatel: BaldSlattery 17. 01. 2019, 14:11:32
nemá smysl si stěžovat, že výpočetní model OOP je jiný než funkcionální, a tvrdit, že jeden je lepší než druhý.
To ne.
Název: Re:Co si myslíte o OOP?
Přispěvatel: Kadet 17. 01. 2019, 14:25:45
V pripade event sourcingu, kdy je historie vsech zmen uchovana jako linearni log zprav, je suffix takovyho logu skutecne kontinuace.

V jazycich, kde neni cas explicitni, ale implicitne schovanej ve vnitrnostech runtimu v zasobniku, je kontinuace rovna tomu zasobniku. Tj. na zasobnik ulozim to, co chci vypocitat potom az dokoncim neco ted. Mnozina vsech operaci odlozena do budoucna = kontinuace = runtime stack.
Název: Re:Co si myslíte o OOP?
Přispěvatel: Inkvizitor 17. 01. 2019, 14:34:57
Připomněl jsi mi peklo fixní délky stringů v Pascalu. S tím se fakt nedalo rozumně pracovat. Staticky typovaného jazyka jsem si užil až až.
Fixní délka v typu může být užitečná. I když asi spíše u seznamu než řetězce.

Pokud si to dobre vybavuju, tak v Pascalu byl akorat tak fixni limit na delku (klasicky string do 255 znaku, ANSI string mel max. delku omezenou maximalni hodnotou integeru). Fixni delka patri spis k poli (pripade n-tici) a ne seznamu, tam pro to nevidim moc smysl.
Název: Re:Co si myslíte o OOP?
Přispěvatel: v 17. 01. 2019, 15:51:33
Připomněl jsi mi peklo fixní délky stringů v Pascalu. S tím se fakt nedalo rozumně pracovat. Staticky typovaného jazyka jsem si užil až až.
Fixní délka v typu může být užitečná. I když asi spíše u seznamu než řetězce.

Pokud si to dobre vybavuju, tak v Pascalu byl akorat tak fixni limit na delku (klasicky string do 255 znaku, ANSI string mel max. delku omezenou maximalni hodnotou integeru). Fixni delka patri spis k poli (pripade n-tici) a ne seznamu, tam pro to nevidim moc smysl.
dá se třeba zabezpečit funkce head
Kód: [Vybrat]
head :: Vec (1 + more) a -> aVec je seznam s počtem prvků v typu, ale záleží co přesně znamená "fixní"
Název: Re:Co si myslíte o OOP?
Přispěvatel: Inkvizitor 17. 01. 2019, 17:16:13
Připomněl jsi mi peklo fixní délky stringů v Pascalu. S tím se fakt nedalo rozumně pracovat. Staticky typovaného jazyka jsem si užil až až.
Fixní délka v typu může být užitečná. I když asi spíše u seznamu než řetězce.

Pokud si to dobre vybavuju, tak v Pascalu byl akorat tak fixni limit na delku (klasicky string do 255 znaku, ANSI string mel max. delku omezenou maximalni hodnotou integeru). Fixni delka patri spis k poli (pripade n-tici) a ne seznamu, tam pro to nevidim moc smysl.
dá se třeba zabezpečit funkce head
Kód: [Vybrat]
head :: Vec (1 + more) a -> aVec je seznam s počtem prvků v typu, ale záleží co přesně znamená "fixní"

Pokud ma byt hlavicka fixni, rozhodne bych to nedelal pres vektor, ale pres strukturu/record/tuple.
Název: Re:Co si myslíte o OOP?
Přispěvatel: Kit 17. 01. 2019, 17:24:16
Připomněl jsi mi peklo fixní délky stringů v Pascalu. S tím se fakt nedalo rozumně pracovat. Staticky typovaného jazyka jsem si užil až až.
Fixní délka v typu může být užitečná. I když asi spíše u seznamu než řetězce.

K čemu může být užitečná fixní délka typu v seznamu? Seznam by tuto vlastnost nijak nevyužil.
Název: Re:Co si myslíte o OOP?
Přispěvatel: Ondra Satai Nekola 17. 01. 2019, 17:33:37
Připomněl jsi mi peklo fixní délky stringů v Pascalu. S tím se fakt nedalo rozumně pracovat. Staticky typovaného jazyka jsem si užil až až.
Fixní délka v typu může být užitečná. I když asi spíše u seznamu než řetězce.

K čemu může být užitečná fixní délka typu v seznamu? Seznam by tuto vlastnost nijak nevyužil.

Seznam vs. Spojovy seznam...
Název: Re:Co si myslíte o OOP?
Přispěvatel: BaldSlattery 17. 01. 2019, 17:36:31
Připomněl jsi mi peklo fixní délky stringů v Pascalu. S tím se fakt nedalo rozumně pracovat. Staticky typovaného jazyka jsem si užil až až.
Fixní délka v typu může být užitečná. I když asi spíše u seznamu než řetězce.

K čemu může být užitečná fixní délka typu v seznamu? Seznam by tuto vlastnost nijak nevyužil.
Pro typovou kontrolu operací pracujících s délkou, třeba append. Je to prostě silnější typová kontrola při překladu.
Název: Re:Co si myslíte o OOP?
Přispěvatel: v 17. 01. 2019, 18:10:36
Připomněl jsi mi peklo fixní délky stringů v Pascalu. S tím se fakt nedalo rozumně pracovat. Staticky typovaného jazyka jsem si užil až až.
Fixní délka v typu může být užitečná. I když asi spíše u seznamu než řetězce.

Pokud si to dobre vybavuju, tak v Pascalu byl akorat tak fixni limit na delku (klasicky string do 255 znaku, ANSI string mel max. delku omezenou maximalni hodnotou integeru). Fixni delka patri spis k poli (pripade n-tici) a ne seznamu, tam pro to nevidim moc smysl.
dá se třeba zabezpečit funkce head
Kód: [Vybrat]
head :: Vec (1 + more) a -> aVec je seznam s počtem prvků v typu, ale záleží co přesně znamená "fixní"

Pokud ma byt hlavicka fixni, rozhodne bych to nedelal pres vektor, ale pres strukturu/record/tuple.
"fixní" jsem spíš interpretoval jako "počet prvků seznamu je pevně daný typem, ale ne neměnný"
Název: Re:Co si myslíte o OOP?
Přispěvatel: Kit 17. 01. 2019, 18:33:19
Připomněl jsi mi peklo fixní délky stringů v Pascalu. S tím se fakt nedalo rozumně pracovat. Staticky typovaného jazyka jsem si užil až až.
Fixní délka v typu může být užitečná. I když asi spíše u seznamu než řetězce.
K čemu může být užitečná fixní délka typu v seznamu? Seznam by tuto vlastnost nijak nevyužil.
Pro typovou kontrolu operací pracujících s délkou, třeba append. Je to prostě silnější typová kontrola při překladu.

Co když potřebuji mít v seznamu položky různého typu a s rozdílnou délkou?
Název: Re:Co si myslíte o OOP?
Přispěvatel: BaldSlattery 17. 01. 2019, 18:52:14
Připomněl jsi mi peklo fixní délky stringů v Pascalu. S tím se fakt nedalo rozumně pracovat. Staticky typovaného jazyka jsem si užil až až.
Fixní délka v typu může být užitečná. I když asi spíše u seznamu než řetězce.
K čemu může být užitečná fixní délka typu v seznamu? Seznam by tuto vlastnost nijak nevyužil.
Pro typovou kontrolu operací pracujících s délkou, třeba append. Je to prostě silnější typová kontrola při překladu.

Co když potřebuji mít v seznamu položky různého typu a s rozdílnou délkou?
Pak to chce typovou třídu. Nijak to ale nesouvisí se zahrnutím velikosti kolekce přímo do typu.
Název: Re:Co si myslíte o OOP?
Přispěvatel: Kit 17. 01. 2019, 18:58:34
Připomněl jsi mi peklo fixní délky stringů v Pascalu. S tím se fakt nedalo rozumně pracovat. Staticky typovaného jazyka jsem si užil až až.
Fixní délka v typu může být užitečná. I když asi spíše u seznamu než řetězce.
K čemu může být užitečná fixní délka typu v seznamu? Seznam by tuto vlastnost nijak nevyužil.
Pro typovou kontrolu operací pracujících s délkou, třeba append. Je to prostě silnější typová kontrola při překladu.
Co když potřebuji mít v seznamu položky různého typu a s rozdílnou délkou?
Pak to chce typovou třídu. Nijak to ale nesouvisí se zahrnutím velikosti kolekce přímo do typu.

K čemu by mi byla typová třída, když mi plně vyhovuje rozhraní? A tu kolekci chci mít nafukovací, takže její fixní velikost by mi byla také k ničemu.
Název: Re:Co si myslíte o OOP?
Přispěvatel: Mirek Prýmek 17. 01. 2019, 19:11:27
Jo, kontinuace je monáda  :D
To sice jo, ale asi to nikomu úplně neobjasní, co to kontinuace je, páč monáda je beztak při troše vůle skoro všechno ;)

BTW, Balde*, recence na tu The Little Typer mě oslovily, tak jsem neodolal a koupil si to. Formát je teda silně neortodoxní, snad se to bude dobře číst :) Dík za tip!

* a vůbec, neměň si furt ty nicky - a navíc tak blbě, kdo má pořád přemýšlet, jak od těch tvých úletů vytvořit vokativ!

[...] je suffix takovyho logu skutecne kontinuace. [...] je kontinuace rovna tomu zasobniku.
Sorry, ale obraty "log je kontinuace" a "kontinuace je rovna zásobníku" jsou mi teda úplně nesrozumitelný :)

(Ne že bys to musel vysvětlovat ausgerechnet mně, ale docela pochybuju, žes tím příspěvkem někomu něco srozumitelnýho sdělil :) To jenom tak zpětná vazba pro tebe )
Název: Re:Co si myslíte o OOP?
Přispěvatel: JS 17. 01. 2019, 19:16:06
Pak to chce typovou třídu. Nijak to ale nesouvisí se zahrnutím velikosti kolekce přímo do typu.

K čemu by mi byla typová třída, když mi plně vyhovuje rozhraní? A tu kolekci chci mít nafukovací, takže její fixní velikost by mi byla také k ničemu.

::) Typova trida je v podstate rozhrani, akorat o neco lepsi.

Jinak BaldSlatterovi - premyslel jsem nad tim a uznavam, ze mas pravdu o tom simply-typed lambda kalkulu. Asi to brzo vyzkousim v praxi, protoze se chystam napsat si prekladac totalniho funkcionalniho jazyka, ktery bude mit STLC jako typovy system.
Název: Re:Co si myslíte o OOP?
Přispěvatel: BaldSlattery 17. 01. 2019, 19:18:35
Pak to chce typovou třídu. Nijak to ale nesouvisí se zahrnutím velikosti kolekce přímo do typu.
K čemu by mi byla typová třída, když mi plně vyhovuje rozhraní? A tu kolekci chci mít nafukovací, takže její fixní velikost by mi byla také k ničemu.
::) Typova trida je v podstate rozhrani, akorat o neco lepsi.
Ano
Název: Re:Co si myslíte o OOP?
Přispěvatel: BaldSlattery 17. 01. 2019, 19:22:46
Jinak BaldSlatterovi - premyslel jsem nad tim a uznavam, ze mas pravdu o tom simply-typed lambda kalkulu. Asi to brzo vyzkousim v praxi, protoze se chystam napsat si prekladac totalniho funkcionalniho jazyka, ktery bude mit STLC jako typovy system.
Tak to jsem rád. Ne kvůli tomu, kdo měl/má pravdu, ale že někdo projevil zájem a iniciativu a snad se něco zajímavé naučil. S překladačem držím palce.
Název: Re:Co si myslíte o OOP?
Přispěvatel: BaldSlattery 17. 01. 2019, 19:25:28
kontinuace je monáda
monáda je beztak při troše vůle skoro všechno
Pokud to zrovna není diáda...
Název: Re:Co si myslíte o OOP?
Přispěvatel: Kit 17. 01. 2019, 19:26:50
Pak to chce typovou třídu. Nijak to ale nesouvisí se zahrnutím velikosti kolekce přímo do typu.
K čemu by mi byla typová třída, když mi plně vyhovuje rozhraní? A tu kolekci chci mít nafukovací, takže její fixní velikost by mi byla také k ničemu.
::) Typova trida je v podstate rozhrani, akorat o neco lepsi.

V objektových jazycích pojem "typová třída" poněkud ztrácí svůj význam, ne?
Název: Re:Co si myslíte o OOP?
Přispěvatel: Kadet 17. 01. 2019, 19:56:37
[...] je suffix takovyho logu skutecne kontinuace. [...] je kontinuace rovna tomu zasobniku.
Sorry, ale obraty "log je kontinuace" a "kontinuace je rovna zásobníku" jsou mi teda úplně nesrozumitelný :)

(Ne že bys to musel vysvětlovat ausgerechnet mně, ale docela pochybuju, žes tím příspěvkem někomu něco srozumitelnýho sdělil :) To jenom tak zpětná vazba pro tebe )

Dik za zpetnou vazbu. Event log je termin pouzivanej v event sourcingu. Event log = posloupnost zprav reprezentujicich zmenu nejakyho stavu.

Tech stejnych zprav jako 'volani metody' ve smalltalku, jen jsou ty zpravy nekam logovany a ne zapomenuty.
Název: Re:Co si myslíte o OOP?
Přispěvatel: Mirek Prýmek 17. 01. 2019, 20:57:12
Dik za zpetnou vazbu. Event log je termin pouzivanej v event sourcingu. Event log = posloupnost zprav reprezentujicich zmenu nejakyho stavu.

Tech stejnych zprav jako 'volani metody' ve smalltalku, jen jsou ty zpravy nekam logovany a ne zapomenuty.
Ja vim,  co je log.  Kafka,  Vue.js jsou muj denni chleba.  Zrovna nedavno jsem dopsal stream processing engine (Kafka/Go)  :)

Spis jde o to,  ze log je log a kontinuace je kontinuace.  I kdyz to spolu souvisi, je to neco jinyho.

Je to jako bys rekl,  ze seznam je funkce :) Jo,  funkce se da popsat seznamem a naopak, ale i tak je to neco jinyho :)
Název: Re:Co si myslíte o OOP?
Přispěvatel: Kadet 17. 01. 2019, 22:06:36
Dik za zpetnou vazbu. Event log je termin pouzivanej v event sourcingu. Event log = posloupnost zprav reprezentujicich zmenu nejakyho stavu.

Tech stejnych zprav jako 'volani metody' ve smalltalku, jen jsou ty zpravy nekam logovany a ne zapomenuty.
Ja vim,  co je log.  Kafka,  Vue.js jsou muj denni chleba.  Zrovna nedavno jsem dopsal stream processing engine (Kafka/Go)  :)

Spis jde o to,  ze log je log a kontinuace je kontinuace.  I kdyz to spolu souvisi, je to neco jinyho.

Je to jako bys rekl,  ze seznam je funkce :) Jo,  funkce se da popsat seznamem a naopak, ale i tak je to neco jinyho :)

Pokud delas se stream processingem, tak jsi blizko.

log je log a kontinuace je kontinuace mi nerekce co je ani jedno ani druhy

seznam = funkce a naopak. Jestli to je pravda, tak je to isomorfismus, jinak receno prejmenovani.

Kontinuace je 'zbytek vypoctu'.
Tj. existuje zacatek a konec vypoctu. Necham vypocet chvili bezet od zacatku a pak ho pozastavim. Vsechno mezi zacatkem a timhle momentem je 'provedena kalkulace'. Cokoliv mezi timhle momentem a koncem je 'zbytek kalkulace'. Kontinuace je prave ta druha cast.

Suffix logu je 'zbytek logu'. Kazda zprava v logu predstavuje jednu operaci vypoctu.
Existuje zacatek a konec logu. Necham prehrat log do nejakyho bodu uprostred. Cokoliv mezi zacatkem a timhle bodem je prefix logu/provedena kalkulace. Cokoliv od tohoto bodu je suffix logu/zbyvajici vypocet.

log je zhmotneni (reifikace) vypoctu. Suffix logu = kontinuace = zbytek vypoctu

Zasobnik je reifikace zbytku vypoctu ve vnitrnostech nejakyho runtimu. Zasobnik = kontinuace. Takhle jsou kontinuace implementovany v jazycich kde se s nima da explicitne pracovat. Vezmes kus stacku a hodis ho do promenny. Kdyz pak tu promennou zavolas, tak se akorat vezme ten ulozenej stack, pleskne se na stack v tom momentu.
Název: Re:Co si myslíte o OOP?
Přispěvatel: BoneFlute 17. 01. 2019, 22:13:26
K čemu by mi byla typová třída, když mi plně vyhovuje rozhraní? A tu kolekci chci mít nafukovací, takže její fixní velikost by mi byla také k ničemu.
UserName = String[1..255]

Naprosto běžný a obvyklý use case, který se v praxi řeší (zatím) blbě pomocí assertů.
Název: Re:Co si myslíte o OOP?
Přispěvatel: Kit 17. 01. 2019, 22:31:11
K čemu by mi byla typová třída, když mi plně vyhovuje rozhraní? A tu kolekci chci mít nafukovací, takže její fixní velikost by mi byla také k ničemu.
UserName = String[1..255]

Naprosto běžný a obvyklý use case, který se v praxi řeší (zatím) blbě pomocí assertů.

To jako pole pro 255 stringů? K čemu mi to bude, když potřebuji seznam stringů a dopředu nevím, zda jich bude 20 nebo 20000?
Název: Re:Co si myslíte o OOP?
Přispěvatel: BoneFlute 17. 01. 2019, 22:34:07
K čemu by mi byla typová třída, když mi plně vyhovuje rozhraní? A tu kolekci chci mít nafukovací, takže její fixní velikost by mi byla také k ničemu.
UserName = String[1..255]

Naprosto běžný a obvyklý use case, který se v praxi řeší (zatím) blbě pomocí assertů.

To jako pole pro 255 stringů? K čemu mi to bude, když potřebuji seznam stringů a dopředu nevím, zda jich bude 20 nebo 20000?
Ne, je to typ UserName, který obsahuje string v rozsahu 1 až 255. Omezení délky textu.
Název: Re:Co si myslíte o OOP?
Přispěvatel: Kit 17. 01. 2019, 23:44:25
K čemu by mi byla typová třída, když mi plně vyhovuje rozhraní? A tu kolekci chci mít nafukovací, takže její fixní velikost by mi byla také k ničemu.
UserName = String[1..255]
Naprosto běžný a obvyklý use case, který se v praxi řeší (zatím) blbě pomocí assertů.
To jako pole pro 255 stringů? K čemu mi to bude, když potřebuji seznam stringů a dopředu nevím, zda jich bude 20 nebo 20000?
Ne, je to typ UserName, který obsahuje string v rozsahu 1 až 255. Omezení délky textu.

Který objektový jazyk tohle používá?
Název: Re:Co si myslíte o OOP?
Přispěvatel: BoneFlute 18. 01. 2019, 00:25:22
K čemu by mi byla typová třída, když mi plně vyhovuje rozhraní? A tu kolekci chci mít nafukovací, takže její fixní velikost by mi byla také k ničemu.
UserName = String[1..255]
Naprosto běžný a obvyklý use case, který se v praxi řeší (zatím) blbě pomocí assertů.
To jako pole pro 255 stringů? K čemu mi to bude, když potřebuji seznam stringů a dopředu nevím, zda jich bude 20 nebo 20000?
Ne, je to typ UserName, který obsahuje string v rozsahu 1 až 255. Omezení délky textu.

Který objektový jazyk tohle používá?
Tak nezněla otázka.
Název: Re:Co si myslíte o OOP?
Přispěvatel: Mirek Prýmek 18. 01. 2019, 12:24:55
Kontinuaci můžeš implementovat pomocí logu (a naopak), ale jsou to jiné koncepty.
BTW, dobře je to vidět na tom tvrzení "kontinuace je monáda". To je pravda (za nějakých podmínek).

Tvrzení "log je monáda" je dost zhovadilost.
Název: Re:Co si myslíte o OOP?
Přispěvatel: Mirek Prýmek 18. 01. 2019, 12:37:42
Doprčic, teď jsem dal omylem edit místo citace.

V tom původním příspěvku bylo něco jako:

seznam = funkce a naopak. Jestli to je pravda, tak je to isomorfismus, jinak receno prejmenovani.
1. obecně není už proto, že funkčních hodnot může být nespočetně mnoho, zatímco položek listu je vždycky jenom spočetně.

2. a i kdyby to byla pravda (v reálném IT máme jenom spočetné množiny), tak občas máme nějaké koncepty, které jsou (třeba za nějakých omezujících podmínek) vzájemně převoditelné a i tak se hodí je rozlišovat. Např. gramatika a příslušný automat jsou dva různé pohledy na tutéž věc a přitom jsou to dva různé koncepty, které je dobré rozlišovat. Gramatika není automat. Gramatika je gramatika.

Kontinuaci můžeš implementovat pomocí logu (a naopak), ale jsou to jiné koncepty.
Název: Re:Co si myslíte o OOP?
Přispěvatel: BaldSlattery 18. 01. 2019, 12:57:13
Kontinuace je 'zbytek vypoctu'.
Je to přesně naopak, kontinuace je funkce reprezentující nějaký výpočet, které se předá “zbytek výpočtu” ve formě funkce. Z Wikipedie bys mohl pochopit aspoň převod konstanty na příslušnou kontinuaci.
Název: Re:Co si myslíte o OOP?
Přispěvatel: Kadet 18. 01. 2019, 13:25:44
Kontinuace je 'zbytek vypoctu'.
Je to přesně naopak, kontinuace je funkce reprezentující nějaký výpočet, které se předá “zbytek výpočtu” ve formě funkce. Z Wikipedie bys mohl pochopit aspoň převod konstanty na příslušnou kontinuaci.

Synku, ja s timhle pracuju, tak snad vim, o cem mluvim.

Ty zrejme mluvis o funkci callcc, neboli call-with-current-continuation, ktera dostane parametr K, coz je kontinuace, neboli zbytek vypoctu.
Název: Re:Co si myslíte o OOP?
Přispěvatel: BaldSlattery 18. 01. 2019, 13:50:40
Kontinuace je 'zbytek vypoctu'.
Je to přesně naopak, kontinuace je funkce reprezentující nějaký výpočet, které se předá “zbytek výpočtu” ve formě funkce. Z Wikipedie bys mohl pochopit aspoň převod konstanty na příslušnou kontinuaci.

Synku, ja s timhle pracuju, tak snad vim, o cem mluvim.

Ty zrejme mluvis o funkci callcc, neboli call-with-current-continuation, ktera dostane parametr K, coz je kontinuace, neboli zbytek vypoctu.
Vůbec nevíš, která bije. Jestli s tím “pracuješ” v bakalářce, tak ji neobhájíš ani ne VŠE.

P.S. Call/cc je něco zcela jiného.
Název: Re:Co si myslíte o OOP?
Přispěvatel: Kadet 19. 01. 2019, 00:22:03
Kontinuace je 'zbytek vypoctu'.
Je to přesně naopak, kontinuace je funkce reprezentující nějaký výpočet, které se předá “zbytek výpočtu” ve formě funkce. Z Wikipedie bys mohl pochopit aspoň převod konstanty na příslušnou kontinuaci.

Synku, ja s timhle pracuju, tak snad vim, o cem mluvim.

Ty zrejme mluvis o funkci callcc, neboli call-with-current-continuation, ktera dostane parametr K, coz je kontinuace, neboli zbytek vypoctu.
Vůbec nevíš, která bije. Jestli s tím “pracuješ” v bakalářce, tak ji neobhájíš ani ne VŠE.

P.S. Call/cc je něco zcela jiného.

Mas neco cim bys prispel do diskuse nebo tady chces jen dal trollovat?

Jestli chces pokracovat tak predstav svuj argument k vyvraceni a neschovavej se za nejaky hadanky.
Název: Re:Co si myslíte o OOP?
Přispěvatel: Inkvizitor 19. 01. 2019, 10:37:28
Chlapi (a roby), mám zcela nový podnět do diskuse. Když odmyslím Lisp s jeho objektovou nadstavbou, existuje v (skutečném) OOP světě něco jako makra? Pokud ano, jak moc se používají a pokud ne, tak proč ne?
Název: Re:Co si myslíte o OOP?
Přispěvatel: gll 19. 01. 2019, 10:58:11
Chlapi (a roby), mám zcela nový podnět do diskuse. Když odmyslím Lisp s jeho objektovou nadstavbou, existuje v (skutečném) OOP světě něco jako makra? Pokud ano, jak moc se používají a pokud ne, tak proč ne?

v Crystalu se používají makra jako náhrada za runtime metaprogramování a introspekci. V dynamických jazycích jako python a ruby nejsou makra moc potřeba.

https://crystal-lang.org/

Crystal se snaží být statcké Ruby.
Název: Re:Co si myslíte o OOP?
Přispěvatel: gll 19. 01. 2019, 10:59:58
Kontinuace je 'zbytek vypoctu'.
Je to přesně naopak, kontinuace je funkce reprezentující nějaký výpočet, které se předá “zbytek výpočtu” ve formě funkce. Z Wikipedie bys mohl pochopit aspoň převod konstanty na příslušnou kontinuaci.

Synku, ja s timhle pracuju, tak snad vim, o cem mluvim.

Ty zrejme mluvis o funkci callcc, neboli call-with-current-continuation, ktera dostane parametr K, coz je kontinuace, neboli zbytek vypoctu.
Vůbec nevíš, která bije. Jestli s tím “pracuješ” v bakalářce, tak ji neobhájíš ani ne VŠE.

P.S. Call/cc je něco zcela jiného.

Mas neco cim bys prispel do diskuse nebo tady chces jen dal trollovat?

Jestli chces pokracovat tak predstav svuj argument k vyvraceni a neschovavej se za nejaky hadanky.

k čemu tedy call/cc používáš?
Název: Re:Co si myslíte o OOP?
Přispěvatel: Kit 19. 01. 2019, 11:26:49
Chlapi (a roby), mám zcela nový podnět do diskuse. Když odmyslím Lisp s jeho objektovou nadstavbou, existuje v (skutečném) OOP světě něco jako makra? Pokud ano, jak moc se používají a pokud ne, tak proč ne?

Možná by se za nástupce maker daly označit traits a templates. Nejsem však příznivcem ani jednoho z nich, protože to zhoršuje čitelnost. V OOP se dá dosáhnout znovupoužitelnosti i bez nich.
Název: Re:Co si myslíte o OOP?
Přispěvatel: Mirek Prýmek 19. 01. 2019, 12:04:22
V dynamických jazycích jako python a ruby nejsou makra moc potřeba.
V Ruby se makra (a DSLka) používají až tak extenzivně, že to dělá kód totálně nečitelný. Proto Ruby nemám rád - většina Ruby kódu, co jsem viděl, na mě působila jako že hlavní účel kódu je co největší onanie a ne srozumitelnost a čitelnost.

V Pythonu makra nejsou a proto tam taky DSLka prakticky dělat nejde. Jako skoro u všeho, python má "poor man's" variantu, která je pro některé use casy jakžtakž ucházející náhradou - dekorátory.
Název: Re:Co si myslíte o OOP?
Přispěvatel: Mirek Prýmek 19. 01. 2019, 12:13:07
Chlapi (a roby), mám zcela nový podnět do diskuse. Když odmyslím Lisp s jeho objektovou nadstavbou, existuje v (skutečném) OOP světě něco jako makra? Pokud ano, jak moc se používají a pokud ne, tak proč ne?
Já bych řekl, že principielně jsou to ortogonální koncepty. Makra slouží k automatickému generování kódu z dat - tj. jsou někde na úrovni "textu programu" (v případě hloupých C maker doslovně, v případě plnotučných na úrovni AST). OOP je o tom, jak modelovat problém, jak program strukturovat. Takže je to spíš o nějakou tu úroveň výš.

Čistě prakticky je ale pravda, že v dobrém OOP jazyce makra moc nevyužiješ, protože máš prostě jiné prostředky pro dosažení podobných cílů. IMHO makra nejvíc využiješ ve statickém, kompilovaném jazyce, který se hodně motá kolem funkcí.

P.S. a teď je přesně čas na další Go rant: "go generate"? Ve 21. století? To si snad děláte pr.del, ne!?!
Název: Re:Co si myslíte o OOP?
Přispěvatel: Kit 19. 01. 2019, 13:56:14
Chlapi (a roby), mám zcela nový podnět do diskuse. Když odmyslím Lisp s jeho objektovou nadstavbou, existuje v (skutečném) OOP světě něco jako makra? Pokud ano, jak moc se používají a pokud ne, tak proč ne?
Čistě prakticky je ale pravda, že v dobrém OOP jazyce makra moc nevyužiješ, protože máš prostě jiné prostředky pro dosažení podobných cílů. IMHO makra nejvíc využiješ ve statickém, kompilovaném jazyce, který se hodně motá kolem funkcí.

Na tom něco bude, protože občas používám m4, ale kdykoli mě napadlo, že bych s ním generoval třeba PHP, tak jsem si to velmi rychle rozmyslel, protože by to užitek nepřineslo. Je fakt, že ve Vimu používám hodně (i přetížených) maker pro generování kódu, ovšem to je jiná kapitola, protože následně neupravuji zdroj, ale vygenerovaný stub.
Název: Re:Co si myslíte o OOP?
Přispěvatel: Kadet 19. 01. 2019, 13:56:22
Makro je funkce mapujici na AST. Pokud v tom pripade jazyk povoluje pracovat se stavebnimi bloky toho jazyka, pak ma makra. Otazka je o citelnosti. Cim bliz je reprezentace v textu podobna reprezentaci v ast, tim vypada makro citelneji.
Název: Re:Co si myslíte o OOP?
Přispěvatel: Mirek Prýmek 19. 01. 2019, 14:01:37
Makro je funkce mapujici na AST.
To je jenom jeden význam slova "makro". Makrům v C taky říkáme "makra" a s AST nepracují.

Cim bliz je reprezentace v textu podobna reprezentaci v ast, tim vypada makro citelneji.
To není nutně pravda. Např. v Elixiru je AST poměrně komplikované, ale moc to nevadí, protože napřímo s ním skoro nikdy nepracuješ. Používáš totiž quote (čili normální, bežný kód) a jenom tam občas třeba vpašuješ nějaký parametr nebo tak něco.
Název: Re:Co si myslíte o OOP?
Přispěvatel: Inkvizitor 19. 01. 2019, 16:46:33
Chlapi (a roby), mám zcela nový podnět do diskuse. Když odmyslím Lisp s jeho objektovou nadstavbou, existuje v (skutečném) OOP světě něco jako makra? Pokud ano, jak moc se používají a pokud ne, tak proč ne?
Čistě prakticky je ale pravda, že v dobrém OOP jazyce makra moc nevyužiješ, protože máš prostě jiné prostředky pro dosažení podobných cílů. IMHO makra nejvíc využiješ ve statickém, kompilovaném jazyce, který se hodně motá kolem funkcí.

No makro umožňuje psát věci jinak, řekl bych líp. Třeba v Rustu println! a spol., nic lepšího jsem zatím pro formátování řetězců neviděl. Ten formát napíšu hezky čitelně a úsporně, ale zároveň se mi zkontroluje při překladu, že tam mám parametrů přesný počet, že implementují potřebný trait atd. Jelikož pozdní vazba je tak super, šlo by v OOP minimálně počítat ty parametry, počet by měl sedět i přes existenci pozdní vazby.
Název: Re:Co si myslíte o OOP?
Přispěvatel: Mirek Prýmek 19. 01. 2019, 17:44:06
ale zároveň se mi zkontroluje při překladu, že tam mám parametrů přesný počet, že implementují potřebný trait atd. Jelikož pozdní vazba je tak super, šlo by v OOP minimálně počítat ty parametry, počet by měl sedět i přes existenci pozdní vazby.
Ani na jedno z toho nepotřebuješ makra.
Název: Re:Co si myslíte o OOP?
Přispěvatel: Kit 19. 01. 2019, 18:17:09
No makro umožňuje psát věci jinak, řekl bych líp. Třeba v Rustu println! a spol., nic lepšího jsem zatím pro formátování řetězců neviděl. Ten formát napíšu hezky čitelně a úsporně, ale zároveň se mi zkontroluje při překladu, že tam mám parametrů přesný počet, že implementují potřebný trait atd. Jelikož pozdní vazba je tak super, šlo by v OOP minimálně počítat ty parametry, počet by měl sedět i přes existenci pozdní vazby.

Nahlédl jsem do manuálu Rustu a zjistil jsem, že zmíněný println! funguje stejně jako print v Pythonu. Ani PHP nezůstává nijak pozadu a také na to nepotřebuje makra. Něco mi snad uniklo?
Název: Re:Co si myslíte o OOP?
Přispěvatel: BoneFlute 19. 01. 2019, 18:45:46
Chlapi (a roby), mám zcela nový podnět do diskuse. Když odmyslím Lisp s jeho objektovou nadstavbou, existuje v (skutečném) OOP světě něco jako makra? Pokud ano, jak moc se používají a pokud ne, tak proč ne?

Asi bude (jak už to bejvá) problém s definicí, co jsou to makra.

Řekl bych, že tvému dotazu by mohlo nejvíce odpovídat některý z Aspect-Oriented frameworků pro Javu, které zasahují do výsledného bytecode.

Osobně se domnívám, že největší motivace jsou takové ty short-circuit operátory, nebo podobné serepetičky. Páč jinak mě nenapadá na co by nutně muselo být makro potřeba. Všechno se dá zapsat funkcí :-)
Název: Re:Co si myslíte o OOP?
Přispěvatel: Kit 19. 01. 2019, 18:58:27
Osobně se domnívám, že největší motivace jsou takové ty short-circuit operátory, nebo podobné serepetičky. Páč jinak mě nenapadá na co by nutně muselo být makro potřeba. Všechno se dá zapsat funkcí :-)

Všiml jsem si, že některé kompilátory privátní metody normálně expandují, jako by to bylo makro.
Název: Re:Co si myslíte o OOP?
Přispěvatel: Kadet 19. 01. 2019, 19:39:42
Makro je funkce mapujici na AST.
To je jenom jeden význam slova "makro". Makrům v C taky říkáme "makra" a s AST nepracují.
V C je makro preprocessoru mapovani z prvni textovy na druhou textovou reprezentaci. Kompiler pak prevede vysledek na ast a ten pak hodi do vyslednyho binarniho kodu.

Textova reprezentace (C plus preprocessor) -> Textova reprezentace (C) -> ast -> target

Jinymi slovy, nejaka funkce, ktera transformuje reprezentaci programu predtim nez se prevese na AST nebo na target. Zkratka nejaky predchroupani at uz jakyhokoliv typu.


quote author=Mirek Prýmek link=topic=20380.msg304529#msg304529 date=1547902897]
Cim bliz je reprezentace v textu podobna reprezentaci v ast, tim vypada makro citelneji.
To není nutně pravda. Např. v Elixiru je AST poměrně komplikované, ale moc to nevadí, protože napřímo s ním skoro nikdy nepracuješ. Používáš totiž quote (čili normální, bežný kód) a jenom tam občas třeba vpašuješ nějaký parametr nebo tak něco.
[/quote]

Elixir ma myslim prave jednoduchou a homoikonickou reprezentaci AST. Vsemozny konstrukce jako classy jsou implementovany prave pres manipulaci AST, pokud si vzpominam.

Pokud do quotace muzes vlozit parametr, pak se podle me jedna o tzv. quasiquotaci.

abcd - text
"abcd" - quotovany text, neboli string
f"abcd {n}" - quasiquotovany string, neboli string interpolation
Název: Re:Co si myslíte o OOP?
Přispěvatel: Mirek Prýmek 19. 01. 2019, 20:15:25
Jinymi slovy, nejaka funkce, ktera transformuje reprezentaci programu predtim nez se prevese na AST nebo na target. Zkratka nejaky predchroupani at uz jakyhokoliv typu.
No ono to právě není jedno, jakýho typu. Buď pracuju s textem, aniž bych znal jeho význam, nebo pracuju s AST. To je úplně něco jinýho a má to výrazně jiné možnosti.

Elixir ma myslim prave jednoduchou a homoikonickou reprezentaci AST.
No asi je to otázka, čemu chceš říkat "jednoduchá". Každopádně kdybys měl napsat AST tak, aby ti vygenerovalo nějaký kód, tak bys z toho moc nadšenej nebyl, je to trochu opruz. Jak jsem ale řekl, v drtivé většině případů to nepotřebuješ dělat.

Vsemozny konstrukce jako classy jsou implementovany prave pres manipulaci AST, pokud si vzpominam.
Elixir žádné classy nemá a makra se nepoužívají zas tak často (autor jazyka správně tvrdí, že zlaté pravidlo je "dokud to jde udělat funkcí, udělejte to funkcí"). Takže to si spíš asi s něčím pleteš.

Pokud do quotace muzes vlozit parametr, pak se podle me jedna o tzv. quasiquotaci.

abcd - text
"abcd" - quotovany text, neboli string
f"abcd {n}" - quasiquotovany string, neboli string interpolation
Tohle vůbec nechápu. S interpolací to, o čem jsem mluvil, nemá nic společnýho.

quote je taková trochu speciální funkce, která:
1. se spouští při překladu
2. vložíš do ní normální blok kódu a ona ti vrátí příslušný AST
3. tj. když do toho kódu vpašuješ parametr, quote ti ho vpašuje do toho AST, aniž bys AST musel "ručně" upravovat (provádět operace přímo nad daty AST)

Kód: [Vybrat]
$ iex
Erlang/OTP 21 [erts-10.0] [source] [64-bit] [smp:4:4] [ds:4:4:10] [async-threads:1] [hipe]

Interactive Elixir (1.6.6) - press Ctrl+C to exit (type h() ENTER for help)

iex(1)> quote do if f(1) do 1 else 2 end end
{:if, [context: Elixir, import: Kernel], [{:f, [], [1]}, [do: 1, else: 2]]}

iex(2)> f(1)
** (CompileError) iex:2: undefined function f/1

- na tomhle vidíš:

1. quote skutečně "cituje" svůj parametr (převádí ho na AST) - používám tam fci f/1, která není definovaná a ničemu to nevadí, protože se v tuhle chvíli nevolá

2. to elixirovské AST je fakt celkem komplikované (a tohle je ještě jednoduchý příklad, mohl bych ukázat složitější), není to jako v Lispu
Název: Re:Co si myslíte o OOP?
Přispěvatel: Mirek Prýmek 19. 01. 2019, 20:47:15
Osobně se domnívám, že největší motivace jsou takové ty short-circuit operátory, nebo podobné serepetičky. Páč jinak mě nenapadá na co by nutně muselo být makro potřeba. Všechno se dá zapsat funkcí :-)
Občas se s tím dají udělat docela dobrý kravinky pro optimalizaci.

Např. kdysi (nevím jestli ještě dneska) byl v Elixiru nějakej modul pro zpracování unicode napsanej tak, že se online (fakt ve chvíli překladu std. knihovny) stáhla aktuální specifikace z nějakých stránek unicode.org nebo co - a přímo z té specifikace se makrem vygeneroval kód. Taková blbůstka :)
Název: Re:Co si myslíte o OOP?
Přispěvatel: Inkvizitor 20. 01. 2019, 09:09:24
No makro umožňuje psát věci jinak, řekl bych líp. Třeba v Rustu println! a spol., nic lepšího jsem zatím pro formátování řetězců neviděl. Ten formát napíšu hezky čitelně a úsporně, ale zároveň se mi zkontroluje při překladu, že tam mám parametrů přesný počet, že implementují potřebný trait atd. Jelikož pozdní vazba je tak super, šlo by v OOP minimálně počítat ty parametry, počet by měl sedět i přes existenci pozdní vazby.

Nahlédl jsem do manuálu Rustu a zjistil jsem, že zmíněný println! funguje stejně jako print v Pythonu. Ani PHP nezůstává nijak pozadu a také na to nepotřebuje makra. Něco mi snad uniklo?

Uniklo Ti to, co jsem psal. Když napíšu málo parametrů pro formát v Pythonu, v runtime mi to hodí výjimku. Překladač Rustu odmítne chybné parametry makra při překladu.
Název: Re:Co si myslíte o OOP?
Přispěvatel: gll 20. 01. 2019, 09:36:23
Uniklo Ti to, co jsem psal. Když napíšu málo parametrů pro formát v Pythonu, v runtime mi to hodí výjimku. Překladač Rustu odmítne chybné parametry makra při překladu.

parametry format může v pythonu kontrolovat linter

https://pypi.org/project/flake8-string-format/

Python 3.6, má format stringy,  kontrola názvů proměnných uvnitř format stringu funguje normálně.
Název: Re:Co si myslíte o OOP?
Přispěvatel: gll 20. 01. 2019, 09:51:08
V dynamických jazycích jako python a ruby nejsou makra moc potřeba.
V Ruby se makra (a DSLka) používají až tak extenzivně, že to dělá kód totálně nečitelný. Proto Ruby nemám rád - většina Ruby kódu, co jsem viděl, na mě působila jako že hlavní účel kódu je co největší onanie a ne srozumitelnost a čitelnost.

to nejsou makra. V Ruby jsou možná makra jen pomocí third party knihoven, ale nikdo je nepoužívá. Matsumoto se vyjádřil jasně, že makra v jazyku typu Ruby nejsou potřeba.
Název: Re:Co si myslíte o OOP?
Přispěvatel: Kadet 20. 01. 2019, 11:03:18
Jinymi slovy, nejaka funkce, ktera transformuje reprezentaci programu predtim nez se prevese na AST nebo na target. Zkratka nejaky predchroupani at uz jakyhokoliv typu.
No ono to právě není jedno, jakýho typu. Buď pracuju s textem, aniž bych znal jeho význam, nebo pracuju s AST. To je úplně něco jinýho a má to výrazně jiné možnosti.

Elixir ma myslim prave jednoduchou a homoikonickou reprezentaci AST.
No asi je to otázka, čemu chceš říkat "jednoduchá". Každopádně kdybys měl napsat AST tak, aby ti vygenerovalo nějaký kód, tak bys z toho moc nadšenej nebyl, je to trochu opruz. Jak jsem ale řekl, v drtivé většině případů to nepotřebuješ dělat.

Vsemozny konstrukce jako classy jsou implementovany prave pres manipulaci AST, pokud si vzpominam.
Elixir žádné classy nemá a makra se nepoužívají zas tak často (autor jazyka správně tvrdí, že zlaté pravidlo je "dokud to jde udělat funkcí, udělejte to funkcí"). Takže to si spíš asi s něčím pleteš.

Pokud do quotace muzes vlozit parametr, pak se podle me jedna o tzv. quasiquotaci.

abcd - text
"abcd" - quotovany text, neboli string
f"abcd {n}" - quasiquotovany string, neboli string interpolation
Tohle vůbec nechápu. S interpolací to, o čem jsem mluvil, nemá nic společnýho.

quote je taková trochu speciální funkce, která:
1. se spouští při překladu
2. vložíš do ní normální blok kódu a ona ti vrátí příslušný AST
3. tj. když do toho kódu vpašuješ parametr, quote ti ho vpašuje do toho AST, aniž bys AST musel "ručně" upravovat (provádět operace přímo nad daty AST)

Kód: [Vybrat]
$ iex
Erlang/OTP 21 [erts-10.0] [source] [64-bit] [smp:4:4] [ds:4:4:10] [async-threads:1] [hipe]

Interactive Elixir (1.6.6) - press Ctrl+C to exit (type h() ENTER for help)

iex(1)> quote do if f(1) do 1 else 2 end end
{:if, [context: Elixir, import: Kernel], [{:f, [], [1]}, [do: 1, else: 2]]}

iex(2)> f(1)
** (CompileError) iex:2: undefined function f/1

- na tomhle vidíš:

1. quote skutečně "cituje" svůj parametr (převádí ho na AST) - používám tam fci f/1, která není definovaná a ničemu to nevadí, protože se v tuhle chvíli nevolá

2. to elixirovské AST je fakt celkem komplikované (a tohle je ještě jednoduchý příklad, mohl bych ukázat složitější), není to jako v Lispu

V elixiru to jsou protocoly a jiny struktury, ne classy, ale nic to nemeni na to, ze jsou implementovany az v elixiru pomoci maker.

Pomoci quote a unquote delas v elixiru quasiquotaci. Klasicka quotace neni dostatecna. Priklad byl na quotaci stringu, kterou jsi nepochopil. V tomhle pripade nequotuju AST, ale pouze string. Doslova quotuju protoze pouzivam uvozovky.

Elixir AST je vlastne lisp, az na druhy parametr coz je nejaky context. Elixir je syntakticky cukr nad timhle jednoduchym AST.

https://hackernoon.com/understanding-elixir-macros-3464e141434c
Název: Re:Co si myslíte o OOP?
Přispěvatel: BaldSlattery 20. 01. 2019, 11:36:21
Jinymi slovy, nejaka funkce, ktera transformuje reprezentaci programu predtim nez se prevese na AST nebo na target. Zkratka nejaky predchroupani at uz jakyhokoliv typu.
No ono to právě není jedno, jakýho typu. Buď pracuju s textem, aniž bych znal jeho význam, nebo pracuju s AST. To je úplně něco jinýho a má to výrazně jiné možnosti.

Elixir ma myslim prave jednoduchou a homoikonickou reprezentaci AST.
No asi je to otázka, čemu chceš říkat "jednoduchá". Každopádně kdybys měl napsat AST tak, aby ti vygenerovalo nějaký kód, tak bys z toho moc nadšenej nebyl, je to trochu opruz. Jak jsem ale řekl, v drtivé většině případů to nepotřebuješ dělat.

Vsemozny konstrukce jako classy jsou implementovany prave pres manipulaci AST, pokud si vzpominam.
Elixir žádné classy nemá a makra se nepoužívají zas tak často (autor jazyka správně tvrdí, že zlaté pravidlo je "dokud to jde udělat funkcí, udělejte to funkcí"). Takže to si spíš asi s něčím pleteš.

Pokud do quotace muzes vlozit parametr, pak se podle me jedna o tzv. quasiquotaci.

abcd - text
"abcd" - quotovany text, neboli string
f"abcd {n}" - quasiquotovany string, neboli string interpolation
Tohle vůbec nechápu. S interpolací to, o čem jsem mluvil, nemá nic společnýho.

quote je taková trochu speciální funkce, která:
1. se spouští při překladu
2. vložíš do ní normální blok kódu a ona ti vrátí příslušný AST
3. tj. když do toho kódu vpašuješ parametr, quote ti ho vpašuje do toho AST, aniž bys AST musel "ručně" upravovat (provádět operace přímo nad daty AST)

Kód: [Vybrat]
$ iex
Erlang/OTP 21 [erts-10.0] [source] [64-bit] [smp:4:4] [ds:4:4:10] [async-threads:1] [hipe]

Interactive Elixir (1.6.6) - press Ctrl+C to exit (type h() ENTER for help)

iex(1)> quote do if f(1) do 1 else 2 end end
{:if, [context: Elixir, import: Kernel], [{:f, [], [1]}, [do: 1, else: 2]]}

iex(2)> f(1)
** (CompileError) iex:2: undefined function f/1

- na tomhle vidíš:

1. quote skutečně "cituje" svůj parametr (převádí ho na AST) - používám tam fci f/1, která není definovaná a ničemu to nevadí, protože se v tuhle chvíli nevolá

2. to elixirovské AST je fakt celkem komplikované (a tohle je ještě jednoduchý příklad, mohl bych ukázat složitější), není to jako v Lispu

V elixiru to jsou protocoly a jiny struktury, ne classy, ale nic to nemeni na to, ze jsou implementovany az v elixiru pomoci maker.

Pomoci quote a unquote delas v elixiru quasiquotaci. Klasicka quotace neni dostatecna. Priklad byl na quotaci stringu, kterou jsi nepochopil. V tomhle pripade nequotuju AST, ale pouze string. Doslova quotuju protoze pouzivam uvozovky.

Elixir AST je vlastne lisp, az na druhy parametr coz je nejaky context. Elixir je syntakticky cukr nad timhle jednoduchym AST.

https://hackernoon.com/understanding-elixir-macros-3464e141434c
Ty jseš dokonalý příklad Dunning-Krugera, jako vystřižený z jedné glosy o flatearthers “Retarded monkeys lecturing Nobel laureates”. No nic, každé fórum musí mít svého šaška, jde ti to lépe jež javamanovi ;)
Název: Re:Co si myslíte o OOP?
Přispěvatel: gll 20. 01. 2019, 11:38:12
Ty jseš dokonalý příklad Dunning-Krugera, jako vystřižený z jedné glosy o flatearthers “Retarded monkeys lecturing Nobel laureates”. No nic, každé fórum musí mít svého šaška, jde ti to lépe jež javamanovi ;)

v čem nemá pravdu?
Název: Re:Co si myslíte o OOP?
Přispěvatel: BaldSlattery 20. 01. 2019, 11:48:00
Ty jseš dokonalý příklad Dunning-Krugera, jako vystřižený z jedné glosy o flatearthers “Retarded monkeys lecturing Nobel laureates”. No nic, každé fórum musí mít svého šaška, jde ti to lépe jež javamanovi ;)
v čem nemá pravdu?
V těch kecech o logách, kontinuacích, ASTu...
Název: Re:Co si myslíte o OOP?
Přispěvatel: Inkvizitor 20. 01. 2019, 11:56:29
Uniklo Ti to, co jsem psal. Když napíšu málo parametrů pro formát v Pythonu, v runtime mi to hodí výjimku. Překladač Rustu odmítne chybné parametry makra při překladu.

parametry format může v pythonu kontrolovat linter

https://pypi.org/project/flake8-string-format/

Python 3.6, má format stringy,  kontrola názvů proměnných uvnitř format stringu funguje normálně.

Linter může kotrolovat jenom to, čemu rozumí. Makro si můžu napsat vlastní a mám to i s tou kontrolou, nejde jenom o standardní knihovnu.  Mimochodem právě na Pylintu je vidět, jak se vyplatí psát všechno "hloupě" jako ve statických jazycích, jinak přestane chápat, co se kam může posílat a kde se bere jaká hodnota a už nám s kontrolou nepomůže.
Název: Re:Co si myslíte o OOP?
Přispěvatel: Kit 20. 01. 2019, 12:12:34
No makro umožňuje psát věci jinak, řekl bych líp. Třeba v Rustu println! a spol., nic lepšího jsem zatím pro formátování řetězců neviděl. Ten formát napíšu hezky čitelně a úsporně, ale zároveň se mi zkontroluje při překladu, že tam mám parametrů přesný počet, že implementují potřebný trait atd. Jelikož pozdní vazba je tak super, šlo by v OOP minimálně počítat ty parametry, počet by měl sedět i přes existenci pozdní vazby.
Nahlédl jsem do manuálu Rustu a zjistil jsem, že zmíněný println! funguje stejně jako print v Pythonu. Ani PHP nezůstává nijak pozadu a také na to nepotřebuje makra. Něco mi snad uniklo?
Uniklo Ti to, co jsem psal. Když napíšu málo parametrů pro formát v Pythonu, v runtime mi to hodí výjimku. Překladač Rustu odmítne chybné parametry makra při překladu.

Však to v Pythonu odchytí testy, ne?
Název: Re:Co si myslíte o OOP?
Přispěvatel: Mirek Prýmek 20. 01. 2019, 12:27:34
to nejsou makra. V Ruby jsou možná makra jen pomocí third party knihoven, ale nikdo je nepoužívá. Matsumoto se vyjádřil jasně, že makra v jazyku typu Ruby nejsou potřeba.
Ok, je to možný, že to nejsou makra v tom smyslu, jak jsou implementovaný v Lispu nebo Elixiru. Ruby neznám tolik, abych to uměl pořádně posoudit. Každopádně se tomu makra říká [1] a používá se to k zavádění nové syntaxe, DSLek apod., což je typickej use case pro makra. A ten bordel, co tím Rubyisti vytvořili, je taky typickej pro nevhodný použití maker.

Pokud jsem se v tomhle nechal ošálit tím, že lidi používají zavádějící označení, a symptomatikou používání ne-maker v Ruby, tak se omlouvám a dík za korekci.

[1] https://pragmaticstudio.com/tutorials/ruby-macros

Název: Re:Co si myslíte o OOP?
Přispěvatel: Mirek Prýmek 20. 01. 2019, 12:32:18
v čem nemá pravdu?
Všechno jsou to takový víc nebo míň zavádějící polopravdy, u kterých (alespoň mně) vlastně není vůbec jasný, co chtěl Kadet sdělit, kromě toho, že použil správný klíčový slova. Moc nemá smysl to kdovíjak rozebírat, protože zas jenom skončíme u nekonečnýho hádání se o slova a význam vět, což mě nebaví.
Název: Re:Co si myslíte o OOP?
Přispěvatel: Mirek Prýmek 20. 01. 2019, 12:47:04
V elixiru to jsou protocoly a jiny struktury, ne classy, ale nic to nemeni na to, ze jsou implementovany az v elixiru pomoci maker.
Nevím, o čem přesně mluvíš. No třeba "defprotocol" je makro, no. A co z toho má plynout? Nevím, kam míříš.

Pomoci quote a unquote delas v elixiru quasiquotaci. Klasicka quotace neni dostatecna.
Pojem "quasiquotace" slyším poprvé. Jestli rozdíl mezi quotací a quasi-quotací má být v tom, že do toho druhýho můžeš dávat parametry, tak samozřejmě. Makra bez parametrů by byla dost naprd, to je jasný. A proč to říkáš?

Priklad byl na quotaci stringu, kterou jsi nepochopil.
Pochopil, ale nepřijde mi to jako dobrej příklad. Je srozumitelnej jenom tomu, kdo už ví, co makra jsou, a najde si to v tom.

Elixir AST je vlastne lisp, az na druhy parametr coz je nejaky context.
To právě imho není vždycky pravda. AFAIK, v Lispu je vždycky jasný, jak AST pro nějaký výraz bude vypadat. V Elixiru je to trochu komplikovanější - různé struktury se převádí na různá AST data, z prstu si to nevycucáš, musíš si to buď zkusit, nebo si to najít v dokumentaci. Např.:

Kód: [Vybrat]
iex(2)> quote do [1,2,3] end
[1, 2, 3]
iex(3)> quote do [1,2|3] end
[1, {:|, [], [2, 3]}]
iex(4)> quote do [1,2|_] end
[1, {:|, [], [2, {:_, [], Elixir}]}]
- tady prostě musíš vědět, že "|" se do AST převede zrovna takhle. AST by klidně mohlo vypadat klidně jinak. Úplně 100%ně intuitivní to není.

Elixir je syntakticky cukr nad timhle jednoduchym AST.
Jako celý Elixir? To rozhodně není pravda. Některé věci jsou v Elixiru samozřejmě implementované pomocí maker. Proč ne, když tam ta makra jsou a dává to smysl?

https://hackernoon.com/understanding-elixir-macros-3464e141434c
Proč mi tenhle link dáváš? Já vím, k čemu se makra v Elixiru používají, pracuju s nima často.

----
Vůbec celkově nechápu, co se vlastně snažíš říct - jestli jenom upřesňuješ něco z toho, co jsem řekl, nebo něco vyvracíš, nebo jenom tak plkáme. Zkus být trochu explicitnější, jestli chceš o něčem diskutovat - pokud možno zkus prosím použít věty jako "v tomhle nemáš pravdu", "tohle bych upřesnil" apod. :)
Název: Re:Co si myslíte o OOP?
Přispěvatel: Mirek Prýmek 20. 01. 2019, 13:14:49
A tohle už jenom fakt na okraj, jako ilustrace, jak v těch pojmech děláš zmatek a je obtížný ti rozumět:

V tomhle pripade nequotuju AST
AST se nequotuje. AST je výsledkem quotace. Quotuje se (platný) výraz (jazyka).
Název: Re:Co si myslíte o OOP?
Přispěvatel: Kadet 20. 01. 2019, 14:30:36
V elixiru to jsou protocoly a jiny struktury, ne classy, ale nic to nemeni na to, ze jsou implementovany az v elixiru pomoci maker.
Nevím, o čem přesně mluvíš. No třeba "defprotocol" je makro, no. A co z toho má plynout? Nevím, kam míříš.

Pomoci quote a unquote delas v elixiru quasiquotaci. Klasicka quotace neni dostatecna.
Pojem "quasiquotace" slyším poprvé. Jestli rozdíl mezi quotací a quasi-quotací má být v tom, že do toho druhýho můžeš dávat parametry, tak samozřejmě. Makra bez parametrů by byla dost naprd, to je jasný. A proč to říkáš?

Priklad byl na quotaci stringu, kterou jsi nepochopil.
Pochopil, ale nepřijde mi to jako dobrej příklad. Je srozumitelnej jenom tomu, kdo už ví, co makra jsou, a najde si to v tom.

Elixir AST je vlastne lisp, az na druhy parametr coz je nejaky context.
To právě imho není vždycky pravda. AFAIK, v Lispu je vždycky jasný, jak AST pro nějaký výraz bude vypadat. V Elixiru je to trochu komplikovanější - různé struktury se převádí na různá AST data, z prstu si to nevycucáš, musíš si to buď zkusit, nebo si to najít v dokumentaci. Např.:

Kód: [Vybrat]
iex(2)> quote do [1,2,3] end
[1, 2, 3]
iex(3)> quote do [1,2|3] end
[1, {:|, [], [2, 3]}]
iex(4)> quote do [1,2|_] end
[1, {:|, [], [2, {:_, [], Elixir}]}]
- tady prostě musíš vědět, že "|" se do AST převede zrovna takhle. AST by klidně mohlo vypadat klidně jinak. Úplně 100%ně intuitivní to není.

Elixir je syntakticky cukr nad timhle jednoduchym AST.
Jako celý Elixir? To rozhodně není pravda. Některé věci jsou v Elixiru samozřejmě implementované pomocí maker. Proč ne, když tam ta makra jsou a dává to smysl?

https://hackernoon.com/understanding-elixir-macros-3464e141434c
Proč mi tenhle link dáváš? Já vím, k čemu se makra v Elixiru používají, pracuju s nima často.

----
Vůbec celkově nechápu, co se vlastně snažíš říct - jestli jenom upřesňuješ něco z toho, co jsem řekl, nebo něco vyvracíš, nebo jenom tak plkáme. Zkus být trochu explicitnější, jestli chceš o něčem diskutovat - pokud možno zkus prosím použít věty jako "v tomhle nemáš pravdu", "tohle bych upřesnil" apod. :)

Mirku, ocenuju tvuj konstruktivni styl diskuse. Narozdil od nekterych mistnich trollu, ktery by meli dostat ban nebo pres zadek.

Docela se ta nase debata zkomplikovala, tak to zjednodusim.

Quasiquotace nebo quotace je detail. Quasi je obecnejsi. Ale kdyz lidi rikaji quotace, pravdepodobne mysli quasi. Jen pro upresneni.

Elixir je syntakticky cukr nad ast co v textu vypada skoro uplne presne jako lisp. Ta transformace z elixiru do de facto lispu je komplikovana kvuli vsemoznym infix operatorum, ktery se akorat prevedou na prefiz operatory. Je to krasne videt na prikladu co jsi postnul.

Dalo by se rict, ze je to instance Greenspunova desateho pravidla.
https://en.m.wikipedia.org/wiki/Greenspun%27s_tenth_rule

Jestli neco tvrdim, pak je to, ze si lidi delaji veci komplikovanejsi nez jsou a pak se v tom ztraci. Viz to ze je elixir komplikovanejsi lisp, ale zato je citelnejsi.

Nekdy to delam tak ze poukazu na nejasny pouziti vyrazu. Nekdy to pomuze, jindy to urazi. Neminim to jako utok.

Predtim jsem upresnoval definici co to je makro. Tvrdim ze to je nejaka funkce ktera produkuje reprezentaci programu, at uz text v pripade C preprosessoru nebo rovnou ast v pripade treba toho quote v elixiru. Ocenuji kdyz mi to nekdo zkousi vyvratit, protoze se mi tim zpresnuje definice. Neocenuji, kdyz to nekoho urazi a zacne kolem sebe kopat.
Název: Re:Co si myslíte o OOP?
Přispěvatel: mmm 20. 01. 2019, 15:04:27
Ty jseš dokonalý příklad Dunning-Krugera, jako vystřižený z jedné glosy o flatearthers “Retarded monkeys lecturing Nobel laureates”. No nic, každé fórum musí mít svého šaška, jde ti to lépe jež javamanovi ;)

Flateartheři jsou to herci. Ty jejich videa jsou psyop. Sám jsi retard, když tomu věříš.
Název: Re:Co si myslíte o OOP?
Přispěvatel: mmm 20. 01. 2019, 15:09:23
Ty jseš dokonalý příklad Dunning-Krugera, jako vystřižený z jedné glosy o flatearthers “Retarded monkeys lecturing Nobel laureates”. No nic, každé fórum musí mít svého šaška, jde ti to lépe jež javamanovi ;)

Flateartheři jsou herci. Ty jejich videa jsou psyop. Sám jsi retard, když tomu věříš.
Název: Re:Co si myslíte o OOP?
Přispěvatel: Mirek Prýmek 20. 01. 2019, 15:22:29
Quasiquotace nebo quotace je detail. Quasi je obecnejsi. Ale kdyz lidi rikaji quotace, pravdepodobne mysli quasi. Jen pro upresneni.
Ok, tohle upřesnění může mít smysl.

Elixir je syntakticky cukr nad ast [...] Dalo by se rict, ze je to instance Greenspunova desateho pravidla.
https://en.m.wikipedia.org/wiki/Greenspun%27s_tenth_rule
S tímhle nemůžu souhlasit, hlavně ze dvou důvodů:

1. je to tak strašně obecné tvrzení, že těžko říct, co tím myslíš. Je to jako když někdo řekne "Češi jsou [...]". Nevím, jestli myslíš "většinu aspektů", "všechny aspekty" nebo "některé aspekty" jazyka...

2. Elixir má spoustu featur a některé jsou dost unikátní. Např. posílání zpráv, procesy, atd. Jestli ti v něčem přijde jako "zakuklený lisp", tak jenom na nejnižší úrovni - a na té je to (v nějakém, příliš obecném smyslu) prakticky každý jazyk. Mohl bys klidně říct, že "všechno je zakuklený lambda kalkul". Takové tvrzení není k ničemu dobré.

Ta transformace z elixiru do de facto lispu je komplikovana kvuli vsemoznym infix operatorum, ktery se akorat prevedou na prefiz operatory. Je to krasne videt na prikladu co jsi postnul.
Právě na tom příkladu je vidět, že to není tak, jak píšeš. Proč se tam to "[1,2|_]" nepřevede třeba na
Kód: [Vybrat]
{:|, [], [
  [1,2],
  {:_, [], Elixir}
]}
? No, protože se tak autoři jazyka z nějakých důvodů rozhodli. A klidně se mohli rozhodnout jinak. Dokud se s tím jejich rozhodnutím neseznámíš, nevíš.

Nekdy to delam tak ze poukazu na nejasny pouziti vyrazu. Nekdy to pomuze, jindy to urazi. Neminim to jako utok.
V pohodě, za to jsem vždycky vděčný. Akorát, upřímně řečeno, u tebe to na mě často nepůsobí jako upřesnění, ale spíš jako zamlžení.

Predtim jsem upresnoval definici co to je makro.
No, to je přesně ten případ. Nepřijde mi, že bys to nějak upřesnil. Kdybys to chtěl upřesnit, mohl's napsat něco jako "maker máme X typů, jsou to [...] a rozdíl mezi nimi je v [...] přičemž jazyk Z má makra typu [...]" apod.
Název: Re:Co si myslíte o OOP?
Přispěvatel: Mirek Prýmek 20. 01. 2019, 15:30:55
Ještě přípodotek k tomuhle:
2. Elixir má spoustu featur a některé jsou dost unikátní. Např. posílání zpráv, procesy, atd. Jestli ti v něčem přijde jako "zakuklený lisp", tak jenom na nejnižší úrovni - a na té je to (v nějakém, příliš obecném smyslu) prakticky každý jazyk. Mohl bys klidně říct, že "všechno je zakuklený lambda kalkul". Takové tvrzení není k ničemu dobré.
Kdybys napsal, že Elixir je syntaktický cukr nad Erlangem, tak by to bylao jiný kafe. Tohle tvrzení se objevuje relativně často a je prokazatelně nepravdivé. Viz např. https://joearms.github.io/published/2013-05-31-a-week-with-elixir.html (přímo od Armstronga, takže celkem autoritativní ;) ). Jediný příklad za všechny:
Kód: [Vybrat]
In Erlang FORMS are not EXPRESSIONS.
(disclaimer: ten článek je dost starý a některé věci už pro aktuální Elixir nemusí platit)
Název: Re:Co si myslíte o OOP?
Přispěvatel: Kadet 20. 01. 2019, 15:39:39
Quasiquotace nebo quotace je detail. Quasi je obecnejsi. Ale kdyz lidi rikaji quotace, pravdepodobne mysli quasi. Jen pro upresneni.
Ok, tohle upřesnění může mít smysl.

Elixir je syntakticky cukr nad ast [...] Dalo by se rict, ze je to instance Greenspunova desateho pravidla.
https://en.m.wikipedia.org/wiki/Greenspun%27s_tenth_rule
S tímhle nemůžu souhlasit, hlavně ze dvou důvodů:

1. je to tak strašně obecné tvrzení, že těžko říct, co tím myslíš. Je to jako když někdo řekne "Češi jsou [...]". Nevím, jestli myslíš "většinu aspektů", "všechny aspekty" nebo "některé aspekty" jazyka...

2. Elixir má spoustu featur a některé jsou dost unikátní. Např. posílání zpráv, procesy, atd. Jestli ti v něčem přijde jako "zakuklený lisp", tak jenom na nejnižší úrovni - a na té je to (v nějakém, příliš obecném smyslu) prakticky každý jazyk. Mohl bys klidně říct, že "všechno je zakuklený lambda kalkul". Takové tvrzení není k ničemu dobré.

Ta transformace z elixiru do de facto lispu je komplikovana kvuli vsemoznym infix operatorum, ktery se akorat prevedou na prefiz operatory. Je to krasne videt na prikladu co jsi postnul.
Právě na tom příkladu je vidět, že to není tak, jak píšeš. Proč se tam to "[1,2|_]" nepřevede třeba na
Kód: [Vybrat]
{:|, [], [
  [1,2],
  {:_, [], Elixir}
]}
? No, protože se tak autoři jazyka z nějakých důvodů rozhodli. A klidně se mohli rozhodnout jinak. Dokud se s tím jejich rozhodnutím neseznámíš, nevíš.

Nekdy to delam tak ze poukazu na nejasny pouziti vyrazu. Nekdy to pomuze, jindy to urazi. Neminim to jako utok.
V pohodě, za to jsem vždycky vděčný. Akorát, upřímně řečeno, u tebe to na mě často nepůsobí jako upřesnění, ale spíš jako zamlžení.

Predtim jsem upresnoval definici co to je makro.
No, to je přesně ten případ. Nepřijde mi, že bys to nějak upřesnil. Kdybys to chtěl upřesnit, mohl's napsat něco jako "maker máme X typů, jsou to [...] a rozdíl mezi nimi je v [...] přičemž jazyk Z má makra typu [...]" apod.

Ok, Syntakticka cast elixiru je syntakticky cukr nad skoro lispem. Skoro lispem protoze stale micha infix a prefix syntax. Infix v pripade toho seznamu. Mohl by ho reprezentovat jako (, 1 2 3) misto infixovyho [1,2,3]. Tvuj priklad kodu mi pripada, ze nedela totez co tvuj prechodi priklad. Autori se rozhodli ze nekdy je lepsi citelnost nebo vykonnost nad jednoduchosti a proto zamichali infix a prefix zapis v elixir ast. Podobne v clojure, coz je lisp family ale mota tam infix notaci kvuli citelnosti. Clojure vypada vic jako cisty lisp. U elixiru musi clovek vic zamhourit oci aby to videl.

Podle me je uzitecny kdyz lidi vidi ze programujou v lamda kalkulu se spoustou syntaktickyho cukru. Pak si muzou konecne uvedomit, ze lambda kalkul neni dostatecny na reprezentovani problemu realneho sveta, kde figuruje cas, ktery se v lambda kalkulu neda reprezentovat. Proto vsemozne jazyky pouze vychazeji z lambda kalkulu ale pak pridavaji dalsi featury aby se vubec s casem nebo I/O dalo pracovat.

Obecnejsi kalkul je pi kalkulus nebo petriho site a erlang/elixir pripomina vic prave je.

Nad programem v konkretnim jazyce je tezky delat zavery. Nad kalkulem to jde snaz protoze je jednodussi a neobsahuje horu syntaktickyho cukru.

U tech maker jsi mi ty vyjmenoval ruzny priklady, napr. priklad C preprocessoru, proto uz jsem misto vypisu moznych prikladu uz jen zobecnil definici. Pak jsem to ale v jednom prispevku vyjmenoval, tak nevim o cem se hadame.
Název: Re:Co si myslíte o OOP?
Přispěvatel: Mirek Prýmek 20. 01. 2019, 16:06:41
Ok, Syntakticka cast elixiru je syntakticky cukr nad skoro lispem.
Já ti pořád snáším argumenty, proč to není pravda (resp. je to zavádějící) a ty to pořád opakuješ :) Buď si ten "skoro lisp" nadefinuješ tak, že "syntaktický cukr nad skoro lispem" bude všechno, nebo to nebude Elixir. Tak jako tak není to tvoje tvrzení k ničemu dobré, protože víc zamlžuje než objasňuje.

Mohli bysme jít do detailů a ukázat, že Elixir má věci, které v Lispu nemají ekvivalent, ale upřímně říkám, že s tebou se mi do toho nechce, nevidím v tom smysl.

Skoro lispem protoze stale micha infix a prefix syntax. Infix v pripade toho seznamu. Mohl by ho reprezentovat jako (, 1 2 3) misto infixovyho [1,2,3]. Tvuj priklad kodu mi pripada, ze nedela totez co tvuj prechodi priklad. Autori se rozhodli ze nekdy je lepsi citelnost nebo vykonnost nad jednoduchosti a proto zamichali infix a prefix zapis v elixir ast.
Abych to (naposledy) shrnul: Nejde o infix a prefix. Neukazoval jsem kód, ale AST. A není to totéž AST, protože jsem ukazoval dvě představitelné varianty, jak by se dal do AST zakódovat jeden elixirovský výraz. A rozhodnutí, který z těch dvou bude skutečně použit, je arbitrární. Tím argumentuju pro to, že narozdíl od Lispu, v Elixiru není intuitivně jasné, jak bude AST vypadat, což je podstatný rozdíl. Proto považuju tvoje tvrzení "je to vlastně Lisp" za zavádějící.
Název: Re:Co si myslíte o OOP?
Přispěvatel: Inkvizitor 20. 01. 2019, 16:26:02
Uniklo Ti to, co jsem psal. Když napíšu málo parametrů pro formát v Pythonu, v runtime mi to hodí výjimku. Překladač Rustu odmítne chybné parametry makra při překladu.

Však to v Pythonu odchytí testy, ne?

Ano, na každém jednotlivém místě, kde potenciálně zavoláš danou funkci, to musíš pokrýt testem. Při použití makra ne. A je to horší, v Pythonu můžeš do formátu poslat tuple nebo dict a ten si pošleš do funkce kdoví odkud. A ten test prostě budeš muset dělat pro všechna možná volání té vnitřní funkce, kde se daný formát řetězce provádí a doufat, že jsi na nic nezapomněl. A kvůli hloupému formátování řetězce, který se třeba zapisuje někam do logu, kam prakticky nikdy nikdo nekouká, spadne celá aplikace nebo neošetříš jeden request a je průšvih. S makrem nic takového nehrozí, tam víš, na čem jsi.
Název: Re:Co si myslíte o OOP?
Přispěvatel: listoper 20. 01. 2019, 16:39:13
...
Podobne v clojure, coz je lisp family ale mota tam infix notaci kvuli citelnosti. Clojure vypada vic jako cisty lisp. U elixiru musi clovek vic zamhourit oci aby to videl.
....

Muzes ukazat priklad infix notace v clojure?
Název: Re:Co si myslíte o OOP?
Přispěvatel: Kit 20. 01. 2019, 16:41:24
Uniklo Ti to, co jsem psal. Když napíšu málo parametrů pro formát v Pythonu, v runtime mi to hodí výjimku. Překladač Rustu odmítne chybné parametry makra při překladu.
Však to v Pythonu odchytí testy, ne?
Ano, na každém jednotlivém místě, kde potenciálně zavoláš danou funkci, to musíš pokrýt testem. Při použití makra ne. A je to horší, v Pythonu můžeš do formátu poslat tuple nebo dict a ten si pošleš do funkce kdoví odkud. A ten test prostě budeš muset dělat pro všechna možná volání té vnitřní funkce, kde se daný formát řetězce provádí a doufat, že jsi na nic nezapomněl. A kvůli hloupému formátování řetězce, který se třeba zapisuje někam do logu, kam prakticky nikdy nikdo nekouká, spadne celá aplikace nebo neošetříš jeden request a je průšvih. S makrem nic takového nehrozí, tam víš, na čem jsi.

Nerozumím. Proč by ta aplikace měla spadnout, když zavolám nějakou funkci či metodu s chybným prametrem?
Název: Re:Co si myslíte o OOP?
Přispěvatel: Kadet 20. 01. 2019, 16:52:32
...
Podobne v clojure, coz je lisp family ale mota tam infix notaci kvuli citelnosti. Clojure vypada vic jako cisty lisp. U elixiru musi clovek vic zamhourit oci aby to videl.
....

Muzes ukazat priklad infix notace v clojure?

 (hash-map :key1 1, :key1 2)
Ta carka je infix syntakticky cukr.

{:key1 1, :key1 2}
Dalsi syntakticky cukr je pouziti jinych zavorek.

https://clojuredocs.org/clojure.core/hash-map
Název: Re:Co si myslíte o OOP?
Přispěvatel: Inkvizitor 20. 01. 2019, 17:07:06
Uniklo Ti to, co jsem psal. Když napíšu málo parametrů pro formát v Pythonu, v runtime mi to hodí výjimku. Překladač Rustu odmítne chybné parametry makra při překladu.
Však to v Pythonu odchytí testy, ne?
Ano, na každém jednotlivém místě, kde potenciálně zavoláš danou funkci, to musíš pokrýt testem. Při použití makra ne. A je to horší, v Pythonu můžeš do formátu poslat tuple nebo dict a ten si pošleš do funkce kdoví odkud. A ten test prostě budeš muset dělat pro všechna možná volání té vnitřní funkce, kde se daný formát řetězce provádí a doufat, že jsi na nic nezapomněl. A kvůli hloupému formátování řetězce, který se třeba zapisuje někam do logu, kam prakticky nikdy nikdo nekouká, spadne celá aplikace nebo neošetříš jeden request a je průšvih. S makrem nic takového nehrozí, tam víš, na čem jsi.

Nerozumím. Proč by ta aplikace měla spadnout, když zavolám nějakou funkci či metodu s chybným prametrem?

Asi nerozumíš více věcem, ale to je normální.
Název: Re:Co si myslíte o OOP?
Přispěvatel: listoper 20. 01. 2019, 17:08:03
...
Podobne v clojure, coz je lisp family ale mota tam infix notaci kvuli citelnosti. Clojure vypada vic jako cisty lisp. U elixiru musi clovek vic zamhourit oci aby to videl.
....

Muzes ukazat priklad infix notace v clojure?

 (hash-map :key1 1, :key1 2)
Ta carka je infix syntakticky cukr.

{:key1 1, :key1 2}
Dalsi syntakticky cukr je pouziti jinych zavorek.

https://clojuredocs.org/clojure.core/hash-map

a jo tohle. To sem nikdy nepouzil, protoze to podle me citelnost zhorsuje. Myslel sem, ze mas na mysli neco kde by mel infix operator nejaky vyznam...
Název: Re:Co si myslíte o OOP?
Přispěvatel: operator 20. 01. 2019, 18:45:44
Uniklo Ti to, co jsem psal. Když napíšu málo parametrů pro formát v Pythonu, v runtime mi to hodí výjimku. Překladač Rustu odmítne chybné parametry makra při překladu.
Však to v Pythonu odchytí testy, ne?
Ano, na každém jednotlivém místě, kde potenciálně zavoláš danou funkci, to musíš pokrýt testem. Při použití makra ne. A je to horší, v Pythonu můžeš do formátu poslat tuple nebo dict a ten si pošleš do funkce kdoví odkud. A ten test prostě budeš muset dělat pro všechna možná volání té vnitřní funkce, kde se daný formát řetězce provádí a doufat, že jsi na nic nezapomněl. A kvůli hloupému formátování řetězce, který se třeba zapisuje někam do logu, kam prakticky nikdy nikdo nekouká, spadne celá aplikace nebo neošetříš jeden request a je průšvih. S makrem nic takového nehrozí, tam víš, na čem jsi.

Nerozumím. Proč by ta aplikace měla spadnout, když zavolám nějakou funkci či metodu s chybným prametrem?

Asi nerozumíš více věcem, ale to je normální.
Typický inkvizitorský bullshit. V pythonu bys dnes měl v první řadě používat fstringy a v tu ránu ti zmíněný problém nehrozí. Mimo to, že ti nesedí počet argumentů, ti ošetří lint realtime už při psaní, viz obrázek. Když od někud taháš data, musíš si je validovat v každém jazyce. Statické C ti bez toho s makry i bez nich padá jako zralá hruška. Výjimky jsou tu od toho, abys je ošetřoval a ne proto, abys je ignoroval a nechal na nich spadnout program. A když jsi takový neumětel, že si neošetřuješ IO operace, nic jiného si ani nezasloužíš a to v libovolnám jazyce.

(https://i.ibb.co/VHWhpvd/Screenshot-20190120-182324.jpg) (https://ibb.co/k3gr6hp)
Název: Re:Co si myslíte o OOP?
Přispěvatel: petersonoop 20. 01. 2019, 19:47:11
Clovek zalozi temu a ty par kokotov sa nachyta a honia si tu ego. Mali ste ist radsej kopat jamy curaci, lebo vy nemozte robit programatorov za tych XYtisic kc.
Název: Re:Co si myslíte o OOP?
Přispěvatel: Kit 20. 01. 2019, 20:01:23
Uniklo Ti to, co jsem psal. Když napíšu málo parametrů pro formát v Pythonu, v runtime mi to hodí výjimku. Překladač Rustu odmítne chybné parametry makra při překladu.
Však to v Pythonu odchytí testy, ne?
Ano, na každém jednotlivém místě, kde potenciálně zavoláš danou funkci, to musíš pokrýt testem. Při použití makra ne. A je to horší, v Pythonu můžeš do formátu poslat tuple nebo dict a ten si pošleš do funkce kdoví odkud. A ten test prostě budeš muset dělat pro všechna možná volání té vnitřní funkce, kde se daný formát řetězce provádí a doufat, že jsi na nic nezapomněl. A kvůli hloupému formátování řetězce, který se třeba zapisuje někam do logu, kam prakticky nikdy nikdo nekouká, spadne celá aplikace nebo neošetříš jeden request a je průšvih. S makrem nic takového nehrozí, tam víš, na čem jsi.
Nerozumím. Proč by ta aplikace měla spadnout, když zavolám nějakou funkci či metodu s chybným prametrem?
Asi nerozumíš více věcem, ale to je normální.

Mohl bys mi prosím odpovědět na položenou otázku?
Citace
Proč by ta aplikace měla spadnout, když zavolám nějakou funkci či metodu s chybným prametrem?

Pokud neznáš odpověď, tak samozřejmě nemusíš a ani se nemusíš zbytečně vykrucovat.
Název: Re:Co si myslíte o OOP?
Přispěvatel: BoneFlute 20. 01. 2019, 22:18:40
Uniklo Ti to, co jsem psal. Když napíšu málo parametrů pro formát v Pythonu, v runtime mi to hodí výjimku. Překladač Rustu odmítne chybné parametry makra při překladu.
Však to v Pythonu odchytí testy, ne?
Ano, na každém jednotlivém místě, kde potenciálně zavoláš danou funkci, to musíš pokrýt testem. Při použití makra ne. A je to horší, v Pythonu můžeš do formátu poslat tuple nebo dict a ten si pošleš do funkce kdoví odkud. A ten test prostě budeš muset dělat pro všechna možná volání té vnitřní funkce, kde se daný formát řetězce provádí a doufat, že jsi na nic nezapomněl. A kvůli hloupému formátování řetězce, který se třeba zapisuje někam do logu, kam prakticky nikdy nikdo nekouká, spadne celá aplikace nebo neošetříš jeden request a je průšvih. S makrem nic takového nehrozí, tam víš, na čem jsi.
Nerozumím. Proč by ta aplikace měla spadnout, když zavolám nějakou funkci či metodu s chybným prametrem?
Asi nerozumíš více věcem, ale to je normální.

Mohl bys mi prosím odpovědět na položenou otázku?
Citace
Proč by ta aplikace měla spadnout, když zavolám nějakou funkci či metodu s chybným prametrem?

Pokud neznáš odpověď, tak samozřejmě nemusíš a ani se nemusíš zbytečně vykrucovat.

Ano. Taky se hlásím. Taky nerozumím, proč by zavolání nějaké funkce či metody s chybným prametrem nemělo spadnout.
Název: Re:Co si myslíte o OOP?
Přispěvatel: Honza 20. 01. 2019, 22:40:10
Proč by aplikace musela rovnou celá spadnout? Proč by se nemohlo provádění dané operace zastavit, odeslat programátorovi (třeba e-mailem) serializovaný stack, který si programátor otevře, zobrazí mu to debugger v daném místě, s příslušnými parametry dané metody, zjistí, kde se stala chyba, kterou opraví, aplikaci aktualizuje, a ta může dál v běhu pokračovat tam, kde se zastavila?!
Název: Re:Co si myslíte o OOP?
Přispěvatel: Inkvizitor 20. 01. 2019, 22:46:44
Proč by aplikace musela rovnou celá spadnout? Proč by se nemohlo provádění dané operace zastavit, odeslat programátorovi (třeba e-mailem) serializovaný stack, který si programátor otevře, zobrazí mu to debugger v daném místě, s příslušnými parametry dané metody, zjistí, kde se stala chyba, kterou opraví, aplikaci aktualizuje, a ta může dál v běhu pokračovat tam, kde se zastavila?!

Třeba proto, že než programátor dostane mail, aktualizuje aplikaci apod., request už dávno vyexpiroval a provozovatel přišel o kšeft. Ale asi žijeme každý v jiném světě a Ty s Kitem si pozastavíte realitu, opravíte aplikaci a ona pojede dál, kde skončila a to zcela bez následku.
Název: Re:Co si myslíte o OOP?
Přispěvatel: Kit 20. 01. 2019, 22:59:50
Proč by aplikace musela rovnou celá spadnout? Proč by se nemohlo provádění dané operace zastavit, odeslat programátorovi (třeba e-mailem) serializovaný stack, který si programátor otevře, zobrazí mu to debugger v daném místě, s příslušnými parametry dané metody, zjistí, kde se stala chyba, kterou opraví, aplikaci aktualizuje, a ta může dál v běhu pokračovat tam, kde se zastavila?!
Třeba proto, že než programátor dostane mail, aktualizuje aplikaci apod., request už dávno vyexpiroval a provozovatel přišel o kšeft. Ale asi žijeme každý v jiném světě a Ty s Kitem si pozastavíte realitu, opravíte aplikaci a ona pojede dál, kde skončila a to zcela bez následku.

Program kvůli takové prkotině nezastavuji. Zaloguje chybu, zotaví se a jede dál. Standardní postup.
Název: Re:Co si myslíte o OOP?
Přispěvatel: BoneFlute 20. 01. 2019, 23:38:13
Proč by aplikace musela rovnou celá spadnout? Proč by se nemohlo provádění dané operace zastavit, odeslat programátorovi (třeba e-mailem) serializovaný stack, který si programátor otevře, zobrazí mu to debugger v daném místě, s příslušnými parametry dané metody, zjistí, kde se stala chyba, kterou opraví, aplikaci aktualizuje, a ta může dál v běhu pokračovat tam, kde se zastavila?!

Protože pád aplikace je furt ještě lepší výsledek než poškození dat. Chyba programátora může být prkotina (argument navíc), ale také může být zásadní. A to nejde rozhodnout.

Proto je obecně lepší všechny tyhle scénáře nechat vychytat už dlouho před tím, než se kód vůbec dostane na produkci (dost na tom, že i tak nejdou udělat všechny).
Název: Re:Co si myslíte o OOP?
Přispěvatel: Kit 20. 01. 2019, 23:53:08
Proč by aplikace musela rovnou celá spadnout? Proč by se nemohlo provádění dané operace zastavit, odeslat programátorovi (třeba e-mailem) serializovaný stack, který si programátor otevře, zobrazí mu to debugger v daném místě, s příslušnými parametry dané metody, zjistí, kde se stala chyba, kterou opraví, aplikaci aktualizuje, a ta může dál v běhu pokračovat tam, kde se zastavila?!
Protože pád aplikace je furt ještě lepší výsledek než poškození dat. Chyba programátora může být prkotina (argument navíc), ale také může být zásadní. A to nejde rozhodnout.

Proto je obecně lepší všechny tyhle scénáře nechat vychytat už dlouho před tím, než se kód vůbec dostane na produkci (dost na tom, že i tak nejdou udělat všechny).

Aha, takže když uživatel místo int vloží text, tak necháš aplikaci slítnout? Hmm, to asi bude hodně stabilní.
Název: Re:Co si myslíte o OOP?
Přispěvatel: operator 21. 01. 2019, 05:30:11
Proč by aplikace musela rovnou celá spadnout? Proč by se nemohlo provádění dané operace zastavit, odeslat programátorovi (třeba e-mailem) serializovaný stack, který si programátor otevře, zobrazí mu to debugger v daném místě, s příslušnými parametry dané metody, zjistí, kde se stala chyba, kterou opraví, aplikaci aktualizuje, a ta může dál v běhu pokračovat tam, kde se zastavila?!

Protože pád aplikace je furt ještě lepší výsledek než poškození dat. Chyba programátora může být prkotina (argument navíc), ale také může být zásadní. A to nejde rozhodnout.

Proto je obecně lepší všechny tyhle scénáře nechat vychytat už dlouho před tím, než se kód vůbec dostane na produkci (dost na tom, že i tak nejdou udělat všechny).
Jde to rozhodnout. Už v zadání bylo řečeno, že jde o nedůležitou funkci. Takže příslušnou operace můžeš nechat v klidu selhat, selhání zaznamenat a program může pokračovat dál.
Název: Re:Co si myslíte o OOP?
Přispěvatel: v 21. 01. 2019, 09:04:16
Proč by aplikace musela rovnou celá spadnout? Proč by se nemohlo provádění dané operace zastavit, odeslat programátorovi (třeba e-mailem) serializovaný stack, který si programátor otevře, zobrazí mu to debugger v daném místě, s příslušnými parametry dané metody, zjistí, kde se stala chyba, kterou opraví, aplikaci aktualizuje, a ta může dál v běhu pokračovat tam, kde se zastavila?!

Protože pád aplikace je furt ještě lepší výsledek než poškození dat. Chyba programátora může být prkotina (argument navíc), ale také může být zásadní. A to nejde rozhodnout.

Proto je obecně lepší všechny tyhle scénáře nechat vychytat už dlouho před tím, než se kód vůbec dostane na produkci (dost na tom, že i tak nejdou udělat všechny).
Jde to rozhodnout. Už v zadání bylo řečeno, že jde o nedůležitou funkci. Takže příslušnou operace můžeš nechat v klidu selhat, selhání zaznamenat a program může pokračovat dál.
selhání nedůležié funkce je pro mě třeba selhání zobrazení notifikace na desktopu (tj. IO operace mimo kontrolu programátora), volání funkce s nesprávným počtem argumentů je docela hrozivá logická chyba
Název: Re:Co si myslíte o OOP?
Přispěvatel: Inkvizitor 21. 01. 2019, 09:30:24
Aha, takže když uživatel místo int vloží text, tak necháš aplikaci slítnout? Hmm, to asi bude hodně stabilní.

Kite, Kite. Bavime se o chybach, ktere zpusobil programator, v tomto pripade dokonce o chybe, ktera by se dala odchytit pri prekladu, kdyby dany jazyk rozumne podporoval makra. Pokud nekdo nema validaci vstupu a necha probublat z formulare nenumericky vstup tam, kde je pozadovano cislo, ma mnohem vetsi problem, nez ze mu to shodilo aplikaci.

A ano, mas pravdu, ze v dnesnich interaktivnich systemech fakt runtime chyba obycejne nevede k ukonceni cele aplikace. Jenze problem, o kterem jsem puvodne psal, je v tom, ze (zase se opakuju) dnesni jazyky uz umeji nektere tridy chyb proste eliminovat. Ty ostatni se budto prizpusobi nebo budou v nekterych oblastech po pravu vytlaceny.
Název: Re:Co si myslíte o OOP?
Přispěvatel: gll 21. 01. 2019, 09:55:46
Linter může kotrolovat jenom to, čemu rozumí. Makro si můžu napsat vlastní a mám to i s tou kontrolou, nejde jenom o standardní knihovnu.  Mimochodem právě na Pylintu je vidět, jak se vyplatí psát všechno "hloupě" jako ve statických jazycích, jinak přestane chápat, co se kam může posílat a kde se bere jaká hodnota a už nám s kontrolou nepomůže.

kolik jsi takových maker validujících mikrojazyk napsal? Podle mě to není častý problém a lépe ho vyřeší plugin do linteru.
Název: Re:Co si myslíte o OOP?
Přispěvatel: Inkvizitor 21. 01. 2019, 10:14:11
Linter může kotrolovat jenom to, čemu rozumí. Makro si můžu napsat vlastní a mám to i s tou kontrolou, nejde jenom o standardní knihovnu.  Mimochodem právě na Pylintu je vidět, jak se vyplatí psát všechno "hloupě" jako ve statických jazycích, jinak přestane chápat, co se kam může posílat a kde se bere jaká hodnota a už nám s kontrolou nepomůže.

kolik jsi takových maker validujících mikrojazyk napsal? Podle mě to není častý problém a lépe ho vyřeší plugin do linteru.

No promin, ale jak mam na tohle reagovat? Plugin do linteru ten problem samozrejme nevyresi lepe, je to reseni ad hoc a je to reseni z principu mene spolehlive, nez first-class podpora ve standardnich nastrojich jazyka. Kolik jsem dosud napsal podobnych maker ja (0, kdyz to chces slyset), je z tohoto pohledu vedlejsi.
Název: Re:Co si myslíte o OOP?
Přispěvatel: Kit 21. 01. 2019, 10:29:44
Aha, takže když uživatel místo int vloží text, tak necháš aplikaci slítnout? Hmm, to asi bude hodně stabilní.
Kite, Kite. Bavime se o chybach, ktere zpusobil programator, v tomto pripade dokonce o chybe, ktera by se dala odchytit pri prekladu, kdyby dany jazyk rozumne podporoval makra. Pokud nekdo nema validaci vstupu a necha probublat z formulare nenumericky vstup tam, kde je pozadovano cislo, ma mnohem vetsi problem, nez ze mu to shodilo aplikaci.

Jak víš, že tu chybu způsobil programátor, když se objektové aplikace sestavují až za běhu? Úplně stejná situace nastane, pokud uživatel otevře třeba XML s jinou strukturou. To při překladu neodchytíš. Validaci vstupu dělám až v objektu, který ten vstup má za úkol zpracovat, protože každý objekt si musí umět uhlídat vstupy. Jak bys chtěl při překladu odchytit chybu, když omylem při volání metody přehodíš dva parametry stejného typu?

Kromě toho vložit string nebo tuples do takové metody nemusí být chybou.

A ano, mas pravdu, ze v dnesnich interaktivnich systemech fakt runtime chyba obycejne nevede k ukonceni cele aplikace. Jenze problem, o kterem jsem puvodne psal, je v tom, ze (zase se opakuju) dnesni jazyky uz umeji nektere tridy chyb proste eliminovat. Ty ostatni se budto prizpusobi nebo budou v nekterych oblastech po pravu vytlaceny.

Nebudou vytlačeny. Při překladu stačí kontrola syntaxe. Zbytek je jen nadstavbou, která může být užitečná, ale není nezbytná.
Název: Re:Co si myslíte o OOP?
Přispěvatel: Inkvizitor 21. 01. 2019, 11:01:16
Jak víš, že tu chybu způsobil programátor, když se objektové aplikace sestavují až za běhu? Úplně stejná situace nastane, pokud uživatel otevře třeba XML s jinou strukturou. To při překladu neodchytíš. Validaci vstupu dělám až v objektu, který ten vstup má za úkol zpracovat, protože každý objekt si musí umět uhlídat vstupy. Jak bys chtěl při překladu odchytit chybu, když omylem při volání metody přehodíš dva parametry stejného typu?

Tezko bych hledal lepsi argument proti pouzivani OOP, dekuju. Co se tyce dvou parametru stejneho typu, krome specifickych pripadu (treba min a max) je mozne prohozeni dvou parametru vyresit prave tim, ze se bude pracovat s presnejsimi typy (enum namisto ciselnych konstant atd.). A jasne, logicke chyby typovy system resit neumi.
Název: Re:Co si myslíte o OOP?
Přispěvatel: v 21. 01. 2019, 11:13:10
...logicke chyby typovy system resit neumi.
je to docela dobrý nástroj k jejich prevenci, už prostý newtype (typedef struct v Cčku :D) dost pomůže nebo takové "units of measure" v F#
Název: Re:Co si myslíte o OOP?
Přispěvatel: gll 21. 01. 2019, 12:23:55
Plugin do linteru ten problem samozrejme nevyresi lepe, je to reseni ad hoc a je to reseni z principu mene spolehlive, nez first-class podpora ve standardnich nastrojich jazyka.

Je to univerzálnější. Statická kontrola v případech s konstantním formátovacím řetězcem funguje stejně jako v Rustu. Narozdíl od Rustu funguje i kontrola v čase běhu.
Název: Re:Co si myslíte o OOP?
Přispěvatel: Inkvizitor 21. 01. 2019, 12:42:22
Plugin do linteru ten problem samozrejme nevyresi lepe, je to reseni ad hoc a je to reseni z principu mene spolehlive, nez first-class podpora ve standardnich nastrojich jazyka.

Je to univerzálnější. Statická kontrola v případech s konstantním formátovacím řetězcem funguje stejně jako v Rustu. Narozdíl od Rustu funguje i kontrola v čase běhu.

Na rozdil od Pythonu Rust zadnou podobnou kontrolu v case behu nepotrebuje. A asi rozumime slovu "univerzalni" kazdy jinak, kdyz musis pro kazdou podobnou vec psat novy plugin do linteru.
Název: Re:Co si myslíte o OOP?
Přispěvatel: Kit 21. 01. 2019, 12:44:35
Jak víš, že tu chybu způsobil programátor, když se objektové aplikace sestavují až za běhu? Úplně stejná situace nastane, pokud uživatel otevře třeba XML s jinou strukturou. To při překladu neodchytíš. Validaci vstupu dělám až v objektu, který ten vstup má za úkol zpracovat, protože každý objekt si musí umět uhlídat vstupy. Jak bys chtěl při překladu odchytit chybu, když omylem při volání metody přehodíš dva parametry stejného typu?
Tezko bych hledal lepsi argument proti pouzivani OOP, dekuju. Co se tyce dvou parametru stejneho typu, krome specifickych pripadu (treba min a max) je mozne prohozeni dvou parametru vyresit prave tim, ze se bude pracovat s presnejsimi typy (enum namisto ciselnych konstant atd.). A jasne, logicke chyby typovy system resit neumi.

Nikdo tě nenutí OOP používat. Volné vazby mezi objekty nejsou pro každého.

Číselné konstanty ještě někdo používá? Měl jsem na mysli například výšku a hmotnost. Obojí jsou reálná čísla, ale když je přehodíš, dostaneš nesmysly. Ano, můžeš si udělat typy Výška a Hmotnost. Děláš to?
Název: Re:Co si myslíte o OOP?
Přispěvatel: Kit 21. 01. 2019, 12:51:44
Na rozdil od Pythonu Rust zadnou podobnou kontrolu v case behu nepotrebuje. A asi rozumime slovu "univerzalni" kazdy jinak, kdyz musis pro kazdou podobnou vec psat novy plugin do linteru.

Kontrolu typu dat potřebuješ v obou případech. V Pythonu ji uděláš až v místě, kde ta data zpracováváš, tedy v objektu. V Rustu si je kontroluješ ještě před vstupem do modulu, aby ti tam vstoupila pouze čistá data. Spor je tedy jen v tom, kdy a kde tu kontrolu uděláš - uvnitř či venku.
Název: Re:Co si myslíte o OOP?
Přispěvatel: BoneFlute 21. 01. 2019, 14:29:25
Spor je tedy jen v tom, kdy a kde tu kontrolu uděláš - uvnitř či venku.
Ne, to ani náhodou. Spor je o to, zda data kontrolovat včas, nebo pozdě.
Název: Re:Co si myslíte o OOP?
Přispěvatel: Kit 21. 01. 2019, 14:37:25
Spor je tedy jen v tom, kdy a kde tu kontrolu uděláš - uvnitř či venku.
Ne, to ani náhodou. Spor je o to, zda data kontrolovat včas, nebo pozdě.

Objektový přístup spočívá v tom, že data kontroluješ co možná nejpozději.
Název: Re:Co si myslíte o OOP?
Přispěvatel: BoneFlute 21. 01. 2019, 14:39:52
Objektový přístup spočívá v tom, že data kontroluješ co možná nejpozději.

To je tvá představa o Objektovém přístupu. Doufám, že není moc rozšířená.
Název: Re:Co si myslíte o OOP?
Přispěvatel: operator 21. 01. 2019, 14:48:08
Spor je tedy jen v tom, kdy a kde tu kontrolu uděláš - uvnitř či venku.
Ne, to ani náhodou. Spor je o to, zda data kontrolovat včas, nebo pozdě.
Cele je to o tom, ze tu je sorta lidi, kteri si mysli, ze staticke typy jim odladi system. Coz je blbost nad entou. Viz C, ktere lehce umozni prekladat padajic programy a naopak jsou ty typy zdrojem mnohych chyb. Pak tu jsou jazyky s pokrocilejsim typovym systemem. Pokrocilejsi = slozitejsi. Tyto sice umozni eliminovat nektere chyby typické pro C, ale a) ty se v dynamickem jazyce nevyskytuji b) je tu kardinalni otazka, kdo odladi chyby v pouziti typoveho systemu?  A na to mame univerzalni odpoved, testy. Staticke typy vec zbytecne komplikuji a ve vysledku nic neresi. S vyjimkou vykonu.
Název: Re:Co si myslíte o OOP?
Přispěvatel: BoneFlute 21. 01. 2019, 14:50:58
Cele je to o tom, ze tu je sorta lidi, kteri si mysli, ze staticke typy jim odladi system. Coz je blbost nad entou. Viz C, ktere lehce umozni prekladat padajic programy a naopak jsou ty typy zdrojem mnohych chyb. Pak tu jsou jazyky s pokrocilejsim typovym systemem. Pokrocilejsi = slozitejsi. Tyto sice umozni eliminovat nektere chyby typické pro C, ale a) ty se v dynamickem jazyce nevyskytuji b) je tu kardinalni otazka, kdo odladi chyby v pouziti typoveho systemu?  A na to mame univerzalni odpoved, testy. Staticke typy vec zbytecne komplikuji a ve vysledku nic neresi. S vyjimkou vykonu.
Tak to určitě.
Název: Re:Co si myslíte o OOP?
Přispěvatel: Ondra Satai Nekola 21. 01. 2019, 14:51:42
Spor je tedy jen v tom, kdy a kde tu kontrolu uděláš - uvnitř či venku.
Ne, to ani náhodou. Spor je o to, zda data kontrolovat včas, nebo pozdě.
Cele je to o tom, ze tu je sorta lidi, kteri si mysli, ze staticke typy jim odladi system. Coz je blbost nad entou.

A proc je to blbost na entou? Protoze je to straw man.
Název: Re:Co si myslíte o OOP?
Přispěvatel: operator 21. 01. 2019, 14:52:18
Spor je tedy jen v tom, kdy a kde tu kontrolu uděláš - uvnitř či venku.
Ne, to ani náhodou. Spor je o to, zda data kontrolovat včas, nebo pozdě.
Objektový přístup spočívá v tom, že data kontroluješ co možná nejpozději.
To je spis dynamicky pristup a nerekl bych co nejpozdeji, ale na nejvhodnsim miste. Je to vice flexibilni, ale prave toho se nejvíc boji ti, co s tim neumi pracovat.
Název: Re:Co si myslíte o OOP?
Přispěvatel: Inkvizitor 21. 01. 2019, 14:56:21
A proc je to blbost na entou? Protoze je to straw man.

Blbost na ntou je predevsim porad dokola operovat Ceckem. S Operatorem nema smysl diskutovat, vykasli se na to.
Název: Re:Co si myslíte o OOP?
Přispěvatel: operator 21. 01. 2019, 14:56:42
Spor je tedy jen v tom, kdy a kde tu kontrolu uděláš - uvnitř či venku.
Ne, to ani náhodou. Spor je o to, zda data kontrolovat včas, nebo pozdě.
Cele je to o tom, ze tu je sorta lidi, kteri si mysli, ze staticke typy jim odladi system. Coz je blbost nad entou.
A proc je to blbost na entou? Protoze je to straw man.
To neni straw man, to je reakce na tvrzeni, kdyz se to podari zkompilovat, je to v podstate hotovo.
Název: Re:Co si myslíte o OOP?
Přispěvatel: BoneFlute 21. 01. 2019, 15:00:05
Spor je tedy jen v tom, kdy a kde tu kontrolu uděláš - uvnitř či venku.
Ne, to ani náhodou. Spor je o to, zda data kontrolovat včas, nebo pozdě.
Cele je to o tom, ze tu je sorta lidi, kteri si mysli, ze staticke typy jim odladi system. Coz je blbost nad entou.
A proc je to blbost na entou? Protoze je to straw man.
To neni straw man, to je reakce na tvrzeni, kdyz se to podari zkompilovat, je to v podstate hotovo.

Což je souvislost vysloveně evidentní. A výraz "v podstatě" jsi taky úmyslně vynechal.

Vskutku, tvé příspěvky nejsou v ničem přínosné.
Název: Re:Co si myslíte o OOP?
Přispěvatel: operator 21. 01. 2019, 15:05:38
A proc je to blbost na entou? Protoze je to straw man.
Blbost na ntou je predevsim porad dokola operovat Ceckem. S Operatorem nema smysl diskutovat, vykasli se na to.
To neni blbost, je to jazyk se statickymi typy. Kdyz je rec obecne o statickych typech a jejich vlastnostech, musis vzit v potaz i tento jazyk. Mozna ze potom i pochopis, ze vlastnosti, ktere prisuzujes statickym typum, nejsou ve skutecnosti vlastnosti statickych typu.
Název: Re:Co si myslíte o OOP?
Přispěvatel: A. F. 21. 01. 2019, 15:18:49
Pozoruji zde určitě vzory:
a) přispěvatelé, kteří něčemu rozumí, a něco nového se snaží dozvědět
b) přispěvatelé, kteří něčemu rozumí, a nic nového je nezajímá
c) přispěvatelé, kteří ničemu nerozumí, nic nového je nezajímá
Název: Re:Co si myslíte o OOP?
Přispěvatel: operator 21. 01. 2019, 15:46:37
Spor je tedy jen v tom, kdy a kde tu kontrolu uděláš - uvnitř či venku.
Ne, to ani náhodou. Spor je o to, zda data kontrolovat včas, nebo pozdě.
Cele je to o tom, ze tu je sorta lidi, kteri si mysli, ze staticke typy jim odladi system. Coz je blbost nad entou.
A proc je to blbost na entou? Protoze je to straw man.
To neni straw man, to je reakce na tvrzeni, kdyz se to podari zkompilovat, je to v podstate hotovo.
Což je souvislost vysloveně evidentní. A výraz "v podstatě" jsi taky úmyslně vynechal.
Vskutku, tvé příspěvky nejsou v ničem přínosné.
Ano, souvislost je evidentní, protože to bylo tvrzení ke statickým typům. A žádný z obhájců statických typů to ani nezpochybnil, takže se dá předpokládat, že to je názor přijímaný většinou.
Název: Re:Co si myslíte o OOP?
Přispěvatel: v 21. 01. 2019, 16:18:59
Spor je tedy jen v tom, kdy a kde tu kontrolu uděláš - uvnitř či venku.
Ne, to ani náhodou. Spor je o to, zda data kontrolovat včas, nebo pozdě.
Cele je to o tom, ze tu je sorta lidi, kteri si mysli, ze staticke typy jim odladi system. Coz je blbost nad entou.
A proc je to blbost na entou? Protoze je to straw man.
To neni straw man, to je reakce na tvrzeni, kdyz se to podari zkompilovat, je to v podstate hotovo.
Což je souvislost vysloveně evidentní. A výraz "v podstatě" jsi taky úmyslně vynechal.
Vskutku, tvé příspěvky nejsou v ničem přínosné.
Ano, souvislost je evidentní, protože to bylo tvrzení ke statickým typům. A žádný z obhájců statických typů to ani nezpochybnil, takže se dá předpokládat, že to je názor přijímaný většinou.
již před válkou jsem poukazoval na to, že část lidí tu debatuje o pascalu (nebo i C ...) a část o teorii typů (haskell apod.)
Název: Re:Co si myslíte o OOP?
Přispěvatel: operator 21. 01. 2019, 16:25:19
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?
Je to pouzitelne. Pouzivam to bezne pri vyvoji webu. Main aplikace porovnava cas py a pyc souboru a kdyz je py novejsi, tak modul, typicky nejaky handler requestu, automaticky reloadne. Nemusim kvuli tomu restartovat celou aplikaci.
Název: Re:Co si myslíte o OOP?
Přispěvatel: Dor 21. 01. 2019, 16:28:43
již před válkou jsem poukazoval na to, že část lidí tu debatuje o pascalu (nebo i C ...) a část o teorii typů (haskell apod.)
Tak tak. Těšil jsem se na debaty o polymorfismu a zapouzdřování, které by mohly vyústit v debaty o OO návrhu. Tešil jsem se jak tady budou lítat pojmy jako factory design pattern, dependency injection. Těšil jsem se na poučky o SRP a vůbec o celém SOLID. A místo toho se tu řeší datové typy. :(
Název: Re:Co si myslíte o OOP?
Přispěvatel: operator 21. 01. 2019, 16:33:53
Spor je tedy jen v tom, kdy a kde tu kontrolu uděláš - uvnitř či venku.
Ne, to ani náhodou. Spor je o to, zda data kontrolovat včas, nebo pozdě.
Cele je to o tom, ze tu je sorta lidi, kteri si mysli, ze staticke typy jim odladi system. Coz je blbost nad entou.
A proc je to blbost na entou? Protoze je to straw man.
To neni straw man, to je reakce na tvrzeni, kdyz se to podari zkompilovat, je to v podstate hotovo.
Což je souvislost vysloveně evidentní. A výraz "v podstatě" jsi taky úmyslně vynechal.
Vskutku, tvé příspěvky nejsou v ničem přínosné.
Ano, souvislost je evidentní, protože to bylo tvrzení ke statickým typům. A žádný z obhájců statických typů to ani nezpochybnil, takže se dá předpokládat, že to je názor přijímaný většinou.
již před válkou jsem poukazoval na to, že část lidí tu debatuje o pascalu (nebo i C ...) a část o teorii typů (haskell apod.)
No a to je prave ten problem. Staticky typ je staticky typ v kazdem z techto jazyku. A pokud to neni upresneno, nelze ignorovat mainstramove jazyky se statickymi typy, tedy C, C++, Java a C#. Pokud tvrzeni neplati pro tyto jazyky, neni to tvrzeni platne pro staticke typy jako takove. A pokud to nekdo upresni, ze to plati pro statickevtypy v haskellu, tak fajn, ale je tonpak vlastnost haskellu a jeho typoveho systemu, nikoliv statickych typu. Myslim ze jsem tu presvedcive dokazal, ze vetsinu veci, prisuzovanych statickym typum, lze dosahnout i jinak, bez statatickych typu.
Název: Re:Co si myslíte o OOP?
Přispěvatel: v 21. 01. 2019, 16:40:06
již před válkou jsem poukazoval na to, že část lidí tu debatuje o pascalu (nebo i C ...) a část o teorii typů (haskell apod.)
Tak tak. Těšil jsem se na debaty o polymorfismu a zapouzdřování, které by mohly vyústit v debaty o OO návrhu. Tešil jsem se jak tady budou lítat pojmy jako factory design pattern, dependency injection. Těšil jsem se na poučky o SRP a vůbec o celém SOLID.
v tématu, které začíná slovy  "Je potreba to (OOP) vsade pretlacat?"?
Název: Re:Co si myslíte o OOP?
Přispěvatel: Kotel hoven 21. 01. 2019, 16:53:28
Hm tohle vlakno aspiruje na nejvetsi humus vlakno na rootu - blahopreju vsem kteri ste si tu vyblili mozem - specialni diky agresivnimu predatorovi alfa-dementu kitovi, bez nej by to nebylo ono
Název: Re:Co si myslíte o OOP?
Přispěvatel: BoneFlute 21. 01. 2019, 16:55:37
již před válkou jsem poukazoval na to, že část lidí tu debatuje o pascalu (nebo i C ...) a část o teorii typů (haskell apod.)
No a to je prave ten problem. Staticky typ je staticky typ v kazdem z techto jazyku. A pokud to neni upresneno, nelze ignorovat mainstramove jazyky se statickymi typy, tedy C, C++, Java a C#.

Ne. Problém je v tom, že C a Pascal z pohledu typů dneska už nikoho nezajímají. Takže snaha používat to jako argument je buď snaha o matení, nebo neznalost. Vyber si.
Název: Re:Co si myslíte o OOP?
Přispěvatel: Kit 21. 01. 2019, 16:58:26
již před válkou jsem poukazoval na to, že část lidí tu debatuje o pascalu (nebo i C ...) a část o teorii typů (haskell apod.)
Tak tak. Těšil jsem se na debaty o polymorfismu a zapouzdřování, které by mohly vyústit v debaty o OO návrhu. Tešil jsem se jak tady budou lítat pojmy jako factory design pattern, dependency injection. Těšil jsem se na poučky o SRP a vůbec o celém SOLID. A místo toho se tu řeší datové typy. :(

To vše mohlo být, pokud bys místo této sarkastické poznámky přispěl svou troškou do mlýna a položil dotaz, nad kterým by se dalo diskutovat. Funkcionalisté se rádi vecpou i do vlákna s objektovým návrhem. Pokud chceš udržet téma, napiš příspěvek, který se ho bude týkat.
Název: Re:Co si myslíte o OOP?
Přispěvatel: BoneFlute 21. 01. 2019, 17:00:26
Myslim ze jsem tu presvedcive dokazal, ze vetsinu veci, prisuzovanych statickym typum, lze dosahnout i jinak, bez statatickych typu.

Myslím si, že pokud člověk tématu nerozumí, měl by k příspěvkům přistupovat velmi, velmi opatrně.
Název: Re:Co si myslíte o OOP?
Přispěvatel: operator 21. 01. 2019, 17:01:14
Ja vedel ze to najdu, zajimalo me, kdo s touto vtipnou tezi prisel. A citoval jsem spatne, nebylo to v podstate, ale obecne.

... největší rozdíl vidím v dokumentaci.
Mě teda oslovilo compile time. Když konečně přesvědčím kompilátor, aby to přeložil, tak mám obecně hotovo. Zbejvaj sémantické chyby. Zatímco u dynamického jazyka furt něco padá.
Název: Re:Co si myslíte o OOP?
Přispěvatel: Kit 21. 01. 2019, 17:03:28
již před válkou jsem poukazoval na to, že část lidí tu debatuje o pascalu (nebo i C ...) a část o teorii typů (haskell apod.)
No a to je prave ten problem. Staticky typ je staticky typ v kazdem z techto jazyku. A pokud to neni upresneno, nelze ignorovat mainstramove jazyky se statickymi typy, tedy C, C++, Java a C#.
Ne. Problém je v tom, že C a Pascal z pohledu typů dneska už nikoho nezajímají. Takže snaha používat to jako argument je buď snaha o matení, nebo neznalost. Vyber si.

Máš snad něco proti typům v Pascalu? Co třeba typy ve Fortranu? Lepší?
Název: Re:Co si myslíte o OOP?
Přispěvatel: v 21. 01. 2019, 17:04:13
Myslim ze jsem tu presvedcive dokazal, ze vetsinu veci, prisuzovanych statickym typum, lze dosahnout i jinak, bez statatickych typu.
IMHO ne
Název: Re:Co si myslíte o OOP?
Přispěvatel: Kadet 21. 01. 2019, 17:04:44
již před válkou jsem poukazoval na to, že část lidí tu debatuje o pascalu (nebo i C ...) a část o teorii typů (haskell apod.)
Tak tak. Těšil jsem se na debaty o polymorfismu a zapouzdřování, které by mohly vyústit v debaty o OO návrhu. Tešil jsem se jak tady budou lítat pojmy jako factory design pattern, dependency injection. Těšil jsem se na poučky o SRP a vůbec o celém SOLID. A místo toho se tu řeší datové typy. :(

To by mohla byt pekna debata.

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

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

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

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

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

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

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

Ocekavam konstruktivni debatu. Trolly ignoruju.
Název: Re:Co si myslíte o OOP?
Přispěvatel: Dor 21. 01. 2019, 17:04:50
již před válkou jsem poukazoval na to, že část lidí tu debatuje o pascalu (nebo i C ...) a část o teorii typů (haskell apod.)
Tak tak. Těšil jsem se na debaty o polymorfismu a zapouzdřování, které by mohly vyústit v debaty o OO návrhu. Tešil jsem se jak tady budou lítat pojmy jako factory design pattern, dependency injection. Těšil jsem se na poučky o SRP a vůbec o celém SOLID.
v tématu, které začíná slovy  "Je potreba to (OOP) vsade pretlacat?"?
Celé tohle vlákno mi připomnělo vyprávění mého učitele angličtiny (rodilý mluvčí s pedagogickým vzděláním), jak se s ním jeden jeho žák (taky programátor) hádal o gramatice. Učitel vůbec nechápal a řečnicky se mě tázal, kde ten člověk bere to sebevědomí. Tak jsem jen pokrčil rameny a řekl: "programmer" :D Obor, kdy si člověk tak 5x až 20x za kariéru řekne: "Před tím jsem nevěděl nic, ale teď už jsem konečně programátor."
Název: Re:Co si myslíte o OOP?
Přispěvatel: operator 21. 01. 2019, 17:05:58
již před válkou jsem poukazoval na to, že část lidí tu debatuje o pascalu (nebo i C ...) a část o teorii typů (haskell apod.)
No a to je prave ten problem. Staticky typ je staticky typ v kazdem z techto jazyku. A pokud to neni upresneno, nelze ignorovat mainstramove jazyky se statickymi typy, tedy C, C++, Java a C#.

Ne. Problém je v tom, že C a Pascal z pohledu typů dneska už nikoho nezajímají. Takže snaha používat to jako argument je buď snaha o matení, nebo neznalost. Vyber si.
Pascal uz asi nikoho nezajima, proto ho ani neuvadim. Jazyk C je ale siroce pouzivany, nenahraditelny a nenahrazeny. Programatori, kteri ho pouzivaji, se o jeho statickemu typovemu systemu nevyhnou. Neni to ani mateni, ani neznalost, ne z me strany.
Název: Re:Co si myslíte o OOP?
Přispěvatel: operator 21. 01. 2019, 17:07:34
Myslim ze jsem tu presvedcive dokazal, ze vetsinu veci, prisuzovanych statickym typum, lze dosahnout i jinak, bez statatickych typu.
IMHO ne
Imho jo, vcetne typove kontroly pred spustenim.
Název: Re:Co si myslíte o OOP?
Přispěvatel: v 21. 01. 2019, 17:08:47
Myslim ze jsem tu presvedcive dokazal, ze vetsinu veci, prisuzovanych statickym typum, lze dosahnout i jinak, bez statatickych typu.
IMHO ne
Imho jo, vcetne typove kontroly pred spustenim.
typová kontrola před spuštěním je statická typová kontrola
Název: Re:Co si myslíte o OOP?
Přispěvatel: operator 21. 01. 2019, 17:10:59
Myslim ze jsem tu presvedcive dokazal, ze vetsinu veci, prisuzovanych statickym typum, lze dosahnout i jinak, bez statatickych typu.
Myslím si, že pokud člověk tématu nerozumí, měl by k příspěvkům přistupovat velmi, velmi opatrně.
Tak se toho drz.
Název: Re:Co si myslíte o OOP?
Přispěvatel: Kit 21. 01. 2019, 17:12:03
Ja vedel ze to najdu, zajimalo me, kdo s touto vtipnou tezi prisel. A citoval jsem spatne, nebylo to v podstate, ale obecne.

... největší rozdíl vidím v dokumentaci.
Mě teda oslovilo compile time. Když konečně přesvědčím kompilátor, aby to přeložil, tak mám obecně hotovo. Zbejvaj sémantické chyby. Zatímco u dynamického jazyka furt něco padá.

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

BoneFlute nám zatím nevysvětlil, co mu v dynamicky typovaných jazycích neustále padá. Zřejmě dělá dobře, že se drží staticky typovaných jazyků.
Název: Re:Co si myslíte o OOP?
Přispěvatel: operator 21. 01. 2019, 17:14:35
Myslim ze jsem tu presvedcive dokazal, ze vetsinu veci, prisuzovanych statickym typum, lze dosahnout i jinak, bez statatickych typu.
IMHO ne
Imho jo, vcetne typove kontroly pred spustenim.
typová kontrola před spuštěním je statická typová kontrola
To nerozporuji, ale nepotrebuji k ni staticke typy.
Název: Re:Co si myslíte o OOP?
Přispěvatel: v 21. 01. 2019, 17:15:17
Ja vedel ze to najdu, zajimalo me, kdo s touto vtipnou tezi prisel. A citoval jsem spatne, nebylo to v podstate, ale obecne.

... největší rozdíl vidím v dokumentaci.
Mě teda oslovilo compile time. Když konečně přesvědčím kompilátor, aby to přeložil, tak mám obecně hotovo. Zbejvaj sémantické chyby. Zatímco u dynamického jazyka furt něco padá.

Tam patřilo spíš "Zatímco u dynamického jazyka mi furt něco padá." Už jsem psal, že dynamické typování není pro každého. Je nutné si nejen držet určitou kázeň, ale i pokrýt jednotku testy.
řekl byste tedy, že programování v dynamických jazycích (python, js) je náročnější než ve statických (haskell, pascal)?
Název: Re:Co si myslíte o OOP?
Přispěvatel: BoneFlute 21. 01. 2019, 17:16:03
Dependency injection znamena 'posli mi objekt jako parametr, at si ho nemusim vytvaret sam'.

Rozlišil bych DI jako princip, který klade důraz na popisnost. Tedy
1/ objekt se veřejně hlásí ke svým závislostem
2/ nic si pokoutně nevytváří, to znamená méně nečekaných side-effektů
3/ IMHO to dost pomáhá tomu, aby se udržoval rozumný počet závislostí. Nevzdory obavám začátečníků, málokdy se stane, že by objekt měl "nepříjemně" mnoho závislostí.
4/ Hodně to pomáhá refactoringu. Vzhledem k tomu, že konstruktor obvykle není součástí žádného rozhraní, tak přidat nebo odebrat nějakou závislost je velice levné (občas to trochu komplikují testy).

Na druhou stranu tu máme DI kontainer, který je zase něco úplně jiného. Ten bejvá naopak plnej magie, ale je to velice pohodlná a návyková záležitost. A krom situace, kdy jsem potřeboval kombinovat dva kontainery dohromady jsem zatím nijak zvlášť nenarazil (zkušenosti v tomto vítány).
Taky mám zkušenost, že DIC v typovaném jazyce je subjektivně příjemnější, než v netypovaném (python, javascript).
Název: Re:Co si myslíte o OOP?
Přispěvatel: v 21. 01. 2019, 17:16:25
typová kontrola před spuštěním je statická typová kontrola
To nerozporuji, ale nepotrebuji k ni staticke typy.
to mi vůbec nedává smysl, asi radší půjdu programovat
Název: Re:Co si myslíte o OOP?
Přispěvatel: operator 21. 01. 2019, 17:18:05
Ja vedel ze to najdu, zajimalo me, kdo s touto vtipnou tezi prisel. A citoval jsem spatne, nebylo to v podstate, ale obecne.

... největší rozdíl vidím v dokumentaci.
Mě teda oslovilo compile time. Když konečně přesvědčím kompilátor, aby to přeložil, tak mám obecně hotovo. Zbejvaj sémantické chyby. Zatímco u dynamického jazyka furt něco padá.

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

BoneFlute nám zatím nevysvětlil, co mu v dynamicky typovaných jazycích neustále padá. Zřejmě dělá dobře, že se drží staticky typovaných jazyků.
A hlavne, i kdyz pada, tak jen na semanticke chyby, a ty BoneFlute obecne nepocita :-).

Tudiz tvrdim, ze je tu sorta lidi verici ve staticke typy a to, ze kdyz se jim podari prelozit kod se statickymi typy, maji obecne hotovo.
Název: Re:Co si myslíte o OOP?
Přispěvatel: Kit 21. 01. 2019, 17:19:57
Popravde benefit pouzivani principu SOLID jsem nikdy moc nepochopi, treba mi to nekdo vysvetli na prikladu. Stejne tak jsem nikdy neprisel na to, proc navrhovat aplikace timto komplexnim zpusobem co pouziva milion hierarchii a rozhrani. Podle me je takovych systemu poskrovnu, napr. operacni system nebo GUI.

SOLID obsahuje návody, jak zjednodušit aplikaci. Pokud ho někdo chybně pochopí, tak si naopak tu aplikaci zkomplikuje.
Název: Re:Co si myslíte o OOP?
Přispěvatel: Kadet 21. 01. 2019, 17:20:46
Staticka kontrola je dobra k tomu, ze overi, ze zadna funkce nedostane argument spatnyho typu. Tj. overi, ze struktura programu je spravne, ale neoveri semantiku, tj. takovy ry pripady kdy muzu ve funkci f(vaha: int, vyska: int) v klidu zamenit oba argumenty a typova kontrola mi to neodhali. To je uz pak o discipline programatora jestli na to pouzije typy nebo si na to napise testy. Kazdopadne staticka typova kontrola neni vselek proti vsem chybam.

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

Samozrejme kdyz nekdo prilis vetvi program (aka praseci kod), bude mit hodne prace s psanim testu nebo muze rovnou pouzit statickou kontrolu. Opet, vyresi to jenom strukturalni chyby, ne semanticke, takze za me je lepsi nepsat praseci kod.
Název: Re:Co si myslíte o OOP?
Přispěvatel: operator 21. 01. 2019, 17:22:58
Ja vedel ze to najdu, zajimalo me, kdo s touto vtipnou tezi prisel. A citoval jsem spatne, nebylo to v podstate, ale obecne.
... největší rozdíl vidím v dokumentaci.
Mě teda oslovilo compile time. Když konečně přesvědčím kompilátor, aby to přeložil, tak mám obecně hotovo. Zbejvaj sémantické chyby. Zatímco u dynamického jazyka furt něco padá.
Tam patřilo spíš "Zatímco u dynamického jazyka mi furt něco padá." Už jsem psal, že dynamické typování není pro každého. Je nutné si nejen držet určitou kázeň, ale i pokrýt jednotku testy.
řekl byste tedy, že programování v dynamických jazycích (python, js) je náročnější než ve statických (haskell, pascal)?
Jak se říká, Easy to Learn, Hard to Master. Začátky s pythonem a js jsou snazší, ale plné porozumění, zvláště u poměrně komplexního pythonu, je rozhodně náročné.
Název: Re:Co si myslíte o OOP?
Přispěvatel: Kit 21. 01. 2019, 17:24:34
Tam patřilo spíš "Zatímco u dynamického jazyka mi furt něco padá." Už jsem psal, že dynamické typování není pro každého. Je nutné si nejen držet určitou kázeň, ale i pokrýt jednotku testy.
řekl byste tedy, že programování v dynamických jazycích (python, js) je náročnější než ve statických (haskell, pascal)?

Naopak. Programování v dynamicky typovaných jazycích je jednodušší a bezpečnější, protože se neopíjíš iluzí, že tě typový systém ochrání před chybami.
Název: Re:Co si myslíte o OOP?
Přispěvatel: BoneFlute 21. 01. 2019, 17:26:17
řekl byste tedy, že programování v dynamických jazycích (python, js) je náročnější než ve statických (haskell, pascal)?
Záleží náročnější na co.

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

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

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

Je zajímavé, že u většiny dynamických jazyků se dříve či později objeví tendence přidat tomu statickou typovou kontrolu (Javascript, Python). Proč asi.
Název: Re:Co si myslíte o OOP?
Přispěvatel: operator 21. 01. 2019, 17:26:44
typová kontrola před spuštěním je statická typová kontrola
To nerozporuji, ale nepotrebuji k ni staticke typy.
to mi vůbec nedává smysl, asi radší půjdu programovat
Statickou typovou kontrolu lze provest i nad dynamickymi typy. Python umoznuje provest takovou kontrolu a presto je to porad dynamicky jazyk. A priklad jsem zde uvedl.
Název: Re:Co si myslíte o OOP?
Přispěvatel: Dor 21. 01. 2019, 17:29:14
Paráda. Tákže:

Napr. zapouzdreni je vlastnost modulovyho systemu. Ktery si lidi casto pletou s objektovym. Nebo je to treba taky totez.
Imho znepřístupňovat vlastnosti a funkcionalitu má smysl na úrovni modulů i na úrovni tříd. Jsem zvyklý při zapouzdřování myslet hlavně na to znepřístupňování na úrovni tříd, ale musí se s tím velmi opatrně. Špatně se to pak jednotkově testuje (což se dá většinou obejít), ale hlavně to často není potřeba, pokud se dodržuje SRP.

Polymorfismus je zalezitost typovyho systemu. V dynamickym jazyku me tohle netrapi, ve statickym musim mit po ruce interfacy nebo abstraktni tridy.
V dynamickém jazyku mě právě trápí, že ten interface kolegové často použít nemusí a tím se zhoršuje orientace v kódu.

OO navrh je staticky pohled na relace mezi objekty. Taky znamo jako ER diagram.
Dostal jsi mě. Ale víš co jsem myslel.

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

Viz http://wiki.c2.com/?AreDesignPatternsMissingLanguageFeatures
Asi úplně nerozumím argumentu. Místo factory patternu můžu použít i obyčejnou funkci. Můžu i nalinkovat funkčnost zkompilovanou z assembleru. Jsem programátor. Můžu cokoliv. :)

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

Popravde benefit pouzivani principu SOLID jsem nikdy moc nepochopi, treba mi to nekdo vysvetli na prikladu. Stejne tak jsem nikdy neprisel na to, proc navrhovat aplikace timto komplexnim zpusobem co pouziva milion hierarchii a rozhrani. Podle me je takovych systemu poskrovnu, napr. operacni system nebo GUI.
SOLID je celá sada doporučení a težko se udělá příklad do jednoho komentáře. Ale benefity jsou např: Snadná znovupoužitelnost již naprogramovaného. Dobře testovatelné jednotkovými testy. Minimalizace stavů, kdy opravou jedné funkcionality rozbiji jinou.

Ale samozřejmě OOP může být dobrý sluha ale velmi zlý pán.
Název: Re:Co si myslíte o OOP?
Přispěvatel: v 21. 01. 2019, 17:33:57
typová kontrola před spuštěním je statická typová kontrola
To nerozporuji, ale nepotrebuji k ni staticke typy.
to mi vůbec nedává smysl, asi radší půjdu programovat
Statickou typovou kontrolu lze provest i nad dynamickymi typy. Python umoznuje provest takovou kontrolu a presto je to porad dynamicky jazyk. A priklad jsem zde uvedl.
vybavuju si jenom příklad s typovýma anotacema
Název: Re:Co si myslíte o OOP?
Přispěvatel: operator 21. 01. 2019, 17:34:56
typová kontrola před spuštěním je statická typová kontrola
To nerozporuji, ale nepotrebuji k ni staticke typy.
to mi vůbec nedává smysl, asi radší půjdu programovat
Statickou typovou kontrolu lze provest i nad dynamickymi typy. Python umoznuje provest takovou kontrolu a presto je to porad dynamicky jazyk. A priklad jsem zde uvedl.
vybavuju si jenom příklad s typovýma anotacema
Však to je ono.
Název: Re:Co si myslíte o OOP?
Přispěvatel: Kadet 21. 01. 2019, 17:35:49
řekl byste tedy, že programování v dynamických jazycích (python, js) je náročnější než ve statických (haskell, pascal)?
Záleží náročnější na co.

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

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

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

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

S tim betonem je to dobry prirovnani.

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

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

V rustu je peklo napsat jakoukoliv cyklickou datovou strukturu. Graf, strom s pointrem na rodice, apod. V haskellu se mi to ani nildy nepovedlo, protoze je z principu imutabilni. Urcite existuje nejaly magicky trik jak tyhle problemy v haskellu resit, ale nemam na ne cas, protoze chci resit problemy a ne hadanky jak to udelat.
Název: Re:Co si myslíte o OOP?
Přispěvatel: BoneFlute 21. 01. 2019, 17:36:16
A hlavne, i kdyz pada, tak jen na semanticke chyby

Nikoliv. Padá to na syntaktické či logické chyby. Jako třeba na to, že do metody očekávající dict {street: "", city:""} pošlu: {name: "", surname:"", address: {street: "", city:""}}.
Název: Re:Co si myslíte o OOP?
Přispěvatel: BoneFlute 21. 01. 2019, 17:45:31
Ze to vyplazne semanticky spatnej vysledek mam asi podobnlu duveru jako kdyz to napisu v pythonu.
Nikdy jsem netvrdil opak.

V rustu je peklo napsat jakoukoliv cyklickou datovou strukturu. Graf, strom s pointrem na rodice, apod. V haskellu se mi to ani nildy nepovedlo, protoze je z principu imutabilni. Urcite existuje nejaly magicky trik jak tyhle problemy v haskellu resit
Většinou jsem se bez cyklické struktury obešel.
V Haskellu by to nemusel být problém, pokud nechceš pointer. Něco jako:

Kód: [Vybrat]
data Node = Node {pk: Int, val: String, links: [Node]}
Vycházíš z toho, že:
Kód: [Vybrat]
(Node 42 "text") == (Node 42 "text")protože na pointery se nehraje.
Název: Re:Co si myslíte o OOP?
Přispěvatel: v 21. 01. 2019, 17:46:59
typová kontrola před spuštěním je statická typová kontrola
To nerozporuji, ale nepotrebuji k ni staticke typy.
to mi vůbec nedává smysl, asi radší půjdu programovat
Statickou typovou kontrolu lze provest i nad dynamickymi typy. Python umoznuje provest takovou kontrolu a presto je to porad dynamicky jazyk. A priklad jsem zde uvedl.
vybavuju si jenom příklad s typovýma anotacema
Však to je ono.
tak to je rozpor - anotace / "nepotrebuji k ni staticke typy"
Název: Re:Co si myslíte o OOP?
Přispěvatel: operator 21. 01. 2019, 17:49:41
A hlavne, i kdyz pada, tak jen na semanticke chyby
Nikoliv. Padá to na syntaktické či logické chyby. Jako třeba na to, že do metody očekávající dict {street: "", city:""} pošlu: {name: "", surname:"", address: {street: "", city:""}}.
Logicke chyby povazuji za podmnozinu semantickych, a jak to pada po prelozeni se syntaktickymi, to bych chtel videt.
Název: Re:Co si myslíte o OOP?
Přispěvatel: BoneFlute 21. 01. 2019, 17:53:51
A hlavne, i kdyz pada, tak jen na semanticke chyby
Nikoliv. Padá to na syntaktické či logické chyby. Jako třeba na to, že do metody očekávající dict {street: "", city:""} pošlu: {name: "", surname:"", address: {street: "", city:""}}.
Logicke chyby povazuji za podmnozinu semantickych
Tak to považuješ chybně.
Název: Re:Co si myslíte o OOP?
Přispěvatel: v 21. 01. 2019, 18:01:58
V rustu je peklo napsat jakoukoliv cyklickou datovou strukturu. Graf, strom s pointrem na rodice, apod. V haskellu se mi to ani nildy nepovedlo, protoze je z principu imutabilni. Urcite existuje nejaly magicky trik jak tyhle problemy v haskellu resit, ale nemam na ne cas, protoze chci resit problemy a ne hadanky jak to udelat.
tohle je zajímavé téma! znám asi tři přístupy, reference v IO/ST atd, knot tying (velká sranda!) a u grafů to zajímavě řeší algebraické grafy (http://hackage.haskell.org/package/algebraic-graphs)
Název: Re:Co si myslíte o OOP?
Přispěvatel: Ondra Satai Nekola 21. 01. 2019, 18:07:30
Ja vedel ze to najdu, zajimalo me, kdo s touto vtipnou tezi prisel. A citoval jsem spatne, nebylo to v podstate, ale obecne.

... největší rozdíl vidím v dokumentaci.
Mě teda oslovilo compile time. Když konečně přesvědčím kompilátor, aby to přeložil, tak mám obecně hotovo. Zbejvaj sémantické chyby. Zatímco u dynamického jazyka furt něco padá.

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

BoneFlute nám zatím nevysvětlil, co mu v dynamicky typovaných jazycích neustále padá. Zřejmě dělá dobře, že se drží staticky typovaných jazyků.
A hlavne, i kdyz pada, tak jen na semanticke chyby, a ty BoneFlute obecne nepocita :-).

Tudiz tvrdim, ze je tu sorta lidi verici ve staticke typy a to, ze kdyz se jim podari prelozit kod se statickymi typy, maji obecne hotovo.

To je pořád dokola tvůj strawman.
Název: Re:Co si myslíte o OOP?
Přispěvatel: BoneFlute 21. 01. 2019, 18:19:43
V rustu je peklo napsat jakoukoliv cyklickou datovou strukturu. Graf, strom s pointrem na rodice, apod. V haskellu se mi to ani nildy nepovedlo, protoze je z principu imutabilni. Urcite existuje nejaly magicky trik jak tyhle problemy v haskellu resit, ale nemam na ne cas, protoze chci resit problemy a ne hadanky jak to udelat.
tohle je zajímavé téma! znám asi tři přístupy, reference v IO/ST atd, knot tying (velká sranda!) a u grafů to zajímavě řeší algebraické grafy (http://hackage.haskell.org/package/algebraic-graphs)
Mohl by si sem hodit nějaký scénář, kdy se cyklická datová struktura hodí? Pro představu.
Název: Re:Co si myslíte o OOP?
Přispěvatel: Kit 21. 01. 2019, 18:24:23
Tudiz tvrdim, ze je tu sorta lidi verici ve staticke typy a to, ze kdyz se jim podari prelozit kod se statickymi typy, maji obecne hotovo.
To je pořád dokola tvůj strawman.

Takže pokud aplikaci se statickými typy přeložíš, dáš ho s klidným svědomím bez vyzkoušení ihned na produkci?
Název: Re:Co si myslíte o OOP?
Přispěvatel: Ondra Satai Nekola 21. 01. 2019, 18:25:10
V rustu je peklo napsat jakoukoliv cyklickou datovou strukturu. Graf, strom s pointrem na rodice, apod. V haskellu se mi to ani nildy nepovedlo, protoze je z principu imutabilni. Urcite existuje nejaly magicky trik jak tyhle problemy v haskellu resit, ale nemam na ne cas, protoze chci resit problemy a ne hadanky jak to udelat.
tohle je zajímavé téma! znám asi tři přístupy, reference v IO/ST atd, knot tying (velká sranda!) a u grafů to zajímavě řeší algebraické grafy (http://hackage.haskell.org/package/algebraic-graphs)
Mohl by si sem hodit nějaký scénář, kdy se cyklická datová struktura hodí? Pro představu.

Je to celkem prirozene pro nektere reprezentace grafu.
Název: Re:Co si myslíte o OOP?
Přispěvatel: Ondra Satai Nekola 21. 01. 2019, 18:25:35
Tudiz tvrdim, ze je tu sorta lidi verici ve staticke typy a to, ze kdyz se jim podari prelozit kod se statickymi typy, maji obecne hotovo.
To je pořád dokola tvůj strawman.

Takže pokud aplikaci se statickými typy přeložíš, dáš ho s klidným svědomím bez vyzkoušení ihned na produkci?

Umis cist?
Název: Re:Co si myslíte o OOP?
Přispěvatel: v 21. 01. 2019, 18:26:25
V rustu je peklo napsat jakoukoliv cyklickou datovou strukturu. Graf, strom s pointrem na rodice, apod. V haskellu se mi to ani nildy nepovedlo, protoze je z principu imutabilni. Urcite existuje nejaly magicky trik jak tyhle problemy v haskellu resit, ale nemam na ne cas, protoze chci resit problemy a ne hadanky jak to udelat.
tohle je zajímavé téma! znám asi tři přístupy, reference v IO/ST atd, knot tying (velká sranda!) a u grafů to zajímavě řeší algebraické grafy (http://hackage.haskell.org/package/algebraic-graphs)
Mohl by si sem hodit nějaký scénář, kdy se cyklická datová struktura hodí? Pro představu.
já se s nima potkávám u AST (tam právě zkouším alga a jinde zase "závislostní vektor" - k vynucení konzistence) a interpretrech (knot tying, vážně velká sranda, vemu seznam instrukcí a složím je do jedné IO akce, v místě skoku na jiné místo programu uvážu uzlík)
Název: Re:Co si myslíte o OOP?
Přispěvatel: Kadet 21. 01. 2019, 18:28:00
Paráda. Tákže:

Napr. zapouzdreni je vlastnost modulovyho systemu. Ktery si lidi casto pletou s objektovym. Nebo je to treba taky totez.
Imho znepřístupňovat vlastnosti a funkcionalitu má smysl na úrovni modulů i na úrovni tříd. Jsem zvyklý při zapouzdřování myslet hlavně na to znepřístupňování na úrovni tříd, ale musí se s tím velmi opatrně. Špatně se to pak jednotkově testuje (což se dá většinou obejít), ale hlavně to často není potřeba, pokud se dodržuje SRP.

Polymorfismus je zalezitost typovyho systemu. V dynamickym jazyku me tohle netrapi, ve statickym musim mit po ruce interfacy nebo abstraktni tridy.
V dynamickém jazyku mě právě trápí, že ten interface kolegové často použít nemusí a tím se zhoršuje orientace v kódu.

OO navrh je staticky pohled na relace mezi objekty. Taky znamo jako ER diagram.
Dostal jsi mě. Ale víš co jsem myslel.

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

Viz http://wiki.c2.com/?AreDesignPatternsMissingLanguageFeatures
Asi úplně nerozumím argumentu. Místo factory patternu můžu použít i obyčejnou funkci. Můžu i nalinkovat funkčnost zkompilovanou z assembleru. Jsem programátor. Můžu cokoliv. :)

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

Popravde benefit pouzivani principu SOLID jsem nikdy moc nepochopi, treba mi to nekdo vysvetli na prikladu. Stejne tak jsem nikdy neprisel na to, proc navrhovat aplikace timto komplexnim zpusobem co pouziva milion hierarchii a rozhrani. Podle me je takovych systemu poskrovnu, napr. operacni system nebo GUI.
SOLID je celá sada doporučení a težko se udělá příklad do jednoho komentáře. Ale benefity jsou např: Snadná znovupoužitelnost již naprogramovaného. Dobře testovatelné jednotkovými testy. Minimalizace stavů, kdy opravou jedné funkcionality rozbiji jinou.

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

Moduly a objekty mi pripadaji jako totez. Tj. nejaka skupina funkci (plus pripadne nejaky stav). Ze je to totez je videt na prikladech
1. zapouzdreni se resi u obou a stejnymi zpusoby
2. v pythonu je modul vlastne objekt. A objekt je vlastne dict. Nac tedy pouzivat moduly nebo objekty a ztracet se v komplexite kdyz muzu pouzit obycejny dict

Alespon v erlangu je objekt nejaka isolovana vypocetni jednotka (actor, agent, proces, vlakno, apod.) a ne pouze obycejny dict v prestrojeni.


Pokud je problem ze kolegove nemuzou byt svazani sveraci kazajkou jazyka, jako v pripade chybejicich rozhrani v dynamickych jazycich, pak je to organizacni problem. V dynamickym jazyce bouchne driv nez ve statickym. Co je lepsi, tezko rict. Pro me je lepsi kdyz ten bolak praskne driv nez pozdeji a zacne se resit skutecny problem - spatna organizace lidi.

Ten clanek o design patternech obsahuje priklady. Vetsina oop patternj jsou proste ochcavka kolem toho, ze jazyk nedokaze napr. posilat funkce. Ted uz je ma i java, tak proc by nekdo vubec tyhle zastarale navrhove vzory pouzival.

O SOLID a dependency injection se hadat nebudu, nemam s tim zkusenosti. Ale prijde mi to zbytecne komplikovany.
Název: Re:Co si myslíte o OOP?
Přispěvatel: Kadet 21. 01. 2019, 18:50:14
V rustu je peklo napsat jakoukoliv cyklickou datovou strukturu. Graf, strom s pointrem na rodice, apod. V haskellu se mi to ani nildy nepovedlo, protoze je z principu imutabilni. Urcite existuje nejaly magicky trik jak tyhle problemy v haskellu resit, ale nemam na ne cas, protoze chci resit problemy a ne hadanky jak to udelat.
tohle je zajímavé téma! znám asi tři přístupy, reference v IO/ST atd, knot tying (velká sranda!) a u grafů to zajímavě řeší algebraické grafy (http://hackage.haskell.org/package/algebraic-graphs)

Diky za odkaz. Vic podobnych linku by sem mohli lidi hodit.

Projel jsem slidy toho jak funguje tahle algebraicka reprezentace grafu. Musel bych ale videt metodu jak reprezentovat libovolny netrivialni graf timhle zpusobem. Pak bych potreboval videt jak se nad tim delaji klasicky algoritmy, alespon pruchody grafem. Napada me z toho vygenerovat klasickou adjacency matici a pak s tim pracovat zase klasicky.
Název: Re:Co si myslíte o OOP?
Přispěvatel: BoneFlute 21. 01. 2019, 18:54:16
já se s nima potkávám u AST (tam právě zkouším alga a jinde zase "závislostní vektor" - k vynucení konzistence) a interpretrech (knot tying, vážně velká sranda, vemu seznam instrukcí a složím je do jedné IO akce, v místě skoku na jiné místo programu uvážu uzlík)

Mohl by si se více rozepsat. Shodou okolností jsem zrovna nějaké to ASTčko nedávno dělal. A na žádný cyklický graf jsem nenarazil. Vždy jsem si vystačil se stromem. Buď jsem tak šikovnej (nepravděpodobné), nebo jsem se jen náhodou vyhnul nějakému scénáři... Předem dík.
Název: Re:Co si myslíte o OOP?
Přispěvatel: v 21. 01. 2019, 18:59:51
já se s nima potkávám u AST (tam právě zkouším alga a jinde zase "závislostní vektor" - k vynucení konzistence) a interpretrech (knot tying, vážně velká sranda, vemu seznam instrukcí a složím je do jedné IO akce, v místě skoku na jiné místo programu uvážu uzlík)

Mohl by si se více rozepsat. Shodou okolností jsem zrovna nějaké to ASTčko nedávno dělal. A na žádný cyklický graf jsem nenarazil. Vždy jsem si vystačil se stromem. Buď jsem tak šikovnej (nepravděpodobné), nebo jsem se jen náhodou vyhnul nějakému scénáři... Předem dík.
a jo vlastně, to T v AST znamená strom :D
v mém scénáři začnu se strukturovaným AST (podmínky + cykly, fakt strom) a přeložím ho na seznam příkazů se skokama (tohle jsem měl původně na mysli, když jsem psal AST) a tady už jsou cykly kdy se příkaz skoku odkazuje na jiný příkaz ve stejném seznamu
Název: Re:Co si myslíte o OOP?
Přispěvatel: v 21. 01. 2019, 19:08:53
V rustu je peklo napsat jakoukoliv cyklickou datovou strukturu. Graf, strom s pointrem na rodice, apod. V haskellu se mi to ani nildy nepovedlo, protoze je z principu imutabilni. Urcite existuje nejaly magicky trik jak tyhle problemy v haskellu resit, ale nemam na ne cas, protoze chci resit problemy a ne hadanky jak to udelat.
tohle je zajímavé téma! znám asi tři přístupy, reference v IO/ST atd, knot tying (velká sranda!) a u grafů to zajímavě řeší algebraické grafy (http://hackage.haskell.org/package/algebraic-graphs)

Diky za odkaz. Vic podobnych linku by sem mohli lidi hodit.

Projel jsem slidy toho jak funguje tahle algebraicka reprezentace grafu. Musel bych ale videt metodu jak reprezentovat libovolny netrivialni graf timhle zpusobem. Pak bych potreboval videt jak se nad tim delaji klasicky algoritmy, alespon pruchody grafem. Napada me z toho vygenerovat klasickou adjacency matici a pak s tim pracovat zase klasicky.
paper není nezbytný k využití knihovny, tak jsem ho radši nečet, ale ten základní trik je vidět z deklarace typu:
http://hackage.haskell.org/package/algebraic-graphs-0.3/docs/src/Algebra.Graph.html#Graph
Kód: [Vybrat]
data Graph a = Empty
             | Vertex a
             | Overlay (Graph a) (Graph a)
             | Connect (Graph a) (Graph a)
Název: Re:Co si myslíte o OOP?
Přispěvatel: Mirek Prýmek 21. 01. 2019, 20:30:51
Je to pouzitelne. Pouzivam to bezne pri vyvoji webu. Main aplikace porovnava cas py a pyc souboru a kdyz je py novejsi, tak modul, typicky nejaky handler requestu, automaticky reloadne. Nemusim kvuli tomu restartovat celou aplikaci.
No jistě, funguje ti to proto, že handler requestu je "fire and forget". Pokud by to byl modul, který pořád běží (někdo někde, nikdo neví kde všude ho přímo nebo nepřímo používá), tak by ti to nefungovalo.
Název: Re:Co si myslíte o OOP?
Přispěvatel: operator 21. 01. 2019, 20:38:21
A hlavne, i kdyz pada, tak jen na semanticke chyby
Nikoliv. Padá to na syntaktické či logické chyby. Jako třeba na to, že do metody očekávající dict {street: "", city:""} pošlu: {name: "", surname:"", address: {street: "", city:""}}.
Logicke chyby povazuji za podmnozinu semantickych
Tak to považuješ chybně.
Nejsem si jist, ale doufal jsem, ze to reknes. Vyplyva z toho, ze zijes v domeni, ze kompiler ti diky statickym typum odchyti logicke chyby. Protoze jak jsi uvedl, po uspesne kompilaci je obecne vse hotovo, zbyvaji jen semanticke chyby.
Název: Re:Co si myslíte o OOP?
Přispěvatel: operator 21. 01. 2019, 20:39:51
Ja vedel ze to najdu, zajimalo me, kdo s touto vtipnou tezi prisel. A citoval jsem spatne, nebylo to v podstate, ale obecne.

... největší rozdíl vidím v dokumentaci.
Mě teda oslovilo compile time. Když konečně přesvědčím kompilátor, aby to přeložil, tak mám obecně hotovo. Zbejvaj sémantické chyby. Zatímco u dynamického jazyka furt něco padá.

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

BoneFlute nám zatím nevysvětlil, co mu v dynamicky typovaných jazycích neustále padá. Zřejmě dělá dobře, že se drží staticky typovaných jazyků.
A hlavne, i kdyz pada, tak jen na semanticke chyby, a ty BoneFlute obecne nepocita :-).

Tudiz tvrdim, ze je tu sorta lidi verici ve staticke typy a to, ze kdyz se jim podari prelozit kod se statickymi typy, maji obecne hotovo.
To je pořád dokola tvůj strawman.
Neni, je to reakce na tvrzeni, ktere tu zaznelo.
Název: Re:Co si myslíte o OOP?
Přispěvatel: operator 21. 01. 2019, 20:44:23
Moduly a objekty mi pripadaji jako totez. Tj. nejaka skupina funkci (plus pripadne nejaky stav). Ze je to totez je videt na prikladech
1. zapouzdreni se resi u obou a stejnymi zpusoby
2. v pythonu je modul vlastne objekt. A objekt je vlastne dict. Nac tedy pouzivat moduly nebo objekty a ztracet se v komplexite kdyz muzu pouzit obycejny dict
Modul je reprezentace souboru. Objekt je v pythonu vsechno. Mozna mas na mysli tridy. Ty maji dedicnost, funguji jako uzivatelske datove typy a podobne vychytavky. Jak bys to implementoval jen pomoci slovniku?
Název: Re:Co si myslíte o OOP?
Přispěvatel: Mirek Prýmek 21. 01. 2019, 21:30:29
zvláště u poměrně komplexního pythonu
Co je na Pythonu komplexního?
Název: Re:Co si myslíte o OOP?
Přispěvatel: Mirek Prýmek 21. 01. 2019, 22:03:29
Moduly a objekty mi pripadaji jako totez.
Jako totéž to může připadat právě kvůli tomu zparchantělému OOP, co se rozšířilo jako mor a které považuje za normální lézt do jednoho objektu z víc vláken, takže pojem objektu jako entity, která něco dělá, začíná ztrácet smysl.

Pro zjednodušení si stačí představit, že každý objekt má vlastní vlákno. Když objektu Kuchař pošlu zprávu [vař: pizzu], tak vaří pizzu a těžko může zároveň vařit omáčku. Zparchantělé OOP udělalo z objektu Kuchař jenom KuchařskáKniha, ve které si listuje kdo chce, co chce si sám uvaří a ještě ke všemu si stav uvařeného všichni zapisují na jedno místo, o které se perou. Naprosto něco jinýho než původní myšlenka ("objects being like biological cells").

Alespon v erlangu je objekt nejaka isolovana vypocetni jednotka (actor, agent, proces, vlakno, apod.) a ne pouze obycejny dict v prestrojeni.
Právě proto, že v Erlangu[1] je to přesně naopak, než píšeš, je Erlang původní myšlence OOP paradoxně blíž než ty slavné "OOP jazyky".

V Erlangu:

modul = množina funkcí, nástroj pro organizaci kódu do souvisejících celků, tj. "neživá věc", předpis

proces (v tomhle smyslu ekvivalent objektu) = entita, která drží stav, přijímá zprávy a provádí výpočet, tj. "žije", je to "organismus" (viz biologická inspirace původního OOP)

Jo, občas dává smysl mít modul mapovaný na proces 1:1 (často je to obdoba patternu "singleton"), ale pořád jsou to dvě totálně rozdílné věci s naprosto jiným účelem a dobře to pochopit je pro programování v Erlangu naprosto klíčový, bez toho nedá člověk ani ránu.

[1] tady a všude níž můžeme s/Erlang/Elixir/

=====

P.S. Hele, bez urážky, mám pocit, že ten Erlang a Elixir moc neznáš, bylo by imho lepší, kdybys o nich moc nepsal, nebo aspoň vždycky připsal aspoň "IIRC". Těma chybnýma kategorickýma tvrzeníma zbytečně mateš lidi...
Název: Re:Co si myslíte o OOP?
Přispěvatel: Mirek Prýmek 21. 01. 2019, 22:10:48
Právě proto, že v Erlangu[1] je to přesně naopak, než píšeš
Jo, teď mi došlo, že tady už jsi možná nemluvil o modulech, z kontextu to není poznat. Pokud ne, tak sry, pak to citovaný beru zpět :)
Název: Re:Co si myslíte o OOP?
Přispěvatel: Martin 21. 01. 2019, 22:15:21
Jako totéž to může připadat právě kvůli tomu zparchantělému OOP, co se rozšířilo jako mor a které považuje za normální lézt do jednoho objektu z víc vláken, takže pojem objektu jako entity, která něco dělá, začíná ztrácet smysl.

Pro zjednodušení si stačí představit, že každý objekt má vlastní vlákno. Když objektu Kuchař pošlu zprávu [vař: pizzu], tak vaří pizzu a těžko může zároveň vařit omáčku. ...
Ten objekt se s tim musi nejak popasovat. Kdyz kuchar vari pizzu a zadas mu jeste varit omacku, tak bud na to ma kapacity a dela 2 veci soucasne (na dnesnich PC proc ne), nebo muze vratit nejake ERROR_BUSY pripadne 2. zadost zaradi do fronty a vyzvedne ji az po vyrizeni 1. zadosti.
Vzdyt je to jen objekt. Paralelni zadosti musi zvladat i fyzicky HW a jeho ovladac. Predstavte si sitovku, ktera vas odmitne pripojit na net, protoze se ted pres ni bavi windows update service s MS servery.
Název: Re:Co si myslíte o OOP?
Přispěvatel: Mirek Prýmek 21. 01. 2019, 22:20:22
Ten objekt se s tim musi nejak popasovat. Kdyz kuchar vari pizzu a zadas mu jeste varit omacku, tak bud na to ma kapacity a dela 2 veci soucasne (na dnesnich PC proc ne), nebo muze vratit nejake ERROR_BUSY pripadne 2. zadost zaradi do fronty a vyzvedne ji az po vyrizeni 1. zadosti.
Přesně tak! Ale má to fungovat tak, že já kuchaře o něco požádám a on to buď umí, nebo neumí atd. A ne že se já (vlákno) stanu kuchařem a uvařím si to sám, přičemž kuchařská kniha je napsaná tak, aby dva lidi (vlákna) mohli vařit zaráz, i když o sobě navzájem vůbec nic neví (sdílí jenom zámek).

Chápej, rozdíl je právě v tom, jestli je objekt "jednotka kódu" nebo "jadnotka výpočtu" (neboli "TA entita, která vyvíjí nějakou činnost"). Ve zparchantělém OOP je "objekt" ve skutečnosti spíš modul (a proto někteří lidi moc nechápou, jakej - a vůbec proč - by měl být mezi modulem a objektem rozdíl).
Název: Re:Co si myslíte o OOP?
Přispěvatel: Martin 21. 01. 2019, 22:30:36
Ten objekt se s tim musi nejak popasovat. Kdyz kuchar vari pizzu a zadas mu jeste varit omacku, tak bud na to ma kapacity a dela 2 veci soucasne (na dnesnich PC proc ne), nebo muze vratit nejake ERROR_BUSY pripadne 2. zadost zaradi do fronty a vyzvedne ji az po vyrizeni 1. zadosti.
Přesně tak! Ale má to fungovat tak, že já kuchaře o něco požádám a on to buď umí, nebo neumí atd. A ne že se já (vlákno) stanu kuchařem a uvařím si to sám, přičemž kuchařská kniha je napsaná tak, aby dva lidi (vlákna) mohli vařit zaráz, i když o sobě navzájem vůbec nic neví (sdílí jenom zámek).

Chápej, rozdíl je právě v tom, jestli je objekt "jednotka kódu" nebo "jadnotka výpočtu" (neboli "TA entita, která vyvíjí nějakou činnost"). Ve zparchantělém OOP je "objekt" ve skutečnosti spíš modul (a proto někteří lidi moc nechápou, jakej - a vůbec proč - by měl být mezi modulem a objektem rozdíl).
To, ze o sobe nevedi, je problem kuchare. Kdyz je to schopny nejak zaridit, ze vsechno funguje, nevidim problem. Mame jen omezeny pocet jader (CPU), tak se jadra prevlekaji, chvili hraji cisnika, chvili kuchare.

Pro me je objekt vlastne jen datova struktura + nejake picarny kolem. A ted do me :-)
(uznavam virtualni funkce (= volani pres pointer), muze to dost urychlit vypocet)
Název: Re:Co si myslíte o OOP?
Přispěvatel: Mirek Prýmek 21. 01. 2019, 22:51:47
To, ze o sobe nevedi, je problem kuchare. Kdyz je to schopny nejak zaridit, ze vsechno funguje, nevidim problem.
Jenže ve zparchantělém OOP žádný Kuchař (jako entita která něco dělá, tj. aktor[1]), není. Je jenom KuchařskáKniha, což je takový (nepopírám) docela fikaný protokol, postavený na tom, že kolem Knihy chodí lidi (to jsou tam ti aktoři!) a přesně podle návodu cosi do knihy píšou. Každej z těch různých lidí je občas kuchařem, někdy i víc z nich zaráz atd.

Mame jen omezeny pocet jader (CPU), tak se jadra prevlekaji, chvili hraji cisnika, chvili kuchare.
No tak to každopádně. Určitě budeme mít víc aktorů než jader. V tom není problém. Problém je v tom, že to probublává do programu. Pokud by se to dělo způsobem, o kterém programátor vůbec neví a neřeší to, bylo by to naprosto OK (proto jsou taky goroutiny v tomhle smyslu naprosto OK)

Pro me je objekt vlastne jen datova struktura + nejake picarny kolem. A ted do me :-)
Tak jasně no, to nejsi sám. Však když ti to vyhovuje, není problém, užij si to! :) Akorát to prostě vůbec neodpovídá ani základním myšlenkám původního OOP. Je to prostě takové nové zparchantělé OOP© ;)

===
[1] BTW, všimněme si, že "jednotka, která něco dělá" je vlastně doslovný překlad slova "actor" ;)
Název: Re:Co si myslíte o OOP?
Přispěvatel: Mirek Prýmek 21. 01. 2019, 23:05:01
Mimochodem, pokud máš třeba hru, ve které běží v jednom vlákně herní logika a ve druhém GUI a předávají si data přes nějakou frontu/buffer, tak z pohledu původního OOP je to vlastně de facto systém o dvou objektech, které si posílají zprávy.

Z neznámého důvodu je tam teda taky na jiné úrovni abstrakce jakejsi bordel, kde se mnohokrát opakuje slovo "class" a "object", ale to žádný třídy a objekty nejsou, to je jenom nějaká změť těžko uchopitelných pomateností ;)
Název: Re:Co si myslíte o OOP?
Přispěvatel: Kadet 22. 01. 2019, 00:00:23
Moduly a objekty mi pripadaji jako totez. Tj. nejaka skupina funkci (plus pripadne nejaky stav). Ze je to totez je videt na prikladech
1. zapouzdreni se resi u obou a stejnymi zpusoby
2. v pythonu je modul vlastne objekt. A objekt je vlastne dict. Nac tedy pouzivat moduly nebo objekty a ztracet se v komplexite kdyz muzu pouzit obycejny dict
Modul je reprezentace souboru. Objekt je v pythonu vsechno. Mozna mas na mysli tridy. Ty maji dedicnost, funguji jako uzivatelske datove typy a podobne vychytavky. Jak bys to implementoval jen pomoci slovniku?

Jo, ale misto toho, abych zavadel zbytecne koncepty trida, objekt a modul, muzu pouzit proste jen dict.

Dedicnost muzes v dictu naimplementovat jednoduse. Prolinkujes par dictu dohromady a kdyz hledas konkretni metodu/odpoved na prichazejici zpravu projedes ten seznam dictu dokud nenajdes tu funkci.

[dict1, dict2, dict3]

ekvivalentni

class C: pass
class B(C): pass
class A(B): pass

kde A odpovida dict1, B dict2, C dict3

Kdybys implementoval novej jazyk tak udelas nejpravdepodobneji prave tohle.
Název: Re:Co si myslíte o OOP?
Přispěvatel: Kadet 22. 01. 2019, 00:00:48
Právě proto, že v Erlangu[1] je to přesně naopak, než píšeš
Jo, teď mi došlo, že tady už jsi možná nemluvil o modulech, z kontextu to není poznat. Pokud ne, tak sry, pak to citovaný beru zpět :)

Dik, pochopils.
Název: Re:Co si myslíte o OOP?
Přispěvatel: Mirek Prýmek 22. 01. 2019, 00:03:16
Dik, pochopils.
Zkus pls psát trochu explicitněji a přesněji. Viz "V Erlangu je objekt [...]" - v Erlangu žádný objekt není, takže těžko odhadovat, o čem mluvíš...
Název: Re:Co si myslíte o OOP?
Přispěvatel: Kadet 22. 01. 2019, 00:11:15
Moduly a objekty mi pripadaji jako totez. Tj. nejaka skupina funkci (plus pripadne nejaky stav). Ze je to totez je videt na prikladech
1. zapouzdreni se resi u obou a stejnymi zpusoby
2. v pythonu je modul vlastne objekt. A objekt je vlastne dict. Nac tedy pouzivat moduly nebo objekty a ztracet se v komplexite kdyz muzu pouzit obycejny dict
Modul je reprezentace souboru. Objekt je v pythonu vsechno. Mozna mas na mysli tridy. Ty maji dedicnost, funguji jako uzivatelske datove typy a podobne vychytavky. Jak bys to implementoval jen pomoci slovniku?

Jo, ale misto toho, abych zavadel zbytecne koncepty trida, objekt a modul, muzu pouzit proste jen dict.

Dedicnost muzes v dictu naimplementovat jednoduse. Prolinkujes par dictu dohromady a kdyz hledas konkretni metodu/odpoved na prichazejici zpravu projedes ten seznam dictu dokud nenajdes tu funkci.

[dict1, dict2, dict3]

ekvivalentni

class C: pass
class B(C): pass
class A(B): pass

kde A odpovida dict1, B dict2, C dict3

Kdybys implementoval novej jazyk tak udelas nejpravdepodobneji prave tohle.

Nejdulezitejsi na tom je, ze moduly jsou to samy. vsechno je to dict v prestrojeni.

c.py:
-

b.py:
import c

a.py:
import b
Název: Re:Co si myslíte o OOP?
Přispěvatel: Kadet 22. 01. 2019, 00:15:34
Dik, pochopils.
Zkus pls psát trochu explicitněji a přesněji. Viz "V Erlangu je objekt [...]" - v Erlangu žádný objekt není, takže těžko odhadovat, o čem mluvíš...

Mas pravdu, v Erlangu neni objekt. Vazu na to diskusi Co je to OOP. V Erlangu beru proces jako actor nebo taky jako 'aktivni' objekt. Neco co je bliz OOP myslence od Kaye nez objekt jako modul v tom cemu ty rikas zparchantele oop.
Název: Re:Co si myslíte o OOP?
Přispěvatel: Mirek Prýmek 22. 01. 2019, 00:23:45
Mas pravdu, v Erlangu neni objekt. Vazu na to diskusi Co je to OOP. V Erlangu beru proces jako actor nebo taky jako 'aktivni' objekt. Neco co je bliz OOP myslence od Kaye nez objekt jako modul v tom cemu ty rikas zparchantele oop.
Ok, tak to bylo nedorozumění, v tom případě to chápeš naprosto správně. Omlouvám se.
Název: Re:Co si myslíte o OOP?
Přispěvatel: gll 22. 01. 2019, 08:31:28
zvláště u poměrně komplexního pythonu
Co je na Pythonu komplexního?

Málokdo zná Python dohloubky. Pro běžné programování to ani není potřeba.

Dobré přednášky o pokročilejších vlastnostech má David Beazley.

třeba https://www.youtube.com/watch?v=sPiWg5jSoZI - metaprogramming

https://www.youtube.com/watch?v=0oTh1CXRaQ0 - modules and packages, nudné téma, ale důležité

https://www.youtube.com/watch?v=MCs5OvhV9S4 - concurrency, trochu starší bez async/await
Název: Re:Co si myslíte o OOP?
Přispěvatel: Mirek Prýmek 22. 01. 2019, 08:41:31
Dobré přednášky o pokročilejších vlastnostech má David Beazley.
No, když tyhle "pokročilejší" věci porovnám třeba s C++, tak bych je rozhodně nenazval "komplexní" ;)

(to není kritika, to je dobře)
Název: Re:Co si myslíte o OOP?
Přispěvatel: operator 22. 01. 2019, 08:43:31
Moduly a objekty mi pripadaji jako totez. Tj. nejaka skupina funkci (plus pripadne nejaky stav). Ze je to totez je videt na prikladech
1. zapouzdreni se resi u obou a stejnymi zpusoby
2. v pythonu je modul vlastne objekt. A objekt je vlastne dict. Nac tedy pouzivat moduly nebo objekty a ztracet se v komplexite kdyz muzu pouzit obycejny dict
Modul je reprezentace souboru. Objekt je v pythonu vsechno. Mozna mas na mysli tridy. Ty maji dedicnost, funguji jako uzivatelske datove typy a podobne vychytavky. Jak bys to implementoval jen pomoci slovniku?

Jo, ale misto toho, abych zavadel zbytecne koncepty trida, objekt a modul, muzu pouzit proste jen dict.

Dedicnost muzes v dictu naimplementovat jednoduse. Prolinkujes par dictu dohromady a kdyz hledas konkretni metodu/odpoved na prichazejici zpravu projedes ten seznam dictu dokud nenajdes tu funkci.

[dict1, dict2, dict3]

ekvivalentni

class C: pass
class B(C): pass
class A(B): pass

kde A odpovida dict1, B dict2, C dict3

Kdybys implementoval novej jazyk tak udelas nejpravdepodobneji prave tohle.
Tim ale neimplementujes dedicnost v dictu, a dedicnost pomoci seznamu dictu a kodu, ktery to osetri, pricemz seznam je zase jen nadstavba nad dictem. Jestli tim chces rict, ze dokazes pomoci dictu emulovat chovani trid, tak asi ano, ale budes k tomu potrebovat slozity kod, c3 linearizaci a bude to tezkopadne na pouzivani. A v tom spociva smysl trid, modulu atd. Je to abstrakce, ktera ti zjednodusi a zprehledni programovy kod. Pokud to nepotrebujes, muzes zkusit programovat primo ve strojovem kodu. Pak imho prehodnotis nazor a zjistis, ze abstraktni prvky/pojmy komplexitu programu snizuji, nikoliv zvysuji.

Dict se v pythonu pouziva na implementaci objektu, a protoze vsechno je v pythonu objekt, muzeme rict, ze dict je soucasti vseho, je to zakladni datova struktura Pythonu, proto taky na vsechno funguje dir(). Ale neznamena, ze kdyz to pouziva dict, tak muzeme rikat, ze je to dict a nic jineho nepotrebujeme. Protoze s takovou muzeme jit hloub a prohlasit, ze vsechno je jen cislo, resp. organizovany seznam jednicek a nul, cimz jsme zpatky u strojoveho kodu.
Název: Re:Co si myslíte o OOP?
Přispěvatel: gll 22. 01. 2019, 08:56:57
Dobré přednášky o pokročilejších vlastnostech má David Beazley.
No, když tyhle "pokročilejší" věci porovnám třeba s C++, tak bych je rozhodně nenazval "komplexní" ;)

(to není kritika, to je dobře)

nemůžeš hodnotit komplexitu toho co neznáš.
Název: Re:Co si myslíte o OOP?
Přispěvatel: operator 22. 01. 2019, 09:00:00
zvláště u poměrně komplexního pythonu
Co je na Pythonu komplexního?
a) pisu pomerne, kde jsi vytrhl z kontextu, že ho pomeruji k JS
b) python jako jazyk ma mnoho ruznych abstrakci a pokryva nekolik paradigmat
c) python ma dynamickou introspekci a umoznuje programovat program
d) a po teto diskusi mohu dodat, python je dynamicky, coz predstavuje slozitost, kterou mnozi neumi pobrat
Název: Re:Co si myslíte o OOP?
Přispěvatel: gll 22. 01. 2019, 09:01:58
Moduly a objekty mi pripadaji jako totez. Tj. nejaka skupina funkci (plus pripadne nejaky stav). Ze je to totez je videt na prikladech
1. zapouzdreni se resi u obou a stejnymi zpusoby
2. v pythonu je modul vlastne objekt. A objekt je vlastne dict. Nac tedy pouzivat moduly nebo objekty a ztracet se v komplexite kdyz muzu pouzit obycejny dict
Modul je reprezentace souboru. Objekt je v pythonu vsechno. Mozna mas na mysli tridy. Ty maji dedicnost, funguji jako uzivatelske datove typy a podobne vychytavky. Jak bys to implementoval jen pomoci slovniku?

Jo, ale misto toho, abych zavadel zbytecne koncepty trida, objekt a modul, muzu pouzit proste jen dict.

Dedicnost muzes v dictu naimplementovat jednoduse. Prolinkujes par dictu dohromady a kdyz hledas konkretni metodu/odpoved na prichazejici zpravu projedes ten seznam dictu dokud nenajdes tu funkci.

[dict1, dict2, dict3]

ekvivalentni

class C: pass
class B(C): pass
class A(B): pass

kde A odpovida dict1, B dict2, C dict3

Kdybys implementoval novej jazyk tak udelas nejpravdepodobneji prave tohle.
Tim ale neimplementujes dedicnost v dictu, a dedicnost pomoci seznamu dictu a kodu, ktery to osetri, pricemz seznam je zase jen nadstavba nad dictem. Jestli tim chces rict, ze dokazes pomoci dictu emulovat chovani trid, tak asi ano, ale budes k tomu potrebovat slozity kod, c3 linearizaci a bude to tezkopadne na pouzivani. A v tom spociva smysl trid, modulu atd. Je to abstrakce, ktera ti zjednodusi a zprehledni programovy kod. Pokud to nepotrebujes, muzes zkusit programovat primo ve strojovem kodu. Pak imho prehodnotis nazor a zjistis, ze abstraktni prvky/pojmy komplexitu programu snizuji, nikoliv zvysuji.

Dict se v pythonu pouziva na implementaci objektu, a protoze vsechno je v pythonu objekt, muzeme rict, ze dict je soucasti vseho, je to zakladni datova struktura Pythonu, proto taky na vsechno funguje dir(). Ale neznamena, ze kdyz to pouziva dict, tak muzeme rikat, ze je to dict a nic jineho nepotrebujeme. Protoze s takovou muzeme jit hloub a prohlasit, ze vsechno je jen cislo, resp. organizovany seznam jednicek a nul, cimz jsme zpatky u strojoveho kodu.

javascript donedávna neměl ani třídy ani moduly a nechyběly. Byly přidány hlavně z marketingových důvodů. Vše bylo objekt/slovník. Stále je, nová syntax je jen nadbytečný cukr.
Název: Re:Co si myslíte o OOP?
Přispěvatel: operator 22. 01. 2019, 09:16:23
Moduly a objekty mi pripadaji jako totez. Tj. nejaka skupina funkci (plus pripadne nejaky stav). Ze je to totez je videt na prikladech
1. zapouzdreni se resi u obou a stejnymi zpusoby
2. v pythonu je modul vlastne objekt. A objekt je vlastne dict. Nac tedy pouzivat moduly nebo objekty a ztracet se v komplexite kdyz muzu pouzit obycejny dict
Modul je reprezentace souboru. Objekt je v pythonu vsechno. Mozna mas na mysli tridy. Ty maji dedicnost, funguji jako uzivatelske datove typy a podobne vychytavky. Jak bys to implementoval jen pomoci slovniku?

Jo, ale misto toho, abych zavadel zbytecne koncepty trida, objekt a modul, muzu pouzit proste jen dict.

Dedicnost muzes v dictu naimplementovat jednoduse. Prolinkujes par dictu dohromady a kdyz hledas konkretni metodu/odpoved na prichazejici zpravu projedes ten seznam dictu dokud nenajdes tu funkci.

[dict1, dict2, dict3]

ekvivalentni

class C: pass
class B(C): pass
class A(B): pass

kde A odpovida dict1, B dict2, C dict3

Kdybys implementoval novej jazyk tak udelas nejpravdepodobneji prave tohle.
Tim ale neimplementujes dedicnost v dictu, a dedicnost pomoci seznamu dictu a kodu, ktery to osetri, pricemz seznam je zase jen nadstavba nad dictem. Jestli tim chces rict, ze dokazes pomoci dictu emulovat chovani trid, tak asi ano, ale budes k tomu potrebovat slozity kod, c3 linearizaci a bude to tezkopadne na pouzivani. A v tom spociva smysl trid, modulu atd. Je to abstrakce, ktera ti zjednodusi a zprehledni programovy kod. Pokud to nepotrebujes, muzes zkusit programovat primo ve strojovem kodu. Pak imho prehodnotis nazor a zjistis, ze abstraktni prvky/pojmy komplexitu programu snizuji, nikoliv zvysuji.

Dict se v pythonu pouziva na implementaci objektu, a protoze vsechno je v pythonu objekt, muzeme rict, ze dict je soucasti vseho, je to zakladni datova struktura Pythonu, proto taky na vsechno funguje dir(). Ale neznamena, ze kdyz to pouziva dict, tak muzeme rikat, ze je to dict a nic jineho nepotrebujeme. Protoze s takovou muzeme jit hloub a prohlasit, ze vsechno je jen cislo, resp. organizovany seznam jednicek a nul, cimz jsme zpatky u strojoveho kodu.

javascript donedávna neměl ani třídy ani moduly a nechyběly. Byly přidány hlavně z marketingových důvodů. Vše bylo objekt/slovník. Stále je, nová syntax je jen nadbytečný cukr.
Protirecis si, marketing je uspokojovani potreb zakaznika. Cim komplexnejsi veci se v JS programuji, tim vice takove abstrakce jsou potreba. Proto byly pozadovany a proto byly implementovany. 

Mne v JS v prohlizecich treba porad jeste chybi moznost importovat z jednoho js souboru druhy.
Název: Re:Co si myslíte o OOP?
Přispěvatel: operator 22. 01. 2019, 09:24:48
Pak imho prehodnotis nazor a zjistis, ze abstraktni prvky/pojmy komplexitu programu snizuji, nikoliv zvysuji.
Aby nedoslo k nedorozumeni. Programem tady minim programovy kod. Vzhledem k tomu, ze to zjednodusi programovani, to umoznuje ve vysledku vznik komplexnejsich programu ve smyslu aplikaci.
Název: Re:Co si myslíte o OOP?
Přispěvatel: Kit 22. 01. 2019, 09:32:29
Pak imho prehodnotis nazor a zjistis, ze abstraktni prvky/pojmy komplexitu programu snizuji, nikoliv zvysuji.
Aby nedoslo k nedorozumeni. Programem tady minim programovy kod. Vzhledem k tomu, ze to zjednodusi programovani, to umoznuje ve vysledku vznik komplexnejsich programu ve smyslu aplikaci.

Jinak řečeno pro každou úroveň abstrakce použiješ jiný syntaktický cukr. Čitelnost a přehlednost programu se tím zvýší a sníží se riziko chyb.
Název: Re:Co si myslíte o OOP?
Přispěvatel: operator 22. 01. 2019, 10:00:46
Pak imho prehodnotis nazor a zjistis, ze abstraktni prvky/pojmy komplexitu programu snizuji, nikoliv zvysuji.
Aby nedoslo k nedorozumeni. Programem tady minim programovy kod. Vzhledem k tomu, ze to zjednodusi programovani, to umoznuje ve vysledku vznik komplexnejsich programu ve smyslu aplikaci.
Jinak řečeno pro každou úroveň abstrakce použiješ jiný syntaktický cukr. Čitelnost a přehlednost programu se tím zvýší a sníží se riziko chyb.
Asi bych nemluvil o urovni, ale jinak ano, presne to je cil, zjednoduseni programoveho kodu. Krome toho se take zvysi efetivita tvorby programu.
Název: Re:Co si myslíte o OOP?
Přispěvatel: gll 22. 01. 2019, 10:06:08
Asi bych nemluvil o urovni, ale jinak ano, presne to je cil, zjednoduseni programoveho kodu. Krome toho se take zvysi efetivita tvorby programu.

Class v Javascriptu nic nezjednodušuje. Kód nezkracuje. Je to jen omáčka navíc.
Název: Re:Co si myslíte o OOP?
Přispěvatel: Dor 22. 01. 2019, 11:45:42
Moduly a objekty mi pripadaji jako totez. Tj. nejaka skupina funkci (plus pripadne nejaky stav). Ze je to totez je videt na prikladech
1. zapouzdreni se resi u obou a stejnymi zpusoby
2. v pythonu je modul vlastne objekt. A objekt je vlastne dict. Nac tedy pouzivat moduly nebo objekty a ztracet se v komplexite kdyz muzu pouzit obycejny dict
Alespon v erlangu je objekt nejaka isolovana vypocetni jednotka (actor, agent, proces, vlakno, apod.) a ne pouze obycejny dict v prestrojeni.
Tohle už je na mě příliš konkrétní. Chtěl jsem se jen svěřit se zkušeností, že hodně malé "izolované výpočetní jednotky" pak mají často skoro všechno veřejné, protože jsou tak malé, že už v nich není co schovávat.

Pokud je problem ze kolegove nemuzou byt svazani sveraci kazajkou jazyka, jako v pripade chybejicich rozhrani v dynamickych jazycich, pak je to organizacni problem. V dynamickym jazyce bouchne driv nez ve statickym. Co je lepsi, tezko rict. Pro me je lepsi kdyz ten bolak praskne driv nez pozdeji a zacne se resit skutecny problem - spatna organizace lidi.
Tohle mi přijde tak trochu jako argument: nedávejte na školní schodiště zábradlí, ať se dříve ukáže, že máte nevychované žáky. Jako jasně že se místo interface dá napsat lepší komentář. Ale když tam musí být interface, je o problém méně.

Ten clanek o design patternech obsahuje priklady. Vetsina oop patternj jsou proste ochcavka kolem toho, ze jazyk nedokaze napr. posilat funkce. Ted uz je ma i java, tak proc by nekdo vubec tyhle zastarale navrhove vzory pouzival.
Tohle je takovéto: Ve funkcionálních jazycích můžeme podobná očekávání splnit jinak a napíšeme u toho méně znaků. OK. Proč ne. Ale nepřijde mi, že by funkcionální jazyky byly nějaká novinka, co se chystá spasit svět a OOP zastaralé paradigma.
Název: Re:Co si myslíte o OOP?
Přispěvatel: Kit 22. 01. 2019, 12:15:34
Ten clanek o design patternech obsahuje priklady. Vetsina oop patternj jsou proste ochcavka kolem toho, ze jazyk nedokaze napr. posilat funkce. Ted uz je ma i java, tak proc by nekdo vubec tyhle zastarale navrhove vzory pouzival.
Tohle je takovéto: Ve funkcionálních jazycích můžeme podobná očekávání splnit jinak a napíšeme u toho méně znaků. OK. Proč ne. Ale nepřijde mi, že by funkcionální jazyky byly nějaká novinka, co se chystá spasit svět a OOP zastaralé paradigma.

Funkcionální programování propagují zejména programátoři, kteří nepochopili principy OOP. Vždycky mi ukážou blbě napsaný objektový program a začnou mi tvrdit, že takhle programovat nechtějí. Já také ne. Nad každým objektem je třeba se zamyslet tak, aby nebyl kuchařskou knihou nebo spíží, ale kuchařem.

Funkcionální programování však nepovažuji za špatné - je jen jiné. Dá se skvěle kombinovat s objektovým - zejména v jazycích, které podporují obojí.
Název: Re:Co si myslíte o OOP?
Přispěvatel: v 22. 01. 2019, 13:33:49
Ten clanek o design patternech obsahuje priklady. Vetsina oop patternj jsou proste ochcavka kolem toho, ze jazyk nedokaze napr. posilat funkce. Ted uz je ma i java, tak proc by nekdo vubec tyhle zastarale navrhove vzory pouzival.
Tohle je takovéto: Ve funkcionálních jazycích můžeme podobná očekávání splnit jinak a napíšeme u toho méně znaků. OK. Proč ne. Ale nepřijde mi, že by funkcionální jazyky byly nějaká novinka, co se chystá spasit svět a OOP zastaralé paradigma.

Funkcionální programování propagují zejména programátoři, kteří nepochopili principy OOP. Vždycky mi ukážou blbě napsaný objektový program a začnou mi tvrdit, že takhle programovat nechtějí. Já také ne. Nad každým objektem je třeba se zamyslet tak, aby nebyl kuchařskou knihou nebo spíží, ale kuchařem.

Funkcionální programování však nepovažuji za špatné - je jen jiné. Dá se skvěle kombinovat s objektovým - zejména v jazycích, které podporují obojí.
zkuste častěji ukazovat příklady dobře napsaných OO programů
Název: Re:Co si myslíte o OOP?
Přispěvatel: Ondra Satai Nekola 22. 01. 2019, 14:04:34
Ten clanek o design patternech obsahuje priklady. Vetsina oop patternj jsou proste ochcavka kolem toho, ze jazyk nedokaze napr. posilat funkce. Ted uz je ma i java, tak proc by nekdo vubec tyhle zastarale navrhove vzory pouzival.
Tohle je takovéto: Ve funkcionálních jazycích můžeme podobná očekávání splnit jinak a napíšeme u toho méně znaků. OK. Proč ne. Ale nepřijde mi, že by funkcionální jazyky byly nějaká novinka, co se chystá spasit svět a OOP zastaralé paradigma.

Funkcionální programování propagují zejména programátoři, kteří nepochopili principy OOP. Vždycky mi ukážou blbě napsaný objektový program a začnou mi tvrdit, že takhle programovat nechtějí. Já také ne. Nad každým objektem je třeba se zamyslet tak, aby nebyl kuchařskou knihou nebo spíží, ale kuchařem.

Funkcionální programování však nepovažuji za špatné - je jen jiné. Dá se skvěle kombinovat s objektovým - zejména v jazycích, které podporují obojí.
zkuste častěji ukazovat příklady dobře napsaných OO programů


Jo.... Kit by nam mohl konecne neco ukazat ;)
Název: Re:Co si myslíte o OOP?
Přispěvatel: Kadet 22. 01. 2019, 14:18:52
Ten clanek o design patternech obsahuje priklady. Vetsina oop patternj jsou proste ochcavka kolem toho, ze jazyk nedokaze napr. posilat funkce. Ted uz je ma i java, tak proc by nekdo vubec tyhle zastarale navrhove vzory pouzival.
Tohle je takovéto: Ve funkcionálních jazycích můžeme podobná očekávání splnit jinak a napíšeme u toho méně znaků. OK. Proč ne. Ale nepřijde mi, že by funkcionální jazyky byly nějaká novinka, co se chystá spasit svět a OOP zastaralé paradigma.

Funkcionální programování propagují zejména programátoři, kteří nepochopili principy OOP. Vždycky mi ukážou blbě napsaný objektový program a začnou mi tvrdit, že takhle programovat nechtějí. Já také ne. Nad každým objektem je třeba se zamyslet tak, aby nebyl kuchařskou knihou nebo spíží, ale kuchařem.

Funkcionální programování však nepovažuji za špatné - je jen jiné. Dá se skvěle kombinovat s objektovým - zejména v jazycích, které podporují obojí.

Problem je mozna v tom, ze OOP neni programovaci paradigma, ale vypocetni model. Podobny Petriho sitim. System, kde si mnozina objektu posila zpravy, muzu naimplementovat v cemkoliv. Muzu k tomu pouzit dokonce i C++ nebo Javu, tedy jazyky s dvoji koncepci modulu, tj. modul a trida.


The AlanKay definition of OO is largely that given by CarlHewitt for the ActorsModel which is a model of computation, not a programming paradigm. AlanKay has acknowledged explicitly this derivation.

http://wiki.c2.com/?AlanKaysDefinitionOfObjectOriented
Název: Re:Co si myslíte o OOP?
Přispěvatel: Kadet 22. 01. 2019, 14:30:55
Moduly a objekty mi pripadaji jako totez. Tj. nejaka skupina funkci (plus pripadne nejaky stav). Ze je to totez je videt na prikladech
1. zapouzdreni se resi u obou a stejnymi zpusoby
2. v pythonu je modul vlastne objekt. A objekt je vlastne dict. Nac tedy pouzivat moduly nebo objekty a ztracet se v komplexite kdyz muzu pouzit obycejny dict
Alespon v erlangu je objekt nejaka isolovana vypocetni jednotka (actor, agent, proces, vlakno, apod.) a ne pouze obycejny dict v prestrojeni.
Tohle už je na mě příliš konkrétní. Chtěl jsem se jen svěřit se zkušeností, že hodně malé "izolované výpočetní jednotky" pak mají často skoro všechno veřejné, protože jsou tak malé, že už v nich není co schovávat.

Pokud je problem ze kolegove nemuzou byt svazani sveraci kazajkou jazyka, jako v pripade chybejicich rozhrani v dynamickych jazycich, pak je to organizacni problem. V dynamickym jazyce bouchne driv nez ve statickym. Co je lepsi, tezko rict. Pro me je lepsi kdyz ten bolak praskne driv nez pozdeji a zacne se resit skutecny problem - spatna organizace lidi.
Tohle mi přijde tak trochu jako argument: nedávejte na školní schodiště zábradlí, ať se dříve ukáže, že máte nevychované žáky. Jako jasně že se místo interface dá napsat lepší komentář. Ale když tam musí být interface, je o problém méně.

Ten clanek o design patternech obsahuje priklady. Vetsina oop patternj jsou proste ochcavka kolem toho, ze jazyk nedokaze napr. posilat funkce. Ted uz je ma i java, tak proc by nekdo vubec tyhle zastarale navrhove vzory pouzival.
Tohle je takovéto: Ve funkcionálních jazycích můžeme podobná očekávání splnit jinak a napíšeme u toho méně znaků. OK. Proč ne. Ale nepřijde mi, že by funkcionální jazyky byly nějaká novinka, co se chystá spasit svět a OOP zastaralé paradigma.

Nejak nechapu tu neustalou potrebu v OO neco schovavat. Resit co bude schovane a co verejne. Ja radsi resim zadani problemu.

Zabradli a zaci. Pokud bychom zili v systemu, kde jsou zaci lehce nahraditelni, pak by to bylo skutecne dobre reseni. V nasem svete ale zaci nejsou lehce nahraditelni. V nasem svete ale jsou programy lehce nahraditelne. Alespon v nekterych organizacich. Zacal bych se divat na zdroj problemu zde.

funkcionalni vs objektove jazyky. Zmin jsem to v prispevku pred. OO jako simulace, objekty posilajici si zpravy, je vypocetni model, ne zpusob programovani. OO jako modularni programovani (java,C++) tj. vsemozne zapouzdrovani, zavislosti mezi moduly (dedicnost), mi prijde jako prekomplikovane imperativni a funkcionalni programovani v jednom. Napr. Trida neni nic jineho nez mnozina nekolika funkci.
Název: Re:Co si myslíte o OOP?
Přispěvatel: Dor 22. 01. 2019, 15:32:40
Nejak nechapu tu neustalou potrebu v OO neco schovavat. Resit co bude schovane a co verejne. Ja radsi resim zadani problemu.
Modifikátory přístupu (public, protected, private) považuji za takový lepší komentář, který je mi připomínán i překladačem.

Zabradli a zaci. Pokud bychom zili v systemu, kde jsou zaci lehce nahraditelni, pak by to bylo skutecne dobre reseni. V nasem svete ale zaci nejsou lehce nahraditelni. V nasem svete ale jsou programy lehce nahraditelne. Alespon v nekterych organizacich. Zacal bych se divat na zdroj problemu zde.
Zas až takový darvinista nejsem. Nahraditelnost softwaru je docela dobře vyjádřena jeho cenou.

funkcionalni vs objektove jazyky. Zmin jsem to v prispevku pred. OO jako simulace, objekty posilajici si zpravy, je vypocetni model, ne zpusob programovani. OO jako modularni programovani (java,C++) tj. vsemozne zapouzdrovani, zavislosti mezi moduly (dedicnost), mi prijde jako prekomplikovane imperativni a funkcionalni programovani v jednom. Napr. Trida neni nic jineho nez mnozina nekolika funkci.
Jádro našeho "sporu" je možná právě v tom, že ty počítáš každý konstrukt, který nemusíš napsat a já naopak počítám každý konstrukt, který napsat můžu. Samozřejmě že si můžu pamatovat, že tyhle 3 funkce jsou na sobě závislé a že má smysl volat jen tu jednu, protože ty zbylé dvě té první jen pomáhají a pro nic jiného nejsou použitelné. Nebo to můžu napsat do komentáře. Nebo můžu použít prefixy v názvu. Nebo to můžu zavřít do třídy a pomocí public označit tu metodu, kterou má smysl volat. A pak k tomu může přijít i Ind, který neumí slovo anglicky a na první pokus se trefí. No a nebo můžu hrdě tvrdit, že žádnýho pologramotnýho Inda do svého masterpiece kódu nepustím a hledat na pracovním trhu jenom samé guru s 200k platem.
Název: Re:Co si myslíte o OOP?
Přispěvatel: BoneFlute 22. 01. 2019, 16:17:46
Moduly a objekty mi pripadaji jako totez. Tj. nejaka skupina funkci (plus pripadne nejaky stav). Ze je to totez je videt na prikladech
1. zapouzdreni se resi u obou a stejnymi zpusoby
2. v pythonu je modul vlastne objekt. A objekt je vlastne dict. Nac tedy pouzivat moduly nebo objekty a ztracet se v komplexite kdyz muzu pouzit obycejny dict
Modul je reprezentace souboru. Objekt je v pythonu vsechno. Mozna mas na mysli tridy. Ty maji dedicnost, funguji jako uzivatelske datove typy a podobne vychytavky. Jak bys to implementoval jen pomoci slovniku?

Jo, ale misto toho, abych zavadel zbytecne koncepty trida, objekt a modul, muzu pouzit proste jen dict.

Dedicnost muzes v dictu naimplementovat jednoduse. Prolinkujes par dictu dohromady a kdyz hledas konkretni metodu/odpoved na prichazejici zpravu projedes ten seznam dictu dokud nenajdes tu funkci.

[dict1, dict2, dict3]

ekvivalentni

class C: pass
class B(C): pass
class A(B): pass

kde A odpovida dict1, B dict2, C dict3

Kdybys implementoval novej jazyk tak udelas nejpravdepodobneji prave tohle.
Tim ale neimplementujes dedicnost v dictu, a dedicnost pomoci seznamu dictu a kodu, ktery to osetri, pricemz seznam je zase jen nadstavba nad dictem. Jestli tim chces rict, ze dokazes pomoci dictu emulovat chovani trid, tak asi ano, ale budes k tomu potrebovat slozity kod, c3 linearizaci a bude to tezkopadne na pouzivani. A v tom spociva smysl trid, modulu atd. Je to abstrakce, ktera ti zjednodusi a zprehledni programovy kod. Pokud to nepotrebujes, muzes zkusit programovat primo ve strojovem kodu. Pak imho prehodnotis nazor a zjistis, ze abstraktni prvky/pojmy komplexitu programu snizuji, nikoliv zvysuji.

Dict se v pythonu pouziva na implementaci objektu, a protoze vsechno je v pythonu objekt, muzeme rict, ze dict je soucasti vseho, je to zakladni datova struktura Pythonu, proto taky na vsechno funguje dir(). Ale neznamena, ze kdyz to pouziva dict, tak muzeme rikat, ze je to dict a nic jineho nepotrebujeme. Protoze s takovou muzeme jit hloub a prohlasit, ze vsechno je jen cislo, resp. organizovany seznam jednicek a nul, cimz jsme zpatky u strojoveho kodu.

javascript donedávna neměl ani třídy ani moduly a nechyběly. Byly přidány hlavně z marketingových důvodů. Vše bylo objekt/slovník. Stále je, nová syntax je jen nadbytečný cukr.
To s tím Javascriptem je docela dobrá paralela. Protože díky tomu, že Javascript neměl žádný zvláštní cukr na vytváření objektů, vzniklo pár zajímavejch článků na toto téma. Díky tomu (a taky proto, že jsem si to zkusil :-) ) je mi jasné, že v tom Pythonu je objekt opravdu jen převlečený slovník. S jednou výjimkou. Ta výjimka souvisí s dědičností a s dynamičností Pythonu - že můžeš už vytvořenému objektu přidat metodu tak, že přidáš metodu do jeho předka. A vzhledem k tomu, že něco takového opravdu, ale opravdu nechci, tak se mi to scvrkne na "objekt = dict".
Název: Re:Co si myslíte o OOP?
Přispěvatel: Dor 22. 01. 2019, 17:21:06
javascript donedávna neměl ani třídy ani moduly a nechyběly. Byly přidány hlavně z marketingových důvodů. Vše bylo objekt/slovník. Stále je, nová syntax je jen nadbytečný cukr.
Platí tedy i věta, že require, který načítá modul, byl přidán z marketingových důvodů a je to jen nadbytečný syntax sugar? A ty "marketingové důvody" znamenají, "Chceme aby to používalo více lidí, kteří nevědí, co je pro ně dobré."? Já jen aby to zaznělo pěkně naplno.
Název: Re:Co si myslíte o OOP?
Přispěvatel: gll 22. 01. 2019, 17:27:23
javascript donedávna neměl ani třídy ani moduly a nechyběly. Byly přidány hlavně z marketingových důvodů. Vše bylo objekt/slovník. Stále je, nová syntax je jen nadbytečný cukr.
Platí tedy i věta, že require, který načítá modul, byl přidán z marketingových důvodů a je to jen nadbytečný syntax sugar? A ty "marketingové důvody" znamenají, "Chceme aby to používalo více lidí, kteří nevědí, co je pro ně dobré."? Já jen aby to zaznělo pěkně naplno.

ES6 moduly a importy. Require není jazykový konstrukt, to je jen obyčejná funkce.
Název: Re:Co si myslíte o OOP?
Přispěvatel: Kadet 22. 01. 2019, 17:31:29
javascript donedávna neměl ani třídy ani moduly a nechyběly. Byly přidány hlavně z marketingových důvodů. Vše bylo objekt/slovník. Stále je, nová syntax je jen nadbytečný cukr.
Platí tedy i věta, že require, který načítá modul, byl přidán z marketingových důvodů a je to jen nadbytečný syntax sugar? A ty "marketingové důvody" znamenají, "Chceme aby to používalo více lidí, kteří nevědí, co je pro ně dobré."? Já jen aby to zaznělo pěkně naplno.

Nevim jak vypada implementace require. Ale prislo mi, ze je to jen funkce. A javascript uz koncept funkce ma, takze nic nemuzel pridavat. Kdyby museli upravit jazyk kvuli necemu, co jde implementovat pouhou funkci, pak ano, bylo by to pridani nadbytecneho cukru.

Marketingove dduvody, aby to pouzivalo vic lidi, jsou dost presne vyjadreni situace. Javascript mel prototypy vychazejici ze Selfu. To je presne co tady popisuju. Prolinkovany dicty. Nic vic. Nekdo ted pridal cukr na classy. Proc? Za me je odpoved marketing.
Název: Re:Co si myslíte o OOP?
Přispěvatel: Kadet 22. 01. 2019, 17:34:32
Nejak nechapu tu neustalou potrebu v OO neco schovavat. Resit co bude schovane a co verejne. Ja radsi resim zadani problemu.
Modifikátory přístupu (public, protected, private) považuji za takový lepší komentář, který je mi připomínán i překladačem.

Zabradli a zaci. Pokud bychom zili v systemu, kde jsou zaci lehce nahraditelni, pak by to bylo skutecne dobre reseni. V nasem svete ale zaci nejsou lehce nahraditelni. V nasem svete ale jsou programy lehce nahraditelne. Alespon v nekterych organizacich. Zacal bych se divat na zdroj problemu zde.
Zas až takový darvinista nejsem. Nahraditelnost softwaru je docela dobře vyjádřena jeho cenou.

funkcionalni vs objektove jazyky. Zmin jsem to v prispevku pred. OO jako simulace, objekty posilajici si zpravy, je vypocetni model, ne zpusob programovani. OO jako modularni programovani (java,C++) tj. vsemozne zapouzdrovani, zavislosti mezi moduly (dedicnost), mi prijde jako prekomplikovane imperativni a funkcionalni programovani v jednom. Napr. Trida neni nic jineho nez mnozina nekolika funkci.
Jádro našeho "sporu" je možná právě v tom, že ty počítáš každý konstrukt, který nemusíš napsat a já naopak počítám každý konstrukt, který napsat můžu. Samozřejmě že si můžu pamatovat, že tyhle 3 funkce jsou na sobě závislé a že má smysl volat jen tu jednu, protože ty zbylé dvě té první jen pomáhají a pro nic jiného nejsou použitelné. Nebo to můžu napsat do komentáře. Nebo můžu použít prefixy v názvu. Nebo to můžu zavřít do třídy a pomocí public označit tu metodu, kterou má smysl volat. A pak k tomu může přijít i Ind, který neumí slovo anglicky a na první pokus se trefí. No a nebo můžu hrdě tvrdit, že žádnýho pologramotnýho Inda do svého masterpiece kódu nepustím a hledat na pracovním trhu jenom samé guru s 200k platem.

Popravde se v tom ztracim. Ani se nedivim, kdyz existuje tolik ruznych konceptu, ktery jsou vlastne jedna stejna vec.

Tridy = moduly. Inda nepustim do svyho kodu tak, ze mu hodim nektery funkce private v modulu kam nema sahat. Nepotrebuju k tomu N konceptu, kazdej pripominajici modul a umoznujici skryvani atributu.
Název: Re:Co si myslíte o OOP?
Přispěvatel: Dor 22. 01. 2019, 18:03:48
Citace: Kadet
Nejak nechapu tu neustalou potrebu v OO neco schovavat. Resit co bude schovane a co verejne. Ja radsi resim zadani problemu.

Citace: Kadet
Tridy = moduly. Inda nepustim do svyho kodu tak, ze mu hodim nektery funkce private v modulu kam nema sahat. Nepotrebuju k tomu N konceptu, kazdej pripominajici modul a umoznujici skryvani atributu.

Takže ta potřeba "schovávat" asi není zase tak nepochopitelná.

Jinak asi nikdo nepotřebuje N konceptů. Každému stačí ten jeden, který zrovna on používá.

Jestli skrývat kromě metod i atributy nebo nechávat atributy veřejné, do toho už se pouštět nechci. To strašně záleží na případu použití i na tom, jak to má jaký jazyk zrovna řešeno a návrh to imho nijak zvlášť neovlivňuje. Ale já to mám rád, když můžu některé atributy označit jako private, kvůli lepší čitelnosti kódu. Samozřejmě když má třída/modul desítky privátních atributů, tak v tom návrhu nejspíše něco smrdí.
Název: Re:Co si myslíte o OOP?
Přispěvatel: gll 22. 01. 2019, 18:09:15
To s tím Javascriptem je docela dobrá paralela. Protože díky tomu, že Javascript neměl žádný zvláštní cukr na vytváření objektů, vzniklo pár zajímavejch článků na toto téma. Díky tomu (a taky proto, že jsem si to zkusil :-) ) je mi jasné, že v tom Pythonu je objekt opravdu jen převlečený slovník.

slovník je defaultní reprezentace, ale existují  __slots__, namedtuple, recordclasses, atd. Kde můžu používám knihovnu attrs, se slots=True.

S jednou výjimkou. Ta výjimka souvisí s dědičností a s dynamičností Pythonu - že můžeš už vytvořenému objektu přidat metodu tak, že přidáš metodu do jeho předka. A vzhledem k tomu, že něco takového opravdu, ale opravdu nechci, tak se mi to scvrkne na "objekt = dict".

to v Pythonu nejde. To si asi pleteš s Javascriptem.
Název: Re:Co si myslíte o OOP?
Přispěvatel: Kit 22. 01. 2019, 18:51:11
Stejně nechápu, proč většina jazyků má v návrhu slovo "private". Privátní by mělo být defaultně všechno. Jen ty komponenty, které chci mít veřejné, označím "public" nebo "protected".

Mezi object a dict bývá jeden významný rozdíl: Object se předává odkazem, ale dict hodnotou. Platí to například v PHP.
Název: Re:Co si myslíte o OOP?
Přispěvatel: Kadet 22. 01. 2019, 19:00:38
Citace: Kadet
Nejak nechapu tu neustalou potrebu v OO neco schovavat. Resit co bude schovane a co verejne. Ja radsi resim zadani problemu.

Citace: Kadet
Tridy = moduly. Inda nepustim do svyho kodu tak, ze mu hodim nektery funkce private v modulu kam nema sahat. Nepotrebuju k tomu N konceptu, kazdej pripominajici modul a umoznujici skryvani atributu.

Takže ta potřeba "schovávat" asi není zase tak nepochopitelná.

Jinak asi nikdo nepotřebuje N konceptů. Každému stačí ten jeden, který zrovna on používá.

Jestli skrývat kromě metod i atributy nebo nechávat atributy veřejné, do toho už se pouštět nechci. To strašně záleží na případu použití i na tom, jak to má jaký jazyk zrovna řešeno a návrh to imho nijak zvlášť neovlivňuje. Ale já to mám rád, když můžu některé atributy označit jako private, kvůli lepší čitelnosti kódu. Samozřejmě když má třída/modul desítky privátních atributů, tak v tom návrhu nejspíše něco smrdí.

Ja chapu potrebu schovavat. Akorat debaty o OO navrhu zacinaji tim, co schovat, zapouzdrit a zdedit, nez tim, co je vysledkem vyreseni problemu.

Kdyz jsi sam, kdo pouziva program, tak je fajn, ze si muzes vybrat tridu nebo modul nebo package nebo cokoliv k tomu ucelu. Jenze kdyz pracujes s indem, tak on si vybere jedno a ty druhy. Ja bych na to mel radsi jen jeden koncept.

V Selfu zjistili, ze je lepsi povazovat atribut stejne jako metodu. Jinak jestli se nekdo rozhoduje, jestli schovat nebo ne podle toho, co mu umoznuje jazyk, pak je otazka, jestli nema prilis svazujici jazyk.
Název: Re:Co si myslíte o OOP?
Přispěvatel: Kadet 22. 01. 2019, 19:04:12
Stejně nechápu, proč většina jazyků má v návrhu slovo "private". Privátní by mělo být defaultně všechno. Jen ty komponenty, které chci mít veřejné, označím "public" nebo "protected".

Mezi object a dict bývá jeden významný rozdíl: Object se předává odkazem, ale dict hodnotou. Platí to například v PHP.

Jestli nechat defaultne private nebo public je otazka jestli pracuju v prototypovacim nebo produkcnim modu.

Je vlastnosti 'zpusob predani' nejaka vnitrni vlastnost objektu nebo dictu? Jinymi slovy, dict nelze predat jako odkaz a objekt nelze predat hodnotou?
Název: Re:Co si myslíte o OOP?
Přispěvatel: Kit 22. 01. 2019, 19:27:35
Stejně nechápu, proč většina jazyků má v návrhu slovo "private". Privátní by mělo být defaultně všechno. Jen ty komponenty, které chci mít veřejné, označím "public" nebo "protected".

Mezi object a dict bývá jeden významný rozdíl: Object se předává odkazem, ale dict hodnotou. Platí to například v PHP.

Jestli nechat defaultne private nebo public je otazka jestli pracuju v prototypovacim nebo produkcnim modu.

Je vlastnosti 'zpusob predani' nejaka vnitrni vlastnost objektu nebo dictu? Jinymi slovy, dict nelze predat jako odkaz a objekt nelze predat hodnotou?

Public by nechyběl ani v prototypovém módu. Není mnoho komponent, které potřebuji sdílet - obvykle to jsou jen 2-3 metody.

Dict se v PHP dá předat odkazem, ale nedoporučuje se to. Podobně i object se dá naklonovat a tedy předat hodnotou. Jenže obvykle použiji právě takový typ, se kterým mohu pracovat nativně.
Název: Re:Co si myslíte o OOP?
Přispěvatel: BoneFlute 23. 01. 2019, 03:39:36
S jednou výjimkou. Ta výjimka souvisí s dědičností a s dynamičností Pythonu - že můžeš už vytvořenému objektu přidat metodu tak, že přidáš metodu do jeho předka. A vzhledem k tomu, že něco takového opravdu, ale opravdu nechci, tak se mi to scvrkne na "objekt = dict".

to v Pythonu nejde. To si asi pleteš s Javascriptem.
Ty jo, zaváhal jsem, ale:
Kód: [Vybrat]

class A:
pass

class B (A):
def boo(self):
return 'B'

def goo(self):
return 'C'

b = B()
print(dir(b))
A.goo = goo
print(dir(b))
print b.goo
print b.goo()
Název: Re:Co si myslíte o OOP?
Přispěvatel: operator 23. 01. 2019, 05:51:35
To s tím Javascriptem je docela dobrá paralela. Protože díky tomu, že Javascript neměl žádný zvláštní cukr na vytváření objektů, vzniklo pár zajímavejch článků na toto téma. Díky tomu (a taky proto, že jsem si to zkusil :-) ) je mi jasné, že v tom Pythonu je objekt opravdu jen převlečený slovník.

slovník je defaultní reprezentace, ale existují  __slots__, namedtuple, recordclasses, atd. Kde můžu používám knihovnu attrs, se slots=True.

S jednou výjimkou. Ta výjimka souvisí s dědičností a s dynamičností Pythonu - že můžeš už vytvořenému objektu přidat metodu tak, že přidáš metodu do jeho předka. A vzhledem k tomu, že něco takového opravdu, ale opravdu nechci, tak se mi to scvrkne na "objekt = dict".

to v Pythonu nejde. To si asi pleteš s Javascriptem.
Proc by to nemelo jit, objekty lze dynamicky modifikovat. Jde nejen pridat, ale i z(a)menit. Podívej se také na bound a unbound methods.
Název: Re:Co si myslíte o OOP?
Přispěvatel: operator 23. 01. 2019, 06:10:59
Asi bych nemluvil o urovni, ale jinak ano, presne to je cil, zjednoduseni programoveho kodu. Krome toho se take zvysi efetivita tvorby programu.
Class v Javascriptu nic nezjednodušuje. Kód nezkracuje. Je to jen omáčka navíc.
Ta omacka navic je zadana, takze evidentne neco zjednodusuje. Minimalne pochopeni jazyka pro nektere programatory. Imho je to vyhodne i pro jednodussi a prehlednejsi objektovy navrh programu. Prototypova dedicnost je dobra pro DOM, tedy kdyz chces pracovat s rozsahlou a bohatou kolekci uz existujicich kolekci. Ale neni dobra, kdyz podobnou strukturu nechces jen pouzivat, ale chces ji navrhnout sam.
Název: Re:Co si myslíte o OOP?
Přispěvatel: operator 23. 01. 2019, 06:19:38
javascript donedávna neměl ani třídy ani moduly a nechyběly. Byly přidány hlavně z marketingových důvodů. Vše bylo objekt/slovník. Stále je, nová syntax je jen nadbytečný cukr.
Platí tedy i věta, že require, který načítá modul, byl přidán z marketingových důvodů a je to jen nadbytečný syntax sugar? A ty "marketingové důvody" znamenají, "Chceme aby to používalo více lidí, kteří nevědí, co je pro ně dobré."? Já jen aby to zaznělo pěkně naplno.

Nevim jak vypada implementace require. Ale prislo mi, ze je to jen funkce. A javascript uz koncept funkce ma, takze nic nemuzel pridavat. Kdyby museli upravit jazyk kvuli necemu, co jde implementovat pouhou funkci, pak ano, bylo by to pridani nadbytecneho cukru.

Marketingove dduvody, aby to pouzivalo vic lidi, jsou dost presne vyjadreni situace. Javascript mel prototypy vychazejici ze Selfu. To je presne co tady popisuju. Prolinkovany dicty. Nic vic. Nekdo ted pridal cukr na classy. Proc? Za me je odpoved marketing.

Pouzivas pojem marketing jako sproste slovo, ale marketing je o uspokojovani potreb. Protoze marketing == protoze to je velmi zadana vlastnost.

Syntakticky cukr neni nadbytecny. Syntakticky cukr zjednodusuje pouzivani jazyka, umoznuje psat kratsi, jednodusi, pochopitelnejsi a prehlednejsi kod. Take to muze umoznit rychlejsi beh programu.
Název: Re:Co si myslíte o OOP?
Přispěvatel: operator 23. 01. 2019, 06:31:46
Ja chapu potrebu schovavat. Akorat debaty o OO navrhu zacinaji tim, co schovat, zapouzdrit a zdedit, nez tim, co je vysledkem vyreseni problemu.

Kdyz jsi sam, kdo pouziva program, tak je fajn, ze si muzes vybrat tridu nebo modul nebo package nebo cokoliv k tomu ucelu. Jenze kdyz pracujes s indem, tak on si vybere jedno a ty druhy. Ja bych na to mel radsi jen jeden koncept.

V Selfu zjistili, ze je lepsi povazovat atribut stejne jako metodu. Jinak jestli se nekdo rozhoduje, jestli schovat nebo ne podle toho, co mu umoznuje jazyk, pak je otazka, jestli nema prilis svazujici jazyk.

Uvedomujes si, ze si protirecis?

Vadi ti syntakticky cukr a zaroven ti vadi, ze ind si vybere modul nebo tridu. Kdyz budes mit jazyk, kde si budes muset objekty implementovat sam z dictu, tak ten ind je bude zarucene implementovat jinak nez ty a tech moznych implementaci nebude jen trida nebo modul, bude jich prakticky nekonecne mnoho. Modul nebo trida,vto jsou ruzne abstrakce a ma smysl je mit. Ale mit nekonecne mnoho implementaci te same abstrakce, to smysl nedava. To je jeden z duvod, proc v pythonu pouzivas standardizovanou abstrakci class a ne vlastni reseni postavene nad dicty i kdyz muzes. Aby ses jednoduseji domluvil. Vsechno co ti zjednodusuje pouziti jazyka je uzitecne, nikoliv nadbytecne.

Název: Re:Co si myslíte o OOP?
Přispěvatel: Inkvizitor 23. 01. 2019, 09:53:03
Problem je mozna v tom, ze OOP neni programovaci paradigma, ale vypocetni model. Podobny Petriho sitim. System, kde si mnozina objektu posila zpravy, muzu naimplementovat v cemkoliv. Muzu k tomu pouzit dokonce i C++ nebo Javu, tedy jazyky s dvoji koncepci modulu, tj. modul a trida.


The AlanKay definition of OO is largely that given by CarlHewitt for the ActorsModel which is a model of computation, not a programming paradigm. AlanKay has acknowledged explicitly this derivation.

http://wiki.c2.com/?AlanKaysDefinitionOfObjectOriented

Jakkoliv nesouhlasim s nekterymi Tvymi zavery, libi se mi, ze jsi od sebe rozseknul veci, ktere se obycejne spojuji. Moduly+interfacy poskutuji elegantni reseni vetsiny veci, ktere slibuje resit OOP, jak se obycejne chape. Actor je neco (uz to tady nakousnul Mirek), co mi dava smysl jako "oklestene" vnimani objektoveho modelu. Co je opravdu z principu samostatne, necht je objekt. Zalozit celou aplikaci na "posilani zprav" mezi "objekty", to se moc neuchytilo a IMO jsou k tomu dobre duvody.
Název: Re:Co si myslíte o OOP?
Přispěvatel: operator 23. 01. 2019, 10:35:38

To s tím Javascriptem je docela dobrá paralela. Protože díky tomu, že Javascript neměl žádný zvláštní cukr na vytváření objektů, vzniklo pár zajímavejch článků na toto téma. Díky tomu (a taky proto, že jsem si to zkusil :-) ) je mi jasné, že v tom Pythonu je objekt opravdu jen převlečený slovník. S jednou výjimkou. Ta výjimka souvisí s dědičností a s dynamičností Pythonu - že můžeš už vytvořenému objektu přidat metodu tak, že přidáš metodu do jeho předka. A vzhledem k tomu, že něco takového opravdu, ale opravdu nechci, tak se mi to scvrkne na "objekt = dict".

To se ti scvrkava spatne. Dict je object, ale object neni dict. Jedna se o dve ruzne abstrakce, ktere dokonce ani nejsou na stejne urovni.  Objekty pouzivaji dict pro ulozeni interniho stavu, ale to neznamena, ze se sobe rovnaji.
Lisi se nejen svou abstrakci, ale i svou funkcionalitou. Pokud to nechapes, zkus pomoci dictu implementovat tyto objekty 'a', 'b' a 'c'  typu 'A' a 'B' a provest s nimi predvedene operace.

Porovname si pracnost, rychlost a prehlednost vysledku a pak pochopite, nejen ze od dictu k objektu je to hodne daleko, ale i to, ze ten synktaticky cukr je uzitecny a potrebny.

Kód: [Vybrat]
    1 class X():
    2     counter = 5                                                                               
    3
    4     def __init__(self, x=0):
    5         if  self.__class__.counter < 0:
    6             raise RuntimeError('Overflow maximum allowed instances.')
    7         self.__id = self.__class__.counter
    8         self.__class__.counter -= 1
    9         self.__x  = x
   10
   11     @property
-- 12     def x(self):                                                                               
   13         return self.__x
   14
   15     @property
-- 16     def id(self):
   17         return self.__id
   18
   19     def __iadd__(self, val):
   20         self.__x += val
   21         return self
   22
   23     def __add__(self, val):
   24         if  isinstance(val, type(self)):
   25             return self.__class__(val.x + self.__x)
   26         raise TypeError(f"unsupported operand type(s) for +: " + \
   27                         f"'{type(self).__name__}' and '{type(a).__name__}'")
   28
   29     def __repr__(self):
   30         return f'{self.__x} of type: {type(self).__name__} and id: {self.__id}'
   31
-- 32 class A(X):
   33     pass
   34
-- 35 class B(X):
   36     pass
   37
   38 # vytvoreni objektu 'a', 'b' a 'c' a operace s nimi
-- 39 a = A()
-- 40 b = B(7)
   41
   42 print(a.x)    # 0
   43 print(a.id)   # 5
   44 print(a)      # 0 of type: A and id: 5
   45 print(b)      # 7 of type: B and id: 5
   46
   47 a += 10
-- 48 c = a + a
   49 print(c)      # 20 of type: A and id: 4
   50 print(a + c)  # 30 of type: A and id: 3
   51
>> 52 a.id = 1      # AttributeError, zakaz zapisu do atributu
-- 53 a + b         # Type error, secist lze jen objekty stejneho typu
   54 a += a        # Type error, pridat jde jen int hodnota
-- 55
Název: Re:Co si myslíte o OOP?
Přispěvatel: operator 23. 01. 2019, 12:01:12
Problem je mozna v tom, ze OOP neni programovaci paradigma, ale vypocetni model. Podobny Petriho sitim. System, kde si mnozina objektu posila zpravy, muzu naimplementovat v cemkoliv. Muzu k tomu pouzit dokonce i C++ nebo Javu, tedy jazyky s dvoji koncepci modulu, tj. modul a trida.


The AlanKay definition of OO is largely that given by CarlHewitt for the ActorsModel which is a model of computation, not a programming paradigm. AlanKay has acknowledged explicitly this derivation.

http://wiki.c2.com/?AlanKaysDefinitionOfObjectOriented
OOP je programovaci paradigma. Je to abstrakce, ktera ti umoznuje se na program divat/uvazovat jinym zpusobem. To jestli jde nebo nejde simulovat jinymi prostredky je nepodstatne. Pokud reknes, me abstrakce nezajima, pak se muzes vratit ke strojovemu kodu, protoze vsechno ostatni je vice ci mene pokrocila abstrakce nad nim a v nem jde pouzit/udelat vsechno, akorat to bude dost neprehledne.
Název: Re:Co si myslíte o OOP?
Přispěvatel: gll 23. 01. 2019, 12:57:55
S jednou výjimkou. Ta výjimka souvisí s dědičností a s dynamičností Pythonu - že můžeš už vytvořenému objektu přidat metodu tak, že přidáš metodu do jeho předka. A vzhledem k tomu, že něco takového opravdu, ale opravdu nechci, tak se mi to scvrkne na "objekt = dict".

to v Pythonu nejde. To si asi pleteš s Javascriptem.
Ty jo, zaváhal jsem, ale:
Kód: [Vybrat]

class A:
pass

class B (A):
def boo(self):
return 'B'

def goo(self):
return 'C'

b = B()
print(dir(b))
A.goo = goo
print(dir(b))
print b.goo
print b.goo()

máš pravdu. Nejde to jen u vestavěných typů, kde se to občas hodilo.
Název: Re:Co si myslíte o OOP?
Přispěvatel: BoneFlute 23. 01. 2019, 13:33:51
v mém scénáři začnu se strukturovaným AST (podmínky + cykly, fakt strom) a přeložím ho na seznam příkazů se skokama (tohle jsem měl původně na mysli, když jsem psal AST) a tady už jsou cykly kdy se příkaz skoku odkazuje na jiný příkaz ve stejném seznamu

To bude ono. Já tam žádné skoky ani cykly neměl.
Díky.
Název: Re:Co si myslíte o OOP?
Přispěvatel: Kadet 23. 01. 2019, 13:45:33
javascript donedávna neměl ani třídy ani moduly a nechyběly. Byly přidány hlavně z marketingových důvodů. Vše bylo objekt/slovník. Stále je, nová syntax je jen nadbytečný cukr.
Platí tedy i věta, že require, který načítá modul, byl přidán z marketingových důvodů a je to jen nadbytečný syntax sugar? A ty "marketingové důvody" znamenají, "Chceme aby to používalo více lidí, kteří nevědí, co je pro ně dobré."? Já jen aby to zaznělo pěkně naplno.

Nevim jak vypada implementace require. Ale prislo mi, ze je to jen funkce. A javascript uz koncept funkce ma, takze nic nemuzel pridavat. Kdyby museli upravit jazyk kvuli necemu, co jde implementovat pouhou funkci, pak ano, bylo by to pridani nadbytecneho cukru.

Marketingove dduvody, aby to pouzivalo vic lidi, jsou dost presne vyjadreni situace. Javascript mel prototypy vychazejici ze Selfu. To je presne co tady popisuju. Prolinkovany dicty. Nic vic. Nekdo ted pridal cukr na classy. Proc? Za me je odpoved marketing.

Pouzivas pojem marketing jako sproste slovo, ale marketing je o uspokojovani potreb. Protoze marketing == protoze to je velmi zadana vlastnost.

Syntakticky cukr neni nadbytecny. Syntakticky cukr zjednodusuje pouzivani jazyka, umoznuje psat kratsi, jednodusi, pochopitelnejsi a prehlednejsi kod. Take to muze umoznit rychlejsi beh programu.

Sproste slovo.. to zalezi na pohledu pozorovatele. Ja hovorim neutralne pokud mozno.

Syntakticky cukr je tady jako kafe nebo jako droga. Kafe ti umozni zustat vzhuru dele dneska, ale na ukor spanku zitra. Cukr ti umozni pochopit jazyk driv dneska ale na ukor toho, ze kdyz budes chtit udelat neco slozitejsiho, tak to nepujde, protoze jazykove bozstvo rozhodlo, ze se budou pouzivat classy a ne nic jinyho.
Název: Re:Co si myslíte o OOP?
Přispěvatel: Kadet 23. 01. 2019, 13:53:39
Ja chapu potrebu schovavat. Akorat debaty o OO navrhu zacinaji tim, co schovat, zapouzdrit a zdedit, nez tim, co je vysledkem vyreseni problemu.

Kdyz jsi sam, kdo pouziva program, tak je fajn, ze si muzes vybrat tridu nebo modul nebo package nebo cokoliv k tomu ucelu. Jenze kdyz pracujes s indem, tak on si vybere jedno a ty druhy. Ja bych na to mel radsi jen jeden koncept.

V Selfu zjistili, ze je lepsi povazovat atribut stejne jako metodu. Jinak jestli se nekdo rozhoduje, jestli schovat nebo ne podle toho, co mu umoznuje jazyk, pak je otazka, jestli nema prilis svazujici jazyk.

Uvedomujes si, ze si protirecis?

Vadi ti syntakticky cukr a zaroven ti vadi, ze ind si vybere modul nebo tridu. Kdyz budes mit jazyk, kde si budes muset objekty implementovat sam z dictu, tak ten ind je bude zarucene implementovat jinak nez ty a tech moznych implementaci nebude jen trida nebo modul, bude jich prakticky nekonecne mnoho. Modul nebo trida,vto jsou ruzne abstrakce a ma smysl je mit. Ale mit nekonecne mnoho implementaci te same abstrakce, to smysl nedava. To je jeden z duvod, proc v pythonu pouzivas standardizovanou abstrakci class a ne vlastni reseni postavene nad dicty i kdyz muzes. Aby ses jednoduseji domluvil. Vsechno co ti zjednodusuje pouziti jazyka je uzitecne, nikoliv nadbytecne.

Mohl bys mi ukazat konkretni dve teze ve kterych si protirecim?

Ta spoluprace s indem je organizacni problem. Pokud ho nedokazu vyresit na urovni lidi tak me zadna trida nebo modul nespasi jinak pozdrav panbu. Vratim se k moji starsi tezi. Praseci kod a vic lidi co na nem pracuje? Vyres nejdriv problem praseciho kodu nez budes hledat nastroj co omezi ostatni cleny tymu tak aby neudelaly radsi zadnou chyby a taky zadny pokrok.

Ja v pythonu classy ani pokud mozno nepouzivam btw. Pro me je python jen host language pro vytvoreni lepsiho jazyka (embedded dsl), napr. proto ze python ma dobrej ekosystem knihoven.
Název: Re:Co si myslíte o OOP?
Přispěvatel: Kadet 23. 01. 2019, 13:59:10
Problem je mozna v tom, ze OOP neni programovaci paradigma, ale vypocetni model. Podobny Petriho sitim. System, kde si mnozina objektu posila zpravy, muzu naimplementovat v cemkoliv. Muzu k tomu pouzit dokonce i C++ nebo Javu, tedy jazyky s dvoji koncepci modulu, tj. modul a trida.


The AlanKay definition of OO is largely that given by CarlHewitt for the ActorsModel which is a model of computation, not a programming paradigm. AlanKay has acknowledged explicitly this derivation.

http://wiki.c2.com/?AlanKaysDefinitionOfObjectOriented

Jakkoliv nesouhlasim s nekterymi Tvymi zavery, libi se mi, ze jsi od sebe rozseknul veci, ktere se obycejne spojuji. Moduly+interfacy poskutuji elegantni reseni vetsiny veci, ktere slibuje resit OOP, jak se obycejne chape. Actor je neco (uz to tady nakousnul Mirek), co mi dava smysl jako "oklestene" vnimani objektoveho modelu. Co je opravdu z principu samostatne, necht je objekt. Zalozit celou aplikaci na "posilani zprav" mezi "objekty", to se moc neuchytilo a IMO jsou k tomu dobre duvody.

Moje zavery nejsou zavery ale pouze tvrzeni ktera jsou pokud mozno vyvratitelna (falsifiability). Jinak receno jdu s kuzi na trh a usnadnuju vam ostatnim mi moje tvrzeni lehceji vyvratit.

Rad bych aby mi moje tvrzeni lidi zacali rozebirat na padrt a konstruktivne vyvracet. Casto moje 'zavery' zde ale ocividne lidi urazi.

Aplikace postavena na posilani zprav. To je pohled na vec, ne vec implementace. Kdyz mam distribuovany system z vic pocitacu, tak mi nezbyde nez mezi nimi skutecne poslat pres sit nejakou zpravu. Kdyz se podivam dovnitr jedny masiny nebo dovnitr konkretniho programu, muzu rict, ze zavolani metody je taky poslani zpravy.
Název: Re:Co si myslíte o OOP?
Přispěvatel: Kadet 23. 01. 2019, 14:04:04
Problem je mozna v tom, ze OOP neni programovaci paradigma, ale vypocetni model. Podobny Petriho sitim. System, kde si mnozina objektu posila zpravy, muzu naimplementovat v cemkoliv. Muzu k tomu pouzit dokonce i C++ nebo Javu, tedy jazyky s dvoji koncepci modulu, tj. modul a trida.


The AlanKay definition of OO is largely that given by CarlHewitt for the ActorsModel which is a model of computation, not a programming paradigm. AlanKay has acknowledged explicitly this derivation.

http://wiki.c2.com/?AlanKaysDefinitionOfObjectOriented
OOP je programovaci paradigma. Je to abstrakce, ktera ti umoznuje se na program divat/uvazovat jinym zpusobem. To jestli jde nebo nejde simulovat jinymi prostredky je nepodstatne. Pokud reknes, me abstrakce nezajima, pak se muzes vratit ke strojovemu kodu, protoze vsechno ostatni je vice ci mene pokrocila abstrakce nad nim a v nem jde pouzit/udelat vsechno, akorat to bude dost neprehledne.

Ja jsem nekde rek, ze me nezajima abstrakce?

Kdyz jsme u strojoveho kodu. Kod 'nizke urovne abstrakce' a strojovy kod moderniho cpu pripominaji uz spis python nebo neco vysokourovnovyho.

https://queue.acm.org/detail.cfm?id=3212479
Název: Re:Co si myslíte o OOP?
Přispěvatel: operator 23. 01. 2019, 14:13:58
Sproste slovo.. to zalezi na pohledu pozorovatele. Ja hovorim neutralne pokud mozno.

Syntakticky cukr je tady jako kafe nebo jako droga. Kafe ti umozni zustat vzhuru dele dneska, ale na ukor spanku zitra. Cukr ti umozni pochopit jazyk driv dneska ale na ukor toho, ze kdyz budes chtit udelat neco slozitejsiho, tak to nepujde, protoze jazykove bozstvo rozhodlo, ze se budou pouzivat classy a ne nic jinyho.
Marketing je pozitivni, jeho smyslem je efektivne investovat zdroje. V pripade jazyka by tedy mel vest k vyvoji smerem, po kterem je nejvetsi poptavka, ktery ten jazyk nejlepe zhodnoti. Pokud je to jinak, neni to kvuli marketingu, ale jeho absenci. V lepsim pripade jsou zdroje promarneny, v horsim to jazyk pokazi a bude opusten.

Syntakticky cukr neni ani jako kafe ani jako cukr. Ani jedno neni zavedeni zjednodusujici abstrakce, ani jedno z toho nesnizuje slozitost systemu. Python neni Haskell, tam ti zadne bozstvo neprikazalo pouzivat classy a nic jineho. A u toho Haskelluv tu bezela teze, ze jeho striktni funkcionalita a nic jineho je pro tve blaho, protoze te to donuti ji pouzivat a pochopit. S cimz se osobne neztotoznuji, ja jsem zastance flexibility a co mozna nejsirsich prostredku k vyjadreni.
Název: Re:Co si myslíte o OOP?
Přispěvatel: Inkvizitor 23. 01. 2019, 14:17:08
Moje zavery nejsou zavery ale pouze tvrzeni ktera jsou pokud mozno vyvratitelna (falsifiability). Jinak receno jdu s kuzi na trh a usnadnuju vam ostatnim mi moje tvrzeni lehceji vyvratit.

Rad bych aby mi moje tvrzeni lidi zacali rozebirat na padrt a konstruktivne vyvracet. Casto moje 'zavery' zde ale ocividne lidi urazi.

Aplikace postavena na posilani zprav. To je pohled na vec, ne vec implementace. Kdyz mam distribuovany system z vic pocitacu, tak mi nezbyde nez mezi nimi skutecne poslat pres sit nejakou zpravu. Kdyz se podivam dovnitr jedny masiny nebo dovnitr konkretniho programu, muzu rict, ze zavolani metody je taky poslani zpravy.

No jak mam polemizovat s tim, ze objekt je dict a trida zbytecny syntakticky cukr? Jako zjednoduseni to nejaky smysl dava, prehlednou syntaxi mam vysoko v osobnich prioritach, proc se o to hadat v situaci, kdy je Tvuj nazor dost minoritni a vyvoj jde jinudy (podobne v kauze prototypy, kde Self a spol. evolucne prohravaji).

Zpravu ja si predstavuju ve smyslu pozdni vazby - mam nejaky dohodnuty protokol a pres obecny komunikacni kanal poslu zpravu a doufam, ze ji prijemce porozumi. Volani funkce v situaci, kdy mi to validuje kompilator nebo linter, je trosku neco jineho. Nemam potrebu se na to divat jako na komunikaci autonomnich objektu, protoze funkcim vidim pod prsty. Predstavovat si to muzeme ruzne, o tom zadna.
Název: Re:Co si myslíte o OOP?
Přispěvatel: operator 23. 01. 2019, 14:29:24
Ja jsem nekde rek, ze me nezajima abstrakce?

Kdyz jsme u strojoveho kodu. Kod 'nizke urovne abstrakce' a strojovy kod moderniho cpu pripominaji uz spis python nebo neco vysokourovnovyho.
Doslova, ne, ale neprimo jo. Tebou neustale odmitany syntakticky cukr neni nic jineho, nez implementace vyssi abstrakce do jazyka. Zajima te to?

Ja nevim, jestli si nepletes pojmy. Strojovy kod je rada cisel v pameti. At je instrukce sebepokrocilejsi, porad je to z hlediska kodu jen cislo v pameti. Cim ti to pripomina kod Pythonu? Muzes mi nasledujici priklad prepsat do strojoveho kodu moderniho procesoru?
Citace
import sys
print(sys.argv[::2])
Název: Re:Co si myslíte o OOP?
Přispěvatel: v 23. 01. 2019, 14:29:56
A u toho Haskelluv tu bezela teze, ze jeho striktni funkcionalita a nic jineho je pro tve blaho, protoze te to donuti ji pouzivat a pochopit. S cimz se osobne neztotoznuji, ja jsem zastance flexibility a co mozna nejsirsich prostredku k vyjadreni.
zvláštní, podle mě má haskell striktně bohatší vyjadřovací schopnosti než python :))
Název: Re:Co si myslíte o OOP?
Přispěvatel: Kadet 23. 01. 2019, 14:31:06
Sproste slovo.. to zalezi na pohledu pozorovatele. Ja hovorim neutralne pokud mozno.

Syntakticky cukr je tady jako kafe nebo jako droga. Kafe ti umozni zustat vzhuru dele dneska, ale na ukor spanku zitra. Cukr ti umozni pochopit jazyk driv dneska ale na ukor toho, ze kdyz budes chtit udelat neco slozitejsiho, tak to nepujde, protoze jazykove bozstvo rozhodlo, ze se budou pouzivat classy a ne nic jinyho.
Marketing je pozitivni, jeho smyslem je efektivne investovat zdroje. V pripade jazyka by tedy mel vest k vyvoji smerem, po kterem je nejvetsi poptavka, ktery ten jazyk nejlepe zhodnoti. Pokud je to jinak, neni to kvuli marketingu, ale jeho absenci. V lepsim pripade jsou zdroje promarneny, v horsim to jazyk pokazi a bude opusten.

Syntakticky cukr neni ani jako kafe ani jako cukr. Ani jedno neni zavedeni zjednodusujici abstrakce, ani jedno z toho nesnizuje slozitost systemu. Python neni Haskell, tam ti zadne bozstvo neprikazalo pouzivat classy a nic jineho. A u toho Haskelluv tu bezela teze, ze jeho striktni funkcionalita a nic jineho je pro tve blaho, protoze te to donuti ji pouzivat a pochopit. S cimz se osobne neztotoznuji, ja jsem zastance flexibility a co mozna nejsirsich prostredku k vyjadreni.

Neshodnem se na vyznamu slova marketing. Ja pod marketingem chapu sales operaci s sirokym zaberem, tj. ne obvolavani jednotlivych klientu, ale neco co ma dosah k tisicum az milionum. V marketingu te nezajima kvalita produktu. Jediny cil je prodat. At uz je to smejd nebo super produkt, ktery se pak ale vetsinou prodava sam. Trh kratkodobe reaguje na marketing, ale dlouhodobe vyhrava lepsi produkt.

Analogie s kafem a drogou byla ve smyslu Chci neco ted hned ale rozesere me to pozdeji.
cukr, kafe, droga, dluh, vyber si

Python, Haskell, Javascript. V kazdem bozstvo rozhodlo jaky bude syntax. Rozhodli se ho udelat citelnejsi pro blbecky za cenu flexibility pro pokrocilejsi uzivatele. Podle me spravne rozhodnuti z pohledu adopce uzivateli ale schazi na trhu nastroje pro power usery.

Souhlasim, ze Haskell je prilis striktni, neodpovida lidske intuici, pusobi jako sveraci kazajka. Na druhou stranu clovek v sveraci kazajce nenadela prilis skody okolo, proto chapu, ze nekteri Haskell opevuji, kdyz maji pracovat treba s Indy.






Název: Re:Co si myslíte o OOP?
Přispěvatel: Kadet 23. 01. 2019, 14:40:27
Moje zavery nejsou zavery ale pouze tvrzeni ktera jsou pokud mozno vyvratitelna (falsifiability). Jinak receno jdu s kuzi na trh a usnadnuju vam ostatnim mi moje tvrzeni lehceji vyvratit.

Rad bych aby mi moje tvrzeni lidi zacali rozebirat na padrt a konstruktivne vyvracet. Casto moje 'zavery' zde ale ocividne lidi urazi.

Aplikace postavena na posilani zprav. To je pohled na vec, ne vec implementace. Kdyz mam distribuovany system z vic pocitacu, tak mi nezbyde nez mezi nimi skutecne poslat pres sit nejakou zpravu. Kdyz se podivam dovnitr jedny masiny nebo dovnitr konkretniho programu, muzu rict, ze zavolani metody je taky poslani zpravy.

No jak mam polemizovat s tim, ze objekt je dict a trida zbytecny syntakticky cukr? Jako zjednoduseni to nejaky smysl dava, prehlednou syntaxi mam vysoko v osobnich prioritach, proc se o to hadat v situaci, kdy je Tvuj nazor dost minoritni a vyvoj jde jinudy (podobne v kauze prototypy, kde Self a spol. evolucne prohravaji).

Zpravu ja si predstavuju ve smyslu pozdni vazby - mam nejaky dohodnuty protokol a pres obecny komunikacni kanal poslu zpravu a doufam, ze ji prijemce porozumi. Volani funkce v situaci, kdy mi to validuje kompilator nebo linter, je trosku neco jineho. Nemam potrebu se na to divat jako na komunikaci autonomnich objektu, protoze funkcim vidim pod prsty. Predstavovat si to muzeme ruzne, o tom zadna.

Jak? Funkcionalitu tridy muzes implementovat skrz prototypy. Prototypy muzes implementovat skrz dicty. Ergo dict je obecnejsi abstrakce nez trida.

Minoritni nazor. Tohle by bylo dobry tema. Mas pravdu ze muj nazor je minoritni. Ja se majoritnich nazoru stitim. Majoritni nazor je jako lemmings nebo ovce. Takova ovce nasleduje druhou ovci az se nasleduje cely stado a nakonec poskacou vsichni se srazu. Bud doslova nebo v nejaky financni krizi spadnou na hubu v akciich, nemovitostech, apod.

Kratkodobe vyhrava tenhle majoritni ovci nazor ale kdyz se vlastne sam zabije tim ze poskace ze skaly, dlouhodobe to zas takova konkurence neni.

Ano, nekdy se pohled na system jako mnozinu komunikujicich objektu hodi, jindy ne. Za me je to pouze pohled na vec. Pohled jak probiha vypocet. Muzu vzit jakykoliv system, i ten kde nikdo s zadnym posilanim zprav nepocital, a videt v nem posilani zprav.
Název: Re:Co si myslíte o OOP?
Přispěvatel: operator 23. 01. 2019, 14:45:53
Ja chapu potrebu schovavat. Akorat debaty o OO navrhu zacinaji tim, co schovat, zapouzdrit a zdedit, nez tim, co je vysledkem vyreseni problemu.

Kdyz jsi sam, kdo pouziva program, tak je fajn, ze si muzes vybrat tridu nebo modul nebo package nebo cokoliv k tomu ucelu. Jenze kdyz pracujes s indem, tak on si vybere jedno a ty druhy. Ja bych na to mel radsi jen jeden koncept.

V Selfu zjistili, ze je lepsi povazovat atribut stejne jako metodu. Jinak jestli se nekdo rozhoduje, jestli schovat nebo ne podle toho, co mu umoznuje jazyk, pak je otazka, jestli nema prilis svazujici jazyk.

Uvedomujes si, ze si protirecis?

Vadi ti syntakticky cukr a zaroven ti vadi, ze ind si vybere modul nebo tridu. Kdyz budes mit jazyk, kde si budes muset objekty implementovat sam z dictu, tak ten ind je bude zarucene implementovat jinak nez ty a tech moznych implementaci nebude jen trida nebo modul, bude jich prakticky nekonecne mnoho. Modul nebo trida,vto jsou ruzne abstrakce a ma smysl je mit. Ale mit nekonecne mnoho implementaci te same abstrakce, to smysl nedava. To je jeden z duvod, proc v pythonu pouzivas standardizovanou abstrakci class a ne vlastni reseni postavene nad dicty i kdyz muzes. Aby ses jednoduseji domluvil. Vsechno co ti zjednodusuje pouziti jazyka je uzitecne, nikoliv nadbytecne.

Mohl bys mi ukazat konkretni dve teze ve kterych si protirecim?

Ta spoluprace s indem je organizacni problem. Pokud ho nedokazu vyresit na urovni lidi tak me zadna trida nebo modul nespasi jinak pozdrav panbu. Vratim se k moji starsi tezi. Praseci kod a vic lidi co na nem pracuje? Vyres nejdriv problem praseciho kodu nez budes hledat nastroj co omezi ostatni cleny tymu tak aby neudelaly radsi zadnou chyby a taky zadny pokrok.

Ja v pythonu classy ani pokud mozno nepouzivam btw. Pro me je python jen host language pro vytvoreni lepsiho jazyka (embedded dsl), napr. proto ze python ma dobrej ekosystem knihoven.
Protirecis si  ve svych pozadavcich a jejich dusledcich. Odmitas vyssi abstrakci v jazyce, prijde ti zbytecna, kdyz tehoz muzes dosahnout existujicimi prostredky, byt sloziteji. A zaroven si stezujes na slozitost, ktera ti stezuje spolupraci s indem. Kdyz ti vadi vyssi pocet abstrakci zavedenych do jazyku, mel by ti idealne vyhovovat lisp, ale myslim ze ve skutecnosti i s nim bys mel problemy.

Ze v pythonu nepouzivas tridy muze mit ruzne duvody, namatkou neresis ulohy, kde je jejich pouziti vyhodne, nebo je neumis pouzivat a nebo jejich pouzivani odmitas z ideologickych duvodu. At tak nebo tak, Pythonu je to jedno a umoznuje ti psat dobre programy i bez toho.
Název: Re:Co si myslíte o OOP?
Přispěvatel: operator 23. 01. 2019, 14:49:24
A u toho Haskelluv tu bezela teze, ze jeho striktni funkcionalita a nic jineho je pro tve blaho, protoze te to donuti ji pouzivat a pochopit. S cimz se osobne neztotoznuji, ja jsem zastance flexibility a co mozna nejsirsich prostredku k vyjadreni.
zvláštní, podle mě má haskell striktně bohatší vyjadřovací schopnosti než python :))
Mozna jo, ja ho neznam. Ale ziskal jsem dojem, ze v nem nejde psat jinak nez funkcionalne a ze se v nem proto nejde vyjadrovat objektove nebo proceduralne.
Název: Re:Co si myslíte o OOP?
Přispěvatel: v 23. 01. 2019, 15:00:35
A u toho Haskelluv tu bezela teze, ze jeho striktni funkcionalita a nic jineho je pro tve blaho, protoze te to donuti ji pouzivat a pochopit. S cimz se osobne neztotoznuji, ja jsem zastance flexibility a co mozna nejsirsich prostredku k vyjadreni.
zvláštní, podle mě má haskell striktně bohatší vyjadřovací schopnosti než python :))
Mozna jo, ja ho neznam. Ale ziskal jsem dojem, ze v nem nejde psat jinak nez funkcionalne a ze se v nem proto nejde vyjadrovat objektove nebo proceduralne.
je to čistě funkcionální jazyk, ale neřekl bych, že to brání objektovému (YMMV...) nebo procedurálnímu (tomu určitě ne) programování
Název: Re:Co si myslíte o OOP?
Přispěvatel: BoneFlute 23. 01. 2019, 15:29:20
proto chapu, ze nekteri Haskell opevuji, kdyz maji pracovat treba s Indy.

Kdyby jen s Indy.
Název: Re:Co si myslíte o OOP?
Přispěvatel: Inkvizitor 23. 01. 2019, 15:49:26
Minoritni nazor. Tohle by bylo dobry tema. Mas pravdu ze muj nazor je minoritni. Ja se majoritnich nazoru stitim. Majoritni nazor je jako lemmings nebo ovce. Takova ovce nasleduje druhou ovci az se nasleduje cely stado a nakonec poskacou vsichni se srazu. Bud doslova nebo v nejaky financni krizi spadnou na hubu v akciich, nemovitostech, apod.

Kratkodobe vyhrava tenhle majoritni ovci nazor ale kdyz se vlastne sam zabije tim ze poskace ze skaly, dlouhodobe to zas takova konkurence neni.

Ano, nekdy se pohled na system jako mnozinu komunikujicich objektu hodi, jindy ne. Za me je to pouze pohled na vec. Pohled jak probiha vypocet. Muzu vzit jakykoliv system, i ten kde nikdo s zadnym posilanim zprav nepocital, a videt v nem posilani zprav.

Jsi si ale vedom toho, ze mit minoritni nazor jeste nutne neznamena mit lepsi nazor, vid?
Název: Re:Co si myslíte o OOP?
Přispěvatel: JSH 23. 01. 2019, 15:56:51
Jak? Funkcionalitu tridy muzes implementovat skrz prototypy. Prototypy muzes implementovat skrz dicty. Ergo dict je obecnejsi abstrakce nez trida.
Tahle logika kulhá na všechny čtyři. Kdyby záleželo na tom, co jde v čem implementovat, tak je instrukce mov ta úplně nejobecnější možná abstrakce (je výpočetně úplná, takže jde pomocí nich implementovat úplně všechno).
Název: Re:Co si myslíte o OOP?
Přispěvatel: Mirek Prýmek 23. 01. 2019, 16:47:16
Zalozit celou aplikaci na "posilani zprav" mezi "objekty", to se moc neuchytilo a IMO jsou k tomu dobre duvody.
Já bych to takhle příkře nestavěl. Skoro bych řekl, že naopak tenhle způsob dívání se na systémy se poslední dobou docela rozšiřuje, akorát ne na té "druhé nejnižší úrovní" (samotný programovací jazyk). Na vyšších urovních se mi ale zdá, že docela kvete.

Když se koukneš na RTOSy v embedded , tak tam jsou tasky, mezi kterými se předávají zprávy, základním stavebním kamenem. Stejně goroutiny/channely v Go, REST, microservices, ... Myslím, že ta základní cesta "rozdělíme velký systém na součásti, které spolu komunikují dobře definovanými zprávami" se naopak ukázal jako docela správná cesta - jiné způsoby ve velkých, masivně paralelních systémech dost naráží na limity toho, co jsme vůbec schopní umenežovat (z hlediska návrhu, implementace i provozu). Jak už jsem psal výš, i to rozdělení programu na dvě vlákna, která si předávají nějaká data, je vlastně ono.

Přijde mi, že OOP přišlo s hodně dobrou myšlenkou, akorát trochu moc brzo. To už se tak v IT docela často stává, že výborné myšlenky prvně zkrachují a za nějakých deset dvacet let bombasticky převálcují svět v mírně obměněné podobě :)
Název: Re:Co si myslíte o OOP?
Přispěvatel: Mirek Prýmek 23. 01. 2019, 16:50:14
Stejně goroutiny/channely v Go, REST, microservices, ...
Jo, málem bych zapomněl na výpočetní clustery - tam to funguje už hodně dlouho - MPI, Hadoop, Spark, ... To je všechno o předávání zpráv mezi dost autonomními, "svéprávnými" jednotkami.
Název: Re:Co si myslíte o OOP?
Přispěvatel: Mirek Prýmek 23. 01. 2019, 16:59:56
muzu rict, ze zavolani metody je taky poslani zpravy.
Říct to samozřejmě můžeš, ale naděláš tím víc škody než užitku, protože jsou to dva zásadně odlišné koncepty. Už jsme o tom tady mluvili: pokud volám metodu, tak tím bezprostředně spouštím nějaký (víc nebo míň) statický, předem daný kód. Pokud posílám zprávu, tak jenom sděluju nějakou informaci. Jak s tím příjemce informace naloží, jestli v návaznosti na to vyvine nějakou činnost nebo ne, je už na něm.

V nejčistší podobě je rozdíl vidět na multiagentních systémech, kde si skutečně inteligentní agenti jenom sdělují informace, upravují svoje lokální knowledge bases a podle jejich obsahu pak vyvijejí nějakou činnost.
Název: Re:Co si myslíte o OOP?
Přispěvatel: Inkvizitor 23. 01. 2019, 17:00:49
Zalozit celou aplikaci na "posilani zprav" mezi "objekty", to se moc neuchytilo a IMO jsou k tomu dobre duvody.

Já bych to takhle příkře nestavěl. Skoro bych řekl, že naopak tenhle způsob dívání se na systémy se poslední dobou docela rozšiřuje, akorát ne na té "druhé nejnižší úrovní" (samotný programovací jazyk). Na vyšších urovních se mi ale zdá, že docela kvete.

Nedovedl jsem si predstavit, ze se zrovna Ty na tohle nechytnes. ;-) Mne slo hlavne o tu pozdni vazbu coby deklarovanou ctnost programovaciho jazyka (spolu se zapouzdrenim dat). Reseni konkurence a rozumnou dekompozici beru.
Název: Re:Co si myslíte o OOP?
Přispěvatel: Mirek Prýmek 23. 01. 2019, 17:10:48
Haskell je prilis striktni, neodpovida lidske intuici
Z mýho pohledu hlavně většinové programátorské intuici neodpovídá líné vyhodnocování. Většina z nás začínala a nejvíc času strávila přemýšlením v intencích "algoritmus je posloupnost kroků [...]".

Ja se majoritnich nazoru stitim. Majoritni nazor je jako lemmings nebo ovce.
Majoritní názor taky je, že je Země kulatá. Minoritní názor je, že je placka.

Kdyby záleželo na tom, co jde v čem implementovat, tak je instrukce mov ta úplně nejobecnější možná abstrakce (je výpočetně úplná, takže jde pomocí nich implementovat úplně všechno).
Ještě lepší je logický NOR, s ním si dospělej chlap vystačí ;)

Nedovedl jsem si predstavit, ze se zrovna Ty na tohle nechytnes. ;-)
Tak jasně, pro mě je to prostě srdcovka. S multiagentními systémy jsem si pohrával ještě když jsem tahal kačera po škole :)
Název: Re:Co si myslíte o OOP?
Přispěvatel: Kadet 23. 01. 2019, 18:09:28
muzu rict, ze zavolani metody je taky poslani zpravy.
Říct to samozřejmě můžeš, ale naděláš tím víc škody než užitku, protože jsou to dva zásadně odlišné koncepty. Už jsme o tom tady mluvili: pokud volám metodu, tak tím bezprostředně spouštím nějaký (víc nebo míň) statický, předem daný kód. Pokud posílám zprávu, tak jenom sděluju nějakou informaci. Jak s tím příjemce informace naloží, jestli v návaznosti na to vyvine nějakou činnost nebo ne, je už na něm.

V nejčistší podobě je rozdíl vidět na multiagentních systémech, kde si skutečně inteligentní agenti jenom sdělují informace, upravují svoje lokální knowledge bases a podle jejich obsahu pak vyvijejí nějakou činnost.

V tomhle jsme si predtim nerozumeli na stopro.

Bud mam asynchronni poslani zpravy. Fire and forget.

Nebo mam synchronni volani zpravy, totez co volani funkce nebo metody. A to jsou celkem dve zpravy. Jedna odesilajici pozadavek, druha prijimajici vysledek.
Název: Re:Co si myslíte o OOP?
Přispěvatel: Kadet 23. 01. 2019, 18:12:54
Haskell je prilis striktni, neodpovida lidske intuici
Z mýho pohledu hlavně většinové programátorské intuici neodpovídá líné vyhodnocování. Většina z nás začínala a nejvíc času strávila přemýšlením v intencích "algoritmus je posloupnost kroků [...]".

Ja se majoritnich nazoru stitim. Majoritni nazor je jako lemmings nebo ovce.
Majoritní názor taky je, že je Země kulatá. Minoritní názor je, že je placka.

Kdyby záleželo na tom, co jde v čem implementovat, tak je instrukce mov ta úplně nejobecnější možná abstrakce (je výpočetně úplná, takže jde pomocí nich implementovat úplně všechno).
Ještě lepší je logický NOR, s ním si dospělej chlap vystačí ;)

Nedovedl jsem si predstavit, ze se zrovna Ty na tohle nechytnes. ;-)
Tak jasně, pro mě je to prostě srdcovka. S multiagentními systémy jsem si pohrával ještě když jsem tahal kačera po škole :)

Majoritni nazory. Ano, to je vec co se meni v case. S kulatou zemi to byl nejdriv minoritni nazor a ovce se drzely majoritniho. Nebyla ale placata zeme mytus?

Dneska je programovani zhruba na urovni pred Kopernikem, takze se od tech majoritnich cirkevnich nazoru distancuju.

Pokud dokazes nejak intuitivne pro lidi poskladat nor gates do vyssich abstrakci pak proc ne. Byl by to dobrej system protoze by nemel diry v abstrakcich.
Název: Re:Co si myslíte o OOP?
Přispěvatel: Kadet 23. 01. 2019, 18:14:12
Jak? Funkcionalitu tridy muzes implementovat skrz prototypy. Prototypy muzes implementovat skrz dicty. Ergo dict je obecnejsi abstrakce nez trida.
Tahle logika kulhá na všechny čtyři. Kdyby záleželo na tom, co jde v čem implementovat, tak je instrukce mov ta úplně nejobecnější možná abstrakce (je výpočetně úplná, takže jde pomocí nich implementovat úplně všechno).

Super, tak na tom postav intuitivni programovaci jazyk a budes mit perfektni system.
Název: Re:Co si myslíte o OOP?
Přispěvatel: Mirek Prýmek 23. 01. 2019, 18:24:39
Bud mam asynchronni poslani zpravy. Fire and forget.

Nebo mam synchronni volani zpravy, totez co volani funkce nebo metody. A to jsou celkem dve zpravy. Jedna odesilajici pozadavek, druha prijimajici vysledek.
To s tím, co píšu, přímo nesouvisí.

Rozdíl je v tom, jestli se adresát zprávy autonomně rozhoduje, co udělá. Pokud volám metodu, tak se o ničem nerozhoduje, prostě se provede kód metody. To má potom různé důsledky, třeba právě v tom, jestli (jak snadno) jde udělat obecná proxy.
Název: Re:Co si myslíte o OOP?
Přispěvatel: Mirek Prýmek 23. 01. 2019, 18:26:24
Dneska je programovani zhruba na urovni pred Kopernikem, takze se od tech majoritnich cirkevnich nazoru distancuju.
Jak myslíš, no. Já bych si spíš vsadil, že to ještě v průběhu života přehodnotíš, ale třeba bych prohrál :)
Název: Re:Co si myslíte o OOP?
Přispěvatel: Youda 23. 01. 2019, 18:31:09
Bud mam asynchronni poslani zpravy. Fire and forget.

Nebo mam synchronni volani zpravy, totez co volani funkce nebo metody. A to jsou celkem dve zpravy. Jedna odesilajici pozadavek, druha prijimajici vysledek.
To s tím, co píšu, přímo nesouvisí.

Rozdíl je v tom, jestli se adresát zprávy autonomně rozhoduje, co udělá. Pokud volám metodu, tak se o ničem nerozhoduje, prostě se provede kód metody. To má potom různé důsledky, třeba právě v tom, jestli (jak snadno) jde udělat obecná proxy.

A kdyz zavolam metodu, co se sama interne rozhodne co udela?
Kolik andelu se vejde na spicku jehly?
K cemu je dobre posilat do objektu zpravu, se kterou objekt neumi pracovat? Aby mi vratil InvalidArgumentException?
Neni nahodou lepsi mit metodu se staticky typovanymi parametry, aby vubec nebylo mozne nesmyslnou zpravu objeku zaslat?
Název: Re:Co si myslíte o OOP?
Přispěvatel: Mirek Prýmek 23. 01. 2019, 18:34:09
A kdyz zavolam metodu, co se sama interne rozhodne co udela?
Tak se na tom, co jsem napsal, nemění ani čárka.

K cemu je dobre posilat do objektu zpravu, se kterou objekt neumi pracovat? Aby mi vratil InvalidArgumentException?
Neni nahodou lepsi mit metodu se staticky typovanymi parametry, aby vubec nebylo mozne nesmyslnou zpravu objeku zaslat?
Jak kdy a jak k čemu. Je "k něčemu dobré", že můžeš http serveru poslat nevalidní request? Je "k něčemu dobré", že po něm můžeš chtít resource, který nemá, a on ti odpoví "404 not found"?

Nevím, nerozumím moc smyslu té otázky.
Název: Re:Co si myslíte o OOP?
Přispěvatel: Kit 23. 01. 2019, 18:36:15
Majoritní názor taky je, že je Země kulatá. Minoritní názor je, že je placka.

Majoritní názor je, že Bůh existuje, minoritní názor je, že Bůh neexistuje.
Název: Re:Co si myslíte o OOP?
Přispěvatel: Kit 23. 01. 2019, 18:41:24
Bud mam asynchronni poslani zpravy. Fire and forget.

Nebo mam synchronni volani zpravy, totez co volani funkce nebo metody. A to jsou celkem dve zpravy. Jedna odesilajici pozadavek, druha prijimajici vysledek.

Někdy stačí místo pull používat push. Spoustu aplikací by to změnilo od základu.
Název: Re:Co si myslíte o OOP?
Přispěvatel: Kit 23. 01. 2019, 18:57:15
Jak kdy a jak k čemu. Je "k něčemu dobré", že můžeš http serveru poslat nevalidní request? Je "k něčemu dobré", že po něm můžeš chtít resource, který nemá, a on ti odpoví "404 not found"?

V důsledku by to znamenalo, že by každý klient musel přesně vědět, na co se smí kterého serveru zeptat. Ostatní požadavky by musel ten klient stornovat ještě před jeho odesláním. Tohle může splňovat tzv. tlustý klient.

Vlastně to můžeme zobecnit, že u statického typování je klient tlustý, ale server tenký. U dynamického typování je tomu naopak.
Název: Re:Co si myslíte o OOP?
Přispěvatel: Youda 23. 01. 2019, 19:35:28

K cemu je dobre posilat do objektu zpravu, se kterou objekt neumi pracovat? Aby mi vratil InvalidArgumentException?
Neni nahodou lepsi mit metodu se staticky typovanymi parametry, aby vubec nebylo mozne nesmyslnou zpravu objeku zaslat?
Jak kdy a jak k čemu. Je "k něčemu dobré", že můžeš http serveru poslat nevalidní request? Je "k něčemu dobré", že po něm můžeš chtít resource, který nemá, a on ti odpoví "404 not found"?

Nevím, nerozumím moc smyslu té otázky.

Smysl one otazky spociva v tom, jaky ze je rozdil mezi synchronni zpravou a zavolanim metody.

Kdyz poslu Tomcatu nevalidni Http request ve smyslu, ze to vybec neni Http request, Tomcat (catalina) to odpalkuje hned a k memu Servletu se to vubec nedostane.
Pokud poslu Tomcatu VALIDNI request, Tomcat instaciuje objekt HttpRequest a ten preda dispatcheru, ktery kdyz nic nenajde, tak SPRAVNE odpovi 404 not found pomoci objektu HttpResponse.

Metoda se staticky typovanym atributen tedy NEMUZE dostat nekorektni data ve smyslu, ze to neni objekt HttpRequest.

A ja nevidim zadnou vyhodu v tom, aby se mi do ServletDispatcheru sypal neidentifikovatelny bordel a dej se vule bozi.
Název: Re:Co si myslíte o OOP?
Přispěvatel: Kit 23. 01. 2019, 19:47:22
Kdyz poslu Tomcatu nevalidni Http request ve smyslu, ze to vybec neni Http request, Tomcat (catalina) to odpalkuje hned a k memu Servletu se to vubec nedostane.

Nesmíš Tomcatu poslat nevalidní HTTP request. Klient s ním nesmí ani navázat spojení, protože formát požadavku (typ) není splněn.
Název: Re:Co si myslíte o OOP?
Přispěvatel: Mirek Prýmek 23. 01. 2019, 19:49:28
A ja nevidim zadnou vyhodu v tom, aby se mi do ServletDispatcheru sypal neidentifikovatelny bordel a dej se vule bozi.
Já taky ne. A proč to říkáš?

Já jsem jenom popisoval, jaký je rozdíl mezi voláním metody a předáním zprávy - že jsou to dvě zásadně odlišné věci.

Smysl one otazky spociva v tom, jaky ze je rozdil mezi synchronni zpravou a zavolanim metody.
No já myslím, že jsem to už řekl dostatečně jasně:

pokud volám metodu, tak tím bezprostředně spouštím nějaký (víc nebo míň) statický, předem daný kód. Pokud posílám zprávu, tak jenom sděluju nějakou informaci. Jak s tím příjemce informace naloží, jestli v návaznosti na to vyvine nějakou činnost nebo ne, je už na něm.

Vzhledem k tomu, jaké tohle jednoduché tvrzení pořád způsobuje vlny, by se asi slušelo dodat ještě tohle:

1. Je to rozdíl především koncepční, až podružně technický. Klíčové je, jestli je adresát "dostatečně autonomní" (ano, jsem si vědom toho, jak je to vágní), aby se "sám rozhodnul", a to "na základě informací, které jsou mu dostupné".

2. Implementované to může být technicky různě. Že je předání zprávy implementované voláním funkce/metody je irelevantní, jedná se o odlišné roviny abstrakce a buď se bavíme o jedné, nebo o druhé.[1]


[1] Je to stejné jako že si můžu v céčku implementovat Lisp, ale z toho neplyne, že C a Lisp je totéž nebo že C má všechny vlastnosti Lispu
Název: Re:Co si myslíte o OOP?
Přispěvatel: Mirek Prýmek 23. 01. 2019, 19:53:26
P.S. pokud je to potřeba vyloženě polopaticky:

Mezi voláním metody a předáním zprávy je podobný rozdíl jako mezi voláním metody a HTTP requestem. Pokud někdo bude tvrdit, že volání metody a HTTP request je totéž, tak podle mě jenom zbytečně mate pojmy. Vyvrátit se mu to ale nedá, protože ten člověk prostě jenom zbytečně označuje dvě meritorně rozdílné věci (neobvykle) stejným slovem. Jeho věc.
Název: Re:Co si myslíte o OOP?
Přispěvatel: BoneFlute 23. 01. 2019, 20:58:57
Nebo mam synchronni volani zpravy, totez co volani funkce nebo metody. A to jsou celkem dve zpravy. Jedna odesilajici pozadavek, druha prijimajici vysledek.
Plus započítej implementaci, která se prostě nepovedla. A díky tomu máme objektově orientované programování (místo objektového programování) :-)
Název: Re:Co si myslíte o OOP?
Přispěvatel: Kadet 24. 01. 2019, 00:24:39
Dneska je programovani zhruba na urovni pred Kopernikem, takze se od tech majoritnich cirkevnich nazoru distancuju.
Jak myslíš, no. Já bych si spíš vsadil, že to ještě v průběhu života přehodnotíš, ale třeba bych prohrál :)

Jakmile vidis, ze to na co lidi pouzivaji tisice az miliony radku kodu jde pouzit par set nebo mozna nizkych tisic, a udelat to zaroven jednodussi, rychlejsi, citelnejsi, tak prehodnotis.

Jestli v programovani existuje silver bullet, pak bych bych vsadil hodne na to, ze to bude jednoduchost (simplicity).

Název: Re:Co si myslíte o OOP?
Přispěvatel: BoneFlute 24. 01. 2019, 00:53:26
Metoda se staticky typovanym atributen tedy NEMUZE dostat nekorektni data ve smyslu, ze to neni objekt HttpRequest.

Je rozdíl mezi tím, když se s dotyčným objektem domluvíš na určitých podmínkách, a mezi tím, když se domluvíš na všech (Haskell) a na ničem (Python).

Aktory jsou mezi sebou (často fyzicky) nezávislí. Ty můžeš tomu objektu poslat zprávu, která bude zcela korektní, ale v tom danném okamžiku (0:52hodin) prostě ten aktor tu zprávu nezná. Ale třeba od od 4:00 už jo.

Je pak otázka, co znamená to "nezná". Proč, a jak se to projevuje.
Název: Re:Co si myslíte o OOP?
Přispěvatel: Kadet 24. 01. 2019, 02:22:54
Nejak me ta nase rozprava nad posilanim zprav mate.

Mluvime o fyzicky oddelenych systemech a jak orchestrovat jejich komunikaci? Nebo nas orchestrace vubec nezajima, ale dulezity je, ze se mezi sebou nejak domluvi a dosahnou vysledku autonomni choreografii?

Na oddelenych systemech kompiler nepomuze obavam se. Mozna TLA+?

Orchestrace - nejakej treti dirigent to koordinuje
Choreografie - agenti se koordinujou sami mezi sebou
Název: Re:Co si myslíte o OOP?
Přispěvatel: operator 24. 01. 2019, 04:21:30
Metoda se staticky typovanym atributen tedy NEMUZE dostat nekorektni data ve smyslu, ze to neni objekt HttpRequest.
Je rozdíl mezi tím, když se s dotyčným objektem domluvíš na určitých podmínkách, a mezi tím, když se domluvíš na všech (Haskell) a na ničem (Python).
Python neni pripad, ze se nedomluvis na nicem. U pythonu mas domluvenu jednu zasadni vec, ze vsechno je objekt, tj. vsechno ma nejaky zakladni protokol pomoci ktereho umi kazdy komunikovat s kazdym, treba se ho zeptat na identitu a dalsi veci a kazdy na to umi odpovedet.
Název: Re:Co si myslíte o OOP?
Přispěvatel: operator 24. 01. 2019, 04:24:45
Dneska je programovani zhruba na urovni pred Kopernikem, takze se od tech majoritnich cirkevnich nazoru distancuju.
Jak myslíš, no. Já bych si spíš vsadil, že to ještě v průběhu života přehodnotíš, ale třeba bych prohrál :)
Jakmile vidis, ze to na co lidi pouzivaji tisice az miliony radku kodu jde pouzit par set nebo mozna nizkych tisic, a udelat to zaroven jednodussi, rychlejsi, citelnejsi, tak prehodnotis.

Jestli v programovani existuje silver bullet, pak bych bych vsadil hodne na to, ze to bude jednoduchost (simplicity).
Presne na tohle je dobra vyssi abstrakce, kterou nazyvas nadbytecny syntakticky cukr. Porad to vnimam tak, ze si protirecis.
Název: Re:Co si myslíte o OOP?
Přispěvatel: operator 24. 01. 2019, 04:38:29
P.S. pokud je to potřeba vyloženě polopaticky:

Mezi voláním metody a předáním zprávy je podobný rozdíl jako mezi voláním metody a HTTP requestem. Pokud někdo bude tvrdit, že volání metody a HTTP request je totéž, tak podle mě jenom zbytečně mate pojmy. Vyvrátit se mu to ale nedá, protože ten člověk prostě jenom zbytečně označuje dvě meritorně rozdílné věci (neobvykle) stejným slovem. Jeho věc.

Rozdil je technicky, u posilani zprav muzu komunikovat skrze ruzna rozhrani, treba i socket a mit tak distribuovany system, za tuto flexibilitu se, jako vzdy, plati vykonem a navic je to komplikovanejsi na spravu. Jaky je v tom rozdil ale pro navrh programu? Imho zadny, protoze z pohledu abstrakce je to to same. Tedy v pripade, ze se bude jednat o objekty v ramci jednoho programu.  U distribuovaneho systemu me to bude nutit delat co nejvetsi objekty s co nejdelsi zivotnosti.
Název: Re:Co si myslíte o OOP?
Přispěvatel: operator 24. 01. 2019, 04:41:28
Jak kdy a jak k čemu. Je "k něčemu dobré", že můžeš http serveru poslat nevalidní request? Je "k něčemu dobré", že po něm můžeš chtít resource, který nemá, a on ti odpoví "404 not found"?

V důsledku by to znamenalo, že by každý klient musel přesně vědět, na co se smí kterého serveru zeptat. Ostatní požadavky by musel ten klient stornovat ještě před jeho odesláním. Tohle může splňovat tzv. tlustý klient.

Vlastně to můžeme zobecnit, že u statického typování je klient tlustý, ale server tenký. U dynamického typování je tomu naopak.
To je dobry postreh, ktery by nekomu mohl pomoci pochopit vyhody dynamickeho programovani.
Název: Re:Co si myslíte o OOP?
Přispěvatel: operator 24. 01. 2019, 04:45:40
Jak? Funkcionalitu tridy muzes implementovat skrz prototypy. Prototypy muzes implementovat skrz dicty. Ergo dict je obecnejsi abstrakce nez trida.
Tahle logika kulhá na všechny čtyři. Kdyby záleželo na tom, co jde v čem implementovat, tak je instrukce mov ta úplně nejobecnější možná abstrakce (je výpočetně úplná, takže jde pomocí nich implementovat úplně všechno).
Super, tak na tom postav intuitivni programovaci jazyk a budes mit perfektni system.
To same lze doporucit i tobe, akorat s dicty :-). Implementovat tu mou ukazku jen pomoci dictu se asi nikdo ani nepokusi, co? Beru to jako dukaz toho, ze vyssi abstrakce ma smysl a neni nadbytecna.
Název: Re:Co si myslíte o OOP?
Přispěvatel: operator 24. 01. 2019, 05:05:30
Sproste slovo.. to zalezi na pohledu pozorovatele. Ja hovorim neutralne pokud mozno.

Syntakticky cukr je tady jako kafe nebo jako droga. Kafe ti umozni zustat vzhuru dele dneska, ale na ukor spanku zitra. Cukr ti umozni pochopit jazyk driv dneska ale na ukor toho, ze kdyz budes chtit udelat neco slozitejsiho, tak to nepujde, protoze jazykove bozstvo rozhodlo, ze se budou pouzivat classy a ne nic jinyho.
Marketing je pozitivni, jeho smyslem je efektivne investovat zdroje. V pripade jazyka by tedy mel vest k vyvoji smerem, po kterem je nejvetsi poptavka, ktery ten jazyk nejlepe zhodnoti. Pokud je to jinak, neni to kvuli marketingu, ale jeho absenci. V lepsim pripade jsou zdroje promarneny, v horsim to jazyk pokazi a bude opusten.

Syntakticky cukr neni ani jako kafe ani jako cukr. Ani jedno neni zavedeni zjednodusujici abstrakce, ani jedno z toho nesnizuje slozitost systemu. Python neni Haskell, tam ti zadne bozstvo neprikazalo pouzivat classy a nic jineho. A u toho Haskelluv tu bezela teze, ze jeho striktni funkcionalita a nic jineho je pro tve blaho, protoze te to donuti ji pouzivat a pochopit. S cimz se osobne neztotoznuji, ja jsem zastance flexibility a co mozna nejsirsich prostredku k vyjadreni.
Neshodnem se na vyznamu slova marketing. Ja pod marketingem chapu sales operaci s sirokym zaberem, tj. ne obvolavani jednotlivych klientu, ale neco co ma dosah k tisicum az milionum. V marketingu te nezajima kvalita produktu. Jediny cil je prodat. At uz je to smejd nebo super produkt, ktery se pak ale vetsinou prodava sam. Trh kratkodobe reaguje na marketing, ale dlouhodobe vyhrava lepsi produkt.

Analogie s kafem a drogou byla ve smyslu Chci neco ted hned ale rozesere me to pozdeji.
cukr, kafe, droga, dluh, vyber si

Python, Haskell, Javascript. V kazdem bozstvo rozhodlo jaky bude syntax. Rozhodli se ho udelat citelnejsi pro blbecky za cenu flexibility pro pokrocilejsi uzivatele. Podle me spravne rozhodnuti z pohledu adopce uzivateli ale schazi na trhu nastroje pro power usery.

Souhlasim, ze Haskell je prilis striktni, neodpovida lidske intuici, pusobi jako sveraci kazajka. Na druhou stranu clovek v sveraci kazajce nenadela prilis skody okolo, proto chapu, ze nekteri Haskell opevuji, kdyz maji pracovat treba s Indy.
V marketingu te kvalita produktu zajima, ale nema absolutni prioritu. Zvazuji se i dalsi aspekty. Ve vysledku se v idealnim pripade na kvalitu klade takovy duraz, jaky na nej kladou zakaznici. Ano, vyhrava lepsi produkt, ale to nutne neznamena ten nejkvalitnejsi.

Ta analogie nedava smysl. Syntakticky cukr tu neni proto, ze chceme neco rychle bez ohledu na nasledky, neni to vykonova optimalizace. Je tu pro zjednoduseni sloziteho.

Ano, bozstvo rozhodlo o syntaxi. Jde snad navrhnout jazyk bez syntaxe? Rozhodli se ho udelat citelnejsi (a jednodussi) pro vsechny, to vyuziji jak blbecci, tak chytraci. Nedava smysl navrhovat necitelny jazyk, kdo by o nej stal? A pokud nejaky takovy masochista existuje, muze se realizovat ve strojovem kodu, tam si te necitelnosti uzije do sytosti. Neni pravda, ze je to za cenu flexibility. Porad mluvis o dictech. Tak v pythonu implementuj tu mou ukazku pomoci dictu. Uvidis sam, ze je to pomoci nizsi abstrakce mnohem pracnejsi a neprehlednejsi. Nechapu, jakou v tom vidis vyhodu? Jediny validni argument je vykon. Ale i ten, v pripade interpretovanych jazyku, hovori pro vyssi abstrakci.

Jak by sis takovy flexibilni nastroj pro power usery predstavoval?
Název: Re:Co si myslíte o OOP?
Přispěvatel: operator 24. 01. 2019, 06:28:07
Minoritni nazor. Tohle by bylo dobry tema. Mas pravdu ze muj nazor je minoritni. Ja se majoritnich nazoru stitim. Majoritni nazor je jako lemmings nebo ovce. Takova ovce nasleduje druhou ovci az se nasleduje cely stado a nakonec poskacou vsichni se srazu. Bud doslova nebo v nejaky financni krizi spadnou na hubu v akciich, nemovitostech, apod.
Jestli mohu doporucit, utvor si a zastavej vlastni nazory a neres, jestli jsou majoritni nebo minoritni, protoze oboji muze byt chybne i spravne.
Název: Re:Co si myslíte o OOP?
Přispěvatel: Mirek Prýmek 24. 01. 2019, 08:15:26
Rozdil je technicky, u posilani zprav muzu komunikovat skrze ruzna rozhrani, treba i socket a mit tak distribuovany system, za tuto flexibilitu se, jako vzdy, plati vykonem
To je pravda.

a navic je to komplikovanejsi na spravu.
Ne vždycky, záleží na okolnostech.

Např. v Erlangu je datový typ "Process Identifier" (PID), který se používá jako identifikátor adresáta zprávy a vždycky obsahuje i jakousi "adresu" VM, na které proces běží (v erlangovské terminologii "node"). Takže pokud chce proces A poslat nějakou zprávu procesu B, tak vůbec neřeší, kde B fyzicky běží - kód je stejný pro lokální i vzdálené volání. V principu tak můžeš libovolný proces vzít a přesunout někam jinam, bez změny kódu. Kdybys chtěl tohle udělat v systému s voláním metod, musíš mezi A a B vrazit dvě proxy. V nejhorším myslitelném případě dokonce specializované právě pro ten konkrétní objekt (call stub) a při jakékoliv změně B proxy taky překompilovat (to je pro správu dost peklo).

A tohle je právě jeden z technických důsledků toho zásadního rozdílu - předání informace se velice snadno zakóduje jakkoli (request může putovat klidně třeba mailem a A vůbec nepozná rozdíl), zatímco volání metody typicky využívá přímo instrukce procesoru, takže pokud chci udělat RPC, musím tam vrazit nějakou proxy, která to nafejkuje.

V praxi to pak dopadne tak, že když se rozhodneš monolit rozsekat na nějaké microservices (protože chceš mít tenhle buzzword v letáku), musíš:

1. systém zásadně přepsat (málo kdo to umí napsat dobře, protože to není triviální)
2. nemáš moc způsob, jak komunikaci sjednotit, takže skončíš s nějakým hrůzostrašným HTTP/JSON
3. ve finále teda jak blázen pořád převádíš interní datové struktury do JSONu a zpátky, což je ideální příležitost na domrvení dat, a třetinu energie spálíš na dumání nad tím, jak designovat HTTP endpointy
4. celé je to děsivě náročný proces jak z hlediska nároků na kvalitu designu/analýzy, tak z hlediska řízení exekuce

Srovnej s tím, že v Erlangu jenom tak "mimochodem" napsali distribuovanou databázi (Mnesia) s dost pokročilými vlastnostmi (failover, dynamické přidávání a odebírání nodů, změny způsobu replikace za běhu, ...), která je přímo součástí standardní knihovny. Protože jakmile máš podvozek, který umí skvěle distribuovat sám o sobě, není ta úloha tak těžká, spoustu problémů ti odpadne. Srovnej s mainstreamovými RDBMS, kde udělat to samý je na desetiletí a Turingovu cenu pro hlavního designéra...

(Samozřejmě, Mnesia má svoje problémy, netvrdím, že je to všespásné řešení, ale přijde mi to jako dobrá ilustrace)

Jaky je v tom rozdil ale pro navrh programu? Imho zadny, protoze z pohledu abstrakce je to to same. Tedy v pripade, ze se bude jednat o objekty v ramci jednoho programu.  U distribuovaneho systemu me to bude nutit delat co nejvetsi objekty s co nejdelsi zivotnosti.
I v rámci jednoho programu je rozdíl zásadní - buď píšu autonomní objekty, které se samy rozhodují, nebo píšu tupé recepty "když X, tak Y".
Název: Re:Co si myslíte o OOP?
Přispěvatel: operator 24. 01. 2019, 08:50:51
A tohle je právě jeden z technických důsledků toho zásadního rozdílu - předání informace se velice snadno zakóduje jakkoli (request může putovat klidně třeba mailem a A vůbec nepozná rozdíl), zatímco volání metody typicky využívá přímo instrukce procesoru, takže pokud chci udělat RPC, musím tam vrazit nějakou proxy, která to nafejkuje.
Ale tohle je jen technicky problem, nijak to nemeni abstrakci objektoveho programovani. Volani metod nebo posilani zprav jsou jen ruzne formy komunikace. Je to podobne jako staticke/dynamicke typy. Bud chci vykon nebo flexibilitu, ale ani jednim nenarusim paradigma proceduralniho/oop/funkcionalniho programovani. Posilani zprav je flexibilni, ale ani volanim metod nenarusim oop. Jestli je objekt autonomni nebo ne zalezi na jeho implementaci a ne na zpusobu, jakym komunikuje.
Název: Re:Co si myslíte o OOP?
Přispěvatel: Mirek Prýmek 24. 01. 2019, 09:18:26
Bud chci vykon nebo flexibilitu, ale ani jednim nenarusim paradigma proceduralniho/oop/funkcionalniho programovani. Posilani zprav je flexibilni, ale ani volanim metod nenarusim oop. Jestli je objekt autonomni nebo ne zalezi na jeho implementaci a ne na zpusobu, jakym komunikuje.
Ale jistě, pokud chceš, můžeš všechno. Ale pokud máš nějaké prostředky, tak jim design přizpůsobuješ. Pokud máš jako hlavní prostředek volání metod, tak se ti prostě nebude chtít jít třeba do té distribuovanosti (a je to racionální). Navíc tě to bude motivovat udělat rozhraní objektu určitým způsobem.

Jinými slovy: pokud sis zvolil menší flexibilitu, nebudeš dělat designová rozhodnutí, která by se dobře implementovala jedině v systému s větší flexibilitou. Ne že by to nešlo, ale "nazapadá to do sebe", nemělo by to logiku.

...no a protože mainstream staví jednoznačně na volání metod, tak se v sw inženýrství prosadily metody, které tomu odpovídají. A teprve teď, později, se učíme, jak se vlastně ty víc flexibilní systémy designují a implementují (to jsou právě třeba ty microservices, které jenom málo kdo dokáže navrhnout dobře, aniž by to udělal úplně tupě).
Název: Re:Co si myslíte o OOP?
Přispěvatel: operator 24. 01. 2019, 09:59:19
Bud chci vykon nebo flexibilitu, ale ani jednim nenarusim paradigma proceduralniho/oop/funkcionalniho programovani. Posilani zprav je flexibilni, ale ani volanim metod nenarusim oop. Jestli je objekt autonomni nebo ne zalezi na jeho implementaci a ne na zpusobu, jakym komunikuje.
Ale jistě, pokud chceš, můžeš všechno. Ale pokud máš nějaké prostředky, tak jim design přizpůsobuješ. Pokud máš jako hlavní prostředek volání metod, tak se ti prostě nebude chtít jít třeba do té distribuovanosti (a je to racionální). Navíc tě to bude motivovat udělat rozhraní objektu určitým způsobem.

Jinými slovy: pokud sis zvolil menší flexibilitu, nebudeš dělat designová rozhodnutí, která by se dobře implementovala jedině v systému s větší flexibilitou. Ne že by to nešlo, ale "nazapadá to do sebe", nemělo by to logiku.

...no a protože mainstream staví jednoznačně na volání metod, tak se v sw inženýrství prosadily metody, které tomu odpovídají. A teprve teď, později, se učíme, jak se vlastně ty víc flexibilní systémy designují a implementují (to jsou právě třeba ty microservices, které jenom málo kdo dokáže navrhnout dobře, aniž by to udělal úplně tupě).
Vzhledem k tomu, ze to neni zadarmo, tak tu distribuovatelnost chci jen v pripade, ze ji potrebuji a ne pro strycka prihodu co kdyby. Protoze zpomalit si signifikantne system jen pro strycka prihodu nedava smysl. Kdyz dospeju k tomu, ze distribuovatelnost potrebuji, stejne ji z toho duvodu zaridim jen mezi objekty, ktere ji potrebuji a ne mezi vsemi. Jo, neni to tak flexibilni, ale za to je to pouzitelne. Protoze kdyz scitam objekt 1 + objekt 1, tak to typicky nechci zatezovat pomalou komunikaci.

Ano, volani metod je omezujici, omezeni je vlastnosti efektivity. To same se tyka statickych a dynamickych typu, vykon s omezenim nebo flexibilita s pomalosti. Volani metod misto posilani zprav neni chyba, je to racionalni  rozhodnuti. Cas pro masivni posilani zprav prijde az s technologickym vyvojem IT, kdy nebude problem udrzovat statisice otevrenych spojeni a nebo je budeme umet navazovat bez ekonomicky podstatneho zpozdeni. Stejne jako cas dynamickych jazyku prisel az s tim, kdy vykon byl natolik levny, ze jejich pomalost prestala byt probkem a vyhoda jejich flexibility ekonomicky vyvazila nutnost vyssiho vykonu cpu.
Název: Re:Co si myslíte o OOP?
Přispěvatel: operator 24. 01. 2019, 10:05:57
...no a protože mainstream staví jednoznačně na volání metod, tak se v sw inženýrství prosadily metody, které tomu odpovídají. A teprve teď, později, se učíme, jak se vlastně ty víc flexibilní systémy designují a implementují (to jsou právě třeba ty microservices, které jenom málo kdo dokáže navrhnout dobře, aniž by to udělal úplně tupě).
To je proste proces. Az to bude v praxi pouzitelne a prinosne, tak se s tim lide nauci pracovat. Ne vsichni, nekteri zustanou zamrzli na oop realizovanem pomoci metod, stejne jako nekteri zustali zamrzli na statickych jazycich. Tak to proste je.
Název: Re:Co si myslíte o OOP?
Přispěvatel: Mirek Prýmek 24. 01. 2019, 10:31:36
Protoze kdyz scitam objekt 1 + objekt 1, tak to typicky nechci zatezovat pomalou komunikaci.
To ani není nutně potřeba. Zase příklad z Elixiru: komunikace pomocí zpráv se dělá jenom mezi procesy. V rámci jednoho procesu se dělá (víceméně) standardní volání funkcí.

Jinak ale celkem souhlas se vším, co píšeš.
Název: Re:Co si myslíte o OOP?
Přispěvatel: Youda 24. 01. 2019, 11:04:58
Protoze kdyz scitam objekt 1 + objekt 1, tak to typicky nechci zatezovat pomalou komunikaci.
To ani není nutně potřeba. Zase příklad z Elixiru: komunikace pomocí zpráv se dělá jenom mezi procesy. V rámci jednoho procesu se dělá (víceméně) standardní volání funkcí.

Jinak ale celkem souhlas se vším, co píšeš.

A priklad z Javy je napr. OSGi Container Apache Karaf v podani talend ESB, ktery taktez volani mezi jednotlivymi services v ramci jednoho node implemetuje jako proste volani metody, do externich nodes jako zpravy (z pohledu uzivatele transparentni volani metody). Routuje to tusim Apache Camel, nody jsou managovane via Apache Zookeeper.
Na kazdou mikroservicu kontrola RBAC a PEP (policy enforcement point)

Na papire velika krasa, v realite se to hrouti pod tihou byrokracie a je vyhodnejsi delat si distribuovane funkcni moduly sam. Takze hezky core + collectory + stream processing fronty + backend + GUI.
Cellou filosofii microservices poivazuju za mrtvy hype, vsechny tyhle pristupy stoji na premise, ze zaslani zpravy nestoji nic, resp je stejne levne jako zavolani lokalni metody v ramci JVM a ze je to stejne spolehlive.
Název: Re:Co si myslíte o OOP?
Přispěvatel: operator 24. 01. 2019, 11:42:57
Protoze kdyz scitam objekt 1 + objekt 1, tak to typicky nechci zatezovat pomalou komunikaci.
To ani není nutně potřeba. Zase příklad z Elixiru: komunikace pomocí zpráv se dělá jenom mezi procesy. V rámci jednoho procesu se dělá (víceméně) standardní volání funkcí.

Jinak ale celkem souhlas se vším, co píšeš.
Nutne neni potreba ani to posilani zprav. Resp. je potreba v minimu pripadu, kdy se vyplati ho implementovat rucne a proto je lepsi ho nemit by default. Ale rozlisoval bych mezi interni implementaci a abstrakci. V Pythonu treba cisla interne take ve skutecnosti nejsou objekty, to by byl o dost pomalejsi, ale vuci programatorovi se tak tvari a to je to, co se pocita, to je podle me podstatne, protoze to umoznuje programatorovi k programu pristupovat nejakym a jednotnym pristupem. Podle me je Python vyborne navrzen, vsechno je v nem objekt a definice tridy je zaroven definici datoveho typu. Pricemz k tomuto sjednoceni doslo az ve verzi 2.2, a po zbytek druhe generace v nem byly objekty dvojiho typu. Cesta k jeho dobremu navrhu je lemovana chybami a odvahou prinaset nekompatibilni zmeny. Az nastane cas na posilani zprav mezi objekty, python prijde s flexibilnim funkcnim resenim. Ted je na poradu dne spise asynchronni komunikace, kterou python pred casem adoptoval a ted se ladi.
Název: Re:Co si myslíte o OOP?
Přispěvatel: v 24. 01. 2019, 13:03:06
Ted je na poradu dne spise asynchronni komunikace, kterou python pred casem adoptoval a ted se ladi.
jestli je tím myšleno asyncio, tak tady je IMO python hodně pozadu, srovnejte s erlangem, haskellem a asi go
Název: Re:Co si myslíte o OOP?
Přispěvatel: Kadet 24. 01. 2019, 13:11:56
Dneska je programovani zhruba na urovni pred Kopernikem, takze se od tech majoritnich cirkevnich nazoru distancuju.
Jak myslíš, no. Já bych si spíš vsadil, že to ještě v průběhu života přehodnotíš, ale třeba bych prohrál :)
Jakmile vidis, ze to na co lidi pouzivaji tisice az miliony radku kodu jde pouzit par set nebo mozna nizkych tisic, a udelat to zaroven jednodussi, rychlejsi, citelnejsi, tak prehodnotis.

Jestli v programovani existuje silver bullet, pak bych bych vsadil hodne na to, ze to bude jednoduchost (simplicity).
Presne na tohle je dobra vyssi abstrakce, kterou nazyvas nadbytecny syntakticky cukr. Porad to vnimam tak, ze si protirecis.

Az vyresis tuhle kontradikci, naleznes nirvanu.

Syntakticky cukr je derava abstrakce. Dostanes jednu abstrakci dnes, ale uz z ni zitra nevytvoris jeste vyssi abstrakci. Pro nederavy abstrakce potrebujes vysoce kompozitabilni stavebni bloky, napr. nekdo zminil nor nebo mov nebo funkce. Ty slozis do vyssich abstraktnich bloku, ty jeste do vyssich, atd.
Tridy a objekty jsou derava abstrakce. Je to videt kdyz zjistis ze najednou potrebujes metatridy a tvuj jazyk je nema. Smalltalk tridy mozna deravy nejsou, ale ve vetsine jazyku je to abstraktni dira.
Název: Re:Co si myslíte o OOP?
Přispěvatel: Inkvizitor 24. 01. 2019, 13:24:47
Tridy a objekty jsou derava abstrakce. Je to videt kdyz zjistis ze najednou potrebujes metatridy a tvuj jazyk je nema. Smalltalk tridy mozna deravy nejsou, ale ve vetsine jazyku je to abstraktni dira.

Ve skutecnosti metatridy prakticky nikomu nechybi.
Název: Re:Co si myslíte o OOP?
Přispěvatel: operator 24. 01. 2019, 13:35:52
Ted je na poradu dne spise asynchronni komunikace, kterou python pred casem adoptoval a ted se ladi.
jestli je tím myšleno asyncio, tak tady je IMO python hodně pozadu, srovnejte s erlangem, haskellem a asi go
Pozadu je, ale dotahuje se, s kazdou verzi se to vylepšuje. Asyncio je modelova knihovna. Soucasti jazyka se staly prikazy async a await a pracuje se na jejich hlubsi integraci do systemu. Python jde evolucni cestou vyvoje, takze se nejprve vyzkousi koncept, pak se to implementuje jako modul, pak se to zavede do jazyka, a nakonec se to v nem usazuje a prorusta do systemu. Stejne tak to probihalo u dalsich abstrakci, u novych trid, iteratoru, generatoru, type hintingu. Je to jen otazka casu.
Název: Re:Co si myslíte o OOP?
Přispěvatel: Kadet 24. 01. 2019, 13:40:16
Poslednich par stranek je rozprava o tom jestli je lepsi poslani zpravy nebo zavolani metody. Jednak u toho litaji ruzny interpretace, jednak jestli to bezi uvnitr pocitace nebo vne mezi pocitaci. Bylo by to fajn klasifikovat.

Podobna debata by mohla byt nad tvrdou konzistenci a eventualni konzistenci (eventual consistency). Poslani zpravy je fire and forget. Erlang system mi da dobrej zaklad postavit microservice system, to jo. Ale tezka cast je udelat v tom skutecne konzistentni system, protoze to je to, co uzivatele nebo programatora, co koordinuje jednotky takovyho systemu, zajima. Nezajima ho, ze nekdy ta zprava nekdy dorazi, nekdy mozna ne. Tvrde konzistentni system je RPC nebo taky jinak receno 'zavolani metody' neboli dve zpravy, jedna odesilajici request a druha prijimajici response, obe provazany nejakym reauest-id.

Problem s microservices je matematicka nemoznost provest exactly-once-delivery s omezenou pameti.

Takze posilani zprav je jen potencialni prvni krok k tomu dostat se k nejakymu funkcnimu systemu. Chapu, kdyz se s Erlangem/Elixirem nekdo uci, tak je to ze zacatku wow.

Pokusy v posledni dobe vytvorit NoSQL eventual consistency databaze spadly na hubu, nikdo je nechce pouzivat a ted Google prisel se Spannerem, kterej dela tvrdou konzistenci napric kontinenty diky tomu ze na to ma dedikovanej hardware.
Název: Re:Co si myslíte o OOP?
Přispěvatel: Mirek Prýmek 24. 01. 2019, 13:42:57
Az nastane cas na posilani zprav mezi objekty, python prijde s flexibilnim funkcnim resenim. Ted je na poradu dne spise asynchronni komunikace, kterou python pred casem adoptoval a ted se ladi.
S tím se asi nedá nesouhlasit. Stejně jako s tím asyncio, kdy Python teď ladí něco, co jinde už deset let funguje :) Zasílání zpráv je už teď (Pykka), akorát je to neúplná omezená implementace Akka, což je neúplná omezená implementace toho, co má Erlang víc než dvacet let :)

Takže jo, možná za deset let Python nějakou aspoň jakžtakž použitelnou implementaci mít možná bude. (Teda za předpokladu, že benevolentní diktátor nesdělí poddaným Pravdu, že to je od základů špatný přístup a proto to v Pythonu nikdy nebude :) )
Název: Re:Co si myslíte o OOP?
Přispěvatel: Mirek Prýmek 24. 01. 2019, 13:44:22
jestli je tím myšleno asyncio, tak tady je IMO python hodně pozadu, srovnejte s erlangem, haskellem a asi go
Co Erlang a Haskell... Node.js už tady máme 9 (slovy: devět) let! ;)
Název: Re:Co si myslíte o OOP?
Přispěvatel: v 24. 01. 2019, 13:52:02
jestli je tím myšleno asyncio, tak tady je IMO python hodně pozadu, srovnejte s erlangem, haskellem a asi go
Co Erlang a Haskell... Node.js už tady máme 9 (slovy: devět) let! ;)
já jsem hlavně narážel na nutnost psát explicitně všelijaké ty async/await, když erlang má lightweight vlákna přes 30 let
Název: Re:Co si myslíte o OOP?
Přispěvatel: operator 24. 01. 2019, 13:59:15
Dneska je programovani zhruba na urovni pred Kopernikem, takze se od tech majoritnich cirkevnich nazoru distancuju.
Jak myslíš, no. Já bych si spíš vsadil, že to ještě v průběhu života přehodnotíš, ale třeba bych prohrál :)
Jakmile vidis, ze to na co lidi pouzivaji tisice az miliony radku kodu jde pouzit par set nebo mozna nizkych tisic, a udelat to zaroven jednodussi, rychlejsi, citelnejsi, tak prehodnotis.

Jestli v programovani existuje silver bullet, pak bych bych vsadil hodne na to, ze to bude jednoduchost (simplicity).
Presne na tohle je dobra vyssi abstrakce, kterou nazyvas nadbytecny syntakticky cukr. Porad to vnimam tak, ze si protirecis.

Az vyresis tuhle kontradikci, naleznes nirvanu.

Syntakticky cukr je derava abstrakce. Dostanes jednu abstrakci dnes, ale uz z ni zitra nevytvoris jeste vyssi abstrakci. Pro nederavy abstrakce potrebujes vysoce kompozitabilni stavebni bloky, napr. nekdo zminil nor nebo mov nebo funkce. Ty slozis do vyssich abstraktnich bloku, ty jeste do vyssich, atd.
Tridy a objekty jsou derava abstrakce. Je to videt kdyz zjistis ze najednou potrebujes metatridy a tvuj jazyk je nema. Smalltalk tridy mozna deravy nejsou, ale ve vetsine jazyku je to abstraktni dira.
Nerozumim pojmu derava abstrakce?
Jak vis co bude zitra?
Nad objekty jako abstrakce imho stoji komponenty. Ale neni nutne aby nad kazdou abstrakci byla jeste vyssi, resp. aby kazda abstrakce byla soucasti ci stavebnim kamenem vyssi abstrakce.
Metatrida je spise implementacni detail, druh tridy za nejakym ucelem, podobne jako je treba abstraktni trida, nez nova vyssi abstrakce. Python manipulaci s metatridami umoznuje, ale myslim ze jsem toho nikdy nevyuzil, takze se nedivim, ze v jinych jazycich nejsou k dispozici. Pokud by to byl problem, je dusledkem nedostatecne implementace, nikoliv chybne abstrakce.
V cem je objekt derava abstrakce?
Trida je derava abstrakce ale smalltalk trida derava neni? Zase si protirecis.
Název: Re:Co si myslíte o OOP?
Přispěvatel: operator 24. 01. 2019, 14:17:06
jestli je tím myšleno asyncio, tak tady je IMO python hodně pozadu, srovnejte s erlangem, haskellem a asi go
Co Erlang a Haskell... Node.js už tady máme 9 (slovy: devět) let! ;)
já jsem hlavně narážel na nutnost psát explicitně všelijaké ty async/await, když erlang má lightweight vlákna přes 30 let
Mozna ma a nic mu to nebylo platny. :-) Python ma greenlety uz taky nejaky rok, o tom to preci neni.
Název: Re:Co si myslíte o OOP?
Přispěvatel: v 24. 01. 2019, 14:27:51
jestli je tím myšleno asyncio, tak tady je IMO python hodně pozadu, srovnejte s erlangem, haskellem a asi go
Co Erlang a Haskell... Node.js už tady máme 9 (slovy: devět) let! ;)
já jsem hlavně narážel na nutnost psát explicitně všelijaké ty async/await, když erlang má lightweight vlákna přes 30 let
Mozna ma a nic mu to nebylo platny. :-) Python ma greenlety uz taky nejaky rok, o tom to preci neni.
greenlet jsem neznal, nicméně to nevypadá jako skutečné lightweight vlákno, chybí mi ta abstrakce vlákna
Název: Re:Co si myslíte o OOP?
Přispěvatel: operator 24. 01. 2019, 14:32:36
jestli je tím myšleno asyncio, tak tady je IMO python hodně pozadu, srovnejte s erlangem, haskellem a asi go
Co Erlang a Haskell... Node.js už tady máme 9 (slovy: devět) let! ;)
Node.js neni univerzalni, je orientovan na web. V tomto smeru nabizi Python treba Tornado a Twisted. Ale to je take jednoucelove reseni. Reseni na urovni jazyka je samozrejme lepsi.
Název: Re:Co si myslíte o OOP?
Přispěvatel: gll 24. 01. 2019, 14:34:50
chybí mi ta abstrakce vlákna

to by mělo vypadat jak?
Název: Re:Co si myslíte o OOP?
Přispěvatel: Kadet 24. 01. 2019, 14:35:52
Dneska je programovani zhruba na urovni pred Kopernikem, takze se od tech majoritnich cirkevnich nazoru distancuju.
Jak myslíš, no. Já bych si spíš vsadil, že to ještě v průběhu života přehodnotíš, ale třeba bych prohrál :)
Jakmile vidis, ze to na co lidi pouzivaji tisice az miliony radku kodu jde pouzit par set nebo mozna nizkych tisic, a udelat to zaroven jednodussi, rychlejsi, citelnejsi, tak prehodnotis.

Jestli v programovani existuje silver bullet, pak bych bych vsadil hodne na to, ze to bude jednoduchost (simplicity).
Presne na tohle je dobra vyssi abstrakce, kterou nazyvas nadbytecny syntakticky cukr. Porad to vnimam tak, ze si protirecis.

Az vyresis tuhle kontradikci, naleznes nirvanu.

Syntakticky cukr je derava abstrakce. Dostanes jednu abstrakci dnes, ale uz z ni zitra nevytvoris jeste vyssi abstrakci. Pro nederavy abstrakce potrebujes vysoce kompozitabilni stavebni bloky, napr. nekdo zminil nor nebo mov nebo funkce. Ty slozis do vyssich abstraktnich bloku, ty jeste do vyssich, atd.
Tridy a objekty jsou derava abstrakce. Je to videt kdyz zjistis ze najednou potrebujes metatridy a tvuj jazyk je nema. Smalltalk tridy mozna deravy nejsou, ale ve vetsine jazyku je to abstraktni dira.
Nerozumim pojmu derava abstrakce?
Jak vis co bude zitra?
Nad objekty jako abstrakce imho stoji komponenty. Ale neni nutne aby nad kazdou abstrakci byla jeste vyssi, resp. aby kazda abstrakce byla soucasti ci stavebnim kamenem vyssi abstrakce.
Metatrida je spise implementacni detail, druh tridy za nejakym ucelem, podobne jako je treba abstraktni trida, nez nova vyssi abstrakce. Python manipulaci s metatridami umoznuje, ale myslim ze jsem toho nikdy nevyuzil, takze se nedivim, ze v jinych jazycich nejsou k dispozici. Pokud by to byl problem, je dusledkem nedostatecne implementace, nikoliv chybne abstrakce.
V cem je objekt derava abstrakce?
Trida je derava abstrakce ale smalltalk trida derava neni? Zase si protirecis.

Me tridy nezajimaji, ja je nepouzivam a nejsem na ne expert. Deravy jsou protoze treba nezvladnou dedit z vic rodicu. Nektery jo, protoze maji lrpsi implementaci coz je sada hacku a uz se to nabaluje.

Ja jsem tvrdil ze cukr je derava abstrakce, tridy  vem cert.

Derava abstrakce je takova ze ktery neposkladas jeste vyssi abstrakci. Ne vsechny pripady, protoze tam je dira. Treba te to nezajima protoze matlas kod a pouzivas k tomu abstrakce od jinych lidi. Lidi co ale tvori abstrakce hodne zajima jestli k tomu maji dostatecny nastroje.
Název: Re:Co si myslíte o OOP?
Přispěvatel: v 24. 01. 2019, 14:51:07
chybí mi ta abstrakce vlákna

to by mělo vypadat jak?
jako normální vlákno
Kód: [Vybrat]
forkIO $ forever $ do
  writeChan tx "hello"
  response <- readChan rx
  print response
a není poznat, že to není plnotučné vlákno a místo kanálů může být třeba socket nebo stdin
Název: Re:Co si myslíte o OOP?
Přispěvatel: Kit 24. 01. 2019, 14:54:36
Deravy jsou protoze treba nezvladnou dedit z vic rodicu. Nektery jo, protoze maji lrpsi implementaci coz je sada hacku a uz se to nabaluje.

Ja jsem tvrdil ze cukr je derava abstrakce, tridy  vem cert.

Derava abstrakce je takova ze ktery neposkladas jeste vyssi abstrakci. Ne vsechny pripady, protoze tam je dira. Treba te to nezajima protoze matlas kod a pouzivas k tomu abstrakce od jinych lidi. Lidi co ale tvori abstrakce hodne zajima jestli k tomu maji dostatecny nastroje.

Proč by měly mít třídy možnost dědit od více rodičů? Mohl bys uvést nějaký příklad, kde by to mohlo být k něčemu dobré?
Název: Re:Co si myslíte o OOP?
Přispěvatel: Mirek Prýmek 24. 01. 2019, 15:02:12
Node.js neni univerzalni, je orientovan na web.
Webem to možná začalo, dneska už je to stejně univerzální platforma jako Python.

A i kdyby: devět let, to je v IT celá věčnost.
Název: Re:Co si myslíte o OOP?
Přispěvatel: Kadet 24. 01. 2019, 15:07:35
Deravy jsou protoze treba nezvladnou dedit z vic rodicu. Nektery jo, protoze maji lrpsi implementaci coz je sada hacku a uz se to nabaluje.

Ja jsem tvrdil ze cukr je derava abstrakce, tridy  vem cert.

Derava abstrakce je takova ze ktery neposkladas jeste vyssi abstrakci. Ne vsechny pripady, protoze tam je dira. Treba te to nezajima protoze matlas kod a pouzivas k tomu abstrakce od jinych lidi. Lidi co ale tvori abstrakce hodne zajima jestli k tomu maji dostatecny nastroje.

Proč by měly mít třídy možnost dědit od více rodičů? Mohl bys uvést nějaký příklad, kde by to mohlo být k něčemu dobré?

Muzes mit nekolik Mixin trid a chces je ppuzit vsechny napriklad.

Ano muzes tady pouzit kompozici misto dedicnosti. Tim se vracime k tomu, ze muzes pouzit proste dict, protoze to vyjde nastejno.

Trida neco neumoznuje (derava abstrakce), ale potrebuju toho stejne dosahnout. Musim to ochcat pres kompozici a najednou mam dva zpusoby jak neco resit. Proc nevyhodit ten deravej zpusob a nenechat jen kompozici.
Název: Re:Co si myslíte o OOP?
Přispěvatel: operator 24. 01. 2019, 15:18:12
Dneska je programovani zhruba na urovni pred Kopernikem, takze se od tech majoritnich cirkevnich nazoru distancuju.
Jak myslíš, no. Já bych si spíš vsadil, že to ještě v průběhu života přehodnotíš, ale třeba bych prohrál :)
Jakmile vidis, ze to na co lidi pouzivaji tisice az miliony radku kodu jde pouzit par set nebo mozna nizkych tisic, a udelat to zaroven jednodussi, rychlejsi, citelnejsi, tak prehodnotis.

Jestli v programovani existuje silver bullet, pak bych bych vsadil hodne na to, ze to bude jednoduchost (simplicity).
Presne na tohle je dobra vyssi abstrakce, kterou nazyvas nadbytecny syntakticky cukr. Porad to vnimam tak, ze si protirecis.

Az vyresis tuhle kontradikci, naleznes nirvanu.

Syntakticky cukr je derava abstrakce. Dostanes jednu abstrakci dnes, ale uz z ni zitra nevytvoris jeste vyssi abstrakci. Pro nederavy abstrakce potrebujes vysoce kompozitabilni stavebni bloky, napr. nekdo zminil nor nebo mov nebo funkce. Ty slozis do vyssich abstraktnich bloku, ty jeste do vyssich, atd.
Tridy a objekty jsou derava abstrakce. Je to videt kdyz zjistis ze najednou potrebujes metatridy a tvuj jazyk je nema. Smalltalk tridy mozna deravy nejsou, ale ve vetsine jazyku je to abstraktni dira.
Nerozumim pojmu derava abstrakce?
Jak vis co bude zitra?
Nad objekty jako abstrakce imho stoji komponenty. Ale neni nutne aby nad kazdou abstrakci byla jeste vyssi, resp. aby kazda abstrakce byla soucasti ci stavebnim kamenem vyssi abstrakce.
Metatrida je spise implementacni detail, druh tridy za nejakym ucelem, podobne jako je treba abstraktni trida, nez nova vyssi abstrakce. Python manipulaci s metatridami umoznuje, ale myslim ze jsem toho nikdy nevyuzil, takze se nedivim, ze v jinych jazycich nejsou k dispozici. Pokud by to byl problem, je dusledkem nedostatecne implementace, nikoliv chybne abstrakce.
V cem je objekt derava abstrakce?
Trida je derava abstrakce ale smalltalk trida derava neni? Zase si protirecis.

Me tridy nezajimaji, ja je nepouzivam a nejsem na ne expert. Deravy jsou protoze treba nezvladnou dedit z vic rodicu. Nektery jo, protoze maji lrpsi implementaci coz je sada hacku a uz se to nabaluje.

Ja jsem tvrdil ze cukr je derava abstrakce, tridy  vem cert.

Derava abstrakce je takova ze ktery neposkladas jeste vyssi abstrakci. Ne vsechny pripady, protoze tam je dira. Treba te to nezajima protoze matlas kod a pouzivas k tomu abstrakce od jinych lidi. Lidi co ale tvori abstrakce hodne zajima jestli k tomu maji dostatecny nastroje.
Tridy jako abstrakce vicenasobnou dedicnost umoznuji. Ze to nektere jazyky neimplementuji neni chyba abstrakce.

Tvrdil jsi, ze tridy a objekty jsou derava abstrakce. Cukr a kafe abstrakce neni.
Ok, derava abstrakce je takova, ktera neslouzi jako zaklad vyssi abstrakce. V tom pripade na nich neni nic spatneho.
Abstrakce tvori kazdy programator, ktery pouziva tridy. Takze nevim jestli ty jo, kdyz je nepouzivas, ja ale ano.
Název: Re:Co si myslíte o OOP?
Přispěvatel: operator 24. 01. 2019, 15:20:37
Deravy jsou protoze treba nezvladnou dedit z vic rodicu. Nektery jo, protoze maji lrpsi implementaci coz je sada hacku a uz se to nabaluje.

Ja jsem tvrdil ze cukr je derava abstrakce, tridy  vem cert.

Derava abstrakce je takova ze ktery neposkladas jeste vyssi abstrakci. Ne vsechny pripady, protoze tam je dira. Treba te to nezajima protoze matlas kod a pouzivas k tomu abstrakce od jinych lidi. Lidi co ale tvori abstrakce hodne zajima jestli k tomu maji dostatecny nastroje.
Proč by měly mít třídy možnost dědit od více rodičů? Mohl bys uvést nějaký příklad, kde by to mohlo být k něčemu dobré?
To se hodi, protoze takovy potomek muze nahradit vic ruznych predku soucasne.
Název: Re:Co si myslíte o OOP?
Přispěvatel: operator 24. 01. 2019, 15:22:29
Node.js neni univerzalni, je orientovan na web.
Webem to možná začalo, dneska už je to stejně univerzální platforma jako Python.
A i kdyby: devět let, to je v IT celá věčnost.
Ok, podivam se na dostupne knihovny, treba podporu midi komunikace.
Název: Re:Co si myslíte o OOP?
Přispěvatel: operator 24. 01. 2019, 15:25:08
Ano muzes tady pouzit kompozici misto dedicnosti. Tim se vracime k tomu, ze muzes pouzit proste dict, protoze to vyjde nastejno.

Trida neco neumoznuje (derava abstrakce), ale potrebuju toho stejne dosahnout. Musim to ochcat pres kompozici a najednou mam dva zpusoby jak neco resit. Proc nevyhodit ten deravej zpusob a nenechat jen kompozici.
Tohle tvrzeni jsi neprokazal. Implementuj ukazku, co jsem ti predlozil, pomoci dictu a uvidime, jestli to vyjde na stejno. Ja tvrdim ze ne. Ale treba mi neco unika a dokazes to.
Název: Re:Co si myslíte o OOP?
Přispěvatel: Kit 24. 01. 2019, 16:04:44
Deravy jsou protoze treba nezvladnou dedit z vic rodicu. Nektery jo, protoze maji lrpsi implementaci coz je sada hacku a uz se to nabaluje.

Ja jsem tvrdil ze cukr je derava abstrakce, tridy  vem cert.

Derava abstrakce je takova ze ktery neposkladas jeste vyssi abstrakci. Ne vsechny pripady, protoze tam je dira. Treba te to nezajima protoze matlas kod a pouzivas k tomu abstrakce od jinych lidi. Lidi co ale tvori abstrakce hodne zajima jestli k tomu maji dostatecny nastroje.

Proč by měly mít třídy možnost dědit od více rodičů? Mohl bys uvést nějaký příklad, kde by to mohlo být k něčemu dobré?

Muzes mit nekolik Mixin trid a chces je ppuzit vsechny napriklad.

Ano muzes tady pouzit kompozici misto dedicnosti. Tim se vracime k tomu, ze muzes pouzit proste dict, protoze to vyjde nastejno.

Trida neco neumoznuje (derava abstrakce), ale potrebuju toho stejne dosahnout. Musim to ochcat pres kompozici a najednou mam dva zpusoby jak neco resit. Proc nevyhodit ten deravej zpusob a nenechat jen kompozici.

Vývojář by se měl především zamyslet nad tím, zda takové mixiny nejsou logickým nesmyslem. Mohl bys uvést nějaký příklad, kde by to mohlo být k něčemu dobré?
Název: Re:Co si myslíte o OOP?
Přispěvatel: Kit 24. 01. 2019, 16:10:03
Deravy jsou protoze treba nezvladnou dedit z vic rodicu. Nektery jo, protoze maji lrpsi implementaci coz je sada hacku a uz se to nabaluje.

Ja jsem tvrdil ze cukr je derava abstrakce, tridy  vem cert.

Derava abstrakce je takova ze ktery neposkladas jeste vyssi abstrakci. Ne vsechny pripady, protoze tam je dira. Treba te to nezajima protoze matlas kod a pouzivas k tomu abstrakce od jinych lidi. Lidi co ale tvori abstrakce hodne zajima jestli k tomu maji dostatecny nastroje.
Proč by měly mít třídy možnost dědit od více rodičů? Mohl bys uvést nějaký příklad, kde by to mohlo být k něčemu dobré?
To se hodi, protoze takovy potomek muze nahradit vic ruznych predku soucasne.

Mohl bys uvést nějaký příklad, kde by to mohlo být k něčemu dobré?
Název: Re:Co si myslíte o OOP?
Přispěvatel: operator 24. 01. 2019, 16:10:14
Deravy jsou protoze treba nezvladnou dedit z vic rodicu. Nektery jo, protoze maji lrpsi implementaci coz je sada hacku a uz se to nabaluje.

Ja jsem tvrdil ze cukr je derava abstrakce, tridy  vem cert.

Derava abstrakce je takova ze ktery neposkladas jeste vyssi abstrakci. Ne vsechny pripady, protoze tam je dira. Treba te to nezajima protoze matlas kod a pouzivas k tomu abstrakce od jinych lidi. Lidi co ale tvori abstrakce hodne zajima jestli k tomu maji dostatecny nastroje.

Proč by měly mít třídy možnost dědit od více rodičů? Mohl bys uvést nějaký příklad, kde by to mohlo být k něčemu dobré?

Muzes mit nekolik Mixin trid a chces je ppuzit vsechny napriklad.

Ano muzes tady pouzit kompozici misto dedicnosti. Tim se vracime k tomu, ze muzes pouzit proste dict, protoze to vyjde nastejno.

Trida neco neumoznuje (derava abstrakce), ale potrebuju toho stejne dosahnout. Musim to ochcat pres kompozici a najednou mam dva zpusoby jak neco resit. Proc nevyhodit ten deravej zpusob a nenechat jen kompozici.

Vývojář by se měl především zamyslet nad tím, zda takové mixiny nejsou logickým nesmyslem. Mohl bys uvést nějaký příklad, kde by to mohlo být k něčemu dobré?
Mas tridu Plavidlo a Vozidlo a potrebujes vytvorit tridu Obojzivelnik(Vozidlo, Plavidlo).
Název: Re:Co si myslíte o OOP?
Přispěvatel: operator 24. 01. 2019, 16:20:44
Node.js neni univerzalni, je orientovan na web.
Webem to možná začalo, dneska už je to stejně univerzální platforma jako Python.
A i kdyby: devět let, to je v IT celá věčnost.
Ok, podivam se na dostupne knihovny, treba podporu midi komunikace.
Takze neco na hrani ma, ale asi to nebude pouzitelny kvuli latenci: https://stackoverflow.com/questions/44741879/node-midi-i-o-module-has-a-slight-latency Ze by prave kvuli async io? Jde to vypnout?
Název: Re:Co si myslíte o OOP?
Přispěvatel: Kit 24. 01. 2019, 16:30:28
Vývojář by se měl především zamyslet nad tím, zda takové mixiny nejsou logickým nesmyslem. Mohl bys uvést nějaký příklad, kde by to mohlo být k něčemu dobré?
Mas tridu Plavidlo a Vozidlo a potrebujes vytvorit tridu Obojzivelnik(Vozidlo, Plavidlo).

Obojživelník je buď Vozidlo, které umí i plavat, anebo Plavidlo, které umí jezdit po silnici. V obou případech pouze kompozicí doplním požadovanou vlastnost.

Ber v potaz, že LSP tohle zakazuje, včetně tvého požadavku. Obojživelník, Vozidlo i Plavidlo jsou DopravníProstředky.
Název: Re:Co si myslíte o OOP?
Přispěvatel: Kadet 24. 01. 2019, 16:31:56
Dneska je programovani zhruba na urovni pred Kopernikem, takze se od tech majoritnich cirkevnich nazoru distancuju.
Jak myslíš, no. Já bych si spíš vsadil, že to ještě v průběhu života přehodnotíš, ale třeba bych prohrál :)
Jakmile vidis, ze to na co lidi pouzivaji tisice az miliony radku kodu jde pouzit par set nebo mozna nizkych tisic, a udelat to zaroven jednodussi, rychlejsi, citelnejsi, tak prehodnotis.

Jestli v programovani existuje silver bullet, pak bych bych vsadil hodne na to, ze to bude jednoduchost (simplicity).
Presne na tohle je dobra vyssi abstrakce, kterou nazyvas nadbytecny syntakticky cukr. Porad to vnimam tak, ze si protirecis.

Az vyresis tuhle kontradikci, naleznes nirvanu.

Syntakticky cukr je derava abstrakce. Dostanes jednu abstrakci dnes, ale uz z ni zitra nevytvoris jeste vyssi abstrakci. Pro nederavy abstrakce potrebujes vysoce kompozitabilni stavebni bloky, napr. nekdo zminil nor nebo mov nebo funkce. Ty slozis do vyssich abstraktnich bloku, ty jeste do vyssich, atd.
Tridy a objekty jsou derava abstrakce. Je to videt kdyz zjistis ze najednou potrebujes metatridy a tvuj jazyk je nema. Smalltalk tridy mozna deravy nejsou, ale ve vetsine jazyku je to abstraktni dira.
Nerozumim pojmu derava abstrakce?
Jak vis co bude zitra?
Nad objekty jako abstrakce imho stoji komponenty. Ale neni nutne aby nad kazdou abstrakci byla jeste vyssi, resp. aby kazda abstrakce byla soucasti ci stavebnim kamenem vyssi abstrakce.
Metatrida je spise implementacni detail, druh tridy za nejakym ucelem, podobne jako je treba abstraktni trida, nez nova vyssi abstrakce. Python manipulaci s metatridami umoznuje, ale myslim ze jsem toho nikdy nevyuzil, takze se nedivim, ze v jinych jazycich nejsou k dispozici. Pokud by to byl problem, je dusledkem nedostatecne implementace, nikoliv chybne abstrakce.
V cem je objekt derava abstrakce?
Trida je derava abstrakce ale smalltalk trida derava neni? Zase si protirecis.

Me tridy nezajimaji, ja je nepouzivam a nejsem na ne expert. Deravy jsou protoze treba nezvladnou dedit z vic rodicu. Nektery jo, protoze maji lrpsi implementaci coz je sada hacku a uz se to nabaluje.

Ja jsem tvrdil ze cukr je derava abstrakce, tridy  vem cert.

Derava abstrakce je takova ze ktery neposkladas jeste vyssi abstrakci. Ne vsechny pripady, protoze tam je dira. Treba te to nezajima protoze matlas kod a pouzivas k tomu abstrakce od jinych lidi. Lidi co ale tvori abstrakce hodne zajima jestli k tomu maji dostatecny nastroje.
Tridy jako abstrakce vicenasobnou dedicnost umoznuji. Ze to nektere jazyky neimplementuji neni chyba abstrakce.

Tvrdil jsi, ze tridy a objekty jsou derava abstrakce. Cukr a kafe abstrakce neni.
Ok, derava abstrakce je takova, ktera neslouzi jako zaklad vyssi abstrakce. V tom pripade na nich neni nic spatneho.
Abstrakce tvori kazdy programator, ktery pouziva tridy. Takze nevim jestli ty jo, kdyz je nepouzivas, ja ale ano.

Pokud mas teda jazyk postavenej na neuplny implementaci tridy pak je ten jazyk deravej v abstrakcich. Zapomen na to jestli jsem neco tvrdil o deravych tridach protoze jsme se nikdy neshodli na tom jestli se bavime o implementaci nebo koncepci. Tridu jako abstrakci muzu implementovat pouhym dictem metod a seznamem jak jsem zminil. Tvrdim akorat ze cukr je deravy a tvrdim ze vzdy.
O tridach a objektech tvrdim ze existuje jednodussi mechanismus na kterym zalozit bazi jazyka - napr. prototypy. Clovek pak v implementaci nemusi resit rozdil mezi objektem a tridou, pouze mezi built-in a derivovanym objektem.
Název: Re:Co si myslíte o OOP?
Přispěvatel: Mirek Prýmek 24. 01. 2019, 16:35:18
Obojživelník, Vozidlo i Plavidlo jsou DopravníProstředky.
A jsme na standardní vlně "OOP debaty" :))) Dávám tomu tak dvě stránky, než začnete řešit, jestli má čtverec dědit z obdélníka nebo naopak :)))
Název: Re:Co si myslíte o OOP?
Přispěvatel: Kit 24. 01. 2019, 16:41:26
O tridach a objektech tvrdim ze existuje jednodussi mechanismus na kterym zalozit bazi jazyka - napr. prototypy. Clovek pak v implementaci nemusi resit rozdil mezi objektem a tridou, pouze mezi built-in a derivovanym objektem.

Třídy a objekty jsou užitečnou abstrakcí. V PHP bych mohl používat objekty i bez tříd, ale dává to smysl jen v určitých případech. Obecně je výhodné mít třídy a používat je jako vzor pro vytváření instancí. Pokud někdo používá statické atributy a metody, tak se o jednu úroveň abstrakce zbytečně ochuzuje.
Název: Re:Co si myslíte o OOP?
Přispěvatel: operator 24. 01. 2019, 16:41:38
Obojživelník, Vozidlo i Plavidlo jsou DopravníProstředky.
A jsme na standardní vlně "OOP debaty" :))) Dávám tomu tak dvě stránky, než začnete řešit, jestli má čtverec dědit z obdélníka nebo naopak :)))
Pro vetsinu aplikaci to jsou sourozenci se spolecnym predkem.
Název: Re:Co si myslíte o OOP?
Přispěvatel: v 24. 01. 2019, 16:42:02
Obojživelník, Vozidlo i Plavidlo jsou DopravníProstředky.
A jsme na standardní vlně "OOP debaty" :))) Dávám tomu tak dvě stránky, než začnete řešit, jestli má čtverec dědit z obdélníka nebo naopak :)))
projektový manažer:
  "náš další projekt je informační systém pro veterinární kliniku"
vývojář:
  "a je to tu! na tohle jsi tak dlouho trénoval!
    class Dog implements Animal
        ... "
Název: Re:Co si myslíte o OOP?
Přispěvatel: Kit 24. 01. 2019, 16:47:25
Obojživelník, Vozidlo i Plavidlo jsou DopravníProstředky.
A jsme na standardní vlně "OOP debaty" :))) Dávám tomu tak dvě stránky, než začnete řešit, jestli má čtverec dědit z obdélníka nebo naopak :)))

Ani jedno :)

Tématem je, co si myslíme o OOP. Jak tady někdo začne s diamanty, tak je jasné, že něco navrhuje blbě. Dědičnost je užitečná, ale její nadužívání je škodlivé. Máme tady třídu Obojživelník, Vozidlo a Plavidlo. Ze které z nich bude dědit třída Letadlo?
Název: Re:Co si myslíte o OOP?
Přispěvatel: Mirek Prýmek 24. 01. 2019, 16:50:23
vývojář:
  "a je to tu! na tohle jsi tak dlouho trénoval!
    class Dog implements Animal
        ... "
vývojář 2: Vůbec nerozumíš OOP návrhu! Dog má samozřejmě dědit z HairyAnimal, implementovat rozhraní FourLeggedThing a skládat PetYouCanHoldWithAtLeastTwoHands!
Název: Re:Co si myslíte o OOP?
Přispěvatel: Mirek Prýmek 24. 01. 2019, 16:50:32
A jsme na standardní vlně "OOP debaty" :))) Dávám tomu tak dvě stránky, než začnete řešit, jestli má čtverec dědit z obdélníka nebo naopak :)))
Pro vetsinu aplikaci to jsou sourozenci se spolecnym predkem.
To tu ještě nebylo. Tak to bude delší debata než obvykle! (Tipuju tak dvacet stránek)
Název: Re:Co si myslíte o OOP?
Přispěvatel: operator 24. 01. 2019, 16:51:28
Dneska je programovani zhruba na urovni pred Kopernikem, takze se od tech majoritnich cirkevnich nazoru distancuju.
Jak myslíš, no. Já bych si spíš vsadil, že to ještě v průběhu života přehodnotíš, ale třeba bych prohrál :)
Jakmile vidis, ze to na co lidi pouzivaji tisice az miliony radku kodu jde pouzit par set nebo mozna nizkych tisic, a udelat to zaroven jednodussi, rychlejsi, citelnejsi, tak prehodnotis.

Jestli v programovani existuje silver bullet, pak bych bych vsadil hodne na to, ze to bude jednoduchost (simplicity).
Presne na tohle je dobra vyssi abstrakce, kterou nazyvas nadbytecny syntakticky cukr. Porad to vnimam tak, ze si protirecis.

Az vyresis tuhle kontradikci, naleznes nirvanu.

Syntakticky cukr je derava abstrakce. Dostanes jednu abstrakci dnes, ale uz z ni zitra nevytvoris jeste vyssi abstrakci. Pro nederavy abstrakce potrebujes vysoce kompozitabilni stavebni bloky, napr. nekdo zminil nor nebo mov nebo funkce. Ty slozis do vyssich abstraktnich bloku, ty jeste do vyssich, atd.
Tridy a objekty jsou derava abstrakce. Je to videt kdyz zjistis ze najednou potrebujes metatridy a tvuj jazyk je nema. Smalltalk tridy mozna deravy nejsou, ale ve vetsine jazyku je to abstraktni dira.
Nerozumim pojmu derava abstrakce?
Jak vis co bude zitra?
Nad objekty jako abstrakce imho stoji komponenty. Ale neni nutne aby nad kazdou abstrakci byla jeste vyssi, resp. aby kazda abstrakce byla soucasti ci stavebnim kamenem vyssi abstrakce.
Metatrida je spise implementacni detail, druh tridy za nejakym ucelem, podobne jako je treba abstraktni trida, nez nova vyssi abstrakce. Python manipulaci s metatridami umoznuje, ale myslim ze jsem toho nikdy nevyuzil, takze se nedivim, ze v jinych jazycich nejsou k dispozici. Pokud by to byl problem, je dusledkem nedostatecne implementace, nikoliv chybne abstrakce.
V cem je objekt derava abstrakce?
Trida je derava abstrakce ale smalltalk trida derava neni? Zase si protirecis.

Me tridy nezajimaji, ja je nepouzivam a nejsem na ne expert. Deravy jsou protoze treba nezvladnou dedit z vic rodicu. Nektery jo, protoze maji lrpsi implementaci coz je sada hacku a uz se to nabaluje.

Ja jsem tvrdil ze cukr je derava abstrakce, tridy  vem cert.

Derava abstrakce je takova ze ktery neposkladas jeste vyssi abstrakci. Ne vsechny pripady, protoze tam je dira. Treba te to nezajima protoze matlas kod a pouzivas k tomu abstrakce od jinych lidi. Lidi co ale tvori abstrakce hodne zajima jestli k tomu maji dostatecny nastroje.
Tridy jako abstrakce vicenasobnou dedicnost umoznuji. Ze to nektere jazyky neimplementuji neni chyba abstrakce.

Tvrdil jsi, ze tridy a objekty jsou derava abstrakce. Cukr a kafe abstrakce neni.
Ok, derava abstrakce je takova, ktera neslouzi jako zaklad vyssi abstrakce. V tom pripade na nich neni nic spatneho.
Abstrakce tvori kazdy programator, ktery pouziva tridy. Takze nevim jestli ty jo, kdyz je nepouzivas, ja ale ano.
Pokud mas teda jazyk postavenej na neuplny implementaci tridy pak je ten jazyk deravej v abstrakcich. Zapomen na to jestli jsem neco tvrdil o deravych tridach protoze jsme se nikdy neshodli na tom jestli se bavime o implementaci nebo koncepci. Tridu jako abstrakci muzu implementovat pouhym dictem metod a seznamem jak jsem zminil. Tvrdim akorat ze cukr je deravy a tvrdim ze vzdy.
O tridach a objektech tvrdim ze existuje jednodussi mechanismus na kterym zalozit bazi jazyka - napr. prototypy. Clovek pak v implementaci nemusi resit rozdil mezi objektem a tridou, pouze mezi built-in a derivovanym objektem.
Pak je 'deravy' jazyk (coz nicemu nemusi vadit),  ale nikoliv abstrakce oop jako paradigma. Bavis se o konkretnim jazyku nebo obecne o oop?
Tridu muzes implementovat jak chces, i pomoci struct a pointeru na funkce v C, v tom spor neni. Spor je v tom, jestli to stejne zjednodusi a zprehledni zapis programu jako tridy nebo ne. Jestli ne, maji tridy zjevny prinos, jestli jo, dokaz to a implementuj pomoci dictu mou ukazku pouziti trid.
Jednodussi mechanismus neznamena jednodussi a prehlednejsi kod.
Název: Re:Co si myslíte o OOP?
Přispěvatel: Mirek Prýmek 24. 01. 2019, 16:52:04
Máme tady třídu Obojživelník, Vozidlo a Plavidlo. Ze které z nich bude dědit třída Letadlo?
To je úplně jedno, protože ať tak nebo tak, stejně ve finále vznikne nepřehledný bordel totálních zhovadilostí.
Název: Re:Co si myslíte o OOP?
Přispěvatel: Kit 24. 01. 2019, 16:56:44
Máme tady třídu Obojživelník, Vozidlo a Plavidlo. Ze které z nich bude dědit třída Letadlo?
To je úplně jedno, protože ať tak nebo tak, stejně ve finále vznikne nepřehledný bordel totálních zhovadilostí.

S tím plně souhlasím.

Snad budeš souhlasit i s tím, že Letadlo za určitých okolností může dědit z třídy DopravníProstředek, stejně jako ostatní zmíněné třídy.
Název: Re:Co si myslíte o OOP?
Přispěvatel: operator 24. 01. 2019, 16:57:12
Obojživelník, Vozidlo i Plavidlo jsou DopravníProstředky.
A jsme na standardní vlně "OOP debaty" :))) Dávám tomu tak dvě stránky, než začnete řešit, jestli má čtverec dědit z obdélníka nebo naopak :)))

Ani jedno :)

Tématem je, co si myslíme o OOP. Jak tady někdo začne s diamanty, tak je jasné, že něco navrhuje blbě. Dědičnost je užitečná, ale její nadužívání je škodlivé. Máme tady třídu Obojživelník, Vozidlo a Plavidlo. Ze které z nich bude dědit třída Letadlo?
Diamant je vyreseny c3 linearizaci. Letadlo je sourozenec Vozidla a Plavidla a jeste si k tomu pridej Ponorku. Podzemni vozidla asi nemame a Vesmirna budeme ignorovat.
Název: Re:Co si myslíte o OOP?
Přispěvatel: Mirek Prýmek 24. 01. 2019, 16:59:30
Snad budeš souhlasit i s tím, že Letadlo za určitých okolností může dědit z třídy DopravníProstředek, stejně jako ostatní zmíněné třídy.
Jasně že bych souhlasil. Je to jenom speciální případ obecného tvrzení:

Cokoliv může za určitých okolností  dědit z čehokoliv, je to úplně jedno, protože ať tak nebo tak, stejně ve finále vznikne nepřehledný bordel totálních zhovadilostí.
Název: Re:Co si myslíte o OOP?
Přispěvatel: Kadet 24. 01. 2019, 16:59:53
Obojživelník, Vozidlo i Plavidlo jsou DopravníProstředky.
A jsme na standardní vlně "OOP debaty" :))) Dávám tomu tak dvě stránky, než začnete řešit, jestli má čtverec dědit z obdélníka nebo naopak :)))

Ano. Indoktrinace je uz prilis hluboka, vzdavam to.

Resi se tu: muze modul A importovat z vice jinych modulu? Misto modul se pouziva objekt. O tom je cely to zpraseny java oop
Název: Re:Co si myslíte o OOP?
Přispěvatel: operator 24. 01. 2019, 17:01:34
Máme tady třídu Obojživelník, Vozidlo a Plavidlo. Ze které z nich bude dědit třída Letadlo?
To je úplně jedno, protože ať tak nebo tak, stejně ve finále vznikne nepřehledný bordel totálních zhovadilostí.
Nevznikne, kdyz si dobre analyzujes potreby a tomu navrhnes vhodnou abstrakci. Protoze je potreba mit na mysli, ze tato abstrakce je zjednoduseny model za nejakym konkretnim ucelem, ktery je potreba sledovat a neexistuje zadne univerzalne platne rozdeleni.
Název: Re:Co si myslíte o OOP?
Přispěvatel: Kadet 24. 01. 2019, 17:11:26
Tohle 'dog.implements.animal' oop mi pripomina 'Mas obrovsky kladivo (nastroj), ale hledas hrebik k zatlouknuti (problem k vyreseni)'.
Název: Re:Co si myslíte o OOP?
Přispěvatel: Mirek Prýmek 24. 01. 2019, 17:12:51
Nevznikne, kdyz si dobre analyzujes potreby a tomu navrhnes vhodnou abstrakci. Protoze je potreba mit na mysli, ze tato abstrakce je zjednoduseny model za nejakym konkretnim ucelem, ktery je potreba sledovat a neexistuje zadne univerzalne platne rozdeleni.
Ano, to je pravda. Toto tvrzení (T1) pak zkombinujeme s druhým:

(T2) zadaní se vždycky změní, nejpozději do půl roku

a třetím:

(T3) jakmile se zadání změní, je potřeba okamžitě udělat ad hoc změny, které původně geniální objektovou analýzu změní v nepřehledný bordel totálních zhovadilostí

čímž se dostáváme k větě "obecné tvrzení o oop" (OTOOOP lemma):

(OTOOOP) Cokoliv může [v čase analýzy]  dědit z čehokoliv, je to úplně jedno, protože ať tak nebo tak, stejně ve finále vznikne nepřehledný bordel totálních zhovadilostí.

:)
Název: Re:Co si myslíte o OOP?
Přispěvatel: JSH 24. 01. 2019, 17:21:49
Nevznikne, kdyz si dobre analyzujes potreby a tomu navrhnes vhodnou abstrakci. Protoze je potreba mit na mysli, ze tato abstrakce je zjednoduseny model za nejakym konkretnim ucelem, ktery je potreba sledovat a neexistuje zadne univerzalne platne rozdeleni.
Ano, to je pravda. Toto tvrzení (T1) pak zkombinujeme s druhým:

(T2) zadaní se vždycky změní, nejpozději do půl roku

a třetím:

(T3) jakmile se zadání změní, je potřeba okamžitě udělat ad hoc změny, které původně geniální objektovou analýzu změní v nepřehledný bordel totálních zhovadilostí

čímž se dostáváme k větě "obecné tvrzení o oop" (OTOOOP lemma):

(OTOOOP) Cokoliv může [v čase analýzy]  dědit z čehokoliv, je to úplně jedno, protože ať tak nebo tak, stejně ve finále vznikne nepřehledný bordel totálních zhovadilostí.

:)
Ještě je třeba myslet na další pravidlo :
(T4) Změna zadání rozbordelí jakýkoliv návrh provedený podle jakéhokoliv paradigmatu.

Jediné řešení je vykašlat se na jakoukoliv analýzu a prostě to naprasit. Když to bude nepřehledé už od začátku, tak už to žádná změna nemůže zhoršit. 8)
Název: Re:Co si myslíte o OOP?
Přispěvatel: operator 24. 01. 2019, 17:24:59
Nevznikne, kdyz si dobre analyzujes potreby a tomu navrhnes vhodnou abstrakci. Protoze je potreba mit na mysli, ze tato abstrakce je zjednoduseny model za nejakym konkretnim ucelem, ktery je potreba sledovat a neexistuje zadne univerzalne platne rozdeleni.
Ano, to je pravda. Toto tvrzení (T1) pak zkombinujeme s druhým:

(T2) zadaní se vždycky změní, nejpozději do půl roku

a třetím:

(T3) jakmile se zadání změní, je potřeba okamžitě udělat ad hoc změny, které původně geniální objektovou analýzu změní v nepřehledný bordel totálních zhovadilostí

čímž se dostáváme k větě "obecné tvrzení o oop" (OTOOOP lemma):

(OTOOOP) Cokoliv může [v čase analýzy]  dědit z čehokoliv, je to úplně jedno, protože ať tak nebo tak, stejně ve finále vznikne nepřehledný bordel totálních zhovadilostí.
:)
Zalezi co se snazis modelovat a zda ma byt system flexibilni a rozsiritelny a na jake urovni. I tomu musis prizpusobit navrh. Tady uz zacinaji vyhody flexibility dynamickych jazyku, ktere nemusi resit typ ale jen protokol a casto ani to ne.
Název: Re:Co si myslíte o OOP?
Přispěvatel: Mirek Prýmek 24. 01. 2019, 18:20:26
Jediné řešení je vykašlat se na jakoukoliv analýzu a prostě to naprasit.
A proto je to nejčastější způsob! ;)

Tady uz zacinaji vyhody flexibility dynamickych jazyku, ktere nemusi resit typ ale jen protokol a casto ani to ne.
A úplně ideálně ani třídy ne :)
Název: Re:Co si myslíte o OOP?
Přispěvatel: operator 24. 01. 2019, 18:25:24
Jediné řešení je vykašlat se na jakoukoliv analýzu a prostě to naprasit.
A proto je to nejčastější způsob! ;)

Tady uz zacinaji vyhody flexibility dynamickych jazyku, ktere nemusi resit typ ale jen protokol a casto ani to ne.
A úplně ideálně ani třídy ne :)
Třída je typ.
Název: Re:Co si myslíte o OOP?
Přispěvatel: BoneFlute 24. 01. 2019, 20:43:36
Jediné řešení je vykašlat se na jakoukoliv analýzu a prostě to naprasit.
A proto je to nejčastější způsob! ;)

Tady uz zacinaji vyhody flexibility dynamickych jazyku, ktere nemusi resit typ ale jen protokol a casto ani to ne.
A úplně ideálně ani třídy ne :)
Třída je typ.
V Pythonu?! (Ano, formálně samozřejmě ano, ale reálně na tom nikdo nic nestaví.)
Název: Re:Co si myslíte o OOP?
Přispěvatel: BoneFlute 24. 01. 2019, 20:46:37
Nevznikne, kdyz si dobre analyzujes potreby a tomu navrhnes vhodnou abstrakci. Protoze je potreba mit na mysli, ze tato abstrakce je zjednoduseny model za nejakym konkretnim ucelem, ktery je potreba sledovat a neexistuje zadne univerzalne platne rozdeleni.
Ano, to je pravda. Toto tvrzení (T1) pak zkombinujeme s druhým:

(T2) zadaní se vždycky změní, nejpozději do půl roku

a třetím:

(T3) jakmile se zadání změní, je potřeba okamžitě udělat ad hoc změny, které původně geniální objektovou analýzu změní v nepřehledný bordel totálních zhovadilostí

čímž se dostáváme k větě "obecné tvrzení o oop" (OTOOOP lemma):

(OTOOOP) Cokoliv může [v čase analýzy]  dědit z čehokoliv, je to úplně jedno, protože ať tak nebo tak, stejně ve finále vznikne nepřehledný bordel totálních zhovadilostí.

:)
Ještě je třeba myslet na další pravidlo :
(T4) Změna zadání rozbordelí jakýkoliv návrh provedený podle jakéhokoliv paradigmatu.

Jediné řešení je vykašlat se na jakoukoliv analýzu a prostě to naprasit. Když to bude nepřehledé už od začátku, tak už to žádná změna nemůže zhoršit. 8)
Mě teda přijde, ale možná z toho ještě vyrostu, že na něco takového je dobrej kompromis funkcionální programování. Napsat funkci umí každej. Nejde to moc zvrtat. Kruhový závislosti jsem tam taky nějak moc neviděl. A když vznikne nějaký patvar, nebo se posune zadání, tak se prostě staré funkce nechají vyhnít. Zatím my přišlo, že se to dá snáz ukočírovat.
Název: Re:Co si myslíte o OOP?
Přispěvatel: BoneFlute 24. 01. 2019, 20:54:20
Pokud mas teda jazyk postavenej na neuplny implementaci tridy pak je ten jazyk deravej v abstrakcich. Zapomen na to jestli jsem neco tvrdil o deravych tridach protoze jsme se nikdy neshodli na tom jestli se bavime o implementaci nebo koncepci. Tridu jako abstrakci muzu implementovat pouhym dictem metod a seznamem jak jsem zminil. Tvrdim akorat ze cukr je deravy a tvrdim ze vzdy.
O tridach a objektech tvrdim ze existuje jednodussi mechanismus na kterym zalozit bazi jazyka - napr. prototypy. Clovek pak v implementaci nemusi resit rozdil mezi objektem a tridou, pouze mezi built-in a derivovanym objektem.

Hele, a ono to v tom Pythonu vadí? V čem vadí, že ten cukr je děravý? Někdo ti brání vytvořit si vlastní řešení nějakého vzoru pro Python? Třeba takové Mixiny můžeš udělat celkem v pohodě, a nepotřebuješ žádnou dědičnost. Ale možná mi unikla ta tvá pointa.

Taky bych rozlišoval věci, kdy Python ti nabízí jen základní konstrukce pro vytvoření programu (+ ten tebou zavrhovaný cukr). Úplně něco jiného jsou pak vlastnosti jazyka, které schválně omezují vývojáře. Protože takové omezení může být z různých důvodů přidaná hodnota. Myslíš si, že skutečnost, že Python má syntaktický cukr pro vytvoření objektu (přestože je to jen zabalenej dict) nějak škodí? V čem?
Název: Re:Co si myslíte o OOP?
Přispěvatel: Kit 24. 01. 2019, 21:06:30
Úplně něco jiného jsou pak vlastnosti jazyka, které schválně omezují vývojáře. Protože takové omezení může být z různých důvodů přidaná hodnota.

Dodnes jsem přesvědčen, že gettery a settery nejsou v Javě součástí syntaxe právě proto, aby se nepoužívaly.
Název: Re:Co si myslíte o OOP?
Přispěvatel: hawran diskuse 24. 01. 2019, 21:37:34
Úplně něco jiného jsou pak vlastnosti jazyka, které schválně omezují vývojáře. Protože takové omezení může být z různých důvodů přidaná hodnota.

Dodnes jsem přesvědčen, že gettery a settery nejsou v Javě součástí syntaxe právě proto, aby se nepoužívaly.

:D :D :D
Už jsem se bál, že je snad vůbec nezmíníš.
Název: Re:Co si myslíte o OOP?
Přispěvatel: Mirek Prýmek 24. 01. 2019, 22:24:04
(https://i.ibb.co/Jth6kLb/gettery.png)
Název: Re:Co si myslíte o OOP?
Přispěvatel: Kit 24. 01. 2019, 23:24:41
Já to tušil, že vám udělám radost :)
Název: Re:Co si myslíte o OOP?
Přispěvatel: operator 25. 01. 2019, 05:23:34
Jediné řešení je vykašlat se na jakoukoliv analýzu a prostě to naprasit.
A proto je to nejčastější způsob! ;)

Tady uz zacinaji vyhody flexibility dynamickych jazyku, ktere nemusi resit typ ale jen protokol a casto ani to ne.
A úplně ideálně ani třídy ne :)
Třída je typ.
V Pythonu?! (Ano, formálně samozřejmě ano, ale reálně na tom nikdo nic nestaví.)
Jak jsi na to prisel? Vytvareni uzivatelskych typu pomoci trid je zaklad.
Název: Re:Co si myslíte o OOP?
Přispěvatel: operator 25. 01. 2019, 05:30:38
Jediné řešení je vykašlat se na jakoukoliv analýzu a prostě to naprasit.
A proto je to nejčastější způsob! ;)

Tady uz zacinaji vyhody flexibility dynamickych jazyku, ktere nemusi resit typ ale jen protokol a casto ani to ne.
A úplně ideálně ani třídy ne :)
Třída je typ.
V Pythonu?! (Ano, formálně samozřejmě ano, ale reálně na tom nikdo nic nestaví.)
Jak jsi na to prisel? Vytvareni uzivatelskych typu pomoci trid je zaklad.
Je na tom postavena zakladni typova kontrola, pouziva to chtej nechtej kazdy:
Kód: [Vybrat]
>>> class A():
...     pass
...
>>> a = A()
>>> type(a)
<class '__main__.A'>
>>> type(a).__name__
'A'
>>> 1 + a
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
TypeError: unsupported operand type(s) for +: 'int' and 'A'
Název: Re:Co si myslíte o OOP?
Přispěvatel: BoneFlute 25. 01. 2019, 07:59:29
V Pythonu?! (Ano, formálně samozřejmě ano, ale reálně na tom nikdo nic nestaví.)
Jak jsi na to prisel? Vytvareni uzivatelskych typu pomoci trid je zaklad.
Mě mučí tyhle slovokolotoče: v Pythonu se objekt vytváří pomocí slova class, a na jeho jméno se tážeme slovem type. Uff.

pouziva to chtej nechtej kazdy:
Zas nepřeháněj. Možná někdo někdy.
Název: Re:Co si myslíte o OOP?
Přispěvatel: operator 25. 01. 2019, 09:04:26
V Pythonu?! (Ano, formálně samozřejmě ano, ale reálně na tom nikdo nic nestaví.)
Jak jsi na to prisel? Vytvareni uzivatelskych typu pomoci trid je zaklad.
Mě mučí tyhle slovokolotoče: v Pythonu se objekt vytváří pomocí slova class, a na jeho jméno se tážeme slovem type. Uff.
To je dost zavadejici tvrzeni. Pomoci class se definuje trida, coz je sice take objekt, jako vsechno v pythonu, ale neni to jedina a ani hlavní cesta jak vytvaret objekty. Objekt, ktery jsi mel pravdepodobne na mysli, se vytvari volanim te tridy, nikoliv pomoci slova class. A neni to zadny slovokolotoc, datovym typem tridy je typ type. Volanim type() se pak neptas na jmeno objektu, ale jeho datovy typ. Mas v tom desny chaos.
Citace
pouziva to chtej nechtej kazdy:
Zas nepřeháněj. Možná někdo někdy.
Neprehanim. Protoze je na tom postavena silna typova kontrola, chtej nechtej to pouziva kazdy, te se nevyhnes. I ten, kdo nepouziva v Pythonu tridy a nevytvari si vlastni uzivatelske typy. Python je flexibilni a nenuti te definovat si vlastni tridy, tedy vlastni uzivatelske typy, ale bez toho ho vyuzivas jen tak na pul. Pro male skripty fajn, tam vystacis s generickymi typy, ale pro vetsi aplikace a/nebo komplexnejsi datove struktury je to vyborna pomucka a jen trouba ji nevyuzije.

Myslel jsem, skrz tve autoritativni vyjadrovani k dynamickemu programovani a pythonu, ze se v tom vyznas lepe. Vis o tom ale uplny prd.
Název: Re:Co si myslíte o OOP?
Přispěvatel: Inkvizitor 25. 01. 2019, 09:59:10
Mě mučí tyhle slovokolotoče: v Pythonu se objekt vytváří pomocí slova class, a na jeho jméno se tážeme slovem type. Uff.

Na jmeno tridy se ptame pres x.__class__.__name__. Jestli je objekt instanci (pod)tridy se ptame pomoci isinstance(). type() se pro tyto ucely pouzivat nedoporucuje, rozhodne ne v Pythonu 3, kde se semantika te funkce dost zmenila.
Název: Re:Co si myslíte o OOP?
Přispěvatel: gll 25. 01. 2019, 10:11:56
Mě mučí tyhle slovokolotoče: v Pythonu se objekt vytváří pomocí slova class, a na jeho jméno se tážeme slovem type. Uff.

Na jmeno tridy se ptame pres x.__class__.__name__. Jestli je objekt instanci (pod)tridy se ptame pomoci isinstance(). type() se pro tyto ucely pouzivat nedoporucuje, rozhodne ne v Pythonu 3, kde se semantika te funkce dost zmenila.

x.__class__ je stejné jako type(x)
Název: Re:Co si myslíte o OOP?
Přispěvatel: operator 25. 01. 2019, 10:19:27
Mě mučí tyhle slovokolotoče: v Pythonu se objekt vytváří pomocí slova class, a na jeho jméno se tážeme slovem type. Uff.

Na jmeno tridy se ptame pres x.__class__.__name__. Jestli je objekt instanci (pod)tridy se ptame pomoci isinstance(). type() se pro tyto ucely pouzivat nedoporucuje, rozhodne ne v Pythonu 3, kde se semantika te funkce dost zmenila.
Upresnim. Funkce type(obj) vraci datovy typ promenne. Funkce isinstance(obj, cls) vraci bool a vyhodnocuje, zda obj je instanci tridy nebo jejiho potomka, cili na test typove kompatibility je to vhodnejsi funkce. V Pythonu 3 je type(obj) ekvivalentni s obj.__class__, protoze v pythonu jsou sjednoceny typy a tridy. V Pythonu 2 to tak nebylo, byly tam tridy dvojiho druhu, puvodni a tzv, new class, ktere se v Pythonu 3 staly standardnimi a univerzalni pristup k typum byl pres type() a je stale nutny u Python programu, ktere maji byt funkcni pod obema verzemi Pythonu.

Pokrocilou zajimavosti je, ze type() jde vyuzit i k definici datoveho typu bez pouziti trid. Tudiz kdyby Kadet chtel, mohl by implementovat onen priklad objektu s dicty bez class, jen by to nebylo tak prehledne.
Název: Re:Co si myslíte o OOP?
Přispěvatel: gll 25. 01. 2019, 10:33:29
Pokrocilou zajimavosti je, ze type() jde vyuzit i k definici datoveho typu bez pouziti trid. Tudiz kdyby Kadet chtel, mohl by implementovat onen priklad objektu s dicty bez class, jen by to nebylo tak prehledne.

Přesněji, type vytvoří třídu bez klíčového slova class. Slovem třída bývají označovány i datové typy obecně. Datové typy jsou objekty typu type.

Kód: [Vybrat]
A = type('A', (), {})

# je stejne

class A:
    pass
Název: Re:Co si myslíte o OOP?
Přispěvatel: operator 25. 01. 2019, 11:22:40
Pokrocilou zajimavosti je, ze type() jde vyuzit i k definici datoveho typu bez pouziti trid. Tudiz kdyby Kadet chtel, mohl by implementovat onen priklad objektu s dicty bez class, jen by to nebylo tak prehledne.

Přesněji, type vytvoří třídu bez klíčového slova class. Slovem třída bývají označovány i datové typy obecně. Datové typy jsou objekty typu type.

Kód: [Vybrat]
A = type('A', (), {})

# je stejne

class A:
    pass
Pravda, v Pythonun 3 uz i cislo ma datovy typ tridu int.
Kód: [Vybrat]
~ $ python
Python 3.7.2 (default, Dec 28 2018, 01:00:42)
[Clang 7.0.2 (https://android.googlesource.com/toolchain/clang 003100370607242d on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> type(0)
<class 'int'>
>>>
~ $ python2
Python 2.7.15 (default, Sep 23 2018, 14:53:40)
[GCC 4.2.1 Compatible Android (4751641 based on r328903) Clang 7.0.2 (https://a on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> type(0)
<type 'int'>
>>>