Re: The DCI Architecture: A New Vision of Object-Oriented Programming
Posted: Mar 22, 2009 12:51 AM
By the way, Jim, don't take my rant personally. However, I'm trying to get you to think clearly.
If you are going to present a solution to something, you actually need to describe:
(1) what the problem is
(2) what contributions you can make
(3) experimental results, including prototypes, field studies and project data
More importantly, practitioners have a hard time relating to abstract concepts when there is no connection to a real world problem they have.
By presenting the strawman that "programmers just don't get MVC, but it works", you're basically saying all we really need to do is use something correctly. At which point, I'm wondering why the rest of the article isn't focused on teaching it correctly.
Instead, the article diverges and becomes a sermon about how we've all overlooked some practically fundamental architectural concepts -- "traits", if you will.
Actually, in my 14 years as a programmer, my biggest benefit to an architecture that includes a GUI is what I call the designer-developer facade. Pretty much every system I've seen others build gets this facade incorrect, because once you have to dynamically vary the UI -- for any reason -- you take the design tools out of the designers hands and force him/her to describe the interaction effects to a developer. This doubles resources, and frequently the developer is untrained in how to program complex reactive systems where arbitrary events can occur. As a result, copious bugs pour in. The end result is frequently event handlers with ad-hoc case statements.
There are a few exceptions. For instance, the best selling video games Crash Bandicoot 1 through 3 were architected by one of the top 5 Lisp programmers in the world: Andy Gavin. After several iterations, it was stratified into two main subsystems: a Lisp language for game engine subsystem programmers and a DSL for artists and scene designers. More recently, two members from that 9 person video game company (including cofounder Jason Rubin) started a dotCOM called Flektor, which embodied much of the same principles.
So it is possible to create a designer-developer facade.
But you fail to tell me how to do this (I know how, but just follow me).
And, actually, your traits don't tell me anything about temporal constructs, which is a fundamental element of reactive systems and composing a realistic user's mental model.
Your traits also give the appearance that you're creating mini-classes to provide ad-hoc case statements. The only difference between your classes and an ad-hoc case statement is that you've got type-checking; you've added a little bit of structure. In fact, Odersky recognizes this by providing a switch statement on steroids that can do structural pattern matching. However, you don't explain why that incremental structure improves code clarity, testability or conceptual design.
You also neglect that a parts-centered object model gives you stronger compile-time type checking for what you are trying to accomplish than a specialization-centered object model, hence why you mentioned trying to avoid traditional class inheritance. However, all you do is provide extension methods with a friendship relationship to a class. That's not an awful thing, and the C++ Client/Attorney idiom can be used to good effect, but it is an implementation detail far apart from the architectural level that MVC addresses. It's also far apart from the level of abstraction of considering a system with an architectural constraint of a *pure* developer-designer facade.
Pure abstractions are much harder to design than pure functions, but they give us the ESSENCE Brooks' talks about. Yet, should these abstractions change at the architectural level, they are changing to reflect real world realities. If the roles of designers and developers change, then they will likely change in ways that allow each person at opposite ends of the role the least amount of grief possible. For that reason, you stabilize design around that architectural constraint, not MVC or DCI.