Doug Hoffman <no.spam> wrote:
> Jonah Thomas wrote:
>
> > I suggested one part of it. It should have a GUI interface, not CLI.
>
> (context is non-embedded resource-rich personal computer Forth
> programming)
>
> I strongly agree with this. One only need look at what the rest of
> the (successful) world is doing. Windows, OS X, others.
Sure.
> > Each command gets an icon with a picture on it, and you drag it to
> > its place. Have lines to represent inputs and outputs, and the lines
> > could have some color and/or texture to indicate datatypes.
> >
> >
> > -----|~~~~~~|*****|~~~~|-----|~~~~~|*****
> > XXXXX| ROT |-----| + | XXXX| ROT |-----
> > *****|______|XXX |____| X **|_____|XXXXX
> > XXXXXXXXXXX *
> > ****************************
> >
> > It would probably be slower finding and dragging the icons. But it
> > wouldn't look like postfix! If we want it not to look like postfix
> > but we don't want to actually give up postfix, we need something
> > like this.
>
> No. This would be a big mistake. GUI is like candy, IMO. A little
> is good. Too much makes me sick. I have seen a commercial
> "graphical" attempt at this kind of programming for the Mac. It
> eventually failed and the entire package was given away freely. I
> tried it and strongly detested it. Besides, how would we communicate
> code via text-based mediums such as usenet?
You could send tokenised source code easily. And a good editor could
reassemble it into pictures. People might want to send their icon files
to each other, just as they do on facebook etc. No problem at all for
21st century technology.
I don't know whether that Forth could be done well. It would have some
advantages, done well.
> I have modified MacForth's outstanding Editor to include many useful
> additional GUI elements, including user-specified keyword coloring.
> The source is entirely in Forth and easily modified. An
> editor/environment like this (written in Forth), along with the
> complete source code for user customization, should come with every
> Forth development system IMO.
Great!
> > To appeal to ordinary programmers, I think this is necessary.
> > Postfix is the first big obstacle for ordinary programmers, and we
> > won't get very far with them until we handle that one.
>
> 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.
OK, named locals. That could serve as a sort of stopgap. It discourages
factoring, but we could provide sophisticated debugging tools to use
instead.
> Further, I have heard the oft repeated "locals
> hurts factoring" mantra. I have never understood how, heard an
> explanation of how, nor seen an example of how. I'm sure that someone
>
> can conjure up an obtuse situation, but is it really the normal case
> that a newbie would need?
A local name works only inside the one definition and not in factored
parts of it. So each part you factor out has to get its data marshaled
onto the stack and converted into fresh locals. That makes it harder to
factor.
But Forth traditionally provided so few tools for debugging that you
*needed* to develop a good Forth coding style to get anything done. If
we want it to be popular we need a way for sloppy programmers to get
results with ad style. If they have to think, they'll say the language
is no good. Locals give us a start in that direction, but they don't go
nearly far enough. If we're going to have an explicit stack, why not
show it? With GUI you can painlessly show each stack item along with
some info -- you might have blue for addresses and bright yellow for
xt's and so on. Things that today's Forth programmers have to hold
entirely in their heads (together with whatever stack comments they
make) could be on display all the time. And if you don't like to look at
the SWAP dragon you could have that icon say SWAP .
|
