Thinking for Programmers

Sign in to queue

Description

Leslie Lamport inventor of Paxos and developer of LaTeX introduces techniques and tools that help programmers think above the code level to determine what applications and services should do and ensure that they do it. Depending on the task, the appropriate tools can range from simple prose to formal, tool-checked models written in TLA+ or PlusCal.

Download:

Source Code

Tag:

Research

Day:

2

Code:

3-642

Room:

Room 3018

Embed

Download

The Discussion

  • User profile image
    deen

    Best session on this year`s Build so far for me.
    Nice reminder to look at solving problems first rather than sinking in code.

  • User profile image
    computerguy​0526

    @deen: I absolutely agree. This is probably one of the only sessions that I really looked forward to during the whole conference. I remember when I was a younger programmer, I always dived into code. I wish I hadn't done so.

  • User profile image
    nacho

    Amazing. Best session. I wonder what is he working at.

  • User profile image
    dtower

    It was a good talk and I enjoyed it. I'll admit that I still tend to dive into code without thinking sometimes. So it was a good reminder.

    I feel the presentation may have put some people out of their depth. When it delved into existential quantification several of the people around me reacted with confused laughter. So I think the quite rude response of the audience at the end when we couldn't ask questions because half of them were leaving at once wasn't an indication of the quality of the talk. I think it was just a reflection of the fact that many "programmers" these days don't have a CS background.

  • User profile image
    Bartosz

    Great, without a doubt!

  • User profile image
    Vinod

    not actual slides at the slides link.. please put up the slides..

  • User profile image
    Mitzi

    There are two kinds of mathematicians. Some see functions as sets of parameters and values. Some see them as parameters to be fed to other functions. So much about programming.

  • User profile image
    Matt

    Can we have the slides please? Thanks!

  • User profile image
    thealexdres​ko

    I definitely don't have a CS background, but I'm interested in this. What would be an appropriate path for learning about this stuff (and don't say college)? 

  • User profile image
    DLan

    The right slides are up now.  Thanks Mark!

  • User profile image
    briankel

    For folks who are looking for the slides, you will need to download this ZIP file. Inside that ZIP is a PDF file of the slides.

  • User profile image
    rstewart2702

    @thealexdresco, some places to look for self-study about these kinds of issues are books like _The Science of Programming_ by David Gries, if you're interested in learning about how to think about how imperative programs "move from one state to another." That book does a pretty good job of walking you through the principles of "mathematics" that Dr. Lamport was talking about: the kind of mathematical logic you need to do the kind of thinking that Dr. Lamport so graciously demonstrates in the first 20 minutes or so is, to some degree, codified and made very practical in Prof. Gries' book.

    The Bertrand Meyer book, _Object Oriented Software Construction_, tries to apply some of the same concepts to object-oriented programming, but it doesn't get so much in to the principles of predicate logic that the Gries book introduces at a more nuts-and-bolts level.

    For a great, very accessible introduction to the world of functional programming and the associated reasoning (also very important, and more and more important each day) take a look at _Introduction to Lambda Calculus and Functional Programming_ by Greg Michaelson, which is now a Dover book (which is fantastic, because it doesn't cost an arm and a leg!)

    Hope that helps,
    Rich Stewart

  • User profile image
    Nicolas​Dorier

    Most programmers don't have a CS background.
    And most CS scientist don't have a background in programming.

    I like his model of state and behavior and the difference between a math function and a programming function.
    But most of programs does not need proof.

    We prefer to throw at them an overwhelming amount of test data, and see how it goes.
    For his example on how he managed alignment rules, I would prefer reading his code than his lengthy description. (Given that he used better named variable than the classical x,y,z of CS programmers)

    Still, there is some interesting way to look at a problem in this talk.

Comments closed

Comments have been closed since this content was published more than 30 days ago, but if you'd like to send us feedback you can Contact Us.