3 ms·

Your complaint doesn't make any sense. I think you're struggling with immutability because you don't understand that it actually works very differently from mu

Your complaint doesn't make any sense. I think you're struggling with immutability because you don't understand that it actually works very differently from mutability. In this example, it's not about "making sure nobody uses foo". Nobody is making you use it again. If you don't want to use the variable again, just... don't use it again. Or, you can use it again, if you want to, but if you make an error your tests should fail or your compiler should complain about an unused variable. It's not rocket science.

taeric 12y ago
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.
- ticking 12y ago
  Just do public foo(Bar bar) { bar = baz(bar); //Lots (10+ lines) of code return finishProcess(bar); //Note, this should have been updatedBar. } nothing prevents you from reusing the variable name. The point about immutability is that the objects themselves don't change.
  - taeric 12y ago
    Alas, our style guide insists on final variables...
    - the_af 12y ago
      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.
- theseoafs 12y ago
  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.
  - taeric 12y ago
    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.
    - davexunit 12y ago
      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.
- MichaelGG 12y ago
  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.
  - taeric 12y ago
    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.
AnimalMuppet 12y ago
"Just don't use it again" might be easier said than done in a huge code base...
tjradcliffe 12y ago
In any real software development scenario one of the problems faced is precisely "making sure nobody uses foo again", and "just don't use it again" is not a solution. How do you insure that a maintenance coder ten years from now doesn't use it again?
- theseoafs 12y ago
  How do I ensure that a maintenance coder ten years from now doesn't replace the entire function with printf("butt\n"); ? Yes, sometimes developers make mistakes, but -- again -- this is what the tests are for. And I have seen no evidence that immutable data structures are more prone to errors in "maintenance coding" than mutable data structures.
  - taeric 12y ago
    Is there solid empirical evidence that it is less prone?
    - theseoafs 12y ago
      No, but no one ever said there was.
  - tjradcliffe 12y ago
    This is a completely disingenuous argument. My point is that a sincerely interested maintenance coder could easily accidentally use the wrong variable. This was the GP's point as well. This is not something that is not at all difficult to understand... for anyone who has ever actually worked on shipping code.
    - theseoafs 12y ago
      At no point did I ever indicate that it is impossible for a maintenance coder to accidentally use the wrong variable. In fact, it'll probably happen at some point. I did indicate that you should have tests in place to catch regressions like this. This is true when you're working with mutable data structures as well as immutable ones. I also indicated this type of error, once detected, is typically very easy to spot and correct. I don't know how anything I've said has even been slightly controversial.

taeric 12y ago

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.

ticking 12y ago
Just do public foo(Bar bar) { bar = baz(bar); //Lots (10+ lines) of code return finishProcess(bar); //Note, this should have been updatedBar. } nothing prevents you from reusing the variable name. The point about immutability is that the objects themselves don't change.
- taeric 12y ago
  Alas, our style guide insists on final variables...
  - the_af 12y ago
    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.
theseoafs 12y ago
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.
- taeric 12y ago
  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.
  - davexunit 12y ago
    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.
MichaelGG 12y ago
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.
- taeric 12y ago
  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.

AnimalMuppet 12y ago

"Just don't use it again" might be easier said than done in a huge code base...

tjradcliffe 12y ago

In any real software development scenario one of the problems faced is precisely "making sure nobody uses foo again", and "just don't use it again" is not a solution. How do you insure that a maintenance coder ten years from now doesn't use it again?

theseoafs 12y ago
How do I ensure that a maintenance coder ten years from now doesn't replace the entire function with printf("butt\n"); ? Yes, sometimes developers make mistakes, but -- again -- this is what the tests are for. And I have seen no evidence that immutable data structures are more prone to errors in "maintenance coding" than mutable data structures.
- taeric 12y ago
  Is there solid empirical evidence that it is less prone?
  - theseoafs 12y ago
    No, but no one ever said there was.
- tjradcliffe 12y ago
  This is a completely disingenuous argument. My point is that a sincerely interested maintenance coder could easily accidentally use the wrong variable. This was the GP's point as well. This is not something that is not at all difficult to understand... for anyone who has ever actually worked on shipping code.
  - theseoafs 12y ago
    At no point did I ever indicate that it is impossible for a maintenance coder to accidentally use the wrong variable. In fact, it'll probably happen at some point. I did indicate that you should have tests in place to catch regressions like this. This is true when you're working with mutable data structures as well as immutable ones. I also indicated this type of error, once detected, is typically very easy to spot and correct. I don't know how anything I've said has even been slightly controversial.