Re: [colorforth] abort

["t" <loveall@xxxxxxxxx>]

Samuel,

Thank you for the provocative input. You are helping me to better understand
Chuck Moore and his colorForth.

> XP and the general Forth philosophy share a LOT together. 

Yes, but what, and where do they differ and why?

All of my recent input to this list has been with the intent of answering the
above questions.

The context is colorForth vice all other forms of programming. So to define
the context as I see it, these are the following categories:

1) What is colorForth and how does it operate? What are the logical mechanisms
it is comprised of? see:
http://www.users.qwest.net/~loveall/c4index.htm
for links to all the various colorForths.

2) How does Chuck think and apply it? If one does not understand how to use a
tool, it is difficult to efficiently apply it. c.f.:
http://www.users.qwest.net/~loveall/colorForth.htm
for my analysis of how Chuck thinks.

3) How do I use it, and what do I need to change in my methodologies to more
efficiently use Chuck's methodologies?
http://www.users.qwest.net/~loveall/ModProg.htm
has links to both before and after code/commentaries to my understanding of
colorForth

4) How does that application relate to the rest of the software universe? What
needs to be added/changed in order to use colorForth in a _managed_,
production environment? This seems to be the subject now under discussion.

The colorForth mailing list is a _very_ loose grouping of iconoclasts and
anarchists. Urging XP programming on us is synonomous with "Anarchists of the
world, Unite!". And about as effective.

Management wants managability, not efficiency, otherwise Chuck would be a
billionaire from selling OKAD to all of the silicon foundries. OKAD is 6
orders of magnitude more efficient: 1000 times smaller code running on a CPU
with 1000 times fewer transistors designed with OKAD.

Chuck has always advocated proper up-front design to move as much as possible
out of the edit-compile-crash loop as possible. XP says integrate it. 

For individual, closed data acquisition systems, proper design gives the most
efficient code, c.f. the size of color forth kernels in general, and OKAD
specifically.

For open, buggy-input-data, general applications, XP would seem to be a
reasonable solution. But, "How to integrate XP into a confederation of
anarchists?". By the time one devises and verifies acceptable management
processes for using colorForth, it has swollen and eveolved into ANS Forth. 

So what parts of XP can benifit me as an up-front design programmer on a
closed system? From there, how do we build a bridge from colorForth to
management?

Regards,
Terry Loveall

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