Příspěvky

1

Vývoj / Re:Rozdíl mezi ASM a strojovým kódem

« kdy: 16. 03. 2026, 17:14:05 »

Jako malý kluk jsem měl možnost pracovat na Commodore 64. Programoval jsem většinou v BASICu. Zkoušel jsem i monitor pro strojové instrukce, ale neboť jsem neměl žádnou literaturu k programování v assembleru, tak jsem v podstatě nic nenaprogramoval.

Před pár lety jsem v rámci mého soukromého studia tu literaturu našel a tak jsem si v assembleru naprogramoval jednoduchou hru. Samotné programování mi zabralo asi rok (včetně grafiky, hudby, a SFX). Čtyřikrát jsem to celé přepisoval, neboť jsem se ztrácel v kódu. Napočtvrté jsem už si stanovil vlastní styl, a tak se to nakonec na počtvrté podařilo.

Hra funguje, grafika, font, hudba a zvuky jsou vcelku vydařené. Ale nejvíce si vážím toho, že jsem ten svůj první a zároveň poslední velký program v ASM dotáhl do úplného konce. Bylo to a stále je to pro mě velkým přínosem. Jsem s tou prací spokojen a věřím, že ta zkušenost mi stála za ten rok programování. 

nm

Gratulace (jako vážně!)

2

/dev/null / Re:Nechali byste si do mozku implantovat čip?

« kdy: 09. 03. 2026, 13:29:01 »

Po přečtení sbírky povídek Axiomat (Greg Egan, IMHO jedny z nejlepších sbírek sci-fi a hororových povídek vůbec) bych do toho nikdy nešel. Důvody - žádné TL;DR; přečtěte si to, stojí to za to.

3

Vývoj / Re:Prečo nie je Lisp populárnejší?

« kdy: 04. 11. 2025, 16:05:10 »

Čistě náhodou chystám článek o Basilispu. To je vlastně Clojure pro Python a na to, že je to one man show, to funguje dost dobře. Stay tuned

4

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

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

Btw asi velmi dobré porovnání OOP s funkcionálním přístupem (identity, stavy) napsal Hick Hickey https://clojure.org/about/state

Minimálně za přečtení a zamyšlení to stojí. Možná to automaticky vyřeší ten problém s "lejstrem" vs "lejstrem se štemplem" - imho je to jen otázka správného pojmenování jednotlivých abstrakcí.

Takže když čtu podobné náboženské texty jako ten odkazovaný, už se musím jen usmívat.

Naprosto v pořádku, ať si každý programuje, jak uzná za vhodné, ostatně kdo já jsem, abych to rozhodoval (tedy kromě toho, jak to budeme dělat v mém týmu). Ale ta linkovaná stránka v žádném případě není náboženský text, ale dobré vysvětlení, jak se s identitami a stavy pracuje v Clojure, což je poměrně prakticky navržený jazyk, ovšem postavený na praktickém FP.

5

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

« kdy: 30. 09. 2025, 14:39:44 »

Btw asi velmi dobré porovnání OOP s funkcionálním přístupem (identity, stavy) napsal Hick Hickey https://clojure.org/about/state

Minimálně za přečtení a zamyšlení to stojí. Možná to automaticky vyřeší ten problém s "lejstrem" vs "lejstrem se štemplem" - imho je to jen otázka správného pojmenování jednotlivých abstrakcí.

6

Software / Re:Spojení animovaných gifů do jednoho obrázku

« kdy: 13. 09. 2025, 18:36:28 »

Dá se nainstalovat program gifsicle, ten umí expandovat animace na snímky a potom všechny snímky (z obou gifů) spojit do nového animovaného gifu. plus nějaké optimalizace, řízení rychlosti přepínání, looping atd.

7

Bazar / Re:Daruji starou základní desku 386SX

« kdy: 12. 09. 2025, 19:00:59 »

myslis Dangerous Dave 2 (to s tema zombikama)? To byla/je skvela hra.

Jop, Dave a hlavne ta prisera zo stropu, to na odreagovanie a Supaplex na potrapenie :-D

Ale chyba mi tu narek od Jenkings nad prepasnutou prilezitostou ziskat stary hw

Jmenovalo se to ale "Dangerous dave in the haunted mansion", nebo ono bylo pak i pokračování DD2?

