Názory k článku
Douglas Crockford vyvinul nový programovací jazyk Misty

Kazda pricetne napsana aplikace provadi validaci na vstupu. Jestli to do te aplikace sypete formularem od koncoveho uzivatele, pres nejaky API endpoint a nebo skrze strukturovany format pro prenos dat je v konecnem dusledku vlastne jedno. Tu kontrolu musite udelat tak jako tak a vzdycky - a nejen validaci syntaktickou, ale take validaci semantickou. Pokud je programator liny a nedela to, pak to rozhodne neni vada formatu pro prenos dat.

Škoda, že zase netušíte, o čem píšete. Vaše představa, že si všichni budou psát vlastní parser JSONu třeba v JavaScriptu, protože JSON.parse() nefunguje podle vašich představ, neodpovídá realitě.

No to je neresitelny problem... ;-) A na vyber takovych moznosti, neni potreba vynalezat kolo. Jakze se to rika... neznalost neomlouva? ;-)

Mám pro vás jednu důležitou informaci: Nemusíte reagovat na každý komentář, i když k němu nemáte co říct. Normálně ten komentář ponechte bez odpovědi – uvidíte, že se svět nezboří. Tyhle vaše odpovědi za každou cenu, kdy odbočíte od původního tématu a napíšete něco, co sice s původním tématem velmi volně souvisí, ale ve vaší odpovědi není žádná logická souvislost s předchozím komentářem, jsou akorát velmi hloupé.

Psal jste, jaky je to udajne problem zvalidovat JSON v JavaScriptu, dodal jsem vam jedno mozne reseni popsaneho problemu.
_{Ano, svym poslednim komentarem jste promeskal svou prilezitost mlcet, kdyz teda sam netusite co sem pisete ;-)}

Nepsal.

Ukažte mi nějaký parser, který opravdu dovoluje určit typ pro čísla.

Já jsem si třeba takový napsal. Například pro přečtení fieldu "a", jehož hodnota je 32 bitový int stačí napsat v |> Json.field "a" Json.int (celý příklad).

Kazde zbozi ma sveho kupce. A to same plati i o datovych formatech. Kazdy se hodi nekam, kdyz se nekam konkretne nehodi, tak vas prece nic nenuti jej pouzivat. Nekde je vhodnejsi JSON, jinde zas XML a nekde je i ten JSON kanon na vrabce. Ale popularni je mj. pro svou jednoduchost. A ze by rigidni specifikace datoveho typu byla vzdycky vyhra take neni pravda - viz problem roku 2038, kde se zbavit toho signed integeru neni vubec snadne vzhledem k tomu, kde vsude to muze byt zasite...

To, že číselné datové typy ztrácí přesnost, je u programovacích jazyků normální. Mapují totiž své datové typy na datové typy, se kterými umí počítat procesor. Proto obvykle mají programovací jazyky i nějaký typ, který přenost zaručuje – výměnou za daleko pomalejší výpočty.

Problém JSONu je ten, že počítá s tím, že se budou používat číselné datové typy ztrácející přesnost, ale nedefinuje to a každý parser si to může dělat jinak. Kdyby ve specifikaci JSONu bylo, že číslo musí být reprezentovatelné beze změny jako 64bitové IEEE 754, jak je to v JavaScriptu, ze kterého JSON vychází, bylo by to mnohem lepší, než současný stav. Každý by věděl, že když chce přesná čísla, musí je ukládat jako text. Místo toho specifikace vzbuzuje dojem, že lze JSONem přenášet libovolně přesná čísla, ale klidně pak dovolí parserům, aby ta čísla zmršily. A není to chyba parserů, takhle fungoval už původní „parser“ JSONu, tedy volání JavaScriptového eval(). Tohle je chyba specifikace, která rozvolnila podmínky, aniž by někdo vážně počítal s tím, že se to uvolnění bude využívat.

IEEE754 ve sve revizi z roku 2008 ale specifikuje i 128, 256-bitove cislo. Zatimco vy jste usnul u historicke specifikace z roku 1985, kde byl ten vas maximalne 64bitovy datovy typ. Rigidni pozadavek na 64bitove cislo ale muze nekde ponekud nesmyslne zavrit dvere i z pohledu samotne IEEE754.

18. 12. 2023, 20:26 editováno autorem komentáře

