John Doty
whispertel.LoseTheH.net> wrote:> Jonah Thomas wrote:
>> I'm glad to discuss with you ways to get Forth into new niches. Or
>> for that matter back into old niches. What we've started to consider
>> so far includes:
>>
>> 1. Making Forth simpler so it will be easier to learn.
>
> The question is, what's simple? You have to get into the mind of the
> user.
If you start with the marketing, if you ask what customers think they
want and how can you sell them the sizzle, you probably aren't going to
wind up with a good virtual machine.
> I was talking to an old friend and colleague a couple of weeks ago. He
>
> used to be an avid Forth user. I asked him why he'd stopped. He had a
> lot to say, without further prompting:
>
> "I still use Forth a little: I start up MAGIC/L and do things."
>
> "STOIC and MAGIC/L are Forth."
>
> "RPN is for ideologues."
There might be technical reasons why RPN is particularly valuable. I'm
having a little trouble laying those reasons out so I can decide how
true it is. If it was an important question, we could provide the most
elegant way we can come up with to provide prefix or infix or whatever
it is somebody thinks is better, and then we could test how important it
is. *And* in that case we'd have both approaches available for the
people who really care for one or the other.
> "The mistake Loki made with MAGIC/L was that they developed a new
> language: they should have put an existing language on a Forth
> foundation."
I keep thinking there should be posibilities there. When the guys who
did their Lotus clone in Forth could keep up with upgrades better than
Lotus could .... they were doing something right and Lotus was doing
something wrong. You can't expect to keep time with the drummer better
than the drummer can. It might be possible to do that with other
languages, if the other language developers are doing something wrong.
But it might also be yet another way to play catch-up.
> He made it very clear that the simple, extensible VM is, to him, the
> essence of Forth. That's the valuable idea: Forth's other
> eccentricities are impediments.
There are lots of extensible VMs now. Forth is a simple one.
>> 3. Or we could build simple user languages on top of Forth. These
>> would presumably be much less efficient than Forth,
>
> Why? Forth lets the user carefully optimize virtual code. That's not
> the same as optimizing machine code.
Forth gets away from the actual hardware to provide a simpler VM that's
easier to deal with. If you put some other language on top of Forth that
abstracts away from the hardware in other ways, it's likely to be less
efficient than Forth because it would be a HLL for the Forth VM. It's
also likely to be less "efficient" than a compiler that's closer to the
actual hardware, written for that HLL. There would be advantages -- you
could re-use lots of Forth code for different HLLs, and the compilers
would probably be easier to write and it might be easier to get the
different languages to cooperate etc.
>> but Python and Ruby and
>> Lua got pretty popular while they were far less efficient than
>> Forth. And you could drop down to Forth or assembly or possibly C if
>> you weren't satisfied with the easy language.
>
> Computers are cheap, people are expensive. I can buy quite a computer
> for what I charge for a day's consulting.
Sure. Getting computer programs to run faster or smaller is often not
the issue. Except sometimes for marketing. Forth has been bracketed on
that issue. People who think that their time is the most important can
use a scripting language that's much slower than Forth and be happy.
People who think runtime efficiency is vitally important tend to use C.
>> You want to be the best at something. So for
>> example it's no good to look at what Python does well and try to do
>> that too. Python already has that sewed up, and unless you can beat
>> Python at least double -- meet user expectations twice as well --
>> you can't expect to catch up. It's particularly hard to do head-on
>> competition with Python because a lot of Python users will regard
>> what Python does as the standard. You can't be better than Python
>> when being exactly like Python is the best you can do and any
>> difference counts against you.
>
> What Python is missing is concreteness: its VM is a computer
> scientist's abstraction. It gets in the way when you need to push bits
> on the iron.
Can't you drop into C for that part? Most of the people who want to push
bits will already know C. And if they don't know how to do that but
they've already learned Python then they won't mind the abstraction. It
will seem completely natural.
> The problem is that most Forthers don't seem to understand what the
> application world is. It's like a fish that comes to the surface of
> the water and thinks he's made it to outer space. Forth made its early
>
> friends by being spectacularly good at automating radio astronomical
> spectroscopy. But Forthers have forgotten the lesson that it's the
> accomplishments of complete systems (including other technologies and
> humans) that matter. It was the spectra that mattered, not the code.
For that, you'd want the guys with the applciation needs to learn Forth
well enough to solve their problems. You'd want the Forth to be easy
enough to learn that they can do that easily, without the one-week
course. The ideal is they realise that they're dealing with two
different domains and building a bridge from one to the other -- people
who want the computer stuff to just do what they expect won't get far
unless somebody builds them software that's twisted around to do just
what they expect. So OK, you learn a simple VM, you learn how to make it
do things, and then you write applications that do just what you want.
Other people like you can use the applications, and you've created
another win like automated radio spectroscopy. People who're unlikely to
hire a Forth programmer to do that for them could do it themselves -- if
they get the idea it's worth their time.
I can guess reasons that hasn't worked out. If you give your friends
code that does just what they want, who will they go to when they want
it changed? There's nobody but you. Do you want to maintain everybody
else's code or do you want to get your own research done? If you're
important enough to have underlings, easier to budget enough money to
get the thing solved and hire people to do it in C. If the schedule is
slower you'll figure that's just the breaks. But this is my imagination.
Does it seem to fit your experience?
> One miracle of last week is that a customer actually asked
> specifically for LSE64 for microcode generation for a new system using
> the hardware at
http://www.larosa-eng.com/engineering.htm. They've
> been using it on older systems, and they like it.
Great! That might be like the first robin of spring.
>> Someday there will be a large niche for a simple simulation
>> language. Something that's so simple that guys who're drinking in a
>> bar and arguing politics could make models to show what they mean.
>> Professionals who do simulations are very concerned about validation
>> -- they can't make their models too complicated or they quickly
>> outrun their data, but too-simple models are obviously inadequate.
>> Amateurs with a simple modeling language would not have those
>> limitations. "...where angels fear to tread...." They could make
>> their models as they see fit and then observe just what it is
>> they're predicting. There's a whole lot of potential there. Forth is
>> a great starting place if you want to make something simple. But
>> somehow I mostly haven't done it yet.
>
> At best all it could do is give the sophists another tool to claim
> authority for bogus conclusions based on faulty premises.
If they specifically lay out their faulty premises they'd be in better
position to argue about them. That's a good thing. And if they actually
use the tools, then the tools get used. That's a good thing too.
I think that simulation tools could vastly improve such arguments.
Consider for example abortion. The argument usually centers around
whether it's inherently wrong. If it's inherently wrong then it should
be illegal, otherwise maybe not. But if people used simulation tools to
look at consequences they could have a different argument. First they
might recognise that laws tend to apply far more to poor people than to
people who have some money -- and the more money, the less the laws
apply. People who have enough money can choose to go somewhere that
abortions are not illegal to have them, taking money to the wrong
places. It's poor people who get most affected by abortion laws. Those
who're most affected are women on welfare. Are those the ones we want to
have the most children? So we could look at ways to encourage people to
use more contraceptives, or ways to encourage people to have less sex.
Given that methods to encourage abstinence have so far been rather
ineffective, we could look at ways to get those to work better. People
who look at what consequences they want get a different argument than
people who assume that right and wrong should have inevitable reactions.
hardly anybody thinks that abortion is a good thing that should happen
more often; the argument is about whether it should be illegal. And
arguing about consequences shifts it to that domain.
