
A possible future for PHP - unhammer
http://karlitschek.de/2014/10/a-possible-future-for-php/
======
skrebbel
I'm generally very impressed by what the PHP core team is doing. The PHP
ecosystem is known for its own share of flamewars and its _wildly_
heterogeneous buildup of people (morons, geniuses, accidental programmers and
great engineers). All these people want to pull PHP in a different direction.

PHP6, with breaking changes, failed, and the core team learned from its
failure. Instead, on version 5, the amount of improvements that have been
added in the last years is frankly impressive. Supported by similar ecosystem
improvements such as Composer (PHP's _excellent_ dependency manager), it makes
PHP about as awesome as I can imagine without handing in any backward
compatibility.

I strongly doubt PHP is going to ever make any breaking changes anymore, short
of ones needed to fix Heartbleed-intensity security bugs. The core team has
shown how much awesomeness can be reached _without_ making those breaking
changes. Some holes will never be plugged, but you can't have it all.

It's like Guido van Rossum realizing that nobody wants to migrate to Python 3,
and instead making Python 2 awesomer again. It takes courage to do that, and
the PHP guys did it.

~~~
Someone1234
Why couldn't they just do what the article suggests: Quirks mode.

That's how Internet Explorer managed to move forward. The entire web was
written for IE 6, and it seemed like progression would be impossible, so they
just had everything render in an IE 6 compatible rendering engine unless the
site told them it could handle something better (via DOCTYPE).

PHP could do the same thing. Everything renders in the current PHP rendering
engine unless the *.PHP expressly tells the renderer "I'm modern!" and at that
point the new renderer is utilised.

You could even have mixed old/new sites so that old libraries can be accessed
via a modern PHP page. It might require some serious architecture work behinds
the scenes but to get a brand spanking new PHP environment with backwards
compatibility (when needed) would be a worthy goal.

~~~
pilsetnieks
Quirks mode would create a lot more work for the maintainers that could be
better used for advancing the language. If you really have an old codebase
that cannot be altered for some reason, you could keep using an old version of
PHP. I'd rather they kept 5.4 around forever as a long term support version
than doubled the complexity of developing PHP as a language. The breaking
changes and deprecations with each new version are relatively minor, if those
cannot be made to your existing codebase, you also likely wouldn't develop
anything new there and wouldn't need a quirks/strict mode.

If you really need to, you can run multiple different versions of PHP at the
same time.

------
itry
Been coding PHP for 14 years. Running several servers with PHP applications.
Serving hundreds of thousands of users a month.

None of the issues he wants to get "solved" have ever been an issue to me.

Taking away _GET, _POST and _SERVER would _introduce_ issues.

~~~
kalleboo
The only item on his list I absolutely agree with is "Unicode everywhere". I
don't understand why you'd want to filter the _GET/etc supervars on input,
it's on output you need to filter them, depending on where they're going.

The direction I want to see PHP going in is continued improvements in
consistency. Stuff like turning all those fatal errors into runtime
exceptions. And yes, making all string functions Unicode.

~~~
jcampbell1
You really don't want string functions to be unicode. Strings in php are
actually byte arrays. If you take that away, you will break far more than you
fix. You are basically killing the baby, so substr() works a tiny bit better.

I don't want to have to flag every string as unicode. It is pointless as they
already are all unicode, and it is not that bad to know the very small number
times where php's binary functions don't work (e.g. substr, regex in certain
cases).

~~~
kalleboo
> Strings in php are actually byte arrays. If you take that away, you will
> break far more than you fix. You are basically killing the baby, so substr()
> works a tiny bit better

That's a good point I hadn't thought about - processing binary files. I guess
what I really want is a "texual string" class that you can trust. The problem
right now are the inconsistent "mb_" functions that you sometimes have to use,
don't always exist, and aren't always 1:1 mappings.

------
skrebbel
> _Static typing. This is totally a question of taste but sometimes I would
> really love to have a bit more static typing in PHP. Guess what this
> following code does if you have a file named “1” in your directory_
    
    
        while ( ($filename = readdir($dh)) == true) $files[] = $filename;
    

Complete nitpick, but you don't even need static typing to fix that bug, just
strong typing (like Python has it, for example).

If there's one breaking change that I believe a very large portion of the PHP
community will appreciate, it is strong typing. In fact, it could easily be
made an option, a mode in which == and === are the same and nothing
automatically coerces. I bet that in many well-written projects, the amount of
changes needed to be able to enable this option is pretty small.

~~~
chriswarbo
Also the fact that he's basically reinventing "scandir" ;)

~~~
fein
Theres an OOP way to do this now with DirectoryIterator and
RecursiveDirectoryIterator.

[http://php.net/manual/en/class.directoryiterator.php](http://php.net/manual/en/class.directoryiterator.php)

One of the big problems with PHP seems to be the amount of "hidden" features
that you don't generally stumble upon unless you dive through the docs, or get
the right google search.

~~~
chriswarbo
> Theres an OOP way to do this now with DirectoryIterator and
> RecursiveDirectoryIterator.

OT: Iterators aren't OO.

First of all they don't work with objects/methods: we're forced to write a
for/while loop, which is procedural programming. This also prevents
abstraction and composition. Functions like "array_map" don't have these
problems.

Second, they break encapsulation since they not only expose their elements,
they also expose their internal mechanisms like "next", "rewind", etc. Again,
array_map and friends win here.

Third, since they're a massive case of 'sequential coupling' (
[http://en.wikipedia.org/wiki/Sequential_coupling](http://en.wikipedia.org/wiki/Sequential_coupling)
), and since objects are passed by reference, we must ensure that nothing we
call in our loop body upsets the ordering (eg. by performing its own loop
across the same iterator). This destroys encapsulation and modularity, and
makes polymorphism and concurrency dangerous.

Just because something uses the "class" keyword doesn't mean it's OO.

------
scrollaway
> Static typing. This is totally a question of taste but sometimes I would
> really love to have a bit more static typing in PHP. Guess what this
> following code does if you have a file named “1” in your directory

This has nothing to do with static typing and everything to do with _type
insanity_ (I refuse to call it any other name). Bash and Javascript are also
guilty of this BS behaviour. But Python doesn't have static typing, yet it
would handle this just fine.

------
cdnsteve
Consider Hack Lang [http://hacklang.org/](http://hacklang.org/). Perhaps it’s
PHP’s brightest light. FB has put considerable effort to fork PHP and
developer their own language + interpreter for good reason. Change is likely
too slow or wouldn’t be made in PHP itself.

What your describing directly points to Hack Lang. Even their syntax is: <?hh

We should all take a look at Hack Lang (myself included). It could be what PHP
7 will be in a few years but is ready and available to use today. I'm watching
this right now as motivation! (OSCON 2014: Include Hack - HHVM - PHP)
[http://www.youtube.com/watch?v=JrPGa1JDX38](http://www.youtube.com/watch?v=JrPGa1JDX38)

~~~
duggan
Agreed, I think HACK and HHVM represent the closest and most likely future for
what the author desires.

HHVM is really coming along in leaps and bounds - recently with LTS
commitments from the development team.

------
prht
Writing PHP since 2001. It gets job done & pays bills. No complaints at all. A
big thank you to all whoever made it available and improved.

~~~
jmspring
Seems like every couple if months there is a post justifying a future for
php.yet,it seems to do just fine.

It isn't the sexiest language, but a lot of people are making a decent living
working with it.

~~~
drivingmenuts
The same can be said for Visual Basic and lots of other unsexy languages.
Heck, someone out there is _still_ doing COBOL and that's the unsexiest of
beasts (that I can think of, ATM).

The trick is this: get familiar with a language now and just hang on tooth and
nail. Someone, somewhere will still be using that language when you're close
to retirement. And you can either charge them a bundle converting off of it,
or an even bigger bundle supporting it.

And if it's the government, well, as long as you don't get too careless with
the yachts, vacation homes and shady neighbors in banana republics, you can
probably get away with it until you die. Especially if you own a politician or
two.

~~~
pilsetnieks
There is even some overlap between COBOL programmers and the Github
generation:
[https://github.com/search?utf8=✓&q=language%3Acobol](https://github.com/search?utf8=✓&q=language%3Acobol)
finds 75 repos containing COBOL right now.

------
pearjuice
Friendly reminder that a PHP thread on HN cannot be had without the following:

* complaints about features it has or has not

* some snarky comments on the argument orders

* a reference to that "a fractal of bad design" article

* how language x is better

* nothing big has been built in PHP

* facebook has been built in PHP

* sarcastic and or ironic notes about the above

~~~
imanaccount247
It is interesting, because as I read through the thread I see nothing but
people justifying their like of/use of PHP despite nobody questioning it to
begin with. The number of expert beginners
([http://www.daedtech.com/tag/expert-
beginner](http://www.daedtech.com/tag/expert-beginner)) in the PHP community
seems very high, and they seem very insecure about their choice.

~~~
krapp
That may be the case, but it is also the case that Hacker News can be hostile
towards PHP and anyone who uses it. No one questions the intellectual
capabilities of people who choose Python or RoR for a project, but it happens
in threads about PHP with enough regularity that it's not surprising people
feel defensive about it.

Although, this seems to have died down a bit lately.

------
ownagefool
I wonder if people really do use ownCloud on shared hosting, is it just me or
does that seem slightly off?

For what it's worth, I quite like PHP. Start off with something like Silex,
and you have a nice little language. But, as a contractor I have to deal with
people who are afraid of package managers or expections on a regular basis and
that is far more grating than anything "a fractual of bad design" can throw at
the language.

~~~
jsamuel
> I wonder if people really do use ownCloud on shared hosting

DigitalOcean and other VPS providers are popular for hosting ownCloud.

~~~
derefr
VPS != shared hosting. With a VPS, you get to decide what packages are
installed (and what OS is installed, for that matter.) With shared hosting,
you get a Unix account _without_ administrator access, and have to put up with
whatever packages you're given.

The point being that unless you're specifically in the latter situation, you
get to decide what language platform to install and how to configure it, so
why bother making your choice of language based on that?

------
krapp
PHP already has functions like filter_input_array[0] and
array_walk_recursive[1] which get you pretty close to having an external data
filtering API already, you just have to take a couple of minutes to glue the
pieces together. There's nothing wrong with the arrays themselves, if you
treat them the way you would treat untrusted data in any language.

[0][http://php.net/manual/en/function.filter-input-
array.php](http://php.net/manual/en/function.filter-input-array.php)

[1][http://php.net/manual/en/function.array-walk-
recursive.php](http://php.net/manual/en/function.array-walk-recursive.php)

------
serve_yay
I'm kinda sick of people self-consciously talking about how they use PHP even
though it's not "hip" or whatever. It's a HUGE language, maybe the hugest, it
is everywhere.

And those of us who have used it and decided against using it further are not
obsessed with "hipness" or anything of the sort. A lot of us think it sucks
and it's broken. Feel free to disagree but please don't frame it such that
people who don't use what you use are bird-brained and obsessed with being
trendy.

------
aioprisan
Some of the largest eCommerce sites are built on PHP (Magento). OO PHP is
different than scripted PHP. I can write crappy code in Java as well, but that
doesn't make it a bad language.

------
wisienkas
How about that we just let php be as it is, it's all good now really,
eventually all the "wrongs" there was pointed out, people will get used to and
have workarounds in the base of their code instead of having to rewrite their
core project of 1M lines of code.

------
EGreg
As someone who has been using PHP to develop complex applications for years, I
have a different perspective. I realize PHP can be faster than Node in
production (thanks to efforts of people at facebook etc). Its stability can be
great because every request is naturally isolated.

But there are a couple things that make PHP much less than ideal. First of all
its latency can be legend-- wait for it-- you'll have to because it doesnt
support evented programming - ary. So if you have 100 shards to query, PHP
will in fact do all its I/O sequentially while Node and others can send it out
in parallel and combine. PHP also can't batch requests together while Node
can, so disparate pieces of code hve to know about each other's I/O requests.
Caching and Batching are two separate things. Oh yeah, and forget about
realtime push, websockets and long lived connections. PHP is good for quick
serving of requests. It works on a preforked thread model even if your
webserver doesn't.

So all these thins necessitate another server to do background processing eg
for sending out one-to-many notifications for people affected by an action in
a social app. We at Qbix choose Node because being web devs we already have to
deal with Javascript. What we mostly use PHP for are two things:

1) Generating webpages dynamically, since we believe that caching dybamic
content on many levels is superior to "static sites".

2) Web services where you need to get in and out quickly. For everything else
we have a Node server listening to actual HTTP or TCP based requests to Node,
which coordinates the session and is protected by a shared secret, as well as
communicates via the hostname localhost so an admin is not required to secure
that connection via a firewall.

PS: As far as security, you mainly just have to make sure to use APIs that do
escaping of input for you. It is true that the presence of other APIs presents
dangers and you would have to perform static analysis during code commits to
make sure no one is using THOSE APIs, but nearly every language has APIs to
write to standard output without escaping the html or javascript inside html
etc. At the end of the day, the best you can do is static analysis and
enforcing conventions.

------
jdonaldson
The Haxe language has a php target. Here's an intro (older, but still works):
[http://old.haxe.org/doc/start/php](http://old.haxe.org/doc/start/php)

Haxe has a lot of the language features mentioned here... static typing,
better namespace organization and support, etc. It's also incredibly quick to
compile, and you can easily support older php libs through externs.

As a side note, there's also a Haxe target for javascript, meaning you can
have a super nice modern language workflow for both client and server side on
legacy php/javascript infrastructure.

------
dbasedow
Most of my projects in the last 10 years have been PHP based. I still think it
has to change. There are much nicer alternatives (like Python). The reason PHP
is still so common is the low learning curve. This also attracts bad
programmers who create abominations someone else has to work with.

Some changes are more related to the runtime environment, like the whole
configuration mess that the article mentions.

I also think the PHP community lacks brilliant developers. There are many okay
and even good developers. But most PHP applications nowadays look at Java and
the abundance of design patterns that often don't make sense in a web
environment where application lifetime is usually a few years not decades.
Look at Zend Framework. It can do anything. But you need to write so much
boilerplate code that all the flexibility a scripting language offers is lost.

The PHP community needs to figure out what it wants to be. If I want to use
something that is very verbose I will use Java. If I want to move fast I will
use Ruby or Python. At the moment PHP seems to be somewhere in between.

As long as nothing fundamental changes I will only use PHP when getting paid.
For anything I do for fun I will use other languages.

~~~
aarondf
> I also think the PHP community lacks brilliant developers.

Really? How can you say that with a straight face about a community of that
size? I get that maybe you don't think _PHP_ is brilliant, but to say that it
lacks brilliant developers seems closed minded and kinda rude.

~~~
dbasedow
What I mean by brilliant developer is someone who comes up with new paradigm
shifting ideas that influence not just PHP development but other languages as
well. I have been part of the PHP community for a very long time and I have
read a huge amount of books/articles/blogs on PHP development. And I can't
recall something that really impressed me.

------
imakesnowflakes
Here is why I think that there is no future for php...

[http://www.reddit.com/r/technology/comments/2g9pux/if_progra...](http://www.reddit.com/r/technology/comments/2g9pux/if_programming_languages_were_vehicles/ckh70gi)

~~~
ceejayoz
People are still whining about namespaces?

Laravel's Translation files are namespaced Illuminate\Translation. The
database stuff is Illuminate\Database with some subsections like
Illuminate\Database\Query. Hardly complex.

~~~
krapp
If your namespaces are more than three segments deep then I believe you may be
doing it wrong. This is nothing implicit to the way namespaces work in PHP,
it's just bad design. Most Composer packages i've seen only go as deep as
vendor\package\whatever anyway. That's not difficult.

------
72deluxe
Isn't examining _GET, _POST and _SERVER manually a way of filtering incoming
data....?

------
devicenull
> Security. Kill the _GET and _POST and _SERVER arrays and introduce a proper
> API that can be used to filter all incoming data.

So, reinvent magic quotes?

> kill save_mode, open_basedir and other acient concepts

safe mode is already gone (removed in 5.4)

~~~
chriswarbo
Nothing wrong with _GET and _POST. The problem is that their elements have
type "string" instead of "unsafe_string", so PHP allows them to be used
as/with regular "safe" strings.

Edit: Except of course that they're mutable, which is stupid. In an ideal
world they wouldn't be global either; they'd only be available at the top
level, and passed into the application's initialising function/object, but
that's low on the priority list.

~~~
yuliyp
what is an unsafe_string? Did you mean "non-literal string" instead?

~~~
chriswarbo
> what is an unsafe_string?

A type I just made up.

> Did you mean "non-literal string" instead?

No. Differentiating between literal/non-literal strings would destroy our
ability to abstract and perform equational reasoning (although that's already
pretty limited in PHP).

If I want to write:

    
    
        echo "Hello " . $_GET['name'];
    

I should be prevented. However, I _should_ be allowed to do:

    
    
        echo "Hello " . htmlspecialchars($_GET['name']);
    

This is easy to do:

\- Make the contents of $_GET['name'] have a type that doesn't work for string
operators/functions like "." or "echo".

\- Make the escaping functions like "htmlspecialchars" only accept
"unsafe_string" arguments and produce "string" return values. This forces
unsafe values to be escaped, and prevents safe values from being double-
escaped.

\- If you like, go further with an "sql_snippet" type, a "html_snippet" type,
etc. and specialise the escaping functions. However, most of those values
should really be more structured (eg. HTML should be a DOM, SQL should be an
AST, etc.) since performing general string operations like concatenation on
these values doesn't really make sense.

If we used your literal/non-literal distinction, we'd need our escaping
functions to turn non-literal strings into literal strings; which doesn't make
sense.

------
sauere
All the proposed changes will lead to 5 incompatible PHP versions, 20 stupid
workaround hacks and it will break PHPs biggest feature: widespread
implementation and compability.

------
opendais
> Security. PHP in itself is not insecure and it is obviously possible to
> write perfectly fine and secure applications with PHP. But PHP decided to
> implement an quite naive approach about security and doesn´t support the
> developer too much in writing secure code. Its the same f'n approach every
> other language took. "Offload it to libraries".

> To be fair everybody was naive about web security in the 90s. So there are a
> not a lot of features available in PHP that actively support you with
> writing secure code.

> Security. Kill the _GET and _POST and _SERVER arrays and introduce a proper
> API that can be used to filter all incoming data.

Actually, they tried to implement the kind of "security features" you suggest
and it was a disaster because the compiler isn't aware of the context the
programmer is. Things like magic quotes, etc. were tried. All failed because
its a bad idea.

This suggestion is horribly ignorant and misguided.

> Database. PHP support a ton of different database API. Some of them are very
> old but they are inconsistent to use. Everything should be standardized so
> that only one OO interface exists. I personally would use PDO as a starting-
> point here.

Give up MYSQL ASYNC? Fuck No. I am not re-writing entire libraries into C to
regain access to something I need. There are also differences between Postgres
and MySQL implementations, etc. for reasons other than "Oh we felt like it".
There needs to be one, consistent driver for each database. PDO isn't the
answer.

The fundamental issue seems to be the author is ignorant of the fact there are
reasons some of this stuff does or doesn't exist.

> Remove most of the compile and runtime config options. All PHPNEXT runtime
> environments should be as similar and stable as possible.

Fuck no. That is why Dev & Ops get together and pick "We want combination X to
work with, godspeed!".

> The database situation is a mess so a lot of people still don´t use prepared
> statement which leads to possible SQL injection.

That is the carpenter failing to use the hammer correctly issue. You can't
magically make people do things correctly.

> And filtering incoming data for XSS and other problems has to be done
> relatively manually. There are extensions and libraries available to help
> with all this problems but they are not part of the language/runtime core or
> are incomplete.

Of course it does. Without knowing the context (say, expecting a date vs.
markdown), it would be an awful idea. Security is entirely about the context
and expectations. You can't do a one-size-fits-everyone-for-all-uses approach
and build into the language. That is insane and doomed to fail. PHP tried it
before.

~~~
chriswarbo
tl;dr Stop allowing everything to be concatenated with everything else, and
just because PHP tried bad solutions to a problem doesn't mean that problem is
unsolvable.

> it was a disaster because the compiler isn't aware of the context the
> programmer is

This is completely true, but the underlying cause is that everything is a
string. As long as the "solution" is converting strings into strings (eg.
magic quotes, escaping, etc.) they're doomed.

At a previous job we modified the PHP interpreter to give user input a 'dirty
bit'. Dirty bits spread to anything they touched (dirty . clean -> dirty,
implode(dirty, [clean]) -> dirty, etc.). Trying to output dirty strings (to
stdout, DBs, files, etc.) was a fatal error.

Escaping functions unset the dirty bit. Escaping a non-dirty string was a
fatal error. This worked quite well.

> > introduce a proper API that can be used to filter all incoming data.

> Things like magic quotes, etc. were tried. All failed because its a bad
> idea.

Not really. Making everyone access GET/POST vars in the same way is a bad
idea. Better to provide getter functions like "get_param_unsafe" and
"post_param_unsafe" for this, then provide a bunch of common alternatives
which provide escaping like "get_param_html", "post_param_quoted", etc.

Even safety-conscious languages like Haskell know that there's no one-size-
fits-all approach; but as long as you cover the basics and give scary names to
your escape-hatches (eg. "unsafePerformIO", "unsafeCoerce", etc.) then it
limits the damage.

"unsafe" is basically a big red warning sticker, telling you to pay extra
special attention to what's going on. It only ever occur in custom
validation/sanitising code, eg. in the definition of
"get_param_my_custom_format". If a codebase has "unsafe" all over the place,
that's an alarm bell which says the code is dangerous and needs to be
refactored to provide and use some safe APIs.

> PDO isn't the answer.

Meh, library problems. PDO shouldn't be baked into the language, but neither
should anything else.

> You can't magically make people do things correctly.

Yes you can: you can make it impossible/very difficult to do it incorrectly.
Again, stop allowing everything to be concatenated with everything else and
this issue will be magically resolved.

> Without knowing the context (say, expecting a date vs. markdown), it would
> be an awful idea.

If only PHP were capable of providing some kind of "interface", which other
code could "implement"...

~~~
opendais
I think the problem here is you think it should be a language function and I
think it should be an extensible external implementation. The problem is the
blacksmith, not the tool. LOLPHP stuff is consistent in how it happens. It
doesn't magically change. So, if you know it happens, you adjust and adapt.
Its not wonderful but adding more magic is the opposite of the solution.

The solution is to get rid of all the magic language features that don't work
quite right and clean up the ones that do.

> Meh, library problems. PDO shouldn't be baked into the language, but neither
> should anything else.

That is kind of my point. All of this should be separate implementations.

> tl;dr Stop allowing everything to be concatenated with everything else, and
> just because PHP tried bad solutions to a problem doesn't mean that problem
> is unsolvable.

Provide evidence of a truly secure language with all potential contexts baked
in.

> Not really. Making everyone access GET/POST vars in the same way is a bad
> idea. Better to provide getter functions like "get_param_unsafe" and
> "post_param_unsafe" for this, then provide a bunch of common alternatives
> which provide escaping like "get_param_html", "post_param_quoted", etc.

Quoting strings is not security. People will use that "post_param_quoted" just
like magic quotes and everything else and fuck it up.

> Yes you can: you can make it impossible/very difficult to do it incorrectly.
> Again, stop allowing everything to be concatenated with everything else and
> this issue will be magically resolved.

 _Concatenating quoted strings to each other is an unsafe operation._

So, no, you can't.

> If only PHP were capable of providing some kind of "interface", which other
> code could "implement"...

It does. There are security libraries you can use. Its not a language feature.
PHP has repeatedly failed at attempting to add security-as-a-language-feature
because its complicated, difficult, and most people won't understand it
anyway.

------
Mithaldu
This blog is an astoundingly beautiful example of why this website is
necessary: [http://contrastrebellion.com/](http://contrastrebellion.com/)

------
exstudent
My problem with PHP is that it's a signal of developer laziness. There are a
lot of very interesting things going on with languages nowadays. If you
develop in PHP because "it pays the bills" you ARE NOT the type of developer I
ever want to work with.

Honestly, I'm starting to see the same thing with Python/Ruby/JS devs. Stick
with one language that you're comfortable with and never push yourself.

PHP is an order of magnitude worse in that respect than the other scripting
languages.

~~~
ceejayoz
You sound like
[https://twitter.com/hipsterhacker](https://twitter.com/hipsterhacker).

~~~
exstudent
I have been retweeted by it :P

I stand by my opinion though despite the (anticipated) downvoting. Programming
in PHP is anti-intellectual.

