V té staré dobré, skoro se mi chce říci lepší, době se dělaly věci kvalitně a důkladně.
V těch dobách mimochodem vycházela spousta vědeckých i matematických prací o teoriích kompilátorů i datových typů. Jako vedlejší efekty vzniklo třeba SQL a relační databáze (také jako důsledek pár článků), nebo regulární výrazy, apod.
Věci byly podložené přemýšlením i odborností.
Pak vznikl nabastlený jazyk C a od té doby je to v háji. Najednou programátor dělá za kompilátor věci, které má řešit kompilátor a jazyk. Jako například abstraktní datové struktury nebo paralelní programování, a celou strojovou reprezentaci dat a podprogramů.
Vzorem programátorů se staly jazyky, které měly polidšťoval assembler (C, C++), a nikoli skutečně vyšší programovací jazyky. V mainstreamu se pak šíří jazyky, které například nedokáží ani pracovat se stringem aniž by programátora obtěžoval strojovou podobou stringu (PHP, Ruby, …).
Zkrátka tehdy programovací jazyky něco uměly. A Ada byl jednoduše dobře a důkladně navržený programovací jazyk, tak se jeho technologie přebíraly jako vzor.
Za programovacími jazyky stály matematici a odborníci.
Dnes se mainstreamové jazyky pokoušejí vylepšovat C, a je jedno, jestli se to jmenuje C++, Java, C#, JavaScript, ObjectiveC, PHP, Perl, Go, Dart, a tisíce dalších prekabátěných a přejmenovaných Céček se špatnými návrhy jazyka jako takového.
Znovu říkám, v C/C++ intenzivně dělám před 30 let, a jsem po internetu známý jako jeho obrovský obhájce. Ale jsou to strojové jazyky určené pro systémové programování, ale pro běžné programování jsou špatně navrženy. Ony i pro to strojové programování dost drhnou, ale budiž.
> JAK by takový dokonalý (nebo lepší "vylepšeného C") jazyk měl vypadat...
Já už jsem svůj pohled naznačil minule, ale myslím si, že by jazyky měly být blíž k teoretickým výpočetním modelům a matematice než k počítači, na němž zrovna běží.
Osobně bych například eliminoval omezený zásobník a tím i chyby přetečení zásboníku, standardem by byla neomezená celá a racionální čísla (modulární aritmetika a floaty dle IEEE 754 by byly přístupné až po explicitním zapnutí nebo vůbec), do proměnných by nešlo přiřazovat a neexistovalo by nic jako referenční rovnost. Přidal bych konstrukce pro paralelní programování jako má například Manticore - viz Programming in Manticore, a Heterogenous Parallel Functional Language.
„Já už jsem svůj pohled naznačil minule, ale myslím si, že by jazyky měly být blíž k teoretickým výpočetním modelům a matematice než k počítači, na němž zrovna běží.“
Kde to mám podepsat?
Pokud člověk chce být blízko procesoru, má strojový kód a assembler. Pokud chce programovat, měl by programovací jazyk být něco jiného, než instancí assembleru, jako jsou C/C++.
suhlasil by som az na malicky fakt, ze je rozdiel medzi idealizmom a realitou. Realita je ta, ze pre programovanie blizko procesora je C dostatocne dobry jazyk. Tj uzivatel tazko oceni krasu jazyka v ktorom je OS naprogramovany ak to bude znamenat ze to bude 2x tak pomale a 4x tak velke. Dnes uz to asi nehra moc rolu (stare zlate casy ked jednoduchy editor nemal 10MB) ale kedysi to bolo ine.
PS : cloveka co by chcel naprogramovat cely OS v assembleri by som celkom rad videl. Skor nez zacne nejaky chytrak tu vytahovat priklady podotykam realny OS.
> A co třeba Rust?
Otázkou je, jak velký negativní vliv bude mít lineární (nebo afinní?) typový systém na modularitu. Další otázkou je, jaké programy půjde zapsat v bezpečném fragmentu jazyka bez ztráty výkonu. Bohužel, Rust momentálně není schopen zabránit memory leakům.
Stačí použít počítání referencí ze standardní knihovny a udělat cyklus. V našem případě zkonstruujeme p
, které ukazuje samo na sebe:
use std::cell::RefCell; use std::rc::Rc; struct Pokus { jiny: RefCell<Option<Rc<Pokus>>>, } impl Drop for Pokus { fn drop(&mut self) { println!("Zaviram"); } } fn main() { let p: Rc<Pokus> = Rc::new(Pokus { jiny: RefCell::new(None) }); let mut jiny = p.jiny.borrow_mut(); *jiny = Some(p.clone()); }
Destruktor Pokus
u se nezavolá a lze ověřit valgrindem, že paměť nebyla uvolněna.
V roce 2013 Rust vypadal trochu jinak - měl vestavěnou podporu pro garbage collector (ukazatele se zavináčem) a uvažovalo se o tom, že by typový systém hlídal, aby nevznikl referenční cyklus - viz [rust-dev] Statically preventing reference-counted cycles while allowing nested rc pointers.