wmb@MITCH.ENG.SUN.COM (Mitch Bradley) (12/05/90)
> use it over and over again. extensibility without testability is insanity. > Spell it `C' (sorry, Mitch: I realize that C is not untestable. It's just > harder for me, and takes longer in general.) No argument from me. I too find Forth easier to test than C, and prefer to program in Forth than in C. In promoting Forth, I find that a balanced viewpoint (C has these strengths and these weaknesses, Forth has these strengths and these weaknesses) is more effective overall than the extreme positions (C sucks; it is horrible. Forth is God's gift to programmers) sometimes espoused by Forth fans. I don't consider the statement quoted above to be extreme. In particular, the portion in parentheses is balanced and accurate. If I sometimes appear to be promoting C, consider this: A moderate looks like a liberal to an extreme conservative, and like a conservative to an extreme liberal. C is a useful, useable, and extremely popular language. I prefer Forth. Mitch
bouma@cs.purdue.EDU (William J. Bouma) (12/07/90)
In article <9012051459.AA18739@ucbvax.Berkeley.EDU> Mitch Bradley <wmb%MITCH.ENG.SUN.COM@SCFVM.GSFC.NASA.GOV> writes: >> use it over and over again. extensibility without testability is insanity. >> Spell it `C' (sorry, Mitch: I realize that C is not untestable. It's just >> harder for me, and takes longer in general.) > >No argument from me. I too find Forth easier to test than C, and >prefer to program in Forth than in C. Isn't the main reason for this because FORTH is interactive and the C you are using is not? Interactive languages are always easier to debug and program. There are other interactive languages besides FORTH! >In promoting Forth, I find that a balanced viewpoint (C has these strengths >and these weaknesses, Forth has these strengths and these weaknesses) is >more effective overall than the extreme positions (C sucks; it is horrible. >Forth is God's gift to programmers) sometimes espoused by Forth fans. Definitely! "More effective" is exactly the way to put it. Whenever I encounter the extremist viewpoint from someone, their credibility goes way down. It says to me they both don't have much programming language experience, and they are prone to jump to conclusions. Why should I listen to anything such a person has to say? Why are these people not capable of saying, "FORTH is great", without including "C sucks" along with it? C may indeed suck, but try comparing FORTH to the myriads of other languages out there, including the other interactive ones. Then tell us what makes FORTH different. -- Bill <bouma@cs.purdue.edu>
cwpjr@cbnewse.att.com (clyde.w.jr.phillips) (12/07/90)
> with it? C may indeed suck, but try comparing FORTH to the myriads of > other languages out there, including the other interactive ones. Then > tell us what makes FORTH different. > -- > Bill <bouma@cs.purdue.edu> FORTH being one of the fastest interpreters has a lot to do with it: Most other interpreters seem like batch-job shells! The architecture of FORTH: Most other interpreters aren't *simply* exstensible and as well factored on the "kernal level". The architecture of FORTH: Words for subroutines! Yeah! Support for all major programming paradigms including OOP built-in! Since 1971! Yeah! The architecture of FORTH: Designed as a *doable* processor (being emulated at first ) that happens to run a language! The architecture of FORTH: Simplicity and elegance with a learned twist. --Clyde
ir230@sdcc6.ucsd.edu (john wavrik) (12/07/90)
# In article <9012051459.AA18739@ucbvax.Berkeley.EDU> Mitch Bradley
# <wmb%MITCH.ENG.SUN.COM@SCFVM.GSFC.NASA.GOV> writes:
# >> use it over and over again. extensibility without testability
# >> is insanity. Spell it `C' (sorry, Mitch: I realize that C is not
# untestable. It's just
# >> harder for me, and takes longer in general.)
# > No argument from me. I too find Forth easier to test than C, and
# >prefer to program in Forth than in C.
#
# Isn't the main reason for this because FORTH is interactive and
# the C you are using is not? Interactive languages are always
# easier to debug and program. There are other interactive
# languages besides FORTH!
Bill Bouma's point is well taken. I think that ease of debugging
(which comes from persistence of values of variables and the ability
to execute parts of a program) is in fact characteristic of all
interactive (interpreted) languages. Another feature common to these
languages is the ability to produce what Forth programmers call an
"application" as distinguished from a program. An application is a
collection of commands designed for independent interactive
execution. A program is, in essence, an application with a single
top-level word (RUN or MAIN or whatever). Conventional compiled
languages produce programs.
The fact is that for quick development and debugging, an interactive
environment is desirable. That other languages also offer this does
not negate the fact that Forth does too -- and that it is an asset.
'C' does not have this feature (nor does Pascal, FORTRAN, Modula2,
Ada, etc.)
While on this subject, "factoring" is a programming technique not a
Forth feature. It can be practiced to advantage in all languages
(including non-structured languages like FORTRAN and BASIC). I've had
some of the graduates from my Forth course tell me that they have
used Forth-style programming techniques with good results in their
jobs (using 'C') -- they factor more than their 'C' trained
counterparts -- and they feel that they can produce correct programs
more quickly as a result. In another direction: the programs in the
text "Structure and Interpretation of Computer Programs" by Abelson,
Sussman, Sussman show as much factoring as typical Forth programs --
and the language used is Scheme.
The idea that Forth programmers use (and have used) a technique which
is now recognized as "good style" speaks well for Forth and Forth
programming techniques --- but is not what makes Forth Forth.
# >In promoting Forth, I find that a balanced viewpoint (C has these
# >strengths and these weaknesses, Forth has these strengths and these
# >weaknesses) is more effective overall than the extreme positions (C
# >sucks; it is horrible. Forth is God's gift to programmers) sometimes
# >espoused by Forth fans.
#
# Definitely! "More effective" is exactly the way to put it.
# Whenever I encounter the extremist viewpoint from someone, their
# credibility goes way down. It says to me they both don't have much
# programming language experience, and they are prone to jump to
# conclusions. Why should I listen to anything such a person has to
# say?
It may, rather, be jumping to conclusions to assume that anyone
devoted to Forth "don't have much programming language experience".
The participants in the discussion at Asilomar all seemed to have had
a great deal of programming language experience -- but all sensed a
special quality in Forth. It is indeed a subjective matter --
probably one not much studied -- but some people do perceive one
programming language to be "better" (more powerful?, more flexible?)
than another. The exercise is to identify the qualities of Forth
which account for this subjective experience in those who have it.
There are some areas of application for which programming in a
conventional compiled language (like 'C') seems extraordinarly
awkward to some people -- while Forth seems perfectly natural to
them. It isn't necessary that everyone have the same experience for
the experience to be valid. It isn't necessary for someone who has
the experience to be articulate about it. Given the gift that many
programmers have with the English language it should not be
surprising that some of them summarize their experience by "C sucks,
Forth is great".
It is not necessary to be articulate about the properties of a
programming language to use it. There are two main reasons for
wanting to be more articulate about the properties of Forth:
1. To help Forth take its place in the part of the world that talks
about programming languages (read "academic acceptance").
2. To make sure that essential properties of the language are not
lost in the process of "popularizing" it or "making it
marketable".
# C may indeed suck, but try comparing FORTH to the myriads of
# other languages out there, including the other interactive ones.
# Then tell us what makes FORTH different.
I think that the difference will eventually be found to lie in the
ability of a user (programmer) to exercise control over the features
of the language. This, in turn, will be found to come from the
simplicity of the implementation and the access a programmer has to
it.
I recall a discussion with a 'C' programmer in which I pointed out
that 'C' (like many other languages) requires new algebraic objects
to be treated with a different syntax than built-in objects. He saw
no objection to complex numbers, matrices, polynomials, etc. being
"second class citizens" -- with operations using a different syntax
than used for primary objects. I *DO* see an objection -- and I
regard a strength of Forth as the ability to add new objects with
first class status. This ability comes from the fact that the Forth
programmer has access to the language at the level at which primary
objects are introduced (so it is no surprise that he also has the
tools to introduce new objects which are treated like primitive
objects).
A good example of the distinction between Forth and other languages
is the CASE construct. Forth has not had a CASE construct (more
exactly, it has had many). Instead, Forth provides the programmer
with the ability to add a CASE construct (of any desired form) to an
application. The knowledge that a Forth programmer has of what is
compiled and how it is compiled allows him to introduce new
constructs that affect compilation.
Forth, then, has attributes common to all languages (like "factoring")
and attributes common to all interactive languages (like persistence
of variables) -- but it offers an extraordinary degree of control
over the language itself.
P.S. The main challenge to the Forth community is to show that
putting more control over the language in the hands of the
programmer can result in more power without drastically
increasing error or increasing the incidence of incompre-
hensible programs.
John J Wavrik
jjwavrik@ucsd.edu Dept of Math C-012
Univ of Calif - San Diego
La Jolla, CA 92093 dwpst@unix.cis.pitt.edu (Douglas W Philips) (12/08/90)
In article <14789@sdcc6.ucsd.edu> ir230@sdcc6.ucsd.edu (john wavrik) writes: >The fact is that for quick development and debugging, an interactive >environment is desirable. That other languages also offer this does >not negate the fact that Forth does too -- and that it is an asset. >'C' does not have this feature (nor does Pascal, FORTRAN, Modula2, >Ada, etc.) I got lost here. To what does your last "it" refer? Certainly not to interactive environments for C/Pascal, etc. Those exist. >While on this subject, "factoring" is a programming technique not a >Forth feature. ... >The idea that Forth programmers use (and have used) a technique which >is now recognized as "good style" speaks well for Forth and Forth >programming techniques --- but is not what makes Forth Forth. Agreed. >2. To make sure that essential properties of the language are not > lost in the process of "popularizing" it or "making it > marketable". Agreed. Of course, you have to know what those essential properties are in order to be able to protect them. > I *DO* see an objection -- and I >regard a strength of Forth as the ability to add new objects with >first class status. This ability comes from the fact that the Forth >programmer has access to the language at the level at which primary >objects are introduced... Well, what do you say to the C++/Ada/Smalltalk people then. They can certainly do that too. >P.S. The main challenge to the Forth community is to show that > putting more control over the language in the hands of the > programmer can result in more power without drastically > increasing error or increasing the incidence of incompre- > hensible programs. I have seen nothing so far that would enable me to distinguish PostScript from Forth. In fact, the power and popularity of PostScript would seem to have proved the point already. Forth @ 1+ PostScript ! As we have already seen, it is easy to sketch in where Forth is different from the profane edit-compile-debug languages. I think that trying to find the line between Forth and PostScript and Fifth and ... will necessitate a deeper inquiry into and understanding of the issues involved. (I could be wrong, the last time I brought up this question the answer eventually was: They're different because they are.) Even CM's own characterization of the essentials of Forth would apply to PostScript and Fifth. (I seem to recall them from a transcript of talk/speech CM gave that was reprinted in Volume one of FD, if I can find it I'll extract more details). -Doug
wmb@MITCH.ENG.SUN.COM (12/08/90)
Forth is one of the few interactive languages that are at the same time reasonably compact and reasonably fast. There are other such languages, e.g. STOIC. Forth is not necessarily the "best" such language. One of the things that makes Forth different from other languages of the same ilk is that it is (relatively) successful and other languages aren't. For whatever reason (the possibility of "dumb luck" cannot be discounted), Forth "caught on", and STOIC didn't. It is extraordinarily difficult for any particular language to "gain momentum" and develop a non-trivial user community. Often, technical issues have little to do with the momentum-building process. That is why I choose to use Forth in preference to other similar (and arguably "better", in many respects) languages, such as STOIC. Mitch Bradley, wmb@Eng.Sun.COM
wmb@MITCH.ENG.SUN.COM (12/08/90)
It strikes me that we are in the midst of a "tastes great/less filling" debate. The truth is, Forth has a lot of nice properties, many of which have already been articulated. It also has some flaws. Trying to decide which subset of good properties is the "essential Forth" is like trying to decide why you like your wife. It all boils down to the fact that some combination of attributes pleases you, and taken as a whole, they outweigh the unpleasant aspects. Also you may be stuck with her. If I had to choose any particular aspect of Forth as the "one essential feature", I would probably be forced to program in some other language. For just about anything I like about Forth, there is some other language which does that thing better. But the Forth "package deal" works for me. Ditto for my wife. (That's a setup for witty rejoinders if I ever saw one!) I bet every person has a different weighting function for adding up the values of the various language attributes. (Female readers, please invert the sex of appropriate words). Mitch Bradley, wmb@Eng.Sun.COM
wmb@MITCH.ENG.SUN.COM (12/08/90)
> I have seen nothing so far that would enable me to distinguish PostScript > from Forth. In fact, the power and popularity of PostScript would seem > to have proved the point already. Forth is faster, smaller, and more malleable than PostScript. PostScript is more regular, consistent, and elegant than Forth, and PostScript comes with dynamite graphics. You could take the graphics out of PostScript and still have a nice language, but by and large, people don't use it that way. Fifth is nice but hasn't yet "made the cut" in terms of user community size. Based on purely historical observations, it probably won't make it (the chances of any particular language "making it" is, to a first approximation, zero.) Forth has a firm foothold in certain application areas, PostScript in others. Those domains don't overlap much. Some people have asked me why I chose Forth over PostScript for use in the Sun Open Boot PROM firmware. The answers: PostScript wouldn't have fit, it would have been too slow (probably), and I know Forth better. PostScript would have been easier to "sell" to the powers-that-be. Mitch Bradley, wmb@Eng.Sun.COM
UNBCIC@BRFAPESP.BITNET (12/08/90)
> > I *DO* see an objection -- and I > >regard a strength of Forth as the ability to add new objects with > >first class status. This ability comes from the fact that the Forth > >programmer has access to the language at the level at which primary > >objects are introduced... > Well, what do you say to the C++/Ada/Smalltalk people then. They can > certainly do that too. Let's talk about C++ and Ada first. I know almost nothing about the ++ part of C++ and don't remember well Ada, but can you do: VOCABULARY COMPLEX COMPLEX DEFINITIONS : VARIABLE CREATE 2 CELLS ALLOT ; : + [ FORTH ] ROT + ROT ROT + SWAP ; : - [ FORTH ] ROT - ROT ROT - SWAP ; : SWAP 2SWAP ; : ! [ FORTH ] ROT OVER ! 2+ ! ; : @ [ FORTH ] DUP @ SWAP 2+ @ ; : . [ FORTH ] . ?DUP IF 0> IF ." +" THEN . ." i" THEN ; FORTH DEFINITIONS COMPLEX VARIABLE A VARIABLE B VARIABLE C VARIABLE D 2 3 A ! 5 1 B ! A @ B @ + C ! A @ B @ SWAP - D ! C @ . CR D @ . in Ada or C++? You can do this in Smaltalk, but there are other things you can't redefine in Smaltalk: blocks and arrays delimiters, sintax... In Forth you can redefine anything. (8-DCS)
sabbagh@acf5.NYU.EDU (sabbagh) (12/09/90)
In article <68713@unix.cis.pitt.edu> dwpst@unix.cis.pitt.edu (Douglas W Philips) writes: >In article <14789@sdcc6.ucsd.edu> ir230@sdcc6.ucsd.edu (john wavrik) writes: >> I *DO* see an objection -- and I >>regard a strength of Forth as the ability to add new objects with >>first class status. This ability comes from the fact that the Forth >>programmer has access to the language at the level at which primary >>objects are introduced... > >Well, what do you say to the C++/Ada/Smalltalk people then. They can >certainly do that too. I am currently doing my dissertation work in C++, but have had some Forth experience, so I'll try to field this question, at least for the C++ case. I believe these remarks hold for Ada and Smalltalk as well. It is true that you can overload the semantics of operators in C++, however, there are two problems: 1)you can't overload the _syntax_ and 2) you can't define new operators. 1) causes a problem in the following case: cout << 10 < 20 ? 1 : 0 << endl; which appears a lot; this is the "iostreams" way of writing things to standard output (referred to by cout). Most people want this to print "1", but in fact it prints "10"! This is because "<<" has higher precendence than the trinary operator ?:. Does this make sense for the output stream operator? No! The operator inherits the precendence of the original left-shift operator found in the origin C definition. So, overloaded operators are 1.5 class objects. How does Forth overcome this? Simple: there is NO PRECEDENCE. Forth is the true equal opportunity language: IT MAKES NO ASSUMPTIONS ABOUT WHAT YOU MEAN. Of course, this means that most of the burden is placed on _you_, but this can be handled by building a large collection of small tools. IMHO the thing that Forth implementations need the most is some way to manage large dictionaries! That's what makes Forth inaccessible to most people. The documentation requirements are much higher; not documenting acutal program, since Forth programs are self-documenting, but _systems_ documentation, i.e., what it does, which are interface words and which are implementation, etc. >>P.S. The main challenge to the Forth community is to show that >> putting more control over the language in the hands of the >> programmer can result in more power without drastically >> increasing error or increasing the incidence of incompre- >> hensible programs. > >I have seen nothing so far that would enable me to distinguish PostScript >from Forth. In fact, the power and popularity of PostScript would seem >to have proved the point already. Frankly, neither have I. I can only say that Postscript was not really designed for humans to write programs in, and Forth was. I have discovered that intellectual purity in computer language design is _far_ less important than pragmatic issues: can I write a program in this language. Finally, to answer the obvious question: why can't I use Forth for my dissertation work? The answer is: I REALLY WANT TO. I purchased Mitch Bradley's C Forth 83, which is a fine implementation of Forth (really outstanding, actually). I am using a SGI Personal Iris workstation, which has a large library to support 3d graphics. The problem is in extending Forth to provide a development environment that I'm used to. It can be done (and, in hindsight, would have taken as much time as learning C++) but it is not a small task for someone who's not being paid to be a systems programmer. Hadil G. Sabbagh E-mail: sabbagh@cs.nyu.edu Voice: (212) 998-3125 Snail: Courant Institute of Math. Sci. 251 Mercer St. New York,NY 10012 "There's a difference between being hungry and being on a diet." - Commentary about John Cougar Mellenkamp. Disclaimer: This is not a disclaimer.
ir230@sdcc6.ucsd.edu (john wavrik) (12/09/90)
Doug Philips writes:
#> I *DO* see an objection -- and I
#>regard a strength of Forth as the ability to add new objects with
#>first class status. This ability comes from the fact that the Forth
#>programmer has access to the language at the level at which primary
#>objects are introduced...
#
# Well, what do you say to the C++/Ada/Smalltalk people then. They can
# certainly do that too.
I'd say: "I guess you find the ability to create first class data
objects in your language just as powerful a tool as I find it in
mine."
#>P.S. The main challenge to the Forth community is to show that
#> putting more control over the language in the hands of the
#> programmer can result in more power without drastically
#> increasing error or increasing the incidence of incompre-
#> hensible programs.
#
# I have seen nothing so far that would enable me to distinguish
# PostScript from Forth. In fact, the power and popularity of
# PostScript would seem to have proved the point already.
I must be missing something: what point has been proved?
The popularity of Postscript is not the topic being discussed.
# Even CM's own characterization of the essentials of Forth would
# apply to PostScript and Fifth. (I seem to recall them from a
# transcript of talk/speech CM gave that was reprinted in Volume one
# of FD, if I can find it I'll extract more details).
I think Charles Moore would be the first to tell you that he has
said many things at many times (usually in 25 words or less). It
was he, by the way, who started the discussion at Asilomar.
I don't want to put words in Moore's mouth -- but I think you will
find that Forth was NOT created by developing a theory of what
characteristics a language should have, then making the language
fit the theory. Moore instead seemed to follow his instincts in
making design decisions as the language evolved. The result is
that the language assumed an identity of its own that even its
creator stands back and studies. Its a bit like the relationship
of a parent to a child.
Forth fits applications well that weren't imagined when the
language was conceived. Many design decision fit together in such
a way that Forth performs brilliantly (for some people) -- almost
defying the law of computer science gravity. The aim is to get
people who have had this experience with Forth to spend some time
trying to identify the factors responsible. There are two serious
purposes for wanting this done:
1. If a move is made to gain acceptance for the language in an
academic arena several things are needed -- among them the
ability to discuss the language in the way that other computer
languages are discussed.
2. If we, collectively, are going to alter the language --
redefining it, adding new attributes and eliminating others,
the standard advice applies: "If you don't understand it then
don't mess with it".
(The problem with the advice, of course, is that some of
the people who are messing with it may not realize that they
don't understand it!)
John J Wavrik
jjwavrik@ucsd.edu Dept of Math C-012
Univ of Calif - San Diego
La Jolla, CA 92093 dwp@willett.pgh.pa.us (Doug Philips) (12/10/90)
In <1408@acf5.NYU.EDU>, sabbagh@acf5.NYU.EDU (sabbagh) writes: > I believe these remarks hold for Ada and Smalltalk as well. [...] > It is true that you can overload the semantics of operators in C++, however, > there are two problems: 1)you can't overload the _syntax_ and > 2) you can't define new operators. [...] > How does Forth overcome this? Simple: there is NO PRECEDENCE. Forth is the > true equal opportunity language: IT MAKES NO ASSUMPTIONS ABOUT WHAT YOU MEAN. I know that SmallTalk has no precendence/syntax difference from Forth. I don't know what, if any, limitations it places on user definable names. I suspect that it doesn't care, but I can't remember anymore. > IMHO the thing that Forth implementations need the most is some > way to manage large dictionaries! That's what makes Forth inaccessible > to most people. The documentation requirements are much higher; not > documenting acutal program, since Forth programs are self-documenting, but > _systems_ documentation, i.e., what it does, which are interface words and > which are implementation, etc. I agree with that. The hardest problem I have is in memorizing the dictionary. Handy-Dandy reference cards are invaluable. Two are really needed: One sorted by word name to answer the 'What does <x> do' questions. One sorted by catagory to answer the 'Now what word does <x>' questions. > Frankly, neither have I. I can only say that Postscript was not really > designed for humans to write programs in, and Forth was. I have discovered > that intellectual purity in computer language design is _far_ less important > than pragmatic issues: can I write a program in this language. Hmm... Being a novice at both Forth and PostScript, I see the same problems in learning either language: Vocabulary explosion. The "Red" postscript book is organized in a way I find useful. How many Forth systems generators can afford to put that kind of effort into a PD or ShareWare Forth? I dispute your point about "which can I write programs in" because it smacks of the "law of least astonishment." For whom? I will certainly agree that the application system you generate with the language should be easy for non-programmers to use (i.e. use the bletchiferous prefix defining words). For programmers who are going to make an investment in really learning the language, the number of special cases is more important than any other arbitrary decisions (bytes/words/longs per cell, Direct, Indirect, native code, etc.). -Doug --- Preferred: dwp@willett.pgh.pa.us Ok: {pitt,sei,uunet}!willett!dwp
ir230@sdcc6.ucsd.edu (john wavrik) (12/11/90)
ASSORTED COMMENTS ON
What makes Forth Forth
Mitch Bradley writes,
# It strikes me that we are in the midst of a "tastes great/less
# filling" debate.
# The truth is, Forth has a lot of nice properties, many of which
# have already been articulated. It also has some flaws. Trying to
# decide which subset of good properties is the "essential Forth" is
# like trying to decide why you like your wife.
# For whatever reason (the possibility of "dumb luck" cannot be
# discounted), Forth "caught on", and STOIC didn't.
# That is why I choose to use Forth in preference to other similar
# (and arguably "better", in many respects) languages, such as STOIC.
# PostScript would have been easier to "sell" to the powers-that-be.
I don't think that there is any "debate" in progress -- what I see
(or should see) is an effort by those who feel that there is
something special in Forth to help articulate it.
Your programming language is not like your wife. You are not (I
hope) trying to get other people interested in her. Nor are you
trying to standardize her so that she becomes portable.
One of the essential reasons that certain languages "sell" to the
"powers that be" is that its supporters can articulate reasons why
other people should be interested. Acceptance of a language isn't
entirely whimsical -- usually someone is able to persuade others
that it has desirable characteristics. We've tried in the past to
sell Forth as a branch of Zen Buddhism -- having failed at that I
don't think we'll do much better making it as mystical as a spouse.
Here's a novel idea: suppose we try selling Forth in terms of
recognized computer language characteristics.
If the posting is intended as an expression of impatience with
replies of the "I can do that in C++, Ada or even ABC, URTH, STOIC,
SKIZL, ACTOR, Smalltalk, BOXER, GASP, Gorpol, or PolyWog" I agree.
While it is important to know that Forth can reproduce some highly
regarded features of other languages, this does not establish what
Forth has to offer in its own right. "I'd rather be programming in
STOIC but Forth is more established" is an honest reply -- but
equally irrelevant.
I don't really see this thread as an opportunity for programmers in
other languages to tell us how they would like to rearrange the
furniture to make Forth more like their language. Personally, I
think that Forth suffers from an overabundance of furniture movers.
Instead it would be productive for the people who find that Forth
strikes a particularly responsive chord to imagine that, after
hearing your response, I will go speak to the unconvinced with your
words in my mouth. I will try to convince them of the value of Forth
by citing the features that you have told me are responsible for
making Forth what it is.
John J Wavrik
jjwavrik@ucsd.edu Dept of Math C-012
Univ of Calif - San Diego
La Jolla, CA 92093 dwp@willett.pgh.pa.us (Doug Philips) (12/13/90)
In <14813@sdcc6.ucsd.edu>, ir230@sdcc6.ucsd.edu (john wavrik) writes: > Doug Philips writes: > # I have seen nothing so far that would enable me to distinguish > # PostScript from Forth. In fact, the power and popularity of > # PostScript would seem to have proved the point already. > > I must be missing something: what point has been proved? > The popularity of Postscript is not the topic being discussed. Ok, I was being too obscure. My point was that I was assuming PostScript and Forth were similar enough languages that PostScript's success might be something, fait accompli, that would show (to whomever it is supposed to be shown) "that putting more control over the language in the hands of the programmer can result in more power without drastically increasing error or increasing the incidence of incomprehensible programs." > I don't want to put words in Moore's mouth -- but I think you will > find that Forth was NOT created by developing a theory of what > characteristics a language should have, then making the language > fit the theory. Moore instead seemed to follow his instincts in > making design decisions as the language evolved. The result is > that the language assumed an identity of its own that even its > creator stands back and studies. Its a bit like the relationship > of a parent to a child. I never intended to assert that Forth was designed rather than evolved. On the other hand, your analogy doesn't work. There is nothing in Forth that wasn't put there, even if "unconciously." Because Forth was evolved you can't analyze it to find out what is "essential Forth" and what is "accidental Forth"? There are many languages called Forth: Forth-79 fig-Forth, Forth-83, etc. No one seems to dispute that regardless of differences in the spelling of the words used to make defining words, differences in dictionary structure (such as PC "separate segments"), presence or absence of vocabularies of n different kinds, differences in the inner interpreter (indirect threaded, direct threaded, native code), there must be something more fundamental than those things which groups them all as Forth, yet manages to exclude PostScript. > trying to identify the factors responsible. There are two serious > purposes for wanting this done: I assume you aren't limiting the list to just these two items. > 1. If a move is made to gain acceptance for the language in an > academic arena several things are needed -- among them the > ability to discuss the language in the way that other computer > languages are discussed. Just think of all that cretinous parsing and lexing theory you can trash by teaching Forth! Plus the complicated intermediate compiler structures. Even optimizing Forth compilers are easy to do and extensible (see recent Forth Dimensions). Compare and contrast with the direction of Ada/C++ and see whether academia is in love with complexity (gratuitous or not). I doubt that the solution to academically-legimitizing Forth is a simple one. -Doug --- Preferred: dwp@willett.pgh.pa.us Ok: {pitt,sei,uunet}!willett!dwp
dwp@willett.pgh.pa.us (Doug Philips) (12/13/90)
In <9012092322.AA04013@ucbvax.Berkeley.EDU>, UNBCIC@BRFAPESP.BITNET writes: > > > I *DO* see an objection -- and I > > >regard a strength of Forth as the ability to add new objects with > > >first class status. This ability comes from the fact that the Forth > > >programmer has access to the language at the level at which primary > > >objects are introduced... > > > Well, what do you say to the C++/Ada/Smalltalk people then. They can > > certainly do that too. > > VOCABULARY COMPLEX COMPLEX DEFINITIONS > : VARIABLE CREATE 2 CELLS ALLOT ; > : + [ FORTH ] ROT + ROT ROT + SWAP ; > : - [ FORTH ] ROT - ROT ROT - SWAP ; > : SWAP 2SWAP ; > : ! [ FORTH ] ROT OVER ! 2+ ! ; > : @ [ FORTH ] DUP @ SWAP 2+ @ ; > : . [ FORTH ] . ?DUP IF 0> IF ." +" THEN . ." i" THEN ; > > FORTH DEFINITIONS > > COMPLEX [examples elided... -dwp] [Donning devil's advocate hat here...] Of course, not all Forth's have vocabularies. Even those that do don't all work the same (witness the headaches this caused the X3J14 TC.) Of course you can do the same kind of thing using an OOF, but thats a horse of a different can of worms. Second, the use of vocabularies as you show here has the same kind of flaw that HEX DECIMAL and OCTAL do. It is easy to forget which vocabulary is currently active. That is one reason why some have experimented with prefix and postfix "base qualifiers" on numeric constants. I think a better case for "making first class objects" would be using defining words, but I'm not sure. -Doug --- Preferred: dwp@willett.pgh.pa.us Ok: {pitt,sei,uunet}!willett!dwp
dwp@willett.pgh.pa.us (Doug Philips) (12/13/90)
In <9012092322.AA04007@ucbvax.Berkeley.EDU>, wmb@MITCH.ENG.SUN.COM writes: > > Forth is faster, smaller, and more malleable than PostScript. I was wondering when that would come up. Until we know what Forth is and what PostScript is (or how it is fundamentally different from Forth), we can't make those kinds of comparisons. You might as well say that XYZ Forth on a Z-80 is slower than ABC Forth on a 100MHz XTR-200. > PostScript is more regular, consistent, and elegant than Forth, and > PostScript comes with dynamite graphics. You could take the graphics > out of PostScript and still have a nice language, but by and large, > people don't use it that way. And you could add dynamic memory management and host os file I/O and ..., to Forth, but by and large no two Forth programmer would do it the same way. The question of "libraries", esp. given Smiley's F-PC graphics library, is a moot point. I quite agree that PostScript has a cleaner conceptual model. I'm not clear how that is a difference which is a difference of a kind not like the differences between existing Forths (as per an earlier post). > Forth has a firm foothold in certain application areas, PostScript in others. > Those domains don't overlap much. If you could show HOW those different target domains have molded significant differences in the languages, and what those differences are... > Some people have asked me why I chose Forth over PostScript for use in the > Sun Open Boot PROM firmware. The answers: PostScript wouldn't have fit, > it would have been too slow (probably), and I know Forth better. If you ask people doing embedded systems with C why they would choose C over Forth, you would at least agree on the last point: "I know <X> better." -Doug --- Preferred: dwp@willett.pgh.pa.us Ok: {pitt,sei,uunet}!willett!dwp
shri@ncst.ernet.in (H.Shrikumar) (12/14/90)
In article <14813@sdcc6.ucsd.edu> ir230@sdcc6.ucsd.edu (john wavrik) writes: >1. If a move is made to gain acceptance for the language in an > academic arena several things are needed -- among them the > ability to discuss the language in the way that other computer > languages are discussed. Very truly said. I use Forth(-derived-sort-of-postscript-like-sort-of-CSP-like-dialect) on my hobby-pony (6803,32Krom), and when my (academic) colleagues ask me "whats new in forth", "why forth", what do I say ? 1. Easy to "factor" code does not mesh, people do it in Lisp all the while. 2. Fast code ... "how about C, and good common-lisp." 3. Ease of use ... "with RPN, you must be joking.!" 4. Interactive ... "Lisp is great for that." A bit of introspection tells me that the real *first* reason I chose forth was ... 1. I dont have to sacrifice ROM for a big compiler/parser, RPN and dictionaries makes that trivial. 2. I dont want a symbol table to chew up my 16K RAM, and 3. please no Garbage to be collected in a 1Mips machine. 4. structured constructs to keep sanity, yet low-level when I need. In chose FORTH 'cos it is small, quick to implement, and can be bootstrapped into a new machine in a few evenings, incrementally. Then I got hooked. Now I talk RPN in my sleep :-) So when I talk to my colleagues, I take pains to first show how Forth and Lisp are similar, (stack, recursion (myForth thrives on recursion), functional abstraction); and immediately point out that Forth and Lisp are nevertheless quite different, Lisp is large, Forth is light, fast to implement and yet not bad to work in. This seems convincing enough to most. Now, I am beginning to look at Forth more as "core" language for such things as controllers. As applications get bigger, people will do cross-development in larger machines, with large environments, and generate Forth into the controllers. And when you wish to patch the code, you can do it manually quite easily, since Forth is friendly! (Aside: lots of code in the Shuttle computers, and in COCOTs etc, are written in higher languages, tested and tested to death, and even then patched by hand several times in their life cycle!) A good example is this sort of stuff is S-Bus F-code of Mitch. Its is very-powerful-future-proof-boot-auto-configure code, as well as friendly low-level debugging environment. I am not sure if it is smart to try to push Forth as a general purpose langauge. Dont lets get Forth and Lisp to fight, its not fair. It is ideal for light applications, (I dont for a moment mean "non-serious" ... light as in less number of data-structures and symbol spaces to manage in the core language, maybe the forth-generator does it.) >Doug Philips writes: > ># I have seen nothing so far that would enable me to distinguish ># PostScript from Forth. In fact, the power and popularity of ># PostScript would seem to have proved the point already. > >I must be missing something: what point has been proved? >The popularity of Postscript is not the topic being discussed. Postscript code is generated by a front end program, Yet you can manually edit it easily. Why ? Because PostScript is RPN and stack (easy for code generators), and has dictionaries for factoring code (human-friendly), and yet all this fits in a small little board embedded in a printer. I agree with Doug, just add a { } to Forth, and clean up all the other syntactic-closures into this one beautiful construct, and you have post-script. The value of this has come up here often. Thus PostScript has proved the concept behind Forth. Also, the different attitude academia has to PostScript and Forth is not very well founded. Probably its history, "Forth is used to get a cheap processor to turn screws in a creaky telescope." Thats a wrong image for Forth. "Forth is a great embedded programming vehicle." is better. "Clean semantics, no side-effects unless you use @ and !, fuctional" are nice attributes. >I don't want to put words in Moore's mouth -- but I think you will >find that Forth was NOT created by developing a theory of what >characteristics a language should have, then making the language >fit the theory. Moore instead seemed to follow his instincts in >making design decisions as the language evolved. The result is Yes, I do emphatically agree with that. On the other hand, I'm sure CM wanted to keep the language light and yet factorable ... functions and abstractions yet no link-editors and other batch-mode artifacts. He thought an extensible dictionary gave him the latter, and the data-stack gave the first. Those were in fact his "theory of characteristics". OK, I have often heard such things as "Forth is great, 'cos I can have Scheme syntax in Forth" ... and so on. Has anybody got a good lazy-evaluation embedded in Forth, one whose syntax is clean (must look just like a @ ! or similar), and is quite efficient. The thing about functional programming is not the syntax, it is ability to let a compiler handle a lot, including type checking that is strong and yet polymorphic, optimise very well using such tricks as delayed-evals plus reduction of evaluation graphs. There is probably not much to write home about the BNF of Haskell, but the care taken to ensure that implementations can give such semantics as lazy-eval and make them efficient as well as intutive is what earns it respect in the "academic community". Has this been done in Forth ? Has it been done to Forth ? > John J Wavrik > jjwavrik@ucsd.edu Dept of Math C-012 > Univ of Calif - San Diego > La Jolla, CA 92093 -- shrikumar ( shri@ncst.in )
EBERBERS@YUBGEF51.BITNET (12/17/90)
> Support for all major programming paradigms including OOP > built-in! Since 1971! Yeah! There are a LOT languages which fans could claim the same. Whenever we talk about 'programming paradigms' we are talking more about the way we interpret things and less about what things really are. Strictly speaking neither, C++ nor any present FORTH-with-objects is OO language but that doesn't prevent us from imagining that they are ant that imagination is the one that really helps us understanding and solving real programming problems more efficiently. I'v seen very good OO application in FORTRAN (believe it or not) so I could say that it has 'support for ...' since the ... but that would actually mean nothing except the fact that I or somebody else is feeling well with it. When someone is to produce a piece of useable code ant not to spend a lifetimne on that then it is very that he is able to 1 - 'translate' algorithms to program efficiently. 2 - read and understand programs/routines that somebody have already written (so that he doesn't reinvent the weel) 3 - locate and remove bugs efficiently 4 - produce space/time efficient program 5 - produce a program that is able to live pieacefully with other programs in the system (if he is to sell it to anybody except a very specialized user) Could anybody claim that any present language is perfect or even good for all 5 items? Both vendors and programmers are trying to offer/use systems composed of at least two languages so that a good tradeoff could be made in most real situations. FORTH is a language that has a chance to be good starting point for a really universal language that would be really good for doing everything with it but lets face the fact that right now it is very far from being such language. What makes it exceptional is the fact that for some applications it is much more convenient than any other and there are not a lot of languages which fans could claim the same. So, if someone is happy with that is OK al long as he is not trying to 'prove' that his favourite is a God among languages. There is another question - what FORTH needs to became the real favourite on a large scale? As far as I can see it would be best to have a very good FORTH-processor so that complete UNIX/X-Windows workstation could be built on it. Then, one could have a C implementation in FORTH both as interpreter and compiler and could not only mix C and FORTH code but also change the syntax/semantics of C so that the hybrid will actually behave as a single language capable of handling tasks from robot control to fractal simulations to expert systems and still being very comfortable for producing variuos small utilities. So far about science fiction - the reality is that modern sofware development requires maximal flexibility and interoperability of various language and that present 'omnia mea mecum porto' phylosophy of almost all present programming languages is going to die as soon as operating systems in personal computers start supporting extensive message-based program comunication and shared libraries usage - shell FORTH enter that era still insisting on block-oriented mass storage access and 1024 char source blocks ? Zarko Berberski EBERBERS@YUBGEF51.bitnet