Any computer science graduate from a university, technical school or community college is trained in it. Every company of any stature uses the language and has a cadre of programmers capable in it. It is the lingua franca that drives businesses.
This was COBOL in 1985. Today, it’s Java. While there are differences, these two languages share enough similarity in their trajectories, from nascence to their pinnacles, that someone dubbed Java “the new COBOL,” providing a new vehicle for today’s small but growing segment of indignant Java programmers to convey their discontent with Java’s biggest issues.
It’s easy to empathize with those who consider this subversive comparison an insult. Who wants to see the public image of their primary programming language debased by the baggage of a “legacy” predecessor with an entirely different code makeup?
Java has enjoyed sustained popularity and progress as what many would consider the standard programming language of our day. Meanwhile, mainstream IT pundits have demeaned and denigrated COBOL and its primary platform, the mainframe, to the point of ostracization.
But at the core of this comparison is a premonition the Java community would be wise to acknowledge and proactively prepare for: Java’s laudable status as “the standard” could easily fall to an undesirable rank of “irrelevant” as newer, supposedly better languages arrive—just as it happened with COBOL.
However, a change in status does not have to define Java’s true value, just as facing constant adversity has not defined or decreased the value of COBOL over five decades, despite what many assume. It’s our opinion that as Java plans for its future, it could and should learn something about the importance of perseverance, adaptability and modernization as a language, and it can learn that from none other than the common business-oriented language that started it all.
COBOL, the Perpetual Underdog
Adversity has haunted COBOL from the beginning. Even during its initial development and evolution away from a language designed specifically for the U.S. Department of Defense, COBOL had to vie for its place as the de facto standard business programming language against more established code like FACT, COMTRAN and FORTRAN.
Meanwhile, COBOL’s principal back, IBM, “was having internal qualms about what to do about COBOL,” wrote the late Jean Sammet—arguably the true “mother of COBOL,” as her contemporary Grace Hopper is often deemed—in an article for the Association for Computing Machinery.
Some involved in the COBOL project advocated for abandoning design efforts and starting anew. Others criticized COBOL for its “semantic verbosity, its syntactical redundancy, and its overall lack of linguistic elegance,” Kurt Beyer writes in his 2009 book, Grace Hopper and the Invention of the Information Age. The most insolent critics suggested COBOL would fail simply because women played a large role in its inception.
They were all wrong.
Eventually pushing past its precarious, underdog position, COBOL blossomed into the standard business programming language. Within its first decade, it was being used globally more than any other programming language, and it has lived long past its anticipated expiration date, being widely taught to new programmers throughout the ‘70s and ‘80s as a leading-edge technology, being core to ‘90s computing as the world prepared for Y2K, and remaining essential today as the underpinning of the world’s largest, most complex and most important applications.
But despite its popularity and necessity in the business world, COBOL eventually went off the radar. It stopped being taught in schools as other languages like Java arrived. It stopped receiving the care and attention it needed to stay current, and as a result it became esoteric and niche.
However, while the reality is any programming language can accomplish any task, there are languages that are best equipped for specific tasks. COBOL is ideal for processing large amounts of data as quickly as possible.
More organizations—from Fortune 500 companies to government agencies—are realizing how vital COBOL is to what they do, and how expensive, time-consuming, risky and ultimately futile it is to attempt to rip, rewrite and replace those applications. But the time and effort it took to get COBOL back on the radar, which is an ongoing effort, is something the Java community should be keen to avoid themselves.
Java, the Unsuspecting Favorite
What should be troubling to the Java world is their language could also go off the radar, not from a lack of necessity or evolving capabilities—open-source JDK is a great example of how innovation can occur—but from simply losing its brilliance in the shadows of newer, more modern languages arriving at a faster pace and being used for newer technology.
Java did not have as challenging a beginning as COBOL, nor as challenging an existence. This could account for why many Java advocates refuse to believe the language could ever face the same adversity COBOL has, and maybe why so many resent the Java-COBOL comparison.
Initially designed for interactive television, Java eventually became the standard front-end business programming language it is today. And like COBOL, it garnered popularity in a short amount of time—in large part due to its platform independence that allows it run on various systems—and has been widely taught.
But regardless of its current footprint in enterprise development, analysts are claiming Java is through, and IT influencers have questioned for a long time whether it should continue to be the standard language taught in computer science curriculums—just like COBOL.
This isn’t to say we think Java is seriously becoming irrelevant, as some suggest. It’s alive and well, and we know from COBOL’s history that claims of the language’s imminent demise are bogus. Java has its stake in the business world. It’s still integral to things like banking, retail and big data, and it’s already surrounded by modern processes and tools.
However, it is over 20 years old, and, gradually, it’s beginning to take criticism for being sub-modern in comparison to languages like Scala, Kotlin and Ceylon. The point is, like COBOL, Java is not invulnerable—it could be surpassed by something else. Looking to COBOL’s history as a premonition of what’s possible would be wise, but watching COBOL’s modern-day renaissance would be too.
Looking to the COBOL Renaissance
Although there is still a dearth of academic support for COBOL in universities, there are new programs emerging outside that system focused on teaching COBOL skills, and companies are taking initiative and passing down knowledge from experts who are nearing retirement.
A huge help in restoring COBOL’s image has been IBM’s willingness to once again take ownership of the language and modernize it. In 2018, there is true Continuous Delivery of COBOL optimizations. There are regular version upgrades occurring at an unprecedented pace, such as the move from COBOL Version 5.2 to Version 6.2 in just around two years, and mainframe organizations are being strongly encouraged to update.
What’s more remarkable, you can now work with COBOL in the same way you work with Java. Programmers new to COBOL need only learn its syntax, not its underlying idiosyncrasies. Agile and DevOps best practices in conjunction with new tools designed for automation, graphical visibility and cross-platform integrations are easing the learning curve—and improving the productivity of experts.
And to think this is all occurring after nearly two decades of COBOL being left for dead by the broader IT community.
What Java Can Do
If Java programmers want to prevent their language from experiencing a dark age, as COBOL did, there needs to be a preemptive renaissance before things go south. The beginnings of that could be happening, which is a good sign.
For example, there has been past criticism of Oracle, the “steward of Java technology with a relentless commitment to fostering a community of participation and transparency,” for not taking more ownership of the language. In response, the company has moved Java to six-month release cycles and they are actively pushing users to newer Java releases. However, other steps may still need to be taken, like encouraging mentorship and learning outside the academic system as Java is potentially replaced in academic systems.
Despite shortcomings, languages like COBOL and Java will be with us for a long time, especially considering the millions of lines of code written in them, the thousands of programmers who write in them, the established tools and compilers for them and the extensive ecosystems supporting them.
However, like COBOL, Java will need to adapt to maintain its place and value, because there will come a day when next-generation programmers won’t understand it, much like today’s next-generation programmers don’t readily understand COBOL. Java programmers should look to COBOL as an example of how they can plan for the language to remain modern enough so those who have never seen it, someday in the distant future, can work with it.
If COBOL could do it, so can Java.
This post is co-written by Mike Siemasz, Compuware’s content marketer, and Jim Liebert, product manager at Compuware.