uSX 1.0 - nový formát pro textové a binární reprezentace dat

5.2.2017 21:41 | Přečteno: 2252× | d

Před několika dny jsem narazil na potřebu ukládat konfigurační volby v plně multiplatformním formátu, který by pro zpracování nevyžadoval žádné speciální knihovny (tzn. parser se dá napsat ručně či pomocí bison/yacc/... řádově v minutách) a přitom byl uživatelsky stále docela dobře čitelný.

Jinými slovy jsem hledal formát, který umožňuje vhodně kombinovat binární zápisy datových struktur (binární v tomto kontextu znamená především "lidsky složitě pochopitelný či nepochopitelný a nečitelný") a "znakové" zápisy datových struktur (tzn. především lidsky čitelné a pochopitelné znaky). A to při zachování pěkných vlastností (KISS, rychlost zpracování/tvoření, použitelnost pro nekonečné proudové zpracování, spolupráce s ostatními formáty, rozšiřitelnost, kompatibilita mezi textovými editory a programovacími jazyky, atd.).

Po hodině googlení jsem si s hrůzou přiznal, že žádný takový formát neexistuje a pokud ano, tak je buď proprietární (pro mé účely tedy zcela nepoužitelný) a nebo příliš komplexní (např. XML je nejblíže, ale implementace dle standardu je na vytrhání vlasů a stovky hodin práce a lidská čitelnost taktéž není úplně to pravé ořechové).

Rozhodl jsem se, že si sepíšu co by takový formát měl umět. Nu a od sepisování už to byl jen krůček ke specifikaci takového formátu. Vznikl tak draft

uSX 1.0 (Micro Structure eXtensible)

Rád bych zdejší čtenáře požádal o komentář k tomuto počinu (můžete psát rovnou i do GitHub Issues).

P.S. Těch několik hodin co jsem lepil specifikaci uSX 1.0 mě polévalo horko z XKCD 927 (Standards), protože se mi stále nechce věřit, že něco tak "základního" ještě neexistuje.        

Komentáře

[radix]

Neni mi uplne jasne, jak je to s ukoncovanim multiline bloku. Jak bych treba zapsal hodnotu obsahujici (prave jen) 3 LF?

[dumblob]

Takto:

.some.id^LF

LF

Specifikace říká:

For a one-line record, ' follows, for a multiline record, ^ followed by a string of maximum of 64 octets and LF follows. For a one-line record any data follow until the first occurence of LF. For a multiline record any data follow until the first occurence of LF immediately followed by the string of maximum of 64 octets.

Přemýšlím jak to formulovat ve specifikaci lépe. Možná bych měl oddělit specifikaci pro singleline a multiline. Nebo raději ne? Nějaké nápady jak to upřesnit? Díky.

[dumblob]

Koukám, že je chybně ta ukázka (použil jsem <code> namísto <pre>). Správně má být:

.some.id^LF



LF

[Josef Kufner]

V čem to je lepší než JSON?

[xkucf03]

JSON je smradlavý bastl, který neumí ani komentáře → na konfiguráky absolutně nevhodný a na jakékoli lidsky psané datové struktury vlastně taky (často potřebuješ data ladit a různě si s tím hrát a tam se fakt hodí mít možnost kus zakomentovat – všude jinde ta možnost je – např. XML, INI, SQL, YAML atd.).

[Bedňa]

Tak schválne z praxe, ešte som nevidel XML s komentármi, ak taký príklad máš, to bude nejaký zázrak :)

XML má jasne danú štruktúru, všetko ostané je mínus.

Osobne mám rad texťaky s popisom a nemusia mať ani štruktúru, hoci keby tam nejaká bodková, alebo objektová ale C++ bola, bolo by to prehlednejšie.

Keď to zoberiem, existuje veľké množstvo vynikajúcich WM a ja som si vybral IceWM, pretože má všetko v plaintexte a keď niečo hľadám je to: cat .icewm/preferences | grep -i hladany_retazec no a vždy nájdem čo potrebujem. Spravidla to vypľuje komentár aj s hodnotu.

Ale neviem či nenosím drevo do lesa, keď viem že miluješ XML

[Sten]

Konfigurace D-Busu a Tomcatu jsou detailně okomentovaná XML

[Bedňa]

Netvrdím, že také niesu a je fajn, že niekto dokumentuje svoju prácu, na čom zarvala veľká časť vynikajúcich projektov do ktorých sa už nikto nepipojil.

Plaintext samozrejme núti autora nastavenia zdokumentovať, pretože štruktúru väčšinou nemajú.

[Integral]

> Tak schválne z praxe, ešte som nevidel XML s komentármi

> Netvrdím, že také niesu

LOL!

[kralyk z abclinuxu]

Co ti na tom nesedí? Tebe jsem taky ještě neviděl, ale přesto věřim, že někde existuješ

[xkucf03]

Já zase neviděl JSON s komentáři a vzhledem k tomu, že jsem četl specifikaci, tak ani nevěřím, že nějaký existuje.

Oproti tomu komentovaných XML jsem viděl spoustu a taky jsem viděl spoustu XML s XSD nebo jiným schématem, u kterých mi editor během psaní validoval dokument a napovídal elementy a zobrazoval dokumentaci. Práce pak jde výrazně rychleji od ruky a člověk má větší jistotu, že to bude fungovat, než když píše naslepo nebo podle externí dokumentace.

[kralyk z abclinuxu]

Já zase neviděl JSON s komentáři a vzhledem k tomu, že jsem četl specifikaci, tak ani nevěřím, že nějaký existuje.

No proto bych třeba na konfiguraci doporučil spíš TOML. Beztak je (ještě o něco) jednoušší editovat konfigurák v TOMLu než v JSONU.

Oproti tomu komentovaných XML jsem viděl spoustu a taky jsem viděl spoustu XML s XSD nebo jiným schématem, u kterých mi editor během psaní validoval dokument a napovídal elementy a zobrazoval dokumentaci. Práce pak jde výrazně rychleji od ruky a člověk má větší jistotu, že to bude fungovat, než když píše naslepo nebo podle externí dokumentace.

To, že je potřeba celkem rozsáhlý tooling a od někoho vypracovaná schémata, aby editace XML nezpůsobovala vývojářům PTSD, 1) mě nepřekvapuje a 2) nepovažuju za plus.

[xkucf03]

od někoho vypracovaná schémata

A co jiného navrhuješ? To mám si mám pořídit věšteckou kouli a psát podle ní? Tak jako tak je potřeba napsat specifikaci a strojově čitelná je ta nejlepší, jaká může být (vysvětlující texty do ní lze vždy doplnit, ale obráceně to nefunguje – specifikaci v přirozeném jazyce těžko použije nějaký nástroj a těžko ti usnadní práci – musíš všechno přečíst sám a dělat ručně).

[kralyk z abclinuxu]

Mně ta strojově zpracovatelná dokumentace až tak boží nepřijde zejména z toho důvodu, že nejsem stroj.

Při práci s takovým XML (občas to bohužel taky musim dělat) si stejně zobrazim tu humpoláckou dokumentaci v prohlížeči a "všechno dělám ručně", protože v prohlížeči stejně už mám dokumentaci k X dalším částem software, knihovnám atd. atd., navíc prohlížeč mnohem lépe zobrazí výřečnější typ dokumentace jako různé tutoriály s úryvky kódu apod. Další věc je, že nezávisí na stavu, typu a umístění editoru (ssh foobar vim ~/some/file).

XML by bylo fajn, kdyby

1. ho lidi používali na to, na co je určené, tj. markup pro strukturované dokumenty a ne na konfigurace nebo nedej bože serializaci / marshalling
2. bylo jednodušší a méně ukecané, tj. vykopat pokud možno co nejvíce entit a místo toho používalo vždy unicode, oddělat blbosti jako cdata, umožnit rozumně ukončovat tagy, atd., protože tak jak XML je, je v podstatě na čtení a editaci nešikovné pro lidi i pro stroje.

[Bystroushaak]

A co jiného navrhuješ? To mám si mám pořídit věšteckou kouli a psát podle ní? Tak jako tak je potřeba napsat specifikaci a strojově čitelná je ta nejlepší, jaká může být (vysvětlující texty do ní lze vždy doplnit, ale obráceně to nefunguje – specifikaci v přirozeném jazyce těžko použije nějaký nástroj a těžko ti usnadní práci – musíš všechno přečíst sám a dělat ručně).

A co jsi to používal / používáš za editor? Já jsem na XML zatím nic použitelného neviděl a něco takového by se hodilo.

[xkucf03]

Netbeans a jEdit, občas ještě Eclipse. Nicméně dokonalé to není a ten potenciál, co by z toho fotmátu šel vytěžit, je ještě mnohem větší – ale i tak to dalece přesahuje jiné formány, kde je podpora v podstatě nulová (v lepším případ zvýrazňování syntaxe).

[smazáno]

no offense, ale tomuhle se rika "otrok sveho IDE"

[Kate]

Nebo také „využívat pracovní nástroj“. Nepochybuji že to XML dovede napsat i bez toho, ale proč nepoužít něco co mu usnadní práci.

Osobně preferuji pro své účely JSON a YAML, ale tyhle vlastnosti by se opravdu hodily.

[smazáno]

... tak vis jak to pak vypada v realu - ty XML konfiguraky (prave, kvuli tomu aby se daly zpracovavat pomoci ruznych nastroju) jsou tak slozity, ze dokonce ani s tema udelatkama se v tom nikdo nevyzna

[pavlix]

Já zase neviděl JSON s komentáři a vzhledem k tomu, že jsem četl specifikaci, tak ani nevěřím, že nějaký existuje.

Já ano. A není to rozšíření specifikace o komentáře zase tak složité.

[integral]

Jo, mas recht :) Jsem mimo

[xkucf03]

XML do toho netahej, o to tu nejde – můj komentář byl o JSONu a o jeho zásadní vadě – absenci komentářů – která tento formát činí nevhodným pro většinu použití. I ten tvůj oblíbený „plaintext“¹ ty komentáře podporuje.

_{[1] ve skutečnosti to žádný „plaintext“ není a je to nějak specifikovaný značkovací jazyk, asi něco na způsob INI nebo .properties souborů}

[kralyk z abclinuxu]

můj komentář byl o JSONu a o jeho zásadní vadě – absenci komentářů – která tento formát činí nevhodným pro většinu použití

To bych neřekl, pro svoje většinové použití, tj. data interchange (zejména na webu apod.) a serializaci, vyhovuje v zásadě velmi dobře. (A o lepší alternativě nevím.)

Na konfiguraci JSON jako takový moc není, pokud ta konfigurace je větší než minimální. Editory jako Sublime nebo VS Code si za tímhle účelem do JSONu komentáře přidaly, což není čisté řešení, nicméně v praxi s tím na 99% problém nebude.

[xkucf03]

Pro serializaci a strojové rozhraní se klidně může použít binární formát. Co se týče lidské čitelnosti – většina JSONu, který potkávám, je humus na jednom řádku, takže člověk stejně potřebuje speciální nástroj, který to rozparsuje a zobrazí v lidsky čitelné podobě – a to můžu dělat i s binárním formátem (třeba si ho otevřít ve Wiresharku nebo vypsat jedním příkazem v konsoli).

Editory jako Sublime nebo VS Code si za tímhle účelem do JSONu komentáře přidaly

Takže už to není JSON a nemá cenu se o tom v souvislosti s JSONem bavit, mj. proto, že parser JSONu si na tom vyláme zuby.

[kralyk z abclinuxu]

Pro serializaci a strojové rozhraní se klidně může použít binární formát.

Je otázka, jestli by to přineslo výhody, např. v tom prostředí webu. Přenos se stejně typicky komprimuje a pro dekódování, zejména v JS, je JSON nejspíše stejně snazší.

Takže už to není JSON a nemá cenu se o tom v souvislosti s JSONem bavit, mj. proto, že parser JSONu si na tom vyláme zuby.

Výhoda je v tom, že pro uživatele to stále je JSON, je zvyklý s tím pracovat. Že to nejde parsovat obecným JSON parserem jaksi ničemu nevadí.

[Spitzbube]

Např. zdroják mojí dizertace

[Josef Kufner]

JSON má komentáře na stejné úrovni jako uSX popsaný v blogu. Tedy ani jeden je nemá a emuluje se pomocí vyhrazené property.

Komentáře chybí jen při ručním psaní konfiguráků. Pro všechna ostatní použití to nijak nevadí (ukládání a předávání dat, API, konfigurace upravovaná z GUI, …). V takových případech to je dokonce výhoda, neboť zakódování a dekódování jsou pak zcela symetrické operace a žádná data se při strojovém zpracování neztrácí, což se nedá říct o XML, INI, YAML a dalších.

[dumblob]

JSON má komentáře na stejné úrovni jako uSX popsaný v blogu. Tedy ani jeden je nemá a emuluje se pomocí vyhrazené property.

Ne tak docela. V JSON se musí vyhradit nějaká hodnota vedle ostatních a tudíž každá implementace musí nějak sémanticky rozlišit, zdali to je komentář či hodnota, protože JSON specifikace pro rozlišení neposkytuje žádný nástroj.

uSX však tento problém nemá, protože komentáře nelze adresovat žádným ID (ačkoliv v AST někde samozřejmě zůstanou, ale není důležité kde a implementace by na ně měla zcela kašlat s výjimkou prvních několika bajtů streamu, které určují požadovanou verzi specifikace pro úspěšné zpracování následujícího streamu).

[Josef Kufner]

Pokud není důležité „kde“, tak parsováním a opětovnou serializací komentáře buď ztratíš, nebo zdrhnou někam kdo ví kam. V JSON sice můžou putovat v rámci jednoho objektu taky, ale aspoň se neztratí.

Hlavní výhoda JSONu je v tom, že ve většině dynamických jazyků se mapuje 1:1 na běžné datové struktury (JSON je poskládaný jen z uzlů typu seznam, objekt, null, bool, string, číslo). Takže AST obvykle vůbec není potřeba řešit a typicky se vůbec nepoužívá – parsuje se přímo do nativních datových struktur (pokud to cílový jazyk zvládá). Oproti tomu je například v XML je 18 typů uzlů, parser je složitý až hrůza a neumí to rozlišit null od false.

Další hezká věc na JSON je JSON Schema (inspirované podle XML Schema). Vcelku srozumitelná forma strojově čitelného popisu struktury JSON dokumentu. Mám tu z toho generovaný kus dokumentace a současně si mohlu i automaticky kontrolovat, že ta konfigurace odpovídá specifikaci (automatické testy). Také existují editory, které podle toho sestaví GUI.

[kralyk z abclinuxu]

Hlavní výhoda JSONu je v tom, že ve většině dynamických jazyků se mapuje 1:1 na běžné datové struktury (JSON je poskládaný jen z uzlů typu seznam, objekt, null, bool, string, číslo).

V zásadě ano to tak je, občas bývají problémy s datovými typy - např. kvůli tomu, že JSON nerozlišuje float a integer (natožpak různé velikosti integeru nebo znaménkovitost).

Nicméně souhlasim, že se JSON typicky snadno reprezentuje v různých jayzcích.

Co mně osobně na JSONu vadí (mnohem víc než absence komentářů) je, že netoleruje čárky na konci věcí (trailing comma), tj. např. [ 1, 2, 3, ] není validní.

Oproti tomu je například v XML je 18 typů uzlů, parser je složitý až hrůza a neumí to rozlišit null od false.

XML je markup (navíc zatížený historií - HTML, SGML), na něco jinýho než strukturování dokumentů ho IMHO nejde moc brát vážně...

[dumblob]

Pokud není důležité „kde“, tak parsováním a opětovnou serializací komentáře buď ztratíš, nebo zdrhnou někam kdo ví kam.

Pardon, vyjádřil jsem se dvojsmyslem. Komentáře samozřejmě zůstanou v AST (kterým je holý seznam dvojic, takže mapování na běžné struktury je samozřejmost), a to přesně na stejném místě kde byly na vstupu.

Ohledně schématu, tak uSX samozřejmě podporu schémat má - a to ve formě volitelné standardní knihovny schémat (ta může být však jednoduše nahrazena jinou, vlastní knihovnou schémat v případě potřeby).

[fi]

Vzhledem k tomu, ze YAML je superset JSONu, tak nevidim duvod, proc by neco, co jde pouzit v JSONu, nemelo stejne fungovat i v YAMLu.

[podlesh]

Technická: o XML se to rozhodně říct dá, kódování a dekódování jsou symetrické operace a komentáře se nikde neztrácí.

Disclaimer: to nic nevypovídá o praktičnosti použití na konfigurační soubory. Osobně poslední dobou používám intenzivně YAML a nemůžu si stěžovat.

[kralyk z abclinuxu]

Technická: o XML se to rozhodně říct dá, kódování a dekódování jsou symetrické operace

"Rozhodně" se to tedy IMHO říct nedá. Například následující dva XML snippety mají jiný AST:

<person><firstname>Pepa</firstname><lastname>Vomáčka</lastname></person>

<person>
	<firstname>Pepa</firstname>
	<lastname>Vomáčka</lastname>
</person>

Jestli budou nebo nebudou interpretovány stejně je v zásadě záležitost aplikace, příp. je potřeba to ošetřit schématem.

Další věc je, že enkódery mohou/nemusí různě kódovat znaky do entit (ie. třeba " místo " apod.) nebo používat CDATA.

[podlesh]

?? Ano, jedná se o dva různé dokumenty, tedy různé AST. Aplikace se může rozhodnout jejich rozdíly ignorovat, případně nějaké ty mezery doplnit, ale samo od sebe to není. Koneckonců, pro primární účel (markup) se to jako stejné dokumenty interpretovat ani nesmí.

S těma entitama je to pravda. Také apostrofy a uvozovky, a pořadí atributů nebývá zachováno. Tohle všechno je důvod, proč se musel vytvořil standard pro kanonické XML (pro podepisování/otisky).

Každopádně, reagoval jsem na výrok tvrdící (nebo alespoň implikující) že se ztrácejí komentáře - což není pravda.

[xkucf03]

Komentáře chybí jen při ručním psaní konfiguráků.

Což je dost podstatná vada. Přidání komentářů nezvyšuje výrazně složitost formátu, takže tohle pokládám jednoznačně za špatný návrh a šetření na nesprávném místě.

ukládání a předávání dat, API, konfigurace upravovaná z GUI

I tam se komentáře hodí a není důvod, proč by tam neměly být. Při vývoji těchto věcí je potřeba ladit data, testovat, API si často budeš nejdřív provolávat ručně přes curl, JMeter, SoapUI atd. a tam se hodí mít možnost zakomentovávat různé části, zkoušet posílat různé požadavky nebo si do toho psát poznámky.

V takových případech to je dokonce výhoda, neboť zakódování a dekódování jsou pak zcela symetrické operace a žádná data se při strojovém zpracování neztrácí

Jednak se ztrácí pořadí¹ a jednak třeba u toho XML jsou komentáře normální uzly a jsou součástí modelu (můžeš je načíst a pak zase uložit).

_{[1] což někdy hraje roli resp. omezuje to způsoby využití takového formátu – např. když na hodnotě jednoho atributu závisí způsob parsování dalších atributů – atributy se ti při výstupu zpřehází a pak to nejde přečíst na jeden průchod}

[xkucf03]

Tedy ani jeden je nemá a emuluje se pomocí vyhrazené property.

Ne, to opravdu za komentáře považovat nelze. Zasírá to datový model a v souvislosti s tím, že JSON neumí jmenné prostory, není ani možnost jak to logicky separovat od skutečných dat.

Software na druhé straně by s tím musel počítat, což jsem ještě neviděl. Takové „komentáře“ pak nefungují buď vůbec (druhá strana ti vrátí chybu, protože narazila na atribut, kterému nerozumí) nebo to v horším případě projde a může se to chovat divně (druhá strana si ten komentář vyloží jako něco jiného).

[Kate]

Zrovna tohle mi vůbec nevadí :) Co mě žere mnohem víc je, že nepovoluje trailing comma. Pořád na to při ruční editaci myslet je meh.

[xkucf03]

Zrovna jsem s tím dneska taky bojoval :-) Sice vím, co od toho čekat, takže už na to moc nezapomínám, ale odmazávat ty čárky je otrava. (generoval jsem si nějaké seznamy prvků a kopíroval je do JMeteru s požadavkem v JSONu).

[Kate]

Odmazávat i přidávat. Hodnoty často přidávám tak, že udělám duplikát té předchozí a přepíšu hodnoty. Když to udělám u té poslední... Naštěstí mě alespoň seřve linter :)

[Vykook]

Zcela subjektivně mi to přijde jako neskutečnej chaos a tečkové peklo.

[skunkOS]

1+

[:::]

++1

[Václav Havel]

Ačkoli ve vlastním usx formátu je vidět absolutní nezkušenost autora. Dělá ale stejnou chybu, jako jeden zkušený machr, a ta zkušenost prověřená historií:

Niklaus Wirth stvořil Pascal a řadu dalších jazyků (Module, Oberon, ...) na pascalovské syntaxi. Dal přednost čisté a jednoduše parsovatelné gramatice před praktickou použitelností - tedy udělal stejnou chybu jako autor usx.

Takže uživatelé Pascalu řešili kraviny typu kde končí příkaz a kde výraz - a věci jako, zda před else napsat středník, nebo jak předčasně vystoupit z cyklu, a tisíce dalších kravin. Protože jednoduše parsovatelná gramatika měla přednost před praktičností jazyka. To je také důvod, proč Pascal šel historicky do háje.

Jednoduchost parsování gramatik jeho jazyků umožnila sice Nilausovi Wirthovi chrlit jazyky a kompilátory jako na běžícím páse - ale žádný z nich nežije.

Nebýt Borlandu, který se pokusil polomrtvý Pascal ještě dlouho udržovat na kapačkách, tak nežil ani ten. Nicméně Borland zprznil extenzi Pascalu natolik, že smrt Pascalu byla jen otázkou času přes spousty peněz a nadějí Borlandu.

****

Snahy udělat něco jednoduše parsovatelné a programovatelné - vedly vždy do pekla. Udělat to dobře umí jen zkušený programátor, který udělal už všechny chyby, co se dají udělat a natloukl si nos na všech případech, kde si lze natlouct nos. Vy se evidentně snažíte si natlouct nos s usx formátem.

Něco tak špatně vymyšleného jako usx jsem za svůj život ještě neviděl. A to jsem viděl hodně pokusů začátečníků - ale toto je vysloveně číslo jedna od konce. Smažte to a začněte jinak, to je nejlepší rada. Usx je tak špatný pokus, že jakákoli další práce je jen ztrátou času pro druhé - ale na druhé straně pro vás přesně tím kopancem, kterým se naučíte, že tudy ne.

[Radovan]

On ten Pascal pro praktické použití ani nebyl určený, spíš měl začátečníky nutit přemýšlet o tom kde končí příkaz a kde výraz, a jestli před else napsat středník... A vystoupit z cyklu se tam dá úplně jednoduše, goto umí

Nějaké klady asi měl, když dnes jeho odnož s názvem SCL řídí fabriky a jaderné elektrárny (ty modernější, které nejedou na PDP-11), a stále čiperná Ada z Pascalu také vychází. I když mám takový blbý pocit že software pro F-35 byl napsaný "moderně" v Javě, podle toho jak zabugovaný krám to je!

[Bystroushaak]

I když mám takový blbý pocit že software pro F-35 byl napsaný "moderně" v Javě, podle toho jak zabugovaný krám to je!

Afaik je psaný z většiny v C/C++.

[Radovan]

Tak potom by mě teda fakt zajímalo kde udělali soudruzi z USA chybu :-/

[Rob]

no - víš co - kdyby to používali jen američani, tak by ta tvá prohlášení mohla mít i nějakou váhu (holt by nechtěli přiznat chybu a používali to i za cenu prušvihu, ale proč by si to objednávaly země jako izrael, japonsko, austrálie a podobně? škoda že jsi jim neporadil - mohli ušetřit :(

[Bystroushaak]

Imho to myslel tak, že soudruzi z ameriky je vyrobili, takže jsou oni, kdo udělal chybu při výrobě. Což je pravda, protože ten software byl a je příšerně zabugovaný, zpožděný a nedodělaný (například doteď stále nepodporuje některé druhy zbraní!).

Viz třeba starší, ale názorný Problémy F-35 Lightning II s palubním kanónem a třeba Air force deklarovalo IOC (Initial Operational Capability, něco jako „Počáteční Operační Schopnosti“, tedy podporu software pro boj) docela nedávno.

Celkově je to ukázka silně nezvládnutého vývoje velkého projektu, jen je otázkou, jestli je nezvládnutý schválně, aby se na něm mohli víc napakovat.

[Radovan]

Tohle už není chyba jazyka. A že F-35 je obrovský šíleně prodražený a předražený průser se ví už hodně dlouho, přitom to původně měl být levnější doplněk k F-22.

Koupil by sis Fabii u které nejdou stěrače, zatáčí jen doleva, má tři rychlosti dozadu a dvě dopředu, jenom jednu přední sedačku, a občas jí za jízdy zhasnou všechna světla, za cenu dvou Octavií, které sice nejsou žádný zázrak a loupe se z nich barva v pruzích, ale většinou dojedou a dovezou náklad kam je potřeba? Zvlášť když výrobce před deseti lety sliboval že do pěti let všechny problémy vyřeší, a teď tvrdí totéž... :-X

[Rob]

no právě že nekoupil - jenže tady to lidi kupojou. Tak mi z toho vychází že sice je to zabugovaný a šíleně předražený (s tím se nedá nesouhlasit), jenže tyhle věci holt asi nepřeváží její klady ...

ono na rovinu - co je jako varianta? T50 bez motorů (Izdělije 30 má být kolem 2025)? J20 která teď někdy možná vstoupí do výzbroje?

nechci tady vířit flame, ale tahle absolutní kritika všeho usa taky není moc fér ...

[Radovan]

Lidi ne, politici. A generálové, znáš Pentagon Wars? Doporučuji

Nekritizuji vše USA, jen to špatné. Ono toho není málo. Ten F-22 je celkem obstojné letadlo, po dost slabých začátcích se z toho vyklubalo něco co aspoň trochu funguje. A ten pilot co prototyp hned při prvním letu vinou počítače nerozmlátil na trsátka má mojí poklonu! To byly reakce že by se kobra podělala strachy.

Byl jsem loni v Ostravě na dnech NATO. Chtěl jsem si po letech zase okouknout B-52, naposledy jsem je tady sledoval když létaly na Srbsko, některé se s těmi bombami vlekly tak nízko že jsme jim dalekohledem počítali nýty. To co jsem viděl jsem fakt nečekal, výztuhy, záplaty podlepené silikonem, zvlněný potah, podle druhu šroubů se dalo poznat v jakém období která oprava proběhla. Musím uznat že sednout do toho, naložit třicet tun bomb, odletět v desetikilometrové výšce přes půl zeměkoule, tam to vysypat a letět zase zpátky, to chce fakt pořádné koule (a pořádnou porci amfetaminu, naštěstí ho fasují). Je to totální šrot z roku 1961, a kdyby to byl náklaďák, tak už dávno technickou kontrolou neprojde.

Z B-1B kapalo palivo, a vrchol všeho byl Osprey, který mě zajímal ze všech nejvíc. Zkanibalizované náhradní díly z jiných kusů, vevnitř tak málo místa že se tam nedá postavit, všude hadice a kabely nezakryté ani kusem plachty, bál jsem se abych něco neutrhl. Z toho mi bylo fakt zle, tomuhle letadlu jsem fandil od začátku jeho vývoje

Ostatní letectva měla svoje stroje načančané, i ty polské olétané F-16 vypadaly perfektně. Dvoumístnou verzi člověk často nevidí, tu jsem si pěkně nafotil. A nejvíc jsem si tam užil let Drakenu, tahle deska totiž létá úplně jinak než ostatní (obyčejná) letadla. Dnes už je to historie, ale kouká se na to skvěle. Žádný počítač který to zoufalým kmitáním kormidel stabilizuje aby to nespadlo, jenom poctivý hydraulikou ovládaný stroj který si dokonale rozumí se vzduchem.

Varianta k F-35? Cokoliv, třeba Gripen. Pořád dost dobré letadlo. Nebo MiG-29KUB, osvědčený a masivně modernizovaný, dnes už i částečně stealth. Pokud se potkají v boji, dávám 9:1 vítězství MiGu.

T-50 je velký stroj, úplně jiná kategorie, protiváha k F-22. A že by byl bez motorů se mi fakt nezdá, když předvádí tohle: Spectacular Russian T-50 Demo MAKS 2015 PAK-FA. Dobře se podívej jak je ten prototyp stoprocentně stabilní při libovolném manévru. Přitom je to zatím jen výzkumný koncept na kterém si odlaďují nové technologie, které zpětně použijí do současných modelů řady Su-27. Ty se dají ještě pár desítek let vylepšovat, protože neexistuje nic co by se proti nim mohlo postavit. Akorát F-15, to je jediné americké letadlo které se Suchojům aspoň v něčem vyrovná. Jenže půlka amerického letectva stojí v dílnách a čeká na náhradní díly, a čeká, a čeká, a nedočká se. Nejsou totiž peníze, utratily se za F-35. Reagan chtěl SSSR uzbrojit, a zatím Putin uzbrojil USA. Jako bonus přitom zruinoval Saúdskou Arábii a zesměšnil Evropskou Unii.

[Rob]

na tohle se dá koukat z víc stran - co je lepší - jeden vymazlenej prototyp (z asi 9 co maj) - mimochodem ty správný motory fakt ještě nemaj - plánujou je když dobře tak v tom 2025 co předvádí na leteckých dnech, nebo více - méně seriovka postupně začleňovaná do výzbroje s vychytáváním chyb a laděním?

"dobitá letadla" - zase - na dny NATO usa co vím posílá co zrovna letí okolo - tak co je lepší - pár vyleštěných opečovávaných F16, nebo bojem a používáním jetý stroje ketrý si opravdu zabojovaly?

F35 vs MIG29KUB vs gripen - těžko říct - mohli by si to někde cvičně rozdat - na to bych se rád podíval :)

peníze - utratily se za F35, nebo obamacare?

a tak dále ....

[Radovan]

Nevím jak opečovávané jsou třeba zrovna ty polské F-16, spíš bych řekl že s nimi létají co můžou, protože jich také mají jen pár, navíc jsou to repasované ojetiny. Každopádně jediní Američani tam přiletěli se šrotem, teda kromě toho AVACSu, ten vypadal slušně.

Obamacare bylo jako všechno od Obamby spíš naslibované než realizované, na začátku možná krok správným směrem, ale nedotažený do konce. Každopádně jim teď Trump zakroutí kohoutky a možná i nějaký ten krk, cenu za další F-35 se mu už podařilo srazit

K těm prototypům, viděl jsem loni párek pokusných MiGů, jak se předváděly při nácviku na přehlídku k 9. květnu. Stát na tryskách dneska dokáže každý slušný tryskáč, popojíždět nad zemí sem a tam ty lepší, ale tyhle spolu tančily a hopsaly v páru, a přitom snad jen pět metrů nad zemí! No, F-35 jako nepříliš podařený klon Jaku-141 je proti nim fakt sračka, jeho jediná šance je že odpálí raketu a fofrem uteče dřív, než ho zaměří ruský radar. A to je dost malá šance, zezadu je vidět radarem i infra a rychlostí zrovna neoplývá. Ještě že Rusové nemají dost peněz na to aby takovéhle stroje vyráběli ve větším počtu, protože v situaci kdy mechanici amerického letectva objíždějí letecká muzea a vymontovávají tam součástky z exponátů, aby dostali do vzduchu aspoň něco, je jakékoliv vojenské střetnutí těchhle dvou států předem rozhodnuté. A my jsme opět v tom horším klubu :-/

[Bystroushaak]

No, F-35 jako nepříliš podařený klon Jaku-141 je proti nim fakt sračka, jeho jediná šance je že odpálí raketu a fofrem uteče dřív, než ho zaměří ruský radar.

Tak já bych to zas tak nezatracoval, zrovna dneska vyšlo Cvičení Red Flag: Stíhačka F-35 ničí soupeře poměrem 15:1

[Radovan]

Poslední věta článku to objasňuje:

V každém případě nelze číslo 15:1 brát, ostatně jako číslo 241:2 v případě F-22A, jako etalon pro výsledek jakéhokoliv nasazení F-35 (nebo F-22A) ve skutečné letecké válce.

A jestli MiG-29 simulují pomocí F-16, je třeba podotknout že těm piloti naší tygří letky na MiG-21 v simulovaných soubojích opakovaně natrhávali prdel. Rovněž podobné souboje F-15 či F-18 vs Su-27 přinesly Američanů ve 100% hezké druhé místo.

Ale jo, šanci určitě mají, protože dovedou vymyslet účinnou taktiku a učit se z chyb. Rozhoduje hlavně ta taktika, jako tenkrát v Izraeli, kdy na sestřel jednoho MiG-25 potřebovali šest letadel najednou, pomocí kterých na Syřana ušili dokonalou past. A sami si potom do mnohem primitivnější pasti pořádně naběhli.

[kyknos]

Díky, takhle už jsem se dlouho nezasmál.

[Radovan]

A ještě víc se zasměješ, až zjistíš že USA na tom nejsou zase tak nejhůř. Ze sedmi britských jaderných ponorek je pět porouchaných, jedna nabouraná, a jedna ve zkušebním provozu. Skutečná odstrašující síla, Rusové jsou z nich podělaní hrůzou

[kyknos]

Rusové řeší spíš, čeho se nažrat a čím si utřít prdel.

[Radovan]

Bejvávalo za Jelcina. Teď skupují zlato z celého světa a Američané zase jejich státní dluhopisy, protože propad ruské ekonomiky skončil a čekají růst->zisk. Viz rušení sankcí, zatímco propagandou zblblí probruselští dementi budou dál kvičet a prodělávat miliardy.

[kralyk z abclinuxu]

A tobě třeba není ani trochu blbý někomu takhle totálně lízt do zadku?

[Radovan]

Umíš dobře tahat? Protože ty klapky na očích by ti mohl závidět leckterý valach :-P

[kralyk z abclinuxu]

Jak souvisí moje klapky (ať už skutečné nebo imaginární) s tvým řiťolezectvím?

[Radovan]

Připadá ti jako řiťolezectví, když řeknu že americké námořnictvo plave v ještě větších sračkách než americké letectvo? O tom si už cvrlikají i vrabci v mainstreamu: https://www.novinky.cz/zahranicni/amerika/429070-dve-tretiny-stihacek-americkeho-namornictva-nemohou-letat.html

Ani Německo na tom není lépe, například z osmi nových transportních Airbusů A-400M je plně letuschopný jeden (možná ten co jsem obhlížel loni v Ostraně na dnech NATO, jinak moc hezké letadlo a byla u něj dlouhá fronta), druhý se stále ještě přebírá, a zbytek stojí s poruchami, převážně motorů. To je na turbovrtulový stroj dost ostuda, měli by se podívat jak je možné že dávno zastaralé Tu-95 se stejným typem pohonu Rusům bez problémů létají desítky tisíc kilometrů na okružní mise do Sýrie.

Ale to určitě zachrání změněný přístup k sexuálním menšinám v armádě, který teď vyhlásila německá ministryně obrany, doufám že to bude mít za následek přemalování znaků na strojích Bundeswhru na ten krásný čtyřbarevný LGBT, který prezentovala na konferenci: http://www.noz-cdn.de/media/2017/02/01/urn-newsml-dpa-com-20090101-170131-90-011700_201702011037_full_1.jpg No, přinejmenším jim bude na ruské frontě "teplo"

[Rob]

nepříliš podařený klon Jak 141 - fakt myslíš toho Jak (1)41, který byl postaven v asi 5 prototypech a který museli dodělat s prachama a přispěním od Lockheedu a pak jim motorovou část radši prodali (ano lockheed ji pak použil u F35 - a proč ne?) protože pro na něj v rusku neměli?

[Radovan]

Ve čtyřech prototypech, jako nástupce Jaku-38, což byl nadzvukový VTOL zařazený do výzbroje v polovině sedmdesátých let. V té době začal vývoj Jaku-41, a jeden z těch prototypů byl po vytvoření světového rekordu přečíslovaný na Jak-141. Američani koupili kompletní dokumentaci, protože jim bylo jasné že Harrier už nevylepší a sami to vyvinout nedokážou, stejně jako za padesát let nedokázali postavit vlastní nadzvukový dopravák.

[kyknos]

zatímco rusové nadzvukový dopravák museli okopírovat od britů a francouzů :)

