Harrison Goldstein

My New Favorite Mocktail

2024-09-16T00:00:00+00:00

Here's a quick post, just sharing a mocktail that I'm workshopping.¹

Recipe

2 oz. Lapsang souchong, brewed strong (around 1/2 as much water as normal)
3 oz. Ginger beer (I like Fever Tree)
1/2 oz. Rose vinegar

Add the ingredients to a high-ball glass with ice and stir. Garnish with candied ginger if you have it.

Explanation

My favorite cocktail is the Penicillin, and while this mocktail ends up pretty far away from that starting point, it does hit some of the same ginger-and-whiskey notes.

Lapsang souchong has become popular as a non-alcoholic replacement for Scotch for good reason---it's smokiness really does scratch the same itch, especially in a cocktail with other interesting things going on.

Ginger beer adds sweetness and... ginger. I could have done a more "spirit forward" mocktail with a ginger syrup (as one would in a Pennicilin), but I think mocktails like that go by too quickly. The ginger beer lets me make a longer drink that I don't finish in 5 minutes.

The rose vinegar is, admittedly, where things get a bit weird. I like it because it has a bit more bite than another acid like lemon juice would, which is helpful in a mocktail. Plus, the rose flavor adds an extra little bit of excitement. Of course, I don't expect you have rose vinegar around (and I won't for long either, I got mine at Noma and I don't think I'll be able to get more). I think lemon juice would be a perfectly reasonable option instead, but personally when I finish my rose vinegar I'm going to experiment a bit with other vinegars first. I'll update this post if I find anything interesting.

I don't claim that this is particularly original, I've had drinks like it at restaurants. I'm just documenting my experiments making it myself.

Appearance on Disseminate

2024-07-08T00:00:00+00:00

I had a lovely conversation with Dr. Jack Waudby on the Disseminate podcast. We talked about Property-Based Testing in Practice and PBT in general. You can find the episode here or wherever you listen to podcasts.

Don't Give a No-Op Talk

2024-04-22T00:00:00+00:00

I've noticed a common failure mode among academic conference keynotes and other large audience talks that I've started calling a "no-op" talk.¹ These talks are often delivered well and have reasonably good structure, but they misunderstand their audience in an important way. A no-op talk is unconvincing for your skeptics and boring for your allies.

So how do you know if you're giving a no-op talk? The classic form goes something like this:

Center your talk around a controversial opinion.
Recognize that you have allies in the audience, and spend most of your talk trying to inform them rather than persuade skeptics.
Recognize that you have skeptics in the audience, and simplify your informative points so that the skeptics can understand them.

Did you see what happened? In point (2) you decided to alienate your skeptics, but then in point (3) you decided to bore your allies. The resulting talk doesn't really work for anyone.

By way of example, consider a talk arguing that dogs are better than cats. If the speaker starts "we all know that playing fetch is the greatest joy in the world" — alienating many cat lovers — but then continues with shallow discussion of well-known dog breeds — boring the dog lovers — that's a no-op talk.²

When writing an opinionated talk, you need to carefully consider your goals. Are you trying to sway the skeptics? In that case, start from first principles and speak to their values. When taking this approach, don't forget to be humble and to honestly engage with the arguments against your stance; this will make the audience more likely to trust you. You can do this in a way that is useful for your allies as well — presenting a really clear and convincing argument for your point gives your allies ammunition to argue that point in the future.

On the other hand, you may say f*** the skeptics, I want to make my point without concessions. In that case, just write the talk for your allies. Make points that they'll find interesting and surprising, and make them in enough detail to show real depth. This may be confusing for those who disagree with you, but, if you do it right, the skeptics in the room may find that your opinion has more technical merit than they had expected. They'll be confused, but they may be compelled to clarify that confusion later, rather than simply dismissing your opinion as shallow and unfounded (as they would with a no-op talk).

I know that giving talks is really difficult, and giving good talks is even harder. Academic researchers are not trained orators, and it's totally understandable that not all large talks will land. But I think that being a bit more mindful about our audiences and how our talks might impact them is a great first step towards better academic communication.

Named after "no-op" computer instructions, which have no effect.

For a programming languages audience, a more specialized version: consider a talk arguing that all software should be proved correct. If the speaker starts "we all know that correctness is the most important thing in software engineering" — alienating many — but then continues with shallow discussion of the available tools for proving code correct — boring the true believers — that's a no-op talk.

Victor Basili Postdoctoral Fellowship

2024-02-18T00:00:00+00:00

I'm excited to announce that starting in Fall 2024 I will be working with Leonidas Lampropoulos at the University of Maryland as a Victor Basili Postdoctoral Fellow. With Leo's guidance I will continue to explore themes from my PhD work on property-based testing, leveraging tools from programming languages and human-computer interaction to improve the state of software testing.

I can't wait to see what great opportunities for collaboration pop up over the next two years, and I am honored to have been awarded this fellowship.

I was on TheForkJoin!

2023-07-29T00:00:00+00:00

Last week I had the pleasure of being a guest on TheForkJoin. I chatted with Rachit Nigam and Oliver Flatt about my computer science journey, my research, property-based testing in general.

You can watch the video here:

I'm also uploading a few YouTube Shorts with short clips and follow-ups from the conversation, on my YouTube channel.

Introducing Tourist

2019-04-14T00:00:00+00:00

I've been spending a lot of time lately working on a project that I'm really excited about. With the help of my roommate Jason, I've been working on an application Tourist. It's goal is to empower developers with an interesting new way of writing documentation.

