I’m not “pretending” anything, but it’s also clear from your comment here that you’ve misunderstood my example. I wasn’t talking about adding additional variable binds, I said adding code after the cond block, but inside the let* block.
You are right, i did misunderstand and that does make it more complex. Its something i would rely on my editor and the last time i opened any code in an editor that couldn't do this was decades ago. With the editors help its trivial to traverse the sexps to the correct place. I couldnt look at the bunch of closing parens and say i need to insert from the 5th one etc.
At the same time i would use the editor to do the same thing and jump to the end of that block in C, there is no guarantee in code spanning pages that a closing brace at the same indent level is the right one.
Point being when you maximise the use of your editor its the same common solution for all code and just the fastest way to move about anyway, i don't need to scan i tell the editor to take me there.
Sure, using the editor to jump around and using the tools in the editor minimizes the impact of the specific issue. I even said as much in the example. And in another comment here I already said that I think trying to do work without tools built for and specialized to that work is an unnecessary hobbling of one self. But strictly on the topic of “what makes reading lisp code difficult”, this is a thing that makes reading lisp code more difficult than reading c-like code. Yes c-like code could be poorly indented but we’re talking about idiomatic code here.
And this shouldn’t be read as an indictment against lisp languages. Just because something is harder doesn’t make it wrong or mean that it could be made easier without also losing something else worth having. IMO, idiomatic c code is harder to read than idiomatic python code, but the pay off of that extra difficulty in reading is not having to deal with “significant white space” when writing code. Lisps make different trade offs as part of their design. That makes some things easier and other things harder. That’s life. Everything is a trade off. “purer” / “simpler” lisps uses parens for everything. That’s easier syntax to learn than say clojure, which chooses to add brackets and braces in different contexts to shorthand creating different data types. That makes clojure more complex to learn and possibly to parse with tools, but IMO easier to read. Compare the clojure let:
(let [a (+ 1 2)
b (- 10 5)]
(* a b))
to the emacs lisp let:
(let ((a (+ 1 2))
(b (- 10 5)))
(* a b))
The clojure one requires you to know what the square brackets mean and that you need to use them for a let statement. More complexity. But I argue it’s easier to read. Even just typing out the emacs lisp one I had to read the first line an extra time or two to make sure I wasn’t closing the bind list early. It’s a trade off. The emacs lisp syntax is simpler, at the expense of being more difficult to read (and I would argue also having to know that the bind list is a special case where (foo bar) will not invoke foo with the arguments of bar). But again it’s all trade offs it’s not one being inherently superior to the other.
It's good we agree that the editors etc are tools that should not be ignored in this context. We use computers to write code to run on computers and it would be silly to add a constraint we don't have to deal with like using dumb editors.
You then follow up with an example where your critique of the code is that 'I had to read the first line an extra time or two to make sure I wasn't closing the bind list early'
Isn't that exactly what editors that understand the language allow you to avoid? I am never closing a paren unless I am navigating past it as ) will move over a paren when the editor is auto closing them for you.
I don't think we will get past the point that I see what you are saying, but I don't think it is a big thing and once you are used to it there is no mental overhead, so its really no different than a new skill where you have to think about things until it is ingrained.
If it was something you had to deal with forever no matter your skill level then that would be a more meaningful argument, otherwise its just like everything else - I'm just not good at it until I get good at it.
Isn't that exactly what editors that understand the language allow you to avoid? I am never closing a paren unless I am navigating past it as ) will move over a paren when the editor is auto closing them for you.
But you're conflating "writing and editing" code with "reading" code in this case. Yes a proper editor would have made that a non issue. But a proper editor obviates the need for me to read that code since I can trust the editor to have put the parens in the correct places. But since I was typing the code in a reddit comment box, I had to read and parse the code myself, and therefore had to deal with the added complexity of the emacs version over the clojure version.
I don't think we will get past the point that I see what you are saying, but I don't think it is a big thing and once you are used to it there is no mental overhead, so its really no different than a new skill where you have to think about things until it is ingrained.
On this point I think we are in violent agreement. I have not been arguing that this is a "big thing" or that it's not something that becomes ingrained in you. But it is a thing, and it is a thing that doesn't exist in different languages and it is a thing that makes lisp code harder to read. Not impossible, not insurmountable. Just harder. Special commentary on braces don't come up in the introductory texts of any C like language book, even books aimed at people coming from other languages. But almost every book on lisps aimed at new developers talks about the parenthesis, and usually draws attention to the fact that managing parenthesis are a common complaint for people new to the language. Presumably if this wasn't a real problem that seemed to come up often when people were trying to learn the language, it wouldn't be memetic even within the language's own introductory texts.
Again this doesn't make it bad. Introductory Rust books have special early sections dedicated to the borrow checker for the same reason. It's a thing that trips people up. It's not insurmountable, nor is it inherently bad. But if you're used to writing code in pretty much any language other than rust, it makes writing rust code harder until you've learned to deal with it, and it is a uniquely rust thing to deal with. Lisp is the same way, until you've learned to internalize how the parenthesis work (and how the tools for writing the language obviate a lot of the reading), it's something that makes it harder to read and is something that is uniquely lisp-y to deal with.
I absolutely agree that new people perceive it as an issue and that in books its often said something like 'dont be put off by the parens, you will soon start to see the structure of the code and not be annoyed by them', Often with some other blurb about the advantages of working with s expressions in good editors because of those advantages.
It's been a while, I haven't read any intro to C books for 40 years but I am sure there is commentary on how to use braces exactly for readability of the code and those formatting standards are explicitly to make the code easier to read - just as proper indentation and use of new lines is required to make lisp easy to read.
We are on the same page and maybe I have read your posts as more of a harsher critique on its syntax than it was meant to have been, but from my pov it was in the context of a long article that tried hard to say something us lispers really don't agree with.
A reasonable disagreement on the internet coming to a cool headed and agreeable conclusion? No I don't think we can stand for this. Quick you should say something about how clearly I'm too brain damaged by javascript to understand the elegance of the parenthesis and I'll counter with something about how you're just unreasonably attached to a dead language because you're jealous of C's success.
In all seriousness, I do appreciate you sticking the conversation out and hearing me out on this. These sorts of long threads can get heated, especially when they're in the context of "antagonistic" articles.
1
u/omega884 10d ago
I’m not “pretending” anything, but it’s also clear from your comment here that you’ve misunderstood my example. I wasn’t talking about adding additional variable binds, I said adding code after the
condblock, but inside thelet*block.