ugrás a tartalomhoz

Staking our future on PHP

gphilip · 2011. Ápr. 13. (Sze), 20.45
Javaslatok a PHP jövőjét illetően
 
1

Abszurd

prom3theus · 2011. Ápr. 15. (P), 15.55
Szociológiai szempontból azt hiszem tanulságosabb a poszt (vagyis inkább az abban linkelt eredeti poszt), a kommentek, mint amennyire technológiai szempontból az. Sőt, megkockáztatnám, hogy semmi újat nem mond azokon a rigmusokon túlmenően, mint amiket egyébként is hallani szinte minden elhivatottabb PHP fejlesztő szájából nap mint nap. Általában vannak közös pontok és azokon túl a funkcionális-fanok és az OO-fanok először szétválnak, aztán egymás torkának esnek.

Tulajdonképp csak azt szeretném megtudni, hogy szól-e ez a poszt másról, mint az évenként szokásos sírásról, miszerint "mi legyen a PHP-vel a jövőben?". Ezt a kérdést ugyanis visszatérően felteszik, aztán általában nem történik semmi jelentős.

Az egész PHP-s életérzés része, hogy egy koncepciótlan trágyadombon kell professzionális vagy "félprofesszionális" webalkalmazásokat írni. Mindeközben a Zend ül a kódokon és ontja ki magából az olyan típusú keretrendszert, amitől Rasmus Lardorf-nak az összes haja szála az égnek áll (és ennek szinte minden előadásán hangot is ad). Abszurd.
2

az ijeszto az, hogy kb. 5

Tyrael · 2011. Ápr. 15. (P), 22.20
az ijeszto az, hogy kb. 5 fajta improvement javaslat van:
- a csereljuk ki a needle-haystack sorrendjet
- a legyen xy feature (ahol xy mar egy evek ota letezo feature a php-ben)
- legyen tobb OOP
- legyen kevesebb OOP
- legyen a php node.js, mert az most meno

szoval elegge esz nelkul dobaljak be a kalapba az otleteket az emberek.

Tyrael
3

Tény, hogy lenne mit javítani rajta...

Arnold Layne · 2011. Ápr. 16. (Szo), 11.07
- a csereljuk ki a needle-haystack sorrendjet

Épp időszerű volna... :/
- legyen a php node.js, mert az most meno

Tanulhatna tőle ezt-azt ez tény és való, de azért nem volna okos ötlet egy-az-egyben lemásolni az egészet.
Mundjuk a $_GET, $_POST, $_FILES, $_COOKIE, meg a többi szuperglobális szerintem (is) eltakarodhatna a náthásba, helyette szvsz jobban mutatna még akár egy szem $_REQUEST is – ha már mindenáron ragaszkodnának páran a szuperglobálisokhoz – , amiben van a HTTP metódus, verzió, kérés fejlécek, meg a kérés törzse, aztán azt dolgozza fel magának a programozó, ahogy az jól esik neki.
4

Épp időszerű volna...

Tyrael · 2011. Ápr. 16. (Szo), 17.09
Épp időszerű volna... :/

altalaban aki ezt tartja legfontosabb problemanak, az nem tudja megmondani, hogy melyek azok az esetek, ahol nem stimmel a sorrend, es meg kellene valtoztatni.
amugy egyetertenek a szandekkal, csak szerintem nem akkora problema amennyire sokan emlegetik, egyszeruen ez ragadt meg az emberek fejeben mint hatalmas problema.

Tanulhatna tőle ezt-azt ez tény és való, de azért nem volna okos ötlet egy-az-egyben lemásolni az egészet.

megint nem mondtal semmi konkretumot. az event kezeles sokan emlegettek de altalanossagban bedobni olyan, minthogyha en azert tuntetnek, hogy node.js-ben/javaszcriptben/actionscriptben is lehessen siman strukturálisan/proceduralisan programozni.
tehat legyen benne sleep, es legyenek olyan blockolo hivasok, amivel megirhatom ugyanazt a kodot, amit most csak event handlerek segitsegevel.

