Programming Contest

On Mon, 1 Sep 2008 13:26:31 -0700 (PDT), Richard <riplin@azonic.co.nz>
wrote:

>> You might want to re-examine your own views of yourself, Mr Plinston. *You
>> describe a matter of style as 'idiotic';
>
>I was replying to a statement that called a particular style
>'idiotic', do try and stay in context.
>
>> idiot, according tohttp://www.merriam-webster.com/dictionary/idiot, is a term which is
>> 'usually offensive'.


Ahh, I'm not insulting the person - only his work (which I state isn't
really *wrong*, just idiotic). I'm sure that makes a world of
difference.

On Tue, 2 Sep 2008 01:19:04 +0000 (UTC), docdwarf@panix.com () wrote:

>The point I see you trying to make, Mr Plinston, is that you've found a
>Very Good Reason to develop a certain style. My question, quite simply,
>is: do you believe that there exist other Very Good Reasons, equally as
>valid as yours, which might result in code that shows a style other than
>yours?

Human nature unfortunately seems to have lots and lots of people who
won't or can't think this way. Most wars today are fought by people
who have their Right way, therefore the other guys are Wrong and must
be punished. Their belief that their way is right is a huge threat.

I suppose we all may have some of this (we are human). I hope that I
am fighting such tendencies within myself.

On Sun, 31 Aug 2008 18:36:33 -0500, Robert <no@e.mail> wrote:

>Structured programming was invented around 1970. We're waiting to see whether it catches
>on.

8^)

Often a paradigm is invented that works pretty good - but gets
implemented with some considerable variation. Various "sects" will
argue about the One True Way of implementing it.

In article <7biqb4999lq7nq1giqbdjptic9oklls1q9@4ax.com>,
Howard Brazee <howard@brazee.net> wrote:
>On Tue, 2 Sep 2008 01:19:04 +0000 (UTC), docdwarf@panix.com () wrote:
>
>>The point I see you trying to make, Mr Plinston, is that you've found a
>>Very Good Reason to develop a certain style. My question, quite simply,
>>is: do you believe that there exist other Very Good Reasons, equally as
>>valid as yours, which might result in code that shows a style other than
>>yours?
>
>Human nature unfortunately seems to have lots and lots of people who
>won't or can't think this way.

I start with small steps, Mr Brazee... I may, some day, work up to asking
this of Human Nature but for now I'd like to see what Mr Plinston has to
say.

DD

In article <j6iqb4d8cv43rans8hi7nt5hnuduqa6048@4ax.com>,
Howard Brazee <howard@brazee.net> wrote:
>On Mon, 1 Sep 2008 13:26:31 -0700 (PDT), Richard <riplin@azonic.co.nz>
>wrote:
>
>>> You might want to re-examine your own views of yourself, Mr Plinston. *You
>>> describe a matter of style as 'idiotic';
>>
>>I was replying to a statement that called a particular style
>>'idiotic', do try and stay in context.
>>
>>> idiot, according tohttp://www.merriam-webster.com/dictionary/idiot, is a term which is
>>> 'usually offensive'.
>
>
>Ahh, I'm not insulting the person - only his work (which I state isn't
>really *wrong*, just idiotic). I'm sure that makes a world of
>difference.

Ha!.... only to those unfamiliar with the works of Eward Hopper, Mr
Brazee; he is quoted as having said 'the man is the work'... and wasn't he
a Realist, as well? What greater authority might one hope to mis-use?

DD

On Tue, 2 Sep 2008 15:02:27 +0000 (UTC), docdwarf@panix.com () wrote:

>>Ahh, I'm not insulting the person - only his work (which I state isn't
>>really *wrong*, just idiotic). I'm sure that makes a world of
>>difference.
>
>Ha!.... only to those unfamiliar with the works of Eward Hopper, Mr
>Brazee; he is quoted as having said 'the man is the work'... and wasn't he
>a Realist, as well? What greater authority might one hope to mis-use?

A man in the middle of a(n art) world moving away from realism... He
can be mis-used as well as anybody, and better than most.

This isn't strictly a Cobol question which is why it's OT(?).

