comp.lang.lisp wrote:
>> The problem of indentation is interesting for me
> so you make it a problem for other people too?
No, I didn't mean it in this negative or aggressive way. This problem
belongs to the more general communication problem with mathematical
or technical writing. Often habits of the insiders there are not
obvious or easy for the general public. So I wanted to say that
indeed I am concerned with these aspects and if I write in a certain
way, I think about it, too.
A side-interest in this is also, to what extent behind such flames
are technical reasons, what is pure habit and how much is it the
immune system which becomes active (eliminate everything you don't
know)? It is strange, but perhaps related, that typically in such
discussion lists there are never girls. My classes consist mainly
of female students, and they are as good in programming as the males
and, as it seems, especially attracted by the linguistic aspects
of Lisp.
This doesn't mean that I cannot be wrong or that I should not
adapt my codes, when posted to the list, to the general use.
This is no problem. I did not want a long discussion, if the
question is not interesting or if everybody has a firm conviction.
> a program ... should also be readable by human beings, including
> ones who did not write it.
Agree fully. But one can learn different styles.
> What do you mean by `shapes'?
Something as the interior or logical shape. I meant approximately
that when you have ready such a shape, you can put in easily the
constructions in your program. In some sense indentation means that
you never make that effort and so you are compelled each time to
begin from new.
Often such crutches, when not more necessary, should be thrown away.
This happens very often in natural language learning. It's a general
consideration, maybe in the concrete case I'm wrong.
> However, what if there is a DO within a DO? Wouldn't it take
> time to disentangle one from the other?
Perhaps it could also be a reason to avoid or reorganize too
complicated structures.
> with properly indented code one could pay little attention to
> those parentheses
I'm looking now at some pieces of code in Graham's books. In fact,
I can see some structures immediately, but it appears to me that
the more I look at it, the more it resembles normal C code.
I lose the Lisp a little.
Mathematically it is the old problem of how to represent a tree
by a string. There are many ways, among them indentation, but I
don't know one perfectly corresponding to the human brain.
> Since there isn't a "shape" in filled lines, there's no pattern
> for people to see. They have to inspect and reconstruct the structure.
The danger is, as in natural language, that one does not more
read with attention what is written. People who are accustomed to
read much, usually can understand easily texts of considerable
complexity.
> BTW - What's the largest program you've ever understood or written
> that someone else has been able to easily understand? For some
> people who read comp.lang.lisp, the answer is hundreds of thousands
> of lines....
In fact, I'm impressed by the competence of the members of this
list. It's truly not the first one I participate. Lisp is a rich and
deep language and I have still much to learn.
Josef Eschgfaeller
Dipartimento Matematico
Universita' di Ferrara
···@felix.unife.it e-mail
http://felix.unife.it/ home page
On Tue, 29 Jun 1999 14:18:20 +0200, Josef Eschgfaeller <···@felix.unife.it>
wrote:
> A side-interest in this is also, to what extent behind such flames
> are technical reasons, what is pure habit and how much is it the
> immune system which becomes active (eliminate everything you don't
> know)? It is strange, but perhaps related, that typically in such
I seem to have read that the first Lisp books, published around the
sixties, used a style similar to yours for code samples--i.e. without
indentation. Maybe someone in this group can explain why this changed in
later decades.
One possible technical reason may be that, since Lisp uses a prefix syntax,
it's easier to identify operators by means of the characteristic patterns
that proper indentation makes apparent. Those operators are quick clues to
the main constructs such as function calls, definitions, binding forms,
etc. But when the code is laid out as a mostly continuous stream of text,
such clues may appear anywhere and it's harder to locate them.
The technical importance of indentation is also suggested by the inclusion
of extensive pretty-printing facilities in ANSI Common Lisp. The ANSI
standardization effort was probably driven more by pragmatic concerns than
ideological issues.
> discussion lists there are never girls. My classes consist mainly
> of female students, and they are as good in programming as the males
> and, as it seems, especially attracted by the linguistic aspects
> of Lisp.
Do you mean that your classes in Ferrara are attended by lots of girls who
appreciate Lisp? If so, sign me for your next class :)
> > However, what if there is a DO within a DO? Wouldn't it take
> > time to disentangle one from the other?
>
> Perhaps it could also be a reason to avoid or reorganize too
> complicated structures.
Most Lisp editors, the best known of which is Emacs (in Lisp--not
Fundamental--mode), are able to automatically indent this and other complex
constructs with a single keystroke.
> In fact, I'm impressed by the competence of the members of this
> list. It's truly not the first one I participate. Lisp is a rich and
> deep language and I have still much to learn.
Have you had a look at the wonderful paper "The Evolution of Lisp" by
Richard Gabriel and Guy Steele? It's available at:
ftp://ftp.cs.umbc.edu/pub/Memoization/Misc/Evolution-of-Lisp.ps.Z
Section 5 (Why Lisp is Diverse) lists a number of reasons why there's
something special or different about Lisp. One of the reasons is its
people.
Paolo
--
Paolo Amoroso <·······@mclink.it>
In article <················@news.mclink.it>,
Paolo Amoroso <·······@mclink.it> wrote:
>I seem to have read that the first Lisp books, published around the
>sixties, used a style similar to yours for code samples--i.e. without
>indentation. Maybe someone in this group can explain why this changed in
>later decades.
Because we learned from experience that non-indented code was hard to
understand.
--
Barry Margolin, ······@bbnplanet.com
GTE Internetworking, Powered by BBN, Burlington, MA
*** DON'T SEND TECHNICAL QUESTIONS DIRECTLY TO ME, post them to newsgroups.
Please DON'T copy followups to me -- I'll assume it wasn't posted to the group.
Josef Eschgfaeller <···@felix.unife.it> writes:
> comp.lang.lisp wrote:
>
> >> The problem of indentation is interesting for me
> > so you make it a problem for other people too?
>
> No, I didn't mean it in this negative or aggressive way. This problem
> belongs to the more general communication problem with mathematical
> or technical writing. Often habits of the insiders there are not
> obvious or easy for the general public. So I wanted to say that
> indeed I am concerned with these aspects and if I write in a certain
> way, I think about it, too.
I think that one of the non-obvious insider habits in this case is
the means by which we obtain the indentations we use. In all of your
posts, you give the impression to me that it is a chore to indent
lisp code, a hard exercise to be avoided. However, if you use
emacs/xemacs, vi (in lisp mode), internal lisp editors, or any
other editor that is lisp-indentation-friendly, the indentation
is usually automatic and almost unavoidable. And although all
of those choices give you slightly different indentations, all are
readable by those of us reading this newsgroup.
> This doesn't mean that I cannot be wrong or that I should not
> adapt my codes, when posted to the list, to the general use.
> This is no problem. I did not want a long discussion, if the
> question is not interesting or if everybody has a firm conviction.
It's not an issue of conviction; it's a question of communication.
If the sender of a message wants to communicate with a potential
receiver of the message, the sender must format it in a way that
can be understood by the receiver. And the quality of the
communication depends on the universality of the method of
communication. What you have been told by many on this list is that
the method you used to communicate your point was not easy to
receive. Thus, if you want more people to understand it, it must be
in a form that will more easily be received.
Incidentally, writing programs is also a form of communication in
several ways; when I write a program I am communicating to three
classes of receivers:
1. The computer.
2. Other programmers, who don't necessarily know my design.
3. Myself, six months after I wrote the program.
By far, the most challenging receiver to communicate with is #3.
> > a program ... should also be readable by human beings, including
> > ones who did not write it.
>
> Agree fully. But one can learn different styles.
There are any number of programs wich are lisp-friendly and which make
lisp programming very easy. And just as C has different styles (like
whether to put the opening-curly-brace in "if (x) { ..." immediately
after the test clause or on the next line), these editors usually
accomodate different lisp indentation styles. I don't think we would
object to different styles too much; what we objected to in the case
of the code you submitted was (pardon my being so blunt) no style at
all.
> > What do you mean by `shapes'?
>
> Something as the interior or logical shape. I meant approximately
> that when you have ready such a shape, you can put in easily the
> constructions in your program. In some sense indentation means that
> you never make that effort and so you are compelled each time to
> begin from new.
>
> Often such crutches, when not more necessary, should be thrown away.
> This happens very often in natural language learning. It's a general
> consideration, maybe in the concrete case I'm wrong.
A crutch is a device to aid a weak member of a system. Communication
is almost always the weakest member of any programming system.
Use crutches for communication as often as possible.
> > However, what if there is a DO within a DO? Wouldn't it take
> > time to disentangle one from the other?
>
> Perhaps it could also be a reason to avoid or reorganize too
> complicated structures.
You are welcome to keep your code as simple as you can make it
when you communicate it with us. However, how will you
communicate that code which you just can't simplify any more?
> > with properly indented code one could pay little attention to
> > those parentheses
>
> I'm looking now at some pieces of code in Graham's books. In fact,
> I can see some structures immediately, but it appears to me that
> the more I look at it, the more it resembles normal C code.
> I lose the Lisp a little.
Ahem, lisp is the older language here. Therefore, it is lisp
similarity that you see when you look at C code, not the other
way around.
:-)
> Mathematically it is the old problem of how to represent a tree
> by a string. There are many ways, among them indentation, but I
> don't know one perfectly corresponding to the human brain.
That's why it is so important to keep all of the "crutches" as
is possible in order to more closely match how the receiver of
your communication will be thinking.
--
Duane Rettig Franz Inc. http://www.franz.com/ (www)
1995 University Ave Suite 275 Berkeley, CA 94704
Phone: (510) 548-3600; FAX: (510) 548-8253 ·····@Franz.COM (internet)
Duane Rettig <·····@franz.com> writes:
> Incidentally, writing programs is also a form of communication in
> several ways; when I write a program I am communicating to three
> classes of receivers:
> 1. The computer.
> 2. Other programmers, who don't necessarily know my design.
> 3. Myself, six months after I wrote the program.
>
> By far, the most challenging receiver to communicate with is #3.
>
I gave up on #3 many years ago :)
Cheers
--
Marco Antoniotti ===========================================
PARADES, Via San Pantaleo 66, I-00186 Rome, ITALY
tel. +39 - 06 68 10 03 17, fax. +39 - 06 68 80 79 26
http://www.parades.rm.cnr.it/~marcoxa
In article <········································@arbzi.zuhause.fe>,
Josef Eschgfaeller <···@felix.unife.it> wrote:
> > a program ... should also be readable by human beings, including
> > ones who did not write it.
>
> Agree fully. But one can learn different styles.
People who share a convention can communicate more easily. What
advantages of your convention make it worth the communities'
effort to learn it? Why should a newcomer learn your style?
(It really doesn't matter which side of the road people drive
on, but it's "efficient" for them to agree.)
> > What do you mean by `shapes'?
>
> Something as the interior or logical shape. I meant approximately
> that when you have ready such a shape, you can put in easily the
> constructions in your program. In some sense indentation means that
> you never make that effort and so you are compelled each time to
> begin from new.
Huh? The shape formed by indentation tells me lots of things,
so I never "begin from new".
We haven't seen any examples of something valuable revealed by
the "like text" style of program formatting. All we've seen is
program structure obscured by that style.
> Perhaps it could also be a reason to avoid or reorganize too
> complicated structures.
"too complicated" is problem-specific. If a formatting scheme
can't clearly express the "best" way to solve the problem at
hand, the formatting scheme is an obstacle.
> > with properly indented code one could pay little attention to
> > those parentheses
>
> I'm looking now at some pieces of code in Graham's books. In fact,
> I can see some structures immediately, but it appears to me that
> the more I look at it, the more it resembles normal C code.
Since both languages have composition and sequencing, some structural
similarities are to be expected.
> The danger is, as in natural language, that one does not more
> read with attention what is written. People who are accustomed to
> read much, usually can understand easily texts of considerable
> complexity.
Text which is intentionally deceptive is always hard to understand.
However, programmers often make an effort to be easy to understand.
Most program text is read far more times than it is written, so helping
the reader is "efficient". (One nice thing about indentation is that
indenting programs can reveal many deceptions, hence the suggestion
about letting emacs reformat something as a quick check to see of
one's understanding.) Indentation is efficient for the things it
reveals, leaving more time for the "rest of the problem".
> > BTW - What's the largest program you've ever understood or written
> > that someone else has been able to easily understand? For some
> > people who read comp.lang.lisp, the answer is hundreds of thousands
> > of lines....
>
> In fact, I'm impressed by the competence of the members of this
> list.
I was obscure. Yes, some of the folks participating are incredibly
competent and thoughtful. However, my point is that some things
which "work" with small programs don't work with large ones, and
the distinction isn't necessarily obvious unless you have the
relevant experience.
You learn a lot by writing a 10k line program, and even more by
coming back to it 10 years later to make minor changes. Cranking
out lots of code that must be correct in a short amount of time
is also a learning experience. You won't expect these lessons
if you just do 1k one-timers. (The difference between 10k and
100k is also interesting.)
-andy
Sent via Deja.com http://www.deja.com/
Share what you know. Learn what you don't.
On 1999-06-29 14:18 +0200,
Josef Eschgfaeller wrote:
[...]
> > What do you mean by `shapes'?
>
> Something as the interior or logical shape. I meant approximately
> that when you have ready such a shape, you can put in easily the
> constructions in your program. In some sense indentation means that
> you never make that effort and so you are compelled each time to
> begin from new.
Could it be you mean that indented code could not be copied and
pasted from one program to another?? (I am still trying to grasp
the meaning of `shape' in this context. Would the word `form' (as in
`a form to be filled-in') be more appropriate than `shape'?)
[...]
> > However, what if there is a DO within a DO? Wouldn't it take
> > time to disentangle one from the other?
>
> Perhaps it could also be a reason to avoid or reorganize too
> complicated structures.
Sometimes this means to avoid too complicated problems. I agree
this makes life easier...
[...]
> Lisp is a rich and
> deep language and I have still much to learn.
By the way, it does indeed take some extra effort to learn Lisp
mode (of Emacs, for one who is just using fundamental mode),
but this effort pays off very handsomely (writing Lisp programs,
of course, not writing letters).
Good luck,
Vassil.
Vassil Nikolov
Permanent forwarding e-mail: ········@poboxes.com
For more: http://www.poboxes.com/vnikolov
Abaci lignei --- programmatici ferrei.
* Josef Eschgfaeller wrote:
>> However, what if there is a DO within a DO? Wouldn't it take
>> time to disentangle one from the other?
> Perhaps it could also be a reason to avoid or reorganize too
> complicated structures.
I think this must be commented on. Two nested loops (DO or other) are
an extremely common idiom when processing 2d arrays. You can't in all
seriousness suggest that one should avoid or reorganise structures
this complex: if a programming style is making this hard to read then
it has serious problems.
--tim