Skip to main content

The Self Taught Developer Myth

I have a problem with the phrase “self taught developer”. It’s not that I take issue with autodidacts. Far from it; I find the phrase redundant. Every developer is a self taught developer. Some of us may take courses in school and may learn to write code under the tutelage of a brilliant, perhaps eccentric professor. Others might learn via after school programs or online courses. But the nice guided path of professors and courses never lasts.

The Joy of Revisiting Projects

What separates the super successful, 10k GitHub stars, front-page of Hacker News side project from the abandoned project that languishes on your GitHub, a starter template with a couple commits from June of 2021? I’d say it’s whether or not you revisit the project. In a perfect world we’d all start projects that we work on every day, make fantastic progress, and ship within a couple weeks to thousands of users and adoring comments on Hacker News and Reddit.

Webassembly Woes

I’ve been playing around with a new language called Vicuna. It’s very much in the early stages, just a simple parser that compiles to JS. One thing I like to do when I write a compiler is to build a playground so that I can inspect the various compiler stages and test everything in an interactive fashion. To build this playground, I decided to compile my compiler to WebAssembly. That way everything could run in browser in a tight loop.

The Next Browser Language

Let’s say you’re writing some front-end code. How many options are there for programming languages? I’d say there’s three camps. There’s plain old JavaScript, there’s languages that compile to WebAssembly, and there’s languages that compile to JavaScript. Plain old JavaScript requires the least tooling, at the cost of being rather frustrating to debug and even more annoying to read. It can be a great, low friction option to start, but beyond some obsession around “minimalism”1, I don’t see many benefits.

How to Think About Compiling

I’ve wanted to write a compiler for a while, about 5 years at this point. I struggled with it for a while because I didn’t know how to even approach the problems involved in writing a compiler. I mean, how the heck do you take a nice, elegant language like Java and turn it into bytecode or assembly? Maybe I’m just not that smart, but it took me a lot of effort to figure out this process.

Tooling for Tooling

We’ve seen a boom in programming language tooling in the past few years. Language servers, formatters, and linters have become commonplace in most languages. I’d call it a golden age, but I suspect this is only the beginning. Fulfilling Developer Expectations This explosion has in turn raised the bar for developer experience. No longer is it satisfactory to provide a basic syntax highlighting scheme for a programming language and call it editor support.

Language Checklist

If you’re creating a programming language, here’s what I think you should have: Error messages with source code locations, snippets and explanations A language server A go-to documention source that most libraries use A linter and formatter A new project generator An online playground A way to manage different versions of the language A C interop A package manager A build tool that works with packages A nice selection of libraries, either bundled with the language or in the ecosystem that handle:

Incentives

Every kid has, while grumbling about some injustice perpetrated upon them by their parents, declared “when I’m a parent, I won’t make my kids do these lame things. I’ll be a cool parent!” Sometimes they’re right. Most of the time, however, they are wrong. Why are they wrong? Because they don’t understand that as a kid, they have fundamentally different incentives than as a parent. A kid may want to eat lots of candy and not go to school, because their incentives are to get dopamine out of eating sugar and playing.

gitgot: Dialed in User Interfaces

I’ve been working on an alternate GitHub front end called gitgot. Some people may be wondering why this is a worthwhile project. Here’s an explanation. People use GitHub a lot. I know I do. They use it for their work, for their open source projects, for school, for anything and everything. As a result, the GitHub user interface has to accomodate all of these different users. It has to work for the developer who is looking at a library’s repository in order to check whether it’s worth using, and it has to work for the maintainer of this library to handle all the issues and pull requests.

Fixing Nits Quickly

How many times have you gotten the following comment on your PR? nit: checkProgram -> typeCheckProgram Putting aside the validity of the rename, it’s an annoying change. You have to go to your computer, open the IDE, rename the variable, commit, and push. If you’re already at work, it’s not a huge deal, but sometimes I get a review back when I’m afk1. Something that should be a 5 second change is now a pain because I can’t open my IDE.