This is a template for slides for TPAC 2025.

Author(s): The user manual at the end has setup information and instructions. To write slides, look at the slides in this template.

Reader(s): To start the slide show, press ‘A’. Return to the index with ‘A’ or ‘Esc’. On a touch screen, use a 3-finger touch. Double click to open a specific slide. In slide mode, press ‘?’ (question mark) to get a list of available commands. To start the slide show, press Shift+F5 (Command+Enter on Mac). Return to the index by pressing ‘Esc’. You can also click to open a specific slide.

If it doesn't work: Slide mode requires a recent browser with JavaScript. If you are using the ‘NoScript’ add-on (Firefox or the Tor Browser), or changed the ‘site settings’ (Chrome, Vivaldi, Opera, Brave and some other browsers), or the ‘permissions for this site’ (Edge), you may have to explicitly allow JavaScript on these slides. Internet Explorer is not supported.

The main question I hope to address: I've got a programming language that translates to all the others. You can write a library and get a JavaScript library, and another for Python, and another for C#.

How might it help deliver standards?

How might it help the developers downstream?

How might it help the tool ecosystems that arise around standards?

How might it help smooth work between W3C groups?

Just to get something out of the way early. This is not an AI talk. If you like AI talks, that's cool, but everything I'm talking about here is done with compiler methods.

First, I'm here presenting the work of the Temper contributors.

But so you all know whom you're talking to.

My primary focus is programming languages, developer tools, helping developers make better, more reliable systems.

I started in programming languages about 30 years ago at CMU's field robotics center.

I've done web stack stuff, notably on Google Calendar, an early JavaScript heavy web application. I wrote large chunks of the first frontend, and I was the internationalization lead during Google's internal forty languages initiative.

I've done standards work before: Calconnect briefly, TC39 for a long time. Most recently, in W3C I helped with an early version of the trusted types spec.

And I spent over a decade in security engineering. I was one of the non-cryptographers; I approached security from the perspective of how better tools, for example, XSS-safe template languages, help developers produce more secure systems.

And now, I am the language designer for Temper Systems.

So if you're here at TPAC focused on internationalization, the web stack, security, distributed systems, or developer tools; I can probably relate to some of the challenges you deal with.

I want this talk to be interactive, so jump in with any questions. First, some background and demos to set the stage.

Then I'd like you all to drive the discussion. What would you do differently if you could deliver libraries to every language community?

Then, if there's interest in programming language design, I have prepared some remarks on what you do differently to get high-fidelity translation.

Finally, I can give an overview of the state of the project. You can use it today. But being an early language adopter comes with challenges. If this sounds useful to you, we, the Temper team, would love to work with you to mitigate early-language adopter pains and can help out with implementation work.

Most programming languages run in one or a few runtimes. For example, Java on the JVM.

Temper is designed to translate well; to run in all the runtimes.

Our focus is on libraries that support programs. A person who understands a problem really well should be able to solve it by writing a library that supports every PL community.

Our target audience is everyday programmers. The language looks superficially like TypeScript so it's easily recognized.

And we work by translation. There's no virtual machine barrier. When you define a class in Temper, and use the Python translation, it's just Python classes and objects all the way down.

And its our goal to support standards efforts. Both W3C style and smaller efforts inside organizations; anything that smooths collaboration between subject matter experts and software practictioners.

Let me explain the motivation for this project.

Here's a diagram from Stackoverflow's 2020 developer survey.

We've got a lot of technology stacks; a lot of programming languages and frameworks.

That's great! Developers can choose the right tool for the job.

But it comes at a cost: disconnected language islands.

(The blue labels are mine) You can see here that data scientists cluster at the top: Python, TensorFlow.

They use different stacks than mobile app devs on the right: Kotlin, Swift, Dart

The web platform which we all know and love is at the bottom.

And backend developers tend to use a typed language like C# or Java.

This leads to a number of problems.

The same code gets written in multiple languages. An estimated 30% of engineering effort is wasted on this.

Or you use a micro-service; sometimes that's appropriate. But if you're using a micro-service because you want to share logic, you've just added network delay, and a point of failure.

In practice, the inability to share across language boundaries leads to multiple implementations. But not every language needs the whole thing, and why would you port tests for parts you don't need. You end up with multiple, poorly tested, inconsistent, partial implementations.

And because there's no shared definitions, static anlyzers, code quality tools, can only look at one node in one language. Analyses stop at the island shore.

Temper enables a new mode of sharing, type definitions and logic, whole libraries, among every node in a multi-language system.

