Yahoo stapt over op PHP

Yahoo heeft tijdens een presentatie op PHPCon 2002 bekend gemaakt dat het bedrijf overstapt op PHP, schrijft Slashdot. De presentatie van Michael Radwin, Yahoo-engineer, geeft onder meer een schematisch overzicht van de serversoftware die het bedrijf door de jaren heen gebruikte en waar men naartoe wil in de toekomst. Verschillende scriptingtalen worden tegen het licht gehouden en het bedrijf meent daaruit voor zijn doel de beste gekozen te hebben. Overigens mag PHP dan als meest bruikbare gekozen zijn uit onder meer Perl, ASP en J2EE, maar dat neemt niet weg dat de heren en dames van Yahoo nog redelijk wat aan het product zullen gaan knutselen. Niet alle door Yahoo gewenste functies zitten namelijk al in PHP. Ook hield de keuze van Yahoo wellicht een kleine nederlaag voor Microsoft in, nu Yahoo - mede door licentiekosten - niet kiest voor ASP. Redenen om uiteindelijk voor PHP te kiezen, zijn er legio:

So Why Did We Pick PHP?

1. Designed for server side web scripting
2. Large, Open Source developer community
   • integration, libraries
   • documentation & training
3. Debugging & profiling tools
4. Simple and clear syntax (fits Y! paradigm)
5. Performs well in our tests
• efficient (with acceleration)
• small enough memory footprint

Reacties (92)

[ToAoM]

Hun voornaamste reden is dat alleen PHP fatsoenlijk op het BSD platform draait.

Java gebruikt threads, en die worden niet ondersteund doro BSD, zelfde reden geldt voor Coldfusion (welke ook op JAva draait).

Perl valt af "omdat het niet voor het web ontwikkeld zou zijn"

en ASP moet voor betaald worden...

Ach, het zijn eigenlijk de raarste argumenten om je keuze op te laten baseren. Ik zou ook m'n server platform onder de loupe hebben genomen. Wanneer veel betere performance gehaald zou kunnen worden met bijvoorbeeld Coldfusion op Linux, maar ja, wie ben ik

Daarnaast geldt dat ze niet wensen te betalen voor hun ontwikkeltaal, maar vervolgens wel een sloot peon lappen voor een fatsoenlijke query en template cache voro PHP, want PHP zelf bakt daar helemaal niets van...

[Blubber]

En ander argument wat ze tegen CF aandragen is dat de syntax 'lelijk' is. Vindt ik eerlijkg gezegt geen argument...

[Dennis]

Het argument tegen Perl is nog vager. Behalve dat het niet voor het web zou zijn zeggen ze ook dat het op teveel manieren kan worden geschreven.

Ik neem aan dat, voor welke taal je ook gebruikt, je vantevoren duidelijke richtlijnen opstelt hoe er moet worden gecode.

[Verwijderd]

Ik zou niet graag grote programmaŽs willen schrijven met Perl. Met Perl zijn de variabelen her-en-der uit te lezen. Je kunt er niet gestructureerd mee werken.

[Virtox]

