dwp@willett.pgh.pa.us (Doug Philips) (09/29/90)
Quoting, without permission,
from SIGForth, Volume 1, #2: (typos are mine)
"By not specifying notation in advance, Forth lets you
choose one suitable for each situation. There is no need for
consistency beyond the immediate application. In fact, the single
principle of postfix operators suggests notation very comfortable in
English (12 inches) as well as in postfix languages (German,
Chinese). Not demanding consistency is compatible with natural
language, and exploits their determined ambiguity."
-Chuck Moore
The context of that quote is that CM is explaining why Ada/C are
to be avoided: "They both suffer the same drawback neatly
finessed by Forth. They must have all possibilities resolved in
advance." (CM)
I personally find the first quote less than heartening when
considering the ANSI effort, and the spread of Forth, in general.
But, CM ends with the following:
"Forth has a marvelous opportunity as the the only alternative to
increasingly elaborate and unsatisfactory software. As the
novelty of software applications wears off, users will demand
acceptable levels of performance and accuracy. The existance
proofs offered by academics will not be accepted as solutions to
real-world problems. As investors learn that programming costs
are one-time, and that replicating bugs is not cost-effective,
the value of real programming tools will increase. And as the
marriage of Forth and hardware matures, good solutions will
reveal today's software as the garbage it is."
I am not (yet anyway) convinced that "programming costs are
one-time." Perhaps that is due to my inexperience as a Forth
programmer. I am curious to know what others think of these
quotes, what the forbode for ANSI and Forth in general, and
if the lifecycle of Forth programming is significantly different
from traditional programming (developement vs. maintaince
time/cost), if there is a difference, is due to something about
Forth itself, or something about the domain in which Forth is
being applied.
-Doug
---
Preferred: dwp@willett.pgh.pa.us Ok: {pitt,sei,uunet}!willett!dwpkoopman@a.gp.cs.cmu.edu (Philip Koopman) (10/01/90)
In article <1795.UUL1.3#5129@willett.pgh.pa.us>, dwp@willett.pgh.pa.us (Doug Philips) writes: > I am not (yet anyway) convinced that "programming costs are > one-time." Perhaps that is due to my inexperience as a Forth > programmer. Programming costs are almost never one-time. The bigger and more complex the project, the less likely that the first release of software even grossly approximates the required functionality (i.e. the spec., which is probably not what the customer/user wanted either). The traditional numbers are 20% to create a program, 80% of costs for lifetime maintenance, where maintenance is largely to correct/enhance the software. Much of the problem is language-independent. A lot has to do with the problem of "I think I might understand what I thought I heard you ask for, which may or may not be what you actually thought you might want, assuming that you really understand the problem you want to solve " in spec. writing. Interactive development in Forth and the ability to quickly bring up prototype systems gives more chance for the programmer and customer to come to terms on what the *real* requirements are (not the ones in the spec.). BUT, this is probably only an advantage on small systems where everyone involved can fit around a CRT and knock heads until things are resolved. Phil Koopman koopman@greyhound.ece.cmu.edu Arpanet 2525A Wexford Run Rd. Wexford, PA 15090 Senior scientist at Harris Semiconductor, and adjunct professor at CMU. I don't speak for them, and they don't speak for me.