The logical conclusion of this article is that we should all design our own transistors, and program our apps in terms of the circuit that will execute them. That way nothing will trip us up along the way!

My reading of the article was "I didn't know how to use Hibernate or ActiveRecord, but I tried anyway, and they didn't work right." Yeah, that's the software's fault, not yours. Riiight.

As for magic_quotes, the problem was it was too general, not that it was too magical. Have you ever written this:

   run_query("SELECT * FROM foo WHERE foo=?", "'bar'")

Congratulations, the "'bar'" is magically quoted! It works because you are specifying exactly what you want quoted and why.

All in all, this has got to be one of the worst articles I've ever read in my life. And that is saying a lot.

Really? Do ads for transistors describe them as "smart" or "magic"?

The idea here is not that abstractions are bad, it's that those that are frequently described by the people who made them as "smart" or "magic" are often not very helpful, and tend to do more harm than good. There are some exceptions, but good abstractions, while they may be described as "smart", don't usually include that in their name, and are rarely if ever called "magic".

Neither ActiveRecord nor Hibernate have the words "smart," or "magic," in their names. They were bad examples.

The problem is not with these two packages, but with the developers who use them without taking the time to figure out exactly what they do. Just because something makes a task convenient or easy, does not mean you aren't required to understand how they work.

It's copy/paste, cargo-cult programming, and you can't blame the tools.

I like Rails and ActiveRecord just fine, so I don't meant to bag on it. But they do talk a lot about "magic" in the Rails community. Check it: http://www.google.com/search?q=rails+magic

If this blog entry is just a restatement of "there is no silver bullet," then I agree. However, you can't blame the tools or their authors for what some people in the user community claim. The root of the problem is clearly a combination of lack of understanding and laziness.

I would extend this law a little: if you're going to perform magic, it had better be absolutely flawless.

Otherwise, show what you're doing, or don't do it at all.

I agree. This fits with Joel's law of leaky abstractions. Imperfect magic is dangerous. Perfect magic is wonderful.

http://www.joelonsoftware.com/articles/LeakyAbstractions.htm...

Rails pluralization rules are an interesting example, they leak--I have to know about exceptions, but they're consistent enough that they, in my opinion, just pass the threshold. Nearly-perfect magic is most tolerable when dealing with structure, not data and when the magic's imperfection is consistent, repeatable, and documented.

Interesting example indeed. I'd say they are a perfect illustration of a feature that, in the words of the article author, "[tries] to abstract out some behavior that is not that hard to deal with anyway".

Worse, pluralization in Rails is a feature that fixes something that isn't even a problem. For a framework based on 1 to 1 table mapping, there's absolutely no reason the tables names shouldn't directly map to the class names with no translation at all. Customer class equals Customer table. Pluralizing them is pointless, and creates minor problems that didn't exist prior.

This article however, is extremely bad and its arguments simply don't make sense. Magic isn't bad, leaky abstractions + developers who don't understand it are bad. If he think ORM's don't solve a problem then he hasn't written enough SQL to tire of the insanity of doing it manually when CRUD should clearly be automated because it's so god damn repetitive. Repetition + boredom should always be a signal to automate.

Ah, but you make the mistake of assuming that automated SQL generation == ORM. That's not the case, at least for us.

I touch a bit on the framework we use at Expat here:

http://www.expatsoftware.com/articles/2007/03/examplecode-pr...

Basically, you can think of it as an early-bound Rails. We use CodeSmith to generate a bunch of classes, stored procedures and unit tests based on the existing database schema whenever we make a change to it. Those classes, along with generated wrappers for all our hand-built stored procedures get compiled into the project. This saves us from ever having to guess what SQL we'll get for a given operation, and allows us to pause at any point and be looking at readable code that does real, undestandable work and that can be debugged through.

That may seem like a minor distinction, but then I bet you've tried debugging thru ActiveRecord once or twice and I doubt it was any fun. This way, we keep the same fast development pace that a traditional ORM might give us, without sacrificing the debugability and maintainability side (or relying on Magic happening behind the scenes.)

Nope, been there, done that, doesn't change my point at all. Automation is automation whether it's at build time or run time, it's still better than doing it by hand. Having been down the path of code generation, I'll take runtime reflection every time, or better yet, switch to a language that doesn't prevent abstraction. The need for tools like CodeSmith just screams how bad .Net languages are, and I know, I'm a full time .Net programmer. I've managed to rewrite one of our main products in Smalltalk where the language just works and you never run into the need to generate masses of code.

I remember Yegge calling Java's "smart" for-loop the "stupid" for-loop, and for good reasons.

http://steve.yegge.googlepages.com/next-big-thing

Using PHP's magic_quotes_runtime as an example can support pretty much any argument you want to make about software design choices. How about this: Don't rely on DWIM-style features to actually do what thought you meant. Just write what you mean.

Or, shorter: "Garbage in, garbage out."