

Things that Ruby on Rails people tell you - Nathandim
http://jameschambers.com/blog/lies-that-ruby-on-rails-people-tell-you

======
themgt
I doubt most Rails developers spend much time thinking about .NET

There's a large and growing number of useful, productive high-level languages,
frameworks, databases, webservers, tooling, etc. The thing they all have in
common is they're open source, they can be used on a variety of POSIX-
compatible operating systems and distros, they're often used together, share
underlying libraries, and help build off each other's advances.

OTOH, .NET is stuck in the walled garden it built around itself, with its
fanboys trying to scream out over the walls at the rest of the world bustling
by, demanding we pay them more attention.

Well sorry, no. You guys enjoy that garden though; you keep telling us how
nice it is!

~~~
MattRogish
Indeed. I've been a developer for about 13 years. The last 6 and change has
been doing Rails and JS app development (I started out doing VC++ apps for
Windows). I haven't thought about MS stack at all since about 2002. And I
don't recall any presentations at RailsConf this year about .NET. No one in my
circles even gives .NET a second thought.

ASP MVC may be pretty rad, but I personally hate C# (Ruby is an amazingly
better language) and I don't feel like buying into the Microsoft ecosystem.
It's not one that shares my values and culture, and from the outside it seems
to be losing momentum and relevance. I'm not aware of many developers who
would decide to adopt Rails over .NET due to these "lies" - the choice is
first cultural, then technical.

I'm not suggesting that .NET shops are worse places to work (although that has
been my personal experience) but there's something about the MS ecosystem that
puts .NET shops at risk of turning into overly-stuffy/corporate,
aesthetically-unpleasing shops. There are exceptions of course
(FogCreek/StackOverflow) but they don't appear to be the norm.

~~~
irahul
> but I personally hate C# (Ruby is an amazingly better language)

I won't argue about Ruby being a better language(I like C# and Ruby and I am
not inclined to pick a winner). But what version of C# have you used? If you
had a brush with earlier versions of C#, I suggest you
<http://www.manning.com/skeet2/excerpt_contents.html> read the first chapter.

~~~
rpeden
Indeed. With lambdas, closures, LINQ, and dynamic types when I want them, I
find that C# feels sort of like a nice midway point between Java and Ruby.

------
irahul
> I can use default project templates that are included in Visual Studio,
> download starter projects from the web, or, if I prefer, start with a
> completely empty solution and use Nuget to cherry-pick functionality that
> other developers have made available.

It's not about just the templates(I have personally never used one). Rails has
useful code generation(scaffold, controller, model, migration). I would rather
not type what I can generate. This isn't something you can solve with project
templates.

How is this a myth that you can bootstrap a project faster using Rails? Here,
take this:

[http://guides.rubyonrails.org/getting_started.html#creating-...](http://guides.rubyonrails.org/getting_started.html#creating-
a-resource)

Show me how I do the "10 minutes blog" in your framework of choice.

> Myth 2: It's Easier to Manage Packages Rails

Great. Good on them for realizing adding assemblies using Visual Studio
dialogs is a fucked up way to manage dependencies.

> Myth 3: It's Better to Develop with RoR Because it's Open Source

It's better to develop with RoR because it's open source, and when something
breaks or I need to augment, I don't need to wait for my overlords.

> If your personal opinion or corporate agenda is that it's "better" to
> develop on OSS solutions, then good on you.

It's neither. How hard is it to understand that black boxes are a pain?

> Myth 4: I Get More Options for View Engines/I'm not Limited by Microsoft
> View Engines

> First of all...what limitations? The Razor view engine â the default for MVC
> â is likely one of the best view engines around right now.

