
Be careful with magical code - fogus
http://codemonkeyism.com/beware-magical-code/
======
sophacles
There are a couple assertions in here that I fundamentally disagree with:

1\. Magic is something you don't understand.

I disagree. I get recursion. It is pretty simple. Yet it is elegent and
subtle. I think of it as having a deep underlying magic due to the power it
provides via simplicity. It gives the impression that there is more going on
than there is, that using a recursive algo is touching on a fundamental rule
of existence.

2\. Magic is just a leaky abstraction that breaks down at some point. (it
doesn't scale linearly)

Everything is leaky abstractions. Seriously, everything. I'm learning about
electronics right now. Capacitors in real life are _very_ different than the
ones I learned about in physics E&M. Of course if I assume that I will be
operating w/in sane limits of the components I choose, the leaky physics
abstraction is just fine. This example was specifically chosen because on top
of it is built a pile of leaky abstractions as well, one path of which can end
in data structure (oh no! leaky abstractions).

Just because an abstraction is leaky (magic) doesn't mean it is not useful in
certain places.

~~~
gte910h
I'd contend magic for most of programming/electronics has 3 features:

1\. It breaks more than extremely rarely.

2\. It is esoteric and often cross-domain knowledge

3\. It has limited usefulness to understand if the magic is not broken.

For instance, Ruby on Rails is great except when it isn't, and it's broken.
Then it's hell to figure out the source of the issue (this was from a couple
years ago, haven't touched it in years). But does fixing RoR really yield you
anything of value? Eh, not for most Rails users, beyond not breaking that
specific way again.

I'd ALSO contend deep filesystem work is also esoteric and outside many
peoples' knowledge, but it's _NOT_ magic, because it very very very rarely
breaks (for the use cases normal people have with it). So programmer X can go
do his PHP, and will likely go his entire life without being bit by
"filesystem esoteric failure" if he doesn't get tricky with his mounting of
filesystems.

For a EE who sometimes programs (sounds like you, sorry if I misconstrue you),
I would agree recursion is somewhat magical.

For someone like me (I learned to repeat with recursion before I learned
loops), it isn't esoteric at all, and is just a better way of expressing
repetition in some cases. I have little more trouble debugging a recursive
algorithm than a iterative one.

Due to the limited stack sizes on most embedded systems, I'd actually contend
this falls into the "cross-domain" knowledge for you, as the skillset and
familiarity with recursive algorithms is simply using them lots of times in
places where it's acceptable and proper.

I don't see your vocation giving you that practice, as embedded developers are
often highly suspicious of recursion (even tail recursion). [Disclosure: I am
an embedded developer by later training, but have a computer science degree
with a specialization in embedded and large scale systems].

So what's magic to you isn't magic to everyone. Magic is just a way of saying
"Complex, can break but usually doesn't, not worth learning about that next
layer down, but useful anyhow". I mean, to most programmers, the entire
"hardware" thing is magic. To others though, it's another layer they
understand fine.

------
epochwolf
Edit: After a little more reading, everything he's posting about seems to be
Java specific. It would have been nice for him to point that out somewhere.

After reading the ORM article, I've come to realize this guy is using ORMs to
completely ignore the SQL Layer. Also, I don't see any references to any ORM
except Hibernate. A single datapoint isn't enough information to draw these
conclusions about all orms, just Hibernate.

Coming from Ruby on Rails (and having used NHibernate for a project), I see
this guy as an idiot. I use ActiveRecord to skip writing full sql for every
statement, not to ignore sql completely. I check the generated queries, I only
load the fields I need on high traffic pages, and I dip into raw SQL when I
need it. I'll admit to being lazy with my edit screens but they aren't loaded
nearly as much as other pages. And when I hit a bottle neck, I will do
whatever incantation (SQL) to the database is required to fix the problem.

------
GFischer
I'm much more interested in the ORM discussion... anyone has some good
resources on that? (mabye referenced over here in HN?)

I'm pretty excited about Microsoft's Entity Framework v4 right now (because I
haven't actually tried it :P - the first version didn't fulfill my needs)

