at any point In addition it is possible to experiment with the efficacy of minor variations such as a deeper or shallower search for candidates more frequent global iterations between phases 1 and 2 the use of coding schemes to prevent candidates from reentering candidate lists immediately after being rejected etc This type of manageability makes it easier to understand how the algorithm behaves and tailor the algorithm to particular types of problems Much remains to be done The degree of nonoptimality caused by iterating between phases 1 and 2 rather than combining them should be explored The handling of key orders in the current algorithm must be revised and made more general a maximum of two keys are allowed for each dataset in the current implementation Further refinement of methods for estimating execution costs would increase the applicability of the results This paper has presented an explanation and demonstration of an approach for producing answers to a puzzle that confronts system designers every day The next step is to apply this approach in facilitating the design of real systems Whether human designers really need help of this type is actually an empirical question that can be studied by comparing the efficiency of actual system designs with tha t of designs generated by algorithms such as the one presented here Whether or not such algorithms outperform human designers the need for their development is clear To implement automatic programming capabilities in which people describe the substantive processing to be accomplished and machines translate such descriptions into executable code design choices will have to be made automatically Received November 1977 revised January 1979 Programming Languages J J Homing Editor High Leve Programming for Distributed Computing J e r o m e A F e l d m a n University of Rochester Programming for distributed and other loosely coupled systems is a problem of growing interest This paper describes an approach to distributed computing at the level of general purpose programming languages Based on primitive notions of module message and transaction key the methodology is shown to be independent of particular languages and machines It appears to be useful for programming a wide range of tasks This is part of an ambitious program of development in advanced programming languages and relations with other aspects of the project are also discussed Key Words and Phrases distributed computing modules messages assertions CR Categories 4 22 4 32 References 1 Alter S Optimizing the behavior of application systems Proc Sixth Annual Conf of the Computer Measurement Group San Francisco Oct 8 10 1975 pp 192 211 2 Gerritsen R A preliminary system for the design of DBTG data structures Comm ACM 18 10 Oct 1975 551 557 3 Hoffer J An integer programming formulation of computer data base problems TR 1 74 Dept of Management Studies Case Western Reserve U Cleveland Ohio Oct 1974 4 Kornfeld W Methodology for optimization in automatic programming systems Unpub B S Th M I T Cambridge Mass June 1975 5 Low J Automatic coding choice of data structures Memo AIM242 Stanford Artif Intell Lab Stanford Calif Aug 1974 6 Mitoma M F and Irani K B Automatic database schema design and optimization Proc Int Conf on Very Large Databases 1975 pp 278 321 available from ACM New York 7 Morgenstern M Automated design and optimization of management information systems software Unpub Ph D Th M I T Cambridge Mass 1976 8 Nunamaker J F Nylin W C and Konsynski B Processing systems optimization through automatic design and reorganization of program modules In Information Systems J T Tou Ed Plenum New York 1974 pp 311 336 9 Ruth G Automatic design of data processing systems Third ACM Symp on Principles of Programming Languages Atlanta Georgia Jan 1976 pp 50 57 10 Yao S B and Merten A G Selection of file organization using an analytic model Proc Int Conf on Very Large Databases 1975 pp 255 267 available from ACM New York 353 1 Introduction and Overview When the University of Rochester Computer Science Department was started in 1974 our initial research goals included taking a really serious look at programming languages There were two underlying assumptions l that programming languages had changed little in the previous decade despite advances in many related areas and 2 that one could envision compilers as sophisticated as the best current artificial intelligence programs We began by trying to isolate the most important concepts available in programming systems to see how they interacted with each other The project was called PLITS Programming Language in the Sky and alPermission to copy without fee all or part of this material is granted provided that the copies are not made or distributed for direct commercial advantage the ACM copyright notice and the title of the publication and its date appear and notice is given that copying is by permission of the Association for Computing Machinery To copy otherwise or to republish requires a fee and or specific permission Author s address Dept of Computer Science Mathematical Sciences Building University of Rochester Rochester N Y 14627 1979 ACM 0001 0782 79 0600 0353 00 75 Communications of the ACM June 1979 Volume 22 Number 6 though it has come down a little closer to the ground the name has stuck The study is far from complete but we claim to have an interesting preliminary result namely that a judicious incorporation of three constructs modules messages and assertions can lead to programming language systems of considerable power and elegance This paper concentrates on the implications of the continuing advance of distributed computing On the design for high level programming languages Many problems of distributed computing DC do not arise in conventional programming Solutions of these problems lead in a natural way to new programming language constructs A distributed computation is spread among several computers which are assumed to be connected by some communication paths For the foreseeable future these communication paths will be less reliable and have lower bandwidth than is available in the processors themselves This leads us to expect that DC programs will be made up of largely self contained modules which will share very little information directly One would also want to have the communication between modules be some asynchronous message protocol rather than subroutine or coroutine calls where one module would always have to wait for
View Full Document
Unlocking...