Hi all,
I'm writing this as sort of a professional update during a period of unemployment / funemployment.
Let's see, I left Jane Street about 5 weeks ago. I went to Montreal for a little less than two weeks and have been in New York since. When I left Jane Street, there were two things I was thinking of working on: a "form app" and a "structure editor".
I am interested in making it easier for developers to both make forms and then manipulate the resulting data. In the past I've made a Google form (though next time I would use Tally!), stored the data in Google sheets, and then used curl to get it in JSON format. Then to operate on this data in a type-safe language, I had to write a schema to parse said JSON.
One thing that's sad about this workflow is that I'm effectively specifying the schema of the data twice: Once in Google form's wysiwyg editor, and again to parse the data from JSON. Writing schemas are hard, so it's unfortunate to have to do it twice in different formats.
Another problem is that JSON doesn't support variant types. All the data from the form is stored as records in Google sheets with optional fields. This is dropping type information on the floor: I want to keep the data as well-structured as possible to avoid having to parse it again later down the road.
My goal, at some point, is to implement a library that lets people generate a form with a domain-specific language along these lines:
let name = String.input(label: "Full name")
let age = Int.input(label: "Age")
let occupation =
if age <= 18 {
let grade = Int.input(min:1, max: 12, "What grade are you in?")
Student(grade)
} else if age <= 22 {
let major = String.input(label: "What's your major?")
College(major)
} else {
let field = String.input(label: "What field do you work in?")
Worker(field)
}
submit({occupation ; name ; age})
Here the data passed to submit would be stored in a database, where people would be able to query and manipulate it in the same language. No more converting back and forth between JSON or records! A smart implementation of this could even infer the type of the data being submitted.
I spent the first two weeks of funemployment mostly thinking about this forms app. I did some prototyping with Figma and spent some time setting up and learning Elixir. I found Figma to be an excellent tool for thinking through designs!
Here you can see what that looks like and some of the things I was thinking about:
and here was another iteration:
While I had a great experience with Figma, Elixir re-convinced me that there is a dire need for types. I went into learning Elixir with the hypothesis that maybe the strict type checking I had gotten used to wasn't necessary in all domains and that maybe I could iterate faster in a dynamic language.
After the fourth instance of passing two arguments in the wrong order and spending an hour debugging, I scrapped my Elixir prototype, donated some money to Gleam (an OCaml-like language on the BEAM), and began reading a type theory paper.
For the last three weeks, I've moved from thinking about forms to thinking about languages and types. In particular, I'm creating a programming language called Elderberry. Its type system borrows heavily from a paper The Simple Essence of Algebraic Subtyping (2020), which is a simplified re-presentation of Polymorphism, Subtyping, and Type Inference in MLsub (2017).
I'm pretty excited about Elderberry, but I don't want to hype features that don't exist yet. You can follow along with development with this blog's rss for now or subscribe via email with [email protected]. I'll set up something more formal in the future!
I've also recently been making some art! My friend Rachel has been doing a lot of generative art and has inspired me to get back into it.
So I made this with Jinny! It's amazing how fun and satisfying it is to create art like this! I want to do more of this and bring it to more people.
I have been dreaming about making a so-called "structure" editor tailored to Elderberry. A structure editor directly manipulates the syntax trees of a language instead of manipulating text, see Hazel as an example. That is still very much in my sights and I've been thinking about how to optimize it to make artistic programming as immersive and pleasant an experience as possible. Specifically, a design goal for Elderberry has been and will be to reduce the iteration cycle as much as possible with constant editor feedback and live evaluation. We shall see where it goes!
There you have some things I've been working on / thinking about! I intend to write a similar post as things move along — maybe towards the end of March or beginning of April — so do check back soon or follow along on the RSS!
See you next time, Charles