GreGorGy
BULLSFAN
That is something I recall from back then. COBOL programs could operate through a fückton of data much more efficiently than anything else at the time.
-
Join the MyBroadband community
South Africa’s biggest forum. Discuss, discover, and connect with thousands of members.
-
Question of the Day: Will you be watching the FIFA World Cup Final?
Where can i learn COBOL
- Thread starter f22raptor
- Start date
That is something I recall from back then. COBOL programs could operate through a fückton of data much more efficiently than anything else at the time.
True, but they also don't run COBOL programs on some small server, its usually a big mainframe. I'm sure many programming languages could get similar levels of performance given that hardware
newby_investor
Executive Member
True, but then you need to understand how the hardware works in order to code properly to suit it.
Though modern compilers do a lot of that work for you.
I don't mean coding in assembly language, I mean using something like C++
I do actually have some interest in learning COBOL, however not right now. I am more engrossed in my pursuit of a degree.
I nearly ordered a PiDP replica to maybe learn ALGOL, but FFS another distraction is not what I need right now
newby_investor
Executive Member
Yeah, but just naively coding will only get you so far. A big mainframe usually has a lot of CPUs which (sometimes) are not as powerful individually as you'd get in a high-end workstation. You need to code specifically to make use of that, and if done stupidly can actually end up being slower than just the single-threaded case. And more dangerous.
You have to take this into account in any case if you want your programs to perform well.
What specific things exist in COBOL to cater for this that I wouldn't be able to do as well in C, C++ or Java?
newby_investor
Executive Member
Not sure. I haven't used COBOL apart from a few hours worth of mucking about a couple of years back as I was curious.
I'd presume that their compilers take the architecture of the mainframe into account though, because COBOL was designed so that business-types could use it, not CS types.
Pretty much all multi core, distributed HPC code today is written in C, C++ or Java. These are the most efficient languages for this kind of work.
It’s also not something one wants to leave to the compiler.
I can only read COBOL and not code it, but one thing that impressed me in COBOL is the "move corresponding" statement, which one can use to rapidly copy from one record to another one, especially where the layouts are different: http://www.mainframestechhelp.com/tutorials/cobol/cobol-move-corresponding.htm
In general, COBOL is very good at working with fixed width records, which makes it a good option for record based data processing very common in financial situations.
Pretty much all multi core, distributed HPC code today is written in C, C++ or Java. These are the most efficient languages for this kind of work.
It’s also not something one wants to leave to the compiler.
I also see a lot of Fortran in the HPC arena.
Johnatan56
Honorary Master
Creators of COBOL invested 2 trillion dollars for the universal language. Businesses worldwide run on over 220 billion lines of code today. It would be a herculean feat to replace every single business program with a brand new language without introducing detrimental bugs. Hence, the cost just hasn’t outweighed the benefits of replacing COBOL.
...
The Case for the COBOL Comeback
Although COBOL is currently out of sight and out of mind, businesses have to focus on restitching the antiquated fabric of their infrastructure…eventually. Consider the average age of the COBOL programmer today.
That survey was taken 9 years ago. In 2014, Micro Focus says that the average age of COBOL programmer is still about 55-years-old.
https://blog.hackerrank.com/the-inevitable-return-of-cobol/
So the question become how long until we start replacing it or whether it's worth the cost of training new people to learn COBOL, which it probably is currently.