[ColorForth] On desgin and colorforth

["t" <loveall@xxxxxxxxx>]

Thanks, Chuck, for Forth in general and specifically colorForth. You put the
'L' in elegant.

Chuck Moore:
"You have to really understand the problem. You have to go in there and read it
all, and then think about it, and say what they are really trying to do is this
and then do that. Which is much much simpler than what they were doing."

-----
My response:
There are two parts to completely understanding a problem:
a) understanding the problem that one is confronted with,
b) understanding the tools available to solve the problem.
Merging the two provides for the most optimum solution.

The more fundamental the symbol set is for the tools, the simpler the
expression of the problem can become. You start with a most simple set and
build the most elegant logic (chain) structures that express the problem.

One cannot properly, completely understand a tool without having (re)built it
ones self.

If one builds a tool set specifically for ones self, that still leaves the
problem of communicating said solutions to other humans. One can either build
ones tools to include communication with other humans or one must provide a
bridge for communication, after the fact.

-----

Chuck Moore wrote x86 colorForth to implement OKAD on a PC. His design criteria
required the output be in a format usable by a silicon foundry. For compact,
elegant code he used Huffman encoding for text. It would be logical to assume
he also wrote an ASCII translator for production of pin lists.

When most of the time spent on a project goes into the design phase, code entry
requires very little overhead. Basically, a minimal editor. Debugging amounts
to invoking a definition with the appropriate input parameters and verifying
correct output. Hence the 'crude' user interface.

Translation: colorForth is a specific solution to a specific set of design
criteria for a specific person with a specific set of work habits. Easy long
distance communication during program development was not part of his design
criteria. Had it been, networking, or something to facilitate long distance
communication, would have been in the colorForth release.

Other people Ohhed and Ahhed over it, so he made it available as public domain
to do with as they desired. He went back to his designs and is happily pursuing
them.

What problem are we trying to solve? Is colorForth, as delivered, a 'most
simple set' for the problem? Is Huffman encoding a bug or a feature in the
context of of attempting to provide easy long distance communication during
program development? What is a 'most simple set' that does support long
distance communications during program development?

I worked on getting colorForth to run on my hardware so that I could verify my
understanding of what Chuck was talking about, _after_ I had written my own
color forth. The end result is that I have no problems, at this time, that
require color forth as part of the solution. But the principles I learned from
Chuck and colorForth are being applied daily. I write color forth style
programs in C and assembler.

My efforts on this email list are to help others get to where they, too, can
evaluate colorForth and understand it. Only then can informed decisions be made
as to whether colorForth, as it stands, is a general programming tool fit for
collaborative software development or whether it needs a new 'most simple set'.

For my detailed answer to these questions see
http://www.users.qwest.net/~loveall/binary/4thish3.zip
and
http://www.users.qwest.net/~loveall/binary/concluse.txt
for various color forth implementations and conclusions.

Regards,
Terry Loveall
------------------------

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