[Radovan]

Jenom podvozek. Tvar je daný stavem poznání aerodynamických zákonů té doby, a zbytek si udělali po svém. Proto Tu-144 žral dvakrát tolik co Concorde a občas spadl

[Rob]

http://m.zoom.iprima.cz/supermoderni-americky-f-35b-ma-vnitrnosti-ze-sovetske-stihacky-jak-je-mozne

Treba tady to pisou trochu vic do detailu....

[Smutovan]

Mě by zajímalo odkud se berou ty fámy, že programátoři v C/C++ jsou výrazně lepší než ostatní. Jako C++ programátor pracuju pár let a musim říct, že jsou mezi nimi v převaze samouci a diletanti stejně jako v jiných jazycích. Radši to nemluvím o tom, když vlezu do kódu napsaného před 15 - 20 lety, který většinou vypadá, že ho psal někdo, kdo se po třech dnech beze spánku ve 4 ráno snažil dodělat program, aby v 8 byl připravený k nasazení.

[Radovan]

Ono to bylo myšleno spíš tak že programátoři v Javě jsou výrazně horší než ostatní

[JS1]

Mne neprijdou horsi, spis mi vadi mentalita "pouzivam nejpouzivanejsi jazyk, takze vsechno dela spravne".

[Smutovan]

Zrovna C++ je v celkovém způsobu programování javě dost podobné až na templaty (a tady se nabízí otázka, kolik C++ programátorů je dokáže napsat správně). A ta mentalita často platí i u C++ programátorů, zkus je nechat něco napsat ve funcionálním jazyce.

[kralyk z abclinuxu]

Ono to platí u prakticky všech jazyků, zejména u těch, které jsou často 'první' jazyk.

U Javy je to zhoršeno tím, že je hodně rozšířená a zároveň se na ní na školách demonstruje architektura aplikací. Takže lidi po několika prvních semestrech mají pocit, že aplikace == sada objektů && objekt == java.lang.Object ... :-/

[xsubway]

Hňup dokáže napsat Hovokód v jakémkoliv jazyce.-)

[xsubway]

Hovno-kód samozřejmě

[smazáno]

jojo, typicky treba "javu v pythonu" ;)

[Radovan]

Tak to je naprostá pravda! Zrovna na hovnokódu jsem kdysi našel krásnou ukázku: http://www.hovnokod.cz/659

Ten program jsem poznal na první pohled, kdysi jsem ho viděl v jedné učebnici BASICu, a i v něm to byla strašná prasárna. Někdo ho potom vzal, a doslovně přepsal do C++!!!

[Bedňa]

A zrejme si hneď vedeľ, že ten kód vznikol disasemblingom ako proof of concept.

Takých kódov je plný internet a vznily úplne za iným účelom ako si ty developer guru predstavuješ.

[Radovan]

Takže se přiznáváš k autorství?

[Bedňa]

Ten kód nepísal človek, ale to by si si musel hodiť do Google disasemling.

[Bedňa]

disassembling

[Václav Havel]

>>>Mě by zajímalo odkud se berou ty fámy, že programátoři v C/C++ jsou výrazně lepší než ostatní.

Nejsou. Ale do jisté míry jazyk určuje schopnosti těch, kdo se jim věnují. V každém oboru lidské činnosti jsou v převaze diletanti - to je Gaussova křivka lidí. V programování je to umocněno tím, že firmy berou programátory s důrazem na co nejnižší platy.

Ale až budete požadovat jakoukoli službu, třeba hledat řemeslníky. Nebo se setkáte s nějakým absolventem univerzity, či pouze kurzu třeba pro síťaře. Pak pochopíte, že diletantství je normální stav věci. To samé platí třeba i u lékařů, apod.

Dnešní pozitivní a juchající doba po vzoru pozitivní USA to jen umocňuje a včas nelikviduje diletanstské věci jako je třeba formát usx. Namísto toho lidé ztrácejí čas diskusí, jak to vylepšit. A tak se diletantství rozšiřuje.

[okbob]

Kromě jiného se dal napsat, díky návrhu, jednoprůchodový rychlý překladač, který fungoval na 8bitech s minimem paměti. Na 16bitech měl adhoc kompilovaný Pascal rychlejší start než kód v nějakém interpretu. Je velká škoda, že věci z dílny p. Wirtha se víc nerozšířily - Oberon (jazyk a operační systém) je téměř geniální. Wirth ale primárně řešil výzkum a výuku a byznys pro něj nebyla priorita.

[Václav Havel]

"Je velká škoda, že věci z dílny p. Wirtha se víc nerozšířily"

Naopak, je to velice dobře, a podle zásluhy. Dělat jazyky tak, že na prvním místě je snadnost parsovatelnosti gramatiky - je něco, co si nezaslouží přežít. Zatímco kompilátor/interpretr se dělá jednou či několikrát; programátorů, kteří to používají mohou být i milóny. Je vcelku jasné, kteří z nich by měli mít snadnější práci. Parser by to být neměl.

"Oberon (jazyk a operační systém) je téměř geniální"

Nebyl. Prozkoumal jsem v minulosti jeho jazyky, a nic moc. Přišel byste na to také, kdybyste to prošel.

Wirth převzal algolovskou syntaxi (dnes známou spíše jako pascalovskou) - tedy to, co je dobré, nebylo víceméně Wirthovou zásluhou. Ale co Wirthovou zásluhou je, že sekal jazyky s algolovskou syntaxí (díky primitivnosti gramatik Wirthových jazyků) jak na běžícím páse - a kvůli nesmyslnému důrazu na jednoduchost gramatiky - stály ty jazyky za velké kulové. Ale aktivita Wirtha ve vytváření jazyků způsobila, že algolovskou syntaxi stačil dokonale znemožnit natolik - že se tato syntaxe považuje většinově za špatnou.

Daleko lepší jazyky s algolovskou (pascalovskou) syntaxí:

1) ALGOL sám;

2) vynikajícím a přelomovým jazykem, který byl geniální sám o sobě byla Simula;

3) dále je nedoceněná Ada, i když s drobnými výhradami zejména k jejímu nedomyšlenému namespace a generikami.

qqqqq

Já bych nechtěl programovat ani v jednom z Wirthových programovacích jazyků, protože jsou jen pro zlost. Málokdo z přítomných zde zná skutečný Wirthův Pascal. Borland sám musel Pascal mohutně rozšířit, jinak by byl absolutně prakticky nepoužitelný. A nejen rozšířit - leckteré pasáže nekompatibilně předělat, zejména typ file.

Jazyky Modula (a vyšší verze) a Oberon (a vyšší verze) nejsou také žádné extra dílo. A pro praxi trpí tím samým co Pascal.

Wirthovy jazyky jsou asi nejhoršími jazyky z algolovskou syntaxí vůbec, co existují.

[Blaazen]

@ Naopak, je to velice dobře, a podle zásluhy. Dělat jazyky tak, že na prvním místě je snadnost parsovatelnosti gramatiky - je něco, co si nezaslouží přežít. Zatímco kompilátor/interpretr se dělá jednou či několikrát; programátorů, kteří to používají mohou být i milóny. Je vcelku jasné, kteří z nich by měli mít snadnější práci. Parser by to být neměl.

Tímhle si to ale postavil na hlavu. Pascal rychle kompiluje všechno, tedy i sebe sama (když je self-hosting). Díky návrhu, kde a) jen jeden průchod (nerekurzivním) prekompilerem b) jeden průchod kompilerem (stačí, protože se vše předem deklaruje) c) nemá žádné hlavičkové soubory.
A ta rychlá kompilace je to, co potom ty davu programátorů ocení. Například v Lazaru je "Syntax check", ale nikdo to nepoužívá, protože "Quick compile" je prostě tak rychlé a ukáže toho samozřejmě víc.

