Two talks I have watched recently, and which I both found enjoyable. Even though both speakers are key figures in the Lisp community, both talks are not about Lisp itself (even though the first talk uses it as a vehicle to show examples).

---

Gerald Jay Sussman, We really don't know how to compute http://www.infoq.com/presentations/We-Really-Dont-Know-How-To-Compute

I do really enjoy Sussman's talks, even more than the SICP book.

• Key points: Software Development's big problem is Evolvability, not Correctness. Alternative ways to think about program design (architecture, if you like) may open doors. Different examples are shown:
  • Symbolic differentiation using generic functions and a crazy mathematical trick.
  • Using propagator networks to resolve constraint systems with multiple numeric variables.

  Then using generics to use the same propagator network with interval values. Then propagating provenance of values along with the values.

Some math and basic Scheme programming is required for this talk. It makes you want to build a propagator network. In case you understood the first example, it probably makes you want to implement that as well. :-)

(A quick Google search showed that it might actually be described in the book "Structure and Interpretation of Classical Mechanics, of which Sussman is a co-author.)

---

Rich Hickey, Simple made easy http://www.infoq.com/presentations/Simple-Made-Easy

On the difference between simple and easy, what programming techniques Rich Hickey considers good based on that reasonsing. Interesting perspective on how to build abstractions and on components that have coupling even though they only speak to each other over interfaces.

• Take aways: "Easy" doesn't mean "simple", and "simple" doesn't mean "easy".
• Opinions I agree with: There's a balance between being able to prove a program and it being generic and flexible (e.g. usable in the real world).
• Opinions I am critical of:
  • Rich Hickey pokes fun at people who do testing and refactoring by comparing failing tests with running your car into a traffic barrier to stay on track. The argument is invalid, because in software testing, the car is of course only run into the traffic barrier within a controlled and isolated program setup. The other reason why it's incorrect — but that is my own anecdotal evidence only — is that without tests, I tend to run off track at some point, and it's just nicer to notice it. Software development is just harder to do than driving a car.
  • Objects are only meant to encapsulate driver software and we should manipulate all basic data structures (maps, sets) directly instead of encapsulating them. I disagree with this, but it's really hard to argue these things.

---

In case anyone decides to watch both talks, I suggest first watching the talk by Gerald Sussman, because it actually happened earlier, and Rich Hickey makes some references to it.