Hacker News Reader

Comment by taeric | Hacker News Reader

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!"

View on HN

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.

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.

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.

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.

Alas, our style guide insists on final variables...

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.

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

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?

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.

Is there solid empirical evidence that it is less prone?

No, but no one ever said there was.

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.

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.

You can use a linear type system to enforce that.

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.

Reply on news.ycombinator.com