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
May 31, 2023 at 2:08 am
So can anyone say have they turned the old Model-T into a futuristic hover car or at least a hybrid?
No. But consider that the Model-T still does exactly what it was designed to do. 😉 If that's all you need, an existing Model-T will do.
But, I do agree with the connotation implied by the "Churchill Downs" comment. 😀
--Jeff Moden
Change is inevitable... Change for the better is not.
May 31, 2023 at 3:21 am
Okay educate me -- what is Churchill Downs -- sounds like something happening in merry ole England but COBOL was created in down home America.
May 31, 2023 at 12:32 pm
-------------------------------------------------------------------------------------------------------------------------------------
Please follow Best Practices For Posting On Forums to receive quicker and higher quality responses
May 31, 2023 at 1:02 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.
I STILL have to write code in Mumps from time to time.
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 31, 2023 at 2:07 pm
If you ever had to deal with Assembler then COBOL would look like the futuristic flying car. When I was in college they taught us both Assembler and COBOL. I had to use both early in my career. I even had to convert an Assembler program to COBOL because there wasn't many of us that knew it. Now Assembler is a dinosaur, 1947 I believe. I have great empathy for anyone who would have to deal with that language now. How about some BASIC code? Who remembers that? But COBOL again looks futuristic compared to BASIC. IMHO
-------------------------------------------------------------
we travel not to escape life but for life not to escape us
Don't fear failure, fear regret.
May 31, 2023 at 2:26 pm
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).
OK. Let's both write a report with control breaks. I'll do it in COBOL ... in an hour or so. (Good COBOL programmers had templates for each major type of program and would start from that.) Your C program will take days (and will still have bugs in it).
COBOL, when written properly (structured and following best-practice rules, such as separate paragraphs for I/O), is also the most maintainable language.
One huge advantage COBOL also had was that you could move any data as just bytes (using a GROUP level number), whereas generally in other languages each char / numeric / binary value would have to be moved separately.
SQL DBA,SQL Server MVP(07, 08, 09) "It's a dog-eat-dog world, and I'm wearing Milk-Bone underwear." "Norm", on "Cheers". Also from "Cheers", from "Carla": "You need to know 3 things about Tortelli men: Tortelli men draw women like flies; Tortelli men treat women like flies; Tortelli men's brains are in their flies".
May 31, 2023 at 2:33 pm
If you ever had to deal with Assembler then COBOL would look like the futuristic flying car. When I was in college they taught us both Assembler and COBOL. I had to use both early in my career. I even had to convert an Assembler program to COBOL because there wasn't many of us that knew it. Now Assembler is a dinosaur, 1947 I believe. I have great empathy for anyone who would have to deal with that language now. How about some BASIC code? Who remembers that? But COBOL again looks futuristic compared to BASIC. IMHO
While it's amusing to think of COBOL as futuristic, it's important to note that both COBOL and assembler have gracefully aged into the realm of "outdated". They are both vintage artefacts in the ever-evolving world of technology. Put it this way: if programming languages were superheroes, COBOL would be Captain Nostalgia, and assembler would be The Ancient Coder. They might have once ruled the computing world, but now they're just sitting in a retirement home, reminiscing about the good old days of punch cards and magnetic tapes. So, while it's fun to appreciate their historical significance, it's safe to say that we've moved on to newer and more exciting languages that are better suited for the challenges of today. Time marches on, and so does technology!
May 31, 2023 at 2:33 pm
Yep Assembler was a chore, did you do data cards as well? BASIC was a better human interface than COBOL but then again that would greatly depend upon the flavor of BASIC. I think I learned at least 5 different forms of BASIC and my foggy remembrance of them is that they were pretty much like Pascal, yes you still had to use GOTOs in BASIC but if you were careful you could minimize those greatly. I think the only language I did not learn was machine code, and I cannot imagine having to code in that language and yet there were folks that did it and did it very well.
Note again please do not get me wrong, I do not despise COBOL. In fact, I tip my hat to its inventor as it was, as you say, the futuristic flying car of its day. However like Assembler, there are much better vehicles now as well as 50 years ago. In fact C can be as fast or faster than Assembler and I think this is partially because of highly advanced compilers for C.
Viewing 15 posts - 66,346 through 66,360 (of 66,815 total)
You must be logged in to reply to this topic. Login to reply