Fórum Root.cz
Práce => Studium a uplatnění => Téma založeno: stud 28. 05. 2017, 19:24:27
-
Ahoj, doporučili byste $SUBJ? Slyšel jsem na ni smíšené recenze, tak si nejsem jistý, jestli se investice do ní vyplatí. Existuje na českém trhu nějaká vhodná alternativa?
-
Místní borci říkali, že OOP je mrtvé, tak aby to vůbec bylo potřeba ;D
-
Ahoj, doporučili byste $SUBJ? Slyšel jsem na ni smíšené recenze, tak si nejsem jistý, jestli se investice do ní vyplatí. Existuje na českém trhu nějaká vhodná alternativa?
Pokud jde o prezentované myšlenky, tak je IMHO dobrá. Pokud jde o formu, připadá mi poněkud zmatená a nevyvážená a prošpikovaná nadbytečnými subjektivními dojmy. Prostě Čada. :)
-
Ahoj, doporučili byste $SUBJ? Slyšel jsem na ni smíšené recenze, tak si nejsem jistý, jestli se investice do ní vyplatí. Existuje na českém trhu nějaká vhodná alternativa?
Je to velmi subjektivne pojate. Coz neni nutne spatne, ale je potreba s tim pocitat.
-
Stačí koupit libovolnou Javu a má OOP luxusní. Jen to nesmí být Pecinovský ;D
-
Stačí koupit libovolnou Javu a má OOP luxusní. Jen to nesmí být Pecinovský ;D
No a tohle je druhej extrem. To uz snad pomalu radeji toho Cadu, ten ma alespon rozhled, kdyz ne nadhled.
-
Ahoj, doporučili byste $SUBJ? Slyšel jsem na ni smíšené recenze, tak si nejsem jistý, jestli se investice do ní vyplatí. Existuje na českém trhu nějaká vhodná alternativa?
Pokud jde o prezentované myšlenky, tak je IMHO dobrá. Pokud jde o formu, připadá mi poněkud zmatená a nevyvážená a prošpikovaná nadbytečnými subjektivními dojmy. Prostě Čada. :)
Čada je Apple fanatik a jediný slušný jazyk je pro něj ObjC. Správa paměti má být podle něj jen čistě manuální, generika a namespacy jsou na ho**o a navíc se na fórech chová jak hulvát. Podle toho pak vypadá i ta kniha - obsahově extrémně biased a styl dost zmatený a nevyvážený. Vlastně bych ji nedoporučoval ani zadarmo nebo jen jako příklad, jak nepsat.
-
Ondřeje Čadu nebrat, OOP sám moc nerozumí. Bruce Eckel je mnohem lepší a hlavně píše srozumitelněji.
-
Ondřeje Čadu nebrat, OOP sám moc nerozumí. Bruce Eckel je mnohem lepší a hlavně píše srozumitelněji.
Čada je sice velmi svérázný autor, ale pokud o něm někdo tvrdí, že OOP moc nerozumí, tak to bych si spíše vsadil na to, že v OOP plave autor takovéhoto výroku.
Čada je Apple fanatik a jediný slušný jazyk je pro něj ObjC. Správa paměti má být podle něj jen čistě manuální, generika a namespacy jsou na ho**o a navíc se na fórech chová jak hulvát. Podle toho pak vypadá i ta kniha - obsahově extrémně biased a styl dost zmatený a nevyvážený. Vlastně bych ji nedoporučoval ani zadarmo nebo jen jako příklad, jak nepsat.
No jo, když ono to Objective C je opravdu dobrý jazyk a s applími frameworky se opravdu dobře dělá :) (tento příspěvek píšu na svém Lenovu s Debianem, jen tak BTW, abych snad nebyl nějak osočován). A Čadův "fanatismus" částečně i chápu - už začátkem 90. let byl dost ovlivněn NeXTStepem, Smalltalkem, non-IBM hardware... a když vidí, že ten současný mainstream v podstatě ještě dnes nemá kvality toho, na čem se učil tenkrát jako student, tak se není ani čemu divit.
Sám sice nejsem příznivcem čadovského konfrontačního stylu, ale faktem je, že i tak jeho knížky mají informační hodnotu. Vždycky obsahují velice konkrétní informace a názorné příklady a srovnání. Takže to už raději Čadu než nějakého nemastného, neslaného "noname autora", přežvykujícího po milion páté téma "staňte se Java expertem za 30 dnů", přičemž když zalistujete textem, máte pocit, že sám autor se tu Javu učil max. 30 dní před napsáním toho svého dílka.
-
Ondřeje Čadu nebrat, OOP sám moc nerozumí. Bruce Eckel je mnohem lepší a hlavně píše srozumitelněji.
Nevím o které Eckelově knize mluvíš, ale Myslíme v C++ se bez přeskakování nedá číst. Užitečné informace z prvního dílu by se daly shrnout na maximálně pár desítek stránek, zbytek je omáčka. Je to asi dost subjektivní, osobně preferuji zahuštěnější styl. Víc kódu, méně textu.
-
Ondřeje Čadu nebrat, OOP sám moc nerozumí. Bruce Eckel je mnohem lepší a hlavně píše srozumitelněji.
Nevím o které Eckelově knize mluvíš, ale Myslíme v C++ se bez přeskakování nedá číst. Užitečné informace z prvního dílu by se daly shrnout na maximálně pár desítek stránek, zbytek je omáčka. Je to asi dost subjektivní, osobně preferuji zahuštěnější styl. Víc kódu, méně textu.
Mám na mysli knihu "Thinking in Java", která se dá číst i bez přeskakování, Hlavně se na začátku věnuje rozboru OOP, což Čada nedělá.
-
Ondřeje Čadu nebrat, OOP sám moc nerozumí. Bruce Eckel je mnohem lepší a hlavně píše srozumitelněji.
Čada je sice velmi svérázný autor, ale pokud o něm někdo tvrdí, že OOP moc nerozumí, tak to bych si spíše vsadil na to, že v OOP plave autor takovéhoto výroku.
Čada je Apple fanatik a jediný slušný jazyk je pro něj ObjC. Správa paměti má být podle něj jen čistě manuální, generika a namespacy jsou na ho**o a navíc se na fórech chová jak hulvát. Podle toho pak vypadá i ta kniha - obsahově extrémně biased a styl dost zmatený a nevyvážený. Vlastně bych ji nedoporučoval ani zadarmo nebo jen jako příklad, jak nepsat.
No jo, když ono to Objective C je opravdu dobrý jazyk a s applími frameworky se opravdu dobře dělá :) (tento příspěvek píšu na svém Lenovu s Debianem, jen tak BTW, abych snad nebyl nějak osočován). A Čadův "fanatismus" částečně i chápu - už začátkem 90. let byl dost ovlivněn NeXTStepem, Smalltalkem, non-IBM hardware... a když vidí, že ten současný mainstream v podstatě ještě dnes nemá kvality toho, na čem se učil tenkrát jako student, tak se není ani čemu divit.
Sám sice nejsem příznivcem čadovského konfrontačního stylu, ale faktem je, že i tak jeho knížky mají informační hodnotu. Vždycky obsahují velice konkrétní informace a názorné příklady a srovnání. Takže to už raději Čadu než nějakého nemastného, neslaného "noname autora", přežvykujícího po milion páté téma "staňte se Java expertem za 30 dnů", přičemž když zalistujete textem, máte pocit, že sám autor se tu Javu učil max. 30 dní před napsáním toho svého dílka.
Ano, ObjC je super a předstihlo svoji dobu (a ovlivnilo dost jazyků včetně Javy), ale není to jediný použitelný jazyk a hlavně je nebetyčná debilita tvrdit, že namespacy a generika jsou na nic (to druhé už ObjC má a Čada stejně tvrdí, že jsou na p**u). Navíc je jak korouhvička, kdysi zaníceně obhajoval Javu (contra Virius) a teď ji kritizuje, kudy chodí. Až by člověk řekl, že má nějaký psychický problém.
-
... a hlavně je nebetyčná debilita tvrdit, že namespacy a generika jsou na nic...
Bez namespaces bychom nemohli mít jednoslovní názvy tříd. To by mi chybělo víc než generika.
-
Ano, ObjC je super a předstihlo svoji dobu (a ovlivnilo dost jazyků včetně Javy), ale není to jediný použitelný jazyk a hlavně je nebetyčná debilita tvrdit, že namespacy a generika jsou na nic (to druhé už ObjC má a Čada stejně tvrdí, že jsou na p**u). Navíc je jak korouhvička, kdysi zaníceně obhajoval Javu (contra Virius) a teď ji kritizuje, kudy chodí. Až by člověk řekl, že má nějaký psychický problém.
Neřekl bych, že protežuje jen ObjC. Ale i další jazyky, které se mu nějak podobají :) Neobhajoval on náhodou Javu proti C++? To by totiž smysl dávalo a dokonce by měl i pravdu. Ty jejich veřejné spory (Čada vs. Virius) byly pro čtenáře aspoň docela zajímavé. Přestože Viriuse znám osobně ještě ze svých studentských let a i jeho styl psaní mi vždycky vyhovoval více, názorově je mi o něco bližší Čada.
A z českých autorů okolo OOP bych nezapomínal ještě na Vojtěcha Merunku. Myslím, že by mohl zapadat do té tazatelovy "vhodné alternativy" k Čadovi.
Ovšem oba jsou představitelé té školy "velmi pozdně vazebního OOP", která se v jazycích jako Java či C++ realizuje těžko.
-
Ano, ObjC je super a předstihlo svoji dobu (a ovlivnilo dost jazyků včetně Javy), ale není to jediný použitelný jazyk a hlavně je nebetyčná debilita tvrdit, že namespacy a generika jsou na nic (to druhé už ObjC má a Čada stejně tvrdí, že jsou na p**u). Navíc je jak korouhvička, kdysi zaníceně obhajoval Javu (contra Virius) a teď ji kritizuje, kudy chodí. Až by člověk řekl, že má nějaký psychický problém.
Neřekl bych, že protežuje jen ObjC. Ale i další jazyky, které se mu nějak podobají :) Neobhajoval on náhodou Javu proti C++? To by totiž smysl dávalo a dokonce by měl i pravdu. Ty jejich veřejné spory (Čada vs. Virius) byly pro čtenáře aspoň docela zajímavé. Přestože Viriuse znám osobně ještě ze svých studentských let a i jeho styl psaní mi vždycky vyhovoval více, názorově je mi o něco bližší Čada.
A z českých autorů okolo OOP bych nezapomínal ještě na Vojtěcha Merunku. Myslím, že by mohl zapadat do té tazatelovy "vhodné alternativy" k Čadovi.
Ovšem oba jsou představitelé té školy "velmi pozdně vazebního OOP", která se v jazycích jako Java či C++ realizuje těžko.
Java tu velmi pozdní vazbu má. Ale třeba Swift ne, proto na něj Čada dští síru. Jinak dynamické typování a ta vazba jsou fajn, ovšem nejlépe v kombinaci s kontrolou typů, automatickou správou paměti (ARC) a generickými typy. Ostatně ObjC to všechno má. Jen ty namespacy chybí, ale dá se bez nich žít.
-
Java tu velmi pozdní vazbu má. Ale třeba Swift ne, proto na něj Čada dští síru
Kde? Zběžně jsem googlil a nenašel. Docela rad bych na to kouknul...
-
Java tu velmi pozdní vazbu má. Ale třeba Swift ne, proto na něj Čada dští síru
Kde? Zběžně jsem googlil a nenašel. Docela rad bych na to kouknul...
https://docs.oracle.com/javase/7/docs/api/java/lang/reflect/Proxy.html?is-external=true
-
Java tu velmi pozdní vazbu má. Ale třeba Swift ne, proto na něj Čada dští síru
Kde? Zběžně jsem googlil a nenašel. Docela rad bych na to kouknul...
https://docs.oracle.com/javase/7/docs/api/java/lang/reflect/Proxy.html?is-external=true
Ah, tak tohle ve svem veku vazne nepotrebuju :-D
Myslel jsem, kde OCS kritizuje Swift.
-
Ondřeje Čadu nebrat, OOP sám moc nerozumí. Bruce Eckel je mnohem lepší a hlavně píše srozumitelněji.
Nevím o které Eckelově knize mluvíš, ale Myslíme v C++ se bez přeskakování nedá číst. Užitečné informace z prvního dílu by se daly shrnout na maximálně pár desítek stránek, zbytek je omáčka. Je to asi dost subjektivní, osobně preferuji zahuštěnější styl. Víc kódu, méně textu.
Mám na mysli knihu "Thinking in Java", která se dá číst i bez přeskakování, Hlavně se na začátku věnuje rozboru OOP, což Čada nedělá.
Rozborů je v jeho knihách na můj vkus až moc. Styl je dost podobný zbojovým příspěvkům. Hodně okecávání a informační hodnota 0.
-
Priznam se ze tu knihu od Cady jsem necet, kdysi jsem si ale vypujcil knihu od Pecinovskeho z knihovny a tu jsem po cca 1 hodine zavrel. Ted jsem zbezne prosel http://i.iinfo.cz/r2/k/Jak_efektivne_ucit_OOP.pdf a musim rict ze v nekterych pripadech to dava smysl, nebo myslite ze by se to melo ucit jeste jinak?
-
Java tu velmi pozdní vazbu má. Ale třeba Swift ne, proto na něj Čada dští síru
Kde? Zběžně jsem googlil a nenašel. Docela rad bych na to kouknul...
https://docs.oracle.com/javase/7/docs/api/java/lang/reflect/Proxy.html?is-external=true
Ah, tak tohle ve svem veku vazne nepotrebuju :-D
Myslel jsem, kde OCS kritizuje Swift.
Aha. Na Okounovi ve vláknu o ObjC.
-
Priznam se ze tu knihu od Cady jsem necet, kdysi jsem si ale vypujcil knihu od Pecinovskeho z knihovny a tu jsem po cca 1 hodine zavrel. Ted jsem zbezne prosel http://i.iinfo.cz/r2/k/Jak_efektivne_ucit_OOP.pdf a musim rict ze v nekterych pripadech to dava smysl, nebo myslite ze by se to melo ucit jeste jinak?
Smysl to dává, ale ďábel je v detailech.
-
Přečetl jsem docela dost knih o programování i OOP. Buhžel musím říci, že v podstatě žádná k ničrmu nebyla. Nejvíce mi dala asi kniha Clean Code od Martina Roberta.
Otázkou je, jestli se OOP vůbec učit. On je to trochu zvrácený způsob myšlení a ne zrovna dobrý. Myslím si, že funkcionální programávání je mnohem lepší, ikdyž všichni propagují OOP.
-
Přečetl jsem docela dost knih o programování i OOP. Buhžel musím říci, že v podstatě žádná k ničrmu nebyla. Nejvíce mi dala asi kniha Clean Code od Martina Roberta.
Otázkou je, jestli se OOP vůbec učit. On je to trochu zvrácený způsob myšlení a ne zrovna dobrý. Myslím si, že funkcionální programávání je mnohem lepší, ikdyž všichni propagují OOP.
To původní dynamické OOP je zajímavé a některé jazyky ho dnes částečně implementují (bývá to směska). FP je pochopitelně taky užitečné, když se to nepřehání, jenže je intelektuálně náročnější na pochopení, takže se hůř učí a méně používá. Vot problěma...
-
Přečetl jsem docela dost knih o programování i OOP. Buhžel musím říci, že v podstatě žádná k ničrmu nebyla. Nejvíce mi dala asi kniha Clean Code od Martina Roberta.
Otázkou je, jestli se OOP vůbec učit. On je to trochu zvrácený způsob myšlení a ne zrovna dobrý. Myslím si, že funkcionální programávání je mnohem lepší, ikdyž všichni propagují OOP.
Kniha Clean Code od Roberta C. Martina je skutečně skvělá.
OOP není vůbec zvrácené. Pro ty, kteří ho zcela nepochopili, bývá často výhodnější FP, neboť v něm nemohou dělat chyby, kterých se dopouštěli v OOP.
-
Priznam se ze tu knihu od Cady jsem necet, kdysi jsem si ale vypujcil knihu od Pecinovskeho z knihovny a tu jsem po cca 1 hodine zavrel. Ted jsem zbezne prosel http://i.iinfo.cz/r2/k/Jak_efektivne_ucit_OOP.pdf a musim rict ze v nekterych pripadech to dava smysl, nebo myslite ze by se to melo ucit jeste jinak?
Většina učebních textů a kurzů programování však tuto skutečnost nebere v úvahu a je nadále koncipována přede-vším jako kurzy, ve kterých se jejich čtenáři, resp. frekventanti učí především syntaxi použitého jazyka. Opravdu objektový přístup k vývoji programu se proto studenti učí až v nadstav-bových kurzech, kdy ale již mají zažitu řadu zlozvyků, které se musejí postupně odnaučovat.
Myslím si pravý opak. Postupovat se má od konkrétního k obecnému. Nejdřív se pořádně naučit syntax alespoň jednoho jazyka. Až potom řešit nějaká paradigmata. Přeskakování základů produkuje polovzdělance jako zboj.
-
Přečetl jsem docela dost knih o programování i OOP. Buhžel musím říci, že v podstatě žádná k ničrmu nebyla. Nejvíce mi dala asi kniha Clean Code od Martina Roberta.
Otázkou je, jestli se OOP vůbec učit. On je to trochu zvrácený způsob myšlení a ne zrovna dobrý. Myslím si, že funkcionální programávání je mnohem lepší, ikdyž všichni propagují OOP.
To původní dynamické OOP je zajímavé a některé jazyky ho dnes částečně implementují (bývá to směska). FP je pochopitelně taky užitečné, když se to nepřehání, jenže je intelektuálně náročnější na pochopení, takže se hůř učí a méně používá. Vot problěma...
(uetoyo, někdy haha)
Proč si myslíte, že je FP náročnější? Pokud je to pure jazyk s naprosto matematickým slovníkem jako Haskell, tak možná ze začátku, ale třeba jazyky jako F# nebo OCaml jsou docela přátelské už od prvního setkání. Spíš vás podezřívám z toho, že si přejete, aby to bylo těžké. Nedávno jsme se tu bavili o Milewskim, který umí spoustu věcí skvěle vysvětlit. To že to neumíte vysvětlit vy, neznamená, že je to těžké na pochopení. Třeba v OOP hodně rychle narazíte jestli Message má zpracovat samu sebe, nebo tam je třeba domodelovat objekt Sender, nebo dokonce Receiver ... to mi přijde těžké, ne napsat funkci, co zpracuje message.
-
Přečetl jsem docela dost knih o programování i OOP. Buhžel musím říci, že v podstatě žádná k ničrmu nebyla. Nejvíce mi dala asi kniha Clean Code od Martina Roberta.
Otázkou je, jestli se OOP vůbec učit. On je to trochu zvrácený způsob myšlení a ne zrovna dobrý. Myslím si, že funkcionální programávání je mnohem lepší, ikdyž všichni propagují OOP.
To původní dynamické OOP je zajímavé a některé jazyky ho dnes částečně implementují (bývá to směska). FP je pochopitelně taky užitečné, když se to nepřehání, jenže je intelektuálně náročnější na pochopení, takže se hůř učí a méně používá. Vot problěma...
(uetoyo, někdy haha)
Proč si myslíte, že je FP náročnější? Pokud je to pure jazyk s naprosto matematickým slovníkem jako Haskell, tak možná ze začátku, ale třeba jazyky jako F# nebo OCaml jsou docela přátelské už od prvního setkání. Spíš vás podezřívám z toho, že si přejete, aby to bylo těžké. Nedávno jsme se tu bavili o Milewskim, který umí spoustu věcí skvěle vysvětlit. To že to neumíte vysvětlit vy, neznamená, že je to těžké na pochopení. Třeba v OOP hodně rychle narazíte jestli Message má zpracovat samu sebe, nebo tam je třeba domodelovat objekt Sender, nebo dokonce Receiver ... to mi přijde těžké, ne napsat funkci, co zpracuje message.
Pochopení FP do hloubky vyžaduje detailní znalost teorie kategorií. Kdo pochopí všechny texty na blogu Milewského, může si říkat Pan Programátor. Obávám se, že ne každý toho je schopen. Ovšem ne každý to potřebuje, takže se není o čem hádat.
-
Většina učebních textů a kurzů programování však tuto skutečnost nebere v úvahu a je nadále koncipována přede-vším jako kurzy, ve kterých se jejich čtenáři, resp. frekventanti učí především syntaxi použitého jazyka. Opravdu objektový přístup k vývoji programu se proto studenti učí až v nadstav-bových kurzech, kdy ale již mají zažitu řadu zlozvyků, které se musejí postupně odnaučovat.
Myslím si pravý opak. Postupovat se má od konkrétního k obecnému. Nejdřív se pořádně naučit syntax alespoň jednoho jazyka. Až potom řešit nějaká paradigmata. Přeskakování základů produkuje polovzdělance jako zboj.
Teď jde o to, co je zde vlastně to konkrétní a co to obecné. Aby to nevedlo k jevu, jenž znám ze základní a střední školy, kdy převážně dívčí část žactva na hodinách cizích jazyků psala písemky, v nichž se zkoušela znalost gramatiky, pravopisu a syntaxe, na jedničky, ale tváří v tvář cizinci byly naprosto nepoužitelné, zatímco my, trojkaři, jsme na žádný nepřekonatelný problém při konverzaci nenarazili, přestože jsme se v písemkách z všelijakých těch předbudoucích průběhových časů plácali jak velryby na pláži.
Mně při výuce vyhovuje spíše ten postup, kdy se co nejrychleji vybuduje alespoň hrubá stavba od základů po střechu, která se pak postupně doplňuje o další prvky. Třeba při přednáškách z matematiky na VŠ mě dost demotivovalo, že jsem se musel učit něco, čehož smysl mi v tu chvíli ještě unikal, takže nebylo jasné, k čemu to vlastně bude dobré a co z toho, co se učím, je to podstatné. Teprve když to člověk viděl v souvislostech a v aplikacích, tak mu to začalo dávat smysl a začalo být jasné, proč jsou ty věci definované zrovna tak, jak jsou, a ne jinak, a proč se u nich zkoumají zrovna ty vlastnosti, jaké se zkoumají. Kdyby bývali místo striktního postupu zdola nahoru přednášeli tím iteračním, postupně zpřesňujícím stylem, bylo by mi studium mnohem příjemnější a přínosnější.
Takto jsme se např. na algebře nejdříve učili o lineárních funkcionálech, pak o hermitovských formách, pak o kvadratických formách, pak o skalárním součinu ("forma, která splňuje 1)..., 2)..., 3)... 4)... se nazývá skalární součin..."), pak tam byla jakási definice typu "skalární součin (x, ei), kde ei je z báze, se nazývá i-tý Fourierův koeficient..." a teprve o dva roky později na funkcionální analýze člověku docvaklo, proč se to tenkrát v prváku zavedlo takto a že ten Fourierův koeficient z lineární algebry opravdu nějak souvisí s Fourierovými řadami z matematické analýzy.
-
Většina učebních textů a kurzů programování však tuto skutečnost nebere v úvahu a je nadále koncipována přede-vším jako kurzy, ve kterých se jejich čtenáři, resp. frekventanti učí především syntaxi použitého jazyka. Opravdu objektový přístup k vývoji programu se proto studenti učí až v nadstav-bových kurzech, kdy ale již mají zažitu řadu zlozvyků, které se musejí postupně odnaučovat.
Myslím si pravý opak. Postupovat se má od konkrétního k obecnému. Nejdřív se pořádně naučit syntax alespoň jednoho jazyka. Až potom řešit nějaká paradigmata. Přeskakování základů produkuje polovzdělance jako zboj.
Teď jde o to, co je zde vlastně to konkrétní a co to obecné. Aby to nevedlo k jevu, jenž znám ze základní a střední školy, kdy převážně dívčí část žactva na hodinách cizích jazyků psala písemky, v nichž se zkoušela znalost gramatiky, pravopisu a syntaxe, na jedničky, ale tváří v tvář cizinci byly naprosto nepoužitelné, zatímco my, trojkaři, jsme na žádný nepřekonatelný problém při konverzaci nenarazili, přestože jsme se v písemkách z všelijakých těch předbudoucích průběhových časů plácali jak velryby na pláži.
Mně při výuce vyhovuje spíše ten postup, kdy se co nejrychleji vybuduje alespoň hrubá stavba od základů po střechu, která se pak postupně doplňuje o další prvky. Třeba při přednáškách z matematiky na VŠ mě dost demotivovalo, že jsem se musel učit něco, čehož smysl mi v tu chvíli ještě unikal, takže nebylo jasné, k čemu to vlastně bude dobré a co z toho, co se učím, je to podstatné. Teprve když to člověk viděl v souvislostech a v aplikacích, tak mu to začalo dávat smysl a začalo být jasné, proč jsou ty věci definované zrovna tak, jak jsou, a ne jinak, a proč se u nich zkoumají zrovna ty vlastnosti, jaké se zkoumají. Kdyby bývali místo striktního postupu zdola nahoru přednášeli tím iteračním, postupně zpřesňujícím stylem, bylo by mi studium mnohem příjemnější a přínosnější.
Takto jsme se např. na algebře nejdříve učili o lineárních funkcionálech, pak o hermitovských formách, pak o kvadratických formách, pak o skalárním součinu ("forma, která splňuje 1)..., 2)..., 3)... 4)... se nazývá skalární součin..."), pak tam byla jakási definice typu "skalární součin (x, ei), kde ei je z báze, se nazývá i-tý Fourierův koeficient..." a teprve o dva roky později na funkcionální analýze člověku docvaklo, proč se to tenkrát v prváku zavedlo takto a že ten Fourierův koeficient z lineární algebry opravdu nějak souvisí s Fourierovými řadami z matematické analýzy.
To je částečně tím, že skok z matiky na úrovni SŠ na VŠ je dost strmý. Obecně je ale pravda, že by se mělo postupovat od praktického (příkladů) k abstraktnímu, zvlášť u algebry apod., kde je míra abstrakce značná. Na druhou stranu někomu dělá problém i trojčlenka, tam pak žádný Komenský nepomůže.
-
Většina učebních textů a kurzů programování však tuto skutečnost nebere v úvahu a je nadále koncipována přede-vším jako kurzy, ve kterých se jejich čtenáři, resp. frekventanti učí především syntaxi použitého jazyka. Opravdu objektový přístup k vývoji programu se proto studenti učí až v nadstav-bových kurzech, kdy ale již mají zažitu řadu zlozvyků, které se musejí postupně odnaučovat.
Myslím si pravý opak. Postupovat se má od konkrétního k obecnému. Nejdřív se pořádně naučit syntax alespoň jednoho jazyka. Až potom řešit nějaká paradigmata. Přeskakování základů produkuje polovzdělance jako zboj.
Teď jde o to, co je zde vlastně to konkrétní a co to obecné. Aby to nevedlo k jevu, jenž znám ze základní a střední školy, kdy převážně dívčí část žactva na hodinách cizích jazyků psala písemky, v nichž se zkoušela znalost gramatiky, pravopisu a syntaxe, na jedničky, ale tváří v tvář cizinci byly naprosto nepoužitelné, zatímco my, trojkaři, jsme na žádný nepřekonatelný problém při konverzaci nenarazili, přestože jsme se v písemkách z všelijakých těch předbudoucích průběhových časů plácali jak velryby na pláži.
Mně při výuce vyhovuje spíše ten postup, kdy se co nejrychleji vybuduje alespoň hrubá stavba od základů po střechu, která se pak postupně doplňuje o další prvky. Třeba při přednáškách z matematiky na VŠ mě dost demotivovalo, že jsem se musel učit něco, čehož smysl mi v tu chvíli ještě unikal, takže nebylo jasné, k čemu to vlastně bude dobré a co z toho, co se učím, je to podstatné. Teprve když to člověk viděl v souvislostech a v aplikacích, tak mu to začalo dávat smysl a začalo být jasné, proč jsou ty věci definované zrovna tak, jak jsou, a ne jinak, a proč se u nich zkoumají zrovna ty vlastnosti, jaké se zkoumají. Kdyby bývali místo striktního postupu zdola nahoru přednášeli tím iteračním, postupně zpřesňujícím stylem, bylo by mi studium mnohem příjemnější a přínosnější.
Takto jsme se např. na algebře nejdříve učili o lineárních funkcionálech, pak o hermitovských formách, pak o kvadratických formách, pak o skalárním součinu ("forma, která splňuje 1)..., 2)..., 3)... 4)... se nazývá skalární součin..."), pak tam byla jakási definice typu "skalární součin (x, ei), kde ei je z báze, se nazývá i-tý Fourierův koeficient..." a teprve o dva roky později na funkcionální analýze člověku docvaklo, proč se to tenkrát v prváku zavedlo takto a že ten Fourierův koeficient z lineární algebry opravdu nějak souvisí s Fourierovými řadami z matematické analýzy.
Tím konkrétním jsem myslel právě praktickou znalost a schopnost řešit konkrétní úlohy.
Začínat s OOP bez znalosti základních konstrukcí v konkrétním jazyce mi přijde jako kdybyste v matematické analýze přeskočil reálná čísla a začal rovnou metrickými prostory. Když mají "znalci OOP" natvrdo vyřešit nějakou úlohu. Například na hackerrank. Většinou těžce pohoří.
Se studiem jazyků bez studia gramatiky také úplně nesouhlasím. Pouhým používáním se sice naučíte komunikovat, ale nikdy se nezbavíte gramatických chyb. Gramatiku musí studovat i rodilí mluvčí.
-
(..) převážně dívčí část žactva na hodinách cizích jazyků psala písemky, v nichž se zkoušela znalost gramatiky, pravopisu a syntaxe, na jedničky, ale tváří v tvář cizinci byly naprosto nepoužitelné, zatímco my, trojkaři, jsme na žádný nepřekonatelný problém při konverzaci nenarazili, (..)
Zato divkam-trojkarkam jde vetsinou konverzace s cizinci na jednicku ;-)
Nicmene Cada je bohuzel priklad kdysi asi velmi chytryho cloveka, kterej se uplne zblaznil. Jeho doporucenim bych dnes prikladal vahu nulovou az nepatrne zapornou.
(Presto jsem samozrejme rad treba na jeho davny serial o NeXTSTEPu v SWN apod., to mi pomohlo sledovat zajimave smery, stejne jako napr. special o UNIXu na konci 1991 v temze casopise. Bez toho a bez Elzetova Bajtu bych se jako clovek mimo EARN i FIDO o Linuxu a o tom, ze neco UNIXoveho chci, asi dozvedel vyrazne pozdeji.)
-
(..) převážně dívčí část žactva na hodinách cizích jazyků psala písemky, v nichž se zkoušela znalost gramatiky, pravopisu a syntaxe, na jedničky, ale tváří v tvář cizinci byly naprosto nepoužitelné, zatímco my, trojkaři, jsme na žádný nepřekonatelný problém při konverzaci nenarazili, (..)
Nicmene Cada je bohuzel priklad kdysi asi velmi chytryho cloveka, kterej se uplne zblaznil. Jeho doporucenim bych dnes prikladal vahu nulovou az nepatrne zapornou.
Stává se, no.
-
Začínat s OOP bez znalosti základních konstrukcí v konkrétním jazyce mi přijde jako kdybyste v matematické analýze přeskočil reálná čísla a začal rovnou metrickými prostory. Když mají "znalci OOP" natvrdo vyřešit nějakou úlohu. Například na hackerrank. Většinou těžce pohoří.
Bohužel se mnozí lektoři snaží do těch "základních konstrukcí" nacpat všechny konstrukce daného jazyka. Tedy nejen ty, které jsou potřebné pro splnění objektového úkolu. K objektům se tak často ani nedostanou a třeba k namespaces už vůbec ne. Jiní naopak s namespaces začínají jako s nezbytností, což také nevidím jako správné.
-
Můžu se jen zeptat, co je na Pecinovského knihách o Javě špatného? Chtěl jsem si ty 2 díly pořídit, ale teď si nejsem jist, zda by to byla dobrá volba.
-
Můžu se jen zeptat, co je na Pecinovského knihách o Javě špatného? Chtěl jsem si ty 2 díly pořídit, ale teď si nejsem jist, zda by to byla dobrá volba.
Nic, jsou to dobré knížky.
-
Můžu se jen zeptat, co je na Pecinovského knihách o Javě špatného? Chtěl jsem si ty 2 díly pořídit, ale teď si nejsem jist, zda by to byla dobrá volba.
Koupil jsem si kdysi jeho Návrhové vzory a odložil po dvou stránkách. Styl je infantilní, čekal jsem, kdy si tam udělají kafe.
-
Můžu se jen zeptat, co je na Pecinovského knihách o Javě špatného? Chtěl jsem si ty 2 díly pořídit, ale teď si nejsem jist, zda by to byla dobrá volba.
Obecně je moc svůj. To není nic špatného, ale představ si třeba Kita. Programovat sice neumí, ale vše řeší dost svérázně. Pecinovský je na tom stejně. Lepší tím vůbec neztrácet čas, protože budeš hodiny řešit, proč vymýšlí píčoviny a zároveň proč i příklady v knihách jsou nefunkční.
Jestli ale máš rád na vývoj NB, Vim a preferuješ 10" displej, tak je to stejně jedno a nic horšího se ti s tou knihou už nestane.
-
Já myslim, že nejduležitější je pochopit jak se vlastně k OOP došlo a co je nad ním a nezastavit se u oop ale mít schopnost používat to je co před oop i to co je dál za oop - a je toho hodně. To znamená dohledat éru časopisu Bajt, kde jsou popsány techniky těsně před zavedením OOP do C++. Jak se to dělalo. Samozřejmě objektový model je znám už od prvních procesorů. Byly i návrhy objektových procesorů. Normálně se k OOP dostaneš asi po 1500-1700 hodinách výuky programování sám od sebe. To znamená cca po 12-18 měsících práce. A je jedno jestli začínáš v Basicu, Fortranu, C nebo čemkoliv jiným. Ono tě to prostě donutí OOP používat a pak jít dál k Template a Generikám v OOP ale to je všechno úroveň co se učila na vš někde v polovině 90 let.
-
Aha. Na Okounovi ve vláknu o ObjC.
Na rybe uz jsem nebyl leta. Nekdy nostalgicky kouknu...
-
Nevim, jestli spamovat vlakno o necem uplne jinem, ale kdyz uz jste s tim zacali... A koneckoncu je to mistni kolorit, tak snad v poho ;)
Pochopení FP do hloubky vyžaduje detailní znalost teorie kategorií. [...] Ovšem ne každý to potřebuje, takže se není o čem hádat.
To tvrzeni mi prijde vylozene zhoubne. Protoze uplne zbytecne od FP odrazuje lidi, kteri ho ani nezkusili, popr. ty, kdo ho zkusili a po prvnim zamotani se rychle skoncili, utvrdi v tom, ze udelali dobre. A pritom je dost zavadejici, kdyz uz nechci rict vylozene nepravdive.
V "pragmatickych" FP jazycich, kde jsou povolene side effects (vychazejici ze Standard ML nebo Lispu), je TK vicemene uplne nadbytecna. V pure jazycich typu Haskell se muze hodit na to, ze se na ty konstrukce v jazyce muzu podivat z obecnejsiho pohledu, z jineho uhlu, pochopit, proc je to udelane tak, jak je to udelane. Muze mi to dodat nejaky nadhled apod., ale k praktickemu, skutecnemu, programovani to neni potreba vubec. Uplne bohate staci se naucit to, co v tom jazyce je: ze Functor je typeclass s nejakymi funkcemi a ma splnovat nejake axiomy. Proc, to mi muze byt z praktickeho hlediska uplne putna. Pro nekoho je zabava to zjistit a rozsirit si obzory, ale potreba to neni.
Tak zbytecne nestras lidi! ;)
P.S. pokud by nekdo jo chtel, urcite by pomoci TK slo popsat i OOP - a tvrzeni "k programovani v OOP musite znat TK" by se pak ukazalo ve sve nahote :)
-
pokud by nekdo jo chtel, urcite by pomoci TK slo popsat i OOP
To se dělá, odkud myslíš, že se vzaly pojmy kovariantní a kontravariantní u generik? Právě z TK, a pak se tam pracuje s bifunktory, sliced functors etc. ;)
-
To se dělá, odkud myslíš, že se vzaly pojmy kovariantní a kontravariantní u generik? Právě z TK, a pak se tam pracuje s bifunktory, sliced functors etc. ;)
No vidis - a OOPckarum to necpes ;)
-
To se dělá, odkud myslíš, že se vzaly pojmy kovariantní a kontravariantní u generik? Právě z TK, a pak se tam pracuje s bifunktory, sliced functors etc. ;)
No vidis - a OOPckarum to necpes ;)
Předpokládám, že to znají ;)
-
P.S. Nikdo tu netvrdí, že všichni musí vědět, jak se TK používá ve FP. Zedník taky nepočítá diferenciální rovnice, když má postavit zeď, a je to OK, když zná své místo. Pokud ale někdo píše třeba knihovny pro Haskell, tak by asi měl tušit, vo co go ;)
-
P.S. Nikdo tu netvrdí, že všichni musí vědět, jak se TK používá ve FP. Zedník taky nepočítá diferenciální rovnice, když má postavit zeď, a je to OK, když zná své místo. Pokud ale někdo píše třeba knihovny pro Haskell, tak by asi měl tušit, vo co go ;)
Že ty těm blábolům fakt věříš? Pokud zedník umí skvěle stavět zdi, tak může klidně dělat "knihovny" na stavění zdí. Stejně jako Haskell vývojář k ničemu TK nepotřebuje. Vlastně pokud by byl jako ty, tak by to měl na fóra, kde mu to lopaty budou žrát. V reálu to ale využítí nemá, protože buď programovat umíš a nebo ne. Teorie tam žádné zázračné vylepšení neudělá.
-
Předpokládám, že to znají ;)
https://youtu.be/ienp4J3pW7U?t=3m44s
-
Ahoj, doporučili byste $SUBJ? Slyšel jsem na ni smíšené recenze, tak si nejsem jistý, jestli se investice do ní vyplatí. Existuje na českém trhu nějaká vhodná alternativa?
Investicia? :) Ved ekniha stoji iba 10,50 EUR. Za to raz nepojdes na pivo..
Tuto knihu sice nepoznam, ale mal som v rukach asi podobny titul:
http://knihy.cpress.cz/oop-objektove-orientovane-programovani-bez-predchozich-znalosti.html
Podla mna kniha kde sa s OOP nejako teoretizuje a demonstruje sa na viacerych jazykoch s pochopenim moc nepomoze.
Asi je najlepsie kupit si nejaku knihu o Jave. Tam sa spravidla OOP vysvetluje dobre.
Napriklad teraz je k dispozicii standardne dobra kniha Herbert Schildt: Java
http://www.albatrosmedia.sk/java-8.html
Z povodnych ceskych knih bola velmi dobra kniha Virius: Java pro zelenace.
http://www.martinus.sk/?uItem=23361
Mnohe veci v nej su velmi dobre vysvetlene.
-
Ahoj, doporučili byste $SUBJ? Slyšel jsem na ni smíšené recenze, tak si nejsem jistý, jestli se investice do ní vyplatí. Existuje na českém trhu nějaká vhodná alternativa?
Investicia? :) Ved ekniha stoji iba 10,50 EUR. Za to raz nepojdes na pivo..
Pokud je ta kniha špatná, je i zadarmo drahá.
Tuto knihu sice nepoznam, ale mal som v rukach asi podobny titul:
http://knihy.cpress.cz/oop-objektove-orientovane-programovani-bez-predchozich-znalosti.html
O té jsem slyšel, že autor ji psal bez předchozích znalostí.
-
Můžu se jen zeptat, co je na Pecinovského knihách o Javě špatného? Chtěl jsem si ty 2 díly pořídit, ale teď si nejsem jist, zda by to byla dobrá volba.
Mozno nie su spatne ale mne sa to nepodarilo stravit. Pisane nestandardnym sposobom - formou dialogov a este k tomu sa tam pouzivalo prostredie BlueJ. Mozno zaujimavy experiment pre tych co nikdy neprogramovali, ale mne sa to zdalo moc roztahane.
.
-
Forma dialogu je zrovna luxusní přístup. To je na té knize ještě to nejlepší.
-
P.S. Nikdo tu netvrdí, že všichni musí vědět, jak se TK používá ve FP. Zedník taky nepočítá diferenciální rovnice, když má postavit zeď, a je to OK, když zná své místo. Pokud ale někdo píše třeba knihovny pro Haskell, tak by asi měl tušit, vo co go ;)
Že ty těm blábolům fakt věříš? Pokud zedník umí skvěle stavět zdi, tak může klidně dělat "knihovny" na stavění zdí. Stejně jako Haskell vývojář k ničemu TK nepotřebuje. Vlastně pokud by byl jako ty, tak by to měl na fóra, kde mu to lopaty budou žrát. V reálu to ale využítí nemá, protože buď programovat umíš a nebo ne. Teorie tam žádné zázračné vylepšení neudělá.
Zedník umí stavět zdi, ale pouze ve známém prostředí. Nespočítá si už například vliv náhrady materiálu izolace na tepelné ztráty zdi. Proto jeho zeď bude například dražší, než by mohla být s jiným materiálem. Tedy bude méně efektivní. Proto se ty rovnice pro vedení tepla vyplatí znát. A s TK je to podobné. Mimo to, že je mimořádně zajímavá.
-
P.S. Nikdo tu netvrdí, že všichni musí vědět, jak se TK používá ve FP. Zedník taky nepočítá diferenciální rovnice, když má postavit zeď, a je to OK, když zná své místo. Pokud ale někdo píše třeba knihovny pro Haskell, tak by asi měl tušit, vo co go ;)
Že ty těm blábolům fakt věříš? Pokud zedník umí skvěle stavět zdi, tak může klidně dělat "knihovny" na stavění zdí. Stejně jako Haskell vývojář k ničemu TK nepotřebuje. Vlastně pokud by byl jako ty, tak by to měl na fóra, kde mu to lopaty budou žrát. V reálu to ale využítí nemá, protože buď programovat umíš a nebo ne. Teorie tam žádné zázračné vylepšení neudělá.
Zedník umí stavět zdi, ale pouze ve známém prostředí. Nespočítá si už například vliv náhrady materiálu izolace na tepelné ztráty zdi. Proto jeho zeď bude například dražší, než by mohla být s jiným materiálem. Tedy bude méně efektivní. Proto se ty rovnice pro vedení tepla vyplatí znát. A s TK je to podobné. Mimo to, že je mimořádně zajímavá.
Zajímavá a relativně jednoduchá v porovnání třeba s teorií množin.
-
Zedník umí stavět zdi, ale pouze ve známém prostředí. Nespočítá si už například vliv náhrady materiálu izolace na tepelné ztráty zdi.
Zedník nemá nic počítat. Zedník má postavit zeď tak, jak je to v projektu. A s běžným programátorem je to dost často stejně - přílišná invence, která není na místě, k ničemu dobrému nevede. Imho není ani tak důležité znát všechno, důležitější je znát svoje limity a nepouštět se do věcí, na který nemám.
-
Zedník umí stavět zdi, ale pouze ve známém prostředí. Nespočítá si už například vliv náhrady materiálu izolace na tepelné ztráty zdi.
Zedník nemá nic počítat. Zedník má postavit zeď tak, jak je to v projektu. A s běžným programátorem je to dost často stejně - přílišná invence, která není na místě, k ničemu dobrému nevede. Imho není ani tak důležité znát všechno, důležitější je znát svoje limity a nepouštět se do věcí, na který nemám.
Programování bývalo spíše uměním, dnes je inženýrskou činností, ještě dlouho to nebude jen stavění zdi. Je to řemeslo, ne výroba. A každé řemeslo má v sobě tvůrčí složku, nikdy to není jen prostá reprodukce.
-
Zedník umí stavět zdi, ale pouze ve známém prostředí. Nespočítá si už například vliv náhrady materiálu izolace na tepelné ztráty zdi.
Zedník nemá nic počítat. Zedník má postavit zeď tak, jak je to v projektu. A s běžným programátorem je to dost často stejně - přílišná invence, která není na místě, k ničemu dobrému nevede. Imho není ani tak důležité znát všechno, důležitější je znát svoje limity a nepouštět se do věcí, na který nemám.
A nepřijde ti, že přesně to jsem napsal? (jen trochu jinými slovymi ;))
-
Zedník umí stavět zdi, ale pouze ve známém prostředí. Nespočítá si už například vliv náhrady materiálu izolace na tepelné ztráty zdi.
Zedník nemá nic počítat. Zedník má postavit zeď tak, jak je to v projektu. A s běžným programátorem je to dost často stejně - přílišná invence, která není na místě, k ničemu dobrému nevede. Imho není ani tak důležité znát všechno, důležitější je znát svoje limity a nepouštět se do věcí, na který nemám.
Programování bývalo spíše uměním, dnes je inženýrskou činností, ještě dlouho to nebude jen stavění zdi. Je to řemeslo, ne výroba. A každé řemeslo má v sobě tvůrčí složku, nikdy to není jen prostá reprodukce.
Odtud se nejspíš berou ty různé konflikty mezi "spíše umělci" a "spíše inženýry" (nemluvě o čistě formálních matematicích, i když matematika jakožto věda se taky blíží spíše tomu umění).
-
Forma dialogu je zrovna luxusní přístup. To je na té knize ještě to nejlepší.
Zíval jsem nudou a čekal jsem, kdy si ti dva půjdou vařit kafe.
-
A nepřijde ti, že přesně to jsem napsal? (jen trochu jinými slovymi ;))
Jo. Však jsem taky nereagoval na tebe :)
-
Java tu velmi pozdní vazbu má. Ale třeba Swift ne, proto na něj Čada dští síru
Kde? Zběžně jsem googlil a nenašel. Docela rad bych na to kouknul...
https://docs.oracle.com/javase/7/docs/api/java/lang/reflect/Proxy.html?is-external=true
:o Co to je???! Jak se to používá a jde to vůbec?
-
Otázkou je, jestli se OOP vůbec učit. On je to trochu zvrácený způsob myšlení a ne zrovna dobrý. Myslím si, že funkcionální programávání je mnohem lepší, ikdyž všichni propagují OOP.
Prosímvás, to neřešte, to už se tu řešilo a přišlo se na to, že 1. každý si pod OOP představuje něco jiného, 2. jej skoro nikdo nechápe.
Tazatel se ptal na knihu o OOP, ne na to, co zrovna letí.
-
OOP není vůbec zvrácené. Pro ty, kteří ho zcela nepochopili, bývá často výhodnější FP, neboť v něm nemohou dělat chyby, kterých se dopouštěli v OOP.
Nevím, každopádně by to mnohé vysvětlovalo.
-
Začínat s OOP bez znalosti základních konstrukcí v konkrétním jazyce mi přijde jako kdybyste v matematické analýze přeskočil reálná čísla a začal rovnou metrickými prostory. Když mají "znalci OOP" natvrdo vyřešit nějakou úlohu. Například na hackerrank. Většinou těžce pohoří.
Se studiem jazyků bez studia gramatiky také úplně nesouhlasím. Pouhým používáním se sice naučíte komunikovat, ale nikdy se nezbavíte gramatických chyb. Gramatiku musí studovat i rodilí mluvčí.
Fígl je v tom, že podstata OOP (i jiná paradigmata) jsou soběstačná a nezávislá na jazycích (implementacích). Naopak začít konkrétním jazykem může bých chybou vnucující zkriplení paradigmatu (velmi častý jev).
Naopak přirozený jazyk je implementací myšlenkového či dorozumívacího paradigmatu a bez mluvnice se neobejde.
-
Můžu se jen zeptat, co je na Pecinovského knihách o Javě špatného? Chtěl jsem si ty 2 díly pořídit, ale teď si nejsem jist, zda by to byla dobrá volba.
Mám zkušenost jen s Návrhovými vzory od něj. Kniha je úzce zaměřená na Javu a snaha vyhnout se (jak říká) AHA-příkladům vede na šílené, dlouhé příklady, ve kterých se nějaká myšlenka vzoru ztratí a vy se v nich utopíte. Jak může mít kniha vzorů, což jsou podstatou jednoduché myšlenky, 527 stran?! http://www.databazeknih.cz/knihy/navrhove-vzory-10930?show=binfo (http://www.databazeknih.cz/knihy/navrhove-vzory-10930?show=binfo)
P. S.: Prodám knihu Návrhové vzory od Pecinovského.
-
Prosímvás, to neřešte, to už se tu řešilo a přišlo se na to, že 1. každý si pod OOP představuje něco jiného, 2. jej skoro nikdo nechápe.
Tazatel se ptal na knihu o OOP, ne na to, co zrovna letí.
Souhlasim s tebou, otazka ovsem je, jak pak vubec nekomu doporucit/ohodnotit nejakou knihu o OOP, kdyz plati ty dve tvrzeni.
-
OOP není vůbec zvrácené. Pro ty, kteří ho zcela nepochopili, bývá často výhodnější FP, neboť v něm nemohou dělat chyby, kterých se dopouštěli v OOP.
Nevím, každopádně by to mnohé vysvětlovalo.
Problém je v tom, že OOP programátoři se ani mezi sebou neshodnou, co je chyba a co ne. A to nemluvím o nějakých hlupáčcích, ani špičky v oboru se neshodnou (viz třeba ten zmíněný Virius vs. Čada).
-
OOP není vůbec zvrácené. Pro ty, kteří ho zcela nepochopili, bývá často výhodnější FP, neboť v něm nemohou dělat chyby, kterých se dopouštěli v OOP.
Nevím, každopádně by to mnohé vysvětlovalo.
Problém je v tom, že OOP programátoři se ani mezi sebou neshodnou, co je chyba a co ne. A to nemluvím o nějakých hlupáčcích, ani špičky v oboru se neshodnou (viz třeba ten zmíněný Virius vs. Čada).
Čada není špička, ale major.
-
OOP není vůbec zvrácené. Pro ty, kteří ho zcela nepochopili, bývá často výhodnější FP, neboť v něm nemohou dělat chyby, kterých se dopouštěli v OOP.
Nevím, každopádně by to mnohé vysvětlovalo.
Problém je v tom, že OOP programátoři se ani mezi sebou neshodnou, co je chyba a co ne. A to nemluvím o nějakých hlupáčcích, ani špičky v oboru se neshodnou (viz třeba ten zmíněný Virius vs. Čada).
Jestli máš na mysli tu slavnou debatu o objektové hierarchii čísel (tam to klasicky dospělo, samotného by mě zajímalo, jak to dnes učí), tak tam bylo dost vidět, jak má Virius dost omezený pohled tím, jak je OOP implementováno v C++. On je na C++ hodně dobrej, ale chyběl mu rozhled.
-
Fígl je v tom, že podstata OOP (i jiná paradigmata) jsou soběstačná a nezávislá na jazycích (implementacích). Naopak začít konkrétním jazykem může bých chybou vnucující zkriplení paradigmatu (velmi častý jev).
Naopak přirozený jazyk je implementací myšlenkového či dorozumívacího paradigmatu a bez mluvnice se neobejde.
V každém jazyce se používají jiná paradigmata a jiné best practices. Zobecňovat to podle mě moc nejde. Správné je se přizpůsobit konvencím jazyka. Ne naopak. Učit se zobecnění bez znalosti jednotlivých případů, které zobecňuje, je k ničemu.
Diskuzi o objektovém myšlení celkově moc nechápu. Mě stačí vědět, že fun(obj) je to stejné co obj.fun().
-
Fígl je v tom, že podstata OOP (i jiná paradigmata) jsou soběstačná a nezávislá na jazycích (implementacích). Naopak začít konkrétním jazykem může bých chybou vnucující zkriplení paradigmatu (velmi častý jev).
Naopak přirozený jazyk je implementací myšlenkového či dorozumívacího paradigmatu a bez mluvnice se neobejde.
V každém jazyce se používají jiná paradigmata a jiné best practices. Zobecňovat to podle mě moc nejde. Správné je se přizpůsobit konvencím jazyka. Ne naopak. Učit se zobecnění bez znalosti jednotlivých případů, které zobecňuje, je k ničemu.
Diskuzi o objektovém myšlení celkově moc nechápu. Mě stačí vědět, že fun(obj) je to stejné co obj.fun().
*Mně
-
Diskuzi o objektovém myšlení celkově moc nechápu. Mě stačí vědět, že fun(obj) je to stejné co obj.fun().
Není to stejné. Funkce fun(obj) se ve většině jazyků přetížit ani překrýt nedá.
-
Koupil jsem si kdysi jeho Návrhové vzory a odložil po dvou stránkách. Styl je infantilní, čekal jsem, kdy si tam udělají kafe.
...a to je další věc, co mi vadila - prostý popis vzorů bych upřednostnil před rozvláčnou formou rozhovorů typu základní škola.
-
...Normálně se k OOP dostaneš asi po 1500-1700 hodinách výuky programování sám od sebe. To znamená cca po 12-18 měsících práce...
Objektáři doporučují začít s OOP místo strukturovaného, imperativního programování, protože je pro začátečníka pochopitelnější (samozřejmě ne v Javě).
... k Template a Generikám v OOP...
Co mají šablony a generické programování společné s OOP?
-
... k Template a Generikám v OOP...
Co mají šablony a generické programování společné s OOP?
Budu hádat: C++
-
Jestli máš na mysli tu slavnou debatu o objektové hierarchii čísel (tam to klasicky dospělo, samotného by mě zajímalo, jak to dnes učí), tak tam bylo dost vidět, jak má Virius dost omezený pohled tím, jak je OOP implementováno v C++. On je na C++ hodně dobrej, ale chyběl mu rozhled.
Souhlasím. Mimochodem, když si někde obstaráte postupně starší skripta od Viriuse, tak zjistíte, že ještě tak v polovině 90. let v tom OOP velmi solidně plaval.
A ty debaty o hierarchii vejce-slepice nebo u čísel jsou docela úsměvné. Problém OOP je, že v životě se dají tytéž věci klasifikovat různě, záleží na úhlu pohledu a na tom, k čemu to má celé sloužit. Auta můžu hierarchizovat podle barvy, podle velikosti, podle účelu, podle počtu náprav, podle počtu míst, podle užitného nákladu, podle výrobce, podle druhu pohonu... Žádná z nich není ta jediná správná, každá se hodí k něčemu jinému. Ale při návrhu objektového modelu je třeba zvolit takovou, která usnadní implementaci. A která nemusí mít s reálným životem dokonce nic společného - ale za to může odrážet nějaké implementační souvislosti, jako třeba reprezentaci v paměti apod. A to je ten kámen úrazu, protože to je ve skutečnosti poměrně náročný úkol, který když uděláte špatně, tak už se to potáhne navždy celým projektem a nejde s tím nic udělat. U jiných paradigmat, např. strukturovaného, je samozřejmě také nezbytné navrhnout datový model a strukturu procedur, ale řekl bych, že tam to není tak fatální jako u OOP.
Problém je v tom, že OOP programátoři se ani mezi sebou neshodnou, co je chyba a co ne. A to nemluvím o nějakých hlupáčcích, ani špičky v oboru se neshodnou (viz třeba ten zmíněný Virius vs. Čada).
Čada není špička, ale major.
Možná je magor, ale špička (alespoň v rámci našeho rybníčka) IMHO taky.
-
Jestli máš na mysli tu slavnou debatu o objektové hierarchii čísel (tam to klasicky dospělo, samotného by mě zajímalo, jak to dnes učí), tak tam bylo dost vidět, jak má Virius dost omezený pohled tím, jak je OOP implementováno v C++. On je na C++ hodně dobrej, ale chyběl mu rozhled.
Souhlasím. Mimochodem, když si někde obstaráte postupně starší skripta od Viriuse, tak zjistíte, že ještě tak v polovině 90. let v tom OOP velmi solidně plaval.
A ty debaty o hierarchii vejce-slepice nebo u čísel jsou docela úsměvné. Problém OOP je, že v životě se dají tytéž věci klasifikovat různě, záleží na úhlu pohledu a na tom, k čemu to má celé sloužit. Auta můžu hierarchizovat podle barvy, podle velikosti, podle účelu, podle počtu náprav, podle počtu míst, podle užitného nákladu, podle výrobce, podle druhu pohonu... Žádná z nich není ta jediná správná, každá se hodí k něčemu jinému. Ale při návrhu objektového modelu je třeba zvolit takovou, která usnadní implementaci. A která nemusí mít s reálným životem dokonce nic společného - ale za to může odrážet nějaké implementační souvislosti, jako třeba reprezentaci v paměti apod. A to je ten kámen úrazu, protože to je ve skutečnosti poměrně náročný úkol, který když uděláte špatně, tak už se to potáhne navždy celým projektem a nejde s tím nic udělat. U jiných paradigmat, např. strukturovaného, je samozřejmě také nezbytné navrhnout datový model a strukturu procedur, ale řekl bych, že tam to není tak fatální jako u OOP.
On to je trochu problém čistě technický, a sice (jednoduché) dědičnosti. Lepší je asi používat protokoly, pak jde totiž mít ty různé "hierarchizace" v kódu současně. Haskell, Swift nebo třeba Go jdou v tomto ohledu s dobou a vlastně se ukazuje, že dědičnost à la C++ až tak potřebná není. Celé by to mělo směřovat ke "complexion reduction". Kdy se to prosadí u většiny zkušených vývojářů, to už je věc jiná. Přinejmenším je ale přínosné kouknout se na tuto alternativu a zvážit, jak lze psát efektivněji. Pravděpodobně to bude pozvolný plynulý přechod.
-
A ty debaty o hierarchii vejce-slepice nebo u čísel jsou docela úsměvné. Problém OOP je, že v životě se dají tytéž věci klasifikovat různě, záleží na úhlu pohledu a na tom, k čemu to má celé sloužit. Auta můžu hierarchizovat podle barvy, podle velikosti, podle účelu, podle počtu náprav, podle počtu míst, podle užitného nákladu, podle výrobce, podle druhu pohonu... Žádná z nich není ta jediná správná, každá se hodí k něčemu jinému. Ale při návrhu objektového modelu je třeba zvolit takovou, která usnadní implementaci. A která nemusí mít s reálným životem dokonce nic společného - ale za to může odrážet nějaké implementační souvislosti, jako třeba reprezentaci v paměti apod. A to je ten kámen úrazu, protože to je ve skutečnosti poměrně náročný úkol, který když uděláte špatně, tak už se to potáhne navždy celým projektem a nejde s tím nic udělat. U jiných paradigmat, např. strukturovaného, je samozřejmě také nezbytné navrhnout datový model a strukturu procedur, ale řekl bych, že tam to není tak fatální jako u OOP.
Super shrnutí. Proto mnozí na dědičnost rezignovali a všechno se snaží lepit kompozicí, což také není správně. Rozdělení tříd na třídy s metodami a třídy s atributy je pak už úplné zvěrstvo.
-
Nevim, jestli spamovat vlakno o necem uplne jinem, ale kdyz uz jste s tim zacali... A koneckoncu je to mistni kolorit, tak snad v poho ;)
Pochopení FP do hloubky vyžaduje detailní znalost teorie kategorií. [...] Ovšem ne každý to potřebuje, takže se není o čem hádat.
To tvrzeni mi prijde vylozene zhoubne. Protoze uplne zbytecne od FP odrazuje lidi, kteri ho ani nezkusili, popr. ty, kdo ho zkusili a po prvnim zamotani se rychle skoncili, utvrdi v tom, ze udelali dobre. A pritom je dost zavadejici, kdyz uz nechci rict vylozene nepravdive...
„...i skladník ve šroubárně si může přečísti Vergilia v originále...“
-
„...i skladník ve šroubárně si může přečísti Vergilia v originále...“
Ale nikdo nebude tvrdit, že pochopení šroubárny do hloubky vyžaduje jeho znalost :)
-
Zedník umí stavět zdi, ale pouze ve známém prostředí. Nespočítá si už například vliv náhrady materiálu izolace na tepelné ztráty zdi.
Zedník nemá nic počítat. Zedník má postavit zeď tak, jak je to v projektu. A s běžným programátorem je to dost často stejně - přílišná invence, která není na místě, k ničemu dobrému nevede. Imho není ani tak důležité znát všechno, důležitější je znát svoje limity a nepouštět se do věcí, na který nemám.
Programování bývalo spíše uměním, dnes je inženýrskou činností, ještě dlouho to nebude jen stavění zdi. Je to řemeslo, ne výroba. A každé řemeslo má v sobě tvůrčí složku, nikdy to není jen prostá reprodukce.
Dokud nebude softwareové inženýrství dostatečně formalizované jako např. stavebnictví (a to nyní v žádném případě není), programátor-dělník nebude dostačovat. Toto je zároveň odpovědí na srovnání zedníka s vývojářem.
-
Souhlasim s tebou, otazka ovsem je, jak pak vubec nekomu doporucit/ohodnotit nejakou knihu o OOP, kdyz plati ty dve tvrzeni.
Reagoval jsem především na to, že už tu někdo startoval, že bude doporučovat funkcionální programování jako náhradu OOP.
-
Diskuzi o objektovém myšlení celkově moc nechápu. Mě stačí vědět, že fun(obj) je to stejné co obj.fun().
Není to stejné. Funkce fun(obj) se ve většině jazyků přetížit ani překrýt nedá.
To už se řeší v každém jazyku jinak a je hloupost o tom obecně teoretizovat.
-
V každém jazyce se používají jiná paradigmata a jiné best practices. Zobecňovat to podle mě moc nejde. Správné je se přizpůsobit konvencím jazyka. Ne naopak. Učit se zobecnění bez znalosti jednotlivých případů, které zobecňuje, je k ničemu.
Bavíme se o pochopení jednoho paradigmatu, ne o směsi v nějakém jazyku! Začnete-li vysvětlováním na jazyku, vysvětlil jste implementaci, ne myšlenku. Jazyk není specializací myšlenky, jazyk je její implementací!!!
Diskuzi o objektovém myšlení celkově moc nechápu. Mě stačí vědět, že fun(obj) je to stejné co obj.fun().
Tak jestli je to pro vás to samé, tak co tu ještě řešíme?
-
Co mají šablony a generické programování společné s OOP?
Budu hádat: C++
Pro některé i tak.
-
V každém jazyce se používají jiná paradigmata a jiné best practices. Zobecňovat to podle mě moc nejde. Správné je se přizpůsobit konvencím jazyka. Ne naopak. Učit se zobecnění bez znalosti jednotlivých případů, které zobecňuje, je k ničemu.
Bavíme se o pochopení jednoho paradigmatu, ne o směsi v nějakém jazyku! Začnete-li vysvětlováním na jazyku, vysvětlil jste implementaci, ne myšlenku. Jazyk není specializací myšlenky, jazyk je její implementací!!!
Od používání různých pseudokódů v literatuře a ve výuce se postupně ustupuje. Lepší je vysvětlovat na konkrétním přesně specifikovaném jazyku. Neformální okecávání do technických oborů nepatří.
-
...který když uděláte špatně, tak už se to potáhne navždy celým projektem a nejde s tím nic udělat. U jiných paradigmat, např. strukturovaného, je samozřejmě také nezbytné navrhnout datový model a strukturu procedur, ale řekl bych, že tam to není tak fatální jako u OOP.
Řekl byste, nebo víte?
Jednou z klíčových myšlenek OOP je rozdělení domény na malé části nezávislé tak moc, jak to jen jde. Jejich refaktorizace je potom téměř či úplně nezávislá. K tomu má přispět i zapouzdření, nad kterým zde kdekdo mávne rukou. Dědičnost je nepovinná, i tak refaktorizovatelná. Není mi jasné, v čem spočívá ta horší pozice oproti strukturovanému programování.
-
„...i skladník ve šroubárně si může přečísti Vergilia v originále...“
Ale nikdo nebude tvrdit, že pochopení šroubárny do hloubky vyžaduje jeho znalost :)
Samozřejmě že ne, právě pro onu rozporuplnost jsem tuto neskutečnou větu uvedl.
-
Není to stejné. Funkce fun(obj) se ve většině jazyků přetížit ani překrýt nedá.
To už se řeší v každém jazyku jinak a je hloupost o tom obecně teoretizovat.
To se vůbec neřeší, jsou to 2 rozdílné mechanismy, které fungují zcela jinak a nemají nic polečného!
-
Od používání různých pseudokódů v literatuře a ve výuce se postupně ustupuje. Lepší je vysvětlovat na konkrétním přesně specifikovaném jazyku. Neformální okecávání do technických oborů nepatří.
A inzenyri maji zakazano delat nacrtky a museji vsechno presne narysovat?
To uz je dneska podruhe: ruzne urovne abstrakce (a presnosti) pro ruzne situace. Nekdy potrebujes mit moznost psat realny kod (treba kdyz je ucis test-driven), jindy ti staci nacrtnout (treba kdyz ukazujes variace nejakeho algoritmu).
-
„...i skladník ve šroubárně si může přečísti Vergilia v originále...“
Ale nikdo nebude tvrdit, že pochopení šroubárny do hloubky vyžaduje jeho znalost :)
Právě, že vyžaduje. Lidé co nečetli Vergilia, či něco podobného, většinou nechápou svět kolem sebe i když si myslí, že ho chápou. A pak ho taky stěží mohou modelovat. Naopak, čtenář Vergilia nemusí pracovat ve šroubárně, aby ji pochopil a mohl ji modelovat.
Jinak i ve stavebnictví, v oboru s tisíciletou tradicí, se od nepaměti vede boj mezi stavebními konstruktéry, architekty na jedné straně a políry a zedníky na druhé straně. Jedni o druhých si myslí, že to jsou blbci a jejich výtvory stojí za zlámanou grešli :-)))
-
Od používání různých pseudokódů v literatuře a ve výuce se postupně ustupuje. Lepší je vysvětlovat na konkrétním přesně specifikovaném jazyku. Neformální okecávání do technických oborů nepatří.
A inzenyri maji zakazano delat nacrtky a museji vsechno presne narysovat?
To uz je dneska podruhe: ruzne urovne abstrakce (a presnosti) pro ruzne situace. Nekdy potrebujes mit moznost psat realny kod (treba kdyz je ucis test-driven), jindy ti staci nacrtnout (treba kdyz ukazujes variace nejakeho algoritmu).
Dobrý program vypadá jako náčrtek :-)))
-
Jinak i ve stavebnictví, v oboru s tisíciletou tradicí, se od nepaměti vede boj mezi stavebními konstruktéry, architekty na jedné straně a políry a zedníky na druhé straně. Jedni o druhých si myslí, že to jsou blbci a jejich výtvory stojí za zlámanou grešli :-)))
;D Tak to už bývá...
-
Diskuzi o objektovém myšlení celkově moc nechápu. Mě stačí vědět, že fun(obj) je to stejné co obj.fun().
Není to stejné. Funkce fun(obj) se ve většině jazyků přetížit ani překrýt nedá.
To už se řeší v každém jazyku jinak a je hloupost o tom obecně teoretizovat.
Takže podle tebe je
adam.print()
kniha.print()totéž co
print(adam)
print(kniha)?
V prvním případě mi to s přehledem vypíše údaje o člověku (jméno, příjmení, věk) a také o knize (název, autor, vydavatel).
Pokud to budeš volat jako funkci, tak totéž jen tak neuděláš.
-
„...i skladník ve šroubárně si může přečísti Vergilia v originále...“
Ale nikdo nebude tvrdit, že pochopení šroubárny do hloubky vyžaduje jeho znalost :)
Právě, že vyžaduje. Lidé co nečetli Vergilia, či něco podobného, většinou nechápou svět kolem sebe i když si myslí, že ho chápou. A pak ho taky stěží mohou modelovat. Naopak, čtenář Vergilia nemusí pracovat ve šroubárně, aby ji pochopil a mohl ji modelovat.
Jinak i ve stavebnictví, v oboru s tisíciletou tradicí, se od nepaměti vede boj mezi stavebními konstruktéry, architekty na jedné straně a políry a zedníky na druhé straně. Jedni o druhých si myslí, že to jsou blbci a jejich výtvory stojí za zlámanou grešli :-)))
Dnešním architektům by neuškodilo, kdyby současně rozuměli statice a řemeslu a nebrali architekturu jen jako kreslení obrázků. Michelangelo nebo Petr Parléř se řemeslu nevyhýbali a na jejich díle je to znát. Takovou hovadinu jako chobotnici na Letné by určitě nevymysleli.
-
V prvním případě mi to s přehledem vypíše údaje o člověku (jméno, příjmení, věk) a také o knize (název, autor, vydavatel).
Pokud to budeš volat jako funkci, tak totéž jen tak neuděláš.
o rozhraní (interface) už jste slyšel?
-
V prvním případě mi to s přehledem vypíše údaje o člověku (jméno, příjmení, věk) a také o knize (název, autor, vydavatel).
Pokud to budeš volat jako funkci, tak totéž jen tak neuděláš.
o rozhraní (interface) už jste slyšel?
Ano, slyšel. Je nutné ho zde uvádět nebo musím poprosit puristy, aby mi bylo dovoleno to napsat ve stylu Pythonu?
Jak bys ty funkce (nikoli metody, ty jsou jasné) napsal s použitím rozhraní?
-
Od používání různých pseudokódů v literatuře a ve výuce se postupně ustupuje. Lepší je vysvětlovat na konkrétním přesně specifikovaném jazyku. Neformální okecávání do technických oborů nepatří.
A inzenyri maji zakazano delat nacrtky a museji vsechno presne narysovat?
To uz je dneska podruhe: ruzne urovne abstrakce (a presnosti) pro ruzne situace. Nekdy potrebujes mit moznost psat realny kod (treba kdyz je ucis test-driven), jindy ti staci nacrtnout (treba kdyz ukazujes variace nejakeho algoritmu).
Můžete to načrtnout i v reálném programovacím jazyku. Nemusíte uvádět implementace všech volaných funkcí.
-
Od používání různých pseudokódů v literatuře a ve výuce se postupně ustupuje. Lepší je vysvětlovat na konkrétním přesně specifikovaném jazyku. Neformální okecávání do technických oborů nepatří.
A inzenyri maji zakazano delat nacrtky a museji vsechno presne narysovat?
To uz je dneska podruhe: ruzne urovne abstrakce (a presnosti) pro ruzne situace. Nekdy potrebujes mit moznost psat realny kod (treba kdyz je ucis test-driven), jindy ti staci nacrtnout (treba kdyz ukazujes variace nejakeho algoritmu).
K té abstrakci x konkrétní jazyk: To mi připomíná způsob práce v nejmenované firmě, kde jsem dělal. Když bylo třeba vytvořit či rozšířit funkcionalitu aplikace, místo aby se nejprve obecně pojmenovaly entity a jejich činnosti, nakreslily na papír krabičky, domalovaly vztahy, z toho řešilo, jak to bude v doméně, následně v jazyku a v DB, tak se jako PRVNÍ začalo řešit, jak to bude uloženo v RELAČNÍ databázi. Výsledek: Vše odspodu nahoru podřízeno relační databázi včetně případných chyb, struktury, zpracování... Krása.
-
K té abstrakci x konkrétní jazyk: To mi připomíná způsob práce v nejmenované firmě, kde jsem dělal. Když bylo třeba vytvořit či rozšířit funkcionalitu aplikace, místo aby se nejprve obecně pojmenovaly entity a jejich činnosti, nakreslily na papír krabičky, domalovaly vztahy, z toho řešilo, jak to bude v doméně, následně v jazyku a v DB, tak se jako PRVNÍ začalo řešit, jak to bude uloženo v RELAČNÍ databázi. Výsledek: Vše odspodu nahoru podřízeno relační databázi včetně případných chyb, struktury, zpracování... Krása.
Tak jste mohli použít nerelační databázi, pokud jste chtěli efektivně ukládat nerelační data.
-
Od používání různých pseudokódů v literatuře a ve výuce se postupně ustupuje. Lepší je vysvětlovat na konkrétním přesně specifikovaném jazyku. Neformální okecávání do technických oborů nepatří.
A inzenyri maji zakazano delat nacrtky a museji vsechno presne narysovat?
To uz je dneska podruhe: ruzne urovne abstrakce (a presnosti) pro ruzne situace. Nekdy potrebujes mit moznost psat realny kod (treba kdyz je ucis test-driven), jindy ti staci nacrtnout (treba kdyz ukazujes variace nejakeho algoritmu).
K té abstrakci x konkrétní jazyk: To mi připomíná způsob práce v nejmenované firmě, kde jsem dělal. Když bylo třeba vytvořit či rozšířit funkcionalitu aplikace, místo aby se nejprve obecně pojmenovaly entity a jejich činnosti, nakreslily na papír krabičky, domalovaly vztahy, z toho řešilo, jak to bude v doméně, následně v jazyku a v DB, tak se jako PRVNÍ začalo řešit, jak to bude uloženo v RELAČNÍ databázi. Výsledek: Vše odspodu nahoru podřízeno relační databázi včetně případných chyb, struktury, zpracování... Krása.
Coz je pro znacne procento aplikaci naprosto spravny postup.
Neni nic zoufalejsiho naphled, nez uvidet v Oraclu hromadu hibernatem vygenerovaneho hnoje, po kazdem insertu zpetny select, aby hibernate videl autogenerovany klic, JSQL join genialne implementovany pres java nested loop, indexy jsou sproste slovo, transakce zamykane na J2EE urovni, select limit implementovan stylem stahni vsech 10milonu zaznamu a z prostredka jich vyber 20, jeden by blil. Nebo kod idiotsky neustale tahajici data mezi tomcatem a oraclem jak kocka mlade, aby vusledkem byla jedna integer KPI metrika, kterou mohla spocist jednoducha PLSQL procedura a nemusely po siti litat megabajty dat resultsetu.
Spousta lidi kolem jawy nema sebemensi poneti o SQL/PLSQL a vysledek je otres.
Nebo ted nova moda, vsecko naser do elasticsearch a dej se vule bozi, obvykle navic opensource varianta elasticsearch s nulovou bezpecnosti.
V realu, pokud bude aplikace pracovat s tabulkami se 100k zaznamy a vice, zakladem navrhu je ER model.
Osobne vubec v hibernatu nepouzivam transakce, mam je vyple. Vsechno potrebne balim do PLSQL procedur, ktere jsou z pohledu jawy atomicka operace. Nepouzivam ani JSQL, pozivam primo nativni SQL. Jdou v tom i takove "zazraky" jaomselect limit u MySQL, nebo IP aritmetika Postgresu.
-
Neni nic zoufalejsiho naphled, nez uvidet v Oraclu hromadu hibernatem vygenerovaneho hnoje, po kazdem insertu zpetny select, aby hibernate videl autogenerovany klic, JSQL join genialne implementovany pres java nested loop, indexy jsou sproste slovo, transakce zamykane na J2EE urovni, select limit implementovan stylem stahni vsech 10milonu zaznamu a z prostredka jich vyber 20, jeden by blil. Nebo kod idiotsky neustale tahajici data mezi tomcatem a oraclem jak kocka mlade, aby vusledkem byla jedna integer KPI metrika, kterou mohla spocist jednoducha PLSQL procedura a nemusely po siti litat megabajty dat resultsetu.
Spousta lidi kolem jawy nema sebemensi poneti o SQL/PLSQL a vysledek je otres.
...a kdyz misto "java" das "python" a misto "hibernate" "django", bude to uplne stejne pravde-podobny popis, takze bych z javy uplne nedelal obetniho beranka :)
-
Neni nic zoufalejsiho naphled, nez uvidet v Oraclu hromadu hibernatem vygenerovaneho hnoje, po kazdem insertu zpetny select, aby hibernate videl autogenerovany klic, JSQL join genialne implementovany pres java nested loop, indexy jsou sproste slovo, transakce zamykane na J2EE urovni, select limit implementovan stylem stahni vsech 10milonu zaznamu a z prostredka jich vyber 20, jeden by blil. Nebo kod idiotsky neustale tahajici data mezi tomcatem a oraclem jak kocka mlade, aby vusledkem byla jedna integer KPI metrika, kterou mohla spocist jednoducha PLSQL procedura a nemusely po siti litat megabajty dat resultsetu.
Spousta lidi kolem jawy nema sebemensi poneti o SQL/PLSQL a vysledek je otres.
...a kdyz misto "java" das "python" a misto "hibernate" "django", bude to uplne stejne pravde-podobny popis, takze bych z javy uplne nedelal obetniho beranka :)
Ono je to kvůli MS SQL, který nemá LIMIT, ale jen TOP, což se pro stránkování nedá použít.
-
Neni nic zoufalejsiho naphled, nez uvidet v Oraclu hromadu hibernatem vygenerovaneho hnoje, po kazdem insertu zpetny select, aby hibernate videl autogenerovany klic, JSQL join genialne implementovany pres java nested loop, indexy jsou sproste slovo, transakce zamykane na J2EE urovni, select limit implementovan stylem stahni vsech 10milonu zaznamu a z prostredka jich vyber 20, jeden by blil. Nebo kod idiotsky neustale tahajici data mezi tomcatem a oraclem jak kocka mlade, aby vusledkem byla jedna integer KPI metrika, kterou mohla spocist jednoducha PLSQL procedura a nemusely po siti litat megabajty dat resultsetu.
Spousta lidi kolem jawy nema sebemensi poneti o SQL/PLSQL a vysledek je otres.
...a kdyz misto "java" das "python" a misto "hibernate" "django", bude to uplne stejne pravde-podobny popis, takze bych z javy uplne nedelal obetniho beranka :)
Ono je to kvůli MS SQL, který nemá LIMIT, ale jen TOP, což se pro stránkování nedá použít.
To je právě ten problém. Pod záminkou přenositelnosti mezi databázemi jsou všechny degradovány na nějaký společný základ - ať to stojí, co to stojí.
-
Neni nic zoufalejsiho naphled, nez uvidet v Oraclu hromadu hibernatem vygenerovaneho hnoje, po kazdem insertu zpetny select, aby hibernate videl autogenerovany klic, JSQL join genialne implementovany pres java nested loop, indexy jsou sproste slovo, transakce zamykane na J2EE urovni, select limit implementovan stylem stahni vsech 10milonu zaznamu a z prostredka jich vyber 20, jeden by blil. Nebo kod idiotsky neustale tahajici data mezi tomcatem a oraclem jak kocka mlade, aby vusledkem byla jedna integer KPI metrika, kterou mohla spocist jednoducha PLSQL procedura a nemusely po siti litat megabajty dat resultsetu.
Spousta lidi kolem jawy nema sebemensi poneti o SQL/PLSQL a vysledek je otres.
...a kdyz misto "java" das "python" a misto "hibernate" "django", bude to uplne stejne pravde-podobny popis, takze bych z javy uplne nedelal obetniho beranka :)
Ono je to kvůli MS SQL, který nemá LIMIT, ale jen TOP, což se pro stránkování nedá použít.
To je právě ten problém. Pod záminkou přenositelnosti mezi databázemi jsou všechny degradovány na nějaký společný základ - ať to stojí, co to stojí.
Ale to je základní vlastnost toho prostředí, webu obecně, je polygenní. Na vině je HTML a CSS. Při vývoji webu se začalo od konce a to byla chyba. Kdyby klient byl jen automat ovládaný ze serveru a zprostředkovávající interakce s uživateli, celé prostředí by bylo efektivnější. Mělo se začít javascriptem, nebo ještě lépe lispem na straně klienta. Dnes bychom měli sémantický web, protože klient by sám generoval strojově interpretovatelné informace pro roboty vyhledávačů. Bohužel web vznikl v CERNU, tedy v prostředí orientovaném uživatelsky, ne programátorsky.
V prostředí IoT to bude jinak, tam prezentační vrstva bude chybět, což povede k větší efektivitě a novým paradigmatům kolektivního zpracování informace.
-
Tak jste mohli použít nerelační databázi, pokud jste chtěli efektivně ukládat nerelační data.
To je přece buřt, do čeho to strkám. Důležité je, aby to bylo abstraktně odděleno jako vrstva, pak tam můžu použít pro ukládání třeba pozitronový mozek androida.
-
Tak jste mohli použít nerelační databázi, pokud jste chtěli efektivně ukládat nerelační data.
To je přece buřt, do čeho to strkám. Důležité je, aby to bylo abstraktně odděleno jako vrstva, pak tam můžu použít pro ukládání třeba pozitronový mozek androida.
Pokud jde o výkon, buřt to nebude.
-
To je právě ten problém. Pod záminkou přenositelnosti mezi databázemi jsou všechny degradovány na nějaký společný základ - ať to stojí, co to stojí.
Ale to je základní vlastnost toho prostředí, webu obecně, je polygenní. Na vině je HTML a CSS. Při vývoji webu se začalo od konce a to byla chyba. Kdyby klient byl jen automat ovládaný ze serveru a zprostředkovávající interakce s uživateli, celé prostředí by bylo efektivnější. Mělo se začít javascriptem, nebo ještě lépe lispem na straně klienta. Dnes bychom měli sémantický web, protože klient by sám generoval strojově interpretovatelné informace pro roboty vyhledávačů. Bohužel web vznikl v CERNU, tedy v prostředí orientovaném uživatelsky, ne programátorsky.
V prostředí IoT to bude jinak, tam prezentační vrstva bude chybět, což povede k větší efektivitě a novým paradigmatům kolektivního zpracování informace.
Právě Lisp by mohl s přehledem nahradit jak serverovou část, tak i HTML, CSS s Javascriptem dohromady. Jenže uživatelé to chtěli jinak a implementace Lispu se do webových prohlížečů ani nedostala.
-
Neni nic zoufalejsiho naphled, nez uvidet v Oraclu hromadu hibernatem vygenerovaneho hnoje, po kazdem insertu zpetny select, aby hibernate videl autogenerovany klic, JSQL join genialne implementovany pres java nested loop, indexy jsou sproste slovo, transakce zamykane na J2EE urovni, select limit implementovan stylem stahni vsech 10milonu zaznamu a z prostredka jich vyber 20, jeden by blil. Nebo kod idiotsky neustale tahajici data mezi tomcatem a oraclem jak kocka mlade, aby vusledkem byla jedna integer KPI metrika, kterou mohla spocist jednoducha PLSQL procedura a nemusely po siti litat megabajty dat resultsetu.
Spousta lidi kolem jawy nema sebemensi poneti o SQL/PLSQL a vysledek je otres.
...a kdyz misto "java" das "python" a misto "hibernate" "django", bude to uplne stejne pravde-podobny popis, takze bych z javy uplne nedelal obetniho beranka :)
Django nepoužívám, ale limit funguje normálně, joiny přes loop to neprovádí a pro efektivní save jde použít bulk_save. Má to mouchy, proto jsem přešel na SQLAlchemy. Ale to co píšete, není pravda.
-
Django nepoužívám, ale limit funguje normálně, joiny přes loop to neprovádí a pro efektivní save jde použít bulk_save. Má to mouchy, proto jsem přešel na SQLAlchemy. Ale to co píšete, není pravda.
O limitu jsem nic nepsal. Problém ORM frameworků je, že si člověk "snadno" kdekoliv v kódu šáhne pro cokoliv jako by to byla lokální proměnná a vůbec neřeší, jak ve skutečnosti budou vypadat ty dotazy, jaká s tím bude režie. V tom je ten ďábel v detailu.
-
Právě Lisp by mohl s přehledem nahradit jak serverovou část, tak i HTML, CSS s Javascriptem dohromady. Jenže uživatelé to chtěli jinak a implementace Lispu se do webových prohlížečů ani nedostala.
Jo protoze uzivatele maji sajnu jaky rozdil je mezi lispem visual basicem a javascriptem ze ? ;D Lisp se nedostal vubec nikde, je to akademicky konstrukt na vyuku jistych funkcionalnich aspektu programovani. V praxi je pro masy nepouzitelny a skoncilo by to tak jako tak transpilaci do jazyku nizsi generace. Tedy jedno prakticke nasazeni lispu znam - Emacs, a podle toho to i vypada :-)
-
Právě Lisp by mohl s přehledem nahradit jak serverovou část, tak i HTML, CSS s Javascriptem dohromady. Jenže uživatelé to chtěli jinak a implementace Lispu se do webových prohlížečů ani nedostala.
Javascript je čitelnější než Lisp. JSON, CSS a HTML jsou čitelnější než s-expressions. Lisp měl smysl v sedmdesátých letech, kdy jiné jazyky neumožňovaly zápis složitějších struktur a interaktivní použití. Javascript to umožňuje a IMHO lépe.
-
Právě Lisp by mohl s přehledem nahradit jak serverovou část, tak i HTML, CSS s Javascriptem dohromady. Jenže uživatelé to chtěli jinak a implementace Lispu se do webových prohlížečů ani nedostala.
Jo protoze uzivatele maji sajnu jaky rozdil je mezi lispem visual basicem a javascriptem ze ? ;D Lisp se nedostal vubec nikde, je to akademicky konstrukt na vyuku jistych funkcionalnich aspektu programovani. V praxi je pro masy nepouzitelny a skoncilo by to tak jako tak transpilaci do jazyku nizsi generace. Tedy jedno prakticke nasazeni lispu znam - Emacs, a podle toho to i vypada :-)
No HTML je "podmnožina" lispu, jen závorku nahradilo tagem a implenentaci omezilo pouze na deklarativní aspekt.
-
Uživatelé nerozhodovali.
-
Právě Lisp by mohl s přehledem nahradit jak serverovou část, tak i HTML, CSS s Javascriptem dohromady. Jenže uživatelé to chtěli jinak a implementace Lispu se do webových prohlížečů ani nedostala.
Javascript je čitelnější než Lisp. JSON, CSS a HTML jsou čitelnější než s-expressions. Lisp měl smysl v sedmdesátých letech, kdy jiné jazyky neumožňovaly zápis složitějších struktur a interaktivní použití. Javascript to umožňuje a IMHO lépe.
Klient by měl být konstruován tak, že k němu není přímý přístup přes nějaký jazyk, ale jen přes objektový, nebo funkcionální interface. Server by místo povelů pro renderovací jádro v HTML, CSS a javascriptu generoval lispovské seznamy, přímo interpretované lispovým jádrem prohlížeče. Důraz má být kladen na strojovou analýzu, nikoliv na čtení pro lidi. Lisp použitý jako deklarace je čitelnější než kompozit HTML, CSS a javascriptu. Ostatně proto se přechází na JSON, všude, kde to jde.
-
Uživatelé nerozhodovali.
Rozhodoval uživatelský přístup autorů webu. Tedy aby bylo snadné psát a renderovat hypertextový obsah.
-
Uživatelé nerozhodovali.
Rozhodoval uživatelský přístup autorů webu. Tedy aby bylo snadné psát a renderovat hypertextový obsah.
O javascriptu už uživatelé nerozhodovali.
-
Javascript je čitelnější než Lisp. JSON, CSS a HTML jsou čitelnější než s-expressions. Lisp měl smysl v sedmdesátých letech, kdy jiné jazyky neumožňovaly zápis složitějších struktur a interaktivní použití. Javascript to umožňuje a IMHO lépe.
Javascript je krutá pomsta. Nevím koho, nevím komu, ale opravdu krutá. Nebo něčí odporný žert. Používat ho na skriptování nějakých animací na webu, dejme tomu, ale aplikační jazyk? Proboha. Už jen to doporučované formátování, dávat bracket na stejný řádek jako function nebo if, to je zjevně něčí zlý úmysl.
-
Django nepoužívám, ale limit funguje normálně, joiny přes loop to neprovádí a pro efektivní save jde použít bulk_save. Má to mouchy, proto jsem přešel na SQLAlchemy. Ale to co píšete, není pravda.
O limitu jsem nic nepsal. Problém ORM frameworků je, že si člověk "snadno" kdekoliv v kódu šáhne pro cokoliv jako by to byla lokální proměnná a vůbec neřeší, jak ve skutečnosti budou vypadat ty dotazy, jaká s tím bude režie. V tom je ten ďábel v detailu.
To se dá ale ošetřit, taková db4o měla svého času konfigurovatelná omezení (není to ORM, ale čistě objektová databáze, což je zde ovšem irelevantní). Navíc když je někdo pablb, tak zprasí dotazy do DB i bez ORM.
-
Právě Lisp by mohl s přehledem nahradit jak serverovou část, tak i HTML, CSS s Javascriptem dohromady. Jenže uživatelé to chtěli jinak a implementace Lispu se do webových prohlížečů ani nedostala.
Javascript je čitelnější než Lisp. JSON, CSS a HTML jsou čitelnější než s-expressions. Lisp měl smysl v sedmdesátých letech, kdy jiné jazyky neumožňovaly zápis složitějších struktur a interaktivní použití. Javascript to umožňuje a IMHO lépe.
O čitelnosti Javascript vs. Lisp se dá dlouze diskutovat, je to značně subjektivní. Lisp má úspornější zápis a proto se zřejmě většině lidí čte hůře.
-
Navíc když je někdo pablb, tak zprasí dotazy do DB i bez ORM.
Určitě. Ale ORM framework mu v tom mocně sekunduje a pěkně za ručičku vede do pekla ;) Čím jednodušší na použití, tím horší.
-
Javascript je čitelnější než Lisp. JSON, CSS a HTML jsou čitelnější než s-expressions. Lisp měl smysl v sedmdesátých letech, kdy jiné jazyky neumožňovaly zápis složitějších struktur a interaktivní použití. Javascript to umožňuje a IMHO lépe.
Javascript je krutá pomsta. Nevím koho, nevím komu, ale opravdu krutá. Nebo něčí odporný žert. Používat ho na skriptování nějakých animací na webu, dejme tomu, ale aplikační jazyk? Proboha. Už jen to doporučované formátování, dávat bracket na stejný řádek jako function nebo if, to je zjevně něčí zlý úmysl.
Jazyky se dají hodnotit podle (akademické) čistoty a pragmatičnosti. Takový Haskell je až matematicky "čistý", ale nepříliš pragmatický. Go je třeba naopak vysoce pragmatické, ale na teorii CS zvysoka - ehm - kašle. JS je vzácný příklad jazyka, co není ani "čistý", ani pragmatický. Fakt je to pomsta :) nebo rafinovaný nástroj k odhalování trotlů (IF likes Javascript THEN is thicko) ;)
-
Javascript je čitelnější než Lisp. JSON, CSS a HTML jsou čitelnější než s-expressions. Lisp měl smysl v sedmdesátých letech, kdy jiné jazyky neumožňovaly zápis složitějších struktur a interaktivní použití. Javascript to umožňuje a IMHO lépe.
Javascript je krutá pomsta. Nevím koho, nevím komu, ale opravdu krutá. Nebo něčí odporný žert. Používat ho na skriptování nějakých animací na webu, dejme tomu, ale aplikační jazyk? Proboha. Už jen to doporučované formátování, dávat bracket na stejný řádek jako function nebo if, to je zjevně něčí zlý úmysl.
Nevidím důvod, proč by měl být bracket na samostatném řádku. Otevírací píši vždy na konci aktuálního řádku a následující řádky odsadím. Zatím mi nikdo nezdůvodnil, proč to psát jinak.
BTW: Nedělal jsem to ani v Pascalu. Begin si prostě nezaslouží samostatný řádek.
-
Navíc když je někdo pablb, tak zprasí dotazy do DB i bez ORM.
Určitě. Ale ORM framework mu v tom mocně sekunduje a pěkně za ručičku vede do pekla ;) Čím jednodušší na použití, tím horší.
To asi jo, mám vlastní zkušenost s jedním "juniorem", co za použití automatického ORM dával do DB objekty dědící z UIView >:(
-
JS je vzácný příklad jazyka, co není ani "čistý", ani pragmatický.
JS byl celkem pragmatický a relativně OK ve svém původním účelu: jednořádkový handler kliknutí někam. Že se z něj pak stal jazyk, ve kterém se budují dnešní webové jaderné elektrárny, je jiná věc, spíš historická nahodilost.
Mně spíš doteď není jasný, proč se výrobci prohlížečů nemůžou domluvit na nějakém bytecodu+standardizovaném VM typu CLR, aby se konečně toho JS dalo elegantně zbavit bez transpilace...
-
Django nepoužívám, ale limit funguje normálně, joiny přes loop to neprovádí a pro efektivní save jde použít bulk_save. Má to mouchy, proto jsem přešel na SQLAlchemy. Ale to co píšete, není pravda.
O limitu jsem nic nepsal. Problém ORM frameworků je, že si člověk "snadno" kdekoliv v kódu šáhne pro cokoliv jako by to byla lokální proměnná a vůbec neřeší, jak ve skutečnosti budou vypadat ty dotazy, jaká s tím bude režie. V tom je ten ďábel v detailu.
To stejné byste mohl napsat o každé technologii přidávající úroveň abstrakce. Když to používáte správně, ušetří vám to spoustu práce. Zejména pokud dlouhodobě pracujete se složitější databází a provádíte často podobné, ale ne úplně stejné dotazy. Kdybyste měl stále dokola zapisovat ty stejné joiny, tak byste se z toho zbláznil.
-
JS je vzácný příklad jazyka, co není ani "čistý", ani pragmatický.
JS byl celkem pragmatický a relativně OK ve svém původním účelu: jednořádkový handler kliknutí někam. Že se z něj pak stal jazyk, ve kterém se budují dnešní webové jaderné elektrárny, je jiná věc, spíš historická nahodilost.
Mně spíš doteď není jasný, proč se výrobci prohlížečů nemůžou domluvit na nějakém bytecodu+standardizovaném VM typu CLR, aby se konečně toho JS dalo elegantně zbavit bez transpilace...
Ona ta transpilace do JS nevadí, transpiler si většinou nestěžuje, že musí generovat prasokód (pokud to je program, ne nějaký Ind).
-
Každých 10 let se v Berlíně setkají největší zlouni světa domlouvají se, jak uškodit lidstvu.
"Vyhodíme do povětří Eiffelovu věž"
"Ne, mám něco lepšího, otrávíme všechny obyvatele Moskvy"
"Ne, to je nic. Uděláme z Javascriptu objektový jazyk"
-
To stejné byste mohl napsat o každé technologii přidávající úroveň abstrakce. Když to používáte správně, ušetří vám to spoustu práce. Zejména pokud dlouhodobě pracujete se složitější databází a provádíte často podobné, ale ne úplně stejné dotazy. Kdybyste měl stále dokola zapisovat ty stejné joiny, tak byste se z toho zbláznil.
Ne. Problém není v abstrakci, problém je v abstrakci takového typu, že spousta jejich uživatelů nedokáže sestoupit o úroveň níž a říct, co přesně tohle udělá. Čili efektivně ztratí schopnost uvažovat nad vlastním kódem, což je ten problém.
Např. parametrizovaná fce, která zastupuje nějaký složitější dotaz, který ale má konkrétní účel a konkrétní, všem známou formu, je úplně v pohodě. To je abstrakce úplně jiného typu než když mám třeba ultramagický proxy objekt, který teprve při přístupu k atributu tahá data z DB, nikdo neví v jakém rozsahu a jak často, jakými joiny, s jakými náklady...
-
Javascript je čitelnější než Lisp. JSON, CSS a HTML jsou čitelnější než s-expressions. Lisp měl smysl v sedmdesátých letech, kdy jiné jazyky neumožňovaly zápis složitějších struktur a interaktivní použití. Javascript to umožňuje a IMHO lépe.
Javascript je krutá pomsta. Nevím koho, nevím komu, ale opravdu krutá. Nebo něčí odporný žert. Používat ho na skriptování nějakých animací na webu, dejme tomu, ale aplikační jazyk? Proboha. Už jen to doporučované formátování, dávat bracket na stejný řádek jako function nebo if, to je zjevně něčí zlý úmysl.
Jazyky se dají hodnotit podle (akademické) čistoty a pragmatičnosti. Takový Haskell je až matematicky "čistý", ale nepříliš pragmatický. Go je třeba naopak vysoce pragmatické, ale na teorii CS zvysoka - ehm - kašle. JS je vzácný příklad jazyka, co není ani "čistý", ani pragmatický. Fakt je to pomsta :) nebo rafinovaný nástroj k odhalování trotlů (IF likes Javascript THEN is thicko) ;)
co je v tomto kontextu "pragmatičnost"?
-
Ona ta transpilace do JS nevadí, transpiler si většinou nestěžuje, že musí generovat prasokód (pokud to je program, ne nějaký Ind).
To ne, ale zbytečně to transpiler limituje a dává (nejspíš) o hodně nižší výkon. Zbytečně se řeší úplně zbytečná dilemmata typu "mám generovat čitelný JS (PureScript) nebo pohodlný/efektivní JS (Elm)" atd. atd.
-
Ona ta transpilace do JS nevadí, transpiler si většinou nestěžuje, že musí generovat prasokód (pokud to je program, ne nějaký Ind).
To ne, ale zbytečně to transpiler limituje a dává (nejspíš) o hodně nižší výkon. Zbytečně se řeší úplně zbytečná dilemmata typu "mám generovat čitelný JS (PureScript) nebo pohodlný/efektivní JS (Elm)" atd. atd.
Možná, ale JS na serveru je krávovina a v prohlížeči už to může být jedno, navíc Safari, Chrome etc. mají poměrně rychlý JS.
-
Javascript je čitelnější než Lisp. JSON, CSS a HTML jsou čitelnější než s-expressions. Lisp měl smysl v sedmdesátých letech, kdy jiné jazyky neumožňovaly zápis složitějších struktur a interaktivní použití. Javascript to umožňuje a IMHO lépe.
Javascript je krutá pomsta. Nevím koho, nevím komu, ale opravdu krutá. Nebo něčí odporný žert. Používat ho na skriptování nějakých animací na webu, dejme tomu, ale aplikační jazyk? Proboha. Už jen to doporučované formátování, dávat bracket na stejný řádek jako function nebo if, to je zjevně něčí zlý úmysl.
Jazyky se dají hodnotit podle (akademické) čistoty a pragmatičnosti. Takový Haskell je až matematicky "čistý", ale nepříliš pragmatický. Go je třeba naopak vysoce pragmatické, ale na teorii CS zvysoka - ehm - kašle. JS je vzácný příklad jazyka, co není ani "čistý", ani pragmatický. Fakt je to pomsta :) nebo rafinovaný nástroj k odhalování trotlů (IF likes Javascript THEN is thicko) ;)
co je v tomto kontextu "pragmatičnost"?
"[A]n approach that evaluates theories or beliefs in terms of the success of their practical application."
Člověk by řekl, že to bude jedna škála se dvěma protipóly, ale "díky" JS to jsou dvě nezávislé veličiny.
-
Javascript je čitelnější než Lisp. JSON, CSS a HTML jsou čitelnější než s-expressions. Lisp měl smysl v sedmdesátých letech, kdy jiné jazyky neumožňovaly zápis složitějších struktur a interaktivní použití. Javascript to umožňuje a IMHO lépe.
Javascript je krutá pomsta. Nevím koho, nevím komu, ale opravdu krutá. Nebo něčí odporný žert. Používat ho na skriptování nějakých animací na webu, dejme tomu, ale aplikační jazyk? Proboha. Už jen to doporučované formátování, dávat bracket na stejný řádek jako function nebo if, to je zjevně něčí zlý úmysl.
Stejné formátování se používá i v Javě. Když takový kód nedokážete číst, tak hledejte chybu na sebě a ne v JS.
-
oprava
Javascript je čitelnější než Lisp. JSON, CSS a HTML jsou čitelnější než s-expressions. Lisp měl smysl v sedmdesátých letech, kdy jiné jazyky neumožňovaly zápis složitějších struktur a interaktivní použití. Javascript to umožňuje a IMHO lépe.
Javascript je krutá pomsta. Nevím koho, nevím komu, ale opravdu krutá. Nebo něčí odporný žert. Používat ho na skriptování nějakých animací na webu, dejme tomu, ale aplikační jazyk? Proboha. Už jen to doporučované formátování, dávat bracket na stejný řádek jako function nebo if, to je zjevně něčí zlý úmysl.
Stejné formátování se používá i v Javě. Když takový kód nedokážete číst, tak hledejte chybu na sobě a ne v JS.
-
Stejné formátování se používá i v Javě. Když takový kód nedokážete číst, tak hledejte chybu na sobě a ne v JS.
To je jako vypíchnout svému dítěti oči, aby bylo psychicky silnější.
-
Možná, ale JS na serveru je krávovina a v prohlížeči už to může být jedno, navíc Safari, Chrome etc. mají poměrně rychlý JS.
JS jako jazyk samozřejmě. Ale pokud bys měl v prohlížeči nějaký rozumný, dobře definovaný a standardizovaný jakožeCLR, i to rozdělení na backend a frontend by se dělalo příjemněji (polovina problémů webovýho programování se nějak týká komunikace BE-FE, serializace, převodu do toho dementně-omezenýho-JSONu atd.)
Jako ne, že by to v současnosti nešlo (viz Node, ClojureScript, ...), ale obávám se, že se strašný množství lidské energie pálí na řešení totálně zbytečných problémů, který by vůbec nemusely být, kdyby se webový svět dokázal rozumně domluvit a nepoužíval se všude jenom nejmenší-společná-podmnožina-shitu-která-jakžtakž-funguje :)
-
JS jako jazyk samozřejmě. Ale pokud bys měl v prohlížeči nějaký rozumný, dobře definovaný a standardizovaný jakožeCLR
https://en.wikipedia.org/wiki/WebAssembly ?
-
Stejné formátování se používá i v Javě. Když takový kód nedokážete číst, tak hledejte chybu na sobě a ne v JS.
To je jako vypíchnout svému dítěti oči, aby bylo psychicky silnější.
Píšete také někdy příspěvky k tématu?
-
Píšete také někdy příspěvky k tématu?
Téma už je vyčerpané.
-
co je v tomto kontextu "pragmatičnost"?
"[A]n approach that evaluates theories or beliefs in terms of the success of their practical application."
Člověk by řekl, že to bude jedna škála se dvěma protipóly, ale "díky" JS to jsou dvě nezávislé veličiny.
tak to bych asi haskell nepragmatickým nenazval, ze své zkušenosti, pokud nepragmatický zároveň neznamená nepopulární
-
https://en.wikipedia.org/wiki/WebAssembly ?
No ale to je typicky webový narovnávák na ohýbák. To je asi jako mít na mašině hypervizor, v něm OS s VirtualBoxem, v něm Xen a nad ním emulátor Androidu :)
-
Možná, ale JS na serveru je krávovina a v prohlížeči už to může být jedno, navíc Safari, Chrome etc. mají poměrně rychlý JS.
JS jako jazyk samozřejmě. Ale pokud bys měl v prohlížeči nějaký rozumný, dobře definovaný a standardizovaný jakožeCLR, i to rozdělení na backend a frontend by se dělalo příjemněji (polovina problémů webovýho programování se nějak týká komunikace BE-FE, serializace, převodu do toho dementně-omezenýho-JSONu atd.)
Jako ne, že by to v současnosti nešlo (viz Node, ClojureScript, ...), ale obávám se, že se strašný množství lidské energie pálí na řešení totálně zbytečných problémů, který by vůbec nemusely být, kdyby se webový svět dokázal rozumně domluvit a nepoužíval se všude jenom nejmenší-společná-podmnožina-shitu-která-jakžtakž-funguje :)
Pravda, ale oba víme, že to je utopie :(
-
Pravda, ale oba víme, že to je utopie :(
Těžko říct. Dneska, když už je MS víceméně ze hry, by se Mozilla Foundation s Googlem a Applem třeba domluvit mohli ;)
-
co je v tomto kontextu "pragmatičnost"?
"[A]n approach that evaluates theories or beliefs in terms of the success of their practical application."
Člověk by řekl, že to bude jedna škála se dvěma protipóly, ale "díky" JS to jsou dvě nezávislé veličiny.
tak to bych asi haskell nepragmatickým nenazval, ze své zkušenosti, pokud nepragmatický zároveň neznamená nepopulární
Možná pod to taky spadá, že průměrný Pepa kodér se těžko Haskell v použitelné podobě naučí.
-
To stejné byste mohl napsat o každé technologii přidávající úroveň abstrakce. Když to používáte správně, ušetří vám to spoustu práce. Zejména pokud dlouhodobě pracujete se složitější databází a provádíte často podobné, ale ne úplně stejné dotazy. Kdybyste měl stále dokola zapisovat ty stejné joiny, tak byste se z toho zbláznil.
Ne. Problém není v abstrakci, problém je v abstrakci takového typu, že spousta jejich uživatelů nedokáže sestoupit o úroveň níž a říct, co přesně tohle udělá. Čili efektivně ztratí schopnost uvažovat nad vlastním kódem, což je ten problém.
Např. parametrizovaná fce, která zastupuje nějaký složitější dotaz, který ale má konkrétní účel a konkrétní, všem známou formu, je úplně v pohodě. To je abstrakce úplně jiného typu než když mám třeba ultramagický proxy objekt, který teprve při přístupu k atributu tahá data z DB, nikdo neví v jakém rozsahu a jak často, jakými joiny, s jakými náklady...
Stejnou vlastnost považujete v haskellu za výhodu.
-
Stejnou vlastnost považujete v haskellu za výhodu.
Ani ne. Zrovna nedávno jsem tady psal, že na Haskellu moc nemám rád příliš moc vrstev abstrakce, které běžnému Frantovi programátorovi zatemňují schopnost říct, co doopravdy kód dělá. Třeba taková do notace mi přijde jako spíš ke škodě než k užitku.
Haskell podle mě pro běžného Frantu moc není. Daleko lepší je pro něj imho Elm. Stačilo by ho jenom maličko posunout směrem k silnějším abstrakcím, ale ne tolik jako Haskell.
-
Pravda, ale oba víme, že to je utopie :(
Těžko říct. Dneska, když už je MS víceméně ze hry, by se Mozilla Foundation s Googlem a Applem třeba domluvit mohli ;)
Takhle to nefunguje. Musí přijít někdo s něčím novým, co převrátí trh a udělá jakoukoliv dohodu těch starých dinosaurů zbytečnou a zastaralou.
-
Mně spíš doteď není jasný, proč se výrobci prohlížečů nemůžou domluvit na nějakém bytecodu+standardizovaném VM typu CLR, aby se konečně toho JS dalo elegantně zbavit bez transpilace...
Rovnou javu by si nechtel ? :D JavaScript je uplne v pohode protoze je pomerne jednoduchy. To ze v zakladu toho moc neumi je spise vyhodou, nemas kanon na vrabce. A protoze je vypocetne kompletni tak mas moznost v nem zrealizovat vse, i kdyz nekdy za cenu design patternu. Proto tech kanon-js-frameworku mame spoustu, staci si vybrat dle sve chuti nebo aktualni mody. JS je v zasade event driven, nonblocking, nepadne striktne na hubu pri kde jake chybe, maximalne utne vlakno. A hlavne umi delit nulou! 8)
-
Pravda, ale oba víme, že to je utopie :(
Těžko říct. Dneska, když už je MS víceméně ze hry, by se Mozilla Foundation s Googlem a Applem třeba domluvit mohli ;)
Takhle to nefunguje. Musí přijít někdo s něčím novým, co převrátí trh a udělá jakoukoliv dohodu těch starých dinosaurů zbytečnou a zastaralou.
Nechtěl byste se raději naučit alespoň základy JS? Možná byste zjistil, že to není tak špatné, aby to bylo nutné nahrazovat.
-
Rovnou javu by si nechtel ?
Javu ne, ale něco na způsob JVM jo.
To ze v zakladu toho moc neumi je spise vyhodou
Ne, není. Nejlíp je to vidět na JSONu, ze kterého se bohužel stala lingua franca. Všichni trávíme tuny času tím, že svoje bohaté datové struktury horko těžko serializujeme do formátu, který neumí spolehlivě odlišit ani int a float. A s JS je to podobný. Transpilovat slušné jazyky do podmnožiny shitu je ztráta času.
Nechtěl byste se raději naučit alespoň základy JS? Možná byste zjistil, že to není tak špatné, aby to bylo nutné nahrazovat.
Tak rozhodně musím kvitovat, že jste se mnou nikdy nepracoval, ani mě neviděl, ale přesně víte, co neumím. Nechcete po 11té na Nově předpovídat lidem budoucnost?
-
https://en.wikipedia.org/wiki/WebAssembly ?
No ale to je typicky webový narovnávák na ohýbák.
co se vám na tom nelíbí? nemám to nastudováno, prakticky jenom vím, že to existuje, ale zdá se to jako docela výrazné zlepšení proti js
-
Nechtěl byste se raději naučit alespoň základy JS? Možná byste zjistil, že to není tak špatné, aby to bylo nutné nahrazovat.
Tak rozhodně musím kvitovat, že jste se mnou nikdy nepracoval, ani mě neviděl, ale přesně víte, co neumím. Nechcete po 11té na Nově předpovídat lidem budoucnost?
To nebyla reakce na vás.
-
co se vám na tom nelíbí? nemám to nastudováno, prakticky jenom vím, že to existuje, ale zdá se to jako docela výrazné zlepšení proti js
Nelíbí se mi na tom to, že to je nad asm.js. Což je přesně ta "jakžtakž použitelná podmnožina shitu".
-
co se vám na tom nelíbí? nemám to nastudováno, prakticky jenom vím, že to existuje, ale zdá se to jako docela výrazné zlepšení proti js
Nelíbí se mi na tom to, že to je nad asm.js. Což je přesně ta "jakžtakž použitelná podmnožina shitu".
Tady bych nebyl zas tak ostry. Ta podmnozina je vybrana tak, ze to dava (zda se) celkem rozumny bytecode. Ma sice hodne mizernou serializaci, ale to neni zas takova tragedie - prida to data na prenos, parsovani neni tak snadne, jak by mohlo byt, ale beh a optimalizace uz budou cajk.
-
Tady bych nebyl zas tak ostry. Ta podmnozina je vybrana tak, ze to dava (zda se) celkem rozumny bytecode. Ma sice hodne mizernou serializaci, ale to neni zas takova tragedie - prida to data na prenos, parsovani neni tak snadne, jak by mohlo byt, ale beh a optimalizace uz budou cajk.
No a kdyby se z toho to JS vyhodilo a zůstal jenom rozumný VM, byli bysme tam, kde bych svět rád viděl :)
-
Tady bych nebyl zas tak ostry. Ta podmnozina je vybrana tak, ze to dava (zda se) celkem rozumny bytecode. Ma sice hodne mizernou serializaci, ale to neni zas takova tragedie - prida to data na prenos, parsovani neni tak snadne, jak by mohlo byt, ale beh a optimalizace uz budou cajk.
No a kdyby se z toho to JS vyhodilo a zůstal jenom rozumný VM, byli bysme tam, kde bych svět rád viděl :)
Ano. Ale clovek ocividne nemuze chtit vsechno :-/
-
Tady bych nebyl zas tak ostry. Ta podmnozina je vybrana tak, ze to dava (zda se) celkem rozumny bytecode. Ma sice hodne mizernou serializaci, ale to neni zas takova tragedie - prida to data na prenos, parsovani neni tak snadne, jak by mohlo byt, ale beh a optimalizace uz budou cajk.
No a kdyby se z toho to JS vyhodilo a zůstal jenom rozumný VM, byli bysme tam, kde bych svět rád viděl :)
S tím se v budoucnu počítá. Webassembly není asm.js.
asm.js už dnes funguje celkem dobře. Třeba emulaci starých her zvládá bez problémů.
-
asm.js už dnes funguje celkem dobře. Třeba emulaci starých her zvládá bez problémů.
Jiste no. Emulator Androidu na Xenu ve VirtualBoxu na bare metal hypervisoru by taky nejspis zvladl spustit Dooma ;)
-
Tady bych nebyl zas tak ostry. Ta podmnozina je vybrana tak, ze to dava (zda se) celkem rozumny bytecode. Ma sice hodne mizernou serializaci, ale to neni zas takova tragedie - prida to data na prenos, parsovani neni tak snadne, jak by mohlo byt, ale beh a optimalizace uz budou cajk.
No a kdyby se z toho to JS vyhodilo a zůstal jenom rozumný VM, byli bysme tam, kde bych svět rád viděl :)
A bude to umět aspoň vlákna? A nějaký rozumný GC?
-
To ze v zakladu toho moc neumi je spise vyhodou
Ne, není. Nejlíp je to vidět na JSONu, ze kterého se bohužel stala lingua franca. Všichni trávíme tuny času tím, že svoje bohaté datové struktury horko těžko serializujeme do formátu, který neumí spolehlivě odlišit ani int a float. A s JS je to podobný.
WTF? co ma JS s JSONem a vasi neschopnosti prenaset datove struktury spolecne? Co to ma spolecneho s tim, ze neumis flagnout typy? Nahod si websocket na backend a prenasej rovnou relace a delej transakce. Nikdo ti JSON nenuti, pro mne za mne si prenasej textak nebo proprietarni binarku.
-
Nejlíp je to vidět na JSONu, ze kterého se bohužel stala lingua franca. Všichni trávíme tuny času tím, že svoje bohaté datové struktury horko těžko serializujeme do formátu, který neumí spolehlivě odlišit ani int a float. A s JS je to podobný. Transpilovat slušné jazyky do podmnožiny shitu je ztráta času.
Co si představuješ pod pojmem "horko těžko"? Serializace do JSONu je prkotina, tedy alespoň v PHP.
-
Právě Lisp by mohl s přehledem nahradit jak serverovou část, tak i HTML, CSS s Javascriptem dohromady. Jenže uživatelé to chtěli jinak a implementace Lispu se do webových prohlížečů ani nedostala.
Javascript je čitelnější než Lisp. JSON, CSS a HTML jsou čitelnější než s-expressions. Lisp měl smysl v sedmdesátých letech, kdy jiné jazyky neumožňovaly zápis složitějších struktur a interaktivní použití. Javascript to umožňuje a IMHO lépe.
Klient by měl být konstruován tak, že k němu není přímý přístup přes nějaký jazyk, ale jen přes objektový, nebo funkcionální interface. Server by místo povelů pro renderovací jádro v HTML, CSS a javascriptu generoval lispovské seznamy, přímo interpretované lispovým jádrem prohlížeče. Důraz má být kladen na strojovou analýzu, nikoliv na čtení pro lidi. Lisp použitý jako deklarace je čitelnější než kompozit HTML, CSS a javascriptu. Ostatně proto se přechází na JSON, všude, kde to jde.
Komunikace přes API by asi byla dost pomalá. Nakonec byste prohlížeči stejně musel posílat celé programy a dokumenty najednou.
-
Co si představuješ pod pojmem "horko těžko"? Serializace do JSONu je prkotina, tedy alespoň v PHP.
Tak jistě, zavolat json_encode(val) je prkotina. Ale víš přesně, jaké garance ti to dává? Jsi si jistý, že val == json_decode(json_encode(val))? A když ne, víš přesně, kdy ne? Víš, jaký typ ti to dá, když HTTP/JSON API zavoláš z jiného jazyka?
A co s typy, které JSON prostě nemá? Budu z každého atomu dělat {type: "atom", val: "val"} jak debil? Co budu dělat s mapama, kde klíčem je dvojice nebo nedejsladkákálí strom...
-
Ne, není. Nejlíp je to vidět na JSONu, ze kterého se bohužel stala lingua franca. Všichni trávíme tuny času tím, že svoje bohaté datové struktury horko těžko serializujeme do formátu, který neumí spolehlivě odlišit ani int a float. A s JS je to podobný. Transpilovat slušné jazyky do podmnožiny shitu je ztráta času.
Javascript moc nerozlišuje mezi floatem a integerem. Když dekódujete číslo s desetiným místem, logicky chcete float. Když číslo bez desetiného místa, tak vám může být jedno co dostanete.
-
Co si představuješ pod pojmem "horko těžko"? Serializace do JSONu je prkotina, tedy alespoň v PHP.
Tak jistě, zavolat json_encode(val) je prkotina. Ale víš přesně, jaké garance ti to dává? Jsi si jistý, že val == json_decode(json_encode(val))? A když ne, víš přesně, kdy ne? Víš, jaký typ ti to dá, když HTTP/JSON API zavoláš z jiného jazyka?
A co s typy, které JSON prostě nemá? Budu z každého atomu dělat {type: "atom", val: "val"} jak debil? Co budu dělat s mapama, kde klíčem je dvojice nebo nedejsladkákálí strom...
JSON se rozšířil, protože je jednoduchý. Když vám nevyhovuje, alternativy existují.
Jaký je rozdíl mezi atomem a stringem?
Kdybych chtěl jako klíče dvojice, asi bych je zakódoval do JSONu. Není to ideální, ale je to jednoduché a dostačuje to.
-
A co s typy, které JSON prostě nemá? Budu z každého atomu dělat {type: "atom", val: "val"} jak debil?
Budes, protoze jsi zvolil JSON kde typovost neni primarni zalezitost (jako obecne v JS, to jen nejavascriptiste porad neco melou o typech a resej dest castovacich funkci, kdyz chces udelat neco tak trivialniho jako "5" * 5 ). Kdyz jsou u tebe typy smysl vesmiru tak pouzij XML a <item name="smysl vesmiru" typ="int">42</item>...
Proste places na nespravnem hrobe a pouzivas nespravny lopaty :-)
-
Co si představuješ pod pojmem "horko těžko"? Serializace do JSONu je prkotina, tedy alespoň v PHP.
Tak jistě, zavolat json_encode(val) je prkotina. Ale víš přesně, jaké garance ti to dává? Jsi si jistý, že val == json_decode(json_encode(val))? A když ne, víš přesně, kdy ne? Víš, jaký typ ti to dá, když HTTP/JSON API zavoláš z jiného jazyka?
A co s typy, které JSON prostě nemá? Budu z každého atomu dělat {type: "atom", val: "val"} jak debil? Co budu dělat s mapama, kde klíčem je dvojice nebo nedejsladkákálí strom...
Když dáš json_encode($object), tak v něm budeš mít přesně to, co do něj potřebuješ dostat, včetně kolekcí - tedy i map a stromů. Typy samozřejmě také.
-
Co si představuješ pod pojmem "horko těžko"? Serializace do JSONu je prkotina, tedy alespoň v PHP.
Tak jistě, zavolat json_encode(val) je prkotina. Ale víš přesně, jaké garance ti to dává? Jsi si jistý, že val == json_decode(json_encode(val))? A když ne, víš přesně, kdy ne? Víš, jaký typ ti to dá, když HTTP/JSON API zavoláš z jiného jazyka?
A co s typy, které JSON prostě nemá? Budu z každého atomu dělat {type: "atom", val: "val"} jak debil? Co budu dělat s mapama, kde klíčem je dvojice nebo nedejsladkákálí strom...
Když dáš json_encode($object), tak v něm budeš mít přesně to, co do něj potřebuješ dostat, včetně kolekcí - tedy i map a stromů. Typy samozřejmě také.
Zrovna v případě serializace objektů val == json_decode(json_encode(val)) neplatí. Deserializací získáš pole a ne objekt.
-
Když dekódujete číslo s desetiným místem, logicky chcete float. Když číslo bez desetiného místa, tak vám může být jedno co dostanete.
Ne a ne. Jestli se JSON "3.0" vyparsuje jako int nebo float je nedefinované. Naopak zakódovat int 3 jako 3.0 je plně legitimní. Z čeho a jak plyne, že "logicky chci float", to fakt nevím. Od serializačního formátu především chci, abych z něj dostal to, co jsem do něj dal. Pokud to neplatí ani pro základní věc jako číslo, je to prostě debilní serializační formát a není o čem diskutovat.
JSON se rozšířil, protože je jednoduchý. Když vám nevyhovuje, alternativy existují.
Netvrdil jsem, že neexistují.
Kdyz jsou u tebe typy smysl vesmiru
Ne nejsou. Pro mě je smyslem serializace, aby z ní lezlo to, co do ní dám, a nemusel jsem kolem toho dělat milion opiček.
Jaký je rozdíl mezi atomem a stringem?
Asi tak stejný jako mezi stringem a intem.
-
Když dáš json_encode($object), tak v něm budeš mít přesně to, co do něj potřebuješ dostat, včetně kolekcí - tedy i map a stromů. Typy samozřejmě také.
Zrovna v případě serializace objektů val == json_decode(json_encode(val)) neplatí. Deserializací získáš pole a ne objekt.
json_decode(json_encode(val), true) to řeší.
Zapomínáš, že výsledný JSON není určen pro PHP, ale pro Javascript, kterému je to jedno. Pokud potřebuji serializovat pro PHP, použiji funkci serialize(), který však není určen pro Javascript.
JSON prostě není ideální formát, ale je velmi výhodný pro spolupráci s Javascriptem. Z bezpečnostních důvodů není ani vhodné, pokud by se objekt předával do PHP kompletní. Je lepší, pokud se do PHP předává v podobě datového stromu.
-
Django nepoužívám, ale limit funguje normálně, joiny přes loop to neprovádí a pro efektivní save jde použít bulk_save. Má to mouchy, proto jsem přešel na SQLAlchemy. Ale to co píšete, není pravda.
O limitu jsem nic nepsal. Problém ORM frameworků je, že si člověk "snadno" kdekoliv v kódu šáhne pro cokoliv jako by to byla lokální proměnná a vůbec neřeší, jak ve skutečnosti budou vypadat ty dotazy, jaká s tím bude režie. V tom je ten ďábel v detailu.
To stejné byste mohl napsat o každé technologii přidávající úroveň abstrakce. Když to používáte správně, ušetří vám to spoustu práce. Zejména pokud dlouhodobě pracujete se složitější databází a provádíte často podobné, ale ne úplně stejné dotazy. Kdybyste měl stále dokola zapisovat ty stejné joiny, tak byste se z toho zbláznil.
Od toho existuje view.
ORM mapper je omezeny na tupy CRUD. Treba Oracle MERGE s tim nezavolam.
Osobne nechapu tu nechut lidi kolem javy se naucit rozumne SQL, vzdyt je to tak jednoducha zalezitost.
Je jednodussi se naucit zaklady Oracle PLSQL nez se naucit BEZPECNE delat v Hibernate.
-
Jaký je rozdíl mezi atomem a stringem?
Asi tak stejný jako mezi stringem a intem.
Jaký je praktický rozdíl mezi atomy v erlangu a immutable stringy v jiných jazycích?
-
Jaký je praktický rozdíl mezi atomy v erlangu a immutable stringy v jiných jazycích?
Pokud by ty immutable stringy byly uložené v paměti jenom jednou a vždycky a všude by byly používány jenom reference (včetně toho, že když vytvořím nový string, podívám se, jestli už ho v paměti nemám), tak by to bylo prakticky totéž. Atom je v Erlangu reference do "atoms table" - velikost 1 slovo.
Nicméně v tom kontextu, o kterém se bavíme, jde o to, že to typově není ani string ani int - tj. potřebuju explicitně vědět, že tuhle hodnotu mám načíst jako atom. Rozumné serializační formáty umí uživatelské typy, takže to tam není problém snadno a čistě doplnit (pokud formát sám o sobě atomy neumí, což většinou neumí). JSON nic takového nemá. Musím si udělat vlastní proprietární formát nad formátem, úplně zbytečně.
-
Od toho existuje view.
ORM mapper je omezeny na tupy CRUD. Treba Oracle MERGE s tim nezavolam.
Osobne nechapu tu nechut lidi kolem javy se naucit rozumne SQL, vzdyt je to tak jednoducha zalezitost.
Je jednodussi se naucit zaklady Oracle PLSQL nez se naucit BEZPECNE delat v Hibernate.
Mám podezření, že lidé kolem Javy (i jiných jazyků) jsou přesvědčeni, že to naprogramují lépe a kvalitněji, než kdyby to udělali v nativním SQL. Ještě horší to bývá s vloženými procedurami, funkcemi a triggery. Někdo před nimi na tom pohořel a teď jim vnucuje do hlav, že tyto schopnosti databází jsou špatné.
-
Jaký je rozdíl mezi atomem a stringem?
Asi tak stejný jako mezi stringem a intem.
Jaký je praktický rozdíl mezi atomy v erlangu a immutable stringy v jiných jazycích?
tak trebas to ze je to neco uplne jinyho
-
Osobne nechapu tu nechut lidi kolem javy se naucit rozumne SQL, vzdyt je to tak jednoducha zalezitost.
Je jednodussi se naucit zaklady Oracle PLSQL nez se naucit BEZPECNE delat v Hibernate.
Je to jiny jazyk s jinou filozofii, proto ta nechut. Ja jsem podobne snazil par Javistum vysvetlit, at si k pochopeni FP nastuduji Haskell spise nez Scalu nebo Java 8 streamy, ale taky jsem vesmes nepochodil. :-)
-
Jaký je rozdíl mezi atomem a stringem?
Asi tak stejný jako mezi stringem a intem.
Jaký je praktický rozdíl mezi atomy v erlangu a immutable stringy v jiných jazycích?
tak trebas to ze je to neco uplne jinyho
V čem konkrétně je to jiné kromě chybějících uvozovek? Dokázal byste uvést příklad použití atomu, pro který nelze použít string?
-
Jaký je praktický rozdíl mezi atomy v erlangu a immutable stringy v jiných jazycích?
Pokud by ty immutable stringy byly uložené v paměti jenom jednou a vždycky a všude by byly používány jenom reference (včetně toho, že když vytvořím nový string, podívám se, jestli už ho v paměti nemám), tak by to bylo prakticky totéž. Atom je v Erlangu reference do "atoms table" - velikost 1 slovo.
přesně tak Python ukládá všechny hodnoty. Nejen stringy, ale například i tuple.
-
V čem konkrétně je to jiné kromě chybějících uvozovek? Dokázal byste uvést příklad použití atomu, pro který nelze použít string?
To je jako byste se ptal na příklad použití enumu, pro který nelze použít string.
-
O limitu jsem nic nepsal. Problém ORM frameworků je, že si člověk "snadno" kdekoliv v kódu šáhne pro cokoliv jako by to byla lokální proměnná a vůbec neřeší, jak ve skutečnosti budou vypadat ty dotazy, jaká s tím bude režie. V tom je ten ďábel v detailu.
Ale to je přece přímým důsledkem skutečnosti, že podstaty objektů a relací jsou natolik rozdílné, že převody mezi nimi jsou složité. RDB se na objekty nehodí, MNOHEM vhodnější pro objekty jsou dokumentové DB.
-
O limitu jsem nic nepsal. Problém ORM frameworků je, že si člověk "snadno" kdekoliv v kódu šáhne pro cokoliv jako by to byla lokální proměnná a vůbec neřeší, jak ve skutečnosti budou vypadat ty dotazy, jaká s tím bude režie. V tom je ten ďábel v detailu.
To se dá ale ošetřit, taková db4o měla svého času konfigurovatelná omezení (není to ORM, ale čistě objektová databáze, což je zde ovšem irelevantní). Navíc když je někdo pablb, tak zprasí dotazy do DB i bez ORM.
Jistě, vysvětlovat řešení problému RDB na ODB je velice přínosné.
-
O limitu jsem nic nepsal. Problém ORM frameworků je, že si člověk "snadno" kdekoliv v kódu šáhne pro cokoliv jako by to byla lokální proměnná a vůbec neřeší, jak ve skutečnosti budou vypadat ty dotazy, jaká s tím bude režie. V tom je ten ďábel v detailu.
To stejné byste mohl napsat o každé technologii přidávající úroveň abstrakce. Když to používáte správně, ušetří vám to spoustu práce. Zejména pokud dlouhodobě pracujete se složitější databází a provádíte často podobné, ale ne úplně stejné dotazy. Kdybyste měl stále dokola zapisovat ty stejné joiny, tak byste se z toho zbláznil.
Asi tak. Problémem je především skutečnost, že p. Prýmek považuje použití ORM (což je logické, jinak by aplikace musela zůstat relační) za chybu, ale použití RDB na objektovou doménu mu přijde zcela v pořádku.
-
Ona ta transpilace do JS nevadí, transpiler si většinou nestěžuje, že musí generovat prasokód (pokud to je program, ne nějaký Ind).
Je to vrstva navíc přidávající práci, chyby atd. Nadbytečné.
-
Asi tak. Problémem je především skutečnost, že p. Prýmek považuje použití ORM (což je logické, jinak by aplikace musela zůstat relační) za chybu, ale použití RDB na objektovou doménu mu přijde zcela v pořádku.
Ne. Já považuju za chybu používat jakoukoli knihovnu/framework/abstrakci, která je natolik složitá a neprůhledná, že programátor nedokáže pohledem na kód říct, co vlastně v danou chvíli udělá, a zároveň má potenciálně velmi zásadní vliv na výkon aplikace.
Můžu přidat i osobní zkušenost: v jednom projektu byla komponenta provádějící jakýsi relativně jednoduchý (kontextem parametrizovaný) výpočet nad daty přicházejícímu z vnějšku. Kdyby to dělal člověk ručně, načte si z DB předem cca pět čísel jedním dotazem a pak spustí výpočet, už kompletně bez side effectů, čili snadno paralelizovatelný atd. Ovšem historie tomu chtěla, že danou komponentu psal djangista, čili konfigurace byla uložena pomocí django ORM, načítala se pomocí nějakých magických django objektů a když to bylo v provozu, lámali jsme si hlavu nad tím, proč tak děsně zatěžuje DB. No, nenačítalo se pět čísel, ale nějaké modely, ORM se z nějakého důvodu rozhodl, že k tomu potřebuje i nějaké související hodnoty, takže se ve finále pořádně košatým JOINem načítalo i spousta věcí, které pro výpočet vůbec nebyly potřeba, a to ještě vesele kdykoli jakkoli, třeba uprostřed výpočtu. Nekontrolovatelně. Nádhera...
(Nechci se hádat o to, jestli tahle konkrétní situace jde nebo nejde v Djangu nějak potunit, pointa je v tom, že místo aby se udělala jednoduchá DB s jasnou strukturou a jednoduché SQL dotazy, kterým by každý rozuměl a uměl je ladit, použil se "pohodlný nástroj", který ve finále aplikaci úplně zabil)
-
Když už se tu začlo s ORM vs. RDB, proč v OO jazyce nepoužít přímo nějakou čistě objektovou databázi?
-
Když už se tu začlo s ORM vs. RDB, proč v OO jazyce nepoužít přímo nějakou čistě objektovou databázi?
a vo cem by se pak jako tady psalo?
-
Když už se tu začlo s ORM vs. RDB, proč v OO jazyce nepoužít přímo nějakou čistě objektovou databázi?
ORM, ElasticSearch nebo objektove databaze maji smysl, kdy je potreba ukladat male mnozstvi dat aplikace, napr pro ukladani konfigurace si user preferences.
Pokud ale aplikace ma zpracovavat vetsim mnozstvim externich dat, typicky treba generovani PDF faktur z databaze CRM systemu, pak je ORM totalne k hounu a dokaze zabit cely projekt. Externi data se typicky v objektove podobe nevyskytuji.
Kdyz architekt pak do projektu tupe nacpe ORM, protoze tak tomu bylo v tutorialu "Pet Shop", vysledek je otres.
-
Když už se tu začlo s ORM vs. RDB, proč v OO jazyce nepoužít přímo nějakou čistě objektovou databázi?
Běžně používám i objektové databáze a nevidím v tom problém. Při správném návrhu bývají o 2 řády výkonnější než běžný paskvil ORM+RDB.
-
Pojem databaze je jeden z nejvetsich pruseru v IT vubec
-
V čem konkrétně je to jiné kromě chybějících uvozovek? Dokázal byste uvést příklad použití atomu, pro který nelze použít string?
To je jako byste se ptal na příklad použití enumu, pro který nelze použít string.
Když použiju nedefinovaný atom, tak se vytvoří nový. To je chování stringu a ne enumu.
-
V čem konkrétně je to jiné kromě chybějících uvozovek? Dokázal byste uvést příklad použití atomu, pro který nelze použít string?
To je jako byste se ptal na příklad použití enumu, pro který nelze použít string.
Když použiju nedefinovaný atom, tak se vytvoří nový. To je chování stringu a ne enumu.
Surova naprosto odzbrojujici uvaha pri niz clovek ztvrdne jako kamen naprosto - paralizovan. Vypalena jako kulka - znicujici. Neposkutuje moznost obrany - bez odpovedi. Proste tohle presne dokaze vyvolat to prave ticho.
-
Když použiju nedefinovaný atom, tak se vytvoří nový. To je chování stringu a ne enumu.
Jiste, kazde prirovnani v necem kulha.
Ze je atom v principu imutabilni, deduplikovany string, jsem uz napsal. Pokud chcete, muzete si atomy v libovolnem jazyce takhle implementovat. Ale tak jako tak to bude jiny typ nez string a budete se k nemu muset chovat jinak (kdyz prijde treba po siti, musite atom deduplikovat, string nemusite a v mnoha pripadech ani nemuzete). Cili je potreba je odlisit a JSON k tomu nedava zadny nastroj, narozdil od poradnych serializacnich formatu. Cili skoncite u "formatu nad formatem", napriklad takto:
{
"atom": {"type": "atom", value: "my_atom"},
"string": "myString"
}
Pokud chcete dobrou serializaci, musite totez udelat i pro int a float. A porad jeste nemate vyhrano, porad tady mame problem map s klici, ktere JSON nepodporuje. Takze tu budete muset pro zmenu implementovat nejspis jako
{"type": "general_map", "key_type": "...", value: [[..,..],[..,..]]
}
...coz je proste na palici. Ergo JSON je proste se skripenim zubu zkousnutelny pro jednoduche veci, ale jako obecny serializacni format je to peklo. A nechapu, proc opet musite krecovite obhajovat neobhajitelne...
-
Když použiju nedefinovaný atom, tak se vytvoří nový. To je chování stringu a ne enumu.
Jiste, kazde prirovnani v necem kulha.
Ze je atom v principu imutabilni, deduplikovany string, jsem uz napsal. Pokud chcete, muzete si atomy v libovolnem jazyce takhle implementovat. Ale tak jako tak to bude jiny typ nez string a budete se k nemu muset chovat jinak (kdyz prijde treba po siti, musite atom deduplikovat, string nemusite a v mnoha pripadech ani nemuzete). Cili je potreba je odlisit a JSON k tomu nedava zadny nastroj, narozdil od poradnych serializacnich formatu. Cili skoncite u "formatu nad formatem", napriklad takto:
{
"atom": {"type": "atom", value: "my_atom"},
"string": "myString"
}
Pokud chcete dobrou serializaci, musite totez udelat i pro int a float. A porad jeste nemate vyhrano, porad tady mame problem map s klici, ktere JSON nepodporuje. Takze tu budete muset pro zmenu implementovat nejspis jako
{"type": "general_map", "key_type": "...", value: [[..,..],[..,..]]
}
...coz je proste na palici. Ergo JSON je proste se skripenim zubu zkousnutelny pro jednoduche veci, ale jako obecny serializacni format je to peklo. A nechapu, proc opet musite krecovite obhajovat neobhajitelne...
deduplikace proběhne automaticky.
JSON dnes jde otevřít v každém jazyku. Když chcete ukládat data specifická pro Erlang, můžete rovnou použít serializovaný Erlang.
-
Když chcete ukládat data specifická pro Erlang, můžete rovnou použít serializovaný Erlang.
A to je napad! To me nenapadlo. Cili vlastne JSON je skvely serializacni format, protoze kdyz neco neumi, muzu pouzit jiny format.
Genialni!
-
A porad jeste nemate vyhrano, porad tady mame problem map s klici, ktere JSON nepodporuje.
Mapu muzes porad jednoduse spreadnout do pole a nestratis nic. To ze neco JS/JSON neumi, neznamena ze to nejde nebo, ze to je slozity implementovat.
var map = new Map([
['FOOTBALL_TEAM_NAME', 'FC Barcelona'],
['FOOTBALL_TEAM_NICK', 'Barca'],
['FOOTBALL_TEAM_ABBR', 'FCB'],
]);
// Map(3) {"FOOTBALL_TEAM_NAME" => "FC Barcelona", "FOOTBALL_TEAM_NICK" => "Barca", "FOOTBALL_TEAM_ABBR" => "FCB"}
var json = JSON.stringify([...map])
var map2 = new Map(JSON.parse(json))
// Map(3) {"FOOTBALL_TEAM_NAME" => "FC Barcelona", "FOOTBALL_TEAM_NICK" => "Barca", "FOOTBALL_TEAM_ABBR" => "FCB"}
map2.get("FOOTBALL_TEAM_ABBR")
// "FCB"
-
Mapu muzes porad jednoduse spreadnout do pole a nestratis nic. To ze neco JS/JSON neumi, neznamena ze to nejde nebo, ze to je slozity implementovat.
Jasny. A muzu to implementovat treba takhle:
var json = '"BINARY"';
pricemz BINARY jsou data zakodovana pomoci Apache Thrift.
A pak ze JSON neco neumi! Vsichni jste volove, JSON je super a JavaScript dobude cely svet!
-
Když chcete ukládat data specifická pro Erlang, můžete rovnou použít serializovaný Erlang.
A to je napad! To me nenapadlo. Cili vlastne JSON je skvely serializacni format, protoze kdyz neco neumi, muzu pouzit jiny format.
Genialni!
Použití nejjednoduššího dostačujícího řešení je normální přístup. U složitějších formátů musíte řešit problémy neúplných a zabugovaných parserů. Přidání balastu snižuje čitelnost. Každý jazyk má jiné datové typy. Složité formáty existují. Nic vám nebrání je používat. Vy chcete vnucovat ostatním, něco co nepotřebují?
-
var map = new Map([
['FOOTBALL_TEAM_NAME', 'FC Barcelona'],
['FOOTBALL_TEAM_NICK', 'Barca'],
['FOOTBALL_TEAM_ABBR', 'FCB'],
]);
Trocha normalizace by neuškodila:
var footballTeam = new Map([
['NAME', 'FC Barcelona'],
['NICK', 'Barca'],
['ABBR', 'FCB'],
]);
I přes tohle zjednodušení má XML se svým stručnějším a přitom úplnějším zápisem stále navrch.
-
var map = new Map([
['FOOTBALL_TEAM_NAME', 'FC Barcelona'],
['FOOTBALL_TEAM_NICK', 'Barca'],
['FOOTBALL_TEAM_ABBR', 'FCB'],
]);
Trocha normalizace by neuškodila:
var footballTeam = new Map([
['NAME', 'FC Barcelona'],
['NICK', 'Barca'],
['ABBR', 'FCB'],
]);
I přes tohle zjednodušení má XML se svým stručnějším a přitom úplnějším zápisem stále navrch.
Ja uz sem se uplne ztratil - nevim o cem se bavite, co myslite vazne, co ironicky co ikonicky - za me zasadni ze kdyz neco neni a ja to vytvorim tak že to je - kite znormalizuj to prosim - strejda zboj to potom shrne do jedne indianske poucky tim bychom mohli toto vlakno ukoncit a vytvorit Nove
-
Vy chcete vnucovat ostatním, něco co nepotřebují?
Ano. A taky znasilnuji krecky svazane lepici paskou. Oboje vyplyva z toho, co jsem psal, ze.
-
Vy chcete vnucovat ostatním, něco co nepotřebují?
Ano. A taky znasilnuji krecky svazane lepici paskou. Oboje vyplyva z toho, co jsem psal, ze.
Proc delas takove veci Mirku?
-
Proc delas takove veci Mirku?
Ty chceš vnucovat ostatním, něco co nepotřebují?
-
Kdyz binarni format tak je to obalovat JSONem zbytecne, napriklad takhle:
(https://s21.postimg.org/yjifr3qp3/map.png)
(sorry za obrazek, forum emoji nebere)
-
Kdyz binarni format tak je to obalovat JSONem zbytecne, napriklad takhle:
Zjevně jsi nepochopil pointu: než použít formát, který spoustu věcí neumí, a nad ním si stavět jakýsi vlastní nestandardní formát, který to umí, je rovnou lepší použít standardní formát, který to všechno umí (je jich hromada).
...a celý tenhle cirkus se odvinul od toho, že jsem řekl, že stavět jazyk nad JS přes transpiler je stejně zhovadilý jako stavět vlastní formát nad JSONem - v obou případech je tam to JS/JSON zcela zbytná vrstva, která vnáší jenom zmatek a komplikace.
Už si rozumíme?
-
No nerozumime, ja myslel ze srandicky a ty to beres vazne.
Kdyz chces typovost a presny interface tak klidne WSDL/SOAP a ne REST/JSON. Jiny hrebik, jine kladivo. JSON je uplne v pohode na 90% veci co web resi, a kdyz potrebujes neco sofistikovanjesiho tak mas na vyber kde co.
-
Kdyz chces typovost a presny interface tak klidne WSDL/SOAP a ne REST/JSON. Jiny hrebik, jine kladivo. JSON je uplne v pohode na 90% veci co web resi, a kdyz potrebujes neco sofistikovanjesiho tak mas na vyber kde co.
Takže pořád ještě nepochopil. No co se dá dělat...
-
No neudelas nic, protoze Javascript vyhral na frontendu vcera a na backendu vyhraje zitra. To jakej to je jazyk, co umi a co neumi je uplne irelevantni. Dejiny nejsou idealni ale optimalni. Transpilace je jenom stopgap pro stare browsery, moderni resi ES6+ nativne, a nodejs to ma nativne taky. S jistou nadsazkou muzeme rict, ze ES5 dnes vnimame jako assembler, low level vrstvu. Je jedno v cem programujes, nakonec se to kompiluje do asm/binarky. To ze se tomu u webaru rika "transpilace" je jenom buzzword.
TLDR - resis idealnost a ne optimalnost, navrhuji se vratit na zem a brat programatorinu jaka je a ne jaka by mohla byt.
-
Ze je atom v principu imutabilni, deduplikovany string, jsem uz napsal
Koukám, že ty atomy pocházejí z Prologu. Má Erlang nějakou možnost říct, že dva atomy se rovnají (nadefinovat ekvivalenci)?
-
Koukám, že ty atomy pocházejí z Prologu.
Jo, Erlang je hodně inspirovaný Prologem, je to sem tam znát. První překladač Erlangu byl v Prologu.
Má Erlang nějakou možnost říct, že dva atomy se rovnají (nadefinovat ekvivalenci)?
Ne. Atom je jako ta stringová konstanta - buď je stejný, pak je ekvivalentní, nebo není a pak není :) V Prologu je to ale stejně, ne?
Erlang/OTP 18 [erts-7.2.1] [source] [64-bit] [smp:4:4] [async-threads:10] [hipe] [kernel-poll:false]
Eshell V7.2.1 (abort with ^G)
1> a == a.
true
2> a == b.
false
-
a na backendu vyhraje zitra
Jasný. A letos je rok linuxového desktopu :))
-
S jistou nadsazkou muzeme rict, ze ES5 dnes vnimame jako assembler, low level vrstvu. Je jedno v cem programujes, nakonec se to kompiluje do asm/binarky. To ze se tomu u webaru rika "transpilace" je jenom buzzword.
To se ovšem velice mýlíš. Jediný důvod, proč se kde co kompiluje do JS, je ten, že se výrobci prohlížečů nejsou schopní domluvit na čemkoli jiném (téměř cokoli by bylo lepší než JS).
JS vyhrává ne proto, že "by byl vnímaný jako assembler", ale proto, že prostě není na výběr.
-
JS vyhrává [...] proto, že prostě není na výběr.
Na tom snad není nic špatného, dokud nemusím na JS sahat ručně (ani pohrabáčem). Když to za mě generuje transpiler, tak můžu být v klidu (viz GWT).
-
Atom je [...] stejný, pak je ekvivalentní, nebo není a pak není :) V Prologu je to ale stejně, ne?
Jo, je to stejně, a občas to je problém, proto se ptám, jestli to Erlang nemá vyřešené lépe. Zřejmě to je tedy stejně svazující jako v Prologu a člověk musí hledat workaroundy.
-
Na tom snad není nic špatného, dokud nemusím na JS sahat ručně (ani pohrabáčem). Když to za mě generuje transpiler, tak můžu být v klidu (viz GWT).
Jo, ale kdyby byl místo JS rozumný VM, nemusel by i relativně jednoduchý web vytížit procesor tak, že začne hučet větrák ;) a nejspíš i ta nabídka jazyků pro frontend by byla zajímavější. Ale jak už tady někdo psal, člověk nemůže chtít všechno, no :)
Atom je [...] stejný, pak je ekvivalentní, nebo není a pak není :) V Prologu je to ale stejně, ne?
Jo, je to stejně, a občas to je problém, proto se ptám, jestli to Erlang nemá vyřešené lépe. Zřejmě to je tedy stejně svazující jako v Prologu a člověk musí hledat workaroundy.
To je zajímavý, měl bys nějaký konkrétní příklad (ne nutně kód)? Já si neuvědomuju, že bych na něco narazil (ani v Prologu, ani v Erlangu).
-
Na tom snad není nic špatného, dokud nemusím na JS sahat ručně (ani pohrabáčem). Když to za mě generuje transpiler, tak můžu být v klidu (viz GWT).
Jo, ale kdyby byl místo JS rozumný VM, nemusel by i relativně jednoduchý web vytížit procesor tak, že začne hučet větrák ;) a nejspíš i ta nabídka jazyků pro frontend by byla zajímavější. Ale jak už tady někdo psal, člověk nemůže chtít všechno, no :)
Já používám Safari a zatím jsem nenarazil na web, co by roztočil větrák (a ne, nemyslím na dvanáctipalcovém MacBooku ani iPadu :) )
-
Já používám Safari a zatím jsem nenarazil na web, co by roztočil větrák (a ne, nemyslím na dvanáctipalcovém MacBooku ani iPadu :) )
Stačí nestabilní model v D3 - nějaká kulička se ti tam gingle o jeden pixel tam a zpátky a ČEZ má žně :)
-
Atom je [...] stejný, pak je ekvivalentní, nebo není a pak není :) V Prologu je to ale stejně, ne?
Jo, je to stejně, a občas to je problém, proto se ptám, jestli to Erlang nemá vyřešené lépe. Zřejmě to je tedy stejně svazující jako v Prologu a člověk musí hledat workaroundy.
To je zajímavý, měl bys nějaký konkrétní příklad (ne nutně kód)? Já si neuvědomuju, že bych na něco narazil (ani v Prologu, ani v Erlangu).
Jo, měl. Parsing do FOL například. Když se použije Early nebo něco takového, tak chci pro "Pepe eats pâté" dostat něco jako "eats(x,y) & Pepe(x) & pâté(y)", přičemž z lexikonu vyleze Pepe(u) a pâté(v) a během parsingu zjistím, že x=u a y=v. Pro efektivní implementaci by se hodila hashmapa nad termy, pro které můžu určit ekvivalenci. Kdyby to měl nějaký jazyk zabudované, celkem by to usnadnilo implementaci mnohých algoritmů, protože efektivní algoritmus se pro to píše blbě. Bohužel, "if you want something done right, you have to do it yourself."
-
Jo, měl. Parsing do FOL například. Když se použije Early nebo něco takového, tak chci pro "Pepe eats pâté" dostat něco jako "eats(x,y) & Pepe(x) & pâté(y)", přičemž z lexikonu vyleze Pepe(u) a pâté(v) a během parsingu zjistím, že x=u a y=v. Pro efektivní implementaci by se hodila hashmapa nad termy, pro které můžu určit ekvivalenci. Kdyby to měl nějaký jazyk zabudované, celkem by to usnadnilo implementaci mnohých algoritmů, protože efektivní algoritmus se pro to píše blbě. Bohužel, "if you want something done right, you have to do it yourself."
Čili jestli to dobře chápu, princip je v tom, že v průběhu výpočtu zjistíš nějaké dodatečné informace, které ti nějaké atomy ztotožní. Jasný, to nejde. A imho by by to ani jít nemělo - atom by měl z principu zastupovat nějakou neměnnou entitu. Kdyby ti někdo splnil tohle, tak si zas vymyslíš nějakou jinou krávovinu, která nejde, viď, ty lišáku! ;)
-
Jo, ale kdyby byl místo JS rozumný VM, nemusel by i relativně jednoduchý web vytížit procesor tak, že začne hučet větrák ;) a nejspíš i ta nabídka jazyků pro frontend by byla zajímavější.
Jeste stale si nam nevysvetlil co je na JS nerozumnyho. Ten VM tam pod poklickou tak ci tak je, akorat mu rikame Abstract syntax tree a prave kde jake lintery, minifikatory, transpilery a nastroje pro refactoring tezi primo z nej. Teoreticky si vyhackuj zdrojaky chrome a V8 a muzes si programovat primo v "assembleru" AST, bez meziclanku JS a DOMu kdyz ti to je trnem v oku.
Ta "nabidka" jazyku primo v prohlizeci je to POSLEDNI co chceme (pametnici znaji IE4-5 a VBScript vs JScript vs JavaScript). Roky se tu taha valka o standardy a ted kdyz je raj na dosah protoze IE i FF jsou na vymreni a staci nam podporovat chrome engine tu nekdo chce "svobodu" vyberu ? Tak jako tak by takovej jazyk musel byt navrzen od piky protoze pouzit jiny stavajici by bylo nevhodne vzhledem na specifika webariny, prace s DOM atd. Takze zase idealisticka utopie a vratme se na Zem a k optimalnim postupnym krokum k svetlym zitrkum - ES6+ a TypeScript. A ano stale jsou plne transpilovatelne do ES5 protoze je computational complete a tedy dokonaly i bez tech vasich atomu a primitiv (protoze vsechno v JS je defacto objekt).
No a s tim hucenim vetraku pri browseru, tak nevim co delas spatne ale tipuji to na kombinaci linuxu a firefoxu, zname to neoptimalni zrouty pameti a systemovych prostredku :) My s MacbookPro a Safari (a odnedavna i vytunenym Chrome) to nezname...
-
Jo, ale kdyby byl místo JS rozumný VM, nemusel by i relativně jednoduchý web vytížit procesor tak, že začne hučet větrák ;) a nejspíš i ta nabídka jazyků pro frontend by byla zajímavější.
Jeste stale si nam nevysvetlil co je na JS nerozumnyho. Ten VM tam pod poklickou tak ci tak je, akorat mu rikame Abstract syntax tree a prave kde jake lintery, minifikatory, transpilery a nastroje pro refactoring tezi primo z nej. Teoreticky si vyhackuj zdrojaky chrome a V8 a muzes si programovat primo v "assembleru" AST ... tady sem prestal cist
dalsi zabijak
-
Jo, měl. Parsing do FOL například. Když se použije Early nebo něco takového, tak chci pro "Pepe eats pâté" dostat něco jako "eats(x,y) & Pepe(x) & pâté(y)", přičemž z lexikonu vyleze Pepe(u) a pâté(v) a během parsingu zjistím, že x=u a y=v. Pro efektivní implementaci by se hodila hashmapa nad termy, pro které můžu určit ekvivalenci. Kdyby to měl nějaký jazyk zabudované, celkem by to usnadnilo implementaci mnohých algoritmů, protože efektivní algoritmus se pro to píše blbě. Bohužel, "if you want something done right, you have to do it yourself."
Čili jestli to dobře chápu, princip je v tom, že v průběhu výpočtu zjistíš nějaké dodatečné informace, které ti nějaké atomy ztotožní. Jasný, to nejde. A imho by by to ani jít nemělo - atom by měl z principu zastupovat nějakou neměnnou entitu. Kdyby ti někdo splnil tohle, tak si zas vymyslíš nějakou jinou krávovinu, která nejde, viď, ty lišáku! ;)
Tak, je to o dodatečných informacích, které nejsou a priori známy. V Prologu by to jít mělo (v nějakém rozšíření), protože nikde není řečeno, že dvě konstanty musí být vždy rozdílné. Takhle to člověk musí obcházet a vynalézat kolo (nebo zakulatit ten správný čtverec :D ). A asi jo, často se stává, že člověk potřebuje nějakou "krávovinu", ale to plyne z podstaty řešených problémů/algoritmů.
-
...tady sem prestal cist
dalsi zabijak
Fungujes proste prilis logicky a ne ezotericky jako javascript :-)
Svet nepostavili architekti ale zednici, webarinu neudelali vedci ale inzenyri, bitvu nevyhral general ale vojak. As good as it gets.
-
...tady sem prestal cist
dalsi zabijak
Fungujes proste prilis logicky a ne ezotericky jako javascript :-)
Svet nepostavili architekti ale zednici
Taky podle toho vypadá...
-
Jo, měl. Parsing do FOL například. Když se použije Early nebo něco takového, tak chci pro "Pepe eats pâté" dostat něco jako "eats(x,y) & Pepe(x) & pâté(y)", přičemž z lexikonu vyleze Pepe(u) a pâté(v) a během parsingu zjistím, že x=u a y=v. Pro efektivní implementaci by se hodila hashmapa nad termy, pro které můžu určit ekvivalenci. Kdyby to měl nějaký jazyk zabudované, celkem by to usnadnilo implementaci mnohých algoritmů, protože efektivní algoritmus se pro to píše blbě. Bohužel, "if you want something done right, you have to do it yourself."
Čili jestli to dobře chápu, princip je v tom, že v průběhu výpočtu zjistíš nějaké dodatečné informace, které ti nějaké atomy ztotožní. Jasný, to nejde. A imho by by to ani jít nemělo - atom by měl z principu zastupovat nějakou neměnnou entitu. Kdyby ti někdo splnil tohle, tak si zas vymyslíš nějakou jinou krávovinu, která nejde, viď, ty lišáku! ;)
Tak, je to o dodatečných informacích, které nejsou a priori známy. V Prologu by to jít mělo (v nějakém rozšíření), protože nikde není řečeno, že dvě konstanty musí být vždy rozdílné. Takhle to člověk musí obcházet a vynalézat kolo (nebo zakulatit ten správný čtverec :D ). A asi jo, často se stává, že člověk potřebuje nějakou "krávovinu", ale to plyne z podstaty řešených problémů/algoritmů.
uz by sis mel napsat vlastni jazyk aby ses konecne zabavil a unavil - me se libila prednaska o joxe pro inspiraci - https://vimeo.com/49116180 - to sem si chtel vzdycky vyzkouset ale odsunul sem to do dalsiho zivota
-
Na tom snad není nic špatného, dokud nemusím na JS sahat ručně (ani pohrabáčem). Když to za mě generuje transpiler, tak můžu být v klidu (viz GWT).
Jo, ale kdyby byl místo JS rozumný VM, nemusel by i relativně jednoduchý web vytížit procesor tak, že začne hučet větrák ;)
Jestli to spíš není tím, že dneska weby píše kde kdo ;)
a JavaScript dobude cely svet!
A ne?
----
Jako fakt mě baví, jak tu má někdo mindrák z JS a JSONu jen proto, že v prvním případě to nezná (nebo chce být ignorant) a v druhém proto, že danou technologii chce cpát někam, kam nepatří (aneb vyčítáme Octavii, že nevyjede kopec jako Range Rover). Super.
-
uz by sis mel napsat vlastni jazyk
Občas není jiné cesty.
-
uz by sis mel napsat vlastni jazyk
Občas není jiné cesty.
Jen ne proboha dalsi hruzu jako haskel, erlang, go nebo elm. Neco jeste jednodussiho nez JavaScript. Uplne neblokujici, zadne chybove hlasky, jenom warningy. Kde konci bool logika at nastoupi fuzzy logika. Taky nemusi vsechno pracne pocitat, staci kdyz to dostatecne presne odhadne ne ?
-
Ten VM tam pod poklickou tak ci tak je, akorat mu rikame Abstract syntax tree
Má ty prostoto.
Ta "nabidka" jazyku primo v prohlizeci je to POSLEDNI co chceme (pametnici znaji IE4-5 a VBScript vs JScript vs JavaScript).
Ty to fakt nechápeš? Pokud by prohížeč dostal bytecode, tak by ani nevěděl, z jakého jazyka vzniknul.
specifika webariny
To's nemohl vystihnout líp. Celej ten tvůj příspěvek je geniální ilustrací "specifik webařiny". Kdybych ho chtěl nafejkovat, tak by se mi to nepodařilo.
ale tipuji to na kombinaci linuxu a firefoxu
Oba tipy mimo.
-
Neco jeste jednodussiho nez JavaScript.
To už existuje. Lua je JavaScript done right.
-
Jeste stale si nam nevysvetlil co je na JS nerozumnyho. Ten VM tam pod poklickou tak ci tak je, akorat mu rikame Abstract syntax tree
To máte za to, že se nemodlíte!
-
Neco jeste jednodussiho nez JavaScript.
To už existuje. Lua je JavaScript done right.
Nebo Smalltalk.
-
Neco jeste jednodussiho nez JavaScript.
To už existuje. Lua je JavaScript done right.
Lua? Heh v tom jsem delal sveho casu cartridge do Whereigo odnoze geocachingu. No jednoduchy to je, syntax na styl Pascalu. Ale jako nahrada za JS ? Mne to prijde +/- to samy a luu bych spise pouzil pro studaky na vyuku algoritmu. A jak by si poradila s async vecma to ani nechci tusit, ja v tom busil jen normalne proceduralne. FP se muselo taky doimplementovat.
-
Mne to prijde +/- to samy
Má to jeden zásadni rozdíl: je to udělané dobře. Čili se to chová tak, jak člověk očekává, nemusí studovat tuny weirdovin (https://www.youtube.com/watch?v=2pL28CcEijU).
A jak by si poradila s async vecma to ani nechci tusit
No jak asi?! Úplně stejně jako JS. Viz např. https://luvit.io/
FP se muselo taky doimplementovat.
Ani nechci vědět, čemu říkáš FP. To bude taky nějaký AST, ne? :)
-
Ani nechci vědět, čemu říkáš FP. To bude taky nějaký AST, ne? :)
Co to meles? AST je VM assembler 8) FunPrg jsou ty pjury hajordery karingy map/reduce/filter/zip ne ?
-
Co to meles? AST je VM assembler 8) FunPrg jsou ty pjury hajordery karingy map/reduce/filter/zip ne ?
Prvně si, ty pjůre (to je od kořene "průjem"?), radši přečti https://en.wikipedia.org/wiki/Abstract_syntax_tree
-
Mne to prijde +/- to samy
Má to jeden zásadni rozdíl: je to udělané dobře. Čili se to chová tak, jak člověk očekává, nemusí studovat tuny weirdovin (https://www.youtube.com/watch?v=2pL28CcEijU).
většina z toho nejsou weirdoviny a je to jen půlhodinové video. To byste mohl dokoukat.
-
Prvně si, ty pjůre (to je od kořene "průjem"?), radši přečti https://en.wikipedia.org/wiki/Abstract_syntax_tree
S dovolenim vasnosti, vy skuste s tim AST nekdy i pracovat aby ste tu analogii s vm a assemblerem mohl pochopit.
-
S dovolenim vasnosti, vy skuste s tim AST nekdy i pracovat aby ste tu analogii s vm a assemblerem mohl pochopit.
Já to chápu naprosto přesně. Motáš hrušky s jabkama, protože to je webařské specifikum.
Takže radši vyčistit zuby, vyčůrat a spát :)
-
S dovolenim vasnosti, vy skuste s tim AST nekdy i pracovat aby ste tu analogii s vm a assemblerem mohl pochopit.
Já to chápu naprosto přesně. Motáš hrušky s jabkama, protože to je webařské specifikum.
Takže radši vyčistit zuby, vyčůrat a spát :)
Zapomněls "pomodlit" ;)
-
Zapomněls "pomodlit" ;)
V tomhle případě by to chtělo myslím spíš exorcismus. Minimálně od papeže :)
-
Takže radši vyčistit zuby, vyčůrat a spát :)
Nehrozi, jeste dva dily Dirk Gently's Holistic Detective Agency. To je pokoukanicko pro nas, prd tomu rozumim ale bavim se ::)
-
Otázkou je, jestli se OOP vůbec učit. On je to trochu zvrácený způsob myšlení a ne zrovna dobrý. Myslím si, že funkcionální programávání je mnohem lepší, ikdyž všichni propagují OOP.
OOP smysl jednoznačně má, pokud se používá s rozumem a ne jako ideologie (stylu, že se s ním musí dělat absolutně všechno a všude a že absolutně všechno v progamu musí být objekt...). Jako kniha mi přišla dobrá "The C++ Programming Language" od Stroustrupa.
-
Neco jeste jednodussiho nez JavaScript.
To už existuje. Lua je JavaScript done right.
Lua? To uz radeji Perl...
Btw v JS je implementovanej taky LuaVM, http://moonshinejs.org/ tolik prace a pritom takova blbost :) Dokonce i vlastni debugger je k tomu, jak by se nedaly pouzit chromacke map soubory ?
-
uz by sis mel napsat vlastni jazyk
Občas není jiné cesty.
Když se nad tím zamyslíš, tak každá třída v OOP používá vlastní jazyk. Záleží na programátorovi, jak moc jim udělá podobné rozhraní a jak budou znovupoužitelné.
-
uz by sis mel napsat vlastni jazyk
Občas není jiné cesty.
Když se nad tím zamyslíš, tak každá třída v OOP používá vlastní jazyk. Záleží na programátorovi, jak moc jim udělá podobné rozhraní a jak budou znovupoužitelné.
Nejen to, pojmenování tříd je de facto vlastní jazyk syntetického typu, něco jako inuitština, kdy jedno slovo pomocí prefixů, sufixů a skloňování má vyjadřovací schopnosti analytické věty. Vůbec nevadí identifikátory a zápisy tříd jako ModrySnihBrzyRanoPoMraziveNoci:roztal().
-
Otázkou je, jestli se OOP vůbec učit. On je to trochu zvrácený způsob myšlení a ne zrovna dobrý. Myslím si, že funkcionální programávání je mnohem lepší, ikdyž všichni propagují OOP.
OOP smysl jednoznačně má, pokud se používá s rozumem a ne jako ideologie (stylu, že se s ním musí dělat absolutně všechno a všude a že absolutně všechno v progamu musí být objekt...). Jako kniha mi přišla dobrá "The C++ Programming Language" od Stroustrupa.
Haha - prvni pulka dobra ale s tim soustrupem si to totalne zabil :))
-
uz by sis mel napsat vlastni jazyk
Občas není jiné cesty.
Když se nad tím zamyslíš, tak každá třída v OOP používá vlastní jazyk. Záleží na programátorovi, jak moc jim udělá podobné rozhraní a jak budou znovupoužitelné.
Nejen to, pojmenování tříd je de facto vlastní jazyk syntetického typu, něco jako inuitština, kdy jedno slovo pomocí prefixů, sufixů a skloňování má vyjadřovací schopnosti analytické věty. Vůbec nevadí identifikátory a zápisy tříd jako ModrySnihBrzyRanoPoMraziveNoci:roztal().
Tyvoe uz sem se lekl ze se tu neobjevis - mels dovolenou nebo co?
-
uz by sis mel napsat vlastni jazyk
Občas není jiné cesty.
Když se nad tím zamyslíš, tak každá třída v OOP používá vlastní jazyk. Záleží na programátorovi, jak moc jim udělá podobné rozhraní a jak budou znovupoužitelné.
Zas bych to s tema jazykama neprehanel...
-
uz by sis mel napsat vlastni jazyk
Občas není jiné cesty.
Když se nad tím zamyslíš, tak každá třída v OOP používá vlastní jazyk. Záleží na programátorovi, jak moc jim udělá podobné rozhraní a jak budou znovupoužitelné.
Zas bych to s tema jazykama neprehanel...
Proto se dělají rozhraní, aby těch jazyků bylo méně a byl v nich přehled.
-
Tak jistě, zavolat json_encode(val) je prkotina. Ale víš přesně, jaké garance ti to dává? Jsi si jistý, že val == json_decode(json_encode(val))? A když ne, víš přesně, kdy ne? Víš, jaký typ ti to dá, když HTTP/JSON API zavoláš z jiného jazyka?
A co s typy, které JSON prostě nemá? Budu z každého atomu dělat {type: "atom", val: "val"} jak debil? Co budu dělat s mapama, kde klíčem je dvojice nebo nedejsladkákálí strom...
To ale není chyba JSONu, ale způsobu, kterým serializujete/deserializujete. Když to necháte na nějakém obecném sráči (pokaždé jiném), nemůžete se divit, že vám z toho padají hovadiny. Každá entita má mít schopnost se sama serializovat a deserializovat. Každý datový model má svoje jedinečné entity...
Existují i jiné notace (např. STON), ale k výše uvedenému je nedoporučuju a považuju za nadbytečné.
-
Ne. Já považuju za chybu používat jakoukoli knihovnu/framework/abstrakci, která je natolik složitá a neprůhledná, že programátor nedokáže pohledem na kód říct, co vlastně v danou chvíli udělá, a zároveň má potenciálně velmi zásadní vliv na výkon aplikace.
To souhlasím. Musím přiznat, že mě různé frameworky děsí pro jejich komplexnost a neprůhlednost. V případě problémů je to pak v pr-deli, protože dovnitř se nevidí. Příčinou obrovitosti může být snaha oněch frameworků o obecnost (typ "řeším vše"). Osobně za chybu považuju i přílišnou deklarativnost (něco jako antivzor programování v konfigurácích), čímž vzniká nový, deklarativní jazyk nad původním, tj. pouze náhrada jednoho problému jiným.
...takže se ve finále pořádně košatým JOINem načítalo i spousta věcí, které pro výpočet vůbec nebyly potřeba, a to ještě vesele kdykoli jakkoli, třeba uprostřed výpočtu. Nekontrolovatelně. Nádhera...
(Nechci se hádat o to, jestli tahle konkrétní situace jde nebo nejde v Djangu nějak potunit, pointa je v tom, že místo aby se udělala jednoduchá DB s jasnou strukturou a jednoduché SQL dotazy, kterým by každý rozuměl a uměl je ladit, použil se "pohodlný nástroj", který ve finále aplikaci úplně zabil)
To mohlo být nějakou chybou návrhu, aťto aplikace, nebo frameworku. Každopádně to vůbec neznamená, že nemůžu použít (vhodné!, vlastní ) ORM a abstrakci!
-
ORM, ElasticSearch nebo objektove databaze maji smysl, kdy je potreba ukladat male mnozstvi dat aplikace, napr pro ukladani konfigurace si user preferences.
Toto tvrzení nedává žádný smysl. Jestliže ODB umí servírovat objekty, případně obsahuje nástroje pro hromadné operace (především vyhledávání), není důvod k výrazně většímu rozdílu v rychlosti, v případě správného návrhu domény to může být i rychlejší. Každopádně vždy jednodušší než RDBMS.
-
Když to necháte na nějakém obecném sráči (pokaždé jiném), nemůžete se divit, že vám z toho padají hovadiny. Každá entita má mít schopnost se sama serializovat a deserializovat.
Řekl kdo? Musím psát speciální deserializační funkci pro každou variantu datové struktury (NEbavím se o objektech) jenom protože proto?
A jaktože to v jiných formátech jde? Prostě mají uživatelsky definované typy a ty můžu použít třeba pro serializaci toho atomu - napíšu to jednou a bude mi to fungovat ve všech strukturách. To je špatně? Musím to psát stokrát podle toho, jestli se mi atom objeví v poli, objektu, jako standalone hodnota?
V JSONu by to šlo taky - a velice snadno. Stačil by jeden typ navíc, který by vypadal třeba takhle:
{{type: "atom", value: "myAtom"}}
- důležité je, že je odlišený od objektu, aby byly vyloučeny kolize s objektem
{type: "atom", someRandomGarbage: "blablabla"}
který se v principu v datech může objevit taky.
Ne, v JSONu to nejde, protože "webová specifika"...
-
To mohlo být nějakou chybou návrhu, aťto aplikace, nebo frameworku. Každopádně to vůbec neznamená, že nemůžu použít (vhodné!, vlastní ) ORM a abstrakci!
...což je přesně to, co jsem napsal: že přechytřelé ORM frameworky člověka nepozorovaně vedou do pekla.
-
V JSONu by to šlo taky - a velice snadno. Stačil by jeden typ navíc, který by vypadal třeba takhle:
{{type: "atom", value: "myAtom"}}
- důležité je, že je odlišený od objektu, aby byly vyloučeny kolize s objektem
{type: "atom", someRandomGarbage: "blablabla"}
který se v principu v datech může objevit taky.
Ne, v JSONu to nejde, protože "webová specifika"...
JSON je původně javascriptová notace, která se rozšířila i jinam. Žádné atomy ve většině jazyků neexistují, tak nevím proč by je měl univerzální formát podporovat. Javascriptový string je to stejné co atom, jen to nezní cool. Není důvod ukládat jednu věc dvěma způsoby.
-
JSON je původně javascriptová notace, která se rozšířila i jinam. Žádné atomy ve většině jazyků neexistují, tak nevím proč by je měl univerzální formát podporovat. Javascriptový string je to stejné co atom, jen to nezní cool. Není důvod ukládat jednu věc dvěma způsoby.
No a to je presne ta pointa: JS nezna integer, takze proc by ho mel podporovat? Proc by mel definovat, ze "3.0" NENI integer?! Vsak at si to kazdej naparsuje jak chce, sere pes, my webari integer nemame.
A pak se tenhle "webarsky specificky" mor rozsiri do celeho sveta, kdo nema JSON API jakoby nebyl a vsichni jak kreteni travime tisice manyears dumanim nad tim, jak nad tim shitem postavit neco, co by bylo aspon trochu pouzitelny.
-
To mohlo být nějakou chybou návrhu, aťto aplikace, nebo frameworku. Každopádně to vůbec neznamená, že nemůžu použít (vhodné!, vlastní ) ORM a abstrakci!
...což je přesně to, co jsem napsal: že přechytřelé ORM frameworky člověka nepozorovaně vedou do pekla.
Význam ORM je v tom, že umožňuje abstrakci ORM rozšířit na aplikaci.
Například si uvědomíte, že vaše aplikace se sestává z dokumentů, pak stačí pomocí ORM namodelovat typickou strukturu dokumentu a dále pracovat jen s ní, kdy dokument je určen jednoznačným klíčem, atributy, popřípadě strukturou položky. Nemá smysl pro každé vypsání libovolného dokumentu psát pokaždé zvláštní způsob získání dat. Pro praktickou aplikaci pak vystačíte z řádově jednotkami abstraktních operací.
Pokud je vaše aplikace vybudována nad stromovými strukturami, či řídkými maticemi. Vytvoříte si obdobu ORM a vytvoříte pár abstraktních operací, které pak použijete. Nebudete přece matice, či stromy procházet pomocí zanořovaných cyklů for.
Samozřejmě za cenu snížení výkonu, ale snadnější a tedy levnější údržby.
-
JSON je původně javascriptová notace, která se rozšířila i jinam. Žádné atomy ve většině jazyků neexistují, tak nevím proč by je měl univerzální formát podporovat. Javascriptový string je to stejné co atom, jen to nezní cool. Není důvod ukládat jednu věc dvěma způsoby.
No a to je presne ta pointa: JS nezna integer, takze proc by ho mel podporovat? Proc by mel definovat, ze "3.0" NENI integer?! Vsak at si to kazdej naparsuje jak chce, sere pes, my webari integer nemame.
A pak se tenhle "webarsky specificky" mor rozsiri do celeho sveta, kdo nema JSON API jakoby nebyl a vsichni jak kreteni travime tisice manyears dumanim nad tim, jak nad tim shitem postavit neco, co by bylo aspon trochu pouzitelny.
Vaše strana aplikace, si může json interpetovat jak chce. Když potřebuje integer, může i float interpretovat jako integer. On vlastně float je jen jinak uložený integer.
-
Například si uvědomíte, že vaše aplikace se sestává z dokumentů, pak stačí pomocí ORM namodelovat typickou strukturu dokumentu a dále pracovat jen s ní
Jenže pak je lepší použít objektovou databázi a na nějaké ORM se vykašlat.
-
JSON je původně javascriptová notace, která se rozšířila i jinam. Žádné atomy ve většině jazyků neexistují, tak nevím proč by je měl univerzální formát podporovat. Javascriptový string je to stejné co atom, jen to nezní cool. Není důvod ukládat jednu věc dvěma způsoby.
No a to je presne ta pointa: JS nezna integer, takze proc by ho mel podporovat? Proc by mel definovat, ze "3.0" NENI integer?! Vsak at si to kazdej naparsuje jak chce, sere pes, my webari integer nemame.
A pak se tenhle "webarsky specificky" mor rozsiri do celeho sveta, kdo nema JSON API jakoby nebyl a vsichni jak kreteni travime tisice manyears dumanim nad tim, jak nad tim shitem postavit neco, co by bylo aspon trochu pouzitelny.
nepoužívejte frikulínské přísně typované jazyky a nebudete mít problém.
-
Například si uvědomíte, že vaše aplikace se sestává z dokumentů, pak stačí pomocí ORM namodelovat typickou strukturu dokumentu a dále pracovat jen s ní
Jenže pak je lepší použít objektovou databázi a na nějaké ORM se vykašlat.
Ale ano proč ne. ORM je taky jen implementace virtuální objektové DB.
-
nepoužívejte frikulínské přísně typované jazyky a nebudete mít problém.
NE! Je to presne naopak: ve frikulinskych prisne typovanych jazycich neni problem, protoze tam je jasne dane, co chce clovek dostat, a parser te informace muze vyuzit, aby doplnil to, co specificka webarina nepovazovala za potrebne. Zatimco v dynamicky typovanych jazycich dostane NECO, co mu probubla az kdovi kam a tam to spadne na runtime vyjimku. Jenom proto, ze "integer nemame, tak si to udelejte jak chcete".
Nicmene, cely tenhle cirkus ma i jednu pozitivni stranku: clovek si aspon uvedomi, kam to muze vest, kdyz zasadni IT technologie navrhuje absolvent zurnalistiky na statni univerzite...
-
Asi používáte chybný parser. Python parsuje i serializuje int a float správně.
In [4]: type(json.loads('{"a":1}')['a'])
Out[4]: int
In [5]: type(json.loads('{"a":1.0}')['a'])
Out[5]: float
In [6]: json.dumps({'a':1})
Out[6]: '{"a": 1}'
In [7]: json.dumps({'a':1.0})
Out[7]: '{"a": 1.0}'
-
Uz by to chtelo zmenu - komunikace po fooru na rootu se vzdycky zvrhne v takovydle strasny porno - nechcete si na to zalozit IRC kanal - vyrobit nakej projekt na githubu a bavit se nad konkretnima problemama nejak usporadane? Tohle je tak strašně utopenyho casu a energie az to neni pekny - at vam strejda zboj dela predsedu a je to
-
Uz by to chtelo zmenu - komunikace po fooru na rootu se vzdycky zvrhne v takovydle strasny porno - nechcete si na to zalozit IRC kanal - vyrobit nakej projekt na githubu a bavit se nad konkretnima problemama nejak usporadane? Tohle je tak strašně utopenyho casu a energie az to neni pekny - at vam strejda zboj dela predsedu a je to
Stále ztrácíme čas smysluplnějším způsobem než ty. My diskutujeme k tématu. Tvé příspěvky jsou úplně mimo. Když se ti diskuze nelíbí, proč sem lezeš?
-
Asi používáte chybný parser. Python parsuje i serializuje int a float správně.
Dle jake definice "spravne"? Znovu opakuju: jak se ma "3.0" parsovat v jazycich, ktere rozlisuji int a float je nedefinovane. Cili "spravny" zpusob parsovani "3.0" je "delejte si co chcete, nam webarum je to u pr-dele, my nevime, co je to int".
-
Asi používáte chybný parser. Python parsuje i serializuje int a float správně.
Dle jake definice "spravne"? Znovu opakuju: jak se ma "3.0" parsovat v jazycich, ktere rozlisuji int a float je nedefinovane. Cili "spravny" zpusob parsovani "3.0" je "delejte si co chcete, nam webarum je to u pr-dele, my nevime, co je to int".
Vy jste kritizoval JSON jako formát. Neodlišování float a int je problém javascriptu. V JSONu to odlišit jde.
-
Asi používáte chybný parser. Python parsuje i serializuje int a float správně.
Dle jake definice "spravne"? Znovu opakuju: jak se ma "3.0" parsovat v jazycich, ktere rozlisuji int a float je nedefinovane. Cili "spravny" zpusob parsovani "3.0" je "delejte si co chcete, nam webarum je to u pr-dele, my nevime, co je to int".
Vy z těch webových technologií fakt máte nějaký komplex ;D
-
Sorry, ale už mě to poslouchání obhajování neobhajitelného fakt nebaví, takže poslední slovo:
Vy jste kritizoval JSON jako formát. Neodlišování float a int je problém javascriptu. V JSONu to odlišit jde.
Není to ve specifikaci definované, čili to odlišit nejde. Že nějaké implementace mají nějaké vlastní rozšíření, je sice pěkné a i v praxi použitelné, ale nic to nemění na tom, že JSON je prostě mentální mrzák. A i kdyste to okecával třeba týden, nepřestane to být pravda, protože dementní, zbytečná omezení JSONu jsou prostě snadno ověřitelné faktum.
-
Vy z těch webových technologií fakt máte nějaký komplex ;D
Vadí mi lidi, kteří budou furt dokola tvrdit, že kácet stromy herynkem je přece úplně v pohodě. Na co sekera?
-
Vy z těch webových technologií fakt máte nějaký komplex ;D
Vadí mi lidi, kteří budou furt dokola tvrdit, že kácet stromy herynkem je přece úplně v pohodě. Na co sekera?
S dementem se prostě domluvit nedá. Nicméně JSON je sice pakárna, ale na jednoduché věci stačí.
-
Nicméně JSON je sice pakárna, ale na jednoduché věci stačí.
Jasně, však já nemám nic proti tomu, aby se JSONem posílaly přes websockety zprávy typu
{event: "newChatMessage", sender: "Franta", msg: "specificka webarina"}
ale je škoda, že se ten mor šíří dál a dál. Je to stejný jako monopol Windows 95... Vyhrál největší shit široko daleko...
...a do toho slzavýho údolí ještě přijdou chytráci, kteří začnou tvrdit, že to je vlastně state of the art...
-
Uz by to chtelo zmenu - komunikace po fooru na rootu se vzdycky zvrhne v takovydle strasny porno - nechcete si na to zalozit IRC kanal - vyrobit nakej projekt na githubu a bavit se nad konkretnima problemama nejak usporadane? Tohle je tak strašně utopenyho casu a energie az to neni pekny - at vam strejda zboj dela predsedu a je to
Stále ztrácíme čas smysluplnějším způsobem než ty. My diskutujeme k tématu. Tvé příspěvky jsou úplně mimo. Když se ti diskuze nelíbí, proč sem lezeš?
Tak lze te poslat na desitku zpusobu a co z toho - chtel bych se zbojem a mirdou vyrobit jazyk na beamem třebas - tahle forma me sere a lezu sem kdyz se nudim a musim hlídat deti u bazenu trebas jako ted u toho se totiz nic moc jinyho neda delat
-
Nicméně JSON je sice pakárna, ale na jednoduché věci stačí.
Jasně, však já nemám nic proti tomu, aby se JSONem posílaly přes websockety zprávy typu
{event: "newChatMessage", sender: "Franta", msg: "specificka webarina"}
ale je škoda, že se ten mor šíří dál a dál. Je to stejný jako monopol Windows 95... Vyhrál největší shit široko daleko...
...a do toho slzavýho údolí ještě přijdou chytráci, kteří začnou tvrdit, že to je vlastně state of the art...
Poraďte něco lepšího.
-
Nicméně JSON je sice pakárna, ale na jednoduché věci stačí.
Jasně, však já nemám nic proti tomu, aby se JSONem posílaly přes websockety zprávy typu
{event: "newChatMessage", sender: "Franta", msg: "specificka webarina"}
ale je škoda, že se ten mor šíří dál a dál. Je to stejný jako monopol Windows 95... Vyhrál největší shit široko daleko...
...a do toho slzavýho údolí ještě přijdou chytráci, kteří začnou tvrdit, že to je vlastně state of the art...
To tak bývá, když technologie navrhuje pako. Další paka to pak obhajujou. Akademický přístup k problému někdy není na škodu, ale tady už je pozdě.
-
Nicméně JSON je sice pakárna, ale na jednoduché věci stačí.
Jasně, však já nemám nic proti tomu, aby se JSONem posílaly přes websockety zprávy typu
{event: "newChatMessage", sender: "Franta", msg: "specificka webarina"}
ale je škoda, že se ten mor šíří dál a dál. Je to stejný jako monopol Windows 95... Vyhrál největší shit široko daleko...
...a do toho slzavýho údolí ještě přijdou chytráci, kteří začnou tvrdit, že to je vlastně state of the art...
Poraďte něco lepšího.
Problem tehle debaty je napriklad v takovychdle nesmyslnych otazkach - neco lepsiho existuje na kokretni problem a pozadavky - bez nich se debata tahne jak smrad a konci tim ze se vsichni posilaj
-
delejte si co chcete, nam webarum je to u pr-dele, my nevime, co je to int
Nene, my NERESIME jestli cislo je nebo neni int. Cele cisla jsou podmnozinou realnych. Kdyz nekdo z nejakeho duvodu potrebuje zjistit jestli Number je integer tak ma Number.isInteger() metodu.
Jinak ta lua s cislama taky moc slavy nepobrala:
> print (0.1 * 0.2)
0.02
> print (0.1 * 0.2 == 0.02)
false
> print (0.1 * 0.2 == 0.1 * 0.2)
true
v JS alespon vim proc se to nerovna
> 0.1 * 0.2
0.020000000000000004
> 0.1 * 0.2 === 0.2
false
> 0.1 * 0.2 === 0.1 * 0.2
true
-
delejte si co chcete, nam webarum je to u pr-dele, my nevime, co je to int
v JS alespon vim proc se to nerovna
Tak ten byl taky dobrej :))
-
delejte si co chcete, nam webarum je to u pr-dele, my nevime, co je to int
v JS alespon vim proc se to nerovna
Tak ten byl taky dobrej :))
tak že jistý druh "webařů" neví a zřejmě nechce vědět jak fungují počítače víme nejpozději od debaty o bitových operacích
-
tak že jistý druh "webařů" neví a zřejmě nechce vědět jak fungují počítače víme nejpozději od debaty o bitových operacích
Jo protoze webar od kodera se lisi jak zubar od doktora co? Nahodou ja mel zkousku z turingoveho stroje za jedna, neco o procesorech snad vim a kdyz treba tak dohledam i RFC pro reprezentaci cisel v JS. A pokud mi pamet slouzi ta bitova nepresnost u floatu neni jen vysadou JS ale i jinych jazyku. Takze me zarazi proc to takova Lua nebo Perl orezava kdyz porovnani pak nesedi.
-
Nicméně JSON je sice pakárna, ale na jednoduché věci stačí.
Jasně, však já nemám nic proti tomu, aby se JSONem posílaly přes websockety zprávy typu
{event: "newChatMessage", sender: "Franta", msg: "specificka webarina"}
ale je škoda, že se ten mor šíří dál a dál. Je to stejný jako monopol Windows 95... Vyhrál největší shit široko daleko...
...a do toho slzavýho údolí ještě přijdou chytráci, kteří začnou tvrdit, že to je vlastně state of the art...
Takže chyba není v JSONu, ale v lidech, kteří ho cpou, kam se podle vás nehodí...
Ale kdybyste to řekl takto, tak byste si nemohl plivnout na JavaScript a technologie s ním související, tudíž byste si asi nesplnil denní kvótu urážek JS. Hezký. :)
-
Nicméně JSON je sice pakárna, ale na jednoduché věci stačí.
Jasně, však já nemám nic proti tomu, aby se JSONem posílaly přes websockety zprávy typu
{event: "newChatMessage", sender: "Franta", msg: "specificka webarina"}
ale je škoda, že se ten mor šíří dál a dál. Je to stejný jako monopol Windows 95... Vyhrál největší shit široko daleko...
...a do toho slzavýho údolí ještě přijdou chytráci, kteří začnou tvrdit, že to je vlastně state of the art...
Takže chyba není v JSONu, ale v lidech, kteří ho cpou, kam se podle vás nehodí...
Ale kdybyste to řekl takto, tak byste si nemohl plivnout na JavaScript a technologie s ním související, tudíž byste si asi nesplnil denní kvótu urážek JS. Hezký. :)
Lze urazit programovaci jazyk?
Btw:
https://hackernoon.com/how-it-feels-to-learn-javascript-in-2016-d3a717dd577f
-
Lze urazit programovaci jazyk?
Btw:
https://hackernoon.com/how-it-feels-to-learn-javascript-in-2016-d3a717dd577f
Ten článek si nedělá legraci z javascriptu, ale z nekritického přijímání módních technologií. Mimochodem je inspirován tímhle:
https://circleci.com/blog/its-the-future/
ten distributed systems guy má dost podobné názory jako Mirek Prýmek a Zboj.
-
Lze urazit programovaci jazyk?
Btw:
https://hackernoon.com/how-it-feels-to-learn-javascript-in-2016-d3a717dd577f
Ten článek si nedělá legraci z javascriptu, ale z nekritického přijímání módních technologií. Mimochodem je inspirován tímhle:
https://circleci.com/blog/its-the-future/
ten distributed systems guy má dost podobné názory jako Mirek Prýmek a Zboj.
Hehehehe
-
Nicméně JSON je sice pakárna, ale na jednoduché věci stačí.
Jasně, však já nemám nic proti tomu, aby se JSONem posílaly přes websockety zprávy typu
{event: "newChatMessage", sender: "Franta", msg: "specificka webarina"}
ale je škoda, že se ten mor šíří dál a dál. Je to stejný jako monopol Windows 95... Vyhrál největší shit široko daleko...
...a do toho slzavýho údolí ještě přijdou chytráci, kteří začnou tvrdit, že to je vlastně state of the art...
Takže chyba není v JSONu, ale v lidech, kteří ho cpou, kam se podle vás nehodí...
Ale kdybyste to řekl takto, tak byste si nemohl plivnout na JavaScript a technologie s ním související, tudíž byste si asi nesplnil denní kvótu urážek JS. Hezký. :)
Lze urazit programovaci jazyk?
Btw:
https://hackernoon.com/how-it-feels-to-learn-javascript-in-2016-d3a717dd577f
Někdy tu z těch diskusí mám pocit, že Mirek Prýmků umí a ví všechno a nejlíp. ;)
Ten článek znám a souhlasím s @gll.
Mně osobně přístup části webařské komunity taky dost se... štve. Např. na WebExpu zaznělo, jako důvod, proč používat TypeScript namísto JS, "JavaScript už není dneska cool". Jako what the fuck? Ale to už je asi na trošku jinou debatu, resp. stejně jako zmiňovaný článek, s JavaScriptem samotným to přímo nesouvisí. Spíš je to o tom, že dneska dělá weby kde kdo.
Ve vanilla JavaScriptu se dá psát pěkně.
-
Nicméně JSON je sice pakárna, ale na jednoduché věci stačí.
Jasně, však já nemám nic proti tomu, aby se JSONem posílaly přes websockety zprávy typu
{event: "newChatMessage", sender: "Franta", msg: "specificka webarina"}
ale je škoda, že se ten mor šíří dál a dál. Je to stejný jako monopol Windows 95... Vyhrál největší shit široko daleko...
...a do toho slzavýho údolí ještě přijdou chytráci, kteří začnou tvrdit, že to je vlastně state of the art...
Takže chyba není v JSONu, ale v lidech, kteří ho cpou, kam se podle vás nehodí...
Ale kdybyste to řekl takto, tak byste si nemohl plivnout na JavaScript a technologie s ním související, tudíž byste si asi nesplnil denní kvótu urážek JS. Hezký. :)
Lze urazit programovaci jazyk?
Btw:
https://hackernoon.com/how-it-feels-to-learn-javascript-in-2016-d3a717dd577f
Někdy tu z těch diskusí mám pocit, že Mirek Prýmků umí a ví všechno a nejlíp. ;)
Ten článek znám a souhlasím s @gll.
Mně osobně přístup části webařské komunity taky dost se... štve. Např. na WebExpu zaznělo, jako důvod, proč používat TypeScript namísto JS, "JavaScript už není dneska cool". Jako what the fuck? Ale to už je asi na trošku jinou debatu, resp. stejně jako zmiňovaný článek, s JavaScriptem samotným to přímo nesouvisí. Spíš je to o tom, že dneska dělá weby kde kdo.
Ve vanilla JavaScriptu se dá psát pěkně.
Tak dulezity je ze vis s kym souhlasis :) ze melete oba nesmysly to je vedlejsi... Tak v tom urcite pokračujte kluci
-
Takže chyba není v JSONu, ale v lidech, kteří ho cpou, kam se podle vás nehodí...
V lidech, kteří ho nesmyslně obhajují a v lidech, kteří ho nekriticky cpou všude.
Ale kdybyste to řekl takto, tak byste si nemohl plivnout na JavaScript a technologie s ním související, tudíž byste si asi nesplnil denní kvótu urážek JS. Hezký. :)
No, to ti asi budu muset připomenout, čím celá tahle eskapáda začala:
To ze v zakladu toho moc neumi je spise vyhodou
Ne, není. Nejlíp je to vidět na JSONu, ze kterého se bohužel stala lingua franca.
- kdyby se toho nechytli specfičtí webaři, kteří musí za každou cenu obhajovoat, že hranatý kolo je v pohodě, protože že to mírně drncá nikomu přece nevadí, nemuseli jsme tady to vlákno vůbec zaplevelovat. Jenže webařina je zjevně specificky náboženská...
-
Nene, my NERESIME jestli cislo je nebo neni int. Cele cisla jsou podmnozinou realnych. Kdyz nekdo z nejakeho duvodu potrebuje zjistit jestli Number je integer tak ma Number.isInteger() metodu.
No - a opět nemáš pravdu. Fakt chceš něco obhajovat, když to ani neznáš?!
JS:
9007199254740991+100
> 9007199254741092
Python:
>>> 9007199254740991+100
9007199254741091
Elixir:
iex(1)> 9007199254740991+100
9007199254741091
Jinak ta lua s cislama taky moc slavy nepobrala:
Ano, čísla má udělaný stejně jako JS.
-
Takže chyba není v JSONu, ale v lidech, kteří ho cpou, kam se podle vás nehodí...
V lidech, kteří ho nesmyslně obhajují a v lidech, kteří ho nekriticky cpou všude.
Je JSON špatný? Byl určen pro JS a (nejen) tam je ok. Pokud mi stačí takový vcelku jednoduchý formát, není problém ho použít jinde (a ono to pojede). To není nesmyslné obhajování, to je fakt.
To, že ho lidé cpou neriticky všude je problém, s tím souhlasím. Ale to neznamená to, že je JSON špatný, ale to, že je spousta lidí, co neumí vhodně volit technologie.
Ale kdybyste to řekl takto, tak byste si nemohl plivnout na JavaScript a technologie s ním související, tudíž byste si asi nesplnil denní kvótu urážek JS. Hezký. :)
No, to ti asi budu muset připomenout, čím celá tahle eskapáda začala:
To ze v zakladu toho moc neumi je spise vyhodou
Ne, není. Nejlíp je to vidět na JSONu, ze kterého se bohužel stala lingua franca.
- kdyby se toho nechytli specfičtí webaři, kteří musí za každou cenu obhajovoat, že hranatý kolo je v pohodě, protože že to mírně drncá nikomu přece nevadí, nemuseli jsme tady to vlákno vůbec zaplevelovat. Jenže webařina je zjevně specificky náboženská...
Jenže citujete reakci na vaši strašnou touhu JavaScript vymazat ze světa.
Podsouváte lidem věci, co neřekli, nebo překrucujete fakta. Nikdo tu netvrdí, že JSON je úžasný a všude použitelný formát. Jenže vaše kritika, s nadsázkou, je ve stylu "koupil jsem si kolo a ono nejelo do kopce samo, takže kolo je špatné, nikdo by ho neměl nikdy používat a všichni jezděte autem, protože to jede do kopce samo". To jste v nějaké JS a vše okolo haters sektě?
-
Nene, my NERESIME jestli cislo je nebo neni int. Cele cisla jsou podmnozinou realnych. Kdyz nekdo z nejakeho duvodu potrebuje zjistit jestli Number je integer tak ma Number.isInteger() metodu.
No - a opět nemáš pravdu. Fakt chceš něco obhajovat, když to ani neznáš?!
JS:
9007199254740991+100
> 9007199254741092
Python:
>>> 9007199254740991+100
9007199254741091
Elixir:
iex(1)> 9007199254740991+100
9007199254741091
Jinak ta lua s cislama taky moc slavy nepobrala:
Ano, čísla má udělaný stejně jako JS.
https://developer.mozilla.org/cs/docs/Web/JavaScript/Reference/Global_Objects/Number/MAX_SAFE_INTEGER
-
To, že ho lidé cpou neriticky všude je problém, s tím souhlasím. Ale to neznamená to, že je JSON špatný, ale to, že je spousta lidí, co neumí vhodně volit technologie.
Ty implikace jsou opačně:
JSON má umělá, naprosto zbytečná, snadno odstranitelná, omezení, která podědil po JS => JSON je objektivně špatný serializační formát pro cokoli kromě JS => pokud někdo urputně tvrdí, že JSON je fajn pro obecné použití, je blbec, fanatik nebo oboje.
Jenže citujete reakci na vaši strašnou touhu JavaScript vymazat ze světa.
Nechci JS vymazat ze světa. Jenom nechci, aby měl monopol jako Windows 95.
Podsouváte lidem věci, co neřekli, nebo překrucujete fakta. Nikdo tu netvrdí, že JSON je úžasný a všude použitelný formát. Jenže vaše kritika, s nadsázkou, je ve stylu "koupil jsem si kolo a ono nejelo do kopce samo, takže kolo je špatné, nikdo by ho neměl nikdy používat a všichni jezděte autem, protože to jede do kopce samo". To jste v nějaké JS a vše okolo haters sektě?
Ne. Já jenom říkám objektivní fakta, objektivní nevýhody JS, potažmo JSONu. Kdyby nebyli webaři tak specifičtí a řekli by "jasný no, tohle je fakt na palici, ale tak co už, žít se s tím dá", žádná diskuse by nevznikla.
-
https://developer.mozilla.org/cs/docs/Web/JavaScript/Reference/Global_Objects/Number/MAX_SAFE_INTEGER
No dyť. Tvrzení, že int je podmnožinou floatu je tímpádem co? Nepravdivé. Protože 64-bitový (u)int je větší než 64-bitový float.
-
JSON má umělá, naprosto zbytečná, snadno odstranitelná, omezení, která podědil po JS => JSON je objektivně špatný serializační formát pro cokoli kromě JS => pokud někdo urputně tvrdí, že JSON je fajn pro obecné použití, je blbec, fanatik nebo oboje.
Definici pro obecné použití máte?
A jinak:
http://ssjc.ujc.cas.cz/search.php?hledej=Hledat&heslo=objektivn%C4%9B&sti=EMPTY&where=hesla&hsubstr=no
Nechci JS vymazat ze světa. Jenom nechci, aby měl monopol jako Windows 95.
Takže chcete, aby zase bylo na webu peklo nekompatibility všeho se vším...
Ne. Já jenom říkám objektivní fakta, objektivní nevýhody JS, potažmo JSONu. Kdyby nebyli webaři tak specifičtí a řekli by "jasný no, tohle je fakt na palici, ale tak co už, žít se s tím dá", žádná diskuse by nevznikla.
Marně vzpomínám, kdy jsem od vás na toto téma slyšel něco objektivního.
https://developer.mozilla.org/cs/docs/Web/JavaScript/Reference/Global_Objects/Number/MAX_SAFE_INTEGER
No dyť. Tvrzení, že int je podmnožinou floatu je tímpádem co? Nepravdivé. Protože 64-bitový (u)int je větší než 64-bitový float.
WTF? A přirozená čísla nejsou podmnožinou N0, protože 64. člen první množiny je větší než u té druhé?!
-
Takže chyba není v JSONu, ale v lidech, kteří ho cpou, kam se podle vás nehodí...
V lidech, kteří ho nesmyslně obhajují a v lidech, kteří ho nekriticky cpou všude.
Je JSON špatný? Byl určen pro JS a (nejen) tam je ok. Pokud mi stačí takový vcelku jednoduchý formát, není problém ho použít jinde (a ono to pojede). To není nesmyslné obhajování, to je fakt.
To, že ho lidé cpou neriticky všude je problém, s tím souhlasím. Ale to neznamená to, že je JSON špatný, ale to, že je spousta lidí, co neumí vhodně volit technologie.
Ale kdybyste to řekl takto, tak byste si nemohl plivnout na JavaScript a technologie s ním související, tudíž byste si asi nesplnil denní kvótu urážek JS. Hezký. :)
No, to ti asi budu muset připomenout, čím celá tahle eskapáda začala:
To ze v zakladu toho moc neumi je spise vyhodou
Ne, není. Nejlíp je to vidět na JSONu, ze kterého se bohužel stala lingua franca.
- kdyby se toho nechytli specfičtí webaři, kteří musí za každou cenu obhajovoat, že hranatý kolo je v pohodě, protože že to mírně drncá nikomu přece nevadí, nemuseli jsme tady to vlákno vůbec zaplevelovat. Jenže webařina je zjevně specificky náboženská...
Jenže citujete reakci na vaši strašnou touhu JavaScript vymazat ze světa.
Podsouváte lidem věci, co neřekli, nebo překrucujete fakta. Nikdo tu netvrdí, že JSON je úžasný a všude použitelný formát. Jenže vaše kritika, s nadsázkou, je ve stylu "koupil jsem si kolo a ono nejelo do kopce samo, takže kolo je špatné, nikdo by ho neměl nikdy používat a všichni jezděte autem, protože to jede do kopce samo". To jste v nějaké JS a vše okolo haters sektě?
JS je jako jazyk objektivne odpad - ja nechapu co resite. Kdyby se dneska vytvarel prvni prohlížeč dala by se tam takova silenost? Ani nahodou - ten jazyk zkurvil cele generace programatoru a vytvoril takovej business s hovnem jako nic jinyho - opet obektivne. A v tom ma Mirda pravdu. Tecka.
-
Ne. Já jenom říkám objektivní fakta, objektivní nevýhody JS, potažmo JSONu. Kdyby nebyli webaři tak specifičtí a řekli by "jasný no, tohle je fakt na palici, ale tak co už, žít se s tím dá", žádná diskuse by nevznikla.
JSON používám, když z PHP chci něco poslat Javascriptu, případně obráceně, protože Javascript mi stejně víc informací o typu neposkytne. JSON se tedy hodí pro obousměrnou komunikaci s Javascriptem, protože ostatní jazyky se mu dokáží snadno přizpůsobit.
Pro ostatní případy používám raději XML, protože je obecnější a nemá problémy se znakovými sadami a kompatibilitou. Při správném návrhu je i stručnější než JSON.
-
Definici pro obecné použití máte?
Ano: pouziti kdekoli nejakyho joudu napadne.
Takže chcete, aby zase bylo na webu peklo nekompatibility všeho se vším...
Ty to fakt nechápeš? Pokud by prohížeč dostal bytecode, tak by ani nevěděl, z jakého jazyka vzniknul.
Marně vzpomínám, kdy jsem od vás na toto téma slyšel něco objektivního.
Rikam veci, ktere jsou overitelne a pripadne vyvratitelne. Jako napriklad, ze JSON podporuje velmi omezenou mnozinu typu, nepodporuje uzivatelske typy a timpadem je desne neprakticky pro pouziti v cemkoli jinem nez v JS.
WTF? A přirozená čísla nejsou podmnožinou N0, protože 64. člen první množiny je větší než u té druhé?!
Tak jo, jeste jednou a pomaleji:
Tvrzeni: JSON je nesikovny pro predavani dat kamkoli jinam nez mezi JS.
Priklad:
Python:
>>> import json
>>> json.dumps({"whatTheFuckIsThis": "account", "owner": "Cikada", "balance": 9007199254741091})
'{"owner": "Cikada", "balance": 9007199254741091, "whatTheFuckIsThis": "account"}'
JS:
JSON.parse('{"owner": "Cikada", "balance": 9007199254741091, "whatTheFuckIsThis": "account"}')
> Object {owner: "Cikada", balance: 9007199254741092, whatTheFuckIsThis: "account"}
Bezva. Zadna runtime chyba, zadne upozorneni, ze tohle JSON nepodporuje. Nic. Jenom se Cikadovi nepozorovane nafouklo konto. A ted mi muzete vsichni zacit vysvetlovat, ze JSON je v pohode, protoze ma number, jehoz je int podmnozinou, cili se vlastne vubec nic nedeje.
VLASTNE MOMENT! Dyt ja su debil - tohle prece vim, takze predem otestuju, jestli je cislo v nejakych hranicich. Ok. Tak fajn, neni. Cili to zakoduju do user typu. Oh wait! Ty JSON nema. Tak fajn. Co bych tak pouzil?! Dve cisla v poli? To ne, to by nekdo mohl naparsovat jako dve cisla v poli. Ok, takze objekt se spesl atributem. No jo, ale co kolize? Tak jo, vsechny objekty s takovym atributem zakoduju jako objekt v objektu! Aha, ale to je vlastne jenom muj vymysl a nikdo takovy format nepodporuje. To nevadi! Mam data v JSONu, takze dame na letak, ze jsme interoperabilni!
-
VLASTNE MOMENT! Dyt ja su debil - tohle prece vim, takze predem otestuju, jestli je cislo v nejakych hranicich. Ok. Tak fajn, neni. Cili to zakoduju do user typu. Oh wait! Ty JSON nema. Tak fajn. Co bych tak pouzil?! Dve cisla v poli? To ne, to by nekdo mohl naparsovat jako dve cisla v poli. Ok, takze objekt se spesl atributem. No jo, ale co kolize? Tak jo, vsechny objekty s takovym atributem zakoduju jako objekt v objektu! Aha, ale to je vlastne jenom muj vymysl a nikdo takovy format nepodporuje. To nevadi! Mam data v JSONu, takze dame na letak, ze jsme interoperabilni!
https://www.npmjs.com/package/big-integer
do JSONu to ukládejte jako string.
-
do JSONu to ukládejte jako string.
Fantasickej napad. A co kdybych do toho stringu ulozil msgpack? Jak by se to lisilo?
-
Ja uz sem se uplne ztratil - nevim o cem se bavite, co myslite vazne, co ironicky co ikonicky - za me zasadni ze kdyz neco neni a ja to vytvorim tak že to je - kite znormalizuj to prosim...
Tak ještě jednou a lépe:
var footballTeams = [
{'NAME': 'FC Barcelona', 'NICK': 'Barca', 'ABBR': 'FCB'}
];
Ještě v XML:
<football>
<team NICK="Barca" ABBR="FCB">FC Barcelona</team>
</football>
V XML je vidět, co je atom a co je string.
-
JS je jako jazyk objektivne odpad - ja nechapu co resite. Kdyby se dneska vytvarel prvni prohlížeč dala by se tam takova silenost? Ani nahodou - ten jazyk zkurvil cele generace programatoru a vytvoril takovej business s hovnem jako nic jinyho - opet obektivne. A v tom ma Mirda pravdu. Tecka.
http://ssjc.ujc.cas.cz/search.php?hledej=Hledat&heslo=objektivn%C4%9B&sti=EMPTY&where=hesla&hsubstr=no ;)
Definici pro obecné použití máte?
Ano: pouziti kdekoli nejakyho joudu napadne.
To se potom dá říct o každé technologii.
Takže chcete, aby zase bylo na webu peklo nekompatibility všeho se vším...
Ty to fakt nechápeš? Pokud by prohížeč dostal bytecode, tak by ani nevěděl, z jakého jazyka vzniknul.
Vize hezká, ale IMHO nereálná.
Tak jo, jeste jednou a pomaleji:
Tvrzeni: JSON je nesikovny pro predavani dat kamkoli jinam nez mezi JS.
K čemuž nebyl určený? Takže kritizujete JSON, protože se nehodí na něco, na co nebyl prvotně vytvářen? To, že ho strkají všude možně není chyba JSONu. (jinak s tím kamkoliv bych to neviděl tak žhavé)
-
To, že ho strkají všude možně není chyba JSONu.
Jasně, však já nemám nic proti tomu, aby se JSONem posílaly přes websockety zprávy typu
{event: "newChatMessage", sender: "Franta", msg: "specificka webarina"}
-
- kdyby se toho nechytli specfičtí webaři, kteří musí za každou cenu obhajovoat, že hranatý kolo je v pohodě, protože že to mírně drncá nikomu přece nevadí, nemuseli jsme tady to vlákno vůbec zaplevelovat. Jenže webařina je zjevně specificky náboženská...
Se pletes, kdyz je neco chybne ja nemam problem uznat, ze to chybne je. Jezne v JS chyby nejsou, jsou proste specifika implementace 8) A stejny to je u vsech jazyku, kazdy ma svoje specifika. Kdyby byl JS vadnej vzdyt by chcip po pul roce od vypusteni do sveta. Jenze ouha, "hranaty kolo navrezeno laiky" ovladlo frontendovej svet a pali posledni salvu do proridlych hradeb backendu kde zvitezi take. Protoze nac psat kody 2x v ruzych jazycich kdyz staci JavaScript.
Sekta jste spise vy logicti vedatori. Asi by sem vam zritil svet kdyby ste uznali, ze JS & JSON je cool na mnoho veci, ale ne najdete edge case co nikoho nezajima krome tri logickych vedatoru s poruchou osobnosti made in root.cz a kolem toho onanujete. Btw gratuluji tohle vlakno ma 300 vicemene nic neresicich prispevku, protoze i zitra i poztir na tebe vybafne jak json tak jsvascript a nic s tim nenadelas.
No dyť. Tvrzení, že int je podmnožinou floatu je tímpádem co? Nepravdivé. Protože 64-bitový (u)int je větší než 64-bitový float.
WTF? A přirozená čísla nejsou podmnožinou N0, protože 64. člen první množiny je větší než u té druhé?!
To neres, to jsou logicti vedatori, nedaji ti za pravdu i kdyz ji mas. Jeste opindaji tvoji ucitelku matiky ze zakladky, ze co za bludy te ucila, ze cele cisla jsou podmnozina realnych ze ?
-
To, že ho strkají všude možně není chyba JSONu.
Jasně, však já nemám nic proti tomu, aby se JSONem posílaly přes websockety zprávy typu
{event: "newChatMessage", sender: "Franta", msg: "specificka webarina"}
;)
ale je škoda, že se ten mor šíří dál a dál... Vyhrál největší shit široko daleko...
-
Sekta jste spise vy logicti vedatori. Asi by sem vam zritil svet kdyby ste uznali, ze JS & JSON je cool na mnoho veci, ale ne najdete edge case co nikoho nezajima krome tri logickych vedatoru s poruchou osobnosti made in root.cz a kolem toho onanujete. Btw gratuluji tohle vlakno ma 300 vicemene nic neresicich prispevku, protoze i zitra i poztir na tebe vybafne jak json tak jsvascript a nic s tim nenadelas.
Nojo, kámo, jenže právě corner cases odlišují dobrá a špatná řešení. Jde totiž o to, jetli se na tu danou věc dá spolehnout. Pokud má nějaké prokazatelné vlastnosti, tak se nad ní dá dobře uvažovat (reason) a tímpádem i spolehlivě dál stavět.
...a tohle je přesně ten kořen problémů webového světa ilustrovaný v tom zmíněným https://hackernoon.com/how-it-feels-to-learn-javascript-in-2016-d3a717dd577f - vezme se totiž nějaký vachrlatý hliněný základ (corner cases přece nikoho nezajímají, je to good enough!), na něm se postaví eiffelovka, ta se začne naklánět, tak se podepře lešením ze sirek, který začnou praskat, tak se to celý omotá dvěma tunama lepící pásky a do manuálu se napíše, že to celý funguje, pokud je venku míň než 30 st. C, protože pak začne páska měknout a povolovat. Ok. A pak po webu poskakujou webaři s tvrzením "to není bug, ale feature, si to přečti vole v manuálu, že to můžeš používat jenom do 30 st. C". Načež vyjde nová verze JS, kde se celá ta koule z lepící pásky omotá deseti tunama ocelového řetězu, takže už to přežije víc než 30, ale zas je to těžký a naklání se to pro změnu na druhou stranu. Ok, už víme, že sirky jsou blbý řešení, tak uděláme lešení z brček. Neonových, protože to je cool.
Hele, klidně si mysli, co chceš, já se ti jenom snažím pomoct uvědomit si, že úhelným kamenem IT je předvídatelnost a schopnost o věcech strukturovaně logicky uvažovat. Čím dýl budeš logický uvažování považovat za "vědátorskou onanii", tím dýl budeš dělat shitový produkty, o který bude postupně opadat zájem - stejně jako opadl zájem o správce Windows 95, kteří se cítili na koni, dokud měly W95 monopol. Dneska jsou z nich pupkatí pánové, kteří si horkotěžko vydělávají pár korun v zaflusaným krámku, kde lidem čistí v komplu ventilátory.
-
Sekta jste spise vy logicti vedatori. Asi by sem vam zritil svet kdyby ste uznali, ze JS & JSON je cool na mnoho veci, ale ne najdete edge case co nikoho nezajima krome tri logickych vedatoru s poruchou osobnosti made in root.cz a kolem toho onanujete. Btw gratuluji tohle vlakno ma 300 vicemene nic neresicich prispevku, protoze i zitra i poztir na tebe vybafne jak json tak jsvascript a nic s tim nenadelas.
Nojo, kámo, jenže právě corner cases odlišují dobrá a špatná řešení. Jde totiž o to, jetli se na tu danou věc dá spolehnout. Pokud má nějaké prokazatelné vlastnosti, tak se nad ní dá dobře uvažovat (reason) a tímpádem i spolehlivě dál stavět.
...a tohle je přesně ten kořen problémů webového světa ilustrovaný v tom zmíněným https://hackernoon.com/how-it-feels-to-learn-javascript-in-2016-d3a717dd577f - vezme se totiž nějaký vachrlatý hliněný základ (corner cases přece nikoho nezajímají, je to good enough!), na něm se postaví eiffelovka, ta se začne naklánět, tak se podepře lešením ze sirek, který začnou praskat, tak se to celý omotá dvěma tunama lepící pásky a do manuálu se napíše, že to celý funguje, pokud je venku míň než 30 st. C, protože pak začne páska měknout a povolovat. Ok. A pak po webu poskakujou webaři s tvrzením "to není bug, ale feature, si to přečti vole v manuálu, že to můžeš používat jenom do 30 st. C". Načež vyjde nová verze JS, kde se celá ta koule z lepící pásky omotá deseti tunama ocelového řetězu, takže už to přežije víc než 30, ale zas je to těžký a naklání se to pro změnu na druhou stranu. Ok, už víme, že sirky jsou blbý řešení, tak uděláme lešení z brček. Neonových, protože to je cool.
Hele, klidně si mysli, co chceš, já se ti jenom snažím pomoct uvědomit si, že úhelným kamenem IT je předvídatelnost a schopnost o věcech strukturovaně logicky uvažovat. Čím dýl budeš logický uvažování považovat za "vědátorskou onanii", tím dýl budeš dělat shitový produkty, o který bude postupně opadat zájem - stejně jako opadl zájem o správce Windows 95, kteří se cítili na koni, dokud měly W95 monopol. Dneska jsou z nich pupkatí pánové, kteří si horkotěžko vydělávají pár korun v zaflusaným krámku, kde lidem čistí v komplu ventilátory.
Ten reasoning má naučit VŠ :) Možná už SŠ, my měli na gymplu učitelku, která na nás v matice házela příklady ze života, každé zadání bylo formulované v rámci nějaké situace z reálného světa, někdy skoro až přehnaně uměle, ale nikdy to nebylo "tady máte rovnici a vypočítejte x".
-
Sekta jste spise vy logicti vedatori. Asi by sem vam zritil svet kdyby ste uznali, ze JS & JSON je cool na mnoho veci, ale ne najdete edge case co nikoho nezajima krome tri logickych vedatoru s poruchou osobnosti made in root.cz a kolem toho onanujete. Btw gratuluji tohle vlakno ma 300 vicemene nic neresicich prispevku, protoze i zitra i poztir na tebe vybafne jak json tak jsvascript a nic s tim nenadelas.
Nojo, kámo, jenže právě corner cases odlišují dobrá a špatná řešení. Jde totiž o to, jetli se na tu danou věc dá spolehnout. Pokud má nějaké prokazatelné vlastnosti, tak se nad ní dá dobře uvažovat (reason) a tímpádem i spolehlivě dál stavět.
...a tohle je přesně ten kořen problémů webového světa ilustrovaný v tom zmíněným https://hackernoon.com/how-it-feels-to-learn-javascript-in-2016-d3a717dd577f - vezme se totiž nějaký vachrlatý hliněný základ (corner cases přece nikoho nezajímají, je to good enough!), na něm se postaví eiffelovka, ta se začne naklánět, tak se podepře lešením ze sirek, který začnou praskat, tak se to celý omotá dvěma tunama lepící pásky a do manuálu se napíše, že to celý funguje, pokud je venku míň než 30 st. C, protože pak začne páska měknout a povolovat. Ok. A pak po webu poskakujou webaři s tvrzením "to není bug, ale feature, si to přečti vole v manuálu, že to můžeš používat jenom do 30 st. C". Načež vyjde nová verze JS, kde se celá ta koule z lepící pásky omotá deseti tunama ocelového řetězu, takže už to přežije víc než 30, ale zas je to těžký a naklání se to pro změnu na druhou stranu. Ok, už víme, že sirky jsou blbý řešení, tak uděláme lešení z brček. Neonových, protože to je cool.
Hele, klidně si mysli, co chceš, já se ti jenom snažím pomoct uvědomit si, že úhelným kamenem IT je předvídatelnost a schopnost o věcech strukturovaně logicky uvažovat. Čím dýl budeš logický uvažování považovat za "vědátorskou onanii", tím dýl budeš dělat shitový produkty, o který bude postupně opadat zájem - stejně jako opadl zájem o správce Windows 95, kteří se cítili na koni, dokud měly W95 monopol. Dneska jsou z nich pupkatí pánové, kteří si horkotěžko vydělávají pár korun v zaflusaným krámku, kde lidem čistí v komplu ventilátory.
Blbost. Pojďme si ho poměřit na hackerrank.
-
Blbost. Pojďme si ho poměřit na hackerrank.
Co s cim chces pomerovat? V roce 1996 byla taky shanka po lidech, kteri znaji Windows 95. Pred sedmi lety byla shanka po lidech, kteri umi jQuery...
-
Blbost. Pojďme si ho poměřit na hackerrank.
Co s cim chces pomerovat? V roce 1996 byla taky shanka po lidech, kteri znaji Windows 95. Pred sedmi lety byla shanka po lidech, kteri umi jQuery...
Poměříme efektivitu. Každý může řešit ve svém oblíbeném jazyce.
-
Pred sedmi lety byla shanka po lidech, kteri umi jQuery...
Znalost jQuery se hodí i dnes.
-
Čím dýl budeš logický uvažování považovat za "vědátorskou onanii", tím dýl budeš dělat shitový produkty, o který bude postupně opadat zájem - stejně jako opadl zájem o správce Windows 95...
Kecy uplne vedle. Mozna jsem mel stesti ale o me "produkty" byl a stale je docela zajem. Od gymplu co jsem busil sklady v Pascalu a DbaseIV, pres vejsku kde se busilo od vedatoriny pres grafiku az po neuronky (c/c++,lisp,prolog) pak prisla era webu, prezil jsem ASP, PHP, SQL, OLAP a pak jsem backend povesil na hrebik a ted se uz specializuji jen na frontend a trolim vedatory tim jak je JavaScript skvelej. Jak tak koukam docela me obesla Java a ani nevim jestli je to dobre nebo ne ::)
-
Poměříme efektivitu. Každý může řešit ve svém oblíbeném jazyce.
Proc bych to pripanajana mel delat?! Fakt mne neni sedmnact :)
Znalost jQuery se hodí i dnes.
Jasny.
-
a trolim vedatory tim jak je JavaScript skvelej. Jak tak koukam docela me obesla Java a ani nevim jestli je to dobre nebo ne ::)
Tak jestli ve tvym pojeti "trolit" znamena delat ze sebe na webu vola pouzivanim terminu, kterym nerozumis, tak ti to jde skvele :)
-
Poměříme efektivitu. Každý může řešit ve svém oblíbeném jazyce.
Proc bych to pripanajana mel delat?! Fakt mne neni sedmnact :)
Nech ho aspoň napsat zadání, třeba projednou nenapíše debilní výblitek a bude to stát aspoň za zamyšlení.
-
Poměříme efektivitu. Každý může řešit ve svém oblíbeném jazyce.
To mas jak mereni pindiku.. Hele, kazdej programovaci jazyk je kladivo a at je sebelepsi porad s nim musis busit. Resit hlouposti, ktere kladivo je lepsi je osemetna zalezitost protoze zalezi take na hrebiku, ktery je potreba zatlouct. Zakonite nektere kladivo bude rychlejsi, nektere muze hrebik ohnout atd. Proste to moc nereste a buste s kladivem, ktere je zrovna po ruce a hotovo. Protoze dulezite je umet busit, to cim a po cem je uz vedlejsi.
Bushido.
-
Resit hlouposti, ktere kladivo je lepsi je osemetna zalezitost protoze zalezi take na hrebiku, ktery je potreba zatlouct.
Ke spravne volbe kladiva si ale musis umet priznat, ze tvoje oblibene kladivo ma nedostatky a dobre vedet jake. Coz je to, o co tu kraci.
-
Resit hlouposti, ktere kladivo je lepsi je osemetna zalezitost protoze zalezi take na hrebiku, ktery je potreba zatlouct.
Ke spravne volbe kladiva si ale musis umet priznat, ze tvoje oblibene kladivo ma nedostatky a dobre vedet jake. Coz je to, o co tu kraci.
Unika ti pointa. Ja tu volbu nedelam, tu dela za mne svet. Asi se opakuji, mozna nedostanu do rukou idealni kladivo ale na svou dobu a ucel je optimalni. "Ma nedostatky" je individualni zalezitost, nekoho vytaci 9007199254740991+100 a tvrdi ze to je nedostatek. Nekoho zas vytaci neexistence privatnich properties, ja to naopak vitam (o chybovu blocking hlasku mene). JavaScript je sikovne a sexy kladivko, navic si ho muzes vytunit v poradnyho macka dle libosti.
-
... Nekoho zas vytaci neexistence privatnich properties, ja to naopak vitam (o chybovu blocking hlasku mene).
No vidíš, mě vytáčí i veřejné gettery a settery, kterých jsou nejen javovské programy plné. Všechno má být hezky privátní.
-
Protoze dulezite je umet busit, to cim a po cem je uz vedlejsi.
Důležité je umět bušit, ale důležitější je vybrat si správný nástroj. To je podle mě jedna z věcí, co odlišuje dobrého programátora od toho "tuctového", protože každá technologie má své pro a proti. A "ten dobrý" by měl vybrat optimální řešení. Ano, ne vždy je jednoduché odhadnout, co je v tu chvíli nejlepší, ale cpát všude svůj oblíbený jazyk je pomalu stejně špatná cesta, jako schválně se vyhýbat svému neoblíbenému.
-
Presne tak, treba milovat vsetky jazyky a je po probleme.
-
Ne, to jsem tím přesně říct nechtěl.
-
Resit hlouposti, ktere kladivo je lepsi je osemetna zalezitost protoze zalezi take na hrebiku, ktery je potreba zatlouct.
Ke spravne volbe kladiva si ale musis umet priznat, ze tvoje oblibene kladivo ma nedostatky a dobre vedet jake. Coz je to, o co tu kraci.
Někdy je dobré si kladivo nejdřív vyzkoušet, přečíst si alespoň základní tutoriál z oficiální dokumentace a nečertpat informace jen z rádoby vtipných videí.
-
par slov od odbornika ktory nepouziva iba jedno kladivo :)
https://youtu.be/F07Ov4Y6xQ0?t=22
-
par slov od odbornika ktory nepouziva iba jedno kladivo :)
https://youtu.be/F07Ov4Y6xQ0?t=22
na větší výkovky bych raději použil tohle
https://www.youtube.com/watch?v=msLm4uPxTr0
-
par slov od odbornika ktory nepouziva iba jedno kladivo :)
https://youtu.be/F07Ov4Y6xQ0?t=22
na větší výkovky bych raději použil tohle
https://www.youtube.com/watch?v=msLm4uPxTr0
Tak vidim ze ste preci jenom k necemu dosli - blahopreju a snad uz se nepotkame - děkuji byli ste skveli!
-
a trolim vedatory tim jak je JavaScript skvelej. Jak tak koukam docela me obesla Java a ani nevim jestli je to dobre nebo ne ::)
Tak jestli ve tvym pojeti "trolit" znamena delat ze sebe na webu vola pouzivanim terminu, kterym nerozumis, tak ti to jde skvele :)
Další troll do sbírky ;)
-
Jen pro upřesnění, ne, že bych měl JSON nějak zvlášť rád:
Když dekódujete číslo s desetiným místem, logicky chcete float. Když číslo bez desetiného místa, tak vám může být jedno co dostanete.
Ne a ne. Jestli se JSON "3.0" vyparsuje jako int nebo float je nedefinované. Naopak zakódovat int 3 jako 3.0 je plně legitimní. Z čeho a jak plyne, že "logicky chci float", to fakt nevím. Od serializačního formátu především chci, abych z něj dostal to, co jsem do něj dal. Pokud to neplatí ani pro základní věc jako číslo, je to prostě debilní serializační formát a není o čem diskutovat.
Výraz nedefinované mi přijde krapet silné vyjádření. Každopádně v JSON je číslo definováno typem number. Který není ani Int, ani Float. Takže podobně jako když v Haskellu rozlišuju, čím budu reprezentovat JSON typ string - zda použiju typ String, typ Text, nebo ByteString; podobně i v případě JSON typu numeric musím přemýšlet čím ho budu v Haskellu reprezentovat. Protože s Intem si nevystačím (když tam chci ukládat Float, což jde).
Pokud bude ten parser rozumný, tak:
decode "1" -> 1.0 :: Float
decode "1.0" -> 1.0 :: Float
encode 1.0 :: Float -> "1.0" -- ale může i "1"
encode 1 :: Int -> "1.0" -- ale může i "1"
encode (9007199254740991+100) :: Int -> "\"9007199254741091\"" -- nebo spíše error "příliš velké číslo"
decode "9007199254741091" -> error "příliš velké číslo" -- páč rozsah je IMHO definicí určen
Takže můžem nadávat na JSON, že je to debilně triviální jazyk. Můžem nadávat, že nám v něm schází to či ono. Ale spousta výtek jde spíše na vrub parserům v tom kterém jazyce.
-
Výraz nedefinované mi přijde krapet silné vyjádření.
Nevím, jak jinak bych to měl nazvat. Jak správně píšeš, JSON má typ number. Jenže drtivá většina jazyků tenhle typ nemá. Specifikace JSONu afaik nedefinuje, jak se takové jazyky mají k number stavět. Čili se k tomu můžou stavět různě podle toho, co autoři uznají za "rozumné", protože specifikace jim neříká, co mají dělat.
decode "9007199254741091" -> error "příliš velké číslo" -- páč rozsah je IMHO definicí určen
Ne, ani ten rozsah není specifikací určen. Takže si opět můžeš zvolit čistě libovolně. Třeba 3 :)
http://www.ecma-international.org/publications/files/ECMA-ST/ECMA-404.pdf - kap. 8
Takže můžem nadávat na JSON, že je to debilně triviální jazyk. Můžem nadávat, že nám v něm schází to či ono. Ale spousta výtek jde spíše na vrub parserům v tom kterém jazyce.
Pokud specifikace nespecifikuje zásadní věci, tak není dobrý nebo špatný parser. Jsou prostě různé parsery. Jediné, co je jisté, je, že je špatná specifikace ;)
-
BTW,
Warning
The precise treatment of the “integer” type may depend on the implementation of your JSON Schema validator. JavaScript (and thus also JSON) does not have distinct types for integers and floating-point values. Therefore, JSON Schema can not use type alone to distinguish between integers and non-integers. The JSON Schema specification recommends, but does not require, that validators use the mathematical value to determine whether a number is an integer, and not the type alone. Therefore, there is some disagreement between validators on this point. For example, a JavaScript-based may accept 1.0 as an integer, whereas the Python-based jsonschema does not.
https://spacetelescope.github.io/understanding-json-schema/reference/numeric.html
To je "specifikace" jak poď na mě zboku.
-
decode "9007199254741091" -> error "příliš velké číslo" -- páč rozsah je IMHO definicí určen
Ne, ani ten rozsah není specifikací určen. Takže si opět můžeš zvolit čistě libovolně. Třeba 3 :)
tak specifikace předepisuje notaci, ale neomezuje rozsah, neřekl bych, že to je špatně
-
BTW,
Warning
The precise treatment of the “integer” type may depend on the implementation of your JSON Schema validator. JavaScript (and thus also JSON) does not have distinct types for integers and floating-point values. Therefore, JSON Schema can not use type alone to distinguish between integers and non-integers. The JSON Schema specification recommends, but does not require, that validators use the mathematical value to determine whether a number is an integer, and not the type alone. Therefore, there is some disagreement between validators on this point. For example, a JavaScript-based may accept 1.0 as an integer, whereas the Python-based jsonschema does not.
https://spacetelescope.github.io/understanding-json-schema/reference/numeric.html
To je "specifikace" jak poď na mě zboku.
IMHO JSON a JSON Schema jsou odlišné věci (každá s vlastní specifikací)
-
To je "specifikace" jak poď na mě zboku.
Ale vzdyt to psali vedatori © Space Telescope Science Institute, to uz se trolite i mezi sebou ? Pro inzenyra je popis tak akorat.
-
IMHO JSON a JSON Schema jsou odlišné věci (každá s vlastní specifikací)
Ano, ale tohle je ten problém, o kterém se bavíme - je zavlečený z JSONu potažmo z JS.
-
IMHO JSON a JSON Schema jsou odlišné věci (každá s vlastní specifikací)
Ano, ale tohle je ten problém, o kterém se bavíme - je zavlečený z JSONu potažmo z JS.
osobně v ECMA-404 žádný problém nevidím (ale poprvé jsem to četl dneska...), konkrétně ECMA-404/number má míň problémů než javascript number (ale nejsem expert na js)
-
BTW,
Warning
The precise treatment of the “integer” type may depend on the implementation of your JSON Schema validator. JavaScript (and thus also JSON) does not have distinct types for integers and floating-point values. Therefore, JSON Schema can not use type alone to distinguish between integers and non-integers. The JSON Schema specification recommends, but does not require, that validators use the mathematical value to determine whether a number is an integer, and not the type alone. Therefore, there is some disagreement between validators on this point. For example, a JavaScript-based may accept 1.0 as an integer, whereas the Python-based jsonschema does not.
https://spacetelescope.github.io/understanding-json-schema/reference/numeric.html
To je "specifikace" jak poď na mě zboku.
Nehanej nahodou frikulini soap (a XML obecne) proto, ze prej je zbytecne slozitej, a ze jim json staci? lol ... neni nad to porad dokola vymejslet kolo.
-
decode "9007199254741091" -> error "příliš velké číslo" -- páč rozsah je IMHO definicí určen
Ne, ani ten rozsah není specifikací určen. Takže si opět můžeš zvolit čistě libovolně. Třeba 3 :)
tak specifikace předepisuje notaci, ale neomezuje rozsah, neřekl bych, že to je špatně
Tak já tam vidím něco o devíti cifrách. http://www.json.org. (Ale nějak zvláštně jsem to nezkoumal.)
Eh, sorry, špatně jsem to pochopil, ty cifry.