What really happened is that I was full in on Scala and runtime immutability because I read the plethora of medium articles pushing this stuff and I believed it.
Then I decided to use the stuff for myself and not a single claim that the runtime immutable crowd made panned out, and in fact, in many cases I found myself hard constrained in ways that fucking sucked (threading being a major one).
Then when I took a more practical approach of filing runtime immutability under “tools” rather than “rules”, I stopping having major issues with data, stopped running in to bullshit productivity walls, and stopped running in to minor refactors automatically being major ones, and overall feature implementation became easier and faster.
The only difference between me and the people pushing these things is that I actually decided to ask myself if the supposed benefits were actually panning out, and they didn’t.
Over a few years I became tired of having the exact same stupid bullshit claims without evidence relentlessly pushed by zealots and just gave up with positive engagement with them. It doesn’t matter how much you ask for these people to provide the metrics that back up their claims, they never will. They will give bullshit anecdotes. They will write intentionally bad code in other paradigms. They will lie and lie and lie and lie some more.
All that is to say that I am fully open to DoP being proven. They just have not done so.
It would be nice if you could elaborate on why you think it's idiotic. What's "better" for one scenario could be worse for another. There are tradeoffs to be made.
In my experience immutable data simplifies a lot of things and avoids a lot of common problems related to concurrency. Implementing efficient copy-on-write isn't too hard when everything is immutable.
You’re making your programs orders of magnitude slower to the back of claims that have absolutely zero metric demonstration.
>simplifies a lot of things
Runtime immutability simplifies nothing.
>avoids common problems related to concurrency
While simultaneously creating new problems. Like fine, you cannot make an edit on an object out from under the rug of another thread… except that in most cases, you have now just made that old object into invalid state that is lingering around your program like a death trap and to get around this, you are forced in to some pretty terrible synchronization bullshit that just locking objects doesn’t suffer from.
>Implementing CoW is not too difficult
The single greatest predictor of defects for every single language ever is “lines of code”. Implementing CoW sounds straight forward, but actually, incorrect CoW is a common source of bugs and you are just hand waving that away.
Not sure why you're coming across so aggressively.
Orders of magnitude slower? Citation needed. I don't think I've ever encountered any performance problems caused by immutability in anything I've worked on. But as always, there are tradeoffs, and if there's a bottleneck then it can be addressed when identified.
> The single greatest predictor of defects for every single language ever is “lines of code”.
Did you hallucinate whatever you think you replied to? At no point did I mention LoC. I mentioned simplicity. Two very different things.
You are reading aggression in based on the fact that I am disagreeing with you. It is text over the internet. Whatever tone you are gathering is purely imagined. I would suggest you visit fewer circle jerk areas and discuss things. People telling you you’re wrong and why is not aggression.
>source
I mean. I assume you’re a developer as you have a strong opinion on immutability. So just test it? It isn’t as if testing the impacts of immutability of performance is a difficult thing to test out.
It is actually difficult to find results because functional programmers have flooded the internet with “yes performance is impacted, but performance doesn’t matter. Performance is a premature optimization”
Nevertheless, even with things smaller than a register, performance is impacted here:
By several X. Now get it objects that are larger than a register with numerous stack blowing deep copies and the effects are massively more pronounced.
The fastest Haskell game engine looks like PlayStation 2 on modern hardware.
I mean. That immutability massively hurts performance is not a point of contention, even among immutability fanboys.
>did you hallucinate
I think you forgot your own post. You stated that CoW is trivial and I gave you a specific reason as to why that claim is a lie.
