Styly programování

[Kit]

Co se týče XML. Jeho velká výhoda je vyzrálost - spousta nástrojů, schema, transformace.

Osobně jsem nikdy nepochopil kdy psát atributy a kdy zanořené uzly. Ale tuhle někdo dobře komentoval, že to je z důvodu, že to je původně dokumentový formát. To pak začne dávat smysl - ne, že by to něco vyřešilo.

Princip není složitý. Pokud není možné, aby bylo víc stejných atributů a skutečně bude atomický, můžeš použít atribut. Jinak zanořené uzly. Zkus porovnat:

Kód: [Vybrat]

<osoba jméno="Adam" příjmení="Bernau"/>a

Kód: [Vybrat]

<osoba>
    <jméno>Adam</jméno>
    <příjmení>Bernau</příjmení>
</osoba>
Oba zápisy jsou možné, architekt dokumentu určuje, který z nich bude použit. Osobně dávám přednost prvnímu zápisu, protože je stručnější než odpovídající JSON a dobře se generuje při exportu databázové tabulky, ale často je v požadavcích, aby byl použit druhý způsob.

S xslt jsem se na jednom projektu tak strašně spálil, že jsem ho zavrhl zcela, a raději jsem to přepsal do Rustu (sorry hejtři). A to mě nikdo nemůže po právu obvinit z toho, že bych se necítil dobře ve funkcionálním a deklarativním světě. Jak to ale budu řešit v situaci, kdy budu chtít uživatelské transformace... To bude ještě radost.

Na jedné straně máme XML, kde se escapuje snad půlstovkou různých způsobů, na druhé straně JSON, kde je jenom jeden způsob, ale pro změnu se escapuje všechno.

Mě to celé přijde, že vůči XML jsou oprávněné výhrady, ale JSON jde úplně stejnou cestou a neřeší vůbec nic.

Do jedné firmy mě přijali právě proto, že umím XSLT. Bez něho nebylo možné zajistit, aby skript doběhl za kratší dobu než za 24 hodin. XSLT to s přehledem zvládl s drátem v USB.

Escapování v XML neřeším, neboť to dělají běžné generátory. Někdy však klient pošle nevalidní XML, například název francouzského parfému v souboru kódovaném ve Windows-1250. No jo, Pohoda není vždy pohodová, když ji někdo blbě nastaví. Čtečka XML to samozřejmě odmítla.

Mám proti XML jednu výhradu: Neporadí si s dvojicí znaků "--" v komentáři. Generátor to klidně vygeneruje, ale parser nepřečte. Je to bug.

[Reklama]

[Kit]

Mě to celé přijde, že vůči XML jsou oprávněné výhrady, ale JSON jde úplně stejnou cestou a neřeší vůbec nic.

Zrovna v tomhle srovnání dva rozdíly vidím. Jeden můžeme označit za otázku osobních preferencí, a sice, že JSON se mi většinou čte o dost snáz, než XML, protože prostě míň znečišťuje značkama (a na rozdíl zase od YAML ho nerozhodí špatné odsazení).  A druhý, že JSON zatím zůstal u toho dokumentu a má jednoduchou gramatiku, zatímco  XML je prostě o dost složitější - takže pokud udělají tu stejnou práci, proč bych měl mít 10x tak velkou knihovnu (a tedy i větší šance chyb, o nutnosti udržet XSLT venku ani nemluvě)?

Jiná situace ale je, pokud v tom XML opravdu využíváš věci, které JSON nemá, nebo v něm rovnou programuješ.

Pokud jsou v JSONu české znaky, tak se to čte blbě. Jak poznáš znakovou sadu, ve které byl napsán?

XML je komplexním řešením. I Microsoft ho použil pro ukládání všech dokumentů MS Office. Jsou to soubory s "-x" na konci přípony.

XML je o zvyku a také o nástrojích, které používáš pro práci s ním. Je přísné na validitu dokumentů, o to je však méně problémů při používání. Mimochodem to zlomilo vaz XHTML.

