Chad Myers, Letting It Flow
Chad and I are friends. Chad has opinions and I tend to like people who not only have opinions - but let them out freely.
There's no guess work, no worrying about "did I say something wrong?" - the conversations tend to flow. I like it when people "let it all out" cause then I get to do the same. And, like Chad, it's been a while :) so let's do it!
So it turns out Chad doesn't like Rails:
The state of big web frameworks sucks. Not the least sucky among these is Rails. There, I said it. Bah, hes just a bitter .NET developer stuck in the stone ages. Im tired of getting made fun of and beat up by former PHP scripters telling me how lame and enterprisey .NET is and how wonderful and magical Rails is and how it solves every problem
As I mention, Chad and I are friends. So I have no problem telling Chad that this post really paints him as a serious asshole.
There. I said it. I let it out. Normally I would say "Chad might consider some alternatives here" or I might say "Chad's a smart guy but I think he overlooked this one thing...". Where's the fun in that?
That's me, as a friend with beer in hand - smile on my face as I look Chad in the virtual eye: "Wow you sound like an asshole".
Ahhh this is going to be some fun! Let's take a look at why Chad doesn't like Rails.
Chad starts his post off with a bit of a bang, invoking a quote fromEdsger W. Dijkstra:
It is practically impossible to teach OO design to students that have had a prior exposure to Rails: as potential programmers they are mentally mutilated beyond hope of regeneration - Edsger W. Dijkstra (paraphrased)
There are a few problems here: the first is that Mr. Dijkstra died in 2002 and never experienced Rails. The second is that Dijsktra never said that. The quote that Chad pulled it from was not paraphrased - it was completely bastardized for comedic effect. It seems Chad didn't know this.
It is practically impossible to teach good programming to students that have had a prior exposure to BASIC as potential programmers they are mentally mutilated beyond hope of regeneration.
He went on to say other fun things too:
FORTRAN --"the infantile disorder"--, by now nearly 20 years old, is hopelessly inadequate for whatever computer application you have in mind today: it is now too clumsy, too risky, and too expensive to use.
The use of COBOL cripples the mind; its teaching should, therefore, be regarded as a criminal offence.
But this one is my favorite:
Simplicity is prerequisite for reliability
I wonder what he thought about Ruby? Either way - if you're going to quote someone, make sure the context is clear before basing a post on it.
INHERITANCE IS FAIL FOR MOST DESIGNS, BUT NEVER MORE SO THAN IN WEB/MVC FRAMEWORKS!
Chad likes composition. So do I. What's wrong with Inheritance in web/mvc framworks?
One class that derives from some gawdawful ginormous base class that has many action methods on it is a pile of fail. Why? Because each of those methods has, by definition, a different responsibility and youre breaking the Single Responsibility Principle...It seems almost every web framework has this wrong: Rails, ASP.NET MVC, Struts, Django, Spring, and MonoRail from my limited research.
There's something wonderful in this paragraph. That a person can unequivocally declare every other web framework in the world as failures - is just precious.
Sometimes I marvel at people's ability to not read what they've written and wonder to themselves: "Does this last paragraph make me sound like a complete ass?"
I'm not going to argue Chad's point about inheritance, nor am I going to suggest he's wrong. For all I know he's completely right.
To borrow from David Lee Roth:
I don't feel tardy
After 3 years of running my business on Rails I've never experienced any trouble with this Pile of Fail. Has it been smooth? For me it has - but how? I measure "smooth" by simple means:
Getting work done in a timely manner I can test up a new feature, and deploy it rather quickly. I just did it with special invoicing for large groups - it took me 4 hours.
A site that stays up and doesn't crash. (except when I make it crash). I've had to restart my server twice in 3 years. Both times were my fault.
Little to no security issues. Get in, Get out, Deliver value. Fixing bugs is typically a quick affair. I have a load of tests and I'm able to pinpoint problems quickly and push a fix in about 10 minutes. Seems OK to me.
Granted: Tekpub isn't a stock trading app. But there's a lot going on under the hood: managing Cutomers, Commerce, Subscription Billing, Custom Invoicing and Video Streaming - it does have it's challenges. Rails has served us well.
Chad doesn't like ActiveRecord:
To call ActiveRecord an ORM is to insult the already sullied and notorious name of ORM. I wont even say that AR is the Linq2SQL of Rails dev because its worse than that. AR is the equivalent of dragging and dropping your database to your design surface in Northwind/Designer-driven developing in Visual Studio.
It's actually the other way around if you're using Rails the "Rails Way" - your pushing your model into your database. I'm sure Chad wouldn't like that either.
But what's the problem here? Is it ActiveRecord? What's making Chad mad (emphasis mine)?
I dont care what youre doing with your data store, the model should be the core. This principle is so fundamental that not even silly dynamic typing can overcome it. The model flows out into everything, not your database driving your model. AR represents everything thats wrong with data-driven development Its just wrong, always has been wrong, and always will be wrong... AR flagrantly and flamboyantly %strong violates this principle and anyone with a clue who has used AR seriously on any project of length will tell you how it grows into a big mess.
3 years running - my model is pretty tight. Granted it's not a Huge Enterprise Design - but if it was I'd probably break out the app into separate apps. I don't care for monolithic design and I'd rather build something with messaging and service endpoints - something that Rails' RESTful focus is quite nice at. But I'll concede this point: Rails might not be the best candidate for building Massive Legacyware.
The thing that always strikes me about .NET developers who write about their dislike of Rails is the down-the-nose engineering sophistry and snobbery that is so freely given. It's almost as if .NET gives you some kind of Asshole Jacket where you get to call everyone else an ignorant dumbass - and then accuse them of doing the precise thing you're trying to get away with.
If you read Chad's post - right there in the first paragraph Chad calls out the Haters:
Bah, hes just a bitter .NET developer stuck in the stone ages. Im tired of getting made fun of and beat up by former PHP scripters telling me how lame and enterprisey .NET is and how wonderful and magical Rails is and how it solves every problem
Right on! Stand up yo! But then 4 paragraphs down:
Im sorry. Youre an idiot...Its just wrong (unit testing against your database and eating people). Just because you wear thick rimmed glasses and drink lattes with your scarf flipped casually around your neck doesnt mean you get to throw fundamental principles out of the window.
Zing! Good one!
Just for fun - let's assume that I'm That Guy. Scarf flipped up, thick glasses on. My name is Rob and I'll be your Token Rails Idiot for today. I'll be violating all of Chad's principles.
Is it possible to build a compositional model with ActiveRecord and Rails? Why yes it is... And oddly, in many ways, it's a lot cleaner.
That said - if it's light and simple I have no problems putting it on my model. Why over-engineer and complicate life from the start?
This is one major flaw I find in the "Theory-driven Development": the need to engineer your app before it's needed. A .NET Engineer would argue that it's always needed for "maintainability". Others might argue that "You Aint Gonna Need It" until you ... well you know... need it.
Report from the wild: I use extensive mixins that hang off ActiveRecord - or just use ActiveRecord as a tool - and everything works nicely. For instance, I have a class called "ShoppingCart" that has nothing to do with ActiveRecord. It has all kinds of logic in it - as you might imagine - but it does use ActiveRecord to save a CartItem.
Those noises in my head? Those are thoughts and experience. I don't like bad design much - but I don't blame the frameworks, I blame myself (sometimes for using those frameworks which spawn horrible messes). Moving on...
I have a module called "Authenticatable" that handles membership for me. I can attach it to whatever model object I please (Customer, Account, User, whatever) and guess what it can do! Ruby is really a fascinating language when you take the time to understand it beyond a demo that makes you hate it. Did you know Ruby is older than C#? It is.
If you spend some time with Ruby and investigate various idiomatic approaches (mixins, blocks) you'll quickly find that it's a very deft language - and probably a bit different from what you're used to.
Or you might write a snarky post and call all Ruby programmers idiots.
Unit Tests, Databases, Cannibalism
Chad doesn't like testing against a database (emphasis mine):
Im sorry. Youre an idiot Unit testing against the database is always, and in every case, wrong. Attempts to explain otherwise sound awfully like arguments I once heard from someone explaining why cannibalism isnt as bad as people make it out to be. Its just wrong (unit testing against your database and eating people). Just because you wear thick rimmed glasses and drink lattes with your scarf flipped casually around your neck doesnt mean you get to throw fundamental principles out of the window. So stop it. Just because it may be quick or easy (which I dont believe) doesnt make it right. Cannibalism. Idiots. Go Chad Go.
So if my attempt here to explain otherwise sounds like endorsing cannibilism - get your forks out. The short answer is that many Rails devs don't do this - they prefer to stub their models using Test::Unit (Rails built-in bits) or RSpec's mocking.
It's actually quite simple:
Customer.stub!(:find_by_email).and_return(Customer.new(:email => "email@example.com"))
You can do that in a pre-test harness or wherever you like. I tend to just use Factories.
All I can tell you is that after 3 solid years of having fun while testing - I've never had an issue. In fact I've had the opposite happen: one of my tests uncovered a stupid database issue that I added in error. I set the length wrong on a price field in MySQL (I set it to 2).
MySQL likes to be helpful so it reduced the value of 200 to 99 for me (Chad and I would probably agree: MySQL is pants-on-head retarded).
I wouldn't have caught this. Good thing my tests hit the database! Don't tell Chad that.
Perfection Is... Can You Guess?
Chad likes principles. If he had to create his own web framework, it would:
- Have total adherence to principles
- Completely compositional
- Model-based (whatever that means)
- No Controllers
- Statically Typed (of course!)
... etc. Sounds like a riot. Can't wait to try it. That's actually not true: I have tried it and I find it to be... just as Chad wants it to be. Is this the part where I get to tell Chad that I'd shoot myself if I had to maintain his Mountain of Theory in order to run my business?
I'm not saying there's a damn thing wrong with Fubu - yet I know people will say I'm being a dick to an Open Source project (as opposed to Chad who's... nevermind). Look, if you like Fubu and want to rock your principles - then rock on coder!
Rails works for me. I'm not failing, and I don't feel like an idiot. Have I tried FUBU? Yes - I certainly have. It's not for me. Can we leave it at that and can I take this silly scarf off yet?
In many ways, FubuMVC is better than Rails and Ill put my framework up against yours any day of the week.
The perfect way to end one of the funniest posts I've read in a while.