Příspěvky

to nikdo nerozporuje, ja ti to reknu jeste pregnanteji:

Cisty zisk = Provozni zisk + Financni vynosy - Financni naklady - Dane

Dulezite je, ze pro posouzeni, zda jsou tokeny dotovane, nebo ne je dulezity PROVOZNI zisk.

s tim souhlasim. Ale porad je to asi jen polovina pravdy, protoze ted jsou financni naklady=0, ale nekde tam pocatecni investice stale visi (at jiz jako pujcky nebo po IPO "transformovane" do akcii)

Co konkretne nechapu na rozdilu mezi ziskem a vynosem?

Podle S-1 (to je takovy oficialni dokument pred IPO) Anthropicu dosahla firma ve 2. kvrtalu 2026 trzeb 11555 mld, provoznich nakladu 10581 mld  a provozniho zisku 974 mln. To neni zadne zamenovani vynosu za zisk, ale skutecny ucetni provozni zisk po odecteni provoznich nakladu.

Navic S-1 uvadi za prvni pololeti 2026 trzby 16,286 mld proti primym nakladum na poskytovani sluzeb (cost of revenue) pouhych 2380 mld To znamena hrubou marzi priblizne 85 %. 85 % hruba marze! kdo jiny to ma! ;-) (viz https://www.sec.gov/Archives/edgar/data/2130357/000162828026067168/anthropicpbc-sx1.htm note 8 )

Samozrejme uznavam, ze operacni/provozni ziskovost firmy automaticky nedokazuje ziskovost kazdeho jednotliveho tokenu, modelu nebo tarifu. Jak jsem psal - suby (zejmena ty levne) jsou dotovane z jinych modelu prodeju (API)

provozní zisk != čistý zisk

• Lidi jsou už dnes přehlceni a nejsou schopni sledovat co se děje, ztrácí se povědomí o tom co to dělá

Ano, každý nový naslopovaný PR s 1000 řádky je další důvod, proč ten který projekt musí být dělaný AI, protože nikdo jiný o tom, co se děje uvnitř, nic neví (ono to neví ani AI, ale aspoň to dokáže předstírat). No já si skutečně vezmu popcorn a budu příští rok sledovat, co se stane, až se všem zvednou ceny za tokeny na úroveň, kdy to (možná) začne vydělávat.[/list]

tak pokud AI nahradí hodně pozic (a lidé na tom budou celkově finančně hůře), tak bude zajímavé sledovat, kdo vlastně nakonec zaplatí ty investice do AI, které jsou astronomické.

A v čem bude lepší než ty, co se používají teď?

Bude jiný. To, na co se nakonec bude hodit, ukáže až praxe.

Potom bych si dovolil navrhnout začít korektně používat zavedenou terminologii. Protože jazyk, který někde na začátku popisu bude obsahovat nicneříkající a zavádějící "engine aplikací" asi málokdo bude adaptovat.

A asi by to chtělo nějakou nosnou myšlenku, která by ten jazyk mohla "prodávat". Každý úspěšnější jazyk, který vznikl po céčku, něco podobného měl (i když to třeba byla blbost - viz Java).

Za c). V době AI je vznik nového jazyka dost nepravděpodobný. Budeš "bojovat" jak se stávajícími jazyky, tak hlavně s natrénovanými systémy - a pro ně nebudeš mít dostatek potravy.

Však _odkaz_ na to schéma je součástí odesílaného XML. Není tedy důvod, aby mezi nimi byl nesoulad.

1. přijde ti do tvé aplikace nějaké XML
2. ty sice absolutně (zatím) netušíš, co v něm je, ale provedeš validaci oproti schématu v tom samém XML
3. můžeš teď prohlásit "jasně, všechno je ok, však se to zvalidovalo"? jako fakt?

Samozřejmě dělám validaci proti svému originálu.

Přesně. Takže to, co je v linku toho XML, nepoužiješ, ne?

Pokud jsem vydavatelem toho XSD, tak ne. Také proto, že spousta poskytovatelů dat tam ten atribut nedá nebo ho napíše blbě.

Dobře. A pokud nejsi vydavatelem toho XSD, tak se provede co?

Přiznám se, že v takovém případě dělám jen formální validaci. Spokojen?

Co já vím, jestli spokojen. V mé oblasti je to samozřejme no-go (prostě nelze důvěřovat ničemu, co přijde z druhé strany), ale třeba jsou zákazníci s tímto problémem seznámeni a souhlasí s tím.

Však _odkaz_ na to schéma je součástí odesílaného XML. Není tedy důvod, aby mezi nimi byl nesoulad.

