See, I know the *real* swear-words! <grin>
I actually enjoyed using FORTRAN. It was a lot more tolerable, after you
figured out "equivalents" for 'useful' features in other languages. I even
managed "array of pointer to function" that didn't give any even ANSI WARNING
I'm *not* going to repeat what the salesman for a high-end Fortran-to-C
conversion service said when he got some of that code for a demo of their
product. <evil grin>
Then there was the time the boss made me write more than 40 lines of comments
to document a _single_ line of Fortran code. A *very*simple* line of code.
all it did was a _single_ 'shift' operation. This was one of those things
where _what_ was happening was absolutely clear, but *WHY* it worked took
a _lot_ of explaining. an 'abuse the data representation' situation. :)
I see now that I am in the presence of a true master.
I just couldn't stand the whole "doing things 4 times" aspect of it.
Hey, I'm gonna use a variable. Here is what it's called. Here is what
it's set to. OK, now, use it.
No conversion software has ever been worth a damn, that I've seen.
There's a "guide to writing obfuscated code" somewhere which is great
reading for amusement purposes. Unfortunately, some of the code-monkeys
I've worked with have mistaken it for a style guide, I think.
Ah, here one is, but it's not the one I was thinking:
The one I was thinking talked about using variable names that looked
like commands and so on, but my google-fu is deficient today.
Same reaction here. Of course you had to use DIMENSION and EQUIVALENCE
statements, but simple variables could be used without decaratives.
Some versions even set all data to zero when the program started, so you
wouldn't get the undefined values problem.
The best thing that ever happened to Fortran was Ratfor.
BTW, I really like C's use of functions and absence of subroutines. The
Modcomp realtime minis I used to use a lot had Fortran interfaces to
system functions that looked like:
CALL XYZ( A,B,C,D,.TRUE.,.TRUE.,.FALSE., ... .TRUE.,0)
I contemplated homicide every time I had to figure out what one of those
was actually doing.
When we transitioned from doing algorithm development in Fortran to C,
one of our more senior alg developers finally acquiesced and decided he
could live with using C when he found the GOTO statement.
Absolutely brilliant algorithm developer, you just didn't want to have to
be the one who had to figure out what his code was doing.
If you're gonna be dumb, you better be tough
I'd thought that would be obvious based upon his delight in finding the
GOTO statement. :-)
If you're gonna be dumb, you better be tough
I can show you code that is _much_clearer_ with the use of the carefully
implemented goto than the equivalent mess in a "pure" structured form.
We won't even discuss setjmp()/longjmp() -- that's getting perilously close
to the COBOL "ALTER" verb.
And then there were the people that threatened to implement a 'COMEFROM'
Back in the early days, I had at least one job that required writing
Cobol programs. I was told my Cobol looked like Fortran :-).
Apparently most people didn't even know Cobol had a COMPUTE statement.
BTW, I know COBOL gets a lot of bad press, but it's still one of the
easiest languages to get a novice producing working code. Excepting
RPG, of course.
And I do have fond memories of the "MOVE CORRESPONDING" statement.
No, we just *wish* it didn't. Destroys readability. Except for Fortran
But the one that *really* doesn't belong in the language is ALTER. One place I
once interviewed at told me that they have only one programming standard in
the shop: use ALTER, get fired.
Yeah, but it still takes a long time to get them producing *good* code. :-)
That's another one that IMO should never be used. It's *far* too easy for
seemingly innocuous changes in the structure of a group item to produce
disaster. The other argument against it is that, while it saves development
time, it wastes maintenance effort as the programmer has to look at both data
structures, *carefully*, to see what gets moved and what doesn't. And since
maintenance typically consumes 80 to 90% of a program's life-cycle cost,
anything that saves development time at the expense of maintenance time is a
Doug Miller (alphageek at milmac dot com)
I'm not sure I agree with that. I could use meaningful names in Cobol
when Fortran was still limited to 6 characters, IIRC.
There you got me. I don't even remember that one. But I didn't do a
lot of Cobol. In fact, a lot of what I did back then was assembler.
Anyone remember the addressing capabilities of the GE400 and 600 series?
I still have fond memories of those.
Actually, I used it a lot in one-time programs whose purpose WAS to
change a structure :-).
But if preceded by a comment such as "Extract salary data from personnel
records", I don't think it was that hard to maintain. No, you didn't
want to use it on a highly dynamic structure, but a lot of programs and
data back before disk drives were pretty much cast in concrete after six
months or so - too much hassle to change a lot of tape files.
Anyway, I think we've reminisced about enough - back to woodworking :-).
Some COBOL code is _intrinsically_ virtually unreadable. without COMPUTE.
Try to imagine what data-decompression algorithms look like in COBOL.
(It _wasn't_ a matter of choice, that was the *only* language that that
shop used. CICS command-level COBOL, in fact.)
Variable width bitfield data is all *sorts* of fun.
line after line of
DIVIDE foo INTO bar GIVING baz, REMAINDER quux.
MULTIPLY something BY power_of_two,
ADD this TO that GIVING result.
thrown in, 'as needed'.
It's _all_ scratch-pad temporary variables, there's *NO* way to assign
Plus, 'bit twiddling' is an utterly foreign concept to COBOL programmers
in the first place.
There is simply _nothing_ you can do to make that code 'readable' by anyone
other than a systems "guru". And _they_ have to puzzle over it for quite
a while, because it would *never* occur to them to try to do that kind of
thing in _that_ language.
The _internal_ documentation for _what_ that module was doing was six or
seven times the size of the of the functional parts of the PROCEDURE and
DATA divisions combined. And management _still_ put a declaration on the
front of that module forbidding *anyone* but the author to modify it.
Yeah, and a lot of it was written by Fortran or assembler programmers. :-)
Thank you, I'd rather not.
I've always preferred environments where the programmers could use the
appropriate tools for the job.
To win a bet a number of years ago with a co-worker who claimed it couldn't be
done, I wrote a Cobol-85 program to manipulate individual bits in a
doubleword. It was an interesting intellectual exercise, but one with no
reasonable practical application other than winning a bet.
Probably why my colleague said it couldn't be done. OTOH, I began my career in
DP with four years in an assembler shop. Wrote two Cobol programs the entire
time; everything else was ALC. So I was intimately familiar with the concept,
and practice, of bit twiddling.
Comments help... if the programmer knows how to write them. :-)
I wrote a couple of modules like that myself... including one, in Cobol-85,
that performed closest-match searches of a thousand-element internal table.
The actual search code is only some two dozen lines IIRC, but with comments it
runs around four pages.
Doug Miller (alphageek at milmac dot com)
No choice in this situation. Smallish shop, IBM 4381, 3 'applications'
programers, *zero* 'systems' programmers. COBOL was the only language
product they had licensed.
I was a contractor, that they brought in to 'do the impossible'. Because
I could do d*mn near anything with whatever 'less than appropriate' tools
*GRIN* I had a reputation of "If you want something done, hunt up Bonomi,
tell him it's 'impossible', and stay out of his hair for a couple of weeks."
Yuppers. The primary reason it's foreign to COBOL programmers is that the
relevant verbs ('shift', 'mask', 'bitwise and', 'bitwise or', etc.) simply
do not exist in the COBOL vocabulary. If you don't have the concepts, you
can't think in those terms. You have to have been exposed to the concepts
elsewhere, internalized them, and then find 'equivalent functionality'
work-arounds. Knowing about 'modulo' (another verb that doesn't exist in
COBOL) helps greatly in getting down to the 'equivalent functionality'.
"sometimes". I once had to write an entire page of documentation for
one line of program code. That line of program code reduced to *one*
machine instruction. a 'shift' operation.
The comments were *utterly* lucid, including 'pictures' of exactly what
was going on, and why.
But people couldn't cope with the fact that this shift operation was being
done on a character string and *not* in a multiple of the bits-per-character.
Take a character string, shift it 'x and one-half' characters, and use the
result in an arithmetic comparison was just "too strange" to be believable.
My record is that full page, documenting a single line, a single machine
And then there's the fun when you get into 'fuzzy' math -- where the precise
value used simply *doesn't* matter.
Example: you have the Julian day-number of the first of this month, you
want the day-number of the first of next month. How do you get it?
The 'obvious' way is to convert to Gregorian, bump the month number
(remembering to handle overflow), and convert the result back to Julian.
Twice as fast, however, is to add 50 to day number, convert that to
Gregorian, and subtract the indicated 'day' of the month less one from the
unconverted day-number. Note: the number '50' is meaningless. _any_ value
between 31 and 59 works. every time.
Now, given the 1st of the month day-number, and you want the 1st of the
month 3 months out. you can do *exactly* the same thing. just using
100 as the number added, instead of 50. Again, '100' is meaningless. any
value between 90 and 120 works.
Lastly, if you have a parameter that is '1' if you want '1 month' out,
and '2' if you want '1 calendar quarter' out. you can simply use
'50*period' as what you add to the day-number. Even scarier, if you define
the values for that parameter as binary flags, then the next value
'4', gets you '6 months', and the successor ('8') gets you 'one year')
This is _amazingly_ useful in all sorts of bookkeeping applications.
But trying to explain _how_ that trivial little "50*period" incantation
accomplishes that magic is *very* involved.
I once overheard a manager tell another "I give Larry a job and he tells
me it can't be done. A week later he cones back and says it can, but
it'll cost more than it's worth. Two weeks later he tells me it's all
This was the same manager that when lunch hour came and he saw I was
immersed in code, he went out to the roach coach and bought my lunch,
quietly sat it on my desk, and left. Most times I eventually noticed it
and ate it :-).
(Robert Bonomi) wrote:
[long snip of interesting idea]
In similar situations, I have been known once or twice to write comments along
the lines of "Trust me: this works. If you can't figure out why, you probably
shouldn't modify it."
Those comments occasionally produced some chuckles... but never any
Doug Miller (alphageek at milmac dot com)
I specifically remember being taught _to_ use 9999 as a terminator, to
say "We're done processing data now". I'm sure that that particular
terminator was responsible for more than that Y2K bug.
Ouch. I tend to over-test and iterate as I'm writing something, myself.
Makes the problem more immediate with less "Now WTF did I do wrong and
Ow. Sounds like the run of multi-layer boards they had made, before
debugging the design. Turns out the component library had the wrong
info for a dual j/k flipflop - so all the resets were tied to the wrong
place through their resistors. I spent a non-trivial amount of time
making transparencies of the layers, tracing traces, and finding out
where I could drill which trace to get the right layer and not the wrong
layers, so I could avoid fly-wiring the whole damn thing. Engineer
never _looked at_ the design or he would have said "Hey, waitaminute,
you can't tie that there, it'll stay in reset all the time".
I must remember that one, thank you. I've found old code of mine which
includes comments like:
# Now we're going to do (thing). I'm not quite sure just yet how I'm
# going to pull this off, so let's read on and find out together, shall
(And I just learned that this version of vi automatically continues
comment blocks by adding the # after a cr/lf. That's kinda cool...)
A total rewrite is hard to agree to, but when it's needed, it's needed.
We're re-writing something right now (ref: earlier death threats to
Sean), which unfortunately has to be done without breaking prod - but,
to the guy's credit, at least it's somewhat modular so we can fix one
chunk at a time, just keep the gazintas and gazottas the same.
I was given a test one time in the EAM days to wire a collator to feend
three cards fron the primary followed by two cards from the secondary
and repeat. Blank cards, that is :-).
I couldn't do it, but an experienced hand showed me how. Lots of relay
clicking and cycle delays.
On Fri, 27 May 2005 22:11:12 -0700, Mark & Juanita
When I was managing programmers I used to get rid of those sorts. No
amount of brilliance was worth the pain down the road. I think C tends
to bring out those kinds more than other languages, but they show up
everywhere. It is that mentality that explains a lot of the garbage
running on our systems now.
"We need to make a sacrifice to the gods, find me a young virgin... oh, and
bring something to kill"
HomeOwnersHub.com is a website for homeowners and building and maintenance pros. It is not affiliated with any of the manufacturers or service providers discussed here.
All logos and trade names are the property of their respective owners.