John Doty <jpd@[EMAIL PROTECTED]
> wrote:
> Jonah Thomas wrote:
> > 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.
> >
> >> 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.
> >
> > I asserted that with Forth having 0.1% of the representation, with
> > other things equal we should expect 0.1% of the public shareable
> > code to be in Forth. I haven't seen a claim how much that really is.
> > Is it really 0.1% or 0.01% or what? How would you measure it?
>
> It seems to me you're reversing cause and effect here. For the popular
>
> languages I can think of, the initial very small user base published
> enough code to attract more users, setting up positive feedback that
> eventually made the language popular. It doesn't take *much* published
>
> code to get this going: what's required is the compelling superiority
> of the published code to alternatives in other languages.
So, superior published code that people desperately need in some
specialty niche -- that they need so much that they'll overlook the lack
of much else -- can lead to a foothold in that specialty niche.
But then other languages will move in. The early great code will be
translated into other languages, perhaps with a lot of difficulty. Will
the volume of code written in other languages be translated into Forth?
Probably not. So that's one im****tant advantage that a language needs --
it should be easy to translate foreign code into it. Languages that have
a fundamental similarity to C have an advantage there. If you can
translate more-or-less literally and get something that works, then
there you are. Then you can optimise to use the special features of the
language as much as it seems worthwhile.
Say you have a vitally im****tant 1% of what you need in Python, and 80%
in C. Is it easier to translate the Python into C and do everything in
C? Or is it easier to get the Python to call C routines, and you use the
C routines until you notice which ones cause the most trouble and factor
them into easier C routines with more glue in Python?
I think it might help somewhat to have standard interfaces to call C/C++
routines, and as far as it's easy, to call routines from other languages
too. Maybe one standard interface for recent WinOS and a different one
for Unix/Linux. As it is, commercial Forths and some others let you link
up C object code etc, but when you've done that for one Forth then
you've done it for one Forth. If it was easy to publish a Forth linker
for any particular object code, we could piggy-back more on other
languages. Make it easier to use Forth along with other stuff, compared
to taking the occasional Forth gem and migrate it away from Forth.
I'm not interested in translators directly from C to Forth. I know
there's been some work on it, but how is it better to have bad Forth
that looks just like C, compared to having C?
> > Further, I asserted that the value of public code probably follows a
> > power law where the best of it is very very good and the major part
> > of it is not worth having. If that's true, having 1000 times as much
> > would make a giant difference. Say the best 1000 shared libraries or
> > applications account for 99.9999% of the usage. And Forth is used
> > 1/1000 of the time. Unless Forth tended to result in far superior
> > programs it would be about a 36% chance that none of the top 1000
> > examples would be in Forth. Why would you expect Forth to stand out?
>
> Because of its superior strengths as a language. Except there are
> those superior weaknesses...
Let's say, without having the numbers, that Forth is 10 times as good
once you're good at it. That isn't enough to immediately overcome a
thousand-fold head start. Anyway, Forth has already removed one superior
weakness -- block files. Block files provide a limited tool that gives
wonderful results when the problem fits the solution. Nobody uses them
any more. And most Forths provide locals now, so programmers who don't
like stacks can mostly avoid stack use. What big weaknesses are left?
Postfix notation?
> >> 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.
> >
> > Not so. Forth could be producing mostly nonshared code for
> > historical reasons.
>
> The historical reasons are reflections of its weaknesses. Smart people
>
> don't give up effective techniques without a good reason.
Traditionally Forth was very different from other languages. Hard to
****t code from one to another. Hard to link object code from other
languages into Forth. That's one good reason. There were the standards
poblems. A second good reason. Which good reasons are you looking for?
> > The most popular languages could owe much of their popularity
> > to a bandwagon effect that doesn't stem from any particular virtue
> > of the languages.
>
> I think this is nonsense, a refusal to look at the evidence.
When Java was getting popular, a lot of people told me they were
learning it because they believed there would be a lot of java jobs and
they could get them. That's a bandwagon effect among programmers. The
business pages had lots of stuff about how java was going to make
software cheaper and re-usable. I thought I was seeing a big bandwagon
effect among employers. It didn't falter until published metrics started
coming out that showed java was slow and expensive to produce.
> > If youa're looking for weaknesses in Forth, why not start with
> > weaknesses that have left Forth with 0.1% of the popularity in
> > general? Those would include not having heavy institutional backing
> > (which Java had from Sun at a time when a lot of people were looking
> > for ways to simultaneously work with and move away from MicroSoft).
>
> I don't think institutional backing is worth that much by itself,
> otherwise we'd all be programming in PL/I and Ada. If Sun hadn't done
> a pretty good technical job with Java, I don't think it would have
> made it.
I don't think it's a sole cause either. It can make a big difference. In
the TIOBE survey Java is currently #1 at 20+%. Python (which hasn't had
the institutional sup****t) is #7 at 4.6%. Is Java 4 times as good as
Python? I'd say it's far worse. The institutional sup****t probably made
the difference. But if Java had been utterly inadequate then no amount
of institutional sup****t would have helped.
> > Not having a
> > single official nonproprietary version (which Python and Ruby and
> > Lua have).
>
> gforth? Also note that Python and Ruby and Lua are all examples of
> success without institutional backing, but driven primarily by
> publication.
Do Python and Ruby and Lua each have multiple proprietary competitors?
> > Not having any of the generally-agreed best-practice methods of
> > the last 20 years as standard. (Those include strong typing, OO,
> > transaction-oriented, etc. Forth is however mostly structured.) Etc.
>
> Now you're getting somewhere. Indeed, Forth is trapped in immaturity.
I don't see that enforcing any of those is actually valuable. But
Forthers who agree with me are swimming against the tide. Forth allows
you do use any of these techniques that you like, but it doesn't get
credit for that.
> > If you could find a way to make Forth 100 times as popular as it is
> > now, it would probably also get 100 times as much shared code as a
> > result. Likely more.
>
> Positive feedback. Even a little manifestly superior shared code could
>
> seed a resurgence of Forth.
I tend to doubt that. Put out a superior product that won't be protected
by "look and feel" lawsuits and it's likely to be used as the specs and
test suite for a similar product in some other language. "This is the
result we want. Go produce it."
> >> I cannot understand how you can fail to see the paucity of
> >published > Forth as evidence of a serious problem with Forth.
> >
> > I'd see being #42 with a popularity rating of 0.1% as a serious
> > problem, yes. I wouldn't automatically assume that the problem is
> > with any particular internals of the language.
>
> Your vision of Forth seems way too close to the standard. It keeps you
>
> from seeing the valuable foundational ideas, and how we might exploit
> them while discarding all of the baggage. What's right and wrong about
>
> ColorForth and StrongForth? What was right and wrong about STOIC and
> Magic/L? What's right and wrong with the competition? Discard the
> baggage, find the best ideas, combine them: that's how first rate
> technology is born. I see too much ideology and too little serious
> study of the issues here.
Lead the way! I tend to think that if you figure out the best
combination of tools to make a better Forth, the result will be just
another Forth dialect. So for example 4th looks to me like it's in many
ways a superior product and for many purposes it would get better
results than the Forths I currently use. But I never use it. I'm not
sure why. I think it's mostly that it's too different from the others
and requires that I change my thinking around too much.
A truly superior Forth dialect would have the same problem. You'd have
to teach it to people who didn't already know Forth and wait a
generation for them to spread it to others who didn't already use Forth.
|
