4 ms·

An interview with Leslie Lamport (creator of Latex, Paxos, etc.)

52 points by Maro 18y ago

davidw 18y ago
A bit old, but a nice catch! I liked this bit: > Write a book based on a selection of distorted anecdotes showing that instincts are superior to rational judgment and you get a best seller. Imagine how popular a book would be that urged people to engage in difficult study to develop their ability to think so they could rid themselves of the irrational and often destructive beliefs they now cherish. So, trying to get people to think is dangerous. Over the centuries, many have been killed in the attempt. Fortunately, when applied to programming rather than more sensitive subjects, preaching rational thought leads to polite indifference rather than violence. However, the small number of programmers who are willing to consider such a radical alternative to their current practice will find that thinking offers great benefits. Spending a few hours thinking before writing code can save days of debugging and rewriting. I'm not sure I agree, though, ultimately. Sometimes too much up-front thinking about big huge complex systems is just not possible or productive. It's better to get in and start interacting the system, as that can also drive a more thorough understanding of the system.
- gustavo_duarte 18y ago
  But he did say 'a few hours'. That sounds about right to me.
  - davidw 18y ago
    Ok, but he's talking about it in the context of attempting to write provably correct programs.
yan 18y ago
Lamport clocks is one topic that stood out most prominently in everything I took away from my excellent distributed systems class. I have no idea why, but the second I heard "Lamport clock," it got etched into my brain forever.
trjordan 18y ago
Nice! I particularly liked the bit about Butler Lampson being the first to understand Paxos, mostly because I'm current in his distributed and concurrent systems class. It turns out that when Lamport wrote the paper The Part-Time Parliament, Lampson told him that nobody actually understood it. To prove him wrong, Lamport called a few colleagues and asked them a few elementary questions about the algorithm. They all got it wrong. That prompted him to write Paxos Made Simple. It's good to know that it's not always my fault when academic papers are entirely inscrutable.
- aston 18y ago
  Well, out of fairness, The Part-Time Parliament is a story about a fake Greek society, replete with "Greek"-style reinterpreted names for researchers Lamport wanted to name check. Extended metaphor is not the standard academic approach. Not to mention, the math behind the paper is kind of beyond the grasp of most on the first few readings. http://research.microsoft.com/en-us/um/people/lamport/pubs/lamport-paxos.pdf http://research.microsoft.com/en-us/um/people/lamport/pubs/l...
  - Maro 18y ago
    "The Paxos algorithm, when presented in plain English, is very simple." The abstract of 'Paxos Made Simple'. You have to appreciate the humor =)
jinx 18y ago
My take away from the interview was "You should comment code before you write it." I am going to try it on my code and see how it works out.
- gustavo_duarte 18y ago
  Steve McConnell advocates a similar thing in Code Complete 2, which he calls Pseudocode Programming Process, PPP. The idea is that when first creating a method or function, you write out in comments what you're going to do in a 'why' level (eg, 'keep track of resources') rather than a 'how' level (eg, 'increase cntFooBar by 1'). You then start 'filling out' the code to do what you 'designed' via the comments. Hopefully you end up with a better designed routine, and you get free comments to boot as they now explain what the code is doing. When I first read Code Complete as an impressionable teenager I tried it out and liked it, but I have since had a change of heart on this issue and other Code Complete wisdom. I rarely comment inside methods anymore.
  - derefr 18y ago
    > You then start 'filling out' the code to do what you 'designed' via the comments. Another approach is to just drop the comment markers entirely, massage the pseudocode until it's valid syntax, and then write a DSL that does the right thing upon its execution. That way, all you ever really have is comments.
- gaius 18y ago
  This is called 'literate programming'.
- etal 18y ago
  It is a good approach. The PLT Scheme textbook How to Design Programs walks you through a process for writing new code that more or less goes like that: 1. Write a comment describing the problem. 2. Write comments describing the form of all the data structures involved in the problem, and turn those comments into data definitions. 3. Then write a comment describing the input and output of a function, write the function header, use the form of the data structures defined above to sketch a function body with comments and a few bits of code; repeat for each operation. 4. Finally, fill in the gaps -- at that point it's almost obvious how each function should be written.
wingo 18y ago
I seem to recall from the Chubby lock paper the statement: "we have found Paxos behind everything". Of course they expressed it more eloquently. I think the Paxos papers are among the most beautiful in computer science.

