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

Ten slabě typovaný příklad není zvolen moc šťastně.

Tak zaprvé, stačí do toho printf místi %d dát %s a výsledek bude korektní (za předpokladu, že ten integer bude třeba 2).

A navíc pro Javu je taktéž definovaná operace sčítání mezi stringem a integerem (i když s jinou sémantikou). To z jazyka ještě nedělá slabě typovaný.

Slabě typovaný je ten, jehož překladač/inter­pretr dělá ad hoc konverze typů tak, aby to explicitně nemusel dělat programátor. Třeba céčko skoro pokaždé převede pole na ukazatel na první prvek.

Ono statické a slabé typování opravdu nejde moc dohromady, takže někteří autoři dokonce žádné ortogonální rozdělení slabého/silného + statického/dy­namického typování nezavádí a říkají, že existují typové systémy statické, dynamické silné a dynamické slabé. Tuším, že jsem to takhle četl v Programming Language Pragmatics, ale nejsem si teď jistý. Každopádně jestli existuje nějaký staticky a slabě typovaný jazyk, pak je to Céčko :-)

long a = 1000*1000*100­0*1000;
(a má nyní hodnotu –727379968)

Silné typování mi proto připadá spíš jako falešný pocit bezpečí. U toho PHP aspoň člověk od začátku ví, na čem je.

silne typovanie je predsa o tom, ze do toho longu nepriradis string, nie aku hodnotu tam (ne)priradis

Je to jen banální příklad implicitní konverze int->long, způsobující nepříjemnou chybu, která se navíc projeví pouze v závislosti na konkrétních hodnotách proměnných, a to až za běhu programu, nikoliv při kompilaci.

Chyba bude i v tomto případě (int->float) úplně stejná:

int b = 1000;
float a = b*b*b*b;
(a má nyní hodnotu –7.2737997E8)

Tím chci říct jen to, že každý kód je potřeba testovat, a jakékoliv spoléhání na kontroly překladače (‚je to přece silně typované, tak je to bezpečné‘) se může vymstít.

„Tím chci říct jen to, že každý kód je potřeba testovat, a jakékoliv spoléhání na kontroly překladače (‚je to přece silně typované, tak je to bezpečné‘) se může vymstít.“

Nepochybně, ale silné typování pomáhá mimo jiné:
* chyby najít co nejdříve
* vhodně napovídat metody apod.
* popřemýšlet nad správným návrhem (občas lehce „kopne“ správným směrem)
* refaktorovat kód
* dokumentovat (u slabého typování to můžete uvést tak leda do poznámek, ale nezískáváte tím jiné výhody)
* při odstranění třídy, metody(, …) zjistit, že je stále používána

Není sice všelékem, ale je celkem užitečné a příjemné. Ano, dobrý programátor by IMHO měl zvládnout používat oboje. Stejnětak by IMHO měl dobrý programátor zvládnout programovat bez IDE. Ale pokud chce být maximálně produktivní, pak pro to nevidím důvod.

Menna a typova kontrola je k nezaplateniu. Naviac slabsim programatorom pomaha v niecom comu ja hovorim „Coding by accident“. Napisem nejaku premennu, dam bodku a potom hladam v zozname co by sa najviac hodilo ;-).
Dobry priklad je ale odstranenie metody. Ak to urobim v Jave a da sa to skompilovat tak na 95% je to uz funkcne. Ked urobim to iste v PHP tak preklikavate cely system?

„Ked urobim to iste v PHP tak preklikavate cely system?“

V případě TDD je to trochu přehnané, ale pokud testy z nějakého důvodu nejsou, pak asi není moc jiných cest.

Samozřejmě, i v Javě je Reflection API, já to používám velmi výjimečně (radši mám zpracování anotací pomocí handlerů typu http://projectlombok.org) a třeba ve čtvrt mega zdrojácích se nemusí objevit jediné jeho použití. Všechna použití si pamatuju* (nepočítám nějaké debugovací použití typu getClass().get­Name() apod., což by vadit nemělo), protože každé potenciálně problematické použití předem důkladně zvažuju. V J2ME na místech, kde mám uvést jméno třídy jako String, používám konstrukci MyClass.class­.getName(). Pak se již jistota, že to bude po odstranění oné metody funkční, blíží 100%.

*) Samozřejmě že v projektech, na kterých se podílí více lidí, toto patří do dokumentace.

Hmm, tak to je jako rict, ze jedinou jistotu kterou mate je, ze zadnou jistotu nemate ;-)