If you follow this blog at all, you’ll probably have noticed by now that the site has been redesigned and simplified.
This coincides with me finally getting round to moving away from Drupal and towards a static design using Jekyll.
There is still quite a lot of the old site waiting to be ported, and quite a bit of cleanup to do on the new one, but hopefully I’ll get there eventually.
Increasingly, we’re running our lives - living our lives - through computers.
This is certainly true for someone like me. I make my living writing software, working online with colleagues scattered across different countries. I need computers to make what I make, and to test what I make, and to communicate with the people that I make it with. The people who buy what I make need a computer to do it, and then a computer to use it.
I also happen to live in a relatively remote part of the UK, far away from many of my friends and family, and from most useful shops, sources of entertainment, etc. So computers are a big part of my non-working life too. I shop online, I communicate online, I get my music, my reading, my news, my entertainment online.
The fact that I can use computers to do so much ought to be a positive thing, and in many ways of course it is. They can do amazing things, and I can’t even count the number of aspects of day to day living that are quicker, easier, more efficient, or just downright saner when done electronically.
Having the BBC make its Panorama program all about Apple is tabloid sensationalism, and it sends out completely the wrong message.
It’s saying to companies who attempt, in however ineffectual a way, to do the right thing: “stick your head above the parapet, and we’ll monitor you twice as hard as all of your competitors, even though they are engaged in exactly the same practices”.
The exploitation of labour in poorer countries is a massive problem, but it’s also what the current free trade, free market economies of the richer countries are largely based on.
Our cheap consumer goods don’t appear like magic from nowhere. These things only cost what they do because the people who make them were paid a pittance to work too long in dangerous conditions, and the materials they were made of were sourced in a similarly dubious way.
I’m not saying that it’s somehow easy for us as individual consumers to combat this, but it’s completely hypocritical for anyone who owns a computer, tv, mobile phone etc to single out individual companies without examining the conditions in which their own possesions were produced.
The way to solve this problem is to regulate. We need to raise the burden of proof on manufacturers and sellers that the wares they are peddling have been produced ethically and sustainably. We then need to make it illegal to import and sell things that don’t meet the standard.
That is something that can only be done by governments, and it can only be done if the political will is there to do it.
Which comes back to voters.
Which means you.
A nice quote from the developers of SQLite, who have apparently got some serious performance improvements in their latest version:
The 50% faster number above is not about better query plans. This is 50% faster at the low-level grunt work of moving bits on and off disk and search b-trees. We have achieved this by incorporating hundreds of micro-optimizations. Each micro-optimization might improve the performance by as little as 0.05%. If we get one that improves performance by 0.25%, that is considered a huge win. Each of these optimizations is unmeasurable on a real-world system (we have to use cachegrind to get repeatable run-times) but if you do enough of them, they add up.
I have from time to time been accused of being too obsessed with seemingly trivial performance issues when writing everyday code.
There is an orthodoxy based around the concept of premature optimization which seems to encourage some people to believe that performance should be wilfully ignored when writing code, and only dealt with in an isolated step, using tools like Instruments, once all the dust has settled.
Even then, there is a tendency to focus on the low hanging fruit - the top few methods that show up in a profile - and to ignore the rest, or throw up one’s hands at the prospect of improving them. Small (or not so small) overheads that show up in all the code, such as those associated with message passing, memory allocation, and that sort of thing, can easily get overlooked. Similarly, the decision to aim for a particular programming style of idiom can sometimes overlook the fact that the choices they impose have consequences, like lots of dynamic allocation, or lots of memory copying, or lots of synchronisation, or hitting memory in the wrong order and screwing the cache.
I’m not saying that the basic premise of the premature optimization argument is wrong - far from it. It does make sense not to waste massive amounts of time doing insanely complex optimizations too early, on the wrong code. It does make sense to use tools to guide you, rather than guessing. It does make sense also to write clean code that makes your intent obvious.
Most of the time in any case the biggest improvements come from picking the correct algorithms, rather than in twiddling individual lines of your code.
What numbers like the ones quoted above show though, is that a large number of small improvements to performance can have a massive impact in aggregate. You shouldn’t obfuscate your code unnecessarily or obsessively, but if there are two ways to achieve the same aim, both of which are clean and easy to understand, and one of them is obviously more efficient in speed or space, then you’d be a fool not to choose it.
You can only make an informed decision about which implementation to choose if you have some basic awareness of performance and the implications of your choices. Aiming for a consistent style (functional, object-oriented, whatever) probably makes a lot of sense if it cleans up your code base and makes the whole thing easier to understand; but only if you acknowledge the impact is has.
It’s not wise to just defer even thinking about all this stuff until some mythical optimization phase later.
It definitely is wise to gain a basic understanding of how the building blocks of your language work, and roughly how the things on which you build are implemented, and to make decisions accordingly.
In case you’re wondering, the title of this post comes from the following quote by Herb Sutter:
Definition: Premature pessimization is when you write code that is slower than it needs to be, usually by asking for unnecessary extra work, when equivalently complex code would be faster and should just naturally flow out of your fingers.
A cautionary tale from Christoffer Lernö: To Swift and back again
Doesn’t inspire a great deal of confidence.
The big thing that worries me about Swift is the way that Apple’s culture (cult?) of secrecy meant that it was developed in a virtual vacuum, and not even widely dog-fooded within Apple.
Writing a new programming language is a bit like doing a cover of Stairway to Heaven. It’s the kind of thing every aspiring programmer wants to do, and the results usually range from mildly embarrassing to excruciatingly bad. To pull it off, you have to be fucking good.
There’s no denying the pedigree of Swift’s authors, but I actually think that a better name for the language might have been Hubris.