Die COBOL... Die!!
-
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
There's nothing that can be expressed easily in Cobol, as far as I remember. You quite obviously have no ability for simple things that work do you. I never had a problem in COBOL, and I don't have problems in other the other languages that I picked up when I moved on to other jobs. Cobol is simple, its powerful, and it doesn't use crap gui's that waist cycle, bandwidth power. Get a life, quit being a jealous cry baby. Dan
-
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
-
There's already a COBOL.net... it must serve COBOL developers as much as J# intended in the first place with JAVA devs (but the realized that C# is quite the same... whatever...).
http://www.dotnetheaven.com/Articles/ArticleListing.aspx?SectionID=16[^] The above link should help the old timers, greybeards and punchcard jockeys get with it! Coboloo? better than Cobol++ or Cobol#
-
There's nothing that can be expressed easily in Cobol, as far as I remember. You quite obviously have no ability for simple things that work do you. I never had a problem in COBOL, and I don't have problems in other the other languages that I picked up when I moved on to other jobs. Cobol is simple, its powerful, and it doesn't use crap gui's that waist cycle, bandwidth power. Get a life, quit being a jealous cry baby. Dan
-
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.
I've gotten such a good laugh reading this thread. I was relatively late on the COBOL programming scene. I started programming COBOL and Fortran in 1972. I really don't remember C being an option until the 1980s. :-D COBOL is/was a great language because anyone could be taught it. That didn't make them good programmers, but it did exactly what companies needed. Lots of warm bodies that could write code. Very much like today's modern(?) languages, almost anyone can learn them but the majority of today's programmers are just as bad as yesterday's COBOL programmers. It's not the language that is crappy, it's the people that think they can code. I've learned a number of other languages since my COBOL days, IBM Assembler, C, C++, Powerbuilder, VB, SQL, Actionscript, to name a couple. The really amusing part is that I see programmers making the same types of errors over and over. You get a spec if you're lucky, you start coding, you do some quick testing to make sure that it does what you think it should and then move on. There was a saying that I read years ago. 95% of all programmers should flowchart but only 5% do. That's why we have so many crappy programs, that perform badly and need constant maintenance. Not because the languages we program in are bad, it's because programmers don't learn the languages well enough to express the problem clearly. Anyone remember COBOL's "Alter goto?"
-
There's nothing that can be expressed easily in Cobol, as far as I remember. You quite obviously have no ability for simple things that work do you. I never had a problem in COBOL, and I don't have problems in other the other languages that I picked up when I moved on to other jobs. Cobol is simple, its powerful, and it doesn't use crap gui's that waist cycle, bandwidth power. Get a life, quit being a jealous cry baby. Dan
droolin wrote:
You quite obviously have no ability for simple things that work do you
Yes, I actually use a bunch of mirrors to light up my fireplace. But my real answer is: I have no simpathy for repeated blocks of code that do exactly the same thing ("Mantainability, whatever the heck is it?") Not to speak about the compiler/interpreter bugs: I know that even MS.NET has even more bugs, but it's a much younger environment whem compared to Cobol ones.
droolin wrote:
I never had a problem in COBOL
In my experience, I'd say I hadn't more (but neither less) problems in Cobol than I had/have in other languages. As far as the language I simple find it horribly (and uselessly) verbose.
droolin wrote:
Cobol is simple
That's undisputable! A boss of mine teached me Cobol with this words: "Cobol has four instructions: READ, WRITE, MOVE, IF. Or at least, these are the ones you're going to use" I felt a little worried... (more about my boss, though)
droolin wrote:
its powerful
What do you mean by "powerful"? I think this point is disputable: if you're looking for pure performances nothing compares to pure assembler (machine code), Cobol is interpreted; if you're looking for mantainability, id depends on your "roots". You may be wrong or right, depending on the point of view, but that's not a clear point.
droolin wrote:
and it doesn't use crap gui's that waist cycle
That's totally false: id depends on the operating system you're running the Cobol interpreter, it's not a language feature: Cobols for Windows actually use [crap] gui. You (and I, for that matters) may like it or not, but people is accustomed to use Windows or Macintosh or Linux/XWindows software, not Unix System V Release command line interface based software.
droolin wrote:
bandwidth power
Again, this is not a feature of the language: well written Client/Server code (VB4, for that matters) can actually use less bandwith than poorly written Cobol one: in C/S architecture I never wrote a loop through a thousand of record to find out a single customer, while I've seen dozens of Cobol programs do exactly this.
droolin wrote:
Get a life
-
There's nothing that can be expressed easily in Cobol, as far as I remember. You quite obviously have no ability for simple things that work do you. I never had a problem in COBOL, and I don't have problems in other the other languages that I picked up when I moved on to other jobs. Cobol is simple, its powerful, and it doesn't use crap gui's that waist cycle, bandwidth power. Get a life, quit being a jealous cry baby. Dan
droolin wrote:
You quite obviously have no ability for simple things that work do you. I never had a problem in COBOL, and I don't have problems in other the other languages that I picked up when I moved on to other jobs. Cobol is simple, its powerful, and it doesn't use crap gui's that waist cycle, bandwidth power.
I think that as long as there are large mainframe systems that do the "heavy-lifting" that COBOL seems to do the language will be around. For those who want it to "die" - that's silly. That's like saying that when the JigSaw was invented that the good old trusty Hacksaw should go away. Each still serves its respective purpose.
droolin wrote:
Get a life, quit being a jealous cry baby.
He was abused by his momma. ;) -CB
-
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!
Boffincentral wrote:
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.
That's exactly right, IMHO. I've never written COBOL myself (Like someone else here I came up from FORTRAN in the late 70's) but I respect what has been achieved with it. Technology moves on - no doubt. However the idea that EVERYTHING (in this case COBOL) must phase out for something new is ludicrous. As you have pointed out, why should any company that has that kind of money invested in a platform that WORKS spend tons and tons of money to replace something that is still serviceable? That's just nuts. However, in our particular economy (the U.S.) we think that our cars need to be replaced every three years, too - regardless of whether the ones we have are serviceable or not. Oh God ... don't keep that car past 100K miles - you won't get a good trade-in on that NEW one (that you may or may not need). From my viewpoint COBOL is a trusty old vehicle (that runs FAST I understand) that still has a serviceable engine and is still doing a great job. Those who think it needs to die ... fine, go do something else! Why this is such a big deal I just don't get. -CB :)
-
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
COBOL was near-enough OO, anyway, so it wouldn't take much work. And I really, really miss my 88 lines!
-
droolin wrote:
You quite obviously have no ability for simple things that work do you
Yes, I actually use a bunch of mirrors to light up my fireplace. But my real answer is: I have no simpathy for repeated blocks of code that do exactly the same thing ("Mantainability, whatever the heck is it?") Not to speak about the compiler/interpreter bugs: I know that even MS.NET has even more bugs, but it's a much younger environment whem compared to Cobol ones.
droolin wrote:
I never had a problem in COBOL
In my experience, I'd say I hadn't more (but neither less) problems in Cobol than I had/have in other languages. As far as the language I simple find it horribly (and uselessly) verbose.
droolin wrote:
Cobol is simple
That's undisputable! A boss of mine teached me Cobol with this words: "Cobol has four instructions: READ, WRITE, MOVE, IF. Or at least, these are the ones you're going to use" I felt a little worried... (more about my boss, though)
droolin wrote:
its powerful
What do you mean by "powerful"? I think this point is disputable: if you're looking for pure performances nothing compares to pure assembler (machine code), Cobol is interpreted; if you're looking for mantainability, id depends on your "roots". You may be wrong or right, depending on the point of view, but that's not a clear point.
droolin wrote:
and it doesn't use crap gui's that waist cycle
That's totally false: id depends on the operating system you're running the Cobol interpreter, it's not a language feature: Cobols for Windows actually use [crap] gui. You (and I, for that matters) may like it or not, but people is accustomed to use Windows or Macintosh or Linux/XWindows software, not Unix System V Release command line interface based software.
droolin wrote:
bandwidth power
Again, this is not a feature of the language: well written Client/Server code (VB4, for that matters) can actually use less bandwith than poorly written Cobol one: in C/S architecture I never wrote a loop through a thousand of record to find out a single customer, while I've seen dozens of Cobol programs do exactly this.
droolin wrote:
Get a life
I think that object orientation with polymorphism is a great way to encapsulate complexity and decouple it, from the standpoint clarity, reusability and reliability. But the ability to define 01 level record formats in COBOL is still a desirable feature, for occasional use. Every now and then it would be useful to have a general-purpose struct that you can redefine easily. Compiler/interpreter bugs: I don't know what operating system you are referring to, but Unisys COBOL was perfectly solid. Repeated blocks of code that do exactly the same thing: It was possible to write COBOL that way, but we were taught structured programming, which is as modular as VB6. Add OO to COBOL and you do the same thing for COBOL that .NET did for VB6. Loop through a thousand records to find a single customer: You seem to be referring to reading a tape or a flat file. Unisys had an excellent database, called DMSII, which could do many of the things you can do in a modern relational database, although it did not have SQL. The experts tell me that DMSII was particularly strong in its ability to do a synchronized recovery. We were strongly discouraged from writing linear searches in DMSII. In short, I am grateful to be an OO programmer today, but I respect COBOL. ageless
-
There's nothing that can be expressed easily in Cobol, as far as I remember. You quite obviously have no ability for simple things that work do you. I never had a problem in COBOL, and I don't have problems in other the other languages that I picked up when I moved on to other jobs. Cobol is simple, its powerful, and it doesn't use crap gui's that waist cycle, bandwidth power. Get a life, quit being a jealous cry baby. Dan
droolin wrote:
There's nothing that can be expressed easily in Cobol, as far as I remember.
Must be you never did any complex logic in Cobol. Cobol can do in 3 lines what takes several routines / libraries and lots of code to do in C, C#, C++. When you need to process data, Cobol is the answer. It was designed for that purpose. When you want pretty GUI's, stay away because it was not designed for that. Example, opening a single join-file, which is actually 10 different physical files to us, pull out appropriate data records, and write output to a report. One or two lines of code opens the join file (10 files) "OPEN OUTPUT CUSTOMER-JOIN-FILE.", matches all indexes ala SQL but much simpler, gives appropriate input and output. Plus it runs FAST. It is stupid to throw a GUI on it just because you can. More code just to show a progress bar. Why? So the user has something to look at? That's dumb in console applications. It takes longer to run, just so you can show them it is not done yet. In Windows, the GUI is it's own thread. Process data in that thread and the GUI is non-responsive. Add overhead to create other threads, more code = more bugs. I grew up on machine code, assembly and C - great for running real-time machine controls. Stop the processor, change a couple of words of memory to patch a bug, then start the processor where you left off. Great stuff that most people can't understand. I have done business operations in C and Cobol, and I'll take Cobol over C for THAT purpose any day. Also, realize that not all people grasp software as us here on CP. I know programmers that don't know how a computer works. They like "ADD 1 to INDEX" instead of "i++" or "++i" or "i+=1" or "i = i+1". Give em one why to do it, period (please don't forget the period!). Patch a program? They can't do it. They don't understand debuggers to any depth, and have difficulty debugging their programming errors because they see what they want to see, not what is actually there. I ran a shop where the entire department was like that - honest. I'd debug code without ever looking at the code. Not all Cobol coders are like that (me, for instance), but I saw my share of em. Give em C++ or JAVA and they'll need to get another job. Gary
-
I've gotten such a good laugh reading this thread. I was relatively late on the COBOL programming scene. I started programming COBOL and Fortran in 1972. I really don't remember C being an option until the 1980s. :-D COBOL is/was a great language because anyone could be taught it. That didn't make them good programmers, but it did exactly what companies needed. Lots of warm bodies that could write code. Very much like today's modern(?) languages, almost anyone can learn them but the majority of today's programmers are just as bad as yesterday's COBOL programmers. It's not the language that is crappy, it's the people that think they can code. I've learned a number of other languages since my COBOL days, IBM Assembler, C, C++, Powerbuilder, VB, SQL, Actionscript, to name a couple. The really amusing part is that I see programmers making the same types of errors over and over. You get a spec if you're lucky, you start coding, you do some quick testing to make sure that it does what you think it should and then move on. There was a saying that I read years ago. 95% of all programmers should flowchart but only 5% do. That's why we have so many crappy programs, that perform badly and need constant maintenance. Not because the languages we program in are bad, it's because programmers don't learn the languages well enough to express the problem clearly. Anyone remember COBOL's "Alter goto?"
-
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
However, the only reason those things still run in COBOL is because its not cost effective for companies to spend the money to re-engineer them (that includes hardware and software costs) in another more modern language. Until then, it looks like we're stuck with it :)
-
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
-
http://www.dotnetheaven.com/Articles/ArticleListing.aspx?SectionID=16[^] The above link should help the old timers, greybeards and punchcard jockeys get with it! Coboloo? better than Cobol++ or Cobol#
Dalek Dave wrote:
Coboloo? better than Cobol++ or Cobol#
Yes. I'll bet it would be the most fun to say, if we can ever agree on how to pronounce it. Cobol++ would have to be COBOL PLUS PLUS. But Cobol# no thanks. X|
-
Without looking it up on Google does anyone in this thread even know what the COBOL acronym stands for? Steve :laugh:
No, but let me guess. COmmon Business Oriented Language. What's Google? :laugh:
-
No, but let me guess. COmmon Business Oriented Language. What's Google? :laugh:
-
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
Big Daddy Farang wrote:
But why develop anything new using it or its demon seed?
Because it works, and works great! Not for scientific applications, which have entirely different needs than business apps. If you would program some business apps, you would see it's benefits. I programmed in FORTRAN, and it SUCKS for business operations. It's not dead, because it still twiddles bits efficiently, just as COBOL does for business apps. I ran a COBOL shop that had no system crashes - NOT ONE! - in the 5 years I was there. A program would "abend", but the OS kept going. All other running programs never knew anything happened. No reboots, no blue screens of death. I can't even keep a stable development environment today, what with Fix Packs, new versions of tools, new versions of OS, etc., etc. I spend too much time being a sys-admin on my own machine. A waste of time. (Installed latest MS fixes last week - now XP crashes 2-3 times a day. Explorer crashed yesterday, Outlook crashed this morning. This is DUMB.) Half the day there was no "system operator". Maybe we should convert that shop to Windows and a real language like Visual Basic (cough, choke, puke), hire two system admins to keep it running, then more programmers to get the same amount of coding done because it is guaranteed to take longer to find and fix obtuse bugs. COBOL coders don't relate to pointers because they don't have them. How many coding errors involve pointers? Any guesses? So, the cost of conversion is not the issue. Most companies have computers to get work done. Changing platforms and languages to get the same work done, not better work but same work differently, is JUST PLAIN STUPID. The IT department is a COST center, not a profit center. All additional costs take away from the bottom line, meaning less money to expand, provide raises, grow, buy new hardware, bosses new car, etc.
-
Without looking it up on Google does anyone in this thread even know what the COBOL acronym stands for? Steve :laugh:
-
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