Re: future directions for FORTH

[peb@xxxxxxxxxxxxxxxxxx (Paul E. Bennett)]

In message <Pine.SGI.3.96.970820191916.20422B-100000@venezia.rockefeller.edu> 
Penio Penev writes:
> 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 ;-) 
 
Mixing a processor core and memory on chip and including fast timer facilities 
is the most obvious. Two or three timers should be enough for any application 
(one for RTC functions, two for ad-hoc timing). A communications or network 
port is also very useful. These, I am sure, are quite feasable for a hybrid
package (logic plus memory) and the rest of the I/O can be bussed off-chip.
 
> > 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?

At present a rewrite in Forth can probably improve the vast majority of 
applications (I am told that VP Planner was better than Lotus 123 in a 
lot of respects). We should not need to rewrite everything everytime we 
do a project. I am certain the component oriented view will be taken up 
by the marketeers before too much longer and Forth is capable of coming 
in to it's own here. What wil be required are high quality components 
that at least meet the specification of their datasheet.

> > 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?

For some of the thinking that has been going on see the Forth and Corba 
threads in the newsgroup. Forthists do not yet have all the answers, but 
we can learn from some of the things that other non-Forth types are doing 
and improve on that, bringing the technique into Forth circles. The future
of computing generally will be in more open systems for the general business
community. Forth should be vying for space here.
 
> 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? 
 
The interfaces to Forth are quite simple. That is a general benefit but 
sometimes can be a disbenefit through lack of sophistication. When you develop 
a component that is going to be useable by the rest-of-the-world you need to 
ensure that you protect the component from incorrectly applied interfaces. 
This is like putting Surge Suppression Networks on comms lines to protect them 
electrically from lightning or other high energy sources. The Forth community 
needs to develop useful components with resilient interfaces like that. 
Naturally, away from the interface there is little need of such protection.
 
> > 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. 

The development in Windoze systems has probably been more fragile than the 
developers are willing to admit. At least with cars, the ordinary mechanic was 
able to, for a long time, deal with the repair and maintenance of the cars. 
Lately, even the car has begun to get so much more complex that the ordinary 
mechanic can no longer be intimately knowledgable about the internals of many
of the sub-systems. They, instead, deal with these on the replaceable 
sub-system level (sometimes on the basis of it might be broke so change it 
as a strategy for fault-finding).
 
> 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.

I think there are enough examples of 10 years life for standard parts designed 
in within a model range, sometimes over several manufacturers vehicles. 
However, this may not be the case for the "appearance" components where the 
vehicle design receives a face-lift after 5 years.
 
> So, cars are not a good example of standardization.

I would have thought it  reasonable enough an example. Depends on how you 
view it.
 
> 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 :-)



-- 
Paul E. Bennett ................... <peb@transcontech.co.uk>
Transport Control Technology Ltd.   <http://www.tcontec.demon.co.uk/>
+44 (0)117-9499861                  <enquiry@transcontech.co.uk>
Going Forth Safely