Sound Bytes

Here are some "Sound Bytes" that I have used to describe my vision. Many are elaborated elsewhere in this blog, but it helps to have everything together in one place:

I want to be a teacher, not a programmer. I don't just mean that I would prefer academia to industry, though that statement is mostly true. I mean that I want to be able to teach a computer, not program it to follow a set of instructions. Currently computers are not very teachable. Many researchers are focusing on the back-end AI and machine learning algorithms necessary for a computer to learn, but learning from a teacher requires two-way interaction. I want to develop this interaction. That is, I want to approach teaching a computer—what is today called programming—as a task in human-computer interaction.

Today, the user types in cryptic code and the computer responds with error messages. My new view of programming is as a process by which a computer helps a human clarify, communicate, and refine ideas. Teaching how to program should be teaching how to teach. The implications of this new view range from end-user development, to modularization, to correctness, to optimization, to educational technology.

This new view requires changes to how we make computers programmable. Instead of just developing new programming languages, we must develop programming environments that allow ideas and relationships to be manipulated in natural, familiar ways. Instead of using syntax to forbid ambiguity, we should allow the user to represent an idea or concept that has not yet been fully developed and help him/her develop it. Ask the user questions about corner cases and reason about them. Likewise, let the user ask questions (e.g., the CMU Natural Programming group’s Whyline). Wherever possible, show behavior “live” (e.g., MIT's Flogo II). The programming environment should guide the user's reasoning toward a consistent and correct concept of the task, clearly communicated to the computer at sufficient detail for unambiguous execution. Programmers should develop concepts, not code.

I envision starting with the development of an end-user programming environment that works with concepts instead of instructions and allows a managed degree of ambiguity. I have done extensive background research on this topic within the context of end-user programming systems. My literature survey paper, done for a technical writing class last semester, is linked on the sidebar.