2 ms·
I generally prefer expression-oriented programming like this, but it's hard to pass up the efficiency improvements of arrays and hashmaps. The purely functiona
by wffurr 7y ago
I generally prefer expression-oriented programming like this, but it's hard to pass up the efficiency improvements of arrays and hashmaps. The purely functional list given in the article is actually an order of magnitude less efficient to iterate on modern caching pipelined processors.
What's the best way to have your expression-oriented programming and use cache-friendly data structures? How do Haskell et al handle this?
- jhanschoo 7y agoYou'll have to do it with a compiler, and limit yourself to only certain access patterns, I suppose. To take full advantage of the functional paradigm most settle for logarithmic access with tries.
- kqr 7y agoLocal impurity. The key insight is that mutation/impurity isn't necessarily bad in and of itself. The important thing is that it is guaranteed to not cross API boundaries -- this prevents abstractions from leaking at least one way, and lets you reason about the code as if it were pure. (And in fact, from the outside it is.) This allows mutation to remain the performance optimisation it is, without allowing it to seep into the design of systems, which is where it causes badness. As far as I know, Haskell is one of the few languages (if not the only one) that supports local mutation that is guaranteed to not be visible in any way to the caller.
- throwaway17_17 7y agoIn an ideal world, Haskell would have a uniqueness type ala Clean or Idris which would allow for ‘in-place’ mutations of array and retain referential transparency.