←back to thread

296 points gyre007 | 3 comments | | HN request time: 0.655s | source
Show context
mbo ◴[] No.21286487[source]
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 full of misconceptions of what FP actually is, and the pros and cons outsiders believe about FP are completely different from its practitioners. It's always some whinge about FP not mapping "to the metal", which is comical given say, Rust's derivation from what is quite functional stock.

My personal belief? We just don't teach it. Unis these days start with Python, so a lot of student's first exposure to programming is a multi-paradigm language that can't really support the higher forms of FP techniques. Sure, there may be a course that covers Haskell or a Lisp, but the majority of the teaching is conducted in C, C++, Java or Python. Grads come out with a 4 year headstart on a non-FP paradigm, why would orgs use languages and techniques that they're going to have to train new grads with from scratch?

And training people in FP is bloody time consuming. I've recorded up to 5 hours of lecture content for devs internally teaching functional Scala, which took quadruple the time to write and revise, plus the many hours in 1-on-1 contact teaching Scala and Haskell. Not a lot of people have dealt with these concepts before, and you really have to start from scratch.

replies(7): >>21286652 #>>21286660 #>>21286747 #>>21286935 #>>21287544 #>>21287591 #>>21287775 #
jasode ◴[] No.21286652[source]
>My personal belief? We just don't teach it.[...] Grads come out with a 4 year headstart on a non-FP paradigm,

I don't agree the lack of proactive education is the reason FP isn't the norm. Your conclusion doesn't take into account the counterfactuals:

- C Language took off in popularity despite BASIC/Pascal being the language more often taught in schools

- languages like PHP/Javascript/Python/Java all became popular even though prestigious schools like MIT were teaching Scheme/Lisp (before switching to Python in 2009).

You don't need school curricula to evangelize programming paradigms because history shows they weren't necessarily the trendsetters anyway.

On a related note, consider that programmers are using Git DVCS even though universities don't have formal classes on Git or distributed-version-control. How would Git's usage spread with everybody adopting it be possible if universities aren't teaching it? Indeed, new college grads often lament that schools didn't teach them real-world coding practices such as git commands.

Why does Functional Programming in particular need to be taught in schools for it to become a norm but all the other various programming topics do not?

replies(2): >>21286737 #>>21287241 #
mbo ◴[] No.21286737[source]
> 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 the benefits it has come at scale and up against the wall of complexity (in my opinion). It's hard to adopt upfront. At the small scale it's often painful to use. The syntax is weird. It's aggressively polymorphic, reasoning in abstractions rather than concretions. I could go on (and yet I still adore it).

The only reason FP has been successful as it is, is because its evangelists are incredibly vocal, to the point of being fucking annoying sometimes. It's had to be forced down people's throats at times, and frankly, there's no better place to force a paradigm down someone's throats than at a university, where non-compliance comes at academic penalty, and when the mind is most impressionable.

replies(3): >>21286842 #>>21287111 #>>21287605 #
Mirioron ◴[] No.21287605[source]
>It's had to be forced down people's throats at times, and frankly, there's no better place to force a paradigm down someone's throats than at a university, where non-compliance comes at academic penalty, and when the mind is most impressionable.

That's also a great way to make people hate it. An example is literature classes with mandatory reading and how they make students hate reading fiction.

I would also say that this might turn off more students from programming. We had functional programming in uni, where we learned Haskell. Maybe a handful of students liked it or were neutral about it, the vast majority seemed to have a negative view of it.

I think that FP is just more difficult to learn. Just look at essentially any entry level programming course and how people understand loops vs recursion.

replies(1): >>21287635 #
mbo ◴[] No.21287635[source]
Okay, so FP is more difficult to learn. Assume for the sake of this argument that FP has a tangible benefit over other paradigms, that manifest themselves at scale. You're tasked with educating students in this paradigm, but they complain that it is more difficult than the techniques that they are used to.

What do you do?

replies(3): >>21287709 #>>21287714 #>>21287744 #
ukj ◴[] No.21287714[source]
I validate your assumption against reality.

If FP is not mandatory at Google-scale, it isn’t mandatory at your scale.

The kind of problems that emerge at scale are not the kind of problems FP tackles.

replies(1): >>21288122 #
1. mbo ◴[] No.21288122[source]
Sorry, I mean scale as in "large scale projects".

Spark is the quintessential Google-scale FP project - it was even born out of the MapReduce paper by Google!

And there's plenty of other large-scale projects that are arguably in an FP style specifically to deal with the problems associated with scaling them: the Agda/Isabelle proof checkers, the seL4 kernel, the Chisel/FIIRTL project, Erlang/OTP, the Facebook Anti-Spam system (built on Haxl), Jane Street's massive investment into OCaml, Twitter's investment into Scala.

Not all scale problems are distributed problems. Some distributed problems are tackled by FP, and some aren't. Ultimately, these large-scale projects pop up at similar rates to the usage of the language themselves. It's intellectually dishonest to say that FP can't be used to tackle large scale problems, and the problems that occur at scale, because its repeatedly validated that it can.

replies(1): >>21289189 #
2. ukj ◴[] No.21289189[source]
It is also intellectually dishonest to strawman an argument.

I didn’t say it is impossible to do X with FP - I said it is not necessary to do X in FP. You can convince yourself of that by looking for larger-scale non-FP counter-examples to the ones you've cherry-picked.

Every single large scale problem is a distributed problem simply because human societies are multi-agent distributed systems and programming languages are human-computer interfaces.

The issues at scale are systemic and arise from the design trade-offs made when your system's requirements bumps against the limits of computation. No language/paradigm can work around those.

The best a language can do is abstract-away the complexities behind a problem - solve it once (in the language/paradigm's preferred way) and give the human an interface/concept to work with.

replies(1): >>21301296 #
3. mbo ◴[] No.21301296[source]
Okay, I got really confused by this whole mandatory thing. I never said FP should be mandatory at scale. I said it had a moderate benefit at scale. You respond with "well actually, it's not mandatory at Google-scale" so I assumed that you were trying to refute the fact that FP has benefit at scale.

You also followed this up with

> The kind of problems that emerge at scale are not the kind of problems FP tackles.

I cherry picked these examples to demonstrate that you're completely talking out of your ass here.

> I didn’t say it is impossible to do X with FP - I said it is not necessary to do X in FP. You can convince yourself of that by looking for larger-scale non-FP counter-examples to the ones you've cherry-picked.

I never said it wasn't possible to tackle these problems without FP.

You need to get rid or the assumption that "if X is better than Y at task Z, everyone will use X rather than Y for task Z". You've used that line of logic to attempt to invalidate FP's capabilities. It simply does not make sense.