May 28, 2023 at 10:17 pm
Jonathan AC Roberts wrote:Lynn Pettis wrote:Having supported a COBOL application for over 10 years, COBOL is a good language. Yes, it is wordy compared to modern programming languages, but that doesn't mean it isn't good. It is a tool and when used appropriately it works well.
In the past I've had to convert a Cobol system into .NET code. It was honestly one of the most unpleasant experiences of my working career. My primary frustration stems from the structure of Cobol programs, where all variables are declared at the top of the code and procedures are placed at the bottom. This lack of local variables makes it incredibly difficult to trace the origin of specific variable assignments. Moreover, the absence of modern programming language features, such as collections and data structures inherent in .NET and other modern languages, make Cobol stand out as a really bad language.
I'm curious... did you actually write COBOL for a length of time or just have to do the conversion?
Around 30 years ago, I spent a couple of years working with Cobol, writing and making amendments to the code. While I can still comprehend every line of it, I made a swift exit from that field as soon as I could.
May 29, 2023 at 11:32 pm
Jeff Moden wrote:Jonathan AC Roberts wrote:Lynn Pettis wrote:Having supported a COBOL application for over 10 years, COBOL is a good language. Yes, it is wordy compared to modern programming languages, but that doesn't mean it isn't good. It is a tool and when used appropriately it works well.
In the past I've had to convert a Cobol system into .NET code. It was honestly one of the most unpleasant experiences of my working career. My primary frustration stems from the structure of Cobol programs, where all variables are declared at the top of the code and procedures are placed at the bottom. This lack of local variables makes it incredibly difficult to trace the origin of specific variable assignments. Moreover, the absence of modern programming language features, such as collections and data structures inherent in .NET and other modern languages, make Cobol stand out as a really bad language.
I'm curious... did you actually write COBOL for a length of time or just have to do the conversion?
I started with COBOL and wrote it for more years than I care to remember.
And now you can even use .NET COBOL. Cobol isn't dead.
May 30, 2023 at 3:35 am
And now you can even use .NET COBOL. Cobol isn't dead.
As I said it would not surprise me if they have continued to try and create a better dinosaur rather than leaving the dinosaur behind. Monty Python is not far from the mark when they said "Folks thought I was daft to build a castle in the swamp but I did it anyway. It sank. So I built a second one and it sank. So I built a third one, it burnt down, fell over, and sank. So a built a fourth and it is still standing."
So in short if you waste enough resources, you can make a bad idea feasible. Was it daft to do so? Yes but do so they did anyway.
May 30, 2023 at 12:56 pm
Lynn Pettis wrote:And now you can even use .NET COBOL. Cobol isn't dead.
As I said it would not surprise me if they have continued to try and create a better dinosaur rather than leaving the dinosaur behind. Monty Python is not far from the mark when they said "Folks thought I was daft to build a castle in the swamp but I did it anyway. It sank. So I built a second one and it sank. So I built a third one, it burnt down, fell over, and sank. So a built a fourth and it is still standing."
So in short if you waste enough resources, you can make a bad idea feasible. Was it daft to do so? Yes but do so they did anyway.
So, how would you propose that most of the worlds largest financial institution's replace COBOL? Or, for the matter, many vary large companies?
Replace all the mainframes with servers? Move to the cloud? A move like that will cost more than most of these organizations make in a year.
COBOL may not a fun language to write code in, but there is certainly a use for it, and it will not go away anytime soon.
Michael L John
If you assassinate a DBA, would you pull a trigger?
To properly post on a forum:
http://www.sqlservercentral.com/articles/61537/
May 30, 2023 at 1:58 pm
So, how would you propose that most of the worlds largest financial institution's replace COBOL? Or, for the matter, many vary large companies?
Replace all the mainframes with servers? Move to the cloud? A move like that will cost more than most of these organizations make in a year.
COBOL may not a fun language to write code in, but there is certainly a use for it, and it will not go away anytime soon.
Oh I am confident that eventually it will take care of itself by virtue of the basic principals of nature. Survival of the fittest will eventually set in and these megalithic organizations that have built their companies upon prehistoric foundations will eventually be replaced by more agile and nimble future based companies. It just takes a long time for erosion to take down a mountain but it will and it does. Yes they will be able to shore up their ancient foundations for a while (like they are doing now as they are already experiencing that erosion) but eventually patching the dinosaur just will not be enough.
As for there not being enough money, well heck if they quit wasting it on propping up the old and focused on slowly renovating it to the new. They would future proof themselves but that is not how most megalithic companies think (always short-term thinking versus long-term thinking) and I have seen several of these kinds of companies get completely washed away due to this megalithic thinking.
In short, time will take them down and wash them away because they are and will continue to be just to slow to react to the changes that have already occurred and are coming unforseen just around the next bend in the curvy road of time.
May 30, 2023 at 2:15 pm
I haven't worked with COBOL in over 20 years. But I would rather deal with well written and structured COBOL than some of the garbage SQL, C, C#, VB, HTML, .... (I haven't had to deal with any R or Python, but I'm sure others have ran into the same poorly written code)
In your calling of COBOL as an out of date language that needs to removed. I would ask your thoughts about the internal combustion engine? This dinosaur has been around for longer than COBOL, but we still use it. Sure modifications have been made to make the more efficient over the years, but it still the same technology.
Should we ask everyone to stop using them and replace them with something else? While that may be a nice dream, it isn't going to happen anytime soon.
-------------------------------------------------------------
we travel not to escape life but for life not to escape us
Don't fear failure, fear regret.
May 30, 2023 at 2:44 pm
I vaguely remember COBOL from early in my career. I didn't think much of it as a language then, even though I was working in C/C++/Pascal. Of course, I think SQL is a somewhat broken language as well.
However, COBOL is in use and not likely to go away. If I were younger, I'd have been tempted to (re) learn is a decade ago as there were not many, but some very well-compensated jobs for maintaining old systems.
May 30, 2023 at 3:05 pm
I vaguely remember COBOL from early in my career. I didn't think much of it as a language then, even though I was working in C/C++/Pascal. Of course, I think SQL is a somewhat broken language as well.
However, COBOL is in use and not likely to go away. If I were younger, I'd have been tempted to (re) learn is a decade ago as there were not many, but some very well-compensated jobs for maintaining old systems.
There is a shortage of COBOL developers around here. The salaries being paid for experienced COBOL developers are astronomical.
Michael L John
If you assassinate a DBA, would you pull a trigger?
To properly post on a forum:
http://www.sqlservercentral.com/articles/61537/
May 30, 2023 at 3:51 pm
There is a shortage of COBOL developers around here. The salaries being paid for experienced COBOL developers are astronomical.
And this is part of what I am talking about as things become obsolete it gets costlier and costlier to maintain them and the money being wasted here could have been channeled into future proofing the system.
Sure the basic automobile concept is old and needs to be replaced but I thoroughly believe that the companies behind these beasts have been restricting advancements to make a better vehicle so they could further milk what they have -- still the horse and buggy has pretty much gone the way of the dinosaur. Further there are other technologies that have made leaps and bounds, for instance you cannot even buy an 8-track tape anymore or the technology used to play one and cassettes are even pretty much uncommon these days.
As someone on here says: Change is inevitable... not all changes are good. Addendum: And not working to future proof oneself is very bad.
Note: Just for clarity Future Proofing involves analyzing the changes and adopting the good ones over the not so good and bad ones but always planning for the furthest quality forward progression.
May 30, 2023 at 4:05 pm
Michael L John wrote:There is a shortage of COBOL developers around here. The salaries being paid for experienced COBOL developers are astronomical.
And this is part of what I am talking about as things become obsolete it gets costlier and costlier to maintain them and the money being wasted here could have been channeled into future proofing the system.
Sure the basic automobile concept is old and needs to be replaced but I thoroughly believe that the companies behind these beasts have been restricting advancements to make a better vehicle so they could further milk what they have -- still the horse and buggy has pretty much gone the way of the dinosaur. Further there are other technologies that have made leaps and bounds, for instance you cannot even buy an 8-track tape anymore or the technology used to play one and cassettes are even pretty much uncommon these days.
As someone on here says: Change is inevitable... not all changes are good. Addendum: And not working to future proof oneself is very bad.
Note: Just for clarity Future Proofing involves analyzing the changes and adopting the good ones over the not so good and bad ones but always planning for the furthest quality forward progression.
Michael L John wrote:There is a shortage of COBOL developers around here. The salaries being paid for experienced COBOL developers are astronomical.
And this is part of what I am talking about as things become obsolete it gets costlier and costlier to maintain them and the money being wasted here could have been channeled into future proofing the system.
Sure the basic automobile concept is old and needs to be replaced but I thoroughly believe that the companies behind these beasts have been restricting advancements to make a better vehicle so they could further milk what they have -- still the horse and buggy has pretty much gone the way of the dinosaur. Further there are other technologies that have made leaps and bounds, for instance you cannot even buy an 8-track tape anymore or the technology used to play one and cassettes are even pretty much uncommon these days.
As someone on here says: Change is inevitable... not all changes are good. Addendum: And not working to future proof oneself is very bad.
Note: Just for clarity Future Proofing involves analyzing the changes and adopting the good ones over the not so good and bad ones but always planning for the furthest quality forward progression.
Your perspective on what it would take to "eliminate COBOL" seems pretty narrow. The various systems written in COBOL I have worked with, and continue to work with, are mature in features, performant, cost effective, and secure. It certainly seems to me that these apps were future proofed long ago.
COBOL has already accomplished what you are advocating. If it ain't broke, don't fix it. Your personal bias towards COBOL is obvious. We get it, you despise it. Well, don't work with it then. Leave it to the people who are comfortable with it, and are confident that the applications are viable, and not only from a cost perspective.
In other words, we all understand your opinion. And have heard it over and over and over. I'm pretty tired of reading about it.
Michael L John
If you assassinate a DBA, would you pull a trigger?
To properly post on a forum:
http://www.sqlservercentral.com/articles/61537/
May 30, 2023 at 9:20 pm
Your perspective on what it would take to "eliminate COBOL" seems pretty narrow. The various systems written in COBOL I have worked with, and continue to work with, are mature in features, performant, cost effective, and secure. It certainly seems to me that these apps were future proofed long ago.
COBOL has already accomplished what you are advocating. If it ain't broke, don't fix it. Your personal bias towards COBOL is obvious. We get it, you despise it. Well, don't work with it then. Leave it to the people who are comfortable with it, and are confident that the applications are viable, and not only from a cost perspective.
In other words, we all understand your opinion. And have heard it over and over and over. I'm pretty tired of reading about it.
My perspective on what the solution should have been was and is not all that narrow, so do not tell me about what you do not know. However, what it is not is futile and the path that was chosen a long while back was a path of ultimate fultility.
Further, my position is not a matter of being biased as you incorrectly say but its about being factual and efficient, nothing more nothing less.
Sure corporate world has a lot of sayings that they abuse: If it ain't broke then don't fix it -- being one of these abused sayings. Still it has been proven more than once that the over usage of these sayings, this one in particular, more often than not comes back to bite them solidly, and in a bad way, later on. Therefore, yes to each their own but time is on my side which makes it the right side to be on. The inevitable will happen, it is just a matter of when. Further when it does, the longer that inevitability was pushed out the more drastic the issue will be once it is dealt with properly as that is a fundamental law of something that some highly knowledgeable guy put forth a long time ago. I have seen this played out in more than one company, and watched said companies fold due to -- not fixing what they felt was not broken.
As for your final statement -- take your own advise if you do not like it do not read it. No one is making you.
May 30, 2023 at 9:51 pm
I have been watching this conversation about COBOL - and I find it to be rather funny. I started working in this industry on a little known platform called MUMPS even though that platform was (and still is) running a majority of health care systems across the world.
Just because the platform and language are old - does not mean the platform and language haven't been upgraded and updated to meet current demands. I know for a fact that the old MUMPS platforms have been upgraded and improved to a point where not only are they competitive with current technologies, but often can beat the so-called latest and greatest offerings.
COBOL is no different and is barely older than Oracle and SQL Server.
Jeffrey Williams
“We are all faced with a series of great opportunities brilliantly disguised as impossible situations.”
― Charles R. Swindoll
How to post questions to get better answers faster
Managing Transaction Logs
May 30, 2023 at 10:58 pm
Well truth be told one can take any 3rd-generation language itself and it is fairly meaningless as computers only operate on object code -- so the question boils down more to the efficiency of the native language when it comes to human interaction and how well the compiler was designed.
So yeah if they have changed COBOL so much so that it really is no longer COBOL but another language all together and they simply are putting the COBOL label on it, then yeah maybe that name will still exist into the future but COBOL itself would be no more and this new language that they are calling COBOL, which is not COBOL, might be viable. Assuming that is what has been done. Heck they may have even removed one its most horrendous issues IMO when it came to the human aspect of writing COBOL which is (or was) its extreme verbosity. Back when I hung up that code, a simple program that took about a paragraph in C or Pascal or (I think even) Fortran took literally about 3 pages in COBOL. So that is like about 9 times the effort for the same results, or worse results if the tighter code used was C. So I could not see why such inefficiency was deemed a good thing. So can anyone say have they turned the old Model-T into a futuristic hover car or at least a hybrid?
Sure COBOL had about a 12 year head start on C (1959ish versus 1972ish) but I would find it hard to be convinced that anything written in the 1973 COBOL could not have been written better in 1973 C with both the human interface efficiency upgrade and machine processing efficiency upgrade. So yeah, they should have just chopped off the OBOL and gone full C, starting way back in 1973 (aka 50 years ago).
May 30, 2023 at 11:20 pm
I think they're having a meeting at Churchill Downs about this topic
-------------------------------------------------------------------------------------------------------------------------------------
Please follow Best Practices For Posting On Forums to receive quicker and higher quality responses
Viewing 15 posts - 66,361 through 66,375 (of 66,547 total)
You must be logged in to reply to this topic. Login to reply