Problémy s JavaScript v praxi

[eee]

Přoblém je, že a) jsi to neimplementoval,

Jak to "neimplementoval"? Tak je asi jasné, že implementace "přečti z hashmapy" (getattr, operátor "."), "vrať identifikátor 'typu'" (funkce type() - vrátí nějaký JSObject popisující parametr, případně odvozený od "parent class") a "isinstance" (proleze parenty, jestli se něco neshoduje) je docela triviální...teda aspoň pro mě je...

Dokud nepředvedeš analogický funkční kód mých třech řádků, tak jsi ho neimplementoval. Až ho implementuješ, obávám se, že nebude analogický, ale nechám se překvapit, třeba něco opravdu nevím a nechápu.

[Reklama]

[eee]

b) nepoužil jsi type inference a součtový typ, který dle tebe ze statických jazyků dělají stejně flexibilní a pohodlné jazyky jako jsou dynamické.

JSValue je součtový typ, v tom "let" je použita type inference. V tom kódu jsem omylem na začátku nechal "f :: JSValue" (mělo tam být jiné jméno funkce a typ), ale to se dá klidně smazat. V tom kódu nikde není jediná typová anotace, všechno je přes automatickou type inference..

Dobře, špatně jsem se vyjádřil, beru zpět. Zatím jsi nepředvedl, že type inference a součtový typ ze statických jazyků dělají stejně flexibilní a pohodlné jazyky jako jsou dynamické.

[eee]

Já ti jen ukazuji, že nikoliv. Jistě, nakonec můžeš nasimulovat celý interpret dynamického jazyka, ale nebude to pohodlné a nebude to mít smysl, když ten dynamický jazyk můžeš použít rovnou :-).

Až na to, že tohle _není_ interpret dynamického jazyka. Ten kód s těma "print" je normální haskellový kód, který přistuje k normálnímu haskellovému typu a volá úplně normální haskellové funkce. Akorát jsem ten typ JSValue zadefinoval jakou součtový typ, který je ekvivalentní tomu, jak to má zadefinované python.

Také to ještě nedělá to, co předvedla má ukázka.

Hanzelka ubil v Kostelci rusa. Akorát to nebyl Hanzelka, ale Zikmund, neubil ale upálil, ne v Kostelci ale v Kostnici, a ne rusa, ale Husa...

Jo, to mi připomíná jednoho člověka, který si plete implementaci s abstrakcí. :-)

Mně na tom Kruger-Daningovu efektu nefascinuje ani tak to, že lidi, co o tématu neví nic, přeceňují svoje schopnosti. Spíš to, že lidi, kteří o tématu nic nevědí, nejsou své sebevědomí schopni korigovat ani když narazí, a jsou-li odkázáni na naprosto standardní oborovou literaturu, tak se do ní ani nepodívají, protože oni to přece ví nejlíp...

Mně nevadí, že přeceňuješ své síly. Teď jsi narazil na úkol předvést ve statickém jazyku krátkou ukázku z jazyka dynamického a předvést, že ve statickém jazyku se taková věc dá implementovat stejně jednoduše a pohodlně, o čemž sebevědomě tvrdíš, že to není díky type inference a součtovému typu problém. Uvidíme, jak budeš korigovat své sebevědomí, až zjistíš, že to nedokážeš. Pokud to dokážeš, tak já budu rád, že jsem se něco naučil, a rád přiznám, že moderním aspektům statickch jazyků nerozumím a zamrznul jsem na C a Javě. Abys chápal, podstatou problému není převést string na list v rámci jedné proměnné, ale dynamicky z dat vytvořit nový datový typ, který je k nerozlišení od standardně deklarovaných a se kterým se pracuje úplně stejně a podléhá stejným pravidlům a fungování jako ostatní.

Neznám haskell, ale pokud neumí dynamické typy (pokud jo, je diskvalifikován, protože úkol je implementovat to ve statickém jazyku), máš problém. Můžeš se snažit emulovat chování dynamického interpretu, ale to nebude ani jednoduché ani pohodlné a předpokládám, že výsledek nezapadne do typového systému haskellu, například s ním nebudou fungovat standardní typové funkce.

Nemyslím si ale, že bys byl Krugerův případ, ty jsi prostě jen statický programátor, který nedokáže dynamicky myslet, není schopen pochopit a využít abstrakci dynamických jazyků (je to prasárna, security problem, ...). A jak už jsem předesílal, lidská mysl má řadu záludných obranných mechanismů, kterými se brání změně myšlení. Tvá fascinace a vnucování Krugera je jedna z nich. Je to intelektuálně laciné. Jestli jsem blbec, který tomu nerozumí, dokaž to věcně a racionálně. Neměl by to být problém, pokud tvůj pocit převahy nade mnou je oprávněný.

[v]

Kód [Vybrat] Rozbalit

{-# LANGUAGE OverloadedStrings, OverloadedLabels, FlexibleInstances, MultiParamTypeClasses #-}

import Data.Map
import Data.List.Split
import Data.String
import GHC.OverloadedLabels
import GHC.TypeLits

data V = N Double | S String | O String (Map V V) | C String (Map V V)
    deriving (Ord, Eq, Show)

instance IsString V where
    fromString = S

instance KnownSymbol l => IsLabel l V where
    fromLabel s = S (symbolVal' s)

type_ name fields = C name (fromList fields)
new (C name fields) = O name fields
O _ fields ... k = fields ! k

main = do
    let cls:fields = splitOn " " "A a=1 b=2 c=3"
    let fields' = fmap ((\[k,v] -> (S k, S v)) . splitOn "=") fields
    let ty = type_ cls fields'
    print ty
    let o = new ty
    print (o ... #a)


[JanaH]

Koukam cely thread a vsichni michate jabka s hruskama. At je jazyk jakyvkolik je potreba se mu prizpusobit a pochopit jeho domenu. Kdyz to opomenete tak mate problem. Kdyz se vam v jazyku neco nezda protoze to dela jinak nez jiny tak je problem u vas, ne v implementaci.

[Reklama]

[eee]

Kód [Vybrat] Rozbalit

{-# LANGUAGE OverloadedStrings, OverloadedLabels, FlexibleInstances, MultiParamTypeClasses #-}

import Data.Map
import Data.List.Split
import Data.String
import GHC.OverloadedLabels
import GHC.TypeLits

data V = N Double | S String | O String (Map V V) | C String (Map V V)
    deriving (Ord, Eq, Show)

instance IsString V where
    fromString = S

instance KnownSymbol l => IsLabel l V where
    fromLabel s = S (symbolVal' s)

type_ name fields = C name (fromList fields)
new (C name fields) = O name fields
O _ fields ... k = fields ! k

main = do
    let cls:fields = splitOn " " "A a=1 b=2 c=3"
    let fields' = fmap ((\[k,v] -> (S k, S v)) . splitOn "=") fields
    let ty = type_ cls fields'
    print ty
    let o = new ty
    print (o ... #a)


Děkuji za ukázku. Zatím ji moc nerozumím, potřebuji se jí prkousat, ale nefunguje mi

GHCi, version 8.0.1
   
main.hs:4:1: error:
    Failed to load interface for 'Data.List.Split'
    Use -v to see a list of the files searched for.
<interactive>:3:1: error:
    • Variable not in scope: main
    • Perhaps you meant 'min' (imported from Prelude)
   

[v]

Kód [Vybrat] Rozbalit


cabal update
cabal install split
ghci main.hs


[BoneFlute]

Koukam cely thread a vsichni michate jabka s hruskama. At je jazyk jakyvkolik je potreba se mu prizpusobit a pochopit jeho domenu. Kdyz to opomenete tak mate problem. Kdyz se vam v jazyku neco nezda protoze to dela jinak nez jiny tak je problem u vas, ne v implementaci.

Může být. Ale když dotyčný není schopen vyhmátnout pointu jazyka, a ohání se esoterikou? K čemu to dobrý?

[Kit]

Kód [Vybrat] Rozbalit

{-# LANGUAGE OverloadedStrings, OverloadedLabels, FlexibleInstances, MultiParamTypeClasses #-}
... 27 řádek Haskellu s 5 importy


Není to příliš komplikované ve srovnání s uvedeným řešením v Pythonu? Než takovou divočinu, tak raději použiji ten Python nebo PHP, ve kterých je to kratší, přehlednější a hlavně udržovatelnější.

[eee]

Koukam cely thread a vsichni michate jabka s hruskama. At je jazyk jakyvkolik je potreba se mu prizpusobit a pochopit jeho domenu. Kdyz to opomenete tak mate problem. Kdyz se vam v jazyku neco nezda protoze to dela jinak nez jiny tak je problem u vas, ne v implementaci.

Může být. Ale když dotyčný není schopen vyhmátnout pointu jazyka, a ohání se esoterikou? K čemu to dobrý?

Abstrakce není esoterika. Pointu jazyka nedokáže vyhmátnout ten, kdo nedokáže rozlišovat mezi jeho abstrakcí a implementací. Dobré je to třeba k pochopení, že dynamické jazyky mají datové typy a že se v nich dají jednoduše a pohodlně programovat konstrukce na vyšší úrovní, které se ve statickém jazyku implementují obtížně.

[eee]

Kód [Vybrat] Rozbalit


cabal update
cabal install split
ghci main.hs


Tohle je prohlém, mohu to udělat buď v termuxu (pro který ghc není) nebo online, kde jsem vyzkoušel přes deset překladačů, do jednoho na tom selhaly.

Je z toho zřejmé, že se nejedná o vlastnost statického jazyka, ale nějakého minoritní knihovny, která skutečnou složitost řešení ve statickém jazyku skrývá. Z toho se mi jeví, že je to veli specifické řešení, nepřenosné na jiné jazyky s type inference a součtovým typem, tyto samotné na to nestačí.

Když od toho odhlédnu, tak i ukázaný kód je složitější a řešení není tak jednoduché je zřejmé. Pythonu na to stačily 3 proměnné, 2 builtin funkce a 3 řádky kódu.

Jestli andy nepřijde sbjednodušším řešením,  mohl by to reflektovat a korigovat své tvrzení o statických jazycích.

Nicméně přesto mě to jako technické řešení velmi zajímá. Odporuje to mým chabým vědomostem o haskellu, které říkají, že haskell nemá first-class datové typy, což je podstatou mé ukázky. Má haskell first class datové typy a nebo ta ukázka dělá něco jiného? Díky za vysvětlení.

[eee]

Kód [Vybrat] Rozbalit

{-# LANGUAGE OverloadedStrings, OverloadedLabels, FlexibleInstances, MultiParamTypeClasses #-}
... 27 řádek Haskellu s 5 importy


Není to příliš komplikované ve srovnání s uvedeným řešením v Pythonu? Než takovou divočinu, tak raději použiji ten Python nebo PHP, ve kterých je to kratší, přehlednější a hlavně udržovatelnější.

Já bych na to koukal s větším nadhledem. Dynamický datový typ je prostředek k cíli, nikoliv cíl samotný. Každý jazyk k dosažení cíle dává jiné prostředky. Jestliže mi do programu chodí v čase hodnoty, které dokážu třídit na různé, v čase kompilace neznámé, datové typy (třeba při zpracování různých xml souborů nebo hierarchických dat z databází) tak pro práci s nimi rád využiju typových vlastností jazyka, protože je spolehlivý, komplexní a chytře navržený, je spojený s dědičností, ošetřuje interakci mezi datovými typy a celé je to krásně odladěné. Ušetří to spoustu práce a bude to rychlé.

Samozřejmě, nechci s každým novým sloupcem nebo elementem upravovat a kompilovat program pro zavedení nového datového typu. V pythonu se použití dynamických typů proto přímo nabízí, je to jednoduché, přehledné, efektivní. Případné úpravy pro nové kategorie typů jsou v dynamickém jazyku také jednodušší.

Statické jazyky nabízí jiné možnosti, tam by se to implementovalo jinak, pravděpodobně by se zavedly pseudo datové typů, s kterými by statický typový systém jazyka pracovat neuměl a proto by se veškerá logika a interakce kolem toho musela ošetřit ručně.

Je na zvážení a individuální pro každý případ, co je cesta nejmenšího odporu. Možná změnit jazyk jak navrhuješ (ale to je v konzervativním průmyslovém prostředí dost obtížné, protože tyhle věci bývají integrované do komplexních systémů a nikdo nechce řešit, že každý pes je jiná ves), nebo prostě se změnou dat vždy upravovat program (což neprojde, pokud je to outsourcované a data se mění často, je to těžko udržovatelné), nebo se implementují ony dynamické pseudotypy, které jsou implementovány ručně, což je složité, komplexní, náročné na odladění a ve výsledku stejně omezené. Haskell by to možná tímto způsobem zvládnul podobně jako dynamický jazyk, ale haskell jsem v praxi nikdy nepotkal a vzhledem k tomu, že je to funkcionální jazyk, tak asi ani nikdy nepotkám, jeví se mi spíšenakademicky než prakticky.

Každopádně ne náhodou je Python jedním z nejoblíbenějších jazyků pro analýzu a zpracování dat (data mining), navzdory mínění některých zdejších mistrů, že používání dynamických typů je prasárna a security problém.

[zimb]

Kód [Vybrat] Rozbalit

{-# LANGUAGE OverloadedStrings, OverloadedLabels, FlexibleInstances, MultiParamTypeClasses #-}
... 27 řádek Haskellu s 5 importy


Není to příliš komplikované ve srovnání s uvedeným řešením v Pythonu? Než takovou divočinu, tak raději použiji ten Python nebo PHP, ve kterých je to kratší, přehlednější a hlavně udržovatelnější.

Já bych na to koukal s větším nadhledem. Dynamický datový typ je prostředek k cíli, nikoliv cíl samotný. Každý jazyk k dosažení cíle dává jiné prostředky. Jestliže mi do programu chodí v čase hodnoty, které dokážu třídit na různé, v čase kompilace neznámé, datové typy (třeba při zpracování různých xml souborů nebo hierarchických dat z databází) tak pro práci s nimi rád využiju typových vlastností jazyka, protože je spolehlivý, komplexní a chytře navržený, je spojený s dědičností, ošetřuje interakci mezi datovými typy a celé je to krásně odladěné. Ušetří to spoustu práce a bude to rychlé.

Samozřejmě, nechci s každým novým sloupcem nebo elementem upravovat a kompilovat program pro zavedení nového datového typu. V pythonu se použití dynamických typů proto přímo nabízí, je to jednoduché, přehledné, efektivní. Případné úpravy pro nové kategorie typů jsou v dynamickém jazyku také jednodušší.

Statické jazyky nabízí jiné možnosti, tam by se to implementovalo jinak, pravděpodobně by se zavedly pseudo datové typů, s kterými by statický typový systém jazyka pracovat neuměl a proto by se veškerá logika a interakce kolem toho musela ošetřit ručně.

Je na zvážení a individuální pro každý případ, co je cesta nejmenšího odporu. Možná změnit jazyk jak navrhuješ (ale to je v konzervativním průmyslovém prostředí dost obtížné, protože tyhle věci bývají integrované do komplexních systémů a nikdo nechce řešit, že každý pes je jiná ves), nebo prostě se změnou dat vždy upravovat program (což neprojde, pokud je to outsourcované a data se mění často, je to těžko udržovatelné), nebo se implementují ony dynamické pseudotypy, které jsou implementovány ručně, což je složité, komplexní, náročné na odladění a ve výsledku stejně omezené. Haskell by to možná tímto způsobem zvládnul podobně jako dynamický jazyk, ale haskell jsem v praxi nikdy nepotkal a vzhledem k tomu, že je to funkcionální jazyk, tak asi ani nikdy nepotkám, jeví se mi spíšenakademicky než prakticky.

Každopádně ne náhodou je Python jedním z nejoblíbenějších jazyků pro analýzu a zpracování dat (data mining), navzdory mínění některých zdejších mistrů, že používání dynamických typů je prasárna a security problém.

ne ze bych nesouhlasil s plusy a minusy dyn/stat jazyku, to beze sporu.

Nicmene popularitu pythonu u datove analyzy/miningu, to bych rozhodne neprisuzoval jen dyn typum - python je popularni z jinych duvodu 1) ten jazyk ma na prvni pohled user friendly syntaxi pro neprogramatory 2) python komunita tlaci roky python do mainstreamu hlavne i pro lidi kteri nejsou programatori (napriklad datovi analytici atd atd) 3) tzn datovy analytik ktery neumi profesionalne programovat samozrejme sahne, jako kdokoliv jiny, po dyn jazyku, kdyz mu ho primo ze vsech stran tlaci, pac u "zpracovani dat" se rozhodne zadny pekny OO kod nedela a neni treba, je to takova rozjebanejsi tabulka v excelu z pohledu toho cloveka co to v tom masti. a konecne v pythonu jsou nejpopularnejsi knihovny pro tyhle veci - jeslti je to kvuli slepici nebo vejci, to uz je asi vedlejsi.

[BoneFlute]

Koukam cely thread a vsichni michate jabka s hruskama. At je jazyk jakyvkolik je potreba se mu prizpusobit a pochopit jeho domenu. Kdyz to opomenete tak mate problem. Kdyz se vam v jazyku neco nezda protoze to dela jinak nez jiny tak je problem u vas, ne v implementaci.

Může být. Ale když dotyčný není schopen vyhmátnout pointu jazyka, a ohání se esoterikou? K čemu to dobrý?

Abstrakce není esoterika. Pointu jazyka nedokáže vyhmátnout ten, kdo nedokáže rozlišovat mezi jeho abstrakcí a implementací. Dobré je to třeba k pochopení, že dynamické jazyky mají datové typy a že se v nich dají jednoduše a pohodlně programovat konstrukce na vyšší úrovní, které se ve statickém jazyku implementují obtížně.

Nerozlišuješ abstrakci od implementace. Statické jazyky taky mají datové typy. A hlavně, ty konstrukce na vyšší úrovně jsi nepředvedl.

Ano, javascript může vracet dynamický počet hodnot a dokonce různých typů. Te se ve statických jazycích nedělá, ale ne proto, že by to nešlo, ale protože to není dobrý nápad.

Ty jsi tu nikde neukázal, v čem jsou dynamické jazyky lepší než ty se statickou kontrolou. Proto jsem si tě zařadil do esoteriky. Používáš totiž stejné obraty.

[listoper]

Kód [Vybrat] Rozbalit

{-# LANGUAGE OverloadedStrings, OverloadedLabels, FlexibleInstances, MultiParamTypeClasses #-}
... 27 řádek Haskellu s 5 importy


Není to příliš komplikované ve srovnání s uvedeným řešením v Pythonu? Než takovou divočinu, tak raději použiji ten Python nebo PHP, ve kterých je to kratší, přehlednější a hlavně udržovatelnější.

Já bych na to koukal s větším nadhledem. Dynamický datový typ je prostředek k cíli, nikoliv cíl samotný. Každý jazyk k dosažení cíle dává jiné prostředky. Jestliže mi do programu chodí v čase hodnoty, které dokážu třídit na různé, v čase kompilace neznámé, datové typy (třeba při zpracování různých xml souborů nebo hierarchických dat z databází) tak pro práci s nimi rád využiju typových vlastností jazyka, protože je spolehlivý, komplexní a chytře navržený, je spojený s dědičností, ošetřuje interakci mezi datovými typy a celé je to krásně odladěné. Ušetří to spoustu práce a bude to rychlé.

Samozřejmě, nechci s každým novým sloupcem nebo elementem upravovat a kompilovat program pro zavedení nového datového typu. V pythonu se použití dynamických typů proto přímo nabízí, je to jednoduché, přehledné, efektivní. Případné úpravy pro nové kategorie typů jsou v dynamickém jazyku také jednodušší.

Statické jazyky nabízí jiné možnosti, tam by se to implementovalo jinak, pravděpodobně by se zavedly pseudo datové typů, s kterými by statický typový systém jazyka pracovat neuměl a proto by se veškerá logika a interakce kolem toho musela ošetřit ručně.

Je na zvážení a individuální pro každý případ, co je cesta nejmenšího odporu. Možná změnit jazyk jak navrhuješ (ale to je v konzervativním průmyslovém prostředí dost obtížné, protože tyhle věci bývají integrované do komplexních systémů a nikdo nechce řešit, že každý pes je jiná ves), nebo prostě se změnou dat vždy upravovat program (což neprojde, pokud je to outsourcované a data se mění často, je to těžko udržovatelné), nebo se implementují ony dynamické pseudotypy, které jsou implementovány ručně, což je složité, komplexní, náročné na odladění a ve výsledku stejně omezené. Haskell by to možná tímto způsobem zvládnul podobně jako dynamický jazyk, ale haskell jsem v praxi nikdy nepotkal a vzhledem k tomu, že je to funkcionální jazyk, tak asi ani nikdy nepotkám, jeví se mi spíšenakademicky než prakticky.

Každopádně ne náhodou je Python jedním z nejoblíbenějších jazyků pro analýzu a zpracování dat (data mining), navzdory mínění některých zdejších mistrů, že používání dynamických typů je prasárna a security problém.

Nemel bys po ruce odkaz na nejaky projekt kde se to pouziva? Chtel bych to videt v kontextu abych si mohl udelat obrazek o uzitecnosti.
Zatim mi neprijde, ze by to melo nejakou vyhodu oproti pouziti normalniho slovniku, ale jak o tom mluvis tak se mi zda, ze  asi neco prehlizim.