Hacker News Reader

Comment by compiler-devel | Hacker News Reader

In the age of LLMs I would expect that legacy code bet carried indefinitely. The LLMs will have it indefinitely in their training data, and with code "cheap" to produce now, what are the good reasons for dropping legacy code?

View on HN

The obvious answer is that LLMs are not quite the machine gods they're marketed as, innit.

I don't understand what you're saying.

Your presumption is that code is "cheap" because of LLMs. I am challenging the premise. Maintaining code in production for a product used by billions of people is not cheap, with or without LLMs. Perhaps your shitty disposable code that you write for yourself and never subject anyone else to is cheap, but if your code is in a large, complex codebase and has to actually work for everyone who uses it, not so much.

LLMs are only getting better and more competent, especially for code well-covered by tests. On such codebases it's definitely cheaper to maintain code with a LLM than by humans alone. I presume then that the XSLT implementation in Chrome is not well-tested.

I think that the issue is not the XSLT implementation (that could be contained), but its deep intégration in the XML stack which is part of web pages processing. Think about XML "processing instructions".

This mindset is why programs only ever seem to bloat more by the day. Code for a given functionality could cost 0 development maintenance and still not be worth including going forward.

> what are the good reasons for dropping legacy code?

Reducing attack surface.

That is a good reason. Is XSLT known for security problems the same way that CGI was?

Browsers have been relying on libxml2 for ages. Nobody bothered to help libxml2 much, let alone pay for maintenance, but treated it like a security critical component so let their CVE teams loose on unsuspecting volunteers. libxml2 burned out, the project got abandoned, and now Google and everyone else are sweating about what to do with their XML parsing code.

Ripping out the least common and most dangerous parts of XML parsing makes a lot of sense if you want to keep using the unmaintained library without actually having to put in the work to maintain it.

The libxml2 maintainer forked the repo and released it as AGPL, a license which does to Google what garlic does to vampires, unless you pay up.

It is not because of specific known vulnerabilities. It is because it is old legacy unmaintained code which is rarely used and which has a large attack surface.

Killing RSS, forcing Javascript on people.

XSLT is rarely used, a significant attack surface, and the upstream libraries are riddled with vulnerabilities. LLMs make the problem worse by lowering the cost of finding new vulnerabilities.

> LLMs make the problem worse by lowering the cost of finding new vulnerabilities.

LLMs make the problem easier because lowering the cost of fixing the vulnerabilities

A good plan... if you can afford to maintain your fork forever.

Google and MS could do it

Reply on news.ycombinator.com