Přechod z Javy na Rust. Ano či ne?

[Franta Kučera]

Nebudu ho učit serializovat se do Jsonu, nebo do Databáze, ale obecný serializování musí umět on.

Ale i obecných serializačních formátů existuje mnoho. Jeden například povolí 64-bitová celá čísla a druhý povolí celá čísla bez omezení velikosti. Jiný povolí čas na mikrosekundy, další na pikosekundy. Některé mohou řešit, jak jsou data uložena v paměti, jiné se od toho snaží abstrahovat.

Tak tenhle přístup má samozřejmě nějaké předpoklady. Objekt vysype obecný slovník obsahující nějaké základní typy a pak to chce zpátky v původní podobě beze změn. Prakticky to znamená, že ten dict bude podporovat akorát tak osekané doubly a obecné stringy.
Ve chvíli, kdy je třeba řešit nějaké ztrátové ukládání, tak to takhle obecně nejde. A je otázka, jestli se tomu ještě dá říkat serializace.

Pokud to jazyk podporuje, tak se k tomuto účelu použije spíš reflexe + případně anotace, kterými se dá upravit specifické chování a mapování.

Pokud reflexe není nebo ji nechceme použít a chceme to dělat ručně, tak to sice „vysype hashmapu“ nebo poskytne metody pro procházení toho abstraktního stromu/grafu, ale v něm se budou používat normální datové typy daného programovacího jazyka. Knihovna nebo modul, který pak dělá mapování tohoto abstraktního modelu na konkrétní serializační formát, je zodpovědný za mapování datových typů jazyka na datové typy formátu. Takže když tam třeba nebude číselný typ s příslušnou přesností, tak to namapuje na textový řetězec nebo pole bajtů a případně připojí potřebná metadata (pokud nejsou ve schématu), aby šlo následně provést bezztrátovou deserializaci zpět na objekty a typy v daném programovacím jazyce.

[Reklama]

[Franta Kučera]

P.S. Šlo by sice zavést konvenci, že o přemapování nativních typů programovacího jazyka na nějakou omezenou množinu typů používaných v abstraktním modelu se stará objekt, ale to spíš jen přidělá práci a bude se duplikovat kód v každém objektu resp. třídě. Lepší je, když to přemapování typů je odpovědnost toho de/serializátoru resp. un/marshalleru a je definovaná na jednom místě (případně ovlivnitelná konfigurací – ale naprogramované je to jen jednou).

[Franta Kučera]

Když vývojář dostane zadání, musí ho napřed analyzovat a vybrat pro něj vhodný jazyk, ve kterém ho je nejlépe zakódovat. Každý programovací jazyk má svá specifika (výhody i nevýhody), která se musí při oné volbě brát v úvahu.

Pokud se bavíme o komerčním vývoji, o firmách, tak tam je většinou rozhodnuto předem. Je tam obecně snaha omezovat tyhle „zoo“ programovacích jazyků a technologií a mít to jednotné, aby mohla fungovat zastupitelnost, aby jeden programátor mohl přecházet mezi různými projekty té firmy a nestávalo se ti, že máš několik volných programátorů v jazyce X, ale práci máš pro programátora v jazyce Y.

Vybírat si můžeš, pokud je to tvůj projekt nebo jsi šéf vývoje a máš za úkol stavět něco na zelené louce. I tam je ale dobré myslet na to, kde najdeš potřebné programátory a jaké budou mít požadavky ostatní projekty té firmy, abys to měl do budoucna pokud možno jednotné. Větší firmy si můžou dovolit větší pestrost (byť to není moc záměr, spíš důsledek jakési volnosti a experimentů), u menších je spíš snaha mít jeden hlavní jazyk. A i když je někde víc jazyků současně, tak typicky spíš z historických důvodů a postupně se přechází, nové projekty se začínají jen v tom aktuálním.

Co vývojář, to originální osobnost. Co zadání + vývojář, to originální výsledek zpracování toho zadání. Nikdy jsem nepracoval ve vývojářském týmu. A dotaz zní: Máte také podobnou zkušenost s originalitou každého vývojáře? Mohu veřejně říci, že zpracování zadání (vývoj, programování atd.) je velice osobní záležitost?

