Re: Embedded DSLs and Productivity
Posted: Apr 11, 2006 6:01 PM
> (Apologies for this piecemeal reply.)
> Bill Venners For example, if I have a method that takes
> three Strings in a row, sometimes I might get them out of
> order. That happens now and then too, and since it isn't
> checked at compile time, I find out at runtime (or unit
> test time).
> Let's look at that: we seem to be saying that these 3
> method parameters don't mean the same thing, and we
> haven't captured that difference. One response would be to
> eliminate the mistake. Let's define 3 wrapper types
> that each hold a String and now we can use the compiler to
> check we are using the parameters appropriately.
Perhaps, though you should do a cost/benefit analysis. Having three wrapper types increases the surface area your API, and increases the code to call the method, which are both costs to get at the benefit of static type checking. And to an extent you have just moved the problem. I could still mix up the strings I pass to the constructors of the wrapper types. Whether or not this is worth it depends. One thing I try to do now is use enums as much as possible, which can solve many of these problems without added API clutter.
> We might characterize the Smalltalk response as let's
> reduce how often you'll make that mistake by using
> the method name to label each of the parameters, like this
> copyFrom:to: (we can find the parameter naming approach in
> some other languages, Nice.)
I don't understand how that works in Smalltalk or Nice, but I think trying to figure out how to eliminate the class of bug instead of just fixing the bug is a great strategy.
> I think the more useful way to ask this question is how
> many errors does static type checking help you find that
> you don't find via unit testing, or quickly via plain old
> testing, using a non-static language such as Python, Ruby,
> or Smalltalk. I find that static type checking catches all
> kinds of problems, but the question is, is it worth the
> added programmer pain compared to dynamic alternatives? My
> feeling about that is that the answer depends on the
> Yes, it depends on the context - and that renders the
> interminable context-free quarrels futile. (Can we say how
> much an acre of land is worth without knowing where it is?)
I think it isn't futile if we move the debate away from which is better, to when each is better. I don't have any experience building big systems with dynamic languages, just minor scripts. When I hear people like Dave Thomas, Martin Fowler, David Heinemeier Hansson, and Bob Martin suggesting scripting languages scale much better than static typing enthusiasts believe, I take notice. They are smart guys, and I can't really afford to be slowed down by static typing for applications where it is overkill. I'd really like to hear about real-world experiences building big systems with dynamic languages. I've asked about that before in the forums here, but haven't gotten anything very compelling back.