Díky za článek.

Jen si nemohu odpustit, k tomu přetypovávání objektů v php.

http://stackoverflow.com/a/3243949/1649965

Autor pravděpodobně uměl nejdřív skvěle PHP a pak začal s Javou. U mě je to naopak, takže (kdyby se mi to chtělo sepisovat) bych vyjmenoval 1000+ věcí, kde je PHP podle mě zfušovaný jazyk.

Často je to to spíš dané snahou řešit nějakou věc v Javě pomocí přístupu, který člověk používá v PHP (a naopak). Je to stejně jak s cizími jazyky: máte to anglicky dobře, ale angličan by to takhle neřekl :-)

Na okraj: zrovna jsem včera musel v PHP psát něco jako


$value = $this->validate($this->evaluateExpr($this->obtainParam("param")));


a fakt jsem byl rád za všechny ty $this. Ohromě to kód zpřehlednňuje ;-)

A mně sa zas líbí callbacky.

PHP:

$o = new Bar;
$callback = [$o, 'foo'];
$this->foobar($callback);

Java:

Bar o = new Bar;
IFoo a = new BarAdapter(o); //implements IFoo
foobar(a); //foobar(IFoo object);

V Javě potřebuju kvůli kvůli každému callbacku interface a třídu navíc.

Anebo už ne? :-)

Jen jestli se nedela nekdy z architektury tak trochu svatny gral. Jazyk je naprosto odsouzen na zaklade toho, ze nedodrzuje postupy, ktere jsou zrovna trendy. Ale co je skutecne dulezite? Je to efektivita vyvoje a kvalita vyslednych aplikaci. Bylo by zajimave porovnat webove aplikace v ruznych jazycich napriklad z hlediska rychlosti a ceny vyvoje, snadnosti jejich udrzby, jejich bezpecnosti a rychlosti.

Jinak si myslim, ze programovaci jazyky by se daly rozdelit do dvou skupin, ktere bych nazval treba skriptovaci jazyky a „enterprise“ jazyky. Skripovaci jazyky se vyznacuji velkou volnosti pro programatora, jsou casto beztypove, muzete snadno cokoliv zmenit, treba i predefinovat zakladni prikazy jazyka, jsou mene „ukecane“ nez „enterprise“ jazyky. Umoznuji byt kreativni a vymyslet ruzne efektni zkratky, snadno se uci (lua, php4). To je vyhodne, pokud aplikaci dela jeden programator a neni prilis velka (ale ja se domnivam, ze do teto kategorie spada nadpolovicni vetsina webovych aplikaci).
Pokud se jedna o velky projekt, na kterem pracuji cele tymy programatoru a dlouhodobe se intenzivne vyviji, tak se dost zasadne meni pravidla. Moznost cokoliv zmenit a resit to mnoha ruznymi zpusoby je kontraproduktivni a na dulezitosti ziskava dodrzovani presnych pravidel a postupu, omezeni, ktera mohou nebo musi byt zabudovana uz v jazyce.
PHP proslo vyvojem od sablonovaciho jazyka, kde i register globals melo mozna svuj smysl, ke komplexnimu proceduralnimu jazyku pouzivanemu na siroke spektrum webovych aplikaci ve verzi PHP4 az k „javovskemu“ objektovemu modelu PHP5 umoznujicimu vyvijet velke, snadno udrzovatelne aplikace.
Ale oba typy jazyka maji svuj smysl a podle me vzdy budou existovat oba druhy. I do javy tenhle skriptovaci pristup mozna pronika prostrednictvim veci jako je scala (o jave moc nevim, takze se omlouvam, jestli kecam blbosti)

Hovorit, ze PHP je lepsie ako Java za to, ze v Jave sa multivlaknovost pouzivat MOZE, ale v PHP to nejde je pri najmensom smiesne. V tom je prave ta sila Javy.
P.S.
Momentalne pracujem v Jave, ale v PHP pracujem dlhsie a pracuje sa mi v nom lepsie. Mal som len velke vyhrady k tomuto konkretnemu bodu.

Flamewar Java vs. PHP je v dnešní době tak trošku zbytečná, ne? Divím se, kolik lidí se tu na to ještě chytlo. Je to stejně hloupé, jako by bylo hašteření Cobol vs. Fortran nebo Perl vs. Pascal. Nebo možná rovnou parní stroj vs. vodní kolo.

Ať si každý píše v čem chce, je to jeho věc, z velké části daná tím, jakou aplikaci a v jakém kontextu vůbec chce psát. Že je Java i PHP plná nesmyslných konstrukcí je dané dobou jejich vzniku, dlouhou historií a nutností zachovat jakousi zpětnou kompatibilitu. Vývoj dnes probíhá jinde a místo stokrát přemletého nostalgické mektání bych si rád přečetl raději něco jako „Go vs. Swift“, kde opravdu můžeme kritizovat blbě navržená místa a podivovat se, jak autoři jazyka uvažovali.

V prvé řadě chci poděkovat za zajímavý článek, který se seriózně pokusil o téma obvykle vyvolávající flame – a myslím, že úspěšně. Jako u každého názoru jsou zde věci, se kterými souhlasím (equals), se kterými už méně (kompilovatelnost), ale je tu jedna věc, která si, myslím, zaslouží upřesnění – a tou je část o vláknech a synchronizacích.

Je potřeba uvědomit, že paralelismus je obtížný. Paralelismus není o pár klíčových slovech navíc, není to o dalších algoritmech, které se člověk musí naučit nazpaměť – je to o novém způsobu uvažování. Relativní jednoduchost a spousta jistot sekvenčního přístupu je pryč. Prokládané výstupy, nedeterminismus běhu programu (s tím spojené obtížné debugování), deadlocky a race condition jsou běžnými a netriviálními problémy. Nastupuje potřeba synchronizovat, díky které lze tyto problémy řešit (či obejít). A to ideálně ne moc, aby nakonec z paralelního programu nebyl sekvenční. Z těchto důvodů, když učíme programování, tak se vyhýbáme paralelismu jako čert kříži – na paralelismus (a distribuované systémy) máme samostatné předměty a dokonce i obor (FI MUNI).

Z toho důvodu je potřeba konstatovat, že díky možnosti pouze jednovlákovému zpracování se PHP vyhnulo velké spoustě problémů, které by bylo potřeba jinak řešit – a které Java řešit musí. A Java to řeší nejen jednoduchými (nízkoúrovňovými) synchronizačními primitivy – mutexy, podmínkovými proměnnými, synchronized. Je nad tím postaveno spoustu tříd – synchronized kolekce, thread pooly, a i ve článku zmíněné Futures – díky kterým lze psát i vysokoúrovňově. Na druhou stranu kvůli snaze synchronizovat co nejméně je občas dostačující (a mnohdy i vhodné) používat i nízkoúrovňové konstrukce – proč nepoužít atomické počítadlo nebo kritickou sekci, pokud mi bude stačit?

Pokud na úlohu stačí sekvenční program, je vhodné ho tak napsat. Paralelismus se dá dělat i na úrovni programů, kdy jeden a ten samý sekvenční program dělá jasně oddělenou část úlohy (*) – příkladem budiž třeba paralelní konverze obrázků či videí – a to lze jak v PHP, tak v Javě. Pokud je však potřeba složitějšího přístupu, tak je potřeba se smířit se synchronizačními možnostmi, které jazyk poskytuje – a ty jsou v Javě jak na nízkoúrovňové, tak vysokoúrovňové.

(*) Takovéto úlohy se nazývají „embarrassingly parallel„.

Prosim :)tučný text

Javě jsem se věnoval už docela dost, i když se teď zabývám C#. Dovolil bych si přidat ke článku pár svých připomínek.

Používání this

Používání this (a super) je good practice. Netřeba měnit návyky.

Hodnota null

Jmenuje se to Null Object Pattern. V OOP standard.

Kompilace Regex

Regex nikdy není ideální volbou pro operace náročné na výkon.

Inicializace polí a map

V Javě žádný zmatek okolo kolekcí není, Java Collection Framework má jednoznačnou strukturu. Pole se využívají primárně pro případy, kdy je výkon kritický. Zvláštní je, že zrovna syntaktický cukr okolo EntrySet vám připadne jako důležitý rozdíl mezi Javou a PHP. Přitom PHP žádný vestavěný ekvivalent HashMap s konstantním přístupovým časem nemá.

Instanceof

Nevím, jak máte nastavené prostředí, ale dobře to asi nebude. Následující kód se na JDK 1.8 bez problémů zkompiluje. Dále doufám, že rozdíl mezi staicky a dynamicky typovaným jazykem vám ve škole zvládli vysvětlit.

public class Havran
{
    public Havran(Integer integer)
    {
        if (integer instanceof Integer)
            Vrana(integer);
    }

    public void Vrana(Integer integer)
    {}
}

Runtime optimalizace

Můžete mi vysvětlit, jak by asi fungovalo runtime optimalizace kódu v ve fázi kompilace? Něco jako super.getCrystalSphereWithAI().optimizeUntilAwesome()?

import *

Pokud se mi sejdou dvě stejné závislosti, musím je od sebe odlišit. Ne problema ani v „seriózních“ projektech.

Multithreading

Tady už si snad děláte legraci. Absence důležité vlastnosti jazyka je pro vás výhodou? Navíc reálný web server, který by neuměl pracovat vícevláknově, mi není znám.

Závěr

Tvůrci jazyka Java nemají „štastnější ruku“, ale JCP a JSR.

Píšete jen o kompilaci do bytekódu, ale bytekód se narozdíl od php neinterpretuje ale dál překládá pomocí JIT do binarky, to dělá Javu oproti PHP mnohem rychlejší. Mimochodem FB si kvůli tomu nedostatku udělal vlastní VM s JIT pro PHP. Dá se tedy říct, že to největší nasazení PHP se inspirovalo z kvalitne navržené Javy :-)

No nedokážu pochopit, jak někdo může tvrdit, že radši bude všechno dělat v jednom vláknu. Nemám nic proti autorovi, zbytek článku mi přijde vtipně a celkem fajn podaný, ale to zmínka o vláknech, to se jako autor tak moc „vodvázal“ až si prostě řekl, no tak co bych ještě neshodili.NE NE a NE, někdo kdo nemá ponětí o efektivním využití zdrojů nemá co kecat do vláken, za mě velké nepochopení. Jsem rozhořčen. Čus