In Intel-style assembler, calls are implemented through the stack. In
IBM-style assembler, they are implemented by a BAL (branch-and-link)
instruction, and the first step in the called routine is to save the return
address which the BAL provides.

My questions:

- there must be a similar concept in Intel - access to the "current address"
that the program is executing at
- if so, it could be used to implement calls without using the stack
- if so, is there any reason why it shouldn't be used?

(Not trying to promote a revolution here. Just curious).

PL




Richard <riplin@azonic.co.nz> wrote in message
news:e815f30d-40b6-41f9-bffe->
> That isn't necessarily the case. Using a stack isn't the only way of doing
> this.

Which is why I said: "could".

However, he claimed to be using Microfocus, I understand that this
does use a perform stack. In fact there is even an error code 168 for
this. Whether this particular code would cause the stack to overflow
with a code 168 I don't know, but it is not the sort of code that I
would allow.

On Sep 2, 1:19*pm, docdw...@panix.com () wrote:
> In article <6c4db269-d581-42b0-a52a-750f41646...@t1g2000pra.googlegroups.com>,
>
>
>
> Richard *<rip...@azonic.co.nz> wrote:
> >On Sep 2, 2:58*am, docdw...@panix.com () wrote:
> >> In article <88af676a-5ab8-44cb-a9ac-b06fb0f76...@w1g2000prk.googlegroups.com>,
>
> >> Richard *<rip...@azonic.co.nz> wrote:
> >> >On Sep 1, 12:31*pm, docdw...@panix.com () wrote:
> >> >> In article
> >> ><92fcce4e-2525-4bc8-a4ef-aeff6ac7a...@n33g2000pri.googlegroups.com>,
>
> >> >> Richard *<rip...@azonic.co.nz> wrote:
>
> >> >> [snip]
>
> >> >> >My answer here is yes, If I were to change the code I might
> >> >> >want to start with a conditional, such as (in a theoretical general
> >> >> >case): "IF X1 < 100". Then I would indent the remaining code, BUT,I
> >> >> >would also have to examine all the code seeking out full stops.
>
> >> >> What's this... if you desire to change the depth of condition the current
> >> >> design of the code would force you to go through the rest of it, line by
> >> >> line, making sure your change did not introduce any unanticipated errors?
>
> >> >Well of course it is still checked, but in _my_ code I reduce the
> >> >amount that needs to be _changed_.
>
> >> What needs to be _changed_ (emphasis original), Mr Plinston... the
> >> indentation? *Proponents of free-form source code might question that as a
> >> matter of necessity.
>
> >Changing indentation is a trivial procedure consisting of merely
> >marking the range and a keystroke.
>
> Odd that you'd seem to feel a need to comment on what you call 'a trivial
> procedure', Mr Plinston...

Your porous memory has failed you, yet again. It was you that
commented on 'changing indentation', to which I responded.

> what do you hope to gain by pointing out
> trivialities?

What do you hope to gain by tediously asking inane questions ?

> >Ensuring that the indentation
> >matches the logic levels is more important and also more arduous,
> >unless this has already been catered for in the original code.
>
> Ensuring that indentation of any kind is of questionable necessity in
> free-form code, Mr Plinston, and what 'has already been coatere for in the
> original code' seems perilously close to Hopper's denigrated 'But we've
> *always* done it this way!'

It is nothing like that at all.

Interestingly, I have done very little 'always this way'.


> >> >And, for example, if the IF were later removed and the code
> >> >unindented, then presumably the 'dots everywhere' brigade would go
> >> >back and add them to each line.
>
> >> Mr Plinston, you cannot control what other 'would do', you can only
> >> control - to what extent is another matter - what you do yourself.
>
> >There was no mention of 'control', merely an observation of what some
> >may feel necessary.
>
> When 'some might feel necessary' to comment, Mr Plinston, they might
> choose to do so. *What might be of interest - or at least a Good, Hearty
> Laugh - is to post what *you* feel necessary and let the un-named 'some'
> speak for themselves.

I'll wait until the 'some might', and then discuss it with them.

