Be careful with magical code
codemonkeyism.com
Be careful with magical code
1–7 of 7 posts
Re: Be careful with magical code
#2There 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.
Re: Be careful with magical code
#3I'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)
Re: Be careful with magical code
#4There 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…
I agree that everything is leaky abstractions. The lesson I get from the idea is to assess the probability of leaks occurring and the risks they present when they do. Some of the ORM ones that the author mentions are pretty onerous.
Re: Be careful with magical code
#5Edit: 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.
Re: Be careful with magical code
#6There 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…
[deleted]
Re: Be careful with magical code
#7There 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…
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.