[kibwen]

People often use the analogy of LLMs being to high-level languages what compilers were for assembly languages, and despite being a terrible analogy there's no guarantee it won't eventually be largely true in practice. And if it does come true, consider how the advent of the compiler completely eliminated any incentive to improve the ergonomics or usability of assembly code, which has been and continues to be absolute crap, because who cares? That could be the grim future for high-level languages; this may be the end of the line.

[daxfohl]

A big difference is that compilers are deterministic, and coders generally don't review and patch the generated assembly. There's little reason to expect that LLMs will ever function like that. It's always going to be a back-and-forth of, "hey LLM code this up", "no, function f isn't quite right; do this instead", etc.

This mimics what you see in, say, Photoshop. You can edit pixels manually, you can use deterministic tools, and you can use AI. If you care about the final result, you're probably going to use all three together.

I don't think we'll ever get to the point where we a-priori present a spec to an LLM and then not even look at the code, i.e. "English as a higher-level coding language". The reason is, code is simply more concise and explicit than trying to explain the logic in English in totality up-front.

For some things where you truly don't care about the details and have lots of flexibility, maybe English-as-code could be used like that, similar to image generation from a description. But I expect for most business-related use cases, the world is going to revolve around actual code for a long time.

[seanmcdirmid]

If LLMs can ever produce implementation and tests opaquely, then perhaps we can instruct at the level of requirements. They will never be good enough at the beginning and we will just provide feedback over the working prototype the LLM generates and demonstrates?

I haven’t seen technology move this fast before, so I wouldn’t make any hard predictions about how long actual code written by humans survives. We don’t really need AGI at this point to have opaque coding solutions, even if the LLMs should still be better.

[daxfohl]

I won't say "never", but I guess I left out the caveat that I tried this for a hack week demo once. Working in compliance and onboarding, there's a whole lot of logic around what you have to collect and check, what you have to do around user experience, what steps you can fall back to if something fails, etc. I tried to take all our code and translate it to English to feed to an LLM and see what it would do. But the final result was that, even if it worked perfectly, the English description was longer and more convoluted than the code, would've been harder to make changes to, yada yada, so even if it worked perfectly, it would be a worse option than code.

But maybe there's a future where a "best of both worlds" that intermingles structured code with unstructured verbal instructions, so that you can ensure that the important aspects of your requirements are explicit and deterministic, and the filler parts can be in English descriptions. It'd compile, and you get red squigglies in your editor if something doesn't make sense, maybe even type hints on the English somehow. I think that'd be a pretty good "best of both worlds" because it'd really let you separate the signal from the noise, which is the problem you have when using either English or programming languages distinctly.

[daxfohl]

Though now that I say that, I wonder if maybe the approach should be, instead of specifying the onboarding procedure in terms of steps, maybe it would be better to specify a goal, the constraints, and some optimization function, and allow the AI to figure out what the workflow steps should be. So it would act higher level, more as a constraint solver than a code generator. That could be easier to interact with, allow constraints to be read and updated more easily, and not require diving much into code at all.

Hmm, I don't think LLMs are quite there yet, but I could see this being a potential way to do things, that may fit better with their strengths, and allow more to be done without digging into actual code.

Now I just need to dust off my old Prolog books and figure out how to use coding assistants in a similar fashion.

[seanmcdirmid]

