HP 50g Programming Methods???

[DavidM]

(11-04-2017 01:38 AM)Carsen Wrote:  1. Besides UserRPL, SystemRPL, and Assembly, what other methods of programming are available for the HP 50g?

I believe others have already listed the important ones.

(11-04-2017 01:38 AM)Carsen Wrote:  2. For creating a ton of programs in the form of a library, what programming method is the best to use in terms of speed and memory?

There's not really a "best for libraries" method (IMHO). It really depends on what you want to do, and the programming environments with which you are most comfortable. Any object that can be stored on your calculator (program, list, matrix/array/vector, number, etc.) can be included in a library. The 50g has a "development menu" (256 MENU will show it to you) which includes a command (CRLIB) for building libraries based on the contents of a directory on your 50g. There's a good description of how to use it in this manual in Appendix B.

(11-04-2017 01:38 AM)Carsen Wrote:  3. I read about the HP 50g crashing with SystemRPL. What happens when it crashes? What are the dangers of programming in SystemRPL?

Apologies in advance for my long response, but this needs a bit of an explanation.

When you program using standard (aka "User") RPL, each and every command executes special code to make sure that everything is safe before proceeding to perform the indicated function. For example, if you have a "/" in your program, that command first checks to make sure that there are at least two objects already on the stack, and also that they are objects that make sense for a division to occur. This is even more complex than it may first seem, as the actual method of division can vary even further depending on whether the arguments are exact integers, real numbers, complex, symbolic, algebraics, or some combination of the above. This "pre-check" is absolutely necessary to ensure that user-written programs will gracefully avoid those situations where a user has done something inappropriate (such as attempting to divide a number by a string) as well as branching to the proper method of performing the division based on what's been given. This branching aspect is common to many programming languages and is usually referred to as "overloading" a function or procedure.

In contrast, most System RPL commands don't do any pre-checking at all. They are written to assume that the programmer has already made sure that everything is OK. Furthermore, most System RPL commands are highly specific to certain object types. There are unique "division" commands for various kinds of arguments, and they are not interchangeable. You shouldn't attempt to use %/ (division for two standard-precision reals) if you have two extended reals on the stack -- there's a %%/ command for that situation. This specificity is simultaneously one of the best features as well as a dangerous one. The commands perform well because they skip all of the "safety checks" of their UserRPL counterparts. But they blindly assume that it's OK to proceed without checking.

System RPL commands will gladly attempt to do very inappropriate things if you give them bad arguments, and the results are never good when they do. At the very least, a system reset can occur. Just as likely, though: data loss, data corruption, or the complete loss of your calculator's stored data in some situations. IMHO, a hard crash is actually better than data corruption, which can sometimes go unnoticed for a long time before its impact is seen.

Yes, it's very easy to inadvertently crash your calculator with System RPL (sometimes badly). But there are also advantages besides faster operations due to the lack of pre-checks. System RPL gives you access to different object types (such as the extended reals mentioned above) and additional functionality that you can't obtain through standard User RPL (far more input form features, for example). One of my most frequently-used SysRPL features is the use of null-named locals, which is essentially a faster way to use locals in your programs than is available with User RPL. The benefits that brings to code readability/maintainability and organization are significant.

Some SysRPL programmers have reached the level where they are perfectly comfortable writing their programs and testing them on the calculator itself (and with the proper tools installed, this is easy to do). My preferred method, though, is to use Debug4x on my laptop and testing the code on its integrated Emu48 target during the development process. No matter how careful you are, you will eventually do something you never intended in your code which crashes. If you don't, you simply aren't trying hard enough. Using an emulated calculator gives you the freedom to develop without having to worry about the inevitable "reset and restore" operations that are required with crashes of the real thing. Once you've got the code working properly, copying to your calculator is all that's needed.

Having a background in programming can give you a head start on learning many of the concepts needed to write useful programs for your 50g, but it's not a prerequisite IMHO. I do, however, strongly encourage you to start with User RPL first. Not only is it safer, but it also forces you to become familiar with many of RPL's more abstract concepts and features before being exposed to the nitty-gritty details of how they are actually implemented in something like SysRPL.