--tKW2IUtsqtDRztdT
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Thu, May 26, 2011 at 03:36:39AM +0900, David Masover wrote:
> 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.
>=20
> Thank you!
>=20
> 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.

Maybe Alan Kay . . . ?  My mental model for OOP is inspired kinda
directly by things he has said about how he envisioned things, to some
extent at least.


> >
> > 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.
>=20
> 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.

To be fair to ECMA, the ugliness in JavaScript isn't *all* the fault of
what went on in the standards process -- but I think the lion's share of
that ugliness owes its current existence to the ECMA standard.  There was
serious talk of a new major version of the ECMAScript standard that
promised to fix all kinds of awfulness in the language, but it was
eventually abandoned in favor of a minor version bump to tack on a few
features the corporate ECMA members demanded.


> >
> > 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.
>=20
> 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.
>=20
> I think the JavaScript syntax is easier to pick up, at least for
> getting the point across that I wanted to make:

Io's pretty easy to pick up as well, at least for a basic understanding
of the important parts of the language.  Whirlwind tour for beginners:

    Introducing Io, A Prototype-Based Language
    http://blogs.techrepublic.com.com/programming-and-development/?p=3D3483


>=20
> 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?

I'm making an effort to get a firmer grasp of JavaScript than I already
have, because I'm aware of its usefulness, and think that it has a lot of
potential to serve me well in the near future.  I'm just frustrated by
the way the good (really good) parts of it are weighed down by the
garbage heaped on it, so I probably come off as more critical of it than
I intend.  It's definitely worth knowing -- and using.  I guess that,
within the narrow constraints of languages that accomplish what
JavaScript does well, JavaScript is the best of a bad lot, in part
because our alternative is VBScript (I shudder), but in part because of
the really neat language design decisions that survive at the core of the
language.


> >
> > 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.
>=20
> 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'm not sure what you described would really be Io any longer.

I stumbled across Reia quite a while ago, too, and found it interesting.
I already have far too much on my plate to invest too much time into it
right now, though, so I probably won't check into it too seriously for
another year or two.


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

At least until there's a major housecleaning for the ECMAScript standard,
I don't think I would, either -- though "the Web", in my case, also
includes the enticing prospect of server-side JavaScript programming with
fun toys like Node.js, which I hope to tackle in some depth some time in
the next six months.


> >
> > 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).
>=20
> 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?

It feels almost spitefully bare-bones in a lot of ways.  I alluded to the
same problem in the above-referenced article.  When playing around with
Io, I found myself wishing I was using Ruby more often than just coding,
once I got past the initial fun of the prototype model of OOP.  It just
felt a lot of the time like I was implementing parts of the language its
creator forgot.

I recommend Seven Languages in Seven Weeks for a quick introduction to Io
(and six other interesting languages).  The Introduction to Io article
barely scratches the surface; the Seven Languages book digs a bit deeper
into the interesting ideas built into the design of the language.

--=20
Chad Perrin [ original content licensed OWL: http://owl.apotheon.org ]

--tKW2IUtsqtDRztdT
Content-Type: application/pgp-signature
Content-Disposition: inline

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.14 (FreeBSD)

iEYEARECAAYFAk3dVl8ACgkQ9mn/Pj01uKXoQwCcDNAchuWkA7P+mOLTagtUjTTQ
7IkAn2Y1u8VULRsTkpb6JDFOyBkhdiZ5
=9bsv
-----END PGP SIGNATURE-----

--tKW2IUtsqtDRztdT--

On Thu, May 26, 2011 at 03:36:39AM +0900, David Masover wrote:
> 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.
>=20
> Thank you!
>=20
> 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.

Maybe Alan Kay . . . ?  My mental model for OOP is inspired kinda
directly by things he has said about how he envisioned things, to some
extent at least.


> >
> > 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.
>=20
> 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.

To be fair to ECMA, the ugliness in JavaScript isn't *all* the fault of
what went on in the standards process -- but I think the lion's share of
that ugliness owes its current existence to the ECMA standard.  There was
serious talk of a new major version of the ECMAScript standard that
promised to fix all kinds of awfulness in the language, but it was
eventually abandoned in favor of a minor version bump to tack on a few
features the corporate ECMA members demanded.


> >
> > 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.
>=20
> 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.
>=20
> I think the JavaScript syntax is easier to pick up, at least for
> getting the point across that I wanted to make:

Io's pretty easy to pick up as well, at least for a basic understanding
of the important parts of the language.  Whirlwind tour for beginners:

    Introducing Io, A Prototype-Based Language
    http://blogs.techrepublic.com.com/programming-and-development/?p=3D3483


>=20
> 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?

I'm making an effort to get a firmer grasp of JavaScript than I already
have, because I'm aware of its usefulness, and think that it has a lot of
potential to serve me well in the near future.  I'm just frustrated by
the way the good (really good) parts of it are weighed down by the
garbage heaped on it, so I probably come off as more critical of it than
I intend.  It's definitely worth knowing -- and using.  I guess that,
within the narrow constraints of languages that accomplish what
JavaScript does well, JavaScript is the best of a bad lot, in part
because our alternative is VBScript (I shudder), but in part because of
the really neat language design decisions that survive at the core of the
language.


> >
> > 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.
>=20
> 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'm not sure what you described would really be Io any longer.

I stumbled across Reia quite a while ago, too, and found it interesting.
I already have far too much on my plate to invest too much time into it
right now, though, so I probably won't check into it too seriously for
another year or two.


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

At least until there's a major housecleaning for the ECMAScript standard,
I don't think I would, either -- though "the Web", in my case, also
includes the enticing prospect of server-side JavaScript programming with
fun toys like Node.js, which I hope to tackle in some depth some time in
the next six months.


> >
> > 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).
>=20
> 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?

It feels almost spitefully bare-bones in a lot of ways.  I alluded to the
same problem in the above-referenced article.  When playing around with
Io, I found myself wishing I was using Ruby more often than just coding,
once I got past the initial fun of the prototype model of OOP.  It just
felt a lot of the time like I was implementing parts of the language its
creator forgot.

I recommend Seven Languages in Seven Weeks for a quick introduction to Io
(and six other interesting languages).  The Introduction to Io article
barely scratches the surface; the Seven Languages book digs a bit deeper
into the interesting ideas built into the design of the language.

--=20
Chad Perrin [ original content licensed OWL: http://owl.apotheon.org ]
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.14 (FreeBSD)

iEYEARECAAYFAk3dVl8ACgkQ9mn/Pj01uKXoQwCcDNAchuWkA7P+mOLTagtUjTTQ
7IkAn2Y1u8VULRsTkpb6JDFOyBkhdiZ5
=9bsv
-----END PGP SIGNATURE-----