Třeba by se ta vaše obsese odpovídat, i když nemáte nic k tématu, dala léčit.

Jiná čísla se dají v JSONu reprezentovat ve stringu, podobně jako třeba datum. V tom problém není. Špatné je to, že to od začátku bylo myšleno jako 64bitový double (bez „nečísel“), bylo by bláhové do toho něco jiného než 64bitový double zapisovat, ale stejně se nemůžete spolehnout na to, že to 64bitový double bude. Respektive nakonec se na to stejně prakticky všichni spoléhají a pokud by tam někdo nacpal něco jiného, započítá se to do povolených ztrát.

Jo, všechno se dá nasypat do vlastního stringu. Ale občas se třeba dostanete až k výslednému jsonu, nebo nemůžete jednoduše ovlivnit, jakým způsobem se ty doubly budou sypat.
Když je možné sypat doubly do nějakého vlastního stringu, tak je často možné sypat do nějakého vlastního stringu i všechno ostatní a na celý json se vykašlat. Je zajímavé, jak různorodě špatný ten json je. ;)

Ach ta posedlost 64 bitovym formatem...
^{640K Ought to be Enough for Anyone}
Uz RFC 7159 v dobe sveho psani v roce 2014 explicitne zminuje sirokou dostupnost IEEE754-2008 binary64 implementaci, ale rozhodne si explicitne nezabouchava dvere pred dalsimi formaty specifikovanymi IEEE754-2008. Oni to tam v tom roce 2008 nepridavali jen tak z pleziru. JSON RFC zadne restrikce neobsahuji treba i proto, ze (ne)dostupnost skutecnych implementaci neni duvodem se nejak nesmyslne svazovat. Zvlast kdyz se i v tom RFC odkazujete na normu, co ma limity jinde. Vysledkem podobneho omezeni by byly do budoucna akorat obdobne problemy, co se dnes resi s timestampy...

> Ach ta posedlost 64 bitovym formatem...

Ona tak nějak plyne z toho, že to tak de facto je. Když přesnost neurčila specka, tak ji doplnili implementátoři.

Není prakticky žádný rozdíl mezi současnou situací a tím, že by 128b floaty zavedl nějaký json 2.0. V obou případech by se to zadrhlo na úplně stejných hromadách kódu, co to neumí.

jen opět připomenu, že JSON ani náhodou nestaví na IEEE 754. Ano, tak nějak si všichni odvodili, že bezpečné je předpokládat, že to je double precision (protože to je průnik všech možných interpretací, co "number" znamená v JSON gramatice, ostatně i RFC to docela vágně zmiňuje), ale už jsem psal - nemá to +Inf, -Inf, NaN, které IEEE 754 vyžaduje. [uznávám, pro někoho maličkost, v mém oboru však dost zásadní věc].

Ve skutečnosti JSON na IEEE 754 staví. Protože JSON původně vznikl jako „zápis objektu v JavaScriptu, který se vyjme z kódu“. První parser JSONu fungoval tak, že se před JSON přidalo var x = a celé se to prohnalo přes JavaScriptový eval(). Že tam nejsou ty speciální hodnoty se dá pochopit – neexistují pro ně JavaScriptové literály, jsou to speciální hodnoty a nejsou zas tak často potřeba. Zúžení se dá pochopit, nějaké zúžení přípustných hodnot dělá spousta standardů. Co je nepochopitelné je to, že když to od začátku bylo myšlené jako dekadická reprezentace IEEE 754 čísel bez speciálních hodnot, nikdo to nepoužíval pro hodnoty mimo tento rozsah, a najednou si někdo vzpomene, že to do standardu úplně zbytečně rozšíří.

To je relativní. Na serializované úrovni ano. Ale na sémantické unicode úrovni ne. Pokud se ten unicode normalizuje, tak to bude jeden a ten samý klíč.

Zavádět do obecných standardů sémantickou úroveň je vždy nebezpečné. To by také bylo možné tvrdit, že klíče „1“ a „jedna“ jsou sémanticky to samé.

