A brief summary: * Nowadays, we have the concept of interfaces to achieve modularity and local reasoning * Liskov's initial contribution: partition global var

A brief summary: * Nowadays, we have the concept of interfaces to achieve modularity and local reasoning * Liskov's initial contribution: partition global variables, require functions to only use variables in their partition or call functions in other partitions. * Use data abstraction as a methodology (later on, use object orientation as the target of that methodology) * She created CLU to communicate some of these abstractions to programmers: 1. Procedures are attached to types, not objects, 2. Parametric polymorphism: if quantification is needed, use structural subtyping, essentially, 3. For loops: use iterators with state stored on the stack (generators) * When looking at object orientation in this context, she found that inheritance was widely used, both for interface/implementation and for type hierarchies. In both cases, semantics are important, even if two objects implement the same methods by name/types. Came up with Liskov substitution principle. * Trends today: one of the issues with e.g. Java, C# is that they're not great for beginners who are forced to work around crufty abstractions (public static void main) without having the experience to know how to generally use those abstractions. On the other hand, Python is great for beginners but (according to Liskov) doesn't have great data abstraction for large-scale software engineering. * Some perceived tradeoffs in a language that is good for both beginners and experts: 1. Ease of use vs expressive power, 2. Readability vs writeability (Liskov is worried about too much focus on the latter), 3. Modularity and abstraction, 4. Powerful abstraction matters, 5. State matters (see below) * Finally, for massively parallel computers: how to do programming methodology? That's what I thought to write down. I also thought to take a more precise transcript of her comments on Haskell: > My final thing, which is in some sense aimed at Haskell, is that state matters. So, mostly computer programs are about managing state. And, although I am very sympathetic with the desire to keep most of your program immutable, because it's much easier to reason about correctness if you aren't doing modifications, a major part of your program is going to be concerned with state, and it has to be done in a simple way. It can't be complicated, it can't be hard to understand. State is one of the most important (and sometimes annoying) things you deal with in Haskell when writing large programs. However, is it really better to sweep it under the rug and muddy semantics in the name of simplicity? One might merely just be pushing essential complexity to where it is harder to reason about.