orr@cs.glasgow.ac.uk (Fraser Orr) (08/30/88)
In article <472@umn-d-ub.D.UMN.EDU> gandreas@ub.d.umn.edu.UUCP (Glenn Andreas) writes: >As a disclaimer, I want it noted that I like the basic idea behind forth. >It is elegent. And there are some neat things you can do with it. And it >is small. I like forth since I first learned about it in 82? when Byte did >an issue on it. I just don't like the syntax WITH REGARDS TO ARITHMETIC >EXRESSION (I have no problems with the RPN of procedure calls, although >control statements are a minor hassle - this is something you can get use >to). Don't you mean that you like one of the consequences of the basic idea behind forth, that you get what you consider to be a nice procedure call mechanism. The things that you have problems with are to my mind much more direct consequences of the RPN is best attitude. Need I say that you could have the best of both worlds if you wrote a preprocessor that RPNed your arithmetic and control structures? At the same time you could add all the other nice things - structures, type checking, at least optional parameter lists, my nice implicit parameter passing stuff etc,etc,etc. Sorry if your getting bored hearing me saying the same thing over and over and over and over again, but really I've yet to here a serious objection to it. Regards, ===Fraser
pmy@vivaldi.acc.virginia.edu (Pete Yadlowsky) (09/01/88)
In article <1593@crete.cs.glasgow.ac.uk> orr%cs.glasgow.ac.uk@ucl.nss.ac.uk (Fraser Orr) writes: >Need I say that you could >have the best of both worlds if you wrote a preprocessor that RPNed your >arithmetic and control structures? At the same time you could add all the >other nice things - structures, type checking, at least optional parameter >lists, my nice implicit parameter passing stuff etc,etc,etc. Baggage, baggage and more baggage. Type checking?! *gag* I don't want some uppity compiler protecting me from myself and telling me how I may and may not use my computer. That stuff's fine for beginners, but when it's time to cut loose and actually put the machine to work... Incidentally, some Forths (JForth, for the Amiga, for instance) do provide C-like struct syntax. I only use this, though, to facilitate system calls, as the Amiga is very C-oriented. Forth is, more than anything else, a language used to implement languages... a meta-language. No skilled Forth programmer writes applications in raw Forth. S/he uses it to build a custom language that suits the application; that is, in fact, the application itself. If that means postfix arithmetic, fine, throw it in there. If it requires some sort of data structure, create it. But why should the system and the programmer have to lug around *all* of this "nice" traditional stuff when it is unnecessary and inappropriate? I think most of your complaints about Forth are aimed at its bare-metal bottom level. But, as I've said, the seasoned Forth programmer gets away from this as quickly as possible by building ever higher levels of abstraction and developing conceptually useful vocabularies. With traditional compilers, however, the programmer is stuck with the compiler's single vocabulary/syntax, so it had better be rich and sufficiently complex. You seem to be regarding Forth, through tradition-colored glasses, as yet another language with fixed vocabulary and syntax. In skilled hands, it is not. If it was, it would indeed be as objectionable as you say. Somehow I think this has all been said a hundred times already. Sorry for any redundancy. >Sorry if your getting bored hearing me saying the same thing over and over >and over and over again, but really I've yet to here a serious objection >to it [a set of traditional constructs]. Don't want it. Don't need it. Don't want to pay for it (with money, time, memory, or undue complexity). Is this serious enough? Peter M. Yadlowsky Academic Computing Center University of Virginia pmy@vivaldi.acc.Virginia.EDU
A01DLH1@NIUENG.BITNET (Don Hayes) (09/02/88)
Hi, I have been following the discussion of FORTH and how different features are viewed as *good* or *bad* by different persons. I believe this is just as likely to occur about any language. I do not claim to be expert in FORTH by any means. I am a Systems programmer on a VM system right now, and after over 20 years in the field of Programming and Systems, i don't see any languages which have all the answers for all problems. I am just fascinated by the possibilities of FORTH in a real time environment. My FORTH involvment is on a IBM PC compatible, and can only be classified as dabbleing. I don't spend much time on the PC at home after working on a terminal all day. But, for some reason i was attracted to FORTH when i first read about it several years ago. Reading Frazer Orr's comments has brought to mind other questions. Why does he keep dwelling on a FORTH compiler? Is he perhaps writeing one that he hopes to sell? Or is he just anti-FORTH because he cannot comprehend the usefullness of being able to tailor a language to fit ones needs? It seems to me that a compiler would eliminate a lot of the function of FORTH and make it just another structured language. It would not then be as good a solution for the problems that it now does well. As to the question some time back about why so many programmers chose and still choose to use COBOL, they very likely only have the choice of COBOL, FORTRAN or ASSEMBLER for business programs. From these, which would you choose? ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ Don Hayes A01DLH1 at NIUENG.BITNET VM Systems Programmer Northern Illinois University Dekalb, Il USA
jax@well.UUCP (Jack J. Woehr) (09/02/88)
In article <1593@crete.cs.glasgow.ac.uk> orr%cs.glasgow.ac.uk@ucl.nss.ac.uk (Fraser Orr) writes: >In article <472@umn-d-ub.D.UMN.EDU> gandreas@ub.d.umn.edu.UUCP (Glenn Andreas) writes: >>As a disclaimer, I want it noted that I like the basic idea behind forth. (much deleted) >>I just don't like the syntax WITH REGARDS TO ARITHMETIC >>EXRESSION (I have no problems with the RPN of procedure calls, although >>control statements are a minor hassle - this is something you can get use >>to). > >Don't you mean that you like one of the consequences of the basic idea >behind forth, that you get what you consider to be a nice procedure call >mechanism. The things that you have problems with are to my mind much more >direct consequences of the RPN is best attitude. Need I say that you could >have the best of both worlds if you wrote a preprocessor that RPNed your >arithmetic and control structures? At the same time you could add all the >other nice things - structures, type checking, at least optional parameter >lists, my nice implicit parameter passing stuff etc,etc,etc. > >Sorry if your getting bored hearing me saying the same thing over and over >and over and over again, but really I've yet to here a serious objection The key word in that sentence is "hear", Fraser. You haven't "heard" Forth. You are all wrapped up in that academic conceptualization of conceptualizations about computing. Heck, I'll bet you say "instantiate" instead of "store" :-) Forth is a *rethinking* and *retooling* of the fundamental constructs of serial computation. Maybe it is a little late for that, standing as we are at the dawn of parallel, but better late than never? If individuals as intelligent as yourself would get down on your knees and peer through the keyhole, you would see that Forth is the assembly language of a more powerful model of serial computing. But megabux are committed to the old way, so who cares? The only people who care are those of us who have no committment to the old way. **************************** jax@well ." Meditate, my chela, upon the zero-cycle subroutine return" jax@chariot ." Now open your hands ... see? No return, no zero!" JAX on GEnie ." This one is not far from enlightenment ..."
adam@hpmtlx.HP.COM ($Adam Kao) (09/02/88)
Fraser, the reason I like forth is because it's INCREMENTALLY COMPILED.
This means I get the fast turnaround of an interactive system (think-edit-
run vs. think-edit-compile-run) while generating code that runs almost as
fast as compiled code.
The reason I dislike C (or any other compiled language) is you can only use
it if you fully understand the language already. You can't explore. For
instance, while learning how to program with the X window system there were
many many times when I really needed to know whether some construct would
work or not. Sometimes, by the time I finished editing-compiling-running
a program to test my construct, I had forgotton what I was doing before.
Fast interactive systems are essential for fast learning. Often you want to
put what you're doing aside to examine some part of your code in more detail.
The faster you can do that and come back ('return from the subroutine' :-)
the smoother your overall development process will go. There are two ways you
can achieve this: You can buy a ten thousand dollar development system or
you can have an interpreted or incrementally compiled language.
I think this and the other reasons that have already been posted are excellent
justification for rejecting a preprocessor.
There is another point you made which I think deserves answer. You mentioned
that extensible languages lead to 'Towers of Babel' when many programmers
try to work together on the same project. This may be the most relevant
thing you've said yet :-). In fact, I think you should read "Computer
Languages" by Naomi S. Baron, Anchor Press/Doubleday. Ms. Baron is a linguist,
and her assessment of twenty-two popular and interesting computer languages
is both insightful and fair. (Needless to say, her assessment of Forth pays
appropriate homage to its unique power :-).
Ms. Baron says, in essence, that non-extensible languages are designed for
programming large systems where many programmers must read each others' code
and most code written is expected to have a useful lifetime of years or even
decades. The designers of Ada made explicit reference to this principle when
deciding to make Ada non-extensible.
Extensible languages, on the other hand, are designed for rapid prototyping,
usually one programmer with one vision. In this environment, most programs
don't even exist long enough to be given a name. That's why Artificial
Intelligence researchers MUST have an extensible language like Lisp or Prolog.
So this is really a question of technology appropriate to the situation. What
you say about large programming projects is true, but you haven't acknowledged
the OTHER programming philosophy.
I subscribe to the second philosophy. I am not interested in creating huge
systems where my contribution is relatively minor. I am not interested in
programming for the Department of Defense. I view programming as a form of
personal expression, a way to create order and pattern that rivals poetry
in power and insight.
Someone (in this group?) once said, Forth rewards writing skills, Pascal and
C reward outlining skills.
About RPN: Fraser, living in Europe you should understand this better than
most Americans. The most effective way to communicate with someone else is
to speak THEIR language, not make them speak yours. RPN is closer to
the computer's native instruction set, it maintains a strict correspondence
between Word and Instruction(s). I defy you to produce an infix notation
that can be interpreted at anything lower than the Statement level. This
really is important - you MUST write a multi-state parser to interpret
infix notation, while RPN words compile themselves.
Don't think I mean we should all program in assembly language (though I do
think we should all know how). My point is that Forth provides all the
power of a high-level language while maintaining direct control of the
low level bits. I know that when I program in C or Lisp I often feel
totally isolated from the hardware - not insulated, ISOLATED. And often
I NEED to know what's going on in some memory location to fix my bugs.
That's why there are so many debuggers for C and so few for Forth.
These last two points are more eloquently stated in 'Thinking Forth', by
Leo Brodie. I know this book has been mentioned before, but it bears
repeating (and rereading). If you want to understand Forth, (and I don't
think you should argue about what you don't understand) you MUST read this
book. If you've read it already, read it again, more carefully.
I apologize for blasting you, lo these many weeks ago. I see you've learned
effective use of the :-). Good. :-)
Adamns@cat.cmu.edu (Nicholas Spies) (09/02/88)
In article <7002@well.UUCP> jax@well.UUCP (Jack J. Woehr) writes: ... > Forth is a *rethinking* and *retooling* of the fundamental > constructs of serial computation. Maybe it is a little late > for that, standing as we are at the dawn of parallel, but better > late than never? Watch for an article on Forth on a very large parallel computer in the Journal of Forth Applications and Research.... -- Nicholas Spies ns@cat.cmu.edu.arpa Center for Design of Educational Computing Carnegie Mellon University
orr@cs.glasgow.ac.uk (Fraser Orr) (09/06/88)
In article <7002@well.UUCP> jax@well.UUCP (Jack J. Woehr) writes: > The key word in that sentence is "hear", Fraser. > > You haven't "heard" Forth. > Sorry, don't understand what you mean. > You are all wrapped up in that academic conceptualization > of conceptualizations about computing. ? I don't undersand what this means, but the implication is that nothing good or useful ever comes from acedemia, an implication that I'm not even going to bother to answer since it is so ridiculous. > Heck, I'll bet you say "instantiate" instead of "store" :-) No, No. I say "change in the run time state" :-> > Forth is a *rethinking* and *retooling* of the fundamental > constructs of serial computation. Maybe it is a little late > for that, standing as we are at the dawn of parallel, but better > late than never? > What on earth does this mean? > If individuals as intelligent as yourself would get down on > your knees and peer through the keyhole, you would see that > Forth is the assembly language of a more powerful model > of serial computing. > > But megabux are committed to the old way, so who cares? I agree totally, forth is the assembly code of a more powerful model of serial comunication. What I've been suggestion for the past few months is designing a compiler that can produce this machine code without loosing any of the power of the new model. Regards, === Fraser "Head in the clouds academic" Orr :^>
kopaz@garfield.RDL.COM (John 'Echo' Kopaz) (09/14/88)
In article <1609@crete.cs.glasgow.ac.uk>, orr@cs.glasgow.ac.uk (Fraser Orr) writes: > [...] > I agree totally, forth is the assembly code of a more powerful model > of serial comunication. What I've been suggestion for the past few > months is designing a compiler that can produce this machine code > without loosing any of the power of the new model. > > Regards, > === Fraser "Head in the clouds academic" Orr :^> (opinion alert) this proposed compiler does *NOT* preclude the use of forth as it is!!! i think fraser's idea is sound. with the advent of forth chips, the ability to compile a 'high level language' into forth (or something like it) will be needed. this is not a trivial problem though... as many of you stated there are as many run time environments as there are problems!!! this compiler would create its own r.t.e. based on the h.l.l. that it implements and any volumes from the library it checks out. (:`] (couldn't resist..) this should be viewed as a boon to forth, not as an attack!! forth *IS* the assembly of code of a *MUCH* more powerful model of communication (serial and otherwise...)!!! i think we should exploit it to its fullest extent. -- john a. kopaz | group head, simulators | ...after six, it's just syntax... research scientist by association | voice: 213-410-1244 -- fax: 213-216-5940 -- corporeal: rdl arpa : kopaz@rdlvax.rdl.com 5721 w. slauson ave. uucp : ...!{psivax,csun,sdcrdcf,ttidca}!rdlvax!kopaz culver city, ca 90320