[paulrpotts]

Having used C++, Java, C#, Python, Ruby, NewtonScript, Dylan, Scheme, and various other languages "in anger" I can say that in general I agree with the author's frustrations. My favorite (as in most flexible, least boilerplate) approaches to object-oriented programming have been:

- NewtonScript's frames with prototype inheritance. Allows "objects" to consist of very small data structures that point to ROM objects and only use RAM for slots that actually vary, using copy-on-write. The actual implementation had some issues and of course that platform is dead, but the concept was great.

- Dylan's adaptation of generic functions, with multiple inheritance. There are classes but they don't have methods "inside" them. The class hierarchy describes the dispatch for the generic functions. Allows some really nice styles of programming (dispatching on multiple parameters) that are perhaps possible but absolutely hideous in C++.

- Qt's method. The use of a separate preprocessor step and generated code for dispatch was a hack to get around limitations of C++, but although you don't want to look too closely at that generated code if you value your sanity, at a practical level it works pretty well.

In summary, I'd just add that it is a deep and abiding shame of my industry that people wind up in silos learning one model of object-oriented programming and never consider other models that are different and can be cleaner and far simpler to think about.

[formula1]

I, being one of the few people on HN that like OOP, dont find anything you mentioned that organized, clean or simplified like oop.

No copy is available in rust. Overloading a generic function seems like we are talking about interfaces. A preprocessor step again is similar to rust.

But only the second has anything to do with writing in oop

[miles7]

In addition to Dylan, Julia also allows multiple dispatch via generic functions.

I have found this approach to multiple dispatch leads to code that's much easier to reason about and maintain. My use case is a tensor library where the tensors have a single interface but various storage backend types, which 'interact' with each other. It doesn't make sense to define these interactions through methods belonging to only one class or the other.

[jghn]

Also R via the S4 OOP system, which was directly inspired by Dylan