[Oberon] Project Oberon (was: Coding practice)

[Michael Schierl]

Hello Wojtek,


Am 21.02.2020 um 04:01 schrieb Skulski, Wojciech:
> If there was a common FPGA Oberon System project, then how it would look like? (I know I am dreaming.) Here is my own individual dream list concerning the FPGA Oberon System, which is my main interest.
>
> 1) A project means collaboration among people. So the first step would consist of forming a team willing to communicate and to collaborate on a common FPGA Oberon System.
>
> 2) The team would agree on a set of achievable goals.


In my opinion the order is wrong here. Successful collaboration requires
first to determine the goals (and non-goals) of the collabroration,
because depending on how the goals match, different members may join or
not. And it does not only matter if goals are achievable (by the
members), but also if they are desirable (to most members).

[A good example was the Subversion VCS project, which defined first that
they want to build a centralized version control system, and which
features are in-scope and which are out-of-scope. Then they attracted
like-minded people and were able to achieve their vision, by closing any
feature requests that were out-of-scope of their vision as WONTFIX.]

I guess there are at least 5 people in the list who are interested in
"improving Project Oberon", but what is an improvement to some of them
is a feature-creep or deterioration to others. Which also explains that
there are different code bases.

For example, some time ago I suggested removing some unused exported
members, like Display.Handle, from some Project Oberon modules, and
un-exporting some others, to make coupling lower and make it easier to
understand some code; and immediately I got some reactions why you
cannot remove them - "What if somebody wants to create a different
windowing/input manager? What if somebody wants to extend this or
that?". My answer would be "If they really want, they would have to add
this, or something similar, back".

Another example is actual hardware availability. For me it is enough
that at some point in time, actual hardware existed to run the thing
(proving that the design is indeed implementable in real hardware), and
that today there are some means to still run the thing (which need not
be hardware, but emulation is fine).

So what is an improvement to the system for me is the opposite for
others, and vice versa.


Regards,


Michael