Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

2 is a code smell

tech.puredanger.com

Post reply on HN
Print view View original

11–20 of 33 posts

Re: 2 is a code smell

#11

Post by fhars »

You might with more justification claim that varargs methods are a code smell, as they conflate the algebraic structure of the elements and the operations on them (for example that they form a semigroup with respect to the operation at hand) with the traversal over a collection of elements, thereby grossly violationg the principle of separation of concerns. After all, many interesting algebraic structures are defined in terms of binary operators. If you separate operations between elements and traversal over collections, you can fold any operation over any traversable entity, with just #operations + #traversables functions, instead of #operations * #traversables functions. (You have a similar structure in languages from the APL family, where operators are all unary or binary, and traversal is specified by adverbs to the operators.)

This does of course not apply if you use a deliberately restricted language that has just one type of collection traversal, in that case you are better off with varargs, as n*1 < n+1.

Re: 2 is a code smell

#12

Post by narain »

KeithMajhor wrote: post #6

What about sub-vectors? That smells like a 2 to me... I'd rather call fold or foldr myself and KNOW how it handled more than 2 arguments. I'd rather do it for add-vectors too, just so it was consistent. You have to define primitives somewhere. Even if what you call elsewhere is some fluffy handle-everything function. At the very least, I wouldn't call it a smell.

I think there's a distinction that needs to be drawn here between data that only has two of something, and functions that only take two arguments. In the former case, you limit the things you can represent and generalize to, and everybody agrees that's not good. In the latter, though, there is the standard notion of folding that naturally extends your binary function to arbitrarily many arguments. In fact, I'd agree with what I think you're suggesting: it's better to define a binary function and let fold generalize it, than to have to roll your own multi-argument function every time, because then you and anyone else looking at it can easily know how it behaves. In other words, I think he got carried away by the end of the article, and his last "improvement" isn't an improvement at all.

(Of course, the objection to data having only two things doesn't hold either if it's a recursive data type -- cons lists, binary trees, etc... -- but you know what I mean.)

Re: 2 is a code smell

#13

Post by humbledrone »

heyrhett wrote: post #7

If a co-worker told me that my function was "code smell" because it took 2 arguments, I would tell him that he needs more important things to worry about.

If a coworker told me the same thing, I'd ask, "Why?" If they gave me the explanation given in the article, I'd say, "Thank you, that's a nice little improvement. The code is simpler AND more general." Then, I'd go on working, a little bit better of a programmer for it. If I repeated this ritual a few hundred times, I might actually become a halfway-decent programmer. In this field, details matter.

Re: 2 is a code smell

#15

Post by lyudmil »

I try to be very pedantic about having the most terse, yet readable code possible in my application. This probably means that if, for now, I only need to know how to add two vectors, I will only include a function that adds two vectors and no more. I do realize there's hidden structure there waiting to be exposed, but programming is largely about elaborating the useful structures. If the author's examples had been in Java instead of Clojure, a lot of us would've been complaining that he's over-designing.

I do think the author has a point, but to me the logical complexity progression for a piece of code is:

1. Make it work in the "1" case.

2. If necessary, make it work in the "2" case.

3. If necessary, make it work in the "n" case (n variable).

I find this particularly useful for larger decisions: I can make this work right now if I add this tiny little wart? No problem. Another thing came up and a similar wart is required? Ok, I guess. A third? Time to find the structure that my code is telling me about and refactor to expose it.

Re: 2 is a code smell

#16

Post by humbledrone »

lyudmil wrote: post #15

I try to be very pedantic about having the most terse, yet readable code possible in my application. This probably means that if, for now, I only need to know how to add two vectors, I will only include a function that adds two vectors and no more. I do realize there's hidden structure there waiting to be exposed, but programming is largely about elaborating the useful structures. If the author's examples had been in…

The final (varargs) add-vectors function in the OP is clearly (at least to me) more terse and readable than the original (2 arg) one. I've only written a couple thousand lines of Clojure to date, but code like that already just looks right. The varargs version has less possibilities for errors; the 2 arg version allows for several permutations of first/second to be written incorrectly, or the wrong va/vb used.

Re: 2 is a code smell

#17

Post by MostAwesomeDude »

Since we've already descended into anecdotal territory, lemme drop an anecdote. I had a dot-product function which turned out to be a hotspot in some numerical code. The original function looked something like:

    def dot(v1, v2):
        return sum(i * j for i, j in zip(v1, v2))
Very functional, very pretty, very straightforward. But it was slow, both in CPython and PyPy. A bit of bytecode analysis and profiling later, we realized that unrolling would be faster by several orders of magnitude. So I checked this in:

    def dot2(u, v):
        return u[0] * v[0] + u[1] * v[1]
    def dot3(u, v):
        return u[0] * v[0] + u[1] * v[1] + u[2] * v[2]
And the bottleneck went away. From the Zen of Python: "Practicality beats purity."

Re: 2 is a code smell

#18

Post by puredanger »

brlewis wrote: post #10
Sharlin wrote: post #9

This is pretty much an instance of the good old "zero, one, infinity" rule. http://www.catb.org/jargon/html/Z/Zero-One-Infinity-Rule.htm...

This article restricts itself to a context where following "zero, one, infinity" results in simpler, more concise code. This is a good restriction. In general, following "zero, one, infinity" will often put you at odds with YAGNI.

My experience with Clojure has been that sticking to N is so harmonious with the Clojure way that it is simpler and yields more flexible code.

If the code is simpler then I don't see how YAGNI comes into play. Why would you do something that is both more complicated and less amenable to future needs?

Re: 2 is a code smell

#19

Post by ZitchDog »

MostAwesomeDude wrote: post #17

Since we've already descended into anecdotal territory, lemme drop an anecdote. I had a dot-product function which turned out to be a hotspot in some numerical code. The original function looked something like: def dot(v1, v2): return sum(i * j for i, j in zip(v1, v2)) Very functional, very pretty, very straightforward. But it was slow, both in CPython and PyPy. A bit of bytecode analysis and profiling later, we real…

Any reason you didn't just use NumPy?

http://docs.scipy.org/doc/numpy/reference/generated/numpy.do...

Re: 2 is a code smell

#20

Post by puredanger »

MostAwesomeDude wrote: post #17

Since we've already descended into anecdotal territory, lemme drop an anecdote. I had a dot-product function which turned out to be a hotspot in some numerical code. The original function looked something like: def dot(v1, v2): return sum(i * j for i, j in zip(v1, v2)) Very functional, very pretty, very straightforward. But it was slow, both in CPython and PyPy. A bit of bytecode analysis and profiling later, we real…

If you spend any time in the Clojure community, I think you'll come to an appreciation that practicality and performance are key principles of its design. The goal is to obtain both high levels of abstraction and performance.
Post reply on HN