Die COBOL... Die!!
-
It seems every 3 years there is some new "software thang" to do under the sun. But at the end of the day it's the same old BS. You still gotta parse, you still gota interface to the os and api's. The syntax may change but it's just the same ole bull bucky. Who cares if they add OO enhancements to COBOL. Who really cares anymore... -- modified at 11:58 Monday 27th August, 2007
Old Turd Visual FORTRAN Coder, MrPlankton
MrPlankton wrote:
Who really cares anymore...
Unfortunately, only those hiring new developers. They don't care what you know or how good you are, they care what new "software thang" you know. Wanted to hire, software engineer with the following qualifications: o 3 years Vista experience o 2 years Windows Mobile 6.0 experience o 1 year VS 2008 experience, o 5 years AJAX development in a major project, o Associate CS degree or equivalent
-
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:
In the olden days, when we were developing COBOL programs in a batch environment, we had to learn techniques that placed a very rigid coding and testing discipline on us. For example, when I first started in programming (1964 ), we used to get one compile and test per day. You made sure that the changes you put in were correct and you got as much out of each test as you could. Nowdays, programmers adopt the infinite number of tests approach - find an error, correct it and try again. They are usually working on their own where we used to work more in teams. With changes coming to the industry so fast, programmers wanting to keep up with the latest and greatest, abandon what they are doing and move on to fresh fields. It's good for them, but it doesn't help get the job done.
-
We are on the same wavelength here.
CodeBubba wrote:
I never wrote COBOL myself because I thought it too "wordy"
I used to think the same, before my COBOL days. However, I'm a 60+WPM typist now (thank you COBOL?) and most COBOL characters are on the normal keys. I have to stop and look every time I need curly braces, ampersands, exclamations,...!
CodeBubba wrote:
we all sometimes tend to paint these situations with too broad a brush
Sorry for VB comments. Here *I* am using the broad brush. :-O I actually support a Basic business system running on SCO Unix written years ago. Can't say I enjoy it, but it does the job. I've used VBA on occasion Bubba - Did you miss the adventures of the CPM world? :laugh: Oh my, I was programming RTOS 15 years before the PC was invented by IBM (remember when IBM used to build PC's). Now, it's Embedded VC++ on MS Mobile, doing voice, WiFi, GPS, printer drivers and Auto Id. Too many GUI problems and concerns - have to dive deep into GUI land. The main thread is now GUI, all else is secondary. Opposite of yesterday. Less fun, but cooler. Interesting note comparing this industry to others. If I were a welder 75 years ago, I could still use the same basic equipment and be proficient today. Looking for a job? VC++ doesn't cut it. Everyone wants C#, JAVA, or COBOL. Thank goodness for CP. I'll bet you can look at a DDL header and explain what each byte is used for. X| Thanks for the comments. Gary
Hi Gary!
ghle wrote:
Sorry for VB comments. Here *I* am using the broad brush. I actually support a Basic business system running on SCO Unix written years ago. Can't say I enjoy it, but it does the job. I've used VBA on occasion
No problem. After writing C/ASM/FORTRAN etc. for years I find BASIC very refreshing. Even in .Net I chose to stick with the VB dialect. The thing I find cool about VB is that I can use practically the same syntax across the entire range of technolgies I deal with. VB just really hit the spot for me - I think well in it. In VB6/VB.Net there is enough OO built in for me to construct objects I need to do stuff but it isn't so grossly detailed that it distracts me from what I'm trying to accomplish. Maybe I'm rare among developers but my entire development philosophy revolves around trying to keep things as SIMPLE as possible.
ghle wrote:
Bubba - Did you miss the adventures of the CPM world? Oh my, I was programming RTOS 15 years before the PC was invented by IBM (remember when IBM used to build PC's).
I came into computers right around 1975-76 so the CP/M machines were all there but I was just becoming interested in all of it. The first micro I saw was a CP/M machine (SWTPC S-100 machine).
ghle wrote:
Interesting note comparing this industry to others. If I were a welder 75 years ago, I could still use the same basic equipment and be proficient today. Looking for a job? VC++ doesn't cut it. Everyone wants C#, JAVA, or COBOL. Thank goodness for CP.
That's just the thing that kind of irks me about this industry. I happen to be of the opinion that for Windows desktop applications VB6 (with some extensions to the GUI items) is still best. It produces attractive and fast applications and talks well to the database layer be it Access, SQL Server or whatever. Microsoft comes out with .Net and then everybody all-of-a-sudden decides that the best tool ever invented ain't any good anymore. The reasoning behind it has nothing to do with VB6 itself - they just have a new tool now that everybody "decides" that you're supposed to go to. Ever try to develop a desktop application in VB.Net? It's really not all that much better than VB6, there's just more "stuff". OK, if you're going to write a Web Service or something then of course, .Net is better - and I use it for web-oriented stuff. But if I'm sti
-
MrPlankton wrote:
Who really cares anymore...
Unfortunately, only those hiring new developers. They don't care what you know or how good you are, they care what new "software thang" you know. Wanted to hire, software engineer with the following qualifications: o 3 years Vista experience o 2 years Windows Mobile 6.0 experience o 1 year VS 2008 experience, o 5 years AJAX development in a major project, o Associate CS degree or equivalent
Ooh, that is so true. I truly laugh out loud when I see some recruitment ads. I remember seeing an ad in early 2001 where 2 years .Net experience was mandatory!:laugh: I was working for Microsoft at that time and even I hadn't had any training on it!
-
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
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) He never used the power of COBOL then. There was even in the beginnings much more powerful statements then that. Perform to ultimate levels, tables to ultimate levels, case statement. Long before VB ever thought of them. 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. If that is how you code, then your coding skills are bad. I never used repeated blocks of code. You don't have to if you know how to do structured programming. Sorry, that is coding skill that cause's repeatable blocks of code. Not the language. And with your OO abilities in COBOL, which have been there for years. You have made no point at all in this statement. None. 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. Cobol wasn't developed for winblows. It was developed for main fraim computers that push large volumes of transactions and data. I wouldn't use COBOL on any server, that isn't it's strong point. And for you to even sugest that shows how little you actualy understand WHY it was developed. By the way, ever hear of a database? IMS, DB2? Who use's flat files? Except in some type of interface to populate a database. Again, your coding skills are not making a very impresable showing right now. Dan
-
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?"
Most programmers I met today only work from specs. They don't know how to think for themselves. Doesn't matter what language. They don't want to learn the buisness logic which they are coding for. They just want to do as they are told without trying to understand why they are doing it. They don't understand what the end product or their peace of the end product is spouse to do, how can they provide a valid product. Bad coders are bad coders. No matter what language. Dan
-
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).
kepha wrote:
I don't miss them at all.
With me, it's the fond memories of (particularly on slow days) defining 88s and procedure names so that the code read as if you were reading what it does in normal English (an art in itself, that has been possible in no language since COBOL). Who would ever have problems amending code that says, in words: "If there are too many then discard the three oldest", and the like? You can do that with entire COBOL programs, and then not bother to have to write 90% of the user manual, because the code explains exactly what it's doing. Recent OO standards push in a completely different direction -- "Make it as incomprehensible as possible!!!" Here's a typical (as in not at all unusual) line of Java code, which happens to be out there in the real world, doing Very important things: Interface interface - Interfaces.getInterface(INTERFACE); See a line of code like that, and you know instantly that it's going to take you an hour to chase up to see exactly what's happening (should I add that the app suite in question has five different things that are all called "interface"?) You shouldn't have to beat your brains out, figuring out what some spotty youth has written before you; COBOL proved that.
kepha wrote:
If oo COBOL could keep its syntax, but add flexability in it's file structure, then it would be worth it.
Nail. Head. Well said.
-
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?"
Rob954 wrote:
Anyone remember COBOL's "Alter goto?"
*shudders violently* I havent programmed in COBOL in yrs, but if I ever see an alter goto again it'll be too soon. It is, bar none, the most evil statement of any programming language I've ever seen and is probably responsible for giving COBOL a lot of its bad rap.
-
Okay, I wasn't going to weigh in on this but now you're mixing your metaphors here or something... You wouldn't replace a dinosaur with a Porsche... a horse maybe but not a Porsche. What you might replace with a Porsche is your '57 Chevy with the large block V8. And the thing is, when you put it in this context you realize that while there might be good reasons to buy that Porsche and retire the Chevy (better gas mileage, easier to find parts), the Chevy is still a thing of beauty, was a wonderful ride while it lasted, and actually got you to where you were going when you needed it to. What gets me about a lot of the posts on this thread is the disrespect for those things that paved the way to where we are today. We're not actually talking about dinosaurs here just older versions or types of the tools we use to build the software we get paid to build. Your average carpenter today doesn't use hand saws much but the good ones who only had hand saws and other hand tools to use built some pretty solid houses that are still standing today. Let's not disparage the old tools or the workers just because the trade has evolved and some things (not all) are easier to do with the new tools. Carl
First things first, I never meant to disrespect nothing or anyone.
cjbauman wrote:
older versions or types of the tools we use to build the software we get paid to build
This is my point... you put this in the past when you say "we use to" but my point is exactly why is it still being implemented, why are still new applications being developed on it, and why the effort of upgrading it to OO at this time?
cjbauman wrote:
Let's not disparage the old tools or the workers just because the trade has evolved and some things (not all) are easier to do with the new tools.
You're right until the point when maintaining the old house is more expensive than building a new one. This idea isn't correct for every COBOL implementation but I'm sure it will be good for most. I'm well convinced that converting a COBOL application to C# for instance is as hard as if it was FOX Pro instead of COBOL. Most problems rely on the lack (usually complete absence of) application business logic documentation not on the greatness of this or that language.
-
AlexCode wrote:
I don't know but how long is a decimal number in COBOL?
The key is that COBOL doesn't have to use floating point. The developer determines it's usage. COBOL uses integer arithmetic (makes it extremely fast) that has NO accuracy problems. The decimal point is tracked separately, numbers are normalized before calculations are performed. There are no rounding problems. BCD (Binary Coded Decimal) numbers are not easily expressed in "modern" languages. Each byte contains the numbers 0 through 9. A 16-digit number requires 16 bytes, a 7-digit number requires 7. Sign is encoded in the MSD, or is separate.
AlexCode wrote:
COBOL implemented on the financial area, is this really an issue or a relevant motive?
Errors are errors, 12 decimals or not. If you're calculating hourly/daily interest on my 10 gadzillion dollars, I want any error to benefit me, not you.
AlexCode wrote:
The wrong rounding operations relate specially to the language specification and to the CPU direct calculations.
Not necessarily true. It also has to do with how the code is written. Writing a lot of accounting programs (C, VC++ (on handhelds - slow processors), I never use floating point. All is done in integer arithmetic, with the decimal point normalized as required. Explaining why is normally an exercise in frustration. Nice thread, BTW. Gary
Thanks for the COBOL explanations. I had no idea about how it was implemented in COBOL.
ghle wrote:
All is done in integer arithmetic, with the decimal point normalized as required. Explaining why is normally an exercise in frustration.
BTW, Why? :doh: Decimals always worked fine for me... never gave me any problems. Floats are a pain when 10-1.5 can lead you to 8.499999999999999999999999 X|
-
MrPlankton wrote:
Who really cares anymore...
Unfortunately, only those hiring new developers. They don't care what you know or how good you are, they care what new "software thang" you know. Wanted to hire, software engineer with the following qualifications: o 3 years Vista experience o 2 years Windows Mobile 6.0 experience o 1 year VS 2008 experience, o 5 years AJAX development in a major project, o Associate CS degree or equivalent
-
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.
I never had trouble by having too much tools to use. I had trouble when my toolbox have nothing but old tools that don't meet the today's requirements. Sure I can always make "new" tools based on the old ones but will they ever be actually considered new? :doh: On the other hand, there's people that when have too many tools on their disposal try to use them all on a single job, even if that job only required half of the do be well done. There's still a third scenario... those illuminated people who invent new tools and the have to invent a way of using it somewhere. On this last scenario usually lies most of the tech hypes that come and go and most of us with some years around didn't even cared about.
-
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
Absolutely. One really must remember that everything has its own place and purpose. Event-driven models, forced to sit behind/in a gui framework, just do not fit transactional processing. Remember, transactional processing is back-office, streams of items in, process, filter, archive, and out - stuff that procedural languages COBOL/PLI/ALGOL/FORTRAN/C - can do extremely well and concisely - all with little fluff, transfer vectors for each instantiation, etc., etc. Sometimes it is appropriate to apply structure, abstraction, dynamic binding, etc, to transactional processing - implementable readily in C (and even COBOL with a little preprocessing) - but that is only structure and expression. That does not make COBOL any more appropriate for events driven by HUMAN interaction, nor C++/Net appropriate for transactions. chrysg
-
Thanks for the COBOL explanations. I had no idea about how it was implemented in COBOL.
ghle wrote:
All is done in integer arithmetic, with the decimal point normalized as required. Explaining why is normally an exercise in frustration.
BTW, Why? :doh: Decimals always worked fine for me... never gave me any problems. Floats are a pain when 10-1.5 can lead you to 8.499999999999999999999999 X|
AlexCode wrote:
BTW, Why?
- It's 100% accurate. 2) It's faster. 3) No rounding problems. 4) Smaller storage requirements. Floating points, like integers, are stored as binary, not decimal: 1/2, 1/4, 1/8, 1/16, 1/32, 1/64, etc. So 8.5 is stored perfectly as 8 + 1/2.:omg: But 10 - 1.89 I can see. 8 + 1/16 + 1/64 + 1/128 + 1/256 + ... (ouch, brain cramp) So you can see, financial accounting requires intimate knowledge of the underlying data storage and operations unless the language compensates for you. You can have errors in only a couple decimal places. Multiplying and dividing inaccurate numbers only compounds the effects. You end up with an inexact result. If the language can do math perfectly, you don't have to worry about which results might be inaccurate because there are none. You only have to worry about rounding the final result to pennies, which the language can do for you automatically, also. Gary
-
Great, but just as important is at least 1 year of VS 2008. :rose: Please send the perfect resume and salary requirements to HR@IWontContactYouAtAll.com. No phone calls please. :^) Gary
-
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
It's been many years since I coded COBOL on a Univac 1106 but as I remember, COBOL actually had a self-modifying code statement. If memory serves me correct it was something like: Modify [Paragraph Name] to proceed to [Paragraph Name]. You probably ask yourself why. Well in those days it took a CPU much longer to perform a "If (boolean expresion) ..." than a jump (and probably still does). So what we write today as: void SomeFunc() { static bool FirstTime = true; if (FirstTime) { ... ... FirstTime = false; } ... ... } with the (boolean expression) ALWAYS being evaluated. But the COBOL code does not: ... ... Paragraph-Name1 Goto Paragraph-Name2 Paragraph-Name2 ... ... Modify Paragraph-Name1 to proceed to Paragraph-Name3 Paragraph-Name3 ... ... This COBOL code accomplishes the exact same result as using a "first time" flag but with less CPU time. That was important when processing millions of utility bills for month-end billing and processor speeds where not measured in GHZ. All you good COBOL coders out there, forgive me if I don't have the exact syntax, but regardless COBOL did offer the ability to modify its code at run-time.
-
AlexCode wrote:
BTW, Why?
- It's 100% accurate. 2) It's faster. 3) No rounding problems. 4) Smaller storage requirements. Floating points, like integers, are stored as binary, not decimal: 1/2, 1/4, 1/8, 1/16, 1/32, 1/64, etc. So 8.5 is stored perfectly as 8 + 1/2.:omg: But 10 - 1.89 I can see. 8 + 1/16 + 1/64 + 1/128 + 1/256 + ... (ouch, brain cramp) So you can see, financial accounting requires intimate knowledge of the underlying data storage and operations unless the language compensates for you. You can have errors in only a couple decimal places. Multiplying and dividing inaccurate numbers only compounds the effects. You end up with an inexact result. If the language can do math perfectly, you don't have to worry about which results might be inaccurate because there are none. You only have to worry about rounding the final result to pennies, which the language can do for you automatically, also. Gary
-
It's been many years since I coded COBOL on a Univac 1106 but as I remember, COBOL actually had a self-modifying code statement. If memory serves me correct it was something like: Modify [Paragraph Name] to proceed to [Paragraph Name]. You probably ask yourself why. Well in those days it took a CPU much longer to perform a "If (boolean expresion) ..." than a jump (and probably still does). So what we write today as: void SomeFunc() { static bool FirstTime = true; if (FirstTime) { ... ... FirstTime = false; } ... ... } with the (boolean expression) ALWAYS being evaluated. But the COBOL code does not: ... ... Paragraph-Name1 Goto Paragraph-Name2 Paragraph-Name2 ... ... Modify Paragraph-Name1 to proceed to Paragraph-Name3 Paragraph-Name3 ... ... This COBOL code accomplishes the exact same result as using a "first time" flag but with less CPU time. That was important when processing millions of utility bills for month-end billing and processor speeds where not measured in GHZ. All you good COBOL coders out there, forgive me if I don't have the exact syntax, but regardless COBOL did offer the ability to modify its code at run-time.
Seeing the COBOL syntax I can see why it was adopted compared to C for example. It's a verbose syntax that you write as you speak. The same reason that later on gave so much popularity to VB for example. Understanding the so deep differences makes me even more reluctant about a COBOL OO or/and .net version
-
First things first, I never meant to disrespect nothing or anyone.
cjbauman wrote:
older versions or types of the tools we use to build the software we get paid to build
This is my point... you put this in the past when you say "we use to" but my point is exactly why is it still being implemented, why are still new applications being developed on it, and why the effort of upgrading it to OO at this time?
cjbauman wrote:
Let's not disparage the old tools or the workers just because the trade has evolved and some things (not all) are easier to do with the new tools.
You're right until the point when maintaining the old house is more expensive than building a new one. This idea isn't correct for every COBOL implementation but I'm sure it will be good for most. I'm well convinced that converting a COBOL application to C# for instance is as hard as if it was FOX Pro instead of COBOL. Most problems rely on the lack (usually complete absence of) application business logic documentation not on the greatness of this or that language.
AlexCode wrote:
you put this in the past when you say "we use to"
Uh, actually, not. If I had said "we used to use", that would've been past tense. There are references to the past in my post but this isn't one of them. ;) I guess I need to clarify what I was objecting to in my post. Two things and two things only: 1) The notion that a comparison of dinosaurs to Porsches was somehow an appropriate metaphor of the differences between COBOL and more modern languages. It's not and never has been. Dinosaurs were animals not cars. When you compare dinosaurs and Porsches you're comparing representatives from 2 completely different categories. COBOL is not in a completely different category from C#, it's merely an older tool used for the same purpose as C#; creating software. Of course, there's also the fact that dinosaurs no longer exist whereas COBOL obviously does. :-D My objection was only to the error in reasoning represented by the comparison. It was not to the notion that most current software development should be done using the best tools available. 2) What I saw as the implied disparagement/disrespect towards people who do work or have worked in COBOL. That part wasn't even addressed directly to you, if you'll review my post. At the time I was referring to postings from others but apparently you saw yourself in it since it was the first thing you addressed in your reply. I wasn't pointing fingers; just weighing in against an attitude I run into all too often these days from those I consider to be newbies. I guess this is a hot button for me, but I'm just plain tired of hearing people who (seem to) have no historical perspective and little (apparent) knowledge of the realities of how platform purchasing decisions are made in corporate America (or wherever) devalue the contribution of developers who worked well in technologies that they usually didn't have much choice about but that were, usually, state of the art at the time. Worse than that is the notion that COBOL is somehow still being kept around because the COBOL developers are stuck in their rut and refuse to change. The vast majority of us are/were not making budget decisions and are/were not really heard by those that do. I admit I don't really know what's being taught in universities today but classically trained software developers learned to see the choice of development tool(s) as something yo
-
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?"
Rob954 wrote:
Anyone remember COBOL's "Alter goto?"
Ugh! Yes, but, thankfully, in most COBOL shops I worked in, the nasty beast didn't make it through code review because it was specifically proscribed by published coding standards. Of course, published coding standards seem to be a rare thing these days, too.