Compound Thinking

Framework Comparison Video

Sean Kelly has posted an interesting comparison (warning 60 min video!) of Rails, TurboGears, Django, Plone, and Java Sevlets/JSP, and full fledged J2EE development.

There is a lot of interesting commentary on this movie floating around out there, so I thought it might be worth while to try to gather some of that commentary in one place.

Overall, I think the message of the video is: The “Dynamic Language Frameworks” are all demonstrably better than their Java counterparts for web based application development. These frameworks allow you to make small incremental changes to the user interface as you test your ideas with real users.

And this conclusion is exactly right — user interface design is hard, and it requires the ability to iterate and deploy incremental improvements.
But before I move on to other people’s commentary, let me say a couple of things from my own perspective:

1. Plone rocks for a certain set of problems, which it can solve out of the box.
2. Sean uses TurboGears 0.8. Had he used the newly released 0.9 he would have been able to get authentication and automatic CRUD. Someone made his application with something like 9 lines of TG 0.9 code! :)
3. Rails and Django also have internationalization frameworks now too (For those of you where this is important, I think Django and TurboGears do internationalization better than Rails because of Python’s Unicode support).
4. His application is pretty trivial — a real test for these applications would look better for the TurboGears framework.

On the web people have been saying (I’ll do my best to be complete, and get the attribution right):

• He’s very kind to Zope/Plone, if you step out of the Plone box then the cliff is indeed there but if you stay inside Plone everything tends to look like Plone and act like Plone and that isn’t that useful. That said, I’m sticking with Zope. — Simon Lucy
• This Lessig-style presentation is mostly good, especially if you want to compare J2EE to web frameworks in general… it clearly shows how using any of these frameworks will drastically decrease your development time and lines of code, and generally make your life a lot more fun. — Jeff Croft
• I should point out, though, that his version of Django was a little outdated, and his impressions of it had a few inaccuracies. Django’s got excellent i18n support, and for a while now it’s been able to use it without a database. Still, as long as someone’s not using J2EE, that’s a win for all of us dynamic-language freaks :) — Jacob Kaplan-Moss

My complaint (and it is a minor one) is that Sean seems to get a lot of things wrong about TurboGears, Django, and Rails, so it’s not very good at providing insight into which of these frameworks is going to be the best fit for your particular needs.

Most of the problems I have with his analysis stem from the fact that these three “dynamic language frameworks” are growing and evolving very quickly.

TurboGears, Rails, Django, Plone, and Zope 3 are building the future today. I’m most connected with the future of TurboGears, and I have to say that the changes that are coming present a lot of exciting possibilities. If this is any indication of what is happening in Django, Zope and Rails, then the future of Python web development frameworks looks very bright indeed.

Ruby on Rails class

The folks over at the Ruby users group have decided to hold a Ruby on Rails class for free. Patrick Hurley will do the heavy lifting for the class, and Humantech is supplying space for us to use for the class. Patrick has significant Rails experience in real-world enterprise deployments, and I for one am looking forward to hearing what he has to teach.

The class is scheduled for the afternoons of Saturday, March 11 and Saturday, March 25.

If you would like to enroll in the class all you have to do is:

1. Go to Compound Thinking’s course site
2. Click on “Ruby on Rails”.
3. Create an account (if you don’t have one already!).
4. When prompted for the enrollment key, enter “rubymi-222″.

For now at least, this class is Ann Arbor–In Person only.

The first 25 people to sign up get in, so even if you sign up, you might not get a seat, since I have to close enrolment manually when the class gets full, but if you do enroll, and we don’t have room, I’ll let you know as soon as possible.

MVC, Smalltalk and the Web

So, I’ve been writing the MVC paradigm recently as part of the TurboGears book, and the process has been interesting. MVC has a long and illustrious history, and it seems like it now has as many definitions as there are are books/articles that discuss it. There are a million MVC based frameworks out there, from TurboGears, Rails, Struts, and WebObjects, to Cocoa. And the frustrating/interesting/enlightening thing is that each of these environments implements MVC slightly differently, and those differences reflect significantly different understandings of what is core to the MVC paradigm.

My quest for a unified explanation of MVC lead me back to the original SmallTalk implementation which was codified in Smalltalk-80. But that adds another layer of complexity to the problem of describing MVC, because Smalltalk-80 controllers did things that are now taken care of entirely outside of all of the modern MVC frameworks. For example, the controller was responsible for dealing with keypress and mouse click events — and doing something sensible with them. Now days the OS, and drivers, and window-managers take care of all of that, leaving a Smalltalk-80 controller without much to do.

And that, I think, is one of the key reasons that MVC has mutated so much over the last dozen or so years. The original architectural pattern was created to — among other things — solve the problem of where to put all the event-interpretation code that is necessary when your code is directly responsible for dealing with user input events. Now that we have mouse drivers, windows management systems, and a whole layer of GUI abstraction code between our users and the events there isn’t anywhere near as much need to keep “controller code” partitioned off in it’s own corner.

Another key component of the early version of MVC in Smalltalk that is different than what we find in “modern versions” is the observer relationship between Views and Models. In the original design views either poll, or subscribe to, models and automatically change what the user sees whenever the model is updated. But at least with web based MVC is that it is no longer feasible (well, at least until Ajax came along). So, as a sort of natural evolution, Controllers gained responsibility for sending status updates first to the model after a user event, and the also for telling the view to publish that updated data to the user.

