Diving into the Grails-vs-Rails wars (Or, Here we go again....)

---

Normally, I like to stay out of these kinds of wars, but this
post by Stu (whom I deeply respect and consider a friend, though he may not reciprocate
by the time I'm done here) just really irked me somewhere sensitive. I'm not entirely
sure why, but something about it just... rubbed me the wrong way, I guess is the best
way to say it.

Let's dissect, shall we?

Stu begins with the following two candidates:

1. Joe has a problem to solve. The problem is specific, the need is immediate, and
the scope is well-contrained.

2. Jane has a problem to solve. The problem is poorly understood, the need is ongoing,
and the scope is ambiguous.

For starters, Joe doesn't exist. Or rather, exists only in the theoretical. Of course,
neither does Jane really exist, either. Fact is, almost all projects are a combination
of Joe and Jane. More importantly, Stu's efforts here to force people into the "either/or"
approach to categorization is a subtle (or perhaps not so) ploy to force people into
the decision-making path he thinks should be taken.

It's sort of like saying, most people fall into two categories:

1. Joe lives in Ghettopia, where all the men are dumb, the women are ugly, and the children
   are rejects from the ADHD Clinic.
2. Jane lives in Utopia, where all the men are smart, the woman are good-looking, and
   the children are well-behaved.

Think about it: you're at work, you have a project, and you happen across Stu's page.
Faced with the typical project (too little time, too few resources, too vague in the
understanding of requirements and domain comprehension), with whom are you likely
to identify? Disturblingly happy Joe, who has a specific problem in a well-constrained
scope? Hardly. So from the beginning, you're expected to identify with Jane, which
(not surprisingly) leads you into Stu's preferred conclusion.

He goes on:

How should Joe and Jane think differently about software platforms?

   1. Joe's platform needs to be mainstream. It needs to offer immediate
productivity, and the toolset should closely match the problem. Also, Joe doesn't
want to climb a learning curve.

   2. Jane's needs are quite the opposite. Jane needs flexibility. She needs
glue that doesn't set. She needs a way to control technical debt (Joe doesn't care.)

For my part, I am interested in Jane's problems. (And anyway, Joe often discovers
he is actually Jane midway through projects.)

Hey, Stu, quick reality check for ya: most developers want all of the above.
It's not a binary choice, productivity and toolset vs. flexibility and dynamism. The
fact is, the Java language has a degree of flexibility, just not as much as is offered
by the Ruby language. For that matter, if you want real flexibility, maybe
you oughta look into Lisp, or even Smalltalk, since it (ST) can get at the underlying
stack frames from the ST language itself! Now that's flexibility you Ruby
guys can only dream of. (Oh, I know, Rubinius will give you that flexibility.
Someday. Justin even alludes
to how Rubinius is essentially an attempt to recapture that dynamism from Smalltalk.
Ironic, then, isn't it, that the guys who wrote the fastest Smalltalk VM on the planet
(Strongtalk, which is open-source now, by
the way) ended up working at Sun... on the thing that later came to be called Hotspot?
You think maybe they have a little familiarity and experience with VMs?)

And that crack about "control technical debt (Joe doesn't care)"?

Bullshit.

Let me repeat that in case you missed it: BULL-SHIT.

Joe and Jane both care about technical debt. Each may be willing to spend
their currency on different problems, granted, but both of them care about technical
debt. Not caring about technical debt is what got Chandler into trouble, and it had
nothing to do with language or tools whatsoever. It's insulting to suggest
that either of them don't care about technical debt, particularly the guy that chooses
differently than you.

(Shame on you, Stu. You know better. Quit trolling.)

We continue:

So how does this affect platform choice? If you are Joe, you care about specific details
about what a toolset can do right now. Most of Graeme's
Top 10 reasons are in the "Right here, right now" category. This is true regardless
of whether you think he is right. (Sometimes he is, sometimes
not.)

