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

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

#291

Post by hootbootscoot » Thu, Oct 17, 2019, 11:43 PM UTC

gambler wrote: post #267

mbo wrote: post #254

EDIT: I wrote this comment before watching the video. I stand by this comment, but the video is very good and I wholeheartedly agree with its conclusions. As someone who writes pure FP for a living at a rather large and well known org, these threads physically hurt me. They're consistently full of bad takes from people who don't like FP, or haven't written a lick of it. Subsequently, you get judgements that are chock…

What a coincidence. This sounds exactly like what happens with OOP. Every discussion here gets swarmed with clueless people who think Java is the apex of OO programming, because that's what gets taught in universities these days. They don't understand any of the core concepts that prompted Xerox Park to develop the OO paradigm in the first place. They aren't aware of any of the relevant research. They operate under t…

Good OOP is good FP - they swim in the same water. composition, generics/adt's, elegance, encapsulation...

In it's ideal form it's about taming the metal like a trick pony.

I'm nowhere near that level, being a fortran in any language sorta guy lol, but when I see well-built stuff, I take notes. Matryushka dolls, lol

Kay et al were swimming in the same water as Hewitt etc, conceptually. He said that the key takeaway from OOP was objects passing messages (actor model), not so much the inheritance story (the composition)

but yes, they all criss-cross there

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

#292

Post by senderista » Thu, Oct 17, 2019, 11:48 PM UTC

gambler wrote: post #267

mbo wrote: post #254

EDIT: I wrote this comment before watching the video. I stand by this comment, but the video is very good and I wholeheartedly agree with its conclusions. As someone who writes pure FP for a living at a rather large and well known org, these threads physically hurt me. They're consistently full of bad takes from people who don't like FP, or haven't written a lick of it. Subsequently, you get judgements that are chock…

What a coincidence. This sounds exactly like what happens with OOP. Every discussion here gets swarmed with clueless people who think Java is the apex of OO programming, because that's what gets taught in universities these days. They don't understand any of the core concepts that prompted Xerox Park to develop the OO paradigm in the first place. They aren't aware of any of the relevant research. They operate under t…

I think the Smalltalk paradigm is deeply defective and the Actor model (the purest form of OOP to my mind) remedies most of its faults but perpetuates some others. A few flaws:

- Modeling all communication as synchronous message-passing. Some communication (such as evaluating mathematical functions) is naturally modeled as synchronous procedure calls, while communication which is naturally modeled as message-passing should be asynchronous by default (to address unpredictable latency, partial failure, etc.).

- Emphasizing implementation inheritance as the primary means of code reuse. This is now generally acknowledged to be a mistake, so I won't elaborate.

- Deferring all method resolution to runtime. This makes the amazing introspective and dynamic capabilities of Smalltalk possible, but it also makes it impossible to statically verify programs for type-correctness.

- Relying on mutable local state rather than explicit, externalized state. This is controversial, and it's a defect of the Actor model as well (yes, passing new parameters into a tail-recursive message receive loop is equivalent to mutating local state). The partisans of OOP and the Actor model believe this to be a virtue, enabling robust emergent collective behavior from small autonomous software agents, but it makes predicting large-scale behavior difficult and debugging nearly impossible.

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

#293

Post by cesarb » Thu, Oct 17, 2019, 11:51 PM UTC

socksy wrote: post #185

hootbootscoot wrote: post #168

Earlier quoted context omitted.

OTOH, think of the vast hordes of new developers exposed to lot's of FP and NOT having that background in Amiga and PC and bare-metal programming that you do. FP has been largely introduced into the mainstream of programming through Javascript and Web Dev. Let that sink in. End of the day, the computer is an imperative device, and your training helps you understand that. FP is a perfectly viable high-level specificat…

"End of the day, the computer is an imperative device, and your training helps you understand that." I mean... it's not though, is it? Some things happen synchronously, but this is not the same thing as being an imperative device. Almost every CPU out there is multi core these days, and GPUs absolutely don't work in an imperative manner, despite what a GLSL script looks like. If we had changed the mainstream programm…