52 points by Maro 18y ago

A bit old, but a nice catch! I liked this bit: > Write a book based on a selection of distorted anecdotes showing that instincts are superior to rational judgment and you get a best seller. Imagine how popular a book would be that urged people to engage in difficult study to develop their ability to think so they could rid themselves of the irrational and often destructive beliefs they now cherish. So, trying to get people to think is dangerous. Over the centuries, many have been killed in the attempt. Fortunately, when applied to programming rather than more sensitive subjects, preaching rational thought leads to polite indifference rather than violence. However, the small number of programmers who are willing to consider such a radical alternative to their current practice will find that thinking offers great benefits. Spending a few hours thinking before writing code can save days of debugging and rewriting. I'm not sure I agree, though, ultimately. Sometimes too much up-front thinking about big huge complex systems is just not possible or productive. It's better to get in and start interacting the system, as that can also drive a more thorough understanding of the system.

gustavo_duarte 18y ago
But he did say 'a few hours'. That sounds about right to me.
- davidw 18y ago
  Ok, but he's talking about it in the context of attempting to write provably correct programs.

yan 18y ago

Lamport clocks is one topic that stood out most prominently in everything I took away from my excellent distributed systems class. I have no idea why, but the second I heard "Lamport clock," it got etched into my brain forever.

trjordan 18y ago

Nice! I particularly liked the bit about Butler Lampson being the first to understand Paxos, mostly because I'm current in his distributed and concurrent systems class. It turns out that when Lamport wrote the paper The Part-Time Parliament, Lampson told him that nobody actually understood it. To prove him wrong, Lamport called a few colleagues and asked them a few elementary questions about the algorithm. They all got it wrong. That prompted him to write Paxos Made Simple. It's good to know that it's not always my fault when academic papers are entirely inscrutable.

aston 18y ago
Well, out of fairness, The Part-Time Parliament is a story about a fake Greek society, replete with "Greek"-style reinterpreted names for researchers Lamport wanted to name check. Extended metaphor is not the standard academic approach. Not to mention, the math behind the paper is kind of beyond the grasp of most on the first few readings. http://research.microsoft.com/en-us/um/people/lamport/pubs/lamport-paxos.pdf http://research.microsoft.com/en-us/um/people/lamport/pubs/l...
- Maro 18y ago
  "The Paxos algorithm, when presented in plain English, is very simple." The abstract of 'Paxos Made Simple'. You have to appreciate the humor =)

jinx 18y ago

My take away from the interview was "You should comment code before you write it." I am going to try it on my code and see how it works out.

gustavo_duarte 18y ago
Steve McConnell advocates a similar thing in Code Complete 2, which he calls Pseudocode Programming Process, PPP. The idea is that when first creating a method or function, you write out in comments what you're going to do in a 'why' level (eg, 'keep track of resources') rather than a 'how' level (eg, 'increase cntFooBar by 1'). You then start 'filling out' the code to do what you 'designed' via the comments. Hopefully you end up with a better designed routine, and you get free comments to boot as they now explain what the code is doing. When I first read Code Complete as an impressionable teenager I tried it out and liked it, but I have since had a change of heart on this issue and other Code Complete wisdom. I rarely comment inside methods anymore.
- derefr 18y ago
  > You then start 'filling out' the code to do what you 'designed' via the comments. Another approach is to just drop the comment markers entirely, massage the pseudocode until it's valid syntax, and then write a DSL that does the right thing upon its execution. That way, all you ever really have is comments.
gaius 18y ago
This is called 'literate programming'.
etal 18y ago
It is a good approach. The PLT Scheme textbook How to Design Programs walks you through a process for writing new code that more or less goes like that: 1. Write a comment describing the problem. 2. Write comments describing the form of all the data structures involved in the problem, and turn those comments into data definitions. 3. Then write a comment describing the input and output of a function, write the function header, use the form of the data structures defined above to sketch a function body with comments and a few bits of code; repeat for each operation. 4. Finally, fill in the gaps -- at that point it's almost obvious how each function should be written.

wingo 18y ago

I seem to recall from the Chubby lock paper the statement: "we have found Paxos behind everything". Of course they expressed it more eloquently. I think the Paxos papers are among the most beautiful in computer science.