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
*applys for a job*
I'm a big retard who forgot to log out of Slashdot on Mike's computer! LOOK AT ME.
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 agree, I just thought I'd point out that this doesn't change the fact that perl is HELL to maintain for larger projects :)
sic transit gloria mundi
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.
It runs on all platforms, it is widely supported and deployed and you can get it at every webhoster.
And there are running more Apache servers with PHP module than IIS servers altogether:
securityspace
Apache/PHP is marginalizing IIS and all other servers.
Both Microsoft lovers and monopoly-whiners will hate it, but those are the facts.
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
Viewing Yahoo's press releases, you can see no information that leads us to believe that they are switching at all?
Is this a story just to grab attention to the presentation?!?
Yeah, I'm a Republican AND a geek. It is possible.
I'm really sick and tired of hearing about how ASP is better because it's "more professional". The largest site on the Internet thinks it's the best tool to use for it's massive, massive application, SHUT UP.
We just cannot have this! Let's change it to something trendy.
And just what sort of language is C/C++ anyway?I've heard of C and I've heard of C++, but what is C/C++?
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.
I was going to say the same about security, then I realized that it is unlikely that Yahoo is sharing servers with someone else... in that case, they may have a point. Perl isn't necessarily *more* secure than PHP on a single server. It is, however, *very* secure. If you wish it to be. One problem may be that Perl lets you be as insecure as you like... well, that goes for most languages I guess. But Perl is very powerful, and with great powers come great responsibility. It might be good to choose something with less horsepowers too... ;-)
:)
What I don't understand is how they can think that mixing HTML and code as the default would make it easier to maintain. Most Perl-HTML stuff encourages separation of data, code and presentation, while PHP kinda enforces everything mixed up. In both, you can do it the other way around though.
Perl would seem a much better and more powerful choice to me, but I suppose they had specific reasons in this specific situation.
As long as they didn't choose ASP (or J2EE, for that matter), I'm happy. And so are they.
PHP-Nuke? No thanks... PostNuke (a PHP-Nuke fork) is far superior - instead of one developer, it's an OSS project... lots of features and less bugs than the original.
There is always Python. Wasn't one of the larger Yahoo-like services done in Python? I can't recall which one though.
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)
Since when is C++ proprietary anyway?
SIG: HUP
"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.
More secure?
See, this is where I cannot help but assume that you are inexperienced. If you think a language can make your applications more secure, then you have a fundamental misunderstanding about developing Web applications.
As for maintaining large applications, I can tell you that with proper software architecture employed, PHP is going to be plenty easy to maintain. When you look at the big picture, you need an application that new employees can contribute to after the shortest amount of training possible. Can you honestly tell me that Perl has an advantage here?
Besides being a move to an open-source-based solution, which is good for the community as a whole, this will be good for the development of Enterprise Level PHP. It has been my observation (perhaps a someone inaccurate one?) that PHP has long been overlooked as a solution for high-volume sites...and perhaps rightly so with PHP in its current state. But no doubt Yahoo! intends to make PHP work for them. I can just hope that some of their innovation trickles back down to the mainstream devlopment of PHP where it can be used to further improve its implementation.
But that's probably the reason for choosing PHP over Perl, 3-letter acronyms are hard to beat. ;-)
(Just kidding, I prefer PHP over Perl myself. And it's not because of the name)
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.
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
Perl || die
must... stay... awake...
Perl added a non-greedy matching operator several years ago.
The slides mention that Y!Maps was done in Python, but the slides also conveniently did not mention that all of YahooMail was done in Python. Given that the ability of non-CS types to create code was a requirement as well as the ability to maintain code for large, multi-person development projects I am surprised that Python was not among the possibilities examined by this particular group (unless, of course, the outcome was already pre-determined before the "test" was conducted :)
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.
Yeah, but you get no bragging rights or buzzword compliance. Do you realize how much some people here have paid (are paying) for their CS degrees? It's a club, and it requires certain things for access. Now anyone with $30 for a PHP book can buy membership. How can you ever be a snob again? How can you show your virtual face online anymore, knowing that you didn't have to build an expensive, enterprise-class system just to let people log into secure areas of your site? Woe is you...
Seriously, I'm with you. It's all about right tool for the job. If PHP works fine, then use it. I've noticed that most of the people that dismiss PHP (or Perl, or ASP, or anything else) out of hand are the ones that tend to not follow the "right tool for the job" advice. They know J2EE/Oracle, or Win2K/CF/Access, or whatever, and any project gets that -- regardless of how complex it actually is. See, everything has to scale, or it's merely a toy.
In tha past year, I've used servlets, XSLT/XML, Perl, PHP, MySQL and PostgreSQL and each one does exactly what we need it to do. It's all good.
-B
Ash and Hickory, straight-grained and true, make excellent bludgeons, dandy for the cudgeling of vegetarians.
pow() sure seems to work just fine to me...
HTML::Mason / Perl fit every criteria they had perfectly. (Including allowing them to keep their 3 million lines of perl code untouched)
I doubt they would use AOLserver because FreeBSD's threads are pretty weak. In the presentation, that was the reason they gave for dismissing Java/J2EE.
cpeterso
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:
I'm not sure about 50, but I reckon I can do 75 if I'm allowed to use the p/$@%/ operator and write seventeen consecutive instructions on one line separated only by logical operations. ;-)
If you disagree, post your argument. (-1, Overrated) isn't your personal censorship tool for views you don't like.
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"...
I got an ad for visual studio .net when I pulled up the story...
However, jumping to another UNIX is difficult because of C++. Unlike scripting languages, or even C, C++ is hard to port between platforms. Implementations vary widely.
Mostly valid points, and as far as security is concerned, I think more security problems come from the code written by the engineers themselves, not from the underlying language. I've seen some pretty insecure Perl code in my day.
The only reason I'm replying to you is because of this sentence: "...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."
As far as faster goes, according to the benchmarks that are included in the article, YSP, which seems to be their mod_perl solution, was faster (though not by a huge amount) than PHP. The one place where it did worse than PHP was memory footprint, though that seemed to be by the same small margin that it beat PHP by in speed.
Secure: I refer to my previous statements, I think security is a bigger issue with the end code than the underlying language. Either way, both of these languages have been very good about getting fixes for security problems out, and publishing security problems so we can avoid being victims of them.
Feature Rich: CPAN is my only point here. From my experience, CPAN has more modules and more mature feature sets than PHP. I'm sure that will change over time, but I have found it much easier to get new functionality/features from CPAN than any other language.
Easier to compile and maintain: Compilation isn't really all that much of an issue with perl or PHP. If you're talking about compiling in mod_perl vs. mod_php, both of them were easy as could be for me, and both can be done through RPM. If you're talking about your actual application code, I honestly don't think that is an issue for either language, and a moot point. As far as maintenance is concerned, well written perl code is very easy to maintain. PHP code tends to have HTML & code in the same file, which I've found causes no end of headaches when working on a project that has seperate template/HTML coders and PHP/Perl coders. It can be written to seperate those two, and IMHO, should always be written that way, but in my experience, it rarely is. Similarly, I'm not a fan of Mason with mod_perl because I find the same problem crops up there.
far less code: Honestly, I can't comment on this one, so I'll take your word for it. I can generally get a lot of things done with little perl code, however, and I've never sat there for days working on the same function wishing that I had to write fewer lines.
> PHP has made a grep step forward in disabling register_globals by default
;)
as usual, theonion.com has covered this
"Old man yells at systemd"
AOLServer is an out-of-date toy. It's not being actively maintained, at least to a level to keep up with Apache or IIS. AOLServer is great for small sites and relatively easy to setup, but it doesn't scale well.
Because it costs too much to use Perl. Perl has a very high cost of ownership, compared to even C++.
For small projects, and for throw-away code, Perl is the ideal language.
For large projects, and code with a long life expectancy, it is very hard to maintain.
As they pointed out "there's more than one way to do things". For maintenance programming, this means that you have to know every way of doing things, or you aren't going to be able to read all the code.
One of their earlier slides pointed out that they didn't want to have to pay for highly educated people... the specific item was point 12 on slide #20: "Doesn't require a CS degree to use".
While it's possible to hire people so skilled at Perl that they can do the necessary maintenance work for you without a lot of effort, hiring those people costs a lot of money (see slide #18, under the bullet item "Y! is a cheap company").
-- Terry
I love PHP. I learned Web Programming with PHP. It was a more intuitive move for me from C++ and Powerbuilder development.
The main reason I love it, is that it greatly accelerated my HTML learning curve.
For my career to really take off, however, I passed the Java Certification (which by the way, had zero HTML). Now, I was able to quickly ramp up Java Programmer to J2EE developer with thanks in part to PHP.
Now, I was on PHP3. And there was only one drawback I had with it, I'm sure has been solved. I found it hard to develeop large modular systems because if the way you use the #include directive. It seemed even more picky than C's #include in the order. It was tough to get around chicked befor the eggs problems like.... Hey, you use this method from one php3 module, but that method uses a method from another module. Everything had to be in the right order.
J2EE is a deployment nightmare, nothing against the actual spec... It's the verdors' implimentations that can be a real pain.
The power is definitely there with PHP. Enough similarities with Perl to please all I feel.
I hope Yahoo can definitely give something back to PHP, particularly, catering the language to be flexible to develop huge systems.
Of course, you could always use a real language that enforced coding discipline.
Why do some programmers insist that its more important to be able to lash up buggy code in an eye blink than to write maintainable, bug free code in the first place? Is debugging and maintenance time somehow cheaper?
poor sandboxing, easy to screw up server
This is my biggest (and really only) problem with mod_perl. While the power and interface that mod_perl gives you is extremely powerful, far too often shooting myself in the foot as I am wont to do results in Apache exploding.
I wish there were a more intermediate solution. I suppose (*sniff*) I don't *need* the all access power of mod_perl, but Perl CGI doesn't really float my boat either.
Game... blouses.
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.
Perhaps this will lessen the snobbery that exists regarding PHP over more bloated languages. The same snobby attitude that would have stopped HTML in it's tracks in the 90's.
Let's bring back the pioneering attitude that made the web what it is today...
GO YAHOO!
[preparing to get modded to -20]
Seems a bit strange that when you have 612 developers (!) you would rule out ASP simply because of the cost of buying Windows - plus, I'm sure MS would give them a sweet deal. Surely developer productivity and turnaround time is the most important thing?
I'm not saying they should have used ASP, just saying it's a strange basis for a decision. And they didn't even look at ASP.NET which solves the separation of code from layout better than anything I have seen.
Read reviews of shopping cart software
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.
If you're moving to PHP, you could do well to start with a small core of senior programmers who set standards for variables. Using pair programming, programmers could always review each others' code throughout the work week. Additionally, checks can be made to ensure that on check in to the central repository, the code being handed to them is pure HTML (if it is an HTML template being checked in).
With the apropos methodology and a little discipline, it shouldn't be hard to firmly establish the One way to do it in PHP.
--
Internet Explorer (n): Another bug -- that is, a feature that can't be turned off -- in Windows.
Named arguments can be done in Perl, as well as checking their amount and correctness. In fact, I've got a little module just for that. You call the function like this:
function(foo=>'value', bar=>1);
it dies if a required parameter is missing, or has a wrong value.
but does it change the fact that they read my e-mail and log my every move?
Does it also die if it has an 'extra' key? Also, does it allow you to mix ordered arguments and named arguments at the user's discretion? I'm aware of the common Perl practice for sending in args via a list interpreted as a hash; however, it isn't quite the same or clean as what you can do in Python:
function('foo', 'bar', an_arg='baz', another=4)
ML is actually a great example of strong typing: Strong Typing and Perl (Strong Typing Doesn't Have to Suck)
I'd also be interested to know what the runner up was. ASP? JSP? Perl? .HTML :)
Seriously, what were your criteria, and what were your rankings ofthe various technologies based on those criteria?
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.
Dude, your just saying that.
The guy gave a fairly cogent reason that Java does not scale well on FreeBSD because of screwey threading.
The problem is, it's true. FreeBSD is not a friendly environ for Java.
Get over it and live with it. The anger will pass.
Excuse the Unicode crap in my posts. That's an apostrophe, and slashdot is busted.
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
Being guaranteed to die or throw an exception is almost a must. The user needs to know immediately if he violated the function's signature. Not dying is just as bad as accessing non-existing hash keys and getting undef instead of an exception being thrown, IMO.
Doesn't work in Python either, of course. All varargs must come before kwargs.
With Python the user of the function gets to decide how many arguments are specified by position, and which by naming.
Statically-typed languages (e.g., Eiffel) are easier to maintain than dynamically-typed ones (e.g., Perl, Python), for they are self-documenting.
- There's More Than One Way To Do It
- poor sandboxing, easy to screw up server
- wasn't designed as web scripting language
Whoever tells Larry that PERL was rejected, please be gentle since he isn't done with the next PERL rewrite yet and this might cause unintended consequences. Better yet, just wait until the next version is out before you break the news that Y! rejected PERL for PHP.
Take a look at the memory footprint for each insantiation of Mason and you will find it's perhaps eight to ten times the size of a PHP process's. Corallary: it takes a lot longer to instantiate, even with mod_perl. In short, Mason is a big slow hog and thus unacceptable for megasites.
- 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
This slashdot intro suggests that Yahoo currently only uses C/C++. This isn't correct. Many of Yahoo's services use other languages such as Python, Perl and LISP.
You have to have a layout layer. That is the HTML page (with help from CSS). Into the HTML page you place your widgets. Be they text labels (IE: text which is variant), buttons, etc. You build them programatically and place them into your page layout.
The same thing happens in programs on your desktop. There is a Glade XML file which describes the look and layout of variables. Into this you place your variables, be they text or controls.
Something like the person I was repyling to asked about would be like a custom control. You place the output into the page, and all apears well. Want to change how the entire page looks? Change the CSS. Want to change how the control is logically designed? Then you change the program logic
You don't sound like you understand how stylesheets work. They take care of practically the entire presentation layer. Consider, for example, my changelog. Look at it in Mozilla. Now, choose View -> Use Style -> {pick one}. Note how the entire look of the page changes. That is CSS. The general layout of the page is accomplished via common CSS markup positions (view the basic page style to see it "stripped"). The calendar is a good example of an HTML custom control. Certaintly, the logic of how the control work is tied a little bit to its layout, because it wouldn't make sense for a calendar to look any other way. But it's not married to that specific page layout, which is what the original poster was asking about.
--
Internet Explorer (n): Another bug -- that is, a feature that can't be turned off -- in Windows.
You should accomplish your layout with DIVs. Tables are supposed to be meta-containers, not exact-layout positioning tools.
--
Internet Explorer (n): Another bug -- that is, a feature that can't be turned off -- in Windows.
I especially like this paragraph:
Are you in some way marketing PHP to clients? I haven't seen so many buzz-words/phrases since the last MS press release I read.
I just have to pick that apart... (sorry)
in my experience PHP is faster
Sounds to me like you're not sure... FWIW, I don't know which interpreter is faster at compilation/run-time, but both offer cacheing of compiled scripts, and on the Perl side there are zillions of modules written in C to handle most anything processor intensive.
more secure
where'd you pull that out of? I think they're both probably limited by the experience of the programmers using each language, and there are WAY to many inexperienced programmers writing code in BOTH of them(how often have you seen user input carelessly thrown right into sql queries?).
more feature rich
That's rich(no pun...), I thought Perl was the language overloaded with features? Further, can you say "CPAN"? I thought so...
way easier to compile and maintain
Compile? I think syntax errors are easy enough to pinpoint in either language... I don't thinking getting Perl or PHP scripts to compile is ever really an issue... or did you mean something else by that? Maintain? I've written a lot of code, and I'll tell you right now that I can write equally unmaintainable code in any language you throw at me ;)
and takes far less code to accomplish the same things as Perl
Nonsense! Ludicrous! Perl and PHP can pretty easily, in most circumstances, be directly translated with minimal effort from one language to the other.
To each his own. But, for the love of Jebus, stop the insanity! They're both useful language, stop insulting each over other personal preferences.
Sticking feathers up your butt does not make you a chicken - Tyler Durden
PHP is what J2EE coders use on their own sites. In a big enterprise, J2EE has gotten enough buzz and is well rounded enough and powerful enough to keep everyone happy. The coders like it because it pays well and the work is there even in this economy. But believe me -- J2EE is not really fun, and not really something people would use if given the choice of any toolset. Now -- this is just what I see, the coders that report to me have been developing great "enterprise level" J2EE apps all year with no complaints and only few YAWNS to this point -- but everyone of them I talk to always say that PHP is what they use when given the choice -- and/or if they have to throw up a site at home....
(+1 Funny) only if I laugh out loud.
There was a dilbert a couple weeks ago which I would recommend for you. It had to do with a user having a fatal illness due to exposure to an interface designed by an engineer.
As a developer with a Master's Degree in Business, I would say that more often than not in my experience it is the guys with the most "engineer" oriented approach in them that create the least attractive and worst performing code.
I do not fear computers. I fear the lack of them. Isaac Asimov (1920 - 1992)
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
Comment removed based on user account deletion
The drawback of using a code in template system, is that your code and HTML output quickly become forever intertwined.
This need no longer be.
PHP has in fact a lot of mechanisms for separation of code and content, and I happen to be guilty of adding not only one, but two of them.
My first stab at the separation of PHP from HTML was a rewrite of the mess that was FastTemplate.class.php at that time, adding the Template class to PHPLIB. This was basically a rewrite and cleanup of the FastTemplate API, later revised by Ulf Wendel and added to PEAR. Now called Integrated Template in PEAR, it is a good base technology for HTML/PHP separation, and can be scaled pretty well combined with Cache_Lite_Output also from PEAR.
My latest attempt in separation is XML_Transformer, again in PEAR. XML_Tranformer tries to do what XSLT does, but without the disadvantage of creating a domain specific - it is basically XML transformation specified in PHP and aims to deliver the 80% of features that everybody needs with 20% of the code compared to XSLT. The design of XML_Transformer is heavily influenced by Roxens RXML (Roxen Challenger, formerly called Spinner, is a very old webserver that had XML transformations long before either XML or XSLT were specified at all) and easily extensible.
XML_Transformer extensions (called Namespaces) are modular, and written properly, are enitrely reuseable. Similar to Roxen or Cold Fusion, they implement groups of tags that can be useful in many projects. XML_Transformer will be presented at the PHP Congress in Frankfurt/Main next week.
Kristian
HTML::Mason / Perl fit every criteria they had perfectly.
Well, obviously it didn't. The "Why not Perl?" slide even includes the Mason logo - they considered it and ruled it out.
I am surprised that Python was not among the possibilities examined
I would think the same reasons that ruled out Perl would also impact Python. Neither were designed specifically with the web in mind.
This aspect of PHP more than anything else is probably the primary consideration of a lot of PHP zealots out there... myself included. This doesn't detract in the least from where both Perl, Python, Ruby, or similar langauges shine. It's just that PHP is the only true programming language that I know of that has this kind of dedicated focus to the web.
No, I don't count Cold Fusion either. Closed source, and support tentative on whether or not Macromedia can still pull a buck out of it. Not a warm fuzzy place to be for a project as large as Yahoo.
The line must be drawn here. This far. No further.
PHP is based off of perl and has similiar issues.
Umm, time for a wee history lesson.
The original PHP that Rasmus Lerdorf wrote back in '95 was written in Perl. The second version was written in C as more folks started contributing to the project. By the time version 3.0 hit the net, it hardly resembled anything looking like PHP 1.0.
PHP's roots do go back to Perl, but that's where the story begins and ends. The whole point was to take a different direction from what Perl was doing, and to utilize a C based structure in the process.
Today, PHP's resemblence to Perl stems from 2 things. Both are roughly C based in their structure and PHP has a number of functions that emulate similar ones found in Perl. Mostly regexp kinds of functions.
Bottom line, you're not going to take a PHP programmer, sit him/her down to an editor and expect Perl to come flowing out. Each language has a very different approach to how to go about doing things.
The line must be drawn here. This far. No further.
What's the big advantage of PHP over C++? The author mentions C++ being "cumbersome" and "prone to buffer overflows". That's a load of BS.
If you have a proper set of string, socket and associative array libraries, C++ works just as well as PHP and offers a whole lot more, if only the ability to check for existence of variables. Plus you don't have to type these f?c?i?g dollar signs in front of ever variable.
The other argument, "memory leaks degrade server performance" indicates bad programming, which is not going to be improved in PHP, but which can be solved in aforementioned libraries. Simply don't allocate anything dynamically outside the libraries. Plus, PHP has its own memory problems, if you don't take care of your arrays. Of course, memory will be freed as soon as the program stops, but that holds for C++ as well and memory management by process termination is another sloppy practice.
So PHP is easier to use in Apache, but that should not be a reason for making such an important change to your code.
And then comes the biggest joke of them all: the list of criteria! Do they really want us to believe that data types in PHP are better than in C++? Do they really think that PHP has "a pleasant syntax"? Or is this simply a red herring?
I can imagine using PHP for web-sites where being neat and efficient simply doesn't pay off, but for the "world's largest web site"...
I'm amazed.
Pardon my ignorance (I've only dabbled a little in PHP), what is the danger of the global variables in this situation?
He who defends everything, defends nothing. -- Fredrick The Great
PHP-Templates are very handy for seperating the logic/formatting as well. Well I suppose thats what they were designed for.
He who defends everything, defends nothing. -- Fredrick The Great
Not a very good rebuttal:
Configuration: "We have to recompile to change the background color". Ah, so the answer to this is, rewrite all of Yahoo, so they can easily change the background color. How hard would it really be to refactor this? (For that matter, how often do they change the background color of Yahoo?)
Perhaps they are suggesting their current app isn't modular enough. How hard is to to refactor a large C app every time a small change is needed to the front end? It's a pain in the arse (coming from someone who has done this for a large C based web site)
Maintainence: As God as my witness, their newly written PHP code will still have more bugs in it 5 years from now than your Y code does today.
Depends how well designed their scripting language is, but remember that with PHP there are a wealth of tried and tested libraries to choose from (eg ADODB). Also with all the PHP developer mailing lists it will be a lot quicker to check if there is a bug in the script or the language itself.
Performance: Their own tests show that their technologies are capable of performing as well as PHP.
Their site is currently comparable... but the site isn't going to switch overnight. If they are planning to take a year to change all the code over, how much faster will PHP be in a years time? They will get that performance boost without their own internal software team having to write/optimise/debug a competitor to PHP as well as maintaining the scripts written in that language.
Iteroperability: Oh yes, PHP plugs into everything. You don't even have to write code. Just put a MySql machine in the same room as your PHP code, and dynamic web pages will emenate. GS[]SARCASM
Have you seen the list of databases that ADODB supports? And gee, I didn't even have to write any code... I just stuck MySQL on my box and within minutes dynamic web pages were emanating.
Personnel: "No one has Yahoo script on their resume". When was the last time you hired someone because they knew a language? Employees are a multi-year investment. Learning a computer language is a weekend investment.
LMAO!!! I would go to the opposite extreme and say that most of the people I've seen hired have been hired exclusively on their knowledge and experience of a specific language. Learning a language is not a weekend investment. You need to learn all the libraries, the specific quirks of the language, the tools that are best suited to that language, how the debugger works best for that language, performance trade-offs in how much OO should be used, and many other factors that only come with hands-on experience.
Phillip.
Property for sale in Nice, France
I picked phemplate because it's fast and has a nice syntax. It does have its limitations though.
Phillip.
Property for sale in Nice, France
I skimmed the comments so far and it seems like some people don't have a very high opinion of PHP.
Well I can only speak for myself.
In my experience:
1) It's flakey, buggy and slow. Script's can cause the PHP engine to core dump.
2) The standard argument for using PHP seems to be it's easy rather than it's good, and that speaks volumes to me. The habitué of news:comp.lang.php are arrogant and rude despite for the most part being hobbyist rather than professional engineers. Hell, they make /. look like a paragon on professionalism. Most of them have no idea what the MVC or 3-tier architecture is never mind advantages/disadvantages.
3) PHP language lacks coherence, it's a bucket of functions & wrappers rather that a designed structured language.
4) It tightly couples presentation with logic; php and html are mixed on the same lines not just the same files.
It's one thing to feel like something is better, but to despise it baffles me.
That because you've never felt that Pretty-Horrendous-Pain. In my experience J2ee IS superior, faster and more stable that PHP. It's a lot more elegant and internally consistent. Indeed from the presentation it seems Y! reason for not choosing J2ee over PHP is nothing to do with Java, but that 'Threads support on FreeBSD is not great'.
However PHP has its place, prototyping and hobbyist sites. It's completely unsuitable for a site than need to be maintained and developed, since its inelegant compounds the classic mainternance issue of diminishing returns on effort. Whereas Java's provides the opposite an increasing return on effort from OO reuse.
register_globals allows URL access to system (OS/Server) environment variables.
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.
That's uh, interesting experience. Where have you found Perl to be unsafe where PHP is safe? I'm not sure I remember the last time there was a Perl security hole which would affect any thing you might want to be doing with web stuff.
More feature rich? Which features would those be? Are you aware of CPAN? And how much bigger and more mature it is than PEAR?
Way easier to compile and maintain? Debatable, especially considering people tend to install from binaries for both. Maintain? What do you mean there? The only application of that I can think of is installing third party libraries, where again, the CPAN tools are a very definite step ahead of PEAR.
So please, can you back any of that up? I'd be really interested to learn of any examples, but frankly, at the moment, I think you need to realise false advocacy like that just harms PHP's image.
Score:-1, Funny
What would cause someone to rewrite a working app? If it was a performance issue, then perhaps your code wasn't performing well? If it was 'rewritten' in the middle of development, that's possible more strange, but maybe at least justifiable (not done with the PHP one, so switching is easier than waiting until after the PHP project is done).
creation science book
Thanks, after reading through the PHP docs for a while I saw this was the case. Personally I usually code like
:)
if ($pw='secret') { $auth=true; } else { $auth=false; }
because of years of trying to avoid uninitialized C variables, but I suppose I'm bound to mae mistankes now and then
He who defends everything, defends nothing. -- Fredrick The Great
A caveman dreams of being us, the incalculable power and riches. We dream of being Q, then what?
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?
heh :)
Doesn't surprise me too much that the PHP is faster. We tried to come up with benchmarks that showed Java faster than PHP for the type of work we do - web-based applications - and it was pretty hard to ever show that. PHP was nearly always faster, or it was a dead heat. I can imagine in some cases Java will be faster, but we had a hard time thinking of ways to show it, dealing in situations we deal in (web-based apps - no doubt there are scenarios where Java beats PHP).
creation science book
A caveman dreams of being us, the incalculable power and riches. We dream of being Q, then what?
I tell you what - format your machine code freely and I'll not complain, but your CPU will (in an abstract sense).
A caveman dreams of being us, the incalculable power and riches. We dream of being Q, then what?
So just whack
...
$auth=false;
before
if ($pw='secret') { $auth=true; }
if ($auth) { do_advanced_stuff() }
They did consider perl, and rejected it because the language is (and I quote from "Programming Perl" 3rd ed. page 4) "...on the other hand, the camel has not evolved to smell good. Neither has perl" - non-orthogonal.
It's kind of rank around the edges, but it gets the job done in many cases. However, for someone switching from C/C++, php is easier. This is why perl was ruled out, as the article pointed out.
What I think you're referring to is PCREs, perl-compatible regular expressions. To be compatible, they have to implement greediness by default.
Look, it's not a holy war. My original comment was about how, for C/C++ programmers (which was what the engineers at yahoo were), it's easier to switch to php than to perl.
A good example - the obfuscated perl contest. It's far easier to obfuscate perl than php.
PS: I use both on a daily basis (week-ends excepted)
Never said it was perfect, did I?
I've never encountered random malfunctions or degradation over time, but there are certainly a number of bugs in each release that one has to squash. That said, it's a good system for someone who doesn't know much PHP yet. I've moved off Postnuke to my own custom scripts, but Postnuke (and PHP-Nuke before it) were very helpful in getting started with PHP.
Because when you use PHP the way PHP was originally intended to be used, it's unsafe.
If you use PHP in a safe way, you lose all the fun "features" that make PHP what it is. In fact it starts to look like Perl being used in a safe way. So they might as well use Perl given that their slides show it performs better in most cases, and they already have lots of perl code.
PHP ala PHP:
register_globals- cgi parameters automagically entering your program's name space.
magic quotes/addslashes etc: Very shortsighted features. Better to always keep your filters for different programs separate and distinct. Otherwise you lose information integrity and end up with annoying backslashes everywhere (especially whenever data is redisplayed and resubmitted).
PHP is gradually getting more secure, however the problem is most PHP programmers out there program in the old dangerous PHP style. Look at PHPNuke or any of its derivatives - they are a mess, full of security problems. Better to rewrite. Same goes for many other PHP programs I took a look at.
In fact the slides seem to give a better argument for Perl than PHP. Perl had better performance than PHP as shown in the Yahoo slides (seems YSP = mod_perl). YSP just uses a bit more memory.
As for maintainability - I don't see why PHP should be easier to maintain than Perl. They're in the same class of maintainability. If you're talking about Python vs Perl maybe, but PHP? Doh.
From the slides I still don't see why they are picking PHP over Perl.
Unless maybe they have lost/got rid of their Perl coders?
In parallel, PERL requires expert coders to code and maintain an 8milLOC PERL script. Perhaps PHP by simplification and syntax-enforcement requires more LOC, but this improvement allows a large number of semi-skilled MCSEs to maintain the script. This should decrease the maintenance cost, but will result in some redundant Perl gurus.
A caveman dreams of being us, the incalculable power and riches. We dream of being Q, then what?
http://public.yahoo.com/~radwin/talks/yahoo-phpcon 2002.pdf
sorry about that, its never happened to me before
Read Epic the first RPG novel.
They run PHP Accelerator, which is as fast but free :)
From the Yahoo slides, YSP is faster than PHP. Just uses a bit more memory.
And from their slides YSP seems to be mod_perl or mod_perl based. See slide0041.htm.
PHP maintainability is about the same as Perl. No language enforced discipline, need programmer discipline.
So why are they picking PHP over Perl? They ran out of Perl programmers?
Java requires just too much unnecessary work. For example it was easy to find out how many columns you just selected from a DB, but hard to find out how many rows. I went like "WHAT!?". This and many other annoyances discouraged me from using Java.
I want to solve the problem not the language.
Actually, the big problem comes when a string function returns '0' if it finds a regex at the first character, or '0' if it doesn't find it at all. If a failed find returned '-1', like just about every language I've ever used, this would be unnecessary. That is my only real grip with PHP.
Thomas Galvin
This does not lend much credibility to the rest of your argument.
-Hope
Has Yahoo or PHP (or Zend) done any kind of press release on this? It would be nice to have something that we could send PHB types to have a look at when proposing various solutions, something better than a frameset of a technical conference presentation. I took a quick look around and couldn't come up with anything.
Bleh!
I find it interesting that the Curl website is served up by Java Server Pages. I'd have a little more faith in their tech if they were using it themselves.
Bleh!
The use of -wT only works in the smallest scripts. A 9 milLOC script would generate thousands of warnings, tempting you to ignore them, which makes the first argument doubly important as now you have to port the entire script to a compilable language like C++ or Java.
A caveman dreams of being us, the incalculable power and riches. We dream of being Q, then what?
Perl isn't any harder than any other language to code with in a team as long as CVS (or other revision system is used) and a common set of programming rules are set up for the team and commenting is done at least to some extent. It works, I've done it.
r ever()
... yeah daylight savings time breaks that.) And requiring or including modules is braindead if you can't include the same module twice (like if one is in one file and on is in another), gives you an error. Also for web apps it's nearly impossible to completely separate HTML from the actual code.
As far as PHP, I use it because i'm required to for my job, however I think its namespace issues are a mess. I can't say it enough times: I_really_hate_typing_function_names_that_go_on_fo
With perl that function is in a package and you assign it an object variable or import what you need into the namespace.
And what is this garbage about Perl having longer development times? I had a long discussion in person with someone on this very subject recently. "Perl takes so much more code than PHP". Has no one even heard of CPAN??? There are pre-built functions for everything, frankly I've found the opposite problem with PHP. With Perl I can find a CPAN module to do what I want. Ever tried parsing HTML in PHP? -- actually parsing it not striping it out. Or intense date manipulation? Sure some of this stuff has been written but its a pain to find and nothing is tested so if doesn't work half the time and then you can't easily install modules that can be used everywhere.
PHP has horrible interpolation, regexes you have to call a function? Good date parsing is non-existant (sure you can display them but what about adding them and subtracting? And don't give tell me that you can convert them to UNIX timestamps and then add
Everytime I do PHP I feel like someone complained about lack of X function and so it was just slapped in rather than carefully thought out. With no way to really extend the language without dumping crap into the core. Perl is elegant and functions make sense and objects make sense. It has basic stuff in the core language and you call modules with the extensions you need.
To stay on topic in my personal opinion Perl is far easier because it doesn't try to hold your hand, that's what the man page is for, not to mention the countless resources on the web.
The Anti-Blog
"Tables are deprecated" said by me implies that I think that tables are deprecated.
You're quite welcome to not agree with what I say, but don't try and change how I said things.
--
Internet Explorer (n): Another bug -- that is, a feature that can't be turned off -- in Windows.
Well yeah, but it's the "as long as" part that's more difficult. No one said it was impossible, just more difficult, mostly because there is such variety in perl coding styles. Like I said, not everyone is as good at doing those things in a team environment as we might like them (or ourselves) to be. That doesn't mean that they are necessarily bad programmers and should be shot, but that perhaps Perl isn't the best language to learn these things on.
As far as Perl vs. PHP my personal (un-PC) stance is that Perl wins hands down for pretty much everything, so I guess that part of your post wasn't related to mine.
sic transit gloria mundi
So do you turn on use strict and -wT, or do you decide not to grovel to your boss and install the unstable script? Afterwards, you can blame Perl and recommend switching to PHP. Explains a lot, eh?
A caveman dreams of being us, the incalculable power and riches. We dream of being Q, then what?
A caveman dreams of being us, the incalculable power and riches. We dream of being Q, then what?
A caveman dreams of being us, the incalculable power and riches. We dream of being Q, then what?
That's like saying Vans (or make your pick) are unsecure cars because women are atracted to them. Giving uses something as simple as PHP is indeed a problem for them. Even suposedly experienced programmers make a lot of mistakes.
I've sen lots of codes where input was not being validated. And seen data that came through forms beign validated in intermediate steps and not the final one, or FORM info including what "table" to use (jikes).
It's not PHP fault though...
unfinished: (adj.)
A caveman dreams of being us, the incalculable power and riches. We dream of being Q, then what?
After all the problem isn't what a programming language was designed *for*. It is how well it does a project. If someone judges a language based upon the origins of that language then I think they are being silly. It's like complaining about FORTH languages because they were designed for astronomy and robotics.
But what does PHP do that Python can't?
.htaccess file are a few things off the top of my head that make PHP a stonger candidate for this type of application writing.
I'm honestly not up to speed enough on Python to say. I believe it is fair to say that Python presents itself as a general purpose language for use in a wide range of uses. PHP doesn't. It's a language with a set of commands that are very focused on creating web applications.
To your point, PHP definitely does lose benefits stepping outside the realm of the web. It generally isn't meant to go there. With that in mind, I guess I'd have to toss the reverse question back at you.
What does Python do specifically for web applications that PHP doesn't?
For how I use PHP, I don't believe Python would be as suitable, but again I must disclaimer this with my ignorance of the language. PHP's native ability to process forms, integrate Apache environment variables, and even the ability to set PHP run time attributes directly within a
Where as I'm sure Python may very well be able to do these things, PHP has this stuff natively entrenched into it's core. In Python, I would think you would not want this kind of native web server support for a general purpose language.
I do realize that both Python and Perl have tons of extensions and modules that provide for both web and database interaction. PHP has this stuff built in from the ground up. Again, the difference lies in the focus of the projects.
Now if I could just get the time to crack open this "Learning Python" book I purchased too long ago, I could probably come up with a better answer to your question!
The line must be drawn here. This far. No further.