newbie questions

64 views
Skip to first unread message

Andreas Klimas

unread,
Feb 25, 2001, 6:27:52 PM2/25/01
to
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:

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

unread,
Feb 25, 2001, 9:36:57 PM2/25/01
to
humb...@smart.net

>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

unread,
Feb 26, 2001, 1:30:06 PM2/26/01
to

>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

unread,
Feb 26, 2001, 2:12:03 PM2/26/01
to
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 ?

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

unread,
Feb 26, 2001, 5:22:17 PM2/26/01
to

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

unread,
Feb 26, 2001, 7:45:21 PM2/26/01
to
Jason Damisch wrote:

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

unread,
Feb 27, 2001, 2:37:03 AM2/27/01
to
humb...@smart.net

>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 ?
>
>
>3) GCC was one of the few free compilers in the early 1990s that
>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

unread,
Feb 27, 2001, 3:53:31 PM2/27/01
to
humb...@smart.net
>
>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

unread,
Feb 27, 2001, 9:58:23 PM2/27/01
to
On Tue, 27 Feb 2001, Elizabeth D. Rather wrote:

> 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

unread,
Feb 28, 2001, 4:48:33 AM2/28/01
to
In article <3A9BC446...@ne.mediaone.net>
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

unread,
Feb 28, 2001, 7:22:01 AM2/28/01
to
"Paul E. Bennett" wrote:
> 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

unread,
Feb 28, 2001, 12:38:57 PM2/28/01
to
"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

Michael Coughlin

unread,
Feb 28, 2001, 3:09:03 PM2/28/01
to
Gary Chanson wrote:

> 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

unread,
Feb 28, 2001, 10:15:00 PM2/28/01
to
Elizabeth D. Rather wrote:

> 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
> 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. It's been very
> 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

unread,
Mar 1, 2001, 6:18:47 AM3/1/01
to
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.

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

unread,
Mar 1, 2001, 6:26:52 AM3/1/01
to
Bart Lateur <bart....@skynet.be> wrote:
: 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

unread,
Mar 1, 2001, 7:02:18 AM3/1/01
to
Michael Coughlin wrote:

>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

unread,
Mar 1, 2001, 7:55:38 AM3/1/01
to
Siegfried Gonzi wrote:

>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.forthcad.com/>

<http://www.immersive.com/overview.htm>
<http://www.immersive.com/>

--
Bart.

Tony Williams

unread,
Mar 1, 2001, 9:12:09 AM3/1/01
to
In article <3A9E3017...@kfunigraz.ac.at>,
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

unread,
Mar 1, 2001, 9:17:14 AM3/1/01
to
On Thu, 1 Mar 2001 a...@redhat.invalid wrote:

> 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

unread,
Mar 1, 2001, 10:23:03 AM3/1/01
to
Andrew,

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

unread,
Mar 1, 2001, 11:14:58 AM3/1/01
to
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? 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

unread,
Mar 1, 2001, 11:39:39 AM3/1/01
to
Siegfried Gonzi wrote:

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

unread,
Mar 1, 2001, 12:03:59 PM3/1/01
to
Bart Lateur <bart....@skynet.be> wrote:
: 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

unread,
Mar 1, 2001, 12:46:50 PM3/1/01
to
On Thu, 1 Mar 2001, Siegfried Gonzi wrote:

> 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

unread,
Mar 1, 2001, 1:24:08 PM3/1/01
to

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

unread,
Mar 1, 2001, 2:02:53 PM3/1/01
to
Siegfried Gonzi wrote:

> 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

unread,
Mar 1, 2001, 2:07:58 PM3/1/01
to
On Thu, 01 Mar 2001 12:18:47 +0100, Siegfried Gonzi wrote:

>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

unread,
Mar 1, 2001, 9:42:05 PM3/1/01
to
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.

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

unread,
Mar 2, 2001, 7:04:28 AM3/2/01
to comp.lang.forth
Siegfried Gonzi <siegfri...@kfunigraz.ac.at> wrote in message
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:
This is a management issue, not a programming lnguage issue. Both MPE
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

