[Off-topic] HP Prime is for students... What about professionals?

[TravisE]

Tim:

What I really liked about the 48/49/50g was that virtually every type of data was an “object” and could be moved around and organized in the system in the same way. All of them, including programs, could be stored on the stack, in variables, or even in lists. Everything from system commands, “directories”, grobs, even fonts could be as well, since they were also considered objects. This was a refreshingly consistent abstraction which led to a lot of simplicity and flexibility when it came to developing advanced programs.

The Prime, on the other hand, seems to abandon the “everything is an object” idea, and many types of data, particularly programs and apps, are “special” and can't be manipulated in the same way. If I understand correctly, programs can only exist in a special, flat programs menu, and they can't directly be stored and executed in a variable hierarchy, nor be passed as parameters to other programs, nor collected and organized in a list or other data container object. This makes certain types of programming problems a lot harder to solve.

Yes, trying to use the directory-resolution scheme of the 50g/et.al. on a normal disk filesystem on a modern general computer OS would probably result in a lot of chaos, because they were not designed for such a scheme. But for 50g RAM objects living in an interface that was designed with this behavior in mind, I have found it an indispensable data model. I even managed once (without actually realizing it, even) to simulate a poor-man's version of object-oriented programming. I wrote a program where I used directories sort of like classes. Each directory was an object “instance” which I could store variables of particular standard names in and use as if they were class attributes (numbers, strings, etc.) or methods (programs). The program engine would use the contents of those variables to control its operation, and I could quickly customize it with different sets of parameters by simply swapping out the directory “classes” (or even add routines to manipulate them dynamically at runtime). And, by placing variables of the same names in higher level directories, I could provide for default values to be used in the case of variables that did not exist in a particular directory object (somewhat like single-inheritance). The 50g's system UI made navigating and editing the model quick and easy, and it made for a clean and very flexible architecture. Admittedly, this is probably a rather unorthodox use of 50g “directories”, but I used it because it was there and was a good match for my problem.

When I got the Prime, I wanted to port this program to it and take advantage of the more powerful display and processing speed, but have not been able to think of a way to preserve a similar design. The syntax for saving and retrieving persistent variables and objects as app variables feels overly verbose and clunky, it only provides a flat storage model, and small program routines cannot be saved as variables (unless perhaps they are converted to and from strings, which makes them inconvenient to create and edit). As far as I can tell, I'd have to store all data flat and write my own framework to be able to treat it like a nested hierarchy (and hope that performance of doing this from an interpreted language won't be too big an issue). It seems that I'd have to place all the customizable code routines I want to use directly in the main program source file (which could become quite large, and the Prime editor is not pleasant to use with large source files). Compared with being able to individually store and edit small program routines in a conveniently-navigable hierarchy of variables, this feels like a major disadvantage.

Of course, some of the 48g/49g/50g behaviors don't make sense on a “real” disk file system, which is probably why (along with technical limitations) the 50g treats the SD card and port memory differently. There are some good questions you raise, and I'd have to think about those.

As an alternative to “directories”, one thing I think might be helpful is if there was a key/value-store data type, sort of like how AFiles works, but which could be stored collectively as a single unit in a variable, passed as a parameter to functions and programs, and accept other key/value stores as values (as well as anything else that could be stored in a regular program variable), which would allow for convenient storage and manipulation of nested data hierarchies in programs. This could be used to at least simulate directories in some respects, which are conceptually similar. Modifying and storing back a deeply-nested value, on the other hand, could be syntactically inconvenient unless some means is provided to access them by reference instead of by value, at least for the purpose of reading and writing without having to specify the entire path each time. (For my purposes, the system need not support storing references themselves inside the key/value store, which could open all sorts of cans of worms like circular references that you guys probably don't want to deal with. )

It could be that I'm underestimating the ability of storing code snippets as strings and evaluating them later, but the extra conversion step is a little annoying, and I believe I have found a measurable performance impact with having to parse the string each time it's executed if I'm doing it inside a tight loop. Maybe if there was provision to cache a pre-compiled version of a string of code and save that in a variable for quick evaluation? Combining that with a key-value store like I described might be enough for me to get around much of the “directory” limitation.

Of course, I suppose an even better solution might be to have true OO-style programming on the Prime, though maybe that's a bit much to ask.