
A Look at PHP's Continuing Evolution - geerlingguy
https://www.acquia.com/blog/look-phps-continuing-evolution
======
jmadsen
This article is important because there are still so many people who talk
about how bad PHP is, based on their knowledge of some version from years ago.

There was (another) recent Ruby vs. PHP Bashfest some months ago that was
essentially:

"PHP sucks. It can't do X...oh, it can? Well, it can't do Y...oh, it has been
able to since 3 major release ago..well, it can't..."

PHP is far different than you probably think it is. I also can't help but feel
that a huge number of they people who naysay it are only parroting things they
don't even understand - I rarely hear them explain precisely why such and such
quirk in the language is bad for programming

~~~
jonahx
To give a serious answer to this: While you are right that php bashing isn't
always rooted in informed objectivity, the point you're making is missing
something deeper.

It's sort of like when that person with a crush on you who you just don't like
but who insists that if you really got to know them everything would be
different. It's just not true.

Even if could prove a 1 to 1 correspondence between features of ruby and php,
php would still be... ugly. It would still lack grace. The feeling of looking
at a page of php code just wouldn't be as pleasing. I believe it is this raw,
irrational difference, this visceral reaction to the physicality of the code,
and not a misunderstanding of features (even if they are misunderstood) that
accounts for the most of the hate you allude to.

~~~
smsm42
I personally think if you have raw, irrational, visceral reaction to
programming languages, there's some priorities problem here. Those are tools.
You're supposed to use them, not fall in deep emotional love (or hate) with
them, that's what you do with people, not tools. I know this opinion may be
unpopular and I know people do fall in love with tools (and use people) but I
think they're doing it all wrong.

~~~
eevee
Tools should be designed to fit with humans; the goal is to minimize how much
humans have to contort themselves to fit their tools.

There'll always be some degree of learning and adjusting. But a mallet is
still an improvement over a rock, because it's designed to fit in a human
hand. I doubt anyone scoffed at the mallet and blogged that rocks have 80%
market share so why can't we just get over it already.

~~~
smsm42
That's fine. People have different needs and preferences. Some drive Honda
Accord, some drive BMW convertible and some drive GMC truck. It's just looks a
little silly when Accord driver comes out and starts pronouncing that trucks
are absolutely useless and he has deep visceral hate with anything that ugly
stupid space at the back that nobody ever needs and millions of people that
buy trucks are actually idiots just incapable of driving a clearly superior
Accord.

~~~
eevee
I'm not sure how to reconcile this analogy with the existence of government
programs (carpool lanes, tax incentives for hybrids) that encourage the use of
more efficient cars with more people in them, on the grounds that it's better
overall for the ecosystem.

~~~
smsm42
I sincerely hope you don't imply you'd like government coercion to be used on
people "for their own good" when they choose what tool to use for their
purposes. Or for the government bureaucrats to select winners in software
world and facilitate wealth transfer from actually popular tools to those that
are only viable as beneficiaries of government coercion.

~~~
vectorpush
I think his point is that the truck analogy doesn't favor PHP when he
considers that society has made an effort to reduce the use of trucks due to
their general inefficiency compared to sedans.

I think the analogy fails because trucks and sedans are different tools for
different purposes (one is better for transporting people, one is better for
transporting cargo), while PHP and Ruby pretty much do the same thing, one is
just prettier and streamlined.

~~~
smsm42
>>> while PHP and Ruby pretty much do the same thing

Says who?

>>> one is just prettier and streamlined.

By which objective measure of "prettier" and "streamlined"?

~~~
vectorpush
_Says who?_

Says the fact that PHP and Ruby are both object oriented imperative scripting
languages that are commonly used for connecting to a DB and spitting out
markup. It's impossible to shove a refrigerator into the back of a sedan, but
there is no analogous refrigerator that PHP _xor_ Ruby is incapable of
hauling.

 _By which objective measure of "prettier" and "streamlined"?_

