[Oberon] Amiga OS and Oberon

[eas lab]

Srinivas Nayak wrote:
>....another small nice OS...

Apparently art thrives on RE-creating the same old good-feelings:
classical masterpieces don't become devalued.

But science must progress. Even if it's problematic, due to subjectivety,
we need to TRY to analyse and capture [to writing] WHAT makes an OS 'nice'.

Even Wirth's aim of 'simplify' is not a top aim, and the higher/caller of
the 'simplify' sub-routine needs to be explicetly stated:
We want the maximum gain for the minimum pain.
Non-simplicity/complexity in computing is a major cause of pain.
Therefore maximise simplicity.

People don't seem to appreciate the distinction between
'Oberon' and 'ETHO/S3/V4'.

IMO S3 is a particular HumanComputerInterface, which could be implemented on
ANY hardware/language [Turing complete system]. IMO the only way that S3/V4
depended on Oberon, was via the mindset of: 'simplify & work from first
principles, rather that keep following the herd'.

Particulaly since I've tried/got ARM/Rpi hardware, I'm hoping to become free
of X86 hardware.  But it's not an ARM-Oberon system that's needed.
The S3/V4 HumanComputerInterface is essential.

I don't want to go backwards, like I've been forced to in my failing-state
location, where the ISP's can no longer handle ETHO-based email and I'm forced
to use inefficient gmail.
------
Claudio Nieder wrote:-

|> Surprisingly, I found a page
|> http://oldwww.nvg.ntnu.no/amiga/amigafaq/AmigaFAQ_25.html
|> saying that, Oberon and Oberon-2 compilers were available on AmigaOS!

>Besides the Compiler, there is also a port of Oberon V4 for the Amiga
>which you can download from
>ftp://www.bluebottle.ethz.ch/Oberon/OberonV4/Amiga/V1.4

This again suggest the failure to distinguish between Oberon & S3/V4.
We have a formal definition of Oberon.
What's the formal definition of S3/V4?
Some essential attributes, of S3/V4, for me would be:--
* multiple texts viewable on screen;
* multiple views of a text on screen;
* often-required-operations performable without accessing the keyboard,
    by being allocated to mouse-chording;
* acknowledgement of the power and economy of 'recognition' instead of
  needing to remember. I.e. the menu, cleverly renamed to 'Tool', in
  order to avoid criticism from macho-kiddies who say "I don't need
  memory aids";
* etc...etc.

These should be formalised/written-down. Like the TenCommandments.

Plan9's acme copied S3, although IMO it claims to be based on Oberon.
It's NOT based on Oberon! It's the HCI of ETHO.
It's the HumanComputerInterface that important.
`wily` is the linux/public-domain version of acme.
Yesterday I finally modified wily to use the same LM, RM as
ETHO for scrolling the viewers down, up. I really don't [want to]
understand the C ? C++ code, and I was just lucky to trace
<which/where *.c mentions "scroll", "up", "down", ...>.

Previously, changing between ETHO and wily, was like riding a bicycle
facing backwards.

LEO, which is Linuxbased:S3 can't execute linux commands directly,
[which Linux:V4 can be programmed to do], which makes wily usefull.

== Chris Glur.

PS. It's so difficult for me to mail from gmail, that I'm not
going to just twitter. It's all about cost-benefit ratio.