"A Facebook átírta a PHP runtime-ot"

Címkék

Az SD TIMES BLOG egyik bejegyzése szerint a Facebook nem volt megelégedve a PHP sebességével, ezért a saját főhadiszállására hívta a PHP core fejlesztőit, aláíratott velük egy titoktartási nyilatkoztat, majd egy megbeszélésen titokban felvázolt számukra néhány új, Facebook-támogatott nyílt forrású projektet.

Noha a projekt titkos, Alex Handy azt állítja, összerakta a részleteket és rájött, hogy miről van szó: a Facebook 0-ról újraíratta a PHP runtime-ot. Handy állítja, hogy ezzel kapcsolatban kedden egy nagy bejelentésre készül a Facebook és nyílt forrásúként közzé is teszi a projektet. Pontos részleteket nem ismer, de azt tudja, hogy a Facebook felvett valakit két évvel ezelőtt arra, hogy megcsinálja ezt a melót, és abban is majdnem biztos, hogy egy emberes projekt keretében folyt a munka.

Később, egy frissítésben arról ír, hogy a Facebook feltehetően valamiféle fordítóval áll elő a PHP-hoz.

A részletek itt olvashatók.

Hozzászólások

Gondolom azt szerette volna írni, hogy elég lett volna egy lol is, nem pedig az, hogy meghemperegsz a lolban a földön és közben leröhögöd a segged is mellé. :-P
_______
Powered by Áram // Nem vagyok annyira kocka, hogy napfényt is csak HDR-Renderingen keresztül lássak.

Boven megterul nekik. Tobb mint 10 ezer szerver eseten nehany szazaleknyi teljesitmenynovekedes 100+ gep felszabadulasat jelenti...

ahaha, dehat facebook is php-t hasznal, biztosjo!

--
NetBSD - Simplicity is prerequisite for reliability

szerintem errefele eddig sem a sebességét szidták, hanem hogy csúnya. Mindig is tudtam, hogy a programozás egy művészet, és a használt programnyelv szintaxisának konzisztenciája, esztétikai minősége kulcsfontosságú egy projekt megítélése során.

—-—-—
int getRandomNumber() {
	return 4;//szabályos kockadobással választva.
}		//garantáltan véletlenszerű. xkcd

1) tokeletesen tudom, mi az a tranzakcio, sot, szoktam is hasznalni, bar keruljuk (mint minden normalis ember, igyekszunk atomi muveletekre bontani, es minimalizalni a tranzakcios felteteleket)
2) Dolgoztam EJB-vel, felveteliztem belole cegnel, fel is vettek, bar azota se nyultam EJB-hez (max natur hibernate+spring). Sot, olvastam a 2.1 es 3.0 EJB szabvanyokat is.
3) PHP alatt is vannak classloaderek

Az, hogy miert nem hasznalja a Sun, kerdezd azokat, akik a Sunnal vannak :) En ugy tudom, mar nem fejlesztenek veluk.

Egy nyelvet az expresszivitasa hatarozza meg, a keretrendszereket pedig hogy mennyire kenyelmesen illeszkedik ahhoz, amit tobbsegeben csinalnak vele.

Nezd mar meg, hogy mit muvelnek a Java 7-ben Closure ajanlatkent, ha az neked expressziv...

A PHP es keretrendszerei viszont ezerszer jobban illeszkednek a webes fejleszteshez (miert kell kulon managed beaneket irni, amik delegaljak a feature-eiket egy EJBRemote-nak? Ha mar delegaljak, a nyelvben miert nincs nyelvi szintu delegalas?), mint a java.

Nyilvan a Facebook frontendjei is ezert lettek PHP-ban irva (a fooldal is)

Ja. A PHP-ba legfokeppen sz.t lapatolnak, a nyelv ehhez kenyelmesen illeszkedik. Latod, vegre valami, amiben egyetertunk.

PHP classloaderek. Juj. Eleve az objektumorientalt PHP faj sokszor, de hogy vannak classloaderek is... "Kicsi vagyok, szekre allok, onnan egy nagyot kialtok".

A Java web-hez pedig _nem_ kotelezo a EJB-k hasznalata, lehet pure JSP/JSF/Servlet-et meg JPA-t is hasznalni, ha valakinek az kell. Az EJB csak egy hasznos valami, de van elet rajta kivul is. Foleg most a JAX-RS koraban.

Es csatlakoznek a velemenyhez: a nem tudas nem mentesit.
--


()=() Ki oda vagyik,
('Y') hol szall a galamb
C . C elszalasztja a
()_() kincset itt alant.

Koltoi kerdes: vajon csak az ertelmezot irjak ujra a teljesitmenynovekedes miatt, vagy az API-t is tisztitjak, es a PHP6-ban, 7-ben, n+1-ben bevezetik az ujat, szebbet, es nyilvanosan kivegzik azokat akik a haystackes parametersorrendinkonzisztenciakat kialakitotta???