JSON nemá ani komentáře. V XML je můžeš i zpracovávat. JSON nemá ani definici použité znakové sady. Processing instructions JSON také nemá a přitom je to fakt mocný nástroj. Uživatelé JSON si však zvykli na to, že je to jen serializovaný datový strom a tak ho také používají.

Me prijde xml jak latina.  Na pohled slozite, ale prudce elegantni a mocne.

Jak že se to říká o té dokonalosti a přidávání věcí? Jo aha: Dokonalosti není dosaženo tehdy, když už není co přidat, ale tehdy, když už není co odebrat.   

Specifikace XML je asi na 14 stránkách. Je to moc?

[Jiří Havel]

XML je komplexním řešením.
...
Specifikace XML je asi na 14 stránkách. Je to moc?

Neprotiřečí si to trochu?
Ono je xml a xml. Jedno je jednoduchý formát, který toho vlastně ani moc neumí. No a druhé je ekosystém na ten formát navázaných technologií, který je tak rozsáhlý, že ho zase neumí moc lidí.

[Kit]

XML je komplexním řešením.
...
Specifikace XML je asi na 14 stránkách. Je to moc?

Neprotiřečí si to trochu?
Ono je xml a xml. Jedno je jednoduchý formát, který toho vlastně ani moc neumí. No a druhé je ekosystém na ten formát navázaných technologií, který je tak rozsáhlý, že ho zase neumí moc lidí.

Proč se tedy pro tvorbu webů místo HTML nepoužívá JSON, když je tak skvělý?

Je snad chybou XML, že jsou lidé líní se ho naučit a místo toho ho pomlouvají?

[Ink]

XML je komplexním řešením.
...
Specifikace XML je asi na 14 stránkách. Je to moc?

Neprotiřečí si to trochu?
Ono je xml a xml. Jedno je jednoduchý formát, který toho vlastně ani moc neumí. No a druhé je ekosystém na ten formát navázaných technologií, který je tak rozsáhlý, že ho zase neumí moc lidí.

Proč se tedy pro tvorbu webů místo HTML nepoužívá JSON, když je tak skvělý?

Je snad chybou XML, že jsou lidé líní se ho naučit a místo toho ho pomlouvají?

Ano, je chybou XML (respektive jeho návrhu), že se s ním blbě pracuje. A bez urážky, psát nějaké transformace v tak odporné syntaxi, jakou má XSLT, chce jenom mimoň nebo masochista.

[Reklama]

[Honzan .]

Doporučuju dobré video proč nepoužívat clean code.

Clean code, horrible performance
https://youtu.be/tD5NrevFtbU?si=2NGwwfGr3vcXoUCX

Nebo přesněji by se to dalo říct tak, že je to špatné video, které navíc nijak  nezpochybnilo nutnost dodržovat  clean code
(nejen Clean Code).


Už dávno je programátor mnohem dražší, než hw...

Kód programu je dorozumivacií prostředek mezi programátory i mezi jejich jednotlivými týmy.

Spousta aplikací se musí udržovat i třicet čtyřicet let - a současně jsou to ty, které nejsou malými jednoduchoučkými oneman show.

Překladače jsou čím dál efektivnější - přip. prasárny si zaimplementují samy automaticky, nemusite to dělat vy ve svém high-level kódu.

Ne-bezpečnost (vulnerabilita ap.) systémů/softwaru roste, dalo by se říct skoro raketově - alespoň při pohledu na objem kyberzločinu a na seznamy cvéček..

Atd atd...

To vše mluví pro jasný, srozumitelný, kvalitní a dobře pouklízený kód.
Pro dodržování dobrých pravidel.

Pokud někdo chce skutečně v tomhle oboru dělat business.


Optimalizovat se občas něco musí. Něco.

Vyrábět obsesi výkonem (rychlostí běhu programu) se nemusí.

Jediná oblast, kde se musíte trápit obskurními metodami zrychlování softwaru je když prodáváte těm, co nemají peníze (např. prodej počítačových her dětem, které nemají na normální hw) - což se ale shodneme, že není moc dobrý business plán.

[Ink]

Optimalizovat se občas něco musí. Něco.

