Hacker News Reader

Lisp syntax is pretty rough if you want to prioritize maintainability. I can look at blurry C code and know generally what things are and what’s going on without a single character being legible. Lisps don’t typically have the same convenience. Given that code maintenance is usually about poring through thousands of lines of code quickly, I’d say this is a significant advantage for C.

However, Lisps have unparalleled macro flexibility. It’s a clear trade-off that Lispers often have trouble admitting is a trade-off.

> I can look at blurry C code [...]

I'm kind of curious how much of this is the problem with parens, and how much of this is the conventions that Lisp programmers seem to mostly adopt. For instance, here's the concise 99-bottles from Rosetta Code for Racket:

    (define (sing bottles)
      (define (plural n) (~a n " bottle" (if (= n 1) "" "s")))
      (printf "~a of beer on the wall\n~a of beer\n~
               Take one down, pass it around\n~a of beer on the wall\n\n"
              (plural bottles) (plural bottles) (plural (sub1 bottles)))
      (unless (= 1 bottles) (sing (sub1 bottles))))
    (sing 99)

And even with a snippet this short, it's not quick for me to scan. Lispers generally like hanging parens, the indentation varies depending on what construct you're in, and that example uses recursion instead of a for-loop [0].

Ok, so let's turn the concise Python one into a hypothetical Lisp:

    (for i in (range 99 0 -1)
        (let b = "bottles of beer")
        (let w = "{b} on the wall")
        (print "{i} {w}, {i} {b}\n")
        (print "Take one down and pass it around, {(- i 1)} {w}.\n")
    )

I think you could "know generally what things are" with that version even if it was blurry. And of course, this "hypothetical lisp" is legal Racket/Scheme after implementing a few macros.

[0] I know Racket has for loops, but they didn't choose to use them in that example. Which is my point.

More or less idiomatic TXR Lisp:

  1> (defun bottles-verse (n)
       (flet ((bottles (:match)
                ((0) "No bottles")
                ((1) "1 bottle")
                ((@x) `@x bottles`)))
         (put-line `@(bottles n) of beer on the wall\n\
                    @(bottles n) of beer\n\
                    Take one down; pass it around\n\
                    @(bottles (pred n)) of beer on the wall\n`)))
  bottles-verse
  2> [mapdo bottles-verse 5..1]
  4 bottles of beer on the wall
  4 bottles of beer
  Take one down; pass it around
  3 bottles of beer on the wall

  3 bottles of beer on the wall
  3 bottles of beer
  Take one down; pass it around
  2 bottles of beer on the wall

  2 bottles of beer on the wall
  2 bottles of beer
  Take one down; pass it around
  1 bottle of beer on the wall

  1 bottle of beer on the wall
  1 bottle of beer
  Take one down; pass it around
  No bottles of beer on the wall

  nil
  3>

Why does 5..1 go from 4 to 1? Because 1..5 goes from 1 to 4; it's a half-open interval. 5..1 goes over the same values in reverse.

:match is a "parameter list macro", which is something I invented. flet knows nothing about pattern matching; it transforms to a lambda, which also knows nothing about pattern matching, but :match takes the parameter list and body, transforming the code using the pattern expander logic.

String literals and quasiliterals can go across multiple lines, but with the permission granted by a continuing backslash. Being explicit about this lets us catch errors when a literal is left open accidentally. All unescaped whitespace before a continuing backslash, and leading whitespace at the start of the next line is deleted:

   "abcd    \
    efgh"           -> "abcdefgh"

   "abcd   \
   \ efgh"          -> "abcd efgh" ;; escaped space counts

   "abcd\  \
    efgh"           -> "abcd efgh" ;; on either side of \

I think I must be really bad at communicating, because you aren't responding to any point I was trying to make. Let me try again :-)

I think Racket, Scheme, and some Lisps are conceptually elegant, but they don't read well to people like me (or apparently the poster above).

In particular, your snippet of code has 3 different indentation strategies, and you hang your closing parens the way almost all Lisp programmers do. To me, it all looks so organic and arbitrary.

So, for those of us who don't like to read other people's Lisp - is it because of the parens? Or is it because the conventional Lisp style is alienating to us?

I really think it's the style. I'd rather read your example like:

    (defun bottles-verse (n)
        (flet
            ((bottles (:match)
                ((0) "No bottles")
                ((1) "1 bottle")
                ((@x) `@x bottles`)
            ))
            (put-line
                `@(bottles n) of beer on the wall\n\
                @(bottles n) of beer\n\
                Take one down; pass it around\n\
                @(bottles (pred n)) of beer on the wall\n`
            )
        )
    )