met Perl zijn variabelen her en der uit te lezen
kan niet gestructureerd
Als je niet weet waar je het over hebt, moet je er niet over praten. Ik gok dat je wellicht eens wat slechte perl source gezien heb, maar dat kan ik elke taal.
Als je netjes programmeert in perl kan je vars gewoon "lokaal" houden, en het is juist een super gestructureerde taal.
En ja je kan perl net schrijven alsof het basic is maar dan ben je zelf niet goed bezig.
(Ik ben Perl-programmeur van beroep en schrijf regelmatig grote programma's in perl, geen enkel probleem)

[YaPP]

probeer eens

[code]#!/usr/bin/perl -w

use strict;[/code]

reken maar dat je geen rare dingen meer kan doen, en variabelen MOET declareren.

'Grote' Perl dingen werken echt wel: http://www.codingdomain.com/cgi-bin/x-forum.cgi Of check http://www.kasuto.net/cgi-bin/x-forum.cgi voor een toffe grote implementatie. (mocht je kritiek willen leveren: houd dan wel rekening met de doelgroep die dit forum heeft)

Perl niet voor het web? Tja... 'CGI' heeft een aantal problemen die met mod_perl deels uit de weg worden geruimt... enne.. Perl is al sinds het begin van het internet gebruikt voor cgi-acties, omdat gespecialiseerd is in dataverwerking (van veel data) om vervolgens een output te genereren.

[Verwijderd]

Ik moet altijd maar laggen om de verhitte reacties op programeertalen. De meeste daarvan zijn dan ook nauwelijks onderbouwd en uiterst subjectief. Iedereen recht op zijn eigen mening natuurlijk, maar er zijn belangrijkere zaken dan een specifieke programeertaal.

Neem bijvoorbeeld de architectuur die gebruikt wordt om een bepaald doel te berijken, software technisch gesproken dan. Daar komt toch veel meer bij kijken, zoals wat voor OS, webserver, database en custerering (in geval van erg grote sites) er gebruikt moet worden.

Ook over het genereren van de uiteindelijke webpagina's vallen nogal wat keuzes te maken.

Ga je bijvoorbeeld voor 100% scheiding tussen content en data toepassen? In dat geval is een gelaagde architectuur met XML generatie vanuit een bepaalde scripttaal en een XSLT transformatie in combinatie met specifiek voor de toepassing getunde caching toch wel een van de meest voor de hand liggende en best presterende.

In zo'n geval is de keuze voor de script taal al bijna geheel irelevant. Als je daarintegen de gehele oplossing met alle SQL statement en HTML opmaakcode in een scripttaal zelf wil gaan toepassen met niet standaard 'templates' in de scripttaal zelf, ja dan is de taal natuurlijk wel relevant. Dit is overigens wel een stokoude methode en bedrijven doen hun best om deze ramperiode in de geschiedenins van software ontwikkeling te ontvluchten. Er blijft zo verdomde weinig structuur in de code over en de kans op vooral domme fouten neemt daarmee hand over hand toe.

Ook de manier waarop zoekopdrachten uitgevoerd worden en data uit de database wordt gehaald is natuurlijk erg bepalend de voor de prestatie van het uiteindelijke systeem. Stored prodecures zullen in vrijwel alle gevallen veel sneller zijn dan wat dan ook in een scripttaal gedaan kan worden. Gewoon vanwege betere lokaliteit.

Dit is geheel ongeacht welke scriptaal gekozen wordt. Aangezien bij architectuur (en de prestaties daarvan ) de lokaliteit van alle bewerkingen die nodig zijn om tot een eindresultaat te komen van doorslaggeven belang is. Dit is ook weer bepalend voor de hoeveelheid hardware men er tegenaan moet gooien om het geheel behoorlijk te laten presteren.

Er zijn natuurlijk grenzen en in het optimale geval maak je een gelaagde architectuur waarbij de data als het ware van de database naar de browser stroomt, en waarbij iedere stap in dit process een maximale lokatiteit vertoond. En de laatste stap is in dit process natuurlijk het cachen van gegevens. In dit scenario is de scripttaal niet meer dan veredelde lijm die alle andere delen van het systeem (OS, internet server, database, XML/XSLT transformatie) met elkaar verbind. Een soort van regelneef dus, niet meer en niet minder. Niet zo'n spannende keuze dus .

Als ik de post goed heb gelezen zijn deze zaken niet zo getetaileerd behandeld en alles wijst erop dat er gekozen is voor PHP en daaromheen de architectuur is opgebouwd uit semi kant en klare stukken code. Men moet zelfs de functionaliteit van de taal nog uitbreiden .

De argumentatie die men aandraagd om voor PHP te kiezen lijkt er als het ware later bijgezocht. Als men eerst onafhankelijk van de scripttaal had gekeken, en eerst de architectuur had uitgewerkt (en daarvoor genoeg kennis in huis had), dan was de samenstelling van de producten en daarmee waarscheinlijk ook de scripttaal toch een andere geworden.

Wens ze overigens veel success, zo geredeneerd hebben ze een hoop problemen op te lossen, en kunnen ze zich behoorlijk in de nesten gaan werken met de oplossing die ze nu hebben.

We zullen het wel merken, ze hebben tenslotte geld zat om enkele dozijnen ontwikkelaars hun favourite hobbie te laten uitvoeren.

Just myt 2 cents

[RvdH]

Het is jammer dat je je eigen post onderuit haalt door de vele spelfouten, bij "laggen" hield ik op met lezen.

[steit]

is laggen niet de verleden tijd van liggen

Ik lag, wij laggen?

of is laggen het verschijsel waarbij men op de grond gaat liggen van het lachen?

sorry het is vrijdag .....

[SirBlade]

Argument 2 is er volgens mij door de Yahoo marketing-afdeling bijgezet. Open Source developer community is een zo'n heerlijk woord voor marketing en management, politiek correct en staat prachtig in reclame, persberichten en verslagen. Ze maken mij niet wijs dat MS een enorme (potencieele) klant als Yahoo niet zou voorzien van libraries, documentation & training.

Dat neemt niet weg dat het best kan zijn dat PHP beter is als ASP op de andere punten (ben geen programmeur, kan dit niet beoordelen).

[Verwijderd]

Wees gerust SirBlade,

Ook ontwikkelaars kunnen in dit soort discussies zelden het hoofd koel houden en helder denken. Een programeertaal is voor velen een soort van geloof, iets van mijn taal is beter dan de jouwe.

Dat er argumenten zijn om voor een bepaald product voor taal A or juist voor taal B te kiezen lijkt de meesten dan ook te ontgaan. Je krijgt dan vaak vage argumenten met nog vagere onderbouwing (als die er al is), waarom de taal van ontwikkelaar A beter zou zijn dan de taal van ontwikkelaar B.

Een hoop ontwikkelaars zijn er dan ook gewoon ingerold vanuit hun bestaande werk, of hebben een aantal korte opleidingen gevolgd om snel in de IT aan de slag te kunnen gaan (toen het nog zo geweldig ging). Niets mis mee natuurlijk, er is altijd vraag naar meer mensen geweest, maar als gevolg daarvan zijn er nu relatief weinig mensen met genoeg ervaring om zulke zaken los van 'geloof' te beoordelen, en die mensen willen wel hun mening uiten.

Een mooi voorbeeld is dat iemand die VBScript of juist PHP geleerd heeft alles in die taal probeerd op te lossen. Niet wetende dat een hoop dagelijkse problemen beter in SQL of XML/XSLT opgelost kunnen worden. Je krijgt daardoor functionaliteit op plaatsen waar het niet idiaal is om onder te brengen. Het komt dus voornamelijk door een te smalle horizon. En in gewoon nederlands: te weinig ervaing met verschillende talen en geen kennis van architectuur.

Je moet er dan ook niet al te zwaar aan tillen dat je bepaalde delen niet goed kan volgen. De meesten van ons kunnen dat ook niet, er wordt gewoon veel geschreeuwd.

En tussen haakjes:

ASP is zelf geen programeertaal maar bied een interface met de webserver en het OS (d.m.v. Componenten). Binnen ASP kunnen diverse scripttalen gebruikt worden, waarvan VBScript waarschijnlijk de meest gebruikte is, gevolgd door JScript.

Again, Just My 2 Cents

(getting poor now)

[Verwijderd]

Op zich wel verwonderlijk maar niet onbegrijpelijk.

Heb zo'n beetje al de 3 scripttalen wel onder m'n fikken gehad en allemaal hebben ze hun voor en zeker ook hun nadelen.

En eigenlijk als zo'n grote organisatie je binden aan een standaard lijkt me niet zo slim. Je zou eerder meerdere kampen willen gebruiken die tegen elkaar gaan concurreren. Dan haal je eerder het onderste uit de kan.

Of bouw gewoon je eigen tussenlaag die implementatie van alle varianten ondersteund en blijf je onafhankelijk van allemaal. En baseer die op XML structuren die je intern standaardiseerd en laat inspereren door bestaande ideeen. Dan kun je ook langzaam aan een totaaloplossing werken waar ze nu dus vet problemen mee hebben.

Ze zeggen wel geen C++ te willen gebruiken. Maar ik vind het halfbakken argumenten IMO. Want als het op snelheid aan komt kun je daar in de meeste gevallen toch wel het snelste performance van halen. Maar ja daar lopen ze nu van te balen omdat naar alle waarschijnlijkheid hun software niet goed is meegegroeid. Naar alle waarschijnlijkheid een minder ontwerp van begin af aan. (In veel van de gevallen die ik tegengekomen ben was dat zo nl.)

[Verwijderd]

Ze zeggen wel geen C++ te willen gebruiken. Maar ik vind het halfbakken argumenten IMO. Want als het op snelheid aan komt kun je daar in de meeste gevallen toch wel het snelste performance van halen.

Je hebt het hier over RUNTIME "snelheid" maar in een grote organisatie als Yahoo! lijkt het mij ook belangrijk dat de applicatie flexibel is; dat deze, zonder moeilijke, trage en/of bugprone compile-processen geupdate kan worden.

[steit]

Way to go TheCodeForce, bij het lezen van de titel kreeg ik al het idee 'en Mulisch schrijft voortaan met BIC pennen'.
(maar jou uitleg is iets completer :-)

[YaPP]

hehe.. veel wijsheid, maar ik vraag me of of je voor wijsheid echt zoveel woorden nodig hebt. :-/

De grap is, dat ik laatst zelf op school een onderzoekje heb moeten maken over server-side-scripting. (waarbij ik ook rekening moest houden met verschillende architecturen, en opgestelde criteria) Daar kwam uit dat iedere taal geschikt is voor scripting, afhankelijk van de situatie

Houd er wel rekening mee, dat er behalve veel gescheeuw, iedereen elkaar ook iets probeert bij te brengen over zijn wereld (in de hoop dat je begrepen word, denk ik) Misschien niet de meest effectieve aanpak, maar wel begrijpelijk.

[Verwijderd]

Onvoorstelbaar!

Punt 1: Gij zult Model / View / Controller scheiden

Het is de eerste les in professioneel ontwikkelen. De verwevenheid van HTML en PHP maakt dit zeer moeilijk. Dat dit acceptabel is in kleine tot middelgrote projecten is nog tot daar aan toe. Maar Yahoo behoort niet tot deze categorie. Onvoorstelbaar!


Punt 2: Yahoo is geen website, maar een transactieplatform

Yahoo heeft enorme back-end koppelingen en transactie systemen om die een miljard dollar omzet te kunnen halen. Of dacht je dat het uit bannertjes voorkwam. Waarom kiezen voor een webtaal, terwijl je een transactieplatform bent. Onvoorstelbaar!

Punt 3: Gij zult een eerlijk vergelijk maken

De presentatie met 'WHY NOT ....' pagina's is een lachertje. Java omdat het multithreaded moet zijn. Welke andere omgeving is nog acceptabel in de 21e eeuw? Nergens tref je de overweging aan om FreeBSD eruit te trappen. ColdFusion syntax is lelijk, hahahahaha! Perl is te krachtig, hahahahaha! De presentatie is echt achteraf in elkaar geflanst. Onvoorstelbaar!

Conclusie:
De keuze voor PHP was waarschijnlijk al gemaakt, voordat de criteria gedefinieerd waren. Veel andere talen zijn en ontwikkelplatformen zijn beter schaalbaar, beter geschikt voor transacties, hebben betere 3rd party ondersteuning en zijn ook opensource.

Gefeliciteerd PHP community, meen ik oprecht! Yahoo is veel beter voor PHP dan PHP voor Yahoo.

[Verwijderd]

Punt 1: Gij zult Model / View / Controller scheiden

Het is de eerste les in professioneel ontwikkelen. De verwevenheid van HTML en PHP maakt dit zeer moeilijk. Dat dit acceptabel is in kleine tot middelgrote projecten is nog tot daar aan toe. Maar Yahoo behoort niet tot deze categorie. Onvoorstelbaar!

PHP met HTML erin verweven is een keuze, ik weet niet of je je wel eens verdiept hebt in bijvoorbeeld Smarty, maar het is best mogelijk om MVC te implementeren hiermee.

Punt 2: Yahoo is geen website, maar een transactieplatform

Yahoo heeft enorme back-end koppelingen en transactie systemen om die een miljard dollar omzet te kunnen halen. Of dacht je dat het uit bannertjes voorkwam. Waarom kiezen voor een webtaal, terwijl je een transactieplatform bent. Onvoorstelbaar!

Ik meende ergens hierboven te lezen dat Yahoo! niet haar complete applicatie zal om gooien maar slechts delen. Verder is PHP ontwikkelt in C (wat denk ik, in jouw ogen meer "transactieplatform-waardig" is), dus ik snap niet helemaal wat je hiermee wilt zeggen...

[justice strike]

ze hadden volgens mij veel beter servlets kunnen gebruiken. daar kan je alles zo coden zoals je het wil/nodig hebt.

nu moeten ze aan php knutselen om het te maken zoals ze het nodig hebben.

[Verwijderd]

het zou kunnen, maar de perfomance van java is veel lager dan php, daarom heb je meer servers e.d. nodig waardoor de kosten daar zullen stijgen, en met het aantal pageviews wordt t toch een kostbare zaak...

[Verwijderd]

De performance van java is helemaal niet veel lager dan PHP. Het is eerder hoger aangezien het niet geparsed hoeft te worden op runtime. Java is zowiezo in standaard text output en parsen van bijvoorbeeld XML net zo snel als een native taal, alleen in graphics is het behoorlijk traag

[LionO_NL]

De PHP-scripts die Yahoo! gebruikt zullen gegarandeerd WEL gecompileerd zijn (niet runtime geparsed).

- efficient (with acceleration)

Dat is die acceleration waar ze over spreken. Er zijn tools die dit doen.

[Verwijderd]

Zijn er tests bekend tussen PHP vs. JAVA vs. ASP vs. ZEND (PHP)? Misschien wel interessant.

[YaPP]

oh oh oh...

Zoek aub eens naar een grafiek op internet voordat je dingen gaat zeggen. (let er wel op dat ook dat soort mensen de zaak vaak van 1 kant bekijken, en niet alle ins en outs van een programmeertaal kennen)

Java opstarten heeft heel veel overhead. Dan is het traag. Het verschil is alleen dat een Servlet vervolgens geladen blijft (!) in het geheugen. Zeer efficient dus. (het kost alleen wel geheugen, en dat is waarschijnlijk een afweging die ze bij Yahoo ook gemaakt hebben)

[Blubber]

ALs je de link volgt dan zie je dat ze alles afgewogen hebben, ook de servlets. Maar FreeBSD heeft het niet zo op (JAVA) Threads zo blijkt. En JAVA zonder Threads ziet men aldaar toch niet zo zitten.

[Paul C]

Dat knutselen, gaan ze nieuwe functies toevoegen of verbeteren?
Zo ja worden deze dan ook doorgevoerd in nieuwe PHP-releases??

[Dennis]

Ze zullen zelf modules gaan schrijven voor php neem ik dan aan. En dat is niet php code, maar C code, want dat is veel sneller.

Ik zou er niet vanuit gaan dat deze in nieuwe releases van php komen.

[Blubber]

Sterker nog, op de website van yahoo, staat letterlijk dat ze dat niet doen. Hun verbeteringen zijn specifieke Yahoo dingen...

[RM-rf]

en dit baart me grote zorgen:
ik vraag me af of dit wel zo'n groot succes is voor PHP, of misschien eerder het begin van het einde, hoe commercie een open source initiaf opeet (with fries zoals de licentie-faq op php.net meld)

PHP3 was GPL licensed (alhoewel vreemd genoeg dually, zowel onder een berkeley-syle licente alswel gpl, een contradictio in terminus)

Door de ontwikkelaars van Zend (Zeev Suraski) is een mogelijke overgang van php naar een GPL-compatible licentie getraineerd, omdat dat voor zijn commerciele ideeen met Zend een probleem begon te vormen.
Het heft nu een Qt/Trolltech-achtige licentie, die ook KDE kent.

De huidige licentie biedt directe gevaren omtrend terugtreden in een proprietair systeem, waarin bedrijven eigenaar zijn van onderdelen van de php-code.

Het is goed om open source initiatieven te zien ontwikkelen tot professionele alternatieven voor commerciele initiatieven, kennelijk bied een andere aanpak wel degelijk die meerwaarde, maar het gevaar is groot dat juist binnen dit soort commercialisatie ook een Trojaans Paard schuilt, dat ertoe kan leiden dat alsnog commerciele belangen van bedrijven een directe invloed kunnen hebben op de ontwikkeling en toepassing van een taal.

[yared]

Je kunt er donder op zeggen dat als werelds grootste internet community voor zoiets kiest dat er uiteindelijk een volledig eigen taal zal uit ontstaan.

MyPhP ofzo...

Wat voor een bedrijf als Yahoo! voornamelijk van belang is snelheid en de mogelijkheid tot aanpassen.

Voor diegene die vragen hebben raad ik echt aan even Michael Radwin's (best wel relaxede en zeer duidelijke) presentatie door te nemen. En bij vragen zou ik zeggen hij heeft niet voor niets zijn emailadres erin staan!

Mijn god.. hij had wel even een betere persfoto kunnen submitten

[Verwijderd]

MyPHP? Als ze het maar laten. Als er iets smerigs is, dan is het wel MyDit, MyDat, MyZus, MyZo... om kotsmisselijk van te worden.

[justice strike]

lijkt wel een sony reeks myfirstsqlserver

[rootlinux]

De presentatie is inderdaad erg goed en informatief. :-)

