Vlákno názorů k článku
Java na webovém serveru: porovnání Javy a PHP

> Java je staticky typovaný jazyk – všechny proměnné musíme deklarovat včetně jejich typu

Ne, staticky typovaný jazyk se vyznačuje tím, že se typy kontrolují v době kompilace. A Java je staticky i dynamicky typovaná (ne všechny typy umí ověřit v době kompilace).

Také by stálo za to říci, co je to typ.

> Silné typování znamená, že jazyk kontroluje typy proměnných za běhu a odhaluje jejich chybné použití. Java je silně typovaný jazyk. PHP slabě typovaný.

A PHP nekontroluje typy proměnných za běhu? Ale kontroluje a v případě potřeby provede implicitní přetypování, tomu se říká slabé typování. V podstatě každý jazyk, který někdy dělá implicitní přetypování je slabě typovaný. Silné typování nemá nic společného s kontrolou typů za běhu.

> Zdrojový kód napsaný programátorem není možné interpretovat

Možné to asi bude ;-)

> Můžeme „sčítat“ čísla a znaky, ale výsledek asi není to, co bychom očekávali.

Jenže nesčítáte číslo a znaky, ale číslo a adresu, přirozeně je výsledkem číslo.

„Jenže nesčítáte číslo a znaky, ale číslo a adresu, přirozeně je výsledkem číslo.“
Výsledkem je spíše adresa, to se používá ke trikům typu first++ apod. Konverze je tady v tom, že umožňuje automaticky konvertovat adresu na číslo.

Java je silně typovaná proto, že:
* neumožňuje udělat konverzi násilím s z toho vyplývajícím nedefinovaným chováním
* zřejmě neumožňuje provést jakoukoli potenciálně ztrátovou konverzi bez explicitního požadavku
* neumožňuje provést potenciálně neproveditelnou (zde tzn. hrozí ClassCastException) konverzi bez explicitního požadavku

> Java je silně typovaná proto, že … (zde tzn. hrozí ClassCastExcep­tion) …

Ale ta výjimka bude vyhozena až za běhu (kompilátor na to nepřijde), tedy dynamické typování. Dle mého soudu nezáleží na tom, jestli to musím přetypovat explicitně, ale záleží na tom, že typová chyba nastane za běhu.

Aha, koukám, že reaguju na „Java je silně“ a ne na „Java je staticky“

Ale silně také není protože má implicitní přetypování, silně = bez implicitního přetypování.

Houby dynamické typování. Dynamicky je zjištěno, zda je přetypování správné, protože jinak to nejde.
Programátor v takovém musí explicitně uvést že a na co chce přetypovat.
Tedy, když už to jinak nejde, programátor se může s vědomím* jedné dynamické kontroly rozhodnout explicitně přetypovat.

*) Pokud o tom neví, tak si IMHO nezaslouží označení programátor.

> Dynamicky je zjištěno, zda je přetypování správné, protože jinak to nejde.

Jak jste přišel na to, že to jinak nejde?

> Tedy, když už to jinak nejde, programátor se může s vědomím* jedné dynamické kontroly rozhodnout explicitně přetypovat.

A tím je typová bezpečnost ztracena. Jelikož kompilátor není schopen ověřit typy (což je statické typování), tak jazyk není (čistě) statický. Java je statická i dynamická.

Jinak to nejde, protože za určitých podmínek může nastat kterákoli možnost.

Dobře, Java je převážně statická a pokud se to programátorovi hodí, může se místy na požádání chovat dynamicky.

> Jinak to nejde, protože za určitých podmínek může nastat kterákoli možnost.

Pokud může být návratová hodnota typu Int nebo String, pak bych vracel něco, co je ve funkcionálních jazycích známo jako součtový typ.

Kdybychom měli silnější typové systémy, tak bychom se mohli zbavit mnoha nebezpečných přetypování. Vždyť existují takové jazyky, kde úspěšná typová kontrola implikuje korektnost programu.

Takové jazyky rozhodně neexistují, už proto, že stoprocentně statická typová kontrola je ekvivalentní problému zastavení (a je tedy nerozhodnutelná) :-) Takže staticky typované jazyky samozřejmě mají dynamickou typovou kontrolu, a označují se za staticky typované právě proto, že mají i tu statickou.

