written by owen on 2019-Sep-12.

For the last 2 weeks I have been lurking on the PHP reddit trying to figure out what the general air is like on that side of the world.  I drop one or two questions trying to get a feel of what the community is like. It stinks of future geeks.  I noticed toxic things about the certain members of the PHP community on reddit and prominent in OOP framework users.  Zeev has noticed the coming storm.  I had noticed this before but only today have I been surrounded by such a toxic stink;

"This RFC deals with taking code which has been emitting notices and warnings since its inception, code which exhibits behavior which is, at best, risky, and translates it into either higher severity warnings, or throws an exception so that the result of that risky behavior will not propagate into the following code."

Breaking changes like this to PHP are destructive because they change the nature of how PHP behaves as an "independent" programming language.  I recently read a article called "PHP arrays aren’t really arrays" in which the author referred to the PHP Array as an "ordered map".  It instantly sent off bells in my head.  The author then when on to conflate Laravel Collections with PHP arrays and tried to demonstrate how they are much better at being an "array".  This renaming in subtle almost like dereferencing a pointer but it points to a line of thinking by "modern programmers"(MP) that attempt to change the meaning of something that is inherently "PHP" in nature into some "other thing" from other languages more notably Java.  Most of these MPs might have never used Java but read about its virtues and want to "have their cake and eat it" without that PHP is its own language with its own history.  The more this practice of "renaming" is perpetuated; the easier it will be to justify other breaking changes that destroy the elements of PHP that are established and unique to "PHP" itself.  It is a slippery slope into self-destruction.

It is hard for someone who lacks experience and perspective to understand something as subtle as calling something an "ordered map".  To most MPs this is like a witch hunt to find all the things that are bad with PHP and somehow make it better by adding an arrow function.  On the other hand people who write code in multiple languages and platforms often refered to as "legacy programmers" see these changes as an attack on the language and the history which PHP has created.  A language without its history is nothing (look up ActionScript3).  PHP as it has become; is successful because of its simplicity and dynamic nature.  Either by hidden agenda or ignorance these MPs seek to ride PHP's popularity using these RFCs as a springboard to change the very nature of PHP under the feet of the entire international PHP community.

It may seem like this toxic community doesn't exist.  But because these MPs exist in a echo-chamber of RFCs and frameworks as opposed to the rest of the PHP community which is mostly comprised of a of legacy programmers, Wordpress users and hordes of newbies with no direction - there is nothing limiting their zeal.  There are several threads on REDDIT which show this toxic behaviour towards the core features of PHP.  Take for instant this thread; "Does anyone still use raw PHP?" here is a quote;

"I would say that I'm a Laravel developer, but if I had to build anything in raw PHP, I wouldn't trust myself to get the job done. I'm curious if people still write raw PHP? I do want to learn the language itself also because sometimes I feel like I'm cheating because Laravel makes things so obnoxiously easy to the point it's a joke. I can build fairly complex projects with the framework but what would be a good starting point for me if I want to learn PHP?"

This developer is asking his questions from a point of assumed authority.  Somewhere down the line in his/her development the impression was embedded that "raw PHP" is bad and using a framework such as Laravel is the one true way to do programming in the PHP language.  Even with the fact that Laravel and every framework running in PHP is written in RAW PHP.  PHP frameworks as whole seem to be fostering a breed of MPs/API junkies/future geeks with no understanding of the core nature of PHP.  Cuddling, shielding and encouraging their parasitic and destructive behavior towards core PHP.

Recently, like last week  Laravel 6 was released and implemented lazy collections which is essentially a wrapper around PHP's own internal Generators.  It seems that by wrapping all the features of core PHP and EOL'ing support for earlier versions in a willy-nilly/hap-hazard fashion allows the framework constantly implement breaking changes while encouraging its users to expect the same pace of change and instability from the core of PHP.  Frameworks position themselves as cutting edge, constantly shifting base requirements therefore encouraging its users to always seek higher ground for fear of drowning without support. This is a toxic practice, whether intentional or unintentional. It reeks of an abusive lover-hate relationship controlled by indentured servitude, carrot on a stick society.
I can't stop writing bad code as long as I'm allowed to!

Get off my lawn?

This is more than just a "get off my lawn" problem.  There MP programmers are often stuck in a single paradigm thinking everything is a nail because all they have are OOP hammers.  Worse yet in thier minds they think they make up 95% of the "Professional PHP Community".  They most often cannot help with any changes to PHP internals because they lack the skill and understanding of functional/procedural programming, C, CPUs, or RAM.  They live sheltered lives on top of commercial frameworks that feed them a few crumbs every version.  Generators have been in php for how long now?  Without an informed opinion and foresight knowledge exists in a narrow frame of view.

Another issue which comes to the fore is the 5.6 vs 7.0 versions of PHP and the use of EOL to push PHP forward.  EOL seems to be a new tool that is being used constantly to justify breaking changes for things on the internet.   Millions of pieces of computer HARDWARE have been EOL in order to have arrow functions, flexgrid and CSS3 animations.   These same MPs are even already talking about the EOL of PHP 7.  The rapid moment to EOL php 5.6 is often ecouraged by the fact that php7 is "faster".  Simply "faster".  Speed has become important in a scripting language for people who use a OOP ORMs on top of frameworks that use caching and auto-loaders as a base requirement.  

