[Oberon] Tool for incremental progress vs. immediate WOW.

[easlab at absamail.co.za]

 Soren Renner wrote:
> >  1. I do admit that functional languages have some claim here as well,
> > especially = Ocaml. It is just that I would prefer it to run on top of Oberon.

Patrick.Hunziker at unibas.ch wrote:
> There is a functional language available in Oberon:
> - Scheme.Mod implements an interpreter for the Scheme language (is 
> in the Gfx package)
> There are some examples about how to use it, hidden in the Gfx 
> documentation.
> - Vinci.Mod utilizes Scheme.Mod for graphical purposes as an example.

Yes there's a mass of potential gems lying hidden; which just need
a bit of polishing to add great value to the total Oberon package
for potential new users.

-------
Soren Renner wrote
> > 
> > [...]
> > Look at it like this: on the one hand, we have what is clearly the
> > best OS and language project in the world*1, yet almost noone
> > will pay any attention to it.

Stefan Salewski wrote:
> Yes, ETH-people have done great work to develop this system, and 
> they were very successful all the years to hide it from the world. And
> I think they will successfully continue this tradition by preventing
> writing down any documentation.
> 
> Please excuse my sarcasm.

>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 ?

-------
> > Translating James Carlson's published C-code
> > implementation
> > might be good ?  BTW a tool-set to *assist* C to
> > Oberon code 
> > translation would be of great value to the Oberon
> > community. 
> 
> John M. Drake wrote:-
> I agree.  Good idea.  Don't know why nobody's ever
> done this.

Linux has p2c utility: Pascal to C; but not c2p.
When I investigated I found:
 because Pascal is clean [canonical] it can be
directly translated to C.
Because C is a dog's-breakfast it can't always be
directly translated to Pascal.

There's a problem, because of the wow-factor: people want
immediate automagical answers, like the 9th root of 87.436;
instead of a 'tool' which 'helps' you create a solution.
Like a pencil & paper doesn't replace your brain, but it's a 
powerfull tool.   So a tool-set to HELP translate some of the mass
of C source code to Oberon would be of great value.

An example of a valuable tool which we have is the FontEditor.


== Chris Glur.