Doug Hoffman <no.spam> wrote:
> It appears to me that this thread has lost its way. What started as a
>
> discussion of how to attract newbies to Forth has turned into a
> discussion of how to design graphics packages. Thread drift at it's
> best! ;-)
Still about how to attract newbies.
> "A better approach is to concede that named locals is a perfectly
> acceptable approach to programming in Forth. Many Forths with
> optimizers will actually produce faster code with locals than with
> stack gymnastics."
>
> This lead to some debate about the (supposed) problems with locals.
> Interfered with factoring or something, not entirely clear here.
What good is it to get newbies to use Forth if they write Pascal in
Forth? They might as well write Pascal in Pascal. I'd want to get
newbies learning a Forthlike language that give them Forth's advantages.
The problem with locals is that if they don't already have the Forth
concepts they can squeak by without getting them. Locals let them write
mixed-up Pascal.
Instead of writing A := B + C they can translate to B C + TO A . It's
the same thing but less readable. Why bother?
> Jonah tried an example to demonstrate the problems with locals and
> factoring and found that he actually improved his code somewhat with
> locals. And I respect his honesty for admitting that.
Well, but it was bad code, and it improved a bit with locals. When I
improved it by factoring most of the value from locals disappeared.
> Reader: "Gee Leo, in Thinking Forth when you were discussing how to
> design graphics packages to draw a box you sure picked a loser for a
> line drawing primitive. We can think of much better primitives. See
> page 204."
>
> Brodie: "I don't know what you're talking about. There was no
> 'graphics package' being discussed there. I was simply using the box
> drawing as an example of a dilemma one can have with the stack and how
> local variables can help. I could have chosen anything for an
> example, such as a parabolic equation or a motion equation!"
To me, the fundamental Forth idea is to break complex problems into
simple pieces connected simply. You have to think to do that, but once
you get it right then you can keep it simple.
And using stack operations works partly because it gives you a strong
hint when you're failing to do that. When the coding turns into a
mountain of glue or a mountain of glass, it's a sign you haven't thought
it out well. When you need to handle too many items at once it means
you're still making a mistake. There might be solutions that can't be
broken down into simpler pieces. But I don't want to assume too quick
that's true just because I haven't done it yet.
A parabolic equation? y = ax^2 + bx + c, compute y? Start with the stack
items in the order you need them. That might be the way they're easy to
get, or you can juggle them into position first.
( c b a x )
We'll use x twice, so we save it.
DUP >R \ c b a x R: x
* + \ c (b+ax) R: x
R> * + | c+(b+ax)x
Or you could start from (x-k)^2/4a + h = y
( h 4a k x )
- DUP * \ h 4a (x-k)^2
SWAP / + \ (x-k)^2/4a + h
Shorter but it uses a division instead of two multiplications.
If you start out with the right stack you can make the routine simple.
Simple routines are good. And then it might very likely turn out that
the stack order you want is usually convenient. It tends to work out
that way, except when you have to deal with arbitrary stack orders that
somebody else imposes.
When you give up the chance of using stack snarls to notice that you're
on the wrong track, you give up a useful tool. But maybe newbies would
like Forth better if they didn't have the frustration of noticing when
they're on the wrong track. I dunno.
> OK. Now back to the point. Andrew has presented the following code,
> modified from his 1995 posting to be comparable to the Brodie
> approach.
> Bruce provided a significantly shorter version of DRAW-BOX. Jonah
> provided some snippets of another approach, but it was incomplete (I
> think).
Yes, I was only showing that Andrew's primitive was compatible with
yours, that one could easily be built from the other. So that didn't say
he was doing it wrong.
> Anyway. Bottom Line. *If* we are interested in attracting newbies to
>
> Forth, I maintain that BOX2 is going to be far more effective than
> DRAW-BOX. I believe that DRAW-BOX, or anything like it, will send
> newbies running to look for a different language. BOX2 has a good
> chance of attracting new programmers to Forth. *In my opinion*. Not
> only that, as an experienced Forth programmer I prefer it. I wrote
> the code in about 25 seconds or as fast as I could type. It worked
> perfectly first time through.
Sure, but you know how to factor well. You just chose a problem where it
made sense not to factor. Where the problem is defined in such clear
language that -- given a programming language with adequate syntax --
it's enough to copy the equations into the code and they get compiled to
something that gives the right answer. I think it might be better for
Forth newbies to spend their time with problems where factoring tricks
are worth doing. If you can write good Forth code where it counts, then
you can use Forth to write code that could be done just as well with
other languages. But learn to write good Forth code first.
Of course we've all been assuming that no numerical analysis is needed.
We've given absolutely no thought to the possibility of numerical
instability, to ranges of inputs where the precision might go down with
the approaches we use, but some other approach might work better.
|
