Re: The Promise of Forth

John Doty <jpd@xxxxxxxxxxxxxxxxxxxxxxx> wrote:
Jonah Thomas wrote:
John Doty <jpd@xxxxxxxxxxxxxxxxxxxxxxx> wrote:
Jonah Thomas wrote:

What would we do to test which of these was true?

My problem here is that it appears we have only one history to go
by, and we can't do very good statistics on that.
In astronomy we're quite used to using statistics to examine
historical data. We're not the only ones, either: consider
epidemiology. What's needed, though, is a quantitative statistical
theory.

If people at a church picknick get food poisoning and you want to
figure out what did it, you can look at each different food and ask
who ate it. You might get a graph like this

chicken egg salad mashed potatoes
waldorf salad

ate&gotsick 56 34 30

55
ate&well 62 37 38

35

none&sick 8 30 27

0
none&well 10 30 31

32
132 131 126

132

You can do statistics on this, or more plausibly you can do logic on
it.

Incidentally, consider what sort of statistics you'd do about this? Lots
of people eat contaminated food and don't get sick, so when you look at
what people ate you don't get a smoking gun. Lots of correlation between
eating the spoiled food and the unspoiled food. Not very good statistics
at all. And the data isn't perfect, either. But if only one kind of food
is spoiled you can look at the people who didn't eat it and who got sick
anyway. This time it's almost certainly the waldorf salad, because all
32 people who didn't eat it didn't get sick. It doesn't take much
statistics. When this sort of problem is muddy enough for statistics to
be useful you probably won't find much of an answer.

Sometimes logic works.

But what data do we have about Forth to do quantitative statistics
on?

We don't. That's why we can't address a statistical hypothesis.

Then you have no basis to rule out the null hypothesis. You're going on
gut instinct.

We have a handful of anecdotes. I have a few anecdotes about
managers who used to do Forth and got promoted out of it. I have
second-hand stories about managers who decided to switch away from
Forth. You know a few people who used to use Forth and quit --
perhaps 30 years ago? 20 years? 10 years?

How can we possibly apply statistics to these stories?

We can't. But we can take the stories seriously and try to understand
what's going on behind them. You work with the evidence you have.

I'm up for that. But you don't actually have a basis to say you're right
and anybody else is wrong. Why not stop arguing about that and just look
at where your assumptions lead you?

The scientific method cannot go everywhere we wish. Still, it remains
our most reliable guide to reality.

You aren't using it. But that's OK, it doesn't work for the current
problem.

So here's my idea about why Forth isn't more popular. To me, Forth's
biggest strength is the way it teaches Forth users to do things simply.
When possible use short definitions, a line or two. Test them as you go.
When possible use no more than three input parameters and no more than
two output parameters.

Part of the way Forth encourages this is to provide no facilities to
violate these rules. The data stack is hard to use when you have a lot
of parameters, so you find ways to break things down into simple
routines that use a few inputs each. Short routines are easier to test,
and it's easy to truly test them. Bad programmers can write a big block
of code and test it against some test cases, and if the wrong answers
come out then they fiddle with it until it works better. Get inspired
guesses about what's wrong and try out fixes. Bad. You can test a short
routine by single-stepping it, one word at a time and check the outputs
and the inputs. You don't need a single-stepper. That's inconvenient for
long routines, so you make them short. Back when people used block files
the blocks encouraged short definitions. Two lines of 64 characters is
shorter than 2 lines of 80 characters. And you could aim to get one
complete idea onto a block.

Forth's limitations encouraged a better style of programming. The
special tools that let other languages get debugged weren't there -- and
weren't needed when people adapted to Forth. And whenever you slipped
into bad habits then Forth's limitations brought you up short, pretty
quickly. When it got hard to check your routine it was proof you were
doing something wrong.

Forth *demanded* a better style of programming, and it was Forth style
that was the best thing about Forth. But this is preclsely what people
don't like. People don't like to change their habits. People don't like
to learn new and better ways to get results. People like to do the same
things they've been doing but have development systems that make it more
convenient for them to do the same old things. I don't at all see what
can be done about that.

Some great programmers learned Forth style and then found they could
apply it to other languages. Nothing wrong with that. If you ask John
Passaniti why he doesn't use Forth, well, he does use it sometimes. And
he uses Forth style where it's appropriate whichever language he uses,
and he uses whatever special tools another language provides whenever he
benefits from those tools. He hasn't quit using Forth. But he thinks we
need the sort of community that Python or Lua have.

But the mass of programmers will not like Forth because they'd have to
change their habits and they don't want to. Show them how to program
Pascal in Forth or Python in Forth or whatever they're used to and
they'll complain that it isn't really Pascal or Python but they won't
have any particular trouble. Give them the syntax they expect and the
tools they expect so they can do what they've always done and get the
result they expect, and they'll be fine. Is that worth doing? I think
it's probably better if we can communicate easily with Pascal and Python
code, and let it go at that.
.

Relevant Pages

  • Re: "STL from the Ground Up"
    ... Except that the vast majority of programmers already use more modern ... Gathering statistics from lots of different sources. ... Languages like C have strong staying power thanks to critical code like ... You can also analyze web statistics as TIOBE do: ...
    (comp.programming)
  • Go To Statement Considered Harmful
    ... Just a little food for thought in the "goto" debate. ... Statistics showed that individual programmer productivity varied by as much ... and that it was the same programmers who produced the most ... it was a very clear pattern shown by extensive statistical studies of real world ...
    (comp.lang.basic.misc)
  • Re: Help with daughter! (topic drift)
    ... programmers who decide upon the budget, or the deadlines, or whether ... programmers leave for better-managed companies, and you're left with a bunch ... Most of the statistics I'm familiar with involves additive white Gaussian ... Unfortunately I've never known an engineering manager who could ...
    (sci.electronics.design)
  • Re: Go To Statement Considered Harmful
    ... Statistics showed that individual programmer productivity varied by as much ... and that it was the same programmers who produced the most ... debugging required, using easy to read and follow logical code, that is easy ... avoid use of "goto". ...
    (comp.lang.basic.misc)
  • Re: Wearing your conscience.
    ... meant "not able to get enough food", and those in poverty were skinny. ... So many people are worse off, but they don't appear in the statistics. ... > expectancy in that life style, ... > statistical base, and the numbers only go up a lot in odd countries not ...
    (sci.econ)
Loading