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.

Posted by Eugene Wallingford | Permalink | Categories: Patterns, Software Development, Teaching and Learning

October 24, 2012 11:38 AM

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

Rob Pike in The Set-Up:

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.

Ah, the memories of grad school, WYSE terminals, and VT-100 emulation.

The advent of ubiquitous networking is making it possible for us to return to the days of dumb terminals. Is that where we want to live?

Pike's vision notwithstanding: I still carry a computer, both for state and processor. I access networked computers frequently. I do not yet carry a phone. I remain happy.

Posted by Eugene Wallingford | Permalink | Categories: Computing

October 19, 2012 3:08 PM

Computer Programming, Education Reform, and Changing Our Schools

Seymour Papert

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 logo cat

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.


IMAGE 1: Seymour Papert at the OLPC offices in Cambridge, Massachusetts, in 2006. Source: Wikimedia Commons License: Creative Commons Attribution-Share Alike 2.0.

IMAGE 2: The Scratch logo. Source: Wikimedia Commons License: Creative Commons Attribution-Share Alike 2.0.

Posted by Eugene Wallingford | Permalink | Categories: Computing, Teaching and Learning

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.

(And, as important as these relationships are, they are not the most important relationship in the classroom.)

Posted by Eugene Wallingford | Permalink | Categories: Teaching and Learning

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."

... with apologies to The Gospel of Mark.

Posted by Eugene Wallingford | Permalink | Categories: Software Development, Teaching and Learning

October 12, 2012 10:37 AM

Make Let, Not Var

I don't blog images for their own sake often, but this mash-up makes me happy:

a parody of Lennon and Ono's 'Make Love, Not War' image

Even as I enjoy teaching OO programming this semester, this reminds me that I'll enjoy teaching functional programming in the spring.

This came to me via a tweet. If you know the source, I'd love to hear from you.

Posted by Eugene Wallingford | Permalink | Categories: Computing

October 11, 2012 3:21 PM

Writing Advice for Me

I'm not a big fan of Top Ten lists on the web, unless they come from fellow Hoosier David Letterman. But I do like Number 9 on this list of writing tips:

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.

Posted by Eugene Wallingford | Permalink | Categories: General

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


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.


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


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.


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

But what if...


Recursive Equality Check with Cache


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.


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.

Ruby hashes handle all three of these problems correctly:

    a = { :first  => :int,
          :second => { :first  => :int, :second => :int } }
    b = { :second => { :second => :int, :first  => :int },
          :first  => :int, }

a == b # --> true
c = { :first => c } a = { :first => :int, :second => { :first => c, :second => :int } } b = { :first => :int, :second => { :first => c, :second => :int } }
a == b # --> true
a = { :self => a } b = { :self => b }
a == b # --> true

I don't know if either MRI Ruby or JRuby uses these patterns to implement their solutions, or if they use some other technique.

Posted by Eugene Wallingford | Permalink | Categories: Computing, Patterns

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.

Posted by Eugene Wallingford | Permalink | Categories: Teaching and Learning

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.

Posted by Eugene Wallingford | Permalink | Categories: Software Development

October 01, 2012 7:40 AM

StrangeLoop 9: This and That

the Peabody Opera House

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


the St. Louis Arch, down the street from the Opera House

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.


my StrangeLoop 2012 conference badge

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.


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.

Posted by Eugene Wallingford | Permalink | Categories: General