[Prev][Next][Index][Thread]
Re: MI: why?
Lawrence G. Mayka <mayka@lucent.com> wrote in message
387F52B3.4B5A4662@lucent.com">news:387F52B3.4B5A4662@lucent.com...
>
> > 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.
No, I'm not saying that. In fact, I do have experience with a couple of
languages that support MI (like C++ and CLOS). The first language I learned
in college was Lisp (Scheme actually), and I have used several Lisp variants
including CLOS. Admittedly, I have not had cause to use CLOS for quite a
long time (since the early '90's when Smalltalk became my fulltime job). I
do use C++ periodically (and don't care for it much). Since Smalltalk is my
primary development language, I tend to think in terms of Smalltalk-based
solutions. As I said above, I *have* encountered a few situations where I
wished for MI in Smalltalk. It's just that they are few and far between.
Problems that you think are best solved by MI, I see as being best solved by
delegation or some other technique (even though I am fully cognizant of how
I could solve the problem via MI as well). Such problems usually don't have
an absolute "best" solution and can be solved in a myriad of ways. It's more
a matter of personal opinion, philosophy or comfort level than anything
else.
> 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.
Since my experiences sound similar to your own (although with much less CLOS
focus and much more Smalltalk focus), I respectfully disagree.
> 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?
Because my experience has been "significant"?
> 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.
Yes. MI goes against the grain as far as Smalltalk is concerned.
> Second, my understanding of typical Smalltalk MI implementations is that
> they refrain from modifying the virtual machine and language design.
A Smalltalk VM really shouldn't care too much whether MI is implemented or
not (other than for optimization purposes). Earlier Smalltalk dialects
supported it at the VM level and you can see vestigial MI implementations in
some Smalltalk class libraries (Smalltalk Express is a good example).
Current MI add-ons deal with issue purely from a class library point of
view. Since most of Smalltalk is implemented in itself, adding MI doesn't
require changing the existing VM to get it to work.
> 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.
Performance, maybe not. Having the VM optimized to deal with MI, would
definitely be a benefit. I don't think there would be many limitations in
terms of functionality however.
> 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.
MI in Smalltalk followed a similar path, but ended up being removed due to
the simplicity vs. complexity issues.
-Eric
References: