The First International J User Conference (Toronto, June 24th — 25th 1996)

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

Background¶

The first J User Conference was held in Toronto on the 24th and 25th June. It was very well attended, with 123 people filling the Pharmacy Management Building of the University of Toronto, and also very well organised by Strand Software, the sole distributor of J. Everyone that I met at the conference was friendly and interested to know what I was doing, as well as willing to discuss his own work.

The barbecue on the Monday evening on Algonquin Island was particularly enjoyable in this respect, as with the food, wine and beer everyone relaxed and mingled freely. The university accommodation where we stayed was comfortable and modern, and only a short walk from the conference building; the whole university being very central in Toronto itself. The area round the university is a marvellous mix of coffee, book, food and computer shops with one thing I hadn’t seen before — something rather like a laundromat that instead of having washing machines had computers, I presume for the students’ theses. All in all it was a most enjoyable two days and I will certainly plan to return for the second conference at the same time next year.

The conference itself consisted of two plenary talks followed by parallel talks in two streams. The first plenary, which also served as an introduction to the conference, was by Eric Iverson and during it I was unfortunately busy compiling the final versions of the code for our demonstration in the second plenary, during which I was obviously again too busy to take notes. Of the remainder of the conference I attended mostly the talks about the use of J in conjunction with other software rather than those on the more esoteric aspects of the language, so this account of the conference may be a little one-sided. I have picked three talks that particularly interested me.

Data Rummaging in J — Joey Tuttle¶

Joey’s business is something that I didn’t know existed till the conference. He is a "junk fax" distributor. For clients that have a fax to send identically to a large mailing list his company will handle the distribution. This includes the resending of failures, the logging of unobtainable numbers, the removal of duplicate addresses and, very importantly to them, the correct billing of the client.

The general data analysis is done in J acting on flat ascii files produced by the various automated stages of the process. The disregard of J for the size of the data, its consistent handling of the empty case and its ease of development make it the ideal tool for the job. One thing that came across in the talk was the variety of different formats in which the data arrived and the way in which those formats changed, often with little notice, necessitating a change to the analysis software. The other was the sheer size of the data. Part of the analysis was of an itemised ’phone bill the paper version of which ran to 20,000 pages. However the most instructive thing was the choice of simple format ascii files for the data communication between processes as the most flexible and reliable method. This was reflected later on in Bjorn Helgason’s talk.

Use of J to Manage Large Computer Networks — Bjorn Helgason¶

This talk was interesting to me for two reasons. Firstly it reinforced Joey Tuttle’s message about the use of simple ascii files for communication between asynchronous processes and secondly it gave advice about the development of a complex system using J. Interestingly Bjorn’s presentation package was not Powerpoint, but a J program written with the Window driver, reminiscent of David Piper’s presentation at the BAA GUI development day.

The essence of his approach to network management was that everything that happens on the network should be logged in an ascii file in a specific place on the network — the design of the directory structure is obviously important here — and that J programs should analyse these files. The logs contain meaningful keywords, another thing central to Joey Tuttle’s approach, and the J programs’ analysis of the files is based on these keywords. The J programs are MAPI enabled and if necessary can send mail to alert administrators to non-standard situations. Again following the principle of simplicity in communication, the only protocols used are TCP/IP and FTP, the FTP scripts being generated and run automatically by J programs.

The J of the system is, in contrast to most published J, very simple. It needs to be maintained not only by Bjorn but also by others with only a rudimentary knowledge. Control structures and a consistent naming scheme are used for clarity with all global variables used in a script defined first in the same way as defined constants in a C source file. In general Windows NT is used, in preference to Windows 3.1 or Windows 95, for its greater reliability. A dedicated machine is used for each discrete task, in Bjorn’s words "cheap, stand-alone and left alone". Synchronisation of processes on different machines is done by access to a central control file (as with Clifford Reiter’s fractal and Roger Hui’s prime calculation).

In addition to the subject matter of the talk Bjorn also gave us the benefit of his practical experience in developing J, tips on how best to use the development environment and on the structure of large quantities of code in scripts. To me, a relative tyro, these were useful sidelights.

Using J with ODBC and Delphi — John Baker¶

The title of this talk was slightly misleading as it was nearly all about the OLE interface to J run from Delphi. The simplicity, high capacity and reliability of this was undoubtedly something with which John was clearly very pleased. As he said "What a concept — software that works". He demonstrated a simple use of it in the prime factorisation of the first 1000 integers (in J the verb q:) and the display of the results in a Delphi table control. In the resulting timings only 5% of the overall time was spent in communication, while 85% was spent by Delphi in populating the table.

The code showed the simplicity of the interface. In C the programmer is exposed to the complexity of the variant data structure that is used to communicate in OLE. In Delphi the interface to OLE hides the complexity to a greater extent. However John noted that in the process it loses any J error information. The process of starting a J server and of executing expressions in it was very simple and involved creating an OLE object in the Delphi module and executing its "Do" method with the expression to be executed as argument. The result was an array the dimensions of which could be queried and which could be indexed in the normal way. This is much easier than in C.

John then showed an application using J to calculate sunrise and sunset times. It was very polished and showed something of Delphi’s capabilities. Clearly for the J programmer who wishes to ship easily installed applications with fast user interfaces, and who has access to Delphi, this is a combination that deserves serious consideration.