"Tradition is a terrible justification for anything. Just because something was that way for "two decades" doesn't make it good.  I'm also confused what "fundamental language behaviors" means. What makes something "fundamental"? PHP is/was a loosely typed scripting language. Then typehints were added. Was that not a "fundamental language behavior"? Do parts of the documentation get a "fundamental" tag meaning it will never be modified ever? This seems very arbitrary. *"

This is a toxic culture.  The literal "in breeding" that is happening in PHP by OOP MPs that now want to eat it so that they can add just one more thing - move PHP and the web forward by breaking its history.  Forward to where?  None of these people know.  They just want to fire-fight themselves into the future by deprecating the past.  From my vantage point I am not sure if it is perpetuated by web tutorials, "best practice" authors or the designers of frameworks.  But someone/somewhere in these communities is indoctrinating the new age modern programmers (MPs) into thinking that there is "one true way" to write software on the web.  Not just on the web but everywhere and that PHP is the vehicle to make this one true way a reality.  The big deal is half the internet runs on PHP and the actual professional developers that use it is in the minority. So breaking changes to anyone on this sub is no big deal, but to the unprofessionals it'll be huge.*  And worse that that "one true way" is deep nesting of hooks, callbacks, classes, interfaces, gates, inheritance, design patterns,  routers, view, controllers, containers, templating and general OOP MVC rabbit holes.  There is nothing wrong with these strategies but the rate of code rot, deprecation, refactoring and rebasing is at an all time high.  Entire code bases are often re-written when frameworks change versions without community input.  Code originally sold as more maintainable is EOL-ed and labeled as in-secure in order to constantly push the community towards ever changing goal posts and upgrade cycles.

Proponents of breaking changes often deflate opposing opinions by ignoring valid concerns and encouraging unethical practices in technology such as planned obsolescence, fragmenting users permanently on on to EOL versions of PHP only to then pester them with fear mongering about instability and not getting security patches;

"Seriously? How do you know if they would never or ever upgrade, you can only and should probably speak for yourself...If they want more customers(translating to revenue), they can upgrade and if they don't it's all up to them... *"

Attackers use strawman arguments comparing one change to another. Conflating notices with warnings. Or arrays with ordered maps. Or changes which are feature creep - used to degrade the ease of use of PHP as a language by forcing niche features. Changes are not new to PHP but the mob mentally of one sector of the PHP to impose superfluous changes on the rest of the community for selfish reasons is destructive to everyone involved.

It is not cool to break the PHP code base.  People write framework projects that they never update because all the tools and the framework is are out of date. People deprecate their own OOP code. Even the so called maintainable framework projects are never updated because it is easier to re-factor the entire codebase than to update it.
I personally still have code running that was written in 2003 because PHP is stable and not a "fly by night" programming language maintained by evil people who seek to profit from breaking my hard work and giving me carrots to chase.

Conclusion

This attack on the integrity of PHP as a unique language (including Wordpress and all the frameworks which were spawned from the evil mal-practice belly of PHP) is about more than a few RFCs.  It is about control, shifting the goal posts and making headless chicken programmers who cannot finish any projects they start because they fear that their project will never be good enough to meet the accepted standards set by "future geeks" and people who write best practice books for a living.  And that their potential/success is somehow linked to the constant churn of new version numbers and framework updates.

What this holds for the future is uncertain.  The skills gap is widening fast in every area of tech and the tutorials are increasingly dumb.  The tools are increasing at a rapid pace. PHP is becoming a too heavy language because of bloated packages. This is how the whole RFC thing appears to me. There is certainly alot of money in making tutorials for todo_lists, starting projects that never finish,  padding resumes with github repos and demo MVCs, writing tool chains for bloated software, writing best practices that solve problems created by anti-patterns and even more money in creating APIs to dog food new programmers.  The increasing dependence of modern programmers on tool chains will certainly increase the churn in the tech industry but it will do a dis-service to the programming community as a whole especially in the case of raw PHP.

The way we improve PHPs image is we show why the things that make it unique are actually good things, while adding NEW features to the language. No matter how much we try to make PHP like Java, c#, python, etc., it isn't going to entice those developers over to PHP when PHP doesn't offer them anything different than what they already have. - Chase Peeler

Foot Notes / References

• Changing fundamental language behaviors (Sept 2019)
  
• Zeev Suraski on the rise of RFC deprecations (Sept 2019)
  
• The Entity Service Antipattern (Dec 2017)
  
• .NET Framework 4.8 Release Notes (Aug 2019).
  
• Cargo cult programming (wikipedia)
  
• Please do not break our language Dec 2014 by Tony Marston
  
• PHPs new hashtable implementation Dec2014 by Nikita Popov
  
• Rasmus Lerdorf: PHP in 2018 – phpCE 2018

permanent link. Find similar posts in Articles.