October 17, 2016 4:10 PM
Using Programming to Learn Math, Even at the University
There is an open thread on the SIGCSE mailing list called "Forget the language wars, try the math wars". Faculty are discussing how to justify math requirements on a CS major, especially for students who "just want to be programmers". Some people argue that math requirements are a barrier to recruiting students who can succeed in computer science, in particular calculus.
Somewhere along the line, Cay Horstmann wrote a couple of things I agree with. First, he said that he didn't want to defend the calculus requirement because most calculus courses do not teach students how to think "but how to follow recipes". I have long had this complaint about calculus, especially as it's taught in most US high schools and universities. Then he wrote something more positive:
What I would like to see is teaching math alongside with programming. None of my students were able to tell me what sine and cosine were good for, but when they had to program a dial [in a user interface], they said "oh".
Couldn't that "oh" have come earlier in their lives? Why don't students do programming in middle school math? I am not talking large programs--just a few lines, so that they can build models and intuition.
I agree wholeheartedly. And even if students do not have such experiences in their K-12 math classes, the least we could do help them have that "oh" experience earlier in their university studies.
My colleagues and I have been discussing our Discrete Structures course now for a few weeks, including expected outcomes, its role as a prerequisite to other courses, and how we teach it. I have suggested that one of the best ways to learn discrete math is to connect it with programs. At our university, students have taken at least one semester of programming (currently, in Python) before they take Discrete. We should use that to our advantage!
A program can help make an abstract idea concrete. When learning about set operations, why do only paper-and-pencil exercises when you can use simple Python expressions in the REPL? Yes, adding programming to the mix creates new issues to deal with, but if designed well, such instruction could both improve students' understanding of discrete structures -- as Horstmann says, helping them build models and intuition -- and give students more practice writing simple programs. An ancillary benefit might be to help students see that computer scientists can use computation to help them learn new things, thus preparing for habits that can extend to wider settings.
Unfortunately, the most popular Discrete Structures textbooks don't help much. They do try to use CS-centric examples, but they don't seem otherwise to use the fact that students are CS majors. I don't really blame them. They are writing for a market in which students study many different languages in CS 1, so they can't (and shouldn't) assume any particular programming language background. Even worse, the Discrete Structures course appears at different places throughout the CS curriculum, which means that textbooks can't assume even any particular non-language CS experience.
Returning to Horstmann's suggestion to augment math instruction with programming in K-12, there is, of course, a strong movement nationally to teach computer science in high school. My state has been disappointingly slow to get on board, but we are finally seeing action. But most of the focus in this nationwide movement is on teaching CS qua CS, with less interest in emphasis on integrating CS into math and other core courses.
For this reason, let us again take a moment to thank the people behind the Bootstrap project for leading the charge in this regard, helping teachers use programming in Racket to teach algebra and other core topics. They are even evaluating the efficacy of the work and showing that the curriculum works. This may not surprise us in CS, but empirical evidence of success is essential if we hope to get teacher prep programs and state boards of education to take the idea seriously.
October 16, 2016 10:34 AM
Missing the Rhythm of Running
I ended up with an unexpected couple of hours free yesterday afternoon, and I decided to clean up several piles of old papers on the floor of my running room. Back when I ran marathons, I was an information hound. I wrote notes, collected maps, and clipped articles on training plans, strength training, stretching and exercise, diet and nutrition -- anything I thought I could use to get get better. I'm sure this surprises many of you.
There was a lot of dust to dig through, but the work was full of happy reminiscences. It's magical how a few pieces of paper can activate our memories. The happy memories leave in their wake a sadness, when my time as a runner ended. That's when the piles stopped growing. I stopped collecting material, because I wasn't running anymore.
Fortunately, the sadness of loss didn't drown out the happy memories. Instead, I started thinking about the future, which is really now. These thoughts are long past due.
Looking back through my running logs reminded of the pattern of my life as a marathoner. There was an ebb and a flow to the year. I trained for my first half marathon. Then I trained for my first full marathon. I ran lightly for a few weeks as my body recovered. Winter and spring saw regular runs, but a break for mind and body alike: no big plans, just enjoying the road. Then came the end of spring, and it started all over again: training for big races. These years were filled with variety in my running, variety in my goals.
The last few years have been different. I recovered from a couple of operations, eventually taking up the elliptical machine and returning to my bike for fitness. However, I have never become a cyclist in spirit the way I became a runner. I've been exercising lots, staying fit and healthy, but I miss the rhythm of running and training for marathons. In comparison, my exercise since leaves me bored and uninspired.
Diving into those piles of paper yesterday started me thinking, what are the next goals? I'll be working on that as we slide into winter, looking forward what next spring might bring.
October 15, 2016 10:47 AM
A View of Self-Driving Cars from 1956
A friend and fellow classic science fiction fan told me that one of his favorite books as a teenager was Robert Heinlein's The Door into Summer. I've read a lot of Heinlein but not this one, so I picked it up at the library.
Early in the book, protagonist Daniel B. Davis needed to make the most of the next twenty-fours. He located his car, dropped some money into the "parking attendant", set course, and relaxed as the car headed out into traffic:
Or tried to relax. Los Angeles traffic was too fast and too slashingly murderous for me to be really happy under automatic control; I wanted to redesign their whole installation--it was not a really modern "fail safe". By the time we were west of Western Avenue and could go back on manual control I was edgy and wanted a drink.
This scene is set December 1970; Heinlein wrote it in 1956. He may have missed the year in which self-driving cars were already common technology by 45 years or more, but I think he got the feeling right. People like to be in control of their actions, especially when dropped into hectic conditions they can't control. Heinlein's character is an engineer, so naturally he thinks he could design a better. None of my programmer friends are like this, of course.
It's also interesting to note that automatic control was required in the most traffic. Once he got into a calmer setting, Davis could go back to driving himself. The system allows the human to drive only when he isn't a danger to other people, or even himself!
Today, it is commonplace to think that the biggest challenges of the move to self-driving cars are cultural, not technological: getting people to accept that the cars can drive themselves more safely than humans can drive them, and getting people to give up control. It's neat to see that Heinlein recognized this sixty years ago.
October 13, 2016 4:29 PM
Shocking News: Design Technique Not Helpful When Design Is Already Done
Thanks to Greg Wilson for a pointer to this paper, which reports the result of an empirical evaluation of the effects of test-driven development on software quality and programmer productivity. In a blog entry about the paper, Wilson writes:
This painstaking study is the latest in a long line to find that test-driven development (TDD) has little or no impact on development time or code quality.
He is surprised, because he feels more productive when he writes tests up-front.
I'd like to be able to say that these researchers and others must be measuring the wrong things, or measuring things the wrong way, but after so many years and so many different studies, those of us who believe might just have to accept that our self-assessment is wrong.
Never fear! Avdi Grimm points the way toward resolution. Section 3.3 of the research paper describes the task that was given to the programmers in the experiment:
The task was divided into 13 user stories of incremental difficulty, each building on the results of the previous one. An example, in terms of input and expected output, accompanied the description of each user story. An Eclipse project, containing a stub of the expected API signature, (51 Java SLOC); also an example JUnit test (9 Java SLOC) was provided together with the task description.
Notice what this says:
- Test subjects were given the user stories.
- The stories were sequenced to assist the subjects.
- Each story was accompanied by an example.
- Subjects were given code stubs with method signatures already defined.
The paper reports that previous studies of this sort have also set tasks before programmers with similar initial conditions. Grimm identifies a key feature of all these experiments: The problem given to the test subjects has already been defined in great detail.
Shocking news: test-driven design is not helpful when the design is already done!
As Grimm says, TDD helps the programmer think about how to start writing code and when to stop. For me, the most greatest value in doing TDD is that it helps me think about what I need to build, and why. That is design. If the problem is already defined to the point of implementation, most of the essential design thinking has been done. In that context, the results reported in this research paper are thoroughly unsurprising.
Like Grimm, I sympathize with the challenge of doing empirical research on the practices of programmers. I am glad that people such as the paper's authors are doing such research and that people such as Wilson discuss the results. But when we wonder why some research results conflict with the personal assessments of real programmers and our assessments of our own experiences, I think I know what one of the problems might be:
Evaluating the efficacy of a design methodology properly requires that we observe people doing, um, design.
October 06, 2016 2:46 PM
Computers Shouldn't Need a Restart Button (Memories of Minix)
An oldie but goodie from Andrew Tanenbaum:
Actually, MINIX 3 and my research generally is **NOT** about microkernels. It is about building highly reliable, self-healing, operating systems. I will consider the job finished when no manufacturer anywhere makes a PC with a reset button. TVs don't have reset buttons. Stereos don't have reset buttons. Cars don't have reset buttons. They are full of software but don't need them. Computers need reset buttons because their software crashes a lot. I know that computer software is different from car software, but users just want them both to work and don't want lectures why they should expect cars to work and computers not to work. I want to build an operating system whose mean time to failure is much longer than the lifetime of the computer so the average user never experiences a crash.
I remember loving MINIX 1 (it was just called Minix then, of course) when I first learned it in grad school. I did not have any Unix experience coming out of my undergrad and had only begun to feel comfortable with BSD Unix in my first few graduate courses. Then I was assigned to teach the Operating Systems course, working with one of the CS faculty. He taught me a lot, but so did Tanenbaum -- through Minix. That is one of the first times I came to really understand that the systems we use (the OS, the compiler, the DBMS) were just programs that I could tinker with, modify, and even write.
Operating systems is not my area, and I have no expertise for evaluating the whole microkernel versus monolith debate. But I applaud researchers like Tanenbaum who are trying to create general computer systems that don't need to be rebooted. I'm a user, too.
October 04, 2016 3:40 PM
First, Be Careful What You Teach People To Expect
Last month, Seth Godin posted a short entry about reputation. It brought back memories of my first couple of years as department head. I was excited and wanted to do a good job, so I took on a lot. Pretty soon I was in a position of having promised more than I could deliver. Some of the shortfall resulted from the heavy load itself; there are only so many hours in a week. Some resulted from promising things I couldn't deliver, because I didn't understand the external constraints I faced.
When you don't deliver, explanations sound like excuses.
If I were giving advice to myself at the time I became head (already an adult who should have known better...), I would tell him to heed Godin's advice and help people learn what they can expect from you. Explicit attention to expectations can pay off in seeding reputation but also by setting parameters for yourself. Then live up to that standard.
If you teach people to expect little, perhaps unintentionally, they will -- even on the occasions when you do better. And after you get better, if you do, it takes a long time to undo the expectations you created early on.
Live the life you've taught people to expect from you -- but first be careful what you teach them to expect.
October 02, 2016 10:03 AM
Tom Wolfe on Writer's Block
In the Paris Review's The Art of Fiction No. 123, Tom Wolfe tells how he learned about writer's block. Wolfe was working at Esquire magazine, and his first editor, Byron Dobell, had assigned him to write an article about car customizers. After doing all his research, he was totally blocked.
I now know what writer's block is. It's the fear you cannot do what you've announced to someone else you can do, or else the fear that it isn't worth doing. That's a rarer form. In this case I suddenly realized I'd never written a magazine article before and I just felt I couldn't do it. Well, Dobell somehow shamed me into writing down the notes that I had taken in my reporting on the car customizers so that some competent writer could convert them into a magazine piece. I sat down one night and started writing a memorandum to him as fast as I could, just to get the ordeal over with. It became very much like a letter that you would write to a friend in which you're not thinking about style, you're just pouring it all out, and I churned it out all night long, forty typewritten, triple-spaced pages. I turned it in in the morning to Byron at Esquire, and then I went home to sleep.
Later that day, Dobell called him to say that they were deleting the "Dear Byron" at the top of the memo and running the piece.
Most of us need more editing than that after we write anything, but... No matter; first you have to write something. Even if it's the product of a rushed all-nighter, just to get an obligation off our table.
When I write, and especially when I program, my reluctance to start usually grows out of a different sort of fear: the fear that I won't be able to stop, or want to. Even simple programming tasks can become deep holes into which we fall. I like that feeling, but I don't have enough control of my work schedule most days to be able to risk disappearing like that. What I could use is an extra dose of audacity or impetuosity. Or maybe a boss like Byron Dobell.
September 28, 2016 3:16 PM
Language, and What It's Like To Be A Bat
My recent post about the two languages resonated in my mind with an article I finished reading the day I wrote the post: Two Heads, about the philosophers Paul and Pat Churchland. The Churchlands have been on a forty-year quest to change the language we use to describe our minds, from popular terms based in intuition and introspection to terms based in the language of neuroscience. Changing language is hard under any circumstances, and it is made harder when the science they need is still in its infancy. Besides, maybe more traditional philosophers are right and we need our traditional vocabulary to make sense of what it feels like to be human?
The New Yorker article closes with these paragraphs, which sounds as if they are part of a proposal for a science fiction novel:
Sometimes Paul likes to imagine a world in which language has disappeared altogether. We know that the two hemispheres of the brain can function separately but communicate silently through the corpus callosum, he reasons. Presumably, it will be possible, someday, for two separate brains to be linked artificially in a similar way and to exchange thoughts infinitely faster and more clearly than they can now through the muddled, custom-clotted, serially processed medium of speech. He already talks about himself and Pat as two hemispheres of the same brain. Who knows, he thinks, maybe in his children's lifetime this sort of talk will not be just a metaphor.
If, someday, two brains could be joined, what would be the result? A two-selved mutant like Joe-Jim, really just a drastic version of Siamese twins, or something subtler, like one brain only more so, the pathways from one set of neurons to another fusing over time into complex and unprecedented arrangements? Would it work only with similar brains, already sympathetic, or, at least, both human? Or might a human someday be joined to an animal, blending together two forms of thinking as well as two heads? If so, a philosopher might after all come to know what it is like to be a bat, although, since bats can't speak, perhaps he would be able only to sense its batness without being able to describe it.
(Joe-Jim is a character from a science fiction novel, Robert Heinlein's Orphans of the Sky.)
What a fascinating bit of speculation! Can anyone really wonder why kids are drawn to science fiction?
Let me add my own speculation to the mix: If we do ever find a way to figure out what it's like to be a bat, people will find a way to idescribe what it's like to be a bat. They will create the language they need. Making language is what we do.
September 27, 2016 2:57 PM
Elrond, Agile Development Sage
Call me a crazy extreme programmer, but when I came across the Tolkien passage quoted in my previous post on commitment and ignorance again recently after many years, my first thought was that Elrond sounded like a wise old agile developer:
Look not too far ahead!
You aren't gonna need it, indeed.
This first thought cast Gimli in the role of a Big Design Up Front developer. Unfortunately, that analogy sells his contribution to the conversation short. Just as Gimli's deep commitment to the mission is balanced by Elrond's awareness, so, too, is Gimli's perspective applied to software balanced by Elrond's YAGNI. Perhaps then Gimli plays the role of Metaphor in this fantasy: the impulse that drives the team forward to the ultimate goal.
Just another one of those agile moments I have every now and then. I wonder if they will start happening with more frequency, and less reality, as I get older. They are a little like senior moments, only focused on programming.
September 26, 2016 2:54 PM
A Lesson from Tolkien about Commitment and Ignorance
Elrond has just addressed the Fellowship of the Ring, reminding them that only the Ring-Bearer is charged with completing the task ahead of them. The others "go with him as free companions", to assist in whatever ways they are able. He enters into an exchange with Gimli:
"The further you go, the less easy it will be to withdraw; yet no oath or bond is laid on to go further than you will. For you do not yet know the strength of your hearts, and you cannot foresee what each may meet upon the road."
"Faithless is he who says farewell when the road darkens," said Gimli.
"Maybe," said Elrond, "but let him not vow to walk in the dark who has not seen the nightfall."
"Yet sworn word may strengthen the quaking heart," said Gimli.
"Or break it," said Elrond. "Look not too far ahead!"
This is a tension we all live: the desire to make unconditional promises about the future to our lovers and compatriots despite not evening knowing what is possible in that future. I love Elrond's response, "Let him not vow to walk in the dark who has not seen the nightfall." Members of the Fellowship found that their future contained evil beyond their comprehension and temptations beyond their imagination.
Our challenge is to constantly balance this tension: to live with the confidence of Gimli, but tempered by the pragmatic awareness of our ignorance that Elrond offers. Sometimes, commitment gives us the strength to continue on in the face of fear. Sometimes, though, there is no shame in turning back.