Part of the Twenty Books in Twenty Days series.
Sometimes confused with the also excellent Programming Pearls, Programming Perl [affiliate link] is quite different. It’s big and well written and well structured. But a lot of books meet those criteria, so in what sense did it have an impact on me?
It’s a technical book that proves that you don’t need to be dry and boring to get the message across. Being “professional” doesn’t mean being humourless.
You know that thing were you’re trying to debug a problem and you just know that you’re the culprit, that past-you did something stupid, and you just can’t figure out what?
Welcome to my day.
Anyway, I’m documenting my stupidity so you don’t have to suffer as long as I did.
The background: in order to debug an application that runs on a cluster can be a challenge. The way I tend to do it is to run a server in debug mode in my IDE and connect to that same server using a client. The server is super-simple:
The background story: I’m preparing to deliver a training course. Each module of the course is in a different PowerPoint deck and, once I finished, I need to export each of them as a PDF to share with delegates. There are about twenty modules so doing this wouldn’t take that long but I would probably consider using the word “mind-numbing” to describe the process.
In hindsight, I’m not sure that writing VBA code to automate it was significantly less mind-numbing, but I’m sharing it here so you don’t have to.
Every year I try to complete the Advent of Code. Every year I fail to finish. I get about halfway through, and the exercises start taking longer to complete than I have time.
Every year I think about Jon Bentley’s Programming Pearls1, because the same kinds of challenges you find in Advent of Code can be found in the book. The main difference being the quality of the answers. At least in my case2. In the words of the preface: “Programming pearls whose origins lie beyond solid engineering, in the realm of insight and creativity.”
The whole team got this email today. Okay, it wasn’t today and these are not the exact words, but it was something like this:
We have a serious regression in build 456. We have set the project back rather than taken it forward. We need the utmost focus and commitment on fixing it. We’ve broken it and we stay in the office until it’s fixed.
I’ve had a few of those messages over the years and while it’s intended to focus minds it often has the opposite effect. Let’s examine why.
This is probably the geekiest book I’ve read in a long time. It’s basically one step up from reading the source code for your favourite operating system. Or perhaps having a favourite operating system.
What I would say is that Unix has been pretty much the only constant throughout my career. I started with Solaris and HP-UX at university. I installed an early version of Linux on my personal machine to avoid the thirty-minute walk from home to the university labs. I’ve done consulting, I’ve developed both vertical and horizontal applications1, C and C++, Swift and Java, banking and telecoms. Pretty much the only thing they’ve all had in common was some sort of Unix underpinning.
Preamble: In pre-Swift and pre-ARC days of development on Apple’s platforms, it was necessary to “manually” retain and release objects as you used and discarded them. One common, but incorrect, pattern that kept reappearing was the idea that you could use the retainCount method to ascertain whether an object was still being used.
There’s pretty much never a good reason to use -retainCount. Here’s a short and mildly abusive explanation why.
Graham Lee’s “Why is programming so hard?” made me think about how I started programming and whether I’d be coding now if I was twelve.
When I began, I had a Sinclair Spectrum. Back then, home computers booted into a programming language (BASIC typically) and to do anything you needed to know at least one command. To be fair, even then many people didn’t get beyond J, Symbol Shift-P, Symbol Shift-P (‘LOAD “”‘, the command used to load a program from tape).
If you look at the Swift Language guide, you get the distinct impression that the type system is sleek and modern. However the more you dig into it the more eccentricities you find.
The one I’m going to look at today makes sense only if you look at the problem domain from a slightly skewed perspective. I’ve been trying to think whether this is a sensible, pragmatic way of designing a language or a mistake. Judge for yourself.
I’m seeing a surprising amount of vitriol aimed at Swift, Apple’s new programming language for iOS and Mac development. I understand that there can be reasoned debate around the features (or lack thereof), syntax and even the necessity of it but there can be little doubt about the outcome: if you want to consider yourself an iOS developer, it’s a language that you will need to learn.
The only variable I can think of is when you learn it.