John Ousterhout

Not specifically this, per se, but I HIGHLY recommend "A Philosophy of Software Design" by Dr. John Ousterhout https://web.stanford.edu/~ouster/cgi-bin/book.php

This is one of my favorite pieces of software engineering because it took something difficult and tried to design something easy to understand as a main criteria for success. The PHD Thesis has a lot more info about this if anyone is curious, it is approachable and easy to read: https://web.stanford.edu/~ouster/cgi-bin/papers/OngaroPhD.pdf I think this was core to Raft’s success, and I strive to create systems like this with understandability as a first goal.

When I had contact with TCL for a networking class in the 90's I already knew Python and didn't like that "everthing is a string" pathos. For me the greatest TCL contribution was Ousterhout's dichotomy: https://en.wikipedia.org/wiki/Ousterhout%27s_dichotomy or by the author himself: https://web.stanford.edu/~ouster/cgi-bin/papers/scripting.pdf

TFA mentions the Sprite operating system, which brought us a few things, including (i recently discovered), pmake[0] (by way of Adam de Boor[1]) which was an early instance of parallelizing make(1), and begat BSD Make[2], which is lovely to use. [0] https://web.stanford.edu/~ouster/cgi-bin/spriteRetrospective.php [1] https://www.linkedin.com/in/adam-de-boor-4293a1/ [2] https://man.netbsd.org/make.1

John Ousterhout also was leading a project called RAMcloud (I thought was interesting) that the article doesn't mention - [1], [2]. Also, he has a book on s/w design [3] which is short and nice, and is more of a collection of ideas rather than an approach, which I highly recommend. [1] RAMcloud talk by J. Ousterhout:https://www.youtube.com/watch?v=lcUvU3b5co8 [2] RAMcloud paper: https://web.stanford.edu/~ouster/cgi-bin/papers/ramcloud.pdf [3] A Philosophy of Software Design, https://www.amazon.com/Philosophy-Software-Design-John-Ousterhout/dp/1…

