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.
Co se týče Javy a Go, tak mi to stále nedochází. Obecně v každém okamžiku prvky znají svůj typ. Že ten typ je Object nebo Any, no to je tvoje volba, ne omezení/vlastnost jazyka.Typ objektu je to, co je za new, ne deklarovaný typ proměnné.
Že C++ je slabě typované, přinejmenším typy bez RTTI. V Javě nebo Go se dá z takové chyby zotavit.Obávám se, že mi nedochází co tím chceš demonstrovat.tak jsem nabyl dojem, že zásadní problém je v tom, že slabě typovaný jazyk (= ve smyslu jazyka, kde by prostředí v daném okamžiku nevědělo jakého je ten který prvek typu […]) možná ani neexistuje. Tudíž klauzule, že jazyk XY je silně typovaný je jen tak pro parádu.Tohle mi nedá spátMyšlenkový experiment: Rozhodnu se v různých jazycích explicitně neuvádět typy proměnných, takže v C++ budou všechny pointery void*, v Javě bude všechno Object, v Go vše, jak jinak, interface{}, v Rustu Any apod. Při použití (volání metody, přístup k datům) musím vždy explicitně přetypovat. Kterépak jazyky ustojí chybu v typu a kde nastane segfault nebo něco podobně nedefinovaného a destruktivního? To jen tak k zamyšlení..
tak jsem nabyl dojem, že zásadní problém je v tom, že slabě typovaný jazyk (= ve smyslu jazyka, kde by prostředí v daném okamžiku nevědělo jakého je ten který prvek typu […]) možná ani neexistuje. Tudíž klauzule, že jazyk XY je silně typovaný je jen tak pro parádu.Tohle mi nedá spát
Myšlenkový experiment: Rozhodnu se v různých jazycích explicitně neuvádět typy proměnných, takže v C++ budou všechny pointery void*, v Javě bude všechno Object, v Go vše, jak jinak, interface{}, v Rustu Any apod. Při použití (volání metody, přístup k datům) musím vždy explicitně přetypovat. Kterépak jazyky ustojí chybu v typu a kde nastane segfault nebo něco podobně nedefinovaného a destruktivního? To jen tak k zamyšlení..
Má pravdu, vyjde to nastejno v Javě nebo třeba Ruby.Jinak souhlas, že validace s typovými schopnostmi jazyka v mainstreamových jazycích moc nesouvisí, pokaždé se validuje ručně psaným kódem (ať už ho napsal kdokoli).Jakto doprcic zase ze s tim nesouvisi.
Ne.Nejelegantnější jsou stejně silně typované jazyky (s nepovinným typováním => s kvalitním odvozováním typů) a s pozdní vazbou. Ale to už se tu ale probíralo mnohokrátneni pozdni vazba synonymum pro dynamicke typovani?
Nejelegantnější jsou stejně silně typované jazyky (s nepovinným typováním => s kvalitním odvozováním typů) a s pozdní vazbou. Ale to už se tu ale probíralo mnohokrátJako například ObjC?
YAW. Když narazím na nějaký zajímavý článek k tématu, dám vědětJasně, message received. A dík i za předchozí příspěvek.…BTW možná to zapadlo, ale Rustu ten jazyk nijak nekonkuruje, je náhradou za R, Matlab a Python, těžko v něm někdo bude psát třeba mikroslužby nebo dokonce něco systémového (ani neumí vytvářet pořádné samostatné binárky). Mě osobně zajímají jen čistě technické aspekty překladu a optimalizace kódu. S Rustem se oblasti nasazení prolínají třeba u věci jako je Egg a dost často bude lepší napsat prostě všechno v Rustu kvůli například kontejnerizaci apod. Ale v oblasti tzv. vědeckých výpočtů jsou priority, proč si to nepřiznat, úplně jinde (kdysi kdosi se tam snažil prosadit Swift, ale asi se moc neuchytil).
Proboha... uz je tu zas BoneFlute, a zaslechl staticke typovani. Tato diskuze je timto mrtva.
kdo z vas si vzpomene na hubickovy skolicky?!Já, a i na něj osobně, na MFF byl postrachem profesorů
…BTW možná to zapadlo, ale Rustu ten jazyk nijak nekonkuruje, je náhradou za R, Matlab a Python, těžko v něm někdo bude psát třeba mikroslužby nebo dokonce něco systémového (ani neumí vytvářet pořádné samostatné binárky). Mě osobně zajímají jen čistě technické aspekty překladu a optimalizace kódu. S Rustem se oblasti nasazení prolínají třeba u věci jako je Egg a dost často bude lepší napsat prostě všechno v Rustu kvůli například kontejnerizaci apod. Ale v oblasti tzv. vědeckých výpočtů jsou priority, proč si to nepřiznat, úplně jinde (kdysi kdosi se tam snažil prosadit Swift, ale asi se moc neuchytil).
Rust je jazyk, který by z principu měl být jeden z nejrychlejších, co se běhu týče.Tak Rust je jeden z nejrychlejších, ale má svoje limity dané designem jazyka.
Tu Tvoji empirii nevyvracím, ale když to zkouším googlit, moc vodítek nebo důkazů nenacházím.
Egg neznám, natož abych mohl konkrétní implementaci toho algoritmu rychle srovnat s implementací v Julii a něco z toho vyvodit. Ale dík aspoň za tenhle hint.
Ta nápověda teda měla říct něco jiného, než že MD pomáhá výkonu?Ne, ale neříká celou pravdu, “tajemství úspěchu” tkví v typovém systému, který má (omezenou) dědičnost, varianci typů a HKT, takže ve spojení s dynamickým dispatchem umožňuje překladači extrémní optimalizace. Jaký je přínos sofistikovaného typového systému v porovnání s MD nedokážu říct (a ani nevím, jestli to vůbec jde kvantifikovat, jsou dost propletené). Druhým faktorem jsou ad hoc optimalizace, které překladač dělá hlavně nad typy v době překladu, například u Union apod. Překladač Rustu neznám tak podrobně, ale mám za to, že většinu optimalizací nechává na LLVM (bylo by fajn, kdyby to někdo potvrdil nebo vyvrátil), kde nejsou tak ad hoc, což je v tomto případě nevýhodou.
To je vidětKaždopádně mě teda to Tvoje tvrzení o rychlejší Julii nadále dráždí, asi si to někdy prozkoumám.Jakým způsobem multidispatch urychluje běh programu? Už jsi to psal dřív, ale mně to úplně smysl nedává...To jsem nikdy nepsal, ani teď, jen to, že umožňuje velice efektivní optimalizaci výsledného kódu, pokud je program správně otypovaný (o tom je řada článků na konferencích jako POPL, co to je typově ukotvený program a jak ovlivňuje výsledný stroják).
Ale taky tě dráždí, že je Porsche rychlejší než kombajn? Je to prostě empiricky podložený fakt, mě to taky překvapuje a sám to “prozkoumávám”, což jde celkem lehce, protože oba překladače používají LLVM. Určitě znáš rustí Egg, který, pamatuji-li se dobře, vyhrál (resp. jeho design) i nějaké ceny na akademických konferencích. Tak stejný algoritmus pro e-grafy je v Julii rychlejší
Jakým způsobem multidispatch urychluje běh programu? Už jsi to psal dřív, ale mně to úplně smysl nedává...To jsem nikdy nepsal, ani teď, jen to, že umožňuje velice efektivní optimalizaci výsledného kódu, pokud je program správně otypovaný (o tom je řada článků na konferencích jako POPL, co to je typově ukotvený program a jak ovlivňuje výsledný stroják).
Tak ono to tak zhruba bývá, ten rozdíl je, že ten rozbíjející let donutí JIT znovu přeložit kód a jelikož program není typově správně, vyplivne nějaký pomalý hnus. Na webu jsou příklady, jak změny v typových anotacích enormně ovlivňují generovaný stroják (sám jsem se setkal s více než desetinásobným zpomalením kvůli jednomu špatně uvedenému typovému parametru). Všichni mají zažité, že dynamické jazyky musí být pomalé, protože Python, Ruby nebo JS jsou šneci, ale když všechny typové anotace sedí, překladač může generovat rychlý kód (teď už máme empirický důkaz), ale stejně je IMHO v obecném případě lepší použít třeba Rust nebo Go se statickým typováním, Julia je navržená jako v podstatě DSL nahrazující Matlab, R a Python pro ML apod., na nasazení v jiné oblasti to moc není. Jen je prostě zajímavé pochopit, jak v tomto podivném jazyce funguje typový systém a díky němu překladač.To máš se mnou těžké, když já si představuju, že poté, co kompilátor vyplivne program, tak v něm jsou všechny typy odstraněný jako zbytečný, a jsou ponechaný jen ty nutný pro dynamic dispatch, a to ještě jenom v případě věcí jako je kolekce podtypů...Typová bezpečnost u dynamického jazyka znamená co konkrétně?To samé jako u staticky typovaného, že kód jde otypovat tak (ručně nebo inferencí), že v době běhu není nutné zkoumat typy objektů pro hladký běh.
Zatímco u dynamického jazyka všechny typy musí zůstat, protože je třeba umožnit, aby to ve čtvrtek na produkci zbuchlo až tam Franta zapíše int věk="starej". (Ano, slyšel jsem o JIT.)
Root.cz (www.root.cz), informace nejen ze světa Linuxu. ISSN 1212-8309
Copyright © 1998 – 2023 Internet Info, s.r.o. Všechna práva vyhrazena. Powered by Linux.