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

To jste to dnes poněkud odfláknul.

Co třeba tato témata:

– ukecanost. U PHP stačí nahrát jeden soubor .php a kód se provede. Javu je potřeba složitě nastavovat a ztrácet se ve změti xml
- rozšířenost. Na většinu serverů stačí php nahrát a jede to (PHP je de facto standard)
- rychlost vývoje. Pořádaly se různé závody jazyků (jedno zadání, lidé současně vystartují a měří se čas do výsledku) a Java na tom nebyla moc dobře (je ukecaná)
- podpora IDE. Java má spoustu geniálních IDE s podporou refaktoringu a dalších vlastností, PHP nemá nic pokročilého, protože to z principu jazyka tak hezky nelze
- frameworky pro web
- ORM

atd. atd.

Lze o tom vykládat hodiny a hodiny, to co jste v článku předvedl je bohužel hodně o ničem.

Já takovéto závody v bastlení považuju za naprosto irelevantní. Většina aplikací se udržuje delší dobu, nikdy není napoprvé bez chyb atd.

Java je „ukecaná“, Perl zase umí být extrémně kompaktní (a neudržovatelný). Já za rozumný kompromis pro web považuji Python nebo Ruby.

PHP jako jazyk nesnáším, protože je to fatk ošklivý bastl. Jenže ta dostupnost hostingů a všelijakých těch Drupalů je dost silný argument. Java je rigidní, ale zase má vynikající spolehlivost, možnost refaktoringu (podpora IDE). A tak bych mohl pokračovat u každé myslitelné technologie.

přesně tak

méně kódu == méně chyb
méně kódu == méně kódu, který je nutný refaktorovat a udržovat

Budu-li mít dva velmi podobné jazyky, jeden z nich bude méně ukecaný, je apriori lepší.

PHP je bastl jen pro ty, co v něm neumí psát čistý kód. Nutnost „babrat se v problémech PHP“ je věc, na kterou kvalitní vývojář v PHP narazí tak jednou za několik týdnů a většinou ji vyřeší za 1 minutu díky skvělému PHP manuálu. :)

Ad závody v bastlení – skoro bych se vsadil, že i dobře navržený kód, pokrytý unit testy bude v PHP napsaný dřív, než v Javě.

No jo. Ale projekty kde 10tky az 100vky developerov koduju jeden system niekolko rokov by sa v PHP asi nezvladli. Takze interpoloaciou dojdeme k tomu ze mozno na mensie projekty je PHP v poriadku ale ako vam rastie projekt a komplexnost tak aj uroven bastlenia prerasta nad znesitelnu hranicu.
Nechcem sa hadat, nepoznam PHP natolko dobre ale pokial viem tak pred par rokmi ked sme mi uz prevadzkovali enterprise systemy na Jave tak PHP este malo problem s poolovanim spojenia do databazy. Nehovorim o servroch, nastavovaniach, clustroch, session fail-over, … a podobne. Myslim ze porovnavat akykolvek PHP server s BEA pripadne IBM Java servrami a ich moznostami straca akykolvek zmysel. Bohuzial vacsinu vlastnosti tychto servroch si skutocny zivot vyzaduje.

Nech je Java akokolvek ukecana je ENTERPRISE a skutocne riesit velke napr. bankove systemy na PHP si neviem dost dobre predstavit.

Nevím, co považujete za Enterprise, my tu na PHP vyvíjíme např. řešení s 1 150 000 UIP měsíčně, škálujeme na serverech Amazonu a kód je pokrytý > 1000 unit testy o testy Seleniem ani nemluvě.

To je řešení, které přesahuje, řekl bych, většinu nasazení Javy na webu.

Java je stejně Enterprise jako třeba Cobol nebo Fortran. A já si Cobol ani Fortran neumím představit skoro na nic, to bych pro bankovní aplikace mnohem radši použil to PHP. :))

Takže to že to zvládá tolik lidí není kvůli PHP ale díky Amazonu. Nevidím důvod proč nemít aplikaci pokrytou unit testy a selenium testy.

Stejně tak není problém mít Java aplikaci dobře škálující. Navíc je tu výhoda podpory od Googlu, například GWT.

GWT je ta výhoda, kterou Java má oproti jiným jazykům. Pokud potřebujete v projektu napsat jak server část, tak i část HTML/CSS/JS, tak díky GWT nemusíte opustit Javu, ale v klidu to v ní napsat. Ušetříte hromadu času a výsledné řešení bude lépe udržovatelné.

Co to je za hloupost? Když bude aplikace špatně napsaná nebo jazyk pomalý, neuškáluje ji ani 100 Amazoních instancí. Takhle je to dost výkonné, že by to teoreticky utáhl jeden výkonný (tím myslím „žádná domácí skládačka“) server.

Když je aplikace špatně napsaná, tak má velmi pravděpodobně jistý limit kam může škálovat. Ale škálovat může, například vertikálně. Pokud je jazyk pomalý, tak je to jedno. Bude vás to stát víc peněz, víc počítačů ale možná těch 1 mil UIP dáte.

U horizontálního škálování jde o dvě věci, první zda používáte sessions. Pokud ano, má vaše aplikace dozajista limity. Druhá věc jak vypadá vaše datové úložiště. Dá se rozdělit na více serverů? Více zapisujících nebo jenom čtecích apod.

