As I indicated, this person wasn't a programmer, he was an algorithm developer. Completely different talent and skillset altogether. While some good algorithm developers are good programmers, there are fewer good programmers who are good algorithm designers. Typical development cycle consists of the algorithm developer developing the concept and testing it (hence the need for them to be able to do some level of coding), implementation then follows. Typical implementation is on a different platform and environment altogether than the proof of concept code.
+--------------------------------------------------------------------------------+ If you're gonna be dumb, you better be tough
+--------------------------------------------------------------------------------+
No, we just *wish* it didn't. Destroys readability. Except for Fortran programmers. :-)
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 bad practice.
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.
with various 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 'meaningful' names.
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.
Looks familiar.
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.
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 were available.
*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 instruction.
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 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.
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 done."
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 :-).
In article , snipped-for-privacy@host122.r-bonomi.com (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 complaints.
My personal favorite is writing error messages like "There is no way that you should ever see this error message." But, you don't want an unhandled exception, even if it's "impossible".
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 when" head-scratching.
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 # we?
(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.
The guy who wrote the Fortran IV compiler for the GE400 series of mainframes (Charles something-or-other) had, on the whole, very informative error messages. One, however, made me spew coffee all over the desk when I saw it for the first time.
"The compiler has gotten lost. There are a myriad of possible reasons."
highly doubtful. *Absolutely* reliable for occuring and at what location in any particular build.
It was just that inserting/changing the diagnostic instrumentation caused the location to migrate.
Also, hard to get a timing problem, with a single, self-contained, module that is merely doing a sh*tload of computations.
I figured that the next guy along deserved the information. Heck, he makes some trivial one-line change, and the "Heisen-bug" re-appears, and there he goes, trying to figure out how *THAT* change causes the error "somewhere *totally* unrelated" to what he did. Possibly even happens _before_ the program gets to the point where he made the change.
I did enough of those, I had a standard format for it: "Impossible error {{number}} Internal program logic error. Notify programming immediately!"
HomeOwnersHub website 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.