|
|
 Up |
|
|
  |
Author: Rod PembertonRod Pemberton Date: Jan 17, 2008 10:15
"John Passaniti" JapanIsShinto.com> wrote in message
news:pCxjj.2190$Sa1.1624@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...
|
| Show full article (1.57Kb) |
|
| | 370 Comments |
|
|
Author: John PassanitiJohn Passaniti Date: Jan 17, 2008 14:58
Rod Pemberton wrote:
> "John Passaniti" JapanIsShinto.com> wrote in message
> news:pCxjj.2190$Sa1.1624@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.
|
| Show full article (1.72Kb) |
|
| | no comments |
|
|
Author: Stefan SchmiedlStefan Schmiedl Date: Jan 17, 2008 16:32
On Thu, 17 Jan 2008 22:58:19 GMT
John Passaniti 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.
|
| |
| no comments |
|
|
Author: Mark W. HumphriesMark W. Humphries Date: Jan 17, 2008 18:16
On Jan 18, 2:15 am, "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. 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...
|
| Show full article (1.31Kb) |
| no comments |
|
|
Author: JecelJecel Date: Jan 17, 2008 18:30
On Jan 17, 8:58Â pm, John Passaniti wrote:
> 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
|
| |
| no comments |
|
|
Author: John DotyJohn Doty Date: Jan 17, 2008 20:40
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.
> 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?
|
| Show full article (1.41Kb) |
| 6 Comments |
|
|
Author: Alex McDonaldAlex McDonald Date: Jan 18, 2008 03:21
On Jan 18, 4:40 am, John Doty whispertel.LoseTheH.net> wrote:> 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?
|
| Show full article (2.00Kb) |
| 2 Comments |
|
|
Author: Bernd PaysanBernd Paysan Date: Jan 18, 2008 05:59
John Doty wrote:
> 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 ;-).
|
| |
| no comments |
|
|
Author: John DotyJohn Doty Date: Jan 18, 2008 13:19
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.
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.
|
| Show full article (1.13Kb) |
| 2 Comments |
|
|
|
|
|
Author: Alex McDonaldAlex McDonald Date: Jan 18, 2008 13:58
On Jan 18, 9:19 pm, John Doty 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. 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?
|
| Show full article (1.93Kb) |
| 2 Comments |
|
|
|
|