Je to ta hra, o ktere pises. Me to po tech letech uz vypadlo , jen vim, ze puvodni Dave byla strasna nuda a ten druhej dil naopak dobra skakacka, hlavne ty zeleny hnusy na strope.

8

Bazar / Re:Daruji starou základní desku 386SX

« kdy: 12. 09. 2025, 15:52:16 »

Smis se zeptat predeslych zajemcu co s ni budou delat?

Nahodit MS DOS a parit Supaplex, Dave alebo treba Prince of Perzia.

myslis Dangerous Dave 2 (to s tema zombikama)? To byla/je skvela hra.

9

Vývoj / Re:Je jazyk C skutočne ťažký?

« kdy: 10. 06. 2025, 22:43:38 »

Vyumelkovany proto, ze se cela diskuze toci jenom kolem jednoho undefined signed arithmetic shiftu. O nejakem podelanem shiftu ten jazyk vubec neni.

Jop, C není o jednom podělaném shiftu.

Ale tahle diskuze je o tom jestli je C těžké. A to, že tu můžeme takhle složitě rozebírat chování jednoho podělaného shiftu, tu obtížnost ilustruje naprosto dokonale.

OT: ciste na zaklade tohoto operatoru jde naprosto to stejny rict o Jave, kde zrovna shifty taky pekne ohnuli, takze je to plny prekvapeni.

10

Vývoj / Re:Je jazyk C skutočne ťažký?

« kdy: 05. 06. 2025, 08:17:32 »

jj já vím, co ta operace dělá. ale právě kvůli té problematické -1 (tedy samé jedničky v registru) to je IMHO vždycky způsob, jak se skutečně střelit do nohy. Vlastně právě i kvůli tomu, když píšu testy na kód se signed hodnotami, tak tam vždycky vrážím právě i -1, co to udělá.

docela bych řekl, že kdo toto potřebuje v praxi, tak prakticky vždycky by to měla být unsigned hodnota. Nějaký průchod polem dělením intervalu atd. - nezáporné indexy atd. Akorát unsigned je dlouhý slovo, tak jsme líní to psát...

Praktický případ - neuronka kvantizovaná do integer aritmetiky. Tam je fakt jedno, jestli je nějaká váha 0 nebo -1 v integeru, protože je to rozdí 0.0 vs něco jako -0.000001, což je na úrovni kvantizační chyby a nemá to vliv na výslednou accuracy.

Pravda, v tom případě by se to dalo použít. Takže v podstatě výpočet toho skalárního součinu s FX hodnotami na začátku každého neuronu a potom vydělení (posun) na správné místo řádové tečky. Dobře to je pěkný případ (i když popravdě se na to FX nehodí, možná ale není někdy zbytí, než mít jen integer aritmetiku).

11

Vývoj / Re:Je jazyk C skutočne ťažký?

« kdy: 04. 06. 2025, 10:52:52 »

Jenom takova technicka - k cemu je v C potreba operace posunu na signovane datove typy?

Taky jsem se chtěl zeptat. S tím se zase tak často člověk nesetká. S unsigned posuny ano, ale se signed?

Arithmetic right shift se dá použít na rychlé dělení konstantami 2, 4, 8, 16... signed čísel. I na současných CPU je integer dělení velmi drahá operace v porovnání s bit shiftem. Nelze přitom použít operátor dělení konstantou a doufat, že to překladač optimalizuje, protože integer dělení na signed integerech dává jiné výsledky než bitový posun. Výsledek operace (-1 / 2) je 0 a výsledek operace (-1 >> 1) je -1. Pokud se překladač rozhodne vygenerovat z operace dělení konstantou bitový posun, musí generovat extra kód, který tohle handluje.

Takže když chci extra rychlý kód pro dělení signed integerů konstantou a jsem smířen s tím, že to nedává identické výsledky jako operace dělení v C, je arithmetic right shift jediná varianta.

jj já vím, co ta operace dělá. ale právě kvůli té problematické -1 (tedy samé jedničky v registru) to je IMHO vždycky způsob, jak se skutečně střelit do nohy. Vlastně právě i kvůli tomu, když píšu testy na kód se signed hodnotami, tak tam vždycky vrážím právě i -1, co to udělá.

