you could say that all other web platforms are blub because they don't see the value that PHP brings to the table.
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.
I won't defend PHP as a language, but from an accessibility point of view, other platforms could certainly make things easier.
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.
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.
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!)
Also, the days of PHP's deployment superiority are nearly over.
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...
> Wow, what an achievement! This is the one thing that PHP really, seriously got right: no application server.
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.
Well, if you're considering Apache+plugin to be an application server, then I guess I need to say: no additional application server other than the web server. Most modern systems have a web server and a separate process for the application server (proxied to over HTTP or fed by FastCGI or WSGI or a neat otherwise unused protocol). The standalone application server (back when I was mostly using those languages) always seemed to have a bunch of quirks and to fail at every insult. Compared to the Rube Goldberg nature of some of these stacks of servers and protocols, PHP is delightfully simple, conceptually.
> Compared to the Rube Goldberg nature of some of these stacks of servers and protocols, PHP is delightfully simple, conceptually.
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.
However, PHP was designed from the outset to run in this mode so the interpreter is an order of magnitude faster than Perl, which is what competed with PHP back in 2001 -- PHP was ~designed~ through and through to do what it does, and that's why it does it so well.
I know I might get voted down for not adding to the discussion, but I loved this post. I actually LOL'd. Hammered in screws is exactly how PHP feels to me. And, as a long-time PHP dev who still has to use it on the job (but never for personal projects), putting up a defense of it screams "n00b" to me more than anything else.
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.
and it pick mongrel 2 I have to evaluate a number of different products for hosting ruby, each of which claims to be way better than all the others... yeah right
"you could say that all other web platforms are blub because they don't see the value that PHP brings to the table."
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.
Everybody understands PHP's ease of already-existing-installation is just about the only thing keeping it going. The idea that this is news is a strawman, I've seen this discussed for years and years.
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.
But, it didn't used to come pre-installed. On many hosts in the 1996-1998 range, Perl was the default, and sometimes only, option for dynamic apps. But typically you had to only put files in /cgi-bin, futz with permissions, remember to include content-headers, etc. PHP 'won' because it was genuinely more straightforward than the competition in most use cases.
that article is strikingly inarticulate. if you've got to tell me to scroll to the bottom, then it's a complete failure at selling railo, whatever it is
I am getting a 404 with the link right now. Railo is a JBOSS project that is an open source version of CFML. Here's what they say about Railo in comparison to PHP:
• 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.).
Haha! Having developed with both languages I can honestly say that Coldfusion (one word) simplifies 90+% of the tasks that you would need to use on a regular basis. Is PHP more feature rich, perhaps, but you're not land locked with CF. It allows you to delegate to any other jvm runnable language(in the same execution context, ie. Pass variables between) if need be.
You (and others) should give it a try, you will be pleasantly surprised by its simplicity.
I've done my time in Cold Fusion hell, I know what I need to know.
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....
Sounds like a bad job. I've had bad jobs but I've never blamed the language.
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;<).
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.