John Doty <jpd@[EMAIL PROTECTED]
> wrote:
> Oh yes? What about all of the proprietary software in other languages?
>
> You personally choose Forth. Apparently most who write such software
> don't.
>
> We use Forth for those areas which differentiate our
> > products, the mass appeal of the language isn't in any way a
> > consideration, neither is reusing other's code. It's only for those
> > aspects that are non-differentiating (and therefore generic) that
> > popularity comes into play and we go with the flow of the m*****.
>
> What weakness in Forth restricts it to these situations?
http://www.tiobe.com/index.php/content/paperinfo/tpci/index.html
TIOBE may not be the best judge of programming language popularity, but
let's go with it for the moment.
They put Forth as #42 this month, with about 0.1% of the total. I think
the last time I looked Forth was #37 with about 0.12% of the total. When
you get that low this is statistical noise.
COBOL is now at #15, up from #18 this time last year, with 0.6%. Pascal
is #16, up from #21 last year, with 0.55%. Would you argue that COBOL
and Pascal are somehow 5 times as good as Forth? I wouldn't.
So then, Java is at 20+%, and C is at 15+%. To the extent this actually
measures what we're interested in (which remember I've assumed without
evidence), there's around 200 times as much work being done in Java as
in Forth, and around 150 times as much in C. Not considering the past
when both of them were bigger than they are now and generated a whole
lot of legacy code.
So, if it was a competition to see who could build the biggest pyramid,
would you expect the team which has 150 times as many members to build
faster? If the goal was to see how many pyramids you could build, which
team would you expect to build the most?
If somebody does something truly new and innovative, which group would
you expect it from, the one that was 200 times as big or the little
group? If you figure that 99.9% of the innovations are first done with
something other than Forth, wouldn't it make sense that Forth users
would spend most of their time playing catch-up? And so would most
everybody else, but we wouldn't see that. We'd see a thousand
innovations coming in from elsewhere for each innovation that came from
Forth. Every Forth-size fragment of the C community or the Java
community would see the same thing, but we wouldn't see that, we'd see C
and Java developing 35% of the innovations.
If each Forth programmer was 10 times as effective as programmers in
every other language, then it might seem like we weren't outnumbered
1000:1. It would only seem like 100:1. To the extent that there are
economies of scale, synergy within a language, etc we'd be way behind
even with much better individual productivity. But then, usually Forth
programmers don't claim they're 10 times as effective, but only 4 times
as effective as C. C is basicly a ****table assembler -- it shouldn't
take much to be more effective than that. Java is crippled by objects,
to the point that Java programmers are often less productive than C
programmers. Productivity claims for Forth are not excessive at all. To
be better than Python (#7), Ruby (#10), Lisp/Scheme (#18) or Lua (#20)
surely we should be at least 20 times as productive as C programmers.
You ask why Forth doesn't have more users. I'd suggest the Forth83
standard had a lot to do with it. It's possible that standards don't
affect language popularity. But if they do have an effect, Forth83 did
almost everything wrong. It was incompatible with Forth79. It was a
16-bit implementation standard. Etc. I don't blame the people who did
it. They didn't understand the problems. I expect Forth83 may have
served as a horrible example to teach other standards efforts what not
to do. Forth got split into two factions, and one of them didn't survive
-- I have the impression that the big majority of diehard Forth79 users
didn't switch to Forth83 but left the Forth community. It's almost
surprising that Forth is doing as well as it is after that. Forth94 did
damage control but was too late to help much. And even then the Forth
community was bitter about it, and we almost lost a lot more Forth
programmers who wanted nothing to do with Forth94 but who saw no future
opposing it. Maybe the standards weren't im****tant, but I tend to think
they were.
Now that Forth users are relatively few, it doesn't make sense to point
at things like large projects and published code for anything more than
to demonstrate that there aren't very many Forth users. If we're 0.1% of
programmers, it would be surprising if we had anywhere near 0.1% of the
large projects or 0.1% of the published code.
If you want Forth to thrive, you can assume there's something wrong with
Forth that keeps it from thriving and look for the fatal flaw and try to
remove it. You'll probably be opposed by essentially every active Forth
user who will naturally tend to disagree with you about what the fatal
flaw is. Alternatively, you can try to get people to use Forth and
notice what stops them. You've done some of that and you've given us
some informed opinions about that. the byte memory commands, the
complexities of interpreting/compiling as two different things, etc.
|
