DOCSLIB.ORG

User-Centered Design of Principled Programming Languages Michael J

Total Page：16

File Type：pdf, Size：1020Kb

Download full-text PDF Read full-text

Load more

User-Centered Design of Principled Programming Languages Michael J. Coblenz CMU-CS-20-127 August 2020 Computer Science Department School of Computer Science Carnegie Mellon University Pittsburgh, PA 15213 Thesis Committee: Jonathan Aldrich (Co-Chair) Brad A. Myers (Co-Chair) Frank Pfenning Joshua Sunshine Gail C. Murphy (University of British Columbia) Submitted in partial fulfillment of the requirements for the degree of Doctor of Philosophy. Copyright © 2020 Michael J. Coblenz This research was sponsored by the National Security Agency Department of Defense award H9823018D0008; by the National Science Foundation awards CNS1423054 and CCF1901033; by the United States Air Force Office of Scientific Research award FA8702-15-D-0002; by two IBM PhD Fellowship awards; and by Ripple. The views and conclusions contained in this document are those of the author and should not be interpreted as representing the official policies, either expressed or implied, of any sponsoring institution, the U.S. government or any other entity. Keywords: user-centered programming language design, usability of programming languages, smart contract languages, immutability, blockchain, empirical studies of programmers I dedicate this dissertation to my wife, Lauren, who has supported me and encouraged me to pursue this work. I also dedicate this dissertation to my children, Rebecca and Hannah. I hope that the work I do will make the world a better place in which they can live, and I am thankful for their support as I conducted this research. iv Abstract Programming languages exist to enable people to create and maintain software as effectively as possible. They are subject to two very different sets of requirements: first, the need to provide strong safety guarantees to protect against bugs; and sec- ond, the need for users to effectively and efficiently write software that meets their functional and quality requirements. This thesis argues that fusing formal methods for reasoning about programming languages with user-centered design methods is a practical approach to designing languages that make programmers more effective. By doing so, designers can create safer languages that are more effective for programmers than existing languages. The thesis is substantiated by the introduction of PLIERS: Programming Language Iterative Evaluation and Refinement System. PLIERS is a process for designing programming languages that integrates formal methods with user-centered design. The hypothesis that PLIERS is beneficial is supported by two language design projects. In these projects, I show how PLIERS benefits the programming language design process. Glacier is an extension to Java that enforces transitive class im- mutability, which is a much stronger property than that provided by languages that are in use today. Although there are hundreds of possible ways of restricting changes to state in programming languages, Glacier occupies a point in the design space that was justified by interview studies with professional software engineers. I evaluated Glacier in case studies, showing that it is expressive enough for some real-world applications. I also evaluated Glacier in lab studies and compared it to Java’s final keyword, finding both that Glacier is more effective at expressing immutability than final and that Glacier detects bugs that users are likely to insert in code. Blockchains are a distributed computing platform that aim to enable safe compu- tation among users who do not necessarily trust each other. To improve safety relative to existing languages, in which programmers have repeatedly deployed software with serious bugs, I designed Obsidian, a new programming language for blockchain application development. From observations about typical blockchain applications, I derived two features that motivated the design of Obsidian. First, blockchain ap- plications typically implement state machines, which support different operations in different states. Obsidian uses typestate, which lifts dynamic state into static types, to provide static guarantees regarding object state. Second, blockchain applications frequently manipulate resources, such as virtual currency. Obsidian provides a notion of ownership, which distinguishes one reference from all others. Obsidian supports resources via linear types, which ensure that owning references to resources are not accidentally lost. The combination of resources and typestate results in a novel set of design problems for the type system; although each idea has been explored individually, combining them requires unifying different perspectives on linearity. Furthermore, no language with either one of these features has been designed in a user-centered way or evaluated with users. Typical typestate systems have a complex set of permissions that provides safety properties, but these systems focused on expressiveness rather than on usability. Obsidian integrates typestate and resources in a novel way, resulting in a new type system design with a focus on simplicity and usability while retaining the desired safety properties. Obsidian is based on a core calculus I designed, Silica, for which I proved type soundness. In order to make Obsidian as usable as possible, I based its design on the results of formative studies with programmers. I evaluated Obsidian with two case studies, showing that Obsidian can be used to implement relevant programs. I also conducted a randomized controlled trial comparing Obsidian to Solidity, a popular language for writing smart contracts. I found that most of the Obsidian participants learned Obsidian and completed programming tasks after only a short training period; further, in one task, 70% of the participants who used Solidity accidentally inserted bugs that Obsidian’s compiler would have detected. Finally, Obsidian participants completed significantly more tasks correctly than did Solidity participants. vi Acknowledgments First, I thank my advisors, Jonathan Aldrich and Brad Myers, and my unofficial advisor, Joshua Sunshine, who have nurtured my research career and consistently supported me in achieving my research goals. I am grateful for their technical guidance, their counsel in choosing research directions, and their mentorship. Next, I am grateful for the amazing community at Carnegie Mellon, which has helped me flourish as a researcher and an educator. I have had wonderful conversations with Karl Crary, Andrew Faulring, Matt Fredrikson, Anna Gommerstadt, Claire Le Goues, Mor Harchol-Balter, Michael Hilton, Jan Hoffman, Eliezer Kanal, Christian Kastner,¨ Amy Ko, Stefan Muller, Cyrus Omar, Bryan Parno, Andre Platzer, Frank Pfenning, Michael Sullivan, Mary Shaw. I am particularly grateful for Jenna Wise’s help with the Obsidian formative studies. I also appreciate feedback from and discussions with James Noble and Alex Potanin. Thank you to Gail Murphy for helpful advice as a member of my thesis committee and as part of the ICSE Doctoral Symposium in 2017, and to Frank Pfenning for being part of my thesis committee. I appreciate assistance from Werner Dietl, Michael Ernst, and Suzanne Millstein in understanding the details of IGJ. I also appreciate the help of the team at ZKoss. I am grateful for the help of my numerous experiment participants, who will remain anonymous. Thanks go to Rick Hull, Jim Laredo, Petr Novotny, and Yunhui Zheng at IBM, who provided useful technical and real-world insight during the Obsidian project. Thank you also to David Gould and Georgi Panterov at the World Bank, with whom I worked on the insurance case study. Undergraduate and masters students made significant contributions to this work, and I enjoyed working with them immensely: Gauri Agarwal, Ishan Bhargava, Yan- nick Bloem, Suzz Glennon, Sachi Sharma, and Bobby Zhang. I am particularly grateful for students who spent an entire summer working with me through the Research Experience for Undergraduates in Software Engineering program: Miles Baker, Celeste Barnaby, Tyler Etzel, Gauri Kambhatla, Paulette Koronkevich, Whit- ney Nelson, and Reed Oei. I have learned much working with all of these students. I am grateful to all of my colleagues in the iWork group at Apple, who taught me so much about how to write great software. Finally, special thanks to my wife, Lauren, and my daughters Hannah and Rebecca, for the constant encouragement and support, as well as for facilitating all of the travel that is required to participate in the international research community. Likewise to my parents, Deborah and Robert, who nurtured my fascination with computers since I was a young child; to my brother, Joshua, for his support; and to my aunt Norma, who introduced me to computing at a young age at a time when very few people had personal computers (1985). viii Contents 1 Introduction 1 1.1 Thesis Statement . .3 1.2 Glacier . .3 1.3 Obsidian . .4 1.4 Technical contributions . .5 1.4.1 Immutability . .5 1.4.2 Glacier . .5 1.4.3 Obsidian . .6 1.5 Methodological Contributions . .7 1.6 Thesis Outline . .9 2 Related Work 11 2.1 Human-centered programming language design . 11 2.2 Design Methods . 14 2.2.1 Methods for Requirements and Creation . 14 2.2.2 Methods for Evaluation . 17 2.3 Immutability Systems . 19 2.4 Blockchain Programming Languages . 20 2.4.1 Smart contract languages . 20 2.5 Aliasing, Permissions, and Linearity . 21 2.6 Typestate . 22 3 PLIERS: A User-Centered Process for Programming Language Design 23 3.1 Introduction . 23 3.2 PLIERS . 27 3.2.1 Evaluating PLIERS . 31 4 Exploring Immutability Features 33 4.1 Introduction . 33 4.2 Overview of Concepts . 34 4.2.1 Type of Restriction . 34 4.2.2 Scope . 35 4.2.3 Transitivity . 35 4.2.4 Initialization . 36 ix 4.2.5 Abstract vs. Concrete State . 36 4.2.6 Backward Compatibility . 36 4.2.7 Enforcement . 37 4.2.8 Polymorphism . 37 4.3 A Survey of Existing Systems . 37 4.3.1 Historical and Research Systems . 39 4.3.2 Popular Languages and Libraries . 41 4.3.3 Empirical Evaluations . 42 4.4 Usability of Features . 43 4.5 Interviews with Developers . 45 4.5.1 Methodology . 45 4.5.2 Results . 47 4.5.3 Implications on language design .
Recommended publications
  • Programming Languages & Paradigms Abstraction & Modularity

    Programming Languages & Paradigms Abstraction & Modularity

    Programming Languages & Paradigms PROP HT 2011 Abstraction & Modularity Lecture 6 Inheritance vs. delegation, method vs. message Beatrice Åkerblom [email protected] 2 Thursday, November 17, 11 Thursday, November 17, 11 Modularity Modularity, cont’d. • Modular Decomposability • Modular Understandability – helps in decomposing software problems into a small number of less – if it helps produce software in which a human reader can understand complex subproblems that are each module without having to know the others, or (at worst) by •connected by a simple structure examining only a few others •independent enough to let work proceed separately on each item • Modular Continuity • Modular Composability – a small change in the problem specification will trigger a change of – favours the production of software elements which may be freely just one module, or a small number of modules combined with each other to produce new systems, possibly in a new environment 3 4 Thursday, November 17, 11 Thursday, November 17, 11 Modularity, cont’d. Classes aren’t Enough • Modular Protection • Classes provide a good modular decomposition technique. – the effect of an error at run-time in a module will remain confined – They possess many of the qualities expected of reusable software to that module, or at worst will only propagate to a few neighbouring components: modules •they are homogenous, coherent modules •their interface may be clearly separated from their implementation according to information hiding •they may be precisely specified • But more is needed to fully achieve the goals of reusability and extendibility 5 6 Thursday, November 17, 11 Thursday, November 17, 11 Polymorphism Static Binding • Lets us wait with binding until runtime to achieve flexibility • Function call in C: – Binding is not type checking – Bound at compile-time – Allocate stack space • Parametric polymorphism – Push return address – Generics – Jump to function • Subtype polymorphism – E.g.
  • Concepts of Object-Oriented Programming AS 2019

    Concepts of Object-Oriented Programming AS 2019

    Concepts of Object-Oriented Programming AS 2019 Exercise 6 Multiple Inheritance, Multiple Dispatch and Linearization November 1, 2019 Task 1 (from a previous exam) Consider the following C++ program: class X{ public: X(int p) : fx(p) {} int fx; }; class Y{ public: Y(int p) : fy(p) {} int fy; }; class B: public virtual X,public Y{ public: B(int p) : X(p-1),Y(p-2){} }; class C: public virtual X,public Y{ public: C(int p) : X(p+1),Y(p+1){} }; class D: public B, public C{ public: D(int p) : X(p-1), B(p-2), C(p+1){} }; int main() { D* d = new D(5); B* b = d; C* c = d; std::cout << b->fx << b->fy << c->fx << c->fy; return 0; } What is the output of running the program? (a) 5555 (b) 2177 (c) CORRECT: 4147 (d) 7177 (e) 7777 (f) None of the above Task 2 (from a previous exam) Consider the following Java classes: class A{ public void foo (Object o) { System.out.println("A"); } } class B{ public void foo (String o) { System.out.println("B"); } } class C extends A{ public void foo (String s) { System.out.println("C"); } } class D extends B{ public void foo (Object o) { System.out.println("D"); } } class Main { public static void main(String[] args) { A a = new C(); a.foo("Java"); C c = new C(); c.foo("Java"); B b = new D(); b.foo("Java"); D d = new D(); d.foo("Java"); } } What is the output of the execution of the method main in class Main? (a) The code will print A C B D (b) CORRECT: The code will print A C B B (c) The code will print C C B B (d) The code will print C C B D (e) None of the above Task 3 Consider the following C# classes: public class
  • Methods & Tools

    Methods & Tools

    METHODS & TOOLS Practical knowledge for the software developer, tester and project manager ISSN 1661-402X Spring 2011 (Volume 19 - number 1) www.methodsandtools.com The Salesmen/Developers Ratio at Software Vendors Many of us might think that software is a technological industry. Maybe. But maybe not. If you consider Oracle or Microsoft, I suppose that few of us would consider them as technology leaders, but we will all recognize their financial strength and marketing power. Long lasting organizations in the software industry might have more financial strength than technological capabilities. The recent conflict between Oracle and the creator of Hudson, an open source continuous integration server, is just another episode in the opposition between developers- and salesmen-driven software companies. On one side you have Oracle, for which Hudson is just small project inherited from the Sun buyout and that owns the "Hudson" brand. On the other side, you find Kohsuke Kawaguchi, who created Hudson and wants keep some control on its development. Hudson has been "forked", the open source code being used to start another project. You now have a Jenkins CI project that includes most of the active Hudson contributors and a Hudson CI project backed by Oracle and Sonatype, the commercial company behind the Maven project. Everything is however not black and white. Kohsuke Kawaguchi has joined Cloudbees, a company that has some management and financing coming from ex-JBoss managers, people that know how to make money with open source software. These people are not working hard for the only sake of technology evolution. You can judge the main orientation of a company looking at its salesmen/developers ratios.
  • Safely Creating Correct Subclasses Without Superclass Code Clyde Dwain Ruby Iowa State University

    Safely Creating Correct Subclasses Without Superclass Code Clyde Dwain Ruby Iowa State University

    Iowa State University Capstones, Theses and Retrospective Theses and Dissertations Dissertations 2006 Modular subclass verification: safely creating correct subclasses without superclass code Clyde Dwain Ruby Iowa State University Follow this and additional works at: https://lib.dr.iastate.edu/rtd Part of the Computer Sciences Commons Recommended Citation Ruby, Clyde Dwain, "Modular subclass verification: safely creating correct subclasses without superclass code " (2006). Retrospective Theses and Dissertations. 1877. https://lib.dr.iastate.edu/rtd/1877 This Dissertation is brought to you for free and open access by the Iowa State University Capstones, Theses and Dissertations at Iowa State University Digital Repository. It has been accepted for inclusion in Retrospective Theses and Dissertations by an authorized administrator of Iowa State University Digital Repository. For more information, please contact [email protected]. Modular subclass verification: Safely creating correct subclasses without superclass code by Clyde Dwain Ruby A dissertation submitted to the graduate faculty in partial fulfillment of the requirements for the degree of DOCTOR OF PHILOSOPHY Major: Computer Science Program of Study Committee Gary T. Leavens, Major Professor Samik Basu Clifford Bergman Shashi K. Gadia Jonathan D. H. Smith Iowa State University Ames, Iowa 2006 Copyright © Clyde Dwain Ruby, 2006. All rights reserved. UMI Number: 3243833 Copyright 2006 by Ruby, Clyde Dwain All rights reserved. UMI Microform 3243833 Copyright 2007 by ProQuest Information and Learning Company. All rights reserved. This microform edition is protected against unauthorized copying under Title 17, United States Code. ProQuest Information and Learning Company 300 North Zeeb Road P.O. Box 1346 Ann Arbor, MI 48106-1346 ii TABLE OF CONTENTS ACKNOWLEDGEMENTS .
  • Safely Creating Correct Subclasses Without Seeing Superclass Code

    Safely Creating Correct Subclasses Without Seeing Superclass Code

    Safely Creating Correct Subclasses without Seeing Superclass Code Clyde Ruby and Gary T. Leavens TR #00-05d April 2000, revised April, June, July 2000 Keywords: Downcalls, subclass, semantic fragile subclassing problem, subclassing contract, specification inheritance, method refinement, Java language, JML language. 1999 CR Categories: D.2.1 [Software Engineering] Requirements/Specifications — languages, tools, JML; D.2.2 [Software Engineering] Design Tools and Techniques — Object-oriented design methods, software libraries; D.2.3 [Software Engineering] Coding Tools and Techniques — Object-oriented programming; D.2.4 [Software Engineering] Software/Program Verification — Class invariants, correctness proofs, formal methods, programming by contract, reliability, tools, JML; D.2.7 [Software Engineering] Distribution, Maintenance, and Enhancement — Documentation, Restructuring, reverse engineering, and reengi- neering; D.2.13 [Software Engineering] Reusable Software — Reusable libraries; D.3.2 [Programming Languages] Language Classifications — Object-oriented langauges; D.3.3 [Programming Languages] Language Constructs and Features — classes and objects, frameworks, inheritance; F.3.1 [Logics and Meanings of Programs] Specifying and Verifying and Reasoning about Programs — Assertions, invariants, logics of programs, pre- and post-conditions, specification techniques; To appear in OOPSLA 2000, Minneapolis, Minnesota, October 2000. Copyright c 2000 ACM. Permission to make digital or hard copies of this work for personal or classroom use is granted without fee provided that copies are not made or distributed for profit or commercial advantage and that copies bear this notice and the full citation on the first page. To copy otherwise, or republish, to post on servers or to redistribute to lists, requires prior specific permission and/or a fee. Department of Computer Science 226 Atanasoff Hall Iowa State University Ames, Iowa 50011-1040, USA Safely Creating Correct Subclasses without Seeing Superclass Code ∗ Clyde Ruby and Gary T.
  • Summer 2012 (Volume 20 - Number 2)

    Summer 2012 (Volume 20 - Number 2)

    METHODS & TOOLS Practical knowledge for the software developer, tester and project manager ISSN 1661-402X Summer 2012 (Volume 20 - number 2) www.methodsandtools.com Do Software Developers Want to Be Managers? According to surveys, Agile is now implemented by a majority of organizations and Scrum is the project management framework the most widely used. A characteristic of Scrum teams is that they are (or should be) self-organized. Team members are now responsible to divide between themselves the workload and they will need to deal with conflicts between team members. The former project manager authority and responsibilities are spread amongst the Scrum team. But do Agile developers really want this? Self-organization relies on the ability of team members to communicate and negotiate. The transition from a hierarchical team organization to a flat relationship where everybody participates is not easy and faces many challenges. Software developers have in majority an introverted personality type and this is not the best setting to interact with colleagues or even just to express needs or feelings. Teams might end us as just being organized by the most vocal members. Another implied hypothesis of self-organization is that all team members should have an equal weight in decisions, even if technical superiority or leadership might be recognized. This might not exist when you have teams that mix internal employees and contractors that might be denied authority. Self- organization also works in a culture of individual responsibility, affirmation and (positive) contradiction. This is not always the case in all organizations or countries. The team has now to deal with non-performing members, people that are either technically limited or that have a difficult personality.
  • {Download PDF} Use Cases Requirements in Context 2Nd Edition

    {Download PDF} Use Cases Requirements in Context 2Nd Edition

    USE CASES REQUIREMENTS IN CONTEXT 2ND EDITION PDF, EPUB, EBOOK Daryl Kulak | --- | --- | --- | 9780321154989 | --- | --- R.S. Pressman & Associates, Inc. Managing Software Requirements, Second Edition , specifically addresses the ongoing challenge of managing change and describes a process for assuring that project scope is successfully defined and agreed upon by all stakeholders. Domain-Driven Design DDD software modeling delivers powerful results in practice, not just in theory, which is …. It is a very good book made …. Being a successful software architect is more than just possessing technical knowledge. Upon completion of an object-oriented design, you are faced with a troubling question: "Is it good, …. Skip to main content. Start your free trial. Book description "Many projects fail because developers fail to build the right thing. Topics covered include: The five steps in problem analysis Business modeling and system engineering Techniques for eliciting requirements from customers and stakeholders Establishing and managing project scope Applying and refining use cases Product management Transitioning from requirements to design and implementation Transitioning from use cases to test cases Agile requirements methods XB Show and hide more. Use case diagrams are typically developed in the early stage of development and people often apply use case modeling for the following purposes:. A standard form of use case diagram is defined in the Unified Modeling Language as shown in the Use Case Diagram example below:. Use cases share different kinds of relationships. Defining the relationship between two use cases is the decision of the software analysts of the use case diagram. A relationship between two use cases is basically modeling the dependency between the two use cases.
  • Programming-In-Scala.Pdf

    Programming-In-Scala.Pdf

    Cover · Overview · Contents · Discuss · Suggest · Glossary · Index Programming in Scala Cover · Overview · Contents · Discuss · Suggest · Glossary · Index Programming in Scala Martin Odersky, Lex Spoon, Bill Venners artima ARTIMA PRESS MOUNTAIN VIEW,CALIFORNIA Cover · Overview · Contents · Discuss · Suggest · Glossary · Index iv Programming in Scala First Edition, Version 6 Martin Odersky is the creator of the Scala language and a professor at EPFL in Lausanne, Switzerland. Lex Spoon worked on Scala for two years as a post-doc with Martin Odersky. Bill Venners is president of Artima, Inc. Artima Press is an imprint of Artima, Inc. P.O. Box 390122, Mountain View, California 94039 Copyright © 2007, 2008 Martin Odersky, Lex Spoon, and Bill Venners. All rights reserved. First edition published as PrePrint™ eBook 2007 First edition published 2008 Produced in the United States of America 12 11 10 09 08 5 6 7 8 9 ISBN-10: 0-9815316-1-X ISBN-13: 978-0-9815316-1-8 No part of this publication may be reproduced, modified, distributed, stored in a retrieval system, republished, displayed, or performed, for commercial or noncommercial purposes or for compensation of any kind without prior written permission from Artima, Inc. All information and materials in this book are provided "as is" and without warranty of any kind. The term “Artima” and the Artima logo are trademarks or registered trademarks of Artima, Inc. All other company and/or product names may be trademarks or registered trademarks of their owners. Cover · Overview · Contents · Discuss · Suggest · Glossary · Index to Nastaran - M.O. to Fay - L.S. to Siew - B.V.
  • Selective Open Recursion: a Solution to the Fragile Base Class Problem

    Selective Open Recursion: a Solution to the Fragile Base Class Problem

    Selective Open Recursion: A Solution to the Fragile Base Class Problem Jonathan Aldrich School of Computer Science Carnegie Mellon University 5000 Forbes Avenue Pittsburgh, PA 15213, USA [email protected] ABSTRACT public class CountingSet extends Set { private int count; Current object-oriented languages do not fully protect the implementation details of a class from its subclasses, mak- public void add(Object o) { ing it difficult to evolve that implementation without break- super.add(o); ing subclass code. Previous solutions to the so-called fragile count++; base class problem specify those implementation dependen- } cies, but do not hide implementation details in a way that al- public void addAll(Collection c) { lows effective software evolution. super.addAll(c); In this paper, we show that the fragile base class problem count += c.size(); arises because current object-oriented languages dispatch } methods using open recursion semantics even when these se- public int size() { mantics are not needed or wanted. Our solution is to make return count; explicit the methods to which open recursion should apply. } We propose to change the semantics of object-oriented dis- } patch, such that all calls to “open” methods are dispatched dynamically as usual, but calls to “non-open” methods are dispatched statically if called on the current object this, but Figure 1: The correctness of the CountingSet class de- dynamically if called on any other object. By specifying a pends on the independence of add and addAll in the im- method as open, a developer is promising that future ver- plementation of Set. If the implementation is changed sions of the class will make internal calls to that method in so that addAll uses add, then count will be incremented exactly the same way as the current implementation.
  • Why Objects Are Inevitable

    Why Objects Are Inevitable

    The Power of Interoperability: Why Objects Are Inevitable Onward! Essay, 2013 http://www.cs.cmu.edu/~aldrich/papers/objects-essay.pdf Comments on this work are welcome. Please send them to aldrich at cmu dot edu Jonathan Aldrich Institute for Software Research School of Computer Science Carnegie Mellon University Copyright © 2013 by Jonathan Aldrich. This work is made available under the terms of the Creative Commons Attribution-ShareAlike 3.0 license: http://creativecommons.org/licenses/by-sa/3.0/ Object-Oriented Programming is Widespread 6-8 of top 10 PLs are OO – TIOBE 3 Object-Oriented Programming is Influential • Major conferences: OOPSLA, ECOOP • Turing awards for Dahl and Nygaard, and Kay • Other measures of popularity • Langpop.com: 6-8 of most popular languages • SourceForge: Java, C++ most popular • GitHub: JavaScript, Ruby most popular • Significant use of OO design even in procedural languages • Examples: GTK+, Linux kernel, etc. • Why this success? 4 OOP Has Been Criticized “I find OOP technically unsound… philosophically unsound… [and] methodologically wrong. ” - Alexander Stepanov, developer of the C++ STL 5 Why has OOP been successful? 6 Why has OOP been successful? “…it was hyped [and] it created a new software industry.” - Joe Armstrong, designer of Erlang Marketing/adoption played a role in the ascent of OOP. But were there also genuine advantages of OOP? 7 Why has OOP been successful? “the object-oriented paradigm...is consistent with the natural way of human thinking” - [Schwill, 1994] OOP may have psychological benefits. But is there a technical characteristic of OOP that is critical for modern software? 8 What kind of technical characteristic? Talk Outline 1.
  • Fragile Base-Class Problem, Problem?

    Fragile Base-Class Problem, Problem?

    Noname manuscript No. (will be inserted by the editor) Fragile Base-class Problem, Problem? Aminata Saban´e · Yann-Ga¨elGu´eh´eneuc · Venera Arnaoudova · Giuliano Antoniol Received: date / Accepted: date Abstract The fragile base-class problem (FBCP) has likely to change nor more likely to have faults. Qualita- been described in the literature as a consequence of tively, we conduct a survey to confirm/infirm that some \misusing" inheritance and composition in object-orien- bugs are related to the FBCP. The survey involves 41 ted programming when (re)using frameworks. Many re- participants that analyse a total of 104 bugs of three search works have focused on preventing the FBCP by open-source systems. Results indicate that none of the proposing alternative mechanisms for reuse, but, to the analysed bugs is related to the FBCP. best of our knowledge, there is no previous research Thus, despite large, rigorous quantitative and quali- work studying the prevalence and impact of the FBCP tative studies, we must conclude that the two aspects of in real-world software systems. The goal of our work is the FBCP that we analyse may not be as problematic thus twofold: (1) assess, in different systems, the preva- in terms of change and fault-proneness as previously lence of micro-architectures, called FBCS, that could thought in the literature. We propose reasons why the lead to two aspects of the FBCP, (2) investigate the re- FBCP may not be so prevalent in the analysed systems lation between the detected occurrences and the quality and in other systems in general.
  • =5Cm Cunibig Concepts in Programming Languages

    =5Cm Cunibig Concepts in Programming Languages

    Concepts in Programming Languages Alan Mycroft1 Computer Laboratory University of Cambridge 2016–2017 (Easter Term) www.cl.cam.ac.uk/teaching/1617/ConceptsPL/ 1Acknowledgement: various slides are based on Marcelo Fiore’s 2013/14 course. Alan Mycroft Concepts in Programming Languages 1 / 237 Practicalities I Course web page: www.cl.cam.ac.uk/teaching/1617/ConceptsPL/ with lecture slides, exercise sheet and reading material. These slides play two roles – both “lecture notes" and “presentation material”; not every slide will be lectured in detail. I There are various code examples (particularly for JavaScript and Java applets) on the ‘materials’ tab of the course web page. I One exam question. I The syllabus and course has changed somewhat from that of 2015/16. I would be grateful for comments on any remaining ‘rough edges’, and for views on material which is either over- or under-represented. Alan Mycroft Concepts in Programming Languages 2 / 237 Main books I J. C. Mitchell. Concepts in programming languages. Cambridge University Press, 2003. I T.W. Pratt and M. V.Zelkowitz. Programming Languages: Design and implementation (3RD EDITION). Prentice Hall, 1999. ? M. L. Scott. Programming language pragmatics (4TH EDITION). Elsevier, 2016. I R. Harper. Practical Foundations for Programming Languages. Cambridge University Press, 2013. Alan Mycroft Concepts in Programming Languages 3 / 237 Context: so many programming languages Peter J. Landin: “The Next 700 Programming Languages”, CACM (published in 1966!). Some programming-language ‘family trees’ (too big for slide): http://www.oreilly.com/go/languageposter http://www.levenez.com/lang/ http://rigaux.org/language-study/diagram.html http://www.rackspace.com/blog/ infographic-evolution-of-computer-languages/ Plan of this course: pick out interesting programming-language concepts and major evolutionary trends.