For people not involved in software development, programming and coding sound like the same thing — except they’re not, and it can be important to look at the differences. Coding is basically the process of writing code from one language to another, whereas programming is the process of developing a program so that human inputs and machine outputs are in sync.
In other words, programming deals with the bigger picture, while “coding is the easy part of programming,” Leslie Lamport told ZME Science during an interview at the Heidelberg Laureate Forum (HLF) in Germany, an annual event that brings together the world’s foremost mathematicians and computer scientists.
“Programming can be divided into roughly 3 sub-tasks. The first thing is deciding what the program should do. If you don’t think carefully about that, it’s going to wind up not doing something that it probably should do or you wind up with an ‘absolute bug-free program’. Because to have a bug, you have to have some notion of what it means for the program to be operating correctly. And there is no precise definition of what it means for the program to be correctly operating — so, well, no bugs. Not a very good situation,” said Lamport, who is best known for his seminal work in distributed systems and the development of the document preparation system LaTeX.
Leslie Lamport was the recipient of the 2013 Turing Award for imposing clear, well-defined coherence on the seemingly chaotic behavior of distributed computing systems, in which several autonomous computers communicate with each other by passing messages.
He loves clean code and good algorithms — and he loves to highlight the difference between the two.
“The second part is deciding how the program should do that. And that’s what I would call the algorithm level rather than the code level. If you take something like Euclid’s algorithm and you write Euclid’s algorithm in English, there’s no programming language involved. It’s an algorithm. It’s not a piece of code.”
“The easy part is taking that algorithm and encoding it in some particular programming language. But imagine trying to invent Euclid’s algorithm. If you were thinking about it in terms of code, you know, gee, should I have a procedure here? Should this be an assignment statement? You’d never discover Euclid’s algorithm.”
“So, you should be thinking about the algorithm — the basic how it’s done — before you start writing code.”
“You don’t understand something until you’ve written it down carefully — carefully enough to explain it to somebody else. And if you haven’t done that, you’re just thinking you understand it,” Lamport said at HLF 2019.
“The ‘what a program should do’ should be at a level of detail so that somebody could use the program just based on that description. They shouldn’t have to look at the code to see what the program does. It’s absolutely disgraceful that it has become common practice that if somebody writes a program and somebody else wants to use it, well, he has to read the code to find out what the algorithm does.”
So what can a programmer do to write more clearly and improve their software development skills? This is where TLA+comes in.
Lamport designed TLA+ as a set of tools for specifying and modeling algorithms. It consists of the TLA (Temporal Language of Actions) specification and PlusCal algorithm language, as well as a set of associated tools for writing and modeling. Many liken its use to drawing blueprints for software systems.
“Unlike most languages that engineers use, this is completely mathematical. My goal is, in addition to providing a tool that engineers can use to find errors in their designs, it also improves their thinking about the systems they’re building. Ultimately it leads them to build better systems,” Lamport said.
“By describing it mathematically, you’re able to get closer to the essence of what the algorithm is without having programming language constructs get in the way. It’s something that’s not easy for engineers to learn. Changing the way they think part — that takes time,” he added.
As an anecdote to illustrate the power of mathematical thinking in system design, Lamport once solved the algorithm for digital signatures — which form the backbone of secure online communications — on a piece of napkin.
Many software engineers are petrified of mathematical equations, but by Lamport’s reasoning, they’re doing a disservice to themselves by not employing mathematical thinking in their system design. Oftentimes, you don’t need code — you just need the algorithm.
Think of it this way: writing is a way of revealing how fuzzy your thinking is. In this context, coding is just a small part of programming where real thinking takes place.
The world needs good coders, and it also needs good programmers — and it’s better for everyone if we understand the difference between the two.
