NetNews Usenet Archive 1992 #16/NN_1992_16.iso/spool/comp/sys/mac/programm/13206

Internet Message Format | 1992-07-30 | 5.4 KB

Path: sparky!uunet!portal!cup.portal.com!Chewy
From: [e-mail] (Paul Frederick Snively)
Newsgroups: comp.sys.mac.programmer
Subject: Re: MacOberon
Message-ID: <[e-mail]>
Date: Thu, 30 Jul 92 09:10:34 PDT
Organization: The Portal System (TM)
References: <[e-mail]>
  <[e-mail]>
Lines: 97

In article <[e-mail]> [e-mail]
(Eric C. Kofoid) writes:

>MacOberon "works" on my Mac (13" monitor).  However, the interface is a real
>show stopper.  Even if you assume the author had no particular reason to
follow >Apple's interface guidelines, it's still a disaster. For example, the
"scroll >bars" work by holding down some modifier key while you click with the
mouse to >move the selected line to the top of the window--but this leaves you
with NO >WAY to scroll backwards! Although MacOberon seems to have quite a bit
of >documentation, you are on your own when it comes to figuring out what to
read >first.

Actually, to scroll forward, no modifier key is needed.  Holding down the
Option key will take you to the beginning of the view, and Control will
position the scroller in proportional style.

>I downloaded MacOberon because I wanted to find out something about the Oberon
>language, but decided I didn't want to know badly enough to hassle with the
>brain-dead interface.  (My interest was only casual; someone with more
>motivation could probably succeed.)

This is a fair assessment, IMHO, if you choose to make the assumption that any
given programming environment on the Macintosh is going to implement the human
interface guidelines.  Since I've used other workstations that implemented
their own interfaces (e.g. Symbolics lisp machines), I guess MacOberon didn't
throw me so much that I just gave it up.  It certainly was tempting at first,
though...

>I don't know if the interface is incidental or integral to Oberon.  If
>incidental, then, as you say, you can't fault somebody for making a free port,
>and maybe somebody will someday do a better job.  But it looked as if the
>interface was part of the Oberon design, and in that case you have to wonder
if >the rest of the language is done as badly and with as little regard to
>state-of-the-art techniques.

This paragraph is difficult to respond to, because in doing so I find myself
putting myself at odds with a generalization of software design that usually
works for me, namely that `form follows function.'  In some sense I suppose
that that is still true of MacOberon (as another poster pointed out, the
nomenclature in the menus simply reflects the fact that those menu items are
neither more nor less than Oberon commands, which have the form
ModuleName.Command and are parsed and activated when Control-clicked on in any
view).  In answer to your question, `Oberon' names both an operating
environment and a programming language, so it can be difficult from a lexical
perspective to differentiate the two.  Oberon in that way follows the trail
blazed by such dynamic environments as Smalltalk and Lisp.  The most obvious
difference between Oberon (the language) and Smalltalk or Lisp (the languages)
is that Oberon is statically typed, a la Algol 60 and its descendents.
However, Oberon as a language has a definition in the form of a report that
clearly delineates where the language begins and ends.  Oberon is a very small
language--smaller even than Modula-2.  It retains Modula-2's strong notions of
interface and implementation separation and type safety while adding the notion
of type extension in order to plug the major conceptual gap in Modula-2 that
often led to programmers circumventing Modula-2's type safety by overuse of
Modula-2's low-level system access capabilities.

In any case, Oberon as a language supports a number of state-of-the-art
language features, such as:

Language
  - Strong type checking
  - Modules with type-checked interfaces and separate compilation
  - Type extension, which provides for object-oriented programming
  - Support for run-time type tests
  - Compatibility between all numeric types (mixed expressions)
  - String operations

Compiler
  - Generates native code; no separate linking necessary
  - Very fast compilation
  - Can compile directly from edit window

System
  - Single-process multitasking
  - Automatic garbage collection
  - Commands: procedures that can be called like programs
  - Dynamic loading (adding modules to a running program)
  - Text as a built-in abstract data type
  - Tools for text and graphics editing, and for program development

>Comments are welcome.  I'd be especially interested in hearing whether anyone
>thinks Oberon itself is neat enough to be worth the trouble of learning the
>interface.

Let's put it this way: I'm sufficiently leery of C++ to be spending a fair
amount of my all-too-rare free time searching for alternatives.  Having FTP'ed
MacOberon 2.4(4) and installed it, and purchased the two Oberon books that
Computer Literacy had (The User's/Programmer's Guide and the Language book, but
not the compiler design book), I believe that I can safely say that regardless
of what you think of the pseudo-Ceres- workstation interface, the language
itself deserves a look, and perhaps someone can come up with a development
environment based on Oberon that would be more acceptable to the majority of
Macintosh programmers.

>--dave

Paul Snively Dissolute Wandering Hacker [e-mail]