And how is razor one of the best?
[http://www.asp.net/mvc/tutorials/views/introduction-to-
razor...](http://www.asp.net/mvc/tutorials/views/introduction-to-razor-syntax)
This looks like another run of the mill template engine.

> Maturity isn't dictated by age, and what is really important is how
> comfortable you are with your tools.

Maturity of a framework is independent of how comfortable you are with it.

> but it doesn't mean you can dismiss VS for what it is

Umm. RoR isn't an IDE. What has RoR's maturity got to do with VS? If you want
to talk about tooling, please do, but how does RoR's tooling the same as RoR
maturity?

> You're likely to find just as many bad questions, answers, arguments and
> features in any language, if you look hard enough.

Are you seriously positing all languages have same amount of activity and
features?

> I know exactly where my models go. And my views. And helpers. And filters.

And I am least interested in learning a new project layout every time I work
on a different project. You know your project layout - I don't and I am not
interested in learning it. The point of a standardized layout is "it's more
clear where things go".

~~~
JamesChambers
Hey thanks for this. I will indeed take you up on the "10 minutes blog" and
put it on YouTube. I do it all the time during presentations.

I agree it's not just about the templates. We have support for scaffolding
(controllers, views, migrations and more). Our models are POCOs, so they are
trivial to write, and we have great helpers for that.

Agreed fully on #2. About time.

#3 - I haven't had to wait for anything. Most parts that I don't like I can
and have just built my own parts for. The MVC Framework (and ASP.NET runtime)
are pretty much pluggable up and down the stack.

As for the maturity piece, I think you're taking the VS comments out of
context. I'm not saying MVC is an IDE and I'm not saying RoR is or isn't. My
comments on this were from the segway from "tools" in the previous paragraph.

> Are you seriously positing all languages have same amount of activity and
> features?

No, I'm simply saying you can find _bad_ features in any language. :o)

Again, I'm not saying "You have to drop what you're doing and try MS's
implementation of MVC", I'm just saying, "Don't knock a horse before you try
reading it."

Or however that goes.

Thanks again, great comments.

~~~
sergiotapia
I wonder why you bother posting things like this here of all places. I agree
with you, I'm an MVC3 and a Rails developer - I put food on the table for my
family using both (and even sometimes CakePHP).

The amount of sheer idiocy in this thread is really surprising considering the
website.

It's like people see "Micro$0ft", foam at the mouth, and start rambling on
about FOSS. Without even using MVC3 for anything substantial.

To compare Razor with any other view engine and say it's more or less the same
is SO IGNORANT it makes my blood boil; especially since people are upvoting
those same stupid remarks.

How can you compare Razor's elegant syntax with Rails really smelly view
engine:

    
    
        @foreach (var person in Model.Friends)
        {
            <p>@person.Name</p>
        }

~~~
vidarh
ERB ( _one_ of a ton of view engines you plug into rails):

    
    
        <% Model.friends.each do |person| %>
            <p><%=person.name %></p>
        <% end %>
    

Or:

    
    
        <% for person in Model.friends %>
            <p><%=person.name %></p>
        <% end %>
    

I don't even like Rails, but I fail to see how that is "really smelly". Or as
I prefer Mustache, I'd probably rather pass Model.friends to the view as a
variable and do:

    
    
        {{#friends}}
            <p>{{name}}</p>
        {{/friends}}
    

But regardless what engine you do, you'd be hard pressed to find any big
differences in terms of iterating over a collection. I find it very hard to
believe that you're a Rails developer yet somehow find the above syntax so
much more elegant that you'll use that as an example of how rails has a
"really smelly" view engine.

~~~
sergiotapia
You don't see how uncomfortable for the hands it is to type `<%` and closing
`%>` every single time you want to output something using code?

How can you compare that, to a simple `@` symbol? ERB (or even Mustache for
that matter, feel like a relic compares to Razor.

~~~
irahul
> You don't see how uncomfortable for the hands it is to type `<%` and closing
> `%>` every single time you want to output something using code? How can you
> compare that, to a simple `@` symbol? ERB (or even Mustache for that matter,
> feel like a relic compares to Razor.

I don't think you are doing an objective evaluation.

1\. All goddamn editors can be configured to do a short key for the
expression(I have mapped \1 to `<% %>` and \2 to `<%= %>`)

2\. If that is too much of work, use Haml <http://haml.info/tutorial.html> or
Slim <http://slim-lang.com/>

    
    
        # slim
        - persons.each do |person|
          p = person
    
    
       # haml
       - persons.each do |person|
         %p = person

~~~
sergiotapia
You're comparing something that comes out of the box (Razor) with something
you can achieve comfort with after wiring up hotkeys and snippets. That's not
a fair, clinical comparison.

Are you kidding me?

Slim looks like something much MUCH better than the crufty old ERB.

~~~
irahul
> You're comparing something that comes out of the box (Razor) with something
> you can achieve comfort with after wiring up hotkeys and snippets.

And what difference it makes if it comes with Rails or I have to add an entry
to Gemfile? Ruby has many different templates. What comes bundled with Rails
is totally up to creators. DHH is opposed to haml
<https://twitter.com/dhh/status/58289541068492800> and hence, erb is the
default which is unlikely to change.

They don't even have to accommodate alternate templates(which they do
seamlessly). Do you cry a river every time you have to use a library which
doesn't come bundled with .net?

> Slim looks like something much MUCH better than the crufty old ERB.

And it's better than Razor's crufty syntax as well.

But please keep tooting your horn about your Razor. I have wasted enough time
here.

------
gamache
I am a Ruby on Rails person! I will tell you some things.

I am not going to give up OS independence, on the development or server side.

I am not going to give up editor/IDE independence.

Microsoft is not seen as ahead of the curve with respect to web technologies,
and this is reflected in its developer community.

Until these problems are fixed, the MS stack can pretty much go kick rocks.

~~~
pyrotechnick
<http://mono-project.com>

~~~
Karunamon
On shaky legal ground, IIRC.

~~~
billsix
Not on shaky legal ground <http://tirania.org/blog/archive/2009/Jul-06.html>

~~~
pyrotechnick
"However, their position regarding the non-ECMA components like ASP.NET,
ADO.NET, and Windows Forms (which are the bone of contention) remains
unclarified."

------
jfaucett
My disclaimer (and bias) is I'm a hardcore linux dev and never touch windows
unless its forced upon me. So with that said, here's my thoughts.

"Myth 1: It's Easier to Bootstrap a Project In Rails"

Maybe, but still I doubt its cross platform (without headaches) - can you
bootstrap MVC on Linux or Mac. This would mean you're married to the Windows
Env (not a bad thing necessarly if thats what you decide you want).

"Myth 3: It's Better to Develop with RoR Because it's Open Source"

You say the complete .Net stack is open source? If so this really surprises
me, considering microsofts rep, so I'd ask for links and is the C# compiler
open source?

Finally, where's the advantage? ( I know you say your not trying to say this )
Why should people use something new unless there are reasons for it being not
just as good but better at such and such? This whole post was about how MVC is
just as good as Rails, which probably is true, but if you're a good dev and
know your tools then Symfony2 or Django is probably just as good as well. The
only reason to switch is when people start showing exceptionally new
capabilities that make the devs life easier by trying out the new thing. Thats
what rails did back in the day.

------
cheald
Perhaps this has changed in the last couple of years, but the last time I was
in .NET land, the most glaring difference between the two was the community.

Rails, being built upon a foundation of open source, instills a strong open
source ethos into its community. The amount of free, permissively-licensed
open source libraries available for use with Rails is _staggering_. Rails'
entire ecosystem, down to the preferred OS kernel, is open source and free.
The buy-in to work with Rails is exactly $0. This produces a community who
almost rabidly shares code and knowledge as permissively as possible.

Compare this to ASP.NET, where, until recently, there was a buy-in for
everything, and you had to pony up a fair bit of cash just to play in the
sandbox. In the ASP.NET world, everyone wants their $15 or $50 or $500 for
every little bit of code or whatnot. The entire ecosystem feels like it's
composed of people with an "enterprise" mindset who expect that everything
should be paid for. This massively hampers growth of the technology and its
community. It is directly antithetical to the open source ideals that have
catapulted Rails to where it is today.

Any time I had tried searching for solutions to .NET problems, they were
behind paywalls, behind license restrictions, or otherwise hidden away. When I
search for solutions to Rails problems, they're on StackOverflow and Github.
Where is the GitHub equivalent of ASP.NET MVC projects? The OP argues that the
lack of SO questions is a good thing. I'd suggest that instead, perhaps it's
symptomatic of the community's attitude towards distribution of knowledge.

Like I said, the last time I worked with ASP.NET was a couple of years ago, so
perhaps this has changed by now, but if it has, it'd be a tectonic shift, and
I'm rather doubtful that an entire ecosystem can change like that in such a
relatively short amount of time.

------
btilly
Disclaimer: I came to hate Microsoft back when it was first fashionable to do
so. I've grown up, and still don't like them.

Here is my pet peeve.

MVC is a well-understood idea in web development that traces its inspiration
back to Smalltalk in the 70s. There are many MVC frameworks in many languages,
which differ in various details. All of which, to avoid confusion, called
themselves things other than MVC. Examples include Catalyst, Django, Ruby on
Rails, Struts, CodeIgniter and many, many more. See
[http://en.wikipedia.org/wiki/Comparison_of_web_application_f...](http://en.wikipedia.org/wiki/Comparison_of_web_application_frameworks)
for more.

Why did Microsoft have the gall to try to confuse everyone by calling their
product MVC? Yes, you've got models, views and controllers. So does everyone
else. Yours don't work exactly like anyone else's. (Everyone else's work
differently from each others as well.) Yours wasn't even the first one
available for .NET. Get a less confusing name.

~~~
jiayo
Rails calls themselves MVC:
[http://guides.rubyonrails.org/getting_started.html#the-
mvc-a...](http://guides.rubyonrails.org/getting_started.html#the-mvc-
architecture)

I don't see the issue with calling it "ASP.NET MVC". The Visual Basic event-
driven style of programming is fundamentally different from MVC. Calling it
MVC provides context.

Would you have preferred they come up with a "cute" name that doesn't explain
what it is?

~~~
cheald
Rails claims to implement the MVC design patterns. It does not claim to be
named "Ruby on Rails MVC".

------
brugidou
.NET tooling can't compete with any unix + ruby tooling. I use .NET everyday I
work with NuGet & co and it stinks. It is miles away from being mature and
robust (even with VS2012).

I was a RoR dev before and loved it, now I just hate .NET at work because of
it's OS (Windows) and tools (VS, NuGet, MSBuild...). We don't use MVC though.

~~~
irahul
> tools (VS, NuGet, MSBuild...).

I don't know about NuGet or MSBuild, but back then when I used VS for misc
tasks, it used to run circles around Eclipse or Netbeans.

~~~
nicholassmith
Running circles around Eclipse and Netbeans is not tricky really, they're both
horrifying to use on a regular basis.

~~~
irahul
What else would you compare VS with then?

~~~
vidarh
A solid Unix/Linux command line.

I've yet to see an IDE that can beat the productivity of that, or even get
close.

~~~
irahul
Take a Java or C# project and tell me what you can do with the CLI. Auto
completion? Re-factoring(grep and replace doesn't cut it)? Code generation? I
said Java and C#, because I don't know which IDE people use for dynamic
languages, and if it is possible to offer accurate completion without
executing the code(in some cases, it won't work even with code execution but
there was an article from the VS python guys(I think) about offering
completion without executing code) and reliable re-factoring(this isn't doable
at all without confirming with the user).

~~~
vidarh
> Auto completion? Re-factoring(grep and replace doesn't cut it)? Code
> generation?

Auto-completion is an editor feature, and support for auto-completion in text-
mode editors is not a problem, though I don't use it as I hate auto-complete
with a vengeance. If you need to type enough for auto-complete to matter, your
language and/or your identifier names are messed up.

Re-factoring and code generation are features I expect of the editor and/or
external command line based generators respectively, and there's no reason for
a heavy IDE.

I can understand people grab onto IDE's if forced to deal with ridiculously
verbose languages like Java or C#, possibly. Yet another reason to stay away
from these languages.

~~~
irahul
> Auto-completion is an editor feature, and support for auto-completion in
> text-mode editors is not a problem,

Which mighty text-mode editor would that be where auto completion is not a
problem? I use Vim and Emacs on a regular basis and it's very much a problem
except for cases where it's handled by external tools(eclim, gocode,
vimclojure).

> though I don't use it as I hate auto-complete with a vengeance. If you need
> to type enough for auto-complete to matter, your language and/or your
> identifier names are messed up.

Programming languages benefit a lot from auto-complete. The only people
against it are people who couldn't get it to work in their choice of
environment. I have zero inclination to type "validates_numericality_of" or
"http.ListenAndServe" or ...

> Re-factoring and code generation are features I expect of the editor and/or
> external command line based generators respectively, and there's no reason
> for a heavy IDE.

Please refresh your memory. I said VS is a good IDE and you said a solid CLI
is far more productive. I am not interested in your rant. I am interested in
what does CLI do better than the IDE, particularly VS or Eclipse.

> I can understand people grab onto IDE's if forced to deal with ridiculously
> verbose languages like Java or C#, possibly. Yet another reason to stay away
> from these languages.

Oh man. My environment doesn't have reliable autocomplete. Let's pretend only
verbose languages need autocomplete. Yay.

------
wes-exp
_For the record, the MVC Framework is completely open source. So is the entire
Asp.Net stack._

I'm a former C#/ASP.net programmer. This guy is delusional. Even when MS makes
code available, that doesn't really mean it's useful in any practical sense.
If you're targeting ASP.net, there is a 99.99% chance you're targeting Windows
servers and only Windows servers. Does that sound like "open source"?

~~~
rpeden
A quick look at the ASP.NET MVC source shows that it uses the Apache license,
which is OSI approved:

<http://opensource.org/licenses/category>

So yes, I'd say that is sounds like open source, using a very permissive
license. People can (and do) deploy ASP.NET MVC apps using OSes other that
Windows. The vast majority choose to deploy on Windows servers, but that does
not make the source any less open.

I don't mean to come across as a Microsoft apologist; I've worked with .NET,
Ruby, and Java...and find them all acceptable ways to get things done quickly,
once you know what you're doing. I just feel like if we all spent less time
navel gazing about whose language/tech stack is the most awesome, and spent
that time creating things instead, we'd all be a lot better off.

------
petercooper
Mostly fair points technically and a reasonable conclusion, but..

 _I want to be fair here – there's more than one camp in the Rails world_

To be fair, quit with the linkbaity titles that tar everyone with the same
brush. I could find some developers to spout off some garbage and write _"BS
That Dumb .Net Developers Actually Believe In"_ except I wouldn't, because
it's ridiculous, unfair, and antagonistic. It's as simple as adding the word
"some", really.

~~~
JamesChambers
Point taken, well stated. I've updated my post to reflect that. Cheers.

------
jhspaybar
As someone who has developed in Java, .Net, PHP, Python, Node.js, and Ruby on
Rails for web projects, I must say what sells me on RoR is the nature of the
language and ActiveRecord. My god, ActiveRecord is AMAZING. Sometimes I just
don't have the option to build something in Rails(for example building
internal API's that have to be written in Java for a number of reasons), but
given the choice I will choose a Ruby or RoR app every single time because of
ActiveRecord and the way the language functions. I know there are lots of
ActiveRecord style clones in other languages, but they just feel completely
lacking when compared to the real ActiveRecord and all it's extensions.

~~~
vidarh
I find it peculiar that anyone would describe ActiveRecord that way. In my
eyes it's a behind-the-curve ORM based on the most basic ORM pattern available
from Fowler's "Enterprise Application Architecture", and it seems most of the
people _using_ AR never read it and have not thought at all about the
tradeoffs vs. other ORM patterns (such as Data Mapper ; before anyone mentions
the Ruby DataMapper ORM: That one doesn't actually implement the Data Mapper
pattern).

I particularly dislike the way it tends to result in code that is littered
with leaky database abstractions where schema details tends to find its way
into peoples controllers and views because it encourages people to call AR
methods on model objects directly instead of even trying to encapsulate.

Ruby is my favorite language, but Active Record is one of the things I hold
greatly against Rails, not only for AR itself, but for the inspiration it
provided to many other Ruby ORM's, that while they may improve on various
aspects still to a large extent also end up encouraging leaking implementation
details for your models all over the place.

It'd be great if even 10% of the people using (and writing, it would seem,
given that e.g. the Ruby ORM "Data Mapper" doesn't implement the Data Mapper
pattern at all) these ORM's actually read the relevant chapters of EAA and
pondered a bit on how it related to their applications.

~~~
irahul
> Fowler's "Enterprise Application Architecture", and it seems most of the
> people _using_ AR never read it

I wasn't aware Fowler is a required reading for anything(or I would say even
beneficial) for _anything_, let alone AR.

> I particularly dislike the way it tends to result in code that is littered
> with leaky database abstractions where schema details tends to find its way
> into peoples controllers and views

Your whole rant doesn't have anything concrete I can respond to. How does
schema details creep into controllers and views?

> because it encourages people to call AR methods on model objects directly
> instead of even trying to encapsulate.

Ummm. What? I don't understand. Are you proposing person.save is wrong and
save should be abstracted?

> Ruby is my favorite language, but Active Record is one of the things I hold
> greatly against Rails, not only for AR itself, but for the inspiration it
> provided to many other Ruby ORM's, that while they may improve on various
> aspects still to a large extent also end up encouraging leaking
> implementation details for your models all over the place.

More rant. Still nothing concrete. AR maps the whole table, and if you are
using AR, you should know that. If you need to map parts of the table, or
compose parts from various tables as one object, use something else. Not every
tool has to solve every problem.

~~~
vidarh
> I wasn't aware Fowler is a required reading for anything(or I would say even
> beneficial) for _anything_, let alone AR.

Then I suggestion you read Enterprise Application Architecture. It's a great
book for the way it formalises a number of very common patterns in a very
concise way.

It is also directly or indirectly the inspiration for a large number of recent
ORM's and worth reading for that reason alone. Active Record the ORM is a
direct implementation of Active Record the pattern as described in EAR for
example.

Unfortunately most picked off the easiest ORM pattern presented and stopped
there, without alerting their users to all the caveats of the pattern.

> Your whole rant doesn't have anything concrete I can respond to. How does
> schema details creep into controllers and views?

Because the ORM spews methods all over the models that expose schema details
whether or not they are relevant to the domain model.

> Ummm. What? I don't understand. Are you proposing person.save is wrong and
> save should be abstracted?

No, I am suggesting that, e.g. Person.where("some random SQL") is horrible.
Yet it is hard enough to work with AR without resorting to crap like this,
that you see stuff like that all over most code that uses AR. At least all the
code I've looked at.

> More rant. Still nothing concrete. AR maps the whole table, and if you are
> using AR, you should know that. If you need to map parts of the table, or
> compose parts from various tables as one object, use something else. Not
> every tool has to solve every problem.

The problem is not what AR does, it is how it does it, and the way it's been
packaged with Rails and given legitimacy that way despite being an exceedingly
poor solution for anything but tiny projects because of a) the choice of the
Active Record pattern, b) the poor level of abstraction.

A large chunk of developers are terribly excited about AR because it's better
than what they're used to, and settle for it because it's part of Rails
instead of looking for alternatives.

~~~
irahul
> Unfortunately most picked off the easiest ORM pattern presented and stopped
> there, without alerting their users to all the caveats of the pattern.

I have a general dislike for Fowler church of patterns. That is not to say I
haven't gone through what is listed on his site. I didn't find it intriguing
enough. I derive 100 times more value reading K&R than GoF. There is limited
time and large number of books - one has to be picky.

> No, I am suggesting that, e.g. Person.where("some random SQL") is horrible.

Person.where("last_name = ?", last_name) is the most concise way to issue that
query. Abstracting last_name so that if the field name changes, the query
still is relevant is overkill. If you are so insistent, it isn't really hard
to do a base model class which inherits from ActiveRecord::Base and do the
mapper yourself.

> exceedingly poor solution for anything but tiny projects

github, twitter, heroku et al would like to disagree. Person.where("last_name
= ?", last_name) makes it unsuitable for large projects? Personally, I have
seen 1% cases where a migration changes column names, and when it does, re-
factoring the code base for column name changes will take less than 2 minutes.

> A large chunk of developers are terribly excited about AR because it's
> better than what they're used to, and settle for it because it's part of
> Rails instead of looking for alternatives.

I don't understand. You are quoting it as if AR is the new kid on the block.
It has been long enough to call it time tested. If Person.where("last_name =
?", last_name) is not abstract enough and makes it unsuitable for your
projects(still the only concrete complaint from you), look for alternatives. I
am not a fan of
InternalFrameInternalFrameTitlePaneInternalFrameTitlePaneMaximizeButtonPainter
and I would stick with Person.where("last_name = ?", last_name) and will fork
AR if someone has a bright idea of adding layers of abstractions over a simple
query.

~~~
vidarh
> K&R than GoF.

Very different comparison to the patterns Fowler presented. The patterns GoF
presented were very basic, and were interesting _then_ with languages like C++
when people were still fucking up many of the basic patterns. The number of
horribly broken C++ Singleton implementations I've seen, for example, beggars
belief. Today that's less of an issue.

The patterns Fowler presents are, as the title says, about architecture not
low level implementation, and they are patterns you will tend to find in
pretty much any large software project today yet that people still manage to
fuck up royally, which is the reason the patterns matter.

Patters are nothing but recipes of best practice. They're not meant to be
"intriguing" once you understand the tradeoffs. They're meant to become boring
and bland and trivial once people are comfortable with them and their
implementation is well understood. They're also meant to give people a shared
vocabulary for talking about it. That's the _entire_ _point_.

Most of the patterns in EAR are nowhere that for most people, judging by the
code I see regularly and judging by how there's still this cargo cult around
the AR pattern by people who in many cases have not even heard about the other
ORM patterns presented by Fowler, much less other alternatives.

> There is limited time and large number of books - one has to be picky.

If I were to pick _any_ book on software development from the last 10-15 years
I'd like everyone to read, it'd be Enterprise Software Architecture, for a
simple reason: I still see people using those patterns every day, yet screwing
them up in horrible ways. Maybe you don't need it, but the developers I come
across for the most part sure do.

> Person.where("last_name = ?", last_name) is the most concise way to issue
> that query. Abstracting last_name so that if the field name changes, the
> query still is relevant is overkill.

That is only true if you're dealing with a query that simple (even then, the
"Rails way" of doing your example would be Person.find_by_lastname(lastname)).
On the other hand, I've read the code of dozens of Rails apps that contains
several lines long SQL queries littered just because they could.

The biggest problem in _your_ example as why you are asking for persons with
specific last names in the first place. 9/10 when I see code like that, it is
the wrong (too low level) question, and leaks domain logic that should be
confined to the model.

Also, what happens when you need to serve that query from a web API instead of
your database? From a full text engine? From file? From a noSQL database? From
on disk hash table? I've had to do all of these - often several from the same
application. With a suitable architecture you just plug in your new storage
and implement the finders you need supported, and won't have to play "hunt the
raw SQL". Changing column names is the least of my concerns - that can be
fixed with a simple search replace.

You also miss the point when you say you can do a base model class and do a
mapper yourself: The point is the architecture of AR makes leaking SQL which
often ends up in controllers and other places they don't belong all over the
place the easy default, while implementing cleaner abstractions is more work.

The end result is that most places where AR is used end up with high degrees
of coupling for no good reason.

If everyone used AR in a disciplined way and avoided littering their
controllers and other code with query details that belongs in their models,
there wouldn't be a problem.

Your argument reminds me of the old memory-protection vs. no memory-protection
in the 80's, where the Amiga camp for example tended to be bitterly against
memory protection because it was seen as expensive, slow and enabling lazy
developers. Expecting developers to write clean code with ActiveRecord is a
bit similar to expecting developers to write code free of bad memory accesses
without memory protection - it makes it far too easy to do the wrong thing.

> github, twitter, heroku et al would like to disagree.

And Ebay at least used to be written using ISAPI modules, and large parts of
Yahoo runs or used to run on a horrific mess of PHP and Perl (I used to work
at Yahoo; there was a lot of dreadful code). Your point again?

(and Twitter is a particularly bad example given how much time they spend
moaning about how they've needed to move most stuff off Ruby)

Besides, pointing to web startups as the pinnacle of engineering quality is
ridiculous at best of times - while some of what happens in web startups is
amazing, there are also plenty of areas where we're still lagging 20 years
behind engineering practices in the enterprise space. Active Record was not by
any means a _new_ pattern, for example - none of the patterns in EAR were.
They were Fowler's cataloguing of well established patterns with years of use
in industry.

Rails, and AR, is still better than a lot of the alternatives. That does not
mean there are not better ways for a lot of uses than resorting to AR.

> Person.where("last_name = ?", last_name) makes it unsuitable for large
> projects?

Strawman. If you think simple cases like that is what it is about, you've not
seen much complicated Rails code, and it's a waste having this discussion with
you.

> It has been long enough to call it time tested.

So is BASIC. That doesn't mean it's good. "Time tested" is not in itself an
argument for anything.

> If Person.where("last_name = ?", last_name) is not abstract enough and makes
> it unsuitable for your projects(still the only concrete complaint from you),
> look for alternatives.

I don't use AR the library unless I absolutely have to, which means I only use
it if I help out on Rails projects where I can't dictate policy. Otherwise
I'll generally use Sequel, which though it suffers from many similar flaws
drawn in large part to inspiration from AR, is cleaner in many ways. There's
many things I'd love to change about it, but I already have at twice as much
stuff to do as I should.

For small projects I might use the Sequel schema module which implements the
AR _pattern_ , and which allows for a lot of the same crap that people do with
AR the library, but still makes it a lot easier to avoid raw SQL. The AR
pattern has its place.

But for larger projects I'd generally be inclined to implement mappers, then
often with Sequel ( _without_ the schema/model module) used internally by the
mappers only.

~~~
irahul
>> K&R than GoF.

> Very different comparison to the patterns Fowler presented.

You are intentionally trying to miss the point. I don't have to explain how
K&R and GoF are very different books, and how Fowler and GoF are very similar
books.

> people who in many cases have not even heard about the other ORM patterns
> presented by Fowler, much less other alternatives.

You mention Folwer 10 times in a row as if he is the appointed expert on ORM.
Call me when he has written one, and it's better than the existing ones. Yes,
AR is based on AR pattern named by him. So what? Talks are cheap. Produce a
better ORM if you are so sure about the deficiencies and Fowler already told
you a better solution.

> even then, the "Rails way" of doing your example would be
> Person.find_by_lastname(lastname)

find throws and exception and where does not. Whoever told you the rails way
is to not use where and use the dynamic finder is full of it.

> The biggest problem in your example as why you are asking for persons with
> specific last names in the first place.

Do I have to tell you that's an example? Really?

> Also, what happens when you need to serve that query from a web API instead
> of your database? From a full text engine? From file? From a noSQL database?
> From on disk hash table? I've had to do all of these - often several from
> the same application. With a suitable architecture you just plug in your new
> storage and implement the finders you need supported, and won't have to play
> "hunt the raw SQL". Changing column names is the least of my concerns - that
> can be fixed with a simple search replace.

Querying needs a language. SQL is for relational databases. A data source
agnostic query language does not exist. You can't abstract something that
doesn't exist in the first place.

<quote> > github, twitter, heroku et al would like to disagree. And Ebay at
least used to be written using ISAPI modules, and large parts of Yahoo runs or
used to run on a horrific mess of PHP and Perl (I used to work at Yahoo; there
was a lot of dreadful code). Your point again? (and Twitter is a particularly
bad example given how much time they spend moaning about how they've needed to
move most stuff off Ruby) </quote>

You said AR is a pain for big projects. I pointed out big projects which use
AR. And then you are selectively copy pasting to paint the wrong picture.

Twitter moans about Ruby's performance, not project size. Either get your
facts straight or stop intentionally twisting them.

> Strawman. If you think simple cases like that is what it is about, you've
> not seen much complicated Rails code, and it's a waste having this
> discussion with you.

I have not seen big projects. Twitter and Github aren't worth mentioning.
Apparently I missed the memo where you were appointed the authority on big
projects.

I have wasted enough time with you. Apart from mentioning Fowler about 50
times, and whining about how Person.where("last_name = ?", last_name) will be
an issue when we find life on Mars and we need to integrate with their data
sources, there is absolutely nothing you have to say about AR.

You win. You can go home now.

------
pothibo
I just read all the myths' title and none of them are the reason why I'm using
Ruby on rails.

You like asp.NET? Good on you. It probably has interesting concepts.

I have a feeling that a large percentage of the people choosing a framework
base their choice on two main characteristics:

1\. Language they wish to use/learn(C#, Java, Ruby, PHP, Python, etc)

2\. Framework they know/heard of (ASP.net, RoR, Flask, Django, CakePHP,
Symfony, etc.)

And there's nothing wrong with that.

------
mixmastamyk
The MS stuff is good and getting better. Still, it's a (sometimes expensive)
tarpit that is difficult to free yourself from. Better to not get involved in
the first place, imho.

------
utnick
The big thing that rails has that .NET doesn't are the vast number of open
source engines and plugins available.

For examples see here: <https://www.ruby-toolbox.com/> , nothing like this
really exists in the .net ecosystem, especially something akin to active
record plugins, so you have to roll your own stuff a lot of the time when you
could just use a plugin in rails.

Also, it seems like a lot of the useful .net stuff like mvc, nuget, entity
framework are kind of clones of stuff that exist in the rails ecosystem
already, so you are always going to be a bit behind the curve.

------
dschiptsov
Suggestion to use a Microsoft product to serve content or maintain a database
in 2012 insults my intelligence.

------
losvedir
> _Myth 1: It's Easier to Bootstrap a Project In Rails_

To me, "bootstrapping a project" includes source control and hosting. I
absolutely adore the Rails/Heroku/GitHub trifecta.

I don't really know how this compares to what .NET MVC and VS can provide. Do
they make it equally easy to get something live online with collaborators?
Going to Project -> New is one thing, but only a small step in getting a
project started.

------
warmwaffles
Can these articles please stop? There is no silver bullet solution for
anything. This is why polyglot applications are starting to pop up.

------
ctrlaltesc
What options are available for Linux/Mac developers? Can we just install Mono
and Nuget and start hacking away?

~~~
irahul
You can install Mono(on Linux at least; don't know about Mac). NuGet wasn't
working last time I checked.

~~~
tommorris
Yep, Mono works on Mac. And there's MonoDevelop, which is a reasonably
pleasant IDE.

(I don't know about NuGet and ASP.NET MVC; I only have Mono and MonoDevelop on
my Mac because occasionally I modify C# plugins for a Windows app and I like
being able to see compiler errors without having to install it on a Windows
machine.)

------
sergiotapia
Completely agree with the author. mvc3 and razor are fantastic to use.

~~~
irahul
> Completely agree with the author. mvc3 and razor are fantastic to use.

Then use it by all means. But mvc3 and razor can be awesome without the
flamebaiting.

~~~
camus
and flamebating is for people feeling unsecure about their choices.

------
Toshio
TL;DR This guy claims he was previously a free software enthusiast, but then
he grew up and now he's a microsoft enthusiast.

Yay for stereotyping free software enthusiasts as basement-dwelling pre-
pubescents.

Other than that, the article is pretty light on insightful content.

~~~
pjmlp
I know a few guys that follow this pattern.

