Calculator as a tool

[Claudio L.]

Very interesting topic!
Here are my thoughts on the weaknesses of RPL, in which I worked on for almost 4 years now:

(11-30-2016 07:54 AM)cyrille de brébisson Wrote:  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.

Very true, so I eliminated much of the memory movements for newRPL:
* Objects stored with STO are not copied, but a pointer in the directory points to the same object in TempOb memory. This eliminates a LOT of memory movement.
* Use of the MMU allows to grow stack, return stack, directories and tempob independently by adding virtual memory pages, never by moving entire regions of memory.

(11-30-2016 07:54 AM)cyrille de brébisson Wrote:  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.

Here I confess user libraries are yet to be implemented, but the core is ready with a similar library concept, but libraries are much more powerful than in the past:
* A library can define commands AND entirely new object types.
* The compiler interacts with the library to compile/decompile its own objects, with arbitrarily complex syntax defined by the library, not the compiler.
* All common operators are overloadable, so libraries that define new objects can also define all operations involving that object and combinations of that object and other object types.
This makes newRPL truly extensible, you don't need to change the core to add new objects and integrate them seamlessly into the system.

(11-30-2016 07:54 AM)cyrille de brébisson Wrote:  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.

Comments in newRPL are persistent unless the user sets a flag to remove them automatically. They can also be removed with a STRIPCOMMENTS command without the need to recompile the code.

(11-30-2016 07:54 AM)cyrille de brébisson Wrote:  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.

newRPL does what you mentioned above: Local variables were made as fast as using the stack, thanks to compiler optimizations (using PUTLAM/GETLAM style internal opcodes) and not copying the objects. So the user has the choice of declaring locals and using them instead of (or in addition to) the stack. It reduces stack shuffling, makes code much easier to understand with no speed penalty. On the down side, you need to convince coders to use local variables and change their 30-year old coding style, which may not be that easy.

(11-30-2016 07:54 AM)cyrille de brébisson Wrote:  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.

But those differences are crucial. If you take away the external functions and other features provided by the environment, the language itself is just a few flow control syntax rules, and many languages become almost trivially identical:

FUNC(a,b,c) vs. a b c FUNC
BEGIN ... END vs. << ... >>
IF ... THEN ... ELSE ... END vs. IF ... THEN ... ELSE ... END
etc.

We could argue that the stack is not part of the RPL language, but a feature provided by the environment. But it is so deeply integrated into the language that they become one. The stack gives RPL the "reversed polish" look and feel that makes it difficult to read, so we could say the stack is its main weakness (and its main strength at the same time). You could in theory create syntax rules to abstract the stack use and make it hidden from the user (Lua does this very well! until you want to extend it from C, then the stack hits you in the face). The algebraic mode of the 49/50g was a good attempt at this which did the trick for the most part.
The environment can also affect the language on the Prime, so it shouldn't be removed from the discussion. For example, using CAS("..."); statements negatively affects the readability of the PPL language, same as commands with identical names but case difference. Just see how many threads are in this forum of users getting confused by that alone.

The strength of RPL is not the language by itself, but the whole environment and how cohesive the stack+directories+RPL language feels. If we remove the environment from the discussion, then RPL is nothing but an ugly senseless sequence of tokens.
I agree PPL is a great language, for large programs it can show its superiority but when looking at the entire computing environment, the Prime feels like several distinct pieces glued together, and that reduces the shine of PPL quite a bit.