I think the magic key might be LLMs that can build and test code, and then revise it and test it again, revise tests, etc...all while accepting feedback from human users about what the requirements really are (because they aren't going to be complete at the beginning). We might already be there with LLMs and we just haven't figured out the workflow yet (it isn't just one LLM activation, for sure, it has to be a series, with feedback from test execution and reviews...like real SWEs).

[daxfohl]

Yes. I tried the prolog style requirements last night too and it wasn't great either. Some things are easier to say in "rules" and some things are easier to say in "steps". Trying to get all the way to "rules" ends up sounding like Yoda talk in places. Where with "steps" you feel the need for a GOTO, with "all rules" you feel the need for the infamous COMEFROM keyword in places.

So, yeah, I think what you say is the only logical conclusion. Waterfall development doesn't work well for humans, and it's probably not going to work for AI either. In fact, spending a ton of time formalizing a huge requirements doc is going to be even more of an antipattern with AI. When you can just have a conversation, hammer out details, identify nuances, plan for the future, all while seeing the feature in real time, that's going to be a million times more productive. The requirements doc can come with a full demo and a green button to launch it into production immediately after (or during) the review meeting.

So yeah, we'll probably never have "English as code", but rather an iterative process that leads to both English and code descriptions of the feature.

As far as DSLs, I think they still fit. If you see a pattern that makes sense to encode in a DSL, the LLM will happily do that, and doing so could help the AI optimize its limited context and make the invariants of the domain much more explicit.

Fun times.

[Terr_]

I suspect the important sticking point will be reliability. The "incentive" exists because of an high degree of trust, so much so that "junior dev thinks it's a compiler bug" is a kind of joke.

If compilers had significant non-deterministic error rates with no reliable fix, that would probably be a rather different timeline.

[kibwen]

Yes, that's why I say it's a terrible analogy, but we live in a crap world with a fetish for waste and no incentive for quality, so I fear for a future where every night we just have the server farm spin up a thousand batch jobs to regenerate the entire codebase from scratch and pick out the first candidate that passes today's test suite.

[bee_rider]

We got LLVM IIR which is sort of like… similar-ish to assembly but better and more portable, right? Maybe some observation could be made there—it is something that does a similar job, but does it in a way that is better for the job that actually remains.

[noobermin]

An ignorant perspective, from someone likely hasn't coded assembly ever. Assembly is tied to the system you target and it can't really be "improved". You can however improve ergonomics greatly via macros and everyone does this.

[kibwen]

> Assembly is tied to the system you target and it can't really be "improved".

Of course it can. There's no reason for modern extensions to keep pumping out instructions named things like "VCTTPS2DQ" other than an adherence to cryptic tradition and a confidence that the people who read assembly code are poor saps who don't matter in the grand scheme of the industry, which is precisely my point. And even if x86 was set in stone centuries ago, there's no excuse for modern ISAs to follow suit other than complete apathy over the DX of assembly, and who can blame them?

> You can however improve ergonomics greatly via macros and everyone does this.

Yes, and surely you see how the existence of macro assemblers strengthens my argument?

[noobermin]

>poor saps who don't matter in the grand scheme of the industry

Someone is mad. Just because you don't have the patience for it doesn't mean everyone has the same preferences as you do.

Anyway, one could argue macros in assembly are part and parcel of the process if you develop things in assembly of significant complexity. If you don't like a particular instruction name, you could always relabel it in a macro to something you like. "Redesigning assembly" of an existing target otherwise makes no sense as a concept as assembly languages are usually specified by ISA designers as a target to meet the developers of compilers.

You can of course write your own assembler for yourself if you really want. That's the beauty of asm, you don't have to meet ideological targets for this or that PL school. You just need to admit the right byte codes, and that's sufficient. It doesn't guarantee things will work how you want though easily in a higher level sense, which is why most people use programming languages.

[kibwen]

>> poor saps who don't matter in the grand scheme of the industry

> Someone is mad

You're completely misunderstanding me. This isn't my personal opinion, it's simply an observation of the utter indifference of ISA designers to any consideration of ergonomics or developer experience. The rest of your comment aptly explains ways to work around this fact while failing to understand that the whole point of this thread is that it didn't have to be this way. For example, there's no reason that an assembly language couldn't have basic syntactical affodances like namespaced identifiers or pseudo-structural elements like basic if, while, and switch. Hell, in the 80s we had chips that executed Lisp, and today we might still have some brave souls making chips that execute Forth. There's no law of the universe that says that assembly has to be jank and primitive.