Hacker News Reader

Comment by MetaWhirledPeas | Hacker News Reader

I do some programming, but not OOP. Over the years I've read about it and asked colleagues about it, and the why question finally settled on it helps you organize your code. I can get behind that. But I also want to understand why OOP instead of conventional programming; I'm still waiting for that part to click. Until that question is answered it won't be capturing my full attention.

View on HN

What is "conventional programming", pray tell?

Maybe procedural?

I think the root rant here, which I personally find unconvincing, is thinking in terms of OOP vs functional programming. Procedural isn't the opposite of OO; objects are composed of many procedures.

I wasn't intending to trigger anyone but it seems I have. Perhaps I should have stated it as, "why OOP instead of organizing the code through other means?" It's a genuine question I have, and it just hasn't clicked for me yet, personally. So it's not really trying to be convincing at all; I'm just sharing my experience.

The most compelling scenario for OOP is situations where, in its absence, a developer would tend towards reimplementing some OOP concepts over time. I think it is a natural fit for game development and some other things, but I don't think it melds so well with that thing we call 'business logic'.

I don't think there is a satisfying case for OOP.

https://youtu.be/QM1iUe6IofM?t=477

OOP works well when state and behavior are tightly coupled, particularly for things which are naturally modeled as state machines. Device drivers tend to be perfectly suited to OOP organization: the underlying device has state that needs to be tracked, it has behaviors which can be controlled (usually by sending particular messages), and there are often multiple implementations of the hardware which should all expose the same high-level API. OOP allows bundling the state handling with the control messages needed, exposing a single common API while allowing specialized implementations for particular driver implementations.

For the higher-level code, it's often less useful.

Functional? Procedural? Logic? Dataflow? Relational? Unstructured imperative, like old-school BASIC?

I mean, the only clue we have is that it is some paradigm that isn’t OO, but that leaves... a whole lof options.

Algol

I've never really seen this explicitly stated anywhere, so maybe this is some super idiosyncratic idea on my part, but it's always seemed to me that one of the key pieces of OO is the use of polymorphism as a sort of syntactic/conceptual sugar around function indirection, that many people seem to have an easier time understanding and reasoning about.

Reply on news.ycombinator.com