Subject: Re: Indentation
From: Erik Naggum <erik@naggum.no>
Date: 1999/06/30
Newsgroups: comp.lang.lisp
Message-ID: <3139728333138511@naggum.no>

* Josef Eschgfaeller <esg@felix.unife.it>
| The problem of indentation is interesting for me, because most
| programmers stick to it as if it were an axiom.

  from here, it seems you stick to your non-indentation line with something
  other than willingness to listen to good advice.  I'm not sure that's an
  impression you want to give.

| I had a similar discussion several years ago about C, and I was not able
| to convince anybody.

  well, that often happens when one is mistaken.

| (1) Writing a program should be similar as far as possbile to writing a
| letter.

  of all the things it could be similar to, why a _letter_?

| Also in letters some structure is useful, but it should be esthetic and
| functional, not ritual.  This applies also to C and most other languages.

  funny you say that, since "aesthetic and functional" is what indentation
  is all about.  it seems, however, that _you_ think it is a ritual, and
  that sends some fairly strong signals that you're doing something wrong.
  indeed, it seems you format your code as a ritual _today_.

| (2) More specifically in Lisp I try to memorize (and to teach to
| memorize) the shapes which can appear.

  you _teach_ Lisp, too?  those of us who think that Lisp's image among
  young programmers suffers from bad teachers just got a very unwelcome
  confirmation of our worst fears.  really, you're doing your students a
  huge disservice by teaching a view that you admit is really unique.  I'm
  profoundly sorry to see that people who cannot otherwise convince others
  choose to teach those who are unlikely to object to abject silliness.

| For example: "A do has the following structure ... Therefore, when you
| see a do, look first at the assignments, then at the break-condition and
| the result, then at the single instructions."  And so on. In my opinion
| this is a good training, and after little time one has no more need to
| study the indentations, which also takes time and distracts.

  this sounds like a struggling beginner's view, a beginner who struggles
  because he's doing something wrong and don't want to change his ways.

| Of course, when I write on the computer (I'm using Emacs, but always only
| in fundamental mode), I verify the balance of parentheses with the editor.

  "always in fundamental mode"?  there should be a law against that.

| But I find it useful to write simple functions first by hand and to
| control by myself the parentheses.  I don't find it difficult.  With this
| training the )))))))))))))))-boing disappears quickly.

  I use M-( and M-) and move and manipulate complete forms when possible.
  that is, I don't have unbalanced parens to begin with.

| It was on this list (or perhaps in a paper of Kent Pitman) where I read
| some days ago that in computer science sometimes first habits become
| sanctified.

  yes, this often happens to people who don't engage in introspection.

| In part this may be true also for indentation.

  I'm baffled that you don't see the same argument in your non-indentation.

| Perhaps, but this is a personal argument, it is also a question of eyes.
| For me it takes more time to control the indentation (with more rows to
| read) than to examine the structure.

  and this is _why_ first habits become sanctified: it takes some effort to
  change your ways, and lazy people who don't engage in introspection and
  so constantly look for better ways to do what they do, don't ever expend
  that effort.  so, right now, your non-indentation is the easiest for you,
  simply because you have never indented your code, never learned to use
  the power of Emacs and its programmer-friendly modes, and have not seen
  any reason to change your ways despite not being able to convince anyone
  that your ways are superior.

  I'm frankly amazed that you think _others_ are stubborn.

  here's my suggestion: use PPRINT on your forms to see how Common Lisp is
  most commonly formatted.  learn to appreciate what people have done
  before you and try to understand why they have done it that way, instead
  of believing everybody else is doing silly things out of "ritual" and in
  terms of "convictions" and yours is the only reasonable way to do things.

  e.g.,

(pprint '
(defun num-list (a b &optional (d 1))
(do ((x a (+ x d)) (li nil))
((> x b) (nreverse li)) (push x li))))

  produces, with *PRINT-RIGHT-MARGIN* at 40 and *PRINT-CASE* to :DOWNCASE:

(defun num-list (a b &optional (d 1))
  (do ((x a (+ x d)) (li nil))
      ((> x b) (nreverse li))
    (push x li)))

  with *PRINT-RIGHT-MARGIN* set to 72 (the default, sort of), we get

(defun num-list (a b &optional (d 1))
  (do ((x a (+ x d)) (li nil)) ((> x b) (nreverse li))  (push x li)))

  which may not look great, but this is because (1) normal programmers
  don't use one-letter names of variables unless they are temporary
  variables with no particular meaning, anyway, so if a normal Lisp
  programmer would have written this, it'd look more like this, apart from
  the non-obvious utility of the function and the attendant difficulty of
  finding a good name for it:

(defun number-list (from to &optional (step 1))
  (do ((element from (+ element step)) (list nil))
      ((> element to) (nreverse list))
    (push element list)))

  I would expect a seasoned Lisp programmer not to write this as a function
  at all, but rather just write (loop for n from <from> to <to> collect n)
  instead of (number-list <from> <to>), since there is nothing to be gained
  by writing functions that don't do anything to either help read the code
  or partition abstraction.  after all, we expect some of the code in even
  the highest-level source code to use some normal Common Lisp forms; we
  don't write macros and special functions for _everything_.
  
#:Erik
-- 
@1999-07-22T00:37:33Z -- pi billion seconds since the turn of the century