szinte biztos, hogy bc-re odafigyelnek, hiszen nekik nem erdekuk ujrairni az egesz alkalmazast, csak azert hogy szebb legyen a kod.
az viszont megerte, hogy 2 evig fizettek 1-2 core php fejlesztot, hogy javitson/gyorsitson az ertelmezon, mert minimalis teszteles utan, kodmigracio nelkul atallhatnak a jobb/gyorsabb futtatokornyezetre.

Tyrael

> szinte biztos, hogy bc-re odafigyelnek, hiszen nekik nem erdekuk ujrairni az egesz alkalmazast, csak azert hogy szebb legyen a kod.
Hat azert a megvaltozott API-ra valo atteres nem egyenlo az ujrairassal, es idonkent megeri, ha attol a tovabbi fejlesztes konnyebb lesz.

Persze ez csak kukacoskodas. Egyebkent egyetertek, ezert is irtam, hogy koltoi kerdes.

Hogy lehet nyilt forraskodu es titkos ? :D

Végülis megtehetik:

GPL licensz részlet:

Ha valaki például ilyen program másolatait terjeszti, akár ingyen vagy bizonyos összeg fejében, a szoftverre vonatkozó minden jogot tovább kell adnia a fogadó feleknek. Biztosítani kell továbbá, hogy megkapják vagy legalábbis megkaphassák a forráskódot is, valamint jelen dokumentumban lévő a licencfeltételeket is el kell juttatni hozzájuk, hogy tisztában legyenek a jogaikkal.

Azaz, ha a PHP továbbadja a forráskódot a Facebook-nak, akkor nem sért GPL-t. A Facebook meg megtarthatja magának, amennyiben akarja.

Szerintem OpenGL gyorsítást tesznek bele, hogy legyen facebookra is kompiz kocka.
Igen, trollkodtam.

"The way to find what the mainstream will do tomorrow is to associate with the lunatic fringe today." -- 1995, Jean-Louis Gassée
/ http://haiku-os.org /

igen, de miért szerveroldalon, és ha ott, akkor miért PHP-ban? Szerintem a komoly renderelési feladatokat, amiket már nem bíznának az amúgy szépen fejlődő kliensoldali technológiákra nem PHP-ban célszerű megoldani.
Esetleg akkor látnám létjogosultságát, ha tényleg nincs más és ha valami kliensoldali technológiának szerveroldali fallbackre van szüksége.

Feltehetném, ha nem botlanék lépten-nyomon Pythonban írt desktopalkalmazásokba, amelyek alapján a PHP-val ellentétben a Pythont nem elsősorban szerveroldali programozási nyelvnek tekintem (bár arra is jó).

—-—-—
int getRandomNumber() {
	return 4;//szabályos kockadobással választva.
}		//garantáltan véletlenszerű. xkcd

Erre próbáltam én is utalni. Minden nyelv arra jó, amire használod. Egyik kicsit jobban, másik kevésbé. PHP-t is lehetne scripting nyelvként alkalmazni és a Pythont is webes fejlesztőeszköznek, mivel már mindkettőnek van OpenGL bindingje és képes szerver oldalon is futni. Basicben is meg lehet még ma is írni egy játékot (sokan meg is teszik. Lásd BlitzMax), de én soha vissza nem térnék, mert C++-t preferálom. Mindenki el tudja dönteni, hogy melyik nyelvet mire akarja használni. Mi ezzel a baj?

vannak nyelvek, amelyek alkalmasabbak egy adott célra, és azt kérdőjeleztem meg, hogy webes 3d tartalom készítéséhez pont a PHP lenne-e a legmegfelelőbb néhány marginális esetet leszámítva. Kedvelem a PHP-t, de adott esetben nem nyúlnék hozzá :)
Nincs semmi baj ezekkel a projektekkel, mindig örülök, ha valaki csinál valamit, nekik biztos jólesik. De gyakorlati alkalmazhatóságát korlátosnak tartom.

—-—-—
int getRandomNumber() {
	return 4;//szabályos kockadobással választva.
}		//garantáltan véletlenszerű. xkcd

Szerintem pedig egyszerűen hagyományos grafikai programok elkészítéséhez, a PHP azért már egy jó ideje több, mint egyszerű webes programozási nyelv. Elég sok dologgal használható, gondolom a PHP-GTK-t sem a webre szánták.

-----
"Egy jó kapcsolatban a társunkat az ő dolgában kell támogatni, nem a miénkben."

Ooo... hany helyen? Mondj nagy PHP-ban irt desktop alkalmazasokat. Esetleg desktopokat. En eddig csak kis vacak projekteket lattam PHP-ban irva, a komolyabbak elvergodnek a perl/python/ruby-ig.
--


()=() Ki oda vagyik,
('Y') hol szall a galamb
C . C elszalasztja a
()_() kincset itt alant.

PHP-CLI egy hasznos dolog, használom aktívan is: webes alkalmazásokhoznál kiegészítő cron scriptekre és mindenféle konfigoló eszközre.

PHP-GTK egy ok nélküli fasság. Ha ablakolni akarok, akkor indítok egy visual studio-t és összekattintgatom C#-ban WinForms-szal az ablakot. Gyorsabb, hatékonyabb, jobb, megbízhatóbb.

----------------
Lvl86 Troll