Re: The Promise of Forth

Andrew Haley <andrew29@[EMAIL PROTECTED]
> wrote:
> 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?

My own experience with large projects is limited to a minor role in one
project that Elizabeth Rather had a very large role in. I wouldn't say
that my view of that particular example is clearer than that of the
various people who were more central. It's my best guess, based on my
limited experience and what I've heard from others.

My guess that it takes half as long to understand somebody else's code
well enough tp optimally factor it as it would to write it is only a
guess. Depending on the details some code might be far easier to
understand.
 
> > 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?

It's indisputible that we don't have lots of managers who want to try
Forth for large software projects.

We have a few examples of large Forth software projects that succeeded.
The Riyadh airport. OTA. Others? Sendit? These are kind of old. We have
a few examples of large Forth projects that failed. Valdocs. IBMCAD
(which didn't completely fail). Even older. These are not such obviously
great results that lots of managers want to try Forth. I'm clear on that
much.

I say that Forth is OK for big projects, based on the successes. I don't
know how often large Forth projects follow the pattern I describe, but
how many projects are we talking about? If you'd like to disagree I'll
be fascinated to hear about your experience and/or opinions. It might be
safer to say that there isn't enough data to have an opinion, but I'd
rather try things out and see where they lead.

My opinion is that there aren't enough active, accredited and available
Forth programmers at any one time to support more than one large
project. So large Forth projects will be anomalies. Even if more than
one manager wants one, we can't do it except by filling out with lots of
relative newbies.

To the extent that corporate culture increasingly wants large projects
instead of small ones, Forth's place shrinks even more. How can Forth
keep a niche in an biome of large projects? Possibly Forth could fill
the rapid-development niche? Build the quick prototype in Forth while
the other-language team chugs along behind. Possibly Forth could fill
the testbed role. Quickly build the scaffolding to test the production
code. Etc.

I have the idea that a team of 3 Forth programmers will generally be
more credible than a single Forth programmer in that environment. I
don't have anything to support this idea, it just makes sense to me. If
you like you can try it both ways and see what works. Multiple Forth
teams competing for the same slot would look more credible than a single
team. One Forth programmer might be mistaken for a lone kook. One Forth
team gets compared to, say, a Python team to do the same work, and the
Python team would tend to look better other things equal because the
Python language is newer. Three Forth teams might tend to get compared
to each other. Pretty much anything you do, it won't look as radical if
you aren't the only one doing it. Just an idea.