Re: part 21 asserts forth best for small memory systems, would lisp be better in non small mem?

John Doty <jpd@[EMAIL PROTECTED]
> wrote:
> Andrew Haley wrote:
>> John Doty <jpd@[EMAIL PROTECTED]
> wrote:
>> 
>>> Please leave the argument in place. To snip here is evasion.
>> 
>>> My argument is:
>> 
>>> 1. There is little published shareable Forth code, relative to other 
>>> languages. This seems beyond dispute.
>> 
>> Relative to which other languages?  
>> Per user, or per language?
>> 
>>> 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.
>> 
>>> This requires that somehow Forth, unlike other programming
>>> languages, produces shareable code only if code is not to be
>>> published.
>> 
>> No it doesn't.  This conclusion does not follow from the premises.
>> 
>> All that is necessary is for the language mostly to be used in
>> proprietary applications.  COBOL isn't so different.

> COBOL is very different. COBOL is a highly specialized language,
> useless in most applications, including the kinds people
> publish. 

?  Highly specialized?  COBOL?

> But Forthers, including me, claim Forth is radically flexible. So
> what restricts Forth to proprietary applications?

I think that the issue of lingua franca has already been discussed:
for use in most free software projects, a language has to be
understood by many and widely available.  Thus, any minority language
will have a hard time unless its advantages are very great.  C is not
the best language for most of the areas in which it is used.

Forth has greater advantages when it's not tied to a lumbering beast
of an operating system.  This is when Forth really sings.  Also,
Forth's *margin of advantage* in embedded control projects is greater
than when it's just another language running a desktop program on a
general-purpose computer.

Regardless of whether this is true or not, your conclusion does not
follow from the premises.

Andrew.