Path: utzoo!attcan!uunet!mcvax!ukc!strath-cs!glasgow!orr
From: orr@cs.glasgow.ac.uk (Fraser Orr)
Newsgroups: comp.lang.forth
Subject: RPN, Fights for its life (was Re: Infix operators)
Keywords: Parallel, controllers
Message-ID: <1585@crete.cs.glasgow.ac.uk>
Date: 29 Aug 88 13:07:39 GMT
References: <8808121826.AA23206@jade.berkeley.edu> <1575@crete.cs.glasgow.ac.uk> <6882@well.UUCP> <1581@crete.cs.glasgow.ac.uk> <4057@juniper.uucp>
Reply-To: orr@cs.glasgow.ac.uk (Fraser Orr)
Organization: Comp Sci, Glasgow Univ, Scotland
Lines: 97

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)