NetNews Usenet Archive 1993 #1/NN_1993_1.iso/spool/comp/lang/forth/3771

Text File | 1993-01-06 | 5.3 KB | 124 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: Wed, 6 Jan 1993 00:08:27 GMT
References: <[e-mail]> <[e-mail]> <[e-mail]>
Organization: StarNine Technologies, Inc.
Lines: 112

In article <[e-mail]> [e-mail] (Doug Philips) writes:
>In article <[e-mail]> [e-mail] (Mike Haas) writes:
>+They [screens] are also incredibly wasteful... if you only enter one 1-line
>+definition on a screen, you are wasting all the rest of the storage
>+space, as screens must occupy 1024 characters, regardless of how
>+much is white-space and what is not.  Just the remainder of whitespace
>+on each line following the last non-white character is a waste.
>+
>+All because of the inability to handle an "end-of-line" character!
>+And what OS doesn't provide THAT?
>[Tedious list of the first line "documentation" for a group of screens
>elided.  -dwp]
>+Simple.  Each is in it's own file.  Clean, clear, and no waste of space.
>
>Whoa a minute here.  Most OS's (those that have EOL characters), also have
>file systems with allocations in units of sectors (or multiple-sector
>unitss), and bunches of tiny files will waste a lot of space.  If this is
>really an issue, then let's be clear about it.

It certainly IS an issue:  There is a grain-size to normal file systems,
ans it is usually based on hardware sector size.  BUT...

It standard files, the only disk space that is wasted is in the last block.
In screens, it is virtually always true that a significant portion of
EVERY block in the file is wasted.  If an attempt is made to use screen
real-estate more efficiently, then unreadable, non-indented code is the
result.

Type in the following two lines in a stanard text editor and a screen
editor...

ABC
123

Assuming CR,LF is the eol terminator, a hex dump of that data will reveal...

41 42 43 0d 0a 31 32 33 0d 0a

display in hex the same two lines of the screen reveals...

41 42 43 20 20 20 20 20 20 20 20 20 20 20 20 20
20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20
20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20
20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20
31 32 33 20 20 20 20 20 20 20 20 20 20 20 20 20
20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20
20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20
20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20


>
>+I always wonder how many proponents of screens have never tried
>+a good file implemtation.
>+
>+The fact that many still argue for screens is a statement as to
>+why Forth will never be accepted by the mainsteam.
>
>How about:  The fact that many still argue over screens vs. files is a
>statement as to why Forth will never be accepted by the mainstream?

Attempting to bring "modern" technology (like files- ha ha) to Forth
keeps it out of the mainstream?  That's a new one.

>
>Is Forth so rigid as to require one and disallow the other?

I have said repeatedly that the proper place for screens is in
systems where there is no operating system.  My bone of contention
is with the rigid individuals who insist that if an OS
is available, with standard file system capabilities, that
screens still have a place in that kind of an environment.

It is ridiculous to think that professionals versed in C,
Pascal and other mainstream languages will accept screens in
any way.  They DO keep Forth out of the mainstream.

I believe that screens are viewed by such individuals as
evidence that Forth will never be a modern language.  Remember
that these are computer-literate people that have yet to learn to
appreciate Forth's interactivity, architecture, simplicity and
power.  And they never will as long as, in their 'indoctrination',
they are told that screens are the accepted, standard way of
dealing with Forth source.  Think about it... conventional
language programmers have come to expect that they can PRINT OUT
their source using standard tools, and that's just a small
example of the radical differences between screens and files.

Imagine what such professionals think when they are told that
the only way to track and reference volumous source file is
via a screen number!  Remember all the flack that BASIC received
for insisting upon line numbers?  Remember how, when BASIC's were
introduced that didn't require line numbers, it was praised?

It is difficult to convince xperts that a given language is an
excellent general-purpose tool, when some of it's major features
are architected to work best only in embedded controller
applications.

In truth, I did not find Forth to be a good general purpose
platform language until I had both files and the ability to
generate minimally-sized standalone programs that do not
contain ANY exteraneous code from the development system
(like the compiler itself, fer chrissake).  I also think
we won't even get off THAT easy!  To begin to be considered
by the mainstream, there needs to be a standard set of
functions which allow one to link with object files from
other languages.  That's what the mainstream has come to expect,
and it is a very valuable and useful capability.

But from what I've seen, few care to put that much work into it.
Easier to stay with screens and try to convince others how
great they still are.