Don’t say one year of experience required if you won’t train.

I have been dealing with the issue of many people wanting one year of experience with tool A, but they won’t train you on the differences between tool A and tool B, which I do have experience on. But I need someone with experience? A person with one year of experience in a tool isn’t an expert on the tool. They are a moderately experienced beginner. Also, since Tool A and Tool B do the same job, the differences in how those tools work is maybe a week or two of adjustment, not a whole year of adjustment.

Supporting Older Programming Languages

In general, No, No, No!

I have been mulling this question over because of recent discussions I am following about Java, WordPress hosting, and Python 2. I will start with Java. Java has become the modern COBOL in a lot of ways. An extremely verbose language designed around one programming paradigm. Excluding the inherent problems of OOP, and Java’s verbosity, Java has one other major issue version rot. Java 8 has been end of lifed for a bit now and a lot of people are now learning that all of the ABI compatibility prior to version 8 comes with a load of technical debt. Most of the language syntax improvements that help with Java’s verbosity required ABI incompatible changes in the runtime and incompatible changes to the language syntax between Java 8 and 11. This means you can’t run Java 8 code on the Java 11 libraries and you can’t recompile that code with the Java 11 compiler either. To make matters worse Oracle now plans to allow such breaking changes about every 2 years now.

Both the Python 2 to Python 3 migration problems and the PHP5 to PHP7 migration mirror the issues with Java 8 to Java 11. Though, they have generally been better handled, especially the Python change. The Python authors released code that makes most of the syntactical adjustments automatically requiring a human for the areas that can’t be cleaned up by a computer. Yes, the ABI of the language changed but unlike Java 8 to Java 11 there is a migration tool that allows most python 2 source code to be migrated without a complete rewrite.

I am not as familiar with the details of the PHP 5 to 7 transition as I am with the Java 8 to 11, and Python 2 to 3 transitions. What I do know is that it has been in the works for a while. From the perspective of a programmer using the language PHP 7 isn’t a massive change. From the perspective of extension creators and hosting providers, it was a big deal initially. We are now 6, almost 7, years past this change and a lot of hosts still run PHP5.

I will have more to say about this topic in the future but for now have a good day.


NPM Encourages Abandonware

I am using Gulp.js or just Gulp for automating the compilation of CSS stylesheets for the upcoming custom WordPress theme for this blog. In the process of getting that automation setup, I have concluded that NPM’s extremely lax requirements for adding a package to their servers have resulted in an explosion of abandonware.

One of Gulp’s useful advantages over a more traditional solution like make is its choice to pass virtual files around between stages of the processing chain. Parts of the Gulp chain can modify the contents of a file and pass on those modifications without writing them to disk and creating dozens or more temporary files that require exclusion from git and other tools. The most constructive use of this ability I have found so far is a tool that can replace strings in files based on variables I setup.

NPM manages Gulp’s dependencies and plugins. Since creating a new public NPM package is pretty easy, sharing a plugin you wrote doesn’t take any time. That all sounds great until you end up trying to use a plugin and find that no one has updated it for one or two major versions of Gulp. Worse yet is the situation where some dependency is several versions behind, and either is a security vulnerability itself or requires another dependency that is.

I don’t have time to maintain a public NPM package. I may fix one or two outdated plugins I am probably not going to share those fixes on NPM.

Programming Languages and Nonoptimum Tool Use

Some backstory

In my post about OpenWRT on x86 hardware, I mentioned that I considered balenaEtcher’s size to be a negative trait. I also complained in Yarn versus NPM about the dependency management for Node.js projects.

Both complaints stem from a similar problem, Using a tool without respect for its constraints.


All tools have constraints. For physical tools like a hammer or saw, they have to do with how the tools materials, size, and shape affect whether it scratches a surface on impact or how smooth the cut is. Digital tools like software also have constraints. C, for example, treats nearly all data structures as merely a location in memory. This provides excellent flexibility at the ease of creating memory leaks and buffer overruns.

The creators of a programming language have both a problem domain and several other constraints to juggle when creating the language. The original problem domain especially restricts the general utility of the language.

What does that have to do with the examples in the backstory?

All of those programs use the JavaScript programming language. Netscape originally designed JavaScript to make small dynamic changes to a browser’s DOM. Combined with a choice for fast iteration, JavaScript ended up without a robust typing system and little attention to modularity.

You can see the attachment to a browser’s DOM in Electron. The programming environment that balenaEtcher uses. Two hundred and four megabytes, installed, for a program whose task is to order a dozen or so command-line tools around.

The failure to update transitive dependencies that I ran into using Yarn is a side effect of how Yarn deals with JavaScript’s lack of module separation. The original program I wanted to use didn’t help matters by choosing a broad semantic range for their dependencies.


Like physical tools, software, including programming languages, has constraints. Strive to be a polyglot so you can use the appropriate tool for the job.

Yarn versus NPM

Over the last few days, I have had to use both Yarn and NPM to attempt to install two different programs for a couple of home networking experiments. The dependency packaging of Node projects leaves something to be desired. Problems with dependency fulfillment become especially apparent when the package manager pulls in dependencies that are several years out of date for some reason.

I eventually figured out which dependency was causing the problems and that a non-feature breaking update would solve the problem. Yay, I can get the problem solved quickly and get back to testing a new networking feature for my home lab. A yarn update node-gyp upgrade should have solved the problem.

Over 30 minutes of running around in circles trying to get yarn to update a transitive dependency. A short sequence of

  • Installing npm-check-updates
  • running npm-check-updates -u
  • and npm update

Meant I had node-gyp and several other outdated dependencies updated.

Yarn might be better than NPM for running a built Node package, but it isn’t the easiest to use when a dependency update is required.