bar most nagyon divatos, de szerintem nem kell minden programozasi nyelvnek teljesen event-driven-nek lennie, viszont valamilyen lightos(pl. GIL: http://en.wikipedia.org/wiki/Global_Interpreter_Lock) thread kezelessel teljesen jol event-drivenne lehetne tenni a PHP-t is, anelkul hogy nagyon bele kellene nyulni a kodba.
ezt en is szorgalmaztam mar: https://twitter.com/#!/Tyr43l/status/5318217312501760

itt az implementacio moriyoshi-tol:
https://github.com/moriyoshi/php-src/blob/PHP_5_3-threading/ext/threading/README

es most latom hogy valaki portolta Pthreads-re is:
https://github.com/alecgorge/php_threading


a nehany globalis valtozo felszamolasaval kapcsolatban nem latom hogy ki nyerne ezen barmit is. az OOP huszarok ugyis objecteken keresztul fogjak elereni ezeket az infokat, szoval nekik tok mindegy, hogy hol van eredetileg, a tobbiekkel viszont kibaszas lenne, mert N+1 helyen at kellene irni a meglevo kodbazist.

Tyrael
5

Szerintem a PHP nem sokat

gphilip · 2011. Ápr. 17. (V), 13.11
Szerintem a PHP nem sokat nyerne a threadinggel. Mivel normál esetben egy script egy requesthez fut le, nehéz olyan eseteket találni, amikor tényleg hasznát lehetne venni. A git repo ennek ellenére nagyon érdekes, köszi a linket!

Szerintem sok javaslat körül (mint a threading is) ott lebeg a ki nem mondott kívánság, hogy a PHP futhasson application serverként. Ehhez viszont szerintem a gyökeresen kellene megváltoztatni az egészet. Én szeretem a PHP-nak ezt a tulajdonságát, ti. hogy a per request execution jól igazodik a HTTP "stateless"-ségéhez, és legtöbb esetben nem a PHP a bottleneck teljesítmény szempontból.

Számomra sokkal fontosabb előrelépés lenne például a tesztelhetőség, a rengeteg függvénygyűjtemény összerendezése objektumorientált sémára (mint ahogy ez jelenleg zajlik is, de sajnos túl lassan).

Egyébként az "OOP huszár" úgy hangzik, mintha ez valami elkerülendő ostobaság lenne :P A függvény paraméter sorrend megváltoztatája mint javaslat nevetséges.
8

Szerintem a PHP nem sokat

Tyrael · 2011. Ápr. 17. (V), 18.36
Szerintem a PHP nem sokat nyerne a threadinggel.

az osszes olyan esetben, ahol szukseg lenne az async hivasokra, ott threadinggel ez kivalthato lenne.

hogy a PHP futhasson application serverként

en is inkabb maradnek a shared-nothing megoldasnal, jobban skalazodik (php-ban alapbol csak a default session handler ami skalazodasi szempontbol problema, minden mas szempontbol az adatbazisra van attolva a skalazodas problemaja), szoval egyetertek veled.

Számomra sokkal fontosabb előrelépés lenne például a tesztelhetőség, a rengeteg függvénygyűjtemény összerendezése objektumorientált sémára (mint ahogy ez jelenleg zajlik is, de sajnos túl lassan).

ezt kifejthetned reszletesebben. marmint hogy mi a problemad a php tesztelhetosegevel?
illetve hogy mely fuggvenynyujtemenyre gondolsz, a php-ban levokre? vagy a PEAR-ben? vagy a kulonbozo komponens libekre(Zend, Zeta, etc.)?

Egyébként az "OOP huszár" úgy hangzik, mintha ez valami elkerülendő ostobaság lenne :P A függvény paraméter sorrend megváltoztatája mint javaslat nevetséges.

alapvetoen OOP parti vagyok, de sokszor latom azt, hogy bizonyos emberkek nem racionalisan hasznalnak eszkozoket, patterneket, hanem "divatbol".
pl. sokadszor futok ossze olyann emberrel, aki ki szeretne szedni a php-bol a @-ot, mert hogy neheziti a debugolast, es ugyis csak a ganyhuszarok hasznaljak.
aztan mikor bedob az ember egy ket valo eletbol vett peldat, hogy "de hogy oldanad meg azt, hogy nem tudod elore hogy ott van-e az adott cache-file, es a file_exists es a beolvasas kozben letorolheti egy masik process, viszont le kell tudnod kezelni az esetlegesen kivaltott hibat es nem az error handlerbol szeretned ezt, ahol mar nincs meg kello mennyisegu informacio", vagy ilyesmi, akkor megy a hummoges.

Tyrael
6

Probléma?

_subi_ · 2011. Ápr. 17. (V), 13.21
altalaban aki ezt tartja legfontosabb problemanak, az nem tudja megmondani, hogy melyek azok az esetek, ahol nem stimmel a sorrend, es meg kellene valtoztatni


Vagy a probléma szó jelentésével nincsen tisztában. :)
7

