←back to thread

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

(www.youtube.com)
296 points gyre007 | 7 comments | 17 Oct 19 10:10 UTC | HN request time: 0s | source | bottom
Show context
lewisjoe ◴[17 Oct 19 10:57 UTC] No.21280702[source]▶
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.

replies(13): >>21280720 #>>21280760 #>>21280800 #>>21280835 #>>21280855 #>>21281061 #>>21281225 #>>21281281 #>>21281464 #>>21282667 #>>21283371 #>>21286296 #>>21288188 #
strangenessak ◴[17 Oct 19 11:19 UTC] No.21280835[source]▶
> 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-...

replies(13): >>21280936 #>>21280977 #>>21281011 #>>21281055 #>>21281385 #>>21281396 #>>21281653 #>>21281843 #>>21281990 #>>21282883 #>>21283119 #>>21283649 #>>21283658 #
1. antisemiotic ◴[17 Oct 19 11:39 UTC] No.21280936[source]▶
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 ]

replies(1): >>21281073 #
2. p33p ◴[17 Oct 19 12:00 UTC] No.21281073[source]▶
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)

replies(1): >>21281397 #
3. strangenessak ◴[17 Oct 19 12:41 UTC] No.21281397[source]▶
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.....
replies(3): >>21281736 #>>21281828 #>>21282639 #
4. pkilgore ◴[17 Oct 19 13:22 UTC] No.21281736{3}[source]▶

    [butter, sugar, walnuts]
    ^^^
     Somewhere wanted type CakeIngredients but missing record field "Flour"
If imperative style programming came with type inference on the level of the Ocaml compiler sign me up. For now, though, I can spare a few cycles in exchange for correct programs.
5. antisemiotic ◴[17 Oct 19 13:31 UTC] No.21281828{3}[source]▶
Careful, somewhere along that line you might even come to a conclusion that Haskell is world's most advanced imperative language, with the reprogrammable semicolons and whatnot.
replies(1): >>21282242 #
6. twic ◴[17 Oct 19 14:12 UTC] No.21282242{4}[source]▶
Or, to coin a phrase: https://apps.dtic.mil/dtic/tr/fulltext/u2/a030751.pdf
7. meijer ◴[17 Oct 19 14:50 UTC] No.21282639{3}[source]▶
But this doesn't handle the state. It is not working imperativ code.