[ToAoM]

yaphpoo dan?

[-Odysseus-]

Zie je maar weer dat PHP kont schopt. Duidelijk dat PHP een veel betere optie is boven ASP. Misschien dat Microsoft er wat van leert........misschien.

[Dennis]

Lekker onderbouwd.

Omdat Yahoo voor php kiest is php meteen veel beter dan asp.

ASP is perfect voor koppelingen met office-documenten en clientside VBS-scripting.

[rootlinux]

En wat doe je op het internet alles proberen serverside te regelen. Geen enge active-x of VB scripts die een virus kunnen bevatten / een security risk zijn.

Het is sneller doordat er minder door de internet pijp geschoten moet worden omdat er allen maar text naar de user gaat.

PHP babbelt ook direct met alle databases zoals mysql oracle en andere die ik even niet uit het hoofd weet.

Het werkt samen met alle webservers die van belang zijn op UNIX / Windows / Linux.

De source is vrij aantepassen / te lezen om verbeteringen aan te brengen. Het is nog gratis. Om maar een paar voordelen te noemen.

In mijn opiniet is PHP

[-Odysseus-]

Niet omdat Y! ervoor kiest is PHP beter (in mijn ogen) maar dit onderstreept juist dat PHP vele voordelen tov. ASP heeft.

