Jul 1, 2009

There will be no substitute for COBOL

I've bought that book quite some time ago, and only recently managed to fetch it from my bookshelf (did I already mention that I am a book junkie)?..
Being a second edition of the classic book, some kind of a new thin wrap around ten years old candy, it still manages to sound insightful in some places.
Well, that candy is not just old, it's ancient (first edition is 1990, second one is 2005)... well, at least from the perspective of everchanging software development world.
Still, I'm done through the bigger half of that, and I am not regretting doing that so far. However, there was one part which has turned out to be mind provoking in a somewhat unexpected way:
But there's something else happening here, too. With all that heavy use of COBOL in the business world, where money is to be made by cutting costs wherever possible, why haven't at least a few companies switched to something better? No, I don't mean 4GLs. I mean 3GLs that provide the same capabilities as COBOL. Why haven't the innovative, advanced firms started using a better COBOL?
Here's where I want to get to the real point of this essay. I want to take the position that people aren't switching away from COBOL because there really isn't anything better to switch to.
Heresy! Ignorance! Stupidity! I can hear the silent cries from my reading audience now. But wait, there is method in my madness, and I would like to explain.
...What other tools have been invented to address [the business] problem domain?.. That better way is still COBOL. That's the gist of my heresy.
Does that mean that I think COBOL is a good language?
Emphatically, my answer is a resounding "No."
...Why? Why is this ancient and clumsy language not replaced by something that does its job more cleanly? Because, I would assert, the research world which might create a better language is so disdainful of business application software in general, and the COBOL language in particular, that it is blind to the thought that a major research challenge lies in defining a better COBOL.
COBOL, eh?
Now, certainly, COBOL is out from the scene, and that's something Robert Glass acknowledges himself (what a surprise!) in that "special 2nd edition chapter". But that's not the point.
"COBOL" is just a label, and if one blurs it away from the picture (together with probably some other vintage things), the pattern extracted seems to be very familiar.
As it usually happens with my poor mind, when it's being provoked by something, I see a reference to several (possibly non-related) things at once:
  • That Deja Vu feeling one gets often when reading discussions about the present state of the technology. So, does C++ looks like COBOL in this context?..
  • And what about that too well known Tim Sweeney talk?..
  • And what is a "programming language", after all? Is it programmers' or users' thing, or maybe both?
  • Is really software development history developed in a spiral (pretty much like the human history)?
  • What is the point in developing the new "programming languages"? It seems that users do not care about languages, they prefer working software.
  • And what about our's today arrogance? Like in, "C++ is going to stay here for a while, because it's the most efficient language, and computer games do demand performance".
  • Could it be, that business value of the software is higher if users have more control over the way this software is applied to their domain?
I mean, yeah, of course. C++ is not COBOL. And Java is not COBOL. And C# is not COBOL. And F# is not COBOL.
Those are bloody modern and mainstream.
Or are they?..
Or maybe they are just an another coil of the Spiral?
What we are, then? Are we the pivot of that spiral, or just a part of a coil?
All our experience, knowledge, mental models - all of it can happen to become nothing in the long term.
So, what do we do to prevent that?
Learn COBOL, of course.

1 comment :

Unknown said...

Your post makes the common underlying assumption that COBOL is done and dusted - there is one COBOL. This is far from the case. Innovations in COBOL are happening all the time (I work in a team creating innovations in COBOL at Micro Focus).

I totally agree with your point that people are no researching a better approach to COBOL for business software development. The solution therefore would seem to be to develop a better COBOL.

Looked at another way, one could argue that a completely new language would be a better choice than English for international communication. However, what has actually happened is that English has evolved to be better (sometimes called Globish) for this purpose.