(dotimes (i GODZILLION) (format t "Romani ite domum~%"))

Tsk!   The youth of today.

--

[The subjunctive works though: "Romani eant domum" means pretty much
the same as "Romani ite domum"]

In case you missed it, this is a reference to a scene in Monty
Python's Life of Brian in which Brian sneaks out at night to write
"Romanes eunt domus" on a wall; one of the Roman soldiers catches him
at it, gives him a grammar lesson [though he tells him "domum" is
locative case, which it's not...] and has him write out the corrected
form ("Romani ite domum") a hundred times.

--

In his "History of Lisp" McCarthy says that he intended to clean up the
syntax before Lisp became a production language but it got out in the world.
I figure that if McCarthy wasn't happy with the syntax, it would be
presumptuous of me to like it.

Parens are hard to type.

Some frequently used operators have names left over from the assembler for a
defunct machine.

There's just too much off it. Most of the HyperSpec is just syntax. Compare
Smalltalk. It's entire syntax fits on a couple of pages.

Some frequently used operators, i.e. Do, require the user to put required
parameters in lists that are there just in case the user wanted to use
optional parameters. Others use a perfectly good keyword system. The keyword
system is nice and self documenting but this other, older?, method is
arbitrary.

The syntax for returning multiple values from a function and for receiving
them is awkward and inflexible.

There is no clue, other than sometimes the name, as to whether a function is
a reader or a setter.

In short, Lisp has a reputation for being hard. Where did it get this
reputation? Hardly from its semantics. AFAICT, the semantics of Lisp are
clear and straightforward. It's just the syntax that is confusing.

If you don't believe me, and I don't really expect you to, compare any
random set of postings here with those on any of the big C++ groups. Look at
how many discussions here are about syntax, compared to those that are about
semantics. Compare the C++ discussion where there simply aren't syntactical
issues.

Am I saying that there is an inevitable trade-off between syntactic
complexity and semantic purity? I don't know. It's an interesting question,
though. I do believe that it takes a big language to write a small program
but most of the semantic muddiness of C++ seems to come from the part of the
language, generics, that strikes me as simply broken.

How people get by typing crap like !@#$%^&*{} all day is beyond me.

I would also say that the vast majority of functions have more
descriptive names, it is just the old core of traditional ones that do
not.  There seems to be a tendency in the Lisp community these days to
use more descriptive names over short cryptic ones.

But if you think most of the Hyperspec is ``just syntax'' then you
probably haven't understood any of it.  Or Lisp syntax, for that matter.

(do (variable-stepping-forms*)
    termination-test-form
  body-forms*)

Try doing (multiple-value-bind (a b) 1 ...) in SML.

If you don't believe me, and I don't really expect you to, compare any
random set of discussions here [1] with those in any of the major
totalitarianistic countries.  Look at how many discussions here are
about government, compared to those that are about farming.  Compare the
totalitarianistic country where there simply aren't governmental issues
[to discuss].

[1] Where ``here'' would presumably be a democratic country.

Then, while you are performing this daredevil feat, explain to me that
allowing syntactic abstraction is a mistake.

If you want to convince me of this point you'll have to show me some
examples of what you mean.  Just to take C as a common language target, I
think it quickly gets very obfuscated if you put your {}'s in unusual
places, if you put multiple statements on one line and if you don't indent
properly.  How about deeply nested expressions in C?  There is a reason no
one does it.  Plus, I don't know any language that is still readable if you
screw up the indentation (I don't know that many languages though)

I'm not trying to be argumentative, I just have such different impressions
than you do and it makes me curious.

The Hyperspec is about the _semantics_ of each operation/special form.
Perhaps you don't really know what the word "syntax" means, in the context
of a computer language?

And then you can do nice things with combinations of these operators,
like cadr, cdar, cadar, and so on. Some people don't like it, but I
think these are quite useful in exploratory programming mode.

Pascal

  On Usenet, nobody /believes/ anybody.  Grasping this is /crucial/.

--
Erik Naggum, Oslo, Norway

Maybe a (small) group should get together and just translate (if we can
get his permission) Dorai Sitaram's "Teach Yourself Scheme in Fixnum Days"
<URL:http://www.ccs.neu.edu/home/dorai/t-y-scheme/t-y-scheme.html> into
Common Lisp syntax and idioms. It would need some work to add special
variables (though it already covers FLUID-LET), the chapter on macros
would be significantly different, and the continuation (call/cc etc.)
stuff would have to be converted to talking about exceptions/conditions
and threads (e.g., the "engines" stuff). On the other hand, the presentations
of some topics would even be simpler (e.g., a lot of the development in
the chapter on "Alists & Tables" could be simplified by changing it to
"Alists & Hash Tables").

All in all I think it'd be a good template to work from.

-Rob

Chekout the picture at
http://www.abstractscience.freeserve.co.uk/symbolics/photos/IO/.

The : key is near the top-left. ( and ) are to the right of P.

    pvfunc = 0;

I think that is also where I put the book down, the language, too.

Brave answer you posted, btw. Thx, things were getting a little sleepy
around here.

:)

--

To those who think that the persuasiveness of their argument is somehow
proportional to the vehemence with which they express it, I would point out
that the converse is, in fact, true.

To those who offered various work-arounds for what I asserted were problems
with Lisp's syntax, I would argue that the utility of the work-arounds
demonstrates the existence of the problems.

To the many who said that they find Lisp syntax very simple and elegant
because the proper place to draw the line between syntax and semantics in
Lisp is at the boundary of the S-expression, I would say you win, mostly. If
that's the proper place to draw the line, then Lisp is almost syntax free
and we are discussing nothing. The reason that your argument doesn't prevail
completely is that S-expressions can be trees of arbitrary complexity and it
seems that some of that  complexity was elaborated in the language before
the 'optional parameters are keyword parameters rule' came into play. So
there is some cruft even in this trivial syntax.

To those who said, in some form or other, "The fact that you criticize
Lisp's syntax merely demonstrates that you don't understand it. When you do
understand it, you will recognize it as a thing of power and beauty." I
would say:

I'm inclined to believe you. But if everything you say is true, then Lispers
look more rather than less ridiculous when they criticize the syntax of
other languages to users of those languages.

Finally, to those who say "That's my dog and I love her. She saved my family
when my house caught fire. How dare you point out that spot of mange?" I
would say:

Blame Kenny! He made me do it!

which is not to say a large wadge of code properly formatted cannot be
easily understood. if it is otherwise good code, there is a /lot/ going
on in a large wadge of code. if i am reading it, i probably can break it
down top-down and quickly find the bit i am concerned with.

anyway, this to me is not syntax.

--

There is some `micro-syntax' involving strings, numbers, symbols, etc.
But the syntax of Lisp is fairly minimal, especially when compared to
popular languages such as Java, C, C++, Perl, PHP, VB, Javascript,
etc.

As for flexibility, the common case of getting multiple values when
only one is needed doesn't need any syntax at all.

On many lists such behavior is called wanking or whoring, respectively. It
seems to be more tolerated here. I guess I understand that. It's certainly
excusable if indeed people who are more expressive in Lisp are being forced
by PHBs to use something else.