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)
Cats sleeping with dogs, PHP useful at something!!!
Je t'aime Stéphanie
I hope the developers at Yahoo! understand fully the dangers of using PHP.
Obviously open source DOES apply to the corperate world.
Ignore the "p2p is theft" trolls, they're just uninformed
I'm sure it must be easier to find someone who knows PHP then it is to find someone who does cgi-bin c/c++ to maintain their sites. We use PHP/Asp for many of our internal applications we use for monitoring network systems and integrate it with MySQL. Works very well.
Going from something speedy and efficient to PHP.
Why not switch to J2EE? Obviously, this is an extremely large enterprise web-app. They could take full advantage of all EJBs and Webapp clustering. I just don't see why you'd use PHP, when J2EE has so much more of an advantage on an enterprise level.
On reading the slide show, the reason not to pick J2EE:
you can't really use Java w/o threads
Threads support on FreeBSD is not great
Is this really a bad thing?
Especially for the advantages EJBs give you??
Good quote, too many chars. Seriously, the slashdot 120 char limit sucks!
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.
As long as the change doesn't cause me to lose the lead in my fantasy hockey league, Yahoo can do whatever it pleases.
And, if I do happen to lose the lead in my fantasy hockey league, I now have something to blame it on.
Besides, I hate the greedy matches when doing regexps in perl, and I know most people coming from a C/C++ background will have the same dislike.
...considering it's initial creator is now a Yahoo! employee
yahoo will need more E10000's soon ;-)
Happy days.
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
Why should Perl be "more secure"?
PHP's biggest security problem is it's users. PHP is a powerful and easy to learn and use tool, which means it attracts a lot of new users. And the more new users you have, the more new user mistakes are made.
PHP has made a grep step forward in disabling register_globals by default. Unfortunately, a lot of legacy code isn't built for this.
I'm glad Yahoo is moving to OSS and recognizes the dangers of proprietary software.
I'm a Perl guy, and it was very interesting to note that:
1. Perl beat PHP in all of their performance tests
2. They listed TMTOWDI as a "con" yet,
3. One of the requirements was a language that didn't require a CS degree to use. TMTOWDI helps that, I've noticed.
I'm saddened that Perl has lost a major cheerleader but at least it isn't MS technology.
Even so, I can actually see how PHP is more appropriate. For a site with lots of content, with code mixed in, PHP's "code in the page" model is more ideal. I've had to reinvent something similar in Perl many times, appropriate for whatever I'm working on at the time (I don't like Mason, I prefer my own solution.)
I can see how a solution such as mine - where I prepare an output hash of data then show a webpage by opening and printing the file, using s/// to insert my hash contents with a search/replace method, isn't exactly ideal for Yahoo's high-content needs.
While PerlScript somewhat solves this problem, I remember it being buggy and certainly not as mature as PHP in that regard.
I can't say that I think this is a mistake on Yahoo's part - more like, I think if they wanted to, they could solve Perl's shortcomings and reap the benefits that Perl has over PHP. I guess they're just not interested.
The presentation was a little vague, wish I knew more about the details of their decision.
# Erik
I skimmed the comments so far and it seems like some people don't have a very high opinion of PHP. It's one thing to feel like something is better, but to despise it baffles me.
I do programming in PHP and have found it not only to be useful, but quite an upgrade over ASP. Is there something inherently bad about PHP that should make me shy away from it, or is it more of a religious debate?
It will be nice to go to a large corporate client that is looking for an enterprise solution (what the hell does that even mean) and say something like:
"I'd reccomend using PHP and Postgres on the backend of the project, given Yahoo's recent success, I think the platform is powerful, sucure, and cost-effective."
I realize that what Yahoo does in reality is irrelevant, but executives like to hear that kind of shit. Of course that assumes Yahoo can make it all work well, time will tell.
Cloud City Digital: DVD Production at its cheapest/finest
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.
Would the PHB's like it?
engineer:this is a rare opportunity phb: hmm?....
engineer: PHP is not yet a buzz word...we can set the market, indicators would rise, indexes improve, shareholder confidence would surge!
phb: WOW! I want PHP!
Jr. Engineer: What did all that stuff you said mean?
(clever)engineer: With Y having nearly 11M lines of code to rewrite in a new language....it means job security (and we still don't have to wear a suit)
"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.
Take a look at the top downloads at SourceForge. What is the most downloaded server-side web application?
For those of you too lazy to click the link, the answer (at the moment) is phpBB. #2 is Webmin (Perl), #3 is phpMyAdmin, and #4 is PHP-Nuke. (I'm not counting JBoss as #4 because JBoss is the server itself rather than a web app designed to run on a server).
So, we have
1) PHP
2) Perl
3) PHP
4) PHP
BTW You can get #1 and #4 bundled together as LiquidNuke.
The concept of Industry Standard isn't defined by "running on all platforms".
It means the software has a near monopoly on web development. It's popular, but so are CGIs, Cold Fusion, Flash, VB Script, Java Script, and of course JSPs.
What irks me is that people haven't abandoned HTML for all but display. HTML was designed to be stateless; info wasn't remembered as the browser jumped from one page to the next. To overcome this, all sorts of gross, kludgy, slow and complicated technology has been created (including JSPs, PHP, etc, etc) to overcome the inherent statelessness of the web.
The most interesting technology I've seen (and one that I hope will put these lame ducks out of their misery) is Curl, a programming language that runs in a plug-in (yes, sort of like Java, but more advanced, with fewer of the drawbacks). It was started at MIT via a US DARPA-funded project, and includes Timothy Berners-Lee, the creator of the World Wide Web and Director of the W3C, as one of the founders.
I can't wait for the Internet to go back to what it's good at - serving up pictures of pretty, naked women.
No, I don't work for CURL, or even for a company that uses the technology. I just think it's a better mousetrap.
UGH
PHP-Nuke, PostNuke and all variants are an exceedingly AWFUL way to share info -- click here, click there, stupid avatars, no threading, no straightforward text interface, searching rarely works properly, themes, ads, smileys, animations and more crap than you can shake a stick at.
Give me newsgroups or a mailing list. But please no PHPNuke or derivatives.
I agree, I just thought I'd point out that this doesn't change the fact that perl is HELL to maintain for larger projects :)
Bullshit, or at least bullshit that Perl makes it harder to maintain than any other language.
Code properly, document correctly and adhere to the same design rules for any other maintainable project (which includes firing the assholes who think that obfuscated perl has a place in a maintainable project) and you will have no more difficulty in maintaining a Perl project than you will any other.
The fact that perl lets you create a mess may be open to debate, but it certainly doesn't mean it will be a mess.
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.
If Yahoo can do it, why can't slashdot?
/^[A-Z0-9._%+-]+@[A-Z0-9.-]+\.[A-Z]{2,4}$/i
but I don't think any of us can make a strong argument against it, except that it's not a general-purpose language
I personally don't think a "general purpose language" is possible, nor desirable. If you try to optimize for everything, then it will end up being optimized for nothing. There ain't no free lunch.
Besides, you are going to activate LISP fans to start entering these kinds of debates, and you don't want to do that.
Table-ized A.I.
I read their presentation, and its good. They make a good case for PHP, and I believe PHP is well suited for the task. However, I have to disagree with one of the slides.
Looking at the "Coding PHP Takes Discipline" slide, they make a point that "The drawback of using a code in template system, is that your code and HTML output quickly become forever intertwined"
Well, I disagree captain! PHP can be coded in many different styles. Coding PHP directly into your HTML files is common, but a really poor way of doing things. In fact, there is a better coding style.
I do a lot of development with PHP. In almost everything I do, I separate the code from the output, meaning that the HTML takes the form of a template, and contains no PHP. The PHP scripts perform all data processing, and then pass the data through an abstracted interface to a templating system. Whatever the templating system does with the output is beyond the scope of the PHP scripts themselves.
This is a similiar principle as ODBC... database is abstracted from the code.
For example, yahoo's new scripts could pass the processed data into XSLT transforms, then out through any other page display mechanisms they choose.
I do have to give credit to them however, because they did mention using "smarty". For those that don't know, smarty is a popular PHP templating system, one of many. But it seems like their mention of Smarty is more of an afterthought, than the attention they gave to discussion their dicipline in coding PHP inline with the HTML.
To make this point short, PHP is far more capable than the inline style of coding that a few PHP developers use. In fact, that stems from PHP's old school days. Now that the product is extremely mature, the code can stand completely by itself. Since PHP has C/c++ style semantics, and contains most standard ANSI C functions, converting their existing codebase ought to be a rather boring task. I hope Yahoo! takes a serious look at the fundamentals of engineering their new system.
Skiers and Riders -- http://www.snowjournal.com
Undisputed. But there are languages that go out of their way to make it easier and perl doesn't. Not a criticizm of perl necessarily, just another point in the decision making process.
I personally love perl - I use it every day and it's usually one of the first technology choices for new projects. But coding in a team environment is often still a very hard thing (not every one out there is that great at doing the wonderful things you listed, and firing people left and right is often not an option), and I'll take all the help I can get there.
sic transit gloria mundi
I'm honestly surprised they've survived this long.
The man who trades freedom for security does not deserve nor will he ever receive either. - Benjamin Franklin
Amen, I've had a professor who would churn out C code for the example projects that would curl your hair, and refused to even consider Perl as a programming language because he thought it was an awful mess.
Perl lets you make messy code, and relies on the programmer to actually be responsible in churning out something that anyone who knows the language can pick up and read. Sure, making one liners on the fly to get something done is a neat ability, but IMHO, a good programmer will ADD the extra few lines of code for the sake of readability when readability is an issue.
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:
According to the slides, the only negative thing they had to say about Java (J2EE / JSP / etc.) is that FreeBSD has really lousy thread support (and proper J2EE solutions require threading)...
To me, that seems like a really stupid, short-sighted way to approach the problem. If Java is the best solution for them (which I think it would be), then why not move to an operating system that properly supports it?
Why hamstring yourself to an inferior solution just because you don't want to give up FreeBSD? That's like complaining that your Pinto is too slow -- but you'd rather fill it with Premium gas to get a little performance boost instead of getting a better car.
And what's up with 4500 servers? What a nightmare! Who in their right mind would want to deploy and manage 4500 servers? If they were really serious about this, they'd upgrade to a couple dozen big-iron IBM mainframes (like one of these!), where it can run hundreds of virtual Linux instances (if needed)...
I guess it goes back to the old saying "When you only have a hammer, everything looks like a nail"...
Clearly, they should have used Cobol.NET.
No, Thursday's out. How about never - is never good for you?
I've mostly explored JSP, Zope, and PHP. JSP is cool, tons of support, it feels like and acts like it's the enterprise solution. As such, it's a logical choice for a lot of things because if you need a hammer it's nice to have a sledge hammer. The reality, at least as I've seen it, is it's a bitch. It's huge, it's slow, it takes a super computer to really run, I've seen a fair share of sloppy JSP. It's cool, has all the gizmos that java has and it also has all the gizmos that java has. It seems like you need a ton of crap to build a lot of java stuff, even things from Sun like the JMAPI need 3 or 4 30MB downloads before you can build them and get them working, maybe that's just me complaining though. I'm also not sure what kind of vibe I get about Sun and java as a whole technology any more, I'm not saying it's going away or anything like that but it's not the goose that laid the golden egg anymore either. I don't know I'd tie my cart to java if my cart was as big a yahoo! Again, just my opinions, my C++ and assembly (of all things) skills have taken me farther the last couple years and got me jobs when there weren't any, java has just filled out the resume. While I'm knocking one of the most popular platforms out there let me also throw out the java developer base issue. Java was like a dot.com programming language, in no time it instantly had a huge developer base; how quickly do you think they'll run to the next great thing when/if it happens? I've wondered what would happen if sun started charging for the JDK. Or if .Net 2.0 really rocks and mono
takes off.
Zope. What to say about it. It's the bomb. It's also Python which is huge and on the cusp of going really huge, but hasn't yet. It's its own custom thing. It has a ton of cool parts you can drop in to it. It's probably my favorite. It is also a pain in the ass going to zope.org downloading something and trying to get it to work. It's like they have their own little sourceforget.net running in zope space and it makes the number of available parts look bigger than it really is. It's getting better but there is a lot of dead stuff on there. It also won't drop in to Apache that easily, you usually use their custom server and transport layer. It's not so bad but it's nice to be on mainstreet; it's more trustworthy. Other than that, it rocks, it's just a bit tough to sell it to someone who knows some of the buzz. If it were all up to me Zope would be the next big thing but it doesn't look like it's all up to me.
Then I stumbled on to PHP and it kind of rocked my world when I first started screwing around with it. For simple kinds of web things, like dumping some tables out of a database or something it's kicks the hell out of anything else I've seen. It seems like a few lines of PHP and it's done. No magic web server/container, just the apache server on your redhat box.. Then some of the tools and kits that have been put together with it make it a much more compelling application platform. Zope really appeals to my aesthetic sense of software engineering, I like python, I like the structure and the object nature it just hasn't caught on like the wildfire I think it is. PHP is close to it in terms of pontential and reusable stuff and it's like the second coming of perl. There are still the stock issues, is it fast enough? can it scale? will it last? It seems like those answers are yes. Can it scale better than JSP? I bet for a shop like yahoo! there isn't a comparison; I bet PHP wins unless they triple the amount of RAM that they have or switch off of FreeBSD boxes to S/390s or Sun "Enterprise servers." Also, PHP has such a grass roots following and has really grown up slowly compared to java, I don't see a lot of PHPers really dumping it anytime soon as it is. Now that Yahoo! is involved, PHP may go up to that next level.
Let's see, web development is a) parsing strings, and b) concatenating them. Which of these is Java good at? Well, neither. For the former, nothing beats a language with built-in regular expressions. Yes, I've used the ORO library from the Apache Foundation. Yes, it's a solid implementation of Perl 5 regexes -- but it's implemented in Java (slooooowww), and it's a pain in the ass to escape everything twice, once because it's a Java string literal and again because it's a regular expression. And even aside from those two problems, compare the following snippets:
String foo = "bar"; Perl5Util re = new Perl5Util(); if ( re.match( "/\\s*b\\+z/", foo ) ) foo = re.substitute( "/[ \\t]+/g", foo );...and in Perl:
my $foo = 'bar'; $foo =~ s/\s+//g if ( $foo =~Cleaner, tidier, more readable, and the Perl will execute in one-fifth of the time. I got stuck working on a large project with JSP, and we ended up pushing a lot of stuff out into Perl scripts because working with strings in Java is so slow. I'm not talking about small improvements; I'm talking about "when we did this in Java, the user thought the server had hung, but now the user doesn't notice the wait".
And I HATE Perl. But after using Java, I hate Java more. The only thing Java's got that Perl ain't got is OOP features. No, Perl has no OOP features. They have a hilariously ill-conceived imitation that's such a pain in the ass to use that the tutorial says "most Perl programmers will never define a class; only wizards do that". Yeah, well, in any well-designed language (or even a lame but rational one like Java), defining a class is trivial. If you fuck up a feature so badly that only "wizards" have the patience to learn it, yeah, sure, only wizards will use it. That just proves that the language designer is a fool. Frankly, I doubt very much that Larry Wall or anybody else involved in the design of Perl 5 had a firm grasp on what OOP is about, what it's for, and why people use it. It's like asking an Eskimo to design a garage. Go ask an Eskimo to design and igloo, and you'll get one hell of a solid igloo (as Perl is one hell of a procedural quick'n'dirty-text-processing language), but when you want a garage, hire an architect who owns a house that has one, and keeps his car in it, too. Common sense.
PHP's not Perl, though. I'm not thrilled with it as a language. I hate Microsoft even more than Larry Wall, but ASP with JavaScript is not a bad way to do web pages (JS is less text-friendly than Perl, but far, far more so than Java, and it's vastly better suited than Java to the kind of quick development these Yahoo! guys are talking about wanting; it's got proper closures (better closure implementation than Perl, by far) and a clean, simple, and powerful OOP implementation -- you can define new classes pretty much on the fly. JS is a very expressive and pleasing language to write code in, and any halfassed JS interpreter will be at least somewhat faster than even the best JVM). ASP.NET (so-called) apparently has FINALLY, after YEARS of cluelessness, learned from JSP and started including some of the cool architecture that JSP has (letting pages inherit stuff from a parent class, for example, which is real nice in a large project; there's also other modularization goodies) -- but now you don't have to wade through Java shit to use it. Too bad it's a Microsoft product. But you take it as it comes, eh?
Oh, and those 4,500 servers? Much lower TCO than those Big Iron dinosaurs. Furthermore, they can be replaced gradually and (once again) cheaply. You don't need it all happening in the one box, because it's a million separate Apache processes spitting out little HTML pages to a million different clients. Centralizing that buys you nothing. No one Apache process has to give a damn about any other.
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?
Some of the larger projects I have worked on , where integration is important and a key to the success of the product, JAVA seems to be the best bet.
Not to say that things couldn't be done in PHP, probably can... but I have had a lot of luck in writing all my business logic and middleware in JAVA and then using JSP or Servlets + Velocity for presentation. The thing is, it's not something that someone can do without a middleware engineer and a implimentation engineer.
I have been coding java middleware code ware for almost 3 years now, some of it integrates into web based services, some of it ties into legacy workflow systems and even tied into a IBM mainframe, I just can't IMAGINE doing all of that in PHP... I would of been laughed out the door of my company as a matter of fact with a pink slip in my hand.
The strength of being able to pull in other 3rd party libraries for various tasks that come up, JAVA is first rate.
I worked for a company that had a pretty complex logistics based system that integrated with a German logistics ocmpany.. was ALL done in PHP.. I couldn't believe it when I saw it to be honest, but to say the least... was VERY dificult to manage the application as it grew to many hundreds of classes and pages. The company ended moving to an EJB/JSP solution on websphere I think, and eventually was able to cut out about 1/2 of their engineers because the API became quite manageable by fewer people.
You can't call JAVA hype any more than you can call COBOL, FORTRAN c/C++ hype, because the level of profound impact JAVA is having on the industry at the moment is to those levels IMHO.
NOW.. if the project doesn't really reach beyond basic web applications, yes, even very large companies have such projects.. I see nothing wrong with PHP. It's actually a breath of fresh air when I need to hack something out quick and simple. I use HORDE+IMP for my own personal email and the email server for my wife on my linux box.
That sentence is as much hogwash as what you are so upset about. Perl itself certainly wasn't "designed for the web", but mod_perl was, CGI.pm was, check out CPAN under HTML::, HTTP::, Apache::, etc - all of that was designed for the web.
Oh, and since PHP was designed for the web, that means it wasn't designed for (let's say) database access, does that mean DBI is better?
Anyway, this "designed" bit doesn't really mean much usually, it's what it actually "can do" that counts.
btw, I just can't agree on a few points in one of your sentences:
in my experience PHP is faster - your experience is different from that of many other people.
more secure - this is entirely up to the developer, any differences the languages themselves may have in this ragard are utterly isignificant in comparison to the idiotic things that people routinely do.
more feature rich - Perl has been around pretty much since the middle ages (give or take), the quantity, diversity and (sometimes more importantly) maturity and quality of modules and other various extensions that's available for it cannot be matched by any other language; not to mention the organization of said material.
way easier to compile and maintain - I am not sure if you are talking about the language itself or scripts written in it (as the former doesn't matter a lick, and the latter... well I don't see anyone having trouble compiling Perl or PHP scripts).
If you look at hotscripts.com you will notice PHP has more entries than Perl - I was intrigued and did look at that site. Perl has insiginifcantly more "Scripts and Programs" and PHP makes up for it by having roughly 4 times as many entries in "Tips and Tutorials", why is that one wonders? Quick search at www.oreilly.com - 15 books for PHP, 730 for Perl; sure most of those have nothing to do with web development, but still (for comparison sake, same thing at Amazon.com - 73 to 354).
I know I'm just propagating a stupid flamewar, but what are you going to do?
Furthermore if you don't code for PHP don't comment on it, you don't know what you are talking about. - Lastly, I just wanted to find out if you code in Perl?
sic transit gloria mundi
- There's More Than One Way To Do It - This is a feature, not a flaw! Perl is much more flexible and powerful than PHP. Maintainability comes from coding standards, not language limitations.
- poor sandboxing, easy to screw up server - Perl can create sandboxes with the Safe module... (And if there's any rough edges, Yahoo's engineers could probably handle it.)
- wasn't designed as web scripting language - So what?? With mod_perl and HTML::Mason or TT2, Perl fits this niche well, without PHP's predisposition towards mixing code and data.
These excuses for not using Perl are hardly compelling; they sound like rationalizations. Perl is a more natural fit for Yahoo's needs, especially considering that they already have 3 million lines of Perl code.But they plowed ahead with PHP, and what did they learn?
- very easy to get some pages up quickly - Expected, but Perl would have been nearly as easy, and probably much easier for their existing Perl programmers.
- But mixed app/presentation problematic - PHP code and HTML forever intertwined - Surprise, surprise! This is exactly why PHP is inappropriate for enterprise applications. PHP encourages such shortsighted design. Beginners like it, but engineers should know better.
- PHP != Perl - The "implement twice" problem - They knew that they had 3 million lines of Perl in the backend; why didn't they leverage it? This was avoidable.
- PEAR != CPAN - repository smaller, less mature than CPAN - Again, this was a foreseeable problem.
- Surprises for people used to coding Perl - It's not just that some semantics differ. Experienced Perl programmers forced to work in PHP have to live with the frustration of having to write ugly convoluted code for things that would be clear and simple in Perl. PHP 4 filled in many gaps, but it just doesn't work as well as Perl does. (I speak from experience here.)
So let's see. Their problems with PHP basically boil down to the fact that it's not Perl. (Despite the claims of PHP advocates, it's just not an equivalent substitute.) Of course, any experienced Perl programmer familiar with PHP could see these issues coming from miles away. They rejected Perl as an option, claiming that it wouldn't be maintainable, then discovered the amount of discipline required for PHP -- would following good coding standards for Perl really have taken any more discipline?Perl was a natural fit for their needs, and the obvious choice. The entire presentation seems to be an exercise in rationalization, attempting to justify a poor strategic decision. They should have used Perl. (Even now, they should probably abandon PHP and use Perl instead, to save themselves from getting further entrenched into this bad decision...)
Deven
"Simple things should be simple, and complex things should be possible." - Alan Kay
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
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?