Stop Me If You’ve Heard This One
I used to tell this joke:
An engineer says, “Theory approximates reality.”
A mathematician says, “Reality approximates theory.”
A sociologist says, “Would you like fries with that?”
I used to tell this joke:
An engineer says, “Theory approximates reality.”
A mathematician says, “Reality approximates theory.”
A sociologist says, “Would you like fries with that?”
Last week, I posted an exercise on working with sets and dictionaries that also included a fair bit of file I/O and string manipulation. My solution is below, in four parts, along with the code produced in each. If someone would like to re-do the file parsing using regular expressions, I’d be happy to post that as well.
You are working for a nanotechnology company that prides itself on manufacturing some of the finest molecules in the world. Your job is to rewrite parts of their ordering system, which keeps track of what molecules they can actually make. Before trying this exercise, please review:
Submit your work by mailing Greg:
Do you know someone who’d be helped by a Software Carpentry boot camp? Or can you introduce us to someone who’d help us organize one in a new venue? If so, please introduce us: we’d like to start planning for the fall, and we’re always keen to make new friends.
A lot goes on behind the scenes here at software-carpentry.org:
In my experience, most teachers don’t develop courses from scratch. Instead, they take whatever material is at hand, modify it to meet their needs, and then—well, that’s usually where they stop. Unlike open source software developers, they usually don’t give it back to the community in any explicit way. Instead, the next person who needs a starting point has to stumble over it in a Google search, and the original creator may never know that someone improved upon what they did.
We’re half-way through our current round of work, so it’s time to start thinking about what we’ve accomplished, what we’ve learned, and what we’d like to do next. Here’s what I think we now know:
In more detail:
A faculty member whose research involves building some fairly complex scientific software would like to make all his work open source. He is repeatedly having to justify this choice to funding agencies and his dean, whose objections include:
I know lots of other people have had to overcome these and other objections; what I’m looking for is a published (and preferably peer-reviewed) refutation of them that he and others can cite, preferably one that is specific to open source in science (rather than in general). Pointers would be very welcome.
Our boot camp at Utah State University finished earlier today—many thanks once again to Ethan White and his friends for hosting us. Here’s what the students thought:
| Good | Bad |
|
|
Next stop: London!