Thursday, October 26, 2006

The last OOPSLA keynote: Philip Wadler

So there is this guy with a Lambda superman suit talking about stuff... what is this stuff? It certainly tickles my curiousity! Well, I have been exposed to the type system in Haskell. And, in addition, I have been exposed to generics in Java. Both of them are based on lambda calculus, which is types for natural deduction.

Hmmm, to summarize, generics in Java is incredibly verbose and, according to the presenter, even cumbersome. Enough said about that.

Haskell's type classes are, as I understood them, a way to pass a sort of "method dictionary" so that type inference works. However, the type inference breaks when not all sends are "monomorphic". Well right, if all sends are monomorphic, then types are essentially method lookups --- hence my previous claim that good type inference engines are hard to come by*.

What struck me again, just like with the experiment I did yesterday, is that you can think about typed lambda calculus all you want and that's fine... but you should never explicitly write any of it down. Just the sheer amount of typing and manipulation required to prevent, say, comparing apples to oranges, is disappointing. Because if the problem is that the comparison does not make sense, one should not do it --- period.

Even from a pragmatic point of view, what are you going to fix? The type declarations to prevent the comparison if and only if you run into the particular problematic scenario, or think of issues when you imagine what could possibly go wrong before anything actually happens? I do not think this is particularly productive because we all have known many a great problem, most of which did not occur.

Incidentally, doing refactoring work on type classes is, according to the Lambda guy, nearly impossible. Hence, cost of change is high even with type classes.

So, to me, it comes down to two paths so far. You can try the guessing and adivination game, or you can just fix the bug if and only if it occurs, or as shown by functional testing. Currently, I feel I am more productive with functional testing, so that's what I choose for myself.

However, I wish there was some proper research done to clarify this issue so this decision can be made more rationally. Alas, according to the Lambda guy there's no scientific research available to answer this question properly once and for all.

So, given the material available to me at this point, I have to fall back to my previous position. I can use all that in my head, should I choose to do so, but there should be no explicit manifestation of such artifacts.

As I close the lid of the laptop, I cannot help feeling that types, described this way, remind me too much of the "warning a baby could drown in this recipient if it is filled with water" labels printed on 5 gallon buckets.

Then again, as far as Haskell goes, it is certainly a huge improvement over Java.

* I have a feeling I might have gotten this wrong somehow the first time, please excuse my trying to take down notes as the presentation is still going on. I wish I could have updated this sooner, but Wifi had gone down after a power system failure that tripped the fire alarm and caused everybody to end up on the street.

Update: I changed the title because I didn't choose the first one very well, and reworded a couple things that did come out to reflect what I intended. Please excuse the mess :(.

No comments: