4 ms·

"1. It complies on lots of architectures. Behold what Justine Tuney is doing :) Portable C is actually real!@ There is no other language that runs on as many p

"1. It complies on lots of architectures. Behold what Justine Tuney is doing :) Portable C is actually real!@ There is no other language that runs on as many platforms as C, that much is true. If Justine Tunney's Portable C, as much as an accomplished as it is, is a practical solution is a different question. "2. You don't have to audit code from a lib, nor trust it by default" Now you have to audit the LLM generated code - all of it - and you have gained exactly nothing. It's even worse, because you can assume your library code has been tried and tested by others even if you don't trust them whereas you LLM generated code is fresh and new and probably full of quirks and missing corner cases. "3. You don't have to fear that updating packages in your system (or virtual env, or container) would break your 'batteries included' code" True, but you don't benefit from updates that fix bugs and security vulnerabilities that others have found for you. "4. You can do formal verification (this I know nothing about, just learning now on your prompting!)" You can, but how practical is it? Have you ever done it? "5. It's far easier to deploy" This is a valid point but I also think it depends a lot on your environment.

cxr 3y ago
> Now you have to audit the LLM generated code - all of it - and you have gained exactly nothing. It's even worse, because you can assume your library code has been tried and tested by others You're right to raise the first part as a concern and observing that, all things considered, you probably haven't gained anything on net. (You might actually be losing.) But you're wrong about the last part. What we've seen in practice is that like the free-rider problem there's a dearth of folks performing the work that people are assuming everyone else is doing and a glut of people relying on that false assumption. And it's worth considering how many of those fixes are _only_ necessary because of the rampant code sharing. Monocultures have downsides. A single vulnerability in a single package ends up exposing people to greater risk because the package is trying to be all things to all people and therefore contains functionality that only a fraction of its dependents actually wanted/needed. Because there's a monoculture, though, everyone is impacted. This is the counter to your #3: when you aren't following the same path others are on, you don't get their fixes, but you also aren't impacted by bugs that others are introducing in the first place. Anyone who's ever stared at server logs for an application that isn't Wordpress can see this principle in play when you consider how much protection simply not being on Wordpress provides for thwarting would-be attackers.

cxr 3y ago

> Now you have to audit the LLM generated code - all of it - and you have gained exactly nothing. It's even worse, because you can assume your library code has been tried and tested by others You're right to raise the first part as a concern and observing that, all things considered, you probably haven't gained anything on net. (You might actually be losing.) But you're wrong about the last part. What we've seen in practice is that like the free-rider problem there's a dearth of folks performing the work that people are assuming everyone else is doing and a glut of people relying on that false assumption. And it's worth considering how many of those fixes are _only_ necessary because of the rampant code sharing. Monocultures have downsides. A single vulnerability in a single package ends up exposing people to greater risk because the package is trying to be all things to all people and therefore contains functionality that only a fraction of its dependents actually wanted/needed. Because there's a monoculture, though, everyone is impacted. This is the counter to your #3: when you aren't following the same path others are on, you don't get their fixes, but you also aren't impacted by bugs that others are introducing in the first place. Anyone who's ever stared at server logs for an application that isn't Wordpress can see this principle in play when you consider how much protection simply not being on Wordpress provides for thwarting would-be attackers.