> Polymorphism is doable in plain old C with lookup tables and function pointers

Not without casting. qsort is still:

    void qsort_r(void *base, size_t nmemb, size_t size,
                 int (*compar)(const void *, const void *, void *),
                 void *arg);

Presumably one would write an object-oriented version of quicksort to go with their OO C library design and not use the stdlib functions. For example GObject is OOP in C, and I imagine it has collection types with sort methods.

Inheritance is what will bite hard when hand-rolling OOP in C. For one, you can forget about the compiler enforcing substitutability and co/contravariance for you.

Because syntactic sugar and abstractions matter. You can do everything in assembly too, yet we prefer something higher level.

> what is the point of creating a language where everything is an object?

I think that's the ultimate culprit in everyone hating inheritance. If it weren't for Java, I think we'd all have a healthier view of OO in general.

I learned OO with C++ (pre C++-11), and now I work at a Java shop, but I'm luck that I get to write R&D code in whatever I need to, and I spend most of my time in Python.

In C++ and Python, you get to pick the best tool for the job. If I just need a simple function, I use it. If I need run-time polymorphism, I can use it. If I need duck-typing I can do it (in Python).

Without the need for strict rules (always/never do inheritance) I can pick what makes the best (fastest? most readable? most maintainable? most extensible? - It depends on context) code for the job.

Related to TFA, I rarely use inheritance because it doesn't make sense (unless you shoehorn it in like everyone in the threat is complaining about). But in the cases where it really does work (there really is a "is a" relation), then it does make life easier and it is the right thing.

Context matters, and human judgement and experience is often better than rules.

C++ templates are a form of duck typing as well, and combined with type erasure give you a lot of the benefits of OO without the downsides.

Yes, you're right. I've done that in high-performance code where I couldn't afford the double function call of a virtual function. I forgot about that.

Likewise this is getting easier with the auto keyword now being sugar for templates when used in function arguments and return values

I learned OO with Smalltalk.

Everything is an object so there's no if-it's-an-object do this but if-it's-not-an-object do that.

> If it weren't for Java, I think we'd all have a healthier view of OO in general. > > I learned OO with C++ (pre C++-11), and now I work at a Java shop, but I'm luck that I get to write R&D code in whatever I need to, and I spend most of my time in Python. > > In C++ and Python, you get to pick the best tool for the job. If I just need a simple function, I use it. If I need run-time polymorphism, I can use it. If I need duck-typing I can do it (in Python).

Those first two you can do in (modern) Java. The third is a mess to be avoided at all costs. Interfaces and lambdas will cover most reasonable use cases for polymorphism.

So we might guess that the language designers thought there were other benefits.

1981 "Design Principles Behind Smalltalk"

https://www.cs.virginia.edu/~evans/cs655/readings/smalltalk....

Control flow is doable with gotos. What benefit therefore is structured programming?

Dynamic dispatch is implemented under the hood with lookup tables and function pointers. Sometimes, it is nice for a language to wrap a fiddly thing in a more abstract structure to make it easier to read, understand, and write.