I was recently roped into a discussion of what programming language should be used on a new backend project. There was quite the struggle there.

Some things they didn’t care about:

• Experience using the language - They believed they’d pick anything up quickly enough.

• Good ecosystem of libraries - As long as some basic things were there, they didn’t mind building the rest. They speculated not much would be necessary.

• Learning curve - Everyone had over 5 years experience and experience in multiple paradigms.

With this stuff not being a requirement, I thought we were setup for a wide range of options. Most of the things on their wishlist also didn’t seem hard to fulfil:

• Garbage collection - They didn’t want to care about memory management.

• Static types with nullability included.

• Quickly go from uncompiled code to up and running (fast compilation and startup)

• Basic IDE support (syntax highlighting and auto complete)

Given they weren’t very demanding on the compilation speed, I thought a bunch of options were still available. But then, the more interesting requirement came in:

• Unit tests in the same file as the tested code - They believe this improves using AI to code.

I can totally relate to this requirement. I’ve felt a lot of joy and been quite productive using AI to write code in my programming language, which does support tests in the same file. But my programming language is not something I can recommend yet and I was also not sure what fits the bill.

I didn’t have anything up my sleeve. After some thinking I arrived at Typescript as maybe the way to go if a new testing framework is created. My curiosity got the best of me and I had to try. They also wanted to use Effect. This is what a hello world endpoint handler file looks like:

import { Effect } from "effect"
import { test } from "../testing/testing";

const handler: () => Effect.Effect<string, Error> = () => {
    return Effect.succeed("hello world");
}

test("hello world", (assert) => {
    const result = Effect.runSync(handler());
    assert.isEqual(result, "hello world");
});

export default handler;

And the funny thing is I didn’t even write that test. I wrote the testing framework (more of a hack than an actual framework, mind you) and AI generated the test for me. I didn’t even write a prompt. It was automatically suggested in the editor.

This was a lot of fun. I wonder what other interesting requirements people have for new projects outside of my bubble.

If you haven’t heard of ADTs, they are similar to enums but apply to types instead. The ADT abbreviation stands for Algebraic Data Type, but I won’t explain that mouthful today.

Rust has this concept but just calls it enum and there’s an example from the standard library in the official documentation:

enum Option<T> {
    None,
    Some(T),
}

It means that whenever you have a variable of type `Option`, it’s guaranteed to be a `None` or a `Some` value. You can’t create other variants elsewhere in the code. If you wish, somewhere where you use it, to break it down into the possible cases, you can rely on the compiler to force you to handle all possibilities. This is usually referred to as exhaustiveness checking.

But this is far from a Rust-specific feature. You can find direct support for it or an equivalently powerful construct in a lot of other programming languages.

The golang codebase where I’ve worked the most lately is a compiler and compilers are a domain where this kind of closed universe domain modelling comes up often.

Even though solutions like go-check-sumtype exist, I’ve settled for a slightly different flavour. Instead of additional tooling, I rely on, or perhaps abuse, language features to achieve it.

Let’s start with a sample Rust enum, taken from Rust by Example:

enum WebEvent {
    PageLoad,
    Paste(String),
    Click { x: i64, y: i64 },
}

And, without further ado, convert it to golang (explanation follows):

type WebEvent interface {
	sealedWebEvent()
	WebEventCases() (*PageLoad, *Paste, *Click)
}

type PageLoad struct{}

func (p *PageLoad) sealedWebEvent() {}
func (p *PageLoad) WebEventCases() (*PageLoad, *Paste, *Click) {
	return p, nil, nil
}

type Paste struct {
	Content string
}

func (p *Paste) sealedWebEvent() {}
func (p *Paste) WebEventCases() (*PageLoad, *Paste, *Click) {
	return nil, p, nil
}

type Click struct {
	X int
	Y int
}

func (c *Click) sealedWebEvent() {}
func (c *Click) WebEventCases() (*PageLoad, *Paste, *Click) {
	return nil, nil, c
}

The non-exported `sealedWebEvent` method makes it so no implementations of the interface can be defined in other packages. This is how you can enforce a closed universe of types implementing the interface.

The `WebEventCases` function is the (fisher-price grade) pattern matching. If any cases are added or removed from the return of the function, golang compiler forces us to update all call-sites where they are used (either by being returned or assigned to variables). The other key feature is that golang compiler doesn’t allow you to have unused variables within a method/function body. This means that as long as you assigned it, you’ll use it.

On top of all of that, if you decide to return within the handling of each case, the compiler will also make sure none are missed.

How all of this looks in practice:

func webEventDescription(webEvent WebEvent) string {
	casePageLoad, casePaste, caseClick := webEvent.WebEventCases()
	if casePageLoad != nil {
		return"page load"
	} else if casePaste != nil {
		return "paste"
	} else if caseClick != nil {
		return "click"
	} else {
		panic("WebEventCases nil")
	}
}

Don’t worry. I wouldn’t call it idiomatic code. No need to bring out the pitchforks. It’s a very handy trick, though.

A parser, conceptually, allows us to convert something into something else, if possible.

Too abstract? Let’s get into examples:

• Parsing a Date from a String

• Parsing a data structure from a JSON

• Parsing a number from a String

If we restrict our input to Strings, we can define our parser type as:

struct Parser<ThingWeWant>(
  parse: (input: String) ~> ThingWeWant | ParseError
)
struct ParseError(message: String)

It’s a structure that contains a `parse` function. The `parse` function allows us to take a String and either get the ThingWeWant or a ParseError, when that’s not possible.

But we don’t have to restrict our input to a String. Some JSON libraries parse the JSON String into a data structure representing the JSON values and then allow you to parse from that data structure into your intended target data structure. For that we need to generalise the parser’s input.

struct Parser<In, T>(
  parse: (input: In) ~> T | ParseError
)
struct ParseError(message: String)

Now we’d be able to write that code.

struct Color(red: Int, green: Int, blue: Int)

jsonParser: Parser<String, Json> = functionYouWouldImportFromALibrary()

colorFromJsonParser: Parser<Json, Color> = functionYouWouldImplement()

colorFromStringParser: Parser<String, Color> = Parser(
  parse = (input: String): Color | ParseError => {
    json: Json ?= jsonParser.parse(input)
    colorFromJsonParser.parse(json)
  }
)

So parsers can be sequentially combined. They are just a function, after all. But that’s not what parser combinators are about. Let’s get into that.

When you’re trying to parse something, there’s often smaller parts you isolate and tackle in order to build it up. For instance, when parsing a date “2025-12-25”, you need to parse a number three times. So perhaps it’s possible to build a parser out of smaller parsers.

For that, we need a slightly more sophisticated notion of a parser. We need to know the remaining of the input, so we can feed it into the next parser.

struct Parser<In, T>(
  parse: (input: In) ~> ParseSuccess<In, T> | ParseError
)
struct ParseSuccess<In, T>(parsed: T, remaining: In)
struct ParseError(message: String)

And now, if we implement a parser for a number and a parser for the dash, all we’re missing is the parser combinators to turn it into a date parser. Assuming they exist, you can do something like:

