Hi,

Announcing the cfdos EuroForth 2003 edition.
Includes a 1kHz timer interrupt incrementing a magenta variable - type "int"
and "vv" to see the program change the source.
Also many other demo programs....

www.inventio.co.uk/cfdos.htm

Still no takers for my competition :

I am offering a prize of a set of four colorForth floppies ( value �2-00 )
to the first person to create an analogue of the colorForth magenta variable
in any other computer language ( and convince me that it works ).
Magenta variables return the address of the following cell in the source
block, which means that when their value is changed using "!" the source
changes too.

Regards

Howerd  8^)

"Howerd Oakford" <howerd.oakford@ntlworld.com> wrote in message
news:ZoGjb.1006$e02.1000351@newsfep1-win.server.ntli.net...
> I am offering a prize of a set of four colorForth
> floppies ( value �2-00 ) to the first person to
> create an analogue of the colorForth magenta
> variable in any other computer language ( and
> convince me that it works ).  Magenta variables
> return the address of the following cell in the
> source block, which means that when their value
> is changed using "!" the source changes too.

Since I love a challenge, here's an implementation of magenta variables in
Perl.  There is nothing really special about the choice of Perl here.  I
could have done exactly the same thing in Python, Lua, Ruby, or any language
that allows hooking into the primitive fetch and store operations on a
variable.  Really, your challenge is pretty trivial in most modern
interpreted languages with such a facility.

Here's the Magenta module:

----- start Magenta.pm -----
package Magenta;

sub TIESCALAR {
    my %private;
    my $class = shift;
    $private{'file'} = shift;
    $private{'name'} = shift;
    $private{'value'} = shift;
    return bless \%private, $class;
}

sub FETCH {
    my $self = shift;
    return $$self{'value'};
}

sub STORE {
    my ($self, $newValue) = @_;
    $$self{'value'} = $newValue;

    my $recSep = $/;
    undef $/;
    open FILE, $$self{'file'} or die;
    my $file = <FILE>;
    close FILE;
    $/ = $recSep;

    $file =~ s/(tie\s+\$$$self{'name'}\s*,([^,]+,){3})([^;]+)/$1 $newValue/;

    open FILE, '>' . $$self{'file'} or die;
    print FILE $file;
    close FILE;

    return $$self{'value'};
}

1;
----- end Magenta.pm -----

And here is a Perl file that uses this module:

----- start test.pl -----
use Magenta;

tie $thing, 'Magenta', 'test.pl', 'thing', 42;

$thing *= 668;
----- end test.pl -----

In the line with the 'tie', I have declared a variable named "thing" that
starts off having the value 42 (which is of course, The Answer).  On the
line after this declaration, I am multiplying The Answer by The Neighbor of
the Beast.  According to my trusty RPN calculator, the result should be
28056.

So I run the code with "perl test.pl" and now let's look at the test.pl
source:

----- start test.pl -----
use Magenta;

tie $thing, 'Magenta', 'test.pl', 'thing', 28056;

$thing *= 668;
----- end test.pl -----

Golly, you'll see that the source code has changed to reflect the result of
the multiplication.  And all the programmer had to do was declare 'thing' to
be a special kind of Magenta variable.

Hey, let's run this again.  My calculator says that 28056 times 668 is
18741408.  Here's the source file after running:

----- start test.pl -----
use Magenta;

tie $thing, 'Magenta', 'test.pl', 'thing', 18741408;

$thing *= 668;
----- end test.pl -----

Tada.

Some notes:

0.  I'm changing the variable each and every time there is an assignment to
it.  This is inefficient, but here I'm not concerned with efficiency but
rather showing your challenge is possible.  To make this more efficient, one
should really only write the final value of the variable (if it changed)
when the variable is destructed (such as when it loses scope, or the program
ends).

1.  The need to specify the filename and the variable name in the 'tie'
statement could be hidden behind what are called "source filters" in Perl.
Here, I'm not concerned with making it pretty, just showing that your
challenge is possible.  If someone really wanted magenta variables in Perl,
they could spend the time to make it look nicer.

2.  In Perl, a scalar can hold more than just numbers.  It can store
strings, references to arrays and hashes, and a few other things.  To handle
that, one could use the Data::Dumper module to serialize the value of the
variable to the source file.  Here, I didn't bother, but it wouldn't be hard
to do.

3.  The value of magenta variables in ColorForth (or now, Perl) seems to be
that they make persistence of the values easy.  But the downside is that
since the source changes, the programmer doesn't know if they are seeing the
original source value, or some value that replaced the original value
because of some calculation.  I would think that would get awfully
confusing.  Can you give some examples of how magenta variables are useful
(and not just in the generic sense, as a method of persistence-- I would
like a real-world example that shows the value.)

4.  You can keep your prize.  Floppies are increasingly an anachronism on
modern machines-- my laptop doesn't have a floppy drive, and I haven't
missed it at all.  Instead, next time you're in Rochester, New York, call me
up and you can buy me a chai latte with whipped cream on top.

----- Original Message -----
From: "John Passaniti" <nntp@JapanIsShinto.com>
Newsgroups: comp.lang.forth
To: <comp.lang.forth@ada-france.org>
Sent: Sunday, October 19, 2003 11:42
Subject: Re: ANN cfdos - EuroForth 2003 edition


> Since I love a challenge, <snipped>

I am glad you do.

> 4.  You can keep your prize.  Floppies are increasingly an anachronism on
> modern machines-- my laptop doesn't have a floppy drive, and I haven't
> missed it at all.  Instead, next time you're in Rochester, New York, call
me
> up and you can buy me a chai latte with whipped cream on top.

I suggest you give the prize to the first person who modifies original
ColorForth to use ordinary keyboard layout, and ordinary character set. It
is more fun than a cup of coffee (I can not wait to hear your comments in
clf).

Regards,
Petrus - Pet4th.

Petrus Prawirodidjojo wrote:

> I suggest you give the prize to the first person who modifies original
> ColorForth to use ordinary keyboard layout, and ordinary character set. It

    Does this qualify :

http://www.users.qwest.net/~loveall/binary/4word35.zip

(From http://www.users.qwest.net/~loveall/ModProg.htm )

    Cheers,

    PhiHo.

"Petrus Prawirodidjojo" <petrusp@attglobal.net> wrote in message
news:mailman.113.1066570914.25614.comp.lang.forth@ada-france.org...
>
> ----- Original Message -----
> From: "John Passaniti" <nntp@JapanIsShinto.com>
> Newsgroups: comp.lang.forth
> To: <comp.lang.forth@ada-france.org>
> Sent: Sunday, October 19, 2003 11:42
> Subject: Re: ANN cfdos - EuroForth 2003 edition
>
>
> > Since I love a challenge, <snipped>
>
> I am glad you do.
>
> > 4.  You can keep your prize.  Floppies are increasingly an anachronism
on
> > modern machines-- my laptop doesn't have a floppy drive, and I haven't
> > missed it at all.  Instead, next time you're in Rochester, New York,
call
> me
> > up and you can buy me a chai latte with whipped cream on top.
>
> I suggest you give the prize to the first person who modifies original
> ColorForth to use ordinary keyboard layout, and ordinary character set. It
> is more fun than a cup of coffee (I can not wait to hear your comments in
> clf).
>
> Regards,
> Petrus - Pet4th.
>
>

"Petrus Prawirodidjojo" <petrusp@attglobal.net> wrote in message news:<mailman.113.1066570914.25614.comp.lang.forth@ada-france.org>...

> 
> I suggest you give the prize to the first person who modifies original
> ColorForth to use ordinary keyboard layout, and ordinary character set. It
> is more fun than a cup of coffee (I can not wait to hear your comments in
> clf).

Peter Appelman has done a qwerty colorForth:

http://home.cogeco.ca/~pja/qwerty.html

ASCII could be done, but it seems those who use are colorForth are
satified with the 48 character set.

Mark

"Petrus Prawirodidjojo" <petrusp@attglobal.net> wrote in message
news:mailman.113.1066570914.25614.comp.lang.forth@ada-france.org...
> I suggest you give the prize to the first person who
> modifies original ColorForth to use ordinary
> keyboard layout, and ordinary character set. It
> is more fun than a cup of coffee (I can not wait
> to hear your comments in clf).

I asked for a chai latte as my prize.  A chai latte is spiced tea, not
coffee.  I hate coffee.

As for ColorForth's keyboard layout and character set-- who cares.  The way
I view this is that ColorForth is a personal expression of what Charles
Moore wants in a programming environment.  It was created for himself and
only himself.  If others happen to like it, that's fine, but there was
apparently zero time put into making ColorForth be anything more than a
system to appeal to Mr. Moore's arbitrary choices and sense of software
aesthetics.

I'm sure that lots of people will find Mr. Moore's odd keyboard layout and
his crippled English-centric character set to not work for them.  That's
fine-- they can go off and implement their own version of ColorForth that
conforms to their choices.  There is nothing sacred here.  If you want a
full keyboard and character set, there is no reason why you couldn't
implement that and still retain all the character and flavor of ColorForth.

I'm sure the purists will disagree.  They will likely say that ColorForth
*requires* Mr. Moore's keyboard layout, *requires* the limited character
set, *requires* the particular Huffman encoding, and so on.  Feel free to
ignore these people.  They lack imagination and the ability to see other
solutions to the same problems Mr. Moore tried to solve.

----- Original Message -----
From: "John Passaniti" <nntp@JapanIsShinto.com>
Newsgroups: comp.lang.forth
To: <comp.lang.forth@ada-france.org>
Sent: Monday, October 20, 2003 04:00
Subject: Re: ANN cfdos - EuroForth 2003 edition


> I asked for a chai latte as my prize.  A chai latte is spiced tea, not
> coffee.  I hate coffee.

This chai latte must be good. I must try it someday.

> As for ColorForth's keyboard layout and character set-- who cares.  The
way
> I view this is that ColorForth is a personal expression of what Charles
> Moore wants in a programming environment.  It was created for himself and
> only himself.  If others happen to like it, that's fine, but there was
> apparently zero time put into making ColorForth be anything more than a
> system to appeal to Mr. Moore's arbitrary choices and sense of software
> aesthetics.

I feel the same. But are you sure, that there are no gold inside the
uncommon keyboard layout and uncommon character set? Something that we can
learn?

Regards,
Petrus - Pet4th.

"Petrus Prawirodidjojo" <petrusp@attglobal.net> wrote in message
news:mailman.126.1066692819.25614.comp.lang.forth@ada-france.org...
> I feel the same. But are you sure, that there are no
> gold inside the uncommon keyboard layout and
> uncommon character set? Something that we can
> learn?

Yes, we can learn from the keyboard layout and the character set.  We can
learn that Mr. Moore values software designed around his personal needs and
whims.  From that, we can learn that we too can approach software in the
same way.

I think people often confuse the idea for the implementation.  For example,
take the Huffman-compression used in ColorForth.  The idea (or at least part
of the idea) is to be able to compress identifiers down to a single 32-bit
value.  As a 32-bit value, one can do blindingly-fast lookups in a
dictionary.  (The downside is that identifiers are only significant to
however many bits can fit in the 32-bit value.)

So let's take the idea of (essentially) hashing a string down to a 32-bit
integer and separate it from the ColorForth implementation.  Another way to
approach the same problem is to use interned strings.  That is, every
*unique* string in an application is stored in a table, and the *unique*
address of that string is used for comparisons.  This does exactly the same
thing as Mr. Moore's hashing strings to 32-bits, but has the added
advantages that:

1.  Strings can be any length, no arbitrary limits because of compression.
2.  String comparisons are simply pointer comparisons.
3.  This is a general facility that can be reused throughout the system, not
just the ColorForth dictionary.

There is a cost of interning the strings in the first place, but there are
some nifty (and brutally simple) hashing algorithms that can be used to make
the cost very low.  And applying the philosophy of doing as much as possible
at edit time, the cost is the same as for Huffman compression-- it happens
faster than anyone can type.-- without any of the downsides.

So what's the critical idea behind the keyboard? I think this is mostly a
desire on Mr. Moore's part for simple hardware, and he sees keys he doesn't
use as complexity.  Of course, the keys he doesn't use may be vital to
someone else, so in separating the idea from the implementation, one should
take from it the idea of finding the minimal set of keys needed to create a
user interface.

In a product my company has designed, we used the example of ColorForth's
minimal keyboard to rethink how we might want to change the control surface
of a product.  In our case, after thinking about it, we were able to reduce
the keyboard that had four buttons to just one, using long and short button
presses to perfom different functions.

So what's the critical idea behind the character set?  I think it is mostly
a statement that one doesn't need to internally implement ASCII, Unicode, or
any other character set in an application.  You are free to create your own
character set that is tuned to your needs and your storage requirements.

----- Original Message -----
From: "John Passaniti" <nntp@JapanIsShinto.com>
Newsgroups: comp.lang.forth
To: <comp.lang.forth@ada-france.org>
Sent: Tuesday, October 21, 2003 15:05
Subject: Re: ANN cfdos - EuroForth 2003 edition


>
> "Petrus Prawirodidjojo" <petrusp@attglobal.net> wrote in message
> news:mailman.126.1066692819.25614.comp.lang.forth@ada-france.org...
> > I feel the same. But are you sure, that there are no
> > gold inside the uncommon keyboard layout and
> > uncommon character set? Something that we can
> > learn?
>
> Yes, we can learn from the keyboard layout and the character set.  We can
> learn that Mr. Moore values software designed around his personal needs
and
> whims.  From that, we can learn that we too can approach software in the
> same way.

Those are about keyboard layout and character set. There is freedom. Or
should we say, 'emptyness', 'shapeless'?

What about the rest of ColorForth, is there something that we can learn?

Which Forth do you like most, F79, F83, F94 or ColorForth? In what order?

And, what is Forth for you? Why do you like Forth, when do you use Forth?

Regards,
Petrus - Pet4th.

"Petrus Prawirodidjojo" <petrusp@attglobal.net> wrote in message
news:mailman.158.1066778165.25614.comp.lang.forth@ada-france.org...
> Those are about keyboard layout and character set. There
> is freedom. Or should we say, 'emptyness', 'shapeless'?

I'm not sure what your statement is.  This sounds more like some poetic or
philosophical statement.

> What about the rest of ColorForth, is there
> something that we can learn?

Sure, there is lots.  I already touched on one example-- that Huffman
compression of characters is not essential to ColorForth and represents an
arbitrary design choice of Mr. Moore.  Strip away the implementation and you
see that the idea is about replacing relatively slow character-by-character
string comparisons with the comparison of a unique hashed value representing
the string.  Interned strings are one replacement for Huffman compression.

But there are plenty of other examples where we can learn from the ideas of
ColorForth, and ignore the implementation.  One big example is color itself.
The purpose of color is to signal switching to a different interpreter (or
more abstractly) to show the class of a token.  Color was an obvious choice
because color is cheap (nearly everyone these days uses a color monitor and
most video generation hardware can easily generate color).  Color was also
an obvious choice because programmers have used color in editors for years
to show different classes of words.  But color itself isn't necessary.

One could replace color with other kinds of font changes.  Maybe numeric
literals could appear in a Courier font, comments in italics, executable
words in Times Roman boldface, and so on.  Call it FontForth and you have
the same idea, but with a different implementation.  I also had suggested a
variant of ColorForth that would use XML tags, and those tags would provide
the necessary semantic information for the tokens.

One could also do a mutation of ColorForth that replaced Mr. Moore's colors
with character tokens that represented the same thing.

For example, in ColorForth, a compiled number is green, and an executed
number is yellow.  Instead of color, one could use "#" for compiled numbers,
and "^" for executed numbers, converting this:

    (green) 42 (yellow) 668

To this:

    #42 ^668

The "#" and "^" wouldn't be part of the source code.  After all, ColorForth
preparses source and stores it in a different form (another good idea where
the implementation isn't important).  The programmer would type these prefix
characters, but the parser would store it however it made sense-- including
just like ColorForth stores things now.

> Which Forth do you like most, F79, F83, F94
> or ColorForth? In what order?
>
> And, what is Forth for you? Why do you like
> Forth, when do you use Forth?

When I use a "real" Forth, it is usually Gforth, since that runs under both
Windows XP and Linux.  But in general, I stopped viewing Forth as a
implementation or product a long time ago and instead saw it as a toolbox of
facilities I can freely use in other applications.  That is, when I'm
programming and I need something with the flexibility of Forth as part of a
larger application, I will build what I need.

A recent example was a monitor I wrote to help bring some hardware up.  I
needed something that let me test hardware and to interactively execute
routines in my C code.  So I wrote a simple interpreter that tokenized input
text like Forth does, looks up and executes tokens in a dictionary like
Forth does.  It can't extend itself like a real Forth because (at this
point) I don't need it.  When I do, I'll add it.

Call it "just in time" programming.  I'll pick and choose the features I
like from Forth and build them into my applications as necessary.

----- Original Message -----
From: "John Passaniti" <nntp@JapanIsShinto.com>
Newsgroups: comp.lang.forth
To: <comp.lang.forth@ada-france.org>
Sent: Wednesday, October 22, 2003 10:52
Subject: Re: ANN cfdos - EuroForth 2003 edition


> "Petrus Prawirodidjojo" <petrusp@attglobal.net> wrote in message
> news:mailman.158.1066778165.25614.comp.lang.forth@ada-france.org...
> > Those are about keyboard layout and character set. There
> > is freedom. Or should we say, 'emptyness', 'shapeless'?
>
> I'm not sure what your statement is.  This sounds more like some poetic or
> philosophical statement.

You say that we are free to use any keyboard layout and any character set.
There is freedom. It is not confined to any rules. No rules, no shape,
empty.

> Call it "just in time" programming.  I'll pick and choose the features I
> like from Forth and build them into my applications as necessary.

Sometimes I treat Forth as a macro for assembly language. And other times
Forth is for quick and dirty solution. And sometimes I feel like I have
become a machine doing the stack juggling, the job that should be given to a
compiler. But I have the freedom, program in any way I like.

Thanks for your comments.

Regards,
Petrus - Pet4th.

"Howerd Oakford" <howerd.oakford@ntlworld.com> wrote in message news:<ZoGjb.1006$e02.1000351@newsfep1-win.server.ntli.net>...

> Announcing the cfdos EuroForth 2003 edition.
> Includes a 1kHz timer interrupt incrementing a magenta variable - type "int"
> and "vv" to see the program change the source.

Seeing a timer interrupt change a variable in source in the editor
is unusual and suggests some of what has to go on for this to happen.

> Also many other demo programs....
> 
> www.inventio.co.uk/cfdos.htm

Yery nice. I have been pleased to see all the ports of colorforth.

> Still no takers for my competition :

I doubt if people really understand what magenta variables really are
and what sort of things one can do with them in colorforth.  Magenta
variables are really nothing special in that any variable can be
green, yellow, magenta etc.  In fact to do what colorforth does the
magenta color behavior must be available on any variable.

In colorforth the name of a variable will return an address, or return
the contents of that address, or return the address of the cell in the
source where the initial binary value of that variable in the source
code is specified.  So to do what colorforth does with magenta variables
a system would have to be able to do something like ! into the source
of any ordinary variable.  That would be rather difficult if you were
editing a version of the source at the time.

Also to do what colorforth is doing there needs to be a mechanism to
update the display in real-time to show changes to the source as they
happen as in the case of your 1KHz increment program.  But I think it
is even more important that it work outside of any editor!

Just edit a screen then leave the editor and on the command line
invoke a word to increment a variable in the source code until a key
is pressed.  One may see that a variable that was displayed on the
screen previously is now being continuously updated and refreshed
even without still being in the editor.

Of course you know all this stuff, but I was just trying to explain
to those not familar with colorforth how the magenta mechanism, which
operates on all variables, actually works.  

Well you did state that someone has to deliver the sort of thing
that I described above in some other language, AND convince you that
it really is the same thing.  

> I am offering a prize of a set of four colorForth floppies ( value �2-00 )
> to the first person to create an analogue of the colorForth magenta variable
> in any other computer language ( and convince me that it works ).

Well you did state that someone has to deliver the sort of thing
that I described above in some other language, AND convince you that
it really is the same thing (not apples vs oranges ;-).

> Magenta variables return the address of the following cell in the source
> block, which means that when their value is changed using "!" the source
> changes too.

Let's see, you did specify how one is able to use ! on variables in
live source as easily as in compiled code and see live continuous
real-time updates in your editor or on your desktop.  That sort of
thing would get rather complicated in typical desktop environments.

Is there a penalty for anyone who takes the challange but fails?
Dinner with Jeff Fox perhaps?

Best Wishes,
Jeff Fox

"John Passaniti" <nntp@JapanIsShinto.com> wrote in message news:<tXCkb.42280$Hs.23291@twister.nyroc.rr.com>...
> As for ColorForth's keyboard layout and character set-- who cares.  The way
> I view this is that ColorForth is a personal expression of what Charles
> Moore wants in a programming environment. 

You are certainly free to view things as you choose. However,

> It was created for himself and only himself.  

That is factually incorrect.  Chuck was working at iTV when the first
colorforth was written, other people were using his cad environment so
it was not created only for himself.  You might choose to adjust your
views based on the actual facts.

As you know ..., colorforth was originally a scripting environment in
OKAD hosted by OK.  Chuck did a major rewrite to host OKAD II in colorforth
instead, and factored colorforth as a stand-alone OS and development
environment separate from the CAD environment to do things rightside-up
and to make colorforth a separate public domian package for other people
to use.  Then Chuck went to the trouble to put it up on a website, write a
troubleshooting and installation guide package and user manual complete
with an invitation to other people to contribute and to use it.  All
of this is incontrovertible evidence that colorforth was not created
for Chuck and only for Chuck.

In fact that comment is so ridiculous that I mentioned that I had read
that statement in this newsgroup to Chuck over dinner a couple of months
ago.  We both got a good laugh about how someone actually made this
statement in public. 

> If others happen to like it, that's fine, but there was
> apparently zero time put into making ColorForth be anything more than a
> system to appeal to Mr. Moore's arbitrary choices and sense of software
> aesthetics.

It, colorforth, evolved in a rather complicated way from machineforth
and the requirements of a complex application domain, very large scale
integration computer aided design.  After writing his own cad packages
and fine tuning them for years he had clearly researched the user
interface design for his application, but then he came upon the problem
of adding a Forth development interface below, rather than on-top-of
the cad package.  Lots of standards, other software, and other people
were involved and lots of planning and very well considered choices.

Mr. Moore had written cmForth, 3/4, OK, OKAD, machineForth, and lots
of tools along the way for fifteen years when he applied his expertise
of thirty years of Forth into a very heavily considered new take on
the internal design and user interface for Forth in colorforth.  It
was sort of the opposite of what most people mean by arbitrary choices.

> I'm sure that lots of people will find Mr. Moore's odd keyboard layout and
> his crippled English-centric character set to not work for them.

Of course.  And some people have found that bizare intentionally
crippled qwerty-keyboard layout, crippled GUI, and crippled ASCII 
character sets are not optimal for what they want to do.

Best Wishes,
Jeff Fox

I decided to turn off my killfile on Jeff Fox for this thread because I
thought he might have something useful to say.  I should have known better.
Regardless, I did want to address something:

Howerd Oakford presented a challenge to implement an "analogue of the
colorForth magenta variable" in some language other than ColorForth.  I did
exactly that in Perl, although Howerd has yet to comment on it.  The
requirement of creating an "analogue" suggests one should know what
"analogue" means.  Here's the relevant dictionary definitions that I used:

analogue -- Something that bears an analogy to something else.
analogy -- Similarity in some respects between things that are otherwise
dissimilar.

An analogue then does not mean something is the *same* as something else.
It means it is *similar*.  And for my implementation of magenta variables,
the point of similarity is that when a change is made to a variable, I
wanted the source code to also change.  That seemed to me to be the most
essential thing about a magenta variable that one would try to implement in
another language.  Howerd wrote in his challenge:

> Magenta variables return the address of the following cell in
> the source block, which means that when their value is
> changed using "!" the source changes too.

If Howerd requires the first part (that  the variable return the address of
the following cell in a source block) then his challenge is pointless.
Meeting this part of the challenge would require ColorForth or at least
something that stored source code *exactly* like ColorForth.  By definition
then, nobody could implement an analogue in other languages since there
are-- as far as I am aware-- no other languages that store source code in
exactly the same way as ColorForth.

Seeing as how Howerd probably wouldn't offer a senseless challenge, it is
the second part that I addressed-- that a change to the variable modifies
the source.  As I showed in my initial message in this thread, the source
code is being changed.

Jeff Fox's message details some details about ColorForth and magenta
variables that were not part of Howerd's challenge.  But I'll address one
anyway-- because it's fun:

> Also to do what colorforth is doing there needs to be a
> mechanism to update the display in real-time to show
> changes to the source as they happen as in the case of
> your 1KHz increment program.  But I think it is even
> more important that it work outside of any editor!

This behavior is not part of magenta variables proper, but is rather an
artifact of the ColorForth display system, which weirdly seems to waste time
updating the display even when there is no change to the underlying
variables.  I guess this is simpler in the sense that no display update
notification mechanism is needed, but I personally would rather use those
processor and bus cycles for something more interesting than repetitively
updating a display that hasn't changed.

Regardless, my implementation of magenta variables in Perl does actually
match this behavior-- just at a slower rate.  The text editor that I use
periodically looks at the modification time on files, and if the file
changes, it can be set to automatically reload the file.  I amused myself
with this "feature" by writing a simple loop using my magenta variable
analogue and watching it change in the editor.  Others can play with this
bizarre and seemingly useless behavior themselves.

Jeff Fox also wrote:

> Well you did state that someone has to deliver the sort of
> thing that I described above in some other language, AND
> convince you that it really is the same thing.

No, that wasn't Howerd's challenge.  The challenge was not that it was
"really the same thing" becuase if it was, the challenge would be
pointless-- it would require a system that stored source exactly like
ColorForth.  No, Howerd's challenge stated that contestants had to convince
him that it *worked*.  Well, I think I did that, but again, we'll wait for
Howerd's comments.

> Is there a penalty for anyone who takes the challange but fails?
> Dinner with Jeff Fox perhaps?

I'd actually love to have dinner with you sometime.  In these newsgroups,
you have the ability to contort my words in all sorts of bizarre and
unintended ways.  You wouldn't be able to do that in person, since I would
be able to correct you before you had a chance to offer your distortions.

Well, it looks like Jeff Fox is going back into the killfile.  I get so
tired of Jeff twisting my words and injecting unintended meanings.  I think
others simply put up with this nonsense because of Jeff's proximity to
Charles Moore.  People are so interested to learn what Mr. Moore is doing
that they'll put up with Jeff's behavior.  One wonders if the same would be
true if Mr. Moore directly participated in this newsgroup, or if there was
some other oracle we could turn to.  I think this is why-- in part-- people
enjoy reading messages from Elizabeth Rather.  She gives us all valuable
insight into Charles Moore (at least insight gained during the time they
worked together) without all the baggage that comes along with Jeff.

Regardless, before I put Jeff back into the killfile, I needed to address
one distortion.  I wrote that Mr. Moore created ColorForth for himself and
only himself.  Given the context of what I wrote, I would assume most people
would understand what that statement meant.  Unfortunately most people
doesn't include Jeff Fox, who has an annoyingly literal view of what people
write.

My statement is that Mr. Moore created ColorForth around his needs, his
interests, and his views on software design.  I actually find that to be a
laudable thing, because in doing so, Mr. Moore has shown us all that we can
create our own personalized programming environments that are highly focused
on our own needs and the needs of our applications.

Jeff counters this statement by saying that other people *used* ColorForth
at iTV.  That statement is interesting, but doesn't invalidate what I wrote.
Just because someone else *used* ColorForth doesn't mean that Mr. Moore
*designed* it for them.  That is the difference I'm talking about-- that
instead of designing ColorForth around the perceived needs of others, Mr.
Moore designed ColorForth for *his* needs.  It's great that others *use*
ColorForth, but I have yet to see anything that suggests that Mr. Moore
*designed* it for anyone but himself.

Jeff also confuses Mr. Moore's generosity of making ColorForth available on
www.colorforth.com with my statement.  Here again, the fact that he made
ColorForth available to others doesn't mean Mr. Moore designed it for anyone
but himself.  Mr. Moore did indeed invite others to contribute to
ColorForth, but again, that says nothing about the nature of the design.
Mr. Moore set the standards for ColorForth, and people conform to those
standards.  I don't see where Mr. Moore has entered into a dialog with the
users of ColorForth to design it around the needs of the community.

Jeff can easily disprove my statement by pointing to any element of
ColorForth that Mr. Moore specifically added to the design that is the
result of Mr. Moore thinking about the needs of others using ColorForth.
That is, I would like to know what element of ColorForth is a compromise
that Mr. Moore made for others.  I don't think there is anything, but Jeff
is free to point out my error.

Finally, Jeff added to my statement, below:

> > I'm sure that lots of people will find Mr. Moore's odd keyboard
> > layout and his crippled English-centric character set to not work
> > for them.
>
> Of course.  And some people have found that bizare intentionally
> crippled qwerty-keyboard layout, crippled GUI, and crippled
> ASCII character sets are not optimal for what they want to do.

Jeff here ignores the point that I made.  By pointing out that Mr. Moore
tuned ColorForth to English, I am saying that people who don't use English
natively are effectively locked out of ColorForth.  Mr. Moore apparently
doesn't see this as a problem because (as I have stated) ColorForth is *his*
programming environment, and if others like it, that's fine, but it wasn't
designed for them.  It was designed for him.  The choice of character set is
perhaps the most vivid example of this fact.

Jeff somehow contorts this simple and obvious statement into something he
feels the need to defend against.  Probably because he thinks I am somehow
besmirching Mr. Moore's work.  On the contrary, I find ColorForth a
revolutionary and quite respectable idea-- that one can create a programming
environment tuned for just the individual and the application.

Congratulations to John Passaniti for providing an implementation of the
colorForth magenta variable in Perl!

I have been away at the EuroForth 2003 conference, so I haven't had time to
run the code yet, but the technique seems to be valid. John says that as his
laptop does not have a floppy drive, that he would prefer his prize to be a
chai latte, which I will happily deliver next time I find myself in
Rochester... ;)

At the colorForth workshops at EuroForth we discussed several changes, such
as increasing the token size, and using a "name table" ( a table of strings
that the tokens point to ) to reference names instead of Huffman encoding
them. Both these ideas have their own problems, and I am left with the
conclusion that Chuck's 32 bit Huffman encoded tokens are very solid - that
is it is difficult to improve them without a complete re-think. On the other
hand, the "name table" technique gives you automatic name aliases and
alternative languages, and remove the need for Huffman encoding....

ColorForth is Work In Progress, it is experimental and is changing all the
time.
My paper at EuroForth was "The colorForth Magenta Variable" (
www.inventio.co.uk/EuroForth03.htm ), and describes this fascinating
property.
For a more general introduction to colorForth please see
www.inventio.co.uk/colorForth%20and%20the%20Art%20of%20the%20Impossible.htm,
or, of course , www.colorforth.com .
For the real thing, download cfdos.com ( www.inventio.co.uk/cfdos.htm ),
create a bootable floppy and run colorForth. The type  <space> int <space>
vv  and watch a magenta variable in action...

I will post a use for the magenta variable as soon as I find one!

Enjoy!

Howerd

"Howerd Oakford" <howerd.oakford@ntlworld.com> wrote in message
news:EeMlb.70$dn.622026@newsfep2-gui.server.ntli.net...
> Congratulations to John Passaniti for providing an implementation
> of the colorForth magenta variable in Perl!

Wheee!

> At the colorForth workshops at EuroForth we discussed several
> changes, such as increasing the token size, and using a "name table"
> ( a table of strings that the tokens point to ) to reference names
> instead of Huffman encoding them. Both these ideas have their own
> problems, and I am left with the conclusion that Chuck's 32 bit
> Huffman encoded tokens are very solid - that is it is difficult to
> improve them without a complete re-think. On the other hand,
> the "name table" technique gives you automatic name aliases and
> alternative languages, and remove the need for Huffman encoding....

The "name table" you describe sounds like my suggestion to use "interned
strings."  Probably two different names for the same thing.  I am interested
in the details behind the details about why it was concluded that Chuck's
Huffman-encoded token are "very solid."  To me, it simply looked like one
possible way to hash a string value into a single 32-bit value-- and there
are many different ways to do that.  What specifically about
Huffman-encoding made more sense than any other hashing algorithm that
provided unique keys?

----- Original Message -----
From: "John Passaniti" <nntp@JapanIsShinto.com>
Newsgroups: comp.lang.forth
To: <comp.lang.forth@ada-france.org>
Sent: Thursday, October 23, 2003 11:35
Subject: Re: ANN cfdos - EuroForth 2003 edition


> If Howerd requires the first part (that  the variable return the address
of
> the following cell in a source block) then his challenge is pointless.

I agree with you.

There is a challenge, and I can not participate. You did come forward, and I
feel I am represented, either you lose or you win. That is why I support
you.

Regards,
Petrus - Pet4th.

----- Original Message -----
From: "John Passaniti" <nntp@JapanIsShinto.com>
Newsgroups: comp.lang.forth
To: <comp.lang.forth@ada-france.org>
Sent: Thursday, October 23, 2003 12:16
Subject: Re: ANN cfdos - EuroForth 2003 edition


> Well, it looks like Jeff Fox is going back into the killfile.

Please don't. The discussion is interesting. If I may set the threshold,
into killfile or not, I will set it to "find the words: 10x 100x 1000x". If
the words appear, no further argument will change anything.

Regards,
Petrus-Pet4th.

----- Original Message ----- 
From: "John Passaniti" <nntp@JapanIsShinto.com>
Newsgroups: comp.lang.forth
To: <comp.lang.forth@ada-france.org>
Sent: Thursday, October 23, 2003 15:56
Subject: Re: ANN cfdos - competition winner!


> 
> "Howerd Oakford" <howerd.oakford@ntlworld.com> wrote in message
> news:EeMlb.70$dn.622026@newsfep2-gui.server.ntli.net...
> > Congratulations to John Passaniti for providing an implementation
> > of the colorForth magenta variable in Perl!
> 
> Wheee!

Horeee. John wins.

Regards,
Petrus - Pet4th.

"John Passaniti" <nntp@JapanIsShinto.com> wrote in message news:<yuJlb.46552$Sc7.34033@twister.nyroc.rr.com>...
> Jeff can easily disprove my statement by pointing to any element of
> ColorForth that Mr. Moore specifically added to the design that is the
> result of Mr. Moore thinking about the needs of others using ColorForth.

I repeat, Chuck got a good laugh when he heard that someone had written
that the created colorforth for himself and his use only.

> That is, I would like to know what element of ColorForth is a compromise
> that Mr. Moore made for others.  I don't think there is anything, but Jeff
> is free to point out my error.

I have done it so many times in the past that there should be no need
for anyone who has paid attention in the past.  DUP DROP OVER are good
examples of consessions made for others.

Best Wishes,
Jeff Fox

John Passaniti wrote:

[...]
> Regardless, before I put Jeff back into the killfile, I needed to address
> one distortion.  I wrote that Mr. Moore created ColorForth for himself and
> only himself.  Given the context of what I wrote, I would assume most people
> would understand what that statement meant.  Unfortunately most people
> doesn't include Jeff Fox, who has an annoyingly literal view of what people
> write.
>
[...]

It's obvious that You and Mr. Fox nearly always end up antogonising each 
other.  It is not clear to me why, but you may have to place me in the 
"not most people" category for this particular conversation.

You said:

"As for ColorForth's keyboard layout and character set-- who cares.  The 
way I view this is that ColorForth is a personal expression of what 
Charles Moore wants in a programming environment.  It was created for 
himself and only himself.  If others happen to like it, that's fine, but 
there was apparently zero time put into making ColorForth be anything 
more than a system to appeal to Mr. Moore's arbitrary choices and sense 
of software aesthetics."

Mr. Fox countered this in a fair and reasonable way.  He suggested that 
the project in question was grown (in the usual iterative Forth process) 
over time while (as you say) being used by others.

I took that to mean that ColorForth was not created in a vacuum, only 
for himself, but was created with a good amount of input from 
professionals and perhaps other coders.

Sorry, but this seemed pretty clear to me.  Whatever bone to pick with 
Mr. Fox you may have about this particularr thread is just not in this 
statement.

> My statement is that Mr. Moore created ColorForth around his needs, his
> interests, and his views on software design.  I actually find that to be a
> laudable thing, because in doing so, Mr. Moore has shown us all that we can
> create our own personalized programming environments that are highly focused
> on our own needs and the needs of our applications.
> 
> Jeff counters this statement by saying that other people *used* ColorForth
> at iTV.  That statement is interesting, but doesn't invalidate what I wrote.
> Just because someone else *used* ColorForth doesn't mean that Mr. Moore
> *designed* it for them.  That is the difference I'm talking about-- that
> instead of designing ColorForth around the perceived needs of others, Mr.
> Moore designed ColorForth for *his* needs.  It's great that others *use*
> ColorForth, but I have yet to see anything that suggests that Mr. Moore
> *designed* it for anyone but himself.
>
But this is just your opinion, isn't it?  Where is _your_ proof that 
Moore designed ColorForth for no one "but himself".  Mr. Fox suggested 
that Moore was working _with_ these people, and that the way they worked 
with the toolset was considered during development.  Note that, to me, 
your comments were a bit of a back-handed compliment to Moore.  Whether 
this was intended or not is not the point.

> Jeff also confuses Mr. Moore's generosity of making ColorForth available on
> www.colorforth.com with my statement.  Here again, the fact that he made
> ColorForth available to others doesn't mean Mr. Moore designed it for anyone
> but himself.  Mr. Moore did indeed invite others to contribute to
> ColorForth, but again, that says nothing about the nature of the design.
> Mr. Moore set the standards for ColorForth, and people conform to those
> standards.  I don't see where Mr. Moore has entered into a dialog with the
> users of ColorForth to design it around the needs of the community.
>
Mr. Fox simply added this as icing; that some effort was made to make 
the project available to a wider audience.  That may Moore have had 
other people (coders and designers) in mind during the design, or at 
least implementation.

A lot of this is moot, as we do not necessarily (in this forum) know 
what was in the mind of Moore during the creation and maintenance of 
ColorForth.  I've met Moore exactly once.  He *seemed* like a person who 
might consider others' needs during the design and creation of a 
toolset.  How will any of us know unless we've worked with him?

Is the point that ColorForth a more idiosyncratic project that some?

Perhaps.

I guess Moore chooses projects that allow him the freedom to try 
different things.  In my experience, all development is done to the muse 
of the coder (more or less, and yes, I work for a real software company 
-- but I have my own style).  Perhaps ColorForth is an extreme example 
of the "more", but I'm not sure the contention that Moore designed it 
*only* for himself, with absolutely no input or consideration from 
anyone else seems an extreme an unreasonable point of view.

This is especially in the light of the comments made by Mr. Fox.

"Howerd Oakford" <howerd.oakford@ntlworld.com> wrote in message news:<EeMlb.70$dn.622026@newsfep2-gui.server.ntli.net>...
> I will post a use for the magenta variable as soon as I find one!

Integrated spreadsheet functionality is the most obvious use.  They
are also useful for eliminating the kind of variable initialization
errors that are described as one of the common errors in Forth in
this newsgroup.

Best Wishes,
Jeff Fox

Hi John,

"John Passaniti" <nntp@JapanIsShinto.com> wrote in message
news:bJMlb.66333$Hs.16589@twister.nyroc.rr.com...
>
> "Howerd Oakford" <howerd.oakford@ntlworld.com> wrote in message
> news:EeMlb.70$dn.622026@newsfep2-gui.server.ntli.net...
> > Congratulations to John Passaniti for providing an implementation
> > of the colorForth magenta variable in Perl!
>
> Wheee!
The chai latte is on me!

> > At the colorForth workshops at EuroForth we discussed several
> > changes, such as increasing the token size, and using a "name table"
> > ( a table of strings that the tokens point to ) to reference names
> > instead of Huffman encoding them. Both these ideas have their own
> > problems, and I am left with the conclusion that Chuck's 32 bit
> > Huffman encoded tokens are very solid - that is it is difficult to
> > improve them without a complete re-think. On the other hand,
> > the "name table" technique gives you automatic name aliases and
> > alternative languages, and remove the need for Huffman encoding....
>
> The "name table" you describe sounds like my suggestion to use "interned
> strings."  Probably two different names for the same thing.  I am
interested
> in the details behind the details about why it was concluded that Chuck's
> Huffman-encoded token are "very solid."  To me, it simply looked like one
> possible way to hash a string value into a single 32-bit value-- and there
> are many different ways to do that.  What specifically about
> Huffman-encoding made more sense than any other hashing algorithm that
> provided unique keys?
I think I may have rejected "interned strings", which are probably the same
as a "name table" approach, on the grounds that you lose the encapsulation
of the source entirely within the source block. You must then wrap all
access to the source block in reference/de-reference operators. My current
view, post EuroForth, is that this may be a better scheme, but has its own
set of problems. For example, a 1K byte source block may take up 10K byte of
space when saved to disk. Does this need a filing system? Or late
de-referencing of names, with separate storage for the name table?

It is the compressing of the name string into the token which gives this
total encapsulation - Huffman encoding is the current scheme and seems
adequate, although another algorithm may well be better. Chuck has used a
particular 4,6,7 bit Huffman compression on a 48 character set to get 4 to 7
characters into 28 bits. If you change the number of characters, or the
available space in the token, the best algorithm will probably change too.
The 48 characters can be covered by two keypad screens of 24 characters, the
24 being three rows of four fingers on two hands.
Short of growing extra fingers or adding a third keypad ( which would make
all three much clunkier to select ), what Chuck has done seems about right.

The "name table" scheme works like this :
A table with a fixed number ( say 65536 ) of elements is statically
allocated, each element has a counted string, usage count and possibly a
"locate" field giving the block that it was edited in. Every time a new
string is entered in the editor a new element is assigned by searching for a
0 usage count, the count is incremented and the token set to point to it.
Each 32 bit token can now have 16 bits of "colour" and 16 bits ponting to
its name string. When the token is displayed its name is fetched from the
table. When a token is deleted, its name's usage count is decremented. When
the block is saved to disk, the de-referenced name is saved, and when a
block is loaded the names are moved to the name table. Some additional
complexity, much much more flexibility with features such as aliases and
alternative ( human ) languages coming for free. Also no need for
compression, since we are already using something like an LZ77 system of
pointers to strings.

This whole discussion started because I wanted at least one more bit in the
token's colour field, and preferably four more. The other approach is to
increase the token size from 32 to 64 bits. This makes all programs twice as
big and run at half the speed, so is maybe too inefficient... You could go
to 48 bits, but this must also be the return stack size, and so is probably
best for the parameter stack, so the whole thing gets a bit ugly. One day
this should be implemented in silicon....

Regards

Howerd











>
>

     I wish I could resist the temptation to join in debates
with people with strong opinions. But if a problem is not seen,
there is no hope for a solution.

Jeff Fox wrote:
 
> "John Passaniti" <nntp@JapanIsShinto.com> wrote in message
> news:<tXCkb.42280$Hs.23291@twister.nyroc.rr.com>...
> > As for ColorForth's keyboard layout and character set-- who cares.
> >  The way I view this is that ColorForth is a personal expression of
> > what Charles Moore wants in a programming environment.
> 
> You are certainly free to view things as you choose. However,
> 
> > It was created for himself and only himself.
> 
> That is factually incorrect.  Chuck was working at iTV when the first
> colorforth was written, other people were using his cad environment
> so it was not created only for himself.  You might choose to adjust
> your views based on the actual facts.
> 
> As you know ..., colorforth was originally a scripting environment in
> OKAD hosted by OK.  Chuck did a major rewrite to host OKAD II in
> colorforth instead, and factored colorforth as a stand-alone OS and
> development environment separate from the CAD environment to do
> things rightside-up and to make colorforth a separate public domian
> package for other people to use.  Then Chuck went to the trouble to
> put it up on a website, write a troubleshooting and installation guide
> package and user manual complete with an invitation to other people
> to contribute and to use it.  All of this is incontrovertible evidence
> that colorforth was not created for Chuck and only for Chuck.
> 
> In fact that comment is so ridiculous that I mentioned that I had
> read that statement in this newsgroup to Chuck over dinner a couple
> of months ago.  We both got a good laugh about how someone actually
> made this statement in public.

     I agree with both sides of this argument. Chuck Moore wrote
Colorforth to be used by other people. But it still looks like
it was created for himself and only himself. 

> > If others happen to like it, that's fine, but there was
> > apparently zero time put into making ColorForth be anything more
> > than a system to appeal to Mr. Moore's arbitrary choices and sense
> > of software aesthetics.
> 
> It, colorforth, evolved in a rather complicated way from machineforth
> and the requirements of a complex application domain, very large scale
> integration computer aided design.  After writing his own cad packages
> and fine tuning them for years he had clearly researched the user
> interface design for his application, but then he came upon the problem
> of adding a Forth development interface below, rather than on-top-of
> the cad package.  Lots of standards, other software, and other people
> were involved and lots of planning and very well considered choices.
> 
> Mr. Moore had written cmForth, 3/4, OK, OKAD, machineForth, and lots
> of tools along the way for fifteen years when he applied his expertise
> of thirty years of Forth into a very heavily considered new take on
> the internal design and user interface for Forth in colorforth.  It
> was sort of the opposite of what most people mean by arbitrary
> choices.

      Chuck Moore's work of the last fifteen years or thirty
years is not what I'd call accessible. I was once criticized for
not knowing enough about Chuck Moore's writing because I never
worked with him and could not look over his shoulder from where
I live 3,000 miles away. This actually proved the point I was
trying to make, but nobody noticed.  My critic could not direct
me to anything that would compensate for my lack of being able
to work directly with Chuck Moore. I'd like to be able to show
Forth with Chuck Moore's new ideas to people who think Forth is
only of historic interest. Yet the best sample I have of Chuck's
writing is an article on the history of Forth.

      Radical new ideas need the best possible presentation.
Colorforth is presented badly. I don't even have a computer that
it will run on. It needs a strange combination of things such as
a recent model of video card and an old floppy disk drive. Do
recent computers still have floppy disk drives?

       When Colorforth was first published, I had the feeling
only five or ten people in the whole world could do anything
with it. After a few years development, I've seen an improvement
-- now there might be twenty or thirty people who use it. When I
look for information about Colorforth from a web page, such as 
http://kristopherjohnson.net/cgi-bin/twiki/view/Main/ColorForth or
http://www.users.qwest.net/~loveall/c4index.htm , I find links
to essential information that I can't find from what I see on
the Colorforth web page http://www.colorforth.com/ even tho this
information is located on colorforth.com. 

       If Colorforth is intended to be used by more than a few
dozen people, then the really difficult job of documenting its
radical new methods needs a lot more work. If the simple job of
indexing web pages is neglected, doesn't that tell us something?
     
> > I'm sure that lots of people will find Mr. Moore's odd keyboard
> > layout and his crippled English-centric character set to not work
> > for them.
> 
> Of course.  And some people have found that bizare intentionally
> crippled qwerty-keyboard layout, crippled GUI, and crippled ASCII
> character sets are not optimal for what they want to do.

      One of the hundreds of projects I'd like to do is an
English text to speech system that is simplified by using a
keyboard optimized for the Shavian alphabet (Unicode range 10450
to 1047F). But I know that whatever improvements that I could
make to text to speech software would be completely ignored if I
published the code and documentation with the Shavian alphabet.
Colorforth has all sorts of good ideas Chuck has invented over
the past fifteen years, and it needs as much work by a genius to
create the necessary instructional material as it took to
invent, develop and simplify the code. That would be easier to
do if his new ideas were presented as separate topics instead of
all mixed together.

--
Michael Coughlin   m-coughlin@comcast.net   Cambridge, MA USA

Hi Michael,

"m-coughlin" <m-coughlin@comcast.net> wrote in message
news:3FAA6A95.319D5BFE@comcast.net...

>  I wish I could resist the temptation to join in debates
> with people with strong opinions.
Me too!

[snip]

> Chuck Moore wrote Colorforth to be used by other people.
> But it still looks like it was created for himself and only himself.
Yes, it does look like that, but in fact it isn't.

Finding a suitable PC :

ColorForth is not trying to compete with Windows - that's Linux's job.
If you are going to run any program directly on the hardware of your PC you
immediately lose the cottonwool wrapping that you get with an OS, so it may
not work on _your_ PC.
This means that you have to find a PC that colorForth will run on, or change
colorForth to suit.

"Writing for other people" seems to mean making it easy to run the program
on any PC - a problem which has been largely solved by Microsoft, at the
expense of just about everything else.
I can live with the performance issues, as hardware is so powerful these
days, but I cannot accept the limited possibilites of that environment.

ColorForth gives you back your PC. The price you pay is that you must find
out how your PC works.

So, once you have got past the fact that you will not find colorForth
shrink-wrapped at PC World ( yet ), and made what ever effort it requires to
get colorForth running on a PC - any PC - you can program your PC directly.

When you do this, without an OS, without files and without ASCII, you can
start to explore the computer as it is, not as seen through the eyes of the
Microsoft marketing department.

Documentation :

ColorForth documentaton is not finished. Chuck has described the key points
on his website, and others have added their own comments on many other
websites. Yes we need more documentation. Its on my to-do list...

Design decisions :

I have tried to improve colorForth, but so far with little success. Chuck
has found a combination of keypad, encoding, compiling etc that works as a
coherent whole. This is an enormously valuable asset to the world of
computer science. I find the idea that Chuck designed colorForth "just for
himself" amazing in its inaccuracy.

> Colorforth has all sorts of good ideas Chuck has invented over
> the past fifteen years, and it needs as much work by a genius to
> create the necessary instructional material as it took to
> invent, develop and simplify the code.
No, it just takes time, by lesser mortals. And not fifteen years, maybe
fifteen days...

> That would be easier to
> do if his new ideas were presented as separate topics instead of
> all mixed together.
Yes, it would be easier, but that is the problem with a synergetic system.
Many of the new ideas in colorForth have very little to commend them in any
other environment.

>  Chuck Moore's work of the last fifteen years or thirty
> years is not what I'd call accessible.
Its all in colorForth, which admitedly is not that accessible, but it is
downloadable.

[snip]

> Radical new ideas need the best possible presentation.
Absolutely.

> Colorforth is presented badly.
We are trying our best ;)

> I don't even have a computer that
> it will run on. It needs a strange combination of things such as
> a recent model of video card and an old floppy disk drive. Do
> recent computers still have floppy disk drives?
Some do, for those that don't I hear rumours that a port to a USB drive is
happening.
Please try the latest version from www.inventio.co.uk/cfdos - it runs on
almost all laptops with a floppy, and most PCs ( with PCI/AGP graphics ). It
can be made to run on any PC.

> When Colorforth was first published, I had the feeling
> only five or ten people in the whole world could do anything
> with it. After a few years development, I've seen an improvement
> -- now there might be twenty or thirty people who use it.
Its quality, not quantity that counts.
ColorForth is not for everybody, just the curious and persistent who want to
understand about computers.

> When I
> look for information about Colorforth from a web page, such as
> http://kristopherjohnson.net/cgi-bin/twiki/view/Main/ColorForth or
> http://www.users.qwest.net/~loveall/c4index.htm , I find links
> to essential information that I can't find from what I see on
> the Colorforth web page http://www.colorforth.com/ even tho this
> information is located on colorforth.com.
> If Colorforth is intended to be used by more than a few
> dozen people, then the really difficult job of documenting its
> radical new methods needs a lot more work. If the simple job of
> indexing web pages is neglected, doesn't that tell us something?
Yes, that colorForth is being supported by "amateurs" - people who do it for
the love of their chosen subject.
Give us time!

> One of the hundreds of projects I'd like to do is an
> English text to speech system that is simplified by using a
> keyboard optimized for the Shavian alphabet (Unicode range 10450
> to 1047F). But I know that whatever improvements that I could
> make to text to speech software would be completely ignored if I
> published the code and documentation with the Shavian alphabet.
Except by people who like the Shavian alphabet...
This is about marketing, not programming.
Sounds like a fascinating project!

Regards

Howerd

"Howerd Oakford" <howerd.oakford@ntlworld.com> wrote in message
news:Hr4rb.353$rW3.276440@newsfep1-win.server.ntli.net...
> "Writing for other people" seems to mean making it easy to
> run the program on any PC - [...]

If you are indirectly referencing my comment that Charles Moore wrote
ColorForth only for himself, that's not what I meant.  I don't have a
problem with ColorForth running only on certain hardware-- presumably the
exact hardware Charles Moore has.  People who are interested in ColorForth
on other platforms have and will continue to offer ports.

ColorForth was written according to Charles Moore's sense of what he finds
necessary in a programming environment.  He didn't add any fluff to
ColorForth to make it palatable for others.  And indeed, I would imagine
that as more people use ColorForth, Charles will resist incorporating any
new features they create unless those features are consistent with his
philosophy.

At least, I would certainly hope that is the case.  The primary value of
ColorForth to me isn't that this is the programming environment that Charles
Moore uses.  Yeah, it's interesting to see how he works, and there are lots
of good ideas in ColorForth.  But I don't do the same kind of work Charles
does, so why would I want a programming environment that is tuned to his
needs?  No, the primary value of ColorForth is the underlying message that
programmers can create their own programming environment that directly
addresses their individual needs.

That is what my comment about ColorForth being designed and written only for
Charles Moore is about.  Jeff Fox didn't get it (confusing the issue of
ColorForth's *availability* with the issue of who ColorForth was *designed*
for), but that's par for the course.

> Design decisions :
>
> I have tried to improve colorForth, but so far with little success. Chuck
> has found a combination of keypad, encoding, compiling etc that works
> as a coherent whole. This is an enormously valuable asset to the world of
> computer science. I find the idea that Chuck designed colorForth "just for
> himself" amazing in its inaccuracy.

That is because you don't understand the context of my statement.

Charles' design is centered around his needs-- and that is the strength of
ColorForth.  His primary language is English, so the character set,
character encoding come directly from that.  I would imagine that Charles
would tell users with a primary language other than English that they should
choose a character set that suits them, and that they consider other
character encoding strategies if necessary.  For example, the character
encoding Charles uses depends on some characters having a higher frequency
than others in identifiers.  English has this property, but languages where
that assumption doesn't hold true would need some other encoding scheme.
Additionally, the scheme Charles uses assumes that identifiers will be
unique within the first few characters.  Again, English (usually) has this
property, but I don't believe all languages do.

My point here isn't that Charles designed ColorForth to be hostile to other
languages.  Rather, it is that ColorForth's design is centered around
Charles' needs.  And when you view it in that context, yes, ColorForth works
as a coherent whole.  Start to change some of the assumptions Charles has
made (such as a dependency on English) and his particular implementation may
not make as much sense.  And in that case, it merely means that someone with
different needs than Charles needs to consider how to take ColorForth and
make it fit their needs.  That to me is the primary strength of ColorForth
as an approach to programming.

The only problem I see with ColorForth isn't technical but social.
Following the underlying philosophy of ColorForth to its logical end means
that every programmer who uses it has a very personal environment that meets
their needs.  That is going to make it difficult to share code.  Certainly
if I choose to tune ColorForth to a non-English alphabet or choose a
different character encoding, then I can't (directly) share code.
ColorForth has a society behind it when people choose to be bound by a
particular implementation of ColorForth.  As others continue to embrace the
philosophy behind ColorForth, I see the community splintering into factions
that can't share code.  Normally, I would say this is a bad thing for other
languages (like Forth) and that standardization should be a goal.  In
ColorForth, this is a strength and not a weakness.

Hi John,

"John Passaniti" <nntp@JapanIsShinto.com> wrote in message
news:xJQrb.14065$5b1.10084@news02.roc.ny...
>
> "Howerd Oakford" <howerd.oakford@ntlworld.com> wrote in message
> news:Hr4rb.353$rW3.276440@newsfep1-win.server.ntli.net...
> > "Writing for other people" seems to mean making it easy to
> > run the program on any PC - [...]
> If you are indirectly referencing my comment that Charles Moore wrote
> ColorForth only for himself, that's not what I meant.
Not intentionally. I think I picked up on this as a general complaint about
colorForth.

> I don't have a
> problem with ColorForth running only on certain hardware-- presumably the
> exact hardware Charles Moore has.  People who are interested in ColorForth
> on other platforms have and will continue to offer ports.
The fact that someone may offer a port to your exact PC is useful, but does
not hide the fact that colorForth is not run on the operating system that
your
PC already has.
I am glad that you don't have a problem with this, but I think other people
do ;)

> ColorForth was written according to Charles Moore's sense of what he finds
> necessary in a programming environment.
True, but this implies that what Chuck finds necessary will probably not be
of use to anyone else, which is not true.

> He didn't add any fluff to
> ColorForth to make it palatable for others.
Lack of "fluff" implies good, not "palatable to others" implies bad.
I am not clear whether you are for or against "fluff".
ColorForth is a minimalist system, some people like it, others do not.

> And indeed, I would imagine
> that as more people use ColorForth, Charles will resist incorporating any
> new features they create unless those features are consistent with his
> philosophy.
Chuck has no control over what I or anyone else adds to their version of
colorForth.
That's what public domain means.
I am intrigued by the use of the word "incorporating"  - it implies one
standard version of colorForth into which everything must be added, and to
which everybody must refer.
This is not the Forth philosophy as I understand it.
All that is necessary is an extensible system, what happens next is up to
you.

> At least, I would certainly hope that is the case.  The primary value of
> ColorForth to me isn't that this is the programming environment that
> Charles Moore uses.  Yeah, it's interesting to see how he works, and there
> are lots of good ideas in ColorForth.  But I don't do the same kind of
work Charles
> does, so why would I want a programming environment that is tuned to his
> needs?
Absolutely, but this implies that colorForth is "tuned to his needs".
Like every other Forth, colorForth is extensible, and should be tuned to
your own needs.
It could be that your needs include things like ASCII, files, platform
independence etc, in which case colorForth is probably too far from the
mainstream to be useful to you.  But it is most definitely not tuned solely
to Chuck's needs.
It is at the very least tuned to my needs as well.

> No, the primary value of ColorForth is the underlying message that
> programmers can create their own programming environment that directly
> addresses their individual needs.
That is the primary value of Forth. The primary value of colorForth is that
is challenges some very deeply held mainstream beliefs about what is
possible and what is not possible when programming a computer.

> That is what my comment about ColorForth being designed and written only
> for Charles Moore is about.
I think this sentence and your last one are inconsistent.
How can a program so uniquely tuned to Chuck's requirements allow you to
create your own environment?
Surely to teach the value of creating your own environment it must allow you
do to just that?
In which case it is totally generic.

[snip]

> > Design decisions :
> >
> > I have tried to improve colorForth, but so far with little success.
>> Chuck has found a combination of keypad, encoding, compiling etc
>> that works as a coherent whole.
>> This is an enormously valuable asset to the world of
> > computer science. I find the idea that Chuck designed colorForth
>> "just for himself" amazing in its inaccuracy.
> That is because you don't understand the context of my statement.
Clearly.

> Charles' design is centered around his needs-- and that is the strength of
> ColorForth.
This implies that other people's needs are precluded.
In fact, like any other Forth, colorForth is extensible. See the preceeding
few paragraphs....

> His primary language is English, so the character set,
> character encoding come directly from that.  I would imagine that Charles
> would tell users with a primary language other than English that they
> should
> choose a character set that suits them, and that they consider other
> character encoding strategies if necessary.
There is an icon editor which can be used to change which character is
associated with which number.
It is not tightly bound to any particular character set, but if you change
this, you will have a "non-standard" colorForth.
_You_ choose where to draw the line between common and custom code.
For example, if you write in Russian, you could swap say "a" and "z", or
whatever suits.
It is not difficult to do this - the choice is yours.

> For example, the character
> encoding Charles uses depends on some characters having a higher frequency
> than others in identifiers.  English has this property, but languages
> where
> that assumption doesn't hold true would need some other encoding scheme.
I find it hard to imagine a language that uses all of its characters
equally. If there is such a language, Huffman would not be very useful...

> Additionally, the scheme Charles uses assumes that identifiers will be
> unique within the first few characters.  Again, English (usually) has this
> property, but I don't believe all languages do.
Yes, this could be a deficiency of the current implementation of
colorForth.
Only one cell is stored in the search table, so only the first four to seven
characters are stored.
If this is a problem for you, by all means make it two cells or more.
But one cell works just fine if you write programs that occupy only a few
blocks, and choose short names.
This ties in to the "just in time compilation" of tiny programs. Since the
scope is so limited, you do not need much namespace. Outside of this
block-based, elegant programming style, you would probably need to store
longer filenames. I have not found this to be a problem.

> My point here isn't that Charles designed ColorForth to be hostile to
> other
> languages.  Rather, it is that ColorForth's design is centered around
> Charles' needs.  And when you view it in that context, yes, ColorForth
> works
> as a coherent whole.  Start to change some of the assumptions Charles has
> made (such as a dependency on English) and his particular implementation
> may
> not make as much sense.  And in that case, it merely means that someone
> with
> different needs than Charles needs to consider how to take ColorForth and
> make it fit their needs.  That to me is the primary strength of ColorForth
> as an approach to programming.
>
> The only problem I see with ColorForth isn't technical but social.
> Following the underlying philosophy of ColorForth to its logical end means
> that every programmer who uses it has a very personal environment that
> meets
> their needs.  That is going to make it difficult to share code.
Not if you share the environment too. That is why the magenta variable is so
important.
If you arrange that blocks can be exchanged, you can decide which blocks to
exchange, from just the application, to the font, to the kernel. They are
all just blocks.

> Certainly
> if I choose to tune ColorForth to a non-English alphabet or choose a
> different character encoding, then I can't (directly) share code.
True.

> ColorForth has a society behind it when people choose to be bound by a
> particular implementation of ColorForth.  As others continue to embrace
> the
> philosophy behind ColorForth, I see the community splintering into
> factions that can't share code.
I have collected colorForth programs from various websites and collated them
into a DOS based distribution package.
We all used Chuck's public domain colorForth with changes made to run on our
individual PCs. Chuck's original kernel only worked on my laptop and one of
my PCs with an ISA floppy card, but the latest kernel from Terry Loveall and
others works on all of my PCs and laptop.
Obviously if someone writes code that accesses, for example, an Ethernet
card that my PC doesn't have, its not going to work until it is modified for
the hardware that I do have.
The illusion is that this is a difficult thing to do - I think this is part
of what Chuck calls the "user illusion".
In fact it is extremely difficult to do because it is so hard to get the
hardware information that you need - but its getting easier.
ColorForth faces the same problems as Linux - but hardware manufacturers are
now seeing that it is profitable to let people other than the Microsoft
device driver writers know about their hardware.
In fact there is a lot of commonality between PC hardware, judged by the
fact that colorForth runs on a wide range of hardware with some relatively
simple configuration at power up.

> Normally, I would say this is a bad thing for other
> languages (like Forth) and that standardization should be a goal.
I think we should try some other solutions before we give up and buy
Longhorn...

> In ColorForth, this is a strength and not a weakness.
Sorry, I have lost what "this" referes to.

I hope that I am not being too picky, or cryptic.
I think these discussions are worthwhile, but we are talking about, and in,
different languages.
There are some real problems that need to be addressed with colorForth, such
as code sharing.
Some of these problems have been addressed by mainstream programming
languages, with varying degrees of success.
ColorForth allows me to explore other solutions to these problems.

Regards

Howerd

Hi John,

"John Passaniti" <nntp@JapanIsShinto.com> wrote in message
news:xJQrb.14065$5b1.10084@news02.roc.ny...
>
> "Howerd Oakford" <howerd.oakford@ntlworld.com> wrote in message
> news:Hr4rb.353$rW3.276440@newsfep1-win.server.ntli.net...
> > "Writing for other people" seems to mean making it easy to
> > run the program on any PC - [...]
> If you are indirectly referencing my comment that Charles Moore wrote
> ColorForth only for himself, that's not what I meant.
Not intentionally. I think I picked up on this as a general complaint about
colorForth.

> I don't have a
> problem with ColorForth running only on certain hardware-- presumably the
> exact hardware Charles Moore has.  People who are interested in ColorForth
> on other platforms have and will continue to offer ports.
The fact that someone may offer a port to your exact PC is useful, but does
not hide the fact that colorForth is not run on the operating system that
your
PC already has.
I am glad that you don't have a problem with this, but I think other people
do ;)

> ColorForth was written according to Charles Moore's sense of what he finds
> necessary in a programming environment.
True, but this implies that what Chuck finds necessary will probably not be
of use to anyone else, which is not true.

> He didn't add any fluff to
> ColorForth to make it palatable for others.
Lack of "fluff" implies good, not "palatable to others" implies bad.
I am not clear whether you are for or against "fluff".
ColorForth is a minimalist system, some people like it, others do not.

> And indeed, I would imagine
> that as more people use ColorForth, Charles will resist incorporating any
> new features they create unless those features are consistent with his
> philosophy.
Chuck has no control over what I or anyone else adds to their version of
colorForth.
That's what public domain means.
I am intrigued by the use of the word "incorporating"  - it implies one
standard version of colorForth into which everything must be added, and to
which everybody must refer.
This is not the Forth philosophy as I understand it.
All that is necessary is an extensible system, what happens next is up to
you.

> At least, I would certainly hope that is the case.  The primary value of
> ColorForth to me isn't that this is the programming environment that
> Charles Moore uses.  Yeah, it's interesting to see how he works, and there
> are lots of good ideas in ColorForth.  But I don't do the same kind of
work Charles
> does, so why would I want a programming environment that is tuned to his
> needs?
Absolutely, but this implies that colorForth is "tuned to his needs".
Like every other Forth, colorForth is extensible, and should be tuned to
your own needs.
It could be that your needs include things like ASCII, files, platform
independence etc, in which case colorForth is probably too far from the
mainstream to be useful to you.  But it is most definitely not tuned solely
to Chuck's needs.
It is at the very least tuned to my needs as well.

> No, the primary value of ColorForth is the underlying message that
> programmers can create their own programming environment that directly
> addresses their individual needs.
That is the primary value of Forth. The primary value of colorForth is that
is challenges some very deeply held mainstream beliefs about what is
possible and what is not possible when programming a computer.

> That is what my comment about ColorForth being designed and written only
> for Charles Moore is about.
I think this sentence and your last one are inconsistent.
How can a program so uniquely tuned to Chuck's requirements allow you to
create your own environment?
Surely to teach the value of creating your own environment it must allow you
do to just that?
In which case it is totally generic.

[snip]

> > Design decisions :
> >
> > I have tried to improve colorForth, but so far with little success.
>> Chuck has found a combination of keypad, encoding, compiling etc
>> that works as a coherent whole.
>> This is an enormously valuable asset to the world of
> > computer science. I find the idea that Chuck designed colorForth
>> "just for himself" amazing in its inaccuracy.
> That is because you don't understand the context of my statement.
Clearly.

> Charles' design is centered around his needs-- and that is the strength of
> ColorForth.
This implies that other people's needs are precluded.
In fact, like any other Forth, colorForth is extensible. See the preceeding
few paragraphs....

> His primary language is English, so the character set,
> character encoding come directly from that.  I would imagine that Charles
> would tell users with a primary language other than English that they
> should
> choose a character set that suits them, and that they consider other
> character encoding strategies if necessary.
There is an icon editor which can be used to change which character is
associated with which number.
It is not tightly bound to any particular character set, but if you change
this, you will have a "non-standard" colorForth.
_You_ choose where to draw the line between common and custom code.
For example, if you write in Russian, you could swap say "a" and "z", or
whatever suits.
It is not difficult to do this - the choice is yours.

> For example, the character
> encoding Charles uses depends on some characters having a higher frequency
> than others in identifiers.  English has this property, but languages
> where
> that assumption doesn't hold true would need some other encoding scheme.
I find it hard to imagine a language that uses all of its characters
equally. If there is such a language, Huffman would not be very useful...

> Additionally, the scheme Charles uses assumes that identifiers will be
> unique within the first few characters.  Again, English (usually) has this
> property, but I don't believe all languages do.
Yes, this could be a deficiency of the current implementation of
colorForth.
Only one cell is stored in the search table, so only the first four to seven
characters are stored.
If this is a problem for you, by all means make it two cells or more.
But one cell works just fine if you write programs that occupy only a few
blocks, and choose short names.
This ties in to the "just in time compilation" of tiny programs. Since the
scope is so limited, you do not need much namespace. Outside of this
block-based, elegant programming style, you would probably need to store
longer filenames. I have not found this to be a problem.

> My point here isn't that Charles designed ColorForth to be hostile to
> other
> languages.  Rather, it is that ColorForth's design is centered around
> Charles' needs.  And when you view it in that context, yes, ColorForth
> works
> as a coherent whole.  Start to change some of the assumptions Charles has
> made (such as a dependency on English) and his particular implementation
> may
> not make as much sense.  And in that case, it merely means that someone
> with
> different needs than Charles needs to consider how to take ColorForth and
> make it fit their needs.  That to me is the primary strength of ColorForth
> as an approach to programming.
>
> The only problem I see with ColorForth isn't technical but social.
> Following the underlying philosophy of ColorForth to its logical end means
> that every programmer who uses it has a very personal environment that
> meets
> their needs.  That is going to make it difficult to share code.
Not if you share the environment too. That is why the magenta variable is so
important.
If you arrange that blocks can be exchanged, you can decide which blocks to
exchange, from just the application, to the font, to the kernel. They are
all just blocks.

> Certainly
> if I choose to tune ColorForth to a non-English alphabet or choose a
> different character encoding, then I can't (directly) share code.
True.

> ColorForth has a society behind it when people choose to be bound by a
> particular implementation of ColorForth.  As others continue to embrace
> the
> philosophy behind ColorForth, I see the community splintering into
> factions that can't share code.
I have collected colorForth programs from various websites and collated them
into a DOS based distribution package.
We all used Chuck's public domain colorForth with changes made to run on our
individual PCs. Chuck's original kernel only worked on my laptop and one of
my PCs with an ISA floppy card, but the latest kernel from Terry Loveall and
others works on all of my PCs and laptop.
Obviously if someone writes code that accesses, for example, an Ethernet
card that my PC doesn't have, its not going to work until it is modified for
the hardware that I do have.
The illusion is that this is a difficult thing to do - I think this is part
of what Chuck calls the "user illusion".
In fact it is extremely difficult to do because it is so hard to get the
hardware information that you need - but its getting easier.
ColorForth faces the same problems as Linux - but hardware manufacturers are
now seeing that it is profitable to let people other than the Microsoft
device driver writers know about their hardware.
In fact there is a lot of commonality between PC hardware, judged by the
fact that colorForth runs on a wide range of hardware with some relatively
simple configuration at power up.

> Normally, I would say this is a bad thing for other
> languages (like Forth) and that standardization should be a goal.
I think we should try some other solutions before we give up and buy
Longhorn...

> In ColorForth, this is a strength and not a weakness.
Sorry, I have lost what "this" referes to.

I hope that I am not being too picky, or cryptic.
I think these discussions are worthwhile, but we are talking about, and in,
different languages.
There are some real problems that need to be addressed with colorForth, such
as code sharing.
Some of these problems have been addressed by mainstream programming
languages, with varying degrees of success.
ColorForth allows me to explore other solutions to these problems.

Regards

Howerd

"Howerd Oakford" <howerd.oakford@ntlworld.com> wrote in message
news:VzWrb.511$W%.709252@newsfep1-win.server.ntli.net...
> Hi John,

Howdy,

A point-by-point response to your message would be my usual style.  But
since you're already injecting an agenda into my text that isn't there,
there probably isn't much point.  I would start by quoting you extending my
comments, like this...

> > ColorForth was written according to Charles Moore's sense
> > of what he finds necessary in a programming environment.
>
> True, but this implies that what Chuck finds necessary will
> probably not be of use to anyone else, which is not true.

.... and then I would then point out-- as I often do in comp.lang.forth-- 
that I neither stated nor implied any such thing.  I would then restate my
position, and then you (channeling the spirit of Jeff Fox) would isolate
some word or phrase that sets you off, and then twist the meaning around in
some grotesque way.  Others who came into the conversation late would skim
for their favorite keywords and pound out a thoughtless reply attacking me
for something I never wrote.  Hey, I've played this game enough to know the
patterns, and I'm frankly getting bored with it.

So instead, I'll just end my participation in this thread with a summary:

When ColorForth was first announced, I saw it as just another manifestation
of a theme that runs through Charles' work-- that of building your own tools
to address your needs (and *only* your needs).  Whatever compromises he may
have made to make ColorForth useful to others has got to be minor, because I
can't imagine someone who is so focused on finding what is essential to
allow "fluff" to invade ColorForth.  And by "fluff" I mean anything that
isn't necessary-- anything that Charles wouldn't use himself.

As you and others have pointed out, although the individual elements of
ColorForth may be odd or quirky in isolation, they work well together
synergistically.  That shouldn't be a surprise-- if they didn't work out,
Charles probably wouldn't suffer with it.  And that's because he can bend
and twist and shape ColorForth into exactly the form he wants.  In
ColorForth, he built an environment that suits his work, his ideas, his
style, and his philosophies on software design.  If others find it works out
for them too, hey, that's great.  But from what I read about the origins of
ColorForth, Charles never sat down and said, "I'm going to create a new
language that others can use and here are going to be the features it will
have."  ColorForth evolved over time along *his* requirements, not the
arbitrary requirements of others.

But regardless of the synergy of the individual elements of ColorForth,
there are still a set of choices that can be seen as arbitrary:

1) Why place a dependency on color (potentially making the language useless
to 10% of the adult male population)?  Because Charles has no problem
differentiating color.  If Charles happened to have some form of
color-blindness, you can bet that ColorForth would have used either
different fonts or some kind of inline textual representation-- something
other than color to indicate the different classes of tokens.

2)  Why use Huffman compression?  Charles likely chose it because (1) he
uses English, (2) English has the property of some letters having much
higher frequencies than others, (3) most English words have the property
that they can be differentiated from each other in the first few characters,
and (4) the average amount of text that can be stored in a 32-bit integer is
apparently long enough for Charles to express his identifiers.  If Charles
happened to primarily use a different natural language, the choice of
Huffman might not have worked.  He might have chose a completely different
compression scheme-- or no compression at all.

3)  Why the particular character set he chose?  This overlaps with the
previous point, but the choice of 48 characters is because he uses English
as his primary language.  The same with the symbols he chose to include.
The lack of characters like \ and " and % and so on are arbitrary-- he
doesn't apparently need them in programs.

4)  The choice of keyboard layout is perhaps the most obvious example of
arbitrary design choices.  The Dvorak-like mapping works well, but it's not
the only possible arrangement.

The fact that these (and other) design choices in ColorForth are synergistic
doesn't make them any less arbitrary.  That is, I could come up with my own
mutation of each of these things that also worked in complete harmony.
Moore didn't find *the* only possible synergistic system.  He found *a*
synergistic system.  A system that works for him.  Will it work for others?
Maybe.  Maybe not.

And that to me is the powerful message of ColorForth.  I look at ColorForth
and see a system that can be tuned to an individual's needs at *every*
level.  That's not just extensibility in the Forth tradition where you
extend an existing system but you still have Forth lurking under the covers.
In ColorForth-- at least as I see it-- you are invited to change *anything*
you don't like or need.  Don't have color on your VT100 terminal hooked to
your embedded system?  Change it!  Need a different character set?  Change
it!  Need a different method to encode strings?  Change it!  It's all there,
and if you have different needs from Charles, you're free to change
ColorForth.

In making such changes, you veer away from the arbitrary standards set by
the ColorForth community.  But I see that as perfectly fine, because I don't
see ColorForth's value in a particular implementation.  I see the value in a
DIY aesthetic.  I look at ColorForth and see what is essentially a reference
design for a build-it-yourself language.  I see freedom from the arbitrary
choices of others-- including freedom from the arbitrary choices of Charles
Moore.

Many people in this newsgroup seem to look at the work of Charles Moore as
an end.  He chooses color, and because it works well for him, you should
too.  He chooses English and Huffman compression, and because it works well
for him, you should too.  He chooses a keyboard layout that works well for
him, and you should adopt it too.  Nonsense.  Charles Moore's work isn't an
end.  It's a beginning.  You look at what he has done, step back, take it
all in, and then say, "here is what I need; here is what works for me."  I
get a message that essentially boils down to "do it yourself."

So I find some irony in that there is a ColorForth community-- and even a
page on www.colorforth.com that suggests some projects for the community.  I
would say that past learning from the reference implementation of
ColorForth, the best project the community should have is to document the
variations on a theme that others come up with.  That is when the true value
of ColorForth-- at least as I see it-- will be demonstrated.

You are free to respond to this message and to inject agendas where there is
none.  But before you do, you might consider simply taking what I wrote
flatly.  I don't write between the lines-- if I have something to say, I
have never had a problem coming out and saying it.

"John Passaniti" <nntp@JapanIsShinto.com> wrote in message news:<n9ksb.68884$ji3.58161@twister.nyroc.rr.com>...

> But regardless of the synergy of the individual elements of ColorForth,
> there are still a set of choices that can be seen as arbitrary:
> 
> 1) Why place a dependency on color (potentially making the language useless
> to 10% of the adult male population)?  Because Charles has no problem
> differentiating color.  If Charles happened to have some form of
> color-blindness, you can bet that ColorForth would have used either
> different fonts or some kind of inline textual representation-- something
> other than color to indicate the different classes of tokens.

Perhaps I let you answer this one:

The purpose of color is to signal switching to a different interpreter
(or more abstractly) to show the class of a token.  Color was an
obvious choice because color is cheap (nearly everyone these days uses
a color monitor and most video generation hardware can easily generate
 color).  Color was also an obvious choice because programmers have
used color in editors for years to show different classes of words.
 **But color itself isn't necessary.** [ my emphasis ]

One could replace color with other kinds of font changes.  Maybe
numeric literals could appear in a Courier font, comments in italics,
executable words in Times Roman boldface, and so on.


> Many people in this newsgroup seem to look at the work of Charles Moore as
> an end.  He chooses color, and because it works well for him, you should
> too.  He chooses English and Huffman compression, and because it works well
> for him, you should too.  He chooses a keyboard layout that works well for
> him, and you should adopt it too.  Nonsense.  Charles Moore's work isn't an
> end.  It's a beginning.  You look at what he has done, step back, take it
> all in, and then say, "here is what I need; here is what works for me."  I
> get a message that essentially boils down to "do it yourself."

Here you are inventing a "many people" who hold these views. No one
has held up Chuck's work as an end. That it is ideal in it original
form. If you recall, I have disagreed that your various "improvements"
are as such; perhaps you have taken that to mean I believe it is
impossible to top Chuck Moore's original. This is most certainly not
the case. If we take the elements you consider arbitrary as fixed,
namely the use of English and only English, using word oriented Forth,
colored colors, then the challenge remains to find a system that is of
better quality to Chuck's present design.

> 
> So I find some irony in that there is a ColorForth community-- and even a
> page on www.colorforth.com that suggests some projects for the community.  I
> would say that past learning from the reference implementation of
> ColorForth, the best project the community should have is to document the
> variations on a theme that others come up with.  That is when the true value
> of ColorForth-- at least as I see it-- will be demonstrated.

I would agree that there is value in variations. The reason that there
has not been more experimentation is due the complexity -- yes the
complexity -- of Chuck Moore's implementation. Chuck Moore has even
stated it is overly complex. When we a see a colorForth in colorForth,
the colorForth concept will really come in to its own. Hopefully we
will see all the variations and improvements that should have been
encouraged from the start.

There is also value in community. Someone might have idea you didn't.
Someone might have implemented an algorithm better you have. The main
value in community is in the interactions between people solving
similar sets of problems (and by in large the kinds of problems people
encounter are similar). There is not much value in code which can only
understood by author, or only has value to the author. The software
that makes up the Internet, as well as software I use to write this
message was grown from a social process. It could certainly not be
conceived and implemented by one person, and even if it could the
result be a kind of intellectual dictatorship. People have different
ambitions, desires, which can only be supported by a democratic
process. For code this means a community, exchanges of ideas, exchange
of code, a platform for communication and social process. It would be
a serious mistake for Forth to take the direction of isolation, each
relveling in his or her individualality.

Chuck Moore himself has tried to strike a balance between meeting his
own needs and communicating his results to a larger audience. In many
places he has communicated his ambition for Forth as general purpose
computing tool. In many places he has critiqued the Forth in widest
use, the ANSI standard. If Chuck Moore only cared about his own needs
why would he bother with the ANSI standard? Why would he go through
the trouble of creating a website? Why would he bother with Forth VLSI
chip designs (which only make sense in large quantities)? To say
colorForth was created only for Chuck Moore's needs not only misses
the point but is a direct contradiction to the public statements and
actions of Chuck Moore.

Mark

John Passaniti (nntp@JapanIsShinto.com) wrote:

[...] 
> In ColorForth, he built an environment that suits his work, his 
> ideas, his style, and his philosophies on software design.  If others 
> find it works out for them too, hey, that's great. 
 
But *how* it works for others that's the point you miss, IMO.

> But from what I read about the origins of ColorForth, Charles never sat 
> down and said, "I'm going to create a new language that others can use 
                  ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> and here are going to be the features it will have."  ColorForth evolved 
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Surely he did so.
But what do you call features?

> over time along *his* requirements, not the arbitrary requirements of 
                  ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> others.

Why do his requirements stand solidly against the others? Means there only
exist abitrary requirements? And his requirements punished the features of
ColorForth? 
I think CM was very thoughtful in his descisions which features
he like to have but arbitrary requirements to me seems belong to the
application level.
And it's historically not true, because he first build Okad and
took Forth as a tool, after that he decided to build ColorForth to
run Okad under it. That was a far more generelly approach of
recreating Forth.

Take a look at:

comp/lang/forth, 97/07/27
from: jfox@dnai.com  (Jeff Fox)
subj: Chuck's presentation
sorry, no MID, but I can post the text to you.

--------------------------------zip-----------------------------------
On Saturday July 26 1997 Chuck Moore gave a presentation to the
Silicon Valley Chapter of the Forth Interest Group.
[...]

Charles Moore:

[...]
The medium of interchange is ideas not code.  Tell me how you did a
heap sort, don't give me your code.  I have objected to Forth Dimension's
pages and pages of source when one block has the key definition.  It
just makes it harder to find what I want to know.  I won't use your
code anyway I will rewrite it.

[...]
One year ago I encouraged everyone to write their own OKAD.  Since
you didn't do that I don't feel guilty.  I assure you that I am
now on the right track and I encourage you to experiment with
color Forth.
[...]
--------------------------------zap-----------------------------------

Members of Deutsche Forth Gesellschaft e.V. translated that report
to the German "Vierte Dimension" as a title-story.
Thanks to Jeff Fox again.
-- 
Salut
 _)oachim

OK, my comments below read more trollish than I intented. Sorry in
advance.

What is frustrating is that I'm some one who predisposed to agree with
the ideas that CM expresses. Like: more with less, less stuff between
you & your machine, exchange ideas not perl.pm modules, tailor the
environment to the problem at hand, etc.

If "the medium of exchange is ideas not code" then CM has failed (so
far) by his own criterion. Because there is a miserable flow of ideas
from CM about colorforth. Poorly commented assembler source doesn't
count. All the tables amount to nothing if there is no explaination of
how they were derived. I'm guessing that there is colorforth code in
COLOR.COM but it might as well be encrypted; why couldn't it be posted
as html for the enevitable, "I can't get it to boot on my machine?"
That's just not thinking ahead.

DIY works up to a point but when it becomes DEY (do everthing
yourself) it backfires because I'll just follow my own path
completely. I got frustrated by loving the rhetoric but never getting
what was up with the gory details so I wrote my own bootable threaded
code interpreter based upon my ideas of elegance & efficiency. Likely
his is better, he is a smart man who's been at it many years, but with
out a hint from CM I'll never know for sure. Yes I borrowed some of
the superficial ideas from colorforth but beyond that there ain't
nothing the same.

"Howerd Oakford" <howerd.oakford@ntlworld.com> wrote in message news:<Hr4rb.353$rW3.276440@newsfep1-win.server.ntli.net>...
> Hi Michael,
> 
> "m-coughlin" <m-coughlin@comcast.net> wrote in message
> news:3FAA6A95.319D5BFE@comcast.net...
> 
> > Chuck Moore wrote Colorforth to be used by other people.
> > But it still looks like it was created for himself and only himself.
> Yes, it does look like that, but in fact it isn't.
> 
> Finding a suitable PC :
> 
> ColorForth is not trying to compete with Windows - that's Linux's job.
> If you are going to run any program directly on the hardware of your PC you
> immediately lose the cottonwool wrapping that you get with an OS, so it may
> not work on _your_ PC.
> This means that you have to find a PC that colorForth will run on, or change
> colorForth to suit.
> "Writing for other people" seems to mean making it easy to run the program
> on any PC - a problem which has been largely solved by Microsoft, at the
> expense of just about everything else.
> I can live with the performance issues, as hardware is so powerful these
> days, but I cannot accept the limited possibilites of that environment.

Why find a suitable PC when an "exchange of ideas" would allow me to
tweak the code to my environment. This can be done without aim down
the middle & pray it works on everybody's PC.
 
> ColorForth gives you back your PC. The price you pay is that you must find
> out how your PC works.

Bull! By that logic I've *ALWAYS* had my PC. Using other forths,
assembler or even (the dreaded) C. All I had to do was learn everthing
about the PC I needed & code everything my self... I needed colorforth
for this because...?

> So, once you have got past the fact that you will not find colorForth
> shrink-wrapped at PC World ( yet ), and made what ever effort it requires to
> get colorForth running on a PC - any PC - you can program your PC directly.

Sounds lovely but why c4th & not assembler for this?

> When you do this, without an OS, without files and without ASCII, you can
> start to explore the computer as it is, not as seen through the eyes of the
> Microsoft marketing department.

Huh? What has MS got to do with CM?

> 
> Documentation :
> 
> ColorForth documentaton is not finished. Chuck has described the key points
> on his website, and others have added their own comments on many other
> websites. Yes we need more documentation. Its on my to-do list...
 
See my comment below.

> Design decisions :
> 
> I have tried to improve colorForth, but so far with little success. Chuck
> has found a combination of keypad, encoding, compiling etc that works as a
> coherent whole. This is an enormously valuable asset to the world of

Clearly, you have got a direct line to the man & his ideas, that
doesn't help those grubbing for facts on the fringes of this circle.

> computer science. I find the idea that Chuck designed colorForth "just for
> himself" amazing in its inaccuracy.
> > Colorforth has all sorts of good ideas Chuck has invented over
> > the past fifteen years, and it needs as much work by a genius to
> > create the necessary instructional material as it took to
> > invent, develop and simplify the code.
> No, it just takes time, by lesser mortals. And not fifteen years, maybe
> fifteen days...

Ok maybe some ideas may take a fortnight to sink into my thick skull
but, come on, all of them?

> > That would be easier to
> > do if his new ideas were presented as separate topics instead of
> > all mixed together.
> Yes, it would be easier, but that is the problem with a synergetic system.
> Many of the new ideas in colorForth have very little to commend them in any
> other environment.
> 
> >  Chuck Moore's work of the last fifteen years or thirty
> > years is not what I'd call accessible.
> Its all in colorForth, which admitedly is not that accessible, but it is
> downloadable.
> 
> [snip]
> 
> > Radical new ideas need the best possible presentation.
> Absolutely.
> 
> > Colorforth is presented badly.
> We are trying our best ;)

I could not disagree with this off-hand comment more. Why should it be
up to only YOU to explain CM's ideas? He is a smart articulate man so
why can't he at least direct this a bit more.

> > I don't even have a computer that
> > it will run on. It needs a strange combination of things such as
> > a recent model of video card and an old floppy disk drive. Do
> > recent computers still have floppy disk drives?
> Some do, for those that don't I hear rumours that a port to a USB drive is
> happening.
> Please try the latest version from www.inventio.co.uk/cfdos - it runs on
> almost all laptops with a floppy, and most PCs ( with PCI/AGP graphics ). It
> can be made to run on any PC.

Mmm. I'd better spell this out here. I got this thing to work but
that's not the point. There is a world of difference between code that
works & explaining the ideas behind the code. That is what my rant is
about: I don't just want working code (I have that) I want some clue
as to why decisions were made beyond, "We don't need no stinkin'
Microsoft OS!" That's what the rhetoric promises but never delivers.

> Its quality, not quantity that counts.

You need BOTH to be sucessful. Being clever is great but if you don't
accomplish anything who cares? The dumb don't get hired but smart
people who don't get the job done get fired... unless you're in
academia :/

> ColorForth is not for everybody, just the curious and persistent who want to
> understand about computers.

Colorforth is only for the l33t? I don't think that you mean that but
that's the way it reads. I'll bet that there is a larger group of
people than you realize who'd love to get into this project.

> Yes, that colorForth is being supported by "amateurs" - people who do it for
> the love of their chosen subject.
> Give us time!

Having the support of those who work for the love of it is great. I'd
even be willing to help but unfortunately the details of the vision
haven't been presented clearly. So I'm happy to slog along on with my
own projects.

Hi,

<twisteddweeb@yahoo.com> wrote in message
news:35050f5c.0311131056.573bc2ce@posting.google.com...
> OK, my comments below read more trollish than I intented. Sorry in
> advance.
No problem ;)

> What is frustrating is that I'm some one who predisposed to agree with
> the ideas that CM expresses. Like: more with less, less stuff between
> you & your machine, exchange ideas not perl.pm modules, tailor the
> environment to the problem at hand, etc.
>
> If "the medium of exchange is ideas not code" then CM has failed (so
> far) by his own criterion. Because there is a miserable flow of ideas
> from CM about colorforth.
Chuck's documentation, like his code, is minimalist, but tends to be
complete.

> Poorly commented assembler source doesn't
> count. All the tables amount to nothing if there is no explaination of
> how they were derived. I'm guessing that there is colorforth code in
> COLOR.COM but it might as well be encrypted; why couldn't it be posted
> as html for the enevitable, "I can't get it to boot on my machine?"
> That's just not thinking ahead.
One of the major colorForth projects is to port it to colorForth.
Personally I have no intention of messing about with MASM, but its a long
process.
There is no reason that we should expect Chuck to do all of the work...

> DIY works up to a point but when it becomes DEY (do everthing
> yourself) it backfires because I'll just follow my own path
> completely. I got frustrated by loving the rhetoric but never getting
> what was up with the gory details so I wrote my own bootable threaded
> code interpreter based upon my ideas of elegance & efficiency. Likely
> his is better, he is a smart man who's been at it many years, but with
> out a hint from CM I'll never know for sure. Yes I borrowed some of
> the superficial ideas from colorforth but beyond that there ain't
> nothing the same.
Perhaps you would like to document it, explain the design decisions and
publish it. It will help you appreciate the time and effort involved - but
you may have discovered some new ideas worth sharing ;)

> "Howerd Oakford" <howerd.oakford@ntlworld.com> wrote in message
news:<Hr4rb.353$rW3.276440@newsfep1-win.server.ntli.net>...
[snip]
> Why find a suitable PC when an "exchange of ideas" would allow me to
> tweak the code to my environment. This can be done without aim down
> the middle & pray it works on everybody's PC.
That kind of exchange of ideas works just fine on a newsgroup such as this,
but someday you will want to try it out on a PC.

> > ColorForth gives you back your PC. The price you pay is that you must
find
> > out how your PC works.
>
> Bull! By that logic I've *ALWAYS* had my PC. Using other forths,
> assembler or even (the dreaded) C. All I had to do was learn everthing
> about the PC I needed & code everything my self... I needed colorforth
> for this because...?
I have got control of my PC using a DOS based polyForth, but XP is chopping
away at that by providing a very slow DOS box. Assembler is fine for small
programs, less than 2 bytes, and C is fine for spending time and making
money. There are some other Forths that run directly on the hardware ( your
own one included ), but colorForth is a new slant on what Forth can be, AND
runs directly on the hardware, AND is "supported" ( if that is the right
word ) by a small group of amateurs.

> > So, once you have got past the fact that you will not find colorForth
> > shrink-wrapped at PC World ( yet ), and made what ever effort it
requires to
> > get colorForth running on a PC - any PC - you can program your PC
directly.
>
> Sounds lovely but why c4th & not assembler for this?
I prefer Forth to assembler.

> > When you do this, without an OS, without files and without ASCII, you
can
> > start to explore the computer as it is, not as seen through the eyes of
the
> > Microsoft marketing department.
>
> Huh? What has MS got to do with CM?
OK, that was a bit cryptic. Windows is designed to maximise profit, and the
view you get of a computer running Windows is "pretty", "user friendly",
"designed to be appealing to non-programmers" etc. The actual computer is a
set of hardware components controlled by software and tends to be displayed
using a black background with no borders and is not so eye catching. But it
does have properties that I find "beautiful" in the mathmatical sense of the
word. And its fun.ColorForth is as close as you can get to the computer
without becoming an electron.

> > Documentation :
> >
> > ColorForth documentaton is not finished. Chuck has described the key
points
> > on his website, and others have added their own comments on many other
> > websites. Yes we need more documentation. Its on my to-do list...
>
> See my comment below.
>
> > Design decisions :
> >
> > I have tried to improve colorForth, but so far with little success.
Chuck
> > has found a combination of keypad, encoding, compiling etc that works as
a
> > coherent whole. This is an enormously valuable asset to the world of

> Clearly, you have got a direct line to the man & his ideas, that
> doesn't help those grubbing for facts on the fringes of this circle.
My PR department has obviously been doing a good job! I have met Chuck
twice, once briefly at the Forth, Inc. 10th anniversary party in 1982 IIRC,
once at EuroForth in 1992. At EuroForth Chuck showed me his CAD package
written in colorForth, and described how it worked. Apart from that and a
few emails to/from Chuck my only direct line to Chuck ( and his inner
circle - whoever they are! ) is through his code.

 > > computer science. I find the idea that Chuck designed colorForth "just
for
> > himself" amazing in its inaccuracy.
> > > Colorforth has all sorts of good ideas Chuck has invented over
> > > the past fifteen years, and it needs as much work by a genius to
> > > create the necessary instructional material as it took to
> > > invent, develop and simplify the code.
> > No, it just takes time, by lesser mortals. And not fifteen years, maybe
> > fifteen days...
>
> Ok maybe some ideas may take a fortnight to sink into my thick skull
> but, come on, all of them?
No - the 15 days is to write up a proper explanation, not to read and
understand it!
This will be much easier when the port to colorForth is complete, but until
then you can just use colorForth to write applications. Its the best way to
learn. If you need help, just ask!

> > [snip]

> > > Colorforth is presented badly.
> > We are trying our best ;)
>
> I could not disagree with this off-hand comment more. Why should it be
> up to only YOU to explain CM's ideas? He is a smart articulate man so
> why can't he at least direct this a bit more.
English lacks a second person singular, but the context implies "me", not
"us". This is definitely not just "my" job, but all of the people who are
interested in colorForth. And not just an L33+ !
As for Chuck's involvement - you will have to ask him.

> > > I don't even have a computer that
> > > it will run on. It needs a strange combination of things such as
> > > a recent model of video card and an old floppy disk drive. Do
> > > recent computers still have floppy disk drives?
> > Some do, for those that don't I hear rumours that a port to a USB drive
is
> > happening.
> > Please try the latest version from www.inventio.co.uk/cfdos - it runs on
> > almost all laptops with a floppy, and most PCs ( with PCI/AGP
graphics ). It
> > can be made to run on any PC.
>
> Mmm. I'd better spell this out here. I got this thing to work but
> that's not the point. There is a world of difference between code that
> works & explaining the ideas behind the code. That is what my rant is
> about: I don't just want working code (I have that) I want some clue
> as to why decisions were made beyond, "We don't need no stinkin'
> Microsoft OS!" That's what the rhetoric promises but never delivers.
ColorForth runs without a Microsoft OS. That promise at least has been
delivered!
Please ask specific questions and I am sure the colorForth community, small
though it may be, will answer you.

> > Its quality, not quantity that counts.
>
> You need BOTH to be sucessful. Being clever is great but if you don't
> accomplish anything who cares? The dumb don't get hired but smart
> people who don't get the job done get fired... unless you're in
> academia :/
Who said anything about success? I just like playing with colorForth - its
fun.
For success you need something much more complicated...

> > ColorForth is not for everybody, just the curious and persistent who
want to
> > understand about computers.
>
> Colorforth is only for the l33t? I don't think that you mean that but
> that's the way it reads. I'll bet that there is a larger group of
> people than you realize who'd love to get into this project.
I don't want to stop anyone from joining the elite group of  "curious and
persistent" people who discuss colorForth!

>
> > Yes, that colorForth is being supported by "amateurs" - people who do it
for
> > the love of their chosen subject.
> > Give us time!
>
> Having the support of those who work for the love of it is great. I'd
> even be willing to help but unfortunately the details of the vision
> haven't been presented clearly. So I'm happy to slog along on with my
> own projects.
I print out colorForth documentation to read off-line - it is now about 1.5
inches thick.
I'm not sure what the "vision" is, over and above any other Forth : a neat
way to control a computer.
ColorForth is just a different way of doing this compared to a conventional
Forth, and happens to run directly on the PC's hardware. It is such a simple
environment that it allows entirely new constructs, and this makes it worth
looking at IMHO.

Regards

Howerd  8^)

Hi John,

"John Passaniti" <nntp@JapanIsShinto.com> wrote in message
news:n9ksb.68884$ji3.58161@twister.nyroc.rr.com...
>
> "Howerd Oakford" <howerd.oakford@ntlworld.com> wrote in message
> news:VzWrb.511$W%.709252@newsfep1-win.server.ntli.net...
> > Hi John,
>
> Howdy,
>
> A point-by-point response to your message would be my usual style.  But
> since you're already injecting an agenda into my text that isn't there,
> there probably isn't much point.  I would start by quoting you extending
my
> comments, like this...
>
> > > ColorForth was written according to Charles Moore's sense
> > > of what he finds necessary in a programming environment.
> >
> > True, but this implies that what Chuck finds necessary will
> > probably not be of use to anyone else, which is not true.
I think we will have to agree to differ on this, but I think I am simply
stating the agenda implicit in your specific wording.

> ... and then I would then point out-- as I often do in comp.lang.forth--
> that I neither stated nor implied any such thing.  I would then restate my
> position, and then you (channeling the spirit of Jeff Fox) would isolate
> some word or phrase that sets you off, and then twist the meaning around
in
> some grotesque way.  Others who came into the conversation late would skim
> for their favorite keywords and pound out a thoughtless reply attacking me
> for something I never wrote.  Hey, I've played this game enough to know
the
> patterns, and I'm frankly getting bored with it.
Yes. This has happened.

> So instead, I'll just end my participation in this thread with a summary:
And I will add my own summary :

I think there are two aspects to colorForth - the concepts and the
implementation.
The implementation will obviously be tailored to suit Chucks specific needs.
The concepts, I believe, apply to anyone programming a computer.

Where we differ, I think, is that I accept the limitations of the current
implementation of colorForth in order to discuss the concepts that it
introduces, whereas you seem to "dismiss the concepts" because the
implementation is imperfect.
Perhaps "dismiss the concepts" is too extreme, as you clearly state that
some of the ideas in colorForth are worth looking at.
The problem I have with this is that if you take individual concepts out of
the colorForth environment, they often become pointless.
I am sure that  you appreciate that the value of a concept depends on its
context, but this doesn't always come across in your posts.
A good example of this is the magenta variable, which you admirably emulated
in Perl. But I can see no practical use for the Perl version - it requires
megabytes of executables to run, and modifies your source files. But I can
see some very good uses for magenta variables - they have already simplified
distribution of programs with a defined state. They are implemented in a few
bytes of run time code and a few extra lines in the editor.

The issue of colour in colorForth seems to be neverending!
In my DOS colorForth reader I have included the "colourblind" key ( F4 )
which magically displays the source in a conventional Forth format.
This makes my DOS system different, but I do not agree that either the
original or modified colorForth is compromised in its usefulness to other
people.
You seem think that the freedom to make changes will inevitably cause chaos.

The colorForth kernel is written in MASM, and I do not change that. But I do
write programs in colorForth which I share with other people. I know that if
I change my font to Arabic it will make the sharing of code more difficult,
so I don't do it.

It is your confining of colorForth to the realms of quirky, one-off DIY
programmers that I find particularly bizarre.
I think we will just have to agree to differ - what you see as a hobby for
lone programmers not interested in community programming, I see as a tool to
investigate the archetypal properties of computers.
You seem to require sharing by means of a delegated authority, I prefer
sharing by discovering what is actually common ground.

Best regards,

Howerd   8^)

> When ColorForth was first announced, I saw it as just another
manifestation
> of a theme that runs through Charles' work-- that of building your own
tools
> to address your needs (and *only* your needs).  Whatever compromises he
may
> have made to make ColorForth useful to others has got to be minor, because
I
> can't imagine someone who is so focused on finding what is essential to
> allow "fluff" to invade ColorForth.  And by "fluff" I mean anything that
> isn't necessary-- anything that Charles wouldn't use himself.
>
> As you and others have pointed out, although the individual elements of
> ColorForth may be odd or quirky in isolation, they work well together
> synergistically.  That shouldn't be a surprise-- if they didn't work out,
> Charles probably wouldn't suffer with it.  And that's because he can bend
> and twist and shape ColorForth into exactly the form he wants.  In
> ColorForth, he built an environment that suits his work, his ideas, his
> style, and his philosophies on software design.  If others find it works
out
> for them too, hey, that's great.  But from what I read about the origins
of
> ColorForth, Charles never sat down and said, "I'm going to create a new
> language that others can use and here are going to be the features it will
> have."  ColorForth evolved over time along *his* requirements, not the
> arbitrary requirements of others.
>
> But regardless of the synergy of the individual elements of ColorForth,
> there are still a set of choices that can be seen as arbitrary:
>
> 1) Why place a dependency on color (potentially making the language
useless
> to 10% of the adult male population)?  Because Charles has no problem
> differentiating color.  If Charles happened to have some form of
> color-blindness, you can bet that ColorForth would have used either
> different fonts or some kind of inline textual representation-- something
> other than color to indicate the different classes of tokens.
>
> 2)  Why use Huffman compression?  Charles likely chose it because (1) he
> uses English, (2) English has the property of some letters having much
> higher frequencies than others, (3) most English words have the property
> that they can be differentiated from each other in the first few
characters,
> and (4) the average amount of text that can be stored in a 32-bit integer
is
> apparently long enough for Charles to express his identifiers.  If Charles
> happened to primarily use a different natural language, the choice of
> Huffman might not have worked.  He might have chose a completely different
> compression scheme-- or no compression at all.
>
> 3)  Why the particular character set he chose?  This overlaps with the
> previous point, but the choice of 48 characters is because he uses English
> as his primary language.  The same with the symbols he chose to include.
> The lack of characters like \ and " and % and so on are arbitrary-- he
> doesn't apparently need them in programs.
>
> 4)  The choice of keyboard layout is perhaps the most obvious example of
> arbitrary design choices.  The Dvorak-like mapping works well, but it's
not
> the only possible arrangement.
>
> The fact that these (and other) design choices in ColorForth are
synergistic
> doesn't make them any less arbitrary.  That is, I could come up with my
own
> mutation of each of these things that also worked in complete harmony.
> Moore didn't find *the* only possible synergistic system.  He found *a*
> synergistic system.  A system that works for him.  Will it work for
others?
> Maybe.  Maybe not.
>
> And that to me is the powerful message of ColorForth.  I look at
ColorForth
> and see a system that can be tuned to an individual's needs at *every*
> level.  That's not just extensibility in the Forth tradition where you
> extend an existing system but you still have Forth lurking under the
covers.
> In ColorForth-- at least as I see it-- you are invited to change
*anything*
> you don't like or need.  Don't have color on your VT100 terminal hooked to
> your embedded system?  Change it!  Need a different character set?  Change
> it!  Need a different method to encode strings?  Change it!  It's all
there,
> and if you have different needs from Charles, you're free to change
> ColorForth.
>
> In making such changes, you veer away from the arbitrary standards set by
> the ColorForth community.  But I see that as perfectly fine, because I
don't
> see ColorForth's value in a particular implementation.  I see the value in
a
> DIY aesthetic.  I look at ColorForth and see what is essentially a
reference
> design for a build-it-yourself language.  I see freedom from the arbitrary
> choices of others-- including freedom from the arbitrary choices of
Charles
> Moore.
>
> Many people in this newsgroup seem to look at the work of Charles Moore as
> an end.  He chooses color, and because it works well for him, you should
> too.  He chooses English and Huffman compression, and because it works
well
> for him, you should too.  He chooses a keyboard layout that works well for
> him, and you should adopt it too.  Nonsense.  Charles Moore's work isn't
an
> end.  It's a beginning.  You look at what he has done, step back, take it
> all in, and then say, "here is what I need; here is what works for me."  I
> get a message that essentially boils down to "do it yourself."
>
> So I find some irony in that there is a ColorForth community-- and even a
> page on www.colorforth.com that suggests some projects for the community.
I
> would say that past learning from the reference implementation of
> ColorForth, the best project the community should have is to document the
> variations on a theme that others come up with.  That is when the true
value
> of ColorForth-- at least as I see it-- will be demonstrated.
>
> You are free to respond to this message and to inject agendas where there
is
> none.  But before you do, you might consider simply taking what I wrote
> flatly.  I don't write between the lines-- if I have something to say, I
> have never had a problem coming out and saying it.
>
>

----- Original Message -----
From: "John Passaniti" <nntp@JapanIsShinto.com>
Newsgroups: comp.lang.forth
To: <comp.lang.forth@ada-france.org>
Sent: Wednesday, November 12, 2003 13:10
Subject: Re: Colorforth for Other People (was Re: ANN cfdos - EuroForth
2003edition)


> So instead, I'll just end my participation in this thread with a summary:

John, do you know why some people love ColorForth so much? I am curious. I
already knew their answer and I will not ask them. Since you are not in the
group, and also not in the ColorForth haters group, I expect unbiased
explanation. Is it because of the famous author? Or because of the silent
author? Or because of good pr Mr. Fox? Or.. ?

I also invite neutral group to give opinion. This is phenomenal. The product
can defend itself. What is the secret?

Regards,
Petrus-Pet4th.

"Howerd Oakford" <howerd.oakford@ntlworld.com> wrote in message news:<3NVsb.1673$Et2.1489@newsfep3-gui.server.ntli.net>...
> Hi,
> 
> <twisteddweeb@yahoo.com> wrote in message
> news:35050f5c.0311131056.573bc2ce@posting.google.com...
> > OK, my comments below read more trollish than I intented. Sorry in
> > advance.
> No problem ;)

The dweeb took a needed stress tab ;) thanks for not sinking to my
level in your reply.

> > DIY works up to a point but when it becomes DEY (do everthing
> > yourself) it backfires because I'll just follow my own path
> > completely. I got frustrated by loving the rhetoric but never getting
> > what was up with the gory details so I wrote my own bootable threaded
> > code interpreter based upon my ideas of elegance & efficiency. Likely
> > his is better, he is a smart man who's been at it many years, but with
> > out a hint from CM I'll never know for sure. Yes I borrowed some of
> > the superficial ideas from colorforth but beyond that there ain't
> > nothing the same.
> Perhaps you would like to document it, explain the design decisions and
> publish it. It will help you appreciate the time and effort involved - but
> you may have discovered some new ideas worth sharing ;)

Possibly but for now it's an experiment I have nothing against
sharing. I come from userland so there are a ton of rough edges. Like
with just about every device driver. Give me less than 15years but no
problem (;

> >
> > Huh? What has MS got to do with CM?
> OK, that was a bit cryptic. Windows is designed to maximise profit, and the
> view you get of a computer running Windows is "pretty", "user friendly",
> "designed to be appealing to non-programmers" etc. The actual computer is a
> set of hardware components controlled by software and tends to be displayed
> using a black background with no borders and is not so eye catching. But it
> does have properties that I find "beautiful" in the mathmatical sense of the
> word. And its fun.ColorForth is as close as you can get to the computer
> without becoming an electron.

I'd argue assembler may be but I have nothing against other "higher"
level languages moving into assembler territory.

> This will be much easier when the port to colorForth is complete, but until
> then you can just use colorForth to write applications. Its the best way to
> learn. If you need help, just ask!

OK that's fair. Having asked & been heckled without mercy elsewhere
(not CF related) that option never got fully considered. If you don't
RTFM 1st you'll often get abused... No M to FR so...

> > > Its quality, not quantity that counts.
> >
> > You need BOTH to be sucessful. Being clever is great but if you don't
> > accomplish anything who cares? The dumb don't get hired but smart
> > people who don't get the job done get fired... unless you're in
> > academia :/
> Who said anything about success? I just like playing with colorForth - its
> fun.
> For success you need something much more complicated...

Well maybe the terms need to be defined because I'd argue that point.
But after I experiment more.

dweeb

"Petrus Prawirodidjojo" <petrusp@attglobal.net> wrote in message news:<mailman.6.1068821306.3110.comp.lang.forth@ada-france.org>...
> ----- Original Message -----
> From: "John Passaniti" <nntp@JapanIsShinto.com>
> Newsgroups: comp.lang.forth
> To: <comp.lang.forth@ada-france.org>
> Sent: Wednesday, November 12, 2003 13:10
> Subject: Re: Colorforth for Other People (was Re: ANN cfdos - EuroForth
> 2003edition)
> 
> 
> > So instead, I'll just end my participation in this thread with a summary:
> 
> John, do you know why some people love ColorForth so much? I am curious. I
> already knew their answer and I will not ask them.

I'm curious, what is "our" answer?

> Since you are not in the
> group, and also not in the ColorForth haters group, I expect unbiased
> explanation. Is it because of the famous author? Or because of the silent
> author? Or because of good pr Mr. Fox? Or.. ?
> 
> I also invite neutral group to give opinion. This is phenomenal. The product
> can defend itself. What is the secret?

I can't wait to hear the astounding insights of this group.

Mark

----- Original Message -----
From: "Mark Slicker" <maslicke@oakland.edu>
Newsgroups: comp.lang.forth
To: <comp.lang.forth@ada-france.org>
Sent: Saturday, November 15, 2003 04:27
Subject: Re: The amazing ColorForth (was...)


> > John, do you know why some people love ColorForth so much? I am curious.
I
> > already knew their answer and I will not ask them.
>
> I'm curious, what is "our" answer?

"Your" answer would be like:
- Color is better than b/w
- ASCII is not needed
- QWERTY keyboard layout is inferior
- File system is not needed
- Small size, diskette size
- Fast 10x 25x 100x 1000x
- Simple not complex
- ColorForth is the modern Forth, while ANS Forth is still based on old
Forth 83

Those technical advantage is for a new device and embedded (small) system.
That is if we could (afford to) discard old keyboards, discard old people
who accustomed to the keyboard. A truly "think small" philosophy. Focus on
the detail. And much work to reinvent the wheel.

A rather "think big" philosophy of ANS Forth still produce much interest in
the detail. Always try to improve the Forth. While more people wants to get
the result of using Forth. More people ask for application in ANS Forth.

Please look at the "think big" philosophy of C. They knew that C is not
perfect, at least the operator precedence is said to be wrong. But they go
on and on forward.

Oops. I talk to much. Back to silent mode, I would hear from you instead of
me talking.

Thanks for your comment though you are from the 'love' group. I am avoiding
debate with 'love' group.

Regards,
Petrus-Pet4th.

Howerd Oakford wrote:
> 
> Hi Michael,
> 
> "m-coughlin" <m-coughlin@comcast.net> wrote in message
> news:3FAA6A95.319D5BFE@comcast.net...
> 
> >  I wish I could resist the temptation to join in debates
> > with people with strong opinions.
> Me too!
 
 [snip]
 
 [snip]
 
> > I don't even have a computer that
> > it will run on. It needs a strange combination of things such as
> > a recent model of video card and an old floppy disk drive. Do
> > recent computers still have floppy disk drives?
> Some do, for those that don't I hear rumours that a port to a
> USB drive is happening.

> Please try the latest version from www.inventio.co.uk/cfdos - it runs
> on almost all laptops with a floppy, and most PCs ( with PCI/AGP
> graphics ). It can be made to run on any PC.

     You mean --
http://www.inventio.co.uk/cfdos.htm

     This page has much interesting information. I wish I would
find it immediately when I look for anything about Colorforth. 

   Here are two quotes from this page.

"To run colorForth your PC must have a floppy drive, 386 or
above processor, 32Mbytes of RAM, AGP video and a monitor
capable of displaying 1024x768x16bit colours."

"You should certainly be able to see the source code with
cfdos.com, but if at all possible you should find some floppy
disks and a computer and run colorForth. Press �D� to download
to the floppy. Try CFDOS.BLK first, as it works on most of the
computers that I have tried it on. You may need to find a 200MHz
- 500MHz Pentium ( with a floppy disk and AGP graphics ), as
these seem to be particularly compatible, as are 1GHz to 1.5GHz
laptops. "

      I find the mention of using a '386 or above processor very
confusing. I tried to use Colorforth on an 80486 and a 100 MHz
Pentium computer early on with no success. But the second quote
clears this up. So I would tell any new potential users of
Colorforth that the code is of the 80386 and up family but the
program only runs on much newer machines.

       Now let me point out something of great concern to me. 
You state "It can be made to run on any PC." I would like to run
it off a hard drive on my 80486 based computers with one to
eight megabytes of memory, and an 800x600 or 640x480 video
display. Certainly anyone with the ability to reverse engineer
compiled code or understand uncommented Wintel-PC assembly
language can make the necessary changes. In my opinion, needing
to know that would be a reason to say that it can't be made to
run on any PC. If there existed a write-up that documented how
such changes could be made by a programmer of ordinary ability,
then the situation would be totally different. Until that
documentation exists, Colorforth can be just a source of
frustration for most people who might want to use it.

--
Michael Coughlin   m-coughlin@comcast.net   Cambridge, MA USA

Hi dweeb ( "if that is your real name" - Homer Simpson ),

[snip]

>> ColorForth is as close as you can get to the computer
>> without becoming an electron.
> I'd argue assembler may be but I have nothing against other "higher"
> level languages moving into assembler territory.
ColorForth is actually below assembler in the sense that it does not use
mnemonics to describe the processor instructions. It does however use cyan
macros to define Forth primitives using hexadecimal opcodes. If the
processor was a Forth chip this would be the same thing as an assembler.
I suppose binary would be slightly closer to the hardware, but the processor
documentation gives the opcodes in hex  ;)

Regards

Howerd

Hi Michael,

"m-coughlin" <m-coughlin@comcast.net> wrote in message
news:3FB574AF.D93291EB@comcast.net...
[snip]
> > Please try the latest version from www.inventio.co.uk/cfdos - it runs
> > on almost all laptops with a floppy, and most PCs ( with PCI/AGP
> > graphics ). It can be made to run on any PC.
>      You mean --
> http://www.inventio.co.uk/cfdos.htm
Yes! Sorry about dropping the "htm".
I think "http" is the default for www.

>  This page has much interesting information. I wish I would
> find it immediately when I look for anything about Colorforth.
Thanks. I keep meaning to get it linked to the other cf pages...

>    Here are two quotes from this page.
>
> "To run colorForth your PC must have a floppy drive, 386 or
> above processor, 32Mbytes of RAM, AGP video and a monitor
> capable of displaying 1024x768x16bit colours."
>
> "You should certainly be able to see the source code with
> cfdos.com, but if at all possible you should find some floppy
> disks and a computer and run colorForth. Press "D" to download
> to the floppy. Try CFDOS.BLK first, as it works on most of the
> computers that I have tried it on. You may need to find a 200MHz
> - 500MHz Pentium ( with a floppy disk and AGP graphics ), as
> these seem to be particularly compatible, as are 1GHz to 1.5GHz
> laptops. "
>
>       I find the mention of using a '386 or above processor very
> confusing.
ColorForth is actually designed to run on a Forth chip - the cyan macro
vocabulary allows it to run on something else. It could be ported to
anything, just like conventional Forth. Its just that porting it to some
processors will be easier than others.

> I tried to use Colorforth on an 80486 and a 100 MHz
> Pentium computer early on with no success. But the second quote
> clears this up. So I would tell any new potential users of
> Colorforth that the code is of the 80386 and up family but the
> program only runs on much newer machines.
Have you tried the CF800.BLK file? It uses 800x600 graphics.
There may be some Pentium-specific instructions used in the kernel, and I
think the timing code will not work on a 386 - if anyone has tried
colorForth on non-Pentium processors perhaps they could enlighten us.
These days you can often find 200MHz Pentia ( with floppy drives ) being
thrown out...

>        Now let me point out something of great concern to me.
> You state "It can be made to run on any PC." I would like to run
> it off a hard drive on my 80486 based computers with one to
> eight megabytes of memory, and an 800x600 or 640x480 video
> display. Certainly anyone with the ability to reverse engineer
> compiled code or understand uncommented Wintel-PC assembly
> language can make the necessary changes.
No reverse engineering is neccessary - all MASM ( or NASM ) assembler source
is downloadable, from the original authors' sites - I don't support that on
my site although I do have archives if you get stuck.
The rest is colorForth.

> In my opinion, needing
> to know that would be a reason to say that it can't be made to
> run on any PC.
In the sense that not knowing your pin number means that you can't get cash
from an ATM?
I think it is easier to find a PC that the default colorForth works on,
rather than spend the time customising it for a specific one. But if you do,
please let me have the code and I will add a CF486.BLK to the list... ;)

> If there existed a write-up that documented how
> such changes could be made by a programmer of ordinary ability,
> then the situation would be totally different.
This would indeed be very useful...
The colorForth kernel is about 2K bytes, and is created from three asm
files, totalling about 83K.
The parts that have to be changed for different displays and floppy chips is
actually quite small, and is lightly documented in the asm files.
This is work in progress, and one of the main colorForth projects is to port
it colorForth. This will make it much easier to document.

> Until that
> documentation exists, Colorforth can be just a source of
> frustration for most people who might want to use it.
Please direct your frustration at the reasons why we do not have a 32 bit
BIOS on a 32 bit platform, and lack of support in the 16 bit BIOS that is
provided for anything that might allow people to compete with Windows.... :(

To sum up : colorForth does not come shrink wrapped!
PC hardware seems to be converging. Originally the PC's open architecture
allowed competition between manufacturers, and hardware was often made
different to hinder competitors. But now there are fewer manufacturers, and
a tendency to stick to proven interfaces to avoid having to re-write the
BIOS.
AGP graphics for example, is memory mapped, so the problem just becomes
finding out where the BIOS has mapped it to. The old PC hardware such as
UARTS, timers, speaker and even Ethernet cards are almost always mapped to
the same hardware addresses. Sound cards are a different story though.
I have been pleasantly suprised by how many PCs colorForth will work on.

Regards

Howerd

Hi Petrus,

"Petrus Prawirodidjojo" <petrusp@attglobal.net> wrote in message
news:mailman.8.1068855254.3110.comp.lang.forth@ada-france.org...
[snip]
> Please look at the "think big" philosophy of C. They knew that C is not
> perfect, at least the operator precedence is said to be wrong. But they go
> on and on forward.
To C++? Or have I missed something?

[snip]
> Thanks for your comment though you are from the 'love' group. I am
avoiding
> debate with 'love' group.
I know I fall into the "love" category, but I couldn't resist the temptation
to comment on this one point ;)

Regards

Howerd

----- Original Message -----
From: "Howerd Oakford" <howerd.oakford@ntlworld.com>
Newsgroups: comp.lang.forth
To: <comp.lang.forth@ada-france.org>
Sent: Saturday, November 15, 2003 20:32
Subject: Re: The amazing ColorForth (was...)


> To C++? Or have I missed something?

What I meant is that most C (or C++ or Java or C#) programmers write
applications and they are not modifying the C again and again. While most
Forth programmers are busy improving their Forth system, including me of
course. Kind of have fun with the tools and forget why the tools are made.

One of the Forth problem is that it is fun to play with. And we are allowed
to change everything (to customize it). Now I am changing most variables (@
and !) with values (value and to).

With ColorForth, someone will go deeper. Worse than ANS Forth. Default is
subset of DVORAK. Surely I will change that first if I want to use it. Then
the character set which is subset of ASCII. So I will not have time left to
write applications.

On the other side, "think big" move from ASCII to Unicode, where ASCII is
subset of Unicode.

> I know I fall into the "love" category, but I couldn't resist the
temptation
> to comment on this one point ;)

I am surprised at your nice writing. I do not expect such a nice comment
from the "love" group. Of course such a nice question/comment is welcome.

Regards,
Petrus-Pet4th.

Howerd Oakford wrote:
 
> "m-coughlin" <m-coughlin@comcast.net> wrote in message
> news:3FB574AF.D93291EB@comcast.net...

Regarding the information on 
 http://www.inventio.co.uk/cfdos.htm

      There is a collection of various bits and pieces inspired
by Chuck Moore's original Colorforth. I don't see a coherent
view of the big picture. Everybody seems to be working on one
little piece and not realizing that what one programmer knows is
obvious, other programmers will find so confusing that they
woun't even know what question to ask for clarification.

       I appreciate Howerd Oakford's efforts to collect code and
extend the usefulness of Colorforth. It is a difficult job. It
would be easier if he had clearer material to start with.

> >       I find the mention of using a '386 or above processor very
> > confusing.

> ColorForth is actually designed to run on a Forth chip - the cyan macro
> vocabulary allows it to run on something else. It could be ported to
> anything, just like conventional Forth. Its just that porting it to some
> processors will be easier than others.
> 
> > I tried to use Colorforth on an 80486 and a 100 MHz
> > Pentium computer early on with no success. But the second quote [about how it runs on Pentium ( II, IV, Celeron (?)) chips 400 to 500 MHz}
> > clears this up. So I would tell any new potential users of
> > Colorforth that the code is of the 80386 and up family but the
> > program only runs on much newer machines.

> Have you tried the CF800.BLK file? It uses 800x600 graphics.
> There may be some Pentium-specific instructions used in the kernel,
> and I think the timing code will not work on a 386 - if anyone has tried
> colorForth on non-Pentium processors perhaps they could enlighten us.
> These days you can often find 200MHz Pentia ( with floppy drives )
> being thrown out...

      I can't read the CF800.BLK file unless I get some version
of Colorforth running. Is there a text file with the information
in CF800.BLK available that I can read on a non-Forth system? Is
this executable code? How do I run it? There is a CFDOS.EXE
program that, I guess, runs under Microsoft DOS. Why do we need
that? I want to avoid virus infested frequently crashing
Microsoft systems. Doesn't Colorforth run stand alone? Can I
read about what is going on without switching computers and
operating systems, making floppy disks, and finding incompatibilities?

       My Wintel PC's are gathered from my neighbor's trash,
where they belong. I make one or two good ones out of the parts
from two or three that don't work. Its unfortunate that so many
people pay so much money for them when they are new.

> >        Now let me point out something of great concern to me.
> > You state "It can be made to run on any PC." I would like to run
> > it off a hard drive on my 80486 based computers with one to
> > eight megabytes of memory, and an 800x600 or 640x480 video
> > display. Certainly anyone with the ability to reverse engineer
> > compiled code or understand uncommented Wintel-PC assembly
> > language can make the necessary changes.

> No reverse engineering is neccessary - all MASM ( or NASM ) assembler
> source is downloadable, from the original authors' sites - I don't
> support that on my site although I do have archives if you get stuck.
> The rest is colorForth.

       Reverse engineering is not necessary, but it is
sufficient. I'm still trying to find out what is necessary.

> > In my opinion, needing to know that [reverse engineering of
> > compiled code] would be a reason to say that it can't be made
> > to run on any PC.

> In the sense that not knowing your pin number means that you can't
> get cash from an ATM?

      You pick your pin number when you open a bank account or
use the ATM for the first time. Where do you find the magic
numbers for using low level Forth on all the various computers
it could fit on? Where do you insert these numbers in the source?

> I think it is easier to find a PC that the default colorForth works on,
> rather than spend the time customising it for a specific one. But
> if you do, please let me have the code and I will add a CF486.BLK
> to the list... ;)

        Yes, that is a sign of severe problems. Adding a
CF486.BLK file would be no help even if I knew how to write it.
Having source code that told me what I needed to change when I
read it is what I want.

> > If there existed a write-up that documented how
> > such changes could be made by a programmer of ordinary ability,
> > then the situation would be totally different.

> This would indeed be very useful...

         I wouldn't call it useful, I'd call it essential.

> The colorForth kernel is about 2K bytes, and is created from three asm
> files, totalling about 83K.
> The parts that have to be changed for different displays and floppy
> chips is actually quite small, and is lightly documented in the asm files.
> This is work in progress, and one of the main colorForth projects is to
> port it colorForth. This will make it much easier to document.

      I vote for it being heavily documented, both in the source
listing and in whatever write-ups the Colorforth system hackers
care to provide. Some of the best commented code I've ever seen
was written in assembly. Some of the worst was also written in
assembly. Its not a matter of what language you use, its a
matter of how important the programmer thinks documentation is.

> > Until that documentation exists, Colorforth can be just a source of
> > frustration for most people who might want to use it.

> Please direct your frustration at the reasons why we do not have
> a 32 bit BIOS on a 32 bit platform, and lack of support in the 16 bit
> BIOS that is provided for anything that might allow people to compete
> with Windows.... :(
 
      That is a different topic. If Colorforth gets to be a good
tool for lively BIOS hackers, then we'll have 32 and 64 bit
Forth based BIOS's for various motherboards. But if Colorforth
programmers have to spend so much time pondering the workings of
Colorforth, they will have no time to discover the bugs and
features of chipsets.

> To sum up : colorForth does not come shrink wrapped!
> PC hardware seems to be converging. Originally the PC's open
> architecture allowed competition between manufacturers, and
> hardware was often made different to hinder competitors. But now
> there are fewer manufacturers, and a tendency to stick to proven
> interfaces to avoid having to re-write the BIOS.
> AGP graphics for example, is memory mapped, so the problem just
> becomes finding out where the BIOS has mapped it to. The old PC
> hardware such as UARTS, timers, speaker and even Ethernet cards
> are almost always mapped to the same hardware addresses. Sound
> cards are a different story though.
> I have been pleasantly suprised by how many PCs colorForth will
> work on.

     I have been annoyed that Colorforth will not work on so
many old PC's where it would comfortably fit. Having it run on
Giga* machines (giga hertz clocks and giga byte ram) off a
floppy disk and not a hard disk is really weird. 

      Somewhere there is information on how to get all the above
hardware working together. Is it written for Forth programmers
or other people? It certainly would be a lot of effort to put
all the necessary information in one place for non-specialists
to find it. There will be a Forth programmer who will find that
information when he needs it. But if he isn't interested in
doing the write-up to make things easier for the next Forth
programmer, then that sort of programming will be done in other languages.

--
Michae Coughlin    m-coughlin@comcast.net   Cambridge, MA USA

Joachim Merkel wrote:

[snip]

> Take a look at:
> 
> comp/lang/forth, 97/07/27
> from: jfox@dnai.com  (Jeff Fox)
> subj: Chuck's presentation
> sorry, no MID, but I can post the text to you.
> 
> --------------------------------zip---------------------------------
> On Saturday July 26 1997 Chuck Moore gave a presentation to the
> Silicon Valley Chapter of the Forth Interest Group.
> [...]
> 
> Charles Moore:
> 
> [...]
> The medium of interchange is ideas not code.  Tell me how you did a
> heap sort, don't give me your code.  I have objected to Forth
> Dimension's pages and pages of source when one block has the key
> definition.  It just makes it harder to find what I want to know.
> I won't use your code anyway I will rewrite it.
> 
> [...]
> One year ago I encouraged everyone to write their own OKAD.  Since
> you didn't do that I don't feel guilty.  I assure you that I am
> now on the right track and I encourage you to experiment with
> color Forth.
> [...]
> --------------------------------zap-------------------------------
> 
> Members of Deutsche Forth Gesellschaft e.V. translated that report
> to the German "Vierte Dimension" as a title-story.
> Thanks to Jeff Fox again.

      I only met Chuck Moore once and have only read a small
part of what he has created. But I see a pattern that not
everyone notices. Chuck is very much interested in writing code
but cares little for writing documentation, particularly the
type of documentation called source code commenting. This was
the way programming was done when I first learned it in the
1960's. By the 1980's there was a change in attitude by some
programmers to emphasize the importance of documentation thru
commenting. That interest has died down lately, but is still
expressed by troublemakers such as myself.

      The way Chuck Moore works is to avoiding documentation of
code. This has the good effect of producing the minimum amount
of code. This has the bad effect of only the original programmer
knowing what the code does. The way Forth itself works has this
same quality.  Its part of its style. When the goal is to write
only code and nothing in text, there is a need for the
programmer to memorize everything about his programs. Perhaps if
Chuck Moore spent much effort at documentation, he would not
create the interesting collection of ideas we call Forth. 

       Now we are faced with the problem of how to understand
what Chuck Moore is doing. The problem is clearly shown in the
above quote. We need the ideas, not code. We need to be told how
Chuck's current systems work. The members of the Silicon Valley
fig chapter can not write their own OKAD if they do not
understand OKAD. The problem of understanding Forth code is
unsolved. Chuck say so directly above in his remarks about the
defunct magazine "Forth Dimensions". Lets not spend too much
time reading and writing about whether Chuck writes only for
himself or not, lets spend more time finding ways to write
programs our own way and at the same time make them easy for
others to understand. For me that means writing lots of comments
in the elaborate style of the 1980's, not keeping information
only in my head, and avoiding the murky tricks of the 1960's.
This is completely un-Forth like, and Forth programmers tell me
so in many different ways whenever I mention it. 

--
Michael Coughlin   m-coughlin@comcast.net   Cambridge, MA USA

m-coughlin wrote:
> Joachim Merkel wrote:
>>On Saturday July 26 1997 Chuck Moore gave a presentation

>>[...]

>>The medium of interchange is ideas not code.  Tell me how you did a
>>heap sort, don't give me your code.  I have objected to Forth
>>Dimension's pages and pages of source when one block has the key
>>definition.  It just makes it harder to find what I want to know.
>>I won't use your code anyway I will rewrite it.


> Lets not spend too much
> time reading and writing about whether Chuck writes only for
> himself or not, lets spend more time finding ways to write
> programs our own way and at the same time make them easy for
> others to understand. For me that means writing lots of comments
> in the elaborate style of the 1980's, not keeping information
> only in my head, and avoiding the murky tricks of the 1960's.

That sounds like it wouldn't be good documentation for Chuck.  Chuck 
would want to know about the essential ideas.  And so would I.

Traditional commenting tells you stuff about every tree in the forest. 
But I'd rather start out with a map that shows the peaks and the 
drainage and the roads.  I can find out about the individual trees when 
I need to.  That sense of "What's going on here?" is vital.

Hi Petrus,

"Petrus Prawirodidjojo" <petrusp@attglobal.net> wrote in message
news:mailman.9.1068909856.3110.comp.lang.forth@ada-france.org...
>
[snip]
> > To C++? Or have I missed something?
>
> What I meant is that most C (or C++ or Java or C#) programmers write
> applications and they are not modifying the C again and again. While most
> Forth programmers are busy improving their Forth system, including me of
> course. Kind of have fun with the tools and forget why the tools are made.
Forth is so simple that you can write your own, and change it. This is not
so easy with a C compiler, and quite difficult with a C++ compiler...
I haven't written my own Forth yet, because I haven't been able to improve
on the existing ones : from Forth, Inc., MPE, Chuck Moore and others too
numerous to mention.
One of the things that you can do with Forth is experiment with different
architectures - you can move different parts of the system around. If you
move the dictionary into the editor you get Holon, if you move the QUIT loop
into the editor and pre-parse the source you get colorForth etc. I am
fascinated by the implications of each style, and I try to share my
enthusiasm.

> One of the Forth problem is that it is fun to play with. And we are
allowed
> to change everything (to customize it). Now I am changing most variables
(@
> and !) with values (value and to).
Yes, Forth is fun!
Part of me likes values, but part of me doesn't. I like to think of every
word having just one action, and values have two, depending on a state
variable set by "to" . But I think for PC/Windows applications they are
useful.
Interestingly enough, in a state-free system like colorForth, values would
be quite difficult to implement. Where would the value that "to" changed be
kept? I think it would have to be in the source, like a magenta variable,
but with a more complex run-time action. I am currently working on a new
"blue class" which might work...

> With ColorForth, someone will go deeper. Worse than ANS Forth. Default is
> subset of DVORAK. Surely I will change that first if I want to use it.
Then
> the character set which is subset of ASCII. So I will not have time left
to
> write applications.
When I first started "playing" with colorForth I felt a strong desire to
change it to what I was used to. ASCII was a particular need that took a
long time to overcome, the QUIT loop also. But it is possible to program in
colorForth as it is, and only add what you need for your particular
application. Its a different mindset - we are all taught to make our code as
general as possible, to follow as many standards as possible, so ASCII ( or
UNICODE ) is essential. This comes from a fear that software is so difficult
that we must standardise it and solve every general problem. In fact
software can be simple, but it is difficult to make it simple.

The Dvorak keyboard is one example - every PC has QWERTY ( or similar ), and
it is very difficult to learn a new keyboard layout. In fact my typing speed
using the 27 keys after a week or two is about the same as QWERTY after 25
years - and will get faster. I think in 20 years ( maybe 120 ? ) people will
look back at the QWERTY keyboard in the same way as we view cars with
starting handles, or 5 inch round screen televisions. Its just not right,
but its the standard. Incidentally, I don't think we will be using voice
recognition, a la Star Trek or 2001 - its too public. I think that idea will
go the way of that dreadful talking car...  A _small_ keyboard is a better 1
to 1 interface.

> On the other side, "think big" move from ASCII to Unicode, where ASCII is
> subset of Unicode.
If I find an application that needs Unicode, I will add it. But I will think
about where I store the font data. The conventional way is in one or more
files, but if you have a network connection with transparent block transfer
I would probably use the font from the sender's machine, and just keep a
local cache. That way you will see exactly the same glyph as the sender
intended.

> > I know I fall into the "love" category, but I couldn't resist the
> temptation
> > to comment on this one point ;)
> I am surprised at your nice writing. I do not expect such a nice comment
> from the "love" group. Of course such a nice question/comment is welcome.
Thanks! I do not share Chuck's view that ANS Forth is a bad thing, perhaps
this is because I welcome the opportunity to program in any Forth rather
then C, C++ and friends. Being British, of course, I try to be polite ;)

What I would ask is that the science of computer programming is given the
respect it deserves and is treated as a science - hypotheses should be
tested against reality, not against the current fashion.
There are mainstream methodologies and programming languages that are
extremely complex. While this is good for job security, the technical
benifits are entirely unproven, and in my view illusory.

Regards

Howerd

----- Original Message -----
From: "Howerd Oakford" <howerd.oakford@ntlworld.com>
Newsgroups: comp.lang.forth
To: <comp.lang.forth@ada-france.org>
Sent: Tuesday, November 18, 2003 06:42
Subject: Re: The amazing ColorForth (was...)


> When I first started "playing" with colorForth I felt a strong desire to
> change it to what I was used to. ASCII was a particular need that took a
> long time to overcome, the QUIT loop also. But it is possible to program
in
> colorForth as it is, and only add what you need for your particular
> application. Its a different mindset - we are all taught to make our code
as
> general as possible, to follow as many standards as possible, so ASCII (
or
> UNICODE ) is essential. This comes from a fear that software is so
difficult
> that we must standardise it and solve every general problem. In fact
> software can be simple, but it is difficult to make it simple.

I have a book about 1 inch thick that only explain why ASCII is as we have
it now. Big companies fight to have their character set becomes standard. It
is already small, only 7 bit. Now ASCII is a subset of Unicode with high
byte zero.

If you write application, you may replace ASCII with any character set that
you like. But if you write a programming language, you may not do that.
Recently I write a program that send SMS through serial port to mobile
phone. The GSM mobile phone standard uses ASCII and optional Unicode. Of
course you can do it with ColorForth, but...

> The Dvorak keyboard is one example - every PC has QWERTY ( or similar ),
and
> it is very difficult to learn a new keyboard layout. In fact my typing
speed
> using the 27 keys after a week or two is about the same as QWERTY after 25
> years - and will get faster. I think in 20 years ( maybe 120 ? ) people
will
> look back at the QWERTY keyboard in the same way as we view cars with
> starting handles, or 5 inch round screen televisions. Its just not right,
> but its the standard. Incidentally, I don't think we will be using voice
> recognition, a la Star Trek or 2001 - its too public. I think that idea
will
> go the way of that dreadful talking car...  A _small_ keyboard is a better
1
> to 1 interface.

I agree that Dvorak is better than Qwerty. It is not that difficult to learn
Dvorak, but
-    I use 4 PCs everyday, so I have to change all of them to Dvorak layout
-    One of the PC is also used by my wife for internet
-    I sell computers and sometime I have to test the computers
-    I am not a writer (be it novel or textbook)
So, if I insist on using Dvorak, I can only change 3 computers. That means,
I have to switch my mind from Dvorak to Qwerty back and forth. From pseudo
crazy (using Dvorak in Qwerty society) I will become true/really crazy.

Regards,
Petrus-Pet4th.

"Petrus Prawirodidjojo" <petrusp@attglobal.net> wrote in message news:<mailman.8.1068855254.3110.comp.lang.forth@ada-france.org>...
> ----- Original Message -----
> From: "Mark Slicker" <maslicke@oakland.edu>
> Newsgroups: comp.lang.forth
> To: <comp.lang.forth@ada-france.org>
> Sent: Saturday, November 15, 2003 04:27
> Subject: Re: The amazing ColorForth (was...)
> 
> 
> > > John, do you know why some people love ColorForth so much? I am curious.
>  I
> > > already knew their answer and I will not ask them.
> >
> > I'm curious, what is "our" answer?
> 
> "Your" answer would be like:
> - Color is better than b/w
The guy who answered you that was not serious.

> - ASCII is not needed
The guy who answered you that was not serious.
> - QWERTY keyboard layout is inferior
The guy who answered you that was not serious.
> - File system is not needed
The guy who answered you that was not serious.

> - Small size, diskette size
> - Fast 10x 25x 100x 1000x
> - Simple not complex
> - ColorForth is the modern Forth, while ANS Forth is still based on old
> Forth 83
> 
> Those technical advantage is for a new device and embedded (small) system.

no, that's for everyone. Don't you want to shorten you development
times?

> That is if we could (afford to) discard old keyboards, discard old people
> who accustomed to the keyboard. A truly "think small" philosophy. Focus on

Think simple. Small and fast generally comes along.

> the detail. And much work to reinvent the wheel.
> 

Tu use the right wheel or to be the one fitted to the tracks leading
to the place you wnat to go.

 Amicalement,
  Astrobe

jonah thomas wrote:
> 
> m-coughlin wrote:
> > Joachim Merkel wrote:
> >>On Saturday July 26 1997 Chuck Moore gave a presentation
> 
> >>[...]
> 
> >>The medium of interchange is ideas not code.  Tell me how you did a
> >>heap sort, don't give me your code.  I have objected to Forth
> >>Dimension's pages and pages of source when one block has the key
> >>definition.  It just makes it harder to find what I want to know.
> >>I won't use your code anyway I will rewrite it.
> 
> > Lets not spend too much
> > time reading and writing about whether Chuck writes only for
> > himself or not, lets spend more time finding ways to write
> > programs our own way and at the same time make them easy for
> > others to understand. For me that means writing lots of comments
> > in the elaborate style of the 1980's, not keeping information
> > only in my head, and avoiding the murky tricks of the 1960's.
> 
> That sounds like it wouldn't be good documentation for Chuck.  Chuck
> would want to know about the essential ideas.  And so would I.
> 
> Traditional commenting tells you stuff about every tree in the forest.
> But I'd rather start out with a map that shows the peaks and the
> drainage and the roads.  I can find out about the individual trees when
> I need to.  That sense of "What's going on here?" is vital.

     I'm not interested in "traditional" commenting. I want
commenting that tells me what's happening at all levels. I don't
see anything like that for Colorforth. I can go off to the
library and find books about forests, books about trees and
contour maps for hikers. When I look for information on
Colorforth, all I find is a little bit of an outline for an
outline. The comments in the shadow blocks are only a help for
people who think reverse engineering is recreation. How do you
get that sense of "What's going on here?" for Colorforth? 

--
Michael Coughlin    m-coughlin@comcast.net   Cambridge, MA USA

On Fri, 21 Nov 2003 15:40:09 GMT, m-coughlin <m-coughlin@comcast.net>
wrote:

>How do you
>get that sense of "What's going on here?" for Colorforth? 
A few months ago I spent a day or two with it. The best
introduction is the MASM source code, which is frustrating
but brilliant.

Stephen
--
Stephen Pelc, stephenXXX@INVALID.mpeltd.demon.co.uk
MicroProcessor Engineering Ltd - More Real, Less Time
133 Hill Lane, Southampton SO15 5AF, England
tel: +44 (0)23 8063 1441, fax: +44 (0)23 8033 9691
web: http://www.mpeltd.demon.co.uk - free VFX Forth downloads

Hi Michael,

"m-coughlin" <m-coughlin@comcast.net> wrote in message
news:3FBE31FE.EF08B1BA@comcast.net...
[snip]

> How do you
> get that sense of "What's going on here?" for Colorforth?
By running it and writing applications.

ColorForth is very, very simple.
Lots of little bits of code doing "exactly what it says on the tin" ( to
quote a popular UK advertisment ).

There is edit time when you type code into a block, then compilation time
when you run "load", and execution time when you run one of the words
defined in the block that you just loaded.

There is the possibility to compile at run-time, and run at compile time, or
run at edit time, or edit at run time. The distinction is not as clear as it
is with any other language. This is because there is no global state - the
"colour" of each token determines what it will do, so you can mix and match
immediate words and compiling words or editing words in any way you like.
It works exactly like any other Forth, but does it in a simpler way. This
simpler way allows new possibilities.

If you try to describe the "big picture" of a conventional Forth system you
would probably explain how the QUIT loop searched a linked list dictionary,
decided whether it knew the word, was a number, or would type "?". And how
ASCII characters are collected in a TIB and parsed etc etc.
But in colorForth there is no QUIT loop, no TIB, no linked list dictionary,
and no ASCII.

What I have learned from colorForth is that the mainstream approach of
trying to contain complexity by wrapping it in complex software with a
simple API, is fundamentally flawed. The alternative approach of removing
complexity, produces a different set of problems, and the opportunity to
solve them in different ways.

Maybe that's "what's going on here" ;)

Regards

Howerd

> --
> Michael Coughlin    m-coughlin@comcast.net   Cambridge, MA USA

m-coughlin wrote:

>      I'm not interested in "traditional" commenting. I want
> commenting that tells me what's happening at all levels. I don't
> see anything like that for Colorforth. I can go off to the
> library and find books about forests, books about trees and
> contour maps for hikers. When I look for information on
> Colorforth, all I find is a little bit of an outline for an
> outline. The comments in the shadow blocks are only a help for
> people who think reverse engineering is recreation. How do you
> get that sense of "What's going on here?" for Colorforth? 

Would you give us a link to example code that you have commented the way 
you want?

jonah thomas wrote:
> 
> m-coughlin wrote:
> 
> >      I'm not interested in "traditional" commenting. I want
> > commenting that tells me what's happening at all levels. I don't
> > see anything like that for Colorforth. I can go off to the
> > library and find books about forests, books about trees and
> > contour maps for hikers. When I look for information on
> > Colorforth, all I find is a little bit of an outline for an
> > outline. The comments in the shadow blocks are only a help for
> > people who think reverse engineering is recreation. How do you
> > get that sense of "What's going on here?" for Colorforth?
> 
> Would you give us a link to example code that you have commented
> the way you want?

    I've never written a program for publication. I've written
programs for people who asked me to write a program and given me
the mathematical equations they wanted me to use. Writing decent
comments was not even a requirement. The answers the program
produced were the product, not the program itself. When the
program is the product and people who use it might not
understand the theory behind it, then you have a situation
completely different from what I ever worked on. I only have the
opinions of those who have worked in such situations to go by
and no direct experience as to how well or poorly their examples
work out in practice.

    Badly commented code is all over the place, and its even
possible to find bad instructions for commenting code, like at
http://java.sun.com/docs/codeconv/html/CodeConventions.doc4.html

    A much better short set of instructions, typical of what is
taught in computer courses, can be found at

http://myhome.spu.edu/tbuiten/1230/style.asp

Begin quote --
Programs turned in for grading must conform to the following
standards: 

  1. Begin each program with a comment block containing: 
             Your name 
             Your class (CSC 1230, Fall 2002) 
             The assignment number 
             The due date 
             A brief description of the problem to be solved 
  2. Your C++ code should have the following features: 
     Use indentation to show the structure of the code (if,
while, for, switch, do-while, body of a function).  Use the
indentation styles as demonstrated in your textbook. 
    Indent comments to match the lines of code to which they
refer. 
    Do not over-comment or under-comment; the coded instructions
should be recognizable and not hidden in comments. 
    Comment as you go rather than trying to put in all your
comments after your  program is written. 
    A good test of the amount of commenting is to hand your
program to a friend and see if they can figure out what your
program does.
    Use meaningful identifier names (in lower case) 
    Put all constant identifiers in UPPER CASE 
    Use function prototypes; place them before main() 
    Place all user-defined function definitions after main() 
End quote.

    You can't find a good listing when you want to. You only find
them when you are looking for something else. I once was looking
for information about metal oxide varistors for voltage
transient suppression on AC power lines and I found a nice
listing for an assembly language program when I included MOV in
a search expression for Google. I tried it again, and just found
this --
http://www.ustr.net/files/i2cbits.asm   
It is assembly language but it follows the instructions for the
C++ class.
I also found several pages with code that did not follow the
above convention and even something about transient voltage suppressors.

    An early essay on good programming style is in "The Mythical
Man-Month" by Federick Brooks. Unfortunately it is chapter 15,
in the back of the book, and very few people seem to get that
far, even tho this book is very popular and widely available.
See fig 15.3 on page 173 (in the first edition) to see what a
self-documented program really looks like. It is as radically
different from the usual style of writing as Forth is from other
computer languages. I first came across these ideas in the book
"Fortran with Style, Programming Proverbs" by Henry Ledgard and
Louis Chmura. Nowadays we have new terms and discussions of the
topic, such as "literate" programming. But it is all just a
variation on "A good test of the amount of commenting is to hand
your program to a friend and see if they can figure out what
your program does."

    How does a program listing pass that test? We don't even
have many programmers who know the test needs to be made, let
alone find ways to do it. I was once invited to a job interview
by mistake. Before the boss apologized for wasting my time and
sending me home, I noticed the program listings stacked up in
piles. They looked like they were written by Fred Brooks and
Henry Ledgard. So I know there are some projects that do take
commenting style seriously, even tho I've never worked on any. 

    Chuck Moore has stated he does not write the style of
comments used in http://www.ustr.net/files/i2cbits.asm or the
above books. Colorforth shows that. There are only a handful of
people who can make Colorforth work. I'm not one of them. I
can't even see his code or shadow screens displayed on any of my
computers. I'd like to be the first one to write an
understandable Colorforth listing as an example of adequate
commenting, but life is too short. I'll have to leave it to
someone else who understands the innards of Intel 80x86 CPU's
and PC BIOS's. Maybe it will never happen.

--
Michael Coughlin    m-coughlin@comcast.net    Cambridge, MA USA

m-coughlin <m-coughlin@comcast.net> wrote:

>     You can't find a good listing when you want to. You only find
> them when you are looking for something else. I once was looking
> for information about metal oxide varistors for voltage
> transient suppression on AC power lines and I found a nice
> listing for an assembly language program when I included MOV in
> a search expression for Google. I tried it again, and just found
> this --
> http://www.ustr.net/files/i2cbits.asm   
> It is assembly language but it follows the instructions for the
> C++ class.

This is classical student commenting.

          PUSH    ACC            ;Save accumulator

....

          POP     ACC            ;Restore accumulator

An important rule of commenting is "You are not writing a tutorial, so
do not add comments that are obvious to someone skilled in the art.
They only waste the time of the reader."

Andrew.

andrew29@littlepinkcloud.invalid wrote:
> An important rule of commenting is "You are not writing a tutorial, so
> do not add comments that are obvious to someone skilled in the art.
> They only waste the time of the reader."

This is exactly what I've thought Michael wants when talking about
"documentation": a tutorial that explains in plain english what's going on
on the left side. A sort of "rosetta stone" for computer illiterates.

You find this sort of "student's comments" for all languages taught at
universities, because that's where students work. You won't find it for
Forth programs.

Michael, you have to learn a language *before* you can read programs written
in that language. Really. And even more, you ought to lean a language
before you can *write* programs in that language. A lot of assembler
programmers ignore that and read comments and write assembly language by
writing comments and hoping that the code they wrote on the left side
actually matches the intent stated on the right side. That's why assembler
is such a difficult language, with such a high bug-count per line. People
are lulled into a false feeling of understanding.

Michael often says something like that computer languages are not to be read
by humans, comments are. That's wrong - computer languages are
intentionally created to be read by both humans and computers, they are an
interface between man and machine. Due to their nature, they don't resemble
human languages, which are created (or have been evolved) for communication
between humans.

-- 
Bernd Paysan
"If you want it done right, you have to do it yourself"
http://www.jwdt.com/~paysan/

Bernd Paysan <bernd.paysan@gmx.de> wrote:

> Michael often says something like that computer languages are not to
> be read by humans, comments are. That's wrong - computer languages
> are intentionally created to be read by both humans and computers,
> they are an interface between man and machine.

Precisely.  The Rosetta Stone is a good analogy.

> Due to their nature, they don't resemble human languages, which are
> created (or have been evolved) for communication between humans.

Well, I'm not sure about that.  Computer languages are sometimes like
mathematical notation, which eveloved precisely for communication
between humans.

Andrew.

m-coughlin wrote:
> jonah thomas wrote:
>>m-coughlin wrote:

>>>     I'm not interested in "traditional" commenting. I want
>>>commenting that tells me what's happening at all levels. I don't
>>>see anything like that for Colorforth. I can go off to the
>>>library and find books about forests, books about trees and
>>>contour maps for hikers. When I look for information on
>>>Colorforth, all I find is a little bit of an outline for an
>>>outline. The comments in the shadow blocks are only a help for
>>>people who think reverse engineering is recreation. How do you
>>>get that sense of "What's going on here?" for Colorforth?

>>Would you give us a link to example code that you have commented
>>the way you want?

>     I've never written a program for publication. 

I see.  So you're like a *consumer* of documentation, and you're telling 
us what you want like a user writing specs.

>     Badly commented code is all over the place, and its even
> possible to find bad instructions for commenting code, like at
> http://java.sun.com/docs/codeconv/html/CodeConventions.doc4.html

>     A much better short set of instructions, typical of what is
> taught in computer courses, can be found at

> http://myhome.spu.edu/tbuiten/1230/style.asp

> Begin quote --
> Programs turned in for grading must conform to the following
> standards: 

>   1. Begin each program with a comment block containing: 
>              Your name 
>              Your class (CSC 1230, Fall 2002) 
>              The assignment number 
>              The due date 
>              A brief description of the problem to be solved 
>   2. Your C++ code should have the following features: 
>      Use indentation to show the structure of the code (if,
> while, for, switch, do-while, body of a function).  Use the
> indentation styles as demonstrated in your textbook. 
>     Indent comments to match the lines of code to which they
> refer. 
>     Do not over-comment or under-comment; the coded instructions
> should be recognizable and not hidden in comments. 
>     Comment as you go rather than trying to put in all your
> comments after your  program is written. 
>     A good test of the amount of commenting is to hand your
> program to a friend and see if they can figure out what your
> program does.
>     Use meaningful identifier names (in lower case) 
>     Put all constant identifiers in UPPER CASE 
>     Use function prototypes; place them before main() 
>     Place all user-defined function definitions after main() 
> End quote.

>     You can't find a good listing when you want to. You only find
> them when you are looking for something else. I once was looking
> for information about metal oxide varistors for voltage
> transient suppression on AC power lines and I found a nice
> listing for an assembly language program when I included MOV in
> a search expression for Google. I tried it again, and just found
> this --
> http://www.ustr.net/files/i2cbits.asm   
> It is assembly language but it follows the instructions for the
> C++ class.
> I also found several pages with code that did not follow the
> above convention and even something about transient voltage suppressors.

>     An early essay on good programming style is in "The Mythical
> Man-Month" by Federick Brooks. Unfortunately it is chapter 15,
> in the back of the book, and very few people seem to get that
> far, even tho this book is very popular and widely available.
> See fig 15.3 on page 173 (in the first edition) to see what a
> self-documented program really looks like. It is as radically
> different from the usual style of writing as Forth is from other
> computer languages. I first came across these ideas in the book
> "Fortran with Style, Programming Proverbs" by Henry Ledgard and
> Louis Chmura. Nowadays we have new terms and discussions of the
> topic, such as "literate" programming. But it is all just a
> variation on "A good test of the amount of commenting is to hand
> your program to a friend and see if they can figure out what
> your program does."

>     Chuck Moore has stated he does not write the style of
> comments used in http://www.ustr.net/files/i2cbits.asm or the
> above books. Colorforth shows that. There are only a handful of
> people who can make Colorforth work. I'm not one of them. I
> can't even see his code or shadow screens displayed on any of my
> computers. I'd like to be the first one to write an
> understandable Colorforth listing as an example of adequate
> commenting, but life is too short. I'll have to leave it to
> someone else who understands the innards of Intel 80x86 CPU's
> and PC BIOS's. Maybe it will never happen.

I'll give it a try when I have the free time for it.

Part of the problem is that what you need is an explanation of 
ColorForth as an operating system, and you also need an explanation of 
ColorForth as a language.  Once you can read the language the "tree" 
level pretty much explains itself.  No long definitions.  Line by line 
comments would only get in the way, they'd only tell you what you can 
read in the code, but clumsier.

What's missing is the sense of how it all fits together. That might be 
an interesting challenge.

m-coughlin wrote:

>     Badly commented code is all over the place, and its even
> possible to find bad instructions for commenting code, like at
> http://java.sun.com/docs/codeconv/html/CodeConventions.doc4.html
> 

It would appear that these instructions are demonstrating the comment 
syntax of the language, not an example of how to comment java code.

m-coughlin <m-coughlin@comcast.net> wrote in message news:<3FC6AF37.74992DF3@comcast.net>...
> I
> can't even see his code or shadow screens displayed on any of my
> computers.

Yay, I finally have an answer to your incessant whining. The blocks
for Chuck's colorForth can be found in HTML here:

http://www.merlintec.com/download/color.html

You can now go on to complain how you couldn't find such critical
information on Chuck Moore's website.

I don't mean to be negative, but it helps to show some initiative, not
everything new and experimental can be handed to you and others on a
silver platter.

Mark

maslicke@oakland.edu (Mark Slicker) wrote in message news:<4c45abad.0311281843.7b433ae3@posting.google.com>...
> Yay, I finally have an answer to your incessant whining. The blocks
> for Chuck's colorForth can be found in HTML here:
> 
> http://www.merlintec.com/download/color.html

Thanks for posting this. Some of us either don't have machines 
with floppy drives or don't have machines we can dedicate to 
such experiments.

> I don't mean to be negative, but it helps to show some initiative, not
> everything new and experimental can be handed to you and others on a
> silver platter.

At the risk of seeming negative myself, have you examined that code?
Yee Gods! Writing code like this:

png awh d @ / h ! d @ / w ! wd swap 474E5089 , A1A0A0D , ihdr 52444849
13 bys w @ . h @ . 304 , 0 1, crc plte idat 54414449 0 bys swap
deflate crc iend 444E4549 0 bys crc wd over negate + ;

or this:

cf-ii string 6F747200 , 696E6165 , 79636D73 , 7766676C , 62707664 ,
71757868 , 336A7A6B , 37363534 , 2D313938 , 2F322E30 , 2B213A3B ,
3F2C2A40 ,
ch 7FFFFF0 and unpack cf-ii + 1@ FF and ;

wouldn't pass muster in a first-year programming course, much less 
be accepted in a commercial shop. Heck, the date code doesn't even 
include the year.

And to think they used to crucify C programmers for comments such 
as "Tricky" and "Does what it says."

Tyler

"Tyler" <nlper@junglemate.com> wrote in message
news:65d29696.0311291707.68db0cb1@posting.google.com...
> At the risk of seeming negative myself, have you examined
> that code? Yee Gods! Writing code like this:
>
> png awh d @ / h ! d @ / w ! wd swap 474E5089 , A1A0A0D ,
> ihdr 52444849 13 bys w @ . h @ . 304 , 0 1, crc plte idat
> 54414449 0 bys swap deflate crc iend 444E4549 0 bys crc
> wd over negate + ;

In the ColorForth community, there seems to be an odd sort of "software
machismo" going on.  Much of the code I've seen for ColorForth features both
a lack of comments and a reliance on magic constants sprinkled through the
code.  And when this criticism is brought up, more often than not the
response is, "well, ColorForth is for *real* programmers."  As if proper
documentation skills are merely a crutch for lesser programmers and that
"real" programmers enjoy solving puzzles rather than reading code.

(Charles Moore laments on www.colorforth.com that "[...] user interfaces
feature puzzle-solving."  So in accordance with his philosophy of early
binding, he moves the puzzle-solving from run-time to edit-time!)

> or this:
>
> cf-ii string 6F747200 , 696E6165 , 79636D73 , 7766676C ,
> 62707664 , 71757868 , 336A7A6B , 37363534 , 2D313938 ,
> 2F322E30 , 2B213A3B , 3F2C2A40 , ch 7FFFFF0 and
> unpack cf-ii + 1@ FF and ;
>
> wouldn't pass muster in a first-year programming course,
> much less be accepted in a commercial shop.

I really, really, really want to believe that the poor documentation and
reliance on magic constants I've seen in so much ColorForth code so far is
simply due to the relative newness of the language.  I would imagine that in
every language, there is a settling period where programmers learn what
works and what doesn't.  Lots of people have *used* ColorForth, but only one
person so far has managed to create a significant application with it.
Right now, I think most who code in ColorForth are taking their examples
from Charles Moore, who doesn't need to comment anything since he built the
system from the ground-up and has the entire design in his head.  For those
of us who don't have "Charles Moore" on their driver's license, following
his example might not be the best thing to do.

"John Passaniti" <nntp@JapanIsShinto.com> wrote in message
news:21cyb.2154$Uz7.623@news02.roc.ny...
>
> "Tyler" <nlper@junglemate.com> wrote in message
> news:65d29696.0311291707.68db0cb1@posting.google.com...
> > At the risk of seeming negative myself, have you examined
> > that code? Yee Gods! Writing code like this:
> >
> > png awh d @ / h ! d @ / w ! wd swap 474E5089 , A1A0A0D ,
> > ihdr 52444849 13 bys w @ . h @ . 304 , 0 1, crc plte idat
> > 54414449 0 bys swap deflate crc iend 444E4549 0 bys crc
> > wd over negate + ;
>
> I really, really, really want to believe that the poor documentation and
> reliance on magic constants I've seen in so much ColorForth code so far is
> simply due to the relative newness of the language.

Is it possible, John, that even you are more optimistic about ColorForth
than I am? I don't see it having any future, except as the answer to "What
is Chuck Moore doing these days?" The remarks I see in its defense -- it
strips out the layers, it requires you to understand your computer -- echo
what Linux partisans were saying 7 years ago, and are just as irrelevant to
reality. Linux had the Unix code legacy to sustain it. ColorForth has no
such legacy. Nobody is going to be able to write readable code in ColorForth
that achieves the same efficiencies Moore does, because he gets the
efficiencies precisely by sacrificing readability.

M.

"Myles" <a@b.c> wrote in message news:bqc4ui$2ea$1@news.Stanford.EDU...
> Is it possible, John, that even you are more optimistic about
> ColorForth than I am? I don't see it having any future, except
> as the answer to "What is Chuck Moore doing these days?"

I guess I'm more optimistic about ColorForth, but my optimism comes in a
different form.  When I look at ColorForth, I'm not concerned with the
surface details-- the so-called early binding, the character set, Huffman
compression, keyboard layout, or the primitives Charles Moore chose.  While
all interesting, that to me doesn't seem to be the "message" that
underscores ColorForth.

For me, the message is that programmers can build their own language and
runtime environment that is tuned to their work and the nature and
capabilities of their hardware.  They don't have to accept the limitations
of a more generalized language-- they can build in exactly the features they
need and not worry about compromises.  And there are other messages too-- 
keep it simple, keep it small, keep it specific to your needs-- that is
repeated not only in the larger Forth community, but also in lots of other
communities (for example, the Extreme Programming community).

Unfortunately, taking this message to heart means that ColorForth doesn't
have much of a future itself.  A message of being the creator of your own
language and runtime environment means that one shouldn't accept the
limitations of *any* language-- including ColorForth.

Much of the work I do is on 8-bit microcontrollers.  And for me, I can
easily see building a ColorForth-like environment.  But since I have
different needs from Charles Moore, I would choose a different character set
and thus a different technique for representing strings.  And since my
hardware doesn't have video display capabilities, I would likely choose a
form of the language that didn't use color but rather inline tokens so they
could be easily represented over a simple serial channel.  And there would
be other changes too, that are more geared to my personal needs and
sensibilities as to what makes me most productive.  For example, I'm getting
more into and very excited by the Joy language, and would likely seek to
implement some of the features from that.

I believe people will continue to play with ColorForth, and eventually,
someone (aside from Charles Moore) is going to make a significant
application in it.  And when they do, they're going to find aspects of the
environment they find lacking, and so they'll add those features.  And when
that happens, there will be two major forks of ColorForth.  Then, more
people will use both forks, more applications will be made, and again, there
will be additional forks.  This will continue until people realize that
ColorForth as an implementation simply doesn't matter-- what matters is the
model ColorForth offers as a way to create a custom language and runtime
environment.

Mark Slicker wrote:

> I hear the repeated insistence that colorForth has no "significant
> applications". Take my jpeg decoder.

Can we download your jpeg decoder?

Jos

==
4ePost: 178 bytes in mail. Elapsed time to buffer: .000241 sec.

nlper@junglemate.com (Tyler) wrote in message news:<65d29696.0311291707.68db0cb1@posting.google.com>...
>
> or this:
> 
> cf-ii string 6F747200 , 696E6165 , 79636D73 , 7766676C , 62707664 ,
> 71757868 , 336A7A6B , 37363534 , 2D313938 , 2F322E30 , 2B213A3B ,
> 3F2C2A40 ,
> ch 7FFFFF0 and unpack cf-ii + 1@ FF and ;
> 
> wouldn't pass muster in a first-year programming course, much less 
> be accepted in a commercial shop.

What if the following were provided in the shadow block:
: cf-ii -a ( table which maps colorforth characters to ASCII
characters )
: ch w-wc ( unpack ASCII character from Huffman packed word )

Chuck left many of the shadow comments from the source code. No one is
claiming the the state of his documentation is perfect, though it
seems many have nothing better to do than repeatedly point out the
fact that is isn't. The idea of contributing documentation has
seemingly not occurred to these individuals.

Other than this I don't know what your expectation is. Michael's
expectation appears to be that colorForth should have been distributed
with it's own "Starting colorForth" book on how to program. Surely it
would a great thing to have but no one has put forth the effort. Your
other complaints, to paraphrase, "colorForth is not ANS Forth",
"colorForth is not Linux" are misplaced. To the latter, success of
this kind is not something that can be guaranteed or even fully
understood. To the former, if what you desire is groveling acceptance
of the status quo, you are best to stay with ANS Forth with perhaps
Mr. John Passaniti as your mentor.

I hear the repeated insistence that colorForth has no "significant
applications". Take my jpeg decoder. If it is not significant enough,
what is the expected difference in a "real application"? Chuck has
stated his OKAD is not a monolithic application, but a collection of
smaller applications each defining their own interaction. I suggest
that no one is prevented from creating a "significant application"
short of actually investing the labor to do so.

You have shown that your intention from the outset is to marginalize
colorForth. I think it is consistent with many of the other comments I
see here. I sugest to the entire group this is the true black eye that
has been given to Forth, the stangulation of any kind of diversity by
a small but vocal conservative minority. Prime evidence of this fact
is that people who actually use colorForth and generally experiment
with Forth have migrated to wholly seperate and moderated forums.

Mark

John Passaniti wrote:

> When I look at ColorForth, I'm not concerned with the
> surface details-- the so-called early binding, the character set, Huffman
> compression, keyboard layout, or the primitives Charles Moore chose.  While
> all interesting, that to me doesn't seem to be the "message" that
> underscores ColorForth.

> For me, the message is that programmers can build their own language and
> runtime environment that is tuned to their work and the nature and
> capabilities of their hardware.  They don't have to accept the limitations
> of a more generalized language-- they can build in exactly the features they
> need and not worry about compromises.  And there are other messages too-- 
> keep it simple, keep it small, keep it specific to your needs-- that is
> repeated not only in the larger Forth community, but also in lots of other
> communities (for example, the Extreme Programming community).

> Unfortunately, taking this message to heart means that ColorForth doesn't
> have much of a future itself.  A message of being the creator of your own
> language and runtime environment means that one shouldn't accept the
> limitations of *any* language-- including ColorForth.

That sounds good to me.  So the next step is, how do we make little 
niche languages and document them well enough that somebody else could 
step in and maintain our applications?  This doesn't *have* to be an 
issue.  100,000 lines of C might truly be no harder to maintain than 500 
lines that define a special-purpose language and 500 lines of code in 
that language.  But there's the problem that C programmers are perfectly 
happy to get the job of maintaining 100,000 lines of C code, and if it 
looks too hard they'll ask for an assistant.  While they and their 
managers tend to balk at unusual languages.

If ColorForth turns out to have an underlying structure that makes it 
easy to redesign and easy to understand, we could wind up with a large 
family of languages on that model.  Understand one of them and you're 
well on your way to picking up any other.  We're getting a lot of 
complaints that it isn't that easy to pick up.  But maybe it will turn 
out to be.  Or maybe some other model will work better.  Or it might be 
better to design new languages completely ad hoc to fit the current 
requirements.  Maybe for some market niches it will turn out more 
important to get something workable once than to have it maintainable. 
Fire and forget.  When the problem changes, accept that somebody else 
can do it over easier than they can modify what you did.

I don't know how it will go yet.  But there's surely no reason to accept 
the limitations of ColorForth.  Chuck doesn't.  When something in it 
looks like a limitation to him, he redesigns it.

Hi John,

"John Passaniti" <nntp@JapanIsShinto.com> wrote in message news:<21cyb.2154$Uz7.623@news02.roc.ny>...
> "Tyler" <nlper@junglemate.com> wrote in message
> news:65d29696.0311291707.68db0cb1@posting.google.com...
> > At the risk of seeming negative myself, have you examined
> > that code? Yee Gods! Writing code like this:
> >
> > png awh d @ / h ! d @ / w ! wd swap 474E5089 , A1A0A0D ,
> > ihdr 52444849 13 bys w @ . h @ . 304 , 0 1, crc plte idat
> > 54414449 0 bys swap deflate crc iend 444E4549 0 bys crc
> > wd over negate + ;
> 
> In the ColorForth community, there seems to be an odd sort of "software
> machismo" going on.  
ColorForth is difficult to learn, because it is different to anything
that one already knows. If the persistence required to do this is
"machismo", then I will take that as a compliment ;)

> Much of the code I've seen for ColorForth features both
> a lack of comments 
Appropriate documentation is essential...
 
> and a reliance on magic constants sprinkled through the
> code.
I take this to mean hexadecimal numbers. In mainstream computing,
having "magic numbers" in the code is considered to be a bad thing -
and quite rightly so.
What you see in colorForth are three diferent uses of hex numbers :

1. In character conversion tables. I think this usage is generally
accepted.

2. To represent processor op codes : it is difficult to avoid the hex
value used in an assembler mnemonic. Normally the assembler would be
kept "somehwere else", so you wouldn't have to read the hexadecimal.
In colorForth little bits of the assembler are created where they are
used.

3. To calculate constants at compile time, using the yellow-green
transition to compile a literal. This is a technique unique to
colorForth, AFAIK, which allows a value to be calculated and then
compiled.
A trivial example from block 44 :
: blks 256 * ;
: w/c [yellow]18 blks [green] ;
The "18 blks" is executed at [yellow=immediate] compile-time, then
compiled as a literal by the transition to [green]. This allows you to
control exactly when something happens. The value of the literal is
calculated where it is used.

Both 2 and 3 illustrate a particular style of programming, where
everything is kept locally, and everything happens at the correct
time. What you are seeing here is the complete absence of the layering
of an application into hardware/assembler/primitives/complex words.
Yes, this does _look_ wrong ;)

> And when this criticism is brought up, more often than not the
> response is, "well, ColorForth is for *real* programmers."  
Of course it is...

> As if proper
> documentation skills are merely a crutch for lesser programmers
As if!

> and that
> "real" programmers enjoy solving puzzles rather than reading code.
Have you ever thought of factoring your responses into logically
separate sentances?
 
> (Charles Moore laments on www.colorforth.com that "[...] user interfaces
> feature puzzle-solving."  
I didn't interpret Chuck's comments as a lament, more of an
observation.

> So in accordance with his philosophy of early
> binding, he moves the puzzle-solving from run-time to edit-time!)
Exactly!
 
> > or this:
> >
> > cf-ii string 6F747200 , 696E6165 , 79636D73 , 7766676C ,
> > 62707664 , 71757868 , 336A7A6B , 37363534 , 2D313938 ,
> > 2F322E30 , 2B213A3B , 3F2C2A40 , ch 7FFFFF0 and
> > unpack cf-ii + 1@ FF and ;
Note to Tyler : the above code is much easier to understand either in
colour, or converted to a monochrome format - the "ch" is in [red] and
starts on a new line. Probably got mangled by SMTP... it should read :

: cf-ii string 0x6F747200 , 0x696E6165 , 0x79636D73 , 0x7766676C ,
0x62707664 , 0x71757868 , 0x336A7A6B , 0x37363534 , 0x2D313938 ,
0x2F322E30 , 0x2B213A3B , 0x3F2C2A40 ,
: ch -0x10 and unpack cf-ii + 1@ 0xFF and ;

"string" compiles the value of HERE so that "cf-ii" returns the
address of the start of the character conversion table. Is this really
so difficult?

> > wouldn't pass muster in a first-year programming course,
> > much less be accepted in a commercial shop.
Of course not - its Forth.

> I really, really, really want to believe that the poor documentation and
> reliance on magic constants I've seen in so much ColorForth code so far is
> simply due to the relative newness of the language.  
Poor documentation certainly is due to lack of time, but what you call
"magic numbers" are probably not - see above...

> I would imagine that in
> every language, there is a settling period where programmers learn what
> works and what doesn't.  Lots of people have *used* ColorForth, but only one
> person so far has managed to create a significant application with it.
> Right now, I think most who code in ColorForth are taking their examples
> from Charles Moore, who doesn't need to comment anything since he built the
> system from the ground-up and has the entire design in his head.  For those
> of us who don't have "Charles Moore" on their driver's license, following
> his example might not be the best thing to do.
This is your opinion, I hold Chuck's code in very high regard, and I
beg to differ.

Regards

Howerd

"Howerd Oakford" <howerd.oakford@ntlworld.com> wrote in message
news:3d9354b2.0311301607.5f519377@posting.google.com...
> ColorForth is difficult to learn, because it is different to anything
> that one already knows. If the persistence required to do this is
> "machismo", then I will take that as a compliment ;)

I don't believe ColorForth is difficult to learn, just as I don't believe
Forth is difficult to learn.  The rules for both ColorForth and Forth are
simple.  If a professional programmer can't figure out ColorForth or Forth
in a few days of study, then they better look for other employment.

What is difficult about ColorForth and Forth isn't learning it.  What's
difficult is learning how to *effectively* use it.  There is a big
difference between knowing the syntax and semantics of a language and
knowing how to express a solution to a programming problem effectively.

> I take this to mean hexadecimal numbers. In mainstream
> computing, having "magic numbers" in the code is considered
> to be a bad thing - and quite rightly so.

Not quite.  It is considered a bad thing when it isn't documented.  If you
review the code I've written over the years, you'll find *lots* of magic
numbers scattered throughout without symbolic constants behind them.  What
you will see however is a comment in each case that describes the data.

> What you see in colorForth are three diferent uses of hex numbers :
>
> 1. In character conversion tables. I think this usage is
> generally accepted.

Yeah, as long as there is a simple comment somewhere.  It doesn't have to be
a "War and Peace" tome and it doesn't have to be a tutorial in the language.
But a simple comment like "ASCII conversion table" can only help.

> 2. To represent processor op codes : it is difficult to avoid the
> hex value used in an assembler mnemonic. Normally the
> assembler would be kept "somehwere else", so you wouldn't
> have to read the hexadecimal. In colorForth little bits of the
> assembler are created where they are used.

This is where I start to have a problem.  Here's a line of ColorForth source
code:

2! a! 28966 3, drop ; forth

This line was given a comment:

2! va- store 16-bit value at byte address

This comment answers the question of what the 2! word does.  But what if I
don't want to know what the word does, but how it does it?  I see a magic
constant of 28966 in there.  From this, I can assume that is likely an
opcode.  But what is it?  Now I get to go on a software scavenger hunt
figuring it out. Where did I put my X86 reference book?  Oh, here it is-- 
and here's a tab I added to the page just for decoding ColorForth code...

Wow, that was fun.  Now compare this to nearly every Forth I have ever used,
where a simple assembler was available (and for that matter, although it
isn't ANSI/ISO C, many C compilers also offer the same ability to inject
assembly language code inline).  Nearly every program in ColorForth I've
seen so far has machine code inserted in it, and that tells me that the
ability to drop the machine level is important to ColorForth programmers.
So if it is important, why has nobody written an assembler yet?  It's not
like assemblers are all that difficult or that models for creating simple
assemblers haven't been made in Forth.

Fine-- apparently nobody wants to write an assembler.  So why then the lack
of comments?  The ColorForth compiler will gleefully ignore inline comments.

This is an example of the useless "software machismo" that I see in
ColorForth.  The author of the above code could have easily injected a
comment saying what the opcode was, saving others the effort of looking it
up and allowing him to remember what he did when two years from now he
revisits the code.  But he doesn't, and in reviewing other ColorForth code,
nobody else does it.  Why?

> Both 2 and 3 illustrate a particular style of programming, where
> everything is kept locally, and everything happens at the correct
> time. What you are seeing here is the complete absence of the
> layering of an application into hardware/assembler/primitives/complex
> words. Yes, this does _look_ wrong ;)

No, it *is* wrong.  At least for the case of inline machine code, I can see
no value in injecting opcodes directly verses writing an assembler and
having it inject the same opcodes.  Hell, one could even do it entirely at
run-time giving the same effect as now, and leaving behind a simple comment.

An assembler doesn't fit in the philosophy of ColorForth?  Then the
"complete absence of layering" you are gushing about doesn't absolve the
programmer from commenting what is going on.

"Mark Slicker" <maslicke@oakland.edu> wrote in message
news:4c45abad.0311300342.3e2a8ffc@posting.google.com...
> nlper@junglemate.com (Tyler) wrote in message
news:<65d29696.0311291707.68db0cb1@posting.google.com>...
> To the former, if what you desire is groveling acceptance
> of the status quo, you are best to stay with ANS Forth
> with perhaps Mr. John Passaniti as your mentor.

Ironic.  I rarely use ANS Forth, and instead use a variety of homebrew Forth
and Forth-like languages.  I don't use ANS Forth because it isn't relevant
to my work.  My work actually is more in like with ColorForth in that I am
tuning the language to my needs, not that of a standards body's desire for
portability.

That being said, I respect ANS Forth because it gives programmers an option.
Options can be taken or ignored.

> I hear the repeated insistence that colorForth has no
> "significant applications". Take my jpeg decoder. If it is
> not significant enough, what is the expected difference
> in a "real application"?

I guess we all have our own personal thresholds for what is and isn't
significant.  Taking a well-known and well-documented algorithm and
implementing it in ColorForth to me doesn't seem very significant.  Would
your JPEG decoder been significant if you had coded it in assembler instead
of ColorForth?  What if you had coded it in C?

What does seem more significant to me is to build applications that involve
actual user interaction, where the user builds something with the
application (say for example, a drawing), the user manipulates it (say, by
transforming it in some way), and then the user saves their work.  Such an
application wouldn't need to be monolithic, and may certainly use components
like your JPEG decoder along the way.

Significance to me has to do with user interaction, not complexity.  And
part of the reason is that while the ColorForth environment may be fine for
programmers to work in, it is a hostile environment for end users-- 
presumably the people who will actually be using the applications created
with ColorForth.  That suggests to me that either ColorForth programmers
will force end users to use the same editor they do to interact with
applications, or they will create some kind of user interface.

> You have shown that your intention from the outset is to
> marginalize colorForth. I think it is consistent with many of the
> other comments I see here. I sugest to the entire group this is
> the true black eye that has been given to Forth, the stangulation
> of any kind of diversity by a small but vocal conservative minority.

I assume the above was addressed to "Tyler" and not me.  I in fact am all
for even more diversity than the ColorForth community seems to want, by
viewing ColorForth not as an implementation, but as a statement about
programmers creating their own individual and unique programming languages
and environments.

> Prime evidence of this fact is that people who actually use
> colorForth and generally experiment with Forth have migrated to
> wholly seperate and moderated forums.

Have fun there.  And do keep the rest of us informed when ColorForth
matures.  I'd love to see what happens to the language after more people
start to stress it and discover the weaknesses.

maslicke@oakland.edu (Mark Slicker) wrote in message news:<4c45abad.0311300342.3e2a8ffc@posting.google.com>...
> nlper@junglemate.com (Tyler) wrote in message news:<65d29696.0311291707.68db0cb1@posting.google.com>...
> >
> > or this:
> > 
> > cf-ii string 6F747200 , 696E6165 , 79636D73 , 7766676C , 62707664 ,
> > 71757868 , 336A7A6B , 37363534 , 2D313938 , 2F322E30 , 2B213A3B ,
> > 3F2C2A40 ,
> > ch 7FFFFF0 and unpack cf-ii + 1@ FF and ;
> > 
> > wouldn't pass muster in a first-year programming course, much less 
> > be accepted in a commercial shop.
> 
> What if the following were provided in the shadow block:
> : cf-ii -a ( table which maps colorforth characters to ASCII
>  characters )
> : ch w-wc ( unpack ASCII character from Huffman packed word )

That would be a start. But ask yourself, if this code were 
offered as part of a portfolio, would you want this coder on
your team?
  
> Chuck left many of the shadow comments from the source code. No one is
> claiming the the state of his documentation is perfect, ...

LOL!

> though it
> seems many have nothing better to do than repeatedly point out the
> fact that is isn't. The idea of contributing documentation has
> seemingly not occurred to these individuals.

Few programmers like documenting their code. So why would you expect 
someone else to volunteer to come in and finish Chuck Moore's work 
for him? Especially when they're only guessing at his code and design 
decisions?

> Other than this I don't know what your expectation is.

Take a look at Frank Sergeant's Pygmy Forth distribution. 
It's head, shoulders, and tummy above Color Forth.

If the Pygmy Forth files were in a portfolio, I'd have no qualms 
about hiring the programmer for a project. 

All of this is predicated on your taking Color Forth seriously 
as a programming tool. If you agree with me that Color Forth is 
a toy, a half-finished Rubik's Cube for programmers, then we can 
shrug at the documentation as indicative of a vanity programming 
project and move on.

> Your
> other complaints, to paraphrase, "colorForth is not ANS Forth",

Well, to be more precise, my primary complaint is that Color Forth 
is unfinished and lacks the basic functionality and documentation 
to do useful work. I use ANS Forth distributions as examples, but 
the case could just as easily be made by citing Pygmy Forth. Pygmy 
is another one-person Forth, not ANS, but it doesn't suffer from 
Color Forth's ills.

> "colorForth is not Linux" are misplaced. To the latter, success of
> this kind is not something that can be guaranteed or even fully
> understood.

On the contrary, much can be learned from the success of Linux. 
Most importantly, Torvalds succeeded by making it easy to use 
existing knowledge and code. There may be no guarantees, but 
every time a Forthian repeats the Moore catechism that file 
systems and host operating systems are tools of the devil or 
signs of incompetent programmers, they're just digging their 
grave a little deeper.

> I hear the repeated insistence that colorForth has no "significant
> applications". Take my jpeg decoder. If it is not significant enough,
> what is the expected difference in a "real application"? Chuck has
> stated his OKAD is not a monolithic application, but a collection of
> smaller applications each defining their own interaction. I suggest
> that no one is prevented from creating a "significant application"
> short of actually investing the labor to do so.

I can't take your jpeg decoder ... I don't have regular access to 
a machine that runs Color Forth. But my machines do run applications 
that can display and edit jpeg files, so it's unclear you've solved 
a problem that I or other people have. I suspect you've created 
something that's similar to a library function in other places.

My criteria for a significant application is code that took more than 
a couple of hours to write, and that it performs some function that 
people other than the developer find useful. In theory, OKAD would 
fit that criteria, although I suspect the users aside from Chuck 
didn't really have any choice in the matter.

But here's a test for you. I'm a movie buff and want a program to 
automatically visit some Web sites each Friday morning and generate 
a report with the current films, theaters, and showtimes. This is 
a really easy program to create in Perl, Python, or Ruby. It's a 
little harder in C, Forth, or Smalltalk, and depends on your version 
having the necessary library support. If I wanted to go totally 
retro, I could even code it in a shell script.

So here's the question: how much *extra* work would you have to do 
in Color Forth to generate that program? Are so many pieces missing 
that it is, for all intents and purposes, an impractical project?

If you agree with me that Color Forth is just a toy, then such 
questions are pretty much irrelevant. If you want people to take 
Color Forth seriously, however, you have to answer the question: 
what conceivable application areas are there where Color Forth 
offers an advantage over existing Forths or other languages? 
So far, I haven't seen a good answer to that question.

Tyler

"John Passaniti" <nntp@JapanIsShinto.com> wrote in message news:<%ezyb.159020$ji3.11701@twister.nyroc.rr.com>...

> > What you see in colorForth are three diferent uses of hex numbers :
> >
> > 1. In character conversion tables. I think this usage is
> > generally accepted.
> 
> Yeah, as long as there is a simple comment somewhere.  It doesn't have to be
> a "War and Peace" tome and it doesn't have to be a tutorial in the language.
> But a simple comment like "ASCII conversion table" can only help.

Hello John.  I guess you missed the white "ASCII" comment at the top of
the block? ;) Seriously that block could have been commented better.
Typically ColorForth uses "shawdow-block" commenting.  Consider this
code from the same website:

http://www.oakland.edu/~maslicke/colorforth/ascii/asciiv.html

block 0
--------
ascii viewer empt 48 load
b@ 1@ ff and ; b 69632 cp 69632
-p b @ cp ! ; np 70644
+p np @ dup b@ drop if cp ! ; then drop ;
eq? over or drop ;
emitl -1 + -if drop ; then over b@ if 10 eq? 
if chc emit 1 u+ emitl ; then drop drop 1 + 
cr ; then drop drop pop drop pop drop pop 
drop ;
emitp 22 for 46 emitl next ;
page text green cp @ emitp np ! ;
ok show black screen page keyboard ;
nul ;
h pad nul nul accept nul nul nul nul nul -p 
nul nul +p nul nul nul nul nul nul nul nul 
nul nul nul nul nul nul nul nul 2500 , 0 , 
2b000023 , 0 , 0 , 0 , 0 ,
ascii 1024 * dup b ! cp ! ok h ; 

--------------------------------------------------------------------------------
{block 1} 
b the begining of the ascii text
cp pointer to the current page
np pointer to the next page
b@ fetch byte from byte adress
-p back to the begining
+p next page
eq? xy-x test equality of x and y
emitl an-y emit line of text
y? past 620 y?
emitp a-y emit page of text
page display page
ascii b- view ascii text at block b 
-----------------------------------------------------------------------

Every definition defined in block 0 is explained in block 1.  I'm not
sure why this wasn't done for the other block you were looking at (block
48) but I can only guess it was an oversight.
 
> > 2. To represent processor op codes : it is difficult to avoid the
> > hex value used in an assembler mnemonic. Normally the
> > assembler would be kept "somehwere else", so you wouldn't
> > have to read the hexadecimal. In colorForth little bits of the
> > assembler are created where they are used.
> 
> This is where I start to have a problem.  Here's a line of ColorForth source
> code:
> 
> 2! a! 28966 3, drop ; forth
> 
> This line was given a comment:
> 
> 2! va- store 16-bit value at byte address
> 
> This comment answers the question of what the 2! word does.  But what if I
> don't want to know what the word does, but how it does it?  I see a magic
> constant of 28966 in there.  From this, I can assume that is likely an
> opcode.  But what is it?  Now I get to go on a software scavenger hunt
> figuring it out. Where did I put my X86 reference book?  Oh, here it is-- 
> and here's a tab I added to the page just for decoding ColorForth code...

> An assembler doesn't fit in the philosophy of ColorForth?  Then the
> "complete absence of layering" you are gushing about doesn't absolve the
> programmer from commenting what is going on.

I doubt the the problem is an assembler somehow falls out of the 
"philosophy" of ColorForth, but that "nobody has done it yet".

Regards,

John M. Drake

nlper@junglemate.com (Tyler) wrote in message news:<65d29696.0311302147.5fee7397@posting.google.com>...
> maslicke@oakland.edu (Mark Slicker) wrote in message news:<4c45abad.0311300342.3e2a8ffc@posting.google.com>...
> > nlper@junglemate.com (Tyler) wrote in message news:<65d29696.0311291707.68db0cb1@posting.google.com>...
> > >
> > > or this:
> > > 
> > > cf-ii string 6F747200 , 696E6165 , 79636D73 , 7766676C , 62707664 ,
> > > 71757868 , 336A7A6B , 37363534 , 2D313938 , 2F322E30 , 2B213A3B ,
> > > 3F2C2A40 ,
> > > ch 7FFFFF0 and unpack cf-ii + 1@ FF and ;
> > > 
> > > wouldn't pass muster in a first-year programming course, much less 
> > > be accepted in a commercial shop.
> > 
> > What if the following were provided in the shadow block:
> > : cf-ii -a ( table which maps colorforth characters to ASCII
>  characters )
> > : ch w-wc ( unpack ASCII character from Huffman packed word )
> 
> That would be a start. But ask yourself, if this code were 
> offered as part of a portfolio, would you want this coder on
> your team?
>   
> > Chuck left many of the shadow comments from the source code. No one is
> > claiming the the state of his documentation is perfect, ...
> 
> LOL!
> 
> > though it
> > seems many have nothing better to do than repeatedly point out the
> > fact that is isn't. The idea of contributing documentation has
> > seemingly not occurred to these individuals.
> 
> Few programmers like documenting their code. So why would you expect 
> someone else to volunteer to come in and finish Chuck Moore's work 
> for him? Especially when they're only guessing at his code and design 
> decisions?

One of the first "open source" programs was released for this very
reason (to let someone else do the documentation).  And many software
management books stress that "programmers are the worst documenters of
their own code".  I'm not sure if this is true or not, but if someone
else volunteered to flesh out the documentation of ColorForth that
would certainly not be outside "standard" practice.  As for "guessing
at his code" I assume if someone did this they could post their 
comments and then ask Chuck "is this what you were saying"?

Regards,

John M. Drake

"John Passaniti" <nntp@JapanIsShinto.com> wrote in message news:<1Mzyb.159027$ji3.80196@twister.nyroc.rr.com>...
> "Mark Slicker" <maslicke@oakland.edu> wrote in message
> news:4c45abad.0311300342.3e2a8ffc@posting.google.com...
> > nlper@junglemate.com (Tyler) wrote in message
>  news:<65d29696.0311291707.68db0cb1@posting.google.com>...
> > To the former, if what you desire is groveling acceptance
> > of the status quo, you are best to stay with ANS Forth
> > with perhaps Mr. John Passaniti as your mentor.
> 
> Ironic.  I rarely use ANS Forth, and instead use a variety of homebrew Forth
> and Forth-like languages.  I don't use ANS Forth because it isn't relevant
> to my work.  My work actually is more in like with ColorForth in that I am
> tuning the language to my needs, not that of a standards body's desire for
> portability.
> 
> That being said, I respect ANS Forth because it gives programmers an option.
> Options can be taken or ignored.

I more associate you with the status quo than I do with ANS Forth.
Mostly it is the repetition of the idea that all things are equal just
different. There is actually a technical term for this philosophy,
"relativism" or "absolute relativism". Do a google search of these
terms. Naturally this philosophy is perfect for the status quo since
there can be no objective criticism of it.

> 
> > I hear the repeated insistence that colorForth has no
> > "significant applications". Take my jpeg decoder. If it is
> > not significant enough, what is the expected difference
> > in a "real application"?
> 
> I guess we all have our own personal thresholds for what is and isn't
> significant.  Taking a well-known and well-documented algorithm and
> implementing it in ColorForth to me doesn't seem very significant.  Would
> your JPEG decoder been significant if you had coded it in assembler instead
> of ColorForth?  What if you had coded it in C?

JPEG is not an algorithm, but a specification. The specification does
not specify which algorithms should be used or the structure of the
code. Some algorithms are suggested, the IDCT I found. My
implementation is original, not being based off of any existing code.

Would it be significant otherwise? It is more concise than any code
I've seen. A new version (not released) shows additional improvements
in quality, speed, and conciseness. Some of these qualities are
derived directly from its expression in colorForth. An assembler
version would most likely be faster, but assembler is both clumsy and
non-portable. A C version, also clumsy, would be ignored I think
because the IJG code exists and C programmers do not mind size nor the
ugliness of this code. Once their code is functional, C programmers
tend to move in the direction completeness and generality. I think my
JPEG code is most valuable as part of a simple comprehensible system.

> 
> What does seem more significant to me is to build applications that involve
> actual user interaction, where the user builds something with the
> application (say for example, a drawing), the user manipulates it (say, by
> transforming it in some way), and then the user saves their work.  Such an
> application wouldn't need to be monolithic, and may certainly use components
> like your JPEG decoder along the way.
> 
> Significance to me has to do with user interaction, not complexity.  And
> part of the reason is that while the ColorForth environment may be fine for
> programmers to work in, it is a hostile environment for end users-- 
> presumably the people who will actually be using the applications created
> with ColorForth.  That suggests to me that either ColorForth programmers
> will force end users to use the same editor they do to interact with
> applications, or they will create some kind of user interface.

So your concern is that an application that deals directly with the
user will show some limitation in the system. This is fair game.

If we take a look at current applications, colorForth is basically a
single window interface with a remapable key layout. Mouse interaction
could be easily handled. One limitation might be the need for
independent interactions, for example a multiple windowed desktop. In
this case you need to introduce a piece of code which manages the
display and input differently from the present code.

Another issue is how data is stored and the location. For the icon
editor there is only one font and it is global. Chuck's chips seem to
be encoded in colorForth through the editor. Here the block locations
are likely explicitly specified. I think there is a need for a higher
level that doesn't presently exist. A flat database of application
data. Maybe my view is different from Chuck's in this aspect.

The issue of data is a fundamental one in system design. As much as I
admire colorForth, I find attractive the pure elegance of functional
systems. In a functional system all data is expressed in the type
system of the language and remains persistent until no reference of
the data exists. The kind of code as data that Chuck uses in OKAD
seems like a one way street, modification is through the editor,
mechanical processing only seems to apply to interpretation of the
data. In the general case it seems we are left to define binary
formats and the methods for modification.

> > You have shown that your intention from the outset is to
> > marginalize colorForth. I think it is consistent with many of the
> > other comments I see here. I sugest to the entire group this is
> > the true black eye that has been given to Forth, the stangulation
> > of any kind of diversity by a small but vocal conservative minority.
> 
> I assume the above was addressed to "Tyler" and not me.  I in fact am all
> for even more diversity than the ColorForth community seems to want, by
> viewing ColorForth not as an implementation, but as a statement about
> programmers creating their own individual and unique programming languages
> and environments.

This view is marginalizing for a general purpose programming language.
A language that can't scale beyond a single person and a single
context is worthless. No one wants to maintain a thousand dialects of
language and applications written in these dialects, nor does anyone
want to reinvent the same code over and over again for each dialect.
Robust and well-written code is an invaluable asset. This does not
imply we have to accept colorForth in its present form, this does not
imply we need a colorForth standard. Many languages exist today with
no standard, only a community which accepts basic premises, the
interactions of which produce an evolution of the language. In this
case the implementation is the standard.

> 
> > Prime evidence of this fact is that people who actually use
> > colorForth and generally experiment with Forth have migrated to
> > wholly seperate and moderated forums.
> 
> Have fun there.  And do keep the rest of us informed when ColorForth
> matures.  I'd love to see what happens to the language after more people
> start to stress it and discover the weaknesses.

It has not been as much fun as I would have hoped. I really thought
people would take the ball and run with it. I had no idea of the kind
battles to be fought and the strange group politics that have come
with the Forth association. If I'd known this I might have created an
environment with no association to Forth or Chuck Moore. I still may
do this.

Mark

"jmdrake" <jmdrake_98@yahoo.com> wrote in message
news:e20a4a47.0312010745.5c553439@posting.google.com...

> block 0
> --------
> ascii viewer empt 48 load
> b@ 1@ ff and ; b 69632 cp 69632
> -p b @ cp ! ; np 70644
> +p np @ dup b@ drop if cp ! ; then drop ;
> eq? over or drop ;
> emitl -1 + -if drop ; then over b@ if 10 eq?
> if chc emit 1 u+ emitl ; then drop drop 1 +
> cr ; then drop drop pop drop pop drop pop
> drop ;
> emitp 22 for 46 emitl next ;
> page text green cp @ emitp np ! ;
> ok show black screen page keyboard ;
> nul ;
> h pad nul nul accept nul nul nul nul nul -p
> nul nul +p nul nul nul nul nul nul nul nul
> nul nul nul nul nul nul nul nul 2500 , 0 ,
> 2b000023 , 0 , 0 , 0 , 0 ,
> ascii 1024 * dup b ! cp ! ok h ;

Is it Forth? ColorForth yes. Forth?

0: i st su cf be re to ci ; i s mr m f id ; j af f s fi ; t to be fu ;

(block 1/shadow block: I strongly suggest ColorForth be renamed to
ColorFifth, it is more modern forth indeed. just after fourth is fifth - try
to be funny)

Regards,
Petrus-Pet4th.

maslicke@oakland.edu (Mark Slicker) wrote in message news:<4c45abad.0311281843.7b433ae3@posting.google.com>...
> m-coughlin <m-coughlin@comcast.net> wrote in message news:<3FC6AF37.74992DF3@comcast.net>...
> Yay, I finally have an answer to your incessant whining. The blocks
> for Chuck's colorForth can be found in HTML here:
> 
> http://www.merlintec.com/download/color.html
> 

That sure is a big font. Those of us who are not nearly blind would
probably prefer to see the shadow blocks displayed beside the
corresponding source blocks. Is this possible?

I think for more extensive commenting, the comments should be placed
in a HTML page. A tool could be written to generate hyperlinks to the
comments so that when you click on a word the browser jumps to the
comments.

To take the idea further, imagine hyperlinking through the source
code. Click on a red word to jump to the documentation for that word.
Click on a green word to jump to the source code for that word.

Automated tools could be written to generate the HTML to do this cool
stuff. The comment page could use data extracted from shadow blocks as
a starting point.

Brad

"Petrus Prawirodidjojo" <petrusp@attglobal.net> wrote in message
news:3fcc3788_3@news1.prserv.net...
>
> "jmdrake" <jmdrake_98@yahoo.com> wrote in message
> news:e20a4a47.0312010745.5c553439@posting.google.com...
>
> > block 0
> > --------
> > ascii viewer empt 48 load
> > b@ 1@ ff and ; b 69632 cp 69632
> > -p b @ cp ! ; np 70644
> > +p np @ dup b@ drop if cp ! ; then drop ;
> > eq? over or drop ;
> > emitl -1 + -if drop ; then over b@ if 10 eq?
> > if chc emit 1 u+ emitl ; then drop drop 1 +
> > cr ; then drop drop pop drop pop drop pop
> > drop ;
> > emitp 22 for 46 emitl next ;
> > page text green cp @ emitp np ! ;
> > ok show black screen page keyboard ;
> > nul ;
> > h pad nul nul accept nul nul nul nul nul -p
> > nul nul +p nul nul nul nul nul nul nul nul
> > nul nul nul nul nul nul nul nul 2500 , 0 ,
> > 2b000023 , 0 , 0 , 0 , 0 ,
> > ascii 1024 * dup b ! cp ! ok h ;
>
> Is it Forth? ColorForth yes. Forth?
>
> 0: i st su cf be re to ci ; i s mr m f id ; j af f s fi ; t to be fu ;
>
> (block 1/shadow block: I strongly suggest ColorForth be renamed to
> ColorFifth, it is more modern forth indeed. just after fourth is fifth -
try
> to be funny)
>
> Regards,
> Petrus-Pet4th.
>
>
>

The OP posting was surely of the language ColorLess. Without colo(u)r much
of the "flavour" of the code is lost; if colour is _that_ important in
ColorForth, then surely the meaning has been destroyed too? As a
consequence, it's a difficult language to discuss on Usenet.

-- 
Regards
Alex McDonald

Hi Alex,

"Alex McDonald" <alex_mcd@btopenworld.com> wrote in message
news:bqiqcp$nnn$1@titan.btinternet.com...
[snip]
> The OP posting was surely of the language ColorLess. Without colo(u)r much
> of the "flavour" of the code is lost; if colour is _that_ important in
> ColorForth, then surely the meaning has been destroyed too? As a
> consequence, it's a difficult language to discuss on Usenet.

That's why I added the "F4" key in cfdos.com.

Put the colorForth file into the same directory as cfdos.com, run cfdos.com
and press F4.
You can copy a floppy disk to/from a file using cfdos.com too.

If you are running in a Windows DOS box, you can then right click the MSDOS
icon and mark and copy from the screen.
This is a conventional DOS program and has no known issues with regard to
portability or hard disk safety.

There is so much good stuff in colorForth that I didn't want people to be
put off by details such as the source presentation style or platform
incompatibilities. It is best if you can run colorForth, though.

Regards

Howerd

maslicke@oakland.edu (Mark Slicker) wrote in message news:<4c45abad.0311300342.3e2a8ffc@posting.google.com>...
> I hear the repeated insistence that colorForth has no "significant
> applications". 

One problem with that statement is that 'significant applications'
is a very fuzzy term.  Individuals will assign different meanings.
For some it means useful.  For some it means something that sells
in large volume.  For some it means something that they can buy
at the local computer store.

One thing to consider however is that most of Chuck's colorforth
code is not public domain and neither is the code of the other
people professionally programming in Chuck's cad environment
in colorforth.  Personally I am suprised that there has been
as much interest in colorforth as there has been.  I think an
OS stripped of applications is like an empty box, not too
intesting in itself.  colorforth with all of Chuck's cad code,
the dozen or so applications is an intersting environment.

> You have shown that your intention from the outset is to marginalize
> colorForth. I think it is consistent with many of the other comments I
> see here. I sugest to the entire group this is the true black eye that
> has been given to Forth, the stangulation of any kind of diversity by
> a small but vocal conservative minority. Prime evidence of this fact
> is that people who actually use colorForth and generally experiment
> with Forth have migrated to wholly seperate and moderated forums.

I used to tell people that c.l.f is the last place to get any
information about colorforth, but that has changed.  There are a
few people who post interesting and real information about it here.
And c.l.f does provide some insight into why some people react
so negatively to innovation in Forth.

Best Wishes,
Jeff Fox
> Mark

"John Passaniti" <nntp@JapanIsShinto.com> wrote in message news:<1Mzyb.159027$ji3.80196@twister.nyroc.rr.com>...


> What does seem more significant to me is to build applications that involve
> actual user interaction, where the user builds something with the
> application (say for example, a drawing), the user manipulates it (say, by
> transforming it in some way), and then the user saves their work.  Such an
> application wouldn't need to be monolithic, and may certainly use components
> like your JPEG decoder along the way.

You mean like a Mandelblot viewer?

http://www.oakland.edu/~maslicke/colorforth/mandelbrot/

Or how about Conway's "game of life"?

http://www.strangegizmo.com/forth/ColorForth/msg00460.html

Both applications involve actual "user interaction".

Regards,

John M. Drake

jonah thomas <j2thomas@cavtel.net> wrote in message news:<ONnyb.17$Jv5.16544@news.uswest.net>...

> That sounds good to me.  So the next step is, how do we make little 
> niche languages and document them well enough that somebody else could 
> step in and maintain our applications?  This doesn't *have* to be an 
> issue.  100,000 lines of C might truly be no harder to maintain than 500 
> lines that define a special-purpose language and 500 lines of code in 
> that language.

Who sets the standards for "no harder to maintain"? If I already 
have C programmers on staff, the new language will be an added 
training cost. But the bigger problem is the matter of trust. 
Managers can look at existing projects that have been done in 
C -- there are comparatively few for Forth -- and see none for 
Color Forth or another new, small language. If you're going to 
claim 100x productivity, you're going to have to show some 
successful examples.

I don't think it's the same today, but in years past Smalltalk 
was a favorite among consultants for rapid prototyping. Those 
consultants could demonstrate they were faster than ordinary 
C coders. Conceptual simplicity rather than "smallness" of the 
environment or system was the key.

I note that "light-weight" languages are considered the new 
choice in rapid development, most of them are scripting 
languages. All of them I'm aware of have another characteristic: 
they make it easy to use or coexist with existing C code.

The scripting language Lua has become far more popular than 
Color Forth as it exists can hope to. It's a small, extensible 
language -- you just have to use C for the extensions rather 
than Lua itself.

For a great many people, C has become a virtual machine layer 
to their code, even if they don't code in C themselves. I think 
there's a big lesson there for future small languages.

> But there's the problem that C programmers are perfectly 
> happy to get the job of maintaining 100,000 lines of C code, and if it 
> looks too hard they'll ask for an assistant.  While they and their 
> managers tend to balk at unusual languages.

All too often, such comments are accompanied by a lament that it 
shouldn't be that way. Well, it *is* that way. The question is 
how one intends to deal with it. If you adopt Chuck's extreme 
position that files and operating systems are things to be 
dispensed with, well, don't be surprised if you don't get a 
lot of business offers. But if you develop a language that 
improves on C in some areas and peacefully coexists with the 
code base, it's an entirely different proposition. Being new 
hasn't stopped the widespread adoption of Perl, Python, and 
other languages.

Tyler

     I'm combining two messages with cut and paste, so the
quoting will be a little different from usual.

> andrew29@littlepinkcloud.invalid wrote:

> m-coughlin <m-coughlin@comcast.net> wrote:
> 
> >     You can't find a good listing when you want to. You only find
> > them when you are looking for something else. I once was looking
> > for information about metal oxide varistors for voltage
> > transient suppression on AC power lines and I found a nice
> > listing for an assembly language program when I included MOV in
> > a search expression for Google. I tried it again, and just found
> > this --
> > http://www.ustr.net/files/i2cbits.asm   
> > It is assembly language but it follows the instructions for the
> > C++ class.
> 
> This is classical student commenting.
> 
>           PUSH    ACC            ;Save accumulator
> 
> ...
> 
>           POP     ACC            ;Restore accumulator
> 
> An important rule of commenting is "You are not writing a tutorial, so
> do not add comments that are obvious to someone skilled in the art.
> They only waste the time of the reader."

      Ohmygosh, here I spent several minutes surfing the web to
find an example of commendable commenting and all you can see
out of the 200 or so commented lines are two lines that you
don't approve of.

      I was hoping you might appreciate things like the part I
will paste as a quotation (spacing adjusted)  --
> 
> ; BitDly - insures minimum high and low clock times on I2C bus.
> ; This routine must be tuned for the actual oscilator frequency used, shown 
> ; here tuned for a 12MHz clock. Note that the CALL instruction that invokes 
> ; BitDly already uses 2 machine cycles.
> 
> BitDly:    NOP                    ;  NOPs to delay 5 microseconds (minus 4
>                                          ;  machine cycles for CALL and RET).
>                RET
> 

        Just look at all the vital information included that
usually gets left out. It is for a I2C bus. I don't know what an
I2C bus is, but I'd know even less if it wasn't mentioned. Since
there is also something about clock times, I can see that BitDly
means "bit delay", so along with "bus", I know this part of the
code is a timing loop for reading or writing, possibly to an
external part. Then there is the mention of a 12 MHz clock, 5
microseconds delay, tuning, and NOP. If this were part of some
program that wasn't working because of an I/O problem, I'd
immediately know to check this code and see if the system was
still running with a 12 MHz clock. Now you'd probably say that
it is useless to write so much since  it is obvious to someone
skilled in the art what the label BitDly and 5 microseconds
imply. I'd say the few people in the world who would know that
are highly unlikely to be around to read the code when you need
them to solve a problem. The number of people skilled in the art
is much larger if the extra information is included. 

Bernd Paysan wrote:
 
> andrew29@littlepinkcloud.invalid wrote:
> > An important rule of commenting is "You are not writing a tutorial, so
> > do not add comments that are obvious to someone skilled in the art.
> > They only waste the time of the reader."
 
> This is exactly what I've thought Michael wants when talking about
> "documentation": a tutorial that explains in plain english what's
> going on on the left side. A sort of "rosetta stone" for computer
> illiterates.
 
     It is not for computer illiterates. Its for the project
managers who approve the paychecks and the coworkers who are
supposed to know about the code when the original author isn't
around. What a strange connection you make with the "rosetta
stone". Discovering a "rosetta stone" is the most important step
to learn ancient history. There are some ancient writings, such
as Etruscan, where there is no "rosetta stone", and finding such
a thing has the highest priority. I guess you don't like ancient
history as much as I do, or else you would know you need a
"rosetta stone" for every ancient script. In the software
business an ancient script corresponds to a program written last month.

> You find this sort of "student's comments" for all languages taught at
> universities, because that's where students work. You won't find it for
> Forth programs.

      That must be because Forth is not taught at universities.
Its too bad, because Forth is easy to learn. Or it would be if
it were made easy to learn.

> Michael, you have to learn a language *before* you can read programs
> written in that language. Really. And even more, you ought to lean a
> language before you can *write* programs in that language. 

      When I started programming, I made a lot of mistakes
because I didn't understand FORTRAN very well. Then I had
problems because I couldn't figure out the poorly commented
programs other people wrote. After a year or two I had hardly
any trouble with Fortran code and I still couldn't understand
poorly commented programs other people wrote. My experience is
totally the opposite of yours. Trouble understanding plain code
goes away after a while. Trouble understanding poorly commented
code never goes away. I work on scientific problems. Just
knowing the code is not enough. I have to know what mathematical
equations each section of the code is using. I must know what
each variable stands for, and not just what it stands for, but
what units it is in. And the people who work with me and use my
programs have to know the same thing to check up on me. You are
not going to see that just from the code. Since I like to talk
about computers, and outer space, a friend once asked me about
the crash of a space probe on Mars. Could a hundred million
dollar project run by highly intelligent people fail because of
a simple mistake like using feet instead of meters in a computer
program? I instantly replied -- of course!

> A lot of
> assembler programmers ignore that and read comments and write
> assembly language by writing comments and hoping that the code
> they wrote on the left side actually matches the intent stated on the
> right side. That's why assembler is such a difficult language, with
> such a high bug-count per line. People are lulled into a false feeling
> of understanding.
 
      I never worked with assembly language programmers, so I
have no idea of what happens when the comments don't match the
code and people are lulled into a false feeling of
understanding. I'm interested in true understanding. A listing
for the assembly language code is as important a part of a
computer project as a circuit diagram or node list or whatever
they call that stuff today. So I see the same big problem when
the code does not match the comments as when the code fails to
work. Or when there is a connection to the wrong pin on an
integrated circuit.

> Michael often says something like that computer languages are not
> to be read by humans, comments are. That's wrong - computer
> languages are intentionally created to be read by both humans and
> computers, they are an interface between man and machine. Due to
> their nature, they don't resemble human languages, which are created
> (or have been evolved) for communication between humans.

     Mathematical equations are also created for communication
between humans. I don't think you will have much communication
if you just present your equations and leave out what
corresponds to comments in computer programs.


   Let me make one more comparison between the code in my
randomly chosen assembly language listing and the assembly
listing for ColorForth.

 http://www.ustr.net/files/i2cbits.asm

 ftp://ftp.ultratechnology.com/COLOR.ASM

     i2cbits.asm starts out --

;****************************************************************************

;                     Software Implemented I2C Drivers

; These routines allow an 80C51 based microcontroller to drive
the I2C bus 
; as a single master. The main program at the end demonstrates
writing and 
; reading several types of devices: 

;    PCF8570 256 byte static RAM.
;    PCF8574 8-bit I/O expander.
;    SAA1064 4 digit LED display driver.


;             Written by G.Goodhue, Philips Components-Signetics

;****************************************************************************

     So I see this is for an 80C51 and was written by someone
from 
Philips Components-Signetics. There are lots of different 8051
chips, and this cuts down on the number of variations. It also
mentions the use for the I2C bus, and three peripheral chips. 

COLOR.ASM starts out --

;colorForth, 2001 Jul 22, Chuck Moore, Public Domain

..MODEL tiny
..486p
only SEGMENT USE32
ASSUME DS:only

     This mentions nothing like the above. What CPU is it for?
What video hardware does it work on? What bus does it use? It
says it was written by Chuck Moore. In other places I think I
read it is in MASM format, which is strange since I didn't think
Chuck Moore would use MASM. There is something about .486p,
maybe that means it is for an Intel 80486, but I read, on
comp.lang.forth, ColorForth would only run on a Pentium. There
are very few comments. I can't find where it writes to the video
display. Maybe there is something about that in another listing,
boot.asm. But it would be so much nicer if there was more
information to start with, just as there is in i2cbits.asm.

     On his web page
http://www.colorforth.com/install.htm  Chuck mentions 
"I'd like to recommend a current desktop PC that can run
colorForth as a dedicated platform. It should have a low price,
minimal memory and no software. Gateway? Dell? Likewise a
laptop. Any candidates?"

     Seems like a very difficult question to me. What are the
specifications for such a machine? I guess somebody could
reverse engineer the uncommented assembly code and find out, but
I'll bet all the engineers in the world who could do that job
are busy doing something else. Wouldn't it be easier to find out
what interfaces are common to most new computers and write
ColorForth to use them?

       When I asked why none of my old computers would run
ColorForth, I could not get a definite answer. This is exactly
the result I would expect from a software system published as an
uncommented assembly listing with only a few brief notes on its
use scattered around several different web pages. ColorForth
will be much more interesting when it gets turned into an
assembly language listing resembling the style of, for example,
i2cbits.asm. Unfortunately Forth programmers don't like to work
that way. 

        Without a "rosetta stone" trying to use ColorForth is
like trying to read Etruscan.

--
Michael Coughlin   m-coughlin@comcast.net   Cambridge, MA USA

Jeff Fox wrote:

>  . . . .  Personally I am suprised that there has been
> as much interest in colorforth as there has been.  I think an
> OS stripped of applications is like an empty box, not too
> intesting in itself.  colorforth with all of Chuck's cad code,
> the dozen or so applications is an intersting environment.

     A welcome change. You used to complain that people thought
Forth was the same as the ANS standard and were not interested
in Chuck's current way of working. Well hardly anybody could
find out what Chuck was doing since he hardly made anything public.

      I am not surprised that there has not been more interest
in ColorForth. It woun't run on most computers and there is no
easy way to learn to change that. I don't see it as an operating
system. It is both an operating system AND a programming
language; the combination is more than the sum of its parts. 

 --
Michael Coughlin    m-coughlin@comcast.net    Cambridge, MA USA

        And yet... He still doesn't indicate what assembler it's for.  There's
only about 200 different ones for 8051, and Philips uses several.

        I'm guilty of this, though I have tried to remedy it over the years. 
Indicating what tools are necessary to reproduce a projects output are a
must.

        And just for the record, I've tried ColorForth.  I couldn't get it to 
run on 5 of the 6 machines I had on hand.  When I finally did get it
running, the keyboard mapping was just a little too freaky for me.

        --jc

m-coughlin wrote:

[ snip ]

> 
>  http://www.ustr.net/files/i2cbits.asm
> 
>  ftp://ftp.ultratechnology.com/COLOR.ASM
> 
>      i2cbits.asm starts out --
> 
> ;****************************************************************************
> 
> ;                     Software Implemented I2C Drivers
> 
> ; These routines allow an 80C51 based microcontroller to drive
> the I2C bus
> ; as a single master. The main program at the end demonstrates
> writing and
> ; reading several types of devices:
> 
> ;    PCF8570 256 byte static RAM.
> ;    PCF8574 8-bit I/O expander.
> ;    SAA1064 4 digit LED display driver.
> 
> 
> ;             Written by G.Goodhue, Philips Components-Signetics
> 
> ;****************************************************************************
> 
>      So I see this is for an 80C51 and was written by someone
> from
> Philips Components-Signetics. There are lots of different 8051
> chips, and this cuts down on the number of variations. It also
> mentions the use for the I2C bus, and three peripheral chips.

 [snip]

Mark Slicker wrote:
> 
> nlper@junglemate.com (Tyler) wrote in message news:<65d29696.0311291707.68db0cb1@posting.google.com>...
> >
> > or this:
> >
> > cf-ii string 6F747200 , 696E6165 , 79636D73 , 7766676C , 62707664 ,
> > 71757868 , 336A7A6B , 37363534 , 2D313938 , 2F322E30 , 2B213A3B ,
> > 3F2C2A40 ,
> > ch 7FFFFF0 and unpack cf-ii + 1@ FF and ;
> >
> > wouldn't pass muster in a first-year programming course, much less
> > be accepted in a commercial shop.
> 
> What if the following were provided in the shadow block:
> : cf-ii -a ( table which maps colorforth characters to ASCII
> characters )
> : ch w-wc ( unpack ASCII character from Huffman packed word )
> 
> Chuck left many of the shadow comments from the source code.
> No one is claiming the the state of his documentation is perfect,
> though it seems many have nothing better to do than repeatedly
> point out the fact that is isn't. The idea of contributing documentation
> has seemingly not occurred to these individuals.

      My contribution to the documentation of ColorForth is to
state there is no way for me to contribute to the documentation
of ColorForth. I don't understand it. I don't understand why
anybody would even think that anybody else would understand it
in its present condition. The available information is too
muddled. It violates every rule I respect for clear programming.

> Other than this I don't know what your expectation is. Michael's
> expectation appears to be that colorForth should have been distributed
> with it's own "Starting colorForth" book on how to program. Surely it
> would a great thing to have but no one has put forth the effort. 

       Maybe nobody knows how to do it. After I read "Starting
Forth", I decided that Forth was the greatest programming
language because it was used for the best book on programming.
Surely, if it could be used for such a good book for beginners,
it could also be used for the illumination of more advanced
topics. Well it hasn't. 

       Now I know I'm not asking for anything easy. But if Forth
programmers only do research on how to make Forth run faster and
use less memory while users of other languages teach the new
students and write the textbooks, what direction will the art of
computer programming take? I would like to read about ColorForth
as an assembly language listing that did not look like it was
just printed out by a disassembly program. Other approaches are
possible. Right now we have a situation where only a few
programmers can make sense of ColorForth. Changing the shadow
blocks is not the way to go. Chuck Moore likes to pack as much
code as possible into each screen. You need much more than one
shadow block to explain one block of Chuck's code. I once wrote
a program that took up one half of a printed page and needed
between ten and twenty pages of scientific papers on quantum
mechanics to explain what I did, and that was only for my boss
who was an expert on the topic. My code is not as clever and
sophisticated as Chuck's, so I expect his code to need more
documentation than mine.

[snip]
 
> I hear the repeated insistence that colorForth has no "significant
> applications". Take my jpeg decoder. If it is not significant enough,
> what is the expected difference in a "real application"? 

      I have several programs to display jpeg images.  My
favorite is Irfanview (written by Irfan Skiljan) which started
out as a student's project in Austria. I tell my friends they
don't need to buy Photoshop, they can view, edit and print their
pictures just fine with Irfanview. 
For Wintel computers, not MacIntosh     
http://www.irfanview.com/
download from http://www.tucows.com/
This is what I think about when I see "significant applications"
and "jpeg decoder" written close together.

        Now I know you have not spent the many years that Irfan
Skiljan has on his program, but could you even consider using
ColorForth for such a project? You probably have some other
purpose in mind. Don't the limits imposed by ColorForth cause
you some concern? It certainly does to me, since I can't even
get it running. 
     
> Chuck has
> stated his OKAD is not a monolithic application, but a collection of
> smaller applications each defining their own interaction. I suggest
> that no one is prevented from creating a "significant application"
> short of actually investing the labor to do so.
 
> You have shown that your intention from the outset is to marginalize
> colorForth. I think it is consistent with many of the other comments I
> see here. I sugest to the entire group this is the true black eye that
> has been given to Forth, the stangulation of any kind of diversity by
> a small but vocal conservative minority. Prime evidence of this fact
> is that people who actually use colorForth and generally experiment
> with Forth have migrated to wholly seperate and moderated forums.

     I think Tyler has some good ideas, but he's being too wishy-washy.

--
Michael Coughlin    m-coughlin@comcast.net   Cambridge, MA USA

"m-coughlin" <m-coughlin@comcast.net> wrote in message
news:3FCE7FEA.AC7082D4@comcast.net...
>
>       I have several programs to display jpeg images.  My
> favorite is Irfanview (written by Irfan Skiljan) which started
> out as a student's project in Austria. I tell my friends they
> don't need to buy Photoshop, they can view, edit and print their
> pictures just fine with Irfanview.

    Grandview is a nice viewer and it can do some limited editing, but
comparing it to Photoshop is laughable.  It's like comparing Notepad to a
real word processor.  If you'd like a demo of what Photoshop can do which
Grandview can not do, I'll be glad to show you.

-- 

-GJC [MS Windows SDK MVP]
-Software Consultant (Embedded systems and Real Time Controls)
-gchanson@mvps.org

-Abolish public schools

"Gary Chanson" <gchanson@No.Spam.TheWorld.net> wrote in message
news:NGzzb.27755$lF6.6279@nwrdny01.gnilink.net...
>
> "m-coughlin" <m-coughlin@comcast.net> wrote in message
> news:3FCE7FEA.AC7082D4@comcast.net...
> >
> >       I have several programs to display jpeg images.  My
> > favorite is Irfanview (written by Irfan Skiljan) which started
> > out as a student's project in Austria. I tell my friends they
> > don't need to buy Photoshop, they can view, edit and print their
> > pictures just fine with Irfanview.
>
>     Grandview is a nice viewer and it can do some limited editing, but
> comparing it to Photoshop is laughable.  It's like comparing Notepad to a
> real word processor.  If you'd like a demo of what Photoshop can do which
> Grandview can not do, I'll be glad to show you.

    That should be "Irfanview" (!@#@$%$% spell checker!).

-- 

-GJC [MS Windows SDK MVP]
-Software Consultant (Embedded systems and Real Time Controls)
-gchanson@mvps.org

-Abolish public schools

m-coughlin <m-coughlin@comcast.net> wrote:

>      I'm combining two messages with cut and paste, so the
> quoting will be a little different from usual.

>> andrew29@littlepinkcloud.invalid wrote:

>> This is classical student commenting.
>> 
>>           PUSH    ACC            ;Save accumulator
>> 
>> ...
>> 
>>           POP     ACC            ;Restore accumulator
>> 
>> An important rule of commenting is "You are not writing a tutorial, so
>> do not add comments that are obvious to someone skilled in the art.
>> They only waste the time of the reader."

>       Ohmygosh, here I spent several minutes surfing the web to
> find an example of commendable commenting and all you can see
> out of the 200 or so commented lines are two lines that you
> don't approve of.

It's the most extreme example in the page, but it's not totally
unrepresentative.

>       I was hoping you might appreciate things like the part I
> will paste as a quotation (spacing adjusted)  --
>> 
>> ; BitDly - insures minimum high and low clock times on I2C bus.
>> ; This routine must be tuned for the actual oscilator frequency
>> ; used, shown here tuned for a 12MHz clock. Note that the CALL
>> ; instruction that invokes BitDly already uses 2 machine cycles.

Well, okay.  It's well-documented but rather fragile code.

>> BitDly:    NOP                    ;  NOPs to delay 5 microseconds (minus 4
>>                                   ;  machine cycles for CALL and RET).

>         Just look at all the vital information included that usually
> gets left out. It is for a I2C bus. I don't know what an I2C bus is,
> but I'd know even less if it wasn't mentioned. Since there is also
> something about clock times, I can see that BitDly means "bit
> delay", so along with "bus", I know this part of the code is a
> timing loop for reading or writing, possibly to an external
> part. Then there is the mention of a 12 MHz clock, 5 microseconds
> delay, tuning, and NOP. If this were part of some program that
> wasn't working because of an I/O problem, I'd immediately know to
> check this code and see if the system was still running with a 12
> MHz clock. Now you'd probably say that it is useless to write so
> much since it is obvious to someone skilled in the art what the
> label BitDly and 5 microseconds imply.

Would I?  It looks quite reasonable to me.  The problem with
overcommenting is that you don't find the gems.

Andrew.

----- Original Message -----
From: "J.C. Wren" <jcwren@jcwren.com>
Newsgroups: comp.lang.forth
To: <comp.lang.forth@ada-france.org>
Sent: Thursday, December 04, 2003 05:51
Subject: Re: Colorforth for Other People


>         And just for the record, I've tried ColorForth.  I couldn't get it
to
> run on 5 of the 6 machines I had on hand.  When I finally did get it
> running, the keyboard mapping was just a little too freaky for me.
>
>         --jc

I could not find the right word, now you tell me, it is "freaky". Good.

Regards,
Petrus-Pet4th.

Why do you think that ColorForth is a Forth? It is better to separate those
two, better not to mix them. Though both ideas are from the same person,
those two are not necessarily the same.

Starting Forth is about Forth, not ColorForth.

I read about disappointment that Forth becomes ANSForth. That Forth should
become ColorForth. But I also regret that ColorForth is named that way. I
wish that ColorForth can be more popular and afford a new newsgroup
specially for it.

Regards,
Petrus-Pet4th.

----- Original Message -----
From: "m-coughlin" <m-coughlin@comcast.net>
Newsgroups: comp.lang.forth
To: <comp.lang.forth@ada-france.org>
Sent: Thursday, December 04, 2003 07:28
Subject: Re: Colorforth for Other People (was Re: ANN cfdos - EuroForth
2003edition)


>       My contribution to the documentation of ColorForth is to
> state there is no way for me to contribute to the documentation
> of ColorForth. I don't understand it. I don't understand why
> anybody would even think that anybody else would understand it
> in its present condition. The available information is too
> muddled. It violates every rule I respect for clear programming.

>        Maybe nobody knows how to do it. After I read "Starting
> Forth", I decided that Forth was the greatest programming
> language because it was used for the best book on programming.
> Surely, if it could be used for such a good book for beginners,
> it could also be used for the illumination of more advanced
> topics. Well it hasn't.
>
>        Now I know I'm not asking for anything easy. But if Forth
> programmers only do research on how to make Forth run faster and
> use less memory while users of other languages teach the new
> students and write the textbooks, what direction will the art of
> computer programming take? I would like to read about ColorForth
> as an assembly language listing that did not look like it was
> just printed out by a disassembly program. Other approaches are
> possible. Right now we have a situation where only a few
> programmers can make sense of ColorForth. Changing the shadow
> blocks is not the way to go. Chuck Moore likes to pack as much
> code as possible into each screen. You need much more than one
> shadow block to explain one block of Chuck's code. I once wrote
> a program that took up one half of a printed page and needed
> between ten and twenty pages of scientific papers on quantum
> mechanics to explain what I did, and that was only for my boss
> who was an expert on the topic. My code is not as clever and
> sophisticated as Chuck's, so I expect his code to need more
> documentation than mine.
>
>         Now I know you have not spent the many years that Irfan
> Skiljan has on his program, but could you even consider using
> ColorForth for such a project? You probably have some other
> purpose in mind. Don't the limits imposed by ColorForth cause
> you some concern? It certainly does to me, since I can't even
> get it running.
>
>      I think Tyler has some good ideas, but he's being too wishy-washy.
>
> --
> Michael Coughlin    m-coughlin@comcast.net   Cambridge, MA USA

Tyler wrote:
> jonah thomas <j2thomas@cavtel.net> wrote

>>That sounds good to me.  So the next step is, how do we make little 
>>niche languages and document them well enough that somebody else could 
>>step in and maintain our applications?  This doesn't *have* to be an 
>>issue.  100,000 lines of C might truly be no harder to maintain than 500 
>>lines that define a special-purpose language and 500 lines of code in 
>>that language.

> Who sets the standards for "no harder to maintain"? If I already 
> have C programmers on staff, the new language will be an added 
> training cost. But the bigger problem is the matter of trust. 
> Managers can look at existing projects that have been done in 
> C -- there are comparatively few for Forth -- and see none for 
> Color Forth or another new, small language. If you're going to 
> claim 100x productivity, you're going to have to show some 
> successful examples.

Yes, exactly.  It looks like a good idea to have little simple niche 
languages, but how do we make them easy to maintain?  How do we minimise 
that training cost?

You might need 100x the compactness to justify doing it.  And that might 
be doable -- when it gets to 100,000 lines it's hard to keep it from 
getting bigger, the more that's already there the harder it is to find 
things and the less relative benefit you get from saving the odd 20 
lines here and there.  This is an issue for large C projects, one of the 
things that's hard to do well.  It would only be an improvement for a 
niche language if it could actually meet the needs of the niche, which 
is plausible.  And another 30 years of incremental improvements in C 
methods might make that irrelevant.  But we have these issues already, 
that we'd need to minimise the training costs and the maintenance costs 
generally for a whole family of new languages before those languages 
would even get a chance to compete on a large scale.

> I don't think it's the same today, but in years past Smalltalk 
> was a favorite among consultants for rapid prototyping. Those 
> consultants could demonstrate they were faster than ordinary 
> C coders. Conceptual simplicity rather than "smallness" of the 
> environment or system was the key.

Conceptual simplicity is certainly key in either case.  Now consider, if 
it's going to be a family of niche languages, no one of them can afford 
nearly the maintenance that a popular language will get on its 
compilers.  You need at least two developers making more-or-less 
compatible products or it's defacto proprietary and dead.  It's a lot of 
development and maintenance work, just keeping one niche language going. 
   The less there is under the hood, the better.  The more mechanics it 
takes to create that conceptual simplicity, the more room for bugs.  And 
when the conceptually simple ideas work 98% of the time but the other 2% 
you have to do some arcane workaround that doesn't make any real sense, 
it' not conceptually simple after all.

So if you can do simple mechanics to implement simple concepts, that's 
better because you might actually get it usable at reasonable overhead.

> I note that "light-weight" languages are considered the new 
> choice in rapid development, most of them are scripting 
> languages. All of them I'm aware of have another characteristic: 
> they make it easy to use or coexist with existing C code.

Yes, that's important too.  And that's do-able, depending on the 
variation in C compilers.

> The scripting language Lua has become far more popular than 
> Color Forth as it exists can hope to. It's a small, extensible 
> language -- you just have to use C for the extensions rather 
> than Lua itself.

It makes sense to write tiny efficient routines in C or assembly.

> For a great many people, C has become a virtual machine layer 
> to their code, even if they don't code in C themselves. I think 
> there's a big lesson there for future small languages.

Yes.  Like assembly language.  The point of using a HLL is so you don't 
have to program in assembly or C.

>>But there's the problem that C programmers are perfectly 
>>happy to get the job of maintaining 100,000 lines of C code, and if it 
>>looks too hard they'll ask for an assistant.  While they and their 
>>managers tend to balk at unusual languages.

> All too often, such comments are accompanied by a lament that it 
> shouldn't be that way. Well, it *is* that way. The question is 
> how one intends to deal with it. 

Yes, exactly.  It's fun to talk about how it shouldn't be that way.  Not 
something to be serious about, but a pleasant exchange of posts.  Of 
course complaining that it shouldn't be that way won't change anything, 
and complaining about the complaining won't change anything either.

> If you adopt Chuck's extreme 
> position that files and operating systems are things to be 
> dispensed with, well, don't be surprised if you don't get a 
> lot of business offers. 

Yes, Chuck seems to be doing it on something like a hobbyist basis. 
He's done surprisingly well at getting paid for his innovations.  It 
seems like first he comes up with something new and then somebody finds 
him who's good at marketing innovative ideas.  And they get venture 
capital and continue until the capital dries up, and Chuck goes on 
innovating.

 > But if you develop a language that
> improves on C in some areas and peacefully coexists with the 
> code base, it's an entirely different proposition. Being new 
> hasn't stopped the widespread adoption of Perl, Python, and 
> other languages.

They've tended to grow slowly, except for Perl which is definitely a 
language for specialists and which I believe had its unix niche 
established before the language itself was much developed.

C is useful as a portable assembler, and shops that code in C only are a 
lot like shops 20 years ago that coded in assembly only.  It does no 
good to tell them to look to the future, they're making money now.  Most 
of those assembly shops are long out of business, and I doubt many of 
the C shops will last 20 years.  But if you want it to be different this 
year you'd need to find a way to get the business and outcompete them; 
you aren't going to persuade them.

m-coughlin <m-coughlin@comcast.net> wrote in message news:<3FCE639F.3C2CF193@comcast.net>...
>      A welcome change. You used to complain that people thought
> Forth was the same as the ANS standard and were not interested
> in Chuck's current way of working. Well hardly anybody could
> find out what Chuck was doing since he hardly made anything public.

I still do.  In fact yours is an understatement.  It is a case of
more than non-interest, still bordering on a campaign of mis-
information from various people who have various objections
to the whole idea.  But that is to be expected, it is Forth
after all. ;-)

>       I am not surprised that there has not been more interest
> in ColorForth. It woun't run on most computers and there is no
> easy way to learn to change that. I don't see it as an operating
> system. It is both an operating system AND a programming
> language; the combination is more than the sum of its parts. 

Well, yes, OS + compiler + editor in the kernel and source code
for extensions that get compiled on boot. 

Best Wishes,
Jeff Fox

> Michael Coughlin    m-coughlin@comcast.net    Cambridge, MA USA

Hi Petrus,

Yes, "freaky" is a good word to describe initial impressions of colorForth.
In my EuroForth 2001 paper "colorForth and the Art of the Impossible"
http://www.inventio.co.uk/colorForth%20and%20the%20Art%20of%20the%20Impossib
le.htm I say :

"Chuck Moore described his ColorForth as "brutally simple". Using it has
been compared to "programming an alien computer". It is gloriously
non-standard."

It is difficult to get used to colorForth - it is very different.
My feeling about it now has gone from "freaky" to "hard work", but it is
worth the effort - it's a real gem.

Regards

Howerd  8)






"Petrus Prawirodidjojo" <petrusp@att.biz> wrote in message
news:mailman.5.1070538542.31149.comp.lang.forth@ada-france.org...
>
> ----- Original Message -----
> From: "J.C. Wren" <jcwren@jcwren.com>
> Newsgroups: comp.lang.forth
> To: <comp.lang.forth@ada-france.org>
> Sent: Thursday, December 04, 2003 05:51
> Subject: Re: Colorforth for Other People
>
>
> >         And just for the record, I've tried ColorForth.  I couldn't get
it
> to
> > run on 5 of the 6 machines I had on hand.  When I finally did get it
> > running, the keyboard mapping was just a little too freaky for me.
> >
> >         --jc
>
> I could not find the right word, now you tell me, it is "freaky". Good.
>
> Regards,
> Petrus-Pet4th.
>
>

Hi Petrus,

"Petrus Prawirodidjojo" <petrusp@att.biz> wrote in message
news:mailman.7.1070543119.31149.comp.lang.forth@ada-france.org...
> Why do you think that ColorForth is a Forth?
Because colorForth has two stacks, a dictionary, separate editing, compiling
and execution times, and compiles incrementally.
A trivial modification to the way the editor displays source code ( as
demonstrated in my cfdos DOS reader ) makes the source look like
conventional Forth. You can even copy and paste it into Win32 Forth...
Why do you think colorForth is _not_ Forth???

> It is better to separate those
> two, better not to mix them. Though both ideas are from the same person,
> those two are not necessarily the same.
True. There are hundreds of different Forths out there, only a few were
written by Chuck.
I don't agree that "those two" are separate concepts. They are already
"mixed" by both being Forths!

> Starting Forth is about Forth, not ColorForth.
Starting Forth is about Forth 83 ( IIRC ) - does that mean that ANS Forth
isn't Forth either?

> I read about disappointment that Forth becomes ANSForth.
I have read that Chuck does not like ANS Forth. Personally I love ANS Forth
because it is the only way to get Forth accepted as a mainstream programming
language, and I would like Forth to be more popular.

> That Forth should become ColorForth.
But colorForth already is a Forth. No-one, not even Chuck, can, or should,
limit Forth.

If there is any objection to ANS Forth, it is not to a particular
implementation of it, but to the concept that Forth might in some way be
limited by it.

Just to confuse matters even more, how about adding an ANS compatibility
layer on top of colorForth?
Would that be Forth? My brain is starting to hurt!

> But I also regret that ColorForth is named that way.
Why? Because the name implies that colorForth is a dialect of Forth? But it
is!

> I wish that ColorForth can be more popular and afford a new newsgroup
> specially for it.
We could just clearly label colorForth threads with "Warning : colorForth
can seriously damage your limitations".
That way people of a nervous disposition can skip over them... ;)

What seems to be happening here is that colorForth is being judged in terms
of its performance on the stock market.
Microsoft, Oracle, Novell, Google etc have great share prices, and this is
not unconnected with the fact that their products run on a wide range of
hardware, cater to a mass market, and are supported by some of the biggest
companies on Earth. ColorForth does not run on all PCs and is supported by a
handful of volunteers.

What is very interesting is that the technical aspects of colorForth ( and
other Forths for that matter ) are so easily tossed aside by the dictates of
the computer division of the fashion industry. I think that this is the
nature of business, and that is fine. But in a newsgroup dedicated to Forth
you not only get posts that say how much better other languages are, there
is a tendancy to marginalise colorForth because it just doesn't fit in.

I have responded to numerous posts that seem to be saying the colorForth
isn't really Forth at all, that its a "toy" language not capable of
supporting "real" applications, and now that it should have its own
newsgroup....

Doh!

In fact, colorForth is just a native Forth that runs on a significant
proportion of PC's - specifically, most PC's with AGP/PCI graphics cards and
a floppy disk drive. At EuroForth, the 2003 edition ran on all the laptops
around, including Stephen Pelc's brand new wide-screen super de-luxe 2.8GHz
laptop, although the "cal" function that reports the CPU clock speed
displays it as a negative number - I'll fix this ASAP...

Like all other Forths, colorForth is extensible, so in principle it can be
used to write any program.
In practice, colorForth comes with a design methodology that values
simplicity, and this presents new problems, and new solutions.
I think I will repeat this for the last time, so that I can get on with
writing some colorForth applications : Chuck Moore has created an absolute
gem in colorForth. It really is worth looking at.

Regards

Howerd  8^)

[snip]

"Petrus Prawirodidjojo" <petrusp@att.biz> wrote in message news:<mailman.7.1070543119.31149.comp.lang.forth@ada-france.org>...
> Why do you think that ColorForth is a Forth? 

Now you must be joking. :-)

Forth: a language based on words in a dictionary that use two
stacks.

From that definition we get everything, factoring, the freedom
from reliance on external OS, and the freedom to do things the
way that best matches a given problem.

> It is better to separate those two, better not to mix them. 

Chuck has said that that is why he called the latest creation
colorforth instead of (just plain) Forth.  He said that every
Forth really needs a word to distinguish what flavor of Forth
it is since no single Forth (or standard) can include everything
that is Forth.  This is why he has offered simple definitions
of Forth like the one above.

If anisForth proponents would always remember to call it such
it would be a good thing.  Better to keep that separate from
Forth, better not to mix them up.  Better to keep an open mind
about Forth than to close it or lock the door.

If you have seen a Forth you have seen a Forth.

> Though both ideas are from the same person,
> those two are not necessarily the same.

Right he called the first implementations Forth.  Then to 
distinguish later Forths he called them miniForth, microForth,
PolyForth, cmForth, 3Forth, machineForth and colorforth to
make sure that no flavor is confused with the consistent
theme expressed in each Forth version.
 
> Starting Forth is about Forth, not ColorForth.

Starting Forth was about the PolyForth/MVPForth/... (old)
Forth variants.  There weren't so many back then so people
had less trouble keeping each version separate in the minds
and not confusing any particular versions with the language
itself.
 
> I read about disappointment that Forth becomes ANSForth. 

My disappointment in this regard, and Chuck's I think, is 
that people have come to confuse ANSForth with Forth.  Some
even become so arrogant that they say that Forth means
ANSForth and that they own the term and that Chuck should
stop using the word Forth.  This is a fairly common thing
in the history of many arts.  The students of the founder
branch off into new arts but some insist that they and
only they own the true legacy and that others should stop
using the name of the art that they now own.

> That Forth should become ColorForth. 

Again the disappointment is that people can confuse these
things and this leads to intellectual stagnation.

> But I also regret that ColorForth is named that way. 

Sad.  It is disappointing to see such ignorance championed.

> I wish that ColorForth can be more popular and afford a new newsgroup
> specially for it.

That might be nice.  But there is a nice maillist that is does
not have the posts by colorforth haters or generic Forth haters.
Most of the information posted about colorforth in c.l.f is from
the people who know the least about it.

Best Wishes,
Jeff Fox

m-coughlin <m-coughlin@comcast.net> wrote in message news:<3FCE7FEA.AC7082D4@comcast.net>...

>        Now I know I'm not asking for anything easy. But if Forth
> programmers only do research on how to make Forth run faster and
> use less memory while users of other languages teach the new
> students and write the textbooks, what direction will the art of
> computer programming take?

I think you are talking about Marcel et al. People interested in
colorForth have not overtly concerned themselves with optimization. It
has been reported colorForth is 2.5 times slower than gcc.

> I would like to read about ColorForth
> as an assembly language listing that did not look like it was
> just printed out by a disassembly program.

I would rather read colorForth in colorForth. I would not recomend
going to the assembler source right away if you want to examine it.
You should first interact  with colorForth, build some simple
applications. Then go back to the assembler source, and look for a
correspondce to the behavior you observe. At this point, I still don't
have a full picture of the assembler source. I know from boot to
floppy, graphics, multitaksing, keyboard, compiler, interpreter. Parts
of the editor I have not yet reached.

> Other approaches are
> possible. Right now we have a situation where only a few
> programmers can make sense of ColorForth. Changing the shadow
> blocks is not the way to go. Chuck Moore likes to pack as much
> code as possible into each screen. You need much more than one
> shadow block to explain one block of Chuck's code.

The difference between you and I might be that I am familer with the
programming idioms. A block labeled ASCII with tables on system with a
custom charater set is obviously a conversion table, I don't have much
trouble reading and understanding its purpose. Much of Chuck's
published colorForth code is similarly obvious.

> I once wrote
> a program that took up one half of a printed page and needed
> between ten and twenty pages of scientific papers on quantum
> mechanics to explain what I did, and that was only for my boss
> who was an expert on the topic. My code is not as clever and
> sophisticated as Chuck's, so I expect his code to need more
> documentation than mine.
>

None of the colorForth code Chuck has published needs this kind of
explanation, at least not to a competant programmer. A genuinely new
technique could certainly deserve pages and pages of text.


>         Now I know you have not spent the many years that Irfan
> Skiljan has on his program, but could you even consider using
> ColorForth for such a project? You probably have some other
> purpose in mind. Don't the limits imposed by ColorForth cause
> you some concern? It certainly does to me, since I can't even
> get it running.

Have you tried any of the hosted versions (dos, windows, linux)?

It occured to me a version of colorForth could be made which simply
uses the bios for graphics and floppy. This would give the maximum
compatability that can be acheived for free. Of course the system
would be cripled since you would not be able to save. Maybe the first
task would be to interactively write and test a floppy driver to save
the colorForth image.

As for application signifigance. I didn't propose my jpeg as
signifigant. I don't think it is too far off from signifigant e.g. a
web browser with image support.

I've thought that those without enough foresight to see colorForth is
suitable for signifigant applications, probably wouldn't create any
applications of signifigance to begin with. Now I see that this should
probably be focus, before getting too far into hardware especially to
the level needed to compete with Linux. There should be useful
colorForth applications available on mainstream OSes, hopefully
without comprimizing the internal simplicity of colorForth. My port
for one uses a virtually identical colorForth image.

Mark

Tyler wrote:
 
[snip]
 
> If you agree with me that Color Forth is just a toy, then such
> questions are pretty much irrelevant. If you want people to take
> Color Forth seriously, however, you have to answer the question:
> what conceivable application areas are there where Color Forth
> offers an advantage over existing Forths or other languages?
> So far, I haven't seen a good answer to that question.

     This is an expectation that a new project should be born
all grown up. ColorForth is a collection of new inventions, such
as a different keyboard, the use of color to show functions,
fast compilation of source instead of saving and loading object
code, and so on. It is a test to see if these ideas make
programming easier. The programs you want haven't been written
yet. Maybe there are better programs to do what you like that
haven't been thought of yet and using ColorForth will show what
these programs should be. It wasn't so long ago when I wondered
why new computers had all that complicated code to print a bunch
of overlapping screens. I had to use them for a while to
understand. 

--
Michael Coughlin    m-coughlin@comcast.net    Cambridge, MA USA

jmdrake wrote:
 
[snip]

> . . .  many software management books stress that "programmers
> are the worst documenters of their own code".  I'm not sure if this
> is true or not, but if someone else volunteered to flesh out the
> documentation of ColorForth that would certainly not be outside
> "standard" practice.  As for "guessing at his code" I assume if
> someone did this they could post their comments and then ask
> Chuck "is this what you were saying"?

     This is true in most cases since programmers (especially
Forth programmers) just don't care if anybody else can read
their code. It takes a lot of practice to write both code and
technical documentation, or stories, jokes, novels, poetry, and
whatever. How many programmers want to put as much time and
thought into writing clear documentation as they do in making
their code small and fast? When trying to write documentation
for your own code, there is always a tendency to forget to
document what was obvious and ran without a struggle. But that
part of the code is probably not obvious to other programmers
and would give a lot of trouble if it had to be changed. A
technical writer's job is to see all the hard to understand
parts and make them easy to understand. Its possible to learn to
do that if it is what you are getting paid for.

      Another rule from software management books is to have
code checked by another programmer for readability. They also
say this will not get done unless the boss wants it done. I have
never had a boss who wanted this done. When I've tried to do it
myself, and asked a coworker, "Check my program and tell me what
isn't clear", I've never been able to find one who had any idea
of what I was talking about.

       I hope ColorForth programmers take this up as a
challenge, even if Chuck Moore treats it as a strange idea.

--
Michael Coughlin    m-coughlin@comcast,net    Cambridge, MA USA

Jeff Fox wrote:

[snip]

> . . . people have come to confuse ANSForth with Forth.  Some
> even become so arrogant that they say that Forth means
> ANSForth and that they own the term and that Chuck should
> stop using the word Forth.  This is a fairly common thing
> in the history of many arts.  The students of the founder
> branch off into new arts but some insist that they and
> only they own the true legacy and that others should stop
> using the name of the art that they now own.

      Since most of the currently available literature about
Forth is written for ANS-Forth, it is easy to get confused.
Perhaps as more is written about other versions of Forth, the
arrogance will become less pronounced.

      I'm quite happy to think that Forth is whatever Chuck
Moore says it is. But you can't really use Forth itself. The
term is too broad. You can only use a particular implementation
on a particular computer. Then when you have written enough new
code to do something you like, you no longer have the same
implementation you started with. 

--
Michael Coughlin    m-coughlin@comcast.net   Cambridge, MA USA

Gary Chanson wrote [error corrected]:
 
> "m-coughlin" <m-coughlin@comcast.net> wrote in message
> news:3FCE7FEA.AC7082D4@comcast.net...

> >       I have several programs to display jpeg images.  My
> > favorite is Irfanview (written by Irfan Skiljan) which started
> > out as a student's project in Austria. I tell my friends they
> > don't need to buy Photoshop, they can view, edit and print their
> > pictures just fine with Irfanview.
 
>     Irfanview is a nice viewer and it can do some limited editing, but
> comparing it to Photoshop is laughable.  It's like comparing Notepad
> to a real word processor.  If you'd like a demo of what Irfanview
> can do which Irfanview can not do, I'll be glad to show you.

     Irfanview has many more features than Notepad. I keep
clicking on its menu items and keep finding more surprises.
Photoshop is much too complicated and expensive for my friends
who have trouble plugging in their keyboards and forget how to
format floppy disks.

     What I really wanted to know if there can be a progression
to simplification --  
Photoshop --> Irfanview --> ColorForth with Jpeg decoder
I don't know how ColorForth can read a jpeg file. Actually I
don't even know how to get ColorForth to boot on my computers,
so I'm envious of somebody who can get it to display a jpeg
coded image.

--
Michael Coughlin   m-coughlin@comcast.net   Cambridge, MA USA

----- Original Message -----
From: "Jeff Fox" <fox@ultratechnology.com>
Newsgroups: comp.lang.forth
To: <comp.lang.forth@ada-france.org>
Sent: Friday, December 05, 2003 08:50
Subject: Re: Colorforth for Other People (was Re: ANN cfdos -
EuroForth2003edition)


> "Petrus Prawirodidjojo" <petrusp@att.biz> wrote in message
news:<mailman.7.1070543119.31149.comp.lang.forth@ada-france.org>...
> > Why do you think that ColorForth is a Forth?
>
> Now you must be joking. :-)

I am serious. But I like it that you consider this is a joke, so I can
survive another day or two in this clf, where even big names in this clf do
not dare to tell the truth.

> Forth: a language based on words in a dictionary that use two
> stacks.

Now this time you must be joking. It is too broad so that other programming
language will become Forth.

Regards,
Petrus-Pet4th.

----- Original Message -----
From: "Howerd Oakford" <howerd.oakford@ntlworld.com>
Newsgroups: comp.lang.forth
To: <comp.lang.forth@ada-france.org>
Sent: Friday, December 05, 2003 06:07
Subject: Re: Colorforth for Other People (was Re: ANN
cfdos -EuroForth2003edition)


> "Petrus Prawirodidjojo" <petrusp@att.biz> wrote in message
> news:mailman.7.1070543119.31149.comp.lang.forth@ada-france.org...
> > Why do you think that ColorForth is a Forth?
> Because colorForth has two stacks, a dictionary, separate editing,
compiling
> and execution times, and compiles incrementally.

That is not enough.

> Why do you think colorForth is _not_ Forth???

In its current version, ColorForth is Forth if it is specified as limited
for embedded system only. But when no such limitation is specified, that is,
positioned as general purpose Forth, it lacks "must" features like ASCII .
The difference is too big that it can not be called Forth. It deserves a new
name, not just prefix Forth with Color, so that it looks like ANSForth with
color.

> > Starting Forth is about Forth, not ColorForth.
> Starting Forth is about Forth 83 ( IIRC ) - does that mean that ANS Forth
> isn't Forth either?

FIG/F79, F83, ANSForth are all Forths. ColorForth is Fifth.

> I have read that Chuck does not like ANS Forth. Personally I love ANS
Forth
> because it is the only way to get Forth accepted as a mainstream
programming
> language, and I would like Forth to be more popular.

Yes, you are right. And ColorForth will make Forth to be less popular.

> But colorForth already is a Forth. No-one, not even Chuck, can, or should,
> limit Forth.

I disagree. ColorForth that is targetted as general purpose language is not
a Forth. Not even ...

> Just to confuse matters even more, how about adding an ANS compatibility
> layer on top of colorForth?
> Would that be Forth? My brain is starting to hurt!

No no no, don't hurt your brain. You are right, it then will be ANSForth.
But now it is not ColorForth anymore. ColorForth is supposed to be Forth
without ASCII, floating-point, host os. If ColorForth in its current
condition is because the author lacks time or capability, then it is OK to
called it Forth (maybe someday it will).

> > But I also regret that ColorForth is named that way.
> Why? Because the name implies that colorForth is a dialect of Forth? But
it
> is!

I am embarrassed to be one of the writer of a Forth, but I can not rename
ANSForth to other name. And I can not say that my Forth is a Fifth too.

> > I wish that ColorForth can be more popular and afford a new newsgroup
> > specially for it.
> We could just clearly label colorForth threads with "Warning : colorForth
> can seriously damage your limitations".
> That way people of a nervous disposition can skip over them... ;)

No, I do not mean that. ColorForth has its own place.

> ColorForth does not run on all PCs and is supported by a
> handful of volunteers.

No, it not a problem for me, you mixup with somebody else. I just want
ColorForth be labelled, Forth for very small system, or Forth for embedded
system.

> What is very interesting is that the technical aspects of colorForth ( and
> other Forths for that matter ) are so easily tossed aside by the dictates
of
> the computer division of the fashion industry. I think that this is the
> nature of business, and that is fine. But in a newsgroup dedicated to
Forth
> you not only get posts that say how much better other languages are, there
> is a tendancy to marginalise colorForth because it just doesn't fit in.

Your voice is becoming louder. Remember you are British ;-). I just want
ColorForth to be labelled, Forth for very small system, or Forth for
embedded system.

> I have responded to numerous posts that seem to be saying the colorForth
> isn't really Forth at all, that its a "toy" language not capable of
> supporting "real" applications, and now that it should have its own
> newsgroup....

I do not say it is a toy. I just want ColorForth to be labelled, Forth for
very small system, or Forth for embedded system. If not, then, it should
have its own newsgroup....

> Doh!

Ha ha ha.

> Like all other Forths, colorForth is extensible, so in principle it can be
> used to write any program.

You missed the points of the author. ColorForth is to be without
floating-point. It is not me who limit it. Extensible yes, but the decision
is no.

> In practice, colorForth comes with a design methodology that values
> simplicity, and this presents new problems, and new solutions.
> I think I will repeat this for the last time, so that I can get on with
> writing some colorForth applications : Chuck Moore has created an absolute
> gem in colorForth. It really is worth looking at.

You can make it a gem. Not now.

Regards,
Petrus-Pet4th.

m-coughlin <m-coughlin@comcast.net> wrote in message news:<3FD0021F.52263F3@comcast.net>...
> Tyler wrote:
> > If you agree with me that Color Forth is just a toy, then such
> > questions are pretty much irrelevant. If you want people to take
> > Color Forth seriously, however, you have to answer the question:
> > what conceivable application areas are there where Color Forth
> > offers an advantage over existing Forths or other languages?
> > So far, I haven't seen a good answer to that question.
> 
>      This is an expectation that a new project should be born
> all grown up.

Michael, even if the implementation is rev zero and flakey, we 
should be able to discern the vision or direction.

It was clear from the early work on APL what the author was trying 
to accomplish, despite the primative computers of the day. It's 
doubtful that anyone would invent APL today because so many other 
languages have transcended the limitations of Fortran. ;-)

Even with the continual revisions of Lua, it's easy to discern 
its strengths and weaknesses. If you want a small, portable 
scripting language and like tables as your primary data type, 
Lua's great! (I'm not wild about the Pascalish syntax, but the 
fact that users have addressed the lack of a case/switch statement 
by implementing their own -- with tables, of course -- should 
bring a twinkle to the eye of Forthians with long memories.
<http://lua-users.org/wiki/SwitchStatement>)

So far, two colorForth rationales are apparent:
1) Chuck Moore's private version of Forth for OKAD and other 
projects;
2) A tool for exploring fundamental Forth mechanisms.

The first reason needs only the approval/attention of Chuck himself.

The second is potentially quite profound, at least in the Forth 
realm. I refer to it half-jokingly as a toy, but I'm also aware 
that Rubik's Cube is a toy that can teach you about mathematical 
groups if you look beyond the obvious.

Both of those purposes are of interest to a very small circle of 
Forth devotees, however. It's not at all clear there are other 
purposes for colorForth, and I'd argue that by now they should 
be apparent.

For outsiders, the ability to have '9600' represent either a 
number or a command to change baud rate, depending on its color, 
is an interesting idea. But experienced programmers will know 
that overloading a symbol that way is just asking for trouble. 
And such code examples just reinforce the impression that 
Forthians are out of touch with the rest of the world.

> The programs you want haven't been written
> yet. Maybe there are better programs to do what you like that
> haven't been thought of yet and using ColorForth will show what
> these programs should be.

Perhaps. But all the other languages I've been mentioning have 
allowed people to accomplish real world programming tasks as 
soon as they were released. ColorForth has so much that is 
specific to Chuck Moore and his PC that it's hard to see a 
general case application for it. So far the only substantial 
application is OKAD: a rewrite of an existing app that's used 
by a handful of people.

If Forth is truly an amplifier of programmer skills, shouldn't 
colorForth mature more quickly than other languages? So far I 
haven't seen much evidence it's maturing at all.

Tyler

"Howerd Oakford" <howerd.oakford@ntlworld.com> wrote in message
news:UjOzb.10$dZ1.146512@newsfep2-gui.server.ntli.net...
> My feeling about it now has gone from "freaky" to "hard work",
> but it is worth the effort - it's a real gem.

Let's talk about this statement.

Let's put aside talk about ColorForth being "weird" or "freaky" because
those are the kinds of comments you often hear the first time people start
to play with a new development environment.  Yeah, it's got a strange
keyboard mapping.  Yeah, it does a few other things differently.  We can
talk about these things, or we can talk about things that matter.

What matters more to me is if a development environment provides some
benefit.  Maybe it makes me more productive in terms of time saved or number
of bugs reduced.  Maybe it helps me do something easier that is difficult or
annoying.  Whatever the benefit, it has to be something that is measurable,
quantifiable, and repeatable in order to be worthwhile.  And if it can't
provide a real, tangible benefit, then why bother?

And so, we come to your statement that ColorForth is "worth the effort."
Okay, let's take that at face value.  In order to say it was "worth the
effort," that presumably means you have been able to derive some worthwhile
benefit from using it.  So the first question is obviously what are those
benefits?

But before you answer that, I think you need to put that in some context.
After all, I can remember the first time I used a syntax-directed editor.  I
was initially impressed by it (or rather by the novelty of it), and I
thought it was a terrific tool.  That evaluation was based on using it for a
couple minor projects.  It wasn't until I started to really dive in and
seriously use it that I found that syntax-directed editors didn't match my
style at all.  I thought it might increase my productivity, but after
*really* using it, I found it was quite the opposite.

And so the context I would like you to put your statements about the worth
of ColorForth in is what you have actually done in ColorForth.  I'm not
interested in what you think you *might* do with ColorForth, and I'm not
interested in how you think you *might* benefit from it.  Your statement is
that it is "worth the effort" is in the present tense, and so I expect that
you have, here and now, acquired some benefit from it.  Bonus points if
these benefits are not just abstract things ("seeing Chuck's code, I was
inspired by...", "I have a deeper sense of...", "It is confirmation that a
philosophy of..."), but measurable, quantifiable, and repeatable benefits.

My focus on tangible benefits verses abstract benefits has a purpose.  If
there are tangible benefits to ColorForth, then these are benefits that
others will likely enjoy as well.

Judging ColorForth in objective these terms may be unfair at this point,
since there isn't a lot of real experience to test the limits of the
language.  But since you stated it was "worth the effort," I assume that
means you've done something that at least you consider significant, and that
you've learned something from that.

"Petrus Prawirodidjojo" <petrusp@att.biz> wrote in message news:<mailman.14.1070630361.31149.comp.lang.forth@ada-france.org>...

> No no no, don't hurt your brain. You are right, it then will be ANSForth.
> But now it is not ColorForth anymore. ColorForth is supposed to be Forth
> without ASCII, floating-point, host os. If ColorForth in its current
> condition is because the author lacks time or capability, then it is OK to
> called it Forth (maybe someday it will).

While I agree with most of your points, I disagree on the ASCII issue. 

One could add words to colorForth to read/write host OS files without 
abandoning its essential Forth nature. Similarly, one could develop 
a set of words to import/export colorForth source code from ASCII 
or XML or HTML (the last already done by some) without making it 
any less Forth or colorForth.

Although purists bristled at the outrage initially, giving Forths 
the standard options of blocks *and* files wasn't the end of Forth. 

But colorForthians should learn from the past. Being innovative 
or willfully odd in source code does put substantial limits on 
your ability to communicate with the outside world. (Viz all 
those odd APL characters:
<http://www.users.cloud9.net/~bradmcc/cgi-bin/vuImag3.pl?i=149>)

One of the issues lurking under the covers of the ASCII issue 
is that colorForth was designed for the individual coder, not 
for collaborative efforts. Those HTML source blocks are pretty 
to look at, but they weren't really designed for printing or 
with collaboration in mind. As we've seen recently, people 
discussing colorForth can't easily share code in an ASCII 
format medium such as Usenet, so they wind up pointing to 
URLs of HTML source. Ick.

Tyler

"Petrus Prawirodidjojo" <petrusp@att.biz> wrote in message
news:mailman.14.1070630361.31149.comp.lang.forth@ada-france.org...
> In its current version, ColorForth is Forth if it is specified as limited
> for embedded system only. But when no such limitation is specified, that
is,
> positioned as general purpose Forth, it lacks "must" features like ASCII .
> The difference is too big that it can not be called Forth. It deserves a
new
> name, not just prefix Forth with Color, so that it looks like ANSForth
with
> color.

ANSI did not create Forth. Moore did.

M.

"Petrus Prawirodidjojo" <petrusp@att.biz> wrote in message news:<mailman.14.1070630361.31149.comp.lang.forth@ada-france.org>...
> > Because colorForth has two stacks, a dictionary, 
> > separate editing, compiling and execution times, and
> > compiles incrementally.

I would add to that that the person who invented Forth has
been refining his art for over thirty years and trying to 
get closer and closer to the Forth idea.  That person, the
person who first used the word Forth offered this vision of
Forth as a more modern more accurate incarnation of his
original vision.  Most cultures respect the inventor's
rights to refine their invention.

Only those interested in stealing it will deny this.  Shameful.

I would suggest that if anything ANS Forth should not be called
Forth.  It should probably have been called htrof.  It is more
or less Forth turned inside out and done backwards.  It violates
most of the original principles of Forth.  It was a compromise
between Forth and conventional languages and is about halfway
between Forth and C.  Give it a name like Forth spelled backwards
and call it a C or Unix utility, better than that try to steal
the name and change the meaning completely.
 
> > I have read that Chuck does not like ANS Forth. Personally I love ANS
>  Forth
> > because it is the only way to get Forth accepted as a mainstream
>  programming
> > language, and I would like Forth to be more popular.

Bingo. (for the non=native English speakers that means, you win!
you got the winning combination.)

Exactly.  It is a compromise made to make Forth look more conventional.
As Elizabeth has said, when teaching Forth to C programmers they often
come to realization that Forth looks exactly backwards to them from 
their C mindset.  So if we just run Forth backwards it will look more
like C and be more popular with them.  That is why it should probably
have been called htrof.

Most of them would like to see Forth go away, or at least get put
into its appropriate place as they see it, which is a marginal nitch
of yet another inefficient scripting language for C environments and
so they support the ANS effort to do that.
 
> Yes, you are right. And ColorForth will make Forth to be less popular.

Execellence is not popular.  I prefer quality to popularity.
 
> I disagree. ColorForth that is targetted as general purpose language is not
> a Forth. Not even ...

Missinformation. Chuck has clearly explained that the ideal general purpose
development environment starts with something simple, not with everything
in history glued together.  Trying to build quality on top of hundreds of
megabytes of shifting buggy sand is hopeless.  But it is popular. It
keeps itself going that way. ;-)
  
> No no no, don't hurt your brain. You are right, it then will be ANSForth.
> But now it is not ColorForth anymore. ColorForth is supposed to be Forth
> without ASCII, 

More total missinformation.  Chuck and others have explained that fonts
or character sets really have nothing to do with colorforth.  They have
to do with CAD applications.  The concept of colorforth is something
not bounded to any of that.

You should certainly know that by know.  It has been eight years that
this missinformation has been refuted over and over again.  Since
you could not have missed it I wonder why you persist in posting so
much missinformation about colorforth. 

> floating-point, host os. If ColorForth in its current
> condition is because the author lacks time or capability, then it is OK to
> called it Forth (maybe someday it will).

For some reason the people who know the least about it have the most
to say about it.  They persist in a campaign of missinformation even
when corrected over and over.  They take what Chuck has said, reverse
it exactly, then attribute the reverse logic to Chuck.  Hopefully those
who are open minded appreciate what Chuck has actually said about it.

> I am embarrassed to be one of the writer of a Forth, but I can not rename
> ANSForth to other name. And I can not say that my Forth is a Fifth too.

I feel embarrased to be a Forth programmer when I see Forth programmers
who make such a strong effort to reverse and distort what the founder
of Forth says about Forth.  It is shameful.

I feel embarrased by the hyperboly and advertizing claims made for
ANS Forth.  I know that it is standard practice for the industry
and people want to see Forth marketed more like Windows.

It is espcially funny when these same people reverse it and claim
that they feel embarrased by colorforth.  I'll bet they do. ;-)

It is no different than why most Forth haters hate Forth.  It makes
them feel embarrased by their own pityful practices.  Remember my
description of Chuck's first public presentation about F21.  Chuck
never mentioned C, Intel, Microsoft, Windows, Linux or Pentium
that day.  And I watched closely to see if he said anything offensive,
he didn't.  But at the end a visiting C programmer said that he 
'hated' the presentation because 'Chuck called him an idiot for
using C.'  The fact is that he simply was comparing what he could
do in C to what Chuck was talking about and infered from that that
he would have to be an idiot to use C if what Chuck said about
what he was doing in Forth was true.  This has always been the
biggest problem with Forth.

The solution? Dumb it down to make it more acceptable?  Not the
solution that I would advocate.
 
> Your voice is becoming louder. Remember you are British ;-). I just want
> ColorForth to be labelled, Forth for very small system, or Forth for
> embedded system.

I do not call Pentium computers with 100 to 500MB of RAM (which is
what we are using for CAD) 'very small systems.'  It is very clear
that you would like to mislabel it.  

 What do you call a large system?

> > I have responded to numerous posts that seem to be saying the colorForth
> > isn't really Forth at all, that its a "toy" language not capable of
> > supporting "real" applications, and now that it should have its own
> > newsgroup....

I thought it was funny when Chuck first talked about MuP21 to SVFIG.
He had based the design on his observations that most programs are 1K
or small and that six parameter stack cells and four return stack
cells were quite adequate for good Forth programming.

One of the first questions was "Is it a toy?"  This got quite a
large laugh from the group.

I was talking to Chuck about it a few months later and he gave me
a big laugh.  He said, "Yes, and he said it like a toy was a BAD
thing!"  People are now using that perjorative with respect to
colorforth.  Some things never change. ;-)

> I do not say it is a toy. I just want ColorForth to be labelled, Forth for
> very small system, or Forth for embedded system. If not, then, it should
> have its own newsgroup....

Chuck's main concern with ANS Forth was that it would lead to stagnation
and would completely squelch any spirit of innovation in the Forth
community.  I thought he was WAY off base with that assumption until
I saw the Forth community waste a decade debating with this or that
absurdly wierd code was or was not ANS compliant.  Then I saw people
claiming that 'Forth now means ANS Forth' and I realized that Chuck
had been right on with the concern that ANS Forth could kill off
the spirit of innovation that had defined Forth.  It becomes more
obvious every day when we see posts like yours.
 
> > Doh!
 
Yes, Howard, the ANS Forth logic does sound like it came from
Homer Simpson.
 
> Ha ha ha.

Or the little bully character on the Simpsons who always replies
"ha ha" after some evil deed.
 
> > Like all other Forths, colorForth is extensible, so in principle it can be
> > used to write any program.
> 
> You missed the points of the author. ColorForth is to be without
> floating-point.

You really make up a lot of missinformation.  Chuck has never said
anything like that.  He isn't using floating point in his CAD app
period.  It has nothing to do with the concept of colorforth just
as ASCII or fonts or the Dvorak keyboard are just features of an
implementation.  Colorforth is about using color in place of
syntax, or more generically it is about using visual clues for
the programmer and the compiler.

Other people use visual clues for the programmer.  They colorize
their source to make it clearer to them, but they don't take advantage
of letting the compiler use the visual clues.

> It is not me who limit it. 

It certainly is.  You make this stuff up.  Chuck has never said
anything like what you attribute to him.  Sad.

Best Wishes,
Jeff Fox

"Petrus Prawirodidjojo" <petrusp@att.biz> wrote in message news:<mailman.13.1070630353.31149.comp.lang.forth@ada-france.org>...
> > > Why do you think that ColorForth is a Forth?
> >
> > Now you must be joking. :-)
> 
> I am serious. But I like it that you consider this is a joke, so I can
> survive another day or two in this clf, where even big names in this clf do
> not dare to tell the truth.

Now I can agree with you about that. ;-)
 
> > Forth: a language based on words in a dictionary that use two
> > stacks.
> 
> Now this time you must be joking. It is too broad so that other programming
> language will become Forth.

What other languages are based on 'words' that are factored into
small definitions by use of a parameter stack?  What other languages
do you think are Forth.

I was just offering the defintion given by the person who invented
the language.  In his 1xForth presentation he said 'What is Forth?
That is a question that I have been trying to answer for many 
years.' (or something very similar.)  Then he proceeded to offer
the definition that I gave above.  From the horse's mouth as we
say in English.  No joke. ;-)

Of course people love to reverse things in c.l.f and I have
often read that my objection to ANS Forth is that it didn't go
far enough and doesn't specify enough details. Now that's funny. :-)

Best Wishes,
Jeff Fox
 
> Regards,
> Petrus-Pet4th.

----- Original Message -----
From: "Myles" <a@b.c>
Newsgroups: comp.lang.forth
To: <comp.lang.forth@ada-france.org>
Sent: Saturday, December 06, 2003 06:16
Subject: Re: Colorforth for Other People (was Re:
ANNcfdos-EuroForth2003edition)


>
> "Petrus Prawirodidjojo" <petrusp@att.biz> wrote in message
> news:mailman.14.1070630361.31149.comp.lang.forth@ada-france.org...
> > In its current version, ColorForth is Forth if it is specified as
limited
> > for embedded system only. But when no such limitation is specified, that
> is,
> > positioned as general purpose Forth, it lacks "must" features like ASCII
..
> > The difference is too big that it can not be called Forth. It deserves a
> new
> > name, not just prefix Forth with Color, so that it looks like ANSForth
> with
> > color.
>
> ANSI did not create Forth. Moore did.
>
> M.

Really? You must have skipped Marcel's opinion:
------------------------------------------------------------
Chuck is (probably) a genius, because he stood at the
beginning of Forth as I know it. Without him, it wouldn't
be here now. But, maybe contrary to other languages, Chuck
Moore has had only a very tiny influence on how Forth actually
looks like today. If I check the current crop of Forths with large
userbases, or the Forths used by people that seem to be really
doing significant stuff with it, I don't see direct influences
by Chuck.
--------------------------------------------------------------
Ok, assuming you are right. So is it up to the creator to name the next
creation as the same as previous one, even if they are only slightly
similar?

If  FIG knew in advance that later there will be ColorForth as it is now in
present form, they better choose other name, so everybody will be happy.

By the way, Microsoft will charge manufacturers for each device that
delivered with FAT system in it, USB Flash disk, Digital Camera and others.
The FAT is created in 1976 according to Microsoft. The patent is of 1992,
1993, 1995 and 1996 iirc. After more than 20 years, when FAT is used
anywhere, and Microsoft starts collecting money. Don't you think it is too
late, and therefore unfair?

Regards,
Petrus.

----- Original Message -----
From: "Jeff Fox" <fox@ultratechnology.com>
Newsgroups: comp.lang.forth
To: <comp.lang.forth@ada-france.org>
Sent: Saturday, December 06, 2003 11:09
Subject: Re: Colorforth for Other People (was Re: ANN
cfdos-EuroForth2003edition)


> "Petrus Prawirodidjojo" <petrusp@att.biz> wrote in message
news:<mailman.14.1070630361.31149.comp.lang.forth@ada-france.org>...
> > > Because colorForth has two stacks, a dictionary,
> > > separate editing, compiling and execution times, and
> > > compiles incrementally.

Jeff, you compose it this way as if the comment is from me. It is not.

I am not stealing Forth from Chuck. Nobody does. It is only in your mind.

Your response is way far from my opinion. In OS term, it is cross link. Just
like the sample above, I do not write the comment. Dyslexia is confusing
right and left. It is not dyslexia, don't know what. Par.. para.. paran..,
ah give up, I forget. I think this is a sign I should go back to my nest.
The computer is becoming hot so it crashes.

Ha ha ha.

Regards,
Petrus-Pet4th.

In article <4c45abad.0312041914.35b874a8@posting.google.com>, Mark Slicker 
wrote:
> It occured to me a version of colorForth could be made which simply
> uses the bios for graphics and floppy. This would give the maximum
> compatability that can be acheived for free. Of course the system
> would be cripled since you would not be able to save. Maybe the first
> task would be to interactively write and test a floppy driver to save
> the colorForth image.

Do you know something about the floppy BIOS that I don't? AFAIK, the
BIOS is perfectly capable of writing to floppies.
-- 
Roger Ivie
rivie@ridgenet.net
<input type crash>

"Petrus Prawirodidjojo" <petrusp@att.biz> wrote in message news:<mailman.27.1070694497.31149.comp.lang.forth@ada-france.org>...
> 
> I am not stealing Forth from Chuck. Nobody does. It is only in your mind.

I was just refering to people who say that what they do is Forth and
that what the inventor of Forth does is not Forth.  In that sense they
want to steal the name Forth from the inventor.

It certainly seemed like you said that Chuck should not use the
name 'Forth' now that you have have redefined it your own way. ;-)
 
> Ha, ha, ha.

And a Ho Ho.

Best Wishes,

nlper@junglemate.com (Tyler) wrote in message news:<65d29696.0312051455.cc18889@posting.google.com>...
> One of the issues lurking under the covers of the ASCII issue 
> is that colorForth was designed for the individual coder, not 
> for collaborative efforts. 

You must have missed my correct of that missinformation in the
past.  Colorforth came out of OKAD being done at iTV and being
used by other people.  Chuck intended it for use by other
people and has clearly stated this.  He even got a good 
laugh when I told him that someone made this comment
previously in c.l.f.

> Those HTML source blocks are pretty to look at,

I don't know how pretty they are, but they are colorful!

> but they weren't really designed for printing or 

Nonsense.  Chuck was printing them in 1996.  He has shown 
plenty of examples on many occasions.  In fact when he first
used it it was used for scripting of CAD testing where he would
run it at night and in the morning look at the printouts of the
scripts and their results.  It started out designed for printing.

> with collaboration in mind. 

Nonsense again.  This issue has been correct on numberous
occasions in the past.  Either you missed them or you are
intentionally publishing missinformation for some reason.

> As we've seen recently, people 
> discussing colorForth can't easily share code in an ASCII 
> format medium such as Usenet, so they wind up pointing to 
> URLs of HTML source. Ick.

I often exchang code with Chuck.  It is not in ASCII of
course.  That is a non-issue.  It was not designed to use
ASCII.  It can be converted fairly easily.  Howerd has
explained that a simple utility can convert it into
standard looking ASCII characters that even ANS Forth
programmers can read.  He has also explained to this group
that some of it can be as easily pasted into an ASCII
ANS Forth as anything else.

Ick to missinformation!

Best Wishes,
Jeff Fox

"Jeff Fox" <fox@ultratechnology.com> wrote in message
news:4fbeeb5a.0312061459.4dc12393@posting.google.com...
> "Petrus Prawirodidjojo" <petrusp@att.biz> wrote in message
news:<mailman.27.1070694497.31149.comp.lang.forth@ada-france.org>...
> >
> > I am not stealing Forth from Chuck. Nobody does. It is only in your
mind.
>
> I was just refering to people who say that what they do is Forth and
> that what the inventor of Forth does is not Forth.  In that sense they
> want to steal the name Forth from the inventor.

    It could be argued that since Chuck released Forth into the public
domain without any restrictions, that he has lost the right to call
something else "Forth".

    I'm not claiming to make that argument and I'm not sure that ColorForth
is not a reasonable evolution of Forth (but I have some doubts).

-- 

-GJC [MS Windows SDK MVP]
-Software Consultant (Embedded systems and Real Time Controls)
-gchanson@mvps.org

-Abolish public schools

In article <ddwAb.1088$Ji.593@nwrdny02.gnilink.net>, Gary Chanson wrote:
> 
>     It could be argued that since Chuck released Forth into the public
> domain without any restrictions, that he has lost the right to call
> something else "Forth".

Except that if it's in the public domain he has as much right as
anyone else to call what he's doing "Forth".
-- 
Roger Ivie
rivie@ridgenet.net
<input type crash>

Mark Slicker wrote:
 
> m-coughlin <m-coughlin@comcast.net> wrote in message news:<3FCE7FEA.AC7082D4@comcast.net>...

[snip]

> > I would like to read about ColorForth
> > as an assembly language listing that did not look like it was
> > just printed out by a disassembly program.
 
> I would rather read colorForth in colorForth. I would not recomend
> going to the assembler source right away if you want to examine it.
> You should first interact  with colorForth, build some simple
> applications. Then go back to the assembler source, and look for a
> correspondce to the behavior you observe. At this point, I still don't
> have a full picture of the assembler source. I know from boot to
> floppy, graphics, multitaksing, keyboard, compiler, interpreter. Parts
> of the editor I have not yet reached.
 
      I can't read ColorForth in ColorForth since I can't run
ColorForth to begin with. I can read the html translation of
ColorForth on the web. On one browser on one computer, the text
does not show up in color. On another browser on another
computer, the text shows up in color in very large letters.
Neither browser show the shadow screen next to the code screen.
 
> > Other approaches are
> > possible. Right now we have a situation where only a few
> > programmers can make sense of ColorForth. Changing the shadow
> > blocks is not the way to go. Chuck Moore likes to pack as much
> > code as possible into each screen. You need much more than one
> > shadow block to explain one block of Chuck's code.
> 
> The difference between you and I might be that I am familer with the
> programming idioms. A block labeled ASCII with tables on system with a
> custom charater set is obviously a conversion table, I don't have much
> trouble reading and understanding its purpose. Much of Chuck's
> published colorForth code is similarly obvious.

      I have too much trouble reading and understanding its
purpose. There is a certain style of writing source which I can
study and see exactly what every byte is doing. ColorForth is
not it. 
 
> > I once wrote
> > a program that took up one half of a printed page and needed
> > between ten and twenty pages of scientific papers on quantum
> > mechanics to explain what I did, and that was only for my boss
> > who was an expert on the topic. My code is not as clever and
> > sophisticated as Chuck's, so I expect his code to need more
> > documentation than mine.
> 
> None of the colorForth code Chuck has published needs this kind of
> explanation, at least not to a competant programmer. A genuinely new
> technique could certainly deserve pages and pages of text.

      A competent programmer is one who can explain what he is
doing to another programmer.  The amount of time and study the
other programmer must spend is inversely proportional to the
competency of the first one.

> >         Now I know you have not spent the many years that Irfan
> > Skiljan has on his program, but could you even consider using
> > ColorForth for such a project? You probably have some other
> > purpose in mind. Don't the limits imposed by ColorForth cause
> > you some concern? It certainly does to me, since I can't even
> > get it running.
 
> Have you tried any of the hosted versions (dos, windows, linux)?

     My interest in ColorForth is based on its being a stand
alone system. If  I can't use it standalone, then I will spend
my Forth research time on ciForth or cmForth.

      I did try something connected with ColorForth that ran
under MS-Dos, but I lost interest when I saw it was not
ColorForth. It seemed to be a regular Forth with colors, a
regular keyboard interface and an unknown list of Forth words.
 
      From what I've read about ColorForth, I can't see any
advantage to most of its new feature. But I know I can't be sure
unless I try using them for a while.

> It occured to me a version of colorForth could be made which simply
> uses the bios for graphics and floppy. This would give the maximum
> compatability that can be acheived for free. Of course the system
> would be cripled since you would not be able to save. Maybe the first
> task would be to interactively write and test a floppy driver to save
> the colorForth image.

      You mean ColorForth uses its own drivers and doesn't call
the routines in the BIOS? Well no wonder it doesn't work on my
computers. I'm surprised it works on anything except the board
it was originally developed with. BIOS code has to be tweaked
and patched for every motherboard design it is used on. Maybe
after the BIOS code initializes the interface chips it can be
bypassed, but I'd still expect there to be only certain
combinations of parts that would work with any given code unless
a small army of hackers tests the daylights out of everything
available and did a lot of debugging.
 
--
Michael Coughlin    m-coughlin@comcast.net    Cambridge, MA USA

"Mark Slicker" <maslicke@oakland.edu> wrote in message
news:4c45abad.0312011418.5f569441@posting.google.com...
> I more associate you with the status quo than I do with
> ANS Forth. Mostly it is the repetition of the idea that all
> things are equal just different.

I'm not sure where you get that from what I have wrote.  If I really
believed that, why would I use Forth or any of the other languages I use in
my work?  It would be far easier to follow the herd and just use C for
everything.  Yet, in a typical week, I'm probably coding in at least four
different languages out of a pallet of probably a couple dozen.  Assembler,
C, Forth, Scheme, Lua, Perl, Python, C#, Java, and so on, not to mention
dozens of "little languages" that I've written to address specific
problems-- if nothing else, that *clearly* shows that I don't think all
things (specifically languages) are equal.

The reason I use a variety of languages in my work is because they *aren't*
equal.  Each has a different set of positive and negative qualities, and I
pick and choose them depending on what I need to do.  I am primarily an
embedded systems software engineer, but I do lots of other work too outside
my job title.  And if anything, the wide range of software projects I tackle
has shown me that no one language best suits everything.  More often than
not, those who disagree with this view are programmers who work only in a
particular field.  More often than not, those who disagree with this view
are programmers who don't understand that the world is not limited to their
experience.  But that's true of lots of things, not just programming.

> There is actually a technical term for this philosophy,
> "relativism" or "absolute relativism". Do a google search of
> these terms. Naturally this philosophy is perfect for the
> status quo since there can be no objective criticism of it.

And you're wrong there too.  I don't need to do a Google search on
relativism, because I've argued passionately against various applications of
relativism (especially moral relativism) for many years now.  But that has
little to do with comp.lang.forth, and I'll leave it to others to seek out
my position on various applications of relativism if they care.

> Would it be significant otherwise? It is more concise than any
> code I've seen. A new version (not released) shows additional
> improvements in quality, speed, and conciseness. Some of these
> qualities are derived directly from its expression in colorForth. An
> assembler version would most likely be faster, but assembler is
> both clumsy and non-portable. A C version, also clumsy, would be
> ignored I think because the IJG code exists and C programmers
> do not mind size nor the ugliness of this code. Once their code is
> functional, C programmers tend to move in the direction
> completeness and generality. I think my JPEG code is most valuable
> as part of a simple comprehensible system.

I have to chuckle whenever I see people like you make blanket pronouncements
about a class of people-- in this case C programmers.  Saying "C programmers
do not mind size or the ugliness of this code" suggests there is a single
(or even a dominate) mindset in C programmers, and further, that you are
qualified to discuss this mindset.  In my experience, I see (and work with!)
all kinds of C programmers, with all kinds of views and opinions.  I can't
neatly sum them up in a statement like you can, but then again, I'm more
interested in reality, and not repeating a fantasy in hopes others will
believe it.

It's ironic.  If someone was to come in to comp.lang.forth or a ColorForth
mailing list and start off a message with "All Forth programmers _____"
there would be no end to the passionate disagreement.  Yet people like you
have no problem discussing C programmers as if they were part of a single
unified mindset.

> So your concern is that an application that deals directly with
> the user will show some limitation in the system. This is fair
> game.

Let me clarify my view on this.  I don't think one can *really* judge a
language until one has done something significant with it.  The word
"significant" is deliberately ambiguous, in part because I don't see a
single objective standard for what is significant.

I used to be a big fan of tawk (a souped-up awk variant) for my text
processing work.  During the period I used tawk, I used it for hundreds of
small text transformation tasks.  I got to the point where people would come
into my office, start describing a particular kind of text transformation
they needed, and usually in just a couple minutes, I could whip off a script
that would do what they wanted.

Seeing this, I started to attempt larger and more ambitious programs in
tawk.  The first was an assembler for a proprietary DSP.  The second and
third were for my volunteer work in Fidonet; an application that culled
Usenet newsgroup articles from a satellite feed and converted them into
Fidonet form, and an application that implemented a usage-based billing
system for the local Fidonet network.  And the final application was one
that took data from a block-based mainframe UI and converted it to nicely
formatted web pages on the fly.  I figured that tawk was ideal for these
applications since they all were essentially text transformation tasks.  And
since tawk had done so well in simpler text transformation tasks, I figured
it would work great for these applications too.

It didn't.  It wasn't a complete failure (the applications worked), but what
writing these applications showed me was that tawk had serious scalability
problems that made it unsuitable for these particular tasks.  Why tawk
didn't scale isn't important here.  What is important was that until I had
attempted to do something serious and complex did I really learn the limits
of the language.

Your JPEG decoder is probably the largest set of code (outside of OKAD) that
is mentioned.  But I don't see a JPEG decoder as stressing the ColorForth
environment.  At least, I don't remember seeing any messages from you
describing any case where you "bumped your head" with ColorForth, or where
you found the environment lacking.  That either means that ColorForth is
perfect or that you simply haven't hit the limits yet.  When you hit the
limits, I want to hear about it, because it is then we'll actually start to
*learn* something.

This is my concern for ColorForth.  ColorForth is presumably the ideal
language for OKAD, since Chuck designed it for that purpose.  But I don't
have any real sense of if ColorForth can scale to the kinds of real-world
applications that people use every day.

For discussions like this, I like to use my Mom.  I think she's a typical
user of computers.  At work, she uses a ERP system for the company she works
for.  At home, she likes to surf the web, exchange email with the family and
friends, tracks various personal financial data in spreadsheets, type
numerous lists and letters in a word processor, and play games.  She's just
getting the hang of listening to streaming audio.  And now that she has a
grandson, she's enjoying viewing digital snapshots of him.

I think she's a typical computer user using a typical mix of applications.
She doesn't understand programming at all, and has absolutely no interest in
learning.  She doesn't care in the least what programming language(s) were
used to create the applications she uses.  What she cares about is having a
computer help her do her work, to be a fun diversion, and in general to make
life easier.  Oh, and she wants it to be easy and intuitive (or at least if
it can't be intuitive, she wants it to be easy to learn).

When ColorForth gets to the point of delivering applications to end users
that let's them (and not programmers) do what they want, *then* I think
we'll get some useful feedback on the scalability and overall value of
ColorForth.  Until then, what we have is a bunch of programmers who are
essentially making predictions about ColorForth's scalability and overall
value based on some toy applications they've written.

> If we take a look at current applications, colorForth is basically
> a single window interface with a remapable key layout. Mouse
> interaction could be easily handled. One limitation might be the
> need for independent interactions, for example a multiple windowed
> desktop. In this case you need to introduce a piece of code which
> manages the display and input differently from the present code.

Yep, and that would be the start of the significant applications I am
talking about.  Another needed facility would be a means to support multiple
concurrent applications.  My Mom often runs multiple applications at once.
She might be listening to music in the background while she's receiving mail
and at the same time playing a game.  She as an end user of ColorForth
applications would not accept running a single program at a time, nor would
she accept purchasing multiple dedicated devices each optimized for a
specific task.  I doubt most modern computers users would either.  (Look at
today's cell phones for an example-- some now integrate a MP3 player, a
digital camera, web browsing, games, PIM functions, and yes, a telephone.
The idea that someone would want to carry all those devices around
separately is stupid.)

ColorForth is going to need to be able to handle multiple applications at
the same time-- and that gets into a scalability issue.  How should multiple
concurrent applications work in ColorForth?  Should
the multitasking be
cooperative or preemptive?  How should ColorForth manage dictionaries for
each application?  Multiple dictionaries?  A single dictionary with
namespaces?  Applications can start and end at any time.  How is the memory
occupied by those dictionaries (along with any other storage allocated for
the application) going to be managed?

Writing that user interface layer, and not a JPEG decoder, would be a
significant set of code and would be part of the answer in finding the
limits of ColorForth.

> Another issue is how data is stored and the location. For the
> icon editor there is only one font and it is global. Chuck's chips
> seem to be encoded in colorForth through the editor. Here the
> block locations are likely explicitly specified. I think there is a
> need for a higher level that doesn't presently exist. A flat
> database of application data. Maybe my view is different from
> Chuck's in this aspect.

My Mom (like most rational humans) isn't going to remember that she stored
pictures of her grandson at blocks 2843, 4390, and 5304, her shopping list
at 3495, and that to start her email client, she need to load block 8825.
That's insane.  End users need to store data in terms of something symbolic.
Maybe each application allocates a set of blocks and provides the user with
a simple directory within that space.  Maybe it's a traditional file system
with a more free-form allocation of blocks.  Maybe it's some kind of
high-level object database.  Maybe it's something entirely new and
different.  But whatever it is, it won't be raw blocks.  That's just stupid
for end users.

Raw blocks are fine for programmers who in general are accepting of
remembering useless trivia like "Chuck uses blocks 0 through 63" and "I last
stored my word list at block 800."  But before any significant applications
are written for end users, they are going to need something higher-level and
symbolic.  (I'm waiting for the first ColorForth programmer who suggests
that the ColorForth dictionary is an appropriate place for end users to
store these symbolic names for blocks.)

Writing that storage layer, and not a JPEG decoder, would be a significant
set of code and would be part of the answer in finding the limits of
ColorForth.

> The issue of data is a fundamental one in system design. As much
> as I admire colorForth, I find attractive the pure elegance of
> functional systems. In a functional system all data is expressed in
> the type system of the language and remains persistent until no
> reference of the data exists. The kind of code as data that Chuck
> uses in OKAD seems like a one way street, modification is through
> the editor, mechanical processing only seems to apply to
> interpretation of the data. In the general case it seems we are left to
> define binary formats and the methods for modification.

More than anything else, this is probably my biggest problem with
ColorForth.  In most modern languages, I can create structured data of
arbitrary complexity, and by calling some simple routines I can serialize
that data to an abstract stream.  This works because I can do reflection on
the structure of the data in a generic way.  This lets me know that future
invocations of my application can reliably recreate the data I had at some
point in the future.  And I know that when the data is deleted, underlying
mechanisms will handle the storage management issues.  It's the same reason
why I could use a manual screwdriver, but I prefer using an electric one.

ColorForth doesn't have any kind of support for persisting data, other than
to dump what's in memory to a floppy.  If I want to share data between
applications, I better know the *exact* binary form that data takes.
ColorForth doesn't even have the ability to do what many scripting languages
can do to serialize data-- write out a program that when later executed
recreates a data structure.  Since program source in ColorForth is in an
encoded form, one would need to write out that same encoded form, which
requires intimate knowledge of that encoding.  Ick.

Writing that persistence layer, and not a JPEG decoder, would be a
significant set of code and would be part of the answer in finding the
limits of ColorForth.

> > I assume the above was addressed to "Tyler" and not me.  I in fact
> > am all for even more diversity than the ColorForth community seems
> > to want, by viewing ColorForth not as an implementation, but as a
> > statement about programmers creating their own individual and unique
> > programming languages and environments.
>
> This view is marginalizing for a general purpose programming language.
> A language that can't scale beyond a single person and a single
> context is worthless. No one wants to maintain a thousand dialects of
> language and applications written in these dialects, nor does anyone
> want to reinvent the same code over and over again for each dialect.

I can't remember where I read it, but somewhere on Jeff Fox's site you'll
find a statement from Charles Moore that says, in effect, that programmers
should create their own Forths to meet their own needs.  Charles obviously
believes this himself, as he has veered far away from ANS Forth, and has
implemented over the years a number of Forths that are only compatible with
themselves.  ColorForth is just another in a long line of Forths that stands
alone.  While it may share ideas from his past efforts, ColorForth is in no
sense compatible with the past.

The message of ColorForth-- at least to me-- is that a programmer shouldn't
be afraid to design their own language around their own needs.  I don't see
that as marginalizing at all.  If anything, that is a uniquely empowering
statement-- quite different from the mainstream.  It's deeply ironic that
you find my statement-- which I see as nothing more than what Charles Moore
himself has said-- as marginalizing.  You're championing a language that by
it's very design goes against the mainstream-- and that goes against the
idea that there should be a singular standard because programmers don't want
to reinvent wheels.  Charles Moore reinvents wheels all the time!
ColorForth is a reinvented wheel.  Specifically, it's a better wheel (to
him, at least) than his past wheels!

> Robust and well-written code is an invaluable asset. This does
> not imply we have to accept colorForth in its present form, this
> does not imply we need a colorForth standard. Many languages
> exist today with no standard, only a community which accepts
> basic premises, the interactions of which produce an evolution
> of the language. In this case the implementation is the standard.

Evolution tends to evolve towards increasingly more complex organisms in
order to survive.  Programming languages are much the same way, and I
fearlessly predict that ColorForth will only grow in complexity, not shrink.
And it is going to do this because if ColorForth is to tackle the kinds of
real-world applications that end users want, it is going to need a set of
standards.  It's going to need a standard for a competitive user interface
to modern windowing systems.  It is going to need some model for
multitasking.  It is going to need a dictionary model that can handle
multiple applications at once without collisions.  It's going to need a
means to persist data in a way that makes sense to end users, and in a way
that programmers don't have to worry about physical displacements and data
types.  It's free to use whatever character encoding it wants internally,
but it is going to have to allow end users to manipulate data using a
real-world (not a programmers-world) character set.

In short, it's going to need a lot of things that other languages have found
necessary, because programmers (eventually) find these things necessary as
they tackle more significant applications.  And along the way, there is
going to be discussion and disagreement.  You're going to have the camp that
says these things are unnecessary, and the camp that says they are vital.

And that's the point that ColorForth is going to get interesting.  At the
point in time when programmers with vastly different experience and needs
start to question the design decisions of Charles Moore (instead of simply
accept those decisions as if from on high), ColorForth will start to matter.
But, that is also the same time that ColorForth will probably split into a
variety of implementations.

> > Have fun there.  And do keep the rest of us informed when
> > ColorForth matures.  I'd love to see what happens to the
> > language after more people start to stress it and discover the
> > weaknesses.
>
> It has not been as much fun as I would have hoped. I really thought
> people would take the ball and run with it. I had no idea of the kind
> battles to be fought and the strange group politics that have come
> with the Forth association. If I'd known this I might have created an
> environment with no association to Forth or Chuck Moore. I still may
> do this.

I don't understand, but then I don't read the mailing list.  What kind of
"strange group politics" are you talking about?  You surely don't mean any
conversation in comp.lang.forth, since what happens here has little to do
with the private world of the ColorForth mailing list.  And indeed, I don't
know why ColorForthers would care about any conversation here in
comp.lang.forth.

So for those on the outside, clue us in.  What's the "strange group
politics" you're talking about in the ColorForth community?

Tyler wrote:
> 
> m-coughlin <m-coughlin@comcast.net> wrote in message news:<3FD0021F.52263F3@comcast.net>...

[snip]
> 
> > The programs you want haven't been written
> > yet. Maybe there are better programs to do what you like that
> > haven't been thought of yet and using ColorForth will show what
> > these programs should be.
> 
> Perhaps. But all the other languages I've been mentioning have
> allowed people to accomplish real world programming tasks as
> soon as they were released. ColorForth has so much that is
> specific to Chuck Moore and his PC that it's hard to see a
> general case application for it. So far the only substantial
> application is OKAD: a rewrite of an existing app that's used
> by a handful of people.
> 
> If Forth is truly an amplifier of programmer skills, shouldn't
> colorForth mature more quickly than other languages? So far I
> haven't seen much evidence it's maturing at all.

     Forth was, at one time, only a software system for
gathering data from one astronomical telescope. Then some people
other than Chuck Moore wrote enough documentation and
modifications for it to be used by astronomers all over the
world, and then be used for applications not connected to
astronomy. Perhaps the right other people haven't shown up yet
to get ColorForth out of its narrow niche. Or perhaps ColorForth
is just not suitable for wider uses. Time will tell.  Forth was
never invented to be a cure-all for every programming problem,
just a way to do one job at a time. But maybe somebody will come
along and decide the one job that he wants to use Forth for is
to be a cure-all for every programming problem.

--
Michael Coughlin     m-coughlin@camcast.net     Cambridge, MA USA

Jeff Fox wrote:
 
> "Petrus Prawirodidjojo" <petrusp@att.biz> wrote in message news:<mailman.14.1070630361.31149.comp.lang.forth@ada-france.org>...
 
> I would suggest that if anything ANS Forth should not be called
> Forth.  It should probably have been called htrof.  It is more
> or less Forth turned inside out and done backwards.  It violates
> most of the original principles of Forth.  It was a compromise
> between Forth and conventional languages and is about halfway
> between Forth and C.  Give it a name like Forth spelled backwards
> and call it a C or Unix utility, better than that try to steal
> the name and change the meaning completely.
 
    I mentioned something about changing Forth's name. Nothing
happened. So now I mention why you can't change Forth's name.
Another name would imply that there is something missing from
the essential qualities that Chuck Moore gave to Forth. Nobody
who knows what Forth is would want to have any less capability,
even tho everybody wants to add and subtract their own list of items.

> > I have read that Chuck does not like ANS Forth. Personally I love
> > ANS Forth because it is the only way to get Forth accepted as a
> > mainstream programming language, and I would like Forth to be
> > more popular.

> Bingo. (for the non=native English speakers that means, you win!
> you got the winning combination.)
 
> Exactly.  It is a compromise made to make Forth look more
> conventional. As Elizabeth has said, when teaching Forth to
> C programmers they often come to realization that Forth looks
> exactly backwards to them from their C mindset.  So if we just
> run Forth backwards it will look more like C and be more popular
> with them.  That is why it should probably have been called htrof.
 
> Most of them would like to see Forth go away, or at least get put
> into its appropriate place as they see it, which is a marginal nitch
> of yet another inefficient scripting language for C environments and
> so they support the ANS effort to do that.
 
      ANS-Forth does not look conventional. The compromise to
the "C" way of doing things the ANS standard tried to make was
to present Forth as an unvarying language so that company
managers (who sign the checks and don't read program code) would
think Forth would be the same all over. Or think that an ANS
standard language is better than a non-standard one. Well its
not, and they find out. ANS-Forth is just a little bit more
uniform than regular wild Forth.

       C programmers would like to see Forth go away because
every time they hear about Forth from a missionary, such as
myself, they hear a lot of talk and see no useful application
they can run on their hardware.

> > Yes, you are right. And ColorForth will make Forth to be less popular.
 
> Execellence is not popular.  I prefer quality to popularity.

     So do I. I especially admire excellence in documentation
and technical writing.
 
> > I disagree. ColorForth that is targetted as general purpose language
> > is not a Forth. Not even ...
 
> Missinformation. Chuck has clearly explained that the ideal general
> purpose development environment starts with something simple, not
> with everything in history glued together.  Trying to build quality on
> top of hundreds of megabytes of shifting buggy sand is hopeless.
>  But it is popular. It keeps itself going that way. ;-)
 
     Once a certain size is reached, software systems grow until
they collapse. They are like trees. The old tree in front of my
house got so big that its branches fell off from their own
weight. In the case of software, the collapse is because nobody
understands what has been written well enough for the code to be
maintained. Going back to a very small system could be a cure
for that. But then again, if you keep cutting back too much you
never have anything big enough to do something useful.

[snip]
 
> Chuck's main concern with ANS Forth was that it would lead to
> stagnation and would completely squelch any spirit of innovation
> in the Forth community.  I thought he was WAY off base with that
> assumption until I saw the Forth community waste a decade debating
> with this or that absurdly wierd code was or was not ANS compliant. 
> Then I saw people claiming that 'Forth now means ANS Forth' and
> I realized that Chuck had been right on with the concern that ANS
> Forth could kill off the spirit of innovation that had defined Forth.
> It becomes more obvious every day when we see posts like yours.

     The debate with the weird code is an attempt to learn how
Forth works. It is a reflection of the poor communication among
Forth programmers. The members of the standard committee had a
good time meeting and discussing how Forth does work and how it
should work. They had a bad time when they couldn't agree, spent
so long traveling, and missed out on paying jobs. But all that
work and study did not result in a new crop of Forth textbooks
to replace the old ones. Those who made innovations in Forth
wrote less about their progress than those who wanted to
document a standard Forth.

[snip]

> > > Like all other Forths, colorForth is extensible, so in principle it can be
> > > used to write any program.
> >
> > You missed the points of the author. ColorForth is to be without
> > floating-point.
> 
> You really make up a lot of missinformation.  Chuck has never said
> anything like that.  He isn't using floating point in his CAD app
> period.  It has nothing to do with the concept of colorforth just
> as ASCII or fonts or the Dvorak keyboard are just features of an
> implementation.  Colorforth is about using color in place of
> syntax, or more generically it is about using visual clues for
> the programmer and the compiler.
 
> Other people use visual clues for the programmer.  They colorize
> their source to make it clearer to them, but they don't take advantage
> of letting the compiler use the visual clues.

     I don't know why we have so much trouble with floating
point arithmetic and files. Why don't people consider them to be
applications to be written for a Forth system? Does anybody get
upset if an assembler doesn't somehow have a file system built
in? Or if an assembler for a microprocessor without floating
point hardware doesn't have floating point instructions? Why
don't people who need file systems and floating point just
ignore Forth systems that don't come with those and let
programmers who write for little embedded processors do their
thing? I guess its because programmers first learn a language
like C then can't think without a Unix (or Windows) operating
system. Maybe if they first learned on a small simple Forth
system we wouldn't have this problem.

     So now how can ColorForth be used to solve all these
difficulties? Is ColorForth  going to be used for an application
that C programmers will enjoy? Will there be a ColorForth
training package for young students? Is ColorForth going to be
such a small system that a programmer can understand every part
of it, or will the code be so muddled and tricky  that only the
most determined expert will be able to learn how it works? When
big system bog down and can't be ported to the new processors,
will ColorForth be used to write new replacements? How is
ColorForth going to improve Forth textbooks?

--
Michael Coughlin    m-coughlin@camcast.net   Cambridge, MA USA

jonah thomas <j2thomas@cavtel.net> writes:
>  100,000 lines of C might truly be no harder to maintain than 500 
>lines that define a special-purpose language and 500 lines of code in 
>that language.

Only if about 99000 of the C lines are empty or equivalent to empty.

In the case of gforth-0.6.2 the special-purpose language is defined in
1586 lines (prims2x.fs), there are 2522 lines of code in that language
(prim), and it generates 22482 lines of C code (which, when
hand-written, would probably be less than half the size) and 1421
lines of Forth code.

This organization vastly improves the maintainability, because a
typical change in prim corresponds to 9 changes in the generated C
code (and hand-writing would not change that).

The maintenance work for prims2x.fs is usually very little (e.g., no
changes between 1999/05/17 and 2000/07/14), so in ordinary usage only
prim needs to be maintained.  So even if the generated code was only
4000 lines, this organization would be a win.

The exceptions are when I add significant new features to prims2x.fs
(like static superinstructions or stack caching), but these features
allow me to do things that I would not even dream of if I used
hand-coding, e.g. investingating the effect of using 1000 static
superinstructions.  And the corresponding changes to the hand-written
code would take much more work.

BTW, just recently there were some postings in comp.compilers about
this topic.

- anton
-- 
M. Anton Ertl  http://www.complang.tuwien.ac.at/anton/home.html
comp.lang.forth FAQs: http://www.complang.tuwien.ac.at/forth/faq/toc.html

----- Original Message -----
From: "Gary Chanson" <gchanson@No.Spam.TheWorld.net>
Newsgroups: comp.lang.forth
To: <comp.lang.forth@ada-france.org>
Sent: Sunday, December 07, 2003 09:26
Subject: Re: Colorforth for Other People (was Re:
ANNcfdos-EuroForth2003edition)


>     It could be argued that since Chuck released Forth into the public
> domain without any restrictions, that he has lost the right to call
> something else "Forth".

Thanks for helping me find the argument.

Regards,
Petrus-Pet4th.

----- Original Message -----
From: "Roger Ivie" <rivie@ridgenet.net>
Newsgroups: comp.lang.forth
To: <comp.lang.forth@ada-france.org>
Sent: Sunday, December 07, 2003 09:32
Subject: Re: Colorforth for Other People (was Re:
ANNcfdos-EuroForth2003edition)


> In article <ddwAb.1088$Ji.593@nwrdny02.gnilink.net>, Gary Chanson wrote:
> >
> >     It could be argued that since Chuck released Forth into the public
> > domain without any restrictions, that he has lost the right to call
> > something else "Forth".
>
> Except that if it's in the public domain he has as much right as
> anyone else to call what he's doing "Forth".

Yes, and majority wins over minority.

Regards,
Petrus-Pet4th.

John Passaniti wrote:
 
[snip]

> Evolution tends to evolve towards increasingly more complex
> organisms in order to survive.  Programming languages are much the
> same way, and I fearlessly predict that ColorForth will only grow in
> complexity, not shrink. And it is going to do this because if ColorForth
> is to tackle the kinds of real-world applications that end users want,
> it is going to need a set of standards.  It's going to need a standard
> for a competitive user interface to modern windowing systems.
> It is going to need some model for multitasking.  It is going to need
> a dictionary model that can handle multiple applications at once
> without collisions.  It's going to need a means to persist data in a
> way that makes sense to end users, and in a way that programmers
> don't have to worry about physical displacements and data types.
> It's free to use whatever character encoding it wants internally,
> but it is going to have to allow end users to manipulate data using a
> real-world (not a programmers-world) character set.
 
      It doesn't have to do that. We can add ColorForth to a
complicated system; we don't have to make ColorForth into a
complicated system. Sometimes you need lots of rules for a
little bit of data. Sometimes you need only a few rules for lots
of data. But you don't always need lots of rules for lots of
data. Living things do not all evolve into dinosaurs, whales and
redwood trees. Perhaps ColorForth will turn into the
programmer's ultimate interactive debugger. Maybe it will be
hiding in a high definition video camera ready to be used to
change the codex, video resolution and number of audio channels
when a new standard is written since the standard will be
written in ColorForth code to upload into old high definition
video cameras. Maybe it will be the interface to the computer in
racing cars to manually adjust them to different climates,
terrain and types of fuel. Anybody can think of uses like this.
There are all sorts of things ColorForth could be used for
besides becoming another Unix clone and even places where big
colored letters are better than overlapping layers with small
text and photographs. And do you think operating systems will
always look and work the way they do now? Suppose ColorForth is
the language that programs a computer that can actually
understand connected human speech. Wouldn't that change everything?

[snip]

--
Michael Coughlin    m-coughlin@comcast.net    Cambridge, MA USA

John Passaniti wrote:
 
[snip]

> Evolution tends to evolve towards increasingly more complex
> organisms in order to survive.  Programming languages are much the
> same way, and I fearlessly predict that ColorForth will only grow in
> complexity, not shrink. And it is going to do this because if ColorForth
> is to tackle the kinds of real-world applications that end users want,
> it is going to need a set of standards.  It's going to need a standard
> for a competitive user interface to modern windowing systems.
> It is going to need some model for multitasking.  It is going to need
> a dictionary model that can handle multiple applications at once
> without collisions.  It's going to need a means to persist data in a
> way that makes sense to end users, and in a way that programmers
> don't have to worry about physical displacements and data types.
> It's free to use whatever character encoding it wants internally,
> but it is going to have to allow end users to manipulate data using a
> real-world (not a programmers-world) character set.
 
      It doesn't have to do that. We can add ColorForth to a
complicated system; we don't have to make ColorForth into a
complicated system. Sometimes you need lots of rules for a
little bit of data. Sometimes you need only a few rules for lots
of data. But you don't always need lots of rules for lots of
data. Living things do not all evolve into dinosaurs, whales and
redwood trees. Perhaps ColorForth will turn into the
programmer's ultimate interactive debugger. Maybe it will be
hiding in a high definition video camera ready to be used to
change the codex, video resolution and number of audio channels
when a new standard is written since the standard will be
written in ColorForth code to upload into old high definition
video cameras. Maybe it will be the interface to the computer in
racing cars to manually adjust them to different climates,
terrain and types of fuel. Anybody can think of uses like this.
There are all sorts of things ColorForth could be used for
besides becoming another Unix clone and even places where big
colored letters are better than overlapping layers with small
text and photographs. And do you think operating systems will
always look and work the way they do now? Suppose ColorForth is
the language that programs a computer that can actually
understand connected human speech. Wouldn't that change everything?

[snip]

--
Michael Coughlin    m-coughlin@comcast.net    Cambridge, MA USA

m-coughlin <m-coughlin@comcast.net> wrote in message news:<3FD2E2FA.5720533D@comcast.net>...
>       ANS-Forth does not look conventional. The compromise to
> the "C" way of doing things the ANS standard tried to make was
> to present Forth as an unvarying language so that company
> managers (who sign the checks and don't read program code) would
> think Forth would be the same all over. Or think that an ANS
> standard language is better than a non-standard one. Well its
> not, and they find out. ANS-Forth is just a little bit more
> uniform than regular wild Forth.

ANS Forth has been sucessful in giving Forth more legitimacy
to managers who rightfully want to have access to a pool of
standard programmers.
 
>        C programmers would like to see Forth go away because
> every time they hear about Forth from a missionary, such as
> myself, they hear a lot of talk and see no useful application
> they can run on their hardware.

I think you mean because when they ask questions and don't like
the answers they call the person a name like missionary. This
insult is simply meant to imply that the person has some religious
belief and is used to mask their own religious belief in C.
They define 'useful' in terms of C, they don't see C so they
see nothing 'useful.'  It is a small closed loop.
  
> > > Yes, you are right. And ColorForth will make Forth to be less popular.
>  
> > Execellence is not popular.  I prefer quality to popularity.
> 
>      So do I. I especially admire excellence in documentation
> and technical writing.

That is nice too.  There is so much documentation on some things that
it is hard to find the useful documentation, most of it is next to 
useless.  Of course I don't start with the '... for dummies' type
manuals that are so popular.
    
>      Once a certain size is reached, software systems grow until
> they collapse. They are like trees. The old tree in front of my
> house got so big that its branches fell off from their own
> weight. In the case of software, the collapse is because nobody
> understands what has been written well enough for the code to be
> maintained. Going back to a very small system could be a cure
> for that. But then again, if you keep cutting back too much you
> never have anything big enough to do something useful.

Indeed.  The minimum seems to be an OS with the features that you
need to start, an editor to compose more, and a compiler to extend
the system.  That is the colorforth philosophy.
 
>      The debate with the weird code is an attempt to learn how
> Forth works. It is a reflection of the poor communication among
> Forth programmers. The members of the standard committee had a
> good time meeting and discussing how Forth does work and how it
> should work. 

I was talking about the decade of debate in c.l.f about whether
this code or that code was compliant.  And the above is true if
you insert the word ANS before each occurance of the word Forth.
The discussions also continued after the standard was ratified
and some people certainly still have questions that get answered
even now, almost a decade later.

> They had a bad time when they couldn't agree, spent
> so long traveling, and missed out on paying jobs.

Don't forget that it was paying work for some people.

> But all that
> work and study did not result in a new crop of Forth textbooks
> to replace the old ones.

That is not true Mike.  How many times have people suggested
that you check out the new excellent Forth Inc. textbooks about
ANS Forth.  Those discussions have been beaten to death.  You
might turn off the killfile or whatever mechanism it is that
has prevented you from following up on the information about
new ANS Forth textbooks.  As someone who likes documentation
you certainly go out of your way to try to prevent other
people from learning about it. ;-)

> Those who made innovations in Forth
> wrote less about their progress than those who wanted to
> document a standard Forth.

Systems with innovations in compiler design or user interface
design tend to have their own documentation.  For some reason
it is invisible only to you.
  
>      I don't know why we have so much trouble with floating
> point arithmetic and files.

We always will.  They are people's hot buttons.  There are those
who need them and those who don't.  There are those who prefer
files and those who prefer blocks.  Those who prefer scaled
integer arithmetic and those who prefer floating point, those
work with machines where floating point is a heavy and often
too expensive layer of software and those who have hardware that
is mostly optimized for floating point.  So one style does not
fit all.  And some people hold on to their personal environment
and argue in isolation of others. 

I use floating point on my Pentium, they argue, so everyone should
use it even on an 8051 with 256 bytes of ram.  I use files on my ...
so everyone should just load Linux onto their 8051 with 256 bytes
of RAM etc.  Silly as those arguments sound they will continue to
be made if the past is ANY indication of the future.

> Why don't people consider them to be
> applications to be written for a Forth system?

Probably the biggest reason is that they are already part of
most ANS Forth systems and the work doesn't have to be duplicated
each time.  You know this stuff.

> Does anybody get
> upset if an assembler doesn't somehow have a file system built
> in? Or if an assembler for a microprocessor without floating
> point hardware doesn't have floating point instructions? Why
> don't people who need file systems and floating point just
> ignore Forth systems that don't come with those and let
> programmers who write for little embedded processors do their
> thing?

Some do, some don't.  

> I guess its because programmers first learn a language
> like C then can't think without a Unix (or Windows) operating
> system. 

Some do, some don't.

> Maybe if they first learned on a small simple Forth
> system we wouldn't have this problem.

They will have OTHER problems of course. ;-)
 
>      So now how can ColorForth be used to solve all these
> difficulties? 

I don't think it can solve ALL those problems.  It might also
be good to remember that Forth was designed to AVOID the kinds
of problems that other people can't solve either and to avoid
wasting the time on those same problems over and over.  It
introduces a different set of problems.

(Not the least of which is being called names, booed or
chased out of the room or building by C programmers, etc. ;-)

> Is ColorForth  going to be used for an application
> that C programmers will enjoy? 

I don't call myself a C programmer, though I must admit that
I have done it.  But one member of our team has almost always
been a C programmer prefessionaly and he loves OKAD II and
colorforth because he is so damned productive with it.  You
couldn't pry it out of his hands if you tried.

> Will there be a ColorForth
> training package for young students? 

Who knows, probably.

> Is ColorForth going to be
> such a small system that a programmer can understand every part
> of it, or will the code be so muddled and tricky  that only the
> most determined expert will be able to learn how it works? 

As you often say, that depends a lot on documentation.

> When
> big system bog down and can't be ported to the new processors,
> will ColorForth be used to write new replacements? How is
> ColorForth going to improve Forth textbooks?

Colorforth will have no effect on ANS Forth textbooks that
are present or in the works.  Maybe I am missing your basic
idea, I don't see how they are related.

If you mean will there be colorforth textbooks that are 
better than older textbooks?  Who knows, as I have told
you before these things depend mostly on interest.  If
you are interested you can make it happen.  But bitching
isn't going to make it happen.

Best Wishes,
Jeff Fox

m-coughlin <m-coughlin@comcast.net> wrote in message news:<3FD2C51B.97C394FB@comcast.net>...
> just a way to do one job at a time. But maybe somebody will come
> along and decide the one job that he wants to use Forth for is
> to be a cure-all for every programming problem.

If they do they will learn better.

Best Wishes,
Jeff Fox

"Gary Chanson" <gchanson@No.Spam.TheWorld.net> wrote in message news:<ddwAb.1088$Ji.593@nwrdny02.gnilink.net>...
> > I was just refering to people who say that what they do is Forth and
> > that what the inventor of Forth does is not Forth.  In that sense they
> > want to steal the name Forth from the inventor.
> 
>     It could be argued that since Chuck released Forth into the public
> domain without any restrictions, that he has lost the right to call
> something else "Forth".

Because it is in the public domain I can name my dog, or cat, or
child, or whatever 'Forth.'  That's not the issue.

The issue is when someone says, 'I am now the authority as to what
the word Forth means, I know more than the inventor, what he is doing
isn't Forth.'

He (the founder of Forth) has graciously given the name for free use.
He has manners and has not argued that some very bizare systems that
were called Forth were not actually Forth.  He has not set himself
up as the authority to approve or disaprove of the Forth label.
Sadly some other people do not have such good manners.
 
>     I'm not claiming to make that argument and I'm not sure that ColorForth
> is not a reasonable evolution of Forth (but I have some doubts).

Likewise, and in response to statements like that and given the extra
qualifications like the word 'reasonable', I would also say that I'm
not sure that ANS Forth is not a reasonable evolution of Forth, but
I have some doubts.

Best Wishes,
Jeff Fox

"John Passaniti" <nntp@JapanIsShinto.com> wrote in message news:<D9zAb.1926$UK1.1719@news01.roc.ny>...
> "Mark Slicker" <maslicke@oakland.edu> wrote in message
> news:4c45abad.0312011418.5f569441@posting.google.com...
> > I more associate you with the status quo than I do with
> > ANS Forth. Mostly it is the repetition of the idea that all
> > things are equal just different.
> 
> I'm not sure where you get that from what I have wrote.  If I really
> believed that, why would I use Forth or any of the other languages I use in
> my work?  It would be far easier to follow the herd and just use C for
> everything.  Yet, in a typical week, I'm probably coding in at least four
> different languages out of a pallet of probably a couple dozen.  Assembler,
> C, Forth, Scheme, Lua, Perl, Python, C#, Java, and so on, not to mention
> dozens of "little languages" that I've written to address specific
> problems-- if nothing else, that *clearly* shows that I don't think all
> things (specifically languages) are equal.
> 
> The reason I use a variety of languages in my work is because they *aren't*
> equal.  Each has a different set of positive and negative qualities, and I
> pick and choose them depending on what I need to do.  I am primarily an
> embedded systems software engineer, but I do lots of other work too outside
> my job title.  And if anything, the wide range of software projects I tackle
> has shown me that no one language best suits everything.  More often than
> not, those who disagree with this view are programmers who work only in a
> particular field.  More often than not, those who disagree with this view
> are programmers who don't understand that the world is not limited to their
> experience.  But that's true of lots of things, not just programming.

I had it wrong, but its hard to keep it strait because you have at
different points said contradictory things. The quote I had remembered
was:

"The obvious answer is that no language is best, and that really,
ultimately, language doesn't matter."

> 
> > Would it be significant otherwise? It is more concise than any
> > code I've seen. A new version (not released) shows additional
> > improvements in quality, speed, and conciseness. Some of these
> > qualities are derived directly from its expression in colorForth. An
> > assembler version would most likely be faster, but assembler is
> > both clumsy and non-portable. A C version, also clumsy, would be
> > ignored I think because the IJG code exists and C programmers
> > do not mind size nor the ugliness of this code. Once their code is
> > functional, C programmers tend to move in the direction
> > completeness and generality. I think my JPEG code is most valuable
> > as part of a simple comprehensible system.
> 
> I have to chuckle whenever I see people like you make blanket pronouncements
> about a class of people-- in this case C programmers.  Saying "C programmers
> do not mind size or the ugliness of this code" suggests there is a single
> (or even a dominate) mindset in C programmers, and further, that you are
> qualified to discuss this mindset.  In my experience, I see (and work with!)
> all kinds of C programmers, with all kinds of views and opinions.  I can't
> neatly sum them up in a statement like you can, but then again, I'm more
> interested in reality, and not repeating a fantasy in hopes others will
> believe it.

Consider this, I've never heard any complaint about the IJG code. And
on the whole it is one of the better pieces of C code I've seen. Other
C code that I see tends to get worse, not better than the IJG code.
I've not seen a C code alternative to the IJG C code. That is what
prompts me to say C programmers don't mind this code. I don't see any
differences being expressed, in code or otherwise.

> > So your concern is that an application that deals directly with
> > the user will show some limitation in the system. This is fair
> > game.
> 
> Let me clarify my view on this.  I don't think one can *really* judge a
> language until one has done something significant with it.  The word
> "significant" is deliberately ambiguous, in part because I don't see a
> single objective standard for what is significant.
> 

[ snipped tawk exposition ]

> 
> Your JPEG decoder is probably the largest set of code (outside of OKAD) that
> is mentioned.  But I don't see a JPEG decoder as stressing the ColorForth
> environment.  At least, I don't remember seeing any messages from you
> describing any case where you "bumped your head" with ColorForth, or where
> you found the environment lacking.  That either means that ColorForth is
> perfect or that you simply haven't hit the limits yet.  When you hit the
> limits, I want to hear about it, because it is then we'll actually start to
> *learn* something.

I tend to answer my own questions a lot. I purposely chose JPEG off of
Chuck's list, not only because it seemed useful but it looked liked
the one of the more complex tasks on list. I was interested in how
colorForth would support this kind of complexity. Up to this point I
believe I had the far more modest Mandelbrot set under my belt. It was
quite challenging, but I think this has more to do with JPEG, and less
to do with colorForth.

> 
> This is my concern for ColorForth.  ColorForth is presumably the ideal
> language for OKAD, since Chuck designed it for that purpose.  But I don't
> have any real sense of if ColorForth can scale to the kinds of real-world
> applications that people use every day.
> 
> For discussions like this, I like to use my Mom.  I think she's a typical
> user of computers.  At work, she uses a ERP system for the company she works
> for.  At home, she likes to surf the web, exchange email with the family and
> friends, tracks various personal financial data in spreadsheets, type
> numerous lists and letters in a word processor, and play games.  She's just
> getting the hang of listening to streaming audio.  And now that she has a
> grandson, she's enjoying viewing digital snapshots of him.
> 
> I think she's a typical computer user using a typical mix of applications.
> She doesn't understand programming at all, and has absolutely no interest in
> learning.  She doesn't care in the least what programming language(s) were
> used to create the applications she uses.  What she cares about is having a
> computer help her do her work, to be a fun diversion, and in general to make
> life easier.  Oh, and she wants it to be easy and intuitive (or at least if
> it can't be intuitive, she wants it to be easy to learn).
> 
> When ColorForth gets to the point of delivering applications to end users
> that let's them (and not programmers) do what they want, *then* I think
> we'll get some useful feedback on the scalability and overall value of
> ColorForth. 

Your Mom, from the description, is part of what is called the consumer
market. There are obvious barriers to this market, beside the purely
technical ones.

I don't think we have to wait till colorForth becomes a consumer OS
before we can understand the limits more precisely. Public
applications (OKAD II obviously excluded) that receive the beating of
every day use I think is sufficient.

> Until then, what we have is a bunch of programmers who are
> essentially making predictions about ColorForth's scalability and overall
> value based on some toy applications they've written.

Who exactly is doing this?


> My Mom (like most rational humans) isn't going to remember that she stored
> pictures of her grandson at blocks 2843, 4390, and 5304, her shopping list
> at 3495, and that to start her email client, she need to load block 8825.
> That's insane.  End users need to store data in terms of something symbolic.
> Maybe each application allocates a set of blocks and provides the user with
> a simple directory within that space.  Maybe it's a traditional file system
> with a more free-form allocation of blocks.  Maybe it's some kind of
> high-level object database.  Maybe it's something entirely new and
> different.  But whatever it is, it won't be raw blocks.  That's just stupid
> for end users.
> 
> Raw blocks are fine for programmers who in general are accepting of
> remembering useless trivia like "Chuck uses blocks 0 through 63" and "I last
> stored my word list at block 800."  But before any significant applications
> are written for end users, they are going to need something higher-level and
> symbolic.  (I'm waiting for the first ColorForth programmer who suggests
> that the ColorForth dictionary is an appropriate place for end users to
> store these symbolic names for blocks.)

Yes. I like the blocks as a programmer, I think it is an intelligent
way to structure a system. As a user I would prefer the tasks of
allocating and organizing block storage to be automated.

> 
> Writing that storage layer, and not a JPEG decoder, would be a significant
> set of code and would be part of the answer in finding the limits of
> ColorForth.
> 
> > The issue of data is a fundamental one in system design. As much
> > as I admire colorForth, I find attractive the pure elegance of
> > functional systems. In a functional system all data is expressed in
> > the type system of the language and remains persistent until no
> > reference of the data exists. The kind of code as data that Chuck
> > uses in OKAD seems like a one way street, modification is through
> > the editor, mechanical processing only seems to apply to
> > interpretation of the data. In the general case it seems we are left to
> > define binary formats and the methods for modification.
> 
> More than anything else, this is probably my biggest problem with
> ColorForth.  In most modern languages, I can create structured data of
> arbitrary complexity, and by calling some simple routines I can serialize
> that data to an abstract stream.  This works because I can do reflection on
> the structure of the data in a generic way.  This lets me know that future
> invocations of my application can reliably recreate the data I had at some
> point in the future.  And I know that when the data 
s deleted, underlying
> mechanisms will handle the storage management issues.  It's the same reason
> why I could use a manual screwdriver, but I prefer using an electric one.
> 
> ColorForth doesn't have any kind of support for persisting data, other than
> to dump what's in memory to a floppy.  If I want to share data between
> applications, I better know the *exact* binary form that data takes.
> ColorForth doesn't even have the ability to do what many scripting languages
> can do to serialize data-- write out a program that when later executed
> recreates a data structure.  Since program source in ColorForth is in an
> encoded form, one would need to write out that same encoded form, which
> requires intimate knowledge of that encoding.  Ick.

colorForth bypasses the serialization by just saying there is no
difference in the data used by the application and data stored to
disk. The technical need for serialization is that the data structures
as they exist in memory can not be properly exported directly to the
disk and be read back.

At this point I would not say colorForth needs a type system and the
support for serializing data expressed in this type system. These are
very general approaches, very much the opposite of the colorForth
approach.

colorForth pushes more decisions onto the programmer, prefering not to
default to a generalized decision. It is a different approach and its
strengths and weakness need to be explored more fully.

> 
> Writing that persistence layer, and not a JPEG decoder, would be a
> significant set of code and would be part of the answer in finding the
> limits of ColorForth.
> 
> > This view is marginalizing for a general purpose programming language.
> > A language that can't scale beyond a single person and a single
> > context is worthless. No one wants to maintain a thousand dialects of
> > language and applications written in these dialects, nor does anyone
> > want to reinvent the same code over and over again for each dialect.
> 
> I can't remember where I read it, but somewhere on Jeff Fox's site you'll
> find a statement from Charles Moore that says, in effect, that programmers
> should create their own Forths to meet their own needs.  Charles obviously
> believes this himself, as he has veered far away from ANS Forth, and has
> implemented over the years a number of Forths that are only compatible with
> themselves.  ColorForth is just another in a long line of Forths that stands
> alone.  While it may share ideas from his past efforts, ColorForth is in no
> sense compatible with the past.
> 
> The message of ColorForth-- at least to me-- is that a programmer shouldn't
> be afraid to design their own language around their own needs.  I don't see
> that as marginalizing at all.  If anything, that is a uniquely empowering
> statement-- quite different from the mainstream.  It's deeply ironic that
> you find my statement-- which I see as nothing more than what Charles Moore
> himself has said-- as marginalizing.  You're championing a language that by
> it's very design goes against the mainstream-- and that goes against the
> idea that there should be a singular standard because programmers don't want
> to reinvent wheels.  Charles Moore reinvents wheels all the time!
> ColorForth is a reinvented wheel.  Specifically, it's a better wheel (to
> him, at least) than his past wheels!

I'm not talking about reinventing the wheel. That is what my jpeg code
does in fact. What I am talking about is non-productive variations.
When it comes to the point that each programmer has his own language
and no code can be shared, we end up defeating ourselves. A language
that purports to be general purpose must scale to a greater context.
If that contradicts anything Chuck has said, then so be it.

> 
> > Robust and well-written code is an invaluable asset. This does
> > not imply we have to accept colorForth in its present form, this
> > does not imply we need a colorForth standard. Many languages
> > exist today with no standard, only a community which accepts
> > basic premises, the interactions of which produce an evolution
> > of the language. In this case the implementation is the standard.
> 
> Evolution tends to evolve towards increasingly more complex organisms in
> order to survive.  Programming languages are much the same way, and I
> fearlessly predict that ColorForth will only grow in complexity, not shrink.

Increasing functionality aside, what I have observed in colorForth is
that my programs tend to shrink. This property is especially prominent
in Forth, given the simple method of abstraction (definitions), and
that the smallest discrete unit of the language is smallest possible,
a single token.

> And it is going to do this because if ColorForth is to tackle the kinds of
> real-world applications that end users want, it is going to need a set of
> standards.  It's going to need a standard for a competitive user interface
> to modern windowing systems.  It is going to need some model for
> multitasking.  It is going to need a dictionary model that can handle
> multiple applications at once without collisions.  It's going to need a
> means to persist data in a way that makes sense to end users, and in a way
> that programmers don't have to worry about physical displacements and data
> types.  It's free to use whatever character encoding it wants internally,
> but it is going to have to allow end users to manipulate data using a
> real-world (not a programmers-world) character set.

I agree the complexity will go up as tasks become more elaborate. I
don't know what you mean by standards. If you mean protocols, yes that
goes with applications that work together and share resources.

> 
> In short, it's going to need a lot of things that other languages have found
> necessary, because programmers (eventually) find these things necessary as
> they tackle more significant applications.  And along the way, there is
> going to be discussion and disagreement.  You're going to have the camp that
> says these things are unnecessary, and the camp that says they are vital.

With due respect to other languages, I don't see that they are getting
at what is truely necessary. In the spirit of Chuck Moore, I see this
as the primary work of colorForth, deriving what is necessary directly
from the requirements of the applications built, not to preemptively
add complexity in the anticipation it may be needed later.

> 
> And that's the point that ColorForth is going to get interesting.  At the
> point in time when programmers with vastly different experience and needs
> start to question the design decisions of Charles Moore (instead of simply
> accept those decisions as if from on high), ColorForth will start to matter.
> But, that is also the same time that ColorForth will probably split into a
> variety of implementations.

Splits are healthy. If colorForth as released is perfect for your
intended application, there is no reason to accept additional
complexity. If you happen need more extensive multitasking, you add
that, ect. I hope the splits are modular in nature, so that we can
recombine modules to create a colorForth which suits our context.

> > It has not been as much fun as I would have hoped. I really thought
> > people would take the ball and run with it. I had no idea of the kind
> > battles to be fought and the strange group politics that have come
> > with the Forth association. If I'd known this I might have created an
> > environment with no association to Forth or Chuck Moore. I still may
> > do this.
> 
> I don't understand, but then I don't read the mailing list.  What kind of
> "strange group politics" are you talking about?  You surely don't mean any
> conversation in comp.lang.forth, since what happens here has little to do
> with the private world of the ColorForth mailing list.  And indeed, I don't
> know why ColorForthers would care about any conversation here in
> comp.lang.forth.
> 
> So for those on the outside, clue us in.  What's the "strange group
> politics" you're talking about in the ColorForth community?

There is not a well defined area in which to discuss Forth and
ColorForth as evinced by this thread itself. I skim the headers of
comp.lang.forth from time to time to see if there is anything
relevant. The ColorForth list is simply a more warm and welcome place
to discuss Forth. Creativity is encouraged, and even the man himself,
Chuck Moore, will add his input to the discussion.

Some of things I didn't expect:

* The religious connotations and accusations (comp.lang.forth). I for
one never expected myself to be accused a fundamentalist.

* The combination of fear, hatred, and dishonesty that have confronted
colorForth (comp.lang.forth). This is seen most prominently in the
recent discussions.

* The idea that one should write all of ones code himself (colorForth
mailing list). Coming from the open source community and knowing the
benefits of collaboration and peer reviewed code this is the opposite
of what I expected for what is essentially an open source community.

* The idea that only commercial vendors could offer quality Forth
(comp.lang.forth). This contradicts the experience with open source
languages which offer equal if not better quality to commercial
offerings and are not limited by commercial licensing.

* Bitterness and indifference toward Chuck Moore, the creator of Forth
(comp.lang.forth).

* The idea the colorForth can in no way extend beyond Chuck Moore's
needs, and meet the needs of a larger community (colorForth mailing
list, comp.lang.forth).

Some of these things make me want to create a distinct project. In the
same spirit as the GNU project, but without the intellectual laziness
of the GNU project. I don't know if these things merit a break from
the Forth community in general. Chuck has too many good ideas, too
much wisdom, which I don't want to miss out on. The colorForth
community is a supportive and creative bunch of people which I benefit
from. And sometimes (but rarely) I even find benefit from the larger
Forth community.

Mark

m-coughlin <m-coughlin@comcast.net> wrote in message news:<3FD2E2FA.5720533D@comcast.net>...
>      I don't know why we have so much trouble with floating
> point arithmetic and files. Why don't people consider them to be
> applications to be written for a Forth system?

Most of us who raise such issues don't use Forth as our primary 
tool and our expectations have been set by previous experience. 
I personally find files with names to be a useful abstraction 
over writing data to block numbers. I'm not alone. YMMV.

> Does anybody get upset if an assembler doesn't somehow have a 
> file system built in?

Ask the question another way: how many people will use an 
assembler that can't talk to the customer's existing file 
system? Sooner or later you're going to want that assembled 
code out of the assembler environment to be used elsewhere.
Well, non-Forthians will, at least.

> Or if an assembler for a microprocessor without floating
> point hardware doesn't have floating point instructions?

Not a problem. But when I see colorForth aimed specifically 
at the Pentium and ignoring the floating-point capabilities 
of the chip, my eyebrow arches in skepticism. And when I see 
machine code dropped into definitions instead of the use of 
the assembler words, I see it as a danger sign.

> Why don't people who need file systems and floating point just
> ignore Forth systems that don't come with those and let
> programmers who write for little embedded processors do their
> thing? I guess its because programmers first learn a language
> like C then can't think without a Unix (or Windows) operating
> system.

This would be a better theory if it corresponded even remotely 
to the facts. In the early 1990s I worked at Embedded Systems 
Programming. During that time we saw Forth usage in our reader 
surveys steadily decline, from a small fraction to even smaller. 
Assembler was much more popular, but it also declined. C usage, 
on the other hand, kept expanding as compiler technology kept 
improving.

When the Harris folks marketed the RTX chips they immediately 
heard their customers asking for the RTX C compiler. That wasn't 
because they planned to run Windows or Linux on the RTX, but 
because they found C a useful tool for embedded applications.

I find it curious that Forth developers are quite able to 
accept customer requirements in developing embedded apps, but 
when a potential customer has requirements for Forth itself, 
the fur starts to fly.

>      So now how can ColorForth be used to solve all these
> difficulties? Is ColorForth  going to be used for an application
> that C programmers will enjoy? Will there be a ColorForth
> training package for young students? Is ColorForth going to be
> such a small system that a programmer can understand every part
> of it, or will the code be so muddled and tricky  that only the
> most determined expert will be able to learn how it works? When
> big system bog down and can't be ported to the new processors,
> will ColorForth be used to write new replacements? How is
> ColorForth going to improve Forth textbooks?

Those are all excellent questions. But I think we both know the 
answers with boil down to: Stop whining and fix it yourself.

That, and Jeff will ask you to stop spreading misinformation.

Cheers,
Tyler

Jeff Fox wrote:
> 
> m-coughlin <m-coughlin@comcast.net> wrote in message news:<3FD2E2FA.5720533D@comcast.net>...

[snip]
 
> >        C programmers would like to see Forth go away because
> > every time they hear about Forth from a missionary, such as
> > myself, they hear a lot of talk and see no useful application
> > they can run on their hardware.
> 
> I think you mean because when they ask questions and don't like
> the answers they call the person a name like missionary. This
> insult is simply meant to imply that the person has some religious
> belief and is used to mask their own religious belief in C.
> They define 'useful' in terms of C, they don't see C so they
> see nothing 'useful.'  It is a small closed loop.

      C programmers love C since they can do all sorts of
interesting things with it. I don't remember programmers saying
how much they liked a programming language before C came around.
The programing languages before C were just a constant struggle.
And I don't know why things like Pascal and Fortran (without
punch cards) didn't become more popular than C. But the real
puzzle is why didn't Forth take over instead of C. Nowadays if a
new programmer finds out about Forth he does not find any good
examples to follow. He finds plenty of C programs to use and
learn from. Forth has retreated from several areas where it was
once common, like astronomy and robots. How did a silly language
like C replace it? I'm the one who uses the word missionary. I
have to promise salvation in the future but not right now.

[snip]
 
> .  .  .  There is so much documentation on some things that
> it is hard to find the useful documentation, most of it is next to
> useless.  Of course I don't start with the '... for dummies' type
> manuals that are so popular.

   Well you should. Like many things connected with computers,
the dummies books are not what they are supposed to be. Some of
them are carefully organized and informative. At least some of
them present information that an expert in one computer area can
use to learn about a new different area. Their jokes get stale
after a while, so you woun't want to keep them as reference
manuals. You can read them in the public library instead.

[snip]

> >      The debate with the weird code is an attempt to learn how
> > Forth works. It is a reflection of the poor communication among
> > Forth programmers. The members of the standard committee had a
> > good time meeting and discussing how Forth does work and how it
> > should work.
> 
> I was talking about the decade of debate in c.l.f about whether
> this code or that code was compliant.  And the above is true if
> you insert the word ANS before each occurance of the word Forth.
> The discussions also continued after the standard was ratified
> and some people certainly still have questions that get answered
> even now, almost a decade later.

      Its just as true for any kind of Forth, but you have made
up your mind about what you want in your version of Forth, so
you don't have to worry about it anymore. Or sympathize with
those who have not made up their minds.
 
[snip]

> > But all that
> > work and study did not result in a new crop of Forth textbooks
> > to replace the old ones.
> 
> That is not true Mike.  How many times have people suggested
> that you check out the new excellent Forth Inc. textbooks about
> ANS Forth.  Those discussions have been beaten to death.  You
> might turn off the killfile or whatever mechanism it is that
> has prevented you from following up on the information about
> new ANS Forth textbooks.  As someone who likes documentation
> you certainly go out of your way to try to prevent other
> people from learning about it. ;-)

     Actually people don't suggest reading the new textbooks
very many times. If you think these new books are so good, tell
the world what they are. I don't know what I can do to prevent
other people from learning about them, except by not mentioning
them. But you didn't bother to mention their titles either. If I
don't have anything good to say about these books, then in
fairness I don't think I should say anything about them at all.
But I'm going to reluctantly ignore that consideration, just
this once, since you brought up the subject so forcefully. When
as I heard about  Forth Inc.'s new textbooks, I went off to read
them at the largest public repository of Forth literature in my
area, the library of the Massachusetts Institute of Technology.
They were not there. I've checked every few months for years and
they are still not there. I mentioned this a long time ago on
comp.lang.forth and it didn't result in much or any discussion.
After thinking about it a while, I realized this was not a good
way to encourage people to read these books or even study Forth,
so I decided to try to avoid the topic. Instead I mention the
subject of textbooks in other contexts to see what Forth
programmers currently recommend. It seems to me they still are
using the old books, and not the new ones that I will not name
in the hope that this will arouse curiosity and interest in them.

       There is a connection with Forth standards. I wrote a lot
about the ANS standard years ago before it was approved. I don't
want to write a lot about it now. Instead I want to find out
about the other kinds of Forth. The current textbooks emphasize
ANS Forth, not what I'm eager to learn.

         Trying to find out about ColorForth is a big struggle.
I have to wade thru a lot of messages and web pages to find the
few little facts that tell me what I need to understand. Its a
long process.

> > Those who made innovations in Forth
> > wrote less about their progress than those who wanted to
> > document a standard Forth.
 
> Systems with innovations in compiler design or user interface
> design tend to have their own documentation.  For some reason
> it is invisible only to you.
 
     If you want to make your point, mention some of these
system so people who don't have my supposed problem will know
what they are like and where to find them.

--
Michael Coughlin    m-coughlin@comcast.net   Cambridge, MA USA

"John Passaniti" <nntp@JapanIsShinto.com> wrote in message news:<D9zAb.1926$UK1.1719@news01.roc.ny>...
> This is my concern for ColorForth.  ColorForth is presumably the ideal
> language for OKAD, since Chuck designed it for that purpose.  But I don't
> have any real sense of if ColorForth can scale to the kinds of real-world
> applications that people use every day.
> 
> For discussions like this, I like to use my Mom.  I think she's a typical
> user of computers. At work, she uses a ERP system for the company she works
> for. ....

Well, she's going to *love* colorForth. Imagine her delight when you tell 
she can finally write her own ERP system! (Sorry, I couldn't resist.)

> ColorForth is going to need to be able to handle multiple applications at
> the same time-- and that gets into a scalability issue.  How should multiple
> concurrent applications work in ColorForth?  Should the multitasking be
> cooperative or preemptive?  How should ColorForth manage dictionaries for
> each application?  Multiple dictionaries?  A single dictionary with
> namespaces?  Applications can start and end at any time.  How is the memory
> occupied by those dictionaries (along with any other storage allocated for
> the application) going to be managed?

Excellent points. I used to think managing resources like that was the 
business of an OS, and missing from colorForth. But Jeff pointed out 
that I didn't know what I was talking about.

> More than anything else, this is probably my biggest problem with
> ColorForth.  In most modern languages, I can create structured data of
> arbitrary complexity, and by calling some simple routines I can serialize
> that data to an abstract stream.  This works because I can do reflection on
> the structure of the data in a generic way.  This lets me know that future
> invocations of my application can reliably recreate the data I had at some
> point in the future.  And I know that when the data is deleted, underlying
> mechanisms will handle the storage management issues.  It's the same reason
> why I could use a manual screwdriver, but I prefer using an electric one.

Actually, I think this is more an issue of Forth thinking in general. 
Back in the 1980s, it made a certain amount of sense to use a cell for 
any data and use a contiguous group of them for data structures.  In
general languages have evolved so that now you can pick languages that 
emphasize lists, arrays, tables, dictionaries, objects, etc. Forth 
thinking still seems to look at the world in terms of cells, and 
data abstraction -- like hardware abstraction -- is a sign of a 
weak mind.


> Evolution tends to evolve towards increasingly more complex organisms in
> order to survive.  Programming languages are much the same way, and I
> fearlessly predict that ColorForth will only grow in complexity, not shrink.
> And it is going to do this because if ColorForth is to tackle the kinds of
> real-world applications that end users want, it is going to need a set of
> standards. ....

I agree with your logic, but not your presupposition that the power 
structure of colorForth is concerned with end user requirements. Chuck 
has his goals, which revolve around OKAD x, not your mom. Everyone 
else defers to him, at least politically, so there will never be 
serious movement toward agreement on interfaces.

My fearless prediction is that colorForth will continue on its 
current course of isolation. All the really hard work will always 
seem like someone else's job, so you'll have a succession of 
interesting single-user, single-developer projects. But the 
barrier to using ColorForth in real world applications (with 
the theoretical exception of OKAD x) will remain so high that 
people will continue to choose other Forths and other languages 
when they're trying to get real work done.

The logical way to avoid some of that fate would be to build on 
existing host OS resources and libraries, but such an approach 
would immediately collide with ego and aesthetics.

Tyler

Hi John,

"John Passaniti" <nntp@JapanIsShinto.com> wrote in message
news:em7Ab.1487$x02.517@news01.roc.ny...

[snip]

> And so the context I would like you to put your statements about the worth
> of ColorForth in is what you have actually done in ColorForth.  I'm not
> interested in what you think you *might* do with ColorForth, and I'm not
> interested in how you think you *might* benefit from it.
[snip]
> But since you stated it was "worth the effort," I assume that
> means you've done something that at least you consider significant, and
that
> you've learned something from that.

I only get to spend the occasional evening programming in colorForth, and
most of that time has been spent on
1. understanding colorForth
2. writing CFDOS to interface colorForth to the wider world of files
3. collating and documenting other people's source
4. writing two papers on colorForth ( please follow links at
www.inventio.co.uk )
So even if the above hasn't resulted in a "significant application", it has
been a significant amount of work, and I believe that I have learned
something from it - in fact item 4 presupposes that I have learned something
;)

A lot of my paid work involves communications protocols ( PPP, HDLC, IP
etc ). One thing that I noticed about protocols is that most of the
complexity comes from confusion over "states" that the programs at each end
of a communication link can be in. My conclusion is that if a system has a
state, it should have a state variable that describes it, but the use of any
other "artificial" state variables tends to cause problems. In general, it
is best to minimise the number of states that a system can be in, and that
any state that the system can be in should map directly to a state variable.
[ This incidentally, is why I haven't programmed TCP yet - too many states
for me to be comfortable with ]

In conventional Forth there is an INTERPRET state and a COMPILE state,
sometimes defined by a STATE variable, sometimes by one of two program
loops. There is also an editing "state" , defined by running the editor.
This situation is OK for one programmer sitting at one computer, as the
human memory can hold context quite well - the editor usually looks
different, and INTERPRET and COMPILE states are clearly marked in the source
by ":" ";" "[" "]" and friends.

Following my general principle that the number of states should be
minimised, I was fascinated by the fact that colorForth has fewer states
than conventional Forth. Each token has a "colour" that defines its action,
independently of the state of the system. There is still an editor, but
COMPILE and INTERPRET states are determined by each and every token. There
is also increased modularity - each token also includes a global reference -
its name.

So, one of the things I have learned from colorForth is that it is possible
to write a programming language that uses a smaller number of system-wide
states than conventional Forth.

ColorForth tokens also allow a simpler data structure to be used for
dictionary names ( an array ), and a simpler mapping of source to blocks (
one token per 32 bit cell ). This allows a trivial implentation of the
magenta variable, which then allows the state of the program to be stored in
its source.
This in turn allows compiled code to be discarded without losing state
information, and this leads to "just in time compilation".

"Just in time compilation" means that you can switch between applications by
discarding compiled code, and compiling and running another application.
This removes the need for multi-threading and an OS to select threads for
applications. It also means that to provide networking all you need to do is
to transfer source blocks. Which computer compiles and runs the code is
irrelevant.

ColorForth also defines a standard graphics format - a memory mapped
1024x768 x 16 bit colour display [ thank you Daniel for pointing this out
;) ].

All of the above concepts are demonstrated in the current distribution of
colorForth. You can see a magenta variable being incremented ( in the source
code ) by an interrupt, you can compile "dump" just in time, you can discard
the Mandelbrot program, and send it to a friend who will see the exact same
pattern as you had on your screen. OK , this doesn't sound any different to
what you can achieve with Perl or VB - but if you look into the details it
is very different.

So, how I have already benefitted from colorForth is that I have clearer
insights into how computer programs work. It is so simple that I can
actually understand it!

The reason that I say that it is "worth the effort" is that I have found
that it has been worth the effort for me.

There is a paradox here. ColorForth is very simple, and also very difficult.
Its simplicity lies in its elegance, and its difficulty lies in our
understanding.
A stunningly elegant programming language which requires many weeks of
discussion to produce a "Hello World" program, and an ugly one at that.
A few people, like myself, who have looked at colorForth and think that its
the best thing since conventional Forth, and a few who think that its an
irrelevant embarassment. Fascinating! Vive la difference!

Yes, Chuck has done it again. What you see here in comp.lang.forth is an
echo of the reaction to conventional Forth in the 1980's. What about an OS?
Why isn't it Smalltalk? I can't possibly program without files... etc

To provoke this kind of reaction, its just got to be on the right track ;)

Regards

Howerd  8^)

Jeff Fox wrote:
 
> m-coughlin <m-coughlin@comcast.net> wrote in message news:<3FD2E2FA.5720533D@comcast.net>...

[snip]
 
> > Why don't people consider them [floating point and files] to be
> > applications to be written for a Forth system?
 
> Probably the biggest reason is that they are already part of
> most ANS Forth systems and the work doesn't have to be duplicated
> each time.  You know this stuff.

       Well I know this stuff, but we are conducting a public
discussion and there are always new people lurking around who
don't know it. We had the same discussions before there was an
ANS standard or even a comp.lang.forth. Forth without floating
point and FAT hierarchical file systems always get somebody
agitated. Maybe Forth should come with warning labels that say
"Some features are left as programming exercises for the student".

[snip]
 
> . . .  It might also
> be good to remember that Forth was designed to AVOID the kinds
> of problems that other people can't solve either and to avoid
> wasting the time on those same problems over and over.  It
> introduces a different set of problems.
 
> (Not the least of which is being called names, booed or
> chased out of the room or building by C programmers, etc. ;-)

       I knew a C programmer who laughed hysterically whenever I
mentioned the word "Forth". He almost convinced me I could
become a professional comedian. Then I told him the boot ROM in
his favorite workstation was a Forth system. He was so shocked
that he never laughed at "Forth" again. My hopes for a new
career in show business were dashed. It was an amazing
transition. Too bad there aren't a bigger variety of Forth
systems like that waiting to be discovered by C programmers.

> > Is ColorForth  going to be used for an application
> > that C programmers will enjoy?
> 
> I don't call myself a C programmer, though I must admit that
> I have done it.  But one member of our team has almost always
> been a C programmer prefessionaly and he loves OKAD II and
> colorforth because he is so damned productive with it.  You
> couldn't pry it out of his hands if you tried.

     Prying it out of his hands is not what we should be
thinking of with someone like that. We should wonder why more C
programmers don't feel the same way. What enabled him to make
the transition?
 
> > Will there be a ColorForth
> > training package for young students?

> Who knows, probably.
 
> > Is ColorForth going to be
> > such a small system that a programmer can understand every part
> > of it, or will the code be so muddled and tricky  that only the
> > most determined expert will be able to learn how it works?
 
> As you often say, that depends a lot on documentation.
 
> > When
> > big systems bog down and can't be ported to the new processors,
> > will ColorForth be used to write new replacements? How is
> > ColorForth going to improve Forth textbooks?
 
> Colorforth will have no effect on ANS Forth textbooks that
> are present or in the works.  Maybe I am missing your basic
> idea, I don't see how they are related.
 
> If you mean will there be colorforth textbooks that are
> better than older textbooks?  Who knows, as I have told
> you before these things depend mostly on interest.  If
> you are interested you can make it happen.  But bitching
> isn't going to make it happen.

       I am interested. Whose interest are you thinking of? The
only way I can make it happen is to convince whoever thinks they
understand the internal workings of ColorForth to do a decent
write-up. 

--
Michael Coughlin    m-coughlin@comcast.net   Cambridge, MA USA

"Jeff Fox" <fox@ultratechnology.com> wrote in message
news:4fbeeb5a.0312071249.2eaa565e@posting.google.com...
>
> ANS Forth has been sucessful in giving Forth more legitimacy
> to managers who rightfully want to have access to a pool of
> standard programmers.

    Not in my experience...

-- 

-GJC [MS Windows SDK MVP]
-Software Consultant (Embedded systems and Real Time Controls)
-gchanson@mvps.org

-Abolish public schools

"Jeff Fox" <fox@ultratechnology.com> wrote in message
news:4fbeeb5a.0312071302.1886d4ab@posting.google.com...
>
> Likewise, and in response to statements like that and given the extra
> qualifications like the word 'reasonable', I would also say that I'm
> not sure that ANS Forth is not a reasonable evolution of Forth, but
> I have some doubts.

    So do I.  ;)

-- 

-GJC [MS Windows SDK MVP]
-Software Consultant (Embedded systems and Real Time Controls)
-gchanson@mvps.org

-Abolish public schools

Tyler wrote:
> 
> m-coughlin <m-coughlin@comcast.net> wrote in message news:<3FD2E2FA.5720533D@comcast.net>...
> >      I don't know why we have so much trouble with floating
> > point arithmetic and files. Why don't people consider them to be
> > applications to be written for a Forth system?
> 
> Most of us who raise such issues don't use Forth as our primary
> tool and our expectations have been set by previous experience.
> I personally find files with names to be a useful abstraction
> over writing data to block numbers. I'm not alone. YMMV.
> 
      A file system can be more complicated than a Forth system.
A file system can be simpler than an MS-Dos file allocation and
directory system. If you want a file system, it doesn't have to
be a part of Forth. 
If you want a very simple disk storage system, you already have
it as part of Forth. It has one file for the whole disk and
there are no line endings in the source code. That might not be
popular with most people. Unfortunately when Forth has a file
system added to it, you sometimes lose the simplicity of Forth
and keep the inconveniences of its unusual editors. It would be
more interesting if the filesystems tacked onto Forth were meant
to find new and better ways to keep track of huge amounts of
information instead of just being copies of the same old file thing.

> > Does anybody get upset if an assembler doesn't somehow have a
> > file system built in?
 
> Ask the question another way: how many people will use an
> assembler that can't talk to the customer's existing file
> system? Sooner or later you're going to want that assembled
> code out of the assembler environment to be used elsewhere.
> Well, non-Forthians will, at least.

      The assemblers I've seen are application programs running
under an operating system and a shell. The file I/O is not part
of them. Neither is the editor or the linker. Old fashioned
standalone Forth includes all of that in a very simple form.
Maybe too simple for you. If you want something more
complicated, then you will have something much more complicated. 

> > Or if an assembler for a microprocessor without floating
> > point hardware doesn't have floating point instructions?
 
> Not a problem. But when I see colorForth aimed specifically
> at the Pentium and ignoring the floating-point capabilities
> of the chip, my eyebrow arches in skepticism. And when I see
> machine code dropped into definitions instead of the use of
> the assembler words, I see it as a danger sign.

      The missing floating point capability is an interesting
feature. It shows how you can cut out big pieces that are
normally essential and still have a running Forth, even
something useful to some people. The use of raw machine code
dropped into definitions is completely deadly, however. This
cripples a programmers understanding. To cut out, leave in, or
add new creative parts requires the programmer to understand how
everything fits together and exactly what each byte is used for.
Anything that makes understanding the code more difficult is
deadly. Its worse than dangerous.

> > Why don't people who need file systems and floating point just
> > ignore Forth systems that don't come with those and let
> > programmers who write for little embedded processors do their
> > thing? I guess its because programmers first learn a language
> > like C then can't think without a Unix (or Windows) operating
> > system.
> 
> This would be a better theory if it corresponded even remotely
> to the facts. In the early 1990s I worked at Embedded Systems
> Programming. During that time we saw Forth usage in our reader
> surveys steadily decline, from a small fraction to even smaller.
> Assembler was much more popular, but it also declined. C usage,
> on the other hand, kept expanding as compiler technology kept
> improving.

      During that time I wrote unsympathetically about the new
ANS standard. I was assured that my concerns were misplaced and
the new standard would make Forth more popular.  But I wrote
enough about that back then, so I'll write about something else instead.

> When the Harris folks marketed the RTX chips they immediately
> heard their customers asking for the RTX C compiler. That wasn't
> because they planned to run Windows or Linux on the RTX, but
> because they found C a useful tool for embedded applications.

       I think it is because C programmers don't want to be
retrained to use something as completely different as Forth. A C
compiler is more complicated than a Forth system and it is
harder to write. It does let trained programmers get to work
without learning anything radically new, but it might never have
the time and resources spent to be properly debugged for a
special purpose processor like the Novix. A Forth system
requires a different sort of thinking to use well. But being
different does not have to be harder to learn and it can show
better ways of doing things with a small processor. 

> I find it curious that Forth developers are quite able to
> accept customer requirements in developing embedded apps, but
> when a potential customer has requirements for Forth itself,
> the fur starts to fly.
> 
> >      So now how can ColorForth be used to solve all these
> > difficulties? Is ColorForth  going to be used for an application
> > that C programmers will enjoy? Will there be a ColorForth
> > training package for young students? Is ColorForth going to be
> > such a small system that a programmer can understand every part
> > of it, or will the code be so muddled and tricky  that only the
> > most determined expert will be able to learn how it works? When
> > big systems bog down and can't be ported to the new processors,
> > will ColorForth be used to write new replacements? How is
> > ColorForth going to improve Forth textbooks?
> 
> Those are all excellent questions. But I think we both know the
> answers with boil down to: Stop whining and fix it yourself.
> 
> That, and Jeff will ask you to stop spreading misinformation.

     ColorForth is not a polished system ready to sell as a
proven solution. It is an experiment. I hope all the fuss we are
making will be reported  back to its creator and help make it a
better experiment.

Anton Ertl wrote:
> jonah thomas <j2thomas@cavtel.net> writes:

>> 100,000 lines of C might truly be no harder to maintain than 500 
>>lines that define a special-purpose language and 500 lines of code in 
>>that language.

> Only if about 99000 of the C lines are empty or equivalent to empty.

Doesn't it dpeend on what the special-purpose language does?  Though I 
guess there's no way to get 500 lines of C code to make a language that 
can do more in a few lines than 100,000 lines of C code, so powerful 
special-purpose languages are inevitably complicated and inevitably 
buggy until they get a lot of use.  :(

> In the case of gforth-0.6.2 the special-purpose language is defined in
> 1586 lines (prims2x.fs), there are 2522 lines of code in that language
> (prim), and it generates 22482 lines of C code (which, when
> hand-written, would probably be less than half the size) and 1421
> lines of Forth code.

So you wind up with about 1/4 of the lines of C it generates, and maybe 
1/2 the lines you'd get with hand-written C.  That fits Elizabeth's 
experience with OTA, where the well-done Forth implementation was about 
half the size of the well-done C implementation.

> This organization vastly improves the maintainability, because a
> typical change in prim corresponds to 9 changes in the generated C
> code (and hand-writing would not change that).

Would it take fundamental changes in C to improve that?  It sounds like 
C requires redundancy that helps cause bugs.  You can fix some of that 
with macros etc, but mostly it makes sense to make those when you make 
the changes, so like armies, it gets you ready to remake the last 
change.  If you set up macros to help you with any plausible change you 
might like to make later, you wind up not programming in C so much as in 
a new language you're creating with macros.  So that doesn't solve it.

But it sounds like your C winds up being needlessly verbose, and your 
special-purpose language is getting around that problem with C.  It's 
about 1500 lines of C and then about 2500 lines of code in the language 
itself, only 3-5 times bigger than I was suggesting.  And you use it for 
a special purpose.  You don't need for users to learn it at all.

m-coughlin <m-coughlin@comcast.net> wrote in message news:<3FD3BDBA.EB43DF0A@comcast.net>...

>       C programmers love C since they can do all sorts of
> interesting things with it. I don't remember programmers saying
> how much they liked a programming language before C came around.

I feel more sorry for you than usual.  I didn't realize that you
background in other languages or exposure to other programmers
was quite so limited.  I guess you were born at just the wrong
time.  But keep trying all is not lost.

> The programing languages before C were just a constant struggle.
> And I don't know why things like Pascal and Fortran (without
> punch cards) didn't become more popular than C. But the real

I knew lots of people who enjoyed programming in a learning
various languages as they developed.  I even knew people who
enjoyed programming languages that I could not stomach.

> puzzle is why didn't Forth take over instead of C. Nowadays if a

I was thinking about your use of that expresssion earlier today.
How many times have I read your statements that 'if that were
true then it would have taken over the world.'  Such are often
the dismissals that people give about Forth.  

Of course if you were right about such things you would have
taken over the world. ;-)

> new programmer finds out about Forth he does not find any good
> examples to follow. He finds plenty of C programs to use and
> learn from. Forth has retreated from several areas where it was
> once common, like astronomy and robots. How did a silly language
> like C replace it? 

You are, I mean know the answer. ;-)

> I'm the one who uses the word missionary. I
> have to promise salvation in the future but not right now.

Good luck with your missionary work.  Someday in the future
the salvation that you have promised us will be a thing to
behold.  Perhaps then you will have taken over the world
as you so often aspire to in your posts. :-)

>  
> > .  .  .  There is so much documentation on some things that
> > it is hard to find the useful documentation, most of it is next to
> > useless.  Of course I don't start with the '... for dummies' type
> > manuals that are so popular.
> 
>    Well you should. 

You may be right.  Perhaps what has been lacking all these years
is 'Forth for Dummies.'  Is that what you are looking for?  You
seem to have asked for it many times.

> Like many things connected with computers,
> the dummies books are not what they are supposed to be. Some of
> them are carefully organized and informative. At least some of
> them present information that an expert in one computer area can
> use to learn about a new different area. Their jokes get stale
> after a while, so you woun't want to keep them as reference
> manuals. You can read them in the public library instead.

Don't forget the problem with over 40 million illiterate adult
Americans.  They will need a version on audio or video I guess.
  
>       Its just as true for any kind of Forth, but you have made
> up your mind about what you want in your version of Forth, so
> you don't have to worry about it anymore. Or sympathize with
> those who have not made up their minds.

I keep my eyes open and try to keep informed.  When someone 
asks a question about gForth I read the answers.  When someone
asks a question about iForth I read the answers.  When someone
asks a question about SwiftForth or VFX I read the answers.  I
like to know what choices are available and how they differ.

When someone asks a question about colorforth I read the massive
numbers of angry responses and name calling by people who seem
to know next to nothing about it and think that it would be best
if others were not informed.  Sorting out the answers is not 
hard if you know ahead of time who has experience with it and
who is likely to just repeat missinformation.  I make an attempt
to answer questions when asked as there are a few people who
want to make informed decsions.  I do it because I sympathize
with people who have made up their minds.  I don't have much
patience with people who have made up their minds in an absence
of information or who offer missinformation to make it nearly
impossible for other make to make informed decisions.
   
> > > But all that
> > > work and study did not result in a new crop of Forth textbooks
> > > to replace the old ones.
> > 
> > That is not true Mike.  How many times have people suggested
> > that you check out the new excellent Forth Inc. textbooks about
> > ANS Forth.  Those discussions have been beaten to death.  You
> > might turn off the killfile or whatever mechanism it is that
> > has prevented you from following up on the information about
> > new ANS Forth textbooks.  As someone who likes documentation
> > you certainly go out of your way to try to prevent other
> > people from learning about it. ;-)
> 
>      Actually people don't suggest reading the new textbooks
> very many times. 

They don't suggest it very many times or they don't suggest
reading the textbooks very many times?  It must be the latter
as the former is obviously not the case.  Half the people in
the newsgroup have suggested it to you one time or another.

> If you think these new books are so good, tell
> the world what they are. I don't know what I can do to prevent
> other people from learning about them, except by not mentioning
> them. 

You repeatedly tell people that no documentation exists, that
Forth programmers are genetically incapable of producing
documention.  You repeat many of the favorite negative sound
bytes about Forth.  It is many times worse than not mentioning
them. ;-)

> But you didn't bother to mention their titles either. If I

Give us a break. ;-)

> don't have anything good to say about these books, 

Reading them will help you form an opinion and help you
to realize that all is not a vacume.

> then in
> fairness I don't think I should say anything about them at all.
> But I'm going to reluctantly ignore that consideration, just
> this once, since you brought up the subject so forcefully. When
> as I heard about  Forth Inc.'s new textbooks, I went off to read
> them at the largest public repository of Forth literature in my
> area, the library of the Massachusetts Institute of Technology.

Let me guess.  You didn't find them.  So instead of taking an
active role and helping the University's library you gave up
and continue to tell people that they just don't exist... ;-)

> They were not there. I've checked every few months for years and
> they are still not there. I mentioned this a long time ago on

Have you asked the librarians to get them?  Have you purchased
a copy and donated it to the library?  Have you done anything
ever except bitch about it?

> comp.lang.forth and it didn't result in much or any discussion.
> After thinking about it a while, I realized this was not a good
> way to encourage people to read these books or even study Forth,

So you realized that bitching didn't work.  You gave up for a
while and then went back to bitching about it. ;-)

> so I decided to try to avoid the topic. Instead I mention the
> subject of textbooks in other contexts to see what Forth
> programmers currently recommend. It seems to me they still are

Just currious who this 'they' the Forth programmers that you
discuss these things with.  Certainly you could not be refering
to bitching about the topic in c.l.f.   

> using the old books, and not the new ones that I will not name
> in the hope that this will arouse curiosity and interest in them.
> 
>        There is a connection with Forth standards. I wrote a lot
> about the ANS standard years ago before it was approved. I don't
> want to write a lot about it now. Instead I want to find out
> about the other kinds of Forth. The current textbooks emphasize
> ANS Forth, not what I'm eager to learn.

You seem to want to keep your cake and eat it as well.  You complain
that the reason C is more popular than Forth is that there are
standards.  But standards with Forth are bad, or at least have no
interest for you.  So you want information on more obscure versions
of Forth.  Yet you then complain that the problem with Forth is
that there are obscure versions that don't have hundreds of books
about them like standardized languages like C.

>          Trying to find out about ColorForth is a big struggle.

Not really.  Except for someone with no internet access or perhaps
a lack of the ability to read.  There are lots of web pages, there
are lots of technical explanations, lots of philosophical explanations,
lots of examples, and lots of sources.  Oh, but they didn't jump
out at you at the library despite your checking there regularly. ;-)

> I have to wade thru a lot of messages and web pages to find the
> few little facts that tell me what I need to understand. Its a
> long process.

Poor baby.  What do you want, the ability to pick one of several
hundred books at random on colorforth at your local bookstore? :-)
 
> > > Those who made innovations in Forth
> > > wrote less about their progress than those who wanted to
> > > document a standard Forth.
>  
> > Systems with innovations in compiler design or user interface
> > design tend to have their own documentation.  For some reason
> > it is invisible only to you.
>  
>      If you want to make your point, mention some of these
> system so people who don't have my supposed problem will know
> what they are like and where to find them.

They have been mentioned to you endlessly in this newsgroup,
but reading web pages or reading questions and answers in
mail list archives is too difficult for you.

Best Wishes,
Jeff Fox

m-coughlin <m-coughlin@comcast.net> wrote in message news:<3FD3CACB.BDD77CC0@comcast.net>...
> agitated. Maybe Forth should come with warning labels that say

"Don't listen to what Mike Coughlin has to say about this." ?

>        I knew a C programmer who laughed hysterically whenever I
> mentioned the word "Forth". He almost convinced me I could
> become a professional comedian. Then I told him the boot ROM in
> his favorite workstation was a Forth system. 

Yes I have heard this story from you before.  You knowlege of
Forth is really impressive (to your even more clueless friends
who 'have trouble plugging in keyboards.'

> He was so shocked
> that he never laughed at "Forth" again. My hopes for a new
> career in show business were dashed. It was an amazing

Too bad. 

> transition. Too bad there aren't a bigger variety of Forth
> systems like that waiting to be discovered by C programmers.

Yes, too bad.  Poor baby, you would have more jokes for your
friends who are C programmers. ;-)
 
> > > Is ColorForth  going to be used for an application
> > > that C programmers will enjoy?
> > 
> > I don't call myself a C programmer, though I must admit that
> > I have done it.  But one member of our team has almost always
> > been a C programmer prefessionaly and he loves OKAD II and
> > colorforth because he is so damned productive with it.  You
> > couldn't pry it out of his hands if you tried.
> 
>      Prying it out of his hands is not what we should be
> thinking of with someone like that. 

Now that is an interesting comment.  What sort of people
should 'we' be thinking of prying it out of their hands?

(this would be a good place for you to say that if that
were true it would have taken over the world (again) ;-)

> We should wonder why more C
> programmers don't feel the same way. 

We should?  I think the answer is rather obvious.  Even
talking about colorforth in a Forth newsgroup is like
drawing a bulls-eye on yourself.  C programmers are
for the most part even more ignorant about this topic
than the colorforth haters in this Forth newsgroup.

Or perhaps you know a lot of C programmers working directly
with Mr. Moore and with full access to all the colorforth
software that he has.  Maybe I missed something.

If all I knew about colorforth was what I read in this
newsgroup, which I don't think is required reading for
C programmers, I would be about as intersted in it as
in getting cancer.

> What enabled him to make the transition?

Well first he came to the table with an impressive resume and
some rather incredible experience.  He knows exactly how much
work is required using this language or that or this product
or that because he has been doing that full time for quite a
while.  He knows exactly how much time he puts in on C or
with a particular CAD tool to get a job done, and he knows
exactly how much time he puts in to colorforth programming.
He values his time and he wants to be as productive as 
possible so he makes decisions based on pragmatic considerations.

He is not basing his opinion on what people who have no
experience with these topics say about them. ;-)
  
> > > Will there be a ColorForth
> > > training package for young students?
>  
> > Who knows, probably.

One of my duities, amoung others, is providing colorforth and
OKAD documentation.  Another of my professional duties is 
answering questions that the corporate partners have about
technical details.  But this is quite different than a
colorforth for dummies or children book.  Not that a colorforth
or OKAD book for children might not be a valuable thing.  As
I have said before, if you are really interested and not just
bitching make an offer that I can't refuse. Bitching won't
get it done. ;-)

> > > Is ColorForth going to be
> > > such a small system that a programmer can understand every part
> > > of it, or will the code be so muddled and tricky  that only the
> > > most determined expert will be able to learn how it works?
>  
> > As you often say, that depends a lot on documentation.
>  
> > > When
> > > big systems bog down and can't be ported to the new processors,
> > > will ColorForth be used to write new replacements? How is
> > > ColorForth going to improve Forth textbooks?
>  
> > Colorforth will have no effect on ANS Forth textbooks that
> > are present or in the works.  Maybe I am missing your basic
> > idea, I don't see how they are related.
>  
> > If you mean will there be colorforth textbooks that are
> > better than older textbooks?  Who knows, as I have told
> > you before these things depend mostly on interest.  If
> > you are interested you can make it happen.  But bitching
> > isn't going to make it happen.
> 
>        I am interested. Whose interest are you thinking of? The
> only way I can make it happen is to convince whoever thinks they
> understand the internal workings of ColorForth to do a decent
> write-up.

I don't think you answered the question.

Best Wishes,
Jeff Fox

"Gary Chanson" <gchanson@No.Spam.TheWorld.net> wrote in message news:<qgSAb.1576$kz2.1010@nwrdny01.gnilink.net>...
> "Jeff Fox" <fox@ultratechnology.com> wrote in message
> news:4fbeeb5a.0312071249.2eaa565e@posting.google.com...
> >
> > ANS Forth has been sucessful in giving Forth more legitimacy
> > to managers who rightfully want to have access to a pool of
> > standard programmers.
> 
>     Not in my experience...

Certainly not as much as Forth programmers would like to see. ;-)

Best Wishes,
Jeff Fox

nlper@junglemate.com (Tyler) wrote in message news:<65d29696.0312071514.53ec5ae8@posting.google.com>...
> When the Harris folks marketed the RTX chips they immediately 
> heard their customers asking for the RTX C compiler. That wasn't 
> because they planned to run Windows or Linux on the RTX, but 
> because they found C a useful tool for embedded applications.

Yes certainly, and because many more people have experience with
C than with Forth.  But Harris had limited success in marketing
even with the push toward C.

But the bottom line was that there was a much higher demand,
and perhaps a higher profit margin for 80C286 chips that were
produced on the same production line, so they met the demand
and made 286s instead of RTX.
 
Best Wishes,
Jeff Fox

Michael, I don't think we disagree as much as it might seem...

m-coughlin <m-coughlin@comcast.net> wrote in message news:<3FD3F66A.AE4D1ECC@comcast.net>...

>       A file system can be more complicated than a Forth system.
> A file system can be simpler than an MS-Dos file allocation and
> directory system. If you want a file system, it doesn't have to
> be a part of Forth.

From your mouth to Chuck's ear!

All those people who devoted efforts to creating and refining 
file systems -- who am I to allow all their work to go to waste?


> > > Does anybody get upset if an assembler doesn't somehow have a
> > > file system built in?
>  
> > Ask the question another way: how many people will use an
> > assembler that can't talk to the customer's existing file
> > system? Sooner or later you're going to want that assembled
> > code out of the assembler environment to be used elsewhere.
> > Well, non-Forthians will, at least.
> 
>       The assemblers I've seen are application programs running
> under an operating system and a shell. The file I/O is not part
> of them. Neither is the editor or the linker.

I agree with that. Executing a program usually connects some 
basic IO streams for you. However, once the assembler runs across 
an .include "foo.asm" directive, it has to know how to make a 
request of the file system and process the data. So to that 
extent it has to understand the file system interface. I didn't 
say an assembler had to contain a file system, just the 
interface code.

> Old fashioned
> standalone Forth includes all of that in a very simple form.
> Maybe too simple for you.

Actually, I find the old-fashioned Forth assembler to be perfectly 
adequate for most needs.


> The missing floating point capability is an interesting
> feature. It shows how you can cut out big pieces that are
> normally essential and still have a running Forth, even
> something useful to some people.

I mentioned it because I find it odd that many of colorForth's 
design decisions ignore common PC capabilities. I agree to a 
point with Chuck's assessment that floating-point isn't 
necessary for many apps, especially as we move to a 64-bit 
realm. But geez, the floating point unit was just sitting 
there...

But now that I've thought about it again, I'm going to 
recant on the floating point carping. Virtually everyone 
who has a serious need for floating point performance is 
also going to want things that today's colorForth doesn't 
have, so the lack of floating point words will likely 
never come up.

From a practical perspective, connecting to USB devices is 
a much more annoying thorn in the side. I don't expect it 
to go away quickly, either. It took a while for the Linux 
crowd to get things working, and they have many more warm 
bodies to work on it.


> The use of raw machine code
> dropped into definitions is completely deadly, however. This
> cripples a programmers understanding. To cut out, leave in, or
> add new creative parts requires the programmer to understand how
> everything fits together and exactly what each byte is used for.
> Anything that makes understanding the code more difficult is
> deadly. Its worse than dangerous.

Agreed. I was probably too wishy-washy on that point. ;-)


> > In the early 1990s I worked at Embedded Systems
> > Programming. During that time we saw Forth usage in our reader
> > surveys steadily decline, from a small fraction to even smaller.
> > Assembler was much more popular, but it also declined. C usage,
> > on the other hand, kept expanding as compiler technology kept
> > improving.
> 
>       During that time I wrote unsympathetically about the new
> ANS standard. I was assured that my concerns were misplaced and
> the new standard would make Forth more popular.  But I wrote
> enough about that back then, so I'll write about something else instead.

My vague memory of that time was that many of us wanted to believe 
an ANSI blessing would give warm fuzzy feelings to managers who 
were ambivalent about using Forth. What can I say? We were naive.


> > When the Harris folks marketed the RTX chips they immediately
> > heard their customers asking for the RTX C compiler. That wasn't
> > because they planned to run Windows or Linux on the RTX, but
> > because they found C a useful tool for embedded applications.
> 
>        I think it is because C programmers don't want to be
> retrained to use something as completely different as Forth.

Even back then embedded developers were using multiple languages, 
and I think the number of people who use multiple programming 
languages is much larger now. People who come out of school are 
likely to been exposed to Java and other non-C tools. Things 
are especially diverse in the Linux realm, where C reigns as the 
universal assembler but most distributions include other languages 
such as Java, Perl, Python, etc.

Now compare the fairly rapid rise of Perl and Python usage with 
state of Forth interest during the same period. I don't think 
that Forth's being different from C is the real issue with 
Forth's lack of acceptance. Perl and Python were good for 
solving problems that C sucked at. They combined interactive 
scripting strengths with data and hardware abstraction. 

Forth has always had interactivity as a strength, but instead 
of going for abstraction, Forthians have mostly tried to get 
closer to the hardware. Numerically, there are a lot fewer 
people who care about that kind of thing. And many of them 
are already comfortable with using a small amount of C or 
assembler and don't see a need for Forth's advantages.

Paul Graham's famous essay is significant in that regard. 
(I used to edit a Java magazine, but I still agree with his 
assessment of Java as an evolutionary dead end.) I'm thinking, 
in particular, of his remarks on efficiency:

"Inefficient software isn't gross. What's gross is a language 
that makes programmers do needless work. Wasting programmer time 
is the true inefficiency, not wasting machine time. This will 
become ever more clear as computers get faster."
<http://www.paulgraham.com/hundred.html>


> A C
> compiler is more complicated than a Forth system and it is
> harder to write. It does let trained programmers get to work
> without learning anything radically new, but it might never have
> the time and resources spent to be properly debugged for a
> special purpose processor like the Novix.

Yeah, even a C compiler couldn't save the RTX/Novix. But there 
are legions of Linux, Mac, Windows, and embedded programmers 
who would never think of writing a compiler. It's just a utility 
they use as part of their work or play.

One area that is very different in the C realm is the core 
acceptance of external standards. C itself is rather small; 
the functionality comes from the libraries. Having standard 
libraries and interfaces is an early learning experience 
for C programmers. Nothing like that exists in the Forth 
universe. Just for that issue alone it's not hard to see 
why C lovers and Forthians get along so poorly.


> A Forth system
> requires a different sort of thinking to use well. But being
> different does not have to be harder to learn and it can show
> better ways of doing things with a small processor. 

I agree on this point as well. That's part of my cognitive 
dissonance with colorForth -- I think that most embedded 
shops wouldn't use a Pentium as a "small" processor. So I 
kept asking myself, if it's poorly suited to most embedded 
designs, what would someone other than Chuck Moore use it for?


>      ColorForth is not a polished system ready to sell as a
> proven solution. It is an experiment. I hope all the fuss we are
> making will be reported  back to its creator and help make it a
> better experiment.

We'll know better after the colorForth II Jeff hinted at appears.
I'm not optimistic, but perhaps we'll be pleasantly surprised.

Cheers,
Tyler

m-coughlin <m-coughlin@comcast.net> wrote in message news:<3FD379DE.1C03F50@comcast.net>...
>       It doesn't have to do that. We can add ColorForth to a
> complicated system; we don't have to make ColorForth into a
> complicated system. 

WE?  Reconsider the commedian job! :-)

Best Wishes,
Jeff Fox

nlper@junglemate.com (Tyler) wrote in message news:<65d29696.0312071619.63a85b5d@posting.google.com>...

> > Evolution tends to evolve towards increasingly more complex organisms in
> > order to survive.  Programming languages are much the same way, and I

I agree with that.  But one can also simply explain that as marketing.
The revolving door of fashion drives the industry. 

If cars were made to last it would ruin the industry, if they got
good milage it would ruin another industry.  The computer industry
is exactly the same way.  If the stuff didn't fall out of fashion
instantly the industry would collapse.  And of course infinite
expansion and creeping featurism drive maketing but may also
lead to different kind of collapse.

> > fearlessly predict that ColorForth will only grow in complexity, not shrink.

I fearlessly predict that when colorforth is written in colorforth 
that there will be a significant reduction in complexity.  Also there
will be bug fixes.

> > And it is going to do this because if ColorForth is to tackle the kinds of
> > real-world applications that end users want, it is going to need a set of
> > standards. ....
> 
> I agree with your logic, but not your presupposition that the power 
> structure of colorForth is concerned with end user requirements. Chuck 
> has his goals, which revolve around OKAD x, not your mom. Everyone 
> else defers to him, at least politically, so there will never be 
> serious movement toward agreement on interfaces.
> 
> My fearless prediction is that colorForth will continue on its 
> current course of isolation. All the really hard work will always 

Yes, isolation is a relative term. I have been very pleased by the
growing colorforth community.  Oh, if only other forms of Forth
were growing as fast it would be enjoyed by more people.  In fact
rather the people making fearless predictions in a vacume I have
some access to information about it future and there is good news
and bad news.  Of course for some people the good news is bad news
and the bad news is good news.  It all depends on whether one 
thinks that isolation is good or not in this context.  Your opinion
is clear on that. ;-)

> seem like someone else's job, so you'll have a succession of 
> interesting single-user, single-developer projects. But the 
> barrier to using ColorForth in real world applications (with 
> the theoretical exception of OKAD x) will remain so high that 
> people will continue to choose other Forths and other languages 
> when they're trying to get real work done.
> 
> The logical way to avoid some of that fate would be to build on 
> existing host OS resources and libraries, but such an approach 
> would immediately collide with ego and aesthetics.

Do you mean like hosting colorforth in Windows or Linux?  I have
not seen the collision of egos or aesthetics in these groups. They
are encouraging to one other.  It is the people on the outside
who think it needs to be ripped out of other people's hands. ;-)

I agree with Howerd that such reactions are a good sign that
it is going in the right direction.

Best Wishes,
Jeff Fox

"Jeff Fox" <fox@ultratechnology.com> wrote in message
news:4fbeeb5a.0312080008.6c4b9d8b@posting.google.com...
>
> I agree with that.  But one can also simply explain that as marketing.
> The revolving door of fashion drives the industry.
>
> If cars were made to last it would ruin the industry, if they got
> good milage it would ruin another industry.  The computer industry
> is exactly the same way.  If the stuff didn't fall out of fashion
> instantly the industry would collapse.  And of course infinite
> expansion and creeping featurism drive maketing but may also
> lead to different kind of collapse.

    Computer companies think this is true but I don't think it really is.
The result of their thinking is layer upon layer of buggy code which has
gotten so complicated and brittle that the whole house of cards is on the
verge of colapsing under its own weight.

-- 

-GJC [MS Windows SDK MVP]
-Software Consultant (Embedded systems and Real Time Controls)
-gchanson@mvps.org

-Abolish public schools

John Passaniti <nntp@japanisshinto.com> wrote:
> Evolution tends to evolve towards increasingly more complex
> organisms in order to survive.

This is not certainly true.  There's a discussion at

http://bruce.edmonds.name/evolcomp/evolcomp_22.html

Andrew.

On 7 Dec 2003 15:14:34 -0800, nlper@junglemate.com (Tyler) wrote:

>When the Harris folks marketed the RTX chips they immediately 
>heard their customers asking for the RTX C compiler. That wasn't 
>because they planned to run Windows or Linux on the RTX, but 
>because they found C a useful tool for embedded applications.
>
>I find it curious that Forth developers are quite able to 
>accept customer requirements in developing embedded apps, but 
>when a potential customer has requirements for Forth itself, 
>the fur starts to fly.

In the days when floating point was an argument in Forth, MPE
decided that it was cheaper and easier to provide it than to
spend time arguing and discussing it with clients. Similarly,
these days we have the PowerNet TCP/IP stack in Forth for
embedded systems. PowerNet is both useful and fun. In
general it is more profitable to give clients what they
want.

As a side note, the RTX still lives in the form of our RTXcore
for FPGAs (see web site). Forth and C compilers are available.

Stephen
--
Stephen Pelc, stephenXXX@INVALID.mpeltd.demon.co.uk
MicroProcessor Engineering Ltd - More Real, Less Time
133 Hill Lane, Southampton SO15 5AF, England
tel: +44 (0)23 8063 1441, fax: +44 (0)23 8033 9691
web: http://www.mpeltd.demon.co.uk - free VFX Forth downloads

"Petrus Prawirodidjojo" <petrusp@att.biz> wrote in message news:<mailman.37.1070794791.31149.comp.lang.forth@ada-france.org>...
> >     It could be argued that since Chuck released Forth into the public
> > domain without any restrictions, that he has lost the right to call
> > something else "Forth".
> 
> Thanks for helping me find the argument.
> 
Nowadays there are so many non-ANS Forths that a new Forth being
non-compliant isn't a big surprise. Colorforth's bending of all the
rules includes its germenglish name.

It's closer to the original Forth philosophy than the current ANS as
far as Chuck is concerned and since nobody owns the trademark on Forth
he's free to apply the term to his new language. The argument centers
on whether or not this is a good thing. I think it's a moot point
since we're stuck with the name.

Colorforth's list of supported platforms is a little too short for me,
but the idea is pretty good. Maybe it's time for a C implementation of
ColorForth, or a VHDL/Verilog model of a MachineForth CPU with a
ColorForth to go with it.

Brad

"John Passaniti" <nntp@JapanIsShinto.com> wrote in message news:<D9zAb.1926$UK1.1719@news01.roc.ny>...
> My Mom (like most rational humans) isn't going to remember that she stored
> pictures of her grandson at blocks 2843, 4390, and 5304, her shopping list
> at 3495, and that to start her email client, she need to load block 8825.
> That's insane.  End users need to store data in terms of something symbolic.
> Maybe each application allocates a set of blocks and provides the user with
> a simple directory within that space.  Maybe it's a traditional file system
> with a more free-form allocation of blocks.  Maybe it's some kind of
> high-level object database.  Maybe it's something entirely new and
> different.  But whatever it is, it won't be raw blocks.  That's just stupid
> for end users.

Hello John,

Of course she wouldn't do what you've described.  But this problem was
solved years ago on other "block based" Forths.  If you have a copy of
Starting Forth take a look at the simple database in the appendix.
That could easily be extended to store "block number of photo" along
with "name, phone number, ect."  There have been many applications
written on block based forths where then end user wasn't aware that
they were dealing with a block based forth.

Regards,

John M. Drake

jmdrake wrote:
> Of course she wouldn't do what you've described.  But this problem was
> solved years ago on other "block based" Forths.  If you have a copy of
> Starting Forth take a look at the simple database in the appendix.
> That could easily be extended to store "block number of photo" along
> with "name, phone number, ect."  There have been many applications
> written on block based forths where then end user wasn't aware that
> they were dealing with a block based forth.

People who use a file system also don't realize that it is really a block
based storage (witnessed by how frequently people claim that files are a
stream of data - no, they are blocks on a disk - or blocks transferred over
a network - that appear to be a stream of data by at least one layer of
emulation).

BTW: "Longhorn" is announced to replace the file system for many user data
by a data base. The user doesn't want a file system with subdirectories, at
least according to Microsoft. My former neighbour once said she lost
something (a game), and it turned out that this game was "hidden" in a
subdirectory - all her data was spread out flat in the root directory of
C:. Not that I use a lot of subdirectories myself; usually, my file
hierarchies are shallow. "Order is for people who don't like to search",
and since searching is something computers are extremely good at, you don't
need order.

ColorForth could easily have a color for symbolic constants, and keep
symbolic names for screens in a repository.

-- 
Bernd Paysan
"If you want it done right, you have to do it yourself"
http://www.jwdt.com/~paysan/

"Bernd Paysan" <bernd.paysan@gmx.de> wrote in message
news:cunea1-pk5.ln1@miriam.mikron.de...
>
> "Order is for people who don't like to search",
> and since searching is something computers are extremely good at, you
don't
> need order.

    Just don't try it on Windows XP.  ];-)

-- 

-GJC [MS Windows SDK MVP]
-Software Consultant (Embedded systems and Real Time Controls)
-gchanson@mvps.org

-Abolish public schools

"Mark Slicker" <maslicke@oakland.edu> wrote in message
news:4c45abad.0312071357.76a738f5@posting.google.com...
> I had it wrong, but its hard to keep it strait because you have at
> different points said contradictory things. The quote I had
> remembered was:
>
> "The obvious answer is that no language is best, and that really,
> ultimately, language doesn't matter."

There is only contradiction if you take my comments out of context, which
you evidently have done.  Here, I'll save you the time to find the original
message with Google:

http://tinyurl.com/y9aa

The statement that "language doesn't matter" is not a statement that all
languages are the same.  Rather, "languages doesn't matter" is about
identifying the parts of programming languages that *do* matter-- the
paradigms, facilities, tools, computational models, and methodologies that
language provides.  When people do that, they are no longer limited by the
language they choose.  They can mix and match features of languages and
create their own language that uniquely addresses their needs.

> Consider this, I've never heard any complaint about the IJG code.
> And on the whole it is one of the better pieces of C code I've seen.
> Other C code that I see tends to get worse, not better than the IJG
> code. I've not seen a C code alternative to the IJG C code. That is
> what prompts me to say C programmers don't mind this code. I
> don't see any differences being expressed, in code or otherwise.

The danger of attempting to extrapolate the mindset of C programmers from
your subjective evaluation of a set of source code is the same danger C
programmers have when evaluating Forth from the various code available
online and elsewhere.  You're obviously willing to offer such a subjective
evaluation without a statement of how much experience and depth you have in
the C world.  Whatever.  I guess I'm not really that interested in seeing
you justify your ability to generalize a class of people based on your
subjective evaluation of an unknown amount of work in that language.

> I tend to answer my own questions a lot. I purposely chose JPEG
> off of Chuck's list, not only because it seemed useful but it looked
> liked the one of the more complex tasks on list. I was interested in
> how colorForth would support this kind of complexity. Up to this
> point I believe I had the far more modest Mandelbrot set under
> my belt. It was quite challenging, but I think this has more to do
> with JPEG, and less to do with colorForth.

The issue for me isn't if you were personally challenged.  I really don't
care.  What I do care about is if in your work with ColorForth, you came
across limits-- and what they are.  That gives me (and others) useful
information about ColorForth.  It tells us when and where the language may
need work.  It tells us what kinds of problems ColorForth may not be suited
for.

> Your Mom, from the description, is part of what is called the
> consumer market. There are obvious barriers to this market,
> beside the purely technical ones.

Yes, but as a class of applications, those targeting the consumer market are
ones that do tend to stress languages because of the multiple concerns they
address.  Take a typical application in the consumer market, say a word
processor.  Even the simplest of them have to deal with low-level details
like persistence of data, managing a GUI, dealing with fairly sophisticated
data structures, driving some output device, and so on.  And so, that's why
I bring up applications like my Mom would use-- because they represent a
certain level of sophistication that I think can be used to judge a language
like ColorForth.

I could have chosen a different market-- games for example.  I'm often very
impressed by the level of sophistication lurking in many of games.  Even
simple games these days often have to deal with sophisticated graphics,
audio DSP, AI, multithreading, simulation, and so on-- all within a
real-time context.  Implementing a game in ColorForth that incorporates at
least some of these elements would be the kind of thing one could use to
judge the language.

My point is that you can pick some real-world problem domain, look at the
concerns in that domain, and then see how well a language can deal with
them.  I'm not fixated on ColorForth for consumer market applications, but I
am fixated on seeing ColorForth address *some* problem domain seriously so
we can learn its limits.

> I don't think we have to wait till colorForth becomes a consumer
> OS before we can understand the limits more precisely. Public
> applications (OKAD II obviously excluded) that receive the beating
> of every day use I think is sufficient.

And what are these applications?

> > Until then, what we have is a bunch of programmers who are
> > essentially making predictions about ColorForth's scalability
> > and overall value based on some toy applications they've written.
>
> Who exactly is doing this?

Howerd Oakford for one.

> colorForth bypasses the serialization by just saying there is no
> difference in the data used by the application and data stored
> to disk. The technical need for serialization is that the data
> structures as they exist in memory can not be properly exported
> directly to the disk and be read back.

Well, more generically, it isn't just about storage to disk.  It's also
about transmitting data across machine and process boundaries.

But saying ColorForth "bypasses the serialization" is putting sugar-coating
on a bad apple.  What you are really saying is that ColorForth is simply
writing it's address space to disk.  That doesn't address the other purposes
for serialization, such as transmitting objects over some transport to a
different machine or process.  How would one do that in ColorForth?
Transmit the entire address space (or at least the used portion of the
address space)?  Ick.

> At this point I would not say colorForth needs a type system
> and the support for serializing data expressed in this type system.
> These are very general approaches, very much the opposite of
> the colorForth approach.

Sure, but these are also very common needs, facilities that programmers need
for non-trivial applications.  I have no problem with the idea that
ColorForth provides a low-level substrate to build things-- as needed-- on
top of.  I think that's great.  But I also see numerous facilities that are
important to not just me, but plenty of other programmers.  This is why I
want to see ColorForth used in serious real-world applications beyond OKAD,
your JPEG decoder, and the various toy programs that are discussed.

> I'm not talking about reinventing the wheel. That is what my jpeg
> code does in fact. What I am talking about is non-productive
> variations. When it comes to the point that each programmer has
> his own language and no code can be shared, we end up defeating
> ourselves. A language that purports to be general purpose must
> scale to a greater context. If that contradicts anything Chuck has
> said, then so be it.

But isn't this exactly what ColorForth is about?  Do you really think that
Charles Moore will reuse ColorForth if a future project's requirements
require something different?  I would think he would create a new language
to address that project's concerns, and while it probably would incorporate
elements from ColorForth (and past Forth efforts), I don't know why he would
compromise with a language that didn't meet the application's needs.

I think you (and others) want ColorForth to be something it can't be.  If
you take the philosophy of ColorForth to heart, you aren't going to end up
with one language, but many languages.  At least, that's how I interpret it.

stephenXXX@INVALID.mpeltd.demon.co.uk (Stephen Pelc) wrote in message news:<3fd479c7.264968421@192.168.0.1>...
> In general it is more profitable to give clients what they
> want.

Yes, for instance C.  But one can also take advantage of the
billions spent on producing that want in the clients mind in
the first place.  If you don't have the billions yourself you
can ride on crest of the current wave of fashion created by 
others.

> As a side note, the RTX still lives in the form of our RTXcore
> for FPGAs (see web site). Forth and C compilers are available.

Yes, I know.  And many of todays FPGA are faster than the two
or three micron standard cells from twenty years ago.  The 2010
had a remarkably long production life and the fact that people
were willing to pay ten grand a chip is definately a sign that
it was of value to some people.

Best Wishes,
Jeff Fox

 
> Stephen

"Jeff Fox" <fox@ultratechnology.com> wrote in message
news:4fbeeb5a.0312052009.614097e2@posting.google.com...
....
> Exactly.  It is a compromise made to make Forth look more conventional.
> As Elizabeth has said, when teaching Forth to C programmers they often
> come to realization that Forth looks exactly backwards to them from
> their C mindset.  So if we just run Forth backwards it will look more
> like C and be more popular with them.  That is why it should probably
> have been called htrof.

Um, I doubt seriously that I've ever said anything like that.  In teaching
C programmers I find that the start "getting it" when they realize that
Forth is a lot _simpler_ than C.  "Backwards" isn't a useful concept...
some things are done in a different order, but it's rarely "exactly
backwards".  It's just different.

Moreover, there was never any consideration during the development
of ANS Forth of making it "look more like C."  In fact, I can't think
of any examples of ANS Forth looking in any way like C.

Cheers,
Elizabeth

-- 
==================================================
Elizabeth D. Rather   (US & Canada)   800-55-FORTH
FORTH Inc.                         +1 310-491-3356
5155 W. Rosecrans Ave. #1018  Fax: +1 310-978-9454
Hawthorne, CA 90250
http://www.forth.com

"Forth-based products and Services for real-time
applications since 1973."
==================================================

Part Two:

"Mark Slicker" <maslicke@oakland.edu> wrote in message
news:4c45abad.0312071357.76a738f5@posting.google.com...
> Some of things I didn't expect:
>
> * The religious connotations and accusations (comp.lang.forth).
> I for one never expected myself to be accused a fundamentalist.

How old are you, Mark?  How long have you been involved with computers?  For
anyone to express surprise over the use of religious metaphors related to
computers (and to dozens of others subjects) suggests someone who doesn't
have a lot of experience, or someone who lives a pretty sheltered live.
Religious metaphors related to computers have been around for decades-- 
certainly predating the 20 years I've been a programmer.

I challenge you to name any field in which religious metaphors haven't been
used.

The purpose of a metaphor is to offer an implicit comparison between two
things, typically describing a fuzzy "is in some aspect like" relationship,
not a "is exactly the same as" relationship.  Relative to the subject of
computers, religious metaphors are typically used to show someone has a
faith placed in something.  It might be a language, a tool, a methodology,
or even a person who created a language, tool, or methodology.  When used in
a negative sense, such faith is seen as dogmatic and unquestioning.  When
used in a positive sense, such faith can be simply something one places a
lot of trust in.

There is nothing inherently wrong with being called a fundamentalist.  The
word can have negative connotations, but in a non-judgmental sense a
fundamentalist is simply someone who believes in a return to and a rigid
adherence to fundamental principles.  Of course, a fundamentalist can also
be someone who tends towards rigid and literal interpretation.  And
certainly, anyone who thinks that religious metaphors related to computers
are anything more than metaphors is certainly guilty of literal
interpretation.

> * The combination of fear, hatred, and dishonesty that have
> confronted colorForth (comp.lang.forth). This is seen most
> prominently in the recent discussions.

I wish you would have been more specific.  But regardless, there is a
depressing quality about some in this newsgroup who think that any open
questions or challenges constitute "fear, hatred, and dishonesty."  In some
cases it might be justified, but more often than not, we're simply talking
about a persecution complex, possibly driven by an inability to defend one's
views.

> * The idea that one should write all of ones code himself (colorForth
> mailing list). Coming from the open source community and knowing the
> benefits of collaboration and peer reviewed code this is the opposite
> of what I expected for what is essentially an open source community.

Yes, this is a persistent theme in not just ColorForth, but some of the
Forth discussions you see here.  I have a problem with this too.  Using
another metaphor, I once characterized the "lone wolf" model of programming
to be kind of like solo masturbation.  On the other hand the more
collaborative communities you see around most modern languages are more like
a party of friendly strangers hopping in the hot tub and having a good time.

A less racy metaphor is making music.  I enjoy playing keyboards alone, but
it's a hell of a lot more fun syncing up with others in a band.  When I'm
playing alone, I'm limited by my own creativity and drive.  I have total
freedom and can do whatever I want, but I'm also limited by my experience.
When I'm playing with others, I enjoy the exchange of ideas and the critical
evaluation of others.  Collaborative software development models are much
the same way.

> * The idea that only commercial vendors could offer quality Forth
> (comp.lang.forth). This contradicts the experience with open source
> languages which offer equal if not better quality to commercial
> offerings and are not limited by commercial licensing.

I think you need to define "quality" in order for this to make sense.  If
you judge quality in terms of documentation, support, and experience backing
the implementation, then very few open source (or just publicly available)
Forths can compete.  Gforth is one of the few.

Open source models only work when there is a critical mass of developers
behind them.  Much of the claim for why only commercial vendors can offer
quality Forths (for some definition of "quality") comes from the fact that
the Forth community is largely stuck in a "lone wolf" model.  There isn't a
lot of collaboration except in the abstract sense.

> * Bitterness and indifference toward Chuck Moore, the creator
> of Forth (comp.lang.forth).

I think at least some of the bitterness is imagined.  And what isn't
imagined is hyped.  I'd like examples, please.

As for indifference, Charles Moore can and should be respected as the
creator of Forth and for having a lot of ideas-- some good, some bad, some
innovative, some not.  From what I've seen and read, he's a really sharp
engineer, someone we can all learn from.  But anything beyond that is blind
hero worship.  Nobody should ever feel that they can't question anything
Charles Moore has done, or to provide intelligent criticism.  And
conversely, people should expect that Charles Moore will offer a reasoned
response.  This is what *any* engineer should expect of any other engineer-- 
and of themselves.

> * The idea the colorForth can in no way extend beyond Chuck
> Moore's needs, and meet the needs of a larger community
> (colorForth mailing list, comp.lang.forth).

ColorForth might be able to extend beyond Charles' needs.  It's entirely
possible that Charles will see contributed extensions to ColorForth that
match his philosophy, and that he thinks are worth incorporating into either
the base language or in packaged distributions of that language.  But I kind
of doubt it.  In ColorForth I see a philosophy of "do what you need and
nothing more" and I can't see ColorForth-- at least the ColorForth that
Charles Moore personally works with-- as gaining too much weight that he
doesn't need.

"Bernd Paysan" <bernd.paysan@gmx.de> wrote in message
news:cunea1-pk5.ln1@miriam.mikron.de...
> ColorForth could easily have a color for symbolic constants,
> and keep symbolic names for screens in a repository.

Sure, although what you describe is just another form of dictionary, isn't
it?  And the only reason one can't use the ColorForth dictionary for this is
(1) it has no concept of namespaces, and (2) symbols in the dictionary are
of variable length, with the length being determined by the uniqueness of
the characters of the symbol.

I'm not sure if your idea shows a way that ColorForth should/could be
extended, or if it points out a weakness in it's dictionary.

"jmdrake" <jmdrake_98@yahoo.com> wrote in message
news:e20a4a47.0312030725.92fc356@posting.google.com...
> You mean like a Mandelblot viewer?
> Or how about Conway's "game of life"?
> Both applications involve actual "user interaction".

Well, it's a start.  What I'm waiting for are applications that push the
limits of ColorForth.  I seriously doubt the authors of either a Mandelbrot
viewer or Game of Life will make any claim that ColorForth in any way
limited them.  The point I'm making here is you can't say that ColorForth
will scale based on the experience of a Mandelbrot viewer, Game of Life, and
a JPEG decoder.  To test the scalability of ColorForth, something larger and
more ambitious is needed.

ColorForth implemented in ColorForth might be that thing.

"John Passaniti" <nntp@JapanIsShinto.com> wrote in message news:<v97Bb.4757$PQ4.337@news01.roc.ny>...
> Part Two:
> 
> "Mark Slicker" <maslicke@oakland.edu> wrote in message
> news:4c45abad.0312071357.76a738f5@posting.google.com...
> > Some of things I didn't expect:
> >
> > * The religious connotations and accusations (comp.lang.forth).
> > I for one never expected myself to be accused a fundamentalist.
>
> Religious metaphors related to computers have been around for decades-- 
> certainly predating the 20 years I've been a programmer.

Religious connotations and accusations is what I said, not religious
metaphors. And yes I never seen a forum so rampant with them. If this
is not true give another member of the comp.lang hierarchy which can
be seen to sink to the level of comp.lang.forth in this particular
respect.

> There is nothing inherently wrong with being called a fundamentalist.

Are you trying to defend what you have said before? There is no
defense for it, no matter how hard you try to squirm.

> > * The combination of fear, hatred, and dishonesty that have
> > confronted colorForth (comp.lang.forth). This is seen most
> > prominently in the recent discussions.
> 
> I wish you would have been more specific.

It is my observation. If you want names, how about Tyler, Petrus,
Marcel. I can catalog specific examples but it is a waste of my time,
we all know the arguments and views that have been expressed, and many
of these have already been exposed. Jeff Fox most promiently has taken
on the thankless task. I have no patience for it. If someone wants to
further their knowledge on colorForth or critize specific aspects in
an honest and open fashion they will have my participation.

>  But regardless, there is a
> depressing quality about some in this newsgroup who think that any open
> questions or challenges constitute "fear, hatred, and dishonesty."  In some
> cases it might be justified, but more often than not, we're simply talking
> about a persecution complex, possibly driven by an inability to defend one's
> views.

Stooping to religious accusations -- in a technical forum no less! --
is the clearest most astute declaration that one is unable to defend
ones views.

Mark

Jeff Fox wrote:

[snip]

> m-coughlin <m-coughlin@comcast.net> wrote in message news:<3FD3BDBA.EB43DF0A@comcast.net>...

> You repeatedly tell people that no documentation exists, that
> Forth programmers are genetically incapable of producing
> documention.  You repeat many of the favorite negative sound
> bytes about Forth.  It is many times worse than not mentioning
> them. ;-)

    Well we are not getting anywhere with these long
discussions. Documentation is the weak point of Forth. If you
disagree, then you are entitled to your opinion.
 
[snip]
 
> You seem to want to keep your cake and eat it as well.  You complain
> that the reason C is more popular than Forth is that there are
> standards.  But standards with Forth are bad, or at least have no
> interest for you.  So you want information on more obscure versions
> of Forth.  Yet you then complain that the problem with Forth is
> that there are obscure versions that don't have hundreds of books
> about them like standardized languages like C.

     Nope. C is more popular than Forth because it didn't have a
standard. Instead it became popular because it had one good
textbook. It also had a large collection of applications that
people wanted to use, so they read that textbook. Maybe I don't
have to say anything bad about the ANS Forth standard since
Chuck Moore did a better job of that long before I did. But
there is more to the subject than what he mentioned. It is not a
good thing that there are many obscure versions of Forth (not
hundreds, but more than dozens) and no textbooks about them that
a publisher or a librarian would be interested in. That was not
true fifteen years ago.

[snip]
 
--
Michael Coughlin    m-coughlin@comcast.net   Cambridge, MA USA

     Let me try a whole different approach. In all these
discussions, I don't think I have hit the nail squarely on the
head, and there are a lot of bent nails and loose boards as a
result. 

     One of the best descriptions I've seen about the way Chuck
Moore works was written by the French aviator and author Antoine
de Saint-Exup�ry  -- "Perfection is achieved not when there is
nothing more to   add, but rather, when there is nothing left to
take away".

      He must have thought of this because he was an aircraft
pilot in the early days of flying, seventy to eighty years ago.
Airplanes were canvas, wood and piano wire. The engines were
weak. There couldn't be anything on these old planes that wasn't
absolutely necessary. Its the way Chuck wants his Forth systems.
Forth is not perfect. But what does it need? Chuck tries to take
things away, the rest of us want to put things back and add
more. Unfortunately there are too many involved who want to
build locomotives and battleships instead of airplanes.

     The usual way of writing programs these days is to use an
operating system with multitasking, disk files and bit mapped
graphical displays. The origins go back mainly to Xerox Parc and
AT&T Bell Labs. Chuck Moore claims that all this code is
unnecessary. A very strong statement. So he backs it up by
releasing ColorForth. Naturally anybody who is used to the
popular big systems is going to be perplexed. Most will decide
to ignore ColorForth. A few have decided to look it over and see
what is there. It much easier to see what is not there.
ColorForth is an experiment in removing things. Compare it to a
human powered airplane, not a jumbo jet. Anybody remember when a
flying machine without an engine was impossible? How did they do
the impossible? Maybe it was the same way Chuck wrote ColorForth.

         Forth with file systems, GUI's and all the other
contemporary collection of software is available for anybody who
wants it. Maybe I'll get around to using that kind someday. What
I really want to know is what pieces of his old Forth Chuck
managed to get rid of. I want to see what simplifications he's
made. Some of the changes make Forth more complicated. Maybe I
can take them away. 

           Chuck does not do write-ups. His work gets known by
the documentation of others. This can take a long time.
Perfection in documentation can not happen when everything gets
taken away.

--
Michael Coughlin    m-coughlin@comcast.net   Cambridge, MA USA

"Elizabeth D Rather" <erather@forth.com> wrote in message news:<wtKdnUd8IfoXbUmiRVn-jw@vel.net>...
> > Exactly.  It is a compromise made to make Forth look more conventional.
> > As Elizabeth has said, when teaching Forth to C programmers they often
> > come to realization that Forth looks exactly backwards to them from
> > their C mindset.  So if we just run Forth backwards it will look more
> > like C and be more popular with them.  That is why it should probably
> > have been called htrof.
> 
> Um, I doubt seriously that I've ever said anything like that.  In teaching
> C programmers I find that the start "getting it" when they realize that
> Forth is a lot _simpler_ than C.  "Backwards" isn't a useful concept...
> some things are done in a different order, but it's rarely "exactly
> backwards".  It's just different.

Perhaps I didn't make it clear what part of that you said.  There is
just one sentance attributed to you.  The part about teaching Forth
to C programmers and how sometimes when they finally get it they
say 'Oh, everything is backwards.'  You have certainly said that
in c.l.f.

The second comment, about how backwards Forth, another way I
refer to half Forth half C mixes that cater to the C way of
writing and organizing code, is my own comment.  You would
obviously never say anything like that. ;-)

Sometimes I wonder how selective your memory is.  For instance
when you claimed that you didn't know who Skip Carter was, or
when you claimed that you had never heard of Mitch's C-Forth.
I remember reviewing an old Forth Dimmensions where they listed
people on the ANS committee and I saw Mitch's name next to
yours and listed as Vice Chair I believe.  The article was
right above an add for his C-Forth.  Maybe you never read
Forth Dimmensions in those days or maybe you just didn't
remember Mitch and Skip.
 
> Moreover, there was never any consideration during the development
> of ANS Forth of making it "look more like C."  In fact, I can't think
> of any examples of ANS Forth looking in any way like C.

Yes, I heard you say that before. Along with the comments that you
had never heard of C-Forth.  I wonder if the Vice Chair ever heard
of you or Forth Inc. ;-)

Best Wishes,
Jeff Fox

Writing your own forth is not excessively difficult.   I have done one, 
the manual is at http://veteransinaction.org/michael

I did it as a learning exercise.  There are some additional example 
programs in the files directory on my site as well. 
http://veteransinaction.org/files

richardsnow@bellsouth.net

----- Original Message -----
From: "Mark Slicker" <maslicke@oakland.edu>
Newsgroups: comp.lang.forth
To: <comp.lang.forth@ada-france.org>
Sent: Tuesday, December 09, 2003 09:29
Subject: Religious connotations and accusations


> "John Passaniti" <nntp@JapanIsShinto.com> wrote in message
news:<v97Bb.4757$PQ4.337@news01.roc.ny>...
> > "Mark Slicker" <maslicke@oakland.edu> wrote in message
> > news:4c45abad.0312071357.76a738f5@posting.google.com...
> > > * The combination of fear, hatred, and dishonesty that have
> > > confronted colorForth (comp.lang.forth). This is seen most
> > > prominently in the recent discussions.
> >
> > I wish you would have been more specific.
>
> It is my observation. If you want names, how about Tyler, Petrus,
> Marcel.

You are not serious, are you.

BTW,
What do you call a small number of people, different than the rest, strongly
defend their ideas (militant?), filled with anger, always think being
attacked (paranoid?), lacks of humour, not easily influenced by the mass
(reject new ideas), seldom shy (very confident) ?

Pardon me for enjoying a lot of laugh.

Regards,
Petrus-Pet4th.

"John Passaniti" <nntp@JapanIsShinto.com> wrote in message news:<Gw7Bb.4759$eY4.4097@news01.roc.ny>...
> "jmdrake" <jmdrake_98@yahoo.com> wrote in message
> news:e20a4a47.0312030725.92fc356@posting.google.com...
> > You mean like a Mandelblot viewer?
> > Or how about Conway's "game of life"?
> > Both applications involve actual "user interaction".
> 
> Well, it's a start.  What I'm waiting for are applications that push the
> limits of ColorForth.  I seriously doubt the authors of either a Mandelbrot
> viewer or Game of Life will make any claim that ColorForth in any way
> limited them.  The point I'm making here is you can't say that ColorForth
> will scale based on the experience of a Mandelbrot viewer, Game of Life, and
> a JPEG decoder.  To test the scalability of ColorForth, something larger and
> more ambitious is needed.

Huh?  You're confusing me now.  After first your definition of significant
was a program that required "actual user interaction".  Now the definition
is a program that someone has trouble writing?  What does that have to
do with significance?
 
> ColorForth implemented in ColorForth might be that thing.

Ok, and when this is done will it count in your book if nobody reports
that ColorForth limited them in doing it?

Regards,

John M. Drake

"Petrus Prawirodidjojo" <petrusp@att.biz> wrote in message news:<mailman.52.1070971014.31149.comp.lang.forth@ada-france.org>...
> 
> You are not serious, are you.
> 
> BTW,
> What do you call a small number of people, different than the rest, strongly
> defend their ideas (militant?), filled with anger, always think being
> attacked (paranoid?), lacks of humour, not easily influenced by the mass
> (reject new ideas), seldom shy (very confident) ?
> 
> Pardon me for enjoying a lot of laugh.
> 
> Regards,
> Petrus-Pet4th.

What do you call someone who makes a vain brag about being able 
to write any ColorForth program he's seen so far in "two lines 
of regular forth" is called on it and asked to write a JPEG 
program in two lines and that "calls to routines in other 
programs don't count" but then wastes everybody's time with 
a call to internet explorer?  What do you call someone who 
cheers him on in such lunacy by "counting" the lines in 
his program?  How about someone who makes an obvious error
by saying NOTHING on Chuck's "wish list" has been done, then
when he's called on it tries to cover for his mistake by
minimizing all of the "nothing" that has been done?  What
about people who say that "ColorForth would be better if
it could be run from Linux" only to come up with some
other excuse once people point out that this has "already
been done"?  I used to think Jeff Fox was "paranoid" and
I still think he sometimes jumps to conclusions too 
quickly, but some people in this newsgroup seem determined
to prove his paranoia valid.

Regards,

John M. Drake

jmdrake wrote:
> "John Passaniti" <nntp@JapanIsShinto.com> wrote
>>"jmdrake" <jmdrake_98@yahoo.com> wrote 

>>>You mean like a Mandelblot viewer?
>>>Or how about Conway's "game of life"?
>>>Both applications involve actual "user interaction".

>>Well, it's a start.  What I'm waiting for are applications that push the
>>limits of ColorForth.  I seriously doubt the authors of either a Mandelbrot
>>viewer or Game of Life will make any claim that ColorForth in any way
>>limited them.  The point I'm making here is you can't say that ColorForth
>>will scale based on the experience of a Mandelbrot viewer, Game of Life, and
>>a JPEG decoder.  To test the scalability of ColorForth, something larger and
>>more ambitious is needed.

> Huh?  You're confusing me now.  After first your definition of significant
> was a program that required "actual user interaction".  Now the definition
> is a program that someone has trouble writing?  What does that have to
> do with significance?

He's stopped talking about significance.  Now he's talking about what he 
can learn from ColorForth.  He assumes there must be limitations 
somewhere, things that aren't as easy as everything else.  And so he 
wants to find where the limitations come, both since those would be a 
natural place for you to look for improvements, and because those help 
define the boundaries of where to use ColorForth and where to use 
something else.

>>ColorForth implemented in ColorForth might be that thing.

> Ok, and when this is done will it count in your book if nobody reports
> that ColorForth limited them in doing it?

Clearly, it won't.

Here's my guess.  I'm guessing that ColorForth doesn't give you many 
resources to handle complexity.  It's made with the idea that you do the 
easy things first, and then you do the hard things that you can make 
easy.  You don't go out and design in a lot of independent layers, so 
you can write code that will run provided that all the things in other 
layers you don't understand, all give the results you think they do. 
Instead you just do whatever it is you're going to do and then after you 
see you've done something similar a few times then maybe you factor that 
out.

So the limit comes with your ability to do things simply.  If it comes 
to implementing something that was specified by a large committee over a 
period of years, and that was then previously implemented by multiple 
teams that didn't quite understand the specs who cobbled together 
undocumented workarounds for the worst errors so their stuff would be 
interoperable, and now the job is to be interoperable with all of them 
-- chances are you'll go do something easier.  You won't build the tools 
to deal with that kind of complexity (though you could) because you just 
don't want to deal with that kind of thing.

That's a soft limit.  It's a limit in the minds of the people who use 
ColorForth, and every time one of them finds a simple way to do 
something that used to look hard, the limit shifts.  I expect that's the 
most important limit.

jmdrake wrote:

> I used to think Jeff Fox was "paranoid" and
> I still think he sometimes jumps to conclusions too 
> quickly, but some people in this newsgroup seem determined
> to prove his paranoia valid.

I remember a time when comp.lang.forth was known for its mellow, 
friendly atmosphere.  Very rarely we got some sort of troll who'd come 
in and try to stir up trouble and then leave.  It doesn't seem all that 
long ago.

John Passaniti has been here a long time, and he sort of trolls.  He'll 
glide from one technically-reasonable view to another while maintaining 
an emotional stance that gets some people upset.  When I'm careful to 
pay attention only to his technical points I learn things.

And Jeff Fox has been here a long time.  He's very easily trolled. 
Sometimes he's said things that seem to me over-enthusiastic, or 
possibly kind of like marketing-speak.  One example I remember, he had 
hardware that ought to be a hundred times faster (since it was smaller 
and efficient).  I think it was very fast when it didn't have to consult 
anything off-chip.  And he had software that was supposed to be a 
hundred times smaller, and that translated into another hundred-fold 
speed increase (provided getting the code was limiting and not getting 
data etc).  And he had a couple of other ten-fold or hundred-fold 
increases, and he figured he could multiply them all, that there was no 
overlap or anything else that would keep their speed improvements from 
being multiplicative, and so the result would be a million-fold 
improvement in speed.

I considered that he was excited about his project and so there was no 
need to take his projection literally.  If he got a thousand-fold speed 
increase that was great, and if it turned out higher that was even 
better, and it's mostly marketing people who project that far ahead 
anyway.  But some other people took him seriously and criticised his 
projection methodology.  I doubt he was looking for financial backing on 
comp.lang.forth, he was mostly pumping up his own enthusiasm to get 
himself past the inevitable delays and temporary disappointments, and 
people insisted on reasonable projections.  Jeff has invited more than 
his share of criticism by making claims that he can't back up using 
conventional assumptions, about things he can't yet provide physical 
proof for.  And he's often gotten upset about it, he'll leave 
comp.lang.forth for awhile and then come back when he's feeling better 
and draw more fire.

But this recent ugliness seems to me to be mostly recent.  I don't know 
what's caused the general change in tone, that used to be restricted to 
John Passaniti and Jeff Fox.

m-coughlin <m-coughlin@comcast.net> wrote in message news:<3FD5502C.5990DFD7@comcast.net>...

>      Nope. C is more popular than Forth because it didn't have a
> standard. 

K & R was the standard.

> Instead it became popular because it had one good
> textbook. 

Starting Forth is arguably a better textbook.

> It also had a large collection of applications that
> people wanted to use, so they read that textbook. 

Now here's the key.  The "collection of applications" 
better known as the Unix operating system was the real 
driving force behind the popularity of C.  In fact that 
was the driving force behind the creation of C.  The 
fact that Unix programs are often distributed as source 
and the fact that the shell is "C-like" meant that any 
serious Unix user had to learn C.  I suppose the same 
thing could have happened with the PolyForth operating 
system, but it didn't.  

Regards,

John M. Drake

"Petrus Prawirodidjojo" <petrusp@att.biz> wrote in message news:<mailman.52.1070971014.31149.comp.lang.forth@ada-france.org>...
> > > > * The combination of fear, hatred, and dishonesty that have
> > > > confronted colorForth (comp.lang.forth). This is seen most
> > > > prominently in the recent discussions.

What is kind of funny is that it is a microcosm of how the
outside world treats Forth in general. ;-)

> > > I wish you would have been more specific.
> >
> > It is my observation. If you want names, how about Tyler, Petrus,
> > Marcel.

That list is conspicuously short.
 
> You are not serious, are you.

I suspect that he was perfectly serious.
 
> BTW,
> What do you call a small number of people, 

a group

> different than the rest, strongly defend their ideas 

If they are defending their they are either simply
engaging in discussion or are defending from attack.
If defending from attack they a group defending their
ideas.

> (militant?),

No of course not.  The ones engaging in the attack in
the first place, the attack that prompts the defense,
are the ones who are being militant.

> filled with anger,

Angry.

> always think being attacked 

If they are defending, as you say, they they are being
attacked.  So they should be called the intended victoms.
If the attacks are successful then they may be called
the victoms, but if the attacks fail, due to proper
defense then they are only the intended victoms of attack.

>(paranoid?),

Calling those who are being attacked paranoid is a form
of attack.  Paranoid means that they think they are being
attacked when they are not.  

Often the attackers try to cover up their crimes with the
another crime, and another attack, trying to call the
intended victoms paranoid or defensive or those who
justly deserved to be attack.

They should probably be call vigalent. That is they are smart
enough to learn from the past and not fall victom to attack.
Once put on the defensive by the attackers they are smart
enough to remain vigalent.

> lacks of humour, 

Lacking in humor, or humorless. ;-)

> not easily influenced by the mass

Individuals.  People who seek the truth.  People who think
for themselves.

> (reject new ideas)

Conservative.  Defenders of the status quo.  Small minded.
Followers.

> seldom shy 

Outgoing, confident.

> (very confident) ?

Perhaps I have not been understanding enough of your 
limited English skills.  You seem to use a lot of words 
with the intention of the opposite of their
meaning. I hope the above helps you with that.

Best Wishes,
Jeff Fox
 
> Pardon me for enjoying a lot of laugh.

What do you call a person who engages in attacks, accuses
the intended victom of being the attacker, of being paranoid,
and lacking in humor, and who then laughs about their own
behavior?  The term for that is sociopath.

(Well I have also just been told that the term for that is
French. Though I think that is a bit unfair. ;-)  And I was 
just told that the proper term for someone like that is a 
f***ing idiot with too much time on their hands. Although 
I would never say something like that myself.  I have just been 
told that I should not waste my time on such people.  But 
it is fun.  It is almost as funny as the Jay Walk Allstars. ;-)

Best Wishes,
Jeff Fox

----- Original Message -----
From: "jmdrake" <jmdrake_98@yahoo.com>
Newsgroups: comp.lang.forth
To: <comp.lang.forth@ada-france.org>
Sent: Tuesday, December 09, 2003 23:35
Subject: Re: Religious connotations and accusations


> "Petrus Prawirodidjojo" <petrusp@att.biz> wrote in message
news:<mailman.52.1070971014.31149.comp.lang.forth@ada-france.org>...
> > BTW,
> > What do you call a small number of people, different than the rest,
strongly
> > defend their ideas (militant?), filled with anger, always think being
> > attacked (paranoid?), lacks of humour, not easily influenced by the mass
> > (reject new ideas), seldom shy (very confident) ?

> What do you call someone who makes a vain brag about being able
> to write any ColorForth program he's seen so far in "two lines
> of regular forth" is called on it and asked to write a JPEG
> program in two lines and that "calls to routines in other
> programs don't count" but then wastes everybody's time with
> a call to internet explorer?

Marcel is capable of doing difficult things, but it takes time. And time is
money. So instead he wrote those one and two liner. You must not take that
as serious (lacks of humor).

>  What do you call someone who
> cheers him on in such lunacy by "counting" the lines in
> his program?

That man is not full of anger, but full of humor. And he is not using
"lunacy" word right now.

> How about someone who makes an obvious error
> by saying NOTHING on Chuck's "wish list" has been done, then
> when he's called on it tries to cover for his mistake by
> minimizing all of the "nothing" that has been done?

Has this issue been settled yet? Is it caused by web site that is not
updated?

>  What
> about people who say that "ColorForth would be better if
> it could be run from Linux" only to come up with some
> other excuse once people point out that this has "already
> been done"?

There is issue of whether ColorForth is considered a kind of Forth, or Forth
by Chuck. As far as I know, ColorForth is the one on the Chuck web site. It
is kind of a trademark. Everybody may write a Forth that look like
ColorForth, but still it is not ColorForth. ANSForth is a label for every
Forth that comply to the ANSForth specification, and there is no ANSForth
brand name. And what is wrong with the suggestion? Do they have to apologize
if there are "ColorForth look alike" in Linux already?

>  I used to think Jeff Fox was "paranoid" and
> I still think he sometimes jumps to conclusions too
> quickly, but some people in this newsgroup seem determined
> to prove his paranoia valid.

Why did you use to think Jeff Fox was "paranoid"? Is there a reason? And do
you see any resemblance of you to Jeff if it is only slightly? If he really
sometimes jumps to conclusions too quickly, can this be a small proof that
his paranoia is valid? And can we blame someone who draw the right
conclusion?

I am just asking question. I do not answer them. Please do not accuse me of
insulting people.

Regards,
Petrus-Pet4th.

jmdrake_98@yahoo.com (jmdrake) wrote in message news:<e20a4a47.0312090934.18848dbb@posting.google.com>...
> Starting Forth is arguably a better textbook.

It is very well written.  But it was written for a different
time and different audience than you find today.  Perhaps
if it was slightly reworked and modernized it might fit
more closely into the Forth for Dummies niche that Mike
feels is important.
 
> > It also had a large collection of applications that
> > people wanted to use, so they read that textbook. 
> 
> Now here's the key.  The "collection of applications" 
> better known as the Unix operating system was the real 
> driving force behind the popularity of C.  In fact that 
> was the driving force behind the creation of C.  The 
> fact that Unix programs are often distributed as source 
> and the fact that the shell is "C-like" meant that any 
> serious Unix user had to learn C.  I suppose the same 
> thing could have happened with the PolyForth operating 
> system, but it didn't.  

The same sort of thing did happen.  But on a much smaller
scale.  Forth Inc. was not Bell Labs or AT&T and was not
able to prime the teaching institutions in the same way
that there were.  It is rather unfair to expect them
to have had that kind of big budget for promotion.

Best Wishes,
Jeff Fox

jonah thomas <j2thomas@cavtel.net> wrote in message news:<DynBb.19$vY.36038@news.uswest.net>...
> And Jeff Fox has been here a long time.  He's very easily trolled. 
> Sometimes he's said things that seem to me over-enthusiastic, or 
> possibly kind of like marketing-speak.  One example I remember, he had 
> hardware that ought to be a hundred times faster (since it was smaller 
> and efficient).  

I think you are missrepresenting something I said when you insert
the word because between statements that may have been true in some
context.  If I was talking about something that should be faster
there were probably a lot of reasons why it should be faster.  If
it had a hundred times less code to execute or was a hundred times
more efficient, all other things being the same, then those might
be reasons.  But I think you are attributing an after this therefore
because of this falacy to me.  Can you be more specific?

> I think it was very fast when it didn't have to consult 
> anything off-chip.  And he had software that was supposed to be a 
> hundred times smaller, and that translated into another hundred-fold 
> speed increase (provided getting the code was limiting and not getting 
> data etc).  And he had a couple of other ten-fold or hundred-fold 
> increases, and he figured he could multiply them all, that there was no 
> overlap or anything else that would keep their speed improvements from 
> being multiplicative, and so the result would be a million-fold 
> improvement in speed.

I have shown examples like that.  I know they upset people, but they
are not hard to find.  I would prefer however if you would be specific
because without details it sounds silly.

The ones that really upset people are the 1.8 x 10^18 projections
or the even larger ones when comparing commodity silicon to much
faster technologies.

> I considered that he was excited about his project and so there was no 
> need to take his projection literally.  If he got a thousand-fold speed 
> increase that was great, and if it turned out higher that was even 
> better, and it's mostly marketing people who project that far ahead 
> anyway.  

I disagree.  Most marketing people stick to saying we got a 20% or
a 100% improvement.  They know that people don't believe the bigger
numbers even when they are true.  And I know that we get so much
ANS marketing hype in the newsgroup and so many bentmarks that
real numbers are hard for people used to commodity products to
believe.

> But some other people took him seriously and criticised his 
> projection methodology.  

That's a rather incredible understatement.  There were lots of
people who said it was all lies, the chips didn't exist, the 
software didn't do what we said, the tools didn't do what we
said and they offered their own absurd made up numbers based
on exactly what I had written only an idiot or a person trying
to be intentionally deceptive would use.  For instance we say
we are making a Forth processor smaller and cheaper and faster
for Forth by focusing on Forth.  We clearly said that we were
doing this by tossing out all this expensive stuff that is
needed to run C.  So asking for C benchmarks or Unix benchmarks
or Specmarks designd to measure a systems ability to handle the
overhead that we eliminated would be either completely stupid
by missing the point or intentionaly deceptive.  So of course
people made up their own expectations of how C and Unix and
maybe their Forth written in C for Unix would run on these
chips designed for Forth.  Duh, their made up numbers were
a thousand times lower than mine.  But they proved only that
they wanted to use missinformation to keep real information
from being discussed.  

> I doubt he was looking for financial backing on
> comp.lang.forth, he was mostly pumping up his own enthusiasm to get 
> himself past the inevitable delays and temporary disappointments, and 
> people insisted on reasonable projections.

People insisted on C based benchmarks and taking everything Chuck
has done and trying to make sense of it in a C based mindset.  They
couldn't make sense of it out of context and dismissed it either
as you are doing as just someone being overly enthusiastic or
as complete lies.

>  Jeff has invited more than 
> his share of criticism by making claims that he can't back up using 
> conventional assumptions, 

It is called trying to talk about a Forth context. I am guilty of
inviting criticism by talking about Forth.  Of course since it has
nothing to do with C and the conventional assumptions that most
people make about C they dismiss it as well you can't back up
my misconception of what you are saying.  I maintain that I will
back up anyting I have said with factual information.  Please
give specific examples if you wish to defame my character in this
manner.

> about things he can't yet provide physical 
> proof for.  

Even when I have had physical proof people have claimed that it
was all lies.  And for instance I have no physical proof about
the chips that have not yet been fabed.  We have projections based
on conventional VLSI CAD tools and projections based on OKAD and
they are pretty much in sync.  From having seen dozens of chips
made I am willing to accept the evidence that I have, but it is
true that if Chuck or I say something about the current projects
it is sometimes projection.

I can give quite factual and physical proof for statements about
colorforth or OKAD's operation on the 300Mhz or 3G Pentium machines.
I can give physical numbers for those and physical numbers for the
speed of operation of that software etc.  But sure for the stuff
being designed today it isn't physical until it is physical.  But
I have no reason to doubt that projections by conventional software
or by OKAD II are too far off the mark.

> And he's often gotten upset about it, he'll leave 
> comp.lang.forth for awhile and then come back when he's feeling better 
> and draw more fire.
> 
> But this recent ugliness seems to me to be mostly recent.  I don't know 
> what's caused the general change in tone, that used to be restricted to 
> John Passaniti and Jeff Fox.

More people have had the guts to talk about unacceptable topics in
c.l.f so more people have been labeled and called names.  It is as
simple as that.  The more facts we can give and the more physical
proof that we have the more it upsets the people who feel threatened
by it.

I consider this post of yours a personal attack. I will consider it
as otherwise when you provide the references to the examples that
you listed above.

And by the way, when I said that I wished more people were willing
to express publicly what they have said in private I was thinking
of you.  I have heard things from you in private that you seem to
feel are not appropriate for public consumption.  You seem to have
tried to inject some reason and reality in places when this recent
storm of name calling and attacks took place seemingly trying to
moderate while not appear to take any side.  At least until this
most recent personal attack by you on my character.

I know that you don't want to become the target of such attacks
but I really wish that you could say in public things that you
have said in private about some of the things going on in c.l.f
or that you have been involved with behind the public scenes.
I was impressed when earlier this year you expressed some 
reservations about your contributions to ANS Forth.  But that
is not really where I think you are afraid to be too honest in
c.l.f.  

And seriously, please provide the actual reference to the
information that you were not able to believe and which you
have now publicly stated was just overly enthusiastic
exageration.  I hate to ask you for the proof, but if you
are going to make personal attacks like that please back
them up with the actual references and I will re-examine
the information and see if I was just being overly enthusiastic
or not.  You have introduced the accusation, so bring on
the evidence for us to examine.

Best Wishes,
Jeff Fox




BTW

jonah thomas <j2thomas@cavtel.net> wrote in message news:<61nBb.13$vY.30382@news.uswest.net>...
> Here's my guess.  I'm guessing that ColorForth doesn't give you many 
> resources to handle complexity.  

Probably the most important resource for handling complexity is
that a large fraction of the limited memory available is not being
wasted with code that you are not using and don't need for your
complex problem.  Freeing up memory to handle bigger more complex
problems is pretty obvious.

Then it is factored to let you define the data structures for
your application to make the most of the memory that you have.
That memory bandwidth is also likely to be the bottleneck anyway
so it doesn't start out with pre-defined hold anything containers
that people in other environments see as a resource.

> It's made with the idea that you do the 
> easy things first, 

The important things first like determining the ideal data
structures for the application.  This is probably more important
than anything else.  Code snippet optimization pales in comarison
to this.  It is silly to call this sort of thing doing the easy
part first.  It may be the most difficult thing because it is
also the most important thing.

If you don't take this approach you may fall into the trap of
using FILES or standardized packaging of structures and you
may end up with lots of your memory being wasted and see terrible
hits because you have to swap lots of stuff from mass storage to get
at it in the first place.

> and then you do the hard things that you can make 
> easy.  You don't go out and design in a lot of independent layers, so 
> you can write code that will run provided that all the things in other 
> layers you don't understand, all give the results you think they do. 
> Instead you just do whatever it is you're going to do and then after you 
> see you've done something similar a few times then maybe you factor that 
> out.

Not a bad guess.  After reimplenting and improving some things over
and over you always continue to look for new ways to get further
improvement.
 
> So the limit comes with your ability to do things simply.  If it comes 
> to implementing something that was specified by a large committee over a 
> period of years, and that was then previously implemented by multiple 
> teams that didn't quite understand the specs who cobbled together 
> undocumented workarounds for the worst errors so their stuff would be 
> interoperable, and now the job is to be interoperable with all of them 
> -- chances are you'll go do something easier.  You won't build the tools 
> to deal with that kind of complexity (though you could) because you just 
> don't want to deal with that kind of thing.

I have been warned that I make it sound easier than it is.  Perhaps
people will not really understand your description as it sounds like
you just focus on what is easy.  You focus on what is important, it
may require a lot of thought.  Thought is more important the the
number of lines of code that you write.
 
> That's a soft limit.  It's a limit in the minds of the people who use 
> ColorForth, and every time one of them finds a simple way to do 
> something that used to look hard, the limit shifts.  I expect that's the 
> most important limit.

That's not a bad guess, and it applies everywhere.  But it is of
extra importance in an environment that favors simplicity rather
than one where unneeded complexity (for your problem) is still
carried and at best just masked over as well as can be done.

Best Wishes,
Jeff Fox

maslicke@oakland.edu (Mark Slicker) wrote in message news:<4c45abad.0312081829.6c941642@posting.google.com>...

> Stooping to religious accusations -- in a technical forum no less! --
> is the clearest most astute declaration that one is unable to defend
> ones views.

Of course, certain tempests in a teapot can only be explained that
way. Such as the endian wars or segmented/non-segmented battles.

Forthers have often been called religious zealots, but we're not.
We're much more like heretics.

Brad

        IMHO, the difference is the level of tasks to be accomplished.  The tasks
in Starting Forth are not real world, considering the progress of todays
systems.  

        Better examples are needed.  Assuming a Unix or Windows based system,
command line filters would be a good example.  Socket programming.  Text
processing.  Things people could actually use, instead of recipe storage. 
Virtually no-one uses computers for that.

        How about practical examples of command line argument parsing?  That's a
precursor to being able to write useful filters, like a customized version
of tail, head, wc, sed, etc.  And tail would be a good example of reading
files, using the select() system call, and writing text.

        The trick, I think, is not to try to convince someone to switch to Forth,
but to allow the use Forth, and become enamored with it.  Integrate it into
useful processes, not replace everything whole hog.

        Another thing I see with example code in some of the compilers I've messed
with is that it tries to do too much too soon.  I wanted to mess with
command line arguments.  It took more to figure out what the code that I
didn't want was than the code I did want.  Example code often
over-optimized and under-documented.  The compiler author should never
write example code, because they know too much about their own system.  You
need someone who doesn't have an inate big picture of the compiler,
complete with optimizations, to write code that teaches people how to use
it.  Small bites, not cramming a whole steak (or cow) down your throat at
once.

        This is not to say that *all* examples I've seen are bad.  There are good
ones out there, they just seem to be a lot fewer and further between.  I
also haven't read every Forth book out there.  But I have read a lot of a
Perl books.  Practical Perl is a good approach.  Assuming the title hasn't
been used, Practical Forth would be good.

        As a comment on the state of Forth, consider this:  O'Reilly, who is one of
the most diversfied publishers there is, and who has books on damn near
every topic, has NO books on Forth.  A couple mention OpenBoot, but they're
generally Solaris/Sun specific.  Maybe getting a language in to the ORA
library is like getting on Johnny Carson (in the good old days.  Now I
think it's being on the Simpsons).  It means you've gone mainstream.

        --jc

Jeff Fox wrote:

> jmdrake_98@yahoo.com (jmdrake) wrote in message
> news:<e20a4a47.0312090934.18848dbb@posting.google.com>...
>> Starting Forth is arguably a better textbook.
> 
> It is very well written.  But it was written for a different
> time and different audience than you find today.  Perhaps
> if it was slightly reworked and modernized it might fit
> more closely into the Forth for Dummies niche that Mike
> feels is important.
>  
>> > It also had a large collection of applications that
>> > people wanted to use, so they read that textbook.
>> 
>> Now here's the key.  The "collection of applications"
>> better known as the Unix operating system was the real
>> driving force behind the popularity of C.  In fact that
>> was the driving force behind the creation of C.  The
>> fact that Unix programs are often distributed as source
>> and the fact that the shell is "C-like" meant that any
>> serious Unix user had to learn C.  I suppose the same
>> thing could have happened with the PolyForth operating
>> system, but it didn't.
> 
> The same sort of thing did happen.  But on a much smaller
> scale.  Forth Inc. was not Bell Labs or AT&T and was not
> able to prime the teaching institutions in the same way
> that there were.  It is rather unfair to expect them
> to have had that kind of big budget for promotion.
> 
> Best Wishes,
> Jeff Fox

Jeff Fox wrote:
> jonah thomas <j2thomas@cavtel.net> wrote

>>And Jeff Fox has been here a long time.  He's very easily trolled. 
>>Sometimes he's said things that seem to me over-enthusiastic, or 
>>possibly kind of like marketing-speak.  One example I remember, he had 
>>hardware that ought to be a hundred times faster (since it was smaller 
>>and efficient).  

> I think you are missrepresenting something I said when you insert
> the word because between statements that may have been true in some
> context.  

I apologise.  Some of what you have said has *seemed to me* to be 
simplistic extrapolations beyond what you claimed as evidence.  I didn't 
consider that to be a particularly bad thing, particularly because you 
were looking at possibilities.  At those times you weren't claiming to 
have irrefutable proof about those particular possibilities.

If I was talking about something that should be faster
> there were probably a lot of reasons why it should be faster.  If
> it had a hundred times less code to execute or was a hundred times
> more efficient, all other things being the same, then those might
> be reasons.  But I think you are attributing an after this therefore
> because of this falacy to me.  Can you be more specific?
> 
> 
>>And he had a couple of other ten-fold or hundred-fold 
>>increases, and he figured he could multiply them all, that there was no 
>>overlap or anything else that would keep their speed improvements from 
>>being multiplicative, and so the result would be a million-fold 
>>improvement in speed.

> I have shown examples like that.  I know they upset people, but they
> are not hard to find.  I would prefer however if you would be specific
> because without details it sounds silly.

I don't want to be specific.  I'd rather say that my own understanding 
of what you were talking about was too weak for me to make specific claims.

> The ones that really upset people are the 1.8 x 10^18 projections
> or the even larger ones when comparing commodity silicon to much
> faster technologies.

Yes.  When you estimate 10^18 faster, I wouldn't fault you if the result 
is only 10^9.  Halfway there.  ;)

>>But some other people took him seriously and criticised his 
>>projection methodology.  

> That's a rather incredible understatement.  

Yes, it is.  But here's my point -- in the old days they weren't doing 
that with anybody but you.

>> Jeff has invited more than 
>>his share of criticism by making claims that he can't back up using 
>>conventional assumptions, 

> Please
> give specific examples if you wish to defame my character in this
> manner.

I think we agree.  When you throw away the inefficiencies that people 
want to measure, they don't understand and they don't like it.  You 
can't do that using conventional assumptions, but those are the 
benchmarks that knowledgeable people use to go by.

>>about things he can't yet provide physical 
>>proof for.  

> Even when I have had physical proof people have claimed that it
> was all lies.  

True.  The only thing I saw was the computer that drew windows, that was 
built into your mouse.  You had a limited number of chips, and people 
who think you're lying anyway will think you're lying about the chips 
too until they see it for themselves.  But my point was that it used to 
be you were the only one who got that response.

>>And he's often gotten upset about it, he'll leave 
>>comp.lang.forth for awhile and then come back when he's feeling better 
>>and draw more fire.

>>But this recent ugliness seems to me to be mostly recent.  I don't know 
>>what's caused the general change in tone, that used to be restricted to 
>>John Passaniti and Jeff Fox.

> More people have had the guts to talk about unacceptable topics in
> c.l.f so more people have been labeled and called names.  It is as
> simple as that.  The more facts we can give and the more physical
> proof that we have the more it upsets the people who feel threatened
> by it.

It seems to be mostly ColorForth that I've noticed.  I don't know why it 
gets such negative attention.  I started it up and saw that I should 
have printed out some instructions first.  I played with the keyboard a 
little and found out *some* of how to do things with it, and then I 
quit.  I looked at some software snippets and they looked interesting 
but not extremely easy to follow without the background.  So I figured 
I'd come back to it sometime when I had more time to put into it and I'd 
print out some documentation before I started it.

If somebody else plays with it enough that it's easier to get into by 
the time I get back to it, that's great.  If I get the idea it isn't 
worth spending the time on, I'll be a bit disappointed but no big loss. 
I'll think more on why people care so much.

> I consider this post of yours a personal attack. I will consider it
> as otherwise when you provide the references to the examples that
> you listed above.

I apologise.  I will not provide references.  I will say that if you 
look at the situation from a conventional point of view, it's likely to 
look very much like what I said.  You present things that people tend 
not to believe.  They make their objections and you get a little huffy 
and they repeat their objections more forcefully.  I guess part of what 
gets people to do that is that they're more expert in what they know 
than you are, and you tell them that some of what they know is wrong. 
Possibly a more tentative approach might work better, a "...could it 
possibly be that this part here has a flaw that could allow..." sort of 
approach, or maybe that wouldn't help at all.  I dunno.

In the long run you can only prove them wrong or fail to, and the 
argument back and forth won't have helped much.

> And by the way, when I said that I wished more people were willing
> to express publicly what they have said in private I was thinking
> of you.  I have heard things from you in private that you seem to
> feel are not appropriate for public consumption.  You seem to have
> tried to inject some reason and reality in places when this recent
> storm of name calling and attacks took place seemingly trying to
> moderate while not appear to take any side.  At least until this
> most recent personal attack by you on my character.

I'm sorry.  Again, I felt like I understood why it was happening with 
you.  There's what you said, and the way you said it.  I don't remember 
anywhere near this level of bad feeling on comp.lang.forth before, with 
the exception of some threads involving John Passaniti, and some threads 
involving you, and pretty much every threat that involved both of you.

I don't understand why it's spread.  I'll think about it more.

> I know that you don't want to become the target of such attacks
> but I really wish that you could say in public things that you
> have said in private about some of the things going on in c.l.f
> or that you have been involved with behind the public scenes.
> I was impressed when earlier this year you expressed some 
> reservations about your contributions to ANS Forth.  But that
> is not really where I think you are afraid to be too honest in
> c.l.f.  

When the standard started up I had a dream that it might get Forth 
accepted in mainstream computing.  Lots of Forth jobs, lots of Forth 
teaching, etc.  It didn't happen.  When I look at it, there was an 
inevitability to it all.  We needed a standard.  It had to be a 
portability standard because we couldn't afford to fix on an 
implementation standard and we wouldn't be able to agree on one even if 
we were stupid enough to try for one.  But who really cares about 
porting Forth programs?  If you have a million dollar project 
half-complete in an MPE Forth are you going to switch to SwiftForth?  Is 
the possibility of that happening worth giving up the special 
capabilities the MPE Forth gives you?  (Or the different special 
capabilities SwiftForth gives you, if you start out there?)  It doesn't 
make sense.  And there are essentially no tools to help you tell how 
portable your code is.  If the big companies had started picking up 
Forth and they cared about code portability then there would be a market 
for tools to tell how portable the code actually is, and for tools to 
help document the environmental dependencies, and so on.  But it didn't 
happen and I guess wouldn't happen.  They don't care about code 
portability among compilers either, even for C code.

So besides the credibility of having a standard, most of what we get 
from it is a certain portability of programmers.  You can sit down with 
a Forth you've never used before and have a good chance to write some 
sort of productive code the first day, provided you get told clearly 
what is needed.  You won't know to use the special capabilities of that 
compiler, but you can do something that runs.

It ought to be worth more than that, but that looks like what we've got 
from it.

If we had something like Javascript etc, where we pass Forth code from 
one system to another, then standards would make a difference.  You'd 
want some idea whether the code would run.  But we mostly don't do that 
either.

I dunno.

Jeff Fox wrote:
> jonah thomas <j2thomas@cavtel.net> wrote

>>But this recent ugliness seems to me to be mostly recent.  I don't know 
>>what's caused the general change in tone, that used to be restricted to 
>>John Passaniti and Jeff Fox.

> More people have had the guts to talk about unacceptable topics in
> c.l.f so more people have been labeled and called names.  It is as
> simple as that.  The more facts we can give and the more physical
> proof that we have the more it upsets the people who feel threatened
> by it.

I don't think anybody involved is being evil.  We're all looking at it 
from our own points of view, and they don't mesh.  So I'll guess at what 
different people might be thinking and see where it goes.

Say that Chuck is planning a new chip.  Last time around iTV paid for a 
complicated OS, and since they were paying for it they wound up with 
whole layers of inefficient (theoretically portable) code.  And when 
they went dormant they kept it all.  Ideally the new chip would have a 
working OS (in the most general sense, all the code you need to interact 
with peripherals and get your applications running) from the first day 
it comes from the foundry.  It would be nice if it had some working 
applications too.

To get stuff ready before the hardware is ready, you emulate it.  OK, 
emulate it on PCs, those are the most common.  Release it to Forthers 
who might actually do some work.  The ones who get most interested will 
probably want expensive early chips, too.  Get it running, but it isn't 
important to use lots of PC capabilities, or use them well.  Why put in 
special code to use special video RAM?  There might not be any video RAM 
on the new system, or if there is it probably won't work like the PCs. 
Or if you do use PC peripherals, you can make your own computers and 
sell them with precisely the video cards etc you want.

You don't need to do a whole lot of hand-holding.  The Forthers who'll 
be the most useful are the ones who'll figure it all out for themselves. 
  The more effort you put into making it easy to use by people who don't 
want to figure out drivers etc, the more people you'll get who'll whine 
about documentation instead of contributing.

And of course you put in only enough documentation for the guy who needs 
to rewrite.  It's a work in progress, and the more time you spend 
documenting things that will change, the more time you waste.

 From that point of view it all makes sense to me, and I don't see that 
anything should be different.

Now I imagine the people who don't like it.  If I'm trying to live in a 
conventional computing environment, one where C programmers start booing 
and catcalling whenever the F word gets mentioned, I want everything 
they hear about Forth to come out sounding really good.  I don't want 
them to hear about a crackpot idea to re-invent the PC from scratch with 
custom chips.  I don't want them to hear about a brand new Forth for the 
PC that they probably can't run, that if they do run uses a crackpot new 
keyboard layout, that leaves out everything they think is important. 
Where is the assembler?  Scattered around.  Why does the code look like 
hex?  Because nobody's bothered to put the disassembler into the editor 
yet.  How does the version control work?  Whenever you feel like it, you 
put a new floppy into the disk and copy the current state of the system. 
  Label the floppy.  But there are multiple people working on the 
project, how do they do version control?  They don't, everybody does his 
own project and they copy or adapt anything they like.

It's a project that throws away everything that software engineering has 
learned since the 1980's.  It would give outsiders a very bad 
impression.  Never mind whether we actually ought to throw away 
everything that software engineering has learned since the 1980's.  It 
looks bad.

So if the important thing is to make Forth look good to C programmers 
then ColorForth is something that should be carefully hidden until it's 
ready.

I don't quite understand where the deep emotions come from.  Why get 
upset at people who talk about how much they like ColorForth?  Sure, 
let's say they aren't getting results as fast as they would with a 
professional Forth system.  They're prototyping stuff for a new chip, it 
doesn't need to be as fast to design that way.  They're still finding 
out what design tools they need.  Let's say the resulting code doesn't 
run as fast on a PC as some other code would.  That's fine too, they're 
only running on a PC because the new chips aren't ready yet.

So if the big problem is that they make respectable Forthers look bad, 
would it actually cause anybody trouble to give ColorForth a new name? 
The new stuff doesn't really need the Forth name for anything except 
nostalgia.  In fact when it comes time to actually market something the 
F word might cause them as much trouble as it causes the respectable 
Forthers.  Maybe there could be a contest for a new name.  Chuck could 
pick it, and the winner gets to tell people that he named the language. 
  My first choice is "Clast".  Short for "iconoclast", and you can use 
it whether you ever wind up with any icons or not.  All the code is 
Clast assembly language, and when it comes time to sell development 
systems you can sell a Forth compiler cheap and eventually write and 
sell a C compiler expensive.

Maybe I have it all wrong.  But it looks to me like the trouble is that 
people think of ColorForth as a worthless product for the PC that will 
give Forth and Forthers a bad reputation, when it's actually a product 
for a yet-undelivered chip.  And since Forth already has a bad 
reputation among orthodox programmers, why not use new names?  Why 
shouldn't everybody who wants to market a new Forth system use a new 
name, and provide links here so that we'll know about it, and avoid the 
F word while marketing as much as possible?

Jeff Fox wrote:
> 
> jmdrake_98@yahoo.com (jmdrake) wrote in message news:<e20a4a47.0312090934.18848dbb@posting.google.com>...

      I know Jeff is very particular and insists on accurate
reporting, so I'd better post this.

> > Starting Forth is arguably a better textbook.
 
> It is very well written.  But it was written for a different
> time and different audience than you find today.  Perhaps
> if it was slightly reworked and modernized it might fit
> more closely into the Forth for Dummies niche that Mike
> feels is important.

     I never said anything about wanting a Forth for Dummies. I
want to see a  textbook as clear as "Starting Forth" stay in
print. I'll tell my friends who want to learn how to write
programs to buy it and managers of computer projects who want to
stop using bloated code will find it for themselves. The main
new thing it needs is good examples of Forth coding style. A
modern edition of "Starting Forth" could teach writing turtle
graphics and adventure games for children or metacompilation for
software engineers. Naturally it should cover ColorForth as well
as those other versions.

> > > It also had a large collection of applications that
> > > people wanted to use, so they read that textbook.
> >
> > Now here's the key.  The "collection of applications"
> > better known as the Unix operating system was the real
> > driving force behind the popularity of C.  In fact that
> > was the driving force behind the creation of C.  The
> > fact that Unix programs are often distributed as source
> > and the fact that the shell is "C-like" meant that any
> > serious Unix user had to learn C.  I suppose the same
> > thing could have happened with the PolyForth operating
> > system, but it didn't.
 
> The same sort of thing did happen.  But on a much smaller
> scale.  Forth Inc. was not Bell Labs or AT&T and was not
> able to prime the teaching institutions in the same way
> that they were.  It is rather unfair to expect them
> to have had that kind of big budget for promotion.

      AT&T and Bell Labs did not "prime" the the teaching
institutions. Unix and C were created at a time when AT&T was
not allowed to be in the computer or software business. It was
the computer science students who worked at Bell Labs who asked
to take C and Unix back to their university computer
laboratories. It did the job they wanted better than anything
else that was available.  At the same time astronomers all over
the world took KIt Peak and NRAO Forth back to their local
observatories because it did the job they wanted better than
anything else. As time went on things changed. Why they changed
we can argue about. No commercial version of Forth has ever been
of great interest to university computer departments. We should
wonder why not. Its not a matter of a big company outspending a
little one on marketing. AT&T spent nothing on marketing Unix
when it was first adapted by universities. 

--
Michael Coughlin    m-coughlin@comcast.net    Cambridge, MA USA

jonah thomas <j2thomas@cavtel.net> wrote:

> I don't quite understand where the deep emotions come from.  Why get
> upset at people who talk about how much they like ColorForth?

I think that what is happening is that one side misrepresents the
other's position, the others get annoyed and fight back with their own
misrepresentation, and so on.

Now, I don't think that either side realizes that they're doing this.
They don't actually understand each others' positions.  They only
notice when their own positions are misrepresented.

If everyone could concentrate on promoting their own opinions rather
than rehashing other people's, much of the heat would go out of this.
I could quote a few choice examples, but I won't, because it would
look like I was attacking one side.

Andrew.

jonah thomas <j2thomas@cavtel.net> wrote in message news:<sTwBb.27$Ql1.35635@news.uswest.net>...
> > The ones that really upset people are the 1.8 x 10^18 projections
> > or the even larger ones when comparing commodity silicon to much
> > faster technologies.
> 
> Yes.  When you estimate 10^18 faster, I wouldn't fault you if the result 
> is only 10^9.  Halfway there.  ;)

Please notice that I at no time have claimed a 1.8 x 10^18 ratio
of anyting to anything.  I gave a nubmer from one row and column
in a benchmark.  My point being that most people unless scientists
just have a hard time relating to those kinds of numbers.

Plese don't claim that I said something was 1.8 x 10^18 times faster
than something else.  You just assumed that.  You didn't ask for
the context, or what row or column it was to make sense out of
it.
 
> >>But some other people took him seriously and criticised his 
> >>projection methodology.  
>  
> > That's a rather incredible understatement.  
> 
> Yes, it is.  But here's my point -- in the old days they weren't doing 
> that with anybody but you.

Yes. OK.  That I can accept.  I did expect more reasonableness in
c.l.f years ago to details of the improved Forth engines.  People had
already seen plenty of evidence of Novix beating 8086 and Harris's
RTX beating 286 and 386 by huge margins before P21/486/F21/586/etc.

I quickly realized that in newsgroups like comp.arch.embedded and
comp.realtime that people were used to timing interrupt response
and system task switches in many milliseconds to a few microseconds
depending on the system and how 'realtime' it really was so if 
I talked about doing interupt services or task switches in a few
nanoseconds, many years ago, people in those groups, used to
8051 and 68HC11 type machines would just think that I must be 
a kook.  Having numbers that seemed off by a thousand times or
more seemed unbelievable to those people and I quickly realized
that I could not discuss the stuff there.  Hey, I also used the
F word which immediately labels you as kook with many people.

But I did expect better from comp.lang.forth.  There were lots of
people who should have known better.  I was really quite shocked
that simply by giving people honest numbers from real chips that
actually existed that people would call me a liar, claim I was
lying about the chips because they really didn't exist, claim
that I was lying about the published benchmarks about program
size and speed, etc. since they really should have known better
and I knew that many people did know better.

What shocked me more was the silence from these people who should
know better when I was called a long list of defamatory names by
idiots.  I was even more shocked when people encouraged them.  I
was persistent however at continuing to hold firm to the facts.

> >> Jeff has invited more than 
> >>his share of criticism by making claims that he can't back up using 
> >>conventional assumptions, 
>  
> > Please
> > give specific examples if you wish to defame my character in this
> > manner.
> 
> I think we agree.  When you throw away the inefficiencies that people 
> want to measure, they don't understand and they don't like it.  You 
> can't do that using conventional assumptions, but those are the 
> benchmarks that knowledgeable people use to go by.

Yes, but I was rather shocked that so many people in comp.lang.forth
would be thinking entirely from this C world perspective and who
were only able to see Forth in terms of C.  I made jokes like there
are those who claim that it isn't Forth if it isn't written in C. ;-)
 
> >>about things he can't yet provide physical 
> >>proof for.  
>  
> > Even when I have had physical proof people have claimed that it
> > was all lies.  
> 
> True.  The only thing I saw was the computer that drew windows, that was 
> built into your mouse.  You had a limited number of chips, and people 
> who think you're lying anyway will think you're lying about the chips 
> too until they see it for themselves.  But my point was that it used to 
> be you were the only one who got that response.

Chuck doesn't like to use a mouse and he doesn't like the look and
feel of conventional GUI.  So I took a mouse and removed the 68HC05
in it and replaced it with an F21.  I wrote a tiny amount of code
to make it look like it was a mouse connected to a PC running windows.
The point was that it fooled a number of people into thinking that
that is what it was until I would point out that there was no PC,
that the mouse also contained the CPU the code for the OS and GUI
and the video card and the analog card and the network card.  It
was used to demonstrate that for the price of an ordinary mouse
one could easily have a few hundred mips and lots of expansion
cards built into that mouse.
 
> >>And he's often gotten upset about it, he'll leave 
> >>comp.lang.forth for awhile and then come back when he's feeling better 
> >>and draw more fire.
>  
> >>But this recent ugliness seems to me to be mostly recent.  I don't know 
> >>what's caused the general change in tone, that used to be restricted to 
> >>John Passaniti and Jeff Fox.

Well as you know I would complain to SVFIG that there were plenty of
other people there who saw Chuck give the exact same presentation to
them that I would report on in c.l.f.  When the resident haters would
proclaim in c.l.f that I was lying about what had presented at SVFIG
not a single other person from SVFIG, even those who post and/or lurk
in comp.lang.forth would have the backbone to stand up and be counted
and say, 'Yes, I heard Chuck say that.'  In fact some of them would
encourage the people who would claim it was lies.  I really was
suprised by their silence.  And as you know I even complained quite
directly to some people there, like you about it.

It amazes me how people are so afraid to contront a group of
people like that in a newsgroup.  I mean the worst they can do
is lie about you.  They can't lynch you or anyting.  Well, I guess
if the lies get hateful enough, as they have at times, they have
provoked crazy people to send hate mail and death threats.  I guess
other people are just too afraid of such things to express what they
know to be the truth in public.
  
> > More people have had the guts to talk about unacceptable topics in
> > c.l.f so more people have been labeled and called names.  It is as
> > simple as that.  The more facts we can give and the more physical
> > proof that we have the more it upsets the people who feel threatened
> > by it.
> 
> It seems to be mostly ColorForth that I've noticed.  I don't know why it 
> gets such negative attention.  I started it up and saw that I should 
> have printed out some instructions first.  I played with the keyboard a 
> little and found out *some* of how to do things with it, and then I 
> quit.  I looked at some software snippets and they looked interesting 
> but not extremely easy to follow without the background.  So I figured 
> I'd come back to it sometime when I had more time to put into it and I'd 
> print out some documentation before I started it.

Yes, well I have not been talking about that in this thread, but
rather the behavior of the majority of members of comp.lang.forth
who either put with silently or have encouraged the suppression of
information about forms of Forth that threaten them for their own
reasons.  I guess I just expect more backbone from the mainstream.
But we hear about how ordinary people turn their backs when they
see someone being mugged or raped or attacked in some public place
even when they greatly outnumber the people committing the crime.
There is the mob mentality phenomanon and there is the fight/flight/
or pretend it is not happening behavior in humans that often puzzles
me.
 
> If somebody else plays with it enough that it's easier to get into by 
> the time I get back to it, that's great.  If I get the idea it isn't 
> worth spending the time on, I'll be a bit disappointed but no big loss. 
> I'll think more on why people care so much.

I am not particularly concerned with your interst in colorforth.
It was your and others lack of action regarding the mugging that
was taking place when I arrived that concerned me.
 
> > I consider this post of yours a personal attack. I will consider it
> > as otherwise when you provide the references to the examples that
> > you listed above.
> 
> I apologise.  I will not provide references.  I will say that if you 
> look at the situation from a conventional point of view, it's likely to 
> look very much like what I said.  You present things that people tend 
> not to believe.  

That's not the problem I have with c.l.f.

> They make their objections and you get a little huffy 
> and they repeat their objections more forcefully.  

I have been told, that I should not be concerned when people claim
that I was lying, or when they post that I
am a dangerous cultist
and I get hate mail and death threats from people who read that
I was a dangerous cultist like Osama Bin Laden.   When things like
that have happend I don't get huffy, I get outraged.  And the outrage
is not with idiots who post such things, or with the even bigger
idiots who take them seriously.  My outrage is with all of you
who sit there quietly or describe it as 'Jeff is easily trolled
and he gets huffy when questioned.'  That is outrageous.

> I guess part of what 
> gets people to do that is that they're more expert in what they know 
> than you are, and you tell them that some of what they know is wrong. 

That's not my fault.  If there are people who are so stupid that they
don't think that some of what they think is right is wrong then we just
have to deal with their lack of connection to reality.  When they engage
in the kill the messanger behavior people should not encourage them or
try to dismiss it as 'Jeff gets huffy.'

> Possibly a more tentative approach might work better, a "...could it 
> possibly be that this part here has a flaw that could allow..." sort of 
> approach, or maybe that wouldn't help at all.  I dunno.

I have tried my best to answer any and all questions.  I tried for
years to behave 'gentlemanly' even when confronted by angry mobs of
people calling for blood.  And I have occasionally called the idiots
idiots.  The ones who are not idiots, and I know they know better
puzzle me the most.  It is not the mobs that puzzle me as much as
the bigger crowds who sit quietly and watch for entertainment.
 
> In the long run you can only prove them wrong or fail to, and the 
> argument back and forth won't have helped much.

Yes.  It used to depress me that there we so many stupid people
out there.  Then I began to see the humor in the fact that there
are achives and this stuff is in the record.  What is funny is
that people seem to be getting less rather than more aware of
when the wool has been pulled over their eyes.
 
> > And by the way, when I said that I wished more people were willing
> > to express publicly what they have said in private I was thinking
> > of you.  I have heard things from you in private that you seem to
> > feel are not appropriate for public consumption.  You seem to have
> > tried to inject some reason and reality in places when this recent
> > storm of name calling and attacks took place seemingly trying to
> > moderate while not appear to take any side.  At least until this
> > most recent personal attack by you on my character.

Well I was really getting into another issue here.  A completely
different issue that has nothing to do with me.  It has to do with
prominent people making cowardly attacks against Mr. Moore because
they know that he won't respond here.  But it is probably best
that we not go into that one anyway.  I have always felt like I 
had a number of trump cards that I have never been angry enough
to play.  Maybe it is best that I don't.  But I must admit that
I am often tempted to make some public statements about stuff that
I think stinks really bad.
 
> I'm sorry.  Again, I felt like I understood why it was happening with 
> you.  There's what you said, and the way you said it.  I don't remember 
> anywhere near this level of bad feeling on comp.lang.forth before, with 
> the exception of some threads involving John Passaniti, and some threads 
> involving you, and pretty much every threat that involved both of you.

Yes, well as I say I was talking about something completely different
above and probably better to not go there.  I find that most people
are pretty squimish about seeing anything anywhere near that level
of response.
 
> I don't understand why it's spread.  I'll think about it more.

I think it is obvious.  There were other targets recently before
I arrived and they were trying to be nice and gentlemanly.  When
I came into this 'interesting discussion' about colorforth as
it was called at the last SVFIG Forth day, I waded into the mob
as usual.  But it was pretty ugly before I got here this time.
 
> > I know that you don't want to become the target of such attacks
> > but I really wish that you could say in public things that you
> > have said in private about some of the things going on in c.l.f
> > or that you have been involved with behind the public scenes.
> > I was impressed when earlier this year you expressed some 
> > reservations about your contributions to ANS Forth.  But that
> > is not really where I think you are afraid to be too honest in
> > c.l.f.  

As I said above, probably best to not follow up on those paragraphs
unless you want to see serious escalation. 
 
> When the standard started up I had a dream that it might get Forth 
> accepted in mainstream computing.  Lots of Forth jobs, lots of Forth 
> teaching, etc. 

Yes, of course.  Pretty much everyone felt that way I think way
back when the ANS effort started some 19 years or so years ago.
And good things did come out of the effort.  I lauded the
group until I saw them sitting quitely watching or encouraging
the sort of behavior we have seen in these threads.  My complaints
have been about the biggots and people who don't think that they
are one of them should not be offended.  

> It didn't happen.  When I look at it, there was an 
> inevitability to it all.  We needed a standard.  It had to be a 
> portability standard because we couldn't afford to fix on an 
> implementation standard and we wouldn't be able to agree on one even if 
> we were stupid enough to try for one.  But who really cares about 
> porting Forth programs?  If you have a million dollar project 
> half-complete in an MPE Forth are you going to switch to SwiftForth?  Is 
> the possibility of that happening worth giving up the special 
> capabilities the MPE Forth gives you?  (Or the different special 
> capabilities SwiftForth gives you, if you start out there?)  

In this last year my only complaints have been about the 
statements about ANS Forth that just looked like total hype
to me.  They seemed every bit as damaging to Forth's reputation
to me as the people who believe that I lie about Forth chips
or our software and say unbelievable things about Forth.  

In the second part of my address to SVFIG I personally thanked
you for explaining what the reasoning was behind some of those
statements that looked like so much nonsense to up till this year.
Of course some of them still seem like nonsense to me too.

> It doesn't 
> make sense.  And there are essentially no tools to help you tell how 
> portable your code is.  If the big companies had started picking up 
> Forth and they cared about code portability then there would be a market 
> for tools to tell how portable the code actually is, and for tools to 
> help document the environmental dependencies, and so on.  But it didn't 
> happen and I guess wouldn't happen.  They don't care about code 
> portability among compilers either, even for C code.
> 
> So besides the credibility of having a standard, most of what we get 
> from it is a certain portability of programmers.  You can sit down with 
> a Forth you've never used before and have a good chance to write some 
> sort of productive code the first day, provided you get told clearly 
> what is needed.  You won't know to use the special capabilities of that 
> compiler, but you can do something that runs.
> 
> It ought to be worth more than that, but that looks like what we've got 
> from it.

Well that's quite a lot.

> If we had something like Javascript etc, where we pass Forth code from 
> one system to another, then standards would make a difference.  You'd 
> want some idea whether the code would run.  But we mostly don't do that 
> either.
> 
> I dunno.

Yes well at one time my vision was that if iTV had just been willing
to actually sell product (maybe if they had not let compeditors get
control of the board of directors) and had put a few hundred million
total Forth Internet appliances out there, or a few billion that
we would have a defacto binary and easy to learn Forth standard
and would let them play catch up rather than the other way around.
Something that made Java look pretty damn sick.  But hey, we missed
that mark and I really don't think it had anything to do with the
technical issues.

But we have even more exciting projects going on now.  Those were
nice toys but not like the next generation of ideas.  Well who
knows.

I guess I was also disappointed that FIG chapters would rather
sit around and discuss whether three character names and count
is really better than thirty-one character names or null delimited
names in a Forth dictionary well into the twenty-first century
rather than show interest in the future.   And of course then
there is always comp.lang.forth which as newsgroups go is now
below average I think, and that is pretty sad.

But Best Wishes,
Jeff Fox

----- Original Message -----
From: "Jeff Fox" <fox@ultratechnology.com>
Newsgroups: comp.lang.forth
To: <comp.lang.forth@ada-france.org>
Sent: Wednesday, December 10, 2003 04:56
Subject: Re: Religious connotations and accusations


> "Petrus Prawirodidjojo" <petrusp@att.biz> wrote in message
news:<mailman.52.1070971014.31149.comp.lang.forth@ada-france.org>...
> > > > > * The combination of fear, hatred, and dishonesty that have
> > > > > confronted colorForth (comp.lang.forth). This is seen most
> > > > > prominently in the recent discussions.

Again. You make the comment looks like from me.

Regards,
Petrus-Pet4th.

Gotcha. This is unpleasant surprise.

Regards,
Petrus-Pet4th.

----- Original Message -----
From: "Jeff Fox" <fox@ultratechnology.com>
Newsgroups: comp.lang.forth
To: <comp.lang.forth@ada-france.org>
Sent: Wednesday, December 10, 2003 08:15
Subject: Re: Religious connotations and accusations


In replying to: jonah thomas <j2thomas@cavtel.net> wrote in message
news:<DynBb.19$vY.36038@news.uswest.net>...

> I consider this post of yours a personal attack. I will consider it
> as otherwise when you provide the references to the examples that
> you listed above.
>
> And by the way, when I said that I wished more people were willing
> to express publicly what they have said in private I was thinking
> of you.  I have heard things from you in private that you seem to
> feel are not appropriate for public consumption.  You seem to have
> tried to inject some reason and reality in places when this recent
> storm of name calling and attacks took place seemingly trying to
> moderate while not appear to take any side.  At least until this
> most recent personal attack by you on my character.
>
> I know that you don't want to become the target of such attacks
> but I really wish that you could say in public things that you
> have said in private about some of the things going on in c.l.f
> or that you have been involved with behind the public scenes.
> I was impressed when earlier this year you expressed some
> reservations about your contributions to ANS Forth.  But that
> is not really where I think you are afraid to be too honest in
> c.l.f.
>
> And seriously, please provide the actual reference to the
> information that you were not able to believe and which you
> have now publicly stated was just overly enthusiastic
> exageration.  I hate to ask you for the proof, but if you
> are going to make personal attacks like that please back
> them up with the actual references and I will re-examine
> the information and see if I was just being overly enthusiastic
> or not.  You have introduced the accusation, so bring on
> the evidence for us to examine.

Jeff Fox wrote:
> What shocked me more was the silence from these people who should
> know better when I was called a long list of defamatory names by
> idiots.

That's what you call "don't feed the trolls". If someone insults someone
else, the best reaction is to have it a leaf message - one with no answers.

-- 
Bernd Paysan
"If you want it done right, you have to do it yourself"
http://www.jwdt.com/~paysan/

----- Original Message -----
From: "jonah thomas" <j2thomas@cavtel.net>
Newsgroups: comp.lang.forth
To: <comp.lang.forth@ada-france.org>
Sent: Wednesday, December 10, 2003 11:01
Subject: Re: Religious connotations and accusations


> I apologise.  I will not provide references.  I will say that if you
> look at the situation from a conventional point of view, it's likely to
> look very much like what I said.  You present things that people tend
> not to believe.  They make their objections and you get a little huffy
> and they repeat their objections more forcefully.  I guess part of what
> gets people to do that is that they're more expert in what they know
> than you are, and you tell them that some of what they know is wrong.
> Possibly a more tentative approach might work better, a "...could it
> possibly be that this part here has a flaw that could allow..." sort of
> approach, or maybe that wouldn't help at all.  I dunno.

It is a very good advise. And "I dunno, I dunno, I dunno, I'll think more
about it" is rather polite. I wish you are more active in this clf.

Regards,
Petrus-Pet4th.

----- Original Message ----- 
From: "jonah thomas" <j2thomas@cavtel.net>
Newsgroups: comp.lang.forth
To: <comp.lang.forth@ada-france.org>
Sent: Wednesday, December 10, 2003 11:52
Subject: Re: Religious connotations and accusations

> Maybe I have it all wrong.  But it looks to me like the trouble is that 
> people think of ColorForth as a worthless product for the PC that will 
> give Forth and Forthers a bad reputation, when it's actually a product 
> for a yet-undelivered chip.  And since Forth already has a bad 
> reputation among orthodox programmers, why not use new names?  Why 
> shouldn't everybody who wants to market a new Forth system use a new 
> name, and provide links here so that we'll know about it, and avoid the 
> F word while marketing as much as possible?

Nice try. If not success, please try again.

Regards,
Petrus-Pet4th.

"Petrus Prawirodidjojo" <petrusp@att.biz> wrote in message news:<mailman.63.1071054427.31149.comp.lang.forth@ada-france.org>...
> ----- Original Message -----
> From: "Jeff Fox" <fox@ultratechnology.com>
> Newsgroups: comp.lang.forth
> To: <comp.lang.forth@ada-france.org>
> Sent: Wednesday, December 10, 2003 04:56
> Subject: Re: Religious connotations and accusations
> 
> 
> > "Petrus Prawirodidjojo" <petrusp@att.biz> wrote in message
>  news:<mailman.52.1070971014.31149.comp.lang.forth@ada-france.org>...
> > > > > > * The combination of fear, hatred, and dishonesty that have
> > > > > > confronted colorForth (comp.lang.forth). This is seen most
> > > > > > prominently in the recent discussions.
> 
> Again. You make the comment looks like from me.

Again you make comment like idiot. It should be the least
of your concerns. Learn to count and read, learn how to post 
in usenet too.  More importantly learn them ethics and
something about Forth.

m-coughlin <m-coughlin@comcast.net> wrote in message news:<3FD6AC84.2226DCDD@comcast.net>...
> of great interest to university computer departments. We should
> wonder why not. Its not a matter of a big company outspending a
> little one on marketing. AT&T spent nothing on marketing Unix
> when it was first adapted by universities.

If you sell the product for $40,000 per license and give it
for free to certain people it is called a $40,000 rebate
in today's marketing terms.  Multiply that by the number of
copies that came with the rebate. ...

Jeff Fox wrote:
> If you sell the product for $40,000 per license and give it
> for free to certain people it is called a $40,000 rebate
> in today's marketing terms.  Multiply that by the number of
> copies that came with the rebate. ...

That's not the money they spent, because it would assume that the license
was $40k worth. It might be a psychological thing, as a recent Dilbert
explained (or rather, Dogbert explained it ;-). Have a high nominal price,
and announce a special rebate at the same time - this will create the
impression that the worth of the thing sold is the nominal price, and the
rebate is something you save. Dogbert proposed to make the product's cost a
million and thirty dollars, and give a million rebate.

Unix became popular because it was a toy project*, and AT&T managed to
disguise this by setting up a high nominal price. This allowed all
participants to continue toying around and doing funny stuff (like writing
'fortune'), while being founded by research money.

*) It did not run on real hardware, only on toy 16 bit CPUs which didn't
require a room of their own. It did not provide all the elaborated services
VMS, MVS, OS/370 and others did. It had a special, new, crippled and
unmaintainable language called 'C', which used integers as pointers instead
of easily guarded arrays. It had severe security problems by having an
omnipotent 'root' user. It had an inefficient file system where you can't
allocate cylinders and blocks on your own, so the files would get
fragmented easily. The file system was often corrupted and needed checking
and repairing. In other words: in the late 70s, Unix was considered a step
back by 30 years of OS design (by the zealots of the older OSes ;-).

-- 
Bernd Paysan
"If you want it done right, you have to do it yourself"
http://www.jwdt.com/~paysan/

"Petrus Prawirodidjojo" <petrusp@att.biz> wrote in message news:<mailman.60.1071014267.31149.comp.lang.forth@ada-france.org>...

> > What do you call someone who makes a vain brag about being able
> > to write any ColorForth program he's seen so far in "two lines
> > of regular forth" is called on it and asked to write a JPEG
> > program in two lines and that "calls to routines in other
> > programs don't count" but then wastes everybody's time with
> > a call to internet explorer?
> 
> Marcel is capable of doing difficult things, but it takes time. And time is
> money. So instead he wrote those one and two liner. You must not take that
> as serious (lacks of humor).

The "time is money" argument can be applied to many things.  For instance
why ColorForth doesn't boot from a CD.

That said if Marcel knew he didn't have time to write a two line JPEG
decoder (or a two line Mandelblot viewer or a two line fill-in-the-blank)
then why say that he could?  Oh, and brushing off derision as "bad
humor" doesn't make it less derisive.  Many people in the ANS Forth
community have taken great offense at things Jeff has said that could
be viewed as humor.
 
> >  What do you call someone who
> > cheers him on in such lunacy by "counting" the lines in
> > his program?
> 
> That man is not full of anger, but full of humor. And he is not using
> "lunacy" word right now.

And your point is?

> 
> > How about someone who makes an obvious error
> > by saying NOTHING on Chuck's "wish list" has been done, then
> > when he's called on it tries to cover for his mistake by
> > minimizing all of the "nothing" that has been done?
> 
> Has this issue been settled yet? Is it caused by web site that is not
> updated?

Not really.  1) Some of the stuff that hasn't been updated on the
website has been repeated here many times.  Since you like counting
so much, why not count the number of times the ColorForth JPEG
decoder has been mentioned?  Any serious person who has followed
the discussion should have known about at least THAT example.  
2) The "correction" was pointed out to Marcel in a most polite
manner.  At that point he could (and should) have simply said
"my mistake".  

 
> >  What
> > about people who say that "ColorForth would be better if
> > it could be run from Linux" only to come up with some
> > other excuse once people point out that this has "already
> > been done"?
> 
> There is issue of whether ColorForth is considered a kind of Forth, or Forth
> by Chuck. As far as I know, ColorForth is the one on the Chuck web site. It
> is kind of a trademark.

So you're and others are waiting for Chuck to write a Linux version
of ColorForth?  For the record those who wrote the Linux and Windows
versions of ColorForth did so with Chuck's approval.

> Everybody may write a Forth that look like
> ColorForth, but still it is not ColorForth. ANSForth is a label for every
> Forth that comply to the ANSForth specification, and there is no ANSForth
> brand name. And what is wrong with the suggestion? Do they have to apologize
> if there are "ColorForth look alike" in Linux already?

There's nothing wrong with making the suggestion.  But when after being told
"it's already been done" they come back with the SAME suggestion it raises
eyebrows.  It's like saying "If you really cared about mothers you would
set aside a holiday honoring them."  Nothing wrong with the suggestion.
It's just already been done.

> 
> >  I used to think Jeff Fox was "paranoid" and
> > I still think he sometimes jumps to conclusions too
> > quickly, but some people in this newsgroup seem determined
> > to prove his paranoia valid.
> 
> Why did you use to think Jeff Fox was "paranoid"? Is there a reason? 

Because he complained about all of the irrational "non ANS" Forth hatred 
in c.l.f. I'm beginning to see that he's right.

> And do
> you see any resemblance of you to Jeff if it is only slightly?

Not really.  But if so I'll take that as a compliment.  But I've seen
a picture of Jeff and we really don't look anything alike.

> If he really
> sometimes jumps to conclusions too quickly, can this be a small proof that
> his paranoia is valid? And can we blame someone who draw the right
> conclusion?

And what happens when someone who, like myself, used to think some of his
conclusions were off base, but after reviewing the evidence for YEARS
start to come to the same conclusions?

Regards,

John M. Drake

jonah thomas wrote in <j2thomas@cavtel.net> wrote in message news:<61nBb.13$vY.30382@news.uswest.net>...
> > Here's my guess.  I'm guessing that ColorForth doesn't give you many 
> > resources to handle complexity.

Then fox@ultratechnology.com (Jeff Fox) wrote in message news:<4fbeeb5a.0312091727.1d7e4b57@posting.google.com>...

> Probably the most important resource for handling complexity is
> that a large fraction of the limited memory available is not being
> wasted with code that you are not using and don't need for your
> complex problem.  Freeing up memory to handle bigger more complex
> problems is pretty obvious.

What "limited memory" is that? Unless you're running on extremely 
old PCs, colorForth's typical environment has tens or hundreds of 
megabytes of free RAM and tens of gigabytes of free disk space. 
The difference in free space between colorForth and a Linux-based 
Forth is a vanishingly small fraction of those totals.

If you're talking about manipulating very large images or video 
streams, Linux (and Windows, for that matter) provide virtual 
memory mechanisms. I don't recall seeing that facility in 
colorForth.

Tyler

Jeff Fox wrote:
 
> m-coughlin <m-coughlin@comcast.net> wrote in message news:<3FD6AC84.2226DCDD@comcast.net>...
> > of great interest to university computer departments. We should
> > wonder why not. Its not a matter of a big company outspending a
> > little one on marketing. AT&T spent nothing on marketing Unix
> > when it was first adapted by universities.
 
> If you sell the product for $40,000 per license and give it
> for free to certain people it is called a $40,000 rebate
> in today's marketing terms.  Multiply that by the number of
> copies that came with the rebate. ...

   You probably didn't use Unix as early as I did. At first Unix
could not be sold. It was an internal system for use only by
AT&T. There was a requirement worked out with the United States
federal government that since AT&T was a legal monopoly
providing telephone service, it could not engage in other
businesses in competition with businesses that did not have the
privilege of being a monopoly. This was the time when the
universities started using Unix. It was given to them as a
contribution to educational research. After the universities
started to use Unix and AT&T was broken up into pieces that
could engage in the computer and software business, then AT&T
could ask $40,000 or whatever it could get for a license. This
early history is studied with care by Unix gurus since it is
important to understand certain historical facts to understand
why Unix (and hence Linux) is the way it is today. There were
other computer companies that made grants to universities, for
example IBM and DEC, but their commercially marketed software
did not make as good an impression as non-commercial
unlawful-to-market Unix. If anything Unix and AT&T received the
benefit of marketing that universities provided since they
decided C and Unix were very good systems to teach new students.
A reason AT&T could charge $40,000 per license was because there
were well educated programmers that knew it was worth it to
begin with. 

     Too bad there isn't a version of Forth that is well suited
and popular for use by college students.

--
Michael Coughlin    m-coughlin@comcast.net   Cambridge, MA USA

"Jeff Fox" <fox@ultratechnology.com> wrote in message
news:4fbeeb5a.0312082243.2de58c91@posting.google.com...
> "Elizabeth D Rather" <erather@forth.com> wrote in message
news:<wtKdnUd8IfoXbUmiRVn-jw@vel.net>...
> > > Exactly.  It is a compromise made to make Forth look more
conventional.
> > > As Elizabeth has said, when teaching Forth to C programmers they often
> > > come to realization that Forth looks exactly backwards to them from
> > > their C mindset.  So if we just run Forth backwards it will look more
> > > like C and be more popular with them.  That is why it should probably
> > > have been called htrof.
> >
> > Um, I doubt seriously that I've ever said anything like that.  In
teaching
> > C programmers I find that the start "getting it" when they realize that
> > Forth is a lot _simpler_ than C.  "Backwards" isn't a useful concept...
> > some things are done in a different order, but it's rarely "exactly
> > backwards".  It's just different.
>
> Perhaps I didn't make it clear what part of that you said.  There is
> just one sentance attributed to you.  The part about teaching Forth
> to C programmers and how sometimes when they finally get it they
> say 'Oh, everything is backwards.'  You have certainly said that
> in c.l.f.

Ok, I don't recall saying that and it isn't a phrase that describes
my reality of teaching C programmers.

....
> Sometimes I wonder how selective your memory is.  For instance
> when you claimed that you didn't know who Skip Carter was, or
> when you claimed that you had never heard of Mitch's C-Forth.
> I remember reviewing an old Forth Dimmensions where they listed
> people on the ANS committee and I saw Mitch's name next to
> yours and listed as Vice Chair I believe.  The article was
> right above an add for his C-Forth.  Maybe you never read
> Forth Dimmensions in those days or maybe you just didn't
> remember Mitch and Skip.

I know who Skip Carter is.  I believe you've described him as an
expert on ANS Forth who told ITV many things about the "intent"
of ANS Forth, but at the time he had never attended an ANS Forth
TC meeting, and his representations as to our intent were inaccurate.

I also know Mitch well.  However, his C-Forth was never discussed
in ANS Forth meetings, although Open Firmware was.  As I recall,
you had asserted that ANS Forth was heavily influenced by C-Forth.

> > Moreover, there was never any consideration during the development
> > of ANS Forth of making it "look more like C."  In fact, I can't think
> > of any examples of ANS Forth looking in any way like C.
>
> Yes, I heard you say that before. Along with the comments that you
> had never heard of C-Forth.  I wonder if the Vice Chair ever heard
> of you or Forth Inc. ;-)

Do you have any specific examples of ANS Forth resembling C?

Cheers,
Elizabeth
-- 
==================================================
Elizabeth D. Rather   (US & Canada)   800-55-FORTH
FORTH Inc.                         +1 310-491-3356
5155 W. Rosecrans Ave. #1018  Fax: +1 310-978-9454
Hawthorne, CA 90250
http://www.forth.com

"Forth-based products and Services for real-time
applications since 1973."
==================================================

----- Original Message -----
From: "Jeff Fox" <fox@ultratechnology.com>
Newsgroups: comp.lang.forth
To: <comp.lang.forth@ada-france.org>
Sent: Wednesday, December 10, 2003 22:59
Subject: Re: Religious connotations and accusations


> "Petrus Prawirodidjojo" <petrusp@att.biz> wrote in message
news:<mailman.63.1071054427.31149.comp.lang.forth@ada-france.org>...
> > Again. You make the comment looks like from me.
>
> Again you make comment like idiot. It should be the least
> of your concerns. Learn to count and read, learn how to post
> in usenet too.  More importantly learn them ethics and
> something about Forth.

(Idiot, idiot, hmmm.)

Of course it is important. Someone will think I write that comment. Do you
wish I neglect it?

And it is not the way to cut and paste previous message into current
message. You need to learn to do that. The way you do it confusing you about
who wrote what. You mixed up people.

Forth? Learning ANSForth I become more organized. I use name instead of
number. I quote properly. I know who wrote what.

Read? Ethics? From you? Again you make comment like genius.

Regards,
Petrus-Pet4th.

m-coughlin <m-coughlin@comcast.net> wrote in message news:<3FD7978A.295FED43@comcast.net>...
> Jeff Fox wrote:
>  
> > m-coughlin <m-coughlin@comcast.net> wrote in message news:<3FD6AC84.2226DCDD@comcast.net>...
> > > of great interest to university computer departments. We should
> > > wonder why not. Its not a matter of a big company outspending a
> > > little one on marketing. AT&T spent nothing on marketing Unix
> > > when it was first adapted by universities.
>  
> > If you sell the product for $40,000 per license and give it
> > for free to certain people it is called a $40,000 rebate
> > in today's marketing terms.  Multiply that by the number of
> > copies that came with the rebate. ...
> 
>    You probably didn't use Unix as early as I did.

Yes.  We have had this discussion before.  It was provided for
us at the University when I was there.  When I got out it was
way too expensive for individuals to get and there were no
PCs anyway.  I got my first exposure in 82 while working at
Bank of America.  I was in a group that was determining techincal
standard for the bank at the time.

> At first Unix
> could not be sold. It was an internal system for use only by
> AT&T. There was a requirement worked out with the United States
> federal government that since AT&T was a legal monopoly
> providing telephone service, it could not engage in other
> businesses in competition with businesses that did not have the
> privilege of being a monopoly. This was the time when the
> universities started using Unix. It was given to them as a
> contribution to educational research. After the universities
> started to use Unix and AT&T was broken up into pieces that
> could engage in the computer and software business, then AT&T
> could ask $40,000 or whatever it could get for a license. This
> early history is studied with care by Unix gurus since it is
> important to understand certain historical facts to understand
> why Unix (and hence Linux) is the way it is today. There were

Indeed.

> other computer companies that made grants to universities, for
> example IBM and DEC, but their commercially marketed software
> did not make as good an impression as non-commercial
> unlawful-to-market Unix. If anything Unix and AT&T received the
> benefit of marketing that universities provided since they
> decided C and Unix were very good systems to teach new students.

A quite reasonable decision considering the options.

> A reason AT&T could charge $40,000 per license was because there
> were well educated programmers that knew it was worth it to
> begin with. 

Well I didn't think it was worth the price of several houses
back then to get a copy to examine.  Anyway to run it I would
also have had to purchase a minicomputer which would have also
not been inexpensive.   

You say it was worth it. Did you personally ever shell out
$40,000 or $50,000 to get exposure to it.  If you would have
had to pay that would you?   Are you really saying that you
would have felt it was worth it?

Of course it was being used as the multi-user Operating System
for minicomputers which is what it was.  It wasn't until 82
that it appeared on any microcomputers that I was aware of.
I really doubt that if asked to take out a $40,000 student
load to learn it in college that you would have been so
quick to proclaim that it was worth that.  But who knows
maybe it would have been.  The pool of experts was much
smaller when it was so beastly expensive.  But still I
question your declaration that it was worth it.  I really
doubt that you would have paid that price personally.
It was worth the price when given away, no one can
argue with that, especially to a classroom environment.
 
>      Too bad there isn't a version of Forth that is well suited
> and popular for use by college students.

The word 'popular' is the limiting condition in the above
sentance.  There have been and continue to be Forth systems
used in teaching college students, both in the US and in
various foreign University settings.  And they remain popular
with the students and teachers who use them.  But compared to
the numbers of C/UNIX students popular is expected to mean
both well liked and in wide use.  We know the wide use part
does not fit when compared with C.
  
Best Wishes,
Jeff Fox

Bernd Paysan <bernd.paysan@gmx.de> wrote in message news:<84vja1-gie.ln1@miriam.mikron.de>...
> impression that the worth of the thing sold is the nominal price, and the
> rebate is something you save. Dogbert proposed to make the product's cost a
> million and thirty dollars, and give a million rebate.

I don't know about your taxes in Germany but you might be able to
deduct a fraction of the $1,000,030.00 expense though most people
would not qualify, but you would have to pay considerable taxes
on getting a rebate officially valued at that level.  

> *) It did not run on real hardware, only on toy 16 bit CPUs which didn't
> require a room of their own. It did not provide all the elaborated services
> VMS, MVS, OS/370 and others did. 

That was indeed the way the compting gurus saw it the time, and the
way many still set it.  Those are 'professional grade OS' while Unix
is a toy.

> It had a special, new, crippled and
> unmaintainable language called 'C', which used integers as pointers instead
> of easily guarded arrays. It had severe security problems by having an
> omnipotent 'root' user. It had an inefficient file system where you can't
> allocate cylinders and blocks on your own, so the files would get
> fragmented easily. The file system was often corrupted and needed checking
> and repairing. In other words: in the late 70s, Unix was considered a step
> back by 30 years of OS design (by the zealots of the older OSes ;-).

That is indeed the way the 'experts' saw it at that time.  And as I
say I still hear tha argument forwarded by supercomputing folks.

Best Wishes,
Jeff Fox

nlper@junglemate.com (Tyler) wrote in message news:<65d29696.0312101250.5324035@posting.google.com>...
> > Probably the most important resource for handling complexity is
> > that a large fraction of the limited memory available is not being
> > wasted with code that you are not using and don't need for your
> > complex problem.  Freeing up memory to handle bigger more complex
> > problems is pretty obvious.
> 
> What "limited memory" is that? 

The memory of whatever hardware you have access to.  You have
hit on one of my favorite topics.  I often see people in this
newsgroup saying apologetically that Forth is still valuable
on computers with limited resources. ;-)

Excuse me but I have yet to see or hear of any with unlimited
resources.  I don't expect to see any either.  I think it is
histerically funny that people alude to unlimited resources.
It is a complete fantacy, lunacy, idiocy.

I have access to a PC with 100MB of RAM, and that is refered to
as a joke by supercomputing types facing problems of moderate
complexity.  Hell it is not considered adequate for many
consumer grade toy programs.

Please, please tell us about your access to computers with
'unlimited memory' as we are all excited to hear about it. ;-)

> Unless you're running on extremely old PCs, 

That is a value judgement.  I guess a two or three year old
PC is considered extremely old to a class of consumers.  But
I don't think of it as extremely old myself.  Personally
I have never had access to more than 128MB of RAM on any
PC I have had at home.

> colorForth's typical environment has tens or hundreds of 
> megabytes of free RAM and tens of gigabytes of free disk space. 

Chuck made a lot of comments about going to considerable efforts
to make use of whatever memory was available on a PC in the
colorforth design rather than just throwing away a large 
percentage of the limited memory available as many systems do.

Colorforth typical environment today for commercial use is
512MB although because I am struggling along with only 128MB
I can only run more limited simulations than the folks who
are running 512MB and using every bit of it.  But most stuff
will run with limitations with only 128MB although we will
be upgrading to 2GB or so of RAM to handle more complex
problems.

128MB, 512MB, or 2GB of RAM seem like very large numbers 
compared to older PCs but on the subject of complex applications
doing significant things it is very useful.  I think you have
avoided access to actual information about colorforth.

> The difference in free space between colorForth and a Linux-based 
> Forth is a vanishingly small fraction of those totals.

Well with a 2GB machine that is true for what we are doing today.
But I question if I can run the simulations that I do if I gave
up ten megabytes to OS code on my little 128MB machine.  Sure
I could do more trivial things.

But for the most part we look at using these machines to bootstrap
to more serious computing platforms and to high volume embedded
applications where memory use, cost, and power requirements are
multiplied by the number of units.  In those environments there
are even bigger advantages to not wasting memory as if it were
either free or unlimited.  It is neither.
 
> If you're talking about manipulating very large images or video 
> streams, Linux (and Windows, for that matter) provide virtual 
> memory mechanisms. I don't recall seeing that facility in 
> colorForth.

You know perfectly well what I am talking about.  I can load
Linux and any of several popular VLSI CAD environments on 
my PC and simulate about 1/1000th of the circuitry that I
can on that same machine with more efficient software.
I think people would prefer to hear about the reality of
the software rather than your fantacies or guesses.  I
suggest that you reread what has been said on the subject
of running serious applications on complex problems and
the specifics of how colorforth approaches the problems
that are faced.

You make jokes about how you feel insulted because it sounds
like I have said that writing custom VLSI CAD software that
out performs off-the-shelf software by a large margin is
saying that these things are just for very smart people.
I can understand your resentment when you have only told
us that you knowledge of Forth is from playing with Pygmy
Forth recently.

That is why I asked you what significant applications you have
written in Forth and how you solved things in tackling complex
problems.  Your silence on this issue suggests to me that
you have played with trivial things and resent people who
really do significant applications and solve complex problems.
Am I wrong?  If so please take this opportunity to answer the
question that has been asked of you a couple of times now.

I am beginning to think that you might be a good candidate for
the Jay Walk All Stars since you seem to keep digging yourself
in deeper and deeper and saying more idiotic things as you
try to expose the reasons for your opinions.

In case you have a very short attention span, what computer
do you have access to that has unlimited memory and what
signficant applications have your written in Forth that solve
complex problems?

Best Wishes,
Jeff Fox

Oh, so the action has moved to this thread...

"Petrus Prawirodidjojo" <petrusp@att.biz> wrote in message 

> Subject: Re: Religious connotations and accusations

Please note the subject his is a discussion of the worst
sort of personal accusations and inappropriate use of
relgious attacks on other people.  In great part it is
in response to your personal attacks on other people
which people have been telling you are in very bad taste.

> Has this issue been settled yet? Is it caused by web site that is not
> updated?

No.  This thread is not about blaming someone else for posting
information that you want access to.

This thread is about the personal attacks.
 
> Why did you use to think Jeff Fox was "paranoid"? 

This is what the threat is about.  He said that he saw the
personal attacks that you and others were engaging in and
realized that the people who had been calling me paranoid
were just enganing in personal attacks.

> Is there a reason? 

Obviously.  In the past he saw more claims that I was being
paranoid, or more defensive statements by me and mistakenly
assumed that I was being paranoid.

Then, seeing your and other's behavior in comp.lang.forth
recently realized that it wasn't an issue of paranoia at
all.  Your insulting behavior towards him, me and others
made it clear that it wasn't paranoia.  That is the reason
why 'he used to think' it was only paranoia.

> And do
> you see any resemblance of you to Jeff if it is only slightly? 

Obviously.  He is saying that after being attacked by you he
was more sympathetic with my position. 

You seem unable to see that this thread is about your attacks.

> If he really
> sometimes jumps to conclusions too quickly, can this be a small proof that
> his paranoia is valid? And can we blame someone who draw the right
> conclusion?

? You don't 'blame' people for drawing the right conclusion.  He
is saying that the 'right' conclusion is that I was not being 
paranoid because it is so obvious that you are engaging in personal
attacks.
 
> I am just asking question. I do not answer them. 

The thread is about the inappropriate use of personal attacks.
You don't ask questions.  You don't answer them.  You have made
absurd personal attacks on people trying to inform you about
colorforth.

> Please do not accuse me of insulting people.

But that is the subject of the thread! ;-)

Please don't accuse me of insulting you, you idiot.  After all
I don't mean that as and insult, just a way of helping other
people to realize that they must deal with you as the idiot
that you are.

Best Wishes,
Jeff Fox

Jeff Fox wrote:
> 
> m-coughlin <m-coughlin@comcast.net> wrote in message news:<3FD7978A.295FED43@comcast.net>...

[snip]
 
> > A reason AT&T could charge $40,000 per license was because there
> > were well educated programmers that knew it was worth it to
> > begin with.
> 
> Well I didn't think it was worth the price of several houses
> back then to get a copy to examine.  Anyway to run it I would
> also have had to purchase a minicomputer which would have also
> not been inexpensive.

     That is why it was only used for business who had expensive
computers. AT&T sold Unix for various prices and even kept the
price secret.
 
> You say it was worth it. Did you personally ever shell out
> $40,000 or $50,000 to get exposure to it.  If you would have
> had to pay that would you?   Are you really saying that you
> would have felt it was worth it?

      I didn't say it was worth it. I said there were well
educated programmers who thought it was worth it. If a company
had to spend $250,000 for a computer and its software engineers
could do a faster and better job with Unix than with whatever
came with that computer, then it was worth it. I didn't decide
about corporate budgets. The first Unix system I owned was an
AT&T 3b1 from a ham radio flea market. I used Unix at work long
before that.
 
> Of course it was being used as the multi-user Operating System
> for minicomputers which is what it was.  It wasn't until 82
> that it appeared on any microcomputers that I was aware of.
> I really doubt that if asked to take out a $40,000 student
> load to learn it in college that you would have been so
> quick to proclaim that it was worth that.  But who knows
> maybe it would have been.  The pool of experts was much
> smaller when it was so beastly expensive.  But still I
> question your declaration that it was worth it.  I really
> doubt that you would have paid that price personally.
> It was worth the price when given away, no one can
> argue with that, especially to a classroom environment.

      Poor students didn't own minicomputers with Unix around
1980. Maybe by 1982 some of them did when they started to be
scrapped. They didn't have to own their own computers. They used
the universities' with Unix versions 3 to 7, before version V
(or five). Then Berkeley (BSD) Unix took over, especially when
AT&T asked too much money or wanted unfavorable restrictions of
source code. The licenses and restrictions on Unix were very
complicated and I don't know what they were. 

       Forth systems were a more economical choice than Unix for
minicomputers 20 to 25 years ago. The price of everything about
computers has gone down wildly over the years. Its hard to
remember the time when computers were much too expensive for an
individual to own.

[snip]
--
Michael Coughlin   m-coughlin@comcast.net   Cambridge, MA USA

"Mark Slicker" <maslicke@oakland.edu> wrote in message
news:4c45abad.0312081829.6c941642@posting.google.com...
> Religious connotations and accusations is what I said, not
> religious metaphors. And yes I never seen a forum so
> rampant with them. If this is not true give another member
> of the comp.lang hierarchy which can be seen to sink to the
> level of comp.lang.forth in this particular respect.

Do your own research.  I just went to Google Groups, selected "Advanced
Groups Search", told it look in comp.lang.* and plugged in various words
like "cult," "worship," and "holy" and a few others.  Once you weed out the
non-metaphorical references, you find *plenty* of the very metaphors I'm
talking about.

Examples I quickly found using just the word "cult":  Apparently some fans
of QuickBasic have (or had) a magazine called "QB Cult Magazine."  A
discussion in comp.lang.lisp talks about static verses dynamic typing and
how people who go for static typing are part of a "cult."  A thread in
comp.lang.objective-c talks explicitly about how some fans of the language
are exactly like members of a religious cult.  A thread in comp.lang.java
about the FSF being a cult and using cult-like methods to brainwash others.
We have Robert Martin going after Bertrand Meyer in comp.lang.eiffel about
comments Bertrand made in his book "Object Success" talking about "C
hackers" as being part of an "almost monotheist cult."

My point in listing these is to show what I claim-- that relgious metaphors
(which is no different than your "connotations and accusations") are common.
I personally find them most common in what I call "high paradigm" language
newsgroups like comp.lang.lisp and comp.lang.smalltalk, but you'll find them
*everywhere* any remotely interesting conversation is made.

Religious metaphors in discussions about programming are common for what I
think is an obvious reason.  Much of what programmers do-- good programmers,
anyway-- is about metaphors.

Talk about "traversing a tree" and you aren't going to find many programmers
who will confuse that with climbing an oak.  Talk about "killing a child
process" and you won't find many programmers calling the police because you
are a murderer.  Talk about "garbage collection" and most programmers know
it doesn't involve a big truck that smells bad.  Talk about "master" and
"slave" and only a few programmers will think of the local leather bar.

Endless other metaphors exist:  You probably don't reach for a can of Raid
when you have a "bug" in your code.  And I doubt you'll get much of a
cardiovascular workout "walking a directory" structure.

Programming is all about metaphors.  So I'm not sure why people are
surprised when religious metaphors are used.

> > There is nothing inherently wrong with being called a fundamentalist.
>
> Are you trying to defend what you have said before? There
> is no defense for it, no matter how hard you try to squirm.

Give me the context and I will *gladly* defend *anything* I have written.
And thanks to the wonders of Google, I'll even remind you of the surrounding
context of those statements, since you seem to have a problem in that area.
I'm not going to defend myself against ambiguous claims of things I may have
stated, so please be specific if you want a specific reply.

> > > * The combination of fear, hatred, and dishonesty that have
> > > confronted colorForth (comp.lang.forth). This is seen most
> > > prominently in the recent discussions.
> >
> > I wish you would have been more specific.
>
> It is my observation. If you want names, how about Tyler, Petrus,
> Marcel. I can catalog specific examples but it is a waste of my time,
> we all know the arguments and views that have been expressed,
> and many of these have already been exposed.

Ah, I see you're suffering from the same persecution complex Jeff Fox and a
handful of others have.  You see critical discussions about ColorForth to be
"fear, hatred, and dishonesty."

> >  But regardless, there is a depressing quality about some in
> > this newsgroup who think that any open questions or challenges
> > constitute "fear, hatred, and dishonesty."  In some cases it might
> > be justified, but more often than not, we're simply talking about
> > a persecution complex, possibly driven by an inability to defend
> > one's views.
>
> Stooping to religious accusations -- in a technical forum no
> less! -- is the clearest most astute declaration that one is
> unable to defend ones views.

Failure to recognize that "religious accusations" (or more properly
religious metaphors) are common in not only the industry but in *all* human
endeavor is the problem here.  Once you get out in the world more and see
that religious metaphors are nothing special or unique in comp.lang.forth,
you'll understand just how whiney you are to the rest of us who have been on
the planet a few more years and who have kept our eyes and ears open.

"Brad Eckert" <brad@tinyboot.com> wrote in message
news:4da09e32.0312091735.3f5f6a17@posting.google.com...
> Of course, certain tempests in a teapot can only be
> explained that way. Such as the endian wars or
> segmented/non-segmented battles.

Can anyone give me statistics on how many lives were lost in the battle
between vi and emacs users?  Where is the memorial for the war between those
in comp.lang.forth who argue passionately for files verses blocks?  Frankly,
I'm disgusted that we had people in the streets protesting the war in Iraq,
but where are they in the ongoing bloody battles between VHDL and Verilog?

> Forthers have often been called religious zealots, but
> we're not. We're much more like heretics.

Ouch!  Careful!  You're using a religious metaphor, but in a (mostly)
positive sense.  This could make some heads explode as those who cry foul
over the use of religious metaphors will now have to consider the
application of one with positive connotations.

"jmdrake" <jmdrake_98@yahoo.com> wrote in message
news:e20a4a47.0312090642.57229153@posting.google.com...
> Huh?  You're confusing me now.  After first your definition
> of significant was a program that required "actual user
> interaction".  Now the definition is a program that someone
> has trouble writing?  What does that have to do with
> significance?

There is no single objective standard for "significant."  I have written
that before, at least three times so far.  What I consider to be significant
may not be what others consider to be so.  As a programmer, I have yet to
find a programming environment that doesn't have both pluses and minuses.
And at least in my work, I have found these pluses and minuses when I have
pushed the limits of what the language was designed for.

I suggested a program that required "actual user interaction" as *one* way
to push the limits of ColorForth.  There are other suggestions I have also
provided.

> > ColorForth implemented in ColorForth might be that thing.
>
> Ok, and when this is done will it count in your book if nobody
> reports that ColorForth limited them in doing it?

Yes, it would.  I seriously doubt that will happen, but we'll see when
someone does it, won't we?

----- Original Message -----
From: "Jeff Fox" <fox@ultratechnology.com>
Newsgroups: comp.lang.forth
To: <comp.lang.forth@ada-france.org>
Sent: Thursday, December 11, 2003 11:33
Subject: Re: Religious connotations and accusations


> You seem unable to see that this thread is about your attacks.

This thread is not about me. You are confused about everything.

> Please don't accuse me of insulting you, you idiot.  After all
> I don't mean that as and insult, just a way of helping other
> people to realize that they must deal with you as the idiot
> that you are.

(Idiot, idiot, hmm, and that is not an insult, hmm. I am not used to insult
people, hmm. Idiot is not an insult, hmm. Anyway English is his first
language, hmm...) You are an idiot!

Regards,
Petrus-Pet4th.

m-coughlin <m-coughlin@comcast.net> wrote in message news:<3FD562F0.6B91F998@comcast.net>...
> Let me try a whole different approach. In all these
> discussions, I don't think I have hit the nail squarely on the
> head, and there are a lot of bent nails and loose boards as a
> result. 
> 
>      One of the best descriptions I've seen about the way Chuck
> Moore works was written by the French aviator and author Antoine
> de Saint-Exup�ry  -- "Perfection is achieved not when there is
> nothing more to   add, but rather, when there is nothing left to
> take away".

Yes, I agree with this assessment. There is much of the 
artist's approach in Chuck Moore's work.

>       He must have thought of this because he was an aircraft
> pilot in the early days of flying, seventy to eighty years ago.
> Airplanes were canvas, wood and piano wire. The engines were
> weak. There couldn't be anything on these old planes that wasn't
> absolutely necessary. Its the way Chuck wants his Forth systems.
> Forth is not perfect. But what does it need?

Question: Do you charter an old airplane for your trips, pleased 
that you've avoided the trappings of modern airliners? Or do you 
bypass the allure of a DC-3 for the convenience and low cost of 
a regularly scheduled airline flight?

A few years back I got to fly in the cockpit of a DC-3, so I'm 
not knocking the experience. (It was reminiscent, in some ways, 
of a ride in an old Ford pickup truck -- especially the part 
about landing at night with headlights that incompletely lit 
the way ahead.) But as much fun as it was, I wouldn't want to 
use it if my goal was to get from one side of the US to the 
other. The charm would quickly give way to muscle aches and 
deafness.

So the question comes back to your goals in programming.

Forth is a great language for people who like to tinker 
under the hood. Outside the Forth realm, however, there 
is a much larger group of developers who just want to get 
in the car and go. They don't see the Forth car's lack of 
doors and seat belts as getting rid of unnecessary bloat.
So they find other languages more appealing. And I think 
in the long run this will mean fewer and fewer people 
will know or care about Forth.

BTW, Chuck would apparently disagree with you about Forth 
being perfect. As he said in his Slashdot interview:

"I'm locked in the Forth paradigm. I see it as the ideal 
programming language. If it had a flaw, I'd correct it. 
colorForth uses pre-parsed source to speed and simplify 
compilation. This solves a non-problem, but it's neat and 
worth exploring."

That is essentially my take on colorForth: that it's 
neat but it solves a non-problem.

All of which brings to mind the French poet Guillaume 
Apollinaire, a predecessor of Saint-Exup�ry, who observed 
that a work of art is never completed, just abandoned.

Cheers,
Tyler

fox@ultratechnology.com (Jeff Fox) wrote in message news:<4fbeeb5a.0312102018.2435f09@posting.google.com>...
> nlper@junglemate.com (Tyler) wrote in message news:<65d29696.0312101250.5324035@posting.google.com>...
> > > Probably the most important resource for handling complexity is
> > > that a large fraction of the limited memory available is not being
> > > wasted with code that you are not using and don't need for your
> > > complex problem.  Freeing up memory to handle bigger more complex
> > > problems is pretty obvious.
> > 
> > What "limited memory" is that? 
> 
> The memory of whatever hardware you have access to.  You have
> hit on one of my favorite topics.  I often see people in this
> newsgroup saying apologetically that Forth is still valuable
> on computers with limited resources. ;-)
> 
> Excuse me but I have yet to see or hear of any with unlimited
> resources.

Me neither, which would only be relevant if I had claimed to 
have unlimited resources.

You must have been laughing yourself silly at Chuck in his 
Slashdot interview, when he said "Forth is being used today 
as it always has been. In resource-constrained applications."
Did you verbally smack him around and ask him when he'd 
heard of computers without constrained resources?

All of that is really one of your distraction tactics, however.
You said: "a large fraction of the limited memory available is 
not being wasted with code that you are not using"

I questioned what limited memory you thought was a problem. 
Because if you have a 50 KB colorForth footprint versus a 2 MB 
Linux, it seems unlikely either will be significant for a 512 MB 
RAM space, which as you later admit, is pretty common today. 

Certainly, Linux taking 1/256th of available RAM isn't the 
"large fraction" you originally wrote.

But again, rather than defend one of your hyperbolic statements, 
you attack the questioner.
 
> Colorforth typical environment today for commercial use is
> 512MB although because I am struggling along with only 128MB
> I can only run more limited simulations than the folks who
> are running 512MB and using every bit of it.  But most stuff
> will run with limitations with only 128MB although we will
> be upgrading to 2GB or so of RAM to handle more complex
> problems.

OK, so you have some folks upgrading to 2 GB of RAM for 
large data sets. The 2 MB for a Linux-based Forth is now 
1/1,024th of available RAM -- how is this a "large fraction" 
of limited memory again?

> > If you're talking about manipulating very large images or video 
> > streams, Linux (and Windows, for that matter) provide virtual 
> > memory mechanisms. I don't recall seeing that facility in 
> > colorForth.
> 
> You know perfectly well what I am talking about.

Hmmm, when it suits your purposes, I'm clairvoyant. When I 
don't agree with you I'm an idiot. Right.

> You make jokes about how you feel insulted because it sounds
> like I have said that writing custom VLSI CAD software that
> out performs off-the-shelf software by a large margin is
> saying that these things are just for very smart people.

No, I make fun of you because you predictably claim that 
people who agree with you are very smart, and people who 
disagree with you must be idiots and/or malicious.

I have added to my list of Foxisms your recent habit of 
attacking Petrus for statements clearly made by other 
people. This is worthy of ridicule as well. But I digress.

> I can understand your resentment when you have only told
> us that you knowledge of Forth is from playing with Pygmy
> Forth recently.

I can guess at your meaning here, but it would help if you 
wrote in properly formed English sentences. I think "have 
only told us that you knowledge of Forth" is an attack based 
on your assumption that my use of Pygmy is my first experience 
with Forth. My first Forth experience was in the early 80s.
None of which, frankly, should be relevant to the question 
I asked you.

> That is why I asked you what significant applications you have
> written in Forth and how you solved things in tackling complex
> problems.  Your silence on this issue suggests to me that
> you have played with trivial things and resent people who
> really do significant applications and solve complex problems.
> Am I wrong?

Yes, Jeff, you are wrong. I answered your question back on Dec 
7th. But to elaborate, 20 years ago I used Forth for debugging 
hardware. The few applications I wrote were developed in Z-80 
assembler or C.

I don't resent people for creating significant applications. 
I resent people like you for not reading the messages you're 
responding to, and