Re: Elegant code Was: Re: what kind of non microconroller app are

Gerry wrote:
> Contrast this with the typical Forther approach of doing the whole
> thing from scratch, e.g. Jonah developing code for text recognition -
> a problem that is already solved by a general purpose lexical scanner.
> This of course results in more concise source code, faster code etc.
> but probably takes longer to develop.
> 
> Which is the best approach, I don't know, I suppose it depends on your
> point of view, but I know which I prefer.

Actually, what is the best approach has little to do with one's point of 
view.  It has to do with requirements.

I come to you and say, "I need code to execute on a platform that is 
very resource limited.  You have a relatively slow processor and data 
coming in at a constant rate that can't be dropped.  We want to ****p 
this in a couple months."  These requirements suggest a "from scratch" 
implementation, maximizing space and time efficiency, and eschewing 
abstractions.

Now I come to you and say, "I have a few megabytes of data that I need 
to extract some features from.  The data I care about can be described 
as a grammar, and the processing I need is some pretty basic statistics. 
  Oh, and I need this tomorrow."  These requirements suggest reusing 
existing generalized tools, working at a high level of abstraction, and 
not worrying about space and time efficiency because it's far more 
im****tant to get an answer quickly than in having the most elegant code 
possible.

Where I work, this kind of dynamic range between projects happens all 
the time.  And so it demands getting out of the mental trap that there 
is a general best approach.  It's certainly possible to say that a 
particular approach is best for a specific context, but to suggest that 
can be generalized is usually evidence that the person making the claim 
has limited scope.  (And here in comp.lang.forth, this is also often 
evidenced by how dogmatic the person is about the claim.)

So getting back to Elizabeth Rather's description of Charles Moore's 
approach (solve only the problem in front of you, be direct, avoid 
unnecessary abstraction), she stated that she couldn't say if that 
approach was good or bad.  Okay, I'll say:  It's exactly the right 
approach for cases where it makes sense, and exactly the wrong approach 
for cases where it doesn't.  Shocking.  This will require people *think* 
not just about the problem being solved, but the appropriateness of the 
approach.