John Ousterhout, a Stanford professor and creator of Tcl, hosts papers and writing on software design, threads, and operating systems.
HN commenters recommend his book "A Philosophy of Software Design" and cite his work on Tcl, Sprite, and RAMcloud.
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…
> "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 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/weekendThoughts.php
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
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.
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