Fórum Root.cz
Hlavní témata => Vývoj => Téma založeno: Vlado 26. 09. 2018, 14:58:58
-
V predošlom vlakne sa píše o problémoch s JS, ale ja som s ním v praxi zatiaľ žiadny reálny problém nezaznamenal. Preto ma zaujíma, či ste sa teraz, v aktuálnej praxi stretli s nejakým problémom s JS. Rovno však upresním:
1. Že je iný ako nejaký iný jazyk neznamená, že to je problém s JS. To len znamená, že je proste iný. Zrovnania sem nepatria.
2. TypeScript nie je JavaScript. Ak máte problém s TS, to sem tiež nepatrí.
3. Problémy s nejakým frameworkom tiež nie sú problémy s JavaScriptom, ale problémy s príslušným frameworkom, to sem tiež nepatrí.
4. Node je platforma. Akokoľvek určená
pre JavaScript, je to platforma, nie jazyk samotný. Praktický problém s Node sem však môžete napísať, nebude sa však rátať ako problém s JavaScriptom, ale zvlášť ako problém s platformou.
5. Node prístup k modulárnosti kódu a mudrovanie o tisícoch závislostí si nechajte pre seba. To nie je chyba, to je vlastnosť, aj to čo sa týka organizácie kódu, navyše nepovinnej, nie jazyka samotného. Tak ako nikto pri zmysloch nepičuje na tisíce tried v Java projektoch, tak nie je dôvod tvrdiť, že to isté v JavaScripte už ale zlé je. Nie je.
6. Teoretici pohov. Nikoho nezaujímajú vaše vygooglené múdra, otázka je smerovaná na aktuálnych JS developerov, konkrétne na ich aktuálne problémy s JavaScriptom v aktuálnom projekte.
Som zvedavý, koľko reálnych problémov sa nájde. Nejde mi totiž do hlavy, prečo som s JS za nemálo rokov nemal jediný problém vo web aplikáciách, hoci je internet plný žvástov, aký je to zlý jazyk. Som presvedčený, že tie "problémy" sú iba v hlavách autorov ktorí ho proste neovládajú, nepochopili, ale v zmysle hesla "kto to nevie, ten to učí", aspoň píšu po internete svoje verzie bájky o kyslých hroznách... Ale tak to možno vnímam iba ja, preto nech sa páči, feel free to change my mind.
-
Ked ste odfiltrovali vsetky moznosti, tak je u mna vsetko v poriadku ;) ;) 8) 8) ;)
Pridam klasiku https://www.destroyallsoftware.com/talks/wat
-
Ked ste odfiltrovali vsetky moznosti, tak je u mna vsetko v poriadku ;) ;) 8) 8) ;)
Pridam klasiku https://www.destroyallsoftware.com/talks/wat
A to je všetko? Jedno nie vážne myslené video spred šiestich rokov? To je potom JS ale vááážne zlý jazyk...
-
Js je neskutecna sra... urcena na male Scripty a ne na velke aplikacni baliky s nemoznosti refaktorizace atd.
To ze jsem videl v js hodne spatneho kodu nelze nedavat za vjnu jazyku - ten takovy kod umoznuje.
Co se mi nelibi na js? Vsechno.
-
Js je neskutecna sra... urcena na male Scripty a ne na velke aplikacni baliky s nemoznosti refaktorizace atd.
To ze jsem videl v js hodne spatneho kodu nelze nedavat za vjnu jazyku - ten takovy kod umoznuje.
Co se mi nelibi na js? Vsechno.
Ja som zas videl kopec zlého kódu aj v iných jazykoch, tak ma s hejtom neotravuj. Ja sa pýtam reálnych developerov na praktické problémy s JS, nie na subjektívne pičoviny od niekoho, kto ho ani len neovláda.
-
https://wtfjs.com/
-
Je fakt ze pro Indy co pred rokem jeste prodavali zeleninu a pro tebe muze js byt jedine, co zvladnes.
-
https://wtfjs.com/
:o Díky moc! Tohle by mělo ukončit všechny debaty...
-
Jop, deti ma odhalili - JS je jediné čo zvládam. Ale to je v pohode, blbečkov čo nevedia uviesť jediný objektívny argument je tu priveľa na to, aby som to tu ukončil. Stále čakám na skutočný problém s JS z praxe a vôbec sa nedivím, že stále žiadny neprichádza ;)
-
https://wtfjs.com/
Begun the language wars have! :)
-
Jop, deti ma odhalili - JS je jediné čo zvládam. Ale to je v pohode, blbečkov čo nevedia uviesť jediný objektívny argument je tu priveľa na to, aby som to tu ukončil. Stále čakám na skutočný problém s JS z praxe a vôbec sa nedivím, že stále žiadny neprichádza ;)
obdivuji vaši trpělivost.
-
Stále čakám na skutočný problém s JS z praxe a vôbec sa nedivím, že stále žiadny neprichádza ;)
Trpělivost přináší růže: Velkým problémem Javascriptu je absence typování v jazyku. Jednak je prakticky nemožné udělat spolehlivý hinting v IDE, což se u trochu větších projektů projevuje sníženou produktivitou. S tím souvisí i menší počet chyb, které nemohou být odhaleny při kompilaci a musí se odladit až testováním => opět snížená produktivita.
-
Uz umi js formatovani retezcu a cisel?
-
Uz umi js formatovani retezcu a cisel?
ne, ale řetězec a číslo je v javascriptu totéž:
"111" == 111; -> true
:-)
-
Stále čakám na skutočný problém s JS z praxe a vôbec sa nedivím, že stále žiadny neprichádza ;)
Trpělivost přináší růže: Velkým problémem Javascriptu je absence typování v jazyku. Jednak je prakticky nemožné udělat spolehlivý hinting v IDE, což se u trochu větších projektů projevuje sníženou produktivitou. S tím souvisí i menší počet chyb, které nemohou být odhaleny při kompilaci a musí se odladit až testováním => opět snížená produktivita.
To nie je problém, to je feature. JS je proste dynamicky typovaný jazyk. A zďaleka nie jediný. Kto sa s tým nevie zžiť, môže použiť TypeScript. Ale mňa nepresvedčil. Výsledný kód je doslova bloated oproti čistému JS. Navyše, keďže k rozsiahlejšiemu projektu treba automaticky písať aj testy, nevidím v tom už úplne žiadny problém v tom, že je dynamicky typovaný. Alebo si myslíte, že keby bol staticky typovaný, tak by nebolo treba písať testy? Bolo, skúste zagoogliť. Plus si skúste vygoogliť aká je hustota chýb v staticky a v dynamicky typovaných jazykoch. Rozdiel vás prekvapí a kvôli nemu nie je TS potrebný. Stačia testy a keď už silou mocou chcem statickú analýzu, preženiem to cez Flow aj bez definície jediného typu. Statické typy sú preceňované, aj to sa dá vygoogliť. A rovnako sa dá vygoogliť, že takto uvažujú napríklad inžinieri od Uberu. Ale pokojne si môžete ďalej myslieť, že stavali svoj Fusion framework od základov bez TS, lebo sú neproduktívni. Tak či onak stále platí, že dynamicky typované jazyky nie sú zle navrhnuté, stavajú len na inej paradigme, stále platí, že staticky typované nie sú žiadny silver bullet a stále platí, že v praxi sa dá JS použiť aj na megarozsiahly projekt tak, ako je navrhnutý. S dynamickými typmi. Popravde, ale to už vyslovene subjektívne, myslím, že s TS budete menej efektívny / produktívny. Akurát tak projekt spomalíte, priamo aj nepriamo predražíte, s minimálnym dopadom výsledný počet chýb.
-
https://wtfjs.com/
:o Díky moc! Tohle by mělo ukončit všechny debaty...
Nevím, jestli zrovna https://wtfjs.com/wtfs/2014-01-29-regular-expression-and-slash (autorova totální obecná neznalost regexpů, a nesmyslný předpoklad že by /[A-z]/ mělo matchnout jen písmena), nebo https://wtfjs.com/wtfs/2014-10-07-true-equals-false (překvapení, že !!"string" je true, ať už jde o !!"Ne", !!"true" nebo !!"false") jsou zrovna ukázky chybně navrženého jazyka ...
-
1. monkey patching. Nevidím problém v možnosti přidat nějakou metodu jako takové. Ale v tom, že bez varování mohu přepisovat existující, to mi přijde nešikovné.
2. jazyk je to strašně ukecanej, na to, že toho zase tolik neumí
3. žádná podpora pro zapouzdření. Zapouzdřenost ala Python by mi stačila.
4. nejednotnost - třeba jazyk Lua má pro "nic" jen jednu hodnotu. A můžeš na ni normálně "šahat", chybu ti vyhodí tepreve nil of nil. Javascript má undefined, null, '', 0, false. Vytváření objektu jde taky dělat na několik způsobů, včetně pravěkého "new".
5. absence foreach mě furt nutila přecházet do transpilerů
6. má typy ale nemá statické typování - prvé bez druhého podle mého nemá vůbec žádný smysl. Buď ať je to dynamický jazyk bez typů (příklad Lua, Erlang), nebo staticky typovaný.
-
Uz umi js formatovani retezcu a cisel?
ne, ale řetězec a číslo je v javascriptu totéž:
"111" == 111; -> true
:-)
Nie, nie je. Typeof "111" je reťazec, typeof 111 je číslo. A že nevieš, sa pri porovnaní nekompatibilných typov najprv vykoná implicit coercion, je tvoja neznalosť, nie problém s JS.
-
Uz umi js formatovani retezcu a cisel?
ne, ale řetězec a číslo je v javascriptu totéž:
"111" == 111; -> true
:-)
Nie, nie je. Typeof "111" je reťazec, typeof 111 je číslo. A že nevieš, sa pri porovnaní nekompatibilných typov najprv vykoná implicit coercion, je tvoja neznalosť, nie problém s JS.
Ale kazdej takovej jazyk je pak nebezpecnej svetu, protoze se realne *NEDA* otestovat, jak to bude spolehlive. Leda mit na kazdem tretim radku force typu :) To plati i pro PHP (== vs ===). Nesouhlasim, ze to je o 'nevim'. Je, dle meho, zasadni problem. Nechtel bych, aby muj zivot (treba nekde v aute :) zavisel na tom, jestli se nahodou neco (ne)povede. Z meho pohledu: to co selze pokazdy je o 10 radu lepsi, nez to co selze 'nekdy'. Treba kvuly zapomenutymu testu na '.' nekde kdesi naprosto jinde v kodu (a je z toho hnedle float)
Kolemjdouci
-
https://wtfjs.com/
:o Díky moc! Tohle by mělo ukončit všechny debaty...
Nevím, jestli zrovna https://wtfjs.com/wtfs/2014-01-29-regular-expression-and-slash (autorova totální obecná neznalost regexpů, a nesmyslný předpoklad že by /[A-z]/ mělo matchnout jen písmena), nebo https://wtfjs.com/wtfs/2014-10-07-true-equals-false (překvapení, že !!"string" je true, ať už jde o !!"Ne", !!"true" nebo !!"false") jsou zrovna ukázky chybně navrženého jazyka ...
Dík, ale opakujem: hľadám len problémy z praxe. Problémy pri tvorbe web aplikácií, kde niekto narazil na reálny problém s JS. A nie ďalšie "akademické" debaty o ideálnom jazyku / syntaxe. Wtfjs je pre blbečkov - kto JS ovláda, s "chybami" tam uvedenými ráta.
-
To nie je problém, to je feature.
Aha, takže jsi opravdu troll. Tak nic.
-
Uz umi js formatovani retezcu a cisel?
ne, ale řetězec a číslo je v javascriptu totéž:
"111" == 111; -> true
:-)
Nie, nie je. Typeof "111" je reťazec, typeof 111 je číslo. A že nevieš, sa pri porovnaní nekompatibilných typov najprv vykoná implicit coercion, je tvoja neznalosť, nie problém s JS.
Ale kazdej takovej jazyk je pak nebezpecnej svetu, protoze se realne *NEDA* otestovat, jak to bude spolehlive. Leda mit na kazdem tretim radku force typu :) To plati i pro PHP (== vs ===). Nesouhlasim, ze to je o 'nevim'. Je, dle meho, zasadni problem. Nechtel bych, aby muj zivot (treba nekde v aute :) zavisel na tom, jestli se nahodou neco (ne)povede. Z meho pohledu: to co selze pokazdy je o 10 radu lepsi, nez to co selze 'nekdy'. Treba kvuly zapomenutymu testu na '.' nekde kdesi naprosto jinde v kodu (a je z toho hnedle float)
Kolemjdouci
Len nevieš o čom hovoríš a tvoj scenár z dynamicky typovaných jazykov vôbec automaticky nevyplýva.
-
1. monkey patching. Nevidím problém v možnosti přidat nějakou metodu jako takové. Ale v tom, že bez varování mohu přepisovat existující, to mi přijde nešikovné.
2. jazyk je to strašně ukecanej, na to, že toho zase tolik neumí
3. žádná podpora pro zapouzdření. Zapouzdřenost ala Python by mi stačila.
4. nejednotnost - třeba jazyk Lua má pro "nic" jen jednu hodnotu. A můžeš na ni normálně "šahat", chybu ti vyhodí tepreve nil of nil. Javascript má undefined, null, '', 0, false. Vytváření objektu jde taky dělat na několik způsobů, včetně pravěkého "new".
5. absence foreach mě furt nutila přecházet do transpilerů
6. má typy ale nemá statické typování - prvé bez druhého podle mého nemá vůbec žádný smysl. Buď ať je to dynamický jazyk bez typů (příklad Lua, Erlang), nebo staticky typovaný.
1. Ide to. Object.defineProperty()
2. Nepodstatné
3. Isteže nemá, je postavený na inom princípe, zrovnávaš hrušky s jablkami.
4. Nepodstatné, stačí vedieť čo robíš.
5. Má foreach.
6. Len tvoj názor. Ide použiť tak ako je, to nie je praktický problém.
-
To nie je problém, to je feature.
Aha, takže jsi opravdu troll. Tak nic.
Alebo len nemám trpezlivosť s mudrlantov, čo sa vyjadrujú o veciach o ktorých nič nevedia... Ešte raz: toto má byť o problémoch z praxe, nie o pseudointelektuálnych žvástoch ako je tu zvykom. Ak robíš aktívne v JS na konkrétnom projekte a máš kvôli JS konkrétny problém, píš. Inak mlč.
-
Dve stránky kecov a ani jeden praktický problém. Len samá teória, mudrovanie, porovnávanie, ale skutočný problém ANI JEDEN???
-
Uz umi js formatovani retezcu a cisel?
ne, ale řetězec a číslo je v javascriptu totéž:
"111" == 111; -> true
:-)
Nie, nie je. Typeof "111" je reťazec, typeof 111 je číslo. A že nevieš, sa pri porovnaní nekompatibilných typov najprv vykoná implicit coercion, je tvoja neznalosť, nie problém s JS.
Nejde o neznalost, jde o to, že pokud tohle jazyk dělá, tak to může být 1000x napsáno v dokumentaci, ale stále to neznamená, že je to dobrý nápad. A jestli chceš reálný problém, tak zrovna dnes jsme s frontenďákem zkoušeli propojit co dělal on s naším backendem. Jemu to házelo 500, přitom stejný JSON poslaný přes curl vracel přesně co měl. Nakomec se ukázalo, že z JavaScriptu sice šel content-type application/json, v post datech byl JSON, ale ten byl ještě zabalený do řetězce. Takže přesně takové chyby pak tyto "featury" způsobují, v JavaScriptu to v unit testech funguje, ale okolní svět očekává JSON Object, ne String. Nebo má snad okolní svět ty post data parsovat přes json dvakrát?
-
Dve stránky kecov a ani jeden praktický problém. Len samá teória, mudrovanie, porovnávanie, ale skutočný problém ANI JEDEN???
Myslim, ze ziadne nie su. Je to velmi profesionalny a bezproblemovy jazyk. Povrava sa, ze NASA do neho prepise svoje riadiace systemy.
-
Dve stránky kecov a ani jeden praktický problém. Len samá teória, mudrovanie, porovnávanie, ale skutočný problém ANI JEDEN???
Myslim, ze ziadne nie su. Je to velmi profesionalny a bezproblemovy jazyk. Povrava sa, ze NASA do neho prepise svoje riadiace systemy.
Ano, řídí se příkladem Slovenské vesmírné agentury.
-
Uz umi js formatovani retezcu a cisel?
ne, ale řetězec a číslo je v javascriptu totéž:
"111" == 111; -> true
:-)
Nie, nie je. Typeof "111" je reťazec, typeof 111 je číslo. A že nevieš, sa pri porovnaní nekompatibilných typov najprv vykoná implicit coercion, je tvoja neznalosť, nie problém s JS.
Nejde o neznalost, jde o to, že pokud tohle jazyk dělá, tak to může být 1000x napsáno v dokumentaci, ale stále to neznamená, že je to dobrý nápad. A jestli chceš reálný problém, tak zrovna dnes jsme s frontenďákem zkoušeli propojit co dělal on s naším backendem. Jemu to házelo 500, přitom stejný JSON poslaný přes curl vracel přesně co měl. Nakomec se ukázalo, že z JavaScriptu sice šel content-type application/json, v post datech byl JSON, ale ten byl ještě zabalený do řetězce. Takže přesně takové chyby pak tyto "featury" způsobují, v JavaScriptu to v unit testech funguje, ale okolní svět očekává JSON Object, ne String. Nebo má snad okolní svět ty post data parsovat přes json dvakrát?
O čom to hovoríš? Ako "dvakrát"? Prijatý JSON je VŽDY a VŠADE string.
-
Nejde o neznalost, jde o to, že pokud tohle jazyk dělá, tak to může být 1000x napsáno v dokumentaci, ale stále to neznamená, že je to dobrý nápad.
Přesně tak, to si také myslím. Jinak tenhle argument, že "je to přece v dokumentaci", ten se tu bohužel objevuje docela dost často.
-
Dve stránky kecov a ani jeden praktický problém. Len samá teória, mudrovanie, porovnávanie, ale skutočný problém ANI JEDEN???
Myslim, ze ziadne nie su. Je to velmi profesionalny a bezproblemovy jazyk. Povrava sa, ze NASA do neho prepise svoje riadiace systemy.
Ale inak doma všetko v poriadku?
-
Dve stránky kecov a ani jeden praktický problém. Len samá teória, mudrovanie, porovnávanie, ale skutočný problém ANI JEDEN???
Myslim, ze ziadne nie su. Je to velmi profesionalny a bezproblemovy jazyk. Povrava sa, ze NASA do neho prepise svoje riadiace systemy.
Ano, řídí se příkladem Slovenské vesmírné agentury.
Vy ste si fakt sadli. Hotový Puf a Muf :D K veci deti, o veci...
-
A čím iným sa chceš riadiť? Dokumentáciou od iného jazyka? Si ok?
-
čobolo to bolo, terazky umis ten ako sa to vola - javascript, tak si king.
ty ses neprisel bavit o jayku, ty jsi prisel machrovat jaky jsi borec ze umis (spis ne) ten nejlepsi jazyk na svete.
teda po slovenstine.
-
čobolo to bolo, terazky umis ten ako sa to vola - javascript, tak si king.
ty ses neprisel bavit o jayku, ty jsi prisel machrovat jaky jsi borec ze umis (spis ne) ten nejlepsi jazyk na svete.
teda po slovenstine.
Prišiel som s konkrétnou otázkou, upresnila som ju a napriek tomu mi tu píšu hlavne trolkovia ako ty, úplne od veci, a potom vyplakávajú, že s nimi nemám trpezlivosť? To sú vaše sračky, s tým sa naučte žiť sami :*
-
Uz umi js formatovani retezcu a cisel?
ne, ale řetězec a číslo je v javascriptu totéž:
"111" == 111; -> true
:-)
Nie, nie je. Typeof "111" je reťazec, typeof 111 je číslo. A že nevieš, sa pri porovnaní nekompatibilných typov najprv vykoná implicit coercion, je tvoja neznalosť, nie problém s JS.
Ale kazdej takovej jazyk je pak nebezpecnej svetu, protoze se realne *NEDA* otestovat, jak to bude spolehlive. Leda mit na kazdem tretim radku force typu :) To plati i pro PHP (== vs ===). Nesouhlasim, ze to je o 'nevim'. Je, dle meho, zasadni problem. Nechtel bych, aby muj zivot (treba nekde v aute :) zavisel na tom, jestli se nahodou neco (ne)povede. Z meho pohledu: to co selze pokazdy je o 10 radu lepsi, nez to co selze 'nekdy'. Treba kvuly zapomenutymu testu na '.' nekde kdesi naprosto jinde v kodu (a je z toho hnedle float)
Kolemjdouci
Co se nedá otestovat? Chci-li striktní porovnání, tak použiji "===". To jako budeme Pythonu vyčítat, že má "is", že Perl má "==" a "eq", že C má strcmp, apod.? K tomu se váže následující
Nejde o neznalost, jde o to, že pokud tohle jazyk dělá, tak to může být 1000x napsáno v dokumentaci, ale stále to neznamená, že je to dobrý nápad.
Přesně tak, to si také myslím. Jinak tenhle argument, že "je to přece v dokumentaci", ten se tu bohužel objevuje docela dost často.
Opravdu? Vtip je v tom, že u JS je to *ve standardu*. A to je sakra rozdíl (a buďme za to rádi). Zkus si programovat v C/C++ jen jak tě napadne, kašli na dokumentaci/standard, bo to přece není argument. ;)
-
K tématu. Co jsem pociťoval dost, je třeba formátování. "Klasické printf" by bylo fajn. Jakési private u tříd, apod. by bylo taky fajn, ale to tolik nebolí.
-
K tématu. Co jsem pociťoval dost, je třeba formátování. "Klasické printf" by bylo fajn. Jakési private u tříd, apod. by bylo taky fajn, ale to tolik nebolí.
To áno. Nie je čisto objektový, takže private len cez closure. Nepohodlné, ale tak ísť to ide. Formátovanie by bodlo, riešim to knižnicami, ale tak to nie je nič principiálne. Stále je to v pohode.
-
Já když tak přemýšlím, tak nic principíálního nenacházím.
Občas se něco dělá jinak než v jiných jazycích, ale to je jen o zvyku.
Co by mi vcelku často pomohlo, by byla lepší práce s datumy (DateAdd, DateDiff)
-
Ja nerozumim otazce. Muzes uvezt priklad problemu z praxe u jineho jazyka za stejnych/ekvivalentnich podminek jako si definoval pro js?
-
Ja nerozumim otazce. Muzes uvezt priklad problemu z praxe u jineho jazyka za stejnych/ekvivalentnich podminek jako si definoval pro js?
Nie. Lebo pointa je, že sa tu nadáva na JS, nie C++, či Javu. Ako videl som aj blbečkov nadávať na Javu a tvrdiť ako je C# ďaleko lepší, ale mňa teraz zaujíma či nejaký reálny web developer má reálny problém s nejakou web aplikáciou, lebo ja za roky praxe neviem o jedinom. Takže si myslím, že také kecy majú len ovce čo nevedia o čom hovoria. Ale snažím sa v rámci objektivity nájsť nejaký skutočný, blbo až nijak riešiteľný problém s nejakou web app.
-
Nejde o neznalost, jde o to, že pokud tohle jazyk dělá, tak to může být 1000x napsáno v dokumentaci, ale stále to neznamená, že je to dobrý nápad.
Přesně tak, to si také myslím. Jinak tenhle argument, že "je to přece v dokumentaci", ten se tu bohužel objevuje docela dost často.
Opravdu? Vtip je v tom, že u JS je to *ve standardu*. A to je sakra rozdíl (a buďme za to rádi). Zkus si programovat v C/C++ jen jak tě napadne, kašli na dokumentaci/standard, bo to přece není argument. ;)
Já beru, že je to v dokumentaci, a že je to ve standardu. Ale právě proto, to tam už zůstane, nikdo to neopraví. Považuju to za chybu návrhu, zatímco se Javascript tváří jednoduše, tak ve skutečnosti je to samý špek. A i když zkušený programátor bude o všech podobných výjimkách vědět, a budou popsané v té dokumentaci, tak se ty chyby nikam neztratí. A narazí se na ně právě v praxi, i když se počítají triviální věci...
-
Nie. ja za roky praxe neviem o jedinom. Takže si myslím, že také kecy majú len ovce čo nevedia o čom hovoria.
A nechtěl bys raději zase místo JS onanie jít mydlit toho barana (https://www.youtube.com/watch?v=fEyj-rXJbNw)? ;D
-
1. monkey patching. Nevidím problém v možnosti přidat nějakou metodu jako takové. Ale v tom, že bez varování mohu přepisovat existující, to mi přijde nešikovné.
2. jazyk je to strašně ukecanej, na to, že toho zase tolik neumí
3. žádná podpora pro zapouzdření. Zapouzdřenost ala Python by mi stačila.
4. nejednotnost - třeba jazyk Lua má pro "nic" jen jednu hodnotu. A můžeš na ni normálně "šahat", chybu ti vyhodí tepreve nil of nil. Javascript má undefined, null, '', 0, false. Vytváření objektu jde taky dělat na několik způsobů, včetně pravěkého "new".
5. absence foreach mě furt nutila přecházet do transpilerů
6. má typy ale nemá statické typování - prvé bez druhého podle mého nemá vůbec žádný smysl. Buď ať je to dynamický jazyk bez typů (příklad Lua, Erlang), nebo staticky typovaný.
1. Ide to. Object.defineProperty()
2. Nepodstatné
3. Isteže nemá, je postavený na inom princípe, zrovnávaš hrušky s jablkami.
4. Nepodstatné, stačí vedieť čo robíš.
5. Má foreach.
6. Len tvoj názor. Ide použiť tak ako je, to nie je praktický problém.
1. To je něco jiného.
2. Tvůj názor.
3. Ptal si se na problémy, toto je problém. Že je to jeho princip, to vím také.
4. Tvůj názor.
5. Nemá foreach.
Pokud si se ptal na to, zda jde Javascript použít, tak ano, jde použít. Ale tvá otázka vyzněla, že se ptáš na praktické problémy. Ony samozřejmě souvisí s principy, které javascript má.
Největší praktický problém který mám se všema netypovejma jazykama je ten, že něco napíšu, spustím, doklikám si někam a pak mi to chcípne někde uprostřed. A můžu to samé znova. To mě děsně vadí.
Pak mám samozřejmě vůči němu ještě další výhrady, ale ty už souvisí asi spíše použitím javascriptu v prohlížeči než v něm samém.
-
Nejde o neznalost, jde o to, že pokud tohle jazyk dělá, tak to může být 1000x napsáno v dokumentaci, ale stále to neznamená, že je to dobrý nápad.
Přesně tak, to si také myslím. Jinak tenhle argument, že "je to přece v dokumentaci", ten se tu bohužel objevuje docela dost často.
Opravdu? Vtip je v tom, že u JS je to *ve standardu*. A to je sakra rozdíl (a buďme za to rádi). Zkus si programovat v C/C++ jen jak tě napadne, kašli na dokumentaci/standard, bo to přece není argument. ;)
Já beru, že je to v dokumentaci, a že je to ve standardu. Ale právě proto, to tam už zůstane, nikdo to neopraví. Považuju to za chybu návrhu, zatímco se Javascript tváří jednoduše, tak ve skutečnosti je to samý špek. A i když zkušený programátor bude o všech podobných výjimkách vědět, a budou popsané v té dokumentaci, tak se ty chyby nikam neztratí. A narazí se na ně právě v praxi, i když se počítají triviální věci...
Ale já pořád nechápu, co je špatně. To, že "111" == 111 vyhodí true? Naopak se to hodí (když vím, co dělám), pokud to nechci používat / neznám, tak použiji ===.
JavaScript se tváří jednoduše? To záleží... začátky jednoduché jsou, je dostupný všude a má "u zkušených a světaznalých" programátorů pověst "primitivního, skriptovacího jazyka vhodného na formuláře". To je ale potom těžký, s takovým přístupem se do nohy člověk střelí i s něčím jako je... python... A "zas tolik" špeků tam není, programuje-li člověk slušně || ne něco specifického (kde je ale potom čtení dokumentace samozřejmostí).
Ten jazyk má své mouchy, ale je solidní, má spoustu zajímavých konceptů a je imho pěkný. :)
-
Ale já pořád nechápu, co je špatně. To, že "111" == 111 vyhodí true? Naopak se to hodí (když vím, co dělám), pokud to nechci používat / neznám, tak použiji ===.
Na té linkované stránce je toho dost, třeba:
[1,2,3,15,30,7,5,45,60].sort();
// = [1,15,2,3,30,45,5,60,7]
-
Ono je sice moc hezké označit nedostatky za featury, ale když s některými "featurami" má tolik lidí problém, je opravdu problém v těch lidech?
-
[1,2,3,15,30,7,5,45,60].sort();
// = [1,15,2,3,30,45,5,60,7]
[1,2,3,15,30,7,5,45,60].sort(function(a,b){a-b});
// = [ 1, 2, 3, 5, 7, 15, 30, 45, 60 ]
Souhlasím, že je to pakárna.
-
// lib/sorting.js
export const ascending = (a, b) => a - b;
import {ascending} from './lib/sorting';
[1, 15, 2, 3, 30, 45, 5, 60, 7].sort(ascending);
-
Ale já pořád nechápu, co je špatně. To, že "111" == 111 vyhodí true? Naopak se to hodí (když vím, co dělám), pokud to nechci používat / neznám, tak použiji ===.
Na té linkované stránce je toho dost, třeba:
[1,2,3,15,30,7,5,45,60].sort();
// = [1,15,2,3,30,45,5,60,7]
Protože The default sort order is according to string Unicode code points.
Ale ano, tohle není dvakrát intuitivní.
Ono je sice moc hezké označit nedostatky za featury, ale když s některými "featurami" má tolik lidí problém, je opravdu problém v těch lidech?
Ale to není "feature", to je standard. Je jasně specifikováno, jak to funguje. Navíc co je to za argument? S monádami v Haskellu má problém také spousta lidí... Problém "většiny" je v tom, že 1) nečte 2) je nepozorná a spoléhá se na něco, co "tak funguje jinde". Asi mate ta C-like syntax :)
-
O čom to hovoríš? Ako "dvakrát"? Prijatý JSON je VŽDY a VŠADE string.
Mluvím o tom, že když přijatý JSON (jako string) na backendu deserializuju a on je to stále string. Tj. když přijatý JSON místo
'{"foo": 1}'vypadá nějak takhle
'"{\"foo\": 1}"'
Ostatně, podobná chyba, když nám po změnách na frontendu začne na backend chodit
'{"sid": "null"}'
-
Sorry, možná se to řadí podle unicode, ale já v tom poli vidím integer ne string..
-
Sorry, možná se to řadí podle unicode, ale já v tom poli vidím integer ne string..
Ano, ale ono se to nejdřív "přetypuje". Respektive si to spíš představ jako lexikografické řazení, to je korektní i pro čísla. Nicméně můžeš tomu sortu strčit vlastní (lambda) funkci. ;)
-
S monádami v Haskellu má problém také spousta lidí
Na monádách se oddělí zrno od lopat :)
-
Tím bych si nebyl tak jistý... :)
-
Sorry, možná se to řadí podle unicode, ale já v tom poli vidím integer ne string..
Zkušený JS programátor v tom vidí string (http://img24.cz/images/10629076485795120689.png) ("\x01\x02\x03\x0f\x1e\x07\x05-<"), všechno je to ve specifikaci, nech si ty akademické debaty a uveď nějaký PRAKTICKÝ problém!
-
Nejde o neznalost, jde o to, že pokud tohle jazyk dělá, tak to může být 1000x napsáno v dokumentaci, ale stále to neznamená, že je to dobrý nápad.
Přesně tak, to si také myslím. Jinak tenhle argument, že "je to přece v dokumentaci", ten se tu bohužel objevuje docela dost často.
Opravdu? Vtip je v tom, že u JS je to *ve standardu*. A to je sakra rozdíl (a buďme za to rádi). Zkus si programovat v C/C++ jen jak tě napadne, kašli na dokumentaci/standard, bo to přece není argument. ;)
Já beru, že je to v dokumentaci, a že je to ve standardu. Ale právě proto, to tam už zůstane, nikdo to neopraví. Považuju to za chybu návrhu, zatímco se Javascript tváří jednoduše, tak ve skutečnosti je to samý špek. A i když zkušený programátor bude o všech podobných výjimkách vědět, a budou popsané v té dokumentaci, tak se ty chyby nikam neztratí. A narazí se na ně právě v praxi, i když se počítají triviální věci...
A premýšľal si niekedy aj nad tým prečo to nikto neopraví? Napoviem ... otvorím 15 rokov starú web stránku, vtedy ešte s "DHTML" efektami a bude fungovať rovnako ako vtedy...
-
Nie. ja za roky praxe neviem o jedinom. Takže si myslím, že také kecy majú len ovce čo nevedia o čom hovoria.
A nechtěl bys raději zase místo JS onanie jít mydlit toho barana (https://www.youtube.com/watch?v=fEyj-rXJbNw)? ;D
Divnejšie ako to, že v roku 2018 ešte existuje JS je to, že ešte existujú ľudia ako ty.
-
O čom to hovoríš? Ako "dvakrát"? Prijatý JSON je VŽDY a VŠADE string.
Mluvím o tom, že když přijatý JSON (jako string) na backendu deserializuju a on je to stále string. Tj. když přijatý JSON místo
'{"foo": 1}'vypadá nějak takhle
'"{\"foo\": 1}"'
Ostatně, podobná chyba, když nám po změnách na frontendu začne na backend chodit
'{"sid": "null"}'
A v akom jazyku ti na backende ostal z toho JSON po parsovaní string? Nemám s ním problém ani JS, ani v Java, ani v PHP. V akom jazyku a ako si ho deserializoval?
-
Ono je sice moc hezké označit nedostatky za featury, ale když s některými "featurami" má tolik lidí problém, je opravdu problém v těch lidech?
A v čom inom? Pokiaľ jeden je schopný naštudovať si to a zmysluplne ho napriek tomu použiť a druhý len nadávať aké je to zlé, v čom inom môže byť rozdiel?
-
S monádami v Haskellu má problém také spousta lidí
Na monádách se oddělí zrno od lopat :)
Tu to skôr vyzerá, že JS vie oddeliť zrno od lopát...
-
Sorry, možná se to řadí podle unicode, ale já v tom poli vidím integer ne string..
Zkušený JS programátor v tom vidí string (http://img24.cz/images/10629076485795120689.png) ("\x01\x02\x03\x0f\x1e\x07\x05-<"), všechno je to ve specifikaci, nech si ty akademické debaty a uveď nějaký PRAKTICKÝ problém!
No tak to by to právě viděl špatně. Nesedí ti to typově. ;)
-
Nie. ja za roky praxe neviem o jedinom. Takže si myslím, že také kecy majú len ovce čo nevedia o čom hovoria.
A nechtěl bys raději zase místo JS onanie jít mydlit toho barana (https://www.youtube.com/watch?v=fEyj-rXJbNw)? ;D
Divnejšie ako to, že v roku 2018 ešte existuje JS je to, že ešte existujú ľudia ako ty.
Upřímně řečeno, oproti několikadennímu leštění klády nad JS se jeví mydlení baranů jako celkem neškodná úchylka... ;D :P
-
Ono je sice moc hezké označit nedostatky za featury, ale když s některými "featurami" má tolik lidí problém, je opravdu problém v těch lidech?
A v čom inom? Pokiaľ jeden je schopný naštudovať si to a zmysluplne ho napriek tomu použiť a druhý len nadávať aké je to zlé, v čom inom môže byť rozdiel?
Dobře navržený produkt je mimo jiné snadno použitelný a vyhovuje ideálně všem. Dokumentace programovacího jazyka je samozřejmost, ne měřítko kvality. Tvrdit, že nějaký jazyk je perfektní jen na základě toho, že je dobře zdokumentovaný, a že je někdo schopný se jej naučit... tohle přeci není žádný smysluplný argument.
Samozřejmě v praxi je ne každý spokojený se vším, ale pokud se znovu a znovu kritizují tytéž konkrétní vlastnosti (byť zdokumentované), protože jsou nelogické, neintuitivní nebo prostě "divné", pak to o něčem svědčí.
-
Paci sa mi to uvazovanie zakldatala vlakna, najskor odfiltruje vsteko a potom na zvysok povie "is not bug is feature".
Ale tak mne napriklad vadi, ze funkcie sa namiesto slova fuction po novom pisu:
const foo (a)=> {
bla bla bla
};
A tiez znama vec:
funstion foo()
{
return
14;
}
-
Celkovo je to velmi nehomogeny a nkeonzisteny jazyk, co vyzera ako ked polepia nesuvisiace veci dokopy. Ktory sa vdaka vyvoju zhovadil (dlha absencia balickovacieho systemu, chybajuca a funckna standardna kniznica, komunita co nikdy nic nedokonci,...).
Celkovo mal zoszaz priskriptoch do 100 riadkov a prehliadace mali davno prejst na nejaky bytecod, aby sa uvolnil "technologicky lock".
-
Ale tak mne napriklad vadi, ze funkcie sa namiesto slova fuction po novom pisu:
Ono to ale ve skutečnosti není tak, že odteď je všechno lambda. Lambda je doplněk k funkcím, není to plnohodnotná funkce - nedá se použít jako konstruktorová funkce a není možné měnit její kontext(kontext je v JS celkově velmi důležitý aspekt, často přehlížený).
Už tady plno lidí doporučovalo přečíst si dokumentaci. Vím, že je to podle vás možná zbytečnost, ale s JS vám asi nic jiného nezbyde.
-
Ale tak mne napriklad vadi, ze funkcie sa namiesto slova fuction po novom pisu:
const foo (a)=> {
bla bla bla
};
když už, tak
const foo = (a) => {
bla bla bla
};
-
ja nechapem ze sa vam chce robit v takychto pofidernych technologiach ako javascript, paneboze ...
aj ked vsetci nadavaju na javu alebo podobne tak javascript tam NIKDY NEBUDE aj ked by sa cely JS svet postavil na hlavu, rovnako vsetky sragory typu Ruby alebo Python ci nebodaj Go ... to co je za jazyky prosim vas?
Ja by som v nicom inom ako v Jave, C# alebo v Scale, Erlang nerobil ... Proste cim vacsie firmy za tym su, tym to je stabilnejsie, viac toolingu, vsade komercna podpora, kto v 2018 robi nejake weby v Ruby? To je dobre tak na nejaku sukromnu stranku zacinajuceho zahradkara.
-
Proste cim vacsie firmy za tym su, tym to je stabilnejsie, viac toolingu, vsade komercna podpora, ...
Jistě, takový Windows 10 jsou krásným důkazem.
-
Proste cim vacsie firmy za tym su, tym to je stabilnejsie, viac toolingu, vsade komercna podpora, ...
Jistě, takový Windows 10 jsou krásným důkazem.
neviem co ma windows 10 spolocne s programovacimi jazykmi.
Ano, C# a Java je vendor lock-in jak svina (aspon co sa C# tyka tak viac menej skoro urcite) ale co s tym akoze ma dev co nechce zarabat 30k v hrubom robit? To je sucast toho jobu.
Cim rozsirenejsi ten jazyk je, tym tazsie je ho zabit, pretoze sa na to nabaluje milion dalsich technologii na ktore nie je ziadna nahrada. Nejaky prdlackovy web v ruby sa nahradi relativne lahko, ale nejake Java a C# backendy nejake Go len tak nenahradi, aj ked to je mokry sen vela ludi
-
Můj názor na JS se zhoršuje a může za to Vlado, který jasné nedostatky tohoto jazyka bagatelizuje. Tomu se říká medvědí služba. Takže abych to shrnul, praktický nedostatek JS je, že funguje nelogicky, je plný skrytých špeků a i základní jednoduché věci se v něm dělají složitě. A i když si to Vledo nepřizná, tak to jsou praktické problémy jazyka.
Mám rád podobenství. Představme si automobil, kterému funguje volant naopak, při otočení doprava zatočí doleva. Pro všechny lidi je to problém, jen pro Vlada je to v manuálu popsaná featura. Vlado je z těch programátorů, kteří si nepřipouští, že jeho programy mají nedostatky, resp. se jich zbavuje tím, že je popíše v manuálu.
-
Proste cim vacsie firmy za tym su, tym to je stabilnejsie, viac toolingu, vsade komercna podpora, ...
Jistě, takový Windows 10 jsou krásným důkazem.
nejake Go len tak nenahradi, aj ked to je mokry sen vela ludi
Proč by jako mělo? To nějak žereš, čobole. Pro normální lidi je jazyk jen prostředek, ať už Go, Java nebo třeba F#.
-
Klasická js prasárna:
'' == 0 // true
0 == '0' // true
'' == '0' // false
-
Javascript byl vytvoreny za 10 dni. Takze ted uz je to jen stavba na shnilych zakladech.
-
Nebo tohle taky pobaví:
var a = [1,2,3];
var b = [1,2,3];
a == b // false
-
Proste cim vacsie firmy za tym su, tym to je stabilnejsie, viac toolingu, vsade komercna podpora, ...
Jistě, takový Windows 10 jsou krásným důkazem.
neviem co ma windows 10 spolocne s programovacimi jazykmi.
Ano, C# a Java je vendor lock-in jak svina (aspon co sa C# tyka tak viac menej skoro urcite) ale co s tym akoze ma dev co nechce zarabat 30k v hrubom robit? To je sucast toho jobu.
Cim rozsirenejsi ten jazyk je, tym tazsie je ho zabit, pretoze sa na to nabaluje milion dalsich technologii na ktore nie je ziadna nahrada. Nejaky prdlackovy web v ruby sa nahradi relativne lahko, ale nejake Java a C# backendy nejake Go len tak nenahradi, aj ked to je mokry sen vela ludi
Skus sa zamysliet naco je taky programovaci jazyk, ak chces patrit medzi fanusikov "najlepsich" skus radsej pozerat a fandit futbalovemu muzstvu. Programovaci jazyk je o vyjadreni myslienky urcitym sposobom a ci sa ti to paci alebo nie, skoro kazdy jazyk sa hodi na nieco ine. Skus v C robit webovku, alebo v PHP pisat nejaky ovladac. Vidis?
-
Takze v JS je prakticky problem pri praci s cisly, pri prace s retezci, pri praci s datovymi typy a to nejen pri porovnavani hodnot. Tedy v naprostych zakladech jazyka. Troufnu si tvrdit, ze JS neumi porovnat dve hodnoty, chybi mu na to operator, viz priklady vyse.
-
Ako vidím, žiadna zmena. Stále sem vypisujú predovšetkým lopaty a len málo reálnych web developerov. Lopaty ktoré doteraz všetky stránky generujú na serveri a loose coupled architektúry im nič nehovoria a v živote by nedokázali nakódiť SPA, či nebodaj rovno PWA apku. Čo sa divím, lebo ešte aj Vaadin začal používať web komponenty na frontende, konkrétne Polymérové a aj podľa Java developerov to značne uľahčuje a urýchľuje vývoj. Ale tak zdá sa, že nie len mentálne, ešte aj znalostne ste pozadu. Čo už, väčší priestor pre uplatnenie, vlastne dík...
-
Mimochodem v Pythonu
a = [1,2,3]
b = [1,2,3]
a == b // false
a is b // true
PHP také dokáže vyhodnotit správně equalitu. LUA to nedokáže.
-
Hledal jsi problémy z praxe, tak ti jeden dám. Sice je z oblasti, kterou jsi vyfiltroval, ale je to reálný problém použití JS na serveru. Na začátek jen doplním, že nejsem žádný JS hater, první aplikace v node.js jsem psal v době, kdy zdejší mistři ani netušili, že něco takového vůbec existuje (verze 0.4).
Jednalo se o streamovací aplikaci, která načítala na portu stream dat, modifikovala jej a obohacovala o data z databáze a přeposílala dále. Node.js byl použit z důvodu výkonosti, jednoduchosti a rychlosti vývoje (na začátku to byl spíš prototyp).
Protože se nejednalo o webovou službu, vznikl dodatečně požadavek, aby výsledkem byla binárka. Sice to přineslo první komplikace a předělávání, ale povedlo se. Další komplikace vznikla, když zákazník požadoval nasazení na RHEL6, který, ale oficiálně node.js nepodporoval (tehdy verze 4.x). Po různých (poměrně komplikovaných hacích) se i toto povedlo a zhruba rok jela aplikace v produkci. [Přes zmíněné komplikace je potřeba říct, že to vše šlo poměrně hladce a hlavně rychle.] Pak přišly požadavky na doplnění a hlavně se objevil problém/bug. Trochu se změnila struktura vstupních dat a jedno pole, které kolidovalo s JS objektem se nepropagovalo.
V té chvíli došlo k rozhodnutí udělat definitivní krok a přepsat produkční prototyp do kompilovaného jazyka (Go). Díky rozsáhlé standardní knihovně a jedné externí knihovně se rozsah aplikace (SLOC) zmenšil zhruba na polovinu, zásadně se zmenšil počet externích závislostí na 3! (db driver, cache a de-facto standardní balík na práci s chybami, což bylo neuvěřitelné zjednodušení údržby), významně se zjednodušil build proces (kroskompilace) a bylo to naprosto nezávislé na tom, co je pod tím.
Velice komplikovaná a časově náročná údržba závislostí v node.js je důvod, proč jsem node.js více méně úplně opustil, i když vývoj v něm je extrémně rychlý a nesmírně produktivní. Pokud to porovnám právě s Go, vývoj v jazyce Go není příliš pomalejší, ale poprodukční údržba projektu je o řád jednodušší. Zvláště třeba u webových služeb, kde vše (včetně šablon a assetů) zabalím do jedné binárky.
-
Proste cim vacsie firmy za tym su, tym to je stabilnejsie, viac toolingu, vsade komercna podpora, ...
Jistě, takový Windows 10 jsou krásným důkazem.
neviem co ma windows 10 spolocne s programovacimi jazykmi.
Ano, C# a Java je vendor lock-in jak svina (aspon co sa C# tyka tak viac menej skoro urcite) ale co s tym akoze ma dev co nechce zarabat 30k v hrubom robit? To je sucast toho jobu.
Cim rozsirenejsi ten jazyk je, tym tazsie je ho zabit, pretoze sa na to nabaluje milion dalsich technologii na ktore nie je ziadna nahrada. Nejaky prdlackovy web v ruby sa nahradi relativne lahko, ale nejake Java a C# backendy nejake Go len tak nenahradi, aj ked to je mokry sen vela ludi
Skus sa zamysliet naco je taky programovaci jazyk, ak chces patrit medzi fanusikov "najlepsich" skus radsej pozerat a fandit futbalovemu muzstvu. Programovaci jazyk je o vyjadreni myslienky urcitym sposobom a ci sa ti to paci alebo nie, skoro kazdy jazyk sa hodi na nieco ine. Skus v C robit webovku, alebo v PHP pisat nejaky ovladac. Vidis?
to je jasna vec, nikto tu nejde pisat weby v cecku, ale pisat nejake backendy v javascripte ... preco by som to robil? na nejake patlaniny na frontende to je dobre.
rovnako nepouzijem jazyky nad jvm tam kde potrebujem ist na zelezo s ceckom
len nechapem, kto si to dobrovolne vyberie na frontende ...
-
Nebo tohle taky pobaví:
var a = [1,2,3];
var b = [1,2,3];
a == b // false
Takze v JS je prakticky problem pri praci s cisly, pri prace s retezci, pri praci s datovymi typy a to nejen pri porovnavani hodnot. Tedy v naprostych zakladech jazyka. Troufnu si tvrdit, ze JS neumi porovnat dve hodnoty, chybi mu na to operator, viz priklady vyse.
Nerozumím tomu, proč někdo ze sebe dělá dobrovolně blbce? :-\
-
Ako vidím, žiadna zmena. Stále sem vypisujú predovšetkým lopaty a len málo reálnych web developerov. Lopaty ktoré doteraz všetky stránky generujú na serveri a loose coupled architektúry im nič nehovoria a v živote by nedokázali nakódiť SPA, či nebodaj rovno PWA apku. Čo sa divím, lebo ešte aj Vaadin začal používať web komponenty na frontende, konkrétne Polymérové a aj podľa Java developerov to značne uľahčuje a urýchľuje vývoj. Ale tak zdá sa, že nie len mentálne, ešte aj znalostne ste pozadu. Čo už, väčší priestor pre uplatnenie, vlastne dík...
Nenech se vysmát lopato bez rozhledu. JavaScript je na webovém frontendě zatím nenahraditelný, to mu zajišťuje široké uplatnění, ale ani o trochu to ze špatně navrženého jazyka nedělá lepší.
-
Mimochodem v Pythonu
a = [1,2,3]
b = [1,2,3]
a == b // false
a is b // true
PHP také dokáže vyhodnotit správně equalitu. LUA to nedokáže.
Meanwhile
Python 3.5.3 (default, Jan 19 2017, 14:11:04)
Type 'copyright', 'credits' or 'license' for more information
IPython 6.5.0 -- An enhanced Interactive Python. Type '?' for help.
In [1]: a = [1,2,3]
...: b = [1,2,3]
...:
...:
In [2]: a==b
Out[2]: True
In [3]: a is b
Out[3]: False
-
to je jasna vec, nikto tu nejde pisat weby v cecku, ale pisat nejake backendy v javascripte ... preco by som to robil? na nejake patlaniny na frontende to je dobre.
Ani na frontend to není dobrý, ale prostě nic lepšího není.
-
Nebo tohle taky pobaví:
var a = [1,2,3];
var b = [1,2,3];
a == b // false
Takze v JS je prakticky problem pri praci s cisly, pri prace s retezci, pri praci s datovymi typy a to nejen pri porovnavani hodnot. Tedy v naprostych zakladech jazyka. Troufnu si tvrdit, ze JS neumi porovnat dve hodnoty, chybi mu na to operator, viz priklady vyse.
Nerozumím tomu, proč někdo ze sebe dělá dobrovolně blbce? :-\
Tak já to zkusím ještě jednodušeji:
JS: [1, 2, 3] == [1, 2, 3] // false
PY: [1, 2, 3] == [1, 2, 3] // true
PHP: [1, 2, 3] == [1, 2, 3] // true
-
Meanwhile
Díky za upozornění, přehodil jsem popisky.
-
Nebo tohle taky pobaví:
var a = [1,2,3];
var b = [1,2,3];
a == b // false
Takze v JS je prakticky problem pri praci s cisly, pri prace s retezci, pri praci s datovymi typy a to nejen pri porovnavani hodnot. Tedy v naprostych zakladech jazyka. Troufnu si tvrdit, ze JS neumi porovnat dve hodnoty, chybi mu na to operator, viz priklady vyse.
Nerozumím tomu, proč někdo ze sebe dělá dobrovolně blbce? :-\
Tak já to zkusím ještě jednodušeji:
JS: [1, 2, 3] == [1, 2, 3] // false
PY: [1, 2, 3] == [1, 2, 3] // true
PHP: [1, 2, 3] == [1, 2, 3] // true
ja len dodam :D
scala> List(1,2,3) == List(1,2,3)
res0: Boolean = true
-
Nebo tohle taky pobaví:
var a = [1,2,3];
var b = [1,2,3];
a == b // false
A co je na tom divného?
V JS je pole objekt.
Porovnáním object == object jen otestuješ, jestli jde o tentýž objekt (proto a == a vrátí true).
JS bohužel nemá žádnou metodu nebo funkci na porovnání obsahu dvou objektů, ale pro běžné případy se to dá vcelku jednoduše obejít: :) (nebo si na to napsat plnohodnotnou metodu na porovnání)
JSON.stringify(a) == JSON.stringify(b); // true
-
Ako vidím, žiadna zmena. Stále sem vypisujú predovšetkým lopaty a len málo reálnych web developerov. Lopaty ktoré doteraz všetky stránky generujú na serveri a loose coupled architektúry im nič nehovoria a v živote by nedokázali nakódiť SPA, či nebodaj rovno PWA apku. Čo sa divím, lebo ešte aj Vaadin začal používať web komponenty na frontende, konkrétne Polymérové a aj podľa Java developerov to značne uľahčuje a urýchľuje vývoj. Ale tak zdá sa, že nie len mentálne, ešte aj znalostne ste pozadu. Čo už, väčší priestor pre uplatnenie, vlastne dík...
Tvoje loser coupled “architektury” nikoho nezajímají :p
-
Javascript nemá forEach
const arr = [1, 2, 3];
const obj = {a: 1, b: 2, c: 3};
const str = '123';
const set = new Set([1, 2, 3]);
const map = new Map([[0, 1], [1, 2], [2, 3]]);
Object.entries(obj).forEach(([key, value]) => {
console.log(key, value);
});
arr.forEach((value, key) => {
console.log(key, value);
});
Array.from(str).forEach((value, key) => {
console.log(key, value);
});
Array.from(set).forEach((value, key) => {
console.log(key, value);
});
map.forEach((value, key) => {
console.log(key, value);
});
Jinak je samozřejmě k dispozici for, for in a for of.
-
Mám rád podobenství. Představme si automobil, kterému funguje volant naopak, při otočení doprava zatočí doleva. Pro všechny lidi je to problém, jen pro Vlada je to v manuálu popsaná featura. Vlado je z těch programátorů, kteří si nepřipouští, že jeho programy mají nedostatky, resp. se jich zbavuje tím, že je popíše v manuálu.
Úplně přesně totéž napadlo mě ;-)
-
Nebo tohle taky pobaví:
var a = [1,2,3];
var b = [1,2,3];
a == b // false
A co je na tom divného?
V JS je pole objekt.
Porovnáním object == object jen otestuješ, jestli jde o tentýž objekt (proto a == a vrátí true).
JS bohužel nemá žádnou metodu nebo funkci na porovnání obsahu dvou objektů, ale pro běžné případy se to dá vcelku jednoduše obejít: :) (nebo si na to napsat plnohodnotnou metodu na porovnání)
JSON.stringify(a) == JSON.stringify(b); // true
Na porovnani identity objektu mas operator ===. Na porovnani obsahu objektu mas ==, ale v JS je spatne implementovan. Ale tak hlavne ze porovnava cislo se stringem.
-
Jestli to není spíš jako jet na motorce a divit se, že tam nejsou pedály :-)
-
Javascript nemá forEach
const arr = [1, 2, 3];
const obj = {a: 1, b: 2, c: 3};
const str = '123';
const set = new Set([1, 2, 3]);
const map = new Map([[0, 1], [1, 2], [2, 3]]);
Object.entries(obj).forEach(([key, value]) => {
console.log(key, value);
});
arr.forEach((value, key) => {
console.log(key, value);
});
Array.from(str).forEach((value, key) => {
console.log(key, value);
});
Array.from(set).forEach((value, key) => {
console.log(key, value);
});
map.forEach((value, key) => {
console.log(key, value);
});
Jinak je samozřejmě k dispozici for, for in a for of.
forEach v JS není konstrukt ale metoda (tzn objekt) a průběh se určuje přes callback. Neříkám že to je vyloženě špatně, ale pro mě to snižuje užitnost jazyka.
-
Jestli to není spíš jako jet na motorce a divit se, že tam nejsou pedály :-)
Typicky tohle
[1,2,3,15,30,7,5,45,60].sort();
// = [1,15,2,3,30,45,5,60,7]
je volant (řidítka, knipl, cokoliv), co otáčí dopravní prostředek na druhou stranu, než je přirozené a než všichni očekávají.
-
Na porovnani identity objektu mas operator ===. Na porovnani obsahu objektu mas ==
V JS se objekty porovnávají striktně. Operátor === jenom vynechává konverze. Jak a tak b jsou objekty, proto je úplně jedno, jestli použiješ == nebo ===.
-
Nebuďte tak krutý, někdo ty preplacane weby dělat musí :)
-
Na porovnani identity objektu mas operator ===. Na porovnani obsahu objektu mas ==, ale v JS je spatne implementovan. Ale tak hlavne ze porovnava cislo se stringem.
Co mi napíše java nebo c# na (volná syntaxe)?:
var x = new object(bla bla bla);
var y = new object(bla bla bla);
(x == y)
taky false, protože neporovnává obsah, ale zda jde o totožný objekt (stejně jako v JS).
=== to nevylepší, protože k předchozímu jen přidá porovnání typu proměnné (zde object).
Proto java i c# na skutečné porovnání obsahu používá .equals() které JS nemá, ale není problém si ho přidat z nějaké knihovny nebo dopsat (anebo použít to výše uvedené porovnání objektů převedených na JSON stringy) .
-
Je volant (řidítka, knipl, cokoliv), co otáčí dopravní prostředek na druhou stranu, než je přirozené a než všichni očekávají.
Já vás svým způsobem chápu, ale "je to trochu jinak, než jinde a já jsem líný si přečíst dokumentaci" je takový dost slabý argument. To nevztahuju jenom na JavaScript, ale celkově.
-
Jestli to není spíš jako jet na motorce a divit se, že tam nejsou pedály :-)
Typicky tohle
[1,2,3,15,30,7,5,45,60].sort();
// = [1,15,2,3,30,45,5,60,7]
je volant (řidítka, knipl, cokoliv), co otáčí dopravní prostředek na druhou stranu, než je přirozené a než všichni očekávají.
Protože řadí lexikograficky...? Většinou očekávám, že výsledek lexikografického sortu, bude lexikograficky seřazený vstup...
Na porovnani identity objektu mas operator ===. Na porovnani obsahu objektu mas ==, ale v JS je spatne implementovan. Ale tak hlavne ze porovnava cislo se stringem.
Co mi napíše java nebo c# na (volná syntaxe)?:
var x = new object(bla bla bla);
var y = new object(bla bla bla);
(x == y)
taky false, protože neporovnává obsah, ale zda jde o totožný objekt (stejně jako v JS).
=== to nevylepší, protože k předchozímu jen přidá porovnání typu proměnné (zde object).
Proto java i c# na skutečné porovnání obsahu používá .equals() které JS nemá, ale není problém si ho přidat z nějaké knihovny nebo dopsat (anebo použít to výše uvedené porovnání objektů převedených na JSON stringy) .
TYVOGO, Java to má taky špatně a jinak, než všichni čekají! :o ;D ;D
-
Typicky tohle
[1,2,3,15,30,7,5,45,60].sort();
// = [1,15,2,3,30,45,5,60,7]
je volant (řidítka, knipl, cokoliv), co otáčí dopravní prostředek na druhou stranu, než je přirozené a než všichni očekávají.
Když na to narazíš poprvé, zjistíš si, že pro čísla je správná syntaxe např:
[1,2,3,15,30,7,5,45,60].sort((a, b) => (a - b));
a příště už to neřešíš a jen používáš.
Já bych to uzavřel - kdo vidí JS poprvé (asi většina z přítomných), toho spousta věcí překvapí, kdo v něm pracuje pravidelně, tak automaticky píše syntaxi tak, aby to fungovalo správně.
-
Typicky tohle
[1,2,3,15,30,7,5,45,60].sort();
// = [1,15,2,3,30,45,5,60,7]
je volant (řidítka, knipl, cokoliv), co otáčí dopravní prostředek na druhou stranu, než je přirozené a než všichni očekávají.
Když na to narazíš poprvé, zjistíš si, že pro čísla je správná syntaxe např:
[1,2,3,15,30,7,5,45,60].sort((a, b) => (a - b));
a příště už to neřešíš a jen používáš.
Já bych to uzavřel - kdo vidí JS poprvé (asi většina z přítomných), toho spousta věcí překvapí, kdo v něm pracuje pravidelně, tak automaticky píše syntaxi tak, aby to fungovalo správně.
To je k bliti, rovnak na ohybak.
Osobne nechapu tuhle modu, jednou za cas vytahnout na svetlo sracku, ktera neresi davno vyresene zaklady a stavet na tom hype.
Kdyz nekdo navrhuje _NOVY_ jazyk, ocekaval bych, ze na tom bude lip, nez jazyky 20 let stare postavene na urovni computer science 80tych let...
-
Treba takove dinosauri cecko (resp jeho kompilery) za poslednich 20 let na kazdou jen trochu nebezpecnejsi nebo nejednoznacnejsi vec zacaly hazet warningy, ale jak koukam tak moderni trend je opacny, vynadat chudakovi nezkusenemu programatorovi do lam, lopat a at si precte dokumentaci.
BTW: Kdyz procitam povysenecke reakce Vlada na prvnich dvou strankach, opravdu rad bych videl nejaky jeho produkt. Byla by nejaka ukazka?
-
Na porovnani identity objektu mas operator ===. Na porovnani obsahu objektu mas ==, ale v JS je spatne implementovan. Ale tak hlavne ze porovnava cislo se stringem.
Co mi napíše java nebo c# na (volná syntaxe)?:
var x = new object(bla bla bla);
var y = new object(bla bla bla);
(x == y)
taky false, protože neporovnává obsah, ale zda jde o totožný objekt (stejně jako v JS).
=== to nevylepší, protože k předchozímu jen přidá porovnání typu proměnné (zde object).
Proto java i c# na skutečné porovnání obsahu používá .equals() které JS nemá, ale není problém si ho přidat z nějaké knihovny nebo dopsat (anebo použít to výše uvedené porovnání objektů převedených na JSON stringy) .
V C# to zalezi a tom ci si pretazil operator ==.
-
Jinak je samozřejmě k dispozici for, for in a for of.
Tak já jsem narážel na `for .. of` a je vidět, že mi to uteklo. Díky za doplnění.
-
[1,2,3,15,30,7,5,45,60].sort((a, b) => (a - b));
To je k bliti, rovnak na ohybak.
Pokud ti někdo řekne, že musíš povinně uvést porovnávací funkci, tak to zas tak hrozné není. Tímto způsobem můžeš řadit podle libovolného atributu objektů v kolekci.
-
Ten váš sort() je jedno z mála WTF, co moderní JS má. V PHP jich je mnohem víc a k pořádný práci je potřeba hodně knihoven.
Např. mě každej den vytáčí, že číslo/řetězec/pole neni objekt, takže nemůžu pěkně přehledně zavolat arr.filter(..).map(..) ale musim volání do sebe nepřehledně zanořit nebo několikrát za sebou přiřadit.
-
Populárna knižnica Ramda to má vyriešené tak, že je nutné zadať komparátor. Nie je defaultné triedenie.
Má tiež zabudovanú forEach funkciu.
const R = require('ramda');
let nums = [3, 1, 4, 2, 8, 5, 6];
console.log(R.sort((x, y) => x-y, nums));
console.log(R.sort((x, y) => y-x, nums));
nums.forEach(e => console.log(e), nums);
-
Treba takove dinosauri cecko (resp jeho kompilery) za poslednich 20 let na kazdou jen trochu nebezpecnejsi nebo nejednoznacnejsi vec zacaly hazet warningy, ale jak koukam tak moderni trend je opacny, vynadat chudakovi nezkusenemu programatorovi do lam, lopat a at si precte dokumentaci.
BTW: Kdyz procitam povysenecke reakce Vlada na prvnich dvou strankach, opravdu rad bych videl nejaky jeho produkt. Byla by nejaka ukazka?
Vlado je preci JS buh. Koupil si knizku a uz naprogramoval skoro funkcni tic-tac-toe!
-
Vlado je jen lopata co si čte dokumentaci před spaním a dělá machry.
Když už něco v JS dělat, tak bez TS ani ránu. Je to úplně nebe a dudy.
Až na to přijde i tady Vlado, tak se budeme mít všichni lépe a nebude třeba mu ukazovat na základní nedostatky jazyka JS,viz ty s*ačky se sortem a porovnáváním.
-
Populárna knižnica Ramda to má vyriešené tak, že je nutné zadať komparátor. Nie je defaultné triedenie.
Má tiež zabudovanú forEach funkciu.
A k čemu je to dobré, když to Javascript umí nativně?
-
https://wtfjs.com/
:o Díky moc! Tohle by mělo ukončit všechny debaty...
Presne tak, napraseny jazyk za 10 dni. Jsem rad, ze se javascript zatim nepouziva treba v medicine, autech, chemii...
-
Populárna knižnica Ramda to má vyriešené tak, že je nutné zadať komparátor. Nie je defaultné triedenie.
Má tiež zabudovanú forEach funkciu.
A k čemu je to dobré, když to Javascript umí nativně?
Ramda toho samozrejme dokáže oveľa viac. Keď už Ramdu používame v projekte, tak prečo v rámci konzistentnosti nepoužiť aj sort, forEach funkcie?
const R = require('ramda');
// senior is a person over 70
const users = [
{ name: 'John', age: 25 }, { name: 'Lenny', age: 51 },
{ name: 'Andrew', age: 43 }, { name: 'Peter', age: 81 },
{ name: 'Anna', age: 43 }, { name: 'Albert', age: 76 },
{ name: 'Adam', age: 47 }, { name: 'Robert', age: 72 }
];
console.log(R.pluck('age', users));
console.log(R.pluck('name', users));
let senAges = R.filter(e => e >= 70, R.pluck('age', users));
console.log(senAges);
console.log(`There are ${senAges.length} senior users`);
-
Treba takove dinosauri cecko (resp jeho kompilery) za poslednich 20 let na kazdou jen trochu nebezpecnejsi nebo nejednoznacnejsi vec zacaly hazet warningy, ale jak koukam tak moderni trend je opacny, vynadat chudakovi nezkusenemu programatorovi do lam, lopat a at si precte dokumentaci.
Nahoďte nějaký linter, ideálně ESLint (https://eslint.org/docs/user-guide/getting-started). Inteligentnější editor/IDE vás bude na warningy a chyby upozorňovat přímo v kódu, u těch tupějších vystačíte s konzolí. Dál si nainstalujte do prohlížeče podporu pro debugging(pokud to vaše IDE podporuje, třeba JetBrains IDE Support (https://chrome.google.com/webstore/detail/jetbrains-ide-support/hmhgeddbohgjknpmjagkdomcpobmllji)) a můžete si kódy v IDE rovnou krokovat. Jinak na hraní je super StackBlitz (https://stackblitz.com/), tam můžete zkoušet třeba nejasnosti při čtení dokumentace (https://developer.mozilla.org/en-US/docs/Web/javascript)...
-
Ked chcete realny problem:
Teraz rieism istu vec, potreboval sok kniznicu na pracu z X, na NPM nebol problem, lebo som ich nasiel asi 20-30. Zial jedna nevedela to, druha to, tretia, dalsia bola zabugovana, dalsia nezvldala UTF-8 enkoding atd... tazke som si po dvoch dnoch hladania ju musel poradit inak.
A najlepsie na tom bolo, ze ani jedna s tych kniznic nemala dokumentaciu okrem jedneho trapneho prikladu, takze na to aby som zistil, ci je pre mna vhodna som kazdu kniznicu musel vyskusat alebo sa pozerat na jej zdrojove kody.
Takze, ked mame jazyk, kde 90% kniznic je nedokoncenych polodorobkov, kde 90% komunity prasi kod, kde nedokazu zachovat konzistenciu jazyka ani stylu, kde na rutinne veci treba pouzivat kniznicu alebo trasnkompiler, asi s tym jazykom nebude nieco v poriadku.
-
Ramda toho samozrejme dokáže oveľa viac. Keď už Ramdu používame v projekte, tak prečo v rámci konzistentnosti nepoužiť aj sort, forEach funkcie?
const R = require('ramda');
// senior is a person over 70
const users = [
{ name: 'John', age: 25 }, { name: 'Lenny', age: 51 },
{ name: 'Andrew', age: 43 }, { name: 'Peter', age: 81 },
{ name: 'Anna', age: 43 }, { name: 'Albert', age: 76 },
{ name: 'Adam', age: 47 }, { name: 'Robert', age: 72 }
];
console.log(R.pluck('age', users));
console.log(R.pluck('name', users));
let senAges = R.filter(e => e >= 70, R.pluck('age', users));
console.log(senAges);
console.log(`There are ${senAges.length} senior users`);
console.log(users.map((user) => (user.age)))
console.log(users.map((user) => (user.name)))
console.log(users.filter((user) => (user.age >= 70)))
Co ještě umí Ramda? Pokud možno zkus najít něco, co Javascript nativně neumí.
-
Co ještě umí Ramda? Pokud možno zkus najít něco, co Javascript nativně neumí.
Ramda je veľmi prepracovaná, tam je toho veľa. Natívne sa dá spraviť všetko, akurát to nemusí byť také elegantné a krátke.
Funkcia compose, pipe:
let val = R.compose(Math.abs, R.add(1), R.multiply(2))(-4)
console.log(val);
var f = R.pipe(Math.pow, R.negate, R.inc);
console.log(f(3, 4));
Funkcia range:
const R = require('ramda');
console.log(R.range(1, 10));
console.log(R.sum(R.range(2, 8)));
Partition:
const R = require('ramda');
let nums = [4, -5, 3, 2, -1, 7, -6, 8, 9];
let [ neg, pos ] = R.partition(e => e < 0, nums);
console.log(neg);
console.log(pos);
Pokročilé spracovanie dát pomocou where:
const R = require('ramda');
const moment = require('moment');
const users = [
{ name: 'John', city: 'London', born: '2001-04-01' },
{ name: 'Lenny', city: 'New York', born: '1997-12-11' },
{ name: 'Andrew', city: 'Boston', born: '1987-02-22' },
{ name: 'Peter', city: 'Prague', born: '1936-03-24' },
{ name: 'Anna', city: 'Bratislava', born: '1973-18-11' },
{ name: 'Albert', city: 'Bratislava', born: '1940-12-19' },
{ name: 'Adam', city: 'Trnava', born: '1983-12-01' },
{ name: 'Robert', city: 'Bratislava', born: '1935-05-15' },
{ name: 'Robert', city: 'Prague', born: '1998-03-14' }
];
let res1 = R.filter(R.where({ city: R.equals('Bratislava') }))(users);
console.log(res1);
let res2 = R.filter(R.where({
city: R.equals('Bratislava'),
name: R.startsWith('A')
}))(users);
console.log(res2);
let res3 = R.filter(R.where({
born: (dt) => getAge(dt) > 40}))(users);
console.log(res3);
function getAge(dt) {
return moment.duration(moment() - moment(dt, 'YYYY-MM-DD', true)).years();
}
-
Ramda je veľmi prepracovaná, tam je toho veľa. Natívne sa dá spraviť všetko, akurát to nemusí byť také elegantné a krátke.
Kdybys uvedl i očekávaný výstup, jistě bych ti místo toho napsal nativní zápis v Javascriptu, který bude kratší a přehlednější. Zkusím odhadnout, co Ramda dělá:
// console.log(R.compose(Math.abs, R.add(1), R.multiply(2))(-4));
console.log(Math.abs(-4*2+1))
// var f = R.pipe(Math.pow, R.negate, R.inc);
// console.log(f(3, 4));
var f = (a, b) => -(a^b)+1
console.log(f(3, 4));
// console.log(R.range(1, 10));
console.log(Array.from({length: 10}, (x,i) => i+1));
// console.log(R.sum(R.range(2, 8)));
console.log(Array.from({length: 7}, (x,i) => i+2).reduce((a, b) => a+b));
let nums = [4, -5, 3, 2, -1, 7, -6, 8, 9];
// let [ neg, pos ] = R.partition(e => e < 0, nums);
let neg = nums.filter(e => e<0);
let neg = nums.filter(e => e>=0);
To poslední se mi dělat nechce, ale bude to něco podobného.
No dobrá, poslední tři mám o něco delší, ale stejně jsi mě nepřesvědčil o užitečnosti Ramdy.
-
Typicky tohle
[1,2,3,15,30,7,5,45,60].sort();
// = [1,15,2,3,30,45,5,60,7]
je volant (řidítka, knipl, cokoliv), co otáčí dopravní prostředek na druhou stranu, než je přirozené a než všichni očekávají.
Když na to narazíš poprvé, zjistíš si, že pro čísla je správná syntaxe např:
[1,2,3,15,30,7,5,45,60].sort((a, b) => (a - b));
a příště už to neřešíš a jen používáš.
Já bych to uzavřel - kdo vidí JS poprvé (asi většina z přítomných), toho spousta věcí překvapí, kdo v něm pracuje pravidelně, tak automaticky píše syntaxi tak, aby to fungovalo správně.
To je pěkný bullshit. Javascript používám, od časů Netscape a IE 4.0, tedy od jeho počátku. Znám většinu jeho temných zákoutí i jeho historický vývoj. Už v roce 2002, tedy ještě před ajaxem, jsem s ním pracoval tak, že jsem si posílal do prohlížeče surová data a v js z nich generoval stránky, implementoval jsem v té době i interaktivní weby napsané čistě v js. Hodně věcí se mi na js líbí, ale to nic nemění na tom, že je to špatně navržený jazyk, který spoustu svých dětských problémů nedokázal odstranit a který spoustu jednoduchých a základních věcí neumí, nebo je dělá špatně, takže je zbytečně těžkopádý.
-
Je volant (řidítka, knipl, cokoliv), co otáčí dopravní prostředek na druhou stranu, než je přirozené a než všichni očekávají.
Já vás svým způsobem chápu, ale "je to trochu jinak, než jinde a já jsem líný si přečíst dokumentaci" je takový dost slabý argument. To nevztahuju jenom na JavaScript, ale celkově.
To není argument, jsem líný si přečíst dokumentaci, o lenosti nebylo ani slovo. A tím že špatné řešení zdokumentuji z něj dobré neudělám.
-
Na porovnani identity objektu mas operator ===. Na porovnani obsahu objektu mas ==
V JS se objekty porovnávají striktně. Operátor === jenom vynechává konverze. Jak a tak b jsou objekty, proto je úplně jedno, jestli použiješ == nebo ===.
Nemusíš mi vysvětlovat jak to je udělané, já to vím, jen říkám, že je to udělané blbě. Z toho blbého návrhu pak plyne spousta logických nesmyslů, třeba tohle:
'x' == 'x' // true
new String('x') == new String('x') // false
To na co upozorňuji je, že v JS nemá operátor na porovnání dvou stejných hodnot.
-
Na porovnani identity objektu mas operator ===. Na porovnani obsahu objektu mas ==, ale v JS je spatne implementovan. Ale tak hlavne ze porovnava cislo se stringem.
Co mi napíše java nebo c# na (volná syntaxe)?:
var x = new object(bla bla bla);
var y = new object(bla bla bla);
(x == y)
taky false, protože neporovnává obsah, ale zda jde o totožný objekt (stejně jako v JS).
=== to nevylepší, protože k předchozímu jen přidá porovnání typu proměnné (zde object).
Proto java i c# na skutečné porovnání obsahu používá .equals() které JS nemá, ale není problém si ho přidat z nějaké knihovny nebo dopsat (anebo použít to výše uvedené porovnání objektů převedených na JSON stringy) .
Ano, java je zrovna tak těžkopádný jazyk, ale ta je aspoň statická a má alespíň nějaké standardní řešení. Mimochodem i v C je porovnání polí vždy false, ale a) hodí warning, když to programátor zkusí, b) má memcmp().
Mimochodem, víte že v JS se může vyhodnocení změnit z true na false, když k jedné straně přičtete nulu?
-
Jestli to není spíš jako jet na motorce a divit se, že tam nejsou pedály :-)
Typicky tohle
[1,2,3,15,30,7,5,45,60].sort();
// = [1,15,2,3,30,45,5,60,7]
je volant (řidítka, knipl, cokoliv), co otáčí dopravní prostředek na druhou stranu, než je přirozené a než všichni očekávají.
Protože řadí lexikograficky...? Většinou očekávám, že výsledek lexikografického sortu, bude lexikograficky seřazený vstup...
Ano, proto. Že lexikografický sort řadí lexigraficky očekává každý, ale nikdo neočekává, že by default se bude na pole čísel aplikovat lexikografický sort.
-
Ramda je veľmi prepracovaná, tam je toho veľa. Natívne sa dá spraviť všetko, akurát to nemusí byť také elegantné a krátke.
Kdybys uvedl i očekávaný výstup, jistě bych ti místo toho napsal nativní zápis v Javascriptu, který bude kratší a přehlednější. Zkusím odhadnout, co Ramda dělá:
// console.log(R.compose(Math.abs, R.add(1), R.multiply(2))(-4));
console.log(Math.abs(-4*2+1))
// var f = R.pipe(Math.pow, R.negate, R.inc);
// console.log(f(3, 4));
var f = (a, b) => -(a^b)+1
console.log(f(3, 4));
// console.log(R.range(1, 10));
console.log(Array.from({length: 10}, (x,i) => i+1));
// console.log(R.sum(R.range(2, 8)));
console.log(Array.from({length: 7}, (x,i) => i+2).reduce((a, b) => a+b));
let nums = [4, -5, 3, 2, -1, 7, -6, 8, 9];
// let [ neg, pos ] = R.partition(e => e < 0, nums);
let neg = nums.filter(e => e<0);
let neg = nums.filter(e => e>=0);
To poslední se mi dělat nechce, ale bude to něco podobného.
No dobrá, poslední tři mám o něco delší, ale stejně jsi mě nepřesvědčil o užitečnosti Ramdy.
Odhadol si to dobre, akurát tam v druhom príklade bolo treba dať ** operátor.
Ramda má veľa šikovných funkcií a čím zložitejší problém, tým je úspora kódu vyššia.
-
Mimochodem, víte že v JS se může vyhodnocení změnit z true na false, když k jedné straně přičtete nulu?
Ono to má svůj důvod. Že tě to pořád baví, vysmívat se vlastní neznalosti. Ano, není to Java, není to Python a není to céčko. To jsi poznal, za to máš bod.
-
Mimochodem, víte že v JS se může vyhodnocení změnit z true na false, když k jedné straně přičtete nulu?
Ono to má svůj důvod. Že tě to pořád baví, vysmívat se vlastní neznalosti. Ano, není to Java, není to Python a není to céčko. To jsi poznal, za to máš bod.
On to právě ví, takže to není neznalost... jen mu to asi připadá trošku směšné, že se takhle jazyk chová...a že to je dokonce podle specifikace....
-
Mimochodem, víte že v JS se může vyhodnocení změnit z true na false, když k jedné straně přičtete nulu?
Co by podle tebe mělo být správným výsledkem {}+0 ?
Pokud pominu, že je nesmyslné sčítat číslo a objekt, tak JS se s tím vyrovnává převedením obou operandů na string před sečtením místo vyhození chyby (viz dokumentace "The general rule for addition in JavaScript is simple: You can only add numbers and strings, all other values will be converted to either one of those types.").
A {}+0 == {} (což je totéž jako "[object Object]0" == {} ) mi stejně true nevrátí.
-
Když to celé čtu, mám z toho pocit, že uživatelé mají největší problém s tím, že JS dělá v určitých případech automatické konverze typů.
-
Když to celé čtu, mám z toho pocit, že uživatelé mají největší problém s tím, že JS dělá v určitých případech automatické konverze typů.
Což je něco, co se už se hezkých pár let považuje za anti-pattern, s možnou výjimkou int->float konverze...
-
Pan EEE - s tim vsim co tady psa, ma naprostou pravdu, bez vyhrad souhlasim, jako clovek co je vpodstate 100% ziven javascriptem a mam ho rad, tak tyhle chyby tam jsou, a je treba si to priznat.
-
Podle mne nejvetsi problemy JavaScriptu v praxi jsou:
1) V eshopu si chcete koupit vyrobek, ktery ma parametry A, B a C. Ve filtru kliknete na A, roztoci se kolecko, JS zacne drtit a po nekolika desitkach vterin, az vysype stranku s vyrobky s parametrem A, lze zaskrtnout B. Opet kolecko, JS drti desitky vterin, dalsi stranka a konecne lze zaskrtnout C. Nevim, co je tak tezkeho na tom udelat stranku, kde si zakaznik nejprve naklika A, B, C, pak to teprve odesle a dostane vysledek na prvni pokus, ne na treti.
2) 99% JS je reklamni a smirovaci hnuj.
-
Podle mne nejvetsi problemy JavaScriptu v praxi jsou:
1) V eshopu si chcete koupit vyrobek, ktery ma parametry A, B a C. Ve filtru kliknete na A, roztoci se kolecko, JS zacne drtit a po nekolika desitkach vterin, az vysype stranku s vyrobky s parametrem A, lze zaskrtnout B. Opet kolecko, JS drti desitky vterin, dalsi stranka a konecne lze zaskrtnout C. Nevim, co je tak tezkeho na tom udelat stranku, kde si zakaznik nejprve naklika A, B, C, pak to teprve odesle a dostane vysledek na prvni pokus, ne na treti.
Není na tom nic těžkého. A nemůže za to JS, ale debilní vývojáři a ještě debilnější UX "designéři".
-
Podle mne nejvetsi problemy JavaScriptu v praxi jsou:
1) V eshopu si chcete koupit vyrobek, ktery ma parametry A, B a C. Ve filtru kliknete na A, roztoci se kolecko, JS zacne drtit a po nekolika desitkach vterin, az vysype stranku s vyrobky s parametrem A, lze zaskrtnout B. Opet kolecko, JS drti desitky vterin, dalsi stranka a konecne lze zaskrtnout C. Nevim, co je tak tezkeho na tom udelat stranku, kde si zakaznik nejprve naklika A, B, C, pak to teprve odesle a dostane vysledek na prvni pokus, ne na treti.
Není na tom nic těžkého. A nemůže za to JS, ale debilní vývojáři a ještě debilnější UX "designéři".
To jiste, ale pak se nabizi otazka, vzhledem k rozsirenosti tohoto jevu, proc je mezi JS vyvojari a designery tak hrozive % debilu, potazmo odpovedi, ze bud je ten jazyk laka, nebo vyrabi. Nebo kombinace obojiho, ale tak jak tak z toho JS nevychazi dobre.
-
Podle mne nejvetsi problemy JavaScriptu v praxi jsou:
1) V eshopu si chcete koupit vyrobek, ktery ma parametry A, B a C. Ve filtru kliknete na A, roztoci se kolecko, JS zacne drtit a po nekolika desitkach vterin, az vysype stranku s vyrobky s parametrem A, lze zaskrtnout B. Opet kolecko, JS drti desitky vterin, dalsi stranka a konecne lze zaskrtnout C. Nevim, co je tak tezkeho na tom udelat stranku, kde si zakaznik nejprve naklika A, B, C, pak to teprve odesle a dostane vysledek na prvni pokus, ne na treti.
Není na tom nic těžkého. A nemůže za to JS, ale debilní vývojáři a ještě debilnější UX "designéři".
To jiste, ale pak se nabizi otazka, vzhledem k rozsirenosti tohoto jevu, proc je mezi JS vyvojari a designery tak hrozive % debilu, potazmo odpovedi, ze bud je ten jazyk laka, nebo vyrabi. Nebo kombinace obojiho, ale tak jak tak z toho JS nevychazi dobre.
To fakt není jen záležitost JS :). Vemte libovolný mainstream jazyk. Teď jsem školil lidi, co dělají erlang, a po nějaké době jsem měl z toho školení velice dobrý pocit. Nicméně erlang je a byl jazyk z vyšší vstupní bariérou, a ten jazyk dělají srdcaři. JS umožňuje prasit, ale umožňuje také napsat špičkové portabilní aplikace.
-
Není na tom nic těžkého. A nemůže za to JS, ale debilní vývojáři a ještě debilnější UX "designéři".
To jiste, ale pak se nabizi otazka, vzhledem k rozsirenosti tohoto jevu, proc je mezi JS vyvojari a designery tak hrozive % debilu, potazmo odpovedi, ze bud je ten jazyk laka, nebo vyrabi. Nebo kombinace obojiho, ale tak jak tak z toho JS nevychazi dobre.
Javascript vypadá tak jednoduše, že k sobě láká debilní vývojáře společně s kvalitními. Stejný problém je i v PHP. Nízká vstupní bariéra umožní každému začátečníkovi vyrobit první aplikaci za pár minut až hodin. Kvalitní vývojáři se dále rozvíjí, pochopí temná zákoutí těchto jazyků a produkují kvalitní aplikace. Ti hloupí zůstanou začátečníky a generují hromady binárního odpadu.
-
Lol
Tak až mi dáš třeba normální jazyk jako C# místo JS na client side, nebudu si stěžovat na s*ačky tohoto typu.
Ale chápu, že obhajování antipatternu je teď v oblibě a pomlouvat vývojáře jaký to jsou neschopný lopaty je in.
Trochu začněte používat tu věc co máte na hlavě a proberte se proboha...
-
Kladu si otázku, proč je Vlado ve své argumentaci tak agresivní a vulgární? Co se mu stalo? Kdo mu co udělal? Vypadá to, že kromě JS na světě už nic jiného nemá a proto kolem JS vystavil hradbu témat, o kterých se nesmí mluvit je nepříčetný, když někdo něco namítne proti tomu, co ještě zbylo. Asi musí být radost mít takového člověka v týmu.
-
Kladu si otázku, proč je Vlado ve své argumentaci tak agresivní a vulgární? Co se mu stalo? Kdo mu co udělal? Vypadá to, že kromě JS na světě už nic jiného nemá a proto kolem JS vystavil hradbu témat, o kterých se nesmí mluvit je nepříčetný, když někdo něco namítne proti tomu, co ještě zbylo. Asi musí být radost mít takového člověka v týmu.
To su nasledky pouzivania toho jazyka.
-
A podotazka:
To nikomu nevadi ten loknutie jedneho jazyka v browseri?
-
A podotazka:
To nikomu nevadi ten loknutie jedneho jazyka v browseri?
Mně to vadí. Rád bych vedle něj viděl třeba Lisp.
-
A podotazka:
To nikomu nevadi ten loknutie jedneho jazyka v browseri?
To nestačí svetu jeden JavaScript? :)
-
A podotazka:
To nikomu nevadi ten loknutie jedneho jazyka v browseri?
Mně to vadí. Rád bych vedle něj viděl třeba Lisp.
Koukni na clojurescript.
-
A podotazka:
To nikomu nevadi ten loknutie jedneho jazyka v browseri?
MSIE do verze 10 uměl ještě VBScript :)
-
A podotazka:
To nikomu nevadi ten loknutie jedneho jazyka v browseri?
Mně to vadí. Rád bych vedle něj viděl třeba Lisp.
Koukni na clojurescript.
Je to sice trochu kostrbaté řešení, ale možná to stojí za vyzkoušení. Díky za tip.
-
A podotazka:
To nikomu nevadi ten loknutie jedneho jazyka v browseri?
Mně to vadí. Rád bych vedle něj viděl třeba Lisp.
Koukni na clojurescript.
A podotazka:
To nikomu nevadi ten loknutie jedneho jazyka v browseri?
MSIE do verze 10 uměl ještě VBScript :)
V oboch ma tam desi to "script" :D
Ono by to chcelo nieco slobodne, nejaky bytecod. WebAssembly moze byt fajn, ale mam pocit ze vyvojari Googlu ho sabotuju aby bolo node viac cool, alebo neviem pre co. Pri tom by stacilo par features (ako pristup k DOM, HTTP client...) a zavladla by sloboda. Ale to by sa sudruhovia v googli nesmeli spravat horsie ako Microsoft v devediastach rokoch.
-
Mimochodem, víte že v JS se může vyhodnocení změnit z true na false, když k jedné straně přičtete nulu?
Ono to má svůj důvod. Že tě to pořád baví, vysmívat se vlastní neznalosti. Ano, není to Java, není to Python a není to céčko. To jsi poznal, za to máš bod.
Jak jsi přišel na to, že se jedná o mou neznalost? Ja upozorňuji na nedomyšlená rozhodnutí, která jsou následně zdrojem obdivuhodných side efektů.
-
Mimochodem, víte že v JS se může vyhodnocení změnit z true na false, když k jedné straně přičtete nulu?
Co by podle tebe mělo být správným výsledkem {}+0 ?
Výjimka.
-
Mimochodem, víte že v JS se může vyhodnocení změnit z true na false, když k jedné straně přičtete nulu?
Co by podle tebe mělo být správným výsledkem {}+0 ?
Výjimka.
To mě také napadlo. Jenže jak tu už někdo psal, filozofií JS je snaha za každou cenu nepadnout. Zda je to dobře, nebo špatně...
-
Mimochodem, víte že v JS se může vyhodnocení změnit z true na false, když k jedné straně přičtete nulu?
Co by podle tebe mělo být správným výsledkem {}+0 ?
Výjimka.
To mě také napadlo. Jenže jak tu už někdo psal, filozofií JS je snaha za každou cenu nepadnout. Zda je to dobře, nebo špatně...
Špatně.
-
Mimochodem, víte že v JS se může vyhodnocení změnit z true na false, když k jedné straně přičtete nulu?
Co by podle tebe mělo být správným výsledkem {}+0 ?
Výjimka.
To mě také napadlo. Jenže jak tu už někdo psal, filozofií JS je snaha za každou cenu nepadnout. Zda je to dobře, nebo špatně...
I za cenu chybného chování? Řada chyb s tímto navíc nesouvisí. Zkuste si třeba toto:
{} + 0 // = 0
0 + {} // = 0[Object]
{} == {} // invalid javascript
To je prostě nelogický a nesmyslný bordel, nekonzistentní chování, které je korunované tím, že js specifikace připouští na mnoha místech implementační závislost, tudíž v různých prohlížečích může dávat různé výsledky.
-
{} == {} // invalid javascript[/tt]
To je prostě nelogický a nesmyslný bordel, nekonzistentní chování, které je korunované tím, že js specifikace připouští na mnoha místech implementační závislost, tudíž v různých prohlížečích může dávat různé výsledky.
Ano, je to nekonzistentní. V javascript to je validní výraz, ale z nějakého důvodu to není validní jako statement. Stačí uzávorkovat ({}=={}); a je to validní. Naproti tomu výraz 0==0 je validní i jako statement.
-
{} + 0 // = 0
0 + {} // = 0[Object]
To je prostě nelogický a nesmyslný bordel, nekonzistentní chování.
A pritom ti stacilo tak malo, misto plakani a psani tveho nesmyslu stacilo kouknut manual a pochopit ze operator "+" ma dvoji vyznam a javascript pouziva autocast - vsechno veci ktere pochopi bezne inteligentni jedinec. Kdyz ale nedokazes rozlisit state of art od nekonzistentniho chovani tak se vrat k C.
-
{} + 0 // = 0
0 + {} // = 0[Object]
To je prostě nelogický a nesmyslný bordel, nekonzistentní chování.
A pritom ti stacilo tak malo, misto plakani a psani tveho nesmyslu stacilo kouknut manual a pochopit ze operator "+" ma dvoji vyznam a javascript pouziva autocast - vsechno veci ktere pochopi bezne inteligentni jedinec. Kdyz ale nedokazes rozlisit state of art od nekonzistentniho chovani tak se vrat k C.
Ty nejsi kozel, ale vůl. JS je nekonzistentní slepenec s neuvěřitelným množstvím WTF momentů.
-
Kozel má ale pravdu. Nevíte ani, jak v JS fungují operátory, ale řečí máte jak opice. To samé jsem se snažil naznačit panu eee o pár příspěvků výš, ovšem marně. To fakt není céčko.
-
Eee, Scripter či čo si zač, v akomže to jazyku programuješ, že v praxi používaš konštrukcie ako `{} + 0` ?
-
Mimochodem, víte že v JS se může vyhodnocení změnit z true na false, když k jedné straně přičtete nulu?
Co by podle tebe mělo být správným výsledkem {}+0 ?
Výjimka.
To mě také napadlo. Jenže jak tu už někdo psal, filozofií JS je snaha za každou cenu nepadnout. Zda je to dobře, nebo špatně...
I za cenu chybného chování? Řada chyb s tímto navíc nesouvisí. Zkuste si třeba toto:
{} + 0 // = 0
0 + {} // = 0[Object]
{} == {} // invalid javascript
To je prostě nelogický a nesmyslný bordel, nekonzistentní chování, které je korunované tím, že js specifikace připouští na mnoha místech implementační závislost, tudíž v různých prohlížečích může dávat různé výsledky.
Programujem vyhradne v JS uz asi 5 rokov a este sa mi nestalo, ze by mi script daval v roznych prehliadacoch rozne vysledky. Ak nepocitam problemy IE.
Toto moze byt problem Javascript v akademickom svete, ale nie v praxi. A ani v akademickom svete to problem nie je, pretoze si staci precitat manual.
-
{} + 0 // = 0
0 + {} // = 0[Object]
To je prostě nelogický a nesmyslný bordel, nekonzistentní chování.
A pritom ti stacilo tak malo, misto plakani a psani tveho nesmyslu stacilo kouknut manual a pochopit ze operator "+" ma dvoji vyznam a javascript pouziva autocast - vsechno veci ktere pochopi bezne inteligentni jedinec. Kdyz ale nedokazes rozlisit state of art od nekonzistentniho chovani tak se vrat k C.
To nejsou nesmysly, Kozle, to jsou ukázky důsledků špatného návrhu javascriptu. Pochopit to lze, žít se s tám dá, ale dobré, chytré a krásné to není.
-
https://medium.com/javascript-non-grata/the-lie-that-has-beguiled-a-generation-of-developers-1b33e82de94f
-
Kozel má ale pravdu. Nevíte ani, jak v JS fungují operátory, ale řečí máte jak opice. To samé jsem se snažil naznačit panu eee o pár příspěvků výš, ovšem marně. To fakt není céčko.
Jak jsi přišel na to, že nevím jak v JS fungují operátory?
-
{} + 0 // = 0
0 + {} // = 0[Object]
To je prostě nelogický a nesmyslný bordel, nekonzistentní chování.
A pritom ti stacilo tak malo, misto plakani a psani tveho nesmyslu stacilo kouknut manual a pochopit ze operator "+" ma dvoji vyznam a javascript pouziva autocast - vsechno veci ktere pochopi bezne inteligentni jedinec. Kdyz ale nedokazes rozlisit state of art od nekonzistentniho chovani tak se vrat k C.
To nejsou nesmysly, Kozle, to jsou ukázky důsledků špatného návrhu javascriptu. Pochopit to lze, žít se s tám dá, ale dobré, chytré a krásné to není.
Eeeee ... a čo myslíš, prečo to doteraz neopravili. Hm?
-
https://medium.com/javascript-non-grata/the-lie-that-has-beguiled-a-generation-of-developers-1b33e82de94f
Článok od idiota pre idiotov. Preto si ho spomenul? A pozrel si sa aj do komentárov?
-
Eee, Scripter či čo si zač, v akomže to jazyku programuješ, že v praxi používaš konštrukcie ako `{} + 0` ?
Já podle potřeby programuji v C, C#, Python, PHP, JS, Lua a když dojde na nejhorší, tak i Java. Nejradši mám Python, když mám na výběr. Pokud jsi to pochopil tak, že chci používat takové konstrukce, tak jsi nepochopil vůbec nic.
-
{} + 0 // = 0
0 + {} // = 0[Object]
To je prostě nelogický a nesmyslný bordel, nekonzistentní chování.
A pritom ti stacilo tak malo, misto plakani a psani tveho nesmyslu stacilo kouknut manual a pochopit ze operator "+" ma dvoji vyznam a javascript pouziva autocast - vsechno veci ktere pochopi bezne inteligentni jedinec. Kdyz ale nedokazes rozlisit state of art od nekonzistentniho chovani tak se vrat k C.
To nejsou nesmysly, Kozle, to jsou ukázky důsledků špatného návrhu javascriptu. Pochopit to lze, žít se s tám dá, ale dobré, chytré a krásné to není.
Eeeee ... a čo myslíš, prečo to doteraz neopravili. Hm?
Kdo ví, ale o tom tahle diskuse není, ta je o špatných vlastnostech JS, nikoliv jejich příčinách. Zdá se, že spousta lidí si odmítá připustit, že JS není dobře navržený jazyk. A na mysl se mi vkrádá kacířská myšlenka, že se jedná o lidi, kteří ho v praxi příliš nepoužívají a nebo nic jiného neznají.
-
Zdá se, že spousta lidí si odmítá připustit, že JS není dobře navržený jazyk. A na mysl se mi vkrádá kacířská myšlenka, že se jedná o lidi, kteří ... nic jiného neznají.
Když se celej život koupeš v hovnech, vypěstuješ si imunitu... ;D
-
Eee, Scripter či čo si zač, v akomže to jazyku programuješ, že v praxi používaš konštrukcie ako `{} + 0` ?
Já podle potřeby programuji v C, C#, Python, PHP, JS, Lua a když dojde na nejhorší, tak i Java. Nejradši mám Python, když mám na výběr. Pokud jsi to pochopil tak, že chci používat takové konstrukce, tak jsi nepochopil vůbec nic.
Ok, ospravedlňujem sa. Stačí, že ty si pochopil všetko a do vlákna s názvom praktické problémy s JS si pridal svoj nesmierne prínosný postreh z tvojej praxe, že v dynamicky typovanom jazyku ťa pletie implicit coercion vďaka ktorej ťa interpret neupozorní, že objekt plus číslo nevyhodí výnimku. Mňa, ani nikoho kto má prax s dynamicky a nie len staticky typovanými jazykmi to neprekvapí, vie, že na implicit coercion si treba dať pozor a nie spoliehať na ňu, a to v KTOROMKOĽVEK JAZYKU, ale tak ... ty si iný. V poriadku, vyplač sa tu. Za mňa však tvoje príspevky čistý offtopic a nie k téme, k otázke. Páčko.
-
Zdá se, že spousta lidí si odmítá připustit, že JS není dobře navržený jazyk. A na mysl se mi vkrádá kacířská myšlenka, že se jedná o lidi, kteří ... nic jiného neznají.
Když se celej život koupeš v hovnech, vypěstuješ si imunitu... ;D
Ty si zjavne kapitola sám o sebe :D Ešte raz k tomu článku čo si sem vygrcal: hneď začína nezmyslom, ako sú SPA apky s modernými f-e frameworkami zložitejšie, ako klasické, server side rendered MVC apky :D Ten kokot zjavne zamrzol v roku 2000 :D S tými frameworkami sa web app píšu zrovna rýchlejšie, aj prehľadnejšie, čiže udržiavate ľahšie. Čo je dôvod prečo sa Spring prerába z MVC na reaktívny framework, či dôvod prečo nový Vaadin je založený na web komponentoch. Lopaty ako ty, neschopné udržať krok s dobou a kompenzujúce si to aspoň hejtom na fórach, nemajú v dnešnej dobe miesto. Zalez do kúta a tam si tíško ďalej píš v Pascale svoje hypermoderné apky, ale tu sa prestaň vyjadrovať ;)
-
Ok, ospravedlňujem sa. Stačí, že ty si pochopil všetko a do vlákna s názvom praktické problémy s JS si pridal svoj nesmierne prínosný postreh z tvojej praxe, že v dynamicky typovanom jazyku ťa pletie implicit coercion vďaka ktorej ťa interpret neupozorní, že objekt plus číslo nevyhodí výnimku. Mňa, ani nikoho kto má prax s dynamicky a nie len staticky typovanými jazykmi to neprekvapí, vie, že na implicit coercion si treba dať pozor a nie spoliehať na ňu, a to v KTOROMKOĽVEK JAZYKU, ale tak ... ty si iný. V poriadku, vyplač sa tu. Za mňa však tvoje príspevky čistý offtopic a nie k téme, k otázke. Páčko.
Myslím, že většinu diskutujících to nepřekvapuje a dokonce o tom ví, proto to sem dávají jako příklady problémů JS. Jen se tím pokouší ukázat na špatný návrh jazyka a může to být ve specifikaci a dokumentaci klidně zlatým písmem, ale historická koule na noze to zůstane a dobrý nápad se z toho nestane. Ostatně, třeba Python je taky dynamický a takovéhle prasárny v něm nejdou, tam se naopak razí cesta "Explicit is better than implicit.".
-
Ok, ospravedlňujem sa. Stačí, že ty si pochopil všetko a do vlákna s názvom praktické problémy s JS si pridal svoj nesmierne prínosný postreh z tvojej praxe, že v dynamicky typovanom jazyku ťa pletie implicit coercion vďaka ktorej ťa interpret neupozorní, že objekt plus číslo nevyhodí výnimku. Mňa, ani nikoho kto má prax s dynamicky a nie len staticky typovanými jazykmi to neprekvapí, vie, že na implicit coercion si treba dať pozor a nie spoliehať na ňu, a to v KTOROMKOĽVEK JAZYKU, ale tak ... ty si iný. V poriadku, vyplač sa tu. Za mňa však tvoje príspevky čistý offtopic a nie k téme, k otázke. Páčko.
Myslím, že většinu diskutujících to nepřekvapuje a dokonce o tom ví, proto to sem dávají jako příklady problémů JS. Jen se tím pokouší ukázat na špatný návrh jazyka a může to být ve specifikaci a dokumentaci klidně zlatým písmem, ale historická koule na noze to zůstane a dobrý nápad se z toho nestane. Ostatně, třeba Python je taky dynamický a takovéhle prasárny v něm nejdou, tam se naopak razí cesta "Explicit is better than implicit.".
A si tú historickú guľu na nohe ťahá doteraz, miesto toho aby to opravili? Hm?
-
Zdá se, že spousta lidí si odmítá připustit, že JS není dobře navržený jazyk. A na mysl se mi vkrádá kacířská myšlenka, že se jedná o lidi, kteří ho v praxi příliš nepoužívají a nebo nic jiného neznají.
Ja JS/CS/TS delam uz snad dekadu, vim o nem snad vsechno a prekvapoval mne asi tak prvni rok jako kazdy jiny jazyk. Je navrzen uplne skvele, akorat naucit se ho poradne trva trochu dele nez u jazyku co pindaji na kde co a neumeji delit nulou :)
Kdyz uz chcete plamennou valku na spatne navrzeny jazyk tak vam poradim treba Perl. Ten vam pripravi tolik dafuq momentu, ze JS zacnete milovat vecnou a nehybouci laskou..
-
Zdá se, že spousta lidí si odmítá připustit, že JS není dobře navržený jazyk. A na mysl se mi vkrádá kacířská myšlenka, že se jedná o lidi, kteří ho v praxi příliš nepoužívají a nebo nic jiného neznají.
Ja JS/CS/TS delam uz snad dekadu, vim o nem snad vsechno a prekvapoval mne asi tak prvni rok jako kazdy jiny jazyk. Je navrzen uplne skvele, akorat naucit se ho poradne trva trochu dele nez u jazyku co pindaji na kde co a neumeji delit nulou :)
Kdyz uz chcete plamennou valku na spatne navrzeny jazyk tak vam poradim treba Perl. Ten vam pripravi tolik dafuq momentu, ze JS zacnete milovat vecnou a nehybouci laskou..
Preeesne taaak... Moderný JS je skvelý a má krásny syntax. Preto aj ja prispejem článkom, z opačného súdka: https://blog.sourcerer.io/why-is-a-java-guy-so-excited-about-node-js-and-javascript-7cfc423efb44 (https://blog.sourcerer.io/why-is-a-java-guy-so-excited-about-node-js-and-javascript-7cfc423efb44)
-
Zdá se, že spousta lidí si odmítá připustit, že JS není dobře navržený jazyk. A na mysl se mi vkrádá kacířská myšlenka, že se jedná o lidi, kteří ... nic jiného neznají.
Když se celej život koupeš v hovnech, vypěstuješ si imunitu... ;D
Ty si zjavne kapitola sám o sebe :D Ešte raz k tomu článku čo si sem vygrcal: hneď začína nezmyslom, ako sú SPA apky s modernými f-e frameworkami zložitejšie, ako klasické, server side rendered MVC apky :D Ten kokot zjavne zamrzol v roku 2000 :D S tými frameworkami sa web app píšu zrovna rýchlejšie, aj prehľadnejšie, čiže udržiavate ľahšie. Čo je dôvod prečo sa Spring prerába z MVC na reaktívny framework, či dôvod prečo nový Vaadin je založený na web komponentoch. Lopaty ako ty, neschopné udržať krok s dobou a kompenzujúce si to aspoň hejtom na fórach, nemajú v dnešnej dobe miesto. Zalez do kúta a tam si tíško ďalej píš v Pascale svoje hypermoderné apky, ale tu sa prestaň vyjadrovať ;)
Chlapi bacha na to, toto je maskovany Vlado. Styl jazyka a reci uplne rovnaky ako nas Vladko, ktory sa to strapnil az pod ciernu zem.
-
Chlapi bacha na to, toto je maskovany Vlado. Styl jazyka a reci uplne rovnaky ako nas Vladko, ktory sa to strapnil az pod ciernu zem.
No zrovna tady ma pravdu a tomu trolovi Phirae nalozil poradne :)
-
{} + 0 // = 0
0 + {} // = 0[Object]
To je prostě nelogický a nesmyslný bordel, nekonzistentní chování.
A pritom ti stacilo tak malo, misto plakani a psani tveho nesmyslu stacilo kouknut manual a pochopit ze operator "+" ma dvoji vyznam a javascript pouziva autocast - vsechno veci ktere pochopi bezne inteligentni jedinec. Kdyz ale nedokazes rozlisit state of art od nekonzistentniho chovani tak se vrat k C.
To nejsou nesmysly, Kozle, to jsou ukázky důsledků špatného návrhu javascriptu. Pochopit to lze, žít se s tám dá, ale dobré, chytré a krásné to není.
Eeeee ... a čo myslíš, prečo to doteraz neopravili. Hm?
Kdo ví, ale o tom tahle diskuse není, ta je o špatných vlastnostech JS, nikoliv jejich příčinách. Zdá se, že spousta lidí si odmítá připustit, že JS není dobře navržený jazyk. A na mysl se mi vkrádá kacířská myšlenka, že se jedná o lidi, kteří ho v praxi příliš nepoužívají a nebo nic jiného neznají.
Neznají dobře ani ten svůj javascript.
-
Zdá se, že spousta lidí si odmítá připustit, že JS není dobře navržený jazyk. A na mysl se mi vkrádá kacířská myšlenka, že se jedná o lidi, kteří ho v praxi příliš nepoužívají a nebo nic jiného neznají.
Ja JS/CS/TS delam uz snad dekadu, vim o nem snad vsechno a prekvapoval mne asi tak prvni rok jako kazdy jiny jazyk. Je navrzen uplne skvele, akorat naucit se ho poradne trva trochu dele nez u jazyku co pindaji na kde co a neumeji delit nulou :)
Kdyz uz chcete plamennou valku na spatne navrzeny jazyk tak vam poradim treba Perl. Ten vam pripravi tolik dafuq momentu, ze JS zacnete milovat vecnou a nehybouci laskou..
Preeesne taaak... Moderný JS je skvelý a má krásny syntax. Preto aj ja prispejem článkom, z opačného súdka: https://blog.sourcerer.io/why-is-a-java-guy-so-excited-about-node-js-and-javascript-7cfc423efb44 (https://blog.sourcerer.io/why-is-a-java-guy-so-excited-about-node-js-and-javascript-7cfc423efb44)
Syntax je ženského rodu (aj v hornouhorčine ;)). “Ten syntax” je stejně debilní jako “ten monád” (i to se tu člověk bohužel dočte). Jinak teda syntax JS je příšerně nelogická a zmatečná.
-
Zdá se, že spousta lidí si odmítá připustit, že JS není dobře navržený jazyk. A na mysl se mi vkrádá kacířská myšlenka, že se jedná o lidi, kteří ho v praxi příliš nepoužívají a nebo nic jiného neznají.
Ja JS/CS/TS delam uz snad dekadu, vim o nem snad vsechno a prekvapoval mne asi tak prvni rok jako kazdy jiny jazyk. Je navrzen uplne skvele, akorat naucit se ho poradne trva trochu dele nez u jazyku co pindaji na kde co a neumeji delit nulou :)
Kdyz uz chcete plamennou valku na spatne navrzeny jazyk tak vam poradim treba Perl. Ten vam pripravi tolik dafuq momentu, ze JS zacnete milovat vecnou a nehybouci laskou..
Preeesne taaak... Moderný JS je skvelý a má krásny syntax. Preto aj ja prispejem článkom, z opačného súdka: https://blog.sourcerer.io/why-is-a-java-guy-so-excited-about-node-js-and-javascript-7cfc423efb44 (https://blog.sourcerer.io/why-is-a-java-guy-so-excited-about-node-js-and-javascript-7cfc423efb44)
Syntax je ženského rodu (aj v hornouhorčine ;)). “Ten syntax” je stejně debilní jako “ten monád” (i to se tu člověk bohužel dočte). Jinak teda syntax JS je příšerně nelogická a zmatečná.
Jop, ženského rodu, ospravedlňujem sa. Ale môžeš mi do code bloku nakopírovať príklad s nelogickým a zmätočným kódom? Ergo, môžem ťa poprosiť o objektívny argument miesto subjektívneho dojmu? Ďakujem.
-
Je navrzen uplne skvele, akorat naucit se ho poradne trva trochu dele nez u jazyku co pindaji na kde co a neumeji delit nulou :)
No úplně skvěle bych to asi nenazýval, ale ano, je to dobrý jazyk, který se i přes C-like syntax velmi liší. Mám ho rád.
Kdyz uz chcete plamennou valku na spatne navrzeny jazyk tak vam poradim treba Perl. Ten vam pripravi tolik dafuq momentu, ze JS zacnete milovat vecnou a nehybouci laskou..
To by nebylo fér. V Perlu je velmi, velmi, velmi důležitý kontext, který, když ho člověk chápe, vysvětluje 99% wtf věcí. Ale ano, zvlášť pro člověka, co už programoval v něčem jiném, to bude občas dost wtf. :)
-
Eee, Scripter či čo si zač, v akomže to jazyku programuješ, že v praxi používaš konštrukcie ako `{} + 0` ?
Já podle potřeby programuji v C, C#, Python, PHP, JS, Lua a když dojde na nejhorší, tak i Java. Nejradši mám Python, když mám na výběr. Pokud jsi to pochopil tak, že chci používat takové konstrukce, tak jsi nepochopil vůbec nic.
Ok, ospravedlňujem sa. Stačí, že ty si pochopil všetko a do vlákna s názvom praktické problémy s JS si pridal svoj nesmierne prínosný postreh z tvojej praxe, že v dynamicky typovanom jazyku ťa pletie implicit coercion vďaka ktorej ťa interpret neupozorní, že objekt plus číslo nevyhodí výnimku. Mňa, ani nikoho kto má prax s dynamicky a nie len staticky typovanými jazykmi to neprekvapí, vie, že na implicit coercion si treba dať pozor a nie spoliehať na ňu, a to v KTOROMKOĽVEK JAZYKU, ale tak ... ty si iný. V poriadku, vyplač sa tu. Za mňa však tvoje príspevky čistý offtopic a nie k téme, k otázke. Páčko.
To ale nesouvisi s tim, ze ten jazyk je dynamicky, ale s tim, ze je spatne navrzeny. PHP je take dynamácky, take v jinych ohledech spatne navrzeny a problemy JS nema. Nejlepe to imho resi Python, ktery je take dynamicky a ve kterem je take vsechno objekt.
-
Kdyz uz chcete plamennou valku na spatne navrzeny jazyk tak vam poradim treba Perl. Ten vam pripravi tolik dafuq momentu, ze JS zacnete milovat vecnou a nehybouci laskou..
<ironie>To říkají jen ti, co si nepřečetli nebo nepochopili jeho dokumentaci!</ironie>
-
Kdyz uz chcete plamennou valku na spatne navrzeny jazyk tak vam poradim treba Perl. Ten vam pripravi tolik dafuq momentu, ze JS zacnete milovat vecnou a nehybouci laskou..
<ironie>To říkají jen ti, co si nepřečetli nebo nepochopili jeho dokumentaci!</ironie>
Argumentovat věcně je moc mentálně náročné, viď? Překrucovat je očividně snazší :)
-
Kdyz uz chcete plamennou valku na spatne navrzeny jazyk tak vam poradim treba Perl. Ten vam pripravi tolik dafuq momentu, ze JS zacnete milovat vecnou a nehybouci laskou..
<ironie>To říkají jen ti, co si nepřečetli nebo nepochopili jeho dokumentaci!</ironie>
Argumentovat věcně je moc mentálně náročné, viď? Překrucovat je očividně snazší :)
To je parodie na uplne stejnou obhajobu prasaren v JS. Dotycni to ale na rozdil ode mne mysleli vazne :-).
-
Mimochodem, víte že v JS se může vyhodnocení změnit z true na false, když k jedné straně přičtete nulu?
Co by podle tebe mělo být správným výsledkem {}+0 ?
Výjimka.
To mě také napadlo. Jenže jak tu už někdo psal, filozofií JS je snaha za každou cenu nepadnout. Zda je to dobře, nebo špatně...
Špatně.
Ne, že bych s tím obecně nesouhlasil. Ale co se má stát když:
1 + "1"? Taky výjimka?
A při:
var weight = 10
var size = 10
weight + size
? I zde výjimka?
-
Ne, že bych s tím obecně nesouhlasil. Ale co se má stát když:
1 + "1"? Taky výjimka?
ano, zde vyjimka ScitaniJablekHrusekException
A při:
var weight = 10
var size = 10
weight + size
? I zde výjimka?
tady nevidím problém.
-
A při:
var weight = 10
var size = 10
weight + size
? I zde výjimka?
tady nevidím problém.
[/quote]
Nevidíš problém? Sčítáš váhu s výškou. To ti přijde v pořádku?
-
Kdyz uz chcete plamennou valku na spatne navrzeny jazyk tak vam poradim treba Perl. Ten vam pripravi tolik dafuq momentu, ze JS zacnete milovat vecnou a nehybouci laskou..
<ironie>To říkají jen ti, co si nepřečetli nebo nepochopili jeho dokumentaci!</ironie>
Argumentovat věcně je moc mentálně náročné, viď? Překrucovat je očividně snazší :)
To je parodie na uplne stejnou obhajobu prasaren v JS. Dotycni to ale na rozdil ode mne mysleli vazne :-).
PHP si si vybral za príklad dobre navrhnutého jazyka? Ktorému najviac vyčítali nekonzistentnú syntax? Ktorý mal chyby typu, že AND a && malo rozdielnu prioritu vo vyhodnocovaní poradia operátorov? Srandista :) A pripomínam, že si stále neuviedol code snippet s tým nelogickým kódom a zmätočným kódom ;)
-
A při:
var weight = 10
var size = 10
weight + size
? I zde výjimka?
tady nevidím problém.
Nevidíš problém? Sčítáš váhu s výškou. To ti přijde v pořádku?
[/quote]
To se hluboce pletes, scitas dve cisla stejneho typu. Az budes mit var weight = Weight(10) a var size = Size(10), pak to teprve nebude v poradku.
-
Kdyz uz chcete plamennou valku na spatne navrzeny jazyk tak vam poradim treba Perl. Ten vam pripravi tolik dafuq momentu, ze JS zacnete milovat vecnou a nehybouci laskou..
<ironie>To říkají jen ti, co si nepřečetli nebo nepochopili jeho dokumentaci!</ironie>
Argumentovat věcně je moc mentálně náročné, viď? Překrucovat je očividně snazší :)
To je parodie na uplne stejnou obhajobu prasaren v JS. Dotycni to ale na rozdil ode mne mysleli vazne :-).
PHP si si vybral za príklad dobre navrhnutého jazyka? Ktorému najviac vyčítali nekonzistentnú syntax? Ktorý mal chyby typu, že AND a && malo rozdielnu prioritu vo vyhodnocovaní poradia operátorov? Srandista :) A pripomínam, že si stále neuviedol code snippet s tým nelogickým kódom a zmätočným kódom ;)
Nevybral, neco jsi spatne pochopil. Existence dvou ruznych operatoru pro stejnou vec by mela vest k zamysleni duvodu jejich existence, a je to prave rozdilna priorita, to je to nejmensi, co bych php vycital.
-
A při:
var weight = 10
var size = 10
weight + size
? I zde výjimka?
tady nevidím problém.
Nevidíš problém? Sčítáš váhu s výškou. To ti přijde v pořádku?
To se hluboce pletes, scitas dve cisla stejneho typu. Az budes mit var weight = Weight(10) a var size = Size(10), pak to teprve nebude v poradku.
[/quote]
Nepletu. Nesmíš se dívat tak povrchně.
Vytvoříme tedy objekty na váhu a výšku, tak:
var weight = new Weight(8)
var size = new Size(9)
weight + size
tak mi to vyhodilo:
[object Object][object Object] což je úsměvné.
Když přidám metodu:
Weight.prototype.sum = function(x) {this.val += x.val} protože přetěžování operátorů asi nejde (minimálně o tom nevím).
Tak to opět nevyhazuje výjimku (pochopitelně).
Tím neobhajuju rozhodnutí autorů. Já bych taky 1 + "1" netoleroval. Jenže já jsem příznivcem typování. A javascript ho nemá. (Pomocí x instaceof Weight si sice můžu ověřit, co mi tam leze, ale musím to dělat ručně. To je jakoby ho neměl.)
-
A při:
var weight = 10
var size = 10
weight + size
? I zde výjimka?
tady nevidím problém.
Nevidíš problém? Sčítáš váhu s výškou. To ti přijde v pořádku?
[/quote] Výška by byla height. Nicméně kdybys to chtěl takto kontrolovat, tak je ten kód špatně, musel bys mít zvlášť typy pro výšku a pro váhu, nebo aspoň kontrolu přes fyzikální dimenze. Některé jazyky mají typové aliasy bez implicitní coercion.
-
Nevybral, neco jsi spatne pochopil. Existence dvou ruznych operatoru pro stejnou vec by mela vest k zamysleni duvodu jejich existence, a je to prave rozdilna priorita, to je to nejmensi, co bych php vycital.
Nad ničím sa tam netreba zamýšľať. Bola to zjavná chyba, preto to aj časom opravili. Ale ... viac ma zaujíma onen zmätočný kód :) Obzvlášť, keď viem, že hodne nových PHP frameworkov sa inšpirovalo syntaxe JS, konkrétne Express frameworkom z Node. Takže, čo ten príklad onoho zmätku? Neustále totiž len odbočuješ od témy, ešte aj to nesprávnymi argumentami. Čiže? Čakám... :)
-
A při:
var weight = 10
var size = 10
weight + size
? I zde výjimka?
tady nevidím problém.
Nevidíš problém? Sčítáš váhu s výškou. To ti přijde v pořádku?
To se hluboce pletes, scitas dve cisla stejneho typu. Az budes mit var weight = Weight(10) a var size = Size(10), pak to teprve nebude v poradku.
Nepletu. Nesmíš se dívat tak povrchně.
Vytvoříme tedy objekty na váhu a výšku, tak:
var weight = new Weight(8)
var size = new Size(9)
weight + size
tak mi to vyhodilo:
[object Object][object Object] což je úsměvné.
Když přidám metodu:
Weight.prototype.sum = function(x) {this.val += x.val} protože přetěžování operátorů asi nejde (minimálně o tom nevím).
Tak to opět nevyhazuje výjimku (pochopitelně).
Tím neobhajuju rozhodnutí autorů. Já bych taky 1 + "1" netoleroval. Jenže já jsem příznivcem typování. A javascript ho nemá. (Pomocí x instaceof Weight si sice můžu ověřit, co mi tam leze, ale musím to dělat ručně. To je jakoby ho neměl.)
Pleteš, název identifikátoru pro jazyk nic neznamená, pokud se nejedná o nějakou speciální pojmenovávací konvenci, třeba název funkce main v jazyce C. Na základě názvu proměnných proto jazyk nemůže vědět, zda jejich matematické operace jsou v pořádku nebo nikoliv a to ani kdyby jim sémanticky rozuměl, protože někdy to může být chyba a někdy ne, třeba při počítání BMI kde se počítá s výškou i váhou. Co je tedy správné musí říct programátor a to nikoliv názvem proměnné, ale příslušným typem. Správný defenzivní přístup jazyka je, že když programátor nestanoví co a jak, tak jazyk operaci odmítne provést. Třeba v pythonu:
>>> class Size(object):
... def __init__(self, number):
... self.number = number
...
>>> class Weight(object):
... def __init__(self, number):
... self.number = number
...
>>> s = Size(10)
>>> w = Weight(10)
>>> s + w
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
TypeError: unsupported operand type(s) for +: 'Size' and 'Weight'
>>>
To co dělá JS není úsměvné, ale hloupé.
-
Nevybral, neco jsi spatne pochopil. Existence dvou ruznych operatoru pro stejnou vec by mela vest k zamysleni duvodu jejich existence, a je to prave rozdilna priorita, to je to nejmensi, co bych php vycital.
Nad ničím sa tam netreba zamýšľať. Bola to zjavná chyba, preto to aj časom opravili. Ale ... viac ma zaujíma onen zmätočný kód :) Obzvlášť, keď viem, že hodne nových PHP frameworkov sa inšpirovalo syntaxe JS, konkrétne Express frameworkom z Node. Takže, čo ten príklad onoho zmätku? Neustále totiž len odbočuješ od témy, ešte aj to nesprávnymi argumentami. Čiže? Čakám... :)
Doporučuju ti radši přemýšlet. Chyba to nebyla a funguje to tak stále: http://php.net/manual/en/language.operators.precedence.php
-
Pleteš, název identifikátoru pro jazyk nic neznamená, pokud se nejedná o nějakou speciální pojmenovávací konvenci, třeba název funkce main v jazyce C. Na základě názvu proměnných proto jazyk nemůže vědět, zda jejich matematické operace jsou v pořádku nebo nikoliv a to ani kdyby jim sémanticky rozuměl, protože někdy to může být chyba a někdy ne, třeba při počítání BMI kde se počítá s výškou i váhou. Co je tedy správné musí říct programátor a to nikoliv názvem proměnné, ale příslušným typem. Správný defenzivní přístup jazyka je, že když programátor nestanoví co a jak, tak jazyk operaci odmítne provést. Třeba v pythonu:
>>> class Size(object):
... def __init__(self, number):
... self.number = number
...
>>> class Weight(object):
... def __init__(self, number):
... self.number = number
...
>>> s = Size(10)
>>> w = Weight(10)
>>> s + w
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
TypeError: unsupported operand type(s) for +: 'Size' and 'Weight'
>>>
To co dělá JS není úsměvné, ale hloupé.
Těší mne, že si dáváš tak záležet, aby si pochopil co píšu.
Btw: Python je jen o chlup lepší Javascript. Tím nepřesvědčíš.
-
Pleteš, název identifikátoru pro jazyk nic neznamená, pokud se nejedná o nějakou speciální pojmenovávací konvenci, třeba název funkce main v jazyce C. Na základě názvu proměnných proto jazyk nemůže vědět, zda jejich matematické operace jsou v pořádku nebo nikoliv a to ani kdyby jim sémanticky rozuměl, protože někdy to může být chyba a někdy ne, třeba při počítání BMI kde se počítá s výškou i váhou. Co je tedy správné musí říct programátor a to nikoliv názvem proměnné, ale příslušným typem. Správný defenzivní přístup jazyka je, že když programátor nestanoví co a jak, tak jazyk operaci odmítne provést. Třeba v pythonu:
>>> class Size(object):
... def __init__(self, number):
... self.number = number
...
>>> class Weight(object):
... def __init__(self, number):
... self.number = number
...
>>> s = Size(10)
>>> w = Weight(10)
>>> s + w
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
TypeError: unsupported operand type(s) for +: 'Size' and 'Weight'
>>>
To co dělá JS není úsměvné, ale hloupé.
Těší mne, že si dáváš tak záležet, aby si pochopil co píšu.
Btw: Python je jen o chlup lepší Javascript. Tím nepřesvědčíš.
Python je o notny kus lepší než JS, každý se nacházi na opačném konci spektra. Python má jeden z nejepších návrhů (a platí za to už třetí nekompatibální verzí), kdežto javascript má jedn z znejhorších návrhů. O chlup lepší návrh má PHP, a v obou případech je to bída.
-
Python je o notny kus lepší než JS, každý se nacházi na opačném konci spektra. Python má jeden z nejepších návrhů (a platí za to už třetí nekompatibální verzí), kdežto javascript má jedn z znejhorších návrhů.
Tak když to říkáš :-)
-
@eee Na něco takového se reaguje opravdu těžce... bolelo to moc? :)
-
Python je o notny kus lepší než JS, každý se nacházi na opačném konci spektra. Python má jeden z nejepších návrhů (a platí za to už třetí nekompatibální verzí), kdežto javascript má jedn z znejhorších návrhů.
Tak když to říkáš :-)
Python by nebyl tak špatný, kdyby byl staticky typovaný.
-
Jsou důležitější věci než jazyk použitý k vytvoření programu. :)
Třeba vymyslet správné funkční algoritmy, vhodnou datovou strukturu a životní cyklus objektů.
Pokud budete mít možnost si jazyk vybrat, použijete takový, ve kterém se vám dobře a rychle pracuje.
Pokud tu možnost mít nebudete, uděláte to v tom, co je požadováno nebo k dispozici.
JS na backend nikomu vnucovat nechci, ani já sám bych si ho tam nevybral (ale akceptoval bych, když by ho použil tvůrce projektu, který bych následně upravoval - už se mi stalo). Po zkušenostech s PHP preferuju staticky typované jazyky, ale na webovém frontendu na výběr není, takže v něm budu psát vesele dál, obcházet jeho nedostatky a využívat jeho výhody (třeba to jednoduché vytváření a rozšiřování objektů). :)
-
Python by nebyl tak špatný, kdyby byl staticky typovaný.
S tím bych mohl souhlasit. Ale ty novosti, co přišli s verzí 3.4 vypadají dobře.
Problém je v tom, že je to hodně o povaze. Někomu prostě styl, jako má Python nebo Javascript vyhovuje. A ostatně proč taky ne.
Mně to třeba nevyhovuje vůbec. Pokud chci takovou dynamickou opičárnu, tak šáhnu po jazyku Lua. Je snad po všech stránkách (IMHO) lepší. Krom rozšířenosti. Jinak bez statického typování trpím. Ale jak říkám, je to o povaze. Těžko objektivně soudit.
-
Python je o notny kus lepší než JS, každý se nacházi na opačném konci spektra. Python má jeden z nejepších návrhů (a platí za to už třetí nekompatibální verzí), kdežto javascript má jedn z znejhorších návrhů.
Tak když to říkáš :-)
Python by nebyl tak špatný, kdyby byl staticky typovaný.
Tohle je na úrovni tvrzení, že všechny dynamicky typované jazyky jsou špatné z důvodu dynamického typování. A to je nesmysl. Zrovna tak je nesmysl odsoudit všechny slabě typované jazyky, kam patří i Javascript, za to, že mají slabé typy. Ale ty slabé typy se dají implementovat dobře a nebo špatně a JS je má implementované špatně. PHP má také slabé typy a implementuje je mnohem lépe než JS, ale zase má jiné problémy, řakže nechci, aby to vyznělo tak, žebho dávám za vzor dobrého jazyka. Ani Python není bez chyb a na všem se dá něco vyšťourat, ale imho z rozšířených a hodně používaných jazyků je nejhorší JS, který těží z toho, že má monopooni postavení ve webových prohlížečích. Všude jinde, kde má konkurenci, má marginální postavení.
-
Jsou důležitější věci než jazyk použitý k vytvoření programu. :)
Třeba vymyslet správné funkční algoritmy, vhodnou datovou strukturu a životní cyklus objektů.
Pokud budete mít možnost si jazyk vybrat, použijete takový, ve kterém se vám dobře a rychle pracuje.
Pokud tu možnost mít nebudete, uděláte to v tom, co je požadováno nebo k dispozici.
JS na backend nikomu vnucovat nechci, ani já sám bych si ho tam nevybral (ale akceptoval bych, když by ho použil tvůrce projektu, který bych následně upravoval - už se mi stalo). Po zkušenostech s PHP preferuju staticky typované jazyky, ale na webovém frontendu na výběr není, takže v něm budu psát vesele dál, obcházet jeho nedostatky a využívat jeho výhody (třeba to jednoduché vytváření a rozšiřování objektů). :)
Přesně tak to je.
-
Jsou důležitější věci než jazyk použitý k vytvoření programu. :)
Třeba vymyslet správné funkční algoritmy, vhodnou datovou strukturu a životní cyklus objektů.
Pokud budete mít možnost si jazyk vybrat, použijete takový, ve kterém se vám dobře a rychle pracuje.
Pokud tu možnost mít nebudete, uděláte to v tom, co je požadováno nebo k dispozici.
JS na backend nikomu vnucovat nechci, ani já sám bych si ho tam nevybral (ale akceptoval bych, když by ho použil tvůrce projektu, který bych následně upravoval - už se mi stalo). Po zkušenostech s PHP preferuju staticky typované jazyky, ale na webovém frontendu na výběr není, takže v něm budu psát vesele dál, obcházet jeho nedostatky a využívat jeho výhody (třeba to jednoduché vytváření a rozšiřování objektů). :)
Ano ale problem s javascriptom, ze tie super algoritmy si musis vzdy robit sam, lebo kniznce v nom su odflaknute a prerastene. Ono dost spomaluje vyvoj, ked si kazdu prkotinu musis robit sam, lebo v NPM-ku je 20 kniznic, ale su bez dokumentacie alebo nepouzitelne, ci zabugovane.
-
Python je o notny kus lepší než JS, každý se nacházi na opačném konci spektra. Python má jeden z nejepších návrhů (a platí za to už třetí nekompatibální verzí), kdežto javascript má jedn z znejhorších návrhů.
Tak když to říkáš :-)
Python by nebyl tak špatný, kdyby byl staticky typovaný.
Tohle je na úrovni tvrzení, že všechny dynamicky typované jazyky jsou špatné z důvodu dynamického typování. A to je nesmysl. Zrovna tak je nesmysl odsoudit všechny slabě typované jazyky, kam patří i Javascript, za to, že mají slabé typy. Ale ty slabé typy se dají implementovat dobře a nebo špatně a JS je má implementované špatně. PHP má také slabé typy a implementuje je mnohem lépe než JS, ale zase má jiné problémy, řakže nechci, aby to vyznělo tak, žebho dávám za vzor dobrého jazyka. Ani Python není bez chyb a na všem se dá něco vyšťourat, ale imho z rozšířených a hodně používaných jazyků je nejhorší JS, který těží z toho, že má monopooni postavení ve webových prohlížečích. Všude jinde, kde má konkurenci, má marginální postavení.
Dynamicky typovane jazyky, nie su zle pretoze by boli dynymicky typovane, su len prosto nevhodne na cokolvek vetsie ako 100-200 riadkov. Potom zacnu prinasat len problemy.
-
Python je o notny kus lepší než JS, každý se nacházi na opačném konci spektra. Python má jeden z nejepších návrhů (a platí za to už třetí nekompatibální verzí), kdežto javascript má jedn z znejhorších návrhů. O chlup lepší návrh má PHP, a v obou případech je to bída.
A Python je neskutečně pomalejší než jiný skriptovací jazyky.
-
Ne, že bych s tím obecně nesouhlasil. Ale co se má stát když:
1 + "1"? Taky výjimka?
ano, zde vyjimka ScitaniJablekHrusekException
Jenze kdyz je jeden z operandu string tak + neni scitani ale concat. Ale to zabednencum nevysvetlis, budou pindat, ze to ma hazet exception :D
-
Ne, že bych s tím obecně nesouhlasil. Ale co se má stát když:
1 + "1"? Taky výjimka?
ano, zde vyjimka ScitaniJablekHrusekException
Jenze kdyz je jeden z operandu string tak + neni scitani ale concat. Ale to zabednencum nevysvetlis, budou pindat, ze to ma hazet exception :D
Ked su dane veci v promennych tak ty ako programator netusis ci sa bude scitavat alebo concatovat, o to ide.
-
Python je o notny kus lepší než JS, každý se nacházi na opačném konci spektra. Python má jeden z nejepších návrhů (a platí za to už třetí nekompatibální verzí), kdežto javascript má jedn z znejhorších návrhů.
Tak když to říkáš :-)
Python by nebyl tak špatný, kdyby byl staticky typovaný.
Tohle je na úrovni tvrzení, že všechny dynamicky typované jazyky jsou špatné z důvodu dynamického typování. A to je nesmysl. Zrovna tak je nesmysl odsoudit všechny slabě typované jazyky, kam patří i Javascript, za to, že mají slabé typy. Ale ty slabé typy se dají implementovat dobře a nebo špatně a JS je má implementované špatně. PHP má také slabé typy a implementuje je mnohem lépe než JS, ale zase má jiné problémy, řakže nechci, aby to vyznělo tak, žebho dávám za vzor dobrého jazyka. Ani Python není bez chyb a na všem se dá něco vyšťourat, ale imho z rozšířených a hodně používaných jazyků je nejhorší JS, který těží z toho, že má monopooni postavení ve webových prohlížečích. Všude jinde, kde má konkurenci, má marginální postavení.
Dynamicky typovane jazyky, nie su zle pretoze by boli dynymicky typovane, su len prosto nevhodne na cokolvek vetsie ako 100-200 riadkov. Potom zacnu prinasat len problemy.
Áno, ale problémy robia len idiotom. Iný v dynamicky typovaných jazykoch urobia radšej Facebook a sú za vodou.
-
Ked su dane veci v promennych tak ty ako programator netusis ci sa bude scitavat alebo concatovat, o to ide.
Pokud jsi autorem toho kódu, tak bys to tušit měl.
Nebo jsi jeden z těch lepičů, co skládají kód ze zkopírovaných fragmentů, kterým nerozumí?
-
Python je o notny kus lepší než JS, každý se nacházi na opačném konci spektra. Python má jeden z nejepších návrhů (a platí za to už třetí nekompatibální verzí), kdežto javascript má jedn z znejhorších návrhů.
Tak když to říkáš :-)
Python by nebyl tak špatný, kdyby byl staticky typovaný.
Tohle je na úrovni tvrzení, že všechny dynamicky typované jazyky jsou špatné z důvodu dynamického typování. A to je nesmysl. Zrovna tak je nesmysl odsoudit všechny slabě typované jazyky, kam patří i Javascript, za to, že mají slabé typy. Ale ty slabé typy se dají implementovat dobře a nebo špatně a JS je má implementované špatně. PHP má také slabé typy a implementuje je mnohem lépe než JS, ale zase má jiné problémy, řakže nechci, aby to vyznělo tak, žebho dávám za vzor dobrého jazyka. Ani Python není bez chyb a na všem se dá něco vyšťourat, ale imho z rozšířených a hodně používaných jazyků je nejhorší JS, který těží z toho, že má monopooni postavení ve webových prohlížečích. Všude jinde, kde má konkurenci, má marginální postavení.
Dynamicky typovane jazyky, nie su zle pretoze by boli dynymicky typovane, su len prosto nevhodne na cokolvek vetsie ako 100-200 riadkov. Potom zacnu prinasat len problemy.
Áno, ale problémy robia len idiotom. Iný v dynamicky typovaných jazykoch urobia radšej Facebook a sú za vodou.
Idiot je člověk nezvládající psát správně v rodném jazyce. Pořiď si aspoň nějaký slušný Upper Hungarian checker ;)
-
Python je o notny kus lepší než JS, každý se nacházi na opačném konci spektra. Python má jeden z nejepších návrhů (a platí za to už třetí nekompatibální verzí), kdežto javascript má jedn z znejhorších návrhů.
Tak když to říkáš :-)
Python by nebyl tak špatný, kdyby byl staticky typovaný.
Tohle je na úrovni tvrzení, že všechny dynamicky typované jazyky jsou špatné z důvodu dynamického typování. A to je nesmysl. Zrovna tak je nesmysl odsoudit všechny slabě typované jazyky, kam patří i Javascript, za to, že mají slabé typy. Ale ty slabé typy se dají implementovat dobře a nebo špatně a JS je má implementované špatně. PHP má také slabé typy a implementuje je mnohem lépe než JS, ale zase má jiné problémy, řakže nechci, aby to vyznělo tak, žebho dávám za vzor dobrého jazyka. Ani Python není bez chyb a na všem se dá něco vyšťourat, ale imho z rozšířených a hodně používaných jazyků je nejhorší JS, který těží z toho, že má monopooni postavení ve webových prohlížečích. Všude jinde, kde má konkurenci, má marginální postavení.
Dynamicky typovane jazyky, nie su zle pretoze by boli dynymicky typovane, su len prosto nevhodne na cokolvek vetsie ako 100-200 riadkov. Potom zacnu prinasat len problemy.
Áno, ale problémy robia len idiotom. Iný v dynamicky typovaných jazykoch urobia radšej Facebook a sú za vodou.
Idiot je člověk nezvládající psát správně v rodném jazyce. Pořiď si aspoň nějaký slušný Upper Hungarian checker ;)
Idiot si ty. Vyslovený. Nepoučuj o preklepoch a daj si odchod blbeček. Okrem hejtovania a bezdôvodného napádania sem nič zmysluplného nepíšeš.
-
Python je o notny kus lepší než JS, každý se nacházi na opačném konci spektra. Python má jeden z nejepších návrhů (a platí za to už třetí nekompatibální verzí), kdežto javascript má jedn z znejhorších návrhů.
Tak když to říkáš :-)
Python by nebyl tak špatný, kdyby byl staticky typovaný.
Tohle je na úrovni tvrzení, že všechny dynamicky typované jazyky jsou špatné z důvodu dynamického typování. A to je nesmysl. Zrovna tak je nesmysl odsoudit všechny slabě typované jazyky, kam patří i Javascript, za to, že mají slabé typy. Ale ty slabé typy se dají implementovat dobře a nebo špatně a JS je má implementované špatně. PHP má také slabé typy a implementuje je mnohem lépe než JS, ale zase má jiné problémy, řakže nechci, aby to vyznělo tak, žebho dávám za vzor dobrého jazyka. Ani Python není bez chyb a na všem se dá něco vyšťourat, ale imho z rozšířených a hodně používaných jazyků je nejhorší JS, který těží z toho, že má monopooni postavení ve webových prohlížečích. Všude jinde, kde má konkurenci, má marginální postavení.
Dynamicky typovane jazyky, nie su zle pretoze by boli dynymicky typovane, su len prosto nevhodne na cokolvek vetsie ako 100-200 riadkov. Potom zacnu prinasat len problemy.
Boze, to je nezmysel. Samozrejme, ak pises ako prasa, tak ti to prinesie problemy.
Ale v PRAXI, o tom tato tema je, sa ti nestane, ze budes s niecim pracovat v 100 - 200 riadkoch, pretoze vsetko rozbijas na mensie casti a tie na mensie a tak dalej, kde ti uz z principu nehrozi, ze sa ti zacnu krizit typy alebo, ze ti zacne hrozit nekonzistencia (ano, schvalne som tu redundanciu pouzil).
Za tie roky sa mi naozaj nestalo, ze by JS vzal nieco a nespravne si to pretypoval. A ak uz ma niekto z toho taky velky strach, tak pouzije Typescript.
Ale pokial pises ako prasa, tak samozrejme, budes mat problemy.
-
Ked su dane veci v promennych tak ty ako programator netusis ci sa bude scitavat alebo concatovat, o to ide.
Vazne? tak to pak nejsi programator.
-
Ne, že bych s tím obecně nesouhlasil. Ale co se má stát když:
1 + "1"? Taky výjimka?
ano, zde vyjimka ScitaniJablekHrusekException
Jenze kdyz je jeden z operandu string tak + neni scitani ale concat. Ale to zabednencum nevysvetlis, budou pindat, ze to ma hazet exception :D
Zjistit si nejdřív, co je concat, než tu ze sebe budeš dělat debila.
-
Ked su dane veci v promennych tak ty ako programator netusis ci sa bude scitavat alebo concatovat, o to ide.
Pokud jsi autorem toho kódu, tak bys to tušit měl.
Nebo jsi jeden z těch lepičů, co skládají kód ze zkopírovaných fragmentů, kterým nerozumí?
Když ten kód vidím po roce, co jsem to napsal, tak fakt netuším, co to dělá. Navíc pokud je ten kód volany "odněkud", tak evidentně se chování toho kódu liší dost výrazně podle toho, jak byl zavolán. No a "1" + 1 v drtivé většině případů je něco, co programátor _nechtěl_, tak je docela fajn, pokud to slítne rovnou při kompilaci, nebo aspoň při runtimu _vždycky_ a ne, že pak člověk hledá, proč mu z toho padaj jiný výsledky.
-
Ked su dane veci v promennych tak ty ako programator netusis ci sa bude scitavat alebo concatovat, o to ide.
Vazne? tak to pak nejsi programator.
Mělo by to být v tagu [sarcasm] nebo je to míněno vážně? ???
-
Ne, že bych s tím obecně nesouhlasil. Ale co se má stát když:
1 + "1"? Taky výjimka?
ano, zde vyjimka ScitaniJablekHrusekException
Jenze kdyz je jeden z operandu string tak + neni scitani ale concat. Ale to zabednencum nevysvetlis, budou pindat, ze to ma hazet exception :D
Ked su dane veci v promennych tak ty ako programator netusis ci sa bude scitavat alebo concatovat, o to ide.
Ale tušíš. Jednak si můžeš zjistit, co uvnitř je, druhak je úplně jedno, jak typovaný máš jazyk, ale imho by měl programátor vědět, co má kde v programu. A ano, víš, jak se to + bude chovat, protože existuje něco jako specifikace, kterou tady někteří pohrdají (chtěl bych třeba eee vidět v Céčku).
-
Ale tušíš. Jednak si můžeš zjistit, co uvnitř je, druhak je úplně jedno, jak typovaný máš jazyk, ale imho by měl programátor vědět, co má kde v programu. A ano, víš, jak se to + bude chovat, protože existuje něco jako specifikace, kterou tady někteří pohrdají (chtěl bych třeba eee vidět v Céčku).
Já mám pořád pocit, že jsem se špatně vyspal a nepoznám vtip... fakt to myslíte vážně?
function f(a,b) {
return a + b;
}
Bude to concatovat, nebo sčítat, nebo přetypovávat a konkatovat?
-
Z některých příspěvků tady mám celkem strach... to jako staticky typovaný systém někteří používají proto, aby mohli psát jako prasata?
-
Ale tušíš. Jednak si můžeš zjistit, co uvnitř je, druhak je úplně jedno, jak typovaný máš jazyk, ale imho by měl programátor vědět, co má kde v programu. A ano, víš, jak se to + bude chovat, protože existuje něco jako specifikace, kterou tady někteří pohrdají (chtěl bych třeba eee vidět v Céčku).
Já mám pořád pocit, že jsem se špatně vyspal a nepoznám vtip... fakt to myslíte vážně?
function f(a,b) {
return a + b;
}
Bude to concatovat, nebo sčítat, nebo přetypovávat a konkatovat?
A takhle normálně programuješ v dynamicky typovaných jazycích? Já mám zato, že je fajn si hlídat, co kam předávám. Uživatelský vstup člověk ošetří, zbytek programu mám 100% pod kontrolou. Čili vím, CO té funkci dávám -> vím, co to udělá.
-
Zjistit si nejdřív, co je concat, než tu ze sebe budeš dělat debila.
No zatim to vypada, ze ten titul sedi spise na tebe.
"a".concat("b")
// "ab"
"a" + "b"
// "ab"
-
Ale tušíš. Jednak si můžeš zjistit, co uvnitř je, druhak je úplně jedno, jak typovaný máš jazyk, ale imho by měl programátor vědět, co má kde v programu. A ano, víš, jak se to + bude chovat, protože existuje něco jako specifikace, kterou tady někteří pohrdají (chtěl bych třeba eee vidět v Céčku).
Já mám pořád pocit, že jsem se špatně vyspal a nepoznám vtip... fakt to myslíte vážně?
function f(a,b) {
return a + b;
}
Bude to concatovat, nebo sčítat, nebo přetypovávat a konkatovat?
A takhle normálně programuješ v dynamicky typovaných jazycích?
Teď nerozumím... jak by ta výše uvedená funkce měla vypadat v dynamickém jazyku?
Já mám zato, že je fajn si hlídat, co kam předávám.
Aha...takže nejen, že se musím zabývat tím, že tu funkci napíšu a odladím, ale ještě ke všemu vlastně k tomu pochopení co ta funkce dělá (a má dělat) musím zkontrolovat, kde všude je volaná.... v pythonu to aspoň zbuchne, když to tím proběhne, ne že to vrátí "něco".
Uživatelský vstup člověk ošetří, zbytek programu mám 100% pod kontrolou. Čili vím, CO té funkci dávám -> vím, co to udělá.
Super pro větší projekty, nedejbože když tam je víc lidí...
-
Uživatelský vstup člověk ošetří, zbytek programu mám 100% pod kontrolou. Čili vím, CO té funkci dávám -> vím, co to udělá.
Super pro větší projekty, nedejbože když tam je víc lidí...
Od toho je codereview. Ani nepocitam kolik krat jsem rejectnul pull request za slendriansky kod juniora nebo borce ex C/Java co si mysli ze umi javascript a nadela prasarny.
-
Uživatelský vstup člověk ošetří, zbytek programu mám 100% pod kontrolou. Čili vím, CO té funkci dávám -> vím, co to udělá.
Super pro větší projekty, nedejbože když tam je víc lidí...
Od toho je codereview. Ani nepocitam kolik krat jsem rejectnul pull request za slendriansky kod juniora nebo borce ex C/Java co si mysli ze umi javascript a nadela prasarny.
Mně nějak není jasné, co tím chcete říct.
Jazyk X (např. C) - 1 + "1" není validní kód, slítne to už při překladu
Jazyk Y (např. Python) - 1 + "1" nebude fungovat, slítne to při runtimu
Jazyk Z (např. JS) - 1 + "1" je prasárna, neslítne to, jen to snadno vrátí něco, co programátor nechtěl
Ono samozřejmě tyhle vlastnosti s sebou nesou i nějaké "náklady", ale mně připadá, že se snažíš říct - to vlastně není problém, že v tom jazyce tyhle prasárny normálně projdou, od čeho máme code review.... nebylo by výrazně lepší, kdyby tyhle věci vůbec nefungovaly (ideálně při překladu, ale tak aspoň při runtimu, aby ten kód vůbec nemohl projít unit testama), takže by se pak při code review nemusely řešit?
-
Z některých příspěvků tady mám celkem strach... to jako staticky typovaný systém někteří používají proto, aby mohli psát jako prasata?
Spoustě programátorů jednoduše nedochází(kromě jiného), že v dynamicky typovaných jazycích je ta kontrola z velké části na nich. JS má jako každý jazyk i slabší místa, ale není možné brát jako chybu, že v něm nejde psát na chlup stejně jako v Javě. To je jak když někdo mluví anglicky s českým slovosledem - jde to, ale pro angličany bude za debila.
-
Andy - pokud s tím máš problém, tak používej jenom === a už tě to nemusí trápit.
-
slendriansky kod juniora nebo borce ex C/Java co si mysli ze umi javascript a nadela prasarny.
Ex C-káři či Javisté jsou ještě v pohodě. Pár krát jim něco vysvětlíš a pak už obvykle fungují. Ale zaučovat ex PHP-káře či Perlistu, to je to pravé ořechové. Přijdou 50x s něčím, že jaký je ekvivalent nějaké jejich temné obskurity v JS ? A řekneš jim, že není a jsou v koncích. JS je úplně jednoduchý jazyk a všechno děláš sám nebo nahodíš knihovnu. A tak dokolečka. Děs a hrůza co za zombíky nadělá z lidí Perl či PHP.
-
Sorry, to nebylo na Andyho.
-
Od toho je codereview. Ani nepocitam kolik krat jsem rejectnul pull request za slendriansky kod juniora nebo borce ex C/Java co si mysli ze umi javascript a nadela prasarny.
Pokrocily programovaci jazyk je od toho, aby co nejvice moznych lidskych chyb odstinil a nedovolil. Argument "code review" je naprosto tragikomicky.
-
Od toho je codereview. Ani nepocitam kolik krat jsem rejectnul pull request za slendriansky kod juniora nebo borce ex C/Java co si mysli ze umi javascript a nadela prasarny.
Argument "code review" je naprosto tragikomicky.
Tak ale funguje vývojářská spodina, na nic sofistikovanějšího nemají intelektuální schopnosti.
-
Ono samozřejmě tyhle vlastnosti s sebou nesou i nějaké "náklady", ale mně připadá, že se snažíš říct - to vlastně není problém, že v tom jazyce tyhle prasárny normálně projdou, od čeho máme code review.... nebylo by výrazně lepší, kdyby tyhle věci vůbec nefungovaly (ideálně při překladu, ale tak aspoň při runtimu, aby ten kód vůbec nemohl projít unit testama), takže by se pak při code review nemusely řešit?
Priorita c.1 pri navrhu JS byla aby nepadal pri kdejake blbosti. Slo o jazyk do browsera, ktery ma podobne ako html odpoustet chyby a snazit se automaticky neco vymyslet v nevalidni situaci. Kdyby html & js byly totalne striktni tak jedina chyba a stranka se nezobrazi. To samozrejme nechceme. Radeji at nefunfuje nejaka mala cast stranky nez aby neslo vubec nic.
Tato priorita tu byla, je a bude. Je to dizajnovy navrh, muze se vam nelibit ale nikdo vas nenuti delat webarinu.
Kdyz chcete mit mene prace pri CR tak muzete pouzit nejaky jiny jazyk co do (validniho) JS transpiluje. Nejpopularnejsi jsou dnes TypeScript a CoffeeScript. Tam vam zjevne 1 + "1" neprojde, a potencialni runtime je mozne take osetrit pres type guardy. To je ale spise vec pro velke MVC apky.
-
Ono samozřejmě tyhle vlastnosti s sebou nesou i nějaké "náklady", ale mně připadá, že se snažíš říct - to vlastně není problém, že v tom jazyce tyhle prasárny normálně projdou, od čeho máme code review.... nebylo by výrazně lepší, kdyby tyhle věci vůbec nefungovaly (ideálně při překladu, ale tak aspoň při runtimu, aby ten kód vůbec nemohl projít unit testama), takže by se pak při code review nemusely řešit?
Priorita c.1 pri navrhu JS byla aby nepadal pri kdejake blbosti. Slo o jazyk do browsera, ktery ma podobne ako html odpoustet chyby a snazit se automaticky neco vymyslet v nevalidni situaci. Kdyby html & js byly totalne striktni tak jedina chyba a stranka se nezobrazi. To samozrejme nechceme. Radeji at nefunfuje nejaka mala cast stranky nez aby neslo vubec nic.
Pokud jsem slyšel o historii JS, tak při návrhu se o nějakých prioritách asi nebavili...
Tato priorita tu byla, je a bude. Je to dizajnovy navrh, muze se vam nelibit ale nikdo vas nenuti delat webarinu.
Kdyz chcete mit mene prace pri CR tak muzete pouzit nejaky jiny jazyk co do (validniho) JS transpiluje. Nejpopularnejsi jsou dnes TypeScript a CoffeeScript. Tam vam zjevne 1 + "1" neprojde, a potencialni runtime je mozne take osetrit pres type guardy. To je ale spise vec pro velke MVC apky.
A smím se teda zeptat, proč JS ochotně slítne na sebemenší syntax error?
-
Pokrocily programovaci jazyk je od toho, aby co nejvice moznych lidskych chyb odstinil a nedovolil. Argument "code review" je naprosto tragikomicky.
1. takovy jazyk neexistuje.
2. Je to jen a pouze tvuj subjektivni nazor. Navic je chybny.
-
A smím se teda zeptat, proč JS ochotně slítne na sebemenší syntax error?
Ja myslel, ze se tady bavim s programatory, kteri rozlisuji co je syntax a runtime error.
-
Ono samozřejmě tyhle vlastnosti s sebou nesou i nějaké "náklady", ale mně připadá, že se snažíš říct - to vlastně není problém, že v tom jazyce tyhle prasárny normálně projdou, od čeho máme code review.... nebylo by výrazně lepší, kdyby tyhle věci vůbec nefungovaly (ideálně při překladu, ale tak aspoň při runtimu, aby ten kód vůbec nemohl projít unit testama), takže by se pak při code review nemusely řešit?
Priorita c.1 pri navrhu JS byla aby nepadal pri kdejake blbosti. Slo o jazyk do browsera, ktery ma podobne ako html odpoustet chyby a snazit se automaticky neco vymyslet v nevalidni situaci. Kdyby html & js byly totalne striktni tak jedina chyba a stranka se nezobrazi. To samozrejme nechceme. Radeji at nefunfuje nejaka mala cast stranky nez aby neslo vubec nic.
Tato priorita tu byla, je a bude. Je to dizajnovy navrh, muze se vam nelibit ale nikdo vas nenuti delat webarinu.
Kdyz chcete mit mene prace pri CR tak muzete pouzit nejaky jiny jazyk co do (validniho) JS transpiluje. Nejpopularnejsi jsou dnes TypeScript a CoffeeScript. Tam vam zjevne 1 + "1" neprojde, a potencialni runtime je mozne take osetrit pres type guardy. To je ale spise vec pro velke MVC apky.
Předvádíš myšlenkové pochody hodné kreténa: "Radši ať nefunguje nějaká malá část jaderné elektrárny, než aby nešlo vůbec nic." ::)
-
Pokrocily programovaci jazyk je od toho, aby co nejvice moznych lidskych chyb odstinil a nedovolil. Argument "code review" je naprosto tragikomicky.
1. takovy jazyk neexistuje.
Přečti si něco o silných typových systémech (klidně i zdejší vlákno o tomto tématu), rozšíří ti to tvé zatuchlé JS obzory. Ne že bys měl na to to pochopit, ale aspoň budeš vědět, co existuje.
-
Předvádíš myšlenkové pochody hodné kreténa: "Radši ať nefunguje nějaká malá část jaderné elektrárny, než aby nešlo vůbec nic." ::)
[/quote]
Hura doslo na invektivy, takze zabednenym "takyprogramatorum" uz zrejme dochazeji argumenty. Jen tak dal, vyzpovidejte se a ukazte svoje skutecne ja aby jsme vsichni videli co za paka se tu snazi shazovat tak skvely jazyk ako JavaScript.
-
A smím se teda zeptat, proč JS ochotně slítne na sebemenší syntax error?
Ja myslel, ze se tady bavim s programatory
Ty se nemáš co bavit s programátory, kdejaký Pepa, co na stavbě kope díru lopatou, se taky nebaví s architekty.
-
Přečti si něco o silných typových systémech (klidně i zdejší vlákno o tomto tématu), rozšíří ti to tvé zatuchlé JS obzory. Ne že bys měl na to to pochopit, ale aspoň budeš vědět, co existuje.
Nebudu krmit trola, ktery se tu snazi argumentovat nesmysly, ze "silne typovane systemy" odstini lidske chyby.
-
aby jsme vsichni videli co za paka se tu snazi shazovat tak skvely jazyk ako JavaScript.
Zatím jen vidíme, co za - tvými slovy - "paka" przní "tak svělý jazyk ako (sic! čobole)" je čeština - "aby jsme" místo "abychom" může použít jen (censored).
-
A smím se teda zeptat, proč JS ochotně slítne na sebemenší syntax error?
Ja myslel, ze se tady bavim s programatory, kteri rozlisuji co je syntax a runtime error.
No a ti programátoři vědí, že syntax error je často recoverable, tak v čem je problém?
-
Já mám zato, že je fajn si hlídat, co kam předávám.
Aha...takže nejen, že se musím zabývat tím, že tu funkci napíšu a odladím, ale ještě ke všemu vlastně k tomu pochopení co ta funkce dělá (a má dělat) musím zkontrolovat, kde všude je volaná.... v pythonu to aspoň zbuchne, když to tím proběhne, ne že to vrátí "něco".
Ano, je to vhodný programátorský návyk. Buď funkci volám tak, že vždycky vím, že jí pošlu korektní vstup, nebo to v ní ošetřím. V C snad taky ve funkci kontroluješ, že jsi nedostal NULL a pak ho tam můžeš poslat, nebo nekontroluješ, ale dáváš si sakra pozor, aby sis byl "jistý", že jí tam nepřijde.
Jinak je fajn si funkce pojmenovávat tak, aby bylo +/- jasné, co dělá. ;)
Uživatelský vstup člověk ošetří, zbytek programu mám 100% pod kontrolou. Čili vím, CO té funkci dávám -> vím, co to udělá.
Super pro větší projekty, nedejbože když tam je víc lidí...
A vidíš, dá se to. :) Je to jen o tom, jak jsou lidi zvyklí programovat. Pokud se někdo takto spoléhá na typový systém, tak si zaslouží, aby ho to vyšplouchlo. Dá se to (a celkem hezky), ale chce to daleko větší sebekázeň, protože programátorovi takové jazyky spoustu dovolí.
-
Ja sa strácam. Pep, v akom jazyku programuješ, že je tak dobrý, že ti nedovolí napísať chybný kód???
-
Já mám zato, že je fajn si hlídat, co kam předávám.
Aha...takže nejen, že se musím zabývat tím, že tu funkci napíšu a odladím, ale ještě ke všemu vlastně k tomu pochopení co ta funkce dělá (a má dělat) musím zkontrolovat, kde všude je volaná.... v pythonu to aspoň zbuchne, když to tím proběhne, ne že to vrátí "něco".
Ano, je to vhodný programátorský návyk. Buď funkci volám tak, že vždycky vím, že jí pošlu korektní vstup, nebo to v ní ošetřím. V C snad taky ve funkci kontroluješ, že jsi nedostal NULL a pak ho tam můžeš poslat, nebo nekontroluješ, ale dáváš si sakra pozor, aby sis byl "jistý", že jí tam nepřijde.
V Javě si parametr označím jako @NonNull a překladač mi případně vynadá. Když tam ten NULL přijde, tak to slítne, ne že to vrátí nějaký poněkud neočekávaný výsledek.
Tohle je mimochodem supr na silných typových systémech - já prostě nemusím řešit, kdo to kde volá. Ta funkce prostě v typu specifikuje, co je korektní parametr a očekávání je, že v rámci těchto mezí by měla vracet korektní výsledky. A pak prostě nemusím řešit, kdo kde jak tu funkci volá.
Uživatelský vstup člověk ošetří, zbytek programu mám 100% pod kontrolou. Čili vím, CO té funkci dávám -> vím, co to udělá.
Super pro větší projekty, nedejbože když tam je víc lidí...
A vidíš, dá se to. :) Je to jen o tom, jak jsou lidi zvyklí programovat. Pokud se někdo takto spoléhá na typový systém, tak si zaslouží, aby ho to vyšplouchlo. Dá se to (a celkem hezky), ale chce to daleko větší sebekázeň, protože programátorovi takové jazyky spoustu dovolí.
Ono se dá škrábat i levou nohou za pravým uchem... ale tak nějak nechápu proč odpověď "dá se s tím žít" by měla být jakkoliv relevantní k tezi "je to stupidní a způsobuje to problémy". Samozřejmě že code review řeší, když tam nějaký user napíše prasárnu. Stejně tak to řeší jazyk tím, že takovou konstrukci vůbec nepřipustí. Ano, holt jazyky nejsou dokonalé a musíme se s tím nějak naučit žít, ale proč tyhle stupidní vlastnosti obhajujete??
Připomíná mi to jednoho kamaráda - trabanty jsou dobrý, že se na nich dá poměrně snadno prakticky všechno opravit. Ale ono by se to nemuselo opravovat, kdyby se to pořád nerozbíjelo....
-
Já mám zato, že je fajn si hlídat, co kam předávám.
Aha...takže nejen, že se musím zabývat tím, že tu funkci napíšu a odladím, ale ještě ke všemu vlastně k tomu pochopení co ta funkce dělá (a má dělat) musím zkontrolovat, kde všude je volaná.... v pythonu to aspoň zbuchne, když to tím proběhne, ne že to vrátí "něco".
Ano, je to vhodný programátorský návyk. Buď funkci volám tak, že vždycky vím, že jí pošlu korektní vstup, nebo to v ní ošetřím. V C snad taky ve funkci kontroluješ, že jsi nedostal NULL a pak ho tam můžeš poslat, nebo nekontroluješ, ale dáváš si sakra pozor, aby sis byl "jistý", že jí tam nepřijde.
V Javě si parametr označím jako @NonNull a překladač mi případně vynadá. Když tam ten NULL přijde, tak to slítne, ne že to vrátí nějaký poněkud neočekávaný výsledek.
Tohle je mimochodem supr na silných typových systémech - já prostě nemusím řešit, kdo to kde volá. Ta funkce prostě v typu specifikuje, co je korektní parametr a očekávání je, že v rámci těchto mezí by měla vracet korektní výsledky. A pak prostě nemusím řešit, kdo kde jak tu funkci volá.
Uživatelský vstup člověk ošetří, zbytek programu mám 100% pod kontrolou. Čili vím, CO té funkci dávám -> vím, co to udělá.
Super pro větší projekty, nedejbože když tam je víc lidí...
A vidíš, dá se to. :) Je to jen o tom, jak jsou lidi zvyklí programovat. Pokud se někdo takto spoléhá na typový systém, tak si zaslouží, aby ho to vyšplouchlo. Dá se to (a celkem hezky), ale chce to daleko větší sebekázeň, protože programátorovi takové jazyky spoustu dovolí.
Ono se dá škrábat i levou nohou za pravým uchem... ale tak nějak nechápu proč odpověď "dá se s tím žít" by měla být jakkoliv relevantní k tezi "je to stupidní a způsobuje to problémy". Samozřejmě že code review řeší, když tam nějaký user napíše prasárnu. Stejně tak to řeší jazyk tím, že takovou konstrukci vůbec nepřipustí. Ano, holt jazyky nejsou dokonalé a musíme se s tím nějak naučit žít, ale proč tyhle stupidní vlastnosti obhajujete??
Připomíná mi to jednoho kamaráda - trabanty jsou dobrý, že se na nich dá poměrně snadno prakticky všechno opravit. Ale ono by se to nemuselo opravovat, kdyby se to pořád nerozbíjelo....
Takže vďaka tomu ty píšeš len dokonalý kód. Programy ktoré produkuje školy bežia dokonale, bez jedinej chyby. Tak?
-
Takže vďaka tomu ty píšeš len dokonalý kód. Programy ktoré produkuje školy bežia dokonale, bez jedinej chyby. Tak?
Ne, píšu kód, ve kterém se chyby určitého typu nevyskytují.
-
Produkuješ tam malo byť. To len môj tel. má svojský zmysel pre humor.
-
Takže vďaka tomu ty píšeš len dokonalý kód. Programy ktoré produkuje školy bežia dokonale, bez jedinej chyby. Tak?
Ne, píšu kód, ve kterém se chyby určitého typu nevyskytují.
A vieš, že podľa jednej štúdie majú statické typy len 4% vplyv na hustotu výskytu chýb oproti dynamicky typovaným?
-
Já mám zato, že je fajn si hlídat, co kam předávám.
Aha...takže nejen, že se musím zabývat tím, že tu funkci napíšu a odladím, ale ještě ke všemu vlastně k tomu pochopení co ta funkce dělá (a má dělat) musím zkontrolovat, kde všude je volaná.... v pythonu to aspoň zbuchne, když to tím proběhne, ne že to vrátí "něco".
Ano, je to vhodný programátorský návyk. Buď funkci volám tak, že vždycky vím, že jí pošlu korektní vstup, nebo to v ní ošetřím. V C snad taky ve funkci kontroluješ, že jsi nedostal NULL a pak ho tam můžeš poslat, nebo nekontroluješ, ale dáváš si sakra pozor, aby sis byl "jistý", že jí tam nepřijde.
Tohle je mimochodem supr na silných typových systémech - já prostě nemusím řešit, kdo to kde volá. Ta funkce prostě v typu specifikuje, co je korektní parametr
Ano, a díky CHI si i můžu říct nejen typ, ale i další dodatečné podmínky (tzv. kontrakty), např. že int má být nenulový.
-
Já mám zato, že je fajn si hlídat, co kam předávám.
Aha...takže nejen, že se musím zabývat tím, že tu funkci napíšu a odladím, ale ještě ke všemu vlastně k tomu pochopení co ta funkce dělá (a má dělat) musím zkontrolovat, kde všude je volaná.... v pythonu to aspoň zbuchne, když to tím proběhne, ne že to vrátí "něco".
Ano, je to vhodný programátorský návyk. Buď funkci volám tak, že vždycky vím, že jí pošlu korektní vstup, nebo to v ní ošetřím. V C snad taky ve funkci kontroluješ, že jsi nedostal NULL a pak ho tam můžeš poslat, nebo nekontroluješ, ale dáváš si sakra pozor, aby sis byl "jistý", že jí tam nepřijde.
Tohle je mimochodem supr na silných typových systémech - já prostě nemusím řešit, kdo to kde volá. Ta funkce prostě v typu specifikuje, co je korektní parametr
Ano, a díky CHI si i můžu říct nejen typ, ale i další dodatečné podmínky (tzv. kontrakty), např. že int má být nenulový.
A si si vedomý, že to môžem aj v JS?
-
Takže vďaka tomu ty píšeš len dokonalý kód. Programy ktoré produkuje školy bežia dokonale, bez jedinej chyby. Tak?
Ne, píšu kód, ve kterém se chyby určitého typu nevyskytují.
A vieš, že podľa jednej štúdie majú statické typy len 4% vplyv na hustotu výskytu chýb oproti dynamicky typovaným?
:) A podle té druhé...? Experti říkají....... špatně jsem se vyspal, asi dneska nechápu vtipy...
-
Já mám zato, že je fajn si hlídat, co kam předávám.
Aha...takže nejen, že se musím zabývat tím, že tu funkci napíšu a odladím, ale ještě ke všemu vlastně k tomu pochopení co ta funkce dělá (a má dělat) musím zkontrolovat, kde všude je volaná.... v pythonu to aspoň zbuchne, když to tím proběhne, ne že to vrátí "něco".
Ano, je to vhodný programátorský návyk. Buď funkci volám tak, že vždycky vím, že jí pošlu korektní vstup, nebo to v ní ošetřím. V C snad taky ve funkci kontroluješ, že jsi nedostal NULL a pak ho tam můžeš poslat, nebo nekontroluješ, ale dáváš si sakra pozor, aby sis byl "jistý", že jí tam nepřijde.
Tohle je mimochodem supr na silných typových systémech - já prostě nemusím řešit, kdo to kde volá. Ta funkce prostě v typu specifikuje, co je korektní parametr
Ano, a díky CHI si i můžu říct nejen typ, ale i další dodatečné podmínky (tzv. kontrakty), např. že int má být nenulový.
A si si vedomý, že to môžem aj v JS?
Nemůžeš, ani staticky typovaná Java ti to v typovém systému neumožní.
-
Takže vďaka tomu ty píšeš len dokonalý kód. Programy ktoré produkuje školy bežia dokonale, bez jedinej chyby. Tak?
Ne, píšu kód, ve kterém se chyby určitého typu nevyskytují.
A vieš, že podľa jednej štúdie majú statické typy len 4% vplyv na hustotu výskytu chýb oproti dynamicky typovaným?
:) A podle té druhé...? Experti říkají....... špatně jsem se vyspal, asi dneska nechápu vtipy...
Na typový systém sa dnes nikto nespolieha. Ani na statický, ani na dynamický. Každý skutočný programátor píše k svojim funkciám rovno aj testy, v zmysle TDD metodiky. Lebo len to je aká taká záruka, že tam nebudú chyby, nie typový systém. A ešte zvlášť sú pri staticky typovaných programátori upozorňovaní, aby testy láskavo nevynechávali, lebo statický systém dáva len pocit falošnej bezpečnosti, až TDD metodika má reálnym vplyv na hustotu výskytu chýb, niekde medzi 25 až 80 percent. Ak toto nevieš, si lopata bez skúseností na reálnom projekte v týme. Čo si u mňa tak či tak, pokojne si ľahni a spí ďalej, s takýmito názormi tak skoro nebudeš vstávať do práce ;)
-
Já mám zato, že je fajn si hlídat, co kam předávám.
Aha...takže nejen, že se musím zabývat tím, že tu funkci napíšu a odladím, ale ještě ke všemu vlastně k tomu pochopení co ta funkce dělá (a má dělat) musím zkontrolovat, kde všude je volaná.... v pythonu to aspoň zbuchne, když to tím proběhne, ne že to vrátí "něco".
Ano, je to vhodný programátorský návyk. Buď funkci volám tak, že vždycky vím, že jí pošlu korektní vstup, nebo to v ní ošetřím. V C snad taky ve funkci kontroluješ, že jsi nedostal NULL a pak ho tam můžeš poslat, nebo nekontroluješ, ale dáváš si sakra pozor, aby sis byl "jistý", že jí tam nepřijde.
Tohle je mimochodem supr na silných typových systémech - já prostě nemusím řešit, kdo to kde volá. Ta funkce prostě v typu specifikuje, co je korektní parametr
Ano, a díky CHI si i můžu říct nejen typ, ale i další dodatečné podmínky (tzv. kontrakty), např. že int má být nenulový.
A si si vedomý, že to môžem aj v JS?
Nemůžeš, ani staticky typovaná Java ti to v typovém systému neumožní.
A ako Ti pomáha Java s nesprávnym vstupom za behu programu? Nechávaš svoje programy proste zahučať na runtime error? Nezájem? Veď ty si to napísal správne?
-
Takže vďaka tomu ty píšeš len dokonalý kód. Programy ktoré produkuje školy bežia dokonale, bez jedinej chyby. Tak?
Ne, píšu kód, ve kterém se chyby určitého typu nevyskytují.
A vieš, že podľa jednej štúdie majú statické typy len 4% vplyv na hustotu výskytu chýb oproti dynamicky typovaným?
:) A podle té druhé...? Experti říkají....... špatně jsem se vyspal, asi dneska nechápu vtipy...
Na typový systém sa dnes nikto nespolieha. Ani na statický, ani na dynamický. Každý skutočný programátor píše k svojim funkciám rovno aj testy
Potom software vypadá tak, jak vypadá, když ho píšou retardi jako ty, co ani neví, co to typ je.
-
Takže vďaka tomu ty píšeš len dokonalý kód. Programy ktoré produkuje školy bežia dokonale, bez jedinej chyby. Tak?
Ne, píšu kód, ve kterém se chyby určitého typu nevyskytují.
A vieš, že podľa jednej štúdie majú statické typy len 4% vplyv na hustotu výskytu chýb oproti dynamicky typovaným?
:) A podle té druhé...? Experti říkají....... špatně jsem se vyspal, asi dneska nechápu vtipy...
Na typový systém sa dnes nikto nespolieha. Ani na statický, ani na dynamický. Každý skutočný programátor píše k svojim funkciám rovno aj testy
Potom software vypadá tak, jak vypadá, když ho píšou retardi jako ty, co ani neví, co to typ je.
Tak to si len potvrdil čo som si myslel
Si naprostá lopata :/ A vraj programátor...
-
Já mám zato, že je fajn si hlídat, co kam předávám.
Aha...takže nejen, že se musím zabývat tím, že tu funkci napíšu a odladím, ale ještě ke všemu vlastně k tomu pochopení co ta funkce dělá (a má dělat) musím zkontrolovat, kde všude je volaná.... v pythonu to aspoň zbuchne, když to tím proběhne, ne že to vrátí "něco".
Ano, je to vhodný programátorský návyk. Buď funkci volám tak, že vždycky vím, že jí pošlu korektní vstup, nebo to v ní ošetřím. V C snad taky ve funkci kontroluješ, že jsi nedostal NULL a pak ho tam můžeš poslat, nebo nekontroluješ, ale dáváš si sakra pozor, aby sis byl "jistý", že jí tam nepřijde.
V Javě si parametr označím jako @NonNull a překladač mi případně vynadá. Když tam ten NULL přijde, tak to slítne, ne že to vrátí nějaký poněkud neočekávaný výsledek.
Tohle je mimochodem supr na silných typových systémech - já prostě nemusím řešit, kdo to kde volá. Ta funkce prostě v typu specifikuje, co je korektní parametr a očekávání je, že v rámci těchto mezí by měla vracet korektní výsledky. A pak prostě nemusím řešit, kdo kde jak tu funkci volá.
Nemám dojem, že bych mluvil o Javě. Pointa byla jasná.
Já mám rád "silné" typové systémy, třeba takový Haskell je fakt super. ALE nebudu kvůli tomu odsuzovat jazyky, které na to jdou jinak. Když neumím programovat bez silných typů, tak to nebudu dělat (projde-li mi to), ale nebudu psát, jak jsou všechny "slaběji" typované jazyky na nic. V takovém případě bych byl tak akorát debil.
Jinak je ti doufám jasné, že i v JavaScriptu taky můžeš hlídat, jestli jsi dostal číslo, nebo string, nebo... žejo? :D
Uživatelský vstup člověk ošetří, zbytek programu mám 100% pod kontrolou. Čili vím, CO té funkci dávám -> vím, co to udělá.
Super pro větší projekty, nedejbože když tam je víc lidí...
A vidíš, dá se to. :) Je to jen o tom, jak jsou lidi zvyklí programovat. Pokud se někdo takto spoléhá na typový systém, tak si zaslouží, aby ho to vyšplouchlo. Dá se to (a celkem hezky), ale chce to daleko větší sebekázeň, protože programátorovi takové jazyky spoustu dovolí.
Ono se dá škrábat i levou nohou za pravým uchem... ale tak nějak nechápu proč odpověď "dá se s tím žít" by měla být jakkoliv relevantní k tezi "je to stupidní a způsobuje to problémy". Samozřejmě že code review řeší, když tam nějaký user napíše prasárnu. Stejně tak to řeší jazyk tím, že takovou konstrukci vůbec nepřipustí. Ano, holt jazyky nejsou dokonalé a musíme se s tím nějak naučit žít, ale proč tyhle stupidní vlastnosti obhajujete??
Připomíná mi to jednoho kamaráda - trabanty jsou dobrý, že se na nich dá poměrně snadno prakticky všechno opravit. Ale ono by se to nemuselo opravovat, kdyby se to pořád nerozbíjelo....
Nevidím nikde, že bych nabízel odpověď "dá se s tím žít". Spíš odmítám tvé kategorické "nejde" a nabízím "jde to, ale má to vyšší nároky na programátorovu kázeň" v kontextu toho, že pokud někdo píše jako čuně, tak mu to kompilátor z malé části zatrhne.
Řeknu to jinak, abys to pochopil. Jestli ti přijde ok strkat Int do funkce "duplicateString", tak není chyba v typovém systému. Programovat se dá pěkně i v dynamicky typovaných jazycích jako jsou JavaScript, Perl a další. Stupidní jsou tvé teze.
-
Řeknu to jinak, abys to pochopil. Jestli ti přijde ok strkat Int do funkce "duplicateString", tak není chyba v typovém systému. Programovat se dá pěkně i v dynamicky typovaných jazycích jako jsou JavaScript, Perl a další. Stupidní jsou tvé teze.
Mně to OK nepřijde. Přijde mi to celkem jasně prasárna a nechápu proč to ten jazyk vůbec umožňuje, když to evidentně umožňovat nemusí (viz python). Takže když se někdo ptá na problémy tohoto jazyka, tak tohle mi připadá jako problém.
To je jako když máš přehlídku aut a auto jménem JS má 10x delší brzdnou dráhu než ostatní. Jasně, můžeš jezdit takovým způsobem, abys nenaboural. Ale fakt ti to přijde divný, když to označím jako "problém", který to auto má?
-
Řeknu to jinak, abys to pochopil. Jestli ti přijde ok strkat Int do funkce "duplicateString", tak není chyba v typovém systému. Programovat se dá pěkně i v dynamicky typovaných jazycích jako jsou JavaScript, Perl a další. Stupidní jsou tvé teze.
Mně to OK nepřijde. Přijde mi to celkem jasně prasárna a nechápu proč to ten jazyk vůbec umožňuje, když to evidentně umožňovat nemusí (viz python). Takže když se někdo ptá na problémy tohoto jazyka, tak tohle mi připadá jako problém.
To je jako když máš přehlídku aut a auto jménem JS má 10x delší brzdnou dráhu než ostatní. Jasně, můžeš jezdit takovým způsobem, abys nenaboural. Ale fakt ti to přijde divný, když to označím jako "problém", který to auto má?
Urobíš nesprávne porovnanie, vyjde ti nesprávny výsledok. To divné nie je. Jediné divné je, kam chodíš na tie porovnania. On totiž jediný rozdiel medzi staticky a dynamicky typovaným jazykom je, že si musíš v dynamicky typovanom viac strážiť typy. To je daň za tú väčšiu flexibilitu. Ale v konečnom dôsledku to musíš robiť tak či tak, lebo nejde o pár preklepov pri písaní programu, ale o chyby za behu, o runtime chyby. A tie ti neustráži žiadny jazyk.
-
Věci jako dynamické typy, truthy values a podobně ti dávají větší volnost a dají se díky nim psát stručnější, přehlednější programy. Musíš ale vědět, co děláš(to je důležitá věta - cokoliv se na první pohled může zdát jako naprostý nesmysl, bez zasazení do správného kontextu). Když nejsi ochotný přijmout vyšší zodpovědnost, která provází mnohem vyšší volnost, tak zůstaň u jazyků, které tě sice omezují, ale zároveň chrání. Trochu takový stockholmský syndrom.
-
Jinak je ti doufám jasné, že i v JavaScriptu taky můžeš hlídat, jestli jsi dostal číslo, nebo string
Jen za běhu. Fakt budeš "kopat" základy lžičkou, když můžeš použít bagr?
-
Na typový systém sa dnes nikto nespolieha. Ani na statický, ani na dynamický. Každý skutočný programátor píše k svojim funkciám rovno aj testy, v zmysle TDD metodiky. Lebo len to je aká taká záruka, že tam nebudú chyby, nie typový systém. A ešte zvlášť sú pri staticky typovaných programátori upozorňovaní, aby testy láskavo nevynechávali, lebo statický systém dáva len pocit falošnej bezpečnosti, až TDD metodika má reálnym vplyv na hustotu výskytu chýb, niekde medzi 25 až 80 percent. Ak toto nevieš, si lopata bez skúseností na reálnom projekte v týme. Čo si u mňa tak či tak, pokojne si ľahni a spí ďalej, s takýmito názormi tak skoro nebudeš vstávať do práce ;)
Tak nevím. Zkoušel jsi stejný projekt implementovat v nějakým jazyce s pořádným typovým systémem, abys měl srovnání? BTW, nevíš náhodou, proč se dneska tak tlačí TypeScript a Flow?
-
Věci jako dynamické typy ti dávají větší volnost a dají se díky nim psát stručnější, přehlednější programy.
To je nebetyčná hovadina, viz HMTS.
-
Python je o notny kus lepší než JS, každý se nacházi na opačném konci spektra. Python má jeden z nejepších návrhů (a platí za to už třetí nekompatibální verzí), kdežto javascript má jedn z znejhorších návrhů.
Tak když to říkáš :-)
Python by nebyl tak špatný, kdyby byl staticky typovaný.
Tohle je na úrovni tvrzení, že všechny dynamicky typované jazyky jsou špatné z důvodu dynamického typování. A to je nesmysl. Zrovna tak je nesmysl odsoudit všechny slabě typované jazyky, kam patří i Javascript, za to, že mají slabé typy. Ale ty slabé typy se dají implementovat dobře a nebo špatně a JS je má implementované špatně. PHP má také slabé typy a implementuje je mnohem lépe než JS, ale zase má jiné problémy, řakže nechci, aby to vyznělo tak, žebho dávám za vzor dobrého jazyka. Ani Python není bez chyb a na všem se dá něco vyšťourat, ale imho z rozšířených a hodně používaných jazyků je nejhorší JS, který těží z toho, že má monopooni postavení ve webových prohlížečích. Všude jinde, kde má konkurenci, má marginální postavení.
Dynamicky typovane jazyky, nie su zle pretoze by boli dynymicky typovane, su len prosto nevhodne na cokolvek vetsie ako 100-200 riadkov. Potom zacnu prinasat len problemy.
Jak komu :-). Není s nimi problém ani v o dva rady rozsahlejsich programech.
-
Věci jako dynamické typy ti dávají větší volnost a dají se díky nim psát stručnější, přehlednější programy.
To je nebetyčná hovadina, viz HMTS.
Čo je HTMS?
-
Věci jako dynamické typy, truthy values a podobně ti dávají větší volnost a dají se díky nim psát stručnější, přehlednější programy. Musíš ale vědět, co děláš(to je důležitá věta - cokoliv se na první pohled může zdát jako naprostý nesmysl, bez zasazení do správného kontextu). Když nejsi ochotný přijmout vyšší zodpovědnost, která provází mnohem vyšší volnost, tak zůstaň u jazyků, které tě sice omezují, ale zároveň chrání.
(taky odpověď Wal-De-Mar)
Zkoušel jsi někdy jazyk z pořádným typovým systémem? (haskell, scala, ocaml) Protože pokud jo, tak bych prosil nějaké zdůvodnění, protože tohle IMO naprosto není pravda.
-
Věci jako dynamické typy ti dávají větší volnost a dají se díky nim psát stručnější, přehlednější programy.
To je nebetyčná hovadina, viz HMTS.
Čo je HTMS?
Googluj, šmudlo.
-
Na typový systém sa dnes nikto nespolieha. Ani na statický, ani na dynamický. Každý skutočný programátor píše k svojim funkciám rovno aj testy, v zmysle TDD metodiky. Lebo len to je aká taká záruka, že tam nebudú chyby, nie typový systém. A ešte zvlášť sú pri staticky typovaných programátori upozorňovaní, aby testy láskavo nevynechávali, lebo statický systém dáva len pocit falošnej bezpečnosti, až TDD metodika má reálnym vplyv na hustotu výskytu chýb, niekde medzi 25 až 80 percent. Ak toto nevieš, si lopata bez skúseností na reálnom projekte v týme. Čo si u mňa tak či tak, pokojne si ľahni a spí ďalej, s takýmito názormi tak skoro nebudeš vstávať do práce ;)
Tak nevím. Zkoušel jsi stejný projekt implementovat v nějakým jazyce s pořádným typovým systémem, abys měl srovnání? BTW, nevíš náhodou, proč se dneska tak tlačí TypeScript a Flow?
Netlačí. Používam Vue bez TS. Ale spustím si statickú analýzu cez Flow, avšak bez typov. Píšem na f-e všetko ako komponenty. Tak malé, čiže prehľadné, že mi drvivou väčšinou Flow aj tak nič nenájde. A na b-e ako moduly a mikroservisy. Zasa tak malé, že ani tam. Špagety kód v ktorom sa po týždni nevyzná ani autor sám, hoc používal statické typy, je dnes tak out, ako sú začiatočníkmi preceňované statické typy.
-
Věci jako dynamické typy ti dávají větší volnost a dají se díky nim psát stručnější, přehlednější programy.
To je nebetyčná hovadina, viz HMTS.
Čo je HTMS?
Googluj, šmudlo.
Šmudlu máš v trenkách. Nehraj chytrého a napíš čo si tým myslel.
-
Zkoušel jsi někdy jazyk z pořádným typovým systémem? (haskell, scala, ocaml) Protože pokud jo, tak bych prosil nějaké zdůvodnění, protože tohle IMO naprosto není pravda.
Dřív jsem dělal v Pascalu, C#, Javě. Takže čistě osobní zkušenost. A teď se zeptám já - zkoušel sis v JS napsat nějaký pořádný program(podle idiomů platných pro JS, ne pro Javu)? nebo soudíš podle několika třířádkových skriptů, co sis sesmolil v konzoli, abys měl argumenty pro flame na rootu?
-
Zkoušel jsi někdy jazyk z pořádným typovým systémem? (haskell, scala, ocaml) Protože pokud jo, tak bych prosil nějaké zdůvodnění, protože tohle IMO naprosto není pravda.
Dřív jsem dělal v Pascalu, C#, Javě. Takže čistě osobní zkušenost. A teď se zeptám já - zkoušel sis v JS napsat nějaký pořádný program(podle idiomů platných pro JS, ne pro Javu)? nebo soudíš podle několika třířádkových skriptů, co sis sesmolil v konzoli, abys měl argumenty pro flame na rootu?
Tomu ver, že je to tak, ako píšeš. A použil ES3. O modernom JS miestny hejteri nemajú ani šajn, tam je jadro problému.
-
Ne, že bych s tím obecně nesouhlasil. Ale co se má stát když:
1 + "1"? Taky výjimka?
ano, zde vyjimka ScitaniJablekHrusekException
Jenze kdyz je jeden z operandu string tak + neni scitani ale concat. Ale to zabednencum nevysvetlis, budou pindat, ze to ma hazet exception :D
Ked su dane veci v promennych tak ty ako programator netusis ci sa bude scitavat alebo concatovat, o to ide.
Ale tušíš. Jednak si můžeš zjistit, co uvnitř je, druhak je úplně jedno, jak typovaný máš jazyk, ale imho by měl programátor vědět, co má kde v programu. A ano, víš, jak se to + bude chovat, protože existuje něco jako specifikace, kterou tady někteří pohrdají (chtěl bych třeba eee vidět v Céčku).
Vy jste hrozne nechapavi. Jako programator vis co mas v kodu, ale netusis a nemuzes tusit, kdo tu funkci pouzije a co ti do ni nacpe. A chybne pouziti by melo byt oznameno a nebo by alespín melo séadnouť na misto toho,mze udela nesmysl. Pokud ti jde o spolehlivost, musis programovat defenzivne. Temer nikdy nechces scitat string s intem, to je proste prasarna. Proto by to jazyk nemel povolit. Kdyz to nahodou mimoradne opravdu chces, pak si to jako programator osetris pretypovanim. Proto to JS dela blbe, pokud chces mit spolehlivy program, musis neustale rucne kontrolovat typy. To je opruz, takovy jazyk je akorat na hrani a je smutne, ze s jazykem na hrani musime delat frontendy i v byznys a prumyslovem prostredi pro vazne veci. A co se tyce cecka, nemej peci, to byl muj prvnin jazyk, na kterem jsem vyrostl.
-
Zkoušel jsi někdy jazyk z pořádným typovým systémem? (haskell, scala, ocaml) Protože pokud jo, tak bych prosil nějaké zdůvodnění, protože tohle IMO naprosto není pravda.
Dřív jsem dělal v Pascalu, C#, Javě. Takže čistě osobní zkušenost. A teď se zeptám já - zkoušel sis v JS napsat nějaký pořádný program(podle idiomů platných pro JS, ne pro Javu)? nebo soudíš podle několika třířádkových skriptů, co sis sesmolil v konzoli, abys měl argumenty pro flame na rootu?
Takže nezkoušel.
-
Ne, že bych s tím obecně nesouhlasil. Ale co se má stát když:
1 + "1"? Taky výjimka?
ano, zde vyjimka ScitaniJablekHrusekException
Jenze kdyz je jeden z operandu string tak + neni scitani ale concat. Ale to zabednencum nevysvetlis, budou pindat, ze to ma hazet exception :D
Ked su dane veci v promennych tak ty ako programator netusis ci sa bude scitavat alebo concatovat, o to ide.
Ale tušíš. Jednak si můžeš zjistit, co uvnitř je, druhak je úplně jedno, jak typovaný máš jazyk, ale imho by měl programátor vědět, co má kde v programu. A ano, víš, jak se to + bude chovat, protože existuje něco jako specifikace, kterou tady někteří pohrdají (chtěl bych třeba eee vidět v Céčku).
Vy jste hrozne nechapavi. Jako programator vis co mas v kodu, ale netusis a nemuzes tusit, kdo tu funkci pouzije a co ti do ni nacpe. A chybne pouziti by melo byt oznameno a nebo by alespín melo séadnouť na misto toho,mze udela nesmysl. Pokud ti jde o spolehlivost, musis programovat defenzivne. Temer nikdy nechces scitat string s intem, to je proste prasarna. Proto by to jazyk nemel povolit. Kdyz to nahodou mimoradne opravdu chces, pak si to jako programator osetris pretypovanim. Proto to JS dela blbe, pokud chces mit spolehlivy program, musis neustale rucne kontrolovat typy. To je opruz, takovy jazyk je akorat na hrani a je smutne, ze s jazykem na hrani musime delat frontendy i v byznys a prumyslovem prostredi pro vazne veci. A co se tyce cecka, nemej peci, to byl muj prvnin jazyk, na kterem jsem vyrostl.
A chápeš aspoň trochu, že ti statické typy za behu programu nepomôžu ani ň? Že musíš ručne kontrolovať vstupy aj v statickom jazyku, inak aj z Javy urobíš jazyk na hranie, lebo bude padať po každej akcii? Alebo že spadne na runtime error to nevadí? Ty ho budeš aj tak považovať za dobre napísaný?
-
Ale tušíš. Jednak si můžeš zjistit, co uvnitř je, druhak je úplně jedno, jak typovaný máš jazyk, ale imho by měl programátor vědět, co má kde v programu. A ano, víš, jak se to + bude chovat, protože existuje něco jako specifikace, kterou tady někteří pohrdají (chtěl bych třeba eee vidět v Céčku).
Já mám pořád pocit, že jsem se špatně vyspal a nepoznám vtip... fakt to myslíte vážně?
function f(a,b) {
return a + b;
}
Bude to concatovat, nebo sčítat, nebo přetypovávat a konkatovat?
A takhle normálně programuješ v dynamicky typovaných jazycích? Já mám zato, že je fajn si hlídat, co kam předávám. Uživatelský vstup člověk ošetří, zbytek programu mám 100% pod kontrolou. Čili vím, CO té funkci dávám -> vím, co to udělá.
Až budeš mít za sebou zkušenost člověka, který 20 let udržuje stále se měnící kód, na kterém pracuje skupina programátorů, budeš se smát tomu, jak jsi byl naivní.
-
Zkoušel jsi někdy jazyk z pořádným typovým systémem? (haskell, scala, ocaml) Protože pokud jo, tak bych prosil nějaké zdůvodnění, protože tohle IMO naprosto není pravda.
Dřív jsem dělal v Pascalu, C#, Javě. Takže čistě osobní zkušenost. A teď se zeptám já - zkoušel sis v JS napsat nějaký pořádný program(podle idiomů platných pro JS, ne pro Javu)? nebo soudíš podle několika třířádkových skriptů, co sis sesmolil v konzoli, abys měl argumenty pro flame na rootu?
Takže nezkoušel.
Písal predsa, že robil v Jave. Podľa teba teda nemá Java poriadny typový systém? Zato Haskell áno? Sranduješ...
-
Písal predsa, že robil v Jave. Podľa teba teda nemá Java poriadny typový systém? Zato Haskell áno? Sranduješ...
Nemá. A myslím to vážně.
-
Vy jste hrozne nechapavi. Jako programator vis co mas v kodu, ale netusis a nemuzes tusit, kdo tu funkci pouzije a co ti do ni nacpe.
To je sice nepochopení, ale z tvojí strany. Pokud má funkce přijímat zásadně jen jeden typ, tak si to máš ověřit na vstupu.
-
Takže nezkoušel.
Tak to jsme na tom v podstatě stejně, že.
-
Takže nezkoušel.
Tak to jsme na tom v podstatě stejně, že.
Napsal jsem toho fakt hodně v pythonu. Což je dynamický jazyk, který se v těchhle podstatných věcech od JS neliší. Takže bych řekl, že na rozdíl od tebe v tomhle zkušenost mám.
-
Ale tušíš. Jednak si můžeš zjistit, co uvnitř je, druhak je úplně jedno, jak typovaný máš jazyk, ale imho by měl programátor vědět, co má kde v programu. A ano, víš, jak se to + bude chovat, protože existuje něco jako specifikace, kterou tady někteří pohrdají (chtěl bych třeba eee vidět v Céčku).
Já mám pořád pocit, že jsem se špatně vyspal a nepoznám vtip... fakt to myslíte vážně?
function f(a,b) {
return a + b;
}
Bude to concatovat, nebo sčítat, nebo přetypovávat a konkatovat?
A takhle normálně programuješ v dynamicky typovaných jazycích? Já mám zato, že je fajn si hlídat, co kam předávám. Uživatelský vstup člověk ošetří, zbytek programu mám 100% pod kontrolou. Čili vím, CO té funkci dávám -> vím, co to udělá.
Až budeš mít za sebou zkušenost člověka, který 20 let udržuje stále se měnící kód, na kterém pracuje skupina programátorů, budeš se smát tomu, jak jsi byl naivní.
Takže teď si budeme honit ego, kdo má víc zkušeností? Hlavně že víš, kolik jich mám já... Trošku nevalidní argument. :)
-
Jinak je ti doufám jasné, že i v JavaScriptu taky můžeš hlídat, jestli jsi dostal číslo, nebo string
Jen za běhu. Fakt budeš "kopat" základy lžičkou, když můžeš použít bagr?
Jistě, v interpretovaných jazycích se tak nějak věci za běhu kontrolují... :D
-
Proto to JS dela blbe, pokud chces mit spolehlivy program, musis neustale rucne kontrolovat typy.
A co se tyce cecka, nemej peci, to byl muj prvnin jazyk, na kterem jsem vyrostl.
Nepřijde ti na tvých "myšlenkových" pochodech nic divné?
-
Věci jako dynamické typy, truthy values a podobně ti dávají větší volnost a dají se díky nim psát stručnější, přehlednější programy. Musíš ale vědět, co děláš(to je důležitá věta - cokoliv se na první pohled může zdát jako naprostý nesmysl, bez zasazení do správného kontextu). Když nejsi ochotný přijmout vyšší zodpovědnost, která provází mnohem vyšší volnost, tak zůstaň u jazyků, které tě sice omezují, ale zároveň chrání. Trochu takový stockholmský syndrom.
něco jako tohle https://blog.rinatussenov.com/is-javascript-type-coercion-a-good-thing-83f4e1a17fb2 ?
-
Až budeš mít za sebou zkušenost člověka, který 20 let udržuje stále se měnící kód, na kterém pracuje skupina programátorů, budeš se smát tomu, jak jsi byl naivní.
Takže teď si budeme honit ego, kdo má víc zkušeností? Hlavně že víš, kolik jich mám já... Trošku nevalidní argument. :)
No, moje zkušenost je, že v dynamických jazycích dělat velký refaktoring je třeba věc, kdy se pomalu vyplatí napsat celou tu věc od základu znovu. V jazycích typu Java to "nějak" s větším vypětím jde, v jazycích ve stylu haskell se refaktoring (a to dost masivní) dělá poměrně běžně. Osobní zkušenost. Dává to celkem smysl.
-
Jinak je ti doufám jasné, že i v JavaScriptu taky můžeš hlídat, jestli jsi dostal číslo, nebo string
Jen za běhu. Fakt budeš "kopat" základy lžičkou, když můžeš použít bagr?
Jistě, v interpretovaných jazycích se tak nějak věci za běhu kontrolují... :D
Interpretovanost nijak nesouvisí s typováním.
-
Jinak je ti doufám jasné, že i v JavaScriptu taky můžeš hlídat, jestli jsi dostal číslo, nebo string
Jen za běhu. Fakt budeš "kopat" základy lžičkou, když můžeš použít bagr?
Jistě, v interpretovaných jazycích se tak nějak věci za běhu kontrolují... :D
Interpretovanost nijak nesouvisí s typováním.
Ano, dobrý point - chtěl jsem napsat dynamických (~dynamicky typovaných). Moje chyba. :)
-
Jinak je ti doufám jasné, že i v JavaScriptu taky můžeš hlídat, jestli jsi dostal číslo, nebo string
Jen za běhu. Fakt budeš "kopat" základy lžičkou, když můžeš použít bagr?
Jistě, v interpretovaných jazycích se tak nějak věci za běhu kontrolují... :D
Interpretovanost nijak nesouvisí s typováním.
Ano, dobrý point - chtěl jsem napsat dynamických (~dynamicky typovaných). Moje chyba. :)
Pak to ale není argument. 1. “Java umí kontrolovat typy na vstupu při překladu - před během.” 2. “V JS taky jdou kontrolovat typy na vstupu.”
-
Vy jste hrozne nechapavi. Jako programator vis co mas v kodu, ale netusis a nemuzes tusit, kdo tu funkci pouzije a co ti do ni nacpe.
To je sice nepochopení, ale z tvojí strany. Pokud má funkce přijímat zásadně jen jeden typ, tak si to máš ověřit na vstupu.
Vygoogli si “historie teorie typů”, ať víš, co ti uniká.
-
Ne, že bych s tím obecně nesouhlasil. Ale co se má stát když:
1 + "1"? Taky výjimka?
ano, zde vyjimka ScitaniJablekHrusekException
Jenze kdyz je jeden z operandu string tak + neni scitani ale concat. Ale to zabednencum nevysvetlis, budou pindat, ze to ma hazet exception :D
Ked su dane veci v promennych tak ty ako programator netusis ci sa bude scitavat alebo concatovat, o to ide.
Ale tušíš. Jednak si můžeš zjistit, co uvnitř je, druhak je úplně jedno, jak typovaný máš jazyk, ale imho by měl programátor vědět, co má kde v programu. A ano, víš, jak se to + bude chovat, protože existuje něco jako specifikace, kterou tady někteří pohrdají (chtěl bych třeba eee vidět v Céčku).
Vy jste hrozne nechapavi. Jako programator vis co mas v kodu, ale netusis a nemuzes tusit, kdo tu funkci pouzije a co ti do ni nacpe. A chybne pouziti by melo byt oznameno a nebo by alespín melo séadnouť na misto toho,mze udela nesmysl. Pokud ti jde o spolehlivost, musis programovat defenzivne. Temer nikdy nechces scitat string s intem, to je proste prasarna. Proto by to jazyk nemel povolit. Kdyz to nahodou mimoradne opravdu chces, pak si to jako programator osetris pretypovanim. Proto to JS dela blbe, pokud chces mit spolehlivy program, musis neustale rucne kontrolovat typy. To je opruz, takovy jazyk je akorat na hrani a je smutne, ze s jazykem na hrani musime delat frontendy i v byznys a prumyslovem prostredi pro vazne veci. A co se tyce cecka, nemej peci, to byl muj prvnin jazyk, na kterem jsem vyrostl.
A chápeš aspoň trochu, že ti statické typy za behu programu nepomôžu ani ň? Že musíš ručne kontrolovať vstupy aj v statickom jazyku, inak aj z Javy urobíš jazyk na hranie, lebo bude padať po každej akcii? Alebo že spadne na runtime error to nevadí? Ty ho budeš aj tak považovať za dobre napísaný?
Nechápu proč mě konfrontuješ se statickými typy, o těch jsem nenapsal ani čárku. Dobře napsaný program na runtime vyjimku nespadne, protože výjimku bude mít rozumně a bezpečně ošetřenu hned na několika funkčních úrovních dle potřeby. Problém nastává v JS, který udělá kravinu a tu výjimku neudělá ani na zjevné blbosti, takže chyba se neovladatelně šíří dál systémem.
-
Takže nezkoušel.
Tak to jsme na tom v podstatě stejně, že.
Napsal jsem toho fakt hodně v pythonu. Což je dynamický jazyk, který se v těchhle podstatných věcech od JS neliší. Takže bych řekl, že na rozdíl od tebe v tomhle zkušenost mám.
Buď kecáš a Python neznáš, nebo nevíš jak je JS špatně navržený. Každopádně tvrzení, že se Python neliší od JS je hodně zcestný. :-)
-
Pokud to nechcete číst celé, tak zde je pár závěrů, které jsem vyvodil z dosavadní diskuse:
- JavaScript je špatný, protože pokud v něm programuji jako (doplň název oblíbeného jazyka - např. Cobol, Fortran, Basic aj.) tak programy v něm nefungují správně.
- JavaScript je špatný, protože akceptuje konstrukce jako např. "1" + 1, 1 + {}, apod.
- JavaScript je špatný, protože neumí správně porovnat dvě hodnoty.
- JavaScript je špatný, protože jeho dokumentace popisuje chování, které nedává smysl.
Pro nové čtenáře jen doplním že:
- Vývojáři, kteří přispívají do tohoto vlákna mají minimálně 50 let komerční praxe.
- Vývojáři, kteří přispívají do tohoto vlákna mají mzdu, alespoň 250k/měsíc, popř. 12k/MD.
- Vývojáři, kteří přispívají do tohoto vlákna znají alespoň 20 programovacích jazyků (obvykle mezi ně nepatří JavaScript).
-
Pokud to nechcete číst celé, tak zde je pár závěrů, které jsem vyvodil z dosavadní diskuse:
- JavaScript je špatný, protože pokud v něm programuji jako (doplň název oblíbeného jazyka - např. Cobol, Fortran, Basic aj.) tak programy v něm nefungují správně.
- JavaScript je špatný, protože akceptuje konstrukce jako např. "1" + 1, 1 + {}, apod.
- JavaScript je špatný, protože neumí správně porovnat dvě hodnoty.
- JavaScript je špatný, protože jeho dokumentace popisuje chování, které nedává smysl.
Pro nové čtenáře jen doplním že:
- Vývojáři, kteří přispívají do tohoto vlákna mají minimálně 50 let komerční praxe.
- Vývojáři, kteří přispívají do tohoto vlákna mají mzdu, alespoň 250k/měsíc, popř. 12k/MD.
- Vývojáři, kteří přispívají do tohoto vlákna znají alespoň 20 programovacích jazyků (obvykle mezi ně nepatří JavaScript).
+ obhajovatelé JS nemají ani ponětí o teorii typů.
-
Jinak je ti doufám jasné, že i v JavaScriptu taky můžeš hlídat, jestli jsi dostal číslo, nebo string
Jen za běhu. Fakt budeš "kopat" základy lžičkou, když můžeš použít bagr?
Jistě, v interpretovaných jazycích se tak nějak věci za běhu kontrolují... :D
No, mě na tom Javascriptu (a Pythonu do 3.4) vadí jiná věc.
Přeci jen je rozdíl mezi tím, když:
1. kontroluješ před spuštěním
2. kontroluješ za běhu
3. nekontroluješ vůbec, respektive ručně = všichni na to kašlou
Důsledek stavu, že v "v interpretovaných jazycích se tak nějak věci za běhu kontrolují" je ten, že se nekontrolují. Ani za běhu.
Proto se rozšiřují věci jako typescript, nebo flow. Protože i v JS komunitě dozrávají k přesvědčení, že je to tedy asi potřeba, některé věci kontrolovat.
-
Jednak si můžeš zjistit, co uvnitř je, ...
Tohle by slušný programátor nemohl ani vyslovit!
-
Jednak si můžeš zjistit, co uvnitř je, ...
Tohle slušný programátor nemůže ani vyslovit!
Ale cikáda tedy může.
-
Z některých příspěvků tady mám celkem strach... to jako staticky typovaný systém někteří používají proto, aby mohli psát jako prasata?
Spoustě programátorů jednoduše nedochází(kromě jiného), že v dynamicky typovaných jazycích je ta kontrola z velké části na nich.
Což v praxi znamená...
-
Pokrocily programovaci jazyk je od toho, aby co nejvice moznych lidskych chyb odstinil a nedovolil.
Naprosto souhlasím. Jenže život není tak přímočarý. Javascript vymejšleli v době, kdy byly rádi, že nemusí řešit paměť. A s ohledem na to, že netušili co za styly se v budoucnu budou prefereovat je to jazyk velmi nadčasový a flexibilní. Někdy i debilní.
-
No, mě na tom Javascriptu (a Pythonu do 3.4) vadí jiná věc.
Přeci jen je rozdíl mezi tím, když:
1. kontroluješ před spuštěním
2. kontroluješ za běhu
3. nekontroluješ vůbec, respektive ručně = všichni na to kašlou
Rozdíl mezi statickým a dynamickým typováním je v tom, že u staticky typovaných jazyků musíš data prověřit před vstupem do bloku, ale u dynamicky typovaných tu můžeš udělat v dekorátoru nebo až uvnitř bloku. Kontrolu před spuštěním můžeš udělat u všech.
-
No, mě na tom Javascriptu (a Pythonu do 3.4) vadí jiná věc.
Přeci jen je rozdíl mezi tím, když:
1. kontroluješ před spuštěním
2. kontroluješ za běhu
3. nekontroluješ vůbec, respektive ručně = všichni na to kašlou
Rozdíl mezi statickým a dynamickým typováním je v tom, že u staticky typovaných jazyků musíš data prověřit před vstupem do bloku, ale u dynamicky typovaných tu můžeš udělat v dekorátoru nebo až uvnitř bloku. Kontrolu před spuštěním můžeš udělat u všech.
Tak. Když už to chápe i Kit, tak v čem je tedy problém?
-
Vy jste hrozne nechapavi. Jako programator vis co mas v kodu, ale netusis a nemuzes tusit, kdo tu funkci pouzije a co ti do ni nacpe.
To je sice nepochopení, ale z tvojí strany. Pokud má funkce přijímat zásadně jen jeden typ, tak si to máš ověřit na vstupu.
Typická knížecí rada. 1) Data se kterými pracuješ ve funkci se do ní nedostávají jen na vstupu 2) tato data nemusí být jen jednoduché hodnoty, ale rozsáhlá pole hodnot či hůř zapouzdřených objektů.
Takže na vstupu si vše neověříš a nebo je to neefektivní, což znamená, že si je musíš ověřovat až při použití a doplnit tak do funkce mraky kontrol pro jistotu, co kdyby někdy někde něco náhodou. V podstatě tedy musíš jako programátor neustále nahrazovat absenci rozumné kontroly ze strany překladače/interpretu, čímž ti vzniká zbytečně rozsáhlý a nepřehledný kód plný kontrol, které přitom mohl dělat na pozadí a spolehlivěji 'jazyk' sám. To samo o sobě má řadu dalších negativních důsledků, třeba při změně programu, kde musíš náledně opravovat desítky až stovky těchto dodatečných kontrol v kvůli spoustě kontrol nepřehledném kódu, kde tyto úpravy dělá zpravidla někdo jiný, než původní autor.
-
No, mě na tom Javascriptu (a Pythonu do 3.4) vadí jiná věc.
Přeci jen je rozdíl mezi tím, když:
1. kontroluješ před spuštěním
2. kontroluješ za běhu
3. nekontroluješ vůbec, respektive ručně = všichni na to kašlou
Rozdíl mezi statickým a dynamickým typováním je v tom, že u staticky typovaných jazyků musíš data prověřit před vstupem do bloku, ale u dynamicky typovaných tu můžeš udělat v dekorátoru nebo až uvnitř bloku. Kontrolu před spuštěním můžeš udělat u všech.
Tak. Když už to chápe i Kit, tak v čem je tedy problém?
Třeba v tom, že to je 1) nepodstatné a 2) bezpředmětné. Ad 1) Hlavní rozdíl mezi statickým a dynamickým je v tom, že statické typy se kontrolují už při překladu. Ad 2) javascriptu není vyčítáno to, že nemá statické typy, ale jeho hloupé chování v řadě případů.
-
No, mě na tom Javascriptu (a Pythonu do 3.4) vadí jiná věc.
Přeci jen je rozdíl mezi tím, když:
1. kontroluješ před spuštěním
2. kontroluješ za běhu
3. nekontroluješ vůbec, respektive ručně = všichni na to kašlou
Rozdíl mezi statickým a dynamickým typováním je v tom, že u staticky typovaných jazyků musíš data prověřit před vstupem do bloku, ale u dynamicky typovaných tu můžeš udělat v dekorátoru nebo až uvnitř bloku. Kontrolu před spuštěním můžeš udělat u všech.
Tak. Když už to chápe i Kit, tak v čem je tedy problém?
Třeba v tom, že to je 1) nepodstatné a 2) bezpředmětné. Ad 1) Hlavní rozdíl mezi statickým a dynamickým je v tom, že statické typy se kontrolují už při překladu. Ad 2) javascriptu není vyčítáno to, že nemá statické typy, ale jeho hloupé chování v řadě případů.
Takže když do staticky typovaného jazyka narveš nevalidní data, tak nespadne?
-
Takže nezkoušel.
Tak to jsme na tom v podstatě stejně, že.
Napsal jsem toho fakt hodně v pythonu. Což je dynamický jazyk, který se v těchhle podstatných věcech od JS neliší. Takže bych řekl, že na rozdíl od tebe v tomhle zkušenost mám.
Buď kecáš a Python neznáš, nebo nevíš jak je JS špatně navržený. Každopádně tvrzení, že se Python neliší od JS je hodně zcestný. :-)
Přečti si historii diskuze ;) Byl jsem konfrontován s tím, že neznám moderní JS, takže neznám skvělé vlastnosti dynamických jazyků. Tudíž odpověď, že mám léta praxe v pythonu (s tím, že Python > JS) je IMO zcela na místě.
Ale jinak mi to připadá přesně takhle: ideální je kontrolovat všechno při překladu, a když to nejde, tak aspoň něco vynutit za běhu. Automatické přetypování je prostě anti-pattern, který by v jazyce být neměl, bez ohledu na to, jestli je něco kontrolované při překladu nebo ne.
-
Takže když do staticky typovaného jazyka narveš nevalidní data, tak nespadne?
No, v principu by neměl, protože by to při chroustání těch vstupních dat mělo vyhlásit, že ta data jsou chybná. Což samozřejmě může klidně být uděláno i v dynamickém jazyku, akorát tam se to moc nevynucuje.
Např. ve staticky typovaném jazyku se JSON na vstupu dekóduje do nějaké Class. To je operace, která může selhat (třeba z důvodu chybějících políček, špatných typů apod.) a mělo by se to ošetřit. "Nedekódovat to" je v podstatě práce navíc. V dynamicky typovaném (JS) se udělá JSON.decode a je to. "Zkontrolovat to" je práce navíc.
-
No, mě na tom Javascriptu (a Pythonu do 3.4) vadí jiná věc.
Přeci jen je rozdíl mezi tím, když:
1. kontroluješ před spuštěním
2. kontroluješ za běhu
3. nekontroluješ vůbec, respektive ručně = všichni na to kašlou
Rozdíl mezi statickým a dynamickým typováním je v tom, že u staticky typovaných jazyků musíš data prověřit před vstupem do bloku, ale u dynamicky typovaných tu můžeš udělat v dekorátoru nebo až uvnitř bloku. Kontrolu před spuštěním můžeš udělat u všech.
Tak. Když už to chápe i Kit, tak v čem je tedy problém?
Třeba v tom, že to je 1) nepodstatné a 2) bezpředmětné. Ad 1) Hlavní rozdíl mezi statickým a dynamickým je v tom, že statické typy se kontrolují už při překladu. Ad 2) javascriptu není vyčítáno to, že nemá statické typy, ale jeho hloupé chování v řadě případů.
Takže když do staticky typovaného jazyka narveš nevalidní data, tak nespadne?
Kde jsi takovou blbost vyčetl?
-
Takže nezkoušel.
Tak to jsme na tom v podstatě stejně, že.
Napsal jsem toho fakt hodně v pythonu. Což je dynamický jazyk, který se v těchhle podstatných věcech od JS neliší. Takže bych řekl, že na rozdíl od tebe v tomhle zkušenost mám.
Buď kecáš a Python neznáš, nebo nevíš jak je JS špatně navržený. Každopádně tvrzení, že se Python neliší od JS je hodně zcestný. :-)
Přečti si historii diskuze ;) Byl jsem konfrontován s tím, že neznám moderní JS, takže neznám skvělé vlastnosti dynamických jazyků. Tudíž odpověď, že mám léta praxe v pythonu (s tím, že Python > JS) je IMO zcela na místě.
Ale jinak mi to připadá přesně takhle: ideální je kontrolovat všechno při překladu, a když to nejde, tak aspoň něco vynutit za běhu. Automatické přetypování je prostě anti-pattern, který by v jazyce být neměl, bez ohledu na to, jestli je něco kontrolované při překladu nebo ne.
Žádná historie diskuse tě neopravňuje k tvrzení, že Python se v podstatných věcech od JS neliší.
-
Jinak je ti doufám jasné, že i v JavaScriptu taky můžeš hlídat, jestli jsi dostal číslo, nebo string
Jen za běhu. Fakt budeš "kopat" základy lžičkou, když můžeš použít bagr?
Jistě, v interpretovaných jazycích se tak nějak věci za běhu kontrolují... :D
Interpretovanost nijak nesouvisí s typováním.
Ano, dobrý point - chtěl jsem napsat dynamických (~dynamicky typovaných). Moje chyba. :)
Pak to ale není argument. 1. “Java umí kontrolovat typy na vstupu při překladu - před během.” 2. “V JS taky jdou kontrolovat typy na vstupu.”
Zaprvé se koukni na to, jak šly "argumenty" po sobě. Zadruhé Java je dynamicky typovaná?
Jednak si můžeš zjistit, co uvnitř je, ...
Tohle by slušný programátor nemohl ani vyslovit!
Pročpak? A co je to "slušný programátor".
Pokud by mi těžce šlo o to, aby oba parametry byly Stringy, tak si to prostě ověřím a případně vyhodím výjimku (když už na tom tak trváte). V C si taky ověřuji, jestli pointer není NULL.
-
Takže když do staticky typovaného jazyka narveš nevalidní data, tak nespadne?
No, v principu by neměl, protože by to při chroustání těch vstupních dat mělo vyhlásit, že ta data jsou chybná. Což samozřejmě může klidně být uděláno i v dynamickém jazyku, akorát tam se to moc nevynucuje.
Např. ve staticky typovaném jazyku se JSON na vstupu dekóduje do nějaké Class. To je operace, která může selhat (třeba z důvodu chybějících políček, špatných typů apod.) a mělo by se to ošetřit. "Nedekódovat to" je v podstatě práce navíc. V dynamicky typovaném (JS) se udělá JSON.decode a je to. "Zkontrolovat to" je práce navíc.
Takže když má funkce jako parametr string, ve kterém očekává číslo (např. z terminálu) a někdo tam zadá slovo, tak to stejně musíš uvnitř té funkce ošetřit, aby při konverzi na číslo ten proces nespadl.
Podobně je na tom i parametr int, ve kterém má být třeba číslo měsíce 1-12. Jen málo jazyků má pro tohle typ, např. Pascal a předpokládám, že i Haskell. Tím se ovšem přesouvá validace vstupu ven z funkce. Otázkou je: Opravdu chceme validovat vstupní data ještě před každým voláním funkce nebo si je raději zvalidujeme na jednom místě uvnitř?
Používám oba přístupy tak, jak to zrovna potřebuji. V PHP validaci uvnitř, v XSLT validaci venku.
-
Třeba v tom, že to je 1) nepodstatné a 2) bezpředmětné. Ad 1) Hlavní rozdíl mezi statickým a dynamickým je v tom, že statické typy se kontrolují už při překladu. Ad 2) javascriptu není vyčítáno to, že nemá statické typy, ale jeho hloupé chování v řadě případů.
Takže když do staticky typovaného jazyka narveš nevalidní data, tak nespadne?
Kde jsi takovou blbost vyčetl?
To není blbost, ale řečnická otázka. Při překladu nevalidní vstupní data nezkontroluješ, musíš je zkontrolovat až za běhu.
-
Jinak je ti doufám jasné, že i v JavaScriptu taky můžeš hlídat, jestli jsi dostal číslo, nebo string
Jen za běhu. Fakt budeš "kopat" základy lžičkou, když můžeš použít bagr?
Jistě, v interpretovaných jazycích se tak nějak věci za běhu kontrolují... :D
Interpretovanost nijak nesouvisí s typováním.
Ano, dobrý point - chtěl jsem napsat dynamických (~dynamicky typovaných). Moje chyba. :)
Pak to ale není argument. 1. “Java umí kontrolovat typy na vstupu při překladu - před během.” 2. “V JS taky jdou kontrolovat typy na vstupu.”
Zaprvé se koukni na to, jak šly "argumenty" po sobě. Zadruhé Java je dynamicky typovaná?
Jednak si můžeš zjistit, co uvnitř je, ...
Tohle by slušný programátor nemohl ani vyslovit!
Pročpak? A co je to "slušný programátor".
Pokud by mi těžce šlo o to, aby oba parametry byly Stringy, tak si to prostě ověřím a případně vyhodím výjimku (když už na tom tak trváte). V C si taky ověřuji, jestli pointer není NULL.
Však C je také slabě typovaný jazyk. Prpblém v JS, že samotné ověřování typů není dostatečné, protože JS s nimi pracuje špatně, viz řada už uvedených příkladů:
'aa' == 'aa'
'aa' == new String('aa')
new String('aa') == new String('aa')
{} == {}
-
Pročpak? A co je to "slušný programátor".
Potřeba podívat se co je uvnitř je znakem blbě napsané rutiny.
Zvyk, dívat se dovnitř je znakem špatného programátora.
Ale obávám se, že toto nejde dokázat. Buď máte zkušenosti, a pak je vám to jasné, a nebo nemáte, a pak mi nevěříte.
-
Třeba v tom, že to je 1) nepodstatné a 2) bezpředmětné. Ad 1) Hlavní rozdíl mezi statickým a dynamickým je v tom, že statické typy se kontrolují už při překladu. Ad 2) javascriptu není vyčítáno to, že nemá statické typy, ale jeho hloupé chování v řadě případů.
Takže když do staticky typovaného jazyka narveš nevalidní data, tak nespadne?
Kde jsi takovou blbost vyčetl?
To není blbost, ale řečnická otázka. Při překladu nevalidní vstupní data nezkontroluješ, musíš je zkontrolovat až za běhu.
Ptáš se způsobem, jakobych takovou blbost napsal já. Při překladu se kontroluje práce s typy, nikoliv validita vstupních data. To porovnáváš hrušky a jabka.
-
Třeba v tom, že to je 1) nepodstatné a 2) bezpředmětné. Ad 1) Hlavní rozdíl mezi statickým a dynamickým je v tom, že statické typy se kontrolují už při překladu. Ad 2) javascriptu není vyčítáno to, že nemá statické typy, ale jeho hloupé chování v řadě případů.
Takže když do staticky typovaného jazyka narveš nevalidní data, tak nespadne?
Kde jsi takovou blbost vyčetl?
To není blbost, ale řečnická otázka. Při překladu nevalidní vstupní data nezkontroluješ, musíš je zkontrolovat až za běhu.
Ptáš se způsobem, jakobych takovou blbost napsal já. Při překladu se kontroluje práce s typy, nikoliv validita vstupních data. To porovnáváš hrušky a jabka.
Vstupní data přece také musí být nějakého typu.
-
Jinak je ti doufám jasné, že i v JavaScriptu taky můžeš hlídat, jestli jsi dostal číslo, nebo string
Jen za běhu. Fakt budeš "kopat" základy lžičkou, když můžeš použít bagr?
Jistě, v interpretovaných jazycích se tak nějak věci za běhu kontrolují... :D
Interpretovanost nijak nesouvisí s typováním.
Ano, dobrý point - chtěl jsem napsat dynamických (~dynamicky typovaných). Moje chyba. :)
Pak to ale není argument. 1. “Java umí kontrolovat typy na vstupu při překladu - před během.” 2. “V JS taky jdou kontrolovat typy na vstupu.”
Zaprvé se koukni na to, jak šly "argumenty" po sobě. Zadruhé Java je dynamicky typovaná?
Jednak si můžeš zjistit, co uvnitř je, ...
Tohle by slušný programátor nemohl ani vyslovit!
Pročpak? A co je to "slušný programátor".
Pokud by mi těžce šlo o to, aby oba parametry byly Stringy, tak si to prostě ověřím a případně vyhodím výjimku (když už na tom tak trváte). V C si taky ověřuji, jestli pointer není NULL.
Však C je také slabě typovaný jazyk. Prpblém v JS, že samotné ověřování typů není dostatečné, protože JS s nimi pracuje špatně, viz řada už uvedených příkladů:
'aa' == 'aa'
'aa' == new String('aa')
new String('aa') == new String('aa')
{} == {}
Problém je, že tvrdíš, že ověřování typů není dostatečné, ale jako příklad uvádíš něco, co typ neověřuje...
Pročpak? A co je to "slušný programátor".
Potřeba podívat se co je uvnitř je znakem blbě napsané rutiny.
Zvyk, dívat se dovnitř je znakem špatného programátora.
Ale obávám se, že toto nejde dokázat. Buď máte zkušenosti, a pak je vám to jasné, a nebo nemáte, a pak mi nevěříte.
Možná to díky citacím vypadlo z kontextu, ale "uvnitř" je tu použito ve smyslu "uvnitř proměnné". Nevím, co je zlého na tomto:
let x = 100;
let y = "ahoj";
typeof x;
typeof y;
A v jakém smyslu se to liší od tohoto?
if (ptr == NULL)
Z jakého důvodu by to ze mě mělo dělat špatného programátora?
-
Funny je, že musí přijít @Kit a mluvit k tématu. Zase se po nějaké době shodneme. :)
-
Možná to díky citacím vypadlo z kontextu, ale "uvnitř" je tu použito ve smyslu "uvnitř proměnné". Nevím, co je zlého na tomto:
let x = 100;
let y = "ahoj";
typeof x;
typeof y;
A v jakém smyslu se to liší od tohoto?
if (ptr == NULL)
Z jakého důvodu by to ze mě mělo dělat špatného programátora?
Tak takhle je to v pořádku. Zdá se, že jsem tě špatně pochopil. Omlouvám se.
Narážel jsem na tohle:
def format(a, b):
return a + b
format(1, 2)
Špatný název protože "tak se kouknu dovnitř, co to dělá, že jo".
-
Funny je, že musí přijít @Kit a mluvit k tématu. Zase se po nějaké době shodneme. :)
Kit a k tématu? Ano, to je Funny.
-
Narážel jsem na tohle:
def format(a, b):
return a + b
format(1, 2)
Špatný název protože "tak se kouknu dovnitř, co to dělá, že jo".
Ne, to by bylo fakt nepěkné. :)
Funny je, že musí přijít @Kit a mluvit k tématu. Zase se po nějaké době shodneme. :)
Kit a k tématu? Ano, to je Funny.
Možná, ale často tu měl teď point. :)
-
Třeba v tom, že to je 1) nepodstatné a 2) bezpředmětné. Ad 1) Hlavní rozdíl mezi statickým a dynamickým je v tom, že statické typy se kontrolují už při překladu. Ad 2) javascriptu není vyčítáno to, že nemá statické typy, ale jeho hloupé chování v řadě případů.
Takže když do staticky typovaného jazyka narveš nevalidní data, tak nespadne?
Kde jsi takovou blbost vyčetl?
To není blbost, ale řečnická otázka. Při překladu nevalidní vstupní data nezkontroluješ, musíš je zkontrolovat až za běhu.
Ptáš se způsobem, jakobych takovou blbost napsal já. Při překladu se kontroluje práce s typy, nikoliv validita vstupních data. To porovnáváš hrušky a jabka.
Vstupní data přece také musí být nějakého typu.
To je a) marginalni, pri validaci dat kontrolujes predevsim hodnoty, b) vstupni data jsou vetsinou text, ktery po jejích valádaci teprve prevadis na prislusne datove typy.
-
Jinak je ti doufám jasné, že i v JavaScriptu taky můžeš hlídat, jestli jsi dostal číslo, nebo string
Jen za běhu. Fakt budeš "kopat" základy lžičkou, když můžeš použít bagr?
Jistě, v interpretovaných jazycích se tak nějak věci za běhu kontrolují... :D
Interpretovanost nijak nesouvisí s typováním.
Ano, dobrý point - chtěl jsem napsat dynamických (~dynamicky typovaných). Moje chyba. :)
Pak to ale není argument. 1. “Java umí kontrolovat typy na vstupu při překladu - před během.” 2. “V JS taky jdou kontrolovat typy na vstupu.”
Zaprvé se koukni na to, jak šly "argumenty" po sobě. Zadruhé Java je dynamicky typovaná?
Jednak si můžeš zjistit, co uvnitř je, ...
Tohle by slušný programátor nemohl ani vyslovit!
Pročpak? A co je to "slušný programátor".
Pokud by mi těžce šlo o to, aby oba parametry byly Stringy, tak si to prostě ověřím a případně vyhodím výjimku (když už na tom tak trváte). V C si taky ověřuji, jestli pointer není NULL.
Však C je také slabě typovaný jazyk. Prpblém v JS, že samotné ověřování typů není dostatečné, protože JS s nimi pracuje špatně, viz řada už uvedených příkladů:
'aa' == 'aa'
'aa' == new String('aa')
new String('aa') == new String('aa')
{} == {}
Problém je, že tvrdíš, že ověřování typů není dostatečné, ale jako příklad uvádíš něco, co typ neověřuje...
To jsi to zase nepochopil. Takže srozumitelněji, problém v js je, že ani ruční ověřování typů není dostatečné, protože JS s těmi datovými typy stejně pracuje špatně. Prostě problém JS jení v slabém typování, ale v tom, že ho má špatně implementované, je nekonzistentní a s datovými typy zachází nesmyslně.
-
Vstupní data přece také musí být nějakého typu.
To je a) marginalni, pri validaci dat kontrolujes predevsim hodnoty, b) vstupni data jsou vetsinou text, ktery po jejích valádaci teprve prevadis na prislusne datove typy.
Jenže to už neuděláš při kompilaci, ale až za běhu. Teprve za běhu zjistíš, je je v nich chyba. Tohle ti statické typování neodchytí. No a pak je otázkou, zda tyto chyby odchytávat před voláním funkce, v dekorátoru nebo až ve funkci.
Myslím si, že marginální to není. Programátoři tohle řeší dnes a denně.
-
To jsi to zase nepochopil. Takže srozumitelněji, problém v js je, že ani ruční ověřování typů není dostatečné, protože JS s těmi datovými typy stejně pracuje špatně. Prostě problém JS jení v slabém typování, ale v tom, že ho má špatně implementované, je nekonzistentní a s datovými typy zachází nesmyslně.
Problém Javascriptu je hlavně v tom, že sis nepřečetl manuál.
-
Vstupní data přece také musí být nějakého typu.
To je a) marginalni, pri validaci dat kontrolujes predevsim hodnoty, b) vstupni data jsou vetsinou text, ktery po jejích valádaci teprve prevadis na prislusne datove typy.
Jenže to už neuděláš při kompilaci, ale až za běhu. Teprve za běhu zjistíš, je je v nich chyba. Tohle ti statické typování neodchytí. No a pak je otázkou, zda tyto chyby odchytávat před voláním funkce, v dekorátoru nebo až ve funkci.
Myslím si, že marginální to není. Programátoři tohle řeší dnes a denně.
Co jsi nepochopil na vyjádření: Při překladu se kontroluje práce s typy, nikoliv validita vstupních data. To porovnáváš hrušky a jabka.
-
To jsi to zase nepochopil. Takže srozumitelněji, problém v js je, že ani ruční ověřování typů není dostatečné, protože JS s těmi datovými typy stejně pracuje špatně. Prostě problém JS jení v slabém typování, ale v tom, že ho má špatně implementované, je nekonzistentní a s datovými typy zachází nesmyslně.
Problém Javascriptu je hlavně v tom, že sis nepřečetl manuál.
Za prvé to nevíš, za druhé lžeš a za třetí problémy JS jsou nezávislé na mě a na tom, co já si přečtu nebo ne.
-
Tady se přidám ke Kitovi - fakt si ten manuál přečti.
V JS operátor == nemá význam "porovnej 'a' a 'b' podle obsahu", ale "porovnej 'a' a 'b' a v případě potřeby je přetypuj". V tom je jádro problému.
'aa' == new String('aa')
Tady porovnáváš hodnotu s objektem. No a objekt není hodnota. Je to sice nešťastné, ale je to tak právě proto, že to je konzistentní se zbytkem. Samozřejmě by to mohlo být lepší, ale na webu má zpětná kompatibilita takovou prioritu, takže třeba změny chování operátoru pro porovnání nepřipadají moc v úvahu. Pokud se s tím někdo smířit nedokáže, tak má na výběr ze stovek transpilovaných jazyků. Každopádně vytvářet řetězce pomocí new String jsem snad ani nikde neviděl, nikdo to nepoužívá.
new String('aa') == new String('aa')
{} == {}
Tady zase porovnáváš objekt s objektem. No a shodné objekty to nejsou. Tzn. je to konzistentní.
-
Omlouvám se, v prvním jsem přehlídl, že to není ===. Význam je ale pořád stejný.
-
new String('aa') == new String('aa')
{} == {}
Tady zase porovnáváš objekt s objektem. No a shodné objekty to nejsou. Tzn. je to konzistentní.
Tady někde je tuším ta hranice, kdy se přepíná mezi porovnávání hodnoty, a porovnávání identity. Což je další matení nepřítele, že si se dvěma oparátory (== a ===) vlastně furt nevystačíš.
-
new String('aa') == new String('aa')
{} == {}
Tady zase porovnáváš objekt s objektem. No a shodné objekty to nejsou. Tzn. je to konzistentní.
Tady někde je tuším ta hranice, kdy se přepíná mezi porovnávání hodnoty, a porovnávání identity. Což je další matení nepřítele, že si se dvěma oparátory (== a ===) vlastně furt nevystačíš.
Ne, to bych neřekl. Ono totiž není úplně snadné říct, kdy jsou si objekty rovny... :)
-
new String('aa') == new String('aa')
{} == {}
Tady zase porovnáváš objekt s objektem. No a shodné objekty to nejsou. Tzn. je to konzistentní.
Tady někde je tuším ta hranice, kdy se přepíná mezi porovnávání hodnoty, a porovnávání identity. Což je další matení nepřítele, že si se dvěma oparátory (== a ===) vlastně furt nevystačíš.
Ne, to bych neřekl. Ono totiž není úplně snadné říct, kdy jsou si objekty rovny... :)
A co by si řekl?
Pokud se nehraje na identitu, tak mi to přijde krásně čisté:
1 == 1
"1" == "1"
{} == {}
{x: 1} == {x: 1}
new String("x") == new String("x")
Má to spoustu pěknejch důsledků. (A taky pár podrazů.)
-
Teď nevím, co se tím pokoušíš říct...
-
Problemy v praxi: dynamicnost jazyka a nejasna specifikace jazyka/nekolik verzi. (Takove ty legrace s `==`, `+`, `undefined`/`null`, `this`... uz asi zaznely)
Na jednu stranu je super, ze v JS velice rychle napisete aplikaci... smekam! Jenze jsem zatim nevidel aplikaci psanou v JS, ktera by casem nepozrala sama sebe. Nejvetsi bolistka je dynamicnost jazyka - pokud potrebuji neco zmenit/pridat/opravit, vzdy musim aplikaci lokalne spustit, pripojit debugger a podivat se, co mi proteka v parametrech - az pak mohu zacit realne pracovat. Vzdy, kdyz jsem neco psal v JS, jen debugovanim kodu jsem zabil spoustu casu a porad dokola - spustit, breakpoint, watch, zmena kodu, repeat...
Ke specifikaci: kdyz jsem s JS zacinal, poctive jsem si nastudoval specifikaci Ecma Scriptu (vim, neni to to same!). A pak prisel prvni import a ja byl v koncich. Nakonec jsem dohledal asi ctyri ruzne zpusoby, jak neco imporotvat, zadny ale neodpovidal tomu, co jsem se drive naucil. Byl to moc hezky zacatek, vzdy mi ukapne slzicka, kdyz si na to vzpomenu.
-
Teď nevím, co se tím pokoušíš říct...
1, "x" - jsou pouze hodnoty. Nemají identitu.
new Int(1), new String("x") - mají navíc identitu. Tudíž se v některých jazycích platí:
new Int(1) != new Int(1)
Což není hezké.
-
Tak ja teda neviem... Facebook, Netflix či Uber by podľa vašich kydov nemali vlastne fungovať. Uber už vôbec nie, keďže nepoužívajú vo svojom frameworku TypeScript. Vlastne aj kopec iných mega projektov Fortune500 firiem vlastne nemá fungovať, a ešte ich aj riadia idioti frčiaci na Reacte či Angulare. A programovať vedia len miestne esá. My, ktorí máme radi JS sme vlastne len lopaty, lepiči a pod. Hm. Nejak mi tu však nesedí. Obzvlášť to, že JS seniori sú už lepšie platení ako C# lopaty a siahajú platovo už na Java seniorov. Ale tak asi iba niečo prehliadam. Veď čo ja môžem vedieť s 25 rokmi praxe. Vedia len tí, čo ani len nemajú toľko rokov čo ja tej praxe. Holt, svet patrí mladým... :D:D:D:D
-
... Obzvlášť to, že JS seniori sú už lepšie platení ako C# lopaty a siahajú platovo už na Java seniorov. ...
Ono jestli to neni spise poptavkou nez kvalitou vyvojaru. Zatimco treba v C# se povazuje za zaklad znalost GC, asynchronniho programovani, paralelismu, multithreadingu, zamykani/synchronizace, ... a buhvi co jeste, v JS tohle clovek vubec neresi. Neznam moc JS vyvojaru, kteri vubec vidi do hloubky (ani nemaji poneti, jak funguje event loop!), ale ten kod proste vysypou. Nehodnotim, kdo je lepsi/horsi, poptavka je po jednom a podle vyse platu usuzovat nelze (... jinak by samozrejme C# vyvojari brali nejvice ;)).
JS nekomu sende, nekomu ne, je to asi hodne o zvyku a zpusobu mysleni. Nekdo se v dynamickem jazyce ztraci, jiny povazuje typovy system za prilis restriktivni - a to tak nejak vidim v diskusi. Problemy existuji, nekomu nevadi, nekdo je povazuje za featuru, a pro nekoho jsou proste no-go.
-
Tady se přidám ke Kitovi - fakt si ten manuál přečti.
V JS operátor == nemá význam "porovnej 'a' a 'b' podle obsahu", ale "porovnej 'a' a 'b' a v případě potřeby je přetypuj". V tom je jádro problému.
'aa' == new String('aa')
Tady porovnáváš hodnotu s objektem. No a objekt není hodnota. Je to sice nešťastné, ale je to tak právě proto, že to je konzistentní se zbytkem. Samozřejmě by to mohlo být lepší, ale na webu má zpětná kompatibilita takovou prioritu, takže třeba změny chování operátoru pro porovnání nepřipadají moc v úvahu. Pokud se s tím někdo smířit nedokáže, tak má na výběr ze stovek transpilovaných jazyků. Každopádně vytvářet řetězce pomocí new String jsem snad ani nikde neviděl, nikdo to nepoužívá.
new String('aa') == new String('aa')
{} == {}
Tady zase porovnáváš objekt s objektem. No a shodné objekty to nejsou. Tzn. je to konzistentní.
Ten 'manuál' si přečti sám :-), vždyť ty ani nevíš co to dělá. Já vím nejen jak, ale i proč to tak funguje a považuji to za velmí špatně vymyšlené a navržené, neznám žádný jazyk, který by se choval hůř než javascript.
Takže 'aa' == 'aa' // true, porovnavam hodnoty
'aa' == new Script('aa') // true, protože přetypování objektu na string
new String('aa') == new String('aa') // false, porovnavam typy
{} == {} // syntax error
Až tak blbý JS je.
-
new String('aa') == new String('aa')
{} == {}
Tady zase porovnáváš objekt s objektem. No a shodné objekty to nejsou. Tzn. je to konzistentní.
Tady někde je tuším ta hranice, kdy se přepíná mezi porovnávání hodnoty, a porovnávání identity. Což je další matení nepřítele, že si se dvěma oparátory (== a ===) vlastně furt nevystačíš.
Ne, to bych neřekl. Ono totiž není úplně snadné říct, kdy jsou si objekty rovny... :)
Tak proč tedy JS tedy říká, kdy si je objekt roven s primitivním typem? Blbost JS je neobhajitelná a nevysvětlitelná.
-
Teď nevím, co se tím pokoušíš říct...
Máš vysvětlit, proč to JS má navrženo tak blbě a nekonzistentně.
-
Tak proč tedy JS tedy říká, kdy si je objekt roven s primitivním typem? Blbost JS je neobhajitelná a nevysvětlitelná.
Ale JS nic takového neříká.
Všichni kdo JS znají přece vědí, že když se při == porovnávání typy porovnávaných operandů neshodují, tak JS bude AUTOMATICKY přetypovávat jednu ze stran na typ té druhé a porovnávat HODNOTY až po přetypování. A primitivní typy mají samozřejmě přednost před objekty, protože porovnávat dva objekty je nesmysl (vrátí vždy false).
Takže JS pouze říká, že hodnota uvnitř String objektu je shodná s primitivním stringem.
Totéž zapsané explicitně (ruční přetypování + kontrola typu): new String('xx').valueOf() === 'xx' //true
Pravdu bys měl, kdyby se tak JS choval při použití === kde k přetypování nedojde.
-
Ale JS nic takového neříká.
Všichni kdo JS znají přece vědí, že když se při == porovnávání typy porovnávaných operandů neshodují, tak JS bude AUTOMATICKY přetypovávat jednu ze stran na typ té druhé a porovnávat HODNOTY až po přetypování.
Tak oni to tu někteří i vědí. Jen s tím nesouhlasí.
A primitivní typy mají samozřejmě přednost před objekty, protože porovnávat dva objekty je nesmysl (vrátí vždy false).
A proč by mělo být porovnávání dvou objektů nesmysl?
var a = {}
var b = {}
var c = a
a == b // false
a == c // true
-
Tak ja teda neviem... Facebook, Netflix či Uber by podľa vašich kydov nemali vlastne fungovať. Uber už vôbec nie, keďže nepoužívajú vo svojom frameworku TypeScript. Vlastne aj kopec iných mega projektov Fortune500 firiem vlastne nemá fungovať, a ešte ich aj riadia idioti frčiaci na Reacte či Angulare. A programovať vedia len miestne esá. My, ktorí máme radi JS sme vlastne len lopaty, lepiči a pod. Hm. Nejak mi tu však nesedí. Obzvlášť to, že JS seniori sú už lepšie platení ako C# lopaty a siahajú platovo už na Java seniorov. Ale tak asi iba niečo prehliadam. Veď čo ja môžem vedieť s 25 rokmi praxe. Vedia len tí, čo ani len nemajú toľko rokov čo ja tej praxe. Holt, svet patrí mladým... :D:D:D:D
To nikdo nerika, ze by nemely fungovat. Prehlizis to, ze rec je o tom, ze JS je spatne navrzeny jazyk se spoustou problemu, který ale má monopol na webu a kvuli tomu se bohuzel rozsiril. Ale i se spatnym nastrojem lze tvorit, nakonec to tak tady dela kazdy z nas. Ale to neni duvod pro to, abychom ty chyby nepojmenovali.
-
Tak proč tedy JS tedy říká, kdy si je objekt roven s primitivním typem? Blbost JS je neobhajitelná a nevysvětlitelná.
Ale JS nic takového neříká.
Všichni kdo JS znají přece vědí, že když se při == porovnávání typy porovnávaných operandů neshodují, tak JS bude AUTOMATICKY přetypovávat jednu ze stran na typ té druhé a porovnávat HODNOTY až po přetypování. A primitivní typy mají samozřejmě přednost před objekty, protože porovnávat dva objekty je nesmysl (vrátí vždy false).
Takže JS pouze říká, že hodnota uvnitř String objektu je shodná s primitivním stringem.
Totéž zapsané explicitně (ruční přetypování + kontrola typu): new String('xx').valueOf() === 'xx' //true
Pravdu bys měl, kdyby se tak JS choval při použití === kde k přetypování nedojde.
Ale jo, presne to JS rika. Argument ze neni snadne rict kdy jsou si objekty rovny je klamny.
Kdyz js muze rict, ze jsou si rovny 'aa' a new String('aa'), tak uplne stejne by mohl rict, ze jsou si rovny new String('aa') a new String('aa'). A pokud prijmeme tezi, ze vnitrni stav objektu je slozity a je tezke je porívnavat, pak by melo byt stejne tezke je porovnavat s cimkoliv. Z toho plyne, ze navrh chovani JS je nekonzistentni a proto spatny.
Neexistuje rozumny duvod, proc se v jednom pripade vniřrni hodnota objektu porovnava a v druhem ne. Zrovna tak neexistuje duvod, proc se pri trideni pole ciselntyto vsechny prevedíu na stríngy, zvlaste kdyz se pri normalnim porovhavani stringy prevadi na cisla, je to opet jen vysledek spatneho nekonzistentniho havrhu JS.
-
A primitivní typy mají samozřejmě přednost před objekty, protože porovnávat dva objekty je nesmysl (vrátí vždy false).
Takže JS pouze říká, že hodnota uvnitř String objektu je shodná s primitivním stringem.
Ty rikas jak to je, ale to neni argument na nase tvrzeni, ze je to navrzeno spatne.
Primitivni typy == chybny navrh, cistejsi koncept je mit navenek vsechno je objekt, pak nebudes mit primitivni a objektove stringy. Syntaxe 'neco' by mel byt jennsyntakticky cukr pro zapis new String('neco'). JS tonproste dela blbe.
Porovnavat dva objekty je nesmysl pouze v JS v dusledku jeho spatneho navrhu. Nemoznost porovnat dva objekty je stejne inteligentni jako nemoznost porovnat dva jednoduche promenne (coz v nekterych jazycich je ostatne jedno a to same). V rozumne navrzenych jazycich si to proto muzes lehce zaridit i u vlastnich objektu/datovych typu.
bash-4.4$ cat cmpobj.py
class Obj(object):
def __init__(self, data=None):
self.data = data
def __eq__(self, other):
if isinstance(other, Obj):
return self.data == other.data
return False
a = Obj()
b = Obj()
c = Obj('aa')
d = Obj('aa')
e = Obj('bb')
bash-4.4$ python -i cmpobj.py
>>> a == a
True
>>> a == b
True
>>> a is a
True
>>> a is b
False
>>> c == d
True
>>> c == e
False
>>>
Vidis? Zadny problem pri porovnani objektu, je to konzistentni, predvidatelne a prehledne. A dle stejnych pravidel se to zachova i pri serazeni v poli, nema to jina nekonzistentni pravidla. Stejne tak si mohu jednoznacne zvolit, zda chci porovnat hodnotu nebo identitu. Tak vypada kvalitni navrh jazyka.
Ano, pouziti == v JS znamena, ze se nekdy porovnavaji typy a nekdy hodnoty, tj nekdy ma == stejny vyznam jako === a nekdy ne. Dalsi príklad spatneho nekonzistentniho navrhu.
-
K původnímu tématu a specificky k již zmíněnému stupidnímu návrhu async/await: http://journal.stuffwithstuff.com/2015/02/01/what-color-is-your-function/
-
Môže mi niekto napísať nekonzistentnosti v návrhu JS od verzie ES5? Lebo kritici sa tu ako slamky chytajú len problémov ktoré sú staré snáď 20 rokov a boli zanechané len kvôli spätnej kompatibilite, aby aj 15 ročná stránka so "super DHTML efektami" fungovala aj dnes, čo však neznamená, že máte JS aj dnes používať takým spôsobom. Preto keď už, ukážte zlý návrh vo verzii ES5 a vyššie, v modernom JS. Vopred vďaka za vaše postrehy.
-
Môže mi niekto napísať nekonzistentnosti v návrhu JS od verzie ES5? Lebo kritici sa tu ako slamky chytajú len problémov ktoré sú staré snáď 20 rokov a boli zanechané len kvôli spätnej kompatibilite, aby aj 15 ročná stránka so "super DHTML efektami" fungovala aj dnes, čo však neznamená, že máte JS aj dnes používať takým spôsobom. Preto keď už, ukážte zlý návrh vo verzii ES5 a vyššie, v modernom JS. Vopred vďaka za vaše postrehy.
async/await, viď odkaz výše
-
Môže mi niekto napísať nekonzistentnosti v návrhu JS od verzie ES5? Lebo kritici sa tu ako slamky chytajú len problémov ktoré sú staré snáď 20 rokov a boli zanechané len kvôli spätnej kompatibilite, aby aj 15 ročná stránka so "super DHTML efektami" fungovala aj dnes, čo však neznamená, že máte JS aj dnes používať takým spôsobom. Preto keď už, ukážte zlý návrh vo verzii ES5 a vyššie, v modernom JS. Vopred vďaka za vaše postrehy.
async/await, viď odkaz výše
Async / await je len syntaktický cukor nad Promises plus generátor funkcia. Bol to veľmi obľúbený pattern, tak ho zaviedli priamo do jazyka. Niektorí ho ani len nepoužívajú. Veď napokon, nikto v žiadnom jazyku nevyužíva všetky možnosti poskytované jazykom. Ten článok je len tendenčný a zbytočný. Povedz mi radšej čo tebe konkrétne vadí na async / await a prečo to považuješ za chybu, zlý návrh.
-
Takže když do staticky typovaného jazyka narveš nevalidní data, tak nespadne?
No, v principu by neměl, protože by to při chroustání těch vstupních dat mělo vyhlásit, že ta data jsou chybná. Což samozřejmě může klidně být uděláno i v dynamickém jazyku, akorát tam se to moc nevynucuje.
Např. ve staticky typovaném jazyku se JSON na vstupu dekóduje do nějaké Class. To je operace, která může selhat (třeba z důvodu chybějících políček, špatných typů apod.) a mělo by se to ošetřit. "Nedekódovat to" je v podstatě práce navíc. V dynamicky typovaném (JS) se udělá JSON.decode a je to. "Zkontrolovat to" je práce navíc.
Takže když má funkce jako parametr string, ve kterém očekává číslo (např. z terminálu) a někdo tam zadá slovo, tak to stejně musíš uvnitř té funkce ošetřit, aby při konverzi na číslo ten proces nespadl.
Podobně je na tom i parametr int, ve kterém má být třeba číslo měsíce 1-12. Jen málo jazyků má pro tohle typ, např. Pascal a předpokládám, že i Haskell. Tím se ovšem přesouvá validace vstupu ven z funkce. Otázkou je: Opravdu chceme validovat vstupní data ještě před každým voláním funkce nebo si je raději zvalidujeme na jednom místě uvnitř?
Ano, chceme. A třeba pokud jde o měsíce, tak "enum" má snad prakticky každý typovaný jazyk včetně Javy.
Funkce, které pracují s měsíců pak vyžadují nějaký typ Month, a při zpracování vstupu musíš provést konverzni String->Month a případně ošetřit, pokud to selže. Funkce pracující s měsícem má pak naprost jasně definovaný vstupní typ a na jedné straně velmi snadno ověříš při psaní té funkce, že dělá to co má, protože to je nezávislé na tom, kdo ji kde jak volá, z druhé strany je to skvělá dokumentace a při případném refaktoringu pak kompiler dost pomůže.
-
Takže když do staticky typovaného jazyka narveš nevalidní data, tak nespadne?
No, v principu by neměl, protože by to při chroustání těch vstupních dat mělo vyhlásit, že ta data jsou chybná. Což samozřejmě může klidně být uděláno i v dynamickém jazyku, akorát tam se to moc nevynucuje.
Např. ve staticky typovaném jazyku se JSON na vstupu dekóduje do nějaké Class. To je operace, která může selhat (třeba z důvodu chybějících políček, špatných typů apod.) a mělo by se to ošetřit. "Nedekódovat to" je v podstatě práce navíc. V dynamicky typovaném (JS) se udělá JSON.decode a je to. "Zkontrolovat to" je práce navíc.
Takže když má funkce jako parametr string, ve kterém očekává číslo (např. z terminálu) a někdo tam zadá slovo, tak to stejně musíš uvnitř té funkce ošetřit, aby při konverzi na číslo ten proces nespadl.
Podobně je na tom i parametr int, ve kterém má být třeba číslo měsíce 1-12. Jen málo jazyků má pro tohle typ, např. Pascal a předpokládám, že i Haskell. Tím se ovšem přesouvá validace vstupu ven z funkce. Otázkou je: Opravdu chceme validovat vstupní data ještě před každým voláním funkce nebo si je raději zvalidujeme na jednom místě uvnitř?
Ano, chceme. A třeba pokud jde o měsíce, tak "enum" má snad prakticky každý typovaný jazyk včetně Javy.
Funkce, které pracují s měsíců pak vyžadují nějaký typ Month, a při zpracování vstupu musíš provést konverzni String->Month a případně ošetřit, pokud to selže. Funkce pracující s měsícem má pak naprost jasně definovaný vstupní typ a na jedné straně velmi snadno ověříš při psaní té funkce, že dělá to co má, protože to je nezávislé na tom, kdo ji kde jak volá, z druhé strany je to skvělá dokumentace a při případném refaktoringu pak kompiler dost pomůže.
Zrovna u datumu je poučné napsat si typ pro validní hodnoty, tj. nikdy nemám 30. února a 29. února jen někdy apod. To otevírá oči.
-
Môže mi niekto napísať nekonzistentnosti v návrhu JS od verzie ES5? Lebo kritici sa tu ako slamky chytajú len problémov ktoré sú staré snáď 20 rokov a boli zanechané len kvôli spätnej kompatibilite, aby aj 15 ročná stránka so "super DHTML efektami" fungovala aj dnes, čo však neznamená, že máte JS aj dnes používať takým spôsobom. Preto keď už, ukážte zlý návrh vo verzii ES5 a vyššie, v modernom JS. Vopred vďaka za vaše postrehy.
async/await, viď odkaz výše
Async / await je len syntaktický cukor nad Promises plus generátor funkcia. Bol to veľmi obľúbený pattern, tak ho zaviedli priamo do jazyka. Niektorí ho ani len nepoužívajú. Veď napokon, nikto v žiadnom jazyku nevyužíva všetky možnosti poskytované jazykom. Ten článok je len tendenčný a zbytočný. Povedz mi radšej čo tebe konkrétne vadí na async / await a prečo to považuješ za chybu, zlý návrh.
Wal-de-mar pattern:
1) Jaký je praktický problém s JS?
2) Počkám na odpověď
3) Odpověď je tendenční a zbytečná, nepřečetl sis manuál, je to plně specifikované, od čeho máme code review.
-
Môže mi niekto napísať nekonzistentnosti v návrhu JS od verzie ES5? Lebo kritici sa tu ako slamky chytajú len problémov ktoré sú staré snáď 20 rokov a boli zanechané len kvôli spätnej kompatibilite, aby aj 15 ročná stránka so "super DHTML efektami" fungovala aj dnes, čo však neznamená, že máte JS aj dnes používať takým spôsobom. Preto keď už, ukážte zlý návrh vo verzii ES5 a vyššie, v modernom JS. Vopred vďaka za vaše postrehy.
async/await, viď odkaz výše
Async / await je len syntaktický cukor nad Promises plus generátor funkcia. Bol to veľmi obľúbený pattern, tak ho zaviedli priamo do jazyka. Niektorí ho ani len nepoužívajú. Veď napokon, nikto v žiadnom jazyku nevyužíva všetky možnosti poskytované jazykom. Ten článok je len tendenčný a zbytočný. Povedz mi radšej čo tebe konkrétne vadí na async / await a prečo to považuješ za chybu, zlý návrh.
Wal-de-mar pattern:
1) Jaký je praktický problém s JS?
2) Počkám na odpověď
3) Odpověď je tendenční a zbytečná, nepřečetl sis manuál, je to plně specifikované, od čeho máme code review.
Ok, tak to upresním. Článok ktorý si nalinkoval nadáva na JavaScript, lebo JS nepracuje s asynchrónnymi funkciami rovnako ako Go jazyk... Ten autor je snáď idiot. No jasne, že starší jazyk nemá vlastnosti ktoré má novšie navrhnutý jazyk. Navyše kompletne iného typu, staticky typovaný, kompilovaný, oproti dynamicky typovanému, interpretovanému. Preto sa ťa pýtam na tvoj názor prečo je async / await zle navrhnutý a ako by si to implementoval ty, so zachovaním spätnej kompatibility. Alebo ste fakt všetci len vytreté nuly bez nadhľadu a dokážete sa len opičiť po iných vytretých nulách a kopírovať jeden od druhého nezmyselné argumenty? Alebo ste fakt programátori? Ak programátori, ukážte mi iný, lepšie navrhnutý jazyk do asynchrónneho prostredia, rovnako starý, stále spätne kompatibilný s prvou verziou, interpretovaný, nie kompilovaný. Inak tu len stále budete miešať hrušky s jablkami bez čo len náznaku kritického myslenia, ako nemysliace ovce čo si preposielajú konšpiračné teórie ktoré reflektujú ich presvedčenie, nie znalosti.
-
Ok, tak to upresním. Článok ktorý si nalinkoval nadáva na JavaScript, lebo JS nepracuje s asynchrónnymi funkciami rovnako ako Go jazyk... Ten autor je snáď idiot. No jasne, že starší jazyk nemá vlastnosti ktoré má novšie navrhnutý jazyk. Navyše kompletne iného typu, staticky typovaný, kompilovaný, oproti dynamicky typovanému, interpretovanému. Preto sa ťa pýtam na tvoj názor prečo je async / await zle navrhnutý a ako by si to implementoval ty, so zachovaním spätnej kompatibility. Alebo ste fakt všetci len vytreté nuly bez nadhľadu a dokážete sa len opičiť po iných vytretých nulách a kopírovať jeden od druhého nezmyselné argumenty? Alebo ste fakt programátori? Ak programátori, ukážte mi iný, lepšie navrhnutý jazyk do asynchrónneho prostredia, rovnako starý, stále spätne kompatibilný s prvou verziou, interpretovaný, nie kompilovaný. Inak tu len stále budete miešať hrušky s jablkami bez čo len náznaku kritického myslenia, ako nemysliace ovce čo si preposielajú konšpiračné teórie ktoré reflektujú ich presvedčenie, nie znalosti.
Rad bych ukazal, ale autor vlakna to zakazal...
1. Že je iný ako nejaký iný jazyk neznamená, že to je problém s JS. To len znamená, že je proste iný. Zrovnania sem nepatria.
-
Preto sa ťa pýtam na tvoj názor prečo je async / await zle navrhnutý a ako by si to implementoval ty, so zachovaním spätnej kompatibility.
Aha, tak k bodu 3) jsem zapomněl dodat výmluvu "ale javascript byl navrhnut děsně dávno".... Prostě praktický problém není problémem, protože jazyk je straašně starý, je tam snaha být zpětně kompatibilní atd.....
-
Zásadním problémem JS taky je, že Ryan Dahl (autor node.js) ho kritizuje a místo node.js doporučuje Go.
-
Môže mi niekto napísať nekonzistentnosti v návrhu JS od verzie ES5? Lebo kritici sa tu ako slamky chytajú len problémov ktoré sú staré snáď 20 rokov a boli zanechané len kvôli spätnej kompatibilite, aby aj 15 ročná stránka so "super DHTML efektami" fungovala aj dnes, čo však neznamená, že máte JS aj dnes používať takým spôsobom. Preto keď už, ukážte zlý návrh vo verzii ES5 a vyššie, v modernom JS. Vopred vďaka za vaše postrehy.
async/await, viď odkaz výše
Async / await je len syntaktický cukor nad Promises plus generátor funkcia. Bol to veľmi obľúbený pattern, tak ho zaviedli priamo do jazyka. Niektorí ho ani len nepoužívajú. Veď napokon, nikto v žiadnom jazyku nevyužíva všetky možnosti poskytované jazykom. Ten článok je len tendenčný a zbytočný. Povedz mi radšej čo tebe konkrétne vadí na async / await a prečo to považuješ za chybu, zlý návrh.
Wal-de-mar pattern:
1) Jaký je praktický problém s JS?
2) Počkám na odpověď
3) Odpověď je tendenční a zbytečná, nepřečetl sis manuál, je to plně specifikované, od čeho máme code review.
Ok, tak to upresním. Článok ktorý si nalinkoval nadáva na JavaScript, lebo JS nepracuje s asynchrónnymi funkciami rovnako ako Go jazyk... Ten autor je snáď idiot. No jasne, že starší jazyk nemá vlastnosti ktoré má novšie navrhnutý jazyk. Navyše kompletne iného typu, staticky typovaný, kompilovaný, oproti dynamicky typovanému, interpretovanému. Preto sa ťa pýtam na tvoj názor prečo je async / await zle navrhnutý a ako by si to implementoval ty, so zachovaním spätnej kompatibility. Alebo ste fakt všetci len vytreté nuly bez nadhľadu a dokážete sa len opičiť po iných vytretých nulách a kopírovať jeden od druhého nezmyselné argumenty? Alebo ste fakt programátori? Ak programátori, ukážte mi iný, lepšie navrhnutý jazyk do asynchrónneho prostredia, rovnako starý, stále spätne kompatibilný s prvou verziou, interpretovaný, nie kompilovaný. Inak tu len stále budete miešať hrušky s jablkami bez čo len náznaku kritického myslenia, ako nemysliace ovce čo si preposielajú konšpiračné teórie ktoré reflektujú ich presvedčenie, nie znalosti.
Ty jsi fakt primitiv, co se nejen že vůbec neorientuje v IT, ale neznáš ani ten tvůj Javascript. Async/await nijak nesouvisí se zpětnou kompatibilitou, korutiny (potažmo kooperativní konkurence obecně) šly navrhnout mnohem lépe bez ohledu na jiné JS šaškárny. Čti si ten odkazovaný článek tak dlouho, dokud ho nepochopíš, autor totiž má - na rozdíl od tebe - rozsáhlé znalosti o jazycích, překladačích, interpretech a souběžnosti.
-
Zásadním problémem JS taky je, že Ryan Dahl (autor node.js) ho kritizuje a místo node.js doporučuje Go.
On kritizuje spíš návrh node.js :) A je příznivcem staticky typovaného systému, takže třeba prosazuje víc TypeScript oproti JS.
-
Zásadním problémem JS taky je, že Ryan Dahl (autor node.js) ho kritizuje a místo node.js doporučuje Go.
On kritizuje spíš návrh node.js :) A je příznivcem staticky typovaného systému, takže třeba prosazuje víc TypeScript oproti JS.
Ne, on zcela jednoznačně doporučuje Go jako nejlepší volbu pro aplikace s NIO. S typovým systémem to nijak nesouvisí.
-
Všimol si v praxi nasledovné: bývalý profi Java programátor z Telekomu začal v januári s JS projektom - na frontende SPA s Vue, komunikujúcu cez REST so serverless backendom bežiacim v JS v Lambdách nad AWS. Po dvoch dňoch oboznamovania sa s novými princípmi a jazykom plne kódil v JS, po dvoch mesiacoch sme spolu dokončili celú serverless web aplikáciu. Ani slovkom si nesťažoval na JS ani na serverless, ani na microservices princípy, na nič. Naopak, celá serverless architektúra sa mu páčila tak, že ju bol v Telekome odprezentovať bývalím kolegom, lebo umožňovala písať web aplikácie výrazne rýchlejšie a prehľadnejšie. A JS sa mu vyslovene zapáčil, obzvlášť kvôli Promisom. Dnes robí na inej web aplikácii, v Jave, ale frontend robí naďalej ako SPA a backend v Jave, ale už len ako REST API.
Iný profesionálny Java developer, šéf developer vývoja bankových aplikácií. Drvivou väčšinou robia aplikácie pre banky nie ako desktopové apky, ale vo forme web aplikácií s Vaadin frameworkom. Nikdy HTML/CSS/JS či Ajax neriešili, proste si frontend navrhli vizuálne, z komponentov poskytovaných Vaadinom. Ale aj nový Vaadin prešiel na web komponenty na frontende, konkrétne na Polymérové. To bolo pičovania na tú zmenu, to ste ešte nezažili. Deň na to ako sme sa o web komponentoch porozprávali, ako pochopil ako sú tie komponenty napojené na Java backend, že sú navyše reaktívne a samé sa aktualizujú, po tom ako si to cez deň vyskúšal, večer už hurá, nech žije reaktívny pattern, uznanlivo pokyvkával hlavou ako mu to zjednoduší a urýchli vývoj.
Takže nie len ten článok čo som sem v predošlom príspevku vložil, ako bol profi Java developer od Sun nadšený z JS, ale ani profesionáli z môjho okolia, voči JS a novým princípom vývoja web aplikácií ktoré prišli vďaka Node platforme, nemajú nič proti. Všetci v tom vidia posun vpred.
Potom prídem na nejaké bezvýznamné fórum, kde anonymne každý druhý 20 ročný murár s fušovaním do programovania ako s voľnočasovou aktivitou sa cíti povolaný kritizovať nejaký jazyk. A to nie preto, žeby ho v dobe jeho vzniku vedel za daných podmienok navrhnúť lepšie. Nevedel. Ani jeden jediný z tých kritikov. Tak prečo potom kritizujú? Možné sú len tieto dôvody:
Prvý: ješitnosť. Keď murár konečne dogooglil, že najviac hype je okolo Go, tak sa s vypätím posledných síl po šichte naučil na ubytovni pri sviečke aspoň základný syntax Go a ako prvé sa nerozhodol niečo naprogramovať, nemá na čom, notebook by mu zo skrine ukradol jeden z desiatich ukrajinských spolubývajúcich, no tak aspoň hejtuje z mobilu na fórach každý jazyk, ktorý nemá rovnaký syntax ako Go.
Druhý možný dôvod nie je o nič lepší: nedostatok znalostí / praxe. Kuchár, ktorý sa časom naučil programovať, typicky v PHP, ale tam aj končí jeho rozhľad. Nevie, že existuje mnoho jazykov postavených na rôznych paradigmách a nikdy sa nedelia na dobré a zlé, ale podľa účelu za ktorým vznikli a podľa vhodnosti či nevhodnosti na ten či onen typ úlohy. Bez tohoto potrebného nadhľadu a hlbšej znalosti teórie programovania tak delia jazyky jediným spôsobom: na dobré a zlé. Presnejšie na ten jediný čo vedia a "tie ostatné".
Ďalším dôvodom je nedostatok kritického myslenia: programátor, ktorý sa naučil programovať hlavne z tutoriálov na nete a tak čokoľvek, čo nájde na nete napísané, považuje za slovo božie. Vlastné názory, premýšľanie nad tématikou, to je mimo neho, to je nad jeho mentálne kapacity a ak sa k niečomu vyjadrí, najskôr si vygoogli cudzie argumenty a potom si sem len nakopíruje, či nalinkuje.
Ďalšie možné dôvody sa mi nechce písať, stačí ak si uvedomíte jedno: ak aj máš akademický background, nestrápňuj sa kritikou JS, lebo v danej dobe, za daných podmienok, za danej úrovne techniky a teórie, by si JS navrhol lepšie. A uvedom si, že to vedia aj vývojári JS a neopravili dané problémy len preto, aby ostal spätne kompatibilný.
Ale aby som aj ja len nekritizoval, tu je návod ako na JS pre menej bystrých: nainštaluj si VS Code, nainštaluj si Flow, maj zapnutý Linter a nastav aby Ti Flow zbehol kód pri ukladaní a každý kód začni dvoma riadkami:
// @flow
'use strict'
Potom nebudete mať problém s vašimi "neprekonateľnými problémami" s JS. Žiadne == nebude povolené, iba ===, žiadne nesprávne typy odovzdané funkciám, na všetko budete upozornení. Následne sa zamestnajte v reálnom tíme a aj tam aj sami prídete na to, že sú vám statické typy za behu hovno platné, a že ochranou pred chybami je TDD, nie typový systém.
Happy coding, ovce ;)
-
odprezentovať bývalím kolegom
Máš tu zase "překlep", bývalím -> mývalím. Pokud to ovšem mělo být "bývalým", tak to není překlep, ale pravopis retarda :) Neber si to osobně ;)
-
Keď murár konečne dogooglil
Už se ti povedlo zjistit, co to je HMTS? Minules to ani neuměl opsat ("HTMS"), možná proto ti Google neporadil. Ale nic si z toho nedělej, i mistr tesař se někdy utne, absolvent zvláštní školy jako ty na to právo třikrát denně ;)
-
odprezentovať bývalím kolegom
Máš tu zase "překlep", bývalím -> mývalím. Pokud to ovšem mělo být "bývalým", tak to není překlep, ale pravopis retarda :) Neber si to osobně ;)
Neberiem si to osobne retarde. Prvá definícia trola na fórach znie upozorňovanie na gramatiku, nie vyjadrovanie sa k obsahu. Takže nie, nenoj, naozaj mi je ten preklep spolu s tebou ukradnutý.
-
Keď murár konečne dogooglil
Už se ti povedlo zjistit, co to je HMTS? Minules to ani neuměl opsat ("HTMS"), možná proto ti Google neporadil. Ale nic si z toho nedělej, i mistr tesař se někdy utne, absolvent zvláštní školy jako ty na to právo třikrát denně ;)
Ale ja viem presne čo to je. V tvojom konkrétnom prípade je to vygooglený argument o ktorého pointe nevieš ani ň. Takých argumentátorov ako ty ale fakt vyseriem denne aj troch, aspoň v tom sa nemýliš.
-
Zásadním problémem JS taky je, že Ryan Dahl (autor node.js) ho kritizuje a místo node.js doporučuje Go.
On kritizuje spíš návrh node.js :) A je příznivcem staticky typovaného systému, takže třeba prosazuje víc TypeScript oproti JS.
Ne, on zcela jednoznačně doporučuje Go jako nejlepší volbu pro aplikace s NIO.
A to někde rozporuji?
S typovým systémem to nijak nesouvisí.
A to si poslechnu na základě čeho jsi k tomu došel. :)
-
Potom prídem na nejaké bezvýznamné fórum, kde anonymne každý druhý 20 ročný murár s fušovaním do programovania ako s voľnočasovou aktivitou sa cíti povolaný kritizovať nejaký jazyk. A to nie preto, žeby ho v dobe jeho vzniku vedel za daných podmienok navrhnúť lepšie. Nevedel. Ani jeden jediný z tých kritikov. Tak prečo potom kritizujú?
...
Ďalšie možné dôvody sa mi nechce písať, stačí ak si uvedomíte jedno: ak aj máš akademický background, nestrápňuj sa kritikou JS, lebo v danej dobe, za daných podmienok, za danej úrovne techniky a teórie, by si JS navrhol lepšie. A uvedom si, že to vedia aj vývojári JS a neopravili dané problémy len preto, aby ostal spätne kompatibilný.
...
Happy coding, ovce ;)
LOL, to me vazne rozesmalo :-). Takze zpackany JS se nesmi kritizovat proto, ze kritik by udajne nedokazal navrhnout lepsi jazyk. Hmm, tak to vlastne skoro nikdo nesmi nic kritizovat. Mohu byt s paskvilem alespon tise nespokojeny, nebo se musim tvarit radostne?
V seznamu duvodu, proc lide kritizuji JS, ti chybi ten hlavni. Je to jazyk nelogicky a nekonzistentne navrhnuty a holt to nekímu vadi :-).
-
Potom prídem na nejaké bezvýznamné fórum, kde anonymne každý druhý 20 ročný murár s fušovaním do programovania ako s voľnočasovou aktivitou sa cíti povolaný kritizovať nejaký jazyk. A to nie preto, žeby ho v dobe jeho vzniku vedel za daných podmienok navrhnúť lepšie. Nevedel. Ani jeden jediný z tých kritikov. Tak prečo potom kritizujú?
Protože otázka byla, jaké jsou dnes praktické problémy JS. Ne, zda někdo z přítomných byl v té době s tehdejšími znalostmi schopen něco podobného navrhnout.... Nemáš trochu problém udržet téma (a myšlenku)?
Prvý: ješitnosť. Keď murár konečne dogooglil, že najviac hype je okolo Go, tak sa s vypätím posledných síl po šichte naučil na ubytovni pri sviečke aspoň základný syntax Go a ako prvé sa nerozhodol niečo naprogramovať, nemá na čom, notebook by mu zo skrine ukradol jeden z desiatich ukrajinských spolubývajúcich, no tak aspoň hejtuje z mobilu na fórach každý jazyk, ktorý nemá rovnaký syntax ako Go.
Go má skvěle udělaný runtime s non-blocking IO. Což je to, k čemu se v tom článku vyjadřoval... nebo snad máš pocit, že Go tohle zrovna dobře udělané nemá?
Druhý možný dôvod nie je o nič lepší: nedostatok znalostí / praxe. Kuchár, ktorý sa časom naučil programovať, typicky v PHP, ale tam aj končí jeho rozhľad. Nevie, že existuje mnoho jazykov postavených na rôznych paradigmách a nikdy sa nedelia na dobré a zlé, ale podľa účelu za ktorým vznikli a podľa vhodnosti či nevhodnosti na ten či onen typ úlohy. Bez tohoto potrebného nadhľadu a hlbšej znalosti teórie programovania tak delia jazyky jediným spôsobom: na dobré a zlé. Presnejšie na ten jediný čo vedia a "tie ostatné".
Několik lidí tady má velké zkušenosti třeba s Haskellem a při té příležitosti se v podstatě nevyhneš tomu občas nějaký ten jazyk navrhnout a k tomu si nějaký ten interpret napsat.... mně naopak připadá, že člověk, který tohle obsáhne, začne mít vcelku dobrou představu o tom, co je dobré a zlé, proč jsou statické typy dobré, proč jsou některé věci prasárny a proč by je jazyk vůbec neměl povolovat....
Ďalším dôvodom je nedostatok kritického myslenia: programátor, ktorý sa naučil programovať hlavne z tutoriálov na nete a tak čokoľvek, čo nájde na nete napísané, považuje za slovo božie. Vlastné názory, premýšľanie nad tématikou, to je mimo neho, to je nad jeho mentálne kapacity a ak sa k niečomu vyjadrí, najskôr si vygoogli cudzie argumenty a potom si sem len nakopíruje, či nalinkuje.
Tak nějak si říkám, jestli problémem nebude Tvoje ego...
Ďalšie možné dôvody sa mi nechce písať, stačí ak si uvedomíte jedno: ak aj máš akademický background, nestrápňuj sa kritikou JS, lebo v danej dobe, za daných podmienok, za danej úrovne techniky a teórie, by si JS navrhol lepšie. A uvedom si, že to vedia aj vývojári JS a neopravili dané problémy len preto, aby ostal spätne kompatibilný.
Když ty máš pocit, že to je pořád o egu, jestli je někdo lepší než ty. Ale otázka byla věcná - má dneska, s tím, co dneska víme a očekáváme, JS nějaké praktické problémy? A má - je to z dnešního pohledu naprosto tragický jazyk. A byl i z tehdejšího pohledu, pokud vím, tak oni prostě potřebovali navrhnout "nějaký" jazyk, tak to nějak spatlali a nikdo netušil, že to bude mít takový úspěch.
Jinak v tehdejší době vznikl Erlang, který by klidně místo JS v tom prohlížeči běžet mohl a návrh má mnohem lepší (protože si s tím v té době s tehdejší teorií a technikou dali práci, protože věděli, že chtějí mít dobrý jazyk).
Ale aby som aj ja len nekritizoval, tu je návod ako na JS pre menej bystrých: nainštaluj si VS Code, nainštaluj si Flow, maj zapnutý Linter a nastav aby Ti Flow zbehol kód pri ukladaní a každý kód začni dvoma riadkami:
Ano, JS žádné problémy nemá, ale nainstalujte si statický type checker....
-
// @flow
'use strict'
Potom nebudete mať problém s vašimi "neprekonateľnými problémami" s JS. Žiadne == nebude povolené, iba ===, žiadne nesprávne typy odovzdané funkciám, na všetko budete upozornení.
A jak se prosim bez == porovnavaji hodnoty?
-
// @flow
'use strict'
Potom nebudete mať problém s vašimi "neprekonateľnými problémami" s JS. Žiadne == nebude povolené, iba ===, žiadne nesprávne typy odovzdané funkciám, na všetko budete upozornení.
A jak se prosim bez == porovnavaji hodnoty?
Veď je to tam napísané... Pomocou ===?
-
// @flow
'use strict'
Potom nebudete mať problém s vašimi "neprekonateľnými problémami" s JS. Žiadne == nebude povolené, iba ===, žiadne nesprávne typy odovzdané funkciám, na všetko budete upozornení.
A jak se prosim bez == porovnavaji hodnoty?
Veď je to tam napísané... Pomocou ===?
Takze new String('aa') === new String('aa') zacne zazracne fungovat? Jak tedy potom porovnam identitu objektu? Uz chapes? Timhle jen zakazes nektere hlouposti, ale z blbeho navrhu dobry neudelas.
-
// @flow
'use strict'
Potom nebudete mať problém s vašimi "neprekonateľnými problémami" s JS. Žiadne == nebude povolené, iba ===, žiadne nesprávne typy odovzdané funkciám, na všetko budete upozornení.
A jak se prosim bez == porovnavaji hodnoty?
Veď je to tam napísané... Pomocou ===?
Takze new String('aa') === new String('aa') zacne zazracne fungovat? Jak tedy potom porovnam identitu objektu? Uz chapes? Timhle jen zakazes nektere hlouposti, ale z blbeho navrhu dobry neudelas.
Jediné zlé je na tom to, že používaš operátor === na to, na čo nie je určený. Na porovnávanie objektov treba použiť Object.is() metódu.
let a = new String('aa')
let b = new String('aa')
console.log(Object.is(a, b))
-
Takze new String('aa') === new String('aa') zacne zazracne fungovat? Jak tedy potom porovnam identitu objektu? Uz chapes? Timhle jen zakazes nektere hlouposti, ale z blbeho navrhu dobry neudelas.
Nemůžeš chtít, aby stejně napsaná věc najednou od nějaké verze JS začala fungovat jinak - zpětná kompatibilita je JS důležitá, protože zdrojové kódy a interpret jsou v zásadě při každém spuštění z různých nezávislých zdrojů, přičemž ty zdrojáky můžou být klidně 20 let staré (na 20 let staré webové stránce, na kterou od té doby nikdo nesáhl) - a nikdo nechce, aby najednou přestaly fungovat a všechny starší stránky s JS se musely zahodit nebo přepsat.
Jediné řešení by byla standardizace dalšího jazyka (nějaké nové moderní verze JS bez zpětné kompatibility nebo úplně jiného jazyka) v browseru <script language="XYZ">. Ale to by museli chtít Google, Mozilla a Microsoft.
Na backend straně žádné omezení není, komu JS (a tedy node.js) nevyhovuje, má desítky dalších možností v čem psát.
-
Takze new String('aa') === new String('aa') zacne zazracne fungovat? Jak tedy potom porovnam identitu objektu? Uz chapes? Timhle jen zakazes nektere hlouposti, ale z blbeho navrhu dobry neudelas.
Nemůžeš chtít, aby stejně napsaná věc najednou od nějaké verze JS začala fungovat jinak - zpětná kompatibilita je JS důležitá, protože zdrojové kódy a interpret jsou v zásadě při každém spuštění z různých nezávislých zdrojů, přičemž ty zdrojáky můžou být klidně 20 let staré (na 20 let staré webové stránce, na kterou od té doby nikdo nesáhl) - a nikdo nechce, aby najednou přestaly fungovat a všechny starší stránky s JS se musely zahodit nebo přepsat.
Jediné řešení by byla standardizace dalšího jazyka (nějaké nové moderní verze JS bez zpětné kompatibility nebo úplně jiného jazyka) v browseru <script language="XYZ">. Ale to by museli chtít Google, Mozilla a Microsoft.
Na backend straně žádné omezení není, komu JS (a tedy node.js) nevyhovuje, má desítky dalších možností v čem psát.
A proto tu máme "use strict", což je v podstatě jiný jazyk....
Pořád nechápu, co se snažíte říct: že ty problémy v JS vlastně nejsou problémy, protože potřebujeme zpětnou kompatibilitu? Nebo že to nejsou problémy, protože by to v té době málokdo navrhl lépe? (což není pravda, IMO kdyby ti lidi věděli, jak to bude úspěšné, tak by to sami navrhli líp). Nebo že to nejsou problémy, protože potřebujeme zpětnou kompatibilitu?
-
Jediné řešení by byla standardizace dalšího jazyka (nějaké nové moderní verze JS bez zpětné kompatibility nebo úplně jiného jazyka) v browseru <script language="XYZ">. Ale to by museli chtít Google, Mozilla a Microsoft.
Na backend straně žádné omezení není, komu JS (a tedy node.js) nevyhovuje, má desítky dalších možností v čem psát.
Hodně se používají transpilery. Takže ani v browseru to omezení není.
Otázka zněla na problém s javascriptem v praxi. A zdá se, že vlastně skutečně žádné nemá. Protože komu nevyhovuje, ten používá něco jiného :-)
-
// @flow
'use strict'
Potom nebudete mať problém s vašimi "neprekonateľnými problémami" s JS. Žiadne == nebude povolené, iba ===, žiadne nesprávne typy odovzdané funkciám, na všetko budete upozornení.
A jak se prosim bez == porovnavaji hodnoty?
Veď je to tam napísané... Pomocou ===?
Takze new String('aa') === new String('aa') zacne zazracne fungovat? Jak tedy potom porovnam identitu objektu? Uz chapes? Timhle jen zakazes nektere hlouposti, ale z blbeho navrhu dobry neudelas.
Jediné zlé je na tom to, že používaš operátor === na to, na čo nie je určený. Na porovnávanie objektov treba použiť Object.is() metódu.
let a = new String('aa')
let b = new String('aa')
console.log(Object.is(a, b))
Dává ten samý výsledek jako === :-).
To prostě neokecáš a mám v zásobě spoustu dalších špeků, třeba tento je také povedený.
null == 0
null === 0
null > 0
null >= 0
Kdo si tipne výsledeky? :-)
-
Takze new String('aa') === new String('aa') zacne zazracne fungovat? Jak tedy potom porovnam identitu objektu? Uz chapes? Timhle jen zakazes nektere hlouposti, ale z blbeho navrhu dobry neudelas.
Nemůžeš chtít, aby stejně napsaná věc najednou od nějaké verze JS začala fungovat jinak - zpětná kompatibilita je JS důležitá, protože zdrojové kódy a interpret jsou v zásadě při každém spuštění z různých nezávislých zdrojů, přičemž ty zdrojáky můžou být klidně 20 let staré (na 20 let staré webové stránce, na kterou od té doby nikdo nesáhl) - a nikdo nechce, aby najednou přestaly fungovat a všechny starší stránky s JS se musely zahodit nebo přepsat.
Jediné řešení by byla standardizace dalšího jazyka (nějaké nové moderní verze JS bez zpětné kompatibility nebo úplně jiného jazyka) v browseru <script language="XYZ">. Ale to by museli chtít Google, Mozilla a Microsoft.
Na backend straně žádné omezení není, komu JS (a tedy node.js) nevyhovuje, má desítky dalších možností v čem psát.
Chtít to mohu a řešitelné to je. Ať v rámci mechanismu 'use strict' či jeho obdobě nebo v rámci JS2, protože html mi dává možnost volat různé jazyky. S různými verzemi html se prohlížeče také vyrovnali.
-
Takze new String('aa') === new String('aa') zacne zazracne fungovat? Jak tedy potom porovnam identitu objektu? Uz chapes? Timhle jen zakazes nektere hlouposti, ale z blbeho navrhu dobry neudelas.
Nemůžeš chtít, aby stejně napsaná věc najednou od nějaké verze JS začala fungovat jinak - zpětná kompatibilita je JS důležitá, protože zdrojové kódy a interpret jsou v zásadě při každém spuštění z různých nezávislých zdrojů, přičemž ty zdrojáky můžou být klidně 20 let staré (na 20 let staré webové stránce, na kterou od té doby nikdo nesáhl) - a nikdo nechce, aby najednou přestaly fungovat a všechny starší stránky s JS se musely zahodit nebo přepsat.
Jediné řešení by byla standardizace dalšího jazyka (nějaké nové moderní verze JS bez zpětné kompatibility nebo úplně jiného jazyka) v browseru <script language="XYZ">. Ale to by museli chtít Google, Mozilla a Microsoft.
Na backend straně žádné omezení není, komu JS (a tedy node.js) nevyhovuje, má desítky dalších možností v čem psát.
Chtít to mohu a řešitelné to je. Ať v rámci mechanismu 'use strict' či jeho obdobě nebo v rámci JS2, protože html mi dává možnost volat různé jazyky. S různými verzemi html se prohlížeče také vyrovnali.
Další možné řešení je rozšíření jazyka. Operátor == je tak zprasen, že se v podstatě zakazuje používat a doporučuje se používat místo něj ===. Ani zdaleka to neřeší všechny problémy, ale nějaké přeci jen. Ale bohuželnuž JS nezná nic jako >== a <==. Blbě implementované třízení polí by šlo řešit novou metodou array.sort2() (sort_strict, ...) a tak dále.
-
// @flow
'use strict'
Potom nebudete mať problém s vašimi "neprekonateľnými problémami" s JS. Žiadne == nebude povolené, iba ===, žiadne nesprávne typy odovzdané funkciám, na všetko budete upozornení.
A jak se prosim bez == porovnavaji hodnoty?
Veď je to tam napísané... Pomocou ===?
Takze new String('aa') === new String('aa') zacne zazracne fungovat? Jak tedy potom porovnam identitu objektu? Uz chapes? Timhle jen zakazes nektere hlouposti, ale z blbeho navrhu dobry neudelas.
Jediné zlé je na tom to, že používaš operátor === na to, na čo nie je určený. Na porovnávanie objektov treba použiť Object.is() metódu.
let a = new String('aa')
let b = new String('aa')
console.log(Object.is(a, b))
Dává ten samý výsledek jako === :-).
To prostě neokecáš a mám v zásobě spoustu dalších špeků, třeba tento je také povedený.
null == 0
null === 0
null > 0
null >= 0
Kdo si tipne výsledeky? :-)
Iste, že je to false. Veď porovnávaš referencie na dva rôzne objekty v pamäti. Čo iné by to akože malo dať?
-
To prostě neokecáš a mám v zásobě spoustu dalších špeků, třeba tento je také povedený.
null == 0
null === 0
null > 0
null >= 0
Kdo si tipne výsledeky? :-)
Iste, že je to false. Veď porovnávaš referencie na dva rôzne objekty v pamäti. Čo iné by to akože malo dať?
A to je důvod proč mi přijde to rozlišování objektů a hodnot jako fakt ošklivé. (Jako kdyby null sám o sobě nebylo zvěrstvo.)
-
// @flow
'use strict'
Potom nebudete mať problém s vašimi "neprekonateľnými problémami" s JS. Žiadne == nebude povolené, iba ===, žiadne nesprávne typy odovzdané funkciám, na všetko budete upozornení.
A jak se prosim bez == porovnavaji hodnoty?
Veď je to tam napísané... Pomocou ===?
Takze new String('aa') === new String('aa') zacne zazracne fungovat? Jak tedy potom porovnam identitu objektu? Uz chapes? Timhle jen zakazes nektere hlouposti, ale z blbeho navrhu dobry neudelas.
Jediné zlé je na tom to, že používaš operátor === na to, na čo nie je určený. Na porovnávanie objektov treba použiť Object.is() metódu.
let a = new String('aa')
let b = new String('aa')
console.log(Object.is(a, b))
Dává ten samý výsledek jako === :-).
To prostě neokecáš a mám v zásobě spoustu dalších špeků, třeba tento je také povedený.
null == 0
null === 0
null > 0
null >= 0
Kdo si tipne výsledeky? :-)
Iste, že je to false. Veď porovnávaš referencie na dva rôzne objekty v pamäti. Čo iné by to akože malo dať?
Nastuduj si manuál :-).
-
// @flow
'use strict'
Potom nebudete mať problém s vašimi "neprekonateľnými problémami" s JS. Žiadne == nebude povolené, iba ===, žiadne nesprávne typy odovzdané funkciám, na všetko budete upozornení.
A jak se prosim bez == porovnavaji hodnoty?
Veď je to tam napísané... Pomocou ===?
Takze new String('aa') === new String('aa') zacne zazracne fungovat? Jak tedy potom porovnam identitu objektu? Uz chapes? Timhle jen zakazes nektere hlouposti, ale z blbeho navrhu dobry neudelas.
Jediné zlé je na tom to, že používaš operátor === na to, na čo nie je určený. Na porovnávanie objektov treba použiť Object.is() metódu.
let a = new String('aa')
let b = new String('aa')
console.log(Object.is(a, b))
Dává ten samý výsledek jako === :-).
To prostě neokecáš a mám v zásobě spoustu dalších špeků, třeba tento je také povedený.
null == 0
null === 0
null > 0
null >= 0
Kdo si tipne výsledeky? :-)
Iste, že je to false. Veď porovnávaš referencie na dva rôzne objekty v pamäti. Čo iné by to akože malo dať?
Nastuduj si manuál :-).
Ja to viem. To ty tvrdíš nezmysel, tak ty mi vysvetli prečo by porovnanie dvoch referencií ukazujúce na dve rozličné miesta v pamäti mali dať true.
-
Ja to viem. To ty tvrdíš nezmysel, tak ty mi vysvetli prečo by porovnanie dvoch referencií ukazujúce na dve rozličné miesta v pamäti mali dať true.
No..fakt to nevíš...
-
Ja to viem. To ty tvrdíš nezmysel, tak ty mi vysvetli prečo by porovnanie dvoch referencií ukazujúce na dve rozličné miesta v pamäti mali dať true.
No..fakt to nevíš...
Hm. Ok, tak mi to vysvetli.
-
Poslední porovnání null >= 0 vrátí true.
Protože >= se chová jinak než ==
Vynutí si přetypování null na number (pro jiné typy nemá >= smysl), což je 0 :)
Co
-
Na téhle stránce dole je tabulka popisující výsledku přetypování různých hodnot na number, string a bool.
https://www.w3schools.com/js/js_type_conversion.asp
Přiznám se že některé konverze mě také překvapily, samy o sobě smysl dávají, ale moc konzistence tam není :D
Ještě, že se to v praxi obvykle nepoužívá.
-
Poslední porovnání null >= 0 vrátí true.
Protože >= se chová jinak než ==
Vynutí si přetypování null na number (pro jiné typy nemá >= smysl), což je 0 :)
Přesně, ale měl jsi ho nechat, aby si na to přišel sám, pak by pochopil, jak je JS nekonzistentně navržený a dává hloupé výsledky. Protože není úplně podstatné, zda se null považuje za větší, rovný nebo menší než 0, ale v dobře navrženém jazyku musí napříč tímto jazykem ve všech případech dávat konzistentní odpověď. A u JS tomu tak v mnohých případech není. A i když je to popsané, je to prostě špatně.
-
To prostě neokecáš a mám v zásobě spoustu dalších špeků, třeba tento je také povedený.
null == 0
null === 0
null > 0
null >= 0
Kdo si tipne výsledeky? :-)
Iste, že je to false. Veď porovnávaš referencie na dva rôzne objekty v pamäti. Čo iné by to akože malo dať?
Nastuduj si manuál :-).
Ja to viem. To ty tvrdíš nezmysel, tak ty mi vysvetli prečo by porovnanie dvoch referencií ukazujúce na dve rozličné miesta v pamäti mali dať true.
Nevíš, odpověděl jsi špatně. To ty mi vysvětli, proč je to v jednom případě true.
Všimni si, jak se tu prezentuješ, jako expert na JS, s ohromnými zkušenostmá, my ostatní jsme blbečci, co si nedokážou ani přečíst nebo pochopit manuál. Píšeš nám tu urážky jako Happy coding, ovce ;).
A pak selžeš na jednoduché otázce, na kterou by i podprůměrný programátor dokonce i kdejaký začátečník v normálním srozumitelném a předvídatelném jazyce odpověděl s jistotou a to bez nahlížení kamkoliv.
Takže si vyber, buď jsi totální hňup, s kterým nemá smysl cokoliv řešit, protože neovládáš ani naprosté základy a to i navzdory upozornění na chybu a nebo holt je JS špatně navržený jazyk a jeho používání je procházka po minovém poli, kde i expert na JS se čas od času plete v základech jazyka a neumí s jistotou předvídat jeho chování.
Já osobně, ač používám JS od časů Netscape a IE4, tedy dřevních dob kdy vznikal, a znám hodně jeho špeků, nemám v něm jistotu a poustu věcí si musím pořád zkoušet a ověřovat, protože JS je nepředvídatelný. A proto říkám, je to špatně navržený jazyk. Navíc nedostatečný pro spolehlivé programování a zajištění ne aby program nespadl, ale aby neudělal něco, co nemá (k čemuž stačí jedna blbě vyhonocená podmínka, nebo že projde nějaký nesmysl, na kterém by každý slušný jazyk vyvolal výjimku). Pohybuji se v průmyslovém prostředí náročném na bezpečnost a je to na palici. Dobře polovina kódu jsou kontroly navíc nutné oproti jiným jazykům. JS je jazyk vhodný pro blogýsky, kde vcelku o nic nejde, pro náročnější použití je nedostatečný, bohužel nemá alternativu.
-
I když to není 100% alternativa, tak tohle vypadá moc zajímavě.
https://shift.infinite.red/phoenixs-liveview-client-side-elixir-at-last-2280716ae791
-
To prostě neokecáš a mám v zásobě spoustu dalších špeků, třeba tento je také povedený.
null == 0
null === 0
null > 0
null >= 0
Kdo si tipne výsledeky? :-)
Iste, že je to false. Veď porovnávaš referencie na dva rôzne objekty v pamäti. Čo iné by to akože malo dať?
Nastuduj si manuál :-).
Ja to viem. To ty tvrdíš nezmysel, tak ty mi vysvetli prečo by porovnanie dvoch referencií ukazujúce na dve rozličné miesta v pamäti mali dať true.
Nevíš, odpověděl jsi špatně. To ty mi vysvětli, proč je to v jednom případě true.
Všimni si, jak se tu prezentuješ, jako expert na JS, s ohromnými zkušenostmá, my ostatní jsme blbečci, co si nedokážou ani přečíst nebo pochopit manuál. Píšeš nám tu urážky jako Happy coding, ovce ;).
A pak selžeš na jednoduché otázce, na kterou by i podprůměrný programátor dokonce i kdejaký začátečník v normálním srozumitelném a předvídatelném jazyce odpověděl s jistotou a to bez nahlížení kamkoliv.
Takže si vyber, buď jsi totální hňup, s kterým nemá smysl cokoliv řešit, protože neovládáš ani naprosté základy a to i navzdory upozornění na chybu a nebo holt je JS špatně navržený jazyk a jeho používání je procházka po minovém poli, kde i expert na JS se čas od času plete v základech jazyka a neumí s jistotou předvídat jeho chování.
Já osobně, ač používám JS od časů Netscape a IE4, tedy dřevních dob kdy vznikal, a znám hodně jeho špeků, nemám v něm jistotu a poustu věcí si musím pořád zkoušet a ověřovat, protože JS je nepředvídatelný. A proto říkám, je to špatně navržený jazyk. Navíc nedostatečný pro spolehlivé programování a zajištění ne aby program nespadl, ale aby neudělal něco, co nemá (k čemuž stačí jedna blbě vyhonocená podmínka, nebo že projde nějaký nesmysl, na kterém by každý slušný jazyk vyvolal výjimku). Pohybuji se v průmyslovém prostředí náročném na bezpečnost a je to na palici. Dobře polovina kódu jsou kontroly navíc nutné oproti jiným jazykům. JS je jazyk vhodný pro blogýsky, kde vcelku o nic nejde, pro náročnější použití je nedostatečný, bohužel nemá alternativu.
To, ked je exkrement opisany v dokumentacii este neznamena, ze je to torta.
Je to objedktivne zle vymysleny jazyk, ktory prinasa problemy komunite, programatorom. V dospliych jazykoch sa take veci proste nedeju.
A to nezmeni ani tvoja arogancia ani nadavky.
-
Má to určitá na první pohled nejasná místa, ale teď upřímně - jak často sčítáte objekty s řetězci? Nebo porovnáváne nully s čísly? Použili jste vůbec někdy v životě new String()? Aniž bych to chtěl nějak bagatelizovat, tak většina toho, co uvádíte jako nepřekonatelný problém, jsou těžce okrajové případy.
-
Na některé už mě nebaví stále reagovat, nerad házím hrách o zeď. Nicméně je pozoruhodné, že <nadsázka> jeden týden tu není dost dobrý návrh Haskellu, další týden není dost dobrý návrh JavaScriptu... <ironie> (obojí perfektně vyargumentováno) ještě štěstí, že tu máme ten dobře navržený Python </ironie></nadsázka>. :)
-
Má to určitá na první pohled nejasná místa, ale teď upřímně - jak často sčítáte objekty s řetězci? Nebo porovnáváne nully s čísly? Použili jste vůbec někdy v životě new String()? Aniž bych to chtěl nějak bagatelizovat, tak většina toho, co uvádíte jako nepřekonatelný problém, jsou těžce okrajové případy.
Null s čísly neporovnáváš záměrně, ale může k tomu občas dojít nechtěně. I když ty osobně nepoužiješ new String(), může ti to do programu lézt z řady použitých knihoven, a když ne hned, tak třeba po její aktualizaci a tím se ti najednou nepředvídatelně změní chování důležitého programu. Takže si to potom všechno musíš pořád ručně kontrolovat na spoustě míst, abys měl jistotu, že se ti to nestane.
-
I když ty osobně nepoužiješ new String(), může ti to do programu lézt z řady použitých knihoven
chci vidět takovou knihovnu. Podle mě to neprojde CI.
-
Rád bych zmínil můj pohled na věc.
Nejsem si úplně jistý, co vlastně autor chce slyšet. Pokud je nutností se naučit všechny vlastnosti a výjimky toho jazyka, tak není žádný jazyk špatný. Ani asembler.
Skutečnost, že se tu občas někdo naváží do programátorů jako do lopat, to taky není tak úplně jednoznačný. Přeci jen je rozdíl když si musím namáhat hlavu, abych ošéfoval všechny vlastnosti a situace, a podrazy toho jazyka (javascript, C, python) a pak doufal, že jsem byl opravdu tak dobrej, a na nic nezapoměl...
... a nebo si musím namahat hlavu, abych přesvědčil kompilátor, že má udělat to co chci, a on na mě furt řve, že tohle nejde, a tohle nejde, a že to musím ještě takhle jinak - a tu všechnu buzeraci kůli tomu, aby kompilátor minimalizoval riziko špatného programu (typescript, rust, haskell).
Tohle jsem si uvědomil při mém studiu jazyka Rust. On to není žádný jednoduchý jazyk. Naučit se ho chce trošku mentální námahy. Ale ta námaha má smysl. Námaha vložená do programu v C mi přijde naprosto zbytečná, protože dělám to, co by měl dělat stroj.
-
Rád bych zmínil můj pohled na věc.
Nejsem si úplně jistý, co vlastně autor chce slyšet. Pokud je nutností se naučit všechny vlastnosti a výjimky toho jazyka, tak není žádný jazyk špatný. Ani asembler.
Skutečnost, že se tu občas někdo naváží do programátorů jako do lopat, to taky není tak úplně jednoznačný. Přeci jen je rozdíl když si musím namáhat hlavu, abych ošéfoval všechny vlastnosti a situace, a podrazy toho jazyka (javascript, C, python) a pak doufal, že jsem byl opravdu tak dobrej, a na nic nezapoměl...
... a nebo si musím namahat hlavu, abych přesvědčil kompilátor, že má udělat to co chci, a on na mě furt řve, že tohle nejde, a tohle nejde, a že to musím ještě takhle jinak - a tu všechnu buzeraci kůli tomu, aby kompilátor minimalizoval riziko špatného programu (typescript, rust, haskell).
Tohle jsem si uvědomil při mém studiu jazyka Rust. On to není žádný jednoduchý jazyk. Naučit se ho chce trošku mentální námahy. Ale ta námaha má smysl. Námaha vložená do programu v C mi přijde naprosto zbytečná, protože dělám to, co by měl dělat stroj.
Mentální námaha se vyplatí v jazyce jako Idris nebo Agda, které mi zaručí korektnost. U JS to je spíše opruz.
-
Rád bych zmínil můj pohled na věc.
Nejsem si úplně jistý, co vlastně autor chce slyšet. Pokud je nutností se naučit všechny vlastnosti a výjimky toho jazyka, tak není žádný jazyk špatný. Ani asembler.
Skutečnost, že se tu občas někdo naváží do programátorů jako do lopat, to taky není tak úplně jednoznačný. Přeci jen je rozdíl když si musím namáhat hlavu, abych ošéfoval všechny vlastnosti a situace, a podrazy toho jazyka (javascript, C, python) a pak doufal, že jsem byl opravdu tak dobrej, a na nic nezapoměl...
... a nebo si musím namahat hlavu, abych přesvědčil kompilátor, že má udělat to co chci, a on na mě furt řve, že tohle nejde, a tohle nejde, a že to musím ještě takhle jinak - a tu všechnu buzeraci kůli tomu, aby kompilátor minimalizoval riziko špatného programu (typescript, rust, haskell).
Tohle jsem si uvědomil při mém studiu jazyka Rust. On to není žádný jednoduchý jazyk. Naučit se ho chce trošku mentální námahy. Ale ta námaha má smysl. Námaha vložená do programu v C mi přijde naprosto zbytečná, protože dělám to, co by měl dělat stroj.
Mentální námaha se vyplatí v jazyce jako Idris nebo Agda, které mi zaručí korektnost. U JS to je spíše opruz.
Šak to píšu.
A Idris či Agda je zbytečnej extrém. Stačí cokoliv, co aspoň trochu spolupracuje.
Ale obhajovat Javascript, že je super, když vlastně nijak nepomáhá a všechno si to vývojář musí ošéfovat sám?
-
Ale obhajovat Javascript, že je super, když vlastně nijak nepomáhá a všechno si to vývojář musí ošéfovat sám?
Vždycky si to musíš ošéfovat sám. Jde jen o to, nakolik je to v kterém jazyce pracné, na co všechno musíš dávat pozor a ve výsledku kolik v tom ošéfování statisticky naděláš chyb.
-
.... ve výsledku kolik v tom ošéfování statisticky naděláš chyb.
Takže konečně věcný argument - ukážeš nám statistiky! Nebo je nemáš...?
-
.... ve výsledku kolik v tom ošéfování statisticky naděláš chyb.
Takže konečně věcný argument - ukážeš nám statistiky! Nebo je nemáš...?
Ja ukážem. Vôbec eee nepotešia, ale stav sa, že si bude aj tak ďalej obhajovať svoje nezmysli. To vieš, ješitnosť nepustí...
https://medium.com/javascript-scene/the-shocking-secret-about-static-types-514d39bf30a3 (https://medium.com/javascript-scene/the-shocking-secret-about-static-types-514d39bf30a3)
-
.... ve výsledku kolik v tom ošéfování statisticky naděláš chyb.
Takže konečně věcný argument - ukážeš nám statistiky! Nebo je nemáš...?
Ja ukážem. Vôbec eee nepotešia, ale stav sa, že si bude aj tak ďalej obhajovať svoje nezmysli. To vieš, ješitnosť nepustí...
https://medium.com/javascript-scene/the-shocking-secret-about-static-types-514d39bf30a3 (https://medium.com/javascript-scene/the-shocking-secret-about-static-types-514d39bf30a3)
Co asi vyjde při porovnání diametrálně odlišných projektů napsaných v jiných jazycích různým množstvím lidí...... garbage in garbage out? Pro změnu vzít X programátorů a říct jim "naimplementujte si tenhle velký projekt ve svém jazyce"... Jak je těžké psát vůbec dobré testy (QuickCheck...), jak je těžký refaktoring...
Zrovna teď jsem zvažoval částečný přechod na kotlin v jednom androidím projektu - umí to součtové typy a líp to pracuje s null hodnotama. To, že pak NullPointerException nemusím řešit a že mi kompiler zařve při neošetřených pattern matchích je fakt. Tvrzení, že to nemá žádný vliv na množství bugů při stejné dodané energii....mi prostě připadá silně nepravděpodobné.
-
.... ve výsledku kolik v tom ošéfování statisticky naděláš chyb.
Takže konečně věcný argument - ukážeš nám statistiky! Nebo je nemáš...?
Ja ukážem. Vôbec eee nepotešia, ale stav sa, že si bude aj tak ďalej obhajovať svoje nezmysli. To vieš, ješitnosť nepustí...
https://medium.com/javascript-scene/the-shocking-secret-about-static-types-514d39bf30a3 (https://medium.com/javascript-scene/the-shocking-secret-about-static-types-514d39bf30a3)
Co asi vyjde při porovnání diametrálně odlišných projektů napsaných v jiných jazycích různým množstvím lidí...... garbage in garbage out? Pro změnu vzít X programátorů a říct jim "naimplementujte si tenhle velký projekt ve svém jazyce"... Jak je těžké psát vůbec dobré testy (QuickCheck...), jak je těžký refaktoring...
Zrovna teď jsem zvažoval částečný přechod na kotlin v jednom androidím projektu - umí to součtové typy a líp to pracuje s null hodnotama. To, že pak NullPointerException nemusím řešit a že mi kompiler zařve při neošetřených pattern matchích je fakt. Tvrzení, že to nemá žádný vliv na množství bugů při stejné dodané energii....mi prostě připadá silně nepravděpodobné.
To je práve ten problém. Ono ti len na prvý pohľad PRIPADÁ nepravdepodobné, ale pritom opak je pravdou. Je to akademický výskum na tému vplyv statických typov na hustotu výskytu chýb. A jasným výsledkom je, že je tam istý vplyv, ale malý. Faktom tak ostáva, že tu prítomný diskutujúci sa dopúšťajú dokola tej istej chyby: preceňujú vplyv statických typov. A faktom dva ostáva: reálny "problem solver", či pri statických, či pri dynamických jazykoch je TDD approach. Bodka.
-
To je práve ten problém. Ono ti len na prvý pohľad PRIPADÁ nepravdepodobné, ale pritom opak je pravdou. Je to akademický výskum na tému vplyv statických typov na hustotu výskytu chýb. A jasným výsledkom je, že je tam istý vplyv, ale malý. Faktom tak ostáva, že tu prítomný diskutujúci sa dopúšťajú dokola tej istej chyby: preceňujú vplyv statických typov. A faktom dva ostáva: reálny "problem solver", či pri statických, či pri dynamických jazykoch je TDD approach. Bodka.
Aha, takže OPAK pravdou není. Je pravdou přesně to, co říkám, akorát se bavíme o tom, do jaké míry...
Jinak mám osobně i proti tomu akademickému výzkumu výhrady. Vezmeš nějakou netriviální úlohu, která je ale testovatelná, a pak řekneš skupině programátorů, aby to v různých jazycích napsali.
No tak ta skupina programátorů udělá v podstatě TDD a na konci se bavíme akorát tak o tom, kdo byl schopen si napsat lepší testy, který mu odchytili ty jeho bugy...? Fakt máš pocit, že to něco říká o real-world projektech..?
-
No tak ta skupina programátorů udělá v podstatě TDD a na konci se bavíme akorát tak o tom, kdo byl schopen si napsat lepší testy, který mu odchytili ty jeho bugy...? Fakt máš pocit, že to něco říká o real-world projektech..?
Čo to splietaš? Ten výskum bol robený na real world projektoch. Mám uveriť spochybneniu jeho výpovednej hodnoty na základe DOJMU anonymného príspevku na fóre? Alebo kam tým mieriš? Čo píšeš nedáva zmysel.
-
No tak ta skupina programátorů udělá v podstatě TDD a na konci se bavíme akorát tak o tom, kdo byl schopen si napsat lepší testy, který mu odchytili ty jeho bugy...? Fakt máš pocit, že to něco říká o real-world projektech..?
Čo to splietaš? Ten výskum bol robený na real world projektoch. Mám uveriť spochybneniu jeho výpovednej hodnoty na základe DOJMU anonymného príspevku na fóre? Alebo kam tým mieriš? Čo píšeš nedáva zmysel.
Těch výzkumů je několik, jeden z nich byl i to, že vzali tu samou úlohu a dali ji naprogramovat lidem v různých jazycích a pak se koukali na výsledek.
Nicméně to, co myslíš ty, je asi tohle: http://web.cs.ucdavis.edu/~filkov/papers/lang_github.pdf (http://web.cs.ucdavis.edu/~filkov/papers/lang_github.pdf)
Asi bych potřeboval vysvětlit, proč si nemyslíš, že to je Garbage In - Garbage out.... Obzvláště v oblasti "defect density" mi přijde, že to prostě bude porovnávání jablek s hruškama....
-
Být to pět let zpátky, tak bych ten hate na JavaScript chápal. Dneska už to ale dá opravdu práci, vyhrabat nějaký faktický, ne jen teoretický problém. A v budoucnu to bude ještě pracnější - JS komunita nasadila takové tempo, že většina ostatních jazyků oproti tomu působí jako zakleté království. To je sice možno brát i jako mínus, za mě je to ale jasně plus.
-
No tak ta skupina programátorů udělá v podstatě TDD a na konci se bavíme akorát tak o tom, kdo byl schopen si napsat lepší testy, který mu odchytili ty jeho bugy...? Fakt máš pocit, že to něco říká o real-world projektech..?
Čo to splietaš? Ten výskum bol robený na real world projektoch. Mám uveriť spochybneniu jeho výpovednej hodnoty na základe DOJMU anonymného príspevku na fóre? Alebo kam tým mieriš? Čo píšeš nedáva zmysel.
Těch výzkumů je několik, jeden z nich byl i to, že vzali tu samou úlohu a dali ji naprogramovat lidem v různých jazycích a pak se koukali na výsledek.
Nicméně to, co myslíš ty, je asi tohle: http://web.cs.ucdavis.edu/~filkov/papers/lang_github.pdf (http://web.cs.ucdavis.edu/~filkov/papers/lang_github.pdf)
Asi bych potřeboval vysvětlit, proč si nemyslíš, že to je Garbage In - Garbage out.... Obzvláště v oblasti "defect density" mi přijde, že to prostě bude porovnávání jablek s hruškama....
Nerozumiem čo potrebuješ vysvetliť, a už vôbec nie prečo. Ponúknem ti štatistiku z real world podmienok, čo si presne chcel, ty zaargumentuješ výskumom za umelých podmienok, nie z real world, a ešte aj chceš z neznámeho dôvodu niečo vysvetliť. Nerozumiem, ale OK, napíš ktorá konkrétna časť toho pdf ti nieje jasná, alebo o ktorej konkrétne časti pochybuješ a na základe čoho pochybuješ.
-
Nerozumiem čo potrebuješ vysvetliť, a už vôbec nie prečo. Ponúknem ti štatistiku z real world podmienok, čo si presne chcel, ty zaargumentuješ výskumom za umelých podmienok, nie z real world, a ešte aj chceš z neznámeho dôvodu niečo vysvetliť. Nerozumiem, ale OK, napíš ktorá konkrétna časť toho pdf ti nieje jasná, alebo o ktorej konkrétne časti pochybuješ a na základe čoho pochybuješ.
Máš 2 projekty, které se každý týká něčeho jiného, jsou napsané v jiném jazyce. Jeden má silné typy, jeden má dynamické typy. Řekněme, že na SLOC jsou srovnatelné. V jednom najdeš v issue trackeru víc bugů než v druhém. Mně připadá, že z toho rozdílu ohledně náchylnosti k bugům daného paradigmatu nejde usoudit prakticky nic. Ti statistikové to dělají. Tak to zkus obhájit.
Být to pět let zpátky, tak bych ten hate na JavaScript chápal. Dneska už to ale dá opravdu práci, vyhrabat nějaký faktický, ne jen teoretický problém. A v budoucnu to bude ještě pracnější - JS komunita nasadila takové tempo, že většina ostatních jazyků oproti tomu působí jako zakleté království. To je sice možno brát i jako mínus, za mě je to ale jasně plus.
Všechny jazyky jdou dopředu, nové vlastnosti v Javě, C++, pythonu... - type inference, lepší generika atd. A v javascriptu se víc a víc používá Typescript - což je ale jiný jazyk.
-
Nerozumiem čo potrebuješ vysvetliť, a už vôbec nie prečo. Ponúknem ti štatistiku z real world podmienok, čo si presne chcel, ty zaargumentuješ výskumom za umelých podmienok, nie z real world, a ešte aj chceš z neznámeho dôvodu niečo vysvetliť. Nerozumiem, ale OK, napíš ktorá konkrétna časť toho pdf ti nieje jasná, alebo o ktorej konkrétne časti pochybuješ a na základe čoho pochybuješ.
Máš 2 projekty, které se každý týká něčeho jiného, jsou napsané v jiném jazyce. Jeden má silné typy, jeden má dynamické typy. Řekněme, že na SLOC jsou srovnatelné. V jednom najdeš v issue trackeru víc bugů než v druhém. Mně připadá, že z toho rozdílu ohledně náchylnosti k bugům daného paradigmatu nejde usoudit prakticky nic. Ti statistikové to dělají. Tak to zkus obhájit.
Být to pět let zpátky, tak bych ten hate na JavaScript chápal. Dneska už to ale dá opravdu práci, vyhrabat nějaký faktický, ne jen teoretický problém. A v budoucnu to bude ještě pracnější - JS komunita nasadila takové tempo, že většina ostatních jazyků oproti tomu působí jako zakleté království. To je sice možno brát i jako mínus, za mě je to ale jasně plus.
Všechny jazyky jdou dopředu, nové vlastnosti v Javě, C++, pythonu... - type inference, lepší generika atd. A v javascriptu se víc a víc používá Typescript - což je ale jiný jazyk.
Inými slovami, tvrdíš, že tá štúdia na kódoch z praxe má nulovú výpovednú logiku, lebo autor použil nevhodnú metodiku? Ok, rozviň to.
Tvrdíš, že sa čoraz viac používa TS. Ukáž čísla. Lebo ja tvrdím, že rýchlejšie pribúdajú programátori v JS, ako v TS. Čiže používa sa čoraz častejšie TS, ale nie viac ako JS. Aj preto toto:
https://medium.com/javascript-scene/you-might-not-need-typescript-or-static-types-aa7cb670a77b (https://medium.com/javascript-scene/you-might-not-need-typescript-or-static-types-aa7cb670a77b)
-
Že vám vůbec stojí za námahu se tady dohadovat s nějakou slovenskou píčou, která nechce přijímat žádné argumenty. JS je pro něj něco jako modla, nic jiného v životě nepoznal a ani nepozná, protože tento maďar má IQ houpajícího se koně. Takové gumy je třeba ignorovat a při potkání vzít ocelovou trubkou o ten jeho molekulový mozek
-
Inými slovami, tvrdíš, že tá štúdia na kódoch z praxe má nulovú výpovednú logiku, lebo autor použil nevhodnú metodiku? Ok, rozviň to.
No vždyť:
Máš 2 projekty, které se každý týká něčeho jiného, jsou napsané v jiném jazyce. Jeden má silné typy, jeden má dynamické typy. Řekněme, že na SLOC jsou srovnatelné. V jednom najdeš v issue trackeru víc bugů než v druhém. Mně připadá, že z toho rozdílu ohledně náchylnosti k bugům daného paradigmatu nejde usoudit prakticky nic. Ti statistikové to dělají.
Já vůbec netuším, co by ta čísla měla vypovídat. Takže když to staticky zagreguju, tak netuším, co by ten výsledek měl říkat....Garbage in, garbage out...
A v javascriptu se víc a víc používá Typescript.
Tvrdíš, že sa čoraz viac používa TS. Ukáž čísla. Lebo ja tvrdím, že rýchlejšie pribúdajú programátori v JS, ako v TS. Čiže používa sa čoraz častejšie TS, ale nie viac ako JS.
? Nesouhlasíš z principu?
https://medium.com/javascript-scene/you-might-not-need-typescript-or-static-types-aa7cb670a77b
Ufff... no, jak bych to řekl... no kromě toho, že autor neslyšel o row types (a moje zkušenost s row types je spíš negativní). Spíš přemýšlím, jaký je rozdíl mezy typovaným jazykem, který má kvalitně udělanou type inference a dynamickým jazykem, kdy programátor píše v IDE, které má kvalitně udělanou type inference. Obzvláště, když si přeje, aby javascript podporoval optional anotace, když inference selže. Podle mě v tom rozdíl není z hlediska kontroly typů žádný...
Ale jinak samozřejmě rozdíl je - v momentě, kdy ten kompiler začne ten typový systém využívat i pro něco víc než jen kontrolu korektnosti. To pak začnou být možné věci, které jsou bez typové kontroly jenom jeden "velký hack".
-
v javascriptu se víc a víc používá Typescript - což je ale jiný jazyk.
Když si odmyslíš typy, tak je to takřka 1:1 JavaScript. No a co se týče rozšířenosti, tak marketshare JavaScriptu se počítá v procentech, zatímco u TypeScriptu je to v desetinách procent(a ty desetiny jsou tak dvě). Hype dokáže udělat z komára velblouda.
-
jen tak za zvědavosti, můžete někdo ukázat kus javascriptu, který be se do staticky typovaného jazyka přepsat nedal nebo jen s velkými obtížemi?
-
jen tak za zvědavosti, můžete někdo ukázat kus javascriptu, který be se do staticky typovaného jazyka přepsat nedal nebo jen s velkými obtížemi?
To záleží. Můžou se použít generika? Defaultní protokoly? Dej příklad jazyka, pak půjde odpovědět.
-
v javascriptu se víc a víc používá Typescript - což je ale jiný jazyk.
Když si odmyslíš typy, tak je to takřka 1:1 JavaScript. No a co se týče rozšířenosti, tak marketshare JavaScriptu se počítá v procentech, zatímco u TypeScriptu je to v desetinách procent(a ty desetiny jsou tak dvě). Hype dokáže udělat z komára velblouda.
Ano, takže když napíšu, že typescript se používá víc a víc...a začal z nuly...? A samozřejmě tady je to hodně zkreslené tím, že JS je výrazně jednodušší než TS, takže začátečníci si zvolí celkem jasně. Ale používá se, frameworky to podporují. Třeba je to bublina, kdo ví.
Jinak ale otázka toho zda je to jiný jazyk - já nevím. Nějak mi celý ten argument (zvlášť z toho článku) linkovaného článku připadá zvláštní: Nepotřebujeme statické typy, máme linter s type inferencí, který ty typy odvodí a zkontroluje a případně vyhlásí problém. A ještě lepší by byly typové anotace, aby se případně pomohlo linteru tam, kde to odvodit nedokáže....
Jaký je teda rozdíl mezi JS+anotace+linter vs. staticky typovaný jazyk...? Pokud ten jazyk využívá ty typy pouze pro kontrolu korektnosti, tak mi to ve výsledku připadá jako naprosto identické?
-
jen tak za zvědavosti, můžete někdo ukázat kus javascriptu, který be se do staticky typovaného jazyka přepsat nedal nebo jen s velkými obtížemi?
To záleží. Můžou se použít generika? Defaultní protokoly? Dej příklad jazyka, pak půjde odpovědět.
to mi je jedno, zajímá mě pohled zastánců dynamických typů a zároveň si chci zkusit jak by vypadal přepis do silně typovaného jazyka (haskellu, jak jinak)
-
Jaký je teda rozdíl mezi JS+anotace+linter vs. staticky typovaný jazyk...? Pokud ten jazyk využívá ty typy pouze pro kontrolu korektnosti, tak mi to ve výsledku připadá jako naprosto identické?
Krom odpovědi, která je evidentní, a dalších zajímavostí...
JS+anotace+linter má jednu takovou drobnou výhodu v tom, že ty typy jsou volitelné.
Ono ve výsledku to opět není rozdíl, protože ve statickém jazyce můžeš všude rvát Any, ale v praxi vlastně jde hlavně o zvyk. Podporuje to styl vývoje, kdy nejdříve naprototypuješ cosi, aby to alespoň zhruba odpovídalo tomu, co chceš. A pak přidáš typy, aby se ti to zase celé nerozpadlo.
-
jen tak za zvědavosti, můžete někdo ukázat kus javascriptu, který be se do staticky typovaného jazyka přepsat nedal nebo jen s velkými obtížemi?
To záleží. Můžou se použít generika? Defaultní protokoly? Dej příklad jazyka, pak půjde odpovědět.
to mi je jedno, zajímá mě pohled zastánců dynamických typů a zároveň si chci zkusit jak by vypadal přepis do silně typovaného jazyka (haskellu, jak jinak)
Z typovaných problémů třeba Duck typing. Haskell nemá row types, takže tohle se případně dá vyřešit lensama s generováním Has. Ale Duck typing mi připadá jak minové pole, a Row types mi přišly strašný v*s*r. Navíc jsem to fakt nikdy nepotřeboval, alternativní řešení s použitím normálních typeclass bylo vždy přehlednější. Ale možná u nějakých hodně velkých projektů určitého stylu, nevím.
Nebo nějaké věci, které využívají drsně introspekci. Kdysi jsem si napsal knihovnu v Pyhtonu, která generuje SQL dotazy. Když se podíváš na nabídku těchto knihoven v haskellu, zjistíš, že to je vlastně všechno docela těžké na použití. Na rozdíl od toho pythonu je to "víceméně" typesafe (i.e. většinou to zabrání generování nevalidního SQL), ale ty knihovny jsou silně netriviální (a bohužel trošku netriviální i na použití, ale to možná platí i u těch netypovaných knihoven - u haskellu mě vždycky tyhle složité knihovny vyděsí....u pythonu/js to nějak nevypadá vizuálně strašidelně...)
-
jen tak za zvědavosti, můžete někdo ukázat kus javascriptu, který be se do staticky typovaného jazyka přepsat nedal nebo jen s velkými obtížemi?
To záleží. Můžou se použít generika? Defaultní protokoly? Dej příklad jazyka, pak půjde odpovědět.
to mi je jedno, zajímá mě pohled zastánců dynamických typů a zároveň si chci zkusit jak by vypadal přepis do silně typovaného jazyka (haskellu, jak jinak)
V Haskellu nebude problém s ničím kromě proxy.
-
jen tak za zvědavosti, můžete někdo ukázat kus javascriptu, který be se do staticky typovaného jazyka přepsat nedal nebo jen s velkými obtížemi?
Jen tak ze zvědavosti, proč? Respektive proč by něco takového mělo existovat a zároveň k čemu by ti takový případný kód byl? Asi nechápu pointu. :)
-
jen tak za zvědavosti, můžete někdo ukázat kus javascriptu, který be se do staticky typovaného jazyka přepsat nedal nebo jen s velkými obtížemi?
Jen tak ze zvědavosti, proč? Respektive proč by něco takového mělo existovat a zároveň k čemu by ti takový případný kód byl? Asi nechápu pointu. :)
statický typový systém je omezující, třeba heterogení kontejnery (duck typing, jak psal andy) můžou být docela zajímavá věc, přitom v dynamických jazycích je to naprostá samozřejmost... z toho vyvozuju, že některé programy, pokud bych chtěl víceméně zachovat jejich tvar, budou citelně delší a/nebo zajímavější a zajímá mě to proto, že si chci svou weapon of choice pořádně otestovat :)
-
jen tak za zvědavosti, můžete někdo ukázat kus javascriptu, který be se do staticky typovaného jazyka přepsat nedal nebo jen s velkými obtížemi?
To záleží. Můžou se použít generika? Defaultní protokoly? Dej příklad jazyka, pak půjde odpovědět.
to mi je jedno, zajímá mě pohled zastánců dynamických typů a zároveň si chci zkusit jak by vypadal přepis do silně typovaného jazyka (haskellu, jak jinak)
V Haskellu nebude problém s ničím kromě proxy.
tohle https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Proxy ?
-
jen tak za zvědavosti, můžete někdo ukázat kus javascriptu, který be se do staticky typovaného jazyka přepsat nedal nebo jen s velkými obtížemi?
To záleží. Můžou se použít generika? Defaultní protokoly? Dej příklad jazyka, pak půjde odpovědět.
to mi je jedno, zajímá mě pohled zastánců dynamických typů a zároveň si chci zkusit jak by vypadal přepis do silně typovaného jazyka (haskellu, jak jinak)
V Haskellu nebude problém s ničím kromě proxy.
tohle https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Proxy ?
Jo, něco takového mnohé dynamické jazyky mají a se statickým typováním se to moc rádo nemá (i když třeba Java má proxy taky).
-
]Já vůbec netuším, co by ta čísla měla vypovídat. Takže když to staticky zagreguju, tak netuším, co by ten výsledek měl říkat....Garbage in, garbage out...
Máš tam jasne vysvetlenú použitú metodológiu, aj jasne prezentované výsledky z tej štúdie vyplývajúce. Ešte aj pekne zarámované. Takže to ja nerozumiem ako tomu môžeš nerozumieť. Čo je nepochopiteľné na vete "Niektoré jazyky sú náchylnejšie na bugy ako iné, avšak rozdiel je malý"? Tak čo máš neustále s tým garbage in garbage out? Čítal si to vôbec? Poslal som ti aj článok o TS, ktorý sa na to odvoláva, od profesionála z praxou, ktorý rovnako tvrdí, že TS je fajn, ale nie nevyhnutný a je to viac hype, ako potreba. V inom príspevku som pripol aj článok od Java profi zo Sun, ktorý na JS nenadáva, je z neho nadšený. Výsledok z praxe: statické typy sú často preceňované, v tej súvislosti aj samotné TS okolo ktorého je až nezdravý hype, kladivom na chyby je TDD, nie typový systém a JS nie je zďaleka tak škaredý jazyk, ako mnohí amatéri prezentujú - profesionáli si to nemyslia. A to som presne taký prípad aj zažil, nie len o tomto čítal. A praxi tu, v tomto vlákne? Ani jeden protiargument podporený akademicky, či aspoň nejakým doloženým profesionálom. No tak som teda skúsil aspoň vygoogliť "is javascript badly designed" a ako prvé na mňa vyskočila séria článkov vysvetľujúca drvivú väčšinu vašich argumentov, v zmysle, že je viac nepochopený, ako zle navrhnutý. V ďalšom výsledku v princípe tvrdí to isté aj Crockford, aj spomína, že väčšina kníh a amatérov mu robí hanbu, nie zlý návrh. Ďalej článok od ukrajinského developera, že JS nie je zlý jazyk a kto mu robí zle meno. Zasa len lopaty. Áno, nájdeš tam aj hejt, ale zasa len od lopát. Čistý hejt, to zmená bez vysvetlenia PREČO, v čom je zlý. Proste ako to robia anonymné lopaty tu. Je zlý a hotovo. Ale ok, možno stále niečo prehliadam a preto sa rád poučím: dajte mi link na akúkoľvek zmysluplnú kritiku, prečo je zlý. Či od akademikov, či od profesionálov ktorí od neho odišli, lebo ich znechutil. Ja som nič také totiž ani len nevedel vygoogliť, zato presný opak nebol problém...
-
statický typový systém je omezující, třeba heterogení kontejnery (duck typing, jak psal andy) můžou být docela zajímavá věc, přitom v dynamických jazycích je to naprostá samozřejmost... z toho vyvozuju, že některé programy, pokud bych chtěl víceméně zachovat jejich tvar, budou citelně delší a/nebo zajímavější a zajímá mě to proto, že si chci svou weapon of choice pořádně otestovat :)
Heterogenní kontejnery se dají dělat vcelku jednoduše i ve statických typových systémech. Nic obtížného ani opruzujícího.
-
jen tak za zvědavosti, můžete někdo ukázat kus javascriptu, který be se do staticky typovaného jazyka přepsat nedal nebo jen s velkými obtížemi?
Jen tak ze zvědavosti, proč? Respektive proč by něco takového mělo existovat a zároveň k čemu by ti takový případný kód byl? Asi nechápu pointu. :)
statický typový systém je omezující, třeba heterogení kontejnery (duck typing, jak psal andy) můžou být docela zajímavá věc, přitom v dynamických jazycích je to naprostá samozřejmost... z toho vyvozuju, že některé programy, pokud bych chtěl víceméně zachovat jejich tvar, budou citelně delší a/nebo zajímavější a zajímá mě to proto, že si chci svou weapon of choice pořádně otestovat :)
Záleží, co člověk bere jako omezující. Např. v již několikrát zmíněném Haskellu zase umožňuje dost jednoduše spoustu *magic*. Imho že některé programy budou delší/kratší, snazší/složitější bude spíše věcí zvolených jazyků než třeba typovým systémem. Ale to spíš můj tip, je docela dobře možné, že se pletu. :)
-
.... ve výsledku kolik v tom ošéfování statisticky naděláš chyb.
Takže konečně věcný argument - ukážeš nám statistiky! Nebo je nemáš...?
Ja ukážem. Vôbec eee nepotešia, ale stav sa, že si bude aj tak ďalej obhajovať svoje nezmysli. To vieš, ješitnosť nepustí...
https://medium.com/javascript-scene/the-shocking-secret-about-static-types-514d39bf30a3 (https://medium.com/javascript-scene/the-shocking-secret-about-static-types-514d39bf30a3)
To sis mě s někým popletl. Já tu na příkladech vysvětluji, že JS je špatně navržený jazyk. Se statickým typováním to vůbec nedávám do souvislosti. Konec konců takový statický C má také implicitní přetypování a je náchylný k chybám, byť není navržen tak nelogicky jako JS. Ale co budu vykládat někomu, kdo ani neumí porovnat null s nulou, že?
-
jen tak za zvědavosti, můžete někdo ukázat kus javascriptu, který be se do staticky typovaného jazyka přepsat nedal nebo jen s velkými obtížemi?
Špatný návrh JS nepramení z toho, že nemá statické typy. To bych nedával do souvislosti.
A obecně dynamické typování neumožňuje něco, co by ve staticky typovaném jazyce nešlo naprogramovat, ale mnohé věci dělá pohodlnější, kratší, přehlednější a srozumitelnější. Čím je kód přehlednější, tím méně chyb v něm programátor udělá.
-
jen tak za zvědavosti, můžete někdo ukázat kus javascriptu, který be se do staticky typovaného jazyka přepsat nedal nebo jen s velkými obtížemi?
Špatný návrh JS nepramení z toho, že nemá statické typy. To bych nedával do souvislosti.
A obecně dynamické typování neumožňuje něco, co by ve staticky typovaném jazyce nešlo naprogramovat, ale mnohé věci dělá pohodlnější, kratší, přehlednější a srozumitelnější. Čím je kód přehlednější, tím méně chyb v něm programátor udělá.
Když použiješ type inference, máš kód stejně krátký a přehledný. O typech nevíš, dokud neuděláš chybu.
-
Já tu na příkladech vysvětluji, že JS je špatně navržený jazyk.
To ani nahodou. Vsechny tvoje "priklady" byli rozdrceny protiargumenty na prach, tady jde pouze o to ze JS proste nechces rozumet. A tak ti zbyva jen hejt. JS je naopak velice dobre navrzeny jazyk. To, ze ho neumis je jina pisnicka.
-
Já tu na příkladech vysvětluji, že JS je špatně navržený jazyk.
To ani nahodou. Vsechny tvoje "priklady" byli rozdrceny protiargumenty na prach, tady jde pouze o to ze JS proste nechces rozumet. A tak ti zbyva jen hejt. JS je naopak velice dobre navrzeny jazyk. To, ze ho neumis je jina pisnicka.
Uvozovkami neuděláš ze slova příklad životné substantivum. Umíš JS stejně mizerně jako češtinu?
-
Já tu na příkladech vysvětluji, že JS je špatně navržený jazyk.
To ani nahodou. Vsechny tvoje "priklady" byli rozdrceny protiargumenty na prach, tady jde pouze o to ze JS proste nechces rozumet. A tak ti zbyva jen hejt. JS je naopak velice dobre navrzeny jazyk. To, ze ho neumis je jina pisnicka.
Ty drtive mezonové protiargumenty se rozpadly v prach dříve, než se dostaly ke mě. Leda že bys za protiargumen považoval oblíbené tvrzení, že je to popsané v manuálu. Jiným způsobem se nikdo ty js prasárny obhajovat nepokoušel.
-
Zhruba čas to zamknout, ne?
-
jen tak za zvědavosti, můžete někdo ukázat kus javascriptu, který be se do staticky typovaného jazyka přepsat nedal nebo jen s velkými obtížemi?
Špatný návrh JS nepramení z toho, že nemá statické typy. To bych nedával do souvislosti.
A obecně dynamické typování neumožňuje něco, co by ve staticky typovaném jazyce nešlo naprogramovat, ale mnohé věci dělá pohodlnější, kratší, přehlednější a srozumitelnější. Čím je kód přehlednější, tím méně chyb v něm programátor udělá.
Když použiješ type inference, máš kód stejně krátký a přehledný. O typech nevíš, dokud neuděláš chybu.
Mylíš tím tohle a nebo ještě něco jiného?
#define let(name,value) const __typeof__ (value) name = value;
#define var(name,value) __typeof__ (value) name = value;
Jestli tohle, obávám se, že to podstatu problému neřeší. Jestli něco jiného, pouč mě, jak mohu zjednodušit, zkrátit a zpřehlednit C program na úroveň dynamického jazyka.
-
jen tak za zvědavosti, můžete někdo ukázat kus javascriptu, který be se do staticky typovaného jazyka přepsat nedal nebo jen s velkými obtížemi?
Špatný návrh JS nepramení z toho, že nemá statické typy. To bych nedával do souvislosti.
A obecně dynamické typování neumožňuje něco, co by ve staticky typovaném jazyce nešlo naprogramovat, ale mnohé věci dělá pohodlnější, kratší, přehlednější a srozumitelnější. Čím je kód přehlednější, tím méně chyb v něm programátor udělá.
Když použiješ type inference, máš kód stejně krátký a přehledný. O typech nevíš, dokud neuděláš chybu.
Mylíš tím tohle a nebo ještě něco jiného?
#define let(name,value) const __typeof__ (value) name = value;
#define var(name,value) __typeof__ (value) name = value;
Jestli tohle, obávám se, že to podstatu problému neřeší. Jestli něco jiného, pouč mě, jak mohu zjednodušit, zkrátit a zpřehlednit C program na úroveň dynamického jazyka.
Co to je za výblitek? Si zjisti, co to je type inference.
-
jen tak za zvědavosti, můžete někdo ukázat kus javascriptu, který be se do staticky typovaného jazyka přepsat nedal nebo jen s velkými obtížemi?
Špatný návrh JS nepramení z toho, že nemá statické typy. To bych nedával do souvislosti.
A obecně dynamické typování neumožňuje něco, co by ve staticky typovaném jazyce nešlo naprogramovat, ale mnohé věci dělá pohodlnější, kratší, přehlednější a srozumitelnější. Čím je kód přehlednější, tím méně chyb v něm programátor udělá.
Když použiješ type inference, máš kód stejně krátký a přehledný. O typech nevíš, dokud neuděláš chybu.
Mylíš tím tohle a nebo ještě něco jiného?
#define let(name,value) const __typeof__ (value) name = value;
#define var(name,value) __typeof__ (value) name = value;
Jestli tohle, obávám se, že to podstatu problému neřeší. Jestli něco jiného, pouč mě, jak mohu zjednodušit, zkrátit a zpřehlednit C program na úroveň dynamického jazyka.
Co to je za výblitek? Si zjisti, co to je type inference.
Type inference je automatická detekce typů a ohledně C jsem našel jen tohle. Takže naopak já bych doporučil vám si zjistit co to je a následně vysvětlit, jak tím u statických jazyků chcete dosáhnout flexibility dynamických typů. To mi jasné není a opakuji, rád se nechám poučit.
-
Zhruba čas to zamknout, ne?
+1 nacase zvanilum a trolum jako eee zavrit hubu
-
Zhruba čas to zamknout, ne?
+1 nacase zvanilum a trolum jako eee zavrit hubu
Jeste ze te tu mame, jsi ohromny prinos pro tuto kultivovanou diskusi :-).
A pritom ti stacilo tak malo, misto plakani a psani tveho nesmyslu stacilo kouknut manual a pochopit ze operator "+" ma dvoji vyznam a javascript pouziva autocast - vsechno veci ktere pochopi bezne inteligentni jedinec. Kdyz ale nedokazes rozlisit state of art od nekonzistentniho chovani tak se vrat k C.
---
Ja JS/CS/TS delam uz snad dekadu, vim o nem snad vsechno a prekvapoval mne asi tak prvni rok jako kazdy jiny jazyk. Je navrzen uplne skvele, akorat naucit se ho poradne trva trochu dele nez u jazyku co pindaji na kde co a neumeji delit nulou :)
---
Jenze kdyz je jeden z operandu string tak + neni scitani ale concat. Ale to zabednencum nevysvetlis, budou pindat, ze to ma hazet exception :D
---
Vazne? tak to pak nejsi programator.
---
Ja myslel, ze se tady bavim s programatory, kteri rozlisuji co je syntax a runtime error.
---
Hura doslo na invektivy, takze zabednenym "takyprogramatorum" uz zrejme dochazeji argumenty. Jen tak dal, vyzpovidejte se a ukazte svoje skutecne ja aby jsme vsichni videli co za paka se tu snazi shazovat tak skvely jazyk ako JavaScript.
---
Nebudu krmit trola, ktery se tu snazi argumentovat nesmysly, ze "silne typovane systemy" odstini lidske chyby.
---
To ani nahodou. Vsechny tvoje "priklady" byli rozdrceny protiargumenty na prach, tady jde pouze o to ze JS proste nechces rozumet. A tak ti zbyva jen hejt. JS je naopak velice dobre navrzeny jazyk. To, ze ho neumis je jina pisnicka.
---
+1 nacase zvanilum a trolum jako eee zavrit hubu
-
Máš tam jasne vysvetlenú použitú metodológiu, aj jasne prezentované výsledky z tej štúdie vyplývajúce. Ešte aj pekne zarámované. Takže to ja nerozumiem ako tomu môžeš nerozumieť. Čo je nepochopiteľné na vete "Niektoré jazyky sú náchylnejšie na bugy ako iné, avšak rozdiel je malý"? Tak čo máš neustále s tým garbage in garbage out?
No já nechápu, jak ze 2 projektů napsaných v různých jazycích na základě počtu bugů v issue trackeru hodlá někdo usuzovat na náchylnost jazyku k bugům... tak očekávám, že mi dáš nějaké vysvětlení. A ty zatím místo vysvětlení šermuješ pojmy "nechápeš", "akademický" a "statistika"...
Výsledok z praxe: statické typy sú často preceňované, v tej súvislosti aj samotné TS okolo ktorého je až nezdravý hype, kladivom na chyby je TDD, nie typový systém a JS nie je zďaleka tak škaredý jazyk, ako mnohí amatéri prezentujú - profesionáli si to nemyslia.
Jestli sis nevším, tak ten "JS" profesionál píše, že mu bohatě stačí... IDE s type inference a typové hinty. Což je v podstatě ekvivalentní jazyku se statickými typy. Takže mi ten jeho pohled připadá... tak nějak absurdní..
A to som presne taký prípad aj zažil, nie len o tomto čítal. A praxi tu, v tomto vlákne? Ani jeden protiargument podporený akademicky, či aspoň nejakým doloženým profesionálom.
Protiargument proti čemu? Najdi si články profíků, kteří píšou v Haskellu, prakticky každý, kdo se v tom pohybuje ti řekne, že to je proti JS nebe a dudy.
Jinak evidentně si nevidíš na špičku nosu, když v tom skvělým jazyce sám děláš boty...
Boneflute to popsal moc hezky. Ono nejde o to, že v tom nejde dělat velký projekty. Jde o to, že to je nuda a zbytečná pruda. A další maintenance a refaktoring těch projektů, když už to všem vypadne z hlavy, je tragédie.
-
Type inference je automatická detekce typů a ohledně C jsem našel jen tohle. Takže naopak já bych doporučil vám si zjistit co to je a následně vysvětlit, jak tím u statických jazyků chcete dosáhnout flexibility dynamických typů. To mi jasné není a opakuji, rád se nechám poučit.
V C to není. Jedná se o jazyky, které implementují nějakou variantu třeba tohodle https://en.wikipedia.org/wiki/Hindley%E2%80%93Milner_type_system (https://en.wikipedia.org/wiki/Hindley%E2%80%93Milner_type_system). V podstatě pokud ty typy nejsou moc složitý a polymorfní, tak to toho odvodí docela hodně (nebo i úplně všechno). V praxi se dělá anotace top-level funkcí, což způsobí, že ty chybové hlášky pak nevylítnou někde, kde by to člověk nejmíň čekal a zároveň to většinou stačí, aby kompiler odvodil všechno ostatní.
-
No já nechápu, jak ze 2 projektů napsaných v různých jazycích na základě počtu bugů v issue trackeru hodlá někdo usuzovat na náchylnost jazyku k bugům... tak očekávám, že mi dáš nějaké vysvětlení. A ty zatím místo vysvětlení šermuješ pojmy "nechápeš", "akademický" a "statistika"...
Aké dva projekty? To si pletieš s tým, čo píše ten magor eee. Pozri si to pdf, potom kecaj.
Jestli sis nevším, tak ten "JS" profesionál píše, že mu bohatě stačí... IDE s type inference a typové hinty. Což je v podstatě ekvivalentní jazyku se statickými typy. Takže mi ten jeho pohled připadá... tak nějak absurdní..
Presne taaak, aj bez uvedenia typov mám to pohodlie, čo ten magor so statickými typmi.
Protiargument proti čemu? Najdi si články profíků, kteří píšou v Haskellu, prakticky každý, kdo se v tom pohybuje ti řekne, že to je proti JS nebe a dudy.
No aké nečakané, že novší jazyk bude lepší :/ A hlavne treba následne zrovnávať hrušky s jablkami, resp. Haskell s JS. Veď nech sa páči, použi ho v browseri.
Boneflute to popsal moc hezky. Ono nejde o to, že v tom nejde dělat velký projekty. Jde o to, že to je nuda a zbytečná pruda. A další maintenance a refaktoring těch projektů, když už to všem vypadne z hlavy, je tragédie.
Tragédia je, keď by to robil Boneflute. Inak s dnešnými modernými frameworkami, modulmi, web komponentami, či funkcionálnym prístupom je maintenance a refaktoring hračka.
Takže ak to zhrniem, možno si nevidím na špičku nosa, možno z teba a iných hovorí čistá neznalosť. Who knows?
-
Aké dva projekty? To si pletieš s tým, čo píše ten magor eee. Pozri si to pdf, potom kecaj.
Tak z 50.000 projektů, to je jedno. Do toho PDF jsem se podíval a pořád nechápu, jak na základě toho, že máš 1000 projektů v jednom jazyce, 800 projektů v druhém jazyce, ty projekty jsou jiné, dělají je jiní lidé, a teď porovnáváš nějaká čísla z issue trackeru - dojdeš k tomu, že u projektů z jazyka A je těch issues víc, v jazyce B míň.... a teď jako co? Co z toho hodláš vyvozovat a proč?
Presne taaak, aj bez uvedenia typov mám to pohodlie, čo ten magor so statickými typmi.
Tak ještě jednou, javascript+typová inference+typové anotace je jazyk se statickými typy. Co si myslíš, že se udělá s typy potom, co to proleze překladem? Normálně se to zahodí (type erasure).
Ten jeho argument je absurdní, protože říká, že nepotřebuje statické typy, stačí mu dynamické, protože.... podívejte, jak mi ty statické typy pomáhají, mám je v IDE a funguje to skvěle, kdyby tam byly anotace, aby to odvodilo to, co to neodvodí, tak by to bylo ještě lepší...
No aké nečakané, že novší jazyk bude lepší :/
Haskell - 1990. JavaScript - 1995.....?
A hlavne treba následne zrovnávať hrušky s jablkami, resp. Haskell s JS. Veď nech sa páči, použi ho v browseri.
No on se taky používá, i když transpilace do JS je funkční, ale má to některé nepříjemné vlastnosti, takže do toho nejdu. A pro změnu se jako paradigma experimentuje s Functional Reactive Programming, takže třeba za pár let uvidíme JS a spol. přejímat nějaké ideje. Doufám, že se brzo dotáhne do rozumného stavu WebAssembly, pak by to mohlo být dobrý. Elm je docela oblíbený (i když neexistence typeclass je IMO dost problém), PureScript se používá (ale nemám dobrou zkušenost z jiných důvodů).
Inak s dnešnými modernými frameworkami, modulmi, web komponentami, či funkcionálnym prístupom je maintenance a refaktoring hračka.
Heh... fakt, že jo... takovej refaktoring z angularu do reactu bych chtěl vidět.... A ano, refaktoring z jednoho REST frameworku do jiného, z jedné SQL knihovny do jiné atp. je v haskellu reálně udělatelná záležitost. Největší sranda je, když uděláš megacommit typu stovka změněných souborů, pár dní práce, jdeš to zkusit - a ono to napoprvý funguje. Prostě jenom po rekompilaci. Zažil jsem. Ne jednou. (samozřejmě taky ne vždycky, ale typicky bylo těch chyb naprosté minimum).
A hlavně spousta těch jazyků to dneska přebírá - IDE s typovou inferencí (python, javascript), jazyky s přímou podporou - Kotlin, Scala, Rust, TypeScript, Flow, type hinty v pythonu... takže statické typy jsou na nic, akorát to dneska začínají podporovat skoro všichni...?
-
Type inference je automatická detekce typů a ohledně C jsem našel jen tohle. Takže naopak já bych doporučil vám si zjistit co to je a následně vysvětlit, jak tím u statických jazyků chcete dosáhnout flexibility dynamických typů. To mi jasné není a opakuji, rád se nechám poučit.
V C to není. Jedná se o jazyky, které implementují nějakou variantu třeba tohodle https://en.wikipedia.org/wiki/Hindley%E2%80%93Milner_type_system (https://en.wikipedia.org/wiki/Hindley%E2%80%93Milner_type_system). V podstatě pokud ty typy nejsou moc složitý a polymorfní, tak to toho odvodí docela hodně (nebo i úplně všechno). V praxi se dělá anotace top-level funkcí, což způsobí, že ty chybové hlášky pak nevylítnou někde, kde by to člověk nejmíň čekal a zároveň to většinou stačí, aby kompiler odvodil všechno ostatní.
Polymorfní typy ještě jdou, problém je až v případě zobecněných algebraických typů.
-
Jestli sis nevším, tak ten "JS" profesionál píše, že mu bohatě stačí... IDE s type inference a typové hinty. Což je v podstatě ekvivalentní jazyku se statickými typy. Takže mi ten jeho pohled připadá... tak nějak absurdní..
Píšu v JS ve VSCode, který hezky barví syntax a podobně, type interference nepoužívám, protože imho není proč, když jsem v dynamicky psaném jazyce. Píšu tak třeba i v Perlu.
Pravdou je, že si zase "typy" dost hlídám sám, reps. kde je to nutné... chce to pečlivost. :)
Boneflute to popsal moc hezky. Ono nejde o to, že v tom nejde dělat velký projekty. Jde o to, že to je nuda a zbytečná pruda. A další maintenance a refaktoring těch projektů, když už to všem vypadne z hlavy, je tragédie.
Je to nuda a pruda? A co si pod tím mám představit? Respektive v čem je ta nuda? A pruda? To mám naopak občas u C/C++, apod. kde "musím" psát každý blbý typ. (nestěžuji si, jen to je prostě občas pomalejší než let x = "ahoj"; )
Protiargument proti čemu? Najdi si články profíků, kteří píšou v Haskellu, prakticky každý, kdo se v tom pohybuje ti řekne, že to je proti JS nebe a dudy.
Nebe a dudy v čem? Je to jako srovnávat Ferrari s F35... je to zkrátka něco jiného, užívám si psaní v obou jazycích; imho jde hlavně o to zvolit správný jazyk/technologii vzhledem k problému. Ale argumentovat Haskellem, že je JS špatně navržený jazyk mi přijde trochu přitažené za vlasy...
(nutno podotknout, že bych se určitě nenazval "profíkem, který píše v Haskellu" :) )
-
Jak na pískovišti. Já mám lepší bábovičky! Než jsem všechny vybalil, tak tys postavil hrad, ale máš to z nějakýho divnýho písku! To ti určitě spadne! Mááámííí!!!!! Mně se to nelíííbííí!!! Ať to nedělá!!!
-
Píšu v JS ve VSCode, který hezky barví syntax a podobně, type interference nepoužívám, protože imho není proč, když jsem v dynamicky psaném jazyce. Píšu tak třeba i v Perlu.
Pravdou je, že si zase "typy" dost hlídám sám, reps. kde je to nutné... chce to pečlivost. :)
Ona otázka zní, proč to nepoužívat - když stejně ty funkce konstruuješ způsobem, že by to tím klidně prošlo..
Je to nuda a pruda? A co si pod tím mám představit? Respektive v čem je ta nuda? A pruda? To mám naopak občas u C/C++, apod. kde "musím" psát každý blbý typ. (nestěžuji si, jen to je prostě občas pomalejší než let x = "ahoj"; )
...
Protiargument proti čemu? Najdi si články profíků, kteří píšou v Haskellu, prakticky každý, kdo se v tom pohybuje ti řekne, že to je proti JS nebe a dudy.
Nebe a dudy v čem? Je to jako srovnávat Ferrari s F35... je to zkrátka něco jiného, užívám si psaní v obou jazycích; imho jde hlavně o to zvolit správný jazyk/technologii vzhledem k problému.
Na frontendu moc na výběr není - na backendu ano. Takže můžeme srovnat, jak by se stejná úloha řešila v Js (node), C#, Javě, Haskellu, Elixiru atd.. Rozdíl je třeba v tom, že prakticky neděláš "iterativní" vývoj. Když píšu v netypovaném jazyku, tak to je typicky - napíšu pár řádek. Zkusím. Napíšu dalších pár řádek. Zkusím. Potřebuju změnit něco, co jsem už zkusil... bez TDD pro větší projekt je to sebevražda.
I C++ už umí dneska "auto". U C++ je naprosto nesnesitelné psát ty příšerné typy např. v iterátoru - "auto" to řeší.
Potřebuješ něco refaktorovat.... už je to docela dávno, potřeboval jsem upravit program (C++), který prováděl síťovou komunikaci, aby fungoval jak na little-endian tak na big-endian strojích. Takže...jak to udělat? Jak najít všechna místa, kde je potřeba přidat tu případnou konverzi do nějakého "network-order"? Ukázalo se, že stačí změnit typ v těch serializovaných strukturách z "int_32" (apod) na nějaký "struct net_int32", spustit kompiler a rovnou z toho vypadl seznam řádek, kde je to potřeba opravit. Při TDD (bez typů) by ti z toho vypadl seznam spadlých testů, a ty bys pak hledal v kódu, kde to opravit a doufal, že ty testy jsou fakt důsledné.
Většina lidí má asi pocit, že typový systém je nějaký artefakt toho, že je potřeba to nakonec nějak zkompilovat a je potřeba to nějak překladači vysvětlit jak. A dynamické typy berou jako "posun vpřed" - proč mu to vysvětlovat, když si to překladač může zjistit sám. Ten pohled, který se dneska prosazuje, je, že statické typy jsou nástroj pro programátora, který využívá k tomu, aby napsal program s méně chybami, méně zbytečného kódu a vyššími možnostmi abstrakce.
Ale argumentovat Haskellem, že je JS špatně navržený jazyk mi přijde trochu přitažené za vlasy...
Taky jsem nic takového neřekl - JS je špatný z jiných důvodů, než že nemá statické typy. Proti JS jsem argumentoval některými věcmi z Pythonu (ten má taky spoustu much) případně Go (runtime). Ještě by se to dalo srovnávat s Elixirem (ale o tom vím akorát, že existuje), případně Clojure/lisp. Proti tvrzení, že statické typy jsou na nic argumentuji haskellem (a dal by se k tomu přidat asi Rust, ale ten je dost mladý).
-
...
Ještě by se to dalo srovnávat s Elixirem (ale o tom vím akorát, že existuje), případně Clojure/lisp.
...
Srovnavani jakehokoli(ne lisp) jazyka s lispem ma tu nevyhodu, ze vzdycky vyhraje lisp, takze prinos srovnani bude nizky.
;)
-
Je to nuda a pruda? A co si pod tím mám představit? Respektive v čem je ta nuda? A pruda? To mám naopak občas u C/C++, apod. kde "musím" psát každý blbý typ. (nestěžuji si, jen to je prostě občas pomalejší než let x = "ahoj"; )
V C++ to bude auto x = “ahoj”; Písmenko navíc je problém?
-
Type inference je automatická detekce typů a ohledně C jsem našel jen tohle. Takže naopak já bych doporučil vám si zjistit co to je a následně vysvětlit, jak tím u statických jazyků chcete dosáhnout flexibility dynamických typů. To mi jasné není a opakuji, rád se nechám poučit.
V C to není. Jedná se o jazyky, které implementují nějakou variantu třeba tohodle https://en.wikipedia.org/wiki/Hindley%E2%80%93Milner_type_system (https://en.wikipedia.org/wiki/Hindley%E2%80%93Milner_type_system). V podstatě pokud ty typy nejsou moc složitý a polymorfní, tak to toho odvodí docela hodně (nebo i úplně všechno). V praxi se dělá anotace top-level funkcí, což způsobí, že ty chybové hlášky pak nevylítnou někde, kde by to člověk nejmíň čekal a zároveň to většinou stačí, aby kompiler odvodil všechno ostatní.
Tohle chápu, ale tím si jen ušetříš práci s ručním popisem typů a což má dle mně několik dopadů:
a) asi to ušetří trochu práce s psaním kódu
b) asi to sníží počet chybných otypování proměnných (záleží jak moc to funguje a jak dobře je ošetřeno selhání automařiky)
S tím pomáhají i ta céčková makra.
Ale nijak nevidím, jak by to mělo pomoci s omezeními, které sebou nese statický typový systém, jejichž absence dynamickým jazykům zajišťuje jejich vyšší flexibilitu. Pokud někdo jako jediný nebo hlavní rozdíl mezi statickým a dynamickým jazykem vidí nutnost psaní typů, tak dynamickým jazykům nerozumí a neumí je efektivně používat. Popisování typů je marginálie. A pokud někdo chápe rozdíl mezi dynamickým a statickým programováním, nechť mi prosím vysvětlí, jaký přínos v tomto nese type inference. Imho žádný, pokud neumožní věci jako:'
a = 1
a = 1.1
a = 999999999999999999999999999999999999L
a = 'text'
-
Type inference je automatická detekce typů a ohledně C jsem našel jen tohle. Takže naopak já bych doporučil vám si zjistit co to je a následně vysvětlit, jak tím u statických jazyků chcete dosáhnout flexibility dynamických typů. To mi jasné není a opakuji, rád se nechám poučit.
V C to není. Jedná se o jazyky, které implementují nějakou variantu třeba tohodle https://en.wikipedia.org/wiki/Hindley%E2%80%93Milner_type_system (https://en.wikipedia.org/wiki/Hindley%E2%80%93Milner_type_system). V podstatě pokud ty typy nejsou moc složitý a polymorfní, tak to toho odvodí docela hodně (nebo i úplně všechno). V praxi se dělá anotace top-level funkcí, což způsobí, že ty chybové hlášky pak nevylítnou někde, kde by to člověk nejmíň čekal a zároveň to většinou stačí, aby kompiler odvodil všechno ostatní.
Tohle chápu, ale tím si jen ušetříš práci s ručním popisem typů a což má dle mně několik dopadů:
a) asi to ušetří trochu práce s psaním kódu
b) asi to sníží počet chybných otypování proměnných (záleží jak moc to funguje a jak dobře je ošetřeno selhání automařiky)
S tím pomáhají i ta céčková makra.
Ale nijak nevidím, jak by to mělo pomoci s omezeními, které sebou nese statický typový systém, jejichž absence dynamickým jazykům zajišťuje jejich vyšší flexibilitu. Pokud někdo jako jediný nebo hlavní rozdíl mezi statickým a dynamickým jazykem vidí nutnost psaní typů, tak dynamickým jazykům nerozumí a neumí je efektivně používat. Popisování typů je marginálie. A pokud někdo chápe rozdíl mezi dynamickým a statickým programováním, nechť mi prosím vysvětlí, jaký přínos v tomto nese type inference. Imho žádný, pokud neumožní věci jako:'
a = 1
a = 1.1
a = 999999999999999999999999999999999999L
a = 'text'
Dynamické typování není flexibilnější, jen umožňuje chyby a prasárny jako kód výše. A když už někdo chce mermomocí prasit, může použít any/dynamic.
-
Dynamické typování není flexibilnější, jen umožňuje chyby a prasárny jako kód výše. A když už někdo chce mermomocí prasit, může použít any/dynamic.
Ani ja uprimne nechapu tu ohromnou vyhodu, kterou ma prinest moznost postupne do te same promenne prirazovat uplne odlisne typy. A nemusi jit ani o ten extremni pripad od eee - (staticke) funkcionalni jazyky resi nulovatelnost pomoci Option/Maybe a dve ruzne moznosti pomoci Either/Result. "Vyhoda" dynamickych jazyku v teto konkretni veci je v tom, ze autori jazyku i programu v nich nemusi moc premyslet a ono jim to tak nejak (vetsinou) vyjde. Vyjimecne se to hodit muze, ale obecne je to spis z nouze ctnost.
-
Při TDD (bez typů) by ti z toho vypadl seznam spadlých testů, a ty bys pak hledal v kódu, kde to opravit a doufal, že ty testy jsou fakt důsledné.
Ale blbost.
a) při testu ti chybové hlášení přesně řekne kde máš chybu
b) není důvod aby to padalo, pokud to nemáš napsané špatně a používáš stejné rozhraní nad různými daty, takže ti stačí pro nová data upravit akorát objekt, který je nese
-
Type inference je automatická detekce typů a ohledně C jsem našel jen tohle. Takže naopak já bych doporučil vám si zjistit co to je a následně vysvětlit, jak tím u statických jazyků chcete dosáhnout flexibility dynamických typů. To mi jasné není a opakuji, rád se nechám poučit.
V C to není. Jedná se o jazyky, které implementují nějakou variantu třeba tohodle https://en.wikipedia.org/wiki/Hindley%E2%80%93Milner_type_system (https://en.wikipedia.org/wiki/Hindley%E2%80%93Milner_type_system). V podstatě pokud ty typy nejsou moc složitý a polymorfní, tak to toho odvodí docela hodně (nebo i úplně všechno). V praxi se dělá anotace top-level funkcí, což způsobí, že ty chybové hlášky pak nevylítnou někde, kde by to člověk nejmíň čekal a zároveň to většinou stačí, aby kompiler odvodil všechno ostatní.
Tohle chápu, ale tím si jen ušetříš práci s ručním popisem typů a což má dle mně několik dopadů:
a) asi to ušetří trochu práce s psaním kódu
b) asi to sníží počet chybných otypování proměnných (záleží jak moc to funguje a jak dobře je ošetřeno selhání automařiky)
S tím pomáhají i ta céčková makra.
Ale nijak nevidím, jak by to mělo pomoci s omezeními, které sebou nese statický typový systém, jejichž absence dynamickým jazykům zajišťuje jejich vyšší flexibilitu. Pokud někdo jako jediný nebo hlavní rozdíl mezi statickým a dynamickým jazykem vidí nutnost psaní typů, tak dynamickým jazykům nerozumí a neumí je efektivně používat. Popisování typů je marginálie. A pokud někdo chápe rozdíl mezi dynamickým a statickým programováním, nechť mi prosím vysvětlí, jaký přínos v tomto nese type inference. Imho žádný, pokud neumožní věci jako:'
a = 1
a = 1.1
a = 999999999999999999999999999999999999L
a = 'text'
Dynamické typování není flexibilnější, jen umožňuje chyby a prasárny jako kód výše. A když už někdo chce mermomocí prasit, může použít any/dynamic.
To je prasárna jen z pohledu statického progamátora, který má zafixováno paradigma, že proměnná je svázaná s datovým typem a už neumí myslet jinak. Statický programátor nechápe flexibilitu dynamického jazyka a neumí ji využít ani když ji má k dispozici, je omezen ne jazykem, ale vlastním myšlením. Proto ty tragické dopady, když si pak sednou k něčemu jako Python, ale stejně se v něm snaží programovat staticky. Statický programátot proto nevnímá ímšzení statických jazyků a flexibilitu těch dynamických. Naopak to neplatí, statické jazyky dynamického programátora omezují, nutí ho implementivat těžkopádná řešení. V dynamickém jazyku je proměná jen něco jako ukazatel na datový objekt, který si informaci o svém typu nese stále s sebou. Výhodou statických jazyků jsou možnosti optimalizace a výkonu. Co se týče any, bavíme se stále o statickém C nebo už něčem jiném, případně o čem?
-
Ani ja uprimne nechapu tu ohromnou vyhodu, kterou ma prinest moznost postupne do te same promenne prirazovat uplne odlisne typy. A nemusi jit ani o ten extremni pripad od eee - (staticke) funkcionalni jazyky resi nulovatelnost pomoci Option/Maybe a dve ruzne moznosti pomoci Either/Result. "Vyhoda" dynamickych jazyku v teto konkretni veci je v tom, ze autori jazyku i programu v nich nemusi moc premyslet a ono jim to tak nejak (vetsinou) vyjde. Vyjimecne se to hodit muze, ale obecne je to spis z nouze ctnost.
A asi to ani nikdy nepochopíš, musel bys úplně změnit pohled na programování, zapomenout na své osvědčené postupy jak algoritmizuješ úlohy, které používáš automaticky a už o nich ani nepřemýšlíš.
V dynamickém jazyku nejsou proměnné důležité, pracuješ v něm s hodnotami, nikoliv proměnnými. A možná to více oceníš, když si uvědomíš, že nejde jen o pojmenované proměnné, ale i ty anonymní, listy, slovníký, generátory, návratové hodnoty funkcí. To vše pracuje primárně s variabilními hodnotami. Je to něco jako nákupní taška, kam si dáš libovolné zboží jaké zrovna potřebuješ. Pro statického programátora hrůzná představa, ten za normální považuje, že má tašku na rohlíky, tašku na mlíka, tašku ha piva a přijde mu, že je velmi prasácké mít všechno v jedné tašce a nemá z toho dobrý pocit. Ale je to dáno jen tím, jak je vychovaný a jak je naučený myslet.
-
Ani ja uprimne nechapu tu ohromnou vyhodu, kterou ma prinest moznost postupne do te same promenne prirazovat uplne odlisne typy. A nemusi jit ani o ten extremni pripad od eee - (staticke) funkcionalni jazyky resi nulovatelnost pomoci Option/Maybe a dve ruzne moznosti pomoci Either/Result. "Vyhoda" dynamickych jazyku v teto konkretni veci je v tom, ze autori jazyku i programu v nich nemusi moc premyslet a ono jim to tak nejak (vetsinou) vyjde. Vyjimecne se to hodit muze, ale obecne je to spis z nouze ctnost.
A asi to ani nikdy nepochopíš, musel bys úplně změnit pohled na programování, zapomenout na své osvědčené postupy jak algoritmizuješ úlohy, které používáš automaticky a už o nich ani nepřemýšlíš.
V dynamickém jazyku nejsou proměnné důležité, pracuješ v něm s hodnotami, nikoliv proměnnými. A možná to více oceníš, když si uvědomíš, že nejde jen o pojmenované proměnné, ale i ty anonymní, listy, slovníký, generátory, návratové hodnoty funkcí. To vše pracuje primárně s variabilními hodnotami. Je to něco jako nákupní taška, kam si dáš libovolné zboží jaké zrovna potřebuješ. Pro statického programátora hrůzná představa, ten za normální považuje, že má tašku na rohlíky, tašku na mlíka, tašku ha piva a přijde mu, že je velmi prasácké mít všechno v jedné tašce a nemá z toho dobrý pocit. Ale je to dáno jen tím, jak je vychovaný a jak je naučený myslet.
Tohle mne poněkud dráždí. Kde se vzala ta zažraná představa, že ve staticky typovaném jazyce pracuji s proměnnými? V Haskellu samozřejmě pracuji primárně s hodnotami. Proměnné jsou tam jen v případě nutnosti, kdy potřebuješ něco někam přehodit.
Chci slyšet tu skutečnou výhodu, v čem je dynamický jazyk výhodnější. Tohle je nesmysl.
-
Pro statického programátora hrůzná představa, ten za normální považuje, že má tašku na rohlíky, tašku na mlíka, tašku ha piva a přijde mu, že je velmi prasácké mít všechno v jedné tašce a nemá z toho dobrý pocit. Ale je to dáno jen tím, jak je vychovaný a jak je naučený myslet.
a ten statický programátor používá jaký jazyk? nebo jazyky
-
To je prasárna jen z pohledu statického progamátora, který má zafixováno paradigma, že proměnná je svázaná s datovým typem a už neumí myslet jinak. Statický programátor nechápe flexibilitu dynamického jazyka a neumí ji využít ani když ji má k dispozici, je omezen ne jazykem, ale vlastním myšlením. Proto ty tragické dopady, když si pak sednou k něčemu jako Python, ale stejně se v něm snaží programovat staticky. Statický programátot proto nevnímá ímšzení statických jazyků a flexibilitu těch dynamických. Naopak to neplatí, statické jazyky dynamického programátora omezují, nutí ho implementivat těžkopádná řešení. V dynamickém jazyku je proměná jen něco jako ukazatel na datový objekt, který si informaci o svém typu nese stále s sebou. Výhodou statických jazyků jsou možnosti optimalizace a výkonu. Co se týče any, bavíme se stále o statickém C nebo už něčem jiném, případně o čem?
Jako člověk, který se profesně živí dynamickými jazyky (Javascript, Python, PHP, Lua) bych měl zájem o vysvětlení, v čem jsou ty dynamické jazyky výhodnější. Víše uvedený popis je spíš takový esoterický kec, než vysvětlení.
-
To je prasárna jen z pohledu statického progamátora, který má zafixováno paradigma, že proměnná je svázaná s datovým typem a už neumí myslet jinak. Statický programátor nechápe flexibilitu dynamického jazyka a neumí ji využít ani když ji má k dispozici, je omezen ne jazykem, ale vlastním myšlením. Proto ty tragické dopady, když si pak sednou k něčemu jako Python, ale stejně se v něm snaží programovat staticky. Statický programátot proto nevnímá ímšzení statických jazyků a flexibilitu těch dynamických. Naopak to neplatí, statické jazyky dynamického programátora omezují, nutí ho implementivat těžkopádná řešení. V dynamickém jazyku je proměná jen něco jako ukazatel na datový objekt, který si informaci o svém typu nese stále s sebou. Výhodou statických jazyků jsou možnosti optimalizace a výkonu. Co se týče any, bavíme se stále o statickém C nebo už něčem jiném, případně o čem?
Jako člověk, který se profesně živí dynamickými jazyky (Javascript, Python, PHP, Lua) bych měl zájem o vysvětlení, v čem jsou ty dynamické jazyky výhodnější. Víše uvedený popis je spíš takový esoterický kec, než vysvětlení.
Me prijde, ze v dynamickych jazycich je levnejsi polymorfismus.
-
Type inference je automatická detekce typů a ohledně C jsem našel jen tohle. Takže naopak já bych doporučil vám si zjistit co to je a následně vysvětlit, jak tím u statických jazyků chcete dosáhnout flexibility dynamických typů. To mi jasné není a opakuji, rád se nechám poučit.
V C to není. Jedná se o jazyky, které implementují nějakou variantu třeba tohodle https://en.wikipedia.org/wiki/Hindley%E2%80%93Milner_type_system (https://en.wikipedia.org/wiki/Hindley%E2%80%93Milner_type_system). V podstatě pokud ty typy nejsou moc složitý a polymorfní, tak to toho odvodí docela hodně (nebo i úplně všechno). V praxi se dělá anotace top-level funkcí, což způsobí, že ty chybové hlášky pak nevylítnou někde, kde by to člověk nejmíň čekal a zároveň to většinou stačí, aby kompiler odvodil všechno ostatní.
Tohle chápu, ale tím si jen ušetříš práci s ručním popisem typů a což má dle mně několik dopadů:
a) asi to ušetří trochu práce s psaním kódu
b) asi to sníží počet chybných otypování proměnných (záleží jak moc to funguje a jak dobře je ošetřeno selhání automařiky)
S tím pomáhají i ta céčková makra.
Ale nijak nevidím, jak by to mělo pomoci s omezeními, které sebou nese statický typový systém, jejichž absence dynamickým jazykům zajišťuje jejich vyšší flexibilitu. Pokud někdo jako jediný nebo hlavní rozdíl mezi statickým a dynamickým jazykem vidí nutnost psaní typů, tak dynamickým jazykům nerozumí a neumí je efektivně používat. Popisování typů je marginálie. A pokud někdo chápe rozdíl mezi dynamickým a statickým programováním, nechť mi prosím vysvětlí, jaký přínos v tomto nese type inference. Imho žádný, pokud neumožní věci jako:'
a = 1
a = 1.1
a = 999999999999999999999999999999999999L
a = 'text'
Dynamické typování není flexibilnější, jen umožňuje chyby a prasárny jako kód výše. A když už někdo chce mermomocí prasit, může použít any/dynamic.
To je prasárna jen z pohledu statického progamátora, který má zafixováno paradigma, že proměnná je svázaná s datovým typem a už neumí myslet jinak. Statický programátor nechápe flexibilitu dynamického jazyka a neumí ji využít ani když ji má k dispozici, je omezen ne jazykem, ale vlastním myšlením. Proto ty tragické dopady, když si pak sednou k něčemu jako Python, ale stejně se v něm snaží programovat staticky. Statický programátot proto nevnímá ímšzení statických jazyků a flexibilitu těch dynamických. Naopak to neplatí, statické jazyky dynamického programátora omezují, nutí ho implementivat těžkopádná řešení. V dynamickém jazyku je proměná jen něco jako ukazatel na datový objekt, který si informaci o svém typu nese stále s sebou. Výhodou statických jazyků jsou možnosti optimalizace a výkonu. Co se týče any, bavíme se stále o statickém C nebo už něčem jiném, případně o čem?
Ona už je prasárna pojmenovat proměnnou a, neřkuli rvát do ní hodnoty různých typů.
-
Jako člověk, který se profesně živí dynamickými jazyky (Javascript, Python, PHP, Lua) bych měl zájem o vysvětlení, v čem jsou ty dynamické jazyky výhodnější. Víše uvedený popis je spíš takový esoterický kec, než vysvětlení.
Me prijde, ze v dynamickych jazycich je levnejsi polymorfismus.
OK. Můžeš to prosím rozvést?
Jediný případ, kdy jsem se setkal, že ta dynamičnost byla k něčemu, byl Erlang. Protože tam se opravdu dalo real-time opravovat chyby. Prostě se ten aktor kousl, a čekal, dokavad jsi to neopravil. Ostatní vesele běhali, maximálně se teda ta chyba rozjela. V Pythonu, ani v Javascriptu tohlencto nejde.
-
To je prasárna jen z pohledu statického progamátora, který má zafixováno paradigma, že proměnná je svázaná s datovým typem a už neumí myslet jinak. Statický programátor nechápe flexibilitu dynamického jazyka a neumí ji využít ani když ji má k dispozici, je omezen ne jazykem, ale vlastním myšlením. Proto ty tragické dopady, když si pak sednou k něčemu jako Python, ale stejně se v něm snaží programovat staticky. Statický programátot proto nevnímá ímšzení statických jazyků a flexibilitu těch dynamických. Naopak to neplatí, statické jazyky dynamického programátora omezují, nutí ho implementivat těžkopádná řešení. V dynamickém jazyku je proměná jen něco jako ukazatel na datový objekt, který si informaci o svém typu nese stále s sebou. Výhodou statických jazyků jsou možnosti optimalizace a výkonu. Co se týče any, bavíme se stále o statickém C nebo už něčem jiném, případně o čem?
Jako člověk, který se profesně živí dynamickými jazyky (Javascript, Python, PHP, Lua) bych měl zájem o vysvětlení, v čem jsou ty dynamické jazyky výhodnější. Víše uvedený popis je spíš takový esoterický kec, než vysvětlení.
Není to ezoterické, ale abstraktní. Změnit lidem myšlení, přimět je dívat se na věci úplně jiným pohledem je těžké, protože to není věc racionální znalosti informací, ale spíše procesu nebo způsobu uvažování a přirozenost člověka je taková, te se tomu z jistých důvodů podvědomě brání a to platí obecně, nejen v programování.
Dynamické jazyky jsou výhodnější ve své flexibilitě, ve své přirozenější a jednodušší schopnosti vyjadřování, které je bližší přirozenému lidskému uvažování. Nemají to zadarmo, je to vzdálenější strojovému zpracování dat a platí se za to výkonem. Nemusí to vyhovovat lidem s různými poruchami myšlení, kteří mezi běžnou moc nezapadají a kterým může být strojové myšlení bližší. Mezi programátory je takových asociálů asi zvýšené množství, alespoň mají takovou pověst a má to logické zdůvodnění. U nich ten odpor k dynamickým jazykům a adorace těch statických pochopitelná. Pro ně jsou statické jazyky lepší, ale chybí jim nadhled, který by jim pomohl rozpoznat, že se jedná o osobní preference, které nemohou zobecňovat.
-
To je prasárna jen z pohledu statického progamátora, který má zafixováno paradigma, že proměnná je svázaná s datovým typem a už neumí myslet jinak. Statický programátor nechápe flexibilitu dynamického jazyka a neumí ji využít ani když ji má k dispozici, je omezen ne jazykem, ale vlastním myšlením. Proto ty tragické dopady, když si pak sednou k něčemu jako Python, ale stejně se v něm snaží programovat staticky. Statický programátot proto nevnímá ímšzení statických jazyků a flexibilitu těch dynamických. Naopak to neplatí, statické jazyky dynamického programátora omezují, nutí ho implementivat těžkopádná řešení. V dynamickém jazyku je proměná jen něco jako ukazatel na datový objekt, který si informaci o svém typu nese stále s sebou. Výhodou statických jazyků jsou možnosti optimalizace a výkonu. Co se týče any, bavíme se stále o statickém C nebo už něčem jiném, případně o čem?
Jako člověk, který se profesně živí dynamickými jazyky (Javascript, Python, PHP, Lua) bych měl zájem o vysvětlení, v čem jsou ty dynamické jazyky výhodnější. Víše uvedený popis je spíš takový esoterický kec, než vysvětlení.
Me prijde, ze v dynamickych jazycich je levnejsi polymorfismus.
To je nesmysl, v čem by to mělo být levnější? A jaký polymorfismus, statický ani parametrický to nemá, leda ad hoc, kde to vyjde nastejno.
-
Ona už je prasárna pojmenovat proměnnou a, neřkuli rvát do ní hodnoty různých typů.
To přece záleží na okolnostech, v krátké ukázce takové pojmenování ničemu nevadí. Nebuď rigidní a používej pravidla s pochopením jejich účelu. V dynamických jazycích se s hodnotami různých typů zachází volně a není to prasárna. Kdo tohle nedokáže pochopit, ten ani nedokáže pochopit, že typová inference vlastně nic podstatného neřeší. Abychom se vrátili ke kořenům této debaty.
-
To je prasárna jen z pohledu statického progamátora, který má zafixováno paradigma, že proměnná je svázaná s datovým typem a už neumí myslet jinak. Statický programátor nechápe flexibilitu dynamického jazyka a neumí ji využít ani když ji má k dispozici, je omezen ne jazykem, ale vlastním myšlením. Proto ty tragické dopady, když si pak sednou k něčemu jako Python, ale stejně se v něm snaží programovat staticky. Statický programátot proto nevnímá ímšzení statických jazyků a flexibilitu těch dynamických. Naopak to neplatí, statické jazyky dynamického programátora omezují, nutí ho implementivat těžkopádná řešení. V dynamickém jazyku je proměná jen něco jako ukazatel na datový objekt, který si informaci o svém typu nese stále s sebou. Výhodou statických jazyků jsou možnosti optimalizace a výkonu. Co se týče any, bavíme se stále o statickém C nebo už něčem jiném, případně o čem?
Jako člověk, který se profesně živí dynamickými jazyky (Javascript, Python, PHP, Lua) bych měl zájem o vysvětlení, v čem jsou ty dynamické jazyky výhodnější. Víše uvedený popis je spíš takový esoterický kec, než vysvětlení.
Není to ezoterické, ale abstraktní. Změnit lidem myšlení, přimět je dívat se na věci úplně jiným pohledem je těžké, protože to není věc racionální znalosti informací, ale spíše procesu nebo způsobu uvažování a přirozenost člověka je taková, te se tomu z jistých důvodů podvědomě brání a to platí obecně, nejen v programování.
Dynamické jazyky jsou výhodnější ve své flexibilitě, ve své přirozenější a jednodušší schopnosti vyjadřování, které je bližší přirozenému lidskému uvažování. Nemají to zadarmo, je to vzdálenější strojovému zpracování dat a platí se za to výkonem. Nemusí to vyhovovat lidem s různými poruchami myšlení, kteří mezi běžnou moc nezapadají a kterým může být strojové myšlení bližší. Mezi programátory je takových asociálů asi zvýšené množství, alespoň mají takovou pověst a má to logické zdůvodnění. U nich ten odpor k dynamickým jazykům a adorace těch statických pochopitelná. Pro ně jsou statické jazyky lepší, ale chybí jim nadhled, který by jim pomohl rozpoznat, že se jedná o osobní preference, které nemohou zobecňovat.
Jak říkám, esoterika.
Mám rád jazyk Thue (https://cs.wikipedia.org/wiki/Ezoterický_programovac%C3%AD_jazyk#Thue). Je výhodnější ve své flexibilitě, ve své přirozenější a jednodušší schopnosti vyjadřování, které je bližší přirozenému lidskému uvažování. Nemá to zadarmo, je to vzdálenější strojovému zpracování dat a platí se za to výkonem. Nemusí to vyhovovat lidem s různými poruchami myšlení, kteří mezi běžnou moc nezapadají a kterým může být strojové myšlení bližší. Mezi programátory je takových asociálů asi zvýšené množství, alespoň mají takovou pověst a má to logické zdůvodnění. U nich ten odpor k dynamickým jazykům a adorace těch statických pochopitelná. Pro ně jsou statické jazyky lepší, ale chybí jim nadhled, který by jim pomohl rozpoznat, že se jedná o osobní preference, které nemohou zobecňovat.
-
Jak říkám, esoterika.
Lidská mysl si vyvinula řadu strategií, kterými se brání změně myšlení. Neočekávám v této diskusi, že by tu někdo k něčemu takovému dospěl :-).
-
Jak říkám, esoterika.
Lidská mysl si vyvinula řadu strategií, kterými se brání změně myšlení. Neočekávám v této diskusi, že by tu někdo k něčemu takovému dospěl :-).
Tak to chápeš špatně.
Za prvé, máš pravdu, lidská mysl se přirozeně brání změně. Na to jsou studie. Ale otázka je, zda ten problém mám já, neby ty.
Za druhé, jak jsem psal, tak mě živí programování v dynamických jazycích. A tudíž bych samozřejmě uvítal, možná i zaplatil, když by mi někdo ukázal, v čem dělám chybu v úvaze. Protože, co si budem nalhávat, proč bych měl programovat s utrpením, když bych mohl programovat s potěšením.
-
proč bych měl programovat s utrpením, když bych mohl programovat s potěšením
no pain, no gain
-
proč bych měl programovat s utrpením, když bych mohl programovat s potěšením
no pain, no gain
Takže když se u programování budu mlátit kladivem do prstů, tak budu tvořit kvalitnější kód? OK.
-
A asi to ani nikdy nepochopíš, musel bys úplně změnit pohled na programování, zapomenout na své osvědčené postupy jak algoritmizuješ úlohy, které používáš automaticky a už o nich ani nepřemýšlíš.
V dynamickém jazyku nejsou proměnné důležité, pracuješ v něm s hodnotami, nikoliv proměnnými. A možná to více oceníš, když si uvědomíš, že nejde jen o pojmenované proměnné, ale i ty anonymní, listy, slovníký, generátory, návratové hodnoty funkcí. To vše pracuje primárně s variabilními hodnotami. Je to něco jako nákupní taška, kam si dáš libovolné zboží jaké zrovna potřebuješ. Pro statického programátora hrůzná představa, ten za normální považuje, že má tašku na rohlíky, tašku na mlíka, tašku ha piva a přijde mu, že je velmi prasácké mít všechno v jedné tašce a nemá z toho dobrý pocit. Ale je to dáno jen tím, jak je vychovaný a jak je naučený myslet.
Sorry, ale tohle jsou hrozné kydy. Programuju v dynamickém jazyku snad déle než Ty, ale jakkoli je mi jasné, že v kontejneru můžu mít vedle sebe jabka s hruškama a pytli dalších jablek a hrušek a vedle toho ještě i rezavý hřebík a mrtvolu křečka, běžně se to nedělá a to z dobrého důvodu. Aby se v tom člověk vyznal a nedělalo mu to za zády něco, co neočekává. A zrovna tak identifikátor není kýbl na sr.čky, ale pomůcka k tomu, aby se člověk v kódu vyznal a proto by mělo obsah co nejlépe a nejjednoznačněji popsat a jelikož mám obsah identifikátorem popsaný, tak ctím, co říká a nedávám tam něco jiného.
-
typová inference vlastně nic podstatného neřeší
::)
-
Jeden z mých oblíbených postupů na vytváření kolekcí hodnot s kratkou zivotnosti je tento:
import pickle
class MessageData: pass
...
md = MessageData()
md.type = ... // number, string
md.sub_type = ... // number, string
md.session = session
md.data = data // number, string, array, object, ...
message_data = pickle.dumps(md)
// dalsi polozky se pridavaji dle potreby
...
Vznikají tak velmi snadno a rychle funkcni prototypy aplikací v testovacim prostredi, ktere se ukazi koncovemu uzivateli a casto se hned na miste interaktivne doladi. Zkuste neco podobneho delat v C.
-
Jak říkám, esoterika.
Lidská mysl si vyvinula řadu strategií, kterými se brání změně myšlení. Neočekávám v této diskusi, že by tu někdo k něčemu takovému dospěl :-).
Tak to chápeš špatně.
Za prvé, máš pravdu, lidská mysl se přirozeně brání změně. Na to jsou studie. Ale otázka je, zda ten problém mám já, neby ty.
Za druhé, jak jsem psal, tak mě živí programování v dynamických jazycích. A tudíž bych samozřejmě uvítal, možná i zaplatil, když by mi někdo ukázal, v čem dělám chybu v úvaze. Protože, co si budem nalhávat, proč bych měl programovat s utrpením, když bych mohl programovat s potěšením.
Ten problem maji obecne vsichni, takze i my oba. Ale co se tyce statickych/dynamickych jazyku, tak tam mas problem ty, ja mam rad a synergicky vyuzivam oboji. Ale mam treba problem s funkcionalnimi jazyky. Byt zabedneny, tak se proti nim vyhranuji a odsuzuji je, takhle si jen rikam, ze nejsou pro me, nejsem s nimi mentalne kompatibilni. Ty programujes s utrpenim? Ja jsem tim stale vice nadsenejsi. Jestli chces zmenu, zkus vic otevrit svou mysl, na misto odsuzovani.
-
Jako člověk, který se profesně živí dynamickými jazyky (Javascript, Python, PHP, Lua) bych měl zájem o vysvětlení, v čem jsou ty dynamické jazyky výhodnější. Víše uvedený popis je spíš takový esoterický kec, než vysvětlení.
Me prijde, ze v dynamickych jazycich je levnejsi polymorfismus.
OK. Můžeš to prosím rozvést?
Zkusim.
Mam funkci ktera umi pracovat s nejakym typem vstupu.
Chci ji rozsirit, aby umela zpracovat i nejaky dalsi typ vstupu.
U dynamicky typovaneho jazyka upravim telo funkce. (Idealne ani to ne, v clojure muzu pouzit multimethod a dispatch podle ceho se mi zamane na konkretni implementaci).
U staticky typovaneho musim upravit i signaturu, nebo vymyslet ze novy typ vstupu je subtyp nejakeho jiz podporovaneho.
Cim presneji specifikuju typ vstupu tim vic omezuju definicni obor a tim snizuju moznost polymorfismu.
-
Ad dynamické vs. statické jazyky (s hodně dobrým typovým systémem typu Haskell)
Typování obecně zabrání některým validním programům běžet. Typický příklad:
if (true) then 1 else "no"Tohle prostě staticky typovaným jazykem neprojde, přestože to je validní program. Samozřejmě díky tomu je dynamický jazyk "flexibilnější"; a je to strašná prasárna. Takže asi není čím se chlubit...
eee, můžeš poskytnout nějaký kus kódu, který ti přijde jako ukázka toho, jak je dynamický jazyk flexibilnější? IMO zapomínáš, že v těch jazycích, o kterých se bavíme, je podpora pro algebraické datové typy (a kdyby to nestačilo, tak generalizované algebraické datové typy...), která IMO tu flexibilitu, kterou máš na mysli, naprosto uspokojivě řeší.
Mam funkci ktera umi pracovat s nejakym typem vstupu.
Chci ji rozsirit, aby umela zpracovat i nejaky dalsi typ vstupu.
U dynamicky typovaneho jazyka upravim telo funkce. (Idealne ani to ne, v clojure muzu pouzit multimethod a dispatch podle ceho se mi zamane na konkretni implementaci).
U staticky typovaneho musim upravit i signaturu, nebo vymyslet ze novy typ vstupu je subtyp nejakeho jiz podporovaneho.
Cim presneji specifikuju typ vstupu tim vic omezuju definicni obor a tim snizuju moznost polymorfismu.
Máš na mysli třeba toto?
encode :: ToJSON a => a -> ByteString
Aneb "vezmi hodnotu, která se umí zakódovat do JSONu a zakóduj ji"? A následně když to chci rozšířit třeba pro nějaký nový typ vstupu - "Jidlo", tak udělám:
data Jidlo = Mliko | Rohlik | Jablko
-- Genericka instance, zakoduje jako stringy:
instance ToJSON Jidlo
-- Nebo custom instance, zakoduje jak potrebuju
instance ToJSON Jidlo where
toJSON Mliko = toJSON "mlicko"
toJSON Rohlik = toJSON "rohlicek"
toJSON Jablko = toJSON "jablicko"
Asi tak?
-
zkus vic otevrit svou mysl,
Není čemu.
-
A asi to ani nikdy nepochopíš, musel bys úplně změnit pohled na programování, zapomenout na své osvědčené postupy jak algoritmizuješ úlohy, které používáš automaticky a už o nich ani nepřemýšlíš.
V dynamickém jazyku nejsou proměnné důležité, pracuješ v něm s hodnotami, nikoliv proměnnými. A možná to více oceníš, když si uvědomíš, že nejde jen o pojmenované proměnné, ale i ty anonymní, listy, slovníký, generátory, návratové hodnoty funkcí. To vše pracuje primárně s variabilními hodnotami. Je to něco jako nákupní taška, kam si dáš libovolné zboží jaké zrovna potřebuješ. Pro statického programátora hrůzná představa, ten za normální považuje, že má tašku na rohlíky, tašku na mlíka, tašku ha piva a přijde mu, že je velmi prasácké mít všechno v jedné tašce a nemá z toho dobrý pocit. Ale je to dáno jen tím, jak je vychovaný a jak je naučený myslet.
Sorry, ale tohle jsou hrozné kydy. Programuju v dynamickém jazyku snad déle než Ty, ale jakkoli je mi jasné, že v kontejneru můžu mít vedle sebe jabka s hruškama a pytli dalších jablek a hrušek a vedle toho ještě i rezavý hřebík a mrtvolu křečka, běžně se to nedělá a to z dobrého důvodu. Aby se v tom člověk vyznal a nedělalo mu to za zády něco, co neočekává. A zrovna tak identifikátor není kýbl na sr.čky, ale pomůcka k tomu, aby se člověk v kódu vyznal a proto by mělo obsah co nejlépe a nejjednoznačněji popsat a jelikož mám obsah identifikátorem popsaný, tak ctím, co říká a nedávám tam něco jiného.
Nemas pravdu. Neni duvod, proc by ses v tom nemel vyznat. Typicky priklad je binding hodnot pro SQL, ktery predavam nebo ziskavam jako objekt, a je to prirozena kolekce nahodnych dat ruznych typu. Nebo se bezne zpracovavaji data z excelu, kdy zaznam (radek) je opet nahodnou smesi hodnot ruznych datovych typu (text, cislo, datum, mena, kde navic rozlisujes i vyznam textu a cisel a prirazujes jim vlastni datove typy). Vhodne zvoleny nazev identifikatoru je dulezity a je na tobe abys zvolil takovy, ktery bude mit odpovidajici abstrakci a nematl te. To se nijak nevylucuje s efektivnim vyuzivanim dynamickych datovych typu. Takze si mohu vytvorit datovy typ pro kontejner SQLData a v nem budu ocekavat libovolnou kolekci atributu jak co se tyce nazvu identifikatoru (odpovádaji nazvum sloupcu tabulky) tak jejich typovych hodnot. Obdobne mohu mit komplexni XLSRecord/XLSValue s metadaty kazde hodnoty nebo jednoduchy CSVRecord. V prirozenem svete bezne pracujes s kolekcemi hodnot ruznych typu a neni dvod, proc by ti to melo delat problem pri programovani, naopak to pomahá lepe vystihnout chaos realneho sveta.
-
Nemas pravdu. Neni duvod, proc by ses v tom nemel vyznat. Typicky priklad je binding hodnot pro SQL, ktery predavam nebo ziskavam jako objekt, a je to prirozena kolekce nahodnych dat ruznych typu.
Tomu nerozumím. Jako třeba:
data Row = Row {
ident :: Int
, name :: Text
, age :: int
..etc
}
V statických jazycích se tomu říká struct..? A pomáhá to zorganizovat chaos reálného světa a nezbláznit se v tom, co do té sql řádky dávám..?
-
Typování obecně zabrání některým validním programům běžet. Typický příklad:
if (true) then 1 else "no"Tohle prostě staticky typovaným jazykem neprojde, přestože to je validní program. Samozřejmě díky tomu je dynamický jazyk "flexibilnější"; a je to strašná prasárna. Takže asi není čím se chlubit...
Není to prasárna, jen se na to podívej abstraktněji:
promenna = (podminka) ? datovy_typ1 : datovy_typ2
Na tom přece nic špatného není. Třeba když datovy_typ2 je None. Nebo ty datové typy jsou muz a zena, nebo html a pdf, a pak bys také mohl mít třeba toto:
levy = (typeof(pravy) == int) ? int(levy) : str(levy)
Já si bežně z funkcí které čtou data vracím hodnotu false, pokud funkce selže, None pokud data nejsou nebo datový objekt - tedy tři různé datové typy. Není to o nic horší, než návratový číselný kód z C funkce, která možná změní obsah proměnné předané funkci a pro získání chybového textu je nutné volat zvláštní funkci.
-
Máš na mysli třeba toto?
encode :: ToJSON a => a -> ByteString
Aneb "vezmi hodnotu, která se umí zakódovat do JSONu a zakóduj ji"? A následně když to chci rozšířit třeba pro nějaký nový typ vstupu - "Jidlo", tak udělám:
data Jidlo = Mliko | Rohlik | Jablko
-- Genericka instance, zakoduje jako stringy:
instance ToJSON Jidlo
-- Nebo custom instance, zakoduje jak potrebuju
instance ToJSON Jidlo where
toJSON Mliko = toJSON "mlicko"
toJSON Rohlik = toJSON "rohlicek"
toJSON Jablko = toJSON "jablicko"
Asi tak?
To je vzhuru nohama. Ty menis typ, aby se dal poslat funkci. Ja jsem mluvil o pripadu kdy menim funkci aby umela zpracovat novy typ. Je to spis o pripadech kdy mam typ definovany externe a chci ho ve svem kodu umet pouzit.
Nedavno jsem resil nejake zpracovani exif dat u fotek. Kazdy vyrobce ma sve vlastni tagy. Narazil jsem na fotku ktera mela nejaka data v tagu, ktery jsem zatim neznal a tak jsem proste pridal defmethod s dispatch value :manufacturer "kodak" (nebo neco takoveho) a uz to frcelo.
-
Není to prasárna, jen se na to podívej abstraktněji:
promenna = (podminka) ? datovy_typ1 : datovy_typ2
Na tom přece nic špatného není. Třeba když datovy_typ2 je None. Nebo ty datové typy jsou muz a zena, nebo html a pdf, a pak bys také mohl mít třeba toto:
levy = (typeof(pravy) == int) ? int(levy) : str(levy)
Já si bežně z funkcí které čtou data vracím hodnotu false, pokud funkce selže, None pokud data nejsou nebo datový objekt - tedy tři různé datové typy. Není to o nic horší, než návratový číselný kód z C funkce, která možná změní obsah proměnné předané funkci a pro získání chybového textu je nutné volat zvláštní funkci.
Víš proč se NullPointerException říká "million dolar mistake"..? Asi nevíš.... Ano, je to strašné. Je to úplně příšerné. Třeba z toho důvodu, že když vůbec chceš vědět, co se z té funkce vrací, tak se do ní musíš podívat. Ty type inference enginy (které tak děsně vychvaloval tvůj oblíbenec) ti na tom budou řvát, že to máš blbě. A teď je samozřejmě otázka, jak to dělat "dobře", když se bavíme o statických jazycích. Dělá se to pomocí algebraických datových typů - konkrétně součtového typu, který bohužel právě v C/C++/Java není. A vypadá to následovně:
data Result a = Data a | NoData | GotError text
mojefunkce :: Nejaky_vstupni_typ -> Result Navratovy typ
mojefunkce vstupni_data
| jsou_chybna vstupni_data = GotError "Chybna vstupni data"
| nedostaneme_vysledek vstupni_data = NoData
| otherwise = Data (spocitej_vysledek vstupni_data)
-
Není to prasárna, jen se na to podívej abstraktněji:
promenna = (podminka) ? datovy_typ1 : datovy_typ2
Na tom přece nic špatného není. Třeba když datovy_typ2 je None. Nebo ty datové typy jsou muz a zena, nebo html a pdf, a pak bys také mohl mít třeba toto:
levy = (typeof(pravy) == int) ? int(levy) : str(levy)
Já si bežně z funkcí které čtou data vracím hodnotu false, pokud funkce selže, None pokud data nejsou nebo datový objekt - tedy tři různé datové typy. Není to o nic horší, než návratový číselný kód z C funkce, která možná změní obsah proměnné předané funkci a pro získání chybového textu je nutné volat zvláštní funkci.
Dělá se to pomocí algebraických datových typů - konkrétně součtového typu, který bohužel právě v C/C++/Java
V C++ je a je to super.
-
Nemas pravdu. Neni duvod, proc by ses v tom nemel vyznat. Typicky priklad je binding hodnot pro SQL, ktery predavam nebo ziskavam jako objekt, a je to prirozena kolekce nahodnych dat ruznych typu.
Tomu nerozumím. Jako třeba:
data Row = Row {
ident :: Int
, name :: Text
, age :: int
..etc
}
V statických jazycích se tomu říká struct..? A pomáhá to zorganizovat chaos reálného světa a nezbláznit se v tom, co do té sql řádky dávám..?
Ano, ve statických jazycích je to struct. Jeho nevýhoda je, že je statický, takže pro každý dotaz ho musíš mít nadefinovaný předem, mohou jich být stovky a neumožňuje ti zpracívat uživatelské dotazy vytvářené za běhu programu. Třeba u monitorovacího systému výkonových transformátorů, který měří několik set parametrů a uživatel chce zobrazit historii šesti z nich, které si zaklikl, třeba teplotu oleje z čidel pod víkem, nebo některé údaje z analyzátoru plynů. Ne že by to nešlo ve statickém jazyku řešit, ale je to holt komplikovanější a je s tím nutno řešit problémy, které v dynamickém jazyku nejsou.
-
To je vzhuru nohama. Ty menis typ, aby se dal poslat funkci. Ja jsem mluvil o pripadu kdy menim funkci aby umela zpracovat novy typ. Je to spis o pripadech kdy mam typ definovany externe a chci ho ve svem kodu umet pouzit.
Nedavno jsem resil nejake zpracovani exif dat u fotek. Kazdy vyrobce ma sve vlastni tagy. Narazil jsem na fotku ktera mela nejaka data v tagu, ktery jsem zatim neznal a tak jsem proste pridal defmethod s dispatch value :manufacturer "kodak" (nebo neco takoveho) a uz to frcelo.
Teď úplně nerozumím... to Jidlo může být definované externě, tu instanci (včetně případně i té class) si můžu definovat interně. Takže když mám tu funkci:
encode :: ToJson a => a -> ByteStringA Jidlo je definované externě, tak pro mě není problém si vyrobit tu instanci u sebe.
Konkrétně u toho exifu tomu úplně nerozumím, z knihovny pro přečtení Exifu by patrně vypadával nějaký typ ve stylu:
data ExifTag = TagString Text | TagInt Int | ... a ty bys zpracovával typ ExifTag. Překladač by po tobě chtěl, abys zpracoval všechny varianty (nebo tam dal nějaký "wildcard"), takže přidání další varianty by bylo jenom přidání další varianty místo toho wildcardu.
-
Není to prasárna, jen se na to podívej abstraktněji:
To není o abstraktnosti.
promenna = (podminka) ? datovy_typ1 : datovy_typ2
Na tom přece nic špatného není. Třeba když datovy_typ2 je None. Nebo ty datové typy jsou muz a zena, nebo html a pdf,
A proč je muž == true a žena == false? A pokud je html true a pdf false, co je json?
Takový problém se správně řeší pravidlem:
podminka = žena
promenna = is_default(podminka) ? datovy_typ1 : datovy_typ2
Předpoklad, že to jazyk nějak skvěle rozhodne za mě, není projev flexibilnosti.
-
Ano, ve statických jazycích je to struct. Jeho nevýhoda je, že je statický, takže pro každý dotaz ho musíš mít nadefinovaný předem, mohou jich být stovky a neumožňuje ti zpracívat uživatelské dotazy vytvářené za běhu programu.
To není pravda. Pokud tvá argumentace stojí na tomto předpokladu, tak máme vyřešeno.
-
Ano, ve statických jazycích je to struct. Jeho nevýhoda je, že je statický, takže pro každý dotaz ho musíš mít nadefinovaný předem, mohou jich být stovky a neumožňuje ti zpracívat uživatelské dotazy vytvářené za běhu programu. Třeba u monitorovacího systému výkonových transformátorů, který měří několik set parametrů a uživatel chce zobrazit historii šesti z nich, které si zaklikl, třeba teplotu oleje z čidel pod víkem, nebo některé údaje z analyzátoru plynů. Ne že by to nešlo ve statickém jazyku řešit, ale je to holt komplikovanější a je s tím nutno řešit problémy, které v dynamickém jazyku nejsou.
Mohl bys dát nějaký konkrétní příklad kódu? Já si skutečně myslím, že skutečná _práce_ právě s takovými strukturami je mnohem jednodušší s pořádném typovém systému než bez něj. Neskutečným způsobem s tím pomáhají "lens", což je IMO bez statického typového systému dost problém uhlídat (jestli to obecně vůbec jde).
-
Typování obecně zabrání některým validním programům běžet. Typický příklad:
if (true) then 1 else "no"Tohle prostě staticky typovaným jazykem neprojde, přestože to je validní program. Samozřejmě díky tomu je dynamický jazyk "flexibilnější"; a je to strašná prasárna. Takže asi není čím se chlubit...
Není to prasárna, jen se na to podívej abstraktněji:
promenna = (podminka) ? datovy_typ1 : datovy_typ2
Na tom přece nic špatného není. Třeba když datovy_typ2 je None. Nebo ty datové typy jsou muz a zena, nebo html a pdf, a pak bys také mohl mít třeba toto:
levy = (typeof(pravy) == int) ? int(levy) : str(levy)
Já si bežně z funkcí které čtou data vracím hodnotu false, pokud funkce selže, None pokud data nejsou nebo datový objekt - tedy tři různé datové typy. Není to o nic horší, než návratový číselný kód z C funkce, která možná změní obsah proměnné předané funkci a pro získání chybového textu je nutné volat zvláštní funkci.
Takové věci jdou otypovat několika způsoby, ovšem obecně to je zvěrstvo a vidět takový kód svědčí o junioritě nebo debilitě (v případě seniora) toho, co to spáchal.
-
V C++ je a je to super.
..to mi asi uniklo..? Jak to konkrétně vypadá? (součtový typ)
-
V C++ je a je to super.
..to mi asi uniklo..? Jak to konkrétně vypadá? (součtový typ)
Například variant<int,string,MyFancyType>
-
Není to prasárna, jen se na to podívej abstraktněji:
promenna = (podminka) ? datovy_typ1 : datovy_typ2
Na tom přece nic špatného není. Třeba když datovy_typ2 je None. Nebo ty datové typy jsou muz a zena, nebo html a pdf, a pak bys také mohl mít třeba toto:
levy = (typeof(pravy) == int) ? int(levy) : str(levy)
Já si bežně z funkcí které čtou data vracím hodnotu false, pokud funkce selže, None pokud data nejsou nebo datový objekt - tedy tři různé datové typy. Není to o nic horší, než návratový číselný kód z C funkce, která možná změní obsah proměnné předané funkci a pro získání chybového textu je nutné volat zvláštní funkci.
Víš proč se NullPointerException říká "million dolar mistake"..? Asi nevíš.... Ano, je to strašné. Je to úplně příšerné. Třeba z toho důvodu, že když vůbec chceš vědět, co se z té funkce vrací, tak se do ní musíš podívat. Ty type inference enginy (které tak děsně vychvaloval tvůj oblíbenec) ti na tom budou řvát, že to máš blbě. A teď je samozřejmě otázka, jak to dělat "dobře", když se bavíme o statických jazycích. Dělá se to pomocí algebraických datových typů - konkrétně součtového typu, který bohužel právě v C/C++/Java není. A vypadá to následovně:
data Result a = Data a | NoData | GotError text
mojefunkce :: Nejaky_vstupni_typ -> Result Navratovy typ
mojefunkce vstupni_data
| jsou_chybna vstupni_data = GotError "Chybna vstupni data"
| nedostaneme_vysledek vstupni_data = NoData
| otherwise = Data (spocitej_vysledek vstupni_data)
Mam holt smulu, ze ja pouzivam akorat to C a Javu. Na druhou stranu, tohle jsou asi nejrozsirenejsi staticke jazyky. Nicmene tady je videt, ze michani ruznych datovych typu je vec potreba a zadana, nikoliv prasarna a pronika to i do statickych jazyku. Ono timto jsi rekl A a k tomu patri i B. Ta navratova hodnota se predava promenne, ktera musi byt schopna prijmout ruzne datovy typy, cimz musi byt jazyk obdaren introspekci, abych byl schopen zjistit, jaky datovy typ hodnota v promenne ma, tydy sama hodnota si nejspis nese datovy typ sebou a to už je vlastne na pul implementovany dynamicky jazyk. To si bud sebou nese nektera omezeni, treba na velikost promenne a nebo to uz tak uplne staticky jazyk nebude. Mozna budoucnost bude patrit takovym hybridum. Do dynamických jazyků zase prorůstají type hinty, uvidíme jak se to bude vyvíjet dál.
-
Mam holt smulu, ze ja pouzivam akorat to C a Javu. Na druhou stranu, tohle jsou asi nejrozsirenejsi staticke jazyky.
Jo, v C a Javě tohle bohužel implementované není. Jak mi bylo právě ukázáno, v C++ to implementované je, ale bez znalosti odjinud by mě to nenapadlo použít...
Nicmene tady je videt, ze michani ruznych datovych typu je vec potreba a zadana, nikoliv prasarna a pronika to i do statickych jazyku. Ono timto jsi rekl A a k tomu patri i B. Ta navratova hodnota se predava promenne, ktera musi byt schopna prijmout ruzne datovy typy, cimz musi byt jazyk obdaren introspekci, abych byl schopen zjistit, jaky datovy typ hodnota v promenne ma, tydy sama hodnota si nejspis nese datovy typ sebou a to už je vlastne na pul implementovany dynamicky jazyk. To si bud sebou nese nektera omezeni, treba na velikost promenne a nebo to uz tak uplne staticky jazyk nebude. Mozna budoucnost bude patrit takovym hybridum. Do dynamických jazyků zase prorůstají type hinty, uvidíme jak se to bude vyvíjet dál.
Tohle nepotřebuje žádnou introspekci. Říká se tomu "součtový datový typ", je to takový "lepší enum", nebo z C++ ten variant, nebo "tagging". On totiž dynamický jazyk je de-fakto jazyk právě s jedním součtový typem ve stylu:
data DynamicType = DynInt Int | DynString Text | DynBool Boolean | DynNone
A to fakt - když si napíšeš interpet dynamického jazyka, tak přesně takovýhle typ vyrobíš.
-
Není to prasárna, jen se na to podívej abstraktněji:
To není o abstraktnosti.
promenna = (podminka) ? datovy_typ1 : datovy_typ2
Na tom přece nic špatného není. Třeba když datovy_typ2 je None. Nebo ty datové typy jsou muz a zena, nebo html a pdf,
A proč je muž == true a žena == false? A pokud je html true a pdf false, co je json?
Takový problém se správně řeší pravidlem:
podminka = žena
promenna = is_default(podminka) ? datovy_typ1 : datovy_typ2
Předpoklad, že to jazyk nějak skvěle rozhodne za mě, není projev flexibilnosti.
Je, ale mimo tvé chápání :-).
Proč je muž v příkladu true? To je přece jedno, ale když to nedokážeš vnímat na abstraktní rovině, tak třeba proto, že to zatrhl na formuláři.
Ad is_default(), opět marginální, podstatné je, že se ti vrací jeden nebo druhý datový typ, o to teď v diskusi běží.
Myslím že tu ukázku vůbec nechápeš, program za tebe nic nerozhoduje, program rozhoduje podle podmínky zadané programátorem.
Napsal jsi toho hodně, ale vůbec nic k věci, tedy k vrácení dvou různých datových typů z podmínky. Škoda.
-
Mam holt smulu, ze ja pouzivam akorat to C a Javu. Na druhou stranu, tohle jsou asi nejrozsirenejsi staticke jazyky.
Jo, v C a Javě tohle bohužel implementované není. Jak mi bylo právě ukázáno, v C++ to implementované je, ale bez znalosti odjinud by mě to nenapadlo použít...
Nicmene tady je videt, ze michani ruznych datovych typu je vec potreba a zadana, nikoliv prasarna a pronika to i do statickych jazyku. Ono timto jsi rekl A a k tomu patri i B. Ta navratova hodnota se predava promenne, ktera musi byt schopna prijmout ruzne datovy typy, cimz musi byt jazyk obdaren introspekci, abych byl schopen zjistit, jaky datovy typ hodnota v promenne ma, tydy sama hodnota si nejspis nese datovy typ sebou a to už je vlastne na pul implementovany dynamicky jazyk. To si bud sebou nese nektera omezeni, treba na velikost promenne a nebo to uz tak uplne staticky jazyk nebude. Mozna budoucnost bude patrit takovym hybridum. Do dynamických jazyků zase prorůstají type hinty, uvidíme jak se to bude vyvíjet dál.
Tohle nepotřebuje žádnou introspekci. Říká se tomu "součtový datový typ", je to takový "lepší enum", nebo z C++ ten variant, nebo "tagging". On totiž dynamický jazyk je de-fakto jazyk právě s jedním součtový typem ve stylu:
data DynamicType = DynInt Int | DynString Text | DynBool Boolean | DynNone
A to fakt - když si napíšeš interpet dynamického jazyka, tak přesně takovýhle typ vyrobíš.
To je jako kdybych v C++ všude rval any.
-
Ano, ve statických jazycích je to struct. Jeho nevýhoda je, že je statický, takže pro každý dotaz ho musíš mít nadefinovaný předem, mohou jich být stovky a neumožňuje ti zpracívat uživatelské dotazy vytvářené za běhu programu.
To není pravda. Pokud tvá argumentace stojí na tomto předpokladu, tak máme vyřešeno.
Je to pravda a pokud máš dojem že ne, tak jsi asi nepochopil, o čem je řeč.
Řeč je o tom , že struct v C není dynamická struktura.
-
Píšu v JS ve VSCode, který hezky barví syntax a podobně, type interference nepoužívám, protože imho není proč, když jsem v dynamicky psaném jazyce. Píšu tak třeba i v Perlu.
Pravdou je, že si zase "typy" dost hlídám sám, reps. kde je to nutné... chce to pečlivost. :)
Ona otázka zní, proč to nepoužívat - když stejně ty funkce konstruuješ způsobem, že by to tím klidně prošlo..
Není to nutné a jsem tak schopen programovat i v čistém vimu, bez obezliček. :)
Na frontendu moc na výběr není - na backendu ano. Takže můžeme srovnat, jak by se stejná úloha řešila v Js (node), C#, Javě, Haskellu, Elixiru atd.. Rozdíl je třeba v tom, že prakticky neděláš "iterativní" vývoj. Když píšu v netypovaném jazyku, tak to je typicky - napíšu pár řádek. Zkusím. Napíšu dalších pár řádek. Zkusím. Potřebuju změnit něco, co jsem už zkusil... bez TDD pro větší projekt je to sebevražda.
To asi dost záleží... nevím, nemám ten problém, ale asi by to chtělo si sednout a "jeden druhého zkoušet". :)
I C++ už umí dneska "auto". U C++ je naprosto nesnesitelné psát ty příšerné typy např. v iterátoru - "auto" to řeší.
To jistě, ale psát ho všude ten kód imho prasí. :) Do for či na iterátory, apod. je to ale moc pěkné. :)
Potřebuješ něco refaktorovat.... už je to docela dávno, potřeboval jsem upravit program (C++), který prováděl síťovou komunikaci, aby fungoval jak na little-endian tak na big-endian strojích. Takže...jak to udělat? Jak najít všechna místa, kde je potřeba přidat tu případnou konverzi do nějakého "network-order"? Ukázalo se, že stačí změnit typ v těch serializovaných strukturách z "int_32" (apod) na nějaký "struct net_int32", spustit kompiler a rovnou z toho vypadl seznam řádek, kde je to potřeba opravit. Při TDD (bez typů) by ti z toho vypadl seznam spadlých testů, a ty bys pak hledal v kódu, kde to opravit a doufal, že ty testy jsou fakt důsledné.
Většina lidí má asi pocit, že typový systém je nějaký artefakt toho, že je potřeba to nakonec nějak zkompilovat a je potřeba to nějak překladači vysvětlit jak. A dynamické typy berou jako "posun vpřed" - proč mu to vysvětlovat, když si to překladač může zjistit sám. Ten pohled, který se dneska prosazuje, je, že statické typy jsou nástroj pro programátora, který využívá k tomu, aby napsal program s méně chybami, méně zbytečného kódu a vyššími možnostmi abstrakce.
Tady myslím, že se shodneme... Nemyslím si, že by byly dynamické typy posun vpřed... je to jiný přístup... a mám ho neméně rád.
Ale argumentovat Haskellem, že je JS špatně navržený jazyk mi přijde trochu přitažené za vlasy...
Taky jsem nic takového neřekl - JS je špatný z jiných důvodů, než že nemá statické typy. Proti JS jsem argumentoval některými věcmi z Pythonu (ten má taky spoustu much) případně Go (runtime). Ještě by se to dalo srovnávat s Elixirem (ale o tom vím akorát, že existuje), případně Clojure/lisp. Proti tvrzení, že statické typy jsou na nic argumentuji haskellem (a dal by se k tomu přidat asi Rust, ale ten je dost mladý).
Zatím si nejsem jist, že jsem zde viděl nějaký argument, proč je JS špatný... :)
-
Já si bežně z funkcí které čtou data vracím hodnotu false, pokud funkce selže, None pokud data nejsou nebo datový objekt - tedy tři různé datové typy. Není to o nic horší, než návratový číselný kód z C funkce, která možná změní obsah proměnné předané funkci a pro získání chybového textu je nutné volat zvláštní funkci.
Takové věci jdou otypovat několika způsoby, ovšem obecně to je zvěrstvo a vidět takový kód svědčí o junioritě nebo debilitě (v případě seniora) toho, co to spáchal.
Je to jedno z možných řešení a nedokážeš nijak obhájit své tvrzení, že je to řešení špatné. Je to přirozené řešení na přirozenou potřebu, kdy z funkce potřebuješ vracet různé stavy a výsledky. Jazyky které to neumí to obchází různými méně čitelnými způsoby.
-
Proč aspoň ne výjimku místo false? Nebylo by to čistší?
-
Proč aspoň ne výjimku místo false? Nebylo by to čistší?
Bylo, ale třeba v Pythonu jsou výjimky drahé, takže u funkce kterou voláš v řádech statisíců a při selhání nechceš přerušit chod programu ji nepoužiješ.
-
Já si bežně z funkcí které čtou data vracím hodnotu false, pokud funkce selže, None pokud data nejsou nebo datový objekt - tedy tři různé datové typy. Není to o nic horší, než návratový číselný kód z C funkce, která možná změní obsah proměnné předané funkci a pro získání chybového textu je nutné volat zvláštní funkci.
Takové věci jdou otypovat několika způsoby, ovšem obecně to je zvěrstvo a vidět takový kód svědčí o junioritě nebo debilitě (v případě seniora) toho, co to spáchal.
Je to přirozené řešení na přirozenou potřebu, kdy z funkce potřebuješ vracet různé stavy a výsledky. Jazyky které to neumí to obchází různými méně čitelnými způsoby.
Nebo místo obcházení použijí již zmíněný součtový typ.
-
Já si bežně z funkcí které čtou data vracím hodnotu false, pokud funkce selže, None pokud data nejsou nebo datový objekt - tedy tři různé datové typy. Není to o nic horší, než návratový číselný kód z C funkce, která možná změní obsah proměnné předané funkci a pro získání chybového textu je nutné volat zvláštní funkci.
Takové věci jdou otypovat několika způsoby, ovšem obecně to je zvěrstvo a vidět takový kód svědčí o junioritě nebo debilitě (v případě seniora) toho, co to spáchal.
Je to přirozené řešení na přirozenou potřebu, kdy z funkce potřebuješ vracet různé stavy a výsledky. Jazyky které to neumí to obchází různými méně čitelnými způsoby.
Nebo místo obcházení použijí již zmíněný součtový typ.
To nepodporují všechny jazyky a zůstává zachována podstata řešení, které jsi arogantně napadl, funkce vrací hodnoty různých datových typů :-). Takže už pak jen záleží na jazyku, jakými prostředky ti to dovolí realizovat. Má vůbec nějaký dynamický jazyk součtový typ, nebo je to jen obezlička některých statických jazyků, které se snaží přiblížit flexibilitě dynamických, jenž v tomto směru mají bohatší možnosti?
-
Já si bežně z funkcí které čtou data vracím hodnotu false, pokud funkce selže, None pokud data nejsou nebo datový objekt - tedy tři různé datové typy. Není to o nic horší, než návratový číselný kód z C funkce, která možná změní obsah proměnné předané funkci a pro získání chybového textu je nutné volat zvláštní funkci.
Takové věci jdou otypovat několika způsoby, ovšem obecně to je zvěrstvo a vidět takový kód svědčí o junioritě nebo debilitě (v případě seniora) toho, co to spáchal.
Je to přirozené řešení na přirozenou potřebu, kdy z funkce potřebuješ vracet různé stavy a výsledky. Jazyky které to neumí to obchází různými méně čitelnými způsoby.
Nebo místo obcházení použijí již zmíněný součtový typ.
funkce vrací hodnoty různých datových typů
Nevrací, musíš použít příslušný konstruktor. To může překladač udělat za tebe, ale nevyhneš se při použití hodnoty matchingu. Ty fakt nevíš o typových systémech ani houno.
-
Zatím si nejsem jist, že jsem zde viděl nějaký argument, proč je JS špatný... :)
Automatické přetypování při porovnáních je antipattern. Runtime dělaný jako continuation passing místo toho, aby to bylo normálně "jako-synchronní" (to je IMO největší problém). Našlo by se asi i pár dalších věcí - postupem času se ty nejhorší nějak daří vylepšovat (takže už to není tak strašný jako před 5 lety).
-
a
-
To nepodporují všechny jazyky
Jenomže otázka zněla dynamické vs. statické jazyky, nikoliv jsou dynamické lepší než "kterýkoliv statický".
a zůstává zachována podstata řešení, které jsi arogantně napadl, funkce vrací hodnoty různých datových typů :-).
Ne... funkce vrací konkrétní jeden typ...
Má vůbec nějaký dynamický jazyk součtový typ, nebo je to jen obezlička některých statických jazyků, které se snaží přiblížit flexibilitě dynamických, jenž v tomto směru mají bohatší možnosti?
Striktně vzato dynamický jazyk má 1 součtový typ, kdy to, co ty nazýváš "typ" jsou varianty v tom součtovém typu. Nepsal jsem to někde výše?
-
Píšu v JS ve VSCode, který hezky barví syntax a podobně, type interference nepoužívám, protože imho není proč, když jsem v dynamicky psaném jazyce. Píšu tak třeba i v Perlu.
Pravdou je, že si zase "typy" dost hlídám sám, reps. kde je to nutné... chce to pečlivost. :)
Ona otázka zní, proč to nepoužívat - když stejně ty funkce konstruuješ způsobem, že by to tím klidně prošlo..
Není to nutné a jsem tak schopen programovat i v čistém vimu, bez obezliček. :)
Na frontendu moc na výběr není - na backendu ano. Takže můžeme srovnat, jak by se stejná úloha řešila v Js (node), C#, Javě, Haskellu, Elixiru atd.. Rozdíl je třeba v tom, že prakticky neděláš "iterativní" vývoj. Když píšu v netypovaném jazyku, tak to je typicky - napíšu pár řádek. Zkusím. Napíšu dalších pár řádek. Zkusím. Potřebuju změnit něco, co jsem už zkusil... bez TDD pro větší projekt je to sebevražda.
To asi dost záleží... nevím, nemám ten problém, ale asi by to chtělo si sednout a "jeden druhého zkoušet". :)
I C++ už umí dneska "auto". U C++ je naprosto nesnesitelné psát ty příšerné typy např. v iterátoru - "auto" to řeší.
To jistě, ale psát ho všude ten kód imho prasí. :) Do for či na iterátory, apod. je to ale moc pěkné. :)
Potřebuješ něco refaktorovat.... už je to docela dávno, potřeboval jsem upravit program (C++), který prováděl síťovou komunikaci, aby fungoval jak na little-endian tak na big-endian strojích. Takže...jak to udělat? Jak najít všechna místa, kde je potřeba přidat tu případnou konverzi do nějakého "network-order"? Ukázalo se, že stačí změnit typ v těch serializovaných strukturách z "int_32" (apod) na nějaký "struct net_int32", spustit kompiler a rovnou z toho vypadl seznam řádek, kde je to potřeba opravit. Při TDD (bez typů) by ti z toho vypadl seznam spadlých testů, a ty bys pak hledal v kódu, kde to opravit a doufal, že ty testy jsou fakt důsledné.
Většina lidí má asi pocit, že typový systém je nějaký artefakt toho, že je potřeba to nakonec nějak zkompilovat a je potřeba to nějak překladači vysvětlit jak. A dynamické typy berou jako "posun vpřed" - proč mu to vysvětlovat, když si to překladač může zjistit sám. Ten pohled, který se dneska prosazuje, je, že statické typy jsou nástroj pro programátora, který využívá k tomu, aby napsal program s méně chybami, méně zbytečného kódu a vyššími možnostmi abstrakce.
Tady myslím, že se shodneme... Nemyslím si, že by byly dynamické typy posun vpřed... je to jiný přístup... a mám ho neméně rád.
Ale argumentovat Haskellem, že je JS špatně navržený jazyk mi přijde trochu přitažené za vlasy...
Taky jsem nic takového neřekl - JS je špatný z jiných důvodů, než že nemá statické typy. Proti JS jsem argumentoval některými věcmi z Pythonu (ten má taky spoustu much) případně Go (runtime). Ještě by se to dalo srovnávat s Elixirem (ale o tom vím akorát, že existuje), případně Clojure/lisp. Proti tvrzení, že statické typy jsou na nic argumentuji haskellem (a dal by se k tomu přidat asi Rust, ale ten je dost mladý).
Zatím si nejsem jist, že jsem zde viděl nějaký argument, proč je JS špatný... :)
Neviděl? V Google si napsali celé GWT, aby se v tom dalo nějak rozumně psát, pokud možno s odstíněním od vývojářů.
-
Já si bežně z funkcí které čtou data vracím hodnotu false, pokud funkce selže, None pokud data nejsou nebo datový objekt - tedy tři různé datové typy. Není to o nic horší, než návratový číselný kód z C funkce, která možná změní obsah proměnné předané funkci a pro získání chybového textu je nutné volat zvláštní funkci.
Takové věci jdou otypovat několika způsoby, ovšem obecně to je zvěrstvo a vidět takový kód svědčí o junioritě nebo debilitě (v případě seniora) toho, co to spáchal.
Je to přirozené řešení na přirozenou potřebu, kdy z funkce potřebuješ vracet různé stavy a výsledky. Jazyky které to neumí to obchází různými méně čitelnými způsoby.
Nebo místo obcházení použijí již zmíněný součtový typ.
funkce vrací hodnoty různých datových typů
Nevrací, musíš použít příslušný konstruktor. To může překladač udělat za tebe, ale nevyhneš se při použití hodnoty matchingu. Ty fakt nevíš o typových systémech ani houno.
Vskutku neznám jazyk, který by používal součtový typ, byť aktivně těch jazyků používám několik. Pro mě je to okrajová záležitost, nikoliv typická vlastnost statických jazyků, jak se snažíš tvářit. Nejblíže tomu co znám je TypeVar v Pythonu. Ty zase plaveš v dynamických jazycích a aplikuješ na ně svůj toporný statický pohled.
-
To nepodporují všechny jazyky
Jenomže otázka zněla dynamické vs. statické jazyky, nikoliv jsou dynamické lepší než "kterýkoliv statický".
a zůstává zachována podstata řešení, které jsi arogantně napadl, funkce vrací hodnoty různých datových typů :-).
Ne... funkce vrací konkrétní jeden typ...
Má vůbec nějaký dynamický jazyk součtový typ, nebo je to jen obezlička některých statických jazyků, které se snaží přiblížit flexibilitě dynamických, jenž v tomto směru mají bohatší možnosti?
Striktně vzato dynamický jazyk má 1 součtový typ, kdy to, co ty nazýváš "typ" jsou varianty v tom součtovém typu. Nepsal jsem to někde výše?
Tady si imho odporuješ. Klidně přistoupím na tezi, že dynamický jazyk má jediný součtový typ, proč ne. Ale pořád v dynamickém jazyku platí, že funkce může vracet hodnoty různých datových typů (nebo variant v tvé terminologii). To ovšem rozporuješ o kus výše, kde uvádíš, že funkce vrací jeden součtový typ. Takže buď to není totožné s fungováním dynamických jazyků a nebo součtový typ vrací hodnoty různých datových typů (variant v tvé terminologii). Obojí současně platit nemůže, vyber si, co platí.
-
Já si bežně z funkcí které čtou data vracím hodnotu false, pokud funkce selže, None pokud data nejsou nebo datový objekt - tedy tři různé datové typy. Není to o nic horší, než návratový číselný kód z C funkce, která možná změní obsah proměnné předané funkci a pro získání chybového textu je nutné volat zvláštní funkci.
Takové věci jdou otypovat několika způsoby, ovšem obecně to je zvěrstvo a vidět takový kód svědčí o junioritě nebo debilitě (v případě seniora) toho, co to spáchal.
Je to přirozené řešení na přirozenou potřebu, kdy z funkce potřebuješ vracet různé stavy a výsledky. Jazyky které to neumí to obchází různými méně čitelnými způsoby.
Nebo místo obcházení použijí již zmíněný součtový typ.
funkce vrací hodnoty různých datových typů
Nevrací, musíš použít příslušný konstruktor. To může překladač udělat za tebe, ale nevyhneš se při použití hodnoty matchingu. Ty fakt nevíš o typových systémech ani houno.
Vskutku neznám jazyk, který by používal součtový typ, byť aktivně těch jazyků používám několik. Pro mě je to okrajová záležitost, nikoliv typická vlastnost statických jazyků
Aspoň teď už víme, proč píšeš takové kraviny. Nauč se Haskell nebo něco podobně rozumně typovaného (i když existují ještě mnohem silnější typové systémy), otevře ti to oči (pokud to pochopíš).
-
To nepodporují všechny jazyky
Jenomže otázka zněla dynamické vs. statické jazyky, nikoliv jsou dynamické lepší než "kterýkoliv statický".
a zůstává zachována podstata řešení, které jsi arogantně napadl, funkce vrací hodnoty různých datových typů :-).
Ne... funkce vrací konkrétní jeden typ...
Má vůbec nějaký dynamický jazyk součtový typ, nebo je to jen obezlička některých statických jazyků, které se snaží přiblížit flexibilitě dynamických, jenž v tomto směru mají bohatší možnosti?
Striktně vzato dynamický jazyk má 1 součtový typ, kdy to, co ty nazýváš "typ" jsou varianty v tom součtovém typu. Nepsal jsem to někde výše?
Tady si imho odporuješ. Klidně přistoupím na tezi, že dynamický jazyk má jediný součtový typ, proč ne. Ale pořád v dynamickém jazyku platí, že funkce může vracet hodnoty různých datových typů (nebo variant v tvé terminologii). To ovšem rozporuješ o kus výše, kde uvádíš, že funkce vrací jeden součtový typ. Takže buď to není totožné s fungováním dynamických jazyků a nebo součtový typ vrací hodnoty různých datových typů (variant v tvé terminologii). Obojí současně platit nemůže, vyber si, co platí.
Nechceš si radši jít hrát na pískoviště?
-
eee: když si definuju tohle:
data Value = VInt Int | VDouble Double | VStrint Text | VBool Boolean | VObject (Dict Text Value) | VNone
-- Čti: Typ Value může nabývat hodnot "VInt s parametrem celé číslo", "VDouble s parametrem double" etc.
-- To VInt, VDouble je de-fakto "tag"
Tak to je přesně ten typ, který se používá v JS, Pythonu etc. Všechny funkce potom budou typu ve stylu:
f: Value -> Value
-- Čti: vstupem do funkce je hodnota typu Value, výstupem je hodnota typu Value
No a třeba sčítání by se třeba definovalo jako:
(+) :: Value -> Value -> Value
(+) (VInt i) (VInt j) = VInt (i + j)
(+) (VDouble i) (VDouble j) = VDouble (i + j)
(+) (VInt i) (VDouble j) = VDouble (toDouble i + j)
(+) _ _ = error "crash"
Takže pak mám v programu jeden typ a hotovo, chová se to přesně stejně jako dynamické jazyky (teď ignoruju pure/non-pure, to je další level).
Ve staticky typovaném jazyku můžu udělat něco, co v tom dynamickém nemůžeš: Můžu tu funkci omezit. Můžu říct: tahle funkce může vrátit jenom Int. A nic jiného.
Tady si imho odporuješ. Klidně přistoupím na tezi, že dynamický jazyk má jediný součtový typ, proč ne. Ale pořád v dynamickém jazyku platí, že funkce může vracet hodnoty různých datových typů (nebo variant v tvé terminologii). To ovšem rozporuješ o kus výše, kde uvádíš, že funkce vrací jeden součtový typ. Takže buď to není totožné s fungováním dynamických jazyků a nebo součtový typ vrací hodnoty různých datových typů (variant v tvé terminologii). Obojí současně platit nemůže, vyber si, co platí.
Varianta typu není typ. Prvek "enumu" taky není zvláštní typ - je to hodnota typu toho enumu.
Představ si součtový typ jako "Enum", kdy ale jednotlivé volby jsou "structy" (v C je tomu dost blízký union, ale překladač nevynucuje to "nebo"). Ad absurdum by se to dalo Enumem simulovat takhle (v C++?):
enum JsValue = { JSNull, JSTrue, JSFalse, Int0, Int1, Int2, Int3, Int4,.... }
Jak vidíš, typ je fakt jeden (JsValue), ale klidně ta funkce (i v C) může vrátit "null", "true", "false", 0, 1.... atd.
-
Já si bežně z funkcí které čtou data vracím hodnotu false, pokud funkce selže, None pokud data nejsou nebo datový objekt - tedy tři různé datové typy. Není to o nic horší, než návratový číselný kód z C funkce, která možná změní obsah proměnné předané funkci a pro získání chybového textu je nutné volat zvláštní funkci.
Takové věci jdou otypovat několika způsoby, ovšem obecně to je zvěrstvo a vidět takový kód svědčí o junioritě nebo debilitě (v případě seniora) toho, co to spáchal.
Je to přirozené řešení na přirozenou potřebu, kdy z funkce potřebuješ vracet různé stavy a výsledky. Jazyky které to neumí to obchází různými méně čitelnými způsoby.
Nebo místo obcházení použijí již zmíněný součtový typ.
funkce vrací hodnoty různých datových typů
Nevrací, musíš použít příslušný konstruktor. To může překladač udělat za tebe, ale nevyhneš se při použití hodnoty matchingu. Ty fakt nevíš o typových systémech ani houno.
Vskutku neznám jazyk, který by používal součtový typ, byť aktivně těch jazyků používám několik. Pro mě je to okrajová záležitost, nikoliv typická vlastnost statických jazyků
Aspoň teď už víme, proč píšeš takové kraviny. Nauč se Haskell nebo něco podobně rozumně typovaného (i když existují ještě mnohem silnější typové systémy), otevře ti to oči (pokud to pochopíš).
Díky za radu, ale už jsem psal, že funkcionální jazyky nejsou nic pro mě. Navíc dávám přednost těm praktickým před akademickými. Co se týče součtového typu, snažím se něco dozvědt od vás, ale sami v tom máte hokej a poskytujete rozporuplné informace typu, že dynamické jazyky jsou specální případ jediného součtového typu, který pokrývá všechny možne datové typy a když z toho vyjdu a odvozuji od toho jeho fungování, tak je všechno špatně. Byť tvrdíte, že součtový typ je adekvátní odpověď na dynamické typy.
Rád bych tu viděl příklad, kde funkce vrací hodnoty různých datových typů (false, none, object), předává to nějaké proměnné a dále se program větví podle toho, jaká hodnota byla předána. Jestli to nejde, pak je z vaše zaklínání se součtovým typem pěkná blamáž. :-).
-
Není to prasárna, jen se na to podívej abstraktněji:
promenna = (podminka) ? datovy_typ1 : datovy_typ2
Na tom přece nic špatného není. Třeba když datovy_typ2 je None. Nebo ty datové typy jsou muz a zena, nebo html a pdf, a pak bys také mohl mít třeba toto:
levy = (typeof(pravy) == int) ? int(levy) : str(levy)
Já si bežně z funkcí které čtou data vracím hodnotu false, pokud funkce selže, None pokud data nejsou nebo datový objekt - tedy tři různé datové typy. Není to o nic horší, než návratový číselný kód z C funkce, která možná změní obsah proměnné předané funkci a pro získání chybového textu je nutné volat zvláštní funkci.
Víš proč se NullPointerException říká "million dolar mistake"..? Asi nevíš.... Ano, je to strašné. Je to úplně příšerné. Třeba z toho důvodu, že když vůbec chceš vědět, co se z té funkce vrací, tak se do ní musíš podívat. Ty type inference enginy (které tak děsně vychvaloval tvůj oblíbenec) ti na tom budou řvát, že to máš blbě. A teď je samozřejmě otázka, jak to dělat "dobře", když se bavíme o statických jazycích. Dělá se to pomocí algebraických datových typů - konkrétně součtového typu, který bohužel právě v C/C++/Java není. A vypadá to následovně:
data Result a = Data a | NoData | GotError text
mojefunkce :: Nejaky_vstupni_typ -> Result Navratovy typ
mojefunkce vstupni_data
| jsou_chybna vstupni_data = GotError "Chybna vstupni data"
| nedostaneme_vysledek vstupni_data = NoData
| otherwise = Data (spocitej_vysledek vstupni_data)
Mam holt smulu, ze ja pouzivam akorat to C a Javu. Na druhou stranu, tohle jsou asi nejrozsirenejsi staticke jazyky. Nicmene tady je videt, ze michani ruznych datovych typu je vec potreba a zadana, nikoliv prasarna a pronika to i do statickych jazyku. Ono timto jsi rekl A a k tomu patri i B. Ta navratova hodnota se predava promenne, ktera musi byt schopna prijmout ruzne datovy typy, cimz musi byt jazyk obdaren introspekci, abych byl schopen zjistit, jaky datovy typ hodnota v promenne ma, tydy sama hodnota si nejspis nese datovy typ sebou a to už je vlastne na pul implementovany dynamicky jazyk. To si bud sebou nese nektera omezeni, treba na velikost promenne a nebo to uz tak uplne staticky jazyk nebude. Mozna budoucnost bude patrit takovym hybridum. Do dynamických jazyků zase prorůstají type hinty, uvidíme jak se to bude vyvíjet dál.
Pro lidi, co nechápou typové systémy, vzniklo protokolí programování. Jazyk se chová jako dynamicky typovaný a dynamický dispatch se řeší v runtimu. Vracení hodnot více typů se pak řeší nepříliš duchaplně tuplem. Je to sice taky prasárna, ale aspoň pragmatická a se zachycením chyb při překladu. Kdo chce megaprasit, použije überrozhraní, které neumí zhola nic (v Go interface{}). Kupodivu se to lidem dost líbí, asi že tak můžou dekódovat například libovolný JSON apod.
-
To nepodporují všechny jazyky
Jenomže otázka zněla dynamické vs. statické jazyky, nikoliv jsou dynamické lepší než "kterýkoliv statický".
a zůstává zachována podstata řešení, které jsi arogantně napadl, funkce vrací hodnoty různých datových typů :-).
Ne... funkce vrací konkrétní jeden typ...
Má vůbec nějaký dynamický jazyk součtový typ, nebo je to jen obezlička některých statických jazyků, které se snaží přiblížit flexibilitě dynamických, jenž v tomto směru mají bohatší možnosti?
Striktně vzato dynamický jazyk má 1 součtový typ, kdy to, co ty nazýváš "typ" jsou varianty v tom součtovém typu. Nepsal jsem to někde výše?
Tady si imho odporuješ. Klidně přistoupím na tezi, že dynamický jazyk má jediný součtový typ, proč ne. Ale pořád v dynamickém jazyku platí, že funkce může vracet hodnoty různých datových typů (nebo variant v tvé terminologii). To ovšem rozporuješ o kus výše, kde uvádíš, že funkce vrací jeden součtový typ. Takže buď to není totožné s fungováním dynamických jazyků a nebo součtový typ vrací hodnoty různých datových typů (variant v tvé terminologii). Obojí současně platit nemůže, vyber si, co platí.
Nechceš si radši jít hrát na pískoviště?
Leda bych tě tam potkal :-). Něco k věci bys neměl?
-
Já si bežně z funkcí které čtou data vracím hodnotu false, pokud funkce selže, None pokud data nejsou nebo datový objekt - tedy tři různé datové typy. Není to o nic horší, než návratový číselný kód z C funkce, která možná změní obsah proměnné předané funkci a pro získání chybového textu je nutné volat zvláštní funkci.
Takové věci jdou otypovat několika způsoby, ovšem obecně to je zvěrstvo a vidět takový kód svědčí o junioritě nebo debilitě (v případě seniora) toho, co to spáchal.
Je to přirozené řešení na přirozenou potřebu, kdy z funkce potřebuješ vracet různé stavy a výsledky. Jazyky které to neumí to obchází různými méně čitelnými způsoby.
Nebo místo obcházení použijí již zmíněný součtový typ.
funkce vrací hodnoty různých datových typů
Nevrací, musíš použít příslušný konstruktor. To může překladač udělat za tebe, ale nevyhneš se při použití hodnoty matchingu. Ty fakt nevíš o typových systémech ani houno.
Vskutku neznám jazyk, který by používal součtový typ, byť aktivně těch jazyků používám několik. Pro mě je to okrajová záležitost, nikoliv typická vlastnost statických jazyků
Aspoň teď už víme, proč píšeš takové kraviny. Nauč se Haskell nebo něco podobně rozumně typovaného (i když existují ještě mnohem silnější typové systémy), otevře ti to oči (pokud to pochopíš).
poskytujete rozporuplné informace typu, že dynamické jazyky jsou specální případ jediného součtového typu, který pokrývá všechny možne datové typy a když z toho vyjdu a odvozuji od toho jeho fungování, tak je všechno špatně
Kde tam vidíš rozpor? Bylo to napsáno správně.
-
Rád bych tu viděl příklad, kde funkce vrací hodnoty různých datových typů (false, none, object), předává to nějaké proměnné a dále se program větví podle toho, jaká hodnota byla předána. Jestli to nejde, pak je z vaše zaklínání se součtovým typem pěkná blamáž. :-).
Pominu tvoji terminologii, tady máš příklad:
data JSValue = JSBool Boolean | JSNone | JSText String
-- Funkce f: parametr typu "String", vraci typ "JSValue"
f :: String -> JSValue
f "true" = JSBool True
f "false" = JSBool False
f "none" = JSNone
f t = JSText t
mojeFunkce :: IO () -- (treba...)
mojeFunkce = do
vstup <- readLine -- neco precti ze vstupu
let result = f vstup -- Zavolame nasi funkci 'f'
case result of -- Pattern match na jednotlive varianty
JSBool b -> if b then putStrLn "dostali jsme true" else putStrLn "dostali jsme false"
JSNone -> putStrLn "dostali jsme None"
JSText t -> putStrLn ("Dostali jsme nejaky jiny string: " <> t)
-
Rád bych tu viděl příklad, kde funkce vrací hodnoty různých datových typů (false, none, object), předává to nějaké proměnné a dále se program větví podle toho, jaká hodnota byla předána. Jestli to nejde, pak je z vaše zaklínání se součtovým typem pěkná blamáž. :-).
Pominu tvoji terminologii, tady máš příklad:
data JSValue = JSBool Boolean | JSNone | JSText String
-- Funkce f: parametr typu "String", vraci typ "JSValue"
f :: String -> JSValue
f "true" = JSBool True
f "false" = JSBool False
f "none" = JSNone
f t = JSText t
mojeFunkce :: IO () -- (treba...)
mojeFunkce = do
vstup <- readLine -- neco precti ze vstupu
let result = f vstup -- Zavolame nasi funkci 'f'
case result of -- Pattern match na jednotlive varianty
JSBool b -> if b then putStrLn "dostali jsme true" else putStrLn "dostali jsme false"
JSNone -> putStrLn "dostali jsme None"
JSText t -> putStrLn ("Dostali jsme nejaky jiny string: " <> t)
A teď v C++ ;)
-
A teď v C++ ;)
No, přiznávám, že větší projekt v C++ jsem dělal někdy před 8 lety a od té doby jsem to neviděl...ale přes ty varianty bych to asi s velkou mírou vypětí a soubojem s kompilátorem (a za vydatné pomoci googlu) snad dal ;D
-
eee: když si definuju tohle:
data Value = VInt Int | VDouble Double | VStrint Text | VBool Boolean | VObject (Dict Text Value) | VNone
-- Čti: Typ Value může nabývat hodnot "VInt s parametrem celé číslo", "VDouble s parametrem double" etc.
-- To VInt, VDouble je de-fakto "tag"
Tak to je přesně ten typ, který se používá v JS, Pythonu etc. Všechny funkce potom budou typu ve stylu:
f: Value -> Value
-- Čti: vstupem do funkce je hodnota typu Value, výstupem je hodnota typu Value
No a třeba sčítání by se třeba definovalo jako:
(+) :: Value -> Value -> Value
(+) (VInt i) (VInt j) = VInt (i + j)
(+) (VDouble i) (VDouble j) = VDouble (i + j)
(+) (VInt i) (VDouble j) = VDouble (toDouble i + j)
(+) _ _ = error "crash"
Takže pak mám v programu jeden typ a hotovo, chová se to přesně stejně jako dynamické jazyky (teď ignoruju pure/non-pure, to je další level).
Ve staticky typovaném jazyku můžu udělat něco, co v tom dynamickém nemůžeš: Můžu tu funkci omezit. Můžu říct: tahle funkce může vrátit jenom Int. A nic jiného.
Tady si imho odporuješ. Klidně přistoupím na tezi, že dynamický jazyk má jediný součtový typ, proč ne. Ale pořád v dynamickém jazyku platí, že funkce může vracet hodnoty různých datových typů (nebo variant v tvé terminologii). To ovšem rozporuješ o kus výše, kde uvádíš, že funkce vrací jeden součtový typ. Takže buď to není totožné s fungováním dynamických jazyků a nebo součtový typ vrací hodnoty různých datových typů (variant v tvé terminologii). Obojí současně platit nemůže, vyber si, co platí.
Varianta typu není typ. Prvek "enumu" taky není zvláštní typ - je to hodnota typu toho enumu.
Představ si součtový typ jako "Enum", kdy ale jednotlivé volby jsou "structy" (v C je tomu dost blízký union, ale překladač nevynucuje to "nebo"). Ad absurdum by se to dalo Enumem simulovat takhle (v C++?):
enum JsValue = { JSNull, JSTrue, JSFalse, Int0, Int1, Int2, Int3, Int4,.... }
Jak vidíš, typ je fakt jeden (JsValue), ale klidně ta funkce (i v C) může vrátit "null", "true", "false", 0, 1.... atd.
Díky za vysvětlení. Chápu co se snažíš říct, že ten jeden typ vrací různé hodnoty. Ale nevím zda si uvědomuješ, že to neodpovídá chování dynamického jazyka, byť tvrdíš že jo.
a) dynamický jazyk je dynamický, dynamické jsou i typy, takže je nemůžeš předem staticky dát do výčtu, každá třída je novým typem
>>> class A(object): pass
>>> type(type(A()))
<class 'type'>
b) dynamický jazyk rozlišuje datové typy svých hodnot, což ten enum nedělá, v dynamickém jazyku ta varianta je datový typ. Nejde jen o to, že můžeš vrátit libovolnou hodnotu, ale že znáš její typ s kterým můžeš pracovat a s kterým pracuje jazyk. Co to udělá, když budes sčítat hodnoty 5 + '5' obě jednoho součtového typu? V pythonu ti to spadne na rozdílnost datových typů.
c) i v dynamickém jazyku můžeš funkci omezit, buď dekorátorem, což se kontroluje runtime a nebo type hintem, což se kontroluje při překladu.
-
Já si bežně z funkcí které čtou data vracím hodnotu false, pokud funkce selže, None pokud data nejsou nebo datový objekt - tedy tři různé datové typy. Není to o nic horší, než návratový číselný kód z C funkce, která možná změní obsah proměnné předané funkci a pro získání chybového textu je nutné volat zvláštní funkci.
Takové věci jdou otypovat několika způsoby, ovšem obecně to je zvěrstvo a vidět takový kód svědčí o junioritě nebo debilitě (v případě seniora) toho, co to spáchal.
Je to přirozené řešení na přirozenou potřebu, kdy z funkce potřebuješ vracet různé stavy a výsledky. Jazyky které to neumí to obchází různými méně čitelnými způsoby.
Nebo místo obcházení použijí již zmíněný součtový typ.
funkce vrací hodnoty různých datových typů
Nevrací, musíš použít příslušný konstruktor. To může překladač udělat za tebe, ale nevyhneš se při použití hodnoty matchingu. Ty fakt nevíš o typových systémech ani houno.
Vskutku neznám jazyk, který by používal součtový typ, byť aktivně těch jazyků používám několik. Pro mě je to okrajová záležitost, nikoliv typická vlastnost statických jazyků
Aspoň teď už víme, proč píšeš takové kraviny. Nauč se Haskell nebo něco podobně rozumně typovaného (i když existují ještě mnohem silnější typové systémy), otevře ti to oči (pokud to pochopíš).
poskytujete rozporuplné informace typu, že dynamické jazyky jsou specální případ jediného součtového typu, který pokrývá všechny možne datové typy a když z toho vyjdu a odvozuji od toho jeho fungování, tak je všechno špatně
Kde tam vidíš rozpor? Bylo to napsáno správně.
Už jsem ho popsal, funkce v dynamickém jazyku vrací hodnoty různých datových typů. Funkce vracející součtový typ to podle vás nedělá, ergo se to nechová stejně a dynamické jazyky nejsou implementovány jako případ jediného vše pokrývajícího součtového typu.
-
A teď v C++ ;)
No, přiznávám, že větší projekt v C++ jsem dělal někdy před 8 lety a od té doby jsem to neviděl...ale přes ty varianty bych to asi s velkou mírou vypětí a soubojem s kompilátorem (a za vydatné pomoci googlu) snad dal ;D
Není to zrovna pastva pro oči:
std::variant<bool,std::string> sillyFunction(const std::string& s) {
if (s == "true"s) return true;
if (s == "false"s) return false;
return s;
}
int main() {
const auto& r = sillyFunction("C++ sux"s);
std::visit(match {
[](bool b) { std::cout << "we got a boolean: " << b << std::endl; },
[](const std::string& s) { std::cout << "we got a string: " << s << std::endl; }
}, r);
}
-
a) dynamický jazyk je dynamický, dynamické jsou i typy, takže je nemůžeš předem staticky dát do výčtu, každá třída je novým typem
>>> class A(object): pass
>>> type(type(A()))
<class 'type'>
Ono se o Pythonu říká, že to je jeden velkej "symbol-table hack"... Prostě si tam do toho typu přidáš "VObject Name (HashMap String JSValue), nějak si inteligentně nadefinuješ "isinstance" funkci (aby nějak pracovala s Name), případně tu "type", aby vracela nějaký ten VObject a máš python. Fakt. Všechny ty třídy v pythonu jsou prakticky stejný, akorát se liší v tom, jaký mají __class__.
b) dynamický jazyk rozlišuje datové typy svých hodnot, což ten enum nedělá, v dynamickém jazyku ta varianta je datový typ. Nejde jen o to, že můžeš vrátit libovolnou hodnotu, ale že znáš její typ s kterým můžeš pracovat a s kterým pracuje jazyk. Co to udělá, když budes sčítat hodnoty 5 + '5' obě jednoho součtového typu? V pythonu ti to spadne na rozdílnost datových typů.
Podívej se na definici toho (+). Ty jednotlivé řádky jsou varianty podle těch typů, co to dostane. Buď takhle nebo přes "case" se můžeš zeptat, která z těch variant (to, co ty nazývaš "typ") to je. Když se pokusíš sečíst číslo a string, tak to slítne na ten "error".
c) i v dynamickém jazyku můžeš funkci omezit, buď dekorátorem, což se kontroluje runtime a nebo type hintem, což se kontroluje při překladu.
Tak runtime si to můžeš omezit s tím jedním typem jednoduše...prostě si zkontroluješ, jestli jsi dostal správnou variantu. Type hint už pak naopak dělá z dynamického jazyka statický, kdy už třeba některé funkce mají jiný typ než ten univerzální JSValue.
Jenom k terminologii - tohle je z knihy Types and Programming languages (Pierce), to je takový základní text:
A type system is a tractable syntactic method for proving the absence of certain program behaviours by classyfing phrases according to the kinds of values they compute.
-
Rád bych tu viděl příklad, kde funkce vrací hodnoty různých datových typů (false, none, object), předává to nějaké proměnné a dále se program větví podle toho, jaká hodnota byla předána. Jestli to nejde, pak je z vaše zaklínání se součtovým typem pěkná blamáž. :-).
Pominu tvoji terminologii, tady máš příklad:
data JSValue = JSBool Boolean | JSNone | JSText String
-- Funkce f: parametr typu "String", vraci typ "JSValue"
f :: String -> JSValue
f "true" = JSBool True
f "false" = JSBool False
f "none" = JSNone
f t = JSText t
mojeFunkce :: IO () -- (treba...)
mojeFunkce = do
vstup <- readLine -- neco precti ze vstupu
let result = f vstup -- Zavolame nasi funkci 'f'
case result of -- Pattern match na jednotlive varianty
JSBool b -> if b then putStrLn "dostali jsme true" else putStrLn "dostali jsme false"
JSNone -> putStrLn "dostali jsme None"
JSText t -> putStrLn ("Dostali jsme nejaky jiny string: " <> t)
Nejsem si jist, zda ten zapis chapu spravne.
a) Promenna result je jakeho typu? Nevidim jeji deklaraci. A co je to fyzicky? Pojmenovana pamet kde je hodnota nebo pojmenovana pamet, kde je adresa pameti s hodnotou?
b) of dela co? zjistuje datove typy promenne nebo hodnoty? Podle ceho, odkud se ta informace bere?
c) kdyz funkci f spustim dvakrat a vysledky nactu do result1 (None) a result2 (Text), jaky datovy typ bude mit promenne result1 a result2 a co bude vysledkem?
-
a) dynamický jazyk je dynamický, dynamické jsou i typy, takže je nemůžeš předem staticky dát do výčtu, každá třída je novým typem
>>> class A(object): pass
>>> type(type(A()))
<class 'type'>
Ono se o Pythonu říká, že to je jeden velkej "symbol-table hack"... Prostě si tam do toho typu přidáš "VObject Name (HashMap String JSValue), nějak si inteligentně nadefinuješ "isinstance" funkci (aby nějak pracovala s Name), případně tu "type", aby vracela nějaký ten VObject a máš python. Fakt. Všechny ty třídy v pythonu jsou prakticky stejný, akorát se liší v tom, jaký mají __class__.
b) dynamický jazyk rozlišuje datové typy svých hodnot, což ten enum nedělá, v dynamickém jazyku ta varianta je datový typ. Nejde jen o to, že můžeš vrátit libovolnou hodnotu, ale že znáš její typ s kterým můžeš pracovat a s kterým pracuje jazyk. Co to udělá, když budes sčítat hodnoty 5 + '5' obě jednoho součtového typu? V pythonu ti to spadne na rozdílnost datových typů.
Podívej se na definici toho (+). Ty jednotlivé řádky jsou varianty podle těch typů, co to dostane. Buď takhle nebo přes "case" se můžeš zeptat, která z těch variant (to, co ty nazývaš "typ") to je. Když se pokusíš sečíst číslo a string, tak to slítne na ten "error".
c) i v dynamickém jazyku můžeš funkci omezit, buď dekorátorem, což se kontroluje runtime a nebo type hintem, což se kontroluje při překladu.
Tak runtime si to můžeš omezit s tím jedním typem jednoduše...prostě si zkontroluješ, jestli jsi dostal správnou variantu. Type hint už pak naopak dělá z dynamického jazyka statický, kdy už třeba některé funkce mají jiný typ než ten univerzální JSValue.
Jenom k terminologii - tohle je z knihy Types and Programming languages (Pierce), to je takový základní text:
A type system is a tractable syntactic method for proving the absence of certain program behaviours by classyfing phrases according to the kinds of values they compute.
Python (a JS též) jsou hezké v tom, jak umožňují uzávěry nad třídami. Vnitřní implementace je sice zoufalá, ale kód je z akademického pohledu bjůtyfl.
-
Rád bych tu viděl příklad, kde funkce vrací hodnoty různých datových typů (false, none, object), předává to nějaké proměnné a dále se program větví podle toho, jaká hodnota byla předána. Jestli to nejde, pak je z vaše zaklínání se součtovým typem pěkná blamáž. :-).
Pominu tvoji terminologii, tady máš příklad:
data JSValue = JSBool Boolean | JSNone | JSText String
-- Funkce f: parametr typu "String", vraci typ "JSValue"
f :: String -> JSValue
f "true" = JSBool True
f "false" = JSBool False
f "none" = JSNone
f t = JSText t
mojeFunkce :: IO () -- (treba...)
mojeFunkce = do
vstup <- readLine -- neco precti ze vstupu
let result = f vstup -- Zavolame nasi funkci 'f'
case result of -- Pattern match na jednotlive varianty
JSBool b -> if b then putStrLn "dostali jsme true" else putStrLn "dostali jsme false"
JSNone -> putStrLn "dostali jsme None"
JSText t -> putStrLn ("Dostali jsme nejaky jiny string: " <> t)
Nejsem si jist, zda ten zapis chapu spravne.
a) Promenna result je jakeho typu? Nevidim jeji deklaraci. A co je to fyzicky? Pojmenovana pamet kde je hodnota nebo pojmenovana pamet, kde je adresa pameti s hodnotou?
b) of dela co? zjistuje datove typy promenne nebo hodnoty? Podle ceho, odkud se ta informace bere?
c) kdyz funkci f spustim dvakrat a vysledky nactu do result1 (None) a result2 (Text), jaky datovy typ bude mit promenne result1 a result2 a co bude vysledkem?
Radši bádej na tím kódem v C++, je názornější a bez monád.
-
data JSValue = JSBool Boolean | JSNone | JSText String
-- Funkce f: parametr typu "String", vraci typ "JSValue"
f :: String -> JSValue
f "true" = JSBool True
f "false" = JSBool False
f "none" = JSNone
f t = JSText t
mojeFunkce :: IO () -- (treba...)
mojeFunkce = do
vstup <- readLine -- neco precti ze vstupu
let result = f vstup -- Zavolame nasi funkci 'f'
case result of -- Pattern match na jednotlive varianty
JSBool b -> if b then putStrLn "dostali jsme true" else putStrLn "dostali jsme false"
JSNone -> putStrLn "dostali jsme None"
JSText t -> putStrLn ("Dostali jsme nejaky jiny string: " <> t)
Nejsem si jist, zda ten zapis chapu spravne.
a) Promenna result je jakeho typu? Nevidim jeji deklaraci. A co je to fyzicky? Pojmenovana pamet kde je hodnota nebo pojmenovana pamet, kde je adresa pameti s hodnotou?
Proměnná result je typu toho, co vrací funkce "f", tzn. JSValue (příklad type inference). No, fyzicky...fyzicky v podstatě ta proměnná neexistuje.... "let" je definice. Jako v matematice. V podstatě kdekoliv pak použiješ v kódu "result", tak se místo toho vloží "f vstup" (kvůli optimalizaci je to malinko jinak, ale to je podstata).
b) of dela co? zjistuje datove typy promenne nebo hodnoty? Podle ceho, odkud se ta informace bere?
"case .... of" je normální "case" jako z Javy, C apod. Ty řádký pod tím je tzv. Pattern match na hodnoty, které to může nabývat. "JSBool b" říká: je to varianta JSBool a do proměnné "b" dej ten parametr té varianty (tzn. true nebo false)
c) kdyz funkci f spustim dvakrat a vysledky nactu do result1 (None) a result2 (Text), jaky datovy typ bude mit promenne result1 a result2 a co bude vysledkem?
Výsledkem funkce f je vždycky hodnota typu JSValue. Na tu je potřeba udělat ten pattern match a na základě toho se dopídit k tomu, kterou variantu jsi dostal. Já zkusím kód v nějakým pseudo-C, který v zásadě dělá to samý (ale hrozně ošklivě a z hlavy):
enum TType = { JSBool, JSText, JSNone}
struct JSValue {
TType tag;
union {
bool boolVal;
String stringVal;
}val;
}
JSValue f(String vstup) {
struct JSValue result;
if (vstup == "true") {
result.tag = JSBool;
result.boolVal = true;
} else ...
return result;
}
int main() {
JSValue result = f("true");
switch (result.tag) {
case JSBool:
bool b = result.val.boolval;
if (b) printf("Dostali jsme true...");
break;
case...
}
}
Tímhle způsobem můžeš snadno vracet hodnoty různých typů i v C. Ale výhoda jazyků, které přímo součtové typy podporují, je samozřejmě výrazně jednodušší syntaxe a hlavně kontrola jazyka, že jsi třeba nějakou variantu nezapomněl ošetřit, že jsi nezapomněl nastavit ten result.val, že jsi tam opravdu dal správný typ atd.. Popravdě, co mě na většině jazycích štve je právě absence součtových typů, dost výrazným způsobem to usnadní práci a zvýší bezpečnost programu.
-
a) dynamický jazyk je dynamický, dynamické jsou i typy, takže je nemůžeš předem staticky dát do výčtu, každá třída je novým typem
>>> class A(object): pass
>>> type(type(A()))
<class 'type'>
Ono se o Pythonu říká, že to je jeden velkej "symbol-table hack"... Prostě si tam do toho typu přidáš "VObject Name (HashMap String JSValue), nějak si inteligentně nadefinuješ "isinstance" funkci (aby nějak pracovala s Name), případně tu "type", aby vracela nějaký ten VObject a máš python. Fakt. Všechny ty třídy v pythonu jsou prakticky stejný, akorát se liší v tom, jaký mají __class__.
b) dynamický jazyk rozlišuje datové typy svých hodnot, což ten enum nedělá, v dynamickém jazyku ta varianta je datový typ. Nejde jen o to, že můžeš vrátit libovolnou hodnotu, ale že znáš její typ s kterým můžeš pracovat a s kterým pracuje jazyk. Co to udělá, když budes sčítat hodnoty 5 + '5' obě jednoho součtového typu? V pythonu ti to spadne na rozdílnost datových typů.
Podívej se na definici toho (+). Ty jednotlivé řádky jsou varianty podle těch typů, co to dostane. Buď takhle nebo přes "case" se můžeš zeptat, která z těch variant (to, co ty nazývaš "typ") to je. Když se pokusíš sečíst číslo a string, tak to slítne na ten "error".
c) i v dynamickém jazyku můžeš funkci omezit, buď dekorátorem, což se kontroluje runtime a nebo type hintem, což se kontroluje při překladu.
Tak runtime si to můžeš omezit s tím jedním typem jednoduše...prostě si zkontroluješ, jestli jsi dostal správnou variantu. Type hint už pak naopak dělá z dynamického jazyka statický, kdy už třeba některé funkce mají jiný typ než ten univerzální JSValue.
Jenom k terminologii - tohle je z knihy Types and Programming languages (Pierce), to je takový základní text:
A type system is a tractable syntactic method for proving the absence of certain program behaviours by classyfing phrases according to the kinds of values they compute.
Jak funguje python mi nemusíš vysvětlovat. Implementace není podstatná, důležité je, jakou abstrakci ti to poskytuje na venek.
Pořád máš divnou terminologii. Nechápu, proč ji používáš. Shodnem se na tom, že číslo a string jsou různé datové typy? Ano, když sečtu číslo a string, tak to spadne na type error, proto mi není jasné, proč to označuješ za varianty jednoho datového typu. To jsou hodnoty různých datových typů. Na základě čeho to spadne u tebe, když to považuješ za jeden datový typ?
Type hint z jazyka nedělá statický, statičnost není o deklaraci typů, ale o způsobu práce s pamětí. Python i s type hintem zůstává dynamický, type hint jen pomáhá lépe odhalovat chyby při překladu.
-
data JSValue = JSBool Boolean | JSNone | JSText String
-- Funkce f: parametr typu "String", vraci typ "JSValue"
f :: String -> JSValue
f "true" = JSBool True
f "false" = JSBool False
f "none" = JSNone
f t = JSText t
mojeFunkce :: IO () -- (treba...)
mojeFunkce = do
vstup <- readLine -- neco precti ze vstupu
let result = f vstup -- Zavolame nasi funkci 'f'
case result of -- Pattern match na jednotlive varianty
JSBool b -> if b then putStrLn "dostali jsme true" else putStrLn "dostali jsme false"
JSNone -> putStrLn "dostali jsme None"
JSText t -> putStrLn ("Dostali jsme nejaky jiny string: " <> t)
Nejsem si jist, zda ten zapis chapu spravne.
a) Promenna result je jakeho typu? Nevidim jeji deklaraci. A co je to fyzicky? Pojmenovana pamet kde je hodnota nebo pojmenovana pamet, kde je adresa pameti s hodnotou?
Proměnná result je typu toho, co vrací funkce "f", tzn. JSValue (příklad type inference). No, fyzicky...fyzicky v podstatě ta proměnná neexistuje.... "let" je definice. Jako v matematice. V podstatě kdekoliv pak použiješ v kódu "result", tak se místo toho vloží "f vstup" (kvůli optimalizaci je to malinko jinak, ale to je podstata).
b) of dela co? zjistuje datove typy promenne nebo hodnoty? Podle ceho, odkud se ta informace bere?
"case .... of" je normální "case" jako z Javy, C apod. Ty řádký pod tím je tzv. Pattern match na hodnoty, které to může nabývat. "JSBool b" říká: je to varianta JSBool a do proměnné "b" dej ten parametr té varianty (tzn. true nebo false)
c) kdyz funkci f spustim dvakrat a vysledky nactu do result1 (None) a result2 (Text), jaky datovy typ bude mit promenne result1 a result2 a co bude vysledkem?
Výsledkem funkce f je vždycky hodnota typu JSValue. Na tu je potřeba udělat ten pattern match a na základě toho se dopídit k tomu, kterou variantu jsi dostal. Já zkusím kód v nějakým pseudo-C, který v zásadě dělá to samý (ale hrozně ošklivě a z hlavy):
enum TType = { JSBool, JSText, JSNone}
struct JSValue {
TType tag;
union {
bool boolVal;
String stringVal;
}val;
}
JSValue f(String vstup) {
struct JSValue result;
if (vstup == "true") {
result.tag = JSBool;
result.boolVal = true;
} else ...
return result;
}
int main() {
JSValue result = f("true");
switch (result.tag) {
case JSBool:
bool b = result.val.boolval;
if (b) printf("Dostali jsme true...");
break;
case...
}
}
Tímhle způsobem můžeš snadno vracet hodnoty různých typů i v C. Ale výhoda jazyků, které přímo součtové typy podporují, je samozřejmě výrazně jednodušší syntaxe a hlavně kontrola jazyka, že jsi třeba nějakou variantu nezapomněl ošetřit, že jsi nezapomněl nastavit ten result.val, že jsi tam opravdu dal správný typ atd.. Popravdě, co mě na většině jazycích štve je právě absence součtových typů, dost výrazným způsobem to usnadní práci a zvýší bezpečnost programu.
Takže už ti začínám rozumět. Je to přesně o tom, co jsem tu povídal na začátku o omezeném (bez urážky) myšlení statických programátorů, kteří se nedokáží dívat na program jinak než přes proměnné. Ty stále řešíš datový typ proměnné, nikoliv hodnoty, datový typ hodnoty je pro tebe jen varianta dat. To je chybné vnímání dynamického jazyka. V něm nejsou proměnné důležité. Proměnná v dyn. jazyku je jen ukazatel na hodnotu, není na venek nositelem žádného datového typu a neobsahuje žádnou hodnotu. Je v tomto kontextu nezajímavá. V dynamickém jazyku se pracuje s hodnotami, datový typ je integrální součástí hodnoty, ne proměnné. Neřeš vnitřní implementaci, ta není podstatná a je poplatná optimalizacím, vnímej vnější prezentaci, vnější abstrakci.
-
Pořád máš divnou terminologii. Nechápu, proč ji používáš. Shodnem se na tom, že číslo a string jsou různé datové typy? Ano, když sečtu číslo a string, tak to spadne na type error, proto mi není jasné, proč to označuješ za varianty jednoho datového typu. To jsou hodnoty různých datových typů. Na základě čeho to spadne u tebe, když to považuješ za jeden datový typ?
No úplně právě neshodneme. V dynamických jazycích jsou číslo a string vlastně stejný datový typ ("JSValue"), protože ty můžeš zavolat "3 + '6'" - a normálně se to zavolá. A pak někde v tom __add__ se to zkontroluje a případně spadne. Ty přece klidně můžeš sečíst 2 různé třídy a __add__se normálně zavolá, zkus si to, nikde tam k žádné kontrole nedochází. Typy jsou právě statická záležitost....
Tady to je z Pierce... a je to z knížky, která se celosvětově používá pro výuku teorie typovaných jazyků, takže být tebou se tak úplně nesnažím s tím polemizovat, pokud to nemáš nastudované....
To word "static" is sometimes added explicitly - we speak of a "statically types programming language," for example - to distinguish the sorts of compile-time analyses we are considering her from the dynamic or latent typing found in languages such as Scheme, where run-time type tags are used to distinguish differend kinds of structures in the heap. Terms like "dynamically typed" are arguably misnomers and shoudl probably be replaced by "dynamically checked", but the usage is standard.
Ještě se koukni na tu citaci předtím - typy se řeší staticky. Pokud nejsi schopen ty typy řešit staticky, ale až runtime, tak už se tomu tak úplně neříká typ, ale třeba "tag". Python je naimplementovaný podobně jako ten příklad v C. A všechny ty funkce vrací JSValue (PyValue?? už jsem to API dlouho neviděl).
To je chybné vnímání dynamického jazyka. V něm nejsou proměnné důležité. Proměnná v dyn. jazyku je jen ukazatel na hodnotu, není na venek nositelem žádného datového typu a neobsahuje žádnou hodnotu. Je v tomto kontextu nezajímavá. V dynamickém jazyku se pracuje s hodnotami, datový typ je integrální součástí hodnoty, ne proměnné. Neřeš vnitřní implementaci, ta není podstatná a je poplatná optimalizacím, vnímej vnější prezentaci, vnější abstrakci.
No vždyť jo, v dynamickém jazyce obsahuje každá hodnota "tag", který jsi schopen v runtimu přečíst a zařídit se. Zkus si napsat vlastní implementaci __add__ na sečtení 2 objektů "tvého" typu (napiš si třeba komplexní číslo). Tipuju, že tam někde budeš mít:
def __add__(self, other):
# Tady by mohla byt kontrola na komplex cislo + normalni atd.
# Porovnej tagy... nebo treba pres isinstance...
if type(self) != type(other):
raise TypeError(...)
V Haskellu (i v tom C++) při běhu hodnoty ten tag neobsahují, nejsi schopen dělat introspekci, typy se po compile-time-kontrole normálně vymažou. Proto potřebuješ součtový typ, který tam ty tagy dodá, abys byl schopen ty různé typy rozlišit. No a dynamické jazyky tam ty tagy run-time mají a umíš se na ně run-time zeptat. Takže je to přesně ekvivalentní tomu, jako když ve statickém jazyku použiješ to JSValue... A jak vidíš výše, není to žádný implementační detail, ale normálně se s tím v tom jazyce pracuje (akorát ta terminologie je trošku jiná).
A proto tady protestujeme proti té ne-flexibilitě statického jazyka: přes součtový typ naprosto bez problému uděláš chování, které bude ekvivalentní dynamickým jazykům. Kompiler přestane řvát na chyby typů (kromě počtu parametrů) - všechno bude jeden typ. Nic se nebude kontrolovat compile-time, všechno spadne runtime. Při běhu se budeš moct zeptat na tag ("typ") té hodnoty, kterou tvoje funkce dostane...
Co ti typový systém přináší, je, že těch typů můžeš mít víc a při kompilaci ti to najednou vyhlásí: tahle funkce nemůže vracet číslo....
-
V Haskellu (i v tom C++) při běhu hodnoty ten tag neobsahují
I když teď mě napadá, že pokud nevypneš RTTI, tak to v tom C++ vlastně runtime někde k dispozici je...
-
V Haskellu (i v tom C++) při běhu hodnoty ten tag neobsahují
I když teď mě napadá, že pokud nevypneš RTTI, tak to v tom C++ vlastně runtime někde k dispozici je...
Jen u virtuálních tříd.
-
eee: když si definuju tohle:
data Value = VInt Int | VDouble Double | VStrint Text | VBool Boolean | VObject (Dict Text Value) | VNone
-- Čti: Typ Value může nabývat hodnot "VInt s parametrem celé číslo", "VDouble s parametrem double" etc.
-- To VInt, VDouble je de-fakto "tag"
Tak to je přesně ten typ, který se používá v JS, Pythonu etc. Všechny funkce potom budou typu ve stylu:
já myslím, že to tomu chybí reference/identita objektu
-
eee: když si definuju tohle:
data Value = VInt Int | VDouble Double | VStrint Text | VBool Boolean | VObject (Dict Text Value) | VNone
-- Čti: Typ Value může nabývat hodnot "VInt s parametrem celé číslo", "VDouble s parametrem double" etc.
-- To VInt, VDouble je de-fakto "tag"
Tak to je přesně ten typ, který se používá v JS, Pythonu etc. Všechny funkce potom budou typu ve stylu:
já myslím, že to tomu chybí reference/identita objektu
object.__class__? (teda pomíjím, že to není mutable, ale to myslím není předmětem diskuze)
-
eee: když si definuju tohle:
data Value = VInt Int | VDouble Double | VStrint Text | VBool Boolean | VObject (Dict Text Value) | VNone
-- Čti: Typ Value může nabývat hodnot "VInt s parametrem celé číslo", "VDouble s parametrem double" etc.
-- To VInt, VDouble je de-fakto "tag"
Tak to je přesně ten typ, který se používá v JS, Pythonu etc. Všechny funkce potom budou typu ve stylu:
já myslím, že to tomu chybí reference/identita objektu
Ta je ale k ničemu.
-
Ako sa s temy o PHP stala tema o Haskelly?
-
Pořád máš divnou terminologii. Nechápu, proč ji používáš. Shodnem se na tom, že číslo a string jsou různé datové typy? Ano, když sečtu číslo a string, tak to spadne na type error, proto mi není jasné, proč to označuješ za varianty jednoho datového typu. To jsou hodnoty různých datových typů. Na základě čeho to spadne u tebe, když to považuješ za jeden datový typ?
No úplně právě neshodneme. V dynamických jazycích jsou číslo a string vlastně stejný datový typ ("JSValue"), protože ty můžeš zavolat "3 + '6'" - a normálně se to zavolá. A pak někde v tom __add__ se to zkontroluje a případně spadne. Ty přece klidně můžeš sečíst 2 různé třídy a __add__se normálně zavolá, zkus si to, nikde tam k žádné kontrole nedochází. Typy jsou právě statická záležitost....
Nutíš mě zopakovat, co už jsem jednou napsal.
Implementace není podstatná, důležité je, jakou abstrakci ti to poskytuje na venek.
Tohle je pochopení, které ti chybí. Ty se nezabýváš vlastním jazykem, ale jeho implementací, a to je chybný přístup. Jazyk je jeho vnější abstrakce, kterou poskytuje programátorovi a na této úrovni se s nim zachází.
Chápej, i statické typy jsou jen vrstva abstrakce nad reálnými daty. Reálná data v paměti jsou jen jedničky a nuly organizované a adresované po bajtech, nic víc, nic míň. Všechno nad tím je abstrakce, kterou ti prg. jazyk nad těmito daty poskytuje. Dynamické jazyky jsou implementované ve statických, a to je to, co tě mate a brání ti uvažovat o dynamickém jazyku o level výš, na jeho úrovni abstrakce.
Datový typ není nic jiného, než definice/informace o těchto reálných datech v paměti, která specifikuje, jak s nimi zacházet. A to platí jak pro statické, tak dynamické jazky, akorát ty dynamické jazyky jsou tlustší o jednu (interpretační) úroveň. Platí, že data jsou nějak reálně uložena v paměti a prg. jazyk programátorovi umožňuje s nimi nějakým definovaným způsobem zacházet. Jakým způsobem to dělá je jeho interní záležitost.
Proto datové typy má i dynamický jazyk a neoznačují se tag, ale typ. V Pythonu máš datové typy a zjišťuješ je funkcí type(), nikoliv tag(), stejně tak to má Lua, obdobně v JS máš typeof nebo v php zase gettype() a tak dále. Snažit se to předefinovat je marná a hoavně hloupá snaha, která tě vede k nesmyslnému tvrzení, že číslo a string je v Pythonu ten samý datový typ.
-
Implementace není podstatná, důležité je, jakou abstrakci ti to poskytuje na venek.
Souhlas. Sbstrakce, které poskytuje dynamický jazyk, jsou "zjištění tagu" (type, instanceof), volání funkcí (lze poslat jakoukoliv hodnotu dovnitř, můžeš dostat cokoliv ven). Což je identické ve statickém jazyku součtovému typu JSValue.
Chápej, i statické typy jsou jen vrstva abstrakce nad reálnými daty. Reálná data v paměti jsou jen jedničky a nuly organizované a adresované po bajtech, nic víc, nic míň. Všechno nad tím je abstrakce, kterou ti prg. jazyk nad těmito daty poskytuje. Dynamické jazyky jsou implementované ve statických, a to je to, co tě mate a brání ti uvažovat o dynamickém jazyku o level výš, na jeho úrovni abstrakce.
Abstrakci, kterou dynamický jazyk poskyuje, je (v oblasti té "flexibility", kvůli které o tom mluvíme) ekvivalentní abstrakci JSValue, kterou jsem tady uvedl.
Datový typ není nic jiného, než definice/informace o těchto reálných datech v paměti, která specifikuje, jak s nimi zacházet.
Mám tendenci s tímhle nesouhlasit (paměť je jen implementační detail). Co kdybys toho Pierce přečet (stačí prvních pár kapitol) a pak se k tomu zkusil vyjádřit? Tady to je online: https://www.asc.ohio-state.edu/pollard.4/type/books/pierce-tpl.pdf (https://www.asc.ohio-state.edu/pollard.4/type/books/pierce-tpl.pdf) Je to docela eye-opening....
Proto datové typy má i dynamický jazyk a neoznačují se tag, ale typ. V Pythonu máš datové typy a zjišťuješ je funkcí type(), nikoliv tag(), stejně tak to má Lua, obdobně v JS máš typeof nebo v php zase gettype() a tak dále. Snažit se to předefinovat je marná a hoavně hloupá snaha, která tě vede k nesmyslnému tvrzení, že číslo a string je v Pythonu ten samý datový typ.
Takže to není "tag", ale "typ", protože ta funkce se jmenuje "type" a ne "tag". A kdyby to autoři jazyka nazvali "tag", tak by to nebyl typ, ale tag.... eh... nedostává se mi slov...
Ano, číslo a string je v pythonu jiná hodnota toho samého součtového typu (pokud tam nejsou type anotace). Pokud s tím nesouhlasíš, tak si nejdřív přečti začátek toho Pierce a pak to svoje tvrzení zkus nějak obhájit. V tomto pořadí, ne opačně.
-
Ještě se koukni na tu citaci předtím - typy se řeší staticky. Pokud nejsi schopen ty typy řešit staticky, ale až runtime, tak už se tomu tak úplně neříká typ, ale třeba "tag". Python je naimplementovaný podobně jako ten příklad v C. A všechny ty funkce vrací JSValue (PyValue?? už jsem to API dlouho neviděl).
Datové typy jsou implementovány různě a pořád se tomu říká datový typ, rozhlédni se někdy kolem sebe. Pořád se na to nedovedeš podívat na dynamický jazyk z vyššího nadhledu, než je implementace interpretu ve statickém jazyce. Máš omezené chápání datového typu jako formátu bytů v paměti, jako datový typ proměnné, tak jak s nimi zachází statické jazyky. Datové typy ale mají vyšší principiální význam, označují i druh/význam dat. A mohou být integrální součástí hodnoty, nikoláv proměnné. Tuto jejich vyšší funkci přehlížíš.
-
Ještě se koukni na tu citaci předtím - typy se řeší staticky. Pokud nejsi schopen ty typy řešit staticky, ale až runtime, tak už se tomu tak úplně neříká typ, ale třeba "tag". Python je naimplementovaný podobně jako ten příklad v C. A všechny ty funkce vrací JSValue (PyValue?? už jsem to API dlouho neviděl).
Datové typy jsou implementovány různě a pořád se tomu říká datový typ, rozhlédni se někdy kolem sebe. Pořád se na to nedovedeš podívat na dynamický jazyk z vyššího nadhledu, než je implementace interpretu ve statickém jazyce.
Už sis toho Pierce přečet?
Máš omezené chápání datového typu jako formátu bytů v paměti, jako datový typ proměnné, tak jak s nimi zachází statické jazyky.
Ehm... tos ale před chvílí říkal ty...?
Datový typ není nic jiného, než definice/informace o těchto reálných datech v paměti, která specifikuje, jak s nimi zacházet.
Mám tendenci s tímhle nesouhlasit
???
Datové typy ale mají vyšší principiální význam, označují i druh/význam dat. A mohou být integrální součástí hodnoty, nikoláv proměnné. Tuto jejich vyšší funkci přehlížíš.
Ehm podruhé.... už sis přečet toho Pierce? Znáš tohle? https://cs.wikipedia.org/wiki/Dunning%C5%AFv%E2%80%93Kruger%C5%AFv_efekt (https://cs.wikipedia.org/wiki/Dunning%C5%AFv%E2%80%93Kruger%C5%AFv_efekt) To nemíním jako urážku, ale myslím si, že po přečtení prvních pár kapitol změníš názor... (bohužel rychločtení u tohodle nefunguje)
-
Nicméně mám podezření, že jsme se trošku vzdálili od tématu - tvrdil jsi, že dynamické jazyky mají flexibilitu, že můžeš z jedné funkce vracet false, None a nějaký jiný výsledek. Tak ti bylo ukázáno, že některé často používané statické jazyky (normálnější jako C++, méně obvyklé jako Haskell, Rust atd.) toto umí také v rámci součtových typů (variant atd.). Tudíž mi připadá, že výhoda flexibility u dynamického jazyku...vlastně není. Souhlasíš s tím? Pokud ne, mohl bys teda ukázat konkrétní kód v dynamickém jazyce týkající se tohoto problému, který není řešitelný v jazyce se statickými typy?
-
A proto tady protestujeme proti té ne-flexibilitě statického jazyka: přes součtový typ naprosto bez problému uděláš chování, které bude ekvivalentní dynamickým jazykům. Kompiler přestane řvát na chyby typů (kromě počtu parametrů) - všechno bude jeden typ. Nic se nebude kontrolovat compile-time, všechno spadne runtime. Při běhu se budeš moct zeptat na tag ("typ") té hodnoty, kterou tvoje funkce dostane...
Obávám se, že jsi ještě pořád nepochopil pravou podstatu přívlastku dynamický. Zkus ve statickém jazyku za pomoci součtového typu a type inference implementovat tohle.
>>> data = 'A a=1 b=2 c=3'
>>> data = data.split(' ')
>>>
>>> cls = type(data[0], (), dict(s.split('=') for s in data[1:]))
>>> cls
<class '__main__.A'>
>>>
>>> obj = cls()
>>> obj
<__main__.A object at 0xb65c4e50>
>>> vars(obj)
{}
>>> obj.a
'1'
Tyhle legrácky ti ve statickém jazyku trochu zjednoduší život, ale dynamický jazyk tím ze statického neudělají a na jeho flexibilitu nedosáhnou. Práce s datovými typy v dynamickém jazyku je nový/vyšší level, které typovému/objektovému programování přidává nový rozměr.
-
Implementace není podstatná, důležité je, jakou abstrakci ti to poskytuje na venek.
Souhlas. Sbstrakce, které poskytuje dynamický jazyk, jsou "zjištění tagu" (type, instanceof), volání funkcí (lze poslat jakoukoliv hodnotu dovnitř, můžeš dostat cokoliv ven). Což je identické ve statickém jazyku součtovému typu JSValue.
Sice souhlasíš, ale nechápeš, pleteš si abstrakci jazyka s jeho implementací. Vážně mezi tím nedovedeš rozlišit? To je prostě to omezené myšlení statických programátorů, kteří se na věc nedovedou podívat jiným pohledem, o kterém jsem psal. Nevím jak v tobě rozžehnout jiskru pochopení.
-
Proto datové typy má i dynamický jazyk a neoznačují se tag, ale typ. V Pythonu máš datové typy a zjišťuješ je funkcí type(), nikoliv tag(), stejně tak to má Lua, obdobně v JS máš typeof nebo v php zase gettype() a tak dále. Snažit se to předefinovat je marná a hoavně hloupá snaha, která tě vede k nesmyslnému tvrzení, že číslo a string je v Pythonu ten samý datový typ.
Takže to není "tag", ale "typ", protože ta funkce se jmenuje "type" a ne "tag". A kdyby to autoři jazyka nazvali "tag", tak by to nebyl typ, ale tag.... eh... nedostává se mi slov...
Máš nějaký dar chápat věci obráceně, pozpátku a naruby. Ta kauzalita je přece opačná. Jedná se o datové typy a proto autoři všech těch jazyků tyto introspektivní funkce nazývají type a ne tag :-).
-
Máš omezené chápání datového typu jako formátu bytů v paměti, jako datový typ proměnné, tak jak s nimi zachází statické jazyky.
Ehm... tos ale před chvílí říkal ty...?
Datový typ není nic jiného, než definice/informace o těchto reálných datech v paměti, která specifikuje, jak s nimi zacházet.
Mám tendenci s tímhle nesouhlasit
???
Pochopil jsi mé vyjádření tak, že je to pouhý formát dat v paměti a nic víc? Pak jsi to pochopil špatně, je to informace, která specifikuje, jak s nimi zacházet a to ve smyslu co se s nimi dá a nedá dělat, jakých mohou nabývat hodnot, jejich interakce s ostatními typy, jak je lze konvertovat. Proto máš v pythonu třeba řadu datumových datových typů date, time, datetime, timedelta a podobně.
Zapomeň na datové typy jako na pouhou deklaraci uspořádání bajtů v paměti. To nikdy neplatilo ani pro C, viz jeho typedef.
-
Zapomeň na datové typy jako na pouhou deklaraci uspořádání bajtů v paměti. To nikdy neplatilo ani pro C, viz jeho typedef.
@eee: problém programátorů od statických jazyků je, že uvažují o proměnných, zatímco dynamické jazyky jsou o hodnotách
@ostatní: statické jazyky nejsou o proměnných, ale o hodnotách
@eee: problém programátorů od statických jazyků je, že uvažují o typech jako o pouhém uspořádání bajtů v paměti.
@ostatní: typy ve statických jazycích nejsou o uspořádání bajtů v paměti
@eee: problém programátorů od statických jazyků je, že uvažují o proměnných, zatímco dynamické jazyky jsou o hodnotách
@ostatní: statické jazyky nejsou o proměnných, ale o hodnotách... aha!
-
... číslo a string je v pythonu jiná hodnota toho samého součtového typu ...
Já si dovolím toho Pierce nečíst, a přesto bych měl otázku:
Mám typ: JSValue
Pak mám variantu typu JSString a JSNumber
A pak mám hodnotu typu "text", 43
Takže zápis v haskellu: JSString "text", JSNumber 43.
Nejsem si jist s tím názvoslovím, ale JSString není hodnota, ale konstruktor, ne?
-
... číslo a string je v pythonu jiná hodnota toho samého součtového typu ...
Já si dovolím toho Pierce nečíst, a přesto bych měl otázku:
Mám typ: JSValue
Pak mám variantu typu JSString a JSNumber
A pak mám hodnotu typu "text", 43
Takže zápis v haskellu: JSString "text", JSNumber 43.
Nejsem si jist s tím názvoslovím, ale JSString není hodnota, ale konstruktor, ne?
Jistě, konstruktor.
-
Obávám se, že jsi ještě pořád nepochopil pravou podstatu přívlastku dynamický. Zkus ve statickém jazyku za pomoci součtového typu a type inference implementovat tohle.
>>> data = 'A a=1 b=2 c=3'
>>> data = data.split(' ')
>>>
>>> cls = type(data[0], (), dict(s.split('=') for s in data[1:]))
>>> cls
<class '__main__.A'>
>>>
>>> obj = cls()
>>> obj
<__main__.A object at 0xb65c4e50>
>>> vars(obj)
{}
>>> obj.a
'1'
Tyhle legrácky ti ve statickém jazyku trochu zjednoduší život, ale dynamický jazyk tím ze statického neudělají a na jeho flexibilitu nedosáhnou. Práce s datovými typy v dynamickém jazyku je nový/vyšší level, které typovému/objektovému programování přidává nový rozměr.
No... otázka, co s tím chceš dělat - tak nějak to zavání prasárnou... Nicméně v rámci toho, co jsem psal prostě vyrobíš nový JSObject a narveš tam ty hodnoty... něco jako:
f :: JSValue
newobject input =
let (cls,data) = nejaky split/span input
pairs = parse_pairs data
in JSObject cls (fromList pairs) -- ten JSObject by asi mel byt trozku sirsi, neco jako Parent, __dict__ apod..
-- no a kdyz si zadefinujem nejake operatory (trosku kolize s haskellovymi, ale to se da skryt), tak pak klidne muze fungovat
main = do
let obj = newobject "A a=1 b=2 c=3"
print (obj.#a)
print (typeOf obj)
atd...
What's the problem?
.. pleteš si abstrakci jazyka s jeho implementací. Vážně mezi tím nedovedeš rozlišit?
Když si udělám modul "PyHaskell", která bude obsahovat typ JSValue, pár operátorů a funkcí, které pracují jenom s JSValue - tak výsledkem bude, že budu moct psát v podstatě totéž, jako píšeš v pythonu (haskell je "pure" a "immutable", takže v tom se to bude lišit, ale o tom se nabvíme). Bude to házet TypeError při běhu stejně jako python, budeš moct dělat "instanceOf" a "type" na JSValue stejně jako v pythonu. Budeš moct dereferencovat atributy velmi podobně jako v pythonu. Bude to všechno pracovat s jedním type JSValue.
Prostě importuju jednu knihovnu a budu z toho mít v podstatě python. Tak nevím, co je abstrakce a implementace - připadá mi, že jeden sumtype (JSValue) je abstrakce, která velmi přesně vystihuje to, o čem ty typy v pythonu jsou.
Máš nějaký dar chápat věci obráceně, pozpátku a naruby. Ta kauzalita je přece opačná. Jedná se o datové typy a proto autoři všech těch jazyků tyto introspektivní funkce nazývají type a ne tag :-).
Jo, a autoři typovaných jazyků tomu říkají "tagged types" nebo "sum types". Tak mi zkus vysvětlit, jak se ten "tvůj typ" liší od "tagu". IMO je to úplně totéž...
Pochopil jsi mé vyjádření tak, že je to pouhý formát dat v paměti a nic víc? Pak jsi to pochopil špatně, je to informace, která specifikuje, jak s nimi zacházet a to ve smyslu co se s nimi dá a nedá dělat, jakých mohou nabývat hodnot, jejich interakce s ostatními typy, jak je lze konvertovat. Proto máš v pythonu třeba řadu datumových datových typů date, time, datetime, timedelta a podobně.
No, třeba jsem to pochopil, tak, že to je _mimo jiné_ formát v paměti. Když jsem psal, že "paměť je implementační detail", tak jsem to myslel docela dost vážně. Typ nemá s formátem dat v paměti nic společného.
-
Obávám se, že jsi ještě pořád nepochopil pravou podstatu přívlastku dynamický. Zkus ve statickém jazyku za pomoci součtového typu a type inference implementovat tohle.
>>> data = 'A a=1 b=2 c=3'
>>> data = data.split(' ')
>>>
>>> cls = type(data[0], (), dict(s.split('=') for s in data[1:]))
>>> cls
<class '__main__.A'>
>>>
>>> obj = cls()
>>> obj
<__main__.A object at 0xb65c4e50>
>>> vars(obj)
{}
>>> obj.a
'1'
Tyhle legrácky ti ve statickém jazyku trochu zjednoduší život, ale dynamický jazyk tím ze statického neudělají a na jeho flexibilitu nedosáhnou. Práce s datovými typy v dynamickém jazyku je nový/vyšší level, které typovému/objektovému programování přidává nový rozměr.
No... otázka, co s tím chceš dělat - tak nějak to zavání prasárnou... Nicméně v rámci toho, co jsem psal prostě vyrobíš nový JSObject a narveš tam ty hodnoty... něco jako:
f :: JSValue
newobject input =
let (cls,data) = nejaky split/span input
pairs = parse_pairs data
in JSObject cls (fromList pairs) -- ten JSObject by asi mel byt trozku sirsi, neco jako Parent, __dict__ apod..
-- no a kdyz si zadefinujem nejake operatory (trosku kolize s haskellovymi, ale to se da skryt), tak pak klidne muze fungovat
main = do
let obj = newobject "A a=1 b=2 c=3"
print (obj.#a)
print (typeOf obj)
atd...
What's the problem?
Jasně, když to statický jazyk neumí, je to prasárna. :-)
Přoblém je, že a) jsi to neimplementoval, 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é. 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 :-).
-
.. pleteš si abstrakci jazyka s jeho implementací. Vážně mezi tím nedovedeš rozlišit?
Když si udělám modul "PyHaskell", která bude obsahovat typ JSValue, pár operátorů a funkcí, které pracují jenom s JSValue - tak výsledkem bude, že budu moct psát v podstatě totéž, jako píšeš v pythonu (haskell je "pure" a "immutable", takže v tom se to bude lišit, ale o tom se nabvíme). Bude to házet TypeError při běhu stejně jako python, budeš moct dělat "instanceOf" a "type" na JSValue stejně jako v pythonu. Budeš moct dereferencovat atributy velmi podobně jako v pythonu. Bude to všechno pracovat s jedním type JSValue.
Prostě importuju jednu knihovnu a budu z toho mít v podstatě python. Tak nevím, co je abstrakce a implementace - připadá mi, že jeden sumtype (JSValue) je abstrakce, která velmi přesně vystihuje to, o čem ty typy v pythonu jsou.
Je tomarný, je to marný, je to marný :-). Nejsi schopen rozlišit mezi implementací a abstrakcí. To je hranice na který jsi zaseklý a nedovedeš ji překročit.
Ano, můžeš si ve svém statickém programu implementovat interpret dynamicho jazyka, ale pořád ti bude chybět jeho abstrakce, jeho jazyk. Takže to stále bude mít daleko k pohodlnosti a flexibilitě dynamického jazyka. Bude to stejně hloupé a nepohodlné, jako psát "python" program v C za pomoci jeho python api.
-
Máš nějaký dar chápat věci obráceně, pozpátku a naruby. Ta kauzalita je přece opačná. Jedná se o datové typy a proto autoři všech těch jazyků tyto introspektivní funkce nazývají type a ne tag :-).
Jo, a autoři typovaných jazyků tomu říkají "tagged types" nebo "sum types". Tak mi zkus vysvětlit, jak se ten "tvůj typ" liší od "tagu". IMO je to úplně totéž...
Takže typům říkají types, čemu na tom nerozumíš? To samé to není, ale protože rozdíl je ve vyšší abstrakci, je u tebe zbytečné na to poukazovat.
-
implementovat tohle.
>>> data = 'A a=1 b=2 c=3'
>>> data = data.split(' ')
>>>
>>> cls = type(data[0], (), dict(s.split('=') for s in data[1:]))
>>> cls
<class '__main__.A'>
>>>
>>> obj = cls()
>>> obj
<__main__.A object at 0xb65c4e50>
>>> vars(obj)
{}
>>> obj.a
'1'
Gratuluju k titulu prase roku. Dej to na hovnokód, tam ti to "ocení". A pak si přečti tu knihu, co ti byla doporučena, abys pochopil, že tento tvůj dementní příklad se ani v nejmenším netýká typů.
-
Pochopil jsi mé vyjádření tak, že je to pouhý formát dat v paměti a nic víc? Pak jsi to pochopil špatně, je to informace, která specifikuje, jak s nimi zacházet a to ve smyslu co se s nimi dá a nedá dělat, jakých mohou nabývat hodnot, jejich interakce s ostatními typy, jak je lze konvertovat. Proto máš v pythonu třeba řadu datumových datových typů date, time, datetime, timedelta a podobně.
No, třeba jsem to pochopil, tak, že to je _mimo jiné_ formát v paměti. Když jsem psal, že "paměť je implementační detail", tak jsem to myslel docela dost vážně. Typ nemá s formátem dat v paměti nic společného.
Mimo jiné ovšem není jen a já se ti snažím vysvětlit, že datový typ není záležitost jen toho, jak je uložen v paměti nebo případně jak je staticky konstruován v interpretu. To není jeho podstatou.
-
implementovat tohle.
>>> data = 'A a=1 b=2 c=3'
>>> data = data.split(' ')
>>>
>>> cls = type(data[0], (), dict(s.split('=') for s in data[1:]))
>>> cls
<class '__main__.A'>
>>>
>>> obj = cls()
>>> obj
<__main__.A object at 0xb65c4e50>
>>> vars(obj)
{}
>>> obj.a
'1'
Gratuluju k titulu prase roku. Dej to na hovnokód, tam ti to "ocení". A pak si přečti tu knihu, co ti byla doporučena, abys pochopil, že tento tvůj dementní příklad se ani v nejmenším netýká typů.
Můj příklad se bytostně týká typů, asi vůbec netušíš, co ta ukázka ukazuje.
-
implementovat tohle.
>>> data = 'A a=1 b=2 c=3'
>>> data = data.split(' ')
>>>
>>> cls = type(data[0], (), dict(s.split('=') for s in data[1:]))
>>> cls
<class '__main__.A'>
>>>
>>> obj = cls()
>>> obj
<__main__.A object at 0xb65c4e50>
>>> vars(obj)
{}
>>> obj.a
'1'
Gratuluju k titulu prase roku. Dej to na hovnokód, tam ti to "ocení". A pak si přečti tu knihu, co ti byla doporučena, abys pochopil, že tento tvůj dementní příklad se ani v nejmenším netýká typů.
Můj příklad se bytostně týká typů
A proč to jde udělat ve staticky typovaném jazyce úplně stejně (stejně pochybně)? Přiznej se, ty nemáš z informatiky ani Bc. Nestyď se ;)
-
Jasně, když to statický jazyk neumí, je to prasárna. :-)
Ten kód výše ukazuje, že to umí...? A prasárna to je proto, že ze vstupu vyrábět napřímo třídu je koledování si minimálně o security problém. A ano, faktem je, že některé věci (deserializace) jinak v dynamicky typovaných jazycích rozumně dělat nejdou....ve statických samozřejmě ano.
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...
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..
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.
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...
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...
-
... číslo a string je v pythonu jiná hodnota toho samého součtového typu ...
Já si dovolím toho Pierce nečíst, a přesto bych měl otázku:
Mám typ: JSValue
Pak mám variantu typu JSString a JSNumber
A pak mám hodnotu typu "text", 43
Takže zápis v haskellu: JSString "text", JSNumber 43.
Nejsem si jist s tím názvoslovím, ale JSString není hodnota, ale konstruktor, ne?
Ano, je to konstruktor. Myslel jsem to tak, že konkrétní číslo ("JSNumber 43") je hodnota daného typu.
-
implementovat tohle.
>>> data = 'A a=1 b=2 c=3'
>>> data = data.split(' ')
>>>
>>> cls = type(data[0], (), dict(s.split('=') for s in data[1:]))
>>> cls
<class '__main__.A'>
>>>
>>> obj = cls()
>>> obj
<__main__.A object at 0xb65c4e50>
>>> vars(obj)
{}
>>> obj.a
'1'
Gratuluju k titulu prase roku. Dej to na hovnokód, tam ti to "ocení". A pak si přečti tu knihu, co ti byla doporučena, abys pochopil, že tento tvůj dementní příklad se ani v nejmenším netýká typů.
Můj příklad se bytostně týká typů
A proč to jde udělat ve staticky typovaném jazyce úplně stejně (stejně pochybně)? Přiznej se, ty nemáš z informatiky ani Bc. Nestyď se ;)
Tak to předveď :-).
-
Jasně, když to statický jazyk neumí, je to prasárna. :-)
Ten kód výše ukazuje, že to umí...? A prasárna to je proto, že ze vstupu vyrábět napřímo třídu je koledování si minimálně o security problém. A ano, faktem je, že některé věci (deserializace) jinak v dynamicky typovaných jazycích rozumně dělat nejdou....ve statických samozřejmě ano.
V čem si tvůj kód mohu přeložit a vyzkoušet jeho funkčnost?
O security problém si koleduješ vždycky, když čteš data z venku. Je číst data z venku prasárna? Je snad json prasárna? :-)
-
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.
-
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é.
-
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ý.
-
{-# 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)
-
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.
-
{-# 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)
-
cabal update
cabal install split
ghci main.hs
-
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ý?
-
{-# 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ší.
-
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ě.
-
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í.
-
{-# 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.
-
{-# 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.
-
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.
-
{-# 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.
-
Díky v za sepsání ukázky...
{-# 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ší.
To je dobrý, eee tady chce, jak by se daný problém řešil "stejně" v kompletně jiném jazyce, o kterém tvrdí, že to v něm nejde. Tak je mu předveden minikód, který podobnou funkcionalitu "typů" jako v Pythonu vyrobí na 15 řádkách (ze kterých jde klidně udělat knihovna) a ty si stěžuješ, že to je "složité"....
-
funguje s repl.it, "obskurní knihovnu" nahrazuje splitOnChar, speciálně pro Kita odstraněn "syntactic sugar"
import Data.Map
data V = N Double | S String | O String (Map V V) | C String (Map V V)
deriving (Ord, Eq, Show)
type_ name fields = C name (fromList fields)
new (C name fields) = O name fields
O _ fields ... k = fields ! k
--stolen from prelude
splitOnChar c s
= case dropWhile (c==) s of
"" -> []
s' -> w : splitOnChar c s''
where
(w, s'') = break (c==) s'
main = do
let cls:fields = splitOnChar ' ' "A a=1 b=2 c=3"
let fields' = fmap ((\[k,v] -> (S k, S v)) . splitOnChar '=') fields
let ty = type_ cls fields'
print ty
let o = new ty
print (o ... S "a")
-
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čí
???? z tvé neschopnosti něco zkompilovat je zřejmé...co? Knihovna "split" je na rozsekávání stringů....
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.
Vy už tady normálně trolíte. Otázka zněla, zda lze python řešení udělat ve statickém jazyce. "V" tady ukázal kompletní zkompilovatelné řešení, které to dělá. V Haskellu bys samozřejmě řešil celou otázku přímo přes HashMap (dict) a nevyráběl si kvůli tomu nějaké typy. Ale chtěl jsi typy, tak máš 15řádkovou knihovnu (nazvi si je třeba PyTypes), dej si na začátek "import PyTypes" a celý to má v podstatě stejnou délku.
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í.
V rámci tvého paradigmatu je C "first-class datový typ".
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ě.
Tak už jsi přiznal? Mimochodem,už jsi si přečetl prvních pár kapitol Pierce?
-
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.
Nevím, jestli i Javu považuješ za statický jazyk, ale dělá se to v ní často a docela snadno.
-
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.
Nevím, jestli i Javu považuješ za statický jazyk, ale dělá se to v ní často a docela snadno.
Ono je to trošku napůl (má to run-time tagování), ale...teď si teda nejsem nějak schopen vybavit, že bych to někde viděl - jaké je to časté využití? Serializační knihovny?
-
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.
Nevím, jestli i Javu považuješ za statický jazyk, ale dělá se to v ní často a docela snadno.
Ono je to trošku napůl (má to run-time tagování), ale...teď si teda nejsem nějak schopen vybavit, že bych to někde viděl - jaké je to časté využití? Serializační knihovny?
DO proxy? Nebo db4objects to taky měla.
-
Dobré je to třeba k pochopení, že dynamické jazyky mají datové typy a ...
Tohle je vůbec formulace. Má se to chápat tak, že staticky typované jazyky typy nemají, nebo co?
Ale abych byl alespoň trochu konstruktivní: vykašli se na cizí termíny, zdá se, že ti tu mnozí nerozumí ve způsobu jak používáš termín typ, implementace a abstrakce. Zkus to prosím, opravdu tě prosím, jednoduše popsat, v čem je podle tebe výhoda dynamických jazyků. Jednoduše, polopatě. Žádné cizí výrazy. Třeba na nějakém příkladu. Hlavně žádnou esoteriku prosím.
A prosím tě ještě o jednu věc, ať je ten příklad alespoň trochu věrohodnej.
A aby si mě nechápal špatně, není to z mé strany ironie. Jen se mi nechce věřit, že by spousta chytrejch lidí dělala věc, bez racionálního užitku.
-
Dobré je to třeba k pochopení, že dynamické jazyky mají datové typy a ...
Tohle je vůbec formulace. Má se to chápat tak, že staticky typované jazyky typy nemají, nebo co?
Vždyť výše psal, že Haskell typy nemá.
-
v čem je podle tebe výhoda dynamických jazyků
Sice nejsem pan eee, ale za mě je to podstatně jednodušší a kratší kód. Má to samozřejmě i svoje nevýhody, ale na to se neptáte.
-
v čem je podle tebe výhoda dynamických jazyků
podstatně jednodušší a kratší kód
To tu přece už haskellisti vyvrátili.
-
Haskell je mě moc mainstream. Ještě by to mohli vyvrátit v něčem obskurnějším, třeba v Javě.
-
v čem je podle tebe výhoda dynamických jazyků
Sice nejsem pan eee, ale za mě je to podstatně jednodušší a kratší kód. Má to samozřejmě i svoje nevýhody, ale na to se neptáte.
Děkuji. V porovnání k jakému jazyku?
-
Haskell je mě moc mainstream. Ještě by to mohli vyvrátit v něčem obskurnějším, třeba v Javě.
Tak haskell se tu stavel proti pythonu. Co dame proti Jave? Navrhuju malbolge.
-
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.
Nevím, jestli i Javu považuješ za statický jazyk, ale dělá se to v ní často a docela snadno.
Ono je to trošku napůl (má to run-time tagování), ale...teď si teda nejsem nějak schopen vybavit, že bych to někde viděl - jaké je to časté využití? Serializační knihovny?
Kolekce a generika to v Javě zvládají s přehledem. Bez serializace. Jakékoli zpracování stromu se bez toho neobejde - uzly i listy mohou být tvořeny instancemi různých tříd dle potřeby. Stačí mít společné rozhraní.
-
Jakékoli zpracování stromu se bez toho neobejde - uzly i listy mohou být tvořeny instancemi různých tříd dle potřeby. Stačí mít společné rozhraní.
Ano, to je přesně místo, kde se perfektně využijí součtové typy - garantují, že uzly/listy mohou nabývat pouze předem definovaných hodnot (instance konkrétních tříd). Kotlin už tohle umožňuje jako tzv. sealed classes. Naopak přístup Javy je spíš přístupem dynamického jazyka - ta třída je interně otagovaná a při přetypování (nebo instanceOf) se ty tagy runtime porovnávají.
-
Jakékoli zpracování stromu se bez toho neobejde - uzly i listy mohou být tvořeny instancemi různých tříd dle potřeby. Stačí mít společné rozhraní.
Ano, to je přesně místo, kde se perfektně využijí součtové typy - garantují, že uzly/listy mohou nabývat pouze předem definovaných hodnot (instance konkrétních tříd). Kotlin už tohle umožňuje jako tzv. sealed classes. Naopak přístup Javy je spíš přístupem dynamického jazyka - ta třída je interně otagovaná a při přetypování (nebo instanceOf) se ty tagy runtime porovnávají.
Jen ze zvědavosti - rozumím, že často se hodí graf (,list, atp.) kde jsou hodnoty nějakého uzavřeného typu (součtový typ). Co když chci mít v Haskellu typ otevřený? Je možné mít např. hodnoty "všech typů, které jsou instancí nějaké typeclass"? V Rustu tohle jde (trait objects), v Javě a spol. to skoro jinak ani nejde (použije se třídní polymorfizmus), jak je to v Haskellu?
-
Jakékoli zpracování stromu se bez toho neobejde - uzly i listy mohou být tvořeny instancemi různých tříd dle potřeby. Stačí mít společné rozhraní.
Ano, to je přesně místo, kde se perfektně využijí součtové typy - garantují, že uzly/listy mohou nabývat pouze předem definovaných hodnot (instance konkrétních tříd). Kotlin už tohle umožňuje jako tzv. sealed classes. Naopak přístup Javy je spíš přístupem dynamického jazyka - ta třída je interně otagovaná a při přetypování (nebo instanceOf) se ty tagy runtime porovnávají.
Jen ze zvědavosti - rozumím, že často se hodí graf (,list, atp.) kde jsou hodnoty nějakého uzavřeného typu (součtový typ). Co když chci mít v Haskellu typ otevřený? Je možné mít např. hodnoty "všech typů, které jsou instancí nějaké typeclass"? V Rustu tohle jde (trait objects), v Javě a spol. to skoro jinak ani nejde (použije se třídní polymorfizmus), jak je to v Haskellu?
dovolím si odpovědět za andyho, jo, jde to
-
jedna z obecnějších možností:
{-# 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
-
Jakékoli zpracování stromu se bez toho neobejde - uzly i listy mohou být tvořeny instancemi různých tříd dle potřeby. Stačí mít společné rozhraní.
Ano, to je přesně místo, kde se perfektně využijí součtové typy - garantují, že uzly/listy mohou nabývat pouze předem definovaných hodnot (instance konkrétních tříd). Kotlin už tohle umožňuje jako tzv. sealed classes. Naopak přístup Javy je spíš přístupem dynamického jazyka - ta třída je interně otagovaná a při přetypování (nebo instanceOf) se ty tagy runtime porovnávají.
Jaké přetypování máš na mysli? Jaké instanceOf? To někdo používá?
-
Jakékoli zpracování stromu se bez toho neobejde - uzly i listy mohou být tvořeny instancemi různých tříd dle potřeby. Stačí mít společné rozhraní.
Ano, to je přesně místo, kde se perfektně využijí součtové typy - garantují, že uzly/listy mohou nabývat pouze předem definovaných hodnot (instance konkrétních tříd). Kotlin už tohle umožňuje jako tzv. sealed classes. Naopak přístup Javy je spíš přístupem dynamického jazyka - ta třída je interně otagovaná a při přetypování (nebo instanceOf) se ty tagy runtime porovnávají.
Jaké přetypování máš na mysli? Jaké instanceOf? To někdo používá?
Neuvědomil jsem si, že se ptáš na objekty se stejným rozhraním. Byl jsem už o krok dál, občas člověk potřebuje ukládat nějaké objekty, na které napasovat stejné rozhraní je trošku přes ruku. Ta odpověď od v je správně, přes ConstraintKinds a ExistentialQuantification se dá tohle udělat docela pěkně. Z nějakého důvodu se to považuje spíš za anti-pattern, ale mám trošku podezření, že tohle je pravidlo ve stylu "nejdřív se ho nauč, a pak ho porušuj".
-
Jakékoli zpracování stromu se bez toho neobejde - uzly i listy mohou být tvořeny instancemi různých tříd dle potřeby. Stačí mít společné rozhraní.
Ano, to je přesně místo, kde se perfektně využijí součtové typy - garantují, že uzly/listy mohou nabývat pouze předem definovaných hodnot (instance konkrétních tříd). Kotlin už tohle umožňuje jako tzv. sealed classes. Naopak přístup Javy je spíš přístupem dynamického jazyka - ta třída je interně otagovaná a při přetypování (nebo instanceOf) se ty tagy runtime porovnávají.
Jaké přetypování máš na mysli? Jaké instanceOf? To někdo používá?
Neuvědomil jsem si, že se ptáš na objekty se stejným rozhraním. Byl jsem už o krok dál, občas člověk potřebuje ukládat nějaké objekty, na které napasovat stejné rozhraní je trošku přes ruku.
Vždycky se objekty dají napasovat na společné rozhraní - v nouzi použiješ proxy. Společné rozhraní však mívám už v okamžiku návrhu, teprve pak řeším implementaci komponent.
-
Vždycky se objekty dají napasovat na společné rozhraní - v nouzi použiješ proxy. Společné rozhraní však mívám už v okamžiku návrhu, teprve pak řeším implementaci komponent.
Ano, vždycky dají...... a často to bývá zbytečné žonglování, když se to dá vyřešit součtovým typem...
-
Vždycky se objekty dají napasovat na společné rozhraní - v nouzi použiješ proxy. Společné rozhraní však mívám už v okamžiku návrhu, teprve pak řeším implementaci komponent.
Ano, vždycky dají...... a často to bývá zbytečné žonglování, když se to dá vyřešit součtovým typem...
Zbytečné žonglování je to jen tehdy, když se snažíš udělat rozhraní až dodatečně místo předem.
-
Vždycky se objekty dají napasovat na společné rozhraní - v nouzi použiješ proxy. Společné rozhraní však mívám už v okamžiku návrhu, teprve pak řeším implementaci komponent.
Ano, vždycky dají...... a často to bývá zbytečné žonglování, když se to dá vyřešit součtovým typem...
Zbytečné žonglování je to jen tehdy, když se snažíš udělat rozhraní až dodatečně místo předem.
Rád se poučím - jak v Javě implementuješ normální binární strom? V jazycích se součtovými typy se to dělá takhle:
data Tree a = Node (Tree a) (Tree a) | Leaf aJak to uděláš v Javě? Buď si uděláš dvě třídy (Node, Leaf) a budeš to přetypovávat. Nebo nad to uděláš společný interface (případně to rovnou vrazíš do jedné třídy), a budeš tam mít metody typu "isNode", "isLeaf", "getLeft", "getRight". To ti pro změnu nezabrání udělat "getLeft" na Leaf, takže ten společný interface je dost násilný. Nebo do interfacu dáš metodu "udělěj()" a budeš to v podstatě řešit přes inversion of control (což by byla zrovna tady docela lahůdka). Nic jiného mě nenapadá, ale nejsem Java nejvyšší guru - jaké je podle tebe to správné řešení?
A samozřejmě totéž se může stát u konkrétních hodnot - mohou mít něco společného, ale také můžou mít diametrálně odlišné vlastnosti. Součtový typ je logické řešení a hezky se mapuje na to, co to má modelovat - prvek je "A nebo B nebo C". Rvát na to stejný interface je prostě snaha ten součtový typ nějak namodelovat.
-
Vždycky se objekty dají napasovat na společné rozhraní - v nouzi použiješ proxy. Společné rozhraní však mívám už v okamžiku návrhu, teprve pak řeším implementaci komponent.
Ano, vždycky dají...... a často to bývá zbytečné žonglování, když se to dá vyřešit součtovým typem...
Zbytečné žonglování je to jen tehdy, když se snažíš udělat rozhraní až dodatečně místo předem.
Rád se poučím - jak v Javě implementuješ normální binární strom? V jazycích se součtovými typy se to dělá takhle:
data Tree a = Node (Tree a) (Tree a) | Leaf aJak to uděláš v Javě? Buď si uděláš dvě třídy (Node, Leaf) a budeš to přetypovávat. Nebo nad to uděláš společný interface (případně to rovnou vrazíš do jedné třídy), a budeš tam mít metody typu "isNode", "isLeaf", "getLeft", "getRight". To ti pro změnu nezabrání udělat "getLeft" na Leaf, takže ten společný interface je dost násilný. Nebo do interfacu dáš metodu "udělěj()" a budeš to v podstatě řešit přes inversion of control (což by byla zrovna tady docela lahůdka).
V Javě nedělám, ale v PHP tohle řeším právě přes to "udělěj()". Je to mnohem jednodušší než ostatní uvažovaná řešení. Hlavně tím odpadnou zbytečné metody "isNode", "isLeaf", "getLeft", "getRight" apod. Nehledě k tomu, že tento přístup by tě omezoval pouze na binární stromy.
-
Vždycky se objekty dají napasovat na společné rozhraní - v nouzi použiješ proxy. Společné rozhraní však mívám už v okamžiku návrhu, teprve pak řeším implementaci komponent.
Ano, vždycky dají...... a často to bývá zbytečné žonglování, když se to dá vyřešit součtovým typem...
Zbytečné žonglování je to jen tehdy, když se snažíš udělat rozhraní až dodatečně místo předem.
Rád se poučím - jak v Javě implementuješ normální binární strom? V jazycích se součtovými typy se to dělá takhle:
data Tree a = Node (Tree a) (Tree a) | Leaf aJak to uděláš v Javě? Buď si uděláš dvě třídy (Node, Leaf) a budeš to přetypovávat. Nebo nad to uděláš společný interface (případně to rovnou vrazíš do jedné třídy), a budeš tam mít metody typu "isNode", "isLeaf", "getLeft", "getRight". To ti pro změnu nezabrání udělat "getLeft" na Leaf, takže ten společný interface je dost násilný. Nebo do interfacu dáš metodu "udělěj()" a budeš to v podstatě řešit přes inversion of control (což by byla zrovna tady docela lahůdka).
V Javě nedělám, ale v PHP tohle řeším právě přes to "udělěj()". Je to mnohem jednodušší než ostatní uvažovaná řešení. Hlavně tím odpadnou zbytečné metody "isNode", "isLeaf", "getLeft", "getRight" apod. Nehledě k tomu, že tento přístup by tě omezoval pouze na binární stromy.
Jo, když má člověk v arzenálu i součtový typ, i nějakou formu polymorfizmu, může si vybrat, a každé řešení má svoje pro a proti.
Když použiju součtový typ, těžko se mi rozšiřuje množina hodnot, nad kterými můžu operovat (musím editovat původní zdroják), ale snadno se mi rozšiřuje množina algoritmů, které s tím pracují (použiju pattern matching, mám zaručený exahustiveness checking).
Když použiju otevřený typ (interface/instance), snadno se mi rozšiřuje množina hodnot (prostě někde jinde udělám novou instanci a ono to s ní funguje), ale blbě se mi rozšiřuje množina algoritmů (chci třeba umět každou hodnotu vykreslit, což by znamenalo přidat do interface nějakou metodu "draw" - musím editovat původní zdroják).
Takže podle situace je prostě vhodnější jedno nebo druhé, součtový typ používám tam, kde očekávám že typ se nebude moc rozšiřovat (třeba AST nějakého daného jazyka), otevřený typ tam, kde se zas moc nebudou rozšiřovat operace nad tím typem, ale chci mít možnost přidat další hodnoty (třeba grafické widgety si chci mít možnost přidělat v nějakém rozšiřujícím modulu, ale operace přibývat nebudou - bude tam nějaké kreslení, události atp. a hotovo).
Když chci oboje, dostanu https://en.wikipedia.org/wiki/Expression_problem :-)
Takže je to spíš rozhodnutí podle specifického případu, který řeším, než podle jazyka - ovšem za předpokladu, že mám slušný jazyk, který umí součtové typy :) Jinak se to skutečně musí v OOP bez ADT řešit přes dispatch na nějaké "udělej". Ona to v praxi není zas taková tragédie, když si na to člověk zvykne, ale mít k dispozici skutečný součtový typ a pattern matching je samozřejmě mnohem lepší...
-
Vždycky se objekty dají napasovat na společné rozhraní - v nouzi použiješ proxy. Společné rozhraní však mívám už v okamžiku návrhu, teprve pak řeším implementaci komponent.
Ano, vždycky dají...... a často to bývá zbytečné žonglování, když se to dá vyřešit součtovým typem...
Zbytečné žonglování je to jen tehdy, když se snažíš udělat rozhraní až dodatečně místo předem.
Rád se poučím - jak v Javě implementuješ normální binární strom? V jazycích se součtovými typy se to dělá takhle:
data Tree a = Node (Tree a) (Tree a) | Leaf aJak to uděláš v Javě? Buď si uděláš dvě třídy (Node, Leaf) a budeš to přetypovávat. Nebo nad to uděláš společný interface (případně to rovnou vrazíš do jedné třídy), a budeš tam mít metody typu "isNode", "isLeaf", "getLeft", "getRight". To ti pro změnu nezabrání udělat "getLeft" na Leaf, takže ten společný interface je dost násilný. Nebo do interfacu dáš metodu "udělěj()" a budeš to v podstatě řešit přes inversion of control (což by byla zrovna tady docela lahůdka).
V Javě nedělám, ale v PHP tohle řeším právě přes to "udělěj()". Je to mnohem jednodušší než ostatní uvažovaná řešení. Hlavně tím odpadnou zbytečné metody "isNode", "isLeaf", "getLeft", "getRight" apod. Nehledě k tomu, že tento přístup by tě omezoval pouze na binární stromy.
Gratuluju k objevu volných monád.
-
V Javě nedělám, ale v PHP tohle řeším právě přes to "udělěj()". Je to mnohem jednodušší než ostatní uvažovaná řešení. Hlavně tím odpadnou zbytečné metody "isNode", "isLeaf", "getLeft", "getRight" apod. Nehledě k tomu, že tento přístup by tě omezoval pouze na binární stromy.
Gratuluju k objevu volných monád.
Nevím, co je volná monáda (prosím zdroj) ale je to úplně normální OOP.
-
V Javě nedělám, ale v PHP tohle řeším právě přes to "udělěj()". Je to mnohem jednodušší než ostatní uvažovaná řešení. Hlavně tím odpadnou zbytečné metody "isNode", "isLeaf", "getLeft", "getRight" apod. Nehledě k tomu, že tento přístup by tě omezoval pouze na binární stromy.
Když vyrábím vyvážený binární strom, tak mě fakt netrápí, že tento přístup mě omezuje pouze na binární stromy...
Ten problém je, když máš na jednom místě věci, které dělají něco jiného. Funkce "vraťPotomky" nedává smysl na listu (při vyvažování), takže bude nějak stupidně implementovaná. Nebo se to celý můžeš pokusit obrátit, psát uzlu, aby "vyvážil sebe", jenže uzel nezná svého rodiče, takže to začne být správný sado-maso kód...
Nebo třeba jsem řešil problém, kdy si uživatel v aplikaci volí různé způsoby navigace a pak má na obrazovce různé informace. Problém je, že pro některé typy navigace ty infoboxy prostě nedávají smysl. Takže buď zvolím nějaký interface, který u většiny navigací bude vracet nějaký nesmysl nebo noop (a to i u toho udělej()), a nebo si v tom infoboxu udělám přetypování na tu konkrétní navigaci a budu volat metody přímo. Což je nejelegantnější, a kdyby Java měla součtové typy, tak i čisté.
Součtové typy samozřejmě neřeší všechno, Expression problem je bohužel realita, ale překvapivě hodně věcí se tím modeluje fakt dobře. Což je taky důvod, proč se to v nových jazycích objevuje stále častěji.
-
V Javě nedělám, ale v PHP tohle řeším právě přes to "udělěj()". Je to mnohem jednodušší než ostatní uvažovaná řešení. Hlavně tím odpadnou zbytečné metody "isNode", "isLeaf", "getLeft", "getRight" apod. Nehledě k tomu, že tento přístup by tě omezoval pouze na binární stromy.
Když vyrábím vyvážený binární strom, tak mě fakt netrápí, že tento přístup mě omezuje pouze na binární stromy...
Ten problém je, když máš na jednom místě věci, které dělají něco jiného. Funkce "vraťPotomky" nedává smysl na listu (při vyvažování), takže bude nějak stupidně implementovaná. Nebo se to celý můžeš pokusit obrátit, psát uzlu, aby "vyvážil sebe", jenže uzel nezná svého rodiče, takže to začne být správný sado-maso kód...
Nebo třeba jsem řešil problém, kdy si uživatel v aplikaci volí různé způsoby navigace a pak má na obrazovce různé informace. Problém je, že pro některé typy navigace ty infoboxy prostě nedávají smysl. Takže buď zvolím nějaký interface, který u většiny navigací bude vracet nějaký nesmysl nebo noop (a to i u toho udělej()), a nebo si v tom infoboxu udělám přetypování na tu konkrétní navigaci a budu volat metody přímo. Což je nejelegantnější, a kdyby Java měla součtové typy, tak i čisté.
Součtové typy samozřejmě neřeší všechno, Expression problem je bohužel realita, ale překvapivě hodně věcí se tím modeluje fakt dobře. Což je taky důvod, proč se to v nových jazycích objevuje stále častěji.
Jsem sice známý tím, že nerad používám frameworky, ale přece jen už nemám potřebu programovat AVL stromy, když dnešní jazyky mají řazení jako součást syntaktického cukru.
Různé informace na obrazovce řeším různými objekty. Mohu je mezi sebou vyměňovat dle potřeby. Jak prosté - SRP je mnohem lepší než dělat nějaký God object.
Nevím, proč bych měl řešit součtové typy, když PHP to má už v základu.
-
V Javě nedělám, ale v PHP tohle řeším právě přes to "udělěj()". Je to mnohem jednodušší než ostatní uvažovaná řešení. Hlavně tím odpadnou zbytečné metody "isNode", "isLeaf", "getLeft", "getRight" apod. Nehledě k tomu, že tento přístup by tě omezoval pouze na binární stromy.
Gratuluju k objevu volných monád.
Nevím, co je volná monáda (prosím zdroj) ale je to úplně normální OOP.
Je to matematická formalizace toho “udělej”: https://ncatlab.org/nlab/show/free+monad
-
Jsem sice známý tím, že nerad používám frameworky, ale přece jen už nemám potřebu programovat AVL stromy, když dnešní jazyky mají řazení jako součást syntaktického cukru.
Chápu, v PHP se člověk zpravidla k implementaci složitějších algoritmů nedostane....
Různé informace na obrazovce řeším různými objekty. Mohu je mezi sebou vyměňovat dle potřeby. Jak prosté - SRP je mnohem lepší než dělat nějaký God object.
To souvisí s čím? Nevím, proč bych měl řešit součtové typy, když PHP to má už v základu.
PHP má součtové typy? A bavili jsme se o tom, jak nikdo nepoužívá instanceOf a přetypování v Javě...asi jsem ztratil nit diskuze....
Ale jinak teď jsem viděl zrovna v PHP hezkou implementaci součtového typu ve stylu CPS. Pokud má jazyk možnost pracovat s higer-order funkcema, pak je to hezký trik, jak to implementovat.
-
V Javě nedělám, ale v PHP tohle řeším právě přes to "udělěj()". Je to mnohem jednodušší než ostatní uvažovaná řešení. Hlavně tím odpadnou zbytečné metody "isNode", "isLeaf", "getLeft", "getRight" apod. Nehledě k tomu, že tento přístup by tě omezoval pouze na binární stromy.
Gratuluju k objevu volných monád.
Nevím, co je volná monáda (prosím zdroj) ale je to úplně normální OOP.
Je to matematická formalizace toho “udělej”: https://ncatlab.org/nlab/show/free+monad
Ve škole jsme funkcionální programování neprobírali a nebyla o tom zmínka ani v matematice, takže je to pro mne hůře stravitelné. Přesto díky za link.
-
Jsem sice známý tím, že nerad používám frameworky, ale přece jen už nemám potřebu programovat AVL stromy, když dnešní jazyky mají řazení jako součást syntaktického cukru.
Chápu, v PHP se člověk zpravidla k implementaci složitějších algoritmů nedostane....
Nejenže nedostane, ale dokonce je to nežádoucí z důvodů negativního dopadu na výkon aplikace.
Různé informace na obrazovce řeším různými objekty. Mohu je mezi sebou vyměňovat dle potřeby. Jak prosté - SRP je mnohem lepší než dělat nějaký God object.
To souvisí s čím?
S tím, že si v objektu vystačím s jednou metodou typu "udělej()". Na jinou práci mám jiný objekt.
Nevím, proč bych měl řešit součtové typy, když PHP to má už v základu.
PHP má součtové typy? A bavili jsme se o tom, jak nikdo nepoužívá instanceOf a přetypování v Javě...asi jsem ztratil nit diskuze...
Součtové typy mají hlavně funkcionální jazyky. V PHP se dá docílit téhož výsledku podobnou konstrukcí.
Ale jinak teď jsem viděl zrovna v PHP hezkou implementaci součtového typu ve stylu CPS. Pokud má jazyk možnost pracovat s higer-order funkcema, pak je to hezký trik, jak to implementovat.
Až budu něco takového skutečně potřebovat, tak to určitě použiji. Určitě však přitom nepoužiji žádný framework, ale napíši to na jeden řádek, jak se v PHP sluší a patří.
-
V Javě nedělám, ale v PHP tohle řeším právě přes to "udělěj()". Je to mnohem jednodušší než ostatní uvažovaná řešení. Hlavně tím odpadnou zbytečné metody "isNode", "isLeaf", "getLeft", "getRight" apod. Nehledě k tomu, že tento přístup by tě omezoval pouze na binární stromy.
Gratuluju k objevu volných monád.
Nevím, co je volná monáda (prosím zdroj) ale je to úplně normální OOP.
Je to matematická formalizace toho “udělej”: https://ncatlab.org/nlab/show/free+monad
Ve škole jsme funkcionální programování neprobírali a nebyla o tom zmínka ani v matematice, takže je to pro mne hůře stravitelné. Přesto díky za link.
Ono to hlavně v praxi v této formě k ničemu není, jen mě občas fascinuje, jak se dá kdejaká veskrze praktická věc zasadit do brutálně abstraktního formálního kontextu (a naopak).