Názory k článku
Statická vs. dynamická typová kontrola

%subj%!!!! :?)

Byl jsem upozorněn na velmi zajímavý článek, který se (nejen) na tuto problematiku dívá očima autorů Pythonu.

http://www.py.cz/Members/honza/GuidoVanRossum

Skutečně stojí za přečtení.

Programator ma mit rozum a vzdy pocitat s tim,
ze se muze dostat mimo rozsah pole nebo promenne.
Slovem vzdy nemyslim for (int i=1; i<pole.length();i++).
Ale kdyz neco pocitam, v pocitaci musim mit prehled, zda vypocet nepretece. To bylo i od dob fortranu.

Je mi lito, ze se tak malo venujete Jave. Je to super elegantni jazyk. Jeste bych bral free prekladac a linker do nativniho kodu.

Ideální je, pokud se o to starat nemusí. Například pomocí konstrukcí typu foreach či do:. Neméně vhodné je, pokud čísla mají neomezený rozsah jako v některých dynamicky typovaných jazycích.

Hned máte o dva podstatné zdroje chyb méně.

GCC > 3.x? nevim presne od ktere verze je zahrnut javovsky JIT compiler, ale pokud si stahnes nejnovejsi 3.4 verzi, tak tam bude urite. existuje samozrejme i verze pro widle, pokud po ni touzis.

gcj bohuzel stale nema podporu pro graficke prvky Javy
Viz http://gcc.gnu.org/java/
AWT is currently unsupported, but work to implement it is in progress.
Tato hlaska tam je uz minimalne 3 roky.

mno gcj je uz trosku mimo dnesni javu, ktera je uz nekde uplne jinde :)). Nicmene licence pro klasickou sunovskou javu je hodne volna.

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í.

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.


ALE na maly projekt je asi rychlejsi pouzit PHP

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" :-)))

Možnost volby jsem u staticky typovaných jazyků jako výhodu uvést nezapomněl.

Článek se mi líbil, až se proberu, přečtu si jej ještě jednou.
Ale mám pocit, že jsem tam někde zahlédl překlep, "Samalltalku" by měl být spíš "Smalltalku", není-liž pravda?

Nová varianta Smalltalku pro programátory trpící samomluvou.

opraveno, dik

Dobry clanek, zaslouzi pochvalu.

Rad bych podporil nazor nekoho prede mnou, totiz ze nezalezi ani tak na jazyku, jako na programatorovi, jaky vysledny produkt bude. Jde o to pouzivat jazyk spravne a vytezit z nej maximum.

Ja sam jsem jeste pred rokem delal ve Smalltalku a dodnes na ne nej nedam dopustit. Nyni jsem C# a nemam pocit, ze bych si nejak pohorsil. Vyhrady, ktere k C# jsou dany spise nevyzralosti pomerne novych knihoven trid, nez jazykem samotnym.

Autor zjevně míchá bezpečnost jazyka (jakkoliv se mi toto vůbec nelíbí) a bezpečnost (resp nebezpečnost) při programování v beztypových jazycích. A tam je větší riziko, že se bude používat proměnná v jiném kontextu, vyšší. Nehledě na to, že kromě špatně odhalitelných chyb se mohou generovat například zbytečné převody číslo-řetězec-číslo ve smyčkách a podobně.

To všechno záleží na programátorovi. Beztypové jazyky tu jsou, jsou dobré, ale bankovní systém by s tím asi žádný tým nedělal. Mimochodem, v práci máme rozsáhlý IS napsaný v Perlu a funguje. Dělají na tom 3 lidé. Je to až k nevíře.

Zanášíte do toho problematiku slabého a silného typování. Bankovní systémy v dynamicky typovaných jazycích samozřejmě existují, např.

http://smalltalk.cincom.com/smalltalksuccess/index.ssp?id=1&langId=1&content=profile

Ale ve slabě typovaném Perlu skutečně asi ne.

Většinu problémů Perlu řeší use strict; a use warnings;.

