Review: Dyalog APL for MS DOS

Transcribed from the printed issue; not yet reviewed. Read it in the PDF of the issue, page 49

Introduction¶

This is definitely not a review! When you come across something as novel and exciting as Dyadic’s new APL Session Manager, your first reaction is to play with it, then you start to wonder why no-one thought of it before, then you go back to APL*PLUS/PC and are overcome with sudden depression. I feel about as competent to review this product as I would be to review (say) Windows 3; I just don’t have enough experience of working with windowed development environments, so what follows must be taken with a very substantial pinch of salt. If you want a full technical description of how the Dyalog environment works, please refer back to John Scholes’ article in Vector 6.4, page 101.

Why has No-one Done it Before?¶

This is the first real attempt to market an APL system for the 1980’s. Surely this is absurd; I bought my £50 copy of Turbo Prolog at least three years ago, and it came with windows for editing, tracing, program output etc. These could be tiled or overlaid, resized with the cursor keys, zoomed to full screen, set to your favourite colours and so on. Turbo Prolog, like APL, is interpretive, and benefits more than most languages from this kind of environment. Unfortunately, Prolog has the disadvantage that it is almost impossible to program anything useful in it, so I’m afraid it has joined the ranks of unwanted software on my bookshelf upstairs, and no longer even merits space on my hard disk.

Meanwhile, we soldier on with APL*PLUS/PC and APL2/PC. The former is OK (as glass teletypes go); the latter is a poor imitation of the mainframe AP120 and I am glad to hear it is due for a total rewrite in Release-2. APL*PLUS/PC is dogged with some dreadful limitations, the main one being the lack of full-screen edit on suspended functions. Coupled with the fact that ⎕EDIT doesn’t window properly, and the hassle of moving code between functions, and from functions to the APL session and back … I am beginning to get more than a little frustrated. Of course APL*PLUS II does actually do most of these things, but by such a horrific tangle of key combinations that only the most dedicated hacker will ever use it to its full potential.

In summary, Dyalog have moved APL a long way in the right direction. I hope the rest of the APL world is running as fast as it can to catch up, and hopefully do it even better. The rest of these notes should be read with this in mind!

Why a Development Environment Matters¶

I cost Rowntrees about £300 a day to run; between one third and one half of that time is spent developing and testing APL code; with the APL*PLUS/PC environment (the plain old kind) I reckon I go about 30% faster than on the mainframe (and we have sub-second TSO response). Watching carefully what I do most of, and bearing in mind the strengths and weaknesses of APL*PLUS/PC, I am confident that Dyalog would give me at least another 20%. At a conservative estimate, that looks like £20 per day, or £100 per week, or £4,800 per annum. That is clearly the kind of money that makes accountants look up and take note.

To look at it from the other end: we have two people working nearly full time rolling out a complete rewrite of our company-wide medium-term planning system; this is scheduled to hit the various UK sites between now and early 1991. Of course we are under all the usual pressures (the spec keeps changing, Oracle keeps going down at the wrong moments, …); if we could cut 30% out of the final debugging and testing time, we would be more confident of meeting that schedule, and more likely to deliver a product that worked!

There is one more angle worth considering. If I come home after a day’s mainframe work, I am tired and ratty, and likely to beat up the children for no particular reason. If I come home after a day working on APL*PLUS/PC, I may aim the occasional kick at the dog, but am usually able to sit down of an evening and hack out an article like this. A day at work with Dyalog APL, and I might actually become a nicer person, able to play Scrabble with the family and willing to take the dog for a walk in the rain!

Good APL developers are hard to come by, and just as the best secretaries can demand the best word-processors, I reckon that we poor bloody infantry have earned the right to some decent boots that keep the water out, and don’t chafe too much round the ankles. If you are an OR manager, and you want to get rid of someone - give them a TSO system to maintain. If you want to keep them - put them on PC work. If you really can’t afford to lose them - get them a copy of Dyalog APL.

To summarise: the development environment matters because it saves you money; because it gets better systems delivered faster; because it helps to keep your staff. The next section looks in more detail at some specific areas where time and money can be saved.

Where the Dyalog Environment Scores¶

I spend a lot of time digging around in old systems looking for the bits that need to be changed. This usually means going in at the ⎕LX and working down the tree of functions until I find the ones that do the real work. Often these are 6 or 7 levels deep, and I need to track up and down the calling tree making changes en route. The recursive ‘point and edit’ mechanism is absolutely ideal for this; coupled with the excellent search/replace mechanism it can be a huge time saver.

Our standard routine for rescuing crashed workspaces is to ask the user to run a CRASH function which kills the ⎕LX and does a )WSID CRASH and )SAVE. To be able to load this up, hit the <trace> key and immediately see a stack of windows with the suspension at the bottom … then to be able to back up the stack to the point where safe resumption is possible … to execute lines of the suspended code in any order … all this can not only be a time-saver, it could come close to being a life-saver!

