Comparing APL/J Implementations

Dick Bowman
Dogon Research
Email: bowman@apl.demon.co.uk

It seems appropriate to collect together in a single place some comparative comments on the major APL (and J) implementations available for the Windows 3.1 (and OS/2) environment. Many of these comments may transfer across to newer products available for Windows 95 and Windows NT - but I do not yet have personal experience of these environments. Please note that the comments are highly subjective and may not reflect the values which you as a reader may apply to these products - you should not use this article as anything other than a guide to beginning your own evaluation.

It is a matter of personal regret that I omit the (generally excellent, but no longer officially available) ISI APL, and that I have not enough experience of modern APLs running under UNIX or on the 68000 chip.

Products covered are Dyalog APL Release 7.1, APL2/2 Entry Edition, J Release 3 Freeware, APL*PLUS III. I also discuss an 'ideal' (short-term) APL, and come to some (personal) conclusions. Links to vendor Web sites are included.

Dyalog APL

Dyalog APL seems to have really come good with its Windows implementations; the core language implementation has always been rich and it has integrated with a more-than comfortable development environment and a well-conceived GUI interface. Industrial-strength applications are easy to build with Dyalog APL and can (depending on the author) have a look, feel and behaviour very similar to any other Windows application.

With a long history as a sometimes wayward introducer of 'interesting' language extensions it is welcome that APL/W is consciously moving toward offering full language-level compatibility with APL2. Recent innovations such as namespaces address issues that have lain dormant in APL (such as name pollution) for far too long. Inclusion of basic ODBC support in the core product is a smart move - because it makes the doorway to integrating APL with data from other applications so much more obvious.

Weaknesses of APL/W are that early releases tended to be rather more unstable than Dyadic Systems would have cared to acknowledge, there still is no visual GUI builder and that too enthusiastic an embrace of Dyadic's language extensions (don't forget, for all of these APLs, this includes the GUI extensions) will leave you locked in to a single vendor. My personal opinion is that Dyadic have squeezed themselves into a position that (when you use APL/W, APL is the home from which all else grows) they are likely to be forced to spend more of their time supporting their GUI (keeping it in line with industry expectations) than on the core APL. I am not yet totally convinced that their namespace/GUI path is really a road towards what the rest of the world considers to be object-orientation, and perhaps they have a marketing problem here.

Return to start of article

APL2/2

APL2 earns its place here because of the pre-eminence of mainframe APL2 and the path that it offers to painlessly migrate to the desktop. It is also the only game in the OS/2 town. My personal view is that anyone committed to OS/2 as an environment really ought to use native OS/2 applications - Win-OS/2 (or whatever they call it) is OK for emergencies, but that's all.

APL2/2 follows the long tradition of idiosyncracity in IBM's desktop APL products - perhaps I just haven't figured out how to use it right. There is, for example, a full-screen editor that works just fine if you double-click on the name of the item you want to edit. But I can't find a way to use it always, and it will not successfully edit a function held on the stack. APL2 has always had focus, in so far as access to files and so forth is through Auxiliary Processors; given the right encapsulation this works well enough and is extended into areas such as DDE. GUI-building once needed purchase of a separate product (the same product as used by non-APL language products) but now appears to be integrated into the product. The core language is very solid (with a few clearly-documented deviations across the whole desktop-to-mainframe family); where APL2/2 gets rough is around the edges.

Support is 'different'; the purchased product is the base product from a couple of years ago, which the user can update by download from IBM's ftp site. While good, in that you can access the most recent updates easily (CSD 7 is the most recent as I write) it leaves me with an uneasy feeling that everything may not be quite alright with the version I have (problems documented as fixed have recurred). I wonder whether OS/2 is the problem here (DOS/Windows may be crude, but you don't need to be too smart to fix it with the proverbial screwdriver). I'd like to like APL2/2 more - and I probably would if there were more native OS/2 applications around to integrate it with; but as it stands at the moment it's an APL that gets used when there's nowhere else to go.

Return to start of article

J Release 3

Let's be blunt - one of the main premises of J is that it solves an APL problem that is no longer an issue for the stand-alone user (the character set and keyboard) and offers a solution which, to these eyes, is worse than the problem ever was. J, to me, is plain ugly.