[Dennis]

Zoals je hieronder had kunnen lezen zou als het platform Linux zou zijn misschien wél voor Java/JSP zijn gekozen. Dus in dit geval is het deels een samenloop van omstandigheden.

Als jij als bedrijf alleen maar Microsoft-software hebt en je moet kiezen tussen een Microsoft en een ander pakket.... wat kies je dan ?

[wzzrd]

Als jij als bedrijf alleen maar Microsoft-software hebt en je moet kiezen tussen een Microsoft en een ander pakket.... wat kies je dan ?

Met deze zin vat je dus precies het hele probleem samen.

[-Odysseus-]

Ja daar heb je wel gelijk in.

[wzzrd]

Nee, omdat Yahoo een mooie presentatie van het geheel gebakken heeft, kun je lezen waarom PHP kont schopt. En hoor nou wat je zegt:

ASP is perfect voor koppelingen met office-documenten en clientside VBS-scripting.

Dat willen ze bij Yahoo helemaal niet! Voor Yahoo is PHP - lees die presentatie maar - duidelijk de beste keuze. En goddank, goddank, zijn er nog bedrijven die niet direct in de houding springen als Microsoft zegt dat iets goed is!

(* 786562 wzzrd

[Dennis]

Ik suggereerde niet dat asp beter zou zijn voor yahoo
Alleen is asp niet gelijk slecht nu yahoo voor php kiest.

Verder is wat je zegt echt absoluut waar.

[packman]

ASP is perfect voor koppelingen met office-documenten en clientside VBS-scripting.

Office documenten geintegreerd in mijn webpages? geen haar op mijn hoofd dat er nog maar aan denkt zulke bloatwareformaten te gaan gebruiken voor mijn webpages. En client-side vbscript? Sinds wanneer is dat een standaard? Volgens mij ondersteunen verschrikkelijk veel browsers dit...

[RvdH]

1. Designed for server side web scripting

mod_perl ook

2. Large, Open Source developer community
* integration, libraries
* documentation & training

Er is meer perl training/documentatie/modules op de markt dan php.

3. Debugging & profiling tools
4. Simple and clear syntax (fits Y! paradigm)

Perl ook.

5. Performs well in our tests
* efficient (with acceleration)
* small enough memory footprint

Perl deed het schijnbaar niet zo goed als php in hun tests, wat mij doet denken dat ze niet naar mod_perl hebben gekeken.

Jammer

[Verwijderd]

1. Designed for server side web scripting

mod_perl ook

Je haalt 2 dingen door elkaar. PHP en Perl zijn 2 talen, mod_php en mod_perl zijn echter 2 methodes om betere integratie en performance (minder interpreter spawn overhead) te verkrijgen met Apache.

[Verwijderd]

Smarty, maar het is best mogelijk om MVC te implementeren hiermee

Tuurlijk kun je in PHP MVC ontwikkelen, maar het is een hack. Het is niet het natuurlijk design van PHP, terwijl het een eerste prioriteit van Yahoo zou moeten zijn. Als een team groter is dan 10 man, kun je niet anders. Bij 600 ontwikkelaars en wie weet hoeveel ander productie personeel is het ronduit suicidaal.

Ik meende ergens hierboven te lezen dat Yahoo! niet haar complete applicatie zal om gooien maar slechts delen. Verder is PHP ontwikkelt in C (wat denk ik, in jouw ogen meer "transactieplatform-waardig" is), dus ik snap niet helemaal wat je hiermee wilt zeggen...

Het feit dat PHP ontwikkeld is in C, maakt het nog geen transactietaal. Die twee dingen hebben niets met elkaar van doen. Back-end connectivity, message queueing, transactie / integriteits bewaking, schaalbaarheid zijn elementen die in een transactieomgeving van belang zijn. PHP ondersteunt geen van allen. PHP is enorm gegroeid en voor veel sites wellicht een goede, zo niet beste oplossing. Maar dit is werkelijk lachwekkend.

Ik heb dit niet geschreven om PHP te dissen. Het punt is dat PHP evangelisten, de keuze van Yahoo, te pas en te onpas verdedigen, hetgeen ik erg knap vind als je de uitgangspunten niet kent. Uit hun onvoorstelbaar slechte en inconcistente presentatie kun je de indruk krijgen dat Yahoo zelf de uitgangspunten niet goed heeft gedefinieerd. Dat is de werkelijke discussie en die onstijgt echt nullen en enen.

[Verwijderd]

EJB's zijn een onderdeel van het J2EE platform - Java 2 Enterprise Edition. Zoals de naam al doet vermoeden een zware kandidaat dus.

Het hele idee is dat je een of meerdere appservers hebt waarin speciale zelfstandige Java objecten kunnen leven. Deze objecten noemen we Enterprise Java Beans (EJB). Deze kunnen zichzelf of andere EJB's aanroepen al dan niet op dezelfde machine. Het aanroepen leidt tot een soort verbondenheid die we een transactie noemen, waarbij de appserver het hele proces bewaakt. De mate van bewaking is sterk afhankelijk van de features van de appserver, daarom zijn er zoveel verschillende, waaronder ook opensource versies zoals JBoss.

Aangezien EJB''s zelfstandig zijn ben je behoorlijk flexibel in productie en deployment, zolang ze zich maar een aantal basisregels houden. Het grootste probleem met onafhankelijkheid is gebrek aan communicatie en centrale aansturing. Het mooie is dat de onderliggende appserver dit voor je oplost. Een voorwaarde voor een robuuste transactie omgeving.

Zijn EJB's perfect? Verre van. Beter geschikt voor Yahoo? Ik vermoed van wel. Kan het niet zeggen, ken de situatie van Yahoo niet goed genoeg!

[Verwijderd]

Het feit dat PHP ontwikkeld is in C, maakt het nog geen transactietaal. Die twee dingen hebben niets met elkaar van doen. Back-end connectivity, message queueing, transactie / integriteits bewaking, schaalbaarheid zijn elementen die in een transactieomgeving van belang zijn. PHP ondersteunt geen van allen. PHP is enorm gegroeid en voor veel sites wellicht een goede, zo niet beste oplossing. Maar dit is werkelijk lachwekkend.

Even om een beeld te vormen: wat is dan een "typische transactie-taal" ? Want IMHO zijn alle dingen die jij zojuist noemde dan wel in "userland" danwel in "phpland" te implementeren en zoals je kunt lezen in de nieuwsposting zijn er ook nog dingen die de Yahoo! engineers missen en zelf zullen implementeren in de PHP code.

[Verwijderd]

Graag mijn onkunde vergeven bij het posten. Moet even wennen aan de postinglogica.

C leent zich niet echt voor transacties. Je wilt eigenlijk geen businesslogica schrijven in een taal, waar je gelijktijdig ook je eigen memory management moet gaan doen. Leidt veel te veel af. Je hebt nu eenmaal specialisten in e-commerce, in collaborative computing, etc. Laat die zich bezig houden met hun specialisme i.p.v. lost pointers op te sporen.

Een voorbeeld van een transactie infrastructuur is bijvoorbeeld een serie EJB's. Een EJB start een transactie en roept functionaliteit aan van andere EJB's die elk bijdragen aan de transactie. Mocht het onverhoopt fout lopen, dan is een simpele roll-back voldoende om alles te herstellen. De objecten die bijdragen in de transactie zijn autonoom, maar toch centraal aangestuurd.

Let op! Dit is dus geen database transactie - maar een proces transactie in de businesslogica. Uiteraard kun je zoiets gaan ontwikkelen in PHP. Maar het is het typische geval dat je met een nijptang ook een spijker in de muur kunt slaan. Definieer je doel en zoek dan de juiste weg ernaar toe.

[Verwijderd]

Let op! Dit is dus geen database transactie - maar een proces transactie in de businesslogica. Uiteraard kun je zoiets gaan ontwikkelen in PHP. Maar het is het typische geval dat je met een nijptang ook een spijker in de muur kunt slaan. Definieer je doel en zoek dan de juiste weg ernaar toe.

En dat terwijl je juist met PHP weer geen memory management hoeft te doen ...

_{EJB is iets uit de java wereld als ik goed geinformeerd ben, maar kun je mij vertellen wat het precies is?}

[Verwijderd]

Dit is ook mogelijk met PHP en wel met SRM "Script Running Machine". In SRM kun je zgn. Banana's (k'heb het ook nie t verzonnen) laden.

