Forth add-on libraries (was: Questions regarding Forth's success) 
Author Message
 Forth add-on libraries (was: Questions regarding Forth's success)

Quote:



>+A few years ago, Martin Tracy invested months of his time
>+writing several different standard libraries, which were sold
>+through FIG at rock-bottom prices.  These libraries were
>+professionally coded and documented and in every way they were
>+far above the quality of the average PD Forth code.  And, they
>+sank without a trace, teaching us all a valuable lesson.

>I am not familiar with those libraries' details.

>How many different Forth systems did they work with, and on how
>many different hardware platforms?

>My guess is that there wasn't a widely available common Forth
>platform for him to base his libraries upon.  But I think that may
>not be the lesson you are hinting at.

Martin preempted compatibility problems by writing "preludes" to
his libraries for many of the then-popular Forth systems. These  
preludes, which were each only a few screens in length, were basically
compatibility suites which aliased existing definitions or overlaid
other definitions to bring all of the systems up to a common base
state.

I can't remember exactly which systems his libraries worked with, but
I'm pretty sure the list included at least polyForth, LMI Forth,
F83, F-PC, and MacForth. There might be others.  Perhaps if Martin
is out there somewhere reading this thread he will provide further
details.



Sun, 30 Jul 1995 17:24:04 GMT  
 Forth add-on libraries (was: Questions regarding Forth's success)


+The main reason is that you can't write such libraries  based
+ONLY on ANS FORTH required and extension word sets -- you're
+ALWAYS going to have hardware and environmental dependencies.
+These dependencies will be far more important than (say) the
+differences between ANS FORTH and FORTH-83.

I think having the ANS Forth base will only help.  The X windowing
system seems to be able to overcome hardware and environmental
difficulties while still allowing programmers to write portable
code.  Granted it also sucks down massive system resources.  (I don't
the internals of the X code, so I can't say if its hoggish resource
usage is merely poor implementation, or if it is unavoidable.)

I do agree, however, that ANS Forth is not sufficient, but I think it
is necessary.

+A secondary reason is that even if such libraries exist, most
+FORTH programmers would rather reinvent their own "improved"
+interfaces than suffer the indignity of incorporating someone
+else's code into their applications.

That does seem to be a common stereotype of the rugged independent
I_can_do_it_better_and_faster Forth programmer.  I think there
is another reason though (see below).

+A few years ago, Martin Tracy invested months of his time
+writing several different standard libraries, which were sold
+through FIG at rock-bottom prices.  These libraries were
+professionally coded and documented and in every way they were
+far above the quality of the average PD Forth code.  And, they
+sank without a trace, teaching us all a valuable lesson.

I am not familiar with those libraries' details.

How many different Forth systems did they work with, and on how
many different hardware platforms?

My guess is that there wasn't a widely available common Forth
platform for him to base his libraries upon.  But I think that may
not be the lesson you are hinting at.

-Doug
---



Sun, 30 Jul 1995 09:38:01 GMT  
 Forth add-on libraries (was: Questions regarding Forth's success)


Quote:
(Doug Philips) writes:

|> I do agree, however, that ANS Forth is not sufficient, but I think it
|> is necessary.

ANS Forth's merit is standardizing some of the libraries. I don't
think it will do much for other libraries, for the following reasons:
The most interesting libraries are those that cannot be written in
ANSI Forth. Not because of the limited scope of the standard, but
because of the concept of a commercial library: I can usually write
the code I need in the same time that I need to learn the library and
to write code that crosses the gap between the library and my needs.
So, the main advantage of the library is, when the library supports
several systems that are incompatible at the do-it-yourself level.

A library that uses only portable features can only be successful if
a) most users use it constantly or
b) it has a high ratio of implementation effort to learning effort.

- anton
--
M. Anton Ertl                    Some things have to be seen to be believed



Mon, 31 Jul 1995 16:49:04 GMT  
 Forth add-on libraries (was: Questions regarding Forth's success)


+Martin preempted compatibility problems by writing "preludes" to
+his libraries for many of the then-popular Forth systems. These  
+preludes, which were each only a few screens in length, were basically
+compatibility suites which aliased existing definitions or overlaid
+other definitions to bring all of the systems up to a common base
+state.

Ok, let's assume that his code would run on most of the existing
platforms, so that compatibility wasn't a limiting issue.  Perhaps
there were other problems.  I'm not at all convinced that FIG has
wide enough visibility to have the kind of success you implied it
should have had.  Perhaps the lesson you were refering to was "Don't
use FIG (and nothing else?) to promote libraries"?  Or perhaps FIG
had a wide enough audience, but it was just the wrong audience?  Or
perhaps the timing was wrong for some reason(s) or other?  Maybe only
a few people bought the stuff from FIG, but they then shared it and
passed it on?  Maybe support was a bigger issue than anyone realized?
... etc. etc. etc.

I can see many reasons for why FIG didn't sell a lot of copies of
those disks.  I don't have any data that supports picking any one (or
group) of reasons above the others as "the real reasons."  Nor any clear
indication of just what lessons we should learn from that experience.

-Doug
---



Wed, 02 Aug 1995 06:50:50 GMT  
 
 [ 4 post ] 

 Relevant Pages 

1. Questions regarding Forth's success

2. Questions regarding Forth's success (was: Recent FORTHs' guts)

3. Forth Class, Starting Forth, GUI's...

4. You don't need forth to run forth

5. Getting Forth related files (was: Forth primer/teaching Forth)

6. Forth in Forth vs. Forth in assembly language

7. Forth in Forth vs Forth in assembly

8. Forth in Forth vs. Forth in assembly language

9. Help Please Fig Forth question from Forth beginner

10. Forth Successes / Failures

11. Forth Successes / Failures

12. Success of FORTH in the marketplace

 

 
Powered by phpBB® Forum Software