These machines are doing some crazy things to get to the result. That said, I can't help but feel like this is the compilers argument all over again. Are the methods used to get to the result good? No. Is the code that it generates good? No. Does it achieve the goal. Yes. Is it likely to get better with time. Also yes. In my use cases, jobs that would have taken weeks to months are being done in minutes to hours. Involving complex testing and reasoning and experimentation. I'm no fanboy, but I can't argue against the speed gains. I'm sure we'll still have artisans who hand weave incredible code. But for me, I'm switching to the weaving loom for speed and efficiency.

▲

kzrdude 3 hours ago | parent | next [-]

It seems like we're not supposed to care about the code quality then? I guess that's the compilers argument. But I'm not ready to give up the code just yet.. These LLMs don't even have a stable interface, they change every few months in how they interpret our prompts and tasks.

▲

lelanthran an hour ago | parent | prev | next [-]

> But for me, I'm switching to the weaving loom for speed and efficiency.

Poor analogy - the loom was deterministic. LLMs are not, they are probabilistic. I made a page I can point anyone to because I keep seeing this "LLMs are the next level of abstraction" argument.

https://www.lelanthran.com/chap15/content.html

▲

tripledry 4 hours ago | parent | prev | next [-]

Similar for me, I don't like the development for many reasons, but that's another discussion. I also can't deny the capabilities.

I use the tools with this "risk analysis":

- If performance doesn't improve I can just always switch back to whatever I've done for the past 10 years, so it's not really a risk to start exploring.

- If performance does improve, then I'm already familiar with it.

▲

idiliv 4 hours ago | parent | prev | next [-]

What is the "compilers argument"?

▲

prerok 4 hours ago | parent | next [-]

Back in the day, the argument was that compilers produce unreadable assembly, so people used to writing assembly were arguing against the use of compilers.

Compilers also had bugs, so we still had to debug the assembly to understand how to fix the problem. Nowadays, almost nobody has to resort to those steps, except of course compiler developers. But that is just a testament to the quality of compilers.

Comparing LLMs to compilers is a take I often see, but I am not sure the comparison quite holds. The problem is that LLMs are inherently non-deterministic, so we always get a different output on the same prompt.

Maybe if LLMs are powerful enough it won't matter. I doubt it but we will see.

▲

i2km 3 hours ago | parent | next [-]

And in general, especially with something like C, the correspondence between the compiled code and source code isn’t very “lossy”. You don’t get one-to-one correspondence but it’s not too bad and you’re not introducing massive uncertainty by running it through a compiler. With LLMs though all bets are off… you’re not gonna know what you end up with

▲

tripledry 3 hours ago | parent | prev | next [-]

What you say is true, the comparison indeed doesn't hold.

But is it relevant? does it matter from a product perspective if LLMs are non-deterministic. You don't need to one shot the correct result, english is ambiguous and LLMs non-deterministic, but you can iterate.

If it's possible to iterate fast and cheap enough, even ambiguous language can produce the results you want, given enough iterations.

There are a lot of ifs and buts here, just a thought on the compiler argument.

▲

prerok 2 hours ago | parent [-]

I think it matters, because nowadays we don't look at assembly any more. I mean, I don't recall the last time I was tracking down a compiler bug but it's definitely been more than 15 years ago.

We do have to look at the LLMs' output, though, and, as you already pointed out, iterate to get the correct results. What this means is that the output must still be readable, must be analyzed by someone and I don't see it going away any time soon.

The problem is that the analysis is not cheap. Sometimes, with boilerplate, it is easy, but many times it is not and that's where we get only slight gains by using LLMs.

	▲	tripledry 2 hours ago \| parent [-]
		I agree from a programmers perspective. But from a broad market and product perspective, for most things you don't need to look at the code. If the product kinda does what it's supposed to. For example, in my game projects I don't look at the CMakeLists anymore, or python scripts that move assets here and there, I can run my game and just see that it did what I expect it to do (renders assets etc). Similar with frontend, I don't care that much what the code looks like anymore, mostly that the site looks and feels as I expect it, and the correct network calls are happening. TLDR; I'm thinking there are levels to this, in some projects it matters, in others it doesn't, it's kinda two different things. Programming wasn't replaced, LLMs just brought a new paradigm of doing things on the side. I'm just rambling at this point, my thoughts on this are not super clear, sorry for that :D

▲

quikoa 3 hours ago | parent | prev [-]

There is also a predictable relation between the input and output of a compiler w.r.t. the semantics of a programming language. Natural languages are ambiguous leaving room for the implementation to diverge that may not be obvious at first glance.

	▲	Almondsetat 2 hours ago \| parent [-]
		There are also plenty of things a compiler might not expose that end up being ambiguous. For example, C++ doesn't officially have a restrict keyword, so how can you express the fact that two memory regions never operlap and can be optimized? Unfortunately the reality is that if we had a language capable of truly expressing the programmer's intent we'd end up with a monster

▲

sampullman 3 hours ago | parent | prev | next [-]

Hand writing assembly produces more efficient and concise code, at the cost of developer time and required expertise. It was true for a long time, now not so much.

▲

big-chungus4 4 hours ago | parent | prev | next [-]

I think it's that when some code compiles to say assembler, the compiler doesn't prioritize readability and maintainability of the assembler code, since people are not expected to read and maintain it directly

▲

IceDane 3 hours ago | parent | prev | next [-]

Lots of really silly people love to compare LLMs to compilers. "You don't look at the compiled code either" and "Back in the day, people also had negative reactions to compilers and wanted to keep writing assembly by hand" and other such nonsense.

	▲	recursivecaveat 2 hours ago \| parent \| next [-]
		Indeed, the compiler does not have to ingest its own output, figure it out, and insert modifications in the middle. Source code is the medium that LLMs work in.
	▲	bluetomcat 2 hours ago \| parent \| prev [-]
		They are ignorant about the elephant in the room. The input language of a compiler is a formally-specified grammar with well-defined semantics for each operation. It generally abstracts the computation process over a von-Neumann machine, adding convenience features and bells and whistles. What "a=1" means in an HLL is, store that value in a particular storage location, so that it can be accessed later by the same name. The slop machine reads lousy natural human language that can mean different things in different contexts. That lousy language is then statistically probed for the most likely output correspondence, producing shit that needs to be externally verified.

▲

OtomotO 2 hours ago | parent | prev | next [-]

I assume it's the idea that initially you wrote machine code, later assembly and then the "high level languages" started to gain traction.

And for each iteration there were scepticals...

But I am curious myself, what OP meant by this.

▲

troupo 4 hours ago | parent | prev [-]

People keep saying that "models are just compilers, and I don't see you complsining about compilers". Which is such a bullshit argument

	▲	lelanthran an hour ago \| parent [-]
		> People keep saying that "models are just compilers, and I don't see you complsining about compilers". Which is such a bullshit argument At what point do we normalise the message "This is a stupid line of reasoning and you should feel stupid for suggesting it, stupid!" I mean, all the reasoned and logical arguments in the world doesn't change a religious follower's faith, but emotive ones regularly work! At what point can we start using shaming language on people who apparently don't know how neither an LLM works nor how a compiler works, but still trot out this argument as a cognitive kill switch?

▲

oblio 4 hours ago | parent | prev | next [-]

The compiler argument is great, if we turn it on its head.

To create professional products, compilers are great, when used by professionals or passionate and technical amateurs. They're useless if you're neither.

LLMs are the next step up. They are quite useful if you are neither, and you can get a lot farther with them, which means that low quality software is much easier to create. But if, for whatever reason, you need to create higher quality software (like most software that's actually sold directly or through subscriptions or ads), you're back to the "be a professional or passionate and technical amateur".

▲

troupo 4 hours ago | parent | prev [-]

> Is it likely to get better with time. Also yes.

There are no signs to show that. If anything, the new models produce worse code, only significantly faster