107 komentářů k článku Java na webovém serveru: porovnání Javy a PHP:

  1. dc

    pekne zhrnutie

    Celkom pekne zhrnutie. K tym kompilovanym vs. interpretovanym jazykom, dnes asi kazdy vyznamnejsi jazyk ktory bol povodne interpretovany ma uz aj nejaky kompiler. Tusim existuje aj java kompiler ale to som si fakt neni isty. Asi je ale najdolezitejsie aka je najrozsirenejsia implementacia daneho jazyka.
    Na jave mi akurat tak trochu vadi taka obcas az prehnana prekomplikovanost aj jednoduchych veci a procesov.

    1. Palo

      Re: pekne zhrnutie

      Daj nejake prekomplikovanosti, poradime, pomozeme. Tusis spravne ze existuje Java compiler, ten tam aj vzdy bol (koli prenositelnosti kompiluje do pCode). A dnes existuju Java Virtual Machine (JVM) ktore potom tento kod prelozia za behu do nativneho kodu pocitaca (JIT Just-in-time Compiler).

      V clanku sa mi nepaci ze webove aplikacie sa zhrnu pod JSP a EJB. Uz existuju aj nove kniznice a toolkity ako napr. GWT a pripadne pomocou Spring Remoting velmi jednoducho urobit servisnu vrstvu bez potreby pouzitia EJB.
      To nebudeme hovorit o buducnosti v podobe OSGi containerov, inych sablonovacich systemoch ako je JSP pripadne generatoroch kodu. Rozumiem ze autor sa snazil to aspon trochu zovseobecnit dany problem ale Java je ozrutna problematika.

      1. Ladislav Thon

        Re: pekne zhrnutie

        dc měl asi na mysli překladače z Javy přímo do nativního kódu, umí to třeba gcj (ale existují i komerční, třeba Excelsior JET). A takový JRockit (dříve BEA, dnes Oracle), ač „klasická“ virtuální mašina, žádnou interpretaci neprovádí a všechno nejdřív kompiluje do nativního kódu. Osobně si myslím, že v případě virtuálních strojů se dá těžko mluvit o kompilaci nebo interpretaci, spousta z nich je prostě „někde mezi“.

        S druhým odstavcem naprosto souhlasím. I když budoucnost v podobě OSGi mne děsí, to je jeden z těch příkladů překomplikovanosti. Modulový systém Javě chybí jako praseti drbání a možná ještě víc, ale tohle podle mne prostě není ta správná cesta. Trochu doufám, že tady Rod Johnson vsadil na špatného koně :-)

        1. Palo

          Re: pekne zhrnutie

          Network OSGi – krasa. Sa na ten „cloud“ pripojis pekne z Eclipsu. Buildnes a stlacis reload. Ono sa to deployne do centralneho repository a reloadnu sa moduly. No krasa. Uvidime kam to bude viest.
          Modulovy system pre Javu zalezi s akeho uhla sa na to pozrieme. Je Maven modulovy system? Na urovni vyvoja iste. Runtime modulovy system je napr OSGi a bezi na nom napriklad Eclipse takze je to uz v podstate overena technologia. Myslim ze niet cesty spat ;-).

          1. Ladislav Thon

            Re: pekne zhrnutie

            Je to tak, OSGi je dneska v podstatě průmyslový standard, a tuším, že i JSRko pro Java Module System či jak se to jmenuje k němu přihlíží. Ale ta classloaderová magie… já prostě nevím.

  2. alblaho

    Slabě typovaný příklad

    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.

    1. Ladislav Thon

      Re: Slabě typovaný příklad

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

    2. Kamil

      Re: Slabě typovaný příklad

      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.

      1. milan

        Re: Slabě typovaný příklad

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

        1. Kamil

          Re: Slabě typovaný příklad

          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.

          1. v6ak

            Re: Slabě typovaný příklad

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

            1. Palo

              Re: Slabě typovaný příklad

              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?

              1. v6ak

                Re: Slabě typovaný příklad

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

      2. MD

        Re: Slabě typovaný příklad

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

  3. Jarda

    Výkon

    Jsem zvědav na porovnání výkonnosti, potřeby systémových prostředků atd. Bohužel my s Javou máme ohledně provozu jen ty nejčernější zkušenosti. Jakmile s aplikacemi pracuje více uživatelů, rychlost klesá limitně k nule. Problém s verzemi Javy je skoro stejný jako u PHP, takže pak už porovnáváme objektový model, štábní kulturu atd. V tom je PHP silně propadající, nicméně to neznamená, že pokud si na to zvyknete, že to není celkem dobrý sluha a těžko hledat lepšího (pro web)…

    1. Jan Kodera

      Re: Výkon

      Podělte se o jaké aplikace se jedná, jaké je nastavení systémových prostředků, verze Javy apod. Protože to jak to popisujete není nutně chyba jazyka.

      1. Jarda

        Re: Výkon

        no dejme tomu aplikace typu spisová služba, oběh dokumentů či GIS aplikace. Problém je v tom, že podobně napsané aplikace v PHP či .NET nevyžadují tak nabušený server. Jakmile je to řešení v Javě, tak požadavky na paměť výrazně narostou. Je to logické vzhledm k filozofii Javy, ale občas je to enormní, pokud s aplikací pracuje několk stovek uživatelů najednou. Nebudu asi zabíhat do detailů, jestli je to aplikačním serverem, způsobem komunikace s persistentním uložištěm atd.
        Java je prostě super, logická a přehledná, trochu ukecanější než PHP, nutí vás víc domýšlet každý krok a nutí vás k objektovému modelu. PHP je jednoduchý nenáročný (na naučení i na prostředky) scriptovací jazyk, který se už trochu zlepšil a můžete v ně programovat jak úplně prasárny, tak klasicky sturkturálně nebo celkem slušně objektově a na 99% aplikací vám to bude stačit. howg a pěkný večer

        1. v6ak

          Re: Výkon

          V čem se principiálně liší filozofie .NET a Javy?
          Požadavky na paměť u Javy určitě jsou, už jen kvůli JIT, což je ale v tomto případě vyváženo optimalizacemi. Je teda taky možné zvolit např. AOT JVM.

          1. ARny

            Re: Výkon

            nelisi sa prakticky v nicom. C# a v podstate starsia .NET platforma bola opajcnuta od javi. Dokonca aj niektore nazvy metod maju rovnake ;)

    2. Michal Kára

      Re: Výkon

      Ad problem s verzemi: Pokud se dobre pamatuji, PHP nekolikrat vydalo novou verzi v citelne mire zpetne nekompatibilni. U Javy mozna nejake drobne zpetne nekompatibility byly (nejsem az tak dobry historik), ale rozhodne je na tom v tomto ohledu lepe, nez PHP.

      1. František KučeraAutor příspěvku

        Re: Výkon

        Např. když v Javě 5 zavedli enum, některým lidem přestaly fungovat jejich dosavadní zdrojáky, protože tohle nové klíčové slovo v nich používali třeba jako název proměnné. Ale takováhle nekompatibilita je dost výjimečná a obecně je Java hodně konservativní. Za enum jsou všichni rádi a nová funkcionalita bohatě vyváží tu nutnost přepsat trochu ten starý kód (pokud měl člověk fakt smůlu a tohle slovo pro název proměnných používal).

        Soudit, jestli je i v PHP nekompatibilita vždy vyvážena novými užitečnými funkcemi, nechám raději na ostatních (osobně mi přijde, že často ne, soudě alespoň podle reakcí PHP vývojářů).

        1. Ladislav Thon

          Re: Výkon

          enum je asi tak nejzbytečnější rozšíření, co se do Javy 5 dostalo. Je to prakticky převod vzoru „typesafe enum“ do jazyka s minimální úsporou kódu, asi největší přínos je ve správně implementované serializaci. Ale enum-singleton prostě žeru :-)

          1. František KučeraAutor příspěvku

            Re: Výkon

            Do té doby ale většina vývojářů používala textové nebo celočíselné konstanty, jejichž problém je jednosměrnost a fakt, že nejsou nijak seskupené. Zjistit zpětně z hodnoty (třeba 1, 0, 5, „blabla“) o jakou konstantu se jedná je prakticky nemožné (leda pomocí relfexe procházet a porovnávat, ale to musím vědět aspoň třídu, ve které hledám). Taky když nějaká hodnota má jako parametr int/String musím se dívat do dokumentace, kde hledat příslušné konstanty – kdežto v případě enumu vím i bez dokumentace, co tam patří a nemůžu tam zadat úplnou blbost (jako třeba natvrdo zadané číslo, které nepochází z žádné konstanty), protože jinak by se mi program ani nepřeložil. Takže IMHO enumy v Javě užitečné jsou.

            typesafe enum“ jde sice použít, ale kdo ho skutečně používal? Většinou jsem totiž viděl kód zaneřáděný těmi textovými/číselnými konstantami.

    3. Palo

      Re: Výkon

      To asi nebude chyba jazyka ani frameworkov. Java sa pouziva na velke enterprise aplikacie. My prevadzkujeme viacvrstvove Java clustre pre velke organizacie. Ziadny problem ktore zle napisaneho kodu neexistuje. A to niektore dostavaju pekne do tela. Importy 10MB XML suborov radovo 10.000 denne popri beznej webovej pravadzke nad databazou. Tisice uzivatelov/session online.

  4. Martin Soušek

    Trošku odfláknuté "porovnání"

    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.

    1. alblaho

      Re: Trošku odfláknuté "porovnání"

      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.

      1. Jiří Knesl

        Re: Trošku odfláknuté "porovnání"

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

        1. Palo

          Re: Trošku odfláknuté "porovnání"

          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.

          1. Jiří Knesl

            Re: Trošku odfláknuté "porovnání"

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

            1. Jan Kodera

              Re: Trošku odfláknuté "porovnání"

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

              1. Jiří Knesl

                Re: Trošku odfláknuté "porovnání"

                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.

                1. Jan Kodera

                  Re: Trošku odfláknuté "porovnání"

                  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.

                  1. v6ak

                    Re: Trošku odfláknuté "porovnání"

                    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++

                  2. karmi

                    Re: Trošku odfláknuté "porovnání"

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

              2. xx

                Re: Trošku odfláknuté "porovnání"

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

                1. Jan Kodera

                  Re: Trošku odfláknuté "porovnání"

                  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.

                  1. xx

                    Re: Trošku odfláknuté "porovnání"

                    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.

              3. v6ak

                Re: Trošku odfláknuté "porovnání"

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

            2. Palo

              Re: Trošku odfláknuté "porovnání"

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

            3. v6ak

              Re: Trošku odfláknuté "porovnání"

              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.

        2. Borek Bernard

          Re: Trošku odfláknuté "porovnání"

          >>> 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ů…

          1. František KučeraAutor příspěvku

            Re: Trošku odfláknuté "porovnání"

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

  5. PR

    I PHP umí scope=application

    PHP sice neumí nativně ,,server-wide“ proměnné skrze celý server, ale poměrně efektivně k tomu lze využít například Xcache – tím že ukládá do paměti, jsou data uložená skrze něj dostupná pro všechny relace. Primární využití Xcache je ale samozřejmě pro caching.

  6. maertien

    Porovnani

    Skoda, ze se nepojednalo o vhodnosti jednotlivych platforem pro ruzna zadani. To mi v clanku osobne chybi. Ale jinak celkem pekne, diky…

    1. František KučeraAutor příspěvku

      Re: PHP v Jave

      Vždyť tam je: „Existují i další implementace jako např. výše zmíněný překladač HipHop nebo třeba Quercus.“

      ale díky za odkaz, aspoň ho čtenáři nemusejí googlovat.

      BTW: používáte někdo Quercus? Já jsem s ním párkrát experimentoval – poprvé to byla úplná tragédie, nepodažilo se mi rozchodit ani spojení do DB, fungovaly jen základní věci (jenže bez DB si většina aplikací ani neškrtne). Když jsem zkoušel nějakou pozdější verzi, tak se mi už spojení s DB navázat podařilo a rozjel jsem v tom i Drupal 6, ale byla tu potíž s češtinou – někde byla OK a jinde rozbitá – a nebylo to tím, že by se mršila na rozhraní DB/aplikace (některé texty z DB byla dobré jiné ne), pravděpodobně některé texty Drupal prohání nějakou funkcí a ta byla v Quercusu špatně implementovaná…

  7. Jiří Knesl

    Stalo se, co jsem čekal

    Stalo se, co jsem čekal – tedy, že se vylilo bahno na PHP od lidí, kteří o PHP a jeho schopnostech ví jen nutné minimum.

    V podstatě jediné problémy PHP jsou:
    a) parametry funkcí jsou nesystémové (což třeba já pomalinku řeším ve své knihovně Googy http://bitbucket.org/jiriknesl/googy)
    b) PHP je vyvíjeno nesystémově a pomalu, co fungovalo v jedné verzi, v jiné nemusí bez varování fungovat apod.

    Tací, co lijí bahno, nad PHP vývojáří vytváří image bastlířů, přitom dnes už je v PHP stále běžnější, že se využívají návrhové vzory, Test Driven Development, agilní metodiky, akceptační testy v Seleniu a další.

    Ještě jedna připomínka:

    „Dodnes je Java „objektovější“ jazyk – např. ani při psaní „Hello World“ programu se zde nevyhnete práci s třídami.“ – tohle mě pobavilo. Objective-C je objektovější než Java a žádnou třídu tam pro Hello World nepotřebujete. :) Obdobně Ruby – také objektovější než Java a taky se bez třídy pro Hello World obejdete. :) Já bych spíš řekl, že Java je méně produktivní, ale neřeknu to, protože já o ten flame vůbec nestojím. :)

    1. Palo

      Re: Stalo se, co jsem čekal

      > Já bych spíš řekl, že Java je méně produktivní, ale neřeknu to, protože já o ten flame vůbec nestojím.

      To je dobre, ja tu ciham iba na to :-D.

      Toho image as nezbavite tym ze zacnete odkukovat od Javistov co robia a budete po nich opakovat (ooo vy uz ste zacali aj testovat a dokonca v seleniu). Skuste si porovnat mnozstva a kvalitu kniznic, komercnych implementacii Javy, Java servrov, security, moznosti clustrovania, dynamickeho deploymentu, moznosti rekonfiguracie aplikacie pre prislusne prostredie (Nvrstvovy deployment), java zbernice (SOA), pravidlove enginy, … .
      Zrazu sa vas pidi svet rozpadne. Mozno nic take nepotrebujete to ale neznamena ze robite s lepsim jazykom. V jave to tiez nemusite pouzivat ale … mozte.

    2. MD

      Re: Stalo se, co jsem čekal

      c) chyba typu:

      $promenna = 1;
      .
      .
      .
      $promena = 2;

      Takova chyba se velmi tezko hleda a v tom me PHP strasne vadi. Podobne jako $this->promenna je neco jineho nez $promenna coz se hleda lepe, ale taky je to opruz.

      d) rozsahly PHP kod nejde oproti rozsahlemu Java kodu snadno refaktorovat.

      1. Palo

        Re: Stalo se, co jsem čekal

        Ide o to ze dobry programator to napise rovnako PHP ako aj v C++. Problem je ze nie je vela dobrych progratorov. Na jedneho dobreho pripada priblizne 10 priemernych. S pouzitim, generatorov, odskusanych frameworkov, Aspect Oriented Programming, code waving, … dokazem aspon trochu kludne spavat ze ta aplikacia splna aspon zakladne poziadavky na udrziavanie kodu, bezpecnost, skalovatelnost aj ked ju pise v podstate banda cvicenych opic. Na druhej strane neviem si predstavit platit partu profikov na vyvoj vsetkeho.

        Refaktoring nerobime az tak casto ale minimalne orientacia v kode v dobrom nastroji je v Jave velmi jednoducha. Pre niekoho je Java velmi komplikovana a zlozita. Ked sa ale ja pozriem na PHP nevidim ziadny dovod v tom robit. Co by mi to ako malo priniest?

      2. Paja

        Re: Stalo se, co jsem čekal

        c/
        Takova chyba se naopak najde hned.
        Interpretr vam to nahlasi.
        Staci zapnout error reporting a napsat funkci ktera chyby dava do DB. Je to par radku kodu, staci dat include v kazdem scriptu.

        1. v6ak

          Re: Stalo se, co jsem čekal

          Přiřazení do jiné proměnné interpret neošetří, jen ji založí. S tím si AFAIK neporadí i Duby se svojí inferencí skoro všeho.

          Jinak dělat error_reporting includem je… možné, ale máme tu IMHO lepší nástroje (.htaccess a php_value).

  8. v6ak

    Statické typování bez uvádění typu

    I statické typování jde dělat jinak, příkladem jsou například jazyky Scala, Duby a Groovy++ (všechny ze jmenovaných jsou pro platformu Java). V článku je tam menší nepřesnost.

    1. benzin

      Re: Statické typování bez uvádění typu

      No tak na platforme javy to nebezi. Da se to zkompilovat do bytecode pro JVM, ale s Javou jako takovou to nema nic spolecneho. Java je programovaci jazyk. Btw. pokud vim tak i PHP se da kompilovat do bytecode.

      1. Ladislav Thon

        Re: Statické typování bez uvádění typu

        Never. Java je 1. platforma, 2. low-level jazyk pro tuto platformu. Možná tomu tak nechcete říkat, ale v takovém případě jste v těžké menšině.

  9. xx

    Re: 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.

    1. v6ak

      Re: Java na webovém serveru: porovnání Javy a PHP

      „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

      1. xx

        Re: Java na webovém serveru: porovnání Javy a PHP

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

        1. xx

          Re: Java na webovém serveru: porovnání Javy a PHP

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

        2. v6ak

          Re: Java na webovém serveru: porovnání Javy a PHP

          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.

          1. xx

            Re: Java na webovém serveru: porovnání Javy a PHP

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

            1. v6ak

              Re: Java na webovém serveru: porovnání Javy a PHP

              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.

              1. xx

                Re: Java na webovém serveru: porovnání Javy a PHP

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

                1. Ladislav Thon

                  Re: Java na webovém serveru: porovnání Javy a PHP

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

                  1. v6ak

                    Re: Java na webovém serveru: porovnání Javy a PHP

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

                    1. Ladislav Thon

                      Re: Java na webovém serveru: porovnání Javy a PHP

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

                      1. v6ak

                        Re: Java na webovém serveru: porovnání Javy a PHP

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

                        1. Ladislav Thon

                          Re: Java na webovém serveru: porovnání Javy a PHP

                          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.

                  2. xx

                    Re: Java na webovém serveru: porovnání Javy a PHP

                    > 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ý?

                    1. Ladislav Thon

                      Re: Java na webovém serveru: porovnání Javy a PHP

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

                      1. xx

                        Re: Java na webovém serveru: porovnání Javy a PHP

                        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.

                        1. Ladislav Thon

                          Re: Java na webovém serveru: porovnání Javy a PHP

                          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.

                          1. xx

                            Re: Java na webovém serveru: porovnání Javy a PHP

                            > 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ěť.

              2. Palo

                Re: Java na webovém serveru: porovnání Javy a PHP

                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.

                1. v6ak

                  Re: Java na webovém serveru: porovnání Javy a PHP

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

                2. xx

                  Re: Java na webovém serveru: porovnání Javy a PHP

                  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ý).

                  1. Palo

                    Re: Java na webovém serveru: porovnání Javy a PHP

                    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.

                    1. xx

                      Re: Java na webovém serveru: porovnání Javy a PHP

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

                      1. v6ak

                        Re: Java na webovém serveru: porovnání Javy a PHP

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

                        1. xx

                          Re: Java na webovém serveru: porovnání Javy a PHP

                          > * 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í :-)).

                          1. v6ak

                            Re: Java na webovém serveru: porovnání Javy a PHP

                            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

                            1. xx

                              Re: Java na webovém serveru: porovnání Javy a PHP

                              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.

                        2. xx

                          Re: Java na webovém serveru: porovnání Javy a PHP

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

                  2. František KučeraAutor příspěvku

                    Re: Java na webovém serveru: porovnání Javy a PHP

                    „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).

                    1. xx

                      Re: Java na webovém serveru: porovnání Javy a PHP

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

                      1. František KučeraAutor příspěvku

                        Re: Java na webovém serveru: porovnání Javy a PHP

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

                        1. xx

                          Re: Java na webovém serveru: porovnání Javy a PHP

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

  10. František KučeraAutor příspěvku

    Ukecanost a Lombok

    Na Javě se často kritizuje její údajná „ukecanost“, padlo to i v této diskusi. Osobně s tím moc nesouhlasím, ale je pravda, že psát gettery a settery je někdy otrava.

    Existuje ale zajímavá knihovna jménem Lombok, která tenhle problém elegantně řeší pomocí anotací.

    1. jehovista

      Re: Ukecanost a Lombok

      Co je spatneho na getterech a setterech? Podle me to v mnoha ohledech zvysuje bezpecnost pri programovani(z hle­diska programatora). A kdyz to maji byt jen jednoradkace, tak si je necham vygenerovat v IDE.
      P.S. Jak koukam na ten Lombok, tak bych se to vazne bal pouzit.

      1. Ladislav Thon

        Re: Ukecanost a Lombok

        Generování řeší pouze počáteční režii, čili ve výsledku je úspora prakticky nulová. Automatické generování getterů a setterů je výhodné pro triviální DTO (s ohledem na lokalitu budoucích změn) nebo třeba pro setterovou dependency injection.

        Problém v Javě je jeden: anotační procesory nesmí modifikovat třídy, ve kterých jsou anotace uvedeny – takže Lombok se musí uchylovat ke kódu závislému na implementaci.

        1. v6ak

          Re: Ukecanost a Lombok

          Myslím, že to je vhodné víceméně všude, kde zrovna nechci něco komplecnějšího, protože až se mi to přestane hodit, tak vyhodím @Setter a napíšu si svůj nebo si jen napíšu svůj (v případě @Data).

          1. Ladislav Thon

            Re: Ukecanost a Lombok

            Souhlas, po anotacích pro generování getterů a setterů toužím už pár let. Nicméně, když tak koukám na tu diskusi ohledně implemetnace uzávěrů odkazovanou níže, musím smeknout – nevěděl jsem, že má Lombok až tak široký záběr. Ale protože jakés takés uzávěry budou v Javě 7, celkem to podle mne přestává mít smysl – i když nelokální návrat je paráda (nezkoumal jsem to detailně, ale v té diskusi o něm mluví). Díky za link!

      2. František KučeraAutor příspěvku

        Re: Ukecanost a Lombok

        Používat gettery a settery (místo veřejných proměnných) je samozřejmě správné, protože to umožňuje vložit připadnou další funkcionalitu, aniž by se měnilo „rozhraní“ tříd. Ale trochu nepraktické je, že tu další funkcionalitu vkládáme celkem výjimečně, takže hodně tříd zůstane s gettery a settery, které kromě čtení/zápisu nic jiného nedělají – tzn. hodně řádků kódu bez nějakého hlubšího významu. Osobně s tím problém nemám, beru to spíš jako kosmetickou záležitost – elegantnější by ale bylo, mít „property“ jako je má třeba C#.

  11. Honza

    minimálně 3 chyby

    „PHP je skriptovací interpretovaný jazyk tzn. jeho skripty nasazujeme na server tak, jak je programátor napsal“

    Nejsem odborník, ale viděl jsem už i předkompilované php asi do nějakého bytekódu (když jsem se před 7 lety staral o web na civilce).

    „Zprovoznit si lokálně LAMP nebo třeba aplikační server či pouhý webový kontejner a vedle toho databázi vyjde přibližně nastejno“

    Na starším, vytíženějším nebo virtuálním počítači to přibližně na stejno rozhodně nevyjde.

    „nejlevnější hosting pro PHP stojí pár desetikorun“

    Nikoli, nejlevnější hosting pro PHP je zadarmo.

  12. Paja

    web server java a php

    Ja osobne jsem doiteroval k tomu ze je nejlepe veskere programovani aplikacni logiky delat v PL/SQL (konkretne PL/pgSQL).
    Na webovem serveru se pak PHP i Java stavi do role sablonovacich systemu. Tudiz reseni typove kontroly je na nic – zobrazuje jen to co dostane z databaze.

    Ano, nedovedu si predstavit naprogramovat L2J v PHP. Ale o tom serie clanku neni.

  13. DeathWalker

    interpretovany vs. kompilovany

    „PHP je skriptovací interpretovaný jazyk tzn. jeho skripty nasazujeme na server tak, jak je programátor napsal a zde se interpretují.“
    1. dnes PHP uz standartne obsahuje ZEND opimizer, kod sa prelozi do bytekodu ktory sa uklada aj do cache samozrejme.
    2. je moznost namiesto skriptov na server ulozit priamo bytekod vygenerovany cez ZEND encoder, ktory naviac umoznuje kryptovanie so zavislostou na domene, ip adrese, umoznuje casove obmedzenie funkcnosti skriptu a podobne
    3. na servroch ktore preferujem sa v poslednej dobe objavuje aj IONCUBE encoder, je to podobne ako ZEND len o nieco lacnejsi

Napsat komentář

Tato diskuse je již příliš stará, pravděpodobně již vám nikdo neodpoví. Pokud se chcete na něco zeptat, použijte diskusní server Devel.cz

Zdroj: https://www.zdrojak.cz/?p=3185