Chapter 4 is about declarative concurrency. This takes what we’ve learned about declarative programming and applies it to a concurrent execution model.

A challenge of concurrent programming is nondeterminism. A source of many painful, and in some cases fatal, bugs in software.

A declarative concurrent model means that any nondeterminism is not visible to the programmer. There are two reasons:

After a long hiatus, I’m back to doing the CTM bookclub. It’s been quite busy at work, but we (Terrateam) delivered GitLab support, are working on Bitbucket, and we’ve delivered a host of other changes. Needless to say, I’ve been too busy for other fun activities like blogging. But I’ve scraped some time together and going to aim to be more consistent. What’s helping is I’m doing this bookclub with my co-worker, so now there is a support group.

I was a big fan of the original Chromecast. The UX was simple: install the thing, get it on your Wifi, and then just send stuff to it from your phone. The end. No remote. No account. Barely even any security! It didn’t do anything other than be a destination for whatever content I want to see on my TV.

I recently bought whatever Google is calling the latest generation of Chromecast and it involves a whole account setup, it has a remote, collects a bunch of data about me (which it probably can get based on what I cast and my IP anyways), and, basically, it’s just a TV. It’s still an HDMI dongle, but it’s basically a TV. I hated every second of it.

The first few chapters are dedicated to getting the user acquainted with the basics of the programming language, the system, and the base concepts that will be expanded on through the book.

Concepts, Techniques, and Models of Computer Programming, otherwise called CTM, by Peter van Roy and Seif Haridi is my "one book" for software development, if you need to pick one.

What I love about CTM is that it covers a huge range in topics, from programming in the small to in the large, functional programming to object oriented programming, and sequential programming to concurrent programming. Not only does it cover all these topics but, in my opinion, covers each of them sufficiently such that the reader can understand them and successfully use them correctly.

Every few months there is a news story about some AI company CEO saying that in a year almost all code will be written by AI. The software engineer, where previously having tremendous bargaining power, is going from scarcity to redundant.

The valuations are huge. Windsurf was recently bought for $3bn. Anthropic raises money on a bi-weekly cadence and most recently has a valuation of $61.5bn. Even the French are getting in on it, Mistral having a valuation of $6bn. And Cursor raised at a $10bn valuation.

The infrastructure startup Wing Cloud, creators of Winglang, recently shutdown, after receiving a $20 million investment in 2023. I did not find this surprising. Not because the developers aren’t great or because I’m a genius business person. It wasn’t surprising because the idea of Winglang went against my mental model of how technical progress happens.

The idea of Winglang is to combine application code and infrastructure code. You use a "queue" object in your code and the Winglang environment constructs the underlying cloud infrastructure for that. Maybe it’s SQS on Amazon, and something else on GCP. Not only is Winglang a new programming language but also it’s a totally different way to provision and manage infrastructure.

I recently got sent the slides for a talk titled On Bloat by Rob Pike, that can be found here. I don’t know the origin of the talk or what the intention was and only have the slides to go by.

The presentation makes the superficial observation that hardware has become significantly faster since the first mainframes yet software does not feel like it has utilized those gains well. Computers don’t boot instantly. Logging into your bank has some noticeable latency, etc.

One of the primary skills I try to impart to people that I mentor is to "think before you type". This is obviously not a new idea but I suspect, with the proliferation of LLMs to write code, that stopping to think will be a rarer skill in software engineering.

An analogy I use is that coding is like getting from A to B. You don’t start going in a direction until you know which direction you need to go. You need to understand where you want to be before even any automation can help you.

This week I implemented a pattern I find myself reaching to quite often. I call it the Match Set/Query Pattern.

The pattern is simple and requires two elements: