3 ms·

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 l

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.
  - dmitriid 7y ago
    True, it’s the symptom (in many, but not all cases)
- earthboundkid 7y ago
  This criticism makes no sense. If you always want an Array-like object, just always use querySelectorAll. If you don't then don't. Why is it bad that the DOM gives you a choice instead of giving you a pseudo-array that sometimes acts like an element and sometimes not? The DOM more clearly separates NodeList from Element than JQuery, and that's good! I agree that not having forEach by default was a mistake, but it's long since been solved.
  - dmitriid 7y ago
    > If you always want an Array-like object, just always use querySelectorAll `querySelectorAll` doesn’t even return an array-like object. It took w3c almost two years to add a forEach to it. It’s also so badly designed that MDN docs has a whole section oh how it behaves with unexpected results and how, quote “to restore expected behavior”. So all perceived benefits (like the separation between Element and NodeList) are badly contrived and trumped by how badly they are designed in comparison with a 15-year old library whose core API was designed by one person.
Carpetsmoker 7y ago
It's dense in the sense that there's a lot of text on the screen, and a lot of reading required. All other things being equal, I find it easier to read very short names rather than very long ones, even for code I didn't write myself. Similar in prose, if you can say it in 5 words, then why use a paragraph?
- partialrecall 7y ago
  If you can say it in five words, why say it in five letters? That's the problem with a lot of old Unix/C stuff in particular. Consider atoi. If you're not already steeped in the arcane language of unix beards, how are you meant to divine that it means "a[rray] to i[nteger]"? It's simply unreasonable. By comparison, string->number seems pretty intuitive. (That ascii-art arrow may be straying from the code-as-prose ideal, but I think it's intuitive enough to make up for that.) Of course, there is a sense in which lisp-like code can be dense while at the same time having verbose names for things. Consider this and an idiomatic C equivalent: (filter odd? '(1 2 3)) That is simultaneously intuitive and verbose. Would it be improved by changing `filter` to `fltr` or some nonsense like that? I don't think so. But even though it hasn't code-golf'd the names for things, it's doubtlessly shorter (denser) than the equivalent in idiomatic C using the mangled shortened identifiers that are par for the course in that language. Density through good abstractions is superior to density through short names and abbreviations. Could you do both? Sure. But for what marginal gain?
  - deleted 7y ago
    [deleted]
  - Carpetsmoker 7y ago
    I never claimed atoi is a good name or that the least amount of characters is always better. But str_to_int() is better than, say, convert_string_to_integer(), while still being equally clear.
    - partialrecall 7y ago
      For each their own I suppose, but I think string->number looks nicer than either. Writing str instead of string is like writing ppl instead of people. Some people seem to prefer it (https://hn.algolia.com/?query=ppl&type=comment https://hn.algolia.com/?query=ppl&type=comment), but personally I find it almost intolerable.

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.
- dmitriid 7y ago
  True, it’s the symptom (in many, but not all cases)
earthboundkid 7y ago
This criticism makes no sense. If you always want an Array-like object, just always use querySelectorAll. If you don't then don't. Why is it bad that the DOM gives you a choice instead of giving you a pseudo-array that sometimes acts like an element and sometimes not? The DOM more clearly separates NodeList from Element than JQuery, and that's good! I agree that not having forEach by default was a mistake, but it's long since been solved.
- dmitriid 7y ago
  > If you always want an Array-like object, just always use querySelectorAll `querySelectorAll` doesn’t even return an array-like object. It took w3c almost two years to add a forEach to it. It’s also so badly designed that MDN docs has a whole section oh how it behaves with unexpected results and how, quote “to restore expected behavior”. So all perceived benefits (like the separation between Element and NodeList) are badly contrived and trumped by how badly they are designed in comparison with a 15-year old library whose core API was designed by one person.

Carpetsmoker 7y ago

It's dense in the sense that there's a lot of text on the screen, and a lot of reading required. All other things being equal, I find it easier to read very short names rather than very long ones, even for code I didn't write myself. Similar in prose, if you can say it in 5 words, then why use a paragraph?

partialrecall 7y ago
If you can say it in five words, why say it in five letters? That's the problem with a lot of old Unix/C stuff in particular. Consider atoi. If you're not already steeped in the arcane language of unix beards, how are you meant to divine that it means "a[rray] to i[nteger]"? It's simply unreasonable. By comparison, string->number seems pretty intuitive. (That ascii-art arrow may be straying from the code-as-prose ideal, but I think it's intuitive enough to make up for that.) Of course, there is a sense in which lisp-like code can be dense while at the same time having verbose names for things. Consider this and an idiomatic C equivalent: (filter odd? '(1 2 3)) That is simultaneously intuitive and verbose. Would it be improved by changing `filter` to `fltr` or some nonsense like that? I don't think so. But even though it hasn't code-golf'd the names for things, it's doubtlessly shorter (denser) than the equivalent in idiomatic C using the mangled shortened identifiers that are par for the course in that language. Density through good abstractions is superior to density through short names and abbreviations. Could you do both? Sure. But for what marginal gain?
- deleted 7y ago
  [deleted]
- Carpetsmoker 7y ago
  I never claimed atoi is a good name or that the least amount of characters is always better. But str_to_int() is better than, say, convert_string_to_integer(), while still being equally clear.
  - partialrecall 7y ago
    For each their own I suppose, but I think string->number looks nicer than either. Writing str instead of string is like writing ppl instead of people. Some people seem to prefer it (https://hn.algolia.com/?query=ppl&type=comment https://hn.algolia.com/?query=ppl&type=comment), but personally I find it almost intolerable.