←back to thread

296 points gyre007 | 1 comments | | HN request time: 0s | 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 #
gambler ◴[] No.21286747[source]
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 the assumption that OO was born out complete ignorance of functional programming, even though people who kick-started its rise were keenly aware of Lisp (for example, Alan Kay frequently references McCarthy's work and research papers in his talks). Etc, etc.
replies(5): >>21287162 #>>21287371 #>>21287400 #>>21287762 #>>21287810 #
1. joe_the_user ◴[] No.21287762[source]
The thing about these discussions is they seem to have two different questions mixed together. One question is "what's the best way to produce good software in a circumstance where everyone start on top of their game and the right thing" and the other is "what's a sort-of natural, slightly better average, way that programming can be." The answer to the first can be "Good functional Programming" or "Good OOP" or maybe something even more exotic. But it doesn't matter that much for the second question. Because usually the question of "how can this code we have already be better" mean "how do you take a general mess and make salvagable?" I don't know what the FP's answer to this is. I generally get the feel the FP people don't want to have an answer to this because then there'd be a lot of better-but-still-bad installations out there. But there are plenty answers to improvement using OOP - most say just encapsulate everything or similar things. All sorts of things can be thinly encapsulated, better, but still far from good. That seems to me explain the prevalence of OOP.