The project page says,

Tourist is a new approach to documentation that allows programmers to explain low-level technical details of a system while simultaneously providing the context of how those details fit into the broader architecture. It lets programmers document code in the same way that they would explain it in person: by walking the consumer step-by-step through the important parts of a codebase.

That's really all Tourist is -- a tool (currently an extension for Visual Studio Code) that allows programmers to guide virtual "tours" of their code. Rather than writing technical documentation in a wiki or other format that is totally external to the code, Tourist lets you associate documentation with specific locations in the code, and then makes it easy to view that documentation in the appropriate context.

What is a tour?

A tour is a series of code locations (a particular line in a particular file) along with a markdown description of why that location is significant. The locations (or "stops") can be in different files and even in different git repositories.¹

Tourist provides a simple interface for building and viewing tours. The GIF below shows what it's like to view a tour in Visual Studio Code.

When you click on a tour stop, your editor jumps to the appropriate file and line, and the stop's markdown content is rendered in a "web-view".

Adding tour stops is as easy as viewing them. Once you have a tour file created, you can simply right click in a file and ask tourist to add a stop at that location. From there you can edit the stop content, move the stop around, and reorder stops as needed.

(This demo is fairly simple, and the first version of the extension is planned to stay that way. That being said, we have lots of cool ideas for how the extension can be made more powerful in the future, and we welcome suggestions.)

Why is this exciting?

As I mentioned before, long-form external documentation like wiki pages is disconnected from the code that it documents. A technical report can explain a lot about class X or function Y, but you have to do your own legwork to actually connect that information to the logic involved. In addition, it is really easy to forget to maintain the documentation as the code changes. If class X becomes class Z you need to change that in your documentation too, and that documentation generally fairly far-removed from the place that you made the change.

Inline comments have a different issue: context. When you read inline comments, you're generally only reading to understand a particular line or set of lines. Maybe a docstring on a module or function gives you sligtly more context, but the main goal is still to explain the code that's written right here. When inline comments to try to explain broader context, it can start to get hard to read the actual code. Tourist's idea of documentation that is connected to a code location but not written inline is an attractive solution to this problem.

Of course, both inline comments and long-form documentation are important, and Tourist doesn't necessarily intend to replace either. Long-form documentation is still crucial for less technical documentation like user manuals, as well as for more external techncial things like release notes. Inline comments provide important insight into the nitty-gritty details of an algorithm. Code tours bridge the gap between these worlds, rounding out a project's documentation by addressing the interaction between high-level architectural concerns and low-level information about the code itself.

What can I use it for?

This technology is still really new, and we expect that people will come up with all sorts of interesting ways to use it. That being said, here are a few things that I think tours are really good for:

Onboarding. Getting started with a new codebase is always a challenge, and it's often really helpful to have someone who already knows the code walk you through the important parts. Tourist provides a low-cost, repeatable method of knowledge transfer. This is especially powerful when someone is leaving a company or project and needs a quick way to write down as much knowledge as possible. Someone can come along later and pick up the project as if the old maintainer was still there.
Low-level demos. When demoing a new feature or code-path to other programmers, it is often helpful to show how data flows through the new code. A code tour that hits each important branch point in turn makes it really easy to see the impact of the change.
Library overviews. Automatically generated documentation isn't always enough information for someone to use a library effectively. Library writers can use Tourist to put use-case code snippets alongside the actual code that is being called in the snippets.

If you have other ideas, reach out and let me know! I'm really excited to see what we can do with this framework.

How can I get it?

Tourist is in extremely early alpha, so you'll need to build everything yourself. First and foremost, you'll need tourist from hgoldstein95/tourist, and unless you're going to write your own editor extension, you'll want tourist-vscode at hgoldstein95/tourist-vscode. Getting tourist set up should be fairly straightforward -- the README should have enough information. Once that's built, you can run

npm install

from tourist-vscode and start the extension with the debugger.

If you're trying to get tourist up and running on your machine, feel free to send me an email or create an issue on either of the above repositories. I'm happy to help anyone who wants to help us keep moving tourist forward.

Watch this blog for more about tourist! As we move towards a feature-complete launch, I'll keep this page updated, and I'll probably post again with news and information.

As of now, Tourist requires that all of the code you reference is versioned using git. In the future we hope to add support for subversion and mercurial, but git is universal enough that we think this is the right place to start.

Brown Butter Chocolate Chip Cookies

2019-02-24T00:00:00+00:00

I know all two of you who read this blog are here for my computer science content, but who doesn't like chocolate chip cookies??

TL;DR: Jump to the recipe or jump to the super short, condensed recipe.

The Setup

I've been cooking and baking since I was little. My parents are both great cooks with adventurous tastes, so I grew up eating tons of good food and learning how to make it. One of the earliest things I remember baking are the classic, back-of-the-chocolate-chip-bag recipe Toll House cookies. They'd always come out a little differently; sometimes they were soft and chewy, sometimes crispy and crunchy. We used butter or margerine, just depending on what we had around. We didn't know how or why the recipe worked, and we didn't really care -- the cookies were perfect anyway.

... well, the cookies were really good. The problem is, some batches were a little better than others. I always liked them chewy, but sometimes they'd come out crispy. Eventually we figured out that cookies made with butter were softer than the ones made with margerine; that helped, but there was still so much variability in the finished product that I began to get frustrated. By the time I was baking these cookies in college, I started to feel like they had lost some of their charm.