We try to move responsibility for systems round the department, which means a lot of time is spent ‘picking up’ someone else’s code. I tend to do this by stopping it at strategic points and making sure I understand what the data looks like, and what the functions are doing to it. The APL*PLUS stop and trace mechanism is so cumbersome (and dangerous if you forget to ⍬ ⎕STOP 'FOO') that I usually just stuff a line of ⌹⌹⌹⌹⌹s into the function I want to stop. Dyalog’s trace windows completely eliminate the need for ⎕STOP, ⎕TRACE, S∆, T∆, and are a superb and much safer way of exploring code.

I hope that gives you a flavour of the places where the Dyalog environment scores over any of our current APL systems. It beats mainframe APL out of sight on both functionality and ease of use; APL*PLUS II comes close in functionality, but is hopelessly outclassed on ease of use; APL2/PC remains an unknown quantity at present, but is sure to be vastly improved when release 2 is announced.

Nitpicker’s Corner¶

Here, in no particular order, are some of the things that annoyed me with Dyalog’s environment:

• The installation is wonderfully simple, but leaves off half way. It really ought to set up the UK keyboard driver, and either load the APL character set or create a suitable batch file for you. The average hacker will ignore the manual, and simply go into the dyalog directory and type APL. He will be faced with a plain blue screen, and will find that whatever he types, said screen remains obstinately blank! The more enterprising hacker will try )OFF, but will fail because the ) is actually on shift-2 due to APL thinking that we are on a US keyboard!! I hereby nominate for the BAA Outstanding Achievement Award the first man to get out of this situation without a reboot.
• The APL character set is not nice. The ⍳ looks as if it has had a bad night on the tiles, and the ⍴ is barely recognisable. When you are majoring on visual appeal and programmer productivity, the readability of the APL symbols matters. OK, you can fix it, but you shouldn’t have to.
• The default colour scheme is awful. Even John Scholes was heard to apologise for it at the recent Vendor Forum. It is so easy to fix this … e.g.

V249: 255 11      + marked line           Cyan
V250: 255 2       + session               Green
V251: 255 46      + Status Line           Yellow on Green
V252: 255 63      + Suspended Function    Yellow on Cyan
V253: 255 62      + Pendent Function      White on Cyan
V254: 255 95      + Edit Function         White on Magenta
V255: 255 126     + Tagged block          White on grey

… so why continue to ship the product with something as bad as this. It is not just a matter of taste … there are ground rules for display design and good use of colour, and Dyalog have broken most of them! - I object in principle to packages which assume they can take over your PC. I reckon that a key labelled ‘Page Up’ should Page Up, not throw you into an editor. Of course there are plenty of worse offenders (Oracle Corp. to name but one … they use Delete as ‘delete record’), but I can’t get comfortable with the way Dyadic have annexed the cursor pad. Nor can I face the thought of patching the keyboard tables to fix it!

Enough! What Dyalog need is the services of a professional moaner who is not so close to the product that he is quite unable to see its faults. In spite of the above paragraphs, I really do like this system; it is just frustrating to think how much better it could have been presented, and with so little effort.

Where it Could Go Next¶

Here are a few things on my personal wish list:

• an option to overwrite the session ‘in place’ rather than always echoing changes to the bottom. I like to work with a bunch of commands on the same bit of screen, and I don’t give a damn if I lose the log in the process. I tend to use APL*PLUS II with ‘dragdown off’ and APL*PLUS/PC poked so that it doesn’t clear the line before output. This is untidy, but saves scooting around with the cursor to find the line you want to re-execute.
• mouse support. How about click for execute, double click for trace, right button for edit? Click on the top corner of the window for exit. Sounds silly, but the mouse is a much faster pointing device than the cursor keys, and for exploring a function stack it would be ideal.
• some of that stuff John showed us for watching variables (see my notes on the Vendor Forum on page 64). The beauty of this kind of environment is that you can keep throwing things in without adding any complexity to the user-interface.
• please can the keyboard and screen customisation be a little easier?! Maybe we can have a sensible keyboard layout to start from? Surely we can leave the mainframe behind and put the [] on the [] keys ?? How about a little workspace to sling up a keyboard map on the screen, and allow ‘point and grunt’ editing of the keyboard tables?

Epilogue¶

As I said at the start, I am in no way competent to review this product; all I can do is note down some of my reactions to it, and my feelings about it. It is obviously APL’s first real step into the 1980’s, and as such has no serious rival at present. The economics look good, and the development environment alone gives this APL a significant lead over its two main competitors. It has some rough edges, but they are all easy to fix and I’m sure they will be.

The important thing is that the concept is dead right, and the basics are done consistently and well. I look forward to seeing where Dyadic take it from here, and how STSC and IBM respond.