Now that we have that ritual out of the way, I must say that I like J more every time I use it (which isn't as frequently as I'd like); there's a no-nonsense approach to the development environment and (right out of the box) it comes with a reasonable set of tools for integration with other applications. There's a solid (if basic) GUI-builder, and J2 came with DDE, OLE, ODBC and VBX supported in the base product. Unfortunately the price structure has changed for J3, so that if you agree with my viewpoint that OLE, ODBC and so forth are an essential part of a desktop programming language you will have to purchase the more expensive (but not most expensive) J version. Most of my experience has been with J2.

Any APL programmer is likely to experience a sense of strangeness about J - it is very different and you will probably have to start over from scratch (your APL comfort-pack of personal utilities, tips and techniques is no longer portable). A major factor here is that J arrays are boxed rather than enclosed (in J the box of a simple scalar is different from the original scalar; APL's enclosed simple scalars are identical to the original scalar) - this will force you to start thinking again, which may be no bad thing. The other main shortcoming of J is the documentation - for which the word 'terse' takes on new meaning; it's getting better (Eugene McDonnell's J Idiom Guide is part of the documentation and downloadable from the J Web site), but there are still a lot of gaps to be filled either by your own experience or by the (future) arrival of more articles and books about J from a wider set of authors.

What I like most about J is what I perceive as its direction; there is a useable-enough development environment and a basic GUI editor - but J may be called as an OLE server. This means that you can develop the bulk of your GUI using industry-standard tools and do the bits that they don't handle well in an appropriate method (J does the sums - in other words); since J itself has stuff like ODBC built in you are able to deal with 'conventional' data and can resist the temptation (?) of component data files and lock-in to wierdo-technology. This ought to mean that the J development group can concentrate on improving what they do best and leave MS-catchup to people who do MS-catchup well; I think we get the best of both worlds

A problem with J is the way that it changes from release to release - quite fundamental things which worked in J2 need reqrites to work in J3 (GUI code is a particularly painful example). The long-standing excuse has been that there was no customer base to alienate; current documentation says that future releases will be backwards-compatible (frankly, if J does not address this issue they may never have a customer base to alienate).

Return to start of article

APL*PLUS

I have to mention APL*PLUS, because of the legacy effect; there are still a lot of APL applications based on years of APL*PLUS/PC and the mainframe stuff. APL*PLUS has suffered from a belated arrival in the Windows arena, and (my personal opinion) has a lot of catch-up to do.

The core language seems to be solid, the GUI-builder has a small footprint, and there are innovations such as the control keywords and context-colouring. The GUI extensions are less in the APL idiom than those of APL/W, aligning much more with a VB-like 'onEvent' model that doesn't sit quite so comfortably under my fingers. Not owning a legacy collection of APL*PLUS applications APL*PLUS always seemed to offer less than APL/W and I have rarely felt it attractive to use. Hopefully the new owners will feel able to put more development behind the product.

Return to start of article

An Ideal APL?

None of the present crop of APL implementations is perfect, and this means that it ought ot be possible to compile some sort of personal wish-list for one that is. Here goes...

The list is unordered (apart from the first item), and incomplete.

Return to start of article

Conclusions

None of the current APL implementations for the desktop comes anywhere near satisfying my wish-list; but at some point I would like to settle on a preferred version for personal use - this will probably be a Windows NT solution and a best basis for taking a decision is projection from current usage of the Windows 3.1 products.

Dyalog APL would be the no-risk choice, but I am concerned that unless their 'make it like Microsoft APL would be' approach will lead to some sort of stagnation as they continually chase a moving GUI target. I know that (at present) I can build whatever I want with Dyalog APL. A more likely choice is J, probably in conjunction with something else (no ads here for non-APL programming products) to build front ends; this is achievable because the combined price is lower than stand-alone Dyalog APL. The reasoning here is that I like their direction of concentrating on the computing engine and fitting into a strong framework; also that writing J is a personal challenge. Possible further future changes to J syntax are a cause for concern. Of course, if the rumours of a Windows NT port of APL2 have any basis in fact this will also become a contender.

Return to start of article
Back to the J\APL Contents Page

The Journal of APL is produced by Dick Bowman

Copyright Dick Bowman 1996-2013; latest update 14 March 2013 (repaired links)