Vlákno názorů k článku Programovací jazyk Ada: nástroje pro řízení běhu programu od h - Čili na datové typy není spolehnutí stejně jako...
-
K tomuto nesmyslnému závěru jste došel jak?
V C/C++ se míchají nesmyslně dvě věci, tj. datový typ a jeho binární reprezentace. Ada má ipso facto jen dva celočíselné typy: aritmetický a modulární. Více není potřeba, protože toto určuje všechny operace nad nimi.
C/C++ má pouze jeden celočíselný typ: modulární (z hlediska terminologie Ady). Protože ovšem není schopno C/C++ určit rozsah datového typu, nesmyslně je zmnožuje do myriád názvů, které jsou ovšem stále modulárním celočíselným typem, ovšem s různými rozsahy hodnot: short/int/long/long long, atd. V Adě nic takového není třeba, protože rozsah si určítě explicitně pomocí zadání rozsahu hodnot čísel typu.
Tedy Ada nahradí všechny C/C++ celočíselné typy jediným typem zvaným modulo celočíselné typy. Příklad:
type Byte is mod 256; -- celočíselný integer s rozsahem 1 bajt
Co autor článku bohužel nevysvětlil je že Integer typ v Adě se nechová jako v C/C++. Je to skutečně pravý matematický celočíselný typ. Při podtečení/přetečení se nepřetáří bitíky, takže 255+1 není -1 na 8bitovém typu, atd.
Tedy typ Integer v Adě je celočíselný typ s tak pěkným chováním, v jakém se v jazycích C/C++ vůbec nevyskytuje. Takový typ v C/C++ neexistuje. V C/C++ existují pouze celočíselné typy, které Ada nazývá modulo typy. Skutečný aritmeticý celočíselný typ, který se více chová matematicky, než počítačově, jazyky C/C++ vůbec nemají.
Tedy rozsah celočíselného typu, který jste měl na mysli, není na libovůli kompilátoru, ale na libovůli programátora. Protože máte k dispozici možnost rozsahu, takže třeba 32bitový znaménkový celočíselný typ (z hlediska rozsahu) v Adě programátor předepíše jako Integer range -2**31 .. 2**31-1, a je to. Zde žádná libovůle kompilátoru není.
Ada je čistější jazyk, a odděluje datový typ a jeho rozsah do dvou samostatných věcí, které si můžete samostatně určovat. Takovou kontrolu celočíselných a jiných typů v C/C++ nenajdete, a proto není vůbec potřeba, aby typ měl určen rozsah, ten si přeci programátor explicitně určí dle své potřeby.
To, že C/C++ naučil několik generací programátorů, že prasecké datové typy jsou normální, je bohužel smutná skutečnost.
P.S.: Autor tohoto příspěvku píše v C++ několik desetiletí, a má C++ opravdu rád. Přesto datové typy v C++ jsou tou negativní stránkou C++ jazyka. Velmi negativní.
Ing. Miloslav Ponkrác
-
A tyto typy normální Adista by nejspíše nikdy přímo nepoužil.
Autor, který píše tento seriál je důkazem, že někteří lidé umějí programovat pouze v jednom programovacím jazyce, a v něm programují, ať už se jim pod ruku dostane jakýkoli jazyk.
Nechci autora článku shazovat, ale stjeně tak jako „každý opravdový programátor programuje ve Fortranu v jakémkoli jazyce“, autor tohoto seriálu „programuje v C v jakémkoli jazyce“.
Styl těchto článků se mi zdá poněkud nešťastný, a mám pocit, že poněkud Céčkoidní. Jenže v Adě, která je od C velmi vzdálena, je to poněkud jako pěst na oko. Autor namísto předvedení skutečné Ady neukazuje nic jiného, než jak přepsat Céčkové konstrukce do Ady.
-
Pavel TišnovskýZlatý podporovatelJeště bych přidal problematiku floating point typů - s těmi spousta lidí strašně "kouzlí", takže mnoho algoritmů je zcela špatně nebo "pouze" počítá s obrovskými chybami, protože pro FP hodnoty spousta předpokladů prostě neplatí, například asociativita, distributivita atd.
A není to jen problém C/C++, protože ten typový systém přešel i do Javy (například).
V tomto má Ada skutečně výhodu, protože minimálně programátora donutí se zamyslet, *jaké* hodnoty používá a k jakým operacím s nimi bude docházet.
-
Typový systém C/C++ bohužel přešel do celé řady dalších jazyků. V zásadě to není primárně made by C, ale je to nešťastný systém. Bohužel po C/C++ ho převzala obrovská spousta jazyků, jako Java, C#, atd.
C-like typy jsou typy, které v podstatě vidí proměnné jako konkrétně strojově uložené bitíky.
Ada-like typy vycházejí z toho, že typy jsou data s nějakými operacemi, a strojová podoba vás nezajímá. Teprve pokud moc a moc chcete, Ada vám umožní kontrolovat i strojovou podobu, ale je to kontraproduktivní.
Adě řeknete s jakými daty chcete pracovat, a zbytek je práce Ady. Zatímco v C/C++ programátor maká za kompilátor, a stejně od C/C++ standardu, ani od samotného C/C++ jazyka nedostává potřebné standardy rozsahů typů ani pomoc v syntaxi.
Adě řeknete, jaká data chce mít, jaké hodnoty v nich chcete mít, případně jaké další podmínky/constrainty (třeba vyjádřené matematickou rovnicí) musí hodnoty datového typu splňovat. A zbytek je na Adě. Je to velice pěkně vymyšlené, a představení těchto věcí ukáže skutečnou krásu a možnosti Ady. Velká škoda, že jen minimum jazyků to od Ady převzalo, ale taková konzistence dat, jakou kompilátor je schopen zajistit v Adě (přesněji pomoci zajistit) se jinde nevidí.
U floating point (Ada má také fixed point reálná čísla v jazyce) většina lidí v C/C++ nejenomže nezná obory hodnot, ani chování reálných čísel ve formátu ieee754 a spol., ale také nekontroluje přetečení (to spadne do ±nekonečna), ani definiční obory funkcí (to spadne do NaN). Neřku-li, že by počítali se zaokrouhlovacími chybami.
Zkrátka datový typ v Adě je dán operacemi a množinami hodnot, nikoli strojovou reprezentací jako v C/C++. Překlad do strojáku je věcí kompilátoru Ady, stejně jako volba nejlepšího strojákového typu. Jako člověk, který C/C++ intenzivně používá před tři desetiletí musím říci, že programátor za C/C++ dělá příliš mnoho věcí místo kompilátoru, že C/C++ je spíše jen fikanější assembler, než vysokoúrovňový programovací jazyk. Přitom Ada nedělá méně optimální kód, než C/C++.
-
To není smělé tvrzení, ačkoli benchmarky nemám, a nejsou ani třeba.
Benchmarky stejně nedělají nic jiného, než srovnávají rychlosti kompilátorů, nikoli možností jazyka.
Kód a Ady může být dokonce udělat i rychlejší kód, neboť má více informací, než je v kódu C/C++. Nejvíce to bude patrné v multithreadových aplikacích, protože v Adě to řeší jazyk, ve většině jiných jazyků to řeší knihovny. A Ada má možnost vyhazovat různé zámky a optimalizovat zamykání i počet threadů, protože jazyk o všech paralelních akcích doknale ví, řeší to jazyk, nikoli knihovny, a Ada také celou paralelní práci i se zamykáním a synchronizací optimalizuje jako celek.
Ostatně dříve se kernely operačních systémů psaly třeba v Module, Adě i jiných jazycích, myslíte, že Céčko je nějak lepší nebo rychlejší? Proč by mělo být.
Ten mýtus, že C/C++ je nějak rychlé, nechápu. V porovnání s Javou, C#, Perlem, Ruby, Pythonem ano. Ale každý slušný optimalizovaný jazyk dokáže to samé co C.
Ada navíc umožňuje lépe zvolit strojové reprezentace proměnných, protože to je věcí kompilátoru, nikoli programátora.
Ostatně NASA nasazuje Adu i do pomalých procesorů, proč asi?
Ada je jazyk schopný velmi dobré optimalizace.
Rychlost výsledné binárky je dána více množství informací ve zdrojovém kódu, spíše než jeho nízkoúrovňovostí.
Podle mě je spíše smělé tvrzení, že C je nejrycheljší jazyk. Dříve, když se považovalo za běžné jazyky dobře navrhovat, kdy programátoři museli mít teoretické znalosti atd. – by nikdo Céčko za jediný rychlý jazyk nepovažoval.
Rychlost C nad všechny jiné jazyky je spíše urband legend a unixový fanatismus, než pravda.
-
Inkvizitor (neregistrovaný)
Já netvrdím, že C je *nutně* nejrychlejší jazyk na světě, ale jelikož je to v zásadě o trošku vyšší assembler, což jste myslím sám psal, bral bych jeho potenciál k napsání nejrychlejšího kódu (po assembleru samotném) jako nulovou hypotézu. Jednoduše proto, že do takového programu je možné všechny ty informace dostupné jazykům typu Ada vložit také.
Rozumím tomu a doufám v to, že kompilátory vyšších jazyků jsou v principu schopny dostat se nad úroveň dobrého optimalizátora v C, ale to je teorie a tu praxi, tj. současný stav toho kterého kompilátoru, nelze prokázat jinak než empiricky.
-
JSH (neregistrovaný)
Ano, v assembleru se dá napsat nejrychlejší kód, ale je to zatraceně těžké. Stejně tak se dá v C napsat zatraceně rychlý kód, ale optimalizátor s tím moc nepomůže. Vzhledem k tomu, co všechno C dovoluje, se musí optimalizátor hodně hlídat (např. aliasing).
Nejdůležitější ale není jazyk, ale návrh datových struktur a algoritmů (i podle architektury). Samotný jazyk je až druhořadý. Pak tady na rootu vznikají humorné diskuze, kde si pár trotlů poměřuje, kdo ho má rychlejšího na naivním O(N^3) maticovém násobení a je na nich vidět, že se znalostma o procesorech skončili někde u 386 nebo podobného starého střepu.
Nejvíc prasáren se stejně omlouvá rychlostí kódu a to i u těch 80% programu, kde je rychlost totálně nepodstatná.
-
Inkvizitor (neregistrovaný)
Však já nejsem velkým příznivcem C a ani C++. Když ale někdo napíše, že nějaký překladač produkuje rychlejší kód než jaký se dá běžně napsat v C, zajímalo by mě, jak to ví. Že algoritmus je (často, ne vždy) rozhodující, o tom se nepřu. Že je lepší udržovatelný kód o pár procent pomalejší, o tom se taky nepřu.
Že může Ada (nebo Fortran nebo klidně JavaScript) být někdy a v něčem rychlejší, se taky nepřu. Ale zajímá mě kdy a o kolik. To bez benchmarku nelze zodpovědět.
-
Zimiston (neregistrovaný)
No, jestli Ada kontroluje u každýho výpočtu přetečení, tak to zrovna rychlý nebude. Jestli se použije nějakej modulo type, kterej zrovna odpovídá nějakýmu nativnímu CPU typu, pak to bude stejný IMHO. Jinak nevěřím, že nějaká konkrétní firma měla tolik prostředků, aby dokázala napsat kompilátor, kterej by konkuroval dnešním nejrozšířenějším kompilátorům. Vono oprimalizovat pro moderní CPU je takový voodoo :-)
BTW kdysi jsem porovnával rychlost u nějakejch intenzivních výpočtů mezi MSVC++ a Delphi - na jaký časy se dostaneme já a kamarád zažranej Delphista u floating point a fixed point obojí 32 bitů a dopadlo ro pro Delphi dost žalostně. I po kouknutí do asm co to Delphi vyprodukovalo jsme kroutili hlavama. IMHO neměl Borland dost síly a prostředků napsat skutečně optimalizující kompilátor. -
Pavel TišnovskýZlatý podporovatel
Oni to ani nechteli, protoze konkurence pro Delphi byl VB, takze ukol znel jasne:
1) co nejrychlejsi kompilace, idealne, aby se to spustilo stejne rychle jako tokenizovany kod
2) vysledne programy musi byt rychlejsi nez analogie ve VBTakze takto nizko polozena latka byla splnena (a ano - Delphi jsem mel hodne rad, takovy C++ Builder byl vzdycky o dost pozadu, bylo videt kam Borland predevsim smeruje)
-
Ještě jedna věc, podívejte se také na Fortran a zkuste s ním porovnat rychlost C/C++ pro nějaký matematický výpočet. A opět zjistíte, že C/C++ je rychlostně pozadu.
C/C++ prostě zjednodušením svého jazyka ztratilo také možnosti řady optimalizací.
C/C++ není rychlostně nijak výjimečný mezi kompilátory. Nechápu tu legendu o jeho maximální rychlosti mezi jazyky.
-
SB (neregistrovaný)
„...C/C++ je spíše jen fikanější assembler, než vysokoúrovňový programovací jazyk.“
Jinými slovy:
C je pouze chytřejší a portovatelnější assembler, nic jiného se od něj nečeká (a kdo čeká, spálí se).
C++ vzhledem k tomu, jak nízkoúrovňové věci v něm musí programátor hlídat a řešit, není možno považovat za vysokoúrovňový jazyk. -
Adovské typy jsou nekorunovaným králem Ady. Je to jedno z nejlepších řešení typů, jaké kdy u programovacích jazyků najdete.
Škoda, že autor článku nevyužil možnosti datové typy Ady opravdu představit, stejně tak jako vysvětlit jejich rozdíly oproti C/C++.
Najdete jen minimum programovacích jazyků, kde jsou datové typy tak perfektně povedené, jako je to v Adě. Datové typy jsou v Adě promyšlené, jako nikde jinde. To je jedna z mála věcí, které uzná o Adě i její nepřítel.
