I’ve given a few technical talks in the past, and people seem to enjoy most of them. Sometimes they will tell me stuff like “wow, even though I’m not super technical I could still follow it.” So, having finished writing my talk on security type systems, I thought this would be a great opportunity to talk a little bit about how I approach writing technical talks.

Spoiler: it’s not through a programmer lens. I’m only incidentally a programmer, after all :)

This is exactly how I feel after having finished my talk

Most programming languages need to deal with text in some way or another—and programming languages for writing interactive fiction need to deal a lot with text. The way modern languages do it is to have some sort of String type, which will generally support text encoded using some Unicode format.

But text is deceptively simple. Even if we don’t get into all of the complexities of Unicode and internationalisation (“I just want to count the characters in this text, how hard could that be?”), requirements on how you store and operate on this text can vary wildly depending on the operations and limitations that you have. For example, a contiguously-stored binary is good for displaying text, but terrible for editing it, if you have a text editor. A rope storage is the complete opposite of that. Storing Unicode in UTF-16 is great for implementing operations on a JavaScript string, but it wastes too much memory on small devices like mobile phones.

Because of this, even though we generally talk about “String” as a single type, modern languages will tend to have several of these that embody different trade-offs. This may be exposed to the user (Haskell has at least 5 in the standard library, and you’re supposed to pick the tradeoff that fits your use-case), but it may also just be a runtime detail (JavaScript implementations have one “String” type, but multiple representations covering interning, ropes, slices, and ASCII-only special cases for saving memory).

Crochet has many types of strings as well, and it forces you to pick one of them. The difference here is that Crochet’s types are not about storage, they’re about security.

So, why would you want to differentiate strings for security, even if ultimately they have the exact same storage representation?

I’m often in circles of functional programmers, and one very consistent topic is “how object-oriented programming is the root of all evil, and functional programming is nothing like it”. Not necessarily with those words, but to that effect in any case.

And things tend to take an awkward direction whenever I mention that I like object-oriented programming. “Why?”. It gets worse when I say I’m building one. “No, really, why?”. And then it gets confusing when I throw terms like pure and algebraic effects. “No… wait, WHAT?”

I mean, aren’t “purity” and “algebraic effects” concepts from functional programming anyway? What kind of bullshit am I on? Well, let’s put aside the question and the fact that programming paradigms aren’t even that useful of a concept, and let’s look into Crochet for a moment.

What’s Crochet? But, more importantly, why is Crochet? And how is Crochet?