Re: future directions for FORTH
On Fri, 15 Aug 1997, Michael A. Losh wrote:
> Is it practical to integrate multiple CPU cores in a single die, which
> can communicate over a very high speed link, in other words, make
> parallel processing clusters on a single chip?
Most probably yes, but one will have to experiment with off-die
integration first, see where the bottlenecks are, and address them in the
one-die approach. Most probably memory bandwidth will be a problem,
driving number of pins and packaging cost way up. It might be an
improvement, over existing systems, though (provided one has the market
for them ;-)
> You have described yourself as a "perfectionist" which is a useful
> quality for a programmer, at least if you want to rewrite software to
> make it as good as possible. But the commercial world is going full
> bore towards pre-built software components and reuse, promoting Visual
> Basic and Java as glue languages for quickly slapping together systems.
> This leads to very inefficient use of computer resources, but it does
> seem to save programmer time and allow mediocre programmers to put
> together systems with a lot of functionality. Is it worthwile to
> justify the Forth/rewrite-everything approach to the masses in this
> age?
> Your development approach seems to work well for small systems, but what
> would you do if you had to develop or design an "enterprise solution"
> for a major corporaion supporting very large databases? As an example,
> the system has 1000 users for data entry, approval, and mangement;
> stores several dozen gigabytes of data in 100+ tables; "must"
> generate/display 300 reports for the users; and must automate the flow
> of work in well-defined business processes. What hardware would you
> recommend for the parts of the system? What software? Would you
> recommend a fully custom development? Do you think that current
> commercial database management systems are good and justified or
> overblown and bloated? Do you think that the client/server
> architechtures popular with business are appropriate?
These, I think, are very interesting questions.
The world is complex, and solutions have to be complex. How does FORTH
help us to manage complexity? What tools/concepts does FORTH
utilize/promote to help us manage complexity?
"Keep it simple" is a wish, but reality is not ideal. Do we put ourselves
in the position of the Physicist, who says "Yes, Chemistry is nothing more
but applied Physics. But it is so complex, that we'll leave the Chemists
to deal with is and we'll continue our search of solutions to more and more
abstract ideal systems."
My personal view is that complexity is best managed by factoring out
modules and isolating, standardizing, and publishing the interfaces. It is
unfortunate, that once an interface is published, it is fixed and has to
be maintained.
So how does FORTH help us deal with evolving, publishing, and managing
interfaces?
> How is software different from manufactured items, where a certain
> amount of standardization of parts has lead to much cheaper and better
> performing products, such as automobiles? Is Forth only appropriate for
> the "craftsman" or "chef" programmers?
We may be sure, that the amount of material bloat in a modern car is
_orders of magnitude_ less than the amount of code in windoze, for
example.
Cars do not use standard parts over 10 years. Yet, I have DOS programs
from 15 and more years and they run on a modern Pentium II and will
continue to run for at least 10 more years. There is an enormous amount
of bloat, associated with making them run today.
So, cars are not a good example of standardization.
On Tue, 19 Aug 1997, Jeff Fox wrote:
> I have planned to ask Chuck a half dozen questions about Forth,
> his ideas about hardware/software etc and give him about five
> minutes to talk about each one.
[...]
> My idea was not to try to get Chuck to explain the technical details
> of VLSI design, sub-micron, quantum-design, process variations
> available etc.
>
> The idea of this interview is Forth. It is clear to me that Chuck's
> idea of Forth is very different than the ideas that most Forth user's
> have about Forth.
>
> My idea is to get Chuck to explain something about Forth to the
> Forth community, not to train everyone to become chip designers.
A suggestion for a question, may be it exists already on the list: "What
tools (we know about the concepts) does FORTH have, or are natural for
FORTH to manage complexity in multi-programmer environments? What are the
known bad ways of doing it?"
I bet Chuck has a view on the problem by now :-)
--
Penio Penev <Penev@pisa.Rockefeller.edu> 1-212-327-7423
