Someone's height is a pretty good measure of where they lie on the scale of
adulthood. Except for a small percentage of outliers.
On Tuesday, August 24, 2021, 08:48:26 AM EDT, Gerhard Adam
<[email protected]> wrote:
> length isn't a good measure of complexity
Really? Who dreams up this nonsense? Define "complexity" and then perhaps an
argument can be made about causes or measurements. Until then it is a silly
claim. Length is NOT a MEASURE of complexity any more than height is a measure
of adulthood. It is foolish to pretend that two characteristics are
necessarily the cause or measure of each other. If this is disputed, then give
me an equation or a measurement that can be examined to show how the length of
code gives rise to increased complexity. Remember the point isn't that complex
programs are long, but rather than length is an actual measurement of
complexity.
However, in the final analysis it comes down to "intent" or "purpose". In
short, can an error-free program be produced "on demand"? If the answer is no,
then all the claims are nonsense in taking credit for doing something that
can't actually be controlled. If the answer is yes, then one can question why
the author feels justified in being a thief by not producing such programs all
the time.
Actually any claim that programs can be produced "error free" and "on demand"
is probably nonsense and is justifiably questioned.
-----Original Message-----
From: IBM Mainframe Discussion List <[email protected]> On Behalf Of
Bill Johnson
Sent: Tuesday, August 24, 2021 5:07 AM
To: [email protected]
Subject: Re: Programs that work right the first time.
I said the vast majority of REXX/CLISTS are not very long. 40 was not MY line
in the sand. And that's from 40 years of seeing REXX/CLISTS. Some written in
house and some from vendors.
On Tuesday, August 24, 2021, 08:00:24 AM EDT, Jeremy Nicoll
<[email protected]> wrote:
On Tue, 24 Aug 2021, at 12:16, Bill Johnson wrote:
> The hilarity continues. You say that length isn't a good measure
> of complexity
I did, that's true. But in what I wrote below I also said that I wasn't
claiming that my longest example was particularly complex.
Probably the most complex code in what I did describe is in the general macro I
wrote (which frontends Kedit's own menu support which is somewhat limited) to
handle more complex menus. That's about 650 lines of code.
You might be unfamiliar with Kedit; it's a PC version of IBM's Xedit, and it
has lots of commands for setting/querying editor status & control parms, plus
of course commands that directly edit data.
Writing good Kedit macros is broadly comparable to writing Ispf edit macros.
> and then search high and low for the longest REXX programs
> you can find.
That's because of that "40-line script" comment of yours which
strongly implied you think that no-one writes larger execs.
Incidentally I noticed I have an old copy of an IBM rexx exec
here - ISPDTLC - which is 11,174 lines of code. It was written
in 1989 so if the same thing still exists I would expect it might
have grown a bit. I don't imagine it's trivial. Its purpose is to
"Convert SAA Dialog Tag Language tags to ISPF source panels,
message files, command tables, etc."
Back in the early 1980s I wrote some long (& complex) COBOL
programs. I wrote a compiler in COBOL for a document/data
definition language I'd invented, then a sort of structured text
editor that allowed a user to walk through a document that
adhered to such a predefined structure adding, editing &
removing text that complied with the definition, moving nodes
(chapters, sections, pages ... whatever) around etc. It was, I
think, a sort of precursor to a DTD-driven XML editor.
It had to handle variable length snippets of text, so part of
the editor implemented heap storage for those strings. The
total amount of working storage the compiler supported was
not enough to hold documents and all the control structures
so I wrote a paging subsystem (still in COBOL) to move huge
chunks of data in & out of working storage. Quite a lot of
the data being moved was itself control tables for other parts
of the data. When the thing was in debug mode one could
follow the linked-lists that held the whole data-structure
together, edit data and pointers & even trigger the program's
garbage collector.
COBOL was, of course, not the best language for this, but I
was required to use an IBM-supported language that our
installation had a licence for. It would have been a lot easier
to use our Pascal compiler but that came from a German or
Austrian university and was ruled out.
--
Jeremy Nicoll - my opinions are my own.
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [email protected] with the message: INFO IBM-MAIN
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [email protected] with the message: INFO IBM-MAIN
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [email protected] with the message: INFO IBM-MAIN
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [email protected] with the message: INFO IBM-MAIN
