5 ms·

> the extra resources for OO Thinking like this annoys me, because it assumes a specific implementation for OO. Are people conflating OO with Java? Are they co

by cbd1984 11y ago

> the extra resources for OO 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.

cynicalkane 11y ago
The GP is talking about what OO was like back at the time. What the heck are you complaining about? 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.
- asveikau 11y ago
  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.
  - collyw 11y ago
    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.
- cbd1984 11y ago
  > What the heck are you complaining about? That mindset. Like I said. Did you not read my post?
  - xigency 11y ago
    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.
overgard 11y ago
OO tends to imply things like dynamic dispatch (for method lookup), implicit extra parameters to functions (this pointer and so on), accessors (potentially a lot of extra function calls), placing variables in memory based on grouping within objects rather than where lookup might be most efficient. Not to mention possibly run time type info, which takes up more memory. Those are all things that are mostly fast enough to be a non-issue now, or are optimized by compilers, but they are generally slower.
- asveikau 11y ago
  Seems like you're mentioning a few features that are either optional or inline-able in C++. It took me a long time to appreciate this aspect, but c++ in particular is all about not making you add costs without explicitly asking for it.
  - xigency 11y ago
    Once you start removing features, then you are only speaking of an object oriented-like programming language, not a true object oriented programming language. 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.
    - asveikau 11y ago
      And they say religion is dying out in the civilized world. 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.

by cbd1984 11y ago

cynicalkane 11y ago

The GP is talking about what OO was like back at the time. What the heck are you complaining about? 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.

asveikau 11y ago
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.
- collyw 11y ago
  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.
cbd1984 11y ago
> What the heck are you complaining about? That mindset. Like I said. Did you not read my post?
- xigency 11y ago
  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.

overgard 11y ago

OO tends to imply things like dynamic dispatch (for method lookup), implicit extra parameters to functions (this pointer and so on), accessors (potentially a lot of extra function calls), placing variables in memory based on grouping within objects rather than where lookup might be most efficient. Not to mention possibly run time type info, which takes up more memory. Those are all things that are mostly fast enough to be a non-issue now, or are optimized by compilers, but they are generally slower.

asveikau 11y ago
Seems like you're mentioning a few features that are either optional or inline-able in C++. It took me a long time to appreciate this aspect, but c++ in particular is all about not making you add costs without explicitly asking for it.
- xigency 11y ago
  Once you start removing features, then you are only speaking of an object oriented-like programming language, not a true object oriented programming language. 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.
  - asveikau 11y ago
    And they say religion is dying out in the civilized world. 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.