Comment by FPGAhacker | Hacker News Reader

Comment by FPGAhacker | Hacker News Reader

Quote > The factors that allow programs in functional languages to sometimes be more concise than imperative implementations are pretty much orthogonal to the use of pure functions — garbage collection, powerful built-in types, pattern matching, list comprehensions, function composition, various bits of syntactic sugar, etc. For the most part, these size reducers don't have much to do with being functional, and can also be found in some imperative languages.

—

Amen. I think people new to functional programming are thrown by this, and I think some long time adherents of functional programming have adopted these “factors” as part of the definition.

Definitions change, that’s fine, but the confusion of ideas isn’t good.

Anyway, are there functional data structures widely available to c++? I assume there are. Without them, functional programming has a heavy cost.

Clojure, for one, would not be very attractive without having adopted Bagwell’s data structure concepts.

The challenge then, as with essentially every language that doesn't use persistent data structures _as the default_, is having to recursively convert to and from those persistent data structures at the edges of your system where you need to interact with third party libraries that likely won't be consuming/producing those data structures natively.

Unfortunately this is where the value proposition of a non-standard data structure library usually breaks down for general usage. That recursive translation layer sitting at the edge of your system is generally enough to completely blow up your performance budget and many times leave you worse off than if you had just used the default mutable data structures and made naive shallow copies everywhere in the first place.

The best case study for this is JavaScript, which by now has a fairly substantial following of functional programmers, and has an excellent persistent data structures library in ImmutableJS, but the vast majority of functional codebases in JS just end up doing shallow-copy-on-write using the default mutable data structures regardless, because of the difficulty of taking proper advantage of the performance benefits of persistent data structures in an ecosystem that overwhelmingly deals in mutable data structures. That said, the fact that C++ is not a garbage collected language and the associated developer ergonomics costs of having to manually clean up your own shallow copies might skew the value proposition a bit, but given that if you're writing in C++ you're probably in it for the raw performance in the first place, it's unlikely to be enough to tip the scales.

The problem is that some of those features - function composition, stream/LINQ type APIs, list comprehensions, etc. - become very difficult to reason about/debug when used with side-effecting code.

Yes you get the conciseness but you can create some truly obfuscated behavior when used with non-functional code.

Don't get me wrong - I'm delighted to see such features available in more languages. But they don't all work nicely with the typical abstractions (e.g. objects holding state) available in non-functional languages.

Immutable data structures become a lot harder without gc, though. To update an immutable structure you don't want to copy parts that haven't changed. But this requires sharing and without gc this requires refcounting. Which in turn makes accidental cycles leak memory so you have to deal with weakrefs and have to think about this and multithreading isn't as nice as it could be and...

Regarding data structure there is the Immer library : https://sinusoid.es/immer/#contents

> Clojure, for one, would not be very attractive without having adopted Bagwell’s data structure concepts.

i don't think Clojure ever "adopted" Bagwell's data structures, it was designed around them and few other concepts.

Reply on news.ycombinator.com