docela bych řekl, že kdo toto potřebuje v praxi, tak prakticky vždycky by to měla být unsigned hodnota. Nějaký průchod polem dělením intervalu atd. - nezáporné indexy atd. Akorát unsigned je dlouhý slovo, tak jsme líní to psát...

12

Vývoj / Re:Je jazyk C skutočne ťažký?

« kdy: 04. 06. 2025, 10:23:43 »

Jenom takova technicka - k cemu je v C potreba operace posunu na signovane datove typy?

Taky jsem se chtěl zeptat. S tím se zase tak často člověk nesetká. S unsigned posuny ano, ale se signed?

13

Vývoj / Re:Je jazyk C skutočne ťažký?

« kdy: 03. 06. 2025, 14:04:02 »

OT k těm bitovým a aritmetickým posunům. Ani jinde to není úplně růžové. Třeba Java je na jednu stranu mnohem specifičtější, ale posuny jsou omezeny na 31 resp. 32 bitů, což dokáže docela dobře zmást.

U céčka je situace jasná - musí běžet na čemkoli, od osmibitových MCU přes DSP až po 64bitové příšery. Takže spousta věcí je prostě závislá na architektuře.

14

Vývoj / Re:Programovací jazyk Ada v České republice

« kdy: 29. 04. 2025, 20:27:42 »

Já jsem v diskuzi četl vyjádření íté manažera jedné letecké společnosti, který by dle svých slov velmi rád zaměstnal Ada vývojáře, ale protože univerzity žádné nedodávají, lituje, ale společně s vedením se rozhodl využít to, co pracovní trh nabízí, tedy C++.

Některé firmy si dokážou vývojáře vychovat pro svoji platformu. To je (z toho, co znám) například Kx systems nebo Jane Street. Ale jasně, jestli někdo hledá "hotové" lidi, co se první den posadí k notebooku a začnou makat na enterprise systému...to je zajímavá pohádka.

15

Studium a uplatnění / Re:Prerspektivy studia IT ve světle současného vývoje AI

« kdy: 19. 04. 2025, 13:09:52 »

Velkým zákazníkům jde spíše o to, aby neleaknuly jejich data, tj., aby model nezahrnul jejich otázky do svých znalostí. Některým jde o kód. Vlastně jakákoli práce s copilotama vede k leaku dat, které navíc patří firmě/zaměstnavateli, ne tomu vývojáři, co to tam dobrovolně kopíruje. A dalším jde o to, aby v obecných dotazech nebyly senzitivní informace. Třeba akciovky mají poměrně přesně zákonem dané, jak oznamují některé změny, akvizice atd. A pokud si třeba firemní copywriter nechá "připravit" tiskové prohlášení veřejným LLM, tak to už si říká o velký problém.

Ehm. Naprostá většina firem má maily v Google/MS Cloudu, soubory sdílí přes google/one drive/sharepoint, komunikuje přes Slack, Teams, Meet a Zoom - to "tiskové prohlášení" se připravuje právě tam - zdrojáky a CI mají na GitHubu a hotové aplikace pak běží v Azure, AWS a podobně (=včetně kompletních zdrojáků, pokud je to interpretovaný jazyk, a ze snadno reverzovatelných binárek (určitě tam bude verze s debug symboly) pokud náhodou není). A ty teď tvrdíš, že se situace nějak změní, když budou používat LLM často i od té stejné firmy (Gemini = Google, ChatGPT = efektivně Microsoft, Claude = AWS) hostované na té stejné infrastruktuře?

A ty extrémně paranoidní, co teď mají on-premise Azure a on-premise GitHub/GitLab prostě budou mít vedle toho další rack s GPU - on-premise LLM. Zrovna třeba DeepSeek teď dělá přesně tohle.

Já tvrdím jen to, co nám říkají zákazníci. Na začátku 2024 to bylo jedno, to jim stačila podpora Azure OpenAI, OpenAI (a tím to docela haslo, i když se podporoval i WatsonX), dnes jich hodně chce lokální modely, a ta snaha je tam je značná (i přes cenu). Ale víš jak, ona je to sociální bublina našich zákazníků, kteří potřebují hybrid cloud (jinak by asi šli k jinému dodavateli) a často běží disconnected clustery.

Jinak je vtipný, že taky máme Google mail, Google doc a Google meet. Ovšem (zjednoduším) zákaz copilotů (což ale chápu).