August 17th, 2024

A Definition of Magic in Programming Languages

The article defines "magic" in programming as a continuum of complexity in understanding code, influenced by constructs like inheritance and monkeypatching, emphasizing rational discussions on its costs and benefits.

Read original articleLink Icon
A Definition of Magic in Programming Languages

The article provides a nuanced definition of "magic" in programming languages, describing it as a continuum rather than a binary concept. Magic refers to the complexity involved in understanding a piece of code, particularly how many other code sections must be consulted to grasp its functionality. The author emphasizes that magic is not inherently good or bad; rather, it represents a cost that can either provide significant benefits or be burdensome. Various programming constructs contribute to this magic, including implicit methods, inheritance, polymorphism, monkeypatching, and arbitrary compositions. Each of these elements can increase the difficulty of understanding code, especially for those unfamiliar with the codebase. The article concludes by asserting that discussions about magic should focus on its costs and benefits rather than emotional reactions, advocating for a rational approach to understanding the implications of magic in programming.

- Magic in programming is defined as the complexity of understanding code based on external references needed.

- It exists on a continuum, with varying degrees of magic present in all code.

- Magic is not inherently good or bad; it represents a cost that can yield benefits or create challenges.

- Constructs like inheritance and monkeypatching can significantly increase the level of magic in code.

- Rational discussions about magic should focus on its costs and benefits rather than emotional responses.

Link Icon 3 comments
By @rendaw - 8 months
I got into an argument about black magic in a library with someone and have been thinking about this since.

I think "magic" is fundamentally "hidden dependencies" that prevent full reasoning about a piece of code. Like functions that use globals/thread locals to avoid passing in context, or a smart algorithm that makes a decision based on two supposedly independent arguments, or whatever. Authors recognized these dependencies, but think it makes using the library overly burdensome, or think it somehow reflects badly on them, and then go out of their way to obscure them.

It's similar to TFA's definition, but I feel like TFA's definition could just as easily describe spaghetti code which I don't think anyone would consider magic.

By @chii - 8 months
Sufficiently advanced levels of indirection is indistinguishable from magic!
By @yutuuuuu - 8 months
Reduce magic by striving for reentrancy and referential transparency.