A PHP nyelv "rebootja"
2011-10-11T11:38:00+02:00
2011-10-13T13:32:45+02:00
2022-06-30T06:06:17+02:00
  • A php 6 valóban nem egyenlő a php 5.3-mal, de Stingék nem is ezt állították, hanem azt, hogy a régi php 6-os projektet lezárták és beletették a php 5.3-ba és újraindították a php 6 fejlesztését az elejétől. Ha nem hiszed, akkor parancsolj, itt megtalálod az egyik php fejlesztőnek a témában írt blog post-ját. Ha ez nem volna elég, akkor a post belinkeli a php.net-en nyilvánosan elérhető fejlesztők közötti üzenetváltások közül a leglényegesebbet. Kicsit tovább olvasgatva az üzeneteket, megtalálod azt is, ami a merge-t bejelenti.

    A hivatalos verzió bejelentő üzenetekben miért várod, hogy benne legyen olyasmi, hogy hát, skacok, úgy gondoltuk, hogy ez lesz a php 6, de menet közben meggondoltuk magunkat és pár dolgot kihagyva belőle kiadjuk 5.3-ként?
    Mutasd a teljes hozzászólást!
  • "The whole development series which was meant to be PHP 6 has been pushed aside to a branch, and development is starting anew based on the 5.3 release. Anything of value in the old PHP 6 branch can be cherry-picked from there as need be, but the process of what is going into the next release is beginning from scratch, and one assumes that proposals will be looked at closely. There are no timelines or plans for the next release at this point [..] So timing and features for the next PHP release are completely unknown at this point. Even the name is unknown; Jani's 5.4 branch has been renamed to THE_5_4_THAT_ISNT_5_4. There has been some concern about all of those PHP 6 books out there; it has been suggested that a release which doesn't conform to expectations for PHP 6 should be called something else - PHP7, even." (forrás)

    Magyarul: ami PHP 6 lett volna eredetileg, az PHP 5.3 lett. PHP 6 pedig jó eséllyel soha nem is lesz, pontosan azért, hogy ne legyen keveredés ebből.

    Vagy még rövidebben összefoglalva: ULTIMATE FAIL a részedről.

    Egyébként a Duke Nukem Forever hasonlatot arra értettem, hogy a PHP 6-ot a DNF-hez hasonlóan évekig ígérgették, majd végül az 5.3-as ág (és afölött) megvalósítottak belőle _néhány_ dolgot.

    Persze. Mese habbal. Ugyanis a DNF-et végül kiadták - míg a PHP6-ot nem és soha nem is fogják. Ezért rossz a hasonlatod. Csak ezt egészen eddig nem tudtad, mert hogy gőzöd sem volt arról, hogy a PHP6-ból időközben már PHP5.3 lett.

    Mondjuk tök mindegy is, mert ettől függetlenül sem tudtál egyetlen észérvet mondani egyetlen állításod alátámasztására sem.
    Mutasd a teljes hozzászólást!
  • Értem. Tehát a hipotézisedet cáfoló tényadatokat figyelmen kívül szeretnéd hagyni, és csak az igazoló tényadatokat figyelembe venni. Igen tudományos és szakmai megközelítés.

    Ezt te állítod. Én ezt nem állítottam.

    Ez nem "PHP alternatíva"

    Tehát egy alternatív verzió nem alternatíva. Akkor mi? http://idegen-szavak.hu/alternatív

    Már ugyan miért? Mert már egyébként megint bukik az elméleted?

    Nem azért, hanem mert nem tartom értékelhetőnek az olyan összehasonlításokat a vita szempontjából, amelyek szerint az alma != körte.

    Egyébként meg a PHP-ről beszélünk még mindig. Amiről te közölted, hogy "csigalassan fejlődő nyelv"

    Érdekes, hogy tőlem idézel olyan kifejezést, amit az egész szálban egyedül te használtál. Akkor most kivel vitatkozol tkp?

    Nem mellesleg ezt az állításod sem igazoltad még semmivel.

    És nem is fogom. Tartsd problémának - vagy aminek szeretnéd. Ha ennyire ragaszkodsz az igazoláshoz, akkor fáradj az állításom ellenkezőjének igazolásával te. Szerintem ez a kijelentésem triviális, nem fogok időt fordítani rá az életemből, hogy még igazoljam is azt, ami triviális.

    Ilyen alapon a C-nek, a C++-nak, a C#-nak, a Java-nak és az összes magasszintű nyelvnek is annyi behoznivalója lenne az assembly-hez képest, hogy össze se lehet írni.

    Kifordítod a szavaimat és összemosod az állításaimat azokkal a dolgokkal, amiket te gondolsz - vagy valami mással, ez mindegy.

    Azt már ne is említsük, hogy az előbb az akartad, hogy csak szkriptnyelvekről beszéljünk, ha már valamiről! Azokhoz képest még érdekesebb lenne és még nagyobb figyelemmel hallgatnám, hogy szerinted hol és miként kellene és lehetne a - te megfogalmazásodban - "hiányosságait" behoznia a PHP-nak.

    Számos számtalan felvetés született már erre. Használj google-t vagy olvass többet a PHP körüli dolgokról. Azért, mert az ismereteid hiányosak, ne engem korholj kérlek, hanem vedd a fáradtságot és járj utána.

    Semmi személyeskedő megjegyzést nem tettem.

    Ezzel szemben: "De ebből is látszik milyen jól képben vagy PHP-t illetően... " valamint "Tehát látom ezt is jól áttekintetted... ". Ezeket a megjegyzéseket Te minek tartod? De teljesen mindegy minek, ha egyszer egyébként ez személyeskedés.

    Amit én közöltem az tényinformáció

    Ha ez így van, várom a bizonyítást.

    Bár azt, hogy nem tudsz és ezért nem is akarsz vitatkozni vele, azt látom.

    A következtetésed merőben téves: a tudásom és az akaratom között nem áll fenn ilyen kapcsolat. Ha mégis, arról előre szólni szoktam, de legalábbis utólag belátom.
    Mutasd a teljes hozzászólást!
  • PHP 6.0 mennyire != PHP 5.3 vitaszálhoz még adalék:
    1. PHP 6 Roadmap
    2. PHP 5.3.0 Release Announcement
    3. PHP 5.3.3 Release Announcement

    5.3 ágon ezek az érdemibb kiadások, a bugfix és security kiadásokat is átnéztem, de nem tartom lényegesnek őket a vita szempontjából

    Szerinted csak a unicode támogatás hiányzik a 6-oshoz képest az 5.3-ból - én meg kigyűtöttem az eltéréseket, tehát hogy mi nincs az 5.3-ban és minek kéne lennie benne, ha neked lenne igazad:
    - 1 Unicode (Unicode on/off modes, Different String Types, Extension upgrading, Bundling ICU, Filename Encoding, Collator Caching, Optimising [], Locale Sensitivity, Conversion Errors)
    - 2.12 old type constructors: roadmap szerint maradnia kellett volna, 5.3.3-ban részlegesen (névtér alá sorolt osztályoknál) mégis kivették.
    - 2.14 break $var: csak az 5.4-es ágban fogják eltávolítani.
    - 3.3 Move ereg to PECL: ehelyett deprecated lett.
    - 3.7 Fix ext/soap and add support for wsse/secext: nem, vagy nem teljesen történt meg (a SOAP kiterjesztést még mindig be kell kapcsolni, szemben a roadmap-ben írttal).
    - 4.2 Adding "goto": szemben a roadmap-ben írttal mégis csak lett goto és nem a break utasítás lett kiterjesztve label jump-pal.
    - 4.4 Allow foreach syntax for multi-dimensional arrays: nem történt meg.
    - 5.8 Type-hinted properties and return values: szemben az ott írtakkal, nincs mód típusosan visszatérő függvények deklarálására.
    - 5.11 ReflectionClass cache in zend_class_entry* and support "$this::class": igaz, nem esik szó róla külön, de a $this::class alak tudomásom szerint nincs támogatva (logikusan: mivel nem vetették el a támogatását, feltehetően támogatnia kéne a PHP-nek ezt a formát).
    - 6.1 Add an opcode cache to the distribution (APC): az ott írtakkal szemben az APC mai napig PECL kiterjesztés.
    - 6.10 Read-only properties: bár felvetődött a nyelvi implementáció lehetősége is (nem vetették el, az ott írtak szerint foglalkozni fognak a kérdéssel), a mai napig nem támogatja a PHP a read-only jellemzők használatát nyelvi szinten (__set megkerülés létezik csak).

    Egyébként a Duke Nukem Forever hasonlatot arra értettem, hogy a PHP 6-ot a DNF-hez hasonlóan évekig ígérgették, majd végül az 5.3-as ág (és afölött) megvalósítottak belőle _néhány_ dolgot. Mindezekhez képest az 5.4-ben pedig bevezetnek legalább egy olyan funkcionalitást, amiről szó sem volt a 6-os roadmap-jében (traits). Nem állítom, hogy haszontalan (sőt), nem állítok semmi mást, mint azt, hogy PHP 5.3 nagyon nemegyenlő PHP 6.
    Mutasd a teljes hozzászólást!
  • Évekig fejlesztettem benne. A kérdésedre viszont nem szeretnék válaszolni - csak szubjektív válasszal tudnék válaszolni rá, flame-et pedig nem akarok.

    Értem. Tehát nem tudsz egyetlen valódi érvet sem felsorakoztatni állításod mellett.

    Nyilván érdemes lenne megvizsgálni a kivételes esethez feltételezhetően kapcsolódó kivételes körülményeket is a kérdés tovább boncolásához. Ezt viszont én nem szeretném megtenni, mivel a C nem szívügyem és másra szeretnék koncentrálni.

    Értem. Tehát a hipotézisedet cáfoló tényadatokat figyelmen kívül szeretnéd hagyni, és csak az igazoló tényadatokat figyelembe venni. Igen tudományos és szakmai megközelítés.

    "PHP alternatívák? Mint pl.?"
    Lásd ebben a bejegyzésben: PHP Hacking.

    Ez nem "PHP alternatíva" (hiszen csak implementációs optimalizációs patchek gyűjteménye, ami azonban a nyelv alapszerkezetét semmilyen szempontból nem érinti), és nem több, hanem egy darab. Tehát továbbra is várom a "PHP alternatívák" megjelölését.

    Ne keverjük már össze a szezont a fazonnal. Beszéljünk lehetőleg a PHP-ról és ha már nagyon más nyelvről kell beszélni, beszéljünk más szkript nyelvekről.

    Már ugyan miért? Mert már egyébként megint bukik az elméleted?

    Egyébként meg a PHP-ről beszélünk még mindig. Amiről te közölted, hogy "csigalassan fejlődő nyelv". A "lassú" viszont relatív fogalom, ami önmagában értelmezhetetlen. Ezért kellett a képbe hozni más nyelveket is, amikhez képest már lehet értelmezni ezt a fogalmat.

    Én pontosan ezt (ti. más, relativitási alapot képező nyelvek képbe hozását) tettem meg - és ez alapján kiderült, hogy mégsem lehet annyira csigalassan fejlődő az a PHP, hiszen az említett mainstream nyelvek mindegyikét lekörözi fejlődési sebességben.

    A PHP messze nem a leghatékonyabb nyelv az elérhető webes nyelvek között és szerintem ezt talán te is belátod. Márpedig itt erről van szó.

    Nem, te nem ezt mondtad. Nem mellesleg ezt az állításod sem igazoltad még semmivel. Nem mintha bármilyen hasonlóan általános érvényű kijelentés igazolható és igaz lehetne. Az ugyanis, hogy mi a leghatékonyabb, mindig a konkrét feladattól és a meghatározó egyéb peremfeltételektől függ.

    Amikor azt panaszolom, hogy lassan fejlődik, azt értsd úgy, hogy késve reagál a kor igényeire és hiányzik belőle az előrelátás. Sebesség tekintetében a PHP-nak annyi behoznivalója lenne, hogy össze se lehet írni.

    Ilyen alapon a C-nek, a C++-nak, a C#-nak, a Java-nak és az összes magasszintű nyelvnek is annyi behoznivalója lenne az assembly-hez képest, hogy össze se lehet írni. Nyilván a dolgok nem így működnek. Ráadásul megint nem említettél egyetlen konkrétumot sem, hogy ti. mégis miben kellene és lehetne gyorsítani rajta (anélkül ugye, hogy az előnyöket közben elvesztenénk). Tehát ez az állításod is a levegőben lóg, teljesen hiteltetlenül, objektív ellenőrizhetetlen módon.

    Azt már ne is említsük, hogy az előbb az akartad, hogy csak szkriptnyelvekről beszéljünk, ha már valamiről! Azokhoz képest még érdekesebb lenne és még nagyobb figyelemmel hallgatnám, hogy szerinted hol és miként kellene és lehetne a - te megfogalmazásodban - "hiányosságait" behoznia a PHP-nak.

    A személyeskedő megjegyzéseket pedig kérlek, te is hanyagold.

    Semmi személyeskedő megjegyzést nem tettem. Egyszerűen megállapítottam egy nyilvánvaló tényt: azt, hogy halvány lila gőzöd sincs a PHP-ről (mert egyébként tudta volna, hogy a korábban PHP 6-nak tervezett verzió végül PHP 5.3-ként jelent meg, már évekkel ezelőtt). Ami persze nem akadályoz meg abban, hogy bőszen oszd az észt róla.

    A logikai sorlezárók megszűntetése nekem is furcsa - ugyanakkor az is tény, hogy fordítót írni ezzel együtt is lehetséges, maguk a sorlezáról pedig egyébként feleslegesek (a PHP sem soronként értelmezi a kódot, akkor meg minek?).

    És még azt mondod, hogy nem egy zöldfülű takonnyal vitázom? Aki még azt sem érti, hogy mi a jelentősége a logikai sorelválasztóknak, "mikor a PHP sem soronként értelmezi a kódot"?

    "Szóval ennek a PHP rebootnak valójában annyi köze lesz a PHP-hoz már a jelenlegi tervek szerint is, mint amennyi a C#-nak, vagy akár a LISP-nek van hozzá: semmi"
    :: Ebben szerintem óriásit tévedsz. De szubjektív véleménnyel nem vitázok - megtartom a flamereknek

    Összekeversz magaddal. Amit én közöltem az tényinformáció - semmi szubjektív nincs benne. Bár azt, hogy nem tudsz és ezért nem is akarsz vitatkozni vele, azt látom.
    Mutasd a teljes hozzászólást!
  • Én bármiféle személyeskedés nélkül fenntartom, hogy nagy butaságokat írsz, és egyetértek Sting-el.
    Már megbocsáss, de azok alapján amit írtál, vajmi keveset tudsz a PHP-ről, illetve annak fejlesztési folyamatáról, az meg hogy az 5.3 = 6, nem csacsiság, konkrétan a hónapban beszélgettem egy a PHP fejlesztésében aktívan résztvevő személlyel többek között erről.

    Amit linkeltél PHP "alternatíva", a nevében is benne van, hogy hacking. Ezt te is megteheted, forkolhatod, átírhatsz benne pár dolgot, de ezt rajtad kívül senki más, vagy csak nagyon kevesen fogják használni. Konkrétan az ilyen módosítgatások általában hobbiprojektek, nem szolgálják az adott nyelv közösségét, sőt inkompatibilitást eredményez, nehezíti a frissítést, stb. Ugyanakkor ha egy kicsit is gondolkodnál, ahelyett, hogy összevissza írogatsz mindent, egy nyelv fejlesztése nem olyan egyszerű. A fejlesztőknek eléggé megfontoltan, és lassan kell haladniuk, a nyelvre létezik jó pár keretrendszer, CMS, és kész alkalmazás, amelyek a nyelv drasztikus módosításakor teljes újraírást igényelnének. Ebből fakadóan hiába jönne ki egy nagy változásokat hozó új verzió, senki nem frissítene épp emiatt, így értelme se lenne az egész fejlesztésnek.

    Hol tartanak a PHP és a többi script nyelv?
    Hol? A PHP tökéletesen megfelelő arra amire való. Fejlesztettünk benne sokszerveres nagy terhelésű rendszereket, amik tökéletesen működtek bármilyen sebességbeli és egyéb probléma nélkül. Sőt, egy másik cégnél dolgozó ismerősöm százas nagyságrendű szerverparkkal bíró szolgáltatás alá fejleszt PHP-ban. Akkor miről beszélünk? Persze, vannak a nyelvnek hiányosságai, ugyanakkor ***minden nyelvnek vannak hiányosságai***. Írj Node.JS-ben CPU igényes alkalmazást, vagy futass RoR alatt Redmine-t mod_passangerrel, és próbáld meg az alapjáraton lévő memóriafogyasztását 1 GB alá szorítani. Vagy sebességbeli összehasonlításra gondolsz? A Node.JS nyilván gyorsabb lesz mint a PHP bizonyos esetekben, de ez nem a nyelvből fakad, hanem abból, hogy a Node.JS aszinkron, a PHP-val ellentétben. Egyébként én a neten lévő "szintetikus" tesztekre alapozva nem nagyon vonnék le következtetéseket, ugyanis valós fejlesztési feladatoknál egészen más eredményeket is produkálhatnak a nyelvek.
    Mutasd a teljes hozzászólást!
  • Bár totál offtopic ez a szál itt, de te mikor láttál utoljára Delphi-t? Egyáltalán láttál -e valaha? Miben elmaradott szerinted a Java-hoz, C#-hoz, ASP.NET-hez képest?

    :: Évekig fejlesztettem benne. A kérdésedre viszont nem szeretnék válaszolni - csak szubjektív válasszal tudnék válaszolni rá, flame-et pedig nem akarok.

    Olyanra gondolsz, mint pl. a C, ami annak ellenére, hogy az őt továbbfejleszteni és leváltani hivatott C++ már lassan 30 éve létezik

    :: Kivételek előfordulhatnak egy-egy esetben, ez kétségtelen. Nyilván érdemes lenne megvizsgálni a kivételes esethez feltételezhetően kapcsolódó kivételes körülményeket is a kérdés tovább boncolásához. Ezt viszont én nem szeretném megtenni, mivel a C nem szívügyem és másra szeretnék koncentrálni.

    PHP alternatívák? Mint pl.?

    :: Lásd ebben a bejegyzésben: PHP Hacking. Egyébként PHP fork alatt is erre hivatkoztam a korábbi hozzászólásaimban. Személyszerint pedig a PHP Reboot-ot is alternatívának tekintem, így indokoltnak tartom a többesszám használatát.

    Nem mondom, hogy nem fejlődhetne akár sokkal gyorsabban is, de azért pl. a C++-hoz képest még mindig villámsebesen fejlődik. Utóbbi ugye a mostani előtt utoljára egy évtizeddel kapott frissítést. De mondhattam volna a Java-t is, ami szintén csigalassan halad előre. Állítólag két év múlva már tud lambda kifejezéseket is kezelni - amit a C++ szintén csak most kapott meg, de amit pl. a PHP már csuklóból nyom évek óta.

    :: Ne keverjük már össze a szezont a fazonnal. Beszéljünk lehetőleg a PHP-ról és ha már nagyon más nyelvről kell beszélni, beszéljünk más szkript nyelvekről. V.ö. hol tart a PHP és hol tartanak a több szkript nyelvek. A PHP messze nem a leghatékonyabb nyelv az elérhető webes nyelvek között és szerintem ezt talán te is belátod. Márpedig itt erről van szó. Amikor azt panaszolom, hogy lassan fejlődik, azt értsd úgy, hogy késve reagál a kor igényeire és hiányzik belőle az előrelátás. Sebesség tekintetében a PHP-nak annyi behoznivalója lenne, hogy össze se lehet írni. Minek ezt sorolni ahhoz, hogy értsük egymást?

    Igen, mivel a PHP 6 kvázi át lett nevezve PHP 5.3-ra (ami több mint két éve jelent meg stabilban) - mivel a teljeskörű Unicode-támogatást (beleértve Unicode karakterek használatának lehetőségét az azonosítókban, osztálynevekben is, aminek mondjuk szerintem abszolút semmi értelme) egyelőre kihagyták. De ebből is látszik milyen jól képben vagy PHP-t illetően...

    :: Az 5.3 fejlesztői ága jó ideig - legalábbis ezt állították - párhuzamosan futott a 6-os ággal. Messze nem csak a teljeskörű unicode support-ról van szó, de tény, hogy ez lett a 6-os ág egyik vesszőparipája.
    A személyeskedő megjegyzéseket pedig kérlek, te is hanyagold. Nem egy zöldfülű takonnyal vitázol, de ha így lenne, a másik ember irányába tanúsotott tisztelet képessége akkor is univerzális érték maradna - nem véletlenül.

    Persze. Meg mellesleg meg akarja szüntetni a logikai sorelválasztót (...), meg mellesleg a $-jelölést is a változókhoz (ami akár jó ötlet is lehet, bár ez önmagában teljesen PHP-idegenné teszi ezt az új "dialektust", ami így biztosan nem lesz képes futtatni egyetlen sor PHP-kódot sem teljes konverzió nélkül). Tehát látom ezt is jól áttekintetted...

    :: A logikai sorlezárók megszűntetése nekem is furcsa - ugyanakkor az is tény, hogy fordítót írni ezzel együtt is lehetséges, maguk a sorlezáról pedig egyébként feleslegesek (a PHP sem soronként értelmezi a kódot, akkor meg minek?). A $-jel elhagyását kimondottan üdvözlöm. Felesleges, sokszorta kimondottan idegesítő is.
    A személyeskedő megjegyzésre itt is csak annyit reagálnék, hogy szerintem ez nem egy kocsma - de javíts ki, ha tévedek.

    Szóval ennek a PHP rebootnak valójában annyi köze lesz a PHP-hoz már a jelenlegi tervek szerint is, mint amennyi a C#-nak, vagy akár a LISP-nek van hozzá: semmi

    :: Ebben szerintem óriásit tévedsz. De szubjektív véleménnyel nem vitázok - megtartom a flamereknek.
    Mutasd a teljes hozzászólást!
  • Hogy egy kicsit előre szaladjak: a Node.JS nem azért jött létre, hogy a JS hibáit kiküszöbölje, hanem azért, hogy legyen szerveroldali JS értelmező is - ha már adott egy remek programozási nyelv, legyen adott kliens és szerver oldalra is.


    - szerveroldali JS értelmező a Node.JS előtt is volt
    - a Node.JS azért jött létre mert egy fejlesztő szeretett volna egy aszinkron szerver oldali nyelvet létrehozni
    - a PHP alternatívákra, amikről írsz, én is kíváncsi lennék
    - ahogy előttem is írták a PHP 6 már kiadásra került, csak nem 6-os verziószámmal
    - végül de nem utolsó sorban a PHP teljesen jó arra amire való. Ahogy más nyelvek is. Ugyanúgy ha a Node.JS-t elkezdenéd használni CPU intenzív feladatok megvalósítására, lehetne szidni, mivel arra épp alkalmatlan, de nem is arra találták ki.
    Mutasd a teljes hozzászólást!
  • Ezzel egyúttal Sting-nek is válaszolnék az előző bekezdésemet folytatva: tisztában vagyok vele, hogy mind a Pascal-t, mind a Delphi-t valószínűleg a mai napig van olyan fejlesztő, aki használja valamire. De jellemzően nem ez a main-stream, elmaradt technológiák amikkel csak specifikus eseteket lehet talán valamivel hatékonyabban megoldani, mint mondjuk Java-ban, JSP-ben, C#-ban vagy ASP.NET-ben

    Bár totál offtopic ez a szál itt, de te mikor láttál utoljára Delphi-t? Egyáltalán láttál -e valaha? Miben elmaradott szerinted a Java-hoz, C#-hoz, ASP.NET-hez képest?

    Tehát a feltételezésem abból ered, hogy a történelem általában önmagát ismétli. Leszálló ágra jutó nyelvek hosszú stagnálás után pedig általában arra pár évre kezdenek el eltűnni (és átadni a helyüket másnak), amikor megjelennek az ilyen "jobbító" szándékú alternatívák

    Olyanra gondolsz, mint pl. a C, ami annak ellenére, hogy az őt továbbfejleszteni és leváltani hivatott C++ már lassan 30 éve létezik, még mindig kétszer népszerűbb platform utóbbinál (sőt, miközben a C++ népszerűsége éppen csökkenőben van, a C-é nő)?

    C# is van tíz éve, aztán annak is alig egy harmada a részesedése a C-hez képest, és egy ötöde az összes C/C++/ObjC megoldást egybeszámítva.

    A PHP alternatívák viszont egyöntetűen azért jelennek meg

    PHP alternatívák? Mint pl.?

    mert a PHP évek óta a várakozások alatt teljesít minden téren

    Nem mondom, hogy nem fejlődhetne akár sokkal gyorsabban is, de azért pl. a C++-hoz képest még mindig villámsebesen fejlődik. Utóbbi ugye a mostani előtt utoljára egy évtizeddel kapott frissítést. De mondhattam volna a Java-t is, ami szintén csigalassan halad előre. Állítólag két év múlva már tud lambda kifejezéseket is kezelni - amit a C++ szintén csak most kapott meg, de amit pl. a PHP már csuklóból nyom évek óta.

    Tehát ez a várakozások alatt teljesítő és csigalassan fejlődő nyelv, a PHP, előbb implementál újdonságokat, mint pl. a C++ vagy a Java. Érdekes.

    (a Duke Nukem Forever hamarabb került kiadásra, mint a PHP 6).

    Igen, mivel a PHP 6 kvázi át lett nevezve PHP 5.3-ra (ami több mint két éve jelent meg stabilban) - mivel a teljeskörű Unicode-támogatást (beleértve Unicode karakterek használatának lehetőségét az azonosítókban, osztálynevekben is, aminek mondjuk szerintem abszolút semmi értelme) egyelőre kihagyták. De ebből is látszik milyen jól képben vagy PHP-t illetően...

    A PHP-fork esetében erről például szó sincs, a PHP-Reboot esetében is csak olyan módosításokat sorol a készítő, amikért a közösség évek óta veri a tamtamot a PHP coreteam-nél és már 1-2 éve se számítottak volna újdonságnak.

    Persze. Meg mellesleg meg akarja szüntetni a logikai sorelválasztót (ami önmagában agyrém, utoljára egyes BASIC nyelvjárásokban volt ilyen, de egyetlen modern mainstream nyelv sem alkalmazza ezt, értsd: mindegyikben van logikai sorlezáró), meg mellesleg a $-jelölést is a változókhoz (ami akár jó ötlet is lehet, bár ez önmagában teljesen PHP-idegenné teszi ezt az új "dialektust", ami így biztosan nem lesz képes futtatni egyetlen sor PHP-kódot sem teljes konverzió nélkül). Tehát látom ezt is jól áttekintetted...

    Szóval ennek a PHP rebootnak valójában annyi köze lesz a PHP-hoz már a jelenlegi tervek szerint is, mint amennyi a C#-nak, vagy akár a LISP-nek van hozzá: semmi. Egyszerűen csak ez az ember (mármint a PHP.reboot kitalálója) vagy nem tudja miről beszél, vagy direkt kvázi manipulatív, marketing-céllal hívja PHP.reboot-nak a projekjét, meglovagolandó a PHP népszerűségét, amihez azonban az alkotásának még annyi köze sem lesz, mint amennyi pl. a C++-nak van a C-hez.
    Mutasd a teljes hozzászólást!
  • azért szerintem a Yii rendesen tele van tervezési hibával... példa rá az eval.

    Ez miért is jó példa rá? És te hogyan is oldanád meg egyszerűbben és gyorsabban a dinamikus kifejezéskiértékelés problémáját?

    Csak a sebességre mentek, de ha betekintesz a core-ba lesz párszor az az érzésed, hogy miért nem pattern-t használ?

    Mármint milyen patternt?

    A sebességről meg... nem fordít futtatható állományt mint a java persze, hogy lassabb.

    Az ugye megvan, hogy a Java sem közvetlenül futtatható állományba fordul, hanem bájtkódra - és, hogy kvázi ugyanilyen bájtkód kerül futtatásra akármelyik normális PHP telepítésen is? Sőt, van kifejezetten .exe-be fordító, bájtkód alapú kiterjesztés is PHP-hez, de ha a már említett eval()-t és társait kihagyod, akkor akár valódi natív kódba is fordítható.
    Mutasd a teljes hozzászólást!
  • azért szerintem a Yii rendesen tele van tervezési hibával... példa rá az eval. Csak a sebességre mentek, de ha betekintesz a core-ba lesz párszor az az érzésed, hogy miért nem pattern-t használ?

    A sebességről meg... nem fordít futtatható állományt mint a java persze, hogy lassabb.
    Mutasd a teljes hozzászólást!
  • Furcsálltam is, hogy a V8-at ennyire előre helyezte. Nem olyan rég, pár napja olvastam egy cikket ami a Node.JS teljeítményével foglalkozott és nem igazán arról győzött meg, hogy a Node (ami V8 alapú) olyan száguldó-erőd típus lenne. Igaz, ott Node vs Python és Ruby összehasonlításról van szó, nem PHP-ról, és erről a kettőről úgy tudom, hogy gyorsabb is a PHP-nál - a V8 viszont valószínűleg még így is gyorsabb a PHP-nál.

    Ilyen szempontból abban teljesen igazad van, hogy a mérnöki bravúr a meghatározó tényező, és ebben a jelenlegi PHP - a legfinomabban szólva - nem jeleskedik. Valószínűleg az 5.4-es sem fog.

    Az interpretált nyelvek interpreterei nagyon komoly fejlődésen mentek keresztül az elmúlt pár évben. Nem akarok apokalipszist vizionálni, de nem tudok elmenni amellett, hogy ilyen fejlődés a PHP-nél nem igazán érhető tetten. Itt-ott beletákolnak, kap egy kis ilyen cache-t meg olyat, opcode cache és memcached support, oszt' "Sándor".

    Ezzel egyúttal Sting-nek is válaszolnék az előző bekezdésemet folytatva: tisztában vagyok vele, hogy mind a Pascal-t, mind a Delphi-t valószínűleg a mai napig van olyan fejlesztő, aki használja valamire. De jellemzően nem ez a main-stream, elmaradt technológiák amikkel csak specifikus eseteket lehet talán valamivel hatékonyabban megoldani, mint mondjuk Java-ban, JSP-ben, C#-ban vagy ASP.NET-ben. A Borland Pascal és a Delphi sírját sem a "konkurens" Free Pascal ásta meg, de annak felbukkanása is jelezte már, hogy a fejlesztők türelme elfogyott a változásra való várakozás alatt. A Free Pascal sosem tudott felfutni komolyabban, de megjelenésétől számítva a Delphi és az Object Pascal alig pár év alatt kivonult a köztudatból és ma már a fejlesztők 80%-a legszívesebben azt is letagadná (vagy le is tagadja) hogy valaha fejlesztett ezeken a nyelveken.

    Tehát a feltételezésem abból ered, hogy a történelem általában önmagát ismétli. Leszálló ágra jutó nyelvek hosszú stagnálás után pedig általában arra pár évre kezdenek el eltűnni (és átadni a helyüket másnak), amikor megjelennek az ilyen "jobbító" szándékú alternatívák. Ez egy folyamat eleje: nő a csalódottság, nő a változásra való igény mértéke, a kereslet kínálatot hoz, a kínálatból pedig valami kiemelkedik majd. Hogy egy kicsit előre szaladjak: a Node.JS nem azért jött létre, hogy a JS hibáit kiküszöbölje, hanem azért, hogy legyen szerveroldali JS értelmező is - ha már adott egy remek programozási nyelv, legyen adott kliens és szerver oldalra is. A PHP alternatívák viszont egyöntetűen azért jelennek meg, mert a PHP évek óta a várakozások alatt teljesít minden téren (a Duke Nukem Forever hamarabb került kiadásra, mint a PHP 6 ). Megint más az, amikor dialektusok versenyeznek egymással: ott arról van szó csak, hogy egyik nyelvjárás miben tud többet nyújtani a nyelv szintjén a másiknál és az eredetinél. A PHP-fork esetében erről például szó sincs, a PHP-Reboot esetében is csak olyan módosításokat sorol a készítő, amikért a közösség évek óta veri a tamtamot a PHP coreteam-nél és már 1-2 éve se számítottak volna újdonságnak.

    Bocs, hogy hosszú lett.
    Mutasd a teljes hozzászólást!
  • A cikkhez hozzászólva, az evalért nem kár. Én biztosan nem fogom siratni, mert eddigi PHP-s pályafutásom alatt még egyszer sem használtam. Ki az aki igen és nem tagadja le?

    A template- ill. markup-alapú frameworkökben legtöbbször elengedhetetlen a használata. Pl. a Prado és a Yii is használja, amik azért igen alaposan megtervezett frameworkök, és a velük készült programok is jellemzően nagyon rendesek. Szóval azért nem olyan evidens a mellőzése.

    Én egyébkén nem igazán látom, hogy a JVM-től mitől függ gyorsabban futni ez az új PHP. Mert hogy opcode cache esetében már így is nagyon gyors tud lenni, a másik meghatározó faktor, a dinamikus típuskezelés overheadjén meg ez nem fog segíteni semmit.
    Mutasd a teljes hozzászólást!
  • jó lenne ez, viszont csak saját szerveren tudnám használni, nem hiszem, hogy a tárhelyszolg. cégek közt elterjedne majd.
    Mutasd a teljes hozzászólást!
  • A cikkhez hozzászólva, az evalért nem kár. Én biztosan nem fogom siratni, mert eddigi PHP-s pályafutásom alatt még egyszer sem használtam. Ki az aki igen és nem tagadja le?
    Mutasd a teljes hozzászólást!
  • Nem vagyok én a PHP, mint nyelv ellen, de tény ami tény: néhány helyütt gány és pokoli lassan fejlődő nyelv, rengeteg olyan rárakódott szeméttel, amire ma már semmi szükség nem lenne

    Ebben a mondatban a PHP helyett a C-től kezdve a Pascal-ig elég sok komoly múltra visszatekintő, ma is használt nyelv neve is szereplhetne, és ugyanannyira igaz maradna. Ennek ellenére mindegyik úgy-ahogy, de él és virul. Sőt, sokan akik a PHP-t leszólják, ezen két nyelvet meg istenítik. Pedig ugyanannyi szemetet hordoznak magukkal azok is.

    Szóval ezek a dolgok a jelek szerint önmagukban nem olyan nagy hátrányok, ami miatt temetni kellene egy nyelvet. Függetlenül attól, hogy vannak hátrányai is.
    Mutasd a teljes hozzászólást!
  • Itt egy összehasonlítás sokkal több nyelvvel

    A lényeg végülis nem az, hogy melyik verzió pontosan mennyivel lassabb, hanem az, hogy dinamikus típusokkal rendelkező nyelveket nehezebb gyorsítani, mint a statikusan típusosakat.

    Persze a nyelv és futtatókörnyezet fejlesztőinek mérnöki képességei is vetnek a latba emellett valamit. (Pl. a Java 1999 előtt egy viszonylag amatőr interpreterrel rendelkezett, de 1999-ben jött a JIT-elés, és azóta már nem sok alacsonyan függő gyümölcs van a témában: a JAva teljesítménye már igen közel van egy C-ben vagy akár ASM-ben írt programokéhoz.)
    Vagy pl. mérnöki bravúrnak tekinthető, hogy a fenti listában a V8 nevű Javascript motor annyira fent van annak ellenére, hogy a JAvascript nagyonis dinamikusan típusos nyelv. (Itt a V8 olyan erős versenyt generált, hogy más böngészők megvalósításai is ezen szint köré csoportusulnak ma már. Szóval a kiélezett verseny csodákra képes.)

    De összességében az az ökölszabály - feltételezve, hogy a nyelv futtatókörnyezete elég profin meg van csinálva - hogy a statikusan típusos nyelvek a gyorsabbak, méghozzá legtöbbször jelentősen.
    Mutasd a teljes hozzászólást!
  • Átnéztem az oldalt, meg a hozzá kapcsolódó cikket is. Némileg megkérdőjelezhetővé teszi az ott közölteket, hogy sehol, semmilyen információt nem közöl a nyelvek verziójáról sem, sem pedig arról, hogy azokat mi vette körül (PHP esetében például a fordítási beállítások, az engedélyezett lib-ek, a használt kiszolgáló vagy ha nem kiszolgálón keresztül ment a teszt, akkor a CLI mód jelzése, stb). A Java kiszolgálóról sem közöl semmilyen érdemi információt: melyik alverzió, mikori kiadás, milyen update (7.0-tól 7.0.9-ig felteszem eltelt némi idő, marginálisan változhattak a futás sebességét befolyásoló elemek)...

    De rendben van, elfogadom, hogy a PHP jóval lassabb a Java Server 7-nél. Csak azt nem tudom jelenleg eldönteni, hogy melyik PHP milyen beállítások mellett melyik Oracle iPlanet Web Server 7-nél lassabb... sebaj, majd utánajárok.
    Mutasd a teljes hozzászólást!
  • A PHP-re kezd igencsak rájárni a rúd. Nem rég egy core developer fork-olt saját PHP verziót amiben nagyon fontos javításokat (és sebesség-optimalizálásokat) hajtott végre, egy időben nem kis visszhangot keltve ezzel, most pedig ez a próbálkozás ver még egy szöget a PHP koporsójába. Nem vagyok én a PHP, mint nyelv ellen, de tény ami tény: néhány helyütt gány és pokoli lassan fejlődő nyelv, rengeteg olyan rárakódott szeméttel, amire ma már semmi szükség nem lenne (az oldalon hivatkozott magic_quotes csak az egyik ilyen a sok közül), fejlesztőinek pedig egyre kisebb érzéke van arra nézvést, hogy az alkalmazói közösségének milyen eszközökre lenne szüksége a nyelvben.

    Őszintén: nem várom, hogy ez a PHP variáns megváltja a világot, de a fentiek fényében egyre kevésbé tartom elképzelhetetlennek akár ezt is. 6 évnyi PHP után nekem inkább tűnik úgy, hogy a PHP fejlesztését magyar politikusok irányítják, semmint úgy, mint ami mérnöki munka gondos eredményeként jött és jön létre.

    Követni fogom ezt a fejlesztést, mert ígéretesnek tűnik. Ha többen is rákapnak, még akár hype is kialakulhat körülötte és akkor a jelenleg ismert PHP-nak meg lesznek számlálva a napjai. Én bizony nem siratnám meg.
    Mutasd a teljes hozzászólást!
  • Hogy performancia-témában mennyire mozgok otthonosan, annak megítélését - ilyetén kérdésem/kérésem hiányában - megtartanám magamnak, ha nem haragszol (ha igen, akkor is - bocs).


    Mutasd a teljes hozzászólást!
  • A phprebootelképzelései szépek. Főleg a $ és ; elkerülése és a natív SQL és URI használat a kódban ami különösen szimpatikus.

    A jó kérdés az, hogy egy ilyen használható rendszernek mennyi időbe kerülne beépülnie az IT mindennapjaiba.
    Mutasd a teljes hozzászólást!
  • Mivel nem területem a Java, ez engem újdonságként ért. Hogy performancia-témában mennyire mozgok otthonosan, annak megítélését - ilyetén kérdésem/kérésem hiányában - megtartanám magamnak, ha nem haragszol (ha igen, akkor is - bocs).

    Egyébként köszi a választ.
    Mutasd a teljes hozzászólást!
  • Látom a performancia témának az alapjaival sem vagy tisztában.
    A Java jellegű mainstream erősen típusos nyelvek már legalább 10 éve JIT-elve vannak és elég rendesen vannak optimalizálva.
    Természetes, hogy egy Java jellegű nyelvvel performanciában csak hasonló, erősen típusos managed nyelvek (pl. C#) versenyezhetnek, és egyértelműen csak a C/C++ jellegű nyelvek verhetik meg, de azok is csak pár tíz százalékkal.
    A dinamikus nyelvek performancia optimalizálásában is komoly erőfeszítések vannak az utóbbi évtized(ek)ben, de azokat mindenképpen nehezebb gyorsítani, mint pl. a Java-t. A PHP természetesen jóval lassabb, mint a Java, de hát ez nem hír. Az lenne a hír, ha dinamikussága ellenére gyorsabb lenne.

    Benchmark:

    Java vs. PHP performance comparison
    Mutasd a teljes hozzászólást!
  • A prog.hu hír.

    Szép, szép (átfutva a hírben hivatkozott projektoldalt is), csak ezt a részt nem tudom értelmezni:
    fast as Java thanks to a runtime profiler/optimizer and JSR 292 API

    Eszerint már ott tartunk, hogy a PHP még a Java-nál is lassabb? Ha igen, akkor komoly baj van...
    Mutasd a teljes hozzászólást!
abcd