[Prev][Next][Index][Thread]
Re: MI: why?
Lawrence G. Mayka <mayka@lucent.com> wrote in message
387F33C5.C8DA8D0C@lucent.com">news:387F33C5.C8DA8D0C@lucent.com...
>
>Having programmed in CLOS for 7 years
>and now in Smalltalk the last 4 years, I feel the loss quite painfully.
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.
> 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.
-Eric
Follow-Ups:
References: