4 ms·

The problem isn't about typing it, it's about readability, when the length starts to interfere with reading comprehension for maintainability. With more than t

The problem isn't about typing it, it's about readability, when the length starts to interfere with reading comprehension for maintainability. With more than three or four words, the brain can't easily tokenize it into a single unit or distinguish between similar phrases, and it starts to take a lot of extra mental processing time to scan and parse it all.

klibertp 3y ago
You can cheat with underscores, though. Said another way, you can trick your brain into tokenizing the looooong input by using, as a convention, some kinds of separators. In Elisp, you'll see names-that::have-_a_field_name+in-it. (Because of lack of namespacing and loose syntax rules for identifiers). Even if you do, though, a bad long name is still bad (one with 50% words to be removed without losing the meaning). Because you loose time on sifting through irrelevant or redundant information. At some point, you'll remember and learn to recognize the whole symbol, or a distinct part of it. Until that happens, though, you need to actually read, not just look, to know what's going on. It's slow, like a cache miss, and can be slowed down further by both not enough information, and too much information.
- godelski 3y ago
  You can, but why? There's a reason a lot of people prefer two column formats when writing as opposed to single. It is easier to grab a chunk. Your brain is now able to pick up the full width of a page without moving your eyes. Two column lets you change movements to a vertical scan rather than rasterization (left to right, move a line down, repeat). It literally requires more muscles and frankly, many people will accidentally move vertically when trying to move horizontally. I'm sure I'm not the only one who reads a line and then when moving down to the next line accidentally starts on the wrong new line. Horizontal spacing, be in variable names, code line length, etc is about the receptive field of your vision, which is circular in nature. Recognize how humans see and exploit that nature to maximize readability. This reduces mistakes and errors both when writing and reading.
  - klibertp 3y ago
    In Elisp, there's no other way, because you cannot create private symbols, everything is public and global. What's even worse is that in the case of name clash, the named entity (variable, function, macro) gets silently replaced with the new definition. So, without a convention of, roughly: package-name--private-function package-name-public-function package-name-class-name-_field_name You're playing with fire. But that's an extreme edge case. For other cases, I agree completely. Indeed, the only meaningful consideration when talking about readability is the mechanics of eye movement. You can get used to reading almost anything, but you can't change how your eye works. Line length limits are important also because of this, not only because of better diffs. I also dislike spamming newlines everywhere, as if the line length limit was 20 chars. The newline suggests, to me at least, that something was done and we're moving on. It's a weak signal, but convenient. Now, when you split every single object.call1().call2().callN() into multiple lines, it's actually harder to see the whole thing (you can't see much more than a few lines at the same time) and it makes that signal disappear in the noise. In any case - all talk about "readability" should start, and more importantly stop, at physical and mechanical limitations of human vision. Everything else is just familiarity with a particular notation or style.

klibertp 3y ago

You can cheat with underscores, though. Said another way, you can trick your brain into tokenizing the looooong input by using, as a convention, some kinds of separators. In Elisp, you'll see names-that::have-_a_field_name+in-it. (Because of lack of namespacing and loose syntax rules for identifiers). Even if you do, though, a bad long name is still bad (one with 50% words to be removed without losing the meaning). Because you loose time on sifting through irrelevant or redundant information. At some point, you'll remember and learn to recognize the whole symbol, or a distinct part of it. Until that happens, though, you need to actually read, not just look, to know what's going on. It's slow, like a cache miss, and can be slowed down further by both not enough information, and too much information.

godelski 3y ago
You can, but why? There's a reason a lot of people prefer two column formats when writing as opposed to single. It is easier to grab a chunk. Your brain is now able to pick up the full width of a page without moving your eyes. Two column lets you change movements to a vertical scan rather than rasterization (left to right, move a line down, repeat). It literally requires more muscles and frankly, many people will accidentally move vertically when trying to move horizontally. I'm sure I'm not the only one who reads a line and then when moving down to the next line accidentally starts on the wrong new line. Horizontal spacing, be in variable names, code line length, etc is about the receptive field of your vision, which is circular in nature. Recognize how humans see and exploit that nature to maximize readability. This reduces mistakes and errors both when writing and reading.
- klibertp 3y ago
  In Elisp, there's no other way, because you cannot create private symbols, everything is public and global. What's even worse is that in the case of name clash, the named entity (variable, function, macro) gets silently replaced with the new definition. So, without a convention of, roughly: package-name--private-function package-name-public-function package-name-class-name-_field_name You're playing with fire. But that's an extreme edge case. For other cases, I agree completely. Indeed, the only meaningful consideration when talking about readability is the mechanics of eye movement. You can get used to reading almost anything, but you can't change how your eye works. Line length limits are important also because of this, not only because of better diffs. I also dislike spamming newlines everywhere, as if the line length limit was 20 chars. The newline suggests, to me at least, that something was done and we're moving on. It's a weak signal, but convenient. Now, when you split every single object.call1().call2().callN() into multiple lines, it's actually harder to see the whole thing (you can't see much more than a few lines at the same time) and it makes that signal disappear in the noise. In any case - all talk about "readability" should start, and more importantly stop, at physical and mechanical limitations of human vision. Everything else is just familiarity with a particular notation or style.