Future Directions in Programming Languages

FUTURE DIRECTIONS IN PROGRAMMING LANGUAGES

Samuel A. DiNitto, Jr.

Rome Air Development Center Griffiss Air Force Base, New York

Abstract; This paper explores some language's success, it is more often possibilities for the programming the inertia and politics of its languages of the next century. competitors that must be overcome Projections are based on what has and rather than its relative merits. In has not been accomplished in the last the world of programming languages, four decades and the programming tools inertia is measured in the amount of proposed for the next decade. software already built in a language Influencing programming language and still in use, the number of people directions at both the high levels of trained and actively using the software development (e.g., problem language, the number of popular decomposition) and at the lower levels language sensitive software development (e.g., algorithm implementation) will tools for the language, the be parallel execution. There could requirements (both past and current) (finally) come a serious break with the for the use of the language in specific traditional languages such as Fortran, applications, and other such culture Algol, PL-1, Pascal, C, and Ada. Very considerations . Similarly, "politic s " High Level Languages could take over in is concerned with such things as popularity. Within an increasing authority and scope of authority of number of domains, the programming, in those who require the use of a addition to man-machine interfaces, language, the stature of those who will be accomplished through multiple endorse the language, and the power media (VHLL, speech, natural language, (often me as ur ed as mouse, menus, touch screen, etc.). "share-of-the-market") of those responsible for the origination of the language.