unread,
Mar 2, 2001, 12:30:22 PM3/2/01
to
cLIeNUX user wrote:

> 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

unread,
Mar 2, 2001, 9:44:03 PM3/2/01
to
humb...@smart.net

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

unread,
Mar 2, 2001, 11:56:20 PM3/2/01
to

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

unread,
Mar 3, 2001, 7:45:04 AM3/3/01
to
In article <shtl9tsfo81pavkdk...@4ax.com>,
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

unread,
Mar 3, 2001, 7:59:07 AM3/3/01
to
In article <3A9E3017...@kfunigraz.ac.at>,

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

unread,
Mar 3, 2001, 2:04:54 PM3/3/01
to
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?

cLIeNUX user

unread,
Mar 3, 2001, 6:35:34 PM3/3/01
to
humb...@smart.net

>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

unread,
Mar 3, 2001, 7:06:54 PM3/3/01
to
In article <3AA14056...@ieee.org> jya...@erols.com "Jerry Avins" writes:

> 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

unread,
Mar 4, 2001, 12:59:40 PM3/4/01
to
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


"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

unread,
Mar 4, 2001, 2:21:31 PM3/4/01
to

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

unread,
Mar 4, 2001, 2:28:12 PM3/4/01
to
A noble effort, indeed. Despite the fact that many in the Forth
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

unread,
Mar 4, 2001, 7:06:36 PM3/4/01
to
"Nathan D. Hesterman" wrote:

> 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

unread,
Mar 4, 2001, 8:23:33 PM3/4/01
to
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:

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

unread,
Mar 5, 2001, 3:35:07 AM3/5/01
to
"Elizabeth D. Rather" <era...@forth.com> wrote in message news:3AA2D88C...@forth.com...
> "Nathan D. Hesterman" wrote:
>
>> 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.
[..]

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

unread,
Mar 5, 2001, 6:28:34 AM3/5/01
to
Nathan D. Hesterman <nhest...@compuserve.com> wrote:
> 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

unread,
Mar 5, 2001, 6:28:34 AM3/5/01
to comp.lang.forth

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?
I have recently been working on a mixed-language project in which all
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

unread,
Mar 5, 2001, 2:18:12 PM3/5/01
to
"Elizabeth D. Rather" <era...@forth.com> wrote in article
<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

unread,
Mar 5, 2001, 1:50:23 PM3/5/01
to

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

unread,
Mar 4, 2001, 8:36:52 PM3/4/01
to
In article <3AA295BB...@ieee.org> jya...@erols.com "Jerry Avins" writes:

> 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

unread,
Mar 4, 2001, 6:14:18 PM3/4/01
to
Adrian Ho wrote:
> 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

unread,
Mar 4, 2001, 6:32:01 PM3/4/01
to
Siegfried Gonzi wrote:
> 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

unread,
Mar 5, 2001, 8:57:23 AM3/5/01
to
cLIeNUX user wrote:
> 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

unread,
Mar 5, 2001, 9:15:03 AM3/5/01
to
Marcel Hendrix wrote:
>
> "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

unread,
Mar 5, 2001, 4:47:26 PM3/5/01
to
"Paul E. Bennett" wrote:
>
...

>
> 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.
>
> --
Doctor, I get a headache when I do _this_.

OK. Don't do it.

m_l...@my-deja.com

unread,
Mar 5, 2001, 3:39:50 PM3/5/01
to
Anton Ertl wrote:
> >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

unread,
Mar 5, 2001, 7:56:18 PM3/5/01
to
humb...@smart.net

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

unread,
Mar 5, 2001, 8:54:45 PM3/5/01
to
Michael Coughlin wrote:
> 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

unread,
Mar 5, 2001, 8:23:58 PM3/5/01
to
In article <3AA3DFEF...@interbulletin.com>
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

unread,
Mar 6, 2001, 7:17:24 AM3/6/01