People who don't like Forth say, why bother with a data stack at all?
Declare variables, declare locals, let the compiler do the work of
figuring out where everything is. Don't bother your little brain about
it. And Forthers say that with a data stack we get a simpler compiler
and we get simpler subroutine calling. We're encouraged to factor
deeper, and that helps us write simpler code. And they say it isn't
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.
The Forth promise is that the extra thinking will pay off. That the
normal exponential crufty buildup will be slowed. That the simplicities
will work together so that you'll wind up with less total work. Fewer
places for bugs to hide means faster debugging and the possibility for
actual correct code. The less that extra complexity leaves you making
work for yourself, the more time you have available to think and
simplify and the more actual results you can produce.
It's true for some Forth programmers. When people try Forth and decide
it wouldn't work for them, they may be right. The Forth Promise can't
pay off except for programmers who think of ways to keep it simple.
And if you're an employer, do you want to pay people to think or do you
want to pay them to crank out solutions? One way you get lots of
solutions. Bang. Bang. Bang. Bang. Bang. Bang. Six problems solved
quickly. If your employee spends more time to solve 4 problems and he
changed the problems around to suit himself, how do you decide whether
the time is worth it? It's obviously stupid to measure productivity by
lines of code, but what do you use instead? There are people who try to
measure functionality with function points etc, but I predict that
automated methods to do that will fail, and that to do it correctly
takes competent programmers and requires more time than it does to
produce the code in the first place. For employers it's a leap of faith
to believe the Forth promise. They might believe it from their own
previous experience or from anecdotal evidence. They tend not to believe
it, and Forth has a tiny market share -- mostly limited to customers who
desperately need it to be true.
Forth's proven successes have been in resource-constrained systems,
where Forth has gotten results smaller than assembly or C. This is
partly because C "optimization" has focused more on speed than size.
Forth has also done well for things like debugging hardware interfaces.
Very interactive, easy to modify it for low-level details, etc.
The promise of Forth should be manifest more in larger projects. The
bigger the project, the more opportunity for simplification. A project
that's 10,000 lines of code in some other language will have more
functional redundancy than one that's only 1,000 lines, and one that's
100,000 lines should have even more opportunities.
But in practice there are limits. 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.
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.
Besides everything else there aren't a lot of established candidates for
Forth experts on large projects. I'm going to pull numbers out of the
air, not having good estimates available. Let's suppose that there are
50,000 electical engineers who sometimes use Forth for debugging
hardware etc. And there are, say, 8,000 scientists and engineers etc who
sometimes use Forth or LSE etc for some of their work. And say 1,000
engineers (grading into hobbyists) who use Forth for commercial software
projects that they don't talk about in public. And at any given time
there might be 50 to 100 expert Forth programmers who can drop what
they're doing and spend a year or two on a new large Forth software
project. You simply can't get a lot of large Forth projects starting the
same year, unless you accept some Forthers who don't have very good
credentials. If we got every software manager in the country clamoring
to use Forth for his next project we couldn't possibly fill the need for
programmers. Elizabeth Rather might perhaps produce 50 new Forth
programmers a week. She might find five people she'd trust who could
train 50 programmers a week. In 6 months that approach could produce,
say, 10,000 Forth newbies who'd taken the 1-week course and were basicly
competent. If they were to join 300 or so projects with 30 or so
programmers each, where would we get 300 Forth project managers?
Forth's advantages ought to show up best with projects that can be done
by 1 to 3 Forth programmers. I have the impression that large projects
need to be larger than this because a software manager needs to manage
10 to 30 or more programmers to get the institutional respect an
administrator needs. It isn't that Forth is no good for large projects.
The problem is that Forth's strengths come out when programmers strive
for radical simplicity, and when too many are working in parallel it's
too hard for them to coordinate that. So Forth's promise is diluted and
the advantage is less.
How could Forth break into the large-project market? Could Forth be used
for rapid prototyping? If you plan to throw away the prototype, writing
it in Forth would help to firm up resolve. I read that some successful
large military projects used to have a parallel smaller project. The
secondary project would have 10% of the people and 10% of the funding,
and they would do their best to get results quickly. Could a few
software project managers be persuaded to try that? A fast lean team
might run into some of the pitfalls early and alert the main team to the
coming problems. And they might get results. There could be far more
than 10 times as many 3-person Forth teams available as 30-person Forth
teams. If they get the contract, they stand to win far more than to lose
-- nobody would expect too much from them since they'd be a 3-man team
prototyping for a 30-man team. But if the big team fails when they
succeed then that's a big win.
So, if you'd consider doing this sort of work, you might find two others
you'd work well with. Then find some nascent projects and make your
pitch. I have a thought that a manager who hears from three competing
Forth teams may be more likely to go with one of them than a manager who
only hears from one. It all seems more plausible when there are multiple
teams competing for him, like they're all following the same viable
business model and they think he's a plausible customer.
|
