21–30 of 66 posts
>Programmers tend to worry too much and too soon about performance. Many college-level Computer Science classes focus on fancy algorithms to improve performance, but in real life performance rarely matters . Stopped reading there. A great plague of modern software development is a complete disregard for performance or resource conservation.
Side note: Ousterhout was famous for being the author of Tcl/Tk, which was a popular language and GUI toolkit in the early days of Linux (before Qt and GTK came along). I wouldn't be surprised if many older Unixes are still running Tcl/Tk apps.
Side note: Ousterhout was famous for being the author of Tcl/Tk, which was a popular language and GUI toolkit in the early days of Linux (before Qt and GTK came along). I wouldn't be surprised if many older Unixes are still running Tcl/Tk apps.
Side note: Ousterhout was famous for being the author of Tcl/Tk, which was a popular language and GUI toolkit in the early days of Linux (before Qt and GTK came along). I wouldn't be surprised if many older Unixes are still running Tcl/Tk apps.
Side note: Ousterhout was famous for being the author of Tcl/Tk, which was a popular language and GUI toolkit in the early days of Linux (before Qt and GTK came along). I wouldn't be surprised if many older Unixes are still running Tcl/Tk apps.
His "projects" page also lists "Log Structured File Systems" (which inspired LSM used by many databases) and Raft (the consensus protocol) as things he made significant contributions to.
>Programmers tend to worry too much and too soon about performance. Many college-level Computer Science classes focus on fancy algorithms to improve performance, but in real life performance rarely matters . Stopped reading there. A great plague of modern software development is a complete disregard for performance or resource conservation.
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.
Side note: Ousterhout was famous for being the author of Tcl/Tk, which was a popular language and GUI toolkit in the early days of Linux (before Qt and GTK came along). I wouldn't be surprised if many older Unixes are still running Tcl/Tk apps.
TCL is a great systems programming language. When I need a glue language for an imperative model program it's my first choice.
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 excluding C library functions. I can say that for my embedded requirements, Lua would win...
>Programmers tend to worry too much and too soon about performance. Many college-level Computer Science classes focus on fancy algorithms to improve performance, but in real life performance rarely matters . Stopped reading there. A great plague of modern software development is a complete disregard for performance or resource conservation.
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.
>Programmers tend to worry too much and too soon about performance. Many college-level Computer Science classes focus on fancy algorithms to improve performance, but in real life performance rarely matters . Stopped reading there. A great plague of modern software development is a complete disregard for performance or resource conservation.
"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."
>Programmers tend to worry too much and too soon about performance. Many college-level Computer Science classes focus on fancy algorithms to improve performance, but in real life performance rarely matters . Stopped reading there. A great plague of modern software development is a complete disregard for performance or resource conservation.
> "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.