Comment by ddellacosta | Hacker News Reader

Comment by ddellacosta | Hacker News Reader

Parent Full thread

In my opinion the existence of No true Scotsman posts like this arguing about random concepts is endemic to OOP and a symptom of the lack of formalization inherent in that approach. The GoF book just piles more confusing noise on top of it.

I soured on OOP decades ago exactly because I grew tired of reading dogmatic posts like this or bike-shedding how to do DI or whatever The Right Way with my colleagues. At the end of it I never ended up feeling like I'd ever grasped the core of what OOP actually is, because I don't think there's actually anything there. Maybe there are coherent threads that can tie together languages like Smalltalk, Eiffel, C++, Java, Self, Javascript, Python, Ruby, etc. etc. but I don't think it's a nebulous concept called "OOP," and I think there's more value in talking about how specific features can be used in these different languages on a case-by-case basis than trying to hone in on some coherent, generalized notion of "delegation in OOP."

To be fair the same could be said for FP, but at least with functional programming I can latch onto some core concepts and assert a coherent, formalize-able definition that makes sense across languages, to a greater or lesser extent (again, with debatable value given my last point in the paragraph above). "OOP" as a concept just makes me throw my hands up in the air.

"There's nothing there" is pretty close. I see OOP as fundamentally one key concept: that there are functions which "belong to" specific types, and all other operations on those types go through the functions that "belong to" them.

You can do OOP in a language like C by writing your code as structs and accompanying functions that operate on them. You might expose the structs to the rest of your code as opaque pointers to enforce that all other code has to go through these accompanying functions to use this struct. Or you might just make it be convention. An OOP language is just one that has language features to facilitate this, such as by allowing you to define methods within a type rather than functions outside of it.

Once you have this, then you might start thinking of features that might be nice to have alongside, such as dynamic typing, dynamic dispatch, inheritance, etc. But I don't think any of those are fundamentally OOP, they just fit well and are often found together.

Since having functions that belong to specific types isn't a very big concept, discussion about OOP is going to focus on these other things, which are not necessarily omnipresent and are often different across languages. So the discussion is either going to be very specific to one particular language (maybe even one particular set of libraries for it) or very vague.

> I see OOP as fundamentally one key concept: that there are functions which "belong to" specific types, and all other operations on those types go through the functions that "belong to" them

I would go even further:

All programming essentially consists of two things only:

  1. data structures (often, but not necessarily, formalised as "types")
  2. mechanisms to transform that data (functions, methods, algorithms, tasks, whatever)

Programming paradigms essentially describe different ways to organise these two: functional programming, for example, keeps the two strictly separate; in OOP the mechanisms are "attached" to the data they operate on. Of course, in practice there are many combinations and variations, with more and less flexibility (from strictly closed objects to mixins and similar), but this is the foundation.

So you say we don't need OOP because you can use this half-baked (non type-safe) way of implementing your favorite OOP feature yourself in your favorite touring-complete language? While omitting the key concept of virtual functions.

Yes.

"OOP" is a philosophy more than specific implementation details. I've programmed "object orientedly" in any number of languages, many of those with no object orientation helping syntax, like C, assembly, Forth (although that one's more malleable). It's always been about the mental model of your programming, anything else is syntax sugar.

All discussion about "your not doing true OOP because $REASON" arguments are useless, repetitive, and discouraging to exploration, discovery and learning.

I'm not sure where you got "we don't need" from, unless you consider any language feature to be unnecessary if there's a way to implement the concept without it. Which is not a very useful way of looking at language features! You can implement anything in assembly, that doesn't mean higher-level languages aren't needed.

I'm saying that OOP as a concept is simple enough that you can do the basics of it in pretty idiomatic and straightforward C, and all the other stuff that we associate with "OOP" is not really universal. And thus it's no surprise that discussions around OOP as a general concept tend to be vague and not very useful.

Why do you seem to feel that OOP defines a specific set of features, for instance virtual functions?

There are many different OOP styles out there. All one needs to do is to look at the languages that originated the concept, such as SIMULA and Smalltalk to see that they weren't channeling the exact same ideas.

OOP has a "there" there, it's just that the core formalism is user interfaces. If you look up "object oriented programming" on Wikipedia, the first image you get is a UML diagram of a user interface component.

OOP was invented to facilitate old-fashioned "expert systems" type AI research. While that's a nebulous concept[0], it turned out to be really useful to represent (retained-mode) UI in this way. Any mildly complicated UI needs to be a tree structure where the contents of the tree are all different things. You might want to put a button inside of a cell in a scroll list on the right pane of a window, and to do that, all of those things need to...

1. Support arbitrary child objects of different types and data sizes

2. Communicate with a standard set of events and system behaviors

3. But also support modifying those behaviors or introducing new events to fit the present application

Outside of immediate-mode GUIs for games, GUI-approximating text mode applications, and classic Mac OS[1], every UI toolkit worth its salt is OOP. Yes, even USER.dll. Microsoft[2] wrote an object system on top of a non-object-oriented programming language because it was just that useful.

If you aren't doing UI work, OOP loses it's effectiveness. But doing UI work in a non-OOP language is painful, in direct correlation to how non-OOP the language is. e.g. If you're working in Rust, you can probably get by with a bunch of traits and `dyn UiWidget` them; and there might also be something similar for Go; but in C you'd have to manually construct vtables for every object type you plan to include and pass pointers to everything around everywhere.

[0] Yes, the term "AI" has been meaningless for over half a century. Yes, there's probably a link between that meaninglessness and the nebulousness of UI and OOP.

[1] Steve Jobs had been so distracted by the fancy pointer-driven UI at Xerox that he forgot about the OOP language powering it, Smalltalk. He'd fix that immediately at NeXT.

[2] Also, GIMP, whose UI toolkit wound up becoming GTK, and whose object system became GObject.

Having done UI (and a raytracer) in non-OOP language during my curriculum, I can only strongly agree with parent. OOP is essential to do specific kind of work, including but not limited to UI.

I really hate it to be clear, I dislike the paradigm and find it sometimes difficult to understand. I hate the footguns, I hate inheritance chains. I tolerate mixins and interfaces. But I have to admit: in some cases, OOP is what I need , so I use it.

OO is pretty simple. Use objects. There are many many patterns that you can use that rely on this concept. You don't need to use every pattern to be using OO. Even at the most basic level of "a scoped namespace", OO can be useful in organization. The fact it can be used in many ways means there are many perspectives on how it can or should be used.

Popular OO languages are also very pragmatic. That means that even if they are OO languages, they allow for non-OO patterns as well. OO is flexible in this way. A counter example is FP, where it is not very flexible. FP has many rules you must follow to make the concept work, such as how mutability is handled.

Reply on news.ycombinator.com