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

221–230 of 343 posts

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

#221

Post by jamesnorden »

aargh_aargh wrote: post #109
elzbardico wrote: post #101

Earlier quoted context omitted.

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

You don't? I do. A few days ago I lost some data including recent code changes. Today I'm trying to recreate the same code changes - i.e. work I've just recently worked through - and for the life of me I can't get it to work the same way again. Even though "just" that is what I set out to do in the first place - no improvements, just to do the same thing over again.

[flagged]

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

#222

Post by jamesnorden »

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.

Maybe nail guns that have a chance to randomly shoot nails into your leg and apologize when you ask why it did that.

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

#223

Post by skydhash »

johnisgood wrote: post #207
matwood wrote: post #171

Earlier quoted context omitted.

It'll be interesting if tools like Claude will end up being used to highlight the people who have no clue what they are doing.

I think you can do this already. If you do not know the underlying concepts, or have no idea about how you have to architecture your project and so forth, then you will have problems with LLMs. So I think many if not most people who have problems with LLMs, it is most likely due to their lack of knowledge and/or their expectation that you can just simply write two sentences and it will figure out what you want and ho…

The thing is, is it slower to code with LLMs if you already have the knowledge? I think it is so. Coding is formal. There’s usually one correct way to tell the computer to do something (all the alternatives are equivalent through abstraction or transposition). The other ways are what we called bugs and there’s an infinty of them.

The programming language eliminates some (incorrect syntax) while the type system get rid of others (contract error). We also have linter that helps us with harmful patterns. But the range of errors is still enormous. So what’s the probability of having the LLMs be error free or as close as possible to the intended result?

We as humans have reduced the probability of error by having libraries of correct code (or outsourcing the correction of code), thus having a firmer and cognitively manageable foundation to create new code. As well as not having to rely on language to solve problems.

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

#224

Post by skydhash »

maccard wrote: post #168
ZYbCRq22HbJ2y7 wrote: post #32

Earlier quoted context omitted.

We have members on my team that definitely feel empowered to wade into new territory, but they make so much misdirected code with LLMs, even when we make everyone use Claude 4 thinking agents. It seems to me that if you have been pattern matching the majority of your coding career, then you have a LLM agent pattern match on top of that, it results in a lot of headaches for people who haven't been doing that on a team…

One of the things I’ve noticed is that those people are the same people who before would spend 3 weeks on something before coming out with a copy of the docs that doesn’t actually solve the problem at hand, but it spits out a result that almost matches what you asked for. They never understood the problem in the first place, they always just hammered until the nail went in - now they just have a different tool.

Everytime I have to mentor juniors, it’s more productive to get them to articulate the problem and their initial solution. It’s often sufficient to highlight (mostly for them) how little they actually know about the problem itself to actually rush to solve it.

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

#225

Post by jonstewart »

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”.

Carpenters/framers are less skilled and paid less than cabinetmakers. But the world needs more carpenters.

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

#226

Post by skydhash »

maccard wrote: post #170
AdieuToLogic wrote: post #73

Earlier quoted context omitted.

>>> Use these tools for rapid onboarding onto new frameworks. > Also new languages - our team uses Ruby, and Ruby is easy to read, so I can skip learning the syntax and get the LLM to write the code. If Ruby is "easy to read" and assuming you know a similar programming language (such as Perl or Python), how difficult is it to learn Ruby and be able to write the code yourself? > ... but I don't need to learn Ruby to w…

> Instead of learning the lingua franca and being able to verify your own work, "the rest of the team" has to make sure your PR's will not obviously fail. I lead the engineering team at my org and we hire almost exclusively for c++ engineers (we make games). Our build system by happenstance is written in c#, as are all the automation scripts. Out of our control to change. Should we require every engineer to be compet…

Programming language are not actually that different. There’s only a few models of computation and paradigms. The effort is mostly about learning the syntax, the standard library and whatever abstractions built around the above paradigms and computation models. And learning the standard library is the tough one.

I would expect every engineer to be able to read C#. It’s not that hard.

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

#227

Post by stevex »

theptip wrote: post #3

A good case study. I have found these two to be good categories of win: > Use these tools as a massive force multiplier of your own skills. Claude definitely makes me more productive in frameworks I know well, where I can scan and pattern-match quickly on the boilerplate parts. > Use these tools for rapid onboarding onto new frameworks. I’m also more productive here, this is an enabler to explore new areas, and is al…

I had an Amiga disk image (*.adf) that I wanted to extract the files from. There are probably tools to do this but I was just starting with Claude Code, so I asked it to write a tool to extract the files by implementing the filesystem.

It took a few prompts but I know enough about FFS (the Amiga filesystem) to guide it, and it created exactly the tool I wanted.

"force multiplier of your own skills" is a great description.

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

#229

Post by skydhash »

tonkinai wrote: post #125
theptip wrote: post #3

A good case study. I have found these two to be good categories of win: > Use these tools as a massive force multiplier of your own skills. Claude definitely makes me more productive in frameworks I know well, where I can scan and pattern-match quickly on the boilerplate parts. > Use these tools for rapid onboarding onto new frameworks. I’m also more productive here, this is an enabler to explore new areas, and is al…

It’s less about AI vs boilerplate and more about having good tests. if the code works and you can move fast, who cares who typed it.

Code working is a very high bar. And the only way close for most projects is formal verification.

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

#230

Post by skydhash »

rmoriz wrote: post #83
QuadmasterXLII wrote: post #68

Earlier quoted context omitted.

That must be so hard for you.

The bugs are on them. I‘ve fixed them in my fork but of course I‘ll migrate to a non-discriminating alternative.

Your fork works, so why are you so unhappy? You can always publish you diff to help other people if you really want to do so.
Post reply on HN