Doing Functional Things in Procedural Languages

In general, functional programmers like to use "you can't do this" as a stand-in for "the compiler does not guarantee that this is done".

E.g.,

• "You can't make a pure function" → "From a function signature alone, you cannot determine whether or not it affects global state or mutates variables"
• "You don't have strong types" → "You don't have GADTS, and the type manipulations that you can do provide escape hatches"⁴

I find this unhelpful, because something can still be useful even if it is not enforced by the compiler. It will require discipline from the programmer, but it's still there, so it all comes down to what you, the user, really care about the most⁵

I also want to note that the gap between functional programmers and procedural programmers appears to have ben influenced largely by object orientation, paired with bad compilers for early functional languages⁶. OO appears to have convinced most working programmers⁷ that typing was about creating a hierarchy. A particularly salient example is Rob Pike's reasoning as to why Go doesn't really "do" types (emphasis mine):

One thing that is conspicuously absent is of course a type hierarchy. Allow me to be rude about that for a minute.

…

But more important, what it says is that types are the way to lift that burden. Types. Not polymorphic functions or language primitives or helpers of other kinds, but types.

That's the detail that sticks with me.

Programmers who come to Go from C++ and Java miss the idea of programming with types, particularly inheritance and subclassing and all that. Perhaps I'm a philistine about types but I've never found that model particularly expressive.

My late friend Alain Fournier once told me that he considered the lowest form of academic work to be taxonomy. And you know what? Type hierarchies are just taxonomy. You need to decide what piece goes in what box, every type's parent, whether A inherits from B or B from A.

He never discusses functional-style types (i.e., sum & product types)⁸. He views types as not "what is this thing and what makes sense to do with it" but "where does this thing fit in my hierarchy." No wonder then that EE-type⁹ programmers refuse to listen to functional expositions on the utility of type-based thinking, all they expect to hear is another rendition of shuffle your papers around on your desk for a week before you can actually do anything¹⁰.

So, if the compiler isn't enforcing correctness, what's the point of these mechanisms? Well, just because a compiler doesn't do something doesn't mean you can't. So this allows you to apply functional thinking, use functional algorithms, golf¹², and avoid step-debugging where possible.

This is pretty straightforward. Most procedural languages allow you to write recursive functions¹³, and most of their compilers support tail call optimization.

Easily done if you have access to function pointers or an equivalent. The Commander wrote a library(?) for map & reduce, though he doesn't use it.

This is more of a discipline thing. Just don't mutate variables, and if you have to, mark them with a lil Hungarian thing¹⁴.

Again, if you have function pointers or similar, you have higher-order functions¹⁵.

Like immutability, it's a discipline thing, but it's not super difficult to pull off.

This is a bit trickier. You will usually have enums & discriminated unions for sum types, but enums tend to be represented by integers or booleans, and discriminated unions may or may not have escape hatches, so once more it falls on the programmer to verify behavior and not fat-finger themselves into illegal states.