Unit tests are a tenant of agile programming methodologies, and are widely used to improve code quality and prevent code regression. A green (passing) test is usually taken as a robust sign that the code under test is valid. However, some green tests contain assertions that are never executed. We call such tests Rotten Green Tests. Rotten Green Tests represent a case worse than a broken test: they report that the code under test is valid, but in fact do not test that validity. We describe an approach to identify rotten green tests by combining simple static and dynamic call-site analyses. Our approach takes into account test helper methods, inherited helpers, and trait compositions, and has been implemented in a tool called DrTest. DrTest reports no false negatives, yet it still reports some false positives due to conditional use or multiple test contexts. Using DrTest we conducted an empirical evaluation of 19,905 real test cases in mature projects of the Pharo ecosystem. The results of the evaluation show that the tool is effective; it detected 294 tests as rotten-green tests that contain assertions that are not executed. Some rotten tests have been “sleeping” in Pharo for at least 5 years.

Many programming language constructs that support software engineering in the large - explicit variable declarations, explicit external dependencies, static types, information hiding, invariants-provide little benefit to the small programs written by novice programmers, where every extra syntactic token has to be explained and understood before novices can succeed in running even the simplest program. We are designing Grace, a new educational object-oriented language that we hope will prove useful for teaching both programming and software engineering. This paper describes some of the tradeoffs between teaching programming and teaching software engineering that we faced while designing Grace, and our attempts to address those tradeoffs.

Grace is a new object-oriented language that supports a variety of approaches to teaching programming. It integrates accepted new ideas in programming languages into a simple language that allows students and teachers to focus on the essential complexities of programming rather than the accidental complexities of the language. We motivate Grace, review its design, and evaluate it against Kolling's criteria.

Object orientation and pattern matching are often seen as conflicting approaches to program design. Object-oriented programs place type-dependent behavior inside objects and invoke it via dynamic dispatch, while pattern-matching programs place type-dependent behavior outside data structures and invoke it via multiway conditionals (case statements).

No abstract available.

Refactoring tools, common to many integrated development environments, can help programmers to restructure their code. These tools sometimes refuse to restructure the programmer's code, instead giving the programmer a textual error message that she must decode if she wishes to understand the reason for the tool's refusal and what corrective action to take. This paper describes a graphical alternative to textual error messages called Refactoring Annotations. It reports on two experiments, one using an integrated development environment and the other using paper mockups, that show that programmers can use Refactoring Annotations to quickly and accurately understand the cause of refactoring errors.

Refactoring is widely practiced by developers, and considerable research and development effort has been invested in refactoring tools. However, little has been reported about the adoption of refactoring tools, and many assumptions about refactoring practice have little empirical support. In this paper, we examine refactoring tool usage and evaluate some of the assumptions made by other researchers. To measure tool usage, we randomly sampled code changes from four Eclipse and eight Mylyn developers and ascertained, for each refactoring, if it was performed manually or with tool support. We found that refactoring tools are seldom used: 11 percent by Eclipse developers and 9 percent by Mylyn developers. To understand refactoring practice at large, we drew from a variety of data sets spanning more than 39,000 developers, 240,000 tool-assisted refactorings, 2,500 developer hours, and 12,000 version control commits. Using these data, we cast doubt on several previously stated assumptions about how programmers refactor, while validating others. Finally, we interviewed the Eclipse and Mylyn developers to help us understand why they did not use refactoring tools and to gather ideas for future research.

We present Cloud Haskell, a domain-specific language for developing programs for a distributed computing environment. Implemented as a shallow embedding in Haskell, it provides a message-passing communication model, inspired by Erlang, without introducing incompatibility with Haskell's established shared-memory concurrency. A key contribution is a method for serializing function closures for transmission across the network. Cloud Haskell has been implemented; we present example code and some preliminary performance measurements.

Refactoring is the process of changing the structure of code without changing its meaning, and is a frequent practice among developers. Although programmers refactor frequently, they usually do not use refactoring tools to automate this process. We argue that the need to recall the name of a refactoring before the appropriate tool can be invoked makes it unnecessarily hard to initiate a refactoring with a tool. Conventional ways of initiating a tool also make it hard to transition from novice tool user to expert tool user. The contribution of this paper is a memorable mapping from gestures to refactorings, and an implementation of that mapping in the form of marking menus. In the first reported experiment to explore the effect of the position of items in marking menus on people's ability to infer the location of those items, we asked 16 programmers to complete a paper-based evaluation of our mapping. The results suggest that programmers can infer the gesture that will invoke the appropriate refactoring tool, even if they do not know the name of the refactoring. We also illustrate how marking menus might be used for refactoring during development with two other small studies.

