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
No XML, J2EE Engines and the like? Afterall, simple PHP?
Would the PHB's like it?
S
*applys for a job*
I'm a big retard who forgot to log out of Slashdot on Mike's computer! LOOK AT ME.
Slashdot? :)
I know, I know, probably not.
I'm not understanding the reasoning behind choosing php over perl. Maybe it's just me but I've found perl to be a more secure and easier to maintain for larger projects than php.
How is it that one careless match can start a forest fire, but it takes a whole box to start a campfire?
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 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.
Can you imagine writing code to be deployed onto 4500 servers and get hit 1.5 billion times a day? That's nuts.
...considering it's initial creator is now a Yahoo! employee
Why would they not "upgrade" to the increadable "secure" and "functional" C Sharp? LOL but seriously, PHP is a good move. I have seen alota sweet stuff done with PHP as of lately. -Geek
yahoo will need more E10000's soon ;-)
Happy days.
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++?
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.
This must be why my yahoo mail hasnt worked for crap these past couple days....
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
well, we'll see how much yahoo! likes dealing with the Exploit-a-Month club that is PHP. :-( buncha insecure-code writing hacks...
And took a break to come over here and see what's going on... but I just can't escape it!
Seriously though, I love php. It has done a lot for me (several jobs while I am in college), and it makes my life easier (I use it to do all of my shell scripting and personal websites too).
The language is good and solid - it is great to see it being used in places such as Yahoo, this means it is really coming to be accepted by large businesses and will mean it will be around for a while.
Derek
A few papers at this site involving php and security. Php has got to be one of the worst. www.cgisecurity.com/lib
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.
How does this effect my yahoo email account?
PHP: almost object oriented
PHP: a problem for your problem
PHP: at least its faster than java
I think you meant losing. Loosing = To become loose.
Since when is C++ proprietary anyway?
SIG: HUP
Go follow the link. It could be considered humourous!
Somewhere under "Costs of Proprietary Languages" in the slideshow, he says that it's "hard to hire engineers who really understand C++"? What? Listen, butthead, if they don't understand C++, they're not fucking programmers at all. They're idiots: Web-designers at best, pizza-delivery boys or sysadmins at worst. C++ is nothing an intelligent person can't learn thoroughly in a reasonable period of time.
What he's really saying is that you need idiot-friendly toy languages like Perl and PHP so you can hire people who are not engineers of any description, because they're cheaper.
Once that point has been clarified, it's a reasonable point and it makes perfect sense. No competent programmer wants to waste his time designing web pages; that's why PHP exists: So we can hand over the dog-work to losers who'll be glad not to be flipping burgers any more.
Five'll get you ten, 95% of their PHP "engineers" first walked into the office with a pizza in their hands: "Thanks, guy, here's your tip. Oh, hey, wait a minute... Want a job working on our web site?" "Uhhh... duhhh... done it pay good?" "Yeah, yeah, shut the fuck up and sit down over there, okay, read this O'Reilly book tonight, I want to see some code tomorrow..."
I'm not saying that Linux is always better than BSD, but this also isn't the 2.0 kernel days where linux couldn't handle a load like BSD could. Plus Linux scales better and also has much more going on in the cluster area then BSD does.
Again no flame, but performance wise linux is just better than BSD. I wonder if its a license issue?
"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.
3 Million lines of perl?!
Well I am sure there are some perl monkeys on slashdot who will proclaim "Hell I can reduce that 3 millions lines down to 50 in perl!"
Maybe with Yahoo using it they will decide to make the language a bit faster. There is a lot of slow parts in it such as function slashDot is different then function slashdot which is different from fucntion SlashDot. There is also a huge speed difference between echo and print. I want a language that is lean and mean.
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.
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.
A corporate presentation with this included on page 20:
"Why not ASP or Cold Fusion?
Pros
- lots of 3rd-party integration
- professional support
Cons
- CF has ugly syntax
- $$ for languages
- $$ for Microsoft Windows "
Bold added by me for emphasis
?sp
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.
What does it mean?
If Yahoo can do it, why can't slashdot?
/^[A-Z0-9._%+-]+@[A-Z0-9.-]+\.[A-Z]{2,4}$/i
Ok. Maybe not. But would have been funny.
Thank you. Drive through. (:wq)
Might be awfully nice and useful info to have... (And since they're "giving back to the community anyway"...)
Besides, who knows, they might just have made the classic beginners mistaken and put the database connectionstring (including username/password) in an
I hope they don't need to use the pow() function on Yahoo. It's been broken in every release from 4.1.2 to 4.2.3. Sure, they fix the bugs, but never actually put the bug fix out. Maybe, just maybe, we will have a working version of the pow() function in 4.3.0
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.
Let's see... PHP is free and WebLogic is, well, the exact opposite of free. Are you willing to wager a guess how much it would cost for licenses and yearly maintenance for 4,500 WebLogic servers? Let me give you a clue - it is not cheap. Yahoo has done as well as it has in large part by keeping its costs low - using FreeBSD, as an example.
On the technical side, unlike Java, PHP does not have a compilation step so webpage development turnaround time is much quicker. Nevermind the fact that you can usually do most tasks in half the number of lines of code and half the development time in the PHP scripting language as you do with the statically typed Java language. Compare the two languages' associative array syntax, as an example.
PHP has the ease of use of Javascript with much of the power of Perl. It's syntax is short and sweet with no need to declare variable types.
That's why web developers and content providers love using it.
[2:32am] *PHPDev (phpdev@dev.yahoo.com) has joined #php
[2:32am] [PHPDev] hey, can i get some help with echo() ?
I wonder if they considered AOLserver and if so, why they ruled it out.
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
Yahoo is a great poster child for FreeBSD, the world's most robust free operating system.
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
Open Source (Apache and PHP) is the standard in the webserver space already
Right now, only NBM (nothing but Microsoft) users and legacy systems run IIS
I think you're forgetting about the hordes of people who run some sort of Apache+Java app server.
For medium-large web businesses, I've mostly seen Java. I've only seen PHP for small businesses.
Their reasoning for throwing out Java seems like utter nonsense. What on Earth does FreeBSD have to do with anything?
They used a red herring argument abuot thread support on FreeBSD (they should change OS's anyway) to discount what's obviously the best choice - Java technology.
I hope more than this one PHP cheerleader is making the decisions on this.
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.
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.
There's no debate. Perl LETS you make a bigger mess than any other language, ever!!
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"...
and we still don't have to wear a suit
I quit because of the fucked up dress code. First a private school, then my first programming job(after making enough to get my iBook).
Oh well, only three years of high school to go, two if I schedule my classes right.
You can't judge a book by the way it wears its hair.
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
Are there any Unixes that have fast-spawning threads?
As copyright owner of this comment, I authorize everyone to defeat any technological measure which limits access to it.
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.
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.
I like how the link to Yahoo goes thru doubleclick.. I understand OSDN/Slashdot/et al need funds, but if I wanted to support doubleclick, I'd click a banner, not a link on a site I visit regularly..
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.
PHP is easy to compile? That's great to hear. I've been having so much difficulty compiling my scripts.
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!
- Nothing like CPAN.
- No DBI or ODBC, eash DB has it's own API.
- Hardly anyone uses it outside the webserver context.
- Few if any bindings for GUI interfaces.
Have any of these improved?Actually proir to PHP 4.1 it was very easy to create PHP scripts with security holes in them.
Now with PHP 4.1 it is much improved, as long as you follow all the instructions and turn off register_globals.
[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.
I can surely understand all of their reasoning. However, why are they complaining that their proprietary scripting language has an "unpleasant syntax"? If they developed it themselves, couldn't they have made it as nice as any other nice language?
That's a good idea. About as good as the EJB overhead on intel Pentium III's (i.e. the test platform mentioned in the slides, which should mimic their real boxen environment) - that guy must code for IBM mainframes or something.
Why wouldn't you go with FreeBSD? Anyone who claims linux is faster hasn't tried both.
That'll teach me to preview, eh?
Oh, shit. The idiots who wrote Slashcode are a bunch of mouth-breathers: This "ecode" thing only allows one level of indenting. HELLO, ASSHOLES? Jesus Christ, leave even the simplest, most trivial task to a Perl "programmer", and watch it turn to shit before your very eyes... It's rare to find anybody stupid enough to fuck up something like that. Morons! If their "senior" programmers were working for me in entry level positions, I'd fire the jackasses in a week. No refs, either. Fuck 'em. Back to the gas station, boys. You just ain't cut out for a real job.
In Java:
...and in Perl:
Did somebody put Java on a memory diet which would make it viable for the relevant intel platforms recently? [The test platform was a pentium III on FreeBSD. Would you recommend the most popular site in the world trash it's investment and move to "big iron"?]
How about that High-Po Java unicode string parsing? This is about pumping out ascii strings isn't it? Of course they could just do the byte array manipulation workaround. [Well at least that would be "C" like, another "goal" of their effort]. Sounds like they have a lot more practical experience than you and chose what would work for them.
Java's not any kind of scripting language at all. They're looking for a scripting language, not a language that has all the drawbacks of a compiled language (they've got those already, homes), with none of the speed advantage. PHP's faster to execute than Java, and much faster/easier to write in. Java's not much more user-friendly than C++ (except the garbage collection, but that's a brutal speed penalty, plus any moron who knows his job can manage memory just fine without it -- the time I spend finding and fixing memory leaks is a small fraction of the time a Java programmer spends drumming his fingers on the desk, waiting for his code to run... but only a fool would use C++ for rapid web development, and for exactly the same reasons, only a fool would use Java for that job).
Java has proven to be useful for exactly nothing. It failed on the client because it's so slow and because it's one of the least portable languages ever developed; it's failing on the server for the same reasons. Bottom line? Don't write all your libraries in an interpreted langage: Libraries are used by everybody, so they justify the extra effort to write them in C or C++ for speed. Every interpreted language but Java takes advantage of that "economy of scale", and guess what? Perl, Python, and PHP have succeeded dramatically with no marketing budget and continue to grow, while Sun's billions still can't seem to plug the hemhorrage in Java's user base. It's just to damn slow. Furthermore, it's not good for anything. It has no practical uses in the real world. What advantages do you gain in return for the slow speed? None. It was designed without a single thought for usability, and as a result it is virtually unusable (ideology is no substitute for real-world experience with people writing code in the language; the designers of Java got NO feedback from working practitioners on any prototype implementations before finallizing the design for all eternity (compare that to the iterative way C, C++, Perl, and Python were developed)). It offers nobody any kind of compelling value proposition. It's slow to run and slow to write, and in practical terms it's less portable than C. It offers NOTHING.
Java is the Britney Spears of programming languages. Yeah, she looks cute just like Java does and all the commercials on TV tell you to love her, but in five years you'll be embarrassed to admit ever having liked her or Java. Most people already know there's nothing there. The Emperor is bare-ass nekkid (wish I could say the same of Britney...).
but does it change the fact that they read my e-mail and log my every move?
Not really,
super globals didn't really introduce anything new except the arrays being automatically global.
Before $_POST there was $HTTP_POST_VARS before $_GET there was $HTTP_GET_VARS.
If you don't take the time to write secure code any language is going to be secure, it is the programmer not the language that makes a program secure.
PHP has made a grep step forward
:)
With a slip-up like that, we know we're looking at a comment from a bona fide programmer here.
-Waldo Jaquith
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?
From the presentation:
Tradeoffs: App Logic in C++
Advantages
- fast execution speed
- strongly typed, mature language
Disadvantages
- edit, compile, link, debug cycle
- not conducive to rapid prototyping
- too easy to make mistakes with memory
The "edit/compile/link/debug" cycle is not nessasarily smaller for C++. In a previous job I was able to dynamically link in C++ objects into a running apache server. There was a pre-processor, very much like ASP that spat out classes that compiled, linked and loaded straight into a running system. In a debug mode, the pre-processor made it so you could click anywhere in a page and it would take your editor to the line and column where that html was generated. It was a simple save and the file was automatically compiled and the new DLL would automatically be loaded directly into the running apache server. It was sweet and fast and the edit/compile/link cycle was about as fast as aything else. As far as rapid prototyping, I think it was equivalent to any of the scripted languages. It was tightly coupled to the database so that sizes of fields wer directly taken from database definitions where appropriate - no having to keep those in sync; in a prior life I remember endless bugs of input being truncated because the database could not take all the data.
The most important issue when it comes to software development is "mature language". There are plenty of examples of very large, relatively easy to maintain complex systems out there in C++. The fact is that most web systems develop far beyond their original scope. Rapid prototyping can be done simply using plain HTML and a macro language.
I suppose I'm so vocal because it bugs me that people don't see the wood for the trees. Before re-inventing the wheel, make sure you know why the original wheel is the way it is. Maybe this is not a case of this but it sure sounds like it.
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
i would help script it! :)
ASP is controlled by Microsoft, which also runs MSN, a direct competitor to Yahoo. Yahoo using ASP would be like MS using *nix boxes to run Hotmail. And unlike Hotmail, where MS could bury somewhat the fact they had to use *nix servers for awhile, Yahoo! using ASP would be instantly visible to the world.
and takes far less code to accomplish the same things as Perl.
I would question this one. With sufficient web libraries, I think Perl would hold its own here on the average, and I am not a Perl fan.
I would like to see named parameters added to PHP, BTW. And something has to be done about needing a "===" (3 equals) operator for certain operations. That one exposes some embarassing language design flaws in PHP IMO. It has to do with a "hidden" type indicator I think. I don't like hidden type indicators in scripting languages, personally. They are anti-WYSIWYG.
Table-ized A.I.
- 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.
If you had read the info you would see that Yahoo is using PHP for the presentation layer. Using J2EE for presentation layer logic is ridiculous. Sounds to me like backend business logic is done in C and C++ which means the combination of PHP for presentation layer and C or C++ for business logic is going to run circles around any of this J2EE stuff people like to hype.
fucking moron
Not to flame but over the last year I have migrating all my php applications to mod_perl ... Will admit I started out on PHP and it was quick as hell to use but as I progressed I kept finding more and more shortcoming that Perl addressed. Also, the speed advantage died with mod_perl. Check out yahoo own charts where the perl test consitantly(?sp) beat out the PHP solution (though not by much).
:) and perl is one of my last hopes to avoid it.
I find Perl to be the same of your fifth statement about PHP. Perl is faster, more secure, more feature rich, and less code to complish the same thing than in PHP. And I started the first 3 years of my coding life ONLY using PHP.
They both have their places and not dismissing PHP, it is great for a quick lightweight solution. But for enterprise sites, will go the perl route. Then again, I rather hate OOP
De Oppresso Liber
I read their defense of the rewrite decision. I don't buy it. 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?)
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.
Performance: Their own tests show that their technologies are capable of performing as well as PHP.
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
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.
I wonder why they did not consider python?
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
FreeBSD is a nice OS.
An ex BSD user...now I use Gentoo Linux.
Peace !!
Oh, you don't like, "Die OR Perl"?
Perl: Write once, wonder forever.
At least they don't have the social skills of gnat like some.
Well if you read the presentation carefully you will see that one of their reasons to use PHP was clarity of code.
I.E. Perl may take "less code" but less is not always better - especially if you have a MULTIPLE developer environment. I have never seen a large scale Perl application that was easy for multiple developers to maintain and manage - the differences in coding style are too great, and the ease of obfuscation too high.
PHP on the other hand is a very clear language, and while yes, the OOP pieces are not primary, the language itself is very well designed for developing web-applications.
My experience with PHP is that of owning a software company whose products are entirely PHP based. These include near-realtime AI applications. PHP has been a very powerful component in our development process - allowing us to write applications that are clear, easy to understand, well documented, and still fast and scalable.
While it is certain that we could have done much of this in Perl, it is also very likely that it would have taken us longer to code, and that ongoing code reviews would have been more difficult - further PHP's simplicity is a large part of the value.
Our code is anything but simple - we have code that is auto-generated (on the basis of data we have code that writes itself), our code manipulates multi-dimensional arrays, we do file, web, and database access - all in a very compact amount of code.
In an enterprise development environment performance speed is NOT the only criteria, ongoing development and maintanence issues are also very crucial.
Fast code, that is impossible to debug, maintain, update, or correct when something has to change rapidly costs more than the costs of adding slightly more hardware/bandwidth/memory to support the software.
Indeed, in supporting developers the largest advantage of a migration from a complex (but powerful) language to a more simple language is the increased clarity of the code (C++ to Java; Perl to PHP). While you can argue till you are blue in the face about the relative merits of each language - a language that encourages clean code and facilitates rapid development and intra-developer communication is a very very good thing.
-- Join us in Chicago May 1-4th for MeshForum -- writer, historian, tech geek, entrepreneur, internet junky since '91 --
I've found PHP so much easier than C++, VB, BASIC, and Java...For what I do, it's much easier and more supportive...however, I've never done anything in Perl...
At first, it was Yahoo!. Then, they started using the Y!...YaPHPoo (Yaff-poo) now?
Now, one last note...If programming languages could speak...., what would PHP have to say for itself now?
--<Mike>--
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
You spewed the following drivel:
"I'm not a "web app" developer; I'm a real developer who got dragooned into wasting a few months on a web project because that stuff is trivial and we couldn't see any sense in hiring a "web app developer" for something that a programmer could do twice as well in half the time. And then we'd have to fire the poor fool when we were done with him."
You're the same "real developer" that wrote a JSP web project that was so slow that the client thought the server was hung, right? Hmm.....
So the truth, like memory from your code, is slowly leaking out... You're a bigoted C++ programmer that thinks templates are the greatest thing in the world... Sure, Java doesn't have templates, but it does have built-in threading libraries (which C++ doesn't) -- and I find them far more useful...
By the way, the only reason you like templates is because you've never had to debug one...
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.
Well... I don't know if someone else has already pointed these things out, and I don't have time to go through and read all 6800 posts, so I'll just voice a few complaints about PHP.
I use PHP because that's all that's available on my web hosting service other than cgi. I could use the cgi-bin but then all my URLs would start with cgi-bin/, which would suck.
PHP is nice for doing database query stuff, and it's nice for simplifying your pages (for instance if there's a standard block of HTML you want in your pages and don't want to have to copy it all the time or re-compile a bunch of static HTML files), but as I've used it, I've come across a few problems.
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).
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.
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.
I (and it seems other people do, too, guessing from the user-submitted documentation on PHP.net)have to use nasty hacks to get around these problems all the time.
As far as alternatives go, right now I'm a big fan of Python. It has lots of useful libraries, and the language is very elegant (sp?). The one thing I don't like about it is that every time you access a variable, it has to look up the name in a dictionary (I think).
Unfortunately I couldn't get mod_python to work. I'm writing my own web server (in Python), instead, so that I don't have to deal with all of the Apache/PHP problems I've had. Looked at Medusa, but that seemed a little too complicated for what I was doing.
I actually don't care much about the syntax of the language I use (as long as it's not too unreasonable). What's important to me is that I can use an elegant, efficient runtime in which I don't pay for things I don't use, and that I get a useful standard library. I think I'll be happier when I can use mod_parrot :-D
I'm still stuck with PHP on my real site, though (as opposed to my personal box that I play with).
Duct tape, XML, democracy: Not doing the job? Use more.
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)
=== means equal in value and in type, ("" == 0) is true but ("" === 0) is not, you could get the same result. The only time you see it in code is for checking results from functions that return false as an error but 0 or "" is a valid return value. So by using === you can diferentiate. This is actually the same setup as in javascript, im not sure how perl handles this but if it doesn't use the same rules then its more confusing cause then its acting kinda sorta typeless, instead of being explicitly typeless
Yes, but this is true with most software. (Especially Windows or Outlook.) You can't really say PHP is any more insecure than C... beginners are likely to use the functions that don't validate input and cause possible buffer overflows. If you code safely, your PHP applications can be just as safe as any other language. And it's pretty simple in PHP... I don't know what steps need to be taken in C or Perl but in PHP basically you just need to be careful enough to only use $_GET, $_POST, $_SERVER, etc instead of global variables.
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
PHP is more flexible than straight ASP. In order to really utilize ASP you needed to write custom COM objects, and that's difficult to do in a hosting environment.
But you might wish to look into ASP.NET, as it's a signifigant step up above either.
Part of the "cause" of this oddity is that many PHP functions use a zero base, such as for character positions in a string. If they used one-based, then they perhaps would avoid some or all of this zero equality confusion. I personally find one-base more natural for things like positions and subscripts, but I guess they did zeros for C-compatibility/familiarity.
I wish language makers would have the balls to toss all the dumb things about C and start fresh.
Table-ized A.I.
Comment removed based on user account deletion
You should accomplish your layout with DIVs. Tables are supposed to be meta-containers, not exact-layout positioning tools.
:-)
;-)
:-P
In a perfect world, this would be true. I tried. I mean I really tried to not use tables for non-tabular data, but if I used tables, my page showed up just like I wanted it to, and was more tolerant of different browsers than it was when I tried to use floating DIVs (looks best in links
I might be able to use floating DIVs if they could be 'contained', and not overflow into sections of the page where I don't want them. But If I have something like:
<div>
<div class="box" style="float:right">
Lots of text
</div>
Small amount of text
</div>
<div class="box">
text of box
</div>
Then the box in the upper right overlaps the lower one, which is not what I want. But the table:
<table><tr><td>
Small amount of text
</td><td>
Lots of text
</td></tr></table>
Does exactly what I want. See my webpage if you're curious. (Or if you know how to do this right
I don't like using tables for this kind of thing, but they do work better than anything else for what I want to do, as far as I can tell.
Maybe if there was a 'layout' flag, to tell the browser that the table isn't really displaying tabular data, but is only being used for layout purposes? <table layout>blah</table> Then all would be well.
Duct tape, XML, democracy: Not doing the job? Use more.
hf2k was way, way too hard to maintain. Especially when you inheirited someone else's collection of undocumented hacks.
Any good/bad PHP/Apache 2.x experiences out there?
I heard PHP wasn't quite threadsafe yet. Is this true or false?
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
Chee-pee Chi-a-nee H1B ploglammel velly happy!
Go back to the Slashdot synopsis of the article... no, let me help you:
"Yahoo has decided to switch from a proprietary system written in C/C++ to PHP for their backend scripting."
Does that sentence sound to you like they are replacing NOT replacing their C/C++ backend logic with PHP you dyslexic dumb fuck?
Why would the author of the presentation even mention J2EE in the same sentence if there is no possibility that they would put PHP where J2EE would belong you pimple-faced crack whore?
Why is everyone lobbying Java as a silver bullet to every problem? Creating web-applications with Java is RIDDLED with problems.
.. never? It's not the Java language as such, but the overly abstracted crappy JDK classlib, ridiculously complicated web application technologies and so forth .. not to mention EJBs
I have done almost 5 years of web application development with J2EE. Large applications with internationally known clients. I'm not saying Java is bad, but it's not very good with web apps either.
Some things to consider:
- JVM's work differently. x86 vs. SPARC threading, or IBM JVM vs. Sun JVM. Only way to get best of Java is to use Sun SPARC JDK/JVM. Period.
- Java is not cross-platform enough. Java is currently supported on so few platforms that it's really not as cross-platform as PHP, C/C++, or even Perl.
- Java's web technologies (except maybe Servlets) are such an unusable mess; Struts, taglibs, and JSPs are crap. You can only think that they're good if you have nothing to compare to.
- Java development is slow. Admit that! When was the last time your commercial project with a deadline(tm) was delivered on time? Let me guess
Sure, go ahead and say it was just us that sucked, but if you go check out some studies from companies like Standish Group, you quickly notice that most (over 80%) of all projects don't meet their deadlines.
- Java is still "work in progress". Not many sites run Java. Please understand, that if magazines boast Java, and Sun markets it, it DOESN'T mean it's in widespread use in web applications. Even this site you now read is written in Perl, not Java.
- Java is mediocre. As a language it's just mediocre collection of features from earlier languages. No need to hype Java.
- Java application that is much abstracted is not easy to extend, modify or debug, contrary to the marketed opinion. That works only in books, but practise shows that when application gets complex in it's structure, it also gets hard to modify. It takes less skill (no CS degree) to update a PHP+HTML+MySQL site than Java+Servlets+JSP+taglibs+Struts+... site
- Use right tool for the right job. PHP is great tool for the web, Java isn't.
- Java application servers are so different in their implementation that deployment of a J2EE application is a hell to more than 1 server. Try it. I've deployed to Resin, WebSphere, JBoss, JRun, WebLogic and Orion. Only about Resin I can say good things, but not many clients use it so far.
- Word "Enterprise" does not mean anything except marketing. An "Enterprise" application can be made with any language, and MOST enterprise-level or mission critical applications have been done with Cobol, C, Ada and C++.
- Java is SLOW AS HELL. Consider for a moment that Linux was programming in Java. Goddamn, it would boot like 2 days, and opening an application would propably crash to a NullPoin terException with no usable information in the stacktrace
etc etc etc
No, that is not a problem. It is a benefit for fast prototyping and throwing together a quick solution.
.inc and a .php. Force yourself to write the .php with only simple loops, include statements, and echo commands; all other code goes in the .inc file. Works great.
For serious projects, it is up to the programmer to make the seperation between logic and formatting. An easy method is to have every page in two parts, a
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.
I certainly wouldn't want a system that did rm -rf / all the time by default... :)
-- No, no -- Not that one!
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
( I have used Haskell a bit, and since then i wish there was a powerful mainstream language that is *completely* typechecked at compile time. )
Y! LAUNCHcast uses ASP.
nirvanis
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.
You cannot distinguish between variables
...
from within your code and variables from
outside (via i.e. index.php?foo=bar...). this is
not a security concern in the first place, but
prone to errors, like:
if ($pw='secret') { $auth=true; }
if ($auth) { do_advanced_stuff() }
someonce could let advanced_stuff done, without
knowin 'secret', by calling the page with ?auth=1
HTH
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
That's funny.. I made a CMS in php one year ago for a website and the boss decided not to use it and rewrite everything with JSP and servlets because he said php couldn't handle "high-traffic" sites (and the boss considers a 15,000 users/day site a "high-traffic" one)...
HTML is a markup language. HTTP is a protocol. The difference is that mark-up languages are data, while protocols are used for the transferring of data. Contrast XML and FTP. Or the English language and the IRC protocol. Or BASH and ssh.
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
If you're going to look at benchmarks, I'd suggest looking at both the Caucho and Chamas benchmarks:
Caucho benchmark
Chamas
It's worth keeping in mind that Resin is Caucho's main product. I'm not claiming that Caucho distorted their benchmark in any way; I'm just pointing out that they have a vested interest in the outcome of their benchmark.
Similarly, Chamas is the originator of Apache::ASP. Again, I'm not claiming that Chamas distorted their benchmarks in any way, but it is always wise to be aware of potential conflicts of interest. Though in the case of Chamas, the potential conflict is respect to Apache::ASP vs. other technologies rather than Java vs. PHP.
Hmm, I use both Java (JBoss) and PHP. Maybe I should make my own benchmark.
I'd say that if you are primarily interested in failover, message queueing, and the other stuff addressed by J2EE, go with JSPs/servlets/EJBs. If you want to build and deploy something quickly, cheaply, and with low performance overhead, go with PHP.
They are going to need Zend ;)
Notepad specialist & FAT administrator, group training available
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?
Lets say you set a cookie called "admin" and you only set it if the user on your site has admin privileges. If you check for admin by assuming PHP will put it in global context and do something like if (isset($admin)) { ... }, users might request the page like this: index.php?admin=1 and because PHP will bring the variable from the GET string into global context, and you don't know where it came from... the user gets admin privileges and can abuse your code.
The proper way to code in PHP is to check like this: if (admin($_COOKIE["admin"])) that way you know for sure where the variable came from.
... there are several shortcomings:
:)
:). Yes, I know about phpize and php.ini, but some module can only be installed staticly without some heavy patching.
1. Namespace pollution, and they are growing on each new version of PHP, fast. Example: the function str_repeat didn't exist under PHP 3, now suppose somebody created a function using that name, now when upgrading to PHP 4 his scripts no longer works, he needs to do some searching and replacing to rename his function.
2. Config file (php.ini), so that one installation of PHP could be different than another, leading to case that a PHP script works on one PHP installation but don't work on another. This is really a debugging nightmare, especially if you need to debug somebody else's scripts
3. Bloated. There are too many built in functions that shouldn't have been put in the core, for example functions like str_rot13 and md5_file are not useful in almost all application, yet they still consume resources. They should have been relegated to a part of PEAR or something.
4. Adding an extension to PHP is a mess. You need to recompile the whole thing if you want to add a module to PHP. You can only use either compiled C language (PHP API) or PHP language (PEAR), but not both. And of course PHP need something like perl -MCPAN -e 'install Foo'
5. PHP is not secure by default under shared hosting environment where a user doesn't trust another. Yes, I know about safe_mode, but that will get you some security at the expense of flexibility. A better approach is to use CGI mode, but this requires different treatment to PHP scripts than when using regular Apache module installation.
OK, that's what I can think right now.
So just whack
...
$auth=false;
before
if ($pw='secret') { $auth=true; }
if ($auth) { do_advanced_stuff() }
When I opened this story, it had a M$oft .net advert at the top. Is it only me that finds this funny?
poot
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?
Due to Yahoo! choosing against Perl based on the fact it wasn't originally intended for the web I fully expect them to get all of their electronic computers back breaking WW2 encryption.
404 Not Found: No such file or resource as '.sig'
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.
way to take that post seriously. 2 points for you.
Read the link.
Furthermore, if you don't completely read the comment and links don't comment on it, you don't know what you are talking about.
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!
"You say any clown can setup IIS. So, you must be a clown."
:).
We assume that he can set up IIS, but it does not logically follow that he is a clown. Being a clown implies being able to set up IIS. However, being able to set up IIS does NOT imply being a clown. In other words, there are non-clowns who can set up IIS. He might be in the population of non-clowns who can set up IIS, thus we cannot conclude that he is a clown.
That said, the original poster is either a troll (a nicely veiled one at that) or a shill
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!
"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.
actually Yahoo employees have yahoo-inc.com addresses
I think Perl is great for many many many things (did I mention 'many'?) but it seems you have to write an encyclopedia just to do the simplest tasks for integrated web apps.
Like all the Java naysayers I've talked to, I know it well enough to use it, and I'm an experienced programmer.
Like all the Java fans I've talked to, you're a college kid who only knows one language: Java. And you like it pretty well, because when you took a semester of C you had a hard time with pointers.
Java's an overengineered mess. Yes, it is much slower than Perl or PHP, because Perl and PHP have an absolute minimum of interpreted code. A whole boatload of stuff is pushed back into native code. Java, on the other hand, has the bizarre approach of maximizing the amount of interpreted code. This is best characterized as Anti-Optimization: Concentrate your inefficiencies and sluggishness in library routines that get called everywhere, including tight loops. No wonder the language is a dog. But don't take my word for it: Code the same stuff in Java, Perl, and PHP and watch the Java finish dead last by a wide margin. I'm not talking about GUIs, either; even the Java partisans are finally admitting what a disaster it was for those. I recall they tried to brazen it out for a couple of years, though, just as you "server" guys are trying to kid yourselves now.
Java does not, of course, offer anything resembling "rapid development". It's far too constricting and "rulesy" for that, and far too low level in spirit (higher level than C++, but not by much, and if you knew C++ you'd grasp that fact (no, grossly inflating execution times with a JVM doesn't make it "high level"; that just makes it the worst of both worlds)). I've called it the Pascal of the nineties, and it is: They're both Church Lady Languages.
What Java also is, is the Cobol of the twenty-first century. It's used almost exclusively for in-house development at banks, the most degrading and shameful of all programming jobs. You're a Cobol programmer by another name. You're probably not even ashamed of it, but if you ever try to get a real job, you'll find you won't get a lot of calls back with all that Cob^H^H^HJava on your resume (assuming you have a resume yet...)
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.)
I think Yahoo should investigate and possibly bring Turing back from the grave.
If I could make pong with Turing, there's no telling what Yahoo could do with it.
Forget the useless PHP/HTML/ASP/PERL/CFM
TURING!!
Comment removed based on user account deletion