Developers discuss software architecture and concrete source code implementations on a regular basis, be it on question-answering sites, online chats, mailing lists or face to face. In many cases, there is more than one way of solving a programming task. Which way is best may be decided based on case-specific circumstances and constraints, but also based on convention. Having strong conventions, and a common vocabulary to express them, simplifies communication and strengthens common understanding of software development problems and their solutions. While many programming ecosystems have a common vocabulary, Python's relationship to conventions and common language is a particularly pronounced. The "Zen of Python", a famous set of high-level coding conventions authored by Tim Peters, states "There should be one, and preferably only one, obvious way to do it". This 'one way to do it' is often referred to as the 'Pythonic' way: the ideal solution to a particular problem. Few other programming languages have coined a unique term to label the quality of craftsmanship gone into a software artifact. In this paper, we explore how Python developers understand the term 'Pythonic' by means of structured interviews, build a catalogue of 'pythonic idioms' gathered from literature, and conjecture on the effects of having a language-specific term for quality code, considering the potential it could hold for other programming languages and ecosystems. We find that while the term means different things to novice versus experienced Python developers, it encompasses not only concrete implementation, but a way of thinking — a culture — in general.
As modern computation platforms become increasingly complex, their programming interfaces are increasingly difficult to use. This complexity is especially inappropriate given the relatively simple core functionality that many of the computations implement. We present a new approach for obtaining software that executes on modern computing platforms with complex programming interfaces. Our approach starts with a simple seed program, written in the language of the developer's choice, that implements the desired core functionality. It then systematically generates inputs and observes the resulting outputs to learn the core functionality. It finally automatically regenerates new code that implements the learned core functionality on the target computing platform. This regenerated code contains boilerplate code for the complex programming interfaces that the target computing platform presents. By providing a productive new mechanism for capturing and encapsulating knowledge about how to use modern complex interfaces, this new approach promises to greatly reduce the developer effort required to obtain secure, robust software that executes on modern computing platforms.
We introduce a new principle, the open authorial principle, that characterises desirable properties of languages supporting networks of authors. We survey the growth in generosity of authorial systems, in a progression starting with traditional object-orientation, continuing through aspect-oriented, subject-oriented, context-oriented and dependency injection systems, and concluding with the most recent generation of highly dynamic systems such as Korz and Newspeak. We follow the implications of our principle for the externalisation of application designs, resulting from the need to promote the representation of differences between programs as valid programs themselves. This raises conceptual and practical parallels with technologies and idioms supporting the web, such as REST, realised document structures supported by the DOM, and the negotiated space of CSS selectors. These parallels lead to a quite different organisation for the language and runtime of an openly authorable system, which emphasises a publicly addressable cellular structure and a largely static dispatch.
We present an expressive, concise, and extendable domain specific language for planning of assembly systems, such as industrial human robot cooperation. Increased flexibility requirements in manufacturing processes call for more automation at the description and planning stages of manufacturing. Procedural models are good candidates to meet this demand as programs offer a high degree of flexibility and are easily composed. Furthermore, we aim to make our programs close to declarative specification and integrate automatic reasoning tools to help the users. The constraints come both from specific programs and preexisting knowledge base from the target domain. The case of human robot collaboration is interesting as there is a number of constraints and regulations around this domain. Unfortunately, automated reasoners are often too unpredictable and cannot be used directly by non-experts. In this paper, we present our domain specific language ``Tool Ontology and Optimization Language'' (Tool) and describe how we integrated automated reasoners and planners in a way that makes them accessible to users which have little programming knowledge, but expertise in manufacturing domain and no previous experience with or knowledge about the underlying reasoners. We present encouraging results by applying Tool to a case study from the automotive and aerospace industry.
Collections are commonly implemented as libraries by data structure experts, and are relied on heavily by application developers. The expert’s task is to implement a wide range of collections, and the application developer’s task is to pick an appropriate collection for each usage scenario. The design space for collections is huge, as data structures in practice implement not only their semantics, but also several performance-related concerns like memory layout and (im)mutability.
This paper presents C♭, pronounced “C-flat”, a novel way to implement collections that lets experts implement the semantics of a collection data structure, in a way that is decoupled from its data representation. This simplifies collection implementation, and allows a collection’s performance to be tuned, for example, moving from a dense to a sparse representation, without changing its abstract specification.
We describe C♭, both abstractly and in terms of a specific prototype implementation in Java. We use our prototype implementation to show that C♭ is expressive enough to implement common collections, that the code is straightforward, and that the performance of C♭ collections is close to Java’s standard collections for most operations, and much higher for some.
Live programming is an activity in which the programmer edits code while observing the result of the program. It has been exercised mainly for pedagogical and artistic purposes, where outputs of a program are not straightforwardly imagined. While most live programming environments so far target programs that explicitly generate visual or acoustic outputs, we believe that live programming is also useful for data structure programming, where the programmer often has a hard time to grasp a behavior of programs. However, it is not clear what features a live programming environment should provide for such kind of programs. In this paper, we present a design of live programming environment for data structure programming, identify the problems of synchronization and mental map preservation, and propose solutions based on a calling-context sensitive identification technique. We implemented a live programming environment called Kanon, and tested with 13 programmers.
Developers of modern distributed systems continuously face the impossibility result proved by the CAP theorem. In a nutshell, the theorem states that a partition-tolerant system can either guarantee consistency or availability. Most distributed programming languages implicitly make the choice between consistency or availability in their designs and implementations. Concretely, distributed programming languages can be roughly divided into two categories. A first category of languages provide abstractions to implement the consistent parts of a distributed system. A second category of languages provide abstractions to implement the available parts of a distributed system. However, real-world distributed systems often require consistency for some parts while requiring availability for others. Programmers are therefore forced to implement the abstractions missing from their chosen distributed programming language themselves or rely on external libraries. In this paper we present a novel distributed programming model. This model introduces two object-oriented abstractions: consistents and availables. The former guarantees strong consistency by sacrificing availability. The latter guarantees availability, but only provides eventual consistency. Through these constructs programmers are able to implement the entirety of their distributed system within the same language. We present a prototypical implementation of the model as a TypeScript library called CAPtain.js. To showcase the usefulness of our approach we implement a non-trivial example application. Moreover, we highlight both the functional as well as the performance characteristics of both language abstractions.
There is a paradigm shift in web-based services towards conversational user interfaces. Companies increasingly offer conversational interfaces, or chatbots, to let their customers or employees interact with their services in a more flexible and mobile manner. Unfortunately, this new paradigm faces a major problem, namely toxic content in user inputs. Toxic content in user inputs to chatbots may cause privacy concerns, may be adversarial or malicious, and can cause the chatbot provider substantial economic, reputational, or legal harm. We address this problem with an interdisciplinary approach, drawing upon programming languages, cloud computing, and other disciplines to build protections for chatbots. Our solution, called BotShield, is non-intrusive in that it does not require changes to existing chatbots or underlying conversational platforms. This paper introduces novel security mechanisms, articulates their security guarantees, and illustrates them via case studies.
Effect handling is a way to structure and scope side-effects which is gaining popularity as an alternative to monads in purely functional programming languages. Languages with support for effect handling allow the programmer to define idioms for state, exception handling, asynchrony, backtracking, etc. from within the language. Functional programming languages, however, prohibit certain patterns of modularity well-known from object-oriented languages. In this paper we introduce JEff, an object-oriented programming language with native support for effect handling, to provide first answers to the question what it would mean to integrate object-oriented programming with effect handling. We illustrate how user-defined effects could benefit from interface polymorphism, and present its runtime semantics and type system.
Abstraction is broadly considered a key asset in the making of software. However, the author finds that uncritical belief in abstraction puts software development at a substantial risk of failure. His essay combines some personal observations with more general concerns regarding the potential fatality of abstraction.
Our community believes that new domain-specific languages should be as general as possible to increase their impact. However, I argue that we should stop claiming generality for new domain-specific languages. Instead, we should document how domain-specific language based software development is beneficial to the overall software development process.
Approaches for programming language design used commonly in the research community today center around theoretical and performance-oriented evaluation. Recently, researchers have been considering more approaches to language design, including the use of quantitative and qualitative user studies that examine how different designs might affect programmers. In this paper, we argue for an interdisciplinary approach that incorporates many different methods in the creation and evaluation of programming languages. We argue that the addition of user-oriented design techniques can be helpful at many different stages in the programming language design process.