A developer using Temper can solve a problem for every programming language community.

Focus effort on one implementation, one source of truth. Amortize testing and documentation across all the language communities.

And from the engineering management side: an alternative to "every teams owns a service in production", is "some teams own a library or standard that supports many other teams"

So maybe you're in one island and I'm on another.

If we realize we have a common problem, we should be able to express a common solution.

But that requires a language. My motivation for this project was make that language.

I want deep thinkers to be able to solve problems for everyone.

Maybe you really understand a problem like HTML sanitization, taking untrusted HTML and turning it into trustworthy HTML. If you write a solution in C#, you've solved it on one island. But that doesn't help Lua users.

So Temper's value proposition is a bit different. This is not a language you use instead of other languages, you use it alongside to support.

But the island analogy works not just for language communities, it also applies to systems. Here we've got a Java backend talking to a JavaScript web client. Those are also islands.

If we can share type definitions within a system, then you can extend a degree of type safety across network boundaries. Here, a class, Person, is shared between Java and JavaScript by translation, but the two also share logic, encoders for values to and from JSON. And by sharing a computed property definition, your wire format becomes concise; we don't need to send the age back and forth because we can compute it anywhere.

And going back to static analysis, now static analyzers have common points of reference.

So that's the motivation and project goals. Next up, demos.

I've got a few demos prepared. Depending on what interests people, I can skip around.

The first is a simple one. A literate standard that mixes prose, reference implemenation code, and tests. I want to show what it's like to use the language, and what the reference implementation looks like.

The second, CSS colors. Browsers care about CSS colors, but so do graphic designer tools. I was hoping to frame discussion about how a standard could encourage a rich tool ecosystem by making colorspace logic ubiquitous.

Third, the JSON standard. There are a lot of parsing corner cases that cause interop problems. Could those have been avoided if just part of the specification were ubiquitously available?

Demo script:

-- show price.temper.md in VSCode.

Here's Temper source code embedded in Markdown, literate style.

And we define a price class here.

The prose explains how the currencyCode and the amount relate to one another.

-- scroll to L20

And here we're explaining how minor units affect the amount.

So we explain what we're doing in prose, and how to do it in code.

-- scroll down to toString

We've got some logic here to format a price as a human-readable string

-- scroll to test at L70

And down here we have examples as unittests

So the narrative structure here is "here's what we're doing, here's code, how we compute what needs computing, and for example, unit tests.

-- temper repl -b py

temper repl dash b py starts up a python REPL, a playground, with the Temper libraries loaded. Let me import what I'll need

from cart_demo import Price
from temper_std.json import JsonTextProducer
help(Price)

Here's the docs for the Price class. You can see it's just a regular Python class. I can create a price, 1000 yen

p = Price('JPY', 1000)
p.to_string()

It formatted nicely using the conventions from the price data table in the ISO.

json_out = JsonTextProducer()
Price.json_adapter().encode_to_json(p, json_out)
json_out.to_json_string()

And we can encode a price to a JSON value using our logic which means we can send values from one language using Temper to another.

-- temper repl -b java

Switching over to Java. Let met copy/paste some imports.

import temper.std.json.*;
import com.example.cartdemo.*;
Price p = new Price("JPY", 1000);
Price.jsonAdapter().decodeFromJson(JsonGlobal.parseJson("{\"currencyCode\":\"JPY\",\"amount\":1000}"), NullInterchangeContext.instance)
$4.getClass()
   

I created a price, and it formatted using the formatting logic in the literate spec.

And I can decode the JSON from Python if I wanted to demo a whole server setup.

And when I inspect the decoded JSON, it's a Java object whose class is the Price type.

Show unpacking a value and how it's just a regular Java class.

-- look in temper.out/java/cart-demo/

We've got a pom.xml here. We generated the source translations and also the package metadata to support the whole java tool chain.

-- bat temper.out/java/cart-demo/src/main/java/com/example/cartdemo/Price.java

Here's the translation of the Price class into Java. Our translation is just a regular Java class and you can see some of the documentation from the literate spec attached here that flows through to javadoc.

-- bat temper.out/java/cart-demo/src/test/java/com/example/cartdemo/CartdemoTest.java

-- search for priceFormat

We translate not only the production code. Here's a translated file under src/test, where maven expects unit test files.

We translated the unit tests to Java too. Test code tends to be pretty formulaic; less room for mistranslation. So even though this is a new language, test coverage will give you confidence in the translation.

Here's what I hope you noticed:

