DOCSLIB.ORG

Beyond Programming Languages Terry Winograd Stanford University

Total Page：16

File Type：pdf, Size：1020Kb

Download full-text PDF Read full-text
Beyond Programming Languages Terry Winograd Stanford University Reports and Articles Beyond Programming Languages Terry Winograd Stanford University As computer technology matures, our growing Introduction ability to create large systems is leading to basic changes in the nature of programming. Current Computer programming today is in a state of crisis programming language concepts will not be adequate (or, more optimistically, a state of creative ferment). for building and maintaining systems of the complexity There is a growing recognition that the available pro- called for by the tasks we attempt. Just as high level gramming languages are not adequate for building com- languages enabled the programmer to escape from the puter systems. Of course, as any first year student of intricacies of a machine's order code, higher level computation theory knows, they are logically sufficient. programming systems can provide the means to But they do not deal adequately with the problems we understand and manipulate complex systems and face in the day-to-day work of programming. We become components. In order to develop such systems, we need swamped by the complexity of large systems, lost in code to shift our attention away from the detailed written by others, and mystified by the behavior of our specification of algorithms, towards the description of almost debugged systems. When we look to the inte- the properties of the packages and objects with which grated multiprocessor systems that will soon dominate we build. This paper analyzes some of the shortcomings computing, the situation is even worse. of programming languages as they now exist, and lays This crisis in software production is far greater (in out some possible directions for future research. overall magnitude at least) than the situation of the early Key Words and Phrases: programming, 50's that led to the development of high level languages programming languages, programming systems, systems to relieve the burden of coding. The problems are harder development to solve, and the costs of not solving them are in the CR Categories: 4.0, 4.20, 4.22, 4.40 hundreds of millions. "The symptoms appear in the form of software that is nonresponsive to user needs, unrelia- ble, excessively expensive, untimely, inflexible, difficult to maintain, and not reusable." [3, p. 26.] There are many ways to improve things a little, and they are being tried. But to achieve a fundamental jump in our pro- gramming capacity, we need to rethink what we are doing from the beginning. The Problem I believe that the problem lies in an obsolete view of programming and programming languages. A widely accepted view can be paraphrased: The programmer's job is to design an algorithm (or a class of computations) Permission to copy without fee all or part of this material is for carrying out a task, and to write it down as a complete granted provided that the copies are not made or distributed for direct and precise set of instructions for a computer to follow. commercial advantage, the ACM copyright notice and the title of the publication and its date appear, and notice is given that copying is by High level programming languages simplify the writing permission of the Association for Computing Machinery. To copy of these instructions by providing basic building blocks otherwise, or to republish, requires a fee and/or specific permission. for stating instructions (both control and data structures) Author's address: T. Winograd, Computer Science Dept., Stanford University, Stanford, CA 94305. that are at a higher level of the logical structure of the © 1979 ACM 0001-0782/79/0700-0391 $00.75 algorithm than those of the basic machine. 391 Communications July 1979 of Volume 22 the ACM Number 7 This view has guided the development of many pro- Components for general tasks (such as memory manage- gramming languages and systems. It served well in the ment, user interface, file management, and network com- early days of computing, but in today's computational munication) can be designed once, rather than recon- environment, it is misleading and stultifying. It focuses structed for each system that needs the capability. Un- attention on the wrong issues and gives the most impor- fortunately, in current programming practice this is more tant aspects of programming a second-class status. It is of an ideal than a reality. The difficulties of using existing irrelevant in the same sense that binary arithmetic is packages often make it easier to replicate their function irrelevant--the things it deals with are a necessary part than to integrate them into a system. The only way such of computing, but should play a subsidiary rather than packages are generally used is by building programs central role in our understanding. within an "operating system" that provides facilities As computer technology (for both software and hard- within a uniform environment. Only those packages that ware) matures, our growing ability to create complex are needed by the majority of users find their way into systems has led to three basic changes in the nature of operating systems, and the facilities for using them are programming: complex and ad hoc relative to modern programming languages. We need better ways to deal with the prob- 1. Computers are not primarily usedfor solving well-struc- lems of "programming in the large." tured mathematical problems or data processing, but in- As noted in an IBM report on large software systems stead are components in complex systems. [1, p. 6], "... The understanding of how programs work According to Department of Defense studies [3], individually and in cooperation with each other.., re- more than half of DoD software costs are associated with mains very difficult to generalize, teach, communicate, "embedded computer systems." An embedded computer or even preserve, due to lack of easy 'externalization,' system is "one that is logically incorporated in a larger i.e. representation, of ideas." Once we begin to deal with system--e.g, an electromechanical device, a tactical sys- networks of processors, it will become even more impor- tem, a ship, an aircraft, or a communications system-- tant to deal explicity with properties of systems which whose primary function is not computation." Of course, integrate many independent components. embedded computer systems are not unique to the DoD. Many computer scientists spend the majority of their 3. The main activity of programming is not the origination time dealing with embedded computer systems such as of new independent programs, but in the integration, mod- message systems and text editing and formatting systems. ification, and explanation of existing ones. The example discussed below is a large embedded system This third change grows from the first two. As we are in a university context. As the microcomputer revolution able to build more complex programs, we develop sys- continues, this change will become even more extreme. tems that grow to fit an environment of needs, rather There will be computers embedded in every conceivable than carrying out a single well-specified task. An embed- kind of electrical and mechanical system, and applica- ded system (such as one for airline reservations or text tions like text editing and message processing will be- preparation and formatting) evolves over many years, come widespread on the scale of today's telephone net- increasingly fitting the needs of those who use it, and work. As Fisher [3] notes: incorporating new capacities as hardware advances make Embedded computer software often exhibits characteristics that them practical. The DoD study [3, pp. 24-25] noted that, are strikingly different from those of other computer applications .... "The programs are frequently large (50,000 to 100,000 Many embedded computer applications require software that will lines of code) and long-lived (10 to 15 years) .... Change continue to operate in the presence of faults .... For example, the applications may require the monitoring of sensors, control of equip- is continuous because of evolving system requirements-- ment display, or operator input processing. They must interface annual revisions are often of the same magnitude as the special peripheral equipment .... Software must sometimes be able original development .... The majority of costs are in- to respond at periodic (real time) intervals, to service interrupts curred in software maintenance rather than develop- within limited times, and to predict computation times .... In many ment." applications.., it is necessary to access, manipulate and display large quantities of data. Much of this data is symbolic or textual rather As additional needs and possibilities arise, it should than numeric, and must be organized in an orderly and accessible be possible to modify and combine existing well-tested fashion. systems rather than build new ones. In most cases, the needs for continuity in the use of the system (including 2. The building blocks out of which systems are built are "upward compatibility" for existing data and user pro- not at the level of programming language constructs. They grams) make it impractical to start from scratch. Using are "'subsystems" or "'packages," each of which is an current programming techniques, systems often reach a integrated collection of data structures, programs, and point at which the accretion of changes makes their protocols. structure so baroque and opaque that further changes By making use of existing modules, a programmer are impossible, and the performance of the system is can deal with design at a higher level, creating an inte- irreversibly degraded. The situation is further compli- grated system with capacities far greater than a program cated by the fact that modifications are often done not that could be built with the same effort "from scratch." by the original builders, but by new programmers with 392 Communications July 1979 of Volume 22 the ACM Number 7 an incomplete or inaccurate understanding of the system.
Load more

Recommended publications
  • Stanford University Medical Experimental Computer Resource (SUMEX) Records SC1248
    http://oac.cdlib.org/findaid/ark:/13030/c8s46z8g Online items available Guide to the Stanford University Medical Experimental Computer Resource (SUMEX) Records SC1248 Daniel Hartwig & Jenny Johnson Department of Special Collections and University Archives January 2018 Green Library 557 Escondido Mall Stanford 94305-6064 [email protected] URL: http://library.stanford.edu/spc Guide to the Stanford University SC1248 1 Medical Experimental Computer Resource (SUMEX) Records SC... Language of Material: English Contributing Institution: Department of Special Collections and University Archives Title: Stanford University Medical Experimental Computer Resource (SUMEX) records Identifier/Call Number: SC1248 Physical Description: 33 Linear Feet Date (inclusive): 1975-1991 Special Collections and University Archives materials are stored offsite and must be paged 48 hours in advance. For more information on paging collections, see the department's website: http://library.stanford.edu/spc. Conditions Governing Access Materials are open for research use. Audio-visual materials are not available in original format, and must be reformatted to a digital use copy. Conditions Governing Use All requests to reproduce, publish, quote from, or otherwise use collection materials must be submitted in writing to the Head of Special Collections and University Archives, Stanford University Libraries, Stanford, California 94304-6064. Consent is given on behalf of Special Collections as the owner of the physical items and is not intended to include or imply permission from the copyright owner. Such permission must be obtained from the copyright owner, heir(s) or assigns. Restrictions also apply to digital representations of the original materials. Use of digital files is restricted to research and educational purposes.
    [Show full text]
  • Smart Battery Charging Programmer Software User Manual Smart Battery Charging Programmer Software User Manual
    Smart Battery Charging Programmer Software User Manual Smart Battery Charging Programmer Software User Manual 1. Introduction ............................................................................................................... 1 ................................................................................................... 2. Prerequisites 1 .................................................................................................. 2.1 System requirements 1 .................................................................................................. 2.2 Hardware installation 1 ................................................................................................... 2.3 Software installation 2 3. User Interface ............................................................................................................ 2 .............................................................................................................. 3.1 Basic layout 2 CURVE PROFILE ......................................................................................................... 3.2 2 SETTING ...................................................................................... ............. 3.3 ................ 3 . ...................................................................................................... 4 General Operation 4 ...................................................................................................... 4.1 Connection 4 4.2 .........................................................................
    [Show full text]
  • Chapter 1 Issues—The Software Crisis
    Chapter 1 Issues—The Software Crisis 1. Introduction to Chapter This chapter describes some of the current issues and problems in system development that are caused The term "software crisis" has been used since the by software—software that is late, is over budget, late 1960s to describe those recurring system devel- and/or does not meet the customers' requirements or opment problems in which software development needs. problems cause the entire system to be late, over Software is the set of instructions that govern the budget, not responsive to the user and/or customer actions of a programmable machine. Software includes requirements, and difficult to use, maintain, and application programs, system software, utility soft- enhance. The late Dr. Winston Royce, in his paper ware, and firmware. Software does not include data, Current Problems [1], emphasized this situation when procedures, people, and documentation. In this tuto- he said in 1991: rial, "software" is synonymous with "computer pro- grams." The construction of new software that is both Because software is invisible, it is difficult to be pleasing to the user/buyer and without latent certain of development progress or of product com- errors is an unexpectedly hard problem. It is pleteness and quality. Software is not governed by the perhaps the most difficult problem in engi- physical laws of nature: there is no equivalent of neering today, and has been recognized as such Ohm's Law, which governs the flow of electricity in a for more than 15 years. It is often referred to as circuit; the laws of aerodynamics, which act to keep an the "software crisis".
    [Show full text]
  • PHP Programmer Location: North Las Vegas NV, USA
    Batteries ... For Life! PHP Programmer Position Title: PHP Programmer Location: North Las Vegas NV, USA Description: BatterieslnAFlash.com, Inc. has an immediate need for a PH? Web Programmer to join their team full­ time. The ideal candidate will work on development and implementation ofa wide variety of Web-based products using PHP, JavaScript, MySQL and AJAX. Qualified applicants would be initially working on a 90 day probationary period for a growing online battery company. " Responsibilities: • Participate in a team-oriented environment to develop complex Web-based applications. Improve, repair, and manage existing websites and applications. / ( • Maintain existing codebases to include troubieshooting bugs and adding new features. • Convert data from various formats (Excel, ACCESS etc.) into developed databases. • Balance a variety of concurrent projects. Required Experience: • Ability to work independently, take initiative, and contribute to new ideas required in a diverse, fast­ paced, deadline-driven team environment. Self-starter with a professional appearance. • Detailed knowledge of web application development and extensive experience using PHP and Javascript as well as relational databases such a~. PostgreSQL and MySQL. • Proven hands on experience with web applicationfi"."meworks such as CAKE, Kohana, Zend, etc. • Proven hands on experience with JavaScript fral.;cworks such as jQuery and EXT JS • Proven hands on experience with SECURE CODING techniques • Experience developing cross-browser frontends using XHTML, CSS, AJAX, JavaScript. • Organization and analytic skills, with strong problem solving ability. • Excellent written and verbal communications skills • Experience with version control systems such as SVN and CVS • Hands on experience with L1NUX especially using command line tools and writing SHELL scripts (Benefit, not required) • Experience using common business software ~ uch as WORD, PowerPoint, Excel and VISIO to visualize, discuss and present ideas to technical and non-technical audiences.
    [Show full text]
  • Dissertation Submitted in Partial Fulfillment of the Requirements for The
    ON THE HUMAN FACTORS IMPACT OF POLYGLOT PROGRAMMING ON PROGRAMMER PRODUCTIVITY by Phillip Merlin Uesbeck Master of Science - Computer Science University of Nevada, Las Vegas 2016 Bachelor of Science - Applied Computer Science Universit¨at Duisburg-Essen 2014 A dissertation submitted in partial fulfillment of the requirements for the Doctor of Philosophy { Computer Science Department of Computer Science Howard R. Hughes College of Engineering The Graduate College University of Nevada, Las Vegas December 2019 c Phillip Merlin Uesbeck, 2019 All Rights Reserved Dissertation Approval The Graduate College The University of Nevada, Las Vegas November 15, 2019 This dissertation prepared by Phillip Merlin Uesbeck entitled On The Human Factors Impact of Polyglot Programming on Programmer Productivity is approved in partial fulfillment of the requirements for the degree of Doctor of Philosophy – Computer Science Department of Computer Science Andreas Stefik, Ph.D. Kathryn Hausbeck Korgan, Ph.D. Examination Committee Chair Graduate College Dean Jan Pedersen, Ph.D. Examination Committee Member Evangelos Yfantis, Ph.D. Examination Committee Member Hal Berghel, Ph.D. Examination Committee Member Deborah Arteaga-Capen, Ph.D. Graduate College Faculty Representative ii Abstract Polyglot programming is a common practice in modern software development. This practice is often con- sidered useful to create software by allowing developers to use whichever language they consider most well suited for the different parts of their software. Despite this ubiquity of polyglot programming there is no empirical research into how this practice affects software developers and their productivity. In this disser- tation, after reviewing the state of the art in programming language and linguistic research pertaining to the topic, this matter is investigated by way of two empirical studies with 109 and 171 participants solving programming tasks.
    [Show full text]
  • The Cedar Programming Environment: a Midterm Report and Examination
    The Cedar Programming Environment: A Midterm Report and Examination Warren Teitelman The Cedar Programming Environment: A Midterm Report and Examination Warren Teitelman t CSL-83-11 June 1984 [P83-00012] © Copyright 1984 Xerox Corporation. All rights reserved. CR Categories and Subject Descriptors: D.2_6 [Software Engineering]: Programming environments. Additional Keywords and Phrases: integrated programming environment, experimental programming, display oriented user interface, strongly typed programming language environment, personal computing. t The author's present address is: Sun Microsystems, Inc., 2550 Garcia Avenue, Mountain View, Ca. 94043. The work described here was performed while employed by Xerox Corporation. XEROX Xerox Corporation Palo Alto Research Center 3333 Coyote Hill Road Palo Alto, California 94304 1 Abstract: This collection of papers comprises a report on Cedar, a state-of-the-art programming system. Cedar combines in a single integrated environment: high-quality graphics, a sophisticated editor and document preparation facility, and a variety of tools for the programmer to use in the construction and debugging of his programs. The Cedar Programming Language is a strongly-typed, compiler-oriented language of the Pascal family. What is especially interesting about the Ce~ar project is that it is one of the few examples where an interactive, experimental programming environment has been built for this kind of language. In the past, such environments have been confined to dynamically typed languages like Lisp and Smalltalk. The first paper, "The Roots of Cedar," describes the conditions in 1978 in the Xerox Palo Alto Research Center's Computer Science Laboratory that led us to embark on the Cedar project and helped to define its objectives and goals.
    [Show full text]
  • Intermittent Computation Without Hardware Support Or Programmer
    Intermittent Computation without Hardware Support or Programmer Intervention Joel Van Der Woude, Sandia National Laboratories; Matthew Hicks, University of Michigan https://www.usenix.org/conference/osdi16/technical-sessions/presentation/vanderwoude This paper is included in the Proceedings of the 12th USENIX Symposium on Operating Systems Design and Implementation (OSDI ’16). November 2–4, 2016 • Savannah, GA, USA ISBN 978-1-931971-33-1 Open access to the Proceedings of the 12th USENIX Symposium on Operating Systems Design and Implementation is sponsored by USENIX. Intermittent Computation without Hardware Support or Programmer Intervention Joel Van Der Woude Matthew Hicks Sandia National Laboratories∗ University of Michigan Abstract rapid changes drive us closer to the realization of smart As computation scales downward in area, the limi- dust [20], enabling applications where the cost and size tations imposed by the batteries required to power that of computation had previously been prohibitive. We are computation become more pronounced. Thus, many fu- rapidly approaching a world where computers are not ture devices will forgo batteries and harvest energy from just your laptop or smart phone, but are integral parts their environment. Harvested energy, with its frequent your clothing [47], home [9], or even groceries [4]. power cycles, is at odds with current models of long- Unfortunately, while the smaller size and lower cost of running computation. microcontrollers enables new applications, their ubiqui- To enable the correct execution of long-running appli- tous adoption is limited by the form factor and expense of cations on harvested energy—without requiring special- batteries. Batteries take up an increasing amount of space purpose hardware or programmer intervention—we pro- and weight in an embedded system and require special pose Ratchet.
    [Show full text]
  • Software Engineering and Ethics: When Code Goes Bad
    Software Engineering and Ethics: when code goes bad Once upon a time, estimates for the Strategic Defense Initiative (SDI or ``Star Wars'') claimed that there would be 30 million lines of code, all bug free. This is at least three orders of magnitude greater than ever has been achieved. ... What have we learned since then? 2017 TSP (MSc CCN) 1 Lecture Plan It is a bad plan that admits of no modification Publilius Syrus •Software Crisis •Ethics •Software Engineering •Software Engineering and Ethics •The root of the problem - computer science boundaries? •When code goes bad - education through classic examples •Proposals for the future 2017 TSP (MSc CCN) 2 Software Crisis Do you recognise this? 3 When everyone is wrong Software Engineering and “Bugs” everyone is right Nivelle de La Chaussee QUESTION: What’s the difference between hardware and software ?… buy some hardware and you get a warranty, buy some software and you get a disclaimer The software crisis: •always late Does this really exist? •always over-budget •always buggy •always hard to maintain •always better the next time round … but never is! This doesn’t seem right … where are our ethics? 2017 TSP (MSc CCN) 4 Is there really a crisis? … To avoid crisis, just hire the best people … look at the advances we have made Success in software development depends most upon the quality of the people involved. There is more software to be developed than there are capable developers to do it. Demand for engineers will continue to outstrip supply for the foreseeable future. Complacency has already set in … some firms acknowledge that many of their engineers make negative contribution.
    [Show full text]
  • Arxiv:2105.00534V1 [Cs.SE] 2 May 2021 Solutions
    Metadata Interpretation Driven Development J´ulioG.S.F. da Costaa,d, Reinaldo A. Pettac,d, Samuel Xavier-de-Souzaa,b,d, aGraduate Program of Electrical and Computer Engineering bDepartamento de Engenharia de Computa¸c~aoe Automa¸c~ao cDepartamento de Geologia dUniversidade Federal do Rio Grande do Norte, Natal, RN, Brazil, 59078-900 Abstract Context: Despite decades of engineering and scientific research efforts, sep- aration of concerns in software development remains not fully achieved. The ultimate goal is to truly allow code reuse without large maintenance and evo- lution costs. The challenge has been to avoid the crosscutting of concerns phe- nomenon, which has no apparent complete solution. Objective: In this paper, we show that business-domain code inscriptions play an even larger role in this challenge than the crosscutting of concerns. We then introduce a new methodology, called Metadata Interpretation Driven Develop- ment (MIDD) that suggests a possible path to realize separation of concerns by removing functional software concerns from the coding phase. Method: We propose a change in the perspective for building software, from being based on object representation at the coding level to being based on ob- ject interpretation, whose definitions are put into layers of representation other than coding. The metadata of the domain data is not implemented at the level of the code. Instead, they are interpreted at run time. Results: As an important consequence, such constructs can be applied across functional requirements, across business domains, with no concerns regarding the need to rewrite or refactor code. We show how this can increase the (re)use of the constructs.
    [Show full text]
  • PHP Programmer Analyst Markham, ON
    PHP Programmer Analyst Markham, ON PharmaCommunications™ is a leading provider of marketing technology and services to the life sciences industry. Through our offices in Montréal and Toronto, we provide solutions that help the industry manage interactions with stakeholders; improve sales and marketing processes; and identify opportunities for future growth. We have undertaken assignments for virtually all of the industry’s top 100 companies, and have completed projects throughout North America and Europe. We currently have opportunities for Full ‐‐‐Time PHP Programmer Analyst to join our Markham team. Reporting to the Manager, Systems Development this position involves the ongoing development of our marketing technology platforms. Responsibilities PHP LAMP Programming Javascript (JQuery) HTML/CSS and JS/AJAX/SOAP/BOOTSTRAP MySQL and Relational Databases Code Repositories(Subversion) UX design skill set Building professional online web applications Languages: Speak English, Read English, Write English What We’re Looking For Bachelor Degree in Computer Science or related science preferred Fluent in English Minimum of 5 years of related experience with IT and related technologies Must have minimum of 3 years PHP (Object Oriented Programming) Must have UNIX/Linux experience Familiar with SDLC and Agile development methodologies Understand system requirement specifications Experience with creating system documentation and validation documents Good organizational and communication skills In addition to a competitive salary and comprehensive benefits package, we offer a stimulating and challenging work environment, significant opportunities for career development, as well as a close-knit corporate culture that values inclusion, team work and dedication. From flex-time to office lunch events, our goal is to provide our team with both an enriching work environment and a good life-work balance.
    [Show full text]
  • The PHP Programmer's Guide to Secure Code
    School of Mathematics and Systems Engineering Reports from MSI - Rapporter från MSI The PHP programmer’s guide to secure code Richard Clarinsson Samuel Magnusson Maj MSI Report 05046 2005 Växjö University ISSN 1650-2647 SE-351 95 VÄXJÖ ISRN VXU/MSI/IV/E/--05046/--SE Abstract Authors: Richard Clarinsson, Samuel Magnusson Title: The PHP programmer’s guide to secure code Course: IVC730 – Bachelor thesis University: Växjö Universitet Institution: School of Mathematics and Systems Engineering Date: 2005-05-24 Content: Security threats against computer systems are a big problem today which also includes PHP made applications. The report is focused on protection with the help of code and not how you protect a web server. Its purpose is not to educate the readers of the thesis how to make a PHP application, the purpose is how to program a safer PHP application. The thesis contains information about common security threats against PHP scripts. It contains in most cases examples of what an attack can look like and how a protection for that example can be achieved. We have tested all code examples if they work by installing our own server with the configurations according to the delimitations of the thesis and putting up small PHP applications, which we have attacked and then protected. The contents and result of this thesis can benefit developers that use PHP as a programming language for creating web applications, by giving them information about common threats and protection. Keywords: security, PHP, security threats, programming, code, protection Preface This thesis has been very interesting and educational to write, but also a challenge.
    [Show full text]
  • CSC 272 - Software II: Principles of Programming Languages
    CSC 272 - Software II: Principles of Programming Languages Lecture 1 - An Introduction What is a Programming Language? • A programming language is a notational system for describing computation in machine-readable and human-readable form. • Most of these forms are high-level languages , which is the subject of the course. • Assembly languages and other languages that are designed to more closely resemble the computer’s instruction set than anything that is human- readable are low-level languages . Why Study Programming Languages? • In 1969, Sammet listed 120 programming languages in common use – now there are many more! • Most programmers never use more than a few. – Some limit their career’s to just one or two. • The gain is in learning about their underlying design concepts and how this affects their implementation. The Six Primary Reasons • Increased ability to express ideas • Improved background for choosing appropriate languages • Increased ability to learn new languages • Better understanding of significance of implementation • Better use of languages that are already known • Overall advancement of computing Reason #1 - Increased ability to express ideas • The depth at which people can think is heavily influenced by the expressive power of their language. • It is difficult for people to conceptualize structures that they cannot describe, verbally or in writing. Expressing Ideas as Algorithms • This includes a programmer’s to develop effective algorithms • Many languages provide features that can waste computer time or lead programmers to logic errors if used improperly – E. g., recursion in Pascal, C, etc. – E. g., GoTos in FORTRAN, etc. Reason #2 - Improved background for choosing appropriate languages • Many professional programmers have a limited formal education in computer science, limited to a small number of programming languages.
    [Show full text]