John Ousterhout, Carson Gross (htmx, https://grugbrain.dev), and Rich Hickey are my favorite people on complexity. John Ousterhout was notably my professor for operating systems @ Stanford. He taught not just ways to design software, but also ways to live. Carson’s work is also directly influenced by Ousterhout, as referenced at the end of his article. For John Ousterhout, I suggest looking at the class website: https://web.stanford.edu/~ouster/cs190-winter23/ For Carson Gross, I suggest his book, Hypermedia Systems: https://hypermedia.systems/

I found this book in my local library when I was in college, it was a really fun read. I had recently finished the OS course which used PintOS[1] and wanted to learn more about the development process. Unfortunately my C is still fairly rudimentary, and at this point it's going to be a bit longer before I attempt to follow Linus's path. 1: https://web.stanford.edu/~ouster/cgi-bin/cs140-spring20/pintos/pintos_…

He also wrote one of my favorite software books https://web.stanford.edu/~ouster/cgi-bin/book.php. Presentation https://youtu.be/bmSAYlu0NcY

If you liked this interview do not miss J. Ousterhout's broader "Favorite Sayings" ( https://web.stanford.edu/~ouster/cgi-bin/sayings.php )

Ousterhout is the author of one of my favorite programming-related books, A Philosophy of Software Design. It is remarkably concise and practical. I re-read it whenever I sometimes fall into as it reminds me design and craftsmanship are the most important aspects of building great software. https://web.stanford.edu/~ouster/cgi-bin/book.php

I'm partial to John Ousterhout's "The greatest performance improvement of all is when a system goes from not-working to working". <https://web.stanford.edu/~ouster/cgi-bin/sayings.php>

I think John Ousterhout's recommendation of 'thin' interfaces and 'thick' implementations is a good heuristic that's worked well in my experience. This acts as a force that resists service proliferation that hides behind "modularity". https://web.stanford.edu/~ouster/cgi-bin/cs190-spring16/lecture.php?to…

This paper is a followup to: * J. K. Ousterhout. "Why Threads Are A Bad Idea (for mostpurposes)". (http://web.stanford.edu/~ouster/cgi-bin/papers/threads.pdf) * V. S. Pai, P. Druschel, and W. Zwaenepoel. "Flash: An Efficientand Portable Web Server". (https://www.usenix.org/legacy/events/usenix99/full_papers/pai/pai.pdf) * M. Welsh, D. E. Culler, and E. A. Brewer. "SEDA: An architecturefor well-conditioned, scalable Internet services". (http://www.sosp.org/2001/papers/welsh.pdf) Those are some of the more influential papers in the development of event-driven designs.

This paper by John Ousterhout (creator of Tcl) is a good read if you think Tcl is a weird language plagued by bad design decisions. If that describes you, it's probably the case that you don't understand the problem Tcl was designed to solve. https://web.stanford.edu/~ouster/cgi-bin/papers/tcl-usenix.pdf

My favorite saying form John Ousterhout: > What's Wrong With Threads? > Too hard for most programmers to use. > Even for experts, development is painful. I read the slides for his presentation "Why Threads Are A Bad Idea (for most purposes)" [1] in the late 90s and it saved me from a lot of confusion in the following decades. This was especially helpful in a time when Java peaked in popularity and people were like: "Hey, threads are cheap and easy now, what's the problem when our solution uses thousands of them?". [1] https://web.stanford.edu/~ouster/cgi-bin/papers/threads.pdf

Thanks for posting! The Projects page is a great read too: http://web.stanford.edu/~ouster/cgi-bin/projects.php

I teach at Stanford though not in CS. I think this headline is a bit off. There is a CS 106J class that follows the CS 106A curriculum using JS instead of Java, but as far as I know, the CS 106A Java curriculum has not been tossed out for the academic calendar of 2017-2018 (syllabuses aren't up yet, so I can't confirm). As the article states, CS 106J was spearheaded by Professor Roberts this past year. I would imagine it'd take some more time for it to become a curriculum that all of the profs teach, though JS is being used in several other CS classes. For example, CS 142: Web Applications, used to be taught with Rails: https://web.stanford.edu/~ouster/cgi-bin/cs142-winter14/index.php Now it's taught with MEAN (Mongo, Express, Angular, and Node): http://web.stanford.edu/class/cs142/info.html

I love this! I have done a lot of CS research lately, and some of these I haven’t come across yet. Let me share some of my favourites not listed here, off the top of my head: - Ian Piumarta’s “Open, Extensible Object Models” (https://www.piumarta.com/software/id-objmodel/objmodel2.pdf) is about creating the most minimal object-oriented metaobject system that allows the maximum amount of freedom for the programmer. It basically only defines a message send operation, everything else can be changed at runtime. The practical counterpart to the dense “Art of the Metaobject Protocol” book. - John Ousterhout “Scripting: Higher-Level Programming for the 21st Century” (https://web.stanford.edu/~ouster/cgi-bin/papers/scripting.pdf) - not really a paper, but an article from the creator of Tcl about the dichotomy between systems programming languages and scripting languages. Obvious at first sight, the lessons therein have wide ramifications IMO. We always seek the perfect multi-paradigm language that can do anything at high performance with the most productivity, while perhaps it is best to have compiled, fast, clunky systems languages paired with ergonomic, flexible interpreted frontend. Often all you need is C+Tcl in the same app. A must-read for anyone writing yet another programming language. - Niklaus Wirth's Project Oberon (https://people.inf.ethz.ch/wirth/ProjectOberon/) is the implementation of an entire computer system, from the high-level UI down to kernel, compiler, and…

I was the VP of Engineering of Ousterhout's spinout company, Scriptics, and worked for him. I don't know the story of how Sun made the decision but John has a longer History of Tcl here: https://web.stanford.edu/~ouster/cgi-bin/tclHistory.php "At the same time, it became clear that Sun needed to focus its language evangelism around Java, which was released shortly after I arrived at Sun and had become hugely popular. Though Java and Tcl are very different languages, used for very different purposes, it would have been too hard for Sun to evangelize both of them simultaneously. I came to the conclusion that, overall, Java offered more benefits for Sun than Tcl did." John was a great person to work for. He hired me despite the fact that in the interview with him I told him I'd never used Tcl and when he extolled its virtues he told me that it was "easy to learn and had powerful regular expressions" and I said "Don't those two things contradict each other?" He stopped talking and had a rather surprised expression on his face. I thought I'd blown it. Actually, I'd done the most important thing I could possibly have done: made him think something new.

From his website [0]: In July of 2021 I released the Second Edition of A Philosophy of Software Design. This edition is available on Amazon in both paperback and electronic form. There are only a few significant changes from the First Edition: - There is a new chapter "Deciding What Matters" that talks about how good software design is about separating what's important from what's not important and focusing on what's important. - Since the First Edition was published, the importance of choosing general-purpose approaches has become even more clear to me. I have reworked and expanded Chapter 6 ("General-Purpose Modules are Deeper") to reflect this, and I've moved some material from other chapters to Chapter 6. - I have added subsections in two chapters to compare the book's design philosophy with that of Robert Martin's Clean Code (we have significant differences of opinion on topics such as the length of methods and the role of comments). For the benefit of people who already purchased the First Edition, I have made copies of the two new chapters available in a book extract. It may not be worth buying the Second Edition if you already own the First Edition. [0] https://web.stanford.edu/~ouster/cgi-bin/book.php

"The greatest shortcoming of the human race is our inability to understand the exponential function." - Dr. Albert A. Bartlett That's the thesis of Dr. Bartlett's famous lecture "Arithmetic, Population and Energy": https://www.youtube.com/watch?v=sI1C9DyIi_8 Calculus is foundational for understanding our rapidly changing, data-driven world. It gives us the ability to see. You can apply calculus anytime you have a quantity that's changing over time, and you want to see where things are going, how things are changing, and when something is going to happen based on its rate of change -- e.g. stocks, startup growth metrics, how an idea is spreading, mass-market adoption, etc -- anytime you have time-series data and you want to see what it means -- make sense out of it, and understand its implications. See https://en.wikipedia.org/wiki/Calculus#Applications And Calculus gives you the ability to calculate how lifelong learning can impact your growth over time -- the significance it can have throughout your life/career -- and realize it's never too late to learn anything ;-) In the words of Prof John Ousterhout: "A little bit of slope makes up for a lot of y-intercept." https://web.stanford.edu/~ouster/cgi-bin/cs142-spring12/weekendThought…

> "Consensus is a problem that has plagued computer science phd’s for literally decades" No, not really. The Paxos paper was in 1989. One might reasonably argue that Raft is an improvement, but if so it's only an incremental one - not a cure for a "plague" as the author suggests. The problem with consensus for PhDs is not that Paxos doesn't solve it. The problem is that it is SO hard to understand. Notably, soon after Lamport's 1998 Paxos paper he published Paxos Made Simple[1] which noted The Paxos algorithm for implementing a fault-tolerant distributed system has been regarded as difficult to understand This paper was supposed to make it simpler, but it wasn't enough. When the Raft paper was release, the title was In Search of an Understandable Consensus Algorithm[2] which noted the following: most implementations of consensus are based on Paxos or influenced by it, and Paxos has become the primary vehicle used to teach students about consensus. Unfortunately, Paxos is quite difficult to understand,in spite of numerous attempts to make it more approachable. Furthermore, its architecture requires complex changes to support practical systems. As a result, both system builders and students struggle with Paxos I'd say that is reasonable evidence to suggest that, yes, consensus really has plagued computer science phd’s for decades. Additionally, I'd note that the famous maxim There are only two hard problems in computer science: Naming things and Cache Invalidation (and…

The entire premise of callbacks is that threads were a mistake because they broke sequential reasoning and control. JK, obviously callbacks became prominent as a result of folks looking for creative solutions to the C10K[0] problem, but threads have a long history of haters[1][2][3]. [0] https://en.wikipedia.org/wiki/C10k_problem [1] https://brendaneich.com/2007/02/threads-suck/ [2] https://web.stanford.edu/~ouster/cgi-bin/papers/threads.pdf [3] https://www2.eecs.berkeley.edu/Pubs/TechRpts/2006/EECS-2006-1.pdf

And in 1990 people were complaining about the same thing [1]. [1] Why Aren’t Operating Systems Getting Faster As Fast as Hardware? https://web.stanford.edu/~ouster/cgi-bin/papers/osfaster.pdf

Tcl's first "release" was in 1988 and Magic was released in 1984, but it seems like John Ousterhout then wrote Tcl to have a common interface across tools [https://web.stanford.edu/~ouster/cgi-bin/tclHistory.php]. It still is a big thing in EDA, because (in theory) it lets a chip designer run their designs by tools from different vendors

> Eh, I'm not swayed by arguments from authority. Jon's opinion is as valid as mine or yours. John has spent his entire life to learning and teaching general principles of good software design and their limits. His opinion definitely has a different weight than ours. https://web.stanford.edu/~ouster/cgi-bin/cs190-winter21/index.php

Why is that convincing though? Students aren't experienced coders, aren't working in large teams, and student assignments aren't like long-term large commercial projects. If you mean the additions here https://web.stanford.edu/~ouster/cgi-bin/book.php, I read these and it still sounds like general rules of thumb you'll only really learn and understand by practicing a lot e.g. "In my experience, the sweet spot is to implement new modules in a somewhat general-purpose fashion" "Having good taste is an important part of being a good software designer".

> Someone should know about what fp is before writing a book like this. 1. Are you quite sure John Ousterhout (who invented Tcl[1], comparing it to Lisp in section 7 of the original paper) doesn't "know about what fp is" as you say? 2. Do you think that the main reason functional programming hasn't taken off in systems programming is that practitioners are ignorant, or do you think there might be issues with fp systems that prevent its adoption? [1] https://web.stanford.edu/~ouster/cgi-bin/papers/tcl-usenix.pdf

Fun facts, the author of Tcl and tk is Prof. John Ousterhout, and his Software Design book is in its 2nd edition: A Philosophy of Software Design: https://web.stanford.edu/~ouster/cgi-bin/book.php

"The Tcl scripting language grew out of my work on design tools for integrated circuits at the University of California at Berkeley in the early 1980's. " History of TCL, https://web.stanford.edu/~ouster/cgi-bin/tclHistory.php