COBOL vs C++, Declared Dead - Still Alive
In the conversation about a successor for C++, COBOL is often mentioned. I do not think this is a good comparison.
COBOL vs C++
Many people claim to be C++ developers because they have seen some C or can write a hello world program in C++ using Visual Studio.
Not so many people claim to be COBOL developers. Because who writes a hello world program in COBOL?
So you still have, and will have for some time, very many people who are willing to apply for a C++ job. But there are only very few people who are willing to apply for a COBOL job.
That’s it. That’s the difference.
Want more details?
Why C++'s popularity is decreasing
There are real reasons why C++'s popularity is decreasing.
C++ is hard
C++ is hard and brings a lot of difficulties with it.
-
C++ is not C/C++
-
C++ is not C with OOP
-
C++ evolves and changes over time
I see via my participation in SIS/TK611/AG09 that there is some work on the COBOL standard going on, but it is not as much as for C++.
The C++ learning curve is steep and constant. It kind of never stops. And it’s difficult to get the history right (unsafe C code).
C++ is difficult
Additionally, C++ has a very difficult and diverse infrastructure.
-
Setting up the build process correctly
-
Getting dependency management right
-
Using static analysis from the compiler
-
Using static analysis from additional tools correctly
-
Running tests
-
Running tests with sanitizers
-
Running tests with fuzzers
-
Running tests with coverage
Compared to other languages, starting a C++ project is hard. Learning C++ is hard.
That is the real reason people do not like C++ anymore. Learning other languages, that come with tools and infrastructure in mind, is far more pleasant.
Why COBOL’s popularity is decreasing
I don’t know. I have never seen a COBOL project. 😉
But I know one person who improves their pension by still doing COBOL consulting.
Why C++ will be around
There is a reason why C++ is still around and will be around for some time. There are a lot of good projects written in C++. But there is more.
Bad examples (that are not bad)
Some history from reality:
In 2019, a 'Lead' developer in a C++ project said they do not want to use C++11 because they do not want to use two different languages in the same project.
Another example: I saw a project where, in some source files, the line count for suppression of static analysis warnings was higher than the line count of the actual code.
And since all good examples come in threes, here’s one more: A project from a team too young to know what pre-C++11 is. So a modern C++ project. Every non-primitive type was a shared pointer.
Yes, the language and the infrastructure can be quite challenging.
Please don’t get me wrong
To be fair, in all three cases, the people who wrote the code used the code as a tool. Their real profession was not being a C++ developer, but electrical engineer, data analyst, or some other background. They came from different domains.
But — and this is the point — they were able to deliver C++ projects for important projects.
The strength of C++
Isn’t that also a strength of C++?
That all those different people, with their different backgrounds, can write code in C++ and deliver a project that fulfills the requirements? Very often on very restricted systems with tight timing constraints and/or safety requirements.
Why COBOL will be around
I don’t know 😁.
I guess because banks and other mainframe customers will pay for, and even educate COBOL programers as long as they need some.
Summary
I do not think that COBOL or C++ will go away during my lifetime. But in case one has to,
C++ will outlive COBOL because there are people who are willing to apply for C++ jobs.
And people from various domains and backgrounds drop into C++ projects,
and they can deliver C++ projects that fulfill the requirements.
While for COBOL, there are only very few people who are willing to apply for a COBOL job, and most people cannot even make a hello world program in COBOL.
Therefore, I do not think that the comparison of COBOL and C++ is a good one by any means.