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.
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.
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
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.
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.
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.
What if we made art schools but for programming?
Let’s back up. I would like to remake the way we teach programmers. I just don’t think a CS degree with lectures, homework and tests works well for teaching people how to program. I don’t think I’m alone here. Many programmers chafe under this traditional structure. They skip class; they get poor grades; they drop out.
This is where the pedantic peanut gallery points out that CS is not programming.
You’re a high school student who is interested in computer science. Maybe you’ve done some programming already. Maybe you’ve taken a couple classes at your high school. Maybe you’re a total beginner1. How do you judge CS programs?
Why Are You Qualified? In short, I’m not. This is equally a rumination on CS program quality as much as a prescriptive guide.
The long answer is that I’ve spent a lot of time2 thinking about undergraduate CS program quality because I recently graduated from a program that appears prestigious on paper but was, in my opinion, worse than schools with a tenth of the reputation.
We’ve seen these posts before: “I’m 13 and I’m learning Rust”, “I’m 15 and I built a website”, “I’m 20 and I’m the king of Macedon”. They’re kind of nice! It’s great seeing someone so young doing such interesting work. I certainly didn’t have the knowledge or ambition to accomplish what some of these developers have done.
And I should really leave this on that positive note, but every time I see one of those posts, I get this…itch, this…discomfort.
There’s been a lot of ink spilled about how packages are evil and npm will bring about the end of days. I’ve responded to these critiques before, but I realized there’s more to say. While I don’t disagree that large dependencies cause issues ranging from security holes to serious single points of failure, I think it’s important that we recognize why packages are so popular and helpful. Any purported solution will need to satisfy these constraints and not just condescendingly claim that these benefits don’t matter.