Key Moments
Update on the Natural Programming Project
Google TalksWant to know something specific about what's covered?
We've already dissected every moment. Ask and we will deliver (with timestamps).
Key Moments
Programming tools are often designed without understanding how humans naturally think, leading to decades-old debugging methods and inefficient workflows, but new research aims to bridge this gap.
Key Insights
Nearly 75% of programmers spend three-quarters of their time testing and debugging, with over 66% of bugs arising from incorrect hypotheses during the debugging process.
The "Why Line" system, which allows programmers to ask direct 'why' and 'why not' questions about program execution, demonstrated an 8x speed-up in task completion and a 40% increase in overall productivity in early studies.
A significant portion of programmers' time (35%) is spent on navigation within code, often involving wasteful scrolling or difficulty locating relevant sections, highlighting a need for better code organization tools.
Factory patterns, commonly used in languages like Java (61 times) and .NET (13 times), can cause a 2-5x increase in task completion time for expert programmers due to their confusing nature.
End-user programmers, a group estimated at 80 million people worldwide, often struggle with programming languages because they are not their primary job function, and the complexity of associated libraries and APIs adds further barriers.
Interaction designers find creating interactive behaviors significantly harder (86% agreement) than designing visual appearance, underscoring a need for tools that better support exploratory design and behavior implementation.
Rethinking programming through a human-centered lens
The Natural Programming Project, initiated in 1995 and ongoing for over 12 years at the time of this talk, fundamentally aims to make programming languages and environments more intuitive, effective, and less prone to errors. The core philosophy rejects the traditional, mathematics-driven approach favored by programming language theorists. Instead, it adopts a human-computer interaction (HCI) methodology by studying how people naturally think and perform tasks, and then designing tools that align with these natural tendencies. This approach considers all types of programmers, from seasoned professionals to novices and end-user programmers who program out of necessity rather than passion. The project emphasizes rigorous evaluation through user studies, collecting empirical data to validate the effectiveness of designed systems, a practice often lacking in traditional software engineering research.
The persistent problem of debugging: 'why' and hypothesis-driven errors consume programmer time
Debugging remains a massive bottleneck in software development, consuming approximately 75% of a programmer's time. A key challenge identified by the project is the prevalence of "why not" questions, where programmers are trying to understand why something *didn't* happen, a task poorly supported by traditional debugging techniques like print statements or breakpoints. Furthermore, the research revealed that programmers often form hypotheses about bug causes, with 90% of these hypotheses being incorrect. This leads to a vicious cycle: 66% of bugs are introduced when programmers attempt to fix an issue based on a faulty hypothesis, essentially adding more bugs on top of the existing ones. The project's "Why Line" system directly addresses this by allowing programmers to ask explicit "why" and "why not" questions about program execution, significantly speeding up the debugging process.
The 'Why Line' radically improves debugging efficiency
The "Why Line" system was developed to directly tackle the inefficiencies of traditional debugging. It allows users to ask questions like "why did this happen?" or "why did this not happen?" about program execution. Early versions, implemented in environments like Alice, showed dramatic improvements: programmers were eight times faster, and overall productivity increased by 40%. This system works by tracing program execution, logging every event, and then providing an interface to query this trace. A crucial interaction technique involves allowing users to point to an element on the screen (e.g., a UI element displaying an incorrect color) and ask why it has that state. This focuses the queries on relevant aspects of the program's execution, making the "why" and "why not" questions more manageable and meaningful. The system was later reimplemented for Java, demonstrating its potential to benefit a much wider audience beyond specialized environments.
Addressing inefficiencies in navigation and API design
Beyond debugging, the Natural Programming Project identifies other significant areas of inefficiency. Studies revealed that programmers spend 35% of their time navigating code, often through wasteful scrolling or difficulty finding relevant sections, even with advanced IDE features. Tools like "Jasper" were proposed to combat this by collecting and presenting relevant code snippets, documentation, and notes together, aiming to streamline the process of understanding and working with unfamiliar codebases. Furthermore, the project views API design as a form of user interface design. Studies on common API patterns like required constructors and factory patterns reveal that conventional wisdom is often counterproductive. For instance, required constructors can confuse developers, and factory patterns, despite their prevalence (61 times in Java), can slow down expert programmers by two to five times due to their complexity and unnatural interface.
The growing importance and challenges of end-user programming
The landscape of programming is expanding beyond professional developers. The concept of "end-user programmers" – individuals who program as a means to an end in their primary job, not as their profession – represents a massive, largely underserved market, estimated at 80 million people. These users face unique challenges: they are not motivated by programming itself and must contend with a vast array of libraries and APIs beyond the core language. The project's research into human-data interaction, leading to systems like "TAes" (natural data types), aims to make programming more accessible by allowing users to describe data in natural terms (e.g., 'person names' or 'dates') with associated rules and properties, enabling more intelligent validation and conversion across different formats and applications like Excel and web forms.
Bridging the gap between design and implementation for interactive behaviors
The project also extends its human-centered approach to interaction designers. Research indicates that designers find authoring interactive behaviors significantly more challenging (86% agreement) than designing static visual appearance. They often use sketching and annotations to convey behavior, but current tools lack robust support for exploring and iterating on behaviors, forcing designers to spend hours implementing each version. The project proposes developing tools that allow for more fluid, exploratory behavior creation, recognizing that designers often don't know the final solution until they start designing. This exploratory approach, where design and implementation are intertwined, may be more suitable for prototyping and for designers who are not primarily software engineers.
Understanding code and uncovering 'update paths' for complex systems
Reverse engineering and understanding unfamiliar code is a universal challenge for programmers. The project has modeled the process programmers use: discovering facts about code, learning, critiquing, proposing changes, and implementing them. Experts tend to identify higher-level patterns and root causes, while novices focus on symptoms. A critical aspect of this understanding involves tracing "update paths" – how data flows through the system in response to user actions or external events. Current tools, like call graphs, are often too broad and unmanageable. The research is developing methods to visualize and query these update paths more effectively, helping programmers understand the implications of changes across complex systems and avoid breaking functionality in unexpected ways.
Mentioned in This Episode
●Products
●Software & Apps
●Companies
●Organizations
●Concepts
●People Referenced
Common Questions
The main goal of the Natural Programming Project is to make programming easier and more human-centered by approaching it from the perspective of how people naturally think, rather than forcing them into rigid, mathematical constructs.
Topics
Mentioned in this video
The central research project discussed, aiming to make programming more natural and human-centered, ongoing for about 12 years.
A concept mentioned in the context of abstraction levels in programming, contrasting mathematical explanations with user intuition.
A programming approach mentioned as attempting to lower abstraction levels to feel more concrete for programmers, similar to the discussed research.
A type of end-user programming activity that the research aims to make easier and more effective.
A programming paradigm discussed in relation to API design, particularly concerning default constructors and distributed implementation.
A programming paradigm mentioned alongside object-oriented programming, highlighting the distributed nature of modern software implementation.
A controversial API design pattern studied, found to confuse users and significantly slow down code development.
A programming pattern that was inquired about by the audience but not directly studied by the speaker.
A programming pattern that was inquired about by the audience but not directly studied by the speaker.
Colleague of Brad Myers who developed the Alice programming environment.
Speaker from Carnegie Mellon discussing the natural programming project, focusing on making programming more human-centered and natural.
Theorists who identified 'closest of mapping' as a parameter to measure how close a user's goal is to its expression.
A former student who started the Natural Programming Project with Brad Myers, studying how people naturally express algorithms.
A programming environment used by professional programmers, compared against the 'Why Line' tool in a user study.
Mentioned as the underlying representation for code in the Barista system, allowing for flexible reformatting.
A platform on which the Feldspar search tool is built.
A tool used by interaction designers to create user interfaces, mentioned in the context of authoring interactive behaviors.
A programming language designed for kids, embodying results from studies on natural expression of programming concepts.
A programming environment developed by Randy P, used for initial implementation and testing of the 'Why Line' tool.
A debugging tool developed by Brad Myers' group that helps programmers ask 'why' and 'why not' questions about program execution.
A programming language for which the 'Why Line' tool was reimplemented, allowing it to work with complete Java systems.
A word processing application discussed in the context of extending 'why' debugging capabilities beyond programming languages.
A Java Aid tool that collects and presents relevant code snippets, documentation, and notes for specific programming tasks.
Microsoft Developer Network, mentioned as a traditional resource for learning APIs, contrasted with using Google search.
A tool that uses Google APIs to help users find relevant API calls by searching and extracting keywords and code examples.
A toolkit for structured textual abstractions for Java code editing, aiming to bridge the gap between structured and plain text editors.
A software framework mentioned as a platform where factory patterns are used frequently.
A search tool designed to help users find things based on association rather than direct identification.
An image editing software used by interaction designers, mentioned in the context of annotations for explaining behaviors.
A tool that separates design and behavior implementation, discussed in contrast to a more integrated design approach.
Mentioned as a company that the speaker's research is applicable to, particularly around organizing information and providing APIs.
Mentioned for providing data on creative workers and potentially sponsoring research related to designer interaction.
Mentioned as a company where studies of programmers were conducted and for its product like Microsoft Word.
A toolkit that adds 'why' capability to applications like Microsoft Word, showing the specific UI option that caused an event.
A department at Carnegie Mellon focused on user interfaces, with faculty from computer science, psychology, and design.
A company where programmer studies were conducted. Also mentioned for its extensive use of factory patterns.
A version control system mentioned in the context of saving collected code snippets and notes with a project.
More from GoogleTalksArchive
View all 48 summaries
58 minEverything is Miscellaneous
54 minStatistical Aspects of Data Mining (Stats 202) Day 7
45 minKey Phrase Indexing With Controlled Vocabularies
63 minMysteries of the Human Genome
Ask anything from this episode.
Save it, chat with it, and connect it to Claude or ChatGPT. Get cited answers from the actual content — and build your own knowledge base of every podcast and video you care about.
Get Started Free