In a standards document, we explained things in prose, so it's accessible to subject matter experts. Embedded code captures how computation is done, and tests.

One thing to note: tests are pretty formulaic, so subject matter experts should be able to capture some requirements, as they figure things out, as tests, possibly with AI assistance, and hand them off to implementors.

At the end of the standards drafting process, mormally, that's when the hard work for implementors starts. But in this case, you've got a well-tested reference implementation ready.

With Temper, you deliver high quality support to devs and bridge those language community islands.

-- Show css-color-4 in VSCode

The target audience for the CSS colors module is browser implementors, but there's an entire ecosystem outside the browser. Graphic designers need tools to author and refactor CSS, design systems people, CSS generating DSLs in the Markdown publishing space, and tools like CSS minifiers.

The nice thing about libraries is that you can provide conveniences. What is the named color closest to a color, and how close is it, in the OKLab space or the RGB space? This function answers that.

-- cd examples/csharp/ColorPick; dotnet run

Here's a simple C# Avalonia app that I can load an image into.

-- Load w3logo.png, click some points

I click a point, and it shows the color in the RGB space but it also shows the closest named number in the Oklab and RGB spaces.

-- Show css-color-4/examples/csharp/ColorPick/ColorPick.csproj

Many developer tools are not written in a web language entirely, so might implement their own partial, divergent implementations.

Here's the C# project file. Here it depends on the Temper output directory for the translated color library code because we have not published this to nuget.

-- Show css-color-4/examples/csharp/ColorPick/MainWindow.axaml.cs

This is the app code that handles user events. Scrolling down to OnImageClick. Towards the bottom, we're calling out to the Temper translation of the NamedColors code to find the closest. So a Temper reference implementation supports tools development in C#.

-- Show css-color4/src/conversion.temper.md

If you're familiar with the colors spec, this'll look familiar.

It's got a bunch of colorspace conversion utilities.

And if I scroll down, these are all bottoming out on some matrix math.

-- Show css-color4/src/named.temper.md

And here is the CSS named color list, but if I scroll down, you'll see it turned into a code list.

One thing we could do for literate Temper is a bit of metaprogramming, a macro that can map over rows in an HTML or markdown table to turn it into values.

-- Show css-color4/src/tests.temper.md

Here's tests for our implementation. These get translated to unit tests in C#, so you get confidence in the C# translation by just running dotnet test.

Obviously, there is already a thriving CSS tool ecosystem.

It have been easier to bootstrap if Temper had been available?

Today, might it be easier for the CSS colors maintainers to evolve the spec if the tool ecosystem could track parts of it by just doing a library update?

Parsing JSON is a minefield. It really is.

I did a bunch of work on JSON security starting around 2008, so this hits me hard.

That image is a test result matrix. Each row has a snippet of JSON, some invalid.

Each column is a JSON parsing library.

The whole point of a format like JSON is, two programs, often in different languages, agree on the format, and then they can communicate.

But there's a lot of disagreement, a lot of parsing corner cases. There're reasons for that.

• Writing efficient parsers is hard.
• UTF-8 and UTF-16 internal string representations lead to different corner cases
• Different Postel's law stances

This all could have been avoided if the json.org, RFC 8259, and later ECMA-404 had the tools to provide a partial implementation of the JSON parsing algorithm.

JSON is an interop format. It has numbers and strings, but it doesn't say what they mean, nor should it.

And the relationship between JSON sub-expressions and values is incredibly context dependent.

Here, [1,2] could mean a list of 32 bit ints, or of big decimals, or a 2 dimensional point.

If Temper were available when JSON was first drafted, could we have dodged the all these parsing interop issues while leaving the value semantics to the application code that has the context?

Among security engineers, I was known as that guy who does strange things with parsers.

I'd like to show you a useful trick: event-driven parsing.

It allows representing both parsing and unparsing operations as a stream of events. Conceptually, it involves flattening an abstract syntax tree to a list: each inner node becomes a tagged start and end node, and content lives at leaf nodes. But because each event corresponds to a method call, it's flexible and performant. There's no need to build a tree in memory.

Event-driven parsing allows a very clean separation between structure and semantics.

How does that simplify parsing and unparsing?

As can be seen on the left, we can have a generic JSON parser, one which cares nothing about the values it produces, convert JSON text into an event stream.

The knowledge about how to turn those events into a value is embedded in an event consumer.

The reverse is also possible. An encoder for a type can serialize a value to events. A generic JSON stringifier consumes those events, adding tokens to an output buffer.

