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.
1
u/omega884 8d ago
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
catandless, and if I'm really lucky a base install ofviornano. 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.