A New Approach

One evening, a trail of YouTube recommendations led me to no fewer than four high-quality videos chocolate chip cookie recipes. Call it a stroke of luck or just the algorithm at work, but all of a sudden I had all of the resources I needed to fix my cookie problem. Here's what I watched (and I highly recommend you do too):

The recipes in these videos were similar to the one from my childhood, but there were two important differences. First, these recipes were a little more advanced. Each one added some interesting new flavors and/or procedures that aimed to elevate the otherwise simple cookies. Second, many of these videos talked through the food science behind their choices of ingredients and processes. This was a huge improvement from the recipe on the chocolate chip bag -- the extra context made it much easier to diagnose problems, explain differences in batches, and experiement with modifications.

I got to work on my own recipe. I took my favorite ideas from each, and ended up with something that I'm pretty excited about. Full disclosure, this recipe is pretty darn close to the Cook's Illustrated recipe from the America's Test Kitchen video, but I worked in a few ingredient recommendations from the Tasty one. The other two videos provided fewer direct ideas, but Babish and Stella were awesome inspiration anyway.

At this point you probably just want the recipe, so here you go.

The Recipe

Dry Ingredients

5 oz All Purpose Flour
3.8 oz Bread Flour

The Tasty recipe recommended bread flour for added chewiness. The ratio I tried was just a guess, and in the end the cookies might have been a little bit too chewy. I'd consider shifting a little more towards the AP flour next time, but I definitely like the idea of at least some bread flour.

0.5 tsp Baking Soda
1.25 c Chocolate Chips

I used normal semi-sweet chips this time, and I think it turned out really well. Next time I'll see what difference chopped up baking chocolate makes.

Wet Ingredients

1.75 stick Butter
3.5 oz Granulated Sugar
5.3 oz Light Brown Sugar

Most of the recipes called for dark brown sugar, but I don't tend to keep it around. If I remember to buy some I might try the dark brown sugar, or I might just try adding a teaspoon of molasses.

1 XL Egg
1 XL Egg Yolk

The standard Toll House recipe uses two eggs, but the America's Test Kitchen video said that removing the second egg white actually makes the cookies more moist. I believe it.

1 tsp Instant Espresso Powder

This is another addition from the Tasty recipe. Coffee is great with chocolate, and I'm a caffeine addict, so why not?

2 tsp Vanilla Extract

Prepare dough:

Brown 1 stick of butter in a stainless steel saucepan. Heat and stir/swirl pan until the foaming stops and the milk solids begin to brown. Remove from heat.

Browned butter is magic. Three out of the four videos recommend it, and there's a good reason why. You can tell the difference instantly. The batter smells and tastes like toffee. I'll never make this recipe with normal butter again. Keep an eye on the butter while you're browning it, it burns pretty easily.

Add the remaining 0.75 stick of butter to the pan and allow the butter to melt together. Cool slighly.
Combine wet ingredients in a bowl and stir for 30 seconds or so, until everything is combined and no lumps of brown sugar remain.
Wait 3 minutes, then stir for another 30 seconds. Repeat three times, until mixture is smooth and glossy.

This process comes from the Cook's Illustrated recipe, and the idea is to dissolve the sugar without adding too much air. I definitely think it made a difference in the consistency of the dough.

Combine dry ingredients in a bowl and stir to combine.
Add the dry ingredients into the wet. This can be done fairly easily in one installment, folding with a spatula. Do not over-mix.

Adding the chocolate to the flour and folding by hand ensures that you won't overwork the dough. It also makes the dough super easy to make without a stand mixer.

Chill the dough for 15-30 minutes.
Turn the dough out onto a piece of wax or parchment paper, shape into a rough rectangle, and cut into 16 equal pieces. Shape the pieces into balls.

This is really the only innovation that I came up with myself. Chocolate chip cookie recipes always give instructions for scooping the cookies, but I've found that scooping can lead to poor chocolate chip distribution. No one wants the sad cookie that you scooped at the end with only two chocolate chips left. Cutting the dough into pieces makes it easier to get consistent cookies with consistent chocolate. If you hit a chocolate chip with the kife, just cut right through.

Refrigerate for up to 3 days (potentially longer?).

I need to see how long these keep before they're baked. Babish claims that the batter actually keeps getting better for a few days, but I haven't done the tests myself. I also want to know if you can freeze the dough balls -- I bet you can.

When ready to bake:

Preheat oven to 375F.
While the oven is preheating, let cookie dough come to room temperature.
Place dough balls onto parchment paper and flatten slightly. Top with coarse sea salt if desired.

You should desire. The salt makes a huge difference. Don't flatten the cookies too much, but they do need a little help spreading out.

Bake for 12 minutes, or until the cookies are browned on the edges and not completely set in the middle.

They'll finish cooking on the tray. Or maybe they won't. Cookie dough is amazing.

Let cool on the sheet for 5 minutes, and then move to a wire rack to cool completely.

You're not going to let them cool completely.

The Results

The cookies are pretty amazing, if I do say so myself. They're moist, chewy, crispy at the edges, not too sweet, and basically everything else positive that people have said about a chocolate chip cookie. I claim very little credit for the recipe, but I am fairly excited about my idea to ditch the scoop or spoon and just cut the cookies into the right size. Overall I'm mostly just happy because I'm going to be able to make these cookies for any and all cookie-appropriate occasions.

Here's the recipe one more time without my interruptions...

Brown Butter Chocolate Chip Cookies

Dry Ingredients

5 oz All Purpose Flour
3.8 oz Bread Flour
0.5 tsp Baking Soda
1.25 c Chocolate Chips / Chunks

Wet Ingredients

1.75 stick Butter
3.5 oz Granulated Sugar
5.3 oz Light Brown Sugar
1 XL Egg
1 XL Egg Yolk
1 tsp Instant Espresso Powder
2 tsp Vanilla Extract

Prepare dough:

Brown 1 stick of butter in a stainless steel saucepan. Heat and stir/swirl pan until the foaming stops and the milk solids begin to brown. Remove from heat.
Add the remaining 0.75 stick of butter to the pan and allow the butter to melt together. Cool slighly.
Combine wet ingredients in a bowl and stir for 30 seconds or so, until everything is combined and no lumps of brown sugar remain.
Wait 3 minutes, then stir for another 30 seconds. Repeat three times, until mixture is smooth and glossy.
Combine dry ingredients in a bowl and stir to combine.
Add the dry ingredients into the wet. This can be done fairly easily in one installment, folding with a spatula. Do not over-mix.
Chill the dough for 30 minutes.
Turn the dough out onto a piece of wax or parchment paper, shape into a rough rectangle, and cut into 16 equal pieces. Shape the pieces into balls.
Refrigerate for up to 3 days (potentially longer?).

When ready to bake:

Preheat oven to 375F.
While the oven is preheating, let cookie dough come to room temperature.
Place dough balls onto parchment paper and flatten slightly. Top with coarse sea salt if desired.
Bake for 12 minutes, or until the cookies are browned on the edges and not completely set in the middle.
Let cool on the sheet for 5 minutes, and then move to a wire rack to cool.

The (Regular) Language of Dance

2018-04-02T00:00:00+00:00

Over the last month or so, I've gotten really into swing dancing. It's a new and exciting challenge for me---I'm not the most coordinated person, and dancing is a unique kind of social interaction. For the most part, this has taken me well out of my comfort zone. Luckily, as is often the case with learning new things, I've found ways to relate these new ideas to things I already know. In particular, I realized that if you reeeally squint, swing dancing looks kind of like a regular language.

Crash Course in Swing Dancing

The dance that I've been learning is usually called East Coast Swing. It's a really fun social dance that is set to quick swing music.

The basic East Coast Swing step is a six-count pattern---depending on the tempo of the music, the pattern is either "rock step, triple step, triple step" or "rock step, step, step". Often, dancers will also incorporate elements of Lindy Hop, a very closely related dance, which uses the eight-count pattern "rock step, triple step, step, step, triple step". The latter is what's happening in the gif above.

Of course, there's a lot more to dancing than footwork. In swing, partners dance in a number of different holds and positions, and there are also tons of different moves that make the dance fun and interesting. I highly recommend checking out some YouTube videos of people dancing to get an idea of what I mean.

A Dancing Machine

When I started learning different swing moves, I realized that each move was sort of a "transition" from one "state" to another. For example, the partners might be dancing in closed position and the lead might use a "tuck-turn" to transition to open position. More subtly, a left-side pass from open position might leave the couple back in open position, but with the leader's hand on top of the follow's hand (normal open position has the leader's hands under the follow's).

As a computer scientist, when I hear "states" and "transitions" I immediately think of finite automata. A finite automaton is a mathematical structure that is often written out as a graph like the ones below. The nodes are states, and the edges represent transitions. When a node p has an edge labeled a to another node q, you're allowed to "do a" to transition from p to q. Here is an automata that I built based on the first few moves that I learned when I started doing swing.¹

As you can see, even with just a few moves and states, the diagram gets pretty complicated pretty quickly. Focusing in on a particular state often helps to clear things up; for example, looking at "closed", we see that a basic step would keep the couple in closed position, and a tuck-turn would transition to open position.

Keeping Count

As we increase the complexity of the moves that we allow, there are a number of interesting things that we can add to the model. Here's a slightly more complicated automaton that incorporates some 8-count "Lindy Hop" moves.

The main thing to notice is that when I added 8-count moves, I added extra states. Strictly speaking, dancing 8-count moves doesn't correspond to a different physical position, but it does correspond to a different mental position. When leading, it is important to be able to communicate your intent. Your partner needs to know that you want to start dancing 8-count patterns after a while of doing 6-count, and vice versa. Since my partners and I are usually beginners, I try to use a simple move (like a basic) to go between standard East Coast and Lindy.

Speaking My Language

It should be clear that if we focus in on only the moves and positions, we can represent the space of East Coast Swing routines using a finite automaton. At any given point in the dance, all of the "valid" moves would be available as transitions, and other ones wouldn't. It is a well known fact in computer science that every finite automaton corresponds to a (regular) language---formally some set of sequences of symbols (strings) that satisfies some property. In this case, the "symbols" are swing moves, and the property is that the whole sequence makes sense as a dance. This means that we literally have a "language" of swing dance, and it corresponds exactly to routines.

Taking this a step further, we can examine exactly which kinds of strings are in the language of East Coast Swing. According to my "beginner" automaton above, the string

basic, basic, tuck-turn, left-side pass, right-side pass

is a valid dance, but

right-side pass, basic

