"Point-Free or Die: Tacit Programming in Haskell and Beyond" by Amar Shah

Tacit programming, or programming in the “point-free” style, allows you to define a function without reference to one or more of its arguments. Thanks to automatic currying, point-free definitions can be easy to write in Haskell, OCaml, and F#.
But is point-free syntax just point-less? Ostensibly, tacit definitions can calibrate your code to the appropriate level of abstraction. But which level is most appropriate? When is a point-free definition better than its “pointed” variation? And when is it spectacularly worse?
Let's be explicit about tacit programming. Let's learn eta-reduction to produce it. Let's develop our intuition for its expressive power. Let's hunt for it in trusted libraries. Let's probe its origins in John Backus' function-level programming. Let's see it amplified in Joy and J, languages designed for maximum quiet. Let's speak at length, about the unspoken.

[@1111757]

What if you have a function that takes 3 arguments? I stopped the talk right in the middle because I was wondering that myself and had to play around with it. And the answer is actually quite beautiful:
- blackbird is a compose of compose and compose
- blackbird with 3 args is a compose of compose and blackbird
- blackbird with 4 args is a compose of compose and blackbird with 3 args
- blackbird with 5 args is a compose of compose and blackbird with 4 args
Alternatively, blackbird with 4 args is a compose of blackbird and blackbird. I was hoping to also find the blackbird of blackbird and blackbird but that seems less useful (it's something like `outer(middle(inner(x, y), z))`).

[@abebuckingham8198]

Yeah it's called currying after Curry Haskell. There is also a programming language named after him. en.wikipedia.org/wiki/Currying

[@SloeElvis]

@@abebuckingham8198 Haskell Curry* lol

[@AlexanderGosselin]

This is fantastic.

[@wyc7tjmf794]

Joy, Factor, Kitten. Recursion combinators are cool. Great talk though.

[@KipIngram]

I like your "non-dogmatic" approach to all this.

[@ruffianeo3418]

He is right, that the way one writes code is all about communication (well most of the time, sometimes it is about performance). And the first question should be: Who is going to read the code? It could be another haskell programmer, it could be a domain expert (often a customer) with problem domain knowledge but not if any haskell knowledge. The next question should be: How are the readers going to read the code? A print on paper, in the subway on the way home in form of a killing time code review? Interactively in a ghci to play around with the code? With a debugger? For the paper case, as well as for the case where a non-haskell pro reads the code, IMHO locality of functionality is vital. If the reader sees (...) and a) does not even notice it is an overloaded operator (maybe he thinks it is a part of haskell he has not seen yet or it is something like C++ variadic templates..) or b) he knows it is some operator but he has no clue how it looks like and where it is defined, the code review is over. They see some syntax and a few names but cannot even guess what the code will do as all the information related to that is written anywhere but in the spot they look at. So, sometimes it could be best to do brain dead on point code with well known functions and operators.

[@gregbell2117]

This is an interesting point. So much of understanding FP code seems to rely on the reader having a really thick theoretical foundation. The complexity is in the theory, not the code. Imperative/procedural code, on the other hand, relies on just understanding some basic operations, and what a sequence is.

[@ratfuk9340]

You could say the same thing about composition. But composition is such a useful idea that everyone knows it. Blackbird (and others) _should_ be considered a useful pattern as well and everyone should learn it.

[@IanKjos]

Clever, but terseness puzzles. The signature illuminates.

[@trblyoo823]

Does anyone know of a tool/parser that shows you all the steps from pointful to point free and vice versa? He had a great point that to find what communicates best, you'll need to know what your options actually are. I'm still new to Haskell and the ($) (.) (...) operators are "understood", but I don't have them pattern recognition chops yet. I was hoping to build up that skill by finding a tool that did it for me so I could have these patterns thrown in my face over and over.
TL:DR - Anyone know of a tool that does these eta-reductions/vice-versa for you? (Specifically in Haskell)

[@fernandooliveira266]

Yeah, in haskell there is a program called "point-free". If you use vim you can try it by github.com/m00qek/vim-pointfree

[@Argletrough]

hmm...
exactMatches in APL: +/=

[@SergeyPedan]

What sorcery is this

[@MyAce8]

in case anyones curious the way you do the three argument blackbird is (.) . (.) . (.) or (.) . (...) where "..." is blackbird

[@DanDart]

Fun fact: it's called Bunting, or B2.

[@philipschloesser]

Nice way to see (and generalise) this: fmap . fmap . fmap (or any composition of fmaps) has the type (Functor f, Functor g, Functor h) => (a -> b) -> f (g (h a)) -> f (g (h a)), so it is the fmap of the functor you obtain by composing the functors f, g, and h. Now, if we consider the special case of our functors being reader functors, i.e. (->) e, then we just have fmap = (.). So (.) . (.) . (.) takes an a -> b to an (x -> y -> z -> a) -> (x -> y -> z -> b)

[@acykablyatley]

​@@DanDartor ..... ;)

[@magne6049]

Point free programming is actually less expressive, not more. Because you express less, and being more implicit. Tacit means silence as you say. More silence is less expression.

[@glialcell6455]

Haha if you want to write code like that so badly Joy would be a much better fit than Haskell.