I agree, we should not model the design environment in Mastermind right now.
However, we should at least think about some of the issues to make sure that
when we get to build the design environment it will be possible. One way to
do this is to envision how some small portions of the desing environment would
be modeled. This also serves to make sure that we can model realistic
applications in mastermind.
> We should not plan to model the design environment, hence end up limiting the
> functionality of the environment due to the limitation of the modeling language.
I see this the other way around. By thinking on the design environment a bit,
we'll realize what some of the limitations of the modeling language are, and
we can fix them. I agree, we shouldn't limit the design environment because
of shortcomings in the modeling language.
> I think as we build the design environment, we'll see opportunities to save
> development time by using the model. That's when we should revisit the issue.
>
Yes.
> We should try to develop the environment as a traditional program (no model,
> that is) to begin with.
>
I don't agree with this one. We should develop the design environment as a
Mastermind application so that we have a driver to make sure that mastermind
works. If we don't use it ourselves, why should other people use it?
> If we think we're going to design a perfect system in the first place,
> I'm afraid we're going to fail because we will try to manage all complications
> at once and it will be out of hand.
>
I agree. We won't find the limitatins of mastermind until we start using it
ourselves. This is another argument for building the design tools in
mastermind, so that we get first hand experience with the limitations.
I think that the way to proceed is to try to get closure soon on the modeling
language, and start implementing it.
Pedro Szekely
USC/ISI, 4676 Admiralty Way, Marina del Rey, CA 90292
Phone: 310/822-1511, Fax: 310/823-6714
URL: http://www.isi.edu/isd/HUMANOID-HOME.html