5 ms·

yes, but it's also much easier to write a good OOP code... learning curve is way steeper for functional programming, OOP is easier to grasp as it's closer to ho

yes, but it's also much easier to write a good OOP code... learning curve is way steeper for functional programming, OOP is easier to grasp as it's closer to how we usually think of the world, while FP is more math like...

raverbashing 7y ago
We also have a lot more of "holier than thou", gatekeeping, guidance that's more subjective than objective but taken as gospel like "SOLID", "clean code", stuff like MVC where your circular system is made to fit a square hole etc in OOP.
kerkeslager 7y ago
Okay, but how we think of the world is a pretty poor way to program computers. If you write objects to act how we think of the world, then you mutate state within your objects, and when you add threading it becomes a mess. You can avoid this with immutability, but then you start doing stuff like replacing one Person with another with one property changed, and you're no longer treating Objects like they are in the real world. A lot of good OOP practices like this are built in and somewhat enforced in FP. For example, the single responsibility principle: which psuedocode implements single responsibility better? immutable class Schema: Schema(self, ...): ... bool check_document(self, Document document): ... Schema with_constraint(self, Constraint new_constraint): ... Schema without_constraint(self, Constraint old_constraint): ... ...or... ... -> Schema make_schema(...) ... Schema -> Document -> bool make_schema_checker(schema) ... (Schema, Constraint) -> Schema add_constraint(schema, constraint) ... (Schema, Constraint) -> Schema remove_constraint(schema, constraint) ... Sure, you could separate out `class ConstraintChecker` and `class SchemaBuilder`, but you might not think to do that at the time, it costs an extra file, what's the harm, right? And I really doubt many OO programmers would go to the lengths of separating `class SchemaBuilder` into `class ConstraintAdder` and `class ConstraintRemover`. In fact, that would be so verbose that I'd probably argue that it's not good code. Meanwhile, the same functions in a functional style are each already separated because that's the only option for to do it, and it doesn't come with the verbosity cost. Closures are inherently single-responsibility objects, so much so that you don't even need to specify which method on them you're calling, you just call the object itself and it does the only thing it could possibly do! I suppose it might be more intuitive to do this: (Schema, Document) -> true check_document_against_schema(schema, document) Which would force you to leak the concept of the Schema to places that don't need to touch it, but at least check_document_against_schema still has a single responsibility.
- ivanhoe 7y ago
  Well, it's not like you have to mutate the state or program with side-effects just because you have some classes... once someone starts grasping on OOP principles, you can teach them the best practices, what to avoid, etc. That said, I definitely think that FP is the right way to go, I'm personally moving in that direction, but I think people should first get their feet wet with OOP, as it's easier to learn, and there's a lot of common knowledge between the two. Once you learn OOP and start to feel the problems and limitations, transition to FP will make more sense IMHO. It will not be just because some dudes on Internet said it's cooler, but you can spot the benefits yourself.
  - kerkeslager 7y ago
    > Well, it's not like you have to mutate the state or program with side-effects just because you have some classes... That's true, as I said in the post you're responding to. But as I also said in the post you're responding to, then your claim "OOP is easier to grasp as it's closer to how we usually think of the world" ceases to be true: when you give one of your employees a raise, do you replace them with another employee who is identical except for their salary? Obviously not, but that's how you'd give someone a raise if `Employee` is a class of immutable objects. You get to have one or the other: 1. Either OO is similar to how we think of the world and you're writing bad OO code that's got mutation all over the place, 2. OR OO isn't similar to how we think of the world, but you've got immutable objects that play nicely with concurrency. You can't have both. > I think people should first get their feet wet with OOP, as it's easier to learn, "OOP is easier to learn" is a claim I hear a lot, but I've yet to see any evidence that this is the case. Most people's evidence seems to be, "The way I learned it is the easiest." Given that most people start with OOP, it's unsurprising that many people think OOP is easier. There's also more learning materials available for OOP. But if you had completely untrained people learning programming for the first time with equal quality learning materials and instruction, I don't know which group would make progress more quickly, and I don't think anyone does know. In any case, if the ease of learning OOP comes from being able to start with bad habits (i.e. mutation) that allow you to write code the way you think of the world, I question whether this is actually a good thing. > and there's a lot of common knowledge between the two. This I totally agree with you on.
Barrin92 7y ago
I think it's easier to write OOP code period, without the 'good'. I think writing good OOP code is significantly harder than writing good functional code, because OOP gives users significantly more options to go astray. The limiting nature of functional languages tends to force people into cleaner solutions at the cost of harder constraints.
- kazinator 7y ago
  The limiting nature of functional languages tends to force people into looking for cleaner problems.
  - kerkeslager 7y ago
    Like massively multithreaded concurrency? Natural language parsing? AI? Deterministic security? Natural language parsing??? I suppose you're right in a sense, these problems are cleaner if you think of them in functional terms. ;)
contravariant 7y ago
I reckon FP wouldn't have as bad a reputation if the Haskell folks didn't insist that <*> and <$> is perfectly acceptable notation. FP does force you to pay more attention to state though, and losing track of the program state is the root of all evil.
- ferzul 7y ago
  actually they don't. many haskellers would prefer to write foo <$> bar <*> baz quux using idiom brackets as, say, (| foo bar (baz quux) |) in any case, the problem is that we want a lightweight syntax for a widespread, general purpose abstraction. the former syntax is used since it's an abstraction developed in terms of the language - so only general names and syntax were available. obviously they're hostile to people who haven't learnt them yet, but i'm not sure that java's . or = is any better in that respect. these do cause learners difficulty, since they're so foreign to anything they learnt pefore programming.

