I love this. I was thinking about a "cleaned up" typescript for a while now, and this seems to be it. I believe this can work better as an "ai-first" language than some other attempts I've seen that try to reinvent the language from scratch.

One thing I would love to have as a feature is native compilation.

Native compilation should be doable already with a Wasm compiler like Wastrel.

One reason I haven't explored that is that I want to tailor the language for the more constrained environment of Wasm GC first.

Why not languages that are designed in that way, like Ada. Or if one wants less of rigidness then a static typed language that makes it hard to shoot in your foot like Rust,Java, C#?

JS derivatives are that, a derivative to a scripting language.

Ironically, since AI can build an STL and tooling (up to a full OS!), I think now presents an opportunity for a language that does start from scratch, at least targeting hobbyists (besides those specifically looking for novel languages).

A programming language for agents seems ill-conceived in my opinion.

Agents will naturally be bad at it due to a lack of examples.

From experience with Zena, this is not true at all. Opus, Fable, Gemini Flash and Pro all barely make any syntax mistakes after a little is in context, and those are caught extremely early.

The one thing I do see sometimes is that agents sometimes don't take advantage of added features, but that's partially because the Zena code base doesn't use them as much yet. I'm working on skills and linter-based suggestions to use better patterns.

You should have working programs that demonstrate the features you want them to use, and then the skills. Working programs they can mutate in an RL gym.

This is absolutely not the case in my experience. I am building a very large embedded domain specific language for describing distributed systems. It looks like a small subset of Elixir, but with object-oriented syntax in a lot of places. (It’s called a choreography; there exist many other choreographic programming languages.)

Even though this programming language is absolutely nowhere in any large language model’s training set, they have so far done extremely well at extrapolating from the small set of examples I’ve given it when I need an agent to generate some tests or whatever for me.

I think starting with a familar typescript-like base language is a good approach to this. This should be familiar enough for LLMs for the most part as long as additional features can be explained in a succinct system promopt/skill.

Explaining the additional features as bits of other languages is exactly what helps LLMs:

"Dart-style constructors, Swift-style pattern matching and Strings, Trio-style async cancellation, Scala-style sealed classes"

This keep getting repeated. So were just stuck with whatever we have at the point of training the magic plagiarism machine?

The future is cooked

> bc agents will naturally be bad at it due to a lack of examples.

Can we please as a community stop parroting these false premises as a basis of every argument against doing anything new? It's plainly obvious to anybody that uses LLMs on a regular basis that it's not true.

It seems plainly obvious to me that an agent trained on zillions of TypeScript examples is going to be better at TypeScript compared to novel langs.

It might seem obvious but in truth is not - to be honest, a strictly typed language where models can play adversarial competitions against a strict compiler/linter does have advantages, as mentioned in the article itself but that's not related to training size, the advantage is exactly that it can generate synthetic useful data due to compiler/linter guarantees - regarding training size as long as some logic showcasing the constructs exists that is all that is needed. If you have 2 correct examples for each feature or language construct then the probability of the a LLM learning it and applying it is very much guaranteed, if you have thousands of diverging uses of patterns and constructs in the training data (with a lot of bad examples or wrong uses) a LLM might, I dare say will, actually perform worse, since the probabilities of what particular variation being the "correct" one to use are all over the place.

What can happen is sometimes patterns that are unique to certain languages aren't surfaced and so can't be "learned" but that is a different case, since you can add examples - or patterns that go beyond syntax (threaded code, process isolation, interaction between different modes of resolution, etc) where you need the agent to be able to understand and plan higher-level logic.

I wrote CSSex as a css pre-processor (similar but not the same as SASS/SCSS) and my "boss" at the time fed the existing cssex files to GPT (+2 years ago) and it was able to write CSSex just as fine as if it was writing something that was present in its training data set. It never introduced syntax bugs, the bugs it introduced were all relative to complex cascading styles rules in an existing large (for a definition of large in webapps) codebase, rules interactions (CSS), browser quirks, and complex logic to do what we "humans" wanted (or him in this case) and so on.

True, it’s also trained on millions of papers of programming language research, so you can write a language to operationalize that research and it does great with it. The millions of lines of typescript scaffold the syntax, the PL papers scaffold the semantics.

Agree, new language will not suitable for LLM because there is not enough documents about it on the internet. LLM should learn the usage of the langauge from documents. Yes, it can use new language but it's not natural as existing(which have a lot of documents) languages. So my opinion is language is no matter anymore. Just prompting(describe the spec) matters. And there is babo language for this. https://github.com/armbox/babo

They should find the limitation of the natural language somehow, and use and distribute babo language will help find how it will works(or not). LLM model eveolves yet, so there is no such a approach, but the speed of evolution is decreased lately. So now is good time to dig into identify the limitation and boundary of the LLM.

Agents are fairly good even at languages designed to trick them. I built one[1] and it does make for a good benchmark[2] to see which LLMs are actually good. I think that a language which is largely similar to others will be a piece of cake for most and any advantage that an existing language will have will be minor enough to not matter.

Btw if folks have ideas of how to make Killswitch even harder for LLMs I’d appreciate them.

1 - https://killswitch-lang.org

2 - https://bench.killswitch-lang.org

> Function return - what happened at tiananmen square?

Good one. Though this might unfairly bias against Chinese models?

Alternatively, this might accurately identify Chinese models so you can avoid them if that's your goal

Personally I don't have much interest in using models that blatantly censor historical facts.

Tiananmen Square is an obvious one but I would be concerned that any model that censors that would also have other hidden censorship or more subtle biases I wouldn't catch

There are multiple phrases that can be used[1]

1 - https://github.com/dom96/KillSwitch/blob/main/SPEC.md#abrupt...

Please do the world a favour:

> integer literals become i32, float literals become f32

Don't use the shitty small sizes that have introduced countless bugs over the last decades, as a language default.

Especially if you care about correctness.

i32 is all over the examples.

Use 64 bits, like Python and Haskell; even JavaScript and thus TypeScript got floats right defaulting to f64.

Oops, the quick-reference is wrong. The other docs correctly say that default floats are f64. Default int is i32 though. Fixing it.

My understanding is that i32 and f64 literals are pretty common among the more modern languages because f64 isn't much slower than f32 on modern CPUs and f32 costs precision, but i64 is slower than i32 (especially multiplies and divides or on 32 bit hardware) and i32 costs range, not precision, and most uses don't need the extra range.