DEV Community

This is Learning profile image Magne
Magne for This is Learning

Posted on • Edited on

Could parentheses be a reason Lisp is hard to read?

#python #lisp #syntax #language

Many in the communities of Lisp-style languages (Lisp, Clojure etc.) seem to discount parentheses being a reason for people not adopting Lisp. (It must only be the unfamiliarity of FP! You get used to the parentheses, and see past them!) Even though newcomers frequently complain about all the parentheses (of Lisp S-expressions), and several people have attempted to make an indentation-based Lisp (I-expressions, T-expressions aka. Sweet expressions, Cirru, Wisp, etc.). So there must be something to it, or..?

Shared from perplexity.ai :

—-

Reasons why developers might find heavily nested parentheses in Lisp harder to read, and how the Python equivalent addresses that issue.

1. Visual Clutter

Lisp Example:

(defun complex-calculation (x y z)
  (+ (* (- x y) (/ z 2)) (sqrt (abs (- (* x x) (* y y))))))
Enter fullscreen mode Exit fullscreen mode

Why it's hard to read in Lisp:

The parentheses dominate the visual space, making it difficult to focus on the actual logic of the computation. You have to mentally parse which parentheses belong to which operation, and this can be overwhelming in more complex expressions.

Python Example:

def complex_calculation(x, y, z):
    return (x - y) * (z / 2) + math.sqrt(abs(x**2 - y**2))
Enter fullscreen mode Exit fullscreen mode

Why Python is clearer:

Python uses operator precedence and infix notation (+, -, *, /) instead of prefix notation (+, *, etc.). This reduces the need for explicit grouping with parentheses. The mathematical operators are familiar and visually intuitive, making the expression easier to read at a glance.

2. Lack of Visual Cues

Lisp Example:

(if (and (> x 0) ( 0 and y  a b)
      (+ (- a (* b c)) (/ (+ a b) c))
      (- (* a b) (/ (- b c) a))))
Enter fullscreen mode Exit fullscreen mode

Why it's hard to read in Lisp:

With multiple levels of parentheses nested within an if statement, it becomes difficult to match opening and closing parentheses at a glance. Misplacing or omitting just one parenthesis can lead to errors that are hard to debug.

Python Example:

def nested_function(a, b, c):
    if a > b:
        return (a - (b * c)) + ((a + b) / c)
    else:
        return (a * b) - ((b - c) / a)
Enter fullscreen mode Exit fullscreen mode

Why Python is clearer:

Python uses indentation and blocks instead of parentheses for structure. The logical separation between the if and else branches is clear. Parentheses are only used for grouping where necessary, making them easier to match visually.

Sidenote:

In postfix syntax (similar to a stack-based language like PostScript) the Lisp would look like:

((a (b c *) -) ((a b +) c /) +)
((a b *) ((b c -) a /) -)
Enter fullscreen mode Exit fullscreen mode

5. Reduced Readability

Lisp Example:

(loop for i from 0 to 10
      when (evenp i)
        collect (list i (expt 2 i))
      else
        collect (list i (1+ i)))
Enter fullscreen mode Exit fullscreen mode

Why it's hard to read in Lisp:

The combination of nested parentheses and keywords like collect makes it harder to follow what’s happening at each step of the loop. The logic is compact but not immediately intuitive because everything is expressed as nested expressions.

Python Example:

result = []
for i in range(11):
    if i % 2 == 0:
        result.append([i, 2**i])
    else:
        result.append([i, i+1])
Enter fullscreen mode Exit fullscreen mode

Why Python is clearer:

Python's loop syntax separates each part of the logic into distinct lines (for, if, else). The use of indentation makes it easy to see what happens under each condition without needing to mentally parse nested constructs.

6. Limited Expression of Precedence

Lisp Example:

(setq result (+ (* 2 (- 5 3)) (/ 10 (+ 2 3))))
Enter fullscreen mode Exit fullscreen mode

Why it's hard to read in Lisp:

In Lisp's prefix notation, every operator requires explicit grouping with parentheses. This makes it harder to intuitively understand operator precedence because there’s no visual shorthand like infix operators provide.

Python Example:

result = 2 * (5 - 3) + 10 / (2 + 3)
Enter fullscreen mode Exit fullscreen mode

Why Python is clearer:

Python uses standard mathematical notation with infix operators (+, -, *, /) that inherently express precedence rules without requiring extra grouping symbols. This makes the expression more natural and easier for most developers to understand.

7. Indentation Challenges

Lisp Example:

