A když se to spojí, tak máme ten hypotetický jazyk, který by dokázal nahradit testy v případech užití, které byly uváděny.
Uváděn byl příklad dvou funkcí pro sumaci. Nějak ho stále přehlížíte.
Obávám se, že to není nijak podstatné.
Byly časy, kdy API funkce (říkejme tomu spíše signatura) vypadala nějak takto:
function substr(String str, Int start, Int len) : String
A v praxi jsme pak museli ošetřit testem, co se stane, když zavoláme substr("abc", 6, -2). Někde uvnitř té funkce bylo definováno, že to má vyhodit výjimku, prázdný řetězec, nebo něco takového. Podstatné ale je, že signatura funkce o této nesmyslnosti nic nevěděla.
Dnes už máme typy na takové úrovni, že dokážeme zohlednit, že substr("abc", 6, -2) nepůjde vůbec přeložit. A myslím, že nikoho nijak zvlášť nezajímá, že kdysi dávno se tvrdilo, že ošetření těchto nesmyslných vstupů je otázka implementace, a nikoliv API/Signatury.
Takže pokud trváš na tom, že API/Signatura a implemnetace/chování jsou dva oddělené světy, tak já ti tvůj názor přeji, ale v takovém případě nám nejde o stejnou věc.
Ale já nepíšu o signatuře, píšu o API. A součástí API té funkce
substr je, že někde v dokumentaci, např. v manuálové stránce, je napsáno, co ta funkce má dělat, a v lepším případě i jaké jsou možné parametry a co to bude dělat, pokud budou parametry mimo rozsah. V horším případě tam zejména ty chybové stavy moc dobře popsané nebudou , a pak nastává ten případ, o kterém jsem také psal, že se mohou lišit názory na to, jaké je vlastně přesné API té funkce.
Že API a implementace jsou dva oddělené světy jsem uváděl na tom příkladu se sumací, který raději ignorujete. Mimochodem, je to uváděné jako základní vlastnost API, že odstíní uživatele od konkrétní implementace, takže implementace se může měnit, aniž by se o tom uživatel dozvěděl. Znáte třeba POSIX?
Jak nemůže? Proč by nemohl? Ať je platforma jakákoliv, tak čas bude všude stejný ne? Této argumentaci nerozumím.
Nechcete doufám tvrdit, že stejný kód poběží stejně rychle na 386 a na dnešních výkonných procesorech? Že poběží stejně rychle na Raspberry Pi, na chytrém telefonu i na pracovní stanici?
Ostatně, to, že rychlost funkce závisela na rychlosti procesoru je pradávná historie.
Říká vám něco pojem „výpočetní složitost“? Vážně si myslíte, že když budete mít v poli o milionu čísel najít největší hodnotu, nebo ho setřídit, nebude doba trvání té funkce záviset mimo jiné na rychlosti procesoru?
Jen si to představ. Vezmeš nějakou hru a dáš ji přeložit pod 486kou, a ono ti to odmítne, protože nejde zaručit potřebnou rychlost. Horní mez je sranda, to stačí jen oříznout.
Tak samozřejmě se můžeme bavit o tom, jak to zjistit, jak moc to jde zaručit, ale je třeba myslet na kontext tohoto vlákna. Porovnáváme to s testy. Pokud to nezvládneš ani testy, tak není nutné řešit jak to udělat typy.
Jak přeložit pod 486? Vy jí máte k dispozici? A máte k dispozici i budoucí procesory? Navíc rychlost té funkce by přece musela být zakódovaná v tom typu.
Testy se tohle řeší snadno. Napíše se test, který bude měřit dobu běhu té funkce a zkontroluje, že je v daném rozmezí. Že ten test odhalí chybu, až když ho spustím na příslušném zařízení? Ano, to je vlastností testů, že nejsou prevencí chyb, ale umožňují chyby rychle nalézat po té, co k chybě došlo. Že testy nepokrývají všechny případy? Ano, i to je vlastností testů, a to umožňuje, aby se testy vůbec v reálném světě používaly. Protože programování je stále založené na tom, že se vybírají ty podstatné věci, které se vyjádří v programu, a všechny ostatní nepodstatné se ignorují. Takže se třeba v definici API ignorují záporné hodnoty indexu funkce
substr, protože přece nikdo soudný nebude předávat záporný index.
Aby ten váš dokonalý typový systém opravdu předcházel všem chybám, jak si představujete, musel by do typu nakonec zakódovat celý vesmír. Vy považujete za nedokonalost testů, že nepokrývají vše. To ale není nedokonalost testů, to je „nedokonalost“, která je v samotných základech programování, a dokonce i v základech jakéhokoli modelování nebo abstraktního popisu světa, který dělá např. věda. A tahle „nedokonalost“ způsobuje, že vůbec něco jako programování nebo věda může existovat. Bez toho ořezávání nepodstatných informací by to totiž nebyl model ale reálný svět. A že občas ořízneme i informaci, která ve skutečnosti je podstatná? Ano, to se stává, jsme jen omylní lidé. Proto máme různé způsoby, jak na takové chyby přijít. Ale řešením není snažit se tam nacpat co nejvíc jakýchkoli informací, protože to byste nikdy neskončil.