The Hunt
for
Right Abstractions
Keshav Pingali
Department of Computer Science
University of Texas, Austin
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
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?
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
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
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)
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
“Naked Blue IV” Henri Matisse (1952)
• What is essential
depends on the use you
intend to make of the
abstraction
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
Abstractions in PL (contd.)
• Examples (contd.):
– Structured programming (1967)
• abstraction: structured control-flow constructs like if-thenelse, 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)
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
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?
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
• 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
• 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,…)
• 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
The Hunt
For
Right Abstractions