Zdravim
Clanok sa mi velmi pacil. Programujem vo viacerych jazykoch (Java, PHP, C, C++, JavaScript (OO), troska Perl, TCL ...). Najviac je to v Jave a nemozem si vynachvalit vyvojarske prostredie Eclipse. Neviem ci by u slabo typovanych jazykoch bolo mozne spravit take developerske prostredie, kde by vam pocas pisania programu interaktivne podciarkovalo chyby (hlavne napr tykajuce sa statickeho typovania), doplnalo casti kodu (metody, premenne, ...), navrhovalo samo opravy (ktore su IMHO celkom k veci). Naviac si viem tazko predstavit aj taky refactoring, ktory je u velkych porjektov nutny - napriklad premenovanie a presuvanie objektov, metod, premennych a inych "veci". V Eclipse (Java) je refactoring nieco uzasne - kliknem napr na metodu v class-strome, dam si premenovat a v celom projekte mi to krasne poopravuje na 100% bez chyb. Pri dynamicky typovanych jazykoch by to bolo veru dost tazke.

Velmi sa tesim kedy uz vyjde Java 1.5 - tie genericke typy budu uzasne. A paci sa mi, ze aj PHP 5.0 sa bude dost podobat na Javu, hoci ostane slabo typovanym jazykom (co nechapem ako nieco zle).

Este spomeniem Perl - robil som v nom dost, a casto som ladil metodou pokus / omyl, niekedy som nad nejakou blbostou skoro ostarel. Proste Perl je pre mna hroza.

Este by som sa velmi chcel naucit Python, trosku som ho pozeral, je to cool, len potrebujem nejaku inspiraciu a cas.

Este troska Perl vs C (dufam ze nie offtopic) - dost dlho som potreboval nejaky HTTP proxy, ktory modifikuje stranky (iba prida script na popup okno). Verzia v Perli vyuzivaluca HTTP::Proxy fungovala dobre, ale narocnost na CPU bola neskutocna. Nakoniec som pouzil transproxy (napisane v C) a narast vykonu je mozno 100nasobny. Takze na top critical speed applikacie by som pouzival vylucne iba low-level programovacie jazyky.

Rad bych pripomnel, ze Refactoring a veskera
jeho podpora ve vyvojovem prostredi se poprve
(stejne jako Uinit testing) objevili prave v
prostredi smalltalku a je to uz dost davno.
Zatimco se vsichni vytahuji, ze jejich ide
ma refactoring. Smalltalkeri se jen usmivaji, nebot pro ne je to samozrejmost.
Naopak, co mi rikali lide
co delaji v eclipse, tak refactoring je tam proti
tomu co maji dnesni moderni smalltalky dost
slabej (ale osobne jsem to nevidel :-))

Tim nechci hanit eclipse, netbeans apod,
jen rikam, ze situace je presne opacna :-)

Přejděme od slov k činům:

ftp://comtalk.net/Squeak-dev.zip

Nejnovější verze Squeaku s Refactoring Browserem, SmallLintem, Monticellem, zvýrazňováním syntaxe včetně podtrhávání chybných výrazů, vyskakovacím doplňováním apod.

Mimo jiné to má i integrovaný VNC client/server pro ovládání a úpravu na pozadí běžících serverů.

Škoda, že neovládáte Smalltalk a jen stěží tak dokážete docenit, zač je toho loket.

(Je u toho přiložen virtuální stroj pro Linux a Win32, takže to stačí stáhnout a spustit VM se souborem *.image jako parametrem)

> Pri dynamicky typovanych jazykoch by to bolo
> veru dost tazke.

V dynamicky typovaném jazyce obvykle při refactoringu nemusíte přejmenovávat ;-)

Do Eclipse existuju pluginy aj na slabo-typovane jazyky. Napr PHP. Neskusal som ale moze to byt dobre ako pre Javu.

Osobne se mi spise vice libi IdeaJ, dokonce ma JetBrains sidlo tady v Praze. Ma jedinou nevyhodu, stoji 500$, ale 30 dni se da zadarmo zkouset.

a] pro dynamicky (to jste měl myslím na mysli pod pojem slabě) typované jazyky existují nádherná ide (např. Smalltalk/VisualWorks) umějící více (třeba refactoring) než Eclipse.

b] nástroje pro vizualizaci chyb týkajících se porušení statické typové kontroly v prostředích pro dynamicky typované jazyky nenajdete :)

c] -- není reakcí na váš příspěvek -- statická typová kontrola je pouze opravátor překlepů. No takový opravátor překlepů by byl výhodný. Jenže často jsou ty překlepy právě v kódu zajišťující staticou typovou kontrolu ....