Banana's zijn dus wel enigzins te vergelijken met EJBs.
Zie http://www.vl-srm.net/

[Verwijderd]

Het concept is gelijk, de uitvoering absoluut niet. Het zal jaren duren voordat andere talen zover zijn. Zelfs een Microsoft kon het niet voor elkaar krijgen in de eerste release van .NET. Aan resources geen gebrek bij hen. ;-)

[RvdH]

Je haalt 2 dingen door elkaar. PHP en Perl zijn 2 talen, mod_php en mod_perl zijn echter 2 methodes om betere integratie en performance (minder interpreter spawn overhead) te verkrijgen met Apache.

True, maar van perl kun je niet zeggen dat het voor serverside webscripting is ontworpen, en van mod_perl wel
Ik vindt het trouwens meer een nadeel, dan een voordeel van PHP, dat het voor server side webscripting is ontworpen. Maakt het een beetje.. gelimiteerd.

[Verwijderd]

Maar het gaat Yahoo! hier niet zo zeer om de integratie met een webserver als wel om de taal zelf. Perl, wat staat voor Practical Extraction And Reporting Language, (de naam zegt het haast al) is niet ontwikkeld met server-side _web_ scripting in het vizier.

PHP daarintegen is enkel en alleen ontwikkelt voor het web en begint nu pas een beetje uit te spreiden naar applicaties welke wat minder direct te maken hebben met webpagina's.

