

Never use any language feature that describes itself as "Smart" or "Magic." - edw519
http://www.expatsoftware.com/articles/2008/05/no-magic.html

======
jrockway
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.

~~~
Jesin
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".

~~~
dgabriel
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.

~~~
jsdalton
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>

~~~
dgabriel
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.

------
sanj
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.

~~~
ericb
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...](http://www.joelonsoftware.com/articles/LeakyAbstractions.html)

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.

~~~
mtts
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".

~~~
gnaritas
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.

~~~
jasonkester
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...](http://www.expatsoftware.com/articles/2007/03/examplecode-
productioncode.html)

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.)

~~~
gnaritas
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.

------
cousin_it
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>

------
etal
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."

