RPL second impressions (HP 28)

[Valentin Albillo]

.
Hi, Pier:

(07-02-2018 03:41 PM)pier4r Wrote:  

(06-30-2018 11:35 PM)Valentin Albillo Wrote:  Just out of curiosity: what's the result you're eagerly waiting 5-6 days for ?

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!

Ah, I see ... thanks for quenching my curiosity in that regard.

Quote:

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.

Agreed.

Quote:

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).

Semi-agreed. BASIC can almost always be understood and I'm not referring to the algorithm being implemented (which can be difficult) but to the language itself.

Try this: take a BASIC program listing and, without understanding the algorithm or what it does, simply convert the lines to C, C++, C#, Java, Pascal, or whatever. You'll succeed with little trouble as long as you understand both sintaxes, even if you have little or no idea what the original program does or how it does it, you can do the conversion almost automatically, almost in blind fashion.

Now try the same with RPL: take an unfamiliar, non-trivial size RPL program and try to convert it to BASIC, Java, Pascal, C, ... I'll guess that you either won't succeed at all or it will take you an inordinate amount of work and you'll have to resort to actually run or "single-step" the program, review the stack contents all the time, create tons of "stack diagrams", etc, etc.

Quote: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.

Agreed and agreed.

Quote:

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.

RPN was the most elegant, efficient solution hands down for the times when programmable calculators were price-limited to just a few storage registers (think HP-25) and a few program steps (49, 100, 224, 448). As a programmer, you had to jump through loops as required in order to fit a 4th order Runge-Kutta differential equations solver in a calculator with no subroutines and only 49 program steps while leaving enough steps to program the differential equation itself.

It was also the case (though less so) for the HP-41C and HP42S but shortly after that calculators had more than enough RAM and ROM and CPU speed to implement more sophisticated languages which would take all that drudgery and complicated acrobatics out of the equation and let the programmers concentrate on the real problem at hand to be solved.

HP did that with HP-71B BASIC but a number of factors (price, HP politics, marketing, certain people's agendas ...) completely killed the machine and the approach so there was never a 72B or any other BASIC (or C, or Pascal, or ...) calculators and HP relapsed into aggravated cryptography while SHARP, CASIO, Tandy and many others stole the Programmable Pocket Computer from under HP's feet.

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

Agreed. That, removing garbage (CALC mode, etc), compilation and much better hardware would have been a dream machine. Actually, some SHARP PC models almost are.

Quote: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).

Of course, fully agreed. RPL is a no-contest versus any decent language. Fortunately (and unsurprisingly) only HP supported it (no one else would touch it with a 10-foot pole) but fortunately no more.

As always, thanks for your interesting, thoughtful comments, and best regards.
V.
.