NetNews Usenet Archive 1992 #16/NN_1992_16.iso/spool/comp/lang/forth/2839

Internet Message Format | 1992-07-22 | 5.3 KB

Path: sparky!uunet!crdgw1!rdsunx.crd.ge.com!ukulele!eaker
From: [e-mail] (Chuck Eaker)
Newsgroups: comp.lang.forth
Subject: Re: Down with free Forth systems.
Message-ID: <[e-mail]>
Date: 22 Jul 92 23:39:56 GMT
References: <[e-mail]> <[e-mail]> <[e-mail]>
Sender: eaker@ukulele (Charles E Eaker)
Reply-To: [e-mail]
Organization: GE CR&D Computer Science Program
Lines: 90
Nntp-Posting-Host: ukulele.crd.ge.com

I think it is worthwhile to distinguish between systems that are free
(or inexpensive) and systems that are professionally developed.
C and Pascal were both of these. A large number of Forth systems are
neither and I know of no other language for which popular implementations
are free and were developed by people who were paid nothing to do it.

Both C and Pascal were both developed by teams of professionals whose
jobs were to create such things. The circumstances of their development
were such that both were widely distributed to academic institutions at
very low cost. This was a unique window of opportunity which I doubt
will ever be open again.

For the C compilers, support, of sorts, existed from the very beginning.
This was rarely true for Pascal. I recall teaching with a Pascal
compiler running on a Burroughs 6800 (for which there was no documented
assembly language - Burroughs used Algol for their systems work) which
had wandered to our campus from God only knows where and, along the way
had picked up numerous idiosyncracies and exasperating bugs. This
experience led many of us to develop very bad attitudes about free
software: it was free to get in, but you paid the price over and over
in lost productivity.

The answer, it seemed, was to be found in using software that was so
open that we could maintain it ourselves, or getting rich and paying
someone whose reputation and nourishment depending on our being
happy with a programming environment.  So, some of us, not being rich,
tried Forth, but we discovered a basic principle: the more time you spend
maintaining your tools, the less time you have to actually use them.

The moral of all of this is that I believe the following:
Every "successful" language was professionally developed
and is commercially supported. Furthermore, the commercial
support comes from at least one big player who is going to be maintaining
the language and holding hands over the long haul.
(By "successful", I mean something which is used by lots of people,
a high percentage of which are trying to learn something or make money.)

Consequently, free Forth systems will (still) go nowhere. But, there
is no commercial enterprise in the Forth arena big enough to generate
much momentum, so I don't think non-free Forth systems will ever
serve more than a very small but very intense minority of users.

Unless....

Try this. Develop Forth++ which will operate in a Unix environment.
Define Forth++ words which take the name of a (preferably C++) library
(such as some of the X libraries) and links the library into the Forth++
environment so that a user can interactively list the classes, functions,
etc. provided by the library, create instances, execute methods, and
generally perform reckless experiments quickly and cheaply in the manner
that, for me, is the essence of Forth.

C++ will be around for a long time. Many companies have huge investments
in infrastructure that enrich the C++ environment in ways that
dramatically increase productivity. None of GE's software intensive
components would use anything other than a language such as C++ that
does early binding to generate production code. But that requirement
means that, at present, we are trapped in the compile, link, load,
run, swear, edit, compile, ... cycle, and the cycle is verrrrrrrrrrrry
long.

Off the shelf class libraries provide incredible leverage, but they
are stupifyingly complex and the documentation is enormous but still
incomplete. It takes forevvvvvvvvvvver, to create and run a little
program that will give you an answer to how this little widget
behaves when you do this weird thing with it that isn't mentioned
anywhere in the documentation. If I had Forth++ running in another
window, I could significantly increase my productivity.

Devise a Forth++ vocabulary and syntax that I could use for interactive
development and a tool that will translate Forth++ to C++ which
I can then compile and link the object file into Forth++ so that I
can continue development then translate ...

In my opinion the proposed standard has more than captured the essence
of Forth. What Forth needs is a way to capture other standards.
There are lots of common, well known, libraries out there that
tens of thousands of professionals are familiar with. They are
using them to leverage themselves into positions of power from
which they can develop sophisticated software quickly and
cheaply. Forth can never hope to match this achievement on its own.

Beat your standards warfare swords into plowshares and figure out
how to use them to break new ground by giving Forth the ability
to swallow whole the work of others and make it available in the
interactive way that we all know and love.

--
Chuck Eaker / P.O. Box 8, K-1 3C12 / Schenectady, NY 12301 USA
[e-mail]                        [phone]