[colorforth] Forth is Jazz . . .

[Samuel Falvo <falvosa@xxxxxxxxx>]

> > XP and the general Forth philosophy share a LOT together. 
> 
> Yes, but what, and where do they differ and why?

I believe I already gave those differences, and explained why.  To go further
would pretty much require me to teach what XP is, from grass-roots principles. 
I cannot do that nearly as effectively as other industry visionaries have done.
 I suggest heading to your local bookstore and doing some research on it.

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

Then you're reading things I'm not writing.  Where did I say, "We all must use
XP?"  I *DID* say that folks should *consider* it, or give it a try.  But I'm
not forcing anyone to use XP.  I'm not pushing you to adopt it for your own
goals.  I'm merely asking you to consider it, as a viable alternative.

Why am I here?  Is Chuck pushing me to use ColorForth?  No.  I'm genuinely
interested in it for its own merit.  Am I writing a ColorForth?  No.  What I'm
writing is quite definitely a classical Forth environment.  But does that mean
I should ignore ColorForth dogmatically?  No.  FS/Forth is, in fact, quite
*heavily* influenced by ColorForth.  Moreover, I feel that ColorForth could yet
be influenced by some future classical Forth.  We don't know yet.

This is what distinguishes me from most other so-called software "engineers": I
have an active interest in the art, the science, the 'way.'  I look to others
for inspiration (even to those who use other languages; K, C, Python, etc), but
I improvise my own ways of doing things.  I always seek to learn -- ALWAYS. 
When you stop learning, stop considering the input of others, then you fail as
a teacher, a practitioner.  Interestingly, in retrospect, this is precisely
what distinguishes a jazz musician from other kinds of musicians.

A jazz musician is always doing the same: always looking out for new musical
ideas.  Always improvising, always combining concepts in neat ways to make
music that hopefully works and sounds good.  If it doesn't, no biggie -- just
ignore it and move on.  When jazz musicians get together, they don't care about
each other's style -- it's the style of the band as a whole that's important to
them.  In this sense, no jazz musician can legitimately lay claim to a specific
"style" -- it changes with the band's group dynamic.

I like to consider Forth programmers as the jazz musicians of the computer
industry.  We are, if not we *should be*, always looking to outside sources for
new ideas to integrate into our own expressions of software.  We should always
improvise -- we all improvise every time we write a new MACRO or immediate word
for our applications.  That's what extending the language means: heck, I don't
have a language to express my program's problem -- no biggie, I'll make one!! 
A common expression in the jazz industry seems to be, "Shut up and just play." 
The ability to extend Forth arbitrarily gives birth to our equivalent: "Shut up
and just code."  We shouldn't care what other people think of us; we don't NEED
to.  As with a band, when we, as Forth coders, get together, hey, it doesn't
matter if it's ColorForth, MachineForth, ANS Forth, or I don't know, SoundForth
and SmellForth -- doesn't matter.  If you're a Forth coder, you're a Forth
coder, and I, as a Forth coder, appreciate your work in that context.  You
don't need to agree with everything I do, and you may or may not integrate some
ideas I have in your code (or coding practice, in this case).

Chuck Moore is the Thelonious Monk of the Forth community: unrecognized for his
efforts, yet so influential, so original in thought, and so patently elegant
and logical that he can't be ignored.  Just as Monk sometimes walked on stage
with his pants on backwards or wearing weird, funny hats, so Chuck uses bizarre
keyboards, or whatever.  Who cares?!?  It's the music I'm interested in --
clothing and coding style should make no difference to me, or to anyone else
interested in art.

Or maybe he's the Charlie Parker of Forth?  Having deeply inspired Elizabeth
Rather (the Miles Davis of Forth, due to her equally influential, yet
relatively conservative approach to Forth in the presence of the otherwise
be-bop ColorForth?), among many others...

> Management wants managability, not efficiency, otherwise Chuck would be a
> billionaire from selling OKAD to all of the silicon foundries. OKAD is 6

XP's claim to fame is its managability, which is precisely why it's so popular.

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

The problem is that proper up-front design is, in effect and by definition,
leaving hooks.  In my experience, proper up-front design invariably failed: I'd
always have to go back and rip out old code, and replace it with new code that
does something better, or more efficiently, or . . . Something always changes
-- ALWAYS -- which causes me to end up rehashing code.  I tried it again with
FS/Forth for DOS -- and as you might expect, it failed.  I spent countless
hours debugging (through classical Forth practice of Test-Afterwards) when I
could have just written a number of unit tests (the XP practice of Test-First)
and detected errors practically instantly.

XP doesn't try to design around this; rather, it embraces it.

Chuck says to move run-time things into compile-time, compile-time to
edit-time, etc. not because of the edit-compile-crash loop.  ColorForth still
has such a loop, and it's not much different than using PygmyForth or cmForth
from a human perspective.  Rather, he's doing it to *simplify* the
*implementation*.  Sure, the editor is more complex, but the compiler is dead
simple, dictionary lookups occur at break-neck speed, and in some cases (such
as AHA's dictionary management method), even permits "interrupt code to be
compiled in real time," (Chuck to Jeff re: AHA).  But the "edit-compile-crash"
loop is still ever-present.  You cannot escape it.  Unless you're using BASIC
or Smalltalk, I fear you cannot escape this.  AHA certainly comes the closest
I've ever seen to eliminating that loop.  But even AHA has 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. 

The two paragraphs above imply that you do not know what XP really is.  XP has
zero to do what-so-ever with what you produce as the final product.  XP is a
development methodology, just as thoughtful programming is.  YAGNI, one of the
key principles of XP, dictates, "Don't write code you don't need."  In other
words, "NO HOOKS."  <-- This is precisely what Chuck advocates.    XP
advocates, "Factor, factor, factor!"  <-- This is precisely what Chuck
advocates.  I could go on.

Hence, if you follow XP religiously, the end result of both Thoughtful
Programming and XP is *PRECISELY* the same.  Only a few minor differences
exist, such as the existance of a unit test suite that verifies the software in
the same logical sense that a chip can be verified via JTAG, only with much
finer granularity; it's just that these differences makes XP more "managable"
from a suit's perspective, and hence, more systematic and applicable in a
business setting.

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

I think you need to understand XP a bit better before tackling these questions.
 As I cannot explain it with any kind of justice, I would suggest reading, at a
minimum, _XP Installed_ by Chet Atkinson, et. al.  It's a thin book, and it
explains quite effectively what XP is all about from a technical stand point,
with enough management-related material in it to form a bridge to the
management perspective.  There are, of course, other books in the same series
that are dedicated to the management perspective.

A book I'm currently reading, _Planning XP_ (Beck, et. al.), discusses how an
XP project evolves through its release schedule planning and iteration
planning.  It is of direct interest to those who are looking at things from a
more business-management point of view.

I highly recommend both of these books, along with _Test Driven Development_,
the author of which escapes me at the moment.

--
Samuel A. Falvo II


__________________________________
Do you Yahoo!?
SBC Yahoo! DSL - Now only $29.95 per month!
http://sbc.yahoo.com

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