
The new PHP - ingve
http://programming.oreilly.com/2014/03/the-new-php.html
======
nikic
While the gist behind this post is right, the article contains a number of
factual errors. E.g. the version numbers in the "language features" section
are pretty messed up:

* Namespaces, closures and FPM were already in PHP 5.3

* The built-in web server was already in PHP 5.4

* Improved variadic functions, argument unpacking and phpdbg will be in PHP 5.6, which goes to beta in about a week.

~~~
codeguy
Hi nikic. Thanks for the feedback! (I'm the author of that article). The
O'Reilly editors made a few changes to the wording without my review that make
it more ambiguous as to what features were introduced in what version. I agree
as is it can be confusing. But the point is that the latest version of PHP
provides all of these features. The variadic function statement was an error
on my part and it has since been corrected in the article.

~~~
anaphor
Do you really think tacking on more badly designed features makes PHP better?
PHP's "closures" require you to write down the free variables in an enclosed
function and tell PHP that they exist, that is something a compiler should be
doing. Google "closure conversion".

~~~
Kiro
> PHP's "closures" require you to write down the free variables in an enclosed
> function and tell PHP that they exist

Can you give an example? I googled "closure conversion" but didn't understand.

~~~
dmiladinov
In order to use variables from the scope that the anonymous function came
from, you have to explicitly import them into the anonymous function with the
use[1] block:

    
    
        public function getTotal($tax)
        {
            $total = 0.00;
            
            $callback =
                function ($quantity, $product) use ($tax, &$total)
                {
                    $pricePerItem = constant(__CLASS__ . "::PRICE_" .
                        strtoupper($product));
                    $total += ($pricePerItem * $quantity) * ($tax + 1.0);
                };
            
            array_walk($this->products, $callback);
            return round($total, 2);
        }
    
    

In other languages that have true closures, the anonymous function "closes
over" the lexical scope in which it was declared.

[1]:
[http://www.php.net/manual/en/functions.anonymous.php](http://www.php.net/manual/en/functions.anonymous.php)

~~~
coldtea
Yeah, so? Sounds even better, as you can only declare what you'll actually use
from the enclosing scope.

Besides, doesn't Python work the same way?

~~~
anaphor
Wrong. You only need to use the free variables of the closure, you don't need
to copy the entire environment from the function you're defining your closure
in. By the definition of a free variable you actually use it, otherwise it
wouldn't be a free variable of the function! Python definitely does not work
the same way, but in Python "x = 3" can inadvertently shadow (make a local
name) something defined in the outer scope, but that's a completely different
problem.

------
rubiquity
> generators for simpler iteration, namespaces, and variadic functions and
> argument unpacking. With PHP 5.4, traits were introduced (a la Scala or
> Perl) to allow code reuse in single inheritance languages, as well as
> closures, which allow you to code PHP in a functional style.

"The new Java"

It's good to see PHP maturing. However sometimes the most important features
of a language are the features you _don 't_ add. I think PHP would do itself a
big favor by cleaning up its main APIs and standard library first. Maybe they
will do that in PHP 6, since I doubt they want to break APIs in minor
releases.

~~~
nikic
PHP has a rather strict no-BC-break policy for minor releases. As such the 5.x
series improves the language mostly through additions. I think that's good.
PHP has been missing a number of things that are now present.

However that doesn't work forever, at some point you need to clean up some of
the old stuff. That's why a PHP 6 release is planned in the near future (i.e.
somewhere in the next three years ^^).

~~~
uxp
The very first programming book I bought was "PHP6 and MySQL5" by Larry
Ullman. I bought that one specifically because I had another job (career,
really) and I knew it was going to take a while before I really got into
programming and I didn't want to buy a book that was going to be out of date
in 2 years. That book is now 6 years old, out of date, and PHP6 is still not
released. Maybe 6 is just an unlucky number with Perl unable to make that goal
as well, but either way I'm not holding my breath.

I've since moved on to more well thought out languages, though PHP keeps
pulling me back in. I'm currently having to support a CI app that hasn't had a
line of code added to it since 2008, and the only thing I can say, even though
I appreciate the language and how far it's pushed the web, I'm glad it's no
longer my go-to language of choice. Keep PHP5 around for a while so apps like
this one can continue on, but PHP6 is _LONG_ overdue.

~~~
whoopiecush
Literally bought the same book by Larry Ulman.

~~~
dools
I bought the same book metaphorically.

~~~
rubiquity
Same here. Larry's a great author. I got started with his books years ago. He
definitely makes Web dev feel more approachable, which is invaluable to a
newbie. I believe Patrick Collison from Stripe also got started on Larry's
books (for some reason I recall a conversion on Twitter or the like about
this).

------
kayoone
It really pains me that there are so many utter misunderstandings about modern
PHP from people that used it years ago and have no clue about the current
landscape, even in this thread.

Yes, the PHP core api is still a bit messy due to backward compatibility, but
everything else it pretty awesome really. Please take a closer look if you
haven't touched PHP in years, before you talk it down.

~~~
fleitz
Oh, did you mean PHP the language? The webserver? The FastCGI server? The
runtime?

PHP starts as a fucking mess and gets worse. Maybe once the developers figure
out what it is I'll take a look but yeah it's pretty much the developers
taking standard features from other languages and fucking them up just like
they did yesteryear.

Closures with a use block... even in C you don't have to do that... it's a
joke and a mess... How is it that a 44 year old language has better features
and less cruft than one 15 years old?

Does it have a ==== operator yet?

~~~
KingMob
Yeah, the functional programming side of PHP is ugly as sin.

Forgot to add your latest variable to the use block? No "closing over" for
you.

What's that? _All_ array function are prefixed with "array_"... except for the
old ones which aren't, making it both verbose _and_ confusing.

------
Jgrubb
I'm a Drupal dev by trade, and I consider any day that I don't have to get
into the guts of Drupal and write PHP a good day.

Recently, however, I had to get in there. This was a few days after I upgraded
my local environment from 5.3 to 5.5. I've been writing Ruby for fun for a
while now, and I love how I almost never have to look API related questions
up, at least in comparison to PHP API questions. So I just wrote some PHP
without looking up whether it was going to work, and it worked, first try.
That rarely happens. Then I pushed it to dev, which is still on 5.3, and took
the (dev) site down. Turns out the feature "array function dereferencing" is
not available in 5.3, so I had to rewrite my code a little bit.

Point being, I could see myself liking PHP more when we move to 5.5 in all our
environments.

~~~
girvo
I did the same job for 6 months. I really like PHP nowadays, but Christ Drupal
core is a mess (or was, that was v6).

~~~
codygman
If I may ask, what other languages do you have experience with and what are
your opinions of them?

~~~
girvo
Ruby, extensively. It's enjoyable and quite useful. Meta programming makes me
think of Lisp, but need to be careful of side effects.

Go, recently I've been using it for certain services and APIs. Really great
for concurrent programming for services, syntax is nice too.

Python, I've used a few times over the years and have used it with personal
projects a number of times. Still like python quite a bit.

(Bonus: nimrod, which I'm helping build a new type system for, Clojure and
Scala I've played with extensively but never had a chance to use in
production, and C/C++/Vala I've used when doing desktop programming on Linux
for Elementary)

------
lukeholder
All this is very true.

Modern PHP is not the PHP of yesteryear. With Composer for dependancy
management and sticking to the PSR's you can build very stable, testable, and
modern applications that change minds about PHP.

~~~
xr09
The thing is you have to be a medium-to-expert to be confident about Composer
dependencies, every new dev is going to use the language API, which resembles
a bunch of functions with no general pattern.

PHP users need to keep it together and set a common base, a standard library
with sane defaults.

~~~
dylz
I am new to PHP and I started right off with composer -- all you have to do is
composer require pkg dev-master [or other pin].

I don't see how this is different from gem install pkg.

------
d23
> It contains powerful new features and helpful developer tools, such as a
> built-in web server

I haven't finished the article yet, but really? Is that what PHP needs? A
built-in web server? It strikes me that adding more tools that incompetent web
developers can abuse is what got them there in the first place.

How long until we start having security releases for the PHP web server,
because so many clueless devs decided to launch and run their site with it?

~~~
maratd
The web server is explicitly for development purposes. It is _not_ meant for
production.

> It strikes me that adding more tools that incompetent web developers can
> abuse is what got them there in the first place.

This is profoundly ridiculous. It's the equivalent of saying Home Depot
shouldn't sell power tools because some do-it-yourselfer might saw his foot
off.

Just because a tool can be misused is _not_ an argument against it nor its
inclusion.

~~~
mehwoot
_Just because a tool can be misused is not an argument against it nor its
inclusion._

I used to believe this, but now I couldn't disagree more. People can and do
misuse things all the bloody time, and the more you enable them to do that,
the worse your tool is. How people use what you make is every bit as
important, possibly even more important than the technical merits of what you
make.

I'd rather a builder use a second hand hammer to nail something than try doing
it with a jackhammer.

~~~
g8oz
I don't hear people complaining about Python's builtin webserver. Maybe thats
because Python only attracts people who do things correctly right?

~~~
samastur
Python doesn't have a builtin webserver, but there is one in standard library
of CPython.

I've yet to see an article that would argue that its existence is a proof that
you should be using Python now.

~~~
girvo
Then you missed the point of the article, and also obviously don't use PHP
regularly. It's a super handy feature.

------
awestroke
I sometimes ponder what I'd fix, given the chance, about PHP:

* Make the "stdout == response body" an explicit option, and make a rendering engine the default instead. Just sending all output is a senseless DEFAULT.

* Remove all the array_x functions and turn arrays into a class instead, and change the parameter order to be consistent across all the functions. A similar action could be done across many other classes of functions, too.

* Tighten equivalence requirements, == should work like ===.

* Etc.

But I always realize I'd just end up with Ruby or Python, both of which
already exist and have fantastic ecosystems. Oh well.

~~~
mgkimsal
Make the "stdout == response body" an explicit option

Why? It's a primary differentiating factor for PHP, and one of the
cornerstones of its popularity. Given that it powers a non-trivial percentage
of the web, from single page "hello world" sites up to multi billion dollar
ecommerce sites, I'd say 'fixing' that one aspect is not something that needs
to be.

"== should work like ===". Why? If you want ===, use ===. But given that HTTP,
the lingua franca of the web, is typeless, and PHP is targeting web
developers, having a language that doesn't enforce types in all cases isn't
all that bad.

~~~
awestroke
1: "Explicit option" means it's still possible, but shouldn't better practices
be encouraged? Anything to push developers away from interleaving logic and
templates

2: PHP, however, has types. == is wildly unpredictable

~~~
userbinator
1\. Why add complexity when it isn't necessary? Inline output is one of the
best features of PHP in that it makes it _extremely_ easy to get started using
it. If you want templates you can add them. Not everyone wants them.

2\. PHP is dynamically typed, like many other languages, and so you just have
to know what types something can be and how they behave together. Even in a
statically typed language you need to know how type conversions work. That's
what the documentation is for (
[http://php.net/manual/en/language.operators.comparison.php](http://php.net/manual/en/language.operators.comparison.php)
). It's not "wildly unpredictable", it's defined and deterministic.

~~~
awestroke
Easy to get started, then what? I didn't learn how to structure big projects
until I moved to better languages that encourage (through defaults) better
practices.

Predictable !== well defined. If you have to look through a chart for
equivalence, it's unpredictable to the programmer. But this is a theme for all
of PHP, you can't deduct equivalence, function names and function arguments
orders, you have to memorize or peruse the manual. Sure, it works, but it has
drawbacks.

~~~
mgkimsal
"I didn't learn how to structure big projects until I moved to better
languages that encourage (through defaults) better practices."

Do you think that PHP is the only language where developers look to other
practices in other language communities to learn different/new/better/changing
practices? Every _good_ developer is aware of patterns and structures in other
languages/platforms - I dare say it's almost the definition of a good
developer. I would _not_ regard a Ruby developer who'd only ever done Rails
projects as a 'good' developer, regardless of how clean/elegant the code
seems.

------
shubhamjain
Whenever I hear "the new PHP" or "its not the old mess anymore", I say to
myself, thats hardly the point. The key flaw I find with PHP is with its
community and lack of any mature frameworks. Half of the PHP coders are
hopeless script kiddies, thanks to low barrier entry it has, and I don't feel
a single framework exists that can match Rails or Django. For the matter of
fact, the framework with largest community, Codeigniter, only has inline test
functions for any kind of testing and doesn't even come with a auth library.

Being a PHP developer myself, I can't refute that only selling point of PHP,
albeit, a major one, is its so "easy" to get things done. I feel in the near
future, with advent of tools to make mature frameworks more accessible, PHP
would cease to be a tool for any serious web development.

~~~
citricsquid
Codeigniter has been all but abandoned by EllisLab, the community is giving up
on it and there are far better frameworks available now. For example Laravel,
the growth that Laravel is experiencing right now is huge, it has overtaken
Codeigniter as the most popular PHP framework on GitHub and has a growing and
active community. Anyone even _thinking_ about Codeigniter any more is doing
themselves a disservice, Laravel is leaps and bounds ahead of Codeigniter.
Laravel is on its way to being the Rails of PHP.

[http://www.google.co.uk/trends/explore?hl=en-
US&q=laravel,+s...](http://www.google.co.uk/trends/explore?hl=en-
US&q=laravel,+symfony,+codeigniter,+zend)

~~~
pkorzeniewski
I recommend FuelPHP [1] - it has amazing documentation, a lot of built-in
libraries, takes advantage of PHP5 features, is quite mature and really easy
to dive in.

[1] [http://fuelphp.com/](http://fuelphp.com/)

~~~
joebeetee
+1 for FuelPHP - well thought out and easily extensible.

------
pippy
To me the criticisms about PHP are pedantic and is a result of
misunderstanding the philosophy behind PHP. The kneejerk reaction language
modifications the PHP community made because of the 'PHP sucks lol' meme is
detrimental to the language itself.

PHP is a mature webdevelopment language that features an easy to learn, read,
and develop feature set. Scala or Perl are not. (See Perl 6) So I don't see
how emulating it will provide any form of benefit. Picking up a language
feature because a guru attacks PHP because they can write a feature X in Y
lines is almost an immature.

The reusability and performance issues were genuine, but these were to be
expected given version iterations and the fact PHP introduced namespaces a
while back.

~~~
JackMorgan
I think most people don't really compare PHP to Scala: it is an entirely
different language. I think most people who talk down about PHP do so because
Python and Ruby are so much easier to understand and use. But then again I'm
of the unpopular opinion (having worked professionally in all four) that Perl,
PHP, Python, and Ruby should go into a cage, and only one should emerge. The
others must write converters that turn their code into working code of the
winner's, and we should stop having four languages that are basically all
fighting over the same dynamic scripting language mindshare. Imagine if
instead of worrying about "keeping up with the Rail's" you could just think
about how to actually work on converting those Java/Haskell/Lisp programmers!

------
buovjaga
This may be of interest to some: I did research and found out that 58 out of
67 web hosts in Finland either offer PHP 5.4 or 5.5 right now or at least
starting from summer 2014 (5.3 EOL is in July). An increasing number of web
hosts give their customers the ability to switch PHP versions (with .htaccess
or some web interface). It seems this trend will speed up the installation of
fresh PHP versions.

------
anaphor
PHP's "closures" are basically you the programmer calculating the free
variables in an enclosed function and then telling PHP you want them to be
bound in an environment. I would laugh if it weren't so pathetic.

------
eddd
I don't get it. Why people can't just admit the fact that PHP had his time and
now, no one with common sense would not start new project (except simple
wordpress stuff) in PHP.

~~~
cweagans
In most enterprise environments, you have your choice between .NET and PHP.
Given the option, I'll take PHP, thanks.

~~~
dionyziz
Twitter's code is "enterprise" code in that it has to satisfy the
organization's needs and a huge part of it is not user-facing, but targeting
other enterprises (for example, Twitter ads). At Twitter, we use Scala.

So, no, you're not necessarily stuck between these two options (or Java, which
is another popular choice in the enterprise scene). Scala was chosen
specifically, among other things, because Twitter had a lot of Ruby developers
who would cringe at the idea of PHP, Java, or .NET.

~~~
encoderer
Twitter is not what he meant by "enterprise." You work at a tech company.
Enterprise connotes big corporate IT department software development.

------
ck2
I don't see any mention of the "new" zend opcache which has great performance.

------
spoiler
I used to write PHP before I got into Ruby. I'm glad PHP is getting it's shit
together, but it's still a no-language for me.

------
hashberry
"There are only two kinds of programming languages: those people always bitch
about and those nobody uses." \-- Bjarne Stroustrup

------
stevoski
I often wonder why a PHP killer hasn't yet been created.

I don't mean a Ruby or another vastly different language.

I mean a language similar in approach to PHP, but with the gotcha's removed,
some order and consistency introduced into the API, and a few changes to the
defaults. Open source, free, and on all major OS's.

~~~
eddd
check what PyPy did (or is doing with PHP).

~~~
uolot
Could you please explain it a bit or provide a link?

~~~
chrisguitarguy
[http://morepypy.blogspot.com/2012/07/hello-
everyone.html](http://morepypy.blogspot.com/2012/07/hello-everyone.html)

> I'm proud to release the result of a Facebook-sponsored study on the
> feasibility of using the RPython toolchain to produce a PHP interpreter. The
> rules were simple: two months; one person; get as close to PHP as possible,
> implementing enough warts and corner cases to be reasonably sure that it
> answers hard problems in the PHP language. The outcome is called Hippy VM
> and implements most of the PHP 1.0 language (functions, arrays, ints, floats
> and strings).

~~~
uolot
Thanks, seems very impressive

------
pearjuice
What I don't comprehend is how someone can know of all this and then still
stay "you know what? fuck namespaces and PSR, we are doing it old school!" and
come up with arguments like "I/O overhead is costly in one class per file
scenarios"[0].

These people will be the death of all of us.

[0] [https://www.sellvana.com/blog/on-composer-psr-and-
namespaces](https://www.sellvana.com/blog/on-composer-psr-and-namespaces)

------
cies
The article compares PHP now to PHP in the past. But programmers should not do
this, they should compare PHP to other languages and their ecosystems, and
conclude that it is not fit for a greenfield project.

The new libs'n'tools are nice; good to see them showcased. But the bottom line
for any developer should be to avoid it --like Perl-- for any from-scratch
code. This is a legacy language now.

------
foosui
[http://phpthegoodparts.tumblr.com/](http://phpthegoodparts.tumblr.com/)

~~~
mordae
> Here's a rule of thumb: If the O'Reilly company publishes a book called
> "<blank>: The Good Parts" the thing that's in the <blank> is evil!.

\-- Matthew Butterick, RacketCon 2013

[http://shop.oreilly.com/product/9780596804381.do](http://shop.oreilly.com/product/9780596804381.do)

------
dscrd
Here's what would make me accept PHP as passable practical web programming
language: A good REPL, with good support for it over all frameworks. That's
all it would take.

Given that it doesn't have one, python beats it easily.

~~~
indeyets
You mean like boris?
[https://github.com/d11wtq/boris](https://github.com/d11wtq/boris)

~~~
dscrd
Looks good, but here's the practical question: Can I enter this REPL with all
the libraries and models of my web framework loaded so that I can query a
model through it, modify the object and save?

~~~
oinksoft
No more than you could with any other execution environment. Autoloaders
should find your libraries if you are using the same entry point, and you can
query a model as you could in any other language. It looks like people have
made something like this for CakePHP:
[http://josediazgonzalez.com/2013/12/04/interactive-
command-l...](http://josediazgonzalez.com/2013/12/04/interactive-command-line-
repl/)

And there are some REPLs with tab completion:
[https://github.com/ErikDubbelboer/php-
repl](https://github.com/ErikDubbelboer/php-repl)

------
elwell
> The memory usage in PHP 5.5 is far less than earlier versions.

Regarding Zend Engine, does anyone have a link for just how much 'less'?

------
thegoodlab
Let the hate begin

~~~
mrcwinn
Ha! It's a pendulum that swings in both directions, and I think people are
moving on from wasting their time and energy complaining about PHP. Here's
what I have learned.

1\. Developers complain a lot, and that's a good thing. While it can seem
unproductive at times and devolve into flame wars, the truth is you're not
likely to choose this profession if you aren't curious and care about the
right damn thing happening.

It's just a byproduct of what it takes to be a good dev. We research, we
understand, and then we want to stand by our opinions because of that research
and understanding. But we can also get lost in that sometimes. It's important
to have pragmatism in our toolbelt.

At the end of the day, core maintainers or contributors make sure to cherry
pick the best from those arguments. Pull requests are made. Merges happen.
Things improve. It's not always pretty, but discourse is like that.

2\. The world isn't perfect. Neither are languages. PHP has its share of rough
spots, but then it's how you use it. We've all seen some truly awful Ruby on
Rails code, just as we've seen some solid, testable PHP code. Your job is
understand the deficiencies of a language (any language!) and craft the best
code around those limitations.

3\. Shiny new things give us blinders. The antithesis to ad hoc PHP might be
Ruby on Rails. Yet people discount some drawbacks that are unique (from PHP)
to RoR. Do generators, which are encouraged, really help teach a programmer
about how their application stack is operating? Maybe you could tell someone
to avoid scaffolding. Is Rails faster than well-architected PHP? Hell no, but
maybe you could teach someone how to tweak middleware or use JRuby. But you'll
notice the same pattern I mentioned in #2: understand deficiencies, create
workarounds to those limitations. It's not unique to PHP, or any other
language/framework.

And finally...

4\. When you are building things meant to be consumed by the general public,
more goes into a language decision than the features of that language. You
might, for example, have a business requirement to hire up and move very
quickly. Are you going to round up a bunch of seasoned, veteren Go engineers
in a few weeks to build the next sprint of some great app? It's probably not
impossible, but it's not likely either (today). The trick is to solve the
problems you actually have.

I'm not advocating everyone use PHP. I'm advocating everyone use the language
that best suits their personal or larger business needs. If you care about
improving PHP, help make it better. We, the general dev community, are all too
busy, considerate, awesome, hard-working, friendly, and creative to spend much
time on flame wars. :)

------
mjt0229
TL;DR: "sucks less?"

------
hiphopyo
Love the way they avoid mentioning Rails.

~~~
e-tron
does anyone actually use rails anymore... node is the new bling!!!

------
ing33k
same article could have been written like 1 year also .

------
dpeck
Same as the old PHP.

------
hmans
The title is misleading; I expected an article about Javascript.

------
callesgg
Never go full retard.

------
antocv
PHP is and will always be the choice of script kiddies and freelances looking
for a quick small buck.

Because it suits and is made by that niche, copy-pasted "solutions" and
monkey-ing others, just as the latest versions of PHP try to monkey other
language and framework thinking, shows a profound character of its community,
monkey-patches thrown together to look like some thought was put into it.

It is not the language of the future, its not where inventions happen.

Its still the same old to its core, pieces cobbled together to look like
something it isnt, trying to hide the inconsistencies in its core.

------
zaphar
Nothing in that article fixes the issues that make PHP unpalatable to me. They
are all new features added to the current broken set. Even if they are new and
shiny they don't make the rest of the language suddenly better.

Which is really kind of the problem with PHP. All of that broken stuff was
allowed to be broken for so long that it's effectively impossible to fix it.
All you can do is layer on more features.

