Calculator as a tool

[cyrille de brébisson]

Hello,

"I was interested in your original assertion about ppl v rpl"

First, let me setup the frame from which I will speak here.

I have done a LOT of RPL and Sys-RPL programming. I have had great fun doing it. I have created very large programs using these languages. I have also created my own PC version of RPL (never really finished it, sorry)...
I am saying that to convince you that I do not have any anti RPL bias here.

In comparison, I have not done a lot of PPL programming (actually I have done very little! Others such as Han are probably much more PPL experts that I am!). But I have done a lot of programming in similar structured, algebraic languages. I have also created PPL, but I do not feel that I have any strong attachment to it, hence I do not feel any positive bias here either.


So, here comes the arguments.
RPL is definitely much simpler to implement. in the HP48 series, the RPL evaluator is really 3 ASM instructions placed at the end of each RPL instruction. A=DAT0(A) D0=D0+5 PC=(A)
Hard to do any simper. Coupled with the object prolog trick, it is a thing of beauty!
The compiler is barely more complex. There is a handful of objects to recognize and you are done.
RPL is in theory, efficient. As it turns out it is not that efficient, especially on the 48 series due to the fact that it is memory intensive and that the 48 is slow on memory accesses.
You can, as a programmer, get efficiency from a RPL program by using the stack for temporary calculations which are reused. But, this does not happen that often in real life.
RPL is also (in theory, the reality depends on the implementation, the 48 did not really have that property unless you stuffed a library at a fixed address in port1/2) user extendable.

Anyhow, where RPL does fail is in readability. I tend to say that RPL is a write only programing language. This means that you end up having smaller, simpler sub-programs that perform one simple calculation, else you loose the ability to look at your program "from afar" to understand what it does.
Getting back to a program after a month or 2 is much much harder than if you were to do it with a PPL program. The lack of comments is also a killer there.

What I do like about RPL (apart from it's genious implementation on the 48) is the amount of tricks and "funny business" that you can do with it. It makes programming in the language fun. But this is not what is expected form a programming language from a "professional" standpoint. You want a programming language which is fast to program in with high quality, easy to re-read/modify, and can scale well.
These are not RPL qualities.

On the other hand, PPL does have a lot of these qualities.
Easy to read, much less funny business, much more readable at a higher level (because of the algebraic nature and the use of named local variables, vs unnamed, ever changing stack levels). PPL although an interpreted language could be compiled in the future to gain speed and allow local optimizations, so it scales much better.

This means that doing a very short program in PPL is not as easy/simple as doing it in RPL (and let us face it, RPL was designed originally to allow short key sequences to be automatized), but once the program gets a little big bigger, more complicated, then PPL wins easily.
There is one thing that RPL does have and that is truly missing from PPL, and it is the ability to work with symbolic objects. However, this stems mostly from the fact that the 48 is a symbolic machine while Prime is not (unless in CAS).

However, the PPL compiler and interpreter is much much more complex than the RPL one and was much more work.

I have purposefully ignored here differences that stems from the differences in the hosting calculator and which are not attributed to the language. This includes directories for example. The fact that Prime is intrinsically more restrictive than the 48 does trickle to the language.

So, here you go, here are my arguments (at a high level at least). I hope that it clarifies my position on the subject.

Regards,
Cyrille