Co si myslíte o OOP?

[Mirek Prýmek]

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.

[Reklama]

[MartinBeran]

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

[MartinBeran]

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

[Mirek Prýmek]

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

[operator]

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.

[Reklama]

[operator]

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

[lopata]

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.

[operator]

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.

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.

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.

[operator]

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.

[operator]

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.

[anonym]

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 

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.

[operator]

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 

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

[Mirek Prýmek]

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

[SB]

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

[operator]

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.