I started using Substack as an experiment, to see if it would make blogging easier, and it has. There are definitely things that are annoying — my ongoing gripe is that there is no complete list of keyboard shortcuts. Yes, there’s a short list but I have discovered others by accident and suspect there is an unpublished full list. For example, when you’re inside a code block you can hit Ctrl-Enter and it will pop you out. There are likely plenty of others that would make my blogging experience better.
That said, the ability to just type turns out to be very helpful. Sure, I’ve been able to use various forms of text enhancement over the years, from HTML to markdown. Over the years, however, I’ve learned that things that seem like trivial operations add to the cognitive load in small ways that impact the bigger picture. I have a certain limited capacity — we all do — and using any of that capacity on seemingly trivial things depletes it for the important things. So, not having to mentally translate <i> or * to “italics” while I’m typing and reading really does make a difference. I can focus on what I’m writing rather than the mechanics of translation into display form.
My Journey
I was first exposed to concurrency in grad school for computer engineering. We were looking at the assembly-language instruction set for some CPU and there was an instruction that caught my eye. I asked the professor about it, and he said it had to do with parallelism but we wouldn’t be exploring that. It had me wondering how the CPU could possibly do more than one thing at a time, and that question settled into my mental background, apparently for the rest of my life.
Occasionally something in the computing world would wake it up. My first couple of computers (Kaypros) ran an “operating system” called CP/M (control program for microcomputers) which was little more than a glorified program loader; there was no concept of concurrency beyond the interrupt service routines (ISRs) that took care of low-level things like printing, timers, disk access, etc. Clever hackers figured out how to create what came to be called terminate-and-stay-ready (TSR) programs—little utilities that would be loaded into memory and held adjacent to the main program. If you hit a special keyboard combination, it would cause an interrupt that would swap the TSR in and give it control. I did not understand at the time that this was an example of cooperative multitasking, controlled by the end user, which we now automate into our programs using async and await.
Years later I wrote an article for Computer Language magazine (long defunct) where I implemented cooperative multitasking in C using setjmp and longjmp, saving and restoring CPU registers for the context switch. Only now do I understand that I was creating a kind of continuation by using my knowledge of what was important in a function to save and restore essential information.
And that leads me to my point. Regardless of the years of on-again, off-again exposure to concepts in concurrency, I still didn’t have enough foundational ideas clearly formed into a mental structure to read and understand basic treatises on the subject. The dominant problem here is that authors tend to use terminology quite carelessly, but as if their terms and definitions are obviously the correct ones that everyone understands. But to the novice, they can read one thing and it seems to make sense, then read something else which then appears to use very different terms for what seem like similar concepts. Or worse, use the same terms for different concepts.
What I’ve discovered is that to understand even the most basic coverage of concurrency, you must first have a mental foundation that allows you to say “oh, I see how you’re expressing <thing> but I realize that what you actually mean is <basic concept> despite the words you are using here.” It’s the very definition of a Catch-22: you can’t read an introduction to concurrency before you have enough of a foundation to successfully interpret that introduction.
There’s also the problem that so many introductions to concurrency claim that the reader doesn’t need to understand anything about concurrency, and then immediately use terms like “blocking” which the author somehow assumes that the reader already understands, when it’s actually a very messy core concept that is often used in contradictory ways, and needs a lot of basic explanation. This is an example of the “curse of knowledge” problem (as famously expressed in the “curse of the monad”), where as soon as a person understands an idea they become incapable of explaining it, probably because the mental shift they experience requires concepts like “blocking” to become part of the background.
My goal with this work is to create this mental foundation so that newcomers to concurrency can successfully navigate these stormy seas.
The Book
I seem to have been trying to get to this book for a long time. I mentioned the idea to Guido van Rossum at one of the Portland Pycon conferences and he expressed significant enthusiasm, saying that lack of understanding was a serious problem—the depth of which I did not understand at the time.
I got distracted and wrote Atomic Kotlin, then updated On Java 8. I got involved with the Effect-Oriented Programming project which ultimately turned out to be concurrency-heavy (and has provided me great insights). Now it finally feels like I’m ready for this book. It’s taken a long time to get here, and the reason I started this blog is to move me forward even though I cannot yet know the full depth of how I will present this topic. And I definitely cannot say how long it will take. When it’s done, it’s done, but there can be no schedule.
When I do start building the book, my plan is to publish it as I create it, through Leanpub as an eBook. My goal is to have a regular publisher, but it must be the right fit (see below). If that doesn’t happen before it’s done I will publish the print book through Ingram, as I did with Atomic Kotlin and others (but will still be looking for the right publisher).
For Publishers
My very first book, Computer Interfacing with Pascal & C (1988) was a self-published collection of my columns from the late great Micro Cornucopia magazine, the first magazine I ever wrote for and still my fondest experience. Self-publishing was extremely satisfying, and when I started working with publishers I found many aspects quite frustrating by comparison. After Thinking in Java, I decided I wanted to go back to self-publishing, and have published a number of books that way.
That was useful life experience, and now I understand that promotion is something that I dislike to the point of active resistance. If I want to get a book into the hands of as many readers as possible—and I do—then someone else needs to do the promotion, someone enthusiastically committed to that. I am willing to deal with (at least some degree of) hassle to achieve good promotion.
I want good promotion because I would like to give seminars/presentations and consult on this topic. I’ve found that having a widely-known book is helpful in this goal, so I need a publisher that is exceptionally good at, and committed to, promotion.
With past books, I haven’t worried about the size of the advance as I’ve always been confident that the book would earn back that advance. I’ve learned from hard experience that this isn’t what the advance is about. Instead, the advance is the expression of commitment by the publisher: how much jeopardy they are willing to put themselves in for this book. If the advance is small, it becomes easy for the publisher to write off a book if it doesn’t immediately take off after a minimal promotional effort. I don’t love the system, but it’s the harsh reality of capitalist publishing: size-of-advance == level of commitment.
I know that some publishers have a “style” that they decide upon when they start the company, and insist on reforming each new book to conform to that style. I also have a style that has evolved over many books, one which is not frozen in time but which I change as the programming world changes. A simple example of this is that I have a comment at the beginning of each file that tells the reader how to find the file in the book’s Github repository (and as much as possible I keep each file name unique). I find this serves the reader much better than calling a code listing figure 12.4, which is more work for the reader and feels attached to the pre-computer print age. If you like my writing, great, but I’m not likely to adapt my style to some arbitrary old standard. Any changes must somehow serve the reader.
I’m open to better approaches to copyediting. However, I’ve had too many experiences where publishers introduce more errors into a manuscript than they fix. For both Thinking in C++ and Thinking in Java, I generated camera-ready pages. I don’t want to do this; it’s a lot of work and one of the things I like about Leanpub is that it can automatically generate camera-ready pages (there are significant restrictions in how much formatting you can do but it’s worth it not to have to create my own pages). I must be able to ensure the correctness of the book, first and foremost. (Aside: I once had a great experience with a professional copyeditor hired by a publisher, who significantly improved my writing by working through issues with me.)
I’ve also had terrible experiences with publisher-created cover designs. I have my own designer and I control the cover design.
A Working Book Title
So that’s it: I changed the name of this blog because it seems to work well as a way to capture essays that will eventually feed into the creation of a book on the foundations of concurrency. People are thrown into the topic without the fundamental mental model necessary to parse and understand conflicting terminology and ideas. My goal is to solve that problem. I’ve been struggling on and off with this for decades and it seems like it’s ready to come together, although I don’t know how long that will take.