(Read part 1 first.)

When reading code, a lot of people like to print out the code and read it on paper. One of the reasons for that is that it is easier to switch from function call to the function specification and back. However functions are supposed to provide abstraction. You should be able to understand the function call without the function specification. Why is this often not possible? Because the function call doesn't provide enough context for the arguments.

Take for example this function from the DOM: parent.insertBefore(nodeA, nodeB). Is nodeA inserted before nodeB, or is nodeB inserted before nodeA? I keep forgetting that. And the more arguments, the more ridiculous it gets: mouseEvent.initMouseEvent("DOMMouseScroll", true, true, view, numLines, refPoint.x, refPoint.y, point.x, point.y, isControl, isAlt, isShift, isMeta, 0, null) (Simplified from the Mozilla source code). It's impossible to tell what each argument does.

I think almost any programmer can relate to this problem. But functions with multiple arguments seem to be so fundamental in programming that solutions to this problem never actually involve abandoning their use. These solutions are f.e. IntelliSense and using properly named constants. They reintroduce the missing context.

But proper language design can fix this problem more elegantly. Smalltalk provides an interesting solution: each extra argument is separated by a word. F.e. parent insert: nodeA before: nodeB is as clear as it can be. The only languages I know that actually restrict the number of arguments are APL and its derivatives. In APL functions are monadic (one argument, prefix notation) or dyadic (two arguments, infix notation).

That functions with 2 arguments are written with infix notation is very important. Using the DOM example again, but now assuming we don't need the parent: insertBefore nodeA, nodeB is not clear, but nodeA insertBefore nodeB is clear. With infix notation you have more options to choose a clear function name. Note that a method call with one argument on an object can be seen as infix: nodeA.insertBefore(nodeB).

Is a maximum of 2 arguments realistic for everyday programming? I'd say yes, and thinking about this problem actually improved my code! It forces you to really think about the structure of your data. F.e. when you'd normally be lazy and pass a point on the screen as two arguments x and y, you're now forced to create a Point object. It's hard to prove this is a good thing, but I've found it improves my code a lot. And again, programming language design comes into play, because creating simple intermediate objects is too much work, and often performs bad.

More later…