Re: Object-Oriented thinking

On Wednesday, May 25, 2011 01:02:36 AM Chad Perrin wrote:
> I think your description of the object model and how you think of it is
> excellent, and it very closely approaches the way I think about it,
> though I think some of the points you make come off a bit more subtly
> than they would if I tried to explain it.

Thank you!

I actually should give credit to... someone. I'm sure these ideas aren't 
entirely my own, but I don't remember where they come from.

> I would actually suggest that, in large part because of the compromises
> made in JavaScript's implementation in the ECMA standardization process,
> there is a lot of clutter in the language's design that obscures these
> characteristics of JavaScript's object model in some unfortunate ways.

I don't know enough about that process to know that this is where it came 
from, but I'll certainly agree there's clutter and downright ugliness in the 
design. It's fortunate that when you get past the ugliness, there's still 
something kind of cool and useful, whereas it seems like behind every bit of 
ugliness in C++ is more ugliness.

> As an alternative to JavaScript, if the goal is solely to gain an
> understanding of this prototype-based object model philosophy, one might
> be better served to learn Io.  I think that in the end JavaScript is a
> much more *useful* language, and there are in fact some implementation
> details of Io that I find a bit perversely cumbersome, but as a way to
> rapidly pick up the feel and implications of a prototype-based object
> model nothing comes to mind that comes anywhere near the efficacy of Io
> as an example language.

It's one that I've actually been meaning to learn for awhile, mostly because I 
like the idea of objects being actors -- though, reading it now, it's a bit 
depressing that it's cooperative concurrency, so I can't actually do multicore 
stuff that way.

I think the JavaScript syntax is easier to pick up, at least for getting the 
point across that I wanted to make:

function parent() {
  return {
    foo: function() { ... }
  };
}

function child() {
  var obj = parent();
  obj.bar = function() { ... };
  return obj;
}

And of course, the ad-hoc-ness of the various implementations of 'extend'. Off 
the top of my head:

var Extendable = {
  extend: function (other) {
    for (var x in other)
      this[x] = other[x];
    return this;
  },
  infect: function(other) {
    this.extend.apply(other, [this]);
    return other;
  }
};
// So, to make any object extendable, you can have any extendable object
// "infect" it first, then use Object.extend, kind of like Ruby:
var foo = {};
Extendable.infect(foo);
foo.extend({
  bar: function() { ... },
  baz: function() { ... }
});
// Or chain them:
var foo = Extendable.infect({}).extend({ ... });

I don't know enough about IO to really say whether it's better for teaching 
prototypal inheritance, but that wasn't quite the goal here. For one, 
JavaScript is useful, and I'll take almost any opportunity to counter FUD from 
people who bash it without understanding it. But my main goal was to show that 
code like the above can be made to run much more efficiently than you'd think, 
so why not have something that flexible to begin with?

> So, to summarize . . . I think that Io is a better choice for the limited
> purpose of learning about these things.  I think JavaScript is a better
> choice for learning a useful language, though.

That depends entirely what your goals are. For instance, if you can give me an 
IO VM, or an IO derivative, which gives me prototypal-inheritance OOP (or just 
OOP in general), objects-as-actors, and Erlang-style concurrency, I'd be very 
interested (and I really should be following Reia much more closely).

I wouldn't deliberately use JavaScript for anything other than the Web or 
things closely tied to it.

> I'd really like to find out why
> (if it is true) Io is as useful a language as JavaScript for "real world"
> problem solving when it seems to me like it kinda isn't (and not just
> because of lacking libraries, tools, et cetera, but also because of some
> characteristics of its design).

Well, again, I don't know enough about IO to have an opinion, but I'd like to. 
What aspects of its design make it unsuited to real-world problems?