3 ms·

> 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 i

> 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.

josephg 6y ago
> 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?"
valenterry 6y ago
> 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.

josephg 6y ago

> 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?"

valenterry 6y ago

> 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.