←back to thread

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

(www.youtube.com)
296 points gyre007 | 6 comments | 17 Oct 19 10:10 UTC | HN request time: 0.255s | 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. mbrock ◴[17 Oct 19 11:56 UTC] No.21281055[source]▶
I actually don't know of any functional programming languages that don't have syntactic and semantic support for writing step-by-step algorithms.
replies(2): >>21281153 #>>21281201 #
2. pas ◴[17 Oct 19 12:12 UTC] No.21281153[source]▶
Could you elaborate on this a bit? Basically calling a functions form an other is how a step-by-step algorithm would work in FP, no? And pattern match on what comes in, and return an immutable copy.

For example you can put functions in a list, and push a datastructure through them, like a pipeline.

edit: https://probablydance.com/2016/02/27/functional-programming-...

replies(2): >>21281290 #>>21286309 #
3. stingraycharles ◴[17 Oct 19 12:19 UTC] No.21281201[source]▶
The same can be said about imperative languages supporting FP concepts: they have it, but it's just not the same.
4. pyrale ◴[17 Oct 19 12:30 UTC] No.21281290[source]▶
The control structure that takes the different functions/values and glue them together is what makes your code imperative or descriptive. While there is a lot of overlap between descriptive style and fp, it is not always the case.

In haskell, for instance, the do notation lets you write imperative code:

    f  article = do 
       x <- getPrices article
       y <- book article
       finishDeal article x y
...and then the compiler desugars it to a more descriptive form.
replies(1): >>21288303 #
5. gowld ◴[17 Oct 19 20:58 UTC] No.21286309[source]▶
You miscounted the number of negatives in the comment you replied to.
6. gmfawcett ◴[18 Oct 19 03:00 UTC] No.21288303{3}[source]▶
In fairness, we could be in the List monad here, and this would effectively be a list comprehension rather than an imperative program. Even if we are in IO, `getPrices` and `book` may never execute --- even `finishDeal` may never execute! --- depending on non-local details that aren't shown here.

The code certainly "looks imperative" but it's still a declarative program --- the semantics are rather different from what a typical "imperative programmer" would expect.