Pěkný příklad toho, že na jazyku nezáleží podává Facebook. I když už tak přemýšlí, jak jazyk zrychlit. Stojí to peníze. Stejně tak Twitter, odešel od Ruby když už servery byly dražší než práce programátora a přešel na Scalu, tak aby zlevnil svůj provoz. Opravdu to je, jen a jen o penězích, kolik serverů jste ochotni platit.

Je dobře, že vaše aplikace je výkonná – dobře napsaná. Nicméně váš první příspěvek mluvil o tom, že škálujete na Amazonu. Z toho jsem usoudil, že využívá vyrovnávání zátěže podle aktuální návštěvnosti a zvyšuje či snižuje počet zapojených serverů. Protože o tom, škálování je.

BTW, Scala jede na platformě Java a má podobný výkon. (Například o dynamickém Groovy* se to říct nedá.)

*) nemyslím experiment Groovy++

> Stejně tak Twitter, odešel od Ruby když už servery byly dražší
> než práce programátora a přešel na Scalu, tak aby zlevnil svůj provoz.

V kontextu debaty je to sice lhostejné, ale Twitter „neodešel“ od Ruby. To je poněkud nešťastné a reduktivní shrnutí jednoho z nejzajímavějších „incidentů“ z minulého roku.

Prosím čtěte:

* http://www.artima.com/scalazine/articles/twitter_on_scala.html
* http://blog.obiefernandez.com/content/2009/04/my-reasoned-response-about-scala-at-twitter.html
* http://al3x.net/2009/04/04/reasoned-technical-discussion.html

Twitter vyměnil část infrastruktury původně napsané v Ruby (a dle mínění několika významných účastníků debaty napsané špatně) za infrastrukturu přepsanou do Scaly.

Např. celá debata na téma „máme si napsat vlastní messaging system nebo použít RabbitMQ“ je velmi zajímavá a mnohovrstevnatá, bez jednoduchého a instantního závěru. Nebo celá debata o typování, která je pro nezaujatého čtenáře podobně zajímavá.

> GWT je ta výhoda, kterou Java má oproti jiným jazykům. Pokud potřebujete v projektu napsat jak server část, tak i část HTML/CSS/JS, tak díky GWT nemusíte opustit Javu.

Ale podobné věci existují i pro jiné jazyky.

Ale nejsou srovnatelné, co do možností a propracovanosti. Viděl jsem pyjamas pro python, redshift pro ruby a script# pro .net. Jen poslední jmenovaný by se mohl blížit.

Třeba pro Common Lisp existuje parenscript, pro OCaml třeba ocamljs. Pro Haskell existuje spousta různých řešení ve formě EDSL jako HJScript, jmacro nebo přímo jako backend kompilátoru Yhc.

„Stejně tak není problém mít Java aplikaci dobře škálující. Navíc je tu výhoda podpory od Googlu, například GWT.“

Už jsem si myslel, že pletete GAE a GWT, ale ne. Jen bych v daném kontextu spíše očekával zmínku o GAE.

> To je řešení, které přesahuje, řekl bych, většinu nasazení Javy na webu.
Vacsinu asi ano ale az taka exotika vo svete Javy to zas nie je. Zato vo svete PHP asi najvacsacia nie?

> to bych pro bankovní aplikace mnohem radši použil to PHP. :))
Tak to ste asi jediny lebo ja som o takom rieseni nepocul.

Největší?

A co třeba Facebook, Yahoo, Wikipedia?

J2EE jde škálovat u Googlu na Google Apps Engine. Ano, znamená to ve srovnání s klasickými J2EE řešeními určité omezení, ale pořád je to IMHO příjemnější než PHP.

>>> méně kódu == méně chyb

To je sporné, např. už jsem viděl asi sto pokusů, jak regulární výrazy zapsat delší formou, protože kratší zde pro mnoho lidí neznamená lepší, méně náchylné k chybám a podobně, ale spíš právě naopak.

Java se mi sice taky moc nelíbí a její zápis považuji za zbytečně rozvláčný, ale nedělal bych z toho závěry pro udržovatelnost a možnosti refaktoringu (ty jsou u Javy na velmi dobré úrovni). Na kvalitu kódu mají vliv jiné věci, než jestli string do souboru uložím pomocí jednoho nebo dvou příkazů…

„To je sporné, např. už jsem viděl asi sto pokusů, jak regulární výrazy zapsat delší formou, protože kratší zde pro mnoho lidí neznamená lepší, méně náchylné k chybám a podobně, ale spíš právě naopak.“

+1

Někteří lidé jsou vyloženě posedlí minimalizací kódu, někde si přečetli, že čím méně řádek, tím méně potenciálních chyb… jenže ono to neplatí. Když kód uměle nahustíme tak, aby se vešel na méně řádek, riziko vzniku chyb nesnižujeme – naopak spíš vzroste a kód se stává méně přehledným.

Hlavně nezáleží až tak na počtu řádků, jako spíš na počtu větvení, cyklů, jejich vnoření atd. A zároveň ukecanější kód nemusí být na škodu – pokud je napsaný dobře, je z něj na první pohled vidět, co dělá a co byl záměr programátora – zatímco z minimalistického „hackerského“ kódu to často vidět není.