RPL second impressions (HP 28)

[pier4r]

(06-30-2018 11:35 PM)Valentin Albillo Wrote:  Good for you. Just out of curiosity: what's the result you're eagerly waiting 5-6 days for ? Would you indulge me and describe either the problem or the computation ? Thanks.

Nothing of particular interests (at least for other people). I am simulating the average end score in tournaments based on the Elo's formula. I will make an article once I get enough data. The problem is that it takes time!

It is very similar to this: http://pier4r.wikidot.com/pierworks:arti...formatcomp

Quote:The problem with RePeLent is that it's almost impossible to not write unfathomable "garbage" even if you're trying hard not to be cryptic, and in any case the moment you resort to stack juggling and stack acrobatics for the sake of efficiency you'll immediately plunge head on on cryptography.

Yes this yes. I admire many stackrobatics posted here but until I debug them by hand or on the 50g I cannot really understand what they do. So yes RPL can become a write only language if one doesn't pay care.

Quote:See ? you must picture a worst-case scenario (no named variables, long routines, no comments ...) to try and get "basic" to be "hard to follow" (nope!) while in even the best-case scenario RePeLent is nothing but impossibly hard to follow, to the point of needing to write down the stack after every step to understand what's where. Comparing both languages in this respect is utterly ridiculous.

Hmm I am not sure if I agree here. What I wanted to convey is the following. I am not saying that basic is less readable than RPL. Rather that I consider relatively long code unreadable in whatever language when: it is not explained why the code is in the way it is (so the code misses comments), or the variables are cryptic (1 or 2 letters variables).

Sure, I would repel RPL faster than basic, but ultimately I would avoid both and say "you know what? I write my own routine. I am not sure I can trust this one that is too cryptic for me".

Quote:So you're advocating sacrificing speed for readability, i.e., completely going against what the RPL paradigm posits. Stack juggling is virtually incompatible with "readability".

I advocate that since I realized that "speed" is also developer time and not only execution time. Unless it is a library used plenty of times, eveloper time is the largest part of the whole "solution time". It doesn't matter the language, although some languages are more readable than others until a certain code size.

Yes, RPL (at least the one in the 50g) is not designed for readability. I also believe that it is neither designed for long routines.

Nonetheless I find my approach good enough (until a certain time limit) so I continue to use it. I have 4 50g not for nothing.

Quote:
It's the programming language the one which should be working for me and releasing me of the low-level drudgery, not the other way around.

I agree, but I also see that RPN and RPL had to be squeezed in hw with limits, so they put some burden on the programmer. At least I had this idea until I discovered some years ago that the 71B's basic runs on a saturn chip too. Go figure.

I would have preferred the 71B basic too, with a couple of extension (long variable names & co).

Anyway I have to use the prime more, there a lot of problems disappear. HP PPL is a nice language (with limits, but better than RPL in my opinion).