Hi. I am working on a rationale for APL in business applications. The following is my first draft. Your opinion is greatly appreciated.
Blake *Rationale for APL in business applications* *From 1980 to 1985 I programmed business applications in APL. I have* *been programming business applications in many other languages since* *then on a full time basis (30+ additional years). Looking back, I* *believe that I produced more business applications in the first five* *years than the following thirty years. The reason for this is the* *subject of this commentary.* *I have been reflecting on if and why APL would have allowed me to be* *so much more productive. After some reflection I concluded that it* *did, in fact, make me significantly more productive for reasons I have* *been able to surmise as follows.* *APL gave me three huge advantages, one of which is available but* *unused in other languages, and the other two are largely unique to APL.* *1. Terminal / command line programs* *The first benefit is also available in all other languages but rarely* *used these days. In the old days, there was no graphical user* *interface (GUI). The program presented one question to the user at a* *time. The user traversed the application functionality through this* *one-question-at-a-time interaction. Although, to those who never used* *any interface other than a GUI, actually being able to use a non-GUI* *application would seem clunky, limited, and difficult, it is actually* *much more usable than one might imagine. Before the GUI, it was used* *successfully for a long time. The biggest drawback is that it is not* *sexy or pretty, but it is practical and workable.* *These days I spend at least 80% of my time on the GUI. That means 20%* *for the actual design and system logic. With APL, I spent 20% of my* *time on the interface code and 80% on the program logic. This is a* *very, very significant factor in the overall time it takes to develop* *an application.* *Now, I am not suggesting that retail applications abandon GUI's by any* *means. Sexy and cool sell. The world expects a pretty interface, and* *a retail application that doesn't embrace a GUI will surely fail.* *On the other hand, I would bet that there are more in-house* *applications written than retail applications. In-house applications* *are built to get a job done efficiently, and not to make money on* *their sale. These are the targets I am referring to. Especially on* *in-house applications with a small number of users, a GUI is a waste* *of time!* *2. Dynamic, heterogeneous data structures* *APL is unique in its ability to deal with dynamic, heterogeneous data* *structures. This makes it very easy to associate various types of* *information into a single piece of data. * *For example, you may have a customer. You want to keep their name,* *address, any number of contacts, their invoices, their payment, etc.* *In a traditional application you would have to pre-define database* *schema, structures, classes, etc. You would have to define many of* *these different structures and set them up to point to or inherit from* *each other. Then, as you discover additional facts, you have to* *modify those structures to accommodate the new facts. This is a lot of* *work.* *APL can deal with this in a totally dynamic way. It can also adapt to* *changes comparatively trivially. APL2 allows arbitrary, heterogeneous* *data structures to be created and manipulated in a totally ad hoc way.* *APL's ability to deal with dynamic data structures is literally* *unmatched.* *A second benefit in this category is APL's ability to deal with bulk* *operations on large data-sets. Rather than looping through each element* *performing the needed operation, APL is able to apply the operation to* *the entire data-set in a single operation- perhaps, or as if, in* *parallel. This is the aspect of APL that is especially useful in the* *scientific and mathematical arenas, but often applicable to business* *as well.* *3. Keyed Files* *Although not actually a part of APL, keyed files are a necessary* *business capability that has existed in all the APL's I used in the* *past, and is now available in GNU APL. (For some of the APL's I used* *in the past, I wrote the keyed file system for it. But in the end, I* *had a keyed file system.)* *Keyed Files allows the persisting of arbitrary, heterogeneous arrays* *to disk that is accessible via a string or numeric key.* *These days, in the non-APL world, we use SQL. This requires a great* *deal of planning and design for a complex schema providing for all of* *the data relationships. In APL, all of those relationships (and* *corresponding design and implementation) is unneeded since it is all* *kept in a single, heterogeneous array. In APL you could key a file by* *customer number. When you read a particular customer, all of the data* *associated with that customer is read in. Everything known about the* *customer is in one array. If the data is too big for one customer,* *you can split it up and archive it, but this is rarely necessary.* *Conclusion* *If the purpose of in-house application is to get the job done at a* *minimum in development time and cost, APL is a significant and viable* *solution and worth considering. With APL you can develop cost and* *time sensitive, but not sexy, applications at a fraction of what it* *takes in all other environments I am aware of.* *GNU APL is free, and it works well. Adding my keyed file system and* *my or your utilities to it and you have a proven and highly productive* *development environment.* *Blake McBride*
