Die COBOL... Die!!
-
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
-
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|
No! No! No! It's ________ADD ONE TO COBOL. (I had to put the underscores in to get it to start in column 8)
-
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.
ghle wrote:
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.
Agree 100 per cent. Use the right tool for the job.
ghle wrote:
A program would "abend", but the OS kept going.
But isn't that what's supposed to happen? Isn't that due to the OS being competent to protect itself? From what I've seen of various Windows systems, they are not. As you said later...
ghle wrote:
Installed latest MS fixes last week - now XP crashes 2-3 times a day.
I'm no fan of Windows, I just happen to use it some. My machine at work has XP Pro and while I have my share of problems with it, I've never had it crash. If you spend any time in the Lounge, you know that many people have horrible problems caused by Vista while others sing its praises. How can we explain such a wide variety of experiences with these operating systems? Maybe they're not really operating systems. Maybe they're just over-priced toys. Probably your crash-free COBOL shop was using a more solid operating system.
ghle wrote:
Maybe we should convert that shop to Windows...
That's a good one. :laugh:
ghle wrote:
COBOL coders don't relate to pointers because they don't have them. How many coding errors involve pointers? Any guesses?
Not sure where that came from. My guess would be a huge number of them. Most programming languages can cause damage in the hands of incompetents.
ghle wrote:
the cost of conversion is not the issue
Well it is prohibitive. I've never said we should convert existing, stable, running code. But I would make an exhaustive search for a better tool for new development. Failing to find one, I'd use COBOL if it truly is the best tool for the job. Thanks for telling us about your COBOL experiences. It's been an interesting learning experience, this thread. BDF
-
Without looking it up on Google does anyone in this thread even know what the COBOL acronym stands for? Steve :laugh:
Compiles Only Because Of Luck? Completely Obsolete BOLlocks? Changes Occasionally But Operationally Lazy? Got Any More?
-
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
I think the real question is why anyone would want to make an "object oriented" version of COBOL. I have been programming for 30+ years now, and I can't count all the wonderful innovations I have seen come and go. Exactly one of them -- structured programming -- was actually an advance over what went before. I am sure this will ignite a firestorm of rage and recrimination, but as far as I can see, OO is a fancy shmancy name for wasting a whole lot of time dancing around before you design your data structures and subroutine libraries (OOPs, I mean "classes" and "methods"). There is really nothing you can do with Oh-Oh that you can't do with a good assembler. Well, I should qualify that. Nothing useful. Obviously, there is always money to be made selling old wine in new bottles. I have learned and forgotten a Babel of languages, and at this point what I want from a language is for it to Get Out Of The Way and let me work on the problem. Visual Basic comes closest, so naturally they are pulling the plug on it.
-
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
ghle wrote:
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.
Well put. I think one thing that we need to keep in mind here is that not everybody is operating at the same level. For example - I spent the first 8 or 10 years of my career doing mostly O/S level coding in FORTRAN (believe it or not), C and Assembly (on PC's). The next 10 or so was in between where I wrote my own User Interface code for my software (under DOS). In that case I was doing both "systems level" and business code - in C at that point. The last 10 or so years I finally went GUI (thank you VB) and do mostly business-level coding there. While I have been in the lower layers in the past I'm now no longer as concerned with that as I am solving the business problems. I'll do the GUI stuff to the point where I respond to some events but I don't want to dive too deep. My point in saying all that is that we all sometimes tend to paint these situations with too broad a brush and think that everyone is operating at the same level we are. As you aptly pointed out that just ain't so. That's why I think that the "Kill COBOL" (substitute any technology for COBOL there) attitude is wrong. I never wrote COBOL myself because I thought it too "wordy" - but that was because I was interested in writing device-driver code then. -CB :)
-
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.
ghle wrote:
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.
I've found XP to be extremely stable myself - not sure why you're having so many problems - and I run all kinds of development tools - VS6, VS.Net, the works. I think the only time I've had real stability problems was if I was constantly installing and uninstalling stuff.
ghle wrote:
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.)
VB *IS* a real development language. I maintain a large system that is written 60% in VB and it "just works". Normally you only run into a lot of problems with it only if you're using a lot of 3rd-party stuff (custom controls) that aren't reliable. VB/Access (SQL Server) is pretty powerful for developing top-flight software in the PC environment. -CB
-
COBOL was near-enough OO, anyway, so it wouldn't take much work. And I really, really miss my 88 lines!
I don't miss them at all. The syntax was easy enough, but having to have a static working storage section and fd still bothers me. Annoying still was having to define the memory spaces (pic x9) and not having the ability to call an instance of an object (in leau of a subclass). :mad: While syntactically, java and C++ may be more cryptic, the flexability that they bring to the table far outway the negatives that the steeper learning curve incurs. If oo COBOL could keep its syntax, but add flexability in it's file structure, then it would be worth it. (think VB classic with inheritance).
-
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:
Luckily, I managed to persuade the managers that COBOL for .NET is simply not the way to go. New development is now done in C# while COBOL experts are maintaining legacy applications.
Why not? Can't you see it? Visual Cobol.Net. Sounds good to me. -CB :)
-
If memory serves, 'C' came from 'B' which derived from BCPL which came out of the University of Waterloo I think. -CB
-
Without looking it up on Google does anyone in this thread even know what the COBOL acronym stands for? Steve :laugh:
Take a look for more informations: http://en.wikipedia.org/wiki/COBOL