Re: An Observation

Elizabeth D Rather wrote:
John Doty wrote:
....
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.

One of the virtues of Forth is its simplicity. There are no "nouns" or "adjectives", and no syntax. Just words that are executed. Ever so much easier to teach, learn, and use that way.

Then it isn't a *language*, just a set of code generation procedures. If you think of it as a language, you'll make different design choices and people expecting a language will get something they can understand.


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.

Likewise. Fortunately, it's proven to be easy to write code that's readable in both directions.

"Easy". Do you mean that in the same sense as "many"?

Why does Forth have a reputation as "write-only" if it's so easy?


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

Hardly anybody already knows Forth.

It's too bad that you find this to be true. We meet and work with a lot of folks who know Forth, and create new ones regularly.

Sure. At FORTH, Inc. And I know a fair number of LSE users. But go to a large scientific gathering and try to find scientists using Forth. I'll direct you to the ones using LSE ;-).

But I agree with you. It is indeed too bad that I find this to be true.


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

Again, that's your experience. It isn't mine. We see a lot of folks from companies who have been using Forth.

Yes. At FORTH, Inc. Now try a different way of choosing your sample.


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


SwiftForth 3.0.8 18-Feb-2007
ok
14 42 swap . . 14 42 ok
ok \ If you insist on the decimal point:
14 42. rot . d. 14 42 ok

100% portable on all ANS Forths. Unless, of course, I misread what your code does. I don't find LSE64 to be very readable.

LSE64 uses the common convention that a decimal point indicates a floating constant. I see no reason to be *gratuitously* different from more familiar programming languages. Try SWAPing a float and an integer.


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

Sure they do. Newbies tend to go to variables sooner than more experienced Forthers.

No. Not writing, reading. Newbies can't *read* elaborate stack gymnastics. Those are unfortunately all too common in the small amount of published standard Forth.

As they gain experience they can better judge the tradeoffs.

Cheers,
Elizabeth



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

Relevant Pages

  • Re: Am I programming correctly with array parameter?
    ... >>depending on the user to free it is unavoidable. ... > I have no argument with that, but newcomers to the language probably ... char *dupstr ... if (dest!= NULL) ...
    (alt.comp.lang.learn.c-cpp)
  • Re: Are _T() and TEXT() macros equivalent?
    ... are not concerned if a char takes 1 byte or 100. ... since the language defines an object ... various ramifications of using and not using the switch. ... Why the fixation on basing the meaning of the keyword "char" on a compiler ...
    (microsoft.public.vc.mfc)
  • Re: Are _T() and TEXT() macros equivalent?
    ... by every single application developed in that language for the last 30 ... are not concerned if a char takes 1 byte or 100. ... Go through the standard and list the sections that use char as byte. ... void write ...
    (microsoft.public.vc.mfc)
  • Re: An Observation
    ... there is a problem) is that CHAR doesn't always execute. ... 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. ... So when newbies encounter Forth, they get stuck on elaborate stack gymnastics. ...
    (comp.lang.forth)
  • Re: learning c and c++
    ... >> books on each desired language, more would be better, but of course ... > possible) int to char, ... 'int') If you know that a particular 'int' value is within ... to a 'string'. ...
    (alt.comp.lang.learn.c-cpp)