> but this is not the same thing as being an imperative device. Almost every CPU out there is multi core these days

The interface to the CPU is imperative. Each core (or thread for SMT) executes a sequence of instructions, one by one. Even with out-of-order and speculation, the instructions are executed as if they were executed one by one.

> and GPUs absolutely don't work in an imperative manner, despite what a GLSL script looks like.

They do. Each "core" of the GPU executes a sequence of instructions, one by one, but each instruction manipulates several separate copies of the state in parallel; the effect is like having several identical cores which operate in lockstep.

> If we had changed the mainstream programming model years ago, perhaps chip manufacturers would have had more freedom to break free of the imperative mindset, and we could have radically different architectures by now?

The cause and effect are in the opposite direction. The "imperative mindset" comes from the hardware. Even Lisp machines used imperative machine code (see https://en.wikipedia.org/wiki/Lisp_machine#Technical_overvie... for an example).

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

#294

Post by dragonwriter » Thu, Oct 17, 2019, 11:58 PM UTC

cesarb wrote: post #293

socksy wrote: post #185

Earlier quoted context omitted.

"End of the day, the computer is an imperative device, and your training helps you understand that." I mean... it's not though, is it? Some things happen synchronously, but this is not the same thing as being an imperative device. Almost every CPU out there is multi core these days, and GPUs absolutely don't work in an imperative manner, despite what a GLSL script looks like. If we had changed the mainstream programm…

> but this is not the same thing as being an imperative device. Almost every CPU out there is multi core these days The interface to the CPU is imperative. Each core (or thread for SMT) executes a sequence of instructions, one by one. Even with out-of-order and speculation, the instructions are executed as if they were executed one by one. > and GPUs absolutely don't work in an imperative manner, despite what a GLSL…

> The interface to the CPU is imperative. Each core (or thread for SMT) executes a sequence of instructions, one by one. Even with out-of-order and speculation, the instructions are executed as if they were executed one by one.

That is, in the traditional model of declarative programming, the semantics given are guaranteed, but the actual order of operations are not. So, in a sense, the CPU takes what could be construed as imperative code, but treats it as declarative rather than imperative.

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

#295

Post by Supermancho » Fri, Oct 18, 2019, 12:08 AM UTC

chubot wrote: post #273

yogthos wrote: post #209

Earlier quoted context omitted.

The point here is that for many domains performance is not the top consideration. And it's also worth noting that it's perfectly possible to tune applications written in FP languages to get very good performance. It's also possible to identify the parts of the code that are performance critical and implement those using imperative style. This is especially easy to do with Clojure where you have direct access to Java.…

Sure I get that, but I'm saying your statement about "the overall historical trend" is wrong, or at least fails to capture a large part of the truth. At some point in history, people stopped worrying about not understanding compilers This part is misleading too -- I would say there is a renaissance in compiler technology now. For the first 10 years of my career I heard little about compilers, but in the last 10, JS E…

Once parallel execution became part of every design discussion that had a performance concern, the vast majority of programmers stopped caring (and consequently talking) about compilers. Who cares if you can do 36k requests/s to my 18k if I can do 36k across 2 or 3 machines? I pass that on to the customer. Why try to hire for or wait around for an optimization trick to double performance (that will likely never be realized or discovered) when there's business to be done? The post-optimization is pure profit and can be quantified, so might as well wait and let some specialist (who does care about compilers) handle it if the product ends up being valuable enough to hire them. This is how development and hiring works today.

> At some point in history, people stopped worrying about not understanding compilers

> This part is misleading too

Not in the least. Interpreting that to mean "all people stopped worrying" is deliberate misinterpretation.

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

#296

Post by senderista » Fri, Oct 18, 2019, 12:08 AM UTC

cryptica wrote: post #165

stickfigure wrote: post #146

Earlier quoted context omitted.

I don't quite follow this. You can create (very complicated) immutable objects that encapsulate their state, and provide methods that return new immutable objects with different - and still fully encapsulated - state. Vavr is a good example.

Yes you can reduce and map a large state object into a smaller and simpler object before you pass it down to a child component but the encapsulation is still leaky because the parent component needs to know the implementation details of each action of a child component in order to use them correctly (for example, the parent component needs to know how the different actions of the child relate to each other in terms o…

I think some of the spirit of encapsulation (i.e., decoupling from implementation) is achieved by polymorphic functional interfaces, e.g. type classes in Haskell.

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

#297

Post by stillwater56 » Fri, Oct 18, 2019, 12:14 AM UTC

mbo wrote: post #254

EDIT: I wrote this comment before watching the video. I stand by this comment, but the video is very good and I wholeheartedly agree with its conclusions. As someone who writes pure FP for a living at a rather large and well known org, these threads physically hurt me. They're consistently full of bad takes from people who don't like FP, or haven't written a lick of it. Subsequently, you get judgements that are chock…

I'm just starting to dabble in Scala, and as someone who has actually created lecture content, is there a resource you would particularly recommend?

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

#298

Post by mbo » Fri, Oct 18, 2019, 12:20 AM UTC

jasode wrote: post #281

mbo wrote: post #266

Earlier quoted context omitted.

> Why does functional programming need to be taught in schools but all the other various programming topics did not? Because I think it is harder for people who have programmed with other paradigms - following an inverse law, most things should get easier to learn with experience, not harder. It's foreign, it's weird, it's back to front. It doesn't have an immediately obvious benefit to what people are used to, and t…

>Because I think it is harder for people who have programmed with other paradigms I still think there's something missing in your theory of cause-&-effect. A math topic like quaternions is hard and yet programmers in domains like 3d graphics and games have embraced it more than FP. I also think Deep Learning / Machine Learning / Artificial Intelligence is even more difficult than Functional Programming and it seems l…

> Why can't FP's benefits be obvious so that it doesn't require evangelists?

Because there aren't immediate benefits. They only pop out at scale and with complexity, as I said.

> similar real world massive productivity improvement to Imperative Programming

Because there isn't. It's a reasonable benefit, but it's not transformative. I think it's there, enough to commit to FP completely, but the massive productivity improvement doesn't exist, or at least, only exists in specific cases, e.g. the WhatsApp + Erlang + 50 engineers parable (you could argue that this is due to the actor model and BEAM, rather than FP. An argument for a different day).

I feel like this hard + reasonable benefit isn't really efficient utilisation of people's time, especially when there's things like Deep Learning floating around. I think the immediate reaction to a lot of what FP evangelists claim is a shrug and a "I guess, but why bother?"

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

#299

Post by dzonga » Fri, Oct 18, 2019, 12:20 AM UTC

as someone who made my first SPA, using Elm & met the presenter once in NY. functional programming is elegant and nice. but practicality is another different matter. for it, to be the norm, it has to have 10x advantages over the status quo. on the frontend, part JS already offers some features of functional programming, with some imperative parts. On the backend, none of the functional languages you would want to use such as Ocaml match say the ecosystems of Python, Java, Node.js & .Net world.Hell even F# which is an excellent language, is treated like the bastard step son of Microsoft

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

#300

Post by ummonk » Fri, Oct 18, 2019, 12:22 AM UTC

mbo wrote: post #254

EDIT: I wrote this comment before watching the video. I stand by this comment, but the video is very good and I wholeheartedly agree with its conclusions. As someone who writes pure FP for a living at a rather large and well known org, these threads physically hurt me. They're consistently full of bad takes from people who don't like FP, or haven't written a lick of it. Subsequently, you get judgements that are chock…

>Subsequently, you get judgements that are chock full of misconceptions of what FP actually is

I put the blame for that squarely on the Haskell cultists. They've caused everyone to have the impression that functional programming needs to have esoteric syntax and lazy evaluation by default.

It's like how the Java cultists have ruined OOP.