Much of what we know about how programmers refactor in the wild is based on studies that examine just a few software projects. Researchers have rarely taken the time to replicate these studies in other contexts or to examine the assumptions on which they are based. To help put refactoring research on a sound scientific basis, we draw conclusions using four data sets spanning more than 13 000 developers, 240 000 tool-assisted refactorings, 2500 developer hours, and 3400 version control commits. Using these data, we cast doubt on several previously stated assumptions about how programmers refactor, while validating others. For example, we find that programmers frequently do not indicate refactoring activity in commit logs, which contradicts assumptions made by several previous researchers. In contrast, we were able to confirm the assumption that programmers do frequently intersperse refactoring with other program changes. By confirming assumptions and replicating studies made by other researchers, we can have greater confidence that those researchers' conclusions are generalizable.

Refactoring, the process of changing the structure of code without changing its behavior, can be semi-automated with the help of tools. However, many tools do a poor job of communicating errors triggered by the refactoring process. This poor communication causes programmers to refactor slowly, conservatively, and incorrectly. In this paper we demonstrate problems with current refactoring tools, characterize three new tools to assist in refactoring, and describe a user study that compares these new tools against existing tools. The results of the study show that the speed, accuracy, and user satisfaction can be significantly increased The new tools have inspired a set of usability recommendations that we hope will help build a new generation of programmer-friendly refactoring tools.

Inheritance is well-known and accepted as a mechanism for reuse in object-oriented languages. Unfortunately, due to the coarse granularity of inheritance, it may be difficult to decompose an application into an optimal class hierarchy that maximizes software reuse. Existing schemes based on single inheritance, multiple inheritance, or mixins, all pose numerous problems for reuse. To overcome these problems we propose traits , pure units of reuse consisting only of methods. We develop a formal model of traits that establishes how traits can be composed, either to form other traits, or to form classes. We also outline an experimental validation in which we apply traits to refactor a nontrivial application into composable units.

Traits are an object-oriented programming language construct that allow groups of methods to be named and reused in arbitrary places in an inheritance hierarchy. Classes can use methods from traits as well as defining their own methods and instance variables. Traits thus enable a new style of programming, in which traits rather than classes are the primary unit of reuse. However, the additional sub-structure provided by traits is always optional: a class written using traits can also be viewed as a flat collection of methods, with no change in its semantics. This paper describes the tool that supports these two alternate views of a class, called the traits browser, and the programming methodology that we are starting to develop around the use of traits.

Encapsulation in object-oriented languages has traditionally been based on static type systems. As a consequence, dynamically-typed languages have only limited support for encapsulation. This is surprising, considering that encapsulation is one of the most fundamental and important concepts behind object-oriented programming and that it is essential for writing programs that are maintainable and reliable, and that remain robust as they evolve.

Traits are a programming language technology that promote the reuse of methods between unrelated classes. This paper reports on a refactoring of the Smalltalk collections classes using traits. The original collection classes contained much duplication of code; traits let us remove all of it. We also found places where the protocols of the collections lacked uniformity; traits allowed us to correct these non-uniformities without code duplication.Traits also make it possible to reuse fragments of collection code outside of the existing hierarchy; for example, they make it easy to convert other collection-like things into true collections. Our refactoring reduced the number of methods in the collection classes by approximately 10 per cent. More importantly, understandability maintainability and reusability of the code were significantly improved.

Abstract Applications that process continuous information flows are challenging to write because the application programmer must deal with flow‐specific concurrency and timing requirements, necessitating the explicit management of threads, synchronization, scheduling and timing. We believe that middleware can ease this burden, but many middleware platforms do not match the structure of these applications, because they focus on control‐flow centric interaction models such as remote method invocation. Indeed, they abstract away from the very things that the information‐flow centric programmer must control. This paper describes Infopipes—a new high‐level abstraction for information flow applications—and a middleware framework that supports them. Infopipes handle the complexities associated with control flow and multi‐threading, relieving the programmer of these tasks. Starting from a high‐level description of an information flow pipeline, the framework determines which parts of a pipeline require separate threads or coroutines, and handles synchronization transparently to the application programmer. The framework also gives the programmer the freedom to write or reuse components in a passive style, even though the configuration will actually require the use of a thread or coroutine. Conversely, it is possible to write a component using a thread and know that the thread will be eliminated if it is not needed in a pipeline. This allows the most appropriate programming model to be chosen for a given task, and existing code to be reused irrespective of its activity model. Copyright © 2003 John Wiley & Sons, Ltd.

