Speculative Problems

Jean-Philippe Paradis tweeted the perfect answer to those who complain about “problems” with Lisp syntax. The tweet was apparently provoked by this post from John Cook that, while discussing symbols in programming languages, remarked that “Lisp’s typographical monotony makes it hard to skim for landmarks.” Paradis' tweet makes the point that supposed problems with s-expressions are speculative in that they tend to disappear once one becomes familiar with the syntax.

I'm with Paradis on this. Certainly Lisp has fewer symbols than APL and arguably fewer than Perl but I don't find it anymore typographically monotonous than, say, C, C++, Python or most of the other mainstream languages. I certainly don't have any more problem scanning it than I do the others. I think Paradis is exactly right: once you use it for a little while, the syntax or lack of it just disappears into the background.

What do the rest of you find? Do you think Lisp is typographically monotonous? If so, does that make it hard to scan for you? I don't think so but Cook, who is not a stranger to Lisp, seems to believe it is. Share your experience in the comments.

This entry was posted in General and tagged , . Bookmark the permalink.

6 Responses to Speculative Problems

  1. Xah Lee says:

    yeah, i also think it's a problem. I think there are 2 opposite aspects, and whichever side one stands, there's a logical conclusion that lisp syntax have certain problem.

    first is the monotonic syntax problem. Nature isn't monotone, and i don't think we handle it well. You and other lispers believe it isn't a problem at all once used to, but i find it a problem, namely, not as good as if it had more syntax variations. (and i think quite a few lispers are on this side too. Many expert Common lispers expressed this criticism, as well as in discussion when Dylan switched to algor-like syntax.) One supporting evidence of this idea is that there are lots modes to help with the lisp syntax, yet they are almost hard to use, and semi-solutions, doesn't work well, and adopted only minor percentage of lisp coders. For example, the coloring paren mode, the paredit mode. Lisp syntax, given its regular nature, we really should have automatic formatter builtin, or real semantic based editor. I understand some editor has some of that feature to various degrees (hemlock, Climacs, Edwin, ...?), but not gnu emacs.

    the other aspect, which i haven't seen much mention, is that the lisp syntax isn't regular. The syntax for quote, the dot notation for cons pair, the comment syntax, the macro syntax. In my opinion, if we abide 100% regular lisp nested parens, it would make the language much more powerful, in the sense of macros but more importantly, the long-term direction of growth. If lisp syntax were 100% regular, i surmise that we would have automatic formatter or sematic-based editor long ago.

    • jcs jcs says:

      Thanks for your comments, Xah. I have to say that I don't get this "typographical monotony" thing. How is


      for (i=0; i<10; i++)
      a[i] = a[i] + i;

      less monotonous than


      (dotimes (i 10)
      (setf a (+ i (aref a))))
      ?
      Perhaps you could argue that the typical mapcar expression has a more uniform skyline than the corresponding, say, C statements but it's still a win because it expresses the whole operation in a single expression whose meaning is instantaneously recognizable.

      Many of the apparent irregularities in Lisp are really just shortcuts to save typing. For example '(a b c) is just a shortcut for (quote a b c). Similarly ("a" . 2) is just a handy way of setting a cons cell and could just as easily be written (cons "a" 2). One thing for sure, Lisp's syntax (or rather lack of it) is far more regular than most other languages. Part of what really makes programming hard for beginners is learning the syntax of the language.

      • Xah Lee says:

        hey Jon. I love to argue, and thanks for the post on this issue. Our opinions may differ, but i enjoy the discussion/argumentation.

        about the monotonic quality aspect you gave example of, the lisp case is harder to read. ( but am no fan of C-like syntax either, which is mostly syntax soup (between the two, i rather favor lisp syntax)) The example you gave is small, but when in large quantity, as in real world source code, i think the effect is there.
        e.g. this classic example:

        (-b + sqrt(b^2 - 4 * a * c))/(2*a)

        vs

        (/ (+ (- b) (sqrt (+ (^ b 2) (- (* 4 a c))))) (* 2 a))

        this is a artificial example, and involves math formula. But in my experience, the argument in this example applies to general lisp code.

        but then, one may argue that one should indent the code and it become even better than the infix. But that argument by itself indicates a weak quality of lisp syntax. Namely, it requires xyz, while the other syntax don't.

        about the irregularity of lisp code, i can't see how you are in favor of it. It seems a contradition of stance. If lisp touts its regularity of syntax, in its benefit of macros, it should go all the way.

        • (First time I tried posting this I got an error. Refreshing the page didn't show my comment so I tried posting it again, this time it said I "already posted that". Apologies in advance for any duplicates.)

          but then, one may argue that one should indent the code and it become even better than the infix. But that argument by itself indicates a weak quality of lisp syntax. Namely, it requires xyz, while the other syntax don’t.

          That's bullshit. Almost all computer language syntaxes REQUIRE at least some indentation to be properly human-readable beyond short samples.

          I won't recapitulate all the advantages of s-expressions here, but the lack of need for screwed up "precedence rules" is a notable advantage of prefix syntax for mathematical expressions.

  2. (I tried posting this yesterday but didn't see it, so apologies if this is a double post.)

    I have to agree with Jean-Phillipe on both points. Xah's example of the quadratic formula is a bit of a straw man. I have no problem reading the Lisp version with prefix operators (probably due to a lifetime of using RPN on HP calculators). The benefits of Polish notation for easy parsing are well-known.

    But you'd never write a sexp like that (all on one line) in actual Lisp code; you'd indent it to show structure, just as C code is indented by convention even though its semantics are fully specified by non-whitespace delimiters (the curly braces, square brackets, etc.). If there's any proposal to improve the syntax of Lisp that makes sense IMHO, it's not the ones that call for adding more and varied punctuation--it's the proposal to get rid of parens and make whitespace semantically meaningful as in Python!

Leave a Reply

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>