Die COBOL... Die!!
-
Talking on another thread we end up talking about COBOL and finding that IBM (at least) if developing a OO version of this ancient language. The very first question is: WHY? Shouldn't it be easier to learn/use a new good OO language instead of reinventing the wheel on some prehistoric (1950) concept? What should be worst: * Converting COBOL code to another language (I don't mean reverse engineer it, grab the business logic and recode the whole thing)? * Recompile it somehow (thinking that this OO version is somehow backwards compatible) with a OO facelift compiler but stay in the mud? I don't know... this feels like a very few group of people (compared to the developers community) trying not to loose their jobs and keep earning too much money developing and patching restrictive, but most very important, software. Here I leave some links: http://home.swbell.net/mck9/cobol/ooc/ooc.html Hurts my fingers to publish this link... You may also get nasty about this one (COBOL on .net): http://www.dotnetheaven.com/Articles/ArticleListing.aspx?SectionID=16
-
Talking on another thread we end up talking about COBOL and finding that IBM (at least) if developing a OO version of this ancient language. The very first question is: WHY? Shouldn't it be easier to learn/use a new good OO language instead of reinventing the wheel on some prehistoric (1950) concept? What should be worst: * Converting COBOL code to another language (I don't mean reverse engineer it, grab the business logic and recode the whole thing)? * Recompile it somehow (thinking that this OO version is somehow backwards compatible) with a OO facelift compiler but stay in the mud? I don't know... this feels like a very few group of people (compared to the developers community) trying not to loose their jobs and keep earning too much money developing and patching restrictive, but most very important, software. Here I leave some links: http://home.swbell.net/mck9/cobol/ooc/ooc.html Hurts my fingers to publish this link... You may also get nasty about this one (COBOL on .net): http://www.dotnetheaven.com/Articles/ArticleListing.aspx?SectionID=16
AlexCode wrote:
instead of reinventing the wheel on some prehistoric (1950) concept?
There be things about COBOL that them thar newfangled programmers with them hifalutin language could learn from. ;P Marc
-
Talking on another thread we end up talking about COBOL and finding that IBM (at least) if developing a OO version of this ancient language. The very first question is: WHY? Shouldn't it be easier to learn/use a new good OO language instead of reinventing the wheel on some prehistoric (1950) concept? What should be worst: * Converting COBOL code to another language (I don't mean reverse engineer it, grab the business logic and recode the whole thing)? * Recompile it somehow (thinking that this OO version is somehow backwards compatible) with a OO facelift compiler but stay in the mud? I don't know... this feels like a very few group of people (compared to the developers community) trying not to loose their jobs and keep earning too much money developing and patching restrictive, but most very important, software. Here I leave some links: http://home.swbell.net/mck9/cobol/ooc/ooc.html Hurts my fingers to publish this link... You may also get nasty about this one (COBOL on .net): http://www.dotnetheaven.com/Articles/ArticleListing.aspx?SectionID=16
Having worked in COBOL many many years ago I think you'd be surprised how unique and important a language it is in it's domain space. I have no doubt that there are a *lot* of very important finance relating things that touch your life regularly that are running on COBOL to this day.
"I don't want more choice. I just want better things!" - Edina Monsoon
-
Talking on another thread we end up talking about COBOL and finding that IBM (at least) if developing a OO version of this ancient language. The very first question is: WHY? Shouldn't it be easier to learn/use a new good OO language instead of reinventing the wheel on some prehistoric (1950) concept? What should be worst: * Converting COBOL code to another language (I don't mean reverse engineer it, grab the business logic and recode the whole thing)? * Recompile it somehow (thinking that this OO version is somehow backwards compatible) with a OO facelift compiler but stay in the mud? I don't know... this feels like a very few group of people (compared to the developers community) trying not to loose their jobs and keep earning too much money developing and patching restrictive, but most very important, software. Here I leave some links: http://home.swbell.net/mck9/cobol/ooc/ooc.html Hurts my fingers to publish this link... You may also get nasty about this one (COBOL on .net): http://www.dotnetheaven.com/Articles/ArticleListing.aspx?SectionID=16
The last time I saw any statistics on this, there were something like 100 billion lines of COBOL code, still in production today. COBOL is exceptional at chewing through raw data/flat files, and those ISAM file systems only got faster as hardware technology improved. Can you even imagine the costs associated with porting all that working code? And it's not just the COBOL code you'd have to port, but probably the back-ends as well! And all the equipment it runs on ... and then you have to train your staff, ... I'm stopping here, because I could go on-and-on from this point ... I'll wager that price tag is WAY more than 100 billion dollars ... Just a thought.
:..::. Douglas H. Troy ::..
Bad Astronomy |VCF|wxWidgets|WTL -
Having worked in COBOL many many years ago I think you'd be surprised how unique and important a language it is in it's domain space. I have no doubt that there are a *lot* of very important finance relating things that touch your life regularly that are running on COBOL to this day.
"I don't want more choice. I just want better things!" - Edina Monsoon
I would agree. Both my dad and one of my elder brothers work in COBOL. They've worked in areas including credit card and stock market processing as well as a number of other things in the banking industry. I am not exactly shocked that they are trying to give COBOL a facelift given how many places no longer teach it and how many systems rely on it. I believe I heard that something like 75% of COBOL developers are within 10 years of retirement age. I'm not sure if that is accurate, but if it is then we are going to have a shortage in the market fairly soon.
Some people sail through life on a bed of roses like a knife slicing through butter.
-
Talking on another thread we end up talking about COBOL and finding that IBM (at least) if developing a OO version of this ancient language. The very first question is: WHY? Shouldn't it be easier to learn/use a new good OO language instead of reinventing the wheel on some prehistoric (1950) concept? What should be worst: * Converting COBOL code to another language (I don't mean reverse engineer it, grab the business logic and recode the whole thing)? * Recompile it somehow (thinking that this OO version is somehow backwards compatible) with a OO facelift compiler but stay in the mud? I don't know... this feels like a very few group of people (compared to the developers community) trying not to loose their jobs and keep earning too much money developing and patching restrictive, but most very important, software. Here I leave some links: http://home.swbell.net/mck9/cobol/ooc/ooc.html Hurts my fingers to publish this link... You may also get nasty about this one (COBOL on .net): http://www.dotnetheaven.com/Articles/ArticleListing.aspx?SectionID=16
Having been involved in the COBOL discussion on the other thread to which you refer, I feel compelled to join this one also. But first I have a confession to make. I have never actually used COBOL. Not that I'm so new to the programming world. More that I come from a scientific rather than business background. I have used FORTRAN on punch cards. Now I'm sure that others will point out how much of that old code is still running today, etc. Terrific. Let it run. If it ain't broke.... But why develop anything new using it or its demon seed? Let it die in its sleep, for the love of God. I view COBOL much like heroin addiction. I don't need to try it to know it's not for me. BDF
-
Having worked in COBOL many many years ago I think you'd be surprised how unique and important a language it is in it's domain space. I have no doubt that there are a *lot* of very important finance relating things that touch your life regularly that are running on COBOL to this day.
"I don't want more choice. I just want better things!" - Edina Monsoon
John Cardinal wrote:
I have no doubt that there are a *lot* of very important finance relating things that touch your life regularly that are running on COBOL to this day.
COBOL will be reborn as DSL (Domain Specific Language) for financial applications. :suss:
-
Talking on another thread we end up talking about COBOL and finding that IBM (at least) if developing a OO version of this ancient language. The very first question is: WHY? Shouldn't it be easier to learn/use a new good OO language instead of reinventing the wheel on some prehistoric (1950) concept? What should be worst: * Converting COBOL code to another language (I don't mean reverse engineer it, grab the business logic and recode the whole thing)? * Recompile it somehow (thinking that this OO version is somehow backwards compatible) with a OO facelift compiler but stay in the mud? I don't know... this feels like a very few group of people (compared to the developers community) trying not to loose their jobs and keep earning too much money developing and patching restrictive, but most very important, software. Here I leave some links: http://home.swbell.net/mck9/cobol/ooc/ooc.html Hurts my fingers to publish this link... You may also get nasty about this one (COBOL on .net): http://www.dotnetheaven.com/Articles/ArticleListing.aspx?SectionID=16
-
AlexCode wrote:
instead of reinventing the wheel on some prehistoric (1950) concept?
There be things about COBOL that them thar newfangled programmers with them hifalutin language could learn from. ;P Marc
Must be that thar fancy book lernin
Why is common sense not common? Never argue with an idiot. They will drag you down to their level where they are an expert. Sometimes it takes a lot of work to be lazy The people in the lounge said I should google for the answer to a programming question but I do not know what search engine to use
-
Talking on another thread we end up talking about COBOL and finding that IBM (at least) if developing a OO version of this ancient language. The very first question is: WHY? Shouldn't it be easier to learn/use a new good OO language instead of reinventing the wheel on some prehistoric (1950) concept? What should be worst: * Converting COBOL code to another language (I don't mean reverse engineer it, grab the business logic and recode the whole thing)? * Recompile it somehow (thinking that this OO version is somehow backwards compatible) with a OO facelift compiler but stay in the mud? I don't know... this feels like a very few group of people (compared to the developers community) trying not to loose their jobs and keep earning too much money developing and patching restrictive, but most very important, software. Here I leave some links: http://home.swbell.net/mck9/cobol/ooc/ooc.html Hurts my fingers to publish this link... You may also get nasty about this one (COBOL on .net): http://www.dotnetheaven.com/Articles/ArticleListing.aspx?SectionID=16
Geez man, in my firm we are still developing things in COBOL. These are windows gui programs with COBOL backend, well usually around 15 - 20.000 lines of code, all global variables. Shivers :sigh: The problem is, as usually, the human factor. :sigh: People who have learned COBOL some 30-40 years ago, and have never learned anything besides it, today simply cannon program in anything else. Add that to the fact that in these cases the manager is also a COBOL dinosaur, and you have a COBOL development today... But, sometimes there can be a light in this tunnel... :-) Luckily, I managed to persuade the managers that COBOL for .NET :omg: is simply not the way to go. New development is now done in C# while COBOL experts are maintaining legacy applications. And, BTW, if you have never programmed in COBOL you can not really hate it. After programming in it you start to understand what the word hate means... :mad: BTW, where is that other thread?
-
Having worked in COBOL many many years ago I think you'd be surprised how unique and important a language it is in it's domain space. I have no doubt that there are a *lot* of very important finance relating things that touch your life regularly that are running on COBOL to this day.
"I don't want more choice. I just want better things!" - Edina Monsoon
John Cardinal wrote:
you'd be surprised how unique and important a language it is in it's domain space
Is this "uniqueness", that I'm not that reluctant to believe it exists, that I need someone to explain to me. I don't have COBOL as some sort of DSL for the financial area. I think it's well implemented on that area by inertia, meaning that: * was on that area that the biggest requirements began * being a promising language on its time it kept being chosen * most developers knows one language and try to do everything with it * most companies that manage COBOL software don't want it to be replaced by another language because there are less COBOL developers allowing them to get more money for trivial things. This is my main point of view. Am I wrong? I would really like to understand well this paradigm.
-
Geez man, in my firm we are still developing things in COBOL. These are windows gui programs with COBOL backend, well usually around 15 - 20.000 lines of code, all global variables. Shivers :sigh: The problem is, as usually, the human factor. :sigh: People who have learned COBOL some 30-40 years ago, and have never learned anything besides it, today simply cannon program in anything else. Add that to the fact that in these cases the manager is also a COBOL dinosaur, and you have a COBOL development today... But, sometimes there can be a light in this tunnel... :-) Luckily, I managed to persuade the managers that COBOL for .NET :omg: is simply not the way to go. New development is now done in C# while COBOL experts are maintaining legacy applications. And, BTW, if you have never programmed in COBOL you can not really hate it. After programming in it you start to understand what the word hate means... :mad: BTW, where is that other thread?
Dragan Matic wrote:
if you have never programmed in COBOL you can not really hate it
Not sure if that was a general comment, or directed at me. (If the latter, no offense taken.) Anyway the other thread is called, "the end" and the COBOL portion is a tangent onto which some folks veered. The tangent starts here: http://www.codeproject.com/lounge.asp?select=2195257&df=100&forumid=1159&fr=350#xx2195257xx[^] I hope that link works, I don't know nuthin' 'bout this here Internet stuff. :laugh:
Dragan Matic wrote:
After programming in it you start to understand what the word hate means...
No thanks, I'd just as soon not. I'm Mr. What's so funny about peace love and understanding? BDF -- modified at 17:56 Thursday 23rd August, 2007
-
Having been involved in the COBOL discussion on the other thread to which you refer, I feel compelled to join this one also. But first I have a confession to make. I have never actually used COBOL. Not that I'm so new to the programming world. More that I come from a scientific rather than business background. I have used FORTRAN on punch cards. Now I'm sure that others will point out how much of that old code is still running today, etc. Terrific. Let it run. If it ain't broke.... But why develop anything new using it or its demon seed? Let it die in its sleep, for the love of God. I view COBOL much like heroin addiction. I don't need to try it to know it's not for me. BDF
Right... Most arguments are based on the cost of rewriting code. Ok... most software can be hard to recode but not impossible and money well count I don't know what can be more expensive, maintain the dinosaur or kill it and replace it with a brand new Porsche. Note that Porsches still have problems, you have to learn a whole new way of driving, it's expensive to buy... but wouldn't you be happier dealing with a Porsche? Wouldn't it be easier to buy new parts? etc... :-> Why grab the damn dinosaur and stick 4 wheels on hes feet?
-
John Cardinal wrote:
you'd be surprised how unique and important a language it is in it's domain space
Is this "uniqueness", that I'm not that reluctant to believe it exists, that I need someone to explain to me. I don't have COBOL as some sort of DSL for the financial area. I think it's well implemented on that area by inertia, meaning that: * was on that area that the biggest requirements began * being a promising language on its time it kept being chosen * most developers knows one language and try to do everything with it * most companies that manage COBOL software don't want it to be replaced by another language because there are less COBOL developers allowing them to get more money for trivial things. This is my main point of view. Am I wrong? I would really like to understand well this paradigm.
No you've got it all wrong. I doubt anyone is using Cobol just because they know it and Cobol is specifically designed for business purposes. Common business software tasks are easily expressed in cobol code. Even back in the heights of cobol there were plenty of other languages around to use, even on the big IBM iron it was run on like C or pl/i or fortran etc. And don't forget that Cobol isn't still the 1969 or whenever it was first released, it's not static, it grows and changes just like everything else. I don't know why people make such a big deal about it really, if you know any of the other big programming languages you could pick up Cobol in a week or less if you were thrown in the deep end. I do prefer that DSL stuff be implemented as libraries for more general purpose languages like C# but that's just my preference as a generalist, if all you do every day is work with business stuff (I mean really obscure financial processing stuff) then there really is no need to go to another language, it's not like financing and book keeping have changed much in the last 100 years.
"I don't want more choice. I just want better things!" - Edina Monsoon
-
No you've got it all wrong. I doubt anyone is using Cobol just because they know it and Cobol is specifically designed for business purposes. Common business software tasks are easily expressed in cobol code. Even back in the heights of cobol there were plenty of other languages around to use, even on the big IBM iron it was run on like C or pl/i or fortran etc. And don't forget that Cobol isn't still the 1969 or whenever it was first released, it's not static, it grows and changes just like everything else. I don't know why people make such a big deal about it really, if you know any of the other big programming languages you could pick up Cobol in a week or less if you were thrown in the deep end. I do prefer that DSL stuff be implemented as libraries for more general purpose languages like C# but that's just my preference as a generalist, if all you do every day is work with business stuff (I mean really obscure financial processing stuff) then there really is no need to go to another language, it's not like financing and book keeping have changed much in the last 100 years.
"I don't want more choice. I just want better things!" - Edina Monsoon
John Cardinal wrote:
I doubt anyone is using Cobol just because they know it and Cobol is specifically designed for business purposes
Read this other testimony? http://www.codeproject.com/lounge.asp?select=2196789&forumid=1159&df=100&msg=2196789 It may not be some sort of DSL early stage but you have to agree that IBM is well implemented in the financial departments. If it decided to use COBOL as its development language then most likely other companies will adhere to it too to directly compete with them or get their customers applications support.
-
Talking on another thread we end up talking about COBOL and finding that IBM (at least) if developing a OO version of this ancient language. The very first question is: WHY? Shouldn't it be easier to learn/use a new good OO language instead of reinventing the wheel on some prehistoric (1950) concept? What should be worst: * Converting COBOL code to another language (I don't mean reverse engineer it, grab the business logic and recode the whole thing)? * Recompile it somehow (thinking that this OO version is somehow backwards compatible) with a OO facelift compiler but stay in the mud? I don't know... this feels like a very few group of people (compared to the developers community) trying not to loose their jobs and keep earning too much money developing and patching restrictive, but most very important, software. Here I leave some links: http://home.swbell.net/mck9/cobol/ooc/ooc.html Hurts my fingers to publish this link... You may also get nasty about this one (COBOL on .net): http://www.dotnetheaven.com/Articles/ArticleListing.aspx?SectionID=16
AlexCode wrote:
OO version
ahhh, yes... COBOL 2002 and beyond... or... "ADD 1 TO COBOL GIVING COBOL" (for C variant programmers.... COBOL++)
_________________________ Asu no koto o ieba, tenjo de nezumi ga warau. Talk about things of tomorrow and the mice in the ceiling laugh. (Japanese Proverb)
-
Geez man, in my firm we are still developing things in COBOL. These are windows gui programs with COBOL backend, well usually around 15 - 20.000 lines of code, all global variables. Shivers :sigh: The problem is, as usually, the human factor. :sigh: People who have learned COBOL some 30-40 years ago, and have never learned anything besides it, today simply cannon program in anything else. Add that to the fact that in these cases the manager is also a COBOL dinosaur, and you have a COBOL development today... But, sometimes there can be a light in this tunnel... :-) Luckily, I managed to persuade the managers that COBOL for .NET :omg: is simply not the way to go. New development is now done in C# while COBOL experts are maintaining legacy applications. And, BTW, if you have never programmed in COBOL you can not really hate it. After programming in it you start to understand what the word hate means... :mad: BTW, where is that other thread?
Dragan Matic wrote:
And, BTW, if you have never programmed in COBOL you can not really hate it. After programming in it you start to understand what the word hate means...
I have programmed in COBOL at school (1998-1999). It really wasn't too bad, all things considered. It was certainly easy enough to pick up and maintain. JCL on the other hand, sucked royally. Especially as we were writing our scripts in Word/Notepad without access to an interpreter... :mad: Flynn
If we can't corrupt the youth of today,
the adults of tomorrow will be no fun... -
AlexCode wrote:
OO version
ahhh, yes... COBOL 2002 and beyond... or... "ADD 1 TO COBOL GIVING COBOL" (for C variant programmers.... COBOL++)
_________________________ Asu no koto o ieba, tenjo de nezumi ga warau. Talk about things of tomorrow and the mice in the ceiling laugh. (Japanese Proverb)
-
Talking on another thread we end up talking about COBOL and finding that IBM (at least) if developing a OO version of this ancient language. The very first question is: WHY? Shouldn't it be easier to learn/use a new good OO language instead of reinventing the wheel on some prehistoric (1950) concept? What should be worst: * Converting COBOL code to another language (I don't mean reverse engineer it, grab the business logic and recode the whole thing)? * Recompile it somehow (thinking that this OO version is somehow backwards compatible) with a OO facelift compiler but stay in the mud? I don't know... this feels like a very few group of people (compared to the developers community) trying not to loose their jobs and keep earning too much money developing and patching restrictive, but most very important, software. Here I leave some links: http://home.swbell.net/mck9/cobol/ooc/ooc.html Hurts my fingers to publish this link... You may also get nasty about this one (COBOL on .net): http://www.dotnetheaven.com/Articles/ArticleListing.aspx?SectionID=16
-
Talking on another thread we end up talking about COBOL and finding that IBM (at least) if developing a OO version of this ancient language. The very first question is: WHY? Shouldn't it be easier to learn/use a new good OO language instead of reinventing the wheel on some prehistoric (1950) concept? What should be worst: * Converting COBOL code to another language (I don't mean reverse engineer it, grab the business logic and recode the whole thing)? * Recompile it somehow (thinking that this OO version is somehow backwards compatible) with a OO facelift compiler but stay in the mud? I don't know... this feels like a very few group of people (compared to the developers community) trying not to loose their jobs and keep earning too much money developing and patching restrictive, but most very important, software. Here I leave some links: http://home.swbell.net/mck9/cobol/ooc/ooc.html Hurts my fingers to publish this link... You may also get nasty about this one (COBOL on .net): http://www.dotnetheaven.com/Articles/ArticleListing.aspx?SectionID=16