A Philosophy of Software Design | John Ousterhout | Talks at Google

> I'd rather get to value now by making something that just works(and is adequately tested) than engineer something thats future proof but takes longer to get out. If you haven't read it, I highly recommend A Philosophy of Software Design by John Ousterhout. His talk is a great teaser for the book: [this video] Here's the thing: a program properly written for the future does not take longer to get out. Not much, at least. What we instinctively think of as "future proof" is generally anything but: by anticipating some particular kind of change that may happen some time in the future, but in practice almost never does, we end up with more complex programs that are harder to modify when an actual (typically unforeseen ) change comes our way. The best way to future proof your program is to make it simpler , according to the requirement you are currently aware of. If you expect a particular change, sure, plan for it. But for the unexpected, just keep it simple. Because simple is easier to adapt, add to, or rewrite. That said, the simplest solution is rarely the most obvious. Making thing simple does take a bit more time than rushing through the first thing that comes to mind. But it also pays off in a matter of weeks, so it's quite worth it. And if you have a hard time assessing what "simple" means, SLoC is a surprisingly good metric (we have research that shows this). And mostly your modules should be deep: small APIs that hide significant implementations. I think of it as encapsulati

This google talk [this video] is a condensed version of the (already small - 150 pags IIRC) book. I highly recommend both. To the point made by the GP (and others here) about how useful the book is, I must add that I got a whole lot more from this small book than some other well known and oft suggested titles (like Clean Code, POSA etc). My most recent peeve about the matter is that Kent Beck"s "Tidy, Fisrt?" was apparently motivated partly in response to this book and yet it falls way too short to matching up. Half of thst book is way too simplistic and almost patronizing and the other is handwavy abstract notions too scared to touch reality lest it spoil the narrative.

You’re right re: it’s early internals, and we probably both know people who still (mistakenly) complain about that. Conceptually the “everything is a string”(EIAS) model still holds though, even though it’s supported by dual-ported “objects” w native representation, and the running is often byte-compiled instead of string parsing. We’ve got early smart fans who saw the vision and possibilities like Karl Lehenbauer, Don Libes, Richard Hipp, and the current core team like Kevin Kenny, Don Porter, Donal Fellows, etc who deeply understand What Tcl Is, and strictly maintain it, even while pushing it ahead (TclObj, finally an in-core blessed object system, native database framework, Miguel Sopher’s(RIP) work on the stackless non-recursive engine (NRE) and coroutines that fell out of that work... Back to Ousterhout though, you might dig his “Philosophy of Software Design”[0] book, or talks associated with it[1]. Lots to like in this space... [0] [link] [1] [this video]

I came into this thread hoping to find the suggestion near the top. Beyond his credibility as the creator of Tcl, in the talk he gave at Google about the book [1] he describes the course he teaches that was the inspiration for the book. The course is to write a word processor with a team and extended it with features over the semester, swapping codebases between teams so occasionally you have to work with other's code. Essentially the largest possible code project you can fit in one semester. Along the way, Ousterhout will give a deep code review of the each project. I think it must be very insightful to see the same project implemented so many ways, and to see what works in terms of simplicity and extensibility. [1] [this video]

I've been re-learning CS (programmed as a kid, then missed getting a minor in CS in college after the service by one 300-level course which wasn't being re-offered when I needed it) and then just did (La)TeX and AppleScript for my day job, but am now trying to create a tool for CNC which is quite different from those which have existed previously, and one thing which has helped a lot is MIT OCW: - the Python courses got me up-to-speed on the basics of that language: [link] and [link] - Structure and Interpretation of Computer Programs served as a disciplined review of a book which I wasn't patient enough to do the exercises of when I first read it: [link] - Mathematics for Computer Science helped make up for my spotty math: [link] I've also found the recent book: [link] very helpful (first reading I did one chapter at a time, re-writing my current project applying the principles of that chapter) --- interesting video overview at: [this video] If one is fortunate, there are videos on specific subjects/algorithms which one needs, e.g., [link]

