Responding to only one small point from your seminal post:
> So, when we see that Forth has been adopted
> somewhere and it went nowhere ... why not? The example of the MUD is
> easy ... while Forth *is* a scripting language, and an excellent
> general purpose toolkit for building a problem specific scripting
> language, they needed to be able to pick up a problem specific
> scripting language that was already close to good enough for their
> problem and refine it ... having Forth available to people who have
> never designed an effective scripting language and expecting it to
> somehow magnetically attract them to setting to work and then
> successfully solving all the problems is like handing someone a
> canvass, set of brushes, and tubes of oil paint and telling them to
> paint a landscape.
The way I see it, somebody who didn't have Forth experience saw that it
fit the need, and then redesigned the language almost from scratch
because they could. It was still the easiest and quickest language to
implement, so it got a significant share before other language designers
caught up.
"It was also beginning
to gain attention because of one im****tant thing: it was backwards
compatible and painless to switch to MUCK from an already preexisting
TinyMUD or TinyMUCK. That probably had more to do with TinyMUCK's
popularity than the programmnig language, the stability of it, or the
popularity of Atlantis."
This pseudoForth spread because TinyMUCK 2 spread and it was attached to
it. And TinyMUCK 2 spread because it was backward-compatible with a lot
of older systems.
A pseudoLisp was the second language, also easy to implement. The
published consensus was that it was easier to use than MUF but it
couldn't do everything. Both languages coexisted on single systems,
operating together.
The third one that got enough interest for me to find it:
"The UberMUD language - U - was low-level, a cross between Forth and C
(Forth semantics, C syntax). There were no predefined data structures,
as everything was implemented directly in U, nothing hard-wired. Objects
were atomic entities to which properties could be attached; that meant
that things like inheritance had to be implemented in U (MUD2's MUDDLE
language, which has the same overall aims as U, has inheritance built in
automatically: this helps with function matching). U's only
predetermined factor was the order in which programming-language objects
were searched to find code to execute: verb first, noun second, player
third.
Despite all the ideas that were included in UberMUD, some simple things
were left out (gender pronoun substitution being the most glaring
omission). It had the capacity to implement them, but no-one put them
in. The mistake made was to believe that by having a flexible
implementation language that allows pretty much anything to be phrased
in it, everything necessary actually would be phrased in it. Definition
languages have to be either specific (ie. with much assumed, but able to
guide a new programmer in database design) or general (ie. assuming
nothing except that the programmer knows what is to be programmed)."
My guess is that they wanted something like C, and they wanted it to be
palatable to people who only knew MUF. But it was hard enough to switch
from MUF that people didn't want to, and it wasn't enough like C. Also
it was implemented in precisely one MUD, and to spread more people would
have had to host a new system they didn't understand well to start with.
Essentially all of the later languages were based on OO C. If you were a
CS major with time on your hands and you wanted to build an interactive
language for MUDs, what would it be? Obviously it should be
ObjectOriented, why would you put up with something that wasn't? And it
should be like C because that's what everybody who is anybody is
familiar with. You don't survey a bunch of nonprogrammers who happen to
be scripting MUDs. They'll tend to like whatever they're already using
because they don't know any better.
So, Forth tends to get an in when it's first-to-market. How many of the
niches that Forth has had a fighting chance have been that way? Most of
them? One exception is OF, where MicroSoft had a Plug and Play advantage
and various competitors saw a chance to get leverage -- they could have
a cross-OS, cross-processor approach to get plug-ins that would run on
everything but PCs. But for one reason or another the coalition broke
down. Did they start out with the assumption they'd get economy of scale
with multiple vendors, and each one that dropped out made it less
attractive for the others? Were there problems with x86 systems that
made it not work for them? Was there some inflexibility in OF that made
vendors choose proprietary replacements? Did the components vendors fail
to go along and so there weren't enough third-party participants to keep
the momentum? I don't know why OF was abandoned.
Let's say for the moment that Forth's big advantage is time-to-market.
And after a Forth product succeeds, or even at the very start before a
language has been selected for the project, the competition points out:
The majority of software costs are for maintenance over the life cycle,
and you don't want to have to rewrite do you, don't you want something
that'e easy to maintain with fully re-usable code? And Forth gets
replaced with something that has the promise of easy code re-use and
painless maintenance.
Maybe the niche that Forth is currently losing is prototyping. The
marketing could go something like "Plan to throw one away. Make your
first effort in Forth, get it done fast, try out alternatives, get your
specs clear. After you have the details straight then rewrite the
application in something that's easy to maintain." But who can market
for that niche? Individual programmers can't expect to make the sales
pitch. They can hope to get Forth jobs after there are Forth jobs for
them to get. It's only Forth shops that can hope to make the sales
pitches. And if we have two major Forth shops and they get enough
business to sup****t them, why should they look for more?
For Forth to expand in that niche we'd need a decent-size pool of
extremely-good Forth programmers that our Forth shops could call on to
do the work. The Forth shops could get projects that they'd farm out to
reliable teams. When there were enough reliable programmers and enough
business then we could sup****t a third Forth shop doing the same -- and
that would make all three more credible outside the current customer
base. Build from there. But I wouldn't expect that approach to increase
more than say 20% per year under the best conditions. I wouldn't know
how to continue year by year to increase the number of Forth programmers
who're competent at quick development projects by more than 20% per
year, even if the demand was there. So to go from 0.1% to 10% that way
would take about 25 years. A lot of things can happen in that length of
time.
|
