The Evolution of C Programming Practices: a Study of the Unix Operating System 1973–2015

Total Page:16

File Type:pdf, Size:1020Kb

The Evolution of C Programming Practices: a Study of the Unix Operating System 1973–2015 The Evolution of C Programming Practices: A Study of the Unix Operating System 1973–2015 Diomidis Spinellis Panos Louridas Maria Kechagia [email protected] [email protected] [email protected] Department of Management Science and Technology Athens University of Economics and Business Patision 76, GR-104 34 Athens, Greece ABSTRACT or at the resulting artefacts (outputs). Furthermore, we can Tracking long-term progress in engineering and applied sci- examine both using either qualitative or quantitative means. ence allows us to take stock of things we have achieved, ap- The objective of this work is to study the long term evo- preciate the factors that led to them, and set realistic goals lution of C programming in the context of the Unix oper- for where we want to go. We formulate seven hypotheses as- ating system development. The practice of programming sociated with the long term evolution of C programming in is affected by tools, languages, ergonomics, guidelines, pro- the Unix operating system, and examine them by extracting, cessing power, conventions, as well as business and soci- aggregating, and synthesising metrics from 66 snapshots ob- etal trends and developments. Specific factors that can tained from a synthetic software configuration management drive long term progress in programming practices include repository covering a period of four decades. We found that the affordances and constraints of computer architecture, over the years developers of the Unix operating system ap- programming languages, development frameworks, compiler pear to have evolved their coding style in tandem with ad- technology, the ergonomics of interfacing devices, program- vancements in hardware technology, promoted modularity ming guidelines, processing memory and speed, and social to tame rising complexity, adopted valuable new language conventions. These might allow, among other things, the features, allowed compilers to allocate registers on their be- more liberal use of memory, the improved use of types, the half, and reached broad agreement regarding code format- avoidance of micro-optimisations, the writing of more de- ting. The progress we have observed appears to be slowing scriptive code, the choice of appropriate encapsulation mech- or even reversing prompting the need for new sources of in- anisms, and the convergence toward a common coding style. novation to be discovered and followed. Here are a few examples. The gradual replacement of clunky teletypewriters with addressable-cursor visual dis- play terminals in the 1970s may have promoted the use of CCS Concepts longer, more descriptive identifiers and comments. Compil- •Software and its engineering ! Software evolution; ers using sophisticated graph colouring algorithms for regis- Imperative languages; Software creation and management; ter allocation and spilling [12] may have made it unnecessary Open source model; •General and reference ! Empir- to allocate registers in the source code by hand. The real- ical studies; Measurement; •Social and professional isation that the overuse of the goto statement can lead to topics ! Software maintenance; History of software; spaghetti code [13] might have discouraged its use. Simi- larly, one might hope that the recognition of the complexity and problems associated with the (mis)use of the C prepro- Keywords cessor [15,34,48,49] may have led to a reduced and more dis- C; coding style; coding practices; Unix; BSD; FreeBSD ciplined application of its facilities. Also, one would expect that the introduction and standardisation of new language 1. INTRODUCTION features [2,23,45] would lead to their adoption by practition- ers. Finally, the formation of strong developer communities, Tracking long-term progress in engineering and applied the maturing of the field, and improved communication fa- science allows us to take stock of things we have achieved, cilities may lead to a convergence on code style. appreciate the factors that led to them, and set realistic In more formal terms, based on a simple-regression ex- goals for where we want to go. Progress can be tracked along ploratory study [54], we established the following hypothe- two orthogonal axes. We can look at the processes (inputs) ses, which we then proceeded to test with our data. H1: Programming practices reflect technology af- fordances If screen resolutions rise we expect developers to become ACM acknowledges that this contribution was authored or co-authored by an em- ployee, contractor or affiliate of a national government. As such, the Government more liberal with their use of screen space, as they are no retains a nonexclusive, royalty-free right to publish or reproduce this article, or to al- longer constrained to use shorter identifiers and shorter lines. low others to do so, for Government purposes only. Higher communication bandwidth (think of the progress from ICSE ’16, May 14-22, 2016, Austin, TX, USA a 110 bps asr-33 teletypewriter, to a 9600 bps vt-100 char- c 2016 ACM. ISBN 978-1-4503-3900-1/16/05. $15.00 acter addressable terminal, to a 10mb Ethernet-connected DOI: http://dx.doi.org/10.1145/2884781.2884799 bitmap-screen workstation) makes typing more responsive they indeed change over time, as well as the direction and and the refresh of large code bodies faster. Similarly, if rate of change. barriers imposed to compilation unit sizes by the lack of The results of the study on long term evolution of pro- memory or processing capacity are removed, we expect de- gramming practices can be used to allocate the investment velopers to abandon artificially-imposed file size limits, and of effort in areas where progress has been efficiently achieved, move towards longer files packed with more functionality. and to look for new ways to tackle problems in areas showing a lack of significant progress. Also, given the hypothesis that H2: Modularity increases with code size the structure and internal quality attributes of a working, As the Unix source code evolves and multiplies in size non-trivial software artefact will represent first and foremost and complexity we expect developers to manage this growth the engineering requirements of its construction [51], the re- through mechanisms that promote modularity. These in- sults can also indicate areas where developers rationally al- clude the use of the static keyword to limit the visibility located improvement effort and areas where developers did of globally visible identifiers, and the pairing of header files not see a reason to invest. with C implementation into discrete modules. This paper builds on the earlier short exploratory study [54] H3: New language features are increasingly used by explicitly stating and testing hypotheses, by using a more to saturation point sophisticated statistical method for the analysis, by a de- The C language has been changing over time with new tailed explanation of the employed methods, and by present- features being added, albeit sparingly. We expect them to ing possible causality links between external changes, the be increasingly used after being introduced, up to a point metrics, and the hypotheses. To formulate the hypotheses | certainly, a language feature can only be used a certain we took into account the general technological trends, such number of times in a program. For example, when the un- as improved screen technologies and software techniques, signed keyword was introduced, it could in theory, be used combined with metrics, which we could measure from our at most on all integer definitions and declarations of a pro- data and could bear on the trends. In the following sec- gram, and in practice only on those where the underlying tions we describe the methods of our study (Section 2), we value was indeed non-negative. We call this limit the fea- present and discuss the results we obtained (Section 3), and ture's saturation point. outline related work (Section 4). Section 5 summarises our H4: Programmers trust the compiler for register conclusions and provides directions for further work. allocation In the days of yore, programmers had to deal themselves 2. METHODS with the nitty-gritty details of register allocation by declar- Our study is based on a synthetic software configuration ing variables with the register keyword. As compiler tech- management repository tracking the long term evolution of nology has improved, compilers have become more adept the Unix operating system. At successive time points of at the task. We expect that developers have been noticing significant releases we process the C source code files with this and have therefore been more and more trusting of the a custom-developed tool to extract a variety of metrics for compilers with handling register allocation optimizations. each file. We then synthesise these metrics into weighted H5: Code formatting practices converge to a com- values that are related to our hypotheses, and analyse the mon standard results over time using established statistical techniques. We expect developers working on a single project, such 2.1 Data Collection and Primary Metrics as Unix, to adopt a common coding standard, making the code base more homogeneous over time. This can be aided The analysis of the Unix source code over the long term through the increased availability and use of collaboration was made possible by the fact that important Unix material mechanisms such as version control systems and online com- of historical importance has survived and is nowadays openly munities. available. Although Unix was initially distributed with rel- atively restrictive licenses, significant parts of its early de- H6: Software complexity evolution follows self cor- velopment have been released by one of its rights-holders rection feedback mechanisms (Caldera International) under a liberal license. Additional We expect that as software evolves it becomes more com- parts were developed or released as open source software by plex, to a degree. A successful project cannot grow in com- (among others) the University of California, Berkeley and plexity beyond the confines of human comprehension.
Recommended publications
  • Megaraid 6Gb/S SAS RAID Controllers Users Guide
    USER’S GUIDE MegaRAID® 6Gb/s SAS RAID Controllers November 2009 41450-02 Rev. B This document contains proprietary information of LSI Corporation. The information contained herein is not to be used by or disclosed to third parties without the express written permission of an officer of LSI Corporation. LSI products are not intended for use in life-support appliances, devices, or systems. Use of any LSI product in such applications without written consent of the appropriate LSI officer is prohibited. Purchase of I2C components of LSI Corporation, or one of its sublicensed Associated Companies, conveys a license under the Philips I2C Patent Rights to use these components in an I2C system, provided that the system conforms to the I2C standard Specification as defined by Philips. Document 41450-02 Rev. B, November 2009. This document describes the current versions of the LSI Corporation MegaRAID® SAS RAID controllers and will remain the official reference source for all revisions/releases of these products until rescinded by an update. LSI Corporation reserves the right to make changes to any products herein at any time without notice. LSI does not assume any responsibility or liability arising out of the application or use of any product described herein, except as expressly agreed to in writing by LSI; nor does the purchase or use of a product from LSI convey a license under any patent rights, copyrights, trademark rights, or any other of the intellectual property rights of LSI or third parties. Copyright © 2009 by LSI Corporation. All rights reserved. TRADEMARK ACKNOWLEDGMENT LSI, the LSI logo design, Fusion-MPT, and MegaRAID are trademarks or registered trademarks of LSI Corporation.
    [Show full text]
  • Software Rejuvenation Model for Cloud Computing Platform
    International Journal of Applied Engineering Research ISSN 0973-4562 Volume 12, Number 19 (2017) pp. 8332-8337 © Research India Publications. http://www.ripublication.com Software Rejuvenation Model for Cloud Computing Platform I M Umesh System Analyst, Department of Information Science & Engineering, Rashtreeya Vidyalaya College of Engineering, Mysuru Road, Bengaluru, Karnataka, India. Orcid Id: 0000-0002-7595-5501 Dr. G N Srinivasan Professor, Department of Information Science & Engineering, Rashtreeya Vidyalaya College of Engineering, Mysuru Road, Bengaluru, Karnataka, India. Orcid Id: 0000-0003-1059-5952 Matheus Torquato Professor, Federal Institute of Alagoas (IFAL), Campus Arapiraca - AL, Brazil. Orcid Id: 0000-0003-3211-7951 Abstract leading to resource exhaustion. Aging effects are the result of Cloud computing has emerged as one of the most needed error accumulation that leads to resource exhaustion. This technologies that houses software systems and relevant status of softwares makes the system gradually shift from functional entities resulting in complex, multiuser, healthy state to failure prone state. The system performance multitasking and virtualized environments. However, metrics needs to be monitored in order to find the aging reliability of such high performance computing systems patterns while the system is running. The accurate prediction depends both on hardware and software. Virtualization is the of time of aging needs to be forecasted to initiate the technology that many cloud service providers rely on for necessary actions to counter the aging effects. The software efficient management and coordination of the resource pool. aging consequences can be avoided by using the technique The software systems, during operation accumulate errors or called software rejuvenation. garbage leading to software aging which may lead to system Software rejuvenation is the proactive technique proposed to failure and associated consequences.
    [Show full text]
  • Retrocomputing As Preservation and Remix
    Retrocomputing as Preservation and Remix Yuri Takhteyev Quinn DuPont University of Toronto University of Toronto [email protected] [email protected] Abstract This paper looks at the world of retrocomputing, a constellation of largely non-professional practices involving old computing technology. Retrocomputing includes many activities that can be seen as constituting “preservation.” At the same time, it is often transformative, producing assemblages that “remix” fragments from the past with newer elements or joining together historic components that were never combined before. While such “remix” may seem to undermine preservation, it allows for fragments of computing history to be reintegrated into a living, ongoing practice, contributing to preservation in a broader sense. The seemingly unorganized nature of retrocomputing assemblages also provides space for alternative “situated knowledges” and histories of computing, which can sometimes be quite sophisticated. Recognizing such alternative epistemologies paves the way for alternative approaches to preservation. Keywords: retrocomputing, software preservation, remix Recovering #popsource In late March of 2012 Jordan Mechner received a shipment from his father, a box full of old floppies. Among them was a 3.5 inch disk labelled: “Prince of Persia / Source Code (Apple) / ©1989 Jordan Mechner (Original).” Mechner’s announcement of this find on his blog the next day took the world of nerds by storm.1 Prince of Persia, a game that Mechner single-handedly developed in the late 1980s, revolutionized computer games when it came out due to its surprisingly realistic representation of human movement. After being ported to DOS and Apple’s Mac OS in the early 1990s the game sold 2 million copies (Pham, 2001).
    [Show full text]
  • The Past, Present, and Future of Software Evolution
    The Past, Present, and Future of Software Evolution Michael W. Godfrey Daniel M. German Software Architecture Group (SWAG) Software Engineering Group School of Computer Science Department of Computer Science University of Waterloo, CANADA University of Victoria, CANADA email: [email protected] email: [email protected] Abstract How does our system compare to that of our competitors? How easy would it be to port to MacOS? Are users still Change is an essential characteristic of software devel- angry about the spyware incident? As new features are de- opment, as software systems must respond to evolving re- vised and deployed, as new runtime platforms are envis- quirements, platforms, and other environmental pressures. aged, as new constraints on quality attributes are requested, In this paper, we discuss the concept of software evolu- so must software systems continually be adapted to their tion from several perspectives. We examine how it relates changing environment. to and differs from software maintenance. We discuss in- This paper explores the notion of software evolution. We sights about software evolution arising from Lehman’s laws start by comparing software evolution to the related idea of software evolution and the staged lifecycle model of Ben- of software maintenance and briefly explore the history of nett and Rajlich. We compare software evolution to other both terms. We discuss two well known research results of kinds of evolution, from science and social sciences, and we software evolution: Lehman’s laws of software evolution examine the forces that shape change. Finally, we discuss and the staged lifecycle model of Bennett and Rajlich. We the changing nature of software in general as it relates to also relate software evolution to biological evolution, and evolution, and we propose open challenges and future di- discuss their commonalities and differences.
    [Show full text]
  • A Brief History of Software Engineering Niklaus Wirth ([email protected]) (25.2.2008)
    1 A Brief History of Software Engineering Niklaus Wirth ([email protected]) (25.2.2008) Abstract We present a personal perspective of the Art of Programming. We start with its state around 1960 and follow its development to the present day. The term Software Engineering became known after a conference in 1968, when the difficulties and pitfalls of designing complex systems were frankly discussed. A search for solutions began. It concentrated on better methodologies and tools. The most prominent were programming languages reflecting the procedural, modular, and then object-oriented styles. Software engineering is intimately tied to their emergence and improvement. Also of significance were efforts of systematizing, even automating program documentation and testing. Ultimately, analytic verification and correctness proofs were supposed to replace testing. More recently, the rapid growth of computing power made it possible to apply computing to ever more complicated tasks. This trend dramatically increased the demands on software engineers. Programs and systems became complex and almost impossible to fully understand. The sinking cost and the abundance of computing resources inevitably reduced the care for good design. Quality seemed extravagant, a loser in the race for profit. But we should be concerned about the resulting deterioration in quality. Our limitations are no longer given by slow hardware, but by our own intellectual capability. From experience we know that most programs could be significantly improved, made more reliable, economical and comfortable to use. The 1960s and the Origin of Software Engineering It is unfortunate that people dealing with computers often have little interest in the history of their subject.
    [Show full text]
  • SWARE: a Methodology for Software Aging and Rejuvenation Experiments
    Journal of Information Systems Engineering & Management, 2018, 3(2), 15 ISSN: 2468-4376 SWARE: A Methodology for Software Aging and Rejuvenation Experiments Matheus Torquato 1*, Jean Araujo 2, I. M. Umesh 3, Paulo Maciel 4 1 Federal Institute of Alagoas (IFAL), Campus Arapiraca, Arapiraca, AL, BRAZIL 2 Federal Rural University of Pernambuco (UFRPE), Campus Garanhuns, Garanhuns, PE, BRAZIL 3 Bharathiar University, Coimbatore, INDIA 4 Federal University of Pernambuco (UFPE), Center of Informatics (CIn), Recife, PE, BRAZIL *Corresponding Author: [email protected], [email protected] Citation: Torquato, M., Araujo, J., Umesh, I. M. and Maciel, P. (2018). SWARE: A Methodology for Software Aging and Rejuvenation Experiments. Journal of Information Systems Engineering & Management, 3(2), 15. https://doi.org/10.20897/jisem.201815 Published: April 07, 2018 ABSTRACT Reliability and availability are mandatory requirements for numerous applications. Technical apparatus to study system dependability is essential to support software deployment and maintenance. Software aging is a related issue in this context. Software aging is a cumulative process which leads systems with long-running execution to hangs or failures. Software rejuvenation is used to prevent software aging problems. Software rejuvenation actions comprise system reboot or application restart to bringing software to a stable fresh state. This paper proposes a methodology to conduct software aging and software rejuvenation experiments. The approach has three phases: (i) Stress Phase - stress environment with the accelerated workload to induce bugs activation; (ii) Wait Phase - stop workload submission to observe the system state after workload submission; (iii) Rejuvenation Phase - find the impacts caused by the software rejuvenation.
    [Show full text]
  • Software Evolution of Legacy Systems a Case Study of Soft-Migration
    Software Evolution of Legacy Systems A Case Study of Soft-migration Andreas Furnweger,¨ Martin Auer and Stefan Biffl Vienna University of Technology, Inst. of Software Technology and Interactive Systems, Vienna, Austria Keywords: Software Evolution, Migration, Legacy Systems. Abstract: Software ages. It does so in relation to surrounding software components: as those are updated and modern- ized, static software becomes evermore outdated relative to them. Such legacy systems are either tried to be kept alive, or they are updated themselves, e.g., by re-factoring or porting—they evolve. Both approaches carry risks as well as maintenance cost profiles. In this paper, we give an overview of software evolution types and drivers; we outline costs and benefits of various evolution approaches; and we present tools and frameworks to facilitate so-called “soft” migration approaches. Finally, we describe a case study of an actual platform migration, along with pitfalls and lessons learned. This paper thus aims to give software practitioners—both resource-allocating managers and choice-weighing engineers—a general framework with which to tackle soft- ware evolution and a specific evolution case study in a frequently-encountered Java-based setup. 1 INTRODUCTION tainability. We look into different aspects of software maintenance and show that the classic meaning of Software development is still a fast-changing environ- maintenance as some final development phase after ment, driven by new and evolving hardware, oper- software delivery is outdated—instead, it is best seen ating systems, frameworks, programming languages, as an ongoing effort. We also discuss program porta- and user interfaces. While this seemingly constant bility with a specific focus on porting source code.
    [Show full text]
  • Software Design Introduction
    Software Design Introduction Material drawn from [Godfrey96,Parnas86,Parnas94] Software Design (Introduction) © SERG Software Design • How to implement the what. • Requirements Document (RD) is starting point. • Software design is a highly-creative activity. • Good designers are worth their weight in gold! – Highly sought after, head-hunted, well-paid. • Experience alone is not enough: – creativity, “vision”, all-around brilliance required. Software Design (Introduction) © SERG Software Design (Cont’d) • Some consider software design to be a “black art”: – difficult to prescribe how to do it – hard to measure a good design objectively – “I know a good design when I see it.” Software Design (Introduction) © SERG Requirements Engineering: An Overview • Basic goal: To understand the problem as perceived by the user. • Activities of RE are problem oriented. – Focus on what, not how – Don’t cloud the RD with unnecessary detail – Don’t pre-constrain design. • After RE is done, do software design: – solution oriented – how to implement the what Software Design (Introduction) © SERG Requirements Engineering: An Overview • Key to RE is good communication between customer and developers. • Work from Requirements Document as guide. Software Design (Introduction) © SERG Requirements Engineering • Basically, it’s the process of determining and establishing the precise expectations of the customer about the proposed software system. Software Design (Introduction) © SERG The Two Kinds of Requirements • Functional: The precise tasks or functions the system is to perform. – e.g., details of a flight reservation system • Non-functional: Usually, a constraint of some kind on the system or its construction – e.g., expected performance and memory requirements, process model used, implementation language and platform, compatibility with other tools, deadlines, ..
    [Show full text]
  • Govt Linux Appreciation Day 09/18/01
    John Terpstra Vice President, Technology Caldera International, Inc. The Maturation of Linux Are we there yet? Slide 2 The Road to Maturity . Self-Discipline . Acceptance of Responsibility . Accountability for Actions Slide 3 MarketMarket Share 1999 Worldwide Market for Server Operating Environments N = 5.475 Million Shipments Other NOS Netware 2.6% 19.4% NT Server 38.1% Unix & Linux 39.9% Source: IDC Slide 4 Linux Server Applications Primary Function of Linux Servers Installed at U.S. Sites, 1999 Web Server 42.1% Overwhelming File/Print Server 26.0% appeal as a Web Email Server 23.2% DNS 15.3% server – over 50% Firewall/Proxy/Cache 14.7% of all Internet Internet/Intranet Server 12.6% Web Servers run Database 10.5% on Apache and Application Development 8.4% Application server 6.3% 60% of all Apache Experimental/Testing 6.3% Servers run on Router/Gateway 5.8% Linux Networking 2.6% Systems Mgmt. 2.1% Backup 2.1% VPN 1.6% Technical Apps 1.1% Other 1.1% 0% 10% 20% 30% 40% 50% Source: IDC N=195 Slide 5 Where Are We? 1. File and Print – 10 Million servers - Major application - Samba 2. Web Serving – 18 Million servers - Major application - Apache 3. Proxy Serving - - Major application – Squid Linux plays a major role hosting each application Slide 6 A Competitive View – Then http://www.microsoft.com/windows/serverappliance/kempin.asp Date: Nov 9, 2000 But it is true that Linux are actually rapidly increasing their market share in the US also. Doesn't this pose a threat? "Linux is simply a fad that has been generated by the media and is destined to fall by the wayside in time.
    [Show full text]
  • Netiq® Cloudaccess and Mobileaccess Installation and Configuration Guide
    NetIQ® CloudAccess and MobileAccess Installation and Configuration Guide September 2014 www.netiq.com/documentation Legal Notice THIS DOCUMENT AND THE SOFTWARE DESCRIBED IN THIS DOCUMENT ARE FURNISHED UNDER AND ARE SUBJECT TO THE TERMS OF A LICENSE AGREEMENT OR A NON-DISCLOSURE AGREEMENT. EXCEPT AS EXPRESSLY SET FORTH IN SUCH LICENSE AGREEMENT OR NON-DISCLOSURE AGREEMENT, NETIQ CORPORATION PROVIDES THIS DOCUMENT AND THE SOFTWARE DESCRIBED IN THIS DOCUMENT "AS IS" WITHOUT WARRANTY OF ANY KIND, EITHER EXPRESS OR IMPLIED, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. SOME STATES DO NOT ALLOW DISCLAIMERS OF EXPRESS OR IMPLIED WARRANTIES IN CERTAIN TRANSACTIONS; THEREFORE, THIS STATEMENT MAY NOT APPLY TO YOU. For purposes of clarity, any module, adapter or other similar material ("Module") is licensed under the terms and conditions of the End User License Agreement for the applicable version of the NetIQ product or software to which it relates or interoperates with, and by accessing, copying or using a Module you agree to be bound by such terms. If you do not agree to the terms of the End User License Agreement you are not authorized to use, access or copy a Module and you must destroy all copies of the Module and contact NetIQ for further instructions. This document and the software described in this document may not be lent, sold, or given away without the prior written permission of NetIQ Corporation, except as otherwise permitted by law. Except as expressly set forth in such license agreement or non-disclosure agreement, no part of this document or the software described in this document may be reproduced, stored in a retrieval system, or transmitted in any form or by any means, electronic, mechanical, or otherwise, without the prior written consent of NetIQ Corporation.
    [Show full text]
  • The History of Computing in the History of Technology
    The History of Computing in the History of Technology Michael S. Mahoney Program in History of Science Princeton University, Princeton, NJ (Annals of the History of Computing 10(1988), 113-125) After surveying the current state of the literature in the history of computing, this paper discusses some of the major issues addressed by recent work in the history of technology. It suggests aspects of the development of computing which are pertinent to those issues and hence for which that recent work could provide models of historical analysis. As a new scientific technology with unique features, computing in turn can provide new perspectives on the history of technology. Introduction record-keeping by a new industry of data processing. As a primary vehicle of Since World War II 'information' has emerged communication over both space and t ime, it as a fundamental scientific and technological has come to form the core of modern concept applied to phenomena ranging from information technolo gy. What the black holes to DNA, from the organization of English-speaking world refers to as "computer cells to the processes of human thought, and science" is known to the rest of western from the management of corporations to the Europe as informatique (or Informatik or allocation of global resources. In addition to informatica). Much of the concern over reshaping established disciplines, it has information as a commodity and as a natural stimulated the formation of a panoply of new resource derives from the computer and from subjects and areas of inquiry concerned with computer-based communications technolo gy.
    [Show full text]
  • An Overview of Software Evolution
    An Overview of Software Evolution CPRE 416-Software Evolution and Maintenance-Lecture 2 1 Software Evolution • What is it? • How important is it? • What to do about it? 2 An early history of software engineering • The following slides provide a condensation of the ideas of Robert L. Glass in his book "In the Beginning: Recollections of Software Pioneers" about the history of software engineering. 3 The Pioneering Era (1955-1965) • New computers were coming out every year or two. • Programmers did not have computers on their desks and had to go to the "machine room". • Jobs were run by signing up for machine time. Punch cards were used. • Computer hardware was application-specific. Scientific and business tasks needed different machines. 4 The Pioneering Era (1955-1965) • High-level languages like FORTRAN, COBOL, and ALGOL were developed. • No software companies were selling packaged software. • Academia did not yet teach the principles of computer science. 5 The Stabilizing Era (1965-1980) • Came the IBM 360. • This was the largest software project to date. • The 360 also combined scientific and business applications onto one machine. 6 The Stabilizing Era (1965-1980) • Programmers had to use the job control language (JCL) to tell OS what to do. • PL/I, introduced by IBM to merge all programming languages into one, failed. • The notion of timesharing emerged. • Software became a corporate asset and its value became huge. • Academic computing started in the late 60's. • Software engineering discipline did not yet exist. 7 The Stabilizing Era (1965-1980) • High-hype disciplines like Artificial Intelligence emerged.. • Structured Programming burst on the scene.
    [Show full text]