Elizabeth D Rather <erather@[EMAIL PROTECTED]
> wrote:
> Jonah Thomas wrote:
> ...
> > 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?
> >...
>
> Understanding that your percentages here are entirely rhetorical,
Yes. I was using the generalized 90:10 rule where people say that 10% of
something is responsible for 90% of something else. (Occasionally they
use an 80:20 rule instead, which gives a hint of the precision
intended.) And I read somewhere that you found Chuck to produce things
that were always 90% complete. But a quick lit search didn't find that.
It did find you saying that he'd look at the specs and say "This is
easy!" and then make something simple that solved the core of the
problem. Then there would be a lot of this-and-that with the customer
where they said what else they wanted, and he'd add it, and it got more
complicated. Then when it was clear what the customer really wanted he'd
rewrite that simply, from the beginning.
> I think you're on the right track. The big difference between Chuck
> and a lot of folks here is that he only solves the particular problem
> at hand -- he is never groping for a general solution. He would never
> say, "I need a better string handling package." Instead, confronted
> with a particular string challenge, he'd find the most direct way of
> dealing with it. If he is working on an application full of strings,
> he'd find ways to deal with its specific issues, and factor some of
> the common needs into reusable definitions, but he would never be
> searching for either "general purpose" functions or attempting to
> replicate what some other language did.
So, after he'd done that a number of times he'd have a sense of which
tools are most useful for a string package. He'd have those handy
because they worked consistently before. If you start out wanting to
design a string package you might easily do things that aren't what you
need. You might easily have complications that you think ahead of time
are needed, and then when you or others use it they accept those
complications as a necessary part of string handling.
> Whether this is good or bad, I can't say... but if you ask "What does
> Chuck do that I don't do?" that's the answer.
Thank you. It sounds like, by continually re-inventing wheels he both
refines his concept of what kind of wheels he likes, so he does it
better, and also he improves his tools for rebuilding wheels. But his
new code may not be much like his old code, so he'd have more trouble if
he has to go back to old stuff to make small changes. But if he has the
excuse to rewite completely he's likely to do even better this time....
When you regard something as "already solved" then you get the benefit
of using the existing code, and you lose the benefit of improving it.
And if you do enough of that, at some point it isn't worth using a
better solution because if you do you have to keep converting to the
style that the libraries use so you can keep using them.
So we have people who do things with HTML with TCP/IP when it's utter
overkill for their application, because they need to have all that
machinery available for unrelated purposes and so it's available. Unless
they desperately need something more efficient, why go to the trouble of
developing anything else?
|
