I would guard against "arguing from the extremes". I would think "on average" compact is more helpful. There are definitely situations where compactness can lead to obfuscation but where the line is depends on the literacy and astuteness of the reader in the specific subject as already pointed out by another comment. There are ways to be obtuse even in the other direction where written prose can be made sufficiently complicated to describe even the simplest things.
That's probably analogous to reading levels. So it would depend on the reading level of the intended audience. I haven't used C in almost a decade and I would have to refresh/confirm the precise orders of operations there. I do at least know that I need to refresh and after I look it up it should be fine until I forget it again. For people fluent in the language unlikely to be a big deal.
Conceivably, if there were an equivalent of "8th grade reading level" for C that forbade pointer arithmetic on the left hand side of an assignment (for example) it could be reformatted by an LLM fairly easily. Some for loop expressions would probably be significantly less elegant, though. But that seems better that converting it to English.
That might actually make a clever tooltip sort of thing--highlight a snippet of code and ask for a dumbed-down version in a popup or even an English translation to explain it. Would save me hitting the reference.
APL is another example of dense languages that (some) people like to work in. I personally have never had the time to learn it though.
> APL is another example of dense languages that (some) people like to work in.
I recently learn an array programming language called Uiua[0] and it was fun to solve problems in it (I used the advent of code's ones). Some tree operation was a bit of a pain, but you can get very concise code. And after a bit, you can recognize the symbols very easily (and the editor support was good in Emacs).
Arthur Whitney writes compact code in C (and in k of course); most things fit on one A4 which is actually very nice to me as an older person. I cannot remember as much as I could (although i'm still ok) and just seeing everything I need to know for a full program on 1 page is very nice vs searching through a billion files, jump to them, read, jump back and actually mostly forgotten the 1000 steps between (I know, this refers to a typical overarchitected codebase I have to work on, but I see many of those unfortunately).
When I first read the K&R book, that syntax made perfectly sense. They are building up to it through a few chapters, if I remember correctly.
What has changed is that nowadays most developers aren't doing low-level programming anymore, where the building blocks of that expression (or the expression itself) would be common idioms.
Yes, I really like it, it's like a neat little pump that moves the string from the right side to the left. But I keep seeing people saying it's needlessly hard to read and should be split over several lines and use += 1 so everyone can understand it. (And they take issue with the assignment's value being used as the value in the while loop and treated as true or false. Though apparently this sort of thing is fine when Python does it with its walrus operator.)
I think the parent poster is incorrect; it is about precision, not about being compact. There is exactly one interpretation for how to parse and execute a computer program. The opposite is true of natural language.
Nothing wrong with that as long as the expected behavior is formally described (even if that behavior is indeterminate or undefined) and easy to look up. In fact, that's a great use for LLMs: to explain what code is doing (not just writing the code for you).
I would guard against "arguing from the extremes". I would think "on average" compact is more helpful. There are definitely situations where compactness can lead to obfuscation but where the line is depends on the literacy and astuteness of the reader in the specific subject as already pointed out by another comment. There are ways to be obtuse even in the other direction where written prose can be made sufficiently complicated to describe even the simplest things.
That's probably analogous to reading levels. So it would depend on the reading level of the intended audience. I haven't used C in almost a decade and I would have to refresh/confirm the precise orders of operations there. I do at least know that I need to refresh and after I look it up it should be fine until I forget it again. For people fluent in the language unlikely to be a big deal.
Conceivably, if there were an equivalent of "8th grade reading level" for C that forbade pointer arithmetic on the left hand side of an assignment (for example) it could be reformatted by an LLM fairly easily. Some for loop expressions would probably be significantly less elegant, though. But that seems better that converting it to English.
That might actually make a clever tooltip sort of thing--highlight a snippet of code and ask for a dumbed-down version in a popup or even an English translation to explain it. Would save me hitting the reference.
APL is another example of dense languages that (some) people like to work in. I personally have never had the time to learn it though.
> APL is another example of dense languages that (some) people like to work in.
I recently learn an array programming language called Uiua[0] and it was fun to solve problems in it (I used the advent of code's ones). Some tree operation was a bit of a pain, but you can get very concise code. And after a bit, you can recognize the symbols very easily (and the editor support was good in Emacs).
[0]: https://www.uiua.org/
Arthur Whitney writes compact code in C (and in k of course); most things fit on one A4 which is actually very nice to me as an older person. I cannot remember as much as I could (although i'm still ok) and just seeing everything I need to know for a full program on 1 page is very nice vs searching through a billion files, jump to them, read, jump back and actually mostly forgotten the 1000 steps between (I know, this refers to a typical overarchitected codebase I have to work on, but I see many of those unfortunately).
When I first read the K&R book, that syntax made perfectly sense. They are building up to it through a few chapters, if I remember correctly.
What has changed is that nowadays most developers aren't doing low-level programming anymore, where the building blocks of that expression (or the expression itself) would be common idioms.
Yes, I really like it, it's like a neat little pump that moves the string from the right side to the left. But I keep seeing people saying it's needlessly hard to read and should be split over several lines and use += 1 so everyone can understand it. (And they take issue with the assignment's value being used as the value in the while loop and treated as true or false. Though apparently this sort of thing is fine when Python does it with its walrus operator.)
That's a very good point
I'm now wondering what the Rust lang equivalent of K&R is, so I can go do that in a more modern context.
I think the parent poster is incorrect; it is about precision, not about being compact. There is exactly one interpretation for how to parse and execute a computer program. The opposite is true of natural language.
Nothing wrong with that as long as the expected behavior is formally described (even if that behavior is indeterminate or undefined) and easy to look up. In fact, that's a great use for LLMs: to explain what code is doing (not just writing the code for you).
That's confusing because of order of operations. But
is fairly obvious, so I think it gets a pass.
No, but *++d = *++s; does.
That means you have to point just before the source and destination.
(Yeah, I forgot the while: while *d++ = *s++;)