Igen, kb ez az, amiért sosem

prom3theus · 2011. Ápr. 17. (V), 15.05
Igen, kb ez az, amiért sosem volt értelme feltenni teljesen nyíltan ezt a kérdést.

Általában a kívánságlista OO-ra:
- Legyen encapsulation, inheritence
- Legyen protected, static, stb., legyen late binding
- Legyenek mán setterek, getterek minden operátorra
- Legyen mán Dzsava...!

Általában funkcionálisra
- Ne legyen mán Dzsava!
- Dobjuk ki a settereket mer az feketemágia!
- Minek adattagot elrejteni, a programozó tudhassa hogy mi kell neki! Minek static, konstanst vagy globálist kell használni 'oszt jó' van!
- Szedjük mán ki az öröklődést, strukturált adatok tárolására elég egy Record típus is, vagy ott a tömbök!

Szóval...

Szerintem, ami bajos a PHP-vel:
1.) Igen is kusza az API-ja, igenis zavaró a needle-haystack probléma, és igenis probléma. Tény, hogy nem akkora mint sokan mondják, de attól mert kicsit az csak, még továbbra is probléma marad. Probléma, hogy a string függvények fele str_-sal kezdődik, a másik fele meg nem, és egyáltalán semmiféle logika nincs benne, hogy melyik miért.
2.) Problémás a unicode/UTF-8 kezelés, az mb_string kiterjesztés nem implementál egy csomó string fgv.-t.
3.) Sebességoptimalizálás. Akár bundled APC-vel, akár bármivel, csak legyen.
4.) Várom a natív típusok bundled OO implementációját. Az SPL ezirányú törekvése - khm - gyengusz. Vagy ha ez nem eléggé "PHP-like" dolog, akkor teljes operator overloading-ot.
5.) Szükség lenne multithreading-re.
6.) Szükség lenne arra, hogy a PHP-s kódok binárissá fordíthatóak legyenek, amit akár egy VM is futtathat, a lényeg az, hogy korrekt enterprise-level megoldásokat lehessen szállítani PHP-vel, míg a script parser-es (mondjuk LAMP) megoldások megmaradhatnak a "félprofesszionális" alkalmazások- és a "scriptpistikék" számára. Előfordulhatna az is, hogy multithreding-et csak a VM-ben támogatnám, mert "normális" esetben felesleges, sőt veszélyes is lehet.
7.) Event driven-séget feleslegesnek tartom, a keretrendszer dolga legyen az implementálás.
8.) Összeszedett, komoly, hivatalos keretrendszer kiadása. Lehetőleg olyané, amivel RAD-szerű környezetben lehet fejleszteni (.NET, Java?)...

Igazából azt sajnálom, hogy a PHP még ennyi év után is tényleg babajáték. Valóban, meg lehet vele oldalni rendkívül komplex alkalmazások felépítését, de nincs egy jól átgondolt és professzionális fejlesztésre alkalmas kerete ami a korhoz igazodna. Emellett ott a PHP évek óta igérgetett 6-os főverziója, amiből ha a fejlesztés így halad, 2021-ig biztosan várni kell...
9

- 1, szedd ossze a

