On Wednesday, 21 October 2015 at 15:34:14 UTC, Russel Winder
wrote:
On Wed, 2015-10-21 at 14:06 +0000, Jonathan M Davis via
Digitalmars-d wrote:
[...]
[…]
[...]
I am confused as to why you would find these
functional/persistent data structures to be a problem in
functional languages. The whole point of them is they can be
easily shared without any locks. In effect each amendment of
the structure creates a fork (effectively a copy but without
the copy bit) of it. This goes hand in hand with the
functional, and especially tail recursive computational model.
The Groovy team is currently debating adding persistent data
structures to the Groovy armoury. Clojure and Scala have had
persistent data structures for ages. The Clojure ones are
really good. The Scala ones have some issues so there is
currently discussion of a third rewrite.
[...]
Except in a concurrent and parallel world! For big mutable data
structures you end up creating agents (or so we can use hyper
trendy nomenclature, pico-services) to avoid messing around
with locks, mutexes, etc. the use of which generally kills
performance.
[...]
[…]
As noted in an earlier email, I am not yes convinced by this
one.
[...]
I'd say the opposite. I would suggest that
persistent/functional data structures would be more generally
useful than COW ones.
[...]
I am not convinced by this argument. Yes these are the type of
containers C++/D/… programmers are used to and have a lot of
code using, but are they really the ones that should be used.
Experience from Clojure and Scala is that persistent/functional
data structures lead to much nicer/easier concurrent and
parallel code.
> [...]
These are where it's at IMHO. 99.999999% this is what makes
sense.
Except in a concurrent and parallel world! For big mutable data
structures you end up creating agents (or so we can use hyper
trendy nomenclature, pico-services) to avoid messing around with
locks, mutexes, etc. the use of which generally kills performance.
I actually find these annoying in C#. People modify things they
shouldn't be all of the time. Which makes errors so much more
prevalent. Every property that returns a List<T> is frequently
exposed for the world to use. The best workaround I've found is
to use interfaces that restrict what methods they have access to,
but even then people resort to just casting it away.
I'd prefer immutable by default. Personally.
