From ... From: Erik Naggum Subject: Re: Indentation Date: 1999/06/30 Message-ID: <3139728333138511@naggum.no> X-Deja-AN: 495559131 References: mail-copies-to: never Organization: Naggum Software; +47 8800 8879; http://www.naggum.no Newsgroups: comp.lang.lisp * Josef Eschgfaeller | 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 to collect n) instead of (number-list ), 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