NetNews Usenet Archive 1993 #3/NN_1993_3.iso/spool/comp/lang/forth/3951

Text File | 1993-01-21 | 8.6 KB | 214 lines

Newsgroups: comp.lang.forth
Path: sparky!uunet!starnine!mikeh
From: [e-mail] (Mike Haas)
Subject: Re: Documenting
Message-ID: <[e-mail]>
Sender: [e-mail] (Mike Haas)
Date: Fri, 22 Jan 1993 00:02:46 GMT
References: <[e-mail]> <[e-mail]> <[e-mail]>
Organization: StarNine Technologies, Inc.
Lines: 202

In article <[e-mail]> [e-mail] (Kevin Haddock) writes:
>In article <[e-mail]> [e-mail] (Mike Haas) writes:
>>
>>Forth uses blocks because it was almost always used in embedded
>>controllers and on standalone computers which had little or no
>>operating system.
>>
>
>Ahem.  As I recall, the first Forths were all captured, not stand alone.
>And they used screens.  The first experimentation done my Moore in
>threaded interpreters was done in (I believe) Fortran.

Barf.  I'm not referring to whatever perturberation of TIL he used
when Chuck was originally developing the concept that ultimately
became Forth or what language he used.

I'm talking about the form Forth assumed after it was a little more
mature and standardized (I said a LITTLE more).  And I stand by my statement.
It WAS almost exclusively used on standalone machines that had no
file system.  And that's why, even when implemented on a file-based
platform, it took the shape of blocks-within-a-file.

There were few machines with any form of file system available to the
common hacker, CP/M being one of the first.  Even then, many Forths
used the drives on a block basis, ignoring the file system, insuring
you were always open to doing a FLUSH with the wrong disk
in the floppy drive (like your system boot disk) and wrecking
it.  Even back then, screens caused problems with file-system
oriented platforms.

>>It is nuts to suggest that blocks were implemented because they were
>>thought superior to text files and to do so is rewriting history.
>>
>
>Well, if you like, I could call someone who was there (C.M. perhaps)
>or perhaps Elizabeth Rather would care to respond?  I think YOU
>are rewriting history.  I would bet FORTH, Inc. still uses screens
>even captured under operating systems in their projects.

I bet they do.  (I wouldn't brag about it).

>
>> [...]
>>
>>Not using text files will indeed insure that many folks will never use
>>any Forth tools.
>>
>There will always be plenty of people out there like you to help them
>transition over!

That's not the point.  The important thing is that Forth will never be
considered mainstream or popular as long as such non-industry-standard
concepts are the PREVELANT way of doing things.

(I COULD have added "because of people out there like you who stand
by this dead horse" but I won't cause I'm a nice guy.)

>
>> [...]
>>
>>Gee, I bet you found that fixed-length records were better
>>in databases, too.
>>
>They are FAR better!  Variable length records are only usefull in
>sparse arrays (i.e. a long string that is almost always empty or close
>to empty).  In the real world this happens maybe 10% of the time.
>This can be easily handled in a heap data file or in a series of
>fixed record length files of graduating lengths.  To force EVERYTHING
>into a variable length format is the height of folly.  I just
>finished a stint of working with Advanced Revelation (i.e.  Pick)
>and it takes a BIG performance hit due to this.  Perhaps if you
>want to prototype, have an application that suffers major changes
>constantly, have a one-time deal, or if you have hardware support for
>your heap management (smalltalk engines) you could get away with it but
>otherwise don't subject your customers to live with that overhead
>for the life of the project!  It takes 2 386-33's and eithernet to
>do an application that an XT could do with PolyFORTH (probably on a
>floppy!).

Fixed-length records have their place, but also of large importance
is the idea of efficient use of media (another area where blocks
fall flat on their face).  Any database of significant size will
waste space on empty fields in a fixed-length record system.  And there
ARE methods which make variable-length record access incur
minimal performance overhead... it just takes work & talent to
make it so.  AFter all, ever file system is, in effect, a variable-length
record database.



>
>
>>environment on standalone computers, but it is no operating system.
>>Nothing but Forth can operate under it's auspices.
>>
>>
>
>O.K. if that is what it takes for you.  Port the Prolog in Forth
>over and write in that!  How about the BASIC?  Assembly language?
>write your own?  Whatever floats your boat.

Gee, how about C?  Or running MS Word under Forth?  I repeat...
Forth is not an operating system.

>
>>Can you point me to one I can use on my Amiga or Mac?
>DOS doesn't run on Amiga or Mac (w/o emulation).  I suppose you call
>that an O.S.?

Actually, it IS a debatable question whether MSDOS is an operating
system, but I don't want to debate that here.

The point is that each of these three provide a generalized environment
which supports launching of independantly developed applications which
do not have to be written in any particular language, and usually
exist in "compiled" form.

>>  One that
>>uses some IPC to interface with popular applications?
>What does an IPC have to do with it?  You have the best IPC of
>all.  One that does not require BINARY compatibility.  If your
>program wants binary compatibility it can (find) the words it
>needs to interface and lay the addresses in a vector table.

But to be (find)-able, it must have been compiled into the
dictionary, and therefore had to exist in source form.  This
is not "binary" compatibility.  I cannot hand you a binary
component for use in your forth.

>>  One that
>>provides a full GUI with resizeable windows, menus, graphics,
>>photo-quality storage...
>
>Oh, and DOS really does that doesn't it.  How about Unix?  There are
>programs that run under those that provide that.  That does not
>constitute an OS.

What does it constitute, then?  BTW, AmigaDOS and MacOS DO provide this
in their base functionality sets.

>What you are saying is because Forth has not had
>such a large following to produce such fluff that it does not constitute
>an O.S.  What about hanging 60 users off an 8 mhz processor?  Can yours
>do that?  What about networking 350 computers together in a network and
>transmitting any event of interest from one point to any other in less than
>2 seconds (with low speed rs-232 links no less)?

These are just things that PROGRAMS do.  Standalone computers can
be made to do these things.

>I just think we have
>different definitions of what comprises an O.S.  Actuall to get down
>to brass tacks it really should mean a set of programs that allow you
>to OPERATE the SYSTEM.

Yes, there is a "definitions" problem... the one you want to use
for Operating System is one from the 50's.

It may be possible to write an OS in Forth, but itself is only
a Forth environment.  It allows you to compile Forth programs and
run Forth programs.  It is no more an operating system than BASIC.

>
>
>>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.
>>
>
>subjective.  Such tools exist under forth, just not as complex as you're used
>to.

Like I said, you have to roll your own.  And your options are always more
limited.  With files, you can choose from any of a prolifera of
standard, accepted and proven text editors.  Standard ones like
VI and EMACS, or GUI-based ones, even MS Word, WordPerfect, etc.
And the new one coming out next month.  Or next year.  Commercial
ones, shareware ones, freeware ones.  And the same holds true for
print software as well as backups, comparing two sets of source
to find the latest.  WHich of course brings up SOURCE CONTROL
SYSTEMS, something that has never been developed for screens, but
tons exist for text files.

There is nothing subjective about the advantages of files over
screens.

>>It's a helluva lot easyier to insert a new function in the middle of
>>your program with files.
>
>Also subjective.  You are crowding your screens too much or not structuring
>your lexicons properly.

I'm going to start laughing soon.  There are a million legitimate reasons
why someone might want to add a new definition, and there is no
insurance possible with screens no matter what you do.  Leave tons
of blank space?  Then you are wasting disk space and even THAT blank
space can be used up.

Screens are great for embedded controller type projects.

For modern Forth developing software on modern platforms, they are a joke.