goranmoomin

A Lisp program that writes a Lisp program really just needs to produce a list of (nested lists) of tokens. A JavaScript program that writes a javascript program needs to generate a string that is syntactically valid JavaScript code. That is a much bigger task than just constructing a (nested) list.

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?

I like Lisp, I’ve used Common Lisp with a passion, but this doesn’t seem like a valid argument for Lisp.

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.

So this is the change that forced Zig to remove @cImport (and into the build system), right?

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…

they still don't understand Electron is vastly superior technology

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.)

It is pretty annoying to see all of the dismissive comments on this idea, in that it seems that the majority of HN audience are still stuck on the TUI-superiority mindset and they do not care about GUIs at all.

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?

I'm not using my models locally, but the majority (80% or more) of my coding agent sessions run on open source models, i.e. DeepSeek v4 Pro and Kimi K2.6 with thinking.

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.

My experience is that the GPT-family of models are very smart and figure out bugs, edge cases a bit better, but it produces code that is much less mergable – if you review the code, it introduces a lot more useless/inappropriate heavy abstractions and wrapper functions, compared to the Claude-family models which introduces the right amount of straightforward human-style code.

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.

TBH as an outsider, I am just so frustrated on Trump deciding that US invading Iran large scale is a great idea. (And why even is it involving Israel for gods sake?!)

If you guys wanted to be supportive to the Iranian protests, US could instead just selectively target some of the leadership and give the protests a push (and give the whole world a hint that US is supportive of them).

After 40 years of Iran constructing a thearchy government, the Iranians finally started having a huge protest on throwing up the thearchy government and possibly talking about a new west-friendly government.

And then Trump just decides to wholesale invade Iran with Israel?

That's just giving so much more reasons for the current government to be in power and the Iranians to hate the US and more generally the western world. It took 40 years for the Iranians to realize that there's enough problems in the thearchy system and want their more secularized country back; and then Trump just destroyed the whole premise!

Does the US just really think that they will be loved by everyone when they rage in and invade any random country? Do they really think like that? I'm just frustrated so much. How can the US be so egocentric?

Have to say, this feels like Web 2.0 all over again (in a good way) :)

When having APIs and machine consumable tools looked cool and all that stuff…

I can’t see why people are looking this as a bad thing — isn’t it wonderful that the AI/LLM/Agents/WhateverYouCallThem has made websites and platforms to open up and allow programatical access to their services (as a side effect)?

The impact on context tokens would be more of a 'you're holding it wrong' problem, no? The GH MCP burning tokens is an issue on the GH MCP server, not the protocol itself. (I would say that since the gh CLI would be strongly represented in the training dataset, it would be more beneficial to just use the CLI in this case though.)

I do think that we should adopt Amp's MCPs-on-skills model that I've mentioned in my original comment more (hence allowing on-demand context management).

The main problem with this approach at the moment is it busts your prompt cache, because LLMs expect all tool definitions to be defined at the beginning of the context window.

TBH I'm not really sure how it works in Amp (I never actually inspected how it alters the prompts that are sent to Anthropic), but does it really matter for the LLMs to have the tool definitions at the beginning of the context window in contrast to the bottom before my next new prompt?

