John Ousterhout: My favorite sayings
web.stanford.edu
web.stanford.edu
The three most powerful words for building credibility are "I don't know"
The best supervisor I ever had was the one who routinely told me "I don't know, let me call {PersonInOtherDepartment}" or "See if the answer is in {RelevantManual} under {PossibleSection}. If you don't find it, give me a call."
We treat "I don't know" as an admission of failure far too often. It should be seen as an entry point to improvement.
They both had the right answer about 95% of the time, but the one who said "I don't know" was only wrong about 1% of the time.
So, say what you think but at the same time ask (demand?) an argument or discussion.
A friend has a T-shirt with the words: Always sure, often wrong.
Also see: https://www.psychologytoday.com/us/blog/work-matters/201002/...
Sadly, the good habits that you learn in academia will come back to haunt you when you move into industry.
Whenever I've worked with a blowhard who couldn't admit when they didn't know something literally everybody smart thought of them as a blowhard who couldn't admit when they didn't know something.
Too bad this excludes so many managers, but really this is so much a company culture issue than anything. So to cite from the article: "very few companies are capable of making significant changes in their culture or business model, so it is good for companies eventually to go out of business, thereby opening space for better companies in the future."
I've done it plenty of times and my colleagues keep coming back to me when they need help.
I wouldn't be surprised if many older Unixes are still running Tcl/Tk apps.
The Vienna based university, TU-Wien, still runs AOLserver and serves 40K users with it. OpenACS.org and dotLRN.org still use the same Tcl-based webserver today.
Gustaf Neumann shepherded the development of the use of OpenACS/dotLRN at TU-Wien, I think: http://nm.wu.ac.at/nm/neumann
Though I believe Lua is a smaller binary, which matters in some embedded scenarios. According to [1], the core Lua interpreter is 40kB with additional base libraries of 22kB, so total of 62kB.
There are a variety of "small TCL" implementations [2], and one of them, TinyTCL claims to be <60kB, excluding C library functions. I can say that for my embedded requirements, Lua would win...
This is for full featured *nix systems programming in the HPC world so ymmv.
I indeed don't see it having any benefit over Python or TCL in more sophisticated environments.
That said here are things I advise.
* No upvar/uplevel. Use a namespace. * Use apply wisely. * No ad-hoc (say swig inline wrappers) extensions without deep review. * If you are writing a front end in tk - think twice. * If you are doing OOP with TCL choose wisely.
Tk is still the quickest way to create a simple UI which is also highly portable across operation systems. With tclkit you can even create self contained Tcl/Tk applications on the big platforms (Win/Mac/Linux).
Or newer. e.g., I use gitk daily at work.
> 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
Looks like it was just released!
http://antirez.com/articoli/tclmisunderstood.html
(Ousterhout is the creator of Tcl and both antirez and Richard Hipp of sqlite are Tcl programmers)
For those who unfamiliar, the book is based on evidence observations of student groups builindg large systems and then reviewing and discussing complexity sources -- then they swap their systems with other groups. They then need to keep iterating... usually hitting problems that we find in the wild. The book is the result of his observations.
The thing I would recommend John do next in his Stanford course is to encourage the students to infuse testing apporaches to the systems they build. This could reveal even more value of the craft in a setting that is somewhat controlled.
However, file this under "too honest":
> For example, a few years ago I started working on my first large Web application
I've spent most of my career learning the do's and don'ts of building large web applications... I assumed Professor Ousterhout had more experience in this sort of thing than I do!
The Projects page is a great read too: http://web.stanford.edu/~ouster/cgi-bin/projects.php
I agree with this until you come across colleagues with the Jobsian 'reality distortion field'. Or even the social dynamics at play with the orange man that lives in the big white house.
We absolutely assign credibility to people with integrity and self-awareness. But, unfortunately, we also seem to have a capacity to be charisma vultures and will happily believe someone's bullshit if they are making us feel good in the present moment.
> There are 2 kinds of software in the world: software that starts out crappy and eventually becomes great, and software that starts out crappy and stays that way.
I appreciate the concept. And this has the fun of sounding morbid. But this is a bit like saying the most imoprant part of an ICE is a piston which is silly because a piston needs a confined space and a good fuel to operate. It doesn't work without all three (and more).
In this case a mechanism of genetic change is equally (or more important in a way) to evolution than death. Death is obviously very important though.
Except when speed is part of the definition of working. For example deep learning. The correct implementation was not enough until the hardware was fast enough.
This doesn't refute his argument, which I read as being, essentially, against performance optimization of software during initial construction. Knuth famously bemoaned premature optimizations, as well.
There’s a more pithy variant of this, which I use all the time: “You can’t fix what you don’t understand”.
Stopped reading there. A great plague of modern software development is a complete disregard for performance or resource conservation.
Application design and domain knowledge are more important than rote optimization. I think that is what Ousterhout is getting at.
This causes me to interpret statements like "Programmers tend to worry too much and too soon about performance." more charitably. I think he does care about real performance.
That's the critical part of that statement. It is not important to solve for performance concerns until the code actually works so you can verify you've solved the problem at hand.
"You should pay attention to performance, but your algorithms probably won't be the problem. It's more likely you're doing something stupid or wasteful, probably with the help of your technology stack."
That's EXACTLY my problem whenever I hear this or similar advice. It's exactly what I think when I hear people (mis)quote Knuth by mindlessly parroting the old adage (optimization is the root of all evil). Too many people interpret this as a licence to waste resources and bloat your program with reckless abandon to an egregious degree, that I too think people should probably not say spread stuff like this.
> "faster" algorithms often have larger constant factors, meaning they are slower at small scale and only become more efficient at large scale
So what I think he's worried about is sophisticated large-scale-oriented algorithms, but that's really not the problem today, which is huge frameworks and middleware and cluster applications, and the desire to use the very latest of these things. More than once I've heard a frontend dev say they want to use "react and redux" for the next project, without knowing what redux is. I've also seen many backend teams decide they need to use Cassandra for scalability and availability, but the cluster ends up being overwhelmed or down for half a day, every month or so, because you need to be a JVM and Cassandra expert to keep those clusters working. I think this kind of thing is exactly what Ousterhout would warn against.
The zeitgeist has swung wildly in the other direction, developers are no longer eager to implement the most complicated algorithm for theoretical optimization, now they are eager to implement the most complicated frameworks and services for "best practices and to be more maintainable" than the last mess they made. But the recommendation is the same in both cases: make it simple. Study the problem, clean up the mess (hard work!), keep it simple.
Phew.. it's not just me. My one exposure to Cassandra [1] in a production environment mirrors this experience very closely. I felt a bit like the child in the tale looking at the nude Emperor.
Each node held only a single SSD, so increasing database size meant buying an additional multi-thousand-dollar server. Upgrading RAM meant upgrading all the nodes, which became an O(number of nodes) problem in terms of time and cost.
The backend team may have had a JVM expert or two, but obviously no Cassandra (nor database in general, and certainly not hardware) knowledge. It was the Ops team who had to keep it limping along and gain the expertise.
It's just another case of "it works for FAANG, so it'll work for us" thinking, even though "us" is 2-3 OOM smaller and would be better served by the simplicity of a scaled "up" non-distributed system.
[1] Also plenty of experiences with non-Cassandra distributed (usually "NoSQL") databases. The results have ranged from grossly over-engineered (i.e. high cost) to unreliable and/or high-maintenance. Fortunately, rarely both at the same time.
I find it neat that the person arguing for speed is employing heuristics which short circuit reading.
A great way to look at human biases is through the lens of the good they cause. It makes them all make sense in a way that looking at them through the lens of failure cases doesn't. The world is awe inspiring in its complexity and coping with that efficiently and in real time requires trade offs. Catch the same person who appears delusional in one real-time context at a time wherein they can think for longer and their thinking can become much more logical and mathematical.
I don't feel any kind of superiority, I was just voicing my opinion. Maybe you're projecting?