Current RPC mechanisms for persistent languages are either pass by reference-in which case they do not scale-or pass by copy-in which case they duplicate objects and destroy sharing relationships. In this paper we argue that to build very large distributed persistent applications a compromise between these two mechanisms is needed. The ultimate goal of our research is to build a scalable persistent RPC while still maintaining object sharing type safety, type completeness and semantics that are readily understood by application programmers.

Conventionaloperating system code is written to deal with all possible system stat es, and performs considerable interpretation to determine the current system state before taking action.A consequence of this approach is that kernel calls which perform little actual work take a long time to execute.To address this problem, we use specialized operating system code that reduces interpretation for common cases, but still behaves correctly in the fully general case.We describe how specialized operating system code can be generated and bound wtcrementally as the information on which it depends becomes available.We extend our specialization techniques to include the notion of optimistic in c remental specialization n: a technique for generating specialized kernel code optimistically for system states that are likely to occur, but not certain.The ideas outlined in this paper allow the conventional kernel design tenet of "optimizing for the common case" to be extended to the domain of adaptive operating systems.We also show that aggressive use of specialization can produce in-kernel implementations of operating system functionality with performance comparable to user-level implementations.We demonstrate that these ideas are applicable in realworld operating systems by describing a re-implementation of the HP-UX file system.Our specialized read system call reduces the cost of a single byte read by a factor of 3, and an 8 KB read by 26~o, while preserving the semantics of the HP-UXread call.By relaxing the semantics of HP-UX read we were able to cut the cost of a single byte read system call by more than an order of magnitude.1

Abstract Emerald is a general‐purpose language with aspects of traditional object‐oriented languages, such as Smalltalk, and abstract data type languages, such as Modula‐2 and Ada. It is strongly typed with a non‐traditional object model and type system that emphasize abstract types, allow separation of typing and implementation, and provide the flexibility of polymorphism and subtyping with compile‐time checking. This paper describes the Emerald language and its programming methodology. We give examples that demonstrate Emerald's features, and compare and contrast the Emerald approach to programming with the approaches used in other similar languages.

The problems of finding objects in large and wide-area networks where objects may change their location in volatile memory as well as on stable storage are presented. The authors discuss possible solutions and describe those adopted in the Hermes system (a corporate wide, real life office application). They have designed and developed a location-independent-invocation (LII) mechanism that combines finding with invocation, using temporal location information. The mechanism also updates the system's knowledge of an object's location as a side-effect of invocation and object migration. Assumptions about object mobility indicate that objects are likely to be found within a few propagations of an invocation. If they cannot be found in this way, stable-storage and name services are used to locate the object. The major contribution of this work is to show how LII can be achieved in a large and dynamic environment in which objects are supported by neither are operating system nor the programming language.>

A brief overview is presented of work on building a highly distributed office application based on mobile objects. The authors explain the techniques used to find the target of an invocation and describe how the technique is implemented. Location-independent invocation (LII) is presented as a conceptual service that is independent of any particular application, operating system, or programming language. LII completely removes remote call processing buildings from the view of application programmer. It is shown how LII can be implemented without language or system support in any environment that provides reliable interprocess communication. The indications for LII are studied, i.e. under what circumstances the proposed abstractions are beneficial. A description is given of an application domain in which LII is useful and the core services that support it. An object-finding algorithm is described. The relationship of LII to earlier work on object-finding and location independence is included.>

A system is presented for the compact representation of multiple versions of a file. The presentation is in terms of vectors and matrices, which results in conceptual simplicity. Algebraic transformations enable the retrieval process to be optimized for any given version or set of versions, in contrast to always optimizing for the most recent or least recent version. Moreover, any version can be added or deleted without affecting any other. File differencing and dictionary compaction are unified, and data compression can be included. A compact representation for the (sparse) matrices is presented, and the main algorithms are described in terms of this representation.>

Emerald is an object-based language and system designed for the construction of distributed programs. An explicit goal of Emerald is support for object mobility; objects in Emerald can freely move within the system to take advantage of distribution and dynamically changing environments. We say that Emerald has fine-grained mobility because Emerald objects can be small data objects as well as process objects. Fine-grained mobility allows us to apply mobility in new ways but presents implementation problems as well. This paper discusses the benefits of tine-grained mobility, the Emerald language and run-time mechanisms that support mobility, and techniques for implementing mobility that do not degrade the performance of local operations. Performance measurements of the current implementation are included.

This paper describes a new technique for analyzing dynamic file usage patterns based upon classification of file sessions. Afire session Is defined to be the set of operations on a given file from the moment it is opened until the moment it is closed. If file system measurement data is organized into sessions, each session may then be classified by the pattern of file use that it demonstrates. Examination of the overall pattern of file use revealed by this classification leads to valuable insights for file system designers. The technique is Illustrated by applying it to data collected from a UNIX®file system by John Ousterhout at Berkeley [6]. One surprising result was a high incidence of “lock files”.

