3 ms·

Where does one draw the line between magic and a lack of user understanding? I never got this argument. Isn't magic you as a user not understanding how it works

Where does one draw the line between magic and a lack of user understanding? I never got this argument. Isn't magic you as a user not understanding how it works? I mean, classes in c are pretty magic, the this pointer is magic. Type checking, loops, trampoline jumps. A car is pretty much magic yet people use it every day. Is it magic when it does something convenient for you based on conventions without you writing the steps? As long as 'magic' is clearly explained in the docs I don't see how it's different from a layer of abstraction like a compiler or a car.

michaelcampbell 6y ago
> Where does one draw the line between magic and a lack of user understanding? There is no line; that's the definition. (I'm agreeing with you here, btw) It's a blub issue; if one doesn't understand it, it's derisively called "magic". So you don't get this argument because it's totally based on the observer. I use Django at work and I hate it because it's magic all over the place. And I recognize that me saying it is simply I haven't had the time or impetus to go figure out the stuff I don't have figured out yet, so I can bucketize all that as "magic".
- vendiddy 6y ago
  Maybe magic isn't the distinction to make. On the extreme, our processors are magic and I've never understood how exactly they work. I've had a similar experience in Ruby where metaprogramming was used in favor of objects with functions. When I had issues, it was very hard to debug. Maybe it comes down to the quality of the abstraction. I think the point of a good abstraction is you don't have to go down to the layer below.
  - RandoHolmes 6y ago
    > Maybe magic isn't the distinction to make. Or maybe this is a board full of programmers who love to fret over unimportant minutia. The idea has a well understood meaning, just use that meaning. Yes, maybe somewhere on the edges it's fuzzy, learn to live with fuzzy.
    - vendiddy 6y ago
      Sure, words will always have fuzziness, but there is benefit to substituting fuzzy terms with clearer terms. Words help influence thinking, so fuzzy words can lead to fuzzy thinking. If we are debating an API design and a colleague says "it's too much magic", is that bad thing? If I write deliverEmail(email) and the e-mail "magically" gets sent, what's wrong with that? On the other hand, if we debate the abstraction itself--for example behavior doesn't match user expectations--then we can do better at improving the API design.
Touche 6y ago
You're conflating abstractions with magic. They are not the same. Magic is not just an abstraction we don't bother to understand. Magic is magic. A car is not magic. It does exactly what it purports to do and nothing else. David Blaine levitating is magic. It works in a very limited set of circumstances and no more. It works to amuse some spectators. It doesn't work to, for example, cross the Hudson River, despite outward appearances. Similarly, in programming we use "magic" to describe something that seems to defy what the underpinning (language, framework, etc.) would allow. We know that it's using some trick to pull off what it's doing, and that trick likely has constraints that won't allow the magic to ever become a true abstraction. Note that I'm not calling Phoenix magic as I haven't used it enough to know
RandoHolmes 6y ago
No, magic is when you actually do understand and it gets in your way as a result. For example, I actually do understand http, but doing anything not explicitly designed for by the framework of choice can be painful. It's not that I don't understand the underlying tech, it's that the "magic" is expecting a specific use case that I don't want to do.
- headmelted 6y ago
  This is it in a nutshell. Also applies to scenarios where a developer does not understand something not because they don't want to, but because the vendor has actively tried to obscure how it works and is asking you to take it as a given that it will always just work "by magic" for every use case, which invariably nothing ever does.

michaelcampbell 6y ago

> Where does one draw the line between magic and a lack of user understanding? There is no line; that's the definition. (I'm agreeing with you here, btw) It's a blub issue; if one doesn't understand it, it's derisively called "magic". So you don't get this argument because it's totally based on the observer. I use Django at work and I hate it because it's magic all over the place. And I recognize that me saying it is simply I haven't had the time or impetus to go figure out the stuff I don't have figured out yet, so I can bucketize all that as "magic".

vendiddy 6y ago
Maybe magic isn't the distinction to make. On the extreme, our processors are magic and I've never understood how exactly they work. I've had a similar experience in Ruby where metaprogramming was used in favor of objects with functions. When I had issues, it was very hard to debug. Maybe it comes down to the quality of the abstraction. I think the point of a good abstraction is you don't have to go down to the layer below.
- RandoHolmes 6y ago
  > Maybe magic isn't the distinction to make. Or maybe this is a board full of programmers who love to fret over unimportant minutia. The idea has a well understood meaning, just use that meaning. Yes, maybe somewhere on the edges it's fuzzy, learn to live with fuzzy.
  - vendiddy 6y ago
    Sure, words will always have fuzziness, but there is benefit to substituting fuzzy terms with clearer terms. Words help influence thinking, so fuzzy words can lead to fuzzy thinking. If we are debating an API design and a colleague says "it's too much magic", is that bad thing? If I write deliverEmail(email) and the e-mail "magically" gets sent, what's wrong with that? On the other hand, if we debate the abstraction itself--for example behavior doesn't match user expectations--then we can do better at improving the API design.

Touche 6y ago

You're conflating abstractions with magic. They are not the same. Magic is not just an abstraction we don't bother to understand. Magic is magic. A car is not magic. It does exactly what it purports to do and nothing else. David Blaine levitating is magic. It works in a very limited set of circumstances and no more. It works to amuse some spectators. It doesn't work to, for example, cross the Hudson River, despite outward appearances. Similarly, in programming we use "magic" to describe something that seems to defy what the underpinning (language, framework, etc.) would allow. We know that it's using some trick to pull off what it's doing, and that trick likely has constraints that won't allow the magic to ever become a true abstraction. Note that I'm not calling Phoenix magic as I haven't used it enough to know

RandoHolmes 6y ago

No, magic is when you actually do understand and it gets in your way as a result. For example, I actually do understand http, but doing anything not explicitly designed for by the framework of choice can be painful. It's not that I don't understand the underlying tech, it's that the "magic" is expecting a specific use case that I don't want to do.

headmelted 6y ago
This is it in a nutshell. Also applies to scenarios where a developer does not understand something not because they don't want to, but because the vendor has actively tried to obscure how it works and is asking you to take it as a given that it will always just work "by magic" for every use case, which invariably nothing ever does.