Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.compilers > #1007
| From | wclodius@earthlink.net (William Clodius) |
|---|---|
| Newsgroups | comp.compilers |
| Subject | Re: Programming language and IDE design |
| Date | 2013-10-22 19:56 -0600 |
| Organization | Compilers Central |
| Message-ID | <13-10-024@comp.compilers> (permalink) |
| References | <13-10-016@comp.compilers> <13-10-022@comp.compilers> |
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.
Back to comp.compilers | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread
Programming language and IDE design Martin Ward <martin@gkc.org.uk> - 2013-10-17 11:06 +0100
Re: Programming language and IDE design "BartC" <bc@freeuk.com> - 2013-10-19 22:05 +0100
Re: Programming language and IDE design Martin Ward <martin@gkc.org.uk> - 2013-11-07 19:40 +0000
Re: Programming language and IDE design glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2013-11-08 05:21 +0000
Re: Programming language and IDE design Hans-Peter Diettrich <DrDiettrich1@aol.com> - 2013-11-08 06:45 +0100
Re: Programming language and IDE design George Neuner <gneuner2@comcast.net> - 2013-11-08 16:04 -0500
Re: Programming language and IDE design "Jonathan Thornburg" <jthorn@astro.indiana.edu> - 2013-11-10 04:41 +0000
Re: Programming language and IDE design Hans-Peter Diettrich <DrDiettrich1@aol.com> - 2013-10-20 03:22 +0200
Re: Programming language and IDE design Gene Wirchenko <genew@telus.net> - 2013-10-20 14:03 -0700
Re: Programming language and IDE design Gene Wirchenko <genew@telus.net> - 2013-10-21 14:44 -0700
Re: Programming language and IDE design George Neuner <gneuner2@comcast.net> - 2013-10-22 16:17 -0400
Re: Programming language and IDE design Hans-Peter Diettrich <DrDiettrich1@aol.com> - 2013-10-23 03:40 +0200
Re: Programming language and IDE design wclodius@earthlink.net (William Clodius) - 2013-10-22 19:56 -0600
Re: Programming language and IDE design "BartC" <bc@freeuk.com> - 2013-10-23 19:09 +0100
Re: Comments, was Programming language and IDE design "BartC" <bc@freeuk.com> - 2014-08-01 13:15 -0400
Re: Programming language and IDE design Stefan Monnier <monnier@iro.umontreal.ca> - 2013-10-24 10:55 -0400
Re: Programming language and IDE design George Neuner <gneuner2@comcast.net> - 2013-10-24 19:57 -0400
csiph-web