Any application that can be written in a system language, eventually will be

Post by tasuki » Tue, Jan 27, 2026, 11:55 AM UTC

worthless-trash wrote: post #90

ajkjk wrote: post #42

I kinda like viewing this as similar to coordinate-invariance in physics / geometry. A programming language is effectively a function from textual programs to behaviors; this serves the same role as a coordinate system on a space, which is a function from coordinates to points. Naturally many different programs and programming languages can describe the same behavior, especially if you forget about implementation-spe…

I would dearly love this to happen. There are some corner cases that won't fit the translation layer well, for example almost any beam languages philosophy of let it crash.. I imagine those languages will be left by the wayside.

Post by fwip » Tue, Jan 27, 2026, 1:08 PM UTC

tasuki wrote: post #104

fwip wrote: post #62

Earlier quoted context omitted.

Well-written Python apps are very easy to understand, especially if they use well-designed libraries. The 'magic' in Python means that skilled developers can write libraries that work at the appropriate level of abstraction, so they are a joy to use. Conversely, it also means that a junior dev, or an LLM pretending to be a junior dev, can write insane things that are nearly impossible to use correctly.

> Well-written Python apps are very easy to understand, especially if they use well-designed libraries. Oh. Why haven't I seen those?

Post by tomrod » Tue, Jan 27, 2026, 3:46 PM UTC

lmm wrote: post #22

monero-xmr wrote: post #4

Earlier quoted context omitted.

I am old but C is similarly improved by LLM. Build system, boilerplate, syscalls, potential memory leaks. It will be OK when the Linux graybeards die because new people can come up to speed much more quickly

The thing is LLM-assisted C is still memory unsafe and almost certainly has undefined behaviour; the LLM might catch some low hanging fruit memory problems but you can never be confident that it's caught them all. So it doesn't really leave you any better off in the ways that matter.

Post by captain_coffee » Tue, Jan 27, 2026, 5:07 PM UTC

bartread wrote: post #108

captain_coffee wrote: post #63

Earlier quoted context omitted.

So let me get this straight - you vibe code, make what you consider as necessary changes to the LLM-generated code, create PRs that get to be reviewed by another AI tool (Copilot), potentially make changes based on Copilot's suggestions and at the end, when you are satisfied with that particular PR you merge it yourself without having any other human reviewing it and then continue to the next PR. Did I get that right…

Not quite: remember I said I fettled the code myself? This might involve rewriting, refactoring, reorganising, and I'll make changes to Copilot's PRs as well, but still the percentage of code written by LLM remains what I'd consider to be very high. I've been an engineer for more than 25 years so I know how to architect an application from the highest level down to the fine details, and I can obviously code in a vari…

Post by adrianN » Tue, Jan 27, 2026, 6:37 PM UTC

pfdietz wrote: post #9

happytoexplain wrote: post #8

Earlier quoted context omitted.

Defining tests that test for the right things requires an understanding of the problem space, just as writing the code yourself in the first place does. It's a catch-22. Using LLMs in that context would be pointless (unless you're writing short-lived one-off garbage on purpose). I.e. the parent is speaking in the context of learning, not in the context of producing something that appears to work.

I'm not sure that's true. Bombarding code with huge numbers of randomly generated tests can be highly effective, especially if the tests are curated by examining coverage (and perhaps mutation kills) in the original code.