Rexx's strengths and weaknesses

Readers may like to know what I found the advantages and disadvantages of Object Rexx to be. Starting with the latter:

1. expose. Instead of declaring all instance variables at the head of a class definition, they have to be exposed at the start of each method, or at least those used by the method do. This makes it harder to see what instance variables a class has, and less convenient to change the name of a variable consistently.

2. Type-checking. Compile-time type-checking would have enabled us to catch many errors earlier, though it might have made some parts of the run-time system harder to write.

3. Efficiency and reliability. We started off using the DevCon version 6 of Object Rexx, then moved to DevCon 10, and finally to that distributed with Merlin. There were several situations which provoked Rexx into giving an OS/2 register dump, with absolutely no attempt made to provide any other diagnosis. This may be OK for OS/2 systems programmers, but it does leave the rest of us rather in the dark. One cause we eventually tracked down was deeply-nested instance-creation expressions, such as

   .C~new~~setContents( .WebObjectContents~of(
                          .C1~new~~setContents( .WebObjectContents~of(
                                                  .C2~new...
                                              ))
                      )
   

   We circumvented this by making the code generator break such expressions down into several assignments, using temporary variables to store intermediate results. This bug may by now have been fixed, in which case it has been no more than a temporary annoyance.

   More seriously, even under the latest Merlin Object Rexx, it seems that the number of instances that can be created simultaneously is much smaller than one would expect from the amount of memory available. As well, execution speed decreases markedly as instances are created, even if only one is being accessed at a time. Graham Stark has suggested that adjusting process priorities may help with the speed problem, but we do need further help on this.

4. The politics of Object Rexx. Although almost all of this paper has been concerned with purely technical issues, there is one political problem which has more bearing on our use of Object Rexx than any single technical one. This is so important that it would be wrong not to mention it: it alone means that an Object Rexx version of WOM is useless.

   We found, when we started investigating Object Rexx and its efficiency in late 1996, that it was getting less whole-hearted support from IBM than we could have wished. Although the development team were personally very helpful, I found it extremely difficult to discover how long IBM would continue to support Object Rexx for, how much effort they would devote to optimising it and clearing bugs, and so on. It was notable that the IBM Web pages that announced Merlin at this time said almost nothing about Object Rexx. It is, I hope, not unreasonable to say in the revised post-conference version of this paper, that other conference delegates were also worried about future support for Object Rexx. Some felt that IBM top management does not wish to devote many resources to Object Rexx, and that this has hindered its development.

   This has been a big problem. Firstly, IFS software must be reliable under heavy load and while sharing the server with some large modelling programs. It would not be good if the server were to crash on Budget Night, for example! But even four months before Budget Night 1996, we could not find out what might be done in the way of future bug-fixes and improvements. In the event, we decided not to use Object Rexx for anything other than this prototype teaching experiment, and to stick with Classic Rexx for our main Web applications. In the event, this performed excellently: but of course, it is not suitable for big WOM-style applications.

   Secondly, I should add a personal comment. I suspect, and this seems to be borne out by experience, that very few if any Internet service providers and similar organisations use Object Rexx. I certainly would be unable to justify doing so if I were one, not because it's a bad language (it isn't), but because I would always worry about lack of speed and support. Consequently, in its present form, WOM is practically useless; until it is translated into some alternative language, my work on it has been almost entirely wasted.

   All this would not matter if there were alternative non-IBM implementations of the language. But as far as I know, there are not. IBM do have an implementation for Windows, but it is not clear that this would have more support than the OS/2 version. It is also incompatible in a very important way: namely .environment is not global, but there is one copy per process. As indicated just below, its global nature under OS/2 is very important to WOM.

As for Object Rexx's strengths:

1. Long-lived instances. I referred to this above, the ability to have instances which outlive the lifetime of the command file creating them.

2. .environment. This is very handy as a place to store the table which maps session identifiers to instances, and other global information.

3. Method calls with ~~. The expression i~~m calls method m of i but returns i as result. This is unlike the perhaps more normal use of ~; i~m calls m and returns its result. By using ~~, the compiler can generate compact code for creating instances and initialising them in the same expression, as shown in Section 3.3.

4. The ability to convert strings to class names which aren't known in advance (those given in a New$ URL), and to find the corresponding class and instantiate it at run-time.

5. Concurrent method calls and messages. When a Tow session is started, the server sends back a cover page which is constantly updated using client pull, and which continues updating itself until the session has finished initialising. To do this, we create the cover page and then start a message which creates the other instances, thus running the two concurrently.

6. User-defined streams. We used these to construct the server-output stream shown in Section 5.3.

7. The built-in collection classes: tables, directories, and so on.