The secret to PHP's success is simple. I've never seen anyone point it out.
It just works.
If you have a web server configured to run PHP, then it's ridiculously simple to get a page to execute. Just put a .php file on the site and it runs. Done.
You don't have to jigger a bunch of components, dink around with a bunch of Tomcat or Ruby on Rails or proxy or other annoying settings. Most other web execution environments have a bunch of Rube Goldberg machine components you have to plug together to get them to work. It also performs very well and supports a lot of things.
True. A lot of webhosts are configured such that you can drop some PHP files into a directory via ftp, and it'll "just work". Which is nice. But...
...that's not really inherent in PHP. You can configure Python to be just as easy, and some webhosts do this. Node is pretty much always this easy. Django and Rails can also be this easy (if you've ever used Webfaction, you'll know what I'm talking about).
And, on the flip side, if you want to install configure PHP yourself, it's actually not that easy. It's trivial to get a PHP page to execute given a web server configured to make it trivial (but, again, that's true for almost any language), but configuring the web server isn't trivial.
Isn't not programming at all even easier? You don't have to get money, find a computer to buy, buy a computer, install an OS, buy an Internet connection, install a web browser, learn to browse the web, learn about how hosting works, find a host, get money to buy a hosting account, learn about apache, install apache, learn about php, install php, learn about text editors, install a text editor, learn php, write PHP, learn about scp, install scp, scp file to server. By the time you've become that proficient with all that stuff, apt-get install libcatalyst-perl on your desktop sounds about as easy as finding a host that supports PHP.
It's not like PHP solves any of the real problems, like how to manage upstream changes, how to automate releases, how to rollback database schemas after a bad release, and so on. The reason why nobody ever talks about those things is because everyone handles them with downtime and swearing. That's not software engineering. That's fail.
This is truer than you know, but for the wrong reasons.
I worked tech support for a shell provider in the 90s and I helped a LOT of users work through the mechanics of setting up a cgi-bin. One of the most difficult concepts for users without a technical background was file permissions -- specifically the execute bit.
I believe PHP's ease of use primarily stems from what most would consider a security vulnerability: mod_php instructs apache to execute code from php files without the execute bit set. This is inherently the same sort of issue behind email worms on Windows -- exec handlers which pass code to an interpreter without honoring the lack of execute permissions.
It's a terrible idea, and also widely popular. I have personally seen users switch from Perl to PHP purely because they could not figure out how to set the execute bit in their Windows FTP program.
I've seen people point it out before and I think it makes perfect sense for explaining its popularity.
I also think it's a micro-optimization for the wrong thing. It's like buying a car based solely on how close the dealership is to your house. You only have to do the initial setup once (by definition) but you have to live with the consequences of your environment of choice every single day for the rest of the project.
I'll go to a crappy coffee shop if it's the only one around, I'm willing to go very far out of my way to get to the car dealership that has the right thing for me.
PHP is just an example of worse is better (whose key is simplicity of implementation), because PHP is easy to get started with things get built in it. Then you have a lifetime of maintenance hacking around all the bad decisions at the start because of it.
Comparing the rails app config system to PHP.INI, ini_set, .htaccess and the million other ways to configure PHP and considering the app config system to be a rube goldberg machine is really unjustified, the very configuration of PHP itself pretty much non-deterministic.
Yes, it just works. That's also where there are thousands of poorly written sites out there that chug down sql injections like they were going out of style.
PHP is a reasonable templating language. That's what it should be used for.
If you use a framework, you're golden, but at that point you could be using any language.
True, I suppose: if PHP were invented today, I imagine the pitch would be something like "it's the Dropbox of web applications: you just put files in a directory and they run."
(...on that note, I just realized how useful it would be if Dropbox's Public folder executed PHP.)
PHP is like living in a big city. There are all sorts of things wrong with it, like homelessness, noise pollution, traffic, bad neighborhoods, corrupt politicians, perennially-under-funded public transit; the list goes on.
And yet there's nowhere like it. You could move to some ideal community somewhere, and maybe you visit there now and then because it doesn't have all those other problems, but all the arts and culture, all your favorite restaurants and bars, all the meetups and hangouts and friends and co-workers make your city worth the downsides.
PHP the environment (part of the server + html processor + no setup or configuration for most users + page is the app + etc..) = WIN for many many people.
Not a single other environment has ever duplicated that. Until someone does they'll never displace PHP. It's ripe for the replacing but understand that it's not just the language, it's the entire environment surrounding it.
Ruby and its community are far from perfect. The biggest difference that I see between it and other communities, is that when a lot of people come about some negative aspect of using Ruby, eventually within a few months people start working on actually fixing it. X number of months later, it ships.
The thing is, the language doesn't fully suck. It has a few sucky parts that are more or less easy to ignore. As has been said elsewhere in this topic[1], the code one produces in PHP is pretty equivalent to what you do in most other languages.
I found myself thinking whether one could make an heir apparent to PHP that removed the suckiest aspects and left the same basic "no configuration, just a bunch of files" model in place (any inherent problems with that model notwithstanding). Sort of how SVN fixed some of the most glaring issues with CVS without forcing people to really change their habits.
But I think that the things PHP really has going for it (huge installed base of the runtime, huge installed base of legacy apps, huge developer community) aren't going to smoothly make the jump to a new language. And once you've given up that sort of backward compatibility, why not fix a few other things while you're at it?
Still, I think there might be potential for a PHP-like language that breaks some backward compatibility but fixes a lot of basic things like unicode support, modules loaded at startup or runtime rather than as a ./Configure flag, syntactic quirks, etc. Something where you could spend a few minutes to a few hours (max) refactoring a PHP script into PHQ (or whatever you want to call it) script and gradually modernize your app.
I don't think people replicate it because having an environment that is based on directly mapping to the filesystem tree is completely inane for modern webapps. Most decent PHP software now hands the request off to a single file (eg index.php) that handles the routing.
Yes, PHP has mass appeal for people that are happy to limit themselves to the lowest common denominator, however people that want to reach even a tiny bit further can discover other languages that have better ways of doing things.
For instance, his "Hello world" example is completely fucking inane, and just spitting out a thing like that will lead to poor app design and unmaintainable spaghetti code.
Depends on how you define the language? Nobody is twisting your arm, you don't have to use any of the inconsistent syntax. Just write your own functions.
The arguments in favor of PHP that I continue to hear run along the lines of "everybody's using it" or "it's not that bad if you know what you're doing" or "it's great because it's the Swiss Army knife of languages."
It's hard to argue with those sentiments. And I think the root of the argument stems from the diverging convictions of two distinctly different camps of hackers. There are grease monkeys who love tinkering and see value in a tried-and-true tool that works everywhere. And then there are the craftsmen who strive for elegant code and choose their tools carefully. (There's truth in both of those aspirations. Let's not get carried away in value judgements between the two camps.)
But hearing "PHP sucks but I like it" sounds like Stockholm Syndrome to me. There are some great aspects to PHP that other web stacks and frameworks could learn from. Yet there are some major flaws that actually get in the way of productivity. I hope we can keep the discussion constructive and learn from both camps in building the future of web programming.
Different people will end up enjoying different tools. I started web development with Ruby and Rails, but find that I really enjoy PHP. Then again, I don't have to maintain anyone else's crappy code. I find that when I write clean, well tested PHP, it really isn't frustrating or painful.
If you prefer something else, that's great! Use it. I guess these types of debates aren't exactly unique to this industry though. When I used to lurk around automotive message boards when I was younger, I recall some pretty epic flamewars among Chevy/Dodge/Ford/etc. fans. Everyone loved their favourite, and were certain that the others were clunky pieces of crap. Sounds a lot like programming language flamewars... :)
Can we all just agree PHP (like many other languages) has some bad features / design choices (evolutionary features, whatever you wanna call em), yet when used properly under the right circumstances it does the job quite well?
A truely masterful carpenter could build you a pretty impressive desk with nothing but a few jagged rocks. But put better tools in his hands, and the same guy will do a much better job, faster. That was the point of the original blog post, and this one didn't really contradict it in any meaningful way.
I don't like the "tools" analogy that always comes up. For example, Robertson screws are better than Phillips head screws, which in turn are better than flatheads. All of them are tools, and they all effectively do the same thing. But the Robertson screw is better.
The best screw is the one which I have a screwdriver/drill head for! (Thus PHP is still the best language for a newbie on $5/mo or less shared web hosting!) But really I agree with your point that these metaphors and analogies into other fields hurt the discussion since it changes to being about pointing out problems with the analogy rather than about whatever the discussion was originally about.
Exactly, though I'm not sure you're making the point you want to. I have dozens of Phillips screws at home, and at least two Phillips screwdrivers. I've never heard of Robertson screws.
I could get a new set of screws and screwdrivers, but it's a lot more difficult and expensive than just using the Phillips stuff I have lying around. Depending on how important my project is (am I making a load-bearing shelf or am I putting up a poster frame?) the answer may differ.
I would claim that a programming language is more like material than a tool. You can easily switch tools during the course of the project and discard them once it's done, but it's not that easy to replace faulty material. If you want good results, you should invest in quality material.
(Of course every analogy holds only up to a certain point.)
Actually, your own analogy is very apt. When correctly applied, all kinds of screws can perform the same task fine. The difference lies in how the screw is driven.
Not sure this is a valid analogy at all; PHP is a tool, not a type of problem (insert joke here), so rather it would be a choice between brands or types of screwdrivers.
Had we waited for the development of ideal programming tools for the web, the Internet would still be struggling to get off the ground. By making the best of what we have and by continually evolving better solutions we've been able to create something that has, quite literally, changed the world.
Let's keep that in mind. The goal and the end-result isn't a monument to superb software engineering. What we create are experiences for, mostly, non-tech users. How the sausage is made almost isn't important (as long as it doesn't kill you). It's easy to get lost in the pursuit for technical excellence and ignore the realities of building a business.
The fact that Facebook is built on PHP should pretty much tell the story and put a lid on these endless arguments: You use whatever tools you have available at the time to create a good user experience. People don't pay for your choice of programming language. In fact, they couldn't care less.
That's not to say that the tech world should not strive to be on a path of continual improvement and technical evolution. Not at all. I guess what I am trying to say at one level is "quit griping and get back to building a product, nothing else matters".
That said: What might be a likely improved successor to PHP? By this I mean, a language that can gain wide adoption while dealing with a number of the issues of PHP (and other languages) and has a high likelihood of being deployed as far and wide as PHP is today.
Agreed. My web applications maintain nearly identical structures (with slight variations due to some OO quirks across platforms) regardless of language choice. At the end of the day most imperative scripting languages are semantically equivalent.
"WSGI in Python gets you part of the way there, but you still need to import a library to talk to the server. This makes PHP just plain easier to get off the ground for web applications."
The first sentence is mostly accurate, but I disagree strongly with the assertion in the second sentence. Grouping related functionality into libraries reduces the cognitive load of programming. The same could be said for his assertion about the benefits of HTTP as a "first-class citizen."
I do agree that getting a PHP application running on a LAMP stack is easier than say getting a WSGI implementation up and running, but this has nothing to do with libraries.
My intention was the full process from creating the first file, to getting a server to serve the content is far easier to do in PHP than Python (granted, in Python it's pretty much boilerplate, but there's a lot more than needs to happen).
As far as the benefit of first-class vs libraries for handling the request, that's something to consider (as there are arguments on both sides)...
I've found that the people I know (even excellent programmers) who love PHP tend to hate Ruby and find it extremely confusing.
Maybe there is just a fundamental brain-structure difference between individuals... I don't actually think PHP is easier for a beginner than something like Sinatra, so I don't buy the explanation that PHP is easier for those new to programming.
I think there may be something to this. I'm used to programming in PHP and Objective-C and going to Ruby just throws my brain for a loop. I just can't grok it, and reading someone else's Ruby code confuses the hell out of me. I'm more of a designer than a programmer, so take this all with a grain of salt, but coming from a C-style language background I totally feel like a different part of my brain needs to turn on (or off?) to program in Ruby.
It is very interesting how, often when one haphazardly produces a language for a particular purpose, one winds with a language which both "sucks" and is orders of magnitude better for that particular purpose than any other language. Arguable examples include Php, Matlab, shell-script and many others.
I'm creating an ad-hoc language right that also has this quality. I cringe as I shoe-horn one or another crude extensions into it and then step back and realize that for its particular purpose, it would be harder to do that much better.
The biggest WTF was that "tied to Apache" section. Being running nginx + PHP-FPM for years, even before FPM was accepted as official SAPI.
I guess that people still think that they know better than their sysadmin regarding how to set up a production environment (regarding to the php.ini rant). Maybe because the sysadmins know that expose_php = off turns off those pesky easter eggs. Or they are better at Reading The F[...]riendly Manual (http://www.php.net/manual/en/ini.core.php#ini.expose-php).
Had a good laugh at the complaints about PECL libraries that provide "everything but the kitchen sink". Last time I checked, it was still "The PHP Extension Community Library". People should complain about that particular project, if they need to. It has nothing to do with the internals team.
Wondering how he could forget about the <script language="php"></script> bit.
I work all day with PHP even though I love Ruby (and Rails, and Sinatra...) because practically ALL our client base wants either a static site or Wordpress, or another PHP-based CMS. Few of our clients have the budget for a custom web app with its own custom web stack to power it.
There's almost nothing faster to get bootstrapped into a functional application or script than PHP. Assuming your server is already configured with PHP you just upload the project.
PHP 5.3 and 5.4 give me great hope for the future of the language.
I think many like PHP because an inconsistent language full of design flaws is in many contexts better (in a less is more sense) than a good language that is backed by a complex web framework and library system that contains too many complexities, versioning issues, is slow by default or hard to tune, and so forth.
With PHP people have something that just works, reasonably, and given that an interpreter lives the lifespan of a "page view" making big errors is non trivial.
So PHP is not a good language, but many other languages should learn something from PHP. The problem is that the community backing this better dynamic languages, such as Python and Ruby, still for some (IMHO obscure) reason aren't shipping something that is PHP-alike, but just with a better base language (without trying to add tons of abstraction layers).
I no longer use PHP because after years of using better languages (I like Ruby as a "practical language") it's too hard to return back to PHP, but I often find myself fighting with the useless complexities and layers of abstractions that Ruby contains "by default". Not in the language or the implementation itself, that is good enough IHMO, but in the tons of gems around and in the integration with the web "side".
I have written, maintained and worked on gigantic PHP codebases, mainly in the realm of ecommerce (not that train wreck, magento). I have a lovehate relationship with the language, and my pet peeve is that it is so easy, we get the lowest ability developers who never take time to learn the theory or any other technologies. Having said that... If it wasn't for the LAMP infrastructure, the ease and speed of development, these codebases could not have been developed.
I think the standard libraries could do with an update, to add the consistency they deserve, and do update them to use modern features. The community for PHP is reaching a point of maturity that it has not seen before (look at composer, PSR-0, symfony2 and ZF2). I think this maturity is making the community a good place right now. I'm not leaving it anytime soon.
Take away PHP, watch the major sites of the Internet disappear. Where would we be with no Wikipedia?
If I have learned anything during my 3-4 years of experience as a software dev it is that
a) All languages, frameworks and technologies are bad and ugly, each in many of their own horrible ways
b) Nobody has any fracking idea what they're doing (mostly)
c) Your best bet is to find something that does not hurt you as bad as other stuff and stick with it. If you enjoy php, that fine (of course it's completely beyond me how it is possible to enjoy it, but its not the point).
On a side note, after having spent most of my time programming in high-level languages, I wonder how things are down there in bare-metal-programming land. I've grown tired of web development and I wonder what it's like programming in an environment that does not have poorly designed, inconsistent frameworks and leaky abstractions, only registers, memory and pins :) Too bad it's probably too late for me to get started there.
I would still have to say that PHP, by all its flaws, gets the job done. And in the end of the day thats what count to me. That might be a bad view to have but I've been sticking with it for a lot of years now even though Ive flirted with a lot of other languages. Its still the girl i get home to every night
[+] [-] api|14 years ago|reply
It just works.
If you have a web server configured to run PHP, then it's ridiculously simple to get a page to execute. Just put a .php file on the site and it runs. Done.
You don't have to jigger a bunch of components, dink around with a bunch of Tomcat or Ruby on Rails or proxy or other annoying settings. Most other web execution environments have a bunch of Rube Goldberg machine components you have to plug together to get them to work. It also performs very well and supports a lot of things.
[+] [-] Lazare|14 years ago|reply
...that's not really inherent in PHP. You can configure Python to be just as easy, and some webhosts do this. Node is pretty much always this easy. Django and Rails can also be this easy (if you've ever used Webfaction, you'll know what I'm talking about).
And, on the flip side, if you want to install configure PHP yourself, it's actually not that easy. It's trivial to get a PHP page to execute given a web server configured to make it trivial (but, again, that's true for almost any language), but configuring the web server isn't trivial.
[+] [-] jrockway|14 years ago|reply
It's not like PHP solves any of the real problems, like how to manage upstream changes, how to automate releases, how to rollback database schemas after a bad release, and so on. The reason why nobody ever talks about those things is because everyone handles them with downtime and swearing. That's not software engineering. That's fail.
[+] [-] fffggg|14 years ago|reply
I worked tech support for a shell provider in the 90s and I helped a LOT of users work through the mechanics of setting up a cgi-bin. One of the most difficult concepts for users without a technical background was file permissions -- specifically the execute bit.
I believe PHP's ease of use primarily stems from what most would consider a security vulnerability: mod_php instructs apache to execute code from php files without the execute bit set. This is inherently the same sort of issue behind email worms on Windows -- exec handlers which pass code to an interpreter without honoring the lack of execute permissions.
It's a terrible idea, and also widely popular. I have personally seen users switch from Perl to PHP purely because they could not figure out how to set the execute bit in their Windows FTP program.
The rest is inertia, as far as I'm concerned.
[+] [-] MartinCron|14 years ago|reply
I also think it's a micro-optimization for the wrong thing. It's like buying a car based solely on how close the dealership is to your house. You only have to do the initial setup once (by definition) but you have to live with the consequences of your environment of choice every single day for the rest of the project.
I'll go to a crappy coffee shop if it's the only one around, I'm willing to go very far out of my way to get to the car dealership that has the right thing for me.
[+] [-] alanh|14 years ago|reply
Really?
The easy of deploying a single-purpose script / hello world is always trotted out as the reason PHP ever became popular.
Yes, even in yesterday’s big item “PHP: A Fractal of Bad Design.”
[+] [-] fleitz|14 years ago|reply
Comparing the rails app config system to PHP.INI, ini_set, .htaccess and the million other ways to configure PHP and considering the app config system to be a rube goldberg machine is really unjustified, the very configuration of PHP itself pretty much non-deterministic.
http://www.jwz.org/doc/worse-is-better.html
[+] [-] sgerrand|14 years ago|reply
As other have pointed out in this thread, you can easily configure a web server to behave like that for files in other languages like Perl or Python.
[+] [-] emperorcezar|14 years ago|reply
PHP is a reasonable templating language. That's what it should be used for.
If you use a framework, you're golden, but at that point you could be using any language.
[+] [-] derefr|14 years ago|reply
(...on that note, I just realized how useful it would be if Dropbox's Public folder executed PHP.)
[+] [-] slurgfest|14 years ago|reply
[+] [-] aneth|14 years ago|reply
Looking for happiness? Heroine "just works".
Hungry and poor? Eating McDonald's three meals a day is cheap and easy.
[+] [-] mortenjorck|14 years ago|reply
And yet there's nowhere like it. You could move to some ideal community somewhere, and maybe you visit there now and then because it doesn't have all those other problems, but all the arts and culture, all your favorite restaurants and bars, all the meetups and hangouts and friends and co-workers make your city worth the downsides.
[+] [-] greggman|14 years ago|reply
PHP the language sucks ass.
PHP the environment (part of the server + html processor + no setup or configuration for most users + page is the app + etc..) = WIN for many many people.
Not a single other environment has ever duplicated that. Until someone does they'll never displace PHP. It's ripe for the replacing but understand that it's not just the language, it's the entire environment surrounding it.
[+] [-] chaostheory|14 years ago|reply
Someone in the Rails community is trying with a small start.
http://www.kickstarter.com/projects/1397300529/railsapp
Ruby and its community are far from perfect. The biggest difference that I see between it and other communities, is that when a lot of people come about some negative aspect of using Ruby, eventually within a few months people start working on actually fixing it. X number of months later, it ships.
[+] [-] wvenable|14 years ago|reply
[1] http://news.ycombinator.com/item?id=3824767
[+] [-] frankus|14 years ago|reply
But I think that the things PHP really has going for it (huge installed base of the runtime, huge installed base of legacy apps, huge developer community) aren't going to smoothly make the jump to a new language. And once you've given up that sort of backward compatibility, why not fix a few other things while you're at it?
Still, I think there might be potential for a PHP-like language that breaks some backward compatibility but fixes a lot of basic things like unicode support, modules loaded at startup or runtime rather than as a ./Configure flag, syntactic quirks, etc. Something where you could spend a few minutes to a few hours (max) refactoring a PHP script into PHQ (or whatever you want to call it) script and gradually modernize your app.
[+] [-] antihero|14 years ago|reply
Yes, PHP has mass appeal for people that are happy to limit themselves to the lowest common denominator, however people that want to reach even a tiny bit further can discover other languages that have better ways of doing things.
For instance, his "Hello world" example is completely fucking inane, and just spitting out a thing like that will lead to poor app design and unmaintainable spaghetti code.
[+] [-] maratd|14 years ago|reply
Depends on how you define the language? Nobody is twisting your arm, you don't have to use any of the inconsistent syntax. Just write your own functions.
The core language is actually very similar to C.
[+] [-] brendn|14 years ago|reply
It's hard to argue with those sentiments. And I think the root of the argument stems from the diverging convictions of two distinctly different camps of hackers. There are grease monkeys who love tinkering and see value in a tried-and-true tool that works everywhere. And then there are the craftsmen who strive for elegant code and choose their tools carefully. (There's truth in both of those aspirations. Let's not get carried away in value judgements between the two camps.)
But hearing "PHP sucks but I like it" sounds like Stockholm Syndrome to me. There are some great aspects to PHP that other web stacks and frameworks could learn from. Yet there are some major flaws that actually get in the way of productivity. I hope we can keep the discussion constructive and learn from both camps in building the future of web programming.
[+] [-] rpeden|14 years ago|reply
http://i.imgur.com/pG3q7.jpg
Different people will end up enjoying different tools. I started web development with Ruby and Rails, but find that I really enjoy PHP. Then again, I don't have to maintain anyone else's crappy code. I find that when I write clean, well tested PHP, it really isn't frustrating or painful.
If you prefer something else, that's great! Use it. I guess these types of debates aren't exactly unique to this industry though. When I used to lurk around automotive message boards when I was younger, I recall some pretty epic flamewars among Chevy/Dodge/Ford/etc. fans. Everyone loved their favourite, and were certain that the others were clunky pieces of crap. Sounds a lot like programming language flamewars... :)
[+] [-] nthitz|14 years ago|reply
[+] [-] mattbriggs|14 years ago|reply
[+] [-] mikeash|14 years ago|reply
[+] [-] Killswitch|14 years ago|reply
[+] [-] jrockway|14 years ago|reply
Try getting good at a different programming language, then write your blog post about how PHP is awesome.
[+] [-] natesm|14 years ago|reply
[+] [-] Jach|14 years ago|reply
[+] [-] untog|14 years ago|reply
I could get a new set of screws and screwdrivers, but it's a lot more difficult and expensive than just using the Phillips stuff I have lying around. Depending on how important my project is (am I making a load-bearing shelf or am I putting up a poster frame?) the answer may differ.
[+] [-] adambyrtek|14 years ago|reply
(Of course every analogy holds only up to a certain point.)
[+] [-] Zr40|14 years ago|reply
[+] [-] kprobst|14 years ago|reply
[+] [-] jack-r-abbit|14 years ago|reply
[+] [-] robomartin|14 years ago|reply
Let's keep that in mind. The goal and the end-result isn't a monument to superb software engineering. What we create are experiences for, mostly, non-tech users. How the sausage is made almost isn't important (as long as it doesn't kill you). It's easy to get lost in the pursuit for technical excellence and ignore the realities of building a business.
The fact that Facebook is built on PHP should pretty much tell the story and put a lid on these endless arguments: You use whatever tools you have available at the time to create a good user experience. People don't pay for your choice of programming language. In fact, they couldn't care less.
That's not to say that the tech world should not strive to be on a path of continual improvement and technical evolution. Not at all. I guess what I am trying to say at one level is "quit griping and get back to building a product, nothing else matters".
That said: What might be a likely improved successor to PHP? By this I mean, a language that can gain wide adoption while dealing with a number of the issues of PHP (and other languages) and has a high likelihood of being deployed as far and wide as PHP is today.
[+] [-] Kilimanjaro|14 years ago|reply
[+] [-] vectorpush|14 years ago|reply
[+] [-] monkeyfacebag|14 years ago|reply
The first sentence is mostly accurate, but I disagree strongly with the assertion in the second sentence. Grouping related functionality into libraries reduces the cognitive load of programming. The same could be said for his assertion about the benefits of HTTP as a "first-class citizen."
I do agree that getting a PHP application running on a LAMP stack is easier than say getting a WSGI implementation up and running, but this has nothing to do with libraries.
[+] [-] ircmaxell|14 years ago|reply
As far as the benefit of first-class vs libraries for handling the request, that's something to consider (as there are arguments on both sides)...
[+] [-] grandalf|14 years ago|reply
Maybe there is just a fundamental brain-structure difference between individuals... I don't actually think PHP is easier for a beginner than something like Sinatra, so I don't buy the explanation that PHP is easier for those new to programming.
[+] [-] flyosity|14 years ago|reply
[+] [-] emilw|14 years ago|reply
I leave assigning these as an exercise for the reader.
[+] [-] drumdance|14 years ago|reply
[+] [-] joe_the_user|14 years ago|reply
I'm creating an ad-hoc language right that also has this quality. I cringe as I shoe-horn one or another crude extensions into it and then step back and realize that for its particular purpose, it would be harder to do that much better.
[+] [-] 1SaltwaterC|14 years ago|reply
I guess that people still think that they know better than their sysadmin regarding how to set up a production environment (regarding to the php.ini rant). Maybe because the sysadmins know that expose_php = off turns off those pesky easter eggs. Or they are better at Reading The F[...]riendly Manual (http://www.php.net/manual/en/ini.core.php#ini.expose-php).
Had a good laugh at the complaints about PECL libraries that provide "everything but the kitchen sink". Last time I checked, it was still "The PHP Extension Community Library". People should complain about that particular project, if they need to. It has nothing to do with the internals team.
Wondering how he could forget about the <script language="php"></script> bit.
[+] [-] trebor|14 years ago|reply
I work all day with PHP even though I love Ruby (and Rails, and Sinatra...) because practically ALL our client base wants either a static site or Wordpress, or another PHP-based CMS. Few of our clients have the budget for a custom web app with its own custom web stack to power it.
There's almost nothing faster to get bootstrapped into a functional application or script than PHP. Assuming your server is already configured with PHP you just upload the project.
PHP 5.3 and 5.4 give me great hope for the future of the language.
[+] [-] antirez|14 years ago|reply
With PHP people have something that just works, reasonably, and given that an interpreter lives the lifespan of a "page view" making big errors is non trivial.
So PHP is not a good language, but many other languages should learn something from PHP. The problem is that the community backing this better dynamic languages, such as Python and Ruby, still for some (IMHO obscure) reason aren't shipping something that is PHP-alike, but just with a better base language (without trying to add tons of abstraction layers).
I no longer use PHP because after years of using better languages (I like Ruby as a "practical language") it's too hard to return back to PHP, but I often find myself fighting with the useless complexities and layers of abstractions that Ruby contains "by default". Not in the language or the implementation itself, that is good enough IHMO, but in the tons of gems around and in the integration with the web "side".
[+] [-] evilvoidhamster|14 years ago|reply
I think the standard libraries could do with an update, to add the consistency they deserve, and do update them to use modern features. The community for PHP is reaching a point of maturity that it has not seen before (look at composer, PSR-0, symfony2 and ZF2). I think this maturity is making the community a good place right now. I'm not leaving it anytime soon.
Take away PHP, watch the major sites of the Internet disappear. Where would we be with no Wikipedia?
[+] [-] freshhawk|14 years ago|reply
Good god, what debuggers have you been using that makes PHP and xdebug seem like it "works quite well".
[+] [-] 10098|14 years ago|reply
a) All languages, frameworks and technologies are bad and ugly, each in many of their own horrible ways
b) Nobody has any fracking idea what they're doing (mostly)
c) Your best bet is to find something that does not hurt you as bad as other stuff and stick with it. If you enjoy php, that fine (of course it's completely beyond me how it is possible to enjoy it, but its not the point).
On a side note, after having spent most of my time programming in high-level languages, I wonder how things are down there in bare-metal-programming land. I've grown tired of web development and I wonder what it's like programming in an environment that does not have poorly designed, inconsistent frameworks and leaky abstractions, only registers, memory and pins :) Too bad it's probably too late for me to get started there.
[+] [-] ranza|14 years ago|reply