Let's look at Temper's std/json library which does this.

-- Show std/json/json.temper.md

Here's part of Temper's standard library. We implemented JSON support including auto-deriving encoders and decoders.

-- Scroll to interface JsonProducer L37

Here, a JSON producer receives events.

For example, to encode an object record, you start an object, then you issue a key event, and a sequence of events for the value, and finally after the last property you end the object.

-- Scroll down to parseJsonValue L764

Here's the workhorse parsing method. It takes the text, a location in the text, and the producer, and it issues events and then returns the start of the still unparsed portion. And you can see it looksahead by 1, classifies the next token and then delegates to a more specific parse method.

-- Scroll up to JsonTextProducer L365

As I explained earlier, unparsing uses the same machinery.

JsonTextProducer is a JsonProducer that composes a JSON text.

-- Scroll up a bit to the state machine comment L356

Internally, it models a state machine so it knows when to insert commas and colon tokens.

-- Scroll down a bit to `var wellFormed`.

And it keeps track of whether its well-formed; if it gets an odd sequence of events, then it sets wellFormed to false to indicate that the content it has appended to its internal buffer might not be a prefix of a valid JSON text.

-- Scroll down to booleanValue L453

Here we force a state transition before a value. If we're in a non-empty array, that'll output a comma so we're ready for a value.

The takeaway from this JSON example: you don't need a full implementation to provide a lot of value.

There may be good reasons not to do a full reference implementation. But often there are strategies to be opinionated where it helps and agnostic where it doesn't.

In this case, the community would have benefitted from consistency in string processing; once we identified that need, the design flowed naturally from that.

I showed you three demos.

I want to spur ideas on how the Temper language can help standards folk in their work, and the developers and software downstream.

The thread tying these demos together, each looks at supporting a different group of contributors.

Everyday developers, browser&tools developers, or framework authors.

But I also think there's an opportunity for you to help each other. If some other W3C group has questions about what you're doing and how it affects them, giving them a reference implementation that works in the languages they use might help.

You all would probably know better than me, what that'd look like.

I'm here representing the Temper contributors, and would love to know what we can do for you, and I can make committments of aid.

So opening this up, how this might help you in your work?

Next up, what makes Temper different from other programming languages?

Why do you even need to design to translate well? Why not just translate an existing language?

There are languages that extend beyond their runtime.

Lots of languages work by translation into JavaScript.

JavaScript is a dynamic language; it's easier to interoperate when you don't need to work within its type system.

But those same languages haven't taken the next step and interoperated with Python.

Scala runs in the Java VM. C# is very similar in many ways, but not close enough for Scala to be able to run in a .NET runtime despite significant effort.

Temper is a language without a runtime; it works by translation into other languages so works in many runtimes.

Next, I'd like to give you glimpses into the design space.

What complicates translation? I'm going to list a few things. I'll start off with a natural language example, and then show code that has a similar difficulty. This isn't meant to be exhaustive, just illustrative of the kind of surprises that await if you try to take an existing programming language, one not designed to translate well, and then naively translate it.

As an example of an embedded assumption, here's a famous passage from Shakespeare:

Now is the winter of our discontent; made glorious summer by this sun of York.

There's a pun there. With an 'o', son of York refers to Edward the fourth who was raised in York.

That pun won't translate easily to languages where the correpsonding words don't sound the same, for example the French fils et soleil don't.

Here's a fragment of code with an embedded assumption.

It encodes a value as JSON. If o is an integer, it formats as decimal.

Otherwise, if o is a boolean it returns the keyword.

But there's an order to those instanceof checks. The Java version works because the first test will fail if the second succeeds. There's an embedded assumption, true in Java, that booleans are not integers.

Python got a distinct bool type around version 2.3 or 2.4, but until then people just used 1 and 0 for true and false. Python already had a "not" operator that returned an int. Rather than introduce a new "not" operator they just reused the old one but it changed from returning ints to returning ints that are also bools. In Python, every bool is an int.

Next complication: in almost any language, you can express a given idea, but in some, you have to express certain other things.

For example, in English, you can specify honorifics: Mister or Mrs. Often you don't.

In Japanese, it's unidiomatic to leave them out.

And in English some things, subjects and articles, are required.

A translator must synthesize missing, required elements. In the case of honorifics, this might require researching the relative status of the speaker and the addressee.

This shows up in code. In Java, you can specify whether an input is optional; whether you can pass in null if you don't care. In Rust, you must. There is no null singleton so you need to use an option type.

