Jonah Thomas wrote:
> 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.
You have to get deeper than that. I was recently asked to participate in
a Stanford University "webinar" on innovation in space exploration. I
gave the talk last week. This week's speaker made the point that to
innovate, you must figure out what the users of your technology would
want if you could give it to them, not what they tell you they want.
>
>> 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.
Maybe not. I suspect an HLL atop a Forth VM would produce more
consistently idiomatic code at the VM level than a programmer trying to
be clever. That would make it easier for an optimizer.
> It's
> also likely to be less "efficient" than a compiler that's closer to the
> actual hardware, written for that HLL.
I don't see why here either. GCC translates to RTL, and then the
optimizers get to chew on that, mostly. It works pretty well. But an
advantage of a Forth VM over RTL is its extensibility and greater
comprehensibility to humans.
> 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.
Getting the languages to cooperate is an advantage of RTL. But RTL is
intended for batch compilation, not interactivity. A Forth VM in place
of RTL could erase the distinctions between compiled and scripting
languages.
>
>>> 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.
You can't productively hire a programmer unless your requirements are
crystal clear. That effectively prevents programmers from working at
development at the cutting edge, where you necessarily don't know what
you're doing very well.
>
> 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.
My customers modify my LSE64 code to their purposes fairly frequently
and successfully. What bewilders me is that often they *still* don't
appreciate it!
> 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.
One advantage of C is indeed that once you have the application working
there's often a C programmer around who can be tasked with maintenance.
> 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.
My yard's still covered in snow! :-(
>
>>> 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.
There is no justification whatever in history for this view. Sophistry
is almost as old as logic.
> 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.
Computer simulations are notoriously bad at predicting human behavior.
> 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.
--
History teaches that logical consistency is neither sufficient nor
necessary to establish practical, real world truth. Those who attempt to
use logic for that purpose are abusing it.
