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)
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.
It'd be interesting to see Yahoo!'s stats - whether they get a performance/speed/efficiency boost from PHP, how it compares to the old system, etc.
:-D
As a PHP coder, this makes my heart fill with joy... should be much easier to convince PHB's to let me do it in PHP!!!
Besides, I hate the greedy matches when doing regexps in perl, and I know most people coming from a C/C++ background will have the same dislike.
Eep, why J2EE? It's slow, it's a memory hog, it doesn't deliver on the write-once-run-anywhere promise of Java because of the vendors' differences. Perhaps most importantly for them, you really can't use Java w/o threads, and thread support on FreeBSD is not great. Read that over again. That means that Java doesn't scale well for you if your OS's thread don't scale well for you. If you're running FreeBSD, then that's the case, which further limits Java's absymal performance.
11*43+456^2
isn't going to give any type of boost over a proprietary C/C++ app
It wasn't a proprietary C/C++ app, it was a proprietary C/C++ scripting language.
Performace should be same or better, if I understand correctly.
S
Happy days.
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.
Why should Perl be "more secure"?
PHP's biggest security problem is it's users. PHP is a powerful and easy to learn and use tool, which means it attracts a lot of new users. And the more new users you have, the more new user mistakes are made.
PHP has made a grep step forward in disabling register_globals by default. Unfortunately, a lot of legacy code isn't built for this.
I 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?
that's what the non-greedy regexp modifier was made for. read the fucking manual.
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, I dont work for Yahoo! (and I'll assume that you don't either, otherwise you would have mentioned that) but it sounds to me like they would like to use something more organized than the scripting engine they've been writing for the past 7 years. What they have may appear to work just fine to the end user, but inside the vast codebase of Yahoo! there could be really serious problems.
Think about it. After that long that thing's gotta be looking pretty ugly. With PHP they would have a more sane development environment. Writing your own C/C++ (interperet that as C AND C++, it is possible) scripting engine for CGI is just really sloppy most of the time.
I could understand your concern if they were moving to something corporate like ASP. I would assume that Microsoft cut them a deal or something. But when someone like Yahoo! chooses PHP to develop in, you know theyre doing it for all the right reasons.
Attention deficit disorder is a complicated issue, spanning several major... HEY LET'S GO RIDE BIKES!
More secure?
See, this is where I cannot help but assume that you are inexperienced. If you think a language can make your applications more secure, then you have a fundamental misunderstanding about developing Web applications.
As for maintaining large applications, I can tell you that with proper software architecture employed, PHP is going to be plenty easy to maintain. When you look at the big picture, you need an application that new employees can contribute to after the shortest amount of training possible. Can you honestly tell me that Perl has an advantage here?
The concept of Industry Standard isn't defined by "running on all platforms".
It means the software has a near monopoly on web development. It's popular, but so are CGIs, Cold Fusion, Flash, VB Script, Java Script, and of course JSPs.
What irks me is that people haven't abandoned HTML for all but display. HTML was designed to be stateless; info wasn't remembered as the browser jumped from one page to the next. To overcome this, all sorts of gross, kludgy, slow and complicated technology has been created (including JSPs, PHP, etc, etc) to overcome the inherent statelessness of the web.
The most interesting technology I've seen (and one that I hope will put these lame ducks out of their misery) is Curl, a programming language that runs in a plug-in (yes, sort of like Java, but more advanced, with fewer of the drawbacks). It was started at MIT via a US DARPA-funded project, and includes Timothy Berners-Lee, the creator of the World Wide Web and Director of the W3C, as one of the founders.
I can't wait for the Internet to go back to what it's good at - serving up pictures of pretty, naked women.
No, I don't work for CURL, or even for a company that uses the technology. I just think it's a better mousetrap.
UGH
PHP-Nuke, PostNuke and all variants are an exceedingly AWFUL way to share info -- click here, click there, stupid avatars, no threading, no straightforward text interface, searching rarely works properly, themes, ads, smileys, animations and more crap than you can shake a stick at.
Give me newsgroups or a mailing list. But please no PHPNuke or derivatives.
TMTOWTDI (from my experience with PERL) is definitely a drawback for large scale projects, and the presentation mentioned that there are 600+ engineers there.
I would imagine the Yahoo engineers spend much more time reading other peoples' code than writing new code, and that (IMO) is where PERL is worst. Complicated tasks can lead to some truly horrendous looking code and very non-standard code organization. While it is fun to write and powerful, it can be awful to figure out what some other developer is trying to accomplish unless they are very disciplined.
I once inherited a 1000+ line script at a previous company for analyzing IIS logs, and it was pretty difficult to get up to speed compared with comparable tools I've worked on written in Java, C/C++, or VB.
(That said, I like PERL and use it whenever appropriate.)
A: None. The Universe spins the bulb, and the Zen master merely stays out of the way.
I agree, I just thought I'd point out that this doesn't change the fact that perl is HELL to maintain for larger projects :)
Bullshit, or at least bullshit that Perl makes it harder to maintain than any other language.
Code properly, document correctly and adhere to the same design rules for any other maintainable project (which includes firing the assholes who think that obfuscated perl has a place in a maintainable project) and you will have no more difficulty in maintaining a Perl project than you will any other.
The fact that perl lets you create a mess may be open to debate, but it certainly doesn't mean it will be a mess.
Standard Java stereotype. Java was slow a long time ago, not today. That gross asumption alone should get you modded down.
Standard Java propoganda. The Java language is plenty fast (relative to the other solutions discussed), but most of the I/O libraries are still hideously slow. Ignoring that completely should get you modded down.
Even a fairly slow computational language like Python drops Java out of the running for typical high-volume web site usage, simply because of I/O problems. Java is quite suitable in low-volume settings with stiff transactional requirements or heavy computational requirements--any setting where high I/O costs are amortized by several-order-of-magnitude higher page generation costs. It's a bad choice for a very high-volume site which basically wants to paste several database sources together into a template and shove it out the pipe; Yahoo! falls pretty squarely into that camp for most of its pages.
They also have many components written in various domain-appropriate languages or that they don't want to rewrite for whatever reason; JNI is still pretty heavyweight, and if you have a lot of language interop requirements Java isn't a great choice (though if you're willing to sacrifice some JVM portability this can often be worked around, especially if the other benefits of Java outweigh the cost of implementation).
On top of that, using EJB/J2EE will kill performance even more, which means that actually getting the feature benefits of Java requires handing away even more performance.
All that's without even addressing the "requires tons of threads" problem; multiplexed I/O is pretty new to Java, and there's no good multiprocess API. Both of those are major problems, though hopefully multiplexed I/O will mature quickly. But until there's a good multiprocess API, Java's going to be unsuitable for a number of applications (and sticking to a platform-independent mentality instead of a platform-agnostic mentality makes implementing an efficient multiprocess API very difficult indeed).
Worst of all are the memory issues, but those are well-known enough not to be worth rehashing.
Sumner
rage, rage against the dying of the light
You care to back up any of the claims your making? I have seen J2EE in production environments deployed with great success. There is nothing inherently slow about J2EE in general. "Java's abysmal performance"? In what context is Java's performance abysmal. I won't contest that for a number of tasks it is not optimal, for server application programming tasks it really shines.
I just don't buy outright arguments like that at face value. It is *NOT* well understood or believed that what you state is true among any large groups of professional developers with proven experience deploying J2EE apps. Proof please.
Trust me, I love PHP. I wrote a book on PHP and think it can do great things.. but for enterprise level applications and for quite a few tasks it just isn't there.
Jeremy
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.
That's not totally true. Don't get me wrong, I love Perl, I use it almost every day for all sorts of things.
I do have first hand experience with non-trivial Perl projects though and I can say they are much more difficult to maintain. Everyone who writes Perl seems to have their own style which makes the code very difficult to follow. Even with very good coding guidlines there are just so many normal things you do in Perl that make the code hard to follow.
I use and like both PHP and Perl though. I probably write more Perl than PHP.
Well, the fact that Yahoo is switching backends really is not of interest to most of the media. Looking at their other press releases, most of them are about either new services they are launching or about financial information. As far as most financial reporters go, they couldn't care less what backend it has as long as it keeps running. To the best of my knowelege this story is true, and it is backed up by the presentation made to the PHP Con 2002. Cheers, Erek Dyskant
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
BS. Have you even used PHP for database access? Perl's DBI library, which BTW isn't even built-in to Perl unlike PHP's DB functions (which accounts for PHP's speed over Perl), is a convoluted nightmare. PHP's functions are extremely straightforward, easy to create classes for and faster.
If you really don't want to use DB specific functions (which are way faster), then use the ODBC functions.
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.
Amen, I've had a professor who would churn out C code for the example projects that would curl your hair, and refused to even consider Perl as a programming language because he thought it was an awful mess.
Perl lets you make messy code, and relies on the programmer to actually be responsible in churning out something that anyone who knows the language can pick up and read. Sure, making one liners on the fly to get something done is a neat ability, but IMHO, a good programmer will ADD the extra few lines of code for the sake of readability when readability is an issue.
4500+ FreeBSD servers doesn't seem like an irrelevant reason to me.
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"...
Dude, this isn't some little backwater ecommerce site, this is the most hit site in the world. I think it's safe to say they considered the performance. (BTW check slides 30-34 of the link for that exact info)
-Ted
-=-=- Quantum physics - the dreams stuff are made of.
3. One of the requirements was a language that didn't require a CS degree to use. TMTOWDI helps that, I've noticed.
I have to disagree strongly here. TMTOWTDI generally means that two implementations of the same design are different enough that someone without a lot of experience probably wouldn't be able to tell that they were the same thing.
Having standard ways to do things makes it a lot easier to understand what's going on and makes it a lot eaiser to do things. Even in perl, people try to find a common way to do things, and it often ends up being regular expressions, even where there are far easier solutions.
-- The world is watching America, and America is watching TV.
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.
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 just wanted to comment on the write-once-run-anywhere thing. I develop code on Linux and Windows with Tomcat and JBoss, the code is deployed in production on Solaris and Tru64 with Weblogic (in addition to the former), and I don't have to change a line of code to go between them - that's good enough for me.
Anyway, if you claim Java's performance is abysmal (in any area except 3D graphics) you just haven't looked at the damn thing in a few years.
sic transit gloria mundi
Let's see, web development is a) parsing strings, and b) concatenating them.
... have you heard of databases?
I write J2EE web apps for a living, and I can't remember the last time I bothered with parsing/concatenating strings. You must not do any interesting or challenging development.
The only thing Java's got that Perl ain't got is OOP features.
The ONLY thing? That's like saying that the only thing Mt. Everest has on your local anthill it height...
All you seem to care about is text processing
Whatever it is you do viz web app development you're overpaid.
That's an impressive amount of ignorance to display in a single post! No wonder you posted AC...
1. Web development is just "parsing and concatenating strings" ??? Interesting... And here I was thinking that it also involved database lookups, pulling streaming data off of message queues, querying external sources for status and information and data validation, among others.. Why didn't you just say that software development is just typing on a keyboard?
2. Regular expressions are "built-in" to Java now -- ever since the 1.4 release (which has been out for a while now)...
3. If your user thought that your server had hung while processing your Java code, I'd say it was because you wrote REALLY LOUSY code. Unless you're using Swing, there's nothing wrong with Java's speed.
4. You HATE Perl and you hate Java even more ??? Seems like ample proof that you have no idea what you're talking about, and are just _pretending_ to be a programmer. You're clueless, and most likely couldn't code your way out of a paper bag. Java and Perl are tools -- there's no reason to hate either one. Both have their place and excel at different things. Obviously, you're one of those "I only have a hammer" kind of people, and you simply don't know how to use more than 1 type of tool (and as you mentioned above, you _surely_ aren't a competent Java/JSP developer).
5. Java is a "lame but rational" language? Just more proof that you don't have a clue. Java is very well designed; it isn't perfect and needs improvement in certain areas, it is still very nicely done.
6. 4500 PCs have a lower TCO than mainframes? Where exactly is your proof? And what qualifies big iron as an automatic "dinosaur" ??? They are simply another type of tool that can be used. They have their places where they make far more sense than a bunch of PCs stuffed into a rack, and they also have places where they aren't the best idea. But for some reason, you seem to be stuck on this "there's only one right way to do _anything_ trip"....
As I said, you've managed to pack an impressive amount of ignorance in just one post.... Next time, put your name alongside your drivel.
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.
- 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
It's also pretty annoying when you don't read the manual - and this one is NOT obscure to find. Section 8 - "Variables"
OK. I thought I looked at that page. I guess I only looked at the one about superglobal arrays, though. But you don't have to be a jerk about it. And it still doesn't explain why that is done, aside from saying that you need the slashes when doing database queries. Most of the time you're not doing database queries. It seems rather arbitrary to add slashes to user-inputted strings but nothing else. Why not add slashes when you read a line from a file, too? And I realise that you can turn this behavior off in the configuration, but then your scripts won't be portable, since it is the default behavior.
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
What's that got to do with re-parsing pages? Python can use variable variable names, and it always compiles included files.
Or just get a host that will use one of the many caching products available (zend, ioncube, etc)
If PHP itself was little more clever about caching compiled scripts, I wouldn't need to do that. Although I agree that this isn't really a problem in that you can't do it as much as because you have to do extra work.
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.
That's almost exactly what I do, but as I said, it seems like a hack. There should be a way to include files relative to the current file.
Anyway, whether you think these are really problems or not, they are annoyances for me (along with other issues such as no real pass by reference), and they didn't need to be there.
Duct tape, XML, democracy: Not doing the job? Use more.
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