Keshav Pingali Department of Computer Science University of Texas, Austin

1. The Hunt for Right Abstractions Keshav Pingali Department of Computer Science University of Texas, Austin

2. Dewar’s profile • Bachelor of Technology (1978) • I.I.T.Kanpur • S.M. / E.E./Sc.D. (1983,1986) • M.I.T., Cambridge, MA • Faculty member at Cornell University (1986-2006) • Department of Computer Science • Department of Electrical and Computer Engineering • Faculty member at UT, Austin (2006-) • Department of Computer Science • Director, Center for Grid and Distributed Computing, Institute for Computational Engineering and Sciences (ICES) • Favorite hobby • writing newspaper columns on current political events • Favorite beer • Corona • Favorite quote • “Everything should be as simple as possible, but not any simpler.” Einstein

3. High-level theme of talk • My definitions: • PL design: • finding abstractions to express algorithms • PL implementation research: • finding out if these are good abstractions • Questions: • What are abstractions? • Why are abstractions useful? • What does abstraction have to do with programming languages? • What are good abstractions in the context of programming languages?

4. The Power of Abstraction • Bridges of Konigsberg • town in Prussia • now named Kaliningrad in Russia • Problem: • Is there a walk that crosses each bridge exactly once? • Citizens of Konigsberg in the 17th and 18th centuries tried to solve this problem

5. Solution by Euler • Key insight: connectivity between land masses is what is important, not the actual distances or the orientations of the bridges • Create an abstraction: graph • One node for each land mass • Edge between two nodes if there is a bridge connecting the two land masses • Graph has nodes of odd degree, so there is no walk with desired property • Led to field we now call topology

6. Abstraction • Definition: • the act or process of leaving out of consideration one or more properties of a complex object so as to focus on others • (e.g.) Euler left out distances and orientations • a general concept formed by extracting common features from specific examples • (e.g.) general concept of “graph” allows you to solve similar problems Bridges of Madison County (Iowa)

7. Bad abstractions • Abstraction is bad if it has thrown away some essential feature of the problem • topologist is someone who does not know the difference between a doughnut and coffee-cup • What is essential depends on the use you intend to make of the abstraction “Naked Blue IV” Henri Matisse (1952)

8. Abstractions in PL • My opinion: most important advances in PL have introduced new abstractions • Examples: • Procedures (1950?) • abstraction: parameterized code module (l-abstraction) • abstracted away: implementation code • Processor architecture (IBM 360) • abstraction: machine language • abstracted away: implementation of machine language • FORTRAN I (1957) • abstraction: high-level programming language • abstracted away: machine language

9. Abstractions in PL (contd.) • Examples (contd.): • Structured programming (1967) • abstraction: structured control-flow constructs like if-then-else, while-loops, for-loops etc. • abstracted away: conditional jumps (machine language relic) • Object-oriented programming (1970-) • abstraction: abstract data type • abstracted away: representation of data type • Automatic storage management (1960-) • abstraction: objects • abstracted away: machine addresses (pointers)

10. Bad abstractions in PL? • Abstractions that are • difficult to reason about • hard to implement efficiently • Example: functional languages for parallel programming • Abstract away the notion of storage: only values and functions on values • Elegant parallel execution models: reduction, dataflow • Big problem: data structure manipulation can be very inefficient if you view data structures as values • Unfortunately, parallelism in algorithms is mostly data parallelism  • Notion of storage might be an essential feature of program execution that should not be abstracted away by the programming language • Caveat: functional languages are perfectly good abstractions for other uses • Semantics of programming languages

11. Recap • My views: • PL design: • finding abstractions to express algorithms • PL implementation research: • finding out if these are good abstractions • OK, so how do you get started in PL implementation research?

12. Getting started • Take relevant courses • Modern compiler design • there is lots more to compilers than the Dragon book • you will learn powerful algorithms and mechanisms for implementing abstractions • Algorithms • Machine learning • used increasingly in PL implementation • Statistics and inference • learn good experimental protocols • we do not do enough of this in Computer Science

13. Read papers from major PL conferences • PLDI: Programming Language Design and Implementation • POPL: Principles of Programming Languages • OOPSLA: Object-oriented Programming Systems, Languages and Architectures • ASPLOS: Architectural Support for Programming Languages and Operating Systems • PPoPP: Principles and Practice of Parallel Programming

14. Try to replicate results from papers that interest you • standard apprenticeship technique in other sciences • we do not do enough of this in Computer Science • don’t hesitate to contact authors if something is not clear or you cannot replicate their results (but be polite) • Build on other people’s software • starting from scratch is too time-consuming • not even feasible for most research projects nowadays • always be on the look-out for tools and systems you can steal (Open64 compiler from Intel, Java compilers and JVMs like Jikes,…)

15. Do NOT try to tweak other people’s heuristics in minor ways • Most problems in PL implementation are NP-complete or undecidable at some level of generality • Heuristics are the name of the game • Not difficult to add bells and whistles to other people’s heuristics • You go breadth-first, I go depth-first • Bulk of papers in conferences are of this nature • Life is too short to play second fiddle • The scenery never changes if you are not the lead husky. • Hunt for abstractions • write lots of code and think about what might simplify your job • talk to lots of people who write lots of code and think about what might simplify their job • Implementing abstractions is critical • only way to determine if an abstraction is right • use your prototype and give it to your friends to use • Encourage and learn from feedback • Few abstractions are perfect the first time around

16. The Hunt For Right Abstractions