Memo to:Dr. G.E.Thomas Report of the Working Party on Languages. I draw your attention to my Memo 0f 30.11.81 and I attach a copy. The lack of expertise I commented on then has resulted in a report based on serious misunderstandings of some of the technical issues. Comments on section B ______________________ There is general lack of distinction between the benefits of language design, the benefits of International Standards and the benefits of User expertise. A nebulous cloak of the value of "integration" and "support" is cast lightly over this whole area. The benefits Imp is alleged to gain from "integration" with EMAS is almost entirely a myth. Similarly efforts devoted to providing better "integration" of Pascal and Fortran will be largely wasted unless the International Standards are abandoned. Imp has very much better features for non-numerical programming than either of the other languages considered in depth. Interfacing a program or package with a command orientated interactive operating system is almost entirely an exercise in non-numerical programming and thus Imp scores heavily. These are the right and proper benefits of using a well designed language suitable for the job in hand and not the result of some secret rite of integration denied (by a conspiracy of system staff no doubt!) to Fortran and others. To extend Fortran and Pascal within the Standard can only be done by adding library routines; this does not affect the language and the effects are likely to be small. Store mapping is a language feature and not available by procedure call. Much non-numerical programming is done with strings and Imp strings(although annoyingly restricted to 255 characters) are more powerful and flexible than those in Fortran or Pascal. Library routines can not help here especially if the parameter passing of the relevant language is fundementally inadequate. Fortran can not be extended without destroying compatability. Pascal could have better strings (and even store mapping added) but would then become a rather worse local language than Imp which is supposed to be phased out. I am pleased to see that the report admits that the initial enthusiasm for Pascal was overdone. Nevertheless it has not yet returned to anything approaching an objective view of its merits. John Barnes is much better qualified than any of the working party to make such a judgement and his very different assesment is attached. Pascal is fine for teaching but little use for anything else away from UCSD systems. Comments on Section C _____________________ Paragraphs 1 & 2 of section C have serious technical errors and must be revised or deleted before publication. The difficulty of porting compilers to Emas is due to Emas's requirement for sharable, position independent object code. This is a natural consequence of a virtual file system and has immense performance advantages as recognised by Arden & Galler as long ago as 1964. However few systems apart from Multics and Tenex have this requirement so importing compilers from other sources requires extensive modification or slow and costly post processing. ERCC designed compilers have been very satisfactory; many have required much less than 1 man year of effort(eg Imp, Algol(E) and Simula) and have had very low maintenance costs. The report should explain why this method of obtaining langauages has been so decisively rejected. Paragrapgh 2 is nonsense. Imp has had no access to heap or concurrent processing packages. I am not aware of any such packages on EMAS. A screen control package has recently been written but it has certainly arrived too late to explain why Imp is so popular or why users are using Imp when (in the working party's view) they should be using something else. Ada should certainly be investigated but the misplaced enthusiasm for Pascal should not be redirected at Ada. An early, properly certified, compiler is highly desirable but only joke Adas are available at present and are probaly not worth the ERCC parting with cash. The likely restrictions and drawbacks of a language designed for embedded systems together with the likely performance and paging penalties of so large a language should be evaluated along with its advantages. The earliest impact of Ada seems likely to be in the large package scene (ie on Fortran) rather than for non-numerical or system areas(ie Imp) Its role would thus be in addition to rather than replacing Imp and Fortran but in may well replace Pascal if compiler performance is adequate. (The Ada designers would writhe at their terminals if told that "UCSD offers an excellent subset of Ada". This unfortunate malapropism should be deleted) Comments on conclusions and Appendices _____________________________________ The vague suggestion that better integration is a means of improving languages is a fable and insulting to those who have worked very hard in the difficult and unrewarding areas of specific language support. The working party should note the scale of the effort to design and implement a new in processing monitoring scheme. This was mounted in October 81 to investigate the behaviour of Pascal and EdQs under teaching loads. THe outcome enable substantial improvements to be made to EdQs and some useful gains for Pascal. This effort involved 4-5 staff for some weeks and is comparable with all the system effort devoted to Imp on EMAS2900 including the writing of the compiler! Specifics for each language within the relevant standard should be substituted for each recommendation about "Integration". Its has been ERCC policy since the demise of 4/75s to discourage the use of Imp for applications and the only Imp course ever offered was to the GPO. The working party is free to recommend continuation of this policy but it should make it clear that the language has achieved its present popularity in spite of these measures and its seems unlikely that continuing them will make the phasing out of Imp any easier or more popular. The case for implementing as opposed to importing languages does not seem to have been considered. The ERCC is actually rather good at writing compilers and such compilers as it has written have given long service with minimal maintainance costs. This seems to apply particularly to Pascal if we are to continue pushing it towards our rather indifferent user population. I might even be prepared to do this subject to some pretty stringent guarantees to prevent the UCSD freaks getting in on the act. Conclusion 3.4.2 should terminate after 8 words. Removal of the limitations is a formidable matter and is not likely to be attempted before feedback from Ada experience is available. This is likely to be a long way outside the 5 year timescale the report is considering. The case for down grading the Algol support is unanswerable. However let it be noted that this compiler was written in less than 10 weeks and has required minimal maintainance. It has had 5 years hard teaching use at Kent and some use here. It has been sold to ICL at a price which has covered all relevant costs many times over; This hardly supports the contention that it is cheaper to buy in langauages. The case for downgrading support for Imp is nonexistent. It has been used by 49.8% of all ERCC users(Including non-EMAS ones) and as such needs continuing advisory expertise. Further, the position after 2972s is unclear but if ICL-Fujitsu architecture comes to anything Imp may well be around for many more years. An alternative timescale for phasing out Imp is needed to cover this contingency. (Or has the issue already been decided?) My conclusions on the working party ___________________________________ The present report should be filed in a dark corner. (Alongside the 20 volumes of EMAP documents would be a very suitable place.) If publication is intended then the obvious errors should be corrected. Any report which does not accept that the persistent atractions of Imp and the lack of enthusiasm for Pascal are overwhelmingly a matter of langauge design will not be taken very seriously even if it makes valid points (As it does). There are also two more general areas which should be reconsidered. A). The public position of the ERCC is that the replacement of the 2972 with a further ICL offering (&EMAS) is very much under consideration. The report assumes quite clearly that EMAS will have departed well within the 5 year view it claims to be taking. If this assumption is false the then all the conclusions about Imp are undermined or demolished. The Director should give the working party clear guidance on this issue. B). The other unstated but persistent underlieing theme is that Imp owes much of its position to support and publicity from the EMAS team which is denied to Fortran and Pascal. This suggestion is the complete converse of the truth. Imp has suffered benign neglect for years - look at the state of the language Manual. Effort has been poured in to areas such as dynamic loading Fortran with common areas, paging measuremenst and catergory tailoring to suit Pascal and so on. This aspect of the report reflects seriously and quite erroneously on the conduct of the EMAS team and particularly myself. Again clear Directorial intervention before publication is essential if serious and lasting resentment is to be avoided. On a final personal note, I regret and resent the amount of my time that has had to be devoted to this issue including soothing ruffled feathers and writing this paper. Other important matters like the 2988 and the further PERQ work have been pre-empted. My clear warning to the Director on 30.11.81 deserved to have been taken more seriously. P.D.Stephens