Predicated upon the definition of "magic" provided in the article: What is it, if anything, about magic that draws people to it? Is there a process wherein people build tolerance and acceptance to opaque abstractions through learning? Or, is it acceptance that "this is the way things are done", upheld by cargo cult development, tutorials, examples, and the like, for the sake of commercial expediency? I can certainly understand that seldom is time afforded to building a deep understanding of the intent, purpose, and effect of magic abstractions under such conditions.

Granted, there are limits to how deep one should need to go in understanding their ecosystem of abstractions to produce meaningful work on a viable timescale. What effect does it have on the trade to, on the other hand, have no limit to the upward growth of the stack of tomes of magical frameworks and abstractions?

▲

pdonis 2 hours ago | parent | next [-]

> What is it, if anything, about magic that draws people to it?

Simple: if it's magic, you don't have to do the hard work of understanding how it works in order to use it. Just use the right incantation and you're done. Sounds great as long as you don't think about the fact that not understanding how it works is actually a bug, not a feature.

▲

wvenable an hour ago | parent | next [-]

> Sounds great as long as you don't think about the fact that not understanding how it works is actually a bug, not a feature.

That's such a wrong way of thinking. There is simply a limit on how much a single person can know and understand. You have to specialize otherwise you won't make any progress. Not having to understand how everything works is a feature, not a bug.

You not having to know the chemical structure of gasoline in order to drive to work in the morning is a good thing.

▲

xantronix 41 minutes ago | parent [-]

But having to know how a specific ORM composes queries targetting a specific database backend, however, is where the magic falls apart; I would rather go without than deal with such pitfalls. If I were to hazard a guess, things like this are where the author and I are aligned.

	▲	wvenable 34 minutes ago \| parent [-]
		> to know how a specific ORM composes queries targetting a specific database backend, however, is where the magic falls apart I've never found this to be a particular problem. Most ORMs are actually quite predictable. I've seen how my ORM constructs constructs queries for my database and it's pretty ugly but also it's actually also totally good. I've never really gained any insight that way. But the sheer amount of time effort I've saved by using an ORM to basically do the same boring load/save pattern over and over is immeasurable. I can even imagine going back and doing that manually -- what a waste of time, effort, and experience that would be.

▲

socalgal2 2 hours ago | parent | prev | next [-]

Or is just a specialization choice. Taxi drivers don't care how a car works, they hire a mechanic for that. Doctors don't care how a catscan works they just care that it provides the data they need in a useful format.

	▲	xantronix 35 minutes ago \| parent \| next [-]
		This analogy baffles me. I don't think anybody here is making the argument that we must know how all of our tools work at a infinitesimally fundamental level. Rather, I think software is an endless playground and refuge for people who like to make their own flavours of magic for the sake of magic.
	▲	c22 an hour ago \| parent \| prev [-]
		I like the definition of magic I learned from Penn Jillette, (paraphrased): magic is just someone spending way more resources to produce the result than you expected.

▲

farley13 an hour ago | parent | prev [-]

I know magic has a nice Arthur C. Clarke ring to it, but I think arguing about magic obscures the actual argument.

It's about layers of abstraction, the need to understand them, modify them, know what is leaking etc.

I think people sometimes substitute magic when they mean "I suddenly need to learn a lower layer I assumed was much less complex ". I don't think anyone is calling the linux kernal magic. Everyone assumes it's complex.

Another use of "magic" is when you find yourself debugging a lower layer because the abstraction breaks in some way. If it's highly abstracted and the inner loop gives you few starting points ( while (???) pickupWorkFromAnyWhere() )). It can feel kafkaesque.

I sleep just fine not knowing how much software I use exactly works. It's the layers closest to application code that I wish were more friendly to the casual debugger.

	▲	xantronix 42 minutes ago \| parent [-]
		To me, it's much less of an issue when it works, obviously, but far more of a headache when I need to research the "magic" in order to make something work which would be fairly trivially implemented with fewer layers of abstraction.

▲

3form 2 hours ago | parent | prev [-]

I think it's "this is the way things are done in order to achieve X". Where people don't question neither whether this is the only way to achieve X, nor whether they do really care about X in the first place.

It seems common with regard to dependency injection frameworks. Do you need them for your code to be testable? No, even if it helps. Do you need them for your code to be modular? You don't, and do you really need modularity in your project? Reusability? Loose coupling?