Hacker News new | past | comments | ask | show | jobs | submit
pjmlp | on: A new Go API for JSON
I would rather have LLM directly generate machine code, and best of all, macro Assemblers are blazing fast for decades.
dgb23 | parent | next
One of the best techniques for using LLM coding is to let it write programs that frontload and automate work in a repeatable and testable manner rather than letting it only do free form turns.

Letting it generate machine code directly would be the opposite of that.

pjmlp | root | parent
Like a JIT compiler then, where the generated Assembly depends on various parameters, where not two runs are the same, unless you manage to replicate the whole system state across them.

As for proven wrong,

"Frame was created over the past month largely via Claude Code. The Assembly code in all its glory can be found on GitHub."

https://www.phoronix.com/news/Frame-X11-Server-Assembly

bayindirh | parent | next
You can't PGO that code, though. Also, I'm not sure it can generate architecture specific optimized (-march, -mtune) code as well.

Considering it just pulls and remixes blocks, this is a very tall order for today's LLMs, and maybe a couple of generations as well.

Calling GCC/clang at the back and emitting ASM is both cheating and has no advantages whatsoever as well.

pjmlp | root | parent
That is fighting the last war on the early days of 5 GLs, and taken care by agentic runtimes.

This isn't futurology, besides a few projects that already came up on Phoronix and around here, with Assembly generation, there are enough SIGPLAN papers on ML driven compilers already.

bayindirh | root | parent | next
ML driven compilers are different than LLM assembly generation, and former is more sound than the latter one. I believe we both have enough experience to understand that.

However, starting with LLMs directly generating machine code and moving to ML directed optimization passes, you're moving the whole stadium with a crawler-transporter, not only the goalposts.

Helping compiler in a well defined way, and working on IR or driving it repeatedly to optimize the output is one thing, generating machine code from a training set is other. Let's not mix them.

pjmlp | root | parent
Yeah, well as mentioned, that is where it is going.

"Compiler 2.0: Building the Next Generation of Compilers with Machine Learning"

https://eecs.berkeley.edu/research/colloquium/compiler-2-0-b...

There are other researchers if you interest yourself on the matter.

Then the whole iPaaS agentic coding environments like Workato and Boomi, that even if they might generate 3GL as intermediate step, you don't get to see it.

bayindirh | root | parent
Thanks for the link. I have also found a small trove as a warm-up. If anyone interested, here it is:

https://github.com/zwang4/awesome-machine-learning-in-compil...

Using small, purpose built ML "things" to make things better makes sense. We use them everywhere. I never argued against it, as well.

anthk | root | parent
Like inform7 but irreproducible and shitter on every iteration.
pjmlp | root | parent
Like JIT and PGO machine learning optimizer passes more likely.
kibwen | parent | next
This is like saying that a strong man would rather dig a hole with his bare hands than use a shovel. Structured programming languages are force multipliers, it makes absolutely zero sense to forego them just so you can vibe assembly directly.
pjmlp | root | parent
Optimizing compilers were faced with the same disbelief by Assembly developers.

Enterprise applications are already being vibe coded in iPaaS platforms, and as mentioned in other comments with LLMs in the picture, that is what compiler research is switching to.

kibwen | root | parent
In no sense is this "disbelief". You seem to be laboring under a fundamental misunderstanding of the role of structured programming languages. A man with a shovel can dig a hole for some amount of effort, and when that man gets stronger he can use that shovel to either dig the same hole for less effort or dig a larger hole for the same amount of effort. With LLMs, leveraging a structured programming language allows a user to either create the same program for less effort or to create a larger program for the same amount of effort. Getting rid of the programming language and emitting assembly directly sacrifices efficiency for no gain.
pjmlp | root | parent
I am already using a bagger, while you are arguing for electric shovels.

In case you answer there don't fit the same purpose, there are tiny baggers that replace shovels altogether.

I think those arguing for structured language generation, never had that much experience with 4GLs or declarative programming on the previous AI Summer.

So like the Assembly developers required those -S compiler switches, or nowadays Compiler Explorer snippets, there is a tendency to argue for 3GL code generation, when low code/no code tools with AI runtimes are already being adopted at enterprise level.

What in the past took a bunch of developers using structured programming languages to write their frontend, and the myriad of microservices, is slowly being taken over by MCP tools, SaaS AI orchestration prompts and UI generation tooling, most of which doesn't even expose whatever code gets generated.

politician | parent
Use a working Go program as the prompt+oracle for cross-language port or direct generation.
pjmlp | root | parent
I rather not, unless I have to.

If 3 GL code has to be generated, my option list won't certainly have Go on it.