[Prev][Next][Index][Thread]

Re: MI: why?

Eric Clayberg wrote:

> I think this depends on where you are coming from. There are lots of
> problems that can be solved via MI *or* delegation (or other techniques). I
> have seen very few cases where MI is the *only* or *best* solution. If you
> are used to solving problems via MI, then you will feel its loss. If you are
> used to solving those same problems via other techniques, you won't feel the
> loss. I have been developing in Smalltalk for over ten years and have only
> run across a handful of cases where I though to myself, "damn, I wish I had
> MI for that". Most problems that you would see as needing MI solutions, I
> see as naturally needing delegation-based solutions (or some other
> technique). As a result, I don't feel the "loss" of MI in the slightest.

You are saying, essentially, that you don't feel the loss because you've
never gained experience with what you are missing.  I myself, as someone
with considerable experience in both CLOS and Smalltalk (as well as 5
years of C++), merely claim that you *are* missing something
significant.  How do you know whether or not, or how often, MI would
have been the best solution, if you have no significant experience with
it?

Please keep in mind that years ago, I ran across this same difficulty in
language debates with C++ advocates.  They would make confident
assertions about dynamic languages without any significant experience
programming in one!  On the other hand, they dismissed my own views even
though I *had* long years of experience in C++.

> > MI has gotten a bad reputation in some quarters because (a) highly
> > static languages such as C++ cannot use MI to its best advantage, and
> > (b) "one-thought" languages such as Smalltalk cannot expand sufficiently
> > to use MI to its best advantage either.  The best matches for MI are (a)
> > dynamic languages designed for MI from the start, such as Dylan, and (b)
> > highly evolvable dynamic languages such as those of the Lisp family.
> 
> How do you reconcile that with the fact that Smalltalk used to have MI
> (actually, you can still get it if you want it) and it was removed because
> it added too much complexity without enough benefit? In Smalltalk, MI is a
> class library issue, not a language issue (nothing in the language prevents
> it and there are 3rd-party MI add-ons that demonstrate this). If customers
> were demanding it, I'm sure that at least one of the commercial Smalltalk
> vendors would have added it (back) in by now.

First, I admit that MI may not necessarily be a good match for
Smalltalk's design philosophy and culture because, as I think you're
pointing out, Smalltalk places a radical emphasis on simplicity. 
Simplicity vs. expressiveness is a common tradeoff in languages.

Second, my understanding of typical Smalltalk MI implementations is that
they refrain from modifying the virtual machine and language design. 
This is, in essence, what you are saying too.  The resulting MI would, I
expect, have neither the functionality nor the performance required for
a commercially viable MI product.  MI in Dylan was built in from the
start.  MI in CLOS was originally a library which had almost full
functionality (due to Lisp's high evolvability) but lacked performance,
for which absorption into commercial kernels was necessary.

- Larry Mayka
Follow-Ups: References: