- What I Would Take Out of Python. It’s grown a lot over the years; given what we have now, what would you take out, and why?
- How the Hell Did That Happen? How did Rails capture so many hearts and minds when Ruby was a relatively unknown language whose user base in North America and Europe was only a few percent of Python’s?
- Eloquent Python. An exploration of teachable uses of design patterns in the Python standard library.
- Ten Things We Know About Python Programs and Programmers. What do we actually know about execution profiles, common bugs, user demographics, etc.
- Error Handling in Python. What are some patterns for recovering from errors in Python (as opposed to just logging them)?
The University of Toronto Department of Physics brings PyCamp to Toronto on Monday, June 27 through Thursday, June 30, 2011. Register today at http://trizpug.org/boot-camp/torpy11/
For beginners, this ultra-low-cost Python Boot Camp makes you productive so you can get your work done quickly. PyCamp emphasizes the features which make Python a simpler and more efficient language. Following along with example Python PushUps? speeds your learning process. Become a self-sufficient Python developer in just four days at PyCamp! PyCamp is conducted on the campus of the University of Toronto in a state of the art high technology classroom.
Peter Norvig, the author of one of the standard textbooks on AI, and now at Google, has this to say about Python:
I came to Python not because I thought it was a better/acceptable/pragmatic Lisp, but because it was better pseudocode. Several students claimed that they had a hard time mapping from the pseudocode in my AI textbook to the Lisp code that Russell and I had online. So I looked for the language that was most like our pseudocode, and found that Python was the best match. Then I had to teach myself enough Python to implement the examples from the textbook. I found that Python was very nice for certain types of small problems, and had the libraries I needed to integrate with lots of other stuff, at Google and elsewhere on the net.
I think Lisp still has an edge for larger projects and for applications where the speed of the compiled code is important. But Python has the edge (with a large number of students) when the main goal is communication, not programming per se.
In terms of programming-in-the-large, at Google and elsewhere, I think that language choice is not as important as all the other choices: if you have the right overall architecture, the right team of programmers, the right development process that allows for rapid development with continuous improvement, then many languages will work for you; if you don’t have those things you’re in trouble regardless of your language choice.
A couple of days ago, I asked a question about generating tests for Nose. Jacob Kaplan-Moss (of Django fame) provided a elegant answer that I can understand in retrospect, but would probably not have been able to come up with myself. If you’re interested in Python decorators and generators, check out my summary on the Software Carpentry blog.
I just got a report…on the state of the Python CS1 market. The market size is estimated to be about 20,300 students per year, up 45% since last year. The market has had around 40% gains for each of the last three years.
Yay! But I wonder what they count as “the market”, and how big the absolute share (as opposed to growth) is… Anyone know?
From the announcement:
The University of Toronto Department of Physics hosts Toronto PyCamp 2010. For beginners, this ultra-low-cost Python Boot Camp makes you productive so you can get your work done quickly. PyCamp emphasizes the features which make Python a simpler and more efficient language. Following along with example Python PushUps™ speeds your learning process in a modern high-tech classroom. Become a self-sufficient Python developer in just five days at PyCamp! Conducted on the campus of the University of Toronto, PyCamp comes with your own single OS/single developer copy of Wing Professional Python IDE.
My talk at PyCon 2010 was titled “What We’ve Learned From Building Basie (and lots of other software using student labor over the course of eight years)”. The slides are up on Slideshare, and there’s video of the talk itself on blip.tv, but I thought readers of this blog might be interested in a summary.
My starting point is Joel Spolsky’s comment that, “…student projects, while laudatory, frequently fail to deliver anything useful.” Respectfully, I beg to differ: About a quarter of the student projects I’ve helped supervise since 2002 have delivered software that clients actually used, and the rest have produced something even more useful: experience. (And when I say “about a quarter”, I’m talking about a quarter of 368 people from 35 countries of origin working on 136 projects.)
To make a long story short, undergraduate students can build great software if:
- you have realistic expectations,
- you’re patient, and
- you realize that “how” matters more than “what”.
Let’s take those in order.
Realistic Expectations. Most undergrads are doing five courses at once, which leaves them only 8-10 hours/week per course. Putting it another way, 13 weeks of student time is equivalent to 3 weeks of full-time work. When you’re planning projects, you therefore have to ask yourself how much you would expect a new (junior) hire to do in their first three weeks on the job, particularly if (as is often the case with students) they’d never used the tools or worked in the application domain before.
It’s equally important to have realistic expectations of faculty, most of whom are working even harder than their students. A colleague of mine once summed up professorial life by saying, “We’re here to do research, they pay us to teach, and we spend our time on admin.” Keep in mind that computer science professors care about computer science, which is emphatically not the same thing as programming. Computer science is the scientific study of what computers can do; a computer scientist’s job is to invent (or discover, depending on your philosophical point of view) new knowledge. That sometimes involves writing code, but that’s like saying that mathematics sometimes involves doing integrals.
It took me a long time to understand this, and I’m not the only one to misunderstand this. I believe very strongly that being a better programmer can help someone be a better computer scientist, but if you want any traction in academa at all, you have to remember that programming really is just a means to an end.
Patience. Your project may be the first time students have written something that isn’t just going to be marked and thrown away. It may also be the first time they’ve been in a situation where 90% right is a failure rather than an A. You must not make students feel like failures for working the way the educational system has trained them to, even (or especially) if those ways are wrong.
Aside #1: one of the best students I’ve ever had explained to me several years ago why she always left her assignments until the last possible moment. “If I start early,” she said, “I’m the one who has to ask the prof all the questions to clear up what the assignment actually means. And if I start early, the odds are good that one of the prof’s answers will mean I have to re-do something. On the other hand, if I leave it ’til the night before, I can be sure that I have a stable spec.”
Aside #2: People often ask why schools don’t teach students Git, or Haskell, or GPU programming, or mobile devlopment, or whatever else is currently cool. The answer is that the curriculum is full. 4 years × 2 terms/year × 13 weeks is 4800 hours, and every single one of those hours is spoken for. Do you want to add functional programming? Cool! What are you going to take out: operating systems or B-trees?
How Matters More Than What. When I ask alumni of my project courses what the most valuable thing they learned was, none of them name a particular technology—none. Instead, they talk about teamwork, presentation skills, code reviews, time management, prioritization, communication, negotiating real requirements with real users, and building their network and portfolio. This is why I think that efforts to teach open source are slightly mis-aimed: in my experience, students don’t care if the code is open or closed nearly as much as they care about how to build complex things. It just happens that the various open source communities are both good at that, and able to talk publicly and in detail about the mechanics.
My colleagues and I at the University of Toronto have learned a lot of other things about running student projects, including:
- How to run meetings
- How to teach students how to do code reviews
- What level of tooling is appropriate/feasible
- How to accelerate ramp-up
- Carry-overs from previous terms
- Importance of full-time summer work (yay GSoC!)
- Industry support
- Presentations, presentations, presentations
- Scoping and re-scoping deliverables
- Recruiting students and faculty
- How to grade one-of-a-kind projects
We’re now scaling up what we’ve learned in UCOSP, a set of undergraduate capstone projects in which students from 14 universities work together in distributed teams. If you’re interested in taking part, we’d like to hear from you.
It’s a sunny Sunday morning in Atlanta, and I’m on my way home. I came down Thursday to:
- Raise money for Software Carpentry.
- Get people excited about Basie.
- Get people excited about UCOSP.
- Talk with Georgia Tech‘s Mark Guzdial about computer science education.
#4 actually happened first. Mark picked me up Friday morning; we chatted for a while, then I spent an hour with some other faculty before giving my evidence-based software engineering talk. It was fun, and I came away from my discussion with Mark with half a dozen leads to follow up.
#1 is most important to me personally—I really want to spend a year upgrading the course after I leave U of T at the end of this term—but I didn’t have much luck. The people I spoke to were sympathetic, but it’s been a hard 18 months for everyone financially, and there are a lot of other good causes clamoring for attention.
I put less time into #2 than I probably should have, but still got some good feedback (which I’ve posted on the Basie blog). Long story short, if we can make Basie faster and provide a Trac-to-Basie migration tool, our prospects are good.
I wasn’t thinking of #3 (UCOSP) when I proposed my talk, but it’s what people were most interested in. Several students and professors said that they would like to be involved; the trick now is to find money to hire a half-time admin to take care of fundraising and organization. If you have $35K you can spare, please let me know. (And my slides are up if you’re interested.)
The best part of the trip? Talking to people I’ve only ever met electronically, or haven’t seen since my last PyCon eight years ago. Some of the discussion was about programming, but not a lot (since I don’t actually program any more). Mostly it was about kids, careers, and the meaning of life—all the catching up you do with people that you really wish you got to see more often.
It’s a sunny Sunday morning in Atlanta, and I’m on my way home…
Later: video of my lightning talk on Friday evening about yet another collaborative O’Reilly book (this one on software architecture) is available at blip.tv — check about 9 minutes in.
We are pleased to announce the release of Version 0.6 of Basie, a lightweight software project portal built on Django and jQuery. Basie is designed to replace Trac and DrProject; its main features are:
- Multiple projects per forge
- Role-based access control
- Pluggable user account management
- Per-project wiki with standard WikiCreole syntax
- Subversion repository browser
- Per-project mailing list and IRC channel
- A simple ticketing system
- Milestones and calendaring
- Cross-component search
- Dashboard summarizing project activity
- Web-based administration
- REST API for web services
Thanks to the whole team for all their hard work.