The first example actually has more bracket pairs (7) for Javascript than for Lisp (6). Rainbow bracket modes for editors can help when bracket matching is an issue.
This example which suggests counting parens is also solved by rainbow brackets, and/or editor tooling like paredit-mode that won’t even let you type mismatched brackets:
(f (g (h (i (j)))))And in most modern Lisps, one might use a thread/pipeline macro instead:
(-> (j) i h g f)With mixed nesting, Lisp programmers often use newlines to improve clarity:
(aap noot ((mies wim) zus) (jet teun vuur))becomes
(aap noot ((mies wim) zus) (jet teun vuur))A later example in the post does that:
(sum (filter (split (read (open "input.txt") ",") (lambda (it) (> it 0)))Which makes one of the errors it contains clear: “,” should be an argument to split, but here it is an argument to read. It is aligned with the start of the first argument to read, so that’s very visible. There are also two levels of unclosed parens. Pasting it into an editor made that clear instantly.
This version is correct:
(sum (filter (split (read (open "input.txt")) ",")) (lambda (it) (> it 0)))But I’d probably write this with a thread macro:
(-> (open "input.txt") read (split ",") (filter (lambda (it) (> it 0))))It’s possible to write unreadable Lisp, but people who are good at Lisp don’t. This is true of most languages.
Thanks for this, I was half going to respond with a glib “skill issue” in response to the article
I worked with Scheme on a project about a decade ago now, and the only code in the project that wasn’t particularly readable was the code written by someone who didn’t attempt to learn conventions and appropriate tooling before contributing.
I will never not post this picture on this subject. Skimmed through the article, seems well written and will read it later.Edit: did read it through, and don’t necessarily agree. I don’t think about any of this when writing lisp code. Emacs deals with my parens, as does paredit and structural editing. This discussion ignores the things that makes lisp work: s-expressions. By changing this main feature, one destroys lisps best feature.
It’s honestly more familiarity than anything else, and it’s mostly that Polish notation isn’t how people learn to read math in school. If Polish notation was how math was notated then lisp would be the easy one to pick up. Similar to how natural languages have the parts of speech in different places in sentences.
Did you read the article? This has nothing to do with familiarity.
I’m still convince that polish notation was the biggest mistakes of Lisp. At some point, the guy who create Lisp language decide to get rid of 2 centuries of mathematic convention just because of a technical limitation that last for maybe 2 decades.
Oh, and no one to talked about
(1- x)?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.If it supported infix notation (outside of reader macros), it wouldn’t be Lisp.
Why not? Is LISPs only, and major quality, polish notation?
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).
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.
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…
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
I agree very much.
When I started developing in Clojure, I came across a lot of Clojure code that simply seems to be formatted/aligned “wrongly”, which was just my intuitive understanding of what the article names more accurately.
It felt to me like everything was too cramped, not grouped properly.
Luckily, it was super easy to fix for me in my code, just do some different alignment and line breaks and readability increased a lot. However, it now doesn’t look like “standard Clojure” which might be its own problem in collaboration, I don’t know.
Lisp.
the leading question does. :3