is not (since you can't do a right-side pass from closed position) and neither is

tuck-turn, left-side-pass, left-side pass

because the lead's hand would get all flipped around.

When I lead a dance, I can keep a model like this in my head. Obviously, I'm not actually simulating the automaton in earnest, nor am I really thinking about strings and languages, but thinking about moves this way gives me a framework for deciding what to do next. If the "strings" that my partner and I dance are in the language of swing, I can be sure that the dance will feel natural.

Next Steps

I have a lot of cool ideas for ways to use this language model of dance, and I'll probably write another post exploring one or more of those options later. For now, I'll just mention a couple of my ideas.

Non-determinism.

The automata above are both (mostly) deterministic. This means that the current state completely determines the effect of a move. Put more simply, it means that there are no two arrows with the same label coming from the same source state.

Technically speaking, labeling both "closed" and "closed, 8-count" as start states is a form of non-determinism, but this is resolved as soon as the dance starts, so it isn't very interesting. A more interesting form of non-determinism is "$\varepsilon$-transitions". An $\varepsilon$-transition is a transition that happens without a symbol being read, or, in this case, without a move being done. It turns out that these transitions don't actually change the set of languages that automata can represent, but they do offer a compact and intuitive way to consider state changes that don't depend on the input/moves.

If I allowed myself to use $\varepsilon$-transitions, I could encode things like the music speeding up, or even something as silly as getting tired. In both of these cases, we might want to restrict ourselves to simpler moves that might be less time-consuming and labor-intensive. In the model, this would correspond to a set of $\varepsilon$-transitions into a copy of the original machine with the same states but fewer transitions.

Matching up with music.

Dancing is rarely done without music, and swing is no exception. A large part of "getting good" at swing is developing musicality---a sense of how the music should effect your choice of moves. If we want to express musicality in our automata model, one place to start might be representing the music as an automaton as well.

This simple automaton counts out the four beats in a measure of swing music. Let's say we want to enforce that an 8-count move should always start at the beginning of a measure. This won't always happen, since a 6-count moves often end mid-measure, but it usually feels better.

One way we could do this would be to simulate both automata simultaneously. Each time we do a 6-count move, we advance the music automaton 6 steps, and each time we do a 8-count move, advance it 8 steps. Now, we can make sure that 8-count moves start at the beginning of a measure by making sure that the music automaton is in state 1 before we do an 8-count move. I haven't quite worked out a formal way of doing this yet, but I'm sure there's a clean way to work the music into the model.

Conclusion

I am fully aware that I made a ton of simplifications when talking about dancing. There's a lot more to swing than strings of moves, and even if you do ignore all of the human and musical aspects, it is still way more complex than I made it out to be. My point wasn't to fully capture all of swing dance in one computer science formalism---I just wanted to explore the space and see if I could learn something.

Dancing is fun², and computer science is fun³. Putting them together is a natural way for me to explore each in a little bit more depth, and in this case, I think I got something pretty cool out of it.

If you are already familiar with automata, you'll notice that I'm ignoring accepting states. We could theoretically use accepting states to decide which moves are "fun" to end a routine on and which aren't. Here, for the sake of simplicity, I'm going to assume that every state is accepting except for the implicit "trap" state.

For sufficiently musical definitions of fun.

For sufficiently nerdy definitions of fun.

Derivatives of Regular Expressions

2017-09-30T00:00:00+00:00

Quick disclaimer: The ideas in this blog post are not my original work. I am paraphrasing from lectures given by both Nate Foster and Dexter Kozen at Cornell University, and adding some of my own intuition and insights where I think it is helpful. My intent is to increase awareness of a cool thing that I am excited about, not to pass any of this work off as my own.

Regular expressions come up a lot in computer science. From a theory perspective, they are a compact and intuitive way to understand regular languages. In practice, they allow programmers to recognize phone numbers, search for files, and even parse HTML.¹ Up until about a month ago, I thought I knew everything I wanted to know about regular expressions, and then I discovered Brzozowski derivatives.

Before I start, let's take a step back and define exactly what we mean by regular expressions. Here's a nice inductive definition:

$$ r ::= \varnothing \mid a \mid r_1 + r_2 \mid r_1 r_2 \mid r^* \quad\quad a \in \Sigma $$

Note that this definition is minimal---I don't include things like $r^+$ or $r?$ because they can be written in terms of the other operators. One bit of common notation that I will use is $\varepsilon$ to instead of $\varnothing^*$; both are the regular expression denoting the empty string.

At this point, I'll assume you have a general understanding of how to interpret regular expressions; so if I write $a^*b^* + c$, you should know that it denotes any string that is either zero or more $a$'s followed zero or more $b$'s, or just $c$.

The Brzozowski Derivative

With notation out of the way, we can start to look at what a Brzozowski derivative is.² Intuitively, it is a way of partially interpreting a regular expression. The derivative of $r$ with respect to a character $a$, $D_a(r)$, is a new regular expression that matches all strings from $r$ that started with an $a$, but without the $a$. We "take $a$ off the front of $r$". For example,

$$ D_b(foo + bar + baz) = ar + az $$

Since $foo$ doesn't start with a $b$, we dropped that part of the expression altogether. For each of the other pieces, we just took a $b$ off of the front.

Now that we understand what we're going for, let's actually define a way to compute $D_a(r)$. We'll do it inductively, step by step.

$$ D_a(\varnothing) = \varnothing $$

This one should be pretty obvious. If you take $a$ off of every string in $\varnothing$... well there were no strings to begin with.

$$ D_a(c) = \begin{cases} \varepsilon & a = c \\ \varnothing & a \neq c \end{cases} $$

The idea here is that if you try to take $a$ off of the string $a$, you get an empty string back, and if you try to take $a$ off of the string $c$ (where $c$ is some character that isn't $a$), you just can't do it.

$$ D_a(r_1 + r_2) = D_a(r_1) + D_a(r_2) $$

If you want to take an $a$ off the front of an alternation, you can either take it off of the first expression, or off of the second.

$$ D_a(r_1r_2) = D_a(r_1)r_2 + E(r_1)D_a(r_2) $$

Uh oh. What does $E(r)$ mean? It's actually totally straightforward, and I'll define it in detail soon. For now, just know that $E(r) = \varepsilon$ if $r$ can denote the empty string, and $\varnothing$ otherwise. With that in mind, this statement says that taking $a$ off of a concatenation either means taking $a$ off of the first expression, or if the first expression can be empty taking $a$ off of the second expression.

$$ D_a(r^*) = D_a(r)r^* $$

Finally, we can say that taking an $a$ off of a sequence of $r$'s means taking $a$ off of the first $r$, and leaving a sequence of $r$'s after that. This looks a little silly, but if you play around with it for a bit, it should make sense.³

Making Observations

Let's go back and define $E(r)$, which we'll call the observation function. Remember that it "observes" whether $r$ can denote the empty string, and returns $\varepsilon$ or $\varnothing$ accordingly. Here's the definition:

$$ \begin{aligned} E(\varnothing) &= \varnothing \\ E(a) &= \varnothing \\ E(r_1 + r_2) &= E(r_1) + E(r_2) \\ E(r_1r_2) &= E(r_1)E(r_2) \\ E(r^*) &= \varepsilon \end{aligned} $$

The only tricky thing here is convincing yourself that the $+$ and $\cdot$ cases work. These facts might help:⁴

$$ \begin{aligned} \varnothing + r &= r \\ r + \varnothing &= r \\ \varnothing r &= \varnothing \\ r \varnothing &= \varnothing \\ \varepsilon r &= r \\ r \varepsilon &= r \end{aligned} $$

It turns out that $E$ will be more important than just helping us define the derivative. We can actually use the observation function to tell us about which strings match a given expression.

Matching Strings

We're finally ready to implement a regular expression matcher. Let's can extend our derivative function from earlier to handle entire strings:

$$ \begin{aligned} \textbf{D}_{\varepsilon}(r) &= r \\ \textbf{D}_{ax}(r) &= \textbf{D}_x(D_a(r)) \end{aligned} $$

You can think of this as taking a derivative with respect to each character of the string, in order, and accumulating the result. I now claim that $r$ matches a string $x$ if and only if

$$ E(\textbf{D}_x(r)) = \varepsilon $$

So how does this work? Well, $\textbf{D}_x(r)$ goes character-by-character in $x$, taking each character off of $r$. This means that by the end, we will have a regular expression that matches everything left in $r$ after taking the string $x$ off the front.

If we take $x$ off of the strings in $r$ and that set contains the empty string, then it must be the case that $x$ was in $r$ to start with! Conversely, if we know that $r$ matched $x$ to start with, then removing $x$ from $x$ would leave us with $\varepsilon$.

Practically, this means that we can use Brzozowski derivatives to write regular expression matchers in code! I have a Haskell implementation as a gist on GitHub that you can check out, and I am also currently writing a verified version in Coq.

Why I'm Excited

When I first learned about regular expressions formally, we were given a process for implementing them: 0. Transform the regular expression into an $\varepsilon$-NFA, using a Thompson construction. 0. Turn that $\varepsilon$-NFA into a normal NFA. 0. Determinize the NFA to get a DFA. 0. Run the DFA on the input string.

There are things that I love about this algorithm too. It relies on the amazing result that regular expressions, NFAs, and DFAs are all the same, and the Thompson construction itself is really brilliant. But there's just something that feels so nice and PL-ey about the derivative approach. Rather than deal with intermediate representations and stateful algorithms, we can just define our desired result by induction, and write pure functions that capture our intent. The Brzozowski derivatives are also totally symbolic. The whole process is just replacing symbols with other symbols, which obviates the need for any complex reasoning.

Ultimately, this algorithm captures the reason that I study programming languages. For me, doing computer science isn't about just solving the problem.⁵ It's about seeing the structure of the problem that you are working with, and letting that structure guide you to an answer. It's about avoiding complex decision procedures in favor of symbolic manipulations that simplify and transform your goal. At the end of the day, Brzozowski derivatives are just a different way of looking at regular expressions---but I think they're a really freaking cool way of looking at regular expressions, so I wrote a blog post.

Notes:

For those of you who don't get the joke, this stack overflow answer is a must-read.

Technically, this is the Brzozowski Syntactic Derivative. There is also a Semantic Derivative that deals with DFAs and their denotations.

If you reeeeally squint at these last two definitions you might see something familiar. The concatenation and star rules here are similar in structure to the product and power rules for derivatives in calculus. I doubt this is just a coincidence. If I find a satisfying reason why, I'll probably write another post about it.

⁴

I'm being sort of sloppy with my notation around equality. What I really mean is that $[\![\varnothing + r ]\!] = [\![ r ]\!]$, etc., so $E(r)$ might not actually be equal to $\varepsilon$ or $\varnothing$, but it will always be denotationally equal to one or the other.

⁵

To be clear, there's nothing wrong with "just solving the problem"---in fact, that's usually a far more effective approach.

Encryption and Adjunctions

2017-05-26T00:00:00+00:00

This post goes pretty deep into Category Theory, fairly quickly. For explanations of some of the concepts used in this post, I highly recommend this blog. The post on adjunctions is especially relevant.

In Category Theory, a monad is (loosely) defined as a functor $T$ with two natural transformations:

$$ \begin{aligned} \eta &: Id \to T \\ \mu &: T \circ T \to T \end{aligned} $$

I wondered what it would look like to replace the $\mu$ with a slightly different natural transformation:

$$ \mu' : T \circ T \to Id $$

My intuition was that this might be useful for some kind of security application. If the functor represented some kind of encryption, then $\eta$ allows one party to encrypt some data, and $\mu'$ allows the data to be used after being properly decrypted.

In practice, however, this didn't quite make sense. The biggest problem was that encryption and decryption are inverses, but they aren't symmetric. It seemed that if this was going to work, I'd need two functors (call them $L$ and $R$), and a natural transformation:

$$ \epsilon : L \circ R \to Id $$

One party can encrypt some data using $R$, and the other can apply $L$ and use $\epsilon$ to retrieve the data.

If you know some Category Theory, you might know where this is going: adjunctions! An adjunction is a pair of functors $L$ and $R$ with the following natural transformations:

$$ \begin{aligned} \eta &: Id \to R \circ L \\ \epsilon &: L \circ R \to Id \end{aligned} $$

We write $L \dashv R$ to express this condition. Note that $\epsilon$ is exactly what we wrote before! If we want to represent encryption as a pair of functors, it would be smart to choose two adjoined functors. (If you're curious, the $\eta$ can actually be understood as the same $\eta$ from the monad definition. For any adjunction, $R \circ L$ is a monad.)

Since we'd like this construct to be useful, we want candidates for $L$ and $R$ that are endofunctors (functors from a category to itself) in the category where objects are types, and morphisms are pure functions. (This category is often called $Hask$, named after the Haskell programming language.) One such adjunction is

$$ (X, -) \dashv (X \to -) $$

where $L$ is the product (or Tuple) functor, and $R$ is the exponential (or Reader) functor. Using actual code (I'm using Idris here), the functors are just data types, and are written as follows:

data L k a = MkL k a
data R k a = MkR (k -> a)

We can convince ourselves that these functors are adjoined by implementing $\eta$ and $\epsilon$, which are polymorphic functions that are conventionally called unit and counit respectively:

unit : a -> R k (L k a)
unit x = MkR (\y => MkL y x)

counit : L k (R k a) -> a
counit (MkL y (MkR f)) = f y

But what does any of this have to do with encryption? To answer that question, we really need to figure out better names for L and R. Let's start with R. The key insight here is that R sort of hides data behind a function call. It takes a value of type a, and requires that we have a value of type k if we want our value back. Let's rename R to Encrypted, and write a function encrypt as follows:

data Encrypted k a = MkEncrypted (k -> a)

encrypt : (k : Type) -> a -> Encrypted k a
encrypt _ x = MkEncrypted $ \_ => x

This function is the reason that I opted to use a dependently typed language like Idris over a more standard language. In order to get any use out of this function, we need to be able to specify what type k actually is; that requires passing a type to encrypt as if it were data.

Now that we have the Encrypted functor, we can make a guess at what L is supposed to be. The name I settled on (somewhat unsurprisingly) was Decrypter; this is because the key contained within the tuple can be used to decrypt some encrypted value.

data Decrypter k a = MkDecrypter k a

If we rewrite counit from before, we can finally get:

decrypt : Decrypter k (Encrypted k a) -> a
decrypt (MkDecrypter x (MkEncrypted f)) = f x

With all of this machinery, we can: 0. Pick a type k; in a dependently typed language, this type can be a proof of some sort. 0. Call encrypt k on some value of type a to get an Encrypted k a. 0. Use the MkDecrypter constructor, along with a valid value of type k to make a Decrypter k (Encrypted k a). 0. Call decrypt to get the original value out.

Conclusion

My main purpose with this exploration was to gain a deeper understanding of how Category Theory interacts with real-world programming problems. While the end result is not particularly useful, it does give some interesting insight into what a proof-relevant encryption system would look like.

In addition, I found it extremely interesting how two inverse concepts like encryption and decryption map nicely onto adjoined functors. While it is easy to see that adjoined functors are inverses conceptually, it is exciting to see how they model those behaviors in practice.

Elm, First Impressions

2017-05-25T00:00:00+00:00

I like exploring new programming languages and paradigms in my spare time. Here are some of my thoughts on Elm.

Elm is a purely functional, strongly typed language for web development. It's a very opinionated language, with a very powerful run-time that is designed to make writing web applications easy. There are some things that I really like about Elm, and some things that I find frustrating. Your mileage may vary.

Pros

The Elm Architecture

All Elm applications are written with the same general design pattern. The general structure is similar to things like Redux and Flux (which is actually based on Elm):

model: A single object, encapsulating the entire state of the application.
update: A pure function that takes a message and a model and produces a new model.
view: A pure function that takes a model and produces instructions on how to render the application.

This pattern is called "The Elm Architecture", and the run-time supports it directly. Once you specify these three components, the run-time sets up a model and renders a view. Then, it listens for messages from the view, passes each one to the update function, changes the model accordingly, and re-renders only the parts of the view that changed.

I really like this approach because it manages abstraction in a really intelligent way. On one hand, I have access to (and am expected to deal with) all of the application-specific parts of my project. As a programmer, I need to specify the application state, how that state changes, and what that state "looks like". On the other hand, machinery that is especially general (the wiring) is taken out of the programmer's control completely. (There isn't a lot of configuration in Elm; in general, if the run-time want's to handle something, you're expected to let it.)

A nice side effect of this is that Elm is actually really fast. In some sense, the Architecture encompasses all of the slowest parts of the application---this makes it free to heavily optimize those pieces.

Static Typing

The other major benefit of Elm is that it is statically typed. This means that the compiler (and not the Chrome developer console) catches your mistakes. I could go on for a long time about the benefits of a good type system, but I'll leave that for another blog post.

Cons

No Type Classes

Since Elm looks so much like Haskell, I often expect it to behave like Haskell. While it does most of the time, sometimes it falls short. One large place this happens is with type classes; since Elm does not support type classes it misses out on some of the really nice features that come along with them.

For example, rather than use do notation to deal with monads, we need to explicitly bind arguments into monadic functions (in Elm, most types define a function called andThen for this purpose). Keep in mind that this problem is related to type classes because Haskell's do is tied to the Monad type class; anything that implements Monad supports do notation.

Things like do notation would be a nice to have, but in the end, it isn't such a big deal. One thing that is a big deal is how Elm deals with comparisons. In Haskell, we have Ord a which allows a user to define comparisons for their own types. Elm uses something called comparable, does the same job as Ord, without being a proper type class. Basically, a function

f : a -> Int

can take any argument at all, but a function

g : comparable -> Int

can only take an argument that permits comparisons. Unfortunately, the only types that are comparable are Int, Float, Time, Char, and String--- that's it. There's no way to make a user defined type comparable, since comparable is just a built-in language construct and not a formal type class. This is especially frustrating since the built in type Dict (a dictionary based on a balanced binary tree) has the following interface:

get : comparable -> Dict comparable v -> Maybe v

The result is that no user defined types can ever be the key of a dictionary, even if there is a perfectly reasonable way to compare them.

Conclusion

Overall, I really like Elm. It's been fun to work with, and it's definitely mature enough to be usable for some projects. It has some drawbacks, and I'd hesitate to put it into production just yet, but it's certainly heading in the right direction.

Why not try Spacemacs?

2017-05-24T00:00:00+00:00

Disclaimer: I hope this post does not offend anyone. I do mention both vim and emacs, so reader disgression is advised.

When I first started programming, my teacher forced us to write our code in Windows notepad. Not even notepad++. Notepad.

Looking back, I suppose I understand his rationale; if we learned to write code with all of the assistance that an IDE provides, we wouldn't understand what is actually going on. (Clicking "Run" is very different from typing javac at the command line, and I'm glad that I started off with that deeper understanding.) By the time that I was headed to college, I understood that I could write code even without the bells and whistles of IDEs and code editors.

But that didn't mean I could write good code.

Since those days, I have learned to rely on and appreciate the tools that are available to help me do my work. Writing code is constant multitasking: a programmer is simultaneously solving high level problems and dealing with the nuance of implementing the solutions. Any experienced programmer will tell you that it takes a lot of focus to write good code, so I am glad that there is such a rich ecosystem of tools to make the process easier. I have used a number of code editors and IDEs, from Eclipse to Sublime Text to, most recently, Vim. For the last year or so, I learned to love Vim and it's amazingly efficient editing style. It's how I write most of my code, as well as most things that aren't code. It's completely changed the way that I think about programming.

Lately, though, I have gotten a little bit frustrated with Vim. While I appreciate its philosophy of configurability, it has become increasingly frustrating to actually configure all of the behaviors that I want. I've also had more and more need for advanced code editing features like debugging and linting, which are difficult or impossible to actually get set up in Vim.

Enter Emacs.

A few weeks ago, some lucky YouTube video recommendations led me to watch a few talks on Emacs. From what I could see, it had all of the powerful features that I was looking for, along with the same level of "hackability" that I had gotten used to in Vim. Even more importantly, Emacs has evil-mode. Evil stands for Extensible vi Layer, and is basically a full implementation of Vim in Emacs Lisp. (((Emacs uses a dialect of lisp to configure behavior instead of a custom language like vimscript.))) That meant that I could have my cake and eat it too; the editing style of Vim with the power of Emacs.

There was just one problem left to tackle: Emacs pinky. I'll be honest, I don't have the largest hands in the world, and the thought of reaching for control or alt any time I wanted to do something was not particularly appealing.

Enter spacemacs.

Spacemacs is a custom Emacs distribution that is built on evil-mode and configured with Vim users in mind. Basically, Spacemacs changes almost all of the Emacs key-bindings to the spacebar (the "space", in spacemacs) followed by a short string of characters. For example, SPC f s saves the current buffer, and SPC g s displays an interactive window with Git status information. In keeping with Vim's philosophy, these bindings all all mnemonic; "f s" corresponds to "file, save", "g s" for "git, status", etc. It was shocking how quick it was to get used to, and before I knew it I had written a couple thousand lines of code (and this blog post) in spacemacs.

So, if you happen to be like me (comfortable with Vim, but looking for a more powerful code editor), give spacemacs a try. I can say for sure that it is the first editor in a while that I've felt actually has what I need.