Kill hashtables, get shorter code. • Hacker News Board

Re: Kill hashtables, get shorter code.

#11

Post by herdrick » Mon, Jul 19, 2010, 8:59 PM UTC

nostrademons wrote: post #7

This is actually a pretty common technique in Haskell. If you look at the Alex lexical analyzer generator's source code, it represents CharSets as functions from Char -> Bool: they return true if the character is in the charset or false if it is not. Internally, they work just like the article describes: the union of two CharSets doesn't actually enumerate every possible character in the set, it just calls the two Ch…

Regarding Haskell, yeah I thought as much. When writing this code I thought, "This would all be better, or maybe nearly automatic, in a purely functional language".

Regarding Arc, there's still a distinction, since as you point out you can't enumerate the domain of a function like you can the keys of a hashtable. (And you also "call" a hashtable in Clojure.)

Re: Kill hashtables, get shorter code.

#12

Post by jfager » Mon, Jul 19, 2010, 9:00 PM UTC

One of my favorite features of Coffeescript (and other languages) is destructuring assignment, which lets you use pattern matching over an object to pull out values from nested structures. It's way more useful than this proposal: brief when you want brevity, but you still get the full object returned from the method when you need to debug, and apis don't have to be adapted or rewritten with the usage pattern in mind.

Re: Kill hashtables, get shorter code.

#13

Post by herdrick » Mon, Jul 19, 2010, 9:02 PM UTC

ajg1977 wrote: post #4

"But it’s hard to argue with brevity." No, it's really not. Brevity != clarity. Clarity is hard to argue with, brevity is not. By his own admission this new code is harder to write and harder to debug. It's interesting to me that in the article the author dismisses any performance impact of his changes because "we can profile and deal with it latter", but fails to realize that by attempting to reduce the length of hi…

That's a pretty old debate. I think brevity does a lot for clarity, and the more you work at making your code brief the better you'll be at reading brief code.

Of course if other people are reading your code then you should consider what current programming practice is. But the current practice in Clojure is, for cultural reasons, to make things really succinct. So you can assume those reading your code are ok with that.

Re: Kill hashtables, get shorter code.

#14

Post by swannodette » Mon, Jul 19, 2010, 9:19 PM UTC

jfager wrote: post #12

One of my favorite features of Coffeescript (and other languages) is destructuring assignment, which lets you use pattern matching over an object to pull out values from nested structures. It's way more useful than this proposal: brief when you want brevity, but you still get the full object returned from the method when you need to debug, and apis don't have to be adapted or rewritten with the usage pattern in mind.

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

Re: Kill hashtables, get shorter code.

#15

Post by mkramlich » Mon, Jul 19, 2010, 9:24 PM UTC

cageface wrote: post #9

Groxx wrote: post #2

In summary: instead of getting a hash back from a function and pulling out the (single!) desired key, pass the key to the function and get the value back directly. A limited-use but handy technique, and they're not arguing for dogmatic adherence to the rule. Something to keep in mind, but don't go re-wiring old code unless you're bored. You could also code the function so if you pass no key-args, you get the whole ha…

I hate it when I see code like that. It's so much harder to maintain. You've saved two lines of code but made the intent at least 10x harder to infer. I've been wading through the Rails codebase lately and this kind of thing gets to be annoying fast, particularly when you're trying to debug a function that's littered with these kinds of expressions, often nested. Honestly it's this kind of thing that makes me wonder…

pythonistas: we do

Re: Kill hashtables, get shorter code.

#16

Post by jfager » Mon, Jul 19, 2010, 9:44 PM UTC

swannodette wrote: post #14

jfager wrote: post #12

One of my favorite features of Coffeescript (and other languages) is destructuring assignment, which lets you use pattern matching over an object to pull out values from nested structures. It's way more useful than this proposal: brief when you want brevity, but you still get the full object returned from the method when you need to debug, and apis don't have to be adapted or rewritten with the usage pattern in mind.

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.

Re: Kill hashtables, get shorter code.

#17

Post by thaumaturgy » Mon, Jul 19, 2010, 9:51 PM UTC

Aside from the maintainability of this technique, it sounds as though it's taking one of the least efficient routes towards doing its job. (I'm not a LISPer, and although I should stop and think about the code there until I grok it before commenting, I'm looking for a lazier answer.)

So, let's say we have two documents, and want to calculate their distance. Each document has 2,000 words. We can either scan each word in each document once, counting them in memory and processing a total of 4,000 words, or we can start with a word in one document, scan both documents for all occurrences of that word, move on to the next word, scan both documents for all occurrences of that word, and so on, for a total of ~N! scans. Given a choice between a really efficient function running in factorial time, or a longer, uglier function running in constant time ... I'd kind of prefer the latter.

Am I way off the mark here? Is there something I misunderstood?

Re: Kill hashtables, get shorter code.

#18

Post by herdrick » Mon, Jul 19, 2010, 10:15 PM UTC

amalcon wrote: post #6

When he talks about performance, he mentions that memoization allows performance to not suffer very much, but what he doesn't mention that almost the entire performance gain comes from memoizing frequencies ... which stores the hashtables anyway; it just does it behind the scenes. This is fine for CPU usage, but it does have a significant storage penalty depending on the characteristics of the input. There's some low…

Without profiling it I'd guess it's memoizing the function that does the disk i/o that makes the biggest difference.

Re: Kill hashtables, get shorter code.

#19

Post by jimbokun » Mon, Jul 19, 2010, 10:17 PM UTC

"That sort of sucks. Further, it makes some functions, like euclidean, hopelessly non-general, since euclidean now has to know what function to call to get a frequency [3]."

No. You can just pass in the appropriate, memoized frequency function to call. In the new code, that just means that "freq" would be an additional argument to euclidean, instead of a globally defined function.

Re: Kill hashtables, get shorter code.

#20

Post by herdrick » Mon, Jul 19, 2010, 10:22 PM UTC

thaumaturgy wrote: post #17

Aside from the maintainability of this technique, it sounds as though it's taking one of the least efficient routes towards doing its job. (I'm not a LISPer, and although I should stop and think about the code there until I grok it before commenting, I'm looking for a lazier answer.) So, let's say we have two documents, and want to calculate their distance. Each document has 2,000 words. We can either scan each word…

Sorry, I don't understand what you're asking. The way it works now is: each document is read and summarized into a bunch of word frequencies, once. It looks like each is being read many times, but since I'm memoizing, it only happens once. Is that helpful or are you suggesting something else?