5 ms·

I find this to be a bit of an oversimplification. It's certainly not the case that there's only one type of storage, at least from a hardware perspective: ther

I find this to be a bit of an oversimplification. It's certainly not the case that there's only one type of storage, at least from a hardware perspective: there will always be storage that is faster than other storage, and managing that will always be required to optimize performance. I agree with the author that you should program against the simplest abstraction you can, but that's not always clear. Just because your environment is one in which you don't have to doesn't mean you can't or shouldn't in the right circumstances. I'd argue that it's actually more complex now. I programmed in the early 1980s, and did have to worry about where my data physically resided inside the machine, but I never had to worry about whether it was in a different room on a different machine, or sitting on a hard drive in some Amazon Data Center a continent away. As others here note, the idea of using the same abstraction for all storage is at least as old as MMUs and Multics (mid 1960s). What is different is that programmers in the 60s and (early) 70s were usually coding pretty close to the bare metal. Nowadays, Moore's law has allowed us sufficient power to permit programming on top of a big pile of abstractions that try very hard to hide the actual hardware from us. That's a luxury afforded by the sheer power of what we're working with, but the people writing those abstraction layers still have to pay attention to the layer beneath them, and if you go down far enough, you'll find some code that needs to pay attention to what class of memory something is stored in and how to optimally move it around. It's just that work was probably done for you by someone else who wrote your operating system. Just because your programming language doesn't require you to use pointers doesn't meant that indirection isn't being used. You just don't have to deal with it (until it rears up and reminds you it's still there). Joel Spolsky's Law of Leaky abstractions (https://www.joelonsoftware.com/2002/11/11/the-law-of-leaky-abstractions/ https://www.joelonsoftware.com/2002/11/11/the-law-of-leaky-a...) is relevant here.

s17n 5y ago
But the whole point of the article is that given the way modern hardware and kernels work, you don't actually have the ability to program against lower layers of abstraction, and attempting to do so can degrade performance.
- ajarmst 5y ago
  I agree completely that you shouldn’t be digging into that stuff unless you have a reason to and possess the appropriate competence. But the reasons for doing that is the same everywhere: (1) complex systems are difficult and subtle, and (2) “premature optimization is the root of all evil”. In fact, Knuth’s aphorism is a much better description of why one should avoid the complexity of this issue than a clearly incorrect argument proposing that the distinction between storage classes doesn’t exist, that 1975 programmers were ignorant of storage abstraction, and that this issue has become less complex over time. (Edit: corrected typo. Programmers in 1075 were definitely unfamiliar with storage abstractions.)
throwaway894345 5y ago
> I'd argue that it's actually more complex now. I programmed in the early 1980s, and did have to worry about where my data physically resided inside the machine, but I never had to worry about whether it was in a different room on a different machine, or sitting on a hard drive in some Amazon Data Center a continent away. Oof, I hear that. That’s just the tip of the iceberg. We also design for those computers being deleted or disconnected spontaneously. Even more complex than designing distributed systems (in my opinion) is designing the continuous deployment systems which get our code from git to running in production (without running incompatible versions of services even for a moment). It certainly makes the idea of writing single-host software seem simple and romantic.

s17n 5y ago

But the whole point of the article is that given the way modern hardware and kernels work, you don't actually have the ability to program against lower layers of abstraction, and attempting to do so can degrade performance.

ajarmst 5y ago
I agree completely that you shouldn’t be digging into that stuff unless you have a reason to and possess the appropriate competence. But the reasons for doing that is the same everywhere: (1) complex systems are difficult and subtle, and (2) “premature optimization is the root of all evil”. In fact, Knuth’s aphorism is a much better description of why one should avoid the complexity of this issue than a clearly incorrect argument proposing that the distinction between storage classes doesn’t exist, that 1975 programmers were ignorant of storage abstraction, and that this issue has become less complex over time. (Edit: corrected typo. Programmers in 1075 were definitely unfamiliar with storage abstractions.)

throwaway894345 5y ago

> I'd argue that it's actually more complex now. I programmed in the early 1980s, and did have to worry about where my data physically resided inside the machine, but I never had to worry about whether it was in a different room on a different machine, or sitting on a hard drive in some Amazon Data Center a continent away. Oof, I hear that. That’s just the tip of the iceberg. We also design for those computers being deleted or disconnected spontaneously. Even more complex than designing distributed systems (in my opinion) is designing the continuous deployment systems which get our code from git to running in production (without running incompatible versions of services even for a moment). It certainly makes the idea of writing single-host software seem simple and romantic.