41
What makes Lisp difficult to read?
(paultm.nl)
you are viewing a single comment's thread
view the rest of the comments
view the rest of the comments
this post was submitted on 28 Sep 2026
41 points (91.8% liked)
Programming
28628 readers
242 users here now
Welcome to the main community in programming.dev! Feel free to post anything relating to programming here!
Cross posting is strongly encouraged in the instance. If you feel your post or another person's post makes sense in another community cross post into it.
Hope you enjoy the instance!
Rules
Rules
- Follow the programming.dev instance rules
- Keep content related to programming in some way
- If you're posting long videos try to add in some form of tldr for those who don't want to watch videos
Wormhole
Follow the wormhole through a path of communities !webdev@programming.dev
founded 3 years ago
MODERATORS
I wanted to learn lisp, but the default formatting is just terrible. If it had a different formatting and supported infix notation, it would be readable to me.
The polish notation is the simplest thing to wrap you head around. Instead of operations being special syntax exceptions, they're just functions! Functions that take parameters.
the only syntax of lisps are
(myfun p1 p2 p3)Mathematical operations are no exception (unlike otger languages). To make it simpler, think of it like this:
+is just an alias (macro) for a function namedpluswhich does addition.(plus 1 2 4 5)is the same as(+ 1 2 4 5). We don't use infix notation because then that would be a syntactic exepction (like other languages) while this is the only syntax we have in lisp, for everything it's really simple.and also, how is
(1 + 2 + 4 + 5)(15 chars) better than(+ 1 2 4 5)(11 chars)? It's a conceptual shift and once you make it, it makes so much more sense.So if lisp wasn’t lisp, you’d like it? 😂 you might want to take a look at Rhombus, or even Haskell.
Why should LISP always be formatted in a way that's unreadable? That can't that be the defining property of LISP, can it?
Haskell unfortunately has literature which doesn't read well to me. All examples are jumbles of letters
f(a, b, c)with "as one can clearly see". It's as if I'm reading a math textbook. It's like nobody writing a Haskell book is an actual educator. Python's documentation is a better intro to the language than any Haskell book I've read.Never heard of rhombus, but I'll check it out, thanks.
Because if you don’t write it this way, then it’s not lisp. I would recommend you to read PG’s essay: On Lisp, and (a hard read) SICP.
As for Haskell, I am a teacher and I teach Haskell. I use Learn you a Haskell and Haskell programming from first principles. Haskell and Lisp are languages that by nature pull CS and math wizards. So is the documentation also written in that way. Hoogle is still one of the best sources of documentation.
practical common lisp is also nice for a quick practical intro
"If you don't paint a picture with this specific paint, it's not a painting". So if someone were to format the code differently, say put each right bracket on a new line, the compiler would fail?
They pull them because he learning material is written for them. If the learning material were written for non-wizards, it would attract non-wizards.
"Learn you a Haskell" is not a good book, IMO. It teaches exactly in the style mentioned. Just look at the part on applicative functors.
He has to describe what the function does because the function declaration doesn't use clear variables or type names. He says the word "box" but writes "f". Why not just write "box"?
The entire CS and maths field is filled with people who suck terribly at explaining anything to anybody who doesn't think like them. Monads aren't terribly complicated, but the way they are explained is. Every book trying to explain them makes the mistake of going deep first and then zooming out. They explain in excruciatingly minute detail how monads are built, what other complicated concept they are like, and use single letter names for everything in that explanation.
Same here. Then the examples use
Justwhich doesn't help with readability either. It would read much better if the code were actually literal instead of using shorthands for everything. More mental energy has to go into keeping a mapping table for every letter in the alphabet instead of it being written explicitly, right there.It's why I hate reading Haskell declarations and old code. Programmers back then just used 1-4 characters for everything. char, bool, m_lnr, T, R, I, f, g, h,.... As if they were constantly on the run from the last person who had to read and maintain their code.
You might be a Haskell teacher, but that doesn't say anything about the quality of your teaching. I play basketball and could even coach a team, but there's nothing that will say whether I'm a good coach. If I get a team of people who already play well together, speak my lingo, and jive with me, they might think I'm a good coach. But if I get a team of beginners who have never heard my vernacular, can't understand my mannerisms, and think "tough love" and the cold shoulder make me a dick, they'll think I suck.
My students who did Haskell last year all passed with flying colors. I think the examples above are plenty clear, and the students also found them clear after I explained them, and with enough practice it wasn’t an in issue. I read the literature, practice it, and then use my teaching skills to teach it. It’s my job, and I take pride in what I do.
I’d say maybe the hypothetical you just needs a good teacher to show how it’s done, or the hypothetical student needs to read it enough till you understand it. In math we also have symbols, in math we also use shorthands. Why not in compsci?
Bar that, Haskell is just not a language that’s suited as a first language. The literature expects from you to be able to understand technical manuals. You don’t go teaching Rust to 8th graders, you don’t go learning Haskell without knowing at least what currying means.
As for brackets, you’re free to put them wherever you want; the professional are also free to do what they want, and it’s usually a good idea to adhere to a standard.
I remember a promising study about Haskell as a first language several years ago. The much bigger problem is indeed documentation and building a curriculum for beginners than anything about the language itself (currying included -- without background from another language you aren't already stuck in the mental state of "every function is uncurried").
Haskell is my favourite language and I like LYAH but at the end of the day OCaml infrastructure for beginners is just better. LearnOCaml in particular. It's a worse language but I get to focus on the "paradigms" part of my course without having to spend extra time teaching how to jump through Haskell's hoops. (They're good hoops, but if I covered them quickly, students wouldn't see it that way, I think.)
If we could get LearnHaskell or something and have it as easy to write exercises and configure, I'd seriously consider switching.
It seems to that you just have a difficult time going outside your comfort zone. The functional paradigm in general seems to be outside your comfort zone.
So much so that I use nix
If it supported infix notation (outside of reader macros), it wouldn't be Lisp.
Why not? Is LISPs only, and major quality, polish notation?
Yes. Well, sort of.
The actual quality is homoiconicity, meaning that code in the language is represented in the language's own data structures (beyond the entire source file being a string). This enables structural macros - using the language to manipulate code before execution.
Some languages have tried to do this without the language syntax actually being data structure literals. Rust does it, but a typical Lisp macro looks like a simple template where some things are marked to happen at compile-time and others get spliced in at runtime. Rust macros don't beyond the most trivial examples.
To add to the point about homoiconicity, both the article and my toplevel comment mention thread macros. The article talks about them being equivalent (syntactically at least) to method chaining, which I agree with.
The thing is, to get method chaining, the language has to have an object system, and the functionality you want to use has to be written in an object-oriented style. To get a thread macro, you need ten lines of code (aside from the docstring and metadata).
you really want infix notation? go do some APL
I don't know much lisp, but in scheme you can do
(1 . + . 2)=(+ 1 2)I've tried a couple of times but it seems pretty cursed.
i had to try again a couple times too before i got my brain to understand it, also maybe had to find just the right guide (practical common lisp in my case), but now that it's in there its much easier for me to reason about code using LISP than it was ever in C/++/#, D, Java, Python...