Ten učebnicový příklad mi připadá nešťastně zvolený. Definuji-li typ integer s omezením 0..255, musím přirozeně definovat operátor + pro všechny možné hodnoty tohoto typu. I pro hodnoty, jejichž součet je již mimo povolený rozsah. Tudíž nezahlásí-li kompilátor na váš příklad chybu, není to "vina" staticky typovaného jazyka, ale návrháře onoho typu 0..255, protože v definici operátoru + neošetřil přetečení.
Tady nejde o to, že dojde k přetečení - to je problém, který si každý jazyk řeší po svém. Jde o to, že tuhle situaci lze pomocí čisté statické kontroly řešit jen stěží a je nutné to ošetřovat za běhu.
Leč ve staticky typovaných jazycích si mohu u každého typu zvolit, zda naprogramuji explicitní kontrolu korektnosti parametrů, anebo zda ji v daném případě nepotřebuji (a získám tím rychlejší kód než v dynamicky typovaných jazycích)
Mimochodem téměř všechny výhody dynamicky typovaných jazyků, které jste v článku zmínil, jdou IMHO zařídit i ve staticky typovaných jazycích, použijete-li vhodný objektový model.
Např. kontrolu neNULLovosti instance, generické kontejnery a přetypování v rukou programátora můžete řešit klasickým způsobem, že k objektům budete přistupovat pouze přes interface.
Navic pokud zacnete pouzivat v C++ templates a STL a zapomenete na pointry a zacnete vse delat staticky nebo pres reference ziskate temer bezpecny program (co se tyce NULL a spatneho pretypovani).
A kdyz pridate pouzivani const bude delat prekladac divy s rychlosti vysledneho kodu.
Myslim si, ze je lepsi kontrolovat co nejvic veci automaticky pri kompilaci, nez za behu resit tisice vyjimek.
Nakonec zavedeni generickych typu do javy je toho dukazem.
Nechapu totiz, v cem je vyhoda, pokud mi pouzitim dynamickych typu vzroste potreba ladit. Kdo nekdy neco vetsiho ladil, vi, ze je to PEKLO. A urcite byl rad, za kazdou pomoc, kterou za nej udelal automaticky compilator.
Budoucnost je nekde jinde. Budoucnost je ve snaze presunout co nejvice prace na automaticke zpracovani.
Dovolil bych si nesouhlasit. Myslim, ze jste spatne pochopil tu pasaz o potrebe ladeni, soude z vety cituji: Nechapu totiz, v cem je vyhoda, pokud mi pouzitim dynamickych typu vzroste potreba ladit.
Pokud mam dynamicky typovany jazyk smalltalkovskeho typu (dale jen Smalltalkoidni, ale takovy je i LISP, Self...), musim testovat (resp dost dost se to hodi). To znamena, ze pisi unit testy. Jenze - protoze je ten jazyk tak dynamicky, muzu testova nehotove kusy trid, bezprostredne kdyz je napisi (resp si napsat testiky na jednu tridu jeste pred tim, nez ji napisi :-). Takze cyklus design (v malem), implementace, testovani je velmi velmi kratky - 5,10,maximalne 15 minut. O vyhodach unit testu pri refaktoringu ani nemluvim:-) Cili velmi rychle najdu chybu a najdu ji v dobe, kdy mam v hlavne kod, ktery ji zpusobil. Moje osobni (male) zkusenosti s Javou (imho opacna cast spektra) jsou takove, ze abych to otestoval (coz musim) musim to napsat skoro cele - pak najdu chybu a sledovat, proc a kde vlastne...podle me cas straveny ladenim bude podobny u obou pristupu.
Ja jsem neco vetsiho ve smalltalkoidnim jazyce ladil a celkem dost pohoda. Unittesty mi odchytili dost problemu velmi brzo. Naopak ladeni neceho mensiho v C++ bylo pro me peklo - takze bych negeralizoval.
Jak rika pan Krivanek - pri psani v jednom ci druhem jazyce se musi pouzit zasadne odlisny styl.
Pouziti daneho pristupu k programovani v tom "nespravenm" jazyce nutne vede na vyroky typu
"kazdy musi vedet, ze to je peklo." Proto
bych rekl. ze je presnejsi rici "ze tohle je pro me peklo" :-)))