That's still not quite as nice as I'd like, but maybe you can see where I'm coming from.

I think most Lispers would say, "You get used to it." But, well we don't get used to it because we just stay with whatever our curly braced or indentation language is instead.

I write Lisp mostly in the same I write C, and the way I wrote C before learning Lisp. (Except for not closing braces on the same line; though I experimented with that style and it was fine.)

   printf("Hello, %s\n",
          get_user_name());

In C, it is common to close parentheses together though. Look at the alignment in the tm_diff function in glibc:

https://sourceware.org/git/?p=glibc.git;a=blob;f=time/strfti...

  371   int days = (365 * years + intervening_leap_days
  372               + (a->tm_yday - b->tm_yday));
  373   return (60 * (60 * (24 * days + (a->tm_hour - b->tm_hour))
  374                 + (a->tm_min - b->tm_min))
  375           + (a->tm_sec - b->tm_sec));

Vim does this alignment; I'm confident I could visually select these lines, hit = and they would stay the same.

The author put extra parentheses around the initializer for days, and around the return expression. I almost certainly know the reason; doing so encourages the editor to do the alignment of the + operators with the interior of the parenthesis.

Vertical alignment is important because if you violate it, it leads the eyes astray:

  `@(bottles)
  @(bottles)`

Both expressions are inside the quasiliteral: they are parallel elements. Why has one de-indented, as if the literal had already closed in the previous line?

There could be another argument after the quasiliteral:

         (put-line `@(bottles n) of beer on the wall\n\
                    @(bottles n) of beer\n\
                    Take one down; pass it around\n\
                    @(bottles (pred n)) of beer on the wall\n`
                   output-stream)

If you have it like this:

         (put-line `@(bottles n) of beer on the wall\n\
                   @(bottles n) of beer\n\
                   Take one down; pass it around\n\
                   @(bottles (pred n)) of beer on the wall\n`
                   output-stream)))

you're pepetrating a trompe l'oeil. The transition out of the literal is masked, making it look like output-stream is still part of the literal.

I see you like four space indents, and I've used them in C in years past.

Even if I wanted to experiment with four space indents in Lisp, the editor I use wouldn't support it. Believe it or not, the two space indentation is a hard-coded behavior in Vim's Lisp indent mode.

Vim doesn't support the quasiliteral formatting I'm doing; I had to make the one space adjustment by hand.

In short, there is almost nothing arbitrary about the way I'm formatting anything.

Without a doubt, C programmers have different styles. And there's disagreement about what to do when an expression gets too long.

However, almost no C programmer would stack and hang their closing curly braces the way Lisp programmers do with closing parens. And for the few exceptions you'll find, they're almost certainly Lisp programmers making a point about not doing what the Romans do when they're in Rome.

> In short, there is almost nothing arbitrary about the way I'm formatting anything.

Heh, I didn't mean it as an attack on you. I meant it how the rest of us perceive it. Forgive me :-)

I guess it's only natural that you should defend your own style. I'm just curious if maybe part of the reason Lisp is so objectionable to most programmers is because that style is so different from block structured languages.

Many people here seem to like Python. So they think this is fine:

    def doit(n):
        for i in range(n):
             print(i)

Many fewer people seem to like Lisp. So maybe this is less likeable for some reason:

    (def (doit n)
        (for i in (range n)
             (print i)))

Ok, so is this more likeable?

    (def (doit n)
        (for i in (range n)
             (print i)
        )
    )

Just curious.

> Even if I wanted to experiment with four space indents in Lisp, the editor I use wouldn't support it.

That's pretty circular though... Lisp programmers expect a certain indentation, so editors provide it.

> I guess it's only natural that you should defend your own style.

I have reasons for writing things that way, that can be documented, if necessary. The style is not my own, though.

> However, almost no C programmer would stack and hang their closing curly braces the way Lisp programmers do with closing parens.

But they do it all the time with parentheses, which is the normal thing to do.

By the way: spotted lots of this in the Zstandard compression code base a few days ago:

  void fun()
  {
    if (...)
    {
      for (...)
      {
       ...
  } } }

Yikes; the closes braces line up with the opening ones, but not their corresponding matching ones. I hope that wasn't a Lisp coder (and don't suspect it).

> I'm just curious if maybe part of the reason Lisp is so objectionable to most programmers is because that style is so different from block structured languages.

But it isn't. Almost all the indentation and alignment strategies you see in canonically formatted Lisp code have counterparts in everyday code in mainstream languages.

Found this in Linux's kernel/sched/core.c:

        WARN_ON_ONCE(debug_locks && !(lockdep_is_held(&p->pi_lock) ||
                                      lockdep_is_held(__rq_lockp(task_rq(p)))));

                                                                           ^ Lisp disease?

                                      ^ gee what is this "arbitrary" alignment?

Would C be more popular if it was more typically like this?

        WARN_ON_ONCE(
            debug_locks &&
            !(
                lockdep_is_held(
                   &p->pi_lock
                ) ||
                lockdep_is_held(
                    __rq_lockp(
                       task_rq(p)
                    )
                )
            )
        );

In fair.c file in the same directory:

        if ((ns->nr_running < ns->weight) ||
            (((ns->compute_capacity * 100) > (ns->util * imbalance_pct)) &&
             ((ns->compute_capacity * imbalance_pct) > (ns->runnable * 100))))
                return node_has_spare;

in drivers/md/raid5.c:

        if (s.written &&
            (s.p_failed || ((test_bit(R5_Insync, &pdev->flags)
                             && !test_bit(R5_LOCKED, &pdev->flags)
                             && (test_bit(R5_UPTODATE, &pdev->flags) ||
                                 test_bit(R5_Discard, &pdev->flags))))) &&
            (s.q_failed || ((test_bit(R5_Insync, &qdev->flags)
                             && !test_bit(R5_LOCKED, &qdev->flags)
                             && (test_bit(R5_UPTODATE, &qdev->flags) ||
                                 test_bit(R5_Discard, &qdev->flags))))))
                handle_stripe_clean_event(conf, sh, disks);

All of these examples use pretty much identical formatting logic as what I'm following when I'm coding in Lisp; except that a more pure version of it occurs.

Well, you've successfully found examples of C code that I hate to look at. Those are all various shades of awful in my opinion.

And again, I'm not attacking you or your style. I'm sure all 6 or 7 of you from comp.lang.lisp agree it's wonderful. :-)

This is a predominant style used in writing "curly-braced C-likes"; you see it everywhere and examples can be found readily. You simply don't seem familiar with this subject area.

Heh. I see we've gotten to the point where you switch from arguing the point to questioning my qualifications. Gross.

I guess that means I should return the insult: Showing a few examples of ugly formatting doesn't prove that curly-braced languages are that way "everywhere". And besides, other than the one silly example from Zstandard, which many people would agree is unusual, you didn't even show examples of curly braces. Even with all the different styles of C people use, the block structure is pretty consistent. You're either being deceptive or you need work on your logic skills.

Go ahead and grab the last word if you want it, but I think we've gotten away from anything good in this discussion.

The Lisp version looks similar to the Python code, plus parentheses. As a Lisp user I would read the Lisp code just like the Python code, by largely ignoring the parentheses, looking at the indentation and blocks of code. As a Lisp user working with code manipulation I then profit from that Lisp can be pretty printed by a tool, since the indentation is not The dangling parentheses then don't add any value. Actually they waste space and are getting in the way when typing to a read-eval-print-loop (REPL).

I haven't seen anyone typing to a REPL dangling parentheses.

    CL-USER 23 > (defun foo (a)
                   (list
                    (list
                     a b c
                     )
                    )
                   )
    FOO

What I always see is compact code like this:

    CL-USER 24 > (defun foo (a)
                   (list (list a b c)))

It's more like an experienced user of a bicycle will not use stabilizer wheels. For any person who can ride a bicycle they look weird, unneccessary and actually hindering them. After a short learning phase few people will need them any more and will be happy to get rid of them.

Lisp has quasi-standard indentation styles. They make code more readable and writable. The differences between Lisp and most other programming languages: Lisp code is written/read/manipulated as a data structure.

What you wrote has also different indentation styles, but dangling parentheses are seen as not helpful: Lisp users don't count parentheses, they don't match parentheses like that, their code is indentation heavy, code can get very long and code can be generated. Lisp macros are an example of generated code. That means Lisp users also might look at generated code, for example when they check the code a macro generates or when one users a Lisp interpreter during debugging. The Lisp interpreter directly executes Lisp source data structures.

Lisp users read by indentation of lists.