This book has been my own personal technical revolution over the past few months. I've been programming professionally for 7 years now, so while I'm not the most experienced I'm certainly no one new either. Some takeaways from how it changed my flow: 1. It gave me specific goals in terms of my own improvement, and the chapter titles did a good job of being a stand-in for challenging my own intuition. 2. In mentoring other developers, those I shared some of the lessons in the book with saw huge improvement literally week over week. I saw, personally, one of my mentees go from producing code that was hard for me to step through without bringing up half a dozen issues, to producing code where my largest criticisms were ecosystem dependent. 3. It created common language for discussing with teammates why certain code felt wrong. 4. It significantly reduced time spent refactoring later. The subtleties in some of the points make a re-read valuable as well. One of the better examples of this, was "Make code just a little generic"- often, we attempt to code things as generic as possible, and end up making what is effectively code soup that doesn't help accomplish the problem. Instead, building specifically for this problem, but trying to spot places it can be made just a little bit more generic, has altogether eliminated times I know I would've had to refactor again later if I hadn't been thinking of it. 5. The book knows what it isn't. He even says right in the forward and on the rel

JO (John Ousterhout) is so thoughtful and lucid. My experience with him is firstly through Tcl, which I like more than he does now (time for a TIP: "-jo" switch to [unset] which removes complaint to unset non-existent variables)[0], and his book on it[1], and various papers. His work is at once both powerful and humble. Note in [0] how he without much emotion he suggests how Tcl came to be less prominent, and how even at Tcl's height, he explained without ego why it was there, and how it would leave[2]. His papers on threads[3] and comments on performance and testing[4] are also lovely reads. I encourage any developer or architect to read or re-read them. [0] [this video] (thx `quaunaut) [1] [link] [2] [link] (This is The Law, and it is good.) [3] [link] [4] [link]

Relevant recent discussion: • [link] (John Carmack on Inlined Code (2014)) • This comment, which contains a useful example: [link] Please let me know of any further discussion on the topic. (I'm also reminded of Ousterhout's advice in A Philosophy of Software Design that “classes should be ‘thick’” — see talk [this video] or (unrelated) slides: [link] ) One thing I see people miss in this discussion is that there's a tradeoff between having an individual function be understandable (shorter functions are easier to understand) having the entire codebase or interrelationships between functions be easier to understand (fewer functions are easier to understand). When there's an example presented like in the post, it's often presented as an example with a single function, and of course four short functions may each be easier to understand than a single function, but you've also added three nodes to the “graph” (of functions and calls between them) and now you need to study whether these functions are called from anywhere. To make up for this one may start introducing classes/objects to indicate “private”/“public” functions, and so on. (Some languages allow nested functions, which can help.) Most of all I'd say reading very different styles of code, and seeing how people achieve great things in unusual ways (e.g. with lots of abstraction, or with very little abstraction), can be an illuminating experience (see my comment in this thread about reading Knuth's programs).

Thanks for this! I remember watching a video on the philosophy of software design ( [this video] ) but I'll definitely need to re-watch/read, as well as check out the rest of his work. Do you have a suggestion on how the article title could be better? I came across Robert Martin's post while trying to build a better intuition for SRP, and it referenced the Parnas paper. So the title was really me thinking "What does this paper have to do with the SRP?", though the '1972' was both for convenience (e.g. "What does 'On the Criteria to be Used in Decomposing Systems' have to do with the single responsibility principle"? is too long) and intrigue. Perhaps "How a 1972 paper relates to the Single Responsibility Principle"? The Parnas paper wasn't one that Martin initially credited for the SRP as well (see [link] ), so I didn't feel comfortable claiming that it had direct influence (e.g. "The paper that influenced the Single Responsibility Principle").

> I'm not sure why you think that quoting random HN users proves anything except personal opinions of specific people? These are fine, but other people have other opinions. They support my argument so I included them. I don't see a practical difference between a "random HN user" and a random blog post or anything else. A good idea is a good idea, regardless of the medium. > I don't oppose the "principles" you've quoted, but they would just as easily apply to e.g. Haskell Possibly, I threw it together pretty quickly, so it's not very thought-out. > (maybe except for the "there's only one way to do it" which however has never been true of any language, including Python). It's not binary, but a spectrum. No language has just literally one way to express each concept. However, Python is definitely further towards the "one way to do it" end of the scale. Perhaps not as much these days as it used to, but still far more than for example Ruby or Perl. > I feel like you missed my larger point. It's not terribly difficult to write code that you can understand line by line. It's incredibly hard to write a huge code base in a way that you can reason about many code paths simultaneously, however. That's where the abstractions start to make sense. I thought I adressed that; everything I mentioned - explicit error returns, pure functions, no global state, and no metaprogramming - all show their true worth in large and/or unfamiliar codebases. > I don't understand why people think that those