"The Best Programming Advice I Ever Got" with David Chisnall
Be sure to check InformIT for a new article every Wednesday. See more advice from other programmers here.
Like this article? We recommend
Like this article? We recommend
Like this article? We recommend
Name
David Chisnall
Job Experience:
I've tried to avoid having a Proper Job, in the Keep the Aspidistra Flying sense, for most of my life. After finishing my PhD, I wrote a few books and did some freelance programming for a few years. I'm now back in academia at Cambridge University, working on a hardware-software co-design project, redesigning the hardware-OS-language interface for improved security.
Most Frequently Used Programming Language:
Depending on the day, Objective-C, C++, C, Smalltalk, Go, or something esoteric. A surprising amount of my time at the moment is spent with BlueSpec, a high-level hardware description language.
Advice:
The best programming advice that I ever had was not given in the context of programming, but at about the same time I learned to program. I started programming when I was 7, and the advice came from the math teacher who taught me when I was 9 and who sadly died a year later (this was not related to teaching me, although some of my later teachers commented that they were surprised that they survived the experience). She told me that mathematicians were lazy and, done well, mathematics should be as simple as possible.
Programming is closely related to mathematics. Kenneth Iverson's Turing Award lecture, Notation as a Tool for Thought, comes back to this same concept: that, by structuring the description of what you are doing concisely, you can simplify your life. Being lazy as a mathematician means the same thing as it does to a programmer: pick the right tool for the job, and if the right tool doesn't exist, invent it. Robert Recorde's invention of the equals sign was a very important example of laziness: it's less effort to write = than 'is equal to' every time. After a little bit of getting used to, it's also easier to read. In any symbolic algebraic expression, suddenly having complete English words in the middle breaks up the flow, as you have to realise that "is" is a word, and not an expression multiplying the values of i and s together.
Picking the correct language to express a problem is very important. This has motivated a lot of my work on cross-language interoperability and domain-specific languages over the past few years. I like using Smalltalk as a general-purpose high-level language, but if I'm writing some code that needs to do a lot of arithmetic or bit twiddling then I'd much prefer to sink to a lower-level language that makes it easier to express these things in a form closer to what will actually execute. Writing a parser in a general-purpose language is possible, but I'd much prefer to write it in something like OMeta.
Laziness in mathematics, as in programming, also means not solving the same problem twice. A huge amount of effort, from Structured Programming onwards, has gone into making sure that it's easy to reuse code. Late-bound, dynamic languages make this even easier, by making it easy to pull code from one project and use it with a completely different type of data elsewhere. All of my favourite languages (Smalltalk, Objective-C, Go) share this property: that it's easy to take code and reuse it without needing to modify it for its new environment.
The other piece of excellent advice I received was from the late Robin Milner. He said that the credit for an invention doesn't go to the first person to create something, but to the first person to explain it well enough that no one else needs to invent it again afterwards. This is especially true in computing in general, and programming in particular. Spending a little bit of time studying the history of a problem may mean that you find that someone else has already solved it. A lot of recent "inventions" in computing can be found in papers from the '70s and '80s.
It also serves as an important warning for new work. In the programming world, the simplest way of ensuring that no one needs to reinvent the same wheels as you is to package your code into a permissively licensed library. And, if you're lucky, you may find that the person who didn't have to waste a week redoing your work has instead spent it writing some code that you need...