Ten argument někde jinde, že původní Wirthův pascal neměl break je spíš úsměvný, to mluvíme o přelomu šedesátých a sedmdesátých let.

[Václav Havel]

Někdy si připadám, že si ze mě děláte srandu. Rychlou kompilaci má dnes kde co - a nemusí kvůli tomu prznit syntaxi jazyka. Nevidím žádnou výhodu pro programátora v tom, že na jeho úkor se udělá jednoduchoučká syntaxe snadno parsovatelná. To je výhoda pro tvůrce kompilátoru, a nevýhoda pro ostatní.

To, že C/C++ má hlavičkové soubory, což je ptákovina nejhrubšího zrna, s tím souhlasím.

[kralyk z abclinuxu]

Rychlou kompilaci má dnes kde co - a nemusí kvůli tomu prznit syntaxi jazyka.

To si nemyslim, dodnes je to aktuální téma. Na rychlost kompilace se zaměřuje např. Go, které ale je na ten úkor dost osekáno o různé fíčury (např. generika). Naprosti tomu třeba rustc je notoricky pomalý (spousta statické analýzy, složitý type system, ...). Ani jedno z toho mi nepřijde jednoznačně lepší. Otázka složitosti kompilátoru je dnes stále tradeoff tak jako kdysi, akorát to máme celé škálováno na větší objemy...

[Bystroushaak]

Třeba D má rychlou kompilaci a jednoznačně lepší mi přijde.

[deda.jabko]

Málokdo z přítomných zde zná skutečný Wirthův Pascal. Borland sám musel Pascal mohutně rozšířit, jinak by byl absolutně prakticky nepoužitelný

A co ma byt? Jazyky se vyviji. Srovnej puvodni Fortran a dnesni Fortran. Srovnej C# 1.0 a C# 6.0. Srovnej puvodni C++ a C++11.

zejména typ file.

Ok. Ted se nam to keca. Ale v dobe navrhu Pascalu se pracovalo s daty trochu jinym zpusobem, viz derne stitky, pasky, atp., kde puvodni pascalovsky zpusob prace s daty dava smysl.

Nojo, kdyby tak tehdy mel Wirth vesteckou kouli nebo se aspon podival do hvezd, vedel by, ze se za dvacet let bude pracovat se soubory uplne jinak.

[Václav Havel]

Rozpitváváte vedlejší věci. Gró všeho je, že dělat jazyk s důrazem na snadnou parsovatelnost jako nejdůležitější věcí je idiocie. Na to není třeba věštecké koule.

Kromě toho existují jazyky snadněji parsovatelné, jako je třeba LISP nebo Smalltalk.

[R]

Goto? Ved tam je normalny break ako v C.

[Václav Havel]

Nikoli, v Pascalu od Wirtha nic takového není.

[Bystroushaak]

+1

[.]

To je vtip?

[dumblob]

V blogu uvádím

A to při zachování pěkných vlastností (KISS, rychlost zpracování/tvoření, použitelnost pro nekonečné proudové zpracování, spolupráce s ostatními formáty, rozšiřitelnost, kompatibilita mezi textovými editory a programovacími jazyky, atd.).

Myslím tedy, že porovnání s akademickým jazykem není na místě.

Rozhodnutí udělaná v uSX bych spíše přirovnal k vhodnému použití Eulerovy metody na numerické výpočty. Je to triviální metoda, která je nejrychlejší na použití, lidské pochopení a má velmi nízké nároky na výpočetní výkon. Poskytuje velmi přesné výsledky pro velmi malý počet kroků (uSX těží z toho, že používá pouze 3 oddělovací ASCII znaky), ale nehodí se pro velký počet kroků (Pascal používá tolik oddělovačů, že z toho jde hlava kolem). Analogicky s ostatními rozhodnutími v uSX a Pascalu.

Jsem přesvědčený, že konfigurační/serializační formáty, které mají standard popsaný na mnoha stránkách ISO A4 nejsou univerzální a jejich složitost nepřináší užitek. Proč? Protože jediným důvodem existence těchto specifikací je srozumitelnost pro člověka (viz. "binární" serializace níže). Pokud však jeden člověk není schopen zvládnout tu specifikaci (a troufám si tvrdit, že ani tady na ábíčku není ani jeden člověk, který zná např. celou specifikaci XML), pak tyto specifikace pozbývají smyslu a měli by se všude na těchto místech používat "binární" serializace (např. MessagePack, Cap'n Proto, Protobuf, ...), protože jsou výrazně rychlejší a jednodušší na strojové zpracování a jejich "nečitelnost" člověkem je irelevantní.

[Josef Kufner]

Jsem přesvědčený, že konfigurační/serializační formáty, které mají standard popsaný na mnoha stránkách ISO A4 nejsou univerzální a jejich složitost nepřináší užitek.

Ano. A proto má JSON specifikace jen 14 stran, přičemž většinu tvoří obálka, úvod, obsah a reference. Samotná specifikující kapitola je na 5 stran a to jen kvůli tomu, že použili velké obrázky pro popis gramatiky.

[Václav Havel]

To, že používáte 3 oddělovače neznamená, že se držíte hesla KISS, ani že jste vymyslel něco dobrého. Ani že z toho bude někdo/něco dobře těžit.

Abych to přirovnal, teoreticky jde x86 čip navrhnout tak, aby měl jen 3 nožičky. Dvě nožičky budou napájení, a 1 nožičky bude pro vstupní/výstupní data, samozřejmě vše serializované do jednoho signálu. Ale jen idiot by to považoval za dobrý návrh procesoru, a jen idiot by si myslel, že je to KISS návrh.

Nijak se netajím ve svých příspěvcích, že jsem nic horšího, než usx formát za svůj život ještě neviděl. Ani se nepokouším navrhnout jakékoli zlepšení, protože to je škoda energie.

Zřejmě pro návrh formátů nemáte cit. Například navrhnout apostrof pro oddělení identifikátoru a hodnoty - to chce ignoranta hrubého zrna.

Schválně píši ostře, protože chválit něco, co je odpad jako usx, je zbytečné. Když to zahodíte a převezmete něco už existujícího, případně začnete s návrhem znovu a lépe - je to lepší, než vám mazat med kolem huby.

[dumblob]

Abych to přirovnal, teoreticky jde x86 čip navrhnout tak, aby měl jen 3 nožičky. Dvě nožičky budou napájení, a 1 nožičky bude pro vstupní/výstupní data, samozřejmě vše serializované do jednoho signálu. Ale jen idiot by to považoval za dobrý návrh procesoru, a jen idiot by si myslel, že je to KISS návrh.

Všichni víme, že v IT dobrá přirovnání neexistují. Zde popisujete nožičky jako úzké hrdlo, kdežto u datových formátů (uSX není výjimkou) je úzkým hrdlem vždy datový model formátu.

Zdá se mi, že zde vedete ohromnou diskuzi na téma parsovatelnosti, přičemž to bylo zmíněno jako jedna z mnoha zajímavých (požadovaných) vlastností a nikoliv jako nějaký Svatý grál. Ani ve specifikaci uSX to není (ani nebylo) nikde zdůrazněno...

Zřejmě pro návrh formátů nemáte cit. Například navrhnout apostrof pro oddělení identifikátoru a hodnoty - to chce ignoranta hrubého zrna.

Já su rád za každý takový příklad. Apostrof zmínili již ostatní. Předpoklad byl, že téměř všichni budoucí uživatelé mají buď zkušenost s Lisp-like syntaxí a nebo to jsou "sekretářky" mající převládající zkušenost s běžným textem, kde jsou apostrofy časté a nepárové.

Každopádně tento apostrof je ale naprosto podružný problém - máme zde ASCII tabulku a v ní 253 dostupných znaků (LF, ^ a \0 jsou zabrané) a můžeme vybírat do aleluja. Nu a že bych specifikování formátu spojoval s nějakým citem pro návrh formátů, jak píšete, tak to mi zní spíše poeticky než jako vážně míněná kritika.

Hm, ale mohl bych tady udělat anketu o nejoblíbenější nepárový oddělovač pro uSX

[deda.jabko]

Pane Ponkrac, mozna by to chtelo prestat se divat do hvezd a podivat se jednou do minulosti.

Dal přednost čisté a jednoduše parsovatelné gramatice před praktickou použitelností - tedy udělal stejnou chybu jako autor usx.

Pascal vznikal v dobe, kdy tehdejsi superpocitace mely desitky dnesnich kB RAM. Takze cim jednodussi parser/prekladac, tim vic mista na data.

Protože jednoduše parsovatelná gramatika měla přednost před praktičností jazyka.

To je prakticnost z dnesniho pohledu.

Za onoho casu, pokud byl preklad vicepruchodovy, nedaly se jednotlive kroky ulozit do pameti, protoze ji bylo zoufale malo, a tak se to resilo zapisem na externi medium. To tedy znamena: ulozit fazi prekladu na pasku, premotat pasku, pripadne presunout pasku do jineho stroje, spustit dalsi fazi prekladace, v horsim pripade preskladavat derne stitky. To vse za situace, kdy na dany stroj si delaji narok dalsi programatori nebo operatori.

Takze jazyk, ktery v jednom pruchodu zvladne vygenerovat binarku a pripadne ji okamzite spustit, byl v te dobe asi velke terno a prinos k produktivite prace.

Nicméně Borland zprznil extenzi Pascalu natolik, že smrt Pascalu byla jen otázkou času přes spousty peněz a nadějí Borlandu.

Az nekdy do poloviny nultych let, byly Delphi jediny rozumny nastroj pro vyvoj pro MS Windows. Pak je vytlacil Microsoft se svou masivni kampani za C# a .NET.

[Václav Havel]

Je zvláštní, že někteří lidé jsou posedlí touhou demaskovat anonymy jako já. Nic si z toho nedělejte, na každém fóru, kde jsem mě označili za jiného člověka. Tady za Ponkráce, na audiofóru za Federmanna, a třeba na idnes za jakéhosi Šrámka. Pěstujte fantazii dál, hodně se tím bavím.

K věci: Pascal vznikal v době, kdy už na světě řada programovacích jazyků existovala. A přestože se těžko dá předpokládat, že by měl Pascal k dispozici horší počítače než ostatní - málokterý jazyk se idiotsky tehdy rozhodl všechny karty vsadit na snadnou parsovatelnost. Wirth byl asi jediný.

Ještě poznámka: Tehdy bylo spíše důležité, jak kvalitní a nenáročný kód vyplodil ten kompilátor, než to kolik průchodů bylo.

Dříve se programovalo trochu jinak a méně interaktivně. Složitější kompilace nebyla na závadu. Takový devítiprůchodový PL/I...

[deda.jabko]

Pěstujte fantazii dál, hodně se tím bavím.

To je mile.

Pascal vznikal v době, kdy už na světě řada programovacích jazyků existovala. A přestože se těžko dá předpokládat, že by měl Pascal k dispozici horší počítače než ostatní

Pascal byl zverejnen v roce 1970. V te dobe se prodavaly pocitace PDP-11, CDC6000, IBM/360 s kapacitami pameti v radech desitek kB. Dejme tomu, ze pocitac mel cca 64 kB, nejakych cca 20 kB na zakladni obsluzne rutiny/OS, dalsich dejme tomu 20 kB prekladac samotny, a hned zbyva 25 kB na samotny program, prip. data. Navic, je-li program nacitam z dernych stitku (v te dobe standardni medium pro programovani) jeden pruchod je opravdu zadouci.

Ano, tehdy jazyky uz existovaly, dlouhodoba zkusenost byla minimalni. Jazyk B (konec sedesatych let), ze ktereho vzeslo cecko nemel ani datove typy a struktury.

Tehdy bylo spíše důležité, jak kvalitní a nenáročný kód vyplodil ten kompilátor, než to kolik průchodů bylo.

Vzhledem ke zpusobu prace s danym pocitacem, tak rychly jednopruchodovy system opravdu prinasel velke benefity, viz vyse. Prekladace te doby se stezi vzmohly jen na zakladni optimalizace, nic lepsiho si dovolit ani nemohly, protoze by k tomu potrebovaly nejakou pamet a procesorovy cas, ktere se nedostavalo. Jen pro uvedeni do kontextu, Unix byl prvni OS napsany ve vyssim programovacim jazyce ostatne i proto, ze prekladace existujicich jazyku nebyly zrovna 2x efektivni.

[Václav Havel]

"Az nekdy do poloviny nultych let, byly Delphi jediny rozumny nastroj pro vyvoj pro MS Windows."

A proto jsem tehdy já i celá firma programovali v C++ Builderu. A také ve Microsoft Visual Basicu, což byl velice rozumný nástroj.

"Pak je vytlacil Microsoft se svou masivni kampani za C# a .NET."

Ono je to trochu jinak. Borland začal krachovat mnohem mnohem dříve. Aby nezkrachoval zcela, musel Microsoft investovat do Borlandu nějaké šílené peníze, tuším 120 miliónů dolarů, i když si to číslo nepamatuji přesně.

Borland se pak přejmenoval na Inprise, pak zase zpět na Borland. Ale rozhodli se všechno si dělat sami a po svém - až to finančně neutáhli.

Myslím, že podpora Pascalu byla jedna z věcí, co jim sráží vaz.

[deda.jabko]

A také ve Microsoft Visual Basicu, což byl velice rozumný nástroj.

Aaaa, pan bude odbornik! VB byl vsechno, jen ne rozumny nastroj.

Ono je to trochu jinak. Borland začal krachovat mnohem mnohem dříve.

Ano, uz jsem pomalu zapomnel, ze Microsoft tehdy pretahl Anderse Hejsberga, aby delal na vyvoji jejich nastroju.

[dumblob]

Možná mate ukázka na GitHubu, která má demonstrovat extrémní případy. Běžný případ se bude spíše podobat Java resource souborům.

Cvičně jsem přepsal moji konfiguraci gitu:

[user]
  email = xxx@gmail.com
  name = Johnny English
[core]
  pager = less -FRSX
  autocrlf = input
  safecrlf = true
  ; always use plain prompt disregarding $SSH_ASKPASS value
  askpass =
[alias]
  a = add --all
  d = difftool
  co = checkout
  ci = commit --verbose
  st = status
  br = branch
  sh = show --pretty="format:" --name-only
  logg = log --pretty=format:\"%C(auto)%h %cd %s%d [%an]\" --graph --date=short
  type = cat-file -t
  dump = cat-file -p
[commit]
  verbose = true
[diff]
  tool = vimdiff
  indentHeuristic = true
[merge]
  tool = vimdiff
[push]
  default = simple
[difftool]
  prompt = false

do uSX:

'1.0

.user.email'xxx@gmail.com
.user.name'Johnny English

.core.pager'less -FRSX
.core.autocrlf'input
.core.safecrlf'true
' always use plain prompt disregarding $SSH_ASKPASS value
.core.askpass'

.alias.a'add --all
.alias.d'difftool
.alias.co'checkout
.alias.ci'commit --verbose
.alias.st'status
.alias.br'branch
.alias.sh'show --pretty="format:" --name-only
.alias.logg'log --pretty=format:\"%C(auto)%h %cd %s%d [%an]\" --graph --date=short
.alias.type'cat-file -t
.alias.dump'cat-file -p

.commit.verbose'true

.diff.tool'vimdiff
.diff.indentHeuristic'true

.merge.tool'vimdiff

.push.default'simple

.difftool.prompt'false

Považujete tuto syntax za chaotickou? Pokud ano, pak uSX totálně selhal a specifikace by měla vypadat jinak.

[xkucf03]

Ty tečky na začátku názvů mi přijdou nadbytečné¹ a apostrof mi přijde nevhodný z vizuálních důvodů – moc to splývá dohromady – vhodnější mi přijde = nebo : ideálně s možností doplnit mezery pro lepší odlišení klíče a hodnoty případně zarovnání hodnot pod sebe (zarovnávání má sice i nevýhody, ale někdy to smysl dává).

Další věc je, že se na každém řádku opakují názvy všech nadřazených úrovní. Asi je to kvůli snadnému grepování, ale znepříjemňuje to editaci – když budeš chtít přesadit jeden uzel (zvlášť když má potomky) do jiné části stromu, tak to bude docela peklo. V XML to v podstatě jen označíš myší a přetáhneš jinam :-)

