I've watched these videos countless times. I do it because each viewing tends to shed light on whatever problem I'm facing at the time. Alan Kay provides perspective on systems building, Bret Victor on computer-assisted thought, Gerald Sussman on software engineering, Jonathan Blow on the psychology of interaction, and Rich Hickey on coding.
These lectures don't have all the answers, but I think they point us in interesting directions!
https://www.youtube.com/watch?v=O3tVctB_VSU
Sussman points out that in order for the future to happen, we'll eventually be buying processors by the bushel and laying them down like concrete to create smart walls… but we have no idea how to write software for computers like that. In particular, biological systems take advantage of that structure to achieve latency and self-organization that we don't know how to do with software yet.
For example, he displays an optical illusion and notes how quickly people can process the image:
“That's only a few tens of neuron times. I don't care how parallel the machine is, I don't have the foggiest idea how to write a program that organizes a complex process like that in a latency of about 30 or 40 steps.” (1:10)
He also points out that a salamander will grow additional elbows if you rearrange the segments of its legs, but we don't have anything like in today's software.
The bulk of the talk is about “minimizing the cost of changing decisions we've made” (i.e. making software easier to repurpose). We need to consider as many ways as possible to do this, he says, and at 25:10, he presents propagators as one possibility. Propagators are a massively parallel form of computation that he worked on with Stallman (who wrote the original version) and his students.
Short introduction to propagators (detailed description in the references below):
The idea is that you could create many ways of computing the same value, of varying accuracy and performance, execute all of them in parallel (remember you bought processors by the bushel), and let the propagator network resolve to the best possible answer.
A separate premise could be assigned to each method of computing the value, so that if one or more turn out to be contradictory, their results can be thrown out. Synchronization isn't a problem because the only mutation of information that's allowed is to make a value more precise, so the order of mutations doesn't affect the final result.
An awkward aspect to this talk is that Sussman seems repeatedly disappointed by how easy it is to impress the audience. At various points, he works through example problems using the kind techniques that most people forget a few years after learning: automatic differentiation (15:09), Lagrange equations (18:58), and calculating voltage from a circuit diagram (26:10). After speeding through the Lagrange example, he becomes impatient with the applause. He asks, “What did I say? That's easy stuff.” When the audience laughs at that, he continues, “No, I mean it!”
All the lecturers on this page at some point express disappointment in their audience for lacking crucial knowledge. Usually that knowledge is the content of seminal computer science research papers. But I think that conflict is probably most apparent in this talk—second only to The Future of Programming, for which it is the premise…
“Nothing brings fear to my heart more than a floating point number. Numerical analysis is the blackest art I know.” (11:15)
“I want a program to compute up what it's gonna do. Remember in the old days when you used to program in assembly language or something—at least I used to do that. Yeah, it was a great language because you could write the next instruction you were gonna execute. You could put it into the place you were gonna go to. It just was. Many interesting programs were written that way, and it was very flexible. There's too many fearful people. I can see a lot of people cringing.” (11:55)
“Mathematical notation is both awful and, it turns out, ambiguous. To be perfectly honest, it's impressionistic. … The reason why you can understand me is we're almost all identical. Only a few bits have to be transferred in order to get an idea across.” (16:15)
“Putting us into the situation that Mr. Dijkstra got us into about 30 years ago or 40 years ago—where you're supposed to prove everything to be right before you write the program—getting yourself into that situation puts us into a world where we have to make the specifications for the parts as tight as possible because it's hard to prove general things (except occasionally, it's sometimes easier …), so you make a very specialized thing that works for a particular case and you build this very big tower of stuff, and boy is that brittle! Change the problem a little and it all falls over.” (22:23)
“That's an implementation question. It's a question like the difference between applicative order and normal order in lambda calculus. … We can make machines do it any way we like, and we can have policies that can allow you to do both. Remember, a real engineer doesn't want just a religion about how to solve a problem, like object-oriented, or functional, or imperative, or logic programming. This piece of the problem wants to be a functional program. This piece of the program wants to be imperative. This piece wants to be object-oriented. And guess what, this piece wants to be logic-based. And they all want to work together usefully. And that's because of the way the problem is structured, whatever it is. And I don't wanna think that there's any correct answer to any of those questions. It would be awful bad writing a device driver in a functional language. It would be awful bad writing anything like a symbolic manipulator in a thing with complicated syntax. It's awful bad to write a numerical program in anything but Fortran.” That last bit was a joke. 😉 (38:39)
“Almost all the information in my head is inconsistent. I believe lots of things that are false. We all do. But the important thing is that I don't fall apart every time I think … Why? It's because if I run into one of these inconsistencies, I giggle. That's the answer. It's because I can keep apart locally consistent subsystems of my thinking, and each of those I can make deductions that I know where they come from (I hope) and they're dependent only on the things that I specify.” (50:11)
“Search is always exponential and will always eat you if you let it.” (57:34)
https://www.youtube.com/watch?v=YyIQKBzIuBY
TODO: Insert notes here.
https://www.infoq.com/presentations/Simple-Made-Easy
The point of the talk is to (re-)define a few words in the engineering lexicon:
Armed with this definition of “simple”, Hickey invokes Dijkstra, who said “simplicity is a prerequisite for reliability.” Hickey contends that reliabile software for the user is far more valuable than software that's easy to write. Hence, we should be willing to invest more in making our software simpler than we tend to.
He's careful throughout the talk to say that simpler is better without saying that complex things are bad (except ORM). As he puts it:
“There are reasons why you might have to [use a complex construct], but boy, there's no reason why you shouldn't start with [a simple one].” (47:12)
The most interesting part of the talk for me is his analysis of the simplicity and complexity of many easy ideas in computer science. I didn't realize how useful the more precise definitions above were until he revealed their utility with this analysis. Here are a few examples:
State complects value and time. “You don't have the ability to get a value independent of time.” State complects everything that touches it.
refs are simpler because they provide abstractions of time, and have ways of getting immutable values out. In that way, they're closer to composing value and time than complecting them.
He also provided some of the best software design advice I've ever received: When you're trying to create something simple, ask yourself who, what, where, when, why, and how? The fewer of those questions that have fixed answers, the simpler the end result.
For example, when you design an operation, your goal is to answer what is being accomplished without complecting that answer with how is it accomplished. Usually that means writing functions that operate on typeclasses, which allows the what to delegate the how away.
Hickey uses fold as an example of the incidental complexity you might end up with if you're not careful. Ideally, fold's caller could specify the order in which the values are reduced, where the computation occurs, etc, but fold complects how the values are reduced with the simpler job of reducing several values to just one.
“I can't read German. Does that mean German is unreadable? No. I don't know German! … If you want everything to be familiar, you will never learn anything new.” (6:50)
“What's true of every bug found in the field? … It passed the type-checker! … It passed all the tests! … I think we're in this world I like to call ‘guardrail programming.’ Right? It's really sad. We're like ‘I can make changes 'cause I have tests.’ Who does that? Who drives their car around banging against the guardrails, saying, ‘Whoa, I'm glad got these guardrails, 'cause I'd never make it to the show on time!’ Right? And do the guardrails help you get to where you want to go? Like, do guardrails guide you places? No, there's guardrails everywhere. They don't point your car in any particular direction.” (15:44)
“What kind of runner can run as fast as they possibly can from the start of a race? [audience: sprinters!] Right, only someone who runs really short races. But of course, we're programmers, and we're smarter than sprinters, apparently, because we know how to fix that problem. We just fire the starting pistol every hundred yards and call it a new sprint!” (17:27)
“You have to start developing sensibilities around entanglement. You have to have entanglement radar. You wanna look at some software and say ‘Ugh!’ Not that I don't like the names you used, or the shape of the code, or there was a semi-colon… That's also important too, but you want to start seeing complecting. You want to start seeing interconnections between things that could be independent.” (59:10)
https://www.youtube.com/watch?v=gTAghAJcO1o
TODO: Insert notes here.
https://www.youtube.com/watch?v=agOdP2Bmieg
TODO: Insert notes here.
https://www.youtube.com/watch?v=ZfytHvgHybA
TODO: Insert notes here.
https://www.youtube.com/watch?v=J_aREO4OcZg
TODO: Insert notes here.
https://www.youtube.com/watch?v=SqFu5O-oPmU
TODO: Insert notes here.