Prime and 50g, interesting perspective

[OlidaBel]

"The HP Prime from a developer’s perspective"

https://www.disometric.com/blog/the-hp-p...ve-part-i/
https://www.disometric.com/blog/the-hp-p...e-part-ii/
(Aug-2020)

extract from part 2 :
"On the other hand, RPL is nice for short programs. But when your code grows in complexity, it quickly becomes almost unreadable and very difficult to follow, especially when you go back to it a few months later. I recently wrote a medium-sized program for the Prime, about 2.000 lines of code, and I’m pretty sure that if I had tried to code it in RPL, it would have been a nightmare.

The fact is, I don’t use RPN anymore. And the most interesting thing is… I don’t miss it one bit. I think the HP Prime shows its true potential when used as an algebraic calculator. So, if you are a long-time RPN user like me, just give the Algebraic mode a chance. Maybe you’ll be pleasantly surprised."

[toml_12953]

(08-30-2021 10:17 AM)OlidaBel Wrote:  "The HP Prime from a developer’s perspective"

https://www.disometric.com/blog/the-hp-p...ve-part-i/
https://www.disometric.com/blog/the-hp-p...e-part-ii/
(Aug-2020)

extract from part 2 :
"On the other hand, RPL is nice for short programs. But when your code grows in complexity, it quickly becomes almost unreadable and very difficult to follow, especially when you go back to it a few months later. I recently wrote a medium-sized program for the Prime, about 2.000 lines of code, and I’m pretty sure that if I had tried to code it in RPL, it would have been a nightmare.

The fact is, I don’t use RPN anymore. And the most interesting thing is… I don’t miss it one bit. I think the HP Prime shows its true potential when used as an algebraic calculator. So, if you are a long-time RPN user like me, just give the Algebraic mode a chance. Maybe you’ll be pleasantly surprised."

My thoughts exactly. For me, RPL is a write-only language. I can write programs using it but have a hard time figuring out what I did months later. On Prime, HPPL is so much like Pascal or Lua that it's almost self-documenting. The newest OS also has Python which is pretty standard. The speed and ease of use makes Prime my choice. My 50g sits unused for months at a time.

[Garth Wilson]

(08-30-2021 10:59 AM)toml_12953 Wrote:  For me, RPL is a write-only language.

I haven't used RPL, but it looks a lot like Forth to me. We get the same comment about Forth; but I blame that on the programmer, not the language.

[John Keith]

(08-30-2021 09:29 PM)Garth Wilson Wrote:  I haven't used RPL, but it looks a lot like Forth to me.

Indeed, since RPL was based on Forth and Lisp, and both Forth and the classic HP calculators are based on RPN. It's hard to determine which came first, Forth or HP calculators, as both first appeared around 1968.

Personally, I greatly prefer RPL to PPL but I do like Python which makes me happier with the Prime.

[carey]

(08-30-2021 10:17 AM)OlidaBel Wrote:  https://www.disometric.com/blog/the-hp-p...ve-part-ii
extract from part 2:

"I recently wrote a medium-sized program for the Prime, about 2,000 lines of code, and I’m pretty sure that if I had tried to code it in RPL, it would have been a nightmare."

Yes, all 20 lines of it!

[OlidaBel]

(08-31-2021 08:15 AM)carey Wrote:  

(08-30-2021 10:17 AM)OlidaBel Wrote:  "I recently wrote a medium-sized program for the Prime, about 2,000 lines of code, and I’m pretty sure that if I had tried to code it in RPL, it would have been a nightmare."

Yes, all 20 lines of it!

RPL would be easier to read if it could benefit of comment lines and an modern editor.
About the 20 lines, proves it please ;-)

Everything could be possible, have a look : the DM15L (HP-15c copy) is also complicated to maintain, more than a RPL calculator, as running pure RPN instructions without text.
But it's enhanced with the simulator environment of https://hp-15c.homepage.t-online.de/content_web.htm giving access to :
- program documentation
- variables description
- clear instructions, step by step.

[John Keith]

(08-31-2021 08:30 AM)OlidaBel Wrote:  RPL would be easier to read if it could benefit of comment lines and an modern editor.

RPL allows comments followed by the @ symbol. They are not visible on the calculator but are useful in human-readable source files.

There are plug-ins for Notepad++ for RPL and PPL so you can use modern editors if you like.

I don't think I have ever written an RPL program longer than 20 lines, never mind 2000! RPL is by nature more compact than Algol-type languages because each "word" or operation in a stack-based language is approximately equivalent to a line in a traditional language. I think the ratio is closer to 5 than 100 though. If you really value terseness, try APL or J where each operation is a single character.

[OlidaBel]

(08-31-2021 11:33 AM)John Keith Wrote:  RPL allows comments followed by the @ symbol. They are not visible on the calculator but are useful in human-readable source files.

There are plug-ins for Notepad++ for RPL and PPL so you can use modern editors if you like.

I know the @ is not visible by the RPL, but it does not help me I think. I code all my RPL directly on the calculator. I remember copying a source file with the SD card between the 50g and the Mac, the text was modified , hence not really practical.
What's the right way to transfer source files then ?

(08-31-2021 11:33 AM)John Keith Wrote:  I don't think I have ever written an RPL program longer than 20 lines, never mind 2000! RPL is by nature more compact than Algol-type languages because each "word" or operation in a stack-based language is approximately equivalent to a line in a traditional language. I think the ratio is closer to 5 than 100 though. If you really value terseness, try APL or J where each operation is a single character.

Indeed, RPL compact programs are easier to maintain, I prefer also to cut the problem into small pieces.
APL : sadism ? ;-)

[John Keith]

(08-31-2021 11:58 AM)OlidaBel Wrote:  What's the right way to transfer source files then ?

One way is to use the program INOUT from this post. It will turn a program on the 50g into a text file with trigraphs (e.g. \->) and vice versa.

On a PC using the Connectivity Kit you can drag programs from your computer to the 50g or save the programs on the computer. I don't know if there is an equivalent for the Mac.

[Claudio L.]

(08-31-2021 11:33 AM)John Keith Wrote:  RPL allows comments followed by the @ symbol. They are not visible on the calculator but are useful in human-readable source files.

There are plug-ins for Notepad++ for RPL and PPL so you can use modern editors if you like.

Also don't forget newRPL has persistent comments using @@ instead of @, those will stay with the program and will be visible on the calculator, so at least some incarnations of RPL do have persistent comments and can be programmed in-calc.

[3298]

In my opinion, calling RPL a write-only language is plain wrong, and here's why:

In C, Java, Lua, and all those "good" languages you're writing well-commented and formatted code, most likely with an emphasis on making it readable.
Many RPL programs are instead highly optimized for speed or size (or even both). In addition, they're often stored and exchanged in binary format, meaning that the source you see comes from a decompiler - no comments for you, and the formatting is what the decompiler thinks is appropriate.
You're therefore comparing apples to oranges. Don't do that; take an RPL program stored in source form (i.e. as string - you can use OBJ\-> on it to call the compiler manually) with proper comments and formatting.

Let me illustrate with a C function. Have the spaghetti variant first:

Code:

void quat_mul(const double *q1, const double *q2, double *d) { d[0]=q1[0]*q2[0]-q1[1]*q2[1]-q1[2]*q2[2]-q1[3]*q2[3]; d[1]=q1[0]*q2[1]+q1[1]*q2[0]+q1[2]*q2[3]-q1[3]*q2[2]; d[2]=q1[0]*q2[2]-q1[1]*q2[3]+q1[2]*q2[0]+q1[3]*q2[1]; d[3]=q1[0]*q2[3]+q1[1]*q2[2]-q1[2]*q2[1]+q1[3]*q2[0]; }

That doesn't look very readable, does it? And I assure you, no seasoned C programmer would use this for anything other than a code-golf or obfuscated C programming contest. How about this instead?

Code:

/**
 * Multiply two quaternions (Hamilton product)
 * Quaternions are represented by an array of four doubles,
 * with the real part at index 0 and the imaginary part at indices 1 to 3.
 * Quaternion multiplication is non-commutative.
 * @param q1 The first of the quaternions to be multiplied
 * @param q2 The second of the quaternions to be multiplied
 * @param dest The quaternion in which the result shall be stored
 * @warning This implementation assumes that dest is not the same as q1 or q2
 **/
void quat_mul(const double *q1, const double *q2, const double *dest) {
    // the real part of the Hamilton product is the product of the real parts of both factors,
    // minus the dot product of the imaginary parts
    dest[0] = q1[0] * q2[0]
        - (q1[1] * q2[1] + q1[2] * q2[2] + q1[3] * q2[3]);
    // the imaginary part of the Hamilton product is the sum of:
    // - the imaginary part of each quaternion scaled by the real part of the opposite one
    // - the cross product of the imaginary parts (this is the non-commutative portion)
    dest[1] = q1[0] * q2[1]
        + q1[1] * q2[0]
        + q1[2] * q2[3] - q1[3] * q2[2];
    dest[2] = q1[0] * q2[2]
        + q1[2] * q2[0]
        + q1[3] * q2[1] - q1[1] * q2[3];
    dest[3] = q1[0] * q2[3]
        + q1[3] * q2[0]
        + q1[1] * q2[2] - q1[2] * q2[1];
}

There, much better. And that's just formatting and comments along with some mathematically inconsequential reordering of operations, it remains as optimized as it was. It could be even nicer if one would refer to other helper functions for vector-scalar multiplication, vector addition, dot product, and cross product. (By the way, I just typed these examples out - don't rely on their correctness as they are not tested; the point I'm trying to make is about what the code looks like).

An RPL program that has gone through the compiler and decompiler got its formatting and comments stripped, so it looks about as readable as the one-liner. However, that is your fault and not the language's (at least not entirely). For the sake of your and others' sanity, keep a copy of the source around, format it well, and comment it. Perhaps also leave some optimization out, like using local variables instead of juggling everything on the stack; and while you're at it, give them meaningful names, not just single letters.
Seriously, do it.
And stop comparing code-golfed RPL to formatted other languages.

That said, there are certain traits of RPL that permit bad coding habits to form. The ease and ubiquity of decompilation lures you into accepting its considerable drawbacks, and the relatively low-powered RPL systems (the 50G isn't as bad as the 28C and 28S, but its memory and performance are still way behind what "modern" programming environments offer) nudge us toward optimization even when it's not necessary. However, we can choose to fight the temptation - and produce readable code as a result.

And yes, I'm guilty of having produced a lot of highly optimized, hard-to-read RPL code. It's just that this is not the only way to handle the language.

Finally, another pair of hints:
- If you're worried about the memory cost of keeping the source for your RPL programs around, remember the SD card. You may accumulate a few megabytes of commented source if you're a busy programmer, but I don't think you'll reach a gigabyte, and you probably have two of those sitting around in port 3.
- Since RPL's ancestor Forth was also mentioned, I'll refer to this hint from Leo Brodie's classical Forth introduction:

Quote:Some elements of good FORTH style include:
- [...]
- the use of many short definitions rather than a few longer ones,

This can be applied directly to RPL. That means producing a flood of smaller programs to solve small parts of your problem, and using them in more programs to solve incrementally larger parts, until you have one that can handle the entire problem. In addition to having the pieces available for use in related problems, you'll also make it easier to understand the whole solution by breaking it down into bite-sized pieces. For instance, if RPL didn't have DOT and CROSS already, you'd implement them first, then use them in a program calculating the Hamilton product.

[ijabbott]

(09-01-2021 11:08 PM)3298 Wrote:  - Since RPL's ancestor Forth was also mentioned, I'll refer to this hint from Leo Brodie's classical Forth introduction:

Quote:Some elements of good FORTH style include:
- [...]
- the use of many short definitions rather than a few longer ones,

This can be applied directly to RPL. That means producing a flood of smaller programs to solve small parts of your problem, and using them in more programs to solve incrementally larger parts, until you have one that can handle the entire problem. In addition to having the pieces available for use in related problems, you'll also make it easier to understand the whole solution by breaking it down into bite-sized pieces. For instance, if RPL didn't have DOT and CROSS already, you'd implement them first, then use them in a program calculating the Hamilton product.

Good practice, and its why the concatenative programming language 'Factor' gets its name.

However, I understand global symbol look-ups in RPL are rather slow? (No doubt newRPL would speed things up a lot.)

[3298]

(09-02-2021 05:18 PM)ijabbott Wrote:  However, I understand global symbol look-ups in RPL are rather slow? (No doubt newRPL would speed things up a lot.)

Hey, are you optimizing for speed again?
Some optimization may be needed because we don't want to wait for hours, but there is a point at which the gains in speed (or memory) are not worth the loss of readability. The pragmatic answer would be: test if an optimized version brings major gains, and if not, keep it readable instead. For this particular optimization, I would expect it to - in most cases - not make a worthwhile difference.

If you are still worried, you can make an effort to keep the number of global variables searched before finding a match low ... by using directories, because only the current directory and its direct and indirect parents are searched, subdirectories of any of these are not. Simply tell your program where to find its subroutine, and the global name search will find it without having to look at the whole collection.
As a bonus, you get to organize your programs in some way, which wouldn't be such a bad idea by itself, because it also helps others and future you understand the whole deal better by defining a meaningful structure.
Picking up the Hamilton product example once more, you might store it in a 'QuaternionMath' directory and thereby make it glaringly obvious to readers that it relates to quaternions, even if they are not familiar with the term "Hamilton product".

[David Hayden]

(09-01-2021 01:58 PM)Claudio L. Wrote:  Also don't forget newRPL has persistent comments using @@ instead of @, those will stay with the program and will be visible on the calculator, so at least some incarnations of RPL do have persistent comments and can be programmed in-calc.

I believe newRPL also has local variables with no runtime cost difference vs. stack variables. The stackrobatics of some RPN/RPL programs make them nearly unreadable. In their defense, they are usually written for speed and compactness, not readability.

Dave

[Claudio L.]

(09-03-2021 09:39 PM)David Hayden Wrote:  I believe newRPL also has local variables with no runtime cost difference vs. stack variables. The stackrobatics of some RPN/RPL programs make them nearly unreadable. In their defense, they are usually written for speed and compactness, not readability.

Dave

You are correct. If you store subroutines in local variables, you can call them by name in your code, but the compiler replaces them with GETLAM style instructions that do not need to search or scan anything.

I agree with 3298 and you, the shortcomings are normally attributed to the language but are actually a matter of organization and documentation effort from the programmer. No language is self-documenting. It takes hard work to make readable code.