Tyrael · 2011. Ápr. 17. (V), 19.34
- 1, szedd ossze a konkretumokat, es fel lehet venni a wiki-be proposalkent. ha csak fuggveny aliasokkal oldjak meg (ertsd: megmaradnak a regi inkonzisztens nevek is, csak mondjuk deprecated-kent), mar az is elorelepes.
- 2, 22.-en lesz egy eloadas Andrei Zmievski-tol a phpcon-on: The Good, The Bad & The Ugly: What Happened to Unicode in PHP 6 http://phpcon.org/speakers/#zmievski
szvsz ha nem akartak volna akkorat markolni a full unicode supporttal es kozben meg visszafele kompatibilisek is maradni, akkor nem lett volna nagyjabol kidobott ido/energia a php6 fejlesztese.
- 3, APC beepiteset a core-ba nem tamogatom szemely szerint, tulsagosan experimental benne egy csomo feature, meg amugy is xcache parti vagyok.
production kornyezetben amugy imho mar most is mindenki hasznal valamilyen opcode cache-t, szoval akiknek szukseguk lenne a plusz teljesitmenyre, azoknak ez a lepes mar nem segitene.
viszont Dmitry Stogov reszerol eleg sok performance improvement kerul be a nyelvbe, pl. az 5.3 a sok uj feature melle meg tudott hozni egy laza 20%os gyorsulast.
a php egyebkent imho nincs lemaradva pl. a python-hoz vagy a ruby-hoz kepest, de nagyobb beavatkozasok nelkul szerintem nem varhatoak jelentos gyorsulas.
pl. https://wiki.php.net/rfc/remove_zend_api
- 4, mi a bajod az SPL-es tipusokkal? amugy idonkent at szoktak szivarogni spl-es cuccok a nyelvbe, pl. spl_autoload, szoval nem elveszett dolog. operator oeverloading-ot nem tamogatnam, foleg nem ugy, hogy function overloading nincs, es nem is varhato a nyelvben.
- 5, szerintem "igazi" multithreading bekerulesere 0 az esely, internalson szepen ki lett targyalva, egyreszt a php core ugyan szalbiztos, de jelenleg kb. minden ugy van benne kialakitva, hogy csak 1 szal tudna biztonsagosan elerni az adatokat 1 futo scriptbol, plusz az atlag php fejleszto (mondjuk 98+ %) nem tudna hibatlanul mukodo multithreaded alkalmazast irni, viszont legalabb a fela megprobalna.
pedig a jelenleg blocker sync hivasokat hasznalo alkalmazasokat jol fel lehetne gyorsitani vele. :/
- 6, hiphop-php? amugy van tobb php interpreter(phc, Quercus, Roadsend) is, de a legnagyobb problema, hogy maga a nyelv ad-hoc modon van osszerakni, ezert nagyon nehez olyan interpretert csinalni, ami ugyanugy mukodik mint a zend engine. errol ment egy nagyon erdekfeszito beszelgetes itt: http://www.mail-archive.com/internals##kukac##lists.php.net/msg43428.html
- 7, ok, de ha a nyelv nem tamogatja az async utasitasokat, akkor nem tudod nagy hackeles nelkul (kulso process inditas) megoldani a normalis event driven kodot.
- 8, attol fugg mit ertesz alatta. a PEAR lett volna hivatott a "hivatalos" library gyujtemeny szerepet betolteni, de nagyon nem valtotta be a hozza fuzott remenyeket, a Zend meg kiadta a sajat lib gyujtemenyet, ami lehetett volna a kvazi hivatalos lib gyujtemeny, de ott meg a CLA alairasa tartja tavol a kozremukodoket. ennek kapcsan elindult most egy beszelgetes a kozossegen belul, egyreszt a PEAR felturbozasara, masreszt elkezdtek nehanyan dolgozni egy rubygems+bundler jellegu cucc megvalositasan, valamint szuletett egy otlet a jelenleg letezo kulonbozo PEAR repok kozponti elerhetosegevel kapcsolatban (http://blog.stuartherbert.com/php/2011/04/09/gathering-requirements-for-a-pear-channel-aggregator/ , http://packagist.org/), illetve letrejott egy http://pear.apache.org/ is az ASF tamogatasaval.

Emellett ott a PHP évek óta igérgetett 6-os főverziója, amiből ha a fejlesztés így halad, 2021-ig biztosan várni kell...

az megvan, hogy a PHP6-ot lefujtak, es ami mentheto volt az elkeszult fejlesztesekbol, azt adtak ki az 5.3-ban, illetve meg mindig nincs eldontve, hogy mi legyen a kovetkezo kiadas, bar a core fejlesztok egy kissebb csoportja mar megprobalt egy 5.4 alpha-t release-elni, de a tobbseg leszavazta, mert nem volt egyeztetes es dontes ezugyben?

ps: sorry, hosszu lett :/

Tyrael