# If You Need Lifeboats, That Means Your Ship is Sinking

Published

Tags: , and

It’s 1912 and Captain Edward Smith is boarding the RMS Titanic. He sees the lifeboats on deck and shakes his head with a heavy sigh before turning to the crew. “In my experience, I’ve never needed lifeboats. They’re not best practices — if you need lifeboats, that means your ship is sinking!” The crew members are enlightened and eagerly throw all lifeboats overboard. The Titanic begins its voyage to New York.

# Update

Published

Tags: , , and

Just a quick update because I’ve been too busy to write much recently.

I’m giving a talk at DConf 2017 in Berlin! D’s been growing strongly in the past five years, and DConf’s been growing dramatically since the first one in 2013, so it’s pretty exciting to get involved. No, really. I often give tech talks at no-name events here in Sydney, but I’m half scared I’ll wet my pants on stage with a lineup like this — in my university days, I used to read all the C++ books by Andrei Alexandrescu and Scott Meyer that I could get my hands on.

If you have a DConf ticket, I look foward to seeing you there. If not, then you can look forward to watching the videos :)

Instead of writing a real blog post, I’m dropping a link to this classic about backwards compatibility nightmares, which you might like if you thought the mess that’s x86 BIOS booting was interesting. It’s a chapter from The Old New Thing, a book by Raymond Chen from Microsoft, based on his blog. Raymond Chen has spent a lot of his career making sure new versions of Windows can still run old software, no matter how badly the old software abused APIs and deserved to crash. Most of the technical details belong to the 90s, but there are plenty of morals for software development in the real world today. If you can read that chapter without ever wanting to weep for the industry, you’re stronger than I am.

# On Not Optimising for Last Century's Hardware

Published

Once upon a time I wrote a super-optimised algorithm for rotating data in an array. At least, it was meant to be super-optimised, but its real-world performance turned out to be terrible. That’s because my intuition about performance was stuck in the 20th century:

1. Break a program down into basic operations like multiplication and assignment
2. Give each operation a cost (or just slap on an O(1) if you’re lazy)
3. Add up all the numbers
4. Try to make the total in step #3 small

A lot of textbooks still teach this “classic” thinking, but except for some highly constrained embedded systems, it just doesn’t work that well on modern hardware.

# Function Attributes and the D ABI

Published

The D programming language has a bunch of built-in attributes like pure and nothrow. I was wondering how things like libraries might break if function attributes changed between versions, so I gave it a try.

# A Tale of Three Server Caching Architectures

Published

Exactly where you put caching in a distributed system has a significant impact on its effectiveness, in ways that aren’t always obvious during the design phase of development.

# DConf 2016 Talks

Published

Tags: and

The DConf 2016 talk videos have been released.

Here’s my (very short) list of special recommendations. They’re worth watching even if you don’t use D.

# Code Versus Data

Published

Some years back I wrote a program in C++ using an obvious object-oriented architecture. Then, later, I had to rewrite it in C, and I learned some pretty good lessons about software design.

# The Enterprise Pushbutton

Published

Let’s talk about a hardware driver for a pushbutton. A pushbutton driver isn’t as completely trivial as it might sound because you need debouncing logic to ensure a crisp on/off signal, but it’s hard to imagine how it might need more than about 100 lines of C code.

After working on this particular embedded system, I didn’t need to stress my imagination any more. This pushbutton driver was modelled as an explicit finite state machine, and all the possible states and transitions were specified in a spreadsheet. Then there was a python script that processed this spreadsheet and generated state table data as C code. This was linked to an FSM evaluator in C. The FSM was controlled by a bare-metal driver and triggered callbacks on each state transition.

Most of the callbacks were marked “not yet implemented”. In fact, only two states were even reachable: BUTTON_UP and BUTTON_DOWN. Eventually the entire project was canned, but not because of missing support for BUTTON_TIMEOUT or any of the other states.

The FSM didn’t do any debouncing, so the low-level driver had to do that before passing button up/down events to it.

# How Dirtying Pure Functions a Little Can Be Useful

Published , Updated

Functional purity is a valuable concept for writing maintainable code, though outside of functional programming languages like Haskell, it’s often treated like a nice-but-expensive luxury. But it turns out that pure functions that aren’t quite so pure can be cheap while still having concrete benefits for code in non-functional languages like C++, Java and Python. For D code, this is supported by the language itself, but there’s nothing D-specific about the overall idea.

Published

Story time.