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
Ug, as a prior php developer, who worked on enterprise level apps, i'd pray for them. PHP has it's unique problems once you have a large code base. You are more likely to require two modules in php that won't play well toegether or get errors in php itself. Php didn't like gnome-xml and ssl together at one point for example. I've had includes just die randomly when the include_once tree got too large. It'd die on a variable assignment.. strange shit.
-
ping -f 255.255.255.255 # if only
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
It's slow, it's a memory hog...which further limits Java's absymal performance.
Standard Java stereotype. Java was slow a long time ago, not today. That gross asumption alone should get you modded down.
it doesn't deliver on the write-once-run-anywhere promise of Java because of the vendors' differences
Is multiplatform independence truely needed in this application? Sounds like they are using FreeBSD, and probably one webapp (I'd suggest WebLogic, because it clusters best).
It should be pointed out that they have no plans of rewriting the entire site in PHP.
Click on the "Early Adopters" section near the bottom:
Most Y! properties integrating slowly
- no plans to rewrite entire site
So "Moving to PHP" could be a bit misleading.
Going from something speedy and efficient to PHP.
Also it's easier to load custom extensions on PHP, specially if they are done in C/C++, which is Yahoo's case. Code changes needed are smaller if they want to have all the old stuff working with the new.
Buy a Nintendo DS Lite
"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.
Rational has a JSP based site that's pretty damn fast (unless it gets slashdotted, of course).
Good quote, too many chars. Seriously, the slashdot 120 char limit sucks!
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.
Might be awfully nice and useful info to have... (And since they're "giving back to the community anyway"...)
Besides, who knows, they might just have made the classic beginners mistaken and put the database connectionstring (including username/password) in an
PHP is not 'so bad,' but there are reasons why you might not want to use it.
.net) etc.
.net) first. Oracle Objects, native DB connectors, will probably be written for Java before anyone tries to implement them (if ever) in PHP. You might not need these features of a small site, so its not that big of a deal.
Here are a list of reasons why PHP may be suboptimal for web publishing.
1. Lack of seperation between content and logic. Embedded logic code inside presentation can lead to a bewildering jungle of death for anyone who tries to maintain the code. Also, repeated logic must be maintained across all pages, instead of changing it in one place. (this goes for all ASP, PHP, perl type scripts)
2. Performance problems with interpreted languages
3. Can't take advantage of OO goodness. php is a flat procedural-like language, you can't do the robust object modeling, or any of the other spiffy OO things you can do with c++, java, (maybe
4. HTML lock in. Your code will forever live in HTML, if you want a different display format (unlikely) you're stuck. ie. what if you want to have a propriatary client instead of html on your plam, you have to rewrite all the logic.
5. Fancy features availible in Java (maybe
Don't get me wrong, i think PHP is great for certain types of applications, but for large sites like yahoo, I think they'd be better off choosing something else (they wont use java because they claim FreeBSD has threading problems)
These are mostly addressed in the linked Y! eng slides. I'd be interested in hearing others opinion on this topic.
Yahoo is a great poster child for FreeBSD, the world's most robust free operating system.
I hate how uninformed people (I'm not saying you are, but you are certainly propagating the myth) always say something to the effect that PHP is "web only". This is downright false. I've written complex shell scripts with PHP, and tend to do so most of the time over sh or Perl.
#!/usr/bin/php works just like the Perl alternative.
There are several issues, IMHO, with PHP.
The embedded within HTML process is a nightmare. Either your coders need to be HTML designers, or vice-a-versa. It shares this trait with both ASP, CF, and JSP. Coders tend to not be the artistic graphic artsy kind of folks that the HTML people are, and the HTML people don't think in the high level "gee, I could use a nice abstraction here rather than cutting and pasting code across 100 pages". There are certainly exceptions, but they're the exception rather than the rule.
When I looked at it, PHP had different interfaces to different databases, which meant that the code for the mySQL DB was different than the code for Oracle. That's crazy (it may have changed). This presents a large burden should you ever decided to change your database.
The folks writing the back end logic aren't working in the same environment as the folks USING the back end logic, which can end up in finger pointing wars. You would need to be proficient in both PHP and your back end environemnt to handle any problems. This may not be an issue with larger organizations, but with smaller companies it seems a waste to need to learn two different environments.
Points #1 and #4 are totally off base. It is very simple to seperate presentation logic from processing logic in PHP. Don't diss the whole language just because 95% of people don't know how to use it properly. you can either go the simple route, and use a special Display class for all your displaying ( easy to modify, easy to swap out for a totally different page), or as I did, you can use PHP's XML/XSLT functionality to totally seperate your logic form display, but having all logic code return XML strings and only at the funal step transform them using XSL.
As for your point $3, see my exmaple above. PHP has a nice OO clas structue, which is great once you've used it for awhile and being to understand how it is "OO Designed for Web Development", not "OO for Application Development", which are two different things.
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.
Here are some key things which make Python much easier to maintain than Perl:
And here's a killer:
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).
For me, MySQL is more cross-platform than Postgres. I develop on Windows/Linux at work, Linux at home, and then copy it to a Linux server. Postgres doesn't have good Windows support.
--Giving to trolls for the benefit of us all
http://public.yahoo.com/~radwin/talks/yahoo-phpcon 2002.pdf
Read Epic the first RPG novel.
but does it change the fact that they read my e-mail and log my every move?
All the slow EJB installs I have seen have the following problems:
Use of remote classes where local ones would make sense. Use a session bean to aggrigate the results of a few beans and send out the result you need.
Bad database design or just poor JAVA programming.
I have studied EJB extensivly , and can usually get near database-query speed if I think hard enough about what I need. I have read that remote objects should only access session beans, and this is a pretty good idea for the most part.. Your calls should be fewer and pull down the data it needs rather than make LOTS and LOTS of calls...
Anyway, it's a pretty elegent solution and really forces you to think about design. Solutions such as Caucho's Resin CMP makes it even easier to use an EJB solution for object-relational managment and , with resin imparticuarly is easier than using a roll-your-own JDBC based code.
It's slow, it's a memory hog,
Nonsense. J2EE's threaded model is far more effecient than Apache/PHP's process per connection model because of the memory sharing. In terms of speed, App servers like Resin
http://www.caucho.com/articles/benchmark.xtp
do just fine against PHP in terms of speed.
it doesn't deliver on the write-once-run-anywhere promise of Java because of the vendors' difference
True a few years ago before Sun started validating app servers. Now not so true. The ServerSide.com runs on a cluster of machines where each machine runs the same code base on a different vendor's app server.
What I want to know is how come no PHP advocate mentions scalability? How do you pool arbitrary objects, or cache static data in PHP? How do you distribute sessions in PHP????? What happens when you want to cluster that PHP site??
1) http://pear.php.net
2) http://pear.php.net/package-info.php?pacid=46
3) Your point being????
4) http://gtk.php.net
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
Yep, that's pretty much it. If PostgreSQL didn't have the 8k row limit and the need for periodic 'vacuums' at the time when the web was starting to boom, it would have been the db of choice. Those problems are fixed now but it doesn't matter. It supported transactions, views, sub-selects, and most other SQL features years before MySQL did. The fact that PostgreSQL is now a better database in nearly all respects (including speed) doesn't matter because MySQL is entrenched.
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.
... and that is why so few major projects are ever written in Perl. You will never find two programmers who write Perl in the exact same style. PHP may have a much more limited syntax but it enforces readability to a certain extent.
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?