If you’ve discussed CS education or gotten a CS education, you’ve probably encountered this line. It’s often given as a retort for why a CS program is not centered on teaching programming. As a pure factual statement, it is absolutely correct: CS is not programming. Even as an overarching statement about CS programs, it is indeed correct: CS is not programming and therefore CS degrees should cover material that is not programming.

You don’t get paid to write dependencies. To an extent, I think everybody knows this. But it’s worth saying bluntly because people will not say it to your face. Instead they’ll attempt to say other, nicer things, like “don’t reinvent the wheel” or “not-invented-here syndrome”. But really, that’s what they mean. You don’t get paid to write dependencies because your users don’t care about your dependencies. Your users aren’t deciding to use your library on the basis of your node_modules size.

I was reading HN like a dutiful tech employee, when I stumbled upon a classic HN scene: a laudatory Rust post followed by a whole host of reactionary anti-Rust comments. In these comments was an inadvertently good question: Why is “(re)written in Rust” a good selling point? My first instinct was to respond with the typical arguments: Rust is safer; Rust has a nicer build system; Rust is faster. But after some thought, I actually wanted to respond with the answer that most people hold in contempt: Rust is fun!

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.

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.

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.

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.

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 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: