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

Using Claude Code to modernize a 25-year-old kernel driver

dmitrybrant.com

Post reply on HN
Print view View original

281–290 of 343 posts

Re: Using Claude Code to modernize a 25-year-old kernel driver

#281

Post by jimbokun »

kccqzy wrote: post #30
bicx wrote: post #11

Earlier quoted context omitted.

This is a good takeaway. I use Claude Code as my main approach for making changes to a codebase, and I’ve been doing so every day for months. I have a solid system I follow through trial and error, and overall it’s been a massive boon to my productivity and willingness to attempt larger experiments. One thing I love doing is developing a strong underlying data structure, schema, and internal API, then essentially hav…

This is more of a reflection of how our profession has not meaningfully advanced. OP talks about boilerplate. You talk about grunt work. We now have AI to do these things for us. But why do such things need to exist in the first place? Why hasn't there been a minimal-boilerplate language and framework and programming environment? Why haven't we collectively emphasized the creation of new tools to reduce boilerplate a…

Because no one wants to develop and use Lisp macros.

Re: Using Claude Code to modernize a 25-year-old kernel driver

#282

Post by mschuster91 »

Keyframe wrote: post #260
mschuster91 wrote: post #138

Earlier quoted context omitted.

the problem here is that Apple, while at least not standing actively in the way (like console manufacturers), provides zero documentation on how stuff works internally. You gotta reverse-engineer everything , and that either takes at least a dozen highly qualified and thus rare and expensive-to-hire people or someone hard on the autism-hyperfixation spectrum with lots of free time to spare and/or the ability to turn…

You mean to tell me those agents aren't PhD-level experts in every field as we were told by OpenAI?? I'm shocked! Seriously though, it does seem a menial task in itself to reverse engineer what's going on. Would be a really powerful show of force by one of leading AI providers if they setup shop like that to do it in the open.. if they could.

the menial work used to be decompiling, that can be automated though... but that's maybe 1/3rd of the game. you still need to figure out and observe what happens on what kind of external input. that is for now far beyond the capability of any AI.

Re: Using Claude Code to modernize a 25-year-old kernel driver

#283

Post by ori_b »

zer00eyz wrote: post #81
abathologist wrote: post #37

Earlier quoted context omitted.

This is the glaring fallacy! We are turning to unreliable stochastic agents to churn out boilerplate and do toil that should just be abstracted or automated away by fully deterministic, reliably correct programs. This is, prima facie, a degenerative and wasteful way to develop software.

> This is the glaring fallacy! It feels like toil because it's not the interesting or engaging part of the work. If you're going to build a piece of furniture. The cutting, nailing, gluing are the "boiler plate" that you have to do around the act of creation. LLM's are just nail guns.

Great analogy. As someone else pointed out in a different subthread, quality furniture isn't held together with nails.

Re: Using Claude Code to modernize a 25-year-old kernel driver

#284

Post by logicchains »

kccqzy wrote: post #30
bicx wrote: post #11

Earlier quoted context omitted.

This is a good takeaway. I use Claude Code as my main approach for making changes to a codebase, and I’ve been doing so every day for months. I have a solid system I follow through trial and error, and overall it’s been a massive boon to my productivity and willingness to attempt larger experiments. One thing I love doing is developing a strong underlying data structure, schema, and internal API, then essentially hav…

This is more of a reflection of how our profession has not meaningfully advanced. OP talks about boilerplate. You talk about grunt work. We now have AI to do these things for us. But why do such things need to exist in the first place? Why hasn't there been a minimal-boilerplate language and framework and programming environment? Why haven't we collectively emphasized the creation of new tools to reduce boilerplate a…

>Why haven't we collectively emphasized the creation of new tools to reduce boilerplate and grunt work?

Lisp completely eliminates boilerplate and has been around for decades, but hardly anyone uses it because programs that use macros to eliminate boilerplate aren't easy to read.

Re: Using Claude Code to modernize a 25-year-old kernel driver

#286

Post by joombaga »

philsnow wrote: post #254
jama211 wrote: post #86

Earlier quoted context omitted.

Saying boilerplate shouldn’t exist is like saying we shouldn’t need nails or screws if we just designed furniture to be cut perfectly as one piece from the tree. The response is “I mean, sure, that’d be great, not sure how you’ll actually accomplish that though”.

Even Star Trek has self-sealing stem bolts, they don't just 3d print their ships

They do sometimes 3D print at least smaller ships by the 2380s.

Re: Using Claude Code to modernize a 25-year-old kernel driver

#287

Post by yencabulator »

ZYbCRq22HbJ2y7 wrote: post #40
kccqzy wrote: post #30

Earlier quoted context omitted.

This is more of a reflection of how our profession has not meaningfully advanced. OP talks about boilerplate. You talk about grunt work. We now have AI to do these things for us. But why do such things need to exist in the first place? Why hasn't there been a minimal-boilerplate language and framework and programming environment? Why haven't we collectively emphasized the creation of new tools to reduce boilerplate a…

> Why hasn't there been a minimal-boilerplate language and framework and programming environment? There are? For example, rails has had boilerplate generation commands for a couple of decades.

Generating boilerplate is the worst of both worlds. The point is to not need so much of it.

Re: Using Claude Code to modernize a 25-year-old kernel driver

#288

Post by mejutoco »

jama211 wrote: post #86
abathologist wrote: post #37

Earlier quoted context omitted.

This is the glaring fallacy! We are turning to unreliable stochastic agents to churn out boilerplate and do toil that should just be abstracted or automated away by fully deterministic, reliably correct programs. This is, prima facie, a degenerative and wasteful way to develop software.

Saying boilerplate shouldn’t exist is like saying we shouldn’t need nails or screws if we just designed furniture to be cut perfectly as one piece from the tree. The response is “I mean, sure, that’d be great, not sure how you’ll actually accomplish that though”.

There are construction systems, for example in Japanese traditional architecture, that use no nails or screws. Good joinery often removes their need.

Re: Using Claude Code to modernize a 25-year-old kernel driver

#289

Post by punnerud »

Cthulhu_ wrote: post #155
punnerud wrote: post #85

What was the new speed after the upgrade?

...it's a tape drive, they have mechanically fixed speeds. Why do you ask?

He wrote “The tradeoff, of course, is that the data rate is limited by the speed of the floppy controller,”. Implying it could be faster by switching the controller. I guess tape drives could in theory have way way faster transfer speeds, as other tape drives does.

Re: Using Claude Code to modernize a 25-year-old kernel driver

#290

Post by flir »

elzbardico wrote: post #101
jclarkcom wrote: post #72

Earlier quoted context omitted.

When humans are in the loop everything pretty much becomes stochastic as well. What matters more is the error rate and result correctness. I think this shifts the focus towards test cases, measurement, and outcome.

No. This is a fundamentally erroneous analogy. We don't generate code by a stochastic process.

Not interested in joining a pile-on, but I just wanted to point out how difficult reproducible builds are. I think there's still a bit of unpredictability in there, unless we go to extraordinary lengths (see also: software proofs).
Post reply on HN