Vidite a ted si polozme filosofickou otazku :-) Proc nam svet elektronicke posty ovlada SMTP a ne X.400, ktere je v mnoha aspektech promyslenejsi? Proc nam v sitich vyhrava ethernet treba nad ATM ci STM? Proc nam technologie jako iSCSI valcuji FC? A tak muzeme pokracovat... Casto se v praxi bavime o tom, ze se spousta veci slozite hakuje do puvodne trivialnich technologii. XML versus JSON je na tom podobne - a realne to mate o zpravicku vedle - na papire lepsi reseni je sedmkrat drazsi... a jako bonus ta slozita specifikace sama v sobe obsahuje chyby.

No jako uznávám, že CNC soustruh je úžasná a dokonalá věc, ale na obroušení tyčky o milimetr ho málokdo bude kupovat, prostě jí vtazí do vrtačky nebo čínského minisoustruhu, a má to.

To samé s tím prokletům JSON - jistě že má spoustu problémů, ale proti mastodontům jako XML popř SOAP je velmi jednoduchý, což je samo o sobě docela dobrá use case.

Ve skutečnosti když si k JSONu doplníte schémata, dodefinujete si parser, aby bylo zaručené, jaká data se vlastně přenášejí, je to složitější, než XML.

Ano, když k tomu čínskému minisoustruhu doděláte mraky mechaniky, elektroniky, krokových motorků apod. tak z toho nakonec to CNC taky vyrobíte, a taky to hotové bude lepší.

Nicméně, to se poněkud míjíte v use case. Takže ještě jednou - tam, kde to dává smysl, tam jsou samozřejmě obludy jako SOAP vhodné. Tam kde to smysl nedává, nebo je to kanón na vrabce (management API něčeho, komunikace frontend/backend nějakého toho blogu, dotaz na čídlo), tam je ten JSON jednoznačně na prvním místě.

Tam kde to smysl nedává, nebo je to kanón na vrabce (management API něčeho, komunikace frontend/backend nějakého toho blogu, dotaz na čídlo), tam je ten JSON jednoznačně na prvním místě.
Nikoli, v těchto situacích by XML bylo úplně stejně vhodné, jako JSON. Respektive by bylo vhodnější, protože by se dalo snadno povýšit na tu složitější úroveň, kdyby se ukázalo, že je to potřeba.

Navíc polovina z výše uvedených problémů JSONu jeho použití jenom komplikuje (resp. způsobuje, že se všichni smíří s jistou chybovostí), na jednoduchost JSONu by oprava těch chyb neměla žádný vliv.

Ne, to opravdu nebylo. To je skutečně absurdní představa. Pobavil jste.

V čem přesně by to XML bylo komplikovanější? Je těžké napsat na klávesnici menšítko než složenou závorku, nebo v čem přesně je ta komplikace?

Strucne... RTFM :-) Kladete otazky, ktere maji jinde davno napsane odpovedi.

Ke každé otázce existuje stručná jednoduchá nesprávná odpověď. Řeč byla o JSONu obecně, vy odkazujete na text o JSONu ve webových prohlížečích. Navíc ten odkaz argumentuje JSON parserem vestavěným v prohlížeči, o kterém jste se ještě před chvílí tvářil, že ho nikdo soudný nepoužívá a že všichni používají jiné parsery a definují k JSONům schémata.

Omyl pane kolego. Vy jste tvrdil, ze validace mozna neni - ona mozna je, kdyz je vyzadovana. Nikde jsem nenapsal, ze parser v prohlizeci nikdo nepouziva, to je opet jen produkt vasi prebujele fantazie.

Vam pane kolego totiz chybi jedna zakladni vec - schopnost pochopit mysleni druhych. Ja rozumim tomu, proc vy preferujete XML - v systemech, ktere vy pro stat bastlite je to asi rozumna volba. Ale s tezi, ze to neni vhodna volba vsude se shoduji i vyvojari jinych systemu vyvijenych pro statni spravu - kde JSON pouzivaji. A kdyby to byla takova blbost jak tvrdite, tak vam JSON nebude standardizovan ve forme normy ISO/IEC 21778:2017. Nabizi se jedine vychodisko - sam tu placate blbosti ;-) A nebo trpite chorobnym pocitem, ze vy sam mate jako jediny patent na rozum. Akorat tu svou jedinou spravnou pravdu nedokazete prosadit - na pude IETF, na pude IEC, na pude ECMA... nikde. Jen zoufale doufate, ze to tady ukricite. Snazite se hezky, ale tahate za hodne kratky kousek provazku :-)

