Thinking like this annoys me, because it assumes a specific implementation for OO. Are people conflating OO with Java? Are they conflating it with Smalltalk? Are they unaware you can write C in an OO style?
> It's not until the time I graduated college that machines and VMs of managed environments started to get faster than "embarrassingly slow" in mainstream hands.
Yes. People are apparently conflating OO with Java or Smalltalk.
Examples include inheritance, abstraction, and encapsulation which you can achieve merely by changing syntax. What requires extra resources at runtime is polymorphism, and that's one of the most important, functional aspects of object oriented programming.
Consider if you will that the things you are describing as slow - chiefly the indirection of a virtual call - are slow relative to other things because of relatively recent CPU advancements. If a CPU does no branch predicting or caching, I think the overhead of a virtual call doesn't sound so bad. So, if we're talking about why to avoid OO in the late 80s, I'm not as convinced the cost of a virtual call is the barrier.
That said, my point was that C++ lets you do these things, but you have to ask for them. If you want virtual calls, go nuts. But if you don't, you're not going to suffer from mandatory bloat - your object code will still look good, as if you had written it in a language without such mandatory frivolities.
In any case, modern CPUs and compilers can use aggressive optimization, sure, and the runtime speed is only equally as important as the ease of development and concerns about reliability.
On an older system, though, using a liberal OOP design in an operating system would be akin to creating structs that have arrays of function pointers associated with them, and having every function call routed through those pointers. Looking at the machine executing this code, you would reliably see jumps to similar codepoints in-between function calls, and a lot of wasted time or space. And I'm not sure anyone has mentioned this, but exception handling especially can add a lot of overhead.
Obviously, the benefits significantly outweighed the cons, especially in this case (NeXTSTEP and Objective-C), but I think that was helped substantially by the fact that projects Steve worked on always had much better computer hardware.
There were very few fast OO languages and they were emerging at the time. The most prominent examples of those languages are those languages GP names, and they do not exactly live up to the promises of even contemporary OO research, much less modern research.
It was clearly an after thought and a bit of a hack, but it works, and it makes it transparent how everything works. I had been taught Java at university before that, and the whole OOP thing was a bit of a hidden mystery. Perl gave me a far better understanding of OOP.
That mindset. Like I said. Did you not read my post?
Steve Jobs wasn't an engineer technically, so he wouldn't know the specifics here, but at the time object-oriented programming had a stigma associated with it because programmers did know of these drawbacks. Using Objective-C was obviously a fundamental choice by the software engineers.
Writing C in an object oriented style is what a lot of programmers did then. But there's a difference between associating data with methods and supporting polymorphism. Hence the talk of virtual function tables.