A possible future for PHP
karlitschek.de
karlitschek.de
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.
Many of the other changes the author mentions like static typing, new tags made me believe he hasn't really looked into Hack/HHVM except that he mentions it at the end. Still, while I think that is a great product with a lot of potential, the small incompatibilities that still exist and prevent current frameworks and libraries from running on it are the main deterrent to committing and switching to it. Still, as those incompatibilities get fixed, it becomes a more attractive platform.
In the rush for "cleaner" code with more "modern" APIs, a lot of programmers miss the much more important issue of backward compatibility and being able to run mature applications. I would much rather have a language and runtime that can run some of the most useful software out there (Wordpress, Drupal, Magento, Wikimedia) that may not have the cleanest looking code out there, than a pretty language that has few useful programs. This has always been PHP's strongpoint and in respect to server apps, nothing else is even in the same ballpark.
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.
If you really need to, you can run multiple different versions of PHP at the same time.
Source?
> It's [as if] Guido van Rossum realiz[ed] that [...]
My hunch is change at web-scale (when you care about community adoption) can only happen when it's done in a thoughtful, incremental fashion.
I'm sorry to say that this is not an accurate portrayal of how PHP is to be developed in the future. There will be a new major version of PHP: so-called PHP 7 to avoid confusion with the defunct first attempt at a PHP 5 successor.[1] This new major version will contain a completely new engine[2] that is definitely not backwards-compatible with PHP 5 extensions (though it should be backwards-compatible with userland code). The new major version also opens the door for any userland-level breaking to the language; the first three of which are a change to integer semantics,[3] an AST,[4] and a uniform variable syntax.[5]
Instead, I'd characterize PHP 5.3-5.6 as more pragmatic than visionary: PHP 6's major backwards-incompatible feature was going to be full Unicode support, and when that didn't pan out, PHP 6 no longer had a raison d'être. Instead of holding onto a number of useful language features for a few more years until a new major backwards-incompatible change was developed (now the new parse engine), they backported them to PHP 5.
[1]: https://wiki.php.net/rfc/php6
[2]: https://wiki.php.net/rfc/phpng
[3]: https://wiki.php.net/rfc/integer_semantics
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.
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.
I get that the solution he proposed is different, and also reasonably sane, but isn't this basically what magic quotes did? Now that that nightmare is finally over, I'm not too keen on reliving it again.
The real world still has and probably always will have a lot of text in other encodings - Latin-1, Shift-JIS, heck even things like GSM03.38.
I like how Ruby handles it - every string has an encoding attached, and manipulations with non-compatible encodings will complain.
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).
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.
while ( ($filename = readdir($dh)) == true) $files[] = $filename;
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.
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.
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 ), 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.
It's not my only argument. Here's what I wrote on the blog's own comments:
> I agree with your points, but picking this line as an example of the language’s problems
> is a bit of a straw man:
>
> “while ( ($filename = readdir($dh)) == true) $files[] = $filename;”
>
> Code like this smells terribly.
>
> First of all it uses “==”. That operator should trigger a deprecated warning, since it’s
> never appropriate. Even if you want the coercion, it’s better to write it explicitly with
> things like (int) or intval().
>
> Next, it’s using “== true”, which is completely redundant since the “while” will interpret
> the value as a boolean anyway.
>
> Next, it’s performing assignment inside a condition, which is generally frowned upon.
> There’s potential to confuse “=” with “==” or “===”, it’s using a statement in the place of
> an expression and it performs side-effects (setting the $filename value).
>
> After all that, it’s just duplicating existing functionality anyway: you could just say
> $files = scandir($dh).
Some libraries are written assuming <? is fine, some aren't. But god help you when you try to merge them in.
As PHP has grown older, less of these strange incompatibilities continue to be supported (safe mode, etc), and I'm thankful for that.
It could even be a function modifier.
Unlike static typing or const correctness or immutability, strong typing is a very local feature that doesn't "bubble" across your codebase once you start using it.
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.
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
HHVM is really coming along in leaps and bounds - recently with LTS commitments from the development team.
As for adoption, the only stat that I could find was adoption for HHVM[1] (a virtual machine for executing Hack and PHP[2]), but since they list Wikipedia among the HHVM adopters, I'm pretty sure this does not equate to adoption of Hack itself.
[1]:https://github.com/facebook/hhvm/wiki/Users [2]:http://hhvm.com/
It isn't the sexiest language, but a lot of people are making a decent living working with it.
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.
This is actual curiosity, I just can't think of anything that PHP has that Ruby and Python don't. Even more so when it comes to Go. But you didn't mention Go.
* 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
The "several reason for choosing PHP" surely apply to Python even more than they do to PHP?
I'm not sure why PHP got in that situation, but I expect that to change with VM and Docker becoming pretty cheap. Now you can have a low-cost hosting of any language.
Although, this seems to have died down a bit lately.
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.
Huh? Sharepoint Online (which kind of competes with OwnCloud) is massively popular and is at the heart of Office 365. So, yes, people want that kind of centralised file sharing infrastructure likely for inter-company or inter-group work.
A lot of small teams and small companies will just buy a pre-built (often shared) solution (e.g. email, website, collaboration suite, etc). Since they lack the internal expertise to manage their own equipment or to rent a VPN and "do it themselves."
"Shared hosting" is typically referencing you sharing a server with other people and you'd typically have ftp access by default, shell access by request. Typically they don't have a lot of seperation and any user can upload a script that'll become a runaway process or allow remote execution.
I'd be suprised if "teams" were doing this, as soon as you start adding in jails, process seperation, etc, you might as well be selling managed VPS and then it's no longer "shared hosting" in the traditional sense.
DigitalOcean and other VPS providers are popular for hosting ownCloud.
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?
Also important to my point because on a DO server you can install python or ruby, it's only on shared or managed servers where picking PHP because it's ubiquitous is valid idea. Shared hosting is often limited to PHP, SaaS and VPS providers are not.
[0]http://php.net/manual/en/function.filter-input-array.php
[1]http://php.net/manual/en/function.array-walk-recursive.php
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.
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.
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.
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.
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.
I also think the PHP community lacks brilliant developers.
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.
As long as nothing fundamental changes I will only use PHP
when getting paid.
If there's one thing that I found impressive about the Perl community, typified by Perl Monks, it was that any question, no matter how stupid, was always answered thoroughly and respectfully.
There's no analog in the PHP world. It's too diffused. The people that are making a living writing world-class PHP applications don't talk to those just getting started and doing everything wrong.
If your complaint is that there's no PHP-analog to Perl Monks, well then I'd have to say that it does exist, but you need to go to more targeted communities to find it. The CodeIgniter community was immensely helpful. The Laravel community is now large and very helpful. Even the Phalcon community, which is tiny, is great. So while there might not be this one massive PHP Monks community, a similar version does exist in PHP projects' communities.
http://www.reddit.com/r/technology/comments/2g9pux/if_progra...
Laravel's Translation files are namespaced Illuminate\Translation. The database stuff is Illuminate\Database with some subsections like Illuminate\Database\Query. Hardly complex.
So, reinvent magic quotes?
> kill save_mode, open_basedir and other acient concepts
safe mode is already gone (removed in 5.4)
When configured correctly your application never experiences a problem, and can only write to paths it is directly allowed to. This prevents a security breach from accessing the system's configuration files. Disable it when you're building a system-level configuration package, but use it for all consumer-grade web applications.
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.
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'];
echo "Hello " . htmlspecialchars($_GET['name']);
- 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.
> 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.
> 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"...
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.
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.
I stand by my opinion though despite the (anticipated) downvoting. Programming in PHP is anti-intellectual.