[Oberon] Help in using an Oberon systems.

[eas lab]

<zen53397 at zen.co.uk> wrote:-
> Wirth did not design Oberon from 'first principles'. He had 25 years of
> experience to fall back on including designing Pascal, Modula and Modula
> 2, plus exposure to the Cedar/Mesa system and to Algol68.

25 years of experience doesn't prevent people from working from 'first
principles'.
Many of those who 'thought they could mortgage their house for beer'
had decades of.
'experience'. They just decided to ignore first-principles and go-with-the-herd.
It's the same with Coca-Cola and Windows.
50 years of engineering experience won't stop Wirth from thinking in terms of.
Ohms law and the conservation of momentum/energy.

> He felt he knew what was desirable in a language and what was
> problematic. The designer of Safe-C has tried to do just the same.

Fortunately, Wirth could start from a theoretical design basis,
instead of FAT legacy.
BTW, I suspect that Eiffel is also excellent. It just came too late.
Was Plan9 too late too?

>   The virtue of simplicity is an opinion not an axiom..
For any biological entity: a cockroach or me; the highest/most-basic
axiom is "maximum gain
for minimum pain", which directly leads to "optimise the main <cost
center>" which for.
software directly leads to "improve programmer's productivety [not
byte count]" which
directly leads to "simplify".  So the definition of "simplify" in the
context of ETHO
is 'that which improves programmer's productivety'.[I note that you've
acknowledged
'cognitive load' below, as a bad thing.]

And some of those elements are discussed by writers below.

> Wirth is frequently quoted as repeating a saying attributed to Albert
> Einstein, 'make things as simple as possible but not simpler'. But he
> struggled to put this into practice e.g. the number of loop constructs
> to be included, and the need or otherwise for cardinals and for different
> sizes of integer.

Yes, it's difficult to prove optimum simplicity; but didn't you just write
that simplicity is a false goal?

> In making the construction of the compiler as simple as possible by using
> upper case keywords only he imposed an additional 'cognitive load' on
> users because text written in upper case is more difficult to comprehend
> (at least by me) and entering it is much more error prone due to constant
> toggling of the shift key/capitals key. His simplicity is my complexity.

Yes, but that's about WRITING, rather than READING. Besides IMO you shouldn't
pretend to type near-english notes to the little-man-in-the-machine. You should
recognise [not remember] the next-selection from a set-of-valid-selections.
I.e. a syntax directed editor. Imagine that if when entering a lift/elevator,
instead of recognising and activating the required single token, you wrote a
message?

> Interestingly Zonnon the successor to Oberon allows lower case keywords.

Yes, that plus their example which used N-nested IfThenConstructs for the
<dialog between mail/news client and server> gave me a bad impression.

I made a utility that will colour nested constructs, which is the
ultimate 'dimension' that ETHO can handle.

Later I hope to discuss the concatenative paradigm, which is a great
simplifer, but which Wirthian languages ignore, and would have fixed the
absurd nested IfThen constructs by rather doing:.
Stage1 | Stage2 | .... StageN

My favourite example is:-

FindAllFilesin DirD  NewerThanDays 37 |
  whichContainString  aircraft |
  whichContainString  "default judgmemt" |
  whichContainString  Court

Which allows you to re-find that critically important article,
about the aircraft engineer's default judgment case,
which you read shortly before you went on leave 32 days ago.

The beauty of concatenative style, is that if it's correct to stageN,
you don't need to go back, nor even know how previous stages worked.
==Bob Walkden wrote:-
> numerous studies[1] have shown that people find all-caps texts more
> difficult to read than mixed case, but the tests were typically conducted
> using texts significantly longer than any string of consecutive keywords
> you're ever likely to read in a program.

That's our problem. I 'match' the study, but others are free to disagree.

> I find upper case keywords very useful with mixed case source text
> because they provide navigation markers when scanning source code. In
> this way they are rather like paragraph and section headings, which should
> normally differ from the body text in 2 ways (at least according to Tufte)
> to be effective in helping readers to scan.

That's obviously their reason. But psychological stuff is difficult to prove.
IMO the 2-dimensional/matrix is the ultimate/simplest representation of
   a continuous function. I.e. the 'graph';.
   which for discreet values, becomes the matrix/spread-sheet.
Then you can add an extra dimension, of 2 values, by UPPER/lower-case,
 and then a further dimension [all dimensions are mutually orthogonal].
   by a few colours.

That's why, for the most difficult tasks, I need to use LEO and colour.
=========
|   > Is there a source code navigator for Oberon .Mod files?
|   > Like, source-navigator available on Windows/Linux for C/C++ code.
|   >
Chris Burrows wrote:-
|   Yes indeed! Both of our IDEs -
|   CPIde (for Gardens Point Component Pascal):
|     http://www.cfbsoftware.com/cpide
|   and Astrobe:
|     http://www.astrobe.com
|   have the following features:
|   * Automatically generated indexed list of procedures and imports:
|   Click on a procedure name to position the editor at that procedure; click on
|   an import name to open the source code for that import.
|   * Automatic syntax-colouring as you type.
|   * Automatic upper-case conversion of keywords as you type (my pinkies are
|   wasting away!)
|   I use them both a lot when studying / navigating Oberon .Mod files - you
|   just need to strip of the two or three lines of header information when so
|   they become normal text files.

=Aubrey.McIntosh wrote:-
> If you consider "Component Pascal" to be the current version of "Oberon"
> then there is a very nice navigator indeed.

An actual description of the features, like Chris Burrows' above would be.
good, before we invest effort to learn that it's no good for our requirements.

Thanks,

== Chris Glur. I hope this lynx-post works OK.