3 ms·
I'm enjoying Ousterhaut's "A Philosophy of Software Design", but it is striking how much it is shaped and limited by the languages that are implicitly considere
by jasim 8y ago
I'm enjoying Ousterhaut's "A Philosophy of Software Design", but it is striking how much it is shaped and limited by the languages that are implicitly considered (mostly, imperative OO languages).
One oddity is the view of the class as the only real scope at which one can build abstractions. The idea that one can use little abstractions to build big abstractions, without cluttering the final abstraction to be presented to the user, is nowhere in sight.
Most shockingly to me, I've found no reference to types as a design tool. Sure, precise names help you avoid confusing physical block ids and logical ones. But wouldn't a type-based distinction be way better?
- https://twitter.com/yminsky/status/1005066579929911296 https://twitter.com/yminsky/status/1005066579929911296
- jahaja 8y agoI honestly think it's just too esoteric to ever be considered "mainstream" simple.
- johnousterhout 8y agoGood point about using types. I should have mentioned that as a way to eliminate the block number problem in Section 14.1; I'll fix that in a future revision of the book.
- jasim 8y agoThat'll be a great addition to the book. Can I also recommend Yaron Minsky's talk on OCaml, specifically the part where he talks about "making invalid states impossible": https://youtu.be/-J8YyfrSwTk?t=1079 https://youtu.be/-J8YyfrSwTk?t=1079 I've found this to be the single most valuable programming technique I've learnt. Richard Feldman dives deeper into the topic with a lot more examples in https://youtu.be/IcgmSRJHu_8?t=73 https://youtu.be/IcgmSRJHu_8?t=73