Well it is subjective, but the nebulous consensus is that Ruby has a cleaner
and more readable syntax than PHP.

~~~
smsm42
Any Turing-complete language can do any computational task that is computable
by Turing-complete languages, so by that criteria every language is the same.
Obviously, in practice they are not.

>>> Well it is subjective, but the nebulous consensus is that Ruby has a
cleaner and more readable syntax than PHP.

Consensus of whom? "Nobody I know voted for him", right?

~~~
vectorpush
_Any Turing-complete language can do any computational task that is computable
by Turing-complete languages, so by that criteria every language is the same.
Obviously, in practice they are not._

That's a straw man, I didn't use that as a criteria.

 _PHP and Ruby are both object oriented imperative scripting languages that
are commonly used for connecting to a DB and spitting out markup_

See that? That's me describing specific qualities of the languages that make
them similar. Of course, you could use Ruby or PHP to write a graphics engine
(in fact, I have done so with Ruby), but that is not a common use case. Most
of the time, Ruby and PHP are used to solve the same set of problems:
scripting server-side logic for the web.

 _Consensus of whom?_

The internet? The programming community? That's why I used the "nebulous"
qualifier. I'm not saying it's a fact, but it's a pretty popular sentiment
which is about as solid as it gets with regard to matters of taste.

Yes, PHP and Ruby are different, but _most of the time_ they are used to do
the same thing.

~~~
smsm42
>>> That's me describing specific qualities of the languages that make them
similar.

Yes, they are both imperative, non-compiled and can be used to do network
connections and output texts. Doesn't really narrow it down. Any further
restriction (like narrowing network connections to DBs and texts to HTML or
any other specific markup language) just makes it false.

>>> scripting server-side logic for the web

That's closer, but so do tons of other languages.

>>> The internet? The programming community?

See, I just talked to the internet and she says she never told you that.

>>> it's a pretty popular sentiment

Among your friends? I certainly can believe that.

>>> as solid as it gets with regard to matters of taste

Absolutely no problem with taste. The problem comes when somebody tries to
declare his taste to be an objective truth.

------
jimparkins
"That 80% marketshare is not going anywhere anytime soon."

>> I have seen this mentioned many times before, and also worked in PHP
development teams. However I think this statement is confusing. There is no
way that php _development_ or _programming_ is 80% of the market. I suspect
that when you crawl round the internet a lot of spam blogs and advertising
content is based off of php based CMS like Wordpress and Drupal - because it
is so easy to get a generic template driven website up and running with a good
SEO basis. I can believe 80% of the websites that return content could be PHP
based.

~~~
eevee
This is maybe the third comment about whether the 80% is lies, damned lies, or
statistics.

I would much rather see a conversation about how other languages can bridge
the gaps of "hello world in a browser isn't obvious" and "deployment is hard".
Those are important and useful things to do, regardless of PHP's market share.

~~~
nine_k
I thought Ruby has all but bridged it?

~~~
eevee
With what? Rails? Doesn't that require generating a whole "project" (whatever
that is) with a bunch of directories and files and then figuring out where
everything is and...

PHP requires opening index.php and typing "hello world". Obviously that's not
going to work anywhere else, but something like Flask (or Sinatra) is much
closer.

Deployment, maybe. The biggest stumbling block is that no matter how magical a
deployment solution anyone invents, it's worthless unless there are free/cheap
hosts that come with it installed and have cPanel integration.

------
ihsw
For a comprehensive list of new major language features, there is a wiki:
[https://wiki.php.net/rfc#implemented](https://wiki.php.net/rfc#implemented)

One major feature not listed on the submitted article is namespaces, which is
fairly major and it's just starting to reach critical mass in terms of reach.
Despite being probably _the_ most major feature in the past five years, most
users should be able to enjoy using namespaces to their heart's content (along
with all the libraries that utilize it, for example Amazon's latest PHP SDK
(which is thoroughly impressive)).

For reference, Python3 came out in 2008 and it's also just starting to reach
critical mass in terms of library support ( _cough_ third-party Django
libraries).

