Lambda the Ultimate

Is how he doesn't wrap those boolean true and falses into first-class signals. Mouse up and mouse down is a pretty stable model, until you suddenly have to mock up multi-touch devices. Now you've hardwired throughout your code references to booleans, when you'd be better off with an enumerated data type or union construct of some sort.

So even Erik's good API has design bugs in how he is using it. His analysis isn't object-oriented, that's why. That's something Sean McDirmid got right with Bling: he wraps all the primitives like double with first-class objects he can expose as signals.

_

Multi-touch devices are not the same as mice. [...] He isn't designing to handle all sorts of devices, just the mouse.

That's what Z-Bo is saying.

His design isn't flawed and does not have design bugs.

I don't know enough C# to really comment, but supporting only mice in today's world would definitely be shortsighted.

In C#/WPF, there is a completely seperate set of events for handling multi-touch. They include things that make absolutely no sense for mouse events like how large the finger/hand touching the screen is.

Your abstraction you are testing against should not be a stream of zeroes and ones. This is not a register adder we're mocking. It's a stream of signals, MouseUp and MouseDown.

Moreover, there are no semantics for the true and false. It makes use-site maintenance more difficult and subject to mistakes.

With a multi-touch scenario, this design flaw becomes obvious, because you can't simply use true and false. Jonathan Allen already did a nice job explaining the interface exposed by modern GUI toolkits for multi-touch events.

In WPF, there are a lot of basic primitives that aren't wrapped into types the way a Haskell programmer might ordinarily model a problem - by introducing new types to describe an abstraction they are working with. In WPF Bling, Sean McDirmid's library, he wraps those primitives so that you aren't working with them directly. Instead, you're manipulating expression trees that use those primitives.

BTW, just so you are not confused: Yes, Multi-touch and mouse are different and separate. Multi-touch devices are not the same as mice and use separate input sensors. If you want to simplify testing of both, then you should define verbs that explain what a multi-touch device event stream maps to, and what a mouse gesture maps to. The verb is then the interactive "tool" to the underlying model that executes your application logic.

To be honest, I haven't done much with events in Bling yet. Ever since writing my thesis, I've thought that dealing with continuous states (e.g., IsMouseOver) is better than dealing with discrete event streams (OnMouse[Enter/Exit]). But I find myself writing code like OnMouseDown, Capture Mouse, register temporary OnMouseMove and OnMouseUp handlers (BTW, this is made easy in Bling) that implement my custom drag behavior and uncapture/release the mouse when done. I'm trying to abstract this behavior into a more high level "drag adapter" with more continuous semantics (to varying degrees of success). Perhaps a more general discrete event stream abstraction is needed (something like the Reactive Framework)...

Multi-touch really is similar to single-touch, you get your contact event, you capture the contact, capture move events, and release the contact when contact up is reached. The difference is that you could have multiple contacts active at the same time, and you get some optional camera information (how big is the contact, what is its approximated geometry?). Having a physics engine as the basis for your UI really helps with multi-touch, as it can gracefully/transparently deal with the multiple contact problem. In general, physics engines and multi-touch go together really well, so you want to consider physics abstractions along with multi-touch abstractions together.

The first method to handle mulit-touch in Windows development is to simply treat it as a mouse. When using this method, what he has will just work.

The second method is to use built-in user controls that already understand multi-touch. WPF and Silverlight are the primary GUI toolkits for that right now.

The third method, the method of last resort, is to specifically handle multi-touch events. This is non-trival because you have to figure out what the heck you are going to do with all the information you are getting. You no longer get a single points and a couple of flags, you get a set of rectangles and locations.

It's a short video(around 10 minutes). It's not the whole video of his talk. His quote is around the 8 minute mark. He mentions getting test values from something he owns (a collection he created himself) rather than from some other process. I don't actually see how that's not using the same concept as mocks though.

On the GOF book, he is discussing the patterns of Iterator and Observer, and that they ought to be intimately related but are defined (in Java) separately so that they do not pair off together.

Regarding mocks, he is using LINQ to turn interactive events (mouse moves) into a sequence of event values. The app code then observes the sequence and consumes the events. Instead of mocking the interaction, he can just create an array of test values and make them into a sequence with the same interface. Seems like a very clever abstraction layer.

We've been doing his approach to mocking for years now.

It's called using robots to automate interaction. In .NET, this is called Automation Peers: objects that are on the same level as the interface you want to test. The robots actions are your event stream.

Dependency injection, in the context of mock objects, is really just a way to configure your test suite. There's nothing to criticize here.

His comments about Java's core libraries being terrible from an unnecessary boilerplate perspective are fair, though. Java-land will never take me back alive, and I estimate I'm more productive in .NET. And happier.

I also don't think he called GoF crap, so much as criticized how GoF mentions patterns are related, but doesn't actually study how the patterns are related and can be used to construct elegant APIs. This is a positive reaffirmation of Erik's flame. GoF really does a poor job at this, and as a result the books main message -- prefer composition to inheritance -- is lost because all the patterns seem to stand by themselves rather than work in conjunction. More broadly, IEEE journals tend to publish mathematical articles proving formal properties of certain patterns. Erik's recommendation that everyone use category theory to do this, and showing why, is pretty nifty (and arguably convincing).

Apart from that, he also says GoF doesn't say Iterator and Subject-Observer are intimately related. That's sort of true. Iterator's "Related Patterns" section says Composite, Factory Method, and Memento. The problem has more to do with vocabulary. In GoF, the subject-observer pattern is bifurcated into push model and pull model (page 297), and iterators are bifurcated into external iterators and internal iterators (page 260), and there is no discussion of lazy evaluation. That's the key concept, in my opinion. It goes back to the essay "Why Functional Programming Matters" by John Hughes. Hughes paper was the first paper to really disect how to elegantly break apart producers and consumers in a modular fashion.

To be fair, GoF opened up discussion of such topics. These criticisms are easy to say in retrospect; they really apply to work built on top of it.

The bifurcation between the algebraic+categorical approaches and the pattern languages community is depressing. Perhaps that's because we still can't do much in this domain, even in research.

it does make me wonder, when people toot their own horns about how great their application of category theory is to a given thing, how more widely applicable it is. like, appreciate it when it is relevant, but it sometimes sounds like "everything looks like a nail" then which is counter-productive. any thoughts on where to read up on when concretely to use and when not to use in particular category theory?