Function Calesthenics

ilja

Long ago, I discovered something called Object Calisthenics. The idea is that you write a program following a set of specific rules. The limitations these rules bring, force you to think in a more OOP way.

A year a go I wondered if a similar thing existed for Functional Programming. I didn't find anything, so I decided to try something myself, see https://codeberg.org/ilja/function_calesthenics

I hereby share it, so others who may be interested can check it out, and give thoughts and feedback. Do these rules make sense for the stated goal? Are there other things I should add to push for a more functional way of thinking? Are there rules who don't make sense at all? Or are there other adaptions who could improve it? Do you think it's an interesting exercise to begin with? If you tried it, do share your experiences!

In short, the challenge is the following; Write a program (doesn't have to be big), keeping the following limitations in mind.

1. assignments are not allowed

If your language requires assignments to define named functions and/or modules, then you are allowed to use assignments for that and only for that. And you should never re-define the variable you assigned the function/module to.

2. Don't use mutability

Assignments are not allowed, but if your object allows mutability through methods, you can work around that by claiming that you aren't actually using an assignment. This is false because inside the method you called, you are still doing an assignment. This rule makes it explicit that this is not allowed.

3. No imperative for/while/if/else/switch/case structures allowed

The idea of a function in functional programming, is really in the mathematical sense that you have an input who maps to an output. Imperative structures like for/while/if/else/switch/case don't do that. They tell your code "in this case, do this. In that case, do that", but they do not map an input on an output.

In functional languages, there is often also an if structure. Unlike the imperative counterpart, this structure does map an input on an output, making it an actual function. This is an example of how it could look, and this is allowed.

if(is_even(number), function(){return "yup, it's even alright"}, function(){return "that's so odd, I can't even"})

For loops, you can often make use of, and even chain, things like reduce, filter, or map (if you don't know these things, let me shamelessly link to an article where i explain these ). Another option is using recursion.

4. no repetition

Our code needs to remain somewhat clean. When we do something, we only do it once. The following is not allowed because we do the work str.split(":") twice.

break_string(str) {
  return {
    first_part: str.split(":")[0],
    second_part: str.split(":")[1]
  }
}

break_string("something:something else")

When you see that, it just screams at you to use an assignment like var splitted_string = str.split(":"), doesn't it. You aren't allowed to use an assignment, so that's not possible. But you are also not allowed to get away with it so easily. This rule forces you to think a bit more about how to handle this situation.

5. Only pure functions are allowed

As mentioned before, functions in functional programming are really functions in the mathematical sense. You have a set of possible input, a set of possible outputs, and you "map" an input to an output.

Reading/writing something from/to in-/output or a database, is not a function. Randomised output isn't possible in a function. Of course, these things are often required in a program. As such we will only allow it if you keep it on "the edges" of your program. Basically, write the "core" of your application in a functional way, then call that.

The following would be allowed

// This is the "core" of the program, where all the real logic happens
// This is purely functional
MyFunctionalModule {
 def echo(str){
   return str
 }
}

// Here we read and write from/to the console, and then call our functional program
// The non-functional things happen here, only here, and these are the only things allowed to happen here
console.log(
  MyFunctionalModule.echo(
    console.input("tell me what to echo")
  )
)

toast

It feels a little to the side of what the point is.
What are let-bindings if not scoped assignments?
What is an assoc in a pipe if not a redefinition (in a way)?
What is an if if not a more limited cond?

Like, in the 4 example, the typical solution to this would really be:

(fn break-string [s]
  (let [splitted (s:split ::)]
    [(first splitted) (rest splitted)]))

I definitely agree with 5, though.

I think the goal should be to think in terms of pipelines and data modifications.
The restriction I would put in place is: only expressions.

For instance (since we're using js as an example), you may not use functions, only lambdas (arrow functions).
And your lambdas may not open blocks, only have the singular expression.
Similarly, no if, only ?:, etc.

I think that alone would do a lot.

Hélène

Doesn't something like that work better in a language that's oriented towards functional programming? (much like object calisthenics would work better in a language that has objects 😄)

For point 3., I would use ?: as toast says; which feels more functional to me. ?: is the function, equivalent to if in most functional programming languages, but the syntax is infix. switch-case could be alike to a match-case depending on how you use it, except it can't return a value in most imperative languages.

For point 4., I agree with toast. MLs and many Lisps let you use lets which are scoped const bindings. Elixir's syntax hides this fact, but this is otherwise pretty much what Elixir does during compilation. Elixir (and Erlang) are functional, but Elixir makes some functional programming more convenient (for example, it lets you rebind variables, which Erlang does not let you do).

I think the main issue here is that 5. is rooted in mathematics but the rest isn't as much, while almost all of FP is very much deeply rooted in mathematics/lambda calculus (which is why bindings/assignments work the way they do, same for conditionals, mutability, etc.)

ilja

I don't know what is meant with let-binding or assoc, but do I understand correctly that you think the "assignments are not allowed" is not a good rule here?

Note that these are not necessarily good practices. The idea is to push people out of their comfort zone, so they force themselves to think differently, without requiring a change in the tooling that they are already used to. Maybe this should be clarified better 🤔

For the assignments rule; In Elixir, and also JavaScript, I consider a variable to be a function who maps nothing to a specific value. That's why you can do things like a = b = "something", or, in Elixir "something" |> do_something() (i.e. it always "returns" a value).

Basically,

let something = "something"

do_something(something)

is functionally equivalent to

function something() { return "something"}

do_something(something())

But this is not how people generally see it. Peoples brains are basically fuzzy-pattern-matching machines. "It has two long upside-down egg shaped ears on it's head? It's a bunny!", "The ears are pointy instead? It's a donkey!".

The reason why assignments aren't allowed, isn't because they are necessarily different. It's precisely because they are NOT different. But by forcing people to not use them in this form, it makes it more explicit that they should think about them as functions getting combined, rather than "I'm now assigning this value to this variable, and then we do something with it".

Does that make sense? If so, I should probably clarify this better. (And was this indeed the point being made?)

Wrt ?:, I didn't use that notation bc I thought it was too implementation dependent. But if the concept is known broadly enough, then it may indeed be a better example (combined with explaining why this is considered functional).

toast

I do honestly think that the biggest deal is using expressions.
The above is also equivalent to do_something("something"), which is now a single expression (unlike the other two).
Indeed, function something() { return "something"; } is also equivalent to let something = () => "something";, which is a variable assignment. To demonstrate this:

function a() { return "a"; }
a = () => "b";
a(); // => "b"

If I wanted to arbitrarily restrict people into something to make them think more functionally, indeed, I would say "your entire program should be one big nested expression", and then add some details about things like do being forbidden etc.

ilja

the problem is that if someone tells me "use expressions", I wouldn't know what they mean :3c