

Functional C++ talk by Kevlin Henney [video] - adamnemecek
https://vimeo.com/131640207

======
krapht
I watched the talk, not having a lot of exposure to functional programming,
but having exposure to C++ through my job. I am still not sure I understand
his presentation.

The beginning was straightforward and had some good takeaways. The message
was, as he showed through some examples such as a date class, that if you can
avoid mutating state, then do so. Prefer to construct immutable objects that
support fast copying via move semantics. This way, you can preserve class
invariants easily. This is something I agree with, and have started to try to
do in my new code. I guess the other benefit is that you can avoid passing
const ref& around, and just pass by value everywhere, and the compiler will
optimize it for you via return value optimization and move semantics.

Kevlin spends the middle part of the presentation talking about how to
implement an immutable list in C++ using the STL style. The main change seems
to be he has added const modifiers to everything, pop_front/pop_back now
return a new list minus one popped element, and he's added an internal
shared_ptr to track references to the list, (I didn't quite follow why it was
used - I'd probably have to rewatch the presentation). Then, at the end, he
talks about asynchronous computation, and how functional programming is a
better fit for concurrency because now you need no locks, since data is
immutable, and lo, we have an immutable list. But I'm not sure how they go
together to solve any of the typical problems I have with concurrency.
Typically I want concurrency because I have a huge, compute intensive problem.
With this list, suddenly, I have a huge explosion in memory requirements as
each time the list is mutated, I have to store a new copy of the list. I guess
I'd also then have to synchronize access to my new mutated list reference? I'd
need a different algorithm. I feel like functional languages prefer recursive
divide and conquer approaches.

So, in the end, I don't think I was the right audience for this talk, or I
didn't have enough time to devote to understanding it. I watched the video and
ended up more confused about functional C++. I did enjoy his last slide about
the actor model. Being familiar with it, I agree that it is a good solution
for certain types of concurrency. I see it as sort of a generalized solution
to execution flows that can be pipelined.

~~~
pests
I have just started watching the video but IIRC Facebook's Immutable.js
library implements immutable lists and sets with some sort of tree data
structure that allows non-mutated elements to be shared between copies. Maybe
this does something similar?

~~~
dmeb
Trees with a very high branching factor can be used to support immutable
vectors which support effectively constant time insert/remove/indexed lookup.
However, it's not necessary to use trees to implement immutable lists.

In scala:

    
    
      val xs = List(1, 2, 3) // i.e. 1 -> 2 -> 3 -> Nil
      val ys = 42 :: xs  // i.e. 42 -> xs
    

In this instance, ys is a reference to a "Cons" node consisting of the value
42 and a reference to the immutable list xs. As xs is immutable, there is no
risk of ys.tail changing, so we don't have to copy xs but just make a
reference to it. So creating the "new" list ys only incurs the O(1) memory
required to create the new node (42,xs).

Now, if you instead did:

    
    
      val xs = List(1,2,3) // 1 -> 2 -> 3 -> Nil
      val zs = xs ++ List(42) // 1 -> 2 -> 3 -> 42 -> Nil 
    

This would in fact trigger a copy of the entire list xs, as you are modifying
the reference pointed to of the Cons node containing 3, requiring a copy of
the entire xs so that your modification doesn't affect other references to the
original xs.

Performance characteristics of different Scala collections: [http://www.scala-
lang.org/docu/files/collections-api/collect...](http://www.scala-
lang.org/docu/files/collections-api/collections_40.html)