[LosserNL]

Support uit de community hebben ze zeker, maar zeker qua security zou ik zou eerder JSP hebben gekozen, maar goed, ik ben maar een simpele javaklopper en geindoctrineerd door HIO Enschede

Welke database gaan ze hieraan koppelen? dan zullen ze toch zelf de modules moeten schrijven denk ik?

[Blubber]

Ze gebruiken oa MySQL, maar ik krijg een beetje de indruk dat zo ook een zelfgeschreven iets hebben draeien.

[wzzrd]

In die presentatie staat onder meer dat ze inderdaad 'een zelfgeschreven iets' draaien: yscript2. En verder maken ze een heleboel dingen zelf, waaronder een databasesysteem.

[YaPP]

ben maar een simpele javaklopper en geindoctrineerd door HIO Enschede

hehe... ook al?

Je word inderdaad nogal pro-Java als je de voordelen tijdens het programmeren hebt ontdenkt?

[Blubber]

Weel mooie ontwikkeling voor PHP . Ik vindt trouwens dat PHP onoverzichtelijk begint te worden. Ze zouden een aantal functies beter kunnen 'groeperen' eigenlijk een beetje zoals in JAVA echter niet zo extreem.

[Verwijderd]

dat vind ik zo goor van java..
een string heeft een stapel methods van hier tot tokio en terug.. liever op de php manier dan

