[ColorForth] code sharing

[Mark Slicker <maslicke@xxxxxxxxxxx>]

On Thu, 25 Jul 2002, Bob Shafer wrote:

> 
> 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).
> 

I think it was you who sugested looking a Native Oberon for device
code. When I checked, the kernel was closed source, only available to
other academics.

> 
> ColorForth is partly about _not_ abstracting from the hardware, isn't
> it?

Right.

> 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.
> 

But remember, machines are a commodity now. Code that works on one
32-bit intel will work another (cpu code, not device code). There are
esentially two classes of commodity hardware. One is intel the other is
powerpc, ignore workstations since they are a small minority. As Chuck
wrote on his site, macros do factor the machine specific code, so his
helps in porting the machine specific code.

> 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.
> 

The level of abstraction is indeed low. I think the aproach does have
merrit.

My concern is not so much the level of abstraction but the level of
expressiveness of a language. Sometimes you need a low level to truely
express what you want the computer do. colorForth's low level does not
lead to low level of expression. After all Chuck was able to describe
his CAD tools in only 500 lines!

Absraction can be done in colorForth like any other language. Forths in
particular seem apt to abstracion since you can extend the language to fit
the problem.

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

Glad to hear, that was the intent of my first message, to provide a
platform for people with different methods. Unfortunately it was taken as
hostile. I'm not hostile toward ASCII just wanted to hear the opinion of
those that have good amount of experience with it (I have no ASCII forth
experience). 

Mark

------------------------

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