Several weeks ago I made a posting asking for guidance in getting a
high-quality Forth to run on a 386 Xenix/Unix.  My message was almost
totally ignored.  I suppose I could just let my imagination manufacture
reasons as to why I was ignored, but that doesn't seem a very productive
thing to do.  So, I've decided to make a followup posting -- I think it is
*important* to get a high quality Forth running in a 386 Unix environment;
whether you work with and like the Intel 80386 processor or not, it is
my understanding the the current boom in Unix acceptance owes at least as
much to the availability of cheap 386 machines as it does to any other
single factor.  I think it would further both Unix and Forth to have a serious
alternative to 'C' on 386 Unix machines *specifically*.  I admit that a
Forth on 386 Unix would benefit me personally, of course -- 386 Unix is
where I expect to spend the next 5 to 10 years and I guess I'm about the
only programmer in the world who (*blush*) thinks 'C' is overused and
overrated.

My original posting asked how to approach porting an 8088 Forth from MS-DOS
to Unix/Xenix.  It would be better, of course, to get a Forth written
specifically for a 386 processor, but I figured that could be dealt with
later if the ported Forth included a metacompiler and/or full source.  And
there are a number of fairly robust, public-domain Forth's available for the
8088 architecture which should be able to run under Unix/Xenix once the
system calls and binary-header are changed.  I also acknowledged that I
don't know squat about implementing/porting Forth although for some perverse
reason I am strongly attracted to the language.

I said all that and I got . . . silence.  Doesn't anyone knowledgeable who
reads this group share my interest in getting F83 or F-PC or some other
good Forth to run on a 386 Unix??  Did my message fail to get widely
distributed to the net?  Did I say something so "silly" or boring in my
posting that everyone immediately pressed "n"?  Maybe none of the serious Forth
people who follow this group work on 386 Unix machines?  I suppose you might
be divided between those who read usenet but only work on MS-DOS and those
who do use Unix but have high end Sun workstations and VAX minicomputers??

I've exchanged email with a couple of people who have Unix based Forths
written in C and perhaps something will come from one of those leads.  But
I'm concerned that the Forth I use not be a second-rate citizen under Unix;
it will need to support system calls and curses, at a minimum, and it *must*
be f-a-s-t enough so developed applications can compete seriously with
programs coded in C. That doesn't mean the Forth programs have to be as fast
as equivalent C programs, but they've got to be close--not an order of
magnitude slower.  Doesn't that almost necessitate assembly language support
for new primatives?

Is he correct?  That would be terrible.  Some other quick questions before I
end this posting: (1) I just received the FIG catalog. They don't have a 386
Forth advertised but they do have F-PC available.  I've never seen it and
I'm wondering if *complete* assembly source is available and if it might be
a better choice for porting to Unix than is F83?  (2) I've failed in all
attempts to correspond with either the author of the Forth 'compiler'
(CFORTH) or the maintainer of the Forth archive (I wanted to get the source
listing of the minimal Forth kernel and the article describing the different
mechanisms for Forth threading).  I guess that is the problem with crossing
over from uucp (what I have access to) and internet?  Isn't there any
reliable gateway for handling that transition through which I could mail
my letters?

Thanks for your attention.
--
{pacbell!sactoh0! OR ucdavis!csusac!}tree!stever

I never replied to the original posting because I am still very much a
novice Forther. However, I did expect someone to post a reply similar
to:

Such a beastie does already exist in Mitch Bradley's C-Forth which is
claimed to run under SCO Xenix 386. It is available from Mitch for $50.

Disclaimer: I've only heard of Mitch's product. I have not gotten to the
point in Forth where I'm willing to pay for a Forth. I've been using
F-PC under DOS to learn.

If it does turn out that Mitch's C-Forth is not what you want and still
want to make one of your own, I am willing to act as a beta tester and
provide any possible UNIX, C, or 80x86 assembly support I can. I'm good
at all of the above but don't know enough Forth yet to try and implement
one. I can be contacted at one of the addresses below:

j                               |%|John Lawitzke, Dale Computer Corp., R&D
                                |%|UUCP: uunet!frith!dale1!jhl          Work
                                |%|      uunet!frith!dale1!ipecac!jhl   Home

People rarely post a message to the net saying "I don't know the answer to
the question asked by Steve Rudek"

Somehow when we post to this newsgroup we believe that we are addressing the
entire Forth community. Periodically I post a call for people who are involved
in teaching Forth and are interested in education -- and I get silence too.
There are people involved in teaching Forth, they just aren't on USENET.

[Actually there are only about 10 people on comp.lang.forth (even this is a
bit misleading since Tom Almy, Bill Bouma, Mitch Bradley, and John Wavrik are
really pseudonyms for one person who periodically writes a series of heated
exchanges to stir things up)]

P.S. I know of at least one person who responded to you by email.

                                                  John J Wavrik

                                                  Univ of Calif - San Diego
                                                  La Jolla, CA  92093

$ [Actually there are only about 10 people on comp.lang.forth (even this is a
$ bit misleading since Tom Almy, Bill Bouma, Mitch Bradley, and John Wavrik are
$ really pseudonyms for one person who periodically writes a series of heated
$ exchanges to stir things up)]

I think I'd qualify that as 10 expert Forthers in the group and a bunch
of us novices....

j                               |%|John Lawitzke, Dale Computer Corp., R&D
                                |%|UUCP: uunet!frith!dale1!jhl          Work
                                |%|      uunet!frith!ipecac!jhl         Home

Make that 11.  I read it, but since I don't even know FORTH enough to be
dangerous I don't dare post.

                -- Gordon.

--
        ...!uunet!telxon!ping!gorpong

Steve,

We (my group at Tektronix) has contracted to get a 386 UNIX with X Windows
support. Our problem has been to get a working Unix system to send to the
contractor! The final system should be commercially available (not through
us) but it won't be Public Domain.

Why is it that people are willing to pay good money for other languages,
but expect to get good Forths for free?  Why did I decide to make a few bucks
(and *very* few) with Forth when I could have made it rich with a
"politically correct" language used by people with $money$?

[John, are you taking credit for other postings? Or am I responding to myself
occasionally? Have I added enough heat -- Forth users are unlikely to spend
money keeping their furnaces running. :-) of course, I guess.]

Tom Almy

Any resemblance to any person, living or dead, other than myself, is
coincidental.

A good question.  I've been stewing on an answer for about 10 years.

First of all we need to settle on a definition of "good money".  I've
purchased a number of languages through the years, including:
  Software Toolworks' C (cpm)   $50
  Laboratory Microsystems' Z80 Forth (cpm)  $50
  FIG Forth (cpm)  (public domain, but I probably spent about $50
     between disks and source listings)
  Turbo Pascal (msdos)   $50
  Turbo Pascal version 3.0 (msdos)   approx. $50 for update
  Turbo Prolog  (msdos)   $70
  Turbo C  (msdos)        $70
  Abundance/BBL Forth (msdos)  public domain, but I spent $75

Some comments and observations:

(1) I've never spent over $100 on ANY language.  I don't know how common my
parsimony is, but I don't feel too apologetic.  Borland products have been
uniformly EXCELLENT (for my purposes) for less than $100 so why should I spend
more than $100 for a language implementation which is only "good"?

(2) I've purchased 3 different Forths over the years, including LMI Z80
Forth.  I haven't gotten even a "good" version yet.  BEFORE YOU FLAME ME, let
me explain.  In my opinion, a good software product must be (a) friendly (b)
COMPLETE (c) bug free (d) powerful/flexible (e) WELL DOCUMENTED.  The
strategy I follow to learn a new language is to cursorily read the
documentation and then jump in with both feet to write a non-trivial
application which I've been thinking about writing in some other language.
This strategy has never worked with Forth because (a) none of the Forth
implementations I've seen have had adequate documentation to accomodate an
experienced programmer who happens to be new to Forth and (b) to quote from
a recent Harvard Softworks Forth adverti{*filter*}t:

        Forth has to [sic] often been the language that tempted programmers
        with 'great expectations', then frustrated them beyond all endurance
        with the need to reinvent the simplest tools expected in any commercial
        language.

How am I supposed to react when I sit down to learn Forth by writing a
full screen arcade-style game for my PC and find out that *I* first need to
write a slough of primatives to perform basic file manipulation, string
manipulation and floating point math?  There are some further hitches,
of course. Before I can undertake to write these primatives I really need
to write a decent full screen editor since the vendor doesn't include one
and I can't use Wordstar on Forth BLK files.  And before I can write
either the editor or the primative operations I really need to be an
experienced Forth programmer.

Oh, yeah, and before you can become an 'experienced Forth programmer'
I need to understand esoterica such as DOES> CREATE and the operation
of the dictionary and inner interpreter.  Of course the vendor
doesn't adequately document these esoterica or provide any
real examples of their use.  Generally the vendor is nice enough
to refer you to _Starting_Forth_.  Of course, _Starting_Forth_ (unlike K&R's
_The_C_Programming_Language_) doesn't document the esoterica, either,
but only the simple stuff.  Oh well.  You can always buy a FIG assembly
language listing and try to figure out DOES> CREATE from reading that and
examining chicken entrails.  (By the way, Kelly and Spies _FORTH:_a_Text_
and_Reference_ *does* explain things in more detail...but it wasn't
published until 1986).

Forth probably has the steepest learning curve of any language in
existence.  Given the severity of the learning curve, even "ordinary" levels
of documentation are NOT sufficient.  No wonder (according to a recent
posting to this newsgroup, I believe) an unusually small percentage of
Forth programmers are computer science degreed; only hardware hackers have
the background to pick up this language easily.  This needs to change.

(3) Because of the problems mentioned above, a very large number of people
have been 'burned' by Forth.  They've put time AND MONEY into the language
and come out with nothing.  Incomplete implementations and lousy documentation
have soured an enormous number of talented programmers.  If the "public
domain" implementations were the whole problem it would be one thing, but
I don't think that is the case.  When I discovered that the FIG 8080 model
wasn't really robust I just wrote it off as "what can you expect for free".
But when LMI Z80 Forth wasn't much better I was really irritated.  I think
my experience with a commercial Forth implementation is shared by many.  And
you wonder why people aren't anxious to spend more money to try Forth again?

(4) Those who survive the Forth learning curve tend to be hardware hacker/
systems programming types.  Everyone else has been chased away.  Those
who remain have commonly read FIG Forth Assembly Source Listings cover to
cover.  If push came to shove they could write their own Forth from scratch.
And many of them have a secret dream of doing exactly that, whether they
really need to or not.  So...why should they spend more than a hundred
dollars to get a merely 'good' Forth??  Tell you what:  write a KILLER
Forth for Xenix 386 which is competitive with a Borland Turbo C in terms of
performance, documentation and "extras" and I would be willing to spend
up to $250 for it.  But I won't take that gamble for another shot at a
"good" Forth.