I'll grant you, some of Graeme's Top 10 reasons are a bit spurious, and Stu-and-company
do a good job of pointing those out. Frankly, anybody who makes a technical selection
based on version numbers or whether or not a book exists for it seems to be missing
the point, if you ask me. Of far greater concern is the stability of the language/tool,
or the wealth of documentation for it. (And yes, this may seem to fly in the face
of my arguments against Parrot a few posts ago; actually, it's not. If Parrot were
more stable and/or more fully fleshed out, and the version updates just kept going,
I'd be happy to say, "Go get this thing and give it a spin". But it doesn't feel stable
to me, so I can't.)

But Stu's argument here is spurious: I don't care if you're Joe or if you're Jane, you
always care about specific details about what a toolset can do, right now or otherwise.
Certain concerns may be concerns that you can put off until later, but those concerns
are always a part of the platform selection. Consider a hypothetical for a second:
you currently are developing on Windows, and your project will run on Windows servers,
with a possibility that it may need to run on non-Windows servers at some point in
the future. Do you consider .NET or not? This is exactly the kind of detail that needs
to be discussed--how likely is the move to a non-Windows server going to be? If it's
<25%, then the CLR and ASP.NET might be a good choice, particularly if your developers
are less "plumbing wonk" than "GUI designer", and you rely on being able to move the
assemblies to a non-Windows server later via Mono.

Note: I'm not suggesting this a good choice in all scenarios. I'm making the point
that the details of the toolset matter in your choice of toolsets, based on what your
particular project needs are.

Jane cares just as much about toolset details as Joe does. I can't imagine a scenario
where either of them don't care.

To continue:

My advice to Joe: Know exactly what you need, and then pick the platform that comes
closest to solving it out of the box. Depending on Joe's needs, either Rails or Grails
might be appropriate (or neither!). A particular point in Grails' favor would be an
established team of Spring ninjas.

"Know exactly what you need"? Ah, right, because Joe belongs to that .01% of projects
that have "specific problems, immediate need, and well-constrained scope". Nothing
like conceding a point to the other guys, in preparation for the "killer blow":

If you are Jane, you care more about architecture. I mean this term in two senses:

   1. Architecture: the decisions you cannot unmake easily.

   2. Architecture: the constraints on how you think and work.

If you are Jane, you care about how and why the platform was assembled, because you
are likely to have to adapt it quite a bit.

You know, I don't think I've ever been on a project where I didn't care about architecture
or in having to "adapt it quite a bit". Of course, back in the days when I was writing
C++, this meant either subclassing CWnd or TWindow in interesting ways, or else sometimes
even going so far as to reach into the source code and making some tweaks, either
at compile-time or through some well-established hackery. (Yes, I wrote a template
class called THackOMatic that allowed me to bang away on private fields. Sue me. It
worked, I documented the hell out of it, and ripped the hack back out once the bug
was fixed.) Point is, both Joe and Jane care about the architecture.

Now, I think what Stu means here is that the architecture of the web framework is
more malleable in Rails than it is in Grails, because Rails is written on top of Ruby
and Grails is written on top of Groovy, Spring, the JEE container architecture, and
Java:

Most of the commenters on my earlier post (and Graeme in his addendum) correctly identified
the real architectural difference between Grails and Rails. Rails builds on Ruby,
while Grails builds on Groovy and Spring.

Yes! I agree with this so far. (In fact, everybody should, because these are simple
statements of fact.) But then Stu takes the cake for the Best Parting Non-Supported
Shot Ever:

Rails wins this architecture bakeoff twice:

    * Ruby is a better language than Groovy.

    * Spring does most of its heavy lifting in the stable
layer, which is not the right place.

Huh?

Ruby is perhaps a more flexible language than Groovy (and that's an arguable
point, folks, and one which I really don't care to get into), but Ruby also runs on
a less-flexible and less-scalable and less-supported platform than Groovy. I dunno
that this makes Ruby better. It simply makes it different. Try convincing
your IT guys to add yet another platform into their already-overwhelmingly complex
suite of tools, particularly given the surprisingly sparse amount of monitoring information
that Ruby platform offers. Stu may want to argue that Ruby-the-language is more flexible,
regardless of what platform it runs on, and if so, then we're arguing languages not
platforms, and while he might win much of his "Ruby is a better language than Groovy"
argument, he's going to lose the "Ruby is more dynamic than Groovy", because on the
JVM they have to be implemented under the same set of restrictions. You can't have
it both ways.

(By the way, if you're one of those Ruby/Rails enthusiasts who's going to counterclaim
that "Ruby-meaning-MRV is fast enough", I've heard the argument, and I think it's
specious and ignorant. "Fast enough" is an argument that rests on your project being
able to remain within the expected performance and scalability curve known at the
beginning of the project, and remember, Jane's problem is that she doesn't know those
sorts of things yet. So either you know, and have some better scope around the problem
than Stu gives credit to Jane for having, or else you don't know, and can't assume
that the Ruby interpreter will be able to handle the load.)

And WTF is up with the idea that "Spring does most of its heavy lifting in the stable
layer, which is not the right place"? I think Stu means to say that Spring
is a static layer, not stable layer[1], because hey, stability is
kinda important to a few folks. (I'll give Stu the benefit of the doubt here and assume
he cares about stability, too. I know his customers do.) Spring has its flaws, mind
you, but arguing that it's not up to the heavy lifting seems to be like arguing that
Java cannot scale. (Even Microsoft has given up on that argument, by the way.)

The worst part of this is, I've had discussions like this with Stu in the past, and
he's much more articulate about it in person than he is in this blog post. Frankly,
I think the most interesting space here is the intersection of Graeme's and
Stu's positions, which is to say JRuby (and IronRuby or Ruby.NET, but that's for a
different platform and out of the scope of this discussion entirely... yet still compelling
and relevant, strangely enough). At the end of the day, these arguments about "my
web framework is better than your web framework" are really just stupid. (As long
as you're not trying to claim that Perl is the best web framework, anyway. Yes, Perl
enthusiasts, I'm picking on you.)

My advice to Jane: Rails over Grails.

My advice to Jane: pick a consulting firm that
doesn't have preconceived dogma about which web framework... or language, or any
other toolset... to use. [2]

And if Jane can't afford a consulting firm, then Jane needs to do the research on
her own and make her own decision based on the problem set, the context, and the whole
range of tools available to her. (Anybody making a decision based solely on the basis
of a blog-post-flame-war deserves what they get, regardless.)

As for Joe? Well, Joe could probably benefit from the goodness inherent in the dynamic
languages that are popping up all over the place, too, not to mention the goodness
inherent in the type-inferred languages that are starting to poke their heads through
the Barrier of Adoption, all the while not ignoring the fact that he could probably
benefit from the inherent performance and scalability of the major virtual machine
technologies that have been a decade or more in production...

Meaning Joe probably needs to go through the same decision-making criteria Jane does.
Thank God both of them, it turned out, work on the same project, as is often the case.

Meanwhile, I'm done with this thread. It's a pointless, stupid argument. Use the right
tool for the job. Or, if you prefer, "From each language, according to its abilities,
to each project, according to its needs."

Just remember that both shipping and supporting are features, too.
Don't neglect the other in favor of the one.

 

 

 

[1] Yes, I saw the hyperlink to Ola's post about languages, and his definitions therein.
Ironically, Ola's own comments there state that "Java is really the only choice here",
which directly contradicts Stu's choice of MRV (the native Ruby interpreter). More
importantly, I think Stu's point is resting on the static nature of the Java layer
in Groovy, and while it's certainly more flexible to be able to hack at any layer
of the stack, this is only realistically possible in small applications--this isn't
my opinion, it's the opinion of Gregor Kiczales, who spent many years in CLOS and
determined that CLOS's extremely flexible MOP system (more so than what Ruby currently
supports, in fact) led to inherent problems in larger-scale projects. It was this
thought that led him to create AspectJ in the first place.

[2] By the way, if there's any temptation in you[3] to post commentary and say, "Dude,
you just don't understand Ruby" or "How can you agree with Graeme this way?", just
don't. I do understand Ruby, and I like the language. (Much more than I do
Rails, anyway.) And I'm not intrinsically agreeing that Grails is better than Rails,
because I don't believe that, either. I believe in the basic equation that says the
solution you pick is the one that is the right solution to the given problem in
the stated context that yields the most desirable consequences.

[3] This includes you, Stu. Or Justin, or Graeme, or anybody working for Relevance,
or anybody working for G2One, Inc.

---

Enterprise consulting, mentoring or instruction. Java, C++, .NET or XML services.
1-day or multi-day workshops available. Contact
me for details.