I was recently made aware of an article written by Owen called PHP, RFCs and Changing fundamental language behaviors. Like him I have been following the discussions on RFCs by the members of the internals group regarding proposed changes to the language, and like him I am becoming increasingly alarmed at the number of features within the language that are being proposed for removal. Nothing can be (or should be) removed from the language without being deprecated first so that users of such features get a deprecation notice in their error log which then gives them time to alter their code before that feature's removal in the next release.
While certain features of the language, which seemed like a good idea when they were first introduced in the 1990s, were deprecated and then removed, they were done so for legitimate reasons. I am talking specifically about register_globals, magic_quotes and safe_mode which were regarded as security threats. Since then a large number of other features have been removed for what I would consider less than legitimate reasons such as:
You should see from this list that the arguments are based on nothing more than personal opinions. There is no single definition of "properly" or "best practice" which is universally accepted by ALL programmers, there are just different opinions from individuals or small groups. Different groups may have their own programming style, but no group should ever be allowed to force its own style on others. I have used more than a few languages in my long career, and I have never used every feature in any of those languages. I use those features for which I can find a genuine use, and I ignore the rest. I have developed my own particular style of writing code, but I do not try to enforce this style on others unless they wish to join my team. I have released some of my code as open source, so it is up to you whether you use it or not. If you don't like it then don't use, but what you should NEVER do is complain that you don't like the way in which it was written as I will send you away with a flea in your ear.
I share your concerns. Like you I still support and maintain a framework which I started to develop in 2003. I used this framework to build an ERP application, and I have been actively maintaining and enhancing both the framework and the application since then. This application is now being sold all over the world to multi-national corporations.
I switched to using PHP at the start of the century because I discovered that I could become more productive than I had ever been with any of my previous languages. It was easy to learn in that it was possible to construct a working program very quickly using simple instructions, yet it was also possible to write code with more complexity. PHP was the first language I used with OO capabilities, and PHP 4's object model made it easy to develop code which provided large amounts of reusability using encapsulation, inheritance and polymorphism. Although the object model has been greatly extended since the days of PHP 4 the only post-PHP4 feature which I use has been to include the word "abstract" in my generic table class. I do not use any of the other "enhancements" simply because I cannot find a use for them. This is because I am an avid follower of the KISS principle (Keep It Simple, Stupid) which means that I strive to achieve complex results using simple code. Unfortunately there is a growing number of people who seem to follow the KICK principle (Keep It Complex, Knucklehead) in that they like to achieve simple results using complex code.
Too many of today's young programmers have the wrong idea about what makes a programming language popular. Notice I said "popular" and not "perfect". The former concerns the number of people who like the language so much they use it for their application development while the latter is nothing more than a mythical concept as different people will have a totally different opinion on what "perfect" actually means. Which is the more successful language? One which is used by millions yet which a few regard as imperfect, or one which is regarded by a few as perfect and only used by an insignificant number?
Surely it is the opinion of the millions of users which count, not the opinion of a few critics. If those critics don't like the language there is a simple solution - don't use it. Instead these people like to spend their time in changing the language so that it conforms to their idea of perfection, and they don't care that these changes make software which has run for years, sometimes decades, totally unusable. This growing trend of trying to appease a few load-mouthed critics instead of trying to expand the current user base is, I believe, a step in the wrong direction which needs to be reversed. Improvements to the language should be restricted to additions and not deletions. It is a good idea to update the language so that it runs faster, or to add new functions at the request of those programmers who make a living by programming in PHP, but deprecating existing functionality prior to their eventual removal should be limited to those parts which represent a security risk, such as register_globals, magic_quotes and safe_mode. Requesting that something be removed simply because you don't like it should result in the requestor's instant dismissal from the team.
In your post you refer to these critics as "Modern Programmers" (MP) who are new to the game and whose minds are full of wild theories and devoid of practical experience. I call these people "Johnny-Come-Latelys" (JCL) or "Clueless Newbies" (CN). PHP became a popular language because of the brilliance of its original authors, which started with Rasmus Lerdorf and then included Zeev Suraski and Andy Gutmans. They delivered what the userbase wanted, which was a programming language that was quick and easy to learn for the initiate, yet powerful enough for the more experienced. This culminated in it being the 5th most popular language according to the TIOBE index in 2004 and rising to be 4th in 2009.
Since that glorious time there have been numerous updates to the language, yet its popularity (or lack thereof) has caused it to slip down to 8th position, and the signs are that it will fall even lower. Even more worrying is the slow take up of new releases by many existing websites simply because they cannot upgrade as their code simply will not work in the new release. Code that worked perfectly well in release N no longer works in release N+1. The only way to make it work is to spend time and effort in going through the code and replacing all those references to "imperfect" functions or constructs to whatever today's fashion is deemed to be. The amount of time and effort which is required could be quite considerable, yet most companies that use PHP applications simply do not have a budget for such an expensive exercise.
Although my own framework and ERP application were originally written using PHP 4 I have been able to upgrade to each new release with very little effort simply because I used few features that have been deprecated:
These were all BC (Backwards Compatibility) breaks in that they broke previously working code, but unlike the removal of register_globals, magic_quotes and safe_mode they did not remove something that caused a genuine problem, only a perceived problem.
This brings me to the point of your post in that there are some members of the internals group who actively seek to destroy the language by changing fundamental language behaviours. They may choose to use the word "improve" instead of "destroy", but the simple fact of the matter is that if you change the language for no good reason so that previously valid and working code no longer works then that is a destructive change and not a constructive one. Notice the use of the term "good reason". The fact that you don't like something does not qualify. The fact that you don't think it follows "best practice" does not qualify. The fact that it does not follow your personal programming style does not qualify. Unless it matches the criteria used by register_globals, magic_quotes and safe_mode it does not qualify.
It has been a fundamental part of the language since it was first conceived that, as a dynamically typed language, you do not have to define a variable before you use it. This also means that you can reference a variable without it having been declared beforehand, in which case it triggers an E_NOTICE which can be picked up in your error handler and written to the error log. The fact that some modern programmers think that this is bad practice and should be outlawed is irrelevant. If you don't like the practice then don't use it, but don't assume that you have the authority to tell all those millions of other PHP programmers that their applications, which have worked for years or even decades, need to be changed in order to match your personal description of "best practice". There is no single definition of "best practice" which works for everyone. What works for some does not work for others, or, to put it another way, one man's perfection is another man's putrefaction.
The person who wrote PHP's arrays aren't really arrays is, IMHO, talking out of the wrong end of his alimentary canal. He is clearly using a definition of "array" which is different from this one at techterms.com.
In this post on the internals list the author notices that the Python language is gaining in popularity because it exhibits the characteristics that PHP used to have in the "good old days", that of being easy to learn, highly productive, and without enforcing any notion of static typing, strictness or "correct" code. How do you think its growing popularity would be affected if developers found that code that worked in one version failed to work in another? How many of the other languages in the top 10 of the TIOBE index have a policy of deprecating functions which cause widespread disruption for large portions of their userbase?
The person who asked the question Does anyone still use raw PHP? Is missing a serious point. Unless you are using a development methodology which allows you to assemble pre-built components using a GUI interface then, regardless of which framework you use, it can only provide the basics which means that you still have to write code to fill in the details. In my own framework each user transaction involves the use of the Template Method Pattern which means that the boilerplate code is provided in pre-built methods while specific business logic still has to be written in raw PHP code in subclasses. I have been maintaining and enhancing this boilerplate code since 2003, and I have only ever introduced a breaking change when it was absolutely necessary and never on a whim.
The person who wrote I'm also confused what "fundamental language behaviors"
means needs to learn how to look up a term in the dictionary. Anything which has been an accepted part of the language since its original inception can be regarded as fundamental, and changes to that fundamental behaviour should not be made unless that behaviour causes a genuine problem. The same person also stated that the addition of typehints was also a "fundamental change in behaviour" but he is missing another significant point - typehints were added as an option, not a requirement, and in no way invalidated any existing code.
Like you I do not think that it is cool to break existing PHP code by replacing existing features with fancy new ones just to silence the criticisms of a loud-mouthed minority who would never use PHP even if it was an exact duplicate of their current favourite language. PHP is much like marmite - you either love it or you hate it, and those who hate it will still hate it even if the flavour was changed to resemble strawberry jam. By then the damage would be done - all the original marmite fans would hate it because it no longer tasted of marmite, and its haters would still hate it because it carried the marmite label. Changing a product to entice those who do not currently use it at the expense of those who currently do is a lose-lose situation. Adding new features to the language is OK provided that they are optional, but removing existing features that are widely used and which do no harm is a recipe for disaster.
One thing I would like to see changed is the voting rights for changes to the language. At present this is limited to those who "contribute" to the language by submitting changes in C code. What about those who have contributed to the success of PHP by using it to write applications? After all, the success of a product is measured by how many people are willing to consume it and not the opinion of those who produce it. I think that the list of voters should be extended to include those who actually use the language to write software which is use by others and not just for personal use.
To prevent these ignorant and arrogant Johnny-Come-Latelys from destroying our beautiful language I suggest that the following changes be made to the RFC voting process:
Here are some similar articles on the same topic: