October 21, 2018 9:53 AM
Find the Hard Work You’re Willing to Do
I like this passage from John Urschel Goes Pro,
about the former NFL player who is pursuing a Ph.D. in math:
The world thinks mathematicians are people for whom math is easy. That’s wrong. Sure, some kids, like Urschel, have
little trouble with school math. But everyone who starts down the road to creating really new mathematics finds out
what Urschel did: It’s a struggle. A prickly, sometimes lonely struggle whose rewards are uncertain and a long time
coming. Mathematicians are the people who love that struggle.
It’s cliché to tell kids to “find their passion”. That always seems to me like an awful lot of pressure to put
on young adults, let alone teenagers. I meet with potential CS majors frequently, both college students and high school
students. Most haven’t found their passion yet, and as a result many wonder if there is something wrong with them. I do
my my best to assure them that, no, there is nothing wrong with them. It’s an unreasonable expectation placed on them by
a world that, usually with good intentions, is trying to encourage them.
I don’t think there is anything I’d rather be than a computer scientist, but I did not walk a straight path to being
one. Some choices early on were easy: I like biology as a body of knowledge, but I never liked studying biology.
That seemed a decent sign that maybe biology wasn’t for me. (High-school me didn’t understand that there might be a
difference between school biology and being a biologist…) But other choices took time and a little self-awareness.
From the time I was eight years old or so, I wanted to be an architect. I read about architecture; I sent away for
professional materials from the American Institute of Architects; I took courses in architectural drafting at my high
school. (There was an unexpected benefit to taking those courses: I got to meet a lot of people were not part of my usual
academic crowd.) Then I went off to college to study architecture… and found that, while I liked many things about the
field, I didn’t really like to do the grunt work that is part of the architecture student’s life, and when the assigned
projects got more challenging, I didn’t really enjoy working on them.
But I had enjoyed working on the hard projects I’d encountered in my programing class back in high school. They were
challenges I wanted to overcome. I changed my major and dove into college CS courses, which were full of hard problems —
but hard problems that I wanted to solve. I didn’t mind being frustrated for an entire semester one year, working in
assembly language and JCL, because I wanted to solve the puzzles.
Maybe this is what people mean when they tell us to “find our passion”, but that phrase seems pretty abstract to me.
Maybe instead we should encourage people to find the hard problems they like to work on. Which problems do you want to
keep working on, even when they turn out to be harder than you expected? Which kinds of frustration do you enjoy, or at
least are willing to endure while you figure things out? Answers to these very practical questions might help you find a
place where you can build an interesting and rewarding life.
I realize that “Find your passion” makes for a more compelling motivational poster than “What hard problems do you
enjoy working on?” (and even that’s a lot better than “What kind of pain are you willing to endure?”), but it might give
some people a more realistic way to approach finding their life’s work.
October 05, 2018 3:39 PM
Why Patterns Failed and Why You Should Care
Beds are useful. I enjoyed my bed at the hotel last night. But you won’t find a pattern called bed in A Pattern
Language, and that’s because we don’t have a problem with beds. Beds are solved. What we have a problem with is
building with beds. And that’s why, if you look in A Pattern Language, you’ll find there are a number of
patterns that involve beds.
Now, the analogy I want to make is, basically, the design patterns in the book Design Patterns are at the
same level as the building blocks in the book A Pattern Language. So Bridge, which is one of the design
patterns, is the same kind of thing as column. You can call it a pattern, but it’s not really a pattern that gets at
the root problem we’re trying to solve. And if Alexander had written a book that had a pattern called Bed and another
one called Chair, I imagine that that book would have failed and not inspired all of the people that the actual book
did inspire. So that, I claim, is why patterns failed.
Those two nearly-sequential paragraphs are from Patterns Failed. Why? Should We
Care?, a talk Brian Marick gave at Deconstruct 2017. It’s a good
talk. Marick’s provocative claim that, as an idea, software patterns failed is various degrees of true and false
depending on how you define ‘patterns’ and ‘failed’. It’s hard to declare the idea an absolute failure, because a lot of
software developers and UI designers use patterns to good effect as a part of their work every day. But I agree with
Brian that software patterns failed to live up to their promise or to the goals of the programmers who worked so hard to
introduce Christopher Alexander’s work to the software community. I agree, too, that the software pattern community’s
inability to document and share patterns at the granularity that made Alexander’s patterns so irresistible is a big part
I was a second- or third-generation member of the patterns community, joining in after Design Patterns had
been published and, like Marick, I worked mostly on the periphery. Early on I wrote patterns that related to my
knowledge-based systems work. Much of my pattern-writing, though, was at the level of elementary patterns, the patterns
that novice programmers learn when they are first learning to program. Even at that level, the most useful patterns often
were ones that operated up one level from the building blocks that novices knew.
Consider Guarded Linear
Search, from the Loop Patterns paper that Owen Astrachan and I workshopped at PLoP 1998. It helps beginners learn how to arrange a loop and an if
statement in a way that achieves a goal. Students in my beginning courses often commented how patterns like this one
helped them write programs because, while they understood if statements and for statements and
while statements, they didn’t always know what to do with them when facing a programming task. At that
most elementary level, the Guarded Linear Search pattern was a pleasing — and useful — whole.
That said, there aren’t many “solved problems” for beginners, so we often wrote patterns that dropped down to the
level of building blocks simply to help novices learn basic constructs. Some of the Loop Patterns paper does
that, as does Joe Bergin’s Patterns for Selection.
But work in the elementary patterns community would have been much more valuable, and potentially had more effect, if we
had thought harder about how to find and document patterns at the level of Alexander’s patterns.
Perhaps the patterns sub-community in which I’ve worked in which best achieved its goals was the pedagogical patterns community. These are not software patterns but rather
patterns of teaching techniques. They document solutions to problems that teachers face every day. I think I’d be willing
to argue that the primary source of pedagogical patterns’ effectiveness is that these solutions combine more primitive
building blocks (delivery techniques, feedback techniques, interaction techniques) in a way that make learning and
instruction both more effective and more fun. As a result, they captured a lot of teachers’ interest.
I think that Marick’s diagnosis also points out the error in a common criticism of software patterns. Over the years,
we often heard folks say that software patterns existed only because people used horrible languages like C++ and Java. In
a more powerful language, any purported pattern would be implemented as a language primitive or could be made a
primitive by writing a macro. But this misses the point of Alexander’s insight. The problem in software development isn’t
with inheritance and message passing and loops, just as the problem in architecture isn’t with beds and windows and
space. It’s with finding ways to arrange these building blocks in a way that’s comfortable and nice and, to use
Alexander’s term, “life-giving”. That challenge exists in all programming languages.
Finally, you probably won’t be surprised to learn that I agree with Marick that we should all care that software
patterns failed to live up to their promise. Making software is fun, but it’s also challenging. Alexander’s idea of a
pattern language is one way that we might help programmers do their jobs better, enjoy their jobs more, and produce
software that is both functional and habitable. The first pass was a worthy effort, and a second pass, informed by the
lessons of the first, might get us closer to the goal.
Thanks to Brian for giving this talk and to the folks at Deconstruct for posting it online. Go watch it.
October 04, 2018 4:46 PM
Strange Loop 6: Index + This and That
For my convenience and yours, here are all of Strange Loop 2018 posts:
- Simon Peyton
Jones on Teaching CS in the Schools
Schmüdde and the Art of Misuse
- The Quotable
… and few parting thoughts of the non-technical variety:
- All the images used in these posts are photos I took at the conference. They are licensed CC Attribution-ShareAlike 3.0 Unported.
- On Day One, Jason Dagit kept saying H.E., for “homomorphic encryption”. For a while I was confused, because my
brain kept hearing A.G.
- I left my laptop in the hotel room this year, in order to engage more with the talks and the people than with a web
browser. I’m glad I did: I enjoyed the talks more. I also took fewer and more focused notes. That made blogging easier
- I also decided not to acquire swag as greedily as usual, and I did a pretty good job of holding back… except for
this beautiful hard-bound Jane Street notebook with graphed pages:
- I left St. Louis with a lot of plastic. The Stifel Theater, the conference’s main venue, does not recycle plastic.
Like many conference goers, I went through a fair number of water and soda bottles. I hate to see all that plastic go
into the landfill and, having driven down, I did not have to contribute. Twice a day, I took whatever bottles I had
emptied, and whatever other bottles I found lying around, back to my car and through them in the trunk. When I got
home, they went straight into the recycling bin. Yet another advantage to driving over flying.
I think that’s all from Strange Loop 2018. It was fun.
October 02, 2018 4:04 PM
Strange Loop 5: Day Two
Friday was a long day, but a good one. The talks I saw were a bit more diverse than on Day One: a couple on
language design (though even one of those covered a lot more ground than that), one on AI, one on organizations and
work-life, and one on theory:
• “All the Languages Together”, by Amal Ahmed, discussed a
problem that occurs in multi-language systems: when code written in one language invalidates the guarantees made by code
written in the other. Most languages are not designed with this sort of interoperability baked in, and their FFI escape
hatches make anything possible within foreign code. As a potential solution, Ahmed offered principled escape hatches
designed with specific language features in mind. The proposed technique seems like it could be a lot of work, but the
research is in its early stages, so we will learn more as she and her students implement the idea.
This talk is yet another example of how so many of our challenges in software engineering are a result of programming
language design. It’s good to see more language designers taking issues like these seriously, but we have a long way to
• I really liked Ashley Williams‘s talk on on the evolution of
morality, and cognitive science as she reviewed how two different language communities incorporated asynchronous
primitives into their languages. Programming languages are designed, to be sure, but they are also the result of
“contingent turns of history” (a lá Foucault). Even though this turned out to be more of a talk about the Rust
community than I had expected, I enjoyed every minute. Besides, how can you not like a speaker who says, “Yes, sometimes
I’ll dress up as a crab to teach.”?
(My students should not expect a change in my wardrobe any time soon…)
• I also enjoyed “For AI, by AI”, by Connor Walsh. The talk’s
subtitle, “Freedom & Evolution of the Algopoetic Avant-Garde”, was a bit disorienting, as was its cold open, but the
off-kilter structure of the talk was easy enough to discern once Walsh got going: first, a historical review of
humans making computers write poetry, followed by a look at something I didn’t know existed… a community of
algorithmic poets — programs — that write, review, and curate poetry without human intervention. It’s a new
thing, of Walsh’s creation, that looks pretty cool to someone who became drunk on the promise of AI many years ago.
I saw two other talks the second day:
- the after-lunch address by Philip Wadler, “Categories for the Working Hacker”, which I wrote about separately
- Rachel Krol’s Some Things May
Never Get Fixed, about how organizations work and how developers can thrive despite how they work
I wish I had more to say about the last talk but, with commitments at home, the long drive beckoned. So, I departed
early, sadly, hopped in my car, headed west, and joined the mass exodus that is St. Louis traffic on a Friday afternoon.
After getting past the main crush, I was able to relax a bit with the rest of Zen and the Art of Motorcycle
Even a short day at Strange Loop is a big win. This was the tenth Strange Loop, and I think I’ve been to five, or at
least that’s what my blog seems to tell me. It is awesome to have a conference like this in Middle America. We who live
here benefit from the opportunities it affords us, and maybe folks in the rest of the world get a chance to see that not
all great computing ideas and technology happen on the coasts of the US.
When is Strange Loop 2019?
October 01, 2018 7:12 PM
Strange Loop 4: The Quotable Wadler
Philip Wadler is a rockstar to the Strange Loop crowd. His 2015 talk on propositions as types introduced
not a few developers to one of computer science’s great unities. This year, he returned to add a third idea to what is
really a triumvirate: categories. With a little help from his audience, he showed that category theory has elements which
correspond directly to …
- logical ‘and’, which models the record (or tuple, or pair) data type
- logical ‘or’, which models the union (or variant record) data type
- a map, which models the function data type
What’s more, the product/sum dual models De Morgan’s
laws, but with more structure, which enables it to model sets beyond the booleans!
Wadler is an entertaining teacher; I recommend the video of his talk! But he is also as quotable as any CS prof I’ve
encountered in a long while. Here is a smattering of his great lines from “Categories for the Working Hacker”:
If you can use math to do something, do it. It will make your life better.
That’s the great thing about math. It lets you see something obvious after only thirty or forty years.
Pick your favorite algebra. If you don’t have one, get one.
Let’s do that in Java. That’s what you should always do when you learn a new idea: do it in Java.
That’s what category theory is really about: avoiding traffic jams.
Sums are the secret origin of folds.
If you don’t understand this, I don’t mind, because it’s Java.
While watching the presentation, I created a one-liner of my own: Surprise! If you do something that matches
exactly what Haskell does, Haskell code will be much shorter than Java code.
This was a very good talk; I enjoyed it quite a bit. However, I also left the room with a couple of nagging questions.
The talk was titled “Categories for the Working Hacker”, and it did a nice job of presenting some basic ideas from
category theory in a way that most any developer could understand, even one without much background in math. But… How
does this knowledge make one a better hacker? Armed with this new, entertaining knowledge, what are software developers
able to do that they couldn’t do before?
I have my own ideas for answers to these questions, but I would love to hear Wadler’s take.