Comment by jblow | Hacker News Reader

Comment by jblow | Hacker News Reader

Parent Full thread

no more than 3 arguments for your functions

It is hard for me to believe that this is a piece of style advice that anyone writing serious software would follow.

If you need to do something wherein the basic task requires 8 arguments' worth of information (which happens A LOT) then trying to factor that into 3-argument pieces is going to give you something Byzantine that is probably also buggy (and it could get extremely heinous, in a way determined by the data dependencies internal to the procedure you are factoring). And if you somehow succeed at all this, congratulations, you just did a bunch of engineering that did not improve the functionality of your software in any way. (In fact it probably made the software take longer to compile).

If doing a certain job needs 8 pieces of information, it needs 8 pieces of information. It doesn't help anyone to try to break that up.

Similarly with this:

keep the complexity of the functions as low as possible

Not really. If you are just factoring some block of complexity in to 4 blocks of less-complexity, well, now you have the same amount of complexity as the original code, plus the complexity of the call graph, and the fact that the person who comes along to read the code will not be able to clearly see the control flow.

There definitely are many cases when factoring a procedure into simpler things is beneficial. But to claim that it's a good idea all the time, or even half the time, is I think mistaken.

A guideline like "three arguments to a function" says nothing about the type of those three arguments. You are right that there are many jobs that require 8 or more pieces of information, but often those parameters can be grouped into structures which each hold multiple pieces of information. The point is not to create types for every function just to hold their arguments, but that well-thought-out data abstraction can simplify things by factoring data into named structures that are used in multiple functions. For example you could have a drawRectangle function which takes four parameters (x1, y1, x2, y2) of some primitive numeric type, or you could create a Point type and use just two of those. This improves clarity because it is obvious just from the signature of drawRectangle(Point a, Point b) that you are specifying the endpoints of the rectangle, whereas four numeric arguments could mean (x1, y1, x2, y2) or (x, y, width, height).

(a) This kind of thing in many cases is just tedious busywork that you are now making someone do every time they call the routine. What if they have a MyPoint and your procedure takes a YourPoint? And what if your point is 8-dimensional, anyway, what does that constructor look like?

(b) This has performance implications, not least because of the ABI. And depending on what language you are using, they can be quite severe (good luck if you are using one of those languages that always puts classes on the heap).

> What if they have a MyPoint and your procedure takes a YourPoint?

Then you get early warning that you need to be paying attention, rather than silently corrupting your data by swapping some coordinates around.

> And what if your point is 8-dimensional, anyway, what does that constructor look like?

You don't want an 8-dimensional point literal that takes 8 arguments directly, that's never going to be readable. You might want to use a builder. More likely you want to load it from a data file or something on those lines rather than constructing it directly. Where are you even getting these 8-dimensional points from?

> This has performance implications, not least because of the ABI. And depending on what language you are using, they can be quite severe (good luck if you are using one of those languages that always puts classes on the heap).

In Haskell (or indeed in C) it doesn't necessarily have performance implications; an 8-element structure may have exactly the same runtime representation as those 8 elements being passed distinctly.

(In my experience performance concerns are always overblown in any case. If you have actual performance constraints then profile; if you don't, don't worry about it. Too often performance is used as an excuse)

Then you get early warning that you need to be paying attention, rather than silently corrupting your data by swapping some coordinates around.

No, a real-world case is that I have a giant program that uses my own geometric primitives, and now I want to start heavily using a library. I know they are just fricking 3D points or quaternions or whatever. Yet because of some weird ideology you want to increase the amount of gruntwork I have to do, and make my life much less pleasant.

You don't want an 8-dimensional point literal that takes 8 arguments directly, that's never going to be readable. You might want to use a builder. More likely you want to load it from a data file or something on those lines rather than constructing it directly. Where are you even getting these 8-dimensional points from?

WHAT ARE YOU TALKING ABOUT

In Haskell (or indeed in C) it doesn't necessarily have performance implications; an 8-element structure may have exactly the same runtime representation as those 8 elements being passed distinctly.

Wow, okay, this conversation is over.

>> In Haskell (or indeed in C) it doesn't necessarily have performance implications; an 8-element structure may have exactly the same runtime representation as those 8 elements being passed distinctly.

> Wow, okay, this conversation is over.

I'm confused as to why this was a conversation ender.

An 8 element structure using newtypes in haskell would have the same runtime.

For more info, see:

https://skillsmatter.com/skillscasts/5296-safe-zero-cost-coe...

It was the "or indeed in C" that ended it for me right there (though that was compounded by the 'you want to load your 8-dimensional points from a file, where else could you possibly be getting them?' stuff, which shows that the correspondent has not done any scientific or geometric programming, or computer graphics, or video games, which are some of the main fields where performance matters most, so if someone is going to make a performance argument ... maybe he should actually know about performance programming).

If you want to talk about Haskell, fine ... I don't know anything about Haskell, though, and I am interested in high-performance programming, which is an area where Haskell cannot currently play (nor can any GC'd language). Making claims about how the performance of an operation in a slow language doesn't get any slower under certain circumstances isn't that interesting to me.

If you're not interested in a constructive conversation then don't comment in the first place.

If I've misunderstood what's going on with C then by all means tell me what does happen. To the best of my knowledge, if we're talking about 8 same-typed coordinates then there's no alignment/struct-packing issue, so whether you have 8 named doubles (say) or a struct with 8 double members (or indeed an array of 8 doubles), the in-memory representation on the stack is going to be the same; function calling convention is platform-specific but could easily have the same behaviour for the struct vs the named doubles (an array would be different in that case since you can't pass them by value). If that's wrong then talk constructively about what does happen.

> you want to load your 8-dimensional points from a file, where else could you possibly be getting them?

My point wasn't that you want to load them from a file, it's that it would be rare to want to have a point literal directly in your source. But why let that stop you leaping to a good ad hominem?

Function calls pass parameters in registers if they're small enough.

Reply on news.ycombinator.com