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

71–80 of 138 posts

Re: I Don't Like Magic

#71

Post by WJW »

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.

Anything that can be automated can be automated poorly indeed. But while it has been proven that textile manufacturing can be automated well (or at least better than a hand weaver ever could), the jury is still out if programming can be sufficiently automated at all. Even if programming can be completely automated, it's also unclear if the current LLM strategy will be enough or whether we'll have another 30 year AI winter before something better comes along.

Re: I Don't Like Magic

#72

Post by jv22222 »

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 using React, etc., and also the ones rolling their own JavaScript (of which I personally prefer).

Re: I Don't Like Magic

#73

Post by [deleted] »

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…

[deleted]

Re: I Don't Like Magic

#74

Post by Gibbon1 »

sigbottle wrote: post #37
SirMaster wrote: post #31

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.

[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 asse…

I phrase I use is spooky action at a distance. Quantum entanglement but with software.

Re: I Don't Like Magic

#75

Post by llbbdd »

yellowapple wrote: post #34
socalgal2 wrote: post #17

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

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

Re: I Don't Like Magic

#76

Post by kosmotaur »

> I get that. But I still draw a line. When it comes to front-end development, that line is for me to stay as close as I can to raw HTML, CSS, and JavaScript. After all, that’s what users are going to get in their browsers.

No it’s not. They will get shown a collection of pixels, a bunch of which will occupy coordinates (in terms of an abstraction that holds the following promise) such that if the mouse cursor (which is yet another abstraction) matches those coordinates, a routine derived from a script language (give me an A!) will be executed mutating the DOM (give me a B!) which is built on top of more abstractions than it would take to give me the remaining S.T.R.A.C.T.I.O.N. three times over. Three might be incorrect, just trying to abstract away so that I don’t end up dumping every book on computers in this comment.

Ignorance at a not so fine level. Reads like “I’ve established myself confidently in the R.A.C. band, therefore anything that comes after is yucky yucky”.

Re: I Don't Like Magic

#77

Post by bossyTeacher »

yellowapple wrote: post #63
madeofpalk wrote: post #39

Earlier quoted context omitted.

All of that is the JavaScript equivalent of Hello I have even less interest in touching any of your codebases!

Well I'd hesitate to touch any of my codebases, too, so that's fair :)

Stop touching my vanilla.js codebase, you naughty!

Re: I Don't Like Magic

#78

Post by bossyTeacher »

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…

> 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 document is not only nonsense but it is not obvious that it's nonsense until you run the relevant code and see the mismatch.

Re: I Don't Like Magic

#79

Post by llbbdd »

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.

Re: I Don't Like Magic

#80

Post by jv22222 »

bossyTeacher wrote: post #78
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…

> 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!
Post reply on HN