5 ms·

Your example makes no sense to me, particularly the "find everywhere this matters" part. Working with immutable data is fairly straightforward. You perform an

Your example makes no sense to me, particularly the "find everywhere this matters" part. Working with immutable data is fairly straightforward. You perform an operation on a data structure, which produces a new version of that data structure, and then you to return it.

taeric 12y ago
This only works if you still have a reference to the root of the structure everywhere. Which is why something like Huet's zipper works. If you did not build such a structure, then you are likely out of luck. A better example would be SomeLargeTreeThing foo bar = sanitizeTreeThing(foo); //Now, make extra sure nobody uses foo. //Not even accidentally in the future. Now, this can be solved with more types and more layers. So, yes, it is bad code. But, "write less crappy code" is far less sexy than "immutability prevents errors!"
- ticking 12y ago
  I think you got immutability and single side assignment mixed up. If foo is immutable there is no harm if something else tries to manipulate it because it will just derive a new data-structure.
- theseoafs 12y ago
  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.
  - 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

This only works if you still have a reference to the root of the structure everywhere. Which is why something like Huet's zipper works. If you did not build such a structure, then you are likely out of luck. A better example would be SomeLargeTreeThing foo bar = sanitizeTreeThing(foo); //Now, make extra sure nobody uses foo. //Not even accidentally in the future. Now, this can be solved with more types and more layers. So, yes, it is bad code. But, "write less crappy code" is far less sexy than "immutability prevents errors!"

ticking 12y ago
I think you got immutability and single side assignment mixed up. If foo is immutable there is no harm if something else tries to manipulate it because it will just derive a new data-structure.
theseoafs 12y ago
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.
- 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.