Re: An Observation

On Mar 6, 11:26 pm, step...@xxxxxxxxxxxxxxxxx (Stephen J. Bevan)
wrote:
John Doty <j...@xxxxxxxxxxxxxxxxxxxxxxx> writes:
Stephen J. Bevan wrote:
John Doty <j...@xxxxxxxxxxxxxxxxxxxxxxx> writes:
Certainly it's the kind of programming a narrow specialist is
comfortable with. LSE isn't intended for narrow specialists.
We are communicating right via a network of computers running
software that solve problems virtually identical to the SIP one I described.

And very little of this is in Forth.

Agreed, but it does exist. There is no LSE64 code in this area.

These arguments are a side issue from what John Doty is trying to say.
Since the current user base for LSE64 is very small and tends to be
users as opposed to developers, of *course* there are only
applications in the particular areas that his users need them.

But what John is attempting to do here is to invite us to develop a
new Forth, simpler and more powerful than 94 Forth or LSE64 but using
ideas from any source that looks useful including 94 Forth and LSE64.

I like the idea. Forth 94 is some ways too complex. Some of that
complexity came to support Forths that are no longer maintained and
might not be necessary. Some of it could get put into a "convenience"
wordset, and we could have factors in the core that can be used to
build the convenience words.

And Forth 94 is missing features I sometimes really want. (But then I
remember the DIA slogan. "If you want it real bad, you can have it
*real bad*.")

ColorForth is very nice but it isn't what I want. It's tuned to a
virtual machine that's a little too much of a specific machine, and as
soon as Chuck comes up with a better machine he'll drop it.

But this is the classic language problem. You can keep re-inventing
the language and make it simpler and nicer, and each new revision will
lose you the people who want their old code to keep working. Or you
can keep adding more barnacles and it gets more and more complex and
hard to follow, and eventually new users will choose something more
elegant. I don't know whether there's any way to resolve that.

Forth 83 made the mistake of changing so many fundamental things that
Forth 79 code didn't work. It was the biggest setback Forth has ever
had. I don't have numbers but it would be quite plausible that Forth
lost half its user base then. Maybe more.

Forth 94 bent over backward going the opposite way, and now people
complain that it stifled innovation. It does though allow lots of
great innovative systems -- provided that those innovations are
invisible to users who write standard code.

I don't know how to solve this. But creating a new simpler and more
powerful Forth looks like fun, and continuing to argue about Forth 94
does not look like fun. I'd rather spend my hobbyist hours having fun.
On the other hand, I have to spend my professional hours working on
maintainable code.

So if we get a simpler more powerful Forth, it needs to be compatible
with standard Forth. It should be possible to make a system that does
both. Ideally it should be possible to write a compatibility layer
written in the new Forth that implements the old Forth, that can be
rearranged to re-create any of the old standard Forth environments.

I deny that LSE couldn't be good at this, but as I have no interest in
solved problems I have no motivation to work on it. It certainly is a
very narrow area of the programming universe.

And yet you want everyone to care that Standard Forth isn't being used
much in your narrow area of the programming universe? Hm.

By some measures Forth is maintaining its niche. By Anton's measure
we're advancing. By the TIOBE measure we're holding steady at 0.15%.
(We've recently climbed to 36th place without increasing our
percentage share.) http://www.tiobe.com/tpci.htm

But Python is in 7th place and Ruby has gone from 21st place to 10th
place in a year. By whatever TIOBE measures, Ruby's popularity has
gone up 7-fold in one year. Could a Forth do that? Yes, why not? If
there was some reason that lots of new users thought a Forth dialect
was very easy to learn and also very powerful, and easy to integrate
into multi-language apps, why not? Comp.lang.forth could be flooded
with newbies asking newbie questions.


I'm confident that any reasonably unbiased sample of computer users
would judge C code more readable by humans than Standard Forth code.

The vast majority of computer users don't program at all and so I'm
not sure what they find readable. However, one thing I am confident
about is that those users would lump LSE and Standard Forth in the
same category since the difference between them is tiny compared with
the difference between them an C.

Sure, but John isn't considering LSE an end-point. He just considers
it farther along the way to where we need to be than Forth 94 is. And
we did lose a lot with Forth 94. When you knew you had an indirect-
threaded 16-bit Forth you could do lots of useful tricks that we lost
to get system flexibility.

It's very useful -- vital even -- to get the the implementation
options that Forth 94 officially gave us, but you can't deny we lost a
lot too. Of course you can still do lots of special tricks with your
own system. But you won't talk about them much because they aren't
standard code and many other Forth users can't use them.

Forth's niche used to be very large, encompassing much of the kind of
work I'm interested in. Now it's so small it's hard to find. Maybe
that doesn't matter to you, but it matters to me.

No maybe about it: it doesn't matter to me at all since I'm not
interested in the work you are interested in, it certainly a very
narrow area of the programming universe.

Sometimes we get enthusiasts who want Forth to take over the world. I
think this is harmless. They might make something that's worth making.
If somehow they get Forth to take over the world that's probably
harmless too though it's never happened yet. Why argue with them? You
have something that works for you, they say it doesn't work well
enough for their purposes to suit them, all's right with the world.

I think it's a tactical mistake for John to argue with you. He'd do
better to get the people together who want to do something along the
lines of what he wants, and ignore the people who say they don't want
to do it -- except when they make useful suggestions or useful
warnings. He might do better with a new newsgroup or a listserve or a
blog or something. Give it the express purpose of building a simple
powerful Forth to take over the world, and when people want to argue
that it isn't worth doing then direct them here or to a special blog
topic etc devoted specificly to whether it's worth doing.

.

Relevant Pages

  • Re: An Observation
    ... It doesn't sound like anything LSE (either 16 or 64 ... If it was "real world" then how is manpulating FITS ... There's the ubiquitous C, of course, but more interestingly there's also support for application languages like IDL, Python, and Mathematica. ... that is at least as efficient as "Standard Forth". ...
    (comp.lang.forth)
  • Re: An Observation
    ... It doesn't sound like anything LSE (either 16 or 64 ... that is at least as efficient as "Standard Forth". ... fundamental reason why there could not be, it is just a design choice ... "write-only language for overspecialized programmers" culture that its ...
    (comp.lang.forth)
  • Re: An Observation
    ... invisible to users who write standard code. ... portability issues off of the language users' plates onto the language ... but John isn't considering LSE an end-point. ... Note that Mathematica is kind of an umbilical system, ...
    (comp.lang.forth)
  • Re: An Observation
    ... I wouldn't call parsing SIP datagrams much of a real-world problem: it's systems programming, deep in the Platonic artificial world of the computer. ... is no requirement that LSE64 has to be able to solve my problems. ... LSE64 has remained true to Forth's roots, while Standard Forth has evolved away from real-world applications toward the comfort zone of programmers troubled by the reality outside the computer. ... I'm unconvinced that LSE couldn't solve your problem. ...
    (comp.lang.forth)
  • Re: Dynamic includes/linking
    ... There's no standard way - you would need to ask the specialists in a ... "Debugging is twice as hard as writing the code in the first place. ...
    (comp.lang.c)