John Doty <jpd@[EMAIL PROTECTED]
> wrote:
> My argument is:
>
> 1. There is little published shareable Forth code, relative to other
> languages. This seems beyond dispute.
I think that's right.
> 2. You and others asserted that this is not because Forth code is not
> shareable, but because shareable code is proprietary, and that there
> is plenty of such code.
Here's my thought. If Forth was precisely as sharable as Java or C, then
other things equal I'd expect to find 0.1% as much shared Forth code as
shared C code, and about 0.065% as much shared Forth code as shared Java
code.
But the usability of shared code probably follows a power law. There are
a few great applications that lots of people use. A larger number of
adequate applications that can be made to work. And a lot of junk. If
there isn't much code there, then the natural expectation would be that
there would be no great applications, a very few adequate applications
that can be adapted in reasonable time, and a moderate amount of junk.
Isn't that what we see in Forth? If in C 1% of the public code provides
99% of the usability, how much usable shared code would you expect
starting from 0.1% as much code total?
Now, lots and lots of people learn C and other mainstream languages in
school. And each of them would like to get a leg up in the programming
market. Some of them believe that they can get that by writing free
programs that can go on their resumes and give them a reputation, that
will make them more hirable. Does it work? i don't know, but if they
believe it some of them will write free stuff. Is there anybody who
believe he can spend 100 or so hours writing free Forth code that will
land him a job using Forth? Maybe. But certainly not enough of them to
provide much code. They don't learn Forth in school and they don't hear
that there's a market for Forth programmers. Why would they do it?
Some proprietary code gets released after a few years. If it's going to
make money, it will probably all be within the first few years anyway.
You might make money on upgraded software. You might get out of that
particular market niche and sell something else. You might figure your
competitor has a cash cow and you don't, and releasing your code will
hurt him and not hurt you. For one reason or another, sometimes
companies decide to release their obsolete software. If 0.1% of that
software is written in Forth, then other things equal we might get a
tiny fraction of shared Forth code released that way. But I think
they're less likely to release Forth code. They're more likely to think
that nobody wants it. And if it's written for an obsolete commercial
Forth compiler, they don't get to release the compiler. (That reminds
me, I've wondered whether FORTH, Inc might someday release PolyForth.
under GPL or something else. There might be techniques there which a lot
of Forthers feel honor-bound not to discuss publicly because they belong
to FORTH, Inc. Those might not be so im****tant these days for commercial
Forths to keep their competitive edge, and might be useful as publicly
known Forth methods. Maybe it wouldn't work out. But maybe FORTH, Inc
would have more to gain than to lose by it, I don't know.)
If it's true that good Forth code tends to be much more terse than
equivalent code in other languages, it might seem less im****tant to
release it. Say you do something in 1000 lines of C code, with 2000
lines of do***entation. That looks like something significant. If you
can get the same results with 30 lines of Forth code, it doesn't look as
im****tant. And if it gets 150 lines of do***entation when it needs 1000
lines....
Most of this isn't about Forth as a language. Fewer users means less
code. No students means no student code. No jobs for people who release
impressive free projects means less code. If the ratio of required code:
do***entation is less, then we'll naturally tend to get less
adequately-do***ented code. Because if you're X times as productive at
getting the code working -- the fun part -- but you're no more
productive at writing do***entation -- the boring part -- then....
> This requires that somehow Forth, unlike other programming languages,
> produces shareable code only if code is not to be published. If this
> is true, it indicates weaknesses in Forth. Weaknesses, if correctly
> identified, may often be repaired.
That doesn't follow at all.
When we care about sharable code, we really only care about the best of
it. If there are 3 gigabytes of unusable junk libraries written in C and
only 1 megabyte of unusable junk written in Forth, you wouldn't say that
we're falling behind and we need to produce more junk libraries to keep
up. It's the rare extra-good stuff that matters.
So, by comparison, the USA has about 300 million people while Iceland
has about 300 thousand people. Would you go to iceland and tell them
they're weak and flabby because their best Olympic weight lifter isn't
nearly as good as the best US weight lifter? Would you tell them that if
they weren't so weak and flabby they'd be in the top ranks in all the
olympic s****ts?
In 1956 Iceland won a silver medal for the triple jump in athletics. and
in 1984 they got a bronze medal in middle-heavyweight judo. But nothing
since. Oh no! Iceland is losing out in their former niches!
But then, extending the metaphor past all reason, you wouldn't usually
suggest sending a software project to iceland either. There aren't that
many icelandic programmers, and what's the special advantage? Is it that
they consistently get results on time and under budget? That might get
some business, but there's the problem that whenever too many customers
figure out the advantage suddenly there won't be enough Icelandic
programmers to go around. It's limited. Better to send the work to india
where there are lots and lots of people to do the work and the exchange
rate makes them cheap. Cheap is one reason to move a project to the
other side of the world.
Well, if that's what works, we might get a big win for Forth if somebody
could set up a 3-week Forth course that could teach Forth to 1000 high
school graduates at a time, and then test them, and make the verifiable
claim that 1/3 of them would then be more productive than C programmers
with 2 years of experience, and that they'd gladly work for $15/hour. If
software companies etc had a guaranteed supply of adequate Forth
programmers at $15/hour, that might be a big win for Forth though not
for current Forth programmers.
You are repetitively arguing that there is something wrong with Forth
that results in Forth's relative obscurity -- #42. But the inevitable
result of your arguments is that people will disagree with you. And if
you get somebody who agrees, what then? Will they suggest actions the
two of you can do to turn Forth into what you want?
I get interested in ways to simplify the Forth engine further, but
that's a hobbyist interest. Most Forthers don't spend much effort
maintaining Forth systems -- and if we get more Forth programmers even
fewer of them will do that. So reducing the effort required to maintain
a Forth system is not very im****tant. Far more im****tant is finding
methods that make it easier to get great results.
If somebody had a method that did that, and he demonstrated it every
time a programming challenge came up, maybe after awhile people would
notice. I can think of some candidates. Michael Gassenenko came up with
sophisticated control flows by manipulating the return stack. He had
some examples where his approaches worked very very well. But he didn't
keep publi****ng examples, and people mostly ignored it. And then
somebody posted some code that used OO methods to solve some problems.
Things that other people needed to actually code, he could just point to
existing object methods and the work was all done. But he only gave a
few examples too.
Very often people have posted code whose purpose is to get the result on
every standard system. But it would be just as interesting to see code
that's particularly good on one system -- which demonstrates how useful
that particular nonstandard technique can be.
The more LSE64 code you provide that shows you're more effective in
LSE64 than others are in Forth, the more people will pay attention to
your methods. That's got to work better than arguing about whether
there's something wrong with Forth.
|