Vy jste tvrdil, ze validace mozna neni
Nikoli, netvrdil. Já jsem tvrdil, že to neumožňují standardní parsery, např. JSON.parse() v prohlížečích.

Nikde jsem nenapsal, ze parser v prohlizeci nikdo nepouziva, to je opet jen produkt vasi prebujele fantazie.
To plynulo z vašeho komentáře, když jsem předpokládal, že reagujete na můj komentář. Asi byla chyba předpokládat u vás, že reagujete k tématu.

Vam pane kolego totiz chybi jedna zakladni vec - schopnost pochopit mysleni druhych.
Ne, problém je, že vaše komentáře, které se dají vyložit jako komentář k tématu, vykládám jako komentář k tématu.

Ja rozumim tomu, proc vy preferujete XML - v systemech, ktere vy pro stat bastlite je to asi rozumna volba. Ale s tezi, ze to neni vhodna volba vsude se shoduji i vyvojari jinych systemu vyvijenych pro statni spravu - kde JSON pouzivaji. A kdyby to byla takova blbost jak tvrdite, tak vam JSON nebude standardizovan ve forme normy ISO/IEC 21778:2017.
Jste úplně mimo, ve všem, co jste napsal. To, že se JSON používá, je dané tím, že se s ním snadno pracuje v prohlížečích – protože jeho zpracování je zavolání jedné funkce (dříve eval, později JSON.parse). To nevypovídá nic o vhodnosti formátu, to vypovídá jenom o tom, že když máte v ruce kladivo, všechno vypadá jako hřebík. To, že je něco standardizováno nebo normováno neznamená, že je to bezchybné řešení.

Jeden z výrazných problémů JSONu je, že bylo standardizováno něco jiného, než co se reálně používá. Standard JSON byl nesmyslně rozšířen o věci, které se reálně nepoužívají, čímž se do něj ale zavedla nesmyslná složitost. Podle mne je to nepochopení smyslu standardizace. Že se to tak dostalo až do ISO normy je smutné, na druhou stranu chápu, že když už je to takhle blbě standardizované ve standardu s nižší váhou, není řešení to jen tak opravit. Musel by se nejprve vydat nový formát JSON 2 a ten pak teprve standardizovat jako ISO.

Jinak sám jste už několikrát ukazoval, v kolika dalších případech nevyhrálo nejlepší řešení. Takže to, že něco vyhrálo nebo je standardizováno, neznamená, že je to nejlepší.

Nabizi se jedine vychodisko - sam tu placate blbosti ;-)
Tak dokažte, že něco, co tvrdím, je blbost.

A nebo trpite chorobnym pocitem, ze vy sam mate jako jediny patent na rozum.
Kdybych takovým pocitem trpěl, nebudu psát do diskuse. Do diskuse píšu proto, že mne zajímá, jaké argumenty mají ostatní. Třeba mne některý z nich přesvědčí, že se mýlím. Nebo mne třeba nepřesvědčí, že bych změnil názor, ale uznám, že názor někoho jiného vychází z faktů a lišíme se jenom v hodnotách.

Zatím tu ovšem na podporu JSONu zaznělo několik ideologických výkřiků „je lepší a žádné argumenty nejsou potřeba“, a pak je tu několik názorů „je lepší, protože se používá“ (do této kategorie patří i vaše argumenty, i když to píšete mnoha slovy). Za mne to, že se to používá, nesvědčí o tom, že je to lepší formát. Já jsem nikdy nezpochybňoval, že se JSON používá a že v prohlížeči je extrémně snadné JSON použít (a zároveň se v prohlížečích v drtivé většině případů používá něco trochu jiného, než je standardizováno). Sám JSON často používám, nejen v prohlížeči, ale i ke komunikaci backendových systémů. Akorát si myslím, že když člověk něco používá, má si být vědom nedostatků té technologie a zvažovat, kdy je může zanedbat a kdy je musí řešit.
On už také současný JSON není tak omezený, jako byl na začátku. Už se k němu přidalo dost věcí, které mělo to ošklivé XML a JSON to nikdy nebude potřebovat. I když se to bohužel přidávalo způsobem, jak funguje celý JSON – tedy vzala se inspirace z něčeho, co docela dobře funguje, trochu se to pokazilo a z toho vznikl standard pro JSON. Takže už máme JSONSchema, pro ukazování do JSONu máme dokonce dva standardy JSONPath a JSON Pointer. Pro transformace máme JavaScript, to je jediné zlepšení proti XML (resp. XSLT) – sice to vzniklo nechtěně, ale na to se historie neptá.

