if does not evaluate

[James Moughan]

Jacek Generowicz <jacek.generowicz at cern.ch> wrote in message news:<tyfwu2fbmc6.fsf at pcepsft001.cern.ch>...
> moughanj at tcd.ie (James Moughan) trolls:
> 
> > Lisp, I think, has two problems.  
> > 
> > Firstly an attitude among the community that actually *doing* anything
> > is, well, beneath the language;
> 
> Investigate the links in the sidebar on the left on
> 
>    http://www.franz.com/success/
> 
> for a summary of the sort of stuff people actually *do* in Lisp.
> 
> If you actually bothered to look before posting unfounded rubbish, you
> might have noticed that Lisp fans appreciate it exactly because it is
> extremely good for writing industrial programs in real-world
> situations.
> 

I have no doubt that Lisp can be extremely practical as a language. 
I'm expressing a slightly humorous characterization of the attitude of
parts of the Lisp community, especially in academia.

> > after working through two books and several university courses on
> > Lisp, going from the definition of eval to lexical vs dynamic
> > scoping to macros to continuations, I suddenly realised that I had
> > no idea how to open a file or do basic string manipulation.  None of
> > them condescended to sully themselves with such trivia.
> 
> 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.
> 
> Maybe you read the wrong books and go to the wrong universities, at
> least for your sort of mind. 

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.  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.

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'.

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.

> The following book, still in the process
> of being written, might be more to your liking:
> 
>    http://www.gigamonkeys.com/book/
> 
> Note the title: _Practical Common Lisp_.
> 

Yes, I'm aware that there's some stuff on the more practical side; the
Lisp Cookbook isn't too bad either.  But it's definitely not the norm,
and you have to dig quite a bit.  No problem, I'm a persistent git.

> > Secondly, Lisp's syntax doesn't parse well into the way people
> > think,
> 
> ... after 20 seconds of thought.
> 
> If you actually try using Lisp, as a programming language for writing
> real-world programs, rather than as something to troll about, then you
> will find that Lisp's syntax matches very closely the way people
> think: they start thinking about source code as a tree structure
> rather than a series of tokens. 


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.

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.  Nest all
of that a couple of layers deeper and it's going to become annoying. 
That's the trouble with having an extremely regular, simple system.  I
guess it makes building the AST easy, though. ;)

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.

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.


>This takes us back to the original
> point I made upthread. Just because your tools don't provide you with
> the ability to do something, thereby ensuring that you don't do it,
> does not mean that doing it is a bad idea, or that not being able to
> do it is a language feature.
> 
> Lisp allows you to think of program source as a tree. "Source is a
> series of tokens" languages seriously limit the way you think about
> your program: this is a shortcoming, not a feature.
> 
> Don't conclude, just because the tools you use limit you in some way,
> that escaping those limitations is somehow undesirable.

It's quite possible to build a program as a set of recursive functions
in just about any language, if you *wish* to build it as a tree
structure.  In fact I do that pretty often, where a problem happens to
be best expressed in that way.  However Lisp pretty much forces you
into one way of doing things.  That's a shortcoming, not a feature. 
The *advantage* of that shortcoming is that it allows you to blur or
eliminate the distinction between program code and data; that's where
Lisp gets it's power from.  It's a trade-off, like most language
design issues.

Lisp has an extremely natural form for certain problems.  Handling
HTML and XML is one of those, and Lisp should really have squeezed
into in many of the gaps currently filled by Java.  (Yes, there have
been companies doing this highly successfully; not many, though.)

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