Jonah Thomas <jethomas5@[EMAIL PROTECTED]
> wrote:
> 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 to 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.
OK, but I'm not at all sure how much of this is dependent on a
particular programming language. Most of these issues are to do with
software development management, and happen with all programming
languages.
>> > 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.
I guess I don't have much data either, so I'm certainly not going to
push a definite opinion, pro or anti, about the suitability of Forth
as a programming language for large projects.
For what it's worth, I'm not convinced that the choice of programming
language has the biggest impact: when things go awry in a programming
project it's usually due to higher-level problems such as the lack of
processes for testing and code review, or just bad design. When a
well-managed team discovers that the lack of some abstraction layer or
well-defined interface, they refactor, redesign, and create that new
set of interfaces. And they do that in C, Forth, COBOL, whatever. Of
course, if the language or its implementation makes this very hard, or
if your programmers are no good, you're doomed.
Andrew.
|
