Now that I’m knee-deep in doing programming work daily, I’ve come across two different ideal mindsets, which I find parallel Nietzsche’s opposition of active and reactive forces. I’m limiting this description to third party developers because it is most obvious in these cases.
The first mindset comes close to Nietzsche’s active forces whereby the replacement and deprecation of older functionality is seen as a good thing. Some open source ecosystems are rife with active programming (WordPress comes to mind). Every time WP makes a new major release, third party developers are quick to adopt the new methods as well as drive the WP core development to improve its code base. In WordPress’s long life, I have rarely seen major developers complain of change (at least for very long). In general, third party WP developers generally are aware of what is changing in the next major release, so their programming is performed with an eye to future growth.
The second mindset, which echoes Nietzsche’s reactive forces, wants to conserve older functionality regardless of its idosyncratic ways. The deprecation and replacement of these older methods are always contested — so much that a significant number of third party developers refuse to support new major releases until after they have been released. In my experience, the Joomla community is full of reactive programmers. Third party developers regularly cry foul with nearly everything Joomla core developers do (e.g. the six-month release cycle, removal of legacy code, etc).
I have had experience with some third party developers who were in the process of rewriting their code to fit better with Joomla 1.5, a release which had already been around for over a year. During this period, Joomla core developers switched to the six-monthly release cycle (and, in fact, had released two versions before this third party group released their rewrite). When I was involved with the group, I had suggested to take a more active mindset in the rewrite and embrace the newer features of Joomla. Their lead developers, on the other hand, chose to build off of Joomla 1.5 and fix problems with newer Joomla releases as they cropped up. Now, Joomla has two major releases — 2.5 LTS and 3.0 STS — and their rewrite project works on 2.5 only because they have copied functionality deprecated in 2.5 and removed in 3.0 by the Joomla core developers (e.g. JParameter). As a result, they will have to look at rewriting large portions of their codebase in the next year as 2.5 is replaced by the next LTS release.
The reactive programming mindset is full of ressentiment, especially towards the core developers who do not develop their code with the offended third party developers’ code in mind. It tries to reverse the relationship between core and third party. However, it also makes third party code less efficient because they often duplicate newer core functionality. In the Joomla example, the Joomla core developers created a small function, jimport(), that would check to see if a file was already included and include it if necessary; this worked similar to the internal PHP’s __autoload() functionality which was introduced in Joomla 3.0. However, the third party group decided to ignore jimport() most of the time and, instead, use an if(class_exists)) {require} line. Every time. Their code is littered with this under the presumption that it is faster than jimport(). I once questioned this since class_exists() is not the fastest method when doing numerous times on every load (if ($array[$key]) is faster in the long run).
In the end, then, active programming in third party developers embraces core progresses and is more able to keep up with the core release cycle, making it easier for new users to understand. Reactive programming, on the other hand, holds back existing users from keeping up with core releases (the eternal question of ‘does this third party code support the new core code?’). This same mindset was seen when PHP deprecated and ended support for its 4.x series — hosting providers were caught with their pants down as they had to scramble to upgrade their servers to PHP 5.x or, worse, force users to stay on the 4.x series while users’ applications dropped support for the deprecated PHP 4.x. This only produces more ressentiment and makes it more difficult for developers — both core and third party — to focus on writing and improving their code. Instead, developers are caught dealing with non-issues and/or playing catch-up in a game of power which is weighted against them. Just as PHP application developers will not stop PHP from dropping 4.x or releasing 5.5, so too will third party developers not stop core developers from dropping functionality they have deprecated/replaced or producing new functionality that suits their development goals.
Reactive programming is the one of greatest examples of consumer mentality in which third party developers perceive themselves as the consumer of the core application and must always be treated as right by core developers. Rarely do they realise the difficulties which they are causing for no real reason other than to attempt a hostile takeover of the power structure of the core development team without wanting to participate in that structure. Instead, they see themselves as manager-consumer in control of the developer-worker in a grand delusion of power.
