July 21, 2014 10:52 AM

Wesley's Quoted Quote

My recent post Burn All Your Sermons was triggered by a quote taken out of context. Theologian John Wesley did not say:

Once in seven years I burn all my sermons...

He said:

"Once in seven years I burn all my sermons..."

Those "" make all the difference. Wesley wasn't saying that he himself burns all his sermons every seven years; he was talking about the practice doing so. Imagine the assistant of Wesley who, upon seeing this passage in the theologian's diary, burned all of Wesley's old sermons in an effort to ingratiate himself with the boss, only later to find out that Wesley very much intended to use them again. Fiery furnace, indeed.

This sort of indirection isn't important only for human communication. It is a key idea in computing. I wrote a blog post last year about such quotations and how this distinction is an important element in Jon Udell's notion of "thinking like the web". Thinking like the web isn't always foreign to the way most of us already think and work; sometimes it simply emphasizes a particular human practice that until now has been less common.

Studying a little computer science can help, though. Programmers have multiple ways of speaking indirectly about an action such as "burn all the sermons". In Scheme, I might express the program to burn all the sermons in a collection as:

(burn sermons)

We can quote this program, in much the same way that the "" above do, as:

'(burn sermons)

This is actually shorthand for (quote (burn sermons)). The result is a piece of data, much like Wesley's quotation of another person's utterance, that we can manipulate a variety of ways.

This sort of quotation trades on the distinction between data and process. In a post a few years back, I talked a bit about how this distinction is only a matter of perspective, that at a higher level data and program are two sides of the same coin.

However, we can also "quote" our sermon-burning program in a way that stays on the side of process. Consider this program:

(lambda () (burn sermons))

The result is a program that, when executed, will execute the sermon-burning program. Like the data version of the quote, it turns the original statement into something that we can talk about, pass around as a value, and manipulate in a variety of ways. But it does so by creating another program.

This technique, quite simple at its heart, plays a helpful role in the way many of computer language processors work.

Both techniques insert a level of indirection between a piece of advice -- burn all your sermons -- and its execution. That is a crucial distinction when we want to talk about an idea without asserting the idea's truth at that moment. John Wesley knew that, and so should we.


Posted by Eugene Wallingford | Permalink | Categories: Computing

July 17, 2014 10:00 AM

A New Commandment

... I give unto you:

Our first reaction to any comrade, any other person passionate about and interested in building things with computers, any human crazy and masochistic enough to try to expand the capabilities of these absurd machines, should be empathy and love.

Courtesy of Britt Butler.

I hope to impart such empathy and love to my intro students this fall. Love to program, and be part of a community that loves and learns together.


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

July 16, 2014 2:11 PM

Burn All Your Sermons

Marketers and bridge players have their Rules of Seven. Teachers and preachers might, too, if they believe this old saw:

Once in seven years I burn all my sermons; for it is a shame if I cannot write better sermons now than I did seven years ago.

I don't have many courses in which I lecture uninterrupted for long periods of time. Most of my courses are a mixture of short lectures, student exercises, and other activities that explore or build upon whatever we are studying. Even when I have a set of materials I really like, which have been successful for me and my students in the past, I am forever reinventing them, tweaking and improving as we move through the course. This is in the same spirit as the rule of seven: surely I can make something better since the last time I taught the course.

Having a complete set of materials for a course to start from can be a great comfort. It can also be a straitjacket. The high-level structure of a course design limits how we think about the essential goals and topics of the course. The low-level structure generally optimizes for specific transitions and connections, which limits how easily we can swap in new examples and exercises.

Even as an inveterate tinkerer, I occasionally desire to break out of the straitjacket of old material and make a fresh start. Burn it all and start over. Freedom! What I need to remember will come back to me.

The adage quoted above tells us to do this regularly even if we don't feel the urge. The world changes around us. Our understanding grows. Our skills as a writer and storyteller grow. We can do better.

Of course, starting over requires time. It's a lot quicker to prep a course by pulling a prepped course out of an old directory of courses and cleaning it up around the edges. When I decide to redesign a course from bottom up, I usually have to set aside part of a summer to allow for long hours writing from scratch. This is a cost you have to take into account any time you create a new course.

Being in computer science makes it easier to force ourselves to start from scratch. While many of the principles of CS remain the same across decades, the practices and details of the discipline change all the time. And whatever we want to say about timeless principles, the undergrads in my courses care deeply about having some currency when they graduate.

In Fall 2006, I taught our intro course. The course used Java, which was the first language in our curriculum at that time. Before that, the last time I had taught the course, our first language was Pascal. I had to teach an entirely new course, even though many of the principles of programming I wanted to teach were the same.

I'm teaching our intro course again this fall for the first time since 2006. Python is the language of choice now. I suppose I could dress my old Java course in a Python suit, but that would not serve my students well. It also wouldn't do justice to the important ideas of the course, or Python. Add to this that I am a different -- and I hope better -- teacher and programmer now than I was eight years ago, and I have all the reasons I need to design a new course.

So, I am getting busy. Burn all the sermons.

Of course, we should approach the seven-year advice with some caution. The above passage is often attributed to theologian John Wesley. And indeed he did write it. However, as is so often the case, it has been taken out of context. This is what Wesley actually wrote in his journal:

Tuesday, September 1.--I went to Tiverton. I was musing here on what I heard a good man say long since--"Once in seven years I burn all my sermons; for it is a shame if I cannot write better sermons now than I could seven years ago." Whatever others can do, I really cannot. I cannot write a better sermon on the Good Steward than I did seven years ago; I cannot write a better on the Great Assize than I did twenty years ago; I cannot write a better on the Use of Money, than I did nearly thirty years ago; nay, I know not that I can write a better on the Circumcision of the Heart than I did five-and-forty years ago. Perhaps, indeed, I may have read five or six hundred books more than I had then, and may know a little more history, or natural philosophy, than I did; but I am not sensible that this has made any essential addition to my knowledge in divinity. Forty years ago I knew and preached every Christian doctrine which I preach now.

Note that Wesley attributes the passage to someone else -- and then proceeds to deny its validity in his own preaching! We may choose to adopt the Rule of Seven in our teaching, but we cannot do so with Wesley as our prophet.

I'll stick with my longstanding practice of building on proven material when that seems best, and starting from scratch whenever the freedom to tell a new story outweighs the value of what has worked for me and my students in the past.


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

July 15, 2014 3:19 PM

Ambiguous Questions and Wrong Answers

Pianist James Boyk recently shared a story about mathematician Andrew Gleason with me. Boyk had studied a bit with Gleason, who was known for his work in cryptography and in helping to solve Hilbert's fifth problem. Gleason also had a strong interest in early math education. Once, after observing first-grade math teaching for some weeks, Gleason said:

I never saw a kid give a wrong answer. I heard a lot of ambiguous or erroneous questions, but never a wrong answer.

As Boyk told me, there's a lesson in this attitude for everyone. So often in my own courses, I start to mark a student's answer as incorrect, step back, and realize that the question itself was ambiguous. The student had given a correct answer -- only to a question different than the one I had in my mind.

Not all my questions are ambiguous or erroneous, of course. Sometimes the student does give an incorrect answer. For a while now, I've been trying to retrain my mind to think in terms of incorrect answers rather than wrong answers. Yes, these words are synonyms, but their connotations differ. The meaning of "incorrect" is usually limited to the objective sense of being not in accordance with fact or standards. "wrong" has a wider meaning that also can include being immoral or dishonest. Those words seem a bit too judgmental to be applied to my students' sorting algorithms and Scheme programs.

In the case of erroneous answers, I find I'm usually more effective if I focus on the factual incorrectness of an answer. What misconception or missing piece of knowledge led the student to this conclusion? How can I help the student recognize this flaw in the reasoning and reason more accurately in the future?

That seems to be the big lesson of Gleason's comment: to keep the teacher's focus on how a student's answer is the correct answer, given what he or she knows at a given point in time. The teacher's job is to ask better questions and lead students to a better state of knowing and doing.


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

July 11, 2014 2:12 PM

Unclear on the Concept

I love the following passage from Dan Meyer. He is commenting on a survey reported here (scroll to the bottom of the page), in which math teachers were asked what the greatest limitations are on how they teach. 38.79% said, "students who are uninterested", and 23.56% said, "students who are disruptive". Says Meyer:

It's like reading a survey of firefighters in which, when asked about the greatest limitation on how they fight fires, 38.79% responded "all the fires" and 23.56% responded "being a first responder."

Students who are uninterested are part of the job. I don't know that we can make every student who walks into my classroom interested in CS. But I do know that we can teach CS in ways that lose the interest of too many students with the potential to succeed. Trust me; I've done it.

Also, let's not blame the K-12 system for creating students who are predisposed to be uninterested and to lack curiosity. It does not matter if that is true or not. My job is to teach the students in my classroom, not some mythical students somewhere else.


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

July 10, 2014 3:08 PM

The Passing of the Postage Stamp

In this New York Times article on James Baldwin's ninetieth birthday, scholar Henry Louis Gates laments:

On one hand, he's on a U.S. postage stamp; on the other hand, he's not in the Common Core.

I'm not qualified to comment on Baldwin and his place in the Common Core. In the last few months, I read several articles about and including Baldwin, and from those I have come to appreciate better his role in twentieth-century literature. But I also empathize with anyone trying to create a list of things that every American should learn in school.

What struck me in Gates's comment was the reference to the postage stamp. I'm old enough to have grown up in a world where the postage stamp held a position of singular importance in our culture. It enabled communication at a distance, whether geographical or personal. Stamps were a staple of daily life.

In such a world, appearing on a stamp was an honor. It indicated a widespread acknowledgment of a person's (or organization's, or event's) cultural impact. In this sense, the Postal Service's decision to include James Baldwin on a stamp was a sign of his importance to our culture, and a way to honor his contributions to our literature.

Alas, this would have been a much more significant and visible honor in the 1980s or even the 1990s. In the span of the last decade or so, the postage stamp has gone from relevant and essential to archaic.

When I was a boy, I collected stamps. It was a fun hobby. I still have my collection, even if it's many years out of date now. Back then, stamp collecting was a popular activity with a vibrant community of hobbyists. For all I know, that's still true. There's certainly still a vibrant market for some stamps!

But these days, whenever I use a new stamp, I feel as if I'm holding an anachronism in my hands. Computing technology played a central role in the obsolescence of the stamp, at least for personal and social communication.

Sometimes people say that we in CS need to a better job helping potential majors see the ways in which our discipline can be used to effect change in the world. We never have to look far to find examples. If a young person wants to be able to participate in how our culture changes in the future, they can hardly do better than to know a little computer science.


Posted by Eugene Wallingford | Permalink | Categories: Computing, General, Personal

July 09, 2014 12:35 PM

Why I Blog, Ten Years On

A blog can be many things.

It can an essay, a place to work out what I think, in the act of writing.

It can be a lecture, a place to teach something, however big or small, in my own way.

It can be memoir, a place to tell stories about my life, maybe with a connection to someone else's story.

It can be a book review or a conference review, a place to tell others about something I've read or seen that they might like, too. Or not.

It can be an open letter, a place to share news, good or bad, in a broadcast that reaches many.

It can be a call for help, a request for help from anyone who receives the message and has the time and energy to respond.

It can be a riff on someone else's post. I'm not a jazz musician, but I like to quote the melodies in other people's writing. Some blog posts are my solos.

It can be a place to make connections, to think about how things are similar and different, and maybe learn something in the process.

A blog is all of these, and more.

A blog can also be a time machine. In this mode, I am the reader. My blog reminds me who I was at another time.

This effect often begins with a practical question. When I taught agile software development this summer, I looked back to when I taught it last. What had I learned then but forgotten since? How might I do a better job this time around?

When I visit blog posts from the past, though, something else can happen. I sometimes find myself reading on. The words mesmerize me and pull me forward on the page, but back in time. It is not that the words are so good that I can't stop reading. It's that they remind me who I was back then. A different person wrote those words. A different person, yet me. It's quite a feeling.

A blog can combine any number of writing forms. I am not equally good writing in all of these forms, or even passably good in any of them. But they are me. Dave Winer has long said that a blog is the unedited voice of a person. This blog is the unedited voice of me.

When I wrote my first blog post ten years ago today, I wasn't sure if anyone wanted to hear my voice. Over the years, I've had the good fortune to interact with many readers, so I know someone is listening. That still amazes me. I'm glad that something you read here is worth the visit.

Back in those early days, I wondered if it even mattered whether anyone else would read. The blog as essay and as time machine are valuable enough on their own to make writing worth the effort to me. But I'll be honest: it helps a lot knowing that other people are reading. Even when you don't send comments by e-mail, I know you are there. Thank you for your time.

I don't write as often as I did in the beginning. But I still have things to say, so I'll keep writing.


Posted by Eugene Wallingford | Permalink | Categories: General, Personal

July 03, 2014 2:13 PM

Agile Moments: Conspicuous Progress and Partial Value

Dorian Taylor, in Toward a Theory of Design as Computation:

You can scarcely compress the time it takes to do good design. The best you can do is arrange the process so that progress is conspicuous and the partially-completed result has its own intrinsic value.

Taylor's piece is about an idea much bigger than simply software methodology, but this passage leapt off the page at me. It seems to embody two of the highest goals of the various agile approaches to making software: progress that is conspicuous and partial results that have intrinsic value to the user.

If you like ambition attempts to create a philosophy of design, check out the whole essay. Taylor connects several disparate sources:

  • Edwin Hutchins and Cognition in the Wild,
  • Donald Norman and Things That Make Us Smart, and
  • Douglas Hofstadter and Gödel, Escher, Bach
with the philosophy of Christopher Alexander, in particular Notes on the Synthesis of Form and The Nature of Order. Ambitious it is.

Posted by Eugene Wallingford | Permalink | Categories: Computing, Software Development

July 02, 2014 4:31 PM

My Jacket Blurb for "Exercises in Programming Style"

On Monday, my copy of Crista Lopes's new book, Exercises in Programming Style, arrived. After blogging about the book last year, Crista asked me to review some early chapters. After I did that, the publisher graciously offered me a courtesy copy. I'm glad it did! The book goes well beyond Crista's talk at StrangeLoop last fall, with thirty three styles grouped loosely into nine categories. Each chapter includes historical notes and a reading list for going deeper. Readers of this blog know that I often like to go deeper.

I haven't had a chance to study any of the chapters deeply yet, so I don't have a detailed review. For now, let me share the blurb I wrote for the back cover. It gives a sense of why I was so excited by the chapters I reviewed last summer and by Crista's talk last fall:

It is difficult to appreciate a programming style until you see it in action. Cristina's book does something amazing: it shows us dozens of styles in action on the same program. The program itself is simple. The result, though, is a deeper understanding of how thinking differently about a problem gives rise to very different programs. This book not only introduced me to several new styles of thinking; it also taught me something new about the styles I already know well and use every day.

The best way to appreciate a style is to use it yourself. I think Crista's book opens the door for many programmers to do just that with many styles most of us don't use very often.

As for the blurb itself: it sounds a little stilted as I read it now, but I stand by the sentiment. It is very cool to see my blurb and name along side blurbs from James Noble and Grady Booch, two people whose work I respect so much. Very cool. Leave it to James to sum up his thoughts in a sentence!

While you are waiting for your copy of Crista's book to arrive, check out her recent blog entry on the evolution of CS papers in publication over the last 50+ years. It presents a lot of great information, with some nice images of pages from a few classics. It's worth a read.


Posted by Eugene Wallingford | Permalink | Categories: Computing, Software Development

June 30, 2014 4:29 PM

Sometimes, The Truth Is Boring

MacKenzie Bezos, in her Amazon review of The Everything Store: Jeff Bezos and the Age of Amazon, writes:

One of the biggest challenges in non-fiction writing is the risk that a truthfully balanced narration of the facts will be boring, and this presents an author with some difficult choices.

Teachers face these choices all the time, too. Whenever I teach a course, I want to help my students be excited about the ideas and tools that we are studying. I like to tell stories that entertain as well as illuminate. But not every moment of learning a new programming language, or a new programming style, or a set of mathematical ideas, is going to have my students on the edges of their seats.

The best I can hope for is that the exciting parts of the course will give us the momentum we need to make it through the more boring parts. A big part of education is learning that the best parts of a course are the motivation for doing the hard work that gets us to the next exciting idea.


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