I mean, skills also work the same way, right? (it gets appended at the bottom, when the LLM triggers the skill) Why not MCP tooling definitions? (They're basically the same thing, no?)

model understanding of the provided tool and token waste in the model trying to understand the tool and token waste in the model doing things ass backwards and inflating the context because it can't see the vastly shorter path to the solution provided by the tool and...

But even then, throw them a tool they don't understand that has the same capabilities as a tool they do understand and you're going to burn a bunch of tokens watching it try to figure the tool out.

What I was trying to say was that this applies to both MCPs and CLIs – obviously, if you have a certain CLI tool that's represented thoroughly through the model's training dataset (i.e. grep, gh, sed, and so on), it's definitely beneficial to use CLIs (since it means less context spending, less trial-and-error to get the expected results, and so on).

However if you have a novel thing that you want to connect to LLM-based Agents, i.e. a reverse enginnering tool, or a browser debugging protocol adapter, or your next big thing(tm), it might not really matter if you have a CLI or a MCP since LLMs are both post-trained (hence proficent) for both, and you'll have to do the trial-and-error thing anyway (since neither would represented in the training dataset).

I would say that the MCP hype is dying out so I personally won't build a new product with MCP right now, but no need to ditch MCPs for any reason, nor do I see anything inherently deficient in the MCP protocol itself. It's just another tool-calling solution.

I can't believe everyone is talking about MCP vs CLI and which is superior; both are a method of tool calling, it does not matter which format the LLM uses for tool calling as long as it provides the same capabilities. CLIs might be marginably better (LLMs might have been trained on common CLIs), but MCPs have their uses (complex auth, connecting users to data sources) and in my experience if you're using any of the frontier models, it doesn't really matter which tool calling format you're using; a bespoke format also works.

The difference that should be talked about, should be how skills allow much more efficient context management. Skills are frequently connected to CLI usage, but I don't see any reason why. For example, Amp allows skills to attach MCP servers to them – the MCP server is automatically launched when the Agent loads that skill[0]. I belive that both for MCP servers and CLIs, having them in skills is the way for efficent context, and hoping that other agents also adopt this same feature.

[0] https://ampcode.com/manual#mcp-servers-in-skills

tldr; they wanted to run a Tauri app in browser for dev purposes.

To do so, they shimmed the Tauri’s rust communication bridge to use web-socket to communicate with the main app’s rust implementation.

This is only used by dev, but if something like this is provided by Tauri/Electron it can probably enable a bunch of interesting use cases… (and probably a bunch of RCEs as well, though)

TBH I am sad that Anthropic is changing its stance, but in the current world, if you even care about LLM safety, I feel that this is the right choice — there’s too many model providers and they probably don’t consider safety as high priority as Anthropic. (Yes that might change, they can get pressurized by the govt, yada yada, but they literally created their own company because of AI safety, I do think they actually care for now)

If we need safety, we need Anthropic to be not too far behind (at least for now, before Anthropic possibly becomes evil), and that might mean releasing models that are safer and more steerable than others (even if, unfortunately, they are not 100% up to Anthropic’s goals)

Dogmatism, while great, has its time and place, and with a thousand bad actors in the LLM space, pragmatism wins better.

Yeah I realized that only now, for some reason when I was on mobile and I was looking into this the demo video was not loading at all. I would love to retract my comment :(

I feel like declarative container-like dev environments (e.g. nix shell or guix shell, and so on) will become much more popular in the following years with the rise of LLM agentic tools. It seems that the aformentioned tools provide much more value when they can get full access to the dev environment.

Sprites[0], exe.dev[1], and more services seem to be focusing on providing instant VMs for these use cases, but for me it seems like it's a waste for users to have to ssh into a separate cloud server (and feel the latency) just to get a clean dev environment. I feel that a similar tool where you can get a clean slate dev environment from a declarative description locally, without all of the overhead and the weight of Docker or VMs would be very welcomed.

(Note: I am not trying to inject AI-hype on a Guix-related post, I do realize that the audience of LLM tools and Guix would be quite different, this is just an observation)

[0] https://sprites.dev

[1] https://exe.dev

This is very interesting, I haven’t touched macOS development for quite a while but it’s good to know that libraries are still being written for both AppKit and SwiftUI on macOS.

I do feel that this library would benefit from an explanation on why this was needed. AFAIR AppKit already provides a native tabbing API where you can “just” (that “just” is doing a lot of heavy lifting) implement a few delegate methods and you get tabbing behavior for free, especially on document-based apps. (Sorry, I do not remember the specifics, it might have been a tad more difficult)

I’m not updated on the SwiftUI equivalent, but I would imagine that a similar API would exist much alike API for multiple windows or multiple documents.

I think everyone would benefit from a “why” explanation (which I definitely think would exist, since I’ve used too many AppKit APIs in pain), and also some screenshots for a demo app (so that we can expect how it would look and how much the look and feel would deviate from the native counterparts).

I haven't even realized that while I was reading the article, but it is amusing!

Though one explanation is that I think for the other stuff that the writer doesn't explain, one can just guess and be half right, and even if the reader guesses wrong, isn't critical to the bug ­— but sockets and capabilities are the concepts that are required to understand the post.

It still is amusing and I wouldn't have even realized that until you pointed that out.

I'm genuinely curious on how well this is working, is there an independent Java test suite that covers major Java 5/6 features that can verify that the JOPA compiler works per the spec? I.e. I see that Claude has wrote a few tests in it's commits, but it would be wonderful if there's a non-Clauded independent test suite (probably from other Java implementations?) that tracks progress.

I do feel that that is pretty much needed to claim that Claude is adding features to match the Java spec.

It is beyond annoying that the article is totally generated by AI. I appreciate the author (hopefully) spending effort in trying to figure out the AI systems, but the obviously-LLM non-edited content makes me not trust the article.

I knew for a fact that a Linux desktop was a viable option when you have a separate macOS/Windows laptop (which is my main computer). Recently (frustrated with macOS updates), I decided to be Linux-only for a week[0], replacing my MBP with an MBA that runs Asahi Linux.

Unfortunately it turns out that I depend on too many desktop apps that runs on the major desktop OSes but not on Linux (or on Wine, for that matter).

* KakaoTalk, the major South Korean IM app ran on Wine for a week, but the updater doesn't work and freshly reinstalling the app broke Wine for some reason. (I tried removing the whole ~/.wine prefix, but it doesn't work.) Now I'm stuck without KakaoTalk.

* Discord is only provided as a x86_64 Deb file and a .tar.gz file. I tried using it from Firefox, and it works fine but audio sharing during screen sharing doesn't work.

* Disconnecting from my Bluetooth AirPods somehow does not stop my music. I'm not sure if this is an AirPods limitation or a Linux limitation (since I've never used AirPods with Windows), but it annoyed me endlessly.

