John Passaniti wrote:
> 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.
Actually, what I meant by "I can't say" above is that I completely agree
with you -- it depends on the cir***stances. In addition to the two
very valid scenarios you describe, other common ones here are, "I want
to re-write because it helps me understand the problem better" and "I
want to write a Forth version to get more practice with Forth."
Cheers,
Elizabeth
--
==================================================
Elizabeth D. Rather (US & Canada) 800-55-FORTH
FORTH Inc. +1 310-491-3356
5155 W. Rosecrans Ave. #1018 Fax: +1 310-978-9454
Hawthorne, CA 90250
http://www.forth.com
"Forth-based products and Services for real-time
applications since 1973."
==================================================
|
