dwp@willett.UUCP (Doug Philips) (01/10/90)
[I hardly expect any of these ideas to be new, but I thought I'd toss them out for comment.] >Yup. Forth requires another way of thinking about programming. Nothing >in Forth is cast in stone, which is frightening to programmers who expect >that. It takes a *long* time to get used to the fact that you can do >it yourself; just 'cuz it ain't supplied don't mean you can't have it. Forth seems to be like a desert. When first observed, it appears barren, but constantly shifting. Closer inspection reveals life, but on a scale and of a type different from non-desert life. Forth is powerful because it does not stand in your way. It is frustrating to a novice because it is so slippery; one feels as if one has to re-invent half the world before taking a single step. One of the main differences (IMHO) between Forth and Smalltalk is that Smalltalk comes with a whole bunch of 'library' code ready to use. You don't often hear of people redoing or totally abandoning Smalltalk's library. Perhaps that is because it is too herculean a task. Perhaps it is because the library is really well done and has been done and redone enough times for the proper factoring to have happened. Perhaps the Forth community is too few flung too far to have enough feedback to get to the level Smalltalk did confined in one company? Forth encourages you to take the most direct path towards your problem. I have an image of Forth programmers as backpacking trailblazers working diligently towards their own summits, stopping occasionally to get replacement supplies and swap stories of Bigfoot and UFO sitings. I feel an undertone of contempt for the 'fascist' languages [perhaps this is part of me, I'm not sure.] "Seven countries in seven days." If Forth is declining in the few niches it has, perhaps it is because C's "bus route" has finally been put in, Ada's steamship now has a port of call. If Forth is a frontierman's language, where is the frontier? -Doug --- Fastest: (willett!dwp@gateway.sei.cmu.edu OR ...!sei!willett!dwp) ...!{uunet,nfsun,sei}!willett!dwp [in a pinch: dwp@vega.fac.cs.cmu.edu]
koopman@a.gp.cs.cmu.edu (Philip Koopman) (01/10/90)
In article <231.UUL1.3#5129@willett.UUCP>, dwp@willett.UUCP (Doug Philips) writes: > .... I > have an image of Forth programmers as backpacking trailblazers working > diligently towards their own summits, stopping occasionally to get > replacement supplies and swap stories of Bigfoot and UFO sitings. > ... If > Forth is declining in the few niches it has, perhaps it is because C's > "bus route" has finally been put in, Ada's steamship now has a port of > call. If Forth is a frontierman's language, where is the frontier? The frontier is small embedded systems, preferably those that do time-critical control. They are still predominately done in assembler. Now, through sheer inertia, C is moving in. But, Forth is really the way to go. The question is, what do we do before they turn the wilderness into a paved lot? Phil Koopman koopman@greyhound.ece.cmu.edu Arpanet 2525A Wexford Run Rd. Wexford, PA 15090 Senior Scientist at Harris Semiconductor. I don't speak for them, and they don't speak for me.
ir230@sdcc6.ucsd.edu (john wavrik) (01/10/90)
Doug Philips writes: >Forth seems to be like a desert. When first observed, it appears >barren, but constantly shifting. Closer inspection reveals life, but >on a scale and of a type different from non-desert life. Forth is powerful >because it does not stand in your way. It is frustrating to a novice because >it is so slippery; one feels as if one has to re-invent half the world before >taking a single step. People don't often try to express the subjective aspect of a computer language. Doug Philips' attempt is the first that I've read in many years. In the early days of Forth, the Forth Interest Group sponsored a Contest for the best description of Forth in 25 words or less. The winning entry was by Michael Ham: "Forth is like the Tao: it is a Way, and it is realized when followed. It's fragility is its strength; it's simplicity is its direction. We've changed Forth in the past 10 years. Have we changed it from a language in which simple pieces fit together in a strong and beautiful way to something which looks like a desert? If so, we should all be *very* concerned. > If >Forth is declining in the few niches it has, perhaps it is because C's >"bus route" has finally been put in, Ada's steamship now has a port of >call. If Forth is a frontierman's language, where is the frontier? Here the problem is in assuming that Forth is trying to do what other languages do and go the same places that other languages go. Anyone who wants to go where the bus goes should take the bus! Perhaps Forth is declining because we're changing it from a language in which simple pieces fit together in a strong and beautiful way to something which looks like a desert! Phil Koopman writes: >The frontier is small embedded systems, preferably those that do >time-critical control. They are still predominately done in >assembler. Now, through sheer inertia, C is moving in. But, >Forth is really the way to go. The question is, what do we do >before they turn the wilderness into a paved lot? I'd be happier if Phil would include mathematics, physics, chemistry, biology, medicine, oceanography, space physics, engineering, hardware control, and instrumentation to his frontier. (Particularly mathematics!) John J Wavrik jjwavrik@ucsd.edu Dept of Math C-012 Univ of Calif - San Diego La Jolla, CA 92093
dwp@willett.UUCP (Doug Philips) (01/11/90)
In <6001@sdcc6.ucsd.edu>, john wavrik writes:
<We've changed Forth in the past 10 years. Have we changed it from a language
<in which simple pieces fit together in a strong and beautiful way to something
<which looks like a desert? If so, we should all be *very* concerned.
What we have here is a failure to communicate, if you think a
desert is such a bad place to be like! ;-) A desert is full of sand
that can be piled and molded and shaped to suit your desires, and it
can as easily be re-<all those things>. Its most permanent feature
is its adaptability. I don't disagree with your 'strong and beautiful'
assesment, perhaps I'm just saying that Forth's strengths and beauties
are different from most other languages, and as such the casual
observer/novice is going to be looking in the wrong places for the wrong
things.
[I have a feeling that I'm not expressing myself too well, so I'll leave
it at this for now.]
<>[Doug Philips wrote:]
<>If Forth is declining in the few niches it has, perhaps it is because C's
<>"bus route" has finally been put in, Ada's steamship now has a port of
<>call. If Forth is a frontierman's language, where is the frontier?
<
<Here the problem is in assuming that Forth is trying to do what other
<languages do and go the same places that other languages go. Anyone who wants
<to go where the bus goes should take the bus!
That isn't what I was trying to say. The problem is that the buses are
finding it profitable to put in lines where it hadn't been profitable
to put them in before. What were once the refuges of the frontiersman
are now becoming the tourist traps of the bus tours. The frontiersman
hasn't changed. Perhaps the wilderness has. It isn't as hostile as it
used to be, nor as inaccesible to other forms of traffic. [If embedded
systems can cheaply provide the resources for C's bus lines, then they
aren't the same kind of embedded systems that they were.] It isn't
'frontier' anymore. The frontier has moved.
It strikes me as amazing that, given Forth's adapability, it wouldn't have
found other niches over a 10 year period (to use your time frame). I
get the impression that despite all the other changes in the computer
industry, Forth is like a little kid refusing to grow up. The world is
always changing. Forth is, seemingly, ideally suited to track change and
adapt with it, to 'follow the frontier'. Where is Forth going?
Its following the frontier! And where is the frontier?
Will there always be a frontier? Is the frontier shrinking/vanishing?
If so, what then of Forth?
[I think is clearer, but what do I know!]
-Doug
---
Fastest: (willett!dwp@gateway.sei.cmu.edu OR ...!sei!willett!dwp)
...!{uunet,nfsun,sei}!willett!dwp [in a pinch: dwp@vega.fac.cs.cmu.edu]ir230@sdcc6.ucsd.edu (john wavrik) (01/12/90)
The quotes below come from an exchange between John Wavrik and Doug Philips:
# In <6001@sdcc6.ucsd.edu>, john wavrik writes:
# <We've changed Forth in the past 10 years. Have we changed it from a language
# <in which simple pieces fit together in a strong and beautiful way to
# <something which looks like a desert? If so, we should all be *very*
# concerned.
#
# What we have here is a failure to communicate, if you think a
# desert is such a bad place to be like! ;-) A desert is full of sand
# that can be piled and molded and shaped to suit your desires, and it
# can as easily be re-<all those things>. Its most permanent feature
# is its adaptability. I don't disagree with your 'strong and beautiful'
# assesment, perhaps I'm just saying that Forth's strengths and beauties
# are different from most other languages, and as such the casual
# observer/novice is going to be looking in the wrong places for the wrong
# things.
One of the problems with describing Forth to others is that we tend to
use similes and metaphors to describe the subjective experience we have
with the language rather than the objective features which account for
the experiences. [It's a bit like trying to explain to someone who has
never tasted sauerbraten why you think sauerbraten tastes good.]
A desert, to me, is a wasteland. There are, perhaps, a few sparse patches
of vegetation -- but mostly it's bare sand. You can't build much with
sand, and what you build doesn't last very long. Comparing Forth to a
desert strikes a very negative chord.
I try to compare Forth with mathematics (which, to me, is a subject where
vast edifices are built from a few simple ideas by using the
mathematician's understanding of how the system works). Unfortunately,
this seems to provide, for 50% of the people I talk to, an opportunity
for them to tell me why they got a "D" in differential equations -- and
how much they hate math. That's the problem with metaphors: "It's like
mathematics" is the most positive thing I could think of to say about a
computer language (and Forth is the only one I can say it about) -- but
to a lot of people this seems to make negative associations.
I hope we both agree, however, that the importance of Forth lies more in
the ways in which it differs from other languages rather than the
similarities.
<discussion of languages in terms of providing access to places
... the transportation analogy>
# That isn't what I was trying to say. The problem is that the buses are
# finding it profitable to put in lines where it hadn't been profitable
# to put them in before. What were once the refuges of the frontiersman
# are now becoming the tourist traps of the bus tours. The frontiersman
# hasn't changed. Perhaps the wilderness has. It isn't as hostile as it
# used to be, nor as inaccesible to other forms of traffic. [If embedded
# systems can cheaply provide the resources for C's bus lines, then they
# aren't the same kind of embedded systems that they were.] It isn't
# 'frontier' anymore. The frontier has moved.
I guess my problem is with the analogy. I'm using Forth because I need an
interactive computing environment. I also need the ability to add my own
data structures and operations. Experimenting with algorithms and
implementation of data structures is as much a part of my work as
obtaining the results of computations. Using a conventional language
would be a matter of "making do". Forth, to me, is a language for building
languages. I don't think that any other language you care to mention has this
property. Mathematics will never run out of data structures that no one knows
how to represent or computations for which good algorithms are not known.
Mathematics will also never cease to be an area that benefits from an
interactive environment. I don't, therefore, see Forth as a language for
cutting paths which will eventually be taken over by another language -- I see
it as providing an alternative type of computing.
Phil Koopman, on the other hand, sees Forth as the perfect language for
small systems to control hardware. While his view of Forth as "the
language for embedded systems" is quite different than mine of Forth as
"the language for building languages", we both share the view that Forth
is important because it does something different than other languages.
Forth offers unique (and permanent) capabilities that are not within the
nature of other languages to offer.
# It strikes me as amazing that, given Forth's adapability, it wouldn't
# have found other niches over a 10 year period (to use your time frame).
# I get the impression that despite all the other changes in the computer
# industry, Forth is like a little kid refusing to grow up. The world is
# always changing. Forth is, seemingly, ideally suited to track change and
# adapt with it, to 'follow the frontier'. Where is Forth going? Its
# following the frontier! And where is the frontier?
Forth is not a little kid refusing to grow up, it is brilliant idea
waiting for people to understand and use it properly.
Suppose someone provides you with a language that does something, but
has a few deficiencies. After you study the cause of these deficiencies,
you may create a new language (which does essentially the same things in
the same way as the original language) to fix the deficiencies. I hope
that I am not saying anything too controversial by claiming that 'C' is
just Pascal with a few deficiencies fixed. (It doesn't look like Pascal
because begin..end has been replaced by { .. }, etc. -- but the fact is
that programs have been written to translate Pascal programs to 'C', so
the visual differences are more cosmetic than real). Most languages are
part of a progression starting with FORTRAN and ALGOL and inherit a body
of understanding (and misunderstanding) of what a computer language
should be and how it should work.
Now suppose that someone gives you a language which allows a radically
expanded range of capabilities. Suppose, for example, that you can even
add your own control structures --- so, essentially, programming can
involve altering the language itself. It can take years to understand
what can be done with this expanded capability, what should be done,
what should not be done, etc. Some experts will tell you "a programmer
should never be allowed to invent control structures" or "a user should
not be concerned with how a language is implemented" -- and there are
good reasons for saying this -- but also good reasons for feeling that,
if used properly, this could be beneficial. A radically new concept
cannot be expected to bear fruit quickly -- it needs to be explored.
It should not be surprising that such a language encourages a variety of
perversions. Without any conventions for the writing of clear code, there
is no doubt that many examples of "write only" code will be produced
[adding fuel to the fire of critics who claim that writing clear code in
such a language is impossible]. A very flexible language also encourages
a form of masturbation -- people become preoccupied with modifying the
language rather than doing anything with it [adding fuel to the fire of
critics who claim that nothing can be done with it].
1. The whole issue of how to use and not abuse the freedom that the
language provides must be addressed.
2. Can such a language be standardized so that it retains its flexibility
for each user yet achieves a high degree of portability?
3. What is necessary to allow a community to jointly add powerful
features to such a language as portable extensions?
4. What is the best approach for setting standards for such a language?
5. The language must become portable enough, well understood enough,
established enough so that it can be taught. How can these goals be
best achieved.
These are just of the few of the issues that need to be addressed. Since
Forth is not just a reworking of a conventional language, some of these
issues may need to be dealt with in a novel way. It may be that Forth is
having a problem with Standards right now because the approach used to
set standards for conventional languages is inappropriate to Forth.
A brilliant idea doesn't automatically thrive -- it all depends upon the
people to whom it has been entrusted for development.
John J Wavrik
jjwavrik@ucsd.edu Dept of Math C-012
Univ of Calif - San Diego
La Jolla, CA 92093 stever@tree.uucp (Steve Rudek) (01/15/90)
In article <6025@sdcc6.ucsd.edu>, ir230@sdcc6.ucsd.edu (john wavrik) writes: > would be a matter of "making do". Forth, to me, is a language for building > languages. I don't think that any other language you care to mention has this > property. Mathematics will never run out of data structures that no one knows ... > Forth offers unique (and permanent) capabilities that are not within the > nature of other languages to offer. LISP is at least as good for language building (probably better). Of course, all the implementations I've heard of are too slow or run only on expensive hardware. Assuming that LISP's speed problem is inescapably endemic to the language, then Forth has the opportunity to monopolize the market as a language for writing languages which are actually USABLE. That gives Forth at least two market niches -- embedded systems and custom languages. Can anyone think of a third? > Forth is not a little kid refusing to grow up, it is brilliant idea > waiting for people to understand and use it properly. ... > It should not be surprising that such a language encourages a variety of > perversions. Without any conventions for the writing of clear code, there > is no doubt that many examples of "write only" code will be produced > [adding fuel to the fire of critics who claim that writing clear code in > such a language is impossible]. A very flexible language also encourages > a form of masturbation -- people become preoccupied with modifying the > language rather than doing anything with it [adding fuel to the fire of > critics who claim that nothing can be done with it]. If I understand correctly, John is saying that Forth is fine -- Forth PROGRAMMERS, on the other hand, need to grow up. I agree with that. There has always been a tendency for the Forth community to blame Forth's lack of popular acceptance on ignorance, "bigotry", and lack of imagination in the mainstream programming community. The mainstream computing community has blamed the Forth language directly. Neither group was correct: the blame lies with Forth programmers, themselves. In almost twenty years, armed with a language which SHOULD have made them enormously more productive than their programming brethren stuck with "third generation languages", Forth programmers have written almost nothing of any consequence -- just lots of new Forth systems and lots of "small, cute hacks which amuse other Forth programmers". (to quote Peter Silva) > 1. The whole issue of how to use and not abuse the freedom that the > language provides must be addressed. > > 2. Can such a language be standardized so that it retains its flexibility > for each user yet achieves a high degree of portability? > > 3. What is necessary to allow a community to jointly add powerful > features to such a language as portable extensions? > > 4. What is the best approach for setting standards for such a language? > > 5. The language must become portable enough, well understood enough, > established enough so that it can be taught. How can these goals be > best achieved. > > These are just of the few of the issues that need to be addressed. Since > Forth is not just a reworking of a conventional language, some of these > issues may need to be dealt with in a novel way. IT MAY BE THAT FORTH IS > HAVING A PROBLEM WITH STANDARDS RIGHT NOW BECAUSE THE APPROACH USED TO > SET STANDARDS FOR CONVENTIONAL LANGUAGES IS INAPPROPRIATE TO FORTH. (emphasis aded) > > A brilliant idea doesn't automatically thrive -- it all depends upon the > people to whom it has been entrusted for development. John Wavrik's postings are always well composed and thought provoking; this time he outdid himself. In recent months a number of people have voiced a desire for "standards" to ease portability of Forth code. It has been very frustrating to watch even the idea of a unix "standard" rapidly degenerate into nonchalance by some people and arm wrestling contests by others. I have a hunch that the first step in meaningful progress is to discard the word "standard". The word clearly means wildly different things to different people and invokes very stong emotion. As I see it, we can either abandon the word "standard" or force half the Forth programmers into therapy; abandoning the word is easiest. I propose that the Forth community develop "portable libraries" which can be easily retrieved from Fig, Forth BBSes and network archive servers. A portable library for strings, for example, would consist of a base word set prefaced by whatever base primatives are required to adequately define the base word set for your Forth. In other words, the same base word set would be available from a Fig Forth, Forth 79, or Forth 83 by using different definitions for the base primatives. Performance of the base word set is not the primary issue -- portability is. If I write a program which uses portable libraries I will have assurance that you can run that program on another machine; whether it runs "fast enough" on your machine is a different matter but one, I submit, which is not nearly so important as the fact that it does run. If YOU don't think the speed is sufficient, YOU may rewrite the base primatives into suitable assembly language for your machine -- THAT IS *YOUR* CHOICE. You even choose to abandon the base word set to get maximum speed on your machine at the expense of portability -- but isn't it helpful that you at least got to see the program running on your machine before you had to undertake "porting" it? The portable library would ADD a choice -- NOT take anything away. Because Forth programmers are so iconoclastic there would doubtless be disagreements about what constitutes the optimal portable library for strings (for example). That's okay. Write your own portable library and distribute it -- just make sure you clearly identify the necessity of using your library AND that you define the base word set adequately in terms of primatives for all major Forth dialects. It can be survival of the fittest. For portable libraries to help they must 1) exist and 2) be easily retrievable (if you receive source for a game or word processor written in Forth which references a portable library, you must be able to get that portable library quickly and relatively inexpensively. FIG could help by distributing libraries on disk at nominal cost. BBSes and archive servers would be even faster. Certainly such a distribution mechanism for libraries is "doable" -- it would be in keeping with the "different" nature of the Forth community that we use "portable libraries" rather than authoritarian and repressive standards and that we maximize networking to enable portability. Doesn't this approach make more sense than the status quo? The status quo doesn't work and is strangling Forth. If something doesn't work one should try something else. Surely we are all rational enough to agree on that, at least? ----- P.S. I'm leaving for Australia on Wednesday, Jan 17 and won't be back until March 10. I don't want anyone thinking I died of frustration. Those with PCs *should* look at the shareware "Fifth" implementation to stretch their brains regarding a third possibility in the "screens vs. sequential files" debate. It's only $10 and can be ordered from "The Software Construction Company" by calling (409) 696-5432. ----- -- {pacbell!sactoh0! OR ucdavis!csusac!}tree!stever
koopman@a.gp.cs.cmu.edu (Philip Koopman) (01/15/90)
In article <1990Jan14.203752.22131@tree.uucp>, stever@tree.uucp (Steve Rudek) writes: > LISP is at least as good for language building (probably better). Of > course, all the implementations I've heard of are too slow or run only on > expensive hardware. Assuming that LISP's speed problem is inescapably > endemic to the language, then Forth has the opportunity to monopolize the > market as a language for writing languages which are actually USABLE. Scheme (a LISP variant) is no longer slow! Scheme uses compile-time analysis to derive typing information, so run-time tag checking is not needed in most cases. Similarly, it does strictness analysis to reduce the cost of closure building. Finally, modern copying-semispace garbage collection algorithms are *much* cheaper than the old clunkers that used to be around. Given the fact that Forth has an interpretive overhead of about 50% or so on a modern non-stack architecture, Scheme can actually be faster than Forth. Scheme is much bigger than Forth, but who cares on a Sun 3 or Vax? The language implementation group I work with at CMU uses Scheme for most of their work, and I honestly can't say that they would be any better off using Forth. > I propose that the Forth community develop "portable libraries" > which can be easily retrieved from Fig, Forth BBSes and network > archive servers. Sounds like the beginnings of a good idea. You'll find that this is a lot more work than it appears at the onset, but worth doing. Don't forget that establishing technical excellence in Forth is half the problem -- the other half is marketing. Marketing gets people in the door, technical excellence keeps them there. Phil Koopman koopman@greyhound.ece.cmu.edu Arpanet 2525A Wexford Run Rd. Wexford, PA 15090 Senior Scientist at Harris Semiconductor. I don't speak for them, and they don't speak for me.
sdh@flash.bellcore.com (Stephen D Hawley) (01/15/90)
In article <7573@pt.cs.cmu.edu> koopman@a.gp.cs.cmu.edu (Philip Koopman) writes: >Scheme (a LISP variant) is no longer slow! Scheme uses compile-time >analysis to derive typing information, so run-time tag checking is >not needed in most cases. Similarly, it does strictness >analysis to reduce the cost of closure building. Finally, modern >copying-semispace garbage collection algorithms are *much* cheaper >than the old clunkers that used to be around. Scheme is no longer slow in comparison to old versions of Scheme. Scheme is still slow in comparison with the rest of the world, but one must keep in mind what Scheme is good for. I want to point that out for the forthers who are unfamiliar with Scheme. A prof at School (Oberlin) needed to do a dump of some graphics data from Scheme, so he translated a print filter I wrote in C to Scheme with some mods to suit his purpose. It took about a half hour to dump a page, whereas the C version was instantaneous. Conclusion: don't use Scheme for bit-banging, it just isn't suited to the task. Scheme _is_ good for abstraction in programming. Works like a charm. For contrast to Forth, I implemented a Scheme interpretter in C in the space of a semester, and it worked like a charm --not REALLY fast, but it chugged along. I also implemented a Forth _compiler_ to 68000 in assembly and C in the space of a semester. In retrospect, both were about as difficult to implement, but I can't say I could write a scheme _compiler_ (to a real machine) in the same space of time, because of all the fiddling little problems fuctional languages give you (environment, functions as first class objects, etc). The people who are really into functional languages are doing some very clever things in terms of optimizing compilation and getting parallelism into the language. If you get the chance to see Simon Peyton-Jones speak, do it. He is working on a parallel machine that is designed to handle a compiled functional language he has designed (you get parallelism for free -none of this semaphore stuff). He claims it will really scream. The best part is that he gets his hands dirty with the hardware -- a nice contrast to most Schemers (I would doubt that R. Kent Dybvig would be so eager to pull wires). I'm still waiting for the Forth RISC machine. Steve Hawley sdh@flash.bellcore.com A noun's a special kind of word. It's ev'ry name you ever heard. I find it quite interesting, A noun's a person place or thing.
gintera@cpsc.ucalgary.ca (Andrew Ginter) (01/16/90)
It seems to me I've argued this argument before, but last time it was about LISP and its derivatives. Now granted, people use LISP and FORTH for almost completely different kinds of applications and LISP is incredibly much slower than FORTH. What is similar about the languages, though, is their expressive power. Language lovers of both species claim that software is easier and quicker to develop in their favorite language than in mainstream languages. Actually, seems that language lovers of ALL species claim this... Anyhow - my point is that extensibility and regular syntax are nice, yes. But the key to the claim that you need to write less code in these languages is the degree of function nesting. Extremely compact applications in both LISP and FORTH (and maybe APL? - I'm not that familiar with the language) employ high degrees of function nesting. The results of functions are passed directly as arguments to other functions whose results are passed to other functions, etc. MOST programmers will grant that deep nesting produces compact code and that such code is comparatively easy to write. They will also argue that deeply nested code is difficult to read and understand - a criticism commonly leveled against LISP and FORTH. SOME programmers (FORTH lovers included) have no difficulty with function nesting and don't understand why the rest of the world doesn't like the obvious advantagers of FORTH: * clean syntax * super extensibility * compact, easy to write code * good speed & small size (which FORTH has and LISP usually doesn't) The fact is that MOST people have trouble with nesting and no matter how you tout a language which encourages nesting, they will never like it. Andrew Ginter, 403-282-2984, gintera@CPSC.UCALGARY.CA, Ginter@UNCAMULT.BITNET
wmb@SUN.COM (01/16/90)
When you finish your thesis and are ready to start on the C interpreter, let me know and I'll send you a copy of C Forth 83. Mitch
xanthian@saturn.ADS.COM (Metafont Consultant Account) (01/18/90)
(I just had to use such an open subject line for this follow up!) Folks puzzling over "where did all the FIG members go" and "why isn't FORTH more successful among programming languages" are invited to read "Positive Feedbacks in the Economy" in the Feb90 Scientific American. It gives a pretty sobering view of how hard it is for the laggard in a high technology race to even stay in the race, much less pull even or win, and explains why. Winning seems to have little to do with merit! To the remark that "windowing, graphics, etc. are not appropriate for a FORTH standard", I can't argue against such an attitude directly, but I can say that I would be unwilling to start a graphics project on any workstation platform after 1992 using any language that did not include a binding to X Windows. My reason? Almost every job ad in misc.jobs.offered that mentions graphics _requires_ X Windows experience. I blinked, and I'm obsolete! ;-) Again, take a look at the above article to see why it is long too late to avoid the X juggernaut. To the passing mention of standards documents' cost. Yes, since the corporate sponsors of ANSI have tightened the purse strings, a large part of ANSI's budget is derived from selling paper standards documents at about five times the price most potential purchasers are willing to pay. A direct effect is that the standards are slow to be adopted, and that the "big folks" get a big head start on using them. Since these prices also apply to the (photocopied) draft standards, a secondary effect is that the standards are reviewed by only a narrow audience, focused around the "big players" capable of funding standards committee participation (big bucks - perhaps $20K per year by now), while the wider community is stuck with whatever they get at the end of the process, with little opportunity to participate in or comment upon the creation of the standard. (I've said this before in many forums of USENet. I wanted, while unemployed, to use some of my copious free time to comment upon a draft ANSI standard where I had 25 years experience to bring to bear. I was told it would cost me $70 for a bad photocopy of a throw-away document. I used the time instead fomenting flame wars on the net! Human resources - use them or lose them, America!) -- Again, my opinions, not the account furnishers'. xanthian@well.sf.ca.us xanthian@ads.com (Kent Paul Dolan) Kent, the (bionic) man from xanth, now available as a build-a-xanthian kit at better toy stores near you. Warning - some parts proven fragile. -> METAFONT, TeX, graphics programming done on spec -- (415) 964-4486 <-
wmb@SUN.COM (Mitch Bradley) (01/19/90)
> say that I would be unwilling to start a graphics project on any > workstation platform after 1992 using any language that did not include a > binding to X Windows. My reason? Almost every job ad in misc.jobs.offered > that mentions graphics _requires_ X Windows experience. Several points: 1. So far, Forth hasn't made many inroads into the workstation market. I doubt that it ever will. (My own work is in some sense an exception; Forth may become popular as the boot firmware for workstations. However, that has little to do with discussions of window system bindings.) 2. Even if X is ubiquitous in the workstation market, that doesn't necessarily mean that it has much, if any, impact in the Mac or PC markets. 3. There are many competing toolkits and "look and feel" guidelines on top of X. Just having the binding to the underlying window mechanism isn't enough. > five times the price most potential purchasers are willing to pay. A > direct effect is that the standards are slow to be adopted, and that the > "big folks" get a big head start on using them. Since these prices also > apply to the (photocopied) draft standards, The price for the ANSI Forth draft standards aren't inflated. The X3J14 committee sells the draft standards for $10 a pop, which is almost exactly what it costs to photocopy and bind them (figure 3 cents a page x 150 pages + 1.50 for the binding + the time it takes the secretary to go to the copy shop and fill out the address label, etc.). You can't participate in the standards effort for free, but in the case of the ANSI Forth effort, every attempt has been made to minimize the cost. Participation by mail (buying draft standards and submitting proposals) costs 10 or 20 dollars, and going to meetings can be done for a few hundred dollars. Meetings alternate between the east coast and the west coast (where Forth programmers tend to be concentrated). If a meeting is held withing driving distance of you, you can attend that meeting for free (this is not an unlikely think; they really are scattered around pretty well). It will cost me about $200 to attend next week's meeting; I got a cheap plane ticket to San Diego, and I'm sharing a hotel room with another committee member. So, you could reasonably expect to be able to attend every other meeting for about $600 a year, a far cry from $20K. Mitch
ir230@sdcc6.ucsd.edu (john wavrik) (01/19/90)
Some recent comments were made about the speed of the language Scheme.
The claims made for its speed are not substantiated by my experience with
the language.
At the moment I am in the process of writing an article to explain some
of the educational advantages of Forth. I use it in a course designed to
introduce mathematicians to "computer algebra". My claim is that students
can understand the issues involved in this area more quickly if Forth is
the programming language -- and that Forth has the same advantages (in
terms of isolation of implementation details, modularity, etc.) as other
languages. To illustrate my point, I have examples of the same project
implemented in three systems.
The project is to implement a polynomial arithmetic package (polynomials
of one variable with integer coefficients). Beginning Forth students
implement this project in my course. The project also appears in the
MuMath programming lessons written by David Stoutemyer and in the book
"Structure and Interpretation of Computer Programs" by Abelson, Sussman
and Sussman which is an introduction to Scheme -- thus we are comparing
implementations written by experts. Here are the benchmarks.
Polynomial Multiplication (1000 repetitions)
TI Scheme 59.98 sec IBM-AT compatible
MuMath 9.70 IBM-AT compatible
F83 3.74 IBM-AT compatible
Execution speed should not be taken as the sole measure of the merit of a
language (see below). If it is, there is no doubt who wins. But,
actually, execution speed is not the reason for the choice of Forth in
this course. The fact of the matter is that the Forth version of this
package is considerably easier for students to write and understand.
Forth was introduced into this course to help prepare students for using
MuMath (a LISP based system).
--------
How does one measure the merit of a programming language?
I. For some the measure is execution speed.
For the record, here are some results for the Sieve of Eratosthenes
benchmark (essentially the same code was used in each case):
Sieve - 25 repetitions
Interp BASIC 1472.50 sec IBM-AT compatible
TILE 377.90 SUN 2
F83 high level 51.96 IBM-AT compatible
F-PC high level 36.63 IBM-AT compatible
Turbo BASIC 8.40 IBM-AT compatible
Turbo Pascal 7.53 IBM-AT compatible
Turbo C 4.72 IBM-AT compatible
F83 low level 3.40 IBM-AT compatible
(F83 low level means that some parts of the program were recoded in
assembly language. No effort was made to optimize the code -- so the
3.40 figure is probably too high.)
II. Others measure merit in terms of language attributes.
Apparently there are people who say things like "my language is a
referentially transparent applicative language, and your's isn't!". Or "I
like my language because it has a more orthogonal approach to
declarations and data types than yours"
III. But maybe there is something else
One of my students this year said, at the end of the Forth course,
"I've had more fun programming in Forth this year than I've had in a long
time" (spoken by someone who has programmed in 4 or 5 languages)
----------
Phil Koopman says we have to market Forth. Could we really get away with
an ad campaign that says:
"Remember how much fun programming used to be? It still is
with Forth"
John J Wavrik
jjwavrik@ucsd.edu Dept of Math C-012
Univ of Calif - San Diego
La Jolla, CA 92093 xanthian@saturn.ADS.COM (Metafont Consultant Account) (01/20/90)
In article <9001191304.AA23264@jade.berkeley.edu> Forth Interest Group International List <FIGI-L%SCFVM.bitnet@jade.berkeley.edu> writes:
kent> say that I would be unwilling to start a graphics project on any
kent> workstation platform after 1992 using any language that did not
kent> include a binding to X Windows. My reason? Almost every job ad
kent> in misc.jobs.offered that mentions graphics _requires_ X Windows
kent> experience.
mitch> Several points:
mitch> 1. So far, Forth hasn't made many inroads into the workstation
mitch> market. I doubt that it ever will. (My own work is in some
mitch> sense an exception; Forth may become popular as the boot
mitch> firmware for workstations. However, that has little to do
mitch> with discussions of window system bindings.)
If true, this is rather a pity. I have seen some immense projects
done in Forth, including an entire cartographic data capture,
database, editing, application, and drafting package. Such projects
are of the evolutionary development type so suitable to Forth, and are
of the sort that make use of high end displays and workstations.
mitch> 2. Even if X is ubiquitous in the workstation market, that
mitch> doesn't necessarily mean that it has much, if any, impact in
mitch> the Mac or PC markets.
I disagree. First, because I have a firm belief in juggernauts,
second, because X is already available for my Amiga, and if the larger
386 and Mac markets don't have it now they soon will. The interfaces
being built on X allow mixed vendor shops to have common equipment
human interfaces, with the concommitent training savings and
productivity advantages well know from other areas overtaken by
defacto standards. The interface deficits of the PC world have held
folks back for far too long, and the Mac is one of the reasons
managers now come to expect a better interface.
mitch> 3. There are many competing toolkits and "look and feel"
mitch> guidelines on top of X. Just having the binding to the
mitch> underlying window mechanism isn't enough.
Agreed, but it is a beginning, and the discussion grows more complex
as Open Look, Motif, etc. are brought into the picture.
kent> five times the price most potential purchasers are willing to pay.
kent> A direct effect is that the standards are slow to be adopted, and
kent> that the "big folks" get a big head start on using them. Since
kent> these prices also apply to the (photocopied) draft standards,
mitch> The price for the ANSI Forth draft standards aren't inflated.
mitch> The X3J14 committee sells the draft standards for $10 a pop,
mitch> which is almost exactly what it costs to photocopy and bind them
mitch> (figure 3 cents a page x 150 pages + 1.50 for the binding + the
mitch> time it takes the secretary to go to the copy shop and fill out
mitch> the address label, etc.).
You lucked out. The FORTRAN committee, I understand, was compelled by
ANSI to distribute dpANS's via ANSI's outlet, with prices $70 and up.
Now if only you can get the eventual Forth ANS released at a
reasonable price.
mitch> You can't participate in the standards effort for free, but in
mitch> the case of the ANSI Forth effort, every attempt has been made
mitch> to minimize the cost. Participation by mail (buying draft
mitch> standards and submitting proposals) costs 10 or 20 dollars, and
mitch> going to meetings can be done for a few hundred dollars.
mitch> Meetings alternate between the east coast and the west coast
mitch> (where Forth programmers tend to be concentrated). If a meeting
mitch> is held withing driving distance of you, you can attend that
mitch> meeting for free (this is not an unlikely think; they really are
mitch> scattered around pretty well). It will cost me about $200 to
mitch> attend next week's meeting; I got a cheap plane ticket to San
mitch> Diego, and I'm sharing a hotel room with another committee
mitch> member. So, you could reasonably expect to be able to attend
mitch> every other meeting for about $600 a year, a far cry from $20K.
My costing of this was based on my 4.5 years participation in ANSI
X3H3 (Computer Graphics Programming Languages). It included 15% of my
workday when away from meetings (untold unpaid overtime in addition),
and three one week meetings per year with travel, lodging, and meals
expenses. It was every bit of $20K per year, and I am greatful to the
government agency and later the corporation who sponsored me to the
committee for all those years. (I may have been a bit enthusiastic as
a participant, I was a subcommittee secretary for three of those
years, which added a lot of unaudited photocopy and mailing expenses
to the other costs.)
I don't especially mean to disagree heatedly with you in all this,
Mitch. Different committee styles allow different costs for
participation, and what the future actually brings in workstations and
interfaces will be seen in the course of time. I surely have no
crystal ball available.
--
Again, my opinions, not the account furnishers'.
xanthian@well.sf.ca.us xanthian@ads.com (Kent Paul Dolan)
Kent, the (bionic) man from xanth, now available as a build-a-xanthian
kit at better toy stores near you. Warning - some parts proven fragile.
-> METAFONT, TeX, graphics programming done on spec -- (415) 964-4486 <-marc@noe.UUCP (Marc de Groot) (01/21/90)
In article <2342@cs-spool.calgary.UUCP> gintera@cpsc.ucalgary.ca (Andrew Ginter) writes: >MOST programmers will grant that deep nesting produces compact code >and that such code is comparatively easy to write. They will also >argue that deeply nested code is difficult to read and understand - a >criticism commonly leveled against LISP and FORTH. > [ stuff deleted ] >The fact is that MOST people have trouble with nesting and no matter >how you tout a language which encourages nesting, they will never >like it. I have problems reading other programmer's deeply nested Forth code sometimes. Other times I have none. The things that make a difference for me are: - The code must be well-documented. - I must have a word like VIEW, which instantly shows me the source. - I must have a single-stepping mechanism so that I can wander through the code. With the above tools, I have no problem. -- Marc de Groot (KG6KF) |"...few people know what to do with a computer. Noe Systems, San Francisco | They decide that running an operating system UUCP: uunet!hoptoad!noe!marc | is a substitute for doing productive work." Internet: marc@kg6kf.AMPR.ORG | -Chuck Moore
dwp@willett.UUCP (Doug Philips) (01/23/90)
Date: 01-21-90 (11:13) Number: 73 (Echo)
To: GARY SMITH Refer#: 62
From: JERRY SHIFRIN Read: 01-22-90 (06:24)
Subj: THOUGHTS ON FORTH Status: PUBLIC MESSAGE
GS> From: ir230@sdcc6.ucsd.edu (john wavrik)
GS> Subject: Thoughts on Forth
GS> One of my students this year said, at the end of the Forth course,
GS> "I've had more fun programming in Forth this year than I've had in a long
GS> time" (spoken by someone who has programmed in 4 or 5 languages)
Funny. That's just about what I said to Chuck Moore when we first
met -- "thanks for making programming fun again".
---
* QDeLuxe 1.10 #214s
---
Preferred: willett!dwp@gateway.sei.cmu.edu OR ...!sei!willett!dwp
Daily: ...!{uunet,nfsun}!willett!dwp [in a pinch: dwp@vega.fac.cs.cmu.edu]ForthNet@willett.UUCP (ForthNet articles from GEnie) (08/01/90)
Category 18, Topic 12
Message 29 Mon Jul 30, 1990
D.RUFFER [Dennis] at 23:00 EDT
Re: dwp@willett.UUCP (Doug Philips)
> Is there not a perfection to adaptability?
Adaptability allows you or I to create a system that is perfectly matched to
our individual needs. Adaptability gives us the power to create a seamless
integration with the machine. Adaptability allows us to accomodate any new
hardware and software ideas easily.
But does adaptablity produce perfection?
Adaptability means choices that the user must select from. In Forth,
adaptability generally means that you must even do it yourself. Adaptability
means that it will be adapted to fit its environment, and that these
adaptations are rarely the same from implementation to implementation to say
nothing about the variations in environments. Adaptability implies minimal
standards which produce portability problems. Generally, adaptability means
hard to learn.
So, is our view of perfection flawed? As individuals, we have the ability to
make what we need. As individuals, this is enough, but is it sufficient?
Will the common man/woman ever understand the power that we enjoy? Will they
ever care?
What is perfection? DaR
-----
This message came from GEnie via willett through a semi-automated process.
Report problems to: uunet!willett!dwp or willett!dwp@hobbes.cert.sei.cmu.edudwp@willett.UUCP (Doug Philips) (08/02/90)
In <1443.UUL1.3#5129@willett.UUCP>, D.RUFFER [Dennis] writes: > > Re: dwp@willett.UUCP (Doug Philips) > > But does adaptablity produce perfection? No, it allows for it, but there are no guarantees. Inflexibility/Inadaptability prevents it, guaranteed. > nothing about the variations in environments. Adaptability implies minimal > standards which produce portability problems. Generally, adaptability means > hard to learn. Agreed. No one said perfection was easy! :-) > So, is our view of perfection flawed? As individuals, we have the ability to > make what we need. As individuals, this is enough, but is it sufficient? > Will the common man/woman ever understand the power that we enjoy? Will they > ever care? I cannot know if your view of perfection is flawed without first understanding what that view is. More on this below. It is necessary that we be able to "make what we need", it is not sufficient because we are part of the process. It is up to the individual to supply the remaining elements. The language must avoid getting in the way. That is the best method for allowing (not ensuring) perfection. Should we care if the common person understands? Do they understand the power that programmers in general enjoy? Should they? What are the consequences (as you see them) of their understanding or lack thereof? > What is perfection? DaR For finite mortals, I would say, perfection is a process. The moment progression towards perfection ceases, a flawed thing comes into being. No written on paper language standard can be perfect. It may be the best we can do at any given time, but that is all. Perfection, in that static sense, can probably never be attained. Perfection as a process, I think, can be, so long as you maintain the process. -Doug --- Preferred: willett!dwp@hobbes.cert.sei.cmu.edu OR ...!sei!willett!dwp Daily: ...!{uunet,nfsun}!willett!dwp [in a pinch: dwp@vega.fac.cs.cmu.edu]