
Lisp has too many parentheses... - zephyrfalcon
http://symbo1ics.com/blog/?p=275
======
mahmud
Gaaah, knock off the CAPSLOCK and the machismo, please.

Also, you don't need to invent backcronyms for CAR/CDR, they're now called
first/rest.

Having said that, I really like the presentation of your blog, nice
typography. And after skimming your book[1] in progress, and noting your
obvious theoretical bent and taste for rigor, I can only anticipate to read
more of your future posts (latch on to something "obscure" like ACL2 and make
something fun with it.)

[1] <http://symbo1ics.com/blog/?page_id=77>

[Edit:

The book has code samples in 4 different languages; LISP (the ancient cap-
cased "one"), ML, C, and what looks like Pascal. If you want to learn about
the axiomatic specification of computer programs, specially for "structured"
programming, then look into the works of Gries and others, specially in the
silver "Texts and Monographs In Computer Science" books (the entire series is
a feast of delight that should be devoured, and washed down with heirloom,
stolen wine):

 _The Science of Programming_ , Gries.

 _The Design of Well-Structured and Correct Programs_ , Alagic and Arbib.

The selection _Programming Methodology_ edited by Gries has various approaches
to the structured method, with contributions from Dijkstra, Hoare, Wirth,
Reynolds and other rock-stars of axiomatic semantics and verification.]

~~~
angrycoder
The bigger problem is that CAR and CDR actually mean something without the
silly anatomy analogies.

~~~
limmeau
Actually, I like "anterior" and "dorsal" better than assembly instructions
from the 1950s.

------
Jach
I've posted this here before, I'll post it again:

<http://img264.imageshack.us/img264/1397/lispnd7.png>

In practice, I don't find it has many more parens or angle-brackets than, say,
C++ or Java. Considering (), {}, and <> in those two languages, I'd bet Lisp
wins.

~~~
thesz
Languages with juxtaposed argument application (Haskell, OCaml) and meaningful
indentation (Python, Haskell) will win over Lisp. Mixfix-based languages like
Agda2 or Maude will win even more.

BTW, while Halstead metric predict various things about imperative languages
like Algol/PL/1/C/C++/Java quite well, it fails when applied to Haskell:
<http://www.cs.stir.ac.uk/~kjt/techreps/pdf/TR141.pdf>

And fail spectacularly - they have to introduce special "invisible apply"
operator to make Haskell to be closer to imperative languages, just to do not
look like they are cheating.

This is attributed to juxtaposition as application (as it reduces number of
lexems) and to definition of functions by pattern matching. I think other
languages with those two features would have same effect over predictive force
of Halstead metric.

------
koenigdavidmj
Anyone manage to build a Lisp that used semantic indentation (like Python)?
You could make it optional and just have it function as a preprocessor that
generates the real thing.

~~~
j_baker
I find this amusing because I've always found "lisp has too many parenthesis"
and "python has too much significant whitespace" to be roughly equivalent in
terms of relevance.

~~~
prodigal_erik
Nobody writes tools that randomly shred parentheses, but this happens all the
time with whitespace. I'm halfway convinced Ruby is encroaching on Python
because you can't really talk about the latter on the web without ridiculous
workarounds.

~~~
zephyrfalcon
How so? I suppose if you paste Python code in a comment box that happens to
eat whitespace, then there is a problem, yes... but for those cases there's
pastebin and such. Other than that, if you're writing a blog post or article,
then you can just slap the Python code in <pre> blocks, which preserves the
whitespace; most "humane" text editing formats like Textile and Markdown have
ways to preserve it as well.

~~~
prodigal_erik
> comment box that happens to eat whitespace

In my experience, that's easily 2/3 of the web and half of all email and IM
clients. It was so bad that I was surprised when it _didn't_ fail somehow.

Pastebin is just the kind of workaround I would hate to be consigned to.
Reading offline or printing becomes a huge headache because important details
are constantly missing.

------
philwelch
"Dorsal" means "top", like where the dorsal fin on a fish is. It doesn't even
remotely mean "everything except the front". (The belly of a fish is
"ventral".)

~~~
alextgordon
There's an incongruity between animal and human anatomy. In humans, dorsal
does indeed mean back, not top.

Wikipedia has a wall of text by way of explanation:

[http://en.wikipedia.org/wiki/Anatomical_terms_of_location#Wh...](http://en.wikipedia.org/wiki/Anatomical_terms_of_location#Why_zootomy_and_androtomy_terms_differ)

~~~
philwelch
Except, as far as humans are concerned, "dorsal" and "posterior" are
synonymous.

------
eru
Nice article. Though a bit smug; Forth (or even Scheme) have a much cleaner
syntax than the Lisp advertised here.

------
sz
Man all the hype about Lisp just suddenly made sense to me. Why do we need all
this other stuff? Loved the simple exposition and backronyms, contrary to some
other opinions here.

~~~
tlack
We definitely don't need all the fluff, and I like the philosophical
cleanliness of Lisp (from a distance), but to me it seems like too basic of a
building block to think with. Haskell's point free style and K's vector
building blocks seem more useful to me for use in philosophical reasoning
about algorithms.

------
ohyes
Does anyone else have trouble with making the distinction between curly braces
and parenthesis?

I'm pretty near sighted, so I always have to squint to figure out if something
is a brace or a paren. I think it is one of the main reasons I like lisp...

There are no braces, and all I have to do is make sure that emacs indents
everything properly (ctrl+alt+q at top of form... in my head I call it
'regrinding') so I know that the forms I've written have the closing parens in
the proper places.

I know people complain about the parens, but I spend literally no time fudging
with the formatting of my lisp code.. emacs just does it. Java and C code,
however I always end up fiddling with (even with an 'advanced' IDE like
eclipse).

------
brendano
This argument/response comes up every time....

Argument: "Lisp has too many parentheses. It's unreadable."

Response: "It's conceptually elegant that everything is parentheses."

This doesn't address the real point -- you can't read it well. You do get
advantages for macros and symbolic processing. But the cost in readability is
still there.

~~~
tung
My guess is that what people complain about isn't really the parentheses, but
rather heavy nesting of Lisp programs compared to other languages. If
parentheses were replaced with something else, they'd probably complain about
that something else.

~~~
KirinDave
Except that most modern lisps don't even nest that deeply anymore. At least,
not anymore than every functional language that uses nesting to offer new
immutable lexical scopes does.

Seriously, the average nesting depth of a C program is maybe 3-4 (function,
conditional, loop, etc), and C programs are _simple_. More complex languages
like Java and C++ will easily have 4-7 levels of nesting on average. Clojure
and Arc code are probably right on par with that.

~~~
gtani
What happens when a VP of Engineering decides that Cyclomatic complexity will
be capped at 10:

[http://stackoverflow.com/questions/105852/conditional-
loggin...](http://stackoverflow.com/questions/105852/conditional-logging-with-
minimal-cyclomatic-complexity)

~~~
KirinDave
It seems pointless to mandate it, but I don't think it'd really cause a
problem for most real-world clojure programs. For one, cyclomatic complexicty
measures independent paths, and I don't think that's what most people are
complaining about when they say "lisp has too many parenthesis". They're
complaining about how the structures expected require a lot of (sometimes
arduous-seeming) complexity.

Indeed, I suspect that the cyclomatic complexity of an average lisp function
will be less than that of, say, the average Python function. It'd be the same
with any functional language; they encourage you to only have one or two
conditionals per function.

------
Yeroc
And machine code printed in binary is all 1's & 0's. What could be more
elegant than that?

~~~
burgerbrain
Lisp.

------
agentultra
Fantastic article, though the analogy to the Eiffel tower is a bit weak. It's
a good exposition into the argument as to why "code is data," is a relevant
and valuable argument. Lisp is a wonderful language and I love those damn
parenthesis. :)

------
qu1j0t3
@mahmud I don't have to invent backronyms for urmom.

------
crux_
Money quote for the non-lisper:

> For simplicity, let’s use the notation

Yes, let's! Except in lisp, you can't. ;)

(Yes, feeling snarky.)

~~~
jpr
Except you can, just use reader macros.

~~~
vorg
With these reader macros, can the code in the blog example be rewritten as
below, so it still directly maps to the Lisp tree-like semantics, but be more
readable?

    
    
      defun diff(expr, x){
        if(expr == x) 1
        else if(car(expr) == 'plus') ['plus', diff(cadr(expr), x), caddr(expr), x]
        else if(car(expr) == 'times')[
          'plus',
          ['times', cadr(expr), diff(caddr(expr), x)],
          ['times', diff(cadr(expr), x), caddr(expr)]
        ]else 0
      }

~~~
crux_
I'm sure it's possible; lisp is very flexible.

But would your example code still be considered lisp?

------
jpr
"too many parenthesis" is simply a flag that someone is speaking only about
his initial emotional response, not out of actual use experience or
measurement. When you actually count parenthesis in equivalent programs in C
(or C-like syntax) and Lisp, they are almost exactly the same. When you
include the ;.->*& -stuff, C starts to lose because `foo.bar();´ in C becomes
simply `(bar foo)´ in Lisp.

------
partition
Those who keep going on and on about parentheses in Lisp should try Haskell,
which is basically* Lisp, except everything has one argument and is left
associative. This simple rule removes a TON of parens. Add in the $, .
operators and a bunch of other potential parentheses are eliminated.

*Except also that Haskell is typed and does not include code quoting/eval. But that's what Template Haskell is for :)

~~~
petdog
Except that I find myself adding tons of parens to my haskell to be able to
read it. Lisp may have spoiled me.

------
kraynar
I always liked the way Larry Wall put it: "Lisp has all the visual appeal of
oatmeal with fingernail clippings mixed in."

[http://groups.google.com/group/comp.lang.lisp/msg/7700fb02a2...](http://groups.google.com/group/comp.lang.lisp/msg/7700fb02a2750032)

~~~
lispm
then he went on and desi^h^h^h^h ... crea^h^h^h^h ... hacked Perl...

