Programming in the Point-Free Style(eiriktsarpalis.wordpress.com)
eiriktsarpalis.wordpress.com
Programming in the Point-Free Style
https://eiriktsarpalis.wordpress.com/2017/04/02/programming-in-the-point-free-style/
102 comments
> - keep the complexity of the functions as low as possible.
This seems particularly critical. This style works well in Haskell where it's extremely common to have short functions.
I've found that Haskell code often has two kinds of functions: 1-2 line functions (or function cases) that do actual work and computation (often combining other such functions), and 50+ line monadic functions that implement simple sequential routines with very simple control flow (calling other functions for any non-trivial computation). Point-free style works quite well for many of the former.
This seems particularly critical. This style works well in Haskell where it's extremely common to have short functions.
I've found that Haskell code often has two kinds of functions: 1-2 line functions (or function cases) that do actual work and computation (often combining other such functions), and 50+ line monadic functions that implement simple sequential routines with very simple control flow (calling other functions for any non-trivial computation). Point-free style works quite well for many of the former.
I don't do Haskell, but I have worked on projects with lots of small functions, and one of the problems with that is that can be... too many functions. You have to go look up three functions every time you read a block of code. Worse, people start writing the same functions over and over again.
There's probably a bigger picture problem and fix in that kind of situation, but it is something I think about.
There's probably a bigger picture problem and fix in that kind of situation, but it is something I think about.
> You have to go look up three functions every time you read a block of code.
When you write small, single-purpose functions, you can make them fairly self-documenting with the name alone. If you have to look up a one-line function, it probably doesn't have a very clear function or name.
> Worse, people start writing the same functions over and over again.
That one I've definitely run into.
> There's probably a bigger picture problem and fix in that kind of situation, but it is something I think about.
Mechanisms to search functions by type ("find me a function that takes an X and returns a Y") help quite a bit.
When you write small, single-purpose functions, you can make them fairly self-documenting with the name alone. If you have to look up a one-line function, it probably doesn't have a very clear function or name.
> Worse, people start writing the same functions over and over again.
That one I've definitely run into.
> There's probably a bigger picture problem and fix in that kind of situation, but it is something I think about.
Mechanisms to search functions by type ("find me a function that takes an X and returns a Y") help quite a bit.
When you write small, single-purpose functions, you can make them fairly self-documenting with the name alone.
Sometimes, although with languages like Haskell there can be a related problem that accurate names for these small functions wind up being almost as long, or even longer, than their definitions.
Sometimes, although with languages like Haskell there can be a related problem that accurate names for these small functions wind up being almost as long, or even longer, than their definitions.
Pharo/Squeak (and probably other Smalltalk systems) have a utility that let you find a function given a set of input/output examples.
Do you have a name/link? That sounds fascinating.
Conventions also help.
For instance, the lazy readTVar, modifyTVar, etc. functions have strict analogs called readTVar' and so on. mapM, foldM, replicateM, and traverse return a monadic value, while mapM_, foldM_, replicateM_, traverse_ and friends discard the return value (giving an m () instead of an m a).
For instance, the lazy readTVar, modifyTVar, etc. functions have strict analogs called readTVar' and so on. mapM, foldM, replicateM, and traverse return a monadic value, while mapM_, foldM_, replicateM_, traverse_ and friends discard the return value (giving an m () instead of an m a).
In order to be able to read it, you have to know by heart the signature of the standard operators
Unfortunately, while that tells you how many operands there are, it doesn't help you find them in the surrounding syntax.
In Forth, for instance, the operands of a + could be a pair of immediately preceding constants like 1 2 +. These could be far away in a contrived way: 1 2 [... snip stuff that produces side effects and keeps stack balanced ...] +. Or just due to expression complexity: [30 word expr] [27 word expr] +: the left operand of + is the result of the 30 word expr, which is 27 words away from the + symbol. Or is that 26? 29?
Unfortunately, while that tells you how many operands there are, it doesn't help you find them in the surrounding syntax.
In Forth, for instance, the operands of a + could be a pair of immediately preceding constants like 1 2 +. These could be far away in a contrived way: 1 2 [... snip stuff that produces side effects and keeps stack balanced ...] +. Or just due to expression complexity: [30 word expr] [27 word expr] +: the left operand of + is the result of the 30 word expr, which is 27 words away from the + symbol. Or is that 26? 29?
> These could be far away in a contrived way: 1 2 [... snip stuff that produces side effects and keeps stack balanced ...] +
This is obviously poorly written. "1 2 + [stuff]" is the sane way to write it. Or "2 [stuff] 1 +" if [stuff] takes one parameter and outputs one result.
> Or just due to expression complexity: [30 word expr] [27 word expr] +
Post that on comp.lang.forth, and people will certainly tell you "don't do that" or "why do you that" if it's less trivial than a factoring issue.
In similar situations some people have this trick of separating sub-expressions with double spaces. But that's ignoring the writing on the wall.
What I learned from Forth is that it's true that it has its shortcomings, but I have my own shortcomings too. As Forth is a DIY language, you have to make this distinction in order to improve language/programmer pair.
This is obviously poorly written. "1 2 + [stuff]" is the sane way to write it. Or "2 [stuff] 1 +" if [stuff] takes one parameter and outputs one result.
> Or just due to expression complexity: [30 word expr] [27 word expr] +
Post that on comp.lang.forth, and people will certainly tell you "don't do that" or "why do you that" if it's less trivial than a factoring issue.
In similar situations some people have this trick of separating sub-expressions with double spaces. But that's ignoring the writing on the wall.
What I learned from Forth is that it's true that it has its shortcomings, but I have my own shortcomings too. As Forth is a DIY language, you have to make this distinction in order to improve language/programmer pair.
This is obviously poorly written.
It's only obvious in the example form which I have. If such a thing occurs in real code, the stuff won't look like [stuff]; it will not stand out.
"Poorly written" happens.
It's only obvious in the example form which I have. If such a thing occurs in real code, the stuff won't look like [stuff]; it will not stand out.
"Poorly written" happens.
So German trennbare Verben (split verbs)? :)
Whenever the literary German dives into a sentence, that is the last you are going to see of him till he emerges on the other side of his Atlantic with his verb in his mouth. - Mark Twain
Whenever the literary German dives into a sentence, that is the last you are going to see of him till he emerges on the other side of his Atlantic with his verb in his mouth. - Mark Twain
The 30-word expr should have been another word, or two.
I think concatenative languages have great potential when paired with a proper type system and IDE. But you're absolutely right when it comes to plain text programming; point-free style feels clever to write, but makes it more difficult to read.
In Haskell there are some rules of thumb: if your new function is just a composition of existing function, point-free is fine. If you need 'flip' and friends, consider giving points a chance. There's a grey area in the middle that asks for judgement calls.
if your new function is just a composition of existing function, point-free is fine.
I'd probably extend that to things like straightforward partial application as well, but I strongly agree with your implied point that once some new function isn't a relatively simple derivation from some existing function(s), point-free style tends to become a liability. It's cute doing things with weird combinations of operators like (.) and ($), but it's also the Haskell version of writing C code full of one-character identifiers and obscure macros.
I'd probably extend that to things like straightforward partial application as well, but I strongly agree with your implied point that once some new function isn't a relatively simple derivation from some existing function(s), point-free style tends to become a liability. It's cute doing things with weird combinations of operators like (.) and ($), but it's also the Haskell version of writing C code full of one-character identifiers and obscure macros.
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.
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).
(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.
> 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.
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...
> 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 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?
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.
I have yet to see the benefits of point-free programming. Don't get me wrong it's fun, but in my opinion it makes reasoning about programs much harder. I am a huge fan of functional programming nevertheless.
The opinion that a point-free style is "beautiful code" seems pretty esotheric to me.
The opinion that a point-free style is "beautiful code" seems pretty esotheric to me.
For a good, pragmatic introduction that may clear this up for you: https://www.youtube.com/watch?v=Cy7jBYr3Zvc
tldw; point-free style can lead to readable, generic code -- but any dogmatic adherence to a particular style can have the opposite effect. Use it when it makes your code more readable, avoid it otherwise.
tldw; point-free style can lead to readable, generic code -- but any dogmatic adherence to a particular style can have the opposite effect. Use it when it makes your code more readable, avoid it otherwise.
> Use it when it makes your code more readable, avoid it otherwise.
That's probably the most useful approach to point-free programming.
That's probably the most useful approach to point-free programming.
It's the most useful approach to anything when it comes to programming.
Rigid adherence to rules, styles, paradigms or whatever will generally result in at least some corner cases where adherence leads to worse code.
Rigid adherence to rules, styles, paradigms or whatever will generally result in at least some corner cases where adherence leads to worse code.
Some typical pragmatic applications:
1. Escaping parenthesis hell: sometimes you can escape an unreasonable amount of parenthesis nesting by using (some) point-free programming.
2. The same thing that you'd use cascades in Smalltalk for: repeated applications of operations to the same object without having to name the object over and over again. (Obviously, in a functional language, it may not strictly be the "same" object, but conceptually, it's the same pattern.)
3. Combinator libraries (mentioned by the article itself). Here, the functions being composed are really meant to be (mostly) opaque entities and the fact that you're using a form of function composition is an implementation detail.
1. Escaping parenthesis hell: sometimes you can escape an unreasonable amount of parenthesis nesting by using (some) point-free programming.
2. The same thing that you'd use cascades in Smalltalk for: repeated applications of operations to the same object without having to name the object over and over again. (Obviously, in a functional language, it may not strictly be the "same" object, but conceptually, it's the same pattern.)
3. Combinator libraries (mentioned by the article itself). Here, the functions being composed are really meant to be (mostly) opaque entities and the fact that you're using a form of function composition is an implementation detail.
>1. Escaping parenthesis hell: sometimes you can escape an unreasonable amount of parenthesis nesting by using (some) point-free programming.
Why would I want to? Parenthesis make precedence explicit.
Why would I want to? Parenthesis make precedence explicit.
Parens can be harder to parse for humans than operators.
That's the whole point that justifies not going for S-Expression syntax for every programming language in the first place.
That's the whole point that justifies not going for S-Expression syntax for every programming language in the first place.
Indentation can help but personally I like my editor to color matching parens the same color making it easier to visualize structure.
Oh, I definitely have a soft-spot for s-expression syntax---especially with good editor support for colours and indentation and syntax-aware editing. It actually took my quite a while to warm-up to Haskell's richer and more complicated syntax.
How do you feel about shell pipelines? Most shell pipelines don't name the things they operate on. Point-free style feels the same way: you string functions together and don't name the input/output.
I like them. It's not that I don't like point-free functions but more often than not specifying the point makes sense in my opinion — more clarity, less beauty.
I agree. My general rule is that any non-trivial use of "flip" or any use of curried '.' or '$' means I should name the point instead.
Depends. I like using (.) for eg chaining functors, even though it's not trivial:
(fmap . fmap . fmap) toUpper
fmap (\i_string -> fmap (\string -> fmap (\c -> toUpper c)))
I think in that case, for clarity, I'd rather write:
But in general I don't mind that kind of use of '.'; I was talking more about any expression like "g . (f .)" or similarly inscrutable curries.
f (Just (i, cs)) = Just (i, map toUpper cs)
f x = x
But in general I don't mind that kind of use of '.'; I was talking more about any expression like "g . (f .)" or similarly inscrutable curries.
The chained Functors, Traversables etc are useful when you are still writing and changing your code---it's really easy to add or remove a layer.
Yes, some of the instances can be confusing. Adding type signatures afterwards usually clears it up. (The types will tell the reader that for tuples, fmap operates on the second element.)
Yes, "g . (f .)" might be a bit harder to read. Though when I first discovered functor-composition by myself, I was just playing around with exactly that kind of point-less nonsense for fun.
Yes, some of the instances can be confusing. Adding type signatures afterwards usually clears it up. (The types will tell the reader that for tuples, fmap operates on the second element.)
Yes, "g . (f .)" might be a bit harder to read. Though when I first discovered functor-composition by myself, I was just playing around with exactly that kind of point-less nonsense for fun.
> [tacit programming] makes reasoning about programs much harder
With sufficient type information reasoning is easy enough that even the compiler can verify correctness.
> The opinion that a point-free style is "beautiful code" seems pretty esotheric to me.
In some way one could say that tacit programming is the interface-oriented programming of the FP-world.
I just had an example where I used tacit programming and had much cleaner code: I had to talk to PostgreSQL through "some" API. For that I need to connect, authenticate and potentially configure the connection. The toplevel function looks like this (in CL):
And the benefits are just the same you have in OOP when using interfaces properly: Decoupling of logic and implementation.
With sufficient type information reasoning is easy enough that even the compiler can verify correctness.
> The opinion that a point-free style is "beautiful code" seems pretty esotheric to me.
In some way one could say that tacit programming is the interface-oriented programming of the FP-world.
I just had an example where I used tacit programming and had much cleaner code: I had to talk to PostgreSQL through "some" API. For that I need to connect, authenticate and potentially configure the connection. The toplevel function looks like this (in CL):
(defun connect (open authenticate configure)
;;; omitting the (check-type ..)s on the functions here for brevity
(funcall (compose configure authenticate open)))
And the benefits are just the same you have in OOP when using interfaces properly: Decoupling of logic and implementation.
> With sufficient type information reasoning is easy enough that even the compiler can verify correctness.
I think we have a different opinion on "easy to reason about". With easy to reason about I mean the time it takes me to understand a function or part of a program. I can write the most cryptic function with cryptic types that is 100% correct but nobody understands.
> And the benefits are just the same you have in OOP when using interfaces properly: Decoupling of logic and implementation.
No, there are no real benefits as it's only a syntactic difference.
Generally, a point-free style should only be "easier to understand" when the point you decide not to mention is completely irrelevant and non-meaningful to understanding the function, but that's not always the case in my opinion.
I think we have a different opinion on "easy to reason about". With easy to reason about I mean the time it takes me to understand a function or part of a program. I can write the most cryptic function with cryptic types that is 100% correct but nobody understands.
> And the benefits are just the same you have in OOP when using interfaces properly: Decoupling of logic and implementation.
No, there are no real benefits as it's only a syntactic difference.
Generally, a point-free style should only be "easier to understand" when the point you decide not to mention is completely irrelevant and non-meaningful to understanding the function, but that's not always the case in my opinion.
> I think we have a different opinion on "easy to reason about".
> No, there are no real benefits as it's only a syntactic difference.
Yes, but an implementation in brainfuck can be derived by pure syntax transformation as well and thus too is "only a syntactic difference".
I personally find it much easier to reason about 6 consecutive lines of code that enforce 4 interfaces by type annotations (the 2 lines quoted plus the 4 lines of type declarations I omitted) than to read through the equivalent in java, which is at least 12 lines in 4 files and requires an abstraction very far away from underlying mathematical principles (the equivalent of my code in Java would require factories of factories and I'd argue that if one considers that easier to read, one has spent too much time in OOP-land).
As others have pointed out, one should definitely not get carried away with it and always evaluate carefully whether it helps clarity. But when the protocol is as simple as "connect, authenticate, configure" then I don't see any reason why I should not write it exactly like this:
> No, there are no real benefits as it's only a syntactic difference.
Yes, but an implementation in brainfuck can be derived by pure syntax transformation as well and thus too is "only a syntactic difference".
I personally find it much easier to reason about 6 consecutive lines of code that enforce 4 interfaces by type annotations (the 2 lines quoted plus the 4 lines of type declarations I omitted) than to read through the equivalent in java, which is at least 12 lines in 4 files and requires an abstraction very far away from underlying mathematical principles (the equivalent of my code in Java would require factories of factories and I'd argue that if one considers that easier to read, one has spent too much time in OOP-land).
As others have pointed out, one should definitely not get carried away with it and always evaluate carefully whether it helps clarity. But when the protocol is as simple as "connect, authenticate, configure" then I don't see any reason why I should not write it exactly like this:
(compose configure authenticate connect)And in a concatenative language, that would be quite literally:
connect authenticate configureHow is this better then implicit state? I have no idea what data was passed around here.
In typical concatenative code, a function usually has only 1–2 inputs and outputs, so it only ever uses a tiny part of the “implicit state” (typically a stack) being passed between functions. It’s not much different than
Static types help a lot with this (and I’ve actually been working on a statically typed concatenative language for a while) but even basic arity checking (as in Factor) is enough to make it a very minor issue.
To me, the point is not that you should avoid local variables entirely. Rather, it’s that most code doesn’t actually need local variables to be perfectly readable, because the most common dataflow patterns in regular business logic can be captured by simple composition of functions.
configure(authenticate(connect(open())));
Static types help a lot with this (and I’ve actually been working on a statically typed concatenative language for a while) but even basic arity checking (as in Factor) is enough to make it a very minor issue.
To me, the point is not that you should avoid local variables entirely. Rather, it’s that most code doesn’t actually need local variables to be perfectly readable, because the most common dataflow patterns in regular business logic can be captured by simple composition of functions.
The Haskell style guide says not to over-use them, and to write a type-signature on the line before.
https://github.com/tibbe/haskell-style-guide/blob/master/has...
https://github.com/tibbe/haskell-style-guide/blob/master/has...
Avoid over-using point-free style. For example, this is hard to read:
-- Bad:
f = (g .) . h
For me, point free seemed very tight. I didn't struggle to much with reasoning about what was happening, but changing things.
The only way i could really cope was lots of classes. leave the current instance in place while i write a whole new instance with the new approach. Attempting to change an existing instance, like i'd do with a more verbose language, seemed very difficult if not impossible for me.
The only way i could really cope was lots of classes. leave the current instance in place while i write a whole new instance with the new approach. Attempting to change an existing instance, like i'd do with a more verbose language, seemed very difficult if not impossible for me.
[deleted]
> The opinion that a point-free style is "beautiful code" seems pretty esotheric to me.
It feels to me like there's this weird disconnect between people who talk about beautiful code and those who don't. For me, the aesthetic criteria that would lead me to call a piece of code beautiful are things like clarity, ease of understanding and simplicity. Writing code in a certain way might even elucidate the structure of the problem for the reader.
Now, concision is definitely something that matters to me aesthetically, but if it comes at the cost of clarity, it just isn't worth it. I would consider very concise but complex and inscrutable point free code to be ugly.
It definitely is my opinion that much of the time point free code is beautiful by these criteria. It's also often the case that I find point free code ugly. The thing that makes it difficult is that whether code is readable is heavily subjective. It very much depends on the familiarity of the reader with the functions and combinators and constructs that are in use. And of course people differ on the level of fluency in the language and language constructs that should be expected of the reader.
It feels to me like there's this weird disconnect between people who talk about beautiful code and those who don't. For me, the aesthetic criteria that would lead me to call a piece of code beautiful are things like clarity, ease of understanding and simplicity. Writing code in a certain way might even elucidate the structure of the problem for the reader.
Now, concision is definitely something that matters to me aesthetically, but if it comes at the cost of clarity, it just isn't worth it. I would consider very concise but complex and inscrutable point free code to be ugly.
It definitely is my opinion that much of the time point free code is beautiful by these criteria. It's also often the case that I find point free code ugly. The thing that makes it difficult is that whether code is readable is heavily subjective. It very much depends on the familiarity of the reader with the functions and combinators and constructs that are in use. And of course people differ on the level of fluency in the language and language constructs that should be expected of the reader.
Point-free programming would be extremely useful if the composition primitive allowed introspection.
You would then compose functions that would have run-time homoiconicity as you would be able to edit the "ast" embedded in the point-free function.
I use this to modify the parameters of the composite geometric transformations of fractals. This allows me to generate animations for any kind of fractals without having to reimplement the animation code for each fractal : https://scientific-coder.github.io/Playground/2017-03-20-fra... (cf stepify multi-method). This would be useful for web servers in Clojure as we could have our cake and eat it too : while currently one has to pick either easy with ring handlers that are simple function compositions and vectors of interceptors for pedestal that can be modified at runtime.
I use this to modify the parameters of the composite geometric transformations of fractals. This allows me to generate animations for any kind of fractals without having to reimplement the animation code for each fractal : https://scientific-coder.github.io/Playground/2017-03-20-fra... (cf stepify multi-method). This would be useful for web servers in Clojure as we could have our cake and eat it too : while currently one has to pick either easy with ring handlers that are simple function compositions and vectors of interceptors for pedestal that can be modified at runtime.
"For those who find beauty in this kind of thing, this is the kind of thing they find beautiful."
(Twisted paraphrase of a somewhat famous quote. See http://quoteinvestigator.com/2015/09/09/like-sort/ for more.)
(Twisted paraphrase of a somewhat famous quote. See http://quoteinvestigator.com/2015/09/09/like-sort/ for more.)
When you're writing a simple, generic function, naming your arguments can easily feels like pointless (heh) ceremony that just obscures rather than clarifying.
def foo(whatever: Int) = quxxl(bar(whatever))
val foo = bar andThen quxxl
It's beautiful because it maximizes use of existing ideas and minimizes the introduction of new ideas. Idea :: code dependency. It is worth minimizing dependency complexity and it's too bad that today's software and languages is still so hard to think in that factors like this are largely overshadowed.
Turn around and run any time someone starts talking about "beautiful" code.
I'm not so sure. Taking care that you're only exposed to ugly code won't really increase the chance that it's any good.
People who obsess over code "beauty" tend to write unreadable and unmaintainable code and spend a long time doing it.
Interesting article. So far I've been working on one (real and deployed) project that employs F# and I generally liked the experience. Much of my code still is F#ified C# and lacks a cohesive way of structuring things, but every time a new piece of the puzzle snaps in place and I get better, shorter and more beautiful code to replace the old "works but ugly" stuff. The hardest thing is where reality (.Net frameworks, API's, user input and databases) meets theory (nice formatted mathematical situations that make F# shine).
Lots of the comments seem to be missing the point that, despite the title, the author is not advocating the point-free style:
> The point of this exercise is to illustrate how the lambda calculus with pattern matching (or set theory for that matter) is superior to the point-free style in terms of expressive efficiency.
> The point of this exercise is to illustrate how the lambda calculus with pattern matching (or set theory for that matter) is superior to the point-free style in terms of expressive efficiency.
Sure but it's a deeply uninteresting exercise because no one programs in category theory.
No one programs in category theory, therefore... what?
ELI5: What's the connection between your comment and JadeNB's?
ELI5: What's the connection between your comment and JadeNB's?
People aren't missing the point, they just aren't engaging with it because TFA makes it's point by claiming category theory is expressively inefficient... but nobody programs in category theory, the link between point free programming in F# and category theory is meaningless. Tacit programming in F# is a reflection on tacit programming in F# nothing else.
So the commentariate has decided to talk about point free programming in general instead of engaging the article's very narrow and unsubstantiated point.
So the commentariate has decided to talk about point free programming in general instead of engaging the article's very narrow and unsubstantiated point.
Point free expression in production ANSI C90 code:
Function defined here, stored in xform_listed_quote_f global:
http://www.kylheku.com/cgit/txr/tree/eval.c?id=6ca6be767f8ac...
Used as a mapping function here:
http://www.kylheku.com/cgit/txr/tree/eval.c?id=6ca6be767f8ac...
Function defined here, stored in xform_listed_quote_f global:
http://www.kylheku.com/cgit/txr/tree/eval.c?id=6ca6be767f8ac...
Used as a mapping function here:
http://www.kylheku.com/cgit/txr/tree/eval.c?id=6ca6be767f8ac...
Point-free programming is sometimes also called "tacit" programming. I found this practical description of tacit programming in Racket to be useful: http://r-wos.org/blog/tacit-racket
Points-free is helpful if you're mentally focusing on the "verb" or function, and not the "noun" or data. (sqrt x) yields a noun. (sqrt) yields a verb.
> A category consists of abstract functions (or morphisms, or “arrows”) that have an origin and destination (or domain and codomain, or “argument type” and “return type”).
I think perhaps Maths people need to seek more consensus on terminology.
I think perhaps Maths people need to seek more consensus on terminology.
I've only seen mathematicians use the terms morphisms, arrows, and domain/codomain. It is true that morphisms and arrows mean the same thing, but I think that's because the term morphism is specific to category theory and the term arrow is from graph theory.
All the other terms here (abstract functions, origin, destination, argument type, return type) appear to be the author's attempt to make the subject understandable to programmers.
All the other terms here (abstract functions, origin, destination, argument type, return type) appear to be the author's attempt to make the subject understandable to programmers.
Morphism is from Algebra/General Mathematics and it is a function that preserves a "structure". (Group Morphism, Isomorphism between sets, etc)
In Graph Theory the terminology is Node and Vertex.
Arrow, Source and Target are from Category Theory.
In Graph Theory the terminology is Node and Vertex.
Arrow, Source and Target are from Category Theory.
Morphism is the standard general term. If you have a collection of objects with the some sort of structure then a morphism maps one of those to another preserving that structure.
In CT you usually are dealing with morphisms, but not always and that intuition can get in your way. For this reason, arrow is sometimes used instead to indicate something a little more abstract than morhism.
In CT you usually are dealing with morphisms, but not always and that intuition can get in your way. For this reason, arrow is sometimes used instead to indicate something a little more abstract than morhism.
The term "arrow" is from category theory, not graph theory.
> I think perhaps Maths people need to seek more consensus on terminology.
If only they could follow the example of programmers, who never have two different words for identical (or, worse, near-identical) concepts!
If only they could follow the example of programmers, who never have two different words for identical (or, worse, near-identical) concepts!
I find the opposite worse: using the same term for different concepts. (I am looking at you, C++ people, and your so called "Functors"!)
Seriously. I've tried to read on category theory before and never really grokked what it was all about. The sentence you quoted was literally the first one I've ever read that actually made me say, "oh, that's what this is".
The category theory idea of a morphism is more abstract than a function. If functions deal with domains and codomains then certainly morphisms need new words to deal with the abstractions of those ideas that are specific to functions.
A great talk from Strange Loop 2016 on this topic:
"Point-Free or Die: Tacit Programming in Haskell and Beyond" by Amar Shah https://www.youtube.com/watch?v=seVSlKazsNk
"Point-Free or Die: Tacit Programming in Haskell and Beyond" by Amar Shah https://www.youtube.com/watch?v=seVSlKazsNk
For haskell there is a fantastic tool that converts code into a pointfree function definition.
https://hackage.haskell.org/package/pointfree
https://hackage.haskell.org/package/pointfree
> For haskell there is a fantastic tool that converts code into a pointfree function definition.
But why? If a point-free style is more readable, then by all means use it, but if you need an automated tool to do the translation for you, then that seems unlikely. If it's an efficiency question, then your compiler can, and (given the trickiness of GHC in particular) probably will, do anything that an external automated tool can.
But why? If a point-free style is more readable, then by all means use it, but if you need an automated tool to do the translation for you, then that seems unlikely. If it's an efficiency question, then your compiler can, and (given the trickiness of GHC in particular) probably will, do anything that an external automated tool can.
For fun mostly but it can be useful too: it can find neat solutions I couldn't think of and I may decide to use it. Of course it gives also crazy stuff like `(((.) . (,)) .)` that I will never put in a program because I don't understand or it's just worse than the original input.
> For fun mostly but it can be useful too: it can find neat solutions I couldn't think of and I may decide to use it. Of course it gives also crazy stuff like `(((.) . (,)) .)` that I will never put in a program because I don't understand or it's just worse than the original input.
If it is purely an intellectual exercise, to see how else the code could theoretically be written, then I totally see the point. (I am a mathematician, after all!)
On the other hand, if it is code that you actually use in production, then surely the old dictum that I will misquote, for want of looking it up, as "if you write the cleverest code possible, then you are not clever enough to debug it", applies all the more so to say "if you aren't clever enough to write your own code, then you certainly aren't clever enough to debug it"! (Not you personally, I mean; just a comment on programmer-facing auto-generated code.)
If it is purely an intellectual exercise, to see how else the code could theoretically be written, then I totally see the point. (I am a mathematician, after all!)
On the other hand, if it is code that you actually use in production, then surely the old dictum that I will misquote, for want of looking it up, as "if you write the cleverest code possible, then you are not clever enough to debug it", applies all the more so to say "if you aren't clever enough to write your own code, then you certainly aren't clever enough to debug it"! (Not you personally, I mean; just a comment on programmer-facing auto-generated code.)
I think the lesson here is, if the conversion looks horrendous, then the original was questionable in the first place.
Incidentally, I couldn't resist some eta expansion. If I didn't screw it up:
(((.) . (,)) .) f x g y
(((.) . (,)) . f) x g y
(((.) . (,)) (f x)) g y
((.) ((,) (f x))) g y
((.) (f x,)) g y
((f x,) . g) y
(f x, g y)I wish the pointfree utility would use slightly higher-level combinators like those from Control.Arrow. Readable point-free code tends to break things up into many small reusable pieces, following the maxim of “name code, not data”.
This example is totally absurd, since you’d just write “(f x, g y)” and call it a day, but you can extract a fully point-free version that’s somewhat readable.
This example is totally absurd, since you’d just write “(f x, g y)” and call it a day, but you can extract a fully point-free version that’s somewhat readable.
f = pairwise $ curry $ apply *** apply
where
pairwise = fcurry fcurry
fcurry = fmap curry
apply = uncurry ($)> If a point-free style is more readable, then by all means use it, but if you need an automated tool to do the translation for you, then that seems unlikely.
I find the pointfree style is usually easier to read but the pointful style is often easier to write. So I tend to write pointful first and then translate into pointfree. An automated tool can help with that.
I find the pointfree style is usually easier to read but the pointful style is often easier to write. So I tend to write pointful first and then translate into pointfree. An automated tool can help with that.
> If a point-free style is more readable, then by all means use it
And this is a tool to do just that.
And this is a tool to do just that.
Two points particularly add to the complexity of the point-free definition
Having done a lot of programming in Postscript, I understand the allure of point-free style.
Some code can seem extremely elegant, but mostly it's just clever, and an exercise in showing off how smart you are and how much you can keep in your head.
And with all due respect to Joe Condon: Eschew clever code.
Some code can seem extremely elegant, but mostly it's just clever, and an exercise in showing off how smart you are and how much you can keep in your head.
And with all due respect to Joe Condon: Eschew clever code.
Interesting. I find composing operators on streams to require holding less in my head than the equivalent non-point-free (ie, iterative / loop-based) code.
When reading (eg) nested for loops with conditions, I have to push a ton of context variables into my head, and then evolve them over iterations if I'm doing a close read. That's a lot of ask of my head.
But in the point-free style, each compositional unit tends to be small enough to be "obviously no bugs" vs. "no obvious bugs".
When reading (eg) nested for loops with conditions, I have to push a ton of context variables into my head, and then evolve them over iterations if I'm doing a close read. That's a lot of ask of my head.
But in the point-free style, each compositional unit tends to be small enough to be "obviously no bugs" vs. "no obvious bugs".
All things in moderation. Chaining list transforms (like map and filter) in one expression does have fewer points than giving every intermediate result a name or even using a for loop, but it doesn't require the level of tenseness usually associated with the term "point-free".
I think you're mixing up "higher order" code and "point-free" code. Just because you don't go point-free doesn't mean you have to resort to nested for-loops.
After a few seconds I was redirected to an ad site that made my mobile vibrate and that “locked me in“ by some redirect trickery which blocked the back button.
Not really what I'd expect from a HN link with so many upvotes. Did no one else experience this?
Not really what I'd expect from a HN link with so many upvotes. Did no one else experience this?
I think the article makes good points. We have already seen callback hell. I wonder how long it will take before we coin the term “monad hell”.
Great article. 100% agree. Especially the category theory example.
try not to make global functions. or at least put them in name spaces. if the function is reusable cross code bases then make it into a module or library.
Was the language Forth point-free?
It can be. Pure functions which exclusively operate upon the stacks are often considered idiomatic. If you choose, however, you can reference and alter named global variables within a function, and some dialects offer a facility for named local variables. You might argue that the 'i' and 'j' words, which interact with loop constructs to give you a copy of the current and outer loop induction variable, count as references to named variables, even if they aren't strictly the same thing.
As with most languages it comes down to the programmer.
As with most languages it comes down to the programmer.
Yes. That was my introduction to the concept (though I didn't know the term until I later toyed with J and Haskell).
And another example is FP from Backus's Turing Award lecture.
In order to be able to read it, you have to know by heart the signature of the standard operators, and then you have to learn on the go the signature of the operators of the particular program your are studying.
It doesn't fly well if the author doesn't follow certain "usability" rules:
- name things thoughtfully and properly,
- no more than 3 arguments for your functions,
- keep the complexity of the functions as low as possible.
This is good advice in any language, but I'd say that with concatenative languages at least, deviations are likely to have more acute negative consequences on maintainability.