* USB-C DP mode and the fingerprint sensor doesn't work. This is an Asahi Linux limitation, but I've seen various parts of the hardware not working when using other Linux distributions on laptops as well. I feel this is a common occurrence.

Not to mention that the lack of text editing shortcuts that macOS has, which is a big deal to me (but I tried as that is a macOS-ism).

I carried my MBA for 4 days before I gave up today. I brought my MBP today with me.

[0] https://news.ycombinator.com/item?id=45940274

I can't see how this is being blamed to the phone device maker (or the users who have not updated yet), why is Australia phasing out their 3G network if a large swath of their people's phones are dependent on them for dialing their emergency number?

In my view, they (the govt) either should have not gave permission on selling the devices who relies on having a 3G network for emergency calls for at least 10 years ago, or they should just have their 3G network operable for another 5 years.

For example, our country (South Korea) had 2G networks operable until ~2021, and are planning to have all of the 3G networks operable for the foreseeable future. It can be done.

According to the prevalent narrative in North Korea, the war was won by the communists.

According to the North Korean govt, the Korean war was started by the South who wanted to invade North (it was not, based on extensive studies). Therefore in their view (or at least from their propaganda), the communists "won" by successfully defending their part of the peninsula.

(I'm a South Korean.)

According to the prevailing narrative in North Korea, the war was won by the communists and since then, the entire Korean peninsula has remained united under the rule of the Korean Workers’ Party.

This is either not true at all or the writer phrased strangely ­— both of the governments (South & North) recognize that the war is still on-going and they have an enemy that is controlling the other half of the peninsula that they do not control. However, both of the governments also argue that they are the only legal government that is ought to control the whole peninsula and does not recognize each other's legitimacy. For example, ROK(Republic of Korea, the government that controls the southern part of the peninsula)'s constitution writes that it's government governs the whole peninsula and it's islands. It's like how both PRC(People's Republic of China, i.e. China) and ROC(Republic of China, i.e. Taiwan) both argue that they are the only legal government over all of China (i.e. Mainland China and Taiwan combined).

Therefore, when looking at the maps in this atlas, it should come as no surprise that Korea is always shown as one country, with no reference to the other country that exists at the southern tip of the peninsula.

It is universally agreed between the two governments (and their citizens) that a unification should happen at some point, so it is obvious that we should be using a map that covers the whole peninsula. We (as South Koreans) also learn 'our country' as the whole peninsula.

This North Korean world map is centred on the Pacific Ocean, which gives Korea a privileged position on the global stage.

Not going to lie, sometimes it feels that some of the Westerners act like that they don't even think of the remote possibility that they might not be the center of the world…?

South Korean maps do this, China maps do this, Japanese maps do this, I'm pretty sure South East Asia countries also do this, it's a normal thing to do. There's nothing special about having the Pacific Ocean centered.

This article just pushed me over to retry Linux on my laptop, and I've been spending the last 2 hours on a Linux desktop. I would love to use it as my main driver (will try the next week), but it still feels like a thousand paper cuts and realize why I was stuck on macOS for the last 10 years. Ugh :(

While I might not think that JS is a good language (for some definition of a good language), to me the provided spec does feel pretty small, considering that it's a language that has to be specified to the dot and that the spec contains the standard library as well.

It has some strange or weirdly specified features (ASI? HTML-like Comments?) and unusual features (prototype-based inheritance? a dynamically-bounded this?), but IMO it's a small language.

I can’t see why — I do think that the word does convey some sort of useful meaning with the above definition.

IMO: Transpilers are compilers, but not all compilers are transpilers.

In my book, transpilers are compilers that consume a programming language and target human-readable code, to be consumed by another compiler or interpreter (either by itself, or to be integrated in other projects).

i.e. the TypeScript compiler is a transpiler from TS to JS, the Nim compiler is a transpiler from Nim to C, and so on.

I guess if you really want to be pedantic, one can argue (with the above definition) that `clang -S` might be seen as a transpiler from C to ASM, but at that point, do words mean anything to you?

AFAIK Safari was the first browser to support MathML fully, and FF also supports it. Chromium was the latest IIRC. MathML has been baseline-available since 2023 after Chromium got support.

The big issue is that MathML is designed as a target language, not something directly writable. So we still need a KaTeX equivalent, which compiles either LaTeX equations or other markup languages to MathML.

Regardless, the core issue that you have mentioned is now gone (or will be in a few years even if you want more availability).