Cool line of questioning, but one piece of information is pivotal and critically not-yet-included: equivalent accomplishments in each language. For example, if I want to write standard things: web server, memoized fibonnaci, recipe search engine, what's the length-and-density of these outputs for each language? I think that would add in some ~normalization.
Strongly agree- this is how I “evaluated” languages pre-agents. though I suspect this would bias results in favor of whatever has best signal to noise for boilerplate from stackoverflow/reddit , rather than what LLM’s “””reason””” best with. (Presuming those aren’t quite one-and-the-same)
Is doing something for yourself really working for free? That's an interesting take. But I can understand why you don't want this for yourself, so enjoy the page in all its splendour as it is already!
I mean, if it really bothers you you could fairly trivially apply picocss or whatever to it using a user stylesheet. That is so little effort that calling it working for free would be disingenuous to say the least.
For people in the future who want to apply the centered viewport classless version of Pico CSS, just apply the following in Firefox's Style Editor (F12 to open DevTools, then click on Style Editor; click on the + sign to add a new style):
Browser vendors have really dropped the ball in supporting CSS, which is no doubt how we get comments like the above. Firefox is likely the least-worst offender, but as you point out still needlessly complicated for what CSS considers to be a foundational feature.
CSS is explicitly designed for you to apply your own user stylesheet. That is exactly what it envisions you doing. If you don't like web technologies you might want to question what you are doing on the web. However, the web also encourages sharing, so no, theoretically once one user has created a user stylesheet they would share it with others so there would be no need for everyone to create their own, unless they had alternative tastes.
A closer analogy is going to a gas station where a microwave is offered to heat up any food you purchased. If you don't want to heat up the food, cool. If you expect the food to come hot you're in the wrong place.
Except in this case it's a gas station that only exists for the benefit of its owners and there isn't any food for sale. The owners have graciously said you could still use the microwave if you'd like, though.
I love this take because I had exactly the opposite idea. I thought the combo of remarkably simple text (not even wrapped) with incredible, full width visualizations was chef's kiss. I really like the balance there personally, but I hear you. Does your browser have Reader Mode or something like that? I don't use those tools personally, but I believe they will recast the text parts into something that renders optimally for reading (ideal font size, number of characters per line, etc....).
HN’s favorite CS professor homepage webpage-style author is on top of the AIs but sticking with keeping out newfangled CSS. Nothing could tell us more about clanker inevitability.
One thing worth noting is that syntactic density doesn't necessarily mean cheaper because because symbols don't chunk/tokenize as well as plain English
What I see from results like this is that the delta between languages is small enough now that it's hard to justify not not using something like Rust for the performance and correctness benefits if you're using LLMs and it fits the domain
> Dynamically typed languages generally have a lower LLM token cost than traditional statically typed languages because omitting explicit type declarations makes the code more compact.
If this was true, the programming languages that are very much on the left side of
should be very ideal for LLMs, in particular if they are dynamically typed.
What I can tell you is: I experimented with AI prompts for generating Wolfram (Mathematica) code using some LLMs, and I can tell you that the results were very disappointing: in my experience LLMs have difficulties with programming languages that are
- very concise, and
- for which there is less code publicly available.
Wolfram (Mathematica) is a good example of such a programming language.
I’ve actually found Sol delivers great results with Odin, despite there not being much Odin code available. I think it is able to work well with it because:
- It is a rather simple language
- It has a lot of very useful libraries already built in.
With just a single main.odin file you can do a heck of a lot stuff, which LLMs seem to like.
> I think it is able to work well with it because:
> - It is a rather simple language - It has a lot of very useful libraries already built in.
> With just a single main.odin file you can do a heck of a lot stuff, which LLMs seem to like.
Also Wolfram/Mathematica has an insane amount of useful libraries already built in (there even exists the saying "Python is 'batteries included', Wolfram is 'spaceship included'"), and also there in a single file you can do a heck of a lot stuff.
On the other hand:
- LLMs tend to hallucinate non-existing function when you ask an LLM to code something in Wolfram that is not commonly done (concerning this point, nevertheless keep in mind that Wolfram is often used for "one-of-a-kind programs", i.e. for writing very specialized programs that have possibly never been done before).
- Wolfram code tends to be quite dense.
- If there is a small mistake in Wolfram code, the code typically simply won't work.
It’s interesting I’ve been surprised by how well Claude sonnet can write code in a language I’m developing that probably has no code in the training set. It seems like anything with syntax like python/ruby/elixir is pretty LLM friendly, and layering on a HM type system seems to help catch most errors.
I discovered last week that Fable 5 can write perfect xTensa LX7 assembler code without tools or references. Mind blown.
But, when working on a creative graphics task, the results were best in Lua, middling in integer-only C, and underwhelming in ASM in terms of creative depth.
Why would this be the case when the text that produces binaries (code) is usually both more token efficient and vastly more effectively organized for modification/extension?
Unless by bits you just mean text in general, or any data since it’s all bits, in which case what you’re saying is trivially already true.
It seems like you’re saying that long term LLMs will output pure machine code as the most effective way to use them.
What about the other thing that’s the actually important part of my reply, modifiability/extensibility? You just chose the weaker of the two factors I provided. And didn’t even provide a convincing argument related to it.
You also didn’t clarify your position at all.
Explain why there is any benefit to outputting raw machine instructions compared to writing shorter, more interpretable, modifiable, extensible code and then using a compiler to turn it into machine code.
Why are agents not going to use compilers in the future?
Is there a relationship between how good a programming language is for coding agents and how popular it is among humans? If so, wouldn't Python be the best language for agents, since it's is the most popular (and hence has the most context available for models)?
There is definitely a relationship. But I personally believe that once the training corpus reaches a certain scale, the returns exhibit diminishing marginal effects, to the point that multiplying the data volume cannot surpass something essential inherent in language design. (Asked an LLM to help me with the translation, so forgive my expression)
Pick something slightly esoteric (eg Haskell) and the quality of public code is very high, because you only have enthusiasts writing it. Choose something taught in schools (Python) and you are going to find 10,000 traveling salesmen homework problems and Django todo applications.
Not sure how you thread the needle on the quality vs quantity dynamic.
Your point is a good one: Exotic, difficult languages attract enthusiasts with deeper skills than a median developer.
Haskell also has a confounding issue: Because of its focus on research and experimentation, standard best practices don't exist like they do in languages optimized for real-world use. Because there are few community guidelines, engineering practices vary widely, and unfortunately at the same time, Haskell's public codebase resources are small.
To see this playing out, check out Haskell discussions about choosing a SQL library, effect system, monad transformer stack, or web framework. The answers are all over the map because that diversity is baked into Haskell's culture and practice.
Was going to ask what is the Numpy equivalent in Haskell. Cause Python has a thousand decent examples of how to do everything you might want to do in Numpy.
there is a relationship there, but there is also a relationship to the safety of the language and the guard rails in place.
it's a lot harder to experience an agent telling you with certainty that something incomplete is totally finished if there is a comprehensive test suite, a hard failing compiler, a strict type system, etc.
LLMs like to produce a lot of JS and python that silently fails in a graceful way -- why is that? because those languages support that kind of a failure.
when using something like go/rust the LLMs are more likely to re-iterate rather than declaring a victory when they get a strict compiler barking in their face, refusing to output.
182 comments
And every person globally should do this as well for any other website that doesn't have a good default reading experience?
Actions speak louder than words.
> Order food
> Food comes out as raw, unprepared ingredients
> Complain to chef
> Tells me to go cook it myself
> wtf, I'm not here to do work for free
> "Is doing something for yourself really working for free?"
Except in this case it's a gas station that only exists for the benefit of its owners and there isn't any food for sale. The owners have graciously said you could still use the microwave if you'd like, though.
https://danluu.com/web-bloat/
That's all it needs, responsive enough for all devices. He can keep his styleless design but margin is always needed.
What I see from results like this is that the delta between languages is small enough now that it's hard to justify not not using something like Rust for the performance and correctness benefits if you're using LLMs and it fits the domain
If this was true, the programming languages that are very much on the left side of
> https://danuker.go.ro/programming-languages.html#non-math-ma...
> https://danuker.go.ro/programming-languages.html#overall-map
should be very ideal for LLMs, in particular if they are dynamically typed.
What I can tell you is: I experimented with AI prompts for generating Wolfram (Mathematica) code using some LLMs, and I can tell you that the results were very disappointing: in my experience LLMs have difficulties with programming languages that are
- very concise, and
- for which there is less code publicly available.
Wolfram (Mathematica) is a good example of such a programming language.
- It is a rather simple language - It has a lot of very useful libraries already built in.
With just a single main.odin file you can do a heck of a lot stuff, which LLMs seem to like.
> - It is a rather simple language - It has a lot of very useful libraries already built in.
> With just a single main.odin file you can do a heck of a lot stuff, which LLMs seem to like.
Also Wolfram/Mathematica has an insane amount of useful libraries already built in (there even exists the saying "Python is 'batteries included', Wolfram is 'spaceship included'"), and also there in a single file you can do a heck of a lot stuff.
On the other hand:
- LLMs tend to hallucinate non-existing function when you ask an LLM to code something in Wolfram that is not commonly done (concerning this point, nevertheless keep in mind that Wolfram is often used for "one-of-a-kind programs", i.e. for writing very specialized programs that have possibly never been done before).
- Wolfram code tends to be quite dense.
- If there is a small mistake in Wolfram code, the code typically simply won't work.
There is a way to check whether a symbol has been defined:
See https://reference.wolfram.com/language/ref/ValueQ.htmlReplace FunctionName by the function name that you want to check.
I guess this ignores languages with type inference? Hindley-Milner and others
Which programming languages are most token-efficient? - https://news.ycombinator.com/item?id=46582728 - Jan 2026 (91 comments)
Fable and Opus 5 have been released since then along with the corresponding OpenAI models.
But, when working on a creative graphics task, the results were best in Lua, middling in integer-only C, and underwhelming in ASM in terms of creative depth.
I'm saying, eventually, it will... perhaps :)
Unless by bits you just mean text in general, or any data since it’s all bits, in which case what you’re saying is trivially already true.
It seems like you’re saying that long term LLMs will output pure machine code as the most effective way to use them.
You also didn’t clarify your position at all.
Explain why there is any benefit to outputting raw machine instructions compared to writing shorter, more interpretable, modifiable, extensible code and then using a compiler to turn it into machine code.
Why are agents not going to use compilers in the future?
The benefit would be that the AI would have true hardware access. It would be unconstrained by gatekeeper protocols.
Would be very powerful, and thereby, potentially dangerous.
Not sure how you thread the needle on the quality vs quantity dynamic.
that and the language supports (enforces) good decision making; static typing w/ inference and a functional style as a first class concept.
which then rolls into the same result : higher quality code available.
Haskell also has a confounding issue: Because of its focus on research and experimentation, standard best practices don't exist like they do in languages optimized for real-world use. Because there are few community guidelines, engineering practices vary widely, and unfortunately at the same time, Haskell's public codebase resources are small.
To see this playing out, check out Haskell discussions about choosing a SQL library, effect system, monad transformer stack, or web framework. The answers are all over the map because that diversity is baked into Haskell's culture and practice.
it's a lot harder to experience an agent telling you with certainty that something incomplete is totally finished if there is a comprehensive test suite, a hard failing compiler, a strict type system, etc.
LLMs like to produce a lot of JS and python that silently fails in a graceful way -- why is that? because those languages support that kind of a failure.
when using something like go/rust the LLMs are more likely to re-iterate rather than declaring a victory when they get a strict compiler barking in their face, refusing to output.