How to make Forth interesting?
DavidM
I am not alone here as one who remembers the 'good' old days of 8-bit
microprocessors of 8k RAM or less
In those days, the programming choice was between one of those horrible
BASIC interpreters (whose subroutines didn't even allow names, arguments
or return values, and whose variables didn't allow names longer than 1
character), or straight-out assembler.
In that scenario, Forth was like the golden light from heaven.
Unbelievable memory efficiency, excellent speed, infinite flexibility.
You could achieve 4 times as much in 1/4th the time, probably using 1/4th
of the CPU and memory.
But what about today? Even assemblers are available in object oriented
versions, BASIC no longer has line numbers, and in these new modern
languages, dynamic memory management, advanced high-level data structures
and garbage collection are the norm.
The world is full of rapid development languages that are (in each their
own way) kind to the brain: Python, Ruby, Lua, ECMAscript, VB, ...
So how does Forth compare with those languages?
In the old days, one line of Forth could do what required 10+ lines of
BASIC. But these days, one line of Python can often do what takes 10+
lines of Forth.
Let's face it - unless you're programming for extremely memory-tight
platforms (which get rarer with each passing year), Forth is no longer
the shimmering wonder-child it used to be. In fact, Forth is now feeling
a bit like C - a form of quasi-portable assembler.
So my question is - is there any way to make Forth attractive to new
generations of programmers? Is there any way we can come up with a new de-
facto standard set of vocabularies with new features, which offer
programming leverage sufficient to compete with the likes of Python and
its pals?
A new high-level interface that takes care of the menial stuff and sets
its programmers free, the way that classical forth did (in comparison to
BASIC and assembler)?
Some might say that this already exists in the form of Factor.
Others might say it's a stupid goal to aim for, and that Forth should
naturally devolve as it should.
Yet others might be interested in taking part in designing the new
abstractions to take Forth into the 21st Century.
So what are your thoughts?
Cheers
Dave
Elizabeth D Rather
> Hi,
>
> I am not alone here as one who remembers the 'good' old days of 8-bit
> microprocessors of 8k RAM or less
>
> In those days, the programming choice was between one of those horrible
> BASIC interpreters (whose subroutines didn't even allow names, arguments
> or return values, and whose variables didn't allow names longer than 1
> character), or straight-out assembler.
>
> In that scenario, Forth was like the golden light from heaven.
> Unbelievable memory efficiency, excellent speed, infinite flexibility.
> You could achieve 4 times as much in 1/4th the time, probably using 1/4th
> of the CPU and memory.
>
> But what about today? Even assemblers are available in object oriented
> versions, BASIC no longer has line numbers, and in these new modern
> languages, dynamic memory management, advanced high-level data structures
> and garbage collection are the norm.
>
> The world is full of rapid development languages that are (in each their
> own way) kind to the brain: Python, Ruby, Lua, ECMAscript, VB, ...
>
> So how does Forth compare with those languages?
>
> In the old days, one line of Forth could do what required 10+ lines of
> BASIC. But these days, one line of Python can often do what takes 10+
> lines of Forth.
We seem to have this conversation every couple of months. Most
recently, the "Is Forth still interesting" thread.
Each of these languages has a niche. Which is "best" depends entirely
on what you're trying to do.
> Let's face it - unless you're programming for extremely memory-tight
> platforms (which get rarer with each passing year), Forth is no longer
> the shimmering wonder-child it used to be. In fact, Forth is now feeling
> a bit like C - a form of quasi-portable assembler.
Quite a lot of programming is still being done for small embedded
microcontrollers, where size & performance constraints remain severe.
Every company that makes a microprocessor-controlled widget (and they
outnumber PCs by a wide margin) would like to keep unit costs down, by
using smaller/cheaper controllers, minimum memory, etc.
> So my question is - is there any way to make Forth attractive to new
> generations of programmers? Is there any way we can come up with a new de-
> facto standard set of vocabularies with new features, which offer
> programming leverage sufficient to compete with the likes of Python and
> its pals?
>
> A new high-level interface that takes care of the menial stuff and sets
> its programmers free, the way that classical forth did (in comparison to
> BASIC and assembler)?
>
> Some might say that this already exists in the form of Factor.
>
> Others might say it's a stupid goal to aim for, and that Forth should
> naturally devolve as it should.
>
> Yet others might be interested in taking part in designing the new
> abstractions to take Forth into the 21st Century.
>
> So what are your thoughts?
"We" can do anything that "we" want to. The real question is, who is
this "we"?
Every Forth implementor (commercial or non-commercial) has the
opportunity to add whatever enhancements make sense for their goals.
And we do.
You don't even have to be an implementor: take your favorite system and
add whatever features you admire and that will be useful for the kinds
of applications you want to write. Not only is nobody stopping you, if
you implement such additional features you have the opportunity to get
rich/famous/whatever your goal is.
You're asking for this hypothetical "we" to come up with a "de-facto
standard set of vocabularies" for some purpose. Frankly, the way
"de-facto standards" happen is that *someone* actually invests the work
in making something that actually works, that lots of other people want
to use, so they adopt it.
So, don't wait, if you have something in mind, by all means get going!
Cheers,
Elizabeth
--
==================================================
Elizabeth D. Rather (US & Canada) 800-55-FORTH
FORTH Inc. +1 310.999.6784
5959 West Century Blvd. Suite 700
Los Angeles, CA 90045
http://www.forth.com
"Forth-based products and Services for real-time
applications since 1973."
==================================================
noah.r...@cnu.edu
recently become very interested in Forth. I've created my own little
forth for the TI-83, and I have plans for other projects. I would even
like to do research related to forth for my capstone and possibly
master thesis.
It is still an interesting language, even to new programmers. Besides
it obvious applications in resource constrained situations (though I
bet some CE majors would be interested to avoid C) it is interesting
as a language, especially with all the history, culture, and
philosophy behind it. I've tried to get it included in a programming
language concept class at my university, but it is otherwise unknown
to my peers. If there was one thing that would make it more popular
it would be some project or research that would introduce people to
it. I believe that if people knew about it, they would change it into
anything that they wanted it to be as people has been doing with forth
for years, along with their new "21st Century" abstractions that they
bring from other languages.
Doug Hoffman
> The world is full of rapid development languages that are (in each their
> own way) kind to the brain: Python, Ruby, Lua, ECMAscript, VB, ...
>
> So how does Forth compare with those languages?
What are your thoughts about those comparisons?
> So my question is - is there any way to make Forth attractive to new
> generations of programmers? Is there any way we can come up with a new de-
> facto standard set of vocabularies with new features, which offer
> programming leverage sufficient to compete with the likes of Python and
> its pals?
Which new features do you think are important to "come up with" for
Forth to attract those programmers?
> A new high-level interface that takes care of the menial stuff and sets
> its programmers free, the way that classical forth did (in comparison to
> BASIC and assembler)?
Menial stuff? Please describe with some detail which menial stuff you
think needs attention and how you think it should be done differently in
Forth.
-Doug
MarkWills
Well, one man's meat is another man's poison!
<snip>
> But what about today? Even assemblers are available in object oriented
> versions, BASIC no longer has line numbers, and in these new modern
> languages, dynamic memory management, advanced high-level data structures
> and garbage collection are the norm.
</snip>
Yes, but they won't fit in 8K. Furthermore, their complexity means
that they are un-suitable candidates for use say, in a bootstrapping
environment where you need to bring un-tested hardware up with
minimal software.
<snip>
> Let's face it - unless you're programming for extremely memory-tight
> platforms (which get rarer with each passing year), Forth is no longer
> the shimmering wonder-child it used to be. In fact, Forth is now feeling
> a bit like C - a form of quasi-portable assembler.
</snip>
Quasi-portable assembler. An excellent comparison. Assembler, for me,
has beauty, via its simplicity. Forth, is even simpler, and beautiful
as a result, like nature.
For me, the language, in it's current form lacks nothing. In fact, I'm
probably in the old-school camp, and would advocate reducing the
dictionary down to a much smaller size, in line with comments by such
people as Chuck Moore in the past (though he tends to go to extremes
perhaps!)
I have to say, I have been in love with the language since I
discovered it, maybe 9 months ago. Developing programs with it is
exciting, makes me smile when "I get it" and (to me) the beauty of
it's sheer simplicity shines through. It really is a fabulous
language.
And I kind of enjoy it's niche status also; to see it 'endure' a
sudden resurgence in popularity would probably see it hijacked by OOP
crowd, until it resembled nothing of it's former state.
I will just say this: Everyone I have introduced the language to has
had the same reaction as me, disbelief (Forth? You must be crazy),
then I explain it to them and show them how simple it is, with this
little program:
: ... S" S" . ;
: --- S" O" . ;
... --- ...
SOS ok
And they all go "HOLY ****! Thats REALLY COOL!"
Then they're hooked. :-)
Richard Owlett
> [snip]
>
> : ... S" S" . ;
> : --- S" O" . ;
> ... --- ...
> SOS ok
>
> And they all go "HOLY ****! Thats REALLY COOL!"
>
> Then they're hooked. :-)
I think something missing. I'm a rusty newbie - I got
SwiftForth 3.0.5 22-Nov-2006
: ... S" S" . ; ok
: --- S" O" . ; ok
... --- ... 1 1 1 ok
. 4654677 ok
. 4654709 ok
. 4654677 ok
ok
Jonah Thomas
I think he meant
: ... S" S" TYPE ;
: --- S" O" TYPE ;
Alternatively it could be
: ... [CHAR] S EMIT ;
: --- [CHAR] O EMIT ;
Or you could take it farther.
: MORSE
CHAR CREATE C,
DOES> C@ EMIT ;
MORSE E .
MORSE T -
MORSE A .-
MORSE O ---
MORSE I ..
MORSE N -.
MORSE S ...
Etc.
Of course we've already used . and - which are important Forth words,
and it takes more complications to keep that from interfering with
Forth. But it doesn't have to be all that complicated.
John Passaniti
> I think something missing. I'm a rusty newbie - I got
He should have used "type" instead of ".":
: ... s" s" type ;
Or alternatively:
: ... ." s" ;
All I can say is if this kind of thing gets people hooked on Forth, then
people have a much lower threshold for being impressed than I do.
DavidM
> For me, the language, in it's current form lacks nothing.
If you limit your range of programming desires, then it lacks nothing.
Same could be said about nearly all languages.
> In fact, I'm
> probably in the old-school camp, and would advocate reducing the
> dictionary down to a much smaller size, in line with comments by such
> people as Chuck Moore in the past (though he tends to go to extremes
> perhaps!)
What's your position on loadable extensions? Would you advocate some
standardisation there, or just say "it's up to the individual user to
code their own extensions"?
> I have to say, I have been in love with the language since I discovered
> it
That's been my problem - I've loved it (and hated it) since coming across
it in 1984. I can't seem to get away from it.
You don't choose forth. Forth chooses you!
> Developing programs with it is exciting, makes
> me smile when "I get it" and (to me) the beauty of it's sheer simplicity
> shines through. It really is a fabulous language.
Ever written a web application in Forth? Complete with parsing of http
headers, plus POSTed data which can contain arbitrary length lines?
> And I kind of enjoy it's niche status also; to see it 'endure' a sudden
> resurgence in popularity would probably see it hijacked by OOP crowd,
> until it resembled nothing of it's former state.
That makes me think - the Forth I'm working on has a massive OO
component. You are probably not alone in your anti-oo feeling. Makes me
wonder if I should make my OO a loadable extension instead of part of the
core.
Jonah Thomas
I should hope so! You're the guy who's seen it all. If everybody was as
blase as you are it would be hard for anything to impress anybody.
It shouldn't need saying that I mean no offense by that, but I'll say it
anyway. No offense intended.
Richard Owlett
I think it is in the tradition of Mr. Brodie's "washing machine"
example. It may not do anything more than start someone thinking.
Thinking is important ;)
ken...@cix.compulink.co.uk
wrote:
> If you limit your range of programming desires, then it lacks
> nothing. Same could be said about nearly all languages.
One point I have not seen mentioned yet is the availability of tools.
Delphi I was a big hit because of the IDE and the design tools. Compared
with C it greatly simplified writing programs for Windows as there was
no need to code the GUI bits as all that was done in components. All you
needed to code was the actual application and in fact some database
applications did not need additional code.
Winforth does come with a limited forms designer and I do not have any
experience of the IDE supplied with commercial Forth systems but for RAD
you do not want to have to reinvent the wheel every time you make a
system call. Obviously this is different for embedded systems but the
availability of tools to reduce the drudge work and allow people to
concentrate on the actual application is still important.
By the way OO is probably the easiest way to handle a GUI interface.
Ken Young
Jacko
> By the way OO is probably the easiest way to handle a GUI interface.
This is true of OO GUIs which is probably the greatest percentage.
Seem such a circular argument though, make OO GUI, need OO to use it
best.
So a non OO GUI, template based output, and then what of the
callbacks, or 'events'??
cheers jacko
John Passaniti
>> All I can say is if this kind of thing gets people hooked on Forth,
>> then people have a much lower threshold for being impressed than I do.
>
> I think it is in the tradition of Mr. Brodie's "washing machine"
> example. It may not do anything more than start someone thinking.
> Thinking is important ;)
And let's look at that thought process:
"You know, programming in Forth is so fundamentally different than
programming in any other language. Take this washing machine example
for example. In Forth, I'm CREATING A LANGUAGE. Look! I created word
called SPIN! Imagine trying to do that in a language like C! Sure, you
could call it "spin" but then there are all those parenthesis and
semicolons, and it just confuses me all to hell."
If people want to make a compelling argument for Forth, then these
stupid toy examples that get trotted out have to go. They don't promote
thinking. They promote (at most) that Forth has a leaner syntax and has
a larger set of potential identifiers. And if that kind of trivia is
important to someone, great.
What would promote thinking? Show a defining word that does something
non-trivial. Show words that have interesting run-time behaviors that
can't be done in other languages. Show something like adding a major
language feature in a few lines of code (like mini-OOF). In short, show
something that makes Forth unique.
MarkWills
Ok:
IF
THEN
ELSE
Please post the appropriate C code to reproduce the above.
MarkWills
> On Thu, 26 Mar 2009 11:37:59 -0700, MarkWills wrote:
> > For me, the language, in it's current form lacks nothing.
>
> If you limit your range of programming desires, then it lacks nothing.
> Same could be said about nearly all languages.
I hold an opposing point of view! To me, Forth is one level above
machine code, a machine independant machine code if you will; since
everything comes down to machine code in the end, it lacks nothing.
There is nothing I can't do in Forth.
>
> > In fact, I'm
> > probably in the old-school camp, and would advocate reducing the
> > dictionary down to a much smaller size, in line with comments by such
> > people as Chuck Moore in the past (though he tends to go to extremes
> > perhaps!)
>
> What's your position on loadable extensions? Would you advocate some
> standardisation there, or just say "it's up to the individual user to
> code their own extensions"?
I would probably say code them yourself, but that is purely because
Forth, for me, is most useful in embedded type apps, or lab stuff
(like bringing up hardware) - thus the code I would write would tend
to be extremely specific, thus have to be hand coded anyway. I'm from
a SCADA / Controls background, so I'm looking at Forth through those
'filters' :-)
>
> > I have to say, I have been in love with the language since I discovered
> > it
>
> That's been my problem - I've loved it (and hated it) since coming across
> it in 1984. I can't seem to get away from it.
>
> You don't choose forth. Forth chooses you!
>
> > Developing programs with it is exciting, makes
> > me smile when "I get it" and (to me) the beauty of it's sheer simplicity
> > shines through. It really is a fabulous language.
>
> Ever written a web application in Forth? Complete with parsing of http
> headers, plus POSTed data which can contain arbitrary length lines?
No. Whilst I appreciate the language is capable of it, I don't think I
could do agood job of it in forth. I would use a different language,
like .Net or Java, but that's because I have the luxury of being
comfortable with those languages!
One interesting area of Forth though (for the particular problem you
are describing (kind of) - like parsing) is how you can define
elements in terms of Forth words:
: <html> .... ;
: <body> .... ;
: <table> .... ;
This is a very interesting facet of the Forth language.
>
> > And I kind of enjoy it's niche status also; to see it 'endure' a sudden
> > resurgence in popularity would probably see it hijacked by OOP crowd,
> > until it resembled nothing of it's former state.
>
> That makes me think - the Forth I'm working on has a massive OO
> component. You are probably not alone in your anti-oo feeling. Makes me
> wonder if I should make my OO a loadable extension instead of part of the
> core.
Well, I'm probably not a good example to solicit opinion from (and
certainly not qualified to do so). It's just that, OO does not fit my
'idea' of what *I* find Forth great for: Low level embedded control
(pollution monitors for rivers, rain gauges, control panel monitors
(reading buttons/keys, lighting LED's etc). In those scenarios, one
would stay away from OO, because one wants the memory model to be as
static as possible (memory fragmentation in real-time mission critical
applications is very bad news).
To me, Forth is a 'step up' from Assembly, but with a *massively*
increased productivity curve, and the interactivity is a huge bonus
too. If I needed OO, I would look at something like Java.
But, that's just me, and I am not really experienced enough in Forth
to be saying all this stuff, so you should ignore me!
I guess it comes down to the right tool for the right job. If I wanted
an business application (like a HMI visualation app) I would objects,
so I'd look at something that was 'OO to the core' like Java. If I was
building an emergency shutdown system to stop a compressor, I would
look at Forth as an EXCELLENT candidate, over C, assembly, FBD or
Ladder.
Regards
Mark.
John Passaniti
> "Show words that have interesting run-time behaviors that
> can't be done in other languages."
>
> Ok:
>
> IF
> THEN
> ELSE
>
> Please post the appropriate C code to reproduce the above.
I'm not sure I see the point since most Forth's don't allow if/then/else
on the command line so this code would have to be in a definition. You
seem to be defining a word that does nothing based on what's on the
stack. Doesn't seem terribly useful, but sure, behold the awesome power
of nothing:
void pointless(int test) { }
Or maybe you meant that as a placeholder for other code:
typedef void (*func)(void);
void pointless(int test, func true, func false) {
if (test) true(); else false();
}
Or something else.
ayr...@gmail.com
> ["]In Forth, I'm CREATING A LANGUAGE. Look! I created word
> called SPIN! Imagine trying to do that in a language like C! Sure, you
> could call it "spin" but
in C, you'd quickly learn better: the problem is with the
namespace, not syntax. In languages with packages, nameable
namespaces, in Forth when you conceive of its wordlist as the
normal unordered bag of symbols, then it may take you a tiny bit
longer to learn better. Forth _is_ different, here, and you
shouldn't softpedal the differences just to reinsert a pin into
a voodoo doll.
One difference is the linearity, which also makes up for the
lack of lexically-available functions. Another you identify and
call 'trivial'. That you can execute
Q. What phrase does Samuel Falvo use to describe Forth,
that I thought was odd in context?
a. "Code is data"
*b. "Data is code"
c. "Code is code"
d. "Data is trivial"
is nothing special. People invent whole languages to support
such as a
:- type json ---> string(string)
; array(pair(string, json))
; number(float)
; ...
that defines this type, accessors for it, that extends the
pattern-matcher over these accessors, etc. But declarative code
is just for people who get terribly confused by C's syntax.
> these stupid toy examples [...] don't promote thinking.
They promote emotion -- a prerequisite to any kind of
thinking in the contexts that they occur in. Obviously
management and shrink-wrap customers will have to see
something entirely different.
ayr...@gmail.com
> I'm not sure I see the point[;] this code would [appear] in a definition.
That MarkWills simply offered these words as normal words
that do something interesting, and that you speak of 'on
the command line' and 'in a definition' as if these existed
each in their own airtight bubbles -- _is_ the point.
Here's an elaboration of it:
MarkWills
I'm not sure you saw the point either, or you avoided it.
The point is this: IF/THEN/ELSE cannot be defined in C. They can in
Forth, in terms of itself (BRANCH/0BRANCH). I don't know why you
suddenly brought the command line into the equation. You asked "Show
words that have interesting [[run-time]] behaviors that can't be done
in other languages.". I chose C, and IF/THEN/ELSE. C has no immediate
mode. No 'command line'.
>I'm not sure I see the point since most Forth's don't allow if/then/else
on the command line so this code would have to be in a definition.
IF/THEN/ELSE are in definitions. Always. They are high level words
(normally), written in Forth. They execute at run-time only, just like
C, so the playing-field is level and equal.
My challenge still stands!
Stephen J. Bevan
> The point is this: IF/THEN/ELSE cannot be defined in C. They can in
> Forth, in terms of itself (BRANCH/0BRANCH).
My Forth doesn't have BRANCH/0BRANCH, nor apparently does ANS Forth.
Thus it is not clear to me how one meets the challenge in ANS Forth.
Regardless of whether it can be done or not, IMHO the challenge fails
the "interesting" test since nobody is going to care whether Forth can
be used to define something that is considered a built in feature in
most languages.
Anton Ertl
>What would promote thinking? Show a defining word that does something
>non-trivial. Show words that have interesting run-time behaviors that
>can't be done in other languages. Show something like adding a major
>language feature in a few lines of code (like mini-OOF). In short, show
>something that makes Forth unique.
Yes, Mini-OOF is something that I show to my students. Another
example is the Forth quines we have worked out some time ago
<http://www.complang.tuwien.ac.at/forth/quines.html>, where we get to
different solutions by putting different restrictions on Forth. With
enough restrictioons you get a solution equivalent to the usual C
solution. Looked at it in another way, the things you have to take
away to get there are things that Forth does not have and that C has.
- 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
Anton Ertl
>Another
>example is the Forth quines we have worked out some time ago
><http://www.complang.tuwien.ac.at/forth/quines.html>, where we get to
>different solutions by putting different restrictions on Forth. With
>enough restrictioons you get a solution equivalent to the usual C
>solution. Looked at it in another way, the things you have to take
>away to get there are things that Forth does not have and that C has.
This should of course be "... that Forth has and that C does not have".
I should not post when I am tired.
Stephen Pelc
>So my question is - is there any way to make Forth attractive to new
>generations of programmers? Is there any way we can come up with a new de-
>facto standard set of vocabularies with new features, which offer
>programming leverage sufficient to compete with the likes of Python and
>its pals?
The key is not the language itself, but in application libraries.
There's vast range of Forth sytems at any price, performance or
application point. What's missing are libraries and their collation,
a topic that *is* being addressed.
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
Unknown
> For me, the language, in it's current form lacks nothing. In fact, I'm
> probably in the old-school camp, and would advocate reducing the
> dictionary down to a much smaller size,
Can you use it for these problems?
Count the occurrences of distinct sequences of letters ("words") in a
text file, sorting the results primarily by the counts and secondarily
by the "words".
Calculate 33!.
Unknown
> : ... S" S" . ;
> : --- S" O" . ;
> ... --- ...
> SOS ok
>
> And they all go "HOLY ****! Thats REALLY COOL!"
>
> Then they're hooked. :-)
Children are childish.
Let's look at OCaml.
Define an infix operator for creating an array containing a range
of integers:
# let ( -- ) a z = Array.init (z-a+1) (fun i -> i + a);;
val ( -- ) : int -> int -> int array = <fun>
Create array containing 2 through 8, inclusive:
# 2--8;;
- : int array = [|2; 3; 4; 5; 6; 7; 8|]
Unknown
> MarkWills wrote:
>
> > For me, the language, in it's current form lacks nothing. In fact,
> > I'm probably in the old-school camp, and would advocate reducing the
> > dictionary down to a much smaller size,
>
> Can you use it for these problems?
I guess not. Of course, it's well-suited for flushing toilets.
That's what the regulars here want. A low, low, low level
toilet-flushing language.
>
> Count the occurrences of distinct sequences of letters ("words") in a
> text file, sorting the results primarily by the counts and secondarily
> by the "words".
Ruby:
h = Hash.new(0)
IO.read("Bible--kjv10.txt").scan(/[a-z]+/i){|w| h[w] += 1}
puts h.map{|k,v| [v,k]}.sort.map{|a| a.join " "}
--- part of the output ---
....
2 wretched
2 writest
2 wronged
2 x
2 youths
2 zealously
3 AND
3 Abba
3 Abdi
3 Abelmeholah
3 Abiel
3 Above
3 Achshaph
3 Adiel
3 Adonibezek
3 Adonikam
3 Adrammelech
3 Adullamite
....
12346 in
12586 that
12846 And
13447 to
34542 of
38885 and
62169 the
>
>
> Calculate 33!.
Ruby:
def fac n
if n < 2
1
else
n * fac(n - 1)
end
end
==>nil
fac 33
==>8683317618811886495518194401280000000
Jonah Thomas
> Let's look at OCaml.
>
> Define an infix operator for creating an array containing a range
> of integers:
>
> # let ( -- ) a z = Array.init (z-a+1) (fun i -> i + a);;
> val ( -- ) : int -> int -> int array = <fun>
>
> Create array containing 2 through 8, inclusive:
>
> # 2--8;;
> - : int array = [|2; 3; 4; 5; 6; 7; 8|]
This is utterly unreadable. Your comments that start with # do not
explain anything and the ;; interrupt the flow of the line.
Not seriously, but I heard that sort of thing about Forth and I so
rarely get to pass it on to somebody else.... April fool?
John Passaniti
> Can you use it for these problems?
>
> Count the occurrences of distinct sequences of letters ("words") in a
> text file, sorting the results primarily by the counts and secondarily
> by the "words".
No, sadly, Forth has no way to do what you describe. Many years ago, I
remember there was some research on a way for Forth to cull out words
from a sequence of characters, but as I remember the funding fell
through and nobody picked up the ball. Worse, although someone did
figure out a way to allocate space to hold a counter, Forth has no way
to "add one" to that counter. I remember a paper presented at one of
the Rochester Forth conferences that theorized if this "add one"
operation could be put inside a loop with a conditional, it could enable
the very kind of thing you describe.
> Calculate 33!.
Yes, you found the other Achilles heel in Forth. In other languages,
the calculation of a factorial could be done recursively or by
iteration. But as Forth has no way to call a word recursively or to
loop, the calculation of factorials is not possible.
I got around this restriction in Forth by having a table of factorials
for all 32-bit integer values.
Ian Osgood
> William James wrote:
> > Can you use it for these problems?
>
> > Count the occurrences of distinct sequences of letters ("words") in a
> > text file, sorting the results primarily by the counts and secondarily
> > by the "words".
>
> No, sadly, Forth has no way to do what you describe. Many years ago, I
> remember there was some research on a way for Forth to cull out words
> from a sequence of characters, but as I remember the funding fell
> through and nobody picked up the ball. Worse, although someone did
> figure out a way to allocate space to hold a counter, Forth has no way
> to "add one" to that counter. I remember a paper presented at one of
> the Rochester Forth conferences that theorized if this "add one"
> operation could be put inside a loop with a conditional, it could enable
> the very kind of thing you describe.
Missing the point. Forth does not come with batteries included, such
as oft used data structures like maps and lists. You are expected to
roll your own, tailored to the needs of your application. (It is often
easy to make your data structures out of raw memory, but those kind of
techniques are a lost art, probably known only to old school assembly
language programmers. A "Data Structures in Forth" textbook or article
would be a welcome addition to the body of Forth literature.)
Concerning the problem at hand, the Forth dictionary itself might be
an appropriate tool. See the "k-nucleotide" example at the Benchmarks
Game site (was Shootout).
http://shootout.alioth.debian.org/gp4/benchmark.php?test=knucleotide&lang=gforth&id=2
> > Calculate 33!.
>
> Yes, you found the other Achilles heel in Forth. In other languages,
> the calculation of a factorial could be done recursively or by
> iteration. But as Forth has no way to call a word recursively or to
> loop, the calculation of factorials is not possible.
>
> I got around this restriction in Forth by having a table of factorials
> for all 32-bit integer values.
Again missing the point. Although the Forth application domains
usually don't need BigNums, it is easy to extend the language to
support them when required. See the Forth Scientific Library for one
implementation. (That said, there are much better languages for math
exploration, such as Matlab/Octave, Mathematica, and Haskell. Heck, if
you like post-fix, you can use dc at the Unix prompt.)
For serious use of factorials (probability and statistics), you
usually want a different formulation anyway because you actually want
a ratio of factorials.
Ian
John Passaniti
> Missing the point.
> Again missing the point.
And I think you missed both the date, and the dripping sarcasm of my reply.
rickman
Dripping is an understatement. I had to use four heavy bath towels to
mop up my desk...
Rick
Doug Hoffman
> William James wrote:
>> Calculate 33!.
>
> Yes, you found the other Achilles heel in Forth. In other languages,
> the calculation of a factorial could be done recursively or by
> iteration. But as Forth has no way to call a word recursively or to
> loop, the calculation of factorials is not possible.
>
> I got around this restriction in Forth by having a table of factorials
> for all 32-bit integer values.
Carbon MacForth:
needs file big.4th
\ Arithmetic on big signed-magnitude numbers.
\ Forth Scientific Library Algorithm #47
\ Copyright 1996 by Leonard Francis Zettel, Jr.
: move$ ( src$ptr\dest$ptr --) \ copy src to dest - overwrites
: add$ ( src$ptr\dest$ptr --) \ add src to the end of dest
: NUMBER->$ ( n addr -- ) \ Convert number to counted string at addr
create numberpad 15 allot
create bigpad 25 allot
: n>big ( n -- bigptr )
numberpad NUMBER->$
c" big " bigpad move$
numberpad bigpad add$
bigpad count evaluate ;
: fact { n -- n! }
n n>big
1 n DO i 2 = IF unloop exit THEN i 1- n>big big* -1 +LOOP ;
33 fact big.
8683317618811886495518194401280000000 ok
Clearly this must be wrong because it doesn't match the output on my HP
calculator (the calculator doesn't show that many digits). Besides, as
John says, it can't be done in Forth.
-Doug
DavidM
> This is utterly unreadable
Hehe, a slightly ironic remark to make on a Forth newsgroup :P
DavidM
> And I think you missed both the date, and the dripping sarcasm of my
> reply.
Or, he's been using one of those ultra-minimalist forths that don't have
iteration or recursion :P
Jonah Thomas
>
> > Count the occurrences of distinct sequences of letters ("words") in
> > a text file, sorting the results primarily by the counts and
> > secondarily by the "words".
>
> Ruby:
>
> h = Hash.new(0)
> IO.read("Bible--kjv10.txt").scan(/[a-z]+/i){|w| h[w] += 1}
> puts h.map{|k,v| [v,k]}.sort.map{|a| a.join " "}
Standard Forth doesn't give you all the tools to do that. My natural
thought here is to set up some new wordlists whose hash function is the
first four characters. So they'll be mostly sorted. For each new word,
you look it up
ihttp://mycplus.com/source-code/java/count-the-words-in-a-file-java/n
each wordlist and if it isn't found anywhere, put it in the first one.
If it's found, remove it from that wordlist and add it to the next one.
If it's found in the last wordlist, make a new wordlist and add it to
that one.
There's a limitation on word length, maybe 31 characters or maybe 63.
There's the extra work of sorting the words past the first four
characters. And you have to know a lot about how the particular Forth
dictionary works, and use various nonstandard functions.
OK, you can put each word in one wordset and leave it there with a
count. You do a variant of WORDS once for each number of occurences up
to the last, checking each word to see whether it has the right number
of occurrences and printing its name if so, after you check whether the
next word also matches the first four characters and if so, compare to
see which goes first, recursively.
Well, you can leave the hash function alone and just give each name a
count and an entry into a linked list. After all the words are entered
you can make an array of number-of-occurrences and make a linked list of
words for each of them. The only nonstandard part is getting the name
from the body address. You could store the names again too, and make it
standard.
So, you have to make the linked lists yourself. Not nearly as compact as
the Ruby version. John Passaniti says if you have a language that's
particularly good for your problem, then use it. Forth as it's usually
provided is not particularly good for this problem. Better to use Ruby
unless it takes too long to figure out how to do make that scan function
do just what you want and test it.
But if you want to get a solution really quick, it's better to use a
library. I put
Count the occurrences of distinct sequences of letters ("words") in a
text file
into Google and got some leads.
http://mycplus.com/source-code/java/count-the-words-in-a-file-java/
claims to do pretty much what you want, but at first glance the code
appears to be missing.
http://www.hermetic.ch/wfca/wfca.php
advanced version that does much more than you want with a full GUI
interface and many bells and whistles for $42.25
http://www.faqs.org/docs/javap/source/WordCount.java
The missing code from the first reference.
http://crl.nmsu.edu/cgi-bin/Tools/CLR/clrcat#L0
WLIST does part of what you want but I didn't check whether it did it
all.
http://www.scribd.com/doc/5557479/Extremely-Fast-Text-Feature-Extraction-for-Classification-and-Indexing#document_metadata
They claim they have an efficient algorithm but probably don't actually
output what you want.
http://www.allbusiness.com/accommodation-food-services/498941-1.html
They attempt to sell an advanced version of this program to the hotel
industry to analyse customer comments.
http://www.cs.utah.edu/dept/old/texinfo/gawk/gawk_19.html
They describe how to do this in unix using tr awk and sort.
My natural thought here is to use the java version and if necessary
massage it slightly. Somebody else has already written the code nad
tested it -- why write a regexp (which is an inherently buggy and slow
operation) in Ruby when you can use the regexp somebody else has already
banged their head against in whatever language?
On the other hand, if you don't remember java well enough to modify it
easily, the awk version comes in easy-to-manipulate pieces.
Could this functionality be reproduced in Forth? Sure. But why bother?
there's nothing special about it. Why go to the trouble to reproduce in
Forth what you can easily do some other way? Wil Baden did a lot of this
sort of thing in Forth and as far as I know nobody joined him much, and
eventually he switched to doing it in a language where he didn't have to
build all his own tools for himself, where there was a community of
others doing similar things.
Well, but if you want to do part of the work in Forth and part in
another language then you need them to communicate well. In Unix it
isn't hard to do that with pipes. Marcel Hendrix has proposed a
reasonably simple set of Forth words that can do a whole lot of pipe
stuff without having to consider the difference between Windows pipes
and Unix pipes.
A number of Forths communicate well with C, but there isn't yet
agreement about a standard syntax so the code doesn't port well among
them. If you can talk to C programs you can probably talk to other
languages that can talk to C programs.
Meanwhile, it might be useful to have more string stuff in Forth. The
problem has been that working with strings tends to be complicated and
unnecessarily complicated. Lots of little detail stuff to keep track of.
Do it yourself and it's complex. Let the system do it and it's a lot of
stuff going on behind your back that breeds inefficiency of various
sorts. If the complicated string handling is something you're doing to
make your work easier, maybe it would be easier not to do it. But when
complicated string handling is the point in itself....
If there was going to be an extended string package beyond the string
words that are already there, what should be in it?
Jeff Fox
A couple of years ago the problem you describe came up for me.
I didn't use wordlists of course, just some simple Forth code
that took about an hour to write. It was SO much simpler than
the convoluted methods you describe!
Yesterday was April Fools Day, the day for making statements
like if it isn't already a defined word when you open the
Forth box then it isn't possible to program it in Forth!
You missed it by only one day!
On Apr 2, 8:53 am, Jonah Thomas <jethom...@gmail.com> wrote:
> Standard Forth doesn't give you all the tools to do that.
April Fools!
> Could this functionality be reproduced in Forth? Sure. But why bother?
Because what I did to solve the problem was SO much easier than what
you describe. This is simply another case where you prove that you
can make any problem more complicated to solve than other people and
design an ugly backward solution.
> there's nothing special about it. Why go to the trouble to reproduce in
> Forth what you can easily do some other way?
That's where you made you logic mistake. The Forth way is easy, YOUR
way is much harder. You are comparing bad Forth to average JAVA.
When you show how badly you would code in Forth are not proving
that Forth can't do something, only that you can't do it in Forth.
> Wil Baden did a lot of this
> sort of thing in Forth and as far as I know nobody joined him much, and
> eventually he switched to doing it in a language where he didn't have to
........................^ switched back to doing it .......
He switched from C to Forth to make copies of his C programs in Forth.
I always wondered why when he had working programs in C or a C system
that he rewrote those exact same programs into Forth. What did it
gain?
When he was done he just had two copies of the same programs to do
the same things in the C environment that he had been doing in C in
the first place, except that now one required much more effort and
was much more inefficient because the same problems solved simply
and efficiently in C in a C environment were not being solved a second
time inefficiently in a Forth written in C for a C environment to
solve C problems.
I think he eventually figured out that other people were not
interested
in repeating what they had already done in C a second time in a Forth
in C. Other than bad habits it would gain them nothing. So I think he
abandoned the futility of it and returned to doing C in
C which seemed to make more sense to everyone.
> build all his own tools for himself, where there was a community of
> others doing similar things.
I recall his presentation at FORML about reproducing his set of
version control utilies that he had written in C but now in Forth.
These were all copies of C programs he already had to help with
the C programming. Now he had gone to the trouble to make pale
copies of his C programs in Forth. I am sure I was not the only
person who wondered why. If you have a working C program for
doing version control in your C development enviroment then
why bother to write a second version in a Forth written in C?
But I know that c.l.f has a lot of people who don't really
write code in Forth. They write 'about' Forth. ;-)
Other people must have also questioned the futility of not
doing anything new, just repeating old C code again and
making useless duplicates of existing C code.
But what I found most amusing was Chuck's comment. Chuck and
Wil were almost always on opposite ends of point of view.
And even when Wil was given three hours to talk about his
projects at SVFIG he would not tolerate Chuck talking about
Forth or Forth chips without shouting him down many times
in his presentations to continue to talk about RISC chips
and C code when it was Chuck's turn to talk. It was sad
but I have it on tape.
But at FORML after Wil did his presentations about RE-writing
a bunch of C programs into Forth in C programs Chuck made an
amusing comment. Chuck said that since he no longer used
source code the popular C source file management utilities for
C files in C operating systems were of no value to him.
I think Wil was upset that SVFIG would allow talks on Forth
that wasn't written in C, or talks about Forth chips, or
whatever. It is hard to say why he had to keep interrupting
Chuck to say he was wrong. I think Wil thought of SVFIG
the way many people do of c.l.f. C is ok, but not Forth.
Wil was like you in being able to make anything more
complicated than what other people would do. Skip Carter
once said that if you understood ThisForth that you deserved
a doctorate in computer science. Most people don't think you
have to have doctorate in computer science to understand what
a Forth system does, but ThisForth was different. The nightmareish
complications it used always had it at the bottom of all performance
comparisons even when people compared it to the most lame hobby
Forths.
It is not wonder that more people didn't follow Wil's example.
It would have been nice if more people would have studied his
string package I think.
I was quite interested in his work for a long time. I was impressed
by how his integrated Forth editor worked until I found out the
details. I was interested in how he did the GUI stuff until I
learned that he really didn't do it at all and was entirely
dependent on lots of Apple OS services to do almost everything
he had never mentioned that it had an enviromental dependency
on a few megabytes of Apple code doing everything for him.
I had done similar things was a few K of Forth and wanted to see
how Wil did it differently. I was disappointed to learn that he
had done only a fraction of what I had thought and that he had a
lot of code which did very little except to call a massive amount
of external code that he didn't write. Sure, it you want to
make things more complicated and do more effort you could do
the sort of things he did in this regard and end up with an
Apple/Unix dependency.
I think it is simply a case that Chuck designed a language to
avoid the multi-language nightmare according to the first
paper on Forth. And that's a very different idea than
adapting the language to a multi-language environment. I
like to say it is the difference between Forth and Forth
script for some other non-Forth system.
Wil and Chuck were on opposite ends because to Chuck Forth
meant a replacement for C where less code does more and
where the system does not have real layers and is more of
an integrated whole. So Chuck needed Forth programs for
a Forth environment to do things you need in Forth.
Wil used Forth to duplicate things already done in C even
if no one understood why. Wil saw Forth as another layer
in C environment to solve the C problems that were already
solved by C programs even if no one understood why he
would want to do that. So his Forth was always the
biggest and most complicated and least efficient. His
needs were C based and far more than Forth needs.
Like you he would always look for the most complicated
solution. This is unlike Chuck who says Forth seeks the
least complicated solution.
So Chuck likes to work from a few K of Forth. Other people
need to start with many megabytes of C based stuff and
then they need a bridge to all that from Forth. This
glue to C is often much larger and more complicated than
just plain Forth itself. But that's the game when you
switch from simple Forth to complicated Forth script for
C systems.
> Well, but if you want to do part of the work in Forth and part in
> another language then you need them to communicate well.
Indeed the glue may be much larger and more complex than Forth
itself. You are likely to end up with either the biggest and
most complex Forth or the lowest performance Forth this way.
> In Unix it isn't hard to do that with pipes.
Sure. Unix is written in C. Everything is a file. That is sure
different than the idea that everything is a word. Unix is about
hostile C programs being kept under control. Forth is cooperative.
But if you write Forth in C and want it to be treated as a hostile
C program it becomes as complicated as other hostile C programs,
or perhaps moreso.
> Marcel Hendrix has proposed a
> reasonably simple set of Forth words that can do a whole lot of pipe
> stuff without having to consider the difference between Windows pipes
> and Unix pipes.
Reasonably small amount of glue to a C OS. Ok. But what is
reasonable
to you or Wil or Marcel looks pretty big and complicated to people who
are used to Forth without the hundreds of megabytes of C overhead that
you are talking about.
> A number of Forths communicate well with C,
Mostly you are talking about C programs instead of Forth programs.
If you write a C program it is easy to get it to 'communicate well'
with other C programs. One C program talks to another, big deal.
It is a very different idea that Forth which says that Forth is
an alternative to all those hundreds of megabytes of C code that
is so incredibly complicated.
> but there isn't yet
> agreement about a standard syntax so the code doesn't port well among
> them.
And we can all hope that Forth standard will never be about C.
The standard has gone halfway there already. Is it your desire to
get all the Forth out of Forth so it can replaced with C?
> If you can talk to C programs you can probably talk to other
> languages that can talk to C programs.
Sure. The language of the OS is always the favored language for
programs hosted in that OS (and language) so any language written
in C will easily interface to other languages written in C in the
OS designed to handle multiple hostile C programs at the same time.
Thankfully Forth is a thousand times simpler when you have Forth
that isn't 99% about C systems.
> Meanwhile, it might be useful to have more string stuff in Forth.
There is a lot of string stuff out there. What more would you want?
> The
> problem has been that working with strings tends to be complicated and
> unnecessarily complicated.
Well Forth strings make it pretty easy. It does get pretty ugly if you
switch to C style nul terminated strings or mix C and Forth methods.
If you learn to program in Forth it is pretty easy to do. If you
don't
learn to program in Forth you might think it is going to be easier to
cut and paste from some C package. It is just a matter of whether you
want to do Forth or C.
> Lots of little detail stuff to keep track of.
> Do it yourself and it's complex.
No.
> Let the system do it and it's a lot of
more effort and more work and more resources that go into the effort.
> stuff going on behind your back that breeds inefficiency of various
> sorts.
Sure performance and productivity drop when you don't do it yourself
in Forth, or don't use a Forth string package, and instead look for
C interfaces and programs with all the required glue to get the
same thing done.
> If the complicated string handling is something you're doing to
> make your work easier, maybe it would be easier not to do it. But when
> complicated string handling is the point in itself....
I wonder just what sort of 'complicated string handling' you are
talking about. What sort of complicated string handling are you
imagining in Forth applications?
> If there was going to be an extended string package beyond the string
> words that are already there, what should be in it?
I suppose we will see string packages that support unicode
transparently
but from what I have seen these will be many times more complicated
than ASCII string packages. Forth 200x perhaps.
When I first saw the proposal for 200x Forth I natually assumed that
it
was just a step in the progression of making Forth more complex. You
start with 1x Forth then some people make it ten times more complex
and
have 10x Forth. Others make 50x, 100x, and eventually 200x Forth.
I was amused to learn it meant 2009 not 200 times because it still
looked a lot like 200 times Forth to me. ;-)
Not enough damage caused by the standard so far. But with enough
effort there is no limit to how complex and ridiculous a standard
can be. I should file a proposal that the new standard be named
500x Forth or maybe be more forward thinking and call it
10000x Forth. ;-)
Best Wishes
Anton Ertl
>> William James wrote:
>>
>> > Count the occurrences of distinct sequences of letters ("words") in
>> > a text file, sorting the results primarily by the counts and
>> > secondarily by the "words".
>>
>> Ruby:
>>
>> h = Hash.new(0)
>> IO.read("Bible--kjv10.txt").scan(/[a-z]+/i){|w| h[w] += 1}
>> puts h.map{|k,v| [v,k]}.sort.map{|a| a.join " "}
Shell utilities:
awk 'BEGIN {RS="[^a-zA-Z]+"; ORS="\n"} {print}' vmgen.texi|sort|uniq -c|sort -n
>Standard Forth doesn't give you all the tools to do that. My natural
>thought here is to set up some new wordlists whose hash function is the
>first four characters. So they'll be mostly sorted.
...
That sounds quite complicated. Forth certainly does give you the tool
to do a table indexed with the words: wordlists. If you have long
words, just use a Forth system that supports long names in the
wordlist (e.g., Gforth); if you need case sensitivity (or
insensitivity), use a system that supports that (Gforth supports
both).
I guess that there are also systems that include a sort, but
strangely, I have not needed a sort outside of shell programming in
the last 20 years, so I have not yet ported the one I wrote so many
years ago to standard Forth.
BTW, as shown above with the shell script, you don't need the lookup
table, sorting with counted uniqueness is good enough. If you do a
heap sort or a tree sort, the counted uniqueness is a trivial variant.
>http://www.cs.utah.edu/dept/old/texinfo/gawk/gawk_19.html
>They describe how to do this in unix using tr awk and sort.
Ok, my script can be made a little shorter with tr:
tr -c 'a-zA-Z' '\n' <vmgen.texi|sort|uniq -c|sort -n
It's funny that the gawk book used tr where I used awk.
And obviously the Ruby code above is just a huge pile of bloat; any
Forth version would be even more bloated.
- 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 2009: http://www.euroforth.org/ef09/
Jonah Thomas
> Hi Jonah,
>
> A couple of years ago the problem you describe came up for me.
> I didn't use wordlists of course, just some simple Forth code
> that took about an hour to write. It was SO much simpler than
> the convoluted methods you describe!
That's fine. How long do you suppose it took William James to write his
3-line Ruby program? I can imagine it might have taken him an hour to
write it and test it enough to be reasonably sure it had no flaws. But
maybe he's good at Ruby and he could write that 3-line program in much
less than an hour.
How simple was your solution? Was it more than 3 lines?
> > Could this functionality be reproduced in Forth? Sure. But why
> > bother?
>
> Because what I did to solve the problem was SO much easier than what
> you describe.
Are you recently unemployed? It seems like for sometimes years at a time
you find something better to do than come here and harass me, and now
you're back again. Can you tell us anything about Intellasys etc?
> > there's nothing special about it. Why go to the trouble to reproduce
> > in Forth what you can easily do some other way?
>
> That's where you made you logic mistake. The Forth way is easy, YOUR
> way is much harder. You are comparing bad Forth to average JAVA.
I didn't take a close look at the java code, I just found it was
published. I'm pretty sure I could write it in Forth smaller and simpler
than the java code, particularly if I take out all the lower level
routines and call them a library. But-- the java code is already
written! Somebody thought it was good enough to be an example to show
people about how to write java. So if I can use it, I don't have to
write the Forth code at all except to show William James that it can be
done in Forth. I found it in about 3.5 minutes. Add in the time to break
out a java compiler and get it running, and if all goes well it might
take me less time than it took you to do it in Forth.
> > Wil Baden did a lot of this
> > sort of thing in Forth and as far as I know nobody joined him much,
> > and eventually he switched to doing it in a language where he didn't
> > have to
> ........................^ switched back to doing it .......
>
> He switched from C to Forth to make copies of his C programs in Forth.
> I always wondered why when he had working programs in C or a C system
> that he rewrote those exact same programs into Forth. What did it
> gain?
I suspected he could probably debug the same stuff faster in Forth than
in C. If so, that's one thing it gained him.
> So I think he abandoned the futility of it and returned to doing C in
> C which seemed to make more sense to everyone.
I thought he switched to a modern language that let him get things done
much better than he'd been doing in C. I don't now remember which one.
> Other people must have also questioned the futility of not
> doing anything new, just repeating old C code again and
> making useless duplicates of existing C code.
That's what I'm talking about too. You could translate a java or C
program into Forth to solve this sample exercise. Or with effort you
could find a way that looked particularly elegant in Forth to do it. But
the result would be that you were duplicating the effort that other
people had already put into solving that piece of somebody's homework.
> Wil was like you in being able to make anything more
> complicated than what other people would do.
I'm learning better. Can you suggest ways I could improve faster? Last
week I was doing something that processed strings a character at a time,
and it was doing some stack thrashing. It looped around keeping track of
the location in the string, and it had to remember the beginning and end
of the string, and several other things. It was too much stack
manipulation. Then I tried using something that was just like SOURCE and
>IN and the complications went away. I started out not wanting to use
any variables but it turned out that just a few helped a lot.
> > Well, but if you want to do part of the work in Forth and part in
> > another language then you need them to communicate well.
>
> Indeed the glue may be much larger and more complex than Forth
> itself. You are likely to end up with either the biggest and
> most complex Forth or the lowest performance Forth this way.
But maybe most of the glue doesn't have to be on the Forth side. Then
the Forth can be simple and still interact with other stuff. The problem
with doing it all in Forth is you have to do it all. And if you want to
tell somebody else how great it is they'll say "Can you do this in
Forth" and it will be something that takes you an hour and they'll laugh
at you.
If you can get them doing some of their work in Forth and it's truly
easier for them, then they'll want to do more of it that way, and the
more of it they put on the Forth side of the interface the easier it
gets for them. If they have to commit to doing everything for themselves
in Forth before they start, they probably won't.
> > Marcel Hendrix has proposed a
> > reasonably simple set of Forth words that can do a whole lot of pipe
> > stuff without having to consider the difference between Windows
> > pipes and Unix pipes.
>
> Reasonably small amount of glue to a C OS. Ok. But what is
> reasonable to you or Wil or Marcel looks pretty big and complicated to
> people who are used to Forth without the hundreds of megabytes of C
> overhead that you are talking about.
Sure, but if you need to deal with the C OS then it's real good if you
can do so. I like the idea of rewriting Unix utilities in Forth. Get
them smaller and not too much slower, with maybe a second simpler
interface available too. The more of that you can get done, the more of
the system turns into Forth and allows you to simplify it further. But
I'm afraid it would be a losing battle. Unix experts can add complexity
faster than you can possibly remove it. Maybe in a special case. I've
played with a Linux named DamnSmallLinux, where they promise to provide
a functional system that's no more than 50 megabytes when it's stored.
So they have 50 megabytes of storage, and it can easily expand to 500
megabytes in RAM, and they're continually squeezed for space. They
replaced Cron with a perl script to save on size. I'm sure they'd be
happy to replace pieces of it with Forth if somebody wrote the pieces
for them.
> > A number of Forths communicate well with C,
>
> Mostly you are talking about C programs instead of Forth programs.
> If you write a C program it is easy to get it to 'communicate well'
> with other C programs. One C program talks to another, big deal.
> It is a very different idea that Forth which says that Forth is
> an alternative to all those hundreds of megabytes of C code that
> is so incredibly complicated.
Let's suppose that everything they want to do is already written in 500
megabytes of C. The crass opportunist will say to just use the 500
megabytes of C. But that's hard to maintain. So we get some real smart
Forth people to rewrite it in Forth and because they're personally so
good they can replace 500 megabytes of C with 500 kilobytes of Forth.
Hurray! So how long does it take them to write those 500 kilobytes of
working highly-functional Forth code? Is this the best use of their
time? If they can do that, it might be better to have them do something
that's really worthwhile that nobody's ever done before, and go ahead
and pay some C programmers to maintain the 500 megabytes of C code. Or
get some average Ruby programmers to replace the 500 megabytes of C with
50 megabytes of Ruby that's easier to maintain than the C was.
> > but there isn't yet
> > agreement about a standard syntax so the code doesn't port well
> > among them.
>
> And we can all hope that Forth standard will never be about C.
Sure, but if you have a standard syntax to call C routines, what's wrong
with that? You don't have to use it. You don't have to put it in your
Forth even if you want to call your Forth standard. But people who have
C routines can plug them into their Forths and use them without having
to rewrite the whole thing in Forth. Why is that a bad thing? I remember
a long time ago listening to some CS students complain about COBOL.
Various businesses thought they had a big investment in a bunch of
legacy COBOL code, and the students thought that was completely wrong.
The COBOL code wasn't an asset, it was entirely a liability. Throw it
all out and rewrite the whole thing in C and they'd be better off. But
those companies had a tremendous amount of domain knowledge stored in
their COBOL programs, things they didn't have documentation for. Throw
them away and it would take them a long time to write the specs to give
to the C programmers.
Now you tell people who have C routines to throw them away and rewrite
it all in Forth. But they might not be as good at Forth as you are, and
they want to use the stuff that already works. If they have to throw
everything they've ever done away and start over, they won't do it.
> > Meanwhile, it might be useful to have more string stuff in Forth.
>
> There is a lot of string stuff out there. What more would you want?
The string wordset in the Forth-94 standard provides a few simple tools.
Are there more tools that are so commonly useful they'd be useful in
most systems that use strings much?
Where would you suggest I start learning about the lot of string stuff
that's out there?
> > The
> > problem has been that working with strings tends to be complicated
> > and unnecessarily complicated.
> > Lots of little detail stuff to keep track of.
> > Do it yourself and it's complex.
>
> No.
Consider the matter of keeping track of a whole lot of strings. You can
keep them in 1K blocks. You can keep them in files. You can keep them in
memory, either at HERE or ALLOCATEd memory, or in CREATE structures or
string literals in code or even just loose ALLOTed spaces. If you have
multiple strings you need to keep track of them. You'll want to release
their memory when you no longer need them.
So if you ALLOCATE them it's easy to, say, concatenate two strings. Just
ask for a piece of memory big enough to hold them both, copy them both
into it, and free the old spaces. Heap fragmentation? That's not your
worry, the system can deal with it.
If they're in files then you can simply make a buffer big enough to hold
them, copy them both to the buffer, and write the buffer to a file.
Or you can use a string stack package.
Or you can use rubber-band memory. Copy strings at HERE and ALLOT the
space. When your routine is done copy any strings you want to return, to
the front of the space you alloted and then unallot the rest. Even if
your routine has a memory leak the one that called yours will get rid of
your trash when it flushes its own. I think this is one of the better
ways, but I haven't met anyone who agreed with me. People have talked
like they don't want to have to think about freeing up strings when
they're done with them. It ought to be automatic.
How do you do it?
> > If the complicated string handling is something you're doing to
> > make your work easier, maybe it would be easier not to do it. But
> > when complicated string handling is the point in itself....
>
> I wonder just what sort of 'complicated string handling' you are
> talking about. What sort of complicated string handling are you
> imagining in Forth applications?
Say you have a few hundred gigabytes of DNA data. It's strings of 2-bit
characters, but sometimes you only care about whether it's purines or
pyrimidines, so then you're only interested in the even bits. Sometimes
you care about 6-bit characters, and then you might also care about the
some but not all of the shifted data. You have a sequence to compare
against and you're looking for similar sequences that aren't exactly the
same. The strings are sometimes stored in various compressed forms that
reveal some of the sequence data you're interested in but which also
conceal some of it.
Well, usual characters are 8-bit or bigger and so we can't use any of
our usual string routines unless we waste space and use 2 bits per byte
or perhaps 6 bits per byte. Taking 4 times as much space is not such a
big deal when it's only hundreds of gigabytes, but when it's
petabytes, as it will be soon.... It might make sense to build FPGAs
that do special bitwise operations that traditional processors don't
bother with....
OK, a literary analyst is looking at esoteric subtleties in writing
style. She wants to look for similarities in style among the various
books of the bible that normally appear different, looking for
particular passages in the different books that may have been edited by
the same hand. It will involve lots of subtle string comparison.
If the application is a string-handling application then that's what
there is to do.
On the other hand you can add prefixes to Forth strings like $1000 or
Ox1000 or 'character or 'name or "this is my string" and make the Forth
parser work a little harder, and maybe the convenience will be worth it.
> Best Wishes
From your writing I tend to somehow doubt that.
Andrew Haley
> Carbon MacForth:
> needs file big.4th
> \ Arithmetic on big signed-magnitude numbers.
> \ Forth Scientific Library Algorithm #47
> \ Copyright 1996 by Leonard Francis Zettel, Jr.
> : move$ ( src$ptr\dest$ptr --) \ copy src to dest - overwrites
> : add$ ( src$ptr\dest$ptr --) \ add src to the end of dest
> : NUMBER->$ ( n addr -- ) \ Convert number to counted string at addr
> create numberpad 15 allot
> create bigpad 25 allot
> : n>big ( n -- bigptr )
> numberpad NUMBER->$
> c" big " bigpad move$
> numberpad bigpad add$
> bigpad count evaluate ;
> : fact { n -- n! }
> n n>big
> 1 n DO i 2 = IF unloop exit THEN i 1- n>big big* -1 +LOOP ;
> 33 fact big.
> 8683317618811886495518194401280000000 ok
Feh.
500 constant size
create b size allot
: *! ( n) 0 b size + b do over i c@ * +
10 /mod swap i c! loop 2drop ;
: .! b size +
begin 1- dup c@ until
b swap do i c@ [char] 0 + emit -1 +loop ;
: fac ( n) b size 0 fill 1 b c!
1+ 1 ?do i *! loop .! ;
33 fac 8683317618811886495518194401280000000 ok
Bignums, who needs 'em? ;-)
Andrew.
Marcel Hendrix
[..]
>> > Calculate 33!.
[..]
> For serious use of factorials (probability and statistics), you
> usually want a different formulation anyway because you actually want
> a ratio of factorials.
To look at the perfect number n = 2^(m-1) * (2^m-1) I have to use Forth:
Perfect number ( 9689 ) ->
11,434,731,753,038,652,271,870,510,502,563,054,290,369,839,984,534,725,895,332,249,364,908,334,
961,882,164,947,674,351,989,064,116,525,342,087,095,396,782,955,614,598,901,690,359,527,368,200,
306,791,037,330,859,857,972,857,435,008,419,908,682,920,845,277,220,892,386,034,162,964,072,635,
709,694,931,769,479,876,248,750,202,202,966,413,347,062,605,501,560,591,838,954,155,776,739,969,
243,412,686,516,039,219,207,531,547,575,533,505,784,997,468,578,047,154,815,673,455,144,291,529,
551,460,592,270,962,534,531,406,165,620,944,440,834,496,909,183,933,479,177,056,134,394,989,991,
079,872,495,003,112,497,387,572,982,253,655,871,642,841,276,259,997,777,969,281,650,961,184,963,
681,165,156,135,030,716,133,286,358,236,790,904,294,805,085,996,539,450,440,397,259,321,779,367,
404,437,324,097,409,473,827,763,050,662,988,434,475,431,439,487,893,781,464,232,206,686,643,397,
789,899,506,730,271,620,505,444,721,680,758,712,995,051,366,001,609,878,486,401,756,427,622,203,
061,515,536,013,038,628,113,933,285,137,794,681,656,964,917,604,398,533,820,705,074,441,564,282,
611,795,522,268,562,186,704,703,666,450,026,589,020,021,088,118,208,856,495,629,918,319,917,323,
246,502,646,278,589,671,096,849,425,171,744,978,412,686,617,422,702,072,318,303,876,067,532,120,
552,307,086,861,404,163,620,773,329,817,538,718,438,960,094,624,691,381,751,716,824,755,508,230,
593,661,091,142,583,022,460,070,488,652,758,870,749,893,562,067,416,666,683,134,710,937,562,255,
888,939,283,852,449,848,883,083,949,426,685,416,747,561,615,736,871,070,322,397,677,554,824,168,
698,122,415,887,624,044,491,081,523,702,163,186,214,860,670,963,974,843,434,990,150,580,336,061,
361,128,446,317,947,836,395,002,812,389,227,258,535,979,589,116,682,994,095,790,818,840,141,392,
100,002,121,484,746,263,398,298,269,011,568,647,849,919,325,130,179,957,764,082,742,812,086,707,
435,289,888,867,996,546,182,996,334,309,106,553,241,262,702,950,865,875,890,258,826,346,579,702,
381,381,532,554,959,190,921,932,580,283,034,694,452,612,563,595,237,410,148,597,510,276,295,301,
661,021,465,685,367,517,269,929,486,554,251,331,056,986,921,264,847,284,801,220,356,787,886,271,
451,144,575,296,681,731,210,806,262,017,773,614,658,565,355,556,304,203,525,721,218,368,092,716,
803,784,696,369,604,175,605,428,669,596,483,152,723,251,207,753,030,716,796,392,719,600,906,670,
836,303,595,493,470,714,193,198,199,178,512,164,466,800,911,266,395,980,327,226,741,775,067,834,
142,804,538,996,505,567,385,849,212,224,049,038,933,494,413,385,316,694,249,093,117,679,932,317,
175,631,713,976,414,497,786,785,387,930,339,300,514,992,922,213,670,421,059,098,550,054,655,566,
738,564,333,812,948,431,411,916,586,171,122,495,203,548,154,239,947,807,358,729,100,981,341,449,
364,010,936,920,913,641,239,353,666,202,161,372,565,303,868,912,597,733,470,916,773,974,659,066,
920,874,581,905,740,253,737,958,111,365,707,416,415,231,569,912,388,895,514,146,043,465,350,761,
210,218,323,219,258,114,752,999,284,649,256,433,615,427,727,357,746,247,521,167,973,626,920,033,
206,422,419,756,880,299,734,859,922,106,610,249,531,345,645,354,898,619,984,932,287,573,732,778,
253,405,930,614,511,563,461,083,563,246,421,004,359,764,227,776,138,493,737,491,924,858,971,325,
462,356,870,894,436,832,415,652,563,472,219,886,604,579,549,816,794,943,137,016,560,220,374,336,
411,461,772,411,702,666,554,424,421,193,101,769,766,866,425,031,904,228,432,899,084,328,109,382,
386,033,140,878,217,618,407,448,151,385,536,306,356,457,975,091,999,005,435,176,331,707,792,550,
355,847,678,919,185,649,003,980,612,844,127,464,953,441,948,908,653,658,626,757,079,065,602,042,
234,831,459,018,617,928,015,340,713,579,893,643,269,926,553,210,324,578,896,472,679,579,143,057,
499,255,651,721,081,978,203,990,842,068,950,170,363,945,528,154,181,566,893,322,027,199,540,013,
868,476,424,101,983,764,560,669,826,897,372,110,032,444,263,049,853,473,999,581,274,393,509,429,
702,030,074,534,259,774,441,912,514,321,429,954,486,641,764,862,389,912,165,634,753,298,503,496,
987,274,297,021,603,826,373,855,299,489,665,332,980,045,626,042,070,395,302,489,206,897,376,828,
872,831,681,309,460,233,198,673,717,948,526,193,173,815,998,486,243,236,940,990,054,151,299,552,
963,671,083,743,133,131,320,086,142,491,994,920,076,339,753,542,242,262,159,093,060,008,717,407,
830,801,449,149,246,407,429,054,060,057,869,231,925,190,215,381,637,354,397,581,702,813,299,581,
595,268,958,331,206,116,587,059,631,052,398,444,368,230,084,487,200,750,858,802,408,028,362,493,
080,958,863,203,350,540,104,302,885,439,820,929,652,846,810,822,012,268,159,368,936,948,783,149,
742,490,267,564,849,458,269,875,764,387,284,022,479,018,545,533,708,000,475,094,136,029,739,980,
611,391,149,404,998,948,850,020,574,720,276,367,581,532,096,367,245,450,111,438,861,314,016,502,
251,771,626,619,770,617,482,196,040,684,241,051,229,719,638,955,848,258,711,601,449,230,431,864,
642,738,016,264,616,230,947,661,977,546,921,165,614,303,336,920,594,873,047,129,309,514,963,615,
057,037,955,588,709,850,041,079,865,923,722,198,085,036,156,637,475,793,278,800,587,341,968,483,
510,391,600,602,017,902,571,012,696,459,982,918,204,357,935,377,381,473,615,091,532,577,811,728,
590,623,970,443,827,786,656,457,202,024,947,738,949,491,050,434,479,640,309,061,643,647,354,339,
446,987,086,176,829,031,794,081,709,808,641,497,939,028,951,694,979,450,772,527,950,272,653,789,
549,189,971,594,471,857,296,136,989,363,428,018,479,885,550,817,503,819,909,144,866,009,873,515,
648,871,527,470,089,667,117,218,970,465,504,135,840,326,783,375,492,476,724,744,637,849,602,929,
995,407,405,307,200,026,828,342,697,248,300,093,649,018,698,176,608,493,732,874,265,392,514,404,
262,371,752,333,888,107,561,805,388,511,227,497,667,587,557,858,216,793,416,669,121,295,999,876,
380,041,411,848,421,443,009,409,598,069,284,795,805,315,649,519,636,349,094,626,799,058,059,942,
233,564,734,694,322,979,510,381,089,501,783,149,257,954,775,477,023,435,267,078,094,581,178,106,
163,061,749,099,650,274,125,909,364,625,366,872,670,455,272,038,421,461,889,905,163,683,639,604,
619,158,296,889,325,942,133,250,572,297,473,026,399,636,420,841,343,337,282,032,910,249,489,036,
914,866,216,766,306,242,746,086,617,160,783,603,260,669,828,666,764,435,495,974,703,619,964,536,
047,254,724,730,591,094,280,669,421,719,280,473,782,354,957,913,365,214,181,469,812,017,021,835,
874,595,030,465,977,503,896,553,607,168,170,561,453,978,564,245,013,410,219,025,191,747,460,561,
722,957,552,496,171,653,955,970,861,351,116,645,053,443,355,424,088,047,260,644,609,728,255,333,
649,840,992,771,523,160,167,508,544,037,518,309,121,889,943,427,982,452,859,468,270,570,716,001,
999,480,469,941,211,598,166,013,334,561,097,000,740,254,837,141,359,183,281,132,981,187,173,003,
018,007,907,909,084,911,534,754,016,624,659,280,687,015,006,765,916,504,752,568,366,296,745,566,
161,382,550,432,878,374,711,432,860,784,006,448,579,385,752,658,478,330,108,911,715,416,587,381,
980,042,411,441,736,147,879,033,756,959,899,559,967,278,828,335,729,354,948,891,349,957,093,813,
441,062,886,451,717,319,282,051,073,285,430,699,786,813,324,786,910,033,950,981,485,068,506,291,
236,103,005,510,413,799,745,737,938,771,620,843,753,527,896,693,275,958,193,843,005,217,248,433,
029,017,905,892,371,468,821,164,355,559,298,391,566,587,285,882,803,155,556,329,668,836,395,442,
377,139,281,823,916,767,305,350,368,312,012,320,720,545,103,679,686,695,403,688,633,102,445,850,
860,912,200,011,106,419,036,420,168,218,686,675,505,880,007,154,586,289,426,045,638,467,535,055,
657,733,195,385,749,567,833,117,323,728,527,949,370,364,538,683,091,253,891,942,661,535,063,266,
940,844,527,310,380,742,163,037,454,132,151,629,920,196,049,269,431,333,414,952,710,111,030,436,
049,223,732,010,382,065,130,643,059,659,584,756,326,701,909,820,785,002,538,974,738,852,620,988,
773,021,343,666,913,185,983,024,145,754,783,451,177,014,049,057,728,513,234,967,982,558,429,577,
216 (144.575 seconds elapsed.)
Hmmm ... or did I make an error there?
-marcel
Jeff Fox
Belated April Fools ;-)
Doug Hoffman
> 500 constant size
> create b size allot
>
> : *! ( n) 0 b size + b do over i c@ * +
> 10 /mod swap i c! loop 2drop ;
>
> : .! b size +
> begin 1- dup c@ until
> b swap do i c@ [char] 0 + emit -1 +loop ;
>
> : fac ( n) b size 0 fill 1 b c!
> 1+ 1 ?do i *! loop .! ;
>
> 33 fac 8683317618811886495518194401280000000 ok
>
> Bignums, who needs 'em? ;-)
I do, apparently. But not you. Nicely done!
-Doug
foxchip
> That's fine. How long do you suppose it took William James to write his
> 3-line Ruby program? I can imagine it might have taken him an hour to
> write it and test it enough to be reasonably sure it had no flaws. But
> maybe he's good at Ruby and he could write that 3-line program in much
> less than an hour.
>
> How simple was your solution? Was it more than 3 lines?
Mine was a page of code. It took me an hour or more to write. I
never said it was easier or shorter than William James' code. I
was just joking about incredibly simple it was compared to your
explanation of what YOU were talking about doing! ;-)
For lots of things specialized languages may have the easiest
solutions, especially for most people because of their experience.
We could use an iTV card as a sort of Forth stamp and host web pages
and use them to control the computer with Forth script statements
in the pages. But my TINI board does something very similar to
that out of the box except that it has an ethernet interface and
the web page is little more standard.
Out of the box the TINI board is faster and easier to setup a web
page that does stuff very slowly. Of course most of the on board
computing power is spent doing that and only a tiny bit of
scripting power is left over for the user. If that's all you
need then TINI makes that easy. If you want more processing
then it doesn't.
Anything with specialized code is suppose to make the thing that
that specialized code does easier to do. In this case the idea
was that some scripting languages had primitives that more closely
matched sorting words than others. That's certainly true.
I was just joking about the insanely complicated way that you
described the picture. If I wanted to do what you said I would
just schedule a month to do it. If I had to learn another language
and use something like William's solution I could probably do
that faster than what you described. Not as fast as just writing
the primitive words in Forth. But if I already knew that language
or dialect of a language where I could write it in three lines
or less that would be fastest.
But of course I was joking about the your description. Not
William James' code or other languages. ;-)
> > > Could this functionality be reproduced in Forth? Sure. But why
> > > bother?
>
> > Because what I did to solve the problem was SO much easier than what
> > you describe.
BTW. I had thought I had sent you a private email. I guess I posted
it,
but I was mostly just joking about your sort of joking style of trying
to offer the most complex explanations of things. ;-)
> Are you recently unemployed?
Well, not exactly. I just happened to be sick at home and thought
I would send you email in the spirit of April Fools. I guess I was
more under the weather than I thought and posted to c.l.f. ;-)
If I mistype or make other mistakes a bug, bio virus not computer bug
or virus, might have degraded my focus more than I realized.
I have been getting caught up a few projects that fell behind in all
the non-stop high-tech development, some family stuff, playing with
the toys, getting some air time, making some changes for changing
times, and doing some celebrating too.
In this case I was just sick and home and bored. I had been reading
c.l.f and meant to sent you an email. It was in the spirit of
previous
emails and the tone was not intended for c.l.f where it would seem
like personal harsh criticism of you in particular. Sorry for the
error.
> It seems like for sometimes years at a time
> you find something better to do than come here and harass me, and now
> you're back again. Can you tell us anything about Intellasys etc?
I have only heard rumors about the work continuing at IntellaSys
since I declined to stay on the team there to leave room for people
who needed the uninterrupted income more than I. They still have
and are testing chips and are working on the projects they had
going including the ones they have made public. I don't know
more than that.
I have heard some rumors about talks betweeen TPL, (IntellaSys a
TPL Group), and Chuck. Since those talks are ongoing it wouldn't be
appropriate for me to comment. I could talk about patents and
politics like everyone else but I think people have expressed
their opinions on such things often enough. Except perhaps for
April Fools Day. ;-)
I have also been following the work on new chips and new projects
and new customers but haven't had a lot of involvement yet and
am not in a position to disclosing details.
> > > there's nothing special about it. Why go to the trouble to reproduce
> > > in Forth what you can easily do some other way?
>
> > That's where you made you logic mistake. The Forth way is easy, YOUR
> > way is much harder. You are comparing bad Forth to average JAVA.
>
> I didn't take a close look at the java code, I just found it was
> published. I'm pretty sure I could write it in Forth smaller and simpler
> than the java code, particularly if I take out all the lower level
> routines and call them a library. But-- the java code is already
> written! Somebody thought it was good enough to be an example to show
> people about how to write java. So if I can use it, I don't have to
> write the Forth code at all except to show William James that it can be
> done in Forth. I found it in about 3.5 minutes. Add in the time to break
> out a java compiler and get it running, and if all goes well it might
> take me less time than it took you to do it in Forth.
I had the impression from your description that you weren't just
talking about JAVA and talking about Forth and Java. I had the
impression
that you were talking about calling JAVA from Forth etc. I might make
that mistake fairly often since I often have the impression that
you are seeking to add extra layers just to have the most long
winded explanation and most complex way of approaching a problem.
> I suspected he could probably debug the same stuff faster in Forth than
> in C. If so, that's one thing it gained him.
You shouldn't say bad things about C, like it is buggier or harder to
debug than Forth in c.l.f lest you upset the C defenders. Sure the
lowest level of Forth is using it as debugger, it is a debugger that
is
useful. You can debug your buggy C programs with Forth, if your
problem is C bugs that can't be avoided.
And I also realize it gained Wil fun. And it gained some nice code
and clever Forth for other people like me to learn from. I would not
have made videos of his presentations and distributed them if I
didn't think they had value for others. Personally I felt people
ignored the good stuff. I would have liked to see something other
than typical C code problems addressed but I do know there was
other value. Remember it was an email joke.
> > So I think he abandoned the futility of it and returned to doing C in
> > C which seemed to make more sense to everyone.
>
> I thought he switched to a modern language that let him get things done
> much better than he'd been doing in C. I don't now remember which one.
I know he said he used real Unix not bastard Linux and that his Forth
code was very dependent on his toolbox and the Mac toolbox etc.
> > Other people must have also questioned the futility of not
> > doing anything new, just repeating old C code again and
> > making useless duplicates of existing C code.
>
> That's what I'm talking about too. You could translate a java or C
> program into Forth to solve this sample exercise.
I understand.
The thing I was trying to emphasis is the nature of the sample
exercise.
Is it a good representation of a sample of Forth or not?
Any program can be done in one word (at the top level, be it a Forth
word, script, or executable program) if everything below it is already
in place. Languages have primitives for the things they do. If your
problem is building Perl scripts or JAVA then hopefully the problems
you are solving are problems that are matched to what the languages
offer for those problems.
Naturally scripts that are simple in scripting languages are suppose
to be more difficult to write in languages that are not specialized
and without the primitives needed to quickly get to the top level.
I never disputed that.
One can add packages to Forth. There could be portable Forth
packages with the primitives needed to do short specialized scripts
just like those in other scripting languages. My take is that
if someone or a group want to do it they will and then they can
recommend that it become a 'standard' package after it is a
defacto standard package.
Or people who say they care about such things could complain
about how no one does that in c.l.f for decades instead. ;-)
But back to the point. Should we care about how easy it is to
do things in Forth that we would use some other languages to do?
I don't see why. Are you arguing with someone who is claiming
Forth should be used for all things even when some other specialized
tool matches a job better? If so I would love to know who.
I think it makes more sense to evaluate Forth the problems where
Forth is designed to be used.
You don't try to drive your pickup truck on the racetrack at the
same time as the vintage cars. You don't haul the load of dung
in the vintage car. Why care about things people don't do?
> Or with effort you
> could find a way that looked particularly elegant in Forth to do it. But
> the result would be that you were duplicating the effort that other
> people had already put into solving that piece of somebody's homework.
Absolutely.
But my point of view is that Forth is probably not designed to do
the homework that your Perl or JAVA programming instructor gave you.
I think it makes more sense to care about how to do Forth homework
in Forth. I can understand that students who only have exposure to
a particular computer environment may get homework and ask how
someone would do it in Forth.
What I don't get is why people don't just tell the students when
they ask about specialized language homework assignments that their
homework problem does not come up where Forth is used or that if
your Forth has these specialized tools it is just as easy to
use as whatever.
> > Wil was like you in being able to make anything more
> > complicated than what other people would do.
>
> I'm learning better. Can you suggest ways I could improve faster?
I don't know what you have been doing. I know you said you had
quit using Forth and had switched to Java some time ago. I don't
know what problems you were solving then either only you do.
If you want to improve your Forth skills the best thing to
do is practice the real thing doing real code. The next best
thing is doing exercises or repeating the problems others have
solved so that you can compare your solutions to their and
find ways to improve your code.
It really does appear to me that you don't spend much time
looking for the simplest solution. You work from A to B once
you get there that's it. Sometimes you go back and look for
some shortcuts. But these seem to me to smaller and smaller
variants of the original working A to B route that you found.
I guess I don't see you starting by looking at all the
different ways to get from A to B, before going into the
depth required to verify the solution is complete.
Once you decide you need the rent a car and a ride to go
get it, and insurance, and a way back when you are done
and all the other complications you are past the point
of finding out that a bus went from your door to where
you wanted to go at exactly the right time. You seem
to select the first possible or most common solution
and then flesh out detail after detail no matter how
complicated it gets.
Occasionally you go back and clean up a bit on the
plan to take the X bus, then walk, then get the rent
a car, make appointment, return rent a car, walk,
and take the X bus home but are cleaning up the plan
without considering that the Z bus there and back
would be MUCH easier.
Most of the time you seem to be talking about the
futility of optimizing your plan any further because
the X bus only runs once every two hours and the
rent a car place is closed for lunch etc. You
ask about optimizing things without much context.
Usually I read your long descriptions and then
say, "Why didn't he take the Z bus?"
> Last
> week I was doing something that processed strings a character at a time,
> and it was doing some stack thrashing.
That sounds bad. Backed into a corner already with complications?
> It looped around keeping track of
> the location in the string, and it had to remember the beginning and end
> of the string, and several other things.
It sounds like it has many properties in common with the typical
descriptions
of what is needed in C code to manipulate C style structures. I mean
that
in the sense that one can optimize the complications or eliminate the
complications. It is not the same thing.
> It was too much stack manipulation. Then I tried using something that was just
> like SOURCE and>IN and the complications went away. I started out not wanting
> to use any variables but it turned out that just a few helped a lot.
Of course. One of the first lessons in Forth is that some variables
are needed,
not everything should be on the stack. ;-)
> > > Well, but if you want to do part of the work in Forth and part in
> > > another language then you need them to communicate well.
>
> > Indeed the glue may be much larger and more complex than Forth
> > itself. You are likely to end up with either the biggest and
> > most complex Forth or the lowest performance Forth this way.
>
> But maybe most of the glue doesn't have to be on the Forth side. Then
> the Forth can be simple and still interact with other stuff.
Yes.
> The problem with doing it all in Forth is you have to do it all.
Yes. If 'it' is something that is easy to do with something else
why worry about doing 'it' in Forth?
If you say just for fun that's fine. But seriously, why worry about
doing 'it' in Forth?
I am one of those people who think that if you are not doing things
in Forth that you can't do with other languages why are you using
Forth?
> And if you want to tell somebody else how great it is
Is this the same 'it' as above, the thing that is atypical of
Forth but typical, simple, and easy for some other language?
> they'll say "Can you do this in Forth" and it will be something
> that takes you an hour and they'll laugh at you.
Sure I know. Who cares?
If they ask you if you can carry as much shit as easily in your
airplane or racecar as they can in their pickup truck and then
laugh when you say "No", so what? You can say you use your truck
to carry shit not your airplane or racecar and laugh.
I find it amusing that they trick you so easily into filling
your beautiful car with shit instead of just using a pickup truck.
> If you can get them doing some of their work in Forth and it's truly
> easier for them, then they'll want to do more of it that way, and the
> more of it they put on the Forth side of the interface the easier it
> gets for them. If they have to commit to doing everything for themselves
> in Forth before they start, they probably won't.
It seems like you are saying that you love Forth so much that you
want to push it on people even when it is not appropriate to the
problem they need to solve. You try elaborate methods to do
get them to use Forth in their Perl or Java classroom and in
the end give them the impression that Forth is useless.
I missed the explanation of the premise explaining why we are
trying to get people to do their non-Forth type work or non-Forth
homework in Forth? That seems like a disservice to them and to
Forth.
You seem to jump into the depth of that problem without thinking
about the bigger picture. Maybe if they need to solve problems
where Forth is a good fit they can be given exercises with
Forth problems solved with Forth. Maybe it would be better to
focus on showing people who Forth works to do Forth rather
than how hard it is to do your non-Forth homework in Forth,
not to mention what their instructor will say!
> > > Marcel Hendrix has proposed a
> > > reasonably simple set of Forth words that can do a whole lot of pipe
> > > stuff without having to consider the difference between Windows
> > > pipes and Unix pipes.
>
> > Reasonably small amount of glue to a C OS. Ok. But what is
> > reasonable to you or Wil or Marcel looks pretty big and complicated to
> > people who are used to Forth without the hundreds of megabytes of C
> > overhead that you are talking about.
>
> Sure, but if you need to deal with the C OS then it's real good if you
> can do so.
Sure. And I don't deny that you are lucky if you have the best
debugger, Forth, as the firmware below your C OS. And I don't deny
that a Forth in C with all the interfaces to the other C code might
help solve certain problems.
> I like the idea of rewriting Unix utilities in Forth. Get
> them smaller and not too much slower, with maybe a second simpler
> interface available too.
I doubt if smaller utilites gains much and doubt if they really
could be made significantly smaller anyway in that most details
are the same.
About the only value I see is that you like to look at Forth code.
But in a Unix system I would prefer the original in most cases
because it is likely more like everything else in that environment
and simpler in that sense.
> The more of that you can get done, the more of
> the system turns into Forth and allows you to simplify it further. But
> I'm afraid it would be a losing battle. Unix experts can add complexity
> faster than you can possibly remove it. Maybe in a special case. I've
> played with a Linux named DamnSmallLinux, where they promise to provide
> a functional system that's no more than 50 megabytes when it's stored.
People propose writing a Unix or Linux in Forth quite regularly. It
seems like it is based on many misunderstandings of Forth. Some
people have invested man years into the project with predictable
results. The reasons it is not a good idea get explained in c.l.f
a couple of times a year.
> So they have 50 megabytes of storage, and it can easily expand to 500
> megabytes in RAM, and they're continually squeezed for space. They
> replaced Cron with a perl script to save on size. I'm sure they'd be
> happy to replace pieces of it with Forth if somebody wrote the pieces
> for them.
If you think Forth script for Unix is what the world needs then go
for it. Prove that people can use scripts in Forth instead of
scripts in perl and then we will see if people do use Forth instead
of perl. If you are right then after that we can promote that
a something Forth can do. Or the people who talk about it could
just talk about wishing someone would do it instead of doing it
and publishing success stories.
> > > A number of Forths communicate well with C,
>
> > Mostly you are talking about C programs instead of Forth programs.
> > If you write a C program it is easy to get it to 'communicate well'
> > with other C programs. One C program talks to another, big deal.
> > It is a very different idea that Forth which says that Forth is
> > an alternative to all those hundreds of megabytes of C code that
> > is so incredibly complicated.
>
> Let's suppose that everything they want to do is already written in 500
> megabytes of C. The crass opportunist will say to just use the 500
> megabytes of C. But that's hard to maintain. So we get some real smart
> Forth people to rewrite it in Forth and because they're personally so
I love Forth. 'We just get some real smart Forth people to ... (do
something stupid which they will never do) so we can laugh about
the fact that we couldn't get them to do it.'
> good they can replace 500 megabytes of C with 500 kilobytes of Forth.
> Hurray! So how long does it take them to write those 500 kilobytes of
> working highly-functional Forth code?
I haven't see any 500 kilobyte Forth apps that were trivial or seen
anyone re-engineer 500 megabytes of C code and remove the bugs without
considerable effort.
Now one could compare the cost of the 500 megabytes of code, which
might
be multiple million dollar a year licenses with the cost of the
programmer
time needed to re-engineer a Forth solution. When both ways were done
in parallel it worked out to many millions of dollars either way. The
difference in cost was insignificant.
The difference in time was also insignificant. It took about the same
amount of time to reach solutions in either path. Bugs in both paths
reduced programmer efficiency to about the same until the bugs in the
re-engineered code could be corrected.
One big difference was in the quality as measured by speed, size,
cost, and yield as a result of removing limiting bugs in the Forth
path that remained in the other path.
How do you measure the value of that sort of thing. It seems to
lead to a lot of discoveries, new technology, new patents, new
computers and new code. There are many forms of value. One
is understanding. Another is money.
> Is this the best use of their time?
It depends on how much you value understanding and/or money.
It seems pretty hard to compare one person's subjective evaluation
of their own understanding to another person's internal subjective
evaluation of the value of their understanding. But it is real.
It is easier to evaluate the value of work based on what people
pay for it or what it earns.
> If they can do that, it might be better to have them do something
> that's really worthwhile that nobody's ever done before,
I don't get that. Worthwhile means it has been done before?
> and go ahead
> and pay some C programmers to maintain the 500 megabytes of C code.
Since you choose to talk about 500 megabyte C programs reengineered
into 500K or less of Forth code I chose to talk about the real thing.
People say they would like to see large scale projects where the
best Forth team's work can be compared to the best work of a more
mainstream non-Forth team and will all else being equal compare the
real costs and real results.
Some people would prefer to stick to completely made up examples
where they can speculate about what would happen if you spent many
millions on Forth and many millions on non-Forth side by side
over a period of years and then had a neutral third party evaluate
the results. It seems that there are those who do and those who
just speculate.
> Or get some average Ruby programmers to replace the 500
> megabytes of C with 50 megabytes of Ruby that's easier to
> maintain than the C was.
Sure. And what were the results when you tried it?
> > > but there isn't yet
> > > agreement about a standard syntax so the code doesn't port well
> > > among them.
>
> > And we can all hope that Forth standard will never be about C.
>
> Sure, but if you have a standard syntax to call C routines, what's wrong
> with that? You don't have to use it.
Well we could argue about countless different subjects. Let's just
say
that those who think the standard is overly complex with stuff that
gets
in the way feel that infinite further expansion in that direction will
mean more stuff to get in the way when you don't need it. That's what
is
wrong with that. But that needs a different thread.
> You don't have to put it in your
> Forth even if you want to call your Forth standard.
Never mind the it can be in the standard and not in the standard at
the
same time arguement. I'll bow out on that one.
> But people who have
> C routines can plug them into their Forths and use them without having
> to rewrite the whole thing in Forth. Why is that a bad thing?
I don't think that is a bad thing at all. I think it deserves a good
C-Forth standard. I just think we need a Forth standard that is not
the same as the C-Forth standard.
> I remember
> a long time ago listening to some CS students complain about COBOL.
> Various businesses thought they had a big investment in a bunch of
> legacy COBOL code, and the students thought that was completely wrong.
> The COBOL code wasn't an asset, it was entirely a liability. Throw it
> all out and rewrite the whole thing in C and they'd be better off. But
> those companies had a tremendous amount of domain knowledge stored in
> their COBOL programs, things they didn't have documentation for. Throw
> them away and it would take them a long time to write the specs to give
> to the C programmers.
I recall a friend who had to keep a legacy COBOL app running a few
years
after they laid off the 150 COBOL programmers who wrote it and lost
the
source code. I recall the group that Pacific Bell that took legacy
COBOL applications written by hundreds of programmers and re-
engineered
them into one page expert systems suitable for maintenance by the
technically unskilled project manager. In the other end of the
building was a group re-engineering forth-generation SQL/C relational
databases our group had done into COBOL programs by a much larger
less
productive but higher-paid COBOL group. ;-)
> Now you tell people who have C routines to throw them away and rewrite
> it all in Forth.
Who is this 'you?'
Who is it that is arguing that people need to throw away all their
C routines and rewrite them all in Forth?
Who are you argueing with here?
I have said if you can make a few million dollars by rewriting some
of your C code in Forth that you might consider doing it.
If you are telling people to throw away all their C and rewrite it
in Forth then you are nuts.
> But they might not be as good at Forth as you are, and
> they want to use the stuff that already works.
> If they have to throw everything they've ever done
> away and start over, they won't do it.
Even if *you* give people insane advice like that I hope
*they* will have the sense to know it is nuts and not do
it!
> > > Meanwhile, it might be useful to have more string stuff in Forth.
>
> > There is a lot of string stuff out there. What more would you want?
>
> The string wordset in the Forth-94 standard provides a few simple tools.
> Are there more tools that are so commonly useful they'd be useful in
> most systems that use strings much?
>
> Where would you suggest I start learning about the lot of string stuff
> that's out there?
Oh dear. There have been countless discussions in c.l.f. Check the
archives. Talk about it endlessly or actually do something.
> > > The
> > > problem has been that working with strings tends to be complicated
> > > and unnecessarily complicated.
> > > Lots of little detail stuff to keep track of.
> > > Do it yourself and it's complex.
>
> > No.
>
> Consider the matter of keeping track of a whole lot of strings.
I've done that.
> You can keep them in 1K blocks.
Sure. If you wand to do something pretty ugly. Maybe you
are trying to show inappropriate use of blocks.
> You can keep them in files.
Sure.
> You can keep them in
> memory, either at HERE or ALLOCATEd memory, or in CREATE structures or
> string literals in code or even just loose ALLOTed spaces. If you have...
Or in blocks in memory...
> If you have
> multiple strings you need to keep track of them. You'll want to release
> their memory when you no longer need them.
I have only had the need to release ALLOCATEed buffers for files
downloaded in the Forth browser. It seemed pretty atypical of Forth
programs but I thought we handled it a very clever way and implemented
the multitasker and memory and resource manager in the OS in a
good way and have written about it in c.l.f.
> So if you ALLOCATE them it's easy to, say, concatenate two strings. Just
> ask for a piece of memory big enough to hold them both, copy them both
> into it, and free the old spaces. Heap fragmentation? That's not your
> worry, the system can deal with it.
So you are saying that this is a heap issue not file or block issue.
> If they're in files then you can simply make a buffer big enough to hold
> them, copy them both to the buffer, and write the buffer to a file.
Same for blocks of course, except it is either much easier or
automatic.
> Or you can use a string stack package.
>
> Or you can use rubber-band memory. Copy strings at HERE and ALLOT the
> space. When your routine is done copy any strings you want to return, to
> the front of the space you alloted and then unallot the rest. Even if
> your routine has a memory leak the one that called yours will get rid of
> your trash when it flushes its own. I think this is one of the better
> ways, but I haven't met anyone who agreed with me. People have talked
> like they don't want to have to think about freeing up strings when
> they're done with them. It ought to be automatic.
>
> How do you do it?
Using methods I have never published.
> > > If the complicated string handling is something you're doing to
> > > make your work easier, maybe it would be easier not to do it. But
> > > when complicated string handling is the point in itself....
> >
> > I wonder just what sort of 'complicated string handling' you are
> > talking about. What sort of complicated string handling are you
> > imagining in Forth applications?
>
> Say you have a few hundred gigabytes of DNA data. It's strings of 2-bit
> characters, but sometimes you only care about whether it's purines or
> pyrimidines, so then you're only interested in the even bits. Sometimes
> you care about 6-bit characters, and then you might also care about the
> some but not all of the shifted data. You have a sequence to compare
> against and you're looking for similar sequences that aren't exactly the
> same.
That sounds like the string array comparison custom vlsi chip that
Chuck did for Dr. Ting many years ago when he was doing the DNA
robot work.
> The strings are sometimes stored in various compressed forms that
> reveal some of the sequence data you're interested in but which also
> conceal some of it.
Having to uncompress the data to manipulate it will add overhead. But
if the amount of data is so great that you have no choice ...
> Well, usual characters are 8-bit or bigger and so we can't use any of
> our usual string routines unless we waste space and use 2 bits per byte
> or perhaps 6 bits per byte. Taking 4 times as much space is not such a
> big deal when it's only hundreds of gigabytes, but when it's
> petabytes, as it will be soon.... It might make sense to build FPGAs
> that do special bitwise operations that traditional processors don't
> bother with....
Sure. You can take advantage of the parallelism in the problem
if you use an FPGA or a Programmable Forth Array.
> OK, a literary analyst is looking at esoteric subtleties in writing
> style. She wants to look for similarities in style among the various
> books of the bible that normally appear different, looking for
> particular passages in the different books that may have been edited by
> the same hand. It will involve lots of subtle string comparison.
>
> If the application is a string-handling application then that's what
> there is to do.
I don't get your point. Are you saying that you would be compelled
to try to convince them to do it in Forth instead of something else?
> On the other hand you can add prefixes to Forth strings like $1000 or
> Ox1000 or 'character or 'name or "this is my string" and make the Forth
> parser work a little harder, and maybe the convenience will be worth it.
I don't see how that is 'on the other hand' from the previous thought.
You can have an app involving many books or on the other hand
you can name a string in Forth because maybe it is worth it?
> > Best Wishes
>
> From your writing I tend to somehow doubt that.
I did intend the post only for your email. Sorry for it getting posted
to usenet where people don't know the history of emails.
I will answer any questions you have but don't intend to offer
answers to other people about what was to be your email.
If you prefer it can be email. I will read and note people's
opinions, though I probably already know what they are. ;-)
Best Wishes
BTW. If someone asks "How to make Forth interesting? answer
"Have an application suitable to Forth programming."
Jonah Thomas
> > That's fine. How long do you suppose it took William James to write
> > his 3-line Ruby program? I can imagine it might have taken him an
> > hour to write it and test it enough to be reasonably sure it had no
> > flaws. But maybe he's good at Ruby and he could write that 3-line
> > program in much less than an hour.
> >
> > How simple was your solution? Was it more than 3 lines?
>
> Mine was a page of code. It took me an hour or more to write. I
> never said it was easier or shorter than William James' code. I
> was just joking about incredibly simple it was compared to your
> explanation of what YOU were talking about doing! ;-)
OK.
> For lots of things specialized languages may have the easiest
> solutions, especially for most people because of their experience.
Yes.
> I was just joking about the insanely complicated way that you
> described the picture. If I wanted to do what you said I would
> just schedule a month to do it. If I had to learn another language
> and use something like William's solution I could probably do
> that faster than what you described.
So it would be slow for you to do it.
> BTW. I had thought I had sent you a private email. I guess I posted
> it, but I was mostly just joking about your sort of joking style of
> trying to offer the most complex explanations of things. ;-)
OK, I accept that.
> > I didn't take a close look at the java code, I just found it was
> > published.
>
> I had the impression from your description that you weren't just
> talking about JAVA and talking about Forth and Java. I had the
> impression that you were talking about calling JAVA from Forth etc.
No.
> > I suspected he could probably debug the same stuff faster in Forth
> > than in C. If so, that's one thing it gained him.
>
> You shouldn't say bad things about C, like it is buggier or harder to
> debug than Forth in c.l.f lest you upset the C defenders. Sure the
> lowest level of Forth is using it as debugger, it is a debugger that
> is useful. You can debug your buggy C programs with Forth, if your
> problem is C bugs that can't be avoided.
Yes.
> > > Other people must have also questioned the futility of not
> > > doing anything new, just repeating old C code again and
> > > making useless duplicates of existing C code.
> >
> > That's what I'm talking about too. You could translate a java or C
> > program into Forth to solve this sample exercise.
>
> I understand.
>
> The thing I was trying to emphasis is the nature of the sample
> exercise. Is it a good representation of a sample of Forth or not?
Of course it isn't. Forth doesn't easily do some classes of things that
people who like scripting languages want. The tools aren't there and
would have to be built from primitives, or found in Forth libraries.
> But back to the point. Should we care about how easy it is to
> do things in Forth that we would use some other languages to do?
>
> I don't see why. Are you arguing with someone who is claiming
> Forth should be used for all things even when some other specialized
> tool matches a job better? If so I would love to know who.
"I think it is simply a case that Chuck designed a language to
avoid the multi-language nightmare according to the first
paper on Forth."
"So Chuck likes to work from a few K of Forth. Other people
need to start with many megabytes of C based stuff and
then they need a bridge to all that from Forth. This
glue to C is often much larger and more complicated than
just plain Forth itself. But that's the game when you
switch from simple Forth to complicated Forth script for
C systems."
It sounds like you're saying to solve a problem, either do it all in
Forth, or else do it all using some specialised tool that does
everything to solve the problem. If Forth is particularly good to solve
part of the problem and something else is particularly good for another
part, either do it in a few K of Forth or in megabytes of the other
system but don't try to get them to work together.
> I think it makes more sense to evaluate Forth the problems where
> Forth is designed to be used.
Sometimes it's easier to extend Forth to a new problem domain than to
link it to other stuff that does a mediocre job of handling that problem
domain. Forth is nicely preadapted for some things, and not so much for
others.
> But my point of view is that Forth is probably not designed to do
> the homework that your Perl or JAVA programming instructor gave you.
Yes, same here.
> What I don't get is why people don't just tell the students when
> they ask about specialized language homework assignments that their
> homework problem does not come up where Forth is used or that if
> your Forth has these specialized tools it is just as easy to
> use as whatever.
Curiousity.
> I don't know what you have been doing. I know you said you had
> quit using Forth and had switched to Java some time ago. I don't
> know what problems you were solving then either only you do.
You have me confused with somebody else. Roedy Green, maybe? I think he
switched to java.
> > The problem with doing it all in Forth is you have to do it all.
>
> Yes. If 'it' is something that is easy to do with something else
> why worry about doing 'it' in Forth?
>
> If you say just for fun that's fine. But seriously, why worry about
> doing 'it' in Forth?
If a specialised task works a lot better with some new primitives added
to Forth, would those primitives be useful for other Forth tasks too?
Would some other primitives be more generally useful, and do those other
primitives give a clue for a better way to solve the original problem?
> I am one of those people who think that if you are not doing things
> in Forth that you can't do with other languages why are you using
> Forth?
Yes.
> I missed the explanation of the premise explaining why we are
> trying to get people to do their non-Forth type work or non-Forth
> homework in Forth? That seems like a disservice to them and to
> Forth.
It might be possible to do things somewhat similar to what they're
doing, much simpler than they're doing it. No harm done in taking a look
at what they want to do.
> People propose writing a Unix or Linux in Forth quite regularly. It
> seems like it is based on many misunderstandings of Forth. Some
> people have invested man years into the project with predictable
> results. The reasons it is not a good idea get explained in c.l.f
> a couple of times a year.
Yes.
> I haven't see any 500 kilobyte Forth apps that were trivial or seen
> anyone re-engineer 500 megabytes of C code and remove the bugs without
> considerable effort.
>
> Now one could compare the cost of the 500 megabytes of code, which
> might be multiple million dollar a year licenses with the cost of the
> programmer time needed to re-engineer a Forth solution. When both
> ways were done in parallel it worked out to many millions of dollars
> either way. The difference in cost was insignificant.
You have data? ?!
> The difference in time was also insignificant. It took about the same
> amount of time to reach solutions in either path. Bugs in both paths
> reduced programmer efficiency to about the same until the bugs in the
> re-engineered code could be corrected.
> One big difference was in the quality as measured by speed, size,
> cost, and yield as a result of removing limiting bugs in the Forth
> path that remained in the other path.
That sounds very important. Can you say when and where this was done?
> How do you measure the value of that sort of thing. It seems to
> lead to a lot of discoveries, new technology, new patents, new
> computers and new code. There are many forms of value. One
> is understanding. Another is money.
Yes, exactly.
> > Is this the best use of their time?
>
> It depends on how much you value understanding and/or money.
>
> It seems pretty hard to compare one person's subjective evaluation
> of their own understanding to another person's internal subjective
> evaluation of the value of their understanding. But it is real.
>
> It is easier to evaluate the value of work based on what people
> pay for it or what it earns.
>
> > If they can do that, it might be better to have them do something
> > that's really worthwhile that nobody's ever done before,
>
> I don't get that. Worthwhile means it has been done before?
I was making the opposite point, that there are lots of large marginally
functional projects and few teams of super-efficient forth programmers.
Rather than fix up a few run-of-the-mill large marginally functional
projects, they should be hired to do things that would otherwise be
difficult to get working at all.
> > and go ahead
> > and pay some C programmers to maintain the 500 megabytes of C code.
>
> Since you choose to talk about 500 megabyte C programs reengineered
> into 500K or less of Forth code I chose to talk about the real thing.
> People say they would like to see large scale projects where the
> best Forth team's work can be compared to the best work of a more
> mainstream non-Forth team and will all else being equal compare the
> real costs and real results.
Sure.
> Some people would prefer to stick to completely made up examples
> where they can speculate about what would happen if you spent many
> millions on Forth and many millions on non-Forth side by side
> over a period of years and then had a neutral third party evaluate
> the results. It seems that there are those who do and those who
> just speculate.
You've been involved in doing it? Can you tell us about it?
> > But people who have C routines can plug them into their Forths and
> > use them without having to rewrite the whole thing in Forth. Why is
> > that a bad thing?
>
> I don't think that is a bad thing at all. I think it deserves a good
> C-Forth standard. I just think we need a Forth standard that is not
> the same as the C-Forth standard.
You could write one....
> > Now you tell people who have C routines to throw them away and
> > rewrite it all in Forth.
>
> Who is this 'you?'
>
> Who is it that is arguing that people need to throw away all their
> C routines and rewrite them all in Forth?
>
> Who are you argueing with here?
You aren't telling them to do that. You appear to be telling them to
choose Forth or something else, and not to use Forth for the parts of
their application it's good for unless they want to use it for the whole
thing. Or maybe I'm extending your arguments beyond where you take them.
> > If the application is a string-handling application then that's what
> > there is to do.
>
> I don't get your point. Are you saying that you would be compelled
> to try to convince them to do it in Forth instead of something else?
No, I'm saying that sometimes the actual application is string
manipulation, and other times string manipulation might be one possible
approach to solving the real problem. In the latter case you might find
some better approach that avoids the string manipulation. In the former
case there's no getting around it. The more string manipulation you
build into your Forth compiler hoping to make it easier to use, the more
complication you have in your Forth compiler. But it might be easier to
use.
ken...@cix.compulink.co.uk
<c87131a5-db7f-4e34...@a23g2000vbl.googlegroups.com>,
f...@ultratechnology.com (Jeff Fox) wrote:
> he had never mentioned that it had an enviromental dependency
> on a few megabytes of Apple code doing everything for him.
Just about every program written for the Mac or Windows that uses a GUI
is environmentally dependent on OS common controls. The same applies to
programs for X Windows. The days of writing your own GUI interface went
out with Gem for desk tops. With XP and OSX it is impossible for a user
program to use the GUI without going through the OS. Under 95 and 98 a
program could take over the display but even a change in graphics
resolution resulted in a reboot when the program exited.
This means that something like Winforth has to be able to communicate
with Windows and call routines exposed by the OS. Off course this
applies to other languages which are being used to write programs for
Windows or the Mac. That by the way is why all Windows games now use
Direct X.
Ken Young
Jeff Fox
> In article
> <c87131a5-db7f-4e34-8346-8795da86f...@a23g2000vbl.googlegroups.com>,
>
> f...@ultratechnology.com (Jeff Fox) wrote:
> > he had never mentioned that it had an enviromental dependency
> > on a few megabytes of Apple code doing everything for him.
>
> Just about every program written for the Mac or Windows that uses a GUI
> is environmentally dependent on OS common controls. The same applies to
> programs for X Windows. The days of writing your own GUI interface went
> out with Gem for desk tops. With XP and OSX it is impossible for a user
> program to use the GUI without going through the OS. Under 95 and 98 a
> program could take over the display but even a change in graphics
> resolution resulted in a reboot when the program exited.
All true.
The context of my comment was in response to Wil's that in his early
Forth his code was not portable. He complained that Marcel has his
own "private" language because Marcel used things in iForth that were
not specified in the ANS layer. Wil argued that he had learned and
now wrote only portable Forth.
I wrongly assumed that that meant that his code was portable ANS
code only. When I looked into the details I saw that it should have
had included environmental dependencies stating that it was entirely
dependent on the Mac system. I assumed wrongly that he meant that
his code was Mac only code. I thought it should have at least
have to have an environmental dependency stating so.
Because Wil berated other people for using system specific code
layers instead of only sticking to only ANS I assumed when he said
that his code was only ANS not that it was entirely dependent on
Mac and would require low level porting to anything other than Mac.
> This means that something like Winforth has to be able to communicate
> with Windows and call routines exposed by the OS. Off course this
> applies to other languages which are being used to write programs for
> Windows or the Mac. That by the way is why all Windows games now use
> Direct X.
The fact that GUI has two meanings often leads to confusion. There
is GUI code in the OS and GUI code in applications that calls the
GUI code in the OS. Sometimes I make comparisons between the OS
layers in different systems and the application layers in different
systems. People usually take those as comparisons between the
OS GUI code in one system with the application GUI code in another
system.
I am well aware that a Winforth has to be able to communicate with
Windows. I did write the OS GUI layer for some Forth projects too.
;-)
Where I get into trouble is when I talk about Forth GUI and
say that one can do this or that in two or three K of code.
Of course I mean that the OS GUI code and the application GUI
code combined was factored into three K.
But other people often say, "So what, I only used ten K for the
application GUI code in my app. That's not much more than 3k."
My response is "Sure but your 10K of GUI application code is
really calling 10M of OS GUI code. What I was saying was not
that 3K of code is a lot simpler than 10K of code, I was saying
that 3K of code is a lot simpler than 1010K of code.
I had assumed wrongly that Wil was doing a lot more with his
ANS Forth than he was. I had wrongly interpreted what he had
said to mean that he had implemented some of the interesting
parts of the GUI interface and wanted to see what he had done.
Its great to call the Mac ROM but it only works on Macs.
It just came down to portable meaning less to Wil than I
had thought he had meant. That was my point.
Best Wishes
Jeff Fox
> It sounds like you're saying to solve a problem, either do it all in
> Forth, or else do it all using some specialised tool that does
> everything to solve the problem.
There is some truth there. Either you solve (all) your problem or
you don't. Once you identify your problem you either solve it with
Forth or with something else, or you don't solve it.
Now it is the identification of the problem part of the Forth
approach where one questions things outside the context of the
small picture left-brain procedure and language syntax thinking
and has to step back an use the right-brain big picture thinking.
Let me give an example.
Someone will say, "We have identified our problem. In this system
at this point the output of this program is fed to the input
of that program and we must massage the output of this to
match the input needs of that. It is a string problem."
Once the problem is identified then an appropriate method
is selected and the appropriate procedures are followed in
this case to construct a program to massage the output of
the first program to meet the input needs of the other program.
Problem solved. We move on to our next assignment.
What I have described are methods used by beginner
application or support programmers. Had the project been
assigned to a more senior systems analyst they would
likely have looked at a bigger picture and wondered
what the first program was doing and what the second
program were doing to create the small picture problem
that the output of the first program had to be massaged
to match the input of the second program. That would be
step one.
I have certainly had experiences like that where I then
reported to management that the history of this project
led to the second program virtually canceling out the
actions of the first program. I would tell them, "You
can pay for X hours of work to get a third program to
massage the data and solve the problem I was asked to
investigate. But then you will have three programs to
maintain etc."
"Another option is that in X/10 I can write a program
which does exactly the same things as running the
first program, massaging its output with a third
program, and feeding it to the old second program
to do what it did. This program will be one tenth
the size of the massage program and one one hundredth
the size of all three programs combined. There will one
hundred time less code to maintain and the system
will perform better and the work will cost one
tenth as much." (ie. the real problem is not
really a string problem at all!)
Management might say, "OK, do that." Problem solved.
This is the sort of thing that more senior system
analysts do in a large company. They get paid to
look at the bigger picture than a beginning level
application maintenance programmer who is told to
write the massage program, don't waste your
time looking at other things, and don't talk back.
Forth doesn't distinguish between systems programmer,
compiler writer, systems analyst, senior systems
consultant, application designer, application
maintenance programmer, or script kiddie. It lets
one person assume all roles if that fits.
The idea that in complex systems written by
thousands of programmers that there are lots of
opportunities to identify problems that can be
solved by being avoided in the first place rather
than by having another programmer add yet another
buggy program to the mix.
Senior systems consultants who get hired by the
big companies to deal with the most complex and
challenging problems were once beginners and
understand how application maintenance programmers
think. But script kiddies and application
maintenance programmers are mystified by how
a senior person is able to come up with solutions
that are hundreds, thousands, or millions of times
more productive or more valuable to a company
than the work the script kiddies are paid to do.
Some may eventually work their way up to being
able to understand.
One thing is simple: Once you identify your problem
you either solve it with Forth or with something
else or you don't solve it.
Sometimes the best solution requires more than the
narrow focus on only one part of the problem that
many languages provide. Narrow lets less skilled
programmers contribute and it helps coordinate the
work of differnt teams. But it is also what leads
to the accumulation of hidden bugs and counter
productive code over time which can only be
seen from a bigger system level view.
> If Forth is particularly good to solve
> part of the problem and something else is particularly good for another
> part, either do it in a few K of Forth or in megabytes of the other
> system but don't try to get them to work together.
I don't follow that. That's your advice to people?
> > What I don't get is why people don't just tell the students when
> > they ask about specialized language homework assignments that their
> > homework problem does not come up where Forth is used or that if
> > your Forth has these specialized tools it is just as easy to
> > use as whatever.
>
> Curiousity.
I don't get that. "Curiousity" is why people don't tell the
students the correct simple answer? "Curriosity" is the reason
to tell them to do their Perl homework in Forth instead of Perl?
> If a specialised task works a lot better with some new primitives added
> to Forth, would those primitives be useful for other Forth tasks too?
Good question. But now you are outside the task of solving that
problem
what was at hand. You have moved on to future problems that you
suspect
you will want to solve later. Nothing wrong with that unless you
haven't solved the problem at hand yet.
> Would some other primitives be more generally useful, and do those other
> primitives give a clue for a better way to solve the original problem?
Who knows? Those are the kinds of question you ask after you have
come up with your own library of solutions and can compare them to
other people's library of solutions. In Forth we prefer to solve the
real problems at hand first rather than worry about what might or
might not be generally useful. That's something you work on after
each project is done and you have different solutions to compare.
> > I missed the explanation of the premise explaining why we are
> > trying to get people to do their non-Forth type work or non-Forth
> > homework in Forth? That seems like a disservice to them and to
> > Forth.
>
> It might be possible to do things somewhat similar to what they're
> doing, much simpler than they're doing it. No harm done in taking a look
> at what they want to do.
I might disagree. Learning is in stages. You have a beginner who
has been given a problem in a particular context by their instructor
because it is at the level to which they have progressed. We could
indeed do them harm by telling them that at this stage they need to
be thinking like a senior systems consultant and looking into
rewriting the compiler in a different language when their instruction
just wanted them to first learn to massage a string. We should
not tell them to 'avoid' doing their homework, they won't understand
or benefit.
When students ask you about doing their perl homework in Forth
better to tell them don't.
> You have data? ?!
I don't have exact numbers for some things. I know how many people,
backgrounds, range of salaries, cost of tools, time to delivery, and
the details of the results of the work in measurable things like
density, cost, speed, power consumption and production yield.
I joked with Chuck about it a few months ago. I said it was
funny that not just people in c.l.f but that many people were
skeptical about Chuck's claims about Forth. Some call for
large expensive double blind scientific comparisons before
they can make up their minds. And some are willing to pay
out the many millions of dollars needed to make such things
happen. For others it is a way to remain pseudo-skeptical
because they know they will never pay for such a study and
have already made up their minds anyway and don't want to
see results from any real experiments.
> That sounds very important. Can you say when and where this was done?
iTV investors were skeptical of Chuck's claims and paid for top
people to compete against Chuck's effort to prove whether Chuck's
claims were right or wrong. It was an experiment with only a
few people and a few million dollars and only for a couple of
years.
All they proved was that the expensive tools were wrong about
Chuck's circuits being impossible, Chuck's circuits worked as
his tools predicted. The claims about superior performance
of the standard tools were not true since it took more time
and money for them to say that Chuck's working chips were
impossible than it was for Chuck make them and to show
that they worked.
Years later IntellaSys made a more serious effort to evaluate
Chuck's claims about his Forth tools. Productivity and cost
and quality of output were tested against more conventional tools
and methods. Instead of being a test with a couple of people
for a couple of years like at iTV this was on a much larger
scale. I was rather intimidated by some of the top design
engineers hired away from Intel who had designed Pentium
or other mainstream chips or worked on state of the art
classified design projects for top defense contractors and
a few lower level people. The Forth team was similarly
staffed with some very experienced people and some people
just out of school.
After a few years both teams had been able to make new chips
to certain specifications, the team's performance and the
product performance was then evaluated and compared side by
side. Management didn't care whether Forth or something else
did a better job, they were neutral. They just wanted the
most productive work and the best product performance and
were able to make objective comparisons based on real numbers
after the best experiments could be made to test each
individual claim objectively.
I don't know if Chuck liked being challenged again and again
to prove what he said. I think he did enjoy being proven right
again and again. At some point you have to decide what direction
to take and stop doing reasearch that splits the funding on two
competing projects with the same goal if you want to get things
done on a budget.
> > I don't get that. Worthwhile means it has been done before?
>
> I was making the opposite point, that there are lots of large marginally
> functional projects and few teams of super-efficient forth programmers.
> Rather than fix up a few run-of-the-mill large marginally functional
> projects, they should be hired to do things that would otherwise be
> difficult to get working at all.
I just didn't read very clearly what you had written. I saw what you
meant later and got it. I was working a bit below par yesterday.
> > > Now you tell people who have C routines to throw them away and
> > > rewrite it all in Forth.
>
> > Who is this 'you?'
>
> You aren't telling them to do that. You appear to be telling them to
> choose Forth or something else,
That's true.
> and not to use Forth for the parts of
> their application it's good for unless they want to
> use it for the whole thing.
Nonsense. I have never said anything like that.
What I said was that the more parts of the their application
that can be improved by using Forth the more valuable Forth
will be. It you use Forth more it will be of more value.
When people say that they use Forth for only a percent of
a percent of a percent of their application because that's
all it is good for I question whether they understand
Forth very well. Their response is that I said it has to
be 0% or 100% because they have no argument against what
I really said.
> Or maybe I'm extending your arguments beyond where you take them.
I can see how you take my statement that there is a continuum
from 0.00001% Forth to 100% Forth and you get as much out of Forth
as you put in as statements that it is always a black and white
case of either 0.0% Forth or 100% Forth. ;-)
> > > If the application is a string-handling application then that's what
> > > there is to do.
>
> > I don't get your point. Are you saying that you would be compelled
> > to try to convince them to do it in Forth instead of something else?
>
> No, I'm saying that sometimes the actual application is string
> manipulation, and other times string manipulation might be one possible
> approach to solving the real problem.
In the example I detailed earlier one could code the program that
massages the output of program one in Forth or in Java or in Perl or
in C or whatever. Maybe it would ten time easier to code it Perl
than in Forth. Maybe it would be ten times easier than that to
replace all three programs with a Forth program and avoid doing
the string manipulation that the maintenance programmer did not
know how to avoid.
> In the latter case you might find some better approach that avoids
> the string manipulation.
Like in the example I gave. Indeed. When we simply say that we
avoid certain problems newbies often think it means we just don't
solve the problem. Learning to avoid is a more advanced skill
than what beginners learn first. Many people never learn it.
> In the former case there's no getting around it.
So you decide which language makes massaging the strings easiest.
> The more string manipulation you
> build into your Forth compiler hoping to make it easier to use, the more
> complication you have in your Forth compiler. But it might be easier to
> use.
It might be easier to use for string manipulation. If it really
important
it goes in at a low level. But then it might get in the way of
everything
except string manipulation. If it is not the most important thing in
the language there are lower frequency of use options to keep it out
of the way when you don't need it. Things like compiler extensions or
libraries are there to keep things that make things easier "sometimes"
available at the times when you need them. I believe we agree here.
The issue it seems is that I think that when beginners ask about their
non-Forth homework that it doesn't help them or Forth to try to sell
them Forth at that time. It will harm them to advise them bypass
learning to program and jump right to the job of systems analyst.
We should not be concerned if they laugh about Forth not being
suitable for their homework at this time in their learning curve.
Best Wishes
John Passaniti
> I think it is simply a case that Chuck designed a language to
> avoid the multi-language nightmare according to the first
> paper on Forth.
<metaphor type="extended">
Hello comp.lang.forth!
Every now and then, you'll see someone post a message in this newsgroup
in German or French or in another crazy language other than English. So
to eliminate the multi-language nightmare, I hereby declare that all
future messages in this newsgroup will be in English. At last, our
nightmare has ended!
I would also like to say to everyone that they should flipple their
wooznots as soon as possible. Anyone not flippling their wooznots will
certainly have to teeple twice as fast!
Huh? You didn't understand me? I don't know how that could be-- we've
solved the multi-language nightmare here in comp.lang.forth by
standardizing on one language: English.
Oh, I see the problem! In the version of English that you understand,
you don't have the words flipple, wooznots and teeple. They must look
like nonsense to you! I added those words to my version of English as
part of my work because they more succinctly express what they are. And
they are great words-- by defining a handful of these words in my
private version of English, I can communicate with myself far more
efficiently.
Now as everyone starts writing messages in their own private version of
English, communications will get harder. But since it's all based on
English, that's no problem! All we have to do before communicating with
each other is to provide a dictionary of our words, preferably at the
top of every message. It's all defined in terms of English, so it's
completely understandable! Having a single language is great! It solves
so many problems!
I should also mention that I have a bunch of different words in my
private version of English for different contexts. Here in
comp.lang.forth talking about wooznots means one thing, but when I'm
talking to my partner, wooznots are something very different. But
that's the great thing about defining language, you can pick the perfect
words for that language.
See, by each of us defining the perfect language for the contexts we
communicate in, we eliminate the multi-language nightmare! See, before
if someone wrote a message in German or French, I couldn't understand
it. But now... well, I just grankle the floom.
</metaphor>
Jeff Fox
> that 3K of code is a lot simpler than 1010K of code.
Oops. That should have been 10010K or more of code. X windows
isn't just 1M! Those pesky zeros!
Best
Jacko
wooznuts : Things which was nuts before doing somg flippling.
flipple : To exchange things into logical order, instead of order of
occurance.
teeple : To reduce the tea pile (sometimes called inbox), which must
be solved by end of project.
Anywhere close??
cheers jacko
John Passaniti
> wooznuts : Things which was nuts before doing somg flippling.
> flipple : To exchange things into logical order, instead of order of
> occurance.
> teeple : To reduce the tea pile (sometimes called inbox), which must
> be solved by end of project.
>
> Anywhere close??
Yes, your definitions are very vooplarian in their traquitude.
Jacko
Pointing out who's nots was nuts is a little more "who player in",
sarc. ... tranquitude is such a magnanamous chillamologism, fluff on
ney spikey man.
cheers jacko
Jacko
of "injection control computer in engines" GPS for tracking, but no
update of goverment "wanted" efficiency algorithm (ignored by
environmental health) as reduces tax on speeders etc.
How's your system tic inteface? Or you on the polo green?
cheers jacko
Jonah Thomas
> Jonah Thomas <jethom...@gmail.com> wrote:
> > If Forth is particularly good to solve
> > part of the problem and something else is particularly good for
> > another part, either do it in a few K of Forth or in megabytes of
> > the other system but don't try to get them to work together.
>
> I don't follow that. That's your advice to people?
No, I'm trying to get a sense of what you advise.
"I think it is simply a case that Chuck designed a language to
avoid the multi-language nightmare according to the first
paper on Forth. And that's a very different idea than
adapting the language to a multi-language environment. I
like to say it is the difference between Forth and Forth
script for some other non-Forth system."
>> Well, but if you want to do part of the work in Forth and part in
>> another language then you need them to communicate well.
"Indeed the glue may be much larger and more complex than Forth
itself. You are likely to end up with either the biggest and
most complex Forth or the lowest performance Forth this way."
"Thankfully Forth is a thousand times simpler when you have Forth
that isn't 99% about C systems."
""Curriosity" is the reason to tell them to do their Perl homework in
Forth instead of Perl?"
You appear to advise that people do it all in Forth. Or if some language
is a real good fit to the problem, do it in that language. But to solve
a problem partly with Forth and partly with something else your Forth
winds up being complex or low-performance, it's 99% about C, etc. You'd
wind up adapting Forth for a multi-language environment.
You talk about adapting Forth for a multi-language environment like it's
a bad thing. So I wound up thinking that you wouldn't advise people to
do that. And that leaves them not using Forth to solve part of the
problem and something else for another part of the problem.
Can you see how I might think that's what you intended? But it turns out
you're fine with Forths that put 99% of their complexity into
communicating with other languages, so that people can use them to solve
part of a problem with Forth and another part with another language. I
just hadn't noticed you say anything about that before.
> > You have data? ?!
> > That sounds very important. Can you say when and where this was
> > done?
>
> iTV investors were skeptical of Chuck's claims and paid for top
> people to compete against Chuck's effort to prove whether Chuck's
> claims were right or wrong. It was an experiment with only a
> few people and a few million dollars and only for a couple of
> years.
>
> All they proved was that the expensive tools were wrong about
> Chuck's circuits being impossible, Chuck's circuits worked as
> his tools predicted. The claims about superior performance
> of the standard tools were not true since it took more time
> and money for them to say that Chuck's working chips were
> impossible than it was for Chuck make them and to show
> that they worked.
That's good for Chuck's chip-design program against the standard tools
of that day. It doesn't say much about Forth.
> Years later IntellaSys made a more serious effort to evaluate
> Chuck's claims about his Forth tools. Productivity and cost
> and quality of output were tested against more conventional tools
> and methods. Instead of being a test with a couple of people
> for a couple of years like at iTV this was on a much larger
> scale. I was rather intimidated by some of the top design
> engineers hired away from Intel who had designed Pentium
> or other mainstream chips or worked on state of the art
> classified design projects for top defense contractors and
> a few lower level people. The Forth team was similarly
> staffed with some very experienced people and some people
> just out of school.
>
> After a few years both teams had been able to make new chips
> to certain specifications, the team's performance and the
> product performance was then evaluated and compared side by
> side. Management didn't care whether Forth or something else
> did a better job, they were neutral. They just wanted the
> most productive work and the best product performance and
> were able to make objective comparisons based on real numbers
> after the best experiments could be made to test each
> individual claim objectively.
Great! Any chance that IntellaSys might let somebody look over some
fraction of their data and publish the relevant results? It might be too
big a project for Noah Ryman's master's thesis, but maybe not.
> I don't know if Chuck liked being challenged again and again
> to prove what he said. I think he did enjoy being proven right
> again and again. At some point you have to decide what direction
> to take and stop doing reasearch that splits the funding on two
> competing projects with the same goal if you want to get things
> done on a budget.
There are tricks to fooling people into thinking you know what you're
talking about. It might be worth it to Chuck to think about that. For
that matter it might be worth it to me too; I've tended to think it was
immoral and ignore the topic apart from noticing a little bit about how
it works.
Like, there was a renaissance artist who got asked for some sample art
to help the church decide which artist would get the contract. He made a
show of being insulted that they'd ask that of him, and then in front of
the messenger who carried the message, he drew a perfect circle freehand
and sent that back as his sample. Drawing a circle freehand had nothing
to do with the sort of art he'd be doing, but they were still impressed
enough by the story that he won the competition.
Richard Feynman wrote about a man who claimed to understand human
beings, who taught him how to pick up women in bars. The man said that
since he understood people he knew that Feynman wouldn't believe him
unless he first showed Feynman he knew what he was talking about. So he
said he would use his knowledge of people to get some random guy to buy
Feynman a drink. When it worked, Feynman was ready to believe the man
was an expert.
I used to think it was wrong to use silly tricks to fool people that
way. But maybe what's wrong is to fool people into believing you're an
expert when you aren't. If they're ready to believe silly tricks and not
ready to believe real evidence, why not use the methods that work?
Which reminds me:
http://www.sideshowworld.com/tgodvenicebeach.html
http://www.sideshowworld.com/tgodvenicebeachrent.html
Here's a street performer at Venice Beach. He's technically better than
any other performer. But nobody pays any attention to him. He has to
learn techniques to get tourists to notice him -- until he learns
methods to attract a crowd nobody will even stop to watch. And one of
the big things is that people don't want to stop to watch unless there's
already a crowd of others who've stopped to watch. A few buskers got
most of the attention.
"That night as I lay on the lumpy bed watching the spiders weave in the
corner, I figured out a fundamental rule of performing: Being able to
market what you do is more important than what you actually do."
But after he found out how to collect a crowd, they still just watched
and didn't give him money. He had to spend even more effort figuring out
how to get them to pay.
There's surely a lesson here even for someone whose profession doesn't
involve pounding screwdrivers up his nose.
Jacko
> involve pounding screwdrivers up his nose.
What lees on? Tell us teach, or does that involve payment? Just how
restricted does knowledge have to become to have any worth? And is
that worth due to the fear of those without it?
cheers jacko
drj113
I admit to having sat on the sidelines since the late 80's.
Some of my history -- My first real job was as a Trainee Technical
Officer at the Research School of Physical Sciences at the Australian
National University here in Australia. We were a *real* engineering
department - tasked with building the equipment that the reasearchers
couldn't buy. We used CP/M extensively when 8" disks were king... I
rolled my own FigForth implementation on a Z80 based STD BUS card we
built at work (That was hours of typing, and some quality debugging
with a Z80 pod.) I wire wrapped a video card for a PDP-11. I even
got to play with a Novix NC4016 machine at work that one of the vision
researchers had. (Wow, that used EXPENSIVE memory).
I also built a little Rockwell Forth system that uses a 65F11 and a
floppy disk. My final engineering project at Tech used a 65F12. -
That was fun - I got to appreciate the true speed of Forth by ignoring
my project for 16 of the 18 weeks, then I got to work REAL FAST!!!!
(Scored an A+ by the way!!)
So - 20 years on - I have the manuals and software for the LMI Z80
Cross Compiler, as well as the Manuals and Software (I think?) for SFP
Forth. Why? Because somebody at the ANU - 20 years later - remembered
that I loved Forth, and they gave them to me instead of throwing them
in the dumpster. As an adult, who has discovered the benefits of
reading, I have even discovered that I could have used the Cross
Compiler to build the Z80 Forth for that STD card in about 30
minutes..... Gosh - growing up was useful..
Why an I writing this? Well, as a Trainee, the embedded stuff we
built really showed me that Forth was the way of the future. I left
that employer, and eventually landed a series of software jobs, where
I discovered, quite painfully, that professional programmers do not
use Forth. You do not speak of Forth - You don't even joke about
using Forth... You may only use the word Forth to scare the daylights
out of your co-workers. That is madness - especially when you look at
the readability of C or Perl!!! In the jobs of the last 15 years, the
tools of the pre-built systems I maintained have been C, C++, Perl,
and (sadly) Java...
But, try as I could, I could never get any traction for writing large
scale image processing, or database systems in Forth. That would have
been nice. Linux has only recently (8 or so years) obtained
mainstream recognition. And even then in a massive group, they refer
to it as Freeeeee ware, as though it has a disease or something.
Being an avid *nix developer and system administrator using commercial
*nix's (AIX, HP/UX), as well as free ones, (386BSD, FreeBSD, Linux,
etc) for many years, I am frightened by the morons who believe that
you have to pay thousamds of dollars for something to be usefull.
The languages that the programming departments used for new systems
have been C, C++, Perl, and Java - Because they had skills in them.
And that is what it boils down to. If you employ a bunch of cabinet
makers, you shold probably be making furniture.. If you employ a
bunch of C programmers, you should probably be developing systems in
C. If you employ a bunch of Forth programmers, you write Forth code..
I suspect Forth probably never left the embedded systems world. As an
embedded systems tool, it ROCKS - I have just discovered FlashForth
for the PIC 18 series Microcontrollers, and am just about to etch a
couple of prototype cards for playing with it. I even have a job to
do in the next couple of weeks in replacing our commercial sprinkler
controller with a home made one that understands the odds-evens system
that we have imposed on us by the local council to comply with our
water restrictions.
I believe that the ANSI process has been both a Godsend, as well as
extremely destructive. The Forths I see today are not small things
you can get your head around in a couple of days, they are massive - I
suspect that we have lost something. That may have even started in
the 80's when F83 came on 4 floppy disks...
But - Anyway - Hi to the group - It is reassuring to be here. But I
do agree with other posters when I say that there are a lot of dead
forth links out there.......
Lets keep it alive. It is fun!!! It is supposed to be fun!!!
In the meantime, lets not re-write the Linux kernel on forth. That
would be bad!
:-)
Doug Jackson
DavidM
> In the meantime, lets not re-write the Linux kernel on forth. That
> would be bad!
There is a movement of forthers out there who have kinda done just that -
written an x86-based OS, drivers, apps etc entirely in Forth.
Jacko
When it runs WINE style application the migration may be viable for
many, Even if a x86 virtual machine is used for porting to other
chips.
Is there a binary where dictionary entries for the primitives can be
added for any processor? (at the end of the dictionary?)
init mode 4 seems free....
cheers jacko
Jonah Thomas
Did you read it? I thought some of it would be obvious, and for some of
it, maybe you learn what you need from the story more than you'd get
from somebody else's interpretation.
But I saw four big steps. This guy went to Venice Beach assuming that
what he did was so superior that he'd automatically make money.
He assumed that the way to get a good spot on the beach was to get there
early and pick your spot and stay there. But it turned out there was a
social structure that he had to fit into. People paid an old women to
reserve them spots and while she had no legal right to do it, he
couldn't ignore the system. He paid $10/day. Assuming everybody paid
that (which is not a good assumption, she had no legal obligation to
charge equally) she was making a lot more money than any of the
performers. Thirty two of them? $320/day. Fifty? $500/day. Three
hundred?$3000/day. Nice work if you can get it.
He found out how to satisfy the customs among his competitors, well
enough to get by. But then he couldn't get any attention from customers.
He couldn't understand it. His act was far better than any of the
others. He stuck his face in broken glass and let somebody stand on his
head. He hammered a 5" screwdriver into his nose. He lay on a bed of
nails and let somebody jump on his stomach. A quality act, the best one
there, but the tourists acted like they were grossed out, they didn't
recognise the quality. Forth programmers might recognise that feeling.
So he learned tricks to get attention. The tricks to get attention from
potential customers are probably different for software, but whatever
they are, you have to learn them if you hope to avoid being completely
ignored.
"Being able to market what you do is more important than what you
actually do."
He was able to learn how to do that just by watching the other
performers and thinking carefully. "As I peered through the throng, I
was amazed. He wasn't doing anything. Except sweeping. Perry was
sweeping off his area with a broom with such energy, giving you the
feeling that something incredible was going to happen any minute. An
anticipation crept through the crowd, why is he a sweeping fiend, what
is he going to do? All the while the Ambassador of Limbo didn't so much
as look up, letting them be sucked into the mystery without
explanation."
"Don't look. Eye contact intimidates passersby, they feel too intimate,
and walk away; so don't look. At least until you have thirty or more
gathered around, wondering what the hell you're doing and why you're not
looking at them. Take time setting stuff up. Appear very busy and
worried, like something huge is going to happen that's potentially very
dangerous. That's what I'd been doing wrong: I'd been eyeing the crowd
like a hawk, and by the end of my unwatched act it was with that
pitiful, pleading look in my eye that inaudibly conveyed, "Don't go,
please don't go, stay."
If you wait for spectators who appreciate technical excellence, you're
likely to have a small, elite audience. Emphasis on small. People feel
uncomfortable taking risks on things nobody else is trying.... So it's
important to entertain people, and the entertainment that gets them to
pay attention to you in the first place is likely to have little to do
with the work you actually do. I've seen Stephen Pelc hold an audience
spellbound with stories about his customers who did fireworks, or the
ones who disabled minefields. Elizabeth Rather did as well with the
Saudi airport etc. I don't know what stories potential customers like to
hear, but if storytelling has any part in it I'm sure they both do well.
So he learned how to gather a crowd, and then he hit the next barrier.
"There I was doing the most spectacular things on Venice Beach, but then
the crowd would start jeering me, challenging me, heckling me. And they
would walk away right when I was asking for the money. I didn't know how
to react. It was pathetic. Oh, God, it was pathetic."
That rings a bell, doesn't it? Here you are, doing fantastic things with
Forth, and you try to tell people about it and they bully you. They say
it isn't possible, you're a liar, you couldn't get that result. Also
anybody could do it just as well using RPG or whatever their favorite
language is, haha look at the stupid Forth programmer who thinks his
Forth program will execute faster than assembly code.
People look for a show, and some of them are trolls. Some of them enjoy
the show the trolls put on. "At night while my neighbors were groaning
next door, I paced the room thinking of lines to pull them in and
comebacks to shut them up." The audience was just as happy to see him
outtroll the trolls as it was to watch them harass him. It wasn't
rational, it wasn't debate, it wasn't civilised, it was just
entertainment.
"By the end of the weekend I could talk my way through a show and have
enough control to keep spectators throughout. But I still didn't have
enough influence to get them to drop much in that cap." The fourth
barrier. Actually making sales. "Hunger and anger, I found, are the two
great motivators. And I was feeling both."
"Just like on a typical car lot there were only one or two guys making
all the money, and the other thirty lived hand-to-mouth. There's no in
between: you're either real good at it, or ought to get another job."
"I noticed that of all the performers, only three were good at
collecting money, And I studied their techniques they used to get bills
out of pockets and into their hats."
"Their secret: They turned collection into such a comical event, it was
a show unto itself. They had different ways to entice their audience
into paying, and they all had a gimmick."
"They all collected their dough right before the final stunt, which was
pitched as though everything seen before was nothing compared to what
was about to happen. That was enough of a lure to keep the chicken legs
planted, continuing to take the abuse."
"And the formula was so heavy handed that most people paid; the crowd
enjoyed watching the stingy ones be abused, squirted, batted, and
humiliated"
"I kept studying the gimmick guys, and perfecting my crowd-control
abilities. By early August I'd figured it out. The last week's totals
were more than a grand."
The fourth barrier overcome!
"But you know, I wasn't enjoying it. All the hoopla and persuasion, all
the crowd control techniques that wasn't why I was an entertainer. It
was starting to feel like car sales."
Just like somebody who wanted to do Forth and found himself doing mostly
marketing instead, he didn't enjoy success that much. He cared about his
art, and his art was not actually very important for the performance.
And yet some ways it feels better to make money and be dissatisfied,
than to not make money and be even more dissatisfied....
Jacko
is not an asset just a material investment consuptive. Knowing that
'Credit' was out, this paradox naturally resolved itself in hobby.
Marketting : Definition 2 : Do accounting.
Audiance : Definition 1 : Market of prospective or covered customers.
To entertain the occupied spacetime continuum with a flux of punter
cover lux environment.
Audiance : Definition 2 : Do talking to.
Only the mint makes money. What you actually mean is have access to
money. Or to do money. Sarc...
Just as an aside: I don't for clarity fell supirior, I think the
design lacks limt in a way that few chips about do. What for me is an
unpaid hobby, not a reason to make money. Some money would be nice,
says all but the zen. Some of you folks probably had bigger order
books a while back, as yet I have not charged anyone for production,
and the ever growing pile of unsoldered non hot socket needs an end
before a start. Low single core potential with definate base
instruction set. Not far maybe but closer than a use-able end. Sarc.
When does a product start a division begin and an outcome happen?
cheers jacko
Jacko
power swap top pinless jobo's??
j
Jacko
be hell to pay.
Andrew Haley
> I believe that the ANSI process has been both a Godsend, as well as
> extremely destructive. The Forths I see today are not small things
> you can get your head around in a couple of days, they are massive - I
> suspect that we have lost something. That may have even started in
> the 80's when F83 came on 4 floppy disks...
That's right. I think you're committing the famous "Post hoc, ergo
propter hoc" fallacy. the one that states "Since that event followed
this one, that event must have been caused by this one." (Thanks
Wikipedia!)
My guess; There's nothing massive about ANS Forth, it's just that
the implementers either got carried away or had never done a Forth
implementation before. The latter (no names) sometimes used
"traditional" techniques (compilers, linkers, etc) to implement Forth
rather than writing Forth in Forth. This leads to implementations
larger and more complicated than wholly necessary.
> In the meantime, lets not re-write the Linux kernel on forth. That
> would be bad!
It would.
Andrew.
Albert van der Horst
Jonah Thomas <jeth...@gmail.com> wrote:
>> William James wrote:
>>
>> > Count the occurrences of distinct sequences of letters ("words") in
>> > a text file, sorting the results primarily by the counts and
>> > secondarily by the "words".
>>
>> Ruby:
>>
>> h = Hash.new(0)
>> IO.read("Bible--kjv10.txt").scan(/[a-z]+/i){|w| h[w] += 1}
>> puts h.map{|k,v| [v,k]}.sort.map{|a| a.join " "}
>
>Standard Forth doesn't give you all the tools to do that. My natural
>thought here is to set up some new wordlists whose hash function is the
>first four characters. So they'll be mostly sorted. For each new word,
>you look it up
>ihttp://mycplus.com/source-code/java/count-the-words-in-a-file-java/n
>each wordlist and if it isn't found anywhere, put it in the first one.
>If it's found, remove it from that wordlist and add it to the next one.
>If it's found in the last wordlist, make a new wordlist and add it to
>that one.
Given that Forth has virtually no high level tools, it is still easy.
1. Make table to translate characters to uppercase the rest to spaces.
2. Get the King James Bible in a string, and convert according to the
table
3. Split into words.
4. Sort the words
5. Convert into (frequency name) pairs
6. sort those pairs
The only place where non-standard processing takes places is in 5.
I had a guy at the Dutch tax stunned. There was a kind of table
join need and somehow it was outside of databases.
The Unix ``join'' tool made this several orders faster than the way
they did it before.
So in practice I would do
1. Use sed
2. Use sed
3. Use sed
4. Use sort
5. Use Forth
6. Use sort
5 would be something along (untested) (From a slurped file to
standard out.
: SDSWAP ROT ; : DSSWAP ROT ROT ;
\ Count the number the string at ``PAD'' occurs in STRING.
\ Return COUNT and remainder of STRING. (s--m s)
: count 0 SDSWAP BEGIN ^J $/ 2DUP PAD $@ $= WHILE
2DROP DSSWAP 1+ SDSWAP REPEAT PAD $! ;
\ Print the occurrences for FILE.
: doit GET-FILE ^J $/ PAD $!
BEGIN PAD $@ TYPE count SDSWAP . CR DUP 0= UNTIL 2DROP ;
(Same may prefer using NAME instead of ^J $/ to split off
a string from a file.)
A great advantage of using sed in steps is that you can actually see
whether the result after step 2 is what you intended.
The Forth program written could be added to the toolbox.
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
Albert van der Horst
Jonah Thomas <jeth...@gmail.com> wrote:
<SNIP>
>That's what I'm talking about too. You could translate a java or C
>could find a way that looked particularly elegant in Forth to do it. But
>the result would be that you were duplicating the effort that other
>people had already put into solving that piece of somebody's homework.
HOMEWORK. That is what it is. If you are writing a sermon and
you're interested in how many times
the word wine occurs in kjv.txt you would do
grep -i wine kjv.txt | wc -l
>
>> Wil was like you in being able to make anything more
>> complicated than what other people would do.
>
>I'm learning better. Can you suggest ways I could improve faster? Last
>week I was doing something that processed strings a character at a time,
>and it was doing some stack thrashing. It looped around keeping track of
>the location in the string, and it had to remember the beginning and end
>of the string, and several other things. It was too much stack
>manipulation. Then I tried using something that was just like SOURCE and
>>IN and the complications went away. I started out not wanting to use
>any variables but it turned out that just a few helped a lot.
>
>> > Well, but if you want to do part of the work in Forth and part in
>> > another language then you need them to communicate well.
>>
>> Indeed the glue may be much larger and more complex than Forth
>> itself. You are likely to end up with either the biggest and
>> most complex Forth or the lowest performance Forth this way.
>
>But maybe most of the glue doesn't have to be on the Forth side. Then
>the Forth can be simple and still interact with other stuff. The problem
>with doing it all in Forth is you have to do it all. And if you want to
>tell somebody else how great it is they'll say "Can you do this in
>Forth" and it will be something that takes you an hour and they'll laugh
>at you.
>
>If you can get them doing some of their work in Forth and it's truly
>easier for them, then they'll want to do more of it that way, and the
>more of it they put on the Forth side of the interface the easier it
>gets for them. If they have to commit to doing everything for themselves
>in Forth before they start, they probably won't.
>
>> > Marcel Hendrix has proposed a
>> > reasonably simple set of Forth words that can do a whole lot of pipe
>> > stuff without having to consider the difference between Windows
>> > pipes and Unix pipes.
>>
>> Reasonably small amount of glue to a C OS. Ok. But what is
>> reasonable to you or Wil or Marcel looks pretty big and complicated to
>> people who are used to Forth without the hundreds of megabytes of C
>> overhead that you are talking about.
>
>Sure, but if you need to deal with the C OS then it's real good if you
>can do so. I like the idea of rewriting Unix utilities in Forth. Get
>them smaller and not too much slower, with maybe a second simpler
>interface available too. The more of that you can get done, the more of
>the system turns into Forth and allows you to simplify it further. But
>I'm afraid it would be a losing battle. Unix experts can add complexity
>faster than you can possibly remove it. Maybe in a special case. I've
>played with a Linux named DamnSmallLinux, where they promise to provide
>a functional system that's no more than 50 megabytes when it's stored.
This is futile, indeed.
The problem lies in the interfacing with the hardware
and elementary definitions. E.g. an ELF header is defined in
a C include file, and it is a night mare to create an ELF header
from Forth. If your program connects to the internet, you have
TCP/IP and all those protocols to deal with. Without include file
to describe those package, it is a puzzle marathon.
You are entitled to write a new language like C++, as long as ...
you write it in C.
Stephen Pelc
wrote:
>I believe that the ANSI process has been both a Godsend, as well as
>extremely destructive. The Forths I see today are not small things
>you can get your head around in a couple of days, they are massive - I
>suspect that we have lost something. That may have even started in
>the 80's when F83 came on 4 floppy disks...
I sympathise, but the world has changed. PCs are massive compared
to those of the 1980's, and people are required to write much more
complex applications for them. To do this in Forth requires a bigger
chassis than was required for 1980's apps.
The same is true in the embedded world. Where the early single chip
microcontrollers had 1-4k of ROM and 256 bytes of RAM, we now have
chips for the same price or much less with 512k Flash and 64k RAM
and far more peripherals. Engineers expect be able to use these
facilities. A recent single-chip app MPE was involved with had
Ethernet and TCP/IP with web server,
SD card and FAT file system,
USB with mass storage and virtual serial ports,
and much more
Clients are attracted by Forth systems with these facilities.
The great thing about the ANS and Forth200x processes is that
they improve the portability of both programs and programmers.
The loss you observe is not a function of ANS or Forth200x at
all, but a function of what we are required to do these days.
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
Anton Ertl
>the implementers either got carried away or had never done a Forth
>implementation before. The latter (no names) sometimes used
>"traditional" techniques (compilers, linkers, etc) to implement Forth
>rather than writing Forth in Forth. This leads to implementations
>larger and more complicated than wholly necessary.
Interestingly, Gerd Franzkowiak recently told me that he had looked at
various Forth systems for an embedded Linux system. He found FICL
fitting for his task. Not only was it relatively simple, it also
built using a C compiler and linker (I would call this approach
"non-traditional" in comp.lang.forth, though), which fit into the
build environment (http://buildroot.uclibc.org/) he is using.
In contrast, Gforth has a more complicated build process, part of
which is in the Forth tradition: Cross-compile a simple image using a
Forth cross-compiler, then extend it on the target. There's also
other things that the Gforth build process wants to do at the target,
but most of them can be worked around. But my impression is that
Buildroot is not designed for doing any build steps on the target at
all, so Gforth will not be easy to build there in general; you can do
the image extension on the build system if it has the same cell size
and byte order as the target system, though.
For now he has decided to go with FICL.
- 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 2009: http://www.euroforth.org/ef09/
Jeff Fox
> No, I'm trying to get a sense of what you advise.
I no longer have that sense at all. You appear to only by
trying to deny that I wrote and distributed lots of software
used by other people and deny that I did it so people could
use it and learn because you are now just trying to be
insulting. You know you are lying.
It is more fun for you take "identify the problem and select
the appropriate tool" and quote it as "all problems are the
same so use only Forth for everything for insane reasons".
You are just trying to be as insulting as possible and I don't
think you really want to continue that tack for long.
> "Thankfully Forth is a thousand times simpler when you have Forth
> that isn't 99% about C systems."
Well my favorite subjects in Forth are parallelism, Forth OS,
Forth GUI, and the work on simple low power high performance
processors. I think GUI is a good example. Chuck has always used
a different approach than I on it.
I have used the big OS GUI and written for the interface. I have
tried
to avoid that complexity by using a standard Forth that puts a layer
of
glue in between so that you can use Forth syntax out of the box and
reduce the number of low level interface details that you have to deal
with. But they can over mask over the real complexity in all those
tens of megabytes of code too much. You still have to occasionally
wade though hundreds or thousdands of different functions and tens
of thousands of variables to figure how how to use the GUI interface
when the system is mostly this very complex collection of code with
an incredible number of non-obvious side effects.
At iTV I did the GUI for the OS. To do that I had to do it three
times. Once in Windows for the original high level simulator that
let applications developers use the high level GUI interface that
would eventually exist in the OS right from their ANS Forth and
debug their windowing code for the target application a couple of
days after the project started. Humm, Windows Forth
programming, by me.
Then I wrote the low level simulator in Windows that simulated
every bit in memory and machine cycle and allowed developers to
develop binary images for the targer before it was built and
test them right down to every bit from the modem to the keyboard
to the flash files etc. to create flash images for the target
that was not available yet. And you could run the flash images
on your PC because it used its keyboard and modem and Windows
windows exactly like the low level hardware target system with
a layer of glue to the Forth Windows interfaces. Hmm, Windows
Forth programing by me.
Then I wrote the OS GUI code for the target. The application
GUI code for the target had been written long ago. I had done
the Windows programming twice on two products. And now I had
to do it without Windows. I had to write the code that was
going to replace Windows in the real target and provide the
OS GUI services for multi-tasking multi-windowed embedded
applications.
I know you have heard the story before and know the punch
line. Because the target code was only 2K writing it was
MUCH easier than writing the glue to any of the popular
Forth GUI interfaces on top of the ANS Forth windows layer
on top of the Microsoft Windows API. It's pretty simple.
Dealing with 2K of Forth is easier than dealing with
tens of megabyte of code and multiple languages, duh.
Other people tell me they did similar things and found
the same thing. It was easier to write OS code yourself
in Forth than to hook to a big C OS. This seems to shock
people with hosted only experience.
When I mention an alternative that is not the same as
saying that the alternative that other people did not
consider is the only alternative that anyone should
every use for any problem that comes up as you want
to claim to be insulting.
From this I made the simple statement that dealing with
2K of Forth code written to match the application needs
is easier than dealing with 20M of external code that
will do it for you even if the megabyte of glue that
someone else has added is there to make the 20M of
code easier to deal with. I say 2K of code is simpler
than 20M of C. You seem to think that the idea
is absurd.
This sets you off. So despite knowing all this and
that I also published other Forth programs so that
other people could use them in hosted environments
it is easier for you to just insult me and create
a straw man claiming that what I say is that I don't
hosted Forth, that no one should. Or you get even
more insulting and write that I was lying and wrote
that people should always just use Forth for
everything regardless of what it is.
You are just trying to be as insulting as possible.
You want to deny that I wrote that code or all
the compilers, simulators, and tutorials in
various Forth over the years. You want to deny
that I know how many thousands of times they have
been downloaded by other people so that you can
tell people that I say don't use any hosted
software, was lying about the hosted software
I wrote, and tell people that they should only
do everything in Forth.
I said from people's hatred of colorforth c.l.f that
Chuck should not expect people to take to it regardless
of the amount of success with it that he reports. So
someone who argued with Chuck insisted that what
most people would need would be a target compiler/
simulator that would use ASCII source files so that
they could use their favorite editor, and run in
their favorite OS so that they could still do all
that other stuff like they always do and that it
should be written in standard Forth so that the
source code would be readable to people who only
know that much about Forth.
So in 2004 I wrote VentureForth and the t18 compiler.
Hmm, ANS Forth, windows hosted, me. Hmm. that seems to
confict with the garbage you keep posting doesn't it.
Facts never get in your way when you are posting lies
about other people do they?
You keep saying I don't use ANS, don't use hosted
Forth, don't recommend it to anyone etc. And
despite being shown the evidence again and again
you keep insisting on lying so that you can be
insulting and claim that I say not do to what I
do.
> Can you see how I might think that's what you intended?
No. Your just trying to be an ass.
Please explain the FORML papers, the many public hosted Forth
systems, compilers and simulators, and tutorials that have been
hit millions of times and the programs like Ventureforth! If
what you talk about my not doing ANS Forth or using hosted Forth
and telling people that they should not ever used code hosted
in C systems then how do you explain the existence of my website?
How do you explain the existence of VentureForth? You can't.
These simple well known facts conflict with your absurd claims
that you have logical reasons for posting the vengeful lies
that you keep posting.
> That's good for Chuck's chip-design program against the standard tools
> of that day. It doesn't say much about Forth.
Well one can see it as a comparison of as equal of teams as
possible given the same assignment. The main difference one
was using only Forth, the other was using only non-Forth.
People who want only to prove Forth's failures almost always
can do little more than show their own code. People who refuse
to acknowledge Forth success stories for other people will
always simply deny the value of anything that shows Forth in
a good light. But that's a different subject and you are
just trying to be insulting at this point.
> Great! Any chance that IntellaSys might let somebody look over some
> fraction of their data and publish the relevant results? It might be too
> big a project for Noah Ryman's master's thesis, but maybe not.
Your free to try to convince the lawyers to publish the records of
what got spent where. If I were them I wouldn't do it for a long
list of reasons that most adults or people involved in business
would well understand.
> There are tricks to fooling people into thinking you know what you're
> talking about. It might be worth it to Chuck to think about that. For
> that matter it might be worth it to me too; I've tended to think it was
> immoral and ignore the topic apart from noticing a little bit about how
> it works.
Chuck is not trying to fool people. Not a good road to go down. So
he just sticks to reporting facts that can be confirmed when
explaining
what he has accomplished. When he talks about Forth and his methods
to people who want to learn to do Forth better he is willing to
speculate
about things that can't be objectively measured, but that's different
than reporting about how his chips work.
As for your lesson about the newbie street performer it seems
like a story with a lesson for someone starting out, wanting
to follow what they like to do but not knowing how to make
a living with it. I don't think it applies as much to people
who had to deal with that long ago and have been professionals
for a long time and are winding down. If they have loved making
a good living doing what they love then I think it is less
applicable.
Perhaps I get into trouble because most of the Forth people I
know are gray and winding down. Many have made millions just
doing Forth and loved it. I probably tend to talk to people
here as if they understood the stuff those people understand
rather then resenting them for their success with Forth.
These people don't worry about what to say if a student laughs
about how their Perl homework is easier in Perl than in Forth
like you. But their approach to Forth has let Forth be better
for them than it is for some people.
Best Wishes
Jonah Thomas
> > No, I'm trying to get a sense of what you advise.
>
> I no longer have that sense at all. You appear to only by
> trying to deny that I wrote and distributed lots of software
> used by other people and deny that I did it so people could
> use it and learn because you are now just trying to be
> insulting. You know you are lying.
>
> It is more fun for you take "identify the problem and select
> the appropriate tool" and quote it as "all problems are the
> same so use only Forth for everything for insane reasons".
> You are just trying to be as insulting as possible and I don't
> think you really want to continue that tack for long.
Jeff, I think we managed to have a polite conversation that lasted
longer than any of the ones in the last couple of years. Thank you for
that.
Jacko
Sounds like "horses for courses."
cheers jacko
"If the imperative tense was called the lazative tense then the world
MAYBE a better place."
David Thompson
(Anton Ertl) wrote:
> Jonah Thomas <jeth...@gmail.com> writes:
> >> William James wrote:
> >>
> >> > Count the occurrences of distinct sequences of letters ("words") in
> >> > a text file, sorting the results primarily by the counts and
> >> > secondarily by the "words".
> >>
> >> Ruby:
> >>
> >> h = Hash.new(0)
> >> IO.read("Bible--kjv10.txt").scan(/[a-z]+/i){|w| h[w] += 1}
> >> puts h.map{|k,v| [v,k]}.sort.map{|a| a.join " "}
>
> Shell utilities:
>
> awk 'BEGIN {RS="[^a-zA-Z]+"; ORS="\n"} {print}' vmgen.texi|sort|uniq -c|sort -n
>
Nit: you don't need to set ORS (setting RS doesn't change it).
But more important, awk can do the count without sorting first:
gawk -vRS='[^a-zA-Z]+' '{++k[$0]} END{for(i in x){print k[i],x}}' \
input | sort -n
Using a regexp for RS is nonstandard but is available in (GNU) gawk,
where (at least in fairly recent versions) envvar WHINY_USERS will
cause the for(i in x) to enumerate in key=word order; otherwise (in
standard awk) you can do FS and loop over fields within lines*, and
either explicitly sort in awk (tedious) or POSIX sort -k1n -k2 .
(*Or preprocess with tr nonalpha newline as elsethread, but then awk
doesn't give as much benefit over sort|uniq-c.)
gavino
> On Apr 3, 9:58 am,JeffFox<f...@ultratechnology.com> wrote:
>
> > that 3K of code is a lot simpler than 1010K of code.
>
> Oops. That should have been 10010K or more of code. X windows
> isn't just 1M! Those pesky zeros!
>
> Best
ha ha go get him jeff f!
Ian Osgood
> William James wrote:
> > MarkWills wrote:
>
> > > For me, the language, in it's current form lacks nothing. In fact,
> > > I'm probably in the old-school camp, and would advocate reducing the
> > > dictionary down to a much smaller size,
>
> > Can you use it for these problems?
>
> I guess not. Of course, it's well-suited for flushing toilets.
> That's what the regulars here want. A low, low, low level
> toilet-flushing language.
>
>
>
> > Count the occurrences of distinct sequences of letters ("words") in a
> > text file, sorting the results primarily by the counts and secondarily
> > by the "words".
>
> Ruby:
>
> h = Hash.new(0)
> IO.read("Bible--kjv10.txt").scan(/[a-z]+/i){|w| h[w] += 1}
> puts h.map{|k,v| [v,k]}.sort.map{|a| a.join " "}
>
>
> ....
>
> 2 wretched
> 2 writest
> 2 wronged
> 2 x
> 2 youths
> 2 zealously
> 3 AND
> 3 Abba
> 3 Abdi
> 3 Abelmeholah
> 3 Abiel
> 3 Above
> 3 Achshaph
> 3 Adiel
> 3 Adonibezek
> 3 Adonikam
> 3 Adrammelech
> 3 Adullamite
>
> ....
>
> 12346 in
> 12586 that
> 12846 And
> 13447 to
> 34542 of
> 38885 and
> 62169 the
>
>
>
> > Calculate 33!.
>
> Ruby:
>
> def fac n
> if n < 2
> 1
> else
> n * fac(n - 1)
> end
> end
> ==>nil
> fac 33
> ==>8683317618811886495518194401280000000
Hey Mr. Ruby Guy!
Would you like to help with a Forth/Ruby intersection problem? The
Ohloh open source tracking project doesn't yet have a Forth parser,
but its parsing engine is written in Ruby. Would you like to
contribute a Forth parser to the project?
Thanks in advance,
Ian
David Thompson
> But more important, awk can do the count without sorting first:
> gawk -vRS='[^a-zA-Z]+' '{++k[$0]} END{for(i in x){print k[i],x}}' \
Argh. Of course I meant for(i in k){print k[i],i} .
I first wrote x, then decided to use k, but misedited. Sorry.
em...@dyeforit.co.uk
wrote:
> In article <20090402115346.35cdf8b3.jethom...@gmail.com>,
There's an interesting word frequency counter at the back of this
paper from Google.
http://labs.google.com/papers/mapreduce.html
A slightly bigger problem than the KJB ;)
Emma
oua...@gmail.com
here is a acript using gforth.
is a partial solution, working with 'cat' and 'sort -n', like this:
cat file1 file2 .. filen | wf [ -c ] | sort -n
Knowing that gforth dictionary is a hash-table (and should be fast),
here is a script that make use of that. The heart of script is word
'inter' that read a word from input, compile it if is not found in
wordlist, or execute it if is founded. 'data is code' concept.
BUGS: scanned files should not contain words 'wc###' and '.freq###'.
Naive remedy: use more harder names for them.
Feedback welcome! :)
%<-----------------------------------------
#! /usr/local/bin/gforth-fast -m1G
\ using gforth 0.7.0
: usage
s" wf - unsorted Word Frequency"
stderr write-line
s" Usage: cat file1 .. filen | wf [-c case sensitive]"
stderr write-line
-1 throw
;
argc @ 2 > [IF] usage [THEN]
: case-sensitive? \ -- f
next-arg 2dup 0 0 d<>
IF
s" -c" compare
IF usage ELSE -1 THEN
ELSE
2drop 0
THEN
;
: ishere? \ c-addr c -- 0 | xt -+1
get-current search-wordlist
;
: add$ \ c-addr c a -- a+c
2dup + >r
swap move
r>
;
: wc### create 1 , does> 1 swap +! ;
\ ;inspired from 'see name-too-long' -> maximum word-length !?
lcount-mask constant MAXWDLEN
create buff
\ ;hard coding of wc### with blank padding to _8_ chars to keep
aligned
char w c, char c c, char # c, char # c, char # c, bl c, bl c, bl c,
MAXWDLEN allot
: compile \ c-addr c --
MAXWDLEN min
[ buff 8 + ] literal add$
buff -
buff swap EVALUATE
;
: inter \ -- ;THE HEART: interpreter
BEGIN
parse-name dup
WHILE
2dup ishere?
IF execute 2drop ELSE compile THEN
REPEAT
2drop
;
: runner \ -- ;inspired by read-loop@kernel/input.fs
BEGIN refill WHILE inter REPEAT ;
: .freq### \ -- ;inspired by 'see wordlist-words'
get-current
cell + \
BEGIN
@ dup
WHILE
dup name>int >body ?
dup name>string type cr
REPEAT
drop
;
case-sensitive?
[IF] table
[ELSE] wordlist
[THEN] >order definitions
stdin ' runner execute-parsing-file
.freq### bye
------------------------------------------->%
have a nice day,
humptydumpty
P.S. For every one, please use it as you wish, improve it, etc...
oua...@gmail.com
some measurements (on FC8 Intel Q6600 2.4 GHz, 4Gb RAM), here:
$ du -m ccc
120 ccc
$ cat wf.ruby
h = Hash.new(0)
IO.read("ccc").scan(/[a-z]+/i){|w| h[w] += 1}
puts h.map{|k,v| [v,k]}.sort.map{|a| a.join " "}
$ time ruby wf.ruby >ruby.out
real 1m10.237s
user 1m0.083s
sys 0m10.036s
$ time cat ccc | tr -sc "a-zA-Z" "\012" | wf -c | sort -n > gf.out
real 0m25.663s
user 0m25.352s
sys 0m0.346s
$ time cat ccc | tr -sc "a-zA-Z" "\012" | sort | uniq -c | sort -n >
uxtools.out
real 1m5.579s
user 1m5.114s
sys 0m0.642s
$ tail ruby.out gf.out uxtools.out
==> ruby.out <==
116495 and
123887 E
125494 of
131857 to
153377 D
182131 A
197897 K
260002 gamete
300898 a
304104 the
==> gf.out <==
116495 and
123887 E
125494 of
131857 to
153377 D
182131 A
197897 K
260002 gamete
300898 a
304104 the
==> uxtools.out <==
116495 and
123887 E
125494 of
131857 to
153377 D
182131 A
197897 K
260002 gamete
300898 a
304104 the
What to say: gforth solution is not too slow! :)
have a nice day!
humptydumpty
P.S. For every one, please use it as you wish, improve it, and give
it to others too (for free, of course) :)