OOP vs COBOL - My stupid questiongreenspun.com : LUSENET : TimeBomb 2000 (Y2000) : One Thread
Excuse my ignorance ! My Stupid Question...
I've only ever worked with Object Oriented Programming and have virtually no understanding of Main Frames and or languages like COBOL. With OOP it is relatively easy to locate your functions and procedures and to test each one independently.
Could someone explain the how's and why's of OOP vs COBOL etc. and the impact to Y2K Remediation. I'm assuming older languages do not provide the easiest structure for isolating problems, functions, procedure, subs ????
always looking for more input !!! By the way... Yes I can say "duh". thanks
-- WebRNot (email@example.com), April 04, 1999
FWIW: there is an object-oriented version of COBOL, which provides the syntax for creating classes, objects, inheritance hierarchies, etc etc.
You can make a reasonable argument for the advantages of OOP for creating truly "modular" programs, with powerful mechanisms for associating related "chunks" of data and function into a single unit that we call an object.
But the fact that OO provides such capabilities doesn't prevent programmers from writing bad code. There's no guarantee, for example, that a large, complex system developed in C++ or Java won't have the same kind of Y2K problems that we've seen in the older languages.
I think it's more appropriate to say that Y2K problems were consciously, deliberately injected into older programs because of hardware limitations, rather than the inadequacies of the older programming languages. Or, to put it another way, the structured programming features of the older languages would have been sufficient to develop a modularized approach that would have made it relatively simple to cope with Y2K repairs within the code; indeed, the well-written COBOL programs that used common DATE functions have been relatively easy to fix. It's a more difficult issue for database repairs, since field expansion necessitates some pretty onerous logistical exercises of reading, expanding, and then rewri
-- Ed Yourdon (firstname.lastname@example.org), April 04, 1999.
I'm not a programmer but the way I understand it is that OOP is quite a bit easier than COBOL, the way the old masters like Mr. Yourdon did it. I'm sure Ed will fill you in as soon as he finishes his Easter ham!
-- @ (@@@.@), April 04, 1999.
I've done both and the first note is that they're DIFFERENT!
BEGIN TECHNO BABBLE-----------------------------------------------
Think of every method and every instance variable as being public. Alternately think of everybody as very friend-ly.
The resulting spaghetti code creates interdependencies that make it more difficult to debug - if you have a debugger in the first place.
Next, think of every record as being packed in an arbitrary manner to conserve space. Instead of a record with fields that can be used directly, you'll get, say, 14 bytes that represents the date, time, input operator #, agency #, transaction #, and client#.
In order to unpack this record, you have to bit-twiddle it to death, and shift left or right, who knows?
There is no standard way of doing it. The record is compressed so that it takes less space, and depending on lots of (now forgotten) factors, it could be done in a virtually arbitrary way.
END TECHNO BABBLE ---------------------------------------------------
So what you have is data (records) that are hard to deal with, and progams that are intertwined, interconnected, and open for abuse.
And you've got slow, old, HUGE machines, and thousands of them. The work is mind-numbingly tedious, it's not glamorous, and nobody in an IT shop really wants to do it. They want to work on new "sexy" projects.
Jolly like OOP to.
-- Jollyprez (email@example.com), April 04, 1999.
Its possible to write a COBOL/PLI/Assembler/whatever program that looks very OOP-like. However, OOP came into existence because of the arbitrary way in which software was developed in the past. The non-structured programs (the vast majority) became ever more difficult to maintain as they moved from version to version (and mainframe to mainframe). In the these 'classic' mainframe languages, there were simply no limits on how you created/selected/accessed functions and variables aside from quite simple compiler limitations. As Jolly pointed out, data file structures can be fairly bizarre. The result was a few very good program structures, many mediocre ones and a few horrendous examples. It was not always the fault of any one person or team. A given application might well move across several physical platforms (Honeywell to IBM to DEC to IBM) and be 'converted' to the corresponding mainframe dialect version of the language (say COBOL). After 10 or 15 years of such migration, the source code can resemble Etruscan.
-- RD. ->H (firstname.lastname@example.org), April 04, 1999.
the syntax in COBOL is RIGOROUS and bears NO relationship to the types of syntax in OOP.
A missing period will generate a minor compiler error and can generate a HUGE logic error.
COBOL, as you point out, handles data in a byte by byte manner, not in a variable by variable manner.
This is why a LOT of the evaluations being done by OOP guys who have been "retrained" for COBOL and have been passed, will show up as crashes. OOP folks move solid variables around by data name, with no need to know where the data is actually stored in the record. COBOL folks recognize that the whole record gets picked up, and the data item gets located by the programmer in his logic. Even if there isn't a date issue in the program, there is a data location issue in the record.
And now, Ed or someone will fill in the HUGE blanks we have left.
-- Chuck, a night driver (email@example.com), April 04, 1999.
Thanks guys, My vision is clearer... but I see that the water is much muddier than i realized... Waiting for more input from Ed
-- WebRNot (firstname.lastname@example.org), April 04, 1999.
IMHO, with all the demands on his time, we should not be asking Ed to spend his time on examples of COBOL coding problems.
-- Jerry B (email@example.com), April 04, 1999.
Seems like it's fair to say that there's not much light yet at the end of the COBOL tunnel.
-- Tom Carey (firstname.lastname@example.org), April 04, 1999.
Thanks for the insights... I know what you mean by OOP having the capability of being just as ugly, because I've written some UGLY code myself.
Thanks All for your input !
-- WebRNot (email@example.com), April 04, 1999.
A properly written COBOL program is no harder (or easier) to debug than a OOP in Java or C++. Generally speaking though, the debugging tools have better interfaces in C++ and Java. COBOL mainframe debuggers work but are often rather cryptic - at least the ones I have had to use were.
The COBOL code does require separating File and Variable declarations into two clear and easily recognised sections of the code (File Section and Working Storage) thereby giving you a nice way to see what the representation of a variable actually is without going through the pain of trying to find out what the real representation of some types actually are in such languages as MS Foxpro. Still, going in to fix something someone else wrote is never a fun job.
-- Paul Davis (firstname.lastname@example.org), April 05, 1999.