OOPSLA Day One

My notes from the tutorials I attended on Sunday.

Dependency Injection in Dynamic Languages

Miško Hevery and an uncredited cohort named (I think) Coery, who seemed to be the Javascript expert.

DI can make large programs in dynamic languages more tractable. The same argument holds as for static languages: "wiring/construction" and business logic are separate concerns. By separating them you make the code easier to read and modify. Sometimes, when people say dynamic languages don't scale to large programs, they really mean the way they're written.

The example program was tic-tac-toe in Javascript. Even this small application had a main method that was starting to get out of control and consisted mainly of wiring. The DI version reduced main to essentially one line.

It turns out that DI is not all that hard to do in a dynamic language.

  • You choose what you're going to use as your "lookup symbol". This could be a string or it could be more sophisticated, approximating the type information you would get in a statically typed language, such as a Java interface.

  • You implement a chain of "providers", each of which knows about one kind of dependency resolution and delegates to the next if it doesn't know how to handle the request. At the end of the chain is a dummy provider that just errors out.

If you're building your own DI, can build custom providers specific to your domain. In Javascript, for example, it makes sense to wire listeners, so that the boilerplate code that usually is required falls away.

In the tutorial, they wrote a simple, short DI implementation in a couple of dozen lines of Javascript, test driven using the neat JsTestDriver framework.

Functional Programming in Object Oriented Code

Phil Goodwin gave this talk.

You can, with enough effort, use almost all features of functional programming in Java.

I found the ideas of how functional ideas could be incorporated into OO code thought provoking. OO and functional complement each other: one's weaknesses are generally the other's strengths and vice versa. Taking an idea from Bertrand Meyer, you can use commands to change things (OO) and use queries to find things out (functional).

Functional programming means reversing one common workflow in OO programming. In OO, you look for case statements and consider replacing them with polymorphism. In functional programming, you remove polymorphism in favour of explicit case statements. However, these case statements are much more agnostic about what types they work with.

(The example library is written in Java. A brave choice because, in many ways, Java is terrible for functional programming. Functions are not first class values (and it's hard to fake it). The type system is concerned about values, whereas functional programming languages are more concerned about the type of the functions. (Besides, the lack of type inferencing makes nesting of types painful and functional programming is all about nesting.)

The Google collections framework is a helpful starting point: you get the hooks with which you can use filter/map/reduce, etc..

Implementation: you can avoid blowing the stack using a trampoline to provide tail recursion removal and continuations.