Jeff's UltraTechnology Blog

06/23/09 Forth Day 2008 Follow-up

The Silicon Valley Forth Interest Group put the video that they shot at their 2008 Forth Day online this week. I reviewed the presentation that I gave. I used to make transcripts but I haven't done that. Here is a link to the word document that was the outline for much of my presentation last year. It is not clear in the video.

A Transformational Algebra for Communicating Sequential Process Data-Flow Diagram Statements in Classes of Parallel Forthlet Objects for Design, Automated Place and Route, and Application Development on the SEAforth Architecture.

Near the end of my presentation I talked a little about a talking voltmeter demo but never showed it. Here is that picture that you can't see well in video of the diagram of the layout of the talking voltmeter demo.

The code samples a hardware A/D on node 36 and sends samples to node 35.
Node 35 linearizes samples using interpolation and a table on node 25.
Node 34 converts a number to decimal digits.
Node 33 uses digits to index into a sound table with spi address and length.
Node 32 plays reads spi address and lenght and sends it to the splitter.
Node 33 fills one buffer then the other and repeats.
Nodes 30 and 21 are buffers reading then writing 64 words so one can be filled while the other is playing.
Node 20 plays sound from alternate buffers to a digital pin using pulse width modulation.

Here is a portion of the associated VentureForth code. This code was written by hand but could be generated by dropping forthlet library routine and arrow icons onto a layout diagram in one of the tools.

36 {node $171 '--l- V.APP +include" a-d.f" node}
35 {node '--l- 'r--- '-d-- V.APP +include" linearize-interpolate.f" node}
25 {node V.APP +include" a-d-table.f" node}
34 {node 'r--- '--l- v.APP +include" digits.f" node}
33 {node '--l- 'r--- v.APP +include" sound-table.f" node}
32 {node 'r--- '--l- v.APP +include" spi-player.f" node}
31 {node '--l- 'r--- '-d-- v.APP +include" splitter.f" node}     
30 {node 'r--- '-d-- v.APP +include" buffer.f" node}     
21 {node '-d-- 'r--- v.APP +include" buffer.f" node}
20 {node 'rd-- 'iocs v.APP +include" da-pwm.f" node}

5/13/09 Left-brainer, right-brainer, mid-brainer, no-brainer.

I mentioned some of my thoughts about whole-brain activity while programming and was asked to give more detail and to explain how I came to make the observations about the focus on written language in our historically left-brain dominated culture and the reintroduction of more right-brain thinking in the twentieth century. I have talked about my history and my opinions before but let me provide more detail on the implications that language processing takes place in the left-brain on the mental activity that takes place when using different programming languages.

My first exposure to college at the University of Iowa and at Northwestern University was when my interest was in spoken communication. I did well and felt that becoming nationally ranked served me well later in life when I became a teacher and later a computer consultant to big corporations and needed to communicate with other people. But my interests in speech, speech recognition and the relationship between speech patterns and perceived psychological responses was only part of my interest as I was interested in how computers could better communicate with humans using speech. I programmed my first voice recognition and response systems on one megahertz microprocessors with little memory back in the seventies. So I also needed to keep up with reseach in speech, hearing, and language processing.

I took profile tests in college and was told that I was in a small group of right-brain thinkers who tend to see bigger pictures than most other people. I felt that my studies in comparative religion and foreign cultures helped me to better understand people and also served me well in later life giving me a broader understanding of why people think what they think. Training in arts with a physical component helped keep me healthy and interacting with tens of thousands of other people around the world.

The math and science studies led to engineering work starting with the first microprocessor and later to doing work like designing hardware and software optimized for AI. That really forced me to spend more time looking at research in neuroscience explaining mechansisms for language processing, image recognition, and hearing, and simulating the algorithms on digitial computers. Consider the trans-cranial magnetic stimulation experiments that shown how language use supresses vision, memory, creativity and other functions that take place on the right side of the brain in the context of the endless left-brain processed written text message discussions of programming languages on usenet that go nowhere.

As we get older and more experienced we tend to see connections between things that we didn't understand when we were younger. In my case I had spent years teaching and had taught microprocessor programming in college. I had also been assigned to teach Forth to people by its inventor, Chuck Moore, at a number of different companies and learned from that experience. Because I had been studying the art, teaching the art, studying the teaching of the art, and studying research in brain function for making better AI designs I connected up some things that I had experienced and came up with some theories about the often observed problems of communicating about Forth programming. Communication on that subject is not as simple as one might think.

My background in teaching, teaching college, teaching martial arts, teaching Forth, and working with its inventor for twenty years on Forth hardware and software is rather different I think than many other professional Forth programmers and that of Forth hobbiests and that of non-Forth programmers. My experience in researching how humans process natural language, how language limits thought far more than in the linguistic way suggested by the Warf-Sapier hypothesis got me thinking about how thought in computer programming involves use of different parts of the brain, not just the language parts.

A lot is known today about the location of specialized areas of the human brain. We know where language processing takes place, and of a balance between our use of neuronal processing of language structure and our use of something more like lists of language rules. Our DNA predisposes different parts of our brains to organize in different ways and to specialize in function. We even know of differences between the hardware in the language processing area in the brains of humans and gorillas that allow humans to have dependent clauses in the syntax of their language. Marvin Minsky described this as not unlike a context stack in a computer used in multitasking. He said that gorillas don't have this stack and that theyt can't process dependent clauses in their language. If you say to a gorilla that, "The man who climbed the mountain wore a red hat." The gorilla is likely to ask you, "Who wore the red hat?"

I very much liked the work of Marshall McLuhan in media studies in the sixties long before it became fashionable. He pioneered multi-discipline studies that challanged many people's thinking at the time. He observed the decline of literacy in literate cultures and said it was due to a shift from the (left-brain language based) linear sequential thinking of the previous age fostered by the printing press and assembly line to a more holistic (right-brain based) point of view fostered by electronic media. The telephone, the radio, and television all had their own messages and effects man and on world culture. McLuhan predicted that the personal computer, the Internet, and Google (though he didn't name them in the sixties) were going to continue to change world culture in the future. I highly recommend the film McLuhan's Wake.

He said we lived in a world dominated by left-brain thinkers. He offered right-brain ideas. People who couldn't get out of left-brain, language based thinking, had much trouble understanding what he was saying. And he used this to make his point to the people who could see that when he answered left-brain questions with right-brain answers, even when he explained that that was what he was doing, that people couldn't get it until they engaged their right-brain. It was easy to see in other people.

When someone is doing left-brain thinking their left-brain seems to regard with suspicion right-brain activity, the left-brain wants to stay in control rather than give up time to the right-brain. The left-brain tends to classify activty that takes place in the right-brain as emotional, illogical, or religious in nature to stay in control over the right-brain. Right-brain ideas often involved simultaneous parallel connections while left-brain language processing is sequential in nature. When someone working in left-brain mode gets exposed to a right-brain idea they may try to linearize it and fail. If they can't superimose the parallel idea on top of linear thinking they may say, "I don't follow that!" t

I was thinking last year about why it is so hard to explain Forth to some people and why it is so hard for some people to understand what seem to basic concepts to some other people. I am not addressing someone already being able to read and write, understand Boolean logic, number bases, analytic geometry, trigonometry, algebra and calculus or having experience with computer concepts like addressing or instruction sets and registers. I am addressing the language and non-language issues related to the art and science of programming of computers, understanding what people do, and the modes of thinking about problem solving outside of all language issues.

The most obvious example of language constrained thinking is when people engage in extensive programming language syntax comparison discussions. That sort of thing makes Forth nearly impossible to understand. When one frames ideas around syntax one might easily conclude like the inventor of COBOL that Forth is not a programmming language at all because it has almost no syntax.

When comparing the syntax of two programming languages one can only compare things that they can have in common. What is interesting is what they don't have in common. Programming languages are designed to do different things and work in different ways. Some have little notion of real time or of different time phases in the development process. Some have little notion of actual hardware while others do. Many languages assume a minimal amount of hardware and some need more than others.

Many programming languages are designed to help the programmer keep their focus on left-brain activity within the specific context of matching solutions to fixed language syntax. This requires that one assume a lot of assumptions about that context. Assumptions always assumed become so commonplace that people no longer notice them at all. McLuhan used to ask people, "Do fish notice water?"

When doing left-brain language syntax fitting type thinking one is not able to do as much with the right-brain. It is the right-brain that steps outside of language syntax limitations and assumptions about specific context.

In the martial arts you are well aware that not all intelligence or action is langauge based. You also know that language based thinking comes at the expense of use of other functions and other parts of the nervous system. I can think of many lessons and many stories about language interfering with the here-and-now.

Engage in language processing for just a moment at the wrong time and you are dead. Think of it as you should as that moron in the car next to you who is trying to do texting on a cell phone while driving. You don't want to be that moron.

Here is a an example of a small shift away from left-brain syntax processing in programming. This is someting that I have written many times and wondered if people understood what it meant with regard to language activity in the brain and its relationship to other brain activity.

Colorforth transfers responsibility in the brain for the recognition of some structural components of software and specification of time phases by representing them as color or something that is not recognized by the decoding of strings of characters in lists, an activity which takes place in the left-brain. One effect of this is that it unloads some left-brain activity freeing up more finite left-brain power for other symbolic, proceedural, and list based activity while programming. Another effect is producing less interference with right-brain activity. After doing it for some time you can feel it. But 'feeling it' is also right-brain activity that isn't experienced in the left-brain and may even sound like nonsense to a left-brain dominated thinker.

With the old essay about "thoughtful programming" one might think I advocate only left-brain programming. But one might also note that I wrote the blog entry about why doing colorforth sometimes feels more like playing tetris than it feels like programming. Reflexively reordering falling colored blocks uses a very different mix of parts of the brain than does parsing character strings for words in a list. It was designed to be engaging and fun just like Tetris.

This is not the sort of thing the left-brain normally concerns itself with, getting the idea requires right-brain activity and when people are completely focused on language or language vs language vs langauge in the left-brain they are unlikely to see what the right-brain is capable of seeing when it is active.

Even when given explantions multiple times when people stay in left-brain language analysis mode they don't see bigger picture issues that are processed in the right hemisphere. It makes it past the ears but not the left-brain.

Do some left-brain language analysis and logic. Syntax is language related, left-brain. Some programming languages have fixed syntax and you can't change it or you are not doing that language. You have to adapt anything and everything you do into the syntax of that language or it can't be done. Sometimes you have to create a new restricted syntax language for each new problem domain and leave the language of the system behind when using a fixed-syntax programming language. Things are different with extensible programming languages.

Not all forms of intelligence are related to language. There is spacial reasoning for instance which does not take place in the same location or with the same circuits as language activity. And the brain is both a cooperative and competing society with an ever shifting balance of left and right-brain and reason, emotion, reflex, sight, sound, touch, language, reason, imagination, etc. When language is very active other forms of intelligence including spacial, visual, immersive, emotional, etc. are diminished. Poetry excepted of course since it is about engaging the whole-brain in parallel ways.

Is Forth more like poetry than many other programming languages? Many people say so. But that sounds like right-brain stuff to me.

Just as Forth is much more than just a language, as a language it is about semantics and very unrestricted by language syntax. Language syntax restriction is left-brain and Forth does not require as much restriction to fitting ideas to a fixed language syntax as other languages. There are more parallel semantic links active in the brain. Syntax is more sequential and more specialized.

To the right-brain the big picture is important, the programmer is a human being with thoughts other than left-brain language syntax restricted thinking. Some languages are designed to let managers treat programmers as standard language manipulation components. Most right-brain activity is not part of the programmer's job in that context, that's the idea. More is assumed to be unchangable and focus is on smaller parts at one level of abstraction that assume context. Yes, assume all the context without thinking about doing that. Thinking about the assumptions would be a distraction there.

The idea is that if many programmers are going to be used as replacable parts to do the left-brain jobs that management takes over the right-brain jobs and programmers are directed not by their own right-brain but by other people's right brain activity. Their left-brain is free to think that right-brain activity is irrelevant to what they do if they do that kind of programming.

To shift from the narrow left-brain context of a programmer to the bigger right-brain picture of the social interaction issues taking place consider what's called "Freedom from Choice." Many people find it comforting to let someone else do all the important right-brain decision making for them because following is easier and because they won't need to feel responsible for the hard decisions. It is part of larger social trend and it is very understandable that when you ask people to look at it that they are likely to have a strongly negative emotional reaction to either this aspect of social interaction or to discussions about it.

Big picture context is mostly right-brain activity and we can consider some issues regarding it. We could classify questions and answers as being more right or left-brain based on where the type of brain activity required is taking place.

Consider from the left-brain vs right-brain thinking perspective in the classic dialog with a person who uses "C" and likes the way it lets them focus on one function at a certain level of abstraction. With experience the programmer may be inclined to step outside the narrow focus of only high level abstracted code and leave "C" to code some parts of the system in the assembler that is appropriate for a more specific context. But that's leaving "C" for assembler and I am making the point that the idea in "C" is a layer of abstraction to allow the job to be standardized left-brain symbol stringing while fitting things to the rigid syntax of a programming language.

Many "C" programmers will say that they like being able to stay focused at the level of abstraction where selecting the appropriate hardware, selecting the appropriate language and compiler, selecting the appropriate OS, and selecting the syntactic restrictions to be used when they fit their solution to the assumed restrictions is all done by other people, it is not their problem. They call it 'portability' and the idea is that the right-brain stuff gets done by others and they can focus just on programming the remaining left-brain stuff.

They complain that the problem with Forth is that it forces you do deal with both high level and low level details, left and right-brain stuff, abstract and detailed stuff. They want someone else doing the right-brain stuff and the computer's optimizing compiler to do the low level stuff so that they can remain focused on left-brain language syntax issues. They prefer the freedom to not have to do all that right-brain and low level type stuff. Just let them program!

Then the Forth programmer says that they like having the responsibility to act as the systems analyst and like stepping back to deal with big picture problems. They like this because often this is how 'cancelation' happens and how one 'avoids problems that can't be solved easily' and where they eliminate as many non-essential parts of the system as possible. But now they are talking about stuff that sounds like nonsense and outside the other person's assumed context about what is good about programming.

To people only exposed to OS written in "C" and other languages written in "C" running on processors designed to run "C" things outside this "C" hosted world might not even seem like they exist despite the fact that the vast majority of computers in the world don't run "C".

The Forth programmer says that they like like having very little syntax in their way, they like being able to choose syntax. They like being able to choose how the internals of their OS, their compiler, their editor, and all their tools work. They like that it can all be clearly in one simple language with minimal syntax. They like that it is small, on a human scale, and doesn't require a team of thousands each looking at only a tiny part of the picture.

The Forth programmer says that they prefer to use a system designed to satisfy the needs of the whole brain and intentionally designed to be 'fun' (but fun takes place in the right-brain!) They say that they like the 'freedom.' They say that by stepping back and using a bigger picture view the not only make solving the real problem easier, but that they gain experiences that will benefit them in the future, things outside fitting to a language syntax, and that it is fun, and gives them a sense of accomplishment and a satisfaction in a job well done. It is very different than the people who say computing today is all about how fast script kiddies can trash out code in the most restricted context.

When we say simple things like that dealing with 3KB of OS GUI code written in Forth is actually easier than dealing with 10MB of OS GUI code written in "C" it is like we are speaking in a language that they can't understand at all.

From the point of view of the person who wants to stay in left-brain language syntax work and enjoys not having to do all that right-brain stuff will not relate in the same way as the person who prefers minimal syntax in the language and to balance right-brain activity. The "C" programmer may say that programming is not about fun, it is not about how you feel, it is not about freedom and that all that just sounds like religion or mysticism to them not logic. They may say that Forth makes no sense if they have already made enough assumptions about "C" and try to map what they hear about Forth to that context.

To the left-brain and left-brain thinker all that big picture thinking and right-brain activity is likely to be regarded with suspicion and classified as outside the scope of (language) logic. So as soon as you start to discuss human issues involving whole brain activity and get outside the issues of left-brain language syntax issues the people who are comforted by staying in left-brain activity will see it as just illogical or religious thinking and tell you so. They can't see it the same way as more right-brain thinkers and that's the point. Attempts to communicate with them are attempts to wake up their right-brain to get it to understand the right-brain message.

Is there consensus about how the world works?

When I was a kid there were people who were exposed to only abstracted computing in COBOL and Fortran and people exposed to assembler on various machines. Today it is a more complex picture but we have a couple of generations now raised on the "C" abstraction. That's their world view of computing, "C" centric, file centric, and often Linux or Windows centric. There are a lot of people with a very "C" centric view of how the world of computing works.

Their world view tends to be that they came into a world where they were given a computer, given a language, given a syntax, and given declarations to isolate code to a level of abstraction that assumes the world is based on architectures designed to run "C", and code running on OS written in "C", and that all programming is about manipulating strings of symbols in that context. They know about that and that is the 'shared' context even if it more or less excludes all but the tip of Forth. We are lucky if they even get exposure to that. Those who spread their exposure happily over thirty languages or more in that sort of multi-language nightmare enviroment are not going to get exposure to much of the whole brain thinking behind Forth, or even any in depth exposure at all to using Forth that way.

It is not like we don't see a right-brain reaction from "C" programmers towards Forth. Emotion, and anger is in the right-brain and we see it when Forth competes and wins against "C" in systems where size, cost, and power matter most of where "C" could not simplifiy the problem enough to reach a solution at all.

The world view of traditional Forth programmers is somewhat different than that of programmers working inside a very different set of language restrictions. To them it is good to have minimal language syntax restrictions to start with and that it is good to fit the hardware, fit the language, and fit the syntax of a solution to problem on a case by case basis. It is good to have the freedom to change all those things that you can't change in "C". It is good that no OS is appropriate for all problems. It is good to be able to step back and remove unnecessary things to get to a good solution. It is good to refactor after you factor, factor, factor.

But this knowledge is not shared with a couple of generations of programmers raised on "C" systems and often herded into even more restricted niches of this "C" programming world, like Perl and the scripting kiddies. Unlike Forth programmers those people routinely tell everyone that personal computers have infinite power and infinite resources and that no one cares about program size, speed, efficiency, or even clarity any more, just about cutting and pasting from abstracted libraries. That's what they have been taught!

I also should say that that sounds more like what the psychologists who sell SUV say is the market pitch used to defeat people's upper brain activity completely and get them to respond at the reflexive reptile brainstem level. Bigger reptiles eat smaller reptiles and use personal computers with infinite resources. There are left-brain ideas, right-brain ideas, and reptile brainstem ideas.

The issue of how marketing of bigger as better is done and how it effects people's perception is also pretty much outside the common and endless programming languge syntax comparison discussions.. It can also be noted that it is not the "bigger is better" and "it has to be programmed in C" narrow thinking that leads to things like processors that are smaller, cheaper, and lower power at the same level of performance than what is possible by going down the bigger is better "C" path.

Most people who don't share any of the experience in the sort of right-brain activity usually involved in Forth programming tend to mistakenly classify people's enthusiasm for that as just religious thinking. But this is common in how left-brain tends to classify right-brain activity not just how "C" programmers and John Dvorak see Forth.

It is always hard to communicate effectively with people who do not share your world view. But there would not be much point to communication if we all agreed about everything. The idea if often to expose people to a point of view that they are not familiar with. I remember what it was like to think like a Fortran programmer before I learned to think like a Forth programmer. I remember what I thought before I tried teaching Forth to a couple of generations of students.

The bigger picture here, the simpler picture, is that left-brain activity can't understand right-brain activity but right-brain activity can understand left-brain activity. I am constantly looking for ways to get right-brain ideas to left-brain thinkers, but sometimes kickstarting their right-brain can be a problem.

For people seeking 'freedom from thought' by sticking to left-brain activity and letting others do their right brain decision making for them, and for people seeking to become a common commodity programming component in "C" "C" is more than a good thing. For people seeking more freedom of thought, freedom in programming, and who enjoy having to take the responsility for doing more whole brain thinking Forth is a good thing. People are not all the same.

Sure, left-brain dominated thinking is more common in educated society than right-brain dominated thinking today. Creativity is right-brain thinking and is less common today. The issue here is not which is more common, we know we live in a time of left-brain traditions and a resurgence of right-brain thinking.

The left-brain traditions worked for a long time. The fact that the majority of people today prefer freedom from thought makes directing them as a group easier. But we still need a minority of people who can do creative and whole-brain thinking.

Generally to make something 'more popular' means selling it as offering more freedom from thought anyway or by appealing to the lowest levels of the reptile brainstem. We live in a sea of messages about how we can buy a magic bullet that cures everything. People who like the more realistic view that Forth requires more responsibility in exchange from more freedom don't think that trying to remove the need for thinking for everyone is a good thing. It is not Forth that is being sold as a magic bullet.

But thinking can't really been removed anyway, it is just that some people will prefer to own the responsibility for all the (right-brain) thinking and do so by offering other people freedom from thought. If you are selling that, or if you are still high on the sales pitch from the most recent purchase of that and still repeating the sales pitch then you are likely to have a negative emotional response to the idea of "freedom of thought" in this context.

When you suggest to others to use their right-brain they may regard this with suspicion or even argue that you don't want them to think at all. (If they are locked into left-brain and you suggest that they should stop using the left-brain and try the right brain they may regard this as the same as your saying that they should stop thinking!) They may think that what you said was that they should just follow since they think you told them to stop thinking instead of expand their thinking outside of limited syntax restricted thinking.

These different types of thinkers have trouble communicating about many things not just about programming language issues because they start and often end with such different perspectives about how the world works and what is good or bad in it.

I could just make up some informal rules-of-thumb regarding more left-brain or more right-brain activity involved in programming:

A language that has more language syntax is more left.
A language that is extensible is more right.
A language for a specific problem domain is more left.
A more general purpose language is more right.
A langauge that can specify itself is more right.
A language that implements the OS is more right.
A language with more symbols is more left.
A language with more freedom is more right.
A language for projects with 10,000 programmers is more left.
A language on more of a human scale is more right.
A language that needs big hardware is more left.
A language for small hardware is more right.
A language that can't design hardware is more left.
A language designed for fun is more right.
If it is described by its inventor as more of a system for solving problems than a specification for a programming language it is more right.

These rules of thumb are not hard and fast (left-brain) but do have long chains of (left-brain) logic behind them and could each be the subject of much discussion. It should be pretty obvious which computer languages were designed to be more left or whole brain oriented in their use. Each have their niche.

It is hard to argue that a picture where the programmer can modify the syntax of the language and deal with source for everything, compile their OS as needed, compile their compiler as needed, or even compile new hardware designs as needed is a bigger picture to deal with than what most programmers deal with. It is difficult to argue that a programmer who assumes fixed syntax, assumes that black box components without source are going to work for them, assume an OS and all that it contains will fit the job, assume a compiler will fit the job, assume a hardware environment and that the OS, comiler and hardware all fit together with no problems and is focused on fitting a solution into the fixed syntax of a fixed language in a fixed OS with a fixed compiler on fixed hardware has given up a lot of freedom of choice and is dealing with a lot of assumptions about context. The reason for giving up all that freedom of choice is to make the work more left-brain oriented. When Perl programmers have a problem to solve what freedom do they have to solve it? Do they redesign the syntax of Perl? No. Do they redesign the compiler they use or do they use standard compiler? Do they redesign the OS they use using Perl? No. Do they redesign the processor they use using Perl? No. Do they still have the freedom to assume that all of those things are fixed and just focus of fitting a problem solution into the fixed syntax and fixed box? Yes.

On all of these measures Forth can have more whole brain activity than most other languages. After all most languages have rigid syntax, are not extensible, do not metacompile themselves, are not general purpose, do not implement the OS, have more symbols and less freedom, are large, are for compatible large computers, and exist to let more programmers do more left-brain focused work and contribute less work each to a project than what Forth is designed to let them do. And certainly Forth is not the only programming language to be more whole-brain than left-brain oriented.

Of course I am not talking about people who have other serious problems that effect the balance of their right-brain and left-brain activity. Many years ago much was learnd about brain activity by studying those people. I am talking about social trends and long term historic shifts in perspective that effect all of us.

I think one issue in regard reaction to Forth tends to be a right-brain issue; emotion as in like/dislike and love/hate. When Forth was new it was said that half the people who hear about it are neutral about it, a quarter 'love' it and a quarter 'hate' it.

If people knew the productivity and profit margin was really as high as it is with Forth as the many examples where work that could not be done in a man year of "C" was done in a man day of Forth people would have an even more emotional reaction than they do when you water it down and tell them that it was man month of Forth. early history of Forth. It isn't very safe or easy to be completely honest about Forth. Most people who market it have to water down everything you say a lot if you don't want to upset or scare some people. Other people water down the Forth they do by not exercising most of the freedom it offers and don't worry about upsetting non-Forth programmer by using Forth only as debugger or a yet another inefficient scripting language to be used 1% of the time.

I have worked at companies where management didn't know whether to believe the claims made by their best Forth programmers or the claims made by their best "C" programmers and who decided that the only thing to do was to spend millions of dollars or tens of millions of dollars splitting the money evenly and paying two teams to see real results on which they could make informed decisions. It is another thing in my experience with Forth that is probably not shared with many other programmers and we probably don't have the same experience about how the world works or having seen people do in Forth in days jobs that other people couldn't do in months, years, or at all using other languages.

So despite this just being part of Forth history most programmers don't want to face the truth about Forth. Many programmers prefer negative sound-bites to explain away Forth. That may be all many people have ever heard about Forth. The reality of Forth history (non-hobbiest Forth history) seems less believable and more like nonsense to each suceeding generation of people with experience only in segregated languages for hostile programs and who were taught left-brain programming methods for that narrow context that excludes Forth and the freedom it offers by definition.

It is hard to communicate with those people because all but Forth syntax and negative sound-bites are not part of the knowledge that has already been commonly shared with them, and syntax is just left-brain. Forth is about the freedom to change the language, the compiler, the OS or even the hardware design and is very different than programming languages that are about fitting things to a fixed language syntax in a narrow work context. Forth is something that they would much rather dismiss from what they have heard about it than understand. Forth has so little syntax it doesn't even look like a programming language to some people.

The most common thing one hears these days is, "I don't want to have to deal with anything as low as as a stack, that's why I delegate that to an optimzing compiler. I just use a compiler I don't want to understand it. I don't want to deal with anything OS, that's why I use the interface. I don't want to deal with programming an editor or anything else other than my assignment. In my world someone else selects the computer and the OS and maybe even the editor that I will use. I like a narrow focus and small picture, that's what computing is all about today and in the future!"

It is less common to hear, "I like dealing with the big picture and that's why I want to understand the low level code and want a simple compiler with optimized source. I like programming the OS layer if I can. I like programming the compiler if I can. I like programming the editor that I am going to use every day if I can. I like dealing with an integrated whole. I like having more freedom to step outside the box to find a solution to a problem. I don't think that one OS or one compiler can provide the best solutions to all problems."

To Forth programmers Forth is about being correct by design and avoiding bugs, it is about elegant and beautiful solutions. It is about learning and knowing what you are doing and not needing elaborate restrictive mechanisms to protect yourself from yourself. To some Forth programmers many other programming languages seem obssesed with making plans to perform errors and focus on mechanisms to handle the errors that they plan on as their practice. It seems that many people want to drag Forth in that direction. To Forth programmers many other programmers seem to want to make things more complicated because they need to make them more complicated and they don't understand the practice of keeping things so simple that most of the errors they plan for won't and can't happen.

I have covered a lot of ideas on history, learning, social trends, media, brain activity, language activity vs other brain activity, programming and Forth. Most of them are not my ideas and are meant to frame my thoughts on the balance of brain activity in the practice of the art of computer programming. I expect that anyone can find some idea they agree with and some they don't agree with. And I expect a few people would say that it makes no sense at all to them just as they did in the 1960s when Marshall McLuhan explained most of the ideas before Forth existed. I liked his explanations in the sixties of how these things would lead to the Internet and Google searches and how those things they mean change for the "global village."

His somewhat poetic phrases were designed to engage whole-brain understanding of some ideas. It was funny even back then to see people acting like he kicked them in the head and their emotional reaction to simple to understand phrases like global village. It was seen as revolutionary thinking in the backwaters fourty years ago. Now that we can see clearly in the rear-view mirror that he saw some important whole-brain and social trend ideas that predicted the last fourty years so well that we can continue to let them help guide us into a future where we have thought a little about where we are going.

"We make our tools and after that our tools make us." Marshall McLuhan.

"The laws of media are observations on the operation and effects of human artifacts on man and society. They are at least a hope that we can reduce this confusion to some soft of order."

His laws involved concepts like Enhance, Reverse, Retrieve, Obsolesce.

"The first question to ask of any technology, any tool, is what will this thing enhance?"

When you have spent decades working with someone who invented a very unusual programming language and then using this language wrote compilers and operating systems and designed computer hardware optimized for use with this language you think about that language and its use in a different way than most people think of their programming language. The experience in writing OS tuned to applications and in writing compilers and designing and debugging hardware is experience in a larger context than what comes up in work with more left-brain oriented programming languages especially when in a loop influencing hardware design and software design generation after generation. Although natural language limits thought artificial languages, programming languages, limit thought far more.

McLuhan said, "It's translation. It's a loop. You shape your tools in your own image and in their turn they shape you."

When you see a programming language evolve and being used to design hardware to execute the language you can see the step by step process through the loop. Using the language changes your ideas. Your new ideas lead to new ideas of how to make the language more efficient. These lead to ideas on how to make the hardware more efficient. It's a loop. After seeing the loop spun a hundred times and understanding the very long chain of logic in the reasoning and experimentation to learn the unknown the evolution in the loop is obvious. The loops in the big picture are obvious. Some people will claim that there is no such loop in programming, that software is not influenced by hardware design and that hardware design is not influenced by software design. Despite the fact that designers at Intel said very clearly that they made changes to improve the performance of "C" code once their machines got big enough to host "C" systems like Unix so long ago many people have not been able to see the loop there has been in PCs where software has been influencing hardware design and hardware design has been influencing software design for decades. My take is that understanding that loop helps understand Forth.

PCs are designed to run hostile software because they are designed to support "C" and popular operating systems with many of the same "C" system components. The idea originally in "C" was for multi-user minicomputers where one user's program may be hostile to another user's program. The whole idea is about a central control authority to police weaker potentially hostile user processes and misbehaving or buggy software.

Forth happened about the same time as "C" and was first noticed for being smaller, simpler, having better real-time performance, and being able to support more users on that same hardware. It as able to simplify and speed development software and simplify run-time requirements for the OS and application programs. Part of that simplicity was about how it was debugged and made cooperative.

When you take Forth out of Forth source, out of a Forth OS, out of a cooperative software environment and drop it into a "C" system as hostile software you then have to deal with many "C" notions that Forth was designed to avoid. But the thing that is hard for some people to see is that you have to make so many assumptions in the first place to take this path. After a while they not only don't question those assumptions, they don't notice them. McLuhan said, "Narcisus was drugged into thinking that that image outside wasn't himself, it was somebody else. Narcisus did not fall in love with his own image, he thought it was somebody else. And the same with us with our electronic technological gadgetry and gimicry and so on. We don't think that that is part of our physical organism extended out there. We're like Narcisus, completely numb."

He said, "Now when we put out a new part of ourselves, extend ourselves with technology into the outer environment we protect ourselves by numbing that area. The more I looked at this the more difficulty I had in explaining why people ignored it."

McLuhan was a man who tried to communicate many right-brain ideas to the rest of us. He used sound-bites. "The medium is the message." He tried to kick-start some people's brains and sometimes it worked. Other times people ducked and ran for cover or saw it only from the left-brain. McLuhan took things his students thought they already knew and made them take closer look at things that they took so much for granted or were so numbed to like the advertizing messages that had been all around them all their lives.

To quote the film, "He showed them that they didn't know it and that they didn't pay attention to it. And if they could pay attention to it they realized that their brains were already being massaged and that they were oblivious to this environment even at the same time that they were being almost robotically conditioned by this environment." I have felt the same way about how people are numbed to their ideas about programming being manipulated.

McLuhan wrote in the Mechanical Bride, "Advertizing is a vast military-like operation ultimately and brashly intended to conquer the human spirit. The advertizers manipulate our heads. He plays around with human beings like we are his private pigment. He smears us. Students and historians in the future will pour over our advertizing world with the sort of intensity that we should long ago have directed to it."

I feel much the same way about the programming that gets sold and about what we teach kids in school, what they take for granted, and how it influences their thinking or lack of it.

The medium is the message there too. And as McLuhan saw long before most people new tools, the personal computer and later the Internet were going to change people in new ways just as TV, radio, the telephone, the printing press, the written word, and the spoken word had changed what it meant to be human before. "The laws of media are observations on the operation and effects of human artifacts on man and society. They are at least a hope that we can reduce this confusion to some soft of order."

His laws involved concepts like Enhance, Reverse, Retrieve, Obsolesce.

"The first question to ask of any technology, any tool, is what will this thing enhance?"

"The laws of media are observations on the operation and effects of human artifacts on man and society. They are at least a hope that we can reduce this confusion to some soft of order."

His laws involved concepts like Enhance, Reverse, Retrieve, Obsolesce.

"The first question to ask of any technology, any tool, is what will this thing enhance?"

You can't express the message of one medium in another medium and I am writing text. But if you are reading it you are probably using a PC and the Internet. You can't always express the same thing in different languages but I would characterize the 'message' in the Personal Computer medium as having changed a lot from the first generations to today's Internet access and movie and game playing machines.

The first personal computers were imagination machines. The next generation were secretary's tools. The next generation were dazzling as toys or as resources linking people around the world like one big nervous system.

As this process has taken place the message the users got in each generation of machines was different. For a while the right-brain imagination got wrung out and was replaced by practical left-brain tools like speadsheets and word processing programs and databases. This was part of marketing the machines, making money, and messages being sent by the manipulators were automate, use fewer low earning people to get more work done, if you are a low earning person get more work done with automation, buy more Personal Computers and software, be better than the Joneses, consume and enjoy.

Advertizing has to be one sided. As Jeff Bridges said playing Preston Tucker in the film Tucker a Man and His Dream, "If you are selling candy you say it tastes good, you don't say that it rots your teeth."

The message in PCs has had to have a filter about certain content. I think of the PC industry much the way Tucker did about the auto industry in that film. There are a lot of things that should have at least qualified for prosecution of criminal negligance. There must be a lot of people who agree with me. Intel was just fined 1.4 billion dollars today in Europe for unlawful practice.

One strategy to deal with the PC content filter was to spin negatives as positives. Much of the PC industry is about dealing with the problems that are put in to be able to be easily improved. Many software products depend on things being absurdly buggy. On the last few new PC on which I installed software one of the first things I did was to load software to remove registry errors and spyware because accord to it the PCs come with dozens or hundreds of dangerous and malicious spyware programs installed when you buy them.

There have been two counteracting forces in the PC messages. The increasing complexity of PC hardware and software has made them intellectually impenetrable. This has turned them into what we call black boxes, like television. People could only specialize or deal with the outer surface. Imagination and creativity were fostered by the first generation because they were understandable. The marketing direction has been to foster left-brain use and that's what we have been teaching in the schools not the right-brain creativity.

Competing with that the Internet has been a strong factor for society to spread right-brain ideas. Though the mechanisms for verbal and written communication are left-brain we can also use pictures, movies, sound, music, and objects that interact with a user to engage the left-brain or right-brain. The internet offers more than access to textual content and more than multi-media content, it also offers several different communication media. Yes it is used to market things for sale but it also offers different messages than just the marketing information to buy more PCs or to buy into the lastest fashionable software trend.

The message on this page is expressed through Internet content and is Internet content but it also contains messages that are different than most other and quite different than that messages that have to censor questioning any of the assumptions about how things are or have to be that people make without even being aware of it. The message here is also about how I see things and how I came to the conclusions that I try to express here about the patterns that I have seen over the years.

1/4/08 "colorforth is a lot like Tetris."

At work I write code in colorforth for CAD code running on the Pentium and target code for target SEAforth chips. I also write ANS Forth code for tools like compilers, simultors, and code test facilites on the desktop. I write programs in ANS Forth that create more programs that generate target programs. I write ANS Forth code for embedded platforms in addition to the ANS desktop code.

All these things are called Forth but they have significant differences. The differences go deeper than things visible on the surface like standard/non-standard, preference for files/preference for blocks, desktop ASCII byte file editor/integrated colorforth color token Shannon encoded editor, qwerty keyboard mode/ Dvorak keyboard mode, etc.

For other people there are differences that are not there for me. Some people have access to excellent user manuals and reference documents for their ANS Forth but they don't have that kind of documentation for colorforth. But at IntellaSys we have excellent product user manuals and reference guides so there is no difference in that regard.

But there are differences that are true for everyone and which are probably not apparent to those who have not made it past the learning curve in colorforth to have colorforth experience of writing real applications. I was thinking about those differences the other day after doing some work in colorforth.

There are side effects of doing things in those very different ways and there were different design goals in those different systems in the first place. The inventor of Forth had said decades ago that what distinguished Forth from languages like "C" were a lot of things. For one he said, Forth is word oriented at both the semantic level and at the structure level while he said people should accept that "C" has a more byte oriented focus.

Early Forth systems were all implemented on word addressing machines, not byte addressing machines. Early Forth systems often had characters that were not 8-bit. And Chuck said that Forth was not tied to byte access while about the first sentance one will notice in the requirements for the most popular "C" compiler, GCC, is that you need byte addressing. And of course there is the assumption in "C" that source files will be bytes and will use the Operating Systems file system and file system utilites when a developer is using "C". These were not the assumptions behind Forth.

When the desktop market expanded developers embraced the assumptions used by "C" programmers and needed to adopt Forth to these environments. So they looked at what had distinguished Forth from "C" in the past, two stacks instead of one, no need for locals for with two stacks, use of blocks for source instead of "C" file system "C" style source code and "C" style source code editors, small systems with integrated OS services written in the language instead of large systems with large interfaces to the "C" program API to "C" OS services and said, "those are the problems in following "C" to the desktop."

So to make Forth 'portable' in the "C" definition sense of 'ports to "C" systems' instead of the 'Forth in Forth is the easiest thing to port' meaning of portable a decision was made to create a new Forth standard that would give up Forth's second stack, observe that without a second stack that locals become imporant like in "C", give up on source in blocks for source in "C" style files and "C" style file systems access to "C" OS interfaces, and to build large systems easily integrated into "C" environments or even written in the "C" language in the first place instead of being written in Forth.

There were other reasons for the great split in Forth history. When Chuck Moore made the lateral move from Forth Inc. to Novix, the other company owned by the same person, to make Forth hardware along with Forth software he said that he saw it as opportunity to simply Forth because he felt that Forth Inc. had developed "a corporate culture of marketing complexity."

I had been a strong proponent of the development of the ANS Forth standard and Chuck had attempted to make contributions to the standard. Chuck said all his contributions were sumarily rejected and that he concluded that a standard carefully drawn to exclude him was not intended for his use. Years later when asked why he had given up on Forth for a few years and tried the sourceless approach he said that his deliberate exclusion from the standard and the result of the politics of the committee process was so bad that for a while he gave up on the language that he had invented.

And his sourceless programming era was in a sense part of the same effort that led to Forth where the idea of less source code was tested. The sourcelss experiment was to determine whether going to the minimal amount of source code, zero, was a useful thing. He eventually concluded that it was not, explained the reasons and returned to Forth in 1996 with the introduction of the first colorforth.

The inventor of Forth continued to go in the direction of his original ideas that the power of Forth is in its simplicity and that two stacks instead of locals and blocks instead of files and words instead of bytes is what had distinguished Forth in the past and should continue to distinguish Forth in the future from things like "C". He had designed word addressing Forth chips for over a decade by this time and has continued to do that for more than a decade since and has written word oriented software from the beginning.

He saw that if he updated the inner loops of the command interpreter and the compiler from what he had written thirty years earlier that the compiler could become significantly smaller and simpler and the compiled code could be significantly faster. Simple concepts like searching the dictionary first when encouring numbers had been a technique well suited to small system thirty years earlier.

He had learned that different time frames have different costs and that it was useful to move operations to earlier less expensive time frames and leave less to be done in later more expensive time frames. An example of this was that the name dictionary no longer had to be searched on every number at compile time.

When I was programming in ANS Forth and colorforth the other day I made an observation about what I was doing and how I was doing very different things in the different environments. I remembered Chuck saying that one of the important design goals of colorForth had been fun. Fun is a difficult thing to quantize. Fun was not listed as a design goal in most languages or in ANS Forth. The goal there was to produce a specification to make Forth more 'portable' in the "C" sense of the definition of portable.

I and others had observed in the past that the replacement of some Forth syntax with color, and the replacement of some Forth words with color results in a different balance in use of different parts of the brain in a user. The part of one's brain that scans strings of characters and sorts out the semantics of words is different than the par of the one's brain that recognizes different colored objects in a color image.

And the part of one's brain that scans strings and uses the semantic meaning of the matched strings is pretty heavily loaded when programming. And I was noticing that since ANS Forth was designed to allow arbitrarily deep nesting of control structures in code there is nothing preventing words and definitions from becoming arbitrarily long other than the habit of the programmer. Source in files also supports arbitrarily long source code constructs while colorforth uses blocks that factor code into one kilobyte chucks that are presented and edited as units.

As I was factoring a new problem and writing code in an ANS Forth file as the file expanded to be larger than my screen I started having to scroll up and down to scan what I was writing and I even opened another window so I could look at one part of the program in one window and edit another part of the program in another window without having to scroll so much. I recall thinking that this is what a lot of people do in ANS Forth. They may even open dozens of source files at the same time to try to deal with this problem.

Later when I was writing some colorforth code I noticed that it was forcing me to write shorter routines. The code wouldn't work if it is arbitrarily large because it wasn't designed to support arbitrarily large control structures. This was done intentional to try to force the programmer to write more heavily factored code and to help them to avoid the problems that come from arbitrarily large control structures in code being the major source of bugs.

Chuck says if you make most of the definitions short enough that you just cannot make the same kind of errors that are typical with arbitrarily deeply nested control flow and arbitrarily long definitions. We all use the same words when talking about programming. We all say we 'factor' our code. But some people factor into ten page functions, some into code into ten line functions, and some factor code into an average of seven to ten character functions.

I recall taking a bi-phase synchronous serial input testbed routine and making a copy of it to create a high-speed single phase synchronous serial input testbed routine and making a few changes to the new routine. As I started to leave the block a colorful visual rearrangement caught my eye and I moved some code around to make the code cleaner before leaving for other work.

But then another colorful visual rearrangement caught my eye and and I quickly turned a colored block sidesways and slipped it into an open space so that it canceled out some other code and could be deleted. A line of colored code dropped away and the result was a much smaller and less cluttered screen that was obviously simply and faster code and which obviously could now accept more code if I needed or wanted to expand this function. When you only have a few lines of code removing one is a big deal. And I started to leave the block again.

But then another colorful visual rearrangement make itself apparent and I felt almost compelled to turn a colored block of code sideways, slip it in over there, cancel out that code, and watch another whole line of code dissappear again. I felt a sense of accomplishment again at a very primitive and satisfying level.

The thought reminded me of Tetris and how the reflexive turning of colored blocks as they fall into colored spaces, cancel them out, and make them go away, had been such a satisfying and fun thing for people at some primitive level that the game had been very addictive and a wild sucess. I also remembered how Chuck had said that his was about the only computer game that he had enjoyed and had found strangely addictive at a primitive level.

I thought, "Colorforth is a lot like Tetris. It uses that same part of my brain. It is fun." It satisfies some part of the reflexive brain to spin those falling colored blocks and see them fall into the spaces and cancel out the growing problem that the pile of accumulated blocks getting bigger and bigger and the free space getting smaller and smaller. When you make the free space get bigger and the problem of the growing pile of blocks get smaller it feels good.

It is fun. It was designed to be fun. It doesn't feel like work. It doesn't feel like programming when you reflexively spin the falling colored blocks and see the source code compact itself and get smaller and simpler and faster. I remember thinking that it was as fun as playing Tetris and that it was designed to try to engage these different parts of the user's brain this way to make the job of programming easier, more fun, and to get more productive results by almost enforcing better factoring.

I recall Chuck once commenting that people who say that no one cares about quality any more but only how fast people can crank out commodity code are wrong about Forth and that as far as Forth is concerned there is still a requirement for fun and for quality and that there is a sense of satisfaction for a job well done. That reminds me of the fun of watching the colored blocks spin in the air and fall and cancel out and go away and the sense of accomplishment of seeing the code sort of optimize itself to be smaller, simpler and faster.

Chuck says colorforth is a really nice Forth. If you think the "F" in Forth stands for fun then you might agree with Chuck about that. Colorforth was designed to free up cluttered code and to free cluttered minds from the problem that arbitrarily factored code is the main source of bugs and problems in programming.

As the arbitrarily factored code becomes larger and larger and buggier and buggier and harder to test it is like the pile of blocks in Tetris getting higher. It is stressful. It compounds the problem. Every time you add more code to fix some specific problem you make the problem worse. If you can't keep up with the growing pile of syntactically arranged symbols it is game over. You lose.

"What you take away is more important than what you add." Chuck Moore.

> Dear Jeff Fox,
>
> I'd be happy to hear anything about colorforth release
> features, or colorforth release dates, that has not been
> mentioned before.

I am pleased to report that Chuck remains delighted with colorforth saying it is the best Forth he has ever done. He clearly enjoys using it and seeing other people use it. colorforth has been challanged in the workplace to prove that it can be used to write code that does things that normally require software with six figure license fees. It has shown to have remarkable development times and remarkable application performance.

Chuck continues to work from a floppy based environment. He has found it difficult over the years to find new laptops that have non-usb boot floppies. Most users run from windows laptops or desktops and some have racks of computers running colorforth.

The latest release comes up with the word qwerty on the command line. That's the first thing I turn off, as does Chuck. Boy does that throw me off. I can touch type in colorforth pretty well and there is usually a menu one can glance at to keep your brain moving forward.

Things like the editor menus don't change in qwerty mode, so I can get by, but whenever I need to type a word name I have to lift up my hands and scan the qwerty keyboard to find keys because my fingers are trained to do quasi-dvorak when my brain is in colorforth mode. I tell people that it only took my fingers a couple of days to adapt to the easy colorforth keyboard instead of the years it took to touch-type in qwerty the way I can. But the need for my brain to translate from qwerty to dvorak to qwerty constantly in colorforth in qwerty mode slows me down to a crawl. So the first thing I do is turn that off.

The quasi-Dvorak keyboard was clearly designed to make it easier, and I found it did after a couple of days. But I have heard other people say that they cannot teach their fingers so they could not use colorforth. And I understand that colorforth had a lot of things that match where Chuck is going but don't match to what other people normally do (use Ascii, use qwerty, use opcodes from his chips as the Forth primitives, use color tokens etc.) It may make it easier to train some people when they can touch type word names in qwerty mode even if it is not as 'efficient' as quasi-dvorak typing. It is one less barrier to deal with.

I do like the new editor functions. Cycling through colors on the word at the cursor is nice. I think that they are waiting to have a new replacement editor all in source compatible with the new boot code and waiting to strip out the original bootstrap editor from the kernel before they release a new version.

> I would like to hear your theory on "what else might be
> discouraging people from contributing to the colorforth
> community" if you are able and willing to share here.

I think people know my opinion and I know it isn't popular in the mail list as I have expressed it before. I haven't changed my opinions on colorforth, that it is all about the big picture, forth software designing and matching Forth hardware. Pentium is a bootstrap distraction that is less than 1% of the real picture but is all that many people are focused on.

And I have said for a decade that you can't understand colorforth really without understand why it was written, the intent, and where it has been headed. You can't understand it without understanding the history and the evolution of the ideas and I still think people who jump for 30 year old Forth to colorforth without studying he history will never get it.

I see a pattern in the Forth community that is present in the colorforth community too. There seem to be two very different types of Forth enthusiasts. There are programmers, people who work with Forth systems and design/write/debug/enhance/maintain applications. To be programmers people need a working system. One percent of those people will need to spend one percent of their time doing something other than Forth programming, Forth porting. So these folks have little or no intest in the requirement that .0001 of the time needs to go into porting.

As stated in an interesting article in Scientific Amerian last year on how to become an expert in anything it takes about a decade of full-time dedicated study and work to become an expert in anything. And I think programmers who spread themselves over 30 languages would need 300 years to become expert on them. Yes they can learn a few pecent about each one and understand what they have in common. But this doesn't help much with Forth which was designed to have very little in common with these other languages. So you can learn the 1% of Forth by porting it or by using it alongside 30 other languages but no one is every going to learn to really program in Forth that way.

It is like someone who spends 30 years practicing the violin 8 hours a day 7 days a week and what they would learn seriously studying the work of masters and how that would compare to someone who taught 30 instruments in a band class in gradeschool. Yes, the person who spreads their study over 30 differnt instruments could probably play a recognizeable version of "Mary had a little Lamb" on every single one of the instruments but they could never play anything resembling the kind of music that would come from the other person.

If you ever have a chance to interview anyone who has been reviewed as the greatest violinst in the world ask them if they think that a junior high-school band teacher who can play 30 instruments equally well (or badly) understands the violin or thinks of it the same way they do. I have done it. While I haven't actually seen anyone who plays 30 instruments claim that they have a better mastery of the violin than someone with extradinary natural talent, 30 or 40 years of dedicated serious stduy, and reviews as perhaps the best in the world in what they do, but I see that all the time in Forth enthusiasts. ;-)

I see a lot of 'Forth enthusiasts' who want little more than to port Forth, most appear to not have any interest in using Forth whatsoever. They don't write Forth systems, they port someone else's Forth. They don't write much Forth code. It usually involves working in assembler or perhaps some high level language although usually not Forth. They take someone's C or assembler code and paste it in to their app, make some changes and they are done. Many claim this gives them a better understanding of Forth than people like Chuck.

I think if colorforth as a vital and living entity because it gets used to do things that it was designed to do. I am pleased to see that Chuck considers it to be the best Forth he has ever done in 40 years. I think there are people who enjoy using colorforth and who have no interest in porting it to a different computer.

Forth seems to mean programming applications to some and porting Forth or disecting dead Forth to others. And these groups don't seem to have much in common. And the porters don't seem interested in programming and those already programming don't need to port very often.

I saw Pentium as mostly a distraction from Chuck's interest in Forth. Chuck said that Pentium looks like an attempt to design a chip that would be impossible to program (meaning that people are forced to use C to deal with excessive complexity). But he had to take a little time off of doing Forth to bootstrap a Forth for Pentium until he could bootstrap his Forth development environment to his Forth chips. He put in a minimal amount of time mucking around with Pentium and was happy to put that behind him and focus on using colorforth to move forward towards what he saw as the future of Forth: cheap Forth chips running modern Forth code. Porting is an occasional necessity to some programmers but it is all there is to many enthusiasts.

I said that one could not understand Chuck's ideas without following the history of Forth from early versions through cmForth, ok, and machineForth to colorforth. I said that skipping the machineForth phase and focusing on the ugly Pentium details could miss most of the picture yet this is exactly what I saw.

People who have colorforth on a half dozen computers and run it every day are not the ones who tend to be interested in Pentium code and patches to get it to run on someone else's computer. People who want to port it, or people who want to disect it and study its internals to harvest a few spare parts for their toolkit don't seem to be interested in using colorforth. I prefer to think of it as a beautiful living thing rather than to think of it as pickled dead frog.

I work with a lot of people using colorforth. I trained most of them. The list is constantly increasing. I doubt if any of them, besides me, even subscribe to the colorforth mailing list. I think it appears to mostly be about porting old versions of colorforth or about Pentium expertise.

Chuck is where he said he would be, moving towards getting colorforth and okad running on the chips that okad was designed to design. He could not put the Pentium behind him fast enough. And instead of colorforth being a bridge to modern Forth many other people got stuck a decade behind in Pentium details.

My colorforth code is about 90% SEAforth colorforth code and 10% okad colorforth code and 0% Pentium code. I work at the colorforth level on Pentium or SEAforth. They are roughtly equivalent except that there is a huge difference between the colorforth abstraction level and the Pentium hardware level but an almost one to one correspondence between SEAforth colorforth abstraction level and the SEAforth hardware level. This was the idea from the beginning. And if anyone got stuck at the Pentium porting level without following up on the whole reason for colorforth in the first place I think they have the problem that their thinking will be twenty or thirty years behind the logic behind colorforth.

Pentium coding requires a massive expenditure of effort to understand Pentium, pretty much a full time job for anyone who wants to try. I have only met a few people who seem to have a very good grasp of Pentium details. I think there are fewer who understand Forth. And almost none who get both.

Colorforth users are elevated above that level and for the most part don't need to drop into Pentium assembler except to optimize any significant bottlenecks in apps. And we have seen so many times that a good optimizing compiler or hand written assembler can make your code run several times faster, but a system that lets you experiment easily may produce code that runs hundreds or thousands of times faster. And it is all about the use cycle, not the porting cycle.

I think that the people who are using colorforth have the impression that the mail list is mostly about 'porting' antique stuff and that's not what they do with colorforth. Other people were unable to run early colorforths and became interested in taking them apart and porting or studying them. And there is nothing wrong with that. But it just has nothing to do with full time users.

One learns one set of things about frogs from studying them in their natural environment or by getting a doctorate in zoology and specializing in frogs. And people who spend an hour disecting a dead frog in a pan of fermaldahide in a biology class learn something else about frogs.

It is like the difference between a chatroom of users using a product and exchaning information on how they solved problems in using it and the sorts of discussions that take place in say c.l.f where people who don't use or program in Forth post pages of opinions about 'Forth programmers' every day. Although the colorforth mail list has been pretty good regarding bandwidth devoted to opinions about colorforth and has been focused on porting details and application code.

Most Forth programmers don't bother reading what the very confused 'almost-programmers' in c.l.f say about Forth. They are in constant dialog with other people who are using Forth and for the most part none of them engage in the porting and theory discussions that take place in c.l.f.

I think users don't care much about what non-users think because it is irrelevant to them. Non-users don't care what users think because it is irrelevant to them too. These two groups can get rather hostile towards one another. Even the colorforth chatroom seems to me to be dominated by comments by people who seem to hate Forth. I found the same sort of nonsense and hate speech there that is common in c.l.f, basically Forth programmers get insulted there by non-Forth programmers or non-programmers.

So I could post a lot of colorforth code. It is code that I like and that Chuck likes, but I have the impression it doesn't interest the colorforth maillist subscribers because it isn't about Pentium ports and Pentium patches and getting an antique Forth running on some old computer. 90% of my colorforth is simple, SEAforth code.

Sound input? Great I have drivers.

Sound output? Great I have drivers.

High quality sound? Great.

Video drivers? Great.

Communication protocols? Great.

R/F input? Great I have drivers.

R/F output? No problem.

But my code is colorforth for SEAforth. That was the whole idea behind colorforth in the first place.

My PC can already do sound input and sound output and I don't need colorforth to do that. I do have an interest in sound applications and I could write them for the PC using colorforth. But I would prefer to do sound processing with something more embeddable, cheaper, and lower power, and higher performance than a mere PC. That's why colorforth exists.

So Chuck says that his small programs are a little smaller than yours, but that his big programs are a lot smaller than yours. And sure you can replace a K of code in your system with less colorforth code. But the real value of colorforth is when you can use it replace a few gigabytes of other code with a few kilobytes of colorforth source that you can control.

Chuck has been adding more and more SEAforth colorforth code and is well on his way to get colorforth on SEAforth. That's step one into getting okad on SEAforth instead of on the dreadful Pentium. This has always been Chuck's interest and the purpose of colorforth, to get away from the dreadful Pentium as fast as possible. Although that bootstrap period seems to be about 15 years. And Chuck is moving past that phase while most other people who say that they are doing Forth are in my opinion just duplicating a small fraction of small fraction of his work from 30 years ago or from 15 years ago.

I guess I feel that I could say that if it isn't solving a significant real problem in the real world it isn't really Forth. I think it is a little like Chuck saying that if it isn't a hundred times smaller than C it isn't really Forth. I might combine the two things and say that if it isn't doing something that is impossible in C it isn't Forth. Those who only live in the small area where Forth and C/Forth hybrids overlap simply can't understand that most of Forth is outside all that.

OK, IntellaSys has a couple of people who are working at the Pentium level in colorforth, adding system functions or optimizing application bottlenecks. But most users stay at the colorforth level writing cad code or SEAforth code to solve real-world problems, they program...

c.l.f is simply not an option for colorforth discussions. There is little activity in the colorforth mail list and the chat room is dreadful. Most of the activity in the mail list is about versions that are very old to people who get a new release once a month so they have little interest in what patches people have added to versions that are years old. But at work there are lots of people working fulltime in colorforth.

Meanwhile things that are different are happening with the application. In the windows environment you have access to icons and windows functions. And enchancements are possible that were not present on the original bootstrap floppy versions.

If you click on some word a window may pop-up with a video of Chuck explaining the feature in detail. And people who are working on that sort of thing don't seem to show much interst in the problems of people who can't boot an antique floppy version on an incompatible antique computer.

All in all the problems with colorforth are really no different than the problems with Forth. There are professionals who work with it full time and work with other Forth professionals full time. And they have access to a lot of information and they have very different experiences and knowledge than people who can't get colorforth to boot.

One of my favorite examples was that one notable colorforth enthusiast who had spent years studying it, disassembling it, reassembling it and modifying it, and made a lot of public comments about it, but had never bothered running it and in two years of 'study' had not been able to figure out how to do something in colorforth as simple as:

1 dup +

I have seen professional programmers with no background in Forth get training in colorforth and start delivering new impressive applications written in colorforth the next day. I have also seen people who dabbled in Forth for decades spend years working with colorforth and yet never learn to add one to one in the language.

So I don't think people who program in colorforth every day have much interest in reading what people who have not been able to boot colorforth or have but have spent years without getting as far as being able to enter a 1 number from the keyboard to the Forth command line in colorforth think about their experiences of not using colorforth, or about what colorforth has in common with their Perl or C code or antique Forth code.

And people porting colorforth seem to have little interest in what it does, how it is used, or what people using it do with it. But some spend years doing an autopsy on dead code that they don't even run.

Live frogs are just very different than dead frogs.

How does one master Forth? An interesting article by Philip E. Ross appeared in the August issue of Scientific American titled, "The Expert Mind." "Studies in the mental process of chess grandmasters have revealed clues to how people become experts in other fields as well."

In reading the article I was reminded of a lecture by Marvin Minsky on the subject of how people learn and what constitutes being an expert. I was reminded of my own decades of studies in various fields and in the words of my own teachers.

"Effortful study is the key to achieving success in chess, classical music, soccer and many other fields. New research has indicated that motivation is a more important factor than innate ability."

The common wisdom to becoming an expert in anything is 'Practice, practice, practice." But as I was often reminded by my teachers, practicing an error over and over just makes it habit. What is required in addition to motivation and effort is focus. And we should probably consider that there will likely be a contrast between the common view and the expert view.

There are examples throughout history of the giants who had to work out the first principles in new fields and upon who's shoulders following work was built. As a body of knowledge progress people can build on the knowledge derived from the work of previous masters in the field.

The practitioner of any art or any person seeking to master any field will seek out either the work of previous masters or the actual guidance and council of a master in the field they wish to study. Their own intention and motivation is directed and guided with effort to focus on the important details to be studied to make the progress requried to master any field. Most people are motivied at first and make considerable progress as beginners in a new field, but considerable effort and focus distinguishes those who achieve the mastery that few achieve in any field. Most people reach a plateu at the limit of their own unaided ability to learn in a self-directed manner or at the limit of the skill of their teacher. Students who become masters are often told by their teacher that they have outgrown the teacher and need to advance to directed study under a master with a different mastery.

What does it take to become a master? As Marvin Minsky told us so long ago and as noted in the recent Scientific American article the distinction between an expert in a field and the rest of us has been studied and quantified. We understand things in 'chunks' which are sort of like facts in a specific context of experience in problem solving. We accumualte knowledge in these chunks and when we have accumulated about 50,000 of them we are considered to be 'an expert' in a field by other humans.

"The 10-year rule states that it takes approximately a decade of heavy labor to master any field."

The great strength and weakness of Forth for those of us who did not invent it is that it seems so simple. It seems so simple that many people, like myself, reported that when I first encountered Forth I really felt that I understood almost all of it in about 3 minutes. After a decade of doing a lot of Forth and a lot of other languages I had accumuated a few years of study in Forth and considered myself an expert. I had passed some of my first teachers in my understanding of Forth but had found people who clearly knew much more than I and began my serious study of the subject.

Having had experience with the tradition of studying under Zen and martial arts masters I had much the same dedicated self-sacrificing focuses effortful study that is required to achieve the kind of results that warrant the efforts of an established master to mentor or tutor one in a field. The degree of effort required to master a field is not something that is well understood by the average person who does not have and does not want such an experience.

I had fifteen years of professional programming experience split pretty evenly between assembler, BASIC, C, Pascal, and a variety of scripting language environments. I was a successful professional in my field and accumulated an above average body of knowledge, chunks of knowledge about programming. I accumulated a few years of experience at most in each language.

In the mid eighties I became very interested in the new Forth chips that had been build by the inventor of Forth and in the new Forth software that he had written for them. I bought some, programmed them and did several projects. I designed and built a prototype Forth engine multiprocessor laptop. In the nearly twenty years that have followed I have worked almost exclusively with the Forth language using and writing Forth compilers, libraries, Operating Systems, development enviroments, simulators, emulators, cad programs, GUI, test systems, Internet protocols and Internet based applications like browser and email clients. In Forth, on Forth, under Forth, for Forth, developing and using almost exclusively Forth software and often Forth hardware.

I have also had the opportunity to study directly under the inventor of Forth, Chuck Moore, for over fifteen years and to have been guided and assisted in my study of Forth by other well known Forth professionals and masters. I began with an introduction to Forth and mostly used it as a portable monitor/debugger on new computers or with new programs or as a scripting language layer on top of some system. One can be easily lured into understanding that much Forth in fifteen minutes and thinking you have mastered the language.

When I engaged in directed study of an art from a master I found that I had to start over. It was the old parable of the teacup needing to be emptied. I was full of my own expertise and needed to be able to see with the fresh eyes of a beginner and feel that need to make the effort to change whatever needs to be changed in yourself to achieve mastry of your art.

Though traditionally a student does not 'argue' with his master, he may engage in dialog to work towards an understanding. In the case of Mr. Moore and myself I was usually defending the rational behind the ANS Forth standard effort and in the common practices at the time. I could trace what I had been taught back through my teachers and their teachers and of course back to Chuck Moore eventually in the case of Forth. And I could see how each person had added their own understanding and filtered out the parts of what other people were doing that was not compatible with what they were thinking.

I often found myself very challanged and suprised to see that I had been completely wrong about so many things that I really had though I had understood and mastered in those years when I had part time exposure to Forth. I often did not learn what I expected to learn and I observed that Mr. Moore did not always learn what he expected to learn. I observed that he was less sure of exactly what Forth was and what it could do than almost anyone else and was willing to try as many ideas as he could to find a solution while most other people had very narrow definitions for what they considered Forth.

As my teachers in martial arts had always reminded me I had to make and effort to keep 'beginner's mind' and be open to new ideas. I understood that thinking that you understand an art is usually the point where you stop learning and advancing and being just practicing your bad habits.

To a casual game player it might appear that chess and checkers and other games with a similar board have a lot in common and that skills at playing one board game should be pretty transferable to a different game. But academic research in chess, 'the Drosophila of Cognitive Science' as Mr. Ross puts it, has clearly shown that chucks of knowledge about chess are not the same as chunks of knowledge about checkers or other board games.

Programming languages have some things in common. You can write a 'hello world' program in any language. Programming language shave some things that distinguish them from one another the way checkers and chess are different. To the casual user, or a person who's expertise is limited to things like 'hello world' applications that can be written knowledge of Forth has a lot of common chunks with knowledge of other programming languages.

But you get a different view when you talk to the people who have accumulated sufficient chunks of knowledge specific to Forth, the things that distinguish it from other forms of programming, to be considered masters of Forth. These people know that like chess you have to have experience with Forth to become a master of Forth. And the rule is, it takes about ten years of doing focused effortful study in Forth to approach mastery.

If what Mr. Ross says in the Scientific American article is true the effort which must be expended in purposeful directed and focused study is more important in creating a master in a field than inate ability in the individual. Even so I might note that most the Forth programmers I know seem to be in the top two or three percent in intelligence profiles in addition to having invested a considerable effort into the mastery of Forth programming.

All of this is in sharp contrast to the modern American 'instant culture with instant gratification' where the rule seems to be that anything that is hard isn't worth doing. Forth culture is one that abhors black-boxes and hidden details and values the simplicity, clarity, and a complete understanding of hardware, software, algorithms and problems solutions. The strength of Forth has always been to many people that it is both grounded a what people call the lowest levels of simple mechanical operation and extends to whatever lofty level of abstraction is desired. And that contrasts the trend to provide an abstracted-only view of computing in which almost all the details can be hidden from users who can either be unskilled low-cost labor or can be easily controlled by computer systems that they don't understand.

There are people today who brag about spending their 2000 hours at work a year spread out evenly over administration, programming and documentation. They may brag about spreading the 700 hours a year they spend programming over as many as thirty different programming languages.

This should be amusing to Forth programmers considering the history of Forth as an escape from the 'multi-language nightmare.' How much more of a nightmare today where people have thirty different specialized programming languages putting them into a much more elaborate maze than could have been imagined fourty years ago?

I always used to tell my students that they should factor in that being human they would forget some of their training. I told them to expect to forget about one hour's worth per week. So if you put two hours a week of effort into your study you will accumulate about one hours worth a week. In a year you will accumulate about fifty hours worth of study. And research tells us that that is about a hundred chunks of expert knowledge. I often reminded my students that if you stay near the threshold of forgetting in your study that you will not make much forward progress. If you put in one hour a week you will never go beyond the beginner level. If you put in three hours a week you will make twice as much progress as if you put in two.

And of course, if you want to master the art expect to accumulate at least fifty thousand of these chunks. If you accumualte 100 a year you would need to live to be five hundred years old to master your art. Those who want to master their arts often put in a hundred hours of work a week for many years to get enough chunks to do what masters do.

Those who tell you that programming in 30 language will help you master Forth are problably aware of what Forth has in common with those 30 other languages. If they had a few hundred years they might be able to also learn what makes Forth different. But as many of those folks seem convinced that the best way to learn Forth is by using other programming languages I have my doubts that they will ever learn more than about 1% of Forth.

Not everyone wants to seek out experts who are so far beyond your skill that to them you are a rank beginner to study from them. It can be quite a humbling experience. If your teacup is full, if you are already 'a master at a glance' you will see no benefit for the sort of effortful and directed study that scientific research has shown is what makes masters.

I have always told people that some arts can be studied in a self-directed way and some can't. In most cases if you are truely serious about study you need to look for masters until you find one who you can relate to and who is willing to teach you. Then you need to suffer and bleed. I recall a dance teacher telling us that any day we didn't bleed we were wasting his time and ours.

The only way you will ever really master anything is if you spend a good part of your life at it which would be a great sacrifice were it not the thing you love. Those who like Forth because they think it is something you can learn in fifteen minutes seem to dislike the idea that some people think Forth is something that is that hard to master. Those who have made an effort to master Forth dislike the notion that Forth is just that thing you can learn in fifteen minutes.

My problem with your FAQs is the assumption that the greatest bottleneck is always that there will only be one Central Processing Unit. Parallel processing is all about not having a single "Central" Processinng Unit. Here is a clip from a fairly typical FAQ on microcontrollers on the subject of interrupts:

"The advantage of interrupts, compared with polling, is the speed of response to external events and reduced software overhead (of continually asking peripherals if they have any data ready)."

The FAQ is saying that a single Central Processing Unit can't do something simple like read a pin in a loop efficiently. It says that the real problem is that if there is only one CPU and it does more than one thing, then the delay in responding to any given event could be the sum of the time required to respone to all events. So when a loop does more than reading a pin and looping waiting to process the event it is slower than the minimal poll loop.

Interrupts require extra hardware and extra software. We used three interrupts to support use of the Forth processor by the realtime IO coprocessors on the UltraTechnology F21. When a hardware event occurs there may be a delay before the CPU can get to processing the event due to interrupts being disabled either explicity or automatically by some sequence of CPU instructions. When an interrupt happens the machine will save a minimal amount of information and be vectored to an Interrupt Service Routine. This routine will then save any other required state information. Then the routine begins to execute the code that actually does whatever service the event requires.

Take a look at any microcontroller or microprocessor and count the number of CPU cycles or memory cycles involved in all of that. On more complicated CPU it may be difficult to predict in any deterministic way how exactly many cycles it is going to take. Particular instruction sequences or those that explicity disable interrupts, cache misses or pipeline stalls caused by interrupts may require many unplanned cycles.

The common sense knowledge that everyone has, and what one reads in the microcontroller FAQs is that microcontrollers need interrupts to repsond to events quickly. I work with designs that don't have interrupts. They can have very fast poll loops. I can read a pin, test it, and loop or respond in six nanoseconds and that is with a very cheap processor. But people know that an interrupt and all that extra hardware and software would make this faster, but they are wrong.

We use a pin-wake up circuit or message wake-up circuit. It is similar to an interrupt, but it isn't an interrupt because all it interrupts is sleep. The processor reads a pin and/or message port and goes to sleep waiting for an event, other processors will handle other events. The processor is awakened by an event and begins processing that event within a few picoseconds.

A temporarily assigned and dedicated processor can be used to poll or to sleep and be awakened by a signal on a pin. It will be much faster, cheaper, and lower power than a single overburdened and interrupted CPU. Where one has power to program function blocks with multiprocessor synchronization down to the instruction level one is not constrained in the way the FAQs say that embedded processor designs are constrained.

There seem to be two major schools of thought on this. One uses a language that was designed to write a pre-emptive multi-tasking multi-user Operating System to run possibly ill-disposed and uncooperative programs. The other uses a language designed to avoid those typical OS problems and use cooperative hardware/software and cooperative multitasking with cooperative programs. How and why do hardware designs assist with the problems of locked, insoluble, contrary, obdurate, recalcitrant, uncooperative, or unruly software?

I recently asked a question in comp.lang.forth, "hardware errors, do C and Forth need different things in hardware?" I listed ten examples of how simple Forth language programs work in a simple and cooperative manner. I expected that some people might say that they were actually errors that needed extra hardware to correct. Is it just a case of what we see as what makes cooperative hardware and software easy being exactly why people with uncooperative software see it as a bad thing requiring extra hardware and software?

Yes, it is a lot like a Volvox Supercomputer. But instead of 2048 10mip nodes one of our prototypes has 24 1000 mip nodes. The hardware channel links are a thousand times faster, and we can use any normal external memories, and we have standard communication protocols between cluster chips, and our individual processors are about too small to see, and they consume no power when sleeping and very little when running, and it has on-chip io, and it uses some cleverness to get picosecond and nanosecond response to realtime events, and it will be used in embedded products, and it will be used in rf apps, and it will cost a lot less than a Volvox supercomputer. But other than that, it is a lot like a Volvox supercomuter in a scalable network of supercomputers.

Portable electronics are more popular and people want more battery life, and smaller size. Also heat is the big design problem on the high end. Heat comes from burning power.

Going to smaller transistors means lower voltage but higher frequencies raises power. So designers use adjustable clocks and power control circuits that shut down unused parts of a chip. Smaller transistors also typically means more transistors and more leakage current too.

AMD had a recent presentation about the problem where they showed that with overclocking they got a 20% speedup at a cost of a 70% increase in power, then they tried two cores and got a 70% speedup with a 2% increase in power. Which would customers prefer? This is why Intel, AMD, and so many other companys say the megahertz wars ended at the submicron heat wall.

PCs used something like 50 billion dollars per year worth of electricity a decade ago, and here in California the cost of electricity went up about an order of magnitude. That equates to a lot of money we have all paid up front and alot more money to pay in the future for all the polution and greenhouse gases released by the burning of hundreds of billions of dollars worth of fuels to power PC.

I built a laptop with a NOVIX and a solar panel in 88 and it would run 24/7 if it got some sun every day. The idea of F21 was that it would be ten times faster, and a hundred times cheaper and lower power so that the same cheap solar powered or hand cranked laptop could have much more computing power with more computing nodes.

F21 coprocessors could be turned off or on and the power they used depeneded on what they did and at what frequency. Outputting a white pixel took much more power than running the CPU. There was a register to control memory speeds at a given voltage, and lower voltage meant a slower clock and lower power consumption. By lowering voltage to as low as 2.6V power consumption could be kept as low as sleep mode on many processors while it polled io for events upon which to raise operating voltage to perform real processing. It was kind of a trick but it worked to manage power.

With smaller geometry we planned to add RAM and ROM and put more processors on one die to increase speed and reduce cost and power consumption. Pins are expensive and draw power. Pads that drive pins are absolutely huge compared to computing transistors! (I mean pins are expensive relative to computing circuits and cost about a cent each on an F21 package. I was not referring to how adding one more pin to the F21 design would have cost me an additional $10,000.00 on each fab.)

I find it a strange notion that pins and processors are both getting smaller and cheaper but that small processors are getting smaller and cheaper faster than the pins and could be cheaper than pins in designs before too long. It reminds me of my physics instructor saying in 1971 that microprocesssors would someday be cheaper than mechanical switches and copper wires. What is not so hard to picture is that even on the big processor side of things multi-core can reduce the power consumption problem. Pipelining and multi- threading parallelism work up to a point then have diminishing returns.

One can find countless pages on the web explaining Amdahl's law for the speedup of parallel computing compared to serial computing. Speedup is defined as the ratio of time required to do a computation serially divided by the time required to do it in parallel.

Speedup = time_serial/time_parallel

If p is the number of processors and q is the ratio of parallel code to total code then

Speedup = 1/(q/p + (1-q))

So the law says that if all the code is parallel then q is 1 and 1/(1/p +0) and speedup is p.

So it says that if code is 100% parallel then p nodes will give p speedup and that the limit in theory is linear speedup.

Examples are given where q is low, and examples where speedup is greater than p, superlinear speedup, are dismissed as cases where more cache on more nodes meant more of the problem ran in cache. Real superlinear speedup, speedup greater than p, is all about the algorithm. As more people look for parallel algorithms to take advantage of parallel hardware more people will see more superlinear speedup the flaw in Amdahl's law for parallel speedup.

April 30, 2006, What's in a name?

Intelasys becomes IntellaSys after an agreement with Intel.

I hadn't realized that Dick Pountain had been involved in the Transputer though I knew of some of his connections to Forth. Marcel Hendrix provided some interesting history of tForth with some Dhrystone benchmarks comparing the 20MHz Transputer to a 33MHz 386/387 in comp.lang.forth recently. There were some comments about the Archipel Volvox computer which had 2048 Transputer nodes. I still tell people that they should study the Transputer if they want to understand parallel ideas behind F21: boot from a network, integrated multi-tasking/multi-processing, scalability, hardware support for channels etc.

The T800 Transputer added floating point hardware , but was an order of magnitude slower than F21 on integer and drew an order of magnitude more power. The Transputer did have on-chip RAM which was nice, but external memory required expensive TRAMs while F21 could work with a wide range of ordinay $1 memory chips. The Transputer had no IO except its proprietary links while F21 had a proprietary network for links, and a video IO coprocessor, and an analog IO coprocessor, and a parallel port, and a realtime clock, and an interrupt controller etc. So one could use an F21 like a Transputer and also take advantage of built-in IO hardware to treat an F21 node more like a PC with programmable video io, programmable sound io, programmable modem io, programmable network io, and parallel io subsystems in addition to the CPU.

Chuck's Sh-Boom had been getting 80 MIPS in programmable logic before the Transputer came out so the Transputer was really quite a step down compared to the performance of even early Forth chips. I like the idea of that 2048 Transputer node Volvox computer, but I wonder how much it cost and how many kilowatts of power it needed to be able to deliver twenty thousand mips.

A google search on the Spring Microprocessor Forum in San Jose yields up lots of references to the keynote speaker, Chuck Moore, Senior Fellow at AMD, and architect of new multi-core designs. Old press releases reported that AMD licensed technology developed by a different Chuck Moore, inventor of the Forth programming language turned chip designer. That Chuck Moore, CTO at Intelasys in Cupertino, will be speaking at the Spring Microprocessor Forum about new multi-core designs. I expect that at least a few people will be confused by the presence of more Chuck Moore than they expected.