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.

Even in maths, I find a solution in terms of the problem easier to understand than one in terms of the previous step.

Even when the recursive form is a more natural representation, like arithmetic sequences: start at s, increase by d with each step:

  a(0) = s, a(n) = a(n-1)+d

  a(n) = s + n*d

The analytical form seems simpler, neater, more "right" and more efficient to me - even though, if you want the whole sequence, the recursive form is more efficient (given tail-call optimisation).

I suspect I'm just not smart enough.

fp can be much shorter, and the execution model isn't actually hidden, just unfamiliar (and unintuitive and unnatural - for me). Consider: all suffixes of a list. In jq:

  while( length>0; .[1:] )

This doesn't look to me like the difference between functional and imperative so much as the difference between recursion / iteration and map / list comprehension.

You may need to exercise some charity here.

I've been trying to see why fp isn't intuitive for me.

I suspect it's like a second (human) language acquired as an adult: only those with a talent for language (maybe 5%?) can become fluent with practice.

Regarding my first example, I see recursion (or induction) as the essence of fp; and the recurrence form of arithmetic sequences is the simplest recursion I've seen used in mathematics.

The explicit form in that example is harder to justify as "imperative". But a commonality of imperative style is referring to the original input, rather than a previous step (see the first line of my above comment). This isn't the literal meaning of "imperative", but may be a key distinction between fp and ip style - the one that causes the intuitive/fluency issue for me.

To illustrate using my third (jq) example of suffixes, here's an "imperative" version, in py-like psuedocode:

  for i = 1 to length
    # a suffix
    for j = i to length
      print a[j]
    print \n

This is so much longer than jq (though shorter if used .[j:]), but it is how I understand the problem, at first and most easily.

It always refers to the starting input of the problem, not the previous step, and this might be why it's easier for me.

I'm interested in your comment - could you elaborate please? There's a few ways to relate your comment to different parts of mine, and I'm not sure which one was intended.

Well I agree with you that that kind of recurrence (which mathematicians love to use so much, as do some functional programmers who're overly influenced by math) is not very intuitive and frankly is a programming anti-pattern in my view.

But I disagree with you that recursion is the essence of fp. For your concrete example, a more functional version of doing that (in Python) would be something like:

  print("\n".join(a[i:] for i in range(len(a)))

No need to reuse f(i-1) when you can express f(i) directly.

Reusing the previous step (whether it is using recursion, rising intermediate computations in the form of local variables in a loop, or through a fold) should only be done when absolutely necessary.

> [recurrence] is not very intuitive and frankly is a programming anti-pattern in my view. [...] Reusing the previous step ... should only be done when absolutely necessary

Thanks, that's my main concern (fp was just an example). Would you agree the reason it is bad is becase there is more to track mentally in the execution model? (i.e. the intermediate results).

I think a complex execution model is problematic in general (it sounds obvious when I say it that way).

> which mathematicians love to use so much,

hmm... I was thinking "induction", and believed that fp is the same. .. > But I disagree with you that recursion is the essence of fp

This is BTW now, but that statement surprises me. Can you elaborate? What is the essencd of fp (has it one)?

Is your py version "more functional"? I'm so wedded to the idea that fp=recursion that that's the reason it doesn't seem functional to me. What makes it functional? Just that it's a nested expression (i.e. fn calls)?