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 Don't Like Magic
31–40 of 138 posts
Re: I Don't Like Magic
#32So 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.
At least compilers are deterministic
Re: I Don't Like Magic
#33So 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.
Re: I Don't Like Magic
#34You could walk through the framework so you then understand it. There are several "let's create react from scratch" articles https://pomb.us/build-your-own-react/ Certain frameworks were so useful they arguably caused an explosion the productivity. Rails seems like one. React might be too.
Thanks to that page letting me see how many dozens of lines of code React needs to do the equivalent of
const element = document.createElement("h1");
element.innerHTML = "Hello";
element.setAttribute("title", "foo");
const container = document.getElementById("root");
container.appendChild(element);
Re: I Don't Like Magic
#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 much rather optimise for engineer ergonomics than shave a couple of milliseconds off the initial page load.
Re: I Don't Like Magic
#36> And so now we have these “magic words” in our codebases. Spells, essentially. Spells that work sometimes. Spells that we cast with no practical way to measure their effectiveness. They are prayers as much as they are instructions.
Autovectorization is not a programming model. This still rings true day after day.
Re: I Don't Like Magic
#37So 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.
[Autovectorization is not a programming model](https://pharr.org/matt/blog/2018/04/18/ispc-origins).
Sure, obviously, we will not undersatnd every single little thing down to the tiniest atoms of our universe. There are philosophical assumptions underlying everything and you can question them (quite validly!) if you so please.
However, there are plenty of intermediate mental models (or explicit contracts, like assembly, elf, etc.) to open up, both in "engineeering" land and "theory" land, if you so choose.
Part of good engineering as well is deciding exactly when the boundary of "don't cares" and "cares" are, and how you allow people to easily navigate the abstraction hierarchy.
That is my impression of what people mean when they don't like "magic".
Re: I Don't Like Magic
#38The AI pilled view is coding is knitting and AI is an automated loom. But it is not quite the case. The hand coded solution may be quicker than AI at reaching the business goal. If there is an elegant crafted solution that stays in prod 10 years and just works it is better than an initially quicker AI coded solution that needs more maintenance and demands a team to maintain it. If AI (and especially bad operators of…
Doesn’t the loom metaphor still hold? A badly operated loom will create bad fabric the same way badly used AI will make unsafe, unscalable programs. Anything that can be automated can be automated poorly, but we accept that trained operators can use looms effectively.
The difference is the loom is performing linear work.
Programming is famously non-linear. Small teams making billion dollar companies due to tech choices that avoid needing to scale up people.
Yes you need marketing, strategy, investment, sales etc. But on the engineering side, good choices mean big savings and scalability with few people.
The loom doesn't have these choises. There is no make a billion tshirts a day for a well configured loom.
Now AI might end up either side of this. It may be too sloppy to compete with very smart engineers, or it may become so good that like chess no one can beat it. At that point let it do everything and run the company.
Re: I Don't Like Magic
#39You could walk through the framework so you then understand it. There are several "let's create react from scratch" articles https://pomb.us/build-your-own-react/ Certain frameworks were so useful they arguably caused an explosion the productivity. Rails seems like one. React might be too.
Thanks to that page letting me see how many dozens of lines of code React needs to do the equivalent of const element = document.createElement("h1"); element.innerHTML = "Hello"; element.setAttribute("title", "foo"); const container = document.getElementById("root"); container.appendChild(element); I now have even less interest in ever touching a React codebase, and will henceforth consider the usage of React a code…
All of that is the JavaScript equivalent of
Hello
Re: I Don't Like Magic
#40You could walk through the framework so you then understand it. There are several "let's create react from scratch" articles https://pomb.us/build-your-own-react/ Certain frameworks were so useful they arguably caused an explosion the productivity. Rails seems like one. React might be too.
Thanks to that page letting me see how many dozens of lines of code React needs to do the equivalent of const element = document.createElement("h1"); element.innerHTML = "Hello"; element.setAttribute("title", "foo"); const container = document.getElementById("root"); container.appendChild(element); I now have even less interest in ever touching a React codebase, and will henceforth consider the usage of React a code…
To be fair, if all you need is to add elements to a child you don’t need React.
Maybe nobody needs React, I’m not a fan. But a trivial stateless injection of DOM content is no argument at all.