3 ms·

Personally I don't see the problem with code that's verbose in this manner. If the right names for things are chosen then the code written with those names wi

Personally I don't see the problem with code that's verbose in this manner. If the right names for things are chosen then the code written with those names will read like prose, which makes it pleasant for a programmer and approachable for a self-styled non-programmer. And it's not like it's much more typing, what with modern completion systems in modern text editors... One of the reasons I like lisp-like languages more than the rest is because hyphen-separated-symbols are a lot easier to read than camelCase, which feels cramped by comparison. (underscore_separated_words is an improvement over camelCase, but for some reason people seem to shy away from it. In any event I think hyphen-separated is superior, since hyphens are used to conjoin words in English prose, while underlines typically aren't.)

Carpetsmoker 7y ago
I find long names like this much harder to read because the entire text/code is so much more dense, and it really adds up quite fast if all function/variables are dense. It gives a "wall of text" effect. It reminds me of reading 17th century dense English. I don't see how query or select is any less descriptive than querySelector. I find that names are rarely all that useful anyway, since you can't capture the full effect of a function in a name in most cases. I once named a method mkdir() and then someone commented that it was "obscure", so it got renamed createDirectory(), then someone commented that it was actually creating all intermediate directories, so it became createDirectoryTree(). This still doesn't really communicate that it won't error if the directory already exists, so I commented it should really be createDirectoryTreeOrDoNothing().
- partialrecall 7y ago
  I'm not sure what you mean by dense. If two symbols mean the same thing (both reference the same procedure) but one is longer than the other, then surely the longer one is less dense, no? In physics, density is a measure of mass / volume, so in programming density would be a measure of meaning / code length `mkdir` is immediately obvious to someone like you or me that has a background in dealing with legacy system design (namely, any Linux/Unix/BSD/GNU system that all derives from early 70s design ethos (or hardware limitations..)) but to somebody who's not already steeped in this tradition, it's basically a bizarre incantation. And mkdir is far from the worse of it; once you learn what it means it's easy to create a mnemonic mapping between `mkdir` and "m[a]k[e] dir[ectory]". But what about something like `ln`? Obviously that's "natural logorithm", everybody learns that in highschool. Wait no, it's not that at all. It's "[make] l[i]n[k]" Frankly, that's crap. Contrast with `make-file-or-directory-link` from racket. It means the same thing but it's more than 10x as long (less dense) and there is simply no way you could mistake that for a natural log function.
  - partialrecall 7y ago
    Meant as an edit: I don't think the problem with 17th century prose is density either. Rather, it's archaic vocabulary, idioms, and grammar. I've recently been reading through an anthology of English renaissance drama and my impression is that once you become acclimatized to the common archaic vocabulary and grammar, the idioms remain as biggest impediment to understanding. Consider: > "Art thou in thy wits? I tell thee I must have a pair of shoes; dost thou mark me? A pair of shoes, two shoes, made by this very shoe, this same shoe, against tomorrow morning by four o'clock. Dost understand me? Canst thou do't? He's asking for a pair of shoes, and questioning whether his request is understood. It's not a particularly complex or information dense paragraph, but it could be hard to understand if all of that archaic vocabulary is obscure to you. In many ways, this makes it very similar to your average bash script. Saying something simple, but made to seem complicated by archaic terminology.
  - dmitriid 7y ago
    In case of `query` you’d have a uniform API from which all other APIs would flow. That’s what $ essentially is. Instead, browser have two incompatible APIs: `querySelector` to retrieve one item only, and `querySelectorAll` to retrieve multiple items. On top of that, jQuery always returns an array-like object. `querySelectorAll` returns a NodeList that is so poorly designed that it didn’t have a `.forEach` for two years or so, and you’re still better of doing an `Array.from` on it for the sake of consistency and sanity. For every thing that jQuery got right, browsers got 10 things wrong. For every thing that jQuery got wrong, browsers got 100 things wrong. It took browsers 7 years to implement querySelector/querySelectorAll after jQuery showed it’s possible and useful. And they still got it wrong. 13 years after jQuery debuted DOM APIs are still a mishmash of extremely poorly designed functions that are unnecessarily verbose and error prone.
    - partialrecall 7y ago
      Obviously a poorly designed API is inexcusable, but I don't think the verbosity of function or variable names is the cause of that.
- lalos 7y ago
  Interesting naming problem what about EnsureDirectoryTree() or EnsureDirectoryExists()? This name kinda implies that you only care about success and not if it has to create it or not.

Carpetsmoker 7y ago

I find long names like this much harder to read because the entire text/code is so much more dense, and it really adds up quite fast if all function/variables are dense. It gives a "wall of text" effect. It reminds me of reading 17th century dense English. I don't see how query or select is any less descriptive than querySelector. I find that names are rarely all that useful anyway, since you can't capture the full effect of a function in a name in most cases. I once named a method mkdir() and then someone commented that it was "obscure", so it got renamed createDirectory(), then someone commented that it was actually creating all intermediate directories, so it became createDirectoryTree(). This still doesn't really communicate that it won't error if the directory already exists, so I commented it should really be createDirectoryTreeOrDoNothing().

partialrecall 7y ago
I'm not sure what you mean by dense. If two symbols mean the same thing (both reference the same procedure) but one is longer than the other, then surely the longer one is less dense, no? In physics, density is a measure of mass / volume, so in programming density would be a measure of meaning / code length `mkdir` is immediately obvious to someone like you or me that has a background in dealing with legacy system design (namely, any Linux/Unix/BSD/GNU system that all derives from early 70s design ethos (or hardware limitations..)) but to somebody who's not already steeped in this tradition, it's basically a bizarre incantation. And mkdir is far from the worse of it; once you learn what it means it's easy to create a mnemonic mapping between `mkdir` and "m[a]k[e] dir[ectory]". But what about something like `ln`? Obviously that's "natural logorithm", everybody learns that in highschool. Wait no, it's not that at all. It's "[make] l[i]n[k]" Frankly, that's crap. Contrast with `make-file-or-directory-link` from racket. It means the same thing but it's more than 10x as long (less dense) and there is simply no way you could mistake that for a natural log function.
- partialrecall 7y ago
  Meant as an edit: I don't think the problem with 17th century prose is density either. Rather, it's archaic vocabulary, idioms, and grammar. I've recently been reading through an anthology of English renaissance drama and my impression is that once you become acclimatized to the common archaic vocabulary and grammar, the idioms remain as biggest impediment to understanding. Consider: > "Art thou in thy wits? I tell thee I must have a pair of shoes; dost thou mark me? A pair of shoes, two shoes, made by this very shoe, this same shoe, against tomorrow morning by four o'clock. Dost understand me? Canst thou do't? He's asking for a pair of shoes, and questioning whether his request is understood. It's not a particularly complex or information dense paragraph, but it could be hard to understand if all of that archaic vocabulary is obscure to you. In many ways, this makes it very similar to your average bash script. Saying something simple, but made to seem complicated by archaic terminology.
- dmitriid 7y ago
  In case of `query` you’d have a uniform API from which all other APIs would flow. That’s what $ essentially is. Instead, browser have two incompatible APIs: `querySelector` to retrieve one item only, and `querySelectorAll` to retrieve multiple items. On top of that, jQuery always returns an array-like object. `querySelectorAll` returns a NodeList that is so poorly designed that it didn’t have a `.forEach` for two years or so, and you’re still better of doing an `Array.from` on it for the sake of consistency and sanity. For every thing that jQuery got right, browsers got 10 things wrong. For every thing that jQuery got wrong, browsers got 100 things wrong. It took browsers 7 years to implement querySelector/querySelectorAll after jQuery showed it’s possible and useful. And they still got it wrong. 13 years after jQuery debuted DOM APIs are still a mishmash of extremely poorly designed functions that are unnecessarily verbose and error prone.
  - partialrecall 7y ago
    Obviously a poorly designed API is inexcusable, but I don't think the verbosity of function or variable names is the cause of that.
lalos 7y ago
Interesting naming problem what about EnsureDirectoryTree() or EnsureDirectoryExists()? This name kinda implies that you only care about success and not if it has to create it or not.