Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

I Don't Like Magic

adactio.com

Post reply on HN
Print view View original

91–100 of 138 posts

Re: I Don't Like Magic

#91

Post by skydhash »

UncleMeat wrote: post #41
mgaunard wrote: post #33

Earlier quoted context omitted.

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…

> the huge majority of software engineers are not aware of almost any transformations that an optimizing compiler does

They may not, but they can be. Buy a book like "Engineering a Compiler", familiarize yourself with the Optimization chapters, study some papers and the compiler source code (most are OSS). Optimization techniques are not spell locked in a cave under a mountain waiting for the chosen one.

We can always verify the compiler that way, but it's costly. Instead, we trust the developers just like we trust that the restaurant's chef are not poisoning our food.

Re: I Don't Like Magic

#92

Post by dnautics »

thestackfox wrote: post #43

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

int main() is magic (and it's a framework).

Re: I Don't Like Magic

#94

Post by dnautics »

hyperhopper wrote: post #30

This person's distinction between "library" and "framework" is frankly insane. React, which just is functions to make DOM trees and render them is a framework? There is a reason there are hundreds of actual frameworks that exist to make structure about using these functions. At this point, he should stop using any high level language! Java/python are just a big frameworks calling his bytecode, what magical frameworks…

library vs framework (you call a library, a framework calls you) is pretty typical and arguably very useful distinction.

calling a framework necessarily magic is the weird thing.

Re: I Don't Like Magic

#95

Post by pazimzadeh »

jv22222 wrote: post #72
vladms wrote: post #11

The advantage of frameworks is to have a "common language" to achieve some goals together with a team. A good framework hides some of the stupid mistakes you would do when you would try to develop that "language" from scratch. When you do a project from scratch, if you work enough on it, you end up wishing you would have started differently and you refactor pieces of it. While using a framework I sometimes have momen…

I used Claude to document, in great detail, a 500k-line codebase in about an hour of well-directed prompts. Just fully explained it, how it all worked, how to get started working on it locally, the nuance of the old code, pathways, deployments using salt-stack to AWS, etc. I don't think the moat of "future developers won't understand the codebase" exists anymore. This works well for devs who write their codebase usin…

Hey, I also sent this to feedback@nugget.one, but just in case it doesn't arrive:

I wasn't able to get into your 'startup ideas' site.

Signing in with google led to internal server error, and signing in with a password, I never received the verification email.

Thought I would let you know. Can't wait to get those sweet startup ideas....!

Re: I Don't Like Magic

#96

Post by jv22222 »

pazimzadeh wrote: post #95
jv22222 wrote: post #72

Earlier quoted context omitted.

I used Claude to document, in great detail, a 500k-line codebase in about an hour of well-directed prompts. Just fully explained it, how it all worked, how to get started working on it locally, the nuance of the old code, pathways, deployments using salt-stack to AWS, etc. I don't think the moat of "future developers won't understand the codebase" exists anymore. This works well for devs who write their codebase usin…

Hey, I also sent this to feedback@nugget.one, but just in case it doesn't arrive: I wasn't able to get into your 'startup ideas' site. Signing in with google led to internal server error, and signing in with a password, I never received the verification email. Thought I would let you know. Can't wait to get those sweet startup ideas....!

Thanks, I've been very focused on lightwave and as a result let that one slide a bit. I'll try to get it working in next week or so.

Re: I Don't Like Magic

#97

Post by antonvs »

skydhash wrote: post #89
antonvs wrote: post #81

Earlier quoted context omitted.

Are you seriously saying you can’t understand the parallel being drawn here? If you “don’t like magic”, you can’t use a compiler.

Is a compiler magic? Did they came from an electronic heaven? There are plenty of books, papers, courses,... that explains how compiler works. When people are talking about "magic", it usually means choosing a complex solution over a simple one, but with an abstraction that is ill-fitted. Then they use words like user-friendly, easy to install with curl|bash, etc to lure us into using it.

I’m referring to what it actually says in the article, such as, “I don’t like using code that I haven’t written and understood myself.”

Reading comprehension is not magic.

Re: I Don't Like Magic

#98

Post by socalgal2 »

xantronix wrote: post #49
socalgal2 wrote: post #18

Earlier quoted context omitted.

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.

I feel like I'm responding more to the op. Maybe a more concrete example, there are several hit games, Undertale is one I know personally, where the creator is an artist who learned just enough programming in a relatively high level language to ship a hit and beloved game. They didn't need to know the details of how graphics get put on the screen, nor did they need to learn memory management or bytes and bits.

> I don’t like using code that I haven’t written and understood myself.

Maybe it's true for the author but it's not true for lots of productive people in every field and there's plenty of examples of excellence operating at a higher level.

Re: I Don't Like Magic

#99

Post by ompogUe »

lo_zamoyski wrote: post #69

This reads like a transcript of a therapy session. He never gives any real reasons. It's mostly a collection of assertions. This guy must never have worked on anything substantial. He also must underestimate the difficulty of writing software as well as his reliance on the work of others. > I don’t like using code that I haven’t written and understood myself. Why stop with code? Why not refine beach sand to grow your…

>> Abstractions often really do speed up production, but you pay the price in maintenance later on.

> What? I don't know what this means. Good abstractions allow us to better maintain code. Maintaining something that hasn't been structured into appropriate abstractions is a nightmare.

100% agree with this. Name it well, maintain it in one place ... profit.

It's the not abstracting up front that can catch you: The countless times I have been asked to add feature x, but that it is a one-off/PoC. Which sometimes even means it might not get the full TDD/IoC/feature flag treatment (which aren't always available depending upon the client's stack).

Then, months later get asked to created an entire application or feature set on top of that. Abstracting that one-off up into a method/function/class tags and bags it: it is now named and better documented. Can be visible in IDE, called from anywhere and looped over if need be.

There is obviously a limit to where the abstraction juice isn't worth the squeeze, but otherwise, it just adds superpowers as time goes on.

Re: I Don't Like Magic

#100

Post by mey »

ZeWaka wrote: post #58
fragmede wrote: post #55

Earlier quoted context omitted.

Given the verbosity of Java's hello world vs Python's, you'd walk away with the conclusion that Java should never be used for anything, but that would be a mistake.

Clearly Java only belongs on things like credit cards and Minecraft /s

Why do you have to remind us that Java Card exists?
Post reply on HN