A nějak v tom nevidím, jak zapsat pole…

Shodou okolností jsem se taky zamýšlel nad vlastním formátem, pojmenoval jsem si to XFI – XML for idiots – a je to syntaxe pro datové struktury² vytvořená s ohledem na snadný zápis, přehlednost a uniformitu³. Ale zatím to není ve stavu, že bych si to troufal prezentovat ostatním :-)

_{[1] když už je potřeba odlišit více případů, tak bych na to šel tak, aby tam ve většině případů nebylo nic a v těch méně častých případech tam byl nějaký znak – pokud je ale na začátku každého řádku tečka, přijde mi to špatně navržené
[2] nevhodná pro dokumenty – pro ně bych radši něco ve stylu TeXu, ale když jsem se zamýšlel nad zápisem atributů a escapováním, tak mi z toho začalo vycházet něco složitějšího než XML…
[3] pokud možno jeden způsob, jak něco zapsat – nějaká variabilita tam je, ale jen kde to dává smysl}

[dumblob]

Ad. nabdytečnost tečky na začátku. uSX ji tam syntakticky nepotřebuje (ačkoliv je nyní v draftu povinná). Tečka měla plnit funkci vizuálního zvýraznění streamy, které obsahují víceřádkové záznamy a nejsou zobrazeny v editoru s (barevným) zvýrazněním syntaxe. Tento důvod však již v dnešní době nehraje roli. Požadavek tečky zřejmě z uSX zmizí.

Ad. apostrof. Právě z vizuálních důvodů byl zvolen apostrof a nikoliv znaky, které jsou "plnější". Hodnota od ID totiž poté není vizuálně oddělená, nýbrž silně splývá, což je přesně to, co nechceme. Nějaký nápad, který znak použít?

Ad. opakování nadřazených úrovní je v TODO listu (a ne, opravdu to není momentálně kvůli grepování ). Zatím jsou dvě varianty - buď schéma nadefinuje nejprve slovník ID, která poté budou použita (buď ve slovníku bude úplně vše, tedy v případě změny bude potřeba vložit celý slovník znovu, a nebo bude zavedena syntaxe pro referenci do slovníku - třeba ta tečka na začátku) a nebo se zavede syntaxe pro referencování pro např. nejdelší prefix (počítaný až k poslední tečce v ID) ID předchozího záznamu (to může být tečka na začátku). Zatím se více přikláním k té druhé variantě (je intuitivnější, jednodušší a vyřeší všechny smysluplné případy opakování - tedy případy s málo zanořenými strukturami).

Ad. pole, tak vzhledem k tomu, že datovou strukturou je (potenciálně nekonečný) stream dvojic, tak se na něj dá samozřejmě dívat jako na pole - stačí třeba použít stejné ID (moje_pole00) pro několik po sobě jdoucích záznamů.

[Vykook]

xkucf03 byl rychlejší, tak jen doplním. Obecně znaky, které jsou ve většině programovacích jazyků jako "párový"(apostrof, uvozovky, závorky...), bych nikdy nikam nedával sólo, protože nevím jak ostatní, ale já prostě jak narazil na první apostrof, tak jsem podvědomě hledal, kde je ten co to uzavírá... Jinak doporučuju nějakou takovouhle ukázku bez "extrémních" příkladů a s popisem řádek po řádku vložit na ten github a ještě pokud možno před tu co tam je teď. Ta totiž každého fakt vystraší a dál to číst nebude.

P.S.: Možná to bylo už někde řečeno, v tom případě se omlouvám.

[Václav Havel]

Apostrofy se dříve poměrně často používaly jako oddělovače v cestách prostorů jmen. Tedy jako třeba std'file'stream'input. Některé kompilátory to dodnes mají alespoň v objektových souborech (produktech kompilace modulů).

Jako historický zbytek to má třeba Ada pro atributy.

On totiž apostrof není a nikdy nebyl v textu žádného jazyka výhradně párový znak: "Cos' to řekl?", "Beginner's manual", "chargé d’affaires".

[Kate]

To že to kdysi bylo někde použité jako oddělovač neznamená, že je to dobrý nápad dnes. Navíc, text jakéhokoliv jazyka tak nějak nesouvisí s programovacími jazyky, kde je v dnešní době apostrof párový prakticky výhradně. Tady to spíš působí jako snaha zbytečně se za každou cenu odlišovat od ostatních formátů.

[kralyk z abclinuxu]

Autor hlavně vůbec neřekl, na co ten formát potřebuje, kromě "multiplatformních" konfiguráků, ale jinak neřekl vůbec, jaké je zaměření formátu a proč by to mělo mít některé neobvyklé fíčury (třeba ty binární data). Přijde mi, že se snaží vymyslet "obecně skvělý" formát, což IMHO nejde.

[JS1]

Přijde mi, že se snaží vymyslet "obecně skvělý" formát, což IMHO nejde.

Ano, protoze hlavni navrhove kompromisy jsou:

- Chci efektivni reprezentaci (binarni) nebo citelnou reprezentaci (textovou)?

- Chci samopopisny format (schema dat je jeho soucasti) nebo format bez schematu za ucelem uspory mista, a do jake miry?

- Chci primarne text a v nem escapovat strukturovana data (a la treba XML), nebo chci strukturovana data a v nich escapovat text (a la treba JSON)?

[dumblob]

- Chci efektivni reprezentaci (binarni) nebo citelnou reprezentaci (textovou)?

Mohu mít bez kompromisů obojí zároveň - třeba vedle sebe (text -> nepotřebuji zajistit, aby byl čitelný, protože již čitelný je; binární data -> nepotřebuji zajistit, aby byla čitelná, protože jsou binární; QED).

- Chci samopopisny format (schema dat je jeho soucasti) nebo format bez schematu za ucelem uspory mista, a do jake miry?