This is natural, and sort of sensible, because much of the complexity of Smalltalk-80 style controllers had already been abstracted away, so it’s not really that painful to add a bit of “glue code” to the controller. So, anyway you can trace the history of this evolution through Objective-C, and NextStep, to Cocoa, WebObjects and Struts. With the controller being seen increasingly as “the glue that holds models and views together” in addition to its original purpose as “the code that processes user actions.”

OK, so given that this evolution has taken place, how is that reflected in all of the new “full-stack frameworks” we are seeing today.

I’m only deeply familiar with TurboGears and Rails, and both of them allow you to use model objects directly from your View code, so they are somewhat more like Smalltalk-80 than their older brother Struts. But, rails goes further by making it trivially easy to call Models from your view — everything is even magically imported s all you need to do is call the objects. TurboGears has so such magic, so if you want direct access to your model objects you have to import them (which is a single line of code). But it is often easier to just have your controller pass a dictionary of all the data you need into the view when it is called.

This is also a clear reflection of the Rails “convention over configuration” philosophy informing David’s view of MVC, while Python’s “Explicit is better than implicit” philosophy informs Kevin’s interpretation of the “same” design pattern. It’s hard to say which is better, but my experience was that it was really, really, really easy to do easy things in Rails, but then I had to figure out “how the magic works” before I felt comfortable venturing out from there. TurboGears, on the other hand took a little longer to get started, but then the learning curve was comparatively easier for moving on to more complex stuff, because everything was visible and I knew exactly where to look to find out more about how each of the pieces worked.

Ruby and Python (Can’t we all just get along?)

Over on Loud Thinking, David Hanson creator of Rails, seems pretty frustrated with Bruce Eckel’s recent blog post about Ruby, Rails, Python and Tate’s Beyond Java book.

“I’m losing track of the ill-conceived comparisons, but I do know what’s astoundingly clear: Bruce Eckel doesn’t like Ruby, he doesn’t like the attention its getting, and he doesn’t like people such as Bruce Tate fueling that attention.”

Bruce isn’t a huge fan of Ruby, but he doesn’t slam it either. So he does have some critical things to say, but on the other hand, here are a few quotes where he praises Ruby and Rails:

Clearly Ruby is making important contributions to the programming world.

Rails approach isn’t the ultimate solution; there will be plenty of other problems that we need to solve on the way to making web development easy. But it represents a fundamental restart in the thinking process.

He does however criticize Tate’s Beyond Java for announcing Ruby to the be the successor to Java without considering Python in any depth. And from what I can tell this is a reasonable critique of that book.

I know that a while ago on the Ruby list there where some quotes from one of Bruce’s posts which were not favorable to Ruby. And there might some bad blood from those quotes. But that post is no longer available in it’s entirety, and the only thing left is a few out of context quotes on the Ruby mailing list.

So, as far as I’m concerned the Ruby folks should get over it, and start engaging Bruce in a reasonable dialog. Especially since his current stance is that Ruby is nice, but he’s not yet convinced that there’s enough benefit to switching to let go of the advantages (and yes there are some!) of Python.

Bruce Eckel on Python and Rails

Over on Artema.com Bruce Eckel reviews Beyond Java and is somewhat critical of the way that Bruce Tate jumps on the Ruby bandwagon without considering the merits of other languages, and python in particular. I agree that a book like Beyond Java ought to be looking more deeply into the future alternatives before declaring a “winner.”

And while Ruby has a lot going for it (blocks), so does Python (mature libraries). I hope there is room for both in the post-java-as-a-tool-for-every-conceivable-job world, because I really like both languages.

Bruce also brings some much needed perspective to the Rails hype:

I’m sure we will find that the Rails approach isn’t the ultimate solution … But it represents a fundamental restart in the thinking process.

In other words, Rails is light-years better than what came before, but it isn’t at all likely to be better than what comes next.

And as far as what comes next in the Python community, Bruce has this to say:

And [Rails] has caused, in the Python community, attention to Django, the development of Subway (although I don’t know how that one is faring), and the creation of TurboGears, which seems like a very good solution because it builds on best-of-breed existing pieces using a Rails-inspired approach.

TurboGears is my pick of the Python litter. And interestingly enough as far as TurboGears goes, the “rails-inspired” approach is less about API than marketing. Sure both frameworks are “full-stack” and both frameworks are “Ajax-enabled” and both frameworks include and easy to use ORM. But the syntax and developer workflow for the two projects is still pretty different.

But as for marketing, the Kevin Dangoor creator of TurboGears, learned a lot from the Rails folks about intelligent use of screencasts, and the need for a good looking web-site. But I also happen to know that both Kevin and David read the Creating passionate Users blog, which is a good source of “marketing” ideas for framework developers.

I think the most critical piece of marketing advice a framework designer could read is “You can’t out-spend or out-teach.” I think the key to developing mindshare in “the coming framework wars” is not necessarily having the best framework with the cleanest code, and the most features. It will be which framework can grab a users attention long enough to teach them something significant, so they can actually start using the framework.