GPT Repost this old blog post on Java




I had GPT rewrite this post.

https://www.myberlinaustin-atl.com/2008/06/is-java-new-cobol-yes-what-does-that_14.html

In 2008 there is a phrase floating around the software community: “Java is the new COBOL.” Usually it is followed by complaints about EJBs, XML configuration, enterprise frameworks, or somebody announcing that Ruby on Rails is going to replace everything. I think that misses the more interesting question. The important question isn't whether Java sucks. The question is what happened to COBOL, and whether Java developers should learn something from it.

COBOL was created in 1959 and became enormously important for business computing. Banks, insurance companies, governments, and other large organizations built critical systems with it. Many of those systems still work. That is worth emphasizing because old technology is not necessarily bad technology. If a banking system has processed transactions correctly for decades, replacing it simply because the programming language isn't fashionable would be ridiculous. Reliability matters. Stability matters. Existing knowledge and infrastructure matter. There are plenty of situations where leaving a working COBOL system alone is probably the best engineering decision.

But there is another side to that success. A technology can become so entrenched in a particular environment that maintaining the existing system becomes more important than exploring better ways to build the next system. Eventually you have software that nobody particularly wants to change, written using practices established many years earlier, surrounded by infrastructure that is difficult and expensive to replace. The technology still works, but the world around it has changed. That, to me, is the interesting part of the comparison between Java and COBOL.

I work with Java, and I don't hate Java. In fact, Java has a lot going for it. The JVM is a sophisticated runtime, the ecosystem contains an enormous number of useful libraries, and Java is used successfully in complicated production systems. But Java enterprise development also has a tendency toward complexity. A developer trying to build a relatively simple web application can end up combining an application server, Spring, Hibernate, Struts, JSF, Log4j, XML deployment descriptors, property files, build tools, and several other libraries before much application functionality has actually been written. At some point an engineer has to ask a very basic question: Why am I doing all of this?

I ran into this myself when I needed to convert HTML into PDF documents. Most of my work wasn't really programming. I researched libraries, found one that supported the HTML and CSS features I needed, added it to the application, and connected the pieces. Full-text search is another example. If I need search, I can use Lucene. I don't need to write an indexing and retrieval system myself. Modern software development increasingly involves finding existing components and integrating them into a larger system. That means being a good Java developer isn't simply about knowing Java. It is about understanding the problem well enough to decide what technology should solve each part of it.

That is where programming-language loyalty becomes dangerous. Java developers already use multiple languages and formats whether they admit it or not: JavaScript, SQL, HTML, XML, shell scripts and sometimes C or C++. Why should introducing Python, Ruby, Erlang, Lisp, Scala, Haskell or another general-purpose language suddenly become unacceptable? Erlang might make sense for a highly concurrent messaging component. Python might make sense for a small utility. Java might make sense for a large enterprise service. The architecture should follow the requirements rather than forcing every requirement through the technology the development team happens to know best.

Of course, this doesn't mean that every project should become a collection of ten programming languages. Introducing another language creates real costs. Someone has to understand it, deploy it, debug it and maintain it five years later. The available developers matter. The existing infrastructure matters. Security, database support, performance, tooling and operational support matter. A technically elegant language that nobody on the team can maintain may be a worse engineering choice than a boring technology everyone understands. But those are engineering arguments. “We have always used Java” is not an engineering argument.

This is where I think the COBOL comparison becomes useful. The danger isn't that Java syntax will somehow turn into COBOL syntax. The danger is cultural. A successful technology accumulates developers, vendors, frameworks, certifications, consultants and enormous amounts of production software. Eventually the ecosystem becomes capable of solving almost anything. Ironically, that can make developers less willing to ask whether it should solve everything. COBOL found an enormously successful niche and remained there for decades. Java could eventually fall into a similar role: extremely important, heavily used, highly reliable, and increasingly associated with maintaining enormous existing systems rather than exploring new approaches.

I don't think the solution is to abandon Java. That would be the same kind of technology religion in the opposite direction. Replacing Java simply because another language is newer accomplishes nothing. The better approach is to remain technically curious. Learn how other languages solve problems. Understand functional programming. Look at message-passing systems. Experiment with Lisp. Try Python. Look at Erlang. Learn what the JVM itself actually does. Even if none of those technologies ends up in production, understanding them gives you another way to think about the systems you are building.

Ultimately, software development isn't about defending Java, COBOL, Ruby, Lisp, or whatever language happens to be popular this year. It isn't even primarily about developers. We are building systems for users. The user doesn't care whether the application uses Java, Erlang or COBOL. The user cares that the system works, that it is reliable, that it performs well, and that it can evolve when their requirements change.

So when somebody asks me whether Java is the new COBOL, my answer isn't simply yes or no. I think the better question is directed at the developer: Twenty years from now, will you still be using Java because it remains the best technology for the problem you are solving, or because Java is the only technology you ever bothered to learn?

That distinction matters.


Comments

Post a Comment

Popular posts from this blog

JVM Notebook: Basic Clojure, Java and JVM Language performance

Image
"Measure, don't guess. The primary goal of all performance tuning exercises should be maximize the end user experience given the resource constraints." [1] "It isn't so much a "farewell to the J" as an expansion of the platform opportunities Java provides. Sun's investment to power ongoing development of JRuby and Jython broadens the range and reach of Java, as a whole." -- Rick Ross Overview and JVM Languages    One of the exciting trends to recently emerge from the Java community is the concept of the JVM language. These technologies are all that you would expect them to be. They are implementations of languages that run on the Java Virtual Machine. Some are newly created and some are based on existing, more mature languages. JRuby, Jython are two JVM languages based on CRuby and CPython. Groovy, Scala, Clojure are three completely new JVM languages that were created to add new language features that weren't supported by the core Ja...
Read more

On Unit Testing, Java TDD for developers to write

It has been a while, let's kick off 2017 with a blog entry. I have read and I am reading about four or five posts a day about unit testing. It really has been a long time obsession for me. I have moved past the technical and practical considerations on unit testing frameworks and done with the debates with "should you use Junit or Mockito or Karma?" I am more interested in the psychology of unit testing, who does it, likes it, hates it? It really is one of those easy to learn, hard to master concepts. For example, many many may play chess when they are young and can end up being horribly chess players most of their life, I am part of that majority. Unfortunately, I have never played chess and sat down for hours and tried to master it. I never see the common patterns or have a developed end game. I mostly just play with a knowledge of the basic rules. Following good unit testing practices within your software development shop is a lot like playing chess. It is easy to le...
Read more

Application server performance testing, includes Django, ErlyWeb, Rails and others

Image
The following represents a set of toy benchmark results for various web application servers including ErlyWeb, Hunchentoot, Django and other application servers. The goal was to test out of the box performance through a simple VIEW page. For example, I was trying to avoid static files but going through the controller and the view. In the Rails example, there is a simple controller that then activates the view template. The same approach is used with the ErlyWeb example. Ideally, we are trying to avoid the server loading the static files but in our case the server may be loading cached content. Overall, Erlang's ErlyWeb/Yaws had great performance and out of the box Django did very well. Tomcat and my various low-level simple JSP/Servlet apps also had stable performance. Software and Hardware Configuration used in the Benchmark Two machines were used in the benchmark, a Win32 dual core machine and a single CPU Linux machine. Win32 Box: Microsoft Windows XP, Vers 2002, Service ...
Read more