Re: advantages of forth over other languages

Bruce McFarling wrote:
> Note that for this, a pattern language that is "good enough" to allow
> people to talk about their design activity, and is widely understood,
> is superior to a pattern language that is "ideal" for a particular
> design activity, but is not widely understood.

I'm not sure how to interpret this.  I'm reading it as a concern about 
the structure of design patterns.  Do you think that design patterns are 
in some sense too complicated?

Design patterns (at least as they apply to computer science) are nothing 
more than documentation that provides a name, an intent (goals for the 
pattern), context (where the pattern would be used), and discussion. 
More formally, design patterns have a common recommended structure to 
them.  The Wikipedia article on design patterns gives a good overview of 
the usual sections found in a design pattern:

http://en.wikipedia.org/wiki/Design_pattern_(computer_science)#Documentation

Not every section is necessarily important, and many times, these 
sections are nothing more than a single sentence or a list.

> That is, after all, was the rationale for a Scientific Interactive
> Command Language with Forth as its assembler ... something that looks
> much like a common pseudo-code but can be interpreted, incrementally
> compiled and run, and that when you crack the hood allows you to get
> as close to the metal as the host Forth allows ... which for many
> hosts would be quite close to the metal indeed.

Again, I'm not sure what you're addressing here.

A design pattern is not pseudocode.  The purpose of pseudocode is to 
describe abstractly an implementation.  The purpose of a design pattern 
is to describe abstractly a design.

The difference may be clearer if I take a specific example.

One common pattern is "Chain of Responsibility" (COR).  The basic idea 
in COR is that you have some notion of a command and you pass this 
command on down through code that either acts on the command or passes 
the command on to other code that can act on the command.  An example 
might be a help system in a GUI.  I might point my cursor to some 
on-screen element and issue a "help" command.  The system using COR 
would then pass this request for "help" up through the hierarchy of 
controls on the screen.  So I might point to a number, and ask help.  If 
that control didn't have specific help, it would pass my help command up 
to it's parent, which might be a frame.  If that frame didn't have a 
specific help command, it might pass it up to it's parent.

That, in a paragraph is the essence of Chain of Responsibility and 
that's where the design pattern effectively stops.

The programming looking at this may next need a suggestion of how to 
actually implement this.  This is where pseudocode might come in.

given a command:
     if the object can respond to command:
         do command
         end
     else
         if object has a parent:
             pass command to object's parent
         else
              end (command not handled)

The difference between the design pattern and the pseudocode is that the 
design pattern is more abstract and thus can be applied to a larger set 
of problems.  The pseudocode is making an explicit requirement that 
we're dealing with objects that have a sense of their parent.  This 
wasn't required by the design pattern.

Now, one could certainly look at the psuedocode above and be able to see 
how the basic idea might be applicable to a wide variety of things.  You 
don't need objects with notions of parents.  You could express the chain 
as an array-- passing the command through an array of handlers for the 
command.  Or you might have a system that didn't have lists or arrays 
but some kind of dynamic discovery of how things are connected in a
system.

But in that case, one is taking pseudocode (which is more tightly 
coupled to a particular implementation) and generalizing it-- arriving 
at where the design pattern started.

Or put another way, the best design patterns tend not to come from 
people sitting around thinking abstractly about a problem, but from 
observing actual real systems, identifying the common ideas, and the 
abstracting from there.  Indeed, if a design pattern didn't start this 
way, it's probably suspect.