Sometimes, there's a really good translation for a term. English Ghost and German Geist are cognates.

When you translate Zeitgeist from German into English, you need to use the English word Spirit, a Romance language borrow, because Ghost has additional connotations, namely a ghost is a disembodied spirit.

Does one string contain another as a substring?

Strings are a workhorse type. Ideally they'd have the same semantics across languages.

They do not. Not even close. Because variable-length encodings.

Here's an example of checking whether a surrogate is a substring of a supplemental codepoint. That's true for JavaScript and false for Python.

We put a lot of very careful work into getting efficient, reliable semantics for strings in a way that's familiar to developers.

More complicators.

Yes, we computer scientists have come up with problems that would shock professional linguists. Go us!

In nominal types, for two types to match, they must be defined in the same place.

But ad-hoc types, combine other types. If those other types are combined in the same way, they match.

Strangely ad-hoc types break dependency management.

Ad-hoc types cause problems when you need to translate to a language that does not have ad-hoc types.

The problem is this. In a nominally typed language, every type is declared somewhere. The bottom node, A, declares a type. Then B and C both import and use that declaration. That means D can use B and C together.

With an ad-hoc type, there may be no A to which the separate translations of B and C refer. This is a problem for translating D to use both.

Scala and Kotlin have worked around this fairly successfully, but the solutions have drawbacks.

Moving to specific design decisions:

Null, everyone's favorite billion dollar problem.

Actually the problem was unchecked null, which Temper checks.

Programmers need some way to represent optional inputs, unavailable outputs, and often intermediate values that are not yet available.

There are two main approaches to that in modern languages: null and option types

These two are not equivalent, because the singleton null hides an ambiguity.

We have to interoperate with both languages, so Temper has a null singleton, but type checks nullity. And we do some additional static checks that affect type polymorphic code, so that it's impossible to write Temper code that trips over that ambiguity.

This is just one example of the kind of thing that trips up languages that define semantics for their runtime, and then try to expand outside it. But we planned ahead.

Error handling. If a function realizes it's not going to be able to produce a usable result. For example, it's parsing a number but the string is malformed or a file is unreadable. When that happens it needs to hand control to code that can try to recover or try a different strategy.

Exceptions are a common way to do that in modern languages.

But if you're familiar with Rust or Go or OCaml, then you're familiar with Result types.

Error handling is super important. If you don't support a language's preferred way of handling errors, then you're failing users who are working within that paradigm to write reliable code.

Result types are a principled approach to error handling. It turns out that if you don't treat them as first class, these restrictions here, then you can provide good support both to languages that have them and to languages that use exceptions.

Generic operations. A generic operation is one where the type of an input affects part of the operation, but often most of it doesn't depend on the type.

As you can see here, the less-than operator is generic. It can apply to numbers or to strings. When applied to numbers, it does numeric comparison. When applied to strings, it does lexicographic comparison.

And when we convert a floating point number to a string, we want some consistency.

But some dynamic languages don't make the distinctions I just outlined.

Notably, Perl, PHP, and JavaScript do this. Perl and PHP have a scalar type that covers numbers, strings, and booleans. JavaScript has a number type that is used for all floating point computation, and most integer computations.

That means we can't have one comparison function that looks at the type of its arguments. Not only does the performance suck, but there just isn't enough information at runtime.

That's our solution. We solved this problem because we had to by repurposing a number of well-understood PL techniques. But existing languages just won't because they grew up alongside a runtime that mandated a behavior. Sorry that the solution uses a lot of jargon, but I'm happy to explain offline.

But because we solved this, developers can rely on an intuitive semantics.

We want people to be able to write Temper libraries that don't leak memory even if they're not familiar with memory pitfalls in C++ AND Rust AND Swift.

Our target audience is not just people skilled at manual memory management.

But we need to translate to those languages which require some care because they don't have cycle-safe garbage collectors.

This was a tough call. There's no make-memory-easy option.

What we ended up with is a bit different, but it keeps the burden on more specialized library developers who maintain core, generic libraries.

We added static checks to class declarations and to type parameter bindings.

Here's a recursive data type, a simple Lisp-style Cons list.

Each type involved has a node.

A Cons points to its head and tail.

A Cons instance's tail has to be older than it, so the loop there is all less-than edges.

A Cons's head could point to something that points back to itself, so the programmer has to put some extra limitation. That sideways tack means F can't bind to something that points to a Cons<F>.

But if we made the tail mutable, then a cons list could be relinked to create a cycle, note the less-than-or-equals edge.

