completely agreed. Regardless of AI or not, the blog post completely lacks any kind of introduction and context at the start. I had to stop after the first two paragraphs because I just didn't understand anything.
I don't think any new languages will easily beat the existing ones, simply because of the mass of training data that is available. An LLM will have a much easier time one-shotting Java than even Rust today because it doesn't have to look up much and the ecosystem was stable for many years, so the internet is filled with content that is still up2date. Building a new language (or even altering existing ones) will take much longer to get into the models.
LLMs that have to constantly fix their code and look up libraries or features are much slower, more expensive and more prone to create inefficient and slightly wrong code. Sure, an LLM can just create a new web framework from scratch, but you usually don't want to spend your tokens on that.
I also think that with LLMs, new languages will have more trouble building an ecosystem, because until now, the popular libraries had a "proof of work" that kinda also made sure that they were well-trodden and maintained. Now, anyone can just push their new generated library and we have no clue on how to compare (and tbh reading LLM-generated READMEs is also not pleasant).
"LLMs dont create anything new, if programmers stop reading the code technology will be forever frozen to 2022, no new programming languages, operating systems, concurrency primitives, databases, networking protocols, UI frameworks everything will be based on the training data and future generations will forget about all the primitives we now take for granted.
If someone creates a new programming language/ framework or new better way to do async or whatever, no one will use it because it is not in the training data and it wont take off because everyone is using LLMs. It will be like using the same Lego pieces over and over."
Mmmm idk. I used an LLM to write assembler in my made up API so I don’t think what you say is true. The value in LLMs is precisely that they are not just regurgitating training data, but rather inferring concepts extracted from trained data. If a programming language used concepts completely disconnected from existing paradigms you’re probably right… but that would also be quite challenging for humans to learn to use, since by intrinsic construction it would also be widely separated from human language.
Esoteric languages like BrainFuck are esoteric and difficult precisely because they go out of their way to eschew conceptual links to existing languages or paradigms.
So if you invented a new type of esoteric language with arbitrary syntax and strange operators (not sure how you’d do that, exactly, iirc all fundamental binary operators are known) it might be impossible to use with an LLM even if the user manual was in context… but aside from that, languages and the underlying concepts are extremely generalizable.
Yeah. I have my own file formats for music, pixel art, and levels in a little game I’m building with the kids. LLMs are really good at understanding these proprietary formats that exist nowhere else in the world except on my old laptop.
> I used an LLM to write assembler in my made up API so I don’t think what you say is true.
I think you are underestimating the amount of data/context that is required to use a battle tested general purpose language, for both humans and LLMs. The ecosystem requires official docs, stack overflow answers, blog posts, tutorials, existing source code, subreddits, issue/PR discussions of undocumented features, obscure mailing list threads with rare insights, books, youtube videos, benchmarks, tests suits... and the ecosystem of libraries for the language that also need their own official docs, stack overflow answers...
You also need the collective audit by the community and assurance that this language has been used in production by countless others.
In the age of intelligence on tap, any new language not specifically designed for human-only use will be born into the world with an attendant plague of documentation. And languages are shockingly generalizable. There are few things in any language that cannot be done in any other. Even those are computationally equivalent to some other set of instructions.
What might be the case though, is that new languages will use more context to think about until they are well represented in the training set.
> I don't think any new languages will easily beat the existing ones, simply because of the mass of training data that is available.
Seems like a solvable problem though by generating synthetic data that’s guaranteed to be accurate through linters, compilers and tests.
If it’s ~9 figures to train a frontier model, it seems like training on a new language could be a rounding error if it was a priority.
I could see the appeal of a new agentic-friendly language that’s focused on minimizing tokens. The standard library could be massive with no concern of making the language easily readable or learnable.
> Seems like a solvable problem though by generating synthetic data that’s guaranteed to be accurate through linters, compilers and tests.
This makes sense and is very insightful, thank you. But with that solution it seems that only LLM companies will be in the position to create new languages.
Tremendous amounts of the Java out there in the training corpus would be based on outdated patterns, especially anything pre-Java 8 or pre-Java 21 (Pattern Matching, Project Loom). I don’t think this negatively impacts the quality of LLM Java code but it sort of calls into question whether this is simply a case of more is better.
My personal experience is that LLMs are quite good at one-shotting complex solutions in both Rust and Go, and tend to be idiomatic.
I've been playing around with a new DSL, and I've had good luck adding a "describe" feature, eg,
newdsl describe some_feature
This returns the docs for that language feature. So instead of a giant SKILL.md containing the language spec, it exposes a way for an LLM to introspect.
DSLs climb the ladder of abstraction and constrain the solution space at the language level, which IMO provides tighter feedback to both humans and machines.
The frontier models are exceptionally good at one shoting rust. I find them to be even better at writing rust than python (and the dataset for python must surely be bigger). I think there might be a threshold of enough data for a programming language to make it useful for an agente
All of those verbs basically mean "degrade an existing system, after the fact". If anthropic states beforehand that certain use cases are not possible, it should be fine, no?
To give another (bad) analogy: The Pens aren't made to be weapons themselves, they are not intended for that. If the DoD now tries to shoot pens as projectiles and they just melt, that's no reason to classify the pen manufacturer as a supply chain risk, the product was not altered after the fact.
Of course, there _is_ a difference in "It could do that, but it shouldn't" and "It cannot do that". But it is not that large. That's why I don't see it as that clear cut.
Most of the environmentalists will tell you that it's dumb to shut down nuclear, but building new plants just takes too long and is too expensive. Why then not just put the money into things that are cheap now and will get even cheaper tomorrow?
Hedging against downtime is comparatively easy, just diversify by location and improve the grid, which is way less expensive than building out power plants.
Every source of power has pros and cons. They all have risks and benefits.
If there is a push to do a specific clean energy I think we should go for it regardless of the cost. If you think the climate issue is going to be a very severe issue then you should take every option at our disposal and encourage every push for an alternative to fossil fuels. Since you are refusing this, then I assume you don't think it is severe.
Large countries may be able to hedge against downtime, but smaller countries can't. Also, like I said, we don't really know the impact of all of this which is why we should diversify as much as possible. One of those diversifications should be nuclear as well as solar, wind, and hydro.
Where in comparable countries (= in europe) did new reactors take less than 10 years (from scratch even)? So we are at at least 10 years. But more realistically, taking recent megaprojects into account, its 20 years. In that time, batteries are way ahead and you can overbuild _so_ _much_ renewables and people even do it without subsidies (strangely, nobody builds nuclear plants without subsidies).
regarding the "stable energy" point: germany has one of the most (if not _the_ most) stable grids in the world and that is even with 50+ % renewables. And given it sits in the center of europe with grid connections all around, it's far cheaper to buy from whomever has the most favourable weather anyways (and sell to them if they don't). Thats why one of the biggest issues right now is not nuclear, but grids.
- fully-customizable emojis (think of a RPG-like character customization screen)
- heck, why not full jpegs/gifs?
- some unicode programming script (running Doom)
- ?
That said, some very minor (HN-style) nitpick:
> Otherwise for an n byte code unit this is (5n+1) / 8n, that is 5n+1 content bits out of a total of 8n bits from n bytes. We can rewrite this as (5/8) + 1/(8n) which moderately quickly approaches 5/8 = 62.5%. It is nice that this limit is nonzero and does not depend on n.
Isn't a limit by definition no longer dependent on n?
U+E000–U+F8FF, U+F0000–U+FFFFD, and U+100000–U+10FFFD can already provide you with your own emoji, as that range has been reserved for private use. Extending the range further might make sense if you need even more space in your program, but that's a lot of space already.
2-3 bytes are not much space for anything. Sure, you could use multiple successive ones of these code points and define your own "continuation" encoding in these ranges, but that doesn't seem right to me somehow
That combination is how it already works. You can build combined "characters" (grapheme clusters) from multiple code points, e.g. you could have a "base emoji" followed by a "modifier" emoji, and AFAIK that's how emojis with different skin colors work (one code point for the base emoji (e.g. 'thumbs up'), and a number of skin color modification code points which can be applied to all emojis that involve skin color.
I agree with you that Unicode urgently needs a scripting capability (*), but my plan was to just implement it using invisible tag characters [1] or something like that - but of course allowing a script to be written in a single codepoint is the much more elegant solution.
It also neatly solves the problem of how to write Unicode strings inside scripts inside Unicode strings and also scripts inside Unicode strings inside scripts inside Unicode strings.
Another one: encode instructions on how to draw the glyph into the text itself. The string becomes both the text and the font. Why not make it turing complete and as powerful/complex as TTF.
Imagine someone using the same fully customized emoji multiple times in the same text. Seems like a waste of space. Maybe better to encode just a UUID, and send the image codebook separately.
not only inconsistent over time, but also inconsistently distributed over people. rich people got richer (at least lately) and the less rich didn't get much richer (if at all)
yeah, to me this also pretty much sounds like the approach we started with, we bring our data (as a file) into the application and it stores it back if we want to.
Everything old is new again. We started with timeshare machines (there is only market for 7 computers in the world) where you accessed with VT102 etc terminals.
Then we went to personal computers with local data and code.
Now we are back to a handful of massive timeshare machines (AWS, Azure, ..) that keep your data and let you only access with HTTP/HTML terminals.
Now if people get angry enough with Salas enshittification we'll go back to personal computers again...
In the Bash shell, true is a builtin. It may be a builtin for other POSIX-compliant shells. false is also a builtin.
The key difference is that : is required to be builtin. There are several good reasons for this. For example, syntax: the shell can single out this special character syntactically before searching $PATH.
Also, ":" is a disallowed or problematic character for certain filesystem types. If your shell attempted to omit this builtin, it could not always rely on an external command file by this name.
Lastly, people keep bringing up fish, but it is not a POSIX shell, so its similarities in syntax and operation are coincidental.
reply