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

"John Doty" <jpd@[EMAIL PROTECTED]
> wrote in message 
news:8fOdnRvB-N03IUjanZ2dnUVZ_jSdnZ2d@[EMAIL PROTECTED]
> Guy Macon wrote:
>> So now *THREE* people have told you:
>
> And if it was one hundred, they'd still all be wrong.
>
>>
>>  "The effects you cite are not *necessarily* the result of the cause to

>> which you attribute them." -ER
>>
>>  "This conclusion does not follow from the premises." -AH
>>
>>  "you simply assume without evidence that A leads to B, never ever 
>> examining whether that assumption is waranted."-GM
>>
>> ....and still you refuse to even *try* to establish whether or not the 
>> effects you keep talking about are the result of your alleged cause.
>
>
>>
>> I am really curious; why do you believe something when you cannot for
the 
>> life of you come up with any reason to believe
>> that it is true?
>
> Because when there is no alternative that fits the evidence, the
existing 
> hypothesis is the only thing one can reasonably believe.
>

John, I have been progtamming in forth since the early 80's, at multiple 
companies,
and have never published any code, and neither have any of my colleagues, 
because
it all belonged to my employers and they did not want their competitors to

see it.

In addition to that, it was often very application specific (e.g. some of
it 
was only useful
to someone developing a PBX or intercom system) and that affected our
choice 
of
names. However, it was usually very easy to re-use the code at the source 
level because
we had (usually) a fairly good di***entation and cross reference system.
The 
only issue
we noticed was that often the higher level routines needed to be renamed
to 
better
describe its function in the system.

Almost all of these companies used commercial forths (polyForth, LMI, 
MMSForth, VFX,
SwiftForth) although gForth also appeared, and most of the more generic 
routines (i.e. those
that didn't need renaming between systems) were part of the package (and 
therefore not only
not publishable, but also proprietary.

Another key reason for not publi****ng was because we all felt that forth
was 
one of our key
advantages, and we didn't want to lose that significant edge. One of the 
companies had
specifically included the language in the Non-Disclosure and revealing it 
was listed as sufficient
cause for immediate termination, followed by a significant lawsuit.

In my experience, a significant amount of the published code was initially

from academic or
research environments (with the possible exception of the FSF, although
the 
link to MIT, etc.
is there too) or is used as a way to demonstrate a level of expertise 
sufficient to be considered
for consulting or employent. For both these areas, working in the most 
common languages is a
definite positive, so there is little incentive to explore. Those who want

to explore tend to write
their own languages (another significant group).

My hypothesis is that the reason that there is so little published Forth 
relative to other languages,
is that the reasons for publi****ng code don't apply to the majority of 
people using Forth, or to the
(possibly niche) applications developed in Forth. On the contrary, most of

them feel that there is a
significant benefit in not publicising the language.

Stan Katz