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.
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.
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.
> why you'd want to filter the _GET/etc supervars on input
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.
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).
> 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.
> 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'm not sure if this could be easily built into PHP, but per-directory options are supported by PHP (when on apache, via a .htaccess file). If you could turn on or off strong typing per directory (or, alternatively, per file much like JS's "use strict"), there wouldn't be much of a practical problem.
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.
Allowing .htaccess comes with a performance hit (Apache has to scan the directory and all of its parents for a .htaccess file on every pageview) and should generally not be used unless strictly necessary.
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.
> 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 ), 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.
That's just a bad argument. Simple code that suddenly breaks because of the contents of a directory shouldn't be possible, whether or not said simple code is unnecessary because of a standard library function. The example stands, weak typing is a horrible vector for difficult-to-catch bugs.
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.
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.
In addition to the oft-cited deployment story, I think another reason for PHP's success is that it's the only major language specifically created as a DSL for rendering web pages. Once you're accustomed to having its baked-in toolset for web-related tasks, having to constantly hunt for the right third-party library in a general-purpose language like Ruby or Python becomes a major drag coefficient, even if those languages are objectively better in all other respects.
What features are built in to PHP that aren't built in to Ruby and Python?
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.
I'd say the number one reason a lot of open source projects use PHP (Wordpress, Magento, etc.) is because that's what you can run on dirt-cheap shared hosting.
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.
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.
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.
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."
Uh, that's not really the type of shared hosting I was talking about, that's Saas.
"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.
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?
See response to sibling, shared resources isn't the same thing as "shared hosting". Pedantic I know, but an important distinction within the industry.
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.
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.
It's not that the PHP community lacks smart developers, it's that they lack smart developers that really work with the people who have no idea what they're doing to improve everyone's skill.
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.
I mean, I see what you're saying, but that's got to be speculative at best. I don't know if you can pin that problem down to a particular language. The PHP community is massive and most questions are answered already somewhere online. I have seen PHP developers assume people coming from other languages should just pick up and know PHP's quirks and for that the PHP devs should be faulted.
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.
> 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.
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.
Laravel's Translation files are namespaced Illuminate\Translation. The database stuff is Illuminate\Database with some subsections like Illuminate\Database\Query. Hardly complex.
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.
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.
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.
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"...
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.
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.
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.