Re: The Promise of Forth

Axel Harvey <xlrv@[EMAIL PROTECTED]
> wrote:
> Jonah Thomas <jethom...@[EMAIL PROTECTED]
> wrote:
> 
> > simpler, programming in Forth is like solving a Rubik's cube, you're
> > handling details the compiler could do better and it costs you in
> > efficiency.
> >
> > [ ... ]
> >
> > But a large Forth team is if anything more likely to write redundant
> > code because they're likely to produce faster. To avoid that it
> > would be necessary for all of them (or all but one) to know what
> > everybody else is doing.
> 
> As for the Rubik's cube analogy I find it odd that
> so many people have the same reaction. Programming
> is not my first occupation, probably not even my
> twelfth, but I have translated C manuals and looked
> at other languages, and I know that Forth is the
> simplest for me.

When you're dealing with two or three items it's no trouble to keep them
on a stack. You won't forget what they do. You won't get them mixed up.
And if you do, it will come out the first time you test. This is the
sort of mistake that's hard to hide from yourself. 

When you have six items it's easy to get the stack confused and it's
easier to have names for things. 

Using Forth, you assume that you'll be smart enough to find a way to use
a few items at a time, and so the things that are complicated for other
people won't be complicated for you. It usually works. Every now and
then somebody posts a counterexample and we argue about it.

> As for the problem of redundancy, I think Forth makes
> it fairly easy to write words that find redundancies
> in files of Forth code. I did that in a small way a
> long time ago, and I'm not Babbage. Large-scale
> project management software for Forth must already
> exist.

It's easy to find direct repeats. You can easily go through a lot of
source code and find all the DUP ROT sequences, even when there's a
variable number of spaces or linefeeds between the DUPs and the ROTs.
But what if the other guy used SWAP NUP instead? You wind up looking for
every combination of stack operators that has the effect ( a b -- b b a
). Or every one that's likely to be there. 

What if two people solve a similar problem in different ways? You
typically can't put "similar problem" into a search engine and have it
find the code that could be factored if some of the code got rewritten.
But that's the result you want.

I'm not saying it's impossible to do automation that would have a good
result, but I'm saying that to fulfill the promise of Forth in a large
project you'd need to have somebody look at all the code and understand
it well enough to see how to simplify it.