I've written code for a few different computing architectures that were designed to present a single logical level of RAM-like storage. That experience has conv

I've written code for a few different computing architectures that were designed to present a single logical level of RAM-like storage. That experience has convinced me that it is a terrible idea, largely because it makes elementary software optimization difficult and the default result is usually mediocre. No matter how it is presented, all addressable storage in modern computing systems is hierarchical. Pretending these latency hierarchies don't exist doesn't make them go away. If you obscure this by making it all look like RAM, the implied access latency variance due to access patterns and underlying concurrency control is still operative, just opaque. Computer science is full of data structures and algorithms designed to be fitted to the latency hierarchies of real hardware; it is difficult to make algorithms well-behaved when the hardware is designed to make it difficult to reason about these latency hierarchies. Ironically, I always worked around this by reading the low-level system hardware documentation that described how the hierarchy was being hidden and scheduled so that the memory access patterns could be engineered to elicit specific hierarchy aware behaviors that the code wasn't supposed to know about. We ended up writing the same hierarchy aware code required for systems that don't use RAM as an abstraction, but with a much worse and more difficult to control API. Working on different exotic computing architectures was extremely educational. It gave me an appreciation for the practical tradeoffs of various weird hardware models that most people only talk about in theory. It is similar to the perspective you gain from experience writing software in many different programming language paradigms. There are no silver bullets, just a different set of problems you have to deal with.