Kinds of containers

[Ice Cream Man via Digitalmars-d]

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.