Každý má nějaký styl, co je mu nejbližší a přirozené, k čemu se na základě svých zkušeností dopracoval. Spíš než hodnotit, co je správně a odsuzovat, co je špatně, je užitečnější se zajímat, co k tomu dotyčného vedlo, na základě jakých zkušeností k tomu došel. Na druhou stranu, pokud spolu ti lidé mají pracovat v jednom týmu na jednom projektu, tak je dobré, aby si domluvili nějaký kompromis a společné konvence, které budou dodržovat – rozumný člověk si může zachovat svůj názor, ale zároveň si je vědom toho, že dělat to „o trochu horším“ způsobem, ale jednotně, je užitečnější, než když to budou dělat všichni „lépe“ ale každý jinak.

[balkovic]

Každý má nějaký styl, co je mu nejbližší a přirozené, k čemu se na základě svých zkušeností dopracoval. Spíš než hodnotit, co je správně a odsuzovat, co je špatně, je užitečnější se zajímat, co k tomu dotyčného vedlo, na základě jakých zkušeností k tomu došel. Na druhou stranu, pokud spolu ti lidé mají pracovat v jednom týmu na jednom projektu, tak je dobré, aby si domluvili nějaký kompromis a společné konvence, které budou dodržovat – rozumný člověk si může zachovat svůj názor, ale zároveň si je vědom toho, že dělat to „o trochu horším“ způsobem, ale jednotně, je užitečnější, než když to budou dělat všichni „lépe“ ale každý jinak.

Od toho sú best practices, aby sa nevynachádzalo koleso. Programátori ich aj dodržiavajú. Sú prípady, keď je potrebné sa od nich odkloniť, ale to býva väčšinou už v zadaní. (Napríklad keď som kvôli performance na embedded zariadeniach musel programovať javu c-čkovým štýlom, bol to grc, ale všetci rozumeli, že prečo.)
Nie je nutné rozhodovať, čo je horšie/lepšie, keď unifikovaný štýl existuje.

[Jiří Havel]

Pokud to jazyk podporuje, tak se k tomuto účelu použije spíš reflexe + případně anotace, kterými se dá upravit specifické chování a mapování.

Serializace reflexí má své mouchy. A jak je ten serializátor psaný někým jiným, jsou z toho pěkně vypasené masařky.

1) Navrhujete vnitřnosti podle toho, co umí serializátor.
Když máte štěstí dostanete třeba nekonečno a nan. Na denormály ani nemyslete. A na inty větší než 48b bych taky raději slepě nespoléhal.
Pokud serializátor není součást jazyka, tak určitě nedostanete všechny standardní knihovny.

2) Přijdete o zapouzdření, takže si zabetonujete vnitřnosti.
Jak jednou objekt serializujete, tak už takřka nemůžete překopat vnitřní reprezentaci. Nějaká aktualizace pak obvykle něco rozbije.

Ve výsledku pak občas máte vnitřnosti objektů dvakrát. Jednou pro sebe, jednou pro serializátor a přesypáváte je tam a zpět.

[Reklama]

[echo_zulu]

Jak jednou objekt serializujete, tak už takřka nemůžete překopat vnitřní reprezentaci. Nějaká aktualizace pak obvykle něco rozbije.

Iba doplním, že serializačné knižnice umožňujú s dátami ukladať aj ich verziu, ktorá sa pri deserializácii používa na rozhodovanie, čo sa vlastne na vstupe očakáva, takže sa nenačítava niečo, čo na vstupe pre danú verziu nie je.

[Radek Miček]

Jak jednou objekt serializujete, tak už takřka nemůžete překopat vnitřní reprezentaci. Nějaká aktualizace pak obvykle něco rozbije.

Iba doplním, že serializačné knižnice umožňujú s dátami ukladať aj ich verziu, ktorá sa pri deserializácii používa na rozhodovanie, čo sa vlastne na vstupe očakáva, takže sa nenačítava niečo, čo na vstupe pre danú verziu nie je.

Program se ale asi stejně rozbije, protože bude sice vědět, že se jedná o jinou verzi, ale nebude vědět, co s ní dělat.

[echo_zulu]

Jak jednou objekt serializujete, tak už takřka nemůžete překopat vnitřní reprezentaci. Nějaká aktualizace pak obvykle něco rozbije.

Iba doplním, že serializačné knižnice umožňujú s dátami ukladať aj ich verziu, ktorá sa pri deserializácii používa na rozhodovanie, čo sa vlastne na vstupe očakáva, takže sa nenačítava niečo, čo na vstupe pre danú verziu nie je.

Program se ale asi stejně rozbije, protože bude sice vědět, že se jedná o jinou verzi, ale nebude vědět, co s ní dělat.

Program zostavený s podporou verzie 3 bude vedieť, čo robiť pri načítavaní dát serializovaných verziou 2, pretože pri písaní deserializačnej funkcie ošetríte zmeny, ktoré nastali prechodom na novú verziu.

Pokiaľ vaše zmeny boli nad rámec toho, že bolo niečo pridané alebo vymazané, dá sa to riešiť viacerými krokmi s dátovými objektami a ich ďalším spracovaním.

Zároveň je nutné zamyslieť sa na tým, kde sa končí (de)serializácia a kde už začína konverzia dát.

Riešil som celkom divoké veci vrátane veľkých zmien typov a dá sa to.

Pri zachovaní určitej disciplíny sa dá riešiť aj to, že program zostavený s podporou verzie 3 načíta zo súboru uloženého verziou 4 aspoň spoločné dáta. Ktorých môže byť aj 99%. Dokonca aj to, že pri novom uložení, dáta, ktoré verzia 3 nepozná, zachová a verzia 4 ich potom načíta ako keby sa nič nestalo. Je samozrejmé, že to chce dobrý návrh a zmeny pre takéto použitie musia mať zmysel.

[BoneFlute]

Nebudu ho učit serializovat se do Jsonu, nebo do Databáze, ale obecný serializování musí umět on.

Ale i obecných serializačních formátů existuje mnoho. Jeden například povolí 64-bitová celá čísla a druhý povolí celá čísla bez omezení velikosti. Jiný povolí čas na mikrosekundy, další na pikosekundy. Některé mohou řešit, jak jsou data uložena v paměti, jiné se od toho snaží abstrahovat.

Bavíme v kontextu OOP.
Serializační formát je jen jeden, ten dict, což bude nějaký slovník.
A starostí toho objektu právě je, že když používá například čísla s nekonečnou délkou, tak je napasovat do toho interface. O tom byl právě ten příklad.

Pak je další vrstva, že chci serializovat do jsonu. Která umožní přidávat další věci.

Pokud to jazyk podporuje, tak se k tomuto účelu použije spíš reflexe + případně anotace, kterými se dá upravit specifické chování a mapování.

Což je jen buildin implementace serializace. Ale o to nejde.

Připomínám, že původně jsem reagoval na:

Chci vůbec mít member funkce?

Serializace byl příklad.

[BoneFlute]

Jak jednou objekt serializujete, tak už takřka nemůžete překopat vnitřní reprezentaci. Nějaká aktualizace pak obvykle něco rozbije.

Iba doplním, že serializačné knižnice umožňujú s dátami ukladať aj ich verziu, ktorá sa pri deserializácii používa na rozhodovanie, čo sa vlastne na vstupe očakáva, takže sa nenačítava niečo, čo na vstupe pre danú verziu nie je.

Program se ale asi stejně rozbije, protože bude sice vědět, že se jedná o jinou verzi, ale nebude vědět, co s ní dělat.

Není nutný předpoklad, že program neví, co s jinou verzí.

Tohle jsem řešil už několikrát (api, update aplikace). Je to zábavná úloha.

Třeba v API je to sice komplexní ale omezená množina operací. Přidání prvku, odebrání prvku, změna prvku, Přidání typu dat, odebrání typu dat, změna typu dat. A ještě další v podobném duchu.

Některé operace se pro jednoduchost zamítnou.
Některé jsou triviální.
Některé vyžadují trochu péče.

Fungovalo nám to pěkně, myslím, že přes tři až pět verzí.

[BoneFlute]

Celkem jsem to musel čtyřikrát přepisovat prakticky od nuly, neboť jsem narazil na okamžik, kdy už jsem se v kódu sám nevyznal. Četl jsem, že dobrou věcí v programování je určit si nějaký svůj "styl" a toho se pak držet.

Programování už není zábava pro nerdy. Dneska je to business. Takže:
- kolik bude stát programátora číst existující kód?
- kolik bude stát kód napsat?
- kolik bude stát přidání nové funkcionality?
- cenu snižuje znovupoužitelnost
- kdy a kde nastanou chyby a kolik nás to bude stát?

Proto se vymýšlí nové jazyky, jinak by nám ten Assembler bohatě stačil.

Co vývojář, to originální osobnost. Co zadání + vývojář, to originální výsledek zpracování toho zadání. Nikdy jsem nepracoval ve vývojářském týmu. A dotaz zní: Máte také podobnou zkušenost s originalitou každého vývojáře? Mohu veřejně říci, že zpracování zadání (vývoj, programování atd.) je velice osobní záležitost?

Ano, a je to špatné. Protože to jde proti výše uvedenému.

Třeba mě se stalo, že jsem předělal nějakou část kódu a pak jsem se zamyslel nad tím, kolik práce s adopcí těch změn bude mít kolega. A nakonec jsem to zahodil jako neefektivní. Přínos mých změn byl menší jak nutnost kolegu přimět ho adoptovat.

[Radek Miček]

Nebudu ho učit serializovat se do Jsonu, nebo do Databáze, ale obecný serializování musí umět on.

Ale i obecných serializačních formátů existuje mnoho. Jeden například povolí 64-bitová celá čísla a druhý povolí celá čísla bez omezení velikosti. Jiný povolí čas na mikrosekundy, další na pikosekundy. Některé mohou řešit, jak jsou data uložena v paměti, jiné se od toho snaží abstrahovat.

Bavíme v kontextu OOP.
Serializační formát je jen jeden, ten dict, což bude nějaký slovník.
A starostí toho objektu právě je, že když používá například čísla s nekonečnou délkou, tak je napasovat do toho interface. O tom byl právě ten příklad.

Pak je další vrstva, že chci serializovat do jsonu. Která umožní přidávat další věci.

To mi nepřijde jako dobrý návrh - protože to, co už ztratíte tím dictem, se bude dost těžko rekonstruovat v další vrstvě. Proč prostě nemít jen jednu vrstvu. Bude to určitě srozumitelnější a rychlejší.

[BoneFlute]

Nebudu ho učit serializovat se do Jsonu, nebo do Databáze, ale obecný serializování musí umět on.

Ale i obecných serializačních formátů existuje mnoho. Jeden například povolí 64-bitová celá čísla a druhý povolí celá čísla bez omezení velikosti. Jiný povolí čas na mikrosekundy, další na pikosekundy. Některé mohou řešit, jak jsou data uložena v paměti, jiné se od toho snaží abstrahovat.

Bavíme v kontextu OOP.
Serializační formát je jen jeden, ten dict, což bude nějaký slovník.
A starostí toho objektu právě je, že když používá například čísla s nekonečnou délkou, tak je napasovat do toho interface. O tom byl právě ten příklad.

Pak je další vrstva, že chci serializovat do jsonu. Která umožní přidávat další věci.

To mi nepřijde jako dobrý návrh - protože to, co už ztratíte tím dictem, se bude dost těžko rekonstruovat v další vrstvě. Proč prostě nemít jen jednu vrstvu. Bude to určitě srozumitelnější a rychlejší.

Ten příspěvek byl jako vysvětlení kdy udělat metodu a kdy ne. Ale budiž.

Srozumitelnější a rychlejší bezpochyby ano.

Nevýhoda je neflexibilita.

