Live data from Hacker News

Which programming languages are most token-efficient?

martinalderson.com

61–70 of 96 posts

Re: Which programming languages are most token-efficient?

#61

Concatenative languages like Factor and Forth are very token-efficient in theory. Theoretically optimal for raw lexical density. No parentheses, no commas, no argument delimiters, just whitespace-separated words, but stack shuffling can add overhead for complex data flow, unless you use "locals" in Factor, for example. C is surprisingly efficient as well. Minimal keywords, terse syntax, single-character operators. No…

I understand your logic but I found LLM's to be quite strong at C#. It makes little mistakes and the mistakes seem related to the complexity of what I'm doing, not the language itself.

Re: Which programming languages are most token-efficient?

#62
post #6

Realistically, it’s also a function of how many iterations it takes for an AI agent to correctly solve a problem with a given language. I’d imagine most AI agents would frequently have to redo J or F# code, as they are fairly uncommon languages with much smaller training set than JavaScript or Python.

I can say that for F# this has been mostly true up until quite recently. We use F# at work and were mostly unable to use agents like Claude Code up until the release of Opus 4.5, which seems to know F# quite well.

(I concur, Opus 4.5 is quite capable of writing F#.)

Re: Which programming languages are most token-efficient?

#63
I program mostly in Clojure and I expected it to be near the top, as it tends to be very concise and expressive (qualities I really admire). I am getting excellent results from Claude Code (Opus 4.5), and I think this might be one of the reasons. I'm using Claude with a large code base and the token-efficiency of Clojure might help with fitting more into the context window.

Re: Which programming languages are most token-efficient?

#64
post #32

Earlier quoted context omitted.

LLMs in their current form rely heavily on the vast amount of human data that's available, to learn from it as a first step (the second step is RL). We're not building a language for LLMs just yet.

It's worth asking why we haven't had the AlphaZero moment for general learning yet, where no human data is needed.

I think the issue is that for games and other closed-ended systems the criteria are very easy, so self-referential training is effective.

Re: Which programming languages are most token-efficient?

#66
post #54
post #22

Earlier quoted context omitted.

I'm inclined to agree with you in principle, but there's much, much less Haskell examples in their training corpus than for JavaScript or Python.

From what I've heard—and in my own very limited experiments—LLMs are much better at less popular languages than I would have expected. I've had good results with OCaml, and I've talked to people who've had good results with Haskell and even Unison. I've also seen multiple startups that have had some pretty impressive performance with Lean and Rocq. My current theory is that as long as the LLM has sufficiently good ba…

As a huge proponent of constrained decoding for LLM reliability, I don't quite think it's the right approach for code. This is because in many programming languages, it is legal to use a function before its declaration. Since this is common in existing code, LLMs will also try to write code that way.

Re: Which programming languages are most token-efficient?

#67
post #54
post #22

Earlier quoted context omitted.

I'm inclined to agree with you in principle, but there's much, much less Haskell examples in their training corpus than for JavaScript or Python.

From what I've heard—and in my own very limited experiments—LLMs are much better at less popular languages than I would have expected. I've had good results with OCaml, and I've talked to people who've had good results with Haskell and even Unison. I've also seen multiple startups that have had some pretty impressive performance with Lean and Rocq. My current theory is that as long as the LLM has sufficiently good ba…

You might be right, but I think you must take into account that (I think) you're not super familiar with these languages as well, so you might not notice all the warts a programmer with a lot of experience in these langs would, and overrate the skill of the LLM.

Nowadays, I write C# and TS at work, and it's absolutely crazy how much better the LLM is at TS, with almost all code being decent the first try, but with C# I need to do a lot of massaging.

Re: Which programming languages are most token-efficient?

#68
This confirms my personal experience with switching to Go from C# - despite the e framework and language being MUCH simpler, the code usually ends up the same length.

C# often has a 'nice' and 'performant' way of doing things (for example, strings are nice, but they allocate and are UTF16, but ReadOnlySpan is faster for UTF8, and can reuse buffers), the performant syntax often ends up being very verbose, with the nice syntax being barely shorter than Go's. Go also does the right thing by default, and its strings are basically array slices into UTF8 byte arrays.

Re: Which programming languages are most token-efficient?

#69

Concatenative languages like Factor and Forth are very token-efficient in theory. Theoretically optimal for raw lexical density. No parentheses, no commas, no argument delimiters, just whitespace-separated words, but stack shuffling can add overhead for complex data flow, unless you use "locals" in Factor, for example. C is surprisingly efficient as well. Minimal keywords, terse syntax, single-character operators. No…

Is that statement about C based on anything in particular? C was 18th of all the languages in the article's chart (the worst!), which I'd guess was due to the absence of a standard library.

Fair point. There is a distinction between syntactic efficiency (C is terse) and task-completion efficiency (what the benchmark likely measured). If the tasks involved string manipulation, hash maps, JSON, etc. then C pays a massive token tax because you are implementing what other languages provide in stdlib. Python has dict and json.loads(), C has malloc and strcmp.

So: C tokenizes efficiently for equivalent logic, but stdlib poverty makes it expensive for typical benchmark tasks. Same applies to Factor/Forth, arguably worse.

Re: Which programming languages are most token-efficient?

#70

I'm finding that I have to share more and more code to ensure that various standards are being kept. For example I shared some Model code with Claude and Gemini (both via web interfaces) and they both tried to put Controller code into the Model, despite me multiple times telling them that the code wasn't wanted nor needed in there. I had to (eventually) share the entire project with the models (despite them having be…

You’re severely hampering yourself by not using the CLI tools.
Post reply on HN