maar je wens is hun bevel, de nieuwe Zend engine begint meer en meer java trekken te krijgen..

dat is hun uitgangspunt dan ook, komen ze volmondig voor uit.. ik vind 't geen gave ontwikkeling. ik zou 't leuker vinden als ze wat meer zouden baseren op C++ in plaats van Java..

[^Mo^]

Op welke manier vind je PHP op Java lijken? Vanwege dat de nadruk meer op OO zal gaan liggen? Op dit moment vind ik PHP nog het meeste op C lijken, en als je echt OO kunt gaan gebruiken dan zal het nog altijd meer C++ zijn dan Java ... een hybrid taal zoals dat heet.

Oh ja, stl::string heeft ook heel wat functies, dus 'tis niet alleen Java

[Verwijderd]

wat kinderachtig zeg, ik heb het enkel over de syntax natuurlijk, en dat snap ook jij heus wel...

wat dat betreft lijken java en php behoorlijk op elkaar, ze zijn allemaal wel wat van C afgeleid.. als je dit niet met me eens bent zou ik me eens na laten kijken..

en daar komt dus nu bij dat Zend 2 qua syntax nog een stuk meer op java gaat lijken, als je wil weten hoe precies, dan ga je maar lekker die PDF doorspitten op www.zend.com over wat er allemaal in gaat komen.

