Re: Programming language and IDE design

George Neuner <gneuner2@comcast.net> wrote:


> On Thu, 17 Oct 2013 11:06:26 +0100, Martin Ward <martin@gkc.org.uk>
> wrote:
> <snip>
> >(3) Indentation helps the reader if it is consistent: so should also
> >be enforced by the compiler. In line with point (2), nesting should
> >be defined by *both* indentation *and* grouping keywords:
> >with the compiler enforcing consistency between the representations.
> >This means that the reader can rely on either indication of nesting,
> >since both are reliable.
>


I have strong disagreements about what followed. I strongly suspect that
it is based on no significant experience with significant indentation.


> Under NO circumstances should a compiler be enforcing coding styles.


There are good reasons whay Python has become popular in education and
the sciences. In practice novices have problems developing a consistent
coding style unless there are significant consequences from not having a
consistent coding style. Among workers whose primary task is not
programing it can be very difficult to get a mutually consistent
programming style unless their mutual inconsistencies, where it affects
legibility, have significant consequences. In principle these
consedquences can flow from the boss/teacher or from their
collaborators, but doing so uses up a lot of time and energy that are
far better used elsewhere. Putting this enforcement in the
compiler/interpretter/editor gets a ton of stylisstic decisions out of
the way so that far more important issues can have priority.


> Significant indentation is the dumbest idea since paper tape.
>
> Ergonomics dictates that the screen dimensions, fonts and indentation
> units that I choose for my viewing comfort should have absolutely no
> effect on your choices.


Strictly speaking Python restricts none of your choices the screen
dimensions, fonts or indentation units. Normally indentation
significant languages such as Python, Occam, and Haskell in the
appropriate mode, do not have specific indentation units, they only
enforce an increase of indentation for each level of nesting per
sytactic construct, and indentation consistency for the current
syntactic level. However Python's community has developed a style
guide of recommended practices, that is very pragmatic in its
recommendations, readilly enforced by tools such as editors or IDEs,
widely followed in the community, and enforced for the main public
distributions as the leadership of the individual development efforts
have come to believe that a consistency of style is a good idea.


The limited ergonomic studies that have been done suggest that humans
are both flexible and consistent in their ergonomic preferences. They
have trouble consistently recognizing indentation if it is only one
character and can miss the start of lines if it is over eight
characters, but can handle indentation of two to six characters with
with only minor differences in performance. In latin alphabets, as the
line length beyond the indentation starts exceeding fifty to sixty
characters reading performance degrades. As the number of nesting
levels gets above four the ability to keep track of detailed logic
degrades (I suspect related to the nominal limit of seven items a
human can keep track of.) The ideal Python style: four spaces of
indentation per syntactic level, a strong preference for no more than
eighty characters per line but exceptions allowed to keep statements
or strings to a single line, etc are consistent with what is by and
large universally applicable style guidelines.


Your choice of scrren dimensions, fonts, indentation units etc will
interact with other aspects of ergonomics that you do not list: line
length, identtifier size, nesting level, comment structure etc. It is
common, for example, for programmers that indulge in large numbers of
nesting levels to want to compensate by making the indentation units
small. Similarly long line lengths make it easier to write long
statements without factoring out and naming the components in a way
that clarifies the logic.


> Indentation does aid human readers and should be applied consistently
> ... by means of a structural editor. Given a properly designed
> language in which control constructs expect a demarcated list of
> statements, then matching scopes will have matching indentation and
> structural mistakes in the code will be apparent due to statement
> misalignments


While this addresses some sources of errors, I tend to believe it is the
more superficial one.


> Python got many things right, but the whole idea of significant
> indentation in a modern language is a non-starter. I understand why
> Guido thought it might be a good idea, but he really should have left
> it alone.


If it were a non-starter Python wouldn't be one of the most popular
languages in use today. Guido got the idea from years of experience with
ABC, a teaching language he had years of experience with as one of its
developers.

Return to the comp.compilers page.
Search the comp.compilers archives again.