I started to write a little COBOL program last year, but quickly abandoned it. I decided to have another go at COBOL recently, and I have successfully completed my project.
I have made the program available as a gist. What it does is take a share portfolio of tickers (a company’s unique symbol) and portfolio values, cross-references them to a table of sectors, and rolls them up to create a table of portfolio value by sector and percentage of portfolio. That way, you can see if your portfolio is too over- or under- weighted in a particular sector.
It was a fun exercise, and took less than a week working less than an hour a day. The program was 227 lines long.
Data declarations amounted to around half the code, and included a table created at compile-time. I could have created a denser version in most languages, I feel.
COBOL was quite verbose, despite it being a so-called declarative language. I felt that I could probably have written a shorter version in C.
The compiler created a nice compact executable, weighing in at 21k on Linux. If I had written it in C I would have undoubtedly had an executable of the same order of magnitude. If I had written it in C++, I am sure the executable would have been much larger, as I would have used vectors and strings. When you start pulling those kinds of dependencies into the build, your executable tends to expand noticeably.
Abstraction seemed to be quite low in my COBOL code, and you have to do some bookkeeping. I felt that the code ought to be at a higher level. I’m pretty sure I could write at a higher level in a language such as C++.
An example where I found some repetitiveness was in file reading, such as in this section:
display "reading epic file"
open input epics-file
move 'N' to eof
perform until eof = 'Y'
read epics-file next record into epics-file-line
at end move 'Y' to eof
not at end perform process-efl
When I wanted to read another file, it’s basically a copy-and-paste job, with changes made to the calling routines. It would be nice to have a routine where I could say “put this file into that table”, and it would just do it. Maybe if I read about more modern standards of COBOL I would be able to see a way.
I had problems with compilation due to my complete unfamiliarity with the language. This should be expected, of course, and is not a bad reflection on COBOL per se. When I finished with the project, I felt I had a pretty good grasp of the syntax that I needed to use, and could write a program that needed to do what I wanted it to. I am sure I would be able to use many more refinements given more experience.
I’m still a bit confused about the distinction between sentences and paragraphs. I’m under the impression I’m not the only one. Periods (“.”) seem to demarcate both sentences and paragraphs. This is a problem because it crucially determines program flow! The trick seems to be to use less periods. Hmmm.
I thought that COBOL should have handled outputs a little more elegantly. COBOL’s internal representation is different from its output. So, for example, in order to calculate percentages for a category, I defined:
02 cat-percent pic 999v99 value is 0.
In order to print it out neatly, I had to define:
02 cat-percent-out pic ZZ9.99.
and then do a
move cat-percent to cat-percent-out
before displaying it in a more human-readable form.
I suspect that COBOL is very memory-efficient. I am assuming that the working storage section basically defines the whole memory layout of the data. I also assume that the procedure division doesn’t require a stack, as there are no functions, just sections, which could be implemented as jumps.
There’s two schools of thought about the verbosity of COBOL. Its purported advantage is that it makes it easy to read. There’s something of “silver bullet” trap there. The logic is that because it’s written in English, non-programmers can understand it.
The chances are, though, that
ADD X TO Y GIVING Z
is actually less readable than
Z = X + Y
And to be honest, if you have problems with the second version, you have no business reading programmes anyway.
The pro-verbose side also miss the real issue of inherent verses accidental complexity (or as I like to phrase it, intrinsic versus extrinsic complexity). Writing in English cannot remove intrinsic complexity: the problem is as complicated as it is.
So they miss this crucial point: understanding the semantics of a programme is relatively easy, whether it is in English or not, but understanding the structure of a programme is difficult.
I’ll grant you that a language is more suited to a particular task is likely to be more comprehensible than one that isn’t. However, you need to take care that you are not conflating different issues.
I am not advocating or denouncing COBOL per se on the matter, I am just noting that it may be a specious argument.
Would I program in COBOL again? Maybe, if it was a businessy-oriented type problem. It was certainly a fun exercise for me, as I have an interest in obscure and retro languages. No doubt COBOLers will shoot me down for the preceding sentence.
I could make my peace with COBOL. My own impression is that there is something higher-level waiting to get out, a kind of COBOL++. Or should that be ADD 1 TO COBOL?
It has made me curious as to whether writing some EDSL (Embedded Domain Specific Language) in C++ based on the principles of COBOL might be fruitful. You would then be able to do neat tricks like read entire files into tables as I had suggested before, specify relational constraints between tables that can be handled automatically, and even create automatic interfaces to SQL databases.
I have been thinking seriously about the EDSL approach. Before I do that, I think I will try to re-implement my app in Forth.
What I think is interesting is to take a design approach of COBOL as a way of doing it in Forth.
Comments, particularly in relation to my COBOL style? Is there a way that it could be more “idiomatic”? I enjoyed my little foray into COBOL, despite the somewhat overall negative tone of this post.