"Robert Miller" <rsmiller@[EMAIL PROTECTED]
> wrote:
> I have followed with considerable interest, the thread 'The Promise of
> FORTH' started by Johan Thomas. Much has been made of FORTH's
> perceived shortcomings but as these are mostly inherent, there is
> little likelihood that any significant changes can be made.
Forth is extensible. You can do anything you want with it, if you want
to bother to do the programming. But you can't force other Forth
programmers to do it your way, unless you're the boss. So if you want
objects, Forth has lots of object systems. If you want locals, they're
there. If you want pretty-printed source code, with careful indenting,
you can write that way or you can write your text editor in Forth to do
it for you, or you can write a Forth routine to do it to your source
code after it's written. You can have anything you want. But after you
make it work your way, it isn't exactly Forth. Because you haven't
forced everybody else to do it too.
> That said, I think most here
> would like to see a thriving Forth community. In order for that to
> happen, the first thing is to get the existence of the language into
> the consciousness of the general programming community. John Doty's
> complaint that there is no body of shared Forth code reflects that.
> The second thing is to identify those strengths of Forth that would
> make it attractive to potential users and somehow getting the word
> out.
Yes!
> From my point of view, the attractive features of FORTH are; first
> that it is an incremental compiler, second that it incorporates an
> assembler, and third it is extensible.
There are lots of incremental compilers now, right? That's a strength
for Forth, but not much of a selling point just now. The easy extensions
are good but that's also possible for every other acceptable language
now.
The assembler is good, and writing *very short* stretches in assembly --
which you can test easily and quickly -- is a big plus. And you can put
those short stretches together into bigger assembly routines that you
can test easily and quickly. You can keep doing that until your code is
as fast as you need it. BUT -- the conventional wisdom is that
assemblers are no good. Better to use C. So it's probably good to have
that as an option. If you could switch into C to make named Forth
primitives, that might be almost as good as assembler. Some ways better
because easily incrementally dropping into C is something people can
understand when they're prejudiced against assembler.
> Although extensibility is not a big issue for my application, it is a
> powerful tool for anyone who needs it. I have done quite a bit of
> (admittedly boringly linear) work using C/C++ and I haven't
> encountered anything like DOES>. If you want OOP, it would seem that
> you could add it. (How about an OOP word set in the next standard?) If
> you haven't time to add badly needed OOP to your FORTH , use C++ or
> some other language.
Forth has an embarrassment of incompatible OO extensions. It wouldn't
bother me to make them all standard.
> As to the perceived disadvantages of FORTH, the readability and
> maintainability issue can be dealt with by maintaining a bit of
> discipline in commenting.
I think this is a red herring. Forth is quite readable, but some people
don't know Forth and so they can't read it, while others have esthetic
objections to some Forth writing styles. There isn't much we can do
about writing styles except agree to disagree. If somebody presents code
you can use and you don't like their style, then don't use their code.
Settled. And people who don't know the language and criticise its
readability should be, ah, encouraged to learn the language.
> As to getting FORTH known to the wider community, I am at somewhat of
> a loss. Certainly encouraging code sharing would be helpful - if the
> shared code was well done and well documented. Maybe FORTH Inc.
> should be providing T-shirts displaying their Logo with each SwiftX or
> SwiftForth license or with each addition to a shared library - or at
> least offering them for sale. I go to a gym across the street from
> QNX and a lot of the people in the gym are wearing QNX Ts. I wonder
> how many of these guys have ever even heard of Forth. Every little
> helps.
A great application would be good. Here's a somewhat-vague idea I had a
few years ago. Forth ought to have some special niche on the internet.
But for things like the WWW we have to play catch-up. There's a gigantic
network of encrusted standards that aren't quite followed, and to get
anywhere we need a very good understanding of the complex common
practice. Forth does better where we can exploit simplicity better than
the other guy. We have the same problem to a lesser degree with TCP/IP.
Complex standards that are not followed very well, and we've played
catch-up. But with TCP or UDP or whatever we made for ourselves at that
level, we can invent our own standards for whatever we want to do.
There's no necessity to use HTTP etc unless they fit our needs. There
are many thousands of protocols that are officially in use, and we could
have our own -- provided there's something we want to do that deserves
its own simple protocol in place of HTTP etc. We could for example have
a collection of byte-code Forths for special purposes. When you want to
communicate with somebody for the particular special purpose, download
the Forth that does it. A method to easily and quickly build
special-purpose byte-code Forths might be useful for that.
We can do practically anything over the internet, provided it's worth
the trouble to do it simply in Forth instead of fitting it into one of
the existing complicated protocols. Get the application running and
maybe final users can just download it and see it work. The tools to
create all that aren't very hard. All that's needed is applications that
are worth doing.
> In any event, it would be most helpful if c.l.f participants were a
> bit less negative.
There are always ants at a picnic.
|
