"Environment tests"

Alejandro F. Reimondo aleReimondo at smalltalking.net
Wed Nov 5 10:18:15 UTC 2003


Hi Andreas,

> Thanks for the info. One thing I am wondering about is the following. When
> we write tests, we typically model our "internal assumptions" quite
> precisely which helps us to track may of the problems that occur when
those
> assumptions (even slightly) change. Is there anything in research that
> explains why we don't do this on the environment?

The main inconvenience is because the "environment" is not an object.
If you "model" the environment as an object you are reducing the concept
 and the result of reduction will inevitably have less information power.

It is not true that we can make anObject from any thing.
Of course we can think that aThing is anObject ... but it
 only defines our (current) point of view.
To make a thing "our" object do not constrain the thing,
 it only reduce the information power (preserves our inocense).

Why the environment is not an object?
Because the environment is an open system (objects are "entities" of a
closed set of rules, a closed system).
An environment is NOT the objects its contain. An environment is a
trajectory in time.
You can´t reduce the environment to current definition because you loose the
most important part (the trajectory).
Working in an ambient(= = Environment) is very important to learn how to
behave in a way that do not break it.
To learn how to make actions in an ambient without loosing stalibity is NOT
related with science nor instruction, it is related with "education".
We have in Smalltalk a medium to educate, not only to instruct people
(instruct people on how to reduct the world to "simple" objects).

>Is it just considered too big a task?

The problem is not related with size. It is related with time (is an
enviromental problem).
The environment is a trajectory in time, an open system (open not because
you can add objects... open because it is more than its definition, more
that the sum of its parts)

But... what can we do with goodies, packages, and tools that are simply
objects?
Objects have the ability to change. The environment do NOT change. The
environment evolves. (evolution is not the pass throug of changes, evolution
is observed in retrospective, as history, it can´t be predicted)
The changes you can see in the environment are reductions(emergents) of the
main evolving process occurring in the environment (the in-formation
process). So, if you manage changes (e.g. version control) you are solving
"another problem" (correct answer for a wrong question).

The solution must not be modeled as an object. It can´t be expressed IN the
environment.
The solution is named "education" and it can't be done by software (software
objects can only give instruction).
The solution must be in the humman side of the community.

How can we reduce the instalation problems?
We can reduce the instalation problems knowing that:
1.- any instalation is a kind of contaminant to OUR current environment. So
it must be handled with care. It is innocent to download in seconds,
install, run and do not have "side effects" (emergences).
2.- any object has an author and he/she MUST be the humman been more
interested in do not breaking the environments of other people (the author
must mantain the object/package to grant stability and upToDate status)
3.- must exist a commission to determine & regulate the obsolescence of
objects in the repository.
4.- it is helpfull to have a votation mechanism about packages to help the
author know the effort he must invert in mantainment of the package or if it
must be retired from the repository.
5.-we all must learn to work in an environment building objects that produce
the minimal "directed changes" on the environment. (another formulation of
the homogeinity principle)

The only "solution" as I know is to "relax and do smalltalk" :-)

hope this helps,
Ale.

----- Original Message -----
From: "Andreas Raab" <andreas.raab at gmx.de>
To: "'The general-purpose Squeak developers list'"
<squeak-dev at lists.squeakfoundation.org>
Sent: Wednesday, November 05, 2003 5:15 AM
Subject: RE: "Environment tests"


> Hi Stef,
>
> Thanks for the info. One thing I am wondering about is the following. When
> we write tests, we typically model our "internal assumptions" quite
> precisely which helps us to track may of the problems that occur when
those
> assumptions (even slightly) change. Is there anything in research that
> explains why we don't do this on the environment? Is it just considered
too
> big a task? Or is it that we merely assume that we have an unchanging
target
> (which requires people/vendors to fix the API once and forever)? Or is it
> that - because in many cases we simply don't know enough about the
> environment (black box reuse) - we don't even know what assumptions we
(and
> the environemnt itself) is making? What I am interested in here is to
> understand what the causal effect(s) for our effectively blindly relying
on
> the environment is.
>
> Just curious,
>   - Andreas
>
> > -----Original Message-----
> > From: squeak-dev-bounces at lists.squeakfoundation.org
> > [mailto:squeak-dev-bounces at lists.squeakfoundation.org] On
> > Behalf Of ducasse
> > Sent: Wednesday, November 05, 2003 9:06 AM
> > To: The general-purpose Squeak developers list
> > Subject: Re: "Environment tests"
> >
> >
> > Hi andreas
> >
> > Even with Java or languages with a static type system,
> > nothing prevents
> > you that your system will break. There are a lot of research
> > papers on
> > that and none
> > provide a good solution. Between one version and another one the same
> > interface
> > can hold but the behavior slightly changes and break everything
> > (fragile base problem for example).
> >
> > The minimal first step would be to be able to rely on well-known and
> > identifiable versions of other components (package).
> >
> > Stef
> >
> > On Mercredi, nov 5, 2003, at 08:32 Europe/Zurich, Andreas Raab wrote:
> >
> > > Hi Guys,
> > >
> > > Here's a weird and somewhat OT thought that was triggered by a
> > > discussion I
> > > had today. One of the things I am noticing when looking at
> > SqueakMap
> > > (and my
> > > use of it) over the last year is that many of the packages that are
> > > available from SM tend to break in the face of later Squeak
> > versions.
> > > What
> > > happens? Effectively, these packages have been written under the
> > > assumptions
> > > of a certain environment in which they exist (namely that of Squeak
> > > X.Y) and
> > > if these assumptions are ever (even partially) invalidated
> > they break.
> > >
> > > In the discussion I had today Alan (again) mentioned that
> > one of the
> > > things
> > > that could be done for making sure an object (or a package) can
> > > survive in
> > > some environment is to model (at least some) of the
> > assumptions about
> > > the
> > > environment explicitly. We do this internally by, for
> > example, using
> > > unit
> > > tests for the package but typically we have no model
> > whatsoever about
> > > our
> > > environment. This is (at least I think so) an even larger
> > problem for a
> > > dynamically typed environment than it is for a statically typed
> > > environment.
> > > In the statically typed environment you can at least be
> > assured that
> > > the
> > > compiler will do certain checks on your types (and
> > messages) so unless
> > > the
> > > semantics of some message (or type) changes you should be safe (in
> > > theory).
> > >
> > > What I'm curious about here is: Has anyone ever seen a
> > (hopefully even
> > > usable ;) approach to model "environmental assumptions"?
> > Are there any
> > > common rules/guidelines on which "environment tests" could be based?
> > > Anything else in this area?
> > >
> > > Cheers,
> > >   - Andreas
> > >
> > >
> > >
> >
> >
>
>




More information about the Squeak-dev mailing list