Learnable Programming by Bret Victor

Learnable Programming -- Designing a programming system for understanding programs

• Programming is a way of thinking, not a rote skill.
• People understand what they can see. If a programmer cannot see what a program is doing, she can't understand it.
• The goals of a programming system should be:
• to support and encourage powerful ways of thinking
• to enable programmers to see and understand the execution of their programs
• A person is not a machine, and should not be forced to think like one.
• A programming system has two parts. The programming "environment" is the part that's installed on the computer. The programming "language" is the part that's installed in the programmer's head.
• The environment should allow the learner to:
• read the vocabulary -- what do these words mean?
• follow the flow -- what happens when?
• see the state -- what is the computer thinking?
• create by reacting -- start somewhere, then sculpt
• create by abstracting -- start concrete, then generalize
• The language should provide:
• identity and metaphor -- how can I relate the computer's world to my own?
• decomposition -- how do I break down my thoughts into mind-sized pieces?
• recomposition -- how do I glue pieces together?
• readability -- what do these words mean?
• A well-designed system is not simply a bag of features. A good system is designed to encourage particular ways of thinking, with all features carefully and cohesively designed around that purpose.
• In a modern environment, memorizing the minutia of an API should be as relevant as memorizing times tables.
• The environment is responsible for making meaning transparent.
• A programming environment is a user interface for understanding a program.
• One attribute of great explanations is that they are often embedded in the context of what they are explaining. That is, they show as well as tell.
• The environment should make meaning transparent, so the learner can concentrate on high-level concepts, not vocabulary.
• The environments should explain in context. Show and tell. Annotate the data, not just the code.
• People understand things that they can see and touch. In order for a learner to understand what the program is a actually doing, the program flow must be made visible and tangible.
• The environment can make flow tangible, by enabling the programmer to explore forward and backward at her own pace.
• The environment can make flow visible, by visualizing the pattern of execution.
• The environment can represent time at multiple granularities, such as frames or event responses, to enable exploration across these meaningful chunks of execution.
• The entire propose of code is to manipulate data, and we never see the data.
• Information design pioneer Edward Tufte has one primary rule, and this rule should be the principle underlying any environment for creating or understanding: Show the data.
• If you are serious about creating a programming environment for learning, the number one thing you can do -- more important than live coding or adjustable constants, more important than narrated lessons or discussion form, more important than badges or points or ultra-points or anything else -- is to show the data.
• Because the value of a variable varies over time, showing the data is intimately connected with showing time.
• Edward Tufte has a second rule. It is not enough to just show the data. We must show comparisons.
• Data needs context. It is rarely enough to see a single data point in isolation. We understand data by comparing it to other data.
• In order to understand what a line of code does, the learner must see its effect.
• [There are two ways to handle state.] One alternative is to eliminate the state. The other alternative is to show the state. All state must be eliminated or shown.
• Code manipulates data. To understand code, a learner must see the data, and see the effect of code on the data.
• The environment must show the data. If a line of code computes a thing, that thing should be immediately visible.
• The environment must show comparisons. If a program computes many things, all of those things should be shown in context. This is nothing more than data visualization.
• The system must have no hidden state. State should either be eliminated, or represented as explicit objects on the screen. Every action must have a visible effect.
• Working in [inside] the head doesn't scale. The head is a hardware platform that hasn't been updated in millions of years. To enable the programmer to achieve increasingly complex feats of creativity, the environment must get the programmer out of her head, but providing an external imagination where the programmer can always be reading to a work in-progress.
• Get something on the screen as soon as possible.
• The environment is the user interface for working with a program.
• The create-by-reacting way of thinking could be stated as: start with something, then adjust until it's right.
• The programmer must be able to do her thinking out in the environment, not trapped in her head. The environment must serve as an external imagination, where the programmer can be continuously reacting to a work-in-progress.
• The environment must be designed to get something on the screen as soon as possible, so the programmer can start reacting. This requires modeling the programmer's thought process, and designing a system that can pick up on the earliest possible seed of thought.
• The environment must dump the parts bucket onto the floor, allowing the programmer to continuously react to her raw material and spark new ideas.
• Learning programming is learning abstraction.
• The learner should start by writing concrete code, and then gradually change it to introduce abstraction. And the environment must provide the tools to perform this process, in such a way that the learner can understand the program at each stage.
• In the create-by-abstracting way of thinking, the programmer starts by creating a specific case, typically involving constants. She then moves to the general case by turning those constants into variables.
• Start concrete, start grounded. Start with one specific case, entirely understood. Then gradually generalize, level by level, in such a way that the programmer still fully understands the program at each level of abstraction.
• The environment should encourage the learner to start constant, then vary, by providing meaningful ways of gradually and seamlessly transitioning constant expressions into variable expressions.
• The environment should encourage the learner to start with one, then make many, but providing ways of using those variables expressions at a higher level, such as function application or looping.
• A programming system has two parts. The environment is installed on the computer, and the language is installed in the programmer's head.
• The design of the language is just as critical to the programmer's way of thinking as the design of the environment. IN the best cases, they are co-designed and inseparable.
• The canonical work on designing programming systems for learning, and perhaps the greatest book ever written on learning in general, is Seymour Papert's "Mindstorms".
• Every programming language is made of metaphors, but some fit the mind better than others. Standard imperative programming uses the metaphor of "assigning to variables", shuffling bits between little boxes.
• Modularity is the human mind's lever against complexity. Breaking down a complex thing into understandable chunks is essential for understanding, perhaps the essence of understanding.
• A programming language must encourage the programmer to decompose--to approach a complex problem by breaking it into simpler problems.
• A language that discourages decomposition is a language that cripples a programmer's most valuable way of thinking.
• Creating is remixing. To a large extend, new ideas are old ideas in new combinations.
• A programming language must encourage recomposition--grabbing parts of other programs, assembling them together, modifying them, building on top of them. This gives creators the initial material they need to create by reacting, instead of facing every new idea with a blank page. It also allows creators to learn from each other, instead of deriving techniques and style in a vacuum.
• Designing a system that supports recomposition demands long and careful thought, and design decisions that make programming more convenient for individuals may be detrimental to social creation.
• A learner must be able to look at a line of code and know what it means. Syntax matters.
• A language must be parsed by people, not just compilers.
• People are inherently creative, and some will manage to create in even the most hostile of environments. That doesn't justify bad design.
• Traditional visual environments visualize the code. They visualize static structure. But that's not what we need to understand. We need to understand what the code is doing.
• Visualize data, not code. Dynamic behavior, not static structure.