undefined

points

[-]

> 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.

by socalgal23 hours ago|

parent|

[-]

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.

by xantronix2 hours ago|

parent|

[-]

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.

by c222 hours 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.

by wvenable2 hours ago|

parent|

prev|

[-]

> 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.

by xantronix2 hours 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.

by wvenable2 hours 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.

by farley132 hours 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.

by xantronix2 hours 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.

by 3form3 hours ago|

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?