struct Date(year: Int, month: Int, day: Int)

intParser: Parser<String, Int> = assumeThisIsImplemented()
dashParser: Parser<String, Void> = thisOneIsTrivialToImplement()
emptyStringParser: Parser<String, Void> = alsoTrivialToImplement()

dateParser: Parser<String, Date> = 
  intParser
    ->andThenIgnore(dashParser)
    ->andThen(intParser, (year, month) => {
      Date(year, month, 0)
    })
    ->andThenIgnore(dashParser)
    ->andThen(intParser, (date, day) => {
      Date(date.year, date.month, day)
    })
    ->andThenIgnore(emptyStringParser) /// make sure no remaining chars

The validation is missing for what constitutes a valid month number, for example, but that’s not a lot of work to add.

And this is what parser combinators are all about. Building smaller parsers that are easy to reason about and then combining them into something more complex. Some examples of combinators my library supports:

• `andThen`: Combine two parsers sequentially

• `ignoreAndThen`: Run two parsers but ignore the first result

• `andThenIgnore`: Run two parsers but ignore the second result

• `or`: Try one parser, fall back to another

• `zeroOrMoreTimes`: Parse zero or more occurrences

• `oneOrMoreTimes`: Parse one or more occurrences

• `optional`: Make a parser optional

• `separatedBy`: Parse items separated by a delimiter

You can use these to build more complex parsers, such as a CSV parser or a JSON parser. Break down your problem into really small ones and find the appropriate combinators. You might have fun treating parsers like legos.

The most common case I’ve faced that starts such discussions is communication between a backend web server and the clients (frontend & mobile apps). We need to make changes to the backend that are compatible with the oldest client still in use. And different teams usually arrive at the convention. There’s some sort of agreed-upon specification, in which the rules are as such:

On any value:

• it has a specified type (boolean, string, number, array, object)

  • changing the type is not backwards-compatible

• whether it can be “null” or not is specified

  • changing from nullable to non-null is backwards-compatible

  • changing from non-null to nullable is not backwards-compatible

On a JSON object:

• adding a field is backwards-compatible

• removing a non-null field is not backwards-compatible

• removing a nullable field is not backwards-compatible

On a JSON array:

• every element of an array is of the same type

  • changing the type is not backwards-compatible

• whether the array can contain “null” values is specified

  • changing from nullable to non-null is backwards-compatible

  • changing from non-null to nullable is not backwards-compatible

• adding or removing elements is backwards-compatible

Even if you haven’t explicitly thought about these guidelines, you’ve probably seen them in practice before, even if they’re not exactly what you’re using right now. And even though these rules are wide-spread, automation around it isn’t nearly as popular. We can find tools and standards around the idea of JSON schemas and API contracts, such as OpenAPI and JSON Schema, which have existed for a while. But the idea that those schemas need to evolve is also far from novel. Confluent’s Schema Registry exists to tackle this problem.

The ideas of JSON backwards-compatibility don’t require running systems to reason about. There’s no sequence of instructions. There are schemas, which dictate what values are allowed and there are backwards-compatibility rules. There’s nothing stopping us from building developer tooling around these ideas.

It should be possible to build a JSON library that has the concept of the schema as a first-class citizen. As you would expect of a JSON library, it should allow reading/write JSON (conforming to the schema). But it should also have the capability to:

• read / write the schema onto a text representation

• compare different schemas for compatibility

Having the schema also means we’re able to generate documentation or client code automatically.

Imagine the team workflow we can then empower:

• Every time you make a new backend release, you dump your JSON schema into a file and check it in onto git.

• On the CI for each backend PRs you check that you haven’t broken compatibility with your check-in versions.

• Whenever a client version is no longer in use, the backend can now delete the check-in version files that no longer apply.

Bonus points if the client code is auto-generated from the schema and updating means updating a dependency of their program and can do most of work by updating the lines where the Typescript compiler complains.

Fuelled by all of this dreaming I started a while ago working on my own JSON library for Scala. Scala is a good candidate because JSON libraries already usually have a type that’s separate from the data type. Something like `JsonWriter<T>` and `JsonReader<T>` for any `T` you want to convert to / from JSON. So I just had to conceptually upgrade this type to be a `JsonDescriptor<T>`.

I did mention that none of the ideas here are specific to some programming language. You can build all of this in your language of choice. And so I recently ported the Scala library into tenecs (my programming language). You can find the code here. As a showcase of the functionality, here’s two unit tests:

_ := UnitTest(
  "canRead fails for object with non-optional new field",
  (testkit) => {
    hasExpectedIssue := (issues: List<CompatibilityIssue>): Void => {
      testkit.assert.equal(issues->length(), 1)
    }
    newSchema := JsonObject(<JsonObjectField>[
      JsonObjectField("field1", JsonBoolean()),
      JsonObjectField("field2", JsonBoolean())
    ])
    oldSchema := JsonObject(<JsonObjectField>[
      JsonObjectField("field1", JsonBoolean())
    ])
    hasExpectedIssue(newSchema->canRead(oldSchema))
  }
)

_ := UnitTest(
  "canRead object with missing field as optional",
  (testkit) => {
    noExpectedIssues := (issues: List<CompatibilityIssue>): Void => {
      testkit.assert.equal(issues, <CompatibilityIssue>[])
    }
    newSchema := JsonObject(<JsonObjectField>[
      JsonObjectField("field1", JsonBoolean()),
      JsonObjectField("field2", JsonOneOf(<JsonSchema>[JsonBoolean(), JsonNull()]))
    ])
    oldSchema := JsonObject(<JsonObjectField>[
      JsonObjectField("field1", JsonBoolean())
    ])
    noExpectedIssues(newSchema->canRead(oldSchema))
  }
)

The library also supports enums (specific string values), which have their own compatibility rules with strings. What I have on my radar to dive into at some point:

• Generating documentation

• Supporting regex

• Generating client code

But that’s enough of thinking about JSON for today.

• “One-shotting”: getting from zero work done to having the whole thing you wanted to accomplish completed after a single prompt.

• “Vibe-coding”: interfacing with AI as the means of creating and iterating on a programming project and never interacting with the source code directly.

And in the same way you can find a proof-of-concept game created in the 30 minutes that is now a multiplayer game or even funding for vibe-coders, there’s an equal or greater amount of people reporting that AI feels useless to them. A lot of them feel like they are getting gaslit. It all looks like marketing-geared demos with no applicability in the real world of professional software engineering.

At some point I became increasingly intrigued by the discrepancy in experiences and thought it was time to give it a go and start using AI. And I had enough success from the get go to keep me going and believe it’s a very useful tool. So if you’re looking to get started with AI, I have two pieces of advice.

Advice #1: Treat it as a new skill

It took you some time to learn to write code the way you do right now. You’re probably still honing your craft. And you know your way to do things is far from the only way. You’ve met other practitioners that have ways of working so different to yours that it’s almost a miracle that you’re able to collaborate. It’s a bit of a similar problem when it comes to AI. Your old dog needs to learn new tricks. Poke it with curiosity about what will happen.

