Zobrazit příspěvky

Tato sekce Vám umožňuje zobrazit všechny příspěvky tohoto uživatele. Prosím uvědomte si, že můžete vidět příspěvky pouze z oblastí Vám přístupných.


Příspěvky - Jiří Havel

Stran: [1] 2 3 ... 30
1
Vývoj / Re:Styly programování
« kdy: Dnes v 00:17:44 »
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?
Pro json máte schéma k dispozici taky. Ano, není zabudované přímo v tom souboru. Jenže když používáte xml tak schéma, které vaše aplikace bude používat, taky domlouváte bokem. Sice můžete validovat vůči schématu, které je v tom souboru, ale stejně tak musíte validovat vůči schématu podle kterého je psaná vaše appka. A při odesílání taky nevalidujete vůči schématu v tom odesílaném souboru ale vůči tomu, co očekává druhá strana.

2
Vývoj / Re:Styly programování
« kdy: 05. 09. 2026, 23:39:10 »
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.
Bacha, některé věci z profileru nevylezou. Nebo nejsou na první pohled patrné. Největší přínos dají vhodné datové struktury (a nejsou to ty, co by začátečník čekal).
Jak výkon železa roste, pozoruju několik věcí :
- Je stále těžší ho naplno vytížit (třeba relativní cena cache-missu nebo mispredikce větvení stále roste)
- Asymptotická složitost stále víc mate (třeba O(N) hledání v obyčejném poli je rychlé jako prase)

3
Vývoj / Re:Styly programování
« kdy: 05. 09. 2026, 00:41:05 »
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í.

4
Vývoj / Re:Programovací jazyk BASIX
« kdy: 31. 08. 2026, 13:15:58 »
Místo GC jsem měl napsat uvolnění objektu z paměti, které se neděje bezprostředně po jeho zneplatnění.
Ne neměl. Ještě že jste napsal GC. Takhle víme, že je to omyl. Že mluvíte o nějakém jazyce s GC a ne o C++.
Kdybyste dál psal o zneplatnění objektu, tak se tu točíme v kruhu. Protože v kontextu C++ to moc nedává smysl a zároveň je to příliš obecné.

5
Vývoj / Re:Programovací jazyk BASIX
« kdy: 31. 08. 2026, 00:32:38 »
Jestli je v C++ nějaká featura, která maskuje že se něco děje, tak jsou to destruktory. Ale na druhou stranu, nečekané divočiny může dělat i nějaká "kill" funkce v C.

Destruktory v C++ jsou děs. Místo spuštění už při zneplatnění objektu se spustí až při jeho fyzické likvidaci.
Úplně nerozumím. Co přesně je to zneplatnění objektu? Šlo by dát nějaký příklad?

V destruktoru uvedu uvolnění nějakého prostředku (paměti, souboru, spojení,...). Na objekt už neexistuje pointer, ale stále si ten prostředek drží a může to způsobit deadlock. Destruktor je spuštěn až aktivací garbage collectoru, a to je pozdě. Jiné jazyky tím netrpí.

C++ a garbage collector? Teda, ne, že by se nepoužívali, ale je to trochu nonsens.

Tak kdy se v C++ spouští destruktor?
V C++ jsem se s GC teda ještě nepotkal, jen jsem slyšel nějaké zvěsti. Takže můj dotaz tak nějak trvá.

Destruktor se spouští, když končí život objektu :
- u lokálních proměnných na konci scopu
- membery struktury se likvidují při likvidaci samotné struktury
- u dynamicky alokovaných objektů se destruktor volá při uvolňování toho objektu (v novém idiomatickém c++ když zanikne unique_ptr, nebo poslední shared_ptr co na ně ukazuje)
- V c++ když na objekt zanikne poslední ukazatel a on je pořád naživu, tak už leakne navždycky(není GC, není kdo by to taky uvolnil). Ale při použití smartpointerů už toho není až tak jednoduché dosáhnout.

6
Vývoj / Re:Programovací jazyk BASIX
« kdy: 30. 08. 2026, 23:25:15 »
Jestli je v C++ nějaká featura, která maskuje že se něco děje, tak jsou to destruktory. Ale na druhou stranu, nečekané divočiny může dělat i nějaká "kill" funkce v C.

