UH2@PSUVM.BITNET (Lee Sailer) (04/10/88)
Often, an employer doesn't want someone who can think, apply principles
in novel ways, and be creative, as in "We have these 200 COBOL programs,
and they all use the depreciation tables in the IRS rulebook, and the
IRS just changed the rules. Get in there and change the programs to
match the new rules..."
IBM has been famous for hiring people with BA degrees but no computer
experience at all, and training them to do things the IBM way.
Certainly, schools like Stanford, Yale, and so on, are not interested
in *merely* training people.
At the other end of the scale are the JC's, and little out of the
way two-bit struggling four year colleges, where the professor is
lucky if the majority of the students are trainable at all.
In between things get murky. At a typical main campus of a state
university, perhaps half the students can "learn to think", while the rest
prefer to be "trained" so that they can get that COBOL job.
8-) Hmmm. I seem to be in a rather black mood today. Could it
be because I owe the IRS $1800 this year?
leeEGNILGES@pucc.Princeton.EDU (Ed Nilges) (04/12/88)
In article <38797UH2@PSUVM>, UH2@PSUVM.BITNET (Lee Sailer) writes: >Often, an employer doesn't want someone who can think, apply principles >in novel ways, and be creative, as in "We have these 200 COBOL programs, >and they all use the depreciation tables in the IRS rulebook, and the >IRS just changed the rules. Get in there and change the programs to >match the new rules..." The really sad thing is that you CAN be creative in Cobol. You can write a Cobol program, a TSO CLIST, or VM exec to change the code exactly (and even put in an exact comment as to date, time, and whodunit of change). But this sort of thing will get you in trouble in the average Cobol installation. See Phillip Kraft's excellent study, "Programmers and Managers" (Springer/Verlag 1977).
warren@psu-cs.UUCP (Warren Harrison) (04/15/88)
> In article <38797UH2@PSUVM>, UH2@PSUVM.BITNET (Lee Sailer) writes: > > >Often, an employer doesn't want someone who can think, apply principles > >in novel ways, and be creative, as in "We have these 200 COBOL programs, > >and they all use the depreciation tables in the IRS rulebook, and the > >IRS just changed the rules. Get in there and change the programs to > >match the new rules..." > > The really sad thing is that you CAN be creative in Cobol. You can > write a Cobol program, a TSO CLIST, or VM exec to change the code > exactly (and even put in an exact comment as to date, time, and > whodunit of change). But this sort of thing will get you in trouble > in the average Cobol installation. See Phillip Kraft's excellent > study, "Programmers and Managers" (Springer/Verlag 1977). I guess this really isn't the place to defend COBOL given the audience, but I would like to point out that probably the majority of people who love to trash the ole' girl either don't know COBOL from a candy bar, or if they have programmed in it, it was only in a one semester (or worse yet quarter) course in which they barely got into the PROCEDURE DIVISION. I have found COBOL to be orders of magnitude more useful in the areas for which it is meant than almost any other language I know. For example, not many languages offer you a uniform indexed file interface which is for the most part uniform across environments. Likewise few languages support big numbers with no round off errors (how about PIC 9(18) COMP-3?) due to the underlying number representation. Not many languages include a built in binary search verb, or a report writer. In fact, COBOL has a bunch of neat features, but the average computer science major never is exposed to them since the first COBOL course is (1) usually taught at the "beginning programmer" level, so little tim eis spent on the nice features of the language, and (2) is taught by faculty whose exposure to COBOL is little more than what they see in the book, and so aren't even aware how some of the stuff works. I taught a course in software engineering at the graduate level a few years back in which none of the students had ever even seen a piece of COBOL code. Yet these self same students would snicker knowingly when the phrase "COBOL" came up. I guess I'd like someone to let me in on the secret too. What's so bad about COBOL (besides not having an in-line looping statement - but I've found that tends to actually result in mor emodular code since every loop body has to be in a paragraph or section by itself)? Granted, I can write some pretty bad code in COBOL, but nowhere close to the bad code I can write in C. Using the STRING/UNSTRING/INSPECT verbs I have found COBOL's string handling to be almost as good as Turbo Pascal, and infact some compilers are actually (gasp) written in COBOL (eg, Micro Focus COBOL/2, so I understand). If I really want to fool with mantissas and exponents, I can have COMPUTATIONAL fields, and level 88's work better than boolean variables for most uses Anyway, I'm really looking forward to some insight on the problem. Warren Harrison The University of Portland
rick@kimbal.UUCP (Rick Kimball) (04/20/88)
From article <619@psu-cs.UUCP>, by warren@psu-cs.UUCP (Warren Harrison):
> Anyway, I'm really looking forward to some insight on the problem.
COBOL Mentality 101
o Use Globals whenever possible (You have no other choice!)
o MOVE statements are much more efficient than using address manipulation.
o Compilers written in COBOL do things the most efficient way.
o Create interpreted P-Code, not true excutables.
o Execute code from a data segment
o Modify the executable code on the fly
o Interface well to code written in other languages.
o UPPER CASE CODE IS THE EASIEST TO READ.
o Never use one bit when a byte will do.
o Never use 'Y' when 'YES' will do.
o READABLE CODE IS EASIER TO THROW AWAY WHEN IT DOESN'T WORK.
o NEVER use GOTO's; they are a sign of a Bad Programmer.
o ABOVE ALL, readabilty is most important, not functionality.
I left my last company because they tried to implement a PC
based product using COBOL. Originally, it was to be
written in 'C' and XENIX. I wasted five months trying to
make it work without any success. On my own time I
re-designed and re-implemented all the code in 'C'. The
goal of the product was to give the user sub-second response.
With COBOL they got ten second response. With the 'C'
version they got the target response.
When I showed them the results their response was; "Well we
don't have any 'C' programmers except you and two other
people. So we'll write sub-routines for the COBOL programmers"
(the other 20 people). At that point, I got a real job and
have been enjoying every productive moment since.
I really don't hate COBOL. :-) It just doesn't fit well with the
UNIX way of thinking. What I hate most of all is COBOL
thinking.
BTW: After I left, they cancelled the project after wasting
a lot of money on that could have been better spent on
improving PC-Pursuit. :-)
--
Rick Kimball Software Design Group
Maitland, FL 32751
W (407) 660-0006; H (407) 788-6875
UUCP: rick@kimbal, ...codas!flnexus!kimbal!rick
--
Rick Kimball Software Design Group
Maitland, FL 32751
W (407) 660-0006; H (407) 788-6875
UUCP: rick@kimbal, ...codas!flnexus!kimbal!rickjtchew@CSA3.LBL.GOV (Joseph T Chew) (11/09/89)
A number of people who have been chiming in on SoftEng lately will get a kick out of this month's IEEE Spectrum. There's an anecdote about an aging electrical engineer, a member of a curriculum committee, who had a choice in his senior year: either differential equations or spark transmitters. Guess which one he took, and how long the knowledge served him.