May 05, 2016 1:45 PM
In her 1942 book Philosophy in a New Key, philosopher Susanne Langer wrote:
A question is really an ambiguous proposition; the answer is its determination.
This sounds like something a Prolog programmer might say in a philosophical moment. Langer even understood how tough it can be to write effective Prolog queries:
The way a question is asked limits and disposes the ways in which any answer to it -- right or wrong -- may be given.
Try sticking a cut somewhere and see what happens...
It wouldn't be too surprising if a logical philosopher reminded me of Prolog, but Langer's specialties were consciousness and aesthetics. Now that I think about it, though, this connection makes sense, too.
Prolog can be a lot of fun, though logic programming always felt more limiting to me than most other styles. I've been fiddling again with Joy, a language created by a philosopher, but every so often I think I should earmark some time to revisit Prolog someday.
May 03, 2016 4:19 PM
Pair Programming is a Skill to be Learned
David Andersen offers a rather thorough list of ways that academics might adapt Google's coding practices to their research. It's a good read; check it out! I did want to comment on one small comment, because it relates to a common belief about pair programming:
But, of course, effective pair programming requires a lot of soft skills and compatible pairs. I'm not going to pretend that this solution works everywhere.
I don't pretend that pair programming works everywhere, either, or that everyone should adopt it, but I often wonder about statements like this one. Andersen seems to think that pair programming is a good thing and has helped him and members of his team's to produce high-quality code in the past. Why downplay the practice in a way he doesn't downplay other practices he recommends?
Throughout, the article encourages the use of new tools and techniques. These tools will alter the practice of his students. Some are complex enough that they will need to be taught, and practiced over some length of time, before they become an effective part of the team's workflow. To me, pair programming is another tool to be learned and practiced. It's certainly no harder than learning git...
Pair programming is a big cultural change for many programmers, and so it does require some coaching and extended practice. This isn't much different than the sort of "onboarding" that Andersen acknowledges will be necessary if he is to adopt some of Google's practices successfully in his lab upon upon his return. Pair programming takes practice and time, too, like most new skills.
I have seen the benefit of pair programming in an academic setting myself. Back when I used to teach our introductory course to freshmen, I had students pair every week in the closed lab sessions. We had thirty students in each section, but only fifteen computers in our lab. I paired students in a rotating fashion, so that over the course of fifteen weeks each student programmed with fifteen different classmates. We didn't use a full-on "pure" XP-style of pairing, but what we did was consistent with the way XP encourages pair programming.
This was a good first step for students. They got to know each other well and learned from one another. The better students often helped their partners in the way senior developers can help junior developers progress. In almost all cases, students helped each other find and fix errors. Even though later courses in the curriculum did not follow up with more pair programming, I saw benefits in later courses, in the way students interacted in the lab and in class.
I taught intro again a couple of falls ago after a long time away. Our lab has twenty-eight machines now, so I was not forced to use pair programming in my labs. I got lazy and let them work solo, with cross-talk. In the end, I regretted it. The students relied on me a lot more to help them find errors in their code, and they tended to work in the same insulated cliques throughout the semester. I don't think the group progressed as much as programmers, either, even though some individuals turned out fine.
A first-year intro lab is a very different setting than a research lab full of doctoral students. However, if freshmen can learn to pair program, I think grad students can, too.
Pair programming is more of a social change than a technical change, and that creates different issues than, say, automated testing and style checking. But it's not so different from the kind of change that capricious adherence to style guidelines or other kinds of code review impose on our individuality.
Are we computer scientists so maladjusted socially that we can't -- or can't be bothered -- to learn the new behaviors we need to program successfully in pairs? In my experience, no.
Like Andersen, I'm not advocating that anyone require pair programming in a lab. But: If you think that the benefits of pair programming exceed the cost, then I encourage you to consider having your research students or even your undergrads use it. Don't shy away because someone else thinks it can't work. Why deprive your students of the benefits?
The bottom line is this. Pair programming is a skill to be learned, like many others we teach our students.
May 02, 2016 4:30 PM
A Pawn and a Move
The state of computer chess certainly has changed since the fall of 1979, when I borrowed Mike Jeffers's Chess Challenger 7 and played it over and over and over. I was a rank novice, really just getting my start as a player, yet after a week or so I was able to celebrate my first win over the machine, at level 3. You know what they say about practice...
My mom stopped by our study room several times during that week, trying to get me to stop playing. It turns out that she and my dad had bought me a Chess Challenger 7 for Christmas, and she didn't want me to tire of my present before I had even unwrapped it. She didn't know just how not tired I would get of that computer. I wore it out.
When I graduated with my Ph.D., my parents bought me Chess Champion 2150L, branded by in the name of world champion Garry Kasparov. The 2150 in the computer's name was a rough indication that it played expert-level chess, much better than my CC7 and much better than me. I could beat it occasionally in a slow game, but in speed chess it pounded me mercilessly. I no longer had the time or inclination to play all night, every night, in an effort to get better, so it forever remained my master.
Now US champ Hikaru Nakamura and world champ Magnus Carlsen know how I feel. The days of any human defeating even the programs you can buy at Radio Shack have long passed.
Two pawns and move odds against grandmasters, and a pawn and a move odds against the best players in the world? Times have changed.
April 30, 2016 11:02 AM
Thinking About Untapped Extra Credit Opportunities
I don't usually offer extra credit assignments in my courses, but I did this semester. Students submitted their last scheduled homework early in the last week of classes: an interpreter for a small arithmetic language with local variables. There wasn't enough time left to assign another homework, but I had plenty of ideas for the next version of our interpreter. Students had just learned how to implement both functions and mutable data, so they could add functions, true variables, and sequences of expressions to the language. They could extend their REPL to support top-level definitions and state. They could add primitive data objects to the language, or boolean values and operators. If they added, booleans, they could add an if expression. If they were willing to learn some new Racket, they could load programs from a text file and evaluate them. I had plenty of ideas for them to try!
So I asked, "If I write up an optional assignment, how many of you would take a stab at some extra credit?" Approximately twenty of the twenty-five students present raised their hands.
I just downloaded the submission folder. The actual number of attempts was a complement of the number of hands raised: five. And, with only one exception, the students who tried the extra credit problems are the students who need it least. They are likely to get an A or a high B in the course anyway. The students who most need extra credit (and the extra practice) didn't attempt the extra credit.
SMH, as the kids say these days. But the more I thought about it, the more this made sense.
- College students are the most optimistic people I have ever met. Many students probably raised their hand with every intention of submitting extra credit solutions. Then the reality of the last week of classes hit, and they ran out of time.
- The students who submitted new code are likely the ones doing well enough in their other courses to be able to spare extra time for this course. They are also probably used to doing well in all of their courses, and a little uncertainty about their grade in this course may have spurred them into action. So, they may have had both more time and more internal motivation to do extra work.
- To be fair, I don't know that the other students didn't attempt to solve some of the problems. Maybe some tried but did not submit their work. They may not have been satisfied with the quality of their code and didn't have time to seek help from me before the deadline.
- And, if we are being honest, there is at least one more possibility. A few of the students who find themselves needing extra credit at the end of of the semester got themselves into that position by not being very disciplined in their work habits. Those students may be as optimistic as any other students, but they aren't likely to conjure up better work habits on short notice.
These reflections have me thinking... If I want to help the students who most need the help, I need to find ways to reach them sooner. I did try one thing earlier this semester that worked well for many students: the opportunity to rewrite one of their exams at home with access to all the course materials. A couple of students wrote surprisingly candid and insightful assessments of why they had performed below par under test conditions and supplied better work on their second attempt. I hope that experience helps them as they prepare for the final exam.
I've been teaching a long time. I still have much to learn.
April 29, 2016 3:30 PM
A Personal Pantheon of Programming Books
Michael Fogus, in the latest issue of Read-Eval-Print-λove, writes:
The book in question was Thinking Forth by Leo Brodie (Brodie 1987) and upon reading it I immediately put it into my own "personal pantheon" of influential programming books (along with SICP, AMOP, Object-Oriented Software Construction, Smalltalk Best Practice Patterns, and Programmers Guide to the 1802).
Mr. Fogus has good taste. Programmers Guide to the 1802 is new to me. I guess I need to read it.
The other five books, though, are in my own pantheon influential programming books. Some readers may be unfamiliar with these books or the acronyms, or aware that so many of them are available free online. Here are a few links and details:
- Thinking Forth teaches us how to program in Forth, a concatenative language in which programs run against a global stack. As Fogus writes, though, Brodie teaches us so much more. He teaches a way to think about programs.
- SICP is Structure and Interpretation of Computer Programs, hailed by many as the greatest book on computer programming ever written. I am sympathetic to this claim.
- AMOP is The Art of the Metaobject Protocol, a gem of a book that far too few programmers know about. It presents a very different and more general kind of OOP than most people learn, the kind possible in a language like Common Lisp. I don't know of an authorized online version of this book, but there is an HTML copy available.
- Object-Oriented Software Construction is Bertrand Meyer's opus on OOP. It did not affect me as deeply as the other books on this list, but it presents the most complete, internally consistent software engineering philosophy of OOP that I know of. Again, there seems to be an unauthorized version online.
- I love Smalltalk Best Practice Patterns and have mentioned it a couple of times over the years [ 1 | 2 ]. Ounce for ounce, it contains more practical wisdom for programming in the trenches than any book I've read. Don't let "Smalltalk" in the title fool you; this book will help you become a better programmer in almost any language and any style. I have a PDF of a pre-production draft of SBPP, and Stephane Ducasse has posted a free online copy, with Kent's blessing.
There is one book on my own list that Fogus did not mention: Paradigms of Artificial Intelligence Programming, by Peter Norvig. It holds perhaps the top position in my personal pantheon. Subtitled "Case Studies in Common Lisp", this book teaches Common Lisp, AI programming, software engineering, and a host of other topics in a classical case studies fashion. When you finish working through this book, you are not only a better programmer; you also have working versions of a dozen classic AI programs and a couple of language interpreters.
Reading Fogus's paragraph of λove for Thinking Forth brought to mind how I felt when I discovered PAIP as a young assistant professor. I once wrote a short blog entry praising it. May these paragraphs stand as a greater testimony of my affection.
I've learned a lot from other books over the years, both books that would fit well on this list (in particular, A Programming Language by Kenneth Iverson) and others that belong on a different list (say, Gödel, Escher, Bach -- an almost incomparable book). But I treasure certain programming books in a very personal way.
April 28, 2016 4:12 PM
A Homeric Take on the Power of Programming
By participating in history instead of standing by to watch we shall at least be able to enjoy the present. ... You should read your Homer. Gods who manipulate the course of destiny are no more likely to achieve their private ambitions than are men who suffer the slings and arrows of outrageous fortune; but gods have much more fun!
If we are to be thwarted in our ambitions, let us at least enjoy the striving. Writing code is one way to strive bigger.
April 27, 2016 4:35 PM
"I Had No Need Of That Hypothesis"
Joshua Brown closes his blog Simple vs Complex with this delightful little story:
1802: Emperor Napoleon sits in state at the Chateau de Malmaison, ready to receive the the mathematical physicist Pierre Laplace and his just completed Celestial Mechanics. In this book, Laplace has explained the formation of the solar system for the first time and has modeled exactly how the planets and stars work. For all his brutality and battlefield expedience, Napoleon is a sophisticate and an enthusiast of the arts and sciences. He is intellectually curious.
"Tell me, Monsieur Laplace, how did the solar system come about?"One hundred years earlier, Sir Isaac Newton had created a celestial model of his own. In it, he surmised that the planetary orbits were out of control and not stable, and that a God was needed to explain their course. Laplace went further than Newton, showing "it works without that, too."
"A chain of natural causes would account for the construction and preservation of the celestial system," Laplace explains.
"But you don't mention God or his intervention even once, as Newton did?"
"I had no need of that hypothesis."
Whatever one's position on faith in a supernatural deity, Laplace models precisely the attitude that scientists must bring to their work. Let's explain every phenomenon with the fewest and simplest hypotheses.
April 25, 2016 1:26 PM
"So Little of the Great to Conceal"
In a recent post, Clive Thompson quotes a short passage from Carlo Rovelli's Seven Brief Lessons on Physics in which Rovelli notes that genius hesitates when it comes upon great ideas. Einstein introduced quantum theory with "It seems to me...", and Darwin demurred even in his own notebooks on natural selection with "I think...". Thompson writes:
It's not a bad litmus test for the people around us in everyday life. The ones who are proposing genuinely startling and creative ideas are liable to be ... careful about it. It's the ones with small ideas who are shouting them from the rooftops.
These thought brought to mind a wonderful passage from Okakura Kakuzo's The Book of Tea:
Perhaps we reveal ourselves too much in small things because we have so little of the great to conceal.
Those who encounter a great idea are most willing to let their uncertainty show. Those who express no uncertainty often have no greatness to conceal.
Earlier in the book, Okakura writes another line that I see quoted often:
Those who cannot feel the littleness of great things in themselves are apt to overlook the greatness of little things in others.
This passage takes on a different flavor for me when considered in the light of Rovelli's observation.
April 24, 2016 6:46 PM
A Short Break in Boston
This weekend has been a normal one at home, a little online and a little off, but last weekend I went offline for most of three and a half days to visit my older daughter in Boston. She been in Jamaica Plain in for eight months and had plenty of sights to show. I hadn't spent much time in Boston since AAAI 1990 and, except for the walk across the Charles River from my MIT dorm room, had forgotten most of the details of that trip. Now that I blog, I can preserve my memories for 2042 me.
Offline. Being offline for most of three and a half days was a treat. I had my laptop on for only a couple of hours in the Chicago airport when I used a long layover to grade one of my students programming assignments. Thereafter, I left it in its bag, turned off. It was great to be present to my daughter and the world for a while without feeling the need to check mail or tinker with work.
Goal. At the airport, I saw several members of the Fort Lauderdale Strikers, a North American Soccer League team. I'm guessing they were passing through ORD en route to a match with the Minnesota United. From the score of the game, I think my weekend went better than theirs.
Confluence. Saturday morning, we went out for brunch at the Center Street Cafe in Jamaica Plain. We arrived a few minutes after opening. Seating is limited, so we waited outside in line.
There was one party ahead of us, a young couple. The young woman kept looking at my jacket and finally said, "Did you go to UNI?" When I told her that I teach there and that my daughter is from Cedar Falls, she told us that she is from Des Moines. The older guy behind me in line heard us discussing Iowa, asked where we were from, said that he is from Council Bluffs, and recalled that a good friend of his UNI. We all marveled at the coincidence. Our new Council Bluffs friend wondered what it was that attracted Iowans to Boston; I silently wondered if Boston depended on an influx of Iowa talent to stay fresh.
The food was excellent, too.
Walking. After brunch, my daughter and I spent several hours walking in the Arnold Arboretum and the Forest Hills Cemetery. The arboretum is not yet in bloom yet still had plenty of neat things to see, as well as a prodigious hill to climb. The cemetery is full of impressive monuments and interesting sculpture.
For some reason, I got it in my head that I wanted that I wanted to see e.e. cummings's cemetery marker. I did not know that it is famously difficult to find. Alas, after several hours on foot at the arboretum and cemetery in the sun, my brain was not up to the task of finding it. Now I have extra motivation to return to JP. I'll have a picture next time.
The Arts. We decided to spend Sunday afternoon at the Museum of Fine Arts, but I could have spent a week there. Our first stop was the special exhibit called Megacities, by artists from cities that have, in the last few decades, grown to populations in excess of 20 million people. These artists are responding to what this growth means for the people, their way of life, and the cities themselves. The old architecture student in me was drawn especially to two spaces created to evoke the cities that existed before the growth:
- Hu Xiangcheng's room-like installation made from windows and doors that were salvaged from Ming- and Qing-era houses torn down to make way for modern buildings
- Asim Waqif's bamboo scaffolding inspired by the changes in construction techniques in Delhi
Sarah wanted to be sure to see a painting she likes, of a big storm in a valley, and otherwise was open to explore. It turned out to be Albert Bierstadt's wonderful Storm in the Mountains. I expressed interest in the impressionists, so we made sure to swing through those galleries, too. The Pisarros took more of my attention than in the past, and the Monets lived up to my expectations. We spent several minutes examining several of his Rouen Cathedral canvases and several of his Morning on the Seine works up close, then walked to the opposite corner of the room to experience them from a distance. It was hard to leave.
A New Favorite. The MFA has an extensive collection of John Singer Sargent's work, about which I had much to learn. I left the weekend with a new painting among my favorites, Sargent's "An Artist in His Studio":
Up close, the detail in the bedding grabs the eye: "Surely, never were tumbled white sheets so painted before." The artist at work.
Coincidence. My reading for the trip was The Book of Tea, Okakura Kakuzo's short book on the Japanese tea ceremony and its intimate connection to art, culture, and philosophy. Until I reached the biographical essay at the back of this 1956 edition of the book, I did not know that Okakura had a connection to the MFA in Boston:
The wholesale destruction of a nation's cultural heritage [in the late 19th century] aroused to action a small group of Japanese artists and men of letters and a handful of foreigners who seemed more concerned about the fate of Japanese art than were many native hotheads. The nucleus of this movement emerged from the Imperial University in Tokyo, with Professors Morse and Fenollosa in the lead, and with Kano Hogai, of the ancient family of artists, to act as historic instructor. Fenollosa urged his wealthy friend, William Sturgis Bigelow, to buy up whatever of value was tossed on a careless market; this was to become the core of the great Oriental collection of the Boston Museum. Okakura Kakuzo and Baron Kuki were the most energetic Japanese workers in this group.
Iowans and Japanese intersecting with Boston. The Oriental collection is definitely on the itinerary for my next visit.
Much More. We packed the weekend from morning until night, beginning with a workout at my daughter's gym and ending each night with a film. In addition to the places I've mentioned, we visited the aquarium, the North End, Boston Common, and the public garden, another brunch at Vee Vee, and a dinner at Bella Luna. It was a weekend well-spent.
A Modern Man. I even joined the 21st century on this trip. I sent a text for no purpose other than to say 'hello'. My daughter and I streamed movies from Netflix. And I relied on my cell phone alarm to awaken to catch a cab at 5:00 AM. A weekend well-spent, indeed.
PLT Rising. One last bit of new knowledge: Northeastern University is but two short subway stops from where I got off for my visit. This means that my next visit to Jamaica Plain, should there be one, will include a visit to see the home of the PLT group there. If nothing else, I can take snapshots of the labs and offices where so much cool Racket work is done. Then maybe I could write the excursion off as a business trip.
April 22, 2016 12:03 PM
Universities, Cities, and Start-Ups
If I were the city of Des Moines, I'd be thinking about Paul Graham's advice on how to make Pittsburgh a startup hub. Des Moines doesn't have a Carnegie Mellon, but it is reasonably close to two major research universities and has a livable downtown. While Des Moines is not likely to become a major startup hub, it could create the sort of culture needed to sustain a healthy ecosystem for new companies. Such an ecosystem would strengthen its already solid, if unspectacular, IT industry.
Regarding the universities' role in this process, Graham says:
Being that kind of talent magnet is the most important contribution universities can make toward making their city a startup hub. In fact it is practically the only contribution they can make.
But wait, shouldn't universities be setting up programs with words like "innovation" and "entrepreneurship" in their names? No, they should not. These kind of things almost always turn out to be disappointments. They're pursuing the wrong targets. The way to get innovation is not to aim for innovation but to aim for something more specific, like better batteries or better 3D printing. And the way to learn about entrepreneurship is to do it, which you can't in school.
Our university has an entrepreneurship program. I like a lot of what they do for students, but I worry about it becoming about entrepreneurship more than students starting companies. Academics are great at creating programs to talk about stuff, and a lot of what I see our students do is reading about entrepreneurship and studying what other entrepreneurs have done and are done. I'm reminded of an online Q-n-A with Elon Musk's ex-wife. She said that one thing Elon was not doing was sitting around thinking about what other entrepreneurs were doing.
As in so many things, I am also reminded of an aphorism from Kent Beck: "Do stuff, or talk about stuff, but don't talk about doing stuff." An entrepreneur does things. The best thing a university can do is to help students learn what they need to solve hard problems and then get out of their way.