[YaPP]

Ik kan het mishebben, maar lijkt PHP niet ongelooflijk voor op Perl? (als je let op dingen als open(file) or die "error"; e.d.??)

Volgens mij lijkt er momenteel niets werkelijk op Java. Java heeft ongelooflijk veel te bieden op object-orientatie. Eigenlijk vind ik maar 1 ding lijken op Java: dat is .Net van microsoft. Ik heb echt met verbazing gekeken naar de C# en VB.net code. Het lijkt echt gejat!! (verder zal ik maar niet mopperen, voordat ik onzinnige dingen ga zeggen)

[Steven]

Beter goed gejat dan slecht verzonnen...
Microsoft is er groot mee geworden, en ik kan ze er geen ongelijk in geven.

[Verwijderd]

tuurlijk lijkt 't op C, maar java lijkt ook op C..
wat betreft OO gaat php heel veel op java lijken, wait and see..

begint nu al met 't feit dat je functies in php niet kan declaren maar alleen direct in de class declaratie moet opnemen zoals in java

[bille]

[NOFI] jah sorry hoor.. maar das dus echt grote bs. C lijkt niet op Java en beide lijken al helemaaaaaal niet op PHP.
PHP = weaktyped.. pussy dus..zwaar klote om te debuggen enzo.. geen compiletime errors e.d. Om over excepties maar niet te spreken.. neeeeej PHP is een leuke serverside webscriptingtaal.. maar duidelijk in de verste verte geen volledige programmeertaal vergelijkbaar met Java of C.

Overgens dwingt Java helemaal geen OO af. Sterker nog bij Sun is OO niet eens een gebruikte standaard! Java leent zich er wel goed voor, maar in eerste instantie is het niet ontwikkeld als OO taal (hetgeen het ook niet volledig is (primaire types als int's e.d.).. dan moet je maar eens met Smaltalk gaan werken ofzo)

[packman]

een string heeft een stapel methods van hier tot tokio en terug.. liever op de php manier dan

Ooit al eens geteld hoeveel stringfuncties er in php zijn? Vooral niet verschieten hoor...

In java heb je het grote voordeel dat deze mooi gegroepeerd zijn in een classe, en deze heel goed en mooi gedocumenteerd zijn, dat laatste is in php ook wel het geval, maar de doc is in java simpeler terug te vinden imho.

effe op je andere reactie... Java LIJKT op C... Idd - lijken - dan ken je minstens 1 van de 2 talen niet. Buiten de basic blocksyntaxen, arraybenadering en variabeledefinities zijn er niet zoveel dingen "in common". Die "blokmarkers" zijn wel de dingen die het hardste opvallen, en ook meteen heel handig zijn voor geroutineerde programmeurs

[YaPP]

Goor?

Het boeit echt niet... deze methoden worden slechts 1 keer in het geheugen geladen. (als je een beetje begrijpt wat pointers doen) In principe kan je een methode zien als 'functie' die gewoon nog een extra parameter meekrijgt; het object (een array van variabelen) In de werkelijkheid komt er nog wel iets meer bij kijken. btw...

Aan de mensen die tegen OO zijn: het maakt niets uit! Als je graag veel efficiente C code hebt, die je NOOOIT meer veranderd is er niets mis mee. Daar houd het alleen niet mee op. Mensen (vooral niet ICT-ers) willen dat een programma direct aanpasbaar/herbruikbaar is voor een andere taak. e.d. Dat kan met OO zeer goed. Dus word er wat uitvoer-snelheid teruggenomen, maar heb je wel een kwalitatief goed product.