I think ActiveRecord has exactly the sort of problems that Linus describes, when you get to large codebases and large teams. For example, what does 'save!' do? Well, it doesn't just update the row in the database; it also runs any validations on the object, and any before/after validation/save hooks. So, in general, you need that context to know whether a patch that updates something is correct or reasonable. And if you've got any triggers in your DB, there's a whole other area where something unobvious might be happening.

There's also lots of subtle ways for the DB and a particular object or set of objects in memory to get out of sync and cause hard-to-understand bugs.

ActiveRecord is definitely one of those tools that "make easy things easy". But, at the same time, it's not hard to get overly clever and make a mess with it as well.

"a tool that make simple things easy" - thank you for this =)

I was quoting Larry Wall who said that a programming language should "make easy things easy and hard things possible". (Or something close to that... the internet seems a little uncertain on his exact wording.)

I usually hear it in the form of a denouncement of tools that "make easy things easier and hard things impossible". I think that perfectly describes a bad abstraction layer.

Haskell is claimed to make hard things easy, and impossible things happen. (Though, who knows, perhaps easy things will become impossible with it?)

Not before making easy things hard, though.

You get used to it. The stuff that's easier in other languages than in Haskell is mostly done by hiding distinctions.

Though not completely. Some stuff is made more complicated than necessary because of the choice of syntax. E.g. variadic function in Haskell vs Scheme. Or the the Haskell record-syntax.

A little nit pick - "The exception that proves the rule" is commonly misused as above.

It means that by their being an explicit exception a rule must exist for their to be an exception. For example:

"Special leave is given for men to be out of barracks tonight till 11.00 p.m."; "The exception proves the rule" means that this special leave implies a rule requiring men, except when an exception is made, to be in earlier. The value of this in interpreting statutes is plain.

http://en.wikipedia.org/wiki/Exception_that_proves_the_rule

ActiveRecord, like much of Rails, is all about context. ActiveRecord is designed to create a domain specific language for interacting with a relational database. By Linus' reasoning, if you had a project where interacting with a relational database was a significant and pervasive part of the app, then may be worth the tradeoff of bringing in the context and assumptions of a system like ActiveRecord.

In a huge, sprawling project in which the relational database is a small portion, it may not be worth trading the power of ActiveRecord for the accompanying loss of explicitness and clarity.

Interesting question. To be honest I'm kind of on the fence with AR. It makes trivial SQL very simple but I find myself forced to drop down all the time into raw SQL for a lot of cases and I also find that AR queries with a lot of options (order, group, select, limit etc) aren't much of an improvement in readability or abstraction over the raw SQL.

What's more, I finally gave up after a year of waiting for this pretty fundamental bug in the postgres driver to be fixed and finally just hacked around it: https://rails.lighthouseapp.com/projects/8994/tickets/2622-p...

" I also find that AR queries with a lot of options (order, group, select, limit etc) aren't much of an improvement in readability or abstraction over the raw SQL."

This was how I felt when I first scratched the surface, but by using find(...) instead of raw sql you leave open other options for the future like using :include

I think a lot of this will improve with Rails 3's new query syntax. It looks a lot like LINQ for .NET.

Yeah, a lot of times you're using the same keywords you might use in SQL, but the new chainable extensions are really nice for building up queries and reusing common chunks (either in LINQ or in Rails 3)

I should note that this new relational syntax is provided by a library called Arel (http://github.com/nkallen/arel)

If the kernel was written to the common standards of Ruby code, it would come apart completely.

-- > That doesn't mean Ruby is bad. Ruby is great. ActiveRecord is a great model for MVC web development. The standards of Ruby aren't good for more performance-oriented, "hard core" development - Ruby's a pretty mature language but Rubinius, the Ruby-in-Ruby project still isn't production-level. One might guess that compilers/interpreters require a different standard than web frameworks. Neither is bad though (writing a website in c/c++ would be onerous).

If the space shuttle code was written accord to the standards of Linux code, it would come apart completely too.

It's shame that Linus had to frame things as good language versus bad when it's a matter of the right tool for the right job.

Still, the proofs in the pudding and anyone who can write a kernel in C++ or Ruby would sure give those languages a boost (and these are the languages I like best).

There really wasn't much in terms of "good and bad" overall, just "good and bad" for Linux. At the end he says (paraphrased)"I'm not saying this is for every project, but if you are going for more than C, skip C++ and go for <list of features that ruby qualifies for>".

Tu put it more plainly, he said that for any possible job, C++ is never the best tool for it.

  ∀job, ∃L | L(job) > C++(job)

This, plus stating that C++ is very complicated amounts to say that C++ is bad. Because even if C++ is "good enough" for a wide range of jobs, it's complexity makes it longer to learn than several, simpler, more specialized languages.

My personal opinion is that C++ is best only when legacy code is involved, or when the team just won't learn other languages. I can understand them. Learning C++ is such an investment that they are more likely to "throw good learning after bad", or may think that learning another languages will be as difficult as learning C++.

I may change my mind when I bother to look at LLVM or V8. Perhaps.

ActiveRecord is godawful as soon as you want to use for something that wasn't in mind when people designed it. I'm working on a Ruby application that has to talk to a legacy database with composite keys and does so via ActiveRecord. Oh, the pain.

As others say in this thread: ActiveRecord makes easy/simple things very easy. Unfortunately, it makes harder things damn near impossible. To aggravate matters, people that only use it for what it was designed for, tend to blame you, instead of acknowledging that it may very well be that their favorite tool doesn't support a particular kind of use.

i disagree with the assumption that a good tool will support all or even 90+% of use cases. you lose a lot by piling in feature after feature.

I much prefer a few different tools that do a few different things really well. I don't use active record if I have to deal with legacy schemas. I'll use data mapper or roll my own. If I get to design my own schemas then I love the benefits AR gives me.