Some time ago I described the then-new APLX from MicroAPL; now there's a version 2 and it's worth taking a further look.
I was favourably taken by APLX Version 1, which offered a reasonable alternative to other APLs on the Windows platform and was also available for Mac and Linux. If less "substantial" than APL/W it was significantly less expensive on the Windows platform, free for Linux and unique for Mac. I never had the chance to try the Mac version, but the Linux offering was interesting and offered not only code portability but also workspace compatibility between Windows and Linux (when Linux failed, I could just pick up and carry on with the code in Windows). This portability is interesting enough, but what sort of steps forward does Version 2 represent?
In addition, I've now spent a lot more time with APLX, and this gives me a much better sense of useability.
I've long been a little frustrated that APL interpreters (in general) run single sessions - the sort of thing I want to do while working in one session/workspace is to take a quick look elsewhere for interesting objects which I might copy in. It's easy enough to open another APL session, but it somehow seems "wasteful".
APLX Version 2 meets with some of my wishes, as a developer. But the APLX development environment is very "unstructured" and what the developer gets is no more and no less than a second/third/... APL session. I'd rather wished for (but played no part in design) something along the lines of a "tabbed session". It may or may not have been better to use, but something needs to be done to get the multiple windows under some sort of control.
What comes as a bonus is that not only can developers open new sessions, so can APLX itself. Which is useful for hiving off those "worker tasks" and having them report back when finished. Being an unsatisfiable soul, I'd hoped that secondary sessions could be used for little jobs (for example, letting my applications have all their utility code "outside") - but the synchronisation/reporting tasks are (while easy enough to use) themselves a bit of an obscuration - meaning that secondary sessions are most use when they do something substantial.
While this is all well and good, I see parallels here with Sharp APL's various spawned tasks, and Dyalog's multi-threading - it feels a pity that virtually every time APL steps outside of the VSAPL box every implementor goes their own way (but then my goals - among them wanting to take my APL code wherever I want - are not the same as the vendors' goals).
When I first looked at Dyalog's Grid object I made the mistake of underestimating just how much I'd ultimately use it.
APLX Version 2 comes with its own Grid control - very much simpler than the Dyalog object and in some ways easier to use (especially bypassing the need for a tier of edit objects when doing anything more than displaying values).
It's a good step forward - form design is a good deal easier for the programmer who has a grid available to them. I do wonder whether the simplicity will survive into future generations, though (I expect that MicroAPL will come under pressure to add many more options to the grid).
I blow hot and cold on component files - on the one hand they are the most convenient way to put APL objects onto file, but every one is different and so data can be locked into a particular vendor's APL. But APLX didn't have them before, and now they do.
They work as advertised, and that's what we want.
Equally, as we expect, there's been a bit of original thinking going on and it's possible to ŒFWRITE to a non-integer component (meaning "insert between". I'm not sure how heavily this is going to be used - I tend to think of component files as having an overall design so that if a new component is needed it can just go at the end. My own component files tend to have an index component which shows where wanted data can be found and it looks a bit "awkward" to go juggling this around just so that I can add a new component midfile. I guess MicroAPL have something in mind that makes this important enough to add in (and now that they've done it, it would be good - but probably too much to expect - for all vendors to do likewise).
There's a whole raft of the sort of miscellaneous improvements that we normally see as products go from version to version...
One thing I was pleased to see (which had escaped me before) is APLX using the same sort of control keywords as APL/W, APL2 and so on. It's not that what they had before was worse (it might arguably have been better) - but at least it's a sign of vendors converging.
This look at APLX was lengthier than my earlier look at version 1. My goal was to build a small application which exercised the new features, and this was successful. It's also important to recognise that I've been using Dyalog APL/W almost exclusively for several years, meaning that "the APL/W way" falls easily under my fingers and negative reactions may reflect difference rather than value.
Certainly APL/W has a much more contained session, the edit and debug windows sit docked (or dockable) and it's easy to explore the workspace (I was slow moving from old-world APL to things like the Workspace Explorer - but couldn't go back). On the other hand, APLX opens edit/debug windows independently and it can be hard to corral them all together again. The sort of thing I miss is "find", in the sense of "find me this string anywhere in the workspace".
Another frustration - moving from APL to APL - is that I haven't found a universal keyboard. What's Ctrl-key for one is Alt-key for another.
But that said, and despite it all, putting together my little application was quite a smooth process - APLX is solid, the session is workable, and the documentation is clear.
The "big feature" of APLX is portability - write and run the same code on Windows, Mac and Linux. I didn't explore this very much - Linux itself was frustrating experience, and I have no Mac available to me - but if it's what you need APLX is not only the only game in town, it's a pretty good bet. If I wanted to run APL only on a Mac, I'd have no choice - but I'd also have a pretty good APL.
The multiple sessions, grid object, and component files are good news for APLX - they move the interpreter nearer to APL/W (which has to be the target in today's APL world).
I think my frustration with APL interpreters is that while competition and innovation are good, they've led to a very fragmented APL world where we are all competing with each other rather than the inadequate and half-baked languages used for application development elsewhere. I'd rather see all the APL vendors get together and make one killer APL. Fat chance of that happening.
Meanwhile, if you're the sort of person who needs APLX - or if you just want a good interpreter, you won't go far wrong. Looking forward to Version 3 (and if my wishlist were to be granted, namespaces, dynamic functions and dot-notation).
Copyright © Dogon Research 2004; Latest Update: 08 March 2004 16:13