Kill hashtables, get shorter code. • Hacker News Board

Re: Kill hashtables, get shorter code.

#31

Post by gwern » Tue, Jul 20, 2010, 4:21 AM UTC

gnaritas wrote: post #30

gruseom wrote: post #27

Earlier quoted context omitted.

I disagree in two senses. First, it's a poor measurement of brevity that depends on identifier length. Even LOC (surely the gold standard of bad metrics) doesn't depend that much on that. Second and more interestingly, as code gets more concise, long explicit identifiers begin to detract from readability. Well-written concise code discloses valuable information just by the shape it takes. With experience reading such…

Then length of an identifier name should be proportional to it's scope. But specifically I'm talking about non descriptive function names shortened for brevity: map, filter, join, split are better names than mp,flt,jn,sp no matter how often you use them. It takes less effort to read a word than to trip over an unfamiliar abbreviation, so while the code may be more concise, it is less clear. If your code relies upon t…

All words are arbitrary collections of letters. map, filter, join, and split - for at least 2 of those, the most common meaning is so far removed from the programming meaning that they might as well be something shorter like 'mp'.

Re: Kill hashtables, get shorter code.

#32

Post by gnaritas » Tue, Jul 20, 2010, 4:49 AM UTC

gwern wrote: post #31

gnaritas wrote: post #30

Earlier quoted context omitted.

Then length of an identifier name should be proportional to it's scope. But specifically I'm talking about non descriptive function names shortened for brevity: map, filter, join, split are better names than mp,flt,jn,sp no matter how often you use them. It takes less effort to read a word than to trip over an unfamiliar abbreviation, so while the code may be more concise, it is less clear. If your code relies upon t…

All words are arbitrary collections of letters. map, filter, join, and split - for at least 2 of those, the most common meaning is so far removed from the programming meaning that they might as well be something shorter like 'mp'.

That might be true if your users were a blank slate, but they aren't, they have existing language skills and it's easier to remember words from ordinary language than it is some library writers abbreviation.

Nor all all words arbitrary collections of letters, most words have some form of alternating consonant vowel structure that makes them easy to speak and remember. Write a program that just arbitrarily combines letters and I doubt you'll get much out that looks like words; there are lots of patterns in how we create words, it isn't arbitrary. If you can't read your code aloud and sound reasonable then you've probably inappropriately abbreviated your identifiers.

Map is by far a better name than mp; there is no shortage of vowels; map is already a short identifier and a real word.

Re: Kill hashtables, get shorter code.

#33

Post by billmcneale » Tue, Jul 20, 2010, 5:17 AM UTC

jfager wrote: post #16

swannodette wrote: post #14

Earlier quoted context omitted.

Coffeescript is certainly cool, but Clojure has sophisticated destructuring assignment as well.

The point was not "Coffeescript is better than Clojure", it was "destructuring assignment (like in Coffeescript, for instance) is a better solution than the one proposed in the post". If Clojure has sophisticated destructuring assignment, awesome. Use that instead.

Destructuring is a pretty dangerous practice because it completely destroys encapsulation.

Re: Kill hashtables, get shorter code.

#34

Post by jrockway » Tue, Jul 20, 2010, 5:45 AM UTC

Yup, that's what abstraction does for you. The less policy the caller has to implicitly understand, the more flexibility you have in the underlying representation, and the less code you have to write.

Re: Kill hashtables, get shorter code.

#35

Post by yason » Tue, Jul 20, 2010, 7:20 AM UTC

I can't remember which philosopher it was but he said something like: "If you have something that you can actually express, you can then also express it concisely."

Re: Kill hashtables, get shorter code.

#36

Post by gruseom » Tue, Jul 20, 2010, 9:15 AM UTC

gnaritas wrote: post #32

gwern wrote: post #31

Earlier quoted context omitted.

All words are arbitrary collections of letters. map, filter, join, and split - for at least 2 of those, the most common meaning is so far removed from the programming meaning that they might as well be something shorter like 'mp'.

That might be true if your users were a blank slate, but they aren't, they have existing language skills and it's easier to remember words from ordinary language than it is some library writers abbreviation. Nor all all words arbitrary collections of letters, most words have some form of alternating consonant vowel structure that makes them easy to speak and remember. Write a program that just arbitrarily combines le…

I dunno. Exceptional though they may be, I can imagine situations in which it would be a net gain to write mp rather than map. I don't think "readability" should only mean "readable by someone who is unfamiliar with the program's conventions and is encountering it for the very first time". It does mean that, but it should also encompass "readable by someone who is working with the code repeatedly, as if it were clay". Devices (like long names) that help you read the code de novo can get in the way after a while. Map itself doesn't mean what it says; it's a convention, one I bet was introduced for brevity. I think it's reasonable for languages and programs to adhere to conventions and ask the reader for patience while first working with them, especially if the notation has been crafted to maximize the intelligibility of the code over the long haul.

