TITLE: StrangeLoop: Exercises in Programming Style
AUTHOR: Eugene Wallingford
DATE: October 07, 2013 12:07 PM
[My notes on StrangeLoop 2013:
Table of Contents]
I had been looking forward to Crista Lopes's StrangeLoop talk
so I made sure I was in the room well before the scheduled
time. I even had a copy of the trigger book in my bag.
Crista opened with something that CS instructors have learned
the hard way: Teaching programming style is difficult and
takes a lot of time. As a result, it's often not done at all
in our courses. But so many of our graduates go into software
development for the careers, where they come into contact with
many different styles. How can they understand them -- well,
quickly, or at all?
To many people, style is merely the appearance of code on the
screen or printed. But it's not. It's more, and something
entirely different. Style is a constraint. Lopes
used images of a few stylistic paintings to illustrate the
idea. If an artist limits herself to
how can she express important ideas? How does the style limit
the message, or enhance it?
But we know this is true of programming as well. The idea has
been a theme in my teaching for many years. I occasionally
write about the role of constraints in programming here,
Patterns as a Source of Freedom,
a few programming challenges,
a polymorphism challenge
that I've run as a workshop.
Lopes pointed to a more universal example, though: the
The Elements of Programming Style.
Drawing on this book and other work in software, she said that
programming style ...
For me, the last bullet ties back most directly to idea of style
as constraint. A language makes some things easier to express
than others. It can also make some things harder to express.
There is a spectrum, of course. For example, some OO languages
make it easy to create and use objects; others make it hard to
do anything else! But the language is an enabler and enforcer
of style. It is a proxy for style as a constraint on the
Back to the talk. Lopes asked, Why is it so important that we
understand programming style? First, a style provides the
reader with a frame of reference and a vocabulary. Knowing
different styles makes us a more effective consumers of
code. Second, one style can be more appropriate for a given
problem or context than another style. So, knowing different
styles makes us a more effective producers of code.
(Lopes did not use the producer-consumer distinction in the
talk, but it seems to me a nice way to crystallize her idea.)
The, Lopes said, I came across Raymond Queneau's playful little
book, "Exercises in Style". Queneau constrains himself in
many interesting ways while telling essentially the same story.
Hmm... We could apply the same idea to programming! Let's do
Lopes picked a well-known problem, the common word problem
famously solved in
a Programming Pearls column
more than twenty-five years. This is a fitting choice, because
Jon Bentley included in that column a critique of Knuth's
program by Doug McIlroy, who considered both engineering
concerns and program style in his critique.
The problem is straightforward: identify and print the k
most common terms that occur in a given text document, in
decreasing order. For the rest of the talk, Lopes presented
several programs that solve the problem, each written in a
different style, showing code and highlighting its shape and
Python was her language of choice for the examples. She was
looking for a language that many readers would be able to
follow and understand, and Python has the feel of pseudo-code
about it. (I tell my students that it is the Pascal of their
time, though I may as well be speaking of hieroglyphics.) Of
course, Python has strengths and weaknesses that affect its
fit for some styles. This is an unavoidable complication for
Also, Lopes did not give formal names to the styles she
demonstrated. Apparently, at previous versions of this talk,
audience members had wanted to argue over the names more than
the styles themselves! Vowing not to make that mistake again,
she numbered her examples for this talk.
- is a way to express tasks
- exists at all scales
- recurs at multiple scales
- is codified in programming language
That's what programmers do when they don't have good names.
In lieu of names, she asked the crowd to live-tweet to her
what they thought each style is or should be called. She
eventually did give each style a fun, informal name. (CS
textbooks might be more evocative if we used her names instead
of the formal ones.)
I noted eight examples shown by Lopes in the talk, though
there may have been more:
Lopes said that she hopes to produce solutions using a total
of thirty or so styles. She asked the audience for help with
one in particular: logic programming. She said that
she is not a native speaker of that style, and Python does not
come with a logic engine built-in to make writing a solution
Someone from the audience suggested she consider yet another
style: using a domain-specific language. That would
be fun, though perhaps tough to roll from scratch in Python.
By that time, my own brain was spinning away, thinking about
writing a solution to the problem in
using a concatenative style.
Sometimes, it's surprising just how many programming styles
and meaningful variations people have created. The human mind
is an amazing thing.
The talk was, I think, a fun one for the audience. Lopes is
writing a book based on the idea. I had a chance to review an
early draft, and now I'm looking forward to the finished product.
I'm sure I'll learn something new from it.
- monolithic procedural code -- "brain dump"
- a Unix-style pipeline -- "code golf"
- procedural decomposition with a sequential main -- "cook
- the same, only with functions and composition -- "Willy
- functional decomposition, with a continuation parameter
- modules containing multiple functions -- "the kingdom of
- relational style -- (didn't catch this one)
- functional with decomposition and reduction -- "multiplexer"