Jeff M. wrote:
> Most posts (including the most recent thread: "The Promise of Forth")
> tend to try and focus on why Forth is/isn't just as good as <insert
> competitive language here> and then proceed to spout statistics on
> productivity, write-only code, difficulty of floating point
> calculations, efficiency of the stack (good and bad), etc.
>
> I'd like to discuss the (de?)merits of Forth from a different
> perspective. With my current outlook on computing (which tends to
> change every 5 years or so), the future is quite bright down the path
> of vector-based, multi-core, parallel computing. [Note: obviously
> there will always be a need for very small device programming. When
> that's the case, I would choose no other language than Forth].
>
> The core concepts of Forth: dual stack, highly factored, simplicity,
> etc, all lend themselves to being very applicable in any settings.
> However, I have a very difficult time picturing the use of Forth on a
> GPU, doing large FE analysis across 100s of machines, or for real-time
> stock trading. That's not to say it couldn't be done, just that I
> don't think it will be. And that saddens me.
>
> I'm curious, have there been any efforts or attempts to massively
> parallelize a Forth implementation and allow cross-process/thread
> communication (ala Erlang) or perhaps to create a vectorized Forth for
> large vector and matrix operations? If so, how did these
> implementation work out, what was different about them from a
> standard, ANS Forth implementation? Were there any inherent advantages
> to using Forth once the project was done? Disadvantages?
Well, NASA's "Massively Parallel Processor" used Forth for image
processing. Forth was the first language to be used on it. And, of
course, today there's Intellasys, www,intellasys.com
> I've used Forth quite successfully in the past for a few projects. But
> I've always felt that [ANS] Forth was the wrong solution anytime I
> needed to use floating point math, do large-scale mathematics, or
> where job scheduling, multi-threading, and problem distributing across
> machines were all critical to the success of the project. That's not
> to say Forth can't do those things, just that I found myself far more
> productive - quicker - doing those things in C (or another language at
> times). And I'm very interesting in work others have done in Forth
> where those were their goals.
I haven't personally done much heavy number-crunching (though others at
FORTH, Inc. have), but I've certainly used Forth in a lot of projects
that have involved job scheduling, multi-threading, and
multi-processing. All Forths produced by FORTH, Inc. have supported
multitasking (multithreading) since the 1970's. Our approach to this,
which is documented in my books "Forth Programmer's Handbook" (2007 ed.)
and "Forth Application Techniques" (both available from FORTH, Inc. or
Amazon) describe our approach in much more detail than I can go into
here. If you have any specific questions, I can try to address them.
Cheers,
Elizabeth
--
==================================================
Elizabeth D. Rather (US & Canada) 800-55-FORTH
FORTH Inc. +1 310-491-3356
5155 W. Rosecrans Ave. #1018 Fax: +1 310-978-9454
Hawthorne, CA 90250
http://www.forth.com
"Forth-based products and Services for real-time
applications since 1973."
==================================================
|
