NetNews Usenet Archive 1992 #18/NN_1992_18.iso/spool/comp/lang/forth/2978

Internet Message Format | 1992-08-18 | 5.8 KB

Path: sparky!uunet!munnari.oz.au!samsung!transfer!sw.stratus.com!nick
From: [e-mail] (Nicolas Tamburri)
Newsgroups: comp.lang.forth
Subject: Re: "Free" Forth is expensive
Message-ID: <[e-mail]>
Date: 18 Aug 92 22:35:22 GMT
References: <9208051453.AA09858@im8> <[e-mail]> <[e-mail]> <[e-mail]>
Sender: [e-mail]
Organization: Stratus Computer, Inc.
Lines: 103

[e-mail] (Mike Haas) writes:
> ... what machine
> DOESN'T run forth of some kind?  Actually, the question becomes,
> what machine CAN'T forth run on?

The question is not whether it can run it, but whether it runs it well.
For example: Stratus architectures, (admitedly not mainstream, does have a
Forth that runs on it,  but it doesn't run very well because Stratus
uses a Harvard based architecture which forbids the mixing of data and
program instructions.  This largely limits the theading to indirect
methods.  If I wanted my application to run fast, I'd probably not choose
Forth for Stratus.  The first Forth (er, TIL) I wrote was for a DEC PDP-10, whose
36-bit word architecture did not lend itself to character operations very
easily, (although for most other opeations it worked just fine.)

So, agreed, anything will run Forth;  IMO not everything will run it well.
Another example:  I know that JForth, (or any other Forth for that matter,)
does not do structures as well as C.  If the system required lots of
to access C structure fields constantly, and the Forths available required
I do handstands to access those fields, then I probably would not choose
Forth on that system.

> >But its limitations, rather than turning me off, then led me to seek
> >better alternatives;  in this case JForth.
>
> I think you are indirectly making my point.  Forthers will search for
> a better alternative because the KNOW it's out there...they "have the
> faith".  But newcomers, if their initial exposure is so minimal,
> will do the opposite (IMHO).
>
> >but I
> >was also trying to get into C, and let's face it,  the Amiga is geared
> >toward C.  C looked just as tempting as Forth, it was MVP-FORTH which
> >made me realize that Forth was viable on it.
>
> But MVP sure ain't gonna convince a C person to try JForth...or a Pascal
> person, or Modula-2, or...  (maybe BASIC :-)
>

Clearly there is no way to prove either opinion here, and we may just be splitting
hairs, but I see it this way:  New person at a PC gets a minimal PD Forth.
After some experimenting, and liking the interactive nature of it, he
outgrows and finds it limiting because it can't access the file system,
is limited to 64K, etc.  The Forth gets backed up to the floppy and put away.

Still, the user needs a language.  He starts looking at ads, or catalogues,
or (God-forbid) start browsing the local software store's language section.
He's now confronted with 2 languagge packages, both of which promise lots
of libraries and facilities.  One is Forth the other C.  He rembers liking the
interactive nature of Forth, and decides to check it out.

I don't think this scenario is all that far-fetched.  Something like it
happened to me. I don't I could be the only one.

> >... it would be nice if vendors started moving in that directions instead
> >of providing everything but the kitchen sink in one platform dependent
> >environment.
>
> Seriously, I wanted to provide an extremely comprehensive Amiga
> development system...something that would make those C fellows
> take notice of Forth.  And they have, it seems to be pretty-well
> respected in Amiga programming circles.  That can't be bad.

Not bad at all, and I didn't mean to imply it was.  I'm just trying to
provide a different point of view to consider:  Assume I am trying to
write the world's greatest game.  What platform do you think I'm going to
write it for if I want to sell lots of copies (hint: everybody hates it,
but everybody either sells it or buys it.)

Now, assume I have an Amiga at home because I prefer good hardware to
software availability.  I would be very hesitant to use many of the
things which make JForth good because I know they are not portable to
the PC, or Mac or Atari ST or just about anything else.  I'm not talking
about screen library routines.  I know I'm going to have to write
platform specific versions of those.  I'm talking about structure
access routines, ODE, Amiga specific multi-tasking tricks.
Things that are an inherent part of JForth and no other Forth.  In other
words, the things you've put into JForth which make it an excellent
prototyping and development package on the Amiga are a drawback for
someone like me, who cares about portability.

This same problem affects F-PC, and Yerk/Mops.  Both excellent packages
in their own right, but my mind reels when I type WORDS, and the list goes on
forever.   Where do you begin understanding a system like that?  Imagine
what it looks like to the novice.

One saving grace for most Forths, JForth included as I recall, is that
I can pick and choose what I want to load.  The drawback is that if I
choose to load any one package it usually loads lots of others.  Unfortunately,
either because nobody likes using VOCABULARY or because FORTH83 uses a
braindead scheme (IMHO), the main vocabulary keeps growing until you may
as well just load everything to begin with.

Let me summarize, so I can go home:  For me, (and maybe only me,)  portability
and a good development environment are the most important things in any Forth
package I look at.  I appreciate libraries as well, but only in so far as they
can be made portable between platforms.  Clearly we are at the point now where it
should be possible to come up with library routines which provide similar
functionality between the Mac, Intuition, Windows, Gem and maybe X.
Or maybe I'm just naive.  I do know that Forthmacs uses the same manual for
the Mac and the Atari ST.  That's a start.

                            /nt