Can we please get back to the basics for this listserv?
Lionel B. Dyck <><
Website: https://www.lbdsoftware.com
Github: https://github.com/lbdyck
“Worry more about your character than your reputation. Character is what you
are, reputation merely what others think you are.” - - - John Wooden
-----Original Message-----
From: IBM Mainframe Discussion List <[email protected]> On Behalf Of
Gerhard Adam
Sent: Tuesday, August 24, 2021 9:02 AM
To: [email protected]
Subject: Re: Programs that work right the first time.
Really? Perhaps you can demonstrate this relationship by providing the
appropriate equation or basis for evaluation? I mean, something besides your
opinion.
Since you claimed it was a reasonable measure, then you need to provide the
evidence. BTW, you assumed that the conclusion about adulthood was human only.
Please tell how you devised that? Or is it also simply your opinion.
It seems that you make a lot of claims absolutely but have no evidence for any
of them.
-----Original Message-----
From: IBM Mainframe Discussion List <[email protected]> On Behalf Of
Bill Johnson
Sent: Tuesday, August 24, 2021 6:02 AM
To: [email protected]
Subject: Re: Programs that work right the first time.
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
----------------------------------------------------------------------
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
