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.