Hlavní navigace

PHP 4 je mrtvé – ať žije PHP 5

Sdílet

Petr Krčmář 4. 2. 2008

Už je to tři a půl roku od chvíle, kdy byla vydána první verze PHP5. Velké množství projektů však stále vyvíjí software pro PHP4. Potíž je v tom, že webhosteři stále ještě často starší verzi používají a vývojáři chtějí nabídnout software se širokou kompatibilitou. Hosteři zase PHP4 nemění, protože pro něj existuje dostatek aplikací. Je to začarovaný kruh, který je třeba na jednom místě násilně prolomit. K tomuto účelu vznikla iniciativa GoPHP5.org, sdružující organizace, které jsou rozhodnuty k 5. únoru zcela opustit PHP4. Mezi hostery je i řada českých firem. Přidejte se k nim a opusťte PHP4.

Našli jste v článku chybu?
  • Aktualita je stará, nové názory již nelze přidávat.
  • 4. 2. 2008 14:54

    Miloslav Ponkrác
    Situaci způsobili nezodpovědné konání vývojářů PHP. Protože mezi PHP4 a PHP5 neexistuje zpětná kompatibilita, pak samozřejmě se většině lidí nechce znovu investovat spoustu peněz, času a riskovat zavlečení mnohých chyb při převedení fungujícího sw pod PHP5. Kdyby vývojáři neměli zbytečné rozorávací chotuky (které je samozřejmě nepřešli ani s plánováním PHP6), tak je tu PHP5 přijmuto už dávno a o PHP4 nevíme. Ono je hrozně jednoduché, když vývojáři svým konáním způsobí to, že je nutné nacpat obrovské prostředky (peněz, nebo času) do převodu všeho existujícího pod PHP5 a pak vydávat ublíženecké apely, že se musí "prolomit ledy", a svádět to na jiného, než na sebe.

    Pokud by opravdu to vývojáři mysleli vážně, naprogramují nástroj, který bezpečně překonvertuje PHP4 kód do PHP5, nebo alespoň upozorní na chyby vzniklé přechodem na verzi a rázem by přechod byl daleko rychlejší. Ale to chce řešit problém, ne agitaci. Ryba smrdí vždycky od hlavy.

    V PHP6 to bude stejné, pokud vývojáři nezmění svojí taktiku.

    A stejné problémy zažijeme v jazycích, které považují zpětnou kompatibilitu za zbytečný luxus - Python, Perl, Ruby, PHP. Představte si třeba, že by se Céčko rozhodlo nekompatibilně změnit a zrušilo by kompilátory kompatibilní s ANSI C normou. A zároveň by se objevily apely - přepište linux kernel, drivery, všechen GNU sw a prolomte ledy!!! MS by jenom tleskal, protože znovu přepsaný linux kernel do nové verze Céčka by samozřejmě byl značně chybový - zatímco dnes mnohé části kernelu jsou spolehlivé také proto, že mají za sebou mnoho let ladění a odhalování chyb. Ale autoři PHP prostě blbnou a ještě blbě kecají.
  • 4. 2. 2008 15:57

    Lukáš Turek
    Na co konkrétně jsi narazil když jsi kód psaný pro PHP4 pustil pod PHP5? Já jsem žádný problém neměl, a to jsem používal objekty. Naopak jsem měl problém mezi 4.3 a 4.4 (něco s přiřazováním reference, už nevím přesně).
  • 4. 2. 2008 16:22

    Miloslav Ponkrác
    Doporučuji manuál PHP - Kapitolu Migrating from PHP4 to PHP5/Backward incompatible changes.

    Jinak já narazil, protože jsem PHP využíval do mrtě. Sice už v PHP4 nedělám, ale narazil.

    Kromě toho narážím také na to, že PHP5 má velmi mnoho "stable" verzí značně bugových, a jen málokterá verze po tvrdém testnutí projde (samozřejmě pokud používáte jenom echo a pár ptákovin, tak vyhoví každá). Hlavně ta chybovost akcelerovala můj přechod na jiné technologie.
  • 4. 2. 2008 16:02

    Lukáš Turek
    A k tomu Cčku, s každou verzí GCC je potřeba opravovat stávající kód, nedávno se vedla diskuse jestli upravovat kernel 2.4 aby šel zkompilovat s GCC4, někdo dokonce patchoval kernel 0.0.1... A Qemu nefunguje s GCC4 dodnes. Ale v 99% na problém nenarazíš, a když narazíš, tak to je spíš chyba v tvém kódu. Nikdy totiž nejde zachovat kompletní zpětnou kompatibilitu - i oprava chyby je nekompatibilní změna!
  • 4. 2. 2008 16:40

    Miloslav Ponkrác
    Až budete mít program v Céčku vyhovující na 100% ANSI normě C - tak si můžete být na 100% jistí, že tento program na 100% přeložíte na všech běžných, i řadě málo běžných platforem. Pokud bude mít gcc chybu, přeložíte ho jiným, bezchybným ANSI C kompilátorem, třeba Intelem.

    ANSI C norma Céčka je pevná, neměnná, nezávislá na GNU komunitě, ani na chybách v gcc - je to jistota, která se nehne.

    10 let starý program v Céčku vyhovující ANSI C (kterých jsou terabajty zdrojových kódů) normě nebudete mít problém přeložit. Pokud teď napíšete program ve zdrojových kódech vyhovující ANSI C normě - pravděpodobně ho i za mnoho let bez větších problémů přeložíte. To je ta jistota zpětné kompatibility.

    Když teď budete mít 10 let starý program v PHP, můžete ho rovnou zahodit. A dnešní program v PHP za deset let můžete zahodit rovněž - cítíte ten rozdíl oproti programu napsaném v čistém C?

    To, že linux kernel není napsán v žádné C normě jazyka a nedodržuje standardy C jazyka způsobuje to, co popisujete - linux kernel používá proprietární extenze GCC. Stejně tak cokoli jiného.

    Já sám bez problémů přeložím svoje Céčkové kódy, které jsem napsal před 15 lety (samozřejmě vyhovující ANSI normě). Ony bez problémů chodí po překladu pod Linuxem i pod Windows, dělají naprosto to samé, co kdysi dělaly na zcela jiném systému, ačkoli jsem v té době vůbec netušil, že nějaké Windows, nebo Linux kdy vůbec budou někdy existovat. A o tom to je.
  • 4. 2. 2008 17:11

    Lukáš Turek
    Ano, ale stejně tak bude existovat podmnožina PHP kompatibilní s PHP4, PHP5, i budoucím PHP6. Ano, není to standard, ale když bylo C ve věku jako dnes PHP, tak podle mě ještě ANSI standard nebyl (možná se pletu). Ale tak jako u C si s tím základem dost často nevystačíš - v PHP třeba když chceš používat výjimky, u C když chceš používat vlákna, makra s proměnným počtem parametrů, sockety, nebo i obyčejné for(int i = 0; i < 10; i++), které je až od C99.
  • 4. 2. 2008 18:02

    Miloslav Ponkrác
    Tato množina samozřejmě existovat bude - ale není to postavené na hlavu? Jak mohl vývojář píšící po uvedení PHP verze 4 bez křišťálové koule vědět, jak má psát, aby v budoucí (tehdy ještě neexistující pětkové verzi PHP) to bez problémů chodilo? Jinak řečeno, ano tato podmnožina určitě existuje, ale není dopředu známá - je nutno zapojit křišťálovou kouli, věštění z kávové sedliny a jiné osvědčené recepty. Nebo zkuste mi teď napsat, jak máte psát, abyste nemusel zaručeně předělávat projekt v PHP5 až přijde PHP6, nebo ještě spíše v PHP7. Nenapíšete, protože to opravdu nikdo na 100% netuší. A autoři PHP nic jistého v PHP nezaručují.

    V ANSI C je naprosto jistá množina věcí, které jsou zaručené NA VĚKY VĚKŮ a VŽDY, i za desítky let najedete kompilátor, který si s ANSI C poradí. A ta množina není malá - a to je obrovská záruka. Takové záruky jsou znakem serióznosti jazyka.

    Pokud chci větší záruky, mohu využít třeba C++, které je též normativně standardizované, a i tam je zaručeno NA VĚKY VĚKŮ, co bude vždycky fungovat.

    Jenže cyklus for napíšete tak, aby byl v normě ANSI C bez problémů, jen musíte trochu méně pohodlně definovat proměnnou před cyklem. Bez maker s proměnným počtem parametrů se obejdete. To není nic, než omezení syntaxe, ale nikoli možností jazyka.

    Sokety, nebo vlákna jsou součástí API operačního systému - je jasné, že v ANSI C nejsou. Nicméně i pokud je použijete, tak máte při chytrém programování třeba 99% zdrojového kódu přenositelných v čistém ANSI C - a můžete si být jisti, že pokud ho odladíte, jde se na to spolehnout, že na něj nikdy v budoucnu nebudete muset sáhnout (s výjimkou případné opravy chyb). A zbylé 1% kódu holt bude závislé na API systému a je potřeba ho přepsat. Pořád jste na tom výrazně lépe, než u PHP, kde v budoucnu nemáte absolutně žádnou záruku na to, že to třeba nebudete muset přepsat vše - PHP záruky do budoucna dává naprosto nulové.
  • 4. 2. 2008 18:29

    Lukáš Turek
    > Tato množina samozřejmě existovat bude - ale není to postavené na hlavu? Jak mohl vývojář píšící po uvedení PHP verze 4 bez křišťálové koule vědět, jak má psát, aby v budoucí (tehdy ještě neexistující pětkové verzi PHP) to bez problémů chodilo?

    A jak mohl někdo kdo psal pro K&R C vědet, jak bude vypadat ANSI C? PHP je teprve v téhle fázi.

    > Bez maker s proměnným počtem parametrů se obejdete. To není nic, než omezení syntaxe, ale nikoli možností jazyka.

    Jak udělám funkci pro ladící výpis, která vypíše jméno funkce a pak formátovaný řetězec tak jako printf? S variadickými makry je to takhle:
    #define DEBUG(fmt, ...) printf("%s: " fmt, __func__, ##__VA_ARGS__)

    A mimochodem, kterým jazykem by jsi teda nahradil PHP? Ty snad píšeš stránky v ANSI C (něco takového jsem viděl, to co by bylo v PHP 5 řádek bylo asi 100 řádek v C, navíc s jednou bezpečnostní chybou)?

    Java i .NET se vyvíjí podobně jako PHP, včetně změn co rozbijí staré programy, například přidávání klíčových slov (enum v Javě 1.5, group v .NET 3.0). Proti tomuhle je navíc PHP odolné, když proměnné začínají $ a můžeš mít klidně $class.
  • 4. 2. 2008 19:21

    Miloslav Ponkrác
    >A jak mohl někdo kdo psal pro K&R C vědet, jak bude vypadat ANSI C? PHP je teprve v téhle fázi.

    Napište zdrojový kód v K&R C a přeložíte ho dnes také. Říká se tomu zpětná kompatibilita. Zdrojové kód v K&R C nemáte naprosto žádný problém přeložit dnešním C kompilátorem. Třeba takový vim se píše v K&R C dodnes a problémy nejsou.

    Možná nejsem plně pochopen - Je možné napsat zdrojový kód v C tak, abyste MĚL ZÁRUKU, že ho kdykoli v budoucnu přeložíte beze změny jediného písmenka ve zdrojáku, pokud opravdu bude vyhovat nějakému standardu jazyka C.

    V PHP máte velké kulové jako záruku, nemáte naprosto žádnou možnost, jak nějaké záruky na budoucí použitelnost zdrojového kódu získat. Nelze napsat žádným stylem v PHP zdrojový kód tak, abyste ho třeba za deset let zaručeně BEZE ZMĚNY zdrojového kódu použil. Nejde to, je to nemožné.

    >Jak udělám funkci pro ladící výpis, která vypíše jméno funkce a pak formátovaný řetězec tak jako printf? S variadickými makry je to takhle:
    #define DEBUG(fmt, ...) printf("%s: " fmt, __func__, ##__VA_ARGS__)

    Já se zeptám jinak, jak v ANSI C vůbec zjistíte název funkce? Takové makro neexistuje a ani taková možnost v ANSI C není. Tudíž variadické makro Vám ani zde nepomůže, protože Vám chybí už tohle.

    Ono je běžné, že že novější standardy dávají více možností, než předchozí standardy, a že C99 bude umět více, než ANSI C.

    Pokud by možnost __func__ byla, a nebo byste se rozhodl sám takovou proměnnou definovat v každé funkci, pak to jde takto:

    ===========================================================

    const char* __raw_return_fce(const char* fce_name)
    {
    return fce_name;
    }

    const char* __debug(const char* fce_name, const char* format, ...)
    {
    // zde pomocí va_list zavoláte vprintf a přidáte tam navíc jméno funkce
    // jde to zcela bez maker a bez problémů v ANSI C
    }

    #define DEBUG __debug(__func__)__debug

    ===========================================================

    Použití:

    int main()
    {
    DEBUG("%d bleble %c\n", 12, 'a');
    return 0;
    }
  • 4. 2. 2008 19:50

    Lukáš Turek
    > #define DEBUG __debug(__func__)__debug

    Myslel jsi #define DEBUG __debug(__func__);__debug ?
    Představ si co to udělá v kódu typu

    if(i > 10)
    DEBUG("i is %d, more than 10!", i);

    Používají se triky jako
    #define MACRO do { cmd; cmd; } while(0)
    , ale to tím makrem co navrhuješ neuděláš.
  • 4. 2. 2008 20:11

    Miloslav Ponkrác
    Pardon, zhroutila se mi Mozilla Firefox, a odeslala rozepsaný kód, takže ho neberte vážně - kód odvolávám. Mozilla dokonce začla blbnout tak, že na klávesové zkratky dělala náhodné akce, tak jsem jí přeinstaloval. Takže to co tam bylo, bylo rozepsané a samozřejmě špatné. Já bych to nelámal přes koleno, ale udělal bych to jednoduše takto:

    ==================================================

    int debug(const char* fce, const char* fmt, ...)
    {
    // tady uz je to jednoduche
    }

    int main()
    {
    static const char __fce__[] = "main";

    debug(__fce__, "%s", "hello");
    10 + 2 * 3;
    debug(__fce__, "%d", 10*10);
    return 0;
    }

    ====================================================

    Nicméně jak říkám, nedá se očekávat, že by novější verze neměla něco co nemůžete jako SYNTAKTICKÝ CUKR použít ve starší verzi. Jak vidíte tímto kódem udělám to samé, jen s menším komfortem.
  • 5. 2. 2008 11:19

    BLEK. (neregistrovaný)
    "Napište zdrojový kód v K&R C a přeložíte ho dnes také. Říká se tomu zpětná kompatibilita. Zdrojové kód v K&R C nemáte naprosto žádný problém přeložit dnešním C kompilátorem. Třeba takový vim se píše v K&R C dodnes a problémy nejsou."

    To jsem kdysi zkusil přeložit něco z originálního Unixu a nešlo to. K&R C dovolovalo dělat věci jako:
    * sčítání dvou pointerů
    * rozdíl pointerů různých typů
    * mělo jinak dělané (současně nepodporované) definice funkcí s proměnlivým počtem argumentů

    * ANSI před časem zavedlo možnost přehazovat přístupy do paměti na různé typy a spousta programů se tím rozbila (toto není teoretický problém, nýbrž reálný)
  • 5. 2. 2008 12:43

    Miloslav Ponkrác
    Jasně, K&R prostě nebylo normováno, ale bylo prostě popsáno knihou. Nicméně se přiznám, že s uvedenými možnostmi jsem se nesetkal, takže díky za rozšíření obzorů. Jen mi proboha řekněte, k čemu je sčítání dvou pointerů? Z toho nemůžete dostat naprosto žádný použitelný výsledek a k ničemu to v praxi být nemůže. Proto bych ani neočekával použití v programech. Stejně tak co by vlastně měl dělat rozdíl pointerů dvou různých typů? Jakou operaci by měl provést, když výsledek je počet "prvků" mezi adresami pamětí? To co popisujete mi přijde jako nesmysl vůbec používat a já jsem se s programem toto používajícím opravdu nesetkal. V K&R jsem psal - protože kdysi ještě ANSI C nebylo, ale opravdu jsem toto ještě nikdy neviděl použít.
  • 5. 2. 2008 16:32

    BLEK. (neregistrovaný)
    Já myslím, že sčítání dvou pointerů a rozdíl pointerů různých typů není k ničemu a v tom prvním kompilátoru to prostě prošlo proto, že byl napsán rychle a autoři se s kontrolou chyb moc nezabývali. Co to dělalo, těžko říct. Když to tam bylo dovoleno, tak se našel i nějaký program pro původní unix, který to používal. Je rozumné, že to bylo odstraněno.

    Někde na internetu se dá stáhnout emulátor PDP-11 a pod něj image disků s unixem verze 5, 6 a 7 a tam je to vidět.

    Můžu to v tom emulátoru zkusit (někde ho ještě na disku mám), co to vlastně mělo dělat.
  • 4. 2. 2008 20:36

    Miloslav Ponkrác
    >A mimochodem, kterým jazykem by jsi teda nahradil PHP? Ty snad píšeš stránky v ANSI C (něco takového jsem viděl, to co by bylo v PHP 5 řádek bylo asi 100 řádek v C, navíc s jednou bezpečnostní chybou)?

    Já nepíšu, že jsem nahradil PHP, jen že jsem se přesunul k jiných technologiím. Nicméně takový Python, nebo Java je daleko serióznější prostředek. Psát web stránky v C je sice možné, ale neefektivní (ono je vůbec neefektivní vůbec cokoli psát v C, když je tu C++, ale nechci vyvolávat flame).

    Když to vezmete takto: PHP je v podstatě nejhůře vybavený skriptovací jazyk co existuje. Nemá zpětnou kompatibilitu, neustále se rozorává. Nemá binární tvar (respektive ve verzi 3 měl, ale dnes autoři se rozhodli ho dávat za peníze jako komerční produkt), nemá ve standardní instalaci debugger (což mají de facto všechny jiné skriptovací jazyky co mám), důvod stejný - autoři chtějí vydělávat na IDE a čím očesanější bude PHP, tím snadněji přesvědčí zákazníky. Kromě toho PHP dosud ani v nejnovější verzi nepodporuje práci s Unicode - pouze pár externích knihoven to zvládá. Neznám v podstatě žádnou rozsáhleji používanou serverovou webovou technologii s tolika nepříjemnostmi naráz.

    Myslím si, že webovým jazykům by prospělo, kdyby slovo zpětná kompatibilita a norma jazyka začaly brát vážně. Nebylo by príma, kdyby autoři dali do oběhu dokument "norma jazyka PHP", kde by bylo jasně popsáno co bude navždy zaručeno do budoucna? Představte si, že by stejným přístupem jako je PHP trpěly i internetové standardy. Zrušili bychom bez náhrady současný HTTP protokol a vymysleli něco zcela jiného, naprosto a totálně nekompatibilního a nazvali to třeba NGP (New Generation Protocol). S tím, že bychom udělali akci GoNGP a vyzvali všechny, aby přestali používat HTTP a "prolomili ledy". Asi by to v praxi neprošlo, že?



    >Java i .NET se vyvíjí podobně jako PHP, včetně změn co rozbijí staré programy, například přidávání klíčových slov (enum v Javě 1.5, group v .NET 3.0). Proti tomuhle je navíc PHP odolné, když proměnné začínají $ a můžeš mít klidně $class.

    Vám trochu schází cit pro míru. Přidání jednoho klíčového slova je otázkou refactoringu programu, kde automaticky nahradíte jeden identifikátor jiným - dobré IDE to udělají v cukuletu za Vás a můžete mít 100% jistotu, že jste tam nezavlékl jedinou novou chybu. Navíc neznám kvalitního programátora, který by nazýval identifikátoru velmi kolizními jmény typu enum, class, apod.. a to v žádném jazyce.

    Míry boření a destrukce zpětné kompatibility v tak obrovské míře jako PHP se hned tak něco nemůže rovnat. Problém je, že změny v PHP mohou zavést těžko hledatelné záludné skryté chyby, což těžko dokážete s kolizí klíčových slov - prostě kompilátor Vám ohlásí syntax error - a hned to vidíte.

    Jinak Java i .NET je rozhodně bezpečnější jazyk ve smyslu, že tam daleko hůře zanesete takové chyby, jaké lze v PHP vyrobit běžně. A když jde o to, klidně si můžete v PHP pojmenovat proměnnou i jako mezeru, nebo konec řádku, akorát se s tím hůř pracuje.
  • 4. 2. 2008 21:15

    Lukáš Turek
    > Já nepíšu, že jsem nahradil PHP, jen že jsem se přesunul k jiných technologiím. Nicméně takový Python, nebo Java je daleko serióznější prostředek.

    Nová verze Pythonu nebude zpětně kompatibilní v ještě větší míře než PHP, skoro žádný skript prý nebude fungovat bez úprav. U Javy to je lepší, to uznávám. Nezmiňoval jsi Ruby, to je asi jediné kam bych možná přešel od PHP. Proti Javě je Ruby mnohem méně ukecané, viz třeba http://www.majda.cz/vyuka/2006-2007/swi113/slajdy.html#slide-29. Ale to je příliš mladý jazyk, takže jde těžko předvídat kam se vyvine a jak to bude s kompatibilitou.

    > Zrušili bychom bez náhrady současný HTTP protokol a vymysleli něco zcela jiného, naprosto a totálně nekompatibilního a nazvali to třeba NGP (New Generation Protocol). S tím, že bychom udělali akci GoNGP a vyzvali všechny, aby přestali používat HTTP a "prolomili ledy". Asi by to v praxi neprošlo, že?

    Ehm, slyšel jsi o IPv6? :o) V začátcích se dokonce jmenovalo IPng ("Next generation"). A v praxi to zatím bohužel moc neprochází, to je pravda.
  • 4. 2. 2008 23:02

    Miloslav Ponkrác
    >Nová verze Pythonu nebude zpětně kompatibilní v ještě větší míře než PHP, skoro žádný skript prý nebude fungovat bez úprav. U Javy to je lepší, to uznávám. Nezmiňoval jsi Ruby, to je asi jediné kam bych možná přešel od PHP. Proti Javě je Ruby mnohem méně ukecané, viz třeba http://www.majda.cz/vyuka/2006-2007/swi113/slajdy.html#slide-29. Ale to je příliš mladý jazyk, takže jde těžko předvídat kam se vyvine a jak to bude s kompatibilitou.

    Nová verze Pythonu bohužel sice bude nekompatibilní (jedna nekompatibilní změna) - nicméně má dost velmi dobrých frameworků, umí bez problémů Unicode spolu s dalšími věcmi. Python je promyšlený jazyk.

    Ruby jsem nezmiňoval, protože nejnovější verze Ruby je nekompatibilní už dnes - pod nejnovější verzí Ruby framework Ruby on Rails nechodí. Kromě toho Ruby neumí moc dobře Unicode - a pod řetězci v Ruby stále přemýšlím jako sekvenci bajtů, což mě přijde jako bych programoval v assembleru. Řetězec v Ruby pro mě prostě není řetězec, ale proud bajtů s nějakým kódováním nad kterými fungují některé knihovní funkce - tento přístup se mi hodně, ale opravdu hodně nelíbí.

    Navíc mi řekněte, odečtěte Ruby on Rails - a co máte dál ve webu v Ruby na výběr?

    Ukecanost jazyka není až tak silný argument - jde o udržovatelnost, podporu, serióznost, záruky, možnosti jazyka a další.

    Ale nedejte se mnou zvyklat - pokud se Vám Ruby líbí, tak do něj. Ničeho se nebojte.

    >Ehm, slyšel jsi o IPv6? :o) V začátcích se dokonce jmenovalo IPng ("Next generation"). A v praxi to zatím bohužel moc neprochází, to je pravda.

    Tady máte zrovna krásný příklad jak moc těžké je prosadit zpětně nekompatibilní změnu - IPv6 se začalo tvořit před 16 lety - a stále ho skoro nevidět, ba dokonce není dodnes podporováno ani na většíně kořenových DNS serverů. A evidentně ještě mnoho let uplyne, než se v souvislosti s IPv6 o nějakém rozšíření bude dát vůbec mluvit.

    Tady vidíte, že ani výhoda IPv6 (ona je v podstatě jen jedna - větší adresní prostor) nejsou dostatečné pro jeho rozšíření. Prostě ekonomické, technické, a jiné náklady a obrovské investice k tomu potřebné jsou brzdou.

    A stejně tak proto si všimněte, že dlouhodobými stálicemi na poli programovacích jazyků jsou pouze Ty, které DÁVAJÍ ZÁRUKY ZPĚTNÉ KOMPATIBILITY. Jakékoli jiné jsou tu krátkodobě - i když to krátkodobě může znamenat cca max. 10-15 let. A také v těchto seriózních jazycích jsou dělány projekty, kde opravdu o něco jde. Můžeme to vzít začátku - COBOL, Fortran, Ada, C, ale také třeba unix shell (dokážete si představi jaké problémy by způsobilo znekompatibilnění sh?), a dále jazyky, které jsou tu krátce, ale touto seriózní kompatibilní a normovanou cestou tvrdě jdou: C++ například. Ve všech těchto jazycích jsou dělány obrovské a důležité projekty.

    Klidně se ohledněte za 10 let po dnešku - a uvidíte sám, kde bude Python, kde Ruby, kde Perl, kde PHP - podle mě na ně budeme vzpomínat asi tak jako kdysi třeba na Basic, nebo na Pascal. Po každé změně syntaxe se prostě sníží procento vyznavačů a řada lidí odejde za něčím stabilnějším. Zatím jste mladý, jste nadšený a nevadí Vám investovat spoustu času a energie do přepisování a novém odladění chyb. Ale nebudete to tolerovat věčně.
  • 5. 4. 2008 22:02

    Ondra (neregistrovaný)
    > Proti Javě je Ruby mnohem méně ukecané, viz třeba http://www.majda.cz/vyuka/2006-2007/swi113/slajdy.html#slide-29.

    Ano, Java není jazyk určený pro primitivní ukázky do slajdů. Kolikrát v kódu definujete pole tří stringů a ručně jej řadíte?
  • 5. 4. 2008 22:15

    Miloslav Ponkrác
    Java je bohužel ukecaná víc, než je zdrávo, s tím zase musím souhlasit. Je až příliš osekaná, a dohání se to holt okecáváním.
  • 5. 2. 2008 11:23

    BLEK. (neregistrovaný)
    "Když to vezmete takto: PHP je v podstatě nejhůře vybavený skriptovací jazyk co existuje."

    Mně na PHP zarazila jedna věc --- že má rovnou v poli iterátor toho pole. Když člověk bude iterovat stejné pole ve dvou funkcích, co se navzájem volají, tak si asi dokážeme představit, co to udělá. Holt to asi bylo pro děláno BFU :-(
  • 5. 2. 2008 12:37

    Miloslav Ponkrác
    Dneska už iterátory nejsou iterátory, ale v PHP5 exportují rozhraní (interface) třídy Iterator. Tak jsem si třeba já osobně do svých tříd v PHP dodělal možnost iterace přes cyklus foreach třeba. Stejné řešení používá například i Python, principem podobné (byť omezenější) řešení používá C++, které má v STL iterátory, atd..

    Nezkoušel jsem to, jestli pole v PHP5 má iterátor jako proměnnou v poli, a nebo zda exportují interface Iterator, ale pokud to druhé, pak absolutně není problém iterovat stejné pole nezávisle ve svou funkcích aniž by se oovlivňovala. Ale test, zda implementace je a), nebo b) nechám na Váženém zájemci.

    Miloslav Ponkrác
  • 5. 2. 2008 16:36

    BLEK. (neregistrovaný)
    Jasně, že to s těmi iterátory nějak jde napsat čistě, ale php k tomu čistému psaní nevede (každý php tutoriál popisuje tu nečistou variantu s implicitním iterátorem v poli).

    Člověk A napíše funkci A a iteruje v ní pole P
    Člověk B napíše funkci B a iteruje v ní pole P
    Člověk C změní funkci A a zavolá z ní funkci B

    Prostě mi přijde, že v normálních jazycích, když člověk čte proměnnou nebo pole, tak ho nemodifikuje. Ne tak v php. Nedejbože, kdyby tam chtěli udělat thready, to by mohli rovnou zabalit (dva thready čtou totéž pole a navzájem se díky tomu sdílenému iterátoru ovlivňují).
  • 5. 2. 2008 18:01

    Miloslav Ponkrác
    Myslím si naprosto totéž. Koneckonců každý programovací jazyk vzniklý, nebo inspirovaný Perlem skončí jako prasečina - můj osobní názor. Zatím jsem nenašel výjimku.
  • 6. 2. 2008 11:51

    Miloslav Ponkrác
    Mimochodem to makro DEBUG je špatně !!!

    Co když to zavolám takto:

    static const char format_pro_debug = "Index %d is out of range";

    if (index > 10)
    DEBUG(format_pro_debug, index);
    if (index < 0)
    DEBUG(format_pro_index, index);

    Já osobně dávám přednost tomu, aby cokoli se tváří, že se volá jako funkce se také jako funkce volalo. A je dobrým stylem to takto dotáhnout. A v tomto případě vaše makro DEBUG selže, bude to syntax error při kompilaci.
  • 5. 4. 2008 21:40

    Ondra (neregistrovaný)
    Jak klíčové slovo enum rozbíjí staré programy?
    Když už budu tak blbej, že pojmenuju proměnnou "enum", tak kompilátoru řeknu, ať překládá podle verze 1.4. Easy.

    PHP není odolné proti ničemu, protože nemá žádný racionální návrh, žádnou nosnou ideu, jenom vykrádá ostatní jazyky. Nemá žádnou specifikaci, nemá záruku zpětné kompatibility, je to prostě sranda-jazyk, který je dobrý pro věčné začátečníky. Většina rozumných lidí po jisté době vývoje v PHP prozře a uteče k nějaké konzistentnější technologii.
  • 4. 2. 2008 20:48

    Miloslav Ponkrác
    To je jedna z obrovských výhod normovaných jazyků. Při psaní normy všichni vědí, že jde do tuhého a co bude v normě, z toho už se nevyvléknou na věky věků. A proto daleko více promýšlejí a daleko více se snaží - aby tam nezůstala pokud možno moc velká hovadina a když, aby jim bylo aspoň co nejméně.

    Jenže když víte, že se nic neděje, a že jste neomezený pán a vládce nad nějakým PHP - a že jak poručíte, tak milióny lidí budou skákat - a nejenomže budou skákat jak Vy pískáte, ale dokonce budou ostatní přesvědčovat, že chyba není v autorech, kteří debilně přeorávají PHP, ale v programátorech, kteří skákají méně a lízají autorům PHP z ruky méně, než si autoři přejí. A budou zakládat přesvědčovací aktivity typu GoPHP a přitom se zapomene tlačit na autory PHP a nebude se jim dávat jakožto opravdovým a skutečným viníkům toho, proč je situace v PHP taková jaká je najevo, že oni jsou Ti, kteří by měli brzdit. Pak proč byste si to pořádně promýšlel, že?

    PHP je taková Čapkova pohádka jak pejsek a kočička vařili dort a dali tam ze všeho dobrého kousek. Tu kousek C, tu kousek Perlu, tu kousek Javy, tu kousek .... a nakonec z toho bylo tomu kdo ho snědl hodně zle od žaludku.
  • 4. 2. 2008 22:31

    Lukáš Turek
    Slyšel jsi o jazyce Ada? Ten byl navržen přesně takhle, sešla se komise a navrhovala. Každá implementace musela přesně splňovat specifikaci, nic víc, nic míň. Výsledek byl že se jazyk nemohl vyvíjet a umřel, mimo vojenské aplikace v USA (kde byl povinný) se nerozšířil. Nezapomeň že i ta norma C vznikla až dodatečně, po tom co ze jazyk používal! Totéž například POSIX. Hezký příklad normy od zeleného stolu je ACPI: je tak složité (má i vlastní jazyk a bytecode), že ho výrobci nezvládají implementovat správně, a proto je problém s některými deskami v Linuxu (výrobce testuje jenom Windows).
  • 4. 2. 2008 23:19

    Miloslav Ponkrác
    A Vy si myslíte, že Ada se nepoužívá? Kde žijete? Ada není o tom, aby se volně vyvíjela - Ada je o tom, že dává silné záruky na spolehlivost!!! Neseženete spolehlivější programovací jazyk - a pokud je potřeba maximální spolehlivost a záruky, pak se sahá po Adě!!! Ada je velmi spolehlivý jazyk se silnými zárukama na spolehlivost, s velmi vysokou efektivností výsledného kódu blížící se jazyku C. Navíc existují i procesory, kde je k dispozici jen asm a Ada. Ada se bez problémů dá přeložit i na jednočipy. Vzhledem k účelům, proč byla Ada stvořena je postup jeho tvorby naprosto v pořádku!

    Ada samozřejmě nemá vše vyřešeno ideálně, ale to, že ho neznáte Vy, ani se v něm nebouchají formuláře do Windows, nebo do KDE neznamená, že je na nic.

    ISO norma jazyka samozřejmě nevzniká hned, on je to trochu dlouhodobější proces. Ale u jazyka C nebyly patrné "rozorávací" tendence jako u PHP, Ruby, Pythonu, Perlu a jinde. Naopak byly tendence sjednocovací a K&R C, ač nikdy nebylo normováno, byť jen volně popsáno se stále dá přeložit.

    Jinak to, že existuje norma neznamená, že musí být dobrá - ale jazyk bez normy (byť slespoň de facto) není dobrý ani perspektivní skoro nikdy. Norma je nutnou, ale nikoli postačující podmínkou, jak by se matematicky řeklo. Typickým příkladem asi nejhůře napsaných a domyšlených norem je skoro vše, co kdy stvořilo W3C.
  • 4. 2. 2008 15:13

    (neregistrovaný)
    Treba osobne se snazim vyvijet vse tak, aby to bezelo na php4 i php5 bez problemu. Testuji tedy na obou a za tu dobu jsem si tak nejak uz i vychytal styl programovani. Vyvijim na php5 a nenalezam problemy i kdyz to spustim na php4 a obracene.
  • 4. 2. 2008 15:51

    Michal Aichinger (neregistrovaný)
    Takze vlastne vyvijite v PHP4 a nevyuzivate zadnych vyhod PHP5 a tom je tady rec. Lidi jsou zasekli na tom aby jim to bezelo i na PHP4.
  • 4. 2. 2008 15:54

    Lukáš Turek
    Jo, ale pak nemůžeš používat výjimky, private/public metody, typovou kontrolu u funkcí apod. Obyčejné WWW stránky se bez toho obejdou (za cenu trochu ošklivějšího kódu), ale u něčeho většího bys asi narazil.
  • 4. 2. 2008 16:12

    Lukáš Turek
    Právě to je trochu mýtus, kvůli tomu že všichni zůstávají u PHP4 a neznají výhody PHP5. V PHP5 je typová kontrola parametrů funkcí, dědičnost, výjimky, MVC frameworky (např. Zend framework), nástroje pro unit testy (Simpletest), ...

    Mě proti např. Javě chybí namespace a privátní třídy (deklarované uvnitř jiné třídy), ale to vadí až u opravdu velkých projektů.
  • 4. 2. 2008 16:30

    freshmouse (neregistrovaný)
    Typová kontrola, pokud vím, umí kontrolovat jen objekty (ne základní typy jako int a string atd.). Koneckonců, PHP vzniklo jako netypový jazyk. Dědičnost byla snad i v PHP 4 (přestože osekaná, vzhledem k "všechny atributy a metodyjsou veřejné" stylu).

    Jmenné prostory se plánují do dalších verzí PHP (5.x). Vnořené třídy se nijak netýkají velikosti projektů, jako spíš stylu programování...
  • 4. 2. 2008 16:37

    Lukáš Turek
    Pokud máš velký projekt, na kterém dělá několik lidí najednou, tak se ti stane, že si 2 lidé pojmenují stejně nějakou pomocnou datovou třídu (která není součástí domluveného rozhraní). A tomu jde právě předejít buď jmennými prostory, a nebo vnořenými třídami (protože ta datová třída obvykle patří k nějaké jiné třídě, která je součástí rozhraní).
  • 4. 2. 2008 17:08

    freshmouse (neregistrovaný)
    Mně to nemusíš vysvětlovat. :-)

    Já jen řekl, že jmenné prostory budou, a že vnořené třídy nejsou úměrné velikosti projektu a souvisejí spíš se stylem programování...
  • 4. 2. 2008 22:23

    brblava_pani (neregistrovaný)
    Ono by se možná ušetřilo trochu emocí, kdyby si autor zprávičky přečetl aspoň titulní stránku té iniciativy a netvrdil, že jde o úplné opuštění PHP4. Ono je tam totiž celkem jasně napsáno, že "podepsané" projekty nebudou řešit PHP 4 ve feature releases - opravdu nemyslím, že by to znamenalo konec podpory pro PHP4 například u bugfixů. A u "podepsaných" hostingových firem je rozdíl ještě větší - Ty totiž nedeklarují nic víc, než že k 5. únoru budou nabízet tarify s PHP 5.2, přičemž tyto tarify budou defaultní volbou pro všechny nové objednávky.

    Celkem jasně je to vysvětleno ve FAQ:

    "Do I have to go out of my way to break PHP 4 in my project?"

    "No. The pledge is not to force projects to rewrite everything to try and break PHP 4. It's to focus on PHP 5.2 compatibility and not worry about earlier versions.

    ...

    The goal is not to force projects or developers to write code a certain way. It's to enable developers to use newer, more-powerful tools without worrying about 7 year old software. Which tools make the most sense is up to you."

    Jenomze to by to potom nebyla tak bombasticka zprava, a vubec by se k ni pak nehodil ten bulvarni titulek (ktery mimochodem rika pravy opak toho, co sama zpravicka), nemam pravdu?

    V diskusi vyse nekdo zminil, ze bychom meli tlacit spise na vyvojare PHP, aby z jazyka nedelali bramboracku. S tim plne souhlasim, ale to ma smysl pro budouci verze. Nemam ted momentalne prehled, jak daleko je vyvoj PHP6 nebo jak moc ma byt nekompatibilni, ale minimalne pro PHP7 by takova iniciativa stala za to.

    Dneska nema smysl chtit, aby treba 5.3.x bylo zase kompatibilni s radou 4.4, to by nebylo nic jineho, nez breceni nad rozlitym mlikem. A to bysme jeste mohli debatovat o tom, jak moc je to mliko vlastne rozlite, protoze zmeny, se kterymi jsem se (aspon ja sam) srazil, byly vic nez potrebne (konkretne mam na mysli objektovou orientaci a praci s XML).

    Tahle iniciativa - gophp5 - podle me miri prave timhle smerem - nebrecet, ale trosku urychlit prirozeny proces prechazeni k novejsim verzim.
  • 5. 2. 2008 10:01

    n00b (neregistrovaný)
    Všichni tady rozebíráte zpětnou kompatibilitu php4/php5, ale daleko důležitější je přístup k bezpečnosti v PHP. (on to bude spíš přístup k programování PHP devs ;-D)

    Jsem zvědavý jak to bude s Ruby. Co jsem slyšel tak pod pokličkou taky nic moc :-)