Comment by 3grdlurker | Hacker News Reader

Comment by 3grdlurker | Hacker News Reader

This is probably an unpopular opinion but I really can’t wrap my head around the arguments for FP and against OOP.

By the end of the day, regardless of which paradigm you choose, you’re still just defining concepts, and every concept has properties (both externally visible or not) and functions. The problems raised against OOP always seem to be a problem with the average programmer’s lack of understanding of ontology, so then they put structure and function inside concepts where they shouldn’t be. This lack of understanding of ontology is why, in my opinion, there’s equal opportunity for both paradigms to write equally ugly and horrible code.

I mean, I’ve seen people use RxAnything in a modern, expressive programming language that allows both OOP and FP, and still they ended up defining massive view controllers, incomprehensible interface names, extensions that apparently exist but aren’t visible to the programmer from anywhere, property assignments that apparently invoke functions under the hood, etc. If programmers write horrible code with OOP and they still write horrible code with FP, maybe it’s not the paradigm that’s the problem, and maybe it’s the common denominator: the programmer.

> you’re still just defining concepts, and every concept has properties

Sure; but lots of concepts (maybe most) are best expressed as either functions or bare data. OO isn't "bad" - but its massively overused. Lots of programmers (and programming languages) consider it the default abstraction, even when it doesn't make sense. Encapsulating state within a class, with lifecycle methods often makes code more complex, longer (~50% more LoC is common), slower (due to heap thrashing and the inability to vectorize operations), and harder to reason about.

For example, modern javascript has a built-in library for converting binary data to text (either UTF-8 or other formats). This should be a method decodeText(arrayBuf, 'utf-8'). But the API designers instead made a class you need to instantiate first. ( d = new TextDecoder('utf-8'); d.decode(arrBuf) ). This is a strictly worse API, which invokes awful questions like "Is it expensive to instantiate?" "Should I cache it?" "Is there extra hidden state in the text decoder?"

I agree that people can write awful code in any language. I've certainly managed to make messes at one time or another in just about every language I've learned well. But my personal dislike of OO comes from the exhausting, never ending fights I've had trying to convince coworkers to use simple functions and bare structs when appropriate. And to please stop trying to force every program, no matter the language, to look like bloated Java code.

> Sure; but lots of concepts (maybe most) are best expressed as either functions or bare data.

That’s begging the question, isn’t it?

> OO isn't "bad" - but its massively overused. Lots of programmers (and programming languages) consider it the default abstraction, even when it doesn't make sense.

I think that this really drives home my point that the problem is with programmers and their lack of ontology know-how.

Regarding your example on text decoders in JavaScript, you really should be asking the same questions about the functions that you are invoking, too. Just last month there was a huge article here about sscanf taking quadratic time. That could happen to any of the functions that you are invoking.

Again, languages from both paradigms equally allow for bad code to be written. I really don’t think that the debate should be at the paradigm level. We’re better off debating about specific policies in code style.

> Just last month there was a huge article here about sscanf taking quadratic time. That could happen to any of the functions that you are invoking.

I don't really know how that would have been made better or worse by OO. The issue there came from a lack of transparency - its not obvious that sscanf takes time linear with the size of the input string. (FWIW, I didn't know that either).

But both OO and functional approaches can obscure details like that. So it seems kind of tangential.

> We’re better off debating about specific policies in code style.

I don't think good taste can be enforced at a code style level. The problem we have is that all problems can be solved either with OO or FP, or with actors and so on. Its much easier for programmers to learn one style and apply it everywhere, rather than learn all the different ways of expressing something and apply each one only when that approach is appropriate.

Is this what you mean by 'ontology'? When I hear that word I imagine the question of "What is the ontology of data types in our program?" - "We have products, and orders, and users, and ...". Which usually presupposes classes even when they're the wrong tool. Thinking about ontologies is a leading question, and it'll lead you to a different program from classical structured programming's question of "What does your program do". Or FP: "What does your program output, and where does that output come from?" Or dataflow programming: "How does the data move through your system?"

Programming isn't an ontology problem. Its an expression problem - how do you express your program to the computer? I still don't know how to say that in response to an overly OO PR. "Thanks for the change, but this is an inelegant expression of the problem you're solving. Can you please make the data flow primary and obvious in your code, and the ontology secondary?". That doesn't tend to go down well. Even when they're open to it, I get a lot of confused responses. "Huh? Without classes? How would you even do that?"

> Again, languages from both paradigms equally allow for bad code to be written. I really don’t think that the debate should be at the paradigm level. We’re better off debating about specific policies in code style.

This perspective is actually important. When you look at OOP it is a paradigm but not a well defined one. You certainly wouldn't call it a policy.

FP (pure functional programming) however is much closer to a policy in the sense that there isn't so much to argue about. You can see from a piece of code if it is "proper" pure FP or not, whereas for OOP, it is easy to do things that are claimed to be "OOP" by half and claimed to be "improper OOP" by the other half.

And depending on how you define OOP, it is actually completely orthogonal to FP. Just like OOP puts mostly helpful restrictions on how you can model your problem in code, FP puts additional mostly helpful restrictions on it.

I happily use fp+oop in scala and i agree with what you say about rxjava and also most scala code is bad

the benefit of FP as a practice is more modular functionality. imperative code isnt always tangled, but it often is. OOP is for more modular data

Exactly this.

Reply on news.ycombinator.com