From rinehuls@access.digex.net Mon Aug 19 19:09:22 1996 Received: from access2.digex.net (qlrhmEbBUV1EY@access2.digex.net [205.197.245.193]) by dkuug.dk (8.6.12/8.6.12) with ESMTP id TAA18630 for ; Mon, 19 Aug 1996 19:04:44 +0200 Received: from localhost (rinehuls@localhost) by access2.digex.net (8.6.12/8.6.12) with SMTP id NAA17017 ; for ; Mon, 19 Aug 1996 13:04:33 -0400 Date: Mon, 19 Aug 1996 13:04:33 -0400 (EDT) From: "william c. rinehuls" X-Sender: rinehuls@access2.digex.net To: SC22docs@dkuug.dk Subject: Document SC22 N2245 Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII ISO/IEC JTC 1/SC22 Programming languages, their environments and system software interfaces Secretariat: U.S.A. (ANSI) ISO/IEC JTC 1/SC22 N2245 August 1996 TITLE: United Kingdom Contribution on Effective Management of SC22 Projects SOURCE: Secretariat, ISO/IEC JTC 1/SC22 WORK ITEM: N/A STATUS: N/A CROSS REFERENCE: SC22 N2129, N2228 DOCUMENT TYPE: United Kingdom Contribution ACTION: To SC22 Member Bodies for information. THIS DOCUMENT WILL BE DISCUSSED UNDER AGENDA ITEM 11.2 AT THE SEPTEMBER 1996 JTC 1/SC22 PLENARY. Address reply to: ISO/IEC JTC 1/SC22 Secretariat William C. Rinehuls 8457 Rushing Creek Court Springfield, VA 22153 USA Tel: +1 (703) 912-9680 Fax: +1 (703) 912-2973 email: rinehuls@access.digex.net __________________________________________________________________________ From: "Stride, Jean" <100434.3031@compuserve.com> UK Contribution on Effective Management of SC22 Projects Programming and Specification Languages In applying the principles of N2129 (JTC1 N4079) to SC22 projects, the following points should be taken into account. 1. Unlike most standards, programming (and specification) language standards apply to two kinds of product: implementations of the language, and programs written in the language. A producer of the second kind of product is a consumer/user of the first kind of product. For each installed copy of an implementation there will correspond possibly dozens of programs. For each implementation there will correspond hundreds if not thousands of programs. Hence a standard for a "minority" language of apparently low "market validity", as measured by number of implementations, can benefit many businesses and organisations, and large numbers of individuals (both programmers, and users of the programs they write). 2. There are many languages with significant levels of use world-wide, only a limited number of which are the subject of SC22 projects. Commonly, the demand for a standard has arisen within the community of language users and implementers themselves who have then provided the resources to produce it. SC22 language standards can therefore be regarded as having been pre-selected for "market validity". 3. Languages are in general complex entities and the standards for them are correspondingly large and complex. This accounts for the usually long period between establishment of the standards project and publication of the standard, but it also means that a considerable time is likely to elapse before there is a visible impact on the relevant market area - measured in years rather than months. Implementations take time to produce, training courses take time to develop, text books take time to write and to publish. Even once these have appeared, take-up is likely to be gradual since the uses within the language community will have different migration patterns, depending on their needs. Any assessment of "market validity" of a language standard must take account of them. 4. Languages are, on the whole, general purpose tools. Even if originally designed for particular purposes, experience in the use of a language often leads to its application in unanticipated ways. Many factors are involved in this, and standardisation is one. This adds to the difficulty of assessing or predicting "market validity". 5. Once established, languages are, in IT terms, long-lasting. Implementations change as the platforms on which they run change, programs change (usually more slowly) as user needs change, but the languages themselves continue. They get revised, to reflect new needs and expectations, but in essentials remain unchanged. This too means that SC22 projects need to be judged over a much longer timescale than is likely to be expected for many JTCI projects. 6. SC22, and its predecessor TC97/SC5 which itself grew out of TC97 ad hoc group E, has a history which can be traced back continuously to the very beginning of IT standardisation in the early 1960s. SC22's long history and the longevity of its standards has led it to face questions of management, maybe earlier than most. This long experience, often hard-won, has been passed on over the years and some of it has been captured in sets of guidelines, published as TRs and hence available for new projects within SC22 and for projects of a similar nature elsewhere. Management in the sense of N2129 has been learned and exercised in SC5/SC22 for over twenty years. It has always operated in the market, i.e. the programming languages community, and its language standard projects have always been conducted with good visibility within that community. 7. SC22 closes down further development in certain projects - e.g. for PL/I, Full Basic and Pascal - and disbanded the relevant WGs. (The same had done for Algol 60 before it got withdrawn altogether.) Usually, a residual project editor is left to handle any queries. This allows interpretation requests to be answered and in principle would permit technical corrigenda to be issued, but no more. Any further development of any of these would require an NP to JTC1 which would be likely to fail. We do not regard it as acceptable in our area to cancel a project completely once development stops: unfashionable, apparently "faded away" languages do still have sizeable user communities, long after one might think there would be any need for the standards. This again is a consequence of languages being long-lived, having many users, and having millions of lines of legacy code still in use. The cost of keeping such "faded away" standards in being is negligible, yet is still valuable to the user communities concerned. 8. SC22 does withdraw projects that have genuinely "faded away", e.g. by recommending withdrawal of the standards for Algol 60 and Minimal Basic, though this happens only when it is known that there is no remaining benefit. 9. SC22 routinely conducts consultative letter ballots within the SC on proposals for new projects or project extensions. Project divisions to produce multipart documents are scrutinised by SC22 (though the UK would like this scrutiny to be more rigorous in future). General The danger of the "market validity" appraoch is that it may be applied too crudely, simply using the things that are obvious and relatively easy to measure. Point 1 above shows that the number of conforming implementations of a standard is not an adequate measure. Even if there are no conforming implementations at all, conforming programs will still in general be easier to move to a different platform, since they will not use vendor-specific features. With a particular non-conforming implementation, the standard provides a yardstick against which it can be measured: programs rarely use all parts of the language, so any parts that are not correctly implemented can often be avoided, or the effects documented and allowed for. Sales of a standard are also not an adequate criterion: high sales certainly denote validity but low sales do not necessarily mean lack of validity. Language standards are large, complex documents, and hence extremely expensive. Many users cannot justify the expense: programmers learn from textbooks that teach the standard language, or courses, or using a conforming implementation and its documentation. Furthermore, using the standard promotes shared learning and transfer of skills, even without any conforming implementations. All these substantial economic benefits contribute to the market validity of a standard and need to be taken into account. Other Projects SC22 is also responsible for a limited number of additional projects, language-related but not themselves for language standards. The guidelines TRs have already been mentioned. The others can be divided into language-independent standards, internationalisation, and services and utilities. The language-independent standards are enabling standards, not product standards. They will not, directly, lead to conforming implementations. Rather, they provide an infrastructure, able to be used for future projects, which it is difficult to see could be provided in any other way than by standards. They are new, and by their very nature will take a considerable time to bear fruit. The internationalisation area is recognised as one of high importance. It is also of immense complexity. SC22 has monitored progress to try to ensure that it remains focussed. It is important that this should continue. The service and utility projects in SC22 are currently in two areas: PCTE and Posix. PCTE has only recently arrived in SC22 by fast track, like other SC22 projects is quite complex, and hence also will need time before it can fairly be assessed. The Posix standards are developed in IEEE, so SC22's role is primarily one of coordination, and providing comment from an international perspective. In the decade or so that has elapsed since this large and complex project was brought into SC22, management has been exercised, rather than the IEEE work being taken lock stock and barrel. This is shown by the fact that the SC22 Posix projects are organised differently from those in IEEE and not all the IEEE projects appear there. Again, it is important that scrutiny should continue, in SC22 as well as, in more technical detail, by WG15. Confusion, disagreement and transfers of ownership in the Posix-related world of Unix have until recently rendered assessment of the Posix programme premature, but the time is approaching when a comprehensive review will be desirable. ______________________end of document SC22 N2245 ______________________