This is a menu of the topics on this page (click on any):
We need Excel for rapid application development
Completing an application is hard work.
Reducing system errors as much as possible and providing error control for those that remain
or that occur under some fringe condition is very painstaking work.
That and providing an effective user interface is likely to be as much work
as to achieve the basic functionality in APL.
Whatever flaws remain are might be very serious for the user,
including the loss of current work whenever an error is encountered
and the user faces a unretrievable error message and then the application goes away.
Using Excel as the user interface offers a compelling advantage. When an APL error is encountered, one simply can't complete the desired operation, but no previous work is lost, the screen remains, and it is possible that useful work has been done. This might mean that Excel has an important place in the life cycle of a product for getting started provided that Excel can be used in a way that translates well to the later APL front end. The remainder of this page is to set the stage for discussing how this might be done.
How we'll use Excel
Suppose we were to design an application with the "Plain Vanilla" (Phoenix) approach
whereby programming is done by writing specs which compilers then render in whatever environment is desired.
This might mean that a general purpose front end might be written using Excel that
could be quickly put to work and that might be later replaced with an APL gui.
What we'll expect of the user
The unskilled user
The product appears as an Excel spreadsheet.
The unskilled user must be sufficient power and ease in the application so that effective work can be done.
The skilled user
An immense amount of customizing and decorative or documentary work can be done by the user who has Excel skills.
Simplifying design constraints
Comments by Davin 3/27/04 7:45 pm:
Interfacing APL & Excel will be useful when (a) we're not doing much work beyond retrieving data & handing it off to the user, and (b) when the user will want to rearrange & decorate his own output. Error handling/control is more difficult/limited (if anything) in the (combined) Excel environment -- it doesn't really provide much real benefit. Presenting a fancy user interface is more difficult in Excel than APL (assuming you want to present such an interface). Coding to just hand back raw data is about as easy in Excel as with Phoenix grids.
Providing a nice user interface, in *any* language, typically requires between 75% and 95% of the total coding time, the other 5%-25% being base computational functionality and similar tasks. It's also one of the most important things to the user, so it shouldn't be ignored or given only half-hearted attempts if you want your software to be taken seriously. Converting an Excel front-end to an APL front-end isn't significantly easier than just writing the APL front-end in the first place, and is quite a bit more difficult when you add together writing the front-end in Excel first plus converting it to APL afterwards. (And I'm not just talking about re-using generic form specifications -- the little mechanical details to make all this work swamps that amount of effort.)
There are three good ways to interface APL & Excel -- the choice should be determined mostly by how you want it to behave:
1) Excel is the controlling application, and APL is called under the covers as a subroutine to perform data retrieval and complex calculations. (Usually requires an initial spreadsheet with macros to set up the interaction.)
2) APL is the controlling application, and it starts a visible copy of Excel for user interaction but does all its own calculations and interface monitoring (not a particularly trivial task, BTW). (It's also dangerous if there's another copy of Excel already running.)
3) APL is run as a standalone application, with a simple interface to request retrieval of selected data. This data is then written directly to a native Excel file and APL is shut down (or left running for further requests). That file can then be manually brought up and edited by a standalone Excel application at the behest of the user, in the same way they're used to working with any other Excel file. (As a bonus, APL could bring up that first Excel editing session for them, but it would still be an independent Excel application and would not be talking to APL at all.) This is the simplest and most error-free option, though it doesn't give them a fancy (intelligently moderated) interface of any sort.