Why Isn't Functional Programming the Norm? [video]

Richard Gabriel’s famous essay “Worse is better” (https://www.jwz.org/doc/worse-is-better.html) is an interesting perspective on why Lisp lost to C. In a way, the same arguments (simplicity vs consistency vs correctness vs completeness) can be made for why functional programming lost to OOP.

But those philosophical perspectives aside, personally I find my brain works very much like a Turing Machine, when dealing with complex problems. Apart from my code, even most of my todos are simple step-by-step instructions to achieve something. It’s easily understandable why like me, other non-math folks would prefer a Turing Machine over Lambda Calculus’ way of writing instructions.

This could be why OOP/Imperative was often preferred over FP.

> personally I find my brain works very much like a Turing Machine

Exactly this. How baking a cake in FP looks like:

* A cake is a hot cake that has been cooled on a damp tea towel, where a hot cake is a prepared cake that has been baked in a preheated oven for 30 minutes.

* A preheated oven is an oven that has been heated to 175 degrees C.

* A prepared cake is batter that has been poured into prepared pans, where batter is mixture that has chopped walnuts stirred in. Where mixture is butter, white sugar and brown sugar that has been creamed in a large bowl until light and fluffy

Taken from here: https://probablydance.com/2016/02/27/functional-programming-...

And then you actually try to write it in a functional language, and end up with something like:

cake = map (cool . bake 30 175) . splitIntoPans $ mix [ butter, sugar, walnuts ]

I think partial application and pipe operators make this so very intuitive though:

[butter, sugar, walnuts] |> mix() |> splitIntoPans(pans = 3) |> bake(time = 30, temp = 175) |> cool(time = 5)

We can improve the syntax further

    [butter, sugar, walnuts]
    mix()
    splitIntoPans(pans = 3)
    bake(time = 30, temp = 175)
    cool(time = 5)

Hmm, wait a second.....