Nedostatkem velke casti silne typovanych jazyku je to, ze zakazuje pouzivani programovacich konstrukci, ktere jsou naprosto korektni, jenom pro ne ve zvolenem typovem systemu neexistuje typ. Trivialni priklad v Haskellu:

\a -> (a a)

Semantika jasna, typovy system tomu nerozumi.

Domnivam se, ze podstatnou cast z vyhod, ktere prinasi staticke typovani jazyku, je mozne dosahnout v dynamickych jazycich pomoci programu typu 'lint', ktere checknou kod a nahlasi typove podezrele kontrukce.

tak tohle bych rekl ze je naprosto blby priklad pac tohle je lambda vyraz a tam se rekurze takhle resit neda... ;) (aspon teda pokud mne zrak nesali)
pokud to melo byt \a -> (a,a) tak to de ne?

Tohle samo o sobe zadnou rekurzi neobsahuje.

beta redukce na lambda vyraz
(\x -> (x x)) A
ti da
(A A)

Kde A je jakykoliv vyraz

Tudiz v netypovem lambda kalkulu je to naprosto korektni

no ale v haskelu je vyraz (a a) volanim funkce a s parametrem a... nebo se mylim? s tim lamba vyrazem souhlasim nicmene ja jsem to myslel (uznavam ze to asi nebylo jasne) jako lambda vyraz v haskellovske semantice

No ano - ten lambda vyraz dostane nejakou funkci jako argument a tu zavola a preda ji jako argument tu samou funkci. Tedy zadna rekurze tam nutne neni.

Nemylim-li se, tak Haskellovska semantika lambda vyrazu je snad v podstate stejna jako semantika v lambda kalkulu.

praveze ja bych rekl ze je... uz z logiky veci
pokud y f = f (y f) (operator pevneho bodu) je rekurze pak i to vase je rekurze pac je to vlastne uplne to same akoratze bez toho f (protoze lamba nema nazev pro funkci zeo) muzu se mylit ale ja to vidim takhle ;)
jinak - tohle nema s clankem nic moc spolecneho takze bych toho zanechal ;) kdyztak mail

Prilis nerozumim posledni vete v tretim odstavci od konce

"... Můžete se těšit z daleko bohatších dynamických možností vašich jazyků a z lepší podpory pro ladění a testování."

--

... jinak: kdyz uz je tu ten flame o IDE ... tak si taky prihreju:o)

... me oblibene IDE pro vsechno je: *emacs* a pro javu?: *emacs jdee*

Dynamicky typované jazyky umožňují většinou měnit program za běhu, stírá se u nich rozdíl mezi programem a daty, mohou vytvářet třídy a metody za běhu (pokud je mají), lze na nich budovat inkrementální systémy, můžete pracovat s nehotovým programem, ladit a testovat přímo během kódování, máte jednodušší prostředky pro automatizované testy a můžete využívat spoustu dalších užitečných drobností, se kterými se v emacsu nesetkáte.

omyl, emacs je jen sqely os, ktery ale bohuzel nema poradny editor, nejlepsi ide je vim ;)

A co treba takova typova inference ?

"...Existují studie, které se touto problematikou zabývají, a funkční projekty, které umožňují pomocí velice sofistikovaných postupů určovat typy smalltalkovských výrazů..."

Konkrétně např. http://typeinference.swiki.net/1

Studie na toto téma se objevují od roku 1983, kdy se Smalltalk dostal na veřejnost. Každopádně má svá principiální omezení a nelze ji použít vždy.

No chlapci, až sestoupíte z nadoblačných výšin kde se to prohání všemi možnými sofistikovanými jazyky koukněte se na Euphorii, http://www.rapideuphoria.com/, kupodivu se v tom dá taky programovat, a to docela dobře.

Tak jsem se pokusil trochu sestoupit.

Má zajímavou práci s typy. Nicméně nevidím na ní nic úchvatného. Pro výuku to může být zajímavý jazyk a určitě by mohl konkurovat Pascalu nebo Basicu, ale nic moc víc bych od ní neočekával. Z oněch nadoblačných výšin je vidět pár jazyků, které jsou jednodušší, mocnější a použitelnější. A není třeba si připlácet na debugger.