A different kind of computing curriculum? - Thoughts on an interview with Smalltalk Dave
I finally got around to listening to this interview with Smalltalk Dave Thomas (as opposed to Ruby’s Dave Thomas) from the Agile Toolkit Podcast. There’s a lot of interesting stuff in this puppy, and curriculum design would be a totally different animal if more academics were listening to people like Thomas.
He’s clearly a big fan of functional languages and tools
It’s really too bad we didn’t actually keep that course that taught those students functional programming and make them see Haskell or Scheme.
and also argues that JavaScript (a) is huge (in small part because Google just uses it so much, and so well) and (b) is essentially Scheme with a different (nastier, in his opinion) syntax. We teach a little JavaScript in an introductory non-majors course, but I think we almost entirely don’t touch it after that. Hmmm… Maybe we need to look into that.
Also, and not surprisingly given his Smalltalk history, he’s big into duck typing (like Smalltalk and Ruby) and not a big fan of heavyweight static typing. I twitch a little when I hear this stuff because static typing has always been a big deal in my universe, especially in teaching. An interesting take on this, though, is that
Test first really does the same thing as a typechecker, and in fact it does a little more.
My graduate experience at UT was very much a formalist experience, with lots of emphasis on formal methods and static types. Clearly there’s an alternative model here where serious test driven development provides the safety and correctness. You obviously need the discipline to make this work, but you arguably need discipline to do any sort of interesting software development well. Taking that as your premise, however, would lead to a very different curriculum model than most traditional arrangements.
What would a curriculum look like if you took agile methods and test driven development as your key premises from the very beginning. If all the early assignments were all unit tests that need to be passed? (The students would be writing their own tests for later assignments.) If everything was done in pairs/teams? If you emphasized dynamic tools and languages, using heavy tests to keep the quality high?
I’ll leave everyone with this very cool (for someone who teaches this stuff) line:
There is going to be an acute shortage of talented software people.
We all (and I mean everyone in our society) have come to seriously depend on software, so we all need talented people to be doing that work. This means we need to be encouraging bright young people to consider software development and computer science as an important and exciting option. We need to provide curricula that challenge, excite, and prepare them. I think we’re doing a good job at Morris, but could do better. Unfortunately, I think there are still way too schools that are stuck somewhere in the mid-80’s (”Hey, objects are actually pretty cool!”).
No tag for this post.
September 18th, 2007 at 20:37
Nic and everyone,
the role of dynamically typed languages and test-driven development is certainly a topic worth discussing. However, I am afraid that I am an even stronger proponent of (semi-)strongly typed languages, such as Java or ML, at least given available options at the moment. Here are a couple of thoughts:
- you pointed out that test-driven development requires discipline. However, I believe that it also requires experience. Debugging testing code in addition to “real” code can be very tricky and confusing for a new student, and their first tests will be just as buggy as their first code. Having the professor (or a TA) to write (and test!) all of the testing code seems like a complicated process which also takes away the flexibility of material (if I want to make a change to the assignment, I need to make new testing code as well). It is also my experience that even for “seasoned” programmers’ mistakes are just as likely to happen in the testing code as in the “real” code. In this sense I trust compiler-writers more, just because compilers are better tested.
Also, recalling how many times we had to rewrite software D labs might be a good estimate of how much effort is needed to create a viable testbed for an intro course. Unfortunately, a buggy setup in an intro class will cost us disappointed students which we can’t afford.
- I played with Javascript last semester, not just in the intro class, but also in the upper-division web programming class. To me, languages like ruby and especially Javascript fall into a category of “implicitly typed” languages: there is a type system, but it is essentially masked from the programmer by implicit typecasts which can swallow just about any type error until a wrong value suddenly surfaces at run-time. This is annoying for experienced programmers and confusing for new ones. Explaining to a new programmer a difference between an integer and a string in a language that doesn’t even introduce type names (other than in casts) is not a very easy task. I much prefer Scheme which is really a less-typed language and allows you to mix types, and just keep track of your data structures.
- Ruby is a bit better in this sense since its type conversions are often required to be explicit. I don’t mind the idea of duck-typing. However, I still feel that Ruby and especially Ruby-based technologies, such as Rails, are not quite there yet in terms of support for teaching (or even as software development tools). The speed at which new versions grow is a good indicator. I think Ruby (or a Ruby-like language) may be a way to go in the future when there are more reliable tools available and when such languages are more popular in commercial software development.
In any case, I don’t want to destroy the idea altogether, but I am just trying to point out a few practical issues, and mostly playing devil’s advocate here. I really would like to see Ruby or other dynamically typed languages and test-driven development used more in our program. I would also love to see a functional language used in an upper-division course (Haskell might be the best choice). I think we should continue these discussions so that something good hopefully comes out of them.