Destruktory v C++ jsou děs. Místo spuštění už při zneplatnění objektu se spustí až při jeho fyzické likvidaci.
Úplně nerozumím. Co přesně je to zneplatnění objektu? Šlo by dát nějaký příklad?

7
Vývoj / Re:Programovací jazyk BASIX
« kdy: 30. 08. 2026, 23:12:28 »
Tak já jsem slyšel verzi, že to bylo kvůli nepředvídatelnosti. A že jinak jádro není čisté C, je to subset C++, že šikovným featurám se nebrání, ale musí být vidět co se děje. Což vtable tak nějak nesplňuje (o STL nemluvě).
Tak zrovna linux má ručně psané vtable, které fungují skoro stejně jako ty v C++. Akorát je tam přímo to volání skrz pointer na funkci, takže je vidět rozdíl mezi virtuálním a nevirtuálním callem. Jinak je to ale stejná neprůhledná bariéra jak pro člověka, tak pro překladač.

BTW, samotné volání funkcí dokáže "co se děje" skrýt velmi dobře. A ještě lepší na to jsou v C makra.
Jestli je v C++ nějaká featura, která maskuje že se něco děje, tak jsou to destruktory. Ale na druhou stranu, nečekané divočiny může dělat i nějaká "kill" funkce v C.

8
Vývoj / Re:Styly programování
« kdy: 29. 08. 2026, 13:21:19 »
Osobně to nikomu neberu, ale kde je ta hranice? Za chvíli někdo může psát testy jestli se compiler chová tak jak se chovat má...
A co třeba testovat, jestli se compiler chová tak, jak čekám? V některých jazycích má až překvapivou volnost (třeba C). Tam může update překladače udělat zajímavé věci. Ono třeba stačí aby se trochu změnila ochota inlinovat a nějaká kritická část kódu může být násobně pomalejší.

A překladačových bugů jsem už taky pár potkal. Ale tohle jsou věci tak nepředvídatelné, že tu preventivní test nepomůže.

9
Vývoj / Re:Programovací jazyk BASIX
« kdy: 26. 08. 2026, 16:59:48 »
Nemyslím si, že jde o úmyslné trolení. Už jsem se s tím setkal kdysi na fakultě, kde nás tenkrát přes mail nějaký exot neustále bombardoval svými převratnými teoriemi a vynálezy a chtěl, abychom to nějak zkoukli a posoudili a neustále to s námi chtěl konzultovat. Tenkrát šlo o fyziku, přičemž znalosti toho člověka byly tak něco mezi základní a střední školou se značnými mezerami. Kamarád z právnické fakulty mi vyprávěl o něčem podobném - tam je zase podobná existence spamovala s návrhem nové ústavy, aniž by měla tušení, jak se takové věci píšou, co tam patří a co ne atd. Tohle je evidentně podobný případ. Psychologové pro to jistě mají nějaké pojmenování.

Na to jsou ty LLMka skvělá. Já mám nějaký debilní nápad, nejlépe z domény, které fakt nerozumím, a než abych bral čas a energii živému člověku, tak to proberu s nějakým chatem, a když nic jiného je to zábava. V lepším případě se posunu a dostuduji si.
Akorát že v praxi to funguje naopak.
Blbec dostane nápad. Prožene ho llmkem, které mu naslopí megatunu balastu. Pak to raději ani nepřečte (krásný příklad tu je), asi aby nebral čas a energii jedinému živému člověku na kterém mu záleží. A pak ten výsledek vrhne na další lidi bez ohledu na to, kolik člověkohodin tím v součtu promrhá.

10
Vývoj / Re:Programovací jazyk BASIX
« kdy: 26. 08. 2026, 11:32:55 »
Spíš nám řekni, proč by si někdo měl tolik řádků číst, co mu to přinese, jaký je use-case, nebo k čemu je to dobré a proč by tím vůbec měl někdo pálit čas..

Jako je jasný, že když jsi něco "udělal", tak k tomu máš nějakej bližší vztah.. Já si ale jako nestranný pozorovatel pokládám otázku.. Proč bych to měl vůbec číst, když nedokážeš ani stručně vysvětlit, k čemu je to dobré a co to má řešit? :-)

Pokud tě téma nezajímá, proč ho čteš a proč na něj reaguješ? Novomente klade sice neobvyklé, ale zcela legitimní otázky. Prostě téma ignoruj a buď happy.
No ale jak má vědět, jestli ho to zajímá nebo ne?
Novomente sem hodil obrovský dokument s neznámým obsahem a ani se během slopení neobtěžoval nechat si vygenerovat souhrn. A zrovna tohle AIčka umí a měl by to bez práce.

