3 ms·

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 prett

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.

cwinters 17y ago
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.
deleted 17y ago
[deleted]
gte910h 17y ago
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.

cwinters 17y ago

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.

deleted 17y ago

[deleted]

gte910h 17y ago

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.