Program Committee

s of Contributed Talks Program Size: A Call for Inquiry Lucas Bang Harvey Mudd College, USA bang@cs.hmc.edu Size is a fundamental program characteristic that has deep implications for the phenomenological experience and in uence of computer code. Program size has a paradoxically rich yet sparse theoretical history that deserves closer examination. Here, I highlight the importance of program size, using a relatively obscure size theorem of Blum [1] as a beacon, and discuss the relevance of program size on the past, present, and future of programming. Theory in Praxis. Programmers are typically familiar with several foundational results in theoretical computer science and these results show up with varying frequency in the day-to-day experience of most people who regularly write code. A few examples will help illustrate. Ideas like undecidability, incomputability, and incompleteness [6, 17, 3] are required topics in many computer science programs, but it is not common to take them into practical consideration while performing routine software development tasks. Slightly more consideration-worthy on a regular basis is the notion of complexity classes, notably NP-completness [10]. It is indeed the case that the ability to recognize NPcomplete problems can have a real impact on programmers, users, and others a ected by solutions to scheduling, planning, routing, and optimization programs. Even more common are the considerations for algorithmic space and time complexity [5]; programming almost always accounts for memory and time e ciency. Finally, program correctness [12] is of utmost concern; by some accounts, programmers spend 35-50% of their time validating code [2]. If you have experience programming, I would encourage you to re ect on how relative frequency with which you have taken each of these facets of theoretical computer science into account while coding. I claim that the degree to which we consider theoretical areas of computing (e.g. each of the the aforementioned computability, complexity classes, algorithmic complexity, and correctness) in our daily lives is proportional to the potential for phenomenological discomfort caused by not taking them into consideration. I support this claim through the lens of Heidegger's ready-to-hand and present-at-hand framework [8]. Further, I claim that program size is indeed of the utmost importance to the daily activity of programming and to the e ect that programs have on society. Abstractions are born, to some degree, in order to manage program size complexity. When an abstraction does not behave as expected, the programmer shifts from a state of ready-at-hand to present-at-hand in the face of large programs. Yet, there does not currently exist a common familiarity with theoretical results related to program size providing a vocabulary that a ords re ection or communication about such concerns. Remember Not To Forget. Among theoreticians, Kolmogorov Complexity, is well-know. For a string s, the Kolmogorov Complexity of s is the size of the smallest program in a universal programming language that outputs s when provided no input [11]. Less well-known, but, I argue more relevant to day-to-day programmer experience is Blum's Size Theorem, which is not as simple to state upon rst glance [1]. Blum Size Theorem (1967). Let φi be an indexing of recursive functions, g be a recursive function with unbounded range, and f be any recursive function. We can nd indices i, j ∈ N such that φi = φg(i) and f(|i|) < |g(j)|, that is, the size of φg(i) is arbitrarily larger than the size of φi though they compute the same function. In Robert Harper's Practical Foundations for Programming Languages [7], and also in a blog post, Old Neglected Theorems are Still Theorems , he brie y but clearly spells out the consequences of Blum's Size Theorem: for a programming system in which you are guaranteed to be able to know for certain that any program behaves as desired (e.g. halts), there are speci able problems for which the smallest solution is an unfathomably large program. As a concrete example of this fact, Harper points to the Euclidean Algorithm for computing the greatest common divisor of two natural numbers (perhaps a few lines of Python). Writing GCD quickly becomes rather unwieldy in the restricted programming system System T where all programs are guaranteed to converge. I can personally attest to having done so and it is indeed rather painful and the program grew quite large. https://existentialtype.wordpress.com/2014/03/20/old-neglected-theorems-are-still-theorems/