[MUD-Dev] (no subject)

[John Buehler]

>From: Bruce <bruce at puremagic.com>
>Date: Thu, 23 Nov 2000 00:56:14 -0700

>John,
>
>I mean you no disrespect, but I think that perhaps you have been
>a bit overly enthusiastic in some of your posts on this topic.
>
>Many aspects of this topic are active areas of research and
>development, with differing ideas coming out of them.  (Note
>that I am not a fan of inheritance.  I've been arguing with
>people against is-a relationships in MUD-type applications for a
>couple of years now.)
>
>A good programmer, should have a wide variety of tools at his
>beck and call and choose those which are appropriate to the
>situation.  Every task is different, with different goals,
>requirements, and users.  It is important that someone designing
>and/or implementing a system have the freedom to choose those
>tools which they feel will work best within the context of a
>problem and the values that comprise that problem.  In many
>cases, yes, I agree, components will be useful.  Although, what
>exactly is meant by components and the scope of that definition
>may vary depending upon other decisions made during the course of
>design and implementation.

  In 1983 I started writing production software.  In 1998 I was still
writing essentially the same software.  So long as we do not have reuse, I
will have to continue to keep writing that same software.  My time working
with components in a very intense way assures me that components are *A* way
to go.  So I'm going to be very enthusiastic about them until somebody
shoots some holes in them.  Properly understood and employed, they solve a
whole host of problems that plague the software industry.  Certainly they
are a long bit better than the current implementations of inheritance
systems.

  I see it as follows:

  1. I don't want to write code - I want to ship product
  2. I want to reuse what has already been written.
  3. For code to be desireable to reuse, it has to be high quality
  4. In order to reuse code, I have to know what it does

  It doesn't matter how code is created in the first place, and the reuse
paradigm must be simple.  I believe that components offer an opportunity for
the software community to get off its knees and to start walking.  Other
techniques may offer opportunities for even more, but I have yet to see such
a thing - despite being familiar with most of the approaches that you
listed.

  As you say, you enjoy the dynamicism of software, and you probably like
writing code a whole lot.  I did too - for the first 7 years or so.  After
writing the same code over and over again, it gets a bit old.  Lots of
people like the mental games of juggling code and design problems
essentially forever.  It's all a fun hobby that we all get paid lots of
money to play with.  The way we were doing components suggests to me that we
were pursuing the 'physics' of software.  Like I said, I learned more in my
two years on that research team than I did in the 15 years prior.  Note that
during those 15 years, I came up with something very similar to intentional
programming myself.  I like the idea.  But what software do you create with
intentional programming?  Well, components.

  You also mentioned reflection.  That's a critical part of the methodology
that we were using.  Dynamicism was decidedly not.  We cannot currently
manage dynamic software systems.  Heck, we don't even know how to create and
manage STATIC software systems.  I figure we ought to start at the
beginning.

  Many of the other things that you mentioned really aren't in the same
space as components.  In some cases the techniques could be used to
construct components and in other cases components could be used to
implement those systems.

  So pardon my enthusiasm, but if I just put in a comment that read
'components look interesting', I doubt many would look into them.

JB


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