🚀 go-pugleaf

Hi!

On Di 19.03.1996 around 12:37:36 grieblm@trt.allied.com (Mike Griebling)
wrote in message "When will Oberon stop changing?":

> It's a very fine line that Wirth walked when designing Oberon.  A truly
> minimalistic language would resemble an assembler with only assignments
> and a method for looping and procedures.

   This all comes down to the interpretation of Einsteins statement used as
a  "guideline"  for  the  Oberon  project.   In my thesis, I argue that the
statement  is only useful as that, not for following it literally.  I do so
to "justify" my extensions to Oberon-2.

Einsteins statement:

   "Make it as simple as possible, but no simpler."
   (exact wording may differ)

Example:

   Consider  a  programmer  who wants to have a language for pure "hardware
hacking"  in  a  small embedded system application (eg.  a remote control).
Let's  say  he  applies  the  statement  as the "leading guideline" for his
project  and  that  he's  in favour of "structured programming" (instead of
"GOTO-heavy stuff" like assembler).

   What  his  language  will have is a facility to assign symbolic names to
certain  memory  locations  and  processor registers (possibly even a small
BYTE,  WORD,  LONG  type-system),  assignment,  simple  expressions,  an IF
instruction  and  a  loop,  most  likely  a general LOOP ...  EXIT ...  END
thing.  He'd be happy with that language and he has reached his goal.

Conclusion:

   This  argument  is  all  about the "possible" in Einsteins statement.  I
have  to  decide "a priori" what I want to do and then I can try to make it
real "as simple as possible".

   Regarding   Oberon-2  as  a  language  for  (what  I  consider)  "proper
software-engineering",  I feel that multiple sub-typing is necessrary.  The
ETH feels that it is not.

   But  the  point  is,  it  all  depends on what you want to achieve.  The
argument often heard from the ETH "This is not necessary, and it would make
Oberon  to  complicated"  is only valid if you consider carefully what they
want to achieve.

> In general, Oberon-2 strikes
> a nice balance between usability and simplicity. (Note: I didn't say
> Oberon -- the pointers to open arrays in Oberon-2 are an absolute 
> necessity as are the object-oriented facilities).

   See?  Oberon-2 makes you happy.  Oberon makes Wirth happy.  Eiffel makes
Meyer happy.  And Froderon will (hopefully) make me happy.  :-)

   BTW,  if  someone  can provide the orignal reference where Einstein made
his  statement,  please  mail  me  about  it.   I'd  like to read up on the
philosphy behind it.
                  _
By(T)e...   /| _ //3000 /\ People who use Pascal for serious programming |\
   Peter... \| \X/\miga \/ fall into a fatal trap.  (Brian W. Kernighan) |/