[Oberon] Narrow Displays and Oberon Language

[Paul Reed]

> From: GitM
> > The OS is not ONLY about exercising the hardware.  It is also about
> > communication with the USER.

> From: "Thomas Frey" <frey at inf.ethz.ch>
> Therefore the original Ceres workstation had a 1024x800 display
> resolution

Thomas, I totally agree with you.  As I've said, I
have a Ceres 3 on my desk and its monitor is a modified
Moniterm VCX1000 manufactured in Minnetonka, MN, in the 
US of A way back in March 1990.  My guess is that the
monitors cost ETH more than each Ceres, anyone from
ETH in that era care to comment? :)

The point is, it's a 21" screen, and Oberon's beautifully
crisp and clear at 1024x768 (viewable area 17").

The first time I got the same experience with other 
hardware that I could afford was last year, when I bought
a Sony VAIO with a really nice 1024x768 TFT display (tape
measure again: 14" viewable area).

I think this demonstrates how far Wirth and Gutknecht
were ahead of their time, and so it is understandable
that they didn't feel the need to pander to the conventions
being tentatively established on how GUIs should work - 
it was far from a foregone conclusion!

As has widely been observed, departing the "bandwagon 
trail" allowed them to simplify greatly the way the
whole system worked.  For some people, it's too simple
(like not having columns, or overloading the mouse
instead of having to remember keyboard shortcuts).

But although I have made great efforts to adapt
Oberon to legacy hardware (e.g. narrower displays), I
view these adaptations as "specialist applications"
and I wouldn't expect the maintainers of ETH Oberon to
be particularly worried about them (I hope you're
reading this Pieter :]).

I sympathise with people's desires to make Oberon
run on diverse hardware (because I do it myself) but
it is impossible to do this without cutting at the
very heart of the design principles which make
Oberon great.

It strikes me that taking a system like Native Oberon
and trying to make it usable on 640x480 is like trying
to make a motorbike by sawing a car in half.


> From: Frank van Riet <Fvanriet at spescom.com>
> Most of the traffic on the mailing list is devoted to the OS aspects of
> Oberon. I'd like to digress from
> this for a while and get some feedback on the language itself. First of
> whatever I say is only aimed at
> Oberon 1 and 2 i.e not Active Oberon, although some of it may be applicable.
> I have used Oberon in developing
> commercial software for some time. I'd like to know if anyone else has been
> doing the same. I have the following
> comments on some limitations that I have experienced.  Some of my comments
> are specific only to the ETH
> implementation of Oberon while others are fundamental to the language.
> 
> Please note that this is not an attack on the language, I'm asking :)
It's always wise to include a caveat like that - we programmers
are sensitive people at heart!  :)

I've been using Oberon as my commercial programming language
since developing a more commercially-oriented compiler based
on Project Oberon in 1997 (see JMLC 2000).

I've used it on everything from a questionnaire data
entry program on DOS, through delivery note software 
on Win32, to CGI scripts on FreeBSD (see the search 
system at http://www.rexfeatures.com).

I find Oberon to be the most productive development
environment I've ever had (I've been programming for
twenty years).

However, I sympathise with your comment about the lack
of unsigned types and #ifdef, since I did at first miss
them from my C programming days.

> 1) The lack of unsigned data types is a great annoyance. Sure there are ways
> of getting around this, but
>         I cannot see that Oberon has gained anything as a language by not
> supporting unsigned types. Sure
>         it makes the compiler simpler, but not significantly. Perhaps it is
> because of the potential complexities
>         of mixing signed and unsigned types in expressions ?  This also does
> not seem like a convincing argument.
>         It could simple have been disallowed.

Having implemented a compiler, the addition of more
basic types makes me cringe, but even Java took the
view that there were certain types you must have.

I don't think it would be that difficult to add them,
but as Patrik will probably tell you :) the 
combinatorial explosion of type conversions (e.g.
inclusion) within the compiler would indeed make
it much bigger.  Disallowing some of these 
conversions would draw complaints from fans of 
type inclusion. :)

Wirth's view has always been to stick to the essential,
and so he would I'm sure say that unsigned types are
just "nice to have".

I don't use SHORTINT a lot, but an unsigned byte is
a pretty fundamental unit on any normal (non-Turing :])
computer, so I end up having to use CHR and ORD to
maintain bytes using CHARs.  I agree this is
unnatural, but I live with it because my compiler
is more maintainable with less types.  I know that's
a personal view. :)

One advantage of a lack of unsigned types is that
it makes me a better programmer, because I think
much more carefully about the full range of my
variables than I did with C.

This amused me recently when I noticed that in BSD 
the byte-range available for locking a file is only 
half what it should be due to signed-unsigned design
failure.  This is a problem for Samba, which must
maintain the DOS byte-range locking semantics, which
are correct (a rare example of DOS > Unix). :]

Would any computer scientists like to comment
about the educational value of fewer basic types,
and therefore a simpler language?

> 2) In developing large systems for different platforms, conditional
> definintions are a real life saver.
>         (e.g. (Borland?) Pascal's $IFDEF) I'm not sure if this is a language
> or an implementational issue,   although I suspect it is the former. Apart
> from having code for differing platforms. Conditionals will
>         get rid of the clutter of debugging code
> 
>         CONST
>                 debug = TRUE;
>         ;;;
>         IF debug THEN ....
> 
>         which is painfully inefficient.
> 
> The below is perhaps more related to the ETH implemetation. Others may very
> implement these differently.
 
I get round the lack of #ifdef by keeping machine-
dependent code in different (parallel) directories,
compiling the one I need when necessary.  I admit
that this sometimes results in similar or identical
code being duplicated in at least some cases.

However, there is one huge advantage to a lack
of conditional compilation: you are developing
the same program as you release.  Wirth says that
Tony Hoare commented on the switching off of
array bounds checking for release programs: it's 
like wearing arm-bands when swimming in
a pool, and then abandoning them when at sea!

I remember my shock in a meeting with Microsoft
back when Excel 3.0 came out (.exe on 1 floppy):
they boasted that the debug version was over 10
megabytes!  ("And that's good?" I thought...)

> 3) Dynamic array headers: Why was the decision made to to stick the header
> in the middle of the structure
>         and not in-front as with other structures. Not only is it
> non-intuitive nit having the pointer point
>         to the firts element, but it would also make language
> interoperability very difficult. Let alone the
>         nightmare of porting older code in which this was not the case...

Can't comment on this one - I think it was done to
support garbage collection of dynamic arrays of
structures, something I don't support.  I point
to the beginning of the array. :)

> 4) Pragmas are only allowed on a per module basis. It would be very usefull
> to disable type guard checking
>         in many cases, simply for the sake of efficiency. True it
> compromises security, but why allow it
>         at all then.

I agree in general that if you have control over
a compiler, it should be fine-grained.  But I
am happy with no guard checking at all (see my
comment about swimming above).  Instead of the
cost of a guard at every access, I insert
ASSERT() statements where necessary to enforce
invariants.
 
> As an aside does anyone know whether read-only exports are still supported ?
  
>  Frank
>---------------------------------------
>Frank van Riet (Software Developer)
>Datavoice  (Pty) Ltd 
>Snail mail      PO Box 582
>                Stellenbosch 7599 
>                South Africa 

Again, can't comment but aren't they like GOTO? :)
I think in Oberon-SA, Wirth disallowed exporting 
variables completely - computer scientists say
you should have exported procedures to set and get 
the value. I know, I know - you are concerned about 
efficiency.  :)

Paul Reed