Advice #2: Set yourself up for being rewarded

There’s a lot of demos of apps being created from scratch with AI. And for good reason. AI is easier to use in new projects or small projects than otherwise. Start small. You can, for instance, start a new library in a programming language you’re not an expert in. Or you can take something as small as a single simple function alongside unit tests and ask chatgpt to write a similar one. Increase the complexity as your results get better. Play with how you’re asking the questions and the existing code that you’re feeding it. Build up an intuition as you see increasing success. And ride that joy.

As I’m not aspiring to be an inspirational guru, let’s get practical. I attempted to one-shot a syntax highlighting plugin for VS Code for my programming language, called tenecs. I’ve never built a VS Code plugin. I’m not even an avid VS Code user. I’ll report it in the present tense, as it is a transcription of my notes as I went through the process. You can skip to the end to see where I ended up if you don’t want to tag along on the ride.

Let’s start by feeding it a sample file of a parser combinators library I started building (gist) as I think it has a good coverage over the language syntax. I’ll use the prompt: “This is a file of a new programming language I made, called tenecs. Please create a vscode syntax highlighting plugin.”. It suggested some files that I need to create and some steps to follow to create the plugin project. Looking at the files I can see some issues:

• Wrong file extension. It should be “.10x” rather than “.tenecs”.

• Support for single-quote syntax, that the language doesn’t have.

• The pattern for number literals does not include the potential minus at the start, used for negative numbers.

• The list of keywords contains a bunch of keywords the language doesn’t have.

Clearly a failed first attempt. I do happen to have a grammar definition I can give as context. Let’s try giving it just the grammar and the prompt “This is the grammar of a new programming language I made, called tenecs. The file extension is “.10x”. Please create a vscode syntax highlighting plugin.” Looking at the output of this prompt I don’t quickly find any problems except that it missed the syntax for block comments. It is only supporting single-line comments. This made me realise that I don’t have the definitions for comments on the grammar I provided. So it speculated correctly, to some extent. There’s probably other problems there I haven’t spotted yet.

For my next attempt I’ll provide the grammar again but the prompt is “This is the grammar of a new programming language I made, called tenecs. Besides that grammar, there is syntax for line comments and block comments. The file extension is “.10x”. Please create a vscode syntax highlighting plugin.”. I don’t even state what the syntax is, as it is the most commonly used by other languages.

Now that I couldn’t find issues with the generated files (but they probably exist), when I tried to follow the suggested steps to create the plugin I’m starting to run into problems. Apparently it didn’t generate an entry-point for the vscode plugin and therefore the recommended tool to package the plugin fails. So my next attempt will be the same prompt, but followed by “Don’t forget to create the index.js file.“.

It went in a completely different direction. Bunch of problems:

• There’s no “index.js” file.

• It’s missing some language constructs it had correctly done before.

• It suggests very different steps and those don’t include the same plugin packaging tool.

I’ve clearly hit a barrier here of what I can easily get it to do. Time to switch the approach. Instead of asking it to make the whole plugin for me, I’ll follow the official Syntax Highlighting Guide, because after that all I really need is the content for two files that describe a language and those it has already generated. I’ll repeat the previous prompt and attempt to just use those two files.

And we have a working plugin! I’m using a theme I wouldn’t normally use to code but that seems nice to quickly spot syntax highlighting issues. The syntax highlighting isn’t quite right, though:

• A declaration should have “:” and “=” as the same color.

• “~>” is part of a type definition.

Let’s try to fix those two things with a new prompt: “This is the grammar of a new programming language I made, called tenecs. Besides that grammar, there is syntax for line comments and block comments. Please create a vscode syntax highlighting plugin. Make sure the "<", ">", "|" and "~>" are part of the type but all other symbols are bundled together.”

It really seems to have focused on bundling all symbols together and things are overall a bit worse. Perhaps if we remove that part of the prompt and go with “This is the grammar of a new programming language I made, called tenecs. Besides that grammar, there is syntax for line comments and block comments. Please create a vscode syntax highlighting plugin. Make sure the "<", ">", "|" and "~>" are part of the type”.

And it’s still far from the goal. Perhaps listing the symbols is not the way to go. Let’s try “This is the grammar of a new programming language I made, called tenecs. Besides that grammar, there is syntax for line comments and block comments. Please create a vscode syntax highlighting plugin. Make sure the function types and sum types share the same highlight”

Now it’s gotten close. But “:=”, “:?” and “=>” definitely shouldn’t be be half-highlighted. Let’s go with “This is the grammar of a new programming language I made, called tenecs. Besides that grammar, there is syntax for line comments and block comments. Please create a vscode syntax highlighting plugin. Make sure the function types and sum types share the same highlight. Make sure => and :? and := are highlighted.”

Now we fixed that problem but “~>” is no longer highlighted. Let’s go with “This is the grammar of a new programming language I made, called tenecs. Besides that grammar, there is syntax for line comments and block comments. Please create a vscode syntax highlighting plugin. Make sure | and ~> and => and :? and := are highlighted.”

I’m going to consider this one a success. It’s a working plugin. It has questionable taste in the details but that’s what the human touch is for. The last sentence of my prompt where I specify some symbols is for sure not something I would do on a first prompt right now, but that goes to show that either the work needs to be iterative and/or there’s a lot of intuition for me to build up.

To have an example we can compare over different languages, let’s say you have two functions you want to put together. The scenario would be you’re building some service where ads are shown to free tier users but not premium users. You have “getSubscriptionByUserId”, which gives you the type of subscription a user has. You also have “shouldPlayAdvertisement”, which tells you whether to play the advertisement given the subscription type. Now you have to have “shouldPlayAdvertisementToUser”.

Example in javascript:

function getSubscriptionByUserId(userId) {
  throw new Error('failed to connect to database');
}

function shouldPlayAdvertisement(subscriptionType) {
  return subscriptionType != 'premium';
}

function shouldPlayAdvertisementToUser(userId) {
  const subscription = getSubscriptionByUserId(userId);
  return shouldPlayAdvertisement(subscription);
}

Since errors are thrown, in the “shouldPlayAdvertisementToUser” function you can only read the happy path. You don’t know which of the functions invoked might fail.

In wanted to take a nearly opposite approach with tenecs. I didn’t want some short-circuiting that’s invisible at any point in the code. Something more similar to golang, which uses early returns.

Example in golang:

func getSubscriptionByUserId(userId string) (string, error) {
	return "", errors.New("failed to connect to database")
}

func shouldPlayAdvertisement(subscriptionType string) bool {
	return subscriptionType != "premium"
}

func shouldPlayAdvertisementToUser(userId string) (bool, error) {
	subscription, err := getSubscriptionByUserId(userId)
	if err != nil {
		return false, err
	}
	return shouldPlayAdvertisement(subscription), nil
}

Example in tenecs:

getSubscriptionByUserId := (userId: String): String | Error => {
  Error("failed to connect to database")
}

shouldPlayAdvertisement := (subscriptionType: String): Boolean => {
  not(subscriptionType->eq("premium"))
}

