Human bodies can get the horrible disease of cancer. Software programming languages are frequently impacted by software cancer, which also has horrible results.
There are many kinds of cancer, impacting different parts of the body and acting in different ways. They all grow without limit and eventually kill the host. Worse, most cancers can metastasize, i.e., navigate to a different part of the body and start growing there, spreading the destruction and speeding the drive towards death.
Software cancer impacts software languages in similar ways. Once a software programming language has been created and used, enthusiasts decide that the language should have additional features, causing the language to grow and increase in complexity. The language grows and grows, like a cancer. Then some fan of the language, inspired by it in some strange way, thinks a brand-new language must be created, derived from the original but different. Thus the original language evolves into a new language, which then itself tends to have cancerous growth.
Like cancer in humans, programming language cancer leaves a trail of death and destruction in the software landscape. We must find a way to stop this cancer and deny its self-promoting lies that it’s “improving” the language it is destroying.
Programming language origins and growth
All computers have a native machine language that controls how they work. The language is in all cases extremely tedious for humans to use. Solutions for the tedium were invented in the early days of computing, which enabled programmers using the new languages to think more rapidly and naturally about the data they read, manipulated and put somewhere.
Each of the new languages was small and primitive when it was “born.” As the youthful language tried getting somewhere, it struggled to first crawl, then stand with help and finally to walk and run. Growth in the early years was natural and led to good results. Once each new language reached maturity, however, cancer in its various forms began to set in, causing the language to grow in weight and correspondingly to lose strength, agility and overall health.
I have described the giant early advances in language and reaching maturity with the invention of high level languages. After early maturity, a couple small but valuable additions to languages were made to enhance clarity of intention.
The ability to create what amounts to “habits” (frequently used routines) were an important part of the language maturation process. The more valuable such routines were added to libraries so that any new program that needed them could use them with very little effort. There were a couple of valuable languages created that went beyond 3-GL’s, languages that were both popular and highly productive. It’s a peculiarity of programming language evolution that these languages didn’t become the next-generation mainstream.
That should have been pretty much it! You don’t need a new language to solve a new problem! Or an old problem.
Languages exhibit cancerous growth
In the early days of languages, it made sense that they didn’t emerge as full-grown, fully-capable “adults.” But after a few growth spurts, languages reached maturity and were fully capable of taking on any task – as shown for example, by the huge amounts of COBOL performing mission-critical jobs in finance, government and elsewhere, and by the fact that the vast, vast majority of web servers run on linux, written in plain-old C. The official language definitions in each case have undergone cancerous growth, ignored by nearly everyone sensible. For example, newer versions of COBOL incorporate destructive object-oriented features. Of course it’s the fanatics that get themselves onto language standardization committees and collaborate with each other to get useless but distracting jots and tittles added that endlessly complicate the language, making it harder to read, write and maintain.
Languages metastasize
There is plain old ordinary cancer, in which language cultists get passionate about important “improvements” that need to be made to a language. Then there are the megalomaniac language would-be-gurus who decide that some existing language is too flawed to improve and needs full-scale re-creation. Those are the august new-language creators, who make up some excuse to create a “new” language, which invariably takes off from some existing language. This has led to hundreds of “major” languages and literally thousands of others that have been invented and shepherded into existence by their ever-so-proud creators. Most such language "inventors" like to ignore the origins of their language, emphasizing its creativity and newness.
Someone might say they’ve “invented” a language, but the reality is that the invention is always some variation on something that exists. In some cases the variation is made explicit, as it was with the verbose and stultifying variation of C called C++, which hog-tied the clean C language with a variety of productivity-killing object-oriented features. And then went on to grow obese with endless additions.
Purpose-driven programming language cancers
There is no unifying theme among the cancers. But high on the list is to somehow improve programmer productivity and reduce error by inventing a language with features that will supposedly accomplish that and similar goals. Chief among these purposes is the object-oriented languages, which have themselves metastasized into endless competing forms. Did you know that using a good OO language like Java results in fewer bugs? Hey, I've got this bridge to sell, real cheap! Functional languages keep striving to keep up with the OO crew for creating the most confining, crippling languages possible. It's a close race!
The genealogy of programming languages
Everyone who studies programming languages sees that there are relationships between any new language and its predecessors. When you look at the tree of language evolution, it’s tempting to compare it to the tree of biological evolution, with more advanced species evolving from earlier, less advanced ones. Humanoids can indeed do much more than their biological ancestors.
That’s what the “parents” of the new languages would have you believe. Pfahh!
I have described the explosive growth of programming languages and some of the pointless variations. But somehow programmers felt motivated to invent language after language, to no good end. Just as bad, programmers decided that existing languages needed endless new things added to them, often copying things from other languages in a crazed effort to “keep up,” I guess.
Various well-intentioned efforts were made to prove the wonderfulness of the newly invented languages by using them to re-write existing systems. These efforts have largely failed, demonstrating the pointlessness of the new languages. There was a notable success: a major effort to re-write a production credit card system in assembler language to supposedly bad, old COBOL!
How to stop language cancer
Unless we want to continue the on-going cancerous growth and metastasizing of software languages, we need to ... cure the cancer! Just STOP! Easy to say, when a tiny minority of crazed programmers around the globe without enough useful work to keep them from causing trouble keep driving the cancer. There is a solution, though.
The first and most important part of the solution is Science. You know, that thing whose many results, along with effective engineering, created the devices on which we use software languages. Software is very much a pre-scientific discipline. There isn't even a way to examine evidence to decide whether one language is better than another. What is called "Computer Science" isn't scientific or even practical, as a comparison to medical science makes clear.
The second path to a solution is to focus on status in software. Today, software people gain status in peculiar ways; usually the person with the greatest distance between their work and real people who use software has the highest status. A language "inventor" as about as far as you can get from real people using the results of software efforts. As soon as people contributing to software cancer are seen as frivolous time-wasters the better off everyone will be.
What's the alternative to language cancer?
The most important alternative is to cure it, as expressed above. The most productivity-enhancing effort is to focus instead on libraries and frameworks, which are the proven-in-practice way to huge programmer productivity gains. The "hard" stuff you would otherwise have to program is often available, ready to go, in libraries and frameworks. They are amazing.
Finally, focusing on the details of language is staying fixed at the lowest level of program abstraction, like continuing to try to make arithmetic better when you would be worlds better off moving up to algebra.
Conclusion
Software language cancer is real. It's ongoing. the drivers of software language cancer continue to fuel more cancer by honoring those who contribute to it instead of giving them the scorn they so richly deserve. Software would be vastly better off without this horrid disease.
Comments