Hacker News Reader

Comment by jgrodziski | Hacker News Reader

I look forward to the point where 3/4 of business application code will go the trash when we'll have a persistant memory with the latency of actual RAM disk (Memristor !!). Exit all that "copy from RAM to Disk/Network" code. It will definitely change the way we code and look at code. That's why nowadays I think a good interface to your entities, like the Repository pattern, is a must have.

View on HN

    It will definitely change the way we code

Only on a low level, right? I have not been thinking about ram and disk in ages. I calculate with variables, I store stuff in a DB or in a file, I access the net via http. Nothing would change if ram increases I think.

Well, if you have plentiful persistent RAM an application could easily "suspend" itself (on shutdown for example), and then resume running at a later point in time. The code would not have to think about this, since the entire state is just snapshotted. It's basically what machines do now when they "hibernate", except more effecient and could even happen if the power got cut.

Additionally I suppose your variables could also be persistent automatically. Though the biggest change I see is that software would never really need to completely close anymore when RAM == Disk. For RAM usage it wouldn't really matter if they were running or not, unless they delete data upon shutdown. To save CPU or other IO usage the application could simply be suspended.

Can't wait for the persistent memory leaks!

Or losing data on crash because load/save cycle is untested.

I work on an application that was originally designed to persist transactions to battery backed SRAM. It's still full of "business logic", because that's where all the value is. Copying data around really doesn't consume that much time and effort; performing logical, semantic or administrative transformation on it does.

Reply on news.ycombinator.com