Heads up! This blog post is a reading log I'm writing. I'm spending 30 minutes a day reading The Book of the Runtime.

Reading Log 1: The Book of the Runtime

So I've been reading the C# via CLR book, but fellow nerd David Fowler recommended The Book of the Runtime as more up my alley. So here we are.

First off, I love the origin story of the Book of the Runtime. It started off as internal docs for developers on the .NET team at Microsoft. When .NET was open-sourced (yes, .NET is open source!) the documentation was open-sourced as well. I love how organic this evolution was. I find that the best kinds of docs are the ones that come out in that way.

The moment I read the first paragraph of the text, I knew it was right up my alley. It started by providing a conceptual definition of what a runtime was: "a program and all the dependencies (both resource and execution wise) that it needed to run."

The book covers how weak the standardization of programs tends to be. For example, when you compile a program, the best you can do is compile it to the most common standard possible: the architecture and operating system (32-bit or 64-bit Windows or Linux, for example). No standards exist for important components of a program like garbage collection and access to a standard library.

The Common Language Runtime (CLR) serves to solve this problem by providing a standard for this unstandardized landscape. I learned something I didn't know here. The CLR's spec is standardized by ECMA (much the same way that the JavaScript specification is). Nifty!

The specification outlines everything that you need to know in order to run a program, from dependencies to compilation to deployment. The BotR then reiterated some of the key features of the Common Language Runtime that I learned about in the C# via CLR book. The usual suspects are there:

• an intermediate language with removes the requirement for programs to target a particular architecture
• metadata tables that store information about the types and definitions with a set of programs
• the assembly format which provides a portable format for the executed file

The book also stressed the benefits of the CLR's support for multiple languages. Because the CLR provides a common platform that can be targetted by any language, any features that are available in the CLR become available to all the languages it supports.

I drew an analogy between this and the Jupyter messaging specification, a JSON-based messaging specification for managing interactive REPL sessions between arbitrary runtimes (kernels) and clients. I love picking up common threads like this in my learning.

The book then went on to clarify the CLR's focus on simplicity. And enter my favorite quote, ever:

For example, fundamentally only simple things can be easy, so adding user visible complexity to the runtime should always be viewed with suspicion.

Ugh! I love this. For the very particular phrase "user visible complexity." It underscores the fact that some complexity is OK as long as it doesn't bleed out to the user. This is a great note to keep for app and API developers alike.

The book goes onto highlight some things the CLR does to improve ease of use and highlight one particular scenario: keeping object/method names consistent across a codebase. Even when this might seem impractical (renaming every method in a library), the priority for consistency and ease of use is noted.

I've arrived at the end of the 30 minutes and I already like this text more. It's got the right balance of conceptual details vs. nitty-gritty and I find the narrative voice to be friendly and approachable.