newbie questions
Andreas Klimas
actually I'm learning forth, and what should I say ... it's really
nice and easy.
because I'm not an forth guru I can't understand some things:
1) why is C, C++, Java on top position for computer languages and
not forth ?
2) why are the most applications for embedded systems and only a
few for desktop applications ?
3) why is Linux written in C and not in forth ?
hopefully I'm not offtopic here and hopefully these are not
the wrong questions
thanks
Andreas
--
Greetings from Lake Constance, Germany
Andreas Klimas (kli...@k-r.de)
cLIeNUX user
>Hi everybody
>
>actually I'm learning forth, and what should I say ... it's really
>nice and easy.
>because I'm not an forth guru I can't understand some things:
The answers to these questions are opinions. These are mine.
>
>1) why is C, C++, Java on top position for computer languages and
> not forth ?
Unix and marketing. Also, the top is what you can see. I doubt there's
much embedded Java out there.
>
>2) why are the most applications for embedded systems and only a
> few for desktop applications ?
>
Forth is difficult to market without a hardware dongle. Forth is too
flexible for shrinkwrap marketing.
>3) why is Linux written in C and not in forth ?
>
Because Minix is in C, and the examples in "The Design of the UNIX
Operating System", M.J. Bach, AT&T copyright, are in C.
Also, C is a consistantly high-performance compiler. Forth implementations
vary.
The predecessor of C, B, was a threaded code address interpreter like most
Forths, but with one stack. I presume it was determined that that was not
fast enough. That may have changed since 1972.
Rick Hohensee
Jason Damisch
>actually I'm learning forth, and what should I say ... it's really
>nice and easy.
Yes it is. I like the way Forth doesn't get in the way of what you
want to do.
>1) why is C, C++, Java on top position for computer languages and
> not forth ?
Because the C family of languages are the baby of I.T. culture. They
grew up on it, its their native language and their religion. AT&T invented
C and Unix, and AT&T is tightly coupled with the government. So is IBM.
The U.S.A. is a state capitalistic system, meaning the State and its
favored corporations get the steaks, and everyone else gets the organs,
or they eat greens. C looks good in theory. It is what a computer language
is supposed to look like to a mathematics professor. Remember that
computers started out as overgrown adding machines. The schools are
controlled by the Government and the Meagacorporations. Forth on the
other hand was invented by a single man alone working on the shop floor
to solve a real problem. This is why Forth is a very pragmatic language
while the C family of language are baroque.
>2) why are the most applications for embedded systems and only a
> few for desktop applications ?
Because embedded systems are not sexy, they are boring like beets.
Desktop systems are sexy, so that is where the attention went. But,
now that they have conquered the desktop, they are now after
embedded systems as well. Its probably a good thing that Y2K
happened last year, instead of 10 or 20 years from now.
>3) why is Linux written in C and not in forth ?
Unix and C were invented by the establishment. They are inseparatable
They go together like hammer and nail. Unix is built from C, that is the
specification.
>hopefully I'm not offtopic here and hopefully these are not
>the wrong questions
Your questions were on topic. They may have been the wrong questions
but I don't care. I'm glad you asked. Actually, they were the
right questions and these were the wrong answers.
Hi, my name is Jason * Damisch *
#### Forth Link Directory at Memnonio
#### http://www.memnonio.com/forth.html
#### GIVE ME FORTH LINKS
Anton Ertl
Andreas Klimas <kli...@k-r.de> writes:
>1) why is C, C++, Java on top position for computer languages and
> not forth ?
Not sure what you mean with "top position", but I guess you mean
popularity. C++ and Java are popular, because they look like C, and C
is popular because it looks like Fortran, and Fortran is popular,
because it looks like mathematics and because it was the first
language with a high-quality compiler.
>2) why are the most applications for embedded systems and only a
> few for desktop applications ?
Are they?
>3) why is Linux written in C and not in forth ?
Ask Linus Torvalds.
My guesses:
1) C is popular (see above).
2) Linux is a Unix and Unix and C grew up together.
3) GCC was one of the few free compilers in the early 1990s that
optimized well.
- anton
--
M. Anton Ertl Some things have to be seen to be believed
an...@mips.complang.tuwien.ac.at Most things have to be believed to be seen
http://www.complang.tuwien.ac.at/anton/home.html
Gary Chanson
Anton Ertl <an...@mips.complang.tuwien.ac.at> wrote in message
news:97e9q3$j1c$1...@news.tuwien.ac.at...
>
> >3) why is Linux written in C and not in forth ?
>
> Ask Linus Torvalds.
>
> My guesses:
>
> 1) C is popular (see above).
>
> 2) Linux is a Unix and Unix and C grew up together.
>
> 3) GCC was one of the few free compilers in the early 1990s that
> optimized well.
More important, it would be an overwhelming job for someone to create a
Forth implementation of UNIX because it would all have to be created almost
from scratch. In C, most of it can be stolen.
--
-GJC
-gcha...@shore.net
-Abolish Public Schools.
Bart Lateur
>>2) why are the most applications for embedded systems and only a
>> few for desktop applications ?
>
>Because embedded systems are not sexy, they are boring like beets.
>Desktop systems are sexy, so that is where the attention went.
I disagree. I tend to turn this around.
FORTH is used for embedded systems, because it's so damn easy to
(re)write a dedicated full system in FORTH for most processors, in just
a matter of days. Well, alright, weeks, if you're not familiar with the
processor. Besides, the runtime for the FORTH system tends to be pretty
small, often even smaller than applications written in assembler.
Compilers in C/C++, are, OTOH, black boxes. You have not a clue what
exactly they produce, but chances are that the code it produces is BIG.
And, not unlikely, BUGGY, especially for processors that aren't that
widely used just yet. And once you found a compiler bug, there's nothing
you can do about it.
There you have it. It doesn't matter that compiled code is big for
desktop apps. They're so widely used that virtually all bugs will be
eliminated. Plus, C has a reputation of producing code "virtually as
fast as hand written machine code". That's why it's the first choice for
many programmers. Whether it really deserves this reputation, is still
an open question.
Writing code in C, or any other similar language (like Pascal), looks
easier than in FORTH, because the language has some built-in protection
against shooting yourself in the foot: once you've set up what
parameters a function expects, and what it's supposed to return, there's
NO WAY that you can write code, however buggy, that will mess THIS up.
Stack imbalance is typical for FORTH. One tiny error in FORTH, and not
only will your code not produce correct results (same as in C), but
also, chances are that you'll get a runaway program that can easily
crash your system. Not a very desirable feature for a development system
for desktop apps. Net result is that FORTH programs tend to be better
debugged. They have to be. ;-)
--
Bart.
cLIeNUX user
>In article <3A99A2E1...@k-r.de>,
> Andreas Klimas <kli...@k-r.de> writes:
>>1) why is C, C++, Java on top position for computer languages and
>> not forth ?
>
>
>optimized well.
>
That's a good point I'd missed. gcc made Linux and the free BSDs possible,
which was it's goal, roughly. Well, a bit short of it's actual goal, which
is represented by the GNU HURD.
Conversely, people that do things like write a gcc frequently don't know
Forth. They are also very used to useful things being large. Forth can be
underappreciated because of it's size, much like Linux can be
underappreciated because of it's price.
Rick Hohensee
cLIeNUX user
>
>Elizabeth D. Rather <era...@forth.com> wrote in message
>news:3A9C0972...@forth.com...
>>
>> No, it'll take more than "programmers who write." It'll take the
>> backing of one or more large, well-known and widely-respected academic
>> and/or corporate organizations willing to put a large-scale effort
>> behind promoting it. The lack of that kind of support is why Forth
>> isn't more widely known.
>
> And that will never happen because Forth is too idiosyncratic. The
>language design and philosophy are very different from main-stream
>environments, which, of course, is why we love it. Unfortunately, it's also
>why most programmers will never accept it.
>
I don't love Forth because it's different. I love it because it is better.
Rick Hohensee
Adrian Ho
> Our "Forth Programmers' Handbook" has been available from several
> on-line bookstores (e.g. Amazon) as well as from ourselves since 1997,
> and we introduced the introductory "Forth Application Techniques" just
> last December.
Unfortunately, and I think this is Mike C's point, these are the only two
new Forth books I've seen in at least 5 years. (The last one I remember
was Jack Woehr's 1992 opus "Forth: The New Model".)
They're not as much fun (ie. whimsical) as Starting Forth, which really
got me clued-in and jazzed-up about this funky language.
They don't delve into the gory details of Forth implementation like RG
Loeliger's Threaded Interpretive Languages, which gave me the confidence
that, even though I haven't gotten around to "rolling my own", I can do it
in a couple of weekends (which I don't have 8-).
I haven't even smelled Dr Dobb's Toolbooks of Forth, but I guess they'd
have all sorts of interesting articles on uses of Forth, both practical
and whimsical, along with sample code. (I derive this view from Dr Dobb's
Toolbook of 68000 Programming, which itself has three articles on
implementing a Forth, a Forth cross-compiler and a Forth assembler.)
None of the above should be construed as criticism of your books, BTW. I
recently purchased both, and while I haven't finished either, I like what
I've seen so far.
But neither of them get me really excited about Forth, and IMO that's what
holding a lot of people back from exploring Forth. I'm looking for a book
that I can buy off-the-shelf, toss to my colleagues and say: "Here's a
book about a new-old language called Forth. I think you'll like it."
And be reasonably confident that he _will_ like it. "Starting Forth"
would be my first choice, though I've have to shrug if even 5 people ask
me "How can I get a copy?"
> It'll take the backing of one or more large, well-known and
> widely-respected academic and/or corporate organizations willing to
> put a large-scale effort behind promoting it. The lack of that kind
> of support is why Forth isn't more widely known.
Forth would stand a good chance of achieving _stunning_ success that way,
but I don't think that's necessarily a desirable conclusion (esp. looking
at the crap that passes for many C++/Java books nowadays).
Reasonable success is more palatable to me. By this, I mean a general
knowledge amongst the various programming communities about Forth, how it
works, what it's good for and what it's not, what implementations are
available, and the basics of rolling your own if nothing else fits your
bill. Not Forth the uber-language, but an alternative that's understood
and not far from everyone's hearts and minds.
What does it take to achieve this? From the publications side, reprinting
"Starting Forth" might be a start, perhaps through one of those
print-on-demand houses. New quality books on Forth (any Forth, not just
ANS) would also be good. Heck, I might just write one myself, if I can
scrape together enough weekends. 8-)
(And if anyone's planning to get rid of either or both Dr Dobb's Toolbooks
of Forth, do let me know. 8-)
--
- Adrian
-----= Posted via Newsfeeds.Com, Uncensored Usenet News =-----
http://www.newsfeeds.com - The #1 Newsgroup Service in the World!
-----== Over 80,000 Newsgroups - 16 Different Servers! =-----
Paul E. Bennett
m-cou...@ne.mediaone.net "Michael Coughlin" writes:
[%X]
> If some Forth programmers come along who decide to do a good
> job on human communication, Forth will be as widely used as
> Java, C and C++. These other languages beat Forth in the
> quality and quantity of their textbooks, documentation and
> visible application programs.
Having been in Waterstones within the last week I can certainly confirm
the quantity aspect of C/C++ and Java books on the shelves. However, the
sheer quantity does not imply that there is any real quality there.
> Maybe if more "newbies" remind the
> Forth community about the trouble they are having learning,
> things will get better.
I agree that the Forth Community should be doing something about the
situation. I have written several articles for the magazines which
are semi-tutorial. I run a training course (not Forth but it gets
plenty of mention and my coding examples are always in Forth).
Brodies pair of books, Forth Inc's handbook and a lot of reading
through here and the source code texts, and a wider range of books
than is mentioned in our FAQ all present good material. Introducing
new people to Fig and the magazines, the excellent library facilities
within fig (the UK one is very good) and even JFAR's which don't get
mention enough. I know that some of the material may need updating
but the information content is still valid and worth looking at.
--
********************************************************************
Paul E. Bennett ....................<email://p...@amleth.demon.co.uk>
Forth based HIDECS Consultancy .....<http://www.amleth.demon.co.uk/>
Mob: +44 (0)7811-639972 .........NOW AVAILABLE:- HIDECS COURSE......
Tel: +44 (0)1235-814586 .... see http://www.feabhas.com for details.
Going Forth Safely ..... EBA. www.electric-boat-association.org.uk..
********************************************************************
Bernd Paysan
> Brodies pair of books, Forth Inc's handbook and a lot of reading
> through here and the source code texts, and a wider range of books
> than is mentioned in our FAQ all present good material.
Brodies Starting Forth is a bit dangerous. While it's clearly a very
good introduction book, it's also outdated. My cow-orker started to read
it, but soon complained that Forth can't do file operations, floating
point, and some few other points that are clearly part of the ANS Forth
standard. If he had read further, he'd probably complained about the
ideosyncratic screen editor (which is not something Forthers use widely
today). SF needs an update.
FIG apparently did start an effort to update SF, but that effort didn't
get very far. The German Forth Gesellschaft also has some ambitions to
create Forth documentation, but so far, not too much happend. However,
our organization is in a better shape than FIG.
I'd also volunteer to coordinate a public effort to get SF into shape
for this new millennium - the examples have to be adapted, a few new
chapters and several new footnotes have to be written. Also, the
examples have to undergo a quality control: examples written in a
beginner's book should run on as many Forth systems as possible without
modifications, to avoid frustration. Thomas Baierlein volunteered (two
years ago) to write tutorial text, but refused to duplicate SF.
--
Bernd Paysan
"If you want it done right, you have to do it yourself"
http://www.jwdt.com/~paysan/
Marcel Hendrix
> I'd also volunteer to coordinate a public effort to get SF into shape
> for this new millennium - the examples have to be adapted, a few new
> chapters and several new footnotes have to be written. Also, the
> examples have to undergo a quality control: examples written in a
> beginner's book should run on as many Forth systems as possible without
> modifications, to avoid frustration. Thomas Baierlein volunteered (two
> years ago) to write tutorial text, but refused to duplicate SF.
I'd like to volunteer too. What chapter do you need first?
-marcel
Michael Coughlin
> cLIeNUX user <r@your_host.com> wrote in message
> news:t9mm8va...@corp.supernews.com...
> > Conversely, people that do things like write a gcc
> > frequently don't know Forth. They are also very used to
> > useful things being large. Forth can be underappreciated
> > because of it's size, much like Linux can be
> > underappreciated because of it's price.
> Except that in this case, if I remember correctly,
> Richard Stallman does have some experience with Forth.
I haven't read or heard Richard Stallman saying anything
about Forth, but I would assume that he does know a lot about
it. He does talk about Lisp, and the factors that influence his
use or non-use of Lisp are very similar to the factors that
would influence the use of Forth. Remember he worked at the MIT
AI lab where the latest and greatest computers were in use. When
he first learned about Forth, it would probably be using a 16
line by 64 character screen, while his other computers might
have been using a 19 inch two page display. The Gnu project was
always intended to create software for high powered computers.
That was what its developers used -- and they knew they had to
plan ahead for the day when their expensive workstations would
be less powerful than cheap common home game machines.
At the beginning of the Gnu project, the decision was made to
base the creation of free software on Unix and C. This was
because Unix and C were already established in the academic
departments of computer (and other) science. C source code for
the Unix OS had been available for study in universities all
over the world, and there were many programmers who had learned
to use it at an advanced level. It was clear to many in the
educational field that AT&T's new copyright restrictions were
making computer study at the college level more difficult. Yet
there was no other operating system that allowed advanced
computer research to be done as easily as with Unix. This was a
direct result of having access to the source code as well as a
collection of technical literature on Unix.
Contrast this with Lisp. Richard Stallman considers Lisp to
be a better language than C. But C is good enough to do what is
needed. And there are many more people who can (and could)
program in C than Lisp. There were big projects at MIT using
Lisp that had been turned over to two new commercial computer
companies. The extensive Lisp source code written at MIT (much
of which Richard Stallman wrote) was copyrighted and licensed,
and could not be used for the Gnu project. This included very
advanced graphical user interfaces (written before the MacIntosh
was invented) and a software system that could do algebra and
calculus symbolically. On the other hand, there were many
academic projects written in C that might have their licenses
modified to be used as free software. These included the
University of California at Berkeley version of Unix, the MIT
X-window graphical user system, and other research projects from
other universities. The amount of Forth code that could be used
at the beginning of the Gnu project was extremely limited.
So the decision was made that the most important thing to
create as free software was a big universal C compiler.
Incidently, there are Forth and Lisp compilers included in the
Gnu free software collection. But do you hear much about
applications written with them?
There is a new book about the history of Linux which has many
carefully researched facts. Check it out.
http://www.penguin.co.uk/Book/BookFrame?0713995203
--
Michael Coughlin m-cou...@ne.mediaone.net Cambridge, MA USA
Michael Coughlin
> Michael Coughlin wrote:
> > Years ago Forth and C were both obscure new languages
> > that were used by a small number of people. Forth became
> > widely known after the fig public domain defacto standard
> > model was written. A few years later an excellent textbook
> > was published, that was available in bookstores and
> > libraries everywhere. Today there is no interest in such
> > things from the Forth community. People are still creating
> > new Forth systems, but they do not create the educational
> > material necessary to show how to use Forth effectively.
> > Every once in a great while somebody does write something
> > interesting about Forth and then hides it where few people
> > will see it.
> Some people, such as ourselves, work very hard on writing
> and producing Forth educational material, but others such
> as you refuse to read or acknowledge it. Our "Forth
> on-line bookstores (e.g. Amazon) as well as from ourselves
> since 1997, and we introduced the introductory "Forth
> popular, and we've gotten good comments on it. We also work
> very hard producing thorough documentation for our products.
I read everything about Forth I can get my hands on, and a
lot that I can't. I got to look at "Forth Programmers' Handbook"
for about two minutes and couldn't understand why I never see it
in bookstores. Do you just want people who buy online to read
it? Most of the people I could get to consider buying it don't
know anything about programming but want to learn. I feel silly
when I tell people Forth is the best programming language but
you can't buy a textbook for it in your local bookstore anymore.
I don't think they will pay attention to my opinion of Forth
after they see three foot high stacks of books for sale on those
other inferior programming languages.
A fun thing about the web is the ability to look up library
books all over the world. The MIT libraries have 30 items on
Forth -- 20 books, Rochester Conference procs, IEEE SIGForth,
and the ANS Forth standard. But not "Forth Programmers'
Handbook" or "Forth Application Techniques" or anything else by
Elizabeth Rather. When I looked at Harvard's catalog I found ten
items on Forth, and one of them was by E. Rather. But wait -- it
was published in 1980! Must be something wrong with the east
coast. Ok, let me look at Stanford U. -- yes, 23 items, but the
newest is from 1991. All right, no more fooling around, here's
the mother load, 66 items on Forth from the University of
California's unified library catalog. They even have a book by
Dr. Ting (about fig-Forth). But not the new books by Ms. Rather.
Here is a sampling of four universities with the some of the
world's most active and advanced departments in computing,
mathematical sciences and engineering, and they don't have any
new material on Forth in their library systems. They have old
material, but why not new? Do they have a whole student body and
staff of professors who, like me, "refuse to read or
acknowledge" new educational material on Forth? And if they do,
why do they only do it now and not 15 years ago? Technical
librarians who work for universities do a good job. You really
have to work hard to hide things from them that belong in their
collections.
> > If some Forth programmers come along who decide to do a
> > good job on human communication, Forth will be as widely
> > used as Java, C and C++. These other languages beat Forth
> > in the quality and quantity of their textbooks,
> > documentation and visible application programs. Maybe if
> > more "newbies" remind the Forth community about the
> > trouble they are having learning, things will get better.
> No, it'll take more than "programmers who write." It'll
> take the backing of one or more large, well-known and
> widely-respected academic and/or corporate organizations
> willing to put a large-scale effort behind promoting it.
> The lack of that kind of support is why Forth isn't more
> widely known.
Big companies and academic organizations aren't going to do
any promotion for Forth unless Forth will do something for them.
If Forth had more programmers who would write interesting things
with it or about it, then it wouldn't need any big company to
promote it. There are new prospective Forth programmers showing
up on comp.lang.forth all the time and asking how they can learn
more about it. If they find good answers shouldn't they be able
to learn to program four to ten times faster than they used to?
I'll leave this signature for anybody who wants to get
their college library to order a new Forth book.
> ================================================
> Elizabeth D. Rather (US & Canada) 800-55-FORTH
> FORTH Inc. +1 310-492-3356
> 5155 W. Rosecrans Ave. #1018 Fax: +1 310-978-9454
> Los Angeles, CA 90250
> http://www.forth.com
>
> "Forth-based products and Services for real-time
> applications since 1973."
> ================================================
Siegfried Gonzi
> Big companies and academic organizations aren't going to do
> any promotion for Forth unless Forth will do something for them.
> If Forth had more programmers who would write interesting things
> with it or about it, then it wouldn't need any big company to
> promote it.
I can't resist to reply. A few days ago I wrote an email to a scientist
at the "Lawrence Livermore National Laboratory". That scientist is a
section-editor for a scientific magazine concerning
scientific-computing.
I recommended that scientist to write an article about "Is functional
programming for scientific computing". That has nothing to do with
Forth, but, I also mentioned in my email what I do and I wrote that I
learn Forth.
He answerd me (the part about functional programming is not of interest
here), but he wrote to Forth:
"Forth used to be *the* telescope control language. I learned it on an
Atari
800 computer. (I had two disk drives, a TAPE drive, a 4K (I think)
modem. I
love Forth, but of course it is useless for a big program)."
The last part is of interest! In the meantime I also believe that Forth
is not capable of handling big projects:
a) I know I shall become insulted for that, but: there exists not any
big project written in Forth.
b) I sometimes read that the compilers and development environments of
the big dealers are so bugy. For me that means, that this is not a good
reference for Forth, because I believe that the compilers itself are
written in Forth -- isn't it?
c) Even the guys at Smithonian A. lost interest in Forth. Why isn't
Forth used there any longer. The answer is that they were not able to
read the code they coded.
What I want to express is, that there will be no more programmers in
Forth at the really important institutions (like LLNL), even if there
are many books at bookstores. I think Forther deceives oneself too
often...
Regards,
Siegfried Gonzi
a...@redhat.invalid
: Jason Damisch wrote:
: Compilers in C/C++, are, OTOH, black boxes. You have not a clue what
: exactly they produce, but chances are that the code it produces is BIG.
: And, not unlikely, BUGGY, especially for processors that aren't that
: widely used just yet. And once you found a compiler bug, there's nothing
: you can do about it.
On behalf of all the maintainers of gcc, I must protest. You can find
out what code gcc produces, and once you found a compiler bug you can
get it fixed. gcc is not a black box.
Andrew.
Bart Lateur
>I got to look at "Forth Programmers' Handbook"
>for about two minutes and couldn't understand why I never see it
>in bookstores. Do you just want people who buy online to read
>it?
That decision is up to the bookstores. You can't *force* them to sell
it.
--
Bart.
Bart Lateur
>I know I shall become insulted for that, but: there exists not any
>big project written in Forth.
Chuck Moore (and Jeff Fox with him) would say: that's because in FORTH,
the apps needn't be that big! A hardware simulator for a CPU in just a
few k, is that a small or a big app? It certainly isn't a trivial app!
But, there are quite a few non-trivial FORTH apps, ForthCAD (written by
a regular in this group, Charles Mélice) and Meme, to name just two.
<http://www.immersive.com/overview.htm>
<http://www.immersive.com/>
--
Bart.
Tony Williams
Siegfried Gonzi <siegfri...@kfunigraz.ac.at> wrote:
[snippage]
> The last part is of interest! In the meantime I also believe that Forth
> is not capable of handling big projects:
> a) I know I shall become insulted for that, but: there exists not any
> big project written in Forth.
What is the definition of a 'big project'?
I mumble about Forth and avionics ATE on the odd
occasion (well, a bit of a bore about actually).
But look at this comparison.....
A 110-page Avionics Production Acceptance Spec;
Running TestBasic on a pair of Pentium m'boards ATE;
about 5megabytes of source code on the HD, and about
40 minutes of runtime to test the UUT.
Running Forth on a single ARM-based machine, about
330kilobytes of source code (transportable on a floppy)
and about 12 minutes of runtime.
> What I want to express is, that there will be no more programmers in
> Forth at the really important institutions (like LLNL), even if there
> are many books at bookstores. I think Forther deceives oneself too
> often...
You are right in that respect, Forth has definitely
been marginalised, and I don't think it will ever
even approach being mainstream now.
--
Tony Williams.
Adrian Ho
> On behalf of all the maintainers of gcc, I must protest. You can find
> out what code gcc produces, and once you found a compiler bug you can
> get it fixed. gcc is not a black box.
To you and a handful of other people in this world, and I salute you all.
But to the vast majority of folks like Bart and me, who don't understand
gcc's internals but can feed C code in and get compiled applications out,
gcc _is_ a black box. So is any language implementation, to the vast
majority of its users.
While it does not preclude us finding gcc bugs, it's much _much_ less
likely; it's far more likely that we'd be blaming our own code, or that of
our favorite library's implementors. Fixing it ourselves, of course,
would be well nigh impossible.
Jerry Avins
It's a matter of perspective. I can change a tire, but I don't fix
flats. If I tried to repair a bug in gcc on my own, you would be more
foolish than I for trying if you trusted any subsequent .o file. On the
other hand, I found what I called a bug in PolyForth (Others may not
agree.) Some comparisons failed if one of the operands was -$8000. I
rewrote the code and rebuilt the system. Maybe it was fool's confidence,
but I ran a factory line with the result.
As for knowing what gcc produces, sure you can. I hope Bart meant that
you can't guess ahead of time, but one doesn't often care. (For embedded
systems, one sometimes needs to "psych out" the compiler, writing the
same code several different ways -- indexed arrays vs. pointers, e.g. --
until the object code is reasonably efficient.)
Jerry
--
Engineering is the art of making what you want from things you can get.
-----------------------------------------------------------------------
Bart Lateur
>Bart Lateur <bart....@skynet.be> wrote:
>
>: Compilers in C/C++, are, OTOH, black boxes. You have not a clue what
>: exactly they produce, but chances are that the code it produces is BIG.
>: And, not unlikely, BUGGY, especially for processors that aren't that
>: widely used just yet. And once you found a compiler bug, there's nothing
>: you can do about it.
>
>On behalf of all the maintainers of gcc, I must protest.
Do you, as a maintainer of GCC, ever write an embedded system
application? No? Thought so.
Fact is: it's a different breed of programmers who get around inside the
intestines of a compiler, and those who write real world applications,
say, a graphics editing program. Therefore, what one does, is a black
box for the other.
And take Visual or Borland C on a Windows PC, not GCC. I'm not sure that
you can even build Windows DLL's using GCC. Make a minuscule DLL, with
one extremely simple function. Compile it. Disect the DLL that the
compiler made of it. It's not likely that many programmmers can easily
recognize the result. It's also likely that it is quite a bit bigger
than one would have expected. The compiler/linker just threw in a lot of
extra library code, of which it's often hard to tell just what it is
for.
--
Bart.
J Thomas
> "Forth used to be *the* telescope control language. I learned it on an
> Atari 800 computer. (I had two disk drives, a TAPE drive, a 4K (I
> think) modem. I love Forth, but of course it is useless for a big
> program)."
> The last part is of interest! In the meantime I also believe that Forth
> is not capable of handling big projects:
> a) I know I shall become insulted for that, but: there exists not any
> big project written in Forth.
There are some. But consider -- how do you decide what a big project
is?
Is is a project that requires 30 programmers? If 3 Forth programmers
can do the project does that mean it wasdn't a big one after all?
Is it a project that requires 100,000 lines of code? There is some
reason to think that Forth's compactness scales very well. The more
code, the more opportunities to factor -- but also the more important it
is to have things layered well so that the code you want to use in one
specialised module isn't buried in some other specialised module where
you don't notice it. Suppose that gets done well and the 100,000 lines
are reduced to 5,000 lines? Does that mean it wasn't a big project
after all?
Is it a big project if it has a budget of more than, say, 20 million
dollars? But if you're a manager with a $20M budget and you choose
Forth, you're putting your career on the line. You can use C++ and
nobody will blame you for that, and if the big project fails that's bad
but half of them do. If you use Forth and it fails you have made a
mistake that anybody could point to. It makes sense that managers for
big Forth projects would be rare.
Also, since there aren't a tremendous number of Forth programmers, there
aren't a tremendous number of unattached Forth programmers available for
a big project if one comes up suddenly. If you want 50 C++ programmers
you can go to a recruiter who can rent a building and rent equipment and
find programmers and have them all sitting at their desks on Monday. If
you want 50 good Forth programmers it isn't so easy. Lots of the
existing Forth programmers are engineers who use Forth because they just
want to get their work done with a minimum of fuss, who wouldn't be
interested in programming for a big software project.
So, is it just that nobody does big Forth projects because nobody does
them? No, Forth has the reputation for being bad at that. The only big
Forth project I've heard of that failed was the old Atari Valdocs thing,
a long time ago. The story I heard about that was that they tried to
extend some simple Forth tools far beyond the original intentions
instead of throwing them away and doing it right, and after awhile the
patches and the patches on the patches started getting hard to patch
together. They were using scattered people who telecommunicated, and it
was a long time ago. By the time they were sure they needed rewrites
they were out of time and money. By today's standards it might not even
have been a big project. I have never heard of another big Forth
project that failed. Has anyone else here heard of one? What I *have*
heard of, is engineers who build their own simple control language that
does what they need, and who keep adding to it as they need more, and
who train their assistants to use things from it as the need arises, and
then about the time the original engineer retires or moves on there is
no manual and nobody who can maintain it etc. This is not a big
project, it's a personal tool that grew by accident.
One failed Java project wouldn't get people to say Java was no good.
But there's a doctrine problem too. People believe that things like
type-safety are important. (I don't see that strong typing actually
helps with debugging, but it does do one important thing -- it requires
an important piece of documentation. If Forth it's vital to alwayw
provide the stack comment. With strong typing you are absolutely
required to give that information, your code won't compile unless you
do.) If people believe the features are necessary, and Forth doesn't
provide those features, then of course they'll think it won't meet their
needs.
> b) I sometimes read that the compilers and development environments of
> the big dealers are so bugy. For me that means, that this is not a good
> reference for Forth, because I believe that the compilers itself are
> written in Forth -- isn't it?
Some people who don't use commercial Forth compilers want to say they're
buggy. What bugs have yuo heard about from users? I'm sure there are
some. But also consider -- when I get a free, simple compiler, I'm
interested in what it does. Whatever it's good for is a plus. When I
buy a commercial system I want it to do whatever it is I want -- and so
does everybody else with their own needs -- and whatever behavior I
don't expect looks like a bug to me even if it's perfectly workable.
This is just something that vendors have to deal with.
> c) Even the guys at Smithonian A. lost interest in Forth. Why isn't
> Forth used there any longer. The answer is that they were not able to
> read the code they coded.
I hear that occasionally. "The Forth programmers we used couldn't read
their own code. So we got rid of them." I wonder what it involved?
Did they sit in a manager's office and have him point to code at random
and expect them to explain exactly what it did? It's always said the
same way. "They couldn't read their own code." Never any more
information than that. I wonder.
> What I want to express is, that there will be no more programmers in
> Forth at the really important institutions (like LLNL), even if there
> are many books at bookstores. I think Forther deceives oneself too
> often...
Could be.
a...@redhat.invalid
: a...@redhat.invalid wrote:
:>Bart Lateur <bart....@skynet.be> wrote:
:>
:>: Compilers in C/C++, are, OTOH, black boxes. You have not a clue what
:>: exactly they produce, but chances are that the code it produces is BIG.
:>: And, not unlikely, BUGGY, especially for processors that aren't that
:>: widely used just yet. And once you found a compiler bug, there's nothing
:>: you can do about it.
:>
:>On behalf of all the maintainers of gcc, I must protest.
: Do you, as a maintainer of GCC, ever write an embedded system
: application?
I don't write an embedded system application as a maintainer of GCC,
no. Right now I have only the one job and it's enough. :-)
: No? Thought so.
: Fact is: it's a different breed of programmers who get around inside
: the intestines of a compiler, and those who write real world
: applications,
So am I a different breed of person than I was a couple of years back?
I don't think anyone fitted implants while I was asleep...
: And take Visual or Borland C on a Windows PC, not GCC.
If you like; but that really *is* a black box. gcc isn't.
Andrew.
Adrian Ho
> b) I sometimes read that the compilers and development environments of
> the big dealers are so bugy.
Any references? I've been sucking up everything I can find that mentions
Forth, and I've _never_ seen that claim. I'm only half-excited about
this, though, because it sounds suspiciously like FUD.
> For me that means, that this is not a good reference for Forth,
> because I believe that the compilers itself are written in Forth --
> isn't it?
Just a couple of days back, someone in alt.os.dev basically asked how to
construct a self-hosted dev environment on an arbitrary platform without
using external tools, because he didn't want to "write an OS using buggy
compilers on another buggy OS". I replied:
It's not the total number of bugs in the tools you use; it's the number
of bugs that affect your work (which, if you chose your tools
appropriately, should approach zero).
> c) Even the guys at Smithonian A. lost interest in Forth. Why isn't
> Forth used there any longer. The answer is that they were not able to
> read the code they coded.
Did they actually say that? I've been seeing a lot of provocative remarks
lately in the dev groups and lists I lurk in, and most of them smack of
hearsay: "Friends/colleagues/people whose opinion I trust tell me that
[insert dubious statement]." Strangely enough, that last variant usually
accompanies the most outrageous claims.
> What I want to express is, that there will be no more programmers in
> Forth at the really important institutions (like LLNL), even if there
> are many books at bookstores.
The "really important institutions" may very well be doing work that can
be better expressed in languages other than Forth. They'd be fools if
they _didn't_ make the switch in this case.
> I think Forther deceives oneself too often...
The few "Forthers"[*] I know personally are all level-headed folks who use
the right tool for the job (I'm a rabid advocate by comparison). None of
them think that the ascendancy of Forth to the higher levels of
programming prominence would do Forth newbies any good -- just look at all
that C++ & Java crap^H^H^H^Hbooks on any bookstore's shelves.
[*] By which I mean "people who understand the basic principles of Forth
and have used it at one time or another".
--
- Adrian The tao of Forth is quiet revolution, grasshopper.
Marcel Hendrix
Siegfried writes:
> [ no big projects ]
How about the FSL? Minos? Gforth? Brew (757 KB in 67 files)? Manx (16 MB in
630 files)? iForth is 187 MB in 4592 files (it's not just the compiler) ...
-marcel
Elizabeth D. Rather
> Michael Coughlin wrote:
>
> > Big companies and academic organizations aren't going to do
> > any promotion for Forth unless Forth will do something for them.
> > If Forth had more programmers who would write interesting things
> > with it or about it, then it wouldn't need any big company to
> > promote it.
>
> I can't resist to reply. A few days ago I wrote an email to a scientist
> at the "Lawrence Livermore National Laboratory". That scientist is a
> section-editor for a scientific magazine concerning
> scientific-computing.
> [snip]
>
> He answerd me (the part about functional programming is not of interest
> here), but he wrote to Forth:
>
> "Forth used to be *the* telescope control language. I learned it on an
> Atari 800 computer. (I had two disk drives, a TAPE drive, a 4K (I think)
> modem. I love Forth, but of course it is useless for a big program)."
Your contact is poorly informed. See below for details.
> The last part is of interest! In the meantime I also believe that Forth
> is not capable of handling big projects:
>
> a) I know I shall become insulted for that, but: there exists not any
> big project written in Forth.
What's a big project? The biggest Forth project I've personally been
involved with was the instrumentation of the King Khaled International
Airport in Ryadh, Saudi Arabia. This project (mid-80's) involved a network
of ~500 computers controlling >30,000 points over a site several square
miles in size, including many safety-critical items (power systems, runway
lights, etc.). More recently, I know of a number of systems controlling
entire manufacturing plants, such as those producing Spalding golf balls.
Currently, Forth-based Open Firmware is used on the motherboards of all Sun
workstations, Apples, and IBM Power-PC systems. I've just recently trained
over 50 programmers at IBM alone. The NEAR space probe that recently
landed on an asteroid having completed a successful mission was programmed
in Forth at the Johns Hopkins Applied Physics Lab. That's just a few
examples.
> b) I sometimes read that the compilers and development environments of
> the big dealers are so bugy. For me that means, that this is not a good
> reference for Forth, because I believe that the compilers itself are
> written in Forth -- isn't it?
Where have you read such a thing? I am not aware of any such reports. In
any case, what do you consider buggy, given that Windows 2000 (MS's most
reliable system ever) was released with >60,000 known bugs?
> c) Even the guys at Smithonian A. lost interest in Forth. Why isn't
> Forth used there any longer. The answer is that they were not able to
> read the code they coded.
Roger Hauck at the Smithsonian Astrophysics Laboratory is a current and
active user of both SwiftForth and our SwiftX cross-compiler (for the
RAD-hard UT69R000 processor, being used in a NASA project). Several other
observatories are also current users. As to readability, we have customers
who have been using, extending, and maintaining their Forth projects for
>20 years, porting to new platforms as needed, and extol the
maintainability and readability of their Forth code.
> What I want to express is, that there will be no more programmers in
> Forth at the really important institutions (like LLNL), even if there
> are many books at bookstores. I think Forther deceives oneself too
> often...
We also have several active customers at LLNL of whom your friend appears
unaware, as well as Sandia Labs, Los Alamos National Laboratory, Brookhaven
National Laboratory, and Oak Ridge National Laboratory (similar
organizations), not to mention NASA and a number of NASA contractors.
Do not depend so much on folklore, rumor, and ill-informed contacts. The
facts are far more encouraging.
Cheers,
Elizabeth
--
William Tanksley
>a) I know I shall become insulted for that,
That's up to you.
>but: there exists not any big project written in Forth.
If true, this would be a good thing -- it would prove that Forth made big
projects into small ones. It's not true, though, sad to say; it's as easy
to use Forth to make a big problem out of a medium one as it is for any
other language.
The good news is that Forth makes it just as easy to go the other way. I
would go so far as to say that Forth makes it easier to go the other way
than any other language, thanks to its easy refactoring and the simplicity
of including unit tests *in* the source being compiled.
>Siegfried Gonzi
--
-William "Billy" Tanksley
cLIeNUX user
most baffling idiocy in computing, to me. Larger software projects are
built of bits and bytes. The tools for manipulating bits and bytes change
only slightly as you have more of them to deal with, and the larger tools
are of course built by the smaler ones. Excellent smaller tools have a
higher payback in programming than in anything else, in fact. More so than
bricklaying, fine art, etc., since you have a computer right there to
replicate your work limitlessly as soon as it's correct.
The related idiocy that this is usually proximate too is "well, it's good
at getting a lot out of a little." How is this ever not conducive to
getting a lot out of a lot? Never.
Continuously baffled,
Rick Hohensee
www.clieneux.com
Stephen Pelc
news:3A9E3017...@kfunigraz.ac.at...
> The last part is of interest! In the meantime I also believe that
Forth
> is not capable of handling big projects:
and Forth Inc have worked on very substantial projects. If we don't
talk about them as much as you would like, its usually because we
have a cupboard full of non-disclosure agreements ...
> a) I know I shall become insulted for that, but: there exists not any
> big project written in Forth.
If you move the goal posts far enough, you can always make that claim.
The CCS package for the contruction industry (see www.ccssa.com)
is written in ProForth for Windows and ships with about 10Mb of Forth
binary code.
> b) I sometimes read that the compilers and development environments of
> the big dealers are so bugy. For me that means, that this is not a
good
> reference for Forth, because I believe that the compilers itself are
> written in Forth -- isn't it?
If they were "bugy", the big applications like the one above could not
have been written. The fact that these have been written and are in
daily use all over the world shows that Forth is perfectly suitable for
large-scale applications.
--
Stephen Pelc, s...@mpeltd.demon.co.uk
MicroProcessor Engineering Ltd. - More Real, Less Time
133 Hill Lane, Southampton SO15 5AF, UK
tel: +44 (0)23 8063 1441, fax: +44 (0)23 8033 9691
web: http://www.mpeltd.demon.co.uk - free VFX Forth downloads!
J Thomas
> Going back to "of course it's useless for large projects", this is the
> most baffling idiocy in computing, to me. Larger software projects are
> built of bits and bytes. The tools for manipulating bits and bytes
> change only slightly as you have more of them to deal with, and the
> larger tools are of course built by the smaler ones. Excellent smaller
> tools have a higher payback in programming than in anything else, in
> fact. More so than bricklaying, fine art, etc., since you have a
> computer right there to replicate your work limitlessly as soon as it's
> correct.
Larger projects have larger management problems. Forth proponents tend
to say "That's a management problem" and dismiss it, but there are
probably ways to automate some things to palliate the management
problems. It would be good to have a good IME (Integrated Management
Environment) to help managers keep track of what's going on; so far as I
know this has not been done well anywhere, in any language or on any
platform.
Maybe part of the problem is that on a new project, there's always so
much fumbling around. You find problems you didn't expect and have to
work around them. Meanwhile the specs change. *Less* communication is
*more* comfortable. If a software manager was looking over your
shoulder, what would he see? 3 hours -- wrote Module 3. 3 hours --
tested Module 3, found 2 unexpected bugs, made corrections. 2 hours --
documented Module 3, updated archives, etc. 3 hours -- checked
archives, found that Module 3 is incompatible with Module 5 written by
somebody else. 3 hours -- discussed with someone else which module
meets the interface specs, eventually found that neither does. 2 hours
-- modify Module 3 interface. Etc. As hard as it is to bumble through
that sort of thing yourself, imagine how hard it would be to watch a
bunch of other people do it when you're responsible for them. (As a
side issue, often it's better to write the test cases first. That adds
extra steps for new projects, since you won't find the bugs in the test
code until you have the code itself ready and can find that the test
cases don't actually meet the new spec. The SEI has a lot of advice
about how to set up teams that will code right the first time. As near
as I can tell, their advice all depends on the simple rule: Never ever
do anything for the first time.)
Back on topic, consider how much easier it is for everybody, when you
can look at something that appears to be 3 hours coding, and give the
manager a 40 hour estimate. If you're actually done in 35 hours
everybody's happy. It's all much easier the third time around, when
there's a clear idea what's wanted and a lot of example code, and the
question is just to do the same things better.
Anyway, there are various scraps of project-management code written in
Forth, and various Forth systems that are compatible with foreign
version-control systems etc, but there's no common practice and nothing
to point to to say "Forth was designed to make large projects easier".
> The related idiocy that this is usually proximate too is "well, it's
> good at getting a lot out of a little." How is this ever not conducive
> to getting a lot out of a lot? Never.
Some people don't get how easy Forth is. "You have to manage your own
stack instead of having the compiler do it for you. You have to do your
own memory management. Postfix notation. Not type-safe, so it doesn't
tell you about type errors. How is this easy?" So, they see that you
can actually do things on extremely limited systems. Compiler,
interpreter, editor, assembler, cross-compiler, metacompiler in 8K.
That's compact. But they naturally believe that it's harder work for
the programmer to use the tiny systems that can work in such limited
environments. If you can let the computer do more of the work for you,
and it's easier for you that way, then you can get more out of a lot the
easy way than you could the hard way. On a crippled system there's no
other choice; on a big system there is.
So it isn't an idiocy, just a misunderstanding. 6503 assembly code can
get you a lot out of a little, but you wouldn't write a big project in
6503 assembler and use an emulator to run it on sparc stations etc. Yet
you would write code for a Forth virtual machine and use a Forth
compiler to emulate that virtual machine on something else. The
difference is that 6503 assembler is a hard way to get a lot out of a
little, while Forth is an easy way.
cLIeNUX user
Indeed. Relatively easy, anyway.
>"You have to manage your own
>stack instead of having the compiler do it for you. You have to do your
>own memory management. Postfix notation. Not type-safe, so it doesn't
>tell you about type errors. How is this easy?" So, they see that you
>can actually do things on extremely limited systems. Compiler,
>interpreter, editor, assembler, cross-compiler, metacompiler in 8K.
>That's compact. But they naturally believe that it's harder work for
>the programmer to use the tiny systems that can work in such limited
>environments. If you can let the computer do more of the work for you,
>and it's easier for you that way, then you can get more out of a lot the
>easy way than you could the hard way. On a crippled system there's no
>other choice; on a big system there is.
>
>So it isn't an idiocy, just a misunderstanding. 6503 assembly code can
>get you a lot out of a little, but you wouldn't write a big project in
>6503 assembler and use an emulator to run it on sparc stations etc. Yet
>you would write code for a Forth virtual machine and use a Forth
>compiler to emulate that virtual machine on something else. The
>difference is that 6503 assembler is a hard way to get a lot out of a
>little, while Forth is an easy way.
All true. Beautiful post, in fact. Do the major Forth vendors have RCS'es?
How do they do it in-house? Just as an aside, I quit my only stint as a
salaried programmer recently in protest over what I felt was a totally
unacceptable RCS.
There's another funny difference between the 6503 and the Forth VM. The
Forth VM is actually a higher-performance machine than the machine it is
usually running on. This makes things harder to convey, and naturally even
if one can convince someone of this they still probably have utterly
compelling reasons to not want to take a performance hit until
stack-machine hardware is prevalent. This odd bit of Forth's misfortune is
probably why Chuck does hardware. His language can't really come into it's
own on current commodity hardware. What a pain.
To sort of agree with you that it's not quite idiocy, Mike Haas said in
the JForth docs or promo materials that a file-based hosted large 32-bit
subroutine-threaded Forth retains much of the flavor of the original
language, and I can see where it's only recently, due in large part to the
Standard, that that isn't surprising.
Rick Hohensee
www.clienux.com
jbw...@pacifier.com
On 1-Mar-2001, J Thomas <jeth...@ix.netcom.com> wrote:
> > The last part is of interest! In the meantime I also believe that Forth
> > is not capable of handling big projects:
>
> > a) I know I shall become insulted for that, but: there exists not any
> > big project written in Forth.
>
> There are some. But consider -- how do you decide what a big project
> is?
Personally I think that it will take something written in Forth that becomes
really popular. Like the next Doom or Diablo. Yup, games. They get popular,
people want to create things for them, they have their own languages, kinda
sorta, and develop their own following. The next big word processor will not
likely have as big of an impact as the next "latest and greatest" game.
Jeffery
Anton Ertl
Bart Lateur <bart....@skynet.be> writes:
>Stack imbalance is typical for FORTH. One tiny error in FORTH, and not
>only will your code not produce correct results (same as in C), but
>also, chances are that you'll get a runaway program that can easily
>crash your system.
What's a crash? The typical case for a crashing Forth program is that
the program throws something (e.g., -9, "Invalid memory address"), the
Forth system catches it, prints an informative error message and a
backtrace, and I end up on whatever command-line I started the program
from. It's similar for C programs, but the error messages are not
always as informative, there is not backtrace, and the command-line I
started from is always the shell command-line.
- anton
--
M. Anton Ertl Some things have to be seen to be believed
an...@mips.complang.tuwien.ac.at Most things have to be believed to be seen
http://www.complang.tuwien.ac.at/anton/home.html
Anton Ertl
Siegfried Gonzi <siegfri...@kfunigraz.ac.at> writes:
>The last part is of interest! In the meantime I also believe that Forth
>is not capable of handling big projects:
>
>a) I know I shall become insulted for that, but: there exists not any
>big project written in Forth.
The answers to this are in three classes:
1) Counterexamples.
2) Explanations why people would be reluctant to do big projects in
Forth.
3) Claims that the same projects are smaller when written in Forth.
The last answer may be hardest to believe; so you may want to read a
paper on it: http://www.complang.tuwien.ac.at/papers/ertl99ef.ps.gz
>c) Even the guys at Smithonian A. lost interest in Forth. Why isn't
>Forth used there any longer. The answer is that they were not able to
>read the code they coded.
Well, I can read the code I wrote, even non-trivial code I wrote 12
years ago.
Jerry Avins
>
> ... I quit my only stint as a
> salaried programmer recently in protest over what I felt was a totally
> unacceptable RCS.
>
What's an RCS?
cLIeNUX user
>cLIeNUX user wrote:
>>
>> ... I quit my only stint as a
>> salaried programmer recently in protest over what I felt was a totally
>> unacceptable RCS.
>>
> ...
>
>What's an RCS?
Revision Control System. They were calling it, uh, Configuration
Management. A "source safe".
Rick Hohensee
www.clienux.com
Paul E. Bennett
> cLIeNUX user wrote:
> >
> > ... I quit my only stint as a
> > salaried programmer recently in protest over what I felt was a totally
> > unacceptable RCS.
> >
> ...
>
> What's an RCS?
Revision Control System. It is based upon controlling access to the
sources and deltas in a source repository and should be a vital part
of all software projects toolkit, along with a configuration change
management package. See sites like http://www.mks.com/ for some
examples (especially "Source Integrity" and "Track Integrity"
products from them.
--
********************************************************************
Paul E. Bennett ....................<email://p...@amleth.demon.co.uk>
Forth based HIDECS Consultancy .....<http://www.amleth.demon.co.uk/>
Mob: +44 (0)7811-639972 .........NOW AVAILABLE:- HIDECS COURSE......
Tel: +44 (0)1235-814586 .... see http://www.feabhas.com for details.
Going Forth Safely ..... EBA. www.electric-boat-association.org.uk..
********************************************************************
Nathan D. Hesterman
I'm not much of a programmer and my FORTH abilities are meager compared to
the folks I read from here at c.l.f. I do know how to type, however. I'd
like an opportunity to give what little I can back to the FORTH community.
Therefore, I am currently typing in the text from my battle-scarred 1981
edition of Starting Forth into MS Word. Its just talk so far because I've
only started this morning after reading these posts. I've typed in:
ABOUT THE AUTHOR,
FOREWORD,
ABOUT THIS BOOK,
ACKNOWLEDGEMENTS,
INTRODUCTIONS, and
1 FUNDMENTAL FORTH.
I hope to contine at the pace of one chapter a weekend. If I really do have
the commitment, I will add the cartoon characters and formatting afterward.
I would not presume to know enough to update the technical aspects so,
currently, the transcription is verbatim. Please e-mail me if you would
like to update the chapter texts as they are completed.
I have some questions, however. Is it legal to update this book? Am I
duplicating work that has already been accomplished? Thanks for your help.
Nathan Hesterman
NHest...@compuserve.com
"Marcel Hendrix" <m.a.m....@nl.cis.philips.com> wrote in message
news:98338195...@dibbs3.eur.cis.philips.com...
> "Bernd Paysan" <bpa...@mikron.de> wrote in message
news:3A9CED69...@mikron.de...
> > I'd also volunteer to coordinate a public effort to get SF into shape
> > for this new millennium - the examples have to be adapted, a few new
> > chapters and several new footnotes have to be written. Also, the
> > examples have to undergo a quality control: examples written in a
> > beginner's book should run on as many Forth systems as possible without
> > modifications, to avoid frustration. Thomas Baierlein volunteered (two
> > years ago) to write tutorial text, but refused to duplicate SF.
>
> I'd like to volunteer too. What chapter do you need first?
>
> -marcel
>
>
>
Jerry Avins
I understand the process, and subscribe to it with one proviso: that I
can check out a piece of [my] code and do what I will with it
(compiling, editing, recompiling, annotating, etc.) freely until I check
it in again. I find the systems that insist on recording every thought
and alteration very much like videotape in the men's room: an inhibiting
invasion of privacy. Moreover, they waste too much storage.
Jerry Avins
community have taken it to heart, the book remains subject to copyright.
The mere reproduction and distribution of the original might not please
the owners. Perhaps you should ask permission.
Jerry
--
Engineering is the art of making what you want from things you can get.
-----------------------------------------------------------------------
Elizabeth D. Rather
> Hi,
>
> I'm not much of a programmer and my FORTH abilities are meager compared to
> the folks I read from here at c.l.f. I do know how to type, however. I'd
> like an opportunity to give what little I can back to the FORTH community.
> Therefore, I am currently typing in the text from my battle-scarred 1981
> edition of Starting Forth into MS Word. Its just talk so far because I've
> only started this morning after reading these posts. I've typed in:
>
> ABOUT THE AUTHOR,
> FOREWORD,
> ABOUT THIS BOOK,
> ACKNOWLEDGEMENTS,
> INTRODUCTIONS, and
> 1 FUNDMENTAL FORTH.
>
> I hope to contine at the pace of one chapter a weekend. If I really do have
> the commitment, I will add the cartoon characters and formatting afterward.
> I would not presume to know enough to update the technical aspects so,
> currently, the transcription is verbatim. Please e-mail me if you would
> like to update the chapter texts as they are completed.
>
> I have some questions, however. Is it legal to update this book? Am I
> duplicating work that has already been accomplished? Thanks for your help.
>
> Nathan Hesterman
> NHest...@compuserve.com
Whereas I applaud your enthusiasm, I'm afraid this particular effort is
misplaced. In the first place, SF was updated in 1986 to the Forth83 standard,
and that version would be a better place to start. In the second place, the
book is copyrighted; FORTH, Inc. owns the copyright.
The 1986 ed. has been scanned, and although that effort was only partly
successful for a variety of reasons, typing the text isn't the big roadblock to
a new edition. The time-consuming part is writing new text to replace that
which is obsolete or misleading as to the current state of Forth technology.
Thanks anyway,
Elizabeth
--
================================================
Elizabeth D. Rather (US & Canada) 800-55-FORTH
FORTH Inc. +1 310-491-3356
Nathan D. Hesterman
it drop after this observation unless someone more worldly wants to proceed.
To me it seems:
1. The FORTH community here believe that Starting Forth is an excellent
introductory manual for exposing new people to FORTH. (Its what grabbed me,
too.)
2. The FORTH community worries about the lack of new people using FORTH.
3. The book is not up-to-date and is out-of-print.
4. There are many volunteers here willing to illustrate it, update it, and
edit it for free.
5. FORTH, Inc. can advertise SwiftForth in it as previously polyFORTH was
advertised. They can also advertise their more advanced books for those
desiring more information.
So, it seems a win-win situation for everyone involved. Newbies interested
in learning FORTH will have an excellent and compelling introduction to its
ways. FORTH Inc, is given a free book (or .pdf or web-site, etc.) to sell
(or give) which advertises their products. The FORTH community will have an
up-to-date bible extolling the language's virtues.
Thanks for listening.
Naive Nathan
"Elizabeth D. Rather" <era...@forth.com> wrote in message
news:3AA2D88C...@forth.com...
Marcel Hendrix
> "Nathan D. Hesterman" wrote:
>
>> the folks I read from here at c.l.f. I do know how to type, however. I'd
>> like an opportunity to give what little I can back to the FORTH community.
>> I have some questions, however. Is it legal to update this book? Am I
>> duplicating work that has already been accomplished? Thanks for your help.
> Whereas I applaud your enthusiasm, I'm afraid this particular effort is
> misplaced. In the first place, SF was updated in 1986 to the Forth83 standard,
> and that version would be a better place to start. In the second place, the
> book is copyrighted; FORTH, Inc. owns the copyright.
So you don't right-out disapprove of this initiative?
As Nathan says in another post this should be a win-win situation.
Could you please outline acceptable conditions (to Forth Inc.) for a
rewriting effort?
> The 1986 ed. has been scanned, and although that effort was only partly
> successful for a variety of reasons, typing the text isn't the big roadblock to
> a new edition. The time-consuming part is writing new text to replace that
> which is obsolete or misleading as to the current state of Forth technology.
I think that is clear.
An important design decision is the Forth system used in the text. It would
work best to never have to say "this may or may not work on the Forth you're
using now." IMHO a specially written SF Forth to illustrate matters is a
bad idea - first impressions last longest. It should be a top-notch system.
-marcel
Andrew Haley
> I guess that there is a lot going on here that I'm not seeing. I will let
> it drop after this observation unless someone more worldly wants to proceed.
> To me it seems:
> 4. There are many volunteers here willing to illustrate it, update it, and
> edit it for free.
That doesn't help. It is far from certain that anyone in the
community has adequate skills to do this. Starting FORTH was the
collaboration of a very imaginative writer and te best Forth minds in
the business. Without people of the calibre of Leo Brodie and Dean
Sanderson et al there would be no point trying.
Andrew.
Stephen Pelc
cLIeNUX user <r@your_host.com> wrote in message
news:ta0mjje...@corp.supernews.com...
> All true. Beautiful post, in fact. Do the major Forth vendors have
RCS'es?
the sources were held under revision control using ClearCase. No
problems.
There was also a paper at EuroForth 2000 by Michael Milendorf about
Sun's software management process for Open Firmware.
As far as I can tell, there is no conflict between Forth and RCS use,
except
perhaps for those people using blocks/screens for source code and
old-style
RCS systems that required RCS strings in the source code.
Michael Coughlin
<3A9E9CDD...@forth.com> :
>Siegfried Gonzi wrote:
>Roger Hauck at the Smithsonian Astrophysics
>Laboratory is a current and active user of
>both SwiftForth and our SwiftX cross-compiler
>(for the RAD-hard UT69R000 processor, being
>used in a NASA project). Several other
>observatories are also current users. As to
>readability, we have customers who have been
>using, extending, and maintaining their Forth
>projects for 20 years, porting to new
>platforms as needed, and extol the
>maintainability and readability of their
>Forth code.
I know Roger Hauck since we are both fans
of Forth. I went to him last year and told him
about the new textbooks from Forth, Inc. since
I expected he would have the library at SAO
order them so I could read them. I was very
surprised when he wasn't interested and said
he hadn't looked at many new Forth textbooks
lately. I told him he couldn't look at many new
Forth textbooks since there weren't any. Is
there anyone else at SAO who uses Forth
currently? I know someone there who wants to
update an old program and I can't do it since
I don't want to learn to use the VAX/VMS
operating system.
>> What I want to express is, that there will
>> be no more programmers in Forth at the
>> really important institutions (like LLNL),
>> even if there are many books at bookstores.
>> I think Forther deceives oneself too
>> often...
>We also have several active customers at LLNL
>of whom your friend appears unaware, as well
>as Sandia Labs, Los Alamos National Laboratory, Brookhaven
>National Laboratory, and Oak Ridge National
>Laboratory (similar organizations), not to
>mention NASA and a number of NASA contractors.
>Do not depend so much on folklore, rumor, and
>ill-informed contacts. The facts are far more
>encouraging.
If you come across anyone at these
institutions who has published scientific
research using Forth code, please let me know
where to find their articles since I like to
have concrete examples to show people who
laugh at me when I tell them they should be
using Forth.
--
Michael Coughlin m-cou...@ne.mediaone.net Cambridge, MA USA
_______________________________________________
Submitted via WebNewsReader of http://www.interbulletin.com
Michael Coughlin
My usual reading and posting service is not
working, so I am trying something completely
different.
Siegfried Gonzi <siegfri...@kfunigraz.ac.at> wrote in article
<3A9E3017...@kfunigraz.ac.at> :
[snip]
> In the meantime I also believe that Forth
>is not capable of handling big projects:
>
>a) I know I shall become insulted for that, but
> there exists not any big project written in
> Forth.
I write about this frequently. I don't
remember getting involved in insults, but I
certainly get involved in many heated debates.
An oversimplified view is that Forth is very
suitable for writing big projects, but Forth
programmers are not. Their biggest weakness is
writing documentation and well commented code.
This is a problem with every kind of computer
language. Forth helps programmers write code,
but it doesn't help with writing the
documentation.
>b) I sometimes read that the compilers and
>development environments of the big dealers
>are so bugy. For me that means, that this is
>not a good reference for Forth, because I
>believe that the compilers itself are
>written in Forth -- isn't it?
I've known many Forth vendors and devlopers
over the years. They tell me everything they
think is wrong with Forth. They don't complain
about bugs in Forth implementations. They always
complain about everything else. They certainly
complain about bugs in compilers for other
languages, especially the ones from large
software companies.
Forth systems are written in Forth and come
with source code. A good Forth programmer can
find any bugs, and fix them himself. Forth
vendors do the same job even better than their
customers.
>c) Even the guys at Smithonian A. lost
>interest in Forth. Why isn't Forth used there
>any longer. The answer is that they were not
>able to read the code they coded.
You are talking about the place where I first
learned about Forth. You are absolutely right.
By 1982 projects were cancelled and Forth
programmers left Smithsonian Astrophysical
Observatory (my local neighborhood scientific
research organization) because they could not
read their own code.
>What I want to express is, that there will be
>no more programmers in Forth at the really
>important institutions (like LLNL), even if
>there any books at bookstores. I think Forther
>deceives oneself too often...
The responses to this messages show your
points very well. Examples are given of
successful big Forth projects include systems
that are running on obsolete hardware in out
of the way places. If they were really
successful, they would be running on the latest
computers all over the world. There are other
examples given that are hidden where few people
would see them instead of being so important
that you couldn't avoid seeing them.
When I meet people who could profitable use
Forth in their work, I always ask them why they
don't use it. Often they know something about
Forth from the old days and they say "Forth is
unreadable." Instead of finding ways to meet
this problem, you'll find the advocates of Forth
endlessly debating what new Forth words to
define, finding faster ways to compile Forth
code and tinkering around with the fundamental
design of the language itself. It leads to lots
of interesting debate, but hardly any big Forth
applications.
Paul E. Bennett
> I understand the process, and subscribe to it with one proviso: that I
> can check out a piece of [my] code and do what I will with it
> (compiling, editing, recompiling, annotating, etc.) freely until I check
> it in again. I find the systems that insist on recording every thought
> and alteration very much like videotape in the men's room: an inhibiting
> invasion of privacy. Moreover, they waste too much storage.
I agree that some can seem to be very over-bearing. However, the MKS
set-up uses the notion of "Sandboxes" and if the system admin has
done its job properly you should find you have enough freedom to
check out a copy of your code, play around with it in the sandbox
(or another sandbox on another system) and post it back in for review
when your done. In the meantime, everyone else is using your old code
and will continue to do so until they are told that your new version
is cleared.
It is possible to have your code being worked on by several people
at the same time (for different reasons) and that brings its own
headache when you need to merge the updates. Very few RCS systems
are able to manage that feat very well.
Bernd Paysan
> To you and a handful of other people in this world, and I salute you all.
>
> But to the vast majority of folks like Bart and me, who don't understand
> gcc's internals but can feed C code in and get compiled applications out,
> gcc _is_ a black box. So is any language implementation, to the vast
> majority of its users.
For me, GCC is a big black box. There's a small part of GCC that's well
documented, that's the machine description file. I had the pleasure to
use GCC on a target where the port was broken (it was the SHARC port
from Analog Devices). Luckily, the bug was in the .md file, and I was
able to fix in within a few days. But the generic part of GCC is huge,
ugly, and not well documented.
I've thought about a GCC backend for my 4stack processor now and then,
and I've concluded that the only way is to write a sort-of generic
backend, and do the real stuff outside of GCC, because GCC is neither
appropriate for the task (scheduling instructions for a VLIW and
allocating registers on a stack), nor is changing GCC (outside the .md
realm) obvious and easy. The way GCC generates optimized code is better
suited for CISCs, and the way GCC allocates registers is sub-standard,
anyway (and better suited for RISCs). Ok, lately, someone added SSA to
GCC, but I haven't looked at it.
For GCC maintainers who know a lot of the code (and it's megabytes of
it), things are certainly different, but there's a huge difference
between fiddling with a Forth compiler and fiddling with a C compiler,
even one as open as GCC.
--
Bernd Paysan
"If you want it done right, you have to do it yourself"
http://www.jwdt.com/~paysan/
Bernd Paysan
> a) I know I shall become insulted for that, but: there exists not any
> big project written in Forth.
Now you have to define what's a big program. IMHO, Motif is a big
program. It consists of a hundret megabytes source, and compiles down to
a library with several megabytes binaries; it also relies on another
megabyte-library, libXt. Now, if you clone the functionality of Motif
(i.e. a general purpose GUI widget library), have you written a big
program? Yes! MINOS does about everything you want from Motif, and has
even some parts you need additional code for with Motif (like OpenGL
widgets). Yet, MINOS is just about 400 screens, and compiles to a bit
more than 100k binary, and no 300, but only one programmer wrote it. And
those 400 screens contain a Windows port, while Motif does only run on
X.
There are other projects which are even larger than that, like the Riad
Airport project from Forth Inc. Elizabeth can tell you more about that.
Forth is not suitable for big programs, because Forth programs all tend
to stay relatively small. Good programming languages provide means for
compressing, and Forth is much better than common languages in this
discipline.
Forth is not widely used, because it doesn't resemble the other widely
used languages, and there is no large enough niche where it's features
are needed so much that it gains a lot of market share there. Forth
programmers are "crazy" (in the eyes of ordinary programmers), because
they use something different for apparently no reason. We share that
with users of other "crazy" languages, like Lisp or Smalltalk.
Bernd Paysan
> All true. Beautiful post, in fact. Do the major Forth vendors have RCS'es?
> How do they do it in-house? Just as an aside, I quit my only stint as a
> salaried programmer recently in protest over what I felt was a totally
> unacceptable RCS.
We (the Gforth team) use CVS as revision control system. It works fine,
but using it for blocks is not so nice (CVS doesn't yet support an easy
way to convert input and output on the fly, and storing blocks as
binaries is not really what you want).
> There's another funny difference between the 6503 and the Forth VM. The
> Forth VM is actually a higher-performance machine than the machine it is
> usually running on. This makes things harder to convey, and naturally even
> if one can convince someone of this they still probably have utterly
> compelling reasons to not want to take a performance hit until
> stack-machine hardware is prevalent. This odd bit of Forth's misfortune is
> probably why Chuck does hardware. His language can't really come into it's
> own on current commodity hardware. What a pain.
You can run Forth fast on conventional hardware. I think Chuck does
hardware, because he doesn't like the bloat that goes into current
hardware. I remember that in a comp.arch discussion in 1993, I said that
superscalar, out of order execution doesn't scale well, i.e. you add
tons of transistors to get only a small effect of acceleration; the
result of this development will be power-hungry, expensive monsters.
Back then, few people agreed, because back then, they had just started
with OOO execution, and it did well compaired to non-superscalar CPUs
(or to superscalar, in-order execution CPUs). On the latest
processor-related conference just a few weeks ago, they all said
"superscalar doesn't scale", and "did we create monsters?".
Bernd Paysan
>
> "Bernd Paysan" <bpa...@mikron.de> wrote in message news:3A9CED69...@mikron.de...
> > I'd also volunteer to coordinate a public effort to get SF into shape
> > for this new millennium - the examples have to be adapted, a few new
> > chapters and several new footnotes have to be written. Also, the
> > examples have to undergo a quality control: examples written in a
> > beginner's book should run on as many Forth systems as possible without
> > modifications, to avoid frustration. Thomas Baierlein volunteered (two
> > years ago) to write tutorial text, but refused to duplicate SF.
>
> I'd like to volunteer too. What chapter do you need first?
Hans Bezemer volunteered to port his 4th introduction to ANS Forth, and
he's halfways through. So, the introductionary material is - or will be
- there. What I'm looking for is to have small, well-explained examples
that do somewhat advanced things. My mini-OOF and my HTML server are
written for that purpose; the HTML server however now has the
disadvantage that it runs only on Gforth. The descriptions are probably
also too terse for novices.
I'll check Hans' introduction, and I'm quite sure I'll find something to
add. You might probably want to write about floating point, and provide
some interesting examples.
All contributions will be available under the GNU FDL, and the authors
will be named on the title page.
Jerry Avins
>
...
>
> It is possible to have your code being worked on by several people
> at the same time (for different reasons) and that brings its own
> headache when you need to merge the updates. Very few RCS systems
> are able to manage that feat very well.
>
> --
OK. Don't do it.
m_l...@my-deja.com
> >c) Even the guys at Smithonian A. lost interest in Forth. Why isn't
> >Forth used there any longer. The answer is that they were not able to
> >read the code they coded.
>
> Well, I can read the code I wrote, even non-trivial code I wrote 12
> years ago.
1) It is good to read small Forth programs starting from the end.
2) it is good to read big Forth programs via the Find-in-Files
command (I use FAR, but any Commander (Midnight, Norton, Volkov)
or even grep would probably do). The good thing about FAR is that
Find (in file) remembers the strings (several recently used ones) that
were used in Find-in-Files, and vice versa.
It is indeed in most cases stupid to read Forth programs from the very
beginning... just as with any other language.
(Unless the first lines contain docs.)
cLIeNUX user
>
>You can run Forth fast on conventional hardware. I think Chuck does
Not as fast as on Forth hardware, yes?
>hardware, because he doesn't like the bloat that goes into current
>hardware. I remember that in a comp.arch discussion in 1993, I said that
>superscalar, out of order execution doesn't scale well, i.e. you add
>tons of transistors to get only a small effect of acceleration; the
>result of this development will be power-hungry, expensive monsters.
>Back then, few people agreed, because back then, they had just started
>with OOO execution, and it did well compaired to non-superscalar CPUs
>(or to superscalar, in-order execution CPUs). On the latest
>processor-related conference just a few weeks ago, they all said
>"superscalar doesn't scale", and "did we create monsters?".
>
>--
>Bernd Paysan
>"If you want it done right, you have to do it yourself"
>http://www.jwdt.com/~paysan/
Rick
J Thomas
> Siegfried Gonzi <siegfri...@kfunigraz.ac.at> wrote in article
> >c) Even the guys at Smithonian A. lost
> >interest in Forth. Why isn't Forth used there
> >any longer. The answer is that they were not
> >able to read the code they coded.
> You are talking about the place where I first
> learned about Forth. You are absolutely right.
> By 1982 projects were cancelled and Forth
> programmers left Smithsonian Astrophysical
> Observatory (my local neighborhood scientific
> research organization) because they could not
> read their own code.
So you were there. Could you give any more details about
what happened and how this claim came about? How was it
determined that the programmers couldn't read their own
code? Was it all the Forth programmers there who were
shown to be unable to read their code, or only some of
them? What exactly was it that happened?
Paul E. Bennett
donot...@interbulletin.bogus "Michael Coughlin" writes:
[%X]
> >What I want to express is, that there will be
> >no more programmers in Forth at the really
> >important institutions (like LLNL), even if
> >there any books at bookstores. I think Forther
> >deceives oneself too often...
>
> The responses to this messages show your
> points very well. Examples are given of
> successful big Forth projects include systems
> that are running on obsolete hardware in out
> of the way places. If they were really
> successful, they would be running on the latest
> computers all over the world. There are other
> examples given that are hidden where few people
> would see them instead of being so important
> that you couldn't avoid seeing them.
This is where Elizabeth should step in and relate the tale she
told me over dinner in London one night. Old DEC hardware running
Forth and they were concerned over upgrading the processors or
changing them. Fact was they could have probably done so with
quite comparative ease. Anyway, Elizabeth you know all the details
of this ***Really Big Project***.
> When I meet people who could profitable use
> Forth in their work, I always ask them why they
> don't use it. Often they know something about
> Forth from the old days and they say "Forth is
> unreadable." Instead of finding ways to meet
> this problem, you'll find the advocates of Forth
> endlessly debating what new Forth words to
> define, finding faster ways to compile Forth
> code and tinkering around with the fundamental
> design of the language itself. It leads to lots
> of interesting debate, but hardly any big Forth
> applications.
The answer is to make it more readable by using good standards of
coding practice and levels of documentation. The majority of the
documentation should actually precede the coding anyway.
Bernd Paysan
>
> humb...@smart.net
> >
> >You can run Forth fast on conventional hardware. I think Chuck does
>
> Not as fast as on Forth hardware, yes?
That's somewhat a tradeoff consideration. Chuck can use only outdated
processes, because his funding isn't very good. Even though he does an
excellent job at tuning these outdated processes, process shrinks do
better. Then you can run Forth faster on an Athlon than on Chucks Forth
processors. That's an unfair comparison, because the Athlon is in 0.18u
copper, and the uP21 is in 0.8u, the Athlon has 128k ultra-fast internal
L1 cache and 256k very fast internal L2 cache (enough for many
reasonable Forth programs), and the uP21 has only external RAM. Also,
the Athlon burns a lot more power, and costs (in volume) a lot more;
each time think of a factor of 1000. The conclusion is that all this
expensive technology doesn't scale well. It does provide some
improvements over "keep it simple", but not much, and at high costs. If
you just look at speed, the Athlon wins.
Anton Ertl
Bernd Paysan <bernd....@gmx.de> writes:
>- there. What I'm looking for is to have small, well-explained examples
>that do somewhat advanced things.
Not sure about well-explained, but certainly advanced: Sections
"Advanced macros Tutorial" and "Advanced does> usage example" in the
Gforth manual.
a...@redhat.invalid
: It is possible to have your code being worked on by several people
: at the same time (for different reasons) and that brings its own
: headache when you need to merge the updates. Very few RCS systems
: are able to manage that feat very well.
Oh, I don't know. CVS does this fairly well, but most merge problems
occur when people have made incompatible changes, and there's no
source control system that can automatically fix that; it's a
management problem.
In the free software world it often happens that a group works on a
large project that they don't tell anyone about (perhaps because of an
NDA) and later have to merge into the main sources. It can't be
helped.
Andrew.
Jeff Fox
> > Not as fast as on Forth hardware, yes?
>
> That's somewhat a tradeoff consideration. Chuck can use only outdated
> processes, because his funding isn't very good.
It would be more accurate to say that in past Chuck's funding mandated
the use of older processes. People with .18u fabs are making offers
to fund and produce. At the moment Chuck isn't using any process but
it is not very accurate to say that "he can use only outdated
processes."
That makes it sound like there is something flawed in his approach
that makes it only work on outdated technology.
> Even though he does an
> excellent job at tuning these outdated processes, process shrinks do
> better.
Chuck's finer tuning is roughly equivalent to two process shrinks and
independent of process shrinks. So Chuck's old .8u designs perform
about like other designs in .35u. A couple more shrinks down to .18u
does do better than a 10x improvement in tuning efficiency.
But if you are going to do a comparison, and not comparing Chuck's early
prototype chips to current production chips you need to level the
process
and the transistor count. There are several companies fighting over
which will take the chips to .18u and combine it with the two other
factors, the higher tuning and opportunity for parallelism from
the lower transistor counts.
To be fair you need to compare in the same process. To be fair you
need to compare similar cost designs. An Athlon is not the
equivalent of one .8u Forth chip. It can do some things faster and
some things slower. But to level the playing field people are
looking at comparing a .18u Athlon to a .18u Forth design with 100
processing nodes. So you have a 5x to 10x tuning factor and a
100x scale factor.
> Then you can run Forth faster on an Athlon than on Chucks Forth
> processors.
For some things yes. For somethings no. Even the old stuff can
still beat an Athlon on some things.
A 900 Mhz Athlon is certainly not faster than 100 500Mhz processors
on very many things. Really the Athlon needs to be compared to
100 multigigahertz Forth processors to be fair. I think it more fair
to compare units of equal size and cost, or if not to include
cost and power consumption in the comparison since they are
factors in the real work.
One of these Forth chips is not intended to replace something
like an Athlon. The idea is that if you are going to spend that
kind of money you will get 100 x000Mhz Forth processors instead
of 1 big expensive power hungry Athlon. That is what is meant to
compare to or compete against Athlon.
For widgets, appliances, and devices with embedded processors then
a single processor does make sense but then the Athlon is out of
the question as it is intended for desktops or laptops not cheap
consumer devices.
> That's an unfair comparison, because the Athlon is in 0.18u
> copper, and the uP21 is in 0.8u,
MuP21 was 1.2u. 1992-1994 so deserves comparison to chips that
were about the same speed back then. F21 and I21 prototypes, and
some others, were in .8u going back six years now. To make
comparisons today .35u is starting to look old. It has been a
few years since any prototypes were made. .18u and .08u
change the numbers quite a bit. .18u is not only faster but
also means that more than 16 processors are the size of one processor
in .8u.
> the Athlon has 128k ultra-fast internal
> L1 cache and 256k very fast internal L2 cache (enough for many
> reasonable Forth programs),
Yes, many of those millions of transistors are cache, it is a
requirement. As noted in Koopman's book the compactness of
Forth processor code means that the Forth processor version of
the program is often smaller than just the cache required for a
RISC or CISC machine. The code is also more compact now with the
MISC architecture than it was when Phil wrote the book, most
words compile to five bits.
>and the uP21 has only external RAM.
MuP21 had only external memory, but Chuck has done on chip memory
on some designs. It is just a design choice tradeoff.
> Also,
> the Athlon burns a lot more power, and costs (in volume) a lot more;
> each time think of a factor of 1000. The conclusion is that all this
> expensive technology doesn't scale well.
I agree. The reason the PC doesn't scale well is that a single node
requires so many millions of transistors that it is big and expensive.
A few hundred mips costs a few hundred dollars so scaling up to say
100 or 1000 nodes becomes prohibatively expensive for most people. A
few
people with government funded projects get these multiprocessing
workstation farms but the average computer user would never
consider networking 100 or 1000 PCs as their personal computer.
By scaling the nodes down by a factor of 100 what someone would consider
reasonable to pay for a personal computer can have 100 nodes that each
outperform an Athlon on Forth.
PCs also carry extra weight at every level because of hardware
and software backwards compatiblity issues that also make scaling
lose efficiency.
> It does provide some
> improvements over "keep it simple", but not much, and at high costs. If
> you just look at speed, the Athlon wins.
If you compare today's Athelons to five or seven year old prototype
chips
and if you don't level the cost, power consumption, or software overhead
factors then an Athlon does indeed win.
The BIG win is that it is conventional and people understand it
and think of it first. You can buy Athlons off the shelf in
various products. If you had to get prototype Athlon chips from
the source and engineer your own computers and write your own
software they would be useless to most people. The real win is that
they are off the shelf consumer technology. Chuck has not produced
any consumer computers that were produced, and there are only a few
people involved in the development at the present time.
Jeff Fox
cLIeNUX user
>>and the uP21 has only external RAM.
>
>MuP21 had only external memory, but Chuck has done on chip memory
>on some designs. It is just a design choice tradeoff.
Rick
Heh. What about the stacks? That's cache, in a much more sensible layout.
Which is why, at any reasonably balanced comparison, stack machines win.
Philip Preston
<983791714.7903.0...@news.demon.co.uk>...
What dismal advice! Of course there is a point in trying, even if there is
no guarantee of success. My only word of caution would be that there is a
tendency for people to embark on such collaborative projects with more
enthusiasm than stamina, so try to arrange things so that if a key
participant loses interest it doesn't kill off the entire project and waste
other people's efforts.
Regards,
Philip.
Michael Coughlin
<3AA44365...@ix.netcom.com> :
Well, there's not much to tell. There have been many
projects in many languages that have failed and the
inability of programmers to read their own code is a
common reason. At the Smithsonian Astrophysical Observatory
(which is combined with Harvard College Observatory,
in Cambridge, MA USA) in 1980 there were several (many?)
programmers who used Forth. There were telescopes that were
controled by Forth programs running on min-computers and
Forth was used to reduce and display Astronomical images.
I only met the two programmers who wrote the image programs
very briefly when they demonstrated their system. A year or
two later when I wanted to find out how the project had
progressed (with the hope of working on it myself) I was
told that the project was re-written and the Forth
programmers fired or encourged to find employment elsewhere.
My informant insisted that Forth is inherently unreadable and
every project using it must fail. When I tried to suggest
the problem was due to poor management and Forth is a good
language, I suddently realized that I might be talking to
someone who was involved with managing the project, and
such reasoning would not be convincing.
By 1990 the Forth systems I had seen running ten years ago
had been replaced by new hardware that used Uinx/C code. There
were still some programmers who knew what Forth was and might
be favorable to using it. There were also programmers who would
become very annoyed if I mentioned Forth to them. Today I only
know of one programmer at SAO who could write Forth programs,
and he is very busy working on programs not written in Forth.
My spies tell me Forth is still used in Astronomy, but only
hiding in places where it is not visible.
I have met several people from other companies who used and
even liked Forth in the early 1980's. Those who I did not meet
from my local fig chapter all tell me the unreadablilty of Forth
is the main reason they don't use it today. As a broad generality,
I'd say that Forth programmers are less concerned with with
writing code that other people could read than any other group
of programmers. This is very unfortunate since the unique qualities
of Forth that give it power need the most attention to making its
code readable.
a...@redhat.invalid
:>FORTH was the collaboration of a very imaginative writer and te best
:>Forth minds in the business. Without people of the calibre of Leo
:>Brodie and Dean Sanderson et al there would be no point trying.
: What dismal advice! Of course there is a point in trying
I didn't say there was no point trying. However, there's no point
trying unless the people involved have the skills and commitment.
Maybe there are some people in the community who could do it.
Starting FORTH is IMO one of the very best books ever written about
programming, and that surely is due to the circumstances that led to
its creation: a gifted writer with the support of the best programmers
at FORTH Inc.
I'd be happy to be proved wrong, of course!
Andrew.
J Thomas
> J Thomas <jeth...@ix.netcom.com> wrote in article
> >So you were there. Could you give any more details about
> >what happened and how this claim came about? How was it
> >determined that the programmers couldn't read their own
> >code? Was it all the Forth programmers there who were
> >shown to be unable to read their code, or only some of
> >them? What exactly was it that happened?
> Well, there's not much to tell. [....]
> At the Smithsonian Astrophysical Observatory
> (which is combined with Harvard College Observatory,
> in Cambridge, MA USA) in 1980 there were several (many?)
> programmers who used Forth. There were telescopes that were
> controled by Forth programs running on min-computers and
> Forth was used to reduce and display Astronomical images.
> I only met the two programmers who wrote the image programs
> very briefly when they demonstrated their system.
OK, it was two programmers.
> A year or
> two later when I wanted to find out how the project had
> progressed (with the hope of working on it myself) I was
> told that the project was re-written and the Forth
> programmers fired or encourged to find employment elsewhere.
> My informant insisted that Forth is inherently unreadable and
> every project using it must fail. When I tried to suggest
> the problem was due to poor management and Forth is a good
> language, I suddently realized that I might be talking to
> someone who was involved with managing the project, and
> such reasoning would not be convincing.
So you heard it from somebody who might have been a manager.
It occurs to me that once this canard spread widely among managers, it
would brcome the default claim when dismantling Forth projects. I'm
sure there's a default thing to say when dismantling Cobol projects, and
I suspect it would be "We don't have an investment in this legacy code,
we have a *liability*. It costs more to maintain it than it will cost
to rewrite it.". I wonder if people here know the default claims for
dropping Smalltalk, Lisp, Java, etc? I can imagine that you'd probably
get rid of C programmers by saying "They aren't really in tune with OO
design, their C++ code still looks like C.".
There are lots of reasons to change languages, and I suspect the *main*
reason would be a change in management. A new manager coming in wants
things done his way, not "the way we've always done it", and switching
languages while firing staff is an obvious way to accomplish that.
This thing of managers firing Forth programmers and claiming "they
couldn't read their own code" is certainly something that happens. I
can think of four examples off the top of my head that I've heard about
in the last ten years or so, and in each the wording was almost
identical. Each time I've heard it, the manager also required a
language change for his new programmers.
I contend that it's useless for us to take this at face value. If you
were called on to explain random bits of your code to a manager who
wanted you to fail, could you do so? Could a C++ programmer or a Java
programmer or a Cobol programmer? But in management circles, this is
enough excuse to fire a Forth programmer. Nothing more need be said.
> [....] Today I only
> know of one programmer at SAO who could write Forth programs,
> and he is very busy working on programs not written in Forth.
Same here. It might be the same guy.
> I have met several people from other companies who used and
> even liked Forth in the early 1980's. Those who I did not meet
> from my local fig chapter all tell me the unreadablilty of Forth
> is the main reason they don't use it today.
Actually, the majority of the ones I met told me they got promoted out
of doing any programming at all.
> As a broad generality,
> I'd say that Forth programmers are less concerned with
> writing code that other people could read than any other group
> of programmers. This is very unfortunate since the unique qualities
> of Forth that give it power need the most attention to making its
> code readable.
Writing readable code is certainly important, and we've discussed a lot
of techniques to make that easier. People have their favorite
commenting methods and their favorite indenting methods. Choosing good
names is a useful skill that nobody has a lot of pointers about. We
have Forth source code as hypertext so you can click to get comments,
and Forth source as LaTex, "literate programming". Some years ago there
was a surge of popularity for making the coments be the standard text
and putting the source code in { } -- which is easy if it's OK to put a
} at the beginning of each file. There have been suggestions to compile
the file from the back forward, so you can easily have the highest-level
code at the front. I wouldn't be surprised if comp.lang.forth has a
higher proportion of posts about readability than any other comp.*
newsgroup.
But I think we should assume that the managers who fire Forth
programmers for writing unreadable code are not being completely
straighforward. They have the possibility of lawsuits to consider,
etc. Possibly some of the people who used to like Forth but now say
it's unreadable are also not being completely straightforward, maybe
some of them are really saying "My manager tells me that Forth is
unreadable and I support my boss, drunk or sober.".
No matter how much effort we put into readability, that will do nothing
to convince mangaers who don't want to be convinced. Could we make a
technological solution? Say we wrote something in Forth that made Forth
code dramatically more readable. I'll call this hypothetical something
"Holon" although I haven't tried Holon enough to tell whether it
improves readability. That might work -- once. If you had a manager
who was ready to be persuaded, he might say "*Forth* is inherently
unreadable, but Forth+Holon is just great! I'll do it!". But as soon
as he got replaced the new manager would surely say "Holon is no more
readable than Forth is, these Holon programmers can't read their own
code, they're gone."
So if we wanted a place for Forth working under normal managers, we'd
need to find a way to make Forth more *invasive*. We'd need to get it
spreading to new shops faster than it gets removed from existing shops.
It probably will be removed each time management shifts, so we need it
to come *in* more often when management shifts too.
There are lots of ways Forth could get a specialty niche in more shops,
but here's one I think might have a chance. Get some people
concentrating on making it easy to call C and C++ from Forth and vice
versa, and also easy to call high-level scripting languages from Forth
and vice versa. Find managers who're just being installed and persuade
them that Forth can be a good low-level scripting language, useful for
prototyping and testing. Then if given the chance, write a quick
prototype in Forth plus some scripting language (or Forth alone if the
scripting language doesn't give enough advantage for GUI etc). Use the
prototype to help iron out problems with the specs. As the C/C++
programmers get things working, integrate them into the prototype and
test them. At the end there will be a project completely written in C
(or C + scripting language); all the Forth scaffolding will be taken
down. Nobody should care whether your Forth code is readable if they
don't have to read or maintain it. If the project is late then they may
have to send out a product that still has some Forth, but they don't
have to tell anybody except their maintenance people they've done so.
Even after they have it all in C and maintain it in C there may be a
place for Forth in testing the C code; they may be able to write test
harnesses much faster in Forth than in C.
The tools I suggested have been discussed before. I gather that both
the major Forth vendors supply everything that could be desired and also
iForth supplies much if not all of this functionality. I would like to
see this done public-domain also, because that spreads the word faster.
It can establish common practice. Alternatively it can encourage people
to try different approaches and compare them. People who wouldn't buy a
commercial Forth or wouldn't take the time to learn those particular
documented abilities would play with a free version. And if a public
domain Forth or multiple public domain Forths do it, we can say that
Forth does it. If SwiftForth does it we can only say that SwiftForth
does it, which is still very good but is not as useful for persuading
incoming managers that Forth can do what I claim.
If we could get to the point that there was one Forth-user in half the C
shops, and there was an incoming manager who wanted a Forth
prototyping/testing guy one place for each incoming manager somewhere
else who wanted to fire the Forth guy, we'd be doing pretty well.
Elizabeth D. Rather
> >> What I want to express is, that there will
> >> be no more programmers in Forth at the
> >> really important institutions (like LLNL),
> >> even if there are many books at bookstores.
> >> I think Forther deceives oneself too
> >> often...
>
> >We also have several active customers at LLNL
> >of whom your friend appears unaware, as well
> >as Sandia Labs, Los Alamos National Laboratory, Brookhaven
> >National Laboratory, and Oak Ridge National
> >Laboratory (similar organizations), not to
> >mention NASA and a number of NASA contractors.
>
> >Do not depend so much on folklore, rumor, and
> >ill-informed contacts. The facts are far more
> >encouraging.
>
> If you come across anyone at these
> institutions who has published scientific
> research using Forth code, please let me know
> where to find their articles since I like to
> have concrete examples to show people who
> laugh at me when I tell them they should be
> using Forth.
Unlike universities, these are not "publish-or-perish" organizations.
In fact, much of what they do is classified. And, to the extent
that their primary use of Forth is in embedded applications, it
isn't common practice to discuss the language in which a widget
was programmed.
It's a total fallacy to assume that lack of mention in academic
papers equates to lack of use, although of course we'd prefer
lots more mention!
Cheers,
Elizabeth D. Rather
> > The responses to this messages show your
> > points very well. Examples are given of
> > successful big Forth projects include systems
> > that are running on obsolete hardware in out
> > of the way places. If they were really
> > successful, they would be running on the latest
> > computers all over the world. There are other
> > examples given that are hidden where few people
> > would see them instead of being so important
> > that you couldn't avoid seeing them.
>
> This is where Elizabeth should step in and relate the tale she
> told me over dinner in London one night. Old DEC hardware running
> Forth and they were concerned over upgrading the processors or
> changing them. Fact was they could have probably done so with
> quite comparative ease. Anyway, Elizabeth you know all the details
> of this ***Really Big Project***.
Well, yes, it's the current chapter of the Riyadh, Saudi Arabia,
airport.
The installation was designed in the early 80's and installed in the
mid-80's,
by which time much of the hardware was at least obsolescent. Now
it's hoplessly obsolete, and failing. About once a year someone from
the airport gets in touch with us (always a different person/company,
since
contractors there rarely last more than a year, and there's virtually no
information transfer from one generation to the next). They have been
told that, since the project is written in Forth, there's no way the old
stuff can be replaced.
On the contrary, since Forth is readily available on most modern
platforms, a port would be straightforward (not a trivial project, but
vastly simpler than a total rewrite in a new language).
In contrast, the original programming (which we replaced) was done
in PLM and Fortran. How would you port that to modern platforms?
When the opportunity arises, we always point this out, and have
regularly offered to send someone over to make concrete recommendations
and proposals regarding upgrades. So far, no one has accepted this
offer.
Paul E. Bennett
jeth...@ix.netcom.com "J Thomas" writes:
> ............................. There have been suggestions to compile
> the file from the back forward, so you can easily have the highest-level
> code at the front.
More than a mere suggestion. There was an FD article and probably a
Forthwrite one as well where compiling the last screen first was
implemented and the code for doing it was published. Using Blocks
it was easy. Not quite sure how you would do it in a text file (use
page breaks as the start of a loadable segment perhaps).
> ............ I wouldn't be surprised if comp.lang.forth has a
> higher proportion of posts about readability than any other comp.*
> newsgroup.
Probably.
[%X]
> So if we wanted a place for Forth working under normal managers, we'd
> need to find a way to make Forth more *invasive*. We'd need to get it
> spreading to new shops faster than it gets removed from existing shops.
> It probably will be removed each time management shifts, so we need it
> to come *in* more often when management shifts too.
The other way is to get at the kids in school and ensure that they learn
it before they learn any other language. They will need a few basic
concepts in place first (and these need careful structuring in line with
curricula activity) and a good book to start with. SF is probably the best
candidate but, as has already been said, it needs updating.
> There are lots of ways Forth could get a specialty niche in more shops,
> but here's one I think might have a chance. Get some people
> concentrating on making it easy to call C and C++ from Forth and vice
> versa, and also easy to call high-level scripting languages from Forth
> and vice versa. Find managers who're just being installed and persuade
> them that Forth can be a good low-level scripting language, useful for
> prototyping and testing. Then if given the chance, write a quick
> prototype in Forth plus some scripting language (or Forth alone if the
> scripting language doesn't give enough advantage for GUI etc).
I have been involved in projects that, although Forth wasn't the language
of implementation, Forth ideas, style and prototyping of specific cases
was of great benefit to the project. Almost all of my work has been in
the Safety Critical Systems arena.
I recently came across a link to a C/C++ integrity checking house and
requested the available material from them. It arrived this week. Having
had a quick look through there are a number of reccommendations for
coding practice which sound so like the Forth way of doing things that
one could believe that the people running the show may have worked with
Forth at some stage (and learnt the philosophy well). The company is
called Reasoning Inc. who are in Mountain View, CA. They also have a UK
office. I found the website at <http://www.softbugs.co.uk/> interesting.
[%X]
> Even after they have it all in C and maintain it in C there may be a
> place for Forth in testing the C code; they may be able to write test
> harnesses much faster in Forth than in C.
MPE had packages that enabled that.
> The tools I suggested have been discussed before. I gather that both
> the major Forth vendors supply everything that could be desired and also
> iForth supplies much if not all of this functionality. I would like to
> see this done public-domain also, because that spreads the word faster.
Absolutely.
Chris Jakeman
>
>Siegfried writes:
>
>> [ no big projects ]
>
>How about the FSL? Minos? Gforth? Brew (757 KB in 67 files)? Manx (16 MB in
>630 files)? iForth is 187 MB in 4592 files (it's not just the compiler) ...
Please, Marcel, what are Brew and Manx ? And what do you supply in
iForth that takes it up to 187MB ?
Bye for now ____/ / __ / / / / /
/ / / _/ / / / /
Chris Jakeman __/ / / __ / / /_/
/ / / / / / / \
[To reply, please __/ __/ ____/ ___/ __/ _\
unspam my address]
Forth Interest Group United Kingdom
Voice +44 (0)1733 753489 chapter at http://forth.org.uk
Bernd Paysan
> When I meet people who could profitable use
> Forth in their work, I always ask them why they
> don't use it. Often they know something about
> Forth from the old days and they say "Forth is
> unreadable." Instead of finding ways to meet
> this problem, you'll find the advocates of Forth
> endlessly debating what new Forth words to
> define, finding faster ways to compile Forth
> code and tinkering around with the fundamental
> design of the language itself.
Sorry, that's because your problem is not my problem. I can read my
code. I can read code written by other Forthers. And, as I told you
again and again, it took me a few months to learn that - read code from
other Forthers, tight, "undocumented" code. A programming language
should be readable by itself, and comments just disturb you. When I read
Shakespeare or Goethe, I don't read an annotated version (they exist), I
read the unannotated original. It's no trouble for me.
I also often look into the Linux kernel. I can't follow your argument
that C programmer document their code. It's simply not there (in the
Linux kernel), the code is just as terse and uncommented as any other
hacker's code I've looked at. The few comments I read, e.g. in the
horrible unreadable TCP/IP stack of Linux are what should be function
boundaries, i.e. clues for better factoring. If the programmer had a
sense for that, the comments would vanish.
If you use excessive comments from the start of your first programming
language, you'll never learn how to read the programming language
itself, because you always rely on the text on the right. That's wrong.
It reminds me of my Chinese course, where halfways through the book all
glyphs where annotated with the transscript. I've not started to learn
to easily recognise the glyphs until the transscripts vanished, and it
was a tough time first.
Chinese glyphs are clearly unreadable. Yes, seriously, for us westerners
with our long-time experience with lineary ordered alphabets, a
two-dimensional arranged alphabet is difficult to learn (Chinese glyphs
really are composed of around 500 different elements or ~200 "radicals",
of which most of them have variations). But on the other hand, this is a
very successful language (in terms of total texts written in it, overall
time of usage, and overall user number).
You can't write really long texts with it, because even the longest one
is only one fourth of the same translated to Russian; and a lot of
famous Chinese writers have the tendency to create four-glyph aphorisms
instead of Dostojewski-like novels ;-). That includes that Chinese
authors, especially poets, favour terse ambiguous language (to the edge
of unreadability ;-), while Russian authors favour wordy, precise,
redundand language. And it's not just the Russians, it's whole Europe.
You don't win a nobel price for writing Chinese literature; the fact
that the year 2000 laureat is of Chinese origin doesn't count, he writes
thick wordy books in French.
So it boils down to that Forth isn't accepted as mainstream language,
because it's so different. There's some hard work to get into Forth (or
Lisp, or any other unorthodox language - but if you put it right,
there's hard work to get into any computer language, it just matters
which comes first). It isn't helped by putting translations into the
sources, because after all, the reader has to learn Forth, not the
translated stuff.
If you abstract above the familiary argument, and just look at what are
universal attributes that make a computer language readable, Forth
offers a lot to it:
* Words are written lineary, i.e. the flow of operations follows the
reading flow. No need to rearrange the order in your head.
* Programs are written lineary, too. New words only build on words
previously defined. You don't have to seek in the text, you just read
and remember. A Forth program should be written as consistent,
bottom-up
story.
* Words are short, and do one thing right. That's a design philosophy,
but Forth allows to keep words shorter and do simpler things than many
other languages, since the factoring overhead is smaller.
* While the vocabulary of a Forth system typically is large, the
frequently used words are out of a small set. It is important to steer
novices towards those frequently used words, because they are
efficient.
Chuck Moore recently revised his preferred set of simple words
to use, his "machine Forth". It's also a cleaner separation of
language
and library (primitives and high-level functions).
* The Forth semantic model is very simple. You can understand what a
word
does with not much background. There's nothing so complicated that you
must treat it as a black box.
There are also things that make Forth difficult:
* Implicit parameter passing takes away variable names. You must keep
them
in your head. Good Forth definitions don't have many variables
floating
around; my advice is if you have more than four variables active at a
time, refactor; if you are in despair, use locals. The definition
boundaries are clear, because of the stack effect comment.
* Forth uses lots of @!>,? in words. The meanings of these glyphs (they
are used as such, not as letters) seems to be a problem. People
seem to accept all the strange signs in C more easily, because there
they are punctations or operators, not parts of a name.
> It leads to lots of interesting debate, but hardly any big Forth
> applications.
This is comp.lang.forth, by design our place for lots of interesting
debates. Applications aren't written here.
Marcel Hendrix
> On 1 Mar 2001 18:24:08 GMT, m...@iaehv.iae.nl (Marcel Hendrix) wrote:
>>> [ no big projects ]
>> How about the FSL? Minos? Gforth? Brew (757 KB in 67 files)? Manx (16 MB in
>> 630 files)? iForth is 187 MB in 4592 files (it's not just the compiler) ...
> Please, Marcel, what are Brew and Manx ? And what do you supply in
> iForth that takes it up to 187MB ?
Brew: Ask Robert Epprecht http://www.sunweb.ch/custom/epprecht/ (sort of
an evolutionary code generator that looks like the game of Life)
Manx: My algorithmic music language (MIDI and/or elektromechanical outputs).
The most important branches on the iForth CD are include and examples.
The include directory contains the following files
[I recommend to skip this message now!]
Volume in drive C is FRUNOMAIN
Volume Serial Number is 3C3C-1AE6
Directory of C:\dfwforth\include
01/21/01 09:57p <DIR> .
01/21/01 09:57p <DIR> ..
03/27/96 06:51p 6,564 arrays.frt
03/27/96 06:52p 4,180 arraysx.frt
12/29/96 09:39p 8,036 assert.frt
09/03/95 10:29p 7,745 assertio.frt
09/03/95 10:35p 6,377 assertio.glo
09/03/95 10:29p 5,631 backtrac.frt
09/03/95 10:29p 6,044 banner.frt
09/22/00 09:29p 5,112 chebyshe.frt
09/03/95 10:35p 3,074 chebyshe.glo
02/27/00 07:46p 1,681 clapack.frt
10/26/97 03:10p 3,565 cliserv.frt
11/11/97 07:06p 3,546 cliserv2.frt
09/03/95 10:30p 8,436 complex.frt
09/03/95 10:30p 3,208 cvfind.frt
01/22/99 10:11p 5,594 dde.frt
01/23/99 11:31a 14,676 dialogs.frt
01/30/00 04:53p 11,606 dlstroke.frt
01/08/96 08:37p 6,571 dosmouse.frt
09/30/98 06:59p 3,201 dynlink.frt
10/02/94 04:47p 2,778 elip.frt
12/29/96 09:41p 2,261 esoteric.frt
10/02/94 04:47p 2,245 expint.frt
09/03/95 10:33p 2,625 ffind.frt
01/21/01 09:57p <DIR> FONTS
06/07/98 10:17p 2,534 forthpad.h
06/07/98 06:11p 17,236 forthpad.rc
06/13/98 04:09p 36,012 forthpad.res
09/03/95 10:33p 7,857 glossary.frt
09/03/95 10:35p 1,847 glossary.glo
02/06/99 01:15p 21,477 gnugraf.frt
02/06/99 01:15p 22,069 gnugrafh.frt
04/21/96 09:15p 1,867 goto.frt
01/31/00 12:22p 59,505 graphics.frt
09/03/95 10:34p 8,464 heaps.frt
09/03/95 10:36p 2,944 heaps.glo
01/02/98 10:02a 10,387 help.frt
12/18/99 10:08a 10,588 hpgl.frt
02/22/97 03:33p 6,749 html.frt
01/01/98 01:59p 11,329 html2.frt
09/03/95 10:34p 5,854 ibcktrac.frt
09/03/95 10:34p 13,377 imatrix.frt
09/03/95 10:35p 105 iwords1.frt
08/24/96 06:12p 273 iwords2.frt
01/30/00 07:56p 20,771 linuxgrf.frt
12/18/99 03:59p 4,651 lmouse.frt
01/21/96 09:49a 233 LOADSOUN.BAT
09/03/95 10:35p 2,238 locdef.frt
09/03/95 10:36p 1,425 locdef.glo
07/27/98 07:35a 21,370 matrices.frt
08/31/97 12:39p 6,547 mci.frt
01/16/96 07:20p 30,190 menus.frt
12/18/99 03:49p 1,060 mmask.frt
12/16/99 10:40p 923 mouse.frt
01/03/99 08:49p 2,043 now.frt
01/01/99 11:55a 6,313 npipes.frt
07/16/00 04:31p 15,571 os.frt
08/11/00 04:52p 8,892 os.prf
12/31/99 04:49p 3,495 pipes.frt
12/20/99 11:17p 645 playwav.frt
03/24/00 07:01a 4,298 priq.frt
09/03/95 10:36p 1,565 priq.glo
03/02/97 09:24a 6,691 profiler.frt
12/18/99 10:08a 12,291 pscript.frt
04/25/97 11:19p 12,549 pwavdos.frt
04/25/97 11:33p 10,847 pwavewin.frt
12/20/99 11:18p 10,697 pwavlinu.frt
09/03/95 10:35p 2,838 quads.frt
08/16/99 06:58a 6,666 quaternions.frt
09/03/95 10:35p 6,019 queues.frt
08/12/00 04:50p 1,195 raw2out.frt
08/13/00 05:25p 2,111 regfalsi.frt
09/10/00 08:20p 41,870 rk4.frt
01/16/96 06:51a 9,074 rs232com.frt
01/30/00 09:20p 12,667 schema.frt
06/19/99 10:08a 4,413 search.frt
09/03/95 10:35p 4,364 search2.frt
09/22/00 10:19p 34,292 see.frt
02/06/99 01:33p 12,243 servgr16.frt
01/08/96 07:53p 9,257 servgraf.frt
09/03/95 10:35p 2,592 sets.frt
08/13/00 10:07p 651 setstd.frt
09/22/00 10:00p 10,931 sketch3d.frt
09/22/00 09:18p 15,595 sketcher.frt
09/03/95 10:36p 1,409 sketcher.glo
06/10/00 11:59a 34,303 sockets.frt
01/08/96 08:53p 5,002 sort.frt
09/03/95 10:35p 1,468 speaker.frt
09/03/95 10:35p 3,874 spline.frt
09/03/95 10:35p 5,937 stacks.frt
10/02/96 08:25p 11,350 streams.frt
09/03/95 10:35p 26,015 strings.frt
01/30/00 04:39p 632 stroked.frt
12/22/97 12:09a 12,131 strokedx.frt
09/03/95 10:29p 626 template.prf
12/27/99 05:51p 9,533 terminal.frt
12/27/99 05:02p 2,222 terminal.prf
04/18/97 08:39p 1,845 textloop.frt
02/07/00 12:36a 22,713 threads.frt
01/08/96 08:37p 1,600 tmouse.frt
08/14/00 06:55p 14,207 toolbelt.frt
09/03/95 10:35p 2,375 tracer.frt
09/03/95 10:35p 2,785 trcount.frt
09/03/95 10:35p 105 twords1.frt
09/03/95 10:35p 267 twords2.frt
09/03/95 10:35p 6,601 uniq.frt
09/03/95 10:35p 4,795 wc.frt
04/23/97 11:06p 5,339 whatenv.frt
01/23/99 10:57a 17,642 win32gui.frt
01/21/99 10:08p 2,734 winconst.frt
01/21/01 09:58p <DIR> windows
01/30/00 04:53p 5,947 winstrok.frt
06/19/96 09:23p 1,771 wmouse.frt
09/03/95 10:35p 1,721 words.frt
02/06/00 11:35a 27,125 xlinuxgr.frt
07/27/98 07:36a 22,135 xmatrix.frt
12/29/00 11:54p 10,723 assemble.frt
12/28/00 11:46a 25,197 proced.frt
12/23/00 08:14p 10,041 perfctrs.frt
08/31/97 10:15a 1,690 proced.prf
01/29/01 07:58a 4,827 cplx_fsl.frt
02/04/01 01:06a 13,093 genfft.frt
02/04/01 06:03p 15,264 fsl_util.frt
02/08/01 08:01p 1,870 NEEDS.FRT
02/09/01 01:08a 1,861 iforth.prf
02/26/01 11:24p 43,683 ix86asm.frt
03/14/98 01:59p 34,472 wine.emf
02/27/01 09:34p 3,050 nrc.frt
03/03/01 09:41p 22,204 wingrf.frt
03/03/01 10:03p 28,803 eplot.frt
03/04/01 05:43p 28,427 miscutil.frt
03/05/01 02:11a 8,792 blas.frt
03/06/01 09:55p 46,010 gaussj.frt
03/08/01 11:40p 0 files
135 File(s) 1,283,529 bytes
118,652,928 bytes free
The other 186 MBytes are in examples. I'll refrain from a full
listing, but here are the subdirectories:
Directory PATH listing for volume FRUNOMAIN
Volume serial number is 0012FC94 3C3C:1AE6
C:.
+---basic
+---benchmar
| +---ForthIncBench
| +---ForthIncBench2
| +---MPEBench
| +---mmul
| +---Mops_bench
| +---flops
| +---fft
| +---tfftdp
| +---clinpack
| +---nsieve
| +---queens
| +---shuffle
| \---fib
+---blocks
+---caesar
+---editor
+---expert90
+---games
+---sod
+---audiocd
+---graphics
+---gray-3
+---hawk
+---lisp
+---misc
| +---FALSEFRT
| | +---EXAMPLES
| | \---CONTRIB
| | +---BEN_SCHA
| | +---ED_MACKE
| | +---EELKO_DE
| | +---LIONEL_V
| | +---MARCEL_V
| | +---PETER_BE
| | +---STEINAR_
| | +---THOMAS_F
| | \---TOMAS_PA
| +---securehash
| | \---lcc
| \---fips
+---mpascal
+---neural
+---numeric
+---fsl
| +---devel
| +---gforth
| \---trans
+---nspice
| +---circuits
| \---oldcircuits
+---simulati
| +---phasecontrol
+---mix
+---orkest
| +---linux
| +---win
| +---doc
| +---music
| | +---AN
| | \---AN2
| \---wavs
+---pascal
+---modem
| +---q
| +---html
| | +---neurals
| | +---mmult
| | +---flops
| | +---nsieve
| | +---shuffle
| | +---clinpack
| | +---fft
| | +---queens
| | \---fib
| +---post
| \---faq
+---ansi
+---TCL_TK
+---fpga
+---classes
+---modem2
+---bignum
+---digsound
+---ethernet
+---fltest
+---fserver
+---grayo
+---magloss
+---mpqss
+---pl1
+---postscri
+---scope
+---transput
+---junky
+---fitting
+---mxf2
| \---work
+---nrc
| +---chapter16_ODE
| +---chapter15_Modeling_of_Data
| +---chapter20_Less-Numerical_Algorithms
| +---chapter11_Eigensystems
| +---chapter10_MiniMax_of_Functions
| +---chapter9_Root_Finding
| +---chapter7_Random_Numbers
| +---chapter6_Special_Functions
| +---chapter5_Evaluation_of_Functions
| +---chapter4_Integration_of_Functions
| +---chapter3_Interpolation
| +---chapter2_Linear_Algebraic_Equations
| +---chapter12_FFT
| +---chapter13_Fourier_and_Spectral
| \---chapter8_Sorting
+---matlab
+---codebase
+---threads
+---PossibleProjects
+---statevars
| \---pv
+---asm
+---chess
\---brew
+---brew-0_03z6
| +---OUTPUT
| | +---FORTH
| | +---log
| | +---rec-play
| | \---tmp
| +---benchmarks
| \---genes
+---brew-0_03z8
| +---OUTPUT
| | +---FORTH
| | +---log
| | +---rec-play
| | \---tmp
| +---benchmarks
| \---genes
\---brew-0_03z9
+---OUTPUT
| +---FORTH
| +---log
| +---rec-play
| \---tmp
+---benchmarks
\---genes
-marcel
Gary Chanson
Bernd Paysan <bernd....@gmx.de> wrote in message
news:3AA41FBA...@gmx.de...
>
> So it boils down to that Forth isn't accepted as mainstream language,
> because it's so different. There's some hard work to get into Forth (or
> Lisp, or any other unorthodox language - but if you put it right,
> there's hard work to get into any computer language, it just matters
> which comes first). It isn't helped by putting translations into the
> sources, because after all, the reader has to learn Forth, not the
> translated stuff.
To go one step farther, every Forth program is a new language which the
reader must learn before understanding the program.
--
-GJC
-gcha...@shore.net
-Abolish Public Schools.
Michael Coughlin
>
> Michael Coughlin wrote:
> > >We also have several active customers at LLNL
> > >of whom your friend appears unaware, as well
> > >as Sandia Labs, Los Alamos National Laboratory, Brookhaven
> > >National Laboratory, and Oak Ridge National
> > >Laboratory (similar organizations), not to
> > >mention NASA and a number of NASA contractors.
[snip]
> > If you come across anyone at these
> > institutions who has published scientific
> > research using Forth code, please let me know
> > where to find their articles since I like to
> > have concrete examples to show people who
> > laugh at me when I tell them they should be
> > using Forth.
> Unlike universities, these are not "publish-or-perish"
> organizations. In fact, much of what they do is classified.
> And, to the extent that their primary use of Forth is in
> embedded applications, it isn't common practice to discuss
> the language in which a widget was programmed.
> It's a total fallacy to assume that lack of mention in
> academic papers equates to lack of use, although of course
> we'd prefer lots more mention!
I don't know how you manage to only sell Forth to the parts
of the above organizations that only do secret research. They do
as much open scientific academic publishing as universities do.
They just have some other departments that do classified work.
When I worked in secret defense research, we knew that what we
did to hide information from the enemy also kept it from our own
people working on the same project -- sometimes even in our own
department. Maybe you could help your customers by leaking out
the secret that there are other people using Forth.
Just as one indication of how academically oriented these
organizations are, take a look at the web page
http://xxx.lanl.gov/ from Los Alamos National Laboratory. It is
a huge database of the newest scientific research papers from
everywhere on physics, mathematics and computing.
Adrian Ho
> Sorry, that's because your problem is not my problem. I can read my
> code. I can read code written by other Forthers. And, as I told you
> again and again, it took me a few months to learn that - read code
> from other Forthers, tight, "undocumented" code. A programming
> language should be readable by itself, and comments just disturb you.
> When I read Shakespeare or Goethe, I don't read an annotated version
> (they exist), I read the unannotated original. It's no trouble for me.
I wouldn't take such an extreme position -- appropriate comments _are_
helpful and sometimes even essential to understanding. For instance, I
consider stack diagrams to be almost mandatory (you may not consider them
to be comments, though).
Less trivially, comments help illustrate the _intent_ of the author, as
opposed to the _effects_ of the code. This is often helpful:
* for third parties to notice that the two aren't the same (even Forth
programs have bugs 8-)
* to explain why seemingly unnecessary operations/factoring/etc. are, in
fact, needed in the circumstances under which the program runs (ie.
environmental factors)
* to understand system-interface words
> There are also things that make Forth difficult:
> [...]
> * Forth uses lots of @!>,? in words. The meanings of these glyphs (they
> are used as such, not as letters) seems to be a problem. People
> seem to accept all the strange signs in C more easily, because there
> they are punctations or operators, not parts of a name.
This difficulty actually disappears very quickly. It only becomes a real
problem if you use them inconsistently or in obscure ways. For instance:
3 MAIL@ ( fetch message #3 from mailbox)
- potentially confusing, but at least in the spirit of @
"Hi there!" "a...@b.com" MAIL! ( send "Hi there!" to a...@b.com)
- this is just bizarre
--
- Adrian
-----= Posted via Newsfeeds.Com, Uncensored Usenet News =-----
http://www.newsfeeds.com - The #1 Newsgroup Service in the World!
-----== Over 80,000 Newsgroups - 16 Different Servers! =-----
Bernd Paysan
> I wouldn't take such an extreme position -- appropriate comments _are_
> helpful and sometimes even essential to understanding. For instance, I
> consider stack diagrams to be almost mandatory (you may not consider them
> to be comments, though).
There are three sorts of annotations to a program:
a) stack effect. This is part of the "how to use" description of a word.
b) glossary entry. This is also part of the "how to use" description.
c) comment. This is "how it does it".
(a) and (b) can and should be extracted from the source, and are part of
the (source-independent) user manual. (c) should be superfluous if the
language is good enough. There are a lot of (c) coments in my Verilog
sources, because synthesizable code doesn't give much information about
what it does - and even the "how" is hidden. There's little of that in
my Forth code.
Since many Forth programs build up a language you must learn to
understand the program, "how to use" descriptions are important. I
actually like the way Holon organzies glossaries (by having a separate
window in the browser). The way Gforth does it (glossaries interleaved
with code) is less optimal, IMHO, especially since the glossaries are
written to be processed with texinfo, and therefore do not look that
nice (i.e. before formatting).
Paul E. Bennett
lexfie...@usaNOT.netAPPRECIATED "Adrian Ho" writes:
> On Tue, 6 Mar 2001, Bernd Paysan wrote:
>
> > Sorry, that's because your problem is not my problem. I can read my
> > code. I can read code written by other Forthers. And, as I told you
> > again and again, it took me a few months to learn that - read code
> > from other Forthers, tight, "undocumented" code. A programming
> > language should be readable by itself, and comments just disturb you.
> > When I read Shakespeare or Goethe, I don't read an annotated version
> > (they exist), I read the unannotated original. It's no trouble for me.
>
> I wouldn't take such an extreme position -- appropriate comments _are_
> helpful and sometimes even essential to understanding. For instance, I
> consider stack diagrams to be almost mandatory (you may not consider them
> to be comments, though).
In my view, Stack Diagrams ARE mandatory. Especially if you need the code
fully inspected, tested and certified.
> Less trivially, comments help illustrate the _intent_ of the author, as
> opposed to the _effects_ of the code. This is often helpful:
Such as a good file/chapter descriptive heading text that explains the
basic intent of the system design (hopefully taken directly from the
requirements specification) and good glossary text for each word (which
can be later extracted for informational purposes).
> * for third parties to notice that the two aren't the same (even Forth
> programs have bugs 8-)
Which is why documenting sufficiently well enough to enable review by
others is so important. It is hard work if the reviewer has to keep
physically asking the programmer what he was aiming at. Reviewers are
better off knowing what the main intent was and establishing whether or
not the intent was achieved within the code.
> * to explain why seemingly unnecessary operations/factoring/etc. are, in
> fact, needed in the circumstances under which the program runs (ie.
> environmental factors)
One would hope these are minimal, but they may be very importatnt.
> * to understand system-interface words
Considering that, if you take the view that each Forth word has an
interface, then this implies understanding each and every Forth word.
However, I think you were focusing more on the system interfaces and
words that dealt with them.
Richard Owlett
Gary Chanson wrote:
> To go one step farther, every Forth program is a new language which the
> reader must learn before understanding the program.
>
HUH???
If your "logic" is followed then no-one could read a SCI-FI ( FI = fiction or
fantasy) or an "alternate history" novel. I do all regularly.
Walter Rottenkolber
Michael Coughlin wrote in message <3AA843D1...@ne.mediaone.net>...
And if you do try to take a look a the web page of LANL.gov, you will find
that "Access is Denied".
Walter Rottenkolber
Jerry Avins
>
...
> >
> > Just as one indication of how academically oriented these
> >organizations are, take a look at the web page
> >http://xxx.lanl.gov/ from Los Alamos National Laboratory. It is
> >a huge database of the newest scientific research papers from
> >everywhere on physics, mathematics and computing.
> >
> >--
> >Michael Coughlin m-cou...@ne.mediaone.net Cambridge, MA USA
>
> And if you do try to take a look a the web page of LANL.gov, you will find
> that "Access is Denied".
>
> Walter Rottenkolber
I clicked on the link above and saw a lot of references. I followed a
few links in nuclear theory to a paper I could download, but didn't.
Jerry
--
Engineering is the art of making what you want from things you can get.
-----------------------------------------------------------------------
Walter Rottenkolber
Jerry Avins wrote in message <3AAE3648...@ieee.org>...
>Walter Rottenkolber wrote:
>>
> ...
>> >
>> > Just as one indication of how academically oriented these
>> >organizations are, take a look at the web page
>> >http://xxx.lanl.gov/ from Los Alamos National Laboratory. It is
>> >a huge database of the newest scientific research papers from
>> >everywhere on physics, mathematics and computing.
>> >
>> >--
>> >Michael Coughlin m-cou...@ne.mediaone.net Cambridge, MA USA
>>
>> And if you do try to take a look a the web page of LANL.gov, you will
find
>> that "Access is Denied".
>>
>> Walter Rottenkolber
>
>I clicked on the link above and saw a lot of references. I followed a
>few links in nuclear theory to a paper I could download, but didn't.
>
>Jerry
>--
Walter Rottenkolber
Andreas Klimas
> used languages, and there is no large enough niche where it's features
> are needed so much that it gains a lot of market share there. Forth
> programmers are "crazy" (in the eyes of ordinary programmers), because
> they use something different for apparently no reason. We share that
> with users of other "crazy" languages, like Lisp or Smalltalk.
I agree. but I can't understand this behavior.
may be this problem originated from the universities.
some years ago all students have to learn C, than C and C++ and
now Java (at least in German universities, I guess).
I know many friends who are software developers as well but
nobody of them knows about Forth, maybe they have heard
somthing about Smalltalk and Lisp.
Andreas
Andreas Klimas
Bernd Paysan <bernd....@gmx.de> schrieb in im Newsbeitrag:
3AA41FBA...@gmx.de...
> Sorry, that's because your problem is not my problem. I can read my
> code. I can read code written by other Forthers. And, as I told you
> again and again, it took me a few months to learn that - read code from
> other Forthers, tight, "undocumented" code.
I agree. for every language you have to learn to read it. some languages
need more time (C, C++), other less (Smalltalk). I think you need more
time to learn reading Forth programs than Smalltalk. but it's stronger and
more painful to read C or C++ programs (in the beginning time).
> A programming language
> should be readable by itself, and comments just disturb you.
and are misplaced as I told sometimes.
because you implement the semantics two times, and this is bad style.
> * Words are written lineary, i.e. the flow of operations follows the
> reading flow. No need to rearrange the order in your head.
I agree. this is one of the bad circumstances in other langauges like
Java, C and Smalltalk. this is the reason why I like no argument selectors
in Smalltalk.
> * Words are short, and do one thing right. That's a design philosophy,
> but Forth allows to keep words shorter and do simpler things than many
> other languages, since the factoring overhead is smaller.
the next problem after understanding the language is to find the correct
words. this for me is more difficult as coding the body :-)
in forth you have to think about the stack. it's more important
than in other languages that the words are fiting together.
> There are also things that make Forth difficult:
>
> * Implicit parameter passing takes away variable names. You must keep
> them
> in your head. Good Forth definitions don't have many variables
> floating
after a long period in developing software with Smalltalk I find out
that you should not have more than 2 to 3 arguments and no temporaries.
if you follow this concept you have to factor short methods and you
will get a well defined API. again: don't use local variables (temporaries)
if possible.
> * Forth uses lots of @!>,? in words. The meanings of these glyphs (they
> are used as such, not as letters) seems to be a problem.
for peoples who are not familiar with forth.
Andreas
--
Andreas Klimas
Andreas Klimas
Gary Chanson <gcha...@no.spam.shore.net> schrieb in im Newsbeitrag:
lzUp6.7233$JG.9...@news.shore.net...
> > sources, because after all, the reader has to learn Forth, not the
> > translated stuff.
>
> To go one step farther, every Forth program is a new language which
the
> reader must learn before understanding the program.
the developer is responsible for an understandable program. you
might write in C or Java or any other language unreadable and terrible code.
--
Andreas Klimas
Andreas Klimas
Adrian Ho <lexfie...@usaNOT.netAPPRECIATED> schrieb in im Newsbeitrag:
Pine.LNX.4.30.010309...@svr1.03s.net...
> Less trivially, comments help illustrate the _intent_ of the author, as
> opposed to the _effects_ of the code. This is often helpful:
>
> * for third parties to notice that the two aren't the same (even Forth
> programs have bugs 8-)
>
> * to explain why seemingly unnecessary operations/factoring/etc. are, in
> fact, needed in the circumstances under which the program runs (ie.
> environmental factors)
>
> * to understand system-interface words
what's about self testing UnitTests ? this in Forth is very trivial to
implement.
if everybody writes UnitTests for his (her) code (any language) you have
a good point of view how this program works (better than having no, bad
or obsolet documentation ... :-)
> > seem to accept all the strange signs in C more easily, because there
> > they are punctations or operators, not parts of a name.
>
> This difficulty actually disappears very quickly. It only becomes a real
> problem if you use them inconsistently or in obscure ways. For instance:
... in C++ you might overload any operators with different meanings, this
is the same ! I think this is the responsibility of every software developer
(to write code in a consistent way)
--
Andreas Klimas
m_l...@yahoo.com
>
> Bernd Paysan <bernd....@gmx.de> schrieb in im Newsbeitrag:
> 3AA41FBA...@gmx.de...
>
> > Sorry, that's because your problem is not my problem. I can read my
> > code. I can read code written by other Forthers. And, as I told you
> > again and again, it took me a few months to learn that - read code from
> > other Forthers, tight, "undocumented" code.
>
To read Forth:
1) many Forth programs are better read from the end.
2) to read a Forth program, you need a Norton Commander clone
with a Find-in-subdirectory-files command.
Volkov Commander (for DOS) and FAR Manager (for Windows) are ok.
Not sure about Midnight, some versions IIRC were glitchy.
Now, when you have multiple windows (with a FAR in each one),
you can see the word of interest and quickly locate definitions of
the words that it calls.
BUT: that works only for working code.
And it is really stupid to have 2 spaces between : and name
because you will never search for ": name" .
> I agree. for every language you have to learn to read it. some languages
> need more time (C, C++), other less (Smalltalk). I think you need more
> time to learn reading Forth programs than Smalltalk. but it's stronger and
> more painful to read C or C++ programs (in the beginning time).
The C's syntax is no better than Forth's.
Sometimes when I look at my own C code (esp. loops),
I get astonished that this galimatias could compile at all.
iniP ? m_MainFrame->MoveWindow(&m_WinRect), 0:-0 ;
*d++=ps;
if(!*p!=!*q)
_______TVD________
You are missing the most simple method of writting and reading F'
source .
In F' , you start at the modules , understand them and replacing them with
something
you can easily remember , something that is meaningful to you .
Unfortunately ,
F' src has all the details there to confuse you . You can start anywhere
with this
reduction process . It can be called a bottom up process of hiding the
details of
the src behind your names until you get to what appears to be a flow chart
!!
There is no law against writting Forth src with comments discribing the
gory
details , then you can move the code to the bottom , 'cause you no longer
need
more than the comments . Presto ! You now have a flow chart . Your
comments
can look like suedo code , so those who know not Forth can easily read it !
F' is popular for h/w control . It is not used for W98 'cause it has not
been
expanded to be easy to make quick code for W98 . In fact many F's have not
been expanded as C is . Now many have FP , but in the 70's /early 80's
there
were very few Forths with F.P.
C is the worst at h/w control and it's learning curve is only for those
wishing
to show how intellegent they are . It is most unfriendly and obtuse . You
can
not amplify C as you can w/ Forth . If the writers of F' left out something
or did
it slow , anyone can alter this . With C you ae out of luck , pack it in .