Let's discuss the concept of magic — what are your opinions?
In the context of computer programming, magic is an informal term for abstraction; it is used to describe code that handles complex tasks while hiding that complexity to present a simple interface. The term is somewhat tongue-in-cheek, and often carries bad connotations, implying that the true behavior of the code is not immediately apparent. For example, Perl's polymorphic typing and closure mechanisms are often called "magic".
Latest comments (40)
Visit the Paymydoctor official portal paymydoctor.page/.
Magic without documentation = good luck, have fun
There is a word by the German Author/Poet Rainer Maria Rilke "There is magic in every beginning" ("Jedem Anfang wohnt ein Zauber inne").
When you start to learn a new Framework everything seems to be magic. It took me a long moment understand how module mocking works in jest. (the moment is not over yet).
I don't like magic if I am not able to understand whats behind it. I am glad that I first learned JS Promises and then async/await. New JS Programmers need to learn Promises but will not use them much. It will always feel awkward for them. For me async/await actually felt like "syntactical sugar". For them its a language feature, that will feel as magic once they want to understand why something happens when.
Frameworks take this to a whole new level, where you apply some attributes to your html code and you have half an SPA - and a hard time to understand how it works.
I like VanillaJS because there is no magic (as long as you dont do it).
Hating magic is a form of Survivorship/Availability bias.
Yeah you remember all the abstractions that got in your way, either by not letting you know the underlying details or requiring a lot of upfront reading to grok.
But you are forgetting all the good ones that you understood intuitively and/or saved you lifetimes of work.
I remember when Microsoft first created Excel, their motto was something like "Kill all the dependencies".
Is magic not just misdirection? Which is kind of what you're trying to do when creating an API that encapsulates a bunch of complex logic, but presents a simple interface to a user.
I don't see a problem with using the term.
Magic/abstraction is a spectrum. There’s good magic and there’s bad one.
My criteria is, if a magic feels nature, almost close to language primitives, and doesn’t come with easy footgun, it’s good magic.
So the two points for good magic are:
Bad magic often goes wrong easily, and is always difficult to debug. The ones that stand in the middle, I have mix feeling and would approach with caution.
Like for example, MobX’s reactivity is very powerful. But when they allow implicit circular dependency, one can get into a dead loop. Upside is they’re aware of the problem and make it relatively easy to debug.
I would personally use MobX, avoid circular dep with caution (cus that’s usually a sign of bad code structure on your part). But I wouldn’t feel comfy to use it in production codebase maintained by a team of devs of varied levels.
To me...Magic is like having prebuilt functions like Sort. As opposed to manually have to come up with an algorithm to sort things myself. Abstraction is good...But you can't convince me that frameworks like React makes since easier...they become so complex that they defeat the whole purpose.
To me...Magic is like having pre-built functions like Sort. As opposed to manually have to come up with an algorithm to sort things myself. Abstraction is good...But you can't convince me that frameworks like React makes since easier...they become so complex that they defeat the whole purpose.
This kind of magic can offer us a lot in terms of productivity gains, but we should never be dependent on it, and should always use low-magic solutions until we understand the underlying technologies well.
What I mean for example is that you shouldn't try to use React before learning how to build a site with plain HTML, CSS, and JS.
You shouldn't use Nest.js before learning Express (or maybe even the raw
httplibrary).You shouldn't use ORMs without learning SQL.
If you skip learning the fundamentals, and depend on magic, you'll be in trouble when the going gets tough.
Of course, I'm not saying we have to dig silicon out of the ground and build CPUs with our bare hands before learning to program (though I'm sure that would be pretty enlightening).
But any time we use a framework or library, we should try to sense when it might be obscuring the fundamentals and preventing us from learning something important. Not always easy, but I think it's something you can get a sense for.