Ale naprosto souhlasím s potřebou silnějších (statických) typových systémů – dnešní běžné objektové jazyky (Java, C#) jsou na tom fakt mizerně (jak je na tom Scala nevím, zatím se mi ji nechce moc zkoumat, na můj vkus to vypadá jako strašný akademický slepenec).

V čem je na tom Java mizerně? Pravda, nemá type inference (pro pohodlí) a někdy je potřeba přetypovat (metody typu clone()), ale až tak špatné to IMHO není.

Tak absencí typové inference to začíná (úplně by mi stačila ta lokální), pak tu jsou takové věci jako reference na metody (.NET má, i když na můj vkus trochu divné), typové parametry přístupné za běhu ( new T(), .NET tuším má) a vůbec pořádné generiky ala Ada, nullable typy (.NET má, v Javě 7 se to tuším bude dát ošvindlovat přes anotace na typech), součtové typy, bezpečné přetypování (jazyková konstrukce pro if (obj instanceof Clazz) { Clazz aObj = (Clazz) obj; ... }), MyType ( like Current z Eiffelu), a když se rozšoupnu, tak třeba ještě pattern matching, rozšiřující metody, líně vyhodnocované typy nebo strukturní ekvivalence namísto jmenné. Zdaleka neříkám, že tohle všechno chci v Javě, to bych se musel zbláznit :-), ale dost z toho mi pekelně často chybí (hlavně pořádné generiky a nullable typy/součtové ty­py).

inference: souhlas, právě se pohlížím po Duby.
genericita: IMHO je čistější použít Factory. Nevím proč, ale celkově mi to nějak spíše vyhovuje. Už jsem měl potřebu používat instanceof (dobře, v ObjectPascalu se to pro rozhraní jmenuje supports), ale to jde obejít předáním Class. Za určitých podmínek zde jde použít to málo type inference, co Java zatím má.
nullable: Jo, to by se mi líbilo.
bezpečné přetypování: Taky jsem o tom snil.
Ke konci už přestávám rozumět.
Líně vyhodnocované typy jsou IMHO spíš knihovní záležitostí než jazykovou (aspoň v podání Javy).

V Javě jde spousta věcí implementovat jako knihovna, ale zároveň je to v Javě hrozně problematické. Níže v diskusi zmiňujete lexikální uzávěry, což je například jedna z naprosto klíčových vlastností jazyka. Java má téměř plnohodnotné uzávěry od verze 1.1, kdy přibyly anonymní vnitřní třídy – jenže je to syntakticky tak odporné, že se to používá mnohem míň, než by mělo. Proto třeba v Javě 7 bude Automatic Resource Management, což je věc triviálně implementovatelná pomocí uzávěrů. Spousta jiných jazyků takové problémy nemá a knihovní řešení ledasjakých problémů naprosto vyhovuje – Java bohužel není ten případ.

> Takové jazyky rozhodně neexistují, už proto, že stoprocentně statická typová kontrola je ekvivalentní problému zastavení (a je tedy nerozhodnutelná) :-)

Ale já nikde nepsal, že ten jazyk bude ekvivalentní částečně rekurzivním funkcím :-) Ono to často ani není potřeba a stačí obecně rekurzivní funkce.

Podívejte se třeba na jazyk Epigram nebo Agda, to jsou staticky typované jazyky (a existují i další). Navíc je typový systém tak silný, že umožňuje kódovat libovolné výroky z predikátové logiky, takže když vhodně zapíšete typy, tak vám kompilace zaručí parciálně korektní program (vzhledem k typům). Epigram dovolí jen obecně rek. funkce a Agda zase umí kontrolovat to, že program skončí (resp. když to nevidí, tak vás varuje abyste program mohl přepsat tak, že to bude vidět; je pravda, že tam se ta konečnost nevynucuje).

> Takže staticky typované jazyky samozřejmě mají dynamickou typovou kontrolu, a označují se za staticky typované právě proto, že mají i tu statickou.

Tahle definice je dost častá, ale přijde mi divná. Představte si, že budu v jazyce provádět drobnou statickou kontrolu, že když uvidím dvě konstanty a mezi nimi operátor +, tak zahlásím chybu pokud oboje nejsou čísla, tedy už provádím statickou kontrolu typů. Znamená to, že jazyk je staticky typovaný?

Ta definice je častá asi proto, že je užitečná :-) To zavedení jediné statické kontroly může být klidně dost výhodné, ale za statický typový systém bych to fakt nepovažoval. Tohle už je teda podle mne čisté slovíčkaření, ale můj skromný názor je: typový systém je od toho typovým systémem, že kontroluje typy všech výrazů. Že je staticky nemůže zvládnout zkontrolovat stoprocentně už jsme si řekli, že zůstávají díry, které by staticky vyřešit šly, to se bohužel taky děje, ale takový už je holt svět :-)

Právě, že ta moje definice mi přijde užitečnější. Takové jazyky existují a odlišují se od ostatních vyšší bezpečností.

Výhodou mých definic je, že jsou jasné.

> Že je staticky nemůže zvládnout zkontrolovat stoprocentně už jsme si řekli …