Přesně, tight loops a věci, které z profileru vylezou jako priority. Amdahlův zákon je zákon.

[cznarg]

Pokud jsou v JSONu české znaky, tak se to čte blbě. Jak poznáš znakovou sadu, ve které byl napsán?

To je fiktivní problém nebo reálný? Všechny nové systémy běží v UTF-8. Je reálný důvod aby někdo běžel v něčem jiném? Navíc RFC kolem JSONu říká že dokument musí být jen a jen v UTF-8, takže to poznám zcela jednoduše.

JSON nemá ani komentáře. V XML je můžeš i zpracovávat. JSON nemá ani definici použité znakové sady. Processing instructions JSON také nemá a přitom je to fakt mocný nástroj. Uživatelé JSON si však zvykli na to, že je to jen serializovaný datový strom a tak ho také používají.

Komentáře - Proč by proboha někdo chtěl do generovaného výstupu dávat komentáře (api request, response, dokumenty atd.) Aby zvýšil bandwidth a cenu parsování dat nesmyslem který druhá strana zahodí?
Co se processing instruction týče, tak je to jen věc syntaxe, sémantiky a kontraktu, žádná magie. Cílová aplikace to musí podporovat tak jako tak, takže jaký je přesně rozdíl mezi
<?cache ttl="200"?>
a
{"_cache": { "ttl": 200 } }

[cznarg]

Proč se tedy pro tvorbu webů místo HTML nepoužívá JSON, když je tak skvělý?

Nechete přirovnávat HTML ke XML, že? Přestože tam je podobnost, HTML má trochu daleko k validnímu XML...
A jinak je to protože první použití HTML bylo lidmi (psali ho lidé). Nešlo o strojově generovaný kód. Jenže taky se podívejte kdy HTML a XML vzniklo. Kdyby dneska někdo navrhoval nový formát pro browsery, osobně si myslím že HTML by už nepoužil.

Je snad chybou XML, že jsou lidé líní se ho naučit a místo toho ho pomlouvají?

Já jsem třeba XML uměl velmi dobře. Taky XSLT, XML Schema atd. Stejně ho pomlouvám, protože oproti JSON to je prostě těžce neefektivní, složitý formát který obrazně řečeno k předání jednoduché informace mezi stroji typu { "temperature": { "value": 20, unit: "C" } } nebo {"payment": {"currency": "CZK", "value": 210.20, ... }} potřebuje poměrně dost boilerplate a heavy parser.

[Kit]

XML je komplexním řešením.
...
Specifikace XML je asi na 14 stránkách. Je to moc?

Neprotiřečí si to trochu?
Ono je xml a xml. Jedno je jednoduchý formát, který toho vlastně ani moc neumí. No a druhé je ekosystém na ten formát navázaných technologií, který je tak rozsáhlý, že ho zase neumí moc lidí.

Proč se tedy pro tvorbu webů místo HTML nepoužívá JSON, když je tak skvělý?

Je snad chybou XML, že jsou lidé líní se ho naučit a místo toho ho pomlouvají?

Ano, je chybou XML (respektive jeho návrhu), že se s ním blbě pracuje. A bez urážky, psát nějaké transformace v tak odporné syntaxi, jakou má XSLT, chce jenom mimoň nebo masochista.

S dnešním IDE nebo s Vimem či Emacsem je to hračka. AI ti to také napíše.

[Kit]

Je snad chybou XML, že jsou lidé líní se ho naučit a místo toho ho pomlouvají?

Já jsem třeba XML uměl velmi dobře. Taky XSLT, XML Schema atd. Stejně ho pomlouvám, protože oproti JSON to je prostě těžce neefektivní, složitý formát který obrazně řečeno k předání jednoduché informace mezi stroji typu { "temperature": { "value": 20, unit: "C" } } nebo {"payment": {"currency": "CZK", "value": 210.20, ... }} potřebuje poměrně dost boilerplate a heavy parser.

Kód: [Vybrat]

<temperature value="20" unit="C"/>
<payment currency="CZK" value="210.20"/>
mi připadá čitelnější.

[cznarg]

Je snad chybou XML, že jsou lidé líní se ho naučit a místo toho ho pomlouvají?

Já jsem třeba XML uměl velmi dobře. Taky XSLT, XML Schema atd. Stejně ho pomlouvám, protože oproti JSON to je prostě těžce neefektivní, složitý formát který obrazně řečeno k předání jednoduché informace mezi stroji typu { "temperature": { "value": 20, unit: "C" } } nebo {"payment": {"currency": "CZK", "value": 210.20, ... }} potřebuje poměrně dost boilerplate a heavy parser.

Kód: [Vybrat]

<temperature value="20" unit="C"/>
<payment currency="CZK" value="210.20"/>
mi připadá čitelnější.

A pak si někdo vzpomene že XML umí schéma a namespace a že to každý cool a in člověk musí použít

<?xml version="1.0" encoding="utf-8"?>
<temp:record
  xmlns:temp="https://example.com/temperature"
  xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
  xsi:schemaLocation=" https://example.com/temperature https://example.com/temperature/temperature.xsd">

  <temp:temperature temp:value="20" temp:unit="C" />

</temp:record>

Samozřejmě, že jednoduché XML takhle vypadat nemusí. Jenže proč to nepoužít když to jsou "výhody" xml. A jakmile je reálně začnete používat, syntaktická i implementační režie(celkem zbytečná) kolem rychle narůstá.
Navíc, čitelnost pro člověka je příjemný bonus, ale u formátu určeného primárně pro komunikaci mezi stroji není primární. API nefunguje tak že jednu odpověď píše sekretářka a druhá sekretářka ji čte. Osobně si myslím že je důležitý rozumný kompromis mezi čitelností pro člověka (v případě debuggingu, auditu etc.), jednoduchostí a množstvím režie (aneb kolik potřebujete serverů na generování a čtení).

[xyz]

Je snad chybou XML, že jsou lidé líní se ho naučit a místo toho ho pomlouvají?

Já jsem třeba XML uměl velmi dobře. Taky XSLT, XML Schema atd. Stejně ho pomlouvám, protože oproti JSON to je prostě těžce neefektivní, složitý formát který obrazně řečeno k předání jednoduché informace mezi stroji typu { "temperature": { "value": 20, unit: "C" } } nebo {"payment": {"currency": "CZK", "value": 210.20, ... }} potřebuje poměrně dost boilerplate a heavy parser.

Kód: [Vybrat]

<temperature value="20" unit="C"/>
<payment currency="CZK" value="210.20"/>
mi připadá čitelnější.

A pak si někdo vzpomene že XML umí schéma a namespace a že to každý cool a in člověk musí použít

<?xml version="1.0" encoding="utf-8"?>
<temp:record
  xmlns:temp="https://example.com/temperature"
  xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
  xsi:schemaLocation=" https://example.com/temperature https://example.com/temperature/temperature.xsd">

  <temp:temperature temp:value="20" temp:unit="C" />

</temp:record>

Samozřejmě, že jednoduché XML takhle vypadat nemusí. Jenže proč to nepoužít když to jsou "výhody" xml. A jakmile je reálně začnete používat, syntaktická i implementační režie(celkem zbytečná) kolem rychle narůstá.
Navíc, čitelnost pro člověka je příjemný bonus, ale u formátu určeného primárně pro komunikaci mezi stroji není primární. API nefunguje tak že jednu odpověď píše sekretářka a druhá sekretářka ji čte. Osobně si myslím že je důležitý rozumný kompromis mezi čitelností pro člověka (v případě debuggingu, auditu etc.), jednoduchostí a množstvím režie (aneb kolik potřebujete serverů na generování a čtení).

ne, Kit si i za 50 let bude parsovat svoje "XML + XML amespace + XSD + XSLT + JAXB a ja nevim, co jeste" kombo a ostatni budou pouzivat jednodussi formaty na vymenu dat.

[xyz]

Je snad chybou XML, že jsou lidé líní se ho naučit a místo toho ho pomlouvají?

Já jsem třeba XML uměl velmi dobře. Taky XSLT, XML Schema atd. Stejně ho pomlouvám, protože oproti JSON to je prostě těžce neefektivní, složitý formát který obrazně řečeno k předání jednoduché informace mezi stroji typu { "temperature": { "value": 20, unit: "C" } } nebo {"payment": {"currency": "CZK", "value": 210.20, ... }} potřebuje poměrně dost boilerplate a heavy parser.

Kód: [Vybrat]

<temperature value="20" unit="C"/>
<payment currency="CZK" value="210.20"/>
mi připadá čitelnější.

A pak si někdo vzpomene že XML umí schéma a namespace a že to každý cool a in člověk musí použít

<?xml version="1.0" encoding="utf-8"?>
<temp:record
  xmlns:temp="https://example.com/temperature"
  xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
  xsi:schemaLocation=" https://example.com/temperature https://example.com/temperature/temperature.xsd">

  <temp:temperature temp:value="20" temp:unit="C" />

</temp:record>

Samozřejmě, že jednoduché XML takhle vypadat nemusí. Jenže proč to nepoužít když to jsou "výhody" xml. A jakmile je reálně začnete používat, syntaktická i implementační režie(celkem zbytečná) kolem rychle narůstá.
Navíc, čitelnost pro člověka je příjemný bonus, ale u formátu určeného primárně pro komunikaci mezi stroji není primární. API nefunguje tak že jednu odpověď píše sekretářka a druhá sekretářka ji čte. Osobně si myslím že je důležitý rozumný kompromis mezi čitelností pro člověka (v případě debuggingu, auditu etc.), jednoduchostí a množstvím režie (aneb kolik potřebujete serverů na generování a čtení).

ne, Kit si i za 50 let bude parsovat svoje "XML + XML amespace + XSD + XSLT + JAXB a ja nevim, co jeste" kombo a ostatni budou pouzivat jednodussi formaty na vymenu dat.

Nezpochybnuju prumyslove standardy jako jsou platby (SEPA) atd...

[Kit]

Kód: [Vybrat]

<temperature value="20" unit="C"/>
<payment currency="CZK" value="210.20"/>
mi připadá čitelnější.

A pak si někdo vzpomene že XML umí schéma a namespace a že to každý cool a in člověk musí použít

<?xml version="1.0" encoding="utf-8"?>
<temp:record
  xmlns:temp="https://example.com/temperature"
  xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
  xsi:schemaLocation=" https://example.com/temperature https://example.com/temperature/temperature.xsd">

  <temp:temperature temp:value="20" temp:unit="C" />

</temp:record>

Samozřejmě, že jednoduché XML takhle vypadat nemusí. Jenže proč to nepoužít když to jsou "výhody" xml. A jakmile je reálně začnete používat, syntaktická i implementační režie(celkem zbytečná) kolem rychle narůstá.
Navíc, čitelnost pro člověka je příjemný bonus, ale u formátu určeného primárně pro komunikaci mezi stroji není primární. API nefunguje tak že jednu odpověď píše sekretářka a druhá sekretářka ji čte. Osobně si myslím že je důležitý rozumný kompromis mezi čitelností pro člověka (v případě debuggingu, auditu etc.), jednoduchostí a množstvím režie (aneb kolik potřebujete serverů na generování a čtení).

Tohle je záhlaví datového souboru, které má jen minimální režii. JSON tohle nemá, syntaxe se tedy domlouvá mimo datový soubor. Výměna dat mezi různými subjekty je pak žůžo labůžo. Jedna firma mi místo obvyklého XSD poslala dokumentaci ve Wordu. To má být pokrok? Kde je možnost validace před odesláním?

XML je pro mne čitelnější než JSON. U jednoduchých souborů to není velký rozdíl, ale třeba u pětiúrovňového stromu je to znát. Je spousta standardizovaných nástrojů pro vytváření pohledů ve stylu SQL. Pro JSON znám jen jq. Určitě jsou i další.

Režie u XML je mizivá, zpracování gigabajtových souborů je v rozumných časech.