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

101–110 of 138 posts

Re: I Don't Like Magic

#101

Post by hyencomper »

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…

If your project is on Github, you can also use https://deepwiki.com/. I have used it to get an overview of a new codebase quickly.

Re: I Don't Like Magic

#102

Post by bigstrat2003 »

james_marks wrote: post #19
tokenless wrote: post #8

The 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 that one can make good cloth with a loom using less effort than before. With AI one has to choose between less effort, or good quality. You can't get both.

Re: I Don't Like Magic

#103

Post by sriku »

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…

This - I even ran Claude to produce a security eval of openclaw for fun and it was mostly spot on - https://sriku.org/files/openclaw-secreport-claude-13feb2026....

Re: I Don't Like Magic

#104

Post by dnlzro »

piekvorst wrote: post #9
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.

You can learn JavaScript and code for life. You can’t learn React and code for life. Yeah, JavaScript is an illusion (to be exact, a concept). But it’s the one that we accept as fundamental. People need fundamentals to rely upon.

The only reason why you regard JavaScript as “fundamental” is that it’s built into the browser. Sure, you can draw that line, but at least acknowledge that there’s many places to draw the line.

I’d rather make comparative statements, like “JavaScript is more fundamental than React,” which is obviously true. And then we can all just find the level of abstraction that works for us, instead of fighting over what technology is “fundamental.”

Re: I Don't Like Magic

#105

Post by Izkata »

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 this came out in the era of jquery and mustachejs generating strings of HTML from templates instead of targeted updates).

Re: I Don't Like Magic

#106

Post by bryanrasmussen »

monkpit wrote: post #52
sodapopcan wrote: post #14

Earlier quoted context omitted.

The problem with this is that it means you have to read guides which it seems no one wants to do. It drives me nuts. But ya, I hate when people say they don't like "magic." It's not magic, it's programming.

Magic refers to specific techniques used in programming, an people generally dislike these techniques once they have formed any opinion.

do people generally dislike magic once they have formed an opinion, or is it just that people who dislike magic are more prone to voicing that opinion, why, if magic is disliked by people experienced enough to form opinions, does it keep coming back around?

I would suppose the people who create "magic" solutions have at least voiced an opinion that they like magic and the people who take up those solutions the same, for the record I too dislike magic but my feeling is that I am somewhat in the minority on that.

Re: I Don't Like Magic

#107

Post by bryanrasmussen »

sodapopcan wrote: post #14
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…

The problem with this is that it means you have to read guides which it seems no one wants to do. It drives me nuts. But ya, I hate when people say they don't like "magic." It's not magic, it's programming.

https://medium.com/luminasticity/laborers-craftsmen-and-arti...

in my experience among personality types of programmers both laborers and artists are opposed to the reading of guides, I think the laborers due to laziness and the artists due to a high susceptibility to boredom and most guides are not written to the intellectually engaging level of SICP.

Craftsmen are naturally the type to read the guide through.

Of course if you spend enough time in the field you end up just reading the docs, more or less, because everybody ends up adapting craftsmen habits over time.

Re: I Don't Like Magic

#108

Post by bitwize »

goatlover wrote: post #87
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…

It's funny how Lisp has been criticized for its ability to create a lot of macros and DSLs, then Java & JavaScript came along and there was an explosion of frameworks and transpiled languages in JVM, Node or the Browser.

"The problem with Scheme is all of the implementations that are incompatible with one another because they each add their own nonstandard feature set because the standard language is too small." Sometimes with an added subtext of "you fools, you should have just accepted R6RS, that way all Schemes would look like Chez Scheme or Racket and you'd avoid this problem".

Meanwhile in JavaScript land: Node, Deno, Bun, TypeScript, JSX, all the browser implementations which may or may not support certain features, polyfills, transpiling, YOLOOOOO

Re: I Don't Like Magic

#109

Post by est »

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.

Re: I Don't Like Magic

#110

Post by lioeters »

llbbdd wrote: post #75
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…

This code only works if run in a browser composed of millions of lines of C++.

I felt a great disturbance in the Force, as if millions of React devs cried out in terror and were suddenly silenced.
Post reply on HN