#programming-languages

This experience of finding an abandoned, but still required platform got me thinking about other legacy systems and how and why they can stay relevant. I guess this shouldn’t surprise me too much, as I worked on OpenVMS as my primary development platform for almost 2 years. That OS doesn’t even hold a candle to having a micro-controller platform move to iPhone development and drop their compiler’s interrupt extension. The relevance argument is that there are plenty of technologies from that same age that don’t have any connections to development today. Any technology that’s managed to stick around that long must have been pretty amazing when it first came out!

I understand some of the business cases that keep legacy products supported and how much time it can take to migrate once all of the systems assume a certain platform. But my focus on the new and shiny has always blinded me towards the many, many legacy technologies that are not just a common but often thriving platform. For every few developers working on building the next wave of technologies, there are many more with the burden of maintaining the technologies of past generations. All of that momentum from the last wave takes a very long time to die out, specifically if it has a commercial backing. Supporting infrastructure and platform technologies generally don’t go bust as fast as they boom, leaving a long tail of technologies on their way out that often have a much higher ‘work share’ than the technologies that are still pushing for their first wave of adoption.

Delphi

If I had to pick a poster child for this, Object Pascal would cover all of the bases. It’s not a new ecosystem, but it still manages to hold onto some serious mind-share. My favorite is it’s hype of RAD (Rapid Application Development). Today, this isn’t a common term for describing upcoming or recent technologies, but at one point in Delphi’s life-cycle it must have been an important acronym to showcase. It originally meant that the language ecosystem has tools for building GUI applications. What a joke! Now anyone can write some bindings to a widget toolkit for iterative, GUI-driven development. The term has completely lost it’s relevance as other ecosystems (mostly web) have advanced much further in that space, and now the term only serves to identify ‘enterprise’ or aging technologies.

As an aside, just the abbreviation led me down another hole of finding all of the silly three letter acronyms that were once so popular for every hot technology. Although I honestly can’t say that the absurdly named technologies today (there’s are databases named Rocks and Cockroach) have done any better at communicating their intent or application domain.

The ‘outdated’ nature of the technology’s marketing has no impact on it’s original or ongoing technical merits. Delphi hasn’t completely fallen out of favor or only survives for a very small niche. It’s re-branded itself as a cross-platform mobile development ecosystem and remains in the top 50 most popular languages by most rankings. Reading some of of the language recent features and tool chains, I couldn’t find any compelling arguments to use it over any other, newer platform for the exact tasks of GUI application development. It looks like Delphi has stuck around not on it’s innovative feature releases and cutting edge tools, but on the consistency of it’s developer base to solve common and ongoing problems with the knowledge they have from learning Pascal 20 years ago. No one should start their first new project or business in Delphi today, but there are plenty of developers who will have to learn it so that they can maintain and enhance existing projects and then probably on their next project because they became so familiar with its strengths and weaknesses. It’s still a powerful language like many others that can still ‘get shit done’. And that’s really the minimum that a language can offer to stick around.

Cold Tools

There are plenty of technologies like Pascal that I wouldn’t consider serious contenders for the best tools to solve modern problems. Most of these legacy tool-chains had a large user base from many decades ago when they were serious contenders or cutting edge. The developers or executives then chose to never move to a newer or better platform. It’s very disheartening to hear that many programmers are in this time warp where old technologies are still causing old problems in modern systems. This is the classic ‘legacy’ problem most developers have encountered. They know that their current tools are old and broken, but they don’t have other options.

Another aside, I read the MUMPS post on the Daily WTF after I started writing this, found on accident from a podcast arguing about the ‘death/stagnation’ of Ruby. The Wikipedia talk page is hilarious. It’s clear that some readers went overboard to smear the language on an older version of the page, but then MUMPS developers attempt to post some defenses of the language! It’s one thing to understand and accept that you’re stuck using an inferior and antiquated technology and make the most of it, but it’s another to attempt to trumpet the language as a modern or elegant solution in the face of vastly more well established alternatives.

Being held back by technology can have a massive detrimental impact on developers who don’t take the time to look up at what they could be missing (The blub problem). I recall a recent C++ presentation about what was supposed to be a hardcore debugging story and I was expecting to hear something like: “the chip-set had a bug that only appeared while using the highest memory frequency and the CD-rom tray together” or “the JIT compiler output bad optimization code for certain loops”. But instead I heard that an application developer found and reported a strange rendering bug that affected some draw logic in a 1st party widget toolkit and then had to wait multiple years for a fix because the toolkit was closed source and poorly supported. :(

Anti-Hype

The anti-hype train just heads the other direction of the hype train, where developers are just expected to complain about these technologies for just being old, or being bad at something that no longer matters. This isn’t on the same track as the legacy train to nowhere, but sometimes they cross over.

Before ranting, know that I still respect the technologies (and their practitioners) for what they were and I know they were generally kept within reasonable bounds. I know that I'm not going to have to debug and enhance a web application written in Fortran, or that any recent flight control system written in Ada had to have been done with someone with 25 years experience.

But I’m always impressed when I hear about an old technology that’s still seriously kicking mostly because developers can’t pick alternatives without massive switching cost or because their part of the technology stack hasn’t moved as fast as the web development world. Mention or use of these languages or terms are generally red flags to me that the technology or user is far behind cutting edge in programming technologies for one reason or another.

Fortran

Oracle

Delphi & Pascal

Visual Basic 6

GWT

Perl

SOAP

MFC

Sourceforge

J#/J++/JScript

FoxPro

ActionScript & Flash

Corba

Solaris

Symbian

Itantium

I’m not listing just old or abandoned technologies, some of these are still industry giants, and others probably won’t ever disappear completely even when there are much better tools for the job. I’m not even listing hate magnets like PHP or ObjC. These are the tools that ‘should’ have been ‘replaced’ for new projects, there shouldn’t be a compelling technical reason to use these over something else, even if it’s the same age with a worse feature set. The fact that it’s better supported should be enough to justify phasing out these ‘known deficient’ technologies in favor of something that is at least more popular with a better chance at a future. Picking a popular technology at least gives some chance of a later migration, as you can stay in a safe herd for other newer technologies to cater to your migration pains. (again ala C to C++)

Relativity

On the other side of this hype, I’ve been talking to quite a few programmers who don’t follow all the stupid HN hype of the new technologies and found that they don’t have the same perspective as me of what is new and what is aging into irrelevance. I’ve heard that Lisp was “old and vile” or “math based and slow”. That Lisp was only used for “teaching the evolution of languages since then”. I’ve heard how Visual Basic .Net is important and that it’s “really powerful” in comparison to other languages. I’ve recently talked about Ruby on Rails multiple times because everyone wants to learn it as their first web development framework because it’s ‘hot’ and “everyone is using it to use it so jobs are going to grow”. My options and observations are completed opposed to all of the above. So every time something like that happens, it helps me understand how someone would suggest learning Pascal or Ada at this day in age on Quora with their real name. The definition of ‘good’ and ‘bad’ just aren’t widely defined for programming languages. It’s one thing to say “this language is too conservative, weak dynamic typing helps me build faster” or “This system can’t have run-time errors or inefficiency”, but it’s another to say that one particularly flawed tool is worthwhile while others can be demonstrability superior.

There are plenty of old technologies that are still hot today as they’ve grown with their niche to spawn and support the cutting edges of technology in different ways. Out of use technologies can still be considered warm if they have descendants or significant influence on modern technologies. The technologies above are either generally recognized as dead ends (in some communities at least) or treated as important stepping stones that have now far outlived their original usefulness.

But even longer would be the list of technologies I’d consider hot or warm that haven’t had half the recorded adoption of any one of the legacy technologies listed above. My perspective is so warped towards the new that I’d see a small framework take much more mind-share than it actually has in comparison to a well established stack. This is the gap between the early adopters and the mass adoption. So many new and improved technologies are proposed that never make it to the gap and still more fail to make the jump into mainstream popularity. But once that jump has been made, it’s near impossible to kill it. It will go on living long after support has ended and other tools are available that are 10x or more productive. Or even worse is that the jump forward was imaginary, and that the ‘newer’ technology is actually a step backwards for productivity!

The long tail of technologies says something about how future technological progress will unfold. We’ll reach a certain point where some of these dinosaur technologies will indeed go extinct while they are still in use behind the scenes. They will continue to drag down their associated domains until they can be replaced, sapping energy that could have been used to actually improve the application. And normally, by the time they get around to being replaced, they won’t be replaced by a new or forward thinking technology for the same reason it took forever to replace it. The application will be moved to an equally well explored dead-end that has an even shorter lease on life than the last platform. Which will cause the problems of the application to repeat even faster!

This sort of technological burden, the whiplash from the explosion of system choice, won’t have as noticeable effect as bridges collapsing from disrepair and outdated materials, but it will slow down future advancement as once trustworthy infrastructure takes more effort to maintain as it’s pushed towards necessary goals that other technology has long surpassed. I’ve heard arguments that call for a Cambrian explosion of languages and tools that will hopefully provide an evolutionary path out of this repetitive mess, but if done incorrectly this sort of effort could lead instead to a very painful mass extinction!

The topic of legacy code is massive. Even trying to condense a single question of “why”, “how”, or “what” becomes a complex multi-page post!