Hi. I am working on a rationale for APL in business applications. The following is my first draft. Your opinion is greatly appreciated.
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