I did not think of applying LLMs on fuzzing at all until I saw llvm-hackme[0] which does both traditional mutation fuzzing as well as LLM-generated targeted regression test cases, where the LLM is pretty effective in understanding the PR and targeting edge cases! It was pretty impressive and I keep getting to think on how we can actually combine LLMs to make fuzzing much more efficient & effective.

// Sorry about the yet-another-LLM-comment. I really love PLs and I'm terribly sorry that I'm contributing yet another LLM-related content (instead of the more interesting stuff!)

[0]: https://github.com/dtcxzyw/llvm-hackme

Comments URL: https://news.ycombinator.com/item?id=49295101

Points: 2

# Comments: 0

Comments URL: https://news.ycombinator.com/item?id=49288650

Points: 3

# Comments: 0

Comments URL: https://news.ycombinator.com/item?id=49064972

Points: 6

# Comments: 0

Comments URL: https://news.ycombinator.com/item?id=48917501

Points: 7

# Comments: 0

> Because Lisp syntax is so much simpler than that of JavaScript etc. it is much easier to avoid errors when generating code. In JavaScript you can use JSON to generate data, but JSON can not carry functions around.

First of all, the LLM does not produce structured tokens, it produces (tokens of) text. It does not have a concept of nested or structured tokens. Which means that producing a Lisp program and a JavaScript program is basically the same difficulty, i.e. LLMs producing function foo () {} is about the same task as producing (defun foo () ()).

In fact, because most Lisps uses the same token ( and ) for almost all delimiters, the LLM in fact gets confused a lot more than Algol-family languages that uses various different tokens for different purposes. It generates thinking traces that are a few screens long while trying to count the closing parenthesis and the depth, something that I have not found to be the case for other languages, even with languages much more obscure than Lisp. (And no, it is not a training data issue, because the Lisp family as a whole is pretty well represented in the data set, due to Emacs Lisp.)

> I think this idea makes a lot sense. Instead of making the LLM generate JSON or XML, why not make it generate Lisp, which can carry both programs and data?

You do realize that all programming languages contains both programs and data, right? i.e. JSON is literally a subset of the JavaScript language, all JSON documents are valid JavaScript code, can be embedded in JavaScript programs, and so on. This isn't even a JavaScript-specific thing, almost all recent programming languages have data structure literals.

The thing that makes Lisp unique is that it can modify programs as data in the language easily, and why would that be a unique capability that would be beneficial for LLMs, when it can just sed/awk or tree-sitter-parse programs with more conventional languages and modify it as easily?

Homoiconicity, as I understand, is that the code is structured data that is easy to programmatically modify, hence allowing Lisp macros. While some might disagree, I see Rust macros as the closest thing that demonstrates homoiconicity in mainstream Algol-based languages, as Rust macros modify the loosely structured token stream to produce new Rust code.

Eval, on the other hand, that’s more of a capability that comes from Lisp’s runtime, which used to be unique when Lisp was thriving, but not anymore — JS, Python, Ruby, all of the runtime-based languages have an eval function. The fact that they are not used as much is more of a security issue, not a capability issue, and I am not sure how having eval can be argued as Lisp being the language of agents.

Comments URL: https://news.ycombinator.com/item?id=48842934

Points: 4

# Comments: 0

I know that it’s purely a UX concern, and that the changes (to decouple the build system and the compiler) are pretty critical for the maintainers, but it’s still a bit sad that development sanity comes first than the UX. (It’s the right call, just that it’s sad.) @cImport was a big killing feature imho to the language…

For the record, I'm one who loves the idea of Mac-assed Mac apps, I believe that the macOS ecosystem would have been much better if all macOS apps were written in AppKit instead of keep being rewritten into Electron. (See: 1Password, Raycast)

I hate Electron as much as the next person, and I hated Electron before hating Electron became a trendy thing to do. I loathe that Electron apps ship an entire Chromium instance for each app, and that it doesn't deduplicate. I am annoyed as hell that out of my 24GB of RAM that my MBA has, Slack, Linear, and Notion decided to each have a "Helper (Renderer)" process that uses 700MB of RAM each.

I do NOT think that Electron or the HTML/CSS/JS stack has an inherent advantage over other display technologies. I can list of at least 15 reasons on the spot on why it's inappropriate to use the web stack for desktop apps.

Yet, despite all of its flaws, people decided to commonly use it (with good reasons, the big one being cross-platform support!) as a display technology for desktop apps. And turns out that it works out okay-ish, they iterated on it and it improved a lot over the last 10 years, and at this point it's a pretty nice solution for the problem. And we already have a bunch of apps that run on it. Sometimes not the best tech wins, and that's okay.