(defun process-data (data)
  (let ((processed
          (remove-if
            #'null
            (mapcar
              #'(lambda (item)
                  (when (valid-item-p item)
                    (transform-item item)))
              data))))
    (sort processed #'item-compare)))
Enter fullscreen mode Exit fullscreen mode

Why it's hard to read in Lisp:

Proper indentation is critical here because it’s the only way to visually separate different parts of the code. Without clear indentation or if indentation is inconsistent, it becomes nearly impossible to follow what’s happening at each level of nesting.

Python Example:

def process_data(data):
    processed = [transform_item(item) for item in data if valid_item(item)]
    return sorted(processed, key=item_compare)
Enter fullscreen mode Exit fullscreen mode

Why Python is clearer:

Python enforces consistent indentation as part of its syntax rules. This ensures that code blocks are visually distinct and easy to follow without relying on parentheses or other delimiters.

Conclusion

In each case:

  • Lisp's reliance on heavy nesting and uniform syntax creates challenges related to readability, cognitive load, and debugging.

  • Python addresses these issues by using features like indentation, infix operators, keywords (if, for), and breaking logic into smaller steps.

This comparison highlights why many developers perceive Lisp's syntax as harder to read while appreciating Python's more structured approach!

Answer from Perplexity: https://www.perplexity.ai/search/8f98d153-997c-4cca-8236-2ea8c2149ca6?utm_source=copy_output

Top comments (3)

Collapse
 
redbar0n profile image
Magne This is Learning •

perplexity.ai explains and shows with code @curtisf reddit answer:
reddit.com/r/ProgrammingLanguages/...

Homoiconicity means that code and data share the same representation—in Lisp, programs are written as lists that are also Lisp data structures. This allows powerful metaprogramming through macros because code can be manipulated like data uniformly everywhere.

However, as you noted, this uniform representation can make it harder to immediately distinguish different roles in the code, such as control flow, literals, computations, and definitions.

Everything looks like a nested list, so without additional semantic or syntactic clues, it can be confusing to quickly grasp what the code is doing. This contrasts with languages that use distinct syntactic forms or keywords to separate these concerns visually and structurally.

Why homoiconicity might harm engineering practice:

  • Lack of syntactic/semantic separation: Control structures (if, cond), literal values, function calls, variable definitions, and macros all look similar (lists). This requires developers to interpret position and context rather than rely on distinct syntax forms.
  • Uniform macros everywhere: Since macros operate on the same data structures everywhere, they can introduce subtle transformations that blur the line between code and data, making reasoning and maintenance harder.
  • Cognitive load: The reader must remember or infer the meaning of each list based on the head symbol and context, which increases cognitive load especially for those new to Lisp.
  • Potential confusion in large codebases: Without clear visual or syntactic markers for different constructs, onboarding developers can struggle with quickly understanding code structure and intent.

Code Example illustrating the uniformity and possible confusion: 

;; Definition
(defvar x 10)

;; Computation (function call)
(+ x 20)

;; Control flow (conditional)
(if (> x 5)
    (print "x is greater than 5")
    (print "x is not greater than 5"))

;; Literal (list)
(quote (1 2 3))

;; Macro example (simplified)
(defmacro unless (condition &rest body)
  `(if (not ,condition)
       (progn ,@body)))

;; Usage of macro looks like normal code
(unless (= x 0)
  (print "x is not zero"))
Enter fullscreen mode Exit fullscreen mode

All of these look like lists; distinguishing definitions, calls, literals, and macros relies on understanding the head symbol (defvar, +, if, quote, defmacro, unless) and the rules of the language rather than from syntactic variety in structure.

Supporting insights from research and discussions:

  • The uniformity granted by homoiconicity is a double-edged sword: it simplifies writing and manipulating code programmatically (especially macros) but makes human reading harder because the code roles are not visually or syntactically distinguished[1][2].
  • Some practitioners argue that this uniformity and extreme macro flexibility can lead to confusion and maintenance difficulty, especially in large or shared codebases, outweighing the benefits of uniform syntax[6][7].
  • Non-Lisp languages sometimes separate syntax to make control flow, definitions, and literals visually distinct to enhance readability and reduce cognitive overhead[2][8].

In summary, homoiconicity enables powerful metaprogramming but does come with trade-offs in code readability and engineering discipline because of the uniform syntactic and semantic representation of different language constructs.

[1] Parenthetically Speaking: "Bicameral, Not Homoiconic"

[2] Reddit r/ProgrammingLanguages: "What is the benefit of being homoiconic?"

[6][7] C2 Wiki Homoiconic Language Drawbacks and Advantages

[8] Wikipedia Homoiconicity usage and drawbacks

[1] parentheticallyspeaking.org/articl...
[2] reddit.com/r/ProgrammingLanguages/...
[3] arcanesentiment.blogspot.com/2008/...
[4] https://www.freetimelearning.com/software-interview-questions-and-answers.php?Discuss-the-advantages-and-disadvantages-of-using-Lisp-as-a-programming-language.&id=10101
[5] news.ycombinator.com/item?id=16387222
[6] wiki.c2.com/?HomoiconicLanguageDra...
[7] wiki.c2.com/?HomoiconicityAdvantages
[8] en.wikipedia.org/wiki/Homoiconicity

Collapse
 
redbar0n profile image
Magne This is Learning •

in lisp it is confusing that the first list element can be data or a function name

Yes, that is a well-known characteristic of Lisp syntax: the first element of a list can represent either a function/operator to call (in code) or simply data (in data structures). This duality stems from Lisp's uniform syntax of S-expressions (symbolic expressions), where code and data share the exact same structure—lists.

This design offers powerful metaprogramming capabilities because code is data, enabling macros and code transformations, but it also introduces some confusion or ambiguity for readers, especially those new to Lisp:

  • When reading a list like (foo bar baz), one must infer from context whether foo is a function being called with arguments bar and baz, or whether the whole list is just data with foo as its first element.
  • Lisp relies on runtime evaluation rules and the environment to distinguish between these cases.
  • In code, the first element is typically looked up as a function or special form; in data, the list is treated purely as a data structure without evaluation.
  • This uniform syntax means that unlike languages with distinct syntax for code and data (e.g., function calls vs array or tuple literals), Lisp code always has the same basic shape, which can be initially confusing but enables very powerful macro systems.

So while Lisp’s syntax allows elegant code manipulation through homoiconicity (code-as-data), it requires programmers to be mindful of the evaluation context to understand when the first list element is an operator versus just data. This is one of the conceptual shifts Lisp demands but also one of its greatest strengths.

Collapse
 
redbar0n profile image
Magne This is Learning • • Edited

In the lisp community, especially Common Lisp, many seasoned lispers hold the idea that, those who dislike lisp's nested parenthesis syntax are outsiders, who don't get lisp. This is factually incorrect.

This page lists lisp projects or languages that implement alternative syntax to solve the controversial nested parenthesis (S-expression; sexp) problem.

xahlee.info/comp/lisp_sans_sexp.html