Slashdot Log In
Yahoo Moving to PHP
Posted by
michael
on Tue Oct 29, 2002 04:57 PM
from the herding-cats dept.
from the herding-cats dept.
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."
This discussion has been archived.
No new comments can be posted.
The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
Dangers (Score:5, Funny)
It makes sense ... (Score:5, Insightful)
Obviously open source DOES apply to the corperate world.
Re:It makes sense ... (Score:5, Insightful)
If you say that open source has a place in corporate webservers, I'd say that's a massive understatement.
Open Source (Apache and PHP) is the standard in the webserver space already and is gaining more marketshare every year.
Right now, only NBM (nothing but Microsoft) users and legacy systems run IIS. It doesn't offer anything valuable, except customer lock-in. (which is very valuable, but only for Microsoft)
Parent
Re:It makes sense ... (Score:5, Informative)
There's no way you can back that statement up. Corporations generally have a few outward-facing web servers, and yes, these are most likely running apache, but the vast majority of Intranet web servers are still IIS. After that you'll see Lotus Domino and iPlanet, and then Apache.
(This is from my experience with large corporations, though the IT rags such as Information Week and Network Computing back me up.)
IIS is the standard for Intranet web servers for a reason - it's standard. It comes with every NT server. It's easy, and setup/administration hasn't changed in years. Any clown with knowledge of Windows can make it work, and it is stable and reliable.
In the last 7.5 years I have administered just about every popular web server written (including NCSA HTTPd, WebStar, and IIS on NT 3.51 back in the day). Of all of them, I've found IIS the easiest to work with. Coupled with Win2k workstation on the desktop, it's almost fun to administer them with MMC and watch their behavior with PerfMon.
The reason I deploy mainly IIS servers is that I can order a server from the IT department with a standard Win2k build and have secure applications (with access control) running on it within minutes of taking delivery of the box. Try that with a Solaris, Irix, or Linux box, I dare you. (Yes, I currently deploy and manage Apache on Solaris, Irix, and Linux, just not as often as IIS on NT/Win2k.)
Sure Open Source has a place in corporate webservers. That place just isn't big, and won't be until Apache is easy to configure and integrates seamlessly with Windows NT security. When an idiot with an IT degree from the local community college can integrate Apache on Unix with a corporate network and can authenticate users and implement access controls without opening a book, then Open Source will have arrived in the corporation, and will start to eat into IIS market share of the Intranet. Until then, it'll be fringe, relegated to use on big systems with unix sysadmins doing the implementation.
Parent
Maintence must be easier (Score:5, Insightful)
Re:Maintence must be easier (Score:5, Interesting)
I guess everyone is smoking crack except you. Seriously, why does MySQL get all this smack talk? I use it because its easy, every language I know of has bindings for it, its fast enough, and its stable. PLEASE spare me your "But XXX does that too, not to mention bla bla bla!" No, I won't switch, because I learned MySQL first (as I'm sure many others have) and so far it hasn't let me down.
Parent
Re:Maintence must be easier (Score:5, Informative)
MySQL is faster in really only one particular case: lots of SELECTs with few UPDATE/INSERT/DELETEs. Many applications have orders of magnitude more SELECTs than other queries (I'd guesstimate that Slashdot books at least two orders of magnitude more SELECTs). Nothing beats MySQL in that environment, and there are a lot of apps where that's all that's needed (think CMS's and other such things).
Parent
Speed (Score:5, Informative)
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."
Parent
Seems like a silly move... (Score:4, Interesting)
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??
Re:Seems like a silly move... (Score:5, Insightful)
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.
Parent
Re:Seems like a silly move... (Score:4, Insightful)
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
Parent
Re:Seems like a silly move... (Score:4, Interesting)
I had to make this decision myself. I would like to share some of the reasons I chose J2EE over PHP.
J2EE is a specifaction that is implemented by Java. PHP is a scripting language that runs on web servers. One of the problems I came up against was writing PHP was fast but as soon as the application left the modules that where included by PHP you would have to write them in C/C++ and compile them into PHP. This was NOT maintable and C/C++ are not RAD (Rapid Application Development). Basically PHP is limited to the running inside of Apache which for a small site is not much of a limitation but all of the website I have worked this was a huge limitation. For example there is no way to schedule a PHP script to run without outside software. Java is a langauge that provides a lot of different ways to schedule events.
PHP has a couple major database interface problems that Java does not. One the database abstraction exist only by extention such as PEAR. Persitant connections create a connection for every Webserver process. So if I have n number of connections to the webserver I have n number of database connections. Since the query took a lot less time then it does to send the web page back to the client. For a small site this is no problem because there are very few connections at a time. But when you start dealing with multiple servers and large numbers of user connecting at the same time the database server soon cannot support he number of connections required. If you set connection pooling off this works OK for MySQL because it uses threads (this I don't get MySQL threads are ok but Java ones are not?) but Ohh.. my if one was to every use a database design for large systems such as PostgreSQL you would be creating heavy processes for every connection and again this would not scale. J2EE application servers use connection pooling
PHP caching I have used very little of. I used the PEAR caching system and it works OK. The J2EE caching that I have used is the Jboss implementation. The J2EE caching is so much more finegrained than the PHP caching that it is almost like comparing applies to oranges. But J2EE has a concept of row level caching vs. PHP which has a concept of query level caching. My experience is that J2EE caching is faster and much more intelegent.
PHP supports objects
Generally I have found that large application evolve into supporting things I could have never imaged when I start working on it. If I where a C programmer then PHP might make sence because I could extend it to support all the features. But I don't have the time or knowlegde to become a really good C programmer so I use J2EE (Jboss).
Parent
Re:Seems like a silly move... (Score:4, Insightful)
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
Parent
Re:Seems like a silly move... (Score:5, Informative)
Because Yahoo is one of the fastest sites on the 'net.
EJB's are great, don't get me wrong. They are great for handling database abstractions with zero tolerance for errors. But they are not fast, and horrible overkill for a site like Yahoo. All that abstraction and IIOP communication kills performance. Which is why shops that have large EJB applications tend to run them on heavy duty sun hardware. Not i386 boxes running FreeBSD.
Parent
Re:Seems like a silly move... (Score:5, Interesting)
I mean seriously, I'd love to hear the pros and cons of the "Moving our stuff off of FreeBSD" vs. "Having to maintain everything in PHP instead of J2EE" discussion.
Parent
Re:Seems like a silly move... (Score:4, Informative)
Parent
Re:Seems like a silly move... (Score:5, Insightful)
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
Parent
Re:Seems like a silly move... (Score:5, Interesting)
I'd argue that if you use 2.0 EJBs and JBuilder, I could code just as fast as any regular language, but scripting languages are easier to slap code into.
Now, good scripted PHP vs good abstracted OO Java. To code from scratch, PHP'ers could lay down code quicker. Java is easier to maintain and easier to add onto (if properly architected). In the end, I'd call it even ground.
slow at executing
Java 1 was slow. That was like 5 years ago. Go download JBuilder and run it. Made in C++, right? BUZZT! Its Java. Java has come a long way.
J2EE is beautiful in theory, but not in practice
Well, my job is a J2EE developer, so I guess the complex, enterprise level application that is running currently in front of me isn't java, cause it isn't beautiful in practice.
Anyone with that only on their resume will have to shape up the next years, when PHB's stop buying that particular buzzword and move on to the next.
Go look at monster. J2EE is one of the few languages that people have been hiring in throughout the recession. That doesn't sound like something PHB's are gonna just stop hiring.
Parent
An important performance note... (Score:5, Informative)
Dangers of PHP? I think not! (Score:5, Informative)
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.
Re:Dangers of PHP? I think not! (Score:5, Insightful)
PHP has made a grep step forward in disabling register_globals by default. Unfortunately, a lot of legacy code isn't built for this.
Parent
One Yahoo user's perspective (Score:5, Funny)
And, if I do happen to lose the lead in my fantasy hockey league, I now have something to blame it on.
makes sense... (Score:5, Informative)
fascinating (Score:5, Interesting)
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.
Re:fascinating (Score:4, Insightful)
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.
Parent
Why is PHP so bad? (Score:5, Insightful)
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?
Re:Why is PHP so bad? (Score:4, Interesting)
Praise the Lord and pass the pretty-printer! I'm not a PHP fan, but I don't think any of us can make a strong argument against it, except that it's not a general-purpose language, and thus falls into the same geek category as Cold Fusion, Office macros, and, well, ASP. There's a very strong bias against using tools crafted for the job when the job is defined as a presentation method.
If you like, blame the tacit geek belief that any language they learn should allow inline assembler, have CORBA bindings, multithread, and let you hack a serial port monitor to control intelligent coffeemakers.
Parent
Re:Why is PHP so bad? (Score:4, Informative)
Here are a list of reasons why PHP may be suboptimal for web publishing.
1. Lack of seperation between content and logic. Embedded logic code inside presentation can lead to a bewildering jungle of death for anyone who tries to maintain the code. Also, repeated logic must be maintained across all pages, instead of changing it in one place. (this goes for all ASP, PHP, perl type scripts)
2. Performance problems with interpreted languages
3. Can't take advantage of OO goodness. php is a flat procedural-like language, you can't do the robust object modeling, or any of the other spiffy OO things you can do with c++, java, (maybe
4. HTML lock in. Your code will forever live in HTML, if you want a different display format (unlikely) you're stuck. ie. what if you want to have a propriatary client instead of html on your plam, you have to rewrite all the logic.
5. Fancy features availible in Java (maybe
Don't get me wrong, i think PHP is great for certain types of applications, but for large sites like yahoo, I think they'd be better off choosing something else (they wont use java because they claim FreeBSD has threading problems)
These are mostly addressed in the linked Y! eng slides. I'd be interested in hearing others opinion on this topic.
Parent
Alot of this is pure crap (Score:4, Informative)
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.
Parent
Re:Why is PHP so bad? (Score:4, Interesting)
Why?
Because like Mr. Radwin says(the author of this presentation), PHP is simple to use. It has quite a bit of error protection and it deals with sloppy code. The elite programmers amoung us hate this - they see people whom have not spent the last 12 years of their life learning a language but producing the same (or similar) results. PHP itself is great, and the fact that a corporation like Yahoo! has decided to use it over all the other alternatives just re-enforces that.
Parent
Why I'm excited about this. (Score:5, Insightful)
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.
Lack of understand of how PHP works? (Score:5, Informative)
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).
There are many good reasons. (Score:5, Informative)
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.
Re:There are many good reasons. (Score:5, Funny)
Parent
Next Obvious Question... (Score:5, Funny)
They passed on Java because FreeBSD is crappy? (Score:5, Insightful)
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! [ibm.com]), 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"...
Big Mistake (Score:5, Funny)
Yahoo SHOULD be using Perl, not PHP. (Score:5, Insightful)
- 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...)
Re:Perl was ruled out WHY??? (Score:5, Informative)
You haven't read the article. There's a whole page for "Why not Perl?"
Parent
Re:Perl was ruled out WHY??? (Score:5, Informative)
Cons
- There's More Than One Way To Do It
- poor sandboxing, easy to screw up server
- wasn't designed as web scripting language
Parent
Re:Perl was ruled out WHY??? (Score:5, Insightful)
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.
Parent
Re:hmm... (Score:4, Funny)
Parent
Re:MySQL? (Score:4, Interesting)
You got a problem with that?
Parent
Re:Oh my god! (Score:5, Informative)
I didn't expect the spanish inquisition. Really, though. PHP is like PERL made for the web, it has easier access to databases than any other language I know of (which are only a few granted but Perl and C are among them).
I would say more but Language choice tends to get religious. Everyone thinks theirs is superior and few will just yield to my choices
Parent
Re:Oh my god! (Score:4, Informative)
#!/usr/bin/php works just like the Perl alternative.
Parent
Re:Oh my god! (Score:5, Insightful)
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
Parent
Re:Oh no! (Score:5, Funny)
engineer:this is a rare opportunity phb: hmm?....
engineer: PHP is not yet a buzz word...we can set the market, indicators would rise, indexes improve, shareholder confidence would surge!
phb: WOW! I want PHP!
Jr. Engineer: What did all that stuff you said mean?
(clever)engineer: With Y having nearly 11M lines of code to rewrite in a new language....it means job security (and we still don't have to wear a suit)
Parent
Re:PHP is *the* industry standard (Score:4, Insightful)
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 [curl.com], 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.
Parent
Big Whoop. (Score:5, Informative)
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.
Parent
These aren't really problems. (Score:5, Informative)
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 [tapinternet.com] have never complained about the issues you brought up as 'problems'.
Cheers
Parent