JS written by different people became easier to read since Prettier appeared. When others’ code is formatted just like your code, it saves effort. Idk if Scheme or other Lisps have standard formatters now; there wasn’t one for Guile when I learned it.
I get because I was like that when I first experienced lisp but I like lisp now.
I found it pretty messy when I was going through the land of lisp book but lisp is pretty flexible and you can make it readable.
When I was converting my 3d game engine to hare lang I missing the flexibility of lisp.
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.
Threading macros, rainbow parens, and paredit style auto closing parens make lisps syntaxes pretty easy to read and manage. I think declarative style languages like ML and Haskell took me longer to get familiar with than lisp style syntax, but that’s probably just because I learned procedural languages first. And I think lisps tend to be more syntactically dense than say Python or C or other languages most people start with.
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 was tempted, but nobody learns anything from that.
I have the impression the author of the article has dabbled with Lisp but hasn’t actually set up a reasonable development environment and written something non-trivial. That’s not a great position from which to write critiques of a language.
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.
the article talks a lot about the parentheses but honestly i have to think that’s the wrong way to go about it. when i write lisp in stock vim i type a lot of
i()ESChi. then i don’t even have to think about the parentheses. it’s a pain in the ass to do it that way obviously which is why most lisp developers use plugins. but with the right formatting you read it just like python. control flow is a problem for me in some lisps though. for what it’s worth, i thought the error the article had with the missed parenthesis was pretty noticeable.also maybe more importantly, i kinda don’t think the proximity argument holds water. plenty of languages use all sorts of spacing to delimit arguments and none of them are harder to read than c. smalltalk comes to mind, which the stackoverflow annual survey once had as its most beloved language of the year. objective-c had similar syntax but with square brackets. i don’t think either one was particularly hard to read, just unfamiliar to c-only programmers. obviously that was a problem for a “language” that just bolted a new thing onto c, but i don’t think it’s a problem in general.
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.
Yes, but they’re wrong. All else equal some of vthat stuff might would matter as optimization, though
“They’re wrong, that’s the way it is”. Great argument. Very convincing.
Some things are obvious, and you can write a whole essay without the base assertion being correct ¯_(ツ)_/¯
Same as you can say something seemingly obvious but still wrong 🤷
Dunno why you’re trying to start a flame war, but I’ll be on my way. Have a nice day!
well, if familiarity can be ruled out, surely there is a quadruply-blind study then? how many participants were there? you need to test teaching lisp first then c and on another group the other way around. you also need to have groups of untrained people and show lisp first, then c, another group for the other way around.
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.
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)?hard disagree. i’ve been a huge RPN calculator fan since middle school. not only does it eliminate a whole class of errors i know everyone makes, but it frees up the corresponding mindshare. i know back when i had math classes i was much faster than everyone else with the calculator. maybe the mandatory parentheses make it less of an issue but i still hate infix notation with a passion. and a lot of languages don’t even use the standard order of operations, nor do they use the same order of operations as each other. so either way i’m making code that looks like lisp because i can’t be fucked to learn a different order of operations for every language i use.
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.I don’t know much lisp, but in scheme you can do
(1 . + . 2)=(+ 1 2)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?
Haskell and Lisp are languages that by nature pull CS and math wizards
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.
fmap :: (a -> b) -> f a -> f bIt says: give me a function that takes anaand returns aband a box with ana(or several of them) inside it and I’ll give you a box with ab(or several of them) inside it. It kind of applies the function to the element inside the box.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.
class (Functor f) => Applicative f where pure :: a -> f a (<\*>) :: f (a -> b) -> f a -> f bSame 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.
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).
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…
the leading question does. :3
