Re: An Observation

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.

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.

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.

-- 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.

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.

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.

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.

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. 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.

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.

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.

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.

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.

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.

I'm serious, do it right and we could turn 90% of the secretaries into
Forth programmers in 10 years. Being a Forth programmer would be like
using Word, you mostly wouldn't consider yourself a secretary if you
didn't know it.

.

Relevant Pages

  • Re: subroutine stack and C machine model
    ... Hardly matters -- the type rules predate the standard by years. ... was defined as I have said to protect the profits of vendors. ... programmers and as such did a far more valuable service. ... how dare they come up with a common language definition so that people ...
    (comp.lang.c)
  • Re: subroutine stack and C machine model
    ... If you are referring to left-to-right evaluation, ... determined by the programmers of compilers...for the same reason that ... obsolete language APL enforced right to left evaluation. ... each compiler's choice was a defacto standard. ...
    (comp.lang.c)
  • Re: (Prolog + LISP + Erlang) with integration issues versus C++
    ... >> they will write idiomatic lisp so soon after learning it. ... >> Learning the language on the job is not a recipe for good maintainance. ... > programmers. ... standard, but it's been extended so heavily it may as well not be. ...
    (comp.lang.lisp)
  • Re: subroutine stack and C machine model
    ... It is a fact that the C language has been defined by the ISO C standards ... A mistake has been certified standard for too long. ... I've known plenty of good programmers who have switched to C from other ... Microsoft compiler used Int precision, ...
    (comp.lang.c)
  • 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)