From: Clark F Morris on
On Tue, 08 Jun 2010 11:54:12 -0400, Michael Wojcik
<mwojcik(a)newsguy.com> wrote:

>> much snipped
>
>Frens does make a couple of good points: few people are claiming that
>functional approaches are going to "take over", and functional
>features get added to imperative languages because a significant
>number of developers want them. Sometimes, that is; few people want to
>do everything in functional style. Ideally, programmers should use an
>approach that leads to an elegant, robust solution for the problem at
>hand.
>
>
>[1] I've done some significant research into source code readability,
>particularly the history of attempts to make source code more readable
>for maintainers (see previous posts about my 2009 ATTW presentation),
>and I strongly suspect that most arguments about programming-language
>readability are vapid. Few people bother to look at any empirical
>research or even present sensible hypotheses; few even bother to try
>to construct arguments on the topic - they just state their
>prejudices. And programming language readability is a small part of
>source code readability.
>
>[2] If this isn't a clear sign that an author doesn't have a real
>argument, I don't know what is. Phenomenologist, examine thyself -
>don't tell me how *I* think.

One of the things that made IBM Assembler and FORTRAN relatively
unreadable for me was the 8 and 6 character restrictions on names.
Note that both limitations reflect what was true in 1966 when I first
encountered them, NOT what is true today (ore even 20 - 30 years ago).
With decent sized names (at least 15 character and preferably 30)
things become much better. Languages that minimize the name space
needed to accomplish a task may be more readable. The compute
statement may be more readable than the individual arithmetic
statements that make it up because the intermediate variables are
hidden rather than explicitly named. If a language uses terms and
constructs that are natural to the field for which it is being used it
is probably more readable for the purpose. One can produce unreadable
code in any language. It is just that some like the much maligned JCL
(Job Control Language) on IBMs MVS and successors make it easier to do
so.

Clark Morris
From: Howard Brazee on
On Wed, 09 Jun 2010 12:54:47 -0300, Clark F Morris
<cfmpublic(a)ns.sympatico.ca> wrote:

>One of the things that made IBM Assembler and FORTRAN relatively
>unreadable for me was the 8 and 6 character restrictions on names.
>Note that both limitations reflect what was true in 1966 when I first
>encountered them, NOT what is true today (ore even 20 - 30 years ago).
>With decent sized names (at least 15 character and preferably 30)
>things become much better. Languages that minimize the name space
>needed to accomplish a task may be more readable.

Even with modern database based systems, I have troubles figuring out
the rules used for syntax of various fields. Even long names are
filled with abbreviations, prefixes and suffixes. I pulled out a
nice graphic of various data warehouse stars and see long names all
with the same two prefixes followed by abbreviated English words. I
suppose someday it will be intuitive and obvious.

Or else, it is like CoBOL that abbreviates "number" as NUM and NBR.

--
"In no part of the constitution is more wisdom to be found,
than in the clause which confides the question of war or peace
to the legislature, and not to the executive department."

- James Madison
From: Doug Miller on
In article <vjdv069j2sjvtmfqun4hblb83r8j9geqpt(a)4ax.com>, cfmpublic(a)ns.sympatico.ca wrote:

>One of the things that made IBM Assembler and FORTRAN relatively
>unreadable for me was the 8 and 6 character restrictions on names.

In my experience, the unreadability results not from the 8-character
limitation but rather from unimaginative programmers. My first job in IT was
in an assembler shop, where one of the other programmers had a penchant for
using statement labels like these -- and found in this order in the program,
too:
A00001
B00001
A0000001
C000001
A0001
B000001
A000001
Her code was, of course, full of unconditional branches. Try to find the
target of this branch in a listing forty pages long, when *all* of the
statement labels look like the above, and are in no discernable logical
sequence.
BR A0000001

From: Binyamin Dissen on
On Wed, 09 Jun 2010 22:56:41 GMT spambait(a)milmac.com (Doug Miller) wrote:

:>In article <vjdv069j2sjvtmfqun4hblb83r8j9geqpt(a)4ax.com>, cfmpublic(a)ns.sympatico.ca wrote:

:>>One of the things that made IBM Assembler and FORTRAN relatively
:>>unreadable for me was the 8 and 6 character restrictions on names.

:>In my experience, the unreadability results not from the 8-character
:>limitation but rather from unimaginative programmers. My first job in IT was
:>in an assembler shop, where one of the other programmers had a penchant for
:>using statement labels like these -- and found in this order in the program,
:>too:
:>A00001
:>B00001
:>A0000001
:>C000001
:>A0001
:>B000001
:>A000001
:>Her code was, of course, full of unconditional branches. Try to find the
:>target of this branch in a listing forty pages long, when *all* of the
:>statement labels look like the above, and are in no discernable logical
:>sequence.
:> BR A0000001

No problem at all with a listing - the code will have the offset.

Of course the statement above is more difficult as you may not know what is
loaded into register A0000001.

--
Binyamin Dissen <bdissen(a)dissensoftware.com>
http://www.dissensoftware.com

Director, Dissen Software, Bar & Grill - Israel


Should you use the mailblocks package and expect a response from me,
you should preauthorize the dissensoftware.com domain.

I very rarely bother responding to challenge/response systems,
especially those from irresponsible companies.
From: Anonymous on
In article <hup67i$sn6$2(a)news.eternal-september.org>,
Doug Miller <spambait(a)milmac.com> wrote:
>In article <vjdv069j2sjvtmfqun4hblb83r8j9geqpt(a)4ax.com>,
>cfmpublic(a)ns.sympatico.ca wrote:
>
>>One of the things that made IBM Assembler and FORTRAN relatively
>>unreadable for me was the 8 and 6 character restrictions on names.
>
>In my experience, the unreadability results not from the 8-character
>limitation but rather from unimaginative programmers. My first job in IT was
>in an assembler shop, where one of the other programmers had a penchant for
>using statement labels like these -- and found in this order in the program,
>too:
>A00001
>B00001
>A0000001
>C000001
>A0001
>B000001
>A000001
>Her code was, of course, full of unconditional branches.

And yet... her code was allowed into Prod while code I have written has
been returned from Review with comments like 'SEARCH verb not permitted'.

In the words of my Sainted Paternal Grandfather - may he sleep with the
angels! - 'Anyone who told you 'Life is Fair'... lied.'

DD