Před časem jsem začal přemýšlet nad tím, k čemu jsou jazyky s dynamickým typováním - konkrétně python a jeho ducktyping. Nemyslím tím vlastní jazyk, ale právě tu netypovost. Vždyť staticky typované jazyky jsou mnohem pohodlnější. Počínaje nápovědou IDE a konče tím, že si navrhnu applikací pomocí tříd a pak ho tak nějak seskládám do hromady.
Samozřejmě trošku zjednodušuji, ale ten pocit jsem měl.
Díky příspěvkům v tomto vlákně jsem to zdá se pochopil. Zkusím to rozebrat, třeba mi k tomu řeknete něco zajímavého.
Vezměme si třeba takovou Javu jako zástupce staticky typovaného jazyka (Ada by prý byla lepší, ale nemám zkušenosti). V Javě si logiku programu rozdělím do jednotlivých tříd, nejlépe podle návrhových vzorů. Tyto třídy si otestuji, zda dělají co mají, vytvořím instance těchto tříd a pak se mi aplikace skoro sama poskládá z těchto instancí. Přeložím a mám hotovo. Samozřejmě to není jen tak. Díky tomu, že vytvářím konkrétní typy tříd, tak mi půlku pracovní doby trvá, než vychytám všechny ty typové nesoulady.
V případě Pythonu, jako zástupce dynamického typování, to bude podobné, s tím rozdílem, že zde nemám tu kostru typové kontroly. Tudíž na jednu stranu nic mi nebrání jako parametr nějaké metody dát zcela cokoliv, a díky tomu se pěkně zamotat v chybách zanořených v naprosto nečekaných místech, na druhou stranu nemusím se s překladačem dohadovat kdo má pravdu. O různých kouzlech ani nemluvě.
Uvažoval jsem dál, k čemu je tedy dobrá ta silná typová kontrola. Tak například když budu psát unittesty pro Javu, tak nemusím kontrolovat, zda mi do objektu vlezl správný objekt. To mi ošetří překladač. (V Pythonu musím ověřit nejen, že mi tam vlezl správný objekt, ale také, zda je validní.) To znamená, že když bych byl schopen vytvořit typ, který určí, že hodnotou instance můžou být pouze řetězce reprezentující validní email, nemusím v žádném unittestu kontrolovat, zda příchozí instance emalu obsahuje validní hodnotu. (Samozřejmě unittest pro ten vlastní typ napsat musím.) Takže když postoupím o krok dál v úvaze, když bych byl schopen vytořit pro každý typ pravidlo, které normálně píšu do integračních, nebo dokonce do unittestů, nemusel bych pak tyto testy psát. Každé přeložení zdrojáků by bylo zároveň korektní prověření testů. O Adě se říká, že jakmile ji jednou přeložíte, tak funguje bez chyby. U Javy to tedy evidentně nestačí, a nějaké ty testy psát musíme. Ale kdyby...
A tak si možná návrháři pythonu řekli, že když je tak těžký dotáhnout tu typovou kontrolu do stavu, kdy by stačil jen překlad, tak co na to jít z druhé strany? Vykašlat se na typy úplně, nechat je jen jako informaci pro reflexi, a říct vývojáři, že odměnou za to, že bude psát více testů je to, že ho kompilátor nebude tolik otravovat.
Ono psát v pythonu bez testů prostě nejde.