UltraTechnology Blog
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 write 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 cuulture 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 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.
Sept 28, 2007, "Forth Enthusiasts are not all the same."
> 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.
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?
Speedup = time_serial/time_parallel
If p is the number of processors and q is the ratio of parallel code to total code then
So the law says that if all the code is parallel then q is 1 and 1/(1/p +0) and speedup is p.
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.