11:00 - 11:30

• Assert Use in GitHub Projects

  Asserts have long been a strongly recommended (if non-functional) adjunct to programs. They certainly don't add any user-evident feature value; and it can take quite some skill and effort to devise and add useful asserts. However, they are believed to add considerable value to the developer. Certainly, they can help with automated verification; but even in the absence of that, claimed advantages include improved understandability, maintainability, easier fault localization and diagnosis, all eventually leading to better software quality. We focus on this latter claim, and use a large dataset of asserts in C and C++ programs to explore the connection between asserts and defect occurrence. Our data suggests a connection: functions with asserts do have significantly fewer defects. This indicates that asserts do play an important role in software quality; we therefore explored further the factors that play a role in assertion placement: specifically, process factors (such as developer experience and ownership) and product factors, particularly interprocedural factors, exploring how the placement of assertions in functions are influenced by local and global network properties of the callgraph. Finally, we also conduct a differential analysis of assertion use across different application domains.

   

  Preprint available:

Casey Casalnuovo; Premkumar Devanbu; Abilio Oliveira; Vladimir Filkov; Baishakhi Ray

UC Davis, USA

11:30 - 12:00

• A Programming Model for Sustainable Software

  This paper presents a novel energy-aware and temperature-aware programming model with first-class support for sustainability. A program written in the new language, named Eco, may adaptively adjusts its own behaviors to stay on a given (energy or temperature) budget, avoiding both deficit that would lead to battery drain or CPU overheating, and surplus that could have been used to improve the quality of results. Sustainability management in Eco is captured as a form of supply and demand matching, and the language runtime consistently maintains the equilibrium between supply and demand. Among the efforts of energy-adaptive and temperature-adaptive systems, Eco is distinctive in its role in bridging the programmer and the underlying system, and in particular, bringing both programmer knowledge and application-specific traits into energy optimization. Through a number of intuitive programming abstractions, Eco reduces challenging issues in this domain such & as workload characterization and decision making in adaptation & to simple programming tasks, ultimately offering fine-grained, programmable, and declarative sustainability to energy-efficient computing. Eco is an minimal extension to Java, and has been implemented as an open-source compiler. We validate the usefulness of Eco by upgrading real-world Java applications with energy awareness and temperature awareness.

Haitao Steve Zhu; Chaoren Lin; Yu David Liu

Google Inc., USA; SUNY Binghamton, USA

12:00 - 12:30

• A Comparative Study of Programming Languages in Rosetta Code

  Sometimes debates on programming languages are more religious than scientific. Questions about which language is more succinct or efficient, or makes developers more productive are discussed with fervor, and their answers are too often based on anecdotes and unsubstantiated beliefs. In this study, we use the largely untapped research potential of Rosetta Code, a code repository of solutions to common programming tasks in various languages, which offers a large data set for analysis. Our study is based on 7'087 solution programs corresponding to 745 tasks in 8 widely used languages representing the major programming paradigms (procedural: C and Go, object-oriented: C# and Java, functional: F# and Haskell, scripting: Python and Ruby). Our statistical analysis reveals, most notably, that: functional and scripting languages are more concise than procedural and object-oriented languages, C is hard to beat when it comes to raw speed on large inputs, but performance differences over inputs of moderate size are less pronounced and allow even interpreted languages to be competitive, compiled strongly-typed languages, where more defects can be caught at compile time, are less prone to runtime failures than interpreted or weakly-typed languages. We discuss implications of these results for developers, language designers, and educators.

   

  Preprint available:

Sebastian Nanz; Carlo A. Furia

ETH Zurich, Switzerland