Thus, "inertia" covers those items that must be overcome, and "politics" I. Intrduction covers those that must be obtained to begin building significant inertia. As This paper explores some strong (at examples, FORTRAN and COBOL have much least in the author's opinion) inertia and in the past have had strong candidates for the Programming political backing by Government and languages that we will see in the next Industry: in the past, Pascal has century. For this purpose, received strong academic political "programming language" is defined as endorsemnt but has developed little any language used to create a set of inertia: and Ada has seen mixed instructions for a computer to follow political endorsemnt, but is now in carrying out a task, a framework enjoying a rapid buildup of inertia. to use in solving a problem, when that solution is storable for future user In synopsized form, the present It attempts to do this by reviewing how s tate-of -af fairs is simply this : The we have arrived at today's popular procedure oriented (or imperative) programming languages, and identifying style of languages (FORT", Pascal, c, the relevant practical experience ALGOL, PL-1, BASIC, Ada, etc.) still gained from that history. The history rule the roost with regard to will be used with the state of today's popularity, and most of these languages research and expected future successes (when we include all their dialects) to temper the ideals for the next are still increasing their inertia, generation of programming languages. although the relative share of the market is decreasing for some (e.g., This pragmatic author believes the various dialects of ALGOL, PL-1, that, with regard to a programming FORTRAN, etc.). The functional (or

U.S. Government Work. Not protected by 169 U.S. copyright. applicative) styles, such as LISP, and approaches like John McCracken's the logic styles, such as Prolog, are Autocoder for FORTRAN. seeing a resurgence of activity (at least in the R&D world) due to the During these times, very few places renewed interest in artificial had more than one computer system 01 intelligence in the last decade and the had the means or inclination to fund so-called Fifth Generation and more than one. Also, applications were Strategic Computing thrusts. We see becoming more and more diverse. . This some successes for the application meant there was a need for a practical, specific, or very high-level languages general-purpose language to span the (VHLLs) , styles in business scientific, business, and real-time appl i ca t ions , too1 ing , aut omt ed t es t (largely for DOD applications) equipment applications, and even communities. However, the world did AI/expert systems applications; but in not leap at a very good one for the the big picture, the use of such times, namely, JOVIAL , whose languages is not universal, even within implementations came on the scene in their narrow domains, so they have not the early 1960's [SAMM 69, pg. 5301. really caught on yet. JOVIAL, for Jules' Own Version of If one accepts the above view of the International Algebraic Language, where we are, let's now try to built on the structure and controls in establish how we got here. This may Algol-58. It added tables and arrays, allow us to determine what we can learn capable of being packed at the bit from a historical perspective that may level by programmers, or at the bit, be relevant for our future projections. byte, and word level by the compiler. Status, literal, Boolean. and user Most people acknowledge that it was specified fixed-point data types were really the language FORTRAN, in the also added. The language enforced its 1956 timeframe, that seriously kicked typing rules, but on a case-by-case things off for the computing world in basis a programmer could alter them. general. In the next five years, The DEFINE facility allowed one to almost everyone in the computing isolate machine dependent parameters community had at least heard of COBOL, for easy redefinition when porting to ALGOL, LISP, and possible NELIAC, but another machine. COMPOOLS of shared how about the other five dozen data, programs, and their languages? Five years after that specifications allowed the compiler to (i.e., 1966). in addition to the correctly integrate and/or help debug numerous dialects of the previously software developed by multiple named languages, computer people at programmers. Finally, if all else least heard of PL-1, SNOBOL, JOVIAL, failed, the language allowed one to and BASIC, but not too many heard of fall directly into assembly language to the other eight dozen languages accomplish what could not be available [SAMM 72, pgs 606, 6071. efficiently handled at the source level. What more could a programmer of Let's stop here for awhile to make the 1960's ask for?! What went wrong?. some observations about the languages being used to build so-called "fielded" Well, for one thing, while several systems, ignoring the fact that, at of the large mainframers, such as IBM, that time and for at least ten and more UNIVAC, and CDC had some efficient years, most software would be compilers for JOVIAL (most directly or implemented in assembly language. indirectly funded by the Air Force) ; Computers were expensive at that time, while several large, complex, real-time and the programmer who could implement and successful Air Force and FAA software in the fewest (however systems were implemented in JOVIAL; measured) number of words of storage while even commercial applications did was golden. Recursion and block show up (airline reservations) ; and structure were elegant, but both, while the UK's Ministry of Defence especially the former, chewed up copied the JOVIAL style and philosophy storage and machine cycles. The need in CORAL-66, there was no perceived for the programmer to stay close to the support or long-term commitment. After machine's own instructions was evident all, the newer, more modern PL-1 was by the above and the need to debug from being supported by the company with so-called "core dumps" of the binary over two-thirds of the worldwide state-of-the machine's memory and marketplace. Merit and track record registers at selected points. Finally, just did not count for much. People only FORTRAN and COBOL were being using Fortran, COBOL, and/or assembly taught en masse to the people actually language were content to wait until building the fielded systems, and I PL-1 came around, with all the support might add by some very innovative and backing that only the large

I70 mainframers could supply, even though to programming the Von Neumann by the mid-1960's the mst respected computer, and, in this author's software houses (e.g., SDC, CSC) were opinion, in practice, we have not made fielding and supporting JOVIAL that overwhelming improvement in compilers, training, and JOVIAL systems productivity or quality that has been software (including a working promised with the introduction of each time-sharing system). new programming language in this style. If you doubt this, try to develop and Three points can be made at this coduct an experiment that will prove time. First, a language wasn't going the advantages of one imperative to leave the R&D community unless it language over another to the majority's made efficient use of resources. sati sf ac tion. Second, without readily available training, there was little possibility The case for the applicative style of a language gaining popularity. of language on the surface is not much Third, without at least perceived different. The past twenty-eight backing of the hardware vendor(s), a years, since McCarthy's early papers. language was doomed. The limited but have witnessed a gradual inclusion of significant success of CORAL-66 in the the more complex features that students UK and the promising future of Ada are have for years implemented as exercises built on these points. (e.g., APPEND) and the borrowing of some features from the imperative style Other points that became readily (e.g., CASE, DO-WHILE, etc.) much accepted by the canmunity were that earlier than for the imperative styles, people strongly resisted switching to the various dialects of LISP have built another programming language if they up impressive, almost standard, considered themselves proficient in software engineering environments one, and the first language you learned (e.g., Allegro Common-LISP, INTERLISP, forced you into a style of programming LISP Machine Environmnt). If we probe and a perception of computation that deeper into the LISP family, we see was difficult to change. Anyone who that, in comparison with the imperative doubts the above should try to teach languages, the LISP dialects have seasoned FORTRAN IV programmers ALGOL, achieved much more along the lines of Pascal, or Ada (just wait till you get r eusabi 1i ty, truly integrated suppor t to recursion). environments, and a higher level of expressability that improves both The years 1966 to the present are quality and productivity in terms of characterized by the intrcduction of software development. many new languages, most of which died in the research canmunity, or never So why aren't we all LISP gained critical vendor support. The programmers? For one thing, there is focus with the imperative languages still no real support from the big switched in the early 1970's from "give vendors, and the small hardware the programmer the power to do anything vendors, who do seriously support LISP, he might possibly want without do not have a significant share of the encumbrances, such as strong typing or market. For another, there is an even the requirement to learn and understand bigger challenge to turn FORTRAN and the whole language" (PL-1, Algol 68); COBOL programmers to the applicative to "give him a small, efficiently style than to Ada. In addition, the implemented, well-defined language and applicative languages don't yet make protect him from his human frailties efficient use of the computer hardware with regard to programming and those of that is designed to execute them, let other programmers" (Pascal, ALGOL+) , alone the classic Von Neumann to "give him a large, powerful computers. Outside of possibly the efficiently implemented language with best endowed computer science labs and protection mechanisms" (Ada). From those who still believe that right other perspectives, we saw attention around the comer are all the storage being paid to languages (Euclid) or and machine cycles per second we will language features (aliasing) that ever need, at a fraction of our budget, respectively helped or hindered formal this efficiency concern is still with verification. We saw various attempts us. While it is easier to demonstrate at dealing with mass storage progress with applicative languages, (pointers1 , concurrency (semaphores, this author's verdict is that progress mnitors, tasking), real-time cannot hold up to the demands for (interrupts), flexibility (generic data efficiency, productivity, and quality types), etc., etc., etc. The bottom in the market place. line is that, like it or not, in over thirty years, we have merely tweaked in The problem or application oriented an evolutionary way, the basic approach languages in popular use today can only

171 be described as "loosing ground" with software! Now we are on the verge of respect to productivity and quality. FORTRAN 88! One doesn't become a While they tend to make some very pragmatist (or a cynic) overnight. def inite headway when f i rs t employed, their development tends to stagnate So, what are the drivers for a rapidly and they become more or less truly next generation of languages? We frozen in terms of expressability a?d have been hearing this for at least hence productivity. The problem 1s fifteen years, but parallelism (both that they are effectively only a synchronous and asynchronous 1 "st be shorthand notation or macro to be handled directly (and safely) within simply translated to a routine set of the next generation languages. Even assembly or higher level programming with projected successes in hardware statements, and they give little or no technology, it will still fall on assistance beyond that point. This parallelism to provide the computing doesn't have to be the case, but the horsepower for many applications. further refinement of these languages would cost more sophistication and Certain of today's compilers for complexity in their implementations the non-explicitly parallel languages than their vendors will risk. detect the obvious forms of parallelism (nested loops of independent The logic style languages, although operations), but they usually assume fifteen years old, are still in their (because they can't always detect it) infancy. Without the interest of no side effects or aliasing. The Japan's Fifth Generation project and parallelism is not invoked at the hint more recently the interest of the of a problem (e.g., a subroutine call). Defence Advanced Research Projects Agency (DARPA) , these languages would The explicitly para1le1 languages be largely unknown. There are a few of allow for the programmer's declaration us (this author included) who think the of the parallel sections of the potential for this style has just been program. While this allows for more scratched. There are fewer yet (but, parallelism than can be achieved for again, include this author in the few) the nonexplicitly parallel languages, that think the merger of the logic and and thus potentially more efficient use applicative styles offers even greater of the resources, the languages count advantages. While such a smooth and on the programmer knowing what he is aesthetically pleasing language called doing; their compilers cannot detect SUPER (for Syracuse University Parallel all programmer induced deadlocks and Expression Reducer) exists, the races. This problem is of course hardware to efficiently execute it is compounded because such problems don't not yet in the breadboard stage. always show up in testing, and cannot always be reproduced in follow-up 11. "Drivers" for the Next Generation testing once they have occurred during of Programming Languages operation. A truly future generation of parallel programming languages and If it is truly to be a next their implemntations must overcome generation of languages, the new these problems and limitations. generation must catapult us out of this slow evolutionary improvement cycle we Object-oriented design and are in. The slow addition of implemtation has created as much, if evolutionary features, an addition not more, enthusiasm than structured usually thinly disguised by the programming did in the early 197Ols "syntactic sugar'' of a t'new'' language, [Broo 87, pg 141. While certain of will mean that the next century's early today ' s more popular programming languages will mostly be today's languages support some of the essential languages. In 1972, Jean Sammtt [SAMM ingredients for object-oriented design 72, pg 6091 pegg;d FORTRAN's and and programming, namely, encapsulation, COBOL's life span at ..... at least message passing, late binding, and five and probably ten more years." Is inheritance, [WILS 87, pg 53 f fl I they there any among us who doubts they will don't supply them all, or not all to disappear before the year 2000? This the degree necessary. Usually, today's author wrote his last line of FORTRAN approach to object-oriented software is in 1969, threw rocks all during the to design in the object-oriented style, 1970's at those proposing that FORTRAN but to implement the object orientation IV be the language for portable through "project discipline, I' as no software, and finally gave up when in current language imp1 emen tat ion 1985 one of the research products under provides efficient support for this his control was written in FORTRAN 77 paradigm. to guarantee maximum availability - even though the prduct analyzes Ada Another driver for truly new

172 languages is that the role of the space; the amount of change in the "pure 'I programmer is rapidly concept from birth to fielding such a disappearing. More and more, system (three decades brings a lot of businessmen, engineers, scientists, change); the number of people that will etc., are developing or modifying their pass through such a project (loss of own software rather than deal with a corporate memory); and even the programner they probably can't advancement (favorable or unfavorable ) communi ca t e with, because the of technology during the development of programmer doesn't really understand the system. How can we expect to have the application in enough depth. These a "good handle" on such a concept, pople, while computer literate, are evaluate the thousands of alternatives not software engineers capable, nor for interrelated functions of systems, inclined, to put together large subsystems, sub-subsystems, etc., and software systems, of tens to hundreds communicate these concepts to the of thousands of lines of FORTRAN, hundreds of companies that would be COBOL, Ada, or any other similar involved in building the software. A language, requiring dozens of manyears tool, or one would argue a of effort and large teams. They need general-purpose "language, " is needed powerful languages capable of to create maintain an ever evolving expressing solutions and ignoring executable conceptual model of implementation details. They need to long-term complex systems. go beyond today's level of application specific languages which stop at 111. This Author's Prognosis for the reus ing macros and subroutine Future. libraries. They need reuse, but reuse of generalities in addition to With regard to a truly new specifics. They need prompting, easy generation of programming languages in interfaces, protection from obvious wide use to support parallelism by the subtle mistakes, etc. In short, they year 2000, the chances are very slim. need reuse of knowledge. Here, the While there may be better places to line between language and applications start augnenting languages, (e.g., package may seem gray; but if a series Occam), features to explicitly support of high-level operations is created and parallelism will continue to be added stored for reuse, how can one argue to FORTRAN, Pascal, Ada, C, etc. It is that's not a program created with a extremely doubtful a more complete set proqramminq language? of protection mechanisms, to prevent or detect the 'I ove rpar a1le 1 i za t ion" of a On yet another scale, the software program, can or will be developed, and/or system engineers need higher fielded, and massively supported in levels of expressability if we are to this century. Remember that Ada is put together the large complex systems really a 1970's vintage language and, of the Twenty-First Century, in a only because of huge investments by DOD reliable manner. Today, we have design and Industry, and unabashed arm languages, requirements languages, and twisting by the DOD and other NATO even fledgling prototyping languages. defense organizations, is Ada now However, what is missing is the (thirteen years later) a prominent mechanical translation from any one of language. Thus, if the perfect these forms of the software to the next parallel language was already on the phase. We have enough trouble getting drawing board, it is doubtful if it people to learn one new language, let would make it by 2000. While some alone one (or more) to deal with each people argue that efficient Ada phase of the software's life cycle. implementations (in terms of run-time) For years, we have argued that we ma are still difficult today, we can argue keep the human away from the those implementations are almost all implenentation details with the kind of for the same class of machine, the systems we need (and plan) to build; single instruction - single data that means much more than shielding the architecture. The complication in human from the code generated by a getting efficient implementations of a "CASE" statement. new parallel language, and its run-time package on several different parallel To amplify the above, we are also architectures, is much higher than for witnessing a phenomenon that will an efficient Ada compiler strategy for become even more of a problem in the the simple Von Neumann computer. future, namely, the proper development -and maintenance of even the concept for This next projection is easy. a system. Consider the number Of The author has no doubts there be distinct areas of science and a set of efficiently implemented and engineering involved with placing and efficiently executing implementations maintaining a manned space station into of object-oriented languages along the

I73 lines of Smalltalk. Unfortunately if dropping rapidly. A card, not yet on the history repeats itself, we will the open market, can be added to a also see even more efficiently PC-AT to recognize 10,000 spoken words. implemented and efficiently executing In the next five to ten years, it is a variants of today's imperative safe bet that hardware of the class of languages that don't quite do the job. today's best AI workstations, outfitted (Like FORTRAN-77 supported structured with the equivalent boards similar to programming, maybe there will be a the above, will be in the $10K range. FORTRAN-99 for ob jec t-or iented In narrow domains, if we make efficient programming. ) However, vendors appear use of the resources, the application to be latching on to varients Of specific languages can really "take Smalltalk, so there is some hope we off" and fulfill the productivity and won't repeat the past too faithfully. quality promises of the last fifteen years. The application specific languages are finally going to make With regard to the some real headway by the next century. general-purpose languages to put With a little more cmitment and some together large systems (the current in adventuresome spirit by the hardware vogue term is Very High-Level, Wide -and software vendors, there could be a Spectrum Languages), it is almost rash of intelligent very high-level certain that, although direly needed, languages for everything from machine the pragmatic view is that they will tooling to prototyping or even fielding not be available in the early and maintaining C31 systems or twenty-first century. However, for the subsystem components. moment, even though history is against us in programming languages, let's Of course it is knowledge based recognize that in other disciplines, systems technology that will allow this technology projections are usually to happen. The "knowledge" built into overoptimistic relative to actual the analogy to today's compilation progress in the first five years, but process will allow for truly "typeless" pessimistic relative to actual progress language in specific application areas. made in the five-to-fifteen year It will allow for the "skeletal bracket of the future. Taking that routines" purported in the mid-1970's view, there are so many pieces of the as a way of leveraging productivity and theory and technology puzzle being quality by having generic subroutines worked throughout the world that an tailorable to specific requirements, optimist would have to argue all we although the tailoring will be done by need is more funding and more focus to the intelligent compiler, and not by pull off these Very High-Level, Wide the "programmer, 'I as originally Spectrum Languages. conceived. Some pieces of the problem could The technology is almost here to be solved (at least partially) with the allow for a mixture of communication logic-oriented style of languages. media between man and machine (speech, Concept modeling requirements analysis natural language, mouse, mnues, etc.) and prototyping have already been in narrow domains. While a pragmatist demonstrated with this style [DAY 871. should not project until the technology If the goals of the Fifth Generation is well in hand, in this case, it will thrust in Japan are successful, that definitely be a case of "keeping up hardware, coupled with this style, may with the Jones" after the first such be all that's needed as the seed corn system is fielded: the difference in for a wide class of applications. having it or not having it is not as subtle as whether or not a The Knowledge-Based Software hardware-sof tware combination supports Assistant (KBSA) [Green 831 attempts an bit-map displays or the hardware can evolutionary approach to a support 1.2 vs. 1.0 MIPS. By the year revolutionary paradigm for developing 2000, if you don't support capabilities and supporting large software systems. like an informal interface, "smart" The approach is to unite a set of assis tance , and I' in t el 1i gen t " intelligent knowledge-based tools monitoring of execution, you will be visible to the user (requirements closed out of certain application as sistant , specif ica t ion assis tant , areas. performance assis tan t, proj ec t management assistant, etc. 1 with each The role the hardware will play other and some tools not so visible to in supporting these projections cannot the user (activities coordinator. be ignored either. The cost of project data-base builder). The workstations that can handle full-up unification would prduce a single tool expert systems engineering tools is which assists in all aspects of the

I74 software developrent and captures BIBLIOGRAPHY knowledge, about the specific software system being built, that normally disappears (design decisions, algorithm selection and implementation strategy, 1. [BIRD 871 Bird, Richard, "A etc. . This knowledge is invaluable Calculus of Functions for Program for that system's future maintenance Deviation, 'I Technical Monograph PRG-64. and upgrades, for reducing the work December 1967, Oxford University. necessary to build similar systems in the future, and for accommodating the 2. [BROO 871 Brooks, Frederick P.* inevitable personnel turnovers on a "No Silver Bullet: Essence and long-term project. If successful, Accidents of Software Engineering, 'I someday (not in this century) for a Computer, April 1987, pp 10-19. specific class of very complex systems, such as air traffic control, one may 3. [DAY 871 Day, William. et al, only need to specify requirements for Loaic Proaramminq A lied to the grandson of a system previously Re uirements and spe2f ica t ion= built with this paradigm and have a RADqC-TR-87-260, December 1987. KBSA do the rest. This would be the ultimate in high-level languages. 4. [FAUG 861 Faught, William S.. "Applications of AI in Engineering, 'I To reach the ultimate goal of the Computer, Volume 19. Number 7, July KBSA is obviously very ambitious and, 1986, pp 17-27. while various compoents are proving out today (Project Mangement, Requirements 5. [GENE 851 Geneserth, Michael R. Assistant, Specification Assistant. and Mathew L. Ginsberg, "Logic Performacne Assistant, and even a Programming, Communications of the rudimentary framework to connect the ~ACM, September 1985, Volume 287Number independent components or "facets" in 9, pp 933-941. KBSA terms), much more work needs to be done. However, there appears to be 6. [GREE 831 Green, Cordell, et al, renewed interest on both sides of the Report E a Knowledqe-Based Software Atlantic in one of the key areas, Assistant, RADC-TR-83-195, August 1983. formal (or mechanical) transla tion. Some other keys to the KBSA paradigm 7. [HOAR 871 Hoare, C. A. R.. "An (e.g., distr ibuted 'mow 1ed g e Overview of Some Formal Methods for acquisition, truth maintenance) are Program Design, Computer, September necessary for many other applications 1987, pp 85-91. in knowledge-based systems and are also being worked. It is hoped we can 8. [HWAN 871 Hwang, Kai, et al, revisit the success this new paradigm "Computer Architectures for AI in f ifteen-to-twenty years Processing, 'I Computer, Volume 20, Number 1, January 1987, PP 19-17. IV. Conclusion 9. [INGA 781 Ingals, Daniel, "The History is against rapid change in Smalltalk - 76 Proqramming System," programming languages. However, to Conference Record of fhe Fifth Annual meet the software challenges of the -ACM S osium E Princi les of next century, challenges which are ProgrammEE Lanquaqes, Januart 23-25, inseparable from and required for 1978 advancements in many fields, we must make some revolutionary changes. If we 10. [MATT 871 Matthews, Gene, et al, really put our minds to it and focus "Single Chip Processor Runs LISP our attention on furthering Environments, Computer Desiqn, May 1, advancements, rather than succumbing to 1987, pp 69-76. temptation and dissipating our intellectual and financial resources by 11. [SAMM 691 Sammet, Jean E.# trying to accommodate each step forward Programminq Lan ua es: History in almost every existing programming Fundamentals, wtice-Ha11. language, we can orchestrate and field this very necessary revolution. 12. [SAMM 721 Sammet, Jean E., "Programming Languages : History and Future, 'I Communications of the G, July 1972, Volume 15, Number 7, pp 601-610.

13. [TICH 871 Tichy, Walter F., "What

175 Can Software Engineers Learn from Arti f ici a1 Intel1 i gence? 'I , Computer , November 1987, pp 43-54. 14. [UNGA 871 Ungar, David and David Patterson, "What Price Smalltalk, " Computer, Volume 20, Number 1, January 1987, pp 67-74.

15. [WIL 87 I Wilson, Ron, "Object-oriented Languages Reorient Programming Techniques, I' Computer Desiqn, November 1, 1987, pp 52-62.

16. [WULF 801 Wulf, William A., "Trends in the Design and Implementation of Programming Languages, 'I Computer, January 1980, pp 14-23.

17. [YOK 0811 Yokoi, T., et al, "Logic Programming and a Dedicated High-Performance Personal Computer, 'I Proceedinqs of International Conference --on Fifth Generation Computer Systems, October 19-22, 1981.

176