Re: [colorforth] How is colorForth different from other Forths?

["Samuel A. Falvo II" <kc5tja@xxxxxxxx>]

On Tuesday 16 December 2003 09:03 pm, Mark Slicker wrote:
> No thank you, I have a permanent boycot against that group. I just

Me too.  Morons.  Very nearly all of them.

> wondered if it was anything specific failing with the design. I guess
> not.

Nope.  It's purely public image, and that's it.  And that pisses me off.  
Just because it doesn't look or behave *exactly* like their preconceived 
notions does not make ColorForth any less a useful tool.  And even if it 
were a less useful tool, it is still something that can be learned from!

(Vaguely related, though still non sequitor: What I love are people who 
say things like, "An assembler, written in assembler?  What's the 
point?!"  Indeed.)

I love the way ColorForth works, philosophically.  But in terms of actual 
implementation, I don't think it's me.  It's not how I think (e.g., I 
expect my addresses to be byte addresses), and it's not what I want from 
my ideal system (e.g., I'd like to use more than three tasks in my 
system; I'd like to link to externally written software, often in C in 
the form of shared object files, and also, I think the underlying 
MachineForth ought to more closely match the stack machine inherent in 
the underlying hardware, rather than restrict it to a uP21 subset).  
Just as PygmyForth wasn't a verbatim copy of cmForth, so too will 
FS/Forth *not* be a verbatim copy of ColorForth/MachineForth.  And yes, 
I *do* have intentions to explore a ColorForth of my own sooner or 
later.  Just not right now.

What appeals to me is the fact that a cmColorForth program is very nearly 
orthogonally persistent[1], an attribute many other OSes have to work 
*hard* at achieving.  ColorForth, on the other hand, seems to yawn at 
the concept, almost inviting us, as coders, to try towards something 
even more challenging.  I think if I do attempt my own ColorForth 
variant, it'll draw many ideas from Jeff Fox's AHA system (based on 
publicly available documentation) as well as from cmColorForth.

I find it amusing that Chuck claims, "We shouldn't be writing more 
Forths, but writing good applications in the Forths we have now.  It 
seems too many of us are playing games," paraphrased as best my memory 
can put it[2].  The problem is that Forth is like a good sports car: if 
it doesn't fit or suit your driving style, you're not going to be happy, 
and the car won't (perceptably) perform nearly as well as it could.  
Here are my personal pet peeves with Forth environments under Linux, for 
example:

 o They are often so utterly underdocumented that they're virtually 
useless.

 o They do not support interactive development.  I had to write my own 
block editor for gforth, plus support words like EMTPY, MARK, and UNMARK 
to support interactive development.  I'm very happy with what I've come 
up with, but it could be better given the right environment.

 o They nearly all run under an operating system environment, yet few 
give truly useful linkage support for using host libraries or APIs.

 o Perhaps most importantly, every Forth implementation I've seen has a 
vocabulary that is in flux from version to version (by necessity, I 
understand, but still).  Consider gforth's external C-linkage wordset, 
which changed incompatibly from 0.4.x to 0.5.x, and once again to 0.6.x.  
This is not conducive to writing good applications under Linux via 
gforth.  Thus, even if you WERE to successfully write an application for 
a particular version of someone else's Forth system, you'll still end up 
having to track every major change they make in your own code, producing 
a maintenance nightmare.

One can observe that ColorForth came about specifically to support OKAD 
and OKAD-II.  Thus, we can (perhaps erroneously) generalize this: one 
can write a good application in Forth given a custom tailored Forth 
environment for that application.

This is not outside the realm of acceptability.  Emacs, for example, is 
an outstanding editor (though too bloated for my tastes), built with a 
relatively small C core basically implementing elisp, and the bulk of 
the editor is itself written in elisp.  AutoCAD has *its* own 
implementation language: AutoLisp.  Quake has Quake-C.  Neverwinter 
Nights has its own scripting language, a dialect of C that is garbage 
collected, that most of it is written in (in fact, if you complete the 
game, you gain access to its sources!).

I'm quite likely wrong about this, but it seems to me that there is a 
general pattern here.  I'm not aware of any successful application 
written in any truely "standard" language except for C.  Most developers 
always tailor the language to suit the needs of the specific 
application.  The only exception to the rule is Yahoo!'s online store, 
which was written in plain vanilla Common Lisp.  But I suspect that 
largely is because one needs only text input and output facilities to 
communicate with the web infrastructure.  Even old-fashioned BASIC can 
satisfy that requirement.

* * *

[1]  Of course, I know it's not truely orthogonally persistent.  Anything 
that cannot be represented directly in the source code itself is not 
saved.  Also, the user is responsible for invoking the SAVE command 
before shutting down.  There are benefits and disadvantages to this.  
One disadvantage is that you have to remember to SAVE first; clearly 
there is room for error here.  However, the benefit is that, if you 
royally screw the system over with a misplaced ! or something (something 
I've personally done many, many times!), you can just reboot/reload to 
restore the system to a known-good state.

[2]  It's amusing because the person who said this is world-reknowned 
himself for constantly evolving new and mutually incompatible Forth 
variants.  I think Chuck's comment inadvertently made him look 
hipocritical in the eyes of many, especially when taken out of context.

--
Samuel A. Falvo II


---------------------------------------------------------------------
To unsubscribe, e-mail: colorforth-unsubscribe@xxxxxxxxxxxxxxxxxx
For additional commands, e-mail: colorforth-help@xxxxxxxxxxxxxxxxxx
Main web page - http://www.colorforth.com