Knowing and Doing on putting the Science in Computer Science

Knowing and Doing by Eugene Wallingford is one of my favourite CS faculty blogs. His commentary is always interesting and relevant; a bonus for us librarian types is that he often gives keen insight into the minds of working CS faculty, how they think, the problems they face and mostly, what they're thinking about.

Way back in November (yes, I know, I'm still recovering from all the posting about science books) he published a series of conference reports on the SECANT 2007 Workshop. The workshop topic was Science Education in Computational Thinking, in other words, how computational methods have infiltrated the practice of science at all levels. An important topic and one that I find very interesting and relevant.

Eugene was kind enough to publish a table of contents post of all the workshop-related posts, which I am sort of reproducing below. I've taken his TOC post and to each entry I've added a brief quote from the relevant post. Nevertheless, please visit a couple of Eugene's post and check out the details. As well, what he's done here is really a model for blog-based conference reporting, one of, if not the best, examples I've seen. I am certainly going to try and model my own conference blogging after what Eugene has done here.

Primary entries:

• Workshop Intro: Teaching Science and Computing (on building a community)
  

  SECANT's goals are to build a community that is asking and answering questions such as these:

  • What should science majors know about computing?
    
  • How can computer science be used to teach science?
    
  • Can we integrate computer science effectively into other majors?
    
  • What will the implications of answers to these questions be for how we teach computer science and engineering themselves?

  
  
  
• Workshop 1: Creating a Dialogue Between Science and CS (How can we help scientists and CS folks work together?)
  

  The second speaker was Noah Diffenbaugh, a professor in earth and atmospheric sciences at Purdue. He views himself as a modeler dependent on computing. In the last year or so, he has collected 55 terabytes of data as a part of his work. All of his experiments are numerical simulations. He cannot control the conditions of the system he studies, so he models the system and runs experiments on the model. He has no alternative.
  
  Diffenbaugh claims that anyone who wants a career in his discipline must be able to do computing -- as a consumer of tools, builder of models. He goes farther, calling himself a black sheep in his discipline for thinking that learning computing is critical to the intellectual development of scientists and non-scientists alike.

  
  
  
• Workshop 2: Exception Gnomes, Garbage Collection Fairies, and Problems (on a hodgepodge of sessions around the intersection of science ed and computing)
  

  This list tied well into the round-table discussion that followed, on what computational concepts science students should learn. I didn't get a coherent picture from this discussion, but one part stood out to me. Bruce Sherwood said that many scientists view analytical solution as privileged over simulation, because it is exact. He then pointed out that in some domains the situation is being turned on its head: a faithful discrete simulation is a more real depiction of the world than the closed-form analytical solution -- which is, in fact, only an approximation created at a time when our tools were more limited. The best quote of this session came from John Zelle: Continuity is a hack!

  
  
  
• Workshop 3: The Next Generation (what scientists are doing out in the world and how computer scientists are helping them)
  

  From these two talks, it seems clear that domain scientists and computer scientists of the future will need to know more about the other discipline than may have been needed in the past. Computing is redefining the questions that domain scientists must ask and redefining the tasks performed by the CS folks. The domain scientists need to know enough about computer science, especially databases and visualization, to know what is possible. Computer scientists need to study algorithms, parallelism, and HCI. They also need to take more seriously the soft skills of communication and teamwork that we have encouraging for many years now.

  
  
  
• Workshop 4: Programming Scientists (should scientists learn to program? And, if so, how?)
  

  And, yes, I do think that science students should learn how to program, for two reasons. One is that science in the 21st century is science of computation. That was one of the themes of this workshop. The other is that -- deep in my heart -- I think that all students should learn to program. I've written about this before, in terms of Alan Kay's contributions, and I'll write about it again soon. In short, I have at least two reasons for believing this:

  • Computation is a new medium of communication, and one with which we should empower everyone, not just a select few.
    
  • Computer programming is a singular intellectual achievement, and all educated people should know that, and why.

  
  
  
• Workshop 5: Wrap-Up (on how to cause change and disseminate results)
  

  On how to cause change. At one point the discussion turned philosophical, as folks considered more generally how one can create change in a larger community. Should the group try to convince other faculty of the value of these ideas first, and then involve them in the change? Should the group create great materials and courses first and then use them to convince other faculty? In my experience, these don't work all that well. You can attract a few people who are already predisposed to the idea, or who are open to change because they do not have their own ideas to drive into the future. But folks who are predisposed against the idea will remain so, and resist, and folks who are indifferent will be hard to move simply because of inertia. If it ain't broke, don't fix it.

  
  

Ancillary entries:

• A Program is an Idea (going farther on why scientists, and everyone else, should learn to program)

  A scientist can communicate an idea to others with a program, but they can also think better with a program. Graham captured this from the perspective of the software developer in the article I quoted earlier:
  
  Your code is your understanding of the problem you're exploring.
  
  Every programmer knows what this means. I can think all the Big Thoughts I like, but until I have working a program, I'm never quite certain that these thoughts make sense. Writing a program forces me to specify and clarify; it rejects fuzziness and incoherence. As my program grows and evolves, it reflects the growth and evolution of my idea. Graham says it more strongly: the program is the growth and evolution of my idea. Whether this is truth or merely literary device, thinking of the program as the idea is a useful mechanism for holding myself accountable to making my idea clear enough to execute.