Regularized Programming with the BOSQUE Language Moving Beyond Structured Programming Mark Marron [email protected] Abstract and compilers/tooling. The first contribution of this paper is The rise of Structured Programming and Abstract Data Types an identification and categorization of unnecessary complex- in the 1970’s represented a major shift in programming lan- ity sources which can be alleviated via thoughtful language guages. These methodologies represented a move away from design (Section 2). a programming model that reflected incidental features of Using the sources of complexity identified in Section 2 the underlying hardware architecture and toward a model as a guide, the second contribution of this paper is the in- that emphasized programmer intent more directly. This shift troduction of the BOSQUE LANGUAGE1 (Section 3). The simultaneously made it easier and less error prone for a de- BOSQUE language demonstrates the feasibility of eliminating veloper to convert their mental model of a system into code these sources of complexity while retaining the expressivity and led to a golden age of compiler and IDE tooling devel- and performance needed for a practical language as well as opment. This paper takes another step on this path by further hinting at opportunities for improved developer productivity lifting the model for iterative processing away from low-level and software quality. loop actions, enriching the language with algebraic data trans- Section 4 goes into detail on how the concepts used in the formation operators, and further simplifying the problem of design of the BOSQUE language represent a larger step in the reasoning about program behavior by removing incidental development of programming languages and models. Thus, ties to a particular computational substrate and indeterminate the third contribution of this paper is the introduction of the behaviors. We believe that, just as structured programming regularized programming model. This model builds on the did years ago, this regularized programming model will lead successes of structured programming and abstract data types to massively improved developer productivity, increased soft- by simplifying existing programming models into a regular- ware quality, and enable a second golden age of developments ized form that eliminates major sources of errors, simplifies in compilers and developer tooling. code understanding and modification, and converts many au- tomated reasoning tasks over code into trivial propositions. 1 Introduction To explore the opportunities that regularized programming enables this paper concludes with three case studies, using The introduction and widespread use of structured program- the ability to precisely analyze the semantics of a program to ming [14] and abstract data types [42] marked a major shift verify correctness, validating SemVer [67] usage, and how the in how programs are developed. Fundamentally, the concepts regularized semantics enable SIMD [34] optimization in sce- and designs introduced by these programming methodologies narios that would be otherwise difficult or impossible. These simplified the reasoning about program behavior by elimi- results demonstrate how the unique properties of regularized nating substantial sources of, usually entirely accidental [8], programming enable the implementation of previously im- complexity. This allowed engineers to focus on the intent practical developer experiences beyond the direct benefits to and core behavior of their code more directly and, as a re- software quality and developer productivity that are possible sult, produced a drastic improvements in software quality and when moving beyond structured programming! ability to construct large software artifacts. Just as accidental complexity is an impediment to human understanding of a 2 Complexity Sources program it is also an impediment to applying formal reasoning techniques. Despite the inability of structured programming Based on a range of experiences and sources including devel- to fully bridge the chasm of formal mathematical analysis, is- oper interviews, personal experience with analysis/runtime/- sues with loop-invariants and mutation-frames among others compiler development, and empirical studies this section iden- prevented the practical use of verification techniques, it did tifies five major sources of accidental complexity that canbe provide the needed simplifications to enable reasoning about addressed via thoughtful language design. These are sources limited forms of program behavior and supported a golden of various of bug families, increase the effort required for a age of IDE tooling and compiler development [34, 54]. developer to reason about and implement functionality in an Drawing inspiration from these successes, this paper seeks to identify additional opportunities to eliminate complexity 1The BOSQUE specification, parser, type checker, reference interpreter, with the intent that these simplifications will lead to simi- and IDE support are open-sourced and available at https://github.com/ lar advances in software quality, programmer productivity, Microsoft/BosqueLanguage. application, and greatly complicate (or make it infeasible to) the number of details that must be tracked and restored can automatically reason about a program. increase drastically increasing opportunities for mistakes and oversights to occur. Section 4.1 shows how the BOSQUE lan- Mutable State and Frames: Mutable state is a deeply com- guage eliminates this problem through the introduction of plicated concept to model and reason about. The introduction algebraic bulk data operators. of mutability into a programming language destroys the abil- ity to reason about the application in a monotone [56] manner Equality and Aliasing: Programming languages live at the which forces the programmer (and any analysis tools) to iden- boundary of mathematics and engineering. Although lan- tify which facts remain true after an operation and which are guage semantics are formulated as a mathematical concept invalidated. The ability for mutable code to affect the state there are common cases, e.g. reference equality, pass by-value of the application via both return values and side affects on vs. by-reference, or evaluation orders, that expose and favor arguments (or other global state) also introduces the need to one particular hardware substrate, generally a Von Neumann reason about the logical frame [47, 64] of every operation. architecture, either intentionally for performance or acciden- Section 4.1 examines how the BOSQUE language eliminates tally by habit or history. While seemingly minor these choices this source of complexity through the use of immutable data have a major impact on comprehensibility – merely expos- representation. ing reference equality pulls in the complexity of reasoning Loops, Recursion, and Invariants: Loops and recursion about aliasing relations and greatly complicates compilation represent a fundamental challenge to reasoning as the code on other architectures. Section 4.3 shows how the BOSQUE describes the effects of a single step but understanding the language eliminates reference equality and, as a consequence, full construct requires generalization to a quantified property eliminates the complexity of aliasing questions and by-value over a set of values. Invariants [19, 27] provide the needed vs. by-ref argument passing issues. connection but a generalized technique for their computation is, of course, impossible in general and has proved elusive 3 BOSQUE Language Overview even for restricted applications. Section 4.5 examines how The BOSQUE language derives from a combination of Type- BOSQUE handles the invariant problem by eliminating loops Script [72] inspired syntax and types plus ML [52] and Node/ and restricting recursion. JavaScript [31, 58] inspired semantics. This section provides the syntax and operators of the BOSQUE language with an Indeterminate Behaviors: Indeterminate behaviors, includ- emphasis on features of the language that are not widely seen ing undefined, under specified, or non-deterministic or envi- ronmental behavior, require a programmer or analysis tool to in other programming languages. Section 4 focuses on how reason about and account for all possible outcomes. While these features and design choices address various sources of truly undefined behavior, e.g. uninitialized variables, has dis- complexity enumerated in Section 2. appeared from most languages there is a large class of under- 3.1 BOSQUE Type System specified behavior, e.g. sort stability, map/dictionary enumer- ation order, etc., that remains. These increase the complexity The BOSQUE language supports a simple and non-opinionated of the development process and, as time goes on, are slowly type system that allows developers to use a range of struc- being seen as liabilities that should be removed [9]. Less tural, nominal, and combination types to best convey their obviously the inclusion of non-deterministic and/or environ- intent and flexibly encode the relevant features of the problem mental interaction results in code that cannot be reliably tested domain. (flakey tests), behaves differently for non-obvious reasons, Nominal Type System: The nominal type system is a mostly and frequently mixes failure logic widely through a codebase. standard object-oriented design with parametric polymor- Section 4.2 explains how BOSQUE eliminates these sources phism provided by generics. Users can define abstract types, of complexity