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