October 30, 2012 4:22 PM

Mathematical Formulas, The Great Gatsby, and Small Programs

... or: Why Less Code is Better

In Don't Kill Math, Evan Miller defends analytic methods
in the sciences against Bret Victor's "visions for computer-assisted creativity and scientific understanding". (You can
see some of my
reactions to Victor's vision in a piece I wrote about his StrangeLoop talk.)

Miller writes:

For the practicing scientist, the chief virtue of analytic methods can be summed up in a single word:
clarity. An equation describing a quantity of interest conveys what is important in determining that
quantity and what is not at all important.

He goes on to look at examples such as the universal law of gravitation and shows that a single formula gives even a
person with "minimal education in physics" an economical distillation of what matters. The clarity provided by a good
analytic solution affords the reader two more crucial benefits: confident understanding and memorable
insights.

Poet Peter Turchi describes a related phenomenon in fiction writing, in his essay
You and I Know, Order is Everything. A story can pull us forward by omitting details and thus creating in the reader
a desire to learn more. Referring to a particularly strategic paragraph, he writes:

That first sentence created a desire to know certain information: What is this significant event? ... We still
don't have an answer, but the context for the question is becoming increasingly clear -- so while we're eager to have
those initial questions answered, we're content to wait a little longer, because we're getting what seems to be
important information. By the third paragraph, ... we think we've got a clue; but by that time the focus of the
narrative is no longer the simple fact of what's going on, but the [larger setting of the story]. The story has shifted
our attention from a minor mystery to a more significant one. On some level or another nearly every successful story
works this way, leading us from one mystery to another, like stepping stones across a river.

In a good story, eventually...

... we recognize that the narrator was telling us more than we could understand, withholding information but also
drawing our attention to the very thing we should be looking at.

In two very different contexts, we see the same forces at play. The quality of a description follows from the balance
it strikes between what is in the description and what is left out.

To me, this is another example of how a liberal education can benefit students majoring in both the sciences and the
humanities [ 1
| 2 ]. We can
learn about many common themes and patterns of life from both traditions. Neither is primary. A student can encounter the
idea first in the sciences, or first in the humanities, whichever interests the student more. But apprehending a
beautiful pattern in multiple domains of discourse can reinforce the idea and make it more salient in the preferred
domain. This also broadens our imaginations, allowing us to see more patterns and more subtlety in the patterns we
already know.

So: a good description, a good story, depends in some part on the clarity attendant in how it conveys what is
important and what is not important. What are the implications of this pattern for programming? A computer program is,
after all a description: an executable description of a domain or phenomenon.

I think this pattern gives us insight into why less code is usually better than more code. Given two functionally
equivalent programs of different lengths, we generally prefer the shorter program because it contains only what matters.
The excess code found in the longer program obscures from the reader what is essential. Furthermore, as with Miller's
concise formulas, a short program offers its reader the gift of more confident understanding and the opportunity for
memorable insights.

What is not in a program can tell us a lot, too. One of the hallmarks of expert programmers is their ability
to see the negative
space in a design and program and learn from it. My students, who are generally novice programmers, struggle with
this. They are still learning what matters and how to write descriptions at all, let alone concise one. They are still
learning how to focus their programming tools, and on what.

October 24, 2012 11:38 AM

"Don't Break the Phone; Fix the Computer"

Twenty years ago, you expected a phone to be provided everywhere you went, and that phone worked the same
everywhere. At a friend's house, or a restaurant, or a hotel, or a pay phone, you could pick up the receiver and make a
call. You didn't carry a phone around with you; phones were part of the infrastructure. Computers, well, that was a
different story. As laptops came in, people started carrying computers around with them everywhere. The reason was to
have the state stored on the computer, not the computer itself. You carry around a computer so you can access its
disk.

In summary, it used to be that phones worked without you having to carry them around, but computers only worked
if you did carry one around with you. The solution to this inconsistency was to break the way phones worked rather than
fix the way computers work.

October 19, 2012 3:08 PM

Computer Programming, Education Reform, and Changing Our Schools

You almost can't go wrong by revisiting Seymour Papert's work every so often. This morning I read Why School Reform Is Impossible, which reminds us that
reform and change are different things. When people try to "reform" education by injecting a new idea
from outside, schools seem to assimilate the reform into its own structure, which from the perspective of the reformer
blunts or rejects the intended reform. Yet schools and our education system do change over time, evolving as the
students, culture, and other environmental factors change.

As people such as Papert and Alan Kay have long argued, a big part of the problem in school reform involving computers
is that we misunderstand what a computer is:

If you ask, "Which is not like the other two?" in the list "educational movie, textbook, computer", it is pretty
obvious from my perspective that the answer must be "computer."

... not "textbook", which is how most people answer, including many people who want to introduce more computers into
the classroom. Textbooks and movies are devices for receiving content that someone else made. Computers are for
creating content. It just so happens that we can use them to communicate ideas in new ways, too.

This misunderstanding leads people to push computers for the wrong reasons, or at least for reasons that miss their
game-changing power. We sometimes here that "programming is the new Latin". Papert reminds us that the reasons we used to
teach Latin in schools changed over time:

In recent times, Latin was taught in schools because it was supposed to be good for the development of general
cognitive skills. Further back, it was taught because it was the language in which all scholarly knowledge was
expressed, and I have suggested that computational language could come to play a similar role in relation to quite
extensive areas of knowledge.

If programming is the new Latin, it's not Latin class, circa 1960, in which Latin taught us to be rigorous students.
It's Latin class, circa 1860 or 1760 or 1560, in which Latin was the language of scholarly activity. As we watch
computing become a central part of the language of science, communication, and even the arts and humanities, we will
realize that students need to learn to read and write code because -- without that skill -- they are left out of the
future.

No child left behind, indeed.

In this essay, Paper gives a short version of his discussion in Mindstorms of why we teach the
quadratic equation of the parabola to every school child. He argues that its inclusion in the curriculum has more to do
with its suitability to the medium of the say -- pencil and paper -- than to intrinsic importance. I'm not too sure
that's true; knowing how parabolas and ellipses work is pretty important for understanding the physical world. But it is
certainly true that how and when we introduce parabolas to students can change when we have a computer
and a programming language at hand.

Even at the university we encounter this collision of old and new. Every student here must take a course in
"quantitative reasoning" before graduating. For years, that was considered to be "a math course" by students and advisors
alike. A few years ago, the CS department introduced a new course into the area, in which students can explores a lot of
the same quantitative issues using computation rather than pencil and paper. With software tools for modeling and
simulation, many students can approach and even begin to solve complex problems much more quickly than they could working
by hand. And it's a lot more fun, too.

To make this work, of course, students have to learn a new programming language and practice using it in meaningful
ways. Papert likens it to learning a natural language like French. You need to speak it and read it. He says we would
need the programming analog of "the analog of a diverse collection of books written in French and access to
French-speaking people".

The Scratch community is taking at shot at this. The Scratch website offers not
only a way to download the Scratch environment and a way to view tutorials on creating with Scratch. It also offers --
front and center, the entire page, really -- links to shared projects and galleries. This gives students a chance first
to be inspired by other kids and then to download and read the actual Scratch programs that enticed them. It's a great
model.

The key is to help everyone see that computers are not like textbooks and televisions and movie projectors. As
Mitch Resnick has
said:

Computers for most people are black boxes. I believe kids should understand objects are "smart" not because they're
just smart, but because someone programmed them to be smart.

What's most important ... is that young children start to develop a relationship with the computer where they
feel they're in control. We don't want kids to see the computer as something where they just browse and click. We want
them to see digital technologies as something they can use to express themselves.

Don't just play with other people's products. Make your own.

Changes in the world's use of computing may do more to cause schools to evolve in a new direction than anyone's
educational reforms ever could. Teaching children that they can be creators and not simply consumers is a subversive
first step.

October 17, 2012 3:32 PM

What Our Students Think of Us

Following a recommendation on Twitter, I recently read Am I
A Product Of The Institutions I Attended?, the text of a speech by Amitabha
Bagchi. Bagchi is a novelist who studied computer science in school. It is a reflection on what we learn in and out
of school, which isn't always what our schools intend. He closes the paper with some thoughts on being a teacher.

... as all of us who have been teachers for even a short while know, all we can do is give people an opportunity to
learn. And if they don't learn, we can give them another opportunity, and another.

Students learn on their schedules, not ours. All we can do is to keep providing opportunities, so that when they are
ready, an opportunity awaits them.

This passage:

Like so many other teachers I spend a lot of time thinking about my students, and, also like many other teachers, I
don't spend enough time thinking about what they think of me.

... launches a discussion that touched a chord in me. As a high school student, Bagchi realized that students see
their teacher as a figure of authority and decorum no matter the reality on any given day. The teacher may be young, or
inexperienced, or emotionally out of sorts. But to them, the teacher is The Teacher.

So there you are, you poor teacher, frozen in eternal adulthood, even on those days when you wish you could just
curl into a fetal position and suck your thumb instead of having to stand up and talk for an hour to a room full of
young people who are looking at you, or at least should be looking at you. Sometimes in the nitty-gritty of the
syllabus, the announcements about exams and homework, the clearing of the last class's doubts, you forget about the
current that emerges from your body and flows out into the class. You forget what you mean to them.

It's wise to step back occasionally and remember what your students mean to you, and you to them. Long after the
details of any homework assignment or midterm exam have left our minds, these relationships remain.

October 16, 2012 4:45 PM

The Parable of the OO Programming Student

As The Master was setting out on a journey, a young man ran up, knelt down before him, and asked him, "Good teacher,
what must I do to inherit the eternal bliss of OO?"

The Master answered him, "Why do you call me good? No OO programmer is good but The Creator alone.

"You know the commandments: "'An object should have only a single responsibility.'

"'Software entities should be open for extension, but closed for modification.'

"'Objects should be replaceable with instances of their subtypes without altering the correctness of that
program.'

"'Tell, don't ask.'

"'You shall not indulge in primitive obsession.'

"'All state is private.'"

The young man replied and said to Him, "Teacher, all of these I have observed from my youth when first I learned to
program."

The Master, looking at him, loved him and said to him, "You are lacking in one thing. Go, surrender all primitive
types, and renounce all control structures. Write all code as messages passed between encapsulated objects, with extreme
late-binding of all things. Then will you have treasure in Heaven; then come, follow me."

At that statement the young man's face fell, and he went away sad, for he possessed many data structures and
algorithms.

The Master looked around and said to his disciples, "How hard it is for those who have a wealth of procedural
programming experience to enter the kingdom of OO."

October 11, 2012 3:21 PM

Writing Advice for Me

Exclude all words that just don't add anything. This was the very best piece
of advice I read when I first started blogging. Carefully re-read posts that you have
written and try to remove all the extraneous words that add little or nothing.

This advice strikes a chord in me because I struggle to follow it, even when I am writing about it.

October 07, 2012 2:50 PM

Equality Check Patterns for Recursive Structures

I first encountered this trio of programming patterns when writing Smalltalk programs to manipulate graphs back in the
late 1980s. These days I see them most often when comparing recursive data types in language processors. Andrew Black
wrote about these patterns in the context of Smalltalk on the Squeak mailing list in the mid-2000s.

~~~~

Recursive Equality Check

Problem

You are working with a recursive data structure. In the simplest form, you might have a list or a record that can
contain lists or records as parts. In a language application, you might have a structured type that can have the same
type as one of its parts. For instance, a function type might allow a function as an argument or a function as a return
value.

You have two instances of the structure and need to compare them, say, for equality or for dominance. In the language
app, for example, you will need to verify that the type of an argument matches the type of the formal parameter on a
procedure.

Solution

Standard structural recursion works. Walk the
two structures in parallel, checking to see that they have the same values in the same positions. When one of the
positions holds values the same structure, make a recursive call to compare them.

But what if ...

~~~~

Recursive Equality Check with Identity Check

Problem

An instance of the recursive structure can contain a reference to itself as a value, either directly or through mutual
recursion. In the simplest form, this might be a dictionary that contains itself as a value in a key/vaue pair, as in
Smalltalk, where the global variable Smalltalk is the dictionary of all global variables, including
Smalltalk.

Comparing two instances now raises concerns. Two instances may be identical, or contain identical components. In such
cases, the standard recursive comparison will never terminate.

Solution

Check for identity first. Recurse only if the two values are distinct.

But what if...

~~~~

Recursive Equality Check with Cache

Problem

You have two structures that do not share any elements, but they are structurally isomorphic. For example, this can
occur in the simplest of structures, two one-element maps:

a = { :self => a }
b = { :self => b }

Now, even with an identity test up front, the recursive comparison will never terminate.

Solution

Maintain a cache of compared pairs. Before you begin to compare two objects, check to see if the pair is in the cache.
If yes, return true. Otherwise, add the pair to the cache and proceed.

This approach works even though the function has not finished comparing the two objects yet. If there turns out to be
a difference between the two, the check currently in progress will find it elsewhere and answer false. There is no need
to enter a recursive check.

~~~~

A variation of this caching technique can also be used in other situations, such as computing a hash value for a
recursive structure. If in the course of computing the hash you encounter the same structure again, assume that the value
is a suitable constant, such as 0 or 1. Hashes are only approximations anyway, so making only one pass over the structure
is usually enough. If you really need a fixpoint, then you can't take this shortcut.

October 05, 2012 4:02 PM

Ready for a Weekend

After a week in which I left the classroom one day feeling like a pretty good teacher and and another day feeling like
I'll never get this teaching thing right, I was looking for some inspiration.

While looking at a really simple blog this morning, I got to thinking about writing some code for fun this weekend,
something I don't get to do very often these days.

Then came an e-mail exchange with a former student now
thinking about computing in another field. He
has interesting thoughts about how computing can reach people doing real work in other disciplines, and how computing
itself needs to change in order to be relevant in a changing world. It was just what I needed. Some days, the student is
the teacher. Other days, it's the former student.

This all brought to mind a passage from Mark Edmondson's Why Read?:

True teachers of literature become teachers because their lives have been changed by reading. They want to offer
others the same chance to be transformed. "What we have loved, / Others will love," says Wordsworth in The
Prelude, "and we will teach them how."

That's how I feel about programming. I hope that most days my students can sense that in the classroom. It's good to
know that at least occasionally a student is transformed, and just as often I am transformed again.

October 02, 2012 4:14 PM

The Pareto Principle and Programming Purity

After talking about the advantages of making the changeable aspects of the system as declarative as possible, William Payne writes:

Having done a bit of Prolog programming in the dim and distant past, my intuition is that trying to make everything
declarative is a mistake; one ends up tying oneself into knots. The mental gymnastics simply are not worth it. However,
splitting the program into declarative-and-non-declarative parts seems reasonable.

This is an application of the Pareto Principle to
programming, in the form of the purity of style. The Pareto Principle says that, "for many events, roughly 80% of the
effects come from 20% of the causes".

When I was first learning functional programming in Lisp as an AI researcher, a more experienced researcher told me
that about 90% of a big system could be purely functional. The remaining 10% should include all side-effecting
operations, cordoned off from the rest of the app into its own abstraction layer. Since that time, I've heard 85-15 used
as a reasonable split for big Scheme programs.

The lesson is: don't kill yourself trying to be 100%. As Payne says, the mental gymnastics simply are not worth it.
You'll end up with code that easier to understand, maintain, and modify if you allow yourself a little impurity, in
small, controlled doses.

October 01, 2012 7:40 AM

StrangeLoop 9: This and That

Every conference leaves me with unattached ideas floating around after I write up all my entries. StrangeLoop was no
different. Were I master of Twitter, one who live-posted throughout the conference, many of this might have been
masterful tweets. Instead, they are bullets in a truly miscellaneous blog entry.

~~~~

The conference was at the Peabody Opera House (right), an 80-year-old
landmark in downtown St. Louis. It shares a large city block with the ScottTrade Center, home of the NHL Blues, and a
large parking garage ideally positioned for a conference goer staying elsewhere. The main hall was perfect for plenary
sessions, and four side rooms fit the parallel talks nicely.

~~~~

When I arrived at 8:30 AM on Monday, the morning refreshment table contained, in addition to the perfunctory coffee,
Diet Mountain Dew in handy 12-ounce bottles. Soda was available all day. This made me happy.

Sadly, the kitchen ran out of Diet Dew before Tuesday morning. Such is life. I still applaud the conference for
meeting the preferences of its non-coffee drinkers.

~~~~

During the Akka
talk, I saw some code on a slide that made me mutter Ack!
under my breath. That made me chuckle.

~~~~

"Man, there are a lot of Macs and iPads in this room."
-- me, at every conference session

~~~~

On Monday, I saw @fogus across the room in his Manfred von Thun jersey. I bow to you, sir. Joy is one of my
favorites.

After seeing @fogus's jersey tweet, I actually
ordered one for
myself. Unfortunately, it didn't arrive in time for the conference. A nice coincidence: Robert Floyd spent most of his career at Stanford, whose mascot is...
the Cardinal. (The color, not the bird.)

~~~~

During Matthew
Flatt's talk, I couldn't help but think Alan Kay would be proud. This is programming taken to the extreme. Kay always
said that Smalltalk didn't need an operating system; just hook those primitives directly to the underlying metal. Racket
might be able to serve as its own OS, too.

~~~~

I skipped a few talks. During lunch each day, I went outside to walk. That's good for my knee as well as my head. Then
I skipped one talk that I wanted to see at the end of each day, so that I could hit the exercise bike and pool. The web
will surely provide me reports of both ( The
Database as a Value and The State of
JavaScript ). Sometimes, fresh air and exercise are worth the sacrifice.

~~~~

I turned my laptop off for the last two talks of the conference that I attended. I don't think that the result was
being able to think more or better, but I definitely did thought differently. Global connections seemed to
surface more quickly, whereas typing notes seemed to keep me focused on local connections.

~~~~

Wednesday morning, as I hit the road for home, I ran into rush hour traffic driving toward downtown St. Louis. It took
us 41 minutes to travel 12 miles. Love St. Louis and this conference as much as I do, I was glad to be heading home to a
less crowded place.

~~~~

Even though I took walks at lunch, I was able to sneak into the lunch talks late. Tuesday's talk on Plato
(OOP) and Aristotle (FP) brought a wistful smile. I spent a couple of years in grad school drawing inspiration for
our lab's approach to knowledge-based systems from the pragmatists, in contrast to the traditional logical views of much
of the AI world.

That talk contained two of my favorite sentences from the conference:

Computer scientists are applied metaphysicists.

And:

We have the most exciting job in the history of philosophy.

Indeed. We can encode, implement, and experiment with every model of the world we create. It is good to be the
king.

This seems like a nice way to close my StrangeLoop posts for now. Now, back to work.