EISEYIER
Computer
Standards
& Interfaces
18 (1996)
291-294
Controversy and opposition Bill Leonard Harris
Computer
Systems
Dioision,
2101
W. Cypress
Creek Road,
Fort Lauderdale,
FL 33309,
USA
Abstract One of the major causes of delay in development of Fortran 90 was significant opposition to the proposed changes. This article discusses the origin of that opposition. The controversy surrounding Fortran 90 is explained in terms of the historical background of the Fortran language, the composition of the Fortran user community, and the evolution of the computer industry. This article also offers some advice for avoiding such controversy in the future. Keywords:
Standards
development;
Controversy
1. Introduction One of the major causes of delay in development of the Fortran 90 standard was significant opposition to the proposed changes and controversy over how the standard was being developed. This opposition came from both the user community and the standards committee, X3J3, itself. This article attempts to explain some of the causes of the opposition to Fortran 90. It presents one person’s interpretation, but perhaps it will help make some of the history more comprehensible. The underlying causes of the controversy and opposition are complicated, but it can be seen that the seeds of the problems were sown by the success of Fortran itself.
programming language in use. A high percentage of computers then being sold to scientific laboratories, engineering firms, and universities came equipped with only one high-level programming language: Fortran. As a result, Fortran was used by a wide assortment of people for a nearly endless variety of applications. To facilitate analysis of the controversy surrounding Fortran 90, it is useful to divide users into four main groups: 0 Maintainers 0 Large-code designers l Language purists 0 Satisfied users Each of these groups is described as follows. 2.1. Maintainers
2. The Fortran
user community
By the time that the Fortran 77 standard made its debut in 1978, Fortran was by far the most popular 0920-5489/96/$15.00
PII
SO920-5489(96)01004-5
0
1996 Elsevier
Science
B.V.
All rights
reserved
Maintainers were the programmers charged with maintaining large legacy applications. Some of these applications had, by 1980, been in use for over a
292
B. Leonurd/Compurer
Standards
& Interfaces
I8 (1996)
291-294
decade. In some cases, they were implemented in Fortran, not because Fortran was the best language, but because it was the on/y language available. Because these applications were usually difficult to change, maintainers feared major changes to Fortran, particularly the removal of any features. They were primarily concerned with maintaining the status quo.
large-code designers generally wanted more change to modernize the language. The desires of these four groups of users were largely irreconcilable. No wonder that Fortran 90 was so controversial!
2.2. Large-code
While X3J3 was attempting to change the language officially, the Fortran language was evolving unofficially. Computer vendors, who prior to the mid-1980s were almost the only source of compilers for computer languages, were frequently asked by their customers to provide extensions to the language. Some of these extensions were specific to a particular computer system or application domain; others were generally useful constructs (such as DO WHILE) borrowed from other languages. Vendors acceded to these requests if the features seemed useful enough to their customers or if the requesters were willing to pay for them. The existence of extensions also contributed to the controversy. Users of those extensions naturally wanted them to be standardized, so that they would continue to be available. Others thought that the extensions were not well designed or that they constituted poor programming practice; they opposed inclusion of the extensions in the standard.
designers
Large-code designers included scientists, engineers, and programmers who were developing largescale scientific applications. These applications generally manipulated large arrays of numerical data. These users thought that Fortran’s greatest asset was its treatment of arrays. They chiefly wished to extend Fortran’s array capabilities to better match the capabilities of supercomputers. However, they also thought that Fortran would benefit from the addition of features that aided in data abstraction and features that made developing large applications easier. ’ 2.3. Language
purists
The language purists many features that they ming practice. ’ Rather posed such new features same reason.
wished to purge Fortran of regarded as poor programinexplicably, they also opas DO WHILE loops for the
2.5. Vendor
2.6. A moving 2.4. Satisfied
extensions
target
users
Satisfied users of Fortran composed the fourth group. Some of these users wanted a few minor additions to the language. Most of the desired additions consisted of widely-implemented extensions. All wished to see the nature of the language remain largely unchanged. Another way to characterize Fortran users is as conservative or modernist. The maintainers and satisfied users were chiefly conservative, desiring as little change as possible. The language purists and the
’ MODULEs and user-defined types are examples ’ Features such as COMMON and EQUIVALENCE garded as archaic and difficult to maintain.
of these. were re-
Besides the diversity of the Fortran market, the rapid evolution of the computer industry and software technology contributed to the controversy. During the time that Fortran 90 was being developed, the computer industry made the transition from proprietary computer architectures to open systems, thus making portability of programs much more important but also much easier to achieve. Many of the concerns ’ expressed by the modernists were rendered groundless by the advent of open systems and the availability of compilers from many sources other than the hardware vendors. Simultaneously, many of the existing extensions became unnecessary.
3 One big concern was vendor’s version of Fortran
getting
“locked
in”
to a particular
B. Leonard/
Computer
Standards
During this same period, software technology abandoned the procedural paradigm in favor of data abstraction. This period also saw the beginning of the object-oriented paradigm. With this shift, the need for some language features diminished while the need for others increased. It is not surprising, then, that X3J3 found it difficult to hit such a rapidly moving target. X3J3 was trying to serve a diverse group of users who were making radical changes in the way they programmed! 2.7. Indecision
& Interjiaces
18 (1996)
291-294
293
more, it would be harder to add all the extensions that their users would demand, thus further decreasing the market for the new compilers. * In fact, all of the factions delayed the standard by failing to reach a reasonable compromise. No one group should bear the blame for its delay nor take the credit for its approval. In any case, the dissension within X3J3 was simply a reflection of the divisions within the user community itself. The comments generated in the Public Reviews indicated the level of disagreement over what Fortran should become.
reigns 2.8. The final
Unfortunately, X3J3 tried for far too long to please everyone. Pleasing everyone was probably an impossible task. In fact, the resulting delay in completion of the standard displeased nearly everyone. As the controversy raged on, each faction in the user community became more impatient and less tolerant of other viewpoints. Because X3J3’s membership reflected the various factions, X3J3, too, became polarized. Those members who favored modernizing the language by both adding and deleting features were directly at odds with those whose primary concern was compatibility. The modernists accused the conservatives of attempting to sabotage the standard, and the conservatives accused the modernists of exceeding X3J3’s charter by designing a new language. There was probably some truth in both accusations, but the primary result was indecision and delay. A charge frequently heard in X3J3 meetings was that the computer vendors were primarily responsible for the delay. This might have stemmed from the fact that many of the vendors were in the conservative camp. It might also have been a form of retaliation for having been locked into a particular vendor’s version of Fortran. Vendors, however, were the one group within X3J3 who would be most dramatically affected financially if the standard were a failure; they could hardly be blamed for preferring less change. They were concerned that adding many new features would necessitate developing completely new compilers instead of extending their existing Fortran 77 compilers. Developing new compilers would be very expensive. If the new language proved to be less popular than Fortran 77, it would be much harder for them to recover their investments. Further-
product
The product of all of the controversy surrounding Fortran 90 was a language that satisfied none of the various factions. Conservatives condemned it for providing multiple ways to do almost everything, thereby creating unnecessary complexity for both compilers and users. Modernists berated the continued existence of such ancient features as COMMON and EQUIVALENCE as well as the lack of such features as parameterized user-defined types. Dissatisfaction does not mean that Fortran 90 will not be successful. Now that compilers are available, the Fortran 90 user community is fairly large and will no doubt continue to grow. It is highly unlikely that Fortran 90 will ever enjoy the use that Fortran 77 did, but it may be the language of choice in the high-end number-crunching field of computing for some time. The transition of Fortran from general to more specialized use may be lamented, but whether Fortran 90 is the cause may be debated.
3. Conclusions
Despite Fortran 90’s existence, use of Fortran for new development has continued to decline in the computing industry. Some would say this is because Fortran 90 went too far, while others would say it is because Fortran 90 did not go far enough. Possibly both views are correct. Had Fortran 90 been a more
’ Some vendors have already announced that their Fortran compiles will not contain all extensions found in their Fortran compilers.
90 77
294
B. Leonard/Computer
Standards
conservative and timely revision, some users would not have switched to other languages because of feared incompatibilities. Had it been more innovative, perhaps fewer users would have been lost to Ada and C + +. No one will ever know. The controversy over Fortran 90 stems from the success of its predecessor, Fortran 77. However, Fortran is not alone in this regard: Cobol also underwent a painful revision during the same period, although the controversy was a bit more subdued. The emerging C + + standard is undergoing similar controversy because of its close ties to the C language. Such pains are probably inevitable when revising a language that is widely used to accommodate significantly different programming methodologies. One critical lesson that can be learned from the Fortran 90 experience is that revisions to language standards need to be made in smaller and more timely increments. This minimizes the effect on industry, compiler vendors and users, and makes the transition to the new language smoother. X3J3’s current efforts at revising Fortran 90 recognize this need, but it remains to be seen whether any committee made up of volunteers can be sufficiently focused to achieve a small and timely revision. Moreover, it must be realized that standards cannot reflect the state of the art. A good standard of the complexity of Fortran 90 needs at least two years of review after all language features have been estab-
& Inteq3aces
I8 (1996)
291-294
lished. At the rate that software technology is advancing, a standard may be several years out of date at the time it is issued. That is simply the price that must be paid if we wish our language standards to be consistent, coherent, and above all, achievable. Finally, it should also be recognized that the primary reason for revising an existing language, rather than inventing a new one, is to protect the investment in existing code, compilers, and programming skills. Radical changes to a language do little to further that goal; compiler vendors must often completely redesign their software, inevitably resulting in incompatibilities with old code. In the long term, creating a new language, which is perhaps somewhat compatible with the old, may be a better choice.
Bill Leonard (
[email protected]. harriscorn) received his B.S. in Computer Science from Tennessee Technological University in 1976 and his MS. in Computer Science from the University of North Carolina in Chapel Hill in 198 1. He has worked for Harris Computer Systems Corporation for 11 years, on development of Harris’ Common Code Generator, various compiler front ends and on development of Harris’ NightView multi-language debugger. Bill has also taught Comnuter Science and Mathematics course :s at Nova Univer&y, and before coming to Harris. he worked for NCR. Data General. and Gould Comnuter Systems ‘in various development positions. Bill served on the X3J3 Technical Committee for Fortran from November, 1987 until March, 1994.