I literally just had to fix this error in my colleague's code. It looked a little more like:
public foo(Bar bar) {
Bar updatedBar = baz(bar);
//Lots (10+ lines) of code
return finishProcess(bar); //Note, this should have been updatedBar.
}
Now, again, I will not defend this as good code. Neither would my coworker. Mistakes happen, though. And while I will not claim that mutable code is free of defects and makes it easier to write troublefree code, I do take issue with the claim that immutability does accomplish this.
In my opinion, there is a reason for that. Consider the example above, slightly changed:
public foo(Bar bar) {
bar = baz(bar);
//Lots (10+ lines) of code.
bar = qux(bar);
//Lots (10+ lines) of code.
return finishProcess(bar);
}
It is hard to spot the second reuse of variable bar. This can make code harder to understand; it's a lot easier to just look at the point of definition of a variable and assume it never changes. At least, that is why I tend to use final when writing Java, and val when writing Scala.
Of course, usually when adding final to messy Java code I'm trying to understand, this ends up telling me that the whole piece of code was fragile, hard to understand and in dire need of a refactoring. All of which makes final useful to me.
Again, if you forget to use a variable, your compiler should let you know. If that wouldn't have prevented this error, then oh well, but it's not like this kind of problem is particularly difficult to solve or wrap your head around.
Also, I don't know why you're acting like this kind of error represents the ultimate failure of functional programming. Yes, sometimes you get your variables a little mixed up when you're using immutable data structures. You get used to it, and if that's the biggest headache that you come across when working with immutable data structures, then it seems like everything is more or less working as advertised.
The variable was used again, just not in the final line like it should have been.
Where did I say this was the ultimate failure of functional programming? I do not think it is. Nor do I think functional programming is a failure. It is a good skill to have. But so is understanding some of the non-immutable algorithms out there.
If the above function mutated 'bar', then it wouldn't be referentially transparent, which is a lot more error prone and problematic than the trivial error your colleague made.
That said, that function looks strange. What were those other lines of code doing if they didn't contribute to the result? Doesn't look like a referentially transparent function to me.
This this an unfortunate language that won't let you overwrite or "shadow" bindings? In F#, for instance, I try to scope and/or rebind identifiers that shouldn't be used.
This sounds like a scotsman's argument. I could have just reassigned the value, however we have style guidelines saying they have to be final. So, yes, I could have shadowed it in another block or function. At that point, I'm beginning to question just how immutable we wan't the view of the world to be.
This gets back to my point in a sibling about more types and better organization could have helped. Sure. I'm not even going to claim that immutability caused this bug. As it didn't. It also was not a silver bullet that helped make this code bug free.
