This is of course a popular opinion and pretty much the C++ philosophy. Unfortunately a lot of the benefits of functional programming cannot be fully realised unless you are "all in". The paper "The Curse of the Excluded Middle" is somewhat blunt but it makes some good points: https://queue.acm.org/detail.cfm?id=2611829

Programming without immutability is so painful to me, no matter how many functional features a language adds.

In my experience jumping from a Clojure shop to a large Java shop a few years ago, the benefits of persistent data structures are overstated. Mutable collections are just as good for 99% of use cases. And they're a lot faster (in single threaded code) and occasionally mutation makes things easier.

The selling point of Clojure is that persistent data structures prevent several classes of bugs (unintended mutation, locking, etc.). But in reality -- as long as your team members are good enough programmers -- I don't see these kind of bugs happen in practice.

That being said I love Clojure and the standard library is the best out of any language. It is a great choice in the small market of "projects that need simple and correct code".

Looking at an object in my debugger back in my call stack and assume I'm looking at the value as it was but in reality it was mutated in a subsequent stack gives me trust issues

It's probably fine most of the time it's just when I have to get into the weeds I want to have stability

That seems like a debugger problem, can't the debugger clone/maintain history of the object?

This is like saying "the benefits of functional programming are overstated". If you are happy with mutable collections, you've happy with mutable variables, pervasive side effects and essentially the status quo. Many of us are not happy with the level of software quality out there and the status quo, Rich Hickey included.

> the benefits of persistent data structures are overstated.

Well, what else is overstated?

- Structural editing? Fine.

- REPL-driven development? Okay, let's throw that out the window.

- Hosted nature and the interop? Gone.

- Destructuring? Eh, we kinda have it in Javascript, right?

- Concurrency support? Who needs that shit, anyway, right?

- Simplicity and elegance? Arguable. Some like verbose Typescript code more.

- Functional programming? What the heck is it even?

The point I'm trying to make is that you can't just "remove" an essential part of what makes a language. Rich Hickey took a year-long sabbatical (or was it two or even three years? I forgot) and used his savings to get this aspect of the language right. Without the immutable collections, the language would've been an entirely different beast.

It's painful for the compiler too, it has to turn the parents imperative code into SSA (essentially A-normal form) so it can optimise it!

You guys can make all the baloney claims about this you want.

The day that Haskell stops being 10x slower than languages providing mutable data is the day we can start to seriously entertain your claims.

I think the persistent collections are generally worth the cost. IIRC, for HAMT maps/sets for instance, they're about twice as slow for reads and four times as slow for writes. For bulk updates, you can also slip into using transients, and then when you're done, "freeze" it back into a persistent data structure.

I only wish that the transient collections would support more different kinds of writes, like support all operations on java.util.List/Set/Map kind of thing. Forget which ones aren't present but I remember there being a couple...

There's nothing baloney about SSA form. I'm sorry to say it, but C is just not close to the metal any more. Even if you are able to hand optimise something so it works well on one architecture, it likely won't be optimal for another.

As for Haskell, it does pretty well being 100 times faster than Python with 100 times less the number of people working on it.

I believe that your interpretation of what’s actually happening is what’s baloney.

The fact is that you Haskell people only talk about the optimizations that can sometimes open on immutable data in specific circumstances. What you generally ignore is the optimizations that immutable data permanently locks you out of with no recourse.

As with most things programming, immutability should be considered a tool, not a rule.

> I believe that your interpretation of what’s actually happening is what’s baloney.

I'm actually quoting Prof Andrew Appel of Princeton: https://www.cs.princeton.edu/~appel/papers/ssafun.pdf

You seem to think that functional programming and in-place updates are mutually exclusive. This is not the case, e.g. Haskell supports mutation as a tracked and controlled side-effect. It can even give static guarantees that a function is pure even it uses mutation internally. Recent research even suggests that compilers can add the in-place updates for us: https://www.microsoft.com/en-us/research/publication/fp2-ful...

I don’t really care which functional programming advocate you’re quoting. They’re all liars when they make these claims.

You can say SSA, static guarantees, internal mutability, blah blah blah all you want. When third party, not specifically chosen anecdotes to make FP look good, measurements stack up to the claims, we can have a better conversation.

It’s not looking good though, cause these claims of “actually, Haskell is faster than C because compiler magic” have been going on since well before stable Haskell like 15 years ago, and they’ve been lies for just as long.

>a lot of the benefits cannot be fully realized unless you’re all in

That is working under the assumption that “the benefits” are actual benefits.

IMO, “the benefits” are measurably drawbacks, and not a technical debt I am willing to accept for no good reason.

Functional programming is basically maths, it solves the problem of how to compose software safely. I struggle to understand why anyone who really cares about their craft would not want this. In fact, many want it so badly they are willing to make sacrifices for it (performance, esoteric languages).