[Oberon] Anecdotes: human factor, admission - embarrassment !

[John Drake]

--- easlab at absamail.co.za wrote:

> Since writing this a few days ago I wasn't sure if
> I'd already
> posted it. So I tried to check the mailing-list
> archive.
> n-o can't even read its OWN mailing list -- not good
> !!
> 
> John Drake wrote:-
> 
> > I believe there is an ARM/Xscale port already. 
> See:
> >
>
https://www.mail.inf.ethz.ch/archive/oberon/2004/001407.html
> > ....
> Thanks but n-o can't read 'https', and I must reboot
> to linux and
>  face a song-&-dance dialog about security....
> I'll do it later.

I have no idea why the mailing list archive is on
a secure server (https).  There's no logical reason
for this that I can think of.  On the flipside
n-o needs to be updated to support https.  There
are times when it's useful.  (Online banking for
instance).
 
> > On the flipside the OOC (optimizing Oberon
> > Compiler) and the companion product Visual
> > Oberon are open source projects from the
> > ground up.
> > 
> I don't want to spend time investigating another
> failing route,
> but do you know if 'Visual Oberon' has some 'syntax
> directed
> input facilities' instead of free/blind creating
> source text 
> which is then submitted to the compiler ?

Well, I don't know what the context is of
my mentioning OOC and Visual Oberon.  But
Visual Oberon is not an IDE.  In fact it's
probably misnamed.  When people hear "Visual
Oberon" the immediately think of "Visual
Basic" or something similair.  But Visual
Oberon is really just a GUI toolkit.  You
edit your source with Emacs or vi or whatever
other text editor you want to use.  Perhaps
it should have been called "Oberon-TK" or
something, but I wasn't consulted on this. :)
OOC stands for "Optimizing Oberon Compiler"
and (as the name implies) it's a highly
optimizing compiler based on the diploma
thesis of Michael Van Acken.  Visual Oberon
and OOC are the answer to the question
"How can I write programs for Linux using
the Oberon language that look, feel and act
like Linux programs written in C."

> --------------
> You can't do more than the most brief-trivial
> programming
> without pondering the limitations of human mental
> facilities.
> 
> That's what prompted a previous post re. 'syntax
> editors
> and stuff' which removes the need to remember and
> only
> requires recognition.  Of the several responses none
> IMO got
> to the heart of the problem which is that in n-o the
> ability to
> pick sytactically valid big constructs from a menu
> is an 
> irrelevant labour saver compared to the acrobatics
> needed to 
> eg. 'type-change backwards and forwards' to eg. do
> the 
> equivalent of:  
> 
> OutPort[Blue] := MaxOf(Inport[Height],
> Inport[Length]) LOR Speed;
>   where 'LOR' is binary-bit-or (as all of us
> coming-up via hardware
>   are trained and expected to think); versus the n-o
> absurd syntax.

Well, assuming that MaxOf returns a SET type you
could write:

OutPort[Blue] := MaxOf(Inport[Height],
  Inport[Lenght]) + Speed;

 
>   Plus unconventional inconvenience that n-o won't
> accept
>    functions as args. 

n-o WILL accept functions as arguments.  You just
have to use procedure types.

> Plus the 'natural' priority
> to work with
>    bytes requires punishing mental acrobatics.
>    Perhaps it could be hidden behind a macro-menu ?

Not following you here.  Can you provide an
example?
 
> Briefly: any 'syntax editor' which allows you to
> effortlessly build
> naive code 100 times faster, is as irrelevant as the
> box that runs 
> 100 times faster than my previous 386, and saves me
> 99% of 
> 10 mS for n-o operations - i.e. save me 10 mS.

Oberon compiles were fast enough on a 386 for me.
I haven't seen any proposals to increase compile
times.  People were talking about speeding up
edit times by having the editor type in certain
keywords for you.

> As you know, for effective optimisation, you must
> concentrate
> on the resource consuming areas.    It's no good
> halving the 
> trans-atlantic flight time, to be followed by a six
> hr road delay.
> -------------
> 
> Re. 'Nth generation' smart tools:
> Because I dropped out of industry before the Pspice
> & other simulators
> were common, I'm always wondering how much these
> tools really
> contribute.

Not sure.  There have been some tools built with
Oberon V4 to assist with FPGA design.  But I've
never gotten into FPGA so I can't comment further.
  
> Re. human incapacity to remember vs. recognise:
>   I recently posted a query/request for 'removing
> no-ascii chars',
> and while searching for other utils, I see on my
> Personal.Tool:
>      StripNonASCII.Do <Src> <Dst> ~
> 
> How embarassing: I've previously raised this issue
> and had it 
> attended to already !!
> 
> Which confirms my plea to reduce memory load and
> replace
> it by recognition  - especially if the victim has
> many unrelated
> projects/languages.    It's a nightmare when you
> want to do a
> small task in a language which you haven't used for
> a year or more.

Well since StripNonASCII is an addon (I believe
I wrote it) it's up to the end user to put it
somewhere that he can remember it.  Ideally if
this is something you use a lot it should be
added to your toolbar.  That's something I
don't know how to do.  Hopefully someone
else who's reading this knows how and can
chime in.  Ironically not to long ago I was
griping about losing information when I a
accidently did the "cut" mouse chord only
to have someone else point out that I could
have hit the "Recall" button which was right
in front of my face.  Now how embarassing is
that? ;)

> Ideally the user should need to remember nothing -
> just read the box.

Well, you still have to remember what those
"things on the box" do.  (Like me forgetting
about the Recall button).  But I get your point.

Regards,

John M. Drake

__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com