qaexl

Hmm. Maybe? Seems impoverished to me.

Someone on the comments for the original article said, the big idea in Rails wasn't so much MVC as much as separation of concerns. I'm on-board with that. Thinking in that way has brought a lot of advantages for me over the years I've been working with Rails.

By extension, if the big idea is "separation of concerns", then I should be applying it in my non-Rails code too, whether that's "MVC" or not "MVC". In fact, my small taste of functional programming allowed me to play with "separation of concerns" in a different coding style, one that I've imported back into the Ruby code I write. Write functions without side-effects. Treat data as immutable. Interesting times.

Agreed. I can't find any insight or advantage in making this kind of a distinction.

The article attempts to address it by saying that people attempt to implement Model2 on a Javascript front-end. That is awkward. However, it isn't awkward because you should be using real MVC. It is awkward because Javascript is asynchronous and you want to make sure the user interaction stays responsive without devolving into spaghetti. The key insight is "asynchronous" rather than "let's do REAL MVC!"

I've seen this obsessive focus on taxonomy of solutions divorced from specific problems in domains outside computing. I suspect it's a cultural thing. Some cultures obsess over gadgets more than others. That works out until people start arguing about who has the shinier toy, instead of actually using said toys as tools.

+1. This is useful for me.

I'm observing some people trying to break into technology. Yes, there are online tools available. Yes, many of them are free. One of the complaints I hear is that the target platform you choose moves so fast.

Generalized, it means software -- the technology and the economy -- runs at a higher tempo. In order to step into the stream, you have to first match the new tempo.

I suspect that the rest of the economy stays in a slump because they are out-of-phase tempo-wise with software technology ... or that the tools that drive up the tempo of innovation in software has not made it out to the mainstream yet. (And even if it did, it will leave people behind simply because there are people who will refuse to impedance match).

Funny you should mention that. Right after you talked about shapes, I browsed through Sensei's Library and saw that too. Thanks for the recommendation.

:-D

I'm glad you said something about shape. It's something I'm stumbling through right now.

See (4) about unconscious incompetence.

You ever played Weiqi? (Otherwise known as Go).

Unlike chess, stones don't move once played. They can only be captured. On a 19x19 board, you have to balance short-term gains with long-term gains. Since there are no left-right or top-bottom orientations, you often have to reimagine where you draw the lines of territory as you play. Sometimes, you can kill your shapes by playing too many stones. Better players can see where things will go, identify "dead shapes," and stop wasting time trying to rescue them. Sometimes you trade off bad moves for bigger gains. Sometimes you simply have to work with mistakes you made in the early game.

This is very much like writing code and getting it to market. You're trying to build something despite disruptive opposition even as the clock winds down.

I got it for my iPod Touch. From working with it, I'd like to use it on the iPad.

I don't remember. I'm not very good at writing posts that get a lot of upvotes. You are more then welcomed to try -- this app can get all the marketing help it gets.

I'd upvote this comment if I could.

Edo,

You ever practiced something like Tai Chi?

I've had similar, fleeting thoughts brewing for a while. Seeing this stated together like this crystallized it. Thanks for sharing.