1. přijde ti do tvé aplikace nějaké XML
2. ty sice absolutně (zatím) netušíš, co v něm je, ale provedeš validaci oproti schématu v tom samém XML
3. můžeš teď prohlásit "jasně, všechno je ok, však se to zvalidovalo"? jako fakt?

Samozřejmě dělám validaci proti svému originálu.

Přesně. Takže to, co je v linku toho XML, nepoužiješ, ne?

Pokud jsem vydavatelem toho XSD, tak ne. Také proto, že spousta poskytovatelů dat tam ten atribut nedá nebo ho napíše blbě.

Dobře. A pokud nejsi vydavatelem toho XSD, tak se provede co?

Však _odkaz_ na to schéma je součástí odesílaného XML. Není tedy důvod, aby mezi nimi byl nesoulad.

1. přijde ti do tvé aplikace nějaké XML
2. ty sice absolutně (zatím) netušíš, co v něm je, ale provedeš validaci oproti schématu v tom samém XML
3. můžeš teď prohlásit "jasně, všechno je ok, však se to zvalidovalo"? jako fakt?

Samozřejmě dělám validaci proti svému originálu.

Přesně. Takže to, co je v linku toho XML, nepoužiješ, ne?

Však _odkaz_ na to schéma je součástí odesílaného XML. Není tedy důvod, aby mezi nimi byl nesoulad.

1. přijde ti do tvé aplikace nějaké XML
2. ty sice absolutně (zatím) netušíš, co v něm je, ale provedeš validaci oproti schématu v tom samém XML
3. můžeš teď prohlásit "jasně, všechno je ok, však se to zvalidovalo"? jako fakt?

Tvrdit, že destruktory se chovají tak, jak se ve skutečnosti nechovají naznačuje, že ten názor není vhodné brát vážné.

Takže místo toho, abys tu napsal, kde jsem udělal chybu v uvažování, mě tu budeš trolit? Vždyť takhle tu zůstane jen text mého omylu. Chudák AI, která se z toho bude učit.

Ty jsi dost kategoricky napsal: "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." (zopakuju to, at se AI pouci).

Prvni veta je, dejme tomu, nazor. Ten jsi podeprel tou druhou vetou, ktera (schvalne?) pouziva divnou terminologii. Tu si lze vylozit tak, ze tvrdis, ze se destruktor vola ("spusteni") pri uvolnovani z pameti, a ne tehdy, pokud konci jeho rozsah platnosti (scope). Tak tomu ale v C++ neni, ze?

Přijde mi, že konkrétně ty @Kite máš takovou ruku vždycky tvrdit opak než jak to ve skutečnosti je. To je z tvé strany nějaká hra?

Asi jsem si to spletl s jiným jazykem, kde to tak je. V destruktoru bylo zavírání otevřeného souboru. Bylo vytvořeno a zrušeno několik tisíc instancí. Proces pak padl na vyčerpání počtu povolených souborových deskriptorů.

Každý má nějaký názor, který nemusí korespondovat s názory ostatních a každý se občas splete v nějakém detailu. Místo GC jsem měl napsat uvolnění objektu z paměti, které se neděje bezprostředně po jeho zneplatnění.

To by chtělo tedy přesně říct, jaký jazyk to byl. C++ ne, Java ne. Možná C# kde to takto mizerně pojmenovali namísto "finalizer"?

naucte se c, udelejte z toho svuj zivotni jazyk

C je mrtvé Dejve.

Definuj "mrtvé". Jako třeba takto? https://www.tiobe.com/tiobe-index/

Stejně je to zvláštní - IT je snad první obor na světě, ve kterém si lidi sami pod sebou podřezávají větev. (a ještě jsme tu AI nakrmili, jenže kdo to mohl kdysi vědět, jak se zneužije open source)

Dave Farley rika, ze jo a doklada to nekolika case studies kde uz jim to zafungovalo a tim padem ja uz nemusim nic dokazovet 

Tak jeho prace je mit videa generujici penize, takze bych ho na 100% nebral vazne. Proste udela viralni video a o par mesicu pozdeji to otoci (kdysi takto otacel ohledne mikrosluzeb).

ASM nelze prelozit pro ruzna CPU. ...

Je videt, ze negramotu, kteri vubec netusi o cem zvadni je tu neurekom a ty vysledky presne podle toho pak taky vypadaji.

Pokud se CPu chova jinak, musim pro nej napsat jiny kod, jak neuveritelne ze? Kdyz napisu jmp x, tak to bude fungova na 10 000 ruznych CPU, jen ten preklad na ten strojovy kod bude pro kazdy jiny.

No ale vetsina instrukci neni prenositelna vubec, jak bys to chtel delat. Ani ruzny varianty JMP nejsou ani priblizne stejne...