Model-View Catharsis | Hacker News Reader

Model-View Catharsis

acko.net

I had the impression that much time and thought went into this post but unfortunately I couldn't make it much past the beginning. I think I'm not much interested in mixing reading for pleasure and reading for learning, and when I'm reading for learning I just want to the post to get to the point.

I had the same experience. I ended up bookmarking the site, thinking that I could reference it the next time I wanted to formulate an argument about the problems with MVC.

It would help to have a conclusion or abstract somewhere, listing the main points that the article makes, so that I have a way to know where to invest my attention when reading it.

I have to agree that it's a difficult read, and I'm someone who has done a fair share of looking at these different architectures.

But the broad-strokes recommendations seem approximately like these things I would say(which are not exactly the things the author says):

* Some things are best done in an incremental fashion rather than a big "update"

* You often need to copy state in your UI code

* It helps to focus on building explicit synchronization points(which I turn to FSMs to do)

* Modelling abstract cursors on data is a helpful UI idiom

I had trouble following due to the cloud of snark and attempted wittiness.

The MVC pattern is basically what you end up with a naive implementation of a GUI interface. A more sophisticated solution is the plugin pattern where independent code can "plugin" by for example listening on events. It's kinda like MVC but backwards, instead of a button updating the view, the plugin/view listens for button-clicks. And if a server is involved, the view/plugins should listen for events sent by the server. Where each little plugin/component do it's own thing independently. If you for example have a "new messages" badge that shows both new messages and new chat messages, it should listen for new messages and new chat messages!! versus the spaghetti-strategy of having both the messages model/widget and the chat model/widget update the new-messages widget.

Yeah, and that’s why most of the message passing interfaces struggle with race conditions.

In addition to the tone it was distracting that as I read images would appear behind the text.

I'm actually interested in principled criticism of weaknesses of the MVC model (I've been a fan for decades). Anybody have a good link?

The criticism is pretty succinct:

1) No one agrees about what the Controller does 2) As a result no one knows what should make up the Model 3) Therefore this leaves the Views in a real bad state

Oh, thank you for summarizing these points for us! These are very good points to make, indeed.

Thank you for extracting that!

I don't know about the component state on the web, but from my perspective I think that is backwards. As I said I'm not a web developer, but for me those terms are meaningful this way:

Assume I have a program for designing aircraft jet turbines.* It uses a parametric model that lets you specify shaft length, blade length, combustion chamber camber, etc. It has its own constraint system that doesn't let you put 10 meter blades in a 4 meter diameter housing. Etc. I have a whole little set of operations (these days called a DSL) that allow a programmer to manipulate the model using the vocabulary, metaphor, and mental models of a typical jet turbine designer.

That is the M in MVC.

I also have a library of routines for drawing parts of the turbine on the screen. They themselves are parametric with orientation, zoom, etc. A set of view parts -- the V.

Finally I write a little window that displays a turbine with some mouse gestures and the like that allow me to zoom, rotate etc. Maybe point and ask questions.

You might write a different program that does the display on an ipad, calling from my set of Views to fit your interaction model. You won't necessarily need to know much about turbines, frankly, as my model should give you all the affordances you need.

After reading your great note, I went and read a bit from the article and it seemed that the author is entirely in the display -- in the "C". Elements like a user name (let's say a part number in this example) aren't so much as model items -- high level abstractions, but simply inputs. To me the model is the program domain model. To be forced to take the same approach with mere UI widgets is cruelty indeed, and perhaps that's the author's argument?

* obviously nobody would write such a program this way; this is expositional

I believe it is not worthwhile to treat MVC as a pattern to emulate: http://beza1e1.tuxen.de/model_view_controller.html

I always felt that the paper 'Twisting The Triad' laid out the case for Model-View-Presenter (and evolutionary step away from MVC) was a strong, well reasoned paper against your traditional MVC style of programming.

http://www.object-arts.com/downloads/papers/TwistingTheTriad...

Thanks! Reading it now...

So the writing is really ornate but one thing that stood out to me

> 1px wide gradient edge

wtf is a 1 pixel gradient?

I assume the gradient would be along the dimension that isn't 1px, ie the line length.

1 pixel gradient is an old games/graphics trick.. Define an array of pixels, but only one "row".. match the length of the array to the dimension desired, then use the graphics primitives in the window to stretch and fill.. (here, a picture is worth a thousand words) think of a To-Be-Defined rectangular area, and a gradient that is mapped to either the x or Y dimension, and "stretched" across to make the rectangular fill.

Reply on news.ycombinator.com