if does not evaluate

[Jacek Generowicz]

moughanj at tcd.ie (James Moughan) writes:

> Jacek Generowicz <jacek.generowicz at cern.ch> wrote in message news:<tyfwu2fbmc6.fsf at pcepsft001.cern.ch>...
> > moughanj at tcd.ie (James Moughan) trolls:

> I have no doubt that Lisp can be extremely practical as a language. 

Lisp (Common Lisp) is _first and foremost_ an extremely practical
language. It is the product of a couple of decades of smart people
working on a language for solving difficult programming problems in
industry, not in academia.

> I'm expressing a slightly humorous characterization of the attitude of
> parts of the Lisp community, especially in academia.

While there is (used to be) quite a number of Lisp courses around
which should be considered crimes against Lisp and humanity itself
<0.3 wink> (I had the misforture of first encountering Lisp through
one of these myself), that is no good reason to contribute yourself to
perpetuating the myths that such courses help to establish.

> > Maybe Lisp (and therefore Lisp books) are designed for intelligent
> > people who want to solve hard problems, and it is assumed that
> > intelligent people can look up trivia like how to open files in the
> > language standard (); maybe books are considered necessary to teach
> > you the difficult things which you cannot read between the lines of
> > the standard.

[...]

> Strange, I've always worked the other way around.  For the extremely
> simple, basic things it seems like *slight* overkill to refer to the
> ansi standard.

What's the point of writing a book telling you how to open files in
CL? This is described in the CLHS, which is available on-line:

    http://www.lisp.org/HyperSpec/FrontMatter/index.html

> For complex issues I'd rather have a formal language document that
> tells me exactly what's going on, rather than someone blathering for
> 50 pages.

While the CLHS tells you formally how macros work, it tells you
nothing of the philosophy of using them, it tells you nothing about
best practice, it tells you nothing about the pitfalls, and so on.

Do you really think that you would prefer to try to get an
understanding of what macros are, and how you should use them from 
the CLHS (http://www.lisp.org/HyperSpec/FrontMatter/index.html) than
from _On Lisp_ (http://paulgraham.com/paulgraham/onlisp.html) ?

I somehow doubt it.

> In this case, I merely found it particularly striking that a subject
> like file i/o, which would be considered basic and important in most
> languages, seemed to be in many Lispers' 'blind spot'.

Because it's just not interesting. There are so many interesting
things to say and to explain about Lisp. In a language like Java,
opening files is just about as difficult a concept as the programmer
is likely encounter <0.1 wink>, so Java books describe how to do
it. Lisp is by smart people, for smart people who want to solve
difficult problems. Opening files is so trivial that it's just not
worth wasting ink on it.

> Lisp is, without doubt, the most interesting language around in terms
> of pure theory.  The corollary to that, I guess, is that it attracts a
> lot of pure theorists.

Common Lisp attracts a lot of people who want to solve difficult
programming problems. Please notice this fact.

> Not really, no.  People think about programs tree-style where certain
> control structures occur, and virtually all languages nest at those
> points.  However, not in cases like assignment and mathematical
> expressions, where Lisp would still tend to mandate it.  That sort of
> deeply nested code is often the most unreadable.

This is your opinion from the perspective of never seriously having
tried to think about programs as trees. We're back to my original
point: don't confuse your opinion formed fromed with lack of
experience and imagination with some universal truth.

> Also Lisp usually nests somewhat uncomfortably, e.g. in an if
> statement
> 
> (if (< i 0)
>     (* -1 i)
>     i)
> 
> There's simply no context there for the eye to pick up on.

Of course there is. Indentation. (Shouldn't be too hard a concept for
a c.l.py reader to grasp). Of course, in a trivial example like this,
the indentation level is the same because each of the three
constituent parts fits on one line. Try this:

(if (this that
	  the other)
    (foo bar
	 (fubar baz))
    (fred bob
	  (bill ben)))

(Yes, there is a lot more to be said about this, but I don't propose
to do this on c.l.PY)

> Nest all of that a couple of layers deeper and it's going to become
> annoying.

Nope, you look at the indentation, just like in Python. Unlike in
Python, my editor is capable of swapping an arbitrarily large
consequent with an abitrarily large bloop, with a single
keystroke. When you catch on to these possibilities, the prodictivity
gaing is huge.

> I am not trolling about Lisp, btw.  I'm expressing my experiences of
> playing around with Lisp as a new language.  My intention was more in
> the line of amusement.

Unfortunately it's a form of amusement _too often_ chosen by ignorant
people ... which is a pity, because in doing so they help to
perpetuate the myth that what is actually the world's most advanced
and practical programming language, is some sort of joke ... thereby
helping to keep IT in the dark ages. <0.2 wink>

IOW, it's not funny. Pick something else to amuse yourself (like
actually learning Lisp, for example :-)

> And, frankly, if you think that a mildly sarcastic comment about some
> of the learning materials for Lisp, along a bold statement that Lisp
> doesn't  have the world's most intuitive syntax is a viscous, trollish
> slur on the language, justifying random personal attacks, then you
> really need to get a freaking life.

Too many ignoramuses making too many of these cheap shots ... yes it
winds me up.

> Lisp pretty much forces you into one way of doing things.

Please get a clue before posting such unfounded misinformation. Common
Lisp natuarally allows you to program in more different styles that
any other language I have come across.

> That's a shortcoming, not a feature. 

It would be, if it were true.

> But different problems may - shock - be better expressed through
> different languages, and diferent syntaxes.

Yes, and Common Lisp - shock - allows you to use any syntax you
want. And - shock - even though you can arrange for Lisp to understand
_any_ syntax, people usually decide to base their domain-specific
syntaxes on s-expressions, because an s-expression based one usually
turns out to be the best for the job.

Pertinent piece of history: s-expressions were originally not meant
for human consumption, something called m-expressions, which were to
be the sort of thing that you (and others) claim is the "natural" way
of expressing programs, was planned. Shock: the m-expressions never
caught on because the s-expressions turned out to be such a wonderful
way of writing programs. The programmers didn't want to let go of
their lovely, natural s-expressions.