oh no, that's the title of a book I wanted to write 😄

Ah well, good luck! I didn't get very far with it yet, and will find another title. Had a neat intro playing with that title though 😄

Thanks

Thank you for responding to my feedback last episode. I was a little worried that my response was so long nobody would read it.

I'm not sure how to respond when you ask me to give you the same kind of respect that I extend, and encourage others to extend, to people like Licklider, Engelbart, Naur, or Brooks, especially when you are asking me to respect your decision to disrespect them. It is possible that I am mistaken or ignorant here, but I am unaware of any reason to believe that either of you have had a hand in crafting the fundamental nature of modern computing or the way that our entire industry views it.

I do not mean this as an insult, since it also applies to almost every other person who has ever lived as well. I do think it's important to remember, and be sensitive to, the level of genius one is reading when deciding whether and how to criticize.

I have no idea how popular your podcast is. I'm thrilled that you are bringing additional attention to these papers, no matter the size of your audience, but I worry that your casual disrespect during prior episodes could cause your listeners to discount the importance of the papers or their authors.

That said, I have no reason to believe that the authors of Out of the Tar Pit deserve any special consideration, so I don't particularly care about how you treated this one.

I think you are joking about making an episode about Intercal, but now that I heard you say it I have a strange desire to listen to it.

Although the structured programming movement ultimately degenerated into "don't use goto," for what it's worth, papers by Peter Naur (Proof of Algorithms by General Snapshots, Programming by Action Clusters), Tony Hoare (An Axiomatic Basis for Computer Programming), and Edsger Dijkstra (Notes on Structured Programming) were pushing the idea of making programs easier to reason about a long time ago.

A big downside of purely functional programming is that it can interfere with modularity. See The Art of the Interpreter or, The Modularity Complex by Guy Steele and Gerald Sussman.

With respect to trying to reduce complexity, but only measuring some of the dimensions, while I intensely dislike C++, I have a great deal of respect for Bjarne Stroustrup. He has done an amazing job of achieving his design goals, and I really appreciate his observation that "complexity has to go somewhere." I believe he is implicitly referring to essential complexity here.

m.slashdot.org/story/10028

With respect to the challenge of creating a type of programming that informal reasoning cannot help with, Peter Naur pointed out in Formalization in Program Development that all formal reasoning is ultimately defined in terms of informal reasoning, so while I cannot prove it formally, I don't think it's possible to create a system that is not dependent on any informal reasoning.

Hiding state is the basis of encapsulation in the Parnas sense (On the Criteria To Be Used in Decomposing Systems into Modules) and modularity in the Sussman/Steele sense above. Trying to make all state visible might make it easier to design and play with small systems, but I'm not sure how it can coexist with encapsulation and modularity.

For a differing view on the "power corrupts" thesis, in Why Software Jewels are Rare, Parnas notes "Moreover, languages that prevent programming errors, a goal advanced by some inveterate language designers, are as feasible as knives that can cut meat but not hands. We need sharp tools to do good work."

researchgate.net/publication/2954521_Why_software_jewels_are_rare

Also, "Unix was not designed to stop you from doing stupid things, because that would also stop you from doing clever things." -- Doug Gwyn

With respect to creating programs that retain their conceptual integrity when the problem they are solving changes, I am fond of both Dijkstra's string of beads / hierarchy of virtual machines (Notes on Structured Programming) and the Structure and Interpretation of Computer Programs (SICP) model of bottom up design, where you essentially design a language for solving the kind of problem you are facing, and then solve your particular problem in that language. Of course, there's always the possibility that your problem changes in the future to be of a sufficiently different kind that you end up needing to adjust more than just the top layer.

Overall, although I haven't read this paper and am going purely by what you said in the podcast, my sense is that the authors didn't have much new to say. I'm not clear on how this became such a popular paper in recent times.