The parentheses in Lisp have a different purpose as curly braces in other languages. In Lisp the parentheses are used to denote a data structure: lists. The syntax for lists (or more correct s-expressions) has its own syntax. Programs are written as nested lists of other objects. Thus the programming language Lisp is defined on top of lists. It's possible and not unusual that code is not written to a file, but generated in memory or by typing to a Lisp read-eval-print-loop, where some will directly treat the input as data, not as text.

We we want to write lists as compact as possible and use indentation to make groupings visible, where necessary.

The Lisp programmer learns to write/read/manipulate lists as a base. Programs are then written as lists.

The usual pretty printer shows this:

    CL-USER 20 > (pprint '(defun bottles-verse (n)
                            (flet
                                ((bottles (:match)
                                   ((0) "No bottles")
                                   ((1) "1 bottle")
                                   ((@x) "@x bottles")
                                   ))
                              (put-line foo bar)
                              )
                            )
                         )

    (DEFUN BOTTLES-VERSE (N)
      (FLET ((BOTTLES (:MATCH)
               ((0) "No bottles")
               ((1) "1 bottle")
               ((@X) "@x bottles")))
        (PUT-LINE FOO BAR)))

You aren't telling me anything I don't already know.

> Lisp [...] indentation styles. They make code more readable and writable.

This is a matter of opinion, and you're free to ignore the majority or programmers who don't like Lisp. Trust me though: there are a lot of smart programmers who reject Lisp, and it's not because they "just haven't learned to ride a bike" yet.

My only question is whether the people who don't like Lisp dislike it because of parens (which is the conventional wisdom) or because of the arbitrary indentation and closing brace style.

> This is a matter of opinion

But, it turns out, it basically isn't. In the Lisp world there is a tremendous consensus about it; nearly everyone does it in nearly an identical way to everyone else. This is in stark contrast to the way, say, C or C++ people lock horns over formatting.

Even if you might not like the particular way it is done, the dogged consistency has to count for something.

> arbitrary indentation and closing brace style.

Lispm demonstrated how this style is reproduced by a Lisp system's printer. It's codified into a documented algorithm, and one that isn't hugely complicated.

> But, it turns out, it basically isn't. In the Lisp world there is a tremendous consensus about it; nearly everyone does it in nearly an identical way to everyone else.

Yes, and that's self selecting. If someone hates that style, that might be one reason they don't stick around in the Lisp world.

Besides, something being a consensus has little to say about whether it's an opinion or not.

> Even if you might not like the particular way it is done, the dogged consistency has to count for something.

Lol, no! Just like consensus, consistency isn't a virtue on its own. You could be consistently doing it wrong. :-)

>Yes, and that's self selecting.

No, people could just use their style. We've seen that in some subgroups. Often for example with AutoCAD users scripting in AutoLisp / VisualLisp.

> consistency isn't a virtue on its own. You could be consistently doing it wrong. :-)

Consistency is a virtue on its own. Consistent coding standards improve readability for a wider group, even if the coding standard would be slightly less optimal according to some other metrics.

Helping people cooperate is a virtue. You're confusing the means with the ends, and it's very likely that the OP I first responded to above does not find the Lisp-consistent style very readable, so it didn't enable his cooperation.

They made a point of saying, "I can look at blurry C code and know generally what things are and what’s going on without a single character being legible." That sure seems like their problem with Lisp is layout/formatting.

> Helping people cooperate is a virtue.

Oh, is that what you're doing?

> it's very likely that the OP I first responded to above does not find the Lisp-consistent style very readable, so it didn't enable his cooperation.

I can't find that in his post.

He wrote:

"I can look at blurry C code and know generally what things are and what’s going on without a single character being legible. Lisps don’t typically have the same convenience"

> Trust me though: there are a lot of smart programmers who reject Lisp, and it's not because they "just haven't learned to ride a bike" yet.

You aren't telling me anything I don't already know - to quote your remark from above.

The questions of code formatting and Lisp syntax has been discussed since the early 1960s. I've taking part in such discussions myself since the mid 80s.

My take: people don't like Lisp or reject Lisp because of MANY different factors - and many are justified, based on what they are looking for - not everybody needs to like or use Lisp - if there are better programming languages with their eco-systems for many programmers, that's totally fine for me.

Syntax is a factor why people don't program in Lisp. The standard formatting rules are a minor factor. More important is that the syntax&semantics is difficult: the consequences of code as data is confusing them - for example they have to deal with quoting/evaluation rules, they see that there are macro expansion phases which make code understanding and debugging harder, etc.

> ... because of the arbitrary indentation and closing brace style.

