> 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
