Dynamic Typing


In my CS330 class today, we were discussing dynamic typing and the define-datatype declaration. Most of the students have never worked in a dynamically typed language like Scheme before, so there's plenty of opportunity for this topic to come up. What they're discovering is that as a programmer you have to worry about typing no matter what. A strongly typed language merely creates an environment so that the type-checker can automatically check the type constraints for you at the cost of restricting some genuinely useful things you might want to do. I told them that the debate about dynamically and strongly typed languages had been going on for years and would continue on for years. When I got back to my office, I found a well thought out piece by Tim Bray on that very topic in my news and a comment by Sean McGrath that adds some good information regarding typing and XML.

Tim references the Paul Graham piece that I wrote about earlier and then points to Strong Typing vs. Strong Testing from Bruce Eckel, and Are Dynamic Languages Going to Replace Static Languages? by Robert C. Martin. Both of these have some excellent material in them and the Tim goes on to add his own comments. Nice reading for anyone interested in the future of programming languages.

One of my favorite things about the Concepts of Programming Languages class I'm teaching is that it is an excellent vehicle for expanding the scope of what CS students think is "right" or "good" or "the way you do things." Before they take this class most of them have never programmed in anything but a compiled, statically-typed programming language with roots in the imperative programming paradigm. If all we wanted was to create programmers to write code for corporations, then they wouldn't need to learn anything else. Fortunately, we're trying to teach them to be computer scientists, not programmers. This is the age-old problem of academics. If you try to follow what "industry" wants in graduates, you throw out some of the things that will give them flexibility and the tools for life-long learning. How many graduates of an industry driven CS program could understand the articles I reference above and make informed conclusions from them? Not many, I'm afraid.

The problem is greatly exacerbated in Computer Science because the IT industry is a $2 trillion per year locomotive that doesn't often wait for academics to think things through. It uses a lot of capital and survival of the fittest to foster innovative thinking and the next new thing. The IT industry demands graduates that can go to work when they graduate. This presents a difficult choice for academics. However, I think that it makes the student's choice crystal clear: become a computer scientist, not just a programmer, because if the IT locomotive does decide next year that some new thing is better, you'd better be as adaptable or you'll get left in the dust.