Old school COBOL is very wordy, and full of program sections and divisions of dubious value, half of them seemingly redundant (source: I've written some while working at a bank, a few decades ago).
It feels as if you were writing something like this:
Program Name The Program.
Author the_af
Data section.
Some numbers.
X 1.
Y 2.
Actual code section.
Program beginning.
About to start.
Let's do this.
Add X and Y, Giving Z, Z Being the Addition of X and Y, but not of W nor V. U is right out.
Having Computed Z, Z Being The Addition of X and Y, Z is therefore the Result.
Give Result.
Program End.
Ok, this is a parody, but it's also what writing COBOL feels like -- or at least, what it used to be like. And somebody thought because these were "English words", that this would somehow enable less technically minded programmers accomplish their tasks.
Like with C family vs. ML family vs. APL vs. Pascal family debates, some people consider those sort of syntax differences to be deal-breakers. I personally try to keep an open mind.
I've come to take, "If you can look past the syntax..." as a semantically void formulation that is only there because its presence is mandatory whenever you're making a statement about a language that doesn't look like C.
If it's any consolation, COBOL isn't a very interesting language, nowadays, despite its syntax. I had to suffer it a couple of decades ago, and I would never wish it upon anyone.
And I'm untroubled by syntax; I'd happily use C-like languages, ML languages, Lisps, etc. COBOL just isn't a good or interesting language nowadays, if it ever was.
There's a screenshot with some source code up there. It's kind of refreshing to see function calls where the syntax for pass by reference and pass by value is literally "by reference" and "by value".
Modern COBOL would have a DDL which makes using JSON-like and XML-like nested data structures as easy as its existing DDL makes using record-oriented data structures.
It’s pretty easy and straight forward. You run into more interesting issues working with it though.
I just got done (towel thrown) after a 12 hour workday where 30 minutes were code change, build, unit test and the rest was trying to get the tester, who is COBOL age appropriate, to understand how our program works, how we use APIs to communicate with other systems and how to test it.
In the end the Jira errand got sent back to me because of an error in an unrelated program that we verified existed earlier today before my code was deployed, because it ‘has to be the API program’. =,)
They’ve also apparently been testing all other APIs by sending simulated OK responses with the expected data <3
And remote pandemic work in a team where everyone is 2x my age has gotten me into a p. deep depression.
First day of intro to programming at my university and the professor was introducing himself and his background and how his first job was writing cobol at a Paper Mill. He said COBOL was a revelation at the time and that we would never need to learn or use it.
Enter stage left my first job as a developer in 2016 and I'm tasked with learning cobol to support customizations to their 25 year old Lawson Implementation.
I'll probably never use it again but reading and writing cobol code opened my eyes to different design patterns not often seen in more modern languages. Seeing clever implementations of features that come out of the box in modern languages was really neat.
That sounds super interesting. Can you describe some of the interesting design patterns/clever implementations you saw? I feel like there is a lot of benefit in looking at weird languages as it opens your mind to new ways of solving problems.
