orr@cs.glasgow.ac.uk (Fraser Orr) (09/23/88)
In article <810002@hpmtlx.HP.COM> adam@hpmtlx.HP.COM ($Adam Kao) writes: >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. No, I would say that no matter what language is a serious barrier. If I learn to speak French, it will still be a problem, because I will speak french badly and inefficiently to a Frenchman. Now if he learns English, then he will be equally inefficient in communicating with me. So then with computers language is also going to be a barrier. The question is who should put in the effort learning the new language? The Frenchman of course! :-> >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. I find it hard to believe that you feel isolated from the hardware when programming in C. It is important to be able to communicate with the raw machine from a programming language, but I believe that this can be done effectively by hiding the machine behind a pretty model. TO put it another way, you don't have to sacrifice every benefit of HLLs to get FULL access to the machine. Now as to Forth having all the advantages of an HLL, what ones were you refering to? >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. This sort of thing is useful for hardware control certainly, but not for data control. Give me a symbolic debugger any day.:^> >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. Thank you for the advice, can I add a few texts to the comp.lang.forth reading list Say for example, the C reference manual, the Miranda reference manual, Software Engineering a practitioners approach etc (please read all before you are knowledgeable enough to contribute...;^) >Adam Best Regards, ===Fraser
mdg@smegma.UUCP (Marc de Groot) (10/02/88)
In article <810002@hpmtlx.HP.COM> adam@hpmtlx.HP.COM ($Adam Kao) writes: >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. WHOA! Hold on thar a *minute*. I write debuggers in Forth for fun -- and for a living too. Forth is the easiest language to write debuggers for -- bar none! LISP comes close, but doesn't make it. Having a simple, regular structure for executable objects in Forth gives it a unique ability to refer to itself. Moreover, single-steppers can be thrown together trivially. C simply does not lend itself well to interpretation or single-stepping. SDB is a good try, but does not allow control of the execution within a single line of source. It has other problems as well, which are implementation problems (bugs) rather than design problems. Unlike Forth, C has a "rich" syntax which makes it more difficult to write interpreters for. The language was created with traditional compiler concepts in mind, and is poorly suited for other approches. -- Marc de Groot (KG6KF) UUCP: uunet!hoptoad!smegma!mdg Internet:mdg@smegma.UUCP "The pathology is to want control, not that you ever get it, because of course you never do." - Gregory Bateson