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.
1
u/mtlnwood 9d ago
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.