Co si myslíte o OOP?

[baranomrd]

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

[Reklama]

[Kit]

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ší?

[Kadet]

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.

[Wavelet]

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?

[Kadet]

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

[Reklama]

[Kit]

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.

[Ondra Satai Nekola]

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.

[Kit]

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)


[MartinBeran]

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.

[MartinBeran]

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>.

[Honza]

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

[Kit]

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.

[Ondra Satai Nekola]

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.

[Ondra Satai Nekola]

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.

[Ondra Satai Nekola]

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