Takze strucne shrnuto - kdyz vam neco vyplyne z meho prispevku, tak je to v naprostem poradku a muzete tim argumentovat, ale beda jak se stejneho konani dopusti protistrana, tak se zacnete kroutit, ze to jste prece vy nenapsal :-)

A uz jsem to psal vyse, kdyz jste tak skalopevne presvedcen o chybach, muzete je napravit. Tady mlatite prazdnou slamu. Tim, ze budete psat slohovky plne nesmyslu nezmenite ani ten standard a ani neodradite lidi od toho, aby JSON pouzivali. Vase vykriky jsou podobne ideologicke, protoze vy jste prozmenu posedly XMLkem. Ja narozdil od vas respekuju svobody volby a nikomu nevnucuju, ze jen XML je spravne, zatimco JSON je blbost.

Já se příspěvky (nejen vaše) snažím interpretovat tím nejlepším možným způsobem, ve prospěch autora. Vy příspěvky překrucujete. U toho vašeho příspěvku už jsme si to vysvětlili – váš příspěvek byl tradičně mimo téma diskuse, takže jeho obsahem není potřeba se dále zabývat.

Já jsem v této diskusi nenapsal jedinou věc, kterou by někdo vyvrátil jako nesmysl. Což se o vašich komentářích říct nedá. Já nikomu nevnucuju, že jen XML je správně a JSON je blbost. Já jsem jen poukázal na vážné nedostatky JSONu. To se snad ještě smí.

A ted jeste tu O Cervene Karkulce :-) Kdyz jsou ty vanoce, cas pohadek...

Nic na tomhle svete neni dokonale. Poukazovat na nedostatky JSONu muzete, ale mrhate casem a diskovym prostorem tohoto serveru. Lidi to kvuli vasim slohovkam (kdy se cupovanim prispevku na vety vytrzene z kontextu snazite dokazat svou pravdu) pouzivat neprestanou, rekl bych ze vesmes jsou si i vedomi tech podle vas vaznych nedostatku - ba co hure pro vas, oni to ani jako nedostatek nevidi. Je to vas subjektivni nazor, nikoliv objektivne prokazana pravda.

Mimochodem uz jste poslal svuj prispevek na IETF s cilem ty vazne nedostatky odstranit? A nebo tu fakt jen mlatite prazdnou slamu? ;-)

Vypadalo to, že někteří lidé v této diskusi si některých nedostatků vědomi nebyli. Takže těm třeba můj komentář rozšířil obzory. Otázka je, k čemu jsou dobré vaše komentáře, z nichž většina ani nebyla k tématu.

ba co hure pro vas, oni to ani jako nedostatek nevidi
To není hůř pro mne. Pokud někdo nevidí jako nedostatek něco, co objektivně je nedostatek, je to hůře pro něj.

Pro většinu use-case je to pohodlné i bezpečné naprosto dostatečně. Váš poněkud teoreticky nesmyslný pohled je dán nepochopením, že obecně v životě nevítězí dokonalá řešení, ale naopak dostatečně jednoduchá řešení, která prostě jsou v potřebný okamžik k dispozici. Všechna ostatní "kdyby" jsou jen teoretická historie.

Je to stejné, jako když si koupím třicet let starou ojetou felicii abych mohl denně jezdit do vedlejší vesnice do práce. Je to dokonalé? Je to bezpečné? Těžko, ale trade-off mezi cenou a mnou požadovaným výkonem je víc než výhodný protože prostě víc nepotřebuju a jakékoliv jiné řešení by bylo podstatně dražší. A felicii soused zrovna prodával.

19. 12. 2023, 10:16 editováno autorem komentáře

že obecně v životě nevítězí dokonalá řešení, ale naopak dostatečně jednoduchá řešení, která prostě jsou v potřebný okamžik k dispozici

Ano, proto to v Česku vypadá, tak jak to vypadá...