Mohu mít obojí zároveň (formát bude podporovat schéma, ale plně volitelně - schéma bude vyžadované pouze tehdy, pokud bude tento požadavek odesílatele vyjádřen v metadatech streamu).

- Chci primarne text a v nem escapovat strukturovana data (a la treba XML), nebo chci strukturovana data a v nich escapovat text (a la treba JSON)?

Tohle dilema začíná nabývat na důležitosti pouze s rostoucím množstvím syntaktických "vyhrazených" konstruktů. Pokud se však množství těchto konstruktů bude blížit nule (řekněme třeba 1-4), pak to nijak řešit formát nemusí a neomezí to jeho možnosti a upotřebitelnost.

Mimochodem, v uSX se lze escapování (statisticky) vyhnout, pokud si vygeneruji náhodně těch 64 oktetů jako oddělovač (pravděpodobnost, že se v jednom přenášeném záznamu objeví 64 po sobě jdoucích oktetů, které jsem si náhodně vygeneroval by měla být výrazně nižší, než že budu přenášet tak obrovský záznam, ve kterém by se nějaká taková posloupnost mohla objevit).

[Gilhad]

A po prvni strojove editaci (nacteni, uprava dat, zapsani) to bude vypadat takto?

'1.0

.core.askpass'
.core.autocrlf'input
.core.pager'less -FRSX
.core.safecrlf'true
.user.email'zzz@gmail.com
.user.name'Johnny British
' actual value must be this, so
' always use plain prompt disregarding $SSH_ASKPASS value
' until user input something else this value is used

[dumblob]

Nikoliv.

Datový model uSX je seznam dvojic (tedy pořadí je kompletně zachováno). Tento datový model však explicitně nevyžaduje, aby části bez sémantického významu (tzn. to, co je výhradně pro vizuální reprezentaci - tedy zcela prázdné řádky mezi records a odsazení tabelátorem či mezerou před ID) byly zachovány. AST pro parsování uSX to však podporuje. Tedy záleží, zdali implementátor chce zachovat vizuální reprezentaci či nikoliv.

Pokud se implementátor rozhodne ani prázdné řádky ani odsazení nepodporovat, pak bude výsledek po znovuzapsání vypadat následovně:

'1.0
.user.email'xxx@gmail.com
.user.name'Johnny English
.core.pager'less -FRSX
.core.autocrlf'input
.core.safecrlf'true
' always use plain prompt disregarding $SSH_ASKPASS value
.core.askpass'
.alias.a'add --all
.alias.d'difftool
.alias.co'checkout
.alias.ci'commit --verbose
.alias.st'status
.alias.br'branch
.alias.sh'show --pretty="format:" --name-only
.alias.logg'log --pretty=format:\"%C(auto)%h %cd %s%d [%an]\" --graph --date=short
.alias.type'cat-file -t
.alias.dump'cat-file -p
.commit.verbose'true
.diff.tool'vimdiff
.diff.indentHeuristic'true
.merge.tool'vimdiff
.push.default'simple
.difftool.prompt'false

[kralyk z abclinuxu]

Zkoušel jsi TOML?

Na co je dobré kombinovat lidsky čitelný a nečitelný data v jednom souboru / formátu?

[kralyk z abclinuxu]

K technickým detailům:

