The Beauty of the COBOL Programming Language(devops.com)
devops.com
The Beauty of the COBOL Programming Language
https://devops.com/the-beauty-of-the-cobol-programming-language-v2/
15 comments
sigh they say it is in the eye of the beholder. Look at Ada,some find it terrible yet to some an under appreciated marvel
I really don't see the beauty of COBOL in those examples. The real reason COBOL is still used is legacy software that companies don't want to convert (because it's costly and because it works). My company also likes to tell newcomers that you don't need to have studied computer sciences to use it.
Agreed, those examples don't really show the up-sides of COBOL. It's optimized for financial and business data processing, mainly on either the "back end" or as batch jobs (such as nightly re-processing of the day's transactions).
It has a lot of nice short-cuts and built-in "libraries" for that domain. You can get similar libraries/API's for say Java, but they'd be inconsistent for each shop because they are not built into Java. COBOL guarantees that a consistent set of business-oriented operations will be available, reducing the cross-shop learning curve and errors because they are time-tested.
Both FORTRAN and COBOL survive by NOT trying to be general-purpose languages, instead making sure they serve their domain well and consistently. I'm afraid some languages such as C# try too hard to be everything to everybody: a systems language, an application language, a scientific language, etc.
It has a lot of nice short-cuts and built-in "libraries" for that domain. You can get similar libraries/API's for say Java, but they'd be inconsistent for each shop because they are not built into Java. COBOL guarantees that a consistent set of business-oriented operations will be available, reducing the cross-shop learning curve and errors because they are time-tested.
Both FORTRAN and COBOL survive by NOT trying to be general-purpose languages, instead making sure they serve their domain well and consistently. I'm afraid some languages such as C# try too hard to be everything to everybody: a systems language, an application language, a scientific language, etc.
I think that the "beauty" (if you want to call it that) of COBOL was mostly in how it did, for the most part, exactly what you told it to do and rarely surprised you with unintended consequences (I mean, don't get me wrong, it still did, but not like C or Java or Javascript do). The problem was that you gave up a lot of expressiveness for this; when I was working in COBOL, I'd find myself cutting and pasting the same snippet of code in dozens of places with minor modifications - the language just didn't allow enough dynamism to permit decent code reuse. So in exchange for making it harder to accidentally shoot yourself in the foot, you'd end up with a codebase that needed dozens of code changes, far distributed from each other, to make functional updates - and hope that you didn't forget to update one of the cases.
I once worked for a company that used this language for it's main software product (for insurance claims management):
https://www.dbcsoftware.com/index.html
It was very, very similar to COBOL, and was the closest I ever got to using COBOL.
My work there was involved with developing an internally used piece of software written in Visual Basic, so I wasn't involved in the main product, but at one point they wanted to run everyone who did any kind of programming thru a set of training sessions on the language.
I found that it was just -barely- possible to build a version of Breakout using the language; it wasn't great, but it did work.
Later I used some of the extended functionality that was built into the language for network access to build a simple HTTP server; nothing fancy of course, just something to see if it could be done.
I am not sure how I feel about the language - or about COBOL in general, beyond it's legacy/historical value...
https://www.dbcsoftware.com/index.html
It was very, very similar to COBOL, and was the closest I ever got to using COBOL.
My work there was involved with developing an internally used piece of software written in Visual Basic, so I wasn't involved in the main product, but at one point they wanted to run everyone who did any kind of programming thru a set of training sessions on the language.
I found that it was just -barely- possible to build a version of Breakout using the language; it wasn't great, but it did work.
Later I used some of the extended functionality that was built into the language for network access to build a simple HTTP server; nothing fancy of course, just something to see if it could be done.
I am not sure how I feel about the language - or about COBOL in general, beyond it's legacy/historical value...
The company I work for uses COBOL code that was written 30+ years ago to handle accounting, payroll and some other critical stuff. It works, we don't have to mess with it, and in all likelihood it will continue to work for another 30 years.
The company I work for uses it for all of their customer billing, and when I was first doing my orientation I met another new hire that was joining the mainframe team, and from what he described, it is the same for most COBOL programs in most industries...legacy stuff that will continue to run for years
I remember distinctly being a kid, finding a book on programming in a thrift store.
It was all in COBOL. Previously I had only seen snippets of C++ and... perl I think.
Anyway, I saw the COBOL syntax, all-caps, everything spaced out evenly, and it delighted me immensely. It felt structural, weighty, substantial.
I think that if the javascript I write today looked as impressive to outsiders as COBOL looked to me then, I'd be showing off my work to a lot more friends & family.
This was a nice intro to cobol. Not sure if the title is accurate, as I didn't see much info on the beauty of cobol. But I did appreciate the comparisons with more modern languages.
I really didn't mind COBOL back when I took a (required) course on it back in college (around '89 or so). My biggest gripe with it was how constrained you were in some areas -- for example, you couldn't have arrays more than 3 dimensions, and a few other oddities that I don't recall off the top of my head.
My first business language.
Sometimes I think about what it must be like to go back to COBOL today. There's probably money in it-- there can't be too many developers left! The environment is probably stable.... You'd just have to learn to navigate all the programs in your workspace (and that can be no small task.)
I think I'll pass. I like it better in the modern world.
Sometimes I think about what it must be like to go back to COBOL today. There's probably money in it-- there can't be too many developers left! The environment is probably stable.... You'd just have to learn to navigate all the programs in your workspace (and that can be no small task.)
I think I'll pass. I like it better in the modern world.
I didn't mind COBOL as a language (but it was overly verbose), it was the JCL to set it up and kick it off that drove me nuts.
Oh boy, JCL... we had a couple of JCL gurus who understood it but the rest of is just kept hacking away at existing templates.
And CICS. But even worse than those two was a 1980s IBM business language called CSP ( Cross-System Product ). If you can imagine COBOL with all its limited expressiveness removed. I used to be elated when I opened a member and found it to be COBOL or C rather than CSP.
And CICS. But even worse than those two was a 1980s IBM business language called CSP ( Cross-System Product ). If you can imagine COBOL with all its limited expressiveness removed. I used to be elated when I opened a member and found it to be COBOL or C rather than CSP.
"The use of COBOL cripples the mind; its teaching should, therefore, be regarded as a criminal offense."
-- Edsger W. Dijkstra
I use to code Cobol on VMS as was required at a job. But the application was more of a systems application and had to be redundant.
So I would code using VMS system services so it did not look like Cobol. Did have to figure out how to create data structures in Cobol needed with the system services. So a 32 bit word for example, descriptor, reference.
I did the redundancy by taking out a cluster lock on the cluster with a wait ($ENQ_W). Then it was part of the startup on all the nodes in the cluster but only one got the lock and the others were stuck in a wait state. So simple.
If the Vax crashed or rebooted for maintenance another node would get the lock and run properly.
The devices the application interacted with were attached to terminal servers so all the nodes in the Vax cluster could see the terminal server.
What was ridiculous is that it should have been written in assembler or C instead of Cobol. Just because it was Cobol no one else was going to be able to maintain just because it was Cobol.
What normal Cobol programmer is dealing with system level things? I basically did everything using library and system services. So there was almost no lines of code that look like any normal Cobol.
Wonder if that code is still running?