« Coverage in Production: Learning From Your Code's Liveness | Main | Making Too Much of TDD »

December 14, 2010


Tracy Harms

What I liked best was his talking about a problem of documentation. This is familiar to me as especially strong with APL and J: the things that are conveniently unstated when writing are inconveniently missing when reading. Help for future readers naturally gets recorded as comments.

Mark Wilden

This guy obviously never heard of method_missing.

Jason Diamond


He seems like a competent Ruby programmer. I'm sure he's heard of, and even used, method_missing.

A more important question is: what percentage of *your* classes use method_messing? My guess it would be a very small percentage. The rest could be statically typed. And that, I believe, is his main point.

Even though I'm a fan of dynamically-typed languages, I can really appreciate the guarantees that static typing offers. I just don't like it when those statically-typed languages don't let me do something dynamic.

C#, a statically typed language, recently acquired the dynamic keyword which allows you to opt-in to using a feature like method_missing on a variable-by-variable basis. The majority of your application is still statically typed. For the very small percentage of objects that need dynamic typing, you can get it.

It's still nowhere near as dynamic as Ruby, but how often do you need to be *that* dynamic? Very rarely, it seems.

Mark Wilden

@Jason: He's talking about code generation at load time, and he says that this isn't really very dynamic at all.

method_missing is (usually) used to do code generation at some point during the run time, and is not simply a way of typing "def" as he says. Instead, it's (often) used to create functionality based on the runtime behavior of the program.

No, it's not used very frequently, and where it is used, it's mostly in libraries. But I believe it's Rails' (and RSpec's) use of method_missing to generate methods dynamically that's made it so popular, which in turn has made Ruby so popular.

The "guarantees" provided by static typing are not worth the cost, IMO. In my C/C++ days, I never seemed to find myself passing a struct to a function that expected an integer too often.


Michael, I like the idea of using production runs to type code. However, here's the thing: why do we assign types to our code? "To know what it does" breaks up into two sub-reasons that I can identify:

1. when first writing code, it helps speed up development and makes it easy to define the general structure of our idea; if our structure sucks then the type checker will find out
2. when maintaining code, it helps ensure that no one does something stupid that would change the way a lot of our code works. An example is if we have a program which accepts data, processes it to strings, and then does a lot of manipulation on those strings; then prints them.

block of data -> process into strings -> work on strings -> print string output

For example, calculate the frequency of strings, do some heavy stats on them, and then print them out.

At some point we have to fix the fact that in some huge file the back end crashes and change the input back end to spit out (Int, String)to get the line number that string was on in the file. Instead of String and now half our application is not passing around (Int, String) and the front-end doesn't accept that anymore for printing.

In this situation you would see that the front-end is not adhering to a specific type and you might be compelled to change the front end; this is not the whole story however and the fix is probably to change the back end, given that the processor doesn't care about the line number anyways.

This can be aided by some sort of meta SCM with knowledge of the language it's storing; it could tell you how many of the inferred types have changed between two revisions; if it's, statistically seen, too much (noticeably more than the average) then it could mean trouble; probably something you might want to fix.

The SCM would need to understand the structure of the language and keep track of the types. Not trivial -- but not too hard if you're into this sort of thing. A lot of people write parsers in "FP" languages so "FP" languages with type inference are more likely to get this sort of solution.

The comments to this entry are closed.