raverbashing 7y ago

We also have a lot more of "holier than thou", gatekeeping, guidance that's more subjective than objective but taken as gospel like "SOLID", "clean code", stuff like MVC where your circular system is made to fit a square hole etc in OOP.

kerkeslager 7y ago

Okay, but how we think of the world is a pretty poor way to program computers. If you write objects to act how we think of the world, then you mutate state within your objects, and when you add threading it becomes a mess. You can avoid this with immutability, but then you start doing stuff like replacing one Person with another with one property changed, and you're no longer treating Objects like they are in the real world. A lot of good OOP practices like this are built in and somewhat enforced in FP. For example, the single responsibility principle: which psuedocode implements single responsibility better? immutable class Schema: Schema(self, ...): ... bool check_document(self, Document document): ... Schema with_constraint(self, Constraint new_constraint): ... Schema without_constraint(self, Constraint old_constraint): ... ...or... ... -> Schema make_schema(...) ... Schema -> Document -> bool make_schema_checker(schema) ... (Schema, Constraint) -> Schema add_constraint(schema, constraint) ... (Schema, Constraint) -> Schema remove_constraint(schema, constraint) ... Sure, you could separate out `class ConstraintChecker` and `class SchemaBuilder`, but you might not think to do that at the time, it costs an extra file, what's the harm, right? And I really doubt many OO programmers would go to the lengths of separating `class SchemaBuilder` into `class ConstraintAdder` and `class ConstraintRemover`. In fact, that would be so verbose that I'd probably argue that it's not good code. Meanwhile, the same functions in a functional style are each already separated because that's the only option for to do it, and it doesn't come with the verbosity cost. Closures are inherently single-responsibility objects, so much so that you don't even need to specify which method on them you're calling, you just call the object itself and it does the only thing it could possibly do! I suppose it might be more intuitive to do this: (Schema, Document) -> true check_document_against_schema(schema, document) Which would force you to leak the concept of the Schema to places that don't need to touch it, but at least check_document_against_schema still has a single responsibility.

ivanhoe 7y ago
Well, it's not like you have to mutate the state or program with side-effects just because you have some classes... once someone starts grasping on OOP principles, you can teach them the best practices, what to avoid, etc. That said, I definitely think that FP is the right way to go, I'm personally moving in that direction, but I think people should first get their feet wet with OOP, as it's easier to learn, and there's a lot of common knowledge between the two. Once you learn OOP and start to feel the problems and limitations, transition to FP will make more sense IMHO. It will not be just because some dudes on Internet said it's cooler, but you can spot the benefits yourself.
- kerkeslager 7y ago
  > Well, it's not like you have to mutate the state or program with side-effects just because you have some classes... That's true, as I said in the post you're responding to. But as I also said in the post you're responding to, then your claim "OOP is easier to grasp as it's closer to how we usually think of the world" ceases to be true: when you give one of your employees a raise, do you replace them with another employee who is identical except for their salary? Obviously not, but that's how you'd give someone a raise if `Employee` is a class of immutable objects. You get to have one or the other: 1. Either OO is similar to how we think of the world and you're writing bad OO code that's got mutation all over the place, 2. OR OO isn't similar to how we think of the world, but you've got immutable objects that play nicely with concurrency. You can't have both. > I think people should first get their feet wet with OOP, as it's easier to learn, "OOP is easier to learn" is a claim I hear a lot, but I've yet to see any evidence that this is the case. Most people's evidence seems to be, "The way I learned it is the easiest." Given that most people start with OOP, it's unsurprising that many people think OOP is easier. There's also more learning materials available for OOP. But if you had completely untrained people learning programming for the first time with equal quality learning materials and instruction, I don't know which group would make progress more quickly, and I don't think anyone does know. In any case, if the ease of learning OOP comes from being able to start with bad habits (i.e. mutation) that allow you to write code the way you think of the world, I question whether this is actually a good thing. > and there's a lot of common knowledge between the two. This I totally agree with you on.

Barrin92 7y ago

I think it's easier to write OOP code period, without the 'good'. I think writing good OOP code is significantly harder than writing good functional code, because OOP gives users significantly more options to go astray. The limiting nature of functional languages tends to force people into cleaner solutions at the cost of harder constraints.

kazinator 7y ago
The limiting nature of functional languages tends to force people into looking for cleaner problems.
- kerkeslager 7y ago
  Like massively multithreaded concurrency? Natural language parsing? AI? Deterministic security? Natural language parsing??? I suppose you're right in a sense, these problems are cleaner if you think of them in functional terms. ;)

contravariant 7y ago

I reckon FP wouldn't have as bad a reputation if the Haskell folks didn't insist that <*> and <$> is perfectly acceptable notation. FP does force you to pay more attention to state though, and losing track of the program state is the root of all evil.

ferzul 7y ago
actually they don't. many haskellers would prefer to write foo <$> bar <*> baz quux using idiom brackets as, say, (| foo bar (baz quux) |) in any case, the problem is that we want a lightweight syntax for a widespread, general purpose abstraction. the former syntax is used since it's an abstraction developed in terms of the language - so only general names and syntax were available. obviously they're hostile to people who haven't learnt them yet, but i'm not sure that java's . or = is any better in that respect. these do cause learners difficulty, since they're so foreign to anything they learnt pefore programming.