3 ms·
There's a problem here in going from their specific case to where this may make sense, to the more general case they're trying to make, where it doesn't. For i
by wheels 15y ago
There's a problem here in going from their specific case to where this may make sense, to the more general case they're trying to make, where it doesn't.
For instance, if you're mapping disk space to memory addresses and have large blocks of data, this would mean that every time you needed to update a single byte, you'd either have to duplicate the entire block (possibly several mega- or giga-bytes) or give up linear access. Yuck. There are a lot of use cases that would absolutely be miserable for.
You can get away with such things a lot further if you're implementing these things at the file-system level.
- hvs 15y agoThere's a great presentation of these types of issues in the book Purely Functional Data Structures: http://www.cs.cmu.edu/~rwh/theses/okasaki.pdf http://www.cs.cmu.edu/~rwh/theses/okasaki.pdf
- rlander 15y agoThis is a great read for any programmer, not only those interested in functional programming. Also related (HN discussion): http://news.ycombinator.com/item?id=1138979 http://news.ycombinator.com/item?id=1138979 And Cris Okasaki's blog: http://okasaki.blogspot.com/ http://okasaki.blogspot.com/
- hashbo 15y agoHi. Yep agreed, I did I believe mention it is most valuable when you have mostly have creates & reads and less updates like in the example of web applications. Of course there are valid in memory level operations, quite famously in the Java world we have ConcurrentHashMap which is a CoW semantic. However naturally one size doesn’t fit all, but then it never really does :-)