Příspěvky

1

Vývoj / Re:Přechod z Javy na Rust. Ano či ne?

« kdy: 08. 10. 2025, 03:32:32 »

Dokázal byste si představit, že by se v něm dal naprogramovat engine 2,5D počítačové hry třídy AAA?

https://fyrox.rs/
https://bevy.org

2

Vývoj / Re:Přechod z Javy na Rust. Ano či ne?

« kdy: 02. 10. 2025, 23:34:03 »

Nedávno jsem tady do nějaké diskuse napsal, že generování XML je někdy lepší si napsat sám, ručně, bez knihoven a hned se seběhli místní trollové, co že si to dovoluji si takovou věc psát sám… Přitom to generování XML je výrazně jednodušší než parsování (byť si nepíšeš vlastní parser asi zpracováváš SAX události nebo pracuješ nad DOMem nebo něco podobného). (jen dodávám, že cílem toho mého generátoru nebylo generování libovolného XML, ale určité podmnožiny, která je pro moje potřeby dostačující – důležité je, aby výstup bylo validní XML)

Ty výhrady k tomu generovanému kódu částečně chápu. Sám jsem s tím bojoval u Swaggeru resp. OpenAPI, kde generátor nebyl dost zralý, některé věci to nepodporovalo vůbec nebo to generovalo nesmysly… to bylo dost peklo. Něco vyřešili autoři generátoru v novějších verzích, něco jsme vyřešili sami vlastními šablonami. Ale i tak si myslím, že je většinou lepší si jednou odladit šablony/generátor než to psát pokaždé ručně. A JAXB je oproti tomu mnohem zralejší a spolehlivější technologie (byť to zemětřesení, které přišlo po Javě 8, s tím nepěkně zamávalo).

Nevím, proč by zrovna generování xmlka nemělo jít lepením stringů. Do určtié velikosti projektu je to naprosto good enough.

Jedna ze zkušeností, co mne v tomhle ovlivnila, byla, když  jsem  kdysi  pozoroval  lidi, kteří seděli asi dva metry od sebe, jeden psal server v Javě, druhý psal klienta v JavaScriptu a neustále řešili, že ten druhý posílá  atribut  s „jiným  názvem“ nebo  „starým  způsobem“…  v každé  verzi  byly  chyby tohoto typu a pořád se na to plýtval čas a vyvolávalo to hádky. Mezi sebou si sdíleli dokument ve  Wordu,  ve kterém  měli příklady, jak se má služba volat… Takže když mi dneska někdo tvrdí, jak nepotřebuje schéma, a že je to prý jednoduché a že stačí napsat pár příkladů a všem to bude jasné… tak se mi otevírá pomyslná kudla v kapse, protože vím, jak to dopadá. Přitom tohle se v oboru řeší od pradávna a obecně  se  to  jmenuje IDL  (interface  description language). Konkrétních implementací je spousta, ale podstatná je ta myšlenka, že máš nějakou strojově  čitelnou  specifikaci,  která definuje ten kontrakt, a ze které obě strany vycházejí.

Ale každopádně, pokud si píšeš parser ručně ale máš tu specifikaci a ne jen pár příkladů, tak je to ještě ten lepší případ.

To jsme takhle s kamarádem dělali jeden projekt. Měl jsem nápad, a on si z toho udělal bakalářku. To jsem si zavařil. Rozvíjel jsem ten nápad, a on mě furt otravoval, jestlu už to bude hotové, a já mu furt měl tendenci měnit specifikaci, protože to jinak nešlo.

3

Vývoj / Re:Přechod z Javy na Rust. Ano či ne?

« kdy: 02. 10. 2025, 23:02:06 »

Já ti nerozumím. V čem, že je ten problém?

Problém je v tom, že to nemusí být stromová struktura, ale může to být obecný graf a na jeden objekt může vést reference z víc míst. Pokud to řešíš přes reflexi, tak tam tu informaci o tom, že jde o stejný objekt, akorát je na něj odkazováno z víc míst, máš zachovanou. Ale když to přesypeš do mapy map, tak se tam ta informace ztratí (nebo si minimálně přiděláš dost práce s tím, abys ji tam zachoval).

Ne, to teda není.

Ten problém s obecným grafem je obecný problém ať to budeš řešit explicitním řešením nebo reflexí.

Problém vidím v tom, a tady si trochu zaAdHominuju, že Radek Míček hodně prožívá optimalizaci, a nedokáže se od toho oprostit :-)

To ovšem není chyba reflexe ale logická chyba v návrhu.

No, chyba byla v tom, že se použila reflexe s představou, že to přece bude fungovat.

Připravit se kvůli tomu o reflexi mi přijde škoda.

Já nemám nic proti reflexi. Alespoň ne principielně. Jen se zřejmě pohybuju v doméně, kdy vždy narážím na její mantinely. V doméně, kde jde o bezpečnost a zároveň se všechno vyvíjí, tak reflexe jde trochu do pozadí.

Navíc často ten dict může obsahovat jen omezenou množinu typů, takže třeba neomezeně dlouhé číslo do něj nejde uložit přímo jako číslo, ale jako řetězec a pak se bokem serializátoru do JSONu musí říct, ať to uloží jako číslo, ne jako řetězec (i když to tak je v tom slovníku).

No a? To je správně.

A není jednodušší to číslo nechat třeba jako BigInteger a naučit ten generátor, jak mapovat BigInteger na datové typy daného formátu? K čemu je dobré to převádět na String a pak si někde bokem předávat informaci, že tohle vlastně není String ale číslo?

Dobře. Takže já mám systém, který poskytuje a zpracovává data. Mám N klientů, kteří používají mou knihovnu. Já jim posílám nové objekty, oni vytvářejí nové objekty. Potřebuju, aby tam byla nějaká pružnost, takže představa: teď se všechno zastaví a den to nepoběží dokavad nezaktualizujeme všechno - tak úplně nepremáva.
Tak v takovém kontextu by to IMHO opravdu nebylo jednodušší.

Jasně, když zjistím, že můj původní předpoklad, že tam dám dict, a mělo by to pokrývat všechno začne být úzkým hrdlem, a že bych tam strašně nutně potřeboval přidat vlastnost A, tak budu přemýšlet, jak to celé šikovně zaktualizovat. Možná udělám verzi 2, nebo něco takového.

Jasně, pokud to bude nějaký kolotoř několika objektů uvnitř systému, který mám pod kontrolou, tak budu uvažovat jinak a na nějaké serializace se vyprdnu.

4

Vývoj / Re:Přechod z Javy na Rust. Ano či ne?

« kdy: 02. 10. 2025, 21:03:54 »

Už se mi několikrát vyplatilo si ten parser psát ručně (vlastně už to ani jinak nedělám - napsal jsem si na to knihovnu se kterou se to dělá snadno). Prvotním důvodem bylo, že XSD generátory generovaly typy, co se těžko používají (tehdy jsme měli Kotlin a používali data classy a XSD generátor uměl jen tradiční Java classy s gettery a settery bez null anotací). Takže bylo vlastně míň práce parsovat XML ručně, navíc jsme díky tomu objevili, že z té služby chodí i data mimo specifikaci.

Já na jednu stranu mám rád používání různých těch automatický generátorů, ale je fakt, že ve výsledku je to kolikrát úplně stejné množství popisného kódu, protože různé výjimky a hacky. Pro mě je to sympatické, že je to alespoň deklarativní. A třeba naopak, nad XSLT jsem zlomil hůl. Je snazší a čitelnější to parsovat a serializovat v Rustu.

5

Vývoj / Re:Přechod z Javy na Rust. Ano či ne?

« kdy: 02. 10. 2025, 20:59:11 »

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

Protože ne všechny formáty jsou jako dict. Některé serializační formáty např. nemají názvy polí, nebo mohou vzít kus paměti, kde je struktura (s definovaným layoutem) a nic dalšího s ním nedělat. Nebo dokoknce větší blok paměti, kde je více struktur, které na sebe odkazují (třeba pomocí relativních offsetů).

Já ti nerozumím. V čem, že je ten problém?

Navíc často ten dict může obsahovat jen omezenou množinu typů, takže třeba neomezeně dlouhé číslo do něj nejde uložit přímo jako číslo, ale jako řetězec a pak se bokem serializátoru do JSONu musí říct, ať to uloží jako číslo, ne jako řetězec (i když to tak je v tom slovníku).

No a? To je správně.

6

Vývoj / Re:Přechod z Javy na Rust. Ano či ne?

« kdy: 02. 10. 2025, 20:52:05 »

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).

Proč už nikdy nepoužiju reflexi na serializaci: To takhle jeden kolega v kódu, který jsem přebral použil reflexy nad Enum, což ve výsledku znamenalo, že pro každou hodnotu Enumu do dalo jeden int. Hezké, krásně se to namapovalo do databáze. Pak někdo přidal nový záznam do Enumu. A první odstranil, protože ten se už neměl nikdy použít. A najednou si klienti stěžovali, že se nám mrší data.

Druhá věc je ta, že pointa není zda ten serializační systém psát ručně, generovat podle wsdl, nebo jakkoliv jinak. Pointa je v tom, že já vytvořím interface, a pak mohu s maximální jistotou de/serializovat předenm neznámý objekty, stačí, když splní kontrakt.

Řeč byla o OOP.

Samozřejmě, že v praxi se hřeší. Protože výkon. Protože neznalost. Protože lennost. Protože cena.

Automatická serializace pomocí reflexe je snadná, rychlá a křehká.

Serializace podle kontraktu je bezpečná, rozložitelná do týmu, flexibilní.

Serializace objektu přímo do cílového stavu je pracná, výkonná, neflexibilní, nevhodná pro knihovní kód.

