Calculator as a tool

[Santi]

I use the calculator at work everyday (merchant ship officer), so for me it's just another tool (and perhaps one of the most important ones). I've been using HP calcs since early 2000's, first a second hand 48SX, then 49G+, and until now a 50G. I also keep a 35S as a backup calculator (and I really love it)
The 50G keys are starting to break apart now (it's one of the first ones), so I decided to give the Prime an opportunity. And I don't like it at all.
The need to press the softkeys on the touchscreen feels just awkward. Then I'm used to have a quick access to my programs using CST on my previous calcs, and it feels silly to me that it haven't implemented. The programming language it's nice and powerful, but maybe to much for a calculator. I like the RPL and keystroke like logic. So I find the Prime to be maybe a nice learning aid for the college, uni, etc... but not a professional tool as the previous calcs used to be.
On the pros side of things, I really like the looks, the plastic cover and the feel of the keys, but I don't feel its a real substitute for the 48-49-50 line...
What do you think about this? Maybe I haven't tried hard enough?

[cyrille de brébisson]

Hello,

The move from physical to virtual keys is indeed a change, and not everyone is comfortable with it. I personally prefers to have tactile feedback... It is the direction of progress... Youngsters (Defined by anyone at least 5 year younger than oneself) seems to be very use to it and have no issues with it. They find KEYS awkward!!

The programming language is indeed a great improvement over RPL (I imagine that this statement will attract the ire of a few!). Having programmed a LOT in RPL, I however feels correct in this statement.

Prime is not as "finished" as the 50g series (remember, Prime is a 3~4 year old product, the 50g is the end of 20 years of evolution). I have no doubt that, given some more time, it will improve to the point that 50g lovers will start loving it too. It is true that some prime stuff are antinomic to the way things were done on the 50... Change, change change...

Anyhow, for having spent countless hours on 48 and 50 series (when I type text on my prime my muscle memory tries to use the 48 character placement!) I can say that I have 100% switched to prime and feel the better for it. The only times when I miss my 49/50 is when I have to do long series of calculations like checkbook balance where RPN really made things easier. But Prime does offer some good alternatives, even there (for example, enter the numbers in a list and then use sigma list. This has the additional advantage of allowing one to verify his entries. but it takes more planning and a couple more keystrokes).

Cyrille

[DrD]

Santi ...

Because the prime is a different paradigm in hp calculators, like you, I, and several people I know, have had similar feelings as your experience. However, given a chance, the prime seems to grow on you. It's so much faster and easier to work with, (than my 50g), that I finally retired my 50g to its original box, and put it away. I now only use the prime, for everything calculator.

There's been a lot of software evolution since I obtained my first prime. Things have gotten much better, and "issues" have gradually been resolved. As a retired electrician, amateur radio enthusiast, with interests in many other walks of life, I had lots of applications for a scientific computing device. At first, the prime did not seem to meet my expectations, but I always seemed to keep using it for some reason. Gradually, I got to that point where I noticed I didn't use anything else. Probably it was the larger display, and overall speed, that captured my interest.

So, you might not think it is the greatest right now, but don't throw it out too soon. You might just find it pretty handy down the line, and pretty quickly! My one lingering major complaint with the prime is the old style keys, especially the orange legends, which I cannot readily see. The newest inventory seems to have fixed that problem, but I haven't gotten around to buying one of those new ones (yet).

-Dale-

-Dale-

[Santi]

Until later notice I'll stick to the 50g at work, but in the meanwhile I'll try to program the Prime to suit my needs. I'm in the process of polishing and translating my navigation programs to English so I can share them once I'm done if anybody is interested, although i may need some help with the crlib command.
Thank you for your support!

[TravisE]

(11-24-2016 08:29 AM)cyrille de brébisson Wrote:  The programming language is indeed a great improvement over RPL (I imagine that this statement will attract the ire of a few!). Having programmed a LOT in RPL, I however feels correct in this statement.

Well, I do think that can be argued somewhat. I agree that very large RPL programs can be difficult to maintain unless very well documented and broken up into a well-organized series of small subprograms (which is good programming practice, anyway). But, being able to make small, “keystroke-programmable” programs by pressing exactly the same keys as used to solve the problem interactively using RPN, as opposed to having to transform the program into a formal math formula, is a nice characteristic.

Like many others, I haven't completely adjusted to the Prime yet. I'm very attached to the 48g/49g/50g's paradigm (not just in general but to almost every subtle nook and cranny of it), which I consider to be one of (or even the) most well thought-out, intelligently designed calculator interfaces ever made (especially after having read Wickes' Insights books). The Prime is still very new, still has some bugs (which I seem to have a personal knack for discovering frequently, which is quite frustrating), and it feels there are things missing—the program editor feels incomplete and limited, navigating the system and entering text feels slow and inefficient for some reason, etc. The lack of a directory structure is also something I'm unused to. In fact, I'm having trouble translating a complex program I had made on the 50g because it used directories extensively to sort of simulate a “poor man's object-oriented programming”. Without such a feature on the Prime, it's difficult to figure out how to make the program as flexible and modular as the original.

But what I can't argue is that the device has a lot of potential. I really hope that HP doesn't give up on the product before it has a chance to further mature and really shine!

[ColinJDenman]

One imagines Obi-Wan would have preferred the 50G (a more elegant...).

I think the real hurdle with the Prime is the need for it to remain a student/exam market device. The openness of the 50G internals seems very desirable to an old fogie like myself.

