[ColorForth] code sharing

[Bob Shafer <bobsh@xxxxxxxxx>]

On Thu, 25 Jul 2002, Mark Slicker wrote:

> Someone has to write code to interract with devices. No matter what the 
> system, their is no mathematical "proof" that it does what it says. Why do
> you trust Linux, Windows or Oberon, but not colorForth? colorForth is the
> only one of the four that allows you easily examine the code and indentify
> it does what it says.

I happen to have "Project Oberon" sitting on my desk (borrowed from a
library the other day). It contains all (or nearly all) the source code
to the (first) Oberon System. But the book is much more than that: it
explains the System. (Since that time (late-80s), the System has continued
to evolve, and I don't really follow the latest incarnations much).

Originally, it was developed for custom hardware (the Ceres, built by
the same pair at the same time). However, few people would bother with
it on custom hardware. I quote from the introduction:

     The plan to install it on bare machines, as on Ceres, was quickly
     discarded; nobody would even give it a try, if one had to buy another
     computer or even only to exchange ROMs in order to experiment with
     Oberon.  The drawback of building on top of an existing system had
     to be accepted; [description of the many systems Oberon was ported
     to....] All these systems comply with their published description
     in a user manual (Reiser, 1991), all have exactly the same user
     interface, and every program operating on one of these computers can
     be executed on any of the others without change. Evidently, this
     is an important advantage that can only be gained by programming
     at a higher level of abstraction, such as in the language Oberon.

I bring this all up to contrast with the current situation in colorForth,
and in particular, with the desire to share code.

ColorForth is partly about _not_ abstracting from the hardware, isn't
it? That was what I was trying to get at. Because of that, colorForth
code is inherently non-sharable, unless you take the time to truly
understand it, and then re-implement the bits you need to, to port it
to your hardware.

I'm not sure I'm making sense. I do confess to holding multiple views
of how programming should be done, and there are conflicts between
them. Don't encourage me to bring Lisp into this discussion, for
instance. :-)

However, I will say this. To a rough approximation, I think colorForth is
a remarkably beautiful fit into its level of abstraction (aka: level 0);
go one or maybe two levels of abstraction higher, and you end up with
something like the Oberon System. (As I wrote on comp.lang.forth a while
back, colorForth seems like the absolute minimum Model/View/Controller
system; MVC harkens back to Smalltalk, which is what the Oberon System
is also a distillation of -- so, what I really mean is that colorForth
is a level 0 MVC, Oberon is a level 1 or 2 MVC. Smalltalk is level N,
for N > level 1 or 2 -- roughly speaking.

Feel free to shoot holes into my logic (or lack thereof). I don't mind
a bit! :-)
------------------------

To Unsubscribe from this list, send mail to Mdaemon@xxxxxxxxxxxxxxxxxx with:
unsubscribe ColorForth
as the first and only line within the message body
Problems   -   List-Admin@xxxxxxxxxxxxxxxxxx
Main ColorForth site   -   http://www.colorforth.com
Wiki page http://kristopherjohnson.net/wiki/ColorForth
ColorForth index http://www.users.qwest.net/~loveall/c4index.htm