Final GRFP Essays

After I posted a draft of my personal statement for critiquing, a couple of people asked me if I would post the end results of my essays for the NSF Graduate Research Fellowship Program. I figured I would oblige, at least on the two important essays (the personal statement and the plan of research). My advisor was quite happy with both, though I'm fairly certain that the lack of references in the research plan will show how little I know about current research in the area and hurt my chances. In any case, here they are:

Personal Statement

As I begin the journey towards earning my PhD, I cannot help but be grateful that my undergraduate education took place at a small, liberal arts college. I may not have had all of the resources or opportunities to participate in original research that would have been available at a major university, but I was able to thoroughly integrate myself into a small, successful department in a way that would not have been possible in any other setting. For five years, I took every opportunity I could to leave my mark on Calvin College's Computer Science department. As president of the departmental student organization, I strove to foster community and engage my classmates in extra-curricular programming and service projects. As a lab assistant, I gained insight into the essential difficulties of programming while helping first-year students take their first steps into computational thinking. As a student grader for courses in Abstract Data Types, Programming Languages, Operating Systems, Software Engineering, and High Performance Computing, I developed an ever-deepening appreciation for the intricacies of our field.

Perhaps most importantly, I developed relationships with classmates and alumni who had entered the industry in every conceivable environment. From locally owned Agile software shops to corporate IT departments, from Google to MySpace to RIM to Microsoft, I was able to get a strong sense of what the world on the other side looked like. Reflecting on these conversations in the light of my own internship experiences, I quickly came to the realization that, while I could perform well there, industry is not the right fit for my personality. Whereas products are of limited appeal to me, novel problems can keep me captivated endlessly. Further, I could not escape the fact that many of the most fulfilling experiences of my undergraduate career came when working with students. The obvious route appeared to be a PhD and a career in academia. However, I had come to view programmers as “my people”, and I knew that I would not be satisfied if I felt that I was sequestered away in the mythical ivory tower. I concluded that I needed to do research with the potential to positively impact the lives of my friends in the workforce. To my understanding, there is no better path to this goal than working to improve the most fundamental tools at the disposal of every programmer: programming languages.

We live in a rapidly digitizing world, and while plenty of us have not yet bought into the smart-phone revolution, I cannot believe that the day is far off when every individual will benefit from being able to write simple applications for whatever personal computing device they carry with them. I doubt this will happen if people need to use Objective C or Java or even Python to do so. As much as these are improvements over assembly language and FORTRAN, most people simply aren't willing to endure the rigors that even modern high level languages demand. We need to further improve the expressiveness and of our programming languages if want programming to spread to the general populace. More worrisome is the simple truth that applications developed by such para-programmers are likely to be riddled with gaping security vulnerabilities and other errors. We need analysis tools that can identify these problems, explain them in comprehensible language, and even suggest fixes, and we need development tools that integrate utilities of this sort so that developers have all of this information at their fingertips.

While such improvements would certainly help professional programmers, they have their own set of needs that we must meet. As technology advances, software engineers must increasingly look to multi-processor computing to provide users with the performance and convenience improvements that they expect and deserve. If the task of programming in modern languages is too complicated for the general public, then the task of writing concurrent applications is even worse. The most prevalent constructs for concurrency remain threads and processes, machine-level notions that do not naturally lend themselves to the way we design algorithms or programs. We need to find new ways of representing concurrency that will ease the task of utilizing the power at our disposal. These tasks – the improvement of language design and analysis tools – fall squarely on the shoulders of Programming Languages researchers, and by taking them on, we assist in the efforts of all other practitioners of our discipline, be they hobby hackers, software engineers, or our fellow academics.

When the time came to decide where I wanted to pursue these goals, it was easy to choose the University of Colorado at Boulder (CU). For one thing, the Programming Languages group at CU gave me an opportunity to get in near the ground level with a young, energetic, and talented group of professors who are eager to advance the school's reputation in the field. This would not have been enough on its own, but when the time came for me to visit campus, Professor Evan Chang and others echoed my strongly held sentiments that programming languages research ought to be an interdisciplinary affair with a strong eye towards the tenets of Human Computer Interaction. After all, a tool that is difficult to use, no matter how great its functionality, is an inferior tool. Fortunately, CU also provides me the opportunity to work with respected researchers in HCI and cognitive science, including Professor Clayton Lewis, who found one of his first passions within academia in programming language comprehensibility. Considering these prospects, CU provides a near ideal environment in which to build the connections and lay down the foundational work to achieve my goals.

Ultimately, though, I do not believe that we enter academia simply to achieve our own research goals. I do not believe that we seek to make new discoveries simply in order to gain renown or satisfy our own curiosity. I believe whole-heartedly that we work to push the state of the art so that the next generation can push it even further. I believe that our work remains incomplete unless we prepare the next generation to pick up where we left off and provide them with the necessary resources to forge ahead. This, along with my professed love of working with students, is why I intend to return to the liberal arts when the time comes. Through its Graduate Teacher Program and participation in the GK-12 initiative, CU will provide me with ample opportunity to improve my pedagogy. By participating in these programs, I hope to learn how to design curricula that will mitigate my students' struggles while helping them gain an appreciation for both the art of programming and the principles that govern it. I also hope to bring with me a number of opportunities that are all too often lacking for liberal arts students working in the sciences. In particular, I hope to develop opportunities for research both within my own institution and especially in collaboration with my peers at other universities. I believe that building bridges between the liberal arts and and the world of research can only be of benefit to both.

There's a lot of work to be done before I get to that point, and that all starts with having the freedom to work on these problems. While my professors are excited by my ideas and eager to see me forward, we do not currently have funding for the particular work I hope to do, and this is ambitious work. As a student, I have time to do the necessary legwork and build the relationships that will get this work started. More importantly, I have the time to fail on the way towards progress without it impacting my career. I firmly believe that, with the guidance available to me here, I can make real progress and create opportunities for others to join in my work. I just need the opportunity, an opportunity the GRFP can provide.



_______________

Developing New Abstractions for Concurrency
Jonathan Walz

As we all know, in order to keep pace with Moore's Law and to continue providing consumers with the regular performance improvements to which they have grown accustomed, microprocessors have shifted to a multi-core model. While it was only a few short years ago that desktop computers were first adopting dual-core processors, we have now reached a point where six-core chips are being used in servers. Even low-power, ultra-portable devices like netbooks and tablets are seeing the upgrade to dual-core. It will not be long before even our simplest consumer devices have more than one independent processing unit on board. In order to take advantage of this multi-core architecture, developers need to write programs that propagate their computation across multiple processes and threads of execution.

Unfortunately, concurrent programming is fraught with difficulties, especially the sort of shared memory, thread based parallelism that multi-core systems utilize. Deadlock, race conditions, and other problems plague any programmer trying to properly utilize the power at their disposal, and while numerous libraries and frameworks exist to simplify the problem, they require programmers to fundamentally alter the way in which they develop applications. It seems reasonable to me, however, that these issues with thread-based parallelism all stem from a more fundamental problem with threading: it does not match up with our natural understanding of concurrent behavior. It is startling to me that, for all of our advances in high level languages designed to allow us to express programs more naturally and coherently, we still expect programmers to implement concurrency through constructs as fundamentally machine-level as threads and processes. If we want to evolve computing to the point where programmers can quickly and intuitively write concurrent applications that are both efficient and safe, we need to provide new abstractions for concurrency that operate in a manner that is intuitive to human understanding.

This edict requires us to first understand how it is that humans understand concurrency, a troublesome proposition. Think, for a moment, about the simple nature of human existence. Millions of distinct cells, each filled with dozens of organelles, independently send messages back and forth, coordinating their growth and operation in order to make up the tissues and organs that compose our bodies. These organs function in concert to keep us moving and breathing and thinking with nary a lock or semaphore in sight. We manipulate our bodies in response to multiple simultaneous stimuli so naturally that it is only when we start to consider how we are doing so that we falter. Concurrency is simply a fundamental feature of the natural world.

How, then, do we go about trying to understand how people think about concurrency in environments where it needs to be imposed rather than simply being? Fortunately, University of Colorado at Boulder professors Clayton Lewis and Michael Eisenberg have already taken an interest in this question. As a part of an Educational Game Design course taught by Dr. Lewis, several students have ventured to design games meant to help individuals think about concurrency. While results from these early iterations have been limited, there is hope that continuing efforts on this front will start to shed light on the topic.

Doctors Lewis and Eisenberg may be the only researchers at CU who are actively thinking about how we understand concurrency, but they are certainly not the only resource at my disposal. From traditional vanguards of numerical analysis and high performance computing to the emerging needs of software engineering researchers to Dr. Nikolaus Correl's work with robot swarms, concurrency is everywhere at CU. This will provide me a high level overview of how concurrency is viewed throughout the entire spectrum of the discipline and help me to see if there is any sort of unified model that can be applied.

Having access to this new level of expertise on the topic of concurrency has already allowed me to begin a much improved review of the literature on the subject compared to my earlier efforts. While I am only in the beginning phases of learning what has already been done, I am still feeling emboldened and hope to revisit my past research and expand on my efforts. I still believe that a message passing model for concurrency has great potential, but it has been stymied by the fact that we have needed to make the messaging explicit. When we work in Object Oriented programming, we already cause objects to send messages between one another. By utilizing shared memory access in new and well controlled ways, I firmly believe that we can remove or reduce the need for synchronization in these exchanges and gain concurrency and speedup as a result. Most important, such strategies could have a very limited impact on existing programming practices.

I will begin delving back into this topic with the same approach I took in my earlier research efforts: by using metaprogramming techniques to create this functionality in an existing language. Due to its numerous hook methods, reflectivity, and duck typing, Ruby remains an ideal candidate for this work. If I am successful in this endeavor, I hope to establish partnerships with researchers in other areas that use concurrency – especially Software Engineering – to test the usability and performance potential of such a system in real-world uses. If I see success in this area, I would like to continue on and begin work developing a language that natively supports this functionality or even try to add it directly to common runtime environments.

While I am engaged in this work, I also plan to participate in the GK-12 initiative where I can work with students who have had limited or no previous exposure to computing. This could be an ideal environment for gaining a better understanding of how people learn to think about concurrency as well as the best ways to teach it. Of those students who choose to pursue Computer Science as a profession, few will likely ever have to program a system with only a single processing unit. It is only fair that they be prepared for the tasks ahead of them.

The problem of how we understand and represent concurrency in computation is an increasingly important one. The more angles from which we can attack it, the better. I do not yet claim to be an expert on all of the research being done in the area, but the approach I suggest is not one that I or others with whom I have talked have heard of. It may not turn out to be the cure to our problems, but it is another point from which to start and from which to gather new information to help move us along in this new era of computing.