Removing stuff from a programming language has virtually no benefit and a huge real economic cost. That, of course, is under the assumption that the programming language has users.
I could see them deprecating some stuff, and adding yet another E_EVEN_STRICTER level that tosses ugly notifications when deprecated things are done. That would be nice.
Hmm, but does it have to be that way? What if every new version of a programming language came with a tool that converted old source code to new source code, like Python's 2to3? That way you could cleanly handle removals, renamings and all sorts of other changes... maybe even provide implementations of old library functions in terms of new ones.
Automatically updating someone else's code is more difficult than it seems. Any Python project of significant complexity will need manual adjustment before or after passing it through 2to3, and even then you'll need to perform a lot of tests to make sure that everything behaves as expected. Similarly, the upgrade wizard in .NET always breaks a thing or two. I would expect a PHP upgrade wizard to fare no better.
For example, PHP allows you to keep the name of a function in a variable and call it as if it were an anonymous function. So you can do something like:
Of course, it's probably a bad idea to do this unless you really have no other option. (By the way, the above example is not how Lithium uses $h. But we can easily imagine a lame imitator doing the above.) But given that some programs do rely on features like this, how would you update them automatically if you decided to change the way htmlspecialchars() works?
Things get even more complicated when functions change in more subtle ways. If a function that used to return FALSE on failure is updated to throw an exception instead, an automated tool would have to wrap every function call with a try-catch block, with potentially unexpected side effects. If a function that used to take strings in the system charset by default is updated to take UTF-8 all the time, you'll have to throw in some code for charset conversion before every occurrence of that function, but some servers might not have mbstring/iconv installed and turn that into a fatal error.
A better solution is actually what PHP has been doing for the last few minor versions: deprecating stupid functions like mysql_real_escape_string() and encouraging people to migrate to modern alternatives. Once a function is marked as deprecated, it will be removed in a few years. This process takes longer, but it gives everyone enough time to update their own programs.
> how would you update them automatically if you decided to change the way htmlspecialchars() works?
I see two possible cases, the choice between which can be made by the converter developers or by the user (maybe via command-line flags to the converter):
1) If the new functionality is intended to be a drop-in replacement (e.g. it fixes a security bug), no change is necessary.
2) If we want existing programs to keep using the old functionality, you could automatically translate all cases like this (assuming we're translating from PHP7 to PHP8):
echo $h('<script>'); // PHP7 code
to this:
echo php7_varcall($h, '<script>'); // PHP8 code
To clarify, php7_varcall() is a function in PHP8. When it receives 'htmlspecialchars' as an argument, it calls the function php7_htmlspecialchars() which is a faithful rewrite of PHP7's htmlspecialchars() in PHP8.
> If a function that used to return FALSE on failure is updated to throw an exception instead, an automated tool would have to wrap every function call with a try-catch block, with potentially unexpected side effects.
In general, any php7_builtin() should be implementable in PHP8 somehow. If that's not possible, I'd say there's a gross design error somewhere.
> If a function that used to take strings in the system charset by default is updated to take UTF-8 all the time, you'll have to throw in some code for charset conversion before every occurrence of that function, but some servers might not have mbstring/iconv installed and turn that into a fatal error.
In general, if the implementation of php7_builtin() in PHP8 relies on some library, then that library should be included in the "compatibility library" required to run all converted code.
So your solution is to add more functions, like php7_htmlspecialchars(), php7_htmlentities(), etc. whenever a function needs to be deprecated, just like PHP historically added functions like mysql_escape_string(), mysql_real_escape_string(), etc.? I don't think that will help the language and its ecosystem at all. I can almost see the tutorials in my mind: "If you upgrade to PHP 8 and your function call suddenly starts spewing errors, just use php7_function and your problem is solved!" Then 3 years later: "just use php8_function!"
Anyway, my point was that static analysis, which an upgrade script needs to perform, has serious limitations when it comes to dynamic features. Callable variables are a good example of this. What if there are 100 places in your codebase where a variable is callable, but only one of them is ever going to contain a deprecated function? Static analysis can't tell which one it is, because at runtime, the variables might come from anywhere: user input, a database, a command-line argument, or the phase of the moon. The only bulletproof solution is to convert them all to php7_varcall(), even the 99 variables that don't need upgrading. But then your code just becomes unreadable, and therefore even more unmaintainable than before.
Functions like php7_htmlspecialchars() wouldn't live in the standard library, they would live in the "compatibility library" instead. That might help discourage new users from using them and mentioning them in tutorials.
I agree with your point that bulletproof conversion will make reflection-heavy code less readable. But still, if we can make a bulletproof converter that works on 100% of old code and leaves simple code relatively unchanged, doesn't that open up some nice options for everyone?
- Users who don't care about code quality, and just want their old code to work, will be happy because they will have a push-button upgrade solution.
- Users who care about code quality will also be happy, because they can run the converter and have a complete working program right away. Afterwards they can modernize it piece by piece, at their own pace, having a complete working program at each step. Without the converter they'd be stuck doing a full rewrite.
- Language implementors will be happy because they can keep the language clean as it evolves. Imagine how awesome Java could be today if they took this route.
I sort of agree with you, but then I come at it from the view point of why choose PHP? Myself, I can't think of a single awnser, but then again I'm the kind of person who learns a programing language or paradigm for fun.
However there is an elephant in the room with PHP, it has, quite frankly some terrible creations made by it. In much the same way MS had a whole bunch of technologies around DCOM and the like which suddenly found themselves disabled and strongly advised against use in XP SP2. I think PHP really does need to try and clean up its image.
The whole 'lets go find some sql injection vulns on github' game demonstrates many people still use the tool badly.
At what point does someone say, that they should re-design the tool, so that they encourage better use.
I'll be honest, if I hear someone say "we're using php for this" I assume its just because they are ignorant of other languages. I can't think of any problem I've been faced with, where PHP is the best solution.
So ultimately, if your going to try and remove stuff, why bother, you'll only break the existing projects, rather than improve them. The best thing is to treat the language as depreciated.
> I think PHP really does need to try and clean up its image.
Sorry, but you obviously have not been taking notice over the past year or two. PHP really has been cleaning up its image. Go have a look at PHP-FIG, composer and packagist for starters.
Yes, there are problems. Yes, some/most may think that there are better solutions. But to think that PHP has not been "cleaning up its image" is just wrong.
>Sorry, but you obviously have not been taking notice over the past year or two.
I'll admit, I haven't really, because I'll turn it round, why would I?
We've seen Erlang start to be used quite a lot, Scala is becoming very interesting, and F# is appearing suitably mainstreme.
What features would make me think "hmm, I should check out what they are doing in PHP"?
Looking now I still see a cluttered array of APIs, some pretending they are C from the 80s, others hinting that they at least knew of objects in their design.
What I do again see, are PHP developers who are not fluent in any other language. I always find that odd. For instance I've been doing mostly C# since version 2. But I would probably pass most Java or CamL interview questions anyone had. I am happy in C# knowing what I am missing from other languages (well, not happy, just its the right choice for the things I've been doing).
In short, PHP has an image problem with plenty of people. I am one of them. They can't easily solve it, without breaking a whole bunch of existing code, as most of my complaints are inherent languages features and core API design (or lack there off). I don't nock languages that eschew OO, but I do nock ones that implement it, just very, very badly.
>Your definition of mainstream must differ from the dictionary's.
I have got the same two agents constantly bugging me "oh you know some Erlang right?" at the moment, but the only one that I begin to describe as mainstream is F#.
If your in any kind of LOB space which deals with 'Maths' F# is rampant now. Which is handy for me, as I used to instruct labs on OCaml at uni.
Just using www.inqjobs.co.uk looking in London for contract rates on 500pd+ I find over 20 roles for F#. Compare that to the Python or Ruby number.
That to me, is mainstream. Not quite Java/C++/C# league, but certainly out there.
From an engineering perspective you're probably correct. However, from a commercial perspective (be it long-term support, business continuity, cost of developers/support) PHP is one of the best solutions.
Well actually I don't use PHP that much anymore, but I do keep an eye on it; there's been a lot of improvements, mostly on the ecosystem side.
It's definitely not my language of choice, but one still has to eat, and PHP jobs are unfortunately way more common than most other stacks around here, outside of the enterprise stuff which I'm currently doing.
Removing things from a language is a difficult proposition. I think increasingly a case could be made for a cleanup of many of the core functions, and I personally would remove some of the OO sugar coating added as of late. But that's probably more trouble than it's worth.
As core function naming and argument order is a pet peeve of mine, I would welcome a cleaned-up API2.0 if you will, while beginning the long phase-out of the old one.
I would agree though that some features should not have been added in the first place. But they're in now, and once they are in they should probably stay in for a while.
That's pretty much what I had in mind with this comment, I should have expanded it a bit. What grates on my nerves when writing PHP is indeed the awfully inconsistent standard library.
Though some syntax choices (namespaces for instance) are also pretty weird.
Maybe someone should fork the parser/lexer and see what a cleanup can accomplish. There are a few tons of "features" I would delete immediately. And I agree the namespace syntax is horrible.
> Am I the only one thinking PHP needs more stuff removed rather than added ?
You can remove things yourself? The PHP codebase is extremely modular. Just compile your own PHP and leave anything you don't want out. Has a wonderful --disable-all flag and then you just add the stuff you need.
Removing stuff from a programming language has virtually no benefit and a huge real economic cost. That, of course, is under the assumption that the programming language has users.
I could see them deprecating some stuff, and adding yet another E_EVEN_STRICTER level that tosses ugly notifications when deprecated things are done. That would be nice.