Is COBOL, a DSL?

1

I have got the following link from stackoverflow e-mail list:

Finding it a bit contradiction as systems built on DSL should be looking for DSE (experts), at least ideally.

Edit:Append:
I think the large volume of code is making it a complex thing. Can a DSL design take care this and be future proof wrt handling growing volume? What strategies does it potentially employ? Machine Learning? or growing an eco system for abstractions like the one around Java? Is there any reinvention in enterprise context? Please note, I do not have any working knowledge of COBOL or Java or ML or any DSL.

1 Like
2

COBOL was probably originally envisioned in a way that would have made it a DSL, targeting “business-oriented” software. (Nowadays, some people would probably have called it a low-code platform :wink: ) The problem is that “business-oriented” software was defined a bit vaguely, so we’ve ended up with a language that has little chance of providing a heightened level of abstraction, and resorts to low-level constructs for data manipulation, persistence, and flow control. In other words: it’s really a general programming language, not a DSL.

(My €0.02, not being a COBOL-expert, only tried to do some legacy transformation on it.)

4 Likes
3

Thanks Meinte Boersma for sharing your view. So it appears to me, at that time it could have been the best effort by probably anyone. Now that we have more clarity, as a learning I think we need to put more effort on the delineation parts in the design and the strict definition of DSL.

4

The answer depends on what is the level of abstraction you are seeking for. Having wrote some COBOL programs in the past, I would see it similarly to Meinte as a general programming language. However, if you really want to add speed and quality to development, using a domain-specific language(s) is a proven solution. For one public example of been really a proven solution: see e.g. Helvetia Versicherungen on applying domain-specific modeling languages for mainframe COBOL application development.

1 Like
5

I used to do computer consulting, and occasionally would have to fix up some COBOL program. Back in the 60’s, there were 2 main languages in popular use for application programming: FORTRAN and COBOL. COBOL was backed by the Navy, and FORTRAN’s hotbed was scientific computing.

Both camps hated each other, and the business community had to choose one or other as the main language. In recent history the language selected for mainstream use was Java. Anyway COBOL had some good things, such as a clearly defined organization in the code, where you have a declaration section at the top, and an implementation section later. FORTRAN didn’t have that kind of organization, and businesses like that more structured approach.

COBOL is very verbose, and clumsy. But it had 3 things that really appealed to business people: 1) it allowed long variable names, when many FORTRAN compilers only allowed 8 character, COBOL had over 20. 2) it had a number formatting syntax where you could signify how you wanted the number to appear:; $XXX,XXX.XX, where you could specify digits precision, dollar sign prefix, etc. in a very easy way. None of this C nonsense where you go %6.2d and 3) COBOL offered BCD arithmetic, so that 0.1 + 0.2 does equal 0.3. Amazingly BCD arithmetic is not native to any modern language, always added as a library.

Anyway there is still a fair amount of COBOL and FORTRAN around. The compilers for those languages produce incredibly tight code that runs super fast, because they were build back when computers were 1000 times slower and smaller. For tasks that run at night in a batch process, these old languages were very suitable. I would not try to build graphical interactive software in them, very cumbersome.