Zobrazit příspěvky
Tato sekce Vám umožňuje zobrazit všechny příspěvky tohoto uživatele. Prosím uvědomte si, že můžete vidět příspěvky pouze z oblastí Vám přístupných.
Chtěl tím říci, že puristi…Ovšem je hloupé, když chce být někdo purista a puntičkář, a zamotá break mezi způsoby, jak v C ukončit funkci. Čtenář pak totiž může pochybovat, jestli dotyčný vůbec umí programovat…
Navrhoval by som spravne pouzit strukturovane programovanie a vyhnut sa returnom a breakom uprostred procedury.Mohl byste uvést konkrétní příklad, kdy může být v C break na konci procedury (a má tam nějaký smysl)?
Měl jsem za to, že se bavíme o přednostech a nedostatcích formátů, ne o nezávislých nástrojích k nim vytvořených (které si koneckonců můžete vyrobit i sám).Pokud se budeme bavit pouze o samotném formátu a budeme ignorovat infrastrukturu, která kolem formátu existuje, bude vždy nejlepší nějaký vlastní proprietární formát vytvořený přesně na míru danému případu. Napíšete si k němu superrychlý parser, vlastní serializer a vše, co budete potřebovat.
A ještě k tomuhle. On v tom srovnání vysvětluje, proč použil tu ukecanější variantu. Je to proto, že XML dovoluje právě víc zápisů a v dost případech je použita právě ta delší. Vždyť i tohle vlákno začalo tím, jestli použít tu delší nebo kratší verzi. Takže dává smysl se ptát, jaká je cena za tuhle flexibilitu (obzvlášť pokud zůstane nevyužitá).Ehm... Kdyby to aspoň napsal někdo jiný...
Kdybyste řešil smysl textu, a ne jaká konkrétní slovíčka jsou použitá v které větě, bylo by vám to jasné.Jenže tady nikdo netvrdil, že XML není ukecané. Psal jsem, že XML ukecané je, a je to tak záměrně, aby bylo dobře čitelné pro lidi.Ehm... Kdyby to aspoň napsal někdo jiný...Jak už bylo napsáno, XML není ukecané.Až se rozhodnete, jestli xml není ukecané, nebo je dobře že je ukecané, tak možná bude mít smysl o něčem diskutovat.
Napsáno tu bylo spousta věcí. Ale když se podívám na nějaké testy https://www.infragistics.com/community/blogs/b/torrey-betts/posts/mobile-performance-testing-json-vs-xml nebo https://www.codeproject.com/Articles/604720/JSON-vs-XML-Some-hard-numbers-about-verbosity tak to tak opravdu nevypadá.Napsáno tu bylo spousta věcí, a vy je ignorujete. „Ukecanost“ formátu není užitečná proto, aby se lépe četl strojům, ale aby se lépe četl lidem. Takže ta vaše měření jsou sice hezká, ale měří něco úplně jiného.
Ono se stačí podívat na svg. Velké kusy toho formátu vlastně nejsou xml, ale stringy s vlastním výrazně jednodušším formátem. Přepsat to do xml by i při použití jednoznakových elementů strašně nabobtnalo. Seznamy v JSONu jsou daleko kompaktnější.Nikdo netvrdí, že SVG je dobře navržený XML formát. Znovu argumentujete tím, že větší XML je špatně, ale otázka zněla, proč je to špatně. Já jsem uváděl důvod, proč „ukecané“ XML je správně. Pokud chci formát, který se bude dobře zpracovávat strojům, nebudu vůbec používat textový formát, ale nějaký binární. JSON je v tomhle horší, protože je špatně čitelný i pro lidi i pro stroje.
Já netvrdím, že XML je vždycky bloat. Ve spoustě případů ta ukecanost nevadí. Ale tvrdit, že ukecané není, je fakt síla.Jenže tady nikdo netvrdil, že XML není ukecané. Psal jsem, že XML ukecané je, a je to tak záměrně, aby bylo dobře čitelné pro lidi.
Ano, jeden z problémů XML je, že je to moloch.Co přesně je moloch? Standard, formát, nějaká knihovna?
Ano, kdybychom měli XML bez nevýhod XML, tak bychom JSON možná nepotřebovali.Které jsou to ty nevýhody? Já jsem psalo jedné vlastnosti, která se prakticky nepoužívá, takže to XML bez nevýhod XML se reálně používá. Navíc pořád nějak nevidím ty výhody JSONu oproti XML. Že nemá komentáře? Že nejsou prakticky dostupné nástroje pro validaci schémat, pro dotazování, pro transformace?
To máte dobré. Pro řešení mých problémů potřebuju získat data z celého JSONu jeho stupidní deserializací. Vybírat kusy pomocí jakýchkoliv dotazů je mi na houby. Prostě řeším úplně jiné problémy, než vy.Tak to vám gratuluju, že vždy dostáváte jenom perfektně zdokumentované JSONy, u kterých máte 100% jistotu, že té dokumentaci odpovídají. Takže je můžete zpracovávat jenom aplikací a nikdy nemusíte řešit žádné problémy. Mně se dostávají do rukou JSONy, které tak perfektně zdokumentované nejsou, občas je podezření, že někde není něco úplně v pořádku, takže je potřeba ten JSON otevřít ručně a podívat se dovnitř. Až někdy budete muset nějaký JSON otevřít v textovém editoru, pochopíte, o čem píšu.
Že je ukecanějšíTo je výhoda, nikoli nevýhoda.
pomaleji se parsuje. Že to zrovna ve vašem případě nevadí neznamená, že někdo jiný nemůže řešit diametrálně odlišné problémy, kde to sakra vadí.Souhlasím, XML se parsuje pomaleji než vhodně zvolený binární formát. Ale pokud budu potřebovat rychlé parsování, nebudu používat JSON. Navíc i to XML může být při parsování rychlejší, protože si můžu pomocí XML schématu určit, že třeba důležité položky mají být na začátku, a zbytek dokumentu můžu klidně ignorovat. JSON musím rozparsovat celý, protože ta důležitá položka klidně může být až úplně na konci.
Že se to doplňuje až po letech znamená, že to leta nikdo až tak moc nepotřeboval (nebo v případech že jo, použil něco jiného).A nebo nevěděl, že to, co dělá otrocky ručně, se dá dělat i civilizovaně.
Spíš jako bez šroubováku. A je spousta programátorů, co už leta nepotkala šroubek, ale zato pravidelně zatloukají hřebíky.Ne, je to jako bez rukou. Ano, někteří lidé, kteří se bez rukou narodili, zvládnou i nohama nebo ústy neuvěřitelné věci, ale drtivá většina lidí lépe a rychleji píše, jí, obléká se a jinak pracuje rukama než nohama. A to, že jste nikdy nepotřeboval otevřít JSON v textovém editoru a něco tam najít nebo třeba spočítat počet položek, vám nevěřím.
To "jednoduchý až je hloupý" je ale ta killer featura, kvůli které se ujal.Nikoli, ujal se proto, že se (zpočátku natvrdo přes eval()) používal na webu, a web zažil obrovský rozmach. A ruku v ruce to šlo s tím, že lidé od webu byli zvyklí, že nemají pořádné nástroje ani specifikace a musí spoustu věcí řešit hrubou lidskou silou, takže jim na JSONu nepřišlo nic zvláštního.
Prostě jsou aplikace, kde cokoliv navíc je fakt zbytečné.Vy se pořád tváříte, jako by to „něco navíc“ bylo v XML povinné a nějak vám to překáželo. Když nechcete používat schémata, transformace nebo dotazování, používat to nemusíte, a neplatíte za to žádné náklady. Ale máte tu možnost.
Ale v základu je JSON pořád jednoduchý nástroj vhodný na řešení jednoduchých problémů.Ty jednoduché problémy, které řeší JSON, řeší XML lépe. Jediná věc, ve které je JSON skutečně lepší, než XML, je ta, že parser z JSONu do JavaScriptových objektů je součástí webových prohlížečů, ale parser z XML do JavaScript objektů ve webových prohlížečích není. Bohužel tohle je ta klíčová vlastnost, která rozhodla v případě webu. Ale je vidět, že jinde JSON neuspěl – sice se z webu šířil dál, ale lidé s ním nejsou spokojení. Proto vznikl třeba YAML.
Ten JSON parser je ale prece sanity check + eval.To by byla ta nejhloupější možná implementace. Protože ten sanity check by v sobě musel obsahovat parser JavaScriptu. Pořád jednodušší je parsovat JSON než JavaScript.
Ale nekdo kdo dela v javasciptu muze mit jiny nazor(na co parsery, dotazovani, knihovny... kdyz je to prece rovnou objekt )Že je to „přece rovnou objekt“ je obrovská bezpečnostní díra a snad už to tak nikdo nepoužívá. I v tom JavaScriptu bylo potřeba napsat na JSON parser – a mimochodem prohlížeče měly z JavaScriptu dostupný XML parser dříve než JSON parser. Že je teď v prohlížečích podpora pro JSON lepší než podpora XML je pravda, ale kvůli tomu nebylo potřeba vytvářet nový formát. Ale je pravda, že zrovna webový svět nenávidí XML opravdu fest a neváhá kvůli tomu dělat některé pitomosti i opakovaně. Takže HTML5 musí mít samozřejmě svou vlastní serializaci, která je hodně podobná XML, ale XML to není. A aby dokázali, že jmenné prostory fakt nepotřebují, vymysleli nejdřív data-atributy, potom vložení SVG a MathML přímo do HTML5 standardu, a nejnověji webové komponenty. Ale ng- je určitě aspoň o 376 % lepší zápis než ng:.
Ta cena je rozpuštěná v celkové nešikovnosti a ukecanosti xml.Jak už bylo napsáno, XML není ukecané.
A taky třeba ve velikosti knihoven, které jsou na to xml potřeba.Nikoli. Pro transformace nebo dotazování jsou jiné knihovny, než pro parsování XML. Složitost XML parserů je způsobená DTD a uživatelskými entitami, které stejně nikdo nepoužívá. Takže by úplně stačilo vydat standard XML 1.2, který tohle vyhodí, kodifikovalo by se tak to, jak se XML reálně používá, a nemuseli se vymýšlet hlouposti jako JSON.
Jak jsem psal, záleží na kontextu. V práci nedělám školní příklady, ale nic ze zmíněného jsem za poslední roky nepotřeboval. I kdyby to bylo úplně zadarmo, tak je mi to k ničemu.Já to potřebuji tak v polovině případů práce s JSON. Spíš bych řekl, že vás ani nenapadlo, že byste mohl něco takového potřebovat. Že byste třeba informace z JSON souboru mohl získat jednoduchým dotazem, než abyste něco zjišťoval ručně.
Ono to není "XML znovu a hůře".Bohužel je. Opravdu špatně je na XML jen zmiňované DTD spolu s uživatelskými entitami, a odpůrci XML ani netuší, že něco takového existuje, takže to nemohou kritizovat. Jinak se do JSONu postupně doplňuje vše, co už XML dávno má – pokud je to možné. A když to není možné, jako ty komentáře, začne se vymýšlet nějaký JSON5.
Ono je to "něco jako XML s dost odlišnými kompromisy".Mohl byste nějaký z těch odlišných kompromisů popsat? Zajímala by mne jediná výhoda JSONu oproti XML. Jaká je výhoda absence komentářů? Jaká je výhoda toho, že se teprve po letech doplňují jazyky pro schémata nebo dotazování, přičemž stále nejsou běžnou součástí nástrojů pro JSON? Jaká je výhoda absence jmenných prostorů?
A ujalo se právě proto, že ve spoustě případů jsou výhody xml bezcenné a zůstává jen lehký ale všudypřítomný opruz.Pokaždé, když dělám s JSONem, připadám si, jak kdyby mi chyběly obě ruce. Pro někoho, kdo se narodil už bez rukou, mohou opravdu ruce připadat bezcenné. Ale není to tak. A ten „lehký ale všudypřítomný opruz“ je co přesně? Že vám editor musí doplnit název koncového tagu, a XML se pak mnohem lépe čte?
A že se občas ukáže, že byly počáteční analýzy mimo, je bohužel smutná realita vývoje.Smutná realita v tomto případě je, že jsme tu měli docela dobře fungující XML s ekosystémem, který se dále zlepšoval, a místo toho, aby se odpárala ta jedna nepoužívaná ošklivá vlastnost XML, přišlo se s novým formátem, který měl být údajně jednodušší, ale ve skutečnosti je až tak jednoduchý, až je hloupý. A teď se u tohoto nového formátu s patnáctiletým zpožděním opakuje vynalézání toho, co se vynalezlo u XML. Se stejnými chybami jako u XML a navíc na horším podvozku.
Jmenné prostory, transformační a dotazovací jazyky a podobně jsou celkem zbytečné, pokud potřebuju serializovat nebo deserializovat nějakou relativně jednoduchou datovou strukturu.Jenže to je šetření na špatném místě. Třeba transformační a dotazovací jazyky mne nic nestojí, jsou vedle původního standardu a když nechci, vůbec je používat nemusím. Jenže i když chci serializovat nebo deserializovat jednoduchou datovou strukturu, jakmile opustím školní příklady, zjistím, že bych strukturu serializovanou jedním způsobem potřeboval deserializovat jinde, kde se očekává mírně odlišný formát, nebo potřebuju někde jenom ručně ověřit, kolik tam je vlastně položek atd. A najednou se mi hodí, že ty transformační a dotazovací jazyky mám po ruce a můžu je hned použít.
Jakému typu omylu zabrání to, že ty třídy nebudou na classpath? To si nějak neumím moc představit.Omylu, že tu třídu použijete.
Doposud se vezme první třída dané signatury na classpath, ikdyž tam bude ve vícero verzí jar. Tzn. to chování která třída se vezme je deterministické.No, deterministické… Pokud máte zaručené pořadí JARek na classpath, je to determenistické. Jenže pokud se classpath sestavuje dynamicky, třeba skriptem nebo hvězdičkou, je to sice deterministické, ale určit, jaké pořadí to v jakém případě bude, není úplně snadné.
Čím to dělá špatně Maven?S Mavenem to nijak nesouvisí. Bavíme se tu o Java modulech (projekt Jigsaw).
Maven přece nemůže za to, že JRE nepodporuje načtení konkrétní verze importu.Až do Javy 8 to skutečně podporované nebylo. Od Javy 9 to díky modulům podporované je.
Ano ale toto já právěže chápu, jenže to jde přece řešit podporou verzí u importů v bytecode a buiidovací nástroj jako maven by se postaral, aby tam ty správné verze do bytecode dal (aby se o to nemusel starat proramátor). Porotože Maven z pom.xml ví, že A závisí na C-1.0 a B na C-2.0, takže může na classpath vložit cosi, co podporuje JRE a podle čeho bude rozhodnuto, které C-X.0 se zrovna použije. Takže A bude při běhu volat z C-1.0 a b bude volat z C-2.0.Tento teoretický nástroj, který jste vymyslel, a který má ještě určité mouchy, někdo vzal a v podobě projektu Jigsaw ho dotáhl do použitelné podoby. Takže dnes máme k dispozici Java moduly. Nebo-li to, co popisujete jako „dalo by se řešit“ je už právě pomocí modulů vyřešené.
Je tam v Mavenu ta část, co dokáže vyřešit tranzitivní závislosti, a o to přeci jde především.Pokud jde o něco především, tak o to, aby tranzitivní závislosti nebyly zveřejněné. To, že nějaká knihovna A používá pro implementaci nějaké další knihovny B, nemá zajímat nikoho jiného než tu knihovnu A samotnou. Když knihovna A v příští verzi pro implementaci použije jinou knihovnu C, nemá to ovlivnit nikoho, kdo knihovnu A používá. A tohle řeší Maven špatně (dá vám tranzitivní závislosti na compiletime classpath), a za běhu to bez modulů ani nijak řešit nejde, protože když máte jen runtime classpath, ta knihovna B nebo C na ní musí být, a to ovlivňuje váš kód, který o B a C nemá vůbec nic vědět.
No takhle, vyvíjelo se tak posledních 20 let a ty projekty fungují. Můžete dát příklad, kdy konkrétně kvůli chybějícímu zapouzdření na úrovni modulů něco nefungovalo? Jako viděl jsem už pár velkých projektů a chybějící zapouzdřenost na úrovni modulů bylo to úplně nejposlednější, co by mi vadilo.Když to nefungovalo, tak to samozřejmě není nikde v praxi použité. Nedávalo by smysl, aby někdo před dvaceti lety napsal kód, který začne fungovat, až někdo možná za dvacet let přidá do Javy moduly. Ale ty problémy reálně existují, akorát se různými způsoby obcházejí.
To mi přijde jako dost zbytečné, protože to jde řešit pěkně návrhovým vzorem Facade. Mám nějaký balíček a chci k němu vystavit api, tak mu dám do rootu Facade třídu do které podle OOP zaobalím práci s tím modulem (nebo těch zaobalujících Facade tříd udělám víc).Jenže ty implementační třídy vám pořád budou strašit na classpath a kdokoli je může použít omylem. Moduly nemají zabránit tomu, že by někdo chtěl škodit záměrně, ale mají předcházet omylům.
Jestli se pak najde někdo, kdo to bude obcházet a vrtat se ve vnitřnostech balíčku, tak to je přece jeho problém a jeho věc.
Dále má Jigsaw rozkouskovat knihovnu v JDK. Opět nechápu smysl proč to dělají přes nějaký Jigsaw. Ať si JDK rozkouskují jak chtějí, ale dependency projektu na jednotlivé kousky se budou řešit přes Maven. Všichni Javisti používají Maven, tak proč do toho někdo cpe Jigsaw?Všichni Javisti nepoužívají Maven. Používají také Ant, Ivy, Gradle… A když už jste zmínil ten Maven, ten to zrovna dělá špatně, protože vám standardně nacpe tranzitivní závislosti na compile time classpath, takže právě můžete snadno udělat tu chybu, že začnete používat nějaké třídy, na kterých nemáte deklarovanou závislost.
Další věc kterou to má řešit je JAR Hell, že totiž nejde z classpath načíst třídu z jedné verze stejného JAR a jinou verzi stejného JAR. Opět, naco tady je Jigsaw, když to, jakou verzi která dependency potřebuje je plně obsaženo v pom.xml od Mavenu. Měli to do JDK zaintegrovat tak, aby si to mohl vyřešit buildovací nástroj.Tady jste ani nepochopil, v čem je problém. Když budu mít v projektu závislost na knihovnách A a B, a knihovna A závisí na C-1.0, zatímco B závisí na C-2.0, přičemž C-2.0 není zpětně kompatibilní s C-1.0 (ale používají stejné package a třídy), mám neřešitelný problém. Protože když dám na classpath c-1.0.jar i c-2.0.jar, použijí se třídy jen z jednoho z nich, a buď knihovna A nebo B nebude fungovat.
Obsahující redundantní informace o závislostech, které se už nacházejí a nebo se můžou nacházet v pom.xmlKdyž by se ty informace nacházely v pom.xml (jako že ve skutečnosti tam je jenom jejich část), můžete z nich přece module-info.java vygenerovat. Navíc pom.xml se používá pouze při překladu, moduly se používají i za běhu.
Definuje API, které se ale dá nadefinovat dobrým OOP návrhem, takže opět zbytečné.Není to zbytečné, naopak to umožňuje, abyste ten dobrý OOP návrh také mohl použít.
Taková drobnost .... a jaké nameservery mají prosím nativně podporované API, které umožňuje takové ACL definovat ? Bind ? Knot ? PowerDNS ?Nevím. Ale nevím, proč by to měl nativně podporovat DNS server.
Je to vidět na dříve vytvořených jazycích COBOL, SQL nebo třeba Pascal. Zejména ten první byl řádně ukecaný. Výsledek? Dnes už se v něm programuje okrajově. Když jsem se učil Pascal, tak mi vadila zejména slova begin a end. Proč? Musela se psát pořád dokola, dokonce i tam, kde to nebylo povinné. Výsledkem byla a je horší čitelnost a snižující se obliba Pascalu.Nevidím tu souvislost, proč by zrovna ukecanost měla být důvodem, proč se ty jazyky nepoužívají. Třeba Java je podle mne o něco ukecanější, než ObjectPascal/Delphi, ale okrajová není.
Minimalisté přišli s jazykem Python a formátem YAML.Idea, že když už odsazujeme kvůli čitelnosti, může se to použít i pro strukturování kódu, je hezká, ale podle mne troskotá právě na tom, že lidé chtějí odsazení jako tu balastní informaci navíc, pro lepší čtení a pro kontrolu, ale nechtějí to jako primární a jediný zdroj informací o struktuře. Určitá míra ukecanosti je prostě přínosná.
Ideál je tedy někde uprostřed.Navíc má každý ten ideál trochu někde jinde. Každopádně snažit se o co největší stručnost je špatná cesta. Ostatně to platí i u algoritmů – pokud není nutné kód nějak optimalizovat, je lepší delší ale srozumitelnější kód, než nějaký oneliner.
Zbývá jen udělat vhodný návrh, který maximalizuje čitelnost pro lidi i stroje.Vhodný návrh čeho? XML už navrženo bylo :-)
Root.cz (www.root.cz), informace nejen ze světa Linuxu. ISSN 1212-8309
Copyright © 1998 – 2023 Internet Info, s.r.o. Všechna práva vyhrazena. Powered by Linux.