> >> >"""If you don't know what you are doing then do it neatly."""
>
> >> Neatness is also a matter of style, Mr Plinston. *Would you say a
> >> ninety-degree angle is more neat than a sixty-degree one?
>
> >It my code lines were displayed at such angles to the vertical then I
> >may form an opinion on that.
>
> Neatness exists outside of code, Mr Plinston, as you pointed out in your
> assertion about it... which contained nary a mention of code. *Second
> request, then: would you say a ninety-degree angle is more neat than a
> sixty-degree one?

Neatness, or indeed most attributes, is also related to context.
Without context any opinion would be worthless.

>
> >> >Of course no code is ideal, some less so than others.
>
> >> That, I would say, depends on who establishes and who evaluates the
> >> criteria for what you are calling ideal. *I, personally, do not write code
> >> for ideals, I write code in order to make the person who signs my
> >> timesheets smile.
>
> >Your ideals may well be completely different from mine.

I have no particular interest in how long it takes you to maintain the
code that you are given to work with. I will judge, by my standards,
code that I am given.


> No matter what are ideals might be, Mr Plinston, if your assertion that
> 'no code is ideal' then neither yours nor mine is.

Some may be further away than others.


> >> >> Styles differ, Mr Plinston;
>
> >> >Which is why I usually specify what _I_ do, what _my_ code is like,
> >> >and the benefits that _I_ find, rather than attempting to persuade
> >> >others to do it in any particular way.
>
> >> You might want to re-examine your own views of yourself, Mr Plinston. *You
> >> describe a matter of style as 'idiotic';
>
> >I was replying to a statement that called a particular style
> >'idiotic', do try and stay in context.
>
> Another person making a statement jumps off the Brooklyn Bridge, Mr
> Plinston... so you must, as well? *

It is certainly possible that I would make a statement as well.

