Die COBOL... Die!!
-
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
-
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
I have a confession to make. I made a darn good living writing COBOL for ten years on IBM mainframes. I stopped using mainframes on a daily basis (except for a two month consulting engagement at a government department) over 12 years ago. There is a little known factoid that IBM sells more mainframe MIPS each year than in the preceding year. It seems to me that if customers still want it then why shouldn't IBM keep doing it? There is so much investment in mainframes and the supporting software that it would be financially irresponsible for a company to just throw it away. Then there are the arguments that mainframes are still the transaction processing kings, they are still the most reliable hardware and software platform and I/O throughput is still phenomenal. So it's not just COBOL, but everything else that goes with it you would have to first bring up to spec. Many high end UNIX platforms are getting pretty close to mainframes but the Windows Server platform has years to go. Probably (long) after I have retired!
-
One of the reasons that there is still so much COBOL in use, is that the you-beaut systems developed to replace them just didn't work.
-
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:
Common business software tasks are easily expressed in cobol code.
I beg your pardon? There's nothing that can be expressed easily in Cobol, as far as I remember. Yes, it's language was the closest one to the spoken English at it's time, but at the time programmers punched holes on a card (and real people had to stand up from the sofa and go to the TV to change channel, if there was another one). In my experience there are really two main reasons why it's still alive and kicking: 1) most of the software written in Cobol has its root before the 80's: this usually means millions of lines of code and rare documentation 2) many shops think: "We simply port our Cobol programs to the new Windows, Client/Server, Object-Oriented, I*net worlds". I think it's easier to see a healthy penguin colony in hell. I lived a terrible experience: "We are going into just a simple porting thanks to [XXX]Cobol, it'll take no more than six months". The project lasted for more than two years: phase 1: "We're not going to handle events, just a plain porting"; phase 2: "Hey, it's Windows, we must use comboboxes, radiobuttons and toolbars". What was the error? Phase 2 followed Phase 1 by just two or three weeks: we were doing a simple porting, totally refactoring our code. I left the company a few months later; two years later the company shut down and the project reached ITS end, even though it was not the planned end. Long live Sudden death to Cobol!
Marco Turrini
-
One of the main things about COBOL is: when you multiply two real numbers you get the actual result, not some close approximation.
Close approximation... I don't know but how long is a decimal number in COBOL? The wrong rounding operations relate specially to the language specification and to the CPU direct calculations. Most languages I had problems with it they (the problems) started at the 12th decimal place... being COBOL implemented on the financial area, is this really an issue or a relevant motive?
-
One of the reasons that there is still so much COBOL in use, is that the you-beaut systems developed to replace them just didn't work.
It happens... But I still don't have an explanation why they didn't work. My main intent with this thread is to understand what's so good about COBOL that really makes the difference. Like you said "... just didn't work", why? * Wrong new language chosen? * Bad new language implementation? * 50 years old COBOL developers with no experience on another language? * UI? * What?! :doh:
-
Why be so intolerant about a language you know little (or nothing) about? I have programmed in at least a dozen languages, and each has it good points and bad. Variety is the spice of life.:-O
Because people just love to jump on a bandwagon - it's easier than thinking. Surely, if a language was used 20 years ago it must be BAD by definition but the languages we like today are GOOD by definition and will stay that way forever. God forbid that in 20 years, people on forums are saying "C#, you use that pile of crap old man?" Rich
-
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
That still doesn't mean COBOL should be perpetuated. New and important finance relating things can be made to touch your life using numerous modern languages.
-
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
They could rename it to $#, make it CLR compliant, and every one will love it: financial apps suddenly get Visually Designed ...
Luc Pattyn [Forum Guidelines] [My Articles]
this weeks tips: - make Visual display line numbers: Tools/Options/TextEditor/... - show exceptions with ToString() to see all information - before you ask a question here, search CodeProject, then Google