NetNews Usenet Archive 1993 #3/NN_1993_3.iso/spool/comp/lang/forth/3944

Text File | 1993-01-21 | 4.0 KB | 77 lines

Newsgroups: comp.lang.forth
Path: sparky!uunet!math.fu-berlin.de!informatik.tu-muenchen.de!pazsan
From: [e-mail] (Bernd Paysan)
Subject: Re: Forth's Adaptability
References: <[e-mail]> <[e-mail]> <[e-mail]>
Originator: [e-mail]
Sender: [e-mail] (USENET Newssystem)
Organization: Technische Universitaet Muenchen, Germany
Date: Thu, 21 Jan 1993 12:03:16 GMT
Message-ID: <[e-mail]>
Lines: 64


In article <[e-mail]>, [e-mail] (Chuck Eaker) writes:
|> I agree with everything you say about Forth, but I am dismayed at
|> continued defenses of blocks and built-in editors and the
|> rejection of alternatives. The point being made by several people
|> in this thread is that blocks make it very difficult to apply
|> other well-known and powerful tools to the Forth development
|> environment.

What do you mean with "rejection"? All I heard is defending blocks
and built-in editors as a good and useful tool. This does not mean that
no alternatives are allowed. As Ray says in another article, commercial
environments of Forth does support these alternatives. In my experience
it turned out that blocks and other features of Forth give a powerful
tool to implement any sort of stream file (I'd like the one with counted
lines, but my host operating system uses cr/lf to terminate the line).

A command like SH is nice, too, but this does not necessarily mean
"shell script suport" but to start other aplications. I've a SH and a
RUN, too (the latter directly starts the program, the first starts
$SHELL -c <command>). I prefer forward parsing versions, because with
EVALUATE (or my subword ">TIB) it's easy to build a string in the TIB.
And I rarely use SH or RUN in programs, but I like it interactive.

|> Perhaps I'm wrong, but it is my impression that there are still
|> many in the Forth community who look upon files and streams as an
|> unnecessary bit of complexity grudgingly allowed in dpANS to keep
|> Mitch Bradley, and others tainted by their exposure to C and UNIX,
|> happy.

:-). Then be happy. There is, and you can use it. There is even the
Chuck Eaker's case, the wrong solution to a typical problem, where one or
two tables would fit much better (gcc 2.3.2 even compiles case select
statements into branch tables - that's the solution! Maybe you find an
implementation of Eaker's - your - case that does that, too! It's not
the syntax that makes case slow, it's the implementation!).

|> I think the Forth community is unique in resisting a change in
|> the language which would result in giving its users access to
|> powerful tools.  This is the basis for my insularity claim.
|> Unfortunately, many Forthers go beyond Forth's traditional and
|> valuable questioning of the "complexity is good" philosophy and
|> adopt the silly position that all complexity is bad. This is the
|> basis for my self-righteous claim.

My father, working in system developement for 20 years, says: "it's
easy to find a huge, very complex solution to a problem, it's far more
difficult to find a simple solution to the same problem." And even
worse: it's very difficult to explain the power of the simple solution.

It takes more time to build the complex solution, but you have hard to
think for the simple solution (and eventually this takes much more time
than to start without thinking and make it complex).

On Forth conferences (like EuroFORTH or so) I get the impression that
many forthers are quite innovative. They added to Forth nearly all the
power any specialized other language has. I've seen (and implemented)
object oriented tools; pattern matching and backtracking like in Prolog,
but including fuzzy logic, Anton Ertl even proposed a simple way to
create native code just as good as modern C compilers are (and it seems
to fit very natural to Forth).
--
Bernd Paysan
"Late answers are wrong answers!"