> Please try to stay grounded.
>
> [snip]
>
>
>
> >> >> I was taugh, e'er-so-long ago, that the
> >> >> intention of COBOL was to be English-like to the point where a period/full
> >> >> stop was to signal the end of a sentence, the completion of a thought, the
> >> >> full conveying of a particular set of instructions.
>
> >> >Yes, but even you have specified the plural 'instructions'.
>
> >> Even I!.
>
> >> >I ensure that, as far as possible, each of my paragraphs is, to me,
> >> >one 'set of instructions', one 'thought'.
>
> >> You see, Mr Plinston... it can be argued that this is a limitation of
> >> style. *A paragraph, by definition, contains 'one or more sentences'; by
> >> requiring yourself to keep to a subset of the definition ('one sentence
> >> only') you practise and advocate a subset of possibilities.
>
> >I also practice subsets of other possibilities. I see no need, for
> >example, to use every Cobol verb or sub-clause in each program, or
> >indeed, for some, to use them at all.
>
> It was never suggested that such would be a good thing, Mr Plinston... but
> please, don't let that fact deter you from making the argument. *Is it
> your honest opinion that there's an all-or-none approach to style and that
> differing views on the use of periods/full stops are to be equated with
> differing views on ALTER or RENAMES?
>
> >> Your reasons for doing this are your own, of course... but to call
> >> something other than the particular subset you've chosen 'idiotic' does
> >> not, to me, appear to be a reasoned or dispassioned evaluation.
>
> >You completely missing the point seems to be par for the course.
>
> The point I see you trying to make, Mr Plinston, is that you've found a
> Very Good Reason to develop a certain style. *My question, quite simply,
> is: do you believe that there exist other Very Good Reasons, equally as
> valid as yours, which might result in code that shows a style other than
> yours?

There may well be other Reasons. Whether they are Very Good may well
depend on the context. Certainly the context of a site where your pay
cheque depends on certain styles make that a Very Good Reason. But I
don't work in that context.


> >> >That _may_ be because they haven't seen my code.
>
> >> You write code that causes those-who-maintain to grouse or bellyache? *How
> >> brave of you to admit it!
>
> >Well of course they would complain, they would make far less money on
> >a per-hour basis, or even none at all.
>
> I'm not sure how you are using 'they would', Mr Plinston... if it
> indicates a subjunctive ('were they to maintain it they would') then you
> appear to be generating a situation which does not exist.

Your point being ?

On Sep 2, 2:58*am, docdw...@panix.com () wrote:

> >> I was taugh, e'er-so-long ago, that the
> >> intention of COBOL was to be English-like to the point where a period/full
> >> stop was to signal the end of a sentence, the completion of a thought,the
> >> full conveying of a particular set of instructions.

You are limiting the 'English-like' to only be prose. In prose the
punctuation is added to the words so that when the words are
vocalised, either internally or out loud, the pauses and inflections
which are used in speech may be added correctly. They ensure that
correct meaning is transferred.

Other forms of writings do not use punctuation in the same way. A
recipe may omit all punctuation in the ingredients, or even in the
instructions. The meaning of the words is indicated entirely by the
way they are listed on separate lines. No inflections or pauses are
required.

Poetry can be written without punctuation, or at least less than prose
would have. The words are organised into lines and stanzas and the
rhythm and inflections are added by conventions.

Other lists or instruction can similarly be unpunctuated, the
separation of 'ideas' or steps indicated by line feeds and grouped by
indentation.

Program code is not prose. It usually does not run on, filling the
lines and pages aligned left with just a space between each word and
after punctuation. It is not word wrapped or justified, or hyphenated,
though it can be (sort of).

If you did write your code in a manner like prose then it may be
necessary to use punctuation as a guide to the start and end of each
statement and clause.

However, as I was commenting on _POINTLESS_ full stops and useless
commas (they are ignored by the compiler and serve no purpose) then I
leave it to each to examine whether the ones that they use have a
point to them or not.


> >Yes, but even you have specified the plural 'instructions'.
>
> Even I!.
>
>
>
> >I ensure that, as far as possible, each of my paragraphs is, to me,
> >one 'set of instructions', one 'thought'.
>
> You see, Mr Plinston... it can be argued that this is a limitation of
> style. *

It is not a limitation unless it is difficult to fit into the
structure of the program.

For example if every pargraph _must_ be given a number and then the
code ordered by these so that they can easily be found in the pack of
cards, then yes, having shorter paragraphs that are based on one
'idea' or doing just one thing may seem to be a limitation.

It may also be that with PERFORM THRU or PERFORM SECTION it becomes
too hard to arrange the code usefully in smaller and more manageable
blocks.

However, the program organization that I use lends itself to easily
break down the code into reusable parts. If there is any 'limitation'
it is not mine, but that of the other program organization used.


> A paragraph, by definition, contains 'one or more sentences'; by
> requiring yourself to keep to a subset of the definition ('one sentence
> only') you practise and advocate a subset of possibilities.

It is what I practice, yes. Where did you see the 'advocate' ?


> Your reasons for doing this are your own, of course... but to call
> something other than the particular subset you've chosen 'idiotic' does
> not, to me, appear to be a reasoned or dispassioned evaluation.

>
>>> ... I think that
>>> scattering pointless full stops, and especially the useless commas,
>>> through the code as idiotic.
>

Admittedly without having read very single post in this thread, I have to pitch in
my two cents regarding punctuation. Personally I too believe that in most cases,
punctuation should be reserved for those places in the code where it is necessary.

Two cases come immediately to mind, both from lessons painfully learned as a
"maintainer", and both involve situations which required stripping extraneous
punctuation from code.

One situation is when (as has probably already been mentioned) straight line code is
modified to be sandwiched within conditionals, in cases where it would be confusing
or dangerous to relocate the entire chunk of code to some other paragraph.

E.G.:
PERFORM PARA-ONE.
PERFORM PARA-TWO.
PERFORM PARA-THREE.

becomes:
IF CONDITION
PERFORM PARA-ONE
PERFORM PARA-TWO
PERFORM PARA-THREE.

.... requires removing most of the totally unnecessary periods from each line.

But the one that really gets me steamed is those who insist on terminating each line
with a comma. When reading thru the code, a comma can easily appear to be a period,
and more than a few times I've been burned when a procedure appeared to be
terminated by a period that in fact (after much troubleshooting) turned out instead
to be a comma.

PERFORM PARA-ONE,
PERFORM PARA-TWO,
PERFORM PARA-THREE.

It seems obvious in this brief example above, but in a large program, when EVERY
line of code has a dot at the end, they all tend to look alike.