The Emerald compiler analyzes object definitions and attempts to produce efficient implementations commensurate with the way in which objects are used. For example, an object that moves around the network will require a very general remote procedure call implementation; however, an object that is completely internal to that mobile object can be implemented using direct memory addressing and inline code or procedure calls.We wanted to achieve performance competitive with standard procedural languages in the local case and standard remote procedure call systems in the remote case. These goals are not trivial in a location-independent object-based environment. To meet them, we relied heavily on an appropriate choice of language semantics, a tight coupling between the compiler and run-time kernel, and careful attention to implementation.As an example of Emerald's local performance, Table 1 shows execution times for several local Emerald operations executed on a Micro VAX II1. The “resident global invocation” time is for a global object (i.e., one that can move around the network) when invoked by another object resident on the same node. By comparison, other object-based distributed systems are typically over 100 times slower for local invocations of their most general objects [6, 1].The Emerald language uses call-by-object-reference parameter passing semantics for all invocations, local or remote. While call-by-object-reference is the natural semantics for object-based systems, it presents a potential performance problem in a distributed environment. When a remotely invoked object attempts to access its arguments, those accesses will typically require remote invocations. Because Emerald objects are mobile, it may be possible to avoid some of these remote references by moving argument objects to the site of a remote invocation.From this table we can compute the benefit of call-by-move for a simple argument object. For this simple argument object, the additional cost of call-by-move was 2 milliseconds while call-by-visit cost 6.4 milliseconds. These are computed by subtracting the time for a remote invocation with an argument reference that is local to the destination. The call-by-visit time includes sending the invocation message and the argument object, performing the remote invocation (which then invokes its argument), and returning the argument object with the reply. Had the argument been a reference to a remote object (i.e., had the object not been moved), the incremental cost would have been 30.8 milliseconds. These measurements are somewhat of a lower bound because the cost of moving an object depends on the complexity of the object and the types of objects it names.Emerald currently executes on a small network of MicroVAX IIs and has recently been ported to the SUN 32. We have concentrated on implementing fine-grained mobility in Emerald while minimizing its impact on local performance. This has presented significant problems; however, through the use of language support and a tightly-coupled compiler and kernel, we believe that our design has been successful in meeting both its conceptual and performance goals.

Emerald is an object-based language for programming distributed subsystems and applications. Its novel features include 1) a single object model that is used both for programming in the small and in the large, 2) support for abstract types, and 3) an explicit notion of object location and mobility. This paper outlines the goals of Em-erald, relates Emerald to previous work, and describes its type system and distribution support. We are currently constructing a prototype implementation of Emerald.

Emerald is an object-based language for the construction of distributed applications. The principal features of Emerald include a uniform object model appropriate for programming both private local objects and shared remote objects, and a type system that permits multiple user-defined and compiler-defined implementations. Emerald objects are fully mobile and can move from node to node within the network, even during an invocation. This paper discusses the structure, programming, and implementation of Emerald objects, and Emerald's use of abstract types.

Article Free Access Share on Supporting distributed applications: experience with Eden Author: Andrew P. Black Department of Computer Science FR-35, University of Washington, Seattle, WA Department of Computer Science FR-35, University of Washington, Seattle, WAView Profile Authors Info & Claims SOSP '85: Proceedings of the tenth ACM symposium on Operating systems principlesDecember 1985 Pages 181–193https://doi.org/10.1145/323647.323646Published:01 December 1985Publication History 52citation429DownloadsMetricsTotal Citations52Total Downloads429Last 12 Months20Last 6 weeks2 Get Citation AlertsNew Citation Alert added!This alert has been successfully added and will be sent to:You will be notified whenever a record that you have chosen has been cited.To manage your alert preferences, click on the button below.Manage my AlertsNew Citation Alert!Please log in to your account Save to BinderSave to BinderCreate a New BinderNameCancelCreateExport CitationPublisher SiteeReaderPDF

The Eden project is a five year experiment in designing, building, and using an "integrated distributed" computing system. We are attempting to combine the benefits of integration and distribution by supporting an object based style of programming on top of a node machine/local network hardware base. Our experimental hypothesis is that such an architecture will provide an environment conducive to building distributed applications.

Input and output are often viewed as complementary operations, and it is certainly true that the direction of data flow during input is the reverse of that during output. However, in a conventional operating system, the direction of control flow is the same for both input and output: the program plays the active role, while the operating system transput primitives are always passive. Thus there are four primitive transput operations, not two: the corresponding pairs are passive input and active output, and active input and passive output. This paper explores the implications of this idea in the context of an object oriented operating system.