Re: RPN, RPL and BASIC [LONG] Message #7 Posted by Valentin Albillo on 30 Sept 2004, 12:33 p.m., in response to message #6 by Vincent Weber
Hi, Vincent:
I really think your interesting post deserves a thorough answer. No flames, of course, but some points need to be made, I'll write my remarks interspersed with your original post:
"The commun opinion is that RPN is simple, pure, and requires less keystrokes, while RPL would a bulky, intimidating, overkill and clumsly full-blown object-oriented language, a la C++. Valentin, for instance (Hi Valentin :-) ), advocates the
small-size 15C for daily computations, and the Sharp BASIC computers (or the 71B) for more complex programming, while hinting that RPL is not
appealing..."
(Hi Vincent :-) Yes, you absolutely nailed my current opinion on the subject, and may I say you've probably nailed the "common opinion" as well.
"it could be argued that <PGM> 'LBL PROG, ..., RTN' <PGM> on a 41 takes even more keystrokes than <<...>> 'PROG' STO on the 28/48 ;)"
Well, not counting the name "PROG" (which is arbitrary and could equally well be "PROGRAMA" or "P"), you just can assign LBL and RTN to keys in the 41 and enter said code snippet in just 4 keypresses, namely [PRGM][LBL][RTN][PRGM].
Anyway I don't think this kind of example is very much relevant.
"Which of the following is more concise and/or intuitive for newcommers to programming:
- 41: 'RCL 00,1000,/,1.00001 +, STO 01, LBL 00, ..., ISZ 01, GTO 00'
or:
- 28/48: '1 A FOR I ... NEXT' ?"
Well, actually the 41C loop would begin
RCL 00, E3, /, 1, +, STO 01,
i.e, you need only two keypresses (E3) instead of four to enter the constant '1000', plus you need just one keypress (1) to enter the initial value and increment value for the variable, instead of seven (1.00001). Also, depending on the loop's contents, you might well be able to use a stack register for the counter (LASTX, for instance) and avoid the STO 01 altogether. As I once said, and please take no offence as none is meant, this is a typical example of someone writing code in some program language ineptly, then pointing to the defficiencies in the code he just wrote as being inherent in the language.
This is not the exact case here, but close.
Also, your RPL code ('1 A FOR I ... NEXT' ) looks far too weird and twisted compared to the natural HP-71B's
FOR I=1 TO A ... NEXT I
"for variable i equals one to value of A" seems far more sensible than "one value of A for variable i", don't you think ? Also, why is it "1 A FOR I" ? Wouldn't it be more consistent with RPL to have instead "1 A I FOR" or some similar permutation, with the "FOR" being last ?
"Doing a IF-THEN-ELSE alternative with GTOs is quite tricky and inelegant in RPN. Something like:
'X>0?,GTO 01, GTO 02, LBL 03,...,LBL 01,...,GTO 03, LBL 02,..., GTO 03'.
To be compared with:
'IF X 0 > THEN... ELSE...END'."
First, if you've got several actions to perform depending on a comparison, or else two very different set of actions, much cleaner code would be:
X>0 ? LBL "DOTHIS" LBL "DOTHAT"
GTO "DOTHIS" ... ...
X<0 ? ... ...
GTO "DOTHAT" GTO "GO-ON" GTO "GO-ON"
LBL "GO-ON"
...
I think this is pretty clean and easily understandable. Even cleaner would be to use a flag to record the test result, then use XEQ instead of GTO, thus avoiding the LBL "GO-ON" and in fact all four GTO's altogether.
Again, your RPL "IF X 0 > THEN... ELSE...END'." looks unnnatural and contrived when compared to HP-71B's:
IF X>0 THEN ... ELSE ...
If in doubt, just read loud and clear both statements as they're written.
"it is still quite possible to emulate registers on the 28/48, and corresponding STO/RCL functions, with an
array [...] The ability to use local variables is a HUGE plus of RPL - especially with recursive altgorithms."
By the same token, the RPN calculator named HP42S can have both numbered registers AND named variables and you're free to use the ones that best suit your problem. Which is more, you can handle all numbered registers en masse as a named variable (REGS), which allows you to keep several distinct copies at any given time, thus easily achieving a powerful kind of 'local variables' mechanism.
Also, in the HP-71B you've got scalar and array variables, of numeric and string types, and in several precisions, including INTEGER, REAL, SHORT, COMPLEX, and COMPLEX SHORT,
easy to use as pie, not to mention fully recursive subprograms and user-defined functions with explicit parameter passing by both value and reference. Try that with a stack-based machine, where you are frequently at a total loss about the required stack contents before calling a routine and the resulting stack contents at termination, even if it can terminate several ways, some of them abnormal and/or unforeseen.
I miss the lack of replication of the 'T' register; I also hate it to have to 'DUP' every argument to
be re-used, since RPL fanatically removes arguments from the stack systematically."
Not to mention the fact that the stack might get empty and thus give you a nice error message as you simply press the [+] key. Agreed, it is an error trying to add two values that aren't there, but all the same the very fact that the stack can hold less than four entries down to no entry at all gets very easily on the nerves of anyone who's grown fond of the comfy 4-levels-at-all-times-no-matter-what RPN stack.
The fact that an RPN stack had 4 levels was one of the accepted facts of life to HP lovers, just as death, taxes, etc. You don't remove such "facts" without nasty consequences.
"never have
to worry about loosing the older results and store then into registers back and forth..."
Seasoned 4-level RPN stack uses *never* lose older results in the stack, is something automatic. It's just like never falling from your bed when you're asleep, no matter how much your roll left and right. You don't consciously think about it, it just never happens by sheer acquired reflexes. Same with "losing items" from the four level stack. After a while you just don't.
"And being able to see 4 objects at a glance, and scroll the view
for the rest, is extremely handy."
In such a small screen, I find it actually somewhat confusing, distracting. I'd rather have a look at the result I want as the single item on the display, than be forced to also see previous results or unneeded garbage left out in the upper levels by previous, not-relevant-now calculations.
It is a well-known fact that RPL users find themselves clearing the stack at all times, to remove unneeded leftovers, while a veteran RPN user needs to clear the 4-level stack next to never. Anyway, that's just my own, personal feeling on the matter.
"Next to
the 28/48, this only satisfactory calculators in that sense are the 18C/19B/19BII familty (even though inserting characters is clumsy...)"
I think you forgot to mention the HP-71B here, unless you're restricting your comparisons to Goliath vs. David, i.e., mighty RPL vs. humble RPN. If Titans are allowed to enter the fray, HP-71B direct evaluation of algebraic expressions and further, its CALC mode, are a worthy opponent, don't you think ?
"I think it is not a coincidence if BASIC computers more or less disappeared when RPL came."
You must be joking here, no doubt. Do you really think RPL was noticed at all by much of the handheld computing community when it appeared ? Think again ... There's been hundreds of BASIC handhelds sold by the likes of CASIO, SHARP, etc, for each and every RPL machine sold by HP.
"Manipulation of Matrixes,
Lists, even dynamic creation of programs, is extremely concise and elegant in RPL, while it requires calls to external functions in BASIC."
In HP-71B's BASIC:
MAT A=SYS(B,C) 'solve M systems of N equations, real or complex, at once
MAT A=FOUR(B) 'compute the Fourier/Inverse Fourier transform
MAT A=TRN(B)*C 'matrix-multiply the transpose of B by C
MAT A=PROOT(B) 'find all real/complex roots of polynomial B
Are these examples inelegant to you ? And as for 'external', I've told a number of times why the Matrix ROM (ROM 2) was taken apart from mainframe ROMs (ROM 0 and 1) after being there for a number of reasons. It was an integral part of the machine in the original design, not an external ROM, and as far as I'm concerned, it still is.
"My conclusion is: RPN is great. RPL -does- have drawbacks compared to RPN, but often simple programs can be done simpler in RPL than in
RPN - while complex programs can often be made more elegantly in RPL than in BASIC. This makes RPL a very serious candidate for the best
programming method on a handled machine."
That's your conclusion and that's your opinion, which I beg to difer. Each machine and each language is better suited for some tasks than it is for others, and while RPL has its merits it also has horrible faults that most definitely make it unsuitable for many a purpose and for many a person.
I think this was really a case of HP disregarding the old but essential American proverb: "If it ain't broke, don't fix it !". I don't think RPN was broken, at all. The HP42S is a living, breathing example of what HP could have done with RPN: expand it while preserving its very soul. HP42S' RPN is awesome, what with its powerful types such as matrices and complex numbers perfectly integrated in the whole RPN paradigm, its named variables alongside numbered registers, its menu system.
I'm sure I'm not alone if I say that people would've given an arm and a leg for a 42SX, with furtherly enhanced classic RPN, plus full I/O and a faster CPU, preferring it over most any RPL model. RPN wasn't broken. But HP did try to fix it, regardless. And RPL was the result, deeply unsatisfying for many.
As for me, my stand is well known. I use an HP-15C for everyday normal chores, an HP-71B in emulated form for really complex math-related computations, and a SHARP PC-1360 when a lot of data and results are needed and thus a large, perfectly readable screen, QWERTY keyboard, plus computing muscle are a must. For instance, for the equivalent of filling up IRS forms: having your data in sensibly named array variables and being able to see lots of info on the screen, while comfortably resting in your bubble bath is awesome. :-)
Long live to most any HP calculators and a lot of SHARP's.
Best regards from V.
|