Programming Community Index for July 2013: PHP is regaining ground(tiobe.com)
tiobe.com
Programming Community Index for July 2013: PHP is regaining ground
http://www.tiobe.com/index.php/content/paperinfo/tpci/index.html
66 comments
When will we stop pretending TIOBE is even remotely relevant. Do we still honestly think that there are four times as many python developers then Javascript developers or twice as many Perl developers as Ruby developers ? This is absolute rubbish
Just because Hacker News is biased toward Javascript and Ruby doesn't mean the rest of the world is.
Just forget the bias, how many alternatives are their to PHP in terms of back-end? Many : Python (Django), Ruby ( Rails ) and I think almost every major langauge has some port for Web development. Now what are the alternatives to Javascript: None. Why do you think PHP would be more popular?
There are tons of alternatives to JS if you count languages that compile to JS. Probably just as many as there are alternatives to PHP. Also, the fact that there are alternatives to PHP does not mean that they are widely used. We're in an echo chamber here, but in the real world, PHP is still the de facto language of the back end web. The LAMP stack is still the dominant setup. It's unfortunate, but it's reality.
Rails and Django are frameworks, why are you comparing them to a language? It's hardly apples to apples.
If you have socket, concurrency and string capabilities you can create web backend in anything.
Not everything revolves around the web you know. Python and perl are both heavily outside web development, something I'm not sure can be said about ruby or javascript.
Having been in the position of hiring technical people for the past 10 years I can say with a very high level of confidence either all the perl people have such nice jobs with so much security that almost none of them ever need to apply for a job, Or I can say this is a broken metric ( same thing goes for C - C++ BTW)
People will stop paying attention to TIOBE when there is a better metric. Most HN readers are probably aware of TIOBE's limitations, but it is better than nothing.
TL;DR - TIOBE is crap, bad information is worse than no information.
I agree with your first point, people will take any information over no information (for better or worse).
I highly doubt most HN readers are aware of the limitations, else they wouldn't put so high a value on it, so I don't concur with your second point.
Your final point I vehemently disagree with, bad information is worse than no information. A lie is worse than silence. Misinformation is more harmful that no information.
TIOBE is hardly anything to be taken seriously. In 2004, when Google swapped an algorithm, a bunch of TIOBE "rankings" swung massively. Back then they only used Google (the rankings are generated from search engine results, more results == better). Now they use multiple engines, but the list of issues that make it crap persist.
* Older languages like Perl, have years of postings and pages to draw from ... even if many of them are wrong with current Perl.
* Better documented languages generate less noise in terms of pages
* Languages with a higher base level developers (lisp, haskell) tend to generate less pages of noise
* The system is very easily gamed by anyone with the motivation (not sure if anyone cares)
* Communities that rally around good answers rather than repeat themselves generate less noise
Noise == Search Results == Rank
I agree with your first point, people will take any information over no information (for better or worse).
I highly doubt most HN readers are aware of the limitations, else they wouldn't put so high a value on it, so I don't concur with your second point.
Your final point I vehemently disagree with, bad information is worse than no information. A lie is worse than silence. Misinformation is more harmful that no information.
TIOBE is hardly anything to be taken seriously. In 2004, when Google swapped an algorithm, a bunch of TIOBE "rankings" swung massively. Back then they only used Google (the rankings are generated from search engine results, more results == better). Now they use multiple engines, but the list of issues that make it crap persist.
* Older languages like Perl, have years of postings and pages to draw from ... even if many of them are wrong with current Perl.
* Better documented languages generate less noise in terms of pages
* Languages with a higher base level developers (lisp, haskell) tend to generate less pages of noise
* The system is very easily gamed by anyone with the motivation (not sure if anyone cares)
* Communities that rally around good answers rather than repeat themselves generate less noise
Noise == Search Results == Rank
What do you call a javascript developer?
As most people who use javascript aren't going to be developers but merely dabblers and jQuery gluer-togetherers.
But on the whole I agree with you, just that there probably aren't that many half decent javascript developers as you think as there's not a massive demand for them (something you'll notice if you ever watch the SO javascript questions, very low quality and some of the high answerers don't really seem to understand it properly either).
I've actually been half keeping an eye out for a javascript dev job and tbh 90% of the jobs I've seen when someone asks for a front end 'developer', they're asking for a designer that can use CSS and knows basic jQuery magic. Not a developer at all in my book.
As most people who use javascript aren't going to be developers but merely dabblers and jQuery gluer-togetherers.
But on the whole I agree with you, just that there probably aren't that many half decent javascript developers as you think as there's not a massive demand for them (something you'll notice if you ever watch the SO javascript questions, very low quality and some of the high answerers don't really seem to understand it properly either).
I've actually been half keeping an eye out for a javascript dev job and tbh 90% of the jobs I've seen when someone asks for a front end 'developer', they're asking for a designer that can use CSS and knows basic jQuery magic. Not a developer at all in my book.
PHP never really went away. It's still quietly powering many, many websites out there (and not just sites running a copy of Wordpress). There are active developers making loads of projects with it still.
I think it gets a bad rap on HN because there are so many terrible PHP developers and it lends itself to allowing them to function. I work with numerous GOOD php developers and it's quite a different story then. I do find it funny that Matlab is somehow in the top-20. I mean, I've studied engineering and the curriculum used Matlab for teaching, but how many real engineering firms out there actually use Matlab??
I think it gets a bad rap on HN because there are so many terrible PHP developers and it lends itself to allowing them to function. I work with numerous GOOD php developers and it's quite a different story then. I do find it funny that Matlab is somehow in the top-20. I mean, I've studied engineering and the curriculum used Matlab for teaching, but how many real engineering firms out there actually use Matlab??
It also gets a bad rap on HN because it is just not a very good language. There are much better alternatives, and those alternatives are now really easy to use and deploy. Yes, there are good PHP developers, and they can make it work. I like to think I'm one of them. That said, if you give me the choice, I will pick almost any other language over PHP, no questions asked. It's not just warts (though there are plenty of those), the language has deep fundamental flaws.
Relevant: http://me.veekun.com/blog/2012/04/09/php-a-fractal-of-bad-de...
Relevant: http://me.veekun.com/blog/2012/04/09/php-a-fractal-of-bad-de...
>It also gets a bad rap on HN because it is just not a very good language.
It's not the language, it's the ecosystem.
All languages have imperfections.
Javascript, which does not have a "bad rap" on HN is even worse.
It's not the language, it's the ecosystem.
All languages have imperfections.
Javascript, which does not have a "bad rap" on HN is even worse.
Javascript has some really, really bad parts. It also has some very good parts. PHP has the former, but not really the latter. The most common argument made for it is that it's drop-in-and-go, so you don't have to worry about things like application servers or deployment strategies. I would argue that that's the worst thing about PHP. Languages (and frameworks, etc) are well characterized by what they make easy. PHP makes it really easy to do things really wrong.
>Javascript has some really, really bad parts. It also has some very good parts. PHP has the former, but not really the latter.
Not so sure.
PHP is equally dynamic (what with closures et al), with very good reflection style features.
It has an ACTUAL hash instead of using objects a dict.
It has better arithmetic, not the FP horror of Javascript.
It has a class system -- which is something people seem to like and desperately try to imitate in Javascript in 200 ways (very few seem to appreciate prototypical inheritance as is).
It now has generators and traits.
Generally, not that shabby.
It's greatest sin is the hodgepodge that it's standard libraries are. But, given their shortcomings and arbitrary APIs, there are quite complete, feature wise.
Not so sure.
PHP is equally dynamic (what with closures et al), with very good reflection style features.
It has an ACTUAL hash instead of using objects a dict.
It has better arithmetic, not the FP horror of Javascript.
It has a class system -- which is something people seem to like and desperately try to imitate in Javascript in 200 ways (very few seem to appreciate prototypical inheritance as is).
It now has generators and traits.
Generally, not that shabby.
It's greatest sin is the hodgepodge that it's standard libraries are. But, given their shortcomings and arbitrary APIs, there are quite complete, feature wise.
It has a class system that was bolted on after the fact, leading to tons of inconsistencies. It has "closures", but they're not proper lexical closures since you have to explicitly declare what part of the lexical scope you want your anonymous functions to have access to (rather than the interpreter figuring out the free variables like a sane implementation). Named functions can't even do that much (the fact that they're separate implementations being an indicator that they're designed poorly. Unsurprising, given anonymous functions were added post hoc). If by "good reflection style features" you mean the god-awful isset-on-every-line-of-code garbage, I'll pass, thank you. It's Turing complete and can get the job done, yes, but there's absolutely no part of it that I would call "very good". The best it ever reaches, in my experience (several years, for what little that's worth), is "doesn't quite make me want to vomit".
(Yes, I'm a bit bigoted towards PHP. I recognize that. Having to write it every day can do that to a person.)
(Yes, I'm a bit bigoted towards PHP. I recognize that. Having to write it every day can do that to a person.)
Yeah. PHP is really, really easy to get started with. This turns out to be both a blessing and a curse.
It just won't go away and always comes back - just like herpes but not as pleasant.
disclaimer - PHP developer with 3 years of experience.
disclaimer - PHP developer with 3 years of experience.
I'd consider even mentioning them in the same sentence to be an insult to herpes
(PHP developer with 9 years experience. Now thankfully using Python for new projects, but still supporting PHP legacy D: )
(PHP developer with 9 years experience. Now thankfully using Python for new projects, but still supporting PHP legacy D: )
Please link to the actual TIOBE article: http://www.tiobe.com/index.php/content/paperinfo/tpci/index....
Here's an index that is based on GitHub/StackOverflow instead of random search strings.
http://langpop.corger.nl/
(Fun fact: according to Google, there are ten times as many "C developer" than "C programming". TIOBE is somewhere between FUD and trash, stop using it.)
http://langpop.corger.nl/
(Fun fact: according to Google, there are ten times as many "C developer" than "C programming". TIOBE is somewhere between FUD and trash, stop using it.)
The RedMonk programming language rankings seem much more plausible to me. They're based on 1) questions on StackOverflow and 2) projects on GitHub.
http://redmonk.com/sogrady/2013/02/28/language-rankings-1-13...
http://redmonk.com/sogrady/2013/02/28/language-rankings-1-13...
Those are great rankings for the parts of the software development community that use Stack Overflow and GitHub. Here's a hint: those parts of the community are not representative of the community as a whole. Not even close.
I would claim the opposite. People who live in a vaccume can't very well be said to be part of a community.
I actually felt a bit weird using the word community and considered changing it to something else. Really though, just because they aren't part of SO or GitHub doesn't mean they live in a vacuum. There are tons of other focal points for developers on the web, and that's not even considering local user groups and meetups, etc.
There is a reason why php is climbing the list, because how anyone can learn this language and for a beginner because they will learn server-side scripting from the get go with MySQL and this is great for transitioning to other languages that do magical wonders like Ruby ( on Rails ) but it would be cumbersome to understand how this works without really understanding under the hood which PHP will show you and when you move on to an elegant language you will appreciate pythons beauty if you have done PHP.
[deleted]
I find it humbling to look at these lists and see what most people do. At work we have had the occasional debate about Scala versus Clojure. I was for Clojure and I mostly lost (I didn't convince anyone).
Perhaps mistakenly, I thought we were arguing about one of the big issues facing the tech world right now. What is the correct way to move forward in our new, functional, multi-core world?
Then I look TIOBE. Scala is in 33rd place with a 0.326% share.
Clojure is not even listed -- it might as well not exist.
Lists like this remind me how easy it is to think that the thing you are excited about also has other people excited. But that is not necessarily the case.
I've been using PHP since early 2000, when PHP 4.0 was still in beta. For awhile I loved PHP. It was my main language for most of 10 years. But the world has changed. I find it amazing that anyone would still use PHP for a project, given the wealth of great alternatives that have sprung up.
Let's go back in time. Here is what the world looked like in the spring of 2000: I want to build a dynamic website. What should I use? I wanted to use open source so that ruled out Microsoft and ASP. I could use Perl, but Perl took assembly -- every module I could want was in CPAN but you had to know them and understand them and it was a bit of a hassle to assemble them (there was nothing quite as easy as modern package managers). Java seemed like overkill. The people who loved Java were, at that time, very focused on the enterprise and they were loudly promoting the benefits of the Struts framework (which in the end turned out to be overkill for every single type of application that anyone could ever actually want to build). And Java needed to be compiled, and there were none of the tools then that make life so much easier now. And when debugging the stack traces were fearsome. Then there was PHP. It was simple and it was all in one. No assembly required -- a huge built in library. No need to compile, just edit a text file and then hit "reload" in your browser to see the change. When debugging, the error messages were crystal clear and always told you what line, in which file, needed to be fixed.
PHP was an obvious choice then.
But things changed.
In 2004, Basecamp was launched, and the world noticed Ruby On Rails. (Bruce Eckel wrote a great essay at the time about how this effected the thinking of a certain portion of elite programmers: http://www.artima.com/weblogs/viewpost.jsp?thread=141312 )
Starting around 2005 there was a revolution happening in the land of the Java Virtual Machine. Dozens of innovative new languages sprang up (among the ones I worked with and admire: Groovy, Scala, Clojure). The tools improved dramatically: for debugging and profiling, Java had long had the edge, and now you could use those same tools with dynamic languages that were fun to work with. Modern package managers arrived, which made it easy to assemble libraries, and greatly reduced the benefit of PHP's all-in-one approach.
Many of the new languages offer a REPL to make it easy to play with the language and assemble the code in a live environment -- this is even more interactive than the fast edit/reload cycle that made PHP seem so special in 2000.
Meanwhile, PHP was going the other direction, towards more complexity. There was clearly a desire on the part of the core PHP team to imitate aspects of Java. I now work at a company that has a large CMS built with Symfony -- this is a very large code base full of classes that have what I would think of as "classic" OOP features such as variables with limited visibility outside of the class. This is not a bad thing, but please note, PHP is now, in 2013, the only language that I work with that gives me no way to automatically create getters and setters for class variables. (Some of you will say Symfony has tools that will auto-generate these classes for me, which is true, and if you like having your code auto-generated from other sources, like YAML files, then of course this is a fine approach.)
What drew me to PHP, in 2000, was its flexibility, ease of debugging, ease of assembly (all-in-one philosophy) and the fast edit/reload cycle. It's important to note that PHP is no longer the leader of the pack in any of these dimensions. All of the same considerations that drew me to PHP in 2000 now draw me to Clojure -- its a dynamic language that does not get in my way, debugging is easy thanks to many debugging tools, assembly of parts is easy thanks to Leiningen, which is an amazing build tool, and the fast edit/reload cycle is replaced by the even better REPL experience.
What draws people to PHP now? I loved it once but I can not imagine choosing it now.
Perhaps mistakenly, I thought we were arguing about one of the big issues facing the tech world right now. What is the correct way to move forward in our new, functional, multi-core world?
Then I look TIOBE. Scala is in 33rd place with a 0.326% share.
Clojure is not even listed -- it might as well not exist.
Lists like this remind me how easy it is to think that the thing you are excited about also has other people excited. But that is not necessarily the case.
I've been using PHP since early 2000, when PHP 4.0 was still in beta. For awhile I loved PHP. It was my main language for most of 10 years. But the world has changed. I find it amazing that anyone would still use PHP for a project, given the wealth of great alternatives that have sprung up.
Let's go back in time. Here is what the world looked like in the spring of 2000: I want to build a dynamic website. What should I use? I wanted to use open source so that ruled out Microsoft and ASP. I could use Perl, but Perl took assembly -- every module I could want was in CPAN but you had to know them and understand them and it was a bit of a hassle to assemble them (there was nothing quite as easy as modern package managers). Java seemed like overkill. The people who loved Java were, at that time, very focused on the enterprise and they were loudly promoting the benefits of the Struts framework (which in the end turned out to be overkill for every single type of application that anyone could ever actually want to build). And Java needed to be compiled, and there were none of the tools then that make life so much easier now. And when debugging the stack traces were fearsome. Then there was PHP. It was simple and it was all in one. No assembly required -- a huge built in library. No need to compile, just edit a text file and then hit "reload" in your browser to see the change. When debugging, the error messages were crystal clear and always told you what line, in which file, needed to be fixed.
PHP was an obvious choice then.
But things changed.
In 2004, Basecamp was launched, and the world noticed Ruby On Rails. (Bruce Eckel wrote a great essay at the time about how this effected the thinking of a certain portion of elite programmers: http://www.artima.com/weblogs/viewpost.jsp?thread=141312 )
Starting around 2005 there was a revolution happening in the land of the Java Virtual Machine. Dozens of innovative new languages sprang up (among the ones I worked with and admire: Groovy, Scala, Clojure). The tools improved dramatically: for debugging and profiling, Java had long had the edge, and now you could use those same tools with dynamic languages that were fun to work with. Modern package managers arrived, which made it easy to assemble libraries, and greatly reduced the benefit of PHP's all-in-one approach.
Many of the new languages offer a REPL to make it easy to play with the language and assemble the code in a live environment -- this is even more interactive than the fast edit/reload cycle that made PHP seem so special in 2000.
Meanwhile, PHP was going the other direction, towards more complexity. There was clearly a desire on the part of the core PHP team to imitate aspects of Java. I now work at a company that has a large CMS built with Symfony -- this is a very large code base full of classes that have what I would think of as "classic" OOP features such as variables with limited visibility outside of the class. This is not a bad thing, but please note, PHP is now, in 2013, the only language that I work with that gives me no way to automatically create getters and setters for class variables. (Some of you will say Symfony has tools that will auto-generate these classes for me, which is true, and if you like having your code auto-generated from other sources, like YAML files, then of course this is a fine approach.)
What drew me to PHP, in 2000, was its flexibility, ease of debugging, ease of assembly (all-in-one philosophy) and the fast edit/reload cycle. It's important to note that PHP is no longer the leader of the pack in any of these dimensions. All of the same considerations that drew me to PHP in 2000 now draw me to Clojure -- its a dynamic language that does not get in my way, debugging is easy thanks to many debugging tools, assembly of parts is easy thanks to Leiningen, which is an amazing build tool, and the fast edit/reload cycle is replaced by the even better REPL experience.
What draws people to PHP now? I loved it once but I can not imagine choosing it now.
> What draws people to PHP now?
PHP is easily and inexpensively deployed on commodity hosting.
PHP has a large base of existing code that can be re-used and built upon.
PHP has a large base of existing documentation that can be learned to get up to speed on it.
PHP has a large base of existing developers whose knowledge can be tapped into via services like StackExchange.
Most of these advantages aren't really intrinsic to PHP-the-language so much as they are to PHP's position in the marketplace. PHP is popular because it's easy to deploy, but it's also easy to deploy because it's popular -- hosts and admins are willing to put work into supporting PHP that they're less willing to put into supporting languages with smaller user bases, because the upside for doing so is so much bigger. But that doesn't mean they're not advantages.
On the plus side, PHP-the-language has gotten a lot better and more pleasant to use over the last few years. It's still got warts, as you note, but it's a long way from the incoherent grab bag of functions that it started out as. And while it's definitely possible to architecture-astronaut it (cough Symfony cough), it's also possible in PHP 5 to write reasonable clean, modern-feeling code without having to jump through a gazillion flaming hoops.
PHP is easily and inexpensively deployed on commodity hosting.
PHP has a large base of existing code that can be re-used and built upon.
PHP has a large base of existing documentation that can be learned to get up to speed on it.
PHP has a large base of existing developers whose knowledge can be tapped into via services like StackExchange.
Most of these advantages aren't really intrinsic to PHP-the-language so much as they are to PHP's position in the marketplace. PHP is popular because it's easy to deploy, but it's also easy to deploy because it's popular -- hosts and admins are willing to put work into supporting PHP that they're less willing to put into supporting languages with smaller user bases, because the upside for doing so is so much bigger. But that doesn't mean they're not advantages.
On the plus side, PHP-the-language has gotten a lot better and more pleasant to use over the last few years. It's still got warts, as you note, but it's a long way from the incoherent grab bag of functions that it started out as. And while it's definitely possible to architecture-astronaut it (cough Symfony cough), it's also possible in PHP 5 to write reasonable clean, modern-feeling code without having to jump through a gazillion flaming hoops.
>PHP is easily and inexpensively deployed on commodity hosting.
So is everything else now that dirt cheap VMs are the norm.
>PHP has a large base of existing documentation that can be learned to get up to speed on it.
Much of which is wrong or even dangerous.
>PHP has a large base of existing developers whose knowledge
A large number of developers, but most of them possess a shockingly small amount of knowledge.
So is everything else now that dirt cheap VMs are the norm.
>PHP has a large base of existing documentation that can be learned to get up to speed on it.
Much of which is wrong or even dangerous.
>PHP has a large base of existing developers whose knowledge
A large number of developers, but most of them possess a shockingly small amount of knowledge.
>>PHP is easily and inexpensively deployed on commodity hosting.
So is everything else now that dirt cheap VMs are the norm.
Not easy enough for most people.
>Much of which is wrong or even dangerous.
If it stupid and it works, it ain't stupid.
>A large number of developers, but most of them possess a shockingly small amount of knowledge.
The 10% of people with the vast knowledge are not going to write the 100% of the software, so the people with "small amount of knowledge" will still be there.
Just like you don't just have Picassos but also regular painters.
Not easy enough for most people.
>Much of which is wrong or even dangerous.
If it stupid and it works, it ain't stupid.
>A large number of developers, but most of them possess a shockingly small amount of knowledge.
The 10% of people with the vast knowledge are not going to write the 100% of the software, so the people with "small amount of knowledge" will still be there.
Just like you don't just have Picassos but also regular painters.
Your reply contains nothing of substance, and very little that is even of relevance.
Em, considering that this comment of yours is just a blanket accusation, without any arguments at all, whereas I replied to the parent point by point, the proverb "people living in glasshouses", etc comes to mind.
I, for one, in my comment:
1) reminded that the availability of "dirt cheap VMs" doesn't make PHP installation any easier compared to a hosting provider (just drop PHP files into folder -- or just select a PHP app to be installed from a Web panel).
2) Having lots of documentation is a benefit, even if "much of it is wrong" in some way. It it works, people will use it, be it wrong or not, and they will get bootstrapped enough with their app to eventually replace it with something better. If we demanded near perfection from everyone, the web would be 1/1000 the size -- it's the ability to also have "wrong" stuff work that made it huge.
3) That "most of PHP developers posses shockingly small amount of knowledge" is not against but in favour of the language. Those people also need to get something done, and if they can achieve that with PHP, more power to them.
The complaints are elitist cries, that only some deeply knowledgable programmers should be allowed to code stuff for the web.
I find the possibility of somebody with limited knowledge writing a webpage or even a webapp in PHP empowering. And if you don't like to consider my opinion, ask Derek Shivers.
I, for one, in my comment:
1) reminded that the availability of "dirt cheap VMs" doesn't make PHP installation any easier compared to a hosting provider (just drop PHP files into folder -- or just select a PHP app to be installed from a Web panel).
2) Having lots of documentation is a benefit, even if "much of it is wrong" in some way. It it works, people will use it, be it wrong or not, and they will get bootstrapped enough with their app to eventually replace it with something better. If we demanded near perfection from everyone, the web would be 1/1000 the size -- it's the ability to also have "wrong" stuff work that made it huge.
3) That "most of PHP developers posses shockingly small amount of knowledge" is not against but in favour of the language. Those people also need to get something done, and if they can achieve that with PHP, more power to them.
The complaints are elitist cries, that only some deeply knowledgable programmers should be allowed to code stuff for the web.
I find the possibility of somebody with limited knowledge writing a webpage or even a webapp in PHP empowering. And if you don't like to consider my opinion, ask Derek Shivers.
> "dirt cheap VMs" doesn't make PHP installation
> any easier compared to a hosting provider
This is easy, even for a beginner:
yum install java-1.6.0-openjdk-devel
Consider the effort that a PHP developer has to put into editing the vhost of the Apache config. And usually the php.ini file needs to be tweaked. And often there is an .htaccess file with a few mod_rewrite rules (think of WordPress, Drupal, etc) There might easily be a solid 30 minutes of configuration to get PHP/Apache set up to run the way you want it to run.
If I want to use Clojure? I use "yum install" to be sure the server has a functioning JVM. Then I usually set my routes using Compojure, the syntax of which is certainly easier than Apache mod_rewrite. And then for the server I often simply go with Jetty, which is a 1 line dependency, and I bundle it all up with "lein uberjar".
This is the point that I made above: in the spring of 2000, PHP was the easiest thing available to me. That is why I used it. But the world has changed, and now there are other options that are at least as easy. "Ease of setup" was a very strong argument in favor of PHP in the spring of 2000, but it is not a good argument now. There ecosystems, such as the Clojure ecosystem, that offer setups that are at least as easy as configuring Apache and PHP.
> any easier compared to a hosting provider
This is easy, even for a beginner:
yum install java-1.6.0-openjdk-devel
Consider the effort that a PHP developer has to put into editing the vhost of the Apache config. And usually the php.ini file needs to be tweaked. And often there is an .htaccess file with a few mod_rewrite rules (think of WordPress, Drupal, etc) There might easily be a solid 30 minutes of configuration to get PHP/Apache set up to run the way you want it to run.
If I want to use Clojure? I use "yum install" to be sure the server has a functioning JVM. Then I usually set my routes using Compojure, the syntax of which is certainly easier than Apache mod_rewrite. And then for the server I often simply go with Jetty, which is a 1 line dependency, and I bundle it all up with "lein uberjar".
This is the point that I made above: in the spring of 2000, PHP was the easiest thing available to me. That is why I used it. But the world has changed, and now there are other options that are at least as easy. "Ease of setup" was a very strong argument in favor of PHP in the spring of 2000, but it is not a good argument now. There ecosystems, such as the Clojure ecosystem, that offer setups that are at least as easy as configuring Apache and PHP.
Virtual hosts in Apache? mod_rewrite? Your understanding of modern PHP development really is circa 2000. Try replacing those with nginx and PHP-FPM for a start.
I know a lot of programming languages due to the range of work that I do. I've done C++, Java, Perl, and a large amount of PHP starting from PHP 3.0 until 5.1-ish.
I'm currently doing C# on Windows most of my days.
I'm about to start a new project that's a re-write of an old but still very popular PHP 4.0 site and I'm going to use PHP (probably the just released 5.5). The main reason is that I have limited time to learn another language/platform and PHP just isn't that bad. My PHP code looks extremely similar to my code in just about every other language I use. I have great IDE (phpstorm). I'm familiar with the gotchas and avoid them and I'm familiar with the advantages and I exploit them. I intend to keep things relatively simple while taking advantage of all the modern language features currently in PHP (closures, traits, generators, etc).
> PHP is now, in 2013, the only language that I work with that gives me no way to automatically create getters and setters for class variables.
That's actually pretty easy in PHP using the get and set magic methods. In my code, any method that starts with the word "get" or "set" can be accessed as a property. With traits, you can apply that code anywhere.
I'm about to start a new project that's a re-write of an old but still very popular PHP 4.0 site and I'm going to use PHP (probably the just released 5.5). The main reason is that I have limited time to learn another language/platform and PHP just isn't that bad. My PHP code looks extremely similar to my code in just about every other language I use. I have great IDE (phpstorm). I'm familiar with the gotchas and avoid them and I'm familiar with the advantages and I exploit them. I intend to keep things relatively simple while taking advantage of all the modern language features currently in PHP (closures, traits, generators, etc).
> PHP is now, in 2013, the only language that I work with that gives me no way to automatically create getters and setters for class variables.
That's actually pretty easy in PHP using the get and set magic methods. In my code, any method that starts with the word "get" or "set" can be accessed as a property. With traits, you can apply that code anywhere.
Great post, I have also thought quite a bit about the fact that the big issues I spend time considering aren't even on the radar of the majority of developers, let alone the majority of humans.
To answer your question about PHP: I think you're phrasing the question in a way that makes it seem more confusing than it really is. People aren't, generally speaking, drawn to PHP. People code in PHP, and have been coding in PHP, and change is hard, and rationalizing the familiar is easy. Those people then hire other people, and train them to use PHP. I would wager that for a majority of PHP projects, there was never even a 'choose what language to use' phase in the planning.
Edit: Another reason that I forgot to mention, which I've seen used several times in practice — PHP developers are replaceable. It's the same argument pointy-haired bosses have been making for using Java for a long time now.
To answer your question about PHP: I think you're phrasing the question in a way that makes it seem more confusing than it really is. People aren't, generally speaking, drawn to PHP. People code in PHP, and have been coding in PHP, and change is hard, and rationalizing the familiar is easy. Those people then hire other people, and train them to use PHP. I would wager that for a majority of PHP projects, there was never even a 'choose what language to use' phase in the planning.
Edit: Another reason that I forgot to mention, which I've seen used several times in practice — PHP developers are replaceable. It's the same argument pointy-haired bosses have been making for using Java for a long time now.
> I would wager that for a majority of PHP projects, there was never even a 'choose what language to use' phase in the planning.
And if the language you know does what you want, why would there be?
Most code is written for business, and in business bringing in a new language is like re-tooling a factory: an expense you take on when you have to, not something you do just because you can.
And if the language you know does what you want, why would there be?
Most code is written for business, and in business bringing in a new language is like re-tooling a factory: an expense you take on when you have to, not something you do just because you can.
That's fine, and I don't think that using PHP for a project is necessarily a bad decision. That said, there are a lot of factors to consider. PHP developers and say, Ruby or Python developers are generally rather different types of people. You'll get a lot more exposure to new ideas and practices from the latter. Unit testing is still a 'weird new thing' in the PHP community, at least where I'm living. If you aren't even considering what language to use, you're going to miss out on a lot of potential benefits.
Further, the cost is not on par with re-tooling a factory. Any competent developer can switch languages, especially between very similar languages like PHP/Python/Ruby/Perl, in a pretty quick window. Learning the tools that go along with that language does take some time, but I think that amount of time is generally overstated.
Further, the cost is not on par with re-tooling a factory. Any competent developer can switch languages, especially between very similar languages like PHP/Python/Ruby/Perl, in a pretty quick window. Learning the tools that go along with that language does take some time, but I think that amount of time is generally overstated.
PHP developers and say, Ruby or Python developers are generally rather different types of people
Any competent developer can switch languages, especially between very similar languages like PHP/Python/Ruby
Those two statements are contradictory. My own stance is that it's rude to stereotype anyone as a 'PHP developer' and infer that, in some way, that means they're 'different' from a Ruby developer.
Any competent developer can switch languages, especially between very similar languages like PHP/Python/Ruby
Those two statements are contradictory. My own stance is that it's rude to stereotype anyone as a 'PHP developer' and infer that, in some way, that means they're 'different' from a Ruby developer.
They're not contradictory at all. People who present themselves as PHP developers tend to have a set of common differences from people who present themselves as Ruby or Python developers. That doesn't mean that the competent among both groups are incapable of quickly switching languages. It might mean that the percentage of competent developers is different between the two groups. It's basically the Dead Sea Effect[1], but with languages. Generally better developers will want to use better languages. That shouldn't be surprising. Hopefully we don't have to rehash the argument about the fact that some languages are better than others, since we're on HN and pg has covered that point in great depth.
[1] http://brucefwebster.com/2008/04/11/the-wetware-crisis-the-d...
[1] http://brucefwebster.com/2008/04/11/the-wetware-crisis-the-d...
> What draws people to PHP now? I loved it once but I can not imagine choosing it now.
I choose it regularly, although to be fair I also do web projects in Ruby on Rails or Node.js. To me there is no inherent reason not to choose PHP if the nature of the project fits it, it often allows me to get stuff done very quickly, with very little code, and (this might be surprising to some) elegantly.
PHP's per-request execution model is a strength that is often overlooked by people who are mostly using persistent application servers. Starting with a clean environment at every request can be a huge advantage, especially in large projects where PHP allows you to selectively load only what you need. This can be used to severely limit code complexity and unexpected runtime behavior (in addition to the more obvious points such as better resource management).
Language-wise I wouldn't say PHP syntax is pretty, and the standard library is very uneven. There's also some weirdness with the parser that should be fixed. I hope there'll be a reboot that addresses these, but sadly this would probably not come from the PHP core devs. At the same time, "recent" language features have made developing in PHP fun again. For example, I couldn't imagine doing PHP without anonymous functions.
On the flip side, some OO features are superfluous to the point of being a liability. Also, and this is me departing from the party line even further here, framework envy has bogged down PHP by zapping its strengths and unreasonably emphasizing its weaknesses. With the exception of light-weight MVC frameworks, more heavy-handed RoR "clones" and object-relational silliness tends to kill performance and severely hinders developer flexibility. Of course, some newbie developers probably should be prevented from exercising flexibility, but I'd argue that PHP isn't suitable for them in the first place.
You said that PHP is going toward increasing complexity, but I'd argue that this is more due to the proliferation of complexity in its ecosystem - which ultimately comes from importing unsound ideas from other languages just for the sake of making PHP development seem hip and legit by (badly) emulating counterproductive features. Again, this might be unpopular, but for example: why should a PHP app use a templating engine when PHP itself is one? I can see this is justified when unprivileged users are editing the templates, but this case can't possibly account for all the Smarty (and worse) misuse that is happening all over.
People like to switch between languages and frameworks as if nothing changed, but I'd say they're wrong. Building stuff in Node.js is fundamentally different from Rails, which is fundamentally different from PHP. Use the right tool for the job, don't bend runtimes to do something they're unsuited for.
I choose it regularly, although to be fair I also do web projects in Ruby on Rails or Node.js. To me there is no inherent reason not to choose PHP if the nature of the project fits it, it often allows me to get stuff done very quickly, with very little code, and (this might be surprising to some) elegantly.
PHP's per-request execution model is a strength that is often overlooked by people who are mostly using persistent application servers. Starting with a clean environment at every request can be a huge advantage, especially in large projects where PHP allows you to selectively load only what you need. This can be used to severely limit code complexity and unexpected runtime behavior (in addition to the more obvious points such as better resource management).
Language-wise I wouldn't say PHP syntax is pretty, and the standard library is very uneven. There's also some weirdness with the parser that should be fixed. I hope there'll be a reboot that addresses these, but sadly this would probably not come from the PHP core devs. At the same time, "recent" language features have made developing in PHP fun again. For example, I couldn't imagine doing PHP without anonymous functions.
On the flip side, some OO features are superfluous to the point of being a liability. Also, and this is me departing from the party line even further here, framework envy has bogged down PHP by zapping its strengths and unreasonably emphasizing its weaknesses. With the exception of light-weight MVC frameworks, more heavy-handed RoR "clones" and object-relational silliness tends to kill performance and severely hinders developer flexibility. Of course, some newbie developers probably should be prevented from exercising flexibility, but I'd argue that PHP isn't suitable for them in the first place.
You said that PHP is going toward increasing complexity, but I'd argue that this is more due to the proliferation of complexity in its ecosystem - which ultimately comes from importing unsound ideas from other languages just for the sake of making PHP development seem hip and legit by (badly) emulating counterproductive features. Again, this might be unpopular, but for example: why should a PHP app use a templating engine when PHP itself is one? I can see this is justified when unprivileged users are editing the templates, but this case can't possibly account for all the Smarty (and worse) misuse that is happening all over.
People like to switch between languages and frameworks as if nothing changed, but I'd say they're wrong. Building stuff in Node.js is fundamentally different from Rails, which is fundamentally different from PHP. Use the right tool for the job, don't bend runtimes to do something they're unsuited for.
why should a PHP app use a templating engine when PHP itself is one?
It's just cleaner, and makes it easier, visually, to separate layout from code. Wordpress seems to be a good example of the opposite case -- it switches directly between PHP and html and there are no 'templates' to speak of, in the way Smarty/Twig etc. people would think of them. It is 'closer to the metal' I guess but also for anyone who's had to edit a theme, really ugly.
Personally I find just not having to worry about context with opening and closing PHP tags and echoing variables (and manually escaping everything) worth the extra bit of abstraction involved with a templating system, which will do the work for me.
It's just cleaner, and makes it easier, visually, to separate layout from code. Wordpress seems to be a good example of the opposite case -- it switches directly between PHP and html and there are no 'templates' to speak of, in the way Smarty/Twig etc. people would think of them. It is 'closer to the metal' I guess but also for anyone who's had to edit a theme, really ugly.
Personally I find just not having to worry about context with opening and closing PHP tags and echoing variables (and manually escaping everything) worth the extra bit of abstraction involved with a templating system, which will do the work for me.
> It's just cleaner, and makes it easier, visually, to separate layout from code.
That's true, and I think PHP would be better for it if there were three kinds of files by convention: pure code, layout, and entry points that are actually callable (the other two shouldn't be invokable by typing in their URL). It's trivial to configure a webserver to handle them differently, but it's impossible if you're writing code that needs to run everywhere.
However, I would not say that {$blah} is that much more readable than <?= $blah ?>, not to the extent that the complexity and cost of running a separate engine is justified.
That's true, and I think PHP would be better for it if there were three kinds of files by convention: pure code, layout, and entry points that are actually callable (the other two shouldn't be invokable by typing in their URL). It's trivial to configure a webserver to handle them differently, but it's impossible if you're writing code that needs to run everywhere.
However, I would not say that {$blah} is that much more readable than <?= $blah ?>, not to the extent that the complexity and cost of running a separate engine is justified.
Depending on how the code is structured, it might not matter much either way in terms of legibility (assuming the sight of something like
Then again I never use the short tags so i'm adding at least those three characters of overhead per variable anyway. Also, having the views inline couples them to whatever logic they happen to be in, so the templates are less portable. A lot of templating engines will meet you halfway and compile down to classes so they don't reinterpret the templates each time. YMMV I guess.
if($foo){
?>
<b> <?php echo $bar; ?></b>
<?php
}
Then again I never use the short tags so i'm adding at least those three characters of overhead per variable anyway. Also, having the views inline couples them to whatever logic they happen to be in, so the templates are less portable. A lot of templating engines will meet you halfway and compile down to classes so they don't reinterpret the templates each time. YMMV I guess.
Yes, but if you're using short tags, things can be better ;)
Re-interpreting templates is also an interesting case. Of course, native templates will pretty much always be faster so the need to cache isn't as pressing. But still, with the built-in output buffer functions it's easy to do something like
<? if($foo) { ?>
<b><?= $bar ?></b>
<? } ?>
Re-interpreting templates is also an interesting case. Of course, native templates will pretty much always be faster so the need to cache isn't as pressing. But still, with the built-in output buffer functions it's easy to do something like
do_some_caching(function() {
include('sometemplate');
});I was playing around with Slim framework recently and I 'discovered' the option in the PDO driver to fetch into a class. Add a parent class to the data classes (with magic setters and getters, having the getter wrap everything in htmlspecialchars)[1] and you really can, probably, accomplish most of what a lot of templating systems do (and a good chunk of MVC with the serial numbers filed off) with a fraction of the code in most frameworks and, say, Twig.
Even static caching probably, using output buffering.
[1]http://stackoverflow.com/questions/8898794/using-pdofetch-cl...
Even static caching probably, using output buffering.
[1]http://stackoverflow.com/questions/8898794/using-pdofetch-cl...
> PHP's per-request execution model is a strength that is often overlooked by people who are mostly using persistent application servers.
You nailed it. AKA "Shared Nothing Architecture".
You nailed it. AKA "Shared Nothing Architecture".
Node.js is notably absent.
JavaScript is listed there, though I don't understand it's relatively low ranking given that virtually every website uses it.
Having Google Analytics on a website does not make the people working on that website JavaScript developers. For many projects, JavaScript is tacked on, usually via a designer doing some tricks in jQuery.
A puzzling list in general; there are surely more Ruby and JavaScript developers than there are Perl and Visual Basic.
Github's trends offer a different viewpoint: https://github.com/languages/
Github's trends offer a different viewpoint: https://github.com/languages/
A puzzling list in general;
It's TIOBE. This is to be expected.
http://www.tiobe.com/index.php/content/paperinfo/tpci/tpci_d...
http://developers.slashdot.org/comments.pl?sid=3364265&cid=4...
It's TIOBE. This is to be expected.
http://www.tiobe.com/index.php/content/paperinfo/tpci/tpci_d...
http://developers.slashdot.org/comments.pl?sid=3364265&cid=4...
Github's numbers are going to be biased towards programmers who use languages that are more progressive. .NET developers aren't using Github and neither are many older companies that are still using self-hosted SVN and CVS repos.
".NET developers aren't using Github" says who? I find about 80% of open source projects for .Net on Github. With the other 20% being split between codeplex, sourceforge, Google Code, and self-hosting/publishing
Open source is the keyword.
Most corporations would faint just with the idea of hosting their code outside premises.
Most corporations would faint just with the idea of hosting their code outside premises.
[deleted]
Yep. My company is using a throw back gem(Visual Source Safe) to host our VB6 apps written in '98.
Github only lists a very tiny portion of all software that gets developed in the world.
Actually I would say HN and Github communities tend to certain extent to overlap.
Actually I would say HN and Github communities tend to certain extent to overlap.
Let's define "virtually." There are plenty of websites that don't use JS.
Just about every website uses JS in some way. Even Google analytics (or other analytics scripts) being on the page means they're technically using JS.
But doesn't mean they have JS developers.
C'mon Actionscript!