Most active commenters
  • gambler(4)

←back to thread

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

(www.youtube.com)
296 points gyre007 | 11 comments | 17 Oct 19 10:10 UTC | HN request time: 0.001s | source | bottom
Show context
mbo ◴[17 Oct 19 21:25 UTC] 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 #
1. gambler ◴[17 Oct 19 22:01 UTC] 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 #
2. thomascgalvin ◴[17 Oct 19 23:02 UTC] No.21287162[source]▶
> 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.

Realistically, Java (or something very much like it) is the apex of OOP, at least as most people will experience it. The Ur-example of OOP might be a beautiful, internally consistent vision of mathematical purity, but most of us will never experience it.

Similarly, Agile-fall is the most common form of Agile that people will experience, which is why we always fall into "no true Scotsman" territory when ~~arguing about~~ discussing it.

There is, I think, a disconnect between people who are primarily concerned with the beauty of software - simple models, elegant algorithms, and so on - and the people who are primarily concerned with getting their feature branch merged to master so their manager will let them go to their kid's soccer game.

The beauty of software is important, and there's value in trying to bring the useful, but more esoteric concepts of CS into the mainstream, but at the same time we need to be aware of the ground truth of software development.

replies(2): >>21287296 #>>21288034 #
3. gambler ◴[17 Oct 19 23:29 UTC] No.21287296[source]▶
>Realistically, Java (or something very much like it) is the apex of OOP [...]

By this logic Java Streams are the apex of functional programming and anyone who uses them is fully qualified to dismiss the paradigm, even if they don't know anything about proper functional languages.

4. hootbootscoot ◴[17 Oct 19 23:43 UTC] No.21287371[source]▶
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

5. senderista ◴[17 Oct 19 23:48 UTC] No.21287400[source]▶
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.

replies(2): >>21287849 #>>21288431 #
6. joe_the_user ◴[18 Oct 19 01:02 UTC] 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.
7. paulddraper ◴[18 Oct 19 01:12 UTC] No.21287810[source]▶
What are the best OOP languages? Smalltalk?

For FP I would reply Haskell/PureScript, OCaml, and Scheme.

replies(1): >>21287909 #
8. lazulicurio ◴[18 Oct 19 01:21 UTC] No.21287849[source]▶
There was an article on state in OOP posted here a few days ago that I found very thought-provoking[1]. The blog post and related youtube videos are pretty interesting as well[2][3][4].

[1] https://news.ycombinator.com/item?id=21238802

[2] https://medium.com/@brianwill/object-oriented-programming-a-...

[3] https://www.youtube.com/watch?v=QM1iUe6IofM

[4] https://www.youtube.com/watch?v=IRTfhkiAqPw

9. gambler ◴[18 Oct 19 01:36 UTC] No.21287909[source]▶
I don't know what's the best OOP language right now, but Pharo is pretty enjoyable to work with.
10. caseymarquis ◴[18 Oct 19 02:02 UTC] No.21288034[source]▶
This makes me appreciate working somewhere that feels kids' soccer games will always take precedence over merging features. I also use hybrid actors/oop extensively. I'd never really considered that these probably go hand in hand.
11. gambler ◴[18 Oct 19 03:34 UTC] No.21288431[source]▶
All of this has been addressed zillion times. Modern Smalltalk dialects have actor libraries and have code reuse mechanisms that don't involve inheritance. There are ways of doing static analysis on late-bound code. (Obviously, guarantees are not going to be the same. I take that as a reasonable trade-off.) OOP isn't predicated on mutable state and there are ways for the system to manage it anyway. (Although, to be fair - that is one thing from the list that hasn't been fully addressed in any practical OOP system I'm aware of.)

https://tonyg.github.io/squeak-actors/

http://scholarworks.sjsu.edu/cgi/viewcontent.cgi?article=123...

http://scg.unibe.ch/archive/papers/Scha03aTraits.pdf

http://web.media.mit.edu/~lieber/Lieberary/OOP/Delegation/De...

http://bracha.org/pluggableTypesPosition.pdf

http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.134...

Even if none of the work I mentioned above existed, this sort of criticism is amateurish at best. Real engineering requires considering trade-offs in real-life contexts. For example, compile-time checks aren't going to help you figure out that some vendor supplies incorrect data via a web service. An early prototype, however, can do exactly that.