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

The port I couldn't ship

ammil.industries

Post reply on HN
Print view View original

41–50 of 101 posts

Re: The port I couldn't ship

#41

Post by eru »

embedding-shape wrote: post #25

As always, the answer is "divide & conquer". Works for humans, works for LLMs. Divide the task into as small, easy to verify steps as possible, ideally steps you can automatically verify by running one command. Once done, either do it yourself or offload to LLM, if the design and task splitting is done properly, it shouldn't really matter. Task too difficult? Divide into smaller steps.

Well, ideally we teach the AIs how to divide-and-conquer. I don't care, whether my AI coding assistant is multiple LLMs (or other models) working together.

Re: The port I couldn't ship

#42

Post by eru »

jeffrallen wrote: post #12
esafak wrote: post #5

You don't know what the model is capable of until you try. Maybe today's models are not good enough. Try again next year.

This is true, but also: everything I try works! I simply cannot come up with tasks the LLMs can't do, when running in agent mode, with a feedback loop available to them. Giving a clear goal, and giving the agent a way to measure it's progress towards that goal is incredibly powerful. With the problem in the original article, I might have asked it to generate 100 test cases, and run them with the original Perl. Then I…

> I simply cannot come up with tasks the LLMs can't do, when running in agent mode, with a feedback loop available to them. Giving a clear goal, and giving the agent a way to measure it's progress towards that goal is incredibly powerful.

It's really easy to come up with plenty of algorithmic tasks that they can't do.

Like: implement an algorithm / data structure that takes a sequence of priority queue instructions (insert element, delete smallest element) in the comparison model, and return the elements that would be left in the priority queue at the end.

This is trivial to do in O(n log n). The challenge is doing this in linear time, or proving that it's not possible.

(Spoiler: it's possible, but it's far from trivial.)

Re: The port I couldn't ship

#43

Post by eru »

mrguyorama wrote: post #10

This is unfortunate. I thought porting code from one language to another was somewhere LLMs were great, but if you need expertise of the source code to know what you are doing that's only an improvement in very specific contexts: Basically just teams doing rewrites of code they already know. Our team used claude to help port a bunch of python code to java for a critical service rewrite. As a "skeptic", I found this t…

> So now we have 4 broken date parsing functions and 1 working one and that will be a pain that we have to fix in the new year.

Property based testing can be really useful here.

Re: The port I couldn't ship

#44

Post by lolsowrong »

riffraff wrote: post #11

fun to read this in the context of the recent news that microsoft wants to port all their C/C++ to Rust in 5 years with "AI and algorithms"[0]. I'm sure the MS plan is not just asking Claude "port this code to rust: ", but it's just fun to think it is :) 0: https://www.theregister.com/2025/12/24/microsoft_rust_codeba...

Yea, but Galen’s a beast so it might actually happen.

Re: The port I couldn't ship

#45

Post by dwaltrip »

aretu7888 wrote: post #30
dwaltrip wrote: post #22

How many hours until someone else is able to get it to work? I consider myself a bit of an expert vibe engineer and the challenge is alluring :D

You just need to know what you are doing. In this case, the problem is not "rewriting the logic" but "mapping Perl syntax to Typescript syntax" and "mapping Perl libs to Typescript libs". In other words, you'd be better off with an old-fashioned script that merely works on syntax mangling along with careful selection of dependencies (and maybe some manual labor around fixing the APIs of the consumers). This is easy w…

Are you sure you know what you are doing? ;)

The actual goal is to faithfully replicate the functionality and solve the same use cases with a different set of base technologies.

You describing similar but different instrumental goals, which may help reaching the real goal.

Cheekiness aside, your framing is helpful!

Re: The port I couldn't ship

#47

Post by debois »

I recognize this part:

> I don’t recall what happened next. I think I slipped into a malaise of models. 4-way split-paned worktrees, experiments with cloud agents, competing model runs and combative prompting.

You’re trying to have the LLM solve some problem that you don’t really know how to solve yourself, and then you devolve into semi-random prompting in the hope that it’ll succeed. This approach has two problems:

1. It’s not systematic. There’s no way to tell if you’re getting any closer to success. You’re just trying to get the magic to work.

2. When you eventually give up after however many hours, you haven’t succeeded, you haven’t got anything to build on, and you haven’t learned anything. Those hours were completely wasted.

Contrast this with you beginning to do the work yourself. You might give up, but you’d understand the source code base better, perhaps the relationship between Perl and Typescript, and perhaps you’d have some basics ported over that you could build on later.

Re: The port I couldn't ship

#48

Post by fragmede »

elAhmo wrote: post #36
maccard wrote: post #32

Earlier quoted context omitted.

I feel like we’ve been hearing this for 4 years now. The improvements to programming (IME) haven’t come from improved models, they’ve come from agents, tooling, and environment integrations.

Both is true, models have also been significantly improved in the last year alone, let's not even talk about 4 years ago. Agents, tooling and other sugar on top is just that - enabling more efficient and creative usage, but let's not undermine how much better models today are compared to what was available in the past.

The code that's generated when given a long leash is still crap. But damned if I didn't use a JIRA mcp and a gitlab mcp, and just have the corporate AI just "do" a couple of well defined and well scoped tickets, including interacting with JIRA to get the ticket contents, update its progress, push to gitlab, and open an MR. Then, the corporate CodeRabbit does a first pass code review against the code so any glaring errors are stomped out before a human can review it. What's more scary though is that the JIRA tickets were created by a design doc that was half AI generated in the first place. The human proposed something, the AI asked clarifying questions, then broke the project down into milestones and then tickets, and then created the epic and issues on JIRA. One of my tradie friends taking an HVAC class tells me that there are a couple of programmers in his class looking to switch careers. I don't know what the future brings, but those programmers (sorry, "software developers") may have the right idea.

Re: The port I couldn't ship

#49

Post by majormajor »

elAhmo wrote: post #36
maccard wrote: post #32

Earlier quoted context omitted.

I feel like we’ve been hearing this for 4 years now. The improvements to programming (IME) haven’t come from improved models, they’ve come from agents, tooling, and environment integrations.

Both is true, models have also been significantly improved in the last year alone, let's not even talk about 4 years ago. Agents, tooling and other sugar on top is just that - enabling more efficient and creative usage, but let's not undermine how much better models today are compared to what was available in the past.

How do you judge model improvements vs tooling improvements?

If not working at one of the big players or running your own, it appears that even the APIs these days are wrapped in layers of tooling and abstracting raw model access more than ever.

Re: The port I couldn't ship

#50

Post by majormajor »

samdjstephens wrote: post #28
gortok wrote: post #3

While there's not a lot of meat on the bone for this post, one section of it reflects the overall problem with the idea of Claude-as-everything: > I spent weeks casually trying to replicate what took years to build. My inability to assess the complexity of the source material was matched by the inability of the models to understand what it was generating. When the trough of disillusionment hits, I anticipate this wil…

If LLMs stopped improving today I’m sure you would be correct- as it is I think it’s very hard to predict what the future holds and where the advancements take us. I don’t see a particularly good reason why LLMs wouldn’t be able to do most programming tasks, with the limitation being our ability to specify the problem sufficiently well.

> the limitation being our ability to specify the problem sufficiently well

Such has always been the largest issue with software development projects, IMO.

Post reply on HN