11 ms·

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 h

by davnn 10y ago

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.

agentultra 10y ago
For a good, pragmatic introduction that may clear this up for you: https://www.youtube.com/watch?v=Cy7jBYr3Zvc 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.
- davnn 10y ago
  > Use it when it makes your code more readable, avoid it otherwise. That's probably the most useful approach to point-free programming.
  - kungtotte 10y ago
    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.
Flow 10y ago
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/haskell-style.md https://github.com/tibbe/haskell-style-guide/blob/master/has...
- acchow 10y ago
  Avoid over-using point-free style. For example, this is hard to read: -- Bad: f = (g .) . h heh
AnimalMuppet 10y ago
"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/ http://quoteinvestigator.com/2015/09/09/like-sort/ for more.)
jfoutz 10y ago
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.
- deleted 10y ago
  [deleted]
JoshTriplett 10y ago
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.
- davnn 10y ago
  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.
  - JoshTriplett 10y ago
    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.
    - eru 10y ago
      Depends. I like using (.) for eg chaining functors, even though it's not trivial: (fmap . fmap . fmap) toUpper is a function that goes three levels down and applies f, eg on a 'Maybe (Int, [Char]))' and I find this style easier to read than: fmap (\i_string -> fmap (\string -> fmap (\c -> toUpper c))) But chaining 'fmap's in this way might be a special idiom that people can get used to, and not say anything about using point-free style in novel situations. The nice thing is that you can mix 'fmap' and eg 'traverse' like this.
      - JoshTriplett 10y ago
        I think in that case, for clarity, I'd rather write: f (Just (i, cs)) = Just (i, map toUpper cs) f x = x Especially because I find the instances that apply fmap to the second item of a two-item tuple confusing. 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.
        10y ago
jlg23 10y ago
> [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): (defun connect (open authenticate configure) ;;; omitting the (check-type ..)s on the functions here for brevity (funcall (compose configure authenticate open))) There is of course a wrapper that creates the 3 functions for you for the regular use cases, but if you want to implement a connection through IP-over-carrier-pigeon or authentication based on DNA samples, you can do so without having to touch the library - just pass your own open/authenticate/configure functions. And the benefits are just the same you have in OOP when using interfaces properly: Decoupling of logic and implementation.
- davnn 10y ago
  > 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.
  - jlg23 10y ago
    > 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: (compose configure authenticate connect)
rbehrends 10y ago
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.
- coldtea 10y ago
  >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.
  - eru 10y ago
    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.
    - michaelmrose 10y ago
      Indentation can help but personally I like my editor to color matching parens the same color making it easier to visualize structure.
      - eru 10y ago
        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.
emodendroket 10y ago
Turn around and run any time someone starts talking about "beautiful" code.
- recursive 10y ago
  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.
  - emodendroket 10y ago
    People who obsess over code "beauty" tend to write unreadable and unmaintainable code and spend a long time doing it.
wolfgangK 10y ago
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-fractals.html 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.
dustingetz 10y ago
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.
sullyj3 10y ago
> 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.
lmm 10y ago
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 Naming "whatever" just gets in the way of making it clear what foo actually does.

by davnn 10y ago

agentultra 10y ago

For a good, pragmatic introduction that may clear this up for you: https://www.youtube.com/watch?v=Cy7jBYr3Zvc 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.

davnn 10y ago
> Use it when it makes your code more readable, avoid it otherwise. That's probably the most useful approach to point-free programming.
- kungtotte 10y ago
  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.

Flow 10y ago

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/haskell-style.md https://github.com/tibbe/haskell-style-guide/blob/master/has...

acchow 10y ago
Avoid over-using point-free style. For example, this is hard to read: -- Bad: f = (g .) . h heh

AnimalMuppet 10y ago

"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/ http://quoteinvestigator.com/2015/09/09/like-sort/ for more.)

jfoutz 10y ago

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.

deleted 10y ago
[deleted]

JoshTriplett 10y ago

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.

davnn 10y ago
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.
- JoshTriplett 10y ago
  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.
  - eru 10y ago
    Depends. I like using (.) for eg chaining functors, even though it's not trivial: (fmap . fmap . fmap) toUpper is a function that goes three levels down and applies f, eg on a 'Maybe (Int, [Char]))' and I find this style easier to read than: fmap (\i_string -> fmap (\string -> fmap (\c -> toUpper c))) But chaining 'fmap's in this way might be a special idiom that people can get used to, and not say anything about using point-free style in novel situations. The nice thing is that you can mix 'fmap' and eg 'traverse' like this.
    - JoshTriplett 10y ago
      I think in that case, for clarity, I'd rather write: f (Just (i, cs)) = Just (i, map toUpper cs) f x = x Especially because I find the instances that apply fmap to the second item of a two-item tuple confusing. 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.
      - 10y ago

jlg23 10y ago

> [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): (defun connect (open authenticate configure) ;;; omitting the (check-type ..)s on the functions here for brevity (funcall (compose configure authenticate open))) There is of course a wrapper that creates the 3 functions for you for the regular use cases, but if you want to implement a connection through IP-over-carrier-pigeon or authentication based on DNA samples, you can do so without having to touch the library - just pass your own open/authenticate/configure functions. And the benefits are just the same you have in OOP when using interfaces properly: Decoupling of logic and implementation.

davnn 10y ago
> 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.
- jlg23 10y ago
  > 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: (compose configure authenticate connect)

rbehrends 10y ago

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.

coldtea 10y ago
>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.
- eru 10y ago
  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.
  - michaelmrose 10y ago
    Indentation can help but personally I like my editor to color matching parens the same color making it easier to visualize structure.
    - eru 10y ago
      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.

emodendroket 10y ago

Turn around and run any time someone starts talking about "beautiful" code.

recursive 10y ago
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.
- emodendroket 10y ago
  People who obsess over code "beauty" tend to write unreadable and unmaintainable code and spend a long time doing it.

wolfgangK 10y ago

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-fractals.html 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.

dustingetz 10y ago

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.

sullyj3 10y ago

> 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.

lmm 10y ago

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 Naming "whatever" just gets in the way of making it clear what foo actually does.