[comp.lang.forth] Forth is neither useless nor powerful

eaker@sunbelt.crd.ge.com (Charles E Eaker) (03/26/91)

>No, I don't need the language to tell me that : 1 2 ; is stupid.  I also
>don't need my circular saw to tell me that it's stupid to stick my 
>fingers in the blade, but I leave the blade guard on anyway.

The issue then becomes is this the kind of thing a language should
guard against? Is the danger so grave that restrictions should be
introduced?  If so, what sorts? Eliminate leading digits in word names?
That's not ok with me. I think that 2* is a Forth word name I would not
want to sacrifice in favor of a "guard" on a "blade" that I don't think
is all that dangerous to begin with.

>                                                          The difference
>with Forth is that the semantic garbage instantly becomes system garbage.

That is a characteristic of your system and your implementation of
Forth.  It is not a necessary feature of the language. Are you running
fairly simple versions of Forth on a PC? Then the reset button is
probably an important debugging tool. But that's true of any renegade
program on a PC no matter what language it was written in. All Forth
does is reduce the cycle time between successive depressions of the
reset button. It usually doesn't increase the number of times you have
to press the button.

Other systems gracefully inform you of a segmentation fault or other
symptom of coding flaws, and can even restart the Forth interpreter
providing you with source level information about where the problem
occurred.  Forth need not be any different than other languages in this
respect.

>                                                      It just seems
>to me that Forth is too "powerful" for its own good.

Forth may be too dangerous for your tastes, which means, I suppose,
that you feel insecure in some way when you use it. But Forth is NOT a
powerful language. There may be powerful wordsets written in some
vendor's dialect, but there is no extant specification of the language
or commonly implemented wordset that comes even close to being called
"powerful".

	Q: "How do you do floating point calculations in Forth?"
	
	A: "Well you can't unless you are using vendor A's Forth in which
	case you do ... Or unless you are using vendor B's forth in
	which case you  ....  Or you can get a wordset off this BBS I
	know ... of course nobody has staked his or her reputation on
	maintaining it or anything like that, but you did ask about
	Forth, after all.  But it's easy enough to write your own
	floating point wordset in Forth.  That's what a lot of us do.
	But if you really understand your problem and you really
	understand computers, you know that all calculations are really
	done with binary integers anyway, so you merely define a bunch
	of Forth words that do just the calculations you need with no
	more precision than you need ... Of course if they are all
	colon definitions, they will be too slow to be of any use, so
	you will have to code some of them in assembler, and even
	though we use lots of different cpu's and even lots of
	different assembler wordsets for the same cpu, really good
	Forth programmers will be able to use your code without any
	trouble, provided, of course, that we want to, which really
	isn't very likely especially if you use names that we don't
	care for, but at least you can port your application to other
	platforms if you stick with it and become a really good Forth
	programmer ..."

	Q: "Uh ... gee, thanks."

Sadly, this conversation has to be repeated with many things that are
available in, taken for granted by user's of, and supported by vendors
of, other languages. Given all the things that one needs to be able to
do in modern programming languages for which there is no convergent set
of statements that go, "The way to do that in Forth is ...", I do not
think of Forth as being much more than a great concept implemented as
an eccentric instruction set for a rather simple virtual machine.

It is certainly possible for Forth to be more than that. The
FORTHcoming standard is a "minimal" step in the right direction.

--
Chuck Eaker / P.O. Box 8, K-1 3C12 / Schenectady, NY 12301 USA
eaker@crd.ge.com        eaker@crdgw1.UUCP       (518) 387-5964