My point was that despite all of the flaws, we developers as a whole decided to use web stuff for desktop apps, and it has properties that make it a good fit for some use cases that we have not solved yet, and we can use that to our advantage.

And if a lot of applications started to be written in the web stack, an OS could integrate an evergreen web browser as a first-class app runtime, and at least we might get less of the Chromium duplication that we currently have with Electron… at least I can dream. (Seems like Windows is going down this route.)

Two arguments:

- TUIs are not inherently superior to GUIs

- SSH, as a transport layer, should support not just forwarding a pty (as a TUI display layer), but a GUI display layer as well

In fact, these two arguments were already realized by UNIX 30 years ago, and we already have one solution: the X protocol and ssh -X.

Unfortunately, X did not win out. We did not get the promised future where one can ssh -X into a remote machine, run gnome-control-center, and a settings window pops up and I can configure my remote computer. (If you believe that this works, try it out yourself. It is an abysmal experience.)

However the above needs still needed to be satisfied by so much people, and apps that needed it started to be developed as web servers, stuff like jupyter notebooks. It turns out that the web’s document format coupled with a styling solution and a client-side scripting language, with all of its warts and drawbacks, became a viable solution as a display layer for interactive apps. In fact, since it started from remote documents, network transparency is built-in.

It would be dumb to not realize that the HTML/CSS/JS stack did win a dominant position for desktop apps, with all of the Electron apps, and utilize the web as a display layer for the above. I see the project in a similar vein, i.e. utilizing HTML/CSS/JS to provide a display layer for remote apps via SSH.

Also note that Electron apps has the same split with X, where the display server and the client are separated: it's called the "renderer process" and the "main process", and the two processes talk via IPC (where the display server would be the renderer process running embedded Chromium, the display client would be the Electron main process, and the stuff that the client sends to the server would be the contents of the renderer JS bundle). I think, theoretically, it would be possible to run the main process separated from the renderer process on a different machine, with an appropriate IPC transport. I think this would be not far from the above idea?

Comments URL: https://news.ycombinator.com/item?id=48653628

Points: 2

# Comments: 0

Comments URL: https://news.ycombinator.com/item?id=48653216

Points: 387

# Comments: 221

A point that I haven't seen come up a lot, but is very valuable to me is that for open source models, I can select the inference provider myself (even if it's not a local GPU), which means that I can enjoy superb speed (i.e. 300 tok/s) while still spending much less than the big providers.

My experience is that if you were fine with the coding models of yesterday (i.e. Claude Opus from Jan/Feb of 2026), you will be fine with either Kimi K2.6 or DeepSeek v4 Pro. Kimi is a bit more smart but has only 256K context and the performance deteriorates (and sometimes just gets stuck) when it fills up the context window. DeepSeek v4 has a 1M context and performs just as well with much less issues. And they both generate very idiomatic code, gives the same vibe of Opus a few months ago.

Since it's also fast (and does not fixate on trying to fix impossible problems, unlike the recent Opus/GPT 5.5 models), a big benefit is that you still control and steer the coding agent and you won't be losing focus like the major models. They are smart, but they don't fixate as much on trying to do stupid things, and since it's fast, you can just interject. It's a much more pleasant experience than the latest models.

I still use the latest models time to time when I expect the agent to fixate all of the problems and figure out everything themselves, but for me open source models are like 80~90% of all of my sessions.

I can recognize so much of the GPT/Codex generated code long after it gets merged (not by me).

Additionally, the time spent on every agent turn on GPT 5.5 is much longer compared to Claude Opus 4.8, which means iterating on the code takes a lot more patience, and there's a lot more nitpicks to pick when actually using GPT 5.5 to do software engineering.

Feels like GPT-style models are more geared on doing one-shot software vibing (and handling the vibe coded mixture) compared to Claude's focus on actual software maintenance. I got a GPT Pro sub for free and wanted to cancel my Claude subscription so much, but I still keep reaching Claude models a lot more. Frustrating.

Comments URL: https://news.ycombinator.com/item?id=48465194

Points: 2

# Comments: 0

Comments URL: https://news.ycombinator.com/item?id=48318522

Points: 226

# Comments: 79

Comments URL: https://news.ycombinator.com/item?id=48305188

Points: 2

# Comments: 0

Comments URL: https://news.ycombinator.com/item?id=48219404

Points: 2

# Comments: 0