There is also a third-party committee[1][2] with the goal of establishing
things like coding guidelines, logging interfaces, HTTP request/response
interfaces, and so forth.

[1] [http://www.php-fig.org/](http://www.php-fig.org/)

[2] [https://github.com/php-fig/fig-standards](https://github.com/php-fig/fig-
standards)

~~~
eevee
Why is Python 3 relevant? Porting a large Python 2 library to Python 3 (or,
more likely, to both 2 and 3) is a significant undertaking. Porting a PHP
library to use namespaces would largely be a matter of adding global aliases
for backwards-compatibility, surely?

~~~
ihsw
Porting a library from non-namespaced to properly-namespaced code is fairly
significant, and there should be little-to-no backwards incompat. issues
between pre-php-5.3 and post-php-5.3.

The difference is a fairly large undertaking both in code size and technical
challenge.

------
jonahx
There is something almost endearingly quaint about the author's earnest
excitement over a verbose closure implementation and a procedural incarnation
of the map method, like hearing a hunter-gatherer describe in awe the magic
pictures in a box which is in reality a junked television set from 30 years
ago.

~~~
vectorpush
Mmmmmm, sweet condescension. Nothing floats my boat higher than expressing
superiority to PHP developers. They actually consider themselves to be real
programmers, aren't they just the cutest?

~~~
eevee
GP's phrasing aside, it _does_ make the article read as though the author has
never used any other closure implementation (and, by extension, any other
programming language).

~~~
vectorpush
Well, perhaps he _hasn 't_ used any other closure implementation... why would
that merit mockery? I doubt the same tone would be taken if he were a Ruby
novice adulating over block syntax. It's just hip to condescend to PHP
developers.

~~~
eevee
I'm only observing that the article comes across weirdly as a result,
especially when the author makes judgments like "simple". Not defending the
condescension. (Though the same tone might well be taken if he were a Ruby
novice writing articles titled "A Look at Ruby's Continuing Evolution".)

------
nathan_long
"Evolution" describes an unguided process which is declared successful as long
as there are still living descendants.

Just sayin'.

~~~
verandaguy
>unguided

I wouldn't say so. Most species (read: groups, not individuals) adapt when
nature throws an exception they can't handle. Mutations capable of handling
these exceptions become predominant in a group, while obsolete gene pools die
off.

PHP shows too little of this for its progression over time to be called
"evolution."

~~~
krapp
Fine. Let's call it "intelligent design" then.

------
nine_k
On topic: PHP gets lambdas and closures; generators; traits.

In other words, PHP is definitely becoming a better, more reasonable language.

Of course it's still possible to write awful code using some old PHP features.
But it's now far easier to write _good_ , maintainable and expressive code, as
one would in Python, or Ruby, or Go, or [you name it].

With this regard, PHP's evolution is not unlike C++'s.

~~~
zaphar
That has to be one of the strangest syntax's I've seen for closures ever. I
get why it has to be that way sort of. (backwards compatibility) but it only
serves to illustrate how PHP has hamstrung itself in the past.

Comparing PHP's evolution to C++ isn't exactly flattering either.

~~~
smsm42
What's so strange in it? It looks pretty much exactly like JS, for example,
with one small addition of "use" clause. It has very little to do with
"backwards compatibility" \- since there's nothing to be backwards compatible
to, closures didn't exist before.

~~~
zaphar
The use clause is the weird part. I would imagine the reason it has to be
there is because it would be bad if functions that weren't written with
closures in mind previously suddenly turned into closures. Otherwise why even
bother?

~~~
smsm42
The reason has nothing to do with that. The reason is that closures don't need
most of the variables from parent scope, but if they were imported, since PHP
is refcounting they'd keep a lock on those variables even after exit from the
original scope - as long as the closure exists - even though nobody actually
needs them.

Since PHP has $$var (and other things like this) we can not know in advance
which variables the function uses in local scope, so if we did automatic scope
importing, we'd have to keep the whole scope of the parent function for the
lifetime of the closure in case some of the variables would be needed. This,
if parent scope contained some large objects, would result in a memory and
performance hit each time closures are used.

Thus, it was decided that we'd make scope importing explicit (the use clause),
so if you want to import variable, you have to say it. Experience shows that
vast majority of closures need no more than one or two vars from parent scope,
so the tradeoff is fine. Of course, if closures would import dozens of
variables regularly, we'd have to seek different solution, but this is not the
situation.

Additional benefit - though not the reason - is readability improvement, as
now you know where each variable is coming from, otherwise reading in-closure
code you wouldn't know if the variable that is not mentioned anywhere is a
mistake or it is actually expected to be imported from outside.

BTW, C++11 is using the same idea:
[https://en.wikipedia.org/wiki/Anonymous_function#C.2B.2B](https://en.wikipedia.org/wiki/Anonymous_function#C.2B.2B)
though they have catch-all syntaxes which in PHP wouldn't work since PHP is a
dynamic language.

~~~
zaphar
That was a very informative explanation thank you.

I still think it looks weird even if PHP's semantics make it necesary but
that's totally subjective :-)

------
jmstout
"That 80% marketshare is not going anywhere anytime soon."

Whatever helps you sleep at night.

~~~
betenoire
PHP is unlikely to power the next start up. But I wouldn't be so cynical about
it's success, especially in other segments of the web.

~~~
wyck
Why not? , programmers might hate it but they don't always drive start-up
direction. Getting something to market and being useful is just more important
than semantics when you're facing a budget.

Lots of start-ups started with PHP (foursquare, groupon, facebook, etc, etc)
because of the minimal cost and the convenience offered by popularity. If it
works out and they get funding they can spend all that sweet cash on whatever
they prefer.

Mobile apps and heavy REST services maybe not, but websites are still popular,
and PHP is playing catch up for those services too.

~~~
betenoire
I don't disagree. I was responding to the sarcastic comment about PHP, not
really trying to address using it for a start up. Our start up used it as
well. It's not the sexiest or most fun environment, but it works and it's the
devil I know.

~~~
janson0
This is my situation too. I mean, I know PHP and I know CodeIgniter. I have
tons of already ready to deploy code based in those idioms, so why port
everything to laravel? or Ruby? Maybe down the line or something... but not
when speed matters.

~~~
eevee
Speed will always matter. You'll never find time to address technical debt;
you have to make it.

------
programminggeek
There is so much to dislike about PHP that the only thing I can say nice about
PHP is that it's the easiest way to just deploy to any server ever. Beyond
that, I don't think I would look to PHP to do anything ever if I had a choice
of project language.

~~~
shuzchen
As someone that has had to mess with deploying large PHP project in a previous
life, I'd have to disagree.

Using mod_php? Better fix your file permissions. Use any non-trivial language
feature? - better make sure you have the right minor version installed. Use
functions from the supposed standard library (e.g., anything from gd_*, xml,
process control, cryptography modules)? - better pray PHP was compiled with
those enabled. Use routing in your PHP app (and you're crazy if you don't)? -
better pray apache is configured to accept your .htaccess, or port the
mod_rewrite rules for the non-apache server you're on. And then all of this
while futzing with the 3 different php.ini files scattered around the
filesystem.

Between virtualenv and pip, deploying python has been loads easier, as is
getting team members up and running with a dev server.

~~~
stephenr
Out of the box php generally works, which is often touted as a benefit.
Personally i think if you can afford a server you can afford 20 minutes time
for someone who knows what they're doing.

Every one of your examples tells me that you chose not to invest in those 20
minutes.

Here's a hint: there is a reason "developer" and "administrator" are usually
different roles.

~~~
shuzchen
Out of the box php generally works so long as you have trivial php code (that
doesn't take advantage of new language features, doesn't need routing, doesn't
need to write to the filesystem, and doesn't common library modules). Needless
to say, that generally rules out any serious project out there.

I'm not saying I chose not to invest in those 20 minutes, I'm saying there's
nothing about PHP that makes it inherently easier than other things to deploy
real projects. You still have to deal with version incompatibilities, you
still have to deal with configuration, you still have to deal with differing
resources. That applies to all stacks.

------
epoxyhockey
PHP's continuing evolution is also represented by the frameworks available for
the language. For instance, Symfony2, paired with Composer, is (IMHO)
analogous to Rails for Ruby and Django for Python.

HN can be an echo chamber for Ruby, Python and Golang. But outside of the Bay
Area, a lot of people are very excited about Symfony2.

~~~
pearjuice
Laravel 4 is amazing, too. Symfony2 feels like a beomoth to me (a few versions
later and it will probably be on-par with Zend in terms of over-architecturing
as it is going right now) whereas Laravel is lean and elastic yet offering the
complete package in an easy consumable format.

~~~
porker
I'm seeing a lot of love for Laravel 4 at the moment and I'm not 'getting' it.
Sure, the framework's easier to pick up than Symfony2 and not as over-
engineered, but it doesn't feel as complete (forms, anyone?) or as well
designed (what's up with all these static methods?)

Laravel 4 is becoming the CodeIgniter of the PHP 5.4 frameworks - simple
enough for people to jump on as they can get something done. And the
CodeIgniter comparison is not a compliment.

~~~
pearjuice
Laravel doesn't come close to CI in terms of trash. It is very well
architectured to the point where everything is modular, testable, properly
documented and done with a reason. Static methods are actually facades as
pointed out and are key in having proper testable applications.

* Forms? It has support for forms in more way than one. Read the docs! :-)

~~~
porker
> Static methods are actually facades as pointed out and are key in having
> proper testable applications.

Thanks, I had a look about a year ago at the facades document and it seemed a
justification for using static methods, rather than a reason.

I'm pushing hard on this as I really want to understand it. I am surrounded by
PHP programmers chanting "Every time you use a Singletons a kitten dies" and
"No static methods". Yet when I used (and contributed to PEAR) they were
positively encouraged. Is the change another fad, or fact-based?

> * Forms? It has support for forms in more way than one. Read the docs! :-)

I have :) I see helpers to generate form fields and a validation library. I
see no way to create form entities, to extend forms (to create variations on a
base form), or to abstract the field definitions from the view (while the
visible value of select box options could be in the remit of the designer,
modifying the value shouldn't be accessible to anyone other than the
programmer, and neither IMO should choosing the field type (drop down or
multiple radio buttons? Multiple select or checkboxes?)

Also no support for 0..N repeating fields baked in (with conditional
validation), or 1..N fields - stuff I use in almost every form. Every form
library I've discovered falls short in these requirements though!

------
usamec
Evolved shit is still shit. Half of issues mentioned here
([http://me.veekun.com/blog/2012/04/09/php-a-fractal-of-bad-
de...](http://me.veekun.com/blog/2012/04/09/php-a-fractal-of-bad-design/)) are
still not solved.

~~~
tangledweb
I've always loved that fractal of bad design rant. Many of his gripes follow
really neatly from his initial analogy of the hammer with claws on both sides.

Let's say you want to hammer in a nail. You reach into a tool box and pull out
something that you think is a hammer. Instead it has claws on both sides, and
is in fact a nail puller. You don't know much about tools so you use it to
beat in nails, all the while grumbling to your friends that it's a bad hammer.

For instance, I don't see how you expect to "solve" most of the "issues" in
that. The fact that the author does not like the way == works in a weakly
typed language is not a bug. Sure, it present bugs in code when programmers
don't know how implicit type casting works, but it's really nice if you do.

~~~
eevee
Hello, author here. You're not the first to scoff at my hammer description,
but perhaps you can explain to me what kind of nail puller looks exactly like
a hammer but with two claws, or why it would be useful to have the exact same
tool on both sides of the handle. (This is still a PHP analogy.)

I don't see how to solve most of the issues, either. That sucks, and I
genuinely sympathize with Zend on this, but it doesn't make them not-issues.
As I think I said, they'd be acceptable if they were reasonable tradeoffs, but
many of them are not.

Your == counterargument seems apologetic and trivially applied to anything:
whenever a program is wrong because the language violated expectations, it's
the programmer's fault for not having memorized some matrix of arcane rules.
Languages aren't perfect and human beings have wildly differing expectations,
but ultimately we only _have_ programming languages to make it easier to
express ourselves—no one's stopping you from writing the next big web 2.0
thing in x86 machine code. So yes, when it's difficult to reliably ask a
language "are these things the same" without learning paragraphs of gotchas,
that's bad.

Glad you enjoyed the article!

~~~
tangledweb
I think you are stretching the hammer analogy well beyond its useful limit.
I've no idea what php function you think has a redundant left and right
version, but to humor you, sure there are lots of nail pullers that have two
similar sides or ends to attack different sizes. eg
[http://s.shld.net/is/image/Sears/00938076000](http://s.shld.net/is/image/Sears/00938076000)
There are also lots of physical tools that completely reasonably do have
exactly duplicated sides or ends because they wear out, but I don't see how
you want that to apply to software.

Talking about == is not trivial or apologetic. That's the way I expect
comparison to work in a loosely typed language. I expect 0, 0.0, '0', '0.0',
-0, 00, 0x00, null and false to be logically equivalent most of the time. If
it also means that if I don't validate input from an http request 0=='0 foodle
fish' also evaluates as true, then that's a cost I'm willing to bear.

~~~
eevee
Would you expect "1.30" == "13e-1", since both are strings? How about "0xb" ==
"0xB"? 0 == "zero"?

I don't see how this is anything but bugprone, and all to save you from
actually saying what you meant and slapping a couple int()s on your input.

Compare JavaScript, a language with much the same == problems, where the
community generally advises against ever using == at all. CoffeeScript
(different syntax that compiles directly to JavaScript) even translates ==
into ===, leaving the original buggy operator unavailable.

~~~
tangledweb
I would not expect "1.30" == "13e-1" or "0xb" == "0xB" to compare as true, but
it's of kind of cool that they magically do.

I don't think 0 == "zero" is a meaningful comparison, so I don't think there
is any single sensible answer. I know "zero" will be cast into 0 and therefore
it will be true. That's not a matter of expected language logic, it's just
personal preference on do you want your language to fail hard when given
garbage input, or continue.

Most input to a PHP program is going to be strings. It is going to have come
from an untyped GET or POST request string decoded into string parameters. If
you expect it to be integers it needs to be cast somewhere. For most
applications you should be doing that explicitly, taking control of the
process and deciding how to respond to user error or other invalid input.

Our main difference of opinion seems to be that I think it is good that the
language tries to help when the programmer is lazy, and you think it should
immediately reprimand them with a rolled up newspaper so they will be forced
to do it properly before seeing any output.

~~~
eevee
It's good when languages try to help. Reprimanding someone for not doing
enough work is useless.

My problem is that the language is _guessing wildly_ , in ways too obscure to
be mentioned in the documentation or known by you (a user of the language),
even when both operands are strings. That means it _appears to work_ much of
the time even if you don't think you're being lazy, but might actually have a
bunch of false positives you didn't expect. And that's kind of a bad thing in
a programming language. Same sort of reason manually escaping everything is
hard to get right: if you forget, your code still works fine under "normal"
circumstances.

Now, if == did a strict comparison and there were a separate
imlazyjustslopittogether operator, there wouldn't be a problem. Defaults
matter.

------
AlexanderDhoore
I have to create some push based (websockets or similar) web service that's
event driven (events on the stock market). The prototype has been written in
PHP, but doesn't do very much. I'm STRONGLY considering moving to nodejs.

We now use Composer for packages, an automatic classloader, an application
framework and a database abstraction. But even with all this stuff, PHP is
still an incredible pain.

PHP might be good at the situation where: on every request, you start a new
script, that builds a webpage and sends it to the client. But once you try to
make it do something else... Frustration awaits.

~~~
meritt
Your worldview ( Your last statement, that you think PHP is only suitable for
a single request in a fcgi environment.) of PHP's capabilities are the pain
point here.

What difficulties are you encountering trying to do basic pub/sub? Application
developers have solved those exact same issues for decades now. Nodejs didn't
invent "event-based programming".

~~~
wwweston
I've written a lot of PHP, and while I can think of a number of ways you
_might_ use PHP to provide the backend for websocket-like communication
(writing a long-running server, using multipart responses, adaptive polling),
it seems pretty fair to me to say this isn't the place where PHP is strongest
out of the box. Particularly compared to nodejs.

If you know of a PHP runtime-host, library, or even just a development
approach that makes supporting it as easy as nodejs, though, I'm all ears.

~~~
meritt
[http://reactphp.org/](http://reactphp.org/) ( more specifically
[http://socketo.me/](http://socketo.me/) ) work very well for actually
implementing websockets. It's fast and incredibly easy. Igor
([https://github.com/igorw](https://github.com/igorw)) is a really talented
guy.

------
waivej
"That 80% marketshare is not going anywhere anytime soon." \- I had to look
this up to confirm... It changes my perspective on the language.

~~~
kaeruct
could you share what you found? i'm curious

~~~
kragniz
I'm guessing this: [http://w3techs.com/technologies/details/pl-
php/all/all](http://w3techs.com/technologies/details/pl-php/all/all)

~~~
waivej
This one too:
[http://w3techs.com/technologies/overview/programming_languag...](http://w3techs.com/technologies/overview/programming_language/all)

This page was also interesting... Keep in mind, it's only the top 10,000,000
in Alexa:
[http://w3techs.com/forum/topic/22677](http://w3techs.com/forum/topic/22677)

"In total, we have a few thousand technology indicators, many of them can be
used - directly or indirectly - to determine the server-side language.

The number of sites where we don't identify any language is relatively small.
The reason why we don't include it in the statistics is, that we want to show
shifts in the relative popularity of technologies, not distorted by changes in
our abilities to detect them."

------
tel
There's a lot of noise about PHP becoming a better language by adding
features. Isn't it well established that adding features to a dud product is
not the path to a better one?

------
fideloper
In my opinion, the _only_ problem PHP suffers is that it's populated by many
young, inexperienced developers. It's ease of use and low barrier of entry is
a double-edged sword.

Many developers (especially ones building upon CMSes primarily) don't need to
move beyond knowing Wordpress, ExpressionEngine or CodeIgniter.

So many "easy to use" products are built on it (Wordpress alone powers ~18% of
"the internet") that it makes sense that we see so many mis- or un-informed
developers crowding Google and StackOverflow.

You can make good code in PHP. You can also learn other languages. You can,
more importantly, learn when it's a good idea to use other languages. However,
if people don't need to learn more, many won't. That's human nature.

Saying "PHP sucks" is missing the point that other people have other needs,
other experience and other education levels from you.

PHP, as a language with low barrier to entry, can fulfill many's needs without
requiring a CS education, and without writing their own framework/cms.

Source: 18% of internet: [http://thenextweb.com/insider/2013/07/27/wordpress-
now-power...](http://thenextweb.com/insider/2013/07/27/wordpress-now-
powers-18-9-of-the-web-has-over-46m-downloads-according-to-founder-matt-
mullenweg/)

~~~
smsm42
>>> is that it's populated by many young, inexperienced developers.

It's not a bug, it's a feature. PHP _is_ by design the language for young,
inexperienced developers. It's like saying the only problem a school has is
that it's full of kids.

------
Osiris
There are whole books written about how terrible JavaScript is, and yet it is
one of the most popular languages today. People have learned to work around
the quirks and develop best practices to avoid pitfalls.

PHP is an actively developed language. It has its pitfalls and problems, but
is also provides more modern ways to use the language that avoid those
problems.

~~~
camus
> it is one of the most popular languages today

Javascript is popular because people have no choice but to use that. Let's be
truthfull here.

Only a few people actually like this language.If it wasnt for the web nobody
would use javascript ,which is totally inconsistent with the strongly typed
DOM.

Kudos to microsoft as they created DHTML.

------
lysol
Another thing I didn't notice earlier, after perusing the implemented RFCs:
More Python-like array syntax:

[1, 2, 3] ['key1': 'val1', 'key2': 'val2']

We've been on 5.4+ at work for some time now and if I'd know that a year ago
it would've saved me a lot of array()s and visual noise.

~~~
adduc
The colon-based syntax was voted down.

What went live in 5.4 was support for brackets in lieu of array()

    
    
        // Typical array syntax
        $arr = array('key' => 'asdf');
    
        // Supported in 5.4+
        $arr = ['key' => 'asdf'];

------
anaphor
I don't find the closure syntax simple really, since it's essentially a hack
to copy the variable into the current scope, since PHP doesn't support lexical
scope.

~~~
eevee
PHP supports lexical scope; it's just local to the current function.

The actual problem is that PHP automatically initializes variables even on
read—the same reason all globals have to be manually "imported", even if
they're only read from. Similar to the problem Python 3's `nonlocal` solves,
except imagine a world where Python didn't have NameErrors and instead
initialized every unrecognized name to None.

~~~
anaphor
Is there much PHP code that relies on this "feature" or could they have
changed it to actually search in the enclosing scope if something was read,
and avoided the silly "use" keyword? I mean it's not like PHP has an actual
spec, so they can change it whenever they feel like it as long as it doesn't
break much.

~~~
eevee
Variable declaration is pretty core to the language. Remember
register_globals? That was only a problem _because_ so much code relied on
having undeclared variables act like empty strings.

I suppose they could have made it work differently just for nested functions,
but that's a major inconsistency, it's not clear how it would interact with
globals, etc.

~~~
stephenr
register globals didn't "make undeclared variables act like empty strings".

register globals imported request parameters from the query string and post
body into the global variable scope.

having undeclared variables "act like empty strings" is related to non-strict
variable comparison (== vs ===) and either silencing errors, or not
displaying/caring about them.

~~~
eevee
register_globals could not have existed without the legality of undeclared
variables, and it could not have been a security issue without code that
relied on using undefinedness as a default value.

~~~
stephenr
undeclared variabels aren't legal, they cause errors. if your php is
configured to ignore those errors thats on you.

of course it could be a security issue without undefined variables coercing to
an empty string in string context - it could allow request parameters to
override defined variables.

------
zura
Any chance it can get rid of the dollar sign?

~~~
stephenr
Is this a joke?

~~~
zura
That would be a joke if I was wishing replacing it with Euro sign.

------
agumonkey
PHP is maturing but large user base and projects may slow the diffusion of
idioms based on the new additions. Or maybe the next major releases of say
joomla, wordpress and such have redesigned their core to leverage that. Maybe
they'll follow the eclipse ecosystem-wide synchronisation of projects.

------
janson0
I often believe that these arguments over which language is better are a
detriment to actually getting stuff done. But here I am commenting on stuff,
rather than coding... so what does that say about me? :)

------
ausjke
Laravel looks great, is it still a one-person-mainly project? if so that
really concerns me, same as Gitlab project.

------
MindTwister
I hadn't spotted the iterators earlier, interesting.

~~~
troels
Really? They have been around since 5.0, which is nearly a decade old. See
some of the other interfaces SPL provides here:
[http://php.net/manual/en/book.spl.php](http://php.net/manual/en/book.spl.php)

~~~
MindTwister
I meant generators, as in yield

~~~
smsm42
Generators mostly are just a convenient syntax for iterators (i.e. if you
wanted, you could have generators years ago, just required to do some awkward
boilerplate code).

