[MUD-Dev] Object Models

[John Buehler]

> Miroslav Silovic

> > I'm still leery of getting into the design of a skill system as
> an example.
> > I'm not sure how I'd structure it.
>
> This ties into your comment about dynamic object system design being a
> harder problem than static system design. I disagree with that. Losely
> specified problems are precisely the thing for dynamic languages/OO
> systems to handle, because they allow rapid and global changes in the
> interfaces.
>
> The other thing about dynamic languages is the programming paradigm:
> namely, the basic assumption of a static language is the existance of
> edit/compile/test/debug cycle. In this situation, you really want your
> errors caught during compilation phase, because -all other- phases are
> prohibitively expensive, both time-wise and effort-wise.

Fortunately, it is not MY basic assumption that the construction paradigm is
edit/compile/etc.  The primary requirement for system construction using the
techniques that I learned is strong typing.  Thus precise contracts, etc.
The reason that dynamic systems are a bear is because you have to know how
to construct and implement contracts on the fly.  As a general problem that
may even be intractable (completely off-hand remark).  But I'm sure that
some certain class of primitive contracts can be composed and implemented on
the fly.  For example, get/set methods for attributes and the like.

> Dynamic language allow for interactive compilation. In this paradigm,
> the module size is *one function*. You write a single method, and you
> have a command line and an instance of a running environment (note,
> this means you have not only the runtime loaded, but also live
> data). You test this function on live data as soon as you've written
> it. This merges edit, compilation and debugging portions of the cycle,
> leaving only a good test suite - but you write it individually for
> each function, and run it as soon as the function is written. This
> programming paradigm is drastically different from the static
> programming style, and allows both for rapid design and for rapid
> refactoring of large portions of any application.

The development system that we were working on involved an
edit/compile/run/verify cycle.  The verification step was to ensure that the
component implemented the observable requirements of the contracts involved.
We postulated a system where you type your code and you get to see sections
of the contract go from red to green as they are successfully implemented -
among other things.

This is essentially what you're talking about, but the bottom line is that
the instructions that the engineer provides to the machine have to be
converted to an executable form and then run and verified, whether by human
or by machine.  It's all just a matter of having enough cycles and smart
enough tools to do all the processing with the smallest incremental effort
over the last pass.  Change a single character and there's no need to
rebuild the entire system - especially if you have strong types and know
exactly what a change of one character will impact.

JB


_______________________________________________
MUD-Dev mailing list
MUD-Dev at kanga.nu
https://www.kanga.nu/lists/listinfo/mud-dev