7

Vývoj / Re:Přechod z Javy na Rust. Ano či ne?

« kdy: 02. 10. 2025, 18:15:42 »

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.

8

Vývoj / Re:Přechod z Javy na Rust. Ano či ne?

« kdy: 02. 10. 2025, 17:50:54 »

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.

9

Vývoj / Re:Přechod z Javy na Rust. Ano či ne?

« kdy: 02. 10. 2025, 17:40:51 »

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í.

10

Vývoj / Re:Přechod z Javy na Rust. Ano či ne?

« kdy: 02. 10. 2025, 17:15:24 »

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.

11

Vývoj / Re:Přechod z Javy na Rust. Ano či ne?

« kdy: 02. 10. 2025, 02:01:43 »

Já jen použil příklad co tu byl, kdybych měl vytvořit vlastní tak by zněl takto:

```
struct Point {
  double x, y;
};
```

Chci vůbec mít member funkce? Já třeba preferuju `distance(p1, p2)` než `p1.distance(p2)`. To samé když vidím třeba `a.dot(b)`, atd... přijde mi to až přehnané API navrhovat takto.

A naopak. Mám-li nějaký systém, který se například stará o persistenci objektů, tak mohu chtít, aby ten objekt byl persistovatelnej. Dám tomu nějaký

Kód: [Vybrat]

interface Persistable {
    fn serialize() -> dict
    fn unserialize(dict) -> self
}
a zde je to skutečně starostí toho objektu.

(sorry, lepší příklad mě nenapadl)

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

12

Vývoj / Re:Přechod z Javy na Rust. Ano či ne?

« kdy: 02. 10. 2025, 01:47:32 »

Já jen použil příklad co tu byl, kdybych měl vytvořit vlastní tak by zněl takto:

```
struct Point {
  double x, y;
};
```

Chci vůbec mít member funkce? Já třeba preferuju `distance(p1, p2)` než `p1.distance(p2)`. To samé když vidím třeba `a.dot(b)`, atd... přijde mi to až přehnané API navrhovat takto.

Objekt je o tom, že schovává vnitřní stav a nějakou svou logiku. Distance mezi dvěma body není stav ani logika toho bodu, IMHO.

Ještě lépe to vynikne, ale to už tu někdo zmiňoval, když začneš řešit více variant distance. Například s tolerancí. A pak to musíš nějak přidat do toho objektu.

13

Vývoj / Re:Přechod z Javy na Rust. Ano či ne?

« kdy: 30. 09. 2025, 20:22:43 »

Trochu se omlouvám za to rýpnutí do funkcionální víry ale nedalo mi to :-)

Nejde o víru, ale o paradigma. Skrz co interpretujete svět a jaké základní kameny používáte při stavbě toho modelu.

OOP velmi dobře modeluje svět jak ho známe. Když se odprostíme od nějaké metafyziky úrovně kvarků a spol, tak objekt si skutečně uchovává svůj vztah. Když lékař testuje pacienta a jeho organizmus, tak skutečně ta informace je uvnitř, a pěkně schovaná pod kůží, etc, etc.

Problém OOP je v tom, že se to strašně špatně používá v praxi. FP je paradigma, které je trochu atypické, trochu na hlavu (pro někoho), jenže jeho výhoda je v tom, že se mnohem lépe používá. Programátor kód, který je napsaný FP způsobem má kód mnohem více pod kontrolou etc, etc. Za svou kariéru, když jsem řešil problém OOP způsobem, tak jsem se někdy dostal do situace, že to bylo dost nepřirozený, nebo komplikovaný. A velmi často strašně nečitený.

V případě FP se mi to nestává.

Čistá prax, nic víc.

14

Vývoj / Re:Přechod z Javy na Rust. Ano či ne?

« kdy: 30. 09. 2025, 20:13:13 »

jsou takové snahy najít svatý grál, ...
Takže když čtu podobné náboženské texty jako ten odkazovaný, už se musím jen usmívat.

A já ho našel a musím se usmívat vám. Nevím, jak jsme si pomohli 

15

Vývoj / Re:Přechod z Javy na Rust. Ano či ne?

« kdy: 30. 09. 2025, 00:09:05 »

2/ většina jazyků lepší nástroj pro reusable kódu jak dědičnost nemá (Java), některé nemají dokonce ani rozhraní (C++) (Překvapivě takový odsuzovaný jazyk jako je PHP ano.)

Dovolím si polemizovať, java má aj lambdy a to je ďalšia možnosť prepoužitelnosti kódu. Potom sú rozhrania s default implementáciami metód, čo sú vlastne traits na javovský spôsob.

Já ti nevím. Lambdy jsou IMHO na něco jiného, a default implemetace metod tak nějak neřeší, že v jedné skupině adaptérů chci tuto implementaci a v druhé skupině jinou. Nemluvě o tom, že je to stále dědění. To je stejně blbě, jak se o tom bavíme.