### Article summary

Like most fancy-sounding development terms, “point-free notation” actually isn’t that complicated. The “point” refers to the name of an argument for a function. Let’s say you have the following function:

```
function atLeastTwo(someNumber) {
return Math.max(2, someNumber);
}
```

The “point” would be `someNumber`

. To make this function point-free, all you would have to do is define it in such a way that it does not name or directly reference any arguments. That’s all. Can you imagine how you might do this?

## Using Point-Free Notation

The trick is to recall that functions can create other functions. So if you had another function that could create atLeastTwo for you, that would count.

```
var atLeastTwo = createAtLeastTwoForMe(); // this is basically cheating, however
```

In reality, a proper definition of `atLeastTwo`

should reference, at least, that it’s using the `Math.max`

function and the value `2`

.

What we want is a function to perform partial application. With partial application, you provide some, but not all, arguments to a function, and you receive back a function that takes only the remaining arguments.

JavaScript doesn’t include this out of the box, but it’s an interesting exercise to write your own. Let’s assume we have. Then we can use it, as such:

```
Math.max(2,20) // => 20
Math.max(2,0) // => 2
partial(Math.max, 2)(20) // => 20
partial(Math.max, 2)(0) // => 2
```

And, if we simply store the result of calling `partial()`

in a variable, then we’ve achieved point-free notation:

```
var atLeastTwo = partial(Math.max, 2)
```

This is a trivial example, but it’s possible to create much more complex functions using point-free notation. Usually, function composition is a valuable tool. Regardless of how it’s achieved, all it means is that you don’t explicitly name the arguments to your function.

## Why Does It Matter?

Sometimes, especially in abstract situations involving higher-order functions, providing names for tangential arguments can cloud the mathematical concepts underlying what you’re doing. In these cases, point-free notation can help remove those distractions from your code.

This isn’t always the case, obviously, or we’d all be using it a lot more.

What I find more interesting is that point-free notation serves as an example of how subtle changes to the way you think about or define your code can have big impacts on readability.

There’s an artform to structuring and defining your code in a way that maximizes clarity of intent or of the underlying concepts being used. Sometimes, these goals can conflict.

It’s your job as a developer to be cognizant of these tradeoffs. Spending some time thinking about or exploring alternative ways of solving problems, such as point-free notation, is a good way to grow these skills.