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.
I couldn't agree more. Most of the features mentioned as possible changes like a constant DB API, removing superglobals, ignoring php.ini configuration, etc. are already possible and available in PHP right now alongside the outdated aforementioned APIs. It's all about how you decide to approach and code an application. For most applications those things are no longer issues and haven't been for many years due to libraries abstracting away and essentially "deprecating" (but without removal) such functionality. This allows old code to stay backward compatible while new code to be incredibly clean.
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.
> 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.
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.
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.
Very interesting observation. Perhaps the community's reluctance to change (with some of these large open-source projects) is the same kind of dynamic you get within large multi-national corporations where not only are people within those organizations reluctant to make large changes, but once you've reached a certain scale it's just plain difficult to make changes happen.
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.
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.
> 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.
I whole-heartedly agree here. You really shouldn't have to implement workarounds to know you're comparing two integers, or two booleans. === feels like a workaround to me and the amount of times I've seen people forget the last = is high. That's probably my #1 gripe with PHP.
> 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.
Consider Hack Lang 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
I'm not sure if this was added to the article after your reply, but the author mentions Hack specifically, along with some caveats about it's adoption, namely that it is currently unkown how widespread Hack will be and how you're basically at Facebook's mercy in regards to the future of the language.
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.
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) in the PHP community seems very high, and they seem very insecure about their choice.
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.
> I wonder if people really do use ownCloud on shared hosting, is it just me or does that seem slightly off?
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."
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.
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.
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.
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.
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.
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.
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.
I also think the PHP community lacks brilliant developers.
I had to downvote you for this crap. What's odd is how easily it slips into the comment, as if it's assumed that anyone who uses PHP is "lesser". Here's a tip in life: there are 0 times where you should say any developer 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.
You list one example of a framework that is "large but cumbersome", and somehow PHP has an identity crisis?
As long as nothing fundamental changes I will only use PHP
when getting paid.
I would love to see something you put together in PHP. I'm seriously questioning whether you have ever written any PHP code at all, or if the sum of your PHP knowledge is just patching Wordpress plugins for side-money.
> 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.
Laravel's Translation files are namespaced Illuminate\Translation. The database stuff is Illuminate\Database with some subsections like Illuminate\Database\Query. Hardly complex.
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.
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.
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.
> 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.
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"...
[+] [-] skrebbel|11 years ago|reply
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.
[+] [-] joesmo|11 years ago|reply
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.
[+] [-] itafroma|11 years ago|reply
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
[4]: https://wiki.php.net/rfc/abstract_syntax_tree
[5]: https://wiki.php.net/rfc/uniform_variable_syntax
[+] [-] Someone1234|11 years ago|reply
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.
[+] [-] datashovel|11 years ago|reply
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.
[+] [-] sauere|11 years ago|reply
Source?
[+] [-] itry|11 years ago|reply
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|11 years ago|reply
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.
[+] [-] rabino|11 years ago|reply
[+] [-] fein|11 years ago|reply
[+] [-] skrebbel|11 years ago|reply
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.
[+] [-] DanHulton|11 years ago|reply
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.
[+] [-] chriswarbo|11 years ago|reply
[+] [-] mikegioia|11 years ago|reply
[+] [-] scrollaway|11 years ago|reply
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|11 years ago|reply
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
[+] [-] duggan|11 years ago|reply
HHVM is really coming along in leaps and bounds - recently with LTS commitments from the development team.
[+] [-] vderas|11 years ago|reply
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/
[+] [-] prht|11 years ago|reply
[+] [-] jmspring|11 years ago|reply
It isn't the sexiest language, but a lot of people are making a decent living working with it.
[+] [-] pearjuice|11 years ago|reply
* 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|11 years ago|reply
[+] [-] lotsofcows|11 years ago|reply
[+] [-] ownagefool|11 years ago|reply
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.
[+] [-] UnoriginalGuy|11 years ago|reply
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."
[+] [-] jsamuel|11 years ago|reply
DigitalOcean and other VPS providers are popular for hosting ownCloud.
[+] [-] krapp|11 years ago|reply
[0]http://php.net/manual/en/function.filter-input-array.php
[1]http://php.net/manual/en/function.array-walk-recursive.php
[+] [-] serve_yay|11 years ago|reply
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|11 years ago|reply
[+] [-] wisienkas|11 years ago|reply
[+] [-] EGreg|11 years ago|reply
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|11 years ago|reply
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|11 years ago|reply
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.
[+] [-] mikegioia|11 years ago|reply
[+] [-] aarondf|11 years ago|reply
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.
[+] [-] prht|11 years ago|reply
[+] [-] imakesnowflakes|11 years ago|reply
http://www.reddit.com/r/technology/comments/2g9pux/if_progra...
[+] [-] ceejayoz|11 years ago|reply
Laravel's Translation files are namespaced Illuminate\Translation. The database stuff is Illuminate\Database with some subsections like Illuminate\Database\Query. Hardly complex.
[+] [-] ThomPete|11 years ago|reply
[+] [-] 72deluxe|11 years ago|reply
[+] [-] devicenull|11 years ago|reply
So, reinvent magic quotes?
> kill save_mode, open_basedir and other acient concepts
safe mode is already gone (removed in 5.4)
[+] [-] chriswarbo|11 years ago|reply
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.
[+] [-] trebor|11 years ago|reply
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.
[+] [-] sauere|11 years ago|reply
[+] [-] opendais|11 years ago|reply
> 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|11 years ago|reply
> 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"...