Path: utzoo!attcan!uunet!convex!killer!ames!pasteur!ucbvax!decwrl!hplabs!hpl-opus!hpccc!hp-sde!hpfcdc!hpislx!hpmtlx!adam From: adam@hpmtlx.HP.COM ($Adam Kao) Newsgroups: comp.lang.forth Subject: Re: Re: Forth Pre-Compier Message-ID: <810002@hpmtlx.HP.COM> Date: 2 Sep 88 14:32:45 GMT References: <1593@crete.cs.glasgow.ac.uk> Organization: HP Manufacturing Test Division - Loveland, CO Lines: 82 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. :-) Adam