V IT máme možnost to dělat "dokonale" a mělo by se to tak dělat. Proč? Protože to eliminuje hromadu problémů v budoucnosti. Stavět z malých a dokonalých kostiček znamená, že v budoucnu s tím bude méně problémů. A používat systém, o kterém už v době použití je známo, že má a jaké má problémy, je zadělávání na problém v budoucnu.

A obecně mě děsí, jak se opakovaně v diskusích probírá, že nějaká malá ztráta dat vlastně nevadí a nemusí se to řešit. Tohle upřímně nechápu. Já dělám v IT právě proto, že máme možnost od počátku až do konce zabezpečit data. A nikdy si dobrovolně nevyberu cestu, že se možná něco ztratí (a já o tom vlastně ani nebudu vědět). Je spousta míst, kde je použití Float vyloženě špatně, protože float neumí uchovat některá čísla přesně. Proto se třeba ve finančním sektoru používají integer datové typy apod.

Vy snad mate pocit, ze ta zahranicni reseni jsou dokonala? Ja jen ze pod temi RFC k JSONu je historicky podepsany treba i Google. A ten standard ma i podobu ISO/IEC ci ECMA normy a za otce je povazovan Douglas Crockford z univerzity v San Franciscu...

To platí všude na světě, příteli. Dokonce bych řekl, že třeba (a nejen) v USA co se IT týká ještě podstatně více, než tady.

Nemluvě o tom, že zrovna ČR je země průměrných řešení, kde sice nic nefunguje dokonale ale skoro všechno funguje víceméně průměrně čímž se tu ve výsledku máme jako prasata v žitě. On kdejaký Franta vypráví o zahraničí a píše "že ale v Česku", jenomže co všechno tam naopak nefunguje už raději nezmíni. To už by se totiž nehodilo. Nepište nesmysly.

Já jenom chci, aby se i další čtenáři zamysleli nad výběrem různých technologií. Udělat si vlastní nároky a vlastní portfolio není tak těžké. Mě prostě vadí ten přístup "nějaká data možná zmizí, ale to vlastně nevadí". A vadí mi to za situace, kdy je volně dostupné lepší řešení.

"V IT máme možnost to dělat "dokonale" a mělo by se to tak dělat"

...
Priklad ... chmm ... tohle vsichni znaj, to nemohlo minout nikoho ...

Cyberpunk 2077
...

Vis, ono je to vzdy a pouze a jen o penezich. Takze najmes patlala a ten neco splaca. Usetris na cloveku, ktery by to chtel napsat aspon solidne, a tudiz by mu to trvalo 10x dyl. Placal postahuje nekde nejaky knihovny a nejak je slepi.

Ono to na nejakym demu nejak funguje. 10 demo zaznamu to prezije, a preda se to zakaznikovi. Ten to pak spusti na 10M zazanamu, a cely se to slozi. Reknes at si koupi vykonejsi HW, vic ram, rychlejsi disky ... a v naprosto nejhorsim pripade najmes jinyho patlala, at to nejak premasti. On to zplaca tak, ze to tech 10M zaznamu na tom 100x drazsim HW ustoji.

Podotykam, ze treba takovy oracle se presne timhle pristupem zcela nepokryte chlubi. Primo od jejich zamestnancu vim, ze cokoli kdokoli chce, preda se indum, a ti to na 25. pokus dostanou do toho stavu "nejak to funguje". A i tak je to levnejsi nez to udelat rovnou a poradne. Vcetne hladiny nasralinu u zakazniku. Ti totiz typicky stejne nemaji na vyber.

Ano, muzes rict, ze spousta veci bude trvat presne stejne dlouho napsat dobre jako spatne, jenze na to napsat dobre potrebujes cloveka, ktery to dobre umi. Ty takovy lidi nekde kolem vidis? Podle toho co chodi na pohovory konstatuju, ze i senkrubniho potapece sehnat je problem.

Pro většinu use-case je to pohodlné i bezpečné naprosto dostatečně. Váš poněkud teoreticky nesmyslný pohled je dán nepochopením, že obecně v životě nevítězí dokonalá řešení, ale naopak dostatečně jednoduchá řešení, která prostě jsou v potřebný okamžik k dispozici. Všechna ostatní "kdyby" jsou jen teoretická historie.
Přehlédl jste jednu velmi podstatnou věc – to, že by ve specifikaci JSONu bylo uvedeno, že jsou to IEEE 754 double čísla a že se klíče v objektu nemohou opakovat, by ten formát nijak nezesložitilo. Spíš naopak. Komentáře by ho malinko zasložitily, ale pro snadnost použití by to bylo plus.

