December 28, 2020

100th Issue End-of-Year Bonanza

It's the 100th Computer Things Newsletter! I'm celebrating with a book announcement and director's commentary on all of my 2020 essays. But first, a couple of housekeeping notes. First, there's a couple slots left for the February Alloy Workshop. Feb 8th, 10 AM - 6 PM CST. Learn how to find bugs in your designs without having to spend weeks coding them up first, etc etc etc. Second, no newsletter next week, as I'm teaching the TLA+ workshop. Okay, housekeeping notes over!

Computer Things, The Book

I originally started this newsletter to update people on blog posts and share my unpolished thoughts on tech. I expected to write maybe one newsletter every two weeks. Instead, this became, by far, my biggest project of 2020. As of newsletter 99 I had written over 100,000 words for the newsletter. Better yet, almost all of it is original content. Less than 3% of that is administrative overhead, things like workshop announcements, life updates, etc. If Computer Things was a book, it would be over 300 pages and touch on everything from exotic testing strategies to the history and culture of the industry.

I know this because I compiled it into a book. You can now buy the collected 2019 and 2020 essays on Leanpub. Price is $15 this week and $20 after. I removed the administrative overhead and cleaned up the formatting a little, but otherwise everything is as-is. It includes both the public and private newsletters, meaning people who joined late can now catch up on the complete archives.

I want to be clear there is no new content here. If you've been here from the beginning, you've already seen everything in the book. If that's the case, consider it a donation! I want to keep Computer Things a free newsletter, and purchases here would go a long way to justifying all the time I've put into this.

So what's the plan for 2021? More of the same. Keep capturing whatever's on my mind and turn it into a free, original essay on software. I don't know what the specific topics will be, just as I didn't know what they were in 2020. It could be on the structural theory of bugs, it could be about joining a software cult. All I can promise is that I'll keep writing.

Book link again is here.

2020 Essay Commentary

It wasn't just writing for the newsletter! Over the last year I also published another 46,000 words on my blog. I thought the newsletter bit into that a little, but no, that's roughly the same amount I wrote the last two years, too. Guess the 100,000 newsletter words were just a bonus!

I figured I'd give my thoughts on each of the pieces. This is a peek behind the curtain!

• Hypermodeling Hyperproperties: My job is teaching formal methods to beginners and I spend a lot of time on the basics. This can get a little grating. I like teaching, but I also want to push my skills! I could write a piece on advanced TLA+ use, but that didn't feel like it quite fits with the blog's focus on formal methods for a general audience.

  Hyperproperties were my compromise. They're a niche-inside-a-niche that take a lot of cleverness to model. But they're also so obscure most people haven't even heard of the concept, meaning I could introduce them in a general way and still write something unique and engaging. Plus it's still helpful to a general audience, as the mindset of hyperproperties sometimes comes in handy. I like how this piece came out.

  (I've since gotten more okay with putting up an advanced TLA+ piece, so I might start doing that more next year.)

• The Business Case for Formal Methods. Written to help me drum up more business by making it easier to talk to their bosses. I don't know if it helped or not; COVID threw everything sideways. But I'm predicting it didn't do much, if anything. One thing I can improve is the demo. If I made it a video, it'd be easier to show to people.

  The formal methods example I used is an interesting one. On one hand, it's a simple model of a common business problem that's obviously correct and completely broken. On the other, it's "obviously" raw TLA+. I know some people in the community disagree with me on this, but IMO people are much more willing to try a tool that looks like familiar programming. Before this I used a PlusCal bank transfer algorithm, but bank transfers aren't "common business problems". I need to find the middle ground.

• Feature Interaction Bugs: This happens to me a lot:

  1. Run into a weird real-world problem. 1. Think "hm, this could be an interesting example for something" 1. Find a topic that is perfectly illustrated by that example. 1. Write an entire essay around that topic.

  Here it was the footnote: "This is a real bug I found in a large tech product." That is the reason for this essay. If I hadn't run into that bug, I wouldn't have written 3,000 words about feature interaction.

• This is How Science Happens: Someone said this piece had "Straight up Knives Out vibes". That's the highest compliment I could have gotten. This piece was a tricky one, because I was trying to do three things simultaneously: explain a controversy, explain the topic of a controversy, and explain the scientific culture that embeds the controversy. Using a story framing, with a sense of characters and narrative, felt like the best way to hit that for me. I could thread the ideas through the narrative to create "plot points" and "conflict". That compliment told me I had succeeded, and the essay worked as a story.

  I'm also really unhappy that I got P-values wrong. It's a reminder that I don't actually know any statistics. I need to learn statistics, and I need to fix the error.

• 10 Most(ly) Dead Important Programming Languages: One of the most popular things I wrote this year. Is it weird that I don't like it? Like it's a fine writing, but whenever I reread it it just... doesn't click for me. I think I'd like it more if I tried to draw more connections between the ten languages. Then again, maybe that would have made it less interesting to everybody else. I'm not my target audience.

  This was also the first "spite write" I did last year. That's another common inspiration for essays: I read something, hate it, and spend days researching and writing a response. Often I barely even discuss the other article, I just try to present the opposite case so well that everybody agrees with me. Spite writes are some of my most popular pieces. I wrote fewer this year than I've done in previous years, probably because I'm using the newsletter as an alternate outlet.

• Announcing: Alloydocs: Oh yeah, I completely forgot about this. It was my big early-year project. I want to expand it considerably come 2021. Specifically, I want to add more tutorials. The official one is starting to show its age a little.

• The hard part of learning a language: You might remember it as "Why Python is my favorite language". I renamed it to make it clear I wasn't saying Python was good at these things, just that I already overcame the friction of Python. Unsurprisingly, most commenters missed that and thought I was a Python fanboy. I also removed a section on how to fix the problem to keep the article punchy.

  I feel really badly about this essay. In the ProgrammingLanguages Subreddit one language designer said he found it really intimidating. I didn't even consider that I might be discouraging language designers, and that horrifies me.

• In Praise of AutoHotKey: I just added an AHK script to rewind YouTube by 1 second instead of 5. AutoHotKey is great.

  More seriously, I'm always frustrated with how little we augment our computing experiences through tweaking the computer. Not just at the shell level but the GUI and app level. Sometimes it feels like our options are "everything decided for you" and "become a Linux master", when people need more stuff in the middle ground. AHK is a great tool and I want to there to be many, many more similar tools, and affordances in products for interfacing with these tools.

• Constructive vs Predicative Data: IMO the most interesting idea I introduced this year. I've never seen someone distinguish the two types of data before, and I hadn't thought of it until I wrote a bit on "making illegal states unrepresentable" (which is in the newsletter book). I like how just having the concept makes me a better programmer. I can now ask "is this constructive or predicative", come up with an answer, and get useful insight from that answer.

  I'm a little disappointed this piece wasn't very popular. The main criticism I got was that Liquid Haskell has refinement types, which are constructive types as expressive as predicate types. The problem with this criticism is that they are that expressive by adding predicates, and so add their intractability: typechecking LH requires a ton of manual intervention.

• Property Testing with Complex Inputs: Originally wrote this for the Hypothesis blog, but we couldn't figure out how to build the Jekyll site, so I posted it myself. I'm vaguely unhappy about that. It's a good and informative piece, don't get me wrong, but it doesn't fit in with the rest of the blog. Maybe because I was expecting it to go somewhere else, I wrote it in a different register that clashes with the blog. I dunno. I'm harder on myself than I should be.

• Weak and Strong Fairness: An interesting counterpoint to "Hypermodeling Hyperproperties". This is a niche topic for a niche audience. I wrote it because there aren't any intuitive introductions to fairness online. Formal ones, yes, but not intuitive ones. Since then I've linked to it a whole bunch as a reference, it works well for that. I should write more references.

  You don't know badly I wanted to call it "Algorithmic Fairness". Hey, it's still an accurate title!

• Frink is Good, the Unit is Evil: Every year ChiPy hosts a programming language shootout, where people make a case for their favorite non-Python languages. Last year I swept the competition with J.¹ This year I was gonna bring Frink, then COVID happened.

  I just wanna get more people using Frink! It's one of the most useful "supplementary" languages I know. I wouldn't want to do general-purpose programming in it, but I'm often in its domain enough that it shines. Just being able to do things like now[] + 4 hour -> Paris is worth the price of admission.

  ("Supplemental programming languages" is a really cool idea. Off to the slush pile!)

• A better cheatsheet: This is a very... opportunist piece. I tested out progressive cheatsheets late last year and was blown away by their performance. I'm proud of coming up with them and I want more people to make them. So why opportunist? While I included a starter template, I don't expect a single person to actually use it. And I knew that going in! The motive of the piece is to sell myself as a teacher. The kind of person who cared so much about teaching he'd spend hours optimizing his cheat sheets to improve his workshops. So far, that seems to play out. Most of the positive feedback I've gotten on this has been from other teachers.

• J Notation as a Tool of Thought: I didn't talk about it in the essay, but this was inspired by Array languages for Clojurians. That essay argues the unique bits of APL are trivially replicable in Clojure, dismissing APL with "It’s nice to travel: try the food, learn a few phrases, visit their monuments." But he was, by his own admission, just a tourist! He doesn't even know enough to know why his replications are wholly inadequate.² just the surface level oddness. I wanted to show how APLs aren't just "the same needs and the same tools, only under a different set of names." This is all a communication problem born from how hard it is to convey mindsets. Most people who learn J says it changes their thinking, but they struggle to explain how it does. Communicating mindsets is really hard!

  Come to think of it, while I spite wrote this piece I never directly addressed any of the claims in the essay I was mad about. Maybe I should do that in a tweetstorm or something.

• Decision Table Patterns: Probably the most useful thing I wrote this year. I've always found decision tables really powerful, and am surprised that nobody else uses them. Couple fun notes about this piece. First of all, I was sitting on this a while, because I was afraid of releasing something that wasn't heavily battle-tested by me. I didn't want to give bad advice! Eventually I decided that if I was clear it was "theorycrafting" that'd be okay. Second, it took me forever to figure out how to get two tables side-by-side. Markdown does not make doing weird things easy. I had to add a preprocessor shim to Hugo to add div wrappers with custom classes. I found a few other uses for it since.

• Finding Goroutine Bugs with TLA+: I honestly don't have all that much to say on this one? I read a piece on a goroutine concurrency bug, I thought it'd be fun to model, I modeled it and wrote it up. The most interesting parts to this one are a couple of essay innovations I tried. First, adding a "Planning Ahead" section. I really liked how that turned out. Second, putting syntax explanations in dropdown boxes instead of inline with the whole essay. That strikes a nice compromise between people seeing TLA+ for the first time and people who already know it and don't need yet another explanation of what operators are.

• Software correctness is a lot like flossing: Good piece, important topic, screw that I love this title so much. You ever read discussion and wonder "did these people even read the essay?" Shockingly often the answer is "no". People can get away with it because most titles predict the content. If I read "Why we moved to microservices", it's probably going to be glowing praise of microservices.

  But here it's a trap! The metaphor seems like it's gonna be "both are important and you should be shamed if you don't do them", but it's actually "people don't do things that are unpleasant and inconvenient." It's accurate, a more interesting use of the metaphor, and the polar opposite meaning. And yet so many people angrily commented as if I was saying they sucked for not flossing. This the best title I wrote this year.

• Two workers are quadratically better than one: And this one's the worst. I started writing this piece because I figured out the trick to writing useful PRISM specs: use a templating engine. I wanted to get people interested in PRISM! But the example I used was so interesting I realized this piece had two potential audiences: people into formal methods and people into queueing systems. I wanted a title that represented both groups and came up with "Two workers are mathematically better than one".

  That was a mistake. That title infected the rest of the piece, and I started making it more and more about latency and less and less about PRISM. When I changed to title to be more "accurate", PRISM wasn't represented at all. The templating trick I most cared about? One sentence and a gist link. "Two workers" wasn't a bad piece, but it wasn't the one I wanted to write. And I think if I'd used a different title I wouldn't have made the same mistake.

  There's another unrelated issue, which is that I didn't ask anybody for feedback on the piece. There were some dumb comprehension errors I could have fixed if I had.

• There's Always More History: A nice counterpoint to the "10 influential languages" essay. I had two historical nuggets, and rather than write two essays I put them both in one and drew a broader connection between them. That made the essay "complete" to me in a way "10 languages" wasn't. But I also think it made the essay less popular. Both of the historical dives- why vim uses 'hjkl' and why months are 0-indexed- are interesting. People would read essays about those. But if you see "There's Always More History", you don't think it's going to cover those topics; it's probably just a boring historiography lecture. I might try changing the title of the essay and see if that gets more interest.

Thanks again for reading! And here's to a happy and safe 2021.

-Hillel

If you're reading this on the web, you can subscribe here. Updates are once a week. My main website is here.

My new book, Logic for Programmers, is now in early access! Get it here.