Somewhere there is a graveyard for dead programming languages with tombstones marked "</fortran>."
Every technology has a predictable life cycle, and when one language reaches the end of its modern usability, an alternative needs to step in. However, even retired programming languages still exist in the decades beyond their anticipated expiration as a foundation or teaching tool for other languages.
For example, the Massachusetts Institute of Technology uses a language called Racket, a derivative of Lisp, said Jeffrey Hammond, VP and principal analyst at Forrester, in an interview with CIO Dive.
"You're never going to see a Racket implementation out in the wild, but they use that as their initial introduction because it creates a good basis for a lot of good programming practices over time," said Hammond.
Simply put, the digital world is founded on software, and software is nothing without its underlying code.
But to properly evaluate the health and integrity of modern software, companies need to examine three different qualities of coding languages, according to a Gartner report on the IT Market Clock for Programming Languages, made available to CIO Dive.
- Is the language still providing value? Organizations must determine if an older language has the ability to continue to provide a business value as long as in-house developers are regularly updating and maintaining the organization's application. Examples of third-generation languages that do this include Programming Language One, Report Program Generator, Delphie and ColdFusion.
- Can the language adapt to newer generations? IT departments need to evaluate the ability of an older language to "receive infusions of support for new disciplines, architectures or technologies, and retain their product identity despite being dramatically different from their original form," according to Gartner. Visual Basic and COBOL are both examples of adaptable legacy languages as long as organizations use legacy application development tools to help languages "coexist" with other generations.
- Who is going to know the language? Considering the available workforce for a dated language is crucial before deciding to maintain an old code. During the same time a language becomes increasingly outdated, those well versed in it begin to retire out of the workforce.
The stages of a programming language's life cycle
Gartner identifies four phases of a programming language's life cycle: Advantage, choice, cost and replacement. The first phase, advantage, is dedicated to the traditionally low level of competition in the market, so the language "is procured for what it delivers" rather than its replacement.
The next two phases are defined by their level of commoditization and the cost of the language. By the replacement phase, a language has graduated to a "legacy" status, and from there CIOs are tasked with examining the characteristics formerly mentioned to determine if maintaining the language is worth it to the business.
A company's code is only as strong as its developers
When the time has run out on a language's usability, coders leap to adapt to the industry's next viable option. Some developers may show a resistance to a new language, particularly when younger generations are readily equipped to more or less replace their aging counterparts.
But if an older developer eventually leaves a company without updated code, it degrades the quality of the code for the incoming developers and "it's not a solid way to run your company," said Jim Skidmore, CRO at AppGaurd, in an interview with CIO Dive.
A developer's foundational skills vary depending on their means of education. If a student pursues a formal, academic route, it is common to see a foundation in .NET languages like Visual Basic .NET (VB.NET), according to Hammond. In high schools and some universities, students are taught more dynamic languages, including Java.
Eventually, the languages set as a foundation for future code are relegated to just that, a foundation. However, having languages that are "more of a learning language than a doing language" is common for aspiring developers to learn, according to Hammond.
As for the current status of the coding workforce, "we are certainly seeing young people developers and newer developers [that] tend to be much more comfortable with dynamic languages and even use them as a first resort," said Hammond, despite most companies running static languages like Java, .NET, C# or VB.NET.
This is in part due to the "nature of programming metaphors that languages have 20 or 30 years ago," according to Hammond. Static functional languages like Assembler, ForTran or C were used before object orientation was introduced through Java, .NET and C++, and those newer languages then signified a "conceptual change" for developers until around the mid-early 2000s.
Whenever a new crop of programming "metaphors" arise, a new generation of developers embrace them. Older generations of developers inherently gravitate to static languages, but "it's hard to find a developer under 25 that doesn't know how to do some JavaScript," said Hammond. "They've grown up with it."
There will always be a place for developers educated in either static or dynamic languages. Though the emerging trend is to be a connoisseur in both the front and backend, the "full-stack developer" is simply too much of a "heavy lift," according to Hammond.
Instead, developers should examine where they feel most creative and in tune with their craft so that both the front and backend of technologies can work together seamlessly.
If nothing else prompts the migration to new code, maybe security will
Companies less than enthusiastic to update programs are sure to be labeled "digital laggards," which carries more implications than just outdated code. Security falls by the wayside when programs are left outdated.
To mitigate risk, organizations need to "triage" their existing technologies to better understand where and how optimizations should be directed, according to Hammond.
"If they are critical to the business, they help differentiate the business and they are well-written, then you need to modernize them," said Hammond. "If they are critical to the business [but] they're not well-written, they have security errors or there are lots of defects, then you need to rewrite them using modern languages and modern frameworks."
But if an existing program neither serves the business or is well-written, IT departments are recommended to replace them altogether with packaged software, third party services or just shut them down.
Third party applications tend to be stronger and can introduce a company to an API-based economy, according to Skidmore. For example, those embracing SAP with APIs "build like a receptacle for you to plug into."