|Re: RPN or RPL|
Message #13 Posted by Valentin Albillo on 16 Feb 2006, 4:46 a.m.,
in response to message #1 by Joe Edwards
Though this isn't an answer to your exact question, let me quote a relevant post from 2001:
"And here's what I think about RPL versus RPN: All classic machines, such as the wonderful 15C, 41C and 42S, had a simple but powerful
and elegant RPN keystroke programming language, with an efficient 4-level-plus-LAST-X stack, which was easy to understand and
easy to visualize while programming. They also had some simple looping controls (decrement and increment), storage arithmetic and
indirection, and a fairly useful, uncomplicated filesystem.
Now, they've been 'replaced' by these new machines using RPL, which is kinda some "FORTH-with-dressing", which only transforms
the intuitive and simple RPN programming paradigm into something so arcane and complicated that matter of fact, a lot of people
desist from writing programs in that 'language' not to mention trying to understand them.
You need several yellow-pages-sized
'advanced' manuals just to try and grasp the basics and fundamentals of their programming style, the thousands of whimsical functions
and their complicated syntax and expected parameters, to the point where you can do almost nothing without such a manual or
hefty guide always at hand.
Tha sad truth is that the extremely simple, useful and elegant RPN paradigm has been 'improved' to utterly preposterous extremes.
The typical RPL program is a nearly unfathomable mess where you actually need paper (lots) and a pen plus the advanced manuals, just to
attempt to understand what it's going on. It's kinda some 'obfuscated C' contest, if you know what I mean.
Not to mention its efficiency, or lack of it. Where you could do wonders in RPN on a 41C in just 224 bytes, you'll find yourself using
more and more kilobytes for the simplest programs. So what ? After all, those RPL machines do have hundreds of Kbytes, even a
Mb or two, so who cares anymore for elegant, efficient programming ?
To summarize, RPL is RPN's "Peter's Principle" come true: It's RPN raised to its saddest level of incompetence. And like it or not,
there it will remain forever, no turning back."
There's also this other post on the subject:
"Back then we were waiting for the dream
HP calculator for everyone, kinda a super-HP42, i.e., full compatibility
with the 41C and all its peripherals, full I/O, large
screeen (>= 4 lines), menus, named variables plus
registers, matrix operations, complex math, much
better alpha capability, much faster, more RAM, the
Should that have happened, we all would've been in
paradise, and would still be there, 20 years later.
RPN would've had a natural expansion, users would have
had a natural grow path for their skills.
What did HP release instead ? The HP-28S ... and RPL,
thus creating a schism among loyal HP users that
still persists. But we HP lovers were a very tiny
minority among people using calculators at the time,
what with us having to defend and proselitize RPN,
and the *last* thing we needed was a schism among us,
much less something that literally required to throw
all our carefully developed programming skills and
start anew, back to square one. RPN was already too cryptic
for the average non-HP users, RPL made it absolutely
obfuscated for everyone. While you had a chance to
convince some people of RPN's value in normal use
and programming, no non-HP users would ever touch RPL
with a ten feet pole, or be convinced of its alleged advantages, and many
HP users of old thought along the same lines.
The result is, RPN never properly developed an
upgrade path, the 42S was dismayingly handicapped,
and we got extremely complex, very large, graphing
calculators that many of us neither needed nor wanted.
Effort, time, and money who could've been spent in
RPN were instead focused on the new models. A truly
golden opportunity for RPN was absolutely wasted
because someone at HP just happened to have other ideas in
mind, and practically *killed* RPN from then on."
I might add now a lot of things related to program
editing, traceability, debugging, inconsistent and
incoherent program structures, inefficiency, etc, etc. but it's no use,
Best regards from V.
Note: Edited for a typo
Edited: 16 Feb 2006, 5:39 a.m.