FORTH, PASCAL, and C--- which one would you choose (it depends ?)
P Wei
TURBO Pascal and HS/Forth for IBMPC. For 10 iterations, the execution looks
like :
Microsoft C : 13.2 sec (from pc-tech Jan 1986, p91)
8.1 sec (using register)
Lattice C : 10.5 sec (from the same place as above)
TURBO Pascal: 14.1 sec (from an ad for ZBASIC)
HS/Forth : 47.0 sec in interpreter (data from ad)
7.0 sec using code optimizer and improved program
Assembler : 5.0 sec
Now, the question is :
It seems that Forth is as extensible and structured as C and Pascal (to my
understanding), and generates more compact and faster execution program.
Its interpreter being far more faster than BASIC's makes developement time of a
project much less than when using 'edit-compile-link-test' type of language.
I wonder why Forth is still less popular (to my impression) than C and Pascal.
Is it because :
--its somewhat 'awkward' syntax ? (Pascal is closer to human language)
--its lack of predefined data structure ?
--its putting great responsibilty on the programmer ? (the kernel is so compact
and simple that you must first extend the system and create many things which
in C and Pascal are taken care of by the compiler-writer.) In this sense,
if I compare the simplicity and primitiveness I get:
Assembly > Forth > C > Pascal (where > means simpler than).
We know power comes from simplicity, however we must pay price for it.
For C-lovers, do you think UNIX-like (or operating system in the general sense)
can be written in FORTH and possibly has better performance?
For Pascal-lovers, is the 'visually' readability and strongly type the primary
advantage ? and a must ?
For Forth-lovers, do you think Forth is suitable for being used as a
general purpose language instead of the one 'exclusively' designed
for use in the lab and industry to control the machine...
Note: I am not a dedicated C, Pascal or Forth programmer.
HP Wei (wei@princeton)
John Cornelius
You can write anything in anything; Prime proved this by writing an operating
system almost entirely in Fortran. Why I even remember when we wrote operating
systems in Machine Language (no, not Assembly language, Machine Language).
The major comments that I have heard regarding Forth are that it is very fast
and compact but it is more cryptic than C (and maybe even Assembler) and that
it requires the programmer to do too much of the compilation himself at coding
time. The first criticism is probably valid in that I've seen a number of Forth
programmers stare at their code for long periods and then just rewrite the
whole program/subroutine because they cannot remember what they did. The second
criticism is equally valid in any language where portability is not an issue.
Languages are a matter of taste and zealots for most of the currently popular
languages are indistinguishable from one another. One must simply consider what
problem one is trying to solve is and proceed from there for a particular
application. Since efficiency of the language is largely a function of the
skill of the compiler writer(s) the choice of compilers is probably more
important than the choice of language.
John Cornelius
Western Scientific
....!sdcsvax!westsci!jc
David desJardins
>I compared the Eratosthenes sieve benchmark for Lattice C, Microsoft C,
>TURBO Pascal and HS/Forth for IBMPC. For 10 iterations, the execution looks
>like :
>Microsoft C : 13.2 sec (from pc-tech Jan 1986, p91)
> 8.1 sec (using register)
>Lattice C : 10.5 sec (from the same place as above)
>TURBO Pascal: 14.1 sec (from an ad for ZBASIC)
>HS/Forth : 47.0 sec in interpreter (data from ad)
> 7.0 sec using code optimizer and improved program
>Assembler : 5.0 sec
Note that TURBO Pascal is a "quick and dirty" compiler which does no real
optimization. Also, range checking and other slowdowns were probably left on;
this invalidates the comparison with versions of C which (I believe) do not
include these as defaults. Further, the point of benchmarks is _not_ to
improve the program, nor to optimize the code...
The meaning of these numbers is certainly open to question. Let us assume
that Forth can indeed produce somewhat faster results than C or Pascal.
>Now, the question is :
>It seems that Forth is as extensible and structured as C and Pascal (to my
>understanding), and generates more compact and faster execution program.
A structured language is one which imposes structure on the programmer;
i.e. forces programs into a pattern. Forth is the antithesis of structure.
I like Forth, but in the same way that I like assembly language--it is fast
and efficient. It might even be a reasonable alternative to C for some
purposes, since in either language the programmer is largely responsible for
the integrity of his data structures. (I don't like C much, I'm afraid...)
Forth is also _not_ as extensible as Pascal, in that Pascal maintains the
integrity of user extensions, whereas Forth leaves the programmer with this
responsibility.
>Its interpreter being far more faster than BASIC's makes developement time of a
>project much less than when using 'edit-compile-link-test' type of language.
This is not really true on large projects (large enough to be broken into
separate modules). The extent to which it is true is also dependent on
programming style.
>I wonder why Forth is still less popular (to my impression) than C and Pascal.
>Is it because [of]:
>--its somewhat 'awkward' syntax ? (Pascal is closer to human language)
I like Forth syntax a lot; certainly I would not choose one language over
another for its syntax in any case.
>--its lack of predefined data structure ?
I think this is the main point. Modern programming does involve complicated
data abstractions, and while I can believe that structures to represent these
can be constructed in Forth, all of the burden of both the construction and the
segregation of types falls on the programmer. Maintaining the distinction
between data types is half of the purpose of a programming language (especially
if you consider the program itself as a data type!).
>--its putting great responsibilty on the programmer ? (the kernel is so compact
> and simple that you must first extend the system and create many things which
> in C and Pascal are taken care of by the compiler-writer.) In this sense,
> if I compare the simplicity and primitiveness I get:
> Assembly > Forth > C > Pascal (where > means simpler than).
> We know power comes from simplicity, however we must pay price for it.
I strongly disagree that power comes from simplicity. Power comes from
having complex tools in place to support the tasks you wish done, rather than
having to do everything by hand. For driving nails a fist is simple; a hammer
is powerful.
>For C-lovers, do you think UNIX-like (or operating system in the general sense)
>can be written in FORTH and possibly has better performance?
This seems quite possible. Unfortunately, the tools needed for this do not
yet exist (compiler compilers, code generators, etc.). If the same effort is
put into developing Forth that was put into C, I believe it is quite possible.
With hardware Forth machines, the result could be impressive. But work on the
system would still largely be done in high-level languages and perhaps compiled
into Forth. (Disclaimer: I perhaps am not qualified to comment on this, as I
am not a C-lover.)
>For Pascal-lovers, is the 'visually' readability and strongly type the primary
>advantage ? and a must ?
As I said before, syntax is irrelevant... Strong typing, on the other hand,
is invaluable. I don't suppose I'm going to persuade anyone who doesn't
already agree, so I'll just say that I see the weak (lack of?) typing in Forth
as perhaps its biggest problem, especially as I see no easy solution without
substantial changes in the language.
>For Forth-lovers, do you think Forth is suitable for being used as a
>general purpose language instead of the one 'exclusively' designed
>for use in the lab and industry to control the machine...
>HP Wei (wei@princeton)
As I said, I think it is quite possible Forth or Forth-like languages have
a place as system programming languages, provided the proper development tools
are created. I don't believe they have a place as general-purpose languages
though; I think if anything high-level languages are moving in the opposite
direction (Ada...). But then I don't know what people see in C...
-- David desJardins (de...@brahms.UUCP)
Duane Morse
>
> Is it because :
> --its somewhat 'awkward' syntax ? (Pascal is closer to human language)
> --its lack of predefined data structure ?
> and simple that you must first extend the system and create many things which
> in C and Pascal are taken care of by the compiler-writer.)
> HP Wei (wei@princeton)
A few years ago, Forth was popular at the company where I work. The programmers
who wrote Forth programs (myself included) liked the language, but the
company eventually stopped selling Forth-based systems for two basic
reasons: (1) it was next to impossible to find Forth programmers, so the
company would have to spend considerable time training programmers in the
language (and the company really didn't want to spend the time to do this);
(2) when we did half-heartedly try to train people, we found that we had more
trouble teaching Forth than any other language -- we plain had to give up
on some people! Further, customers didn't have Forth programmers on staff,
so they had even greater trouble taking over our software (we sold the source
and they maintained and enhanced their systems).
Recently our company has jumped on the Unix/C bandwagon, and "portability"
is the current watchword. Though I believe that Forth isn't as portable as
C can be, it's interesting to note that we dropped Forth long before anyone
here started programming in C, and no one cared about portability at the time.
--
Duane Morse ...!noao!terak|anasazi!duane or ...!noao!mot!anasazi!duane
(602) 870-3330
Wombat
Benchmarks are not an effective way of judging a language--they serve only
to evaluate a particular *implementation* of a language on a particular
machine. Additionally, use of runtime benchmarks tends to promulgate the
obsolete notion that "running speed is everything"; in most cases,
"programmer time" is everything.
Now, on to Forth vs. other languages. What follows is a paraphrasing
of an artticle I wrote a while back...
There are severe problems with Forth that prevent it from being much more than
an interesting (failed) exercise in threaded-interpretative language design.
It is (1) compact, (2) modifiable at runtime, (3) extensible and (4) hard to
read. Some of these are also features/flaws of other languages, depending on
your viewpoint. However, I'd like to point out the following:
1. Forth is a lot harder to read than even Lisp or APL; at my former employer,
where we used Forth in real-time control and number-crunching applications,
we called it a "write-only" language.
2. There are many incompatible implementations of Forth, and even
implementations from the same vendor behave radically different on
different processors.
3. The debugging support is non-existent.
4. The primitive set of operators is *very* large; and it is not orthogonally
constructed; the names are not even *close* to mnemonic; and many operators
have uncontrollable side effects outside the modules in which they are used.
5. Forth is not structured, typed, or anything like that. When
using Forth, you may forget anything you learned from Software Tools, or
Elements of Programming Style, or Niklaus Wirth, or, roughly speaking,
the last 15 years of evolution in programming techniques.
And now, I'd like to quote another article that appeared at the time:
> From: li...@nbs-amrf.UUCP
> Newsgroups: net.ai
> Subject: Forth for AI? NO!
> Date: Sun, 22-Jan-84 19:54:16 EST
>
> Forth for AI? Don't make me laugh. Here's Forth's really bad points:
>
> 1) Manipulating programs as data in Forth is difficult. Also
> impractical, since it has no garbage collection. You can't expect to
> service high-priority interrupts if you've just run out of space!
> (Forth's primary use is for real-time control.)
>
> 2) Can't pass arguments explicitly. You must pass information by
> putting it on the stack. Since I pushed the 2nd arg at line 6 and then
> used the stack to do something else, what are the odds that at line 23,
> I can push the 3rd arg on the stack and then call that function with
> confidence? Reading code, trying to find out what the arguments are, is
> like counting parens in Lisp, except now imagine that every atom in the
> list manipulates the count of ('s and )'s!
>
> 3) Forward referencing (including recursion) is not normal and must be
> done by manipulating compiled code. Bye-bye portability. Indeed, I have
> never seen anyone write a recursive Forth routine (although it can be
> done). Bye-bye AI.
>
> 4) Code is generated as you type (or load) in Forth source. Hence you
> lose all possible benefits of a good compiler, i.e. type-checking,
> optimization, etc. As for syntax checking, forget it. The syntax of
> the language is so simple, almost every combination of Forth words is
> syntactly correct (although meaningless). If you mistyped that last
> word, you'll find out at run-time.
>
> 5) Scoping, name-space rules are terrible. For example, it is impossible to
> write a subroutine that uses variables that are *guaranteed* to be local.
> (How can you ever be confident about your code?)
>
> 6) The emphasis on Forth is on speed at the cost of everything else. For
> example, if you can keep track of all data by storing it on the stack,
> great, but if you have to use a variable (no less a structure) you start
> losing efficiency. Using a variable in Forth is akin to using those
> features in PL/I that are great but really slow the runtimes down. And
> Forth simply isn't fast to begin with. Any decent compiler can do better
> (then "threaded-code").
>
> 7) The only messages from the system are "ok", "?" (meaning "I don't
> know that word") and "stack empty". (It might check stack-full and some
> others, but these are the only msgs I've ever gotten.) This is very
> consistent with the Forth philosophy (see 6.) but really unhelpful.
> Debugging note: If Forth encounters a word it doesn't know, the stack is
> popped. Since the only other error is when the stack is empty, it is
> impossible to tell where you died by looking at the stack!
>
> 8) I hesitate to criticize any language for being unreadable, since I
> really like APL, which is also unreadable but in a different sense.
> Forth is like Lisp but without parens. Its very hard to figure out what
> the functions, args and bindings are without reading the entire
> subroutine from the beginning and knowing type info about every word.
> And even if you do, glancing at a random line that is manipulating the
> stack doesn't tell you at all what is on the stack. To know this, you
> also have to understand the function of every word.
>
> I could go on, but I think you get the idea by now. (No, not that I
> hate Forth!) Forth has its good points, but none of them make it a
> practical language; most of them are for intellectual stimulation
> only. Given a task and my choice of languages, I would never choose
> Forth. You shouldn't either.
>
> Don Libes
In summary (speaking for myself, not Don), I strongly recommend that you avoid
Forth. If I were you, I'd resort to using assebly language first; you'll
have a better chance of producing debuggable, robust, and maintainable code.
--
Rich Kulawiec pur-ee!rsk purdue-!rsk r...@purdue-asc.arpa r...@asc.purdue.edu
mar...@ccvaxa.uucp
I hate to wander far afield, but David desJardins responded to the claim that
an interpreted language shortens project development time by saying "This is
not really true on large projects (large enough to be broken into separate
that used the edit-compile-test-integrate technique. My current project is
a large Lisp system; it's broken into modules and we write our code in the
usual Lisp interactive way.
As far as I can see, the interactive style is much more productive for
programming and some parts of design. Of course, you still must *do*
design, and you still must test -- programming is not all there is.
Since most languages can be interpreted (some more easily than others),
my point isn't all that germane to this argument.
Brian Marick, Wombat Consort
Gould Computer Systems -- Urbana
...ihnp4!uiucdcs!ccvaxa!marick
ARPA: Marick@GSWD-VMS
Tom Almy
In article <11...@princeton.UUCP> w...@princeton.UUCP (P Wei) writes:
>TURBO Pascal and HS/Forth for IBMPC. For 10 iterations, the execution looks
>like :
>
>Now, the question is :
>It seems that Forth is as extensible and structured as C and Pascal (to my
>understanding), and generates more compact and faster execution program.
>Its interpreter being far more faster than BASIC's makes developement time of a
>project much less than when using 'edit-compile-link-test' type of language.
>I wonder why Forth is still less popular (to my impression) than C and Pascal.
Well ignorance (and I mean to offend nobody by this) is a problem. Most
programmers don't KNOW Forth, and so cannot judge it. "C" is popular amoung
UNIX users, because you just about have to use C under UNIX (I have had no
good experiences with it in NON-UNIX systems). PASCAL is taught in schools
so it has a guarenteed user community -- its rigidity is favored by academic
types. I used it for programs heavily into data structures, but only for
those that PASCAL supports. There are millions of potential Microsoft BASIC
users, since it is built into almost everyone's personal computer. I use
Microsoft BASIC when I want to manipulate strings.
On the other hand, FORTH takes effort -- you have to go out of your way to
obtain it, and you have to learn it on your own.
>Is it because :
>--its somewhat 'awkward' syntax ? (Pascal is closer to human language)
Pascal closer to human language? GAG! If you want to program in human
language use COBOL :-). Actually Forth has simpler syntax rules than any
other language I know except for un-adulterated LISP; I can explain the
syntax rules of Forth much faster than I could appologise for the semicolon
rules in PASCAL!
>--its lack of predefined data structure ?
This is certainly a disadvantage to learning Forth, but the ability to create
any data structure you want and placing them anywhere you please
(like an array on a remote system accessed via modem), hiding the access
method like in Smalltalk, is very powerful indeed.
>--its putting great responsibilty on the programmer ? (the kernel is so compact
> and simple that you must first extend the system and create many things which
> in C and Pascal are taken care of by the compiler-writer.) In this sense,
> if I compare the simplicity and primitiveness I get:
> Assembly > Forth > C > Pascal (where > means simpler than).
But the extensibility of Forth allows making it "less simple" as applications
require. If you MUST have infix expressions, you can have them; if you want
bounds checking on arrays, or or traps on arithmetic overflow, you can have
that too (and be just as invisible to the programmer as in PASCAL).
> We know power comes from simplicity, however we must pay price for it.
>
[...]
>For Forth-lovers, do you think Forth is suitable for being used as a
>general purpose language instead of the one 'exclusively' designed
>for use in the lab and industry to control the machine...
Yes, in fact I have seen accounting packages in Forth, and scientific
programs in Forth. In the past year I have been rewriting many of my
favorite CP/M and MSDOS utilities (mostly filter like programs) in Forth
using the Forth compiler I have written, getting typically 2-4x speedups
(4x for AZTEC CP/M programs that used "stdio"), and 75% code size reductions.
I have implemented a multi-tasking multi-user Forth in CP/M (three users and
a printer spooler on a Z-80!). I also have written an IC layout program
in Forth. I have used it in "traditional" Forth environments as well.
>Note: I am not a dedicated C, Pascal or Forth programmer.
>HP Wei (wei@princeton)
At different points in time, I used almost exclusively all of these,
as well as Fortran, BCPL, LISP and APL. Now I am using Forth almost
exclusively.
Tom Almy
(Usual disclaimer, but you can flame directly at me if you want. Why
wear out /dev/null?).
Tom Almy
errors that I cannot ignore.
In article <681@pucc-j> r...@pucc-j.UUCP (Wombat) writes:
>
>There are severe problems with Forth that prevent it from being much more than
>an interesting (failed) exercise in threaded-interpretative language design.
>
>It is (1) compact, (2) modifiable at runtime, (3) extensible and (4) hard to
>read. Some of these are also features/flaws of other languages, depending on
>your viewpoint. However, I'd like to point out the following:
I fail to see how item (1) could be considered a "flaw", Forth is no more
modifiable at runtime (2) than most other languages except Pascal, (3)
is a subjective judgement.
>1. Forth is a lot harder to read than even Lisp or APL; at my former employer,
>where we used Forth in real-time control and number-crunching applications,
>we called it a "write-only" language.
A lot of this has to do with programming style. It is possible to write
readable Forth code, see the book "Thinking Forth". And it is also possible
to write unreadable programs in any language.
>2. There are many incompatible implementations of Forth, and even
>implementations from the same vendor behave radically different on
>different processors.
The vendor in question must be Forth, Inc. They strive to be incompatible
between their implementations. This is not the case for products of
Laboratory Microsystems, MicroMotion, F83, and even the ancient FIG Forths.
>3. The debugging support is non-existent.
The public domain F83 has an interactive debugger. A display-oriented
debugger is an option for Laboratory Microsystems IBM-PC product.
>4. The primitive set of operators is *very* large; and it is not orthogonally
>constructed; the names are not even *close* to mnemonic; and many operators
>have uncontrollable side effects outside the modules in which they are used.
>
Unfortunately, true, but most names are mnemonic and quite a few others are
understandable after you know the naming conventions. For instance "." in a
name always means "print", "?" at the beginning of a name means it does
something conditionally, and "?" at the end of the name means it leaves a
boolean result.
>5. Forth is not structured, typed, or anything like that. When
>using Forth, you may forget anything you learned from Software Tools, or
>Elements of Programming Style, or Niklaus Wirth, or, roughly speaking,
>the last 15 years of evolution in programming techniques.
>
Well it is structured, at least as far as control structures are concerned.
There are no "gotos". Provided control structures are:
1. IF statement, with optional ELSE. Never any ambiguity of association
between IF and ELSE like in some other languages.
2. DO LOOP structure. Most implementations have a variation which allows
skipping the block if it is to be executed zero times. Loop can count
up, count down, or count by a varying amount (positive negative or zero
on any particular iteration). A command exists to exit a loop in the
middle.
3. Two iterative structures, one with conditional exit at the end, and the
other with conditional exit anywhere in the middle.
4. Most implementations have a CASE statement. For those that don't, it
can be easily (and in an implementation independent way) be added.
Data structures can be added as desired.
>And now, I'd like to quote another article that appeared at the time:
>
>> From: li...@nbs-amrf.UUCP
>> Newsgroups: net.ai
>> Subject: Forth for AI? NO!
>> Date: Sun, 22-Jan-84 19:54:16 EST
>>
>> 1) Manipulating programs as data in Forth is difficult. Also
>> impractical, since it has no garbage collection. You can't expect to
>> service high-priority interrupts if you've just run out of space!
>> (Forth's primary use is for real-time control.)
But this was cited as undesirable in (2).
>> 2) Can't pass arguments explicitly. You must pass information by
>> putting it on the stack. Since I pushed the 2nd arg at line 6 and then
>> used the stack to do something else, what are the odds that at line 23,
>> I can push the 3rd arg on the stack and then call that function with
>> confidence? Reading code, trying to find out what the arguments are, is
>> like counting parens in Lisp, except now imagine that every atom in the
>> list manipulates the count of ('s and )'s!
You can pass arguments in variables and there are several published techniques
to create named parameters (so they can be accessed without stack
manipulation). But the biggest flaw here is "line 23". The proper Forth
programming technique is to have lots of small functions rather than a few
big ones because subroutine calls are cheap. I have a 5000 line Forth
application, and there is only one function longer than 15 lines and no
more than a dozen longer than ten lines. Forth code can also be DOCUMENTED
(anybody know what that word means?) with comments as to stack contents.
>>
>> 3) Forward referencing (including recursion) is not normal and must be
>> done by manipulating compiled code. Bye-bye portability. Indeed, I have
>> never seen anyone write a recursive Forth routine (although it can be
>> done). Bye-bye AI.
True, it is not normal, but it can be done in a portable fashion without
manipulating compiled code. I have written many recursive Forth routines,
and recursion is *VERY* efficient in Forth. Also Forth metacompilers and
compiler do allow for forward referencing at the cost of not being
interactive (in other words "batch").
>> 4) Code is generated as you type (or load) in Forth source. Hence you
>> lose all possible benefits of a good compiler, i.e. type-checking,
>> optimization, etc. As for syntax checking, forget it. The syntax of
>> the language is so simple, almost every combination of Forth words is
>> syntactly correct (although meaningless). If you mistyped that last
>> word, you'll find out at run-time.
Control structures are checked for syntatic correctness. Compilers can
do optimizations and produce code quality comparable with that of C or
Pascal. If you mistype a word you find out right away (assuming that
the word is not a valid Forth word).
>> 5) Scoping, name-space rules are terrible. For example, it is impossible to
>> write a subroutine that uses variables that are *guaranteed* to be local.
>> (How can you ever be confident about your code?)
You CAN write subroutines that use variables guaranteed to be local (technique
requires writing of three one-line routines which localize the scoping of
selected words (which may not only be variables but also other subroutines).
You can also write code without worrying about redefining existing routines
(no reserved words or function names) since your definitions do not alter
the operation of the existing functions. Thus if your application were so
brash as to redefine the operation of "+", the Forth nucleus would continue
to use the original version.
>>
>> 6) The emphasis on Forth is on speed at the cost of everything else. For
>> example, if you can keep track of all data by storing it on the stack,
>> great, but if you have to use a variable (no less a structure) you start
>> losing efficiency. Using a variable in Forth is akin to using those
>> features in PL/I that are great but really slow the runtimes down. And
>> Forth simply isn't fast to begin with. Any decent compiler can do better
>> (then "threaded-code").
Using variables in Forth is frequently faster than stack manipulation.
Forth compilers can handle variables with the same efficiency as other
compilers. No Forth programmer will ever claim that threaded-code is faster
than true compilation, but it is faster than other interpreted languages such
as BASIC LISP and Smalltalk. The use of threaded code allows for very fast
and incremental compilation which greatly reduces the edit-compile-test
cycle time of program debugging. If the final program is insufficiently
fast, then portions of it can be compiled or rewritten in assembly language.
>> 7) The only messages from the system are "ok", "?" (meaning "I don't
>> know that word") and "stack empty". (It might check stack-full and some
>> others, but these are the only msgs I've ever gotten.) This is very
>> consistent with the Forth philosophy (see 6.) but really unhelpful.
>> Debugging note: If Forth encounters a word it doesn't know, the stack is
>> popped. Since the only other error is when the stack is empty, it is
>> impossible to tell where you died by looking at the stack!
Again, this looks like Forth Inc.'s product which is very user unfriendly!
Laboratory Microsystem Forth's manual lists 39 error messages. Forth
discovers words it doesn't know at compile time, so you know exactly
where the error is. Most systems do not tell you where you are when runtime
errors occur. Most systems also provide hooks in the error routines so
that you can do anything you want (including examining the stack).
There are occasions to choose Forth, as well as occasions to avoid it.
I find that I can develop programs far faster in Forth than in C or
Pascal. But I do use C or Pascal for programs that make heavy use of
data structures (that are directly supported by these languages).
For character string manipulation I still prefer BASIC.
Tom Almy
Bill Thomas
the "/Ze" option using their "far" feature does not work on Automatic
variables (they are ignored) so one can't get SEG:OFFSET pointers
in Calls. This in turn makes the /Axxxw option next to you know
what because in the /AM or /AS (SMALL Data) a call could have
a 16 bit (offset) pointer which should be SS:offset or DS:offset
and if the called routine has ESP your ok!!!!.
In addtion in the Large Data model every Global variable gets its
own segment. That is they don't collect them to cut down on loading
the ES. So the Large Data model is SLOW SLOW & you can't get
around it with their funny "/Ze" "far" stuff!
Jerrold Gray
> It seems that Forth is as extensible and structured as C and Pascal (to my
> understanding), and generates more compact and faster execution program.
> Its interpreter being far more faster than BASIC's makes developement time of a
> project much less than when using 'edit-compile-link-test' type of language.
> I wonder why Forth is still less popular (to my impression) than C and Pascal.
>
It has been my experience that whenever speed has been the critical issue,
critical components ( if not all ) of a software package should be written
in assembly language. This optimizing for speed is at the expense of
development time and the general level of support by other developers.
I suspect that the reason Forth is not more popular is that software
support in Forth is more difficult than in the other languages you
cited. The effort expended in support (debugging or adding features)
is product of understanding the native language used as well as the
architecture and symbology of the orginal author. The "keyword" here
is "cryptic".
In assembly language the symbology is fairly fixed so you only have to
deal with the native language (op codes) and the program structure.
Though in a higher level language, the symbology of Fortran and most
flavors of BASIC is also pretty much predefined. The languages in between
allow a lot of freedom to make software extremely cryptic, with
the effect peaking in Forth. I also suspect some people have raised
software cryptography to another artform.
As an effective test of which language to use. Get good and drunk on
several occasions, and write several pages of code ( to do something
harmless of course) whilst under the influence. The result doesn't have
to be entirely working when finished. Before sobriety returns, hide your
source code somewhere where you won't find it for a few weeks.
If and when you find it, try to understand it. Better yet... try to fix it.
My recommendation is to stick with C or Pascal linked to assembly coded
critical routines where necessary.
Jerrold L. Gray
uw-beaver!telone!dataio!pilchuck!jgray
USNAIL: 10525 Willows Road N.E. /C-46
Redmond, Wa. 98052
(206) 881 - 6444 x478
Telex: 15-2167
Wombat
>Normally I don't bother to flame back at flames, but this one has some
>errors that I cannot ignore.
Flame?! You must be joking; I didn't even turn the torch on! Oh, well...
>In article <681@pucc-j> r...@pucc-j.UUCP (Wombat) writes:
>>
>>There are severe problems with Forth that prevent it from being much more than
>>an interesting (failed) exercise in threaded-interpretative language design.
>>
>>It is (1) compact, (2) modifiable at runtime, (3) extensible and (4) hard to
>>read. Some of these are also features/flaws of other languages, depending on
>>your viewpoint. However, I'd like to point out the following:
>
>I fail to see how item (1) could be considered a "flaw", Forth is no more
>modifiable at runtime (2) than most other languages except Pascal, (3)
>is a subjective judgement.
I did not claim that (1) was a flaw; for that matter, I did not claim that
(2), (3), or (4) were flaws either. I claimed that (1) through (4) were
properties of the language "Forth" and that they were features or, OR,
flaws of other languages. Please read what I wrote, not what you think I wrote.
Onwards. (2) is certainly true of Forth, and certainly not true of languages
like C or Pascal, unless someone is really determined. However, it appears
to be a standard technique in Forth to write modifiable code. It certainly
is easy to do--much, much easier than in C or Pascal. I have seen enough
examples of such coding (by competent Forth programmers) to convince me
that such practices are status quo in the Forth community.
Now, then. (3) is most certainly not a subjective judgement; it is the core
of the Forth philosophy. If you do not understand this, then you lack a
basic understanding of how Forth works. I would be most curious to see
an example of a Forth program (of modest size) which did not define any
new "words" in order to perform a useful task.
>>1. Forth is a lot harder to read than even Lisp or APL; at my former employer,
>>where we used Forth in real-time control and number-crunching applications,
>>we called it a "write-only" language.
>
>A lot of this has to do with programming style. It is possible to write
>readable Forth code, see the book "Thinking Forth". And it is also possible
>to write unreadable programs in any language.
This is certainly true; however, the tendency to write unreadable code is
accentuated in Forth because the language itself provides no help whatsoever
to aid the programmer in writing clean code.
>>2. There are many incompatible implementations of Forth, and even
>>implementations from the same vendor behave radically different on
>>different processors.
>
>The vendor in question must be Forth, Inc. They strive to be incompatible
>between their implementations. This is not the case for products of
>Laboratory Microsystems, MicroMotion, F83, and even the ancient FIG Forths.
The vendor in question is *ALL* Forth vendors; the supposed Forth '79 standard
would appear to firmly entrenched in quicksand. My experience has been
that porting Forth is far worse a nightmare than porting Pascal, C, or Fortran.
>>3. The debugging support is non-existent.
>
>The public domain F83 has an interactive debugger. A display-oriented
>debugger is an option for Laboratory Microsystems IBM-PC product.
I will amend my statement to be "almost non-existent".
>>4. The primitive set of operators is *very* large; and it is not orthogonally
>>constructed; the names are not even *close* to mnemonic; and many operators
>>have uncontrollable side effects outside the modules in which they are used.
>
>Unfortunately, true, but most names are mnemonic and quite a few others are
>understandable after you know the naming conventions. For instance "." in a
>name always means "print", "?" at the beginning of a name means it does
>something conditionally, and "?" at the end of the name means it leaves a
>boolean result.
"understandable after you know the naming conventions" is an excuse; it is
similar to claiming that the selection of "der", "die" or "das" for the
definite article is understandable once one knows the naming conventions
of German. Both claims are utter nonsense; knowledge of N Forth operators
does not appear to lend significant aid when attempting to decipher the
meaning of a newly-encountered operator. [...any more than knowing that
doors are feminine and cars are neuter helps predict what German grammar
will consider elevators to be...]
The problem of operator overlap is even nastier, however; I can't recall
ever seeing a language where there are so many ways to do the same thing,
each of which has different obscure side effects from the other.
>>5. Forth is not structured, typed, or anything like that. When
>>using Forth, you may forget anything you learned from Software Tools, or
>>Elements of Programming Style, or Niklaus Wirth, or, roughly speaking,
>>the last 15 years of evolution in programming techniques.
>
>Well it is structured, at least as far as control structures are concerned.
>There are no "gotos". Provided control structures are:
>1. IF statement, with optional ELSE. Never any ambiguity of association
> between IF and ELSE like in some other languages.
>2. DO LOOP structure. Most implementations have a variation which allows
> skipping the block if it is to be executed zero times. Loop can count
> up, count down, or count by a varying amount (positive negative or zero
> on any particular iteration). A command exists to exit a loop in the
> middle.
>3. Two iterative structures, one with conditional exit at the end, and the
> other with conditional exit anywhere in the middle.
>4. Most implementations have a CASE statement. For those that don't, it
> can be easily (and in an implementation independent way) be added.
>
>Data structures can be added as desired.
You, my lucky friend, are working with a Forth onto which someone has
added some semantic sugar. However, possession of a do-loop, a couple
of conditionals, and an iterative structure does not make Forth a
structured language.
"Date structures can be added as desired", eh? Well, one could argue that
they could added to assembly language as well. The point is that Forth
does *NOT* have any, and most of us with some programming to do have better
ways to occupy ourselves than figuring out how to introduce Forth to
concepts like struct{} or union{}, or array[] for that matter.
I don't even want to think about what it would take to implement
type-checking; I'd rather rewrite tar(1) in Lisp.
>>And now, I'd like to quote another article that appeared at the time:
>>
>>> From: li...@nbs-amrf.UUCP
>>> Newsgroups: net.ai
>>> Subject: Forth for AI? NO!
>>> Date: Sun, 22-Jan-84 19:54:16 EST
>>>
>>> 1) Manipulating programs as data in Forth is difficult. Also
>>> impractical, since it has no garbage collection. You can't expect to
>>> service high-priority interrupts if you've just run out of space!
>>> (Forth's primary use is for real-time control.)
>
>But this was cited as undesirable in (2).
Wrong. Also note that manipulate != modify.
>>> 2) Can't pass arguments explicitly. You must pass information by
>>> putting it on the stack. Since I pushed the 2nd arg at line 6 and then
>>> used the stack to do something else, what are the odds that at line 23,
>>> I can push the 3rd arg on the stack and then call that function with
>>> confidence? Reading code, trying to find out what the arguments are, is
>>> like counting parens in Lisp, except now imagine that every atom in the
>>> list manipulates the count of ('s and )'s!
>
>You can pass arguments in variables and there are several published techniques
>to create named parameters (so they can be accessed without stack
>manipulation). But the biggest flaw here is "line 23". The proper Forth
>programming technique is to have lots of small functions rather than a few
>big ones because subroutine calls are cheap. I have a 5000 line Forth
>application, and there is only one function longer than 15 lines and no
>more than a dozen longer than ten lines. Forth code can also be DOCUMENTED
>(anybody know what that word means?) with comments as to stack contents.
Oh, bullshit. The point, again, is that Forth, as is, does not have these
"published techniques". Such claims are akin to asserting that C has runtime
checking because one vendor has an implementation of it. I can't speak for
the other correspondent, but I'd prefer to discuss the *language*, not the
amalgamation of all available features from all vendors.
Let's do some arithmetic. 5000 lines of code; discarding your one very
long function and generously assigning a length of 10 to the remaining
functions yields a count of 500 functions. 500 FUNCTIONS!! Is *this*
the way to write a program?! No thanks. Incidentally, I think the
original correspondent's point is valid even if "23" is replaced with "9";
you are once again grasping at straws.
"DOCUMENTED...with comments as to stack contents" Hmm, I seem to remember
doing a fair amount of that when writing assembler; doesn't sound like much
of an improvement to me.
>>> 3) Forward referencing (including recursion) is not normal and must be
>>> done by manipulating compiled code. Bye-bye portability. Indeed, I have
>>> never seen anyone write a recursive Forth routine (although it can be
>>> done). Bye-bye AI.
>
>True, it is not normal, but it can be done in a portable fashion without
>manipulating compiled code. I have written many recursive Forth routines,
>and recursion is *VERY* efficient in Forth. Also Forth metacompilers and
>compiler do allow for forward referencing at the cost of not being
>interactive (in other words "batch").
"efficient" is a nice buzzword, but efficiency is not the issue here.
The lack of a clean, built-in, and natural way to do recursion in Forth is.
>>> 4) Code is generated as you type (or load) in Forth source. Hence you
>>> lose all possible benefits of a good compiler, i.e. type-checking,
>>> optimization, etc. As for syntax checking, forget it. The syntax of
>>> the language is so simple, almost every combination of Forth words is
>>> syntactly correct (although meaningless). If you mistyped that last
>>> word, you'll find out at run-time.
>
>Control structures are checked for syntatic correctness. Compilers can
>do optimizations and produce code quality comparable with that of C or
>Pascal. If you mistype a word you find out right away (assuming that
>the word is not a valid Forth word).
The checking of control structures for correctness does not cover all
bases; it covers very few of them. There is, as stated, no type-checking
either; and mistyping a word that *is* a Forth word is the very problem!
>>> 5) Scoping, name-space rules are terrible. For example, it is impossible to
>>> write a subroutine that uses variables that are *guaranteed* to be local.
>>> (How can you ever be confident about your code?)
>
>You CAN write subroutines that use variables guaranteed to be local (technique
>requires writing of three one-line routines which localize the scoping of
>selected words (which may not only be variables but also other subroutines).
>
>You can also write code without worrying about redefining existing routines
>(no reserved words or function names) since your definitions do not alter
>the operation of the existing functions. Thus if your application were so
>brash as to redefine the operation of "+", the Forth nucleus would continue
>to use the original version.
Uh-huh. Note that subsequent function definitions would, however, use the
new operator "+". Note also that scoping is built in to most languages,
so that kludging it in isn't required.
>>> 6) The emphasis on Forth is on speed at the cost of everything else. For
>>> example, if you can keep track of all data by storing it on the stack,
>>> great, but if you have to use a variable (no less a structure) you start
>>> losing efficiency. Using a variable in Forth is akin to using those
>>> features in PL/I that are great but really slow the runtimes down. And
>>> Forth simply isn't fast to begin with. Any decent compiler can do better
>>> (then "threaded-code").
>
>Using variables in Forth is frequently faster than stack manipulation.
>Forth compilers can handle variables with the same efficiency as other
>compilers. No Forth programmer will ever claim that threaded-code is faster
>than true compilation, but it is faster than other interpreted languages such
>as BASIC LISP and Smalltalk. The use of threaded code allows for very fast
>and incremental compilation which greatly reduces the edit-compile-test
>cycle time of program debugging. If the final program is insufficiently
>fast, then portions of it can be compiled or rewritten in assembly language.
Nonsense. Using a variable in Forth results in slow execution, and yields
ugly code, since Forth abhors non-stack parameters. The use of threaded
code has next-to-zero influence on the edit-compile-test cycle; as most
folks familiar with software engineering know, there are a couple of blocks
in there marked "think" that represent the largest expenditure of time.
Forth does nothing to reduce the time spent there.
----------
To borrow from some anonymous person on the net from a while back,
Forth is like falling in a hole, crawling out after a protracted
struggle, and then saying "Look at the great thing I've done."
I don't think anyone should take this language seriously; it's just
too hard to learn, too hard to use, and too antiquated.
--
Rich Kulawiec pucc-j!rsk or r...@asc.purdue.edu
dg...@ecsvax.uucp
disappointment with Forth: Unless you use bottom-up development you
have to write in an edit-compile-run fashion, just as in other
languages. This is because if A calls B you have to define B before A,
and if you later redefine B, A still calls the old version.
APL (and LOGO and a few non-standard Forths) offer a much nicer
approach. You can write B as a stub routine and redifine it later.
Routine A always calls the latest version of B. This is the way an
interpretive environment should work!
I became a fanatical convert to this point of view when (many years ago
when I had time for such things) I wrote an adventure game development
system in APL. I could build a few rooms, meander around in them
awhile, add a few more, toss in a few new verbs and objects, and so on,
all very interactively and with absolutely no waiting for the computer
to do anything. Programmer heaven!
--
D Gary Grady
Duke U Comp Center, Durham, NC 27706
(919) 684-3695
USENET: {seismo,decvax,ihnp4,akgua,etc.}!mcnc!ecsvax!dgary
Doug Collinge
>In article <4...@tekchips.UUCP> to...@tekchips.UUCP (Tom Almy) writes:
>>Normally I don't bother to flame back at flames, but this one has some
>>errors that I cannot ignore.
>>In article <681@pucc-j> r...@pucc-j.UUCP (Wombat) writes:
>>>There are severe problems with Forth that prevent it from being much more than
>>>an interesting (failed) exercise in threaded-interpretative language design.
>>>1. Forth is a lot harder to read than even Lisp or APL; at my former employer,
>>>where we used Forth in real-time control and number-crunching applications,
>>>we called it a "write-only" language.
It has to be just as hard to write "readable" C code but no-one calls it a
"write-only" language. The difference, perhaps, is that C is written, by and
large by university-educated programmers and Forth is not. Let's face it:
there are no "readable" languages, only "readable" programs.
>>>> 2) Can't pass arguments explicitly.
This must be the biggest readability problem - in fact, it is simply horrible.
However, when I realized this, I just wrote the code to put named parameters
into the language. Try that in your favourite language. Granted, it should
be an option in the standard...
>>>> 3) Forward referencing (including recursion) is not normal. Bye-bye AI.
Recursion is no problem. Mutual recursion IS a problem that can be solved
in a portable, albeit horrible, way. Don't do AI in Pascal, C, FORTRAN, or
Forth.
>>>> 5) Scoping, name-space rules are terrible.
Forth programmers don't seem to use vocabularies as extensively as they ought.
Using vocabularies we can write nice modules with all the nasty stuff neatly
hidden away.
>Forth is like falling in a hole.
Well, each to his own: Berkeley Unix is the biggest, deepest hole I have ever
fallen into and I don't expect to ever make it out.
The bottom line is: does it get the job done? I was extremely skeptical about
Forth when I started but now I wouldn't use anything else for process control
applications like my own, computer-cotnrolled art.
--
Doug Collinge
School of Music, University of Victoria,
PO Box 1700, Victoria, B.C.,
Canada, V8W 2Y2
decvax!nrl-css!uvicctr!collinge
decvax!uw-beaver!uvicctr!collinge
ubc-vision!uvicctr!collinge
Tim Smith
>
>The lack of a clean, built-in, and natural way to do recursion in Forth is.
>
I use recursion in Forth. What difference does it make if it is built-in?
It is simple to add, and does _exactly_ the same thing that built-in
recursion would do. It is clean and natural. Why build something into
a language that not everybody wants, and that those who do can easily add?
Forth: the Unix V6 of languages.
--
Tim Smith sdcrdcf!ism780c!tim || ima!ism780!tim || ihnp4!cithep!tim
Peter da Silva
> like C or Pascal, unless someone is really determined. However, it appears
> to be a standard technique in Forth to write modifiable code. It certainly
> is easy to do--much, much easier than in C or Pascal. I have seen enough
> examples of such coding (by competent Forth programmers) to convince me
> that such practices are status quo in the Forth community.
I'm a competant FORTH programmer. I have written a *LOT* of programs in FORTH,
including two special-purpose compilers, a screen editor and a display generat-
or, and untold numbers of utilities. I have never used self-modifying code.
> Now, then. (3) is most certainly not a subjective judgement; it is the core
> of the Forth philosophy. If you do not understand this, then you lack a
> basic understanding of how Forth works. I would be most curious to see
> an example of a Forth program (of modest size) which did not define any
> new "words" in order to perform a useful task.
I would be happy to post such a program to the net (by new words I assume you
mean new control- and data- structures, not just subroutines), but I am not
at liberty to do so (trade secrets, copyrights, and other unfunny things
stand in the way).
> >>1. Forth is a lot harder to read than even Lisp or APL; at my former employer,
...
>
> This is certainly true; however, the tendency to write unreadable code is
> accentuated in Forth because the language itself provides no help whatsoever
> to aid the programmer in writing clean code.
This is not really true. A better way of putting it would be that the author
of FORTH, Chuck Moore, writes horrible code... and this has diffused down into
the FORTH community as a whole. WARNING: DO NOT USE FORTH FOR YOUR FIRST
LANGUAGE. Learn to *program* first. And if at all possible throw screen files
out the window & use regular text files (the UNIX FORTH I posted to the net a
while ago does this).
> >>2. There are many incompatible implementations of Forth, and even
> >>implementations from the same vendor behave radically different on
> >>different processors.
True. Except that FIG-FORTH is extremely portable (having ported a screen
editor between FIG forths in the Apple-][+, CP/M, RSX, and RTE-IVB (HP1000)).
Careful non-use of "find", "-find", "?find", and other obscenities can
ameliorate this problem considerably. Avoiding assembly language helps a lot
too.
> >>3. The debugging support is non-existent.
That depends. The support for code development is extremely good (how many
languages have interactive source-level debuggers built in?). After that,
though, you have to fall back on lots of dot-quotes and cross your fingers.
> You, my lucky friend, are working with a Forth onto which someone has
> added some semantic sugar. However, possession of a do-loop, a couple
> of conditionals, and an iterative structure does not make Forth a
> structured language.
A language in which GOTOS are virtually impossible "unstructured"? Sorry,
cheap shot. At least FORTH is more structured than the alternative: assembly.
In an application where FORTH is used you generally don't have the option
of using another "high" level language.
> >>> 3) Forward referencing (including recursion) is not normal and must be
> >>> done by manipulating compiled code. Bye-bye portability. Indeed, I have
> >>> never seen anyone write a recursive Forth routine (although it can be
> >>> done). Bye-bye AI.
: recursive-routine
blah blah blah
[ smudge ] recursive-routine [ smudge ] ( bletch. horrible syntax )
blah blah blah ;
> >>> optimization, etc. As for syntax checking, forget it. The syntax of
> >>> the language is so simple, almost every combination of Forth words is
> >>> syntactly correct (although meaningless). If you mistyped that last
> >>> word, you'll find out at run-time.
Only in Chuck "syntax checking? that's inefficient!" Moore's implementation.
> >>> 5) Scoping, name-space rules are terrible. For example, it is impossible to
> >>> write a subroutine that uses variables that are *guaranteed* to be local.
> >>> (How can you ever be confident about your code?)
vocabulary barvoc immediate
barvoc definitions
0 variable var1 ( ... )
forth definitions
: bar
barvoc
blah blah blah var1 blah blah blah ;
> Uh-huh. Note that subsequent function definitions would, however, use the
> new operator "+". Note also that scoping is built in to most languages,
> so that kludging it in isn't required.
See above definition.
> Nonsense. Using a variable in Forth results in slow execution, and yields
> ugly code, since Forth abhors non-stack parameters. The use of threaded
> code has next-to-zero influence on the edit-compile-test cycle; as most
> folks familiar with software engineering know, there are a couple of blocks
> in there marked "think" that represent the largest expenditure of time.
> Forth does nothing to reduce the time spent there.
No, but reducing the time spent compiling code (and arguing about the latest
language at the desk instead of on usenet) is an admirable goal.
> ----------
> To borrow from some anonymous person on the net from a while back,
> Forth is like falling in a hole, crawling out after a protracted
> struggle, and then saying "Look at the great thing I've done."
> I don't think anyone should take this language seriously; it's just
> too hard to learn, too hard to use, and too antiquated.
> --
If you have anothe alternative, by all means use it. Most of the time the
only alternative to FORTH is assembly language because of memory constraints
and/or the lack of a good host system. In that case, go FORTH and prosper.
--
-- Peter da Silva
-- UUCP: ...!shell!{baylor,graffiti}!peter; MCI: PDASILVA; CIS: 70216,1076