From: mikeh@starnine.com (Mike Haas)
Subject: Re: Documenting
Date: Wed, 13 Jan 1993 04:06:02 GMT
Organization: StarNine Technologies, Inc.

In article <1492@eouk9.eoe.co.uk> ahaley@eoe.co.uk (Andrew Haley) writes:
>Mike Haas (mikeh@starnine.com) says that "screens" (by which I presume
>he means blocks used for source code) are viewed by [users of other
>languages] as evidence that Forth will never be a modern language.
>
>Some people may believe this, but it flies in the face of historical
>fact; BLOCK was an innovation.  Every computer OS around at the time
>(1970) supported text files, but Charles Moore invented a different
>method of accessing source text and other data, not because he was
>"old fashioned" but because he thought that he had a better system.

Forth uses blocks because it was almost always used in embedded
controllers and on standalone computers which had little or no
operating system.

It is nuts to suggest that blocks were implemented because they were
thought superior to text files and to do so is rewriting history.

>
>I don't think that people who do not use Forth will be drawn to it if
>we change all our sources to use OS text files; they will carry on
>happily using C or whatever.  The only difference will be that people
>who like to use blocks will no longer have their sources in that
>convenient form.  

There is no reason that that should occur.  There are many Forths,
my own JForth included, that support both.

>
>There is a great deal of work to be done in getting the interactive
>development tools already used in Forth systems to work with text
>files.  If Forth has any virtue, it is simplicity; rewriting existing
>tools to use text files would greatly complicate things.

Not at all.  Simply change the interpreter such that it considers
the end-of-line character or sequence to be another blank character.
(y'know... the unconditional delimeter, most consider TAB, too).

That's 99% of what's needed to get a Forth to work with
files.

>
>There is too much emphasis in this group on rewriting tools that
>already work very well in order to satisfy the expectations of people
>who are never going to use them.

Not using text files will indeed insure that many folks will never use
any Forth tools.

>
>I've no idea where the notion that some of [Forth's] major features
>are architected to work best only in embedded controller applications
>comes from; that is contrary to what is known about Forth's history.

right.  next?

>Much early Forth use at Forth, Inc was in commercial/database
>systems.  They found that blocks work extremely well in that
>environment.

Gee, I bet you found that fixed-length records were better
in databases, too.

>
>On some platforms, interaction with host operating system files is
>essential; fair enough.  You might even run Forth as a task under
>another OS.  I've done this in many applications, and sometimes it's a
>good solution, but Forth is not a programming language so much as an
>operating system.

Forth is not an operating system.  It provides an execution
environment on standalone computers, but it is no operating system.
Nothing but Forth can operate under it's auspices.

>The Forth applications I've seen which impressed me
>the most used Forth as the OS.  There are some wonderful multiuser
>databases which use the Forth operating system.

Can you point me to one I can use on my Amiga or Mac?  One that
uses some IPC to interface with popular applications?  One that
provides a full GUI with resizeable windows, menus, graphics,
photo-quality storage...

>
>It depends on what your goal is.  If it's to get the maximum number of
>Forth users, maybe Mike Haas's route is the best.  If your goal is to
>develop efficient applications on computers (and yes, efficiency is
>still important) then you might choose a different route.

Usre of blocks in no way increases one's efficiency.  In fact, it hinders it
because you have to develop all your own print software, backup software,
stuff that normal OS files live easy with.

It's a helluva lot easyier to insert a new function in the middle of
your program with files.

>
>If the "mainstream" expects a standard set of functions which allow
>one to link with object files from other languages, then by all means
>let's supply one.  But we shouldn't assume that they will use Forth if
>we do.

Huh?

>
>Those who stay with source blocks don't do so because they don't care
>to "put the work in."  It's because we find that blocks are a good
>solution to the problems we face when developing applications.  If
>some others choose to use text files, that's fine.  I don't want to
>convince others how great blocks are; I just want to explain why _I_
>use them.  
>
>If others prefer text files, that's great, but I resent the
>implication that I haven't moved to text files because of laziness.
>It's because blocks work best for my uses.  If others use text files
>that doesn't bother me at all.
>
>I am very disappointed to see the great "blocks versus files" flame
>war resurrected in this conference.  I suppose this message will only
>prolong the latest outbreak; ho hum.
>

naw.