I share the poster's sentiment. OO is a mental box and a lot of people end up with overly narrow definitions or have trouble escaping the box thinking. You can apply the same ideas without language support. It is orthogonal to bytecodes, VMs, GC or even a "class" keyword. But a lot of people have very specific expectations and will have a hard time seeing this for what it is.

Actually I think this is the beautiful thing about Perl 5's OOP support.

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.

> What the heck are you complaining about?

That mindset. Like I said. Did you not read my post?

We are talking about computing in 1985. A 25 MHz workstation would be at least 10,000% slower than a modern computer, with about 1,000× less memory available. Still, this isn't a huge difference in context, but talking about adding 4 to 16 bytes of overhead on every data structure, or every object, in a worst case scenario could result in twice as much memory usage.

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.