Links: Tom Edelson's home page; Tom Edelson's LiveJournal
The purpose of this document is to support the claim that my Asset Allocation Report software ("ASAL", for short) will be of technical interest to some of my fellow programmers, and to help you decide whether you are one of those programmers. Before I do that, though, I need to introduce some basic background information on its implementation.
ASAL is not a standalone program: it's an "add-on" to a pre-existing "personal finance program" (or "PFP", for short). Probably the best-known program in this genre is Quicken, but ASAL doesn't work with Quicken. It works with either of two other such programs: jGnash or Moneydance. (Details on the supported versions of each are given in the "System Requirements" document.)
One thing these two programs, jGnash and Moneydance, have in common is that each of them is written in Java. ASAL itself, though, is not written in Java. It's written in SISC, which is an implementation (and dialect) of Scheme, which is in turn a dialect (or family of dialects) of the Lisp family of programming languages.
The SISC implementation of Scheme, though, is itself an interpreter which is written in Java. And so SISC code, like Java code, does run inside a Java Virtual Machine.
The design of ASAL ... specifically, how it gets the data it needs from the PFP (jGnash or Moneydance) ... calls for a tight integration between ASAL and the PFP. It doesn't get the data from a file: it wants to access the in-memory data structures of the PFP. That implies that it must be running in the same JVM as is the personal finance program whose data it wants.
There will be more to come on the implications of this fact, since it underlies one of the principal points of interest that I will claim for the software: the one that I will call the "zombie application" feature.
But first, another piece of general background: my Asset Allocation Report code is, at present, unreleased software. What I'm doing here is testing the waters, trying to find out whether anybody would download it if I did go through the "release engineering" process (because if not, why bother?).
Furthermore, this question, "Is anyone interested in this stuff?", doesn't really call for a simple "yes" or "no" answer. That's because depending on who's interested (programmers, potential end users, or both) and other specifics, there is more, or less, work to be done on it before releasing it. In particular, as will be explained in more detail below, one of the things I might do, in order to make it more attractive to users, would actually remove one of the features that I will name as being of potential technical interest to some programmers.
In its close coupling with another program (jGnash or Moneydance), ASAL resembles a "script". But in order for it actually to be run as a script, the PFP itself would have to have built-in support for scripting in SISC. And neither jGnash nor Moneydance, at least at present, has such support. (Releases in the jGnash 1.x series support scripting in BeanShell; those in the jGnash 2.x series support scripting in Javascript; and Moneydance, via an optional extension, supports scripting in Python.)
Absent scripting support for SISC in jGnash or Moneydance, neither of them could be the "host" for running ASAL as a script. For reference, if it were possible, the process of running it would look like this:
The user starts the PFP application.
The user tells the application to run the ASAL script.
The application launches the SISC interpreter.
The application tells the SISC interpreter to run ASAL.
Since this is not possible, how can the user's actions cause the ASAL software to run, and to have access to the in-memory data of jGnash or Moneydance?
The answer is that the process outlined above gets turned upside down:
The user starts the SISC interpreter.
The user tells the the SISC interpreter to run the Asset Allocation Report.
ASAL launches the PFP application.
ASAL takes what it needs from the in-memory data of the PFP application, crunches the numbers, and produces its report.
And this implies part of the reason why a non-programmer would probably consider ASAL to be difficult to run. "Telling the SISC interpreter to run the Asset Allocation Report" consists of interacting with the interpreter's REPL (read-evaluate-print loop), not with a GUI (graphical user interface). In other words, it consists of typing some SISC code in a terminal window.
(More details on this, and on the principal other reason why I think an end-user would find ASAL difficult, are in the parallel document aimed at prospective end users of the software, which can be found at user-doc.html.)
So: the way that one launches [the current version of] the code for ASAL probably won't look very friendly to most end users. However, the technology behind how one launches ASAL is also one of the reasons why I think that the ASAL code might be of technical interest to some programmers. It's not very often that software like jGnash or Moneydance (each of which was designed on the assumption that it would be a standalone application, with the JVM all to itself) gets launched by other code already running in the [same] JVM. It may not be immediately obvious how this would be done. And even knowing that, it may not be obvious how the ASAL code can then access the internal data of the PFP application, since the PFP was not written with this in mind.
On the principle that a technique gets more interest if it has a catchy name, one could say that ASAL, in its current form, "zombifies" your personal finance application. That is, the process resembles the original, voodoo-based account of how zombies are created and used: the ASAL code brings the application to "life", and then makes it do its bidding (hand over the desired data).
So that's the first way in which I think ASAL's design might be of some technical interest. I can think of at least two more ways.
The second way is also suggested by something that I've mentioned already: the fact that the ASAL code works with either jGnash or Moneydance. How is this possible: do jGnash and Moneydance adhere to some common API for accessing their internal data?
No, they don't. The technique by which this is overcome is a standard technique for making software portable: the software is divided into a "portable layer" and an "interface layer". It might be kind of interesting to see an example of how this general technique can be applied in this new setting. "New setting" refers to the fact that the goal, here, is not portability between hardware architectures, or operating systems, or Scheme implementations ... but between two application programs designed for end users. Two application programs, that is, which provide fairly similar functionality, yet have some sizeable differences in how they provide it.
And the third way that the ASAL code might be considered technically interesting? That would be the fact that it uses closures as "poor man's objects" ("objects" from the point of view of a programmer who is much more interested in encapsulation than in polymorphism or in inheritance). I think that most experienced Scheme programmers are already aware that this can be done, but still, there may be some interesting wrinkles in the way that I have done it. For example, I have created a macro which makes the definition of such "objects" a little less labor-intensive.
To summarize the sales pitch (programmer's edition) for the ASAL code, the principal selling points (that I've thought of) are:
It turns scripting on its head: rather than the application launching the "script", the script launches the application.
It uses a standard technique for making software "portable", and uses it in, I believe, an unusual setting. (Also, even though it's a standard technique, not every programmer has first-hand experience with it.)
It uses closures as a sort of objects; and there may be some novelty, and/or elegance, in the details of how this is done.
Of these three features of possible interest, the first one, the "zombie application" technique, is in a different position from that of the others. That's because I consider this technique to be (in this context, at least) a clever hack, not an elegant solution. I think that the Asset Allocation Report would be more user-friendly if it were run according to the standard "scripting" model.
And so, if potential users express interest in this software, it might be on the condition that the software first be made easier to use in this way. If that's what the users want, that's what I will plan, sooner or later, to do.
But in so doing, I would be removing from the software the code which illustrates the "zombie application" technique. So if you are interested in that particular technique, it's important that you let me know that specific fact about the nature of your interest ... so that I can send you a version of the code which still makes use of that technique.
It's always a good idea, when requesting access to someone's code, to be specific about the nature of one's interest in it. But in this case, doing so is of somewhat more practical importance than usual.
So help me out: let me know whether you'd like to see this software released (since if nobody does, it won't be). And (if you would) let me know what you anticipate doing with it: using it to manage your investments, studying the code to see how it works, or (just possibly) both. I need these additional particulars from the potential audience, since it's not just a question of whether to release it, but in what form.
What's that? You're asking how to let me know? That's easy: send me an email. My email address? Take the username "edelsont", and put it together with the domain "well.com".
I look forward to hearing from you.
This page created: 2010-10-27
This page last modified: 2010-11-10
© Copyright 2010 by Tom Edelson.