Why Isn't Functional Programming the Norm? [video] • Hacker News Board

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

#131

Post by overgard » Thu, Oct 17, 2019, 2:42 PM UTC

bpyne wrote: post #125

I think we need to get past the point of believing in some FP revolution in which enlightenment happens and people suddenly switch to Haskell, OCaml, Clojure, etc. FP is happening in a more evolutionary way with newer languages like Kotlin, Scala, F#, etc. taking ideas from Haskell, SML, and Lisp. I'm not pretending to be the first to state this observation but I feel like it needs reinforcement here.

I think most of the growth of FP is coming from libraries and hybrid languages. Things like React and Redux and streams/linq style operations on data structures, or default immutability. I don’t think “pure” languages will ever really become dominant but a lot of the best ideas are being borrowed.

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

#132

Post by Symmetry » Thu, Oct 17, 2019, 2:47 PM UTC

tom_mellior wrote: post #96

Ragib_Zaman wrote: post #62

Earlier quoted context omitted.

Perhaps not a satisfactory response but when I start drifting towards thinking FP is fundamentally not as performant as _whatever_else_, I remember that Jane Street uses OCaml basically from top to bottom, and they certainly can't be too slow... Some black magic going on there.

The "oh no it's slow, and you can't reason about performance" FUD is mostly directed at Haskell's lazy evaluation, but people like to throw it vaguely in the direction of "FP" in general. Most of the performance problems you have in Haskell (as in this recent submission: https://news.ycombinator.com/item?id=21266201 ) are not problems you will have in OCaml. Yes, OCaml has garbage collection. It's a very efficient GC…

Something I've always wondered about Haskell. Given referential transparency, purity, etc shouldn't it be possible for the Haskell compiler to choose whether to evaluate something in an eager or lazy fashion depending on performance heuristics under the covers? You have to make sure you don't ever accidentally do that with an infinite list but it seems that there ought to be lots of scope for optimization and speeding up code written in a straightforward fashion. Possibly also turning lists into arrays secretly too if it can be proven to produce the same result.

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

#133

Post by AlexandrB » Thu, Oct 17, 2019, 2:47 PM UTC

This video exists in an alternate reality where marketing departments do not. Many of these languages became popular not because of some intrinsic property, but because of a strong marketing push by one or more backing companies. There was a period of time, not so long ago, where "object oriented" was basically a checkbox on language marketing copy, and if your language didn't have it you would get scoffed at.

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

#134

Post by meijer » Thu, Oct 17, 2019, 2:50 PM UTC

strangenessak wrote: post #76

p33p wrote: post #42

Earlier quoted context omitted.

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.....

But this doesn't handle the state. It is not working imperativ code.

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

#135

Post by EpicEng » Thu, Oct 17, 2019, 2:50 PM UTC

Torwald wrote: post #36

chii wrote: post #28

Earlier quoted context omitted.

but now that you've written the cake baking data type, with a little small tweak, you've got a bread baking data type.

I'd rather have a baking class that takes an argument for what I want to bake, either bread or cake, and spares me the details of how baking is done. I don't have to know that a preheated oven is one that is at 175 grades etc

And when your oven has a problem with it's heating element you'll have no idea why your cake didn't turn out well. We're supposed to be engineers, right? Learning how things work is good.

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

#136

Post by meijer » Thu, Oct 17, 2019, 2:52 PM UTC

lewisjoe wrote: post #6

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 wi…

The link is NSFW.

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

#137

Post by overgard » Thu, Oct 17, 2019, 2:55 PM UTC

cryptica wrote: post #115

OOP was designed to prioritize encapsulation at the expense of referential transparency. Functional programming was designed to prioritize referential transparency at the expense of encapsulation. You cannot have referential transparency and encapsulation at the same time. In order to prevent mutations (which is a requirement of FP), a module cannot hold any state internally; this necessarily means that the state mus…

Encapsulation is desirable because it limits the possibility space of what can operate on a set of data. Referential transparency is desirable because pure programs are much easier to reason about. If I understand what youre saying, it seems youre saying referential transparency and encapsulation are at odds and encapsulation is more valuable, but I disagree. Hiding state maybe keeps things tidy and enforces that you need to use the API, but its not really the point IMO. The point of encapsulation is managing state mutations. Hiding state is only a small part. You dont need to hide state as much when its immutable because then you don’t need to care what other code is doing with your emitted data structures because it doesn’t effect you.

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

#138

Post by JustSomeNobody » Thu, Oct 17, 2019, 2:57 PM UTC

FpUser wrote: post #114

I got another question. Why don't those prophets leave intelligent people alone and let them use whatever tooling/approach they find appropriate for solving particular problem instead of heating the air trying to propagate/force whatever ideology they carry.

Because those profits don't think your definition of appropriate in this context is correct.

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

#139

Post by verttii » Thu, Oct 17, 2019, 3:08 PM UTC

Symmetry wrote: post #132

tom_mellior wrote: post #96

Earlier quoted context omitted.

The "oh no it's slow, and you can't reason about performance" FUD is mostly directed at Haskell's lazy evaluation, but people like to throw it vaguely in the direction of "FP" in general. Most of the performance problems you have in Haskell (as in this recent submission: https://news.ycombinator.com/item?id=21266201 ) are not problems you will have in OCaml. Yes, OCaml has garbage collection. It's a very efficient GC…

Something I've always wondered about Haskell. Given referential transparency, purity, etc shouldn't it be possible for the Haskell compiler to choose whether to evaluate something in an eager or lazy fashion depending on performance heuristics under the covers? You have to make sure you don't ever accidentally do that with an infinite list but it seems that there ought to be lots of scope for optimization and speedin…

The point of lazy evaluation is to evaluate something only when you really need it. Not to auto-adjust the system performance wise. You can force eager evaluation in places where you want it evaluated sooner.

Personally, I think consistency is more important here because it leads to better predictability. If you don't know whether the compiler assigns something to be evaluated lazily or eagerly that could lead to a lot of nasty debugging issues.

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

#140

Post by denton-scratch » Thu, Oct 17, 2019, 3:12 PM UTC

strangenessak wrote: post #19

lewisjoe wrote: post #6

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 wi…

> 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 ba…

Never seen that before, thanks! It's very funny.

I can't write Lisp to save my life, but I know roughly how you're supposed to do it.