I usually don't jump into these kinds of threads. You get an awful lot of programmers -- some hobbyist, some professional, some experienced, and most of them self-taught -- all with their own prejudices and methodologies, all arguing over what the "right" way is. They go absolutely nowhere, do nothing productive, and turn into a huge time sink for everyone involved.
That said, this article, and every other one like it, reeks of some strange belief that every single language is supposed to have all of the features of some programmer's favorite language, as well as all of the neat new trendy stuff, and if the language doesn't support all of that -- well then it's dead! Or dying. Or "a husk".
There doesn't seem to be any realization on the part of the programmer that a particular language is just a tool, usually designed for a specific application. The programmer is attempting to fit a square peg into a round hole, and they're cursing at the square peg because it doesn't fit.
Let's take one example: closures. They sounded interesting, and potentially could solve a problem in a large JavaScript library I was working on. So I got to know them, I practiced with them, I made sure I grokked them before trying to apply them. Then I put them to work, and found that they ended up making my library unnecessarily complex, that they caused some odd behaviors occasionally, and that they didn't solve any problem that I couldn't more easily solve using simpler methods.
So, does PHP's lack of this author's favorite features really make it a "husk"? No, not at all. Applications as large and complex as osCommerce don't rely on those language features; they rely on the features that the language does have, and they work just fine.
One of the most basic skills programmers need to have in their toolbox is the ability to adapt their habits according to the tools they're using. The programmers that spend their time writing blog posts like this one don't seem to have picked that up.
...Ugh, this just cost me 10 minutes that I could've spent actually working on one of my projects. :-(
I'm not complaining about what features PHP has. In fact, I was never that annoyed that PHP didn't have lamdas or closures until now.
My problem is that it wasn't implemented _correctly_. If you're going to implement a feature, do it right or don't do it at all. Their lack of concern or pride in their project does not bode well for the community.
If there's anything good about PHP that I can tell, its that development is heavily community driven and has been since the early days. However, I think PHP got so popular, and so quickly, that in many cases the community's desire for features has led to an inconsistent, and in your view, 'broken' system. The need for backwards compatibility from almost the very beginning has taken its toll, I think. Is it really 'broken' though? Of course, similar concepts have been implemented in other languages much more elegantly. But PHP is not about elegance - it's about backwards compatibility, and responding to community feature requests.
I'm not a part of the community, and I'm no longer a PHP developer (if I can help it) but I can't think of any other reason the global functions would still have inconsistent argument orders almost 14 years on. So, if the 'correctness' of their implementation bothers you, do what I did: move on. Because it will never get any better.
Incidentally, I wrote an anti-PHP rant last year called "Why PHP Won" that made its rounds here. It's pretty easy to get fed up with PHP, especially when you know there's better stuff out there. Once you're at that point though, you're done. It's anything-else time.
My comment wasn't entirely directed only at your post. The most common complaint against PHP (and other languages, frameworks, etc.) is that it doesn't support the features or methods the programmer expects.
That said, in direct reference to your post: so what? My point still stands. I don't disagree with your assessment of the way it implements those features, I just don't think that it means "there is no hope for PHP", and I don't think it's at all productive to waste time complaining that it doesn't behave the way you want it to.
PHP -- and most other languages -- do have the power to "hack something together". You just have to be willing to adapt to the system at hand.
Thank you for this - I'm the author of a very large PHP application that has been in development for 7 years, and it _works_. We don't use a lot of the more advanced features in PHP, since our target support is PHP 4.3.0, so this leads to some creative (i.e. fun) problems at times. PHP is as "complete" as it needs to be for us.
It reminds me of a time when I had to maintain some very large programs written 100% in AWK - talk about a limited feature set - you had to work with a more limited set of functions and features, but often led to some creative solutions.
"...our target support is PHP 4.3.0, so this leads to some creative (i.e. fun) problems at times."
"PHP is as "complete" as it needs to be for us."
It's so complete that it's painful to write in? There's something to be said for languages that focus on a particular application while peripheral features suffer, but the PHP language is in no way superior to Python or Ruby, even in regards to web development, and there's no problem with saying so.
People use PHP because lots of other people know it, and because it's widely available. Those aren't merits of the language itself. Yes, good things can be written in PHP. That doesn't mean the language isn't demonstrably inferior.
I'm guessing your definition of pain is different then mine - I don't have any issues with writing PHP - it just works for me. I've been developing in PHP since 2002, so by now I'm used to the language and how it works, and don't really have any expectations for new features.
I can see however that coming from a language like Python or Ruby, you're probably going to try to develop in PHP like you would in one of those languages - and I believe that is where frustration will be found. I think it's good to think of PHP as a "simpler" language - stick with the basics and it will work well (as well as be pretty fast).
I was considering language features separately. If you're trying to pick a language, no one would pick PHP unless they need to work with people who already know PHP. If you're trying to pick a runtime, PHP occasionally makes sense due to ease of deployment, memory issues, etc.
There doesn't seem to be any realization on the part of the programmer that a particular language is just a tool, usually designed for a specific application. The programmer is attempting to fit a square peg into a round hole, and they're cursing at the square peg because it doesn't fit.
Ummmm, wrong! The author isn't saying "PHP sucks because it doesn't have closures like my favorite language, so it's dead to me!". The author is saying "PHP claims to support closures, but when you actually attempt to use them for anything useful, they're broken."
So what he's actually cursing is that he has a round hole, and something that looks like a round peg, except it's really not.
Maybe it was a poor choice of title, but the thrust of the article is that closures supposedly are available in the language, but the implementation is so poor as to be unusable.
Part of the problem is that once you start using closures and lambdas all over the place, it's really hard to go back to a language without them. Yes, some tools weren't meant to do some jobs, but PHP's competition has those features, and they work, and they work well. If they wanted to make a simple language without those features, fine, but that won't stop people from complaining that it doesn't have them, and it won't stop people from complaining when those features don't work the way that everyone else's versions of the features work.
Comments
I usually don't jump into these kinds of threads. You get an awful lot of programmers -- some hobbyist, some professional, some experienced, and most of them self-taught -- all with their own prejudices and methodologies, all arguing over what the "right" way is. They go absolutely nowhere, do nothing productive, and turn into a huge time sink for everyone involved.
That said, this article, and every other one like it, reeks of some strange belief that every single language is supposed to have all of the features of some programmer's favorite language, as well as all of the neat new trendy stuff, and if the language doesn't support all of that -- well then it's dead! Or dying. Or "a husk".
There doesn't seem to be any realization on the part of the programmer that a particular language is just a tool, usually designed for a specific application. The programmer is attempting to fit a square peg into a round hole, and they're cursing at the square peg because it doesn't fit.
Let's take one example: closures. They sounded interesting, and potentially could solve a problem in a large JavaScript library I was working on. So I got to know them, I practiced with them, I made sure I grokked them before trying to apply them. Then I put them to work, and found that they ended up making my library unnecessarily complex, that they caused some odd behaviors occasionally, and that they didn't solve any problem that I couldn't more easily solve using simpler methods.
So, does PHP's lack of this author's favorite features really make it a "husk"? No, not at all. Applications as large and complex as osCommerce don't rely on those language features; they rely on the features that the language does have, and they work just fine.
One of the most basic skills programmers need to have in their toolbox is the ability to adapt their habits according to the tools they're using. The programmers that spend their time writing blog posts like this one don't seem to have picked that up.
...Ugh, this just cost me 10 minutes that I could've spent actually working on one of my projects. :-(
I'm not complaining about what features PHP has. In fact, I was never that annoyed that PHP didn't have lamdas or closures until now.
My problem is that it wasn't implemented _correctly_. If you're going to implement a feature, do it right or don't do it at all. Their lack of concern or pride in their project does not bode well for the community.
If there's anything good about PHP that I can tell, its that development is heavily community driven and has been since the early days. However, I think PHP got so popular, and so quickly, that in many cases the community's desire for features has led to an inconsistent, and in your view, 'broken' system. The need for backwards compatibility from almost the very beginning has taken its toll, I think. Is it really 'broken' though? Of course, similar concepts have been implemented in other languages much more elegantly. But PHP is not about elegance - it's about backwards compatibility, and responding to community feature requests.
I'm not a part of the community, and I'm no longer a PHP developer (if I can help it) but I can't think of any other reason the global functions would still have inconsistent argument orders almost 14 years on. So, if the 'correctness' of their implementation bothers you, do what I did: move on. Because it will never get any better.
Incidentally, I wrote an anti-PHP rant last year called "Why PHP Won" that made its rounds here. It's pretty easy to get fed up with PHP, especially when you know there's better stuff out there. Once you're at that point though, you're done. It's anything-else time.
My comment wasn't entirely directed only at your post. The most common complaint against PHP (and other languages, frameworks, etc.) is that it doesn't support the features or methods the programmer expects.
That said, in direct reference to your post: so what? My point still stands. I don't disagree with your assessment of the way it implements those features, I just don't think that it means "there is no hope for PHP", and I don't think it's at all productive to waste time complaining that it doesn't behave the way you want it to.
PHP -- and most other languages -- do have the power to "hack something together". You just have to be willing to adapt to the system at hand.
This is a reasonable statement.
But there's a bit of a delta between this and the attention-grabbing title of the post.
Sorry; it wasn't meant to be attention grabbing. It was more out of frustration, I suppose.
It's spelled "lambda".
Thank you for this - I'm the author of a very large PHP application that has been in development for 7 years, and it _works_. We don't use a lot of the more advanced features in PHP, since our target support is PHP 4.3.0, so this leads to some creative (i.e. fun) problems at times. PHP is as "complete" as it needs to be for us.
It reminds me of a time when I had to maintain some very large programs written 100% in AWK - talk about a limited feature set - you had to work with a more limited set of functions and features, but often led to some creative solutions.
"...our target support is PHP 4.3.0, so this leads to some creative (i.e. fun) problems at times."
"PHP is as "complete" as it needs to be for us."
It's so complete that it's painful to write in? There's something to be said for languages that focus on a particular application while peripheral features suffer, but the PHP language is in no way superior to Python or Ruby, even in regards to web development, and there's no problem with saying so.
People use PHP because lots of other people know it, and because it's widely available. Those aren't merits of the language itself. Yes, good things can be written in PHP. That doesn't mean the language isn't demonstrably inferior.
I'm guessing your definition of pain is different then mine - I don't have any issues with writing PHP - it just works for me. I've been developing in PHP since 2002, so by now I'm used to the language and how it works, and don't really have any expectations for new features.
I can see however that coming from a language like Python or Ruby, you're probably going to try to develop in PHP like you would in one of those languages - and I believe that is where frustration will be found. I think it's good to think of PHP as a "simpler" language - stick with the basics and it will work well (as well as be pretty fast).
"...our target support is PHP 4.3.0, so this leads to some creative (i.e. fun) problems at times."
"I don't have any issues with writing PHP - it just works for me."
PHP fits an important niche. People sometimes use PHP because it is faster and has a smaller memory footprint than Python or Ruby.
I was considering language features separately. If you're trying to pick a language, no one would pick PHP unless they need to work with people who already know PHP. If you're trying to pick a runtime, PHP occasionally makes sense due to ease of deployment, memory issues, etc.
There doesn't seem to be any realization on the part of the programmer that a particular language is just a tool, usually designed for a specific application. The programmer is attempting to fit a square peg into a round hole, and they're cursing at the square peg because it doesn't fit.
Ummmm, wrong! The author isn't saying "PHP sucks because it doesn't have closures like my favorite language, so it's dead to me!". The author is saying "PHP claims to support closures, but when you actually attempt to use them for anything useful, they're broken."
So what he's actually cursing is that he has a round hole, and something that looks like a round peg, except it's really not.
Maybe it was a poor choice of title, but the thrust of the article is that closures supposedly are available in the language, but the implementation is so poor as to be unusable.
Part of the problem is that once you start using closures and lambdas all over the place, it's really hard to go back to a language without them. Yes, some tools weren't meant to do some jobs, but PHP's competition has those features, and they work, and they work well. If they wanted to make a simple language without those features, fine, but that won't stop people from complaining that it doesn't have them, and it won't stop people from complaining when those features don't work the way that everyone else's versions of the features work.