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.
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
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.
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.
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
The trouble, as I see it, is that we still have to look at the code before we run it. Even if it is a one-shot script. And it's just because you never know if there isn't some "rm -rf ${undefined_variable}/" lurking somewhere in there. And if I have to check it then I would very much like it to be readable.
I mean, I do get your point, sometimes it does not matter. Sometimes we could just YOLO it. But... if that then causes a big problem, even if at only 1% of the time, then I don't want to risk it. But that may just be me. YMMV
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.
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
This assumes that there is excess power at some point. This will soon become unrealistic: we either need power for data centers during the day or charging vehicles during the night.
The solution works only to keep a steady production of electricity, but if the demand would require full output all the time then these "mechanical batteries" don't help.
Not the OP but I guess the statement implied cultural and lingual unification which implies erasure of other cultures and languages. We do have to work on being understood across the cultural and lingual division but the differences should be celebrated and welcome, even if they do cause occasional misunderstandings.
What I don't understand is, why not replace middle management, marketing, CTOs, CEOs and the like. Surely, LLMs are better at producing high quality looking slideware and vaporware than they are at producing software.
Heavy sarcasm here if it's not obvious. Of course I know why.
I mean, there a so many startups getting crazy funding that run without management, or without engineers... or at least with so many less people than before.. except: not really.
Is the whole "it's gonna replace people" even still on the table?
I don't really understand what you mean... are you saying that the entire industry is parroting a fantasy that they all know is fake. So, everyone is faking to get more funds?
You think AI will replace a significant portion of the workforce in the sector?
Do you see it already happening? I personally not. Lay offs are due to economic reasons, at least that's what I see. Why does Anthropic still had so many engineers?
I got the impression companies are already moving back from their initial excitement. Many went all-in AI "more is better", that's not the case anymore. Why restricting usage, it's much cheaper than paying an engineer.
Not exactly decentralization but distribution was the main selling point.
In comparison to SVN and other non-DVCs git did not need to continuously talk to the central server for history, "branch" creations, unlocking/locking files before changes, etc.
Linus wanted a DVCS, but they wanted centralization and licenses were expensive, so he decided to launch the git initiative where he provided scaffolding and the rest came from contributions.
It was a selling point. Maybe even intended selling point. But it absolutely isn't the main selling point. Never was, never will. The big thing, the reason people ever started talking about Git outside Linux dev team, has always been branches. It's branches, not distribution, that made every SVN user in the world abandon it in exchange for Git. Saying distribution has been more important than branching is like saying automobiles replaced horses because of smell. Which, admittedly, was a big problem with horses, but come on.
Back then, when working with SVN, we had sites in various countries, with under provisioned VPNs between them. Loading up a single file history could take 15 minutes. I am not joking. Every single operation took ages, so really, any DVCS would have won in that situation, regardless of its approach to branches.
If the SVN server would sit in the same building then I guess the branching would have been the main selling point, but it was not the main selling point for us in that situation.
I agree with your criticism of "the good enough" and "done with taste" dichotomy.
I would like to comment on this, though:
> that only want simple, that finding the most blunt approach is the only way. It has felt tasteless. Anti-ambitious.
I am always aiming for simple. If it's simple, it's maintainable and can be easy to reason about. Doing that is hard work, though. I used to spend three iterations to achieve it: functions are simple, easy to reason about, properly named and composable.
It's the opposite of blunt, though, so it might be that you meant something else with the term "simple" :)
In my country most if not all corporate jobs offer private healthcare plans that let you have an unscheduled online chat with a doctor. You can get one day of sick leave that way. Sometimes two. If you need more you will most likely be asked to show up for examination in person.
You can't just not show up for work and call in sick. Within the same day you have to call your doctor and explain the symptoms and they have to start the paperwork for the sick leave. Even if it is for a day.
For a cold or a cough you would not get sick leave, though.
It depends on the country and company, but usually there are some days you can take off without evidence, and when you need more, you need a doctor's note.
In the Netherlands: This exactly, generally after a few days you get a call by the "company doctor" (it is not from the company, but the literal translation) with an invite to discuss your health issues.
Possibly, although I have to say that I get PRs now where it's clear it's a miss by the LLM and was generated by a human who did not take the time to understand the subject matter.
In the past, a human producing humanslop would get a serious talking to, but nowadays it's apparently a valid excuse "well, an LLM generated it". This approach is placing a huge burden on the reviewers, much more so than in the past.
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.
reply