a total idiot can install PHP and get a system that will meet the performance and reliability needs of 99.5 of web sites out there.
tomcat, mod_perl, the ten different ways people host Ruby sites and all that make a lot more trouble for you. I've run PHP-based web servers for hundreds of sites that have served billions and billions of hits over the years and never once had to restart Apache because an application server got lodged. read that again because if you skip it, you're sysadminning blub.
every other system requires that you make choices, and the truth about choices is that faced with a binary choice there are two common outcomes: (i) a person freezes up like a deer in the headlights or (ii) a person makes a random choice that they're 50% likely to get right. (i)'s probably the better option.
i can complain about things wrong with PHP forever and i've got plenty of reasons to get off the PHP train. however, if you want to kill PHP, it's not enough to attack what's wrong with PHP, you've got attack what's right with PHP... You've got to make a better PHP than PHP.
Coming from a PHP background, the first time I tried Django, I was rather dismayed at the amount of set up involved. I think after following a few tutorials, I was able to more or less get a running mod_WSGI setup, though the only way I could seem to get the web site to refresh was by restarting Apache.
After I got over the fear of using an http daemon written in the same language as my web app, I discovered Ruby / Sinatra, which gave me more or less the same immediacy I was used to from PHP.
Even so, I doubt I could explain Heroku to a non-technical friend in the same way I could convey an understanding of uploading a php web page to a LAMP host. (Ubuntu's broken support for RubyGems didn't do much to help my migration from PHP either).
It seems to me that until Python and Ruby have an infrastructure that's as friendly to novices as PHP is, we'll be seeing the same "PHP ghetto" effect that we've been seeing for the past decade.
This is like living in a house where the builders were "total idiots" and hammered in all the screws with a hammer instead of screwing them in with a screwdriver. Sure, it holds together. It might not even collapse in a light breeze.
But one day, you'll want to reshingle the roof, or there will be a thunderstorm, and then your house collapses, killing your entire family. Good engineering requires good implementation. PHP makes good implementations too hard.
every other system requires that you make choices, and the truth about choices is that faced with a binary choice there are two common outcomes: (i) a person freezes up like a deer in the headlights or (ii) a person makes a random choice that they're 50% likely to get right. (i)'s probably the better option.
Theoretically, this is why you hire people with experience. They picked randomly the first time, and then gathered data. Their random choice either worked or it didn't. Repeat a few times and you have "senior system administrator" and "senior engineer" instead of "random dumbass we found on the street corner", and then this part of the equation goes away.
Now, if your goal is to produce something that sometimes works with the least amount of money possible... yes, you should outsource your development and deployment to some high school kids in India. If your goal is to produce something that works...
(Also, the days of PHP's deployment superiority are nearly over. With mongrel2, I can restart my app instances without losing a single request!)
So I've been hearing since 2000 or so, when I chose RXML/Pike over PHP because PHP was a complete mess. PHP has gotten considerably better since then; now it's only painfully messy, rather than unusable. Sometimes it seems like every competitor has been busy building castles in the sky full of magic and wonder -- as long as you want to do exactly what the creators of your framework wanted to do, and as long as you're willing to stop by and maintain your app. PHP is more of a fire-and-forget language for apps... you can write it and then ignore the app for years without worrying about memory leaks or crashes or that it's taking up resources on your virtual server...
With mongrel2, I can restart my app instances without losing a single request!
Wow, what an achievement! This is the one thing that PHP really, seriously got right: no application server. There are applications out there that need the extra efficiency of not starting up on every request, but the vast majority of webapps do not. The additional robustness and sanity provided by not having to wonder why your app server fails after 292744 requests, or what went wrong when it just stopped responding, or whether, indeed, you might lose requests when restarting -- that helps me sleep at night. Few webapp-oriented languages have this, preferring instead to try over and over to get the application server paradigm right, this time, for sure! We just have to add a little shim here, and build another layer over these layers to interface with that one...
I think you mean PHP has no 'apparent'. It damn well does have an application server, it's called mod_php embedded in Apache processes or php-fcgi backends.
The thing is, that PHP apps DO fail after a certain number of requests, it's just hidden from you. Internally PHP ships with a MAX_REQUESTS (which defaults to 1000 I believe), after a backend has served that many requests the process is recycled (an expensive and non-ideal operation on high load applications).
If you do a look around on Google you'll find this behaviour ships with PHP because of 'known memory leaks'. Rather than fix memory leaks the authors have opted to restart on an arbitrary number of requests. Does this sound like good design to you?
You think there's no application server because you've likely never worked on anything substantial enough to notice the silly string holding the whole mess together.
I agree that what you could call it's deployment API (or whatnot), that it is very simple. I think the reason for it's success is it allowed HTML/CSS 'programmers' to progress to simple scripting within their existing deployment metaphor (upload via FTP, use a PHP file extension, wrap PHP in <?php tags).
However, there's no reason that you couldn't design a similar thing in say, Ruby or Python, where people upload files with a specific extention FTP and it runs some templating language (like ERB or Pythons equivalent). You'd need some web api to allow triggering reloads of files (or reloads on every request if the server is being used for development).
PHP out of the box re-parses _every single script on every single request_, which is what you'd expect a development environment to do, but 'in production' that's what PHP has always done.
Hence were born the optcode caches (which work rather well now), like APC. But still, on every request, every file that is required has a stat performed on it (you can turn this off, though).
It's all very lowest common denominator, and the high end stuff is severely lacking and poorly documented. It's possible to have the best of both worlds (well designed language, pragmatic libraries and toolset out of the box, simple deployment AND well defined high end high traffic considerations), but PHP ain't it.
It's one thing to justify its use on the grounds of supporting legacy systems, or other similar compromises. But if you actually think it's a good, well-designed language, then your metric of "goodness" vis-a-vis programming languages is uninformed.
I do not recall at any point in Beating the Averages [1] in which pg used "ease of installation" as part of the definition of a blub language.
Blub has a specific meaning. It's not a synonym for "bad".
There are plenty of other technologies that are as reliable as PHP. Ruby was not really one of them. Ruby went through a bad hype cycle a couple of years ago and was never quite as good as it was sold to be, especially on the reliability front. It's a great anecdote but a bad argument.
In my mind the important thing about "blub" is that there's a valuable feature a language has and the blubbers don't understand the valuable feature.
For instance, ALGOL-type languages use Chomsky's generative grammar to define a syntax that people find intuitive. LISP is blub because it rejects this major innovation.
Languages that are !PHP are blub because they don't recognize that "ease of installation" is a valuable feature.
The thing that makes it win though is not that PHP is intrinsically that much easier to install or run, what makes it win is that it comes pre-installed on most hosts. That's not a problem a language community can solve, that's a problem only the cheap web hosts can solve.
On one of my VPNs, I've had the experience where Django is actually easier to install, because all the mod_python and stuff was already in the distro, and it took less configuration than PHP to make it work and not be a menace to the net. PHP has a lot of really stupid things you better get right if you're trying to configure it from scratch, or you're insecure by default.
http://www.getrailo.com/com/index.cfm/whyrailo/developers/
(Scroll to bottom where they address why for PHP devs)
• Simplicity
More powerful tags for simple file, email, database and other common operations.
• Best Practices Support
If you want to build OO apps using TDD, you can do so. If not, you can still hack out working scripts in minutes.
• Frameworks
A wide range of frameworks designed to make it quick and easy to build well designed web applications.
• OSS Projects
RIAForge has hundred of pre-built projects so you can quickly deliver anything from a blog to a content management system.
• Robust deployment
Railo CFML is easy to manage and deploy, but it's sitting on top of the Java Virtual Machine so it can be deployed to any servlet container or J2EE application server and can take advantage of all of the tooling available for deploying and maintaining Java applications (JMeter, Maven, etc.).
Is this more clear?
You (and others) should give it a try, you will be pleasantly surprised by its simplicity.
Perhaps I've got a negative attitude about the intelligence of developers because I've been a maintenance programmer for too long. I've seen so many apps that almost work in ColdFusion because some guy didn't know if he was using a session scope or an application scope or request variable in CF.
I worked at a place where there was a ColdFusionMafia that existed just to bamboozle management into shelling out $8000 for server licenses. They'd go blah blah blah about how Cold Fusion was a great force multiplier but most of them couldn't code their way out of a paper bag they just knew a bunch of tricks that almost worked but couldn't be bothered to get HTML and SQL escaping right.
To be fair you can write pretty decent code in CF if you know how to code but if you knew how to code why would you be coding in CF?
The ColdFusionMafia ultimately got the organization to spend upwards of $500k worth of software licenses and people's time to implement a commercial CMS product that was ultimately abandoned. They pulled me off a project that was really worthwhile and it ended up in a project failure that caused my whole group and everybody above it all the way to the top of the organization to get fired.
Some recruiter called me the other day wanting to know if I want to code ColdFusion in Ohio and I'm like I'd rather be shuffling punched cards....
CF is easy to get started in, so is PHP. I've seen some horrible spaghetti code in both languages. That doesn't make either of them bad.
I like CF because I like writing fewer lines of code to get things done. That doesn't stop me from looking at other languages seeing if something is better.
In fact some members of the community are blogging the seven languages in seven days book, not all of us have blinders on;<).
http://www.bennadel.com/blog/2106-Seven-Languages-In-Seven-W...