shouldPlayAdvertisementToUser := (userId: String): Boolean | Error => {
  when getSubscriptionByUserId(userId) {
    is err: Error => {
      err
    }
    is userId: String => {
      shouldPlayAdvertisement(userId)
    }
  }
}

Now we have something very explicit, but due to the lack of early returns, it came with a cost. Nesting. Code with lots of errors will be super nested. It’s a big loss in readability. Wouldn’t want to be the next iteration of the hadouken meme (source):

This is probably not a problem you’ve ever faced because all major languages have solutions for it. I’ve mentioned throwing and early returns but there’s another solution worth looking into. Languages that have some sort of “Result” type, that encapsulates the possibility of success or failure, have some additional syntax. We usually call this “syntactic sugar”, because it reads nicer, but is redundant syntax, as it doesn’t enable something new. It’s still not exactly the same, as in tenecs you return directly something like “Boolean | Error” instead of a “Result” type, but it might get us closer.

Scala has for comprehensions, probably inspired by Haskell’s similar solution. It doesn’t fully get rid of the nesting, but you can have only one level of nesting even when calling multiple functions that might error.

Example in Scala:

def getSubscriptionByUserId(userId: String): Try[String] = {
  Failure(new RuntimeException("failed to connect to database"))
}

def shouldPlayAdvertisement(subscriptionType: String): Boolean = {
  subscriptionType != "premium"
}

def shouldPlayAdvertisementToUser(userId: String): Try[Boolean] = {
  for {
    subscription <- getSubscriptionByUserId(userId)
  } yield shouldPlayAdvertisement(subscription)
}

Gleam has a quite clever solution to this problem. You can use their use keyword to turn the rest of your function into a lambda parameter.

Example in Gleam:

fn get_subscription_by_user_id(user_id: String) -> Result(String, String) {
  Error("failed to connect to database")
}

fn should_play_advertisement(subscription_type: String) -> Bool {
  subscription_type != "premium"
}

fn should_play_advertisement_to_user(user_id: String) -> Result(Bool, String) {
  use subscription <- result.map(get_subscription_by_user_id(user_id))
  should_play_advertisement(subscription)
}

Rust has a different way of addressing this by using their “?” operator to short-circuit on the error case.

Example in Rust:

fn get_subscription_by_user_id(user_id: &str) -> Result<String, String> {
    Err("failed to connect to database".to_string())
}

fn should_play_advertisement(subscription_type: &str) -> bool {
    subscription_type != "premium"
}

fn should_play_advertisement_to_user(user_id: &str) -> Result<bool, String> {
    let subscription = get_subscription_by_user_id(user_id)?;
    Ok(should_play_advertisement(&subscription))
}

So Rust seems to be really close to something I could use. Since I don’t have a Result type and don’t want to constrain the short-circuiting to a specific Error type, I’ll have to make the user annotate either the type to be returned or the type to use. Inspired by Gleam, I’ll handle this on the left-hand side of variable declaration. Let’s start with an example having both.

Example in tenecs:

shouldPlayAdvertisementToUser := (userId: String): Boolean | Error => {
  userId: String ? Error = getSubscriptionByUserId(userId)
  shouldPlayAdvertisement(userId)
}

Now I can decide to omit one of the types and let the compiler infer it.

Example in tenecs with variable type inferred:

shouldPlayAdvertisementToUser := (userId: String): Boolean | Error => {
  userId :? Error = getSubscriptionByUserId(userId)
  shouldPlayAdvertisement(userId)
}

Example in tenecs with returned short-circuit type inferred:

shouldPlayAdvertisementToUser := (userId: String): Boolean | Error => {
  userId: String ?= getSubscriptionByUserId(userId)
  shouldPlayAdvertisement(userId)
}

It definitely doesn’t feel like a silver bullet. It doesn’t allow chaining of expressions. It doesn’t feel familiar to people coming from any language whatsoever. So I’m not sure if I arrived at a jumbled version or a greatest hits remix, but it seems to be very effective at what it’s supposed to do. So far when writing tenecs code I’m trying to reach for it on every opportunity. Time will tell if I keep growing fond of it or learn to dislike it.

At some point I read somewhere, either in a tweet or blog post (can’t find the source right now), that your product being marginally better doesn’t beat the inertia people have against switching over. Your product needs to be ten times better.

And so I thought… What does it take for a programming language to be ten times better?

That thought propelled the work on the programming language I later named “tenecs”. The name is a word play on “10 x”, where the “x” means mathematical “times”. The file extension is “.10x”.

I didn’t necessarily have an answer for what ten times better could look like, but I thought it started with testing. I have professionally written way more web service backend code than anything else, so that’s where my focus started. Not discarding the idea of it being a general purpose programming language, but it’s easier for me to identify the pain points and potential improvements in that area.

Whenever I’m changing existing code, to fix a bug or add a new functionality, it’s way more pleasant and productive when I can easily change and/or add new tests related to the change and be confident I’m done with it. The “being done with it” is fuzzier topic to attempt to tackle, but making it easy to add and/or change tests is something that I think could be tackled.

So my first idea was: why do I write unit tests at all? If I have a function that I can unit test, I could have a command that goes through code and gives me unit tests for each code path. In order for the function to be unit testable I realised I can have forcefully deterministic unit tests by making sure side-effecting functions always come from arguments. So, knowing it can be built, came the question: would these generated tests be good? Would I want to keep them? Maybe they give me an accurate overview of how the system behaves technically but are too detached from what the system is meant to achieve? I tried exploring this idea without building a prototype by talking with some people I consider to be very smart and have vast experience on this topic, but we didn’t come to much of a conclusion. Would have to build to see.

I started working on it. Let me give you a concrete example of my early efforts, taken out of a unit test of the test generator:

package example_package

import tenecs.test.UnitTest

// the function we feed to the test generator
logPrefix := (isError: Boolean): String => {
  if isError {
    "[error]"
  } else {
    "[info]"
  }
}

//
// The output of the test generator: two tests
//

// 1. Test named "[error]", that checks that output
_ := UnitTest("[error]", (testkit) => {
  result := logPrefix(true)

  expected := "[error]"
  testkit.assert.equal(result, expected)
})

// 2. Test named "[info]", that checks that output
_ := UnitTest("[info]", (testkit) => {
  result := logPrefix(false)

  expected := "[info]"
  testkit.assert.equal(result, expected)
})

In the process of building this I kept thinking about the potential of tooling enabled by the constraint of having side-effecting functions always come from arguments. So, even though I have built some stuff in the original testing direction, I am now investing on building the language also with other tools in mind.

I don’t want to turn this post into a list of everything I’d like to achieve, and the test generator is definitely still on the list, but I’ll let you the testing idea that currently excites me the most.

Test generation out of a trace

Generating tests out of the implementation won’t necessarily produce realistic test scenarios. But what if we could record real code runs and turn them into tests? You can’t have more realistic than that. We could have a tracing tool, somewhat like jaegar or honeycomb, but with a button that turns a trace into a unit test. With this tool I’m imagining you could:

• Take an error out of production and as soon as you find it on the tracing tool, you can have a unit test that reproduces it.

• Have another person (maybe QA or PO) do some business-oriented testing and you can take those to be unit test cases you want to maintain.

• As soon as you finish writing your new feature and run the code to check that it behaves as intended, you can press the button to get that exact scenario as a unit test. Easier than having to write the code for that yourself afterwards.

I still have a lot of work to do on this hobby project, but hopefully after reading this you’re also a bit excited by the idea or at least understand my excitement around it.

I decided that in my programming language, currently named “tenecs” (more on that some other day), I don’t want to have things that shortcircuit the call stack. What I mean is I don’t want to have the control flow that is usually enabled by keywords such as “panic” in Golang or “throw” in Java, Javascript and many others.

If you can’t throw, how should division by zero work?

Mathematically it’s not defined. So it shouldn’t be a supported operation. But I don’t have a non-zero integer type. Division is defined over the `Int` type the same way `plus` and `times` are.

What do we do when a function can technically take a value as input that is not a valid input? In a language where errors aren’t thrown, the error is returned. But in the case of division, maybe it will feel clunky and unnecessary? When doing math operations in programming we expect to be able to chain them and not have to deal with intermediate error handling.

Gladly, I’m definitely not the first one to stumble upon this problem!

The Pony programming language had a similar problem and has a section on their tutorial dedicated to Divide by Zero:

In Pony, integer division by zero results in zero

Inspired by their approach, I decided to support both normal “div” and “ponyDiv”:

package example

import tenecs.error.Error
import tenecs.list.fold
import tenecs.list.length
import tenecs.int.div
import tenecs.int.ponyDiv
import tenecs.int.sum

// Average that returns an error when you pass an empty List<Int>
avg := (values: List<Int>): Int | Error => {
  val total = fold(values, 0, (acc, elem) => { acc + elem })
  div(total, length(values))
}

// Average that returns zero when you pass an empty List<Int>
ponyAvg := (values: List<Int>): Int => {
  val total = fold(values, 0, (acc, elem) => { acc + elem })
  ponyDiv(total, length(values))
}

If you prefer reading code with pipe syntax, the language supports it using “->”. Here’s the same code using that syntax:

package example

import tenecs.error.Error
import tenecs.list.fold
import tenecs.list.length
import tenecs.int.div
import tenecs.int.ponyDiv
import tenecs.int.sum

// Average that returns an error when you pass an empty List<Int>
avg := (values: List<Int>): Int | Error => {
  val total = values->fold(0, (acc, elem) => { acc + elem })
  total->div(values->length())
}

// Average that returns zero when you pass an empty List<Int>
ponyAvg := (values: List<Int>): Int => {
  val total = values->fold(0, (acc, elem) => { acc + elem })
  total->ponyDiv(values->length())
}

Given either div or ponyDiv it's possible for users to implement the other, so I might drop one of them at some point. But for now, users have the choice.

You have to talk.

Talk.

Talk. Talk. Talk.

If you improve on that axis, you might increase your chances of a successful interview.

By talking you give the interviewer a chance to see how you think.

By talking you give the interviewer a chance to help you.

By talking you give the interviewer a chance to talk with you.

So how do we turn you into a radio star? Ready to talk non-stop but also ready to be interrupted with questions, without stopping the show. Talking about your thoughts is definitely a different skill from having them in the first place.

If you were making a presentation about a train of thought, you would probably not structure it the way it actually happened. You would change the narrative such that it tells a story, because stories are engaging.

But in a live setting you don't have the luxury of going through things and later turning it into a story. So we have to do the other way around. You adapt your way of thinking to let the story unfold.

The story of your interview is how it goes from zero to the challenge solved, with a nice conversation had along the way. This will feel more natural once we lay out the story arc:

1. The problem is presented

2. Understand the problem and the relevant concerns

3. Decide on the approach to tackle the problem

4. Start solving

1. The problem is presented

The interviewer will tell / show you what the problem is about or present you with a problem statement for you to read. Pay attention to what they are saying. Interrupt with questions when you are two steps behind. Otherwise, let them continue.

When a problem is presented, a lot of times it goes like “and Blob is made out of Foo”, when they have explained Blob but not Foo. Give the interviewer a chance to explain Foo before you jump in asking what it is. Allow yourself to be one step behind. If you are two steps behind, then you are at risk of losing the train. Interrupt then.

You can phrase your question like: “I’m sorry, can we please take a step back? I’m not sure if I fully understood Foo.” Then repeat in your own words what you understood about it. That will help the interviewer help you.

2. Understand the problem and the relevant concerns

At this stage you’ve been given the goal of the game you’re about to play, but not the rules of the game. You should clarify the scope of concerns to take into account.

Example questions:

• Do I need to think of concurrency?

• Is storage part of the scope of the problem

• Is the API meant to be optimised for read or write?

A couple of questions to test the waters should help you get closer to the mental model of the interviewer.

3. Decide on the approach to tackle the problem

If you had the goal of helping a fellow developer tackle a task, it’s likely that before letting that person write code you would think of the easiest way to tackle the problem. Do the same thing here, double checking with the interviewer.

Example questions:

• The existing tests seem to be in increasing order of complexity. I’ll turn them from red to green, going top to bottom. Is that ok?

• There seem to be specific concerns we should have when the API is designed. Could I start from there?

4. Start solving

At this point you’ve set the stage for what’s happening next. You are now ready to take the first step and start talking through the code you are writing. You have all of the context you previously built, ready to be leveraged in the conversation. It’s okay to not literally talk and write at the same time. You can talk between lines of code. You can also write code comments with notes to come back to. It’s easier to talk while writing a comment, because you’re writing in plain English, so you can say the sentence as you write.

Follow the steps you created for yourself and unfold your narrative into your happy ever after.

Bonus tip:

You can practice by yourself by writing code while talking about what you are doing. This helps you get into the headspace of narrating as you go.

Interviews are hard. Good luck out there!

How do I tell my team that the project I've been working on has become so complex I no longer want to deliver it? I think it would actually be detrimental to the codebase.

What popped in my mind was: this looks like accidental complexity. That’s something that can be tackled. If you haven’t heard “essential” vs “accidental” complexity before, I bring you a brief explanation.

Essential complexity is the complexity of the problem you are solving. Any solution you deliver cannot be less complex than that complexity, as the solution can’t be less complex than the problem itself. Otherwise, the problem is not fully addressed.

Accidental complexity is the complexity you add to your solution, while building it. There's always some of it. Usually there’s a fair share of it. And also, not so rarely, there’s a ton of it.

So my actual answer to my friend, after explaining “essential” vs “accidental” complexity was:

It sounds like you landed on something that has a lot of accidental complexity, which is common, when you're solving a problem for the first time without having good examples or experience on it.

So now the question is how much would the team like to invest on bringing it down.

You can tell them you have something, but it feels a bit overblown for the problem it is solving, as you were exploring and adapting as you were figuring things out. If someone would pair with you, where you explain the code and both of you work together on making it clean, you would probably arrive at something maintainable. Because as it stands, it's a bit rough

That gives the team an option to double down or back down.

When working with some code in some IDE, something I see developers do frequently, is to write some variable name, press “.” and then see what auto-complete suggests. I do it myself as well. This is a big deal in exploring what once can do with a variable of some type.

I also like the end result. Out of the following two examples I prefer the first one:

var1.concat(var2)

concat(var1, var2)

The problem in most languages is that you can only do the first one when `concat` is defined in the same place as the type for `var1`. There’s two approaches for enabling this feature:

• Extensions, like Kotlin and Scala have

• Piping, like rescript and Gleam have

Extensions don’t allow the reader of the code to know if it’s an extension or not without checking the definition and/or imports. I think I would prefer something that acts more like syntactic sugar.

The other approach seems fine. And while I don’t like to read `var1|>concat(var2)` (with a space it becomes better), I do like `var1->concat(var2)`.

So I can just adopt what rescript has, right? If a user of my language wants to see what functions take the type of `var1` as an argument, they can write `var1->` and let the IDE do its magic! And if they want to look at the fields, they use “.” instead of “->”.

Problem solved?

Unfortunately not yet.

In order to add new syntax, it needs to match what is already there. Let me show you some example code, so you get an idea of the existing syntax:

import tenecs.list.map

struct Todo(
  title: String,
  done: Boolean
)

struct TodoFilter(
  predicateFunction: (Todo) -> Boolean
)

exampleFunctionUsingFilter := (): Void => {
  todoList := [](
    Todo("finish blog post", false),
    Todo("publish blog post", false)
  )

  filterThatRejectsAll := TodoFilter((todo) => false)

  emptyList := map(todoList, filterThatRejectsAll.predicateFunction)
}

You can see in that example that `->` is being used to declare a function type. I searched for another symbol that would also work, so I don’t have to mess with existing syntax, but haven’t found anything as satisfying as `->`. So, if I want to use that, then I need another symbol for the functions. I can use `=>`. But I was using that as part of the syntax for declaring a function. And that one I can drop without replacement, if I no longer allow defining single-expression functions without the brackets around them.

Let’s try those changes:

import tenecs.list.map

struct Todo(
  title: String,
  done: Boolean
)

struct TodoFilter(
  predicateFunction: (Todo) => Boolean // changed -> to =>
)

exampleFunctionUsingFilter := (): Void { // dropped =>
  todoList := [](
    Todo("finish blog post", false),
    Todo("publish blog post", false)
  )

  filterThatRejectsAll := TodoFilter((todo) { false }) // dropped =>

  emptyList := map(todoList, filterThatRejectsAll.predicateFunction)
}

And, for completeness’ sake, let’s apply our new syntactic sugar:

import tenecs.list.map

struct Todo(
  title: String,
  done: Boolean
)

struct TodoFilter(
  predicateFunction: (Todo) => Boolean
)

exampleFunctionUsingFilter := (): Void {
  todoList := [](
    Todo("finish blog post", false),
    Todo("publish blog post", false)
  )

  filterThatRejectsAll := TodoFilter((todo) { false })

  // doesn't look too bad, I think?
  emptyList := todoList->filterThatRejectsAll.predicateFunction()
}

I’m nearly happy. I don’t mind too much that we lost the `=>` on exampleFunctionUsingFilter` but on `filterThatRejectsAll`… There I’m not a fan at all. It’s missing something. I might end up having to introduce a third, weirder arrow, like `+>` or `~>` to not have ambiguity there.

I suspect there’s a best case scenario here that I just haven’t yet puzzled together. I’ll think about it some more.

• a refactor that nobody asked for but others liked

• a bug fix for a bug that wasn’t reported

• an improvement to a test suite

Assume this change took half a day.

Are you happy or upset with it? Is that a good or a bad thing? Did the developer go rogue or showcase initiative?

I think the answer lies in the perceived momentum of your team. If it’s perceived that there’s no time to waste (low momentum), such time spent feels misaligned with the absolute most critical mission important goals. And that is upsetting. If it’s perceived that the team is a powerhouse of delivering the goods, then improvements are great, as they are aligned with preserving what makes the team so good.

It’s important for you to know where your team sits and adapt to it. If you hear “we don’t fix things just because we can” you should avoid taking initiative by yourself. Initiatives require synchronisation and prioritisation, because time is of the essence. That might feel like a waste of time to you, but you have to consider that you taking actions that are perceived as you going rogue means people will perceive you as less reliable. It’s a net negative overall.

Team momentum is a hell of a drug and makes a lot of actions that seem bad become suddenly welcome. People are suddenly less concerned if you are running slightly in the wrong direction, because direction is in such an environment easy to correct. It’s much easier to correct course than it is to get things going.

So, does your team have momentum? And are you acting accordingly?

I’ve mostly been on the camp that it’s not. I think mostly because it felt different to me. But quite a few times I had a hard time putting my finger on why. It’s still writing code. It still has goals of what that code is meant to support / achieve. Even if when doing open source those goals are quite different, when doing closed source library they overlap more.

So is it different?

It still feels different to me.

Why, though?

The most fundamental difference that I have in mind right now is how other developers will interact with the code that I write.

When I write library code, I expect most of the interaction with my code to be done using the APIs and mostly treating the internals as a blackbox. They’re there for you to dive into, but you’ll avoid it unless really necessary.

When I write application code, I expect most of the interaction with my code will be trying to read it, in order to iterate on it or debug it. Instead of shying away from reading and understanding it, you’ll take the default stance of using it for gathering context related to what you’re trying to achieve.

But then again, I still write my code to achieve its purpose and taking into account the preferences of those working with me. So the distinction might just be in my head and not quite real. Go figure.

In TrAgIc, there is only one recurring meeting with a fixed schedule: the retrospective.

There is also only one recurring meeting without a fixed schedule: feature introduction.

How did it work at all? With one golden rule:

Whenever you are doing some work, you make sure you empower whoever comes after you to also get their job done. When in doubt, go talk to people.

Let’s go a bit more concrete on how a feature might go:

1. Product Owner presents it at the feature introduction meeting. This includes a document describing things from a user point of view, that people can refer back to. Frontend and backend team ask questions and create tickets on the issue tracker of choice, which dependencies between them.

2. Backend dev picks up backend ticket. Things are implemented in a backwards compatible manner, so backend will have a code review and be merged before any frontend work starts. As part of doing the ticket, they also provide all the required documentation such that the frontend dev can do their work.

3. Frontend dev picks up frontend ticket. Code is reviewed and merged.

4. Product owner tests the feature.

5. At some point, product owner thinks there are enough new features to make a production release and asks someone to do so.

This all looks really simple and radically optimistic, but I have seen it work first-hand. As long as the golden rule is respected. Because if you look at each of those points, a long of things can go outside of the happy path. And you’re responsible for communicating so. Some examples might also help here:

1. Feature introduction meeting

   • After questions from the devs, Product Owner realises they need to re-work the feature. There will be later in time another Feature introduction meeting for the same feature.

   • Backend devs believe they should discuss how the new feature should be approached, because it impacts the architecture. They schedule a meeting to do so. Somebody is appointed to prepare and run that meeting.

   • Frontend devs notice that the feature is not testable unless some non-user-facing work is done is done in the backend. It goes into the backend ticket(s) to do that work.

2. Backend work

   • Backend dev is not sure what would be the correct API changes to make frontend implementation easier. They go talk to one or more frontend devs.

3. Frontend work

   • The documentation provided by backend was insufficient for the feature implementation. They request for what is missing to be added.

4. Testing

   • Found a bug but not sure if it’s a backend or frontend issue? Get a developer to look at it with you and help determine the root cause.

At any stage: is this same problem happening a lot of times? Discuss it in the retrospective meeting!

Does this mean this way of working is purely a feature factory without time for refactors? It might surprise you, but it does not. If it’s a small refactor, you just do it. If it’s a bigger one, you discuss with others how to tackle it and create the tickets. Because refactors are a part of normal work and you trust people to be reasonable about their split between feature work and other necessary work, things will be picked up accordingly. And if you think the current split is unbalanced?

I hope you guessed it by now…

You talk to people!

Fuelled by that distaste, comes today's post where I give you tips that I think improve the developer experience when working with ids.

#1: prefix the entity type

Ever had an id in front of you and you weren't necessarily sure which database table it belonged to? That won't happen anymore if you prefix them. If user ids start with “user_” and profile ids with “profile_” you’ll thank yourself over and over again in the future.

#2: use a time-sorteable string

It's not meaningful most of the time, but you can have a time-sorteable string without centralizarion or delegating it to the database. You can use ksuid or uuid v7. For any of them, if you sort the strings, you also get them time-ordered.

#3: let the type-system help you

If you are using a statically typed language, then you can have different types (classes, interfaces, etc) for different ids. Then your functions receive and return `UserId` and the compiler complains if you try to give it a `CatId`. It's not bulletproof but most of these errors happen at the layers with business logic and not the ones concerning serialization.

If the boilerplate of creating a bunch of types bothers you there's always the option of creating a single generic one, `EntityId<T>`. Then your functions use `EntityId<User>` or `EntityId<Cat>`. It achieves the same type-safety.

Obviously we’re not creating new systems all the time and migrations can be painful, but hopefully you have a chance of using one of these in the future and save yourself some precious debugging time.

import java.util.concurrent.atomic.AtomicReference

func main() {
  val foo: AtomicReference<Int> = AtomicReference(42)
  foo.set(null) // it compiles!!!
  println("The answer is " + foo.get().toDouble())
}

Credit to Uberto Barbini for the code snippet and tweet illustrating this problem.

So what’s happening here? Shouldn’t the Kotlin type system prevent this issue?

As soon as you interact with Java code, null restrictions don't have the same rules. We can see that if we wrap the Java class in Kotlin, we won’t have the same issue.

import java.util.concurrent.atomic.AtomicReference

class MyAtomicReference<T>(initialValue: T) {
    private val javaAtomicRef = AtomicReference(initialValue)

    fun get(): T = javaAtomicRef.get()
    fun set(newValue: T) = javaAtomicRef.set(newValue)
}

val foo: MyAtomicReference<Int> = MyAtomicReference(42)

foo.set(null) // does not compile!!!
println("The answer is " + foo.get().toDouble())

Why do we face this problem in the first place? In Java everything can be null, but why do we need that to bleed over?

The first problem is that Kotlin can’t know if a value coming from Java code can be null. If we assume that all of them can be null then you’d be forced to deal with that possibility on cases where it doesn’t happen and it’d be annoying.

Can we assume the opposite, that no values coming from Java are null? We can, because Kotlin won’t stop you from doing null-checks or anything else you would do to safeguard your code.

But do we really have to face this problem when a Java class / interface has a generic? Come on, there we get to specify if we want a `String` or a `String?`…

Unfortunately that doesn’t work for all cases.

Let’s go over a concrete Java interface I just made up:

import java.util.function.Predicate

interface Filtered<T> {
    void set(T t); // T should never be null
    void filter(Predicate<T> f);
    T get() // T can be null
}

If I instantiated that interface with `String?` as `T`, then I can pass null to the `set` function, which is a lie.

If I instantiated that interface with `String` as `T`, then we’re thinking that what is returned from `get` is never null, which is also a lie.

No way to be honest this time! Because we lack information to do so.

So the language designers stuck with the ones that give the user the most flexibility.

In any case make sure to browse the official Kotlin documentation. It tends to be pretty good.

And my final advice to you is:

• wrap Java code

• make sure it’s properly tested

Hopefully that allows avoiding those nasty NullPointerExceptions in production.

As part of my building my own programming language, I’ve been thinking about what it would take to achieve this dream. The compiler can determine what code changed and what tests depend on that code, in order to invalidate the cache. The missing piece to make it safe for unit tests is to make them forcefully deterministic. But we don’t have the same luxury for integration tests. If I use a database and upgrade the database version, the compiler of my programming language has no way of knowing that the tests related to that integration should run again.

The Go programming language suffers from this exact problem. There’s no (automatic; without programmer intervention/discipline) way to distinguish between tests that rely on outside state and ones that don’t. So, while there is test caching, most people I know professionally working with the language always run all of their tests. They don’t leverage the cache at all.

So what would it take to cache integration test results and not think it’s eroding software quality? As you might’ve guessed, I don’t have a silver bullet. But if we look at the individual problems, we might get somewhere.

Problem 1: depending on external systems

Your code might be exactly the same, but system you’re integrating with has changed. The example above of updating database version falls into this category. A similar problem, which is way more common and way more likely to break your tests, is changing your database schema.

How about we add those in a configuration file?

[integration.dependencies]
postgres = "16.0"
latest_db_update_file_name = "321.up.sql"

Then we could have specific tests depend on specific dependencies and the programming language test runner would check the version on the file against the version the tests used. We could have special CLI commands to set the version, to make it easy to use.

This dependency on configuration might require some discipline and/or CI work, but it might easy to use enough that it becomes enjoyable to use.

But what about when a vendor updates their software? Well, if a third party service you depend on, that you’re integrating through calls to a REST API, makes changes to their production system… Integration tests wouldn’t save you there. But we can always keep a date for the version and re-run all the relevant tests.

[integration.dependencies]
last_known_stripe_api_update = "2024-05-03"

Not perfect. But, perhaps, good enough?

Problem 2: a test might be flaky

This is a bit more tricky to have a holistic view of. Why is the test flaky? Is it because test order matters? Is it because two tests running concurrently interfere with each other? Is it because it waits for something with a timeout and the timeout is seldom enough?

I think we definitely need control over concurrency. Some integrations have flows that only work if a certain action is preceded by another action. We can only guarantee that if we’re not running other tests that might interfere with that. So, like the dependency versions, we need another sort of tag, that has a concurrency limit, and have the test runner know how to handle it.

[integration.concurrency]
message_queue_push_and_pull = 1

That covers the concurrency scenario, but much more can be happening. We don’t want to run all of the tests all of the time, but maybe we can add some randomness here and run some? We could add a couple of mechanisms, leaving their configuration to the language user:

• Pick 1/X tests and invalidate their cached result

• Pick 1/X tests to be ran twice in the same test run

[integration.run]
randomly_invalidate = 2
randomly_run_twice_one_in = 100

With this example configuration, on every test run:

• two tests would have their previously cached results invalidated (thus re-ran)

• there’s a 1% chance that a test runs twice during a test run

A bit of chaos helps everyone to sleep better at night.

When these mechanisms are actually in use then I’ll probably come across things that don’t feel as good in practice as one hoped and obviously iterate from there. As of today, this sounds good enough to me for an MVP. Tomorrow I might have changed my mind.

We’ll consider a unit test any test which does not interact with anything outside of the program. Reading a file? Forbidden. Writing to the console? Not allowed. No changes can be observed by running it.

It’d be unproductive to talk about testing without providing examples. Since the ideas I want to talk about are not specific to my language, we can imagine I’m building a new Typescript runtime, for the sake of the examples.

Hello world!

import { console } from "imaginary-standard-library";

function main() {
  console.log("Hello world!")
}

The example above assumes a couple of rules are in place:

• There’s no implicitly available global variables. We need to import `console`.

• When running a program, the runtime looks for the function named “main” and starts there.

Because we love tidy code, we’re going to move the business logic of our application into a separate function.

import { console } from "imaginary-standard-library";

function main() {
  greet()
}

function greet() {
  console.log("Hello world!")
}

Now we want to create a test for our business logic. Let’s introduce more rules to our imaginary runtime:

• Tests are all functions whose name starts with “test_”.

• Tests can be in any file. They can be in the same file as the functions being tested.

That should be enough to add our test:

import { console } from "imaginary-standard-library";

function main() {
  greet()
}

function greet() {
  console.log("Hello world!")
}

function test_greet() {
  greet()
}

Our test doesn’t test anything, besides the fact that function doesn’t crash! 😱

Even if it was testable, we haven’t introduced assertions yet. Because we don’t want `assert` being used outside of test code, it’ll be introduced within a function parameter, which we’ll call testkit.

import { console } from "imaginary-standard-library";
import { TestKit } from "imaginary-standard-library/test";

function main() {
  greet()
}

function greet() {
  console.log("Hello world!")
}

function test_greet(testkit: TestKit) {
  greet()
  testkit.assert.equals(true, true)
}

Now let’s get back to making our code testable. In order to do so, we need to introduce some interface to abstract away the console.

interface Console {
  log(input: string): void;
}

Now we can make our function testable:

import { console } from "imaginary-standard-library";
import { TestKit } from "imaginary-standard-library/test";

interface Console {
  log(input: string): void;
}

function main() {
  greet({ log: console.log })
}

function greet(console: Console) {
  console.log("Hello world!")
}

function test_greet(testkit: TestKit) {
  let fakeStdOut: String[] = []
  let fakeConsole = {
    log(input: String) {
      fakeStdOut.push(input)
    }
  }
  greet(fakeConsole)
  testkit.assert.equals(["Hello world!"], fakeStdOut)
}

We’ve achieved our goal of having our function testable. All it took was having interactions with the outside world abstracted in an interface. This is a pattern that can be used in nearly any programming language.

The success of this is still hinging on your discipline, of not having any outside world interactions being directly used. But we could enforce that responsibility, if it’s up to the runtime to pass it as a function parameter to main. So we move all of the functionality to interact with the outside world into an OutsideWorld instance and remove the ability to import things like console directly.

import { OutsideWorld, Console } from "imaginary-standard-library";
import { TestKit } from "imaginary-standard-library/test";

function main(outsideWorld: OutsideWorld) {
  greet(outsideWorld.console)
}

function greet(console: Console) {
  console.log("Hello world!")
}

function test_greet(testkit: TestKit) {
  let fakeStdOut: String[] = []
  let fakeConsole = {
    log(input: String) {
      fakeStdOut.push(input)
    }
  }
  greet(fakeConsole)
  testkit.assert.equals(["Hello world!"], fakeStdOut)
}

Now that the only place where the OutsideWorld instance comes from is the main function argument, we can no longer pass it to tests. This means all tests no longer have the ability to do anything related to the outside world.

As long as the programming language author keeps all of the functions that can interact with the outside world in the OutsideWorld instance, no discipline is required from the programmer anymore.

Until concurrency primitives are introduced, the tests are deterministic. Forcefully so. By design. That means I can reliably cache the test results and users of my language only run the relevant tests when code changes.

As a side-note, it would be annoying to write the fake instances all the time. I provide a fake OutsideWorld instance in the tests alongside other functions to make most things easy to test.

You have a few (or a lot of) colleagues, but only one boss.

You’ll keep a range of relationships. Some of them will be good. You can keep the bad ones at bay by leveraging group dynamics.

The relationship with your peers feels more quid-pro-quo.

Today I have your back, tomorrow you have my back.

Your boss has no incentive to be a great boss.

When you’re frustrated that your boss is bad, you most likely are not putting yourself enough in their shoes. From their position, how should they behave?

What are they evaluated / promoted on? Certainly not your good relationship.

They don’t need to have your back. You need to not be a problem for them.

They don’t have resources to tangibly reward your good performance.

If you would replace your boss with a robot that acts purely on incentives, do you think the robot would be a good boss? Probably not. Then, why do you expect your boss to be different? Human behaviour is heavily influenced by incentives.

So you either have to be lucky to be in an organization that has wildly different incentives or your boss has to go against their incentives to be stellar, from your point of view. It’s a rare find.

“You don't need an ORM. Just write SQL.”

VS

“You still need the code that goes around the SQL. You’re just building your own ORM.”

I think the debate comes from people not having the same mental model of what an ORM is. ORM stands for “Object Relational Mapper”.

Let’s look at a snippet in a made-up language:

class Person(id: Int, name: String)

let person = new Person(-1,“Mr Reader”)

person.save()

Now let's compare that to another snippet, writing SQL in the same made-up language:

sql.query(“INSERT INTO person (name) VALUES ($)").args(“Mr Reader”).run()

You can think of the two snippets as similar. They are definitely in the same category, in the sense that they are addressing the same problem.

If we come back to the “Object Relational Mapping”, none of them do it. A “mapping” would imply a conversion between the two worlds and you have both sides of it. And none of the two snippets do that, do they?

In the ORM snippet you don't have the sql side of things. What's the query that runs under the hood? When is it run? Are queries running in the order I write them? I wish this last question was a joke, but I have worked with an ORM that reordered queries sometimes if you didn't forceFlush. So it tries to hide the database from you.

In the SQL snippet there's no mapping. It's up to you to take the values and put them onto the SQL. If you add a new field to your class, you won't have the compiler telling you you’re missing an argument to your query. You don't have more type-safety than in the other snippet.

So next time you engage in a debate or ORM vs no ORM, you can now be aware of what the other side is valuing.

A middle ground are query builders, that just provide a DSL for building SQL queries and code to help do the mapping. Some of them make people from both sides less annoyed and they can finally work together to bring world peace.