Lisp does not have an 'arbitrary' indentation and closing brace style. There are clear rules and these are supported by tools in various ways.

> discussed since the early 1960s. I've taking part in such discussions myself since the mid 80s.

You have me beat, if being older is winning. But I was lurking on comp.lang.lisp before web browsers were a thing too...

> Lisp does not have an 'arbitrary' indentation and closing brace style.

Heh, that word seems to bother both you and kazinator. I didn't mean it as an insult. :-)

'being older is not a virtue in itself' (using one of your phrases), more interesting would be the experience of actually seeing people and helping them trying to learn Lisp in different settings. For example: at the local university we had several hundred students each year who had to learn Lisp and/or Scheme (and other programming language) as part of their extensive computer science introductory courses - most students had no prior knowledge of Lisp. That was at a time when we used printer terminals or vt terminals to edit code. Later one could see students who could do programming homework on their personal computers or with UNIX workstations at the University...

That's good context. Thank you for the reply.

A few years back, both my brother and father wanted to learn to program. Actually, relearn in the case of my dad. He was doing assembly programming for fun when I was a kid, and he taught me Basic. So really, he wanted to re-learn after a 30 or more year hiatus.

I tried to turn them both on to DrScheme (PLT wasn't named Racket yet). I figured the language is elegant, the tool is friendly, it's got libraries for tons of things, and the syntax is really simple. Kind of the "learn the language in the first part of the first chapter" approach in SICP, and then get to doing something fun. It's a much better language, environment, library, and implementation than Python. But it really didn't pan out.

I'm sure we can blame me for being a poor teacher, but my brother got turned off completely, and my father seemed pretty annoyed it wasn't anything like he remembered. After that, I showed him Python, and he ran with it for a few months before he switched back to doing his pet projects in Excel. He's older than both of us, so he can do whatever he wants :-)

Anyways, I kind of like Scheme, and I've been installing various implementations of it on my computers for the last two decades. Of course I must not like it that much, because I almost never use it for my pet projects. Maybe that's because I like numerical stuff and am too lazy to sort out an infix macro that makes me happy. It's just easier to use Python or C++ (or lately, Rust).

Elsewhere, you made the comment "The Lisp version looks similar to the Python code, plus parentheses". Apparently it wasn't obvious, but that was intentional :-) I just wonder why people (like my father) find Python so accessible, when you can make Scheme look nearly identical if you ignore the parens. In every way that counts, Scheme is at least as expressive and has much better implementations than Python... Yet people prefer Python.

If I ever make my own compiler, I'm inclined to use parens as delimiters for expressions. I'll spare you the details, but it won't really be a Lisp, and it would be more block structured. I only bring this up because in your first reply above where you were proselytizing and pontificating, you were already preaching to the choir. Since that OP way up there made a comment about it not scanning well (looking at it with blurry text), I wanted to hear from someone who doesn't like Lisp what it would take to make it likable.

And of course all my comment did was draw attention from two people that want to defend Lisp. :-)

> in particular, your snippet of code has 3 different indentation strategies, and you hang your closing parens the way almost all Lisp programmers do. To me, it all looks so organic and arbitrary.

In Lisp we don't align Lisp code according to only the parentheses.

A Lisp programmer looks at the symbol in front and based on that there are one or more strategies for indentation. On my Lisp Machine I can cycle through different indentations or I can completely layout the code (called 'grinding' in old Lisp).

There are different lists:

a definition macro

   (defun name (arg1
                arg2)
     a
     b)

a function call

    (foo bar baz)
    (foo bar
         baz)
    (foo
      bar
      baz)

a special form:

    (if a
        b
      c)
    (if a
        b
        c)
    (when a
      b
      c)

Property lists:

    (:name foo
     :age 23)

and lots more. Each macro has a simple implementation style but typically an editor may have custom layout rules, depending on the macro and its syntax.

I read your article when it was first published and agree with the sentiment.

Off topic (sorry) but one thing Racket is missing is great Python interop to mix in deep learning and other libraries. Common Lisp and Clojure have this support. Years ago I tried saving trained Keras weights and using them in Racket with the Matrix support: it works, but not very fun to use.

Would something like `flomat` have helped?

https://docs.racket-lang.org/manual-flomat/index.html

Thanks, it would have. I see you are the author, what types of applications do you use flomat for?

Couldn't this go the other way too? People who have no experience with programming languages have no basis for evaluating the comprehensibility of a language's syntax. I didn't have any complaints about BASIC until I tried Pascal, etc.