home .. forth .. colorforth mail list archive ..

Re: [colorforth] How is colorForth different from other Forths?

Nick Maroudas wrote:

Samuel A. Falvo II wrote:



Yes, and complexity breeds complexity.A single amoeba holds little
chance against a multi-cellular life form (yes, I'm familiar with
Amoebic Dissentary, but that's caused by LOTS of amoebas running around,
not one).One needs either lots and lots of amoebas (the embedded
computing case), something fundamentally *different* (e.g., viruses;
dataflow processors, hardware neural nets, or traditional [perhaps even
slow] CPUs with good vector processing capabilities [see Cray X1 CPU for
instance] are good examples), or additional complexity (multicellular
organization, intelligence, etc.; Chuck's 25X, CPUs with superscalar
architectures and at least 4 stages per pipeline) to be able to compete
for resources successfully.



 Agreed that "complexity breeds complexity" but, like Frederic, I think we
should be careful to distinguish between neurone count and intelligence,
between adaptation as survival and adaptation as progress.  CF seems to me
an example of progress by elimination.  It  is like the light, open sports car
that the British used to make and Mazda has lately revived with a few
modern conveniences.  Some other forths are like a doubledecker tourbus.
Either vehicle can take you for a scenic drive round the corniche - but it
will be a different experience.  In the light sports car you will be
exposed to the elements so, as Chuck says - be careful.
Look at the mechanism. When it's hard to get something to work, you dcon't want to discard things that work even if you don't need them at the moment. Store it safely away and maybe you'll find a use for it later. The exception is when it costs a lot to store them.
So when you had 16K of RAM and 320K on a disk, it made sense to have just what you needed in the program, and store routines in a library on disk. When you have 64M RAM then it's less inconvenient to store dead code in the program.
And when the system is too complicated to understand, it makes sense to use an evolutionary approach to changes. Add something new, see if it works. If it causes too many problems with existing routines, take it out and rewrite it. If an existing routine causes problems with too many new candidates, remove *that* and see what stops working, and patch things up until they work without it. As long as the system keeps working most of the time, you're happy.
In biology it tends to be size constraints that make the difference. Bacteria don't carry nearly as much dead code as higher organisms; they can't afford it. And some viruses are so compact they code for two proteins with the same DNA, in different reading frames. (DNA codes for amino acids in triplets, so there are three different reading frames. If you code for two different proteins with the same sequence then you have extra contraints; some things that would improve one sequence will wreck the other. They'd probably do better to have two independent sequences if they could afford it.) I read about a virus gene sequence that made three different proteins, two of them in two different reading frames on one DNA strand and the other on the other strand, heading the other direction.
Things do get simpler in evolution, whenever simplicity is selected. Cave creatures lose their pigmentation and then their eyes, not just by random changes but also because both are an energy drain that is subject to selection.
Things that humans think about could be selected for simplicity. When we build things and we can't think about the whole thing, we depend on interfaces. Turn pieces of it into black boxes with simple inputs and simple outputs and you don't have to think about those details. But it's better when you *can* think about the whole thing. Pieces with simple inputs and simple outputs are good, but when you can look into them whenever you want to, you can find new and better ways to factor them.
Also, when the requirement doesn't allow something so complicated that nobody understands it (that usually works but fails at a generally tolerable rate), there's a niche for something simple enough to guarantee. 



---------------------------------------------------------------------
To unsubscribe, e-mail: colorforth-unsubscribe@xxxxxxxxxxxxxxxxxx
For additional commands, e-mail: colorforth-help@xxxxxxxxxxxxxxxxxx
Main web page - http://www.colorforth.com