Slashdot Mirror
Yahoo Moving to PHP
Erek Dyskant writes "Yahoo has decided to switch from a proprietary system written in C/C++ to PHP for their backend scripting. Here's the notes from a presentation by a Yahoo engineer at PHP Con 2002."
← Back to Stories (view on slashdot.org)
I'm not understanding the reasoning behind choosing php over perl
You haven't read the article. There's a whole page for "Why not Perl?"
Buy a Nintendo DS Lite
I find it very funny that some people are posting comments suggesting there are security problems with PHP.
PHP has had a few security problems but they have all been fixed very quickly, just like many other open source projects like FreeBSD and Linux.
I find it very amusing the Perl programmers are shocked that Yahoo picked PHP instead of Perl. Perl has its uses but it is not designed for the web, PHP is.
PHP is easy to learn, powerful and c-like which makes it good for rapid development and web based applications.
I would have been very shocked if they picked Perl of PHP, in my experience PHP is faster, more secure, more feature rich, way easier to compile and maintain, and takes far less code to accomplish the same things as Perl.
If you look at hotscripts.com you will notice PHP has more entries than Perl, this has only been the case for the last few months and though it is a small indicator it is obvious PHP is gaining popularity and it is well know it is the most installed apache module on the Internet.
Furthermore if you don't code for PHP don't comment on it, you don't know what you are talking about.
...considering it's initial creator is now a Yahoo! employee
Because Yahoo is one of the fastest sites on the 'net.
EJB's are great, don't get me wrong. They are great for handling database abstractions with zero tolerance for errors. But they are not fast, and horrible overkill for a site like Yahoo. All that abstraction and IIOP communication kills performance. Which is why shops that have large EJB applications tend to run them on heavy duty sun hardware. Not i386 boxes running FreeBSD.
I don't have a sig...Do you??
Quoth the link:
Cons
- There's More Than One Way To Do It
- poor sandboxing, easy to screw up server
- wasn't designed as web scripting language
PHP useful at something!!!
:-)
I didn't expect the spanish inquisition. Really, though. PHP is like PERL made for the web, it has easier access to databases than any other language I know of (which are only a few granted but Perl and C are among them).
I would say more but Language choice tends to get religious. Everyone thinks theirs is superior and few will just yield to my choices
"The drawback of using a code in template system, is that your code and HTML output quickly become forever intertwined."
You see, the funny part here is that I write PHP, and I do not intermingle my XHTML and PHP at all.
How does it work? Very simply! Your request handler parses the request, reads in any cookies, sets and changes, reads in the template from disk or cache, fills in the new variables, and pushes it to the client.
Look, mah, no PHP/XHTML mingling! You move from a "myFirstPHP" model of HTML with PHP shoved in, to a proper model of a complete HTML document produced in anything with %%variables%% strewn throughout which are replaced at runtime by the PHP engine. With this separation of application logic and appearance, you get all the benefits of PHP with all the benefits of a separate interface code level (.NET WebForms does something similar, and Perl can easily do this too).
--
Internet Explorer (n): Another bug -- that is, a feature that can't be turned off -- in Windows.
I work for Yahoo!.
We chose PHP because our proprietary scripting language didn't give us any performance advantage anymore. PHP is a language with a lot of use and a large group of people in the workforce that know it. We wrote our proprietary solution at the time because nothing else could give us the performance that it could. Things have matured, and with accellerators such as Zend, PHP is a fit for us. There are many more reasons outlined in the presentation. Read it.
Some people here appear *angry* that we didn't choose [their favorite language] and all I can say to you people is "grow up." PHP is a fit for us. Your solution is a fit for you. Get over it. We know *quite well* how to run enterprise sites, and the decision to go with PHP was not made by the clueless.
Yes, we use PHP. We use Perl. We use Python. We use TCL. We use C/C++. We use Java. We use Apache. We use FreeBSD. We use Solaris. We use Windows. We use Linux. We use GCC. We use GPL software. We use BSD software. We use proprietary software. We use a lot of things. This isn't really news.
This doesn't tell me anything about the quality of these products. I cant speak for the others, but have you ever looked at the source for PHPNuke? It is a horrendous mess. Not only that, but the thing is routinely riddled with secuirty holes and other bugs. I had the displeasure of running it on my site for awhile, what a mess.
MySQL is faster in really only one particular case: lots of SELECTs with few UPDATE/INSERT/DELETEs. Many applications have orders of magnitude more SELECTs than other queries (I'd guesstimate that Slashdot books at least two orders of magnitude more SELECTs). Nothing beats MySQL in that environment, and there are a lot of apps where that's all that's needed (think CMS's and other such things).
1) This one is really annoying. Certain pre-defined variables (I'm not sure which, maybe only user-inputted data) are pre-slashed. So if a user inputs the string 'My name is "Jon"', you get it as 'My name is \"Jon\"'. WTF is up with that? That's not what he said! I can't find the reason for this or anything else about it in the documentation (maybe it's there somewhere, but I can't find it).
a bles.ex ternal.php
It's also pretty annoying when you don't read the manual - and this one is NOT obscure to find. Section 8 - "Variables" (which is what you're dealing with) has a section about 'Variables from outside PHP':
http://www.php.net/manual/en/language.vari
2) Every time a page is loaded, it has to be re-parsed, as well as any included scripts that it uses. This is very inefficient.
Then design a better language yourself that has nifty things like variable variables (echo $$b[0]->foo;) and is still faster than most other languages. Or just get a host that will use one of the many caching products available (zend, ioncube, etc)
3) It's a real pain to include scripts that are in different directories which include other scripts, because they will try to open them relative to the location of the original page.
Seems pretty damn logical to me. Of course, PHP will also look for files in the 'include_path' which is set in the php.ini file, so it's really looking in multiple places. And it wouldn't kill you to just use a predefined constant like DOCUMENT_ROOT and include files relative to that so your scripts would be portable and a bit easier to move around internally if you need to.
PHP does have problems - nothing you've mentioned here is a 'problem' beyond the level of mere annoyance to a handful of people.
Slight plug - those who've taken our PHP training course have never complained about the issues you brought up as 'problems'.
Cheers
creation science book
Right now, only NBM (nothing but Microsoft) users and legacy systems run IIS. It doesn't offer anything valuable, except customer lock-in. (which is very valuable, but only for Microsoft)
There's no way you can back that statement up. Corporations generally have a few outward-facing web servers, and yes, these are most likely running apache, but the vast majority of Intranet web servers are still IIS. After that you'll see Lotus Domino and iPlanet, and then Apache.
(This is from my experience with large corporations, though the IT rags such as Information Week and Network Computing back me up.)
IIS is the standard for Intranet web servers for a reason - it's standard. It comes with every NT server. It's easy, and setup/administration hasn't changed in years. Any clown with knowledge of Windows can make it work, and it is stable and reliable.
In the last 7.5 years I have administered just about every popular web server written (including NCSA HTTPd, WebStar, and IIS on NT 3.51 back in the day). Of all of them, I've found IIS the easiest to work with. Coupled with Win2k workstation on the desktop, it's almost fun to administer them with MMC and watch their behavior with PerfMon.
The reason I deploy mainly IIS servers is that I can order a server from the IT department with a standard Win2k build and have secure applications (with access control) running on it within minutes of taking delivery of the box. Try that with a Solaris, Irix, or Linux box, I dare you. (Yes, I currently deploy and manage Apache on Solaris, Irix, and Linux, just not as often as IIS on NT/Win2k.)
Sure Open Source has a place in corporate webservers. That place just isn't big, and won't be until Apache is easy to configure and integrates seamlessly with Windows NT security. When an idiot with an IT degree from the local community college can integrate Apache on Unix with a corporate network and can authenticate users and implement access controls without opening a book, then Open Source will have arrived in the corporation, and will start to eat into IIS market share of the Intranet. Until then, it'll be fringe, relegated to use on big systems with unix sysadmins doing the implementation.
While this may have changed, a few years ago, Postgresql was a non-competitor for one reason and one reason alone: It was slow.
/. - It was the fastest choice available at the time.)
MySQL had a reputation for being VERY fast. (In fact, this is why it was chosen for
Again, this may have changed, but in the past, MySQL was the speed king if you didn't need all of the other features that Postgres offer.
So in short, the one users reason is, "I picked a database with less features/reliability because I need speed more than features/reliability."
retrorocket.o not found, launch anyway?