I Don't Like Magic • Hacker News Board

Re: I Don't Like Magic

#41

Post by UncleMeat » Sat, Feb 21, 2026, 10:31 PM UTC

mgaunard wrote: post #33

SirMaster wrote: post #31

So you don’t like compilers? Or do you really full understand how they are working? How they are transforming your logic and your asynchronous code into machine code etc.

I think most traditional software engineers do indeed understand what transformations compilers do.

I'd wager a lot of money that the huge majority of software engineers are not aware of almost any transformations that an optimizing compiler does. Especially after decades of growth in languages where most of the optimization is done in JIT rather than a traditional compilation process.

The big thing here is that the transformations maintain the clearly and rigorously defined semantics such that even if an engineer can't say precisely what code is being emitted, they can say with total confidence what the output of that code will be.

Re: I Don't Like Magic

#42

Post by xantronix » Sat, Feb 21, 2026, 10:32 PM UTC

farley13 wrote: post #25

pdonis wrote: post #13

Earlier quoted context omitted.

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

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 assume…

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.

Re: I Don't Like Magic

#43

Post by thestackfox » Sat, Feb 21, 2026, 10:32 PM UTC

I get the sentiment, but "I don’t like magic" feels like a luxury belief.

Electricity is magic. TCP is magic. Browsers are hall-of-mirrors magic. You’ll never understand 1% of what Chromium does, and yet we all ship code on top of it every day without reading the source.

Drawing the line at React or LLMs feels arbitrary. The world keeps moving up the abstraction ladder because that’s how progress works; we stand on layers we don’t fully understand so we can build the next ones. And yes LLM outputs are probabilistic, but that's how random CSS rendering bugs felt to me before React took care of them

The cost isn’t magic; the cost is using magic you don’t document or operationalize.

Re: I Don't Like Magic

#44

Post by xantronix » Sat, Feb 21, 2026, 10:33 PM UTC

wvenable wrote: post #27

pdonis wrote: post #13

Earlier quoted context omitted.

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

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

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.

Re: I Don't Like Magic

#45

Post by advael » Sat, Feb 21, 2026, 10:34 PM UTC

mgaunard wrote: post #33

SirMaster wrote: post #31

So you don’t like compilers? Or do you really full understand how they are working? How they are transforming your logic and your asynchronous code into machine code etc.

I think most traditional software engineers do indeed understand what transformations compilers do.

Yea, the pervasiveness of this analogy is annoying because it's wrong (because a compiler is deterministic and tends to be a single point of trust, rather than trusting a crowdsourced package manager or a fuzzy machine learning model trained on a dubiously-curated sampling of what is often the entire internet), but it's hilarious because it's a bunch of programmers telling on themselves. You can know, at least at a high level of abstraction, what a compiler is doing with some basic googling, and a deeper understanding is a fairly common requirement in computer science education at the undergrad level

Don't get me wrong, I don't think you need or should need a degree to program, but if your standard of what abstractions you should trust is "all of them, it's perfectly fine to use a bunch of random stuff from anywhere that you haven't the first clue how it works or who made it" then I don't trust you to build stuff for me

Re: I Don't Like Magic

#46

Post by nosefurhairdo » Sat, Feb 21, 2026, 10:34 PM UTC

cbeach wrote: post #35

> I’ve always avoided client-side React because of its direct harm to end users (over-engineered bloated sites that take way longer to load than they need to). A couple of megabytes of JavaScript is not the "big bloated" application in 2026 that is was in 1990. Most of us have phones in our pockets capable of 500Mbps. The payload of an single page app is trivial compared to the bandwidth available to our devices. I'd…

React + ReactDOM adds ~50kb to a production bundle, not even close to a couple of mbs. React with any popular routing library also makes it trivial to lazy load js per route, so even with a huge application your initial js payload stays small. I ship React apps with a total prod bundle size of ~5mb, but on initial load only require ~100kb.

The idea that React is inherently slow is totally ignorant. I'm sympathetic to the argument that many apps built with React are slow (though I've not seen data to back this up), or that you as a developer don't enjoy writing React, but it's a perfectly fine choice for writing performant web UI if you're even remotely competent at frontend development.

Re: I Don't Like Magic

#47

Post by sevensor » Sat, Feb 21, 2026, 10:36 PM UTC

noelwelsh wrote: post #7

If you have this attitude I hope you write everything in assembly. Except assembly is compiled into micro-ops, so hopefully you avoid that by using an 8080 (according to a quick search, the last Intel CPU to not have micro-ops.) In other words, why is one particular abstraction (e.g. Javscript, or the web browser) ok, but another abstraction (e.g. React) not? This attitude doesn't make sense to me.

A good abstraction relieves you of concern for the particulars it abstracts away. A bad abstraction hides the particulars until the worst possible moment, at which point everything spills out in a messy heap and you have to confront all the details. Bad abstractions existed long before React and long before LLMs.

Re: I Don't Like Magic

#48

Post by Klonoar » Sat, Feb 21, 2026, 10:39 PM UTC

I feel like a lot of the comments here are from people who either weren't around for, or didn't grow up in, the era where adactio and the wider web dev scene (Zeldman, etc) were the driving force of things on the web.

If you've only been in a world with React & co, you will probably have a more difficult time understanding the point they're contrasting against.

(I'm not even saying that they're right)

Re: I Don't Like Magic

#49

Post by xantronix » Sat, Feb 21, 2026, 10:39 PM UTC

socalgal2 wrote: post #18

pdonis wrote: post #13

Earlier quoted context omitted.

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

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.

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.

Re: I Don't Like Magic

#50

Post by wvenable » Sat, Feb 21, 2026, 10:40 PM UTC

xantronix wrote: post #44

wvenable wrote: post #27

Earlier quoted context omitted.

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

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.

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