In article , (Robert Bonomi) wrote:
In article ,
Doug Miller wrote:
In article , lgb
wrote:

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.

No, we just *wish* it didn't. Destroys readability. Except for Fortran
programmers. :-)

Some COBOL code is _intrinsically_ virtually unreadable. without COMPUTE.

Yeah, and a lot of it was written by Fortran or assembler programmers. :-)

Try to imagine what data-decompression algorithms look like in COBOL.

Thank you, I'd rather not.

(It _wasn't_ a matter of choice, that was the *only* language that that
shop used. CICS command-level COBOL, in fact.)

I've always preferred environments where the programmers could use the
appropriate tools for the job.

Variable width bitfield data is all *sorts* of fun.

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.

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'.

Looks familiar.

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.

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.

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.

Comments help... if the programmer knows how to write them. :-)

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.

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.

--
Regards,
Doug Miller (alphageek at milmac dot com)

Nobody ever left footprints in the sands of time by sitting on his butt.
And who wants to leave buttprints in the sands of time?