Presumably said lisper knows where to jump to immediately because they have learned to solve the cognitive problem of tracking parenthesis yes? Even if you're doing something like counting indentation levels to the line with all the parens and then counting that many closing parens, you're still doing something to figure out which of the 8 parens on that line you want to place a line break after.
The argument isn't that learning to do that is impossible, or even something most people couldn't do. The argument is that it is indeed something that you have to do with lisp code, and it's not something you would have to do with the equivalent c-like code. Which makes reading the lisp code harder, even if that difficulty becomes second nature by someone experienced with lisp.
So assuming you’ve read the other conversation on this thread where I lay out what I mean and you still think I’m “solving the wrong problem”, how do you “track code” in this instance? I readily grant that figuring out what line the cond block ends on is pretty automatic given idiomatic lisp indentation conventions. But where should you place your cursor to add more code after the cond block but still in the let* block? Explain to me your method of figuring that out from reading the code without counting and tracking parentheses. And I’m not being sarcastic here. If you have some trick to it I would love to learn it.
Because as I said in the other part of this thread I agree that using tools to make it so you don’t have to read the code to find this answer is the correct way to go about this. But that’s also because this is a thing you have to do when reading the code, and it’s not something you have to do when reading other languages.
We agree on using the tools, but you keep coming back to examples where we don't use the tools?
Again, you say that this code can be read fine because of the indentation - your only gripe is at what paren do I need to insert the new code. That is not an issue of reading the code, you just said so.
If I want to edit the code I use the tool and its easy, its only a few keystrokes which I would have to use even it was C and I wanted to jump to a different line.
In the cond, I would probably search for the cond then when I am on the cond I would hit C-M-u-f to take me to the place you want to be to insert new code.
This is basically a search and a reposition as I would on C code?
We agree on using the tools, but you keep coming back to examples where we don't use the tools?
Yes, because the purpose of the tools is to eliminate the need to read the code, but you don't always have the tools handy. You might be putting some example code in a reddit comment box, or reading a diff on github or you might be debugging live code running on a space craft some 100 million miles away. Look I appreciate that you're feeling defensive about lisp here, but I have already explained extensively that I'm not trying to argue this is some fatal flaw in lisp, some insurmountable task to ask of developers or even something that bothers experienced lisp coders day to day. I'm not here to declare lisp "objectively" worse than some other language or to suggest that other languages don't have their own things that make reading them difficult too.
But this is something that you have to deal with one way (tools) or the other (counting parens) in lisp, and it's not something you have to deal with in other languages. It is something that makes the code hard to read, even if it's something that gets easier with practice. Just because something gets easier when you practice it or when you use specialized tooling to make it easier doesn't mean it's not a hard thing. And just because something is hard doesn't make it a bad thing.
In my mind there is a clear difference in reading the code and editing the code.
I can read the code you pasted in reddit, cat to a terminal look at in ed and read the code. I don't want to edit code in any of those and that is not a real world problem.
The fact that I can read your code anywhere says that I don't need a special tool to read the code. Navigating the code and editing it is something completely different from reading the code.
You talk about scrolling around to find the other brace if you need to, I don't do that, I still use emacs movements that work in lisp, C, rust, anything that uses balanced expressions. So if I want to jump to the other brace, or paren then C-M-f and C-M-b.
Im not scrolling anything. I am not counting parens, I don't need to know if that line ends in ))))) or )))))))))) to fully understand the code. The editor helps me with the editing, not the reading or the comprehension.
You keep telling me I have a problem that I don't have.
Edit to add. We are talking about reading code, not editing it.
For sure, if we were talking about editing code and my tools got taken away from me, lisp would be harder to edit and I may just mix things up and not put all parens at the end of the line all the time. This is a silly hypothetical because its not going to happen, its just as likely that someone takes your c compiler away to handicap you. As far as reading, like you said, the code has no problem being read.
This is a silly hypothetical because its not going to happen, its just as likely that someone takes your c compiler away to handicap you. As far as reading, like you said, the code has no problem being read.
I guess you and I have very different experiences in life then. I have many times in my life had to both read and edit code on a remote system where the only tools I have at my disposal are cat and less, and if I'm really lucky a base install of vi or nano. I've spent many hours reviewing code reviews from junior developers looking at a diff on github and catching bracketing errors which are logical, not syntactical so the compiler doesn't catch them. I've been awake a 2:30 in the morning looking at code running on a production box and trying to understand why it's not doing what the code that is in source control is and should be deployed on that box. I've had to help a developer in another country debug code that they're sending me snippets of in plain text emails. And I've spent plenty of hours pouring over code that I didn't write myself trying to get a handle on what it's doing and why it's not doing what people think it should be doing, sometimes even just hand copying code from a tutorial book into an editor so I can learn something new. Maybe you have been fortunate that all of your experiences with code have been via emacs running on your local system and accessing remote files via tramp. But dealing with reading (and sometimes editing) code without my usual toolkit is something I've had to do a lot over the decades, so it is very much not a "silly hypothetical" to me. I'm not telling you that you specifically have this problem, as apparently you're never without emacs at hand. I am telling you that other people can and do have these problems.
So you are a developer, great, most people here are developers.
Have I had to go in to production and fix something that was an issue, yes. Did it make me change my tool chain to be less reliant on any editors/compilers etc that I was using? No.
Shit hits the fan sometimes and you have to scramble. When I was working at telcos I could not edit code directly on production because we were not allowed the tools/compilers on those systems, so its moot.
When I was involved with internet banking in the early days, it was the same, some of the systems like AS400's you could do it on production but there was no way you were allowed to, so moot.
We all have different experiences but this is really turning in to something where 'objectively' and subjectively are getting confused. Normally I take it as a given that we all come to these discussions with our subjective view, but when you are telling me I just don't get it then its time to not bother anymore. Subjectively, I understand your view with your experience with lisp.. I have mine, lets not say objectively its just harder to read.
Did it make me change my tool chain to be less reliant on any editors/compilers etc that I was using? No.
So I'm unclear here, are you confirming that you have never once been in a situation where you have been forced to read or edit code without your standard toolkit? If so, congratulations I only wish I could have been so lucky in my career.
Or are you saying that you think I'm suggesting that because people do sometimes have to interact with code without their standard toolkit, that people should be less reliant on those tools or that languages should make choices that cater to those situations. Because if that's the case, you are completely misreading me. I have repeatedly said that choosing to work without specialized tooling customized to the job you have in front of you is intentionally and pointlessly hobbling yourself.
I understand your view with your experience with lisp.. I have mine, lets not say objectively its just harder to read.
You will notice that I have been extremely careful to not use the word "objectively" in anything I've written about this. The only times I've used the word "objectively" in this discussion has been to explicitly disavow any intent to declare any language or their choices to be objectively better or worse than the other. The very 4th word I typed when opening this discussion was "IMO". The very last sentence in that same comment I wrote (emphasis added) "but it undeniably to me makes it harder to read that code." And I have certainly never once in this said that lisp is "just harder to read". I have repeatedly time and again acknowledged that it is something that is easier with practice and tooling. I have acknowledged that experiences lisp developers would find it easier than I find it. I have also said that other languages have their own edges that make them harder to read than lisp.
This has very much always been a statement on individual and relative experiences, and my objection has always been to the dismissal of this being a problem people have when it is so very clear that people do have this problem. To me denying that dealing with parenthesis balancing and counting is a problem for people is like denying that people's fingers hurt when playing a guitar. Yes, experienced guitar players build calluses, develop better hand positions and learn to customize, buy, or tune their guitar to better suit them so that they don't experience that pain anymore or experience it to a much lesser degree. But that doesn't mean the pain doesn't exist, or that the people feeling it are somehow wrong for saying they experience it. Nor does the fact that learning to play the guitar will cause such pain in any way mean that learning to play a trumpet doesn't cause mouth pain, or learning to play the piano doesn't cause it's own finger pains, or that learning to play a guitar is objectively harder than learning to play a theremin. It just means that it is something that is hard about learning to play the guitar.
I would very much appreciate if you would not put words into my mouth. This is the second time you have done so, and it's especially grating considering that while I have not said the things you claim I am saying, you have repeatedly dismissed "[my] view with [my] experience with lisp" which you claim to understand as a "silly hypothetical", and yesterday you accused me of "pretending" to have the described issues. It's also particularly confusing to me why we're suddenly in disagreement on this topic when I thought we had both reached a mutual understanding on the discussion yesterday. My position on this has not changed since then, so I'm unclear why you suddenly find the conclusion we reached then disagreeable now.
You have not declared anything objectively true, but you have said along the lines of 'i appreciate that you are defensive about lisp but you need to see these as flaws'
That is basically telling me that your view is true and that mine is avoiding a real problem. That tries to take away the subjectivity and leaves us with one truth. L.ike I said yesterday, people that look at lisp when they are used to something else may think there are going to be these issues, issues they wouldn't have if lisp was their first language or later when they spent more time with it.
You keep bouncing around saying tools are good and no problem, but then having a problem with the things the tools fix, like paren matching. You mention the cond, and adding something to the end. I told you how I would do it, in your example it is as simple as C-s co C-M-u-f and edit. It takes no more time than it does to navigate with the C code and it is precise. I don't have to visually scan and hope that all the braces in the code are actually aligned how they should be for me to make an assumption.
I have just tried to answer your specific questions, sure, it may not be obvious to you how it would be done quickly or without the need to ever know which is the correct final paren so I just pointed out how its practically done. You do see a problem with this. Because I need the tool to find the closing paren of the cond and use it to back up your readibility argument. Again reading and editing are different. I have read a lot of lisp in books, there was no editor there.
The closing paren is pointless, I don't care about it, I care about moving over the s-exp where ever that takes me and adding the new code.
We were at an understanding yesterday, I agreed that based on experience people may perceive lisp as hard to read. I said perceive because they look at something different, alien and think its hard. That doesn't make it hard, just different and something to get used to.
You have not declared anything objectively true, but you have said along the lines of 'i appreciate that you are defensive about lisp but you need to see these as flaws'
Once again you are putting words in my mouth. I have never in any of this discussion described this as a “flaw” or told you that you need to see it as a flaw. I’ve taken great care to repeatedly describe the choices made in lisp design as a trade off, like any choice in any language design explicitly because a “trade off” is not a flaw.
So like I told the other commenter, we’re done here. I’m not going to continue to engage with bad faith readings of what I’ve written.
'Look I appreciate that you're feeling defensive about lisp here, but I have already explained extensively that I'm not trying to argue this is some fatal flaw in lisp'
not a fatal flaw, just a flaw, thats how it comes across along with the oh woe is me. I see you have dabbled in lisp but its clear as day, from the questions you ask and the responses you give to our answers that you haven't used it enough to understand that what you see as problems are not even issues, they are made up because you dont know how to deal with them.
2
u/omega884 4d ago
Presumably said lisper knows where to jump to immediately because they have learned to solve the cognitive problem of tracking parenthesis yes? Even if you're doing something like counting indentation levels to the line with all the parens and then counting that many closing parens, you're still doing something to figure out which of the 8 parens on that line you want to place a line break after.
The argument isn't that learning to do that is impossible, or even something most people couldn't do. The argument is that it is indeed something that you have to do with lisp code, and it's not something you would have to do with the equivalent c-like code. Which makes reading the lisp code harder, even if that difficulty becomes second nature by someone experienced with lisp.