Vsak to muzete napravit.

Přesně tak. Stejně, jako je realita že to většina lidí neřeší a řešit ani nepotřebuje. A ano, někteří ano, ale to je prostě rys toho formátu, který nikdo nikoho nenutí používat.

Jenže ve skutečnosti se JSON stal univerzálním formátem pro výměnu dat na webu. A dnes se přes web řeší skoro vše.

Dneska je taky ethernet univerzalnim mediem pro vymenu paketu. Jisteze, byly tu i jine (a lepsi) technologie, co se pro tento ucel daly pouzit - ale byly slozitejsi, nakladnejsi... no vysledkem je, ze ethernet vladne vsemu (dokonce mame jeho synchronni variantu, abysme se priblizili tomu, co slo v SONET/SDH sitich).

"i jine (a lepsi) "

To bych zas tak moc netvrdil. Ty jine technologie byly mozna lepsi v nejakem konkretnim ohledu, ale v jinem prozmenu zase o dost horsi.

Napriklad to, ze ethernet funguje na principu urvi co muzes, je sice jeho nectnost, ale zaroven i cnost, protoze cokoli jinyho == je treba tu komunikaci nejdriv nejak dojednat, a to je latence a zatizeni nejakeho procesoru.

Ethernet je totiz typicka ukazka efektivity pristupu na tema kdyz je to kladivo male, pouzij vetsi. A dokud se da poridit vetsi kladivo neni treba vymyslet nic slozitejsiho.

A uvedom si, ze prakticky vsechny alternativy vychcipaly v dobach jednotek, maximalne desitek Mbit, takze pri soucasnych rekneme stovkach Gbit by ten overhead byl jeste radove jinde.

Ale ono se to pouziva obcas interne i dnes. Cell ma tady 64B. Podobnost s ATM ciste nahodna (ano, ta bunka je o par bajtu vetsi) ;-) A toto konkretne je platforma s az 96Tbps, zadny parmegabitovy orezavatko...

Ale stale su formaty, ktore su na tom vyrazne lepsie ako JSON ako protobuf, messagepack (zvlada normalne cisla aj datumy, cas, ...), aj to XML. Zial YAML je spetne kompatibilny s JSON-om.

X400 je take vyrazne lepsi nez SMTP... :-) A dokonce i microsofti exchange to interne jeden cas i pouzival, nez to vzdali... a misto toho mame SMTP s ruznymi ohejbaky okolo (SPF, DKIM, DMARC, DANE, MTA-STS...).

Ono riesnie nie je napisat si vlastny parser, ale bolo by super nenchat aby sa standard, ktory nezvlada ani zakladne veci nevypustil do sveta. Potom je uz skoda plakat nad rozliatym mliekom a je lepsie to cele zahodit a pouzit nieco ine.

To ale musite rict na IETF. Standardy se tvori tam a samozrejme se tam stretavaji ruzne pohledy na vec a neni to o tom, ze by existovala prave jen jedna pravda. V obecne rovine navic plati, ze standard za zpackane implementace rozhodne nemuze. A vyvojari holt obcas tihnou k tomu, ze maji potrebu si veci psat sami na kolene s obdobnymi argumenty - vymluvi se, ze dostupne existujici implementace jsou na nic a bylo by lepsi je zahodit...

Víte, problém je jaksi v tom, že to většina lidí fakt neřeší a je jí to srdečně jedno. Takže ta potřeba to zahazovat je jaksi dost minoritní. Ostatně používat nějaký sice dokonalý, ale obskurní proprietární formát vám nebrání naprosto nikdo.

Srovnávat protobuf s JSONem je naprostý nesmysl. MessagePack srovnávat víceméně můžete, ale zrovna i to je v tomhle případě nesmysl protože jedno je binární formát se všemi výhodami a nevýhodami, co z toho vyplývají a to druhé je v podstatě obecně popsaný textový formát. Opět věc určená pro jiné případy užití.

Ach jo.