Hacker News Reader

Comment by iconjack | Hacker News Reader

I like your philosophy, but I think this counterexample is misleading. The Hanoi puzzle is an old favorite, largely because it lends itself to a surprisingly short, recursive solution. If your goal is merely to churn out the steps, then an OO implementation is easily mocked as overkill, but that's because you went into the implementation with the solution already worked out. If your intention was instead to build a program with a UI for playing around with the pieces, moving discs around willy-nilly and perhaps adding more rods, then Rod and Disc classes present themselves quite naturally. In this more real-world setting I think an OO design would be quite elegant and flexible.

View on HN

Yes, this. Most of these, OOP is bad articles follow the same pattern of showing how an idiomatic object based decomposition doesn't do well on algorithmic problems that developers rarely deal with. They then leverage red herring and slippery slope to show that OOP is bad in general. FP similarly falls down on stateful interactive systems in the same grain, where an object-like system emerges in the end in any case.

Who doesn't go into the implementation with the solution worked out?

I think that's not the problem. I think it's just that different things have different levels of complexity, and your representation should match what you want to do.

There is a lot of "real world" computation where it makes more sense to do things the "mathy way" rather than representing them with objects.

I think the point being made is that we use OOP to provide a natural abstraction of the real world to the end user. In this Towers problem: it would be like building the Towers game for an end user to play with - not solve it for the user.

>>Who doesn't go into the implementation with the solution worked out?

OOP, as Allan Kay envisioned it, is about making developing software a process of learning about what you are modeling. You are expected to naturally find the solution to your problem as you model it, not to have a worked up a solution you have to put into the code. With real-world sized problem, this approach gives good results. But, obviously, it can fail to find some great solutions. As is the case for the Hanoi problem: you can model it very well without finding the optimal solution to it. But the model still has some added usefulness.

This is exactly right. Alan Kay said something to the effect that the reason he invented OOP is because he hated algorithms (and data structures). Indeed, one of his criticisms of Java-style OOP is that, by using setters, it "turns objects back into data structures".

Reply on news.ycombinator.com