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

111–120 of 138 posts

Re: I Don't Like Magic

#111

Post by Spivak »

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…

When everything is magic I think we need a new definition of magic or maybe a new term to encapsulate what's being described here.

The key feature of magic is that it breaks the normal rules of the universe as you're meant to understand it. Encapsulation or abstraction therefore isn't, on its own, magical. Magic variables are magic because they break the rules of how variables normally work. Functional components/hooks are magic because they're a freaky DSL written in JS syntax where your code makes absolutely no sense taken as regular JS. Type hint and doctype based programming in Python is super magical because type hints aren't supposed to affect behavior.

Re: I Don't Like Magic

#112

Post by oftenwrong »

fragmede wrote: post #55
yellowapple wrote: post #34

Earlier quoted context omitted.

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…

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.

    #!/usr/bin/env java --source 25
    void main() {
        IO.println("Hello, World!");
    }

Re: I Don't Like Magic

#113

Post by t-writescode »

oftenwrong wrote: post #112
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.

#!/usr/bin/env java --source 25 void main() { IO.println("Hello, World!"); }

Many of Java’s hatred comes from old Java. The rest comes from Spring.

Re: I Don't Like Magic

#114

Post by not_kurt_godel »

est wrote: post #109
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…

> Electricity is magic. TCP is magic. Hmm, they aren't if you have a degree. > Browsers are hall-of-mirrors magic More like Chromium with billions LoC of C++ is magic. I think browser shouldn't be that complex.

> I think browser shouldn't be that complex.

how is browser formed. how curl get internent

Re: I Don't Like Magic

#115

Post by t-writescode »

est wrote: post #109
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…

> Electricity is magic. TCP is magic. Hmm, they aren't if you have a degree. > Browsers are hall-of-mirrors magic More like Chromium with billions LoC of C++ is magic. I think browser shouldn't be that complex.

I took classes on how hardware works with software, and I still am blown away when I really think deeply about how on earth we can make a game render something at 200fps, even if I can derive how it should work.

It’s quite magical.

Re: I Don't Like Magic

#116

Post by MrJohz »

Izkata wrote: post #105
overgard wrote: post #62

React is a weird beast. I've been using it for years. I think I like it? I use it for new projects too, probably somewhat as a matter of familiarity. I'm not entirely convinced it's a great way to code, though. My experience with it is that functional components always grow and end up with a lot of useEffect calls. Those useEffects make components extremely brittle and hard to reason about. Essentially it's very hard…

> so either you ask AI to do it I dunno, AI tools love adding not only useEffect but also unnecessary useMemo. > I don't know why people think the virtual DOM is a performance boost. It was advertised as one of the advantages when React was new, due to the diffing browsers would only need to render the parts that changed instead of shoving a whole subtree into the page and the having to do all of it (because remember…

Patching the DOM existed long before React, that wasn't a new technique. IIRC, the idea was more that the VDOM helped by making batching easier and reducing layout thrashing, where you write to the DOM (scheduling an asynchronous layout update), read from the DOM (forcing that thenlayout update to be executed synchronously now).

That said, none of that is specific to the VDOM, and I think a lot of the impression that "VDOM = go fast" comes from very early marketing that was later removed. I think also people understand that the VDOM is a lightweight, quick-to-generate version of the DOM, and then assume that the VDOM therefore makes things fast, but forget about (or don't understand) the patching part of React, which is also necessary if you've got a VDOM and which is slow.

Re: I Don't Like Magic

#117

Post by nickm12 »

This is such a strange take. The definition of "magic" in this post is apparently "other people's code" and it even admits that that no practical program can avoid depending on other people's code. I think what the author is really saying that they like to minimize dependencies and abstractions, particularly in web client development, and then throws in a connection to coding assistants.

I don't see it, either the notion that other people's code is to be avoided for its own sake nor that depending on LLM-generated code is somehow analogous to depending on React.

Re: I Don't Like Magic

#118

Post by ookblah »

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.

his line (admittedly he acknowledges) is just purely arbitrary and thus basically boils down to his own comfort and opinion. i guess we are all entitled to that, so maybe nothing to really take away from all this. has he read the whole react codebase line by line to understand what works and doesn't? just handwaves it away as some unneeded "abstraction".

Re: I Don't Like Magic

#119

Post by noelwelsh »

kens wrote: post #26
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.

Did someone ask about Intel processor history? :-) The Intel 8080 (1974) didn't use microcode, but there were many later processors that didn't use microcode either. For instance, the 8085 (1976). Intel's microcontrollers, such as the 8051 (1980), didn't use microcode either. The RISC i860 (1989) didn't use microcode (I assume). The completely unrelated i960 (1988) didn't use microcode in the base version, but the fl…

That was interesting. Thanks!

Re: I Don't Like Magic

#120

Post by taneq »

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…

How did you vet the quality of the documentation? I have no doubt that an LLM could produce a great deal of plausible-sounding documentation in short order. Even assuming you’re already completely familiar with the code base, reading through that documentation and fact checking it would take a great deal of effort.

What’s the quality like? I’d expect it to be riddled with subtly wrong explanations. Is Claude really that much better than older models (eg. GPT-4)?

Edit: Oops, just saw your other comment saying you’d verified it manually.

Post reply on HN