functions

I try to not mention other blogs, or posts, or things like that. Unfortunately, it is needed. So, here we are.

Some time ago, I found this what color is your function post. I though, originally, that the “color” there was supposed to be a metaphor for other stuff, kind of like how the post about Railroad Oriented Programming was just the Either monad in an easier to digest format.

Turns out… people started to use this argument to explain why some language/library is better than other. And that is weird, and wrong, for a simple reason: there’s no such thing as “color-based function”.

Ok, I’ll say it again: there is NO SUCH THING as color-based function. And I’ll go further: this whole post is a complete lack of understanding about types, and I’m speaking as someone that likes, and prefers dynamic-typed languages, so you can imagine how freaking wrong the original author is. So let’s dive into the types, shall we?

So, I’ll start with this innocent function: nothing “async” about it:

registerCallback(f: (p: number) => number): void {
  self.callback = f
}

For those that are not familiar with Typescript notations, this is basically a function that accepts another function, which the first argument is a number, and the return is a number. This registerCallback function (method, really) returns nothing, or void. So far, so good. The type of this function is ((p: number) => number) => void, or in Java’s notation, Function<Function<number, number>, void>.

Now, how can I convert ((p: number) => number) => void to ((p: number) => number) => number? Well, if you know anything about static type systems, you know that… well… you can’t. You actually can’t. It’s impossible. Nothing is compatible here. And, guess what? The same is true for Promise types.
(more…)