Re: The Promise of Forth

Jonah Thomas <jethomas5@[EMAIL PROTECTED]
> wrote:

> Forth is great when it's one great Forth developer doing it all
> himself. Three Forth experts can cooperate well, particularly when
> they have different specialties -- for example one writes device
> drivers and low-level code while a second writes the guts of an
> application and a third does the user interface. 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.  If you figure that it takes half as long to look at
> somebody else's code and see whether there are possible common
> factors with your own as it does to write that same code from
> scratch, a team of 9 Forth programmers might need to each spent 80%
> of their time looking at what the others are doing and only 20% of
> their time doing things themselves.

Do you have any actual data or experience to support this, or is it
just what you've heard from somewhere?

> Forth is OK for big projects. But it appears the experience with
> Forth for big projects involves first getting the specs very very
> clear. Then code rigidly to the specs. And finally use Forth's
> interactive strengths to handle all the problems in a fast last-gasp
> race to the deadline.  This works, but it doesn't get such obviously
> great results that lots of managers want to try Forth for large
> software projects.

Or this?

Andrew.