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

Gerry <gerry@[EMAIL PROTECTED]
> wrote:
> Jonah Thomas <jethom...@[EMAIL PROTECTED]
> wrote:
> > Gerry <ge...@[EMAIL PROTECTED]
> wrote:
> > > I've emailed you a copy. I'd appreciate it if you let me know how
> > > you got on with it or if the email doesn't reach you
> >
> > It arrived intact. I've spent half an hour looking at it, I can
> > follow in general what it's doing. It looks more complicated than I
> > expected. I probably haven't noticed all the subtle problems that
> > need to be solved.
> >
> 
> Yes it's more complicated than it need be to solve that particular
> problem but this converter was a by-product from finding a general
> solution to the problem of using my LexGen tool with the Gray parser
> generator. It was a simple example that was a proof of concept and
> just happens to be useful. I found that using Gray is rather
> complicated, the BNF to Gray converter makes it somewhat simpler. Does
> the internal complexity matter if it works and is easy to use?

First off, I think that anything that works is better than anything that
doesn't work. And I don't want to look a gift horse in the mouth, I sure
don't want to complain about your work.

You pointed out that the documentation isn't finished. With the
documentation it will be clearer that some of the sections provide
simple tools that make the next sections easier to manage.

It was late at night and I was feeling kind of philosophical. A fair
number of people have tried Forth and quit it, and some of them say
afterward that when they started it they had a dream that they could
build things out of simple parts connected simply. That it would all
work out, and they wouldn't get drowned in complexity. But then they
tried Forth and it didn't work for them. Sometimes they say they could
do 70% of what they wanted simply, but the result was a toy. Or they got
drowned in complexity anyway. Etc. The dream wasn't fulfilled for them,
and they gave it up.

People say it works for Chuck Moore. He writes lots of routines that are
a line or two each. Simple, clear, powerful. It does 90% of what you'd
want it to, and the other 10% isn't needed. If it's true that 10% of the
specs generate 90% of the complexity and that 10% isn't really
needed.... People say Chuck is the best at using Forth. I'd like to be
better at it than I am. What does Chuck do that I don't do? What do I do
that I shouldn't?

So here we are doing string manipulation in Forth. Only the most
primitive tools are provided. We can do anything we want and we have to
do it ourselves. Come up with a simple elegant low-overhead approach
that makes the later stuff simpler, and we'll really have something.
Implement the same things that Python already has and we wind up with
RPN stack-oriented Python with our own special names. It's OK to do
something that takes a little extra effort to learn, that makes it
simpler later. But if we have to do it ourselves and we don't wind up
with something better than what other languages give us already,
batteries-included, why do it?

I think you're doing some of that. You use mini-OOF and you have your
special LexGen tool, which will both turn out to be used simply. I was
thinking about Forth complexity and I happened to be looking at your
code at the time. I didn't intend to criticise it.