TITLE: Comments on Talks I Didn't Hear AUTHOR: Eugene Wallingford DATE: July 13, 2005 12:29 PM DESC: A recent Scottish Programming Languages Seminar had some interesting talks on typing... ----- BODY: One of the things I miss being at a smaller school in a less densely populated part of the country is the ability to go to stimulating research talks on a regular basis. When I was at Michigan State, I could go to a good talk in computer science or a closely related discipline frequently, if I had the time and inclination. It's hard to create that sort of environment at a school the size of UNI. One of my goals for the department this fall is to create a seminar series that draws on the research our faculty is doing, as well as research and scholarship being done at the many other schools in Northeast Iowa. I don't know if we have a critical mass of audience to sustain such a series, but I think that it's worth finding out. In the meantime, following other people's involvement in research talks is one solace. Andrew Birkett recently wrote about attending the Scottish Programming Languages Seminar held last month. Just reading his summary stimulated my mind a bit... One talk described an attempt to measure the productivity difference between static and dynamic languages, toward which Andrew was skeptical. I am, too. The difference between static and dynamic languages is at least as much one of culture and habit of thought as it is of language and tools.
When you use a dynamic language, it's not because you have a masochistic enjoyment of finding statically-findable bugs by hand. It's because you enjoy a much more flexible overall programming experience - different toolset, and better support for "exploratory programming" as you learn about the problem domain.
Measuring differences in productivity across cultures is tricky. In my experience, folks just end up scratching their heads at the other camp and thinking, "But that's not even a part of my universe." That said, I would be interested in evaluating an attempt to tackle this hard problem. Another talk centered on the notion that the purpose of type checking is, at one level, to distinguish 'good' programs from 'bad' ones, for a particular definition of those evaluative terms. In the usual sense of static typing, good programs pass the type checker, and bad programs do not. The presumption of strongly, statically typed languages is that the first step toward being a good program is passing the type checker. This presumption can get in the way sometimes. I remember my frustration when learning Haskell: I would write a mutually recursive function that executed correctly for all inputs, but the Haskell type inference system refused to accept the definition because it could not infer the types of the inductive data elements. Writing those type definitions by hand proved difficult or impossible. (Don't take this remark about Haskell out of context, though. It is a very cool language that can change how you think about programs -- definitely worth the energy to go learn it!) Defining 'good' and 'bad' programs in terms of passing a type checker is potentially a very fine thing to do, but it has important implications for how programmers think about programs and programming. What if we decided that the first step toward being a good program was something else and then designed a tool to enforce that notion? Programming might be quite different! In a sense, I think that test-driven development is an example of just this sort of thing. Passing a test is more important than making the type checker happy. Working in dynamic languages such as Scheme can feel that way, too -- the emphasis is not on types but on passing test cases. The talk that raised this idea about type systems went on to describe an interesting idea: creating a type checker that blends static and dynamic checks. The checker infers as much as it can statically and then leaves the rest of the type checks for run time.
And then you can either go back and tweak your source code to provide more information, or you can go ahead and run your program, knowing that some properties have been checked statically (i.e., they are true for all possible runs of the program) and some will be checked dynamically (i.e., the program will terminate if a properties is discovered to be false).
If Haskell had this sort of flexibility in its typing system, then I would have been more inclined to use the language as more than a learning and research vehicle. Now that I have mentioned Haskell a couple of times, I will close with one last comment from Andrew, about another of the talks at the seminar:
The formal side of this talk was a little bit beyond me. I have to concentrate when people discuss Monads formally.
I have to admit, with some sheepishness, that reading papers and listening to talks about monads have always made my head hurt. I don't know if this situation can be remedied by the right sort of practice, or if it is merely a sign of my fundamental cognitive limitations. In either case, I'm content with my state for now. -----