Yahoo Moving to PHP 779
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.
Yahoo Moving to PHP
Related Links Top of the: day, week, month.
You know you've landed gear-up when it takes full power to taxi.
Oh my god! (Score:3, Funny)
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
Re:Oh my god! (Score:3, Interesting)
PHP is like PERL made for the web, it has easier access to databases than any other language I know of
I disagree; Perl's DBI interface is *far* simpler (and the functions are not DB-specific) like PHP's. (I think PHP solved that in the not too distant past though)
Re:Oh my god! (Score:4, Informative)
#!/usr/bin/php works just like the Perl alternative.
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
Re:Oh my god! (Score:3, Interesting)
Actually, I learn what I am paid to learn. My employer never cared about cold fusion so I never learned it. I know often people comment about everything, but I stick to what I know and what I know is the languages which can easily gain me employment.
hmm... (Score:2, Funny)
Re:hmm... (Score:4, Funny)
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)
Re:It makes sense ... (Score:3, Insightful)
Apache yes, in its varied forms. But PHP is far from the standard. It may be the standard for hobbyist sites, but most commercial sites run on ASP,Perl,JSP+Servlets, or something proprietry like Vignette. Althogh PHP can be made secure by a good admin, it's often (usually?) not.
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.
Re:You forgot about Java... (Score:4, Interesting)
Some of the larger projects I have worked on , where integration is important and a key to the success of the product, JAVA seems to be the best bet.
Not to say that things couldn't be done in PHP, probably can... but I have had a lot of luck in writing all my business logic and middleware in JAVA and then using JSP or Servlets + Velocity for presentation. The thing is, it's not something that someone can do without a middleware engineer and a implimentation engineer.
I have been coding java middleware code ware for almost 3 years now, some of it integrates into web based services, some of it ties into legacy workflow systems and even tied into a IBM mainframe, I just can't IMAGINE doing all of that in PHP... I would of been laughed out the door of my company as a matter of fact with a pink slip in my hand.
The strength of being able to pull in other 3rd party libraries for various tasks that come up, JAVA is first rate.
I worked for a company that had a pretty complex logistics based system that integrated with a German logistics ocmpany.. was ALL done in PHP.. I couldn't believe it when I saw it to be honest, but to say the least... was VERY dificult to manage the application as it grew to many hundreds of classes and pages. The company ended moving to an EJB/JSP solution on websphere I think, and eventually was able to cut out about 1/2 of their engineers because the API became quite manageable by fewer people.
You can't call JAVA hype any more than you can call COBOL, FORTRAN c/C++ hype, because the level of profound impact JAVA is having on the industry at the moment is to those levels IMHO.
NOW.. if the project doesn't really reach beyond basic web applications, yes, even very large companies have such projects.. I see nothing wrong with PHP. It's actually a breath of fresh air when I need to hack something out quick and simple. I use HORDE+IMP for my own personal email and the email server for my wife on my linux box.
Maintence must be easier (Score:5, Insightful)
Re:Maintence must be easier (Score:3, Interesting)
to trigger happy mods - again, not a troll, I'm curious.
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.
Re:Maintence must be easier (Score:3, Interesting)
I'm simply curious - for most jobs that MySQL is used for, there are better free databases (sometimes not by much, but that's not the point), yet MySQL seems to be the only free RDBMS anyone's ever heard of. I am trying to picture why, and asking people involved (it seems like) with the decision process in a company actually using it, seems like a good way to find out, no?
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).
Re:Maintence must be easier (Score:3, Informative)
Yep, that's pretty much it. If PostgreSQL didn't have the 8k row limit and the need for periodic 'vacuums' at the time when the web was starting to boom, it would have been the db of choice. Those problems are fixed now but it doesn't matter. It supported transactions, views, sub-selects, and most other SQL features years before MySQL did. The fact that PostgreSQL is now a better database in nearly all respects (including speed) doesn't matter because MySQL is entrenched.
Re:Maintence must be easier (Score:3, Interesting)
Re:Maintence must be easier (Score:3, Interesting)
I am a huge PostgreSQL fan myself, but for mostly-read databases (like most web databases) MySQL is hard to beat.
Re:Maintence must be easier (Score:3, Informative)
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."
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:3, Insightful)
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!!!
Re:Seems like a silly move... (Score:3, Interesting)
PHP, even with mod_php, isn't going to give any type of boost over a proprietary C/C++ app other than maintainability. The reason I butted in suggesting J2EE was the easy clustering, database pooling, and data caching that goes above and beyond what mod_php can do.
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
Re:Seems like a silly move... (Score:4, Informative)
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.
Re:Seems like a silly move... (Score:3, Interesting)
So instead of fixing FreeBSD's threading, you advocate not using threads?
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
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).
Re:Seems like a silly move... (Score:4, Informative)
All the slow EJB installs I have seen have the following problems:
Use of remote classes where local ones would make sense. Use a session bean to aggrigate the results of a few beans and send out the result you need.
Bad database design or just poor JAVA programming.
I have studied EJB extensivly , and can usually get near database-query speed if I think hard enough about what I need. I have read that remote objects should only access session beans, and this is a pretty good idea for the most part.. Your calls should be fewer and pull down the data it needs rather than make LOTS and LOTS of calls...
Anyway, it's a pretty elegent solution and really forces you to think about design. Solutions such as Caucho's Resin CMP makes it even easier to use an EJB solution for object-relational managment and , with resin imparticuarly is easier than using a roll-your-own JDBC based code.
Re:Seems like a silly move... (Score:4, Informative)
Nonsense. J2EE's threaded model is far more effecient than Apache/PHP's process per connection model because of the memory sharing. In terms of speed, App servers like Resin
http://www.caucho.com/articles/benchmark.xtp
do just fine against PHP in terms of speed.
it doesn't deliver on the write-once-run-anywhere promise of Java because of the vendors' difference
True a few years ago before Sun started validating app servers. Now not so true. The ServerSide.com runs on a cluster of machines where each machine runs the same code base on a different vendor's app server.
What I want to know is how come no PHP advocate mentions scalability? How do you pool arbitrary objects, or cache static data in PHP? How do you distribute sessions in PHP????? What happens when you want to cluster that PHP site??
Re:Seems like a silly move... (Score:3, Insightful)
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.
Re:Seems like a silly move... (Score:4, Funny)
1) I see Java-lovers have knocked me down -2 overrated so it's back down to 3. Way to squelch opposing opinion there.
2) To ALL the repliers here: I know exactly what I'm talking about. I have coded expertly and will continue to do so in everything from x86 asm to C to C++ to Java to Perl to
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
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.
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.
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.
Re:Seems like a silly move... (Score:3, Informative)
Re:Seems like a silly move... (Score:3, Interesting)
Like solaris x86 perhaps!
java is primarily designed for solaris,after all.
gezlawez (Score:3, Funny)
Jeez (Score:3, Insightful)
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.
Re:Dangers of PHP? I think not! (Score:3, Insightful)
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?
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)
Time to buy SUN stocks ... (Score:3, Funny)
Re:Time to buy SUN stocks ... (Score:3, Interesting)
In fact one of the reasons they didn't use Java instead of PHP is that Java on FreeBSD isn't up to par.
So it's time to invest in Walnut Creek... no wait it's BSDI... no wait it's WindRiver... oh damn it! I give up.
*BSD is dying...
Hot dog! (Score:3, Insightful)
Happy days.
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:3, Insightful)
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.)
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.
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.
one language fits all? Don't think so (Score:3, Insightful)
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.
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.
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.
Re:Alot of this is pure crap (Score:3)
Yes.
"If I understand you posts correctly you are suggesting that PHP OO can hold a stick to Java."
Are you sure you are replying to the same post? I said no such thing.
" If this is the case I wonder how much Java web development have you done?"
TONS.
"Have you used any of these Velocity,Jython, Taglibs, or EJB?"
Some.
"How many 100K objects do you pass around in you PHP applications? "
None.
"Passing by reference?"
Sometimes if I feel the need for it.
"Last time I tried PHP with lots of object I kept getting out of memory errors."
Perhaps you don't know php well enough.
"Well I guess I should have thought to myself it make complete sense that PHP would pass be value instead of by refrence."
Whether it makes sense to you or not is irrelevant. It's a published specification of the language and many things have been written about it. Some languages use copy on assign and some use references it's up to you to read the documentation and learn the language so that you can use it properly. PHP is not java and only an idiot would expect it to behave exactly like java.
"And I should use a _work_around_ to fix it."
No just learn the language you are trying to use.
"And I should build my own intelegent object caching. "
Or use a library written by someone else. Which language support automatic object caching natively? In java you have to rely on HUGE frameworks with extremely complicated setup and configuration to achieve such a thing. Did you write velocity? did you write your own EJB container? Java does not have built in object pools either.
"Oh one more thing how do you get connection pools form PHP or does every Apache proccess have to create a database connections?"
PHP frees me from having to think about database pooling because it takes care of all the dirty work for me. I simply write code as if my database connection was the only one was being opened fresh every time (even though it's being pulled from the pool). All database function in php have a "pconnect" function which goes into the php pool for the database connection. All I have to do is to set an ini entry specifying how many connections I want to maintain. I also use ADODB database abstraction layer which makes my code very easy to port to other databases. Add to this the ability to stream just about any object to string and cache them locally I can skip many trips to the database altogether. I frequently generate comboboxes and grids which are database generated (but not frequently changed) and cache them on the local drive which saves a round trip to the database server.
Coding data driven web sites in PHP is a downright joy compared to the insane headaches one has to go through to do the same thing in EJBs or even velocity. If I really want to use something like taglibs I can use the Krysalis framework which is a velocity look alike. If taglibs are not up my alley I can use smarty templates. If don't want either one I can use an application framework such as binarycloud. I have more choices then a java web developer.
PHP is also much faster then any solution coded with EJB. In fact any solution coded with EJBs is significantly slower then just about any other technology. If you don't believe me go visit theserverside.com and read some the their benchmarks. Java is also a downright annoying language if you ask me. Any language with forces me implement an interface just to define a filemask is too stupid to use.
Re:Alot of this is pure crap (Score:3)
Intterfaces are not the same thing as multiple inheritance. In multiple inheritance you write the methods and the inheriting class has access to them. In interfaces you promise the methods but don't implement them leaving that job to the inheriting class. C++ and some of the more "pure" object oriented languages like smalltalk support multiple inheritance but it is generally considered a dangerous thing. Java does not support it, the
"And encapsulation as an OO term is data hiding."
Are you refering to the fact that PHP does not have private variables? IF so this is a minor thing IMHO. The variables have a "private enough" scope to avoid any namespace problems and you don't have to access them if you don't want to. I simply write my php objects as if the variables were all private and use my object by calling getters and setters just like java.
Personally I much prefer the php objects to java objects because I can change objects at runtime. PHP shares this dynamism with languages like objective-c and ruby. Until you experience it I can't really explain it to you but it's really cool.
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.
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.
You won't see www.yahoo.com/index.php anytime soon (Score:3, Informative)
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.
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).
look at sourceforge (Score:3, Interesting)
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 [liquidmarkets.com].
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.
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:3, Funny)
-your boss-
Re:There are many good reasons. (Score:5, Funny)
Next Obvious Question... (Score:5, Funny)
... I disagree with a few points (Score:3, Insightful)
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.
Is yahoo still profitable? (Score:3, Insightful)
Re:Is yahoo still profitable? (Score:3, Funny)
#1: make search engine
#2: make portal in cgi
#3: profit
#4: make portal in php
#5: more profit
yes it is still profitable if you follow this businessplan
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"...
Java is not suitable for Web stuff (Score:3, Interesting)
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.
Big Mistake (Score:5, Funny)
Very interesting news (Score:4, Insightful)
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.
PDF version of slides available (Score:4, Informative)
Maybe so (Score:3, Informative)
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?"
Re:Perl was ruled out WHY??? (Score:2)
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 :)
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.
Re:Perl was ruled out WHY??? (Score:3, Interesting)
Undisputed. But there are languages that go out of their way to make it easier and perl doesn't. Not a criticizm of perl necessarily, just another point in the decision making process.
I personally love perl - I use it every day and it's usually one of the first technology choices for new projects. But coding in a team environment is often still a very hard thing (not every one out there is that great at doing the wonderful things you listed, and firing people left and right is often not an option), and I'll take all the help I can get there.
Re:Perl was ruled out WHY??? (Score:3, Insightful)
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.
Re:Perl was ruled out WHY??? (Score:3, Informative)
Here are some key things which make Python much easier to maintain than Perl:
And here's a killer:
Re:Perl was ruled out WHY??? (Score:3, Insightful)
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.
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
Re:Perl was ruled out WHY??? (Score:3, Insightful)
Re:MySQL? (Score:4, Interesting)
You got a problem with that?
Re:MySQL? (Score:3, Funny)
Re:MySQL? (Score:3, Informative)
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)
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.
Re:Who's next... (Score:3, Insightful)
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.
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