Re: An Observation

J Thomas wrote:
On Mar 18, 1:08 pm, John Doty <j...@xxxxxxxxxxxxxxxxxxxxxxx> wrote:
J Thomas wrote:

Any Forth programmer can learn to write adequate Forth 94 code in less
than a day.
Still, that's a lot longer than LSE64. How long does it take to learn to
*read* Forth 94?

That's a strength for your system. I'd like to think it can become
even simpler without losing power.

Go for it!


The problems that get so much attention here are mostly
arcane things that matter only for special purposes.
You mean like the fact that "CHAR X" means different things depending on
STATE?

The execution behavior of CHAR is the same regardless. The problem (if
there is a problem) is that CHAR doesn't always execute.

That kind of thinking is perhaps why some don't consider Forth a language at all. In a reasonable language, it should be clear which "noun" an "adjective" like CHAR modifies, and the syntactic relationship shouldn't change depending on some implicit state.


Keep it simple and you can go for years without using ['] IF or
writing a state-smart word. And you don't need to manipulate
dictionary entries. If you feel like the core wordset is bloated then
ignore the words you don't need
I can't unless others have the same discipline.

Only if you need to read their code. And you say they don't write
anything you need to read.

My customers *do* write code I need to read! And I write code they need to read.


-- having those words in the standard
doesn't hurt your code at all unless you use them.
I still have to use the interpreted pidgin to do things at build time.
So anyone reading my code would have to learn two languages if I used
Forth 94.

Anybody who already knows Forth will have no trouble with the standard
about that. It follows common practice.

Hardly anybody already knows Forth.


I can almost imagine ways to write your practice into a standard
Forth. Like, do MARKER first, and then do :NONAME to compile a line
that would otherwise be interpreted. At the end do ; to end the line,
execute the line, and execute the marker to delete the line. That
doesn't quite do it but there's probably a way.

You keep wandering back into the swamp ;-)


And if you don't
use them I guarantee other people will still be able to read your code
if you write well and simply.
Learn standard Forth and you will be more portable.
Does no good if my customers don't know it.

You don't have customers who want you to use the Forth they're already
using, so it isn't your problem at all. More power to you.

It seems extremely unlikely that I'll ever encounter a potential customer who is already using Forth.


Many Forths are
ANS-compatible and you can use them and be productive from the first
day -- though you must study them to use their special strengths.
Still, a simpler more powerful Forth would be a good thing.


If a better Forth can add on a compatibility layer so it can accept
standard Forth code, then you can get whatever benefits come from the
standard.
There aren't any.

All the Forth implementors who have arranged to make Forth 94-
compatible systems think there is some benefit. There may not be any
benefits to you, though.

The benefits implementors perceive may not be of interest to users. As far as I can tell, Forth has continued its decline since '94. Another disaffected Forth enthusiast, Mike Coughlin, has called the Forth '94 standard "the Forth vendors' suicide pact".


You can import code written for some other systems,
There is almost none. Why bother?

Then don't. But I tend to think that both-ways compatibility -- able
to run Forth 94 on a new Forth, and able to run the new Forth's code
on standard Forths, is a big advantage if you want a new Forth's
methods to spread among current Forth users.

I'm more interested in a Forth that could interest new users. Or old disaffected ones.

Particularly the latter.
People say, "It isn't Forth" and you point to it running on multiple
Forth systems. They say "It isn't standard code" and you point to it
running on multiple standard systems. That's a powerful argument.

Only to a handful of people.


You might get increased acceptance for your Forth when you can
legitimately call it a standard Forth system.
My customers don't care. But if someone cares about standards I can call
it a lightweight, simple, flexible, fast, easy to learn scripting
language in standard C. At least they'll have heard of that.

You keep on posting to comp.lang.forth. You appear to care some what
we think. Maybe you'd be better off if you completely ignored people
who know Forth. You haven't done that yet.

I've gotten some good ideas here. There are some smart people here.


If standard Forth can get a compatibility layer so it can accept code
written for your system, then your code will run on standard Forth
systems.
It can't. I make promises Standard Forth can't keep.

Are you sure? I would guess that they're both Turing-compatible, and
that given sufficient work either of them can at some speed generate
whatever output the other generates.

[Tanuki:~] jpd% lse64

LSE> 14 42. swap , sp ,.
14 42
LSE>

I claim that's not simple to arrange portably in Forth 94. I'm sure in the "infinite resource approximation" it could be done.


Code written for your system can run on most
Forths and Forth programmers who use it have the chance to look at how
you do it and how much harder it is to write their way instead of your
way. So your dialect can spread faster.
This double compatibility layer looks like a good thing to me, if it's
feasible. If it isn't feasible then OK, do without it.

.....

If there was a dialect of Forth that people had reason to learn to the
extent that in one year there were 6 times as many users of that
dialect as there were users of all other Forth dialects put together,
it would be the de facto standard. As long as it stayed popular.
Gotta give people code they want to use/extend. I learned Lisp decades
ago, but never used it until gEDA came along using Guile for scripting.

Sure. Give them reason and they might do it. And the easier they can
do it the less that will detract from the reason why they want to. It
isn't the main limiting factor -- they have to want to, first -- but
it's *a* limiting factor.

You have to somehow show people that Forth is still a productive language. Claims like "lots of scientists use Forth" will just discredit Forth to a scientist who knows lots of scientists and knows that very few of them use Forth.


Ruby's claim is that everything is an Object, and the syntax is very simple.
Yes, but is "object" the right model for all data?

Ruby's the one that's grown 7-fold in a year. Increasingly people
think it's the right model for them, now. Maybe by next year they'll
have had experience that convinces them otherwise, I dunno.

Who's using Ruby? What kinds of applications?


Python claims to be simple, readable, interactive, extendable -- just
like Forth! -- except it achieves all this by being so high-level.
Van Rossum studied how users perceive programming before designing
Python. That study informed the design, and I believe it had a great
deal to do with the success of the language.

Yes, I don't know what to do about that. Forth particularly appeals to
smart loners. It might not be regarded as a plus if it got taken up by
half a million secretaries.

Forth's claim has always been simplicity. We'd need to describe using
the stack as simpler than using variables -- which it is.
For volatile temporaries it is when the logic of the data flow is LIFO.
In other cases it isn't.

Sure. but when it works it's simpler and easier to use a stack. People
who don't know Forth talk like using the stack is something weird and
mysterious, something that gets in their way learning the language.
But it's the simplest way! It's easier than anything else, when it
works.

Unfortunately, most Forthers don't go to variables when it's simpler and easier to use variables. So when newbies encounter Forth, they get stuck on elaborate stack gymnastics.

--
John Doty, Noqsi Aerospace, Ltd.
--
Specialization is for robots.
.

Relevant Pages

  • Re: Is C99 the final C? (some suggestions)
    ... > the standard? ... There doesn't have to be any mention of "stack" in what I try to ... "There are five standard signed integer types, ... standard-like language. ...
    (comp.lang.c)
  • Re: Is C99 the final C? (some suggestions)
    ... > that someone will try compile their stuff on an old compiler. ... > because the ANSI standard obsoleted them, and everyone picked up the ANSI ... fixed by using another language. ... >>are multiplying two expressions of the widest type supported by your ...
    (comp.lang.c)
  • Re: Two Questions about "strlen", "strcat" and "strcpy"
    ... >> No. zero terminated strings is the whole problem in the first place. ... > OR length prefixed strings the language would retain compatibility ... is not easily duplicated with the old standard then it will foster interest. ... The C standards committee is dead. ...
    (comp.lang.c)
  • Re: Forth Frustrations
    ... How would they even know what they are without being language lawyers? ... standard systems and a large number of nonstandard ones. ... interpreter, ... They set up four states -- HOST INTERPRETER COMPILER ...
    (comp.lang.forth)
  • Re: Is C99 the final C? (some suggestions)
    ... >> because the ANSI standard obsoleted them, and everyone picked up the ANSI ... > fixed by using another language. ... programmers managing the meaning of the symbols for more generic operators. ... According to a paper by Intel, widening multiply accounts for something like ...
    (comp.lang.c)