As has become a tradition with us, we ran the session as a two-man show, with Pearson on keyboards and Smith on vocals. In the hour which we had available we tried to do three things:
The power of this idea becomes more and more apparent as the complexity of the system grows. The programmer's responsibility is limited to the task of listing, for each control, the expression it shows and the variables it depends on. In between the C++ Windows code and the J 'workspace' lies cw.dll which logs all these dependencies and ensures that any dependent controls are updated for you. We were fortunate that it was possible for Roger Hui to build into J a new debugging verb 4!:5 which can list all the nouns which have been assigned since the last invocation. This makes it the interpreter's job to track changes to data, which is a significant improvement over Dyalog Causeway where the application must 'notify' such changes manually.
Duncan illustrated the basic ideas with a simple Windows form containing an edit field and a bunch of radio buttons. The edit field showed a line of text selected from a matrix by an index; the index was changed by the radio buttons. The dependencies of the edit field were listed as the text variable and the index. As the radios were selected (at keyboard repeat speed using the down arrow) the text changed to match.
This particular example was set up using global data - all the variables were listed with trailing__ to point to the base locale. This gave the interesting possibility of starting more than one form and changing the text or index on any of them! As you would hope, a change to any was instantly reflected in all, and the speed (on a 486 DX2/50 machine) was such that there was no visible delay in updating.
In response to a question from the audience, Duncan removed the __ from the index and recompiled the C code. This had the effect of making the assignment of the index take place in a locale created specifically for that form so that the index could be different on each form and the edit fields were editting different rows of the same global matrix.
The SAP software suite is a complete integrated set of business applications which a large company can use to handle all its commercial transactions. It does all those things - like accounts, inventory, order processing - which APLers traditionally avoid! Some years ago, the top management at Nestle noticed that they were employing more programmers than Microsoft; they bought the SAP software to replace them.
Unfortunately, all large companies are complex, and multinationals particularly so as they must work in many currencies and under many different tax systems. Setting up an SAP system has always kept highly-paid consultants well employed, but at least until recently there was only a single database to worry about. The original SAP suite was designed for IBM mainframes and even the newer R/3 product is still very centralised. However with customers getting more and more determined to distribute data to the point of use, SAP needed to build in some logic to allow several physically separate databases to behave as if there was still one logically consistent application. Their term for this was Application Link Enabling (ALE), and it adds another highly complex task to the installation schedule!
The idea would be that if a warehouseman in Manchester booked in some coffee beans, the inventory change would be (naturally) posted to his local database, but that an ALE message should be sent to whatever company is responsible for that store, as the book value of the company has changed as a result. With a complex organisation where many plants can manufacture for several 'companies' the rules for who needs to see what get rapidly out of hand. Setting up the ALE configuration is mostly about checking along various axes of large boolean tables and doing partitioned or-reductions to see what messages are necessary. Of course this was not how a C-programmer would perceive the problem, which probably explains why SAP were unable to build a good tool to handle this job themselves!
We came on the scene late in 1994 when the ALE team were already committed to a demonstration of a graphical configuration tool by the following March. Fortunately they were willing to gamble on us as a long-shot who might just be able to do the job. We attacked the problem in Dyalog APL/W and were able to show a working prototype by the end of January which they had on the stand at the March exhibition. This prototype has since been extended to include a good part of the normal setting-up task (such as defining plants and companies) and is shipped to around 2000 SAP customers on CD ROM.
An interesting question is why we have decided at this point to switch platform from a single APL base to a mixed environment with C++ for the user-interface and APL for the logic engine. On the face of it we are adding a layer of complexity which one might reasonably expect to slow things down as well as giving us all sorts of new reliability and maintenance headaches.
Secondly, we are concerned to ensure that someone other than ourselves can support and maintain the code. We are a 2-man company and it is not fair to expect SAP to entrust a critical part of their configuration software entirely to such a small concern. The logic code is not a problem - it is the kind of APL that a VS APL programmer from 20 years ago could quickly pick up and fix. The GUI code is highly Dyalog-specific and in many places we may be doing stuff which no-one else in the world has tried - it will keep working only as long as we are around to patch it, assuming that Dyalog don't accidentally change the interpreter behaviour to make some particular trick impossible!
Finally, we need speed. The redraw times on several of the main forms are unacceptable, and the build time for new forms is not as fast as it should be. Part of this is down to the overhead of Causeway - every time you build a form it must register objects and dependencies - every time a changed variable is 'notified' it must look up the table and 'refresh' dependent objects. With namespaces we can improve the redraw times, but no amount of optimisation will get the build time down.
By moving the causeway logic out to a DLL, and by compiling the forms from C++, we can address the speed issue. However we were determined not to throw away all the advantages given to us by APL in solving the complex logical problems in a clean array-based way. At the moment there is only one APL interpreter available on the market which offers the possibility of an in-process OLE server which we could use as our logic engine with minimal call overhead. I am sure that we don't have to tell this audience that the interpreter in question is J!