3 ms·

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 with

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.

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.