orr@cs.glasgow.ac.uk (Fraser Orr) (08/29/88)
In article <4057@juniper.uucp> olorin@juniper.UUCP (David Weinstein) writes: >In article <1581@crete.cs.glasgow.ac.uk> orr@cs.glasgow.ac.uk (Fraser Orr) writes: >[...] >>never done such programming in forth. What I am absolutely certain of >>though, is that if you used a preprocessor that allowed infix, procedures >>with parameter lists, type checking, and all the other things that the >>rest of the Comp Sco world has agreed to be benificial, then the job would >>be much easier. > >NO, it would not. It is possible to write awful code for any language (ever >*looked* at the Unix source?). Long ago in this discussion we agreed on this point, that any language can be used badly. >But even the best written C still looks, well, sloppy. I'm sure you just forgot to say that this statment was unsubstantiated opinion:-] Anyway, I don't seem to have got my point accross to you. I'm not talking about what the programmer contributes to getting the program right (i.e., writting good code), but what the compiler can contribute to getting the program right (taking a syntax that has as obvious as possible a meaning, using redundancy - type info - to check for program consistency etc) >Forth lets you (but does not force you to) write very high level >code, which will converge to RPN english (noun verb format). Writing in this on Come language English the RPN use does not , ! (That is "Come on, the English language does not use RPN!" in RPN :^) Anyway the striving to get a programming language that is like English is ridiculous. Who wants to have to explain how a program works is English? It is wooly, ambiguous, unnecessarily wordy, and there is probably no chance that anyone will ever be able to write a parser for it. To quote an example from the european jokes group, compare "Time files like the wind" and "Fruit flies like bananas"! Computer programming languages are concise and to the point. It takes a good programmer a week or so to learn a new language to a reasonable extent and most programmers can get the gist of most well written programs written in most languages (forth excluded) even if they don't know the language. >style takes a bit more effort, but with proper factoring, and keeping most of >the Forth "noise" words down at a lower level, the resulting code is quite >readable, and does not suffer (at least at the top level), from "flip flop >swap drop" fever (although these "noise words are used at lower levels). >It is impossible to work to that high a level in languages like C, because the >language format is inflexible, and you cannot abstract out the ()s or other >pieces of syntactical noise from your code. All programs, almost regardless of language, at the higher levels of the program degenerate into a series of procedure calls (or whatever the language happens to call these), so to proudly boast that forth does this also is not very interesting. One problem that forth has at these levels is the much discussed parameter problem. i.e., the fact that in languages like C, pascal (and most others) the parameters are explicitly listed after the name, so you can see clearly what uses what (with the proviso of the interesting discussion we had on implicit parameter passing). In Forth you either use the RPN notation in which case the procedure calls get mixed up with the parameters, or you use the implicit parameter passing mechanisms in forth, which as I have said before, I don't like, because it is harder to follow what is going on. As for inflexibility, as I mentioned a long time ago, flexibility is NOT necessarily an asset. Particularly when you are working in a team. Why? because "if there are n equaly good ways to acheive some goal, and m not so good ways, and p programmers on you team, then the p programmers will prefer (n+m)/p (n m + p /) different ways to attain the goal." (Orr's first law of Programming teams, corr. to Murphy's general laws) So by limiting the programmers options to a small set of good ways, we are more likely to get a consistent style accross all the programs. (This by the way is why C programs are generally so appauling, because there is a great deal of flexibility in the language - see Kernighan and Ritchie's book, in which an clear string copy program is transformed into a morras of symbols for "efficiency's sake"! It is also why the goto is not good, it is simply too powerful an operation.) > >As to the great infix/postfix/prefix/fix-the-fight controversy: > >RPN is not hard to learn, and quickly becomes intuitive. As to the assertion >that programmers don't learn it, how many are using HP Calculators? How many >non-programmers use adding-machines? > I work in RPN a lot. I would say I have as much of an "intuitive feel" for it as the average run of the mill forth programmer. I still hate it though, and still have to draw diagrams all the time to keep track of the stack (because in real programming you can't limit yourself to 3 deep stacks) Just because RPN can be understood, doesn't mean to say it is the best. As to HP calculators, I know noone who has one, I almost bought one but was put off by the RPN. Perhaps things are different in the US though. Regards, ===Fraser Orr (orr%cs.glasgow.ac.uk@nss.ucl.ac.uk)
orr@cs.glasgow.ac.uk (Fraser Orr) (08/29/88)
In article <248@c10sd3.StPaul.NCR.COM> anderson@c10sd3.StPaul.NCR.COM (Joel Anderson) writes: >source. Too long have I used the system without using its full potential. Too long have I used systems that are difficult and akward to use. Most compilers for these sorts of systems come with an interface to the graphics sound etc, so this leaves the question of what makes them most accessible to the programmer. And that is what we've spent the last few months discussing. >I can do scads of very, very useful things with this system. Yes, and i can do scads of useful things with my pocket calculator, doesn't mean it is the best way to do it though. >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). Yes, and for a few dollars more, or a few weeks effort more, you could build a preprocesor that would give you all these wonderful things (which I deleted for brevity) and you could do it in a pleasant programming environment. Do you see my point? Regards, ===Fraser Orr (orr%cs.glasgow.ac.uk@nss.ucl.ac.uk)
hjm@cernvax.UUCP (Hubert Matthews) (08/31/88)
English doesn't use much in the way of RPN, but take a look at German grammar. The primary verb comes as the second idea in a sentence and any auxiliary verb comes at the end. In a subordinate clause, both the primary and the auxiliary verbs come at the end. Just to show that RPN isn't that strange a concept.... Hubert Matthews
anderson@c10sd3.StPaul.NCR.COM (Joel Anderson) (09/01/88)
In article <1588@crete.cs.glasgow.ac.uk> orr@cs.glasgow.ac.uk (Fraser Orr) responds to my praise of a CBM 64 Forth where I remarked on the fact that >> Too long have I used the system without using its full potential. In response Fraser makes the odd remark - >Too long have I used systems that are difficult and akward to use. This has nothing to do with my statement. All I was pointing out was that I had a professional quality implementation of Forth, that I used it for a terminal program, and that it actually could do all kinds of very nice things (graphics, sound and such). I didn't say the system was awkward (it isn't). And, if you have the taste for it (no Fraser doesn't apparently), Forth isn't awkward either. Again a non sequitur - >Yes, and i can do scads of useful things with my pocket calculator, doesn't >mean it is the best way to do it though. I was talking about a low cost computer with a useful Forth implementation what did that have to do with the things Fraser does with calculators? >>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). > >Yes, and for a few dollars more, or a few weeks effort more, you could >build a preprocesor that would give you all these wonderful things >(which I deleted for brevity) and you could do it in a pleasant programming >environment. Ahem - again in my original post, I forwarded the remarkable notion that a Forth system is an 'appropriate technology' solution. Those of us whose personal budget (or priorities), limit our computing money may like the incremental approach Forth affords. And I think the preprocessor idea, how ever useful that may be in some settings is a far overblown notion on a C64. I already have a C compiler if I want to tangle in the edit-compile-test-edit-compile-test-edit-compile-test-edit-compile-test- edit-compile-test-edit-compile-test- cycle. What <I> want and what I get in Forth is a nice, neat, fast (cheap) development system. I think this has gone far enough. Lets keep up the quantity of the postings but drop this silly Forth bashing. If you don't like Forth, Fraser, fine. You are entitled to your opinions, however stupid. If this keeps up we are going to devolve into name-calling and personal abuse. >Do you see my point? >===Fraser Orr (orr%cs.glasgow.ac.uk@nss.ucl.ac.uk) Yes, but if you part your hair ... oops - see what I mean..... On a serious level - I saw a note about a Forth neural net simulator in Dr.Dobbs - can anyone else tell me about this? ------------------------------------------------------------------------- "..If you own a machine, you are in turn owned by it, and spend your time serving it...." The Forbidden Tower, Marion Zimmer Bradley ------------------------------------------------------------------------- anderson@c10sd3.StPaul.NCR.COM |UUCP: {rosevax, crash}!orbit!pnet51!jpa Joel Peter Anderson |ARPA: crash!orbit!pnet51!jpa@nosc.mil NCR Comten / Software engineer |INET: jpa@pnet51.cts.com -------------------------------------------------------------------------