What makes Lisp difficult to read?

Join the discussion

• Hacker News
• Some of the Lisp features that people don't like are built into the language. If you don't like them, there are other languages you can use instead. If you're already using a language you prefer, why are you complaining about Lisp?

  Some features are dialect dependent. If you like the idea of a Lisp, but specifically don't like e.g. Common Lisp, Scheme and Clojure are alternatives. If you don't like these either, nothing is stopping you from writing your own Lisp and using that instead. I have. Lisp is one of the easiest languages to implement and there are two excellent books explaining how to do just that.

  And if your problem is just with formatting or getting the parentheses right, you're probably using the wrong editor. You won't have these problems with EMACS.

  by DonaldFisk
• I think the biggest problem is that expressions are lists, but we build lists with quoting, AND unquoting (or quasiquoting). It takes some effort to look at an expression and be certain of what will be run. Are we displaying the instructions to erase the hard drive, or the output of erasing the hard drive.

  Compare this with Prolog. I like to say "a term is just a term until it's a goal". Assuming we have an erase_hard_drive/1 predicate, I know it's safe to do

      write_term(erase_hard_drive([force,silent,noprompt]), [])
  

  or

      EraseCommand = erase_hard_drive([force,silent,noprompt]).

  by z5h
• You get used to it after a while and at some point the parenthesis 'disappear' and stop taking up mental cycles.

  I often thought about this - at first I struggled a lot and wasted so much time trying to match parens, but after some time my brain adapted and then I actually liked the syntax, especially if your editor supports selecting forms or you use something like parinfer, which matches parens based on indentation.

  Clojure has special syntax for collections of various types, so it's even easier to parse after you get used to it imo.

  For me, the bigger challenge was wrapping my head around functional programming using immutable data structures, since that wasn't just syntax, it required me to 'unlearn' thinking in OO paradigm and adopting a new way of thinking about how the program works. You get used to that too after a while.

  by delegate
• I have a suspicion that 99.999% of people who say that Lisp syntax is difficult to read haven't really tried to use it (outside of a random homework assignment in CS101).

  The syntax is incredibly trivial, and needs very little initial instruction (except to tell newbs to stop trying to put the close-paren on a line by itself, like they are fresh out of a JavaScript boot camp and have no frame to conceive anything else, and that, really, the automatic indentation and the shapes should be at least as readable once you try to use it in real-world examples, and see how that works in practice).

  > Since Lisp puts the function name after the opening parenthesis, there is more distance between the parentheses. This makes it less likely that the parentheses are close enough to be scanned as a single shape.

  Or we can navel-gaze differently, and claim it's more a shape, because then it's a nicely rounded shape that contains the whole function application/call:

      (foo x y z)
  
      foo(x, y, z);
  

  There is a small chance that you're doing the following in a Lisp or C, but you'd be doing something fancy that most people do not (like writing the internals for a pluggable framework or object system):

      (((f a) b ) c)    Pseudo-Lisp
  
      f(a)(b)(c)        Pseudo-C
  

  If you were doing this, and you thought the particular code was hard to read, you could throw in a variable or two, for the intermediate function (or function pointer) values. Or use a combinator...

  When you don't have this fancy function-that-produces-function-that-produces-function pattern, your list head will typically have the name of a function there, and then the syntax simple shape and indentation visually disambiguates.

  In skimming the article, I did see something the article could've followed through on, for a good syntax criticism of many Lisps:

      f[a][b][c]    Pseudo-C, array access notation
  

  Array-intensive Lisp code could use syntax/dialect extension for square brackets for this, if the Lisp doesn't already have comparable syntax:

      [m a b c]
  

  In both references and setters; see my most recent mention of it: https://mastodon.online/@neilvandyke/117067069023420085
  by neilv
• I'll repeat what other people here have been saying: I don't think Lisp is actually "hard" to read, in any objective sense.

  It's "difficult" to read because it's different that other languages, but I think some of those differences actually improve readability once you understand the language. The forced use of parentheses everywhere guarantees that precedence is never ambiguous, for example.

  by tombert
• > I have not yet encountered a fully satisfying explanation as to why Lisp is perceived as being less readable.

  Difficulty is, by definition, relative to one's skill. You cannot so quickly discount the fact that 99% of programming is taught in Java/C style language syntax. If you've had lifelong exposure to Lisp, you might feel exactly the opposite. The author does a poor job of justifying why these pop-cognitive-psych theories should have more weight than prior exposure.

  Personally, as someone with decades of exposure to both styles, I look at the factorial example and see everything I love about Lisp syntax - consistent, no magic keywords and syntax to memorize, it represents a tree just like my mental model of code, there's no way to fall through and forget an else, expressions instead of statements, no early returns ... literally everything about the Lisp example is more readable to me. YMMV.

  by perrygeo
• The parentheses are large glyphs that distract the eye, and do not stand out (to the untrained eye) as delimiters.

  Consider:

    (defun split-line (line)
      (remove-if #'(lambda (word) (string= word ""))
                 (split-sequence:split-sequence #\Space line)))
  

  Now imagine if we had some "lower weight" glyph besides the paren.

    .defun split-line .line,
      .remove-if #'.lambda .word, .string= word "",,
                 .split-sequence:split-sequence #\Space line,,,
  

  Obviously a contrived example replacing () with ., but you can see how "heavy" the parens and how they can dominate what the eye sees.

  With experience, the parens vanish. The parens being large and common take control of the conversation more than they should.

  by whartung
• Lisp isn't difficult to read, so I don't understand the question.

  This feels like someone who doesn't know French asking "what makes French difficult to read?"

  by pfdietz