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

121–130 of 138 posts

Re: I Don't Like Magic

#121

Post by atoav »

This kind of "magical UX design" is the most common source of me cursing equipment I interact with. A good example

When I design hardware interfaces one of my main rules is that user agency should be maximized where needed. That requires the manufacturer to trust (or better: ensure) that the user has a meaningful mental model of the device they are using. Your interface then has to honor this mental model at all times.

So build a hammer and show the user how to use it effectively, don't build a SmartNailPuncher3000 that may or may not work depending if the user is holding it right and has selected the wrong mode by touching the wrong part.

Re: I Don't Like Magic

#122

Post by jemmyw »

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.

And actually further to your point, I would assume that many more people who code in Javascript have read the React codebase and not the v8 codebase.

I've read the react source, and some of v8. Imagine how you'd implement hooks, you're probably not too far away. It's messier than you'd hope, but that's kind of the point of an abstraction anyway. It's really not magic, I really dislike that term when all you're doing is building on something that is pretty easy to read and understand. v8 on the other hand is much harder, although I will say I found the code better organised and explained than React.

Re: I Don't Like Magic

#123

Post by WJW »

fragmede wrote: post #56
WJW wrote: post #22

Earlier quoted context omitted.

Oh no! Reading! Sorry for the snark but why is this such a problem?

Because people won't do it.

Sounds like a them problem. If they can't be bothered to learn how to use their tools, it won't be a surprise that they then won't know how to use them. A free advantage to those of us that do dedicate the time to read the docs I guess.

Re: I Don't Like Magic

#124

Post by rerdavies »

bigstrat2003 wrote: post #102
james_marks wrote: post #19

Earlier quoted context omitted.

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.

Have you actually seriously tried using an AI? It really isn't that hard to get good code with less effort using an AI. Just manage the scope of the tasks you give it. And of course, review the code that it generates. And of course, do NOT vibe code.

And I've actually grown quite fond of the "review the selected code (that I wrote) and make suggestions for improvements, but don't actually make any changes" prompt. Or "is this code correct?" And AIs are also exceptionally good at doing large-scale code refactoring. So I am actually producing even better code with less effort.

Yes, it requires good judgement -- something that you learn by doing. And developing a sense of what an AI can and cannot handle. Although I am, truthfully, falling behind the curve on that, as coding AIs are making major leaps and bounds in the complexity of what they can deal with, and the quality you can expect out of them, that changes on pretty much a monthly basis. I was quite amazed to get a C++ port of a 3,900 line python library to write to professional standards, in about 5 prompts total, including .deb packaging, test cases, and .md API documentation.

If you are basing your judgements on anything earlier than Claude 4.5 Sonnet(or any of the ChatGPT models prior to 5.2 Codex, which seems to be the first in the ChatGPT series of models that seems to be halfway comparable to Claude 4.5 Sonnet), then you urgently need to give it another try. Avoid any of the lite models. The difference between old and new models is dramatic. (Currently still figuring out what Claude 4.6 Sonnet is capable of. I haven't yet had a chance to feed it something difficult).

Re: I Don't Like Magic

#125

Post by sodapopcan »

bryanrasmussen wrote: post #106
monkpit wrote: post #52

Earlier quoted context omitted.

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

There is a HUGE difference between framework/library "magic" and business logic "magic." When framework/library "magic" is documented it's awesome, you just need to take the time to learn it.

Re: I Don't Like Magic

#126

Post by sodapopcan »

WJW wrote: post #123
fragmede wrote: post #56

Earlier quoted context omitted.

Because people won't do it.

Sounds like a them problem. If they can't be bothered to learn how to use their tools, it won't be a surprise that they then won't know how to use them. A free advantage to those of us that do dedicate the time to read the docs I guess.

At least in web development it really seems to have become widely accepted, at least at many places, that people aren't expected to be anywhere near experts in the tools they use every day.

Re: I Don't Like Magic

#127

Post by [deleted] »

llbbdd wrote: post #79
sodapopcan wrote: post #16

If you are the only person who ever touches your code, fine, otherwise I despise this attitude and would insta-reject any candidate who said this. In a team setting, "I don't like magic" and "I don't want to learn a framework" means: "I want you to learn my bespoke framework I'm inevitably going to write."

Every non-React app eventually contains a less version of React by another name.

[deleted]

Re: I Don't Like Magic

#128

Post by sodapopcan »

jv22222 wrote: post #80
bossyTeacher wrote: post #78

Earlier quoted context omitted.

> I used Claude to document, in great detail, a 500k-line codebase in about an hour of well-directed prompts Yes, but have you fully verified that the documentation generated matches the code? This is like me saying I used Claude to generate a year long workout plan. And that is lovely. But the generated thing needs to match what you wanted it for. And for that, you need verification. For all you know, half of your d…

Yes, since I spent over 10 years writing it in the first place it was easy to verify!

This is a key piece of information you left out of your original post.

Re: I Don't Like Magic

#129

Post by grey-area »

llbbdd wrote: post #79
sodapopcan wrote: post #16

If you are the only person who ever touches your code, fine, otherwise I despise this attitude and would insta-reject any candidate who said this. In a team setting, "I don't like magic" and "I don't want to learn a framework" means: "I want you to learn my bespoke framework I'm inevitably going to write."

Every non-React app eventually contains a less version of React by another name.

It would be hard to create a worse version of react for the things it is used for nowadays.

Re: I Don't Like Magic

#130

Post by toss1 »

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…

So, use the framework for the prototype and maybe thru v1.x, then after you have better understanding of how it is actually used in the field and what architecture and patterns would work best in your team's situation, fully write the real app yourself (or, if the framework really works best, keep using it).

I've found taking the throwaway approach a bit further down the line pays big benefits; delaying full commitment to a particular path until you have a lot more information tends to work better.

Post reply on HN