Možná jsou to legitimní a neobvyklé dotazy. Ale nepřijde mi, že by nad nimi sám nějak moc přemýšlel.

11
Vývoj / Re:Styly programování
« kdy: 25. 08. 2026, 11:26:59 »
Právě klasické unit testy funkčnost v rámci workflow naopak ztratily.
Větší blbost jsem hodně dlouho nečetl.

Je to nestastne receno, ale s timhle vice mene souhlasim...
ztratili cast sve hodnoty pro cloveka... (tu sebereflexivni.. jak dobre se pouziva to API ktere jsem navrhl?)
Daleko vice ziskavaji E2E testy.. byly vzdycky drahe na udrzbu, ale ted kdyz to stoji vicemene nic tak se vyplati.

Unit testy pise AI a ja je nectu.. jestli jsou pro ni uzitecny tak at je pise.. ale pro me jsou dulezity vystupu e2e(business scenario testu) a NFR testu
Tady bacha. Hranice mezi různými druhy testů není moc standardizovaná.

12
Vývoj / Re:Styly programování
« kdy: 25. 08. 2026, 11:11:13 »
Jak jinak než testy ověřím funkčnost programu, pokud nechci detailně zkoumat zdrojáky od AI?
Co asi tak testujou testy ktery ti napise stejny AIcko jako ten kod ...
Co asi tak testujou testy ktery ti napise stejny _člověk_ jako ten kod ...

Celkem dost, ne?

13
Vývoj / Re:Styly programování
« kdy: 24. 08. 2026, 11:12:54 »
Na best practices na většině projektů fakt není čas. Výsledkem je skoro vždy nějaký kompromis.

Jasny. to je jako rozepinat poklopec kdyz jdes na zachod... Kdo na to ma cas? Navic si jako bonus ani nemusis umejvat ruce kdyz odchazis.
Tenhle příměr kapku kulhá. Když už nic jiného, tak to nejsou tvoje kalhoty.

14
Vývoj / Re:Jak spolupracovat s AI
« kdy: 11. 08. 2026, 18:17:06 »
1) Žádná operace ani konverze v BASIXu nesmí vést k nedefinovanému chování (UB) jazyka C++, do kterého se program překládá. Kdekoliv by ekvivalentní C++ konstrukce UB měla, BASIX pro ni definuje vlastní, deterministické chování — typicky saturací.
Na nedefinovaném chování v C(++) není špatně to, že ta operace nevrací nějakou normální hodnotu, ale že je ten stav nedovolený a ne chybný. Nové C++ to svými "errorneous behavior" IMO posouvá správným směrem.

Vem si třeba přetečení. V drtivé většině případů nechceš ani saturaci ani wrap. Prostě s tím vůbec nepočítáš a každá z těch 2^N možných hodnot je blbě. Co chceš je povolit v nějakém testovacím buildu trap, aby se to dalo chytnout. Jak to přetečení dodefinuješ, tak donutíš překladač ti potichu vrátit nesmysl.

Jo, prostě při chybě neudělat nic je velmi lákavá myšlenka. ALE:
1) Jak velká blbost to je obvykle člověku dojde až když musí řešit následky.
2) Funkce co něco vrací vždycky něco dělá.

Takže doporučuju rychle napsat prototyp a zkusit ho používat. Ať víš, cos to navrhl.

15
/dev/null / Re:Nový systém pro vývoj softwaru
« kdy: 22. 07. 2026, 13:27:22 »
A příčina spočívá v materialismu vědy. Protože přisuzuje reálnost pouze matérii, shledává, že zkoumá vše, co na světě existuje a to vede k přesvědčení, že je kompetentní vyjadřovat ke všemu. Své omezení si ale neuvědomuje, byť tvrdí opak. Logicky pak není schopna dialogu s duchovně smýšlejícím, protože ten přináší pro vědu neakceptovatelné myšlenky. Zde věda porušuje svou vlastní vědeckou metodu. A opět - není si toho vědoma. Čest výjimkám.
A ta vědecká metoda se točí kolem experimentu.
Jakým způsobem navrhujete experimentovat na těch duchovních věcech?

Stran: [1] 2 3 ... 30