3 ms·

I think Clojure is likely to shoot ahead of Erlang as the leading concurrency language. After that will be Concur, an ML/Haskell-inspired statically-typed concu

I think Clojure is likely to shoot ahead of Erlang as the leading concurrency language. After that will be Concur, an ML/Haskell-inspired statically-typed concurrency language my friend Brian Hurt is designing. One thing I've picked up, looking at Clojure, is that the lack of mutable state allows certain cool optimizations. For example, let's say you have a map A with a million key-value pairs. You want to do something with B = A + (k', v'). In a mutable-state language, you'd physically add (k', v') to the map, which is usually implemented as a hash table. Clojure creates a new map (32-ary tree) for B that shares most of its pointers and structure with A, which allows you to do FP without FP's greatest drawback, which is the copying of large data structures. Since the nodes will never change, this sharing is entirely safe. A remains entirely unchanged, so a thread working with A still has A. Functional programming doesn't actually eliminate side effects and mutability. Haskell has the IO and Array monads. Clojure has refs and agents. FP simply segregates them from the rest of the program so that they exist only when desirable, and can be more easily managed. I don't know the details about cache and local memory. This is a weak area for me.

eru 18y ago
> FP's greatest drawback, which is the copying of large data structures I guess you made that one up on the spot. Go read about "Purely Functional Data Structures" http://www.cs.cmu.edu/~rwh/theses/okasaki.pdf http://www.cs.cmu.edu/~rwh/theses/okasaki.pdf or have a look at Haskells Data.Map implementation for another example.
- time_management 18y ago
  I meant that it's the greatest (potential) drawback of the functional style, especially when that style is employed in a non-purely functional language. You're correct that you don't often end up doing full-object copies in the leading implementations of certain purely functional languages, such as Haskell or Clojure.
  - eru 18y ago
    The design of good persistent (i.e. 'functional') data structures remains an art. But you do not have to rely on the designers of your language. Hey, you can even simulate Haskell's lazyness to implement some Persistent Data Structures efficiently in Java.
    - 11ren 18y ago
      Q. If you append to a linked list, you can't avoid creating an entirely new copy of the list, can you? (prepending is OK, because you reuse the old list). Or can Haskell's laziness help with this? Can it somehow avoid actually creating the new copy, but instead just return the correct value when you reach the end of the list? So that the new copy is never actually made, but it just behaves as if it was?
      - time_management 18y ago
        There's a trick for efficient appending that's somewhat analogous to laziness. It's quite clever. Sadly, I cannot claim to have come up with it, and I don't know who did. Instead of working with [a] lists, work with [a] -> [a] prepender functions. So the analogue of [1, 2, 3] is f: \x -> [1 2 3] ++ x. Then the analogue of the append of f and 4 is f . (\x -> [4] ++ x), where the . represents composition. Appending using these analogues, I believe, is O(1) instead of O(n). To "evaluate" an element of this "closure space", just apply it to the empty list.
        eru 18y ago
        You can also re-use some form of balanced binary trees where all interesting operations are doable in log(n) and adding requires about log(n) (mostly internal) nodes to be rebuild. That is worse than the optimum O(1) for linked lists you can reach --- but it's easy to come up with and often good enough.

eru 18y ago

> FP's greatest drawback, which is the copying of large data structures I guess you made that one up on the spot. Go read about "Purely Functional Data Structures" http://www.cs.cmu.edu/~rwh/theses/okasaki.pdf http://www.cs.cmu.edu/~rwh/theses/okasaki.pdf or have a look at Haskells Data.Map implementation for another example.

time_management 18y ago
I meant that it's the greatest (potential) drawback of the functional style, especially when that style is employed in a non-purely functional language. You're correct that you don't often end up doing full-object copies in the leading implementations of certain purely functional languages, such as Haskell or Clojure.
- eru 18y ago
  The design of good persistent (i.e. 'functional') data structures remains an art. But you do not have to rely on the designers of your language. Hey, you can even simulate Haskell's lazyness to implement some Persistent Data Structures efficiently in Java.
  - 11ren 18y ago
    Q. If you append to a linked list, you can't avoid creating an entirely new copy of the list, can you? (prepending is OK, because you reuse the old list). Or can Haskell's laziness help with this? Can it somehow avoid actually creating the new copy, but instead just return the correct value when you reach the end of the list? So that the new copy is never actually made, but it just behaves as if it was?
    - time_management 18y ago
      There's a trick for efficient appending that's somewhat analogous to laziness. It's quite clever. Sadly, I cannot claim to have come up with it, and I don't know who did. Instead of working with [a] lists, work with [a] -> [a] prepender functions. So the analogue of [1, 2, 3] is f: \x -> [1 2 3] ++ x. Then the analogue of the append of f and 4 is f . (\x -> [4] ++ x), where the . represents composition. Appending using these analogues, I believe, is O(1) instead of O(n). To "evaluate" an element of this "closure space", just apply it to the empty list.
      - eru 18y ago
        You can also re-use some form of balanced binary trees where all interesting operations are doable in log(n) and adding requires about log(n) (mostly internal) nodes to be rebuild. That is worse than the optimum O(1) for linked lists you can reach --- but it's easy to come up with and often good enough.