I think this definition in the middle is quite intuitive.
> That’s an example of “supernatural” behavior: e.g. when something happens not being obviously related to natural forces of the language. …And is bad exactly because of this fact: your natural tools and intuitions stop working, you need just to remember entire spellbook to deal with magical code.
The words natural and spellbook could probably map onto idiomatic and confluence. lol
I like it because magic code isn't bad, or slow, or unclever, it is often magic to achieve the opposite. But it does lack something like "being plain spoken"
This is one of the most unreadable websites I've seen in a long time. Right off the bat you're assaulted with multiple levels of unreadable thin grey fonts, and it doesn't get any better from there. It almost seems like this was intentionally created to ruin eyesight.
I wasn't aware that different bits of text in different shades of grey would 'ruin eyesight'. Can you provide a citation, or are you simply expressing "I don't like how this website looks" using hyperbole? Or are you using a hyperbolic way of expressing "I find it difficult to read this website"?
I have vision problems which are not correctable with glasses or contacts, like many people. (Fortunately, my issues are relatively mild.) For people like me, sites with poor contrast are fatiguing to read in a way that sites with good contrast are not. For people with more severe impairments, low-contrast may push past a threshold where a site becomes unreadable in practice.
This is not exactly news, there are whole guidelines on contrast published and backed by copious research.
I understand that some people are unaware of this issue. For those that are open to becoming part of the solution when it is brought to their attention, I hold no resentment.
But for those that belligerently minimize the problem, for example characterizing the challenge as "I don't like how this website looks"... not so much.
Same with organizations that surely know better but continue to present problematic low-contrast interfaces. (Discord, I'm looking at you.)
No, I don't believe that would affect my particular impairment. Do you believe that the only valid metric for accessibility is whether a site is actively damaging eyesight?
No, but my original comment wasn't about accessibility (of which I'm a proponent, by the way), it was about whether the specific sentence "It almost seems like this was intentionally created to ruin eyesight" was unhelpful hyperbole.
OK, it makes me optimistic to hear you characterize yourself that way, and it would be wonderful if you are able to make a difference (acting locally).
A lot of times people will give you feedback with a lot of hyperbole because many designers (and developoers) will simply not do anything without the volume amped up to 104db.
People with disabilities often will not lead with, so I have this condition. They'll just say they are having a hard time reading your site/the fonts are too thin/the contrast is off.
If someone is saying your site is hard to read, listen, because many others are having the same problem.
Yup, if someone is saying your site is hard to read, listen. If someone facetiously dismisses a post because they claim that the parent website is intentionally designed to ruin, as in actively degrade, their eyesight, that's a different story.
I also dislike light grey on a white background. Let alone how often the color and size change throughout. It is hard to see and feels noisy - maybe my eyes are already ruined, though I doubt it was from websites that are not to my taste.
If I really want to read something like this I usually copy it into a text editor (usually Sublime).
To save you a click, the 'it' in the title is 'metaprogramming'.
The thesis of the article is that, especially in Ruby world, we use the term 'magic' too much, when it's really a derogatory term that applies to cases where it's particularly hard to intuit _how_ a particular piece of code works.
For me "magic" is something that's initially impressive but is actually just the result of a very specific setup or slight-of-hand, which actually has little to no practical usage.
To me this is an adequate description of most of the software 'tricks' presented to me as magic.
Wait wait wait... are you telling me that David Copperfield didn't use "rituals, symbols, actions, gestures, and language with the aim of utilizing supernatural forces" when he made the statue of liberty disappear?
Every industry has jargon, words which have one meaning in everyday use, but a different meaning within the industry that can be confusing or even hostile to outsiders. "Magic" is an example of jargon when used within the programming community, and especially within the sub-community devoted to Ruby on Rails.
As an example of jargon, the dictionary definition is irrelevant other than to emphasize that it is jargon. There are applicable broad arguments against jargon in general, of course, but as an example of jargon, it's not any worse than any other jargon term or phrase, such as "It's ____ all the way down."
If we want a definition that we can understand, the correct source is not the dictionary, but this quote from OG sci-fi author Arthur C. Clarke: “Any sufficiently advanced technology is indistinguishable from magic.”
With respect to programming, meta-programming is not indistinguishable from a spell cast by a mage in D&D. A better comparison is to prestidigitation, the entertainment art of doing a thing that appears to be impossible, even though everyone in the audience knows that there is a trick to it that can be explained and understood.
It's really that simple. "Magic" as a term of jargon means "A sufficiently advanced use of Ruby's meta-programming that is indistinguishable from a conjurer's trick to those who don't know the trick."
Metaphors have value. Is magic a good metaphor? It doesn't imply metaprogramming specifically to me, but it implies that the computer figures something out without seemingly being told how, which gives me quite a bit of information. Otoh, one man's boring code is another man's magic, so it's relative. But so is "performant", "simple" etc. Those are certainly useful terms, but they rely on context.
There are worse sins in programming jargon; like when you overuse technical terms so much that you lose the "point" of what it's supposed to do. Another one is using heavily overloaded abstract terms without explaining which variant you're thinking of. If you say "service" without context, I will come after you :)
Magic has a special form of non-locality. To look for the cause of "magic" one must either pray to some god or roll the dice and read the tea leaves. If hunting down the source of understanding feels like this, we call it magic.
Jargon can be carefully laid out and taught. Common practice can be learned and maintained.
Magic is a word invoked to intentionally tell you not to learn and to stop asking questions. It's insulting to the very nature of the programmer, who must ask these questions in order to understand the systems they are trying to describe.
As for the quote, which everyone has heard by now: "Any sufficiently advanced technology is indistinguishable from magic."
This is a cynic's perspective, which while valuable to a point, does not alone lead to that which we desire. We read this quote and think, ah yes, that is how I feel... I wish things were better.
Either you accept everything as jargon, or you actually read my reply and consider my perspective. I'm not offering a crisp definition, I'm merely adding some addition flavor which is at odds with the parent's as I understand.
My perspective as detailed in the full message is that the sense in which meta-programming in Ruby is magic is more akin metaphorically to prestidigitation than to the supernatural.
In that sense, it does not imply "stop asking questions," nor does it imply "there is no answer." To me, it implies, "This may look like a supernatural entity is involved, but that's just a trick we're pulling. If we pull back the curtain, we'll find there's a little man with some levers and we'll see how it's done."
Why pull tricks at all? Ruby is about being nice, not tricking us.
Tricks are fundamentally shocking and uncomfortable at first. Many people like this from time to time, but it shouldn't be the intent of our programs.
The programs should be written in a way that helps the reader learn. If that involves some clever reveals and abstraction / hiding then so be it. The best lessons are taught in stages.
That's how Ruby meta-programming works, just as that's how inheritance works, just as that's how function calls work.
They're mystifying at first, then you learn how to use them without looking under the hood, then you learn exactly how they work, then you start making your own.
The word "trick" is associated with prestidigitation. Unless you're entering the Underhanded C context, these "tricks" are more like magicians showing EACH OTHER how to do things.
"Here's how to make flowers appear out of your top hat."
But it is magic. Personally, I wish we called more of our day to day lives magic. The fact that any of this works is absolutely magic.
The whole point of science is separating the magic that works from the hocus pocus that doesn’t. Just because you understand it, just because we have equations, algorithms, and stories that explain the relationships between things, that doesn’t mean it’s not magic. It just means the magic is REAL.
It’s impossible for me to look at a computer, a server rack, a car, or a roomba and not see the magic. Just because I understand the principles behind them doesn’t rob me of the wonder of the universe.
The analogy I like to use is Hogwarts. Just because they study spells in that fictional world, just because they have schools and universities doesn’t mean the spells aren’t magic. They’re studying the magic available to them in that universe.
I own a slab of glass I can talk to, it talks to me, and it can recognize my face. This is absolutely magic in a figurative sense. And never mind that, I'm typing this message on a device that is thinner, lighter, and does so much more than the typewriter I wrote my high school essays upon... And I use it to exchange messages in real time with people around the world!
Thank you for reminding us of the everyday magic surrounding us.
> If you ever code something that “feels like a hack but it works,” just remember that a CPU is literally a rock that we tricked into thinking. Not to oversimplify: First you have to flatten the rock and put lightning inside it.
I remember graduating with the feeling that I understood all this stuff which is essentially (from a certain, perhaps EE-biased, perspective anyway) built on top of radio, and yet the simplest, oldest forms of wireless communication are baffling.
I 'understand' (more so then) them of course, the theory, the practice, but what magic that any of this works?!
Maybe it's just because we can't see it, and it oughtn't be any weirder than anything else, but I still find it nuts and have to try not to think about it too much. Nevermind the crazy bandwidth & latency & distances we've come to expect with the internet.
To take it one step further, I recently read From Atomos to Atom and From Alchemy to Chemistry. Those books are a fascinating read that made me appreciate both how much we've figured out and how far we are from nature's truths.
The idea of an atom, or a quark, is a construct that approximates reality. Nature doesn't care about our constructs. Just because we've kinda "figured it out" doesn't mean we've robbed nature of it's magic. We are only discovering the magic that was always there.
And, IMH(umble)O, the magic we discovered since the Renaissance is far cooler - far more magical - than anything the Alchemists could come up with in their wildest dreams.
I know some people that also view much of the technology around us as "magic", but for them, that's less a statement of appreciation and wonder, and more of a statement of opaque complexity and a complete unknowability.
I can appreciate how Lightroom works, or an electric car, or the electrical grid, etc. I don't have to know every last detail, but I should have some awareness of the fundamental principles on which these things are built.
Deferring this to "magic" in the sense that I say "I don't know how that works, no one can know, it's MAGIC" can be a lazy way to think. I think it's a slippery slope that gets us closer to psuedoscience, new-age gimmicks, and other forms of poor thinking and manipulation. We should all seek to understand how things really work (even at a coarse level) in this Demon Haunted World of ours.
(Even if this isn't how you interpret this word, I'm suggesting there is a risk that others do).
I understand the sentiment that technology _feels_ magical. It certainly does so for someone unfamiliar with the field.
But for us working in it, who can see the layers upon layers of abstractions, it feels less magical and more like a miracle that any of this works at all.
Many of the devices you mention are programmed at such high levels that the programmers themselves rarely understand exactly what's going on beneath the surface. The hardest part of getting the thing to work at all is managing the complex web of dependencies underneath, not programming the actual functionality. Systems that appear magical are mostly running on a house of cards and person-years worth of frustration.
"magic" is a fun word. Just be sure you can explain what it really does when needed and your fine. I've been using it for years... Mostly as "auto-magic," meaning no user input is needed to make the function work.
I also agree that the site is hard to read w/ grey text on a white background.
Dictionary.com definition
Magic: NOUN the power of apparently influencing the course of events by using mysterious or supernatural forces:
example: "suddenly, as if by magic, the doors start to open"
Some segments adore to express themselves in language figures instead of concepts to market the hype up to the orbit without realizing that their exaggerations alienate intelligent people.
Magic is of course a very arbitrary word: I'll define it more specifically as:
It represents things that happen that you don't understand how they happen. Not just you don't understand how they work when presented with the effect, but is resistant to being reverse-engineered.
In your typical programming environment there are ways to backtrack through code searches, type hierarchy management/overloads, interface implementations, type definitions, recasts, scope resolution, etc that you can deconstruct some "magic incantation" to figure out where it is calling and then what it is doing.
In dynamic languages (the article is about Ruby) this gets a lot more dicey, with duck typing, lack of strong typing or optional typing to enforce / document what types are being used where, sometimes dynamic scoping, macro expansions.
In those cases, IDEs are you friend in a BIG BIG way. They enable targetting searches, parsed/contextual navigations, type guessing even for some dynamic languages. IDE+static-ish typed languages is even better: back navigation to the type, navigate up the type hierarchies or compositions.
I prefer to call it "spooky action at a distance." Because what I observe is that's what gets under software engineers' skin... They think the abstraction is too vague or causes things to happen that are hard to predict, but also hard to trace because the control code is separated from the consuming code, or it has modified the syntax tree or the data at runtime in a place the developer can't directly observe.
This differs from abstraction, which is fine. Abstractions are the bread and butter of programming. But if an abstraction is too leaky, or it interoperates badly with other abstractions applying to the same code... It ceases to be abstraction and becomes spooky action at a distance.
You could implement subclassing in a language via an inheritance chain or you could implement it via taking objects and replacing their various methods and fields with other methods and fields after they've been constructed. One is the object inheritance abstraction. The other is spooky action at a distance.
The author seems oblivious to the fact that we use the word magic metaphorically, in all kinds of contexts ouside programming (and the original occult).
E.g. a "magical vacation" doesn't involve casting spells...
Likewise "magic" in a program doesn't mean we can't ever trace where the effects we see are coming from. Just that they were put in with metaprogramming, and not more conventional methods.
> "magic" in a program doesn't mean we can't ever trace where the effects we see are coming from
This is my definition of magic: when it _does_ so
That's my pet peeve with Rails and Rails-minded gems, which do such magic as a core tenet. Someone ends up being too smart for their own (and others) good, it looks lovely and clever from the outside, methods are added to core objects, often dynamically so, global-like state is rampant, lazy behaviour is pervasive.
Then something breaks, and you're left with behaviours that make no sense. Of course with enough time and energy one can see through the veil by diving deep in the bowels of the framework, but I don't quite like the thinly veiled judgemental statement of TFA that magic is just metaprogramming and that as a dev you should get your shit together, which does not help in the real world when all hell breaks lose in nonsensical ways because a prime directive has been violated†.
Tricks and prestidigitation have no business being used in systems that aim to be reliable.
† Blindly copying references to thread locals into another thread[0], assuming every possible one ever used in all apps and dependencies is either scalar (which they're usually not), deep-frozen (which they're usually not), or thread-safe (which they don't need to be, because they're, you know, thread local), can only be delicately described as "a bold move".
Magic is not supernatural in so far as supernatural means “doesn’t exist”. Otherwise referring to anything as magic simply means “it doesn’t exist” or “it doesn’t work.” If you want to use the term magic in a useful way, use it to refer to the use of processes or rituals that have effects through mechanisms we don’t understand. That fits better the history of the term.
Like, when a design is magical, that means it has effects that aren’t fully understood. Like architectural decorations on buildings have real effects on the vibe of a neighborhood but we really don’t understand the specifics of how or why they affect us psychologically.
I've noticed this especially in the Rails community to talk about functionality they find fascinating and which either they don't understand or don't want to explain.
"It doesn't stop being magic just because you know how it works" - Terry Pratchett
The FA does seem to specify a particular frustration that my pithy quote doesn't address
>>"It is common to see nowadays statements like “this is too magical for less experienced developers to understand”. As Matz says (reciting from memory), “Ruby is complex language to make developer’s life simple”, not the other way round.
>>Your car’s engine and your computer’s processor are pretty complicated, too, but that doesn’t mean that they are “magical”. Neither that you shouldn’t use them and stick to “less magical” solutions."
I think this is a separate point but it is one I agree with. Probably some nuance here, but I think the problem is less that something is seen as magic and more that something might be prematurely hobbled.
I take issue with the 'monkeypatching core classes isn't magic' conclusion. I'd define "magic" in this sense as something that looks like it does one thing, but actually does another.
In python, if I see `print(5)`, I should know what that will do. Now, it's possible to do all sorts of magic and make it do something different (like print "five"). The reason that hijacking `print(5)` is magic is because when I look at it, I have reasonable expectations that are subverted.
The reason that magic is often considered bad is that if my code is supposed to subvert my expertise, then my expertise suddenly isn't useful to getting my job done. If I want to make it do something else, or debug it, I won't know where to go, because I should know how to debug `print(5)` or change it to `print(6)`, but now I don't know my way around my tools.
Maybe it's a connection to black boxes. If a reasonable user can't see how or why your magic works, and can't debug or direct your magic, it's too magical. Yes, that's subjective, but too bad. Maybe "opaque" is a better word.
magic was, what came prior enlightenment. Then came technology.
'Magic' is, when things – after proper enchantment and ritual – sometimes happen as expected. But you cannot explain why (other than 'because of proper enchantment').
"We are about to study the idea of a computational process. Computational processes are abstract beings that inhabit computers. As they evolve, processes manipulate other abstract things called data. The evolution of a process is directed by a pattern of rules called a program. People create programs to direct processes. In effect, we conjure the spirits of the computer with our spells."
Does anyone here think that metaprogramming is actually magic, as in something which defies the laws of nature? If there is no confusion, there is no problem.
79 comments
[ 3.4 ms ] story [ 150 ms ] thread> That’s an example of “supernatural” behavior: e.g. when something happens not being obviously related to natural forces of the language. …And is bad exactly because of this fact: your natural tools and intuitions stop working, you need just to remember entire spellbook to deal with magical code.
The words natural and spellbook could probably map onto idiomatic and confluence. lol
I like it because magic code isn't bad, or slow, or unclever, it is often magic to achieve the opposite. But it does lack something like "being plain spoken"
This is not exactly news, there are whole guidelines on contrast published and backed by copious research.
https://developer.mozilla.org/en-US/docs/Web/Accessibility/U...
I understand that some people are unaware of this issue. For those that are open to becoming part of the solution when it is brought to their attention, I hold no resentment.
But for those that belligerently minimize the problem, for example characterizing the challenge as "I don't like how this website looks"... not so much.
Same with organizations that surely know better but continue to present problematic low-contrast interfaces. (Discord, I'm looking at you.)
People with disabilities often will not lead with, so I have this condition. They'll just say they are having a hard time reading your site/the fonts are too thin/the contrast is off.
If someone is saying your site is hard to read, listen, because many others are having the same problem.
If I really want to read something like this I usually copy it into a text editor (usually Sublime).
The thesis of the article is that, especially in Ruby world, we use the term 'magic' too much, when it's really a derogatory term that applies to cases where it's particularly hard to intuit _how_ a particular piece of code works.
To me this is an adequate description of most of the software 'tricks' presented to me as magic.
Wait wait wait... are you telling me that David Copperfield didn't use "rituals, symbols, actions, gestures, and language with the aim of utilizing supernatural forces" when he made the statue of liberty disappear?
As an example of jargon, the dictionary definition is irrelevant other than to emphasize that it is jargon. There are applicable broad arguments against jargon in general, of course, but as an example of jargon, it's not any worse than any other jargon term or phrase, such as "It's ____ all the way down."
If we want a definition that we can understand, the correct source is not the dictionary, but this quote from OG sci-fi author Arthur C. Clarke: “Any sufficiently advanced technology is indistinguishable from magic.”
With respect to programming, meta-programming is not indistinguishable from a spell cast by a mage in D&D. A better comparison is to prestidigitation, the entertainment art of doing a thing that appears to be impossible, even though everyone in the audience knows that there is a trick to it that can be explained and understood.
It's really that simple. "Magic" as a term of jargon means "A sufficiently advanced use of Ruby's meta-programming that is indistinguishable from a conjurer's trick to those who don't know the trick."
http://www.catb.org/jargon/html/M/magic.html
There are worse sins in programming jargon; like when you overuse technical terms so much that you lose the "point" of what it's supposed to do. Another one is using heavily overloaded abstract terms without explaining which variant you're thinking of. If you say "service" without context, I will come after you :)
"In Smalltalk, everything happens somewhere else."
I vividly recall that when I first installed Digitalk's Smalltalk/V, everything seemed to involve spooky action-at-a-distance.
Magic has a special form of non-locality. To look for the cause of "magic" one must either pray to some god or roll the dice and read the tea leaves. If hunting down the source of understanding feels like this, we call it magic.
Jargon can be carefully laid out and taught. Common practice can be learned and maintained.
Magic is a word invoked to intentionally tell you not to learn and to stop asking questions. It's insulting to the very nature of the programmer, who must ask these questions in order to understand the systems they are trying to describe.
As for the quote, which everyone has heard by now: "Any sufficiently advanced technology is indistinguishable from magic."
This is a cynic's perspective, which while valuable to a point, does not alone lead to that which we desire. We read this quote and think, ah yes, that is how I feel... I wish things were better.
"Magic" is in fact jargon, contrasting other meanings of the word with jargon itself is irrelevant to that.
This was my primary challenge.
Either you accept everything as jargon, or you actually read my reply and consider my perspective. I'm not offering a crisp definition, I'm merely adding some addition flavor which is at odds with the parent's as I understand.
In that sense, it does not imply "stop asking questions," nor does it imply "there is no answer." To me, it implies, "This may look like a supernatural entity is involved, but that's just a trick we're pulling. If we pull back the curtain, we'll find there's a little man with some levers and we'll see how it's done."
Tricks are fundamentally shocking and uncomfortable at first. Many people like this from time to time, but it shouldn't be the intent of our programs.
The programs should be written in a way that helps the reader learn. If that involves some clever reveals and abstraction / hiding then so be it. The best lessons are taught in stages.
They're mystifying at first, then you learn how to use them without looking under the hood, then you learn exactly how they work, then you start making your own.
The word "trick" is associated with prestidigitation. Unless you're entering the Underhanded C context, these "tricks" are more like magicians showing EACH OTHER how to do things.
"Here's how to make flowers appear out of your top hat."
"Ah!"
The whole point of science is separating the magic that works from the hocus pocus that doesn’t. Just because you understand it, just because we have equations, algorithms, and stories that explain the relationships between things, that doesn’t mean it’s not magic. It just means the magic is REAL.
It’s impossible for me to look at a computer, a server rack, a car, or a roomba and not see the magic. Just because I understand the principles behind them doesn’t rob me of the wonder of the universe.
The analogy I like to use is Hogwarts. Just because they study spells in that fictional world, just because they have schools and universities doesn’t mean the spells aren’t magic. They’re studying the magic available to them in that universe.
Thank you for reminding us of the everyday magic surrounding us.
> If you ever code something that “feels like a hack but it works,” just remember that a CPU is literally a rock that we tricked into thinking. Not to oversimplify: First you have to flatten the rock and put lightning inside it.
Neither of those are super closely linked to your comment. I just think you might get a kick out of them.
I 'understand' (more so then) them of course, the theory, the practice, but what magic that any of this works?!
Maybe it's just because we can't see it, and it oughtn't be any weirder than anything else, but I still find it nuts and have to try not to think about it too much. Nevermind the crazy bandwidth & latency & distances we've come to expect with the internet.
The idea of an atom, or a quark, is a construct that approximates reality. Nature doesn't care about our constructs. Just because we've kinda "figured it out" doesn't mean we've robbed nature of it's magic. We are only discovering the magic that was always there.
And, IMH(umble)O, the magic we discovered since the Renaissance is far cooler - far more magical - than anything the Alchemists could come up with in their wildest dreams.
I can appreciate how Lightroom works, or an electric car, or the electrical grid, etc. I don't have to know every last detail, but I should have some awareness of the fundamental principles on which these things are built.
Deferring this to "magic" in the sense that I say "I don't know how that works, no one can know, it's MAGIC" can be a lazy way to think. I think it's a slippery slope that gets us closer to psuedoscience, new-age gimmicks, and other forms of poor thinking and manipulation. We should all seek to understand how things really work (even at a coarse level) in this Demon Haunted World of ours.
(Even if this isn't how you interpret this word, I'm suggesting there is a risk that others do).
But for us working in it, who can see the layers upon layers of abstractions, it feels less magical and more like a miracle that any of this works at all.
Many of the devices you mention are programmed at such high levels that the programmers themselves rarely understand exactly what's going on beneath the surface. The hardest part of getting the thing to work at all is managing the complex web of dependencies underneath, not programming the actual functionality. Systems that appear magical are mostly running on a house of cards and person-years worth of frustration.
I also agree that the site is hard to read w/ grey text on a white background.
Dictionary.com definition Magic: NOUN the power of apparently influencing the course of events by using mysterious or supernatural forces: example: "suddenly, as if by magic, the doors start to open"
It represents things that happen that you don't understand how they happen. Not just you don't understand how they work when presented with the effect, but is resistant to being reverse-engineered.
In your typical programming environment there are ways to backtrack through code searches, type hierarchy management/overloads, interface implementations, type definitions, recasts, scope resolution, etc that you can deconstruct some "magic incantation" to figure out where it is calling and then what it is doing.
In dynamic languages (the article is about Ruby) this gets a lot more dicey, with duck typing, lack of strong typing or optional typing to enforce / document what types are being used where, sometimes dynamic scoping, macro expansions.
In those cases, IDEs are you friend in a BIG BIG way. They enable targetting searches, parsed/contextual navigations, type guessing even for some dynamic languages. IDE+static-ish typed languages is even better: back navigation to the type, navigate up the type hierarchies or compositions.
This differs from abstraction, which is fine. Abstractions are the bread and butter of programming. But if an abstraction is too leaky, or it interoperates badly with other abstractions applying to the same code... It ceases to be abstraction and becomes spooky action at a distance.
You could implement subclassing in a language via an inheritance chain or you could implement it via taking objects and replacing their various methods and fields with other methods and fields after they've been constructed. One is the object inheritance abstraction. The other is spooky action at a distance.
"What junior does not understand, is not magic."
To that, I say the difference between a mid-level and senior is that the senior knows "magic" actually is bad.
E.g. a "magical vacation" doesn't involve casting spells...
Likewise "magic" in a program doesn't mean we can't ever trace where the effects we see are coming from. Just that they were put in with metaprogramming, and not more conventional methods.
This is my definition of magic: when it _does_ so
That's my pet peeve with Rails and Rails-minded gems, which do such magic as a core tenet. Someone ends up being too smart for their own (and others) good, it looks lovely and clever from the outside, methods are added to core objects, often dynamically so, global-like state is rampant, lazy behaviour is pervasive.
Then something breaks, and you're left with behaviours that make no sense. Of course with enough time and energy one can see through the veil by diving deep in the bowels of the framework, but I don't quite like the thinly veiled judgemental statement of TFA that magic is just metaprogramming and that as a dev you should get your shit together, which does not help in the real world when all hell breaks lose in nonsensical ways because a prime directive has been violated†.
Tricks and prestidigitation have no business being used in systems that aim to be reliable.
† Blindly copying references to thread locals into another thread[0], assuming every possible one ever used in all apps and dependencies is either scalar (which they're usually not), deep-frozen (which they're usually not), or thread-safe (which they don't need to be, because they're, you know, thread local), can only be delicately described as "a bold move".
[0]: https://github.com/rails/rails/blob/6ec669b65d5cd47c98466192...
Like, when a design is magical, that means it has effects that aren’t fully understood. Like architectural decorations on buildings have real effects on the vibe of a neighborhood but we really don’t understand the specifics of how or why they affect us psychologically.
Personally I tend to use “plumbing”. It’s important, has a tangible result but it’s working are totally hidden unless you go looking for it.
I like to say to people that a good framework has a lot of plumbing, where others might call it magic.
> What's not magic
> What junior does not understand, is not magic
> Monkey-patching is not magic
> Metaprogramming is not magic
I've noticed this especially in the Rails community to talk about functionality they find fascinating and which either they don't understand or don't want to explain.
The FA does seem to specify a particular frustration that my pithy quote doesn't address
>>"It is common to see nowadays statements like “this is too magical for less experienced developers to understand”. As Matz says (reciting from memory), “Ruby is complex language to make developer’s life simple”, not the other way round.
>>Your car’s engine and your computer’s processor are pretty complicated, too, but that doesn’t mean that they are “magical”. Neither that you shouldn’t use them and stick to “less magical” solutions."
I think this is a separate point but it is one I agree with. Probably some nuance here, but I think the problem is less that something is seen as magic and more that something might be prematurely hobbled.
In python, if I see `print(5)`, I should know what that will do. Now, it's possible to do all sorts of magic and make it do something different (like print "five"). The reason that hijacking `print(5)` is magic is because when I look at it, I have reasonable expectations that are subverted.
The reason that magic is often considered bad is that if my code is supposed to subvert my expertise, then my expertise suddenly isn't useful to getting my job done. If I want to make it do something else, or debug it, I won't know where to go, because I should know how to debug `print(5)` or change it to `print(6)`, but now I don't know my way around my tools.
Maybe it's a connection to black boxes. If a reasonable user can't see how or why your magic works, and can't debug or direct your magic, it's too magical. Yes, that's subjective, but too bad. Maybe "opaque" is a better word.
'Magic' is, when things – after proper enchantment and ritual – sometimes happen as expected. But you cannot explain why (other than 'because of proper enchantment').
I guess we got, what we called for.