Není problém udělat to, že když něco neumím staticky zkontrolovat, tak to prohlásím za chybu. Tím už v době překladu zaručím typovou bezpečnost.

Vaše definice jsou jasné, ale v mainstreamu programovacích jazyků nepoužitelné :-) Mezi statickou typovou bezpečností třeba Ady, Javy a PHP jsou obrovské rozdíly – ale vy byste je klidně šmahem hodil do jednoho pytle. To já tedy za užitečné nepovažuju :-)

Jinak, protože ve vyčíslitelnosti se nevyznám, zeptám se: když budeme uvažovat nějaký pořádný statický typový systém, o jak velkou třídu programů přijdeme, když nezkontrolovatelné věci prohlásíme za chybu? Čistě ze zájmu, já fakt nevím, ale odhaduju, že malá nebude.

> Jinak, protože ve vyčíslitelnosti se nevyznám, zeptám se: když budeme uvažovat nějaký pořádný statický typový systém, o jak velkou třídu programů přijdeme, když nezkontrolovatelné věci prohlásíme za chybu? Čistě ze zájmu, já fakt nevím, ale odhaduju, že malá nebude.

Pokud si vystačíme s částečnou korektností programů (program nemusí skončit), tak z hlediska vyčíslitelnosti o nic nepřicházím*, protože stále tam mohu naprogramovat třeba rekurzivní funkce (s typy nebude problém, neboť mi stačí přirozená čísla) nebo odsimulovat Turingův stroj.

Pokud požadujeme i konečnost programů, tak tam už se omezujeme na obecně rekurzivní funkce, a to navíc ty, o kterých to umíme dokázat (resp. typechecker s naší pomocí). Tady už samozřejmě přicházíme o velkou třídu programů, ale myslím si, že v praxi je velmi často žádoucí, když víme, že program pro konečný vstup skončí.

* Pokud bych předpokládal, že má počítač neomezenou paměť.

Vzdali ste to moc rychlo. Java nema dynamicke typy (napr .Net ma). Java JE STATICKY, SILNE TYPOVY jazyk. Keby bola dynamicky typovy, znamenalo by to ze premenne nemaju typ. Ano umoznuje pretypovanie ale podla definicie je podobne ako napriklad C++ staticky typovy jazyk.
Zo slovickami a moznostami sa mozete hrat ale definicia je definicia.

I v PHP proměnné mají typ, jen je určen za běhu. Podobně .NET.

Podle mě je C++ staticky i dynamicky typované. Napište sem tu Vaši definici statického a dynamického typování.

Moje je: Jazyk je (čistě) staticky typovaný, pokud typy kontroluje kompilátor a za běhu již nemůže nastat typová chyba. To znamená, že pokud se program zkompiluje, tak už typová chyba nenastane. Jazyk je dynamicky typovaný, pokud se typy kontrolují až při běhu programu, a tedy může nastat typová chyba za běhu.

> Keby bola dynamicky typovy, znamenalo by to ze premenne nemaju typ.

V dynamicky typovaném jazyce proměnné mají typy (to plyne z toho, že je typovaný).

Skuste relevantne zdroje v najhorsom pripade odporucam wikipediu. Mozte mi povedat priklad objektoveho staticky typovenaho jazyka podla vasej definicie? Taky neexistuje. V praxi su totiz niektore veci potrebne a preto kazdy jazyk obsahuje taketo nebezpecne konstrukcie.
Tieto pojmy sa pouzivaju uz dlhe roky a kazdy rozumie ze staticky typovany jazyk je na 99% staticky. Dokonca Java aj 100% ak nepouzivate explicit type casting co sa dnes vdaka generickym typom listin da velmi lahko dosiahnut.

> V dynamicky typovaném jazyce proměnné mají typy (to plyne z toho, že je typovaný).
Nie nemaju, nemylte si typ premennej s tym na co odkazuje. V dynamickych jazykoch rovnaka premenna moze odkazovat na rozne „hodnoty“ ktore maju typ.

Zbytocne si tu ale vymyslate pojmy a zbytocne ich krutite. Tak ako som napisal – Java JE STATICKY SILNE TYPOVY jazyk. PHP je dynamicky jazyk. By definition.

> Skuste relevantne zdroje v najhorsom pripade odporucam wikipediu. Mozte mi povedat priklad objektoveho staticky typovenaho jazyka podla vasej definicie? Taky neexistuje. V praxi su totiz niektore veci potrebne a preto kazdy jazyk obsahuje taketo nebezpecne konstrukcie.

Definujte prosím, co podle Vás znamená objektový jazyk.

> Tieto pojmy sa pouzivaju uz dlhe roky a kazdy rozumie ze staticky typovany jazyk je na 99% staticky.