The Prime hardware (keyboard colours aside) is quite nice (one could always want more - ram/rom/external store/non-windows connectivity/rpn). But despite some signs of hacking a while back, I imagine HP would be unhappy to see much user lead evolution lest it be seen to damage the market positioning.

Presumably, market wise there will never be a new old-style rpn scientific. any more than a new slide rule (although I did buy a new Concise circular a couple of years ago :-). Oh well, I'll be dead soon enough!

[cyrille de brébisson]

Hello,

"One imagines Obi-Wan would have preferred the 50G (a more elegant...)"

Since we are talking religion here, I do beg to disagree with you!

I think that Obi-Wan would have preferred a Prime.

Han solo would DEFINITELY have gone for the 50G!

The original 48SX was much more elegant than the 50 ever was (and I worked on the 50, so I can not be accused of being partial!) but not as powerful...
I do not know who would have used that one. Someone old, sentimental, someone with enough power in himself and enough love for simplicity. Yoda maybe?

Any other proposal on calculators? What calc would the emperor use? Darth Vader? Jar-Jar binks

Cyrille

[toml_12953]

(11-29-2016 07:54 AM)cyrille de brébisson Wrote:  Any other proposal on calculators? What calc would the emperor use? Darth Vader? Jar-Jar binks

Cyrille

I'm thinking TI Nspire. Only a Jar-Jar Binks could appreciate the way that POS works!

Tom L

I'm entitled to my opinion and you are entitled to my opinion as well!

[ColinJDenman]

(11-29-2016 07:54 AM)cyrille de brébisson Wrote:  Han solo would DEFINITELY have gone for the 50G!
Cyrille

I could live with that, though I puzzle over Obi-Wan -- I was thinking of Alec Guinness, not the lad.

I was interested in your original assertion about ppl v rpl -- is that the view of someone who sees the inner workings, or do you think those of us on the outside looking in would share that view?

Personally I think Yoda would have a woodstock. I like to think Darth would use a 41.

[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

[DrD]

One lingering weakness is program security. Evermore important these days, program security is necessary not only from just from a copyright perspective, but as a marketing tool, and protection of any embedded data. I realize that security is well beyond the scope of ppl, (the prime was not developed as a professional user device).

From a high level view, though, looking down and going forward, built in program security will allow software developers to be able to sell aftermarket products more confidently. Google and Apple would probably agree with this idea, perhaps the FBI might not. Accommodating both needs requires skillful artisans. Will we ever see such a program product from the Jedi masters at hp for the prime or future clones?

-Dale-

[Santi]

I totally agree with cyrille, on the advantages and disadvantages of PPL vs RPL. But as long as we are talking about calculators, I really like the RPL quick and hands-on approach. The thing changes to the other side while trying to make complex programs, as the lack of readability is a bummer, specially for the beginners. Once that you get used to stack your brain it improves...
I think Mr Vader would use a 41 opt1 anyway...

[ColinJDenman]

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

Interesting. I'm new to the 50/rpl, but find it meshes more naturally with my older rpn ways and is certainly less verbose on a key-by-key basis.

As a C programmer for too many decades, I find the Pascally/Modula syntax of ppl rather wearying via the keyboard (and as a *nix user don't use the connectivity kit).

I also find the rpl seems more cohesive conceptually, more encompassing of the whole calculator compared to the disjointed ppl/apps/cas sense I get of the Prime. Still, as I said originally, I acknowledge the target market is rather different, with different constraints, demands and opportunities. And in the fullness of time, it may evolve a little more.

I do like that the app variables are scoped to be isolated within the apps rather than the rpl style of 'global' variables.

And experience with Forth reminds me of your comments about larger programming tasks being less readable.

Thank you for your time.

[TravisE]

I agree with cyrille's post as well, and have pretty much found the same thing: RPL is fun, but maintenance of programs is tricky. (In fact, Python has long been my favorite programming language, with RPL being second. ) It's unfortunate that the market for calculators these days seems to demand catering largely to education, resulting in less freedom and more restrictions. I miss the days when these calculators were primarily marketed as programmable handheld computers—tools. Adjustment to this changing world is challenging for me.

[cyrille de brébisson]

Hello;

"I find the Pascally/Modula syntax of ppl rather wearying via the keyboard"

I agree with you here...
The pascally feeling comes from the use of Begin/End pairs... Honestly, I did use Begin and End because I am an old Pascal coder and (crucially) because the {} symbols were already used by lists syntax.

We actually spent quite some time looking for 1 character replacement to use in lieu of {}, but found none. We were looking for something that could be typed on a PC keyboard (the 48 used special << >> characters, but it make PC programming impossible without a special editor).

This is why we ended up with the very explicit Begin end.

You are correct that on the calculator, typing them is a "sub-optimal" (which is why you have the template menu). on a PC, it is ok.

Cyrill

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

[ColinJDenman]

(12-01-2016 03:43 PM)Claudio L. Wrote:  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.

I think I share that sense of the Prime still lacking a 'wholeness'.
I certainly enjoy RP as a design approach (... ugly senseless...) and find it has always been an expressive style, but as you say, in conjunction with the stack oriented environment. Ultimately, the lack of full RP on the Prime is the thing I find galling in an HP, despite the market orientation.

I suppose it is rather akin to buying a 12C and discovering it can't do 15C scientific functions -- a mismatch with expectations.