Skip to content

{ Category Archives } code-level

Two ways of thinking

I’ve used this idea in conversations for years, and can’t find a post on it, which I find surprising but there you go. There are, broadly speaking, two different ways to look at programming languages. And I think that these mean two different ways to select programming languages, which are asymmetric. However, they can lead […]

Literate Programming with LibreOffice

This post comes in the form of an OpenDocumentFormat document containing a program that can extract programs from ODF documents, including the program contained in this document.

In defence of assertions

The year is 2017 and people are still recommending processing out assertions from release builds. many assertions are short tests (whether or not that’s a good thing): this variable now has a value, this number is now greater than zero), which won’t cost a lot in production. Or at least, let me phrase this another […]

Your build needs to be better

I’ve said it before, build systems are a huge annoyance. If your build is anything other than seemingly instantaneous, it’s costing you severe money. Your developers are probably off reading HN, or writing blog posts about how slow builds cost them, while the build is going. When they finish doing that, which may be some […]

Working Effectively with Legacy Code

I gave a talk to my team at ARM today on Working Effectively with Legacy Code by Michael Feathers. Here are some notes I made in preparation, which are somewhat related to the talk I gave. This may be the most important book a software developer can read. Why? Because if you don’t, then you’re […]

Build systems are a huge annoyance

Take Smalltalk. Do I have an object in my image? Yes? Well I can use it. Does it need to do some compilation or something? I have no idea, it just runs my Smalltalk. Take Python. Do I have the python code? Yes? Well I can use it. Does it need to do some compilation […]

The package management paradox

There was no need to build a package management system since CPAN, and yet npm is the best. Wait, what? Every time a new programming language or framework is released, people seem to decide that: It needs its own package manager. Simple algorithms need to be rewritten from scratch in “pure” $language/framework and distributed as […]

Apple’s Best Programming Language

My talk at App Builders 2016 was on Apple’s best programming language. Spoiler alert: it’s Dylan. Or is it? I chose a few properties one might wish to find in programming languages, then demonstrated how these were all present in the Dylan language. I also took a dig at certain other languages, which do things […]

Did that work? Maybe.

A limitation with yesterday’s error-preserving approach is that it leaves you on your own to recover from problems. Assuming your error definitions are sufficiently granular, this should be straightforward but tedious. Find out what went wrong, recover from it, then replay everything that happened afterwards. Recovering from failures automatically is difficult in general, after all, […]

Getting better at doing it wrong

For around a month at the end of last year, I kept a long text note called “doing doing it wrong right”. I was trying to understand error handling in programming, look at some common designs and work out a plan for cleaning up some error-handling code I was working with myself (mercifully someone else, […]