Každý evidentně ne.

> Dokonca Java aj 100% ak nepouzivate explicit type casting co sa dnes vdaka generickym typom listin da velmi lahko dosiahnut.

Ale bohužel to přetypování v tom jazyce je.

> Nie nemaju, nemylte si typ premennej s tym na co odkazuje. V dynamickych jazykoch rovnaka premenna moze odkazovat na rozne „hodnoty“ ktore maju typ.

Dobře. Nicméně, nevidím důvod, proč by typ proměnné nemohl být definován jako typ hodnoty.

> Zbytocne si tu ale vymyslate pojmy a zbytocne ich krutite. Tak ako som napisal – Java JE STATICKY SILNE TYPOVY jazyk. PHP je dynamicky jazyk. By definition.

Tak mi sem dejte definici pojmů: silně typovaný, staticky typovaný a dynamicky typovaný.

Já si pod silně typovaným jazykem představím jazyk, který nepoužívá implicitní přetypování.

Přetypování v jazyce stále je:
* z historických důvodů
* kvůli speciálním použitím (např. metoda clone())

Přetypování v bytecode (instrukce checkcast) je navíc i kvůli genericitě.

> * kvůli speciálním použitím (např. metoda clone())

Kovariantní změny v typu návratových hodnot metod v podtřídách jsou bezpečné, takže není důvod přetypovávat z Objectu, když se může vrátit přímo to, co klonuji.

> * z historických důvodů

To je docela dobrý důvod, ale myslím si, že už např. v době vzniku Javy se mohlo mnoha problémům předejít, kdyby se tam udělal silnější typový systém rovnou (teď se mi to mluví :-)).

Dobře, nejen clone. Existují i další příklady:
* equals(Object)
* Mám GUI na zobrazení/editaci a chci umožnit zobrazit toho u potomka víc.
* s jedním dosti specifickým případem jsem se také setkal, ale nechce se mi popisovat souvislosti

V mnoha případech by pomohly typové třídy jako mají funkcionální jazyky, konkrétně třeba typy podporující rovnost jsou v Haskellu instancemi třídy Eq.

Pro OOP jazyky už je to horší. Resp. pokud dovolíte změnu typu parametru equal, tak už dědičnost neprodukuje podtypy.

> Přetypování v bytecode (instrukce checkcast) je navíc i kvůli genericitě.

Když by to udělali jako v CLR, tak by to taky nepotřebovali.

Tam, popravdě, nevím, jak to je.

„Moje je: Jazyk je (čistě) staticky typovaný…“

Podle téhle definice by staticky typovaný jazyk byl dost na nic, protože by v něm nešlo napsat např. následující konstrukci:

Object o = …;
if (o instanceof Opice) {
    Opice op = (Opice)o;
    //TODO: dělej něco s opicí…
} else {
    //TODO: dělej něco s objektem
}

Případně by kompilátor musel rozumět všem těm podmínkám a kontrolám (instanceof), které programátor provádí a na základě nich si říct, že přetypování je možné – jenže ty kontroly mohou být daleko složitější, takže se obávám, že žádný tak chytrý kompilátor neexistují – „typovou chybu“ za běhu tedy nelze nikdy zcela vyloučit, ale důležité je, že např. tupě nevezme ten kus paměti, kam daný pointer ukazuje a nesnaží se ty bajty z paměti interpretovat jako jiný ty, než jaký to je (místo toho dojde k běhové výjimce).

> Podle téhle definice by staticky typovaný jazyk byl dost na nic, protože by v něm nešlo napsat např. následující konstrukci

Konkrétně s touto definicí není problém, ne? Protože to přetypování provádíte ve větvi, kde už je ten typ zřejmý a typová chyba nenastane (ano předpokládám, že se mezitím o nezmění).

Podobnou analýzu dělá třeba kompilátor jazyka Mercury. Samozřejmě kompilátor není úplně nejchytřejší a třeba konstrukci

if a > 10 then ...
else if a <= 10 then ...

vám neuzná (vynucuje se pokrytí všech možností), protože nevidí, že jiná možnost nenastává a je třeba ji změnit na

if a > 10 then ...
else ...

kde už je zřejmé, že jsou všechny případy pokryty.

Podobné je to při dokazování vět nebo algoritmů na počítači, kde ten dokazovací systém často něco nevidí a je třeba to prostě rozepsat.

„ano předpokládám, že se mezitím o nezmění“

Což neplatný předpoklad, protože hodnotu proměnné může změnit třeba jiné vlákno běžící současně a to kompilátor nikdy neodhadne.

V Javě je toto neplatný předpoklad, ale v čistě funkcionálních jazycích je platný.