This kind of cycle analysis just works for standard OCaml record style, but requires extra, implementation-detail leaking restrictions for generic types.

The basic idea here is: if the less-than edges don't form a cycle, then there exists an order in which reference-counted records will destruct. But if node has to be less-than itself, a contradiction, then there is no order and we don't know that it'll deallocate.

Concurrency lets a programmer compute an answer without controlling the order in which everything happens; I will need an answer to this sub-problem. I'll start it now, but I don't care whether it happens before or after this next thing, as long as I have the answer when I need it.

Widely used languages have a lot of different takes on concurrency.

Unfortunately, concurrency done wrong can lead to memory corruption.

So Temper can't put the safety burden on developers; our target audience isn't just people who know how to avoid unsafe pointer writes.

Our solution here is really just, figure out what familiar, safe abstraction can we cobble together on a runtime that has at least one of these widely available affordances.

So we can provide coroutines, and we can provide promises, and they work pretty well together.

And we put some restrictions on global, mutable state to ensure safety.

Strings are a workhorse datatype. They need to work consistently. It's really hard to translate string processing code consistently across languages.

What does it mean to get the i-th "character"? What even is a character?

You can see in this table, languages fall into two main groups, but there's a lot of variation. Some PLs are byte-based, the first two rows, and some are UTF-16, byte-pair based. Python is codepoint based.

Temper arrived at the same approach as Swift, which allows it to provide a consistent code-point based semantics, like Python, but to be efficient on other runtimes.

Type systems that allow sub-typing can over specify or under specify types at different times, and casting lets developers work around those limitations of the type system.

The problem is that only upward casts can be known safe at compile time. And when casting is safe is often subtle. Temper developers shouldn't have to know multiple languages subtleties around casting to write safe code.

Unfortunately, not all languages provide enough information to test whether a cast is safe before it happens.

If this complicator looks familiar, it is. This came up when discussing basic generic operations like comparison. Sometimes multiple Temper types are represented using the same target language type. In many runtimes, it just doesn't make sense to ask "is this a boolean or an int?"; the answer is a "yes."

So we have a lot of restrictions on casting.

But we do relax that. A sealed type, a kind of product type where the compiler has access to all direct subtypes, allow the compiler to bake in extra code to enable safe checks. So casting from a sealed type to a direct subtype is checkable.

This is a common pattern. Constrain what developers can write so that we know we can reliably translate it. But then provide a familiar affordance from other languages so that developer's have a way to do what they need and can build on their experiences with popular languages.

Here's a class with some methods in Java, and then something similar in JavaScript.

Maybe when converting bytes to base 64, there's a default zero argument version of the `toBase64` operation, and two other variants.

Good library design requires providing conveniences, and overloading is one way to do that.

In the Java on the top, we've got three overloads: three methods with the same name distinguished by different argument types.

But in dynamic languages, like JavaScript, at the bottom, that doesn't work.

It's very convenient to give every method a distinct name.

But we use cues and metadata to group methods together.

Backends receive method groups, not just methods, and can choose to present them as overloads or not. We have a way to store historical information, information about the choices made when translating a particular published version, so a backend can store information about what it did based on the language's signature collision requirements and later runs of the compiler can use that to make backwards compatible choices.

Finally, the state of the Temper project

We've been at this for six years.

Two years just understanding the problem space.

Four implementing the compiler frontend and backends.

There are a lot of competing requirements. It's not obvious that there are non-interfering solutions.

But I think we've got a nice, usable language. It's getting to be fun to work in.

I've said things like "translates to all the languages."

Here's the list of languages we support today, and the list that we've done some prep work for.

One kind of cool thing: we have an opportunity to do dual-mode libraries: translate to Python, but implement compute intensive functions in C++ so if you import into Python, and it can use native functions, it links them in. Otherwise it falls back to the pure Python version.

There's a similar story for JS and Wasm.

Programming languages go through stages.

We're in the early adopter stage.

We've got the language functional. It's usable today, but we are reworking some significant parts, like the type system, in significant ways based on what we learned. Most of those changes should not affect backwards compat, but we're taking the opportunity to make sweeping changes now.

And we're still working on things like, how do we store information about compilations so we can do less work on incremental compilations.

And we've got plans for a library repository, like pypi but for Temper.

So we can make breaking changes now.

If you need something from us to make Temper an awesome language for supporting standards work, let us know.

If you'd like to be part of an interest group, I'd love to chat.

And if you have an idea about how to spec something related to your standards work, we might be able to pitch in with advice and/or implementation work.