One doesn't just sit and speed-read math in a single pass. Nor poetry. Good programs have that kind of density and deserve the same consideration; they are not newspaper columns. The trouble with the shallow notion of readability that says "I should be able to random-access any line of code and understand it right away" is that it results in less intelligible whole programs, which is a net loss of readability and of other things as well.

I wish more good programmers understood this. The bad ones we can write off, but too many good ones have been schooled to focus overly on the line-of-code. If you have a million lines of code, it doesn't much matter how readable an individual line is; nobody's going to be able to read the whole thing. What we should be striving for is to produce an equally functional program with orders of magnitude less code (which would automatically be a more functional program). This requires a quite different notion of readability.

Re: Kill hashtables, get shorter code.

#37

Post by jfager » Tue, Jul 20, 2010, 11:44 AM UTC

swannodette wrote: post #28

jfager wrote: post #16

Earlier quoted context omitted.

The point was not "Coffeescript is better than Clojure", it was "destructuring assignment (like in Coffeescript, for instance) is a better solution than the one proposed in the post". If Clojure has sophisticated destructuring assignment, awesome. Use that instead.

I suppose I failed to see how destructuring assignment on hash-maps accomplishes anything interesting at all related to the post. The post eliminates hash-maps altogether.

It eliminates them from the api, but how does memoize work? There are still hashtables, you just never get a hook on them.

I'm just saying that I prefer having that hook, and that destructuring assignment lets me do so with brevity and clarity.

Re: Kill hashtables, get shorter code.

#38

Post by gnaritas » Wed, Jul 21, 2010, 2:33 PM UTC

gruseom wrote: post #36

gnaritas wrote: post #32

Earlier quoted context omitted.

That might be true if your users were a blank slate, but they aren't, they have existing language skills and it's easier to remember words from ordinary language than it is some library writers abbreviation. Nor all all words arbitrary collections of letters, most words have some form of alternating consonant vowel structure that makes them easy to speak and remember. Write a program that just arbitrarily combines le…

I dunno. Exceptional though they may be, I can imagine situations in which it would be a net gain to write mp rather than map . I don't think "readability" should only mean "readable by someone who is unfamiliar with the program's conventions and is encountering it for the very first time". It does mean that, but it should also encompass "readable by someone who is working with the code repeatedly, as if it were clay…

Reducing the size of a program by an order of magnitude requires better abstractions, not shorter selector names. I'm not saying names have to be long, I'm saying they should be whole words, not abbreviations of words. The English language is full of whole words that are still very short.

Math notation is horrendous by the way, too many implicit assumptions about the readers background knowledge. See what Gerry Sussman has to say about it. The great thing about code is it forces one to be explicit, which forces one to actually understand and learn.

Re: Kill hashtables, get shorter code.

#39

Post by herdrick » Wed, Jul 21, 2010, 5:34 PM UTC

gnaritas wrote: post #32

gwern wrote: post #31

Earlier quoted context omitted.

All words are arbitrary collections of letters. map, filter, join, and split - for at least 2 of those, the most common meaning is so far removed from the programming meaning that they might as well be something shorter like 'mp'.

That might be true if your users were a blank slate, but they aren't, they have existing language skills and it's easier to remember words from ordinary language than it is some library writers abbreviation. Nor all all words arbitrary collections of letters, most words have some form of alternating consonant vowel structure that makes them easy to speak and remember. Write a program that just arbitrarily combines le…

map is already a short identifier and a real word

This is heresy, but I actually think it might be better if it weren't a real word. I find I benefit from inventing names for functions or data abtractions. It helps to clear the mind of what those things might be.

Plus making map into mp or whatever makes it much more googleable. And don't get me started on Clojure having map and a Map.

Re: Kill hashtables, get shorter code.

#40

Post by gruseom » Wed, Jul 21, 2010, 5:53 PM UTC

herdrick wrote: post #39

gnaritas wrote: post #32

Earlier quoted context omitted.

That might be true if your users were a blank slate, but they aren't, they have existing language skills and it's easier to remember words from ordinary language than it is some library writers abbreviation. Nor all all words arbitrary collections of letters, most words have some form of alternating consonant vowel structure that makes them easy to speak and remember. Write a program that just arbitrarily combines le…

map is already a short identifier and a real word This is heresy, but I actually think it might be better if it weren't a real word. I find I benefit from inventing names for functions or data abtractions. It helps to clear the mind of what those things might be. Plus making map into mp or whatever makes it much more googleable. And don't get me started on Clojure having map and a Map.

Concur on both. It sounds like we're in the same tiny statistical bucket.

By the way, there is a variant of "googleable" that I find to be a valuable property for names in a codebase, and that is "greppable". I try to make sure that the name of any important concept is a unique string in the program, so a simple grep will yield all the places it occurs. I'll even rename things that aren't as important, if their name includes this string, to preserve said uniqueness. (And no, the 'find usage' feature of IDEs doesn't come close to satisfying this need, since a concept can appear in many ways that don't yield to code analysis, such as comments.)