Comment by someguyiguess
5 hours ago
Unless you are the one having to maintain that library. Then it just migrates the complexity to another location.
5 hours ago
Unless you are the one having to maintain that library. Then it just migrates the complexity to another location.
> Unless you are the one having to maintain that library. Then it just migrates the complexity to another location.
No, it’s a win, even then.
Say you are writing an operating system, and one of the fundamental data structures you use all over the place is a concurrency-safe linked list.
Option 1 is to manipulate the relevant instances of the linked list directly—whenever you need to insert, append, iterate over, or delete from any list from any subsystem in your operating system. So you’ll have low-level list-related lock and pointer operations spread throughout the entire code base. Each one of these operations requires you to struggle with the list at the abstraction level and at the implementation level.
Option 2 is to factor out the linked-list operations and isolate them in a small library. Yes, you must still struggle with the list at the abstraction and implementation levels in this one small library, but everywhere else the complexity has been reduced to having to struggle with the abstraction level only, and the abstraction is a small set of straightforward operations that is easy to wrap your head around.
The sole difference between the options, as you wrote, is that “the complexity just migrates to another location.” But which would you rather maintain?
That was Ousterout’s point.