A number of people have written me to mention that Mitch Bradley's CForth
runs under Xenix and costs only $50.  I'd be delighted to spend $50 except
that it's pretty evident from postings to this group and a mail response
I got from Mitch that his CForth is a second class citizen under Unix.  I'm
not disparaging Mitch or his program--I'm sure he's many times over the
programmer I will ever be.  But the Unix Forth I would like to see must
be able to compete with the standard 'C' compiler in terms of
PERFORMANCE, support of Unix system calls, and the functionality of standard
Unix C libraries.  In particular, a Unix Forth must have complete curses
support or how can I justify using Forth in place of C?  Although Mitch says
that curses support could be hooked into CForth it apparently isn't built in.
And even if it were built in, even Mitch admits that a CForth program
is significantly slower than a comparable C program.  (Please folks, don't
flame me for these comments--I'm trying to get you thinking and talking...
I'm not trying to make an enemy of Mitch or anyone else.)

(5)  Those who survive the horrendous Forth learning curve and, ultimately,
become such experts on Forth internals that they could write their own
Forth discover something else:  compared to other languages, Forth
implementations are EASY to write!  Think about it.  Writing a high
performance, commercially-competitive C or Ada compiler is a extremely
intricate task which almost mandates years and years of formal computer
science education and many man-years of coding.  On the other hand, a Forth
hot shot could write a REALLY high performance Forth within 6 months,
programming all by himself.   And he probably wouldn't have to know a
thing about technologies such as compiler-compilers, LALR parsers,
and optimizing compilers.  So...why SHOULD a commercial Forth vendor
expect to be paid as much for his system as another vendor might
charge for a C or Ada or Modula-2 compiler?
--
{pacbell!sactoh0! OR ucdavis!csusac!}tree!stever

I guess that I can make it at least 12.  I am a regular reader who
hasn't done enough real coding in Forth to have any strong opinions
that I'm willing to express.

Of course, I think we could count something resembling the real number
of readers.  Every few months they used to run a survey of the number
of readers on each news group.  The backbone machines would run a
program (I can't remember the name, but it kept being reposted & had
some catchy name) that read their users' .newsrc files & sent the data
to some central information repository.  This individual would combine
the stats & publish various lists (including Top 10's and Bottom
10's).  The census was only approximate (estimated based on a bunch of
the larger machines), but gave an idea of readership.  I haven't seen
one of those surveys in a year or two...
Christopher Browne

University of Waterloo
ACM Scholastic Programming Contest: Internationals in 1991!!!

Wrong-O.  You can make a read/write executable image very easily
(in BSD UNIX at least).  Just pass the -N flag to the 'ld' (linker)
program when you build your executable.  This is the oldest form
of executable, back from the days when there wasn't any text sharing.
And it doesn't even require root privilege! :-)

-TW
Sybase, Inc. / 6475 Christie Ave. / Emeryville, CA / 94608        415-596-3500

                This message is solely my personal opinion.
                It is not a representation of Sybase, Inc.  OK.

I agree wholeheartedly with many of Steve's comments about the "wimpiness"
(my word) and incompleteness of many commercial Forth systems.

On the other hand, I would like to present another viewpoint about the
economic considerations involved:

Because the commercial Forth vendor has to pay for his food, lodging,
office space, taxes, telephone, shipping, printing, and salaries at the
same rates as the commercial C vendor.  The development effort is a fixed
cost, and is only a small component of the cost of doing business.
Also, since the market for Forth systems is so much smaller than the
market for C compilers, the Forth vendor amortizes his development
costs over fewer systems.  On a per-unit-sold basis, the Forth vendor
may have higher development costs than the C vendor.

C compilers used to cost thousands of dollars before C caught on and
the market expanded.

Furthermore, it is not any cheaper to write the documentation for
a Forth system than for any other language.  The only way to save
money on documentation is to do a crummy job.  In order to show a
profit, considering the small market for Forth systems, you can't
spend too much money up front.  Remember what Unix documentation
used to be like up until about 5 years ago, before Unix "caught on"?
You got a line printer listing of the man pages, and you were lucky
if that was up-to-date.

Steve's comments about C Forth 83 are correct.  It is missing some things
that would be nice to have.  The cause of these shortcomings is rooted in
economics; I don't (and doubt that I could ever) make nearly enough money
from C Forth 83 to justify spending the effort on improving it into a really
great system.  It is important to understand the "niche" that C Forth 83
fills.  C Forth 83 is mainly for those people who use machines for which no
better Forth alternative exists.  As such, it is important that I keep it
as portable as possible.  This works against the inclusion of Unix-specific
things like curses (while many people use C Forth 83 on Unix machines, it is
also used under VMS, DOS, and MVS).

I am basically providing C Forth 83 as a service.  The $50 price of C Forth
83 is just enough money to keep me doing it.  You can't get very high on
the "economy of scale" curve when every customer has a different machine
with a different OS variant, different media requirements, and different
C compiler quirks.  Consequently, the bang-per-buck of C Forth 83 will
never approach that of Turbo C (which, incidentally, is not getting cheaper).

I put most of my effort into products for which I can get a reasonable
aggregate return; namely my assembly language Forth products for Suns,
Atari STs, and SPARC boards.  Those products have many (most?) of the
features which Steve identified as desireable.  In order to justify the
considerable effort and expense of producing and distributing a product,
you have to be able to make enough money.  That means you need either
enough bucks per copy or enough volume (and if you go for a volume market,
you have to slug it out with all the other competitors).

My prices are fairly low; $50 for the Atari product and $200 for the Sun
product.  I would be hard pressed to make a living selling Forth systems
at those prices.  That's why I have a full time job at Sun.

Steve argues that the demand for Forth systems might be higher if the
quality was higher.  This is almost certainly true; on the other hand,
there's a chicken and egg situation in the creation of a market; you
need the volume to get the price down and the quality up, but you need
the affordable, quality, product to create the volume.

No offense taken; the specific complains about C Forth 83 are 100%
accurate.  I'm just trying to communicate some of the lessons that
the marketplace has taught me.

Oh, by the way, I note that JForth for the Amiga is an excellent product
at an attractive price, yet the developer (Phil Burk) says that he hasn't
yet broken even on the product.  He has to pay his bills with a real job.

Business is tough.

     Cheers,
     Mitch

I guess I am lucky 13.

ken

--
-------------------------------------------------------------------------------
Disclamer:  of course it works

{pacbell|ctnews|mordor|sgi|ernie|amdahl}!key!ken