The format uses just three characters (' ^ LF) as delimiters. Any character might be used as value (there are no requirements on encoding nor anything else)

Jestliže spec neobsahuje požadavky na kódování, můžou ty delimitery být kódovaný třeba v UTF-16, UTF-32 nebo obecně jakýmkoli ASCII-nekompatibilním kódování? Linefeed v UTF-32 je 0x0000000A.

[dumblob]

Díky za připomínku. Uvedu, že formát pracuje vždy s oktety bitů (tzn. pro všechny znaky použité a popisované ve standardu).

[dumblob]

Ano, zkoušel. Právě TOML byl jeden z několika málo formátů, který mě přiměl k myšlence, že formát nutně musí podporovat jak lidsky čitelná, tak binární data.

Ještě jsem se totiž nesetkal s použitím jakéhokoliv formátu tak, aby nebylo potřeba zapsat data, pro která formát není připravený. Vznikají tak náhražky jako 7bit pro emaily, baseXX pro XML a mnohé další. Je to neefektivní (jak výpočetně, tak velikostně), vyžaduje to kupu obezliček a lidsky čitelné to taktéž není. Stejně jako v binárních formátech se dost často objevují lidsky čitelné identifikátory, které by člověk rád někdy viděl pěkně čitelné pod sebou, ale nemůže (maximálně může pustit strings), protože je formát čistě binární a nebere ani trochu ohled na lidskou čitelnost.

Mimochodem TOML považuji za extrémně složitý. A už vůbec v porovnání s tím, co poskytuje oproti ostatním lidsky čitelným formátům (YAML, INI, Java resources, JSON, XML, atd.). TOML také nepodporuje streamy (protože to je hash tabulka). I když základní myšlenka TOML je podobná (TOML je hash tabulka key + value; uSX je seznam dvojic key + value).

Mimochodem, všiml jsem si, že ve všech formátech, kde autoři zvolili pro řešení problému "zápis nepovoleného znaku" escapování se strašně špatně cokoliv lidsky píše, protože člověk musí hlídat zanořování znaků, opakování inkriminovaných znaků, escapování escapovaných escapovaných escapovaných znaků, musí znát velmi dobře standard, aby věděl ve kterých kontextech co escapovat a čím, atd. Formáty, které se escapování umí jakž takž vyhýbat považuji za lépe navržené než ty s escapováním.

[kralyk z abclinuxu]

Ano, zkoušel. Právě TOML byl jeden z několika málo formátů, který mě přiměl k myšlence, že formát nutně musí podporovat jak lidsky čitelná, tak binární data.

Docela by mě zajímala motivace / use case pro tenhle požadavek... To jsem asi ještě nikde moc neviděl...

[Josef Kufner]

Uvědomuješ si, že jakýkoliv větší binarní blob ti zasviní soubor natolik, že stejně nebude čitelný a editory budou mít problémy s nevalidním Unicode? A pokud je blob malý, tak trocha neefektivního escapování nevadí.

[Bystroushaak]

Ano, zkoušel. Právě TOML byl jeden z několika málo formátů, který mě přiměl k myšlence, že formát nutně musí podporovat jak lidsky čitelná, tak binární data.

Koukal jsi na Rebol? Sice je to programovací jazyk, ale dá se taky použít na přenos dat, podobně jako třeba lispovské s-expression.

[dumblob]

Na Rebol jsem již narazil. Je to přesný opak KISS (proto se Rebol také vůbec neujal). Ale akademicky je to moc pěkné.

[Tomáš]

Kravina na kvadrát, výplod šílence, de.ilní paskvil ... neumětelové, nýmandi.

Abych to shrnul, nelíbí se ti žádná z hotových a odladěných možností, tak si napíšeš novou, úplně sám a s chybami. Nech si poradit od zkušenějších, takhle by to nešlo.

Tvůj plán je ambiciozní, ale má pár chybiček:

• Budeš muset (sám) napsat implementace pro každou platformu (případně i programovací jazyk), kde se to bude použivat.
• Budeš se sám starat o administrativu - řízení projektu na GitHubu, odstraňování chyb, release, atd.
• Nakonec tě to zatíží víc, než kdyby sis vybral nějaký používaný formát

Přitom většina formátů, které se běžně používají, mají výbornou podporů na všech majoritních platformách (Linux, Mac, Windows) a ve všemožných jazycích.

Pokud bych chtěl být hodně konzervativní, bral bych do úvahy sprostý INI file a XML. Na binární data se dá použít Base64. Jistě existuje mnoho dalších formátů. Ale je totální hloupost zahrabat se do psaní něčeho, co je v tvém projektu okrajová záležitost.

A schválně, poznáš ze kterého filmu je citace na prvním řádku?

[kralyk z abclinuxu]

s/INI/TOML

INI je zlo. Nemá nikde žádný standard a každý parser se chová podle svýho. Naposledy, když jsem řešil INI, což bylo před pár lety, zhrozil jsem se, protože INI codec se choval jinak v kdelibs a jinak v čistém Qt.

TOML je INI-like formát, který ale má pořádnou standardizaci.

[Tomáš]

Je to, jak pravíš. Proto taky píšu sprostý INI file.

Je potřeba buď být velmi konzervativní a mít INI file, který zpracují všechny implementace stejně, nebo si vybrat jednu implementaci a tu všude používat anebo vybrat něco, co má pořádnou specifikaci.

[dumblob]

Úplný souhlas (až na INI, který nemá specifikaci ). Dokonce, světě div se, jsem ještě před započetím psaní uSX specifikace vybral MessagePack pro ten projekt a v projektu pokračoval jako by se nechumelilo.

Kdybys měl zájem dělat na tom projektu za docela pěkné peníze, tak se mi ozvi (já se Ti nemohu ozvat, protože nejsi přihlášený). Chystám se na ábíčku nabídnout dvě nebo tři pracovní pozice, ale ještě jsem se k tomu nedostal.

Vybrání MessagePack mi však nebránilo si zkusit navrhnout specifikaci, která by řešila vše, co mi na existujících formátech silně vadí.

[Heron]

Kravina na kvadrát, výplod šílence, de.ilní paskvil ... neumětelové, nýmandi.

Pojďte dál. Prosím, posaďte se. Tak to budeme točit. Už je to v produkci. Všichni jsou nadšení. To byl produkční, ten co tu byl.

[JS1]

Myslim, ze jednotny format pro lidsky citelnou konfiguraci (text) a binarni je blbost.

Pro binarni data mame CBOR a Msgpack. Pro textova existuji s-expressions a YAML. Skoro vsechno tohle ma RFC.

Jinak me by se libilo XML (tj.markup s mixed tagy) ve stylu TeXu. To asi zatim na trhu chybi.

[Sten]

YAML +1

Pro binární data EBML, používá to Matroska MKV

[dumblob]

YAML se příliš nepovedl (viz. escapování, brutální specifikace plná výjimek a neintuitivních řešení, velmi špatná podpora binárních reprezentací, atd.).

EBML je v mnohém dost podobný uSX a rád bych ho použil. Ale má stále jednu velkou nevýhodu - definuje konečnou množinu typů podporovaných dat, což přináší hned několik zásadních omezení:

• Každá implementace ty typy musí implementovat (i přesto, že je nevyužiji, protože nevyhovují a tudíž použiji pouze typ UTF-8, do kterého si mnou definovanou serializací (což dále potvrzuje selhání formátu, který již ve specifikaci typy má) konečně nasoukám všechna má data).
• Data jednotlivých typů se musí se překódovávat do kódování dle specifikace (narozdíl od např. Cap'n Proto).
• Poskytované typy jsou low level (tzn. nemůžu jednoduše udělat to samé co ve Smalltalku, že pošlu zprávu s jakýmkoliv obsahem, aniž bych ručně řešil rozpad na atomické typy podporované EBML a na druhé straně je zase stejným způsobem skládal dohromady).
• Za pár let budou nejrozšířenější úplně jiné typy (vývoj typů lze hezky sledovat na funkcionálních jazycích a dále na repozitářích jako DefinitelyTyped

[Sten]

1. Nemusí. Pokud je nepoužívá, může ty typy ignorovat, protože každý element definuje délku.
2. Typ BINARY není nijak kódován.
3. Můžete pomocí DTD definovat skládané typy (container), stejně jako skládáte třídy v OOP. Jak myslíte, že to dělá ten Smalltalk, když posílá zprávu přes síť? Rozloží ji na jednotlivé atomy a na druhé straně zase složí (třeba pomocí ObjectDumper/ObjectLoader či DataStream).
4. Tak se do EBML přidají. EBML lze rozšířit, pokud by to bylo potřeba. Nebo si můžete nadefinovat svůj typ založený na BINARY a dát si do něj, co chcete.

[dumblob]

1. Hm, zdá se, že jsou všechny elementy skutečně volitelné (tedy kromě root elementu).
2. Požitím převážně/všude BINARY bychom ten formát silně degradovali. Ale možnost by to skutečně byla.
3. Skládané typy zní pěkně, ale neřeší to základní problém typování v (přenosových/perzistentních) formátech. A sice z problému "typ u tvůrce obsahu" se stává "dva různé typy - ten u tvůrce obsahu a ten v přenosovém formátu". Zřejmě bych tedy stejně nakonec skončil u binárního blobu a raději totálně degradoval EBML.
4. To je fakt a IMHO ten správný přístup (uSX počítá s tím samým).

Ještě bych doplnil, že EBML je do malé míry dokonce lidsky čitelný - chybí však vizuálně reprezentovatelné rozdělení na záznamy a hlavně editace je možná pouze v hex editoru (první oktet(y) musí mít právě jeden bit v jedničce). EBML také limituje délku ID na 4 oktety, což je žalostně málo - představme si triviální příklad konfigurace gitu výše a totálně bychom pohořeli.

[xkucf03]

Jinak me by se libilo XML (tj.markup s mixed tagy) ve stylu TeXu.

Nad tím jsem shodou okolností taky přemýšlel. TeXová syntaxe je jedna z možností, hodí se pro tvorbu dokumentů (text a v něm sem tam nějaká ta značka). Naopak pro popis datových struktur (a konfigurace) by se mi víc líbilo to založit na odsazování.

Každopádně logickým výstupem by byl DOM resp. SAX události, takže by nebyl problém to použít na místě XML nebo dokonce podporovat víc formátů zápisu současně. Něco málo už jsem implementoval v alt2xml.

[dumblob]

Každopádně logickým výstupem by byl DOM resp. SAX události, takže by nebyl problém to použít na místě XML nebo dokonce podporovat víc formátů zápisu současně.

Ju, s tím uSX počítá - viz. paragraf o obousměrném 1:1 mapování do/z jiných formátů (např. XML).

[dumblob]

CBOR by nebyl špatný, kdyby neměl typy (viz. nevýhody v komentáři 47.

MessagePack používám (má jednu málo známou výhodu oproti ostatním formátům - dá se parsovat i v jazycích s garbage collectorem pouze s jednou či dvěma alokacemi paměti, což je hodně znát na výkonu při zpracování streamů apod.).

YAML se v mnohém nepovedl (viz. komentář níže).

A s-expressions nejsou formátem ani syntaxí (uSX pochopitelně může zachytit stromovou syntaxi s-expressions).

Jinak me by se libilo XML (tj.markup s mixed tagy) ve stylu TeXu. To asi zatim na trhu chybi.

Můžete to rozvést (stačí ukázkový konfigurák)? Docela mě to zajímá.

[JS1]

Nechapu, vadi ti CBOR a nevadi MsgPack? Ja jsem se nakonec rozhodl pro CBOR, protoze ma RFC. Te vytce s typy moc nerozumim - z moji zkusenosti je CBOR jednoduchy na generovani i parsovani.

Ano, YAML ma svoje nevyhody, ale je celkem pouzitelny.

A ten TeXovy markup byl spis na dokumenty nez konfiguraky. To jak bych si to predstavoval poslu az budu doma.

Musis si polozit otazku, co chces... Chces binarni nebo textovy format, a proc? Jestli chces format, ktery si mohou lide otevrit v textovem editoru, jakekoli binarni veci predstavuji riziko, ze je ten editor tise pokazi.

Chces mit primarne text a v nem metadata (k tomu by slouzil ten muj markup, nebo jakykoli jiny markup, treba je to puvodni smysl XML), nebo chces ukladat data (treba konfiguracni) jako text? V druhem pripade pouzijes neco jako JSON, YAML, sexpy atd.

Jinak myslel jsem, ze sexpy maji RFC, tak asi ne, no.

[dumblob]

Nechapu, vadi ti CBOR a nevadi MsgPack? Ja jsem se nakonec rozhodl pro CBOR, protoze ma RFC.

CBOR je vlastně "starý MsgPack" popsaný jedním (!) aktivistou jako RFC, aniž by mu to komunita schválila (on tam ještě udělal minimálně jednu docela zásadní změnu zcela dle vlastní vůle, takže to není úplně košér...). Viz. níže.

Te vytce s typy moc nerozumim - z moji zkusenosti je CBOR jednoduchy na generovani i parsovani.

Nedopsal jsem předtím větu .

CBOR je fork MsgPack přesně v době (cca pár měsíců) těsně před tím gigantickým boomem MsgPacku, který způsobil nezanedbatelné zlepšení samotného MsgPacku. Jenomže CBOR byl prostě akorát formálně dle RFC pravidel popsaný MsgPack jedním nezávislým člověkem (který neměl s autory a komunitou MsgPacku prakticky nic společného) z té doby před boomem (a to dokonce s několika změnami, které si komunita nepřála a které byly nakonec v následujících revizích MsgPacku rozhodnuty zcela opačně - např. CBOR podporuje "nekonečný" string, ale MsgPack nikoliv - což je mimochodem chlupa rychlejší na zpracování).

Jinak co chci (požadavky na formát) jsou popsány v blogovém příspěvku a v úvodu samotného draftu specifikace.

[JS]

Můžete to rozvést (stačí ukázkový konfigurák)? Docela mě to zajímá.

Ukazkovy konfigurak nemam, ale tady je mikrospecifikace. Me slo puvodne spis o neco ve stylu Autodocu, ale jednodussiho (konzistentnejsiho) na zapis.

Kex markup is similar to XML or HTML, the markup can intersperse normal text (typically UTF-8).
The normal tags have no meaning and are left untouched unless there is a macro definition that can evaluate it.
The processing of document with Kex syntax will evaluate all the tags that have macros.
Unless define otherwise, the evaluation only happens once (that is, Kex markup can be processed to yield another with Kex narkup).

Kex markup syntax:
\symbol - single tag, symbol is any valid C literal (also character ':' is reserved for namespaces and can occur in symbol)
\symbol{text} -  pair tag, text is any Kex markup
\symbol[arg]{text} - pair tag with optional argument (aka attribute), again attributes can have Kex markup 
\symbol[arg1|arg2|..]{text} - pair tag with multiple arguments (also character ':' can be used within arguments to separate key and value to represent dictionary)
\symbol. - single tag which symbol would normally blend with the text
\!symbol - metatag, reserved for use in Kex macro language (so the normal tags are solely reserved for the user)
\#{comment} - block comment, comment can contain Kex markup (so the closing brace must match)
\#comment - comment to the end of line (copied/ignored during evaluation)
\\ \{ \} \[ \] \| \. \: - escapes for special symbols
\ - escape for whitespace, causes the whitespace to be ignored (not included in the output)
\%xxxx. - escape for any character, xxxx is Unicode in hex, '.' is optional
\!![endmark]{literal text|endmark} - universal escape, endmark can be user specified sequence of characters, endmark is optional and can be empty 
\&location - defines the current location in the document with a name (can be any symbol)
\@location - refers to the named location

[Václav Havel]

S prominutím debilněji už to vymyslet nešlo.

[unicode]

Podle mě jde spíš vidět, že autor neprogramuje.

[.]

Jednou se za to budeš strašně stydět. Snad.

[xkucf03]

Možná to tam někde je (ještě jsem to nepřečetl celé), ale jaká je logická struktura dat popisovaných tím formátem? Např. v případě XML je to strom elementů, atributů, komentářů případně dalších uzlů. Jak to vypadá u tvého formátu? Můžeš to nakreslit? (obrázek hodně pomůže a člověk na první pohled vidí, o co jde)

Tímhle bych každopádně začal a až pak vymýšlel způsob zápisu. Těch může být ostatně víc (např. binární a textový, různé formy), ale logická struktura, které se z toho načte je vždy jedna.

[veni vidi vici]

přišel.jsem

zeblil.se

odešel.jsem

[podlesh]

veni
vermini
vomui

[alfonz]

V minulosti jsme se pro Připravto snažili používat INI, pak YAML a pak nějaký config podobný INI. Zjistili jsme, že je to obvykle zbytečné a nic to neřeší. Takže jsme se inspirovali u jiných projektů např. Django a jiné projekty prostě používají konfiguraci přímo v Pythonu - oddělený soubor. U dat, které jsou načítané i jinde používáme JSON - je bezpečný a vcelku bezproblémový (pokud by uměl komentáře či koncové čárky byl by skvělý). Když si vzpomenu co jsme měli za různé "podivné" problémy např. v YAML či INI tak již nikdy více. Mimo to nastavení v Pythonu má také výhody v tom, že se dá jednoduše naimportovat či přímo udělat specifický kód pro dané nastavení.

[:::]

s tim JSONem je to stejne sranda, ze nekdo navrhne relativne pouzitelny format a potom to takhle zabije tim ze zakaze carky a komentare... :-/

[dumblob]

Bingo!

Tohle řešení používáme snad úplně všude až na tuhle zapeklitou výjimku, kde se očekává zpracování v několik vzájemně nekompatibilních jazycích a zároveň časté ruční čtení, popř. editace.

MsgPack se musí generovat, takže to nyní neplní náš účel, takže zatím na prototypování používáme JSON a místo binárních dat posíláme pouze testovací ASCII stringy.

Možná nakonec zakotvíme u nějakého CSV, pokud se nám podaří potřebná data nějak rozumně dostat do přehledné první normální formy (ano, nemůžeme si dovolit více tabulek paradoxně z důvodu jednoduchosti pro uživatele).

[Odin1918]

Proc vymyslite kolo? Co prinasi toto oproti xml/json/yaml ? Imho nic.

[:::]

Tak tohle konkretne neprinasi nic, ale jinak xml/json/yaml vsechny do jednoho sajou

[Radovan]

Dnešní začátečníci to už holt neznají, ale pár desetiletí byl nejrozšířenější Intel HEX.

Do kombinace s textem i UTF-8 dokonale použitelný.

[dumblob]

To by nám "sekretářka" dala, že musí někde počítat nějaké délky, zapisovat bajtová čísla apod.

Viz. heslo "sekretářky" v příspěvku výše.

[jekub]

Pokud jde o konfigurační volby, není nad ini, kde je pouze popis, odkud konfiguraci načíst - bdb, sqlite nebo ldap.