raisch@eecae.UUCP (Rob Raisch) (07/16/88)
I have been thinking about threaded interpretive languages recently and
would like to share a few of my thoughts with the newsgroup.
I have been a `forthHacker' for a few years and have developed a few
large, sophisticated applications. Since I also have keen interest in
other languages, and most specifically, `object oriented' languages, I
have felt that Forth was sadly lacking in a few areas. Before I explain
what I mean, let me explain what I think I know.
Design Requirements for a Forth Language:
First and foremost, Forth must be small/compact/efficient. This
concept has driven Forth from the early days, and is still quite
an important concern today.
Forth must be portable. This has been accomplished by various
`standards committees', and Forth exists as a `standard' language
for the most part.
A subset exists of what we all know and love as `Forth' which I
shall call `Pure Forth'. Any implementation of Forth must, at
it's lowest level, support `Pure Forth'.
Given these understandings, (which I hope are all correct), there are
certain areas of the Forth language that have not grown much in the
intervening 20 or so years that Forth has been around. I have had a
true `love/hate' relationship with Forth because of these `shortcomings'.
Why I LOVE Forth:
It is FAST! -- Above all else, Forth is one of the fastest
executing languages around. Since it is functionally both a
compiler and an interpreter, this speed is evident both in the
execution of the program and in it's compilation. The speed of
Forth also makes for rapid prototyping.
It is ELEGANT! -- Most of the implementations of Forth share a
cleanliness of paradigm that I find quite pleasing. Programs
developed in Forth tend to be quite `bugless' because of this
`oneness of vision'.
It is SMALL! -- We all know this one. Forth is a tiny language.
It is POWERFUL! -- Forth includes a flexibility of control that,
I believe, is unprecedented in most programming languages,
(except, perhaps, for Lisp).
Why I HATE Forth:
Postfix Notation -- Yes, I know this one has been done to death.
Mr. Moore, himself, has taught us that `infix notation' is not
the natural state of creative thought, but an arbitrary decision
of the educational community. Whether or not you agree with
this, most humans that I have known think in `infix'. This is
the way in which we have been taught, from a very early age, to
deal with the complexities of mathematics.
Linear Definition -- Forth has virtually no mechanism to deal
with memory/vocabulary management. The `flat/linear' structure
of the Forth dictionary has been modified, in the past, to
handle `hierarchical dictionaries', with multiple branches off
of a `root' dictionary. I believe that this has held Forth
programmers in chains for far too long. The fact that a
programmer can `re-code' a word in Forth, but that that new
implementation is not `seen' in the old context is quite
limiting.
Lack of Decent Development Tools -- Well, this one is a favorite
bug-a-boo of mine. Coming, as I do, from a Unix environment, I
can appreciate the fact that Forth can support a full screen
editor, but is this as far as we have gotten? What about
parsers, prettyPrinters, macro-preprocessors, etc.
Ok, now that I have gotten that out of my system, let's talk turkey.
The problems with Forth, as I see them, are not with the `run-time'
engine. Forth is marvelously designed for the speedy and efficient
execution of programs. The problems are created when we attempt to
develop code in this environment. Forth has been called a `programmer
antagonistic' language and I concur.
What we need is a `development environment' that benefits the
programmer, not works against her/him. This is what I propose:
Forth Application Developer - FAD
Supports the full `Pure Forth' language, but in an environment
that supports a new dictionary structure that is laid out like:
Word Hash Table -- used by the interpreter to locate an
`object' in a fast efficient manner. Entries in the
Hash Table point to the Name Table.
Name Table -- contains all of the information used to
describe a particular object and points to the Object
Table. This information is allocated on the computer's
heap and can be changed interactively. (If FAD is used
as an `execution engine', both the Name Table and the
Hash Table are stripped, since they are not needed in an
executing program.)
Object Table -- forward links to the particular objects
data space, and a backward link to it's Name Table entry
to facilitate `reverse compiling'. The Object Table
entry also contains a `reference count' to allow garbage
collection by the interpreter.
Heap -- this is where an object's data space is kept.
Since the Heap is managed by the interpreter, space used
by `de-referenced' objects can be reclaimed and re-used.
Supports an `infix' notation of Forth, (and should ultimately
support an `object oriented' notation, as well.)
Produces the application written in `Pure Forth'.
Supports `relocatable' libraries of definitions, allowing
development of `packages' which can be loaded `on the fly' and
partially unloaded to conserve space.
Benefits:
Since the standard Forth `dictionary' has been redefined, Forth
objects can be defined, re-defined, saved, reloaded, and
destroyed based on the needs of the programmer.
A new `infix' syntax allows the programmer to create complex
programs following current programming paradigms, without the
need for the programmer to act as his/her own language/concept
`preprocessor'.
Entire systems can be `cloned' and saved `in toto'. This allows
historical `revision' control.
When the application is complete, the FAD produces Forth code
that is transportable across many platforms.
I guess what I find most disagreeable about the Forth development philosophy
is the fact that most developers use the `target' machine as a `development'
machine. We should maintain the `purity' of the Forth `execution engine',
but we should not let that limit the programming/development environment. I
feel that the progression of the Forth language has been `held back' because
of the rational requirement that Forth remain a fast/efficient/small
programming language. Perhaps it is time to treat Forth as a `target'
for which we compile programs using higher-level programming tools.
FAD is only slightly more than a dream. I have done some considerable
design of how I believe it _should_ operate, but I have yet to really put
an effort into writing it.
Should FAD be written? If so, should it be written in `C' or should I
tackle it in Forth?
I am very interested in comments about these concepts. Of course, I
would like this to stimulate others to think about the `execution
engine' versus the `development engine', but I would also like some
feedback about FAD. If you feel that this work would benefit the Forth
community or you have problems with these concepts, I would certainly like
to hear from you. Responses mailed directly to me will be abstracted to
the net.
Oh, by the way, my ultimate plans for FAD are to release it into the
public domain.
----------------------------------------------------------------------
Robert Raisch - Systems Programmer/Researcher/Language Nut
CASE Center for Computer Aided Design and Manufacturing
(517-353-4841) Michigan State University, East Lansing Michigan
raisch@eecae.ee.msu.edu | raisch@msudoc.egr.msu.edu
{backbones}!msudoc!raisch | {uunet}!umix!mnet!raisch
----------------------------------------------------------------------orr@cs.glasgow.ac.uk (Fraser Orr) (07/19/88)
In article <10036@eecae.UUCP> you write: > > First and foremost, Forth must be small/compact/efficient. This > concept has driven Forth from the early days, and is still quite > an important concern today. As you mention later this is certainly a requirement for an executible language, but is this really a burden that must be put upon the programmer? Surely generating small/compact/efficient code is the responsbility of a compiler. This leaves the programmer to think about the thing he is good at - generating small/compact/efficient alogorithims. So, yes small/compact/efficient code is an advantage both of Forth and 68000 assembler. > Forth must be portable. This has been accomplished by various > `standards committees', and Forth exists as a `standard' language > for the most part. Last time I looked at forth ( which was a while ago I admit), there were two "standards", Fig-Forth and Forth-79 ( or whatever it was called. I know that Forth-83 has also come into being, has this superceded both (i.e. completely superceded both?). > >Why I LOVE Forth: > > It is FAST! -- Above all else, Forth is one of the fastest > executing languages around. Since it is functionally both a > compiler and an interpreter, this speed is evident both in the > execution of the program and in it's compilation. The speed of > Forth also makes for rapid prototyping. Yes its fast, but so is 68000 assembler. Rapid Prototyping! Speed of execution is nothing to do with rapid prototyping, it requires facilities to generate prototypes rapidly, i.e. being able to translate an idea or a change to an idea quickly. This is provided by using a high level language, not a macro assembler like Forth. > > It is ELEGANT! -- Most of the implementations of Forth share a > cleanliness of paradigm that I find quite pleasing. Programs > developed in Forth tend to be quite `bugless' because of this > `oneness of vision'. Oneness of vision is a great thing in a world where we only want to do one thing, unfortunately I want to do lots of different things such as arithmetic, and procedure calls. to do these things I want to use the most expressive means or most normal means avaliable to convey my intention to the computer, i.e. "a+12*(37+b)" rather than "a 12 37 b add mul add" and "MoveCursor(x,y)" rather than "x y MoveCursor" > > It is POWERFUL! -- Forth includes a flexibility of control that, > I believe, is unprecedented in most programming languages, > (except, perhaps, for Lisp). > Power is not necessarily a quality, the thing that makes goto such an undesirable thing is that it is so powerful, and thus the reader finds it dificult to follow what is going on ( so many possibilities, which one to choose?) > > It is SMALL! -- We all know this one. Forth is a tiny language. > The computer I am typing this on has 12 MB of memory, small is getting to be less and less of an advanage. >Why I HATE Forth: > [Reasons deleted, I agree with them all] You may think from my above comments that I am a forth hater, this is not true. I see forth as being one step up from machine code, i.e. a machine independent assembler. I think this is a useful tool, but, for the same reasons I don't program is 68000 assembler, I don't program in Forth. > >Forth Application Developer - FAD > One of the excellent features of forth is its ability to be changed into a specialised language for specific tasks, for example controlling telescopes or as a page description language, this is my field of interest. I am of course talking about PostScript, or more particularly Sun Microsystem's NeWS window manager programming language ( this is a variant of PostScript that allows the programmer to deal with input, has simple multiprocessing, and object oriented features). I think, Robert that you should have a very close look at this language before you start work on FAD, because it answers many of the questions you will have to ask in designing such a system. I further agree totally with your point that one of the main problems that has held back Forth for so long, is the inability to seperate target machine from development machine. Why not build FAD ontop of an existing environment such as UNIX? NeWS fits very well into the UNIX system, ( for example, I found it simple to knock up a yacc parser to give me a decent syntax), I see no reason why forth shouldn't do likewise, and if you use pure forth as the machine code generated then you loose just about all of your porting and cross compiling problems. ==Fraser Orr ( Dept C.S., Univ. Glasgow, Glasgow, G12 8QQ, UK) UseNet: {uk}!cs.glasgow.ac.uk!orr JANET: orr@uk.ac.glasgow.cs ARPANet(preferred xAtlantic): orr%cs.glasgow.ac.uk@nss.cs.ucl.ac.uk
DAVID@PENNDRLS.BITNET (07/22/88)
Someone whose name I have lost wrote: >Why I LOVE Forth: > > It is FAST! -- Above all else, Forth is one of the fastest > executing languages around. Since it is functionally both a > compiler and an interpreter, this speed is evident both in the > execution of the program and in it's compilation. The speed of > Forth also makes for rapid prototyping. > The claim that FORTH is one of the fastest executing languages around makes me think the author has used only interpreters previously. By its very nature FORTH programs *must* be slower than programs generated by a good optimizing compiler. The gap can be closed (in some cases to almost nil) by coding hot loops in assembler and by using a direct threading FORTH, but overall FORTH *must* still be slower. Of course, if you take the time to learn good FORTH coding techniques your programs (both in FORTH and elsewhere) will tend to get more efficient :-). -- R. David Murray (DAVID@PENNDRLS.BITNET, DAVID@PENNDRLS.UPENN.EDU)
mdg@smegma.UUCP (Marc de Groot) (07/24/88)
In article <8807221513.AA05347@jade.berkeley.edu> Forth Interest Group International List <FIGI-L%SCFVM.bitnet@jade.berkeley.edu> writes: >Someone whose name I have lost wrote: >>Why I LOVE Forth: >> It is FAST! -- Above all else, Forth is one of the fastest >> executing languages around. >The claim that FORTH is one of the fastest executing languages around >makes me think the author has used only interpreters previously. By >its very nature FORTH programs *must* be slower than programs generated >by a good optimizing compiler. It is not strictly true that FORTH must, by its very nature, execute more slowly than code generated by a good optimizing compiler. It *is* true that the popular microprocessors now in use execute threaded code more slowly than, say, a good C compiler's output. It is trivial to design indirect auto-incrementing jump instructions into processors. It is indeed a shame that none of the leading microprocessor manufacturers have chosen to do so! The Novix NC4000 (a hardware Forth implementation) illustrates this point. It executes the indirect, auto-incrementing jump mentioned above in *one* clock tick (at 7 MHz). Indeed, the NC4000 executes the BYTE "sieve" benchmark several times faster than an 8086 clocked at the same speed. I don't have hard numbers in front of me that I can quote, but I worked with the NC4000 a couple of years ago and this was the case. The point is that when the design of the silicon is taken into consideration, Forth wins *hands down* over other languages in terms of execution speed. The industry has an awful lot to learn from Forth. -- Marc de Groot (KG6KF) UUCP: uunet!{uport,ubvax}!smegma!mdg Internet:mdg@smegma.UUCP "Quoiqu'elle soit tres solidement montee, il faut ne pas *brutaliser* la machine." -Oliver Wendell Holmes
stejk@caen.engin.umich.edu (Steven J Kassarjian) (07/25/88)
In article <8807221513.AA05347@jade.berkeley.edu>, DAVID@PENNDRLS.BITNET writes: > Someone whose name I have lost wrote: > > >Why I LOVE Forth: > > > > It is FAST! -- Above all else, Forth is one of the fastest > > executing languages around. Since it is functionally both a > > compiler and an interpreter, this speed is evident both in the > > execution of the program and in it's compilation. The speed of > > Forth also makes for rapid prototyping. > > > > The claim that FORTH is one of the fastest executing languages around > makes me think the author has used only interpreters previously. By > its very nature FORTH programs *must* be slower than programs generated > by a good optimizing compiler. The gap can be closed (in some cases > to almost nil) by coding hot loops in assembler and by using a direct > threading FORTH, but overall FORTH *must* still be slower. Of course, > if you take the time to learn good FORTH coding techniques your programs > (both in FORTH and elsewhere) will tend to get more efficient :-). > Looking back into history (watchout- I'm "young" and could be wrong; or even worse, partially wrong), it seems that 'optimizing' compilers have not been in existance for long. Thus, because of its simplicity, Forth was (much) more optimized than a "Traditional" compiler. Second, as David suggests, hot loops coded in assembler. The key though, is the rapid prototyping, I believe. Through rapid prototyping, information hiding (data and algorithm), several algorithms may be tested, and the best one determined _empirically_. Traditional languages (then) could not possibly support the interactivity that makes such quick changes (and testing) possible. Much of this is changed now, with the very quick compilers and optimizing compilers (though they seem to be exclusive). Forth is still fast and has room for growth, such as the support the 68000 can offer (hardware stacks, (I think), and such), or even Forth in hardware (Novix, Rockwell). Personal Experience. As much as I've used Fortran (I'm a ChE), I doubt I ever will _think_ in Fortran. For the short period of time I used Forth (one class project), I started to think (and dream) in Forth. (I was under a lot of pressure, too!) (strange :-) (is my signature working?) steve kassarjian as stejk@caen.engin.umich.edu
orr@cs.glasgow.ac.uk (Fraser Orr) (07/27/88)
In article <3d7612e1.13370@dow4.engin.umich.edu> stejk@caen.engin.umich.edu (Steven J Kassarjian) writes: > The key though, is the rapid prototyping, I believe. Through rapid >prototyping, information hiding (data and algorithm), several algorithms may >be tested, and the best one determined _empirically_. Traditional ^^^^^^^^^^^^^ Theoretical computing science bites the dust! Are you serious? If I decide to write some sorting algorithims and determine empirically which is the best, and my test data just happens to be an ordered list a reverse ordered list and a fairly random list (which doesn't seem to me to be a totaly ridiculous set of test data, certainly one I might in ignorance choose), I would discover that quicksort was generally fairly rotten, that bubblesort was excelent a third of the time and that selection sort was also pretty good. It is my humble opinion that regardless of how good your language is for _fast_prototyping_ (falls about in fits of laughter), it is usually adviasiable to THINK before you code! >be tested, and the best one determined _empirically_. Traditional >languages (then) could not possibly support the interactivity that makes such >quick changes (and testing) possible. > Much of this is changed now, with the very quick compilers and optimizing >compilers (though they seem to be exclusive). If I may paraphrase, all of my preceding arguments are totally invalid in todays world. >(one class project), I started to think (and dream) in Forth. (I was under ^^^^^^^^^^^^^^^^ My deepest commiserations, you poor backward boy! ==Fraser Orr ( Dept C.S., Univ. Glasgow, Glasgow, G12 8QQ, UK) UseNet: {uk}!cs.glasgow.ac.uk!orr JANET: orr@uk.ac.glasgow.cs ARPANet(preferred xAtlantic): orr%cs.glasgow.ac.uk@nss.cs.ucl.ac.uk
olson@batcomputer.tn.cornell.edu (olson) (07/31/88)
I was going to let this slide, but given the tone of this posting and the next posting (about the Novix chip) by Mr Orr ... Mr Orr, Don't you think you are being just a little too viscous? Disagreement is wonderful, but only if all participants refrain from attacking each other. (Another "wonderful" "American" discovery) In article <1533@crete.cs.glasgow.ac.uk> orr@cs.glasgow.ac.uk (Fraser Orr) writes: >In article <3d7612e1.13370@dow4.engin.umich.edu> stejk@caen.engin.umich.edu (Steven J Kassarjian) writes: >> The key though, is the rapid prototyping, I believe. Through rapid >>prototyping, information hiding (data and algorithm), several algorithms may >>be tested, and the best one determined _empirically_. Traditional > ^^^^^^^^^^^^^ >Theoretical computing science bites the dust! >Are you serious? If I decide to write some sorting algorithims and >determine empirically which is the best, and my test data just happens >to be an ordered list a reverse ordered list and a fairly random list >(which doesn't seem to me to be a totaly ridiculous set of test data, >certainly one I might in ignorance choose), I would discover that quicksort >was generally fairly rotten, that bubblesort was excelent a third of the time >and that selection sort was also pretty good. >It is my humble opinion that regardless of how good your language is >for _fast_prototyping_ (falls about in fits of laughter), it is usually >adviasiable to THINK before you code! This is always good advice. But my experience suggests that before you can think you have to have some experience. If you knew nothing about sorting how do you know what to think about? My approach would be to try anything... with the understanding that it will probably be wrong/bad/etc and see what happens. Then maybe try something else. Then THINK. and then try some more. then THINK. etc... (though you might try thinking a bit first also ..) It is true that you might not pick a good set of test initially, but if you are truely trying to understand what is going on you won't just stop there. You will try others (and THINK) and try to test things out as fully as possible. Maybe you meant "before you write the final production version, THINK" to which I would insert, "and explore empirically'. I believe that it is more useful to use both approaches than just one or the other. Thus one might argue that the advantage to forth is that it lets you move from thinking to thinking and experimenting. How many of you have seen the adds for LightSpeed C for the Macintosh that say something like "We help you make mistakes ... faster!" (open irrational, emotional section: Does the above need "authority"? If so than I am a physicist. Why is that relevent? Because, by and large physics is the field of starting with vague ill defined naggings and producing well defined questions. And a mixture of empirical effort and THINKing both in the "experimental" and "theoretical" (and now "numerical") subfields is the formula for successful progress. It has been said to me "chances are you as a physicist will always be able to find a job in the computer world because by and large while CS majors are good at solving well possed problems (maybe better than physicist), physicists are very good at possing problems well (much better than CS major in the industrial world)" Now this may be just self back patting ... Enough .. close section) > > >If I may paraphrase, all of my preceding arguments are totally invalid >in todays world. (What "arguments"?) > >>(one class project), I started to think (and dream) in Forth. (I was under > ^^^^^^^^^^^^^^^^ >My deepest commiserations, you poor backward boy! (was there supposed to be a :-) after this?) Steve, yea, I understand, I was trying to think in forth before I was introduced to forth. Mr Orr, may I ask you to really THINK about the following question. How would you compute if the process of calling proceedures had zero overhead? You might be interested to know that Postscript is very forth like. And that Stoic is very forthlike. And that the new HP calculator that does symbolic manipulation runs on a forthlike language. And that in some sense the Unix "philosophy" is very forth like. I'm tempted to argue that Forth:C/Fortran/...:assembler :: arabic#:Roman#:hashmarks Note that the difference between Roman# and hashmarks is not all that great. >==Fraser Orr ( Dept C.S., Univ. Glasgow, Glasgow, G12 8QQ, UK) In a subsequent posting Mr Orr made, in a bitting way some observations on the Novix forth chip relative to other chips. One point, the Novix chip does what it does in of order 10,000gates other chips that it is compareable to use order 100,000gates (i think these # are correct) Certainly food for thought. Other tid bits, Harris has come out with a "SemiCustom MicroControler" that has at is core the Novis chip design (licenced from Novix) For those of you that may have noticed that the Novix chip is still one design cycle away from being well done, the Harris chip is well done. The chip (called RTX) is SemiCustom in that it uses so little space on the silicon that if you want to add features, or change the on chip stack size or other customizations, you can, and Harris is actively encouraging people to do so. (Sort of roll your own chip with their help) Actually the Harris RTX is a really neat microprocessor, and they are really supporting it. Now if only I had some extra money ... (Sorry people, but one posting I was willing to let slide but not two in the same tone. Hope this doesn't start flame wars) Todd Olson olson@helios.tn.cornell.edu Physics Dept/Clark Hall/Cornell Univ./Ithaca Ny 14853
jax@well.UUCP (Jack J. Woehr) (08/01/88)
" The NC400 chip made by Novix is very refreshing. Seeing what these 4000 gates can accomplish that took 100,000 gates to do in toher microprocessors makes you wonder if the computer industry is driving into a blind alley at 100 mph." Dr. C.H. Ting in _Footsteps In An Empty Valley_ *C* 1985 Offete Enterprises Only 4,000! _____________________________________________________________________________ jax@well =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= jax@chariot "There is no Moore but Moore, and Ting is his prophet" JAX on GEnie =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
adam@hpmtlx.HP.COM ($Adam Kao) (08/01/88)
Mr. Orr, did you know the net gods, in their infinite wisdom, have created an entire newsgroup just for your kind of writing? It's called alt.flame. I suggest you go there and don't come back until you can be polite. Adam
orr@cs.glasgow.ac.uk (Fraser Orr) (08/02/88)
In article <5703@batcomputer.tn.cornell.edu> olson@tcgould.tn.cornell.edu (olson) writes: >I was going to let this slide, but given the tone of this posting and the >next posting (about the Novix chip) by Mr Orr ... >Mr Orr, > Don't you think you are being just a little too viscous? > Disagreement is wonderful, but only if all participants refrain >from attacking each other. (Another "wonderful" "American" discovery) My appoligies if you found my remarks offensive Mr Olsen. To be honest I expected an erudite net'er like yourself to be able to recognise good humoured sarcasm when you saw it. >>adviasiable to THINK before you code! > > This is always good advice. But my experience suggests that before you >can think you have to have some experience. If you knew nothing about sorting True. >can think you have to have some experience. If you knew nothing about sorting >how do you know what to think about? If you knew nothing about sorting, then you wouldn't be writting code for it. At the very least you must know the pre and post conditions (otherwise you haven't done your system analysis properly.) >My approach would be to try anything... >with the understanding that it will probably be wrong/bad/etc >and see what happens. Then maybe try something else. >Then THINK. and then try some more. then THINK. etc... >(though you might try thinking a bit first also ..) My approach is, 1) think about the problem 2) think of any similar algoritims previously seen (hence the need for experience and books of algorithims) 3) if there is a similar algorithim modify and goto 5 4) code the algorithim in the simplest way possible (with regard to your experience of course) 5) finish the program. 6) if there is strong evidence that the algorithim is a cause of performance problems (i.e., evidence from an execution profile of a REAL run, with REAL data) then maybe think about another algoritim (i.e., goto 1, with step 4 modified to "code the algorithim in as simple a way as possible, with the following constraints ...") Yes I agree that empirical studies are a good idea, but leave them till the end! Why spend hours fine tuning an algorithim that is only used twice? The most important thing we have learned from the study of program design is -keep your mind focused on the problem, NOT the program. > >Maybe you meant "before you write the final production version, THINK" >to which I would insert, "and explore empirically'. > Yes, if necessary. >Thus one might argue that the advantage to forth is that it lets you >move from thinking to thinking and experimenting. This is the crux of the matter, can you justify this statment. >>>(one class project), I started to think (and dream) in Forth. (I was under >> ^^^^^^^^^^^^^^^^ >>My deepest commiserations, you poor backward boy! >(was there supposed to be a :-) after this?) Good guess :-) >Mr Orr, may I ask you to really THINK about the following question. >How would you compute if the process of calling proceedures had zero overhead? Are you trying to say forth has zero overhead for calling procedures? Am I completely missing your point here? >You might be interested to know that Postscript is very forth like. Yes I am aware of this. Interestingly as I mentioned before I have written a preprocessor for PostScript that gives some reasonable syntax to it. It has consequently become quite a nice language to use. I am sad that you are all missing out on this because Forth'ers seem unwilling to use anything but reverse polish notation. >And that in some sense the Unix "philosophy" is very forth like. Justification? >In a subsequent posting Mr Orr made, in a bitting way some observations >on the Novix forth chip relative to other chips. > >One point, the Novix chip does what it does in of order 10,000gates >other chips that it is compareable to use order 100,000gates >(i think these # are correct) >Certainly food for thought. > [Other interesting stuff on Forth chips deleted] I don't think this is a fair representation of my comments at all. My posting merely asked for any experimental results comparing Forth chips (like Novix) to essentially C chips (like 68000). Subsequent communications have indicated that "The Novix chip leaves a 68000 coughing in the dust and takes far less silicon." I accept this without further qualification. I feel that gorups like comp.lang.forth can become very narrow minded (the group has a very narrow set of discussion topics, I'm not trying to suggest that the participants are narrow minded of course!) It is good to discuss the things that other people are doing, in a way that is relevant to your subject of interest. As I mentioned previously I have never understood why Forth'ers are not prepared to use parsers so that their code is more readable. Lets see what we can learn form each other instead of indulging in mindless "I think my language is better than yours" wars. I accept that Forth is fast on Forth chips, I also assert that C or Pascal are easier to program in. What can I learn from you, and what can you learn from me? ==Fraser Orr ( Dept C.S., Univ. Glasgow, Glasgow, G12 8QQ, UK) UseNet: {uk}!cs.glasgow.ac.uk!orr JANET: orr@uk.ac.glasgow.cs ARPANet(preferred xAtlantic): orr%cs.glasgow.ac.uk@nss.cs.ucl.ac.uk
ZMLEB@SCFVM.BITNET (Lee Brotzman) (08/04/88)
In article <810001@hpmtlx.HP.COM>, hpl-opus!hpccc!hp-sde!hpfcdc!hpislx!hpmtlx! adam@hplabs.hp.com ($Adam Kao), writes: >Mr. Orr, did you know the net gods, in their infinite wisdom, have created >an entire newsgroup just for your kind of writing? > >It's called alt.flame. > >I suggest you go there and don't come back until you can be polite. > >Adam Let me answer with an old American saying: "I may not agree with what you say, but I will defend to the death your right to say it." If only it were more than just a saying, eh? I think Mr. Orr's comments could have perhaps done with a few sprinkled :-) and ;-) here and there, but I don't take his criticism of Forth as simply flames. I have written a few public domain and commercial Forth development systems and am definitely a fan of the language, but I also agree with Mr. Orr's observations that program design should concentrate on the problem not the answer. I tend to disagree, however, when he asserts that Forth distracts from thinking about the problem. By the time one is ready to write code, the problem had better be solved already, otherwise, no language is going to help. That's what the modern software design methods teach us, anyway. As for program readability, I can take any language and make it completely unintelligible, what does that prove? To argue whether it is easier to write unreadable code in one language or another is silly. The point to make is that code should be readable, period. Mr. Orr has admitted that he hasn't used Forth for some time. That's no crime, but perhaps his attitude would soften a little bit if he were introduced to the more recent advances in the language's constructs (by recent I mean in the last five years). Use of multiple-code-field named variables reduces or eliminates the need for the @ and ! operations by imbedding them into the word itself. A variable is defined like before, except with an initial value: "0 VAR TEST". When TEST is executed, it pushes its *value* on the stack, like a constant. To store a new value in TEST one can say: "10 TO TEST". To get the address of TEST, one can say "AT TEST". The use of English verbs to describe the actions enhances readability, and the implementation of these words has actually proven to be faster than the traditional @ and ! way of doing things. Several Forths have implemented full data structure defining words which are analogous to C's struct and Pascal's RECORD. The syntax is clean and as readable as either of the other langauges. There are also "local variables", which assign names to input stack items at compile time. These can be used in lieu of the "DROP SWAP FLOP PLOP" stack thrashing phenomena. This does wonders to improve the readability of the code. Here, too, execution speed has been shown to be improved especially in those words which do a lot of stack thrashing. Use of structures which vector the run-time definition of a Forth word like the DOER/MAKE facility outlined in Brodie's Thinking Forth, can greatly enhance the readability and run-time efficiency of code that must change with time. By this I mean that a Forth word can be defined to perform one action under a certain condition and another action under some other condition. It helps to reduce coding messy IF-ELSE-THEN-type statements, and saves processor time that would otherwise be spent checking conditionals and performing branches. Perhaps the area where Forth has lagged behind other programming langauges such as C is in development tools: debuggers, context sensitive editors, etc. Things have improved on this front as well, although Forth is still behind. (One could argue that if C is so much easier to use than Forth, why have C programmers spent years writing development tools, while Forth programmers seem to get along just fine with only an editor -- could it be that Forth is so easy to test and debug that no expensive development aids are necessary? On top of this, the Forth compiler, i.e. the outer interpreter, can be modified to one's own needs, so the compiler itself becomes the most important development tool, ala the "integrated environment" so many other compiler vendors are promoting of late.) I have only given a glossy -- and fuzzy -- overview of some of the things that help make Forth easier to use and more powerful to code in. I am not saying that Forth is a be-all and end-all; so far, I have yet to find a programming language that is. I just want to see it get a fair shake, and not be judged solely on its past. By its very nature, Forth is a constantly and rapidly evolving beast. It can be extremely advanced and complex, or incredibly simple and small. How can anyone pin a single label on it? -- Lee Brotzman (FIGI-L Moderator) -- My opinions are my own and not those of my employer, ST Systems Corp., -- or their employer, NASA Goddard Space Flight Center, or their employer, -- Ronald Reagan, or his employer, Nancy Reagan, or her employer, the -- planets and stars.
ZMLEB@SCFVM.BITNET (Lee Brotzman) (08/04/88)
In article <718@amc.UUCP> pilchuck!amc!jon@uunet.uu.net (Jon Mandrell) writes: >In article <5703@batcomputer.tn.cornell.edu> olson@tcgould.tn.cornell.edu > (olson) writes: >>How would you compute if the process of calling proceedures had zero >>overhead? > > I have seen claims like this for Forth and the Novix chip for quite >a while. >1) What is the definition of zero overhead? The instruction must still > be fetched, and a return address must be stored somewhere. The overhead of a call on the NOVIX chip is one (1) clock cycle; a return from subroutine entails zero (0) clock cycles. Since the code memory, data stack and return stack are all separately addressable memory spaces running in parallel, the chip isn't wasting CPU cycles storing things away on the return stack before it can perform the call; it just does the whole thing in one fell swoop. Compare the cycle times with even the simple 6502 (4 cycles call; 4 cycles return) and you begin to see the difference. I attended a lecture by Charles Moore, co-inventer of the NOVIX, where he stated that a 68000 subroutine call required 20 clock cycles as did the return (I take this number with a grain of salt, unless someone else is willing to confirm it). The NOVIX parallel memory architecture allows it to perform some combinations of Forth operations in a single op-code. I believe the longest any op-code takes to complete is 3 cycles. The large majority of op-codes execute in one cycle. Add this all up and you can see why a NOVIX running at 8MHz can easily outperform a 68000 even if the latter is running at a faster clock speed. >2) Many people have said that C function calls are slower than forth. > No matter what processor you are on, a function call runs the same > speed, no matter what language compiled the code. Direct calls cannot > be less efficient than threaded code, at worst the things will come > out even. I agree. Perhaps the people to which you refer were thinking about the time necessary to set up the correct stack frame for a C call. It is easy for Forth programmers to forget that even though the parameters are already on the data stack when the word is called, they had to be put there somehow. The stack is a blessing and a curse. A blessing because it makes the internal structure of the language so simple; a curse because stack manipulations eat away a significant proportion of the processing time a Forth word takes to execute. (One of my favorite stack stories is of a programmer that redesigned a word and had to change the stack manipulation. After he debugged the word and got it going he took one last look at it. He discovered that in one part of the code he had the sequence: "DUP SWAP DROP" Now isn't that I nice little no-op feature?) See my earlier message which mentions the use of "local variables" for reducing the coding headaches and processing time involved in stack thrashing. >3) The claim that Forth generates more efficient code than a compiler. > I have problems with this, since inefficient code can be written in > any language. I have heard said that the programmer is pass 1 of > a Forth compiler, which does allow for more optimization at a very > low level. But, I would say the same thing can be done for C (and > a few other languages), if you know the code the compiler will generate. > Judicious use of language constructs will produce more efficient code. There are two kinds of efficiency: space and time. Traditional threaded Forth certainly wins in the space category. But I see no easy way that threaded code can be faster on any given processor (save the Forth chips cited above) than regular compiled code. That is, unless the compiler in question was written by complete bozos. There are compilers for Forth, though. Tom Almy wrote one for PC Forth which he mentioned here just recently. The code from these compilers rivals that of other languages. I also caught someone (sorry don't remember who right now) pointing out the limited addressable memory of the NOVIX chip, and how this limits the usefulness of the chip. One has to remember that this is Forth we are talking about, just because a Forth program compiles into 3K and an equivalent Pascal program compiles into 30K, doesn't mean the Forth program is any less functional. I believe the NOVIX chip supports 64 K words for code (128 Kbytes). One word holds either a Forth op-code (primitive) or subroutine call (invocation of a colon word). Since the op-codes are wired directly into the silicon, no memory space is wasted on a "kernel". Given the compactness of Forth, 64,000 words of memory will hold a LOT of Forth code. I regularly pack my Apple // with a kernel, development code (memory management, disk management, advanced data structure defining words, etc.), software floating point, a decompiler, source-level debugger, complete operating system interface, and source file editor. This totals about 35 K bytes of memory. Much of the above is implemented in 6502 assembler for speed. 6502 assembler takes up much more room than the equivalent NOVIX code would. Forth is probably the main reason I haven't felt the need to upgrade from an Apple // to a larger machine. I haven't outgrown the one I'm on yet! -- Lee Brotzman (FIGI-L Moderator) -- My opinions are my own and not those of my employer, ST Systems Corp., -- or their employer, NASA Goddard Space Flight Center, or their employer, -- Ronald Reagan, or his employer, Nancy Reagan, or her employer, the -- planets and stars.
olson@batcomputer.tn.cornell.edu (olson) (08/04/88)
>>How would you compute if the process of calling proceedures had zero overhead? In article <1557@crete.cs.glasgow.ac.uk> orr@cs.glasgow.ac.uk (Fraser Orr) writes: >In article <5703@batcomputer.tn.cornell.edu> olson@tcgould.tn.cornell.edu (olson) writes: >>I was going to let this slide, but given the tone of this posting and the >>next posting (about the Novix chip) by Mr Orr ... >>Mr Orr, >> Don't you think you are being just a little too viscous? >> Disagreement is wonderful, but only if all participants refrain >>from attacking each other. (Another "wonderful" "American" discovery) > >My appoligies if you found my remarks offensive Mr Olsen. To be honest ^o >I expected an erudite net'er like yourself to be able to recognise >good humoured sarcasm when you saw it. Oh. Well, sorry for missinterpreting the tone of your comments. I must confess that your remarks fell on my eyes as those of one with an axe to grind against all aspects of forth, apparently blindly. Glad to hear this is not the case. [... good comments about problem solving deleted ...] >>Thus one might argue that the advantage to forth is that it lets you >>move from thinking to thinking and experimenting. > >This is the crux of the matter, can you justify this statment. Possible we have different styles of problems in mind. The problems I deal with have few direct antecedents. At the start I think about the nature of the problem, and usually I come up with several viable approaches. How do I pick one to work on? Well, 6 or 7 years ago, I would just sit and think more. This resulted in several years of very slow progress on my research. The method I am trying now, is when thinking begins to have diminishing returns for me, then I go and "play". This means try something and see what the results are. Play requires highly interactive experimenting. Every thing is variable, including the problem statement and what goes in to it. After enough play, I have learned enough, made enough observation, tried enough experiments, that I can begin making hypothesis. Eventually playing gives diminishing returns so I go back to thinking. After many cycles the problem becomes well enough defined in my mind that it can be stated and evaluated in theorem proof form. But until then I find play/experiment essential. For me the key to making headway on a problem is knowing how and when to apply one style or the other to the problem at hand. Further, which of several approaches is "best" frequently depends on how I hope to extend the problem after the immedeate concerns are addressed. I find that solutions to my problems are usually a language for discussing the issues of the problem. I find that languages such as C,FORTRAN,Pascal,... tend to actively inhibit my efforts to create such languages. I find that forth does not. One might argue that the proper medium for creating languages is a language generator (eg YACC/LEX). I would argue that that is what Forth is. Further to develop a useful language you must use it, play with it, experiment with it. I feel that forth supports this aspect well. Well, I'm wearing out. I hope this speaks to the point some what. Let me remark that I find a lot of flaws in Forth. I have a project in the wings for taking the forthness of forth and implementing it better, to demonstrate and improve the good points of forth. Or maybe it will show the converse. >... >>How would you compute if the process of calling proceedures had zero overhead? >Are you trying to say forth has zero overhead for calling procedures? No. Seems as though the context intruded more than I thought it would. (oops) I meant the question to be taken independent of the forth context. >Am I completely missing your point here? I'm probably being obscure. I have seen and even written C code, that for the sake of speed and clarity have used a fair number of macros. The clarity could have been achieved by using proceedure calls but the over head of making a C procedure call (creating the stack frame and all) was deemed to be too much. I prefer forth's way in this case. Also C programs can be found that have switch statements with substantial code blocks at each case point. Forth's style would be to make each block a proceedure and at each case point only a proceedure call would occur making the code more readable one hopes. Admittedly this is in some sense a matter of style. But it seems to me that the styles fostered by a language and it's community are as important as the language itself. Forth fosters "factoring" via the preception of low overhead for invoking a word, C does not via the perception of a modest cost for invoking a proceedure. Style(?). This was the thrust of my question. But I am curious if from sort of first principles thought the question produces ideas at odds with existing languages? That is why I asked it the way I did. When I say I program in C (FORTRAN, ..) in Forth style what I mean is that I factor thing as much as possible. (Then if performance demands, I put some of the pieces back together.) Is this what other people mean by working in the forth style? >... >>And that in some sense the Unix "philosophy" is very forth like. > >Justification? The Unix "philosophy" as I understand it is to write your programs in such a way that they do one simple task and that they cooperate with each other so that they can be combined into more complex tasks. This is a good explanation of the the forth idea of factoring. Maybe the confusion here is that for me Forth is only loosely related to it's implementations. >... > >I feel that gorups like comp.lang.forth can become very narrow minded >(the group has a very narrow set of discussion topics, I'm not trying to >suggest that the participants are narrow minded of course!) It is good >to discuss the things that other people are doing, in a way that is >relevant to your subject of interest. As I mentioned previously I have >never understood why Forth'ers are not prepared to use parsers so that >their code is more readable. Lets see what we can learn form each other >instead of indulging in mindless "I think my language is better than yours" >wars. I accept that Forth is fast on Forth chips, I also assert that >C or Pascal are easier to program in. What can I learn from you, >and what can you learn from me? >==Fraser Orr ( Dept C.S., Univ. Glasgow, Glasgow, G12 8QQ, UK) Nicely said. I disagree at several points. 1) parsers make code more readable. ??? I can't agree. 2) I would venture that "forth chips" 3) Pascal and C are easier to program in ??? I can't agree. I do agree that we should learn from each other. I intend to barrow every good idea I have ever come in contact or ever will. Incidently forth is one of the few systems that makes it easy to add on a good language feature to the existing language. For example it is very hard for C to learn from ICON. I have found C, etc useful because by being static in syntax they have taught me how discover both the good points and the limit to a particular syntax. For me it is now time to go beyond this. I need to be able to add to the good pieces I already have. To me forth (or my rendition of forth (one of forths weakness, no?)) is the best tool I have found so far building languages. For example I think forth offers me the best scheme for merging C++ and Icon. Now I agree that these things can not be done haphazardly. And with out a lot of self dicipline it is easy to make a mess in forth. But it can also do more within its frame work than anything else I know. This is vague. Give me a couple of years. Then I will be in a position to show you by example what I mean. Or I will have learned by experimenting that this approach is not viable. Todd Olson olson@helios.tn.cornell.edu
jax@well.UUCP (Jack J. Woehr) (08/05/88)
In article <1557@crete.cs.glasgow.ac.uk> orr@cs.glasgow.ac.uk (Fraser Orr) writes: > >Are you trying to say forth has zero overhead for calling procedures? >Am I completely missing your point here? On the Novix and chips allied to it in design, the answer is " not Zero, but one machine cycle for call, and frequently *<1* for return." > >why Forth'ers are not prepared to use parsers so that >their code is more readable. Lets see what we can learn form each other >instead of indulging in mindless "I think my language is better than yours" >wars. I accept that Forth is fast on Forth chips, I also assert that >C or Pascal are easier to program in. What can I learn from you, >and what can you learn from me? > Good point Fraser! In your defense, i think most of us have found your off -the-cuff assessment of Forth not only humorous, but quite familiar. It is clear, though, that serendipity has not been achieved in your waltz with Forth! We Amerrycuns would say, "You ain't grokked it yet, man!" To the Forth world, the Forth parser is a *model* of *simplicity*, *economy* and *clarity*. Further, if you would care to informally research the matter, I believe you will not find a computer language that attracts such a high percentage of linguistically talented individuals as Forth. Forth rewards skill with language arts; I would say that the C language rewards ability at making college outlines. Seriously, if you have enough acquaintance with Forth to understand, I would recommend you purchase a major text like Dr. C.H. Ting's _Inside F83_ and "nest down" through an examination of the parser code starting at QUIT . There is nothing quite so pristine and beautiful in all of parser theory as the Forth outer interpreter! ***** jax@well ... host of the WELL FOrth Conference jax@chariot JAX on GEnie "Forth programmers get it up faster!"
orr@cs.glasgow.ac.uk (Fraser Orr) (08/08/88)
There have been many interesting responses to my earlier articles on this subject, and I would like to reply to them all in detail, but I don't come here merely to write articles in comp.lang.forth! I'll follow up to Lee Brotzman's excellent article and hope to answer the rest of your comments in so doing. In article <8808032106.AA01436@jade.berkeley.edu> ZMLEB@SCFVM.BITNET (Lee Brotzman) writes: > >not the answer. I tend to disagree, however, when he asserts that Forth >distracts from thinking about the problem. By the time one is ready to write >code, the problem had better be solved already, otherwise, no language >is going to help. That's what the modern software design methods teach us, >anyway. True. The purpose of a programming language is to describe precisely this solution in a way that is clear primarily to the people who are going to maintain the program, and secondarily to make it easy to type in. > As for program readability, I can take any language and make it completely >unintelligible, what does that prove? To argue whether it is easier to >write unreadable code in one language or another is silly. The point to >make is that code should be readable, period. Mr. Orr has admitted that he >hasn't used Forth for some time. That's no crime, but perhaps his attitude >would soften a little bit if he were introduced to the more recent advances >in the language's constructs (by recent I mean in the last five years). > Yes, this is a point many people have made. I accept that the example I gave was pretty unfair. But if you look at a fairer comparison int Fact ( n ) : Fact ( n -- n! ) { VS Dup if ( n > 0 ) -- 0= If return n*fact(n-1) Drop 1 Exit else Else return 1 ; Dup 1- Fact * Then ; Given by David Murray, then I think my point is made most succesfully. If we look at a good peice of Forth code we get lovely lines like "Dup 1- Fact *" and I'm sorry to say that I cannot accept that that is anywhere near as clear as "n*fact(n-1)". Yes I accept that with practise it becomes much easier, why put the extra mental load on yourself of having to maintain a picture of the top of the stack, when you could (as the C does) keep it all above board. If I see something like "while(*s) *s++=*p++" in a C program, I understand it, but that doesn't make it nice. Some people might say that this is trivial, but I just don't agree, in the same way that if I slur my speech or misspel my wardz it puts a barrier between you and me, if there is this extra mental decoding going on in programming, you are moving one step closer to the code and one step farther away from the meaning of the program. What is the objection to having infix operators? People have also said that forth is generally written much better than C and other such languages. This is true, and as someone else said it is pretty tough seperating the programming language from the way it is idiomatically used. But for people who are interested in programming languages this is an effort that must be made. We must find out what is good about a language independently of the way it is used (it would also be interesting to know what makes people use a language badly, but that's a different story) > Use of multiple-code-field named variables reduces or eliminates the need >for the @ and ! operations by imbedding them into the word itself. A variable >is defined like before, except with an initial value: "0 VAR TEST". When >TEST is executed, it pushes its *value* on the stack, like a constant. To >store a new value in TEST one can say: "10 TO TEST". To get the address of >TEST, one can say "AT TEST". The use of English verbs to describe the actions >enhances readability, and the implementation of these words has actually >proven to be faster than the traditional @ and ! way of doing things. > This is interesting, I can't even imagine how it works! Certainly though this is a step in the right direction. Your right that the last book I read on forth was on Forth83, which was before your stated time limit. > Several Forths have implemented full data structure defining words which >are analogous to C's struct and Pascal's RECORD. The syntax is clean and >as readable as either of the other langauges. > Interesting. This leads to another question I have. You tell me that forths have improved a great deal over the past few years. Have type sytems come into being yet? It is certainly possible since PostScript has a type system. Records are only a syntactic sugar ( which is in itself a good thing) without a supporting type checker (of course at this stage C bites the dust!) Have these structures been incorperated into a standard? If not then for most applications you can't really think about using them. > There are also "local variables", which assign names to input stack items >at compile time. These can be used in lieu of the "DROP SWAP FLOP PLOP" >stack thrashing phenomena. This does wonders to improve the readability >of the code. Here, too, execution speed has been shown to be improved >especially in those words which do a lot of stack thrashing. > :-) Horray! This is another step in the right direction. Unfortunately if I may quote your later article on this subject. For simple, one- or two-line words (the kind of Forth words everyone should strive to write anyway), the use of local variables does not help that much. A Forth programmer should train himself to visualize at least a three-deep stack in his head. By using comments with stack pictures, it is relatively easy to keep track. :-( Why? If you need pictures to keep track you need named local variables. > (One could argue that if C is so much easier to use than Forth, why have >C programmers spent years writing development tools, while Forth programmers >seem to get along just fine with only an editor -- could it be that Forth is >so easy to test and debug that no expensive development aids are necessary? >On top of this, the Forth compiler, i.e. the outer interpreter, can be >modified to one's own needs, so the compiler itself becomes the most important >development tool, ala the "integrated environment" so many other compiler >vendors are promoting of late.) > If I were being equally glib(-:) I might ask, how come if forth is so much easier to program in, have forth programmers not managed to produce these essential tools in and for forth? > I have only given a glossy -- and fuzzy -- overview of some of the >things that help make Forth easier to use and more powerful to code in. >I am not saying that Forth is a be-all and end-all; so far, I have yet >to find a programming language that is. I just want to see it get a >fair shake, and not be judged solely on its past. By its very nature, >Forth is a constantly and rapidly evolving beast. It can be extremely >advanced and complex, or incredibly simple and small. How can anyone >pin a single label on it? Equally if it is so fast evolving how can anyone get down to actually using the features that are being added. I agree that there is no such thing as the idea language (and anyone out there who has the idea that I think that C is the best programming language, please change it, your ruining my reputation:-) but I feel that forth is really too low level to be much use except in very special cases. But in those special cases (such as PostScript, epsecially if prvided with a good preprocessor) it is great. I should say further that I have been very interested in the stuff about the NOVIX chip. It sounds a prety impresive beast. I wonder how that sort of technology could be applied to "general microprocessors"? ==Fraser Orr ( Dept C.S., Univ. Glasgow, Glasgow, G12 8QQ, UK) UseNet: {uk}!cs.glasgow.ac.uk!orr JANET: orr@uk.ac.glasgow.cs ARPANet(preferred xAtlantic): orr%cs.glasgow.ac.uk@nss.cs.ucl.ac.uk
ralf@b.gp.cs.cmu.edu (Ralf Brown) (08/10/88)
In article <1563@crete.cs.glasgow.ac.uk> orr@cs.glasgow.ac.uk (Fraser Orr) writes: }>seem to get along just fine with only an editor -- could it be that Forth is }>so easy to test and debug that no expensive development aids are necessary? }>On top of this, the Forth compiler, i.e. the outer interpreter, can be }>modified to one's own needs, so the compiler itself becomes the most important }>development tool, ala the "integrated environment" so many other compiler }>vendors are promoting of late.) }> }If I were being equally glib(-:) I might ask, how come if forth is so much }easier to program in, have forth programmers not managed to produce these }essential tools in and for forth? Let's see now, Laxen & Perry F83 has: editor decompiler assembler debugger multitasker print spooler listing printer and of course, compiler/interpreter Sounds like *more* than most so-called integrated environments offer! No fancy windowing/menu system, but what do you expect from 26K ? :-) -- {harvard,uunet,ucbvax}!b.gp.cs.cmu.edu!ralf -=-=- AT&T: (412)268-3053 (school) ARPA: RALF@B.GP.CS.CMU.EDU |"Tolerance means excusing the mistakes others make. FIDO: Ralf Brown at 129/31 | Tact means not noticing them." --Arthur Schnitzler BITnet: RALF%B.GP.CS.CMU.EDU@CMUCCVMA -=-=- DISCLAIMER? I claimed something?
orr@cs.glasgow.ac.uk (Fraser Orr) (08/11/88)
In article <2651@pt.cs.cmu.edu> ralf@b.gp.cs.cmu.edu (Ralf Brown) writes: >In article <1563@crete.cs.glasgow.ac.uk> orr@cs.glasgow.ac.uk (Fraser Orr) writes: >}If I were being equally glib(-:) I might ask, how come if forth is so much >}easier to program in, have forth programmers not managed to produce these >}essential tools in and for forth? > >Let's see now, Laxen & Perry F83 has: > editor > decompiler > assembler > debugger > multitasker > print spooler > listing printer >and of course, > compiler/interpreter adb ar as cc ctags dbx e ed edit error ex ex eyacc gcore gprof indent ld lex lint lpq lpr lprm make man nm pmerge pr prof ranlib sccs size strings strip tar time touch vgrind vi yacc These are some of the tools on my UNIX system for c programming, I make it 39, vs your 8, hmmh. Oh of course you include process mangment in your list so there is also ps, w, kill ....:^) >Sounds like *more* than most so-called integrated environments offer! No >fancy windowing/menu system, but what do you expect from 26K ? :-) I don't expect anything form 26K, as I mentioned previously I've got 12Mb, moreover I can't think of many general purpose computers of more than a couple of years vintage that have anywhere near as little as this(though I'm sure your all about to release me of my ignorance!) And yes your right I did forget all the windowing stuff, suntools, shelltool, dbxtool ... <-: ==Fraser Orr ( Dept C.S., Univ. Glasgow, Glasgow, G12 8QQ, UK) UseNet: {uk}!cs.glasgow.ac.uk!orr JANET: orr@uk.ac.glasgow.cs ARPANet(preferred xAtlantic): orr%cs.glasgow.ac.uk@nss.cs.ucl.ac.uk
jax@well.UUCP (Jack J. Woehr) (08/16/88)
In article <1567@crete.cs.glasgow.ac.uk> orr@cs.glasgow.ac.uk (Fraser Orr) writes: >In article <2651@pt.cs.cmu.edu> ralf@b.gp.cs.cmu.edu (Ralf Brown) writes: >>In article <1563@crete.cs.glasgow.ac.uk> orr@cs.glasgow.ac.uk (Fraser Orr) writes: >>}If I were being equally glib(-:) I might ask, how come if forth is so much >>}easier to program in, have forth programmers not managed to produce these >>}essential tools in and for forth? >> Good sport and loyal comp.lang.forth poster Fraser goes on to compare a short stack of 8 Laxen & Perry F83 utilities to 39 unix utilities. Straw dogs. Some utils mentioned like vi are much harder to use than the minimalist line editor! Certainly the Wil Baden full screen editor in F83X,F83S is a masterpiece of programming, in Forth or any other language. Other unix utils are easily mimicked intepretively in Forth, and do not require inclusion in a "master set" of compile utils. Utils performing passes on block files analogous to, say, grep or wc can be entered at the keyboard, and are, by professional forth programmers. These types of utils are personalized and given functional relevance not by -abcd command line options, but by being re-written each time they are used! That's the kind of rapid-flow, free form doggie Forth is! Lastly, if Forth had had twenty-odd years of corporate sponsorship from a mega-billion $ (thousand million to our friends on the other side of the Atlantic River) conglomerate, there would be enough utils written and canonized to bury your 12Meg mainframe as deep as a Celtic king in a peat bog! *********** well!jax@lll-winken.arpa "Keep your xi-stack" JAX on GEnie "I'll show you my interpreter if you'll show me yours!" jax@chariot.UUCP " Forth programmers get it up faster!"
hjm@cernvax.UUCP (hjm) (08/16/88)
OK, Laxen & Perry = 8, Orr = 53.
Mr. Orr, are you sure more is better? You assume that because
you need 53 tools to program in C, then others must require 53
tools to program in X, Y or FORTH. If these tools were necessary
for FORTH programming, do you not think that someone would have
written them?
To me, the most important idea in computing is Occam's Razor:
keep it as simple as possible. I loath the inflated operating
systems of the world, just as much as I detest the unnecessary
complication that most of the computing world revels in. If 8
tools do all that is needed in 26KB, then great! That's (12 Mb -
26 Kb) *less* code that has to be written. Less code means writ-
ten quicker, which means cheaper systems for me to play with.
How much do you pay for your compiler/support tools/windows/cute
menus and the like? A lot. UNIX, VMS, MVS and the like? Too
big, too expensive, too inflexible. And how many latent bugs are
there in that 12 Mb of code?
Small = fast = cheap = efficient = flexible = intelligible = us-
able = provable = less bug ridden = more maintainable = ... (need
I say more?)
Hubert Matthewsorr@cs.glasgow.ac.uk (Fraser Orr) (08/18/88)
In article <6826@well.UUCP> jax@well.UUCP (Jack J. Woehr) writes: > > Good sport and loyal comp.lang.forth poster Fraser goes on >to compare a short stack of 8 Laxen & Perry F83 utilities to 39 unix >utilities. > > Straw dogs. Some utils mentioned like vi are much harder to >use than the minimalist line editor! Certainly the Wil Baden full >screen editor in F83X,F83S is a masterpiece of programming, in Forth >or any other language. > Hmmh, I was tempted to redirect follow ups to comp.editors and say something like I *like* vi, and can use it *very* efficiently. But lets not start an editor war (in comp.lang.forth anyway), especially since I've never used you favorite editor. > Other unix utils are easily mimicked intepretively in Forth, >and do not require inclusion in a "master set" of compile utils. >Utils performing passes on block files analogous to, say, grep or > wc can be entered at the keyboard, and are, by professional forth >programmers. These types of utils are personalized and given functional >relevance not by -abcd command line options, but by being re-written >each time they are used! That's the kind of rapid-flow, free form >doggie Forth is! I can write C programs to do things like grep and wc, and it doesn't require too much effort. Why don't I? coz some smart cogger has done it before, so I don't need to make the effort. Sure there is all this command line option stuff, but on all the tools that I use regularly I can remember all the important options, and I bet you that those I can't remember I can look up faster than you can write a grep program in forth. Hubert Matthews says in his article (sorry I'm not quoting, but I never did work out how to follow up to two articles in Pnews!) that having a lot of different utilities was not necessarilly a good idea, and I've got to agree, but the utilities I mentioned really are pretty cohesive, so by saying 39 (or however many) utilities, I am saying 39 useful functions, vs 8 useful functions. It is my ambition, to save people having to remember command names, to write a unix utility called "command" that does everything you want.E.g., command -ls lists the current directory, command -cat filename | command -wc -l copies the file named "filename" into a pipe and counts the number of lines etc, What do you think?:-> > > Lastly, if Forth had had twenty-odd years of corporate sponsorship >from a mega-billion $ (thousand million to our friends on the other side >of the Atlantic River) conglomerate, there would be enough utils written >and canonized to bury your 12Meg mainframe as deep as a Celtic king in >a peat bog! > "Ifs" are wonderful things. Forth doesn't have this kind of sponsorship. I'm interested in what I can do, not in what might have been. The fact is that UNIX is MUCH better tooled than any forth environment than I have ever seen (which admitedly isn't a lot), or heard of (and I presume you are telling me about the best there is.) Someone else mentioned on this subject (I think it was Hubert again) that with all these megabytes of code the system must be riddled with bugs. Anyone who has used UNIX will know that this is true. The reason, coz UNIX is written in a tacky programming language - C. Now to say that C is tacky is not to say that forth is less tacky than C. I have in previous postings stated that I think of forth as a reasonably pleasant assembler language. I reckon that in a UNIX sized system written in forth, programmed by the same types who wrote UNIX would be substantially more bug ridden than UNIX, would probably be much harder to use (because the RPN thing would pervade the whole system) and would have taken much longer to write. This is of course only my opinion, and I have no facts whatsoever to back this up, but that never stopped me before <^: Regards, ===Fraser Orr (orr%cs.glasgow.ac.uk@nss.ucl.ac.uk)
peter@sugar.uu.net (Peter da Silva) (08/21/88)
In article <1573@crete.cs.glasgow.ac.uk>, orr@cs.glasgow.ac.uk (Fraser Orr) writes: > Hmmh, I was tempted to redirect follow ups to comp.editors and say > something like I *like* vi, and can use it *very* efficiently. But lets > not start an editor war (in comp.lang.forth anyway), especially since I've > never used you favorite editor. I like 'vi' so much I wrote a screens editor based on it in Forth. It even a ':' command to pop you back into forth to do line-editor commands. It started in John James' FIG-Forth for the PDP-11, and has been ported to CP/M, Apple, IBM-PC, and HP 1000. Let me see if I can dig up a copy... -- Peter da Silva `-_-' peter@sugar.uu.net Have you hugged U your wolf today?
hjm@cernvax.UUCP (hjm) (08/21/88)
In article <1573@crete.cs.glasgow.ac.uk> orr%cs.glasgow.ac.uk@nss.ucl.ac.uk (Fraser Orr) writes: >In article <6826@well.UUCP> jax@well.UUCP (Jack J. Woehr) writes: >It is my ambition, to save people having to remember command names, to write >a unix utility called "command" that does everything you want.E.g., > > command -ls > >lists the current directory, > > command -cat filename | command -wc -l > >copies the file named "filename" into a pipe and counts the number of lines > >===Fraser Orr (orr%cs.glasgow.ac.uk@nss.ucl.ac.uk) Great, add in 9 extra characters to type and make people remember "options" and not "commands". Since all of your "commands" now begin with the same 9 characters, why not get the shell to add them on for you to save typing? So, your commands would be easily remembered as: ls and cat filename | wc -l Sounds good, huh? A major advance in user-ergonomics! Hubert Matthews
XRBEO@VPFVM.BITNET (Bruce O'Neel) (08/23/88)
Just one thought about unix tools and enviornments vs forth tools and enviornments. Many of the USEFULL unix like tools are in Zimmer et al's f-pc forth for ms-dos. Even though I like forth I always had reservations which f-pc mostly resolved. bruce
jax@well.UUCP (Jack J. Woehr) (08/23/88)
In article <804@cernvax.UUCP> hjm@cernvax.UUCP () writes: >In article <1573@crete.cs.glasgow.ac.uk> orr%cs.glasgow.ac.uk@nss.ucl.ac.uk (Fraser Orr) writes: >>In article <6826@well.UUCP> jax@well.UUCP (Jack J. Woehr) writes: >>It is my ambition, to save people having to remember command names, to write >>a unix utility called "command" that does everything you want.E.g., ...(much deleted) hjm@cernvax ( humbert) that was Orr's reply to me you quoted, not my posting. Am sure this is just a vipo ( a vi typo)! :-) It is not my ambition to write Unix utilities! Innocent! Where's my mouthpiece? ****************** jax@well.UUCP jax@chariot.UUCP " I'll retain my native Forth while you all become Unix ..." JAX on GEnie
anderson@c10sd3.StPaul.NCR.COM (Joel Anderson) (08/24/88)
Wet paint signs usually encourage people to touch, not avoid their object.
After all the talk of straw dogs, peat bogs and mega buck utilities dies
down, a certain note of appreciation must be sent to Fraser Orr et al for
the refreshing burst of activity that has been given to this newsgroup.
Fraser's words have rekindled my interest in Forth - fact is the terminal
program I am using now (on my C64) is written in Forth, and allows me not only
to telecommunicate, but drop out and run graphic words, music, and edit program
source. Too long have I used the system without using its full potential.
(This system includes a more than complete implementation
of Forth83, plus music, turtle graphics,full screen editor, you get the idea -
gosh, there might be more than 39 utilities in here).
Fact is - ( can you say 'appropriate technology', 'small is beautiful'? - I knew
you could ) I can do scads of very, very useful things with this system.
You don't need a massive expensive system to do meaningful work.
This implementation of Forth (Blazin' Forth, by Scott Ballantyne) was snatched
from Quantum Link for pennies (well a few dollars).
Needs be, I could replace my whole system for $300 bucks, less if I go with
used equipment. Forth is not the only solution for every problem, but it
does give professional power in a nice, small and reasonably priced
system. Not only that - I use it routinely as a smart terminal
to access C, Lisp, BAL and other language systems.
And I don't even have grep!
------------------------------------------------------------------
anderson@c10sd3.StPaul.NCR.COM JPA on Q-Link
Joel Peter Anderson
NCR Comten / Software engineer
-------------------------------------------------------------------------
"..If you own a machine, you are in turn owned by it, and spend your time
serving it...." The Forbidden Tower, Marion Zimmer Bradley
-------------------------------------------------------------------------