Ale vysvětli mi, proč bych měl tím dictem něco ztrácet? Nevidím proto jediný důvod...
A o jaké rekonstrukci to mluvíš? Přeci v rámci rozdělení zodpovědnosti já v té druhé vrstvě nic rekonstruovat nebudu. Prostě převedu co mám na to co mám. Dostal jsem dict, převedu ho na json, a json převedu na dict.

[Franta Kučera]

Pokud to jazyk podporuje, tak se k tomuto účelu použije spíš reflexe + případně anotace, kterými se dá upravit specifické chování a mapování.

Serializace reflexí má své mouchy. A jak je ten serializátor psaný někým jiným, jsou z toho pěkně vypasené masařky.

1) Navrhujete vnitřnosti podle toho, co umí serializátor.
Když máte štěstí dostanete třeba nekonečno a nan. Na denormály ani nemyslete. A na inty větší než 48b bych taky raději slepě nespoléhal.
Pokud serializátor není součást jazyka, tak určitě nedostanete všechny standardní knihovny.

2) Přijdete o zapouzdření, takže si zabetonujete vnitřnosti.
Jak jednou objekt serializujete, tak už takřka nemůžete překopat vnitřní reprezentaci. Nějaká aktualizace pak obvykle něco rozbije.

Ve výsledku pak občas máte vnitřnosti objektů dvakrát. Jednou pro sebe, jednou pro serializátor a přesypáváte je tam a zpět.

Tak přesně tohle je ten případ, kdy by mne zajímalo, na základě jakých zkušeností a projektů se takový komentář a názor vznikl. Nikdo z mých zákazníků bohužel (bohudík?) nechce platit za ruční implementaci de/serializátoru a za to, že se o ten nadbytečný kód budou další generace programátorů starat. Ale možná je to někde běžná praxe - právě proto bych rád věděl kde a jaké k tomu vedou důvody.

Moje zkušenost vychází hlavně z bankovních projektů. Tam serializujeme objekty do XML, JSONu případně do Avro nebo nějakých specialit typu ISO 8583. Nebo jsem dělal projekty v oboru telekomunikací a tam to bylo trochu pestřejší, formáty byly často binární, bylo tam hodně ASN.1, Radius, Diameter, SMPP atd. A prakticky vždy je snaha tuhle práci automatizovat a minimalizovat množství kódu, který se musí napsat. Takže buď se do tříd dopíší anotace nebo, lépe, se vychází ze specifikace (XSD, WSDL, Swagger/OpenAPI, Avro schéma, definice ASN.1 modulů, slovníky atd.) a z ní se generují třídy nebo něco jiného. V obou případech ale tu práci za nás dělá nějaká knihovna. Ručně jsem to řešil jen párkrát u hodně malých projektů, kde toho ručně psaného kódu bylo tak málo, že převládl užitek ze snížení komplexity závislostí.

Napadají mne ještě takové věci jako multimediální kodeky nebo implementace síťových protokolů v operačním systému nebo nějaké firmwary… ale tam se spíš než vyrábění stromů objektů ta data namapují přímo, aby se nemusela vůbec kopírovat, maximálně se narovná endianita číselných typů, ale jinak data leží pořád na stejném místě v paměti, a buď se na ně 1:1 napasuje nějaká céčkovská struktura, nebo se vyrobí ukazatele, které ukazují na části dat na tom původním místě nebo se to zpracovává proudově a parser generuje události / volá funkce a ty se průběžně odbavují.

[Franta Kučera]

Ale vysvětli mi, proč bych měl tím dictem něco ztrácet? Nevidím proto jediný důvod...

Tohle už jsem komentoval někde výše. Když už se to tedy bude řešit takhle ručně (osobně bych spíš použil spíš tu reflexi a anotace nebo kód generovaný ze specifikace), tak bych tam nechal normální datové typy toho programovacího jazyka – a jejich mapování na datové typy formátu, ať si řeší ta serializační knihovna (specifika se dají upravit konfigurací, ale nevidím důvod, proč by někdo měl být nucen to ručně programovat).