Re: How to make Forth interesting?

Jeff Fox <fox@xxxxxxxxxxxxxxxxxxx> wrote:
Jonah Thomas <jethom...@xxxxxxxxx> wrote:

If Forth is particularly good to solve
part of the problem and something else is particularly good for
another part, either do it in a few K of Forth or in megabytes of
the other system but don't try to get them to work together.

I don't follow that. That's your advice to people?

No, I'm trying to get a sense of what you advise.

"I think it is simply a case that Chuck designed a language to
avoid the multi-language nightmare according to the first
paper on Forth. And that's a very different idea than
adapting the language to a multi-language environment. I
like to say it is the difference between Forth and Forth
script for some other non-Forth system."

Well, but if you want to do part of the work in Forth and part in
another language then you need them to communicate well.

"Indeed the glue may be much larger and more complex than Forth
itself. You are likely to end up with either the biggest and
most complex Forth or the lowest performance Forth this way."

"Thankfully Forth is a thousand times simpler when you have Forth
that isn't 99% about C systems."

""Curriosity" is the reason to tell them to do their Perl homework in
Forth instead of Perl?"

You appear to advise that people do it all in Forth. Or if some language
is a real good fit to the problem, do it in that language. But to solve
a problem partly with Forth and partly with something else your Forth
winds up being complex or low-performance, it's 99% about C, etc. You'd
wind up adapting Forth for a multi-language environment.

You talk about adapting Forth for a multi-language environment like it's
a bad thing. So I wound up thinking that you wouldn't advise people to
do that. And that leaves them not using Forth to solve part of the
problem and something else for another part of the problem.

Can you see how I might think that's what you intended? But it turns out
you're fine with Forths that put 99% of their complexity into
communicating with other languages, so that people can use them to solve
part of a problem with Forth and another part with another language. I
just hadn't noticed you say anything about that before.

You have data? ?!

That sounds very important. Can you say when and where this was
done?

iTV investors were skeptical of Chuck's claims and paid for top
people to compete against Chuck's effort to prove whether Chuck's
claims were right or wrong. It was an experiment with only a
few people and a few million dollars and only for a couple of
years.

All they proved was that the expensive tools were wrong about
Chuck's circuits being impossible, Chuck's circuits worked as
his tools predicted. The claims about superior performance
of the standard tools were not true since it took more time
and money for them to say that Chuck's working chips were
impossible than it was for Chuck make them and to show
that they worked.

That's good for Chuck's chip-design program against the standard tools
of that day. It doesn't say much about Forth.

Years later IntellaSys made a more serious effort to evaluate
Chuck's claims about his Forth tools. Productivity and cost
and quality of output were tested against more conventional tools
and methods. Instead of being a test with a couple of people
for a couple of years like at iTV this was on a much larger
scale. I was rather intimidated by some of the top design
engineers hired away from Intel who had designed Pentium
or other mainstream chips or worked on state of the art
classified design projects for top defense contractors and
a few lower level people. The Forth team was similarly
staffed with some very experienced people and some people
just out of school.

After a few years both teams had been able to make new chips
to certain specifications, the team's performance and the
product performance was then evaluated and compared side by
side. Management didn't care whether Forth or something else
did a better job, they were neutral. They just wanted the
most productive work and the best product performance and
were able to make objective comparisons based on real numbers
after the best experiments could be made to test each
individual claim objectively.

Great! Any chance that IntellaSys might let somebody look over some
fraction of their data and publish the relevant results? It might be too
big a project for Noah Ryman's master's thesis, but maybe not.

I don't know if Chuck liked being challenged again and again
to prove what he said. I think he did enjoy being proven right
again and again. At some point you have to decide what direction
to take and stop doing reasearch that splits the funding on two
competing projects with the same goal if you want to get things
done on a budget.

There are tricks to fooling people into thinking you know what you're
talking about. It might be worth it to Chuck to think about that. For
that matter it might be worth it to me too; I've tended to think it was
immoral and ignore the topic apart from noticing a little bit about how
it works.

Like, there was a renaissance artist who got asked for some sample art
to help the church decide which artist would get the contract. He made a
show of being insulted that they'd ask that of him, and then in front of
the messenger who carried the message, he drew a perfect circle freehand
and sent that back as his sample. Drawing a circle freehand had nothing
to do with the sort of art he'd be doing, but they were still impressed
enough by the story that he won the competition.

Richard Feynman wrote about a man who claimed to understand human
beings, who taught him how to pick up women in bars. The man said that
since he understood people he knew that Feynman wouldn't believe him
unless he first showed Feynman he knew what he was talking about. So he
said he would use his knowledge of people to get some random guy to buy
Feynman a drink. When it worked, Feynman was ready to believe the man
was an expert.

I used to think it was wrong to use silly tricks to fool people that
way. But maybe what's wrong is to fool people into believing you're an
expert when you aren't. If they're ready to believe silly tricks and not
ready to believe real evidence, why not use the methods that work?

Which reminds me:

http://www.sideshowworld.com/tgodvenicebeach.html
http://www.sideshowworld.com/tgodvenicebeachrent.html

Here's a street performer at Venice Beach. He's technically better than
any other performer. But nobody pays any attention to him. He has to
learn techniques to get tourists to notice him -- until he learns
methods to attract a crowd nobody will even stop to watch. And one of
the big things is that people don't want to stop to watch unless there's
already a crowd of others who've stopped to watch. A few buskers got
most of the attention.

"That night as I lay on the lumpy bed watching the spiders weave in the
corner, I figured out a fundamental rule of performing: Being able to
market what you do is more important than what you actually do."

But after he found out how to collect a crowd, they still just watched
and didn't give him money. He had to spend even more effort figuring out
how to get them to pay.

There's surely a lesson here even for someone whose profession doesn't
involve pounding screwdrivers up his nose.
.

Relevant Pages

  • Re: Armenian, Sumerian, Burushaski, and Turkic languages
    ... Feynman's "common sense" about language was as erroneous as anyone ... I looked up the book "Surely You're Joking, Mr. Feynman!" ... up on learning Japanese. ... we assemble the very same cameras, ...
    (sci.lang)
  • Re: Armenian, Sumerian, Burushaski, and Turkic languages
    ... Feynman's "common sense" about language was as erroneous as anyone ... I looked up the book "Surely You're Joking, Mr. Feynman!" ... use two different verbs, one can't use the verb solve in both ... we assemble the very same cameras, ...
    (sci.lang)
  • Re: Armenian, Sumerian, Burushaski, and Turkic languages
    ... no early language could possibly be discerned from ... said in his funny book "Certainly you are joking, Mr. Feynman!" ... In the unlikely event that it states something about the Japanese ...
    (sci.lang)