4 ms·

No need to stop there - it's just historical, very old advice, the rest is pretty good. It underestimates how aggressively inefficient today's trends and framew

No need to stop there - it's just historical, very old advice, the rest is pretty good. It underestimates how aggressively inefficient today's trends and frameworks are. It actually advocates for focusing first on simplicity. And I think Ousterhout would not consider an "easy-to-use" "developer-friendly" but big and featureful framework to be that kind of simplicity. He says: > "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.

mmt 8y ago
> 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. 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.

mmt 8y ago

> 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. 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.