This may ruffle a few feathers, but I really don't care:
I'm really sick of popular media figures convincing everybody that Science is something other than what it is. Sick of the notion that Science is an infallible authority that answers all of our questions and makes our lives better.
Don't get me wrong. I adore Science. I think that investigating the fundamental behavior of the universe is a supremely important pursuit and that the knowledge we gain is of great use in improving our understanding and our station. I fully endorse theories of evolution and of the big bang and goodness knows whatever else plenty of foolish Christians have insisted on denying in the name of literalism.
I just recognize that Science is not final. Whatever we think we know about the universe is simply a current best guess. It's a set of plausible (likely, even) explanations based on observation of correlation and testing for causation. And none of it can ever be shown to be perfectly true. It's a system that rests on the principle of falsification -- advancements can be made almost exclusively by disproving previous best-guesses.
More than that, almost all of Science is simplification. The vast majority of natural interactions are chaotic -- meaning they cannot be represented in any sort of linear or closed form equation. We cannot observe or interact with the infinite, so we build models that are "good enough". We make substitutions and estimations. We build computer models that, between the necessity of discretization and the fallibility of floating point arithmetic, can only barely be trusted.
Science is not an answer to a question. It's a process by which we go about attempting to improve the answers we have. Science is not God. It is an attempt to reveal the work that God has done in creation in a way we can comprehend.
Friday, February 18, 2011
Thursday, February 10, 2011
Academia
As much as I love music, there's a reason I never could have made a career out of it. Music, in both performance and consumption, is something I do for myself. It is therapeutic to me. I love doing it, but, except for rarely, it's not something I can do in order to meet the needs of others. Oftentimes my ability to perform and other people's desire to listen have overlapped positively, but if I felt like I was somehow beholden to others in my performance, I would grow resentful and lose what love I have for it.
Essentially the same thing holds true for computer science.
I adore designing systems to solve problems. I love analyzing these systems to try to improve them and make them do their job better and generalizing them to a wider variety of tasks...but it's not something I can readily make myself do, and it's certainly not something I can make myself do because somebody else is expecting something from me.
For some reason, when I signed up for grad school, I was under the delusion that academia was a place where I could go to find novel problems of interest to me and seek guidance from a field of experts as to where to start looking to solve them. I thought it would be self-directed. I thought it would be freeing.
Nope.
I get here, and I'm subjected to the frantic energy of brilliant but frazzled men who live and die not by the intrinsic value of their work, but by the whims and opinions of their colleagues. These are men who want me to pursue my own interests, but at their pace and in the manner that they see fit because they know that their careers hinge, in part, on my potential for brilliance.
I don't work that way, at least not in this discipline. I come under sudden pressure to satisfy the needs of others in this regard and I crumble. I fall into depression, and I fall even farther behind. I can't be effective if I'm spending as much time figuring out how to convince my advisors that I'm doing good work as I am actually working.
I'll give it the rest of the semester and probably the year after that -- long enough to get my Masters -- but I'm not sure this is going to happen without taking an unnecessary toll on me. At least not here. Mostly, I think I may need to find a career doing something I'm capable of and enjoy doing for others.
So, who wants to help me start a cafe/brew-pub? I'll manage the food part of the menu and take the day shift. In the evenings, I can hang out with and lead a double life as an eccentric inventor/writer/musician. It will be fun. I promise.
Essentially the same thing holds true for computer science.
I adore designing systems to solve problems. I love analyzing these systems to try to improve them and make them do their job better and generalizing them to a wider variety of tasks...but it's not something I can readily make myself do, and it's certainly not something I can make myself do because somebody else is expecting something from me.
For some reason, when I signed up for grad school, I was under the delusion that academia was a place where I could go to find novel problems of interest to me and seek guidance from a field of experts as to where to start looking to solve them. I thought it would be self-directed. I thought it would be freeing.
Nope.
I get here, and I'm subjected to the frantic energy of brilliant but frazzled men who live and die not by the intrinsic value of their work, but by the whims and opinions of their colleagues. These are men who want me to pursue my own interests, but at their pace and in the manner that they see fit because they know that their careers hinge, in part, on my potential for brilliance.
I don't work that way, at least not in this discipline. I come under sudden pressure to satisfy the needs of others in this regard and I crumble. I fall into depression, and I fall even farther behind. I can't be effective if I'm spending as much time figuring out how to convince my advisors that I'm doing good work as I am actually working.
I'll give it the rest of the semester and probably the year after that -- long enough to get my Masters -- but I'm not sure this is going to happen without taking an unnecessary toll on me. At least not here. Mostly, I think I may need to find a career doing something I'm capable of and enjoy doing for others.
So, who wants to help me start a cafe/brew-pub? I'll manage the food part of the menu and take the day shift. In the evenings, I can hang out with and lead a double life as an eccentric inventor/writer/musician. It will be fun. I promise.
Monday, February 7, 2011
Goals for my 25th Year
Analyze things less.
Enjoy things more.
Stop focusing on expectations.
Man up and ask for help when I need it.
Quit being a pansy in my personal life.
Learn to rock out on bass.
Use bass rocking as an opportunity to improve knowledge of chord structure and progression so as to rock out on saxophone harder than ever (or at least as hard as when I was 18).
Go to more concerts.
Participate in dance parties instead of hiding from them.
Learn to at least tolerate beer (in moderation).
Learn to at least tolerate coffee (in excess as needed).
Prepare vegetarian meals at least thrice a week.
Get exercise beyond copious walking.
Lose another 25+ lbs (already down nearly 40 since graduation).
Develop a stronger rapport with the rest of my lab.
Find a way to twist my research into something I'm passionate about.
Submit at least one paper or article for publication.
Enjoy things more.
Stop focusing on expectations.
Man up and ask for help when I need it.
Quit being a pansy in my personal life.
Learn to rock out on bass.
Use bass rocking as an opportunity to improve knowledge of chord structure and progression so as to rock out on saxophone harder than ever (or at least as hard as when I was 18).
Go to more concerts.
Participate in dance parties instead of hiding from them.
Learn to at least tolerate beer (in moderation).
Learn to at least tolerate coffee (in excess as needed).
Prepare vegetarian meals at least thrice a week.
Get exercise beyond copious walking.
Lose another 25+ lbs (already down nearly 40 since graduation).
Develop a stronger rapport with the rest of my lab.
Find a way to twist my research into something I'm passionate about.
Submit at least one paper or article for publication.
Tuesday, December 7, 2010
Yet Another Endorsement for Community
Over the Thanksgiving weekend, Amazon had the first season of Community on sale for $12. Being a fan of the show, I immediately bought a copy, and as I revisit these episodes, I can't help feeling like I made a mistake in not buying half a dozen copies or more and giving them out as Christmas gifts. Not nearly enough people are watching this show, which could well be the best comedy on tv right now, and I have to say that, if you enjoy television at all, you really should be.
This is a show that is obviously loved by everybody involved in its creation (a trait it has in common with far too many shows that have been canceled before their time, including FX's recent Terriers). There is a joy surrounding it that is simply infectious, and that joy is enhanced by the fact that this is a show with a heart. The single camera sitcom is a genre that has long been shrouded in cynicism. Shows like Arrested Development, It's Always Sunny in Philadelphia, and even, to an extent, 30 Rock, are essentially about flawed people hurting each other. When done well, this is still a funny format, but it wears on you after awhile. While I still adore it, I'm not sure how much longer Arrested Development could have lasted in the format.
Community takes a different direction. It's a show about flawed people overcoming and/or embracing their flaws to help one another. It's a show about how we find family in this crazy, mixed up world where traditional family is no longer a guarantee.
While that's the important part, it wouldn't be worthwhile if the execution wasn't spot-on, and the unique way that Community executes really helps elevate it. This is a show made by people with an abiding love of pop culture, and it is by no means afraid to make heavy use of tropes or references. The way Dan Harmon and the other writers use the tropes, though, is not as a crutch or even a scaffolding. Except in rare, highly intentional moments, they are used in a way that is incredibly organic and that contribute to the development of the characters. They use them in a way that shows the basis of these cliches in the reality of human interaction.
It's a wonderful and unimaginably difficult thing to do, and it wouldn't work if the writers didn't take the reality of the characters incredibly seriously. For all of the ridiculous things they might do or get caught up in, there are genuine people with genuine motivations in even the most ridiculous characters present, and that shines through most clearly in Abed.
Abed is a character who all but officially has Asperger's syndrome. He relates to people most easily through media cliches, which allows him an interesting role as a commentator on the action, providing a certain amount of meta-referential humor without actively breaking the fourth wall. If this was Abed's only role, he would still be a great character because of the singular way that Danny Pudi plays him, but he's far more than that. In episodes like Introduction to Film, Physical Education, Contemporary American Poultry, and especially last week's Mixology Certification, we can see just how troubled Abed is. Media cliches aren't a way for him to understand people. He can do that just fine. They're a way to help people understand him, something he can't do on his own. He struggles with his oddity and with being left outand he's willing to use people, to an extent, to feel like he belongs. He even recognizes that his own friends occasionally see him as something lesser, but he doesn't know how to express his frustration.
That's a lot of depth, and yet all of this is handled delicately. It's a testament to the collaborative effort on display, the willingness by everybody involved to let each other bring their gifts to the table and let the best possible result unfold. It manages to be touching without being saccharine, to be funny without being alienating, and to be fundamentally true despite being admittedly contrived.
Please watch Community. You'll be glad you did.
This is a show that is obviously loved by everybody involved in its creation (a trait it has in common with far too many shows that have been canceled before their time, including FX's recent Terriers). There is a joy surrounding it that is simply infectious, and that joy is enhanced by the fact that this is a show with a heart. The single camera sitcom is a genre that has long been shrouded in cynicism. Shows like Arrested Development, It's Always Sunny in Philadelphia, and even, to an extent, 30 Rock, are essentially about flawed people hurting each other. When done well, this is still a funny format, but it wears on you after awhile. While I still adore it, I'm not sure how much longer Arrested Development could have lasted in the format.
Community takes a different direction. It's a show about flawed people overcoming and/or embracing their flaws to help one another. It's a show about how we find family in this crazy, mixed up world where traditional family is no longer a guarantee.
While that's the important part, it wouldn't be worthwhile if the execution wasn't spot-on, and the unique way that Community executes really helps elevate it. This is a show made by people with an abiding love of pop culture, and it is by no means afraid to make heavy use of tropes or references. The way Dan Harmon and the other writers use the tropes, though, is not as a crutch or even a scaffolding. Except in rare, highly intentional moments, they are used in a way that is incredibly organic and that contribute to the development of the characters. They use them in a way that shows the basis of these cliches in the reality of human interaction.
It's a wonderful and unimaginably difficult thing to do, and it wouldn't work if the writers didn't take the reality of the characters incredibly seriously. For all of the ridiculous things they might do or get caught up in, there are genuine people with genuine motivations in even the most ridiculous characters present, and that shines through most clearly in Abed.
Abed is a character who all but officially has Asperger's syndrome. He relates to people most easily through media cliches, which allows him an interesting role as a commentator on the action, providing a certain amount of meta-referential humor without actively breaking the fourth wall. If this was Abed's only role, he would still be a great character because of the singular way that Danny Pudi plays him, but he's far more than that. In episodes like Introduction to Film, Physical Education, Contemporary American Poultry, and especially last week's Mixology Certification, we can see just how troubled Abed is. Media cliches aren't a way for him to understand people. He can do that just fine. They're a way to help people understand him, something he can't do on his own. He struggles with his oddity and with being left outand he's willing to use people, to an extent, to feel like he belongs. He even recognizes that his own friends occasionally see him as something lesser, but he doesn't know how to express his frustration.
That's a lot of depth, and yet all of this is handled delicately. It's a testament to the collaborative effort on display, the willingness by everybody involved to let each other bring their gifts to the table and let the best possible result unfold. It manages to be touching without being saccharine, to be funny without being alienating, and to be fundamentally true despite being admittedly contrived.
Please watch Community. You'll be glad you did.
Monday, November 22, 2010
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.
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.
Saturday, November 20, 2010
Thoughts on Harry Potter and the Deathly Hallows (pt. 1)
Last summer, I re-read and posted my thoughts on the seventh and final entry in the Harry Potter series. At the time, I mentioned that I had serious problems with a number of elements of the book, both in terms of content and in structure. I also noted that my love of the characters and the ultimate redemption of Snape ultimately made the experience worthwhile. It's safe to say that, by and large, the same holds of part 1 of the film adaptation.
Since I already said pretty much all I have to say on the content of the book, I'm going to take this space to focus on some issues unique to the movie.
First, as anybody familiar with both the books and the movies would expect, the creators had to do a bit of backpedaling in order to make certain elements work. Instead of simply cutting the wedding scene, we get a ridiculously half-assed introduction of Bill ("Hi, Harry, I'm Bill Weasely. I got attacked by a were-wolf and like my meat on the raw side now!" "Oh, nice to finally meet you, Bill").
More distracting, as you might expect, was the way that Dobby was forced back into things after having all of his involvement since Chamber of Secrets cut out. I know that Dobby's sacrifice is immensely moving in the books, but movie-watchers have no familiarity with Dobby's work at Hogwarts or his adventures with Winky or Hermione's creation of SPEW.
I'm not even going to try to describe all of the problems with the scene where Harry and Hermione dance in the tent.
The final problem is that the screenwriters obviously didn't put enough time into some of the dialogue. There were a few lines so clunky that the audience actually laughed. In some cases, it was simply because the characters needed to express thoughts or explain things that could not have been spoken by a human being in a way that didn't sound ridiculous. This is a relatively common problem with any fantasy setting, and in these instances, the writers did a decent job of hanging the lampshade* and creating intentional humor out of the situation. But there were other areas where they didn't seem to recognize the problems. Similarly, the way they shot Harry's interactions with "Bathilda Bagshot" evoked laughter at a number of times in what was supposed to be a tense scene.
The filmmakers did a number of things extremely right, though. For one thing, the death of Hedwig, while a bit abrupt, made far more sense in this setting. Instead of getting hit randomly by a killing curse while stuck in her cage, she swoops in and harasses a Death Eater who was trying to shoot Harry. Not only did it provide Voldemort a much more reasonable means of identifying Harry than "OMG, he used expeliarmus! It must be Potter", but it makes more sense, since there's no good reason that Harry wouldn't have let Hedwig fly freely and find him at The Barrows later.
Second, the infiltration of the Ministry was one of the most entertaining scenes in the series so far. The actors who got to play the Ministry officials into whom our heroes polymorphed must have had boatloads of fun. The physicality of their performances was just perfect. It turned what was kind of an awkward, tense scene in the books into a great tension alleviator, punctuated at points by signs of just how twisted the Ministry had become under Death Eater control.
Third, as much as a handful of critics complained about the camping scenes, I felt that they were handled quite well (with the exception of the aforementioned dance). The creators did a good job of displaying the impact of The Locket on people's temperaments and of Ron's growing insecurity with minimal time commitment. Hermione's almost run-in with the Snatchers seemed a bit purposeless beyond showing the potency of the charms they had set up, but I won't complain too much about that. Unfortunately, we didn't get to see much of how Ron's absence strained Harry and Hermione, but I won't hold that against them overmuch. Ron was only gone for 80 pages in the book (mostly spent at Godric's Hollow), and the impact of his departure is something that was almost entirely told and not shown.
Finally, the animation used for the Story of the Three Brothers was absolutely fantastic. I would buy a DVD just containing the various Tales of Beedle the Bard told in that fashion in a heartbeat.
So, not a great movie for a person who isn't particularly fond of the source material, but an enjoyable time for Harry Potter fans. I'll never be convinced that Deathly Hallows was the appropriate way to end the series, but David Yates and crew are showing that they're devoted to making the best adaptation they can.
Since I already said pretty much all I have to say on the content of the book, I'm going to take this space to focus on some issues unique to the movie.
First, as anybody familiar with both the books and the movies would expect, the creators had to do a bit of backpedaling in order to make certain elements work. Instead of simply cutting the wedding scene, we get a ridiculously half-assed introduction of Bill ("Hi, Harry, I'm Bill Weasely. I got attacked by a were-wolf and like my meat on the raw side now!" "Oh, nice to finally meet you, Bill").
More distracting, as you might expect, was the way that Dobby was forced back into things after having all of his involvement since Chamber of Secrets cut out. I know that Dobby's sacrifice is immensely moving in the books, but movie-watchers have no familiarity with Dobby's work at Hogwarts or his adventures with Winky or Hermione's creation of SPEW.
I'm not even going to try to describe all of the problems with the scene where Harry and Hermione dance in the tent.
The final problem is that the screenwriters obviously didn't put enough time into some of the dialogue. There were a few lines so clunky that the audience actually laughed. In some cases, it was simply because the characters needed to express thoughts or explain things that could not have been spoken by a human being in a way that didn't sound ridiculous. This is a relatively common problem with any fantasy setting, and in these instances, the writers did a decent job of hanging the lampshade* and creating intentional humor out of the situation. But there were other areas where they didn't seem to recognize the problems. Similarly, the way they shot Harry's interactions with "Bathilda Bagshot" evoked laughter at a number of times in what was supposed to be a tense scene.
The filmmakers did a number of things extremely right, though. For one thing, the death of Hedwig, while a bit abrupt, made far more sense in this setting. Instead of getting hit randomly by a killing curse while stuck in her cage, she swoops in and harasses a Death Eater who was trying to shoot Harry. Not only did it provide Voldemort a much more reasonable means of identifying Harry than "OMG, he used expeliarmus! It must be Potter", but it makes more sense, since there's no good reason that Harry wouldn't have let Hedwig fly freely and find him at The Barrows later.
Second, the infiltration of the Ministry was one of the most entertaining scenes in the series so far. The actors who got to play the Ministry officials into whom our heroes polymorphed must have had boatloads of fun. The physicality of their performances was just perfect. It turned what was kind of an awkward, tense scene in the books into a great tension alleviator, punctuated at points by signs of just how twisted the Ministry had become under Death Eater control.
Third, as much as a handful of critics complained about the camping scenes, I felt that they were handled quite well (with the exception of the aforementioned dance). The creators did a good job of displaying the impact of The Locket on people's temperaments and of Ron's growing insecurity with minimal time commitment. Hermione's almost run-in with the Snatchers seemed a bit purposeless beyond showing the potency of the charms they had set up, but I won't complain too much about that. Unfortunately, we didn't get to see much of how Ron's absence strained Harry and Hermione, but I won't hold that against them overmuch. Ron was only gone for 80 pages in the book (mostly spent at Godric's Hollow), and the impact of his departure is something that was almost entirely told and not shown.
Finally, the animation used for the Story of the Three Brothers was absolutely fantastic. I would buy a DVD just containing the various Tales of Beedle the Bard told in that fashion in a heartbeat.
So, not a great movie for a person who isn't particularly fond of the source material, but an enjoyable time for Harry Potter fans. I'll never be convinced that Deathly Hallows was the appropriate way to end the series, but David Yates and crew are showing that they're devoted to making the best adaptation they can.
Thursday, November 4, 2010
Calling All Eyes (pt. 1)
I'm applying for the NSF Graduate Research Fellowship Program, and the materials are due in two weeks minus a few hours. I feel like I'm finally approaching acceptable drafts of my essays, but plenty of proof-readers can't hurt. So, here's the current working draft of my personal statement with the research proposal and previous research to follow shortly. Any and all comments are encouraged, and please especially point out contractions. I write so conversationally that it's hard for me to weed them all out and I don't always catch them when I'm reading. The conclusion is also incomplete, so ideas there would be great (I hate writing conclusions). Thanks in advance and feel free to tell your friends:
__________________
As I look around at my peers taking their first steps towards earning a 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 as they took 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 IT departments at manufacturing and distribution plants, 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. Combined with my own internship experiences, I quickly came to the realization that, while I could perform well there, industry wasn't quite the right fit for me. Whereas products are of limited appeal to me, novel problems can keep me captivated endlessly. Further, I was surprised to realize, upon reflection, that the work I did with students were among the most fulfilling experiences of my life. The obvious route appeared to be a PhD and a career in academia, but I had come to view programmers as “my people”, and I knew that the only way I would be happy in the ivory tower was if I felt like I was doing work that would help them to be fruitful and multiply. To my understanding, there is no better path to this goal than working to improve the most fundamental tools at the disposal of every programming: programming languages.
We live in a rapidly digitizing world, and while plenty of us have not yet bought into the smart-phone revolution, I can't 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. That isn't likely to happen if people need to use Objective C or Java or even Python to do so. Alternatively, if we do expect users to adapt to the demands of modern high level languages, we will need to provide better environments in which to program, environments that have a better understanding of the code and of the resources readily available for expanding or improving it. More worrisome is the simple truth that applications developed by such para-programmers are likely to be riddled with gaping errors and security vulnerabilities. We need tools that can identify these problems, explain the problem in comprehensible language, and even suggest fixes. 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. Current abstractions for concurrency are fraught with difficulties and simply aren't sufficient to this task. These are all tasks that fall to 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 researchers.
When the time came to decide where I wanted to pursue these goals, it was easy to choose the University of Colorado at Boulder. For one thing, 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 make a name for their lab. 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 done with a strong eye towards the tenets of Human Computer Interaction. After all, if we make a tool that is difficult to use, no matter how great its functionality, then we have made 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, the purpose of academia is not just to achieve our own goals. We do not simply seek to make new advances and build new connections in order to gain renown or satisfy our own curiosity. We work to push the state of the art so that the next generation can push it even further. This work isn't complete if we don't prepare the next generation to pick up where we left off and provide them with the necessary resources to do so. This, along with my professed love of teaching, is why I hope to return to the liberal arts when the time comes. Ideally, my work and my particular view of Programming Languages will benefit my pedagogy. I hope to come to a more human understanding of computing so that I can better predict the obstacles my students will face and design curricula that will mitigate their struggles while helping them gain an appreciation for both the art of programming and the principles that govern it. Moreover, as my career in academia progresses, I hope not just to network with my colleagues but to build working relationships that will help me find the sorts of opportunities for my students that small colleges are too often lacking.
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.
__________________
As I look around at my peers taking their first steps towards earning a 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 as they took 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 IT departments at manufacturing and distribution plants, 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. Combined with my own internship experiences, I quickly came to the realization that, while I could perform well there, industry wasn't quite the right fit for me. Whereas products are of limited appeal to me, novel problems can keep me captivated endlessly. Further, I was surprised to realize, upon reflection, that the work I did with students were among the most fulfilling experiences of my life. The obvious route appeared to be a PhD and a career in academia, but I had come to view programmers as “my people”, and I knew that the only way I would be happy in the ivory tower was if I felt like I was doing work that would help them to be fruitful and multiply. To my understanding, there is no better path to this goal than working to improve the most fundamental tools at the disposal of every programming: programming languages.
We live in a rapidly digitizing world, and while plenty of us have not yet bought into the smart-phone revolution, I can't 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. That isn't likely to happen if people need to use Objective C or Java or even Python to do so. Alternatively, if we do expect users to adapt to the demands of modern high level languages, we will need to provide better environments in which to program, environments that have a better understanding of the code and of the resources readily available for expanding or improving it. More worrisome is the simple truth that applications developed by such para-programmers are likely to be riddled with gaping errors and security vulnerabilities. We need tools that can identify these problems, explain the problem in comprehensible language, and even suggest fixes. 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. Current abstractions for concurrency are fraught with difficulties and simply aren't sufficient to this task. These are all tasks that fall to 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 researchers.
When the time came to decide where I wanted to pursue these goals, it was easy to choose the University of Colorado at Boulder. For one thing, 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 make a name for their lab. 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 done with a strong eye towards the tenets of Human Computer Interaction. After all, if we make a tool that is difficult to use, no matter how great its functionality, then we have made 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, the purpose of academia is not just to achieve our own goals. We do not simply seek to make new advances and build new connections in order to gain renown or satisfy our own curiosity. We work to push the state of the art so that the next generation can push it even further. This work isn't complete if we don't prepare the next generation to pick up where we left off and provide them with the necessary resources to do so. This, along with my professed love of teaching, is why I hope to return to the liberal arts when the time comes. Ideally, my work and my particular view of Programming Languages will benefit my pedagogy. I hope to come to a more human understanding of computing so that I can better predict the obstacles my students will face and design curricula that will mitigate their struggles while helping them gain an appreciation for both the art of programming and the principles that govern it. Moreover, as my career in academia progresses, I hope not just to network with my colleagues but to build working relationships that will help me find the sorts of opportunities for my students that small colleges are too often lacking.
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.
Subscribe to:
Posts (Atom)