[Oberon] Re: Decreasing entropy

Stefan Salewski Salewski at physnet.uni-hamburg.de
Sun Jan 16 14:20:47 CET 2005


Chris Glur (easlab at absamail.co.za) wrote:
> 
> From all my harping on this same topic for 5 [or is it 10] years I've
> distilled the following ideas [also by observing other collaborative 
> systems which work better]:
> * there's entropy: stuff get dirty and broken - unintentionally.
> * let's try 'negative entropy': stuff 'evolves' - unintentionally.
>     There are these massive piles of stones in various parts of the 
>     world, which have evolved over centuries from people who [for 
>    religious reasons] throw a stone on the pile, when passing.  
>   I.e. a  'method of capturing even small contributions'.
> The massive pile evolves unintentionally.
> The collaborative systems which which I know well which work 
> better than oberon at inf.ethz.ch depend on a 'boss-man' who
> co-ordinates the contributions. This is less than ideal, because 
> the 'idea' [like the stone pile] should survive and grow, 
> independant of any individual.  I guess linux has acheived this ?
> 
> By moving up the heirarchy of control one achieves leaverage. 
> Ie. 'never mind about doing coding', rather concentrate on 
> developing systems which will ensure that coding effort is captured 
> and adds value.
> Eg. when a new contribution is made, what about naming conventions
> and clashes with existing material; how is it integrated into the 
> existing ...etc.  These considerations need to be formulated, instead 
> of each contributor making his own.  Remove creativity from tasks
> which can be formalised.   Perhaps this is the difference between
> coding and software engineering ?
> 

Hello,

I agree with the core of the above statements of Chris Glur.

Software engineering, like all modern engineering, needs structured
and formalised methods.

At the beginning of each complex project there must be a project description,
and during the project members have to write reports about their progress and
they have to document their work in a formalised way.

Business companies take care of this very strong, while at universities the
organisation of the work is not always very good.

I have make a few negative experiences myself: A not too good project plan of
my own PhD-thesis, useless measurements as a result of bad documentation of
all parameters, or impossibility to continue or use experiments of my co-workers
as a result of incomplete descriptions. 

But I an sure ETH knows all this very well, and I an sure inside of ETH there
exists very precise project plans and very good documentation of all their great
work. Like the description of Active Oberon Language by Patrik Reali or like the
description of the internals of AOS in the PhD-thesis of Pieter Muller. 

But unfortunately the world outside of ETH will see all of this only with very long
delay or never. This makes it very difficult for people outside of ETH to
contribute to the project.  

Best regards 

Stefan Salewski



More information about the Oberon mailing list