People who argue for PHP as a language always brings up this one argument: "PHP gets things done". Great. It get things done. Quick and dirty, but it gets things done.
That is all fine and dandy, but what when you need things done proper? How does it stack up then?
Oh. You mean you have to consider input-data as actual text, not as some byte-streams which incidentally maps to the same character-set you used to write your code with?
Oh. You mean I need to have locale-ware date, time and number-format handling?
Oh. You mean I need to actually validate these input-data and sanitize them for SQL injections and all that before sending off to the database?
Etc etc.
When you need things not just "done", but done proper, how well does PHP stack up then?
It is my opinion (as in opposed to fact) that when you add that one tiny, but oh so important clause, all arguments for PHP being the one language which gets things done falls apart.
I think with the proper tools (and I don't mean using the bare language, but enough libraries that give you nicer abstractions), it can be used for doing things properly just fine. Heck we do a living out of building custom apps for customers that range from financial world to data-oriented startups. You just have to know what you are doing, like with any language really.
- The mbstring ext gives you more or less decent transcoding support. I never had huge issues since it's generally ISO-8859-15 or UTF-8 I'm dealing with, but you may have a point. I can't answer conclusively.
- SQL injection is handled by the PDO db connectors just fine, and all libraries abstracting this basically take care of it. Unless you follow 10 years old tutorials it's pretty hard to have SQL injection leaks.
Define "proper"? Does meeting a business need, bringing in money, putting food on the table, and paying the rent mean "proper"? If not, why not?
PHP has a plethora of flaws, but it's still a serious tool and used to build creations of significant value, that can't be ignored. As far as quality, what platform do you use to guarantee quality? I've heard many stories about terribly broken code bases in every language that's out there, from C to Ruby and Python to Java.
By "proper" I mean building a piece of software which has a clean and maintainable implementation, logical semantics, proper encapsulation, and last but not least, which is solid.
That is, should be able to withstand real world challenges and input-data without crashing, failing, silently failing, creating corrupted data or any combination of those things.
Granted, it's been quite a while since I've done PHP, and it that sense the initial point of the article stand true, but when I need something done in PHP, I always find myself spending more time ensuring basic truths which a proper language should guarantee for me are actually true, than I spend writing code doing something.
I find PHP silently failing all the time making debugging code hard. And it makes it hard to do things proper, because you may have failure-modes which you should have been able to catch, but which PHP "kindly" shields you from.
Right. So by your definition there are no good platforms to write "proper" web applications in, since it takes a lot of special effort to avoid all of those problems in any language (ruby, python, c, c#, java, node.js).
Some languages makes it easier, some make it hard. I would argue that PHP falls into the "hard" camp. And C would definitely be in the "very, very hard" camp.
And then you have stricter languages like C# which makes doing things proper the default, although often at the expense of making other things harder.
That said: This is definitely crossing the line between factual and subjective right now. And I can see how this is a subject open to discussion.
Have you written a production app for PHP in the last 5 years? It handles (out of the box) multibyte encodings, locale-aware number and date formatting, parameterized prepared statements for your SQL, etc as well as most any language.
I'll be intellectually honest and admit that, no, I haven't really touched PHP for anything near a production app in the last 5 years.
But to be absolutely clear: before PHP used to be the only language I wielded for money. I have enough lines of PHP on my back to claim the right to an opinion.
That said, last time I looked into PHP, modus operandi seemed to being focusing on making things easy, not making it easy to do things right.
AFAIK this one quote from "PHP is a fractal of bad design" still holds true and that if you ignore all the other obvious things (wildly inconsistent BCL, etc), it is probably the core reason why I can never bring myself to like anything PHP:
PHP is built to keep chugging along at all costs. When faced with either doing something nonsensical or aborting with an error, it will do something nonsensical. Anything is better than nothing.
AFAIK that's still true, and I find it hard to have confidence in any code written on top of something based on that core tenet.
So why did you comment in the first place, in what world do you find it expectable to berate something with no working knowledge?
Also I have no trouble developing PHP code that halts on the first sniff of an error. But yes, with no experience of the language it will happily chug along.
Surprisingly, out of all the comments, this one caught my eye. I've been hiring programmers since 2005 that have to maintain or extend PHP systems. In 2005, it was difficult to find programmers that knew only PHP (or Perl, which was still used) who had any familiarity with object-oriented programming. Over time, PHP has bolted on features, and at each point, the vast numbers of available PHP programmers are (understandably) not familiar with those features. And obviously the systems that have to be maintained don't have these features. So the armies of PHP programmers are well matched to the old systems. This eliminates a huge risk to the business -- finding relatively inexpensive developers. This is an often cited advantage of PHP. But only the PHP of 2007 (or so) is relevant.
The PHP of 2009 might be worthwhile for the creation of business value (and possibly the reduction of maintenance-related risks), but as I said, the easily available programmers have no experience in those features or concepts. The more common scenario is that a particular programmer has experience in some other language that already included those features and doesn't mind working on old PHP systems. Believe me, there are not legions of these people.
And regarding the 'PHP of 2012', the major problem isn't the availability of programmers who have experience in the new features (they almost don't exist). It is the availability on distros stable enough to support an SLA or provide a modicum of security assurances. This problem applies to all languages though. I'm just pointing out that the 'PHP of 2012' is not as much of an option as it may appear.
To me, every PHP version being vastly better than the previous version says something: the current version is shit too, it's just going to take another few versions until you admit it :P
Compared to something like python, where version 3 has basically one major improvement over version 2 (ie, a unicode core); everything else was done pretty much right the first time, and massive changes aren't needed.
Heck, you can still use 2.5 (the python of 2006) quite happily today, and you'll be missing out on a few nice features that would make your life easier, but there's nothing wrong with it like there is with previous version of PHP.
Regardless of the fact that y2 started at 0.5, fully half of what y1 started at, at some point y2 overtakes y1. It's impotent to whine endlessly that a language used to be bad.
So PHP 5 years ago was terrible. PHP today is 'nearly as good' as Python (I'd argue it's better). In 5 years PHP is going to blow Python out of the water.
These languages that are 'better than PHP' have no appreciable market share, and it's not a vast conspiracy and it's not because PHP caters to the lowest common denominator. It's because they suck, fundamentally, at getting things done. WordPress doesn't exist in Python. Symfony doesn't exist in Python. Doctrine does, but PHP has more database drivers than Python so Doctrine is better.
You can be terse, elegant, and beautiful in Python. That's great, but no one I know has ever cared about what the code they're paying for looks like. They care about stability, agility, and testability - things you've been able to get in PHP since 2005.
I think your graph is accurate when it comes to the amount of effort put into polishing each language -- but as to actual quality, I'd firstly say y=1 is the goal (the language is basically complete; you can add more around the edges, but the core is solid and needs no more changes), and it doesn't account for the fact that with a constant large amount of effort as input, progress as output slows down exponentially due to backwards compatibility concerns. As such, I still think that starting off good and evolving slowly is better than starting off awful and rapidly turning into a giant blob of band-aids :P
Again with the scales, I agree that PHP is great for getting things done to start with, and once you've started with something then carrying on using it is easier than changing. That's why my biggest and most successful project still uses PHP, even though experience has taught me that everything else is more productive after the initial setup hurdle~
Stability, agility, and testability have been in other languages for decades, and in all three cases other languages have done them better, so I'm not sure why PHP having them since 2005 is supposed to be a good sign...
> I'd firstly say y=1 is the goal (the language is basically complete; you can add more around the edges,
Not your functions, not your plane, you don't get to define parameters.
> starting off awful and rapidly turning into a giant blob of band-aids :P
PHP has been completely rewritten at least twice.
> everything else is more productive after the initial setup hurdle~
Can you give a single example of something in Python that introduces greater productivity than PHP?
> and in all three cases other languages have done them better
> so I'm not sure why PHP having them since 2005 is supposed to be a good sign...
Now you're just being a pedant. The point is that it isn't 2005 and it's not 1978. It's 2012. Talking about what the capabilities of a language were almost a decade ago is useless.
The PHP interpreter is much like any other compiler or interpreter. It will halt on errors. It will, by default, output warnings/notices for things like accessing uninitialized variables. Like any other compiler or interpreter, you can tell it to hide warnings, or to halt on warnings, or to log them somewhere instead of outputting them. What makes this a fundamental weakness of the language, but not of, say, C, where gcc will also happily compile code no matter how many warnings it runs into?
C is intended to be low-level, like an extra fancy set of macros for writing assembly. It is intentionally not supposed to do that much for you because you need greater control to do things like writing UNIX. Nonetheless, if you use it seriously then you will find that gcc does outright refuse to compile a great many things that it recognizes as broken, rather than chugging along. There is no way to simply suppress all compiler errors because there should not be.
Nobody in this discussion has raised the possibility of writing web apps entirely in C and suppressing all compiler warnings as they did so. That is a scary idea. And it gets even scarier if we are advocating for newbies to start writing web apps that way.
<input type="text"> works the same as <input type="foobar">
You can have multiple tags with the same ID field.
You can do ALL that and your page will still render, and probably look just fine. That's a major reason why the web took off. Because it didn't take perfection to get something done. Anyone that wanted to make a webpage could fumble around and make something that looked like a webpage.
Perhaps the web would be in a better place if browsers gave an fatal error if it tried to load a page that doesn't validate ... or maybe there wouldn't be a World Wide Web, much like there aren't any CueCats lying around.
You're being some what ignorant. Modern PHP platforms support locales, utf8, and SQL injection prevention out of the box, and the libraries to do so are vast, varied, and decoupled.
That is all fine and dandy, but what when you need things done proper? How does it stack up then?
Oh. You mean you have to consider input-data as actual text, not as some byte-streams which incidentally maps to the same character-set you used to write your code with?
Oh. You mean I need to have locale-ware date, time and number-format handling?
Oh. You mean I need to actually validate these input-data and sanitize them for SQL injections and all that before sending off to the database?
Etc etc.
When you need things not just "done", but done proper, how well does PHP stack up then?
It is my opinion (as in opposed to fact) that when you add that one tiny, but oh so important clause, all arguments for PHP being the one language which gets things done falls apart.
Or am I being too simplistic?