Age Results
John Passaniti
now report the totally scientific results of the survey that someone
else started. And with a whopping 36 responses, we now know the answer.
The average age of comp.lang.forth participants is 49.78. In terms of
distribution, it's pretty even, not all clumped at the younger or older
end of the scale.
Feel free to make whatever grandiose statements you want from this. If
you think Forth is dying, cite the average and play off age biases and
perceptions of what age means. If you think Forth is thriving, cite the
equal distribution of respondents.
Or more simply, if you draw any conclusion about the population from
these numbers, enroll in your local community college and take a course
on statistics. Or, go work in government, where equally idiotic numbers
are used to drive public policy.
Rod Pemberton
"John Passaniti" <nn...@JapanIsShinto.com> wrote in message
news:pCxjj.2190$Sa1....@news02.roc.ny...
> The average age of comp.lang.forth participants is 49.78.
> Feel free to make whatever grandiose statements you want from this.
Without the median? Is the "person in the middle" 65 or 35 vs. the average?
I.e., is the average moving down or up relative to the middle?
> If
> you think Forth is dying, cite the average and play off age biases and
> perceptions of what age means.
If I wanted to do that, I'd just presume that some other "recently" popular
language, like Ruby, has an average age of say 23 or 28...
> If you think Forth is thriving, cite the
> equal distribution of respondents.
FORTH will always have some users. It has advantages (low overhead,
compactness) for certain situations. But, the advantages to the programmer
of not having to manage variables is the reason people use a HLL, like C,
and modern languages with dynamic typing, like Ruby, instead of assembly.
FORTH's use of a stack forces users to manage variables explicitly like
assembly. That's a big negative for many. I believe a large part of
programming is embedding your knowledge into the code. If so, then why halt
the language design of FORTH in the 1970's when knowledge has advanced us
way past that? Is everyone waiting for it's creator to pass away to update
FORTH? I.e., is the state of the FORTH language dead, i.e., good enough?
BASIC lost the line numbers. C reworked declarations. C could've, but
didn't, add a keyword for typedef usage.
Rod Pemberton
John Passaniti
> "John Passaniti" <nn...@JapanIsShinto.com> wrote in message
> news:pCxjj.2190$Sa1....@news02.roc.ny...
>> The average age of comp.lang.forth participants is 49.78.
> ...
>> Feel free to make whatever grandiose statements you want from this.
>
> Without the median? Is the "person in the middle" 65 or 35 vs. the average?
> I.e., is the average moving down or up relative to the middle?
As mentioned previously, the data is public: http://tinyurl.com/3y36rr
But for those who don't want to click, you're right in that I should
have been more precise. The mean is 49.78. The median is 50.50. The
minimum age is 24 and the maximum is 75. The data shows a fairly even
distribution over the range.
>> If
>> you think Forth is dying, cite the average and play off age biases and
>> perceptions of what age means.
>
> If I wanted to do that, I'd just presume that some other "recently" popular
> language, like Ruby, has an average age of say 23 or 28...
My guess-- and it's only a guess-- is that you would be wrong. Ruby is
the spiritual heir to Smalltalk, and it wouldn't surprise me if quite a
lot of the "old timers" in the Smalltalk community are also cranking out
code in Ruby.
>> If you think Forth is thriving, cite the
>> equal distribution of respondents.
>
> FORTH will always have some users. [...]
In case it wasn't clear, let me state it again. Someone else asked
about the ages of Forth programmers here in comp.lang.forth. I simply
started to tally them in a spreadsheet for fun. I make no conclusions
about Forth or Forth programmers from the data because the data isn't
scientific, but do enjoy watching others try to fit the data to their
particular agenda.
Stefan Schmiedl
John Passaniti <nn...@JapanIsShinto.com> wrote:
> The minimum age is 24 and the maximum is 75.
I've got it! By Jove, I've got it!
Forth - a Programming Language for Grown-Ups
s.
Mark W. Humphries
> ...
> FORTH will always have some users. It has advantages (low overhead,
> compactness) for certain situations. But, the advantages to the programmer
> of not having to manage variables is the reason people use a HLL, like C,
> and modern languages with dynamic typing, like Ruby, instead of assembly.
> FORTH's use of a stack forces users to manage variables explicitly like
> assembly. That's a big negative for many. I believe a large part of
> programming is embedding your knowledge into the code. If so, then why halt
> the language design of FORTH in the 1970's when knowledge has advanced us
> way past that? Is everyone waiting for it's creator to pass away to update
> FORTH? I.e., is the state of the FORTH language dead, i.e., good enough?
> BASIC lost the line numbers. C reworked declarations. C could've, but
> didn't, add a keyword for typedef usage.
>
> Rod Pemberton
Nothing prevents you or anyone else from developing and distributing
their 'dream' dialect of Forth and seeing if it can gain any traction.
I think that is a more positive approach than trying to evangelize
others to change their Forth to suit your biases or desires. Just do
it.
That's what I love about Forth, it makes it so easy to 'just do it'.
Jecel
> My guess-- and it's only a guess-- is that you would be wrong. Ruby is
> the spiritual heir to Smalltalk, and it wouldn't surprise me if quite a
> lot of the "old timers" in the Smalltalk community are also cranking out
> code in Ruby.
The flow of people is actually in the other direction, but since these
are probably far fewer than new people coming to Ruby it doesn't hurt
that community much.
If you count the eToys layer in Squeak as a Smalltalk (I don't) then
that language almost certainly has the lowest average age of them all,
and it should fall further as the OLPC project moves further (I
haven't heard of the children programming in Python yet, though that
was the plan).
-- Jecel
John Doty
> FORTH will always have some users. It has advantages (low overhead,
> compactness) for certain situations. But, the advantages to the programmer
> of not having to manage variables is the reason people use a HLL, like C,
> and modern languages with dynamic typing, like Ruby, instead of assembly.
> FORTH's use of a stack forces users to manage variables explicitly like
> assembly.
The conceptual mistake, I think, is to use the stack in non-linguistic
ways. Humans seem to use stacks easily and unconsciously in natural
language perception, but Forth traditionally fights against that
capability instead of exploiting it.
> That's a big negative for many. I believe a large part of
> programming is embedding your knowledge into the code. If so, then why halt
> the language design of FORTH in the 1970's when knowledge has advanced us
> way past that? Is everyone waiting for it's creator to pass away to update
> FORTH?
Nope. He's actually one of the dissidents, trying to push the language
forward.
> I.e., is the state of the FORTH language dead, i.e., good enough?
It's dying because it isn't good enough as a language.
> BASIC lost the line numbers. C reworked declarations. C could've, but
> didn't, add a keyword for typedef usage.
>
>
> Rod Pemberton
>
--
John Doty, Noqsi Aerospace, Ltd.
http://www.noqsi.com/
--
Specialization is for robots.
Alex McDonald
> Rod Pemberton wrote:
> > FORTH will always have some users. It has advantages (low overhead,
> > compactness) for certain situations. But, the advantages to the programmer
> > of not having to manage variables is the reason people use a HLL, like C,
> > and modern languages with dynamic typing, like Ruby, instead of assembly.
> > FORTH's use of a stack forces users to manage variables explicitly like
> > assembly.
>
> The conceptual mistake, I think, is to use the stack in non-linguistic
> ways. Humans seem to use stacks easily and unconsciously in natural
> language perception, but Forth traditionally fights against that
> capability instead of exploiting it.
You've lost me (again!). How does one use a stack in a linguistic
way?
>
> > That's a big negative for many. I believe a large part of
> > programming is embedding your knowledge into the code. If so, then why halt
> > the language design of FORTH in the 1970's when knowledge has advanced us
> > way past that? Is everyone waiting for it's creator to pass away to update
> > FORTH?
>
> Nope. He's actually one of the dissidents, trying to push the language
> forward.
IMHO, he (Chuck Moore for clarity) couldn't care, and probably hasn't
since ANS. There's no present evidence of Chuck dissenting; he just
seems to be happy developing other dialects and varieties of stack
based languages that suit his immediate needs. If he's a dissident,
it's by proxy.
>
> > I.e., is the state of the FORTH language dead, i.e., good enough?
>
> It's dying because it isn't good enough as a language.
I disagree. But then, my definition of dying and yours are probably
incompatible.
>
> > BASIC lost the line numbers. C reworked declarations. C could've, but
> > didn't, add a keyword for typedef usage.
>
> > Rod Pemberton
>
> --
> John Doty, Noqsi Aerospace, Ltd.http://www.noqsi.com/
> --
> Specialization is for robots.
--
Regards
Alex McDonald
Bernd Paysan
> The conceptual mistake, I think, is to use the stack in non-linguistic
> ways. Humans seem to use stacks easily and unconsciously in natural
> language perception, but Forth traditionally fights against that
> capability instead of exploiting it.
Is it Forth that fights or the users? I remember when I wrote the first
program in Forth, I used the stack as sort of dynamic array of variables,
where you could pick into to get the one you liked to have. I soon realized
that this isn't the right way to deal with the stack (there may be
exceptions - I wrote a spline algorithm that used the stack like this).
After I realized that, dealing with the stack became much easier (and it
was after this first example that I realized it ;-).
--
Bernd Paysan
"If you want it done right, you have to do it yourself"
http://www.jwdt.com/~paysan/
John Doty
> You've lost me (again!). How does one use a stack in a linguistic
> way?
If you like rules, in a Forth context:
1. A word should consume all of its arguments, and yield at most one result.
2. Never use explicit stack manipulation.
Natural languages occasionally bend their analogs of these in
disciplined ways, but these are a good rough approximation.
I have old LSE code by users who (no doubt unconsciously) followed these
rules, and it's very readable after more than a quarter of a century. It
has few stack diagrams: who needs them when the code speaks for
itself? My code from the same era is much more traditional (after all, I
learned Forth from Elizabeth!), and much less readable now.
--
John Doty, Noqsi Aerospace, Ltd.
http://www.noqsi.com/
--
Logic is a powerful tool for the refinement and extension of hypotheses.
It is very effective at condensing and simplifying knowledge. However,
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.
Alex McDonald
> Alex McDonald wrote:
> > You've lost me (again!). How does one use a stack in a linguistic
> > way?
>
> If you like rules, in a Forth context:
>
> 1. A word should consume all of its arguments, and yield at most one result.
Oh, I see. So COUNT is out ( c-addr -- c-addr n ) as the c-addr isn't
consumed. Yes, there I would agree. It leaves DUP in an odd place
though. It also negates one of the features of Forth that I positively
like, and differentiates its usefulness from most other Algol-based
languages. Returning a void or a single result per function (no point
in calling it a word any more) is very limiting. Perhaps we need
lists, but then Lisp would be better?
>
> 2. Never use explicit stack manipulation.
Such as PICK? Or are you thinking of SWAP, ROT et al?
>
> Natural languages occasionally bend their analogs of these in
> disciplined ways, but these are a good rough approximation.
>
> I have old LSE code by users who (no doubt unconsciously) followed these
> rules, and it's very readable after more than a quarter of a century. It
> has few stack diagrams: who needs them when the code speaks for
> itself? My code from the same era is much more traditional (after all, I
> learned Forth from Elizabeth!), and much less readable now.
I've too find my own code to be less readable than others', but
perhaps more realistically it's because I'm a poorer programmer.
>
> --
> John Doty, Noqsi Aerospace, Ltd.http://www.noqsi.com/
> --
> Logic is a powerful tool for the refinement and extension of hypotheses.
> It is very effective at condensing and simplifying knowledge. However,
> 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.
Your sig is getting a wee bit long.
--
Regards
Alex McDonald
John Doty
> On Jan 18, 9:19 pm, John Doty <j...@whispertel.LoseTheH.net> wrote:
>> Alex McDonald wrote:
>>> You've lost me (again!). How does one use a stack in a linguistic
>>> way?
>> If you like rules, in a Forth context:
>>
>> 1. A word should consume all of its arguments, and yield at most one result.
>
> Oh, I see. So COUNT is out ( c-addr -- c-addr n ) as the c-addr isn't
> consumed. Yes, there I would agree. It leaves DUP in an odd place
> though.
Can you think of a construct from natural language equivalent to DUP?
Passive voice in English works a bit like SWAP, perhaps. OVER is
definitely out.
> It also negates one of the features of Forth that I positively
> like, and differentiates its usefulness from most other Algol-based
> languages. Returning a void or a single result per function (no point
> in calling it a word any more) is very limiting.
What limits the writer helps the reader here. Coddling the writer leads
to "write only" code.
> Perhaps we need
> lists, but then Lisp would be better?
Didn't have lists in LSE. The folks who wrote clear code there just used
variables for extra outputs and common data.
>
>> 2. Never use explicit stack manipulation.
>
> Such as PICK? Or are you thinking of SWAP, ROT et al?
SWAP might be OK used with discipline, as in "SWAP -". But letting the
outputs of SWAP go their separate ways is abusive to the reader. And ROT
is well named ;-)
>
>> Natural languages occasionally bend their analogs of these in
>> disciplined ways, but these are a good rough approximation.
>>
>> I have old LSE code by users who (no doubt unconsciously) followed these
>> rules, and it's very readable after more than a quarter of a century. It
>> has few stack diagrams: who needs them when the code speaks for
>> itself? My code from the same era is much more traditional (after all, I
>> learned Forth from Elizabeth!), and much less readable now.
>
> I've too find my own code to be less readable than others', but
> perhaps more realistically it's because I'm a poorer programmer.
Yeah, but at that point in my life they were the amateurs, while I was a
seasoned professional programmer, steeped in the conventional wisdom. So
I *should* have been better, and by the standards I had learned I was.
But a quarter century later, those standards don't look so much like wisdom.
>
>> --
>> John Doty, Noqsi Aerospace, Ltd.http://www.noqsi.com/
>> --
>> Logic is a powerful tool for the refinement and extension of hypotheses.
>> It is very effective at condensing and simplifying knowledge. However,
>> 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.
>
> Your sig is getting a wee bit long.
You just don't agree with it ;-)
>
> --
> Regards
> Alex McDonald
>
--
John Doty, Noqsi Aerospace, Ltd.
http://www.noqsi.com/
--
This sig is intentionally left blank.
Jecel
> Can you think of a construct from natural language equivalent to DUP?
Pronouns are equivalent, though not similar. Hypertalk used them in a
reasonable way.
-- Jecel
Alex McDonald
> Alex McDonald wrote:
> > On Jan 18, 9:19 pm, John Doty <j...@whispertel.LoseTheH.net> wrote:
> >> Alex McDonald wrote:
> >>> You've lost me (again!). How does one use a stack in a linguistic
> >>> way?
> >> If you like rules, in a Forth context:
>
> >> 1. A word should consume all of its arguments, and yield at most one result.
>
> > Oh, I see. So COUNT is out ( c-addr -- c-addr n ) as the c-addr isn't
> > consumed. Yes, there I would agree. It leaves DUP in an odd place
> > though.
>
> Can you think of a construct from natural language equivalent to DUP?
> Passive voice in English works a bit like SWAP, perhaps. OVER is
> definitely out.
I think there may be two levels to Forth; possibly 3.
1. Low-level words such as DUP SWAP; primarily those that manipulate
the stack in an explicit way. (There may be a level below this, but
it's a level of detail that we normally don't see as "Forth the
language"; it's "Forth the implementation". Any discussion of ITC vs
DTC for example is, to me, at this much more primitive level 0.)
2. A higher level, abstracted private language that uses (1) to create
words that really don't need to refer to the stack explicity, and it's
used without "conscious" stack juggling.
3. A level beyond that; some of the OOP extensions display properties
that are RPN, but only just. The stack is rarely seen.
An example of (2) is from Forth Inc's website;
0 ( Washing Machine Application ) HEX
1 7000 CONSTANT MOTOR 7006 CONSTANT DETERGENT 700A CONSTANT CLUTCH
2 7002 CONSTANT VALVE 7008 CONSTANT TIMER 7010 CONSTANT LEVEL
3 7004 CONSTANT FAUCETS DECIMAL
4
5 : ON ( port) -1 SWAP OUTPUT ; : OFF ( port) 0 SWAP OUTPUT ;
6 : SECONDS ( n) 1000 * MS ; : MINUTES ( n) 60 * SECONDS ;
7 : ADD ( port) DUP ON 10 SECONDS OFF ;
8 : TILL-FULL BEGIN LEVEL INPUT UNTIL ;
9 : DRAIN VALVE ON 3 MINUTES VALVE OFF ;
10 : AGITATE MOTOR ON 10 MINUTES MOTOR OFF ;
11 : SPIN CLUTCH ON MOTOR ON 5 MINUTES MOTOR OFF CLUTCH OFF ;
12 : FILL FAUCETS ON TILL-FULL FAUCETS OFF ;
13 : WASH FILL DETERGENT ADD AGITATE DRAIN ;
14 : RINSE FILL AGITATE DRAIN ;
15 : WASHER WASH SPIN RINSE SPIN ;
From about 8 on, perhaps 9, we're out of the low level stack and into
a private language that doesn't really demand much from the reader; in
fact, when I read it, I don't see the stack at all, but the machine
itself as a set of interlocking parts, like AGITATE and SPIN, making
the whole with the last line; a WASHER.
The language is absolutely clear; what does a WASHER do? It WASHes,
SPINs, RINSEs and SPINs. Clear as you can get.
>
> > It also negates one of the features of Forth that I positively
> > like, and differentiates its usefulness from most other Algol-based
> > languages. Returning a void or a single result per function (no point
> > in calling it a word any more) is very limiting.
>
> What limits the writer helps the reader here. Coddling the writer leads
> to "write only" code.
>
> > Perhaps we need
> > lists, but then Lisp would be better?
>
> Didn't have lists in LSE. The folks who wrote clear code there just used
> variables for extra outputs and common data.
Hmmm. Not really my idea of maintainable or reusable.
[snipped]
>
> >> --
> >> John Doty, Noqsi Aerospace, Ltd.http://www.noqsi.com/
> >> --
> >> Logic is a powerful tool for the refinement and extension of hypotheses.
> >> It is very effective at condensing and simplifying knowledge. However,
> >> 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.
>
> > Your sig is getting a wee bit long.
>
> You just don't agree with it ;-)
I don't agree with overlong sigs; 6 lines is way too many, and you
should really use -- with an added trailing space to alert smart
newsreaders. See my signoff below.
>
>
>
> > --
> > Regards
> > Alex McDonald
>
> --
> John Doty, Noqsi Aerospace, Ltd.http://www.noqsi.com/
> --
> This sig is intentionally left blank.
--
Regards
Alex McDonald
Alex McDonald
>
> I don't agree with overlong sigs; 6 lines is way too many, and you
> should really use -- with an added trailing space to alert smart
> newsreaders. See my signoff below.
>
I should have said "and one should really use"; you do.
--
Regards
Alex McDonald
Elizabeth D Rather
> On Jan 18, 10:31 pm, John Doty <j...@whispertel.LoseTheH.net> wrote:
>> Alex McDonald wrote:
>>> On Jan 18, 9:19 pm, John Doty <j...@whispertel.LoseTheH.net> wrote:
>>>> If you like rules, in a Forth context:
>>>> 1. A word should consume all of its arguments, and yield at most one result.
I see no reason why Forth should assume C's handcuffs. Even FORTRAN
could return multiple results.
>>> Oh, I see. So COUNT is out ( c-addr -- c-addr n ) as the c-addr isn't
>>> consumed. Yes, there I would agree. It leaves DUP in an odd place
>>> though.
The c-addr *is* consumed, as the one returned is different (incremented
by 1). Both the returned values are results of the operation.
>> Can you think of a construct from natural language equivalent to DUP?
>> Passive voice in English works a bit like SWAP, perhaps. OVER is
>> definitely out.
No computer language I know of really adheres to "natural language"
constructs.
> I think there may be two levels to Forth; possibly 3.
>
> 1. Low-level words such as DUP SWAP; primarily those that manipulate
> the stack in an explicit way. (There may be a level below this, but
> it's a level of detail that we normally don't see as "Forth the
> language"; it's "Forth the implementation". Any discussion of ITC vs
> DTC for example is, to me, at this much more primitive level 0.)
>
> 2. A higher level, abstracted private language that uses (1) to create
> words that really don't need to refer to the stack explicity, and it's
> used without "conscious" stack juggling.
>
> 3. A level beyond that; some of the OOP extensions display properties
> that are RPN, but only just. The stack is rarely seen.
A good observation.
> An example of (2) is from Forth Inc's website;
>
> 0 ( Washing Machine Application ) HEX
> 1 7000 CONSTANT MOTOR 7006 CONSTANT DETERGENT 700A CONSTANT CLUTCH
> 2 7002 CONSTANT VALVE 7008 CONSTANT TIMER 7010 CONSTANT LEVEL
> 3 7004 CONSTANT FAUCETS DECIMAL
> 4
> 5 : ON ( port) -1 SWAP OUTPUT ; : OFF ( port) 0 SWAP OUTPUT ;
> 6 : SECONDS ( n) 1000 * MS ; : MINUTES ( n) 60 * SECONDS ;
> 7 : ADD ( port) DUP ON 10 SECONDS OFF ;
> 8 : TILL-FULL BEGIN LEVEL INPUT UNTIL ;
> 9 : DRAIN VALVE ON 3 MINUTES VALVE OFF ;
> 10 : AGITATE MOTOR ON 10 MINUTES MOTOR OFF ;
> 11 : SPIN CLUTCH ON MOTOR ON 5 MINUTES MOTOR OFF CLUTCH OFF ;
> 12 : FILL FAUCETS ON TILL-FULL FAUCETS OFF ;
> 13 : WASH FILL DETERGENT ADD AGITATE DRAIN ;
> 14 : RINSE FILL AGITATE DRAIN ;
> 15 : WASHER WASH SPIN RINSE SPIN ;
>
> From about 8 on, perhaps 9, we're out of the low level stack and into
> a private language that doesn't really demand much from the reader; in
> fact, when I read it, I don't see the stack at all, but the machine
> itself as a set of interlocking parts, like AGITATE and SPIN, making
> the whole with the last line; a WASHER.
>
> The language is absolutely clear; what does a WASHER do? It WASHes,
> SPINs, RINSEs and SPINs. Clear as you can get.
FWIW, the current version of this on our site is:
( Washing Machine Embedded Application )
\ Port assignments
01 CONSTANT PORT
\ bit-mask name bit-mask name
1 CONSTANT MOTOR 8 CONSTANT FAUCETS
2 CONSTANT CLUTCH 16 CONSTANT DETERGENT
4 CONSTANT PUMP 32 CONSTANT LEVEL
\ Device control
: ON ( mask -- ) PORT C@ OR PORT C! ;
: OFF ( mask -- ) INVERT PORT C@ AND PORT C! ;
\Timing functions
: SECONDS ( n -- ) 0 ?DO 1000 MS LOOP ;
: MINUTES ( n -- ) 60 * SECONDS ;
: TILL-FULL ( -- ) \ Wait till level switch is on
BEGIN PORT C@ LEVEL AND UNTIL ;
\ Washing machine functions
: ADD ( port -- ) DUP ON 10 SECONDS OFF ;
: DRAIN ( -- ) PUMP ON 3 MINUTES ;
: AGITATE ( -- ) MOTOR ON 10 MINUTES MOTOR OFF ;
: SPIN ( -- ) CLUTCH ON MOTOR ON
5 MINUTES MOTOR OFF CLUTCH OFF PUMP OFF ;
: FILL-TUB ( -- ) FAUCETS ON TILL-FULL FAUCETS OFF ;
\ Wash cycles
: WASH ( -- ) FILL-TUB DETERGENT ADD AGITATE DRAIN ;
: RINSE ( -- ) FILL-TUB AGITATE DRAIN ;
\ Top-level control
: WASHER ( -- ) WASH SPIN RINSE SPIN ;
Although much simplified for instructional purposes, this is actually
quite representative of how a lot of our applications end up looking.
Cheers,
Elizabeth
--
==================================================
Elizabeth D. Rather (US & Canada) 800-55-FORTH
FORTH Inc. +1 310-491-3356
5155 W. Rosecrans Ave. #1018 Fax: +1 310-978-9454
Hawthorne, CA 90250
http://www.forth.com
"Forth-based products and Services for real-time
applications since 1973."
==================================================
Jerry Avins
...
> FWIW, the current version of this on our site is:
...
> \ Washing machine functions
...
> : DRAIN ( -- ) PUMP ON 3 MINUTES ;
> : AGITATE ( -- ) MOTOR ON 10 MINUTES MOTOR OFF ;
> : SPIN ( -- ) CLUTCH ON MOTOR ON
> 5 MINUTES MOTOR OFF CLUTCH OFF PUMP OFF ;
> : FILL-TUB ( -- ) FAUCETS ON TILL-FULL FAUCETS OFF ;
>
> \ Wash cycles
> : WASH ( -- ) FILL-TUB DETERGENT ADD AGITATE DRAIN ;
> : RINSE ( -- ) FILL-TUB AGITATE DRAIN ;
>
> \ Top-level control
> : WASHER ( -- ) WASH SPIN RINSE SPIN ;
...
So once the pump turns on, only SPIN turns it off?
Jerry
--
Engineering is the art of making what you want from things you can get.
¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯
Rod Pemberton
"Alex McDonald" <bl...@rivadpm.com> wrote in message
news:5fd78275-a3c3-4365-99da-
> I think there may be two levels to Forth; possibly 3.
>
> 1. Low-level words such as DUP SWAP; primarily those that manipulate
> the stack in an explicit way. (There may be a level below this, but
> it's a level of detail that we normally don't see as "Forth the
> language"; it's "Forth the implementation". Any discussion of ITC vs
> DTC for example is, to me, at this much more primitive level 0.)
>
> 2. A higher level, abstracted private language that uses (1) to create
> words that really don't need to refer to the stack explicity, and it's
> used without "conscious" stack juggling.
>
> 3. A level beyond that; some of the OOP extensions display properties
> that are RPN, but only just. The stack is rarely seen.
>
My understanding, from various literature, is that low level FORTH words,
that must be coded in assembly, have been called "verbs" or "primitives".
Whereas higher level words written in FORTH only, have been called "words"
or "functions". And, a word that creates storage for a variable has been
called "noun" or "constant". Is this correct? Essentially, I see FORTH
divided into: primitives and non-primitives, whereas you see FORTH divided
into: stack, OOP, other.
Rod Pemberton
Jerry Avins
I think you're making too many distinctions.
Nouns and verbs are words. Verbs call out an action, while nouns are the
names of objects. In Elizabeth's response to Alex's message, PUMP is a
noun and ON is a verb.
Primitives are assembly coded. non-primitives are coded in Forth. With a
native-code optimizing compiler, there is little or no difference in
what is actually executed. An CODE word in one Forth is a high-level
word in another, and the programmer is free to write CODE words. Some
Forths have fewer than a dozen primitives, while in others, much of the
supplied vocabulary is coded in assembler.
Alex McDonald
<eratherinva...@spamfree.forth.com> wrote:
> Alex McDonald wrote:
>
> >>> Oh, I see. So COUNT is out ( c-addr -- c-addr n ) as the c-addr isn't
> >>> consumed. Yes, there I would agree. It leaves DUP in an odd place
> >>> though.
>
> The c-addr *is* consumed, as the one returned is different (incremented
> by 1). Both the returned values are results of the operation.
Yes, I saw that but quietly ignored my mistake.
[snipped]
>
> FWIW, the current version of this on our site is:
>
I prefer the original. It has a charming clarity, a bit like a good
haiku.
--
Regards
Alex McDonald
Alex McDonald
> "Alex McDonald" <b...@rivadpm.com> wrote in message
More specifically, I don't see a division, but a blending, from a
[lots of stack+RPN primitives] to [less stack+some abstraction] to
[little stack+much abstraction], with each step reducing the
visibility of the stack.
The division into verbs and nouns is only partly useful;
PUMP ON \ PUMP is a variable
ON PUMP \ ON is a variable
Languages can have other orderings beyond subject-verb-object. Agree
would Obi-wan Kenobi .
--
Regards
Alex McDonald
Coos Haak
You must have read the FigForth manuals, 30 years ago coming august
(1978!). They added L0 and L1 to some words, as a sort of level.
ISO has this system replaced by word sets. CORE CORE EXTENSIIONS and so
forth.
The implementator is allowed to write words in code instead of high level,
but the language makes no difference between code and high-level words.
--
Coos
CHForth, 16 bit DOS applications
http://home.hccnet.nl/j.j.haak/forth.html
Elizabeth D Rather
> Elizabeth D Rather wrote:
>
> ...
>
>> FWIW, the current version of this on our site is:
>
> ...
>
>> \ Washing machine functions
>
> ...
>
>> : DRAIN ( -- ) PUMP ON 3 MINUTES ;
>> : AGITATE ( -- ) MOTOR ON 10 MINUTES MOTOR OFF ;
>> : SPIN ( -- ) CLUTCH ON MOTOR ON
>> 5 MINUTES MOTOR OFF CLUTCH OFF PUMP OFF ;
>> : FILL-TUB ( -- ) FAUCETS ON TILL-FULL FAUCETS OFF ;
>>
>> \ Wash cycles
>> : WASH ( -- ) FILL-TUB DETERGENT ADD AGITATE DRAIN ;
>> : RINSE ( -- ) FILL-TUB AGITATE DRAIN ;
>>
>> \ Top-level control
>> : WASHER ( -- ) WASH SPIN RINSE SPIN ;
>
> ...
>
> So once the pump turns on, only SPIN turns it off?
Well, on all my (recent) machines the pump is certainly working
throughout the spin cycle (whose objective, after all, is to force out
more water).
I wish I could get my hands on the software for my new washer. When you
press the START button, it sits and "thinks" for more than a full minute
before turning on any water. And when it's all done and the last spin
is over, it waits another full minute before signaling that it's done
and unlocking the door. I can't for the life of me imagine what it's
doing all that time.
Jerry Avins
...
> PUMP ON \ PUMP is a variable
> ON PUMP \ ON is a variable
?? In the code, ON is a word. I would call it a verb of I bothered, but
I don't find such correspondences useful. PUMP is a constant. I would
call it a noun if I had to, but I'm glad I don't.
Marcel Hendrix
[..]
> I wish I could get my hands on the software for my new washer. When you
> press the START button, it sits and "thinks" for more than a full minute
> before turning on any water. And when it's all done and the last spin
> is over, it waits another full minute before signaling that it's done
> and unlocking the door. I can't for the life of me imagine what it's
> doing all that time.
It leaves you some time to get the cat out before it'll drown :-)
The wait before unlocking could be because for some combinations of
mechanical errors and light load it can't be sure the motor has spun
down completely.
-marcel
Elizabeth D Rather
> Alex McDonald wrote:
>
> ...
>
>> PUMP ON \ PUMP is a variable
>> ON PUMP \ ON is a variable
>
> ?? In the code, ON is a word. I would call it a verb of I bothered, but
> I don't find such correspondences useful. PUMP is a constant. I would
> call it a noun if I had to, but I'm glad I don't.
I really don't see a distinction between "nouns" and "verbs" in Forth.
They're all words, and they all have a behavior (semantics). Some words
are associated with some amount of data space, in which case their
behavior is to do something about that data space (return its address,
return its value, etc.). If you want to call words that have associated
data space "nouns" you're welcome to do so, but as a teacher of Forth
newbies I find it's helpful for them to understand that *all* words have
a behavior.
In fact, in recent years I've taught from the beginning that all words
have *two* behaviors, one at compile time and one at run time. That's a
new (but not very difficult) concept, and by the time I get to
CREATE/DOES> they just say, "Oh, cool!" and catch on right away.
Jerry Avins
> Jerry Avins wrote:
>> Alex McDonald wrote:
>>
>> ...
>>
>>> PUMP ON \ PUMP is a variable
>>> ON PUMP \ ON is a variable
>>
>> ?? In the code, ON is a word. I would call it a verb of I bothered,
>> but I don't find such correspondences useful. PUMP is a constant. I
>> would call it a noun if I had to, but I'm glad I don't.
>
> I really don't see a distinction between "nouns" and "verbs" in Forth.
> They're all words, and they all have a behavior (semantics). Some words
> are associated with some amount of data space, in which case their
> behavior is to do something about that data space (return its address,
> return its value, etc.). If you want to call words that have associated
> data space "nouns" you're welcome to do so, but as a teacher of Forth
> newbies I find it's helpful for them to understand that *all* words have
> a behavior.
>
> In fact, in recent years I've taught from the beginning that all words
> have *two* behaviors, one at compile time and one at run time. That's a
> new (but not very difficult) concept, and by the time I get to
> CREATE/DOES> they just say, "Oh, cool!" and catch on right away.
Some people like do make comparisons with natural and computer
languages. I have no desire to spoil their fun, even if I don't
participate. I think that Forth lends itself to that conceit more easily
than many other languages;your washing-machine is easily seen that way.
We could amuse ourselves and others with
: defend ( assailant -- ) Fido kill ;
but, as you wrote, it doesn't help understanding.
Ed
"Elizabeth D Rather" <erather...@spamfree.forth.com> wrote in message news:13p7k07...@news.supernews.com...
> ...
> I wish I could get my hands on the software for my new washer. When you
> press the START button, it sits and "thinks" for more than a full minute
> before turning on any water. And when it's all done and the last spin
> is over, it waits another full minute before signaling that it's done
> and unlocking the door. I can't for the life of me imagine what it's
> doing all that time.
Don't you have a forth-controlled robot to do all the house chores?
:)
Alex McDonald
It was difficult to choose an example. A PUMP or to PUMP; noun or
verb. To turn ON; the state of being ON. As Elizabeth says in her
post, not really a distinction worth making.
--
Regards
Alex McDonald
Jenny Brien
<erather...@spamfree.forth.com> wrote:
>
> I wish I could get my hands on the software for my new washer. When you
> press the START button, it sits and "thinks" for more than a full minute
> before turning on any water. And when it's all done and the last spin
> is over, it waits another full minute before signaling that it's done
> and unlocking the door. I can't for the life of me imagine what it's
> doing all that time.
>
In my machine (and probably yours too) that is done in hardware. The door
is locked by a bi-metallic strip thriough which the current runs. You
can't hurry differential expansion.
Rod Pemberton
"Jerry Avins" <j...@ieee.org> wrote in message
news:-vidnTpnpJ0Vnwna...@rcn.net...
> We could amuse ourselves and others with
> : defend ( assailant -- ) Fido kill ;
Aw, what happened to Fido?
:defend (assailant -- Fido) Fido kill;
Rod Pemberton
Mark W. Humphries
Why do we care? He's internal to the implementation of defend.
ken...@cix.compulink.co.uk
> I can't for the life of me imagine what it's
> doing all that time.
It may be a safety feature. Certainly the machine I have which is
getting on a bit does the same though the delay at each end is closer to
30 seconds than 60.
Ken Young
Jean-François Michaud
> Yeah, but at that point in my life they were the amateurs, while I was a
> seasoned professional programmer, steeped in the conventional wisdom. So
> I *should* have been better, and by the standards I had learned I was.
> But a quarter century later, those standards don't look so much like wisdom.
[SNIP]
Thats an interesting statement John because studies were conducted and
apparently, there is very weak correlation between efficiency and
experience as far as coding goes ;-).
Regards
Jean-Francois Michaud
Rod Pemberton
"Coos Haak" <chf...@hccnet.nl> wrote in message
news:1w65muvyxm1jx$.2i4ho7lbfitt$.dlg@40tude.net...
Those may have been a factor since fig-FORTH has "level 0," FORTH-79 and
FORTH-83 have "nucleus," and DPANS94 "core." But, I think I (re)found the
source of my understanding, part 1 of Brad Rodriguez's "Moving FORTH"
series:
"By 'kernel' I mean the set of words that comprises a basic Forth system,
including compiler and interpreter. For CamelForth this is the ANS Forth
Core word set, plus any non-ANSI words necessary to implement the Core word
set. A Forth kernel is usually written partly in machine code (as CODE
words), and partly in high-level Forth. The words which are written in
machine code are called the 'primitives,' since, in the final analysis, the
entire Forth system is defined in terms of just these words."
Brad Rodriquez's "Moving Forth"
http://www.zetetics.com/bj/papers/
Rod Pemberton
John Doty
> I really don't see a distinction between "nouns" and "verbs" in Forth.
> They're all words, and they all have a behavior (semantics). Some words
> are associated with some amount of data space, in which case their
> behavior is to do something about that data space (return its address,
> return its value, etc.). If you want to call words that have associated
> data space "nouns" you're welcome to do so, but as a teacher of Forth
> newbies I find it's helpful for them to understand that *all* words have
> a behavior.
You make a very persuasive case here for the proposition that Forth is
not a language, but merely a code for triggering behaviors in the
hardware. Your concept is similar to the triggers Pavlov used to trigger
behaviors in his dogs: I doubt anybody considers that language. Your
"words" lack the universal linguistic property of a role in grammar. So,
Forth must also not be a language, since it cannot have grammar, another
linguistic universal.
Perhaps it is more productive to consider Forth as an extensible
vocabulary. A vocabulary can be used in grammatical or ungrammatical
ways. Like a natural vocabulary, Forth does not enforce a grammar:
that's the job of its users. Unfortunately the Forth community has no
history of using or valuing grammar. Forth has therefore failed at a
critical function of language: to communicate to human beings. It's a
shame, because there's nothing about Forth that made this necessary.
--
John Doty, Noqsi Aerospace, Ltd.
http://www.noqsi.com/
--
History teaches that logical consistency is neither sufficient nor
Jerry Avins
...
> Forth has therefore failed at a
> critical function of language: to communicate to human beings.
If that doesn't beg the question, nothing does. Do you think you could
demonstrate your point without assuming it?
...
John Doty
> John Doty wrote:
>
> ...
>
>> Forth has therefore failed at a
>> critical function of language: to communicate to human beings.
>
> If that doesn't beg the question, nothing does. Do you think you could
> demonstrate your point without assuming it?
>
> ...
>
> Jerry
Don't you think Forth's reputation for producing "write only" code tells
the story here?
John Doty
>
> I see no reason why Forth should assume C's handcuffs.
Grammar handcuff of see assume I not English should. Readability who
about cares?
--
John Doty, Noqsi Aerospace, Ltd.
http://www.noqsi.com/
--
History teaches that logical consistency is neither sufficient nor
Jerry Avins
> Jerry Avins wrote:
>> John Doty wrote:
>>
>> ...
>>
>>> Forth has therefore failed at a
>>> critical function of language: to communicate to human beings.
>>
>> If that doesn't beg the question, nothing does. Do you think you could
>> demonstrate your point without assuming it?
>>
>> ...
>>
>> Jerry
>
> Don't you think Forth's reputation for producing "write only" code tells
> the story here?
That may or may not be true. It probably is for some, and assuredly is
not for others. Assuming that it's so, then using that assumption to
demonstrate that it's so, is a breakdown of logic. I'm disappointed.
John Passaniti
>> I see no reason why Forth should assume C's handcuffs.
>
> Grammar handcuff of see assume I not English should. Readability who
> about cares?
So readability is a universal constant, not something dictated by
experience with a particular language? Fascinating. Point me to that
study, please.
Elizabeth D Rather
> Elizabeth D Rather wrote:
>
>> I really don't see a distinction between "nouns" and "verbs" in Forth.
>> They're all words, and they all have a behavior (semantics). Some
>> words are associated with some amount of data space, in which case
>> their behavior is to do something about that data space (return its
>> address, return its value, etc.). If you want to call words that have
>> associated data space "nouns" you're welcome to do so, but as a
>> teacher of Forth newbies I find it's helpful for them to understand
>> that *all* words have a behavior.
>
> You make a very persuasive case here for the proposition that Forth is
> not a language, but merely a code for triggering behaviors in the
> hardware. Your concept is similar to the triggers Pavlov used to trigger
> behaviors in his dogs: I doubt anybody considers that language. Your
> "words" lack the universal linguistic property of a role in grammar. So,
> Forth must also not be a language, since it cannot have grammar, another
> linguistic universal.
Jean Sammett first made this observation in about 1972. Frankly, I
don't care one way or another: Forth is an incredibly useful and
powerful way to program computers. Call it what you will.
> Perhaps it is more productive to consider Forth as an extensible
> vocabulary. A vocabulary can be used in grammatical or ungrammatical
> ways. Like a natural vocabulary, Forth does not enforce a grammar:
> that's the job of its users.
I have no particular argument with this, but...
> Unfortunately the Forth community has no
> history of using or valuing grammar. Forth has therefore failed at a
> critical function of language: to communicate to human beings. It's a
> shame, because there's nothing about Forth that made this necessary.
...*this* assertion is not supported by any evidence.
Bernd Paysan
> Don't you think Forth's reputation for producing "write only" code tells
> the story here?
Perl has the same reputation. I think any sufficiently strange looking
language will get that reputation.
As I repeatedly stated, you might as well say "Chinese is unreadable". It
has everything to spoil readability to the western reader: A complex set of
strange glyphs, a rudimentary "grammar" that allows you to stick words
together in many unusual ways and the role they take comes from the
position within the sentence, and a vocabulary where your dictionary tells
you that each word maps to at least 10 wildly different terms in your own
language. And it's a language nobody speaks anymore (classical Chinese, at
least).
Yet, about 1 billion people can read what's written in this write-only
language (actually, they do have difficulties with classical Chinese, at
least when it's without punctuation. When you can stack words together in
many ways, knowing where a sentence starts and ends becomes much more
important - yet this information is omitted in classical Chinese. No wonder
they preferred rhymes with a 5-syllable-pattern back then).
Come on, John, when you like to have a popular language, you must make it
look like what people already know. It must have a feature set that doesn't
differ much from what people already know. I.e. it must be a small
incremental improvement of the current popular languages. Chuck Moore is
right: Nobody wants a new language, they only want a better Fortran. Still
true. Python and Ruby offer that, Forth doesn't.
--
Bernd Paysan
"If you want it done right, you have to do it yourself"
http://www.jwdt.com/~paysan/
astrobe
> > history of using or valuing grammar. Forth has therefore failed at a
> > critical function of language: to communicate to human beings. It's a
> > shame, because there's nothing about Forth that made this necessary.
>
> ...*this* assertion is not supported by any evidence.
>
And even if it is, one may discuss it. I'm not sure that "to
communicate with human beings" is a critical function of a programming
language. The primary purpose of a computer language is human/machine
communication (or to be accurate: it is for human to command the
machine). It's an artificial language, and different languages set
different balances between the human language and the language and the
machine. Forth attempts to stay halfway from both ends, so that each
end must produce a roughly equal effort to understand it (as far as a
machine understands anything).
As a consequence, Forth is not as readable as other languages whose
creators state that a computer language is also for human-to-human
communication, but no other interpreted language is as efficient as
Forth.
Amicalement,
Astrobe
Alex McDonald
> John Doty wrote:
> > Don't you think Forth's reputation for producing "write only" code tells
> > the story here?
>
> Perl has the same reputation. I think any sufficiently strange looking
> language will get that reputation.
>
> As I repeatedly stated, you might as well say "Chinese is unreadable". It
> has everything to spoil readability to the western reader: A complex set of
> strange glyphs, a rudimentary "grammar" that allows you to stick words
> together in many unusual ways and the role they take comes from the
> position within the sentence, and a vocabulary where your dictionary tells
> you that each word maps to at least 10 wildly different terms in your own
> language. And it's a language nobody speaks anymore (classical Chinese, at
> least).
I think Chinese and Forth are a pretty good fit, actually; one word
per glyph that encapsulates a concept. Chinese versions of Forth must
be fun and very intuitive for native modern Chinese writers and
readers. There is (as I noted a few months ago) a Chinese version of
Win32Forth. I suspect the early Egyptians would have enjoyed Forth
too.
>
> Yet, about 1 billion people can read what's written in this write-only
> language (actually, they do have difficulties with classical Chinese, at
> least when it's without punctuation. When you can stack words together in
> many ways, knowing where a sentence starts and ends becomes much more
> important - yet this information is omitted in classical Chinese. No wonder
> they preferred rhymes with a 5-syllable-pattern back then).
>
> Come on, John, when you like to have a popular language, you must make it
> look like what people already know. It must have a feature set that doesn't
> differ much from what people already know. I.e. it must be a small
> incremental improvement of the current popular languages. Chuck Moore is
> right: Nobody wants a new language, they only want a better Fortran. Still
> true. Python and Ruby offer that, Forth doesn't.
But then there's Lisp. How does it fair as a "living language"?
>
> --
> Bernd Paysan
> "If you want it done right, you have to do it yourself"http://www.jwdt.com/~paysan/
--
Regards
Alex McDonald
John Doty
Changing the subject again. Grammar is universal among languages
according to all of the linguistic literature I've ever read.
John Doty
> John Doty wrote:
>> Elizabeth D Rather wrote:
>>
>>> I really don't see a distinction between "nouns" and "verbs" in
>>> Forth. They're all words, and they all have a behavior (semantics).
>>> Some words are associated with some amount of data space, in which
>>> case their behavior is to do something about that data space (return
>>> its address, return its value, etc.). If you want to call words that
>>> have associated data space "nouns" you're welcome to do so, but as a
>>> teacher of Forth newbies I find it's helpful for them to understand
>>> that *all* words have a behavior.
>>
>> You make a very persuasive case here for the proposition that Forth is
>> not a language, but merely a code for triggering behaviors in the
>> hardware. Your concept is similar to the triggers Pavlov used to
>> trigger behaviors in his dogs: I doubt anybody considers that
>> language. Your "words" lack the universal linguistic property of a
>> role in grammar. So, Forth must also not be a language, since it
>> cannot have grammar, another linguistic universal.
>
> Jean Sammett first made this observation in about 1972.
But you've complained before that you don't think this right.
> Frankly, I
> don't care one way or another: Forth is an incredibly useful and
> powerful way to program computers. Call it what you will.
If it's so useful, where are all the libraries and applications? Other
programming techniques demonstrate their utility by publishing these.
>
>> Perhaps it is more productive to consider Forth as an extensible
>> vocabulary. A vocabulary can be used in grammatical or ungrammatical
>> ways. Like a natural vocabulary, Forth does not enforce a grammar:
>> that's the job of its users.
>
> I have no particular argument with this, but...
>
>> Unfortunately the Forth community has no history of using or valuing
>> grammar. Forth has therefore failed at a critical function of
>> language: to communicate to human beings. It's a shame, because
>> there's nothing about Forth that made this necessary.
>
> ....*this* assertion is not supported by any evidence.
No evidence that you care to perceive. But I work in the desert where
Forth is extinct. Where its former users have given up on it. Why would
they do that if it's as productive as you say?
Stephen Pelc
<j...@whispertel.LoseTheH.net> wrote:
>No evidence that you care to perceive. But I work in the desert where
>Forth is extinct. Where its former users have given up on it. Why would
>they do that if it's as productive as you say?
I could just as easily propose:
1) that you've created your own desert by evangelising a minority
language based itself on a minority lanaguage.
2) that (from all the evidence in c.l.f) the main person rubbishing
Forth is John Doty.
I hope that you don't rubbish Forth in your private desert, otherwise
we may assume that you are the architect of your own downfall.
Some of us do publish libraries and so on, but I get the distinct
impression that you haven't looked at what is available in modern
Forth systems. In the interest of science, please go survey what
is available before making statements about what is and what isn't
available. How many different Forth systems are your main PC? Apart
from the MPE versions, I have at least ten others that I survey.
Stephen
--
Stephen Pelc, steph...@mpeforth.com
MicroProcessor Engineering Ltd - More Real, Less Time
133 Hill Lane, Southampton SO15 5AF, England
tel: +44 (0)23 8063 1441, fax: +44 (0)23 8033 9691
web: http://www.mpeforth.com - free VFX Forth downloads
Jerry Avins
> John Passaniti wrote:
>> John Doty wrote:
>>>> I see no reason why Forth should assume C's handcuffs.
>>>
>>> Grammar handcuff of see assume I not English should. Readability who
>>> about cares?
>>
>> So readability is a universal constant, not something dictated by
>> experience with a particular language? Fascinating. Point me to that
>> study, please.
>
> Changing the subject again. Grammar is universal among languages
> according to all of the linguistic literature I've ever read.
A universal attribute perhaps; certainly not a universal grammar.
John Doty
> John Doty wrote:
>> Don't you think Forth's reputation for producing "write only" code tells
>> the story here?
>
> Perl has the same reputation. I think any sufficiently strange looking
> language will get that reputation.
>
> As I repeatedly stated, you might as well say "Chinese is unreadable". It
> has everything to spoil readability to the western reader: A complex set of
> strange glyphs, a rudimentary "grammar" that allows you to stick words
> together in many unusual ways and the role they take comes from the
> position within the sentence, and a vocabulary where your dictionary tells
> you that each word maps to at least 10 wildly different terms in your own
> language. And it's a language nobody speaks anymore (classical Chinese, at
> least).
Yes, but I expect it's even harder to write than to read: I know
Japanese is. Indeed, my Japanese colleagues complain that they are
losing the ability to write the characters by hand. They mostly write it
the same way I do: they type phonetically, let the computer guess the
character, and correct via menu as required.
This seems a general property of natural language: writing is the most
difficult skill. Formal languages are different, generally harder to
read than to write. But it's a matter of degree: I think few are as
unsymmetrical as Forth.
>
> Yet, about 1 billion people can read what's written in this write-only
> language (actually, they do have difficulties with classical Chinese, at
> least when it's without punctuation. When you can stack words together in
> many ways, knowing where a sentence starts and ends becomes much more
> important - yet this information is omitted in classical Chinese. No wonder
> they preferred rhymes with a 5-syllable-pattern back then).
>
> Come on, John, when you like to have a popular language, you must make it
> look like what people already know.
That helps. Fortran survives largely because readability by people with
applied math backgrounds was a priority in its design, I think. That
Forth has always had a tradition of being willfully bizarre is an
unnecessary weakness. Rather than make excuses, we should be fixing this.
> It must have a feature set that doesn't
> differ much from what people already know. I.e. it must be a small
> incremental improvement of the current popular languages. Chuck Moore is
> right: Nobody wants a new language, they only want a better Fortran. Still
> true. Python and Ruby offer that, Forth doesn't.
And yet Forth was embraced by the aerospace and astronomy communities
three decades ago. It *was* what they already knew at the time C started
its penetration (I was there). And now C is a major force, while Forth
is practically extinct in those areas. So your explanation doesn't fit
the actual history.
Bernd Paysan
> A universal attribute perhaps; certainly not a universal grammar.
The attribute for sure is universal. A language consists of vocabulary and
grammar, or if you express it differently, you'd say words and rules how to
put words together. Both words and rules define the semantics of a
statement in any given language, if you omit either one, you just can't
express anything.
In so far, Forth has words and some rules, but the rules are simple and few.
Other languages have more complicated rules. That's how things are - the
book I used to learn Chinese contained about 50 chapters, most of them
featured how to translate a particular grammatical construct in German to
Chinese. It's a grammatical concept in German, but it usually fits within
the simple Chinese grammar, and is *not* a particular construct there. It
usually simply follows the more general rules, i.e. the subject verb object
rule. The good thing is that the modern German dialects have developed into
the same direction, and used remarkable similar constructs for things that
are grammatical in German (in Bavarian, one case completely vanished, only
two time forms are used regularly - and the way to express the rest is
homomorph to the way Chinese does).
The universal grammar of (most) programming languages is that statements are
executed sequentially, and that there are constructs like loops and
alternative branches, functions and subroutines. Forth does have all those
grammatical elements, and the statement is the word. Most other languages
have rules for possible statements, and differ between function calls and
primitive operations, Forth doesn't. But then, if you ask a Latin teacher
what constitutes "grammar" (in Latin), he probably tells you that a
language has gender, case, and tempus, and that words change depending on
gender, case, and tempus (remember the "Romanus eunt domus" scene in "Life
of Brian" ;-). Chinese has none of these features; i.e. "no grammar",
so "luomaren qu jia" is both a literal translation of what Brian had
written, and also grammatically perfectly ok (not ok in intention to insult
them: "qu si ba" (go to hell) is more appropriate).
John Doty
> On Tue, 22 Jan 2008 07:56:07 -0700, John Doty
> <j...@whispertel.LoseTheH.net> wrote:
>
>> No evidence that you care to perceive. But I work in the desert where
>> Forth is extinct. Where its former users have given up on it. Why would
>> they do that if it's as productive as you say?
>
> I could just as easily propose:
>
> 1) that you've created your own desert by evangelising a minority
> language based itself on a minority lanaguage.
Not true. I pretty much quit using Forth around 1990, when I was working
on big projects with cultures that didn't include it. But a few years
ago I started working with on new projects, starting from scratch, and
Forth seemed like a good tool again. So I looked around to see what
people were doing with it, and there was almost nothing to be found.
> 2) that (from all the evidence in c.l.f) the main person rubbishing
> Forth is John Doty.
You think *I* trash Forth? I *like* Forth. I trash those who have ruined
it as a useful tool for real users.
When I was on a NASA review committee a couple of years ago, there was
one project that actually proposed to use Forth. I had language trashing
Forth *removed* from the committee's report: the other members didn't
think much of it. "Write-only", "obsolete", etc.
You don't see the private mail I get from people who read what I've
posted. Almost all agrees with my analysis of the sorry state of Forth,
but most correspondents feel it's hopeless, I'm wasting my time. I'm not
quite so pessimistic.
>
> I hope that you don't rubbish Forth in your private desert, otherwise
> we may assume that you are the architect of your own downfall.
I would love to hook up with a project using Forth. Any dialect, I'm
flexible. But most real computer users aren't so flexible, and if I want
to benefit from their strengths I have to accommodate them.
>
> Some of us do publish libraries and so on, but I get the distinct
> impression that you haven't looked at what is available in modern
> Forth systems.
I have. You think the FSL can be compared to the GSL or Numpy? It's like
comparing a tricycle to a complete transportation system.
> In the interest of science, please go survey what
> is available before making statements about what is and what isn't
> available. How many different Forth systems are your main PC? Apart
> from the MPE versions, I have at least ten others that I survey.
Indeed. Forth is very implementor friendly. But what implementors don't
understand is that real users have abandoned it. I'd be perfectly happy
with one implementation *if* it had a vital user community. But Forth
has no capacity in its present form to attract such a community. Indeed,
it has almost completely driven away the community it once had.
John Doty
> John Doty wrote:
>> John Passaniti wrote:
>>> John Doty wrote:
>>>>> I see no reason why Forth should assume C's handcuffs.
>>>>
>>>> Grammar handcuff of see assume I not English should. Readability who
>>>> about cares?
>>>
>>> So readability is a universal constant, not something dictated by
>>> experience with a particular language? Fascinating. Point me to
>>> that study, please.
>>
>> Changing the subject again. Grammar is universal among languages
>> according to all of the linguistic literature I've ever read.
>
> A universal attribute perhaps; certainly not a universal grammar.
Linguists use the term "universal grammar" to describe the common
features all natural grammars share. One of these is (implicit) tree
structure, a feature Forth violates.
John Doty
> John Doty wrote:
>> Jerry Avins wrote:
>>> John Doty wrote:
>>>
>>> ...
>>>
>>>> Forth has therefore failed at a
>>>> critical function of language: to communicate to human beings.
>>>
>>> If that doesn't beg the question, nothing does. Do you think you
>>> could demonstrate your point without assuming it?
>>>
>>> ...
>>>
>>> Jerry
>>
>> Don't you think Forth's reputation for producing "write only" code
>> tells the story here?
>
> That may or may not be true. It probably is for some, and assuredly is
> not for others. Assuming that it's so, then using that assumption to
> demonstrate that it's so, is a breakdown of logic. I'm disappointed.
I'm disappointed that you don't understand logic. Logic is part of the
story we tell each other about what works in reality. But reality is
what counts: you can tell the most logical story in the world and it's
still false if reality doesn't match it. And an illogical theory (such
as calculus was for 200 years) can still be useful and have tremendous
predictive power in reality.
> Engineering is the art of making what you want from things you can get.
Engineering is the art of making what *others* can use.
Jerry Avins
> Jerry Avins wrote:
>> John Doty wrote:
>>> John Passaniti wrote:
>>>> John Doty wrote:
>>>>>> I see no reason why Forth should assume C's handcuffs.
>>>>>
>>>>> Grammar handcuff of see assume I not English should. Readability
>>>>> who about cares?
>>>>
>>>> So readability is a universal constant, not something dictated by
>>>> experience with a particular language? Fascinating. Point me to
>>>> that study, please.
>>>
>>> Changing the subject again. Grammar is universal among languages
>>> according to all of the linguistic literature I've ever read.
>>
>> A universal attribute perhaps; certainly not a universal grammar.
>
> Linguists use the term "universal grammar" to describe the common
> features all natural grammars share. One of these is (implicit) tree
> structure, a feature Forth violates.
Forth is not a natural language. What's your point?
Anton Ertl
>But, I think I (re)found the
>source of my understanding, part 1 of Brad Rodriguez's "Moving FORTH"
>series:
>
>"By 'kernel' I mean the set of words that comprises a basic Forth system,
>including compiler and interpreter. For CamelForth this is the ANS Forth
>Core word set, plus any non-ANSI words necessary to implement the Core word
>set. A Forth kernel is usually written partly in machine code (as CODE
>words), and partly in high-level Forth. The words which are written in
>machine code are called the 'primitives,' since, in the final analysis, the
>entire Forth system is defined in terms of just these words."
Yes, for a particular Forth system you have a division into primitives
and other words, and usually also between kernel and rest. E.g.,
Gforth has an engine (which contains the primitives) and the image
(which contains the non-primitives); it also has a kernel image
(kernl*.fi), and a complete image (gforth.fi).
However, these divisions are implementation-specific and caused by
implementation concerns, and not particularly aligned with language
concepts or standards layers like CORE and other wordsets. E.g.,
Gforth implements non-core words like OPEN-FILE and non-standard words
like >= as primitives, and implements a CORE word like ENVIRONMENT? in
neither the engine nor the kernel.
- anton
--
M. Anton Ertl http://www.complang.tuwien.ac.at/anton/home.html
comp.lang.forth FAQs: http://www.complang.tuwien.ac.at/forth/faq/toc.html
New standard: http://www.forth200x.org/forth200x.html
EuroForth 2008: http://www.complang.tuwien.ac.at/anton/euroforth/ef08.html
Marc Olschok
> Elizabeth D Rather wrote:
>
> >
> > I see no reason why Forth should assume C's handcuffs.
>
> Grammar handcuff of see assume I not English should. Readability who
> about cares?
It does not help your case when you strip the context in order to
misinterprete Elizabeths comment, which was adressed at a specific
requirement of yours:
(from <13p75a7...@news.supernews.com>)
|
| >>>> If you like rules, in a Forth context:
| >>>> 1. A word should consume all of its arguments, and yield at most
| >>>> one result.
|
| I see no reason why Forth should assume C's handcuffs. Even FORTRAN
| could return multiple results.
So the issue was, whether restricting words to one result only makes
sense in a Forth context.
Strictly speaking one could say that Forth words do this anyway:
they always consume one argumemt (of type stack) and yield exactly
one result (also of type stack). But of course that is not what you
meant here, you took issue with words like e.g.
count with stack effect ( adr --- adr' n )
which apparently leaves two results on the stack.
But conceptually it leaves one argument of type string on the stack,
it is just that in Forth intended types are not made explicit.
The reason why the restriction to "one result only" is not felt to be
a "handcuff" in other languages is the _explicit_ use of types.
I leave it to you to muse on the practicality of introducing
typed stacks to Forth in order to have stack effects
like ( adr:Int --- <adr',n>:Int*Int )
or even better ( x:cstring --- x':bostring )
Of course, since only product types of Int are needed, the above
is not necessary. Instead one could use the projections to the
factors in order to decompose words with more than one result.
So e.g. instead of the above count one could use
start with stack effect ( adr --- adr' )
length with stack effect ( adr --- n )
Such decompositions are useful, especially when only part of the result
is needed, like with /mod decomposed as / and mod.
But still it is nice to have also /mod available
and I doubt whether users will be keen to use
dup start swap length instead of count
Marc
John Doty
> John Doty wrote:
>> Jerry Avins wrote:
>>> John Doty wrote:
>>>> John Passaniti wrote:
>>>>> John Doty wrote:
>>>>>>> I see no reason why Forth should assume C's handcuffs.
>>>>>>
>>>>>> Grammar handcuff of see assume I not English should. Readability
>>>>>> who about cares?
>>>>>
>>>>> So readability is a universal constant, not something dictated by
>>>>> experience with a particular language? Fascinating. Point me to
>>>>> that study, please.
>>>>
>>>> Changing the subject again. Grammar is universal among languages
>>>> according to all of the linguistic literature I've ever read.
>>>
>>> A universal attribute perhaps; certainly not a universal grammar.
>>
>> Linguists use the term "universal grammar" to describe the common
>> features all natural grammars share. One of these is (implicit) tree
>> structure, a feature Forth violates.
>
> Forth is not a natural language. What's your point?
As I have stated repeatedly, it is important for a language to engage
the powerful human linguistic facility instead of fighting against it.
Other programming languages generally do have tree structured grammars.
John Doty
> John Doty <j...@whispertel.losetheh.net> wrote:
>> Elizabeth D Rather wrote:
>>
>>> I see no reason why Forth should assume C's handcuffs.
>> Grammar handcuff of see assume I not English should. Readability who
>> about cares?
>
> It does not help your case when you strip the context in order to
> misinterprete Elizabeths comment, which was adressed at a specific
> requirement of yours:
>
> (from <13p75a7...@news.supernews.com>)
> |
> | >>>> If you like rules, in a Forth context:
> | >>>> 1. A word should consume all of its arguments, and yield at most
> | >>>> one result.
> |
> | I see no reason why Forth should assume C's handcuffs. Even FORTRAN
> | could return multiple results.
>
> So the issue was, whether restricting words to one result only makes
> sense in a Forth context.
You can't have a tree structured grammar without that restriction. The
question is one of language and using Forth as a language, not merely a
code.
>
> Strictly speaking one could say that Forth words do this anyway:
> they always consume one argumemt (of type stack) and yield exactly
> one result (also of type stack). But of course that is not what you
> meant here, you took issue with words like e.g.
>
> count with stack effect ( adr --- adr' n )
>
> which apparently leaves two results on the stack.
Note that it was not me who mentioned this example.
> But conceptually it leaves one argument of type string on the stack,
> it is just that in Forth intended types are not made explicit.
Only if you then use it atomically in a subsequent word can that be
considered true. But if the count and addr have separate paths through
the subsequent code, you have an ungrammatical network of relations, not
a grammatical tree.
>
> The reason why the restriction to "one result only" is not felt to be
> a "handcuff" in other languages is the _explicit_ use of types.
That's part of it.
>
> I leave it to you to muse on the practicality of introducing
> typed stacks to Forth in order to have stack effects
> like ( adr:Int --- <adr',n>:Int*Int )
> or even better ( x:cstring --- x':bostring )
Languages don't have "stack effects": languages engage the unconscious
human capacity to manipulate mental stacks implicitly. The human reader
of a language need not even know what a stack is.
>
> Of course, since only product types of Int are needed, the above
> is not necessary. Instead one could use the projections to the
> factors in order to decompose words with more than one result.
> So e.g. instead of the above count one could use
>
> start with stack effect ( adr --- adr' )
> length with stack effect ( adr --- n )
>
> Such decompositions are useful, especially when only part of the result
> is needed, like with /mod decomposed as / and mod.
> But still it is nice to have also /mod available
Nice for the coder. A barrier to readability, as it is ungrammatical.
Coddle the coder, you get "write only" code.
> and I doubt whether users will be keen to use
> dup start swap length instead of count
That's not a sane alternative. It is not language, only code. Think
about how you would avoid the ungrammatical DUP and SWAP.
Rod Pemberton
"Jerry Avins" <j...@ieee.org> wrote in message
news:6LidnToYpN4tqgva...@rcn.net...
> Forth is not a natural language. What's your point?
>
Yes, I agree, what is his point? I've picked up many programming languages
easily. Written and spoken languages are hard by comparison. So, why would
I want a programming language to have the characteristics of English (or
French, German, Spanish)? It'd only make my life and programming worse.
Clearly using a native language like English is preferred by some, maybe
many, but not all. And then you have to ask, "Are those who prefer to
program in an English-like language, the ones you really want programming?"
My experiences indicate that those who prefer such tend not to be
mathematically inclined and lack the ability to abstract ideas - both
important for a programmer. Does it make much sense to use a programmer
with an average mind with average skills to program something created by
someone with a brilliant mind, e.g., electronic circuit designer? I
understand cost pressures are driving the software industry to embrace less
skilled and lower intellect individuals, but just what type of language
would you need to allow them program well? COBOL? What if the government
came out and declared that all future software they license must be
maintainable by someone with an IQ of 70?
Rod Pemberton
Alex McDonald
> Marc Olschok wrote:
> > John Doty <j...@whispertel.losetheh.net> wrote:
[snip]
>
> > and I doubt whether users will be keen to use
> > dup start swap length instead of count
>
> That's not a sane alternative. It is not language, only code. Think
> about how you would avoid the ungrammatical DUP and SWAP.
I think it's about time you let us in on the secret, since you've
thought about it. Personally, I'm puzzled (yet again) by your almost
Delphic answers.
>
> --
> John Doty, Noqsi Aerospace, Ltd.http://www.noqsi.com/
> --
> 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.
--
Regards
Alex McDonald
Jerry Avins
...
>> Forth is not a natural language. What's your point?
>
> As I have stated repeatedly, it is important for a language to engage
> the powerful human linguistic facility instead of fighting against it.
> Other programming languages generally do have tree structured grammars.
Maybe I'm just a linear thinker. Forth seems to be a good fit. Words in
Forth are like knobs and levers on a machine. I wonder: does anyone
think of the controls on a backhoe as having a grammar?
John Doty
> "Jerry Avins" <j...@ieee.org> wrote in message
> news:6LidnToYpN4tqgva...@rcn.net...
>> Forth is not a natural language. What's your point?
>>
>
> Yes, I agree, what is his point? I've picked up many programming languages
> easily. Written and spoken languages are hard by comparison. So, why would
> I want a programming language to have the characteristics of English (or
> French, German, Spanish)? It'd only make my life and programming worse.
Clearly there are differences between a natural language and a
programming language. Here we agree. But those differences need to
reflect the differences in the uses of the language. Successful
programming languages do have grammar along with symbols that behave
like nouns, verbs, conjunctions, etc.
> Clearly using a native language like English is preferred by some, maybe
> many, but not all. And then you have to ask, "Are those who prefer to
> program in an English-like language, the ones you really want programming?"
> My experiences indicate that those who prefer such tend not to be
> mathematically inclined and lack the ability to abstract ideas - both
> important for a programmer. Does it make much sense to use a programmer
> with an average mind with average skills to program something created by
> someone with a brilliant mind, e.g., electronic circuit designer?
Does it make sense to use a programmer here at all? Shouldn't the
circuit designer be writing the code rather than wasting time
programming a programmer to do it? Programmers are more difficult to
program than computers are. Then, shouldn't the users of the device take
over the code and adapt it to their needs?
> I
> understand cost pressures are driving the software industry to embrace less
> skilled and lower intellect individuals, but just what type of language
> would you need to allow them program well? COBOL? What if the government
> came out and declared that all future software they license must be
> maintainable by someone with an IQ of 70?
You misunderstand the role in which the professional programmer is
effective. Maintaining code, porting code, polishing code, tracking down
the odd recalcitrant bug, setting up regression tests, etc., etc. All
things you cannot expect users to do, and where a good professional
programmer shines. But programmers should not delude themselves that
they can take over design and coding, at least in my world. The
application and its users have to come first, and programmers generally
lack the background to comprehend either.
It's like having a technical writer assist in the composition of a
manuscript. You can't expect such a person to write it from scratch:
you, the expert, must draft something containing all of the information
to be communicated. Then you and the technical writer can work it over
together to make it clean and clear.
The language must therefore be adapted to the needs of the users and the
application area, not to the prejudices of programmers. It's the users
that decide. In my world, they once were very enthusiastic about Forth.
But then alternatives appeared, Forth stagnated, and eventually it all
but disappeared. It's a shame, because the alternatives still have
weaknesses where Forth has strengths. Unfortunately, Forth's own
weaknesses have been too great. But maybe we can fix them and create a
usable 21st century language with Forth's strengths.
John Doty
> John Doty wrote:
>
> ...
>
>>> Forth is not a natural language. What's your point?
>>
>> As I have stated repeatedly, it is important for a language to engage
>> the powerful human linguistic facility instead of fighting against it.
>> Other programming languages generally do have tree structured grammars.
>
> Maybe I'm just a linear thinker. Forth seems to be a good fit. Words in
> Forth are like knobs and levers on a machine. I wonder: does anyone
> think of the controls on a backhoe as having a grammar?
That's the hermit programmer viewpoint, again. Yes, it's easy to use
levers by yourself, but it's hard to collaborate without language.
I have no quarrel at all with the proposition that Forth, as it exists,
can be the ideal programming system for the lone engineer/programmer who
is doing everything in a project. Such projects are rare, though. It's a
collaborative world.
John Doty
> On Jan 22, 8:12 pm, John Doty <j...@whispertel.LoseTheH.net> wrote:
>> Marc Olschok wrote:
>>> John Doty <j...@whispertel.losetheh.net> wrote:
>
> [snip]
>
>>> and I doubt whether users will be keen to use
>>> dup start swap length instead of count
>> That's not a sane alternative. It is not language, only code. Think
>> about how you would avoid the ungrammatical DUP and SWAP.
>
> I think it's about time you let us in on the secret, since you've
> thought about it. Personally, I'm puzzled (yet again) by your almost
> Delphic answers.
One gets very tired of making the same point over and over. Please
reread what you snipped. And don't assume that just because I can
recognize an unclad emperor I am an expert tailor.
Jerry Avins
> Jerry Avins wrote:
>> John Doty wrote:
>>
>> ...
>>
>>>> Forth is not a natural language. What's your point?
>>>
>>> As I have stated repeatedly, it is important for a language to engage
>>> the powerful human linguistic facility instead of fighting against
>>> it. Other programming languages generally do have tree structured
>>> grammars.
>>
>> Maybe I'm just a linear thinker. Forth seems to be a good fit. Words
>> in Forth are like knobs and levers on a machine. I wonder: does anyone
>> think of the controls on a backhoe as having a grammar?
>
> That's the hermit programmer viewpoint, again. Yes, it's easy to use
> levers by yourself, but it's hard to collaborate without language.
>
> I have no quarrel at all with the proposition that Forth, as it exists,
> can be the ideal programming system for the lone engineer/programmer who
> is doing everything in a project. Such projects are rare, though. It's a
> collaborative world.
I'm retired now, but I used to collaborate with a small team. W
communicated in English and coded in Forth with good success in both.
John Doty
> John Doty wrote:
>> Jerry Avins wrote:
>>> John Doty wrote:
>>>
>>> ...
>>>
>>>>> Forth is not a natural language. What's your point?
>>>>
>>>> As I have stated repeatedly, it is important for a language to
>>>> engage the powerful human linguistic facility instead of fighting
>>>> against it. Other programming languages generally do have tree
>>>> structured grammars.
>>>
>>> Maybe I'm just a linear thinker. Forth seems to be a good fit. Words
>>> in Forth are like knobs and levers on a machine. I wonder: does
>>> anyone think of the controls on a backhoe as having a grammar?
>>
>> That's the hermit programmer viewpoint, again. Yes, it's easy to use
>> levers by yourself, but it's hard to collaborate without language.
>>
>> I have no quarrel at all with the proposition that Forth, as it
>> exists, can be the ideal programming system for the lone
>> engineer/programmer who is doing everything in a project. Such
>> projects are rare, though. It's a collaborative world.
>
> I'm retired now, but I used to collaborate with a small team. W
> communicated in English and coded in Forth with good success in both.
Yes, but did you import code from other teams? Was English everybody's
first language? Were you all skilled programmers?
That Forth works in a minority of cases is irrelevant to my point. That
the vast majority of former Forth users in my world have abandoned it is
irrefutable and requires understanding if Forth is to prosper there
again. I don't have all the answers, but I know that denying the problem
will not solve it.
Jerry Avins
> Jerry Avins wrote:
>> John Doty wrote:
>>> Jerry Avins wrote:
>>>> John Doty wrote:
>>>>
>>>> ...
>>>>
>>>>>> Forth is not a natural language. What's your point?
>>>>>
>>>>> As I have stated repeatedly, it is important for a language to
>>>>> engage the powerful human linguistic facility instead of fighting
>>>>> against it. Other programming languages generally do have tree
>>>>> structured grammars.
>>>>
>>>> Maybe I'm just a linear thinker. Forth seems to be a good fit. Words
>>>> in Forth are like knobs and levers on a machine. I wonder: does
>>>> anyone think of the controls on a backhoe as having a grammar?
>>>
>>> That's the hermit programmer viewpoint, again. Yes, it's easy to use
>>> levers by yourself, but it's hard to collaborate without language.
>>>
>>> I have no quarrel at all with the proposition that Forth, as it
>>> exists, can be the ideal programming system for the lone
>>> engineer/programmer who is doing everything in a project. Such
>>> projects are rare, though. It's a collaborative world.
>>
>> I'm retired now, but I used to collaborate with a small team. W
>> communicated in English and coded in Forth with good success in both.
>
> Yes, but did you import code from other teams? Was English everybody's
> first language? Were you all skilled programmers?
No. One lady, the only programmerby profession, was from Venezuela.
Another engineer spent WW II in Italy, where he was born. One of the
others and I are electrical engineers, and the last member of out
customary team was a mechanical engineer.
> That Forth works in a minority of cases is irrelevant to my point. That
> the vast majority of former Forth users in my world have abandoned it is
> irrefutable and requires understanding if Forth is to prosper there
> again. I don't have all the answers, but I know that denying the problem
> will not solve it.
I understand your point, and I think there's some validity to it,
especially these days when people treat computers like magic boxes. I
had occasion to write this this morning to someone who wondered why his
timer code didn't work even after learning that a call to CLK_gethtime()
always returned zero:
Is there a running timer? You would probably understand your
question if you understood how CLK_gethtime() works. Nothing about
a computer is magic. Treating functions as if they were magic can
sometimes work with high-level languages. Sometimes, though, real
understanding is required.
A car seems to run by magic to someone who has never opened the
hood (bonnet). The genie that makes it go is called an N-djinn.
People like that can't use Forth. Still, although I've written my own
timing routines in Forth, I'm glad that Forth, Inc and MPE supply such
code with their systems.
Alex McDonald
> Alex McDonald wrote:
> > On Jan 22, 8:12 pm, John Doty <j...@whispertel.LoseTheH.net> wrote:
> >> Marc Olschok wrote:
> >>> John Doty <j...@whispertel.losetheh.net> wrote:
>
> > [snip]
>
> >>> and I doubt whether users will be keen to use
> >>> dup start swap length instead of count
> >> That's not a sane alternative. It is not language, only code. Think
> >> about how you would avoid the ungrammatical DUP and SWAP.
>
> > I think it's about time you let us in on the secret, since you've
> > thought about it. Personally, I'm puzzled (yet again) by your almost
> > Delphic answers.
>
> One gets very tired of making the same point over and over. Please
> reread what you snipped.
You grammar is unimpeachable, but the meaning is lost on me. I really
do have difficulty identifying the point that you are making, both to
me in other parts of this thread, and to this specific post. My
snipping is indicative of that difficulty, if you believe that it
contains some truth you believe you have revealed. I can't see it.
I've patiently read and re-read and still don't understand how a Forth
is to be rid of the "ungrammatical" DUP and SWAP.
Or perhaps you mean, for Mark's example, COUNT. There, have I solved
it?
> And don't assume that just because I can
> recognize an unclad emperor I am an expert tailor.
Noted. How unsatisfying. We shall just have to live with a naked
emperor and the poor tailors we have.
--
Regards
Alex McDonald
John Passaniti
>>> Grammar handcuff of see assume I not English should. Readability who
>>> about cares?
>>
>> So readability is a universal constant, not something dictated by
>> experience with a particular language? Fascinating. Point me to that
>> study, please.
>
> Changing the subject again. Grammar is universal among languages
> according to all of the linguistic literature I've ever read.
Fascinating. You bring up readability. I comment on it by asking a
question. Then you tell me I'm changing the subject. Fascinating.
I don't know why people talk about Forth as not having a grammar. It
doesn't have a grammar that can be described with EBNF or related
formalisms, but that's not the only method a linguist may use to
describe a language's grammar. Forth's grammar is defined in terms of
state changes caused by words and parsing words.
You seem to be freaking out about Forth's ability to return more than
one value from a word-- that this is somehow not "linguistic." Yet in
most rational examples of this, the multiple returns are related. A
word for example that returns a string as an address and count has two
items on the stack, but they are usually treated semantically as a
single entity.
This bundling together of semantically-related content is very
"linguistic" and relates directly to human experience. If you asked me
for my home address, I will give you a minimum of four separate pieces
of information-- house number, street, city, and state. In natural
conversation, I would express this as "3003 Elmwood Avenue, Rochester,
NY". In Forth, I might choose to represent this as multiple entries on
a stack as a return from a word. In Python, I might return a tuple. In
Lua, I would return a table. In Lisp, I would return a list.
That Forth doesn't have a dedicated data structure for making a tuple
doesn't make separate entries on a stack any less a tuple. It is
conceptually the same thing. Do you fault Python for not being
"linguistic" because it supports multiple return values?
Here's a fun idea. You keep tossing out verbiage that presumably
supports your argument. But what I'm not seeing are real-world examples
that illustrate your point. Show me, for example, some Forth code that
returns multiple values from a word, and how this isn't "linguistic."
Then, show us the same in lovely shiny LSE64. I'm sure we'll all fall
down trembling at the stunning beauty of it, and throw Forth away.
John Passaniti
>> Frankly, I don't care one way or another: Forth is an incredibly
>> useful and powerful way to program computers. Call it what you will.
>
> If it's so useful, where are all the libraries and applications? Other
> programming techniques demonstrate their utility by publishing these.
While I agree there is a need for more authors to publish libraries,
this argument isn't valid. Something doesn't have to be published to be
useful. Or was LSE64 useless before you published it?
By the way, you've described LSE64 as useful. Yet, I don't see any
libraries for it. You know, other programming languages demonstrate
their utility by publishing these. Or so I've heard.
John Doty
> John Doty wrote:
...
>
> doesn't have a grammar that can be described with EBNF or related
> formalisms, but that's not the only method a linguist may use to
> describe a language's grammar. Forth's grammar is defined in terms of
> state changes caused by words and parsing words.
Every grammar is isomorphic to some state machine, true, but not every
state machine is isomorphic to a grammar.
>
> You seem to be freaking out about Forth's ability to return more than
> one value from a word-- that this is somehow not "linguistic." Yet in
> most rational examples of this, the multiple returns are related. A
> word for example that returns a string as an address and count has two
> items on the stack, but they are usually treated semantically as a
> single entity.
I agree with you if that's how the code works consistently. The real
problem comes downstream, where the next words do not necessarily
respect the single entity status.
>
> This bundling together of semantically-related content is very
> "linguistic" and relates directly to human experience. If you asked me
> for my home address, I will give you a minimum of four separate pieces
> of information-- house number, street, city, and state. In natural
> conversation, I would express this as "3003 Elmwood Avenue, Rochester,
> NY". In Forth, I might choose to represent this as multiple entries on
> a stack as a return from a word. In Python, I might return a tuple. In
> Lua, I would return a table. In Lisp, I would return a list.
Yes, and now that you've told me that, I know that "your street" is
"Elmwood Avenue". But in Forth, I would know what? That some anonymous
"" that I have to mentally track is "Elmwood Avenue". Natural language
is tree structured: a phrase has at most one "output". Phrases also have
"side effects" that provide additional channels of communication
forward, even between sentences. But to access these channels you have
to use more language, generally nouns or pronouns.
That's the kind of linguistic clue to the reader that bad Forth code
lacks. Data items disappear from from sight and pop up anonymously later
via paths that lack the discipline of grammar. Readable programming
languages use variables here.
>
> That Forth doesn't have a dedicated data structure for making a tuple
> doesn't make separate entries on a stack any less a tuple. It is
> conceptually the same thing. Do you fault Python for not being
> "linguistic" because it supports multiple return values?
No, I do not, because Python has the discipline of a grammar. A tuple is
a single grammatical object, and when you disassemble it, you do so
grammatically. No phrase in Python has more than a single output. Bits
of a tuple never disappear from sight to surface anonymously later.
>
> Here's a fun idea. You keep tossing out verbiage that presumably
> supports your argument. But what I'm not seeing are real-world examples
> that illustrate your point. Show me, for example, some Forth code that
> returns multiple values from a word, and how this isn't "linguistic."
I already did. Your memory is short:
11/19/07:
John Passaniti wrote:
> John Doty wrote:
>> You have the "degenerate" case. For those examples, the two threads
of of the net are parallel, so the "tree" and "network" are isomorphic.
But they don't have to be in Forth (I don't know Lua).
>
> Please provide an example to illustrate your point.
From the FSL:
: mu/ ( ud u--ud ) >R 0 R@ UM/MOD R> SWAP >R um/ R> ;
Try diagramming that as a tree!
John Doty
LSE64, like other Forth dialects, is mostly useful to hermits and small
teams of just the right composition. I have not solved that problem. I
have gotten some ideas from these discussions, but it will probably be a
while before I find time to really work on them. I keep hoping somebody
smarter than me will tune in and address these problems. I see some
ideas here that could potentially be part of a 21st century language
that could reclaim Forth's niche, but nothing that puts all of the
pieces together. Forth needs a Ritchie, and I'm not him: I'm just a
thoroughly disgruntled user.
But remember, my focus is reclaiming Forth's lost niche with
*something*. I don't really care too much what it is, as long as the
user communities are willing to embrace it. But if you don't see that as
a useful goal we have little to discuss.
Elizabeth D Rather
> Jerry Avins wrote:
>>
>> Maybe I'm just a linear thinker. Forth seems to be a good fit. Words
>> in Forth are like knobs and levers on a machine. I wonder: does anyone
>> think of the controls on a backhoe as having a grammar?
>
> That's the hermit programmer viewpoint, again. Yes, it's easy to use
> levers by yourself, but it's hard to collaborate without language.
>
> I have no quarrel at all with the proposition that Forth, as it exists,
> can be the ideal programming system for the lone engineer/programmer who
> is doing everything in a project. Such projects are rare, though. It's a
> collaborative world.
Having spent the last 30+ years using Forth almost exclusively in
collaborative projects, I fail to see any problem with it in that context.
Cheers,
Elizabeth
--
==================================================
Elizabeth D. Rather (US & Canada) 800-55-FORTH
FORTH Inc. +1 310-491-3356
5155 W. Rosecrans Ave. #1018 Fax: +1 310-978-9454
Hawthorne, CA 90250
http://www.forth.com
"Forth-based products and Services for real-time
applications since 1973."
==================================================
Elizabeth D Rather
> Elizabeth D Rather wrote:
>>> Perhaps it is more productive to consider Forth as an extensible
>>> vocabulary. A vocabulary can be used in grammatical or ungrammatical
>>> ways. Like a natural vocabulary, Forth does not enforce a grammar:
>>> that's the job of its users.
>>
>> I have no particular argument with this, but...
>>
>>> Unfortunately the Forth community has no history of using or valuing
>>> grammar. Forth has therefore failed at a critical function of
>>> language: to communicate to human beings. It's a shame, because
>>> there's nothing about Forth that made this necessary.
>>
>> ....*this* assertion is not supported by any evidence.
>
> No evidence that you care to perceive. But I work in the desert where
> Forth is extinct. Where its former users have given up on it. Why would
> they do that if it's as productive as you say?
You write from your experience in the desert you inhabit, and I write
from my quite different experience in the jungle I inhabit. You seem to
feel your experience somehow invalidates mine, but I must disagree.
John Passaniti
> Every grammar is isomorphic to some state machine, true, but not every
> state machine is isomorphic to a grammar.
So? This might be fascinating if I was a linguist, but I'm not. I fail
to see the *practical* implications of what you're writing. Can you
give a real-world example of not just what you wrote, but WHY IT
MATTERS. If you can't, may I suggest that you spend more time in a
linguist newsgroup? We're all too busy writing code to care.
Yeah, I guess that's the point. I can point to every programming
language I know and cite in it some impurity, flaw, or sub-optimal
element of it's design. And yet, we all continue to use these
langauges. Why? Because they get the job done.
Ironic: When I cite a language feature that you arbitrarily deem as too
computer sciencey, what I hear from you is that programmers (whoops,
domain experts who write code) don't care about that and just care about
results. Now, when I'm BEGGING you to point to the relevance of what
you're talking about, you're no longer John Doty the pragmatist, but
John Doty, linguist and honorary member of the Vienna Circle.
> I agree with you if that's how the code works consistently. The real
> problem comes downstream, where the next words do not necessarily
> respect the single entity status.
Guns don't kill people. People pointing guns at other people kill other
people. What you describe is not a *language* problem. It's a
*programmer* problem. The language provides a framework that words can
use or abuse. Your problem is with programmers, not the language.
> Yes, and now that you've told me that, I know that "your street" is
> "Elmwood Avenue". But in Forth, I would know what? That some anonymous
> "" that I have to mentally track is "Elmwood Avenue".
No mental tracking is necessary. If in your real-world pragmatic
application you weren't treating the data on the stack as a tuple but as
individual elements, then you are free to name them if that makes it
easier for you. Many Forths offer locals, which can give wonderfully
rich names to items on a stack-- if that's what you need. But chances
are that's not what you need. Most of the time, if you leave a tuple on
the stack, you have words that will subsequently consume that tuple.
> That's the kind of linguistic clue to the reader that bad Forth code
> lacks. Data items disappear from from sight and pop up anonymously later
> via paths that lack the discipline of grammar. Readable programming
> languages use variables here.
The Forth programmer is free to choose to name elements on the stack if
that is deemed necessary. Hell, the Forth programmer is free to layer
on any kind of abstraction that they want. That they typically don't
should tell you something about Forth-- that real-world programmers
using it don't find what you're talking about to be a problem.
And the reason they don't typically have a problem is because good Forth
code avoids the issue. Most words don't return multiple values, and
when they do, they are either logically related (like a string) or a
value and a validity flag that Forth programmers have pragmatically
found have resulted in readable code.
Is it readable from a language-theoretic sense? Does it match a tree
structure? DOES IT MATTER?
> No, I do not, because Python has the discipline of a grammar. A tuple is
> a single grammatical object, and when you disassemble it, you do so
> grammatically. No phrase in Python has more than a single output. Bits
> of a tuple never disappear from sight to surface anonymously later.
Please provide an example in Forth of code "disappearing from sight."
More importantly, please take that example from actual Forth code, not
from a contrived example you cooked up.
> From the FSL:
>
> : mu/ ( ud u--ud ) >R 0 R@ UM/MOD R> SWAP >R um/ R> ;
>
> Try diagramming that as a tree!
No thank you. I'm less interested in language-theoretic discussions and
more interested in programming discussions. In much the same way that I
have no desire to diagram each English sentence I come across and
validate it against some standard, I have no desire to worry if a blob
of code that I have no trouble reading, understanding, and using meets
an arbitrary and unpragmatic test.
Reinhold Straub
John Doty wrote:
> That's the kind of linguistic clue to the reader that bad Forth code
> lacks. Data items disappear from from sight and pop up anonymously later
> via paths that lack the discipline of grammar. Readable programming
> languages use variables here.
Yes, and Forth does have variables.
> From the FSL:
>
> : mu/ ( ud u--ud ) >R 0 R@ UM/MOD R> SWAP >R um/ R> ;
When the FSL was written, many Forths still didn't have locals: hence
the
massive overuse of the stacks there was perhaps quite inevitable.
Reinhold Straub
Stephen Pelc
<j...@whispertel.LoseTheH.net> wrote:
>Stephen Pelc wrote:
>> available. How many different Forth systems are on your main PC? Apart
>> from the MPE versions, I have at least ten others that I survey.
>
>Indeed. Forth is very implementor friendly.
Answer the question, John, instead of changing the subject.
Stephen
--
Stephen Pelc, steph...@mpeforth.com
MicroProcessor Engineering Ltd - More Real, Less Time
133 Hill Lane, Southampton SO15 5AF, England
tel: +44 (0)23 8063 1441, fax: +44 (0)23 8033 9691
web: http://www.mpeforth.com - free VFX Forth downloads
John Passaniti
>> From the FSL:
>>
>> : mu/ ( ud u--ud ) >R 0 R@ UM/MOD R> SWAP >R um/ R> ;
>
> When the FSL was written, many Forths still didn't have locals: hence
> the massive overuse of the stacks there was perhaps quite inevitable.
Regardless, it's not a problem.
John Doty (and I, for that matter) advocate the Forth community spends
more of a focus on libraries. A library user may care about the
implementation, but typically, casual use of a library is more about the
interfaces and getting the job done. The end user of the FSL may not
know-- and probably doesn't care-- how words like mu/ are implemented.
They care that the interface is documented, that the implementation is
tested, that it is efficient, and that any issues are described. That's it.
So we're really talking about two classes of users. For users of a
library who are interested in results, what John Doty is talking about
is completely irrelevant. For users of a library who are interested
more in the implementation, they are likely going to be more advanced
programmers and certainly familiar with the Forth language. For them,
one wouldn't expect that code like what is presented for mu/ would
present a difficulty.
John Doty
> On Tue, 22 Jan 2008 10:19:35 -0700, John Doty
> <j...@whispertel.LoseTheH.net> wrote:
>
>> Stephen Pelc wrote:
>>> available. How many different Forth systems are on your main PC? Apart
>>> from the MPE versions, I have at least ten others that I survey.
>> Indeed. Forth is very implementor friendly.
>
> Answer the question, John, instead of changing the subject.
I have no PC.
I have a Mac laptop, a Linux engineering machine, and a Linux lab bench
machine.
Each has two Forths on it: LSE64 and gforth.
Compare with:
1 Python
1 Perl
1 Mathematica (except on the lab bench machine, which has none)
etc.
The lab bench machine has two gcc toolchains, one for native development
and one for cross development. The Mac has two versions of Guile
installed because of backward compatibility trouble affecting imported
applications. But generally, one version of a programming tool should be
enough. Multiple versions are a symptom of trouble.
Marcel Hendrix
[..]
> When the FSL was written, many Forths still didn't have locals: hence the
> massive overuse of the stacks there was perhaps quite inevitable.
When the FSL was written in ANS Forth, locals existed. However, even
today's ANS Forth *still* doesn't have *floating-point* locals.
The FSL invented its own very limited FP locals flavor (Wil Baden),
but some contributors apparently didn't like them. Now the
algorithms have been proved correct, please feel free to write
more elegant or readable versions [using flocals].
-marcel
Brad Eckert
> John Doty (and I, for that matter) advocate the Forth community spends
> more of a focus on libraries. A library user may care about the
> implementation, but typically, casual use of a library is more about the
> interfaces and getting the job done. The end user of the FSL may not
> know-- and probably doesn't care-- how words like mu/ are implemented.
> They care that the interface is documented, that the implementation is
> tested, that it is efficient, and that any issues are described. That's it.
You mean open libraries, I presume. What kind of license would be best
for that? GPL, MIT or Public Domain? Copyleft licenses sound like a
good idea but do they hamper commercial users? If you build propretary
code on top of GPL code (your code has "INCLUDE SomeGPLlib.fs" at the
top), that's kind of a gray area. AFAIK, that doesn't force you to
release the proprietary code. But if that's so, why does LGPL exist?
The MIT license is the most liberal license (being required to retain
a copyright notice makes it possible to contact the original author)
but doesn't satisfy the copyleftists. Do we need a Forth-centric open
license?
Brad
John Doty
> John Doty wrote:
>> Jerry Avins wrote:
>>>
>>> Maybe I'm just a linear thinker. Forth seems to be a good fit. Words
>>> in Forth are like knobs and levers on a machine. I wonder: does
>>> anyone think of the controls on a backhoe as having a grammar?
>>
>> That's the hermit programmer viewpoint, again. Yes, it's easy to use
>> levers by yourself, but it's hard to collaborate without language.
>>
>> I have no quarrel at all with the proposition that Forth, as it
>> exists, can be the ideal programming system for the lone
>> engineer/programmer who is doing everything in a project. Such
>> projects are rare, though. It's a collaborative world.
>
> Having spent the last 30+ years using Forth almost exclusively in
> collaborative projects, I fail to see any problem with it in that context.
Yes, but you are the ultimate Forth developer. I've seen many software
systems that supported teams when a developer was present, but fizzled
in their absence. A couple of examples:
1. Garrett Jernigan's amazing GRD/RDPAR library that turned Fortran into
an asynchronous OO system years before any of its users had heard of
"objects". It facilitated the breakdown of data analysis processes into
comprehensible chunks, just the right size for a student to write and a
minicomputer to run. It was used extensively at MIT and Harvard for
space mission operations and data analysis for about a decade, but it
died out rapidly when Garrett moved to Berkeley and also moved on to
other interests.
2. Nick Negroponte's early "architecture machine", based on a custom OS,
"MAGIC", built upon a lightweight PL/I implementation by Seth Steinberg.
The whole thing was very similar to the Bell Labs shop that created
Unix: they wanted what Multics could do, but they couldn't afford it. It
worked quite well, but unlike Unix, it never took hold anywhere else.
Seth was one of a handful of MIT PL/I experts who could make sense of
the language to people with questions, so I'm sure he had a lot to do
with its irreproducible success.
The power of things like C, Python, Unix, etc. is that they spread like
weeds even in the absence of trained experts. Forth did that briefly,
but then largely died out. Rather than deny this fact, it would be more
productive to try to understand why, and work to reverse the damage.
John Doty
> John Doty wrote:
>> Elizabeth D Rather wrote:
>>>> Perhaps it is more productive to consider Forth as an extensible
>>>> vocabulary. A vocabulary can be used in grammatical or ungrammatical
>>>> ways. Like a natural vocabulary, Forth does not enforce a grammar:
>>>> that's the job of its users.
>>>
>>> I have no particular argument with this, but...
>>>
>>>> Unfortunately the Forth community has no history of using or valuing
>>>> grammar. Forth has therefore failed at a critical function of
>>>> language: to communicate to human beings. It's a shame, because
>>>> there's nothing about Forth that made this necessary.
>>>
>>> ....*this* assertion is not supported by any evidence.
>>
>> No evidence that you care to perceive. But I work in the desert where
>> Forth is extinct. Where its former users have given up on it. Why
>> would they do that if it's as productive as you say?
>
> You write from your experience in the desert you inhabit, and I write
> from my quite different experience in the jungle I inhabit. You seem to
> feel your experience somehow invalidates mine, but I must disagree.
You don't live in a jungle, you live in a zoo. They are superficially
the same, but the zoo environment cannot be reproduced without its walls.
Matthias Trute
> You mean open libraries, I presume. What kind of license would be best
> for that? GPL, MIT or Public Domain? Copyleft licenses sound like a
> good idea but do they hamper commercial users? If you build propretary
> code on top of GPL code (your code has "INCLUDE SomeGPLlib.fs" at the
> top), that's kind of a gray area. AFAIK, that doesn't force you to
> release the proprietary code.
The GPL enforces that. There are even some trials (with results!),
look for the busybox project for embedded systems.
> But if that's so, why does LGPL exist?
To enable the use of GPL code with closed source software.
> Do we need a Forth-centric open license?
IMHO no. There are far too many licenses, one or two of them should
satisfy every need. Adding yet another license would be misleading IMHO.
Either use opensource like GNU to keep it opensource or pay (more or
less) money for license to use it and get more/better/any support.
That is common practice and well accepted all over the world.
Every vendor is free to offer more that one licenses for his work to
satisfy his customers.
The LGPL was kind of a hack to permit programs like acrobat reader and
wordperfect to run on linux wih it's libc....
Matthias
PS: I'm not a lawyer
Elizabeth D Rather
> Elizabeth D Rather wrote:
>> John Doty wrote:
>>> Elizabeth D Rather wrote:
>> ....
>>>>> Perhaps it is more productive to consider Forth as an extensible
>>>>> vocabulary. A vocabulary can be used in grammatical or
>>>>> ungrammatical ways. Like a natural vocabulary, Forth does not
>>>>> enforce a grammar: that's the job of its users.
>>>>
>>>> I have no particular argument with this, but...
>>>>
>>>>> Unfortunately the Forth community has no history of using or
>>>>> valuing grammar. Forth has therefore failed at a critical function
>>>>> of language: to communicate to human beings. It's a shame, because
>>>>> there's nothing about Forth that made this necessary.
>>>>
>>>> ....*this* assertion is not supported by any evidence.
>>>
>>> No evidence that you care to perceive. But I work in the desert where
>>> Forth is extinct. Where its former users have given up on it. Why
>>> would they do that if it's as productive as you say?
>>
>> You write from your experience in the desert you inhabit, and I write
>> from my quite different experience in the jungle I inhabit. You seem
>> to feel your experience somehow invalidates mine, but I must disagree.
>
> You don't live in a jungle, you live in a zoo. They are superficially
> the same, but the zoo environment cannot be reproduced without its walls.
You know absolutely nothing about where and how I live, let along the
number, distribution, and profile of FORTH, Inc. customers. I get
really tired of your ignorant, uninformed assertions.
Elizabeth D Rather
> Elizabeth D Rather wrote:
>> John Doty wrote:
>>>
>>> I have no quarrel at all with the proposition that Forth, as it
>>> exists, can be the ideal programming system for the lone
>>> engineer/programmer who is doing everything in a project. Such
>>> projects are rare, though. It's a collaborative world.
>>
>> Having spent the last 30+ years using Forth almost exclusively in
>> collaborative projects, I fail to see any problem with it in that
>> context.
>
> Yes, but you are the ultimate Forth developer. I've seen many software
> systems that supported teams when a developer was present, but fizzled
> in their absence. A couple of examples:
Ok, first you say Forth can only be used by lone engineer/programmers.
Confronted with evidence to the contrary, you then say that it can be
used only by teams when we're around. Wrong on both counts. A few
examples:
We currently are working with two companies who first developed Forth
applications in the late 70's. One came back to us in the 80's for help
porting their app from a PDP/11 to a PC, and only recently contacted us
again about potential further upgrades. The other did their own ports
to more modern equipment over the ages, supported an in-house team who
adapted their applications over the years, and recently contacted us to
outsource some work because their in-house team is busy.
We hear from many companies who have been using Forth (and not always
our products) successfully for many years before we even heard of them.
They are coming to us not because they are helpless or because Forth
isn't working for them, but because it's advantageous to them to line up
second-source relationships for all the sound reasons companies do that.
It's a continuing source of gratification to me to see so many
successful long-term Forth teams.
John Doty
Huh? It is extremely doubtful that they will be very familiar with the
Forth language (hardly anyone is), especially the techniques used by mu/.
Users of libraries very often want to look into the implementation for a
variety of reasons:
1. The user may suspect the code has undocumented limitations. I ran
into just such a problem in Mathematica today (despite its voluminous
documentation), and of course it's annoying that I can't see why, and
thus avoid it. This kind of thing is one of the barriers to using
Mathematica in production data processing (although it's nice for
interactive exploration).
2. Inexperienced users with access to few code examples may want to
learn from the library code itself. It's very helpful here if the code
at least appears superficially readable. That opens the door, but if the
code is initially completely opaque, many will give up and
3. The code may be *almost* what is needed, but require slight tweaking.
I've successfully tweaked Perl code even though I don't know how to
write it.
It is very reassuring to me that when I use something like stats.py, the
code is readable enough that I can see how the algorithms work and make
a good estimate of their limitations. Also, critically reading such code
is an excellent learning experience. I am certainly no Python expert!
I think the real distinction is between old, widely used workhorses like
LINPACK versus things hardly anybody has heard about, like the FSL.
There's an extra burden on the newcomer to prove its reliability. If
there's no significant experience base, wary users are going to want
more than just a "black box". But adoption by wary users gives the code
credibility.
John Doty
You make statements that I know to be grossly untrue about Forth's
status in aerospace and astronomy. I know that for certain. I infer from
that that the rest of your bragging cannot be trusted. Isn't that enough?
Rod Pemberton
news:ef99e415-25b8-4a5e...@d21g2000prf.googlegroups.com...
> If you build propretary
> code on top of GPL code ...
> that's kind of a gray area.
No grey area, AFAICT. Their license and FAQ covers this. The only area
where their FAQ skips some details is on the legality of modifying Public
Domain code and applying a copyright to the _entire_ slightly modified work,
not just the changes (likely illegal).
1) If you link to GPL code, you must release your source as GPL.
2) If you modify GPL code, you must release your changes, _AND_ the original
copyright holder takes ownership of those changes. Since the original
copyright holder maintains copyright and only granted you a license, the
original copyright holder may close the source at a later date, including
any changes "donated" by you under the GPL license.
2) is one reason why I prefer Public Domain. However, there are countries
that don't recognize Public Domain, although they should because of
international copyright treaties. I've even seen some projects from
countries without a concept of Public Domain, e.g., Germany, claim that
their projects are "Public Domain," when in fact they are copyrighted and
licensed. They are released under some liberal open source license, but
aren't PD as understood in the USA.
> AFAIK, that doesn't force you to
> release the proprietary code.
NO! It does.
> But if that's so, why does LGPL exist?
That's why it exists and why Stallman is trying to get rid of it now. LGPL
originally allowed closed source code to link with it, e.g., so closed
source programs could use libraries and OS API's, etc. But, closed source
companies began using LGPL'd source as a way to keep their code private.
This has annoyed Stallman... The bottom line, IMO, is Gates and co. doesn't
want any not-for-profit software to exist and Stallman doesn't want any
for-profit software to exist. They are both using other ideologies
(capitalism, and open source) to hide their true motives. Programmers need
to eat _and_ individuals in a creative society need low or no cost tools.
Rod Pemberton
John Doty
> John Doty wrote:
>> Elizabeth D Rather wrote:
>>> John Doty wrote:
>>>>
>>>> I have no quarrel at all with the proposition that Forth, as it
>>>> exists, can be the ideal programming system for the lone
>>>> engineer/programmer who is doing everything in a project. Such
>>>> projects are rare, though. It's a collaborative world.
>>>
>>> Having spent the last 30+ years using Forth almost exclusively in
>>> collaborative projects, I fail to see any problem with it in that
>>> context.
>>
>> Yes, but you are the ultimate Forth developer. I've seen many software
>> systems that supported teams when a developer was present, but fizzled
>> in their absence. A couple of examples:
>
> Ok, first you say Forth can only be used by lone engineer/programmers.
> Confronted with evidence to the contrary, you then say that it can be
> used only by teams when we're around. Wrong on both counts. A few
> examples:
>
> We currently are working
I rest my case. *You* are working with.
> with two companies who first developed Forth
> applications in the late 70's. One came back to us in the 80's for help
> porting their app from a PDP/11 to a PC, and only recently contacted us
> again about potential further upgrades. The other did their own ports
> to more modern equipment over the ages, supported an in-house team who
> adapted their applications over the years, and recently contacted us to
> outsource some work because their in-house team is busy.
>
> We hear from
^^^^^^^^^^^^^^
Yes. But you don't go out and look where people are actually solving
problems. If you did, you'd find Forth extremely hard to find. You have
a zoo full of pandas. And occasionally someone captures one and brings
it to you, so you imagine there must be plenty more out there. But in
the wild, pandas are endangered.
> many companies who have been using Forth (and not always
> our products) successfully for many years before we even heard of them.
> They are coming to us not because they are helpless or because Forth
> isn't working for them, but because it's advantageous to them to line up
> second-source relationships for all the sound reasons companies do that.
Sure. There are a few stories to tell. There's even an x-ray optics test
camera still in service at Goddard Space Flight center controlled by LSE
code written in stages by a team from ~1979 to ~1990. But there's no
significant LSE community any more. I suppose if they need software
maintenance they could call me (they know where I am), but I expect some
now unobtainable component will break someday and end its life before
they need that.
>
> It's a continuing source of gratification to me to see so many
> successful long-term Forth teams.
How many are there compared to successful C teams? Python teams? Your
metric for "many" reflects the size of your zoo, not the size of the
world. Now, if you could show that if by choosing team software projects
at random "in the wild" without language prejudice you'd find a
significant number of Forth projects, you'd have something. But I've
tried that in astronomy and come up empty, to my great distress. There
is no significant community there to plug in to any more.
John Doty
>> It's a continuing source of gratification to me to see so many
>> successful long-term Forth teams.
To avoid being too harsh, let me state that you have much to be proud of
here. You and Forth have achieved many things. I would not be writing
this if your early papers had not introduced me to Forth. I think you
underestimate the power of your personal drive and resourcefulness, and
the effect it has had here.
But while Forth's past is something to be proud of, its future looks
bleak. I will repeat:
The power of things like C, Python, Unix, etc. is that they spread like
weeds even in the absence of trained experts. Forth did that briefly,
but then largely died out. Rather than deny this fact, it would be more
productive to try to understand why, and work to reverse the damage.
--
Ed
"Marcel Hendrix" <m...@iae.nl> wrote in message news:2516343...@frunobulax.edu...
There is no guarantee using locals will make code "more elegant
or readable".
I've seen forth programmers who use locals at the drop of a hat.
Their definitions tend to be long (which is why they need locals)
and the result, IMO, is far from readable.
Using globals in forth requires some effort on the part of the
programmer. One has to choose a good name for the variable
and one that doesn't conflict. In the process one might even
question whether a variable was necessary - perhaps using the
stack is better.
It's through effort that one ends up with efficient run-time code.
Have you noticed that even optimizing compilers will reward
you if you give it good forth code to begin with?
But locals require no effort so people like them.
van...@vsta.org
> I've seen forth programmers who use locals at the drop of a hat.
> Their definitions tend to be long (which is why they need locals)
> and the result, IMO, is far from readable.
I think you're right, and I suspect it's not (just) because they are
weak programmers.
A while back I showed a relatively sleek memory copy in C, which took
advantage of idioms like:
*dest++ = *src++;
I suspect that locals BY THEMSELVES are not all that helpful. Yes,
they let you access a value by name. But it seems to me that the idioms
available to deal with that name are rather limited. For instance,
C packed assignment via the current pointer value, along with update
of the pointer value. I haven't seen a Forth locals implementation
that could do that without quite an unwieldy set of uses of the name
(my own implementation of locals in ForthOS certainly would be clunky).
So if locals of some sort are a part of the solution, I submit that we
should also be thinking hard about what idioms we want to support in
conjunction with those names. Just to give an example of a Forth-like
departure, have a look at a little known language called "MINT". One of
the fellows who worked on it is now a Stanford Prof, and he keeps a copy
of the language & its companion book at:
http://qss.stanford.edu/~godfrey/mint/
I'm not saying I think it's the answer. But it incorporates an
unconventional lexical analyzer with a shunt stack parser to permit
infix expressions to be mixed with more traditional Forth stack
programming.
Regards,
Andy Valencia
John Doty
> "Marcel Hendrix" <m...@iae.nl> wrote in message news:2516343...@frunobulax.edu...
>> Reinhold Straub <dema...@web.de> writes Re: modernization of FORTH, Age Results
>> [..]
>>> When the FSL was written, many Forths still didn't have locals: hence the
>>> massive overuse of the stacks there was perhaps quite inevitable.
>> When the FSL was written in ANS Forth, locals existed. However, even
>> today's ANS Forth *still* doesn't have *floating-point* locals.
>>
>> The FSL invented its own very limited FP locals flavor (Wil Baden),
>> but some contributors apparently didn't like them. Now the
>> algorithms have been proved correct, please feel free to write
>> more elegant or readable versions [using flocals].
>
> There is no guarantee using locals will make code "more elegant
> or readable".
>
> I've seen forth programmers who use locals at the drop of a hat.
> Their definitions tend to be long (which is why they need locals)
> and the result, IMO, is far from readable.
I beginning to feel that we should really think about locals in terms of
two separate purposes. Locals defined at word entry serve the purpose of
"formal parameters" in other languages, and can enhance readability.
Locals defined deeper in the definition are more like automatic
variables and are more troublesome, because they have too narrow a
scope. As others have noted, a Forth definition corresponds more to a
"statement" in other languages than to a "function". Usually, an
automatic variable needs more scope than a single statement. That's what
drives definitions to be too long, and reduces readability.
>
> Using globals in forth requires some effort on the part of the
> programmer. One has to choose a good name for the variable
> and one that doesn't conflict. In the process one might even
> question whether a variable was necessary - perhaps using the
> stack is better.
Forth doesn't really have globals in the sense of common variables like
C or Fortran. Forth variables shadow previously defined variables of the
same name, so as long as you use them as internal interfaces within
wordsets, they're pretty safe, although not reentrant. Of course, a
Forth with vocabularies gives you even more control here. Variables used
as external interfaces by wordsets are more problematic: I've sometimes
used the convention wordset;name for their names to insure no conflict.
>
> It's through effort that one ends up with efficient run-time code.
> Have you noticed that even optimizing compilers will reward
> you if you give it good forth code to begin with?
>
> But locals require no effort so people like them.
Given that my desktop machine cost me less than a day's earnings, in
many cases it makes more sense to optimize my time than its time. But it
depends on the circumstance. A few years ago I spent hours rearranging
an inner loop to eliminate one cycle of pipeline stall: that made the
difference between code that could meet a hard deadline and code that
couldn't. But the rest of the code in that application didn't need any
special attention: its timing wasn't critical.
Albert van der Horst
John Doty <j...@whispertel.LoseTheH.net> wrote:
<SNIP examples>
Like in your examples, Python has a central figure, and unlike
your examples, he has not yet quit. So your examples may not
be say much. Imagine what Forth would be like if Chuck Moore
was interested in having a following, and was interested in what
they had to say.
>
>The power of things like C, Python, Unix, etc. is that they spread like
>weeds even in the absence of trained experts. Forth did that briefly,
>but then largely died out. Rather than deny this fact, it would be more
>productive to try to understand why, and work to reverse the damage.
Ever heard of fashion? "Rather then deny the fact that girls are all
wearing mini skirts, try to understand it." (and reverse the damage, if
you are an xfundy).
>--
>John Doty, Noqsi Aerospace, Ltd.
Groetjes Albert
--
--
Albert van der Horst, UTRECHT,THE NETHERLANDS
Economic growth -- like all pyramid schemes -- ultimately falters.
albert@spe&ar&c.xs4all.nl &=n http://home.hccnet.nl/a.w.m.van.der.horst
Reinhold Straub
> When the FSL was written in ANS Forth, locals existed. However, even
> today's ANS Forth *still* doesn't have *floating-point* locals.
And it's still not possible in many Forths to have locals in child
words.
> The FSL invented its own very limited FP locals flavor (Wil Baden),
> but some contributors apparently didn't like them.
And apparently all these years no one, not even the implementor,
tested F~, defined there by using flocals (it's incorrect).
Reinhold Straub
Reinhold Straub
> There is no guarantee using locals will make code "more elegant
> or readable".
John Doty explained when and why the use of stacks will lead to
readable code and when and why to less readable code. He told us that
"readable languages" use variables in these cases. Why not Forth, too?
Sometimes the stack is better, sometimes locals, sometimes words/
globals. So it's helpful to have some criteria here, and John provided
a convincing one. I'd add another one: I'd use locals if otherwise I
had used return stack words.
> I've seen forth programmers who use locals at the drop of a hat.
> Their definitions tend to be long (which is why they need locals)
> and the result, IMO, is far from readable.
You don't need locals while you are busy coding. Put them in for
readability after all factoring is done.
> Have you noticed that even optimizing compilers will reward
> you if you give it good forth code to begin with?
No, so far I haven't. I have noticed that knowledge of the
implementation helps. In Powermops for instance, locals are garanteed
to sit on registers. So if you want fast code, don't use variables or
dup in loops, use locals. Other Forths don't use registers for locals,
so locals won't improve speed there.
> But locals require no effort so people like them.
Positional, relative or implicit references (like "top", "third from
left", "it") require little effort, but can be re-used only shortly
after they have been established. Defining names has some overhead,
but names can be used much longer. Most persistant are unique
references like ID-numbers, but they need even more management than
names.
Reinhold Straub
Bernd Paysan
> 2) If you modify GPL code, you must release your changes, _AND_ the
> original
> copyright holder takes ownership of those changes. Since the original
> copyright holder maintains copyright and only granted you a license, the
> original copyright holder may close the source at a later date, including
> any changes "donated" by you under the GPL license.
No, that's not the case. Some projects requires a copyright transfer
agreement to the copyright holder (MySQL AB comes in mind), and they don't
promise that they will release the project forever under GPL (as the FSF
promises).
> 2) is one reason why I prefer Public Domain. However, there are countries
> that don't recognize Public Domain, although they should because of
> international copyright treaties. I've even seen some projects from
> countries without a concept of Public Domain, e.g., Germany, claim that
> their projects are "Public Domain," when in fact they are copyrighted and
> licensed. They are released under some liberal open source license, but
> aren't PD as understood in the USA.
I don't think this is correctly understood. You can't give up rights that
are perceived as inalienable by the government, because they are perceived
inalienable. When there's another jurisdiction, where you can give up these
rights, and German law has nothing to say there, you can give up this right
there. The statement "this project is in the Public Domain" tells you
exactly the same in both countries, the legal effects are different -
depending on where you sue, not on where you stated that it is PD.
--
Bernd Paysan
"If you want it done right, you have to do it yourself"
http://www.jwdt.com/~paysan/
David N. Williams
> "Marcel Hendrix" <m...@iae.nl> wrote in message
news:2516343...@frunobulax.edu...
>> Reinhold Straub <dema...@web.de> writes Re: modernization of
FORTH, Age Results
>> [..]
>>> When the FSL was written, many Forths still didn't have locals:
hence the
>>> massive overuse of the stacks there was perhaps quite inevitable.
>> When the FSL was written in ANS Forth, locals existed. However, even
>> today's ANS Forth *still* doesn't have *floating-point* locals.
>>
>> The FSL invented its own very limited FP locals flavor (Wil Baden),
>> but some contributors apparently didn't like them. Now the
>> algorithms have been proved correct, please feel free to write
>> more elegant or readable versions [using flocals].
>
> There is no guarantee using locals will make code "more elegant
> or readable